Zigbee Specification: June 27, 2005

ZigBee Specification
ZigBee Document 053474r06, Version 1.0
December 14th, 2004
Sponsored by: ZigBee Alliance
Accepted by ZigBee Alliance Board of Directors.
Abstract The ZigBee Specification describes the infrastructure and services available to
applications operating on the ZigBee platform.
Keywords ZigBee, Stack, Network, Application, Profile, Framework, Device description, Bind-
ing, Security
June 27, 2005

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
2 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

1
2
Legal Notice The ZigBee Specification is available to individuals, companies and institutions free of
3 charge for all non-commercial purposes (including university research, technical evalua-
4 tion, and development of non-commercial software, tools, or documentation). For ease of
5 use, clearly marked errata have been incorporated into this document. These errata may
6 not have been subjected to an Intellectual Property review, and as such, may contain
undeclared Necessary Claims. No part of this specification may be used in development
7
of a product for sale without becoming a member of ZigBee Alliance.
8
9 Copyright © ZigBee Alliance, Inc. (2005). All rights Reserved. This information within this
10 document is the property of the ZigBee Alliance and its use and disclosure are restricted.
11
Elements of ZigBee Alliance specifications may be subject to third party intellectual prop-
12
erty rights, including without limitation, patent, copyright or trademark rights (such a third
13 party may or may not be a member of ZigBee). ZigBee is not responsible and shall not be
14 held responsible in any manner for identifying or failing to identify any or all such third
15 party intellectual property rights.
16
This document and the information contained herein are provided on an “AS IS” basis
17
and ZigBee DISCLAIMS ALL WARRANTIES EXPRESS OR IMPLIED, INCLUDING BUT
18 NOT LIMITED TO (A) ANY WARRANTY THAT THE USE OF THE INFORMATION
19 HEREIN WILL NOT INFRINGE ANY RIGHTS OF THIRD PARTIES (INCLUDING WITH-
20 OUT LIMITATION ANY INTELLECTUAL PROPERTY RIGHTS INCLUDING PATENT,
21 COPYRIGHT OR TRADEMARK RIGHTS) OR (B) ANY IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NON-
22
INFRINGEMENT. IN NO EVENT WILL ZIGBEE BE LIABLE FOR ANY LOSS OF PROF-
23 ITS, LOSS OF BUSINESS, LOSS OF USE OF DATA, INTERRUPTION OF BUSINESS,
24 OR FOR ANY OTHER DIRECT, INDIRECT, SPECIAL OR EXEMPLARY, INCIDENTIAL,
25 PUNITIVE OR CONSEQUENTIAL DAMAGES OF ANY KIND, IN CONTRACT OR IN
26 TORT, IN CONNECTION WITH THIS DOCUMENT OR THE INFORMATION CON-
TAINED HEREIN, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH LOSS OR DAM-
27
AGE. All Company, brand and product names may be trademarks that are the sole
28 property of their respective owners.
29
30 The above notice and this paragraph must be included on all copies of this document that
31 are made.
32
ZigBee Alliance, Inc.
33 2400 Camino Ramon, Suite 375
34 San Ramon, CA 94583
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Contents 1
2
3
4
5
Chapter 1 Application Layer Specification ..................................................... 29
6
1.1 General description .......................................................................................................... 29 7
1.1.1 Application support sub-layer............................................................................... 29 8
1.1.2 Application framework.......................................................................................... 29 9
1.1.3 Addressing ........................................................................................................... 30 10
1.1.4 Application communication fundamentals............................................................ 32 11
1.1.5 Discovery ............................................................................................................. 32 12
1.1.6 Binding ................................................................................................................. 33 13
1.1.7 Messaging............................................................................................................ 34 14
1.1.8 ZigBee device objects.......................................................................................... 35 15
16
1.2 The ZigBee application support (APS) sub-layer ............................................................. 35
17
1.2.1 Scope................................................................................................................... 35
18
1.2.2 Purpose................................................................................................................ 36
19
1.2.3 Application support (APS) sub-layer overview..................................................... 36
20
1.2.4 Service specification ............................................................................................ 37
21
1.2.5 Frame formats...................................................................................................... 51
22
1.2.6 Command frames ................................................................................................ 56
23
1.2.7 Constants and PIB attributes ............................................................................... 56
24
1.2.8 Functional description .......................................................................................... 57
25
1.3 The ZigBee application framework ................................................................................... 62 26
1.3.1 Creating a ZigBee profile ..................................................................................... 62 27
1.3.2 Standard data type formats.................................................................................. 64 28
1.3.3 ZigBee descriptors ............................................................................................... 67 29
1.3.4 AF frame formats ................................................................................................. 77 30
1.3.5 KVP command frames ......................................................................................... 81 31
1.3.6 Functional description .......................................................................................... 86 32
33
1.4 The ZigBee device profile................................................................................................. 86
34
1.4.1 Scope................................................................................................................... 86
35
1.4.2 Device Profile overview........................................................................................ 86
36
1.4.3 Client services...................................................................................................... 89
37
1.4.4 Server services .................................................................................................. 109
38
1.4.5 ZDP enumeration description ............................................................................ 132
39
1.4.6 Conformance ..................................................................................................... 133
40
1.5 The ZigBee device objects (ZDO) .................................................................................. 133 41
1.5.1 Scope................................................................................................................. 133 42
1.5.2 Device Object Descriptions................................................................................ 134 43
1.5.3 Layer Interface Description ................................................................................ 136 44
1.5.4 System Usage.................................................................................................... 137 45
1.5.5 Object Definition and Behavior .......................................................................... 140 46
1.5.6 Configuration Attributes ..................................................................................... 151 47
48
Chapter 2 Network Specification ................................................................... 159 49
50
2.1 NWK layer status values ................................................................................................ 159 51
2.2 General description ........................................................................................................ 160 52
2.2.1 Network (NWK) layer overview .......................................................................... 160 53
54
Copyright © 2005 ZigBee Standards Organization. All rights reserved. 5

1 2.3 Service specification....................................................................................................... 161

2 2.3.1 NWK data service .............................................................................................. 161
3 2.3.2 Network discovery.............................................................................................. 166
4 2.3.3 Network formation.............................................................................................. 169
5 2.3.4 Allowing devices to join...................................................................................... 172
6 2.3.5 Begin as a router................................................................................................ 173
7 2.3.6 Joining a network ............................................................................................... 175
8 2.3.7 Joining a device directly to a network ................................................................ 181
9 2.3.8 Leaving a network.............................................................................................. 183
10 2.3.9 Resetting a device ............................................................................................. 186
11 2.3.10 Receiver synchronization................................................................................... 188
12 2.3.11 Information base maintenance........................................................................... 192
13
2.4 Frame formats ................................................................................................................ 195
14
2.4.1 General NPDU frame format.............................................................................. 195
15
2.4.2 Format of individual frame types........................................................................ 197
16
17 2.5 Command frames ........................................................................................................... 198
18 2.5.1 Route request command.................................................................................... 199
19 2.5.2 Route reply command........................................................................................ 200
20 2.5.3 Route error command ........................................................................................ 202
21 2.5.4 Leave command ................................................................................................ 203
22
2.6 Constants and NIB attributes.......................................................................................... 204
23
2.6.1 NWK constants .................................................................................................. 204
24
2.6.2 NWK information base ....................................................................................... 206
25
26 2.7 Functional description..................................................................................................... 209
27 2.7.1 Network and device maintenance...................................................................... 209
28 2.7.2 Transmission and reception............................................................................... 230
29 2.7.3 Routing............................................................................................................... 231
30 2.7.4 Scheduling beacon transmissions ..................................................................... 245
31 2.7.5 Broadcast communication.................................................................................. 247
32 2.7.6 NWK information in the MAC beacons .............................................................. 249
33 2.7.7 Persistent data ................................................................................................... 251
34
35 Chapter 3 Security Services Specification ................................................... 253
36
37 3.1 Document Organization.................................................................................................. 253
38 3.2 General Description........................................................................................................ 253
39 3.2.1 Security Architecture and Design....................................................................... 253
40 3.2.2 MAC Layer Security ........................................................................................... 255
41 3.2.3 NWK Layer Security........................................................................................... 256
42 3.2.4 APL Layer Security ............................................................................................ 258
43 3.2.5 Trust Center Role............................................................................................... 259
44
45 3.3 MAC Layer Security........................................................................................................ 260
46 3.3.1 Frame Security................................................................................................... 260
47 3.3.2 Security-Related MAC PIB Attributes ................................................................ 262
48 3.4 NWK Layer Security ....................................................................................................... 262
49 3.4.1 Frame Security................................................................................................... 263
50 3.4.2 Secured NPDU Frame ....................................................................................... 265
51 3.4.3 Security-Related NIB Attributes ......................................................................... 265
52
53 3.5 APS Layer Security ........................................................................................................ 267
54 3.5.1 Frame Security................................................................................................... 268

.
Contents
3.5.2 Key-Establishment Services .............................................................................. 271 1

3.5.3 Transport-Key Services ..................................................................................... 278 2
3.5.4 Update-Device Services .................................................................................... 283 3
3.5.5 Remove Device Services................................................................................... 285 4
3.5.6 Request Key Services........................................................................................ 287 5
3.5.7 Switch Key Services .......................................................................................... 289 6
3.5.8 Secured APDU Frame ....................................................................................... 291 7
3.5.9 Command Frames ............................................................................................. 291 8
3.5.10 Security-Related AIB Attributes ......................................................................... 296 9
10
3.6 Common Security Elements ........................................................................................... 297
11
3.6.1 Auxiliary Frame Header Format......................................................................... 298
12
3.6.2 Security Parameters .......................................................................................... 299
13
3.6.3 Cryptographic Key Hierarchy ............................................................................. 300
14
3.6.4 Implementation Guidelines (Informative) ........................................................... 300
15
3.7 Functional Description .................................................................................................... 301 16
3.7.1 ZigBee Coordinator............................................................................................ 301 17
3.7.2 Trust Center Application .................................................................................... 301 18
3.7.3 Security Procedures........................................................................................... 302 19
20
Annex A CCM* Mode of Operation .............................................................. 315 21
22
A.1 Notation and representation ............................................................................................. 315 23
A.2 CCM* mode encryption and authentication transformation.............................................. 315 24
25
A.2.1 Input transformation ........................................................................................... 316
26
A.2.2 Authentication transformation ............................................................................ 316 27
A.2.3 Encryption transformation .................................................................................. 317 28
A.3 CCM* mode decryption and authentication checking transformation............................... 318 29
30
A.3.1 Decryption transformation.................................................................................. 318
31
A.3.2 Authentication checking transformation ............................................................. 318 32
A.4 Restrictions....................................................................................................................... 318 33
34
35
Annex B Security Building Blocks .............................................................. 319
36
B.1 Symmetric-key cryptographic building blocks .................................................................. 319 37
B.1.1 Block-cipher ....................................................................................................... 319 38
B.1.2 Mode of operation .............................................................................................. 319 39
40
B.1.3 Cryptographic hash function .............................................................................. 319
41
B.1.4 Keyed hash function for message authentication .............................................. 319 42
B.1.5 Specialized keyed hash function for message authentication ........................... 320 43
B.1.6 Challenge domain parameters........................................................................... 320 44
45
B.2 Key Agreement Schemes................................................................................................. 320
46
B.2.1 Symmetric-key key agreement scheme............................................................. 320 47
B.3 Challenge Domain Parameter Generation and Validation ............................................... 320 48
B.3.1 Challenge Domain Parameter Generation......................................................... 321 49
50
B.3.2 Challenge Domain Parameter Verification......................................................... 321
51
B.4 Challenge Validation Primitive.......................................................................................... 321 52
53
B.5 Secret Key Generation (SKG) Primitive ........................................................................... 322
54

1 B.6 Block-Cipher-Based Cryptographic Hash Function.......................................................... 323

2
B.7 Symmetric-Key Authenticated Key Agreement Scheme .................................................. 323
3
4 B.7.1 Initiator Transformation ...................................................................................... 325
5 B.7.2 Responder Transformation ................................................................................ 326
6
7 Annex C Test Vectors for Cryptographic Building Blocks ....................... 329
8
9 C.1 Data Conversions............................................................................................................. 329
10 C.2 AES Block Cipher............................................................................................................. 329
11
12 C.3 CCM* Mode Encryption and Authentication Transformation............................................ 329
13 C.3.1 Input Transformation.......................................................................................... 329
14 C.3.2 Authentication Transformation ........................................................................... 330
15 C.3.3 Encryption Transformation................................................................................. 331
16
17 C.4 CCM* Mode Decryption and Authentication Checking Transformation............................ 331
18 C.4.1 Decryption Transformation................................................................................. 332
19 C.4.2 Authentication Checking Transformation ........................................................... 333
20
C.5 Cryptographic Hash Function........................................................................................... 333
21
22 C.5.1 Test Vector Set 1 ............................................................................................... 333
23 C.5.2 Test Vector Set 2 ............................................................................................... 334
24 C.6 Keyed Hash Function for Message Authentication .......................................................... 335
25
C.6.1 Test Vector Set 1 ............................................................................................... 335
26
27 C.6.2 Test Vector Set 2 ............................................................................................... 335
28 C.7 Specialized Keyed Hash Function for Message Authentication ....................................... 336
29
30 C.8 Symmetric-Key Key Agreement Scheme ......................................................................... 337
31 C.8.1 Initiator Transformation ...................................................................................... 337
32 C.8.2 Responder Transformation ................................................................................ 339
33
34 Annex D ZigBee Protocol Stack, Settable Values (Knobs) ....................... 341
35
36 D.1 Network Settings .............................................................................................................. 341
37 D.1.1 nwkMaxDepth and nwkMaxChildren.................................................................. 341
38 D.1.2 NwkMaxRouters................................................................................................. 342
39 D.1.3 Size of routing table ........................................................................................... 344
40
D.1.4 Size of neighbor table ........................................................................................ 345
41
42 D.1.5 Size of route discovery table.............................................................................. 346
43 D.1.6 Number of reserved routing table entries........................................................... 347
44 D.1.7 Buffering pending route discovery ..................................................................... 348
45 D.1.8 Buffering on behalf of end devices..................................................................... 349
46 D.1.9 Routing cost calculation ..................................................................................... 349
47
D.1.10 nwkSymLink....................................................................................................... 350
48
49 D.2 Application Settings.......................................................................................................... 351
50
D.3 Security Settings .............................................................................................................. 360
51
52
53 Annex E ZigBee Stack Profiles.................................................................... 367
54

.
Contents
E.1 Stack Profiles ................................................................................................................... 367 1

2
E.2 Stack Profile Definitions ................................................................................................... 367
3
E.3 Home Controls Stack Profile ............................................................................................ 367 4
E.3.1 Network Settings................................................................................................ 368 5
E.3.2 Application Settings ........................................................................................... 368 6
7
E.3.3 Security Settings ................................................................................................ 369
8
E.4 Building Automation Stack Profile .................................................................................... 369 9
12
13
E.5 Plant Control Stack Profile ............................................................................................... 371 14
17
18
19
Annex F KVP XML schemas ........................................................................ 373 20
F.1 XML schema for the get command .................................................................................. 373 21
22
F.2 XML schema for the get response command................................................................... 373 23
F.3 XML schema for the set command................................................................................... 374 24
25
F.4 XML schema for the set response command................................................................... 374 26
F.5 XML schema for the event command............................................................................... 375 27
28
F.6 XML schema for the event response command............................................................... 375 29
F.7 Example KVP commands................................................................................................. 376 30
31
F.8 Example MSG command ................................................................................................. 377 32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

.
Figures 1
2
3
4
5
6
7
8
Figure 1 Outline ZigBee stack architecture ............................................................................... 18
9
Figure 2 Multiple subunits in a single node ............................................................................... 31
10
Figure 3 ZigBee binding and binding table................................................................................ 33
11
Figure 4 The APS sub-layer reference model ........................................................................... 37
12
Figure 5 General APS frame format.......................................................................................... 51
13
Figure 6 Format of the frame control field ................................................................................. 51
14
Figure 7 Data frame format ....................................................................................................... 54
15
Figure 8 APS command frame format....................................................................................... 54
16
Figure 9 Acknowledgement frame format ................................................................................. 55
17
Figure 10 Direct binding on a ZigBee coordinator or SrcAddr device ......................................... 59
18
Figure 11 Successful data transmission without an acknowledgement ...................................... 61
19
Figure 12 Successful data transmission with an acknowledgement ........................................... 61
20
Figure 13 Format of the character string type ............................................................................. 67
21
Figure 14 Format of the octet string type .................................................................................... 67
22
Figure 15 Format of the complex descriptor................................................................................ 68
23
Figure 16 Format of an individual complex descriptor field ......................................................... 68
24
Figure 17 Format of the MAC capability flags field...................................................................... 70
25
Figure 18 Format of the language and character set field........................................................... 75
26
Figure 19 Format of the general application framework command frame................................... 77
27
Figure 20 Format of a transaction field........................................................................................ 77
28
Figure 21 Format of the general KVP command frame............................................................... 78
29
Figure 22 Format of the MSG transaction frame......................................................................... 80
30
Figure 23 Format of the get with acknowledgement command frame ........................................ 81
31
Figure 24 Format of the get response command frame .............................................................. 82
32
Figure 25 Format of the set/set with acknowledgement command frame................................... 83
33
Figure 26 Format of the set response command frame .............................................................. 84
34
Figure 27 Format of the event/event with acknowledgement command frame........................... 84
35
Figure 28 Format of the event response command frame .......................................................... 85
36
Figure 29 Cluster ID Format for the Device Profile ..................................................................... 89
37
Figure 30 ZigBee Device Object details .................................................................................... 139
38
Figure 31 The NWK layer reference model............................................................................... 161
39
Figure 32 Capability Information parameter format................................................................... 182
40
Figure 33 Message sequence chart for resetting the network layer.......................................... 188
41
Figure 34 Message sequence chart for synchronizing in a non-beaconing network................. 191
42
Figure 35 Message sequence chart for synchronizing in a beacon-enabled network............... 191
43
Figure 36 General NWK frame format....................................................................................... 195
44
Figure 37 Frame control field .................................................................................................... 195
45
Figure 38 Data frame format ..................................................................................................... 197
46
Figure 39 NWK command frame format.................................................................................... 198
47
Figure 40 Route request command frame format ..................................................................... 199
48
Figure 41 Route request command options field....................................................................... 200
49
Figure 42 Route reply command format.................................................................................... 200
50
Figure 43 Route reply command options field........................................................................... 201
51
Figure 44 Route error command frame format.......................................................................... 202
52
Figure 45 Leave command frame format .................................................................................. 203
53
Figure 46 Leave command options field ................................................................................... 204
54

Figures
Figure 47 Establishing a new network....................................................................................... 211 1

Figure 48 Permitting devices to join a network.......................................................................... 212 2
Figure 49 Procedure for joining a network through association ................................................ 215 3
Figure 50 Procedure for handling a join request ....................................................................... 216 4
Figure 51 Joining a device to a network directly ....................................................................... 217 5
Figure 52 Child procedure for joining or re-joining a network through orphaning ..................... 218 6
Figure 53 Parent procedure for joining or re-joining a device to its network through orphaning219 7
Figure 54 Address assignment in an example network............................................................. 224 8
Figure 55 Sequence diagrams for NLME-LEAVE.request, various scenarios .......................... 228 9
Figure 56 Leave command, various scenarios.......................................................................... 229 10
Figure 57 Basic routing algorithm.............................................................................................. 237 11
Figure 58 Receipt of route request............................................................................................ 241 12
Figure 59 Receipt of route reply ................................................................................................ 243 13
Figure 60 Typical frame structure for a beaconing device ........................................................ 245 14
Figure 61 Parent-child superframe positioning relationship ...................................................... 246 15
Figure 62 Broadcast transaction message sequence chart ...................................................... 249 16
Figure 63 Format of the MAC sub-layer beacon payload.......................................................... 251 17
Figure 64 ZigBee frame with security at the MAC level ............................................................ 256 18
Figure 65 ZigBee frame with security on the NWK level ........................................................... 257 19
Figure 66 ZigBee frame with security on the APS level ............................................................ 258 20
Figure 67 Secured NWK layer frame format ............................................................................. 265 21
Figure 68 Sequence chart for successful APSME-ESTABLISH-KEY primitives....................... 275 22
Figure 69 Secured APS layer frame format .............................................................................. 291 23
Figure 70 Generic SKKE frame command format..................................................................... 292 24
Figure 71 Transport-key command frame ................................................................................. 293 25
Figure 72 Trust center master key descriptor field in transport-key command ......................... 293 26
Figure 73 Network key descriptor field in transport-key command ........................................... 294 27
Figure 74 Application master key descriptor in transport-key command................................... 294 28
Figure 75 Update-device command frame format..................................................................... 294 29
Figure 76 Remove-device command frame format ................................................................... 295 30
Figure 77 Request-key command frame format........................................................................ 295 31
Figure 78 Switch-key command frame format........................................................................... 296 32
Figure 79 Auxiliary frame header format ................................................................................... 298 33
Figure 80 Security control field format....................................................................................... 298 34
Figure 81 CCM* nonce.............................................................................................................. 300 35
Figure 82 Example of joining a secured network ...................................................................... 302 36
Figure 83 Example residential-mode authentication procedure ................................................ 307 37
Figure 84 Example commercial-mode authentication procedure .............................................. 308 38
Figure 85 Example Network key-update procedure .................................................................. 309 39
Figure 86 Example Network key-recovery procedure ............................................................... 310 40
Figure 87 Example end-to-end application key establishment procedure................................. 312 41
Figure 88 Example remove-device procedure .......................................................................... 314 42
Figure 89 Example device-leave procedure.............................................................................. 314 43
Figure 90 Symmetric-Key Authenticated Key Agreement Scheme........................................... 324 44
Figure 91 Example of a set with acknowledgement command frame ....................................... 376 45
Figure 92 Example of a set response command frame............................................................. 376 46
Figure 93 Example of a KVP set command frame .................................................................... 376 47
Figure 94 Example of an MSG command frame to set the speed of a fan ............................... 377 48
Figure 95 Example of an MSG command frame to set x and y coordinates of a sensor .......... 377 49
50
51
52
53
54

Tables 1
2
3
4
5
6
7
8
Table 1 APSDE-SAP primitives.............................................................................................. 37
9
Table 2 APSDE-DATA.request parameters ........................................................................... 38
10
Table 3 APSDE-DATA.confirm parameters ........................................................................... 41
11
Table 4 APSDE-DATA.indication parameters ........................................................................ 42
12
Table 5 Summary of the primitives accessed through the APSME-SAP ............................... 43
13
Table 6 APSME-BIND.request parameters............................................................................ 44
14
Table 7 APSME-BIND.confirm parameters ............................................................................ 45
15
Table 8 APSME-UNBIND.request parameters....................................................................... 46
16
Table 9 APSME-UNBIND.confirm parameters....................................................................... 47
17
Table 10 APSME-GET.request parameters ............................................................................. 48
18
Table 11 APSME-GET.confirm parameters ............................................................................. 49
19
Table 12 APSME-SET.request parameters ............................................................................. 50
20
Table 13 APSME-SET.confirm parameters.............................................................................. 50
21
Table 14 Values of the frame type sub-field............................................................................. 52
22
Table 15 Values of the delivery mode sub-field ....................................................................... 52
23
Table 16 APS sub-layer constants ........................................................................................... 56
24
Table 17 APS IB attributes ....................................................................................................... 57
25
Table 18 Address Map ............................................................................................................. 57
26
Table 19 ZigBee standard data types ...................................................................................... 64
27
Table 20 ZigBee descriptors .................................................................................................... 67
28
Table 21 Fields of the node descriptor ..................................................................................... 69
29
Table 22 Values of the logical type field................................................................................... 69
30
Table 23 Values of the frequency band field ............................................................................ 70
31
Table 24 Fields of the node power descriptor .......................................................................... 71
32
Table 25 Values of the current power mode field..................................................................... 71
33
Table 26 Values of the available power sources field .............................................................. 72
34
Table 27 Values of the current power sources field ................................................................. 72
35
Table 28 Values of the current power source level field........................................................... 72
36
Table 29 Fields of the simple descriptor................................................................................... 73
37
Table 30 Values of the application device version field............................................................ 74
38
Table 31 Values of the application flags field ........................................................................... 74
39
Table 32 Fields of the complex descriptor................................................................................ 75
40
Table 33 Values of the character set identifier sub-field .......................................................... 76
41
Table 34 Fields of the user descriptor ...................................................................................... 77
42
Table 35 Values of the frame type field.................................................................................... 77
43
Table 36 Values of the command type identifier field............................................................... 79
44
Table 37 Values of the error code field .................................................................................... 79
45
Table 38 Device and Service Discovery Client Services primitives ......................................... 90
46
Table 39 NWK_addr_req parameters ...................................................................................... 91
47
Table 40 IEEE_addr_req parameters....................................................................................... 92
48
Table 41 Node_Desc_req parameters ..................................................................................... 93
49
Table 42 Power_Desc_req parameters.................................................................................... 93
50
Table 43 Simple_Desc_req parameters................................................................................... 94
51
Table 44 Active_EP_req parameters ....................................................................................... 95
52
Table 45 Match_Desc_req parameters .................................................................................... 95
53
Table 46 Complex_Desc_req parameters................................................................................ 97
54

1 Table 47 User_Desc_req parameters ...................................................................................... 97

2 Table 48 Discovery_Register_req parameters......................................................................... 98
3 Table 49 End_Device_annce parameters ................................................................................ 99
4 Table 50 User_Desc_set parameters....................................................................................... 99
5 Table 51 End Device Bind, Bind and Unbind Client Services primitives ................................ 100
6 Table 52 End_Device_Bind_req parameters ......................................................................... 101
7 Table 53 Bind_req parameters............................................................................................... 102
8 Table 54 Unbind_req parameters........................................................................................... 103
9 Table 55 Network Management Client Services primitives .................................................... 104
10 Table 56 Mgmt_NWK_Disc_req parameters.......................................................................... 105
11 Table 57 Mgmt_Lqi_req parameters ...................................................................................... 106
12 Table 58 Mgmt_Rtg_req parameters ..................................................................................... 106
13 Table 59 Mgmt_Bind_req parameters.................................................................................... 107
14 Table 60 Mgmt_Leave_req parameters ................................................................................. 108
15 Table 61 Mgmt_Direct_Join_req parameters ......................................................................... 109
16 Table 62 Device and Service Discovery Server Services primitives ...................................... 109
17 Table 63 NWK_addr_rsp parameters..................................................................................... 110
18 Table 64 IEEE_addr_rsp parameters..................................................................................... 112
19 Table 65 Node_Desc_rsp parameters ................................................................................... 113
20 Table 66 Power_Desc_rsp parameters.................................................................................. 114
21 Table 67 Simple_Desc_rsp parameters ................................................................................. 115
22 Table 68 Active_EP_rsp parameters...................................................................................... 116
23 Table 69 Match_Desc_rsp parameters .................................................................................. 117
24 Table 70 Complex_Desc_rsp parameters.............................................................................. 118
25 Table 71 User_Desc_rsp parameters .................................................................................... 119
26 Table 72 Discovery_Register_rsp parameters ....................................................................... 119
27 Table 73 User_Desc_conf parameters................................................................................... 120
28 Table 74 End Device Bind, Bind and Unbind Server Services primitives............................... 121
29 Table 75 End_Device_Bind_rsp parameters.......................................................................... 121
30 Table 76 Bind_rsp parameters ............................................................................................... 122
31 Table 77 Unbind_rsp parameters........................................................................................... 123
32 Table 78 Network Management Server Services primitives................................................... 123
33 Table 79 Mgmt_NWK_Disc_rsp parameters.......................................................................... 124
34 Table 80 Mgmt_Lqi_rsp parameters ...................................................................................... 125
35 Table 81 NeighborTableList record format ............................................................................. 126
36 Table 82 Mgmt_Rtg_rsp parameters...................................................................................... 128
37 Table 83 RoutingTableList record format ............................................................................... 128
38 Table 84 Mgmt_Bind_rsp parameters .................................................................................... 130
39 Table 85 BindingTableList record format................................................................................ 130
40 Table 86 Mgmt_Leave_rsp parameters ................................................................................. 131
41 Table 87 Mgmt_Direct_Join_rsp parameters ......................................................................... 132
42 Table 88 ZDP enumerations description ................................................................................ 133
43 Table 89 ZigBee Device Objects............................................................................................ 140
44 Table 90 Device and Service Discovery Attributes ................................................................ 146
45 Table 91 Security Manager Attributes .................................................................................... 147
46 Table 92 Binding Manager Attributes ..................................................................................... 148
47 Table 93 Network Manager Attributes.................................................................................... 149
48 Table 94 Node manager attributes......................................................................................... 150
49 Table 95 Configuration Attributes........................................................................................... 151
50 Table 96 NWK layer status values ......................................................................................... 159
51 Table 97 NLDE-SAP Primitives.............................................................................................. 161
52 Table 98 NLDE-DATA.request parameters............................................................................ 162
53 Table 99 NLDE-DATA.confirm parameters ............................................................................ 164
54 Table 100 NLDE-DATA.indication parameters......................................................................... 165

Tables
Table 101 Summary of the primitives accessed through the NLME-SAP ................................ 165 1
Table 102 NLME-NETWORK-DISCOVERY.request parameters ............................................ 167 2
Table 103 NLME-NETWORK-DISCOVERY.confirm parameters ............................................ 168 3
Table 104 Network descriptor information fields ...................................................................... 168 4
Table 105 NLME-NETWORK-FORMATION.request parameters............................................ 169 5
Table 106 NLME-NETWORK-FORMATION.confirm parameters ............................................ 171 6
Table 107 NLME-PERMIT-JOINING.request parameters........................................................ 172 7
Table 108 NLME-PERMIT-JOINING.confirm parameters........................................................ 173 8
Table 109 NLME-START-ROUTER.request parameters......................................................... 174 9
Table 110 NLME-START-ROUTER.confirm parameters ......................................................... 175 10
Table 111 NLME-JOIN.request parameters............................................................................. 176 11
Table 112 CapabilityInformation bit-fields ................................................................................ 178 12
Table 113 NLME-JOIN.indication parameters.......................................................................... 180 13
Table 114 NLME-JOIN.confirm parameters ............................................................................. 181 14
Table 115 NLME-DIRECT-JOIN.request parameters .............................................................. 182 15
Table 116 NLME-DIRECT-JOIN.confirm parameters .............................................................. 183 16
Table 117 NLME-LEAVE.request parameters ......................................................................... 184 17
Table 118 NLME-LEAVE.indication parameters ...................................................................... 185 18
Table 119 NLME-LEAVE.confirm parameters.......................................................................... 186 19
Table 120 NLME-RESET.confirm parameters ......................................................................... 187 20
Table 121 NLME-SYNC.request parameters ........................................................................... 189 21
Table 122 NLME-SYNC.confirm parameters ........................................................................... 190 22
Table 123 NLME-GET.request parameters.............................................................................. 192 23
Table 124 NLME-GET.confirm parameters.............................................................................. 193 24
Table 125 NLME-SET.request parameters .............................................................................. 193 25
Table 126 NLME-SET.confirm parameters .............................................................................. 194 26
Table 127 Values of the frame type sub-field........................................................................... 196 27
Table 128 Values of the discover route sub-field ..................................................................... 196 28
Table 129 NWK command frames ........................................................................................... 198 29
Table 130 Error codes for route error command frame............................................................ 203 30
Table 131 NWK layer constants............................................................................................... 204 31
Table 132 NWK IB attributes.................................................................................................... 206 32
Table 133 Neighbor table entry format..................................................................................... 220 33
Table 134 Example addressing offset values for each given depth within the network ........... 224 34
Table 135 Routing table ........................................................................................................... 233 35
Table 136 Route status values................................................................................................. 233 36
Table 137 Route discovery table.............................................................................................. 234 37
Table 138 Start time for beacon transmissions ........................................................................ 247 38
Table 139 NWK layer information fields ................................................................................... 250 39
Table 140 NIB security attributes ............................................................................................ 265 40
Table 141 Elements of the network security material descriptor.............................................. 266 41
Table 142 Elements of the incoming frame counter descriptor ................................................ 267 42
Table 143 The APS layer security primitives............................................................................ 267 43
Table 144 APSME-ESTABLISH-KEY.request parameters ...................................................... 271 44
Table 145 APSME-ESTABLISH-KEY.confirm parameters ...................................................... 273 45
Table 146 APSME-ESTABLISH-KEY.indication parameters ................................................... 273 46
Table 147 APSME-ESTABLISH-KEY.response parameters . ................................................. 274 47
Table 148 Mapping of frame names to symmetric-key key agreement scheme messages..... 275 48
Table 149 Mapping of symmetric-key key agreement error conditions to status codes........... 276 49
Table 150 APSME-TRANSPORT-KEY.request parameters.................................................... 279 50
Table 151 KeyType parameter of the transport-key primitive .................................................. 279 51
Table 152 TransportKeyData parameter for a trust-center master key.................................... 279 52
Table 153 TransportKeyData parameter for a Network key..................................................... 280 53
Table 154 TransportKeyData parameter for an application master or link key ........................ 280 54

1 Table 155 APSME-TRANSPORT-KEY.indication parameters................................................. 281

2 Table 156 TransportKeyData parameter for a trust-center master key.................................... 282
3 Table 157 TransportKeyData parameter for a Network key..................................................... 282
4 Table 158 APSME-UPDATE-DEVICE.request parameters ..................................................... 284
5 Table 159 APSME-UPDATE-DEVICE.indication parameters .................................................. 285
6 Table 160 APSME- REMOVE-DEVICE.request parameters ................................................... 286
7 Table 161 APSME-REMOVE-DEVICE.indication parameters ................................................. 287
8 Table 162 APSME-REQUEST-KEY.request parameters......................................................... 287
9 Table 163 APSME-REQUEST-KEY.indication parameters ..................................................... 288
10 Table 164 APSME-SWITCH-KEY.request parameters............................................................ 289
11 Table 165 APSME-SWITCH-KEY.indication parameters......................................................... 290
12 Table 166 Command identifier values...................................................................................... 291
13 Table 167 AIB security attributes ............................................................................................. 296
14 Table 168 Elements of the key-pair descriptor......................................................................... 297
15 Table 169 Security levels available to the MAC, NWK, and APS layers.................................. 298
16 Table 170 Encoding for the key identifier sub-field .................................................................. 299
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
46
47
48
49
50
51
52
53
54

Preface 1
2
3
4
5
The ZigBee Alliance is developing a very low-cost, very low power consumption, two-way, wireless 6
communications standard. Solutions adopting the ZigBee standard will be embedded in consumer 7
electronics, home and building automation, industrial controls, PC peripherals, medical sensor applications, 8
toys and games. 9
10
11
Scope 12
13
This document contains specifications, interface descriptions, object descriptions, protocols and algorithms 14
pertaining to the ZigBee protocol standard, including the application support sub-layer (APS), the ZigBee 15
device objects (ZDO), ZigBee device profile (ZDP), the application framework, the network layer (NWK) 16
and ZigBee security services. 17
18
Purpose 19
20
The purpose of this document is to provide a definitive description of the ZigBee protocol standard as a basis 21
for future implementations, such that any number of implementers incorporating the ZigBee standard into 22
platforms and devices on the basis of this document will produce interoperable, low-cost and highly usable 23
products for the burgeoning wireless marketplace. 24
25
26
Stack architecture 27
28
The ZigBee stack architecture is made up of a set of blocks called layers. Each layer performs a specific set 29
of services for the layer above: a data entity provides a data transmission service and a management entity 30
provides all other services. Each service entity exposes an interface to the upper layer through a service 31
access point (SAP), and each SAP supports a number of service primitives to achieve the required 32
functionality. 33
34
The ZigBee stack architecture, which is depicted in Figure 1, is based on the standard Open Systems
35
Interconnection (OSI) seven-layer model (see [B14]) but defines only those layers relevant to achieving
36
functionality in the intended market space. The IEEE 802.15.4-2003 standard defines the lower two layers:
37
the physical (PHY) layer and the medium access control (MAC) sub-layer. The ZigBee Alliance builds on
38
this foundation by providing the network (NWK) layer and the framework for the application layer, which
39
includes the application support sub-layer (APS), the ZigBee device objects (ZDO) and the manufacturer-
40
defined application objects.
41
IEEE 802.15.4-2003 has two PHY layers that operate in two separate frequency ranges: 868/915 MHz and 42
2.4 GHz. The lower frequency PHY layer covers both the 868 MHz European band and the 915 MHz band 43
that is used in countries such as the United States and Australia. The higher frequency PHY layer is used 44
virtually worldwide. A complete description of the IEEE 802.15.4-2003 PHY layer can be found in [B1]. 45
46
The IEEE 802.15.4-2003 MAC sub-layer controls access to the radio channel using a CSMA-CA 47
mechanism. Its responsibilities may also include transmitting beacon frames, synchronization and providing 48
a reliable transmission mechanism. A complete description of the IEEE 802.15.4-2003 MAC sub-layer can 49
be found in [B1]. 50
51
The responsibilities of the ZigBee NWK layer shall include mechanisms used to join and leave a network, to 52
apply security to frames and to route frames to their intended destinations. In addition, the discovery and 53
maintenance of routes between devices devolve to the NWK layer. Also the discovery of one-hop neighbors 54

1 and the storing of pertinent neighbor information are done at the NWK layer. The NWK layer of a ZigBee
2 coordinator (see "Network topology") is responsible for starting a new network, when appropriate, and
3 assigning addresses to newly associated devices
4
5 The ZigBee application layer consists of the APS, the Application Framework (AF), the ZDO and the
6 manufacturer-defined application objects. The responsibilities of the APS sub-layer include maintaining
7 tables for binding, which is the ability to match two devices together based on their services and their needs,
8 and forwarding messages between bound devices. The responsibilities of the ZDO include defining the role
9 of the device within the network (e.g., ZigBee coordinator or end device), initiating and/or responding to
10 binding requests and establishing a secure relationship between network devices. The ZDO is also
11 responsible for discovering devices on the network and determining which application services they provide.
12
13
14
Application (APL) Layer
15 Application Framework
16
17
ZigBee Device Object
18
ZDO Public
Application (ZDO)
Interfaces
Application
19 Object 240
20
21
… Object 1
Endpoint 240 Endpoint 1 Endpoint 0

22 APSDE-SAP APSDE-SAP APSDE-SAP
ZDO Management Plane

23
APSME-SAP
Application Support Sublayer (APS)
24 ASL
APS Security APS Message Reflector
25 Security Management Broker Management
26 Service NLDE-SAP -
27 Provider Network (NWK) Layer
NLME-SAP
IEEE 802.15.4
28 defined
NWK Security NWK Message Routing Network
Management Broker Management Management
29
ZigBeeTM Alliance
30 defined MLDE-SAP MLME-SAP
31 Medium Access Control (MAC) Layer
End manufacturer
32 defined
33 Layer
PD-SAP PLME-SAP
34 Physical (PHY) Layer

function
35 2.4 GHz Radio 868/915 MHz
Layer di
36 interface
37
38
39 Figure 1 Outline ZigBee stack architecture
40
41 Network topology
42
43 The ZigBee network layer (NWK) supports star, tree and mesh topologies. In a star topology, the network is
44 controlled by one single device called the ZigBee coordinator. The ZigBee coordinator is responsible for
45 initiating and maintaining the devices on the network, and all other devices, known as end devices, directly
46 communicate with the ZigBee coordinator. In mesh and tree topologies, the ZigBee coordinator is
47 responsible for starting the network and for choosing certain key network parameters but the network may
48 be extended through the use of ZigBee routers. In tree networks, routers move data and control messages
49 through the network using a hierarchical routing strategy. Tree networks may employ beacon-oriented
50 communication as described in the IEEE 802.15.4-2003 specification. Mesh networks shall allow full peer-
51 to-peer communication. ZigBee routers in mesh networks shall not emit regular IEEE 802.15.4-2003
52 beacons.
53
54

Preface
This specification describes only intra-PAN networks, i.e., networks in which communications begin and 1
terminate within the same network. 2
3
4
Definitions, Abbreviations, and References 5
6
7
Conformance Levels 8
9
The conformance level definitions shall follow those in Clause 13, section 1 of the IEEE Style Manual 10
[B12]. 11
12
Expected: A key word used to describe the behavior of the hardware or software in the design models 13
assumed by this Specification. Other hardware and software design models may also be implemented. 14
May: A key word indicating a course of action permissible within the limits of the standard (may equals is 15
permitted). 16
17
Shall: A key word indicating mandatory requirements strictly to be followed in order to conform to the 18
standard and from which no deviation is permitted (shall equals is required to). 19
20
Should: A key word indicating that among several possibilities one is recommended as particularly suitable, 21
without mentioning or excluding others; or that a certain course of action is preferred but not necessarily 22
required; or that (in the negative form) a certain course of action is deprecated but not prohibited (should 23
equals is recommended that). 24
25
Reserved Codes: A set of codes that are defined in this specification, but not otherwise used. Future 26
specifications may implement the use of these codes. A product implementing this specification shall not 27
generate these codes. 28
Reserved Fields: A set fields that are defined in this specification, but are not otherwise used. Products that 29
implement this specification shall zero these fields and shall make no further assumptions about these fields 30
nor perform processing based on their content. Products that implement future revisions of this specification 31
may set these fields as defined by the specification. 32
33
ZigBee v1.0: The version of the ZigBee protocols governed by this specification. ZigBee v1.0 is the first 34
officially recognized version of these protocols. The protocol version sub-field of the frame control field in 35
the NWK header of all ZigBee v1.0 frames shall have a value of 0x01. Frames defined in later versions of 36
the specification may set the protocol version sub-field of the frame control field to a different value. A 37
ZigBee device that conforms to this specification shall discard all frames that carry a protocol version sub- 38
field value other than 0x01.1 39
40
Strings and string operations 41
42
43
A string is a sequence of symbols over a specific set (e.g., the binary alphabet {0,1} or the set of all octets). 44
The length of a string is the number of symbols it contains (over the same alphabet). The right-concatenation 45
of two strings x and y of length m and n respectively (notation: x || y), is the string z of length m+n that 46
coincides with x on its leftmost m symbols and with y on its rightmost n symbols. An octet is a symbol string 47
of length 8. In our context, all octets are strings over the binary alphabet. 48
49
50
51
52
53
1
CCB Comment 263 54

1 Transmission order
2
3 By convention, frame structures are presented such that the leftmost field as written in this document shall
4 be transmitted or received first. All multiple octet fields shall be transmitted or received least significant
5 octet first. Each individual octet shall be transmitted or received least significant bit first.
6
7
8 Integers, octets, and their representation
9
10 Throughout this specification, the representation of integers as octet strings and of octet strings as binary
11 strings shall be fixed. All integers shall be represented as octet strings in most-significant-octet first order.
12 This representation conforms to the convention in Section 4.3 of ANSI X9.63-2001 [B7]. All octets shall be
13 represented as binary strings in most-significant-bit first order.
14
15 Entities
16
17 Throughout this specification, each entity shall be a DEV and shall be uniquely identified by its 64-bit IEEE
18 device address [B1]. The parameter entlen shall have the integer value 64.
19
20
21 Definitions
22
23 For the purposes of this standard, the following terms and definitions apply. Terms not defined in this clause
24 can be found in IEEE P802.15.4 §3 [B1] or in ANSI X9.63-2001 §2.1 [B7].
25
26 Access control list: a table used by a device to determine which devices are authorized to perform a specific
27 function. This table may also store the security material (e.g., cryptographic keys, frame counts, key counts,
28 security level information) used for securely communicating with other devices.
29 Active network key: the key used by a ZigBee device to secure outgoing NWK frames and that is available
30 for use to process incoming NWK frames.
31
32 Alternate network key: a key available for use in lieu of the active Network key to process incoming NWK
33 frames.
34
35 Application domain: this describes a broad area of applications, such as building automation.
36 Application object: a component of the top portion of the application layer defined by the manufacturer that
37 actually implements the application.
38
39 Application segment: some application domains are split into application segments, for instance the light-
40 ing application segment within the home control application domain.
41 Application support sub-layer protocol data unit: a unit of data that is exchanged between the application
42 support sub-layers of two peer entities.
43
44 APS command frame: an APS frame that contains neither source nor endpoints.
45
46 Association: the service provided by the IEEE 802.15.4-2003 MAC sub-layer that is used to establish
47 membership in a network.
48
49 Attribute: a data entity which represents a physical quantity or state. This data is communicated to other
50 devices using commands.
51 Beacon-enabled personal area network: a personal area network containing at least one device that trans-
52 mits beacon frames at a regular interval.
53
54

Preface
Binding: the creation of a unidirectional logical link between a source endpoint/cluster identifier pair and a 1
destination endpoint, which may exist on one or more devices.2 2
3
Broadcast: the transmission of a message to every device within a network. 4
5
Broadcast jitter: random delay time introduced by a device before relaying a broadcast transaction.
6
Broadcast transaction record: a local receipt of a broadcast message that was either initiated or relayed by 7
a device. 8
9
Broadcast transaction table: collection of broadcast transaction records.
10
Cluster: is a container for one or more attributes under the KVP service type and is synonymous with “mes- 11
sage” under the MSG service type. 12
13
Cluster identifier: a reference to the unique enumeration of clusters within a specific profile. The cluster
14
identifier is an 8-bit number unique within the scope of the application domain segment and identifies a spe-
15
cific cluster. Cluster identifiers are identified as inputs or outputs in the simple descriptor for use in creating
16
a binding table.
17
Component: a component consists of a physical object (e.g., switch, controller, etc.) and its corresponding 18
application profile(s). 19
20
Coordinator: an IEEE 802.15.4-2003 device responsible for associating and disassociating devices into its 21
PAN. A coordinator must be a full function device (FFD). 22
23
Data integrity: assurance that the data has not been modified from its original form.
24
Data key: a key shared between two devices for peer-to-peer data communications. 25
26
Device: any entity that contains an implementation of the ZigBee protocol stack. 27
28
Device application: a special application that is responsible for Device operation. The Device Application 29
resides on Endpoint 0 by convention and contains logic to manage the Devices networking and general 30
maintenance features. 31
32
Device description: a description of a specific device within an application segment and/or domain. For
33
instance, the light sensor monochromatic device description is a member of the lighting application segment.
34
The device description also has a unique identifier that is exchanged as part of the discovery process.
35
Direct addressing: a mode of addressing in which the destination of a frame is completely specified in the 36
frame itself. 37
38
Direct binding: the procedure through which the uppers layers of a device which maintains a binding table 39
in the APS can create or remove a binding link in that binding table. 40
41
Direct transmission: frame transmission using direct addressing. 42
43
Disassociation: the service provided by the IEEE 802.15.4-2003 MAC sub-layer that is used to discontinue
44
the membership of a device in a network.
45
End application: applications that reside on Endpoints 1 through 240 on a Device. The End Applications 46
implement features that are non-networking and ZigBee protocol related. 47
48
End device binding: the procedure for creating or removing a binding link initiated by each of the end 49
devices that will form the link. The procedure may or may not involve user intervention. 50
51
52
53
2
CCB Comment #127 54

Preface
Endpoint: a particular component within a unit. Each ZigBee device may support up to 240 such compo- 1
nents. 2
3
Endpoint address: the address assigned to an endpoint. This address is assigned in addition to the unique,
4
64-bit IEEE address and 16-bit network address.
5
First hop indirect frame: a period in the transit of a frame that has been indirectly addressed when only the 6
source address appears in the frame. 7
8
Indirect addressing: the ability for resource limited devices to communicate without having to know the
9
address of the desired destination. Indirect transmissions shall include only the source endpoint-addressing
10
field along with the Indirect Addressing bit set in the APDU and are directed to the ZigBee Coordinator by
11
the source. The ZigBee Coordinator is expected to lookup the source address/endpoint/cluster ID within its
12
binding table and re-issues the message to each corresponding destination address/endpoint.
13
Information base: a collection of variables that define certain behavior in a layer. These variables can be 14
specified or obtained from a layer through its management service. 15
16
Key establishment: A mechanism that involves the execution of a protocol by two devices to derive a 17
mutually shared secret key. 18
19
Key transport: A mechanism for communicating a key from one device to another device or other devices.
20
Key-transport key: A key used to protect key transport messages. 21
22
Key update: A mechanism implementing the replacement of a key shared amongst two or more devices by 23
means of another key available to that same group. 24
25
Local coordinator: A ZigBee Coordinator or ZigBee Router, which is the IEEE 802.15.4 coordinator, 26
which processed the association request for a specific End Device. 27
28
Link key: A key that is shared between two devices within a PAN.
29
Master key: A shared key used during the execution of a symmetric-key key establishment protocol. The 30
master key is the basis for long-term security between the two devices, and may be used to generate link 31
keys. 32
33
Mesh network: a network in which the routing of messages is performed as a decentralized, cooperative 34
process involving many peer devices routing on each others’ behalf. 35
36
Multihop network: a network, in particular a wireless network, in which there is no guarantee that the
37
transmitter and the receiver of a given message are connected or linked to each other. This implies that inter-
38
mediate devices must be used as routers.
39
Non-beacon-enabled personal area network: a personal area network that does not contain any devices 40
that transmit beacon frames at a regular interval. 41
42
Neighbor table: a table used by a ZigBee device to keep track of other devices within the POS.
43
Network address: the address assigned to a device by the network layer and used by the network layer for 44
routing messages between devices. 45
46
Network broadcast delivery time: time duration required by a broadcast transaction to reach every device
47
of a given network.
48
Network protocol data unit: a unit of data that is exchanged between the network layers of two peer enti- 49
ties. 50
51
Network service data unit: Information that is delivered as a unit through a network service access point.
52
Node: a collection of independent device descriptions and applications residing in a single unit and sharing a 53
common 802.15.4 radio. 54

Preface
Normal operating state: processing which occurs after all startup and initialization processing has occurred 1
and prior to initiation of shutdown processing. 2
3
NULL: A parameter or variable value that mean unspecified, undefined or unknown.
4
Octet: eight bits of data, used as a synonym for a byte. 5
6
One-way function: A function that is computationally much easier to perform than its inverse. 7
8
Orphaned device: a device that has lost communication contact with or information about the ZigBee 9
device through which it has its PAN membership. 10
11
PAN coordinator: The principal controller of an IEEE 802.15.4-2003-based network that is responsible for
12
network formation and maintenance. The PAN coordinator must be a full function device (FFD).
13
PAN information base: A collection of variables in the IEEE 802.15.4-2003 standard that are passed 14
between layers, in order to exchange information. This database may include the access control list, which 15
stores the security material. 16
17
Personal operating space: the area within reception range of a single device. 18
19
Private method: attributes which are accessible to ZigBee device objects only and unavailable to the end
20
applications.
21
Profile: a collection of device descriptions, which together form a cooperative application. For instance, a 22
thermostat on one node communicates with a furnace on another node. Together, they cooperatively form a 23
heating application profile. 24
25
Protocol data unit: the unit of data that is exchanged between two peer entities.
26
Proxy binding: the procedure through which a device can create or remove a binding link on the ZigBee 27
coordinator between two devices (none of which may be the device itself). 28
29
Public method: attributes which are accessible to End Applications.
30
Radio: the IEEE 802.15.4-2003 radio that is part of every ZigBee device. 31
32
Route discovery: an operation in which a ZigBee coordinator or ZigBee router attempts to discover a route
33
to a remote device by issuing a route request command frame.3
34
Route discovery table: a table used by a ZigBee coordinator or ZigBee router to store temporary informa- 35
tion used during route discovery. 36
37
Route reply: a ZigBee network layer command frame used to reply to route requests.
38
Route request: a ZigBee network layer command frame used to discover paths through the network over 39
which subsequent messages may be delivered. 40
41
Routing table: a table in which a ZigBee coordinator or ZigBee router stores information required to partic-
42
ipate in the routing of frames.
43
Service discovery: the ability of a device to locate services of interest. 44
45
Symmetric-key key establishment: a mechanism by which two parties establish a shared secret, based on a 46
pre-shared secret (a so-called master key). 47
48
Trust center: the device trusted by devices within a ZigBee network to distribute keys for the purpose of 49
network and end-to-end application configuration management. 50
51
Unicast: the transmission of a message to a single device in a network.
52
53
3
CCB Comment #126 54

1 Unit: a component or collection of components that share a single ZigBee radio. Each unit has a unique 64-
2 bit IEEE address and a 16-bit network address.
3
ZigBee coordinator: an IEEE 802.15.4-2003 PAN coordinator.
4
5 ZigBee device object: the portion of the application layer responsible for defining the role of the device
6 within the network (e.g., ZigBee coordinator or end device), initiating and/or responding to binding and dis-
7 covery requests and establishing a secure relationship between network devices.
8
ZigBee end device: an IEEE 802.15.4-2003 RFD or FFD participating in a ZigBee network, which is nei-
9
ther the ZigBee coordinator nor a ZigBee router.
10
11 ZigBee router: an IEEE 802.15.4-2003 FFD participating in a ZigBee network, which is not the ZigBee
12 coordinator but may act as an IEEE 802.15.4-2003 coordinator within its personal operating space, that is
13 capable of routing messages between devices and supporting associations.
14
15
16
Acronyms and Abbreviations
17
18 For the purposes of this standard, the following acronyms and abbreviations apply.
19
20 AIB Application support layer information base
21 AF Application framework
22
23 APDU Application support sub-layer protocol data unit
24
APL Application layer
25
26 APS Application support sub-layer
27
APSDE Application support sub-layer data entity
28
29 APSDE-SAP Application support sub-layer data entity – service access point
30
31 APSME Application support sub-layer management entity - service access point
32 APSME-SAP Application support sub-layer management entity – service access point
33
34 BRT Broadcast retry timer
35
BTR Broadcast transaction record
36
37 BTT Broadcast transaction table
38
39 CCM* Enhanced counter with CBC-MAC mode of operation
40 CSMA-CA Carrier sense multiple access – collision avoidance
41
42 FFD Full function device
43
GTS Guaranteed time slot
44
45 IB Information base
46
KVP Key-value pair
47
48 LQI Link quality indicator
49
50 LR-WPAN Low rate wireless personal area network
51 MAC Medium access control
52
53 MCPS-SAP Medium access control common part sub-layer – service access point
54

Preface
MIC Message integrity code 1

2
MLME-SAP Medium access control sub-layer management entity – service access point 3
4
MSC Message sequence chart
5
MSDU Medium access control sub-layer service data unit 6
7
MSG Message service type 8
NBDT Network broadcast delivery time 9
10
NHLE Next Higher Layer Entity 11
12
NIB Network layer information base
13
NLDE Network layer data entity 14
15
NLDE-SAP Network layer data entity – service access point
16
NLME Network layer management entity 17
18
NLME-SAP Network layer management entity – service access point 19
NPDU Network layer protocol data unit 20
21
NSDU Network service data unit 22
23
NWK Network
24
OSI Open systems interconnection 25
26
PAN Personal area network 27
PD-SAP Physical layer data – service access point 28
29
PDU Protocol data unit 30
31
PHY Physical layer
32
PIB Personal area network information base 33
34
PLME-SAP Physical layer management entity – service access point
35
POS Personal operating space 36
37
QoS Quality of service 38
RC Radius counter 39
40
RFD Reduced function device 41
42
RREP Route reply
43
RREQ Route request 44
45
RN Routing node 46
SAP Service access point 47
48
SKG Secret key generation 49
50
SKKE Symmetric-key key establishment
51
SSP Security services provider 52
53
SSS Security services specification
54

Preface
WPAN Wireless personal area network 1

2
XML Extensible markup language 3
4
ZB ZigBee
5
ZDO ZigBee device object 6
7
8
Symbols and Notation 9
10
Notation follows from ANSI X9.63-2001, §2.2 [B7] 11
12
13
References
14
15
The following standards contain provisions, which, through reference in this document, constitute 16
provisions of this standard. Normative references are given in "ZigBee/IEEE References" and "Normative 17
References" and informative references are given in "Informative References". At the time of publication, 18
the editions indicated were valid. All standards are subject to revision, and parties to agreements based on 19
this standard are encouraged to investigate the possibility of applying the most recent editions of the 20
standards indicated below. 21
22
ZigBee/IEEE References 23
[B1] Institute of Electrical and Electronics Engineers, Inc., IEEE Std. 802.15.4-2003, IEEE Standard for 24
Information Technology — Telecommunications and Information Exchange between Systems — Local and 25
Metropolitan Area Networks — Specific Requirements — Part 15.4: Wireless Medium Access Control 26
(MAC) and Physical Layer (PHY) Specifications for Low Rate Wireless Personal Area Networks (WPANs). 27
New York: IEEE Press. 2003. 28
29
[B2] IEEE 754-1985, IEEE Standard for Binary Floating-Point Arithmetic, IEEE, 1985. 30
[B3] Document 03285r0: Suggestions for the Improvement of the IEEE 802.15.4 Standard, July 2003. 31
32
[B4] Document 02055r4: Network Requirements Definition, August 2003. 33
34
Normative References 35
[B5] ISO/IEC 639-1:2002 Codes for the representation of names of languages - Part 1: Alpha-2 code. 36
37
[B6] ISO/IEC 646:199 Information technology -- ISO 7-bit coded character set for information interchange. 38
[B7] ANSI X9.63-2001, Public Key Cryptography for the Financial Services Industry - Key Agreement and 39
Key Transport Using Elliptic Curve Cryptography, American Bankers Association, November 20, 2001. 40
Available from http://www.ansi.org. 41
42
[B8] FIPS Pub 197, Advanced Encryption Standard (AES), Federal Information Processing Standards Publi- 43
cation 197, US Department of Commerce/N.I.S.T, Springfield, Virginia, November 26, 2001. Available 44
from http://csrc.nist.gov/. 45
[B9] FIPS Pub 198, The Keyed-Hash Message Authentication Code (HMAC), Federal Information Process- 46
ing Standards Publication 198, US Department of Commerce/N.I.S.T., Springfield, Virginia, March 6, 2002. 47
Available from http://csrc.nist.gov/. 48
49
[B10] ISO/IEC 9798-2, Information Technology - Security Techniques - Entity Authentication Mechanisms 50
- Part 2: Mechanisms Using Symmetric Encipherment Algorithms, International Standardization Organiza- 51
tion, Geneva, Switzerland, 1994 (first edition). Available from http://www.iso.org/. 52
53
54

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Chapter 1 Application Layer Specification 1
2
3
4
5
6
1.1 General description 7
8
The ZigBee stack architecture includes a number of layered components including the IEEE 802.15.4 2003 9
Medium Access Control (MAC) layer and Physical (PHY) layer and well as the ZigBee Network (NWK) 10
layer. Each of these provide applications with its own set of services and capabilities. The portion of the 11
stack covered by this document is roughly that labeled Application (APL) Layer in Figure 1. 12
13
As shown, the ZigBee application layer consists of the APS sub-layer, the ZDO (containing the ZDO 14
management plane), and the manufacturer-defined application objects. The responsibilities of the APS sub- 15
layer include maintaining tables for binding, which is the ability to match two devices together based on 16
their services and their needs, and forwarding messages between bound devices. The responsibilities of the 17
ZDO include defining the role of the device within the network (e.g., ZigBee coordinator or end device), 18
discovering devices on the network and determining which application services they provide, initiating and/ 19
or responding to binding requests and establishing a secure relationship between network devices. 20
21
1.1.1 Application support sub-layer 22
23
The application support sub-layer (APS) provides an interface between the network layer (NWK) and the 24
application layer (APL) through a general set of services that are used by both the ZDO and the 25
manufacturer-defined application objects. The services are provided by two entities: the APS data entity 26
(APSDE) through the APSDE service access point (APSDE-SAP) and the APS management entity 27
(APSME) through the APSME service access point (APSME-SAP). The APSDE provides the data 28
transmission service for the transport of application PDUs between two or more devices located on the same 29
network. The APSME provides services for discovery and binding of devices and maintains a database of 30
managed objects, known as the APS information base (AIB). 31
32
33
1.1.2 Application framework 34
35
The application framework in ZigBee is the environment in which application objects are hosted on ZigBee 36
devices. Inside the application framework, the application objects send and receive data through the 37
APSDE-SAP. Control and management of the application objects is performed through the ZDO public 38
interfaces (see clause 1.5). 39
The data service, provided by APSDE-SAP, includes request, confirm, response and indication primitives 40
for data transfer. The request primitive supports data transfers between peer application object entities. The 41
confirm primitive reports the results of a request primitive call. The indication primitive is used to indicate 42
the transfer of data from the APS to the destination application object entity. 43
44
Up to 240 distinct application objects can be defined, each interfacing on an endpoint indexed from 1 to 240. 45
Two additional endpoints are defined for APSDE-SAP usage: endpoint 0 is reserved for the data interface to 46
the ZDO and endpoint 255 is reserved for the data interface function to broadcast data to all application 47
objects. Endpoints 241-254 are reserved for future use.4 48
49
Using these services offered by the APSDE-SAP, the application framework provides an application object 50
two data services: a key value pair service and a generic message service. Each service will be discussed in 51
the following sub-clauses. 52
53
4
CCB Comment #227 54

1 1.1.2.1 Key value pair service

2
3 The key value pair (KVP) service allows attributes, defined in the application objects, to be manipulated by
4 employing a state variable approach with get, get response, set and event transactions. The latter two
5 transactions can be sent with a request for response, resulting in the corresponding set response and event
6 response transactions, respectively. Additionally, KVP uses tagged data structures using compressed XML.
7 Together, this solution provides an elegant command/control mechanism for small footprint devices with
8 extensibility to enable gateways to expand to full XML.
9
The KVP service frame structure is described in sub-clause 1.3.5.
10
11
1.1.2.2 Message service
12
13 Many application areas targeted by ZigBee are addressed by proprietary protocols that do not map well to
14 KVP. Additionally, some overhead is assumed in KVP since the state variable approach assumes support for
15 any of the get, set or event actions requiring devices to maintain storage for state variables.
16
17 To address these cases, the generic message (MSG) service is supported. The MSG service type is
18 transported via the same mechanisms used by KVP. The difference is that MSG does not assume any content
19 in the APS data frame leaving that field free form for the profile developer to define.
20
21 The MSG service frame structure is described in sub-clause 1.3.4.5.2.
22
23 1.1.3 Addressing
24
25
1.1.3.1 Node addressing
26
27 In Figure 2, there are two nodes, each containing a single radio. One node contains two switches and the
28 other contains 4 lamps.
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Application Layer Specification
1
2
3
4
5
Lamps 6
Radio
1 2 3 4 7
8
9
10
11
Radio 12
13
14
15
16
Switch 1 17
18
19
Switch 2 20
21
22
23
24
Figure 2 Multiple subunits in a single node 25
26
A node contains one or more device descriptions and has a single IEEE 802.15.4 radio. In Figure 2, the 27
individual parts of the nodes (the switches and lamps) are subunits containing one device description in each 28
subunit. Each node is given an address when it joins the ZigBee network. 29
30
1.1.3.2 Endpoint addressing 31
32
In Figure 2, it is required that switch 1 should control lamps 1, 2 and 3, while switch 2 should control only 33
lamp 4. However, as the only addressable component is the radio, it is not possible to identify or address the 34
individual subunits, so it would not be possible for switch 2 to turn on lamp 4 only. 35
36
ZigBee provides another level of sub-addressing, which is used in conjunction with the mechanisms of 37
IEEE802.15.4. An endpoint number can be used to identify individual switches and lamps. For instance, in 38
the example above, switch 1 could use endpoint 3, while switch 2 could use endpoint 21. Similarly, the 39
lamps will each have their own endpoints. Endpoint 0 is reserved for device management and is used to 40
address the descriptors in the node. Each identifiable subunit in a node (such as the switches and lamps) is 41
assigned its own specific endpoint in the range 1-240. 42
Physical devices are described in terms of the data attributes that they contain. For instance, a thermostat 43
might contain an output attribute “temperature” which represents the current temperature of a room. A 44
furnace controller may take this attribute as an input and control the furnace according to the temperature 45
value received from the thermostat. These two physical devices, including their attributes, would be 46
described in the relevant device descriptions for those devices. 47
48
The simple room thermostat described has temperature-sensing circuitry, which can be queried by the 49
external furnace controller. It advertises its service on an endpoint and the service is described in the simple 50
description implemented on that endpoint. 51
52
A more complex version of the thermostat may also have an optional “heartbeat” report timer, which causes 53
the device to report current room temperature after a set period. In this example, the ReportTime attribute 54

1 specifies when reports are to be sent and writing a suitable time value to this attribute sets the frequency of
2 these temperature reports. This implementation would advertise its services (in a list of cluster identifiers)
3 on a different endpoint.
4
5 In order to allow product differentiation in the marketplace, manufacturers may add clusters containing extra
6 attributes of their own in the context of one or more private profiles. These manufacturer-specific clusters do
7 not form part of this or any other ZigBee specification and interoperability is not guaranteed for these
8 clusters. Such services would be advertised on different endpoints from those described above.
9
10 1.1.4 Application communication fundamentals
11
12
1.1.4.1 Profiles
13
14 Profiles are an agreement on messages, message formats and processing actions that enable applications
15 residing on separate devices to send commands, request data and process commands/requests to create an
16 interoperable, distributed application. For instance, a thermostat on one node communicates with a furnace
17 on another node. Together, they cooperatively form a heating application profile. Profiles are developed by
18 ZigBee vendors to address solutions to specific technology needs.
19
20 Profiles are simultaneously a means to unify interoperable technical solutions within the ZigBee standard, as
21 well as to focus usability efforts within a given marketing area. For example, it is expected that vendors of
22 lighting equipment will want to provide ZigBee profiles that interoperate with several varieties of lighting
23 types or controller types. Additional information on profiles is provided in clause 1.2 of this document.
24
25 1.1.4.2 Clusters
26
27 Clusters are identified by a cluster identifier, which is associated with data flowing out of, or into, the
28 device. Cluster identifiers are unique within the scope of a particular profile. Binding decisions are taken by
29 matching an output cluster identifier to an input cluster identifier, assuming both are within the same profile.
30 In the thermostat example above, binding takes place on temperature, between a device with a temperature
31 cluster identifier as output and a device with a temperature cluster identifier as input. The binding table
32 contains the 8-bit identifier for temperature along with the address of the source and destination devices.
33
34 1.1.5 Discovery
35
36 1.1.5.1 Device discovery
37
38 Device discovery is the process whereby a ZigBee device can discover other ZigBee devices by initiating
39 queries that are broadcast or unicast addressed. There are two forms of device discovery requests: IEEE
40 address requests and NWK address requests. The IEEE address request is unicast and assumes the NWK
41 address is known. The NWK address request is broadcast and carries the known IEEE address as data
42 payload.
43
44 Responses to the broadcast or unicast device discovery messages vary by logical device type as follows:
45
46 — ZigBee end devices: respond to the device discovery query by sending their IEEE or NWK address
47 (depending on the request).
48 — ZigBee coordinator device: respond to the query by sending their IEEE or NWK addresses and the
49 IEEE or NWK addresses of all devices that are associated with the ZigBee coordinator (depending
50 on the request).
51
52 — ZigBee router devices: respond to the query by sending their IEEE or NWK addresses and the IEEE
53 or NWK addresses of all devices that are associated with the ZigBee router (depending on the
54 request).

A description of the procedure details, primitive calls, and applicable parameters is given in clause 1.4. 1
2
1.1.5.2 Service discovery 3
4
Service discovery is the process whereby services available on endpoints at the receiving device are 5
discovered by external devices. Service discovery can be accomplished by issuing a query for each endpoint 6
on a given device or by using a match service feature (either broadcast or unicast). Service discovery utilizes 7
the complex, user, node or power descriptors plus the simple descriptor further addressed by the endpoint 8
(for the connected application object). 9
10
The service discovery process in ZigBee is key to interfacing devices within the network. Through specific
11
requests for descriptors on specified nodes, broadcast requests for service matching and the ability to ask a
12
device which endpoints support application objects, a range of options are available for commissioning tools
13
and applications. See clause 1.4 for details on service discovery.
14
15
1.1.6 Binding 16
17
In ZigBee, there is an application level concept using cluster identifiers (and the attributes contained in 18
them) on the individual endpoints in different nodes. This is referred to as binding – the creation of logical 19
links between complementary application devices and endpoints. In the example of sub-clause 1.1.3.2, a 20
binding could be made between thermostat and the furnace controller. In Figure 2, switch 1 is bound with 21
lamps 1-3, while switch 2 is bound with lamp 4 only. 22
23
The information about which cluster is bound between nodes is stored in a binding table. This is described 24
fully in sub-clause 1.1.6 and is illustrated in Figure 3. 25
26
27
28
Radio Lamps 29
Z2 1 2 3 4 30
EP5 EP7 EP8 EP17 31
32
33
34
35
36
Radio 37
Z1 38
39
Binding Table 40
Switch 1 41
EP3 42
43
Switch 2 44
EP21 45
46
47
48
Figure 3 ZigBee binding and binding table 49
50
The use of a list of three entries in the binding table for switch 1 allows it to control three lamps, which could 51
also be in separate nodes (with their own ZigBee radios). It is also possible for one lamp to be controlled by 52
several switches: in this case there would be entries for each switch, all linked to the same lamp. 53
54

1 Binding is always performed after a communications link has been established. Once a link has been
2 established, the implementation decides whether a new node should be part of the network. This will depend
3 on the security in operation for the application and how it is implemented. Binding is only allowed if the
4 implemented security on all devices allows this (see Chapter 3).
5
6 The binding table is implemented in the ZigBee coordinator. This is because it needs to be available all the
7 time the network is operative and it is most probable that the ZigBee coordinator has a mains supply. Some
8 applications may need a duplicate of the binding table to be available in the event that the device storing the
9 table fails. Backup of the binding table and any other key ZigBee coordinator data is outside the scope of
10 ZigBee version 1.0 and the responsibility of application software.
11
The details of the creation of binding links is covered in the ZigBee device profile (see clause 1.4).
12
13
14 1.1.7 Messaging
15
16 1.1.7.1 Direct addressing
17
18 Once devices have been associated, commands can be sent from one device to another. A command is sent
19 to an application object at the destination address (radio address plus its endpoint). Details of the commands
20 can be found in sub-clause 1.3.5. Note that binding is not a pre-requisite for using direct addressing.
21
22 Direct addressing assumes device discovery and service discovery have identified a particular device and
23 endpoint, which supply a complementary service to the requestor. Specifically, direct addressing defines a
24 means of directing messages to the device by including its full address and endpoint information.
25
26 1.1.7.2 Indirect addressing
27
Use of direct addressing requires the controlling device to have knowledge of the address, endpoint, cluster
28
identifier and attribute identifier of the target device that it wishes to communicate with and to have this
29
information committed to a binding table on the ZigBee coordinator prior to the creation of an indirectly
30
addressed message between the device pair. A full IEEE 802.15.4 address amounts to 10 octets (PAN
31
identifier plus 64-bit IEEE address) and a further octet is required for the endpoint. Extremely simple
32
devices, such as battery-powered switches, may not want the overhead of storing this information, nor the
33
software for acquiring this information. For these devices, indirect addressing will be more appropriate.
34
35 When a source device wishes to send a command to a destination using indirect addressing, instead of
36 including the address of the destination device (which it does not know and has not stored), it omits the
37 address and specifies indirect addressing via the APSDE-SAP. The included source address, source endpoint
38 and cluster identifier in the indirect addressed message are translated via the binding table to those of the
39 destination device(s) and the messages are relayed to each indicated destination.5
40
41 Where a cluster contains several attributes, the cluster identifier is used for addressing and the attribute
42 identifier is used in the command itself to identify a particular attribute within the cluster. For further
43 information, see sub-clause 1.3.4.5.1. Attributes are not used in the indirect addressing mechanism and are
44 treated as a part of the data payload. The applications, however, can parse and utilize the attributes as
45 defined within their profile.
46
47 1.1.7.3 Broadcast addressing
48
49 An application may broadcast messages to all endpoints on a given destination device. This form of
50 broadcast addressing is called application broadcast. The destination address shall be the 16-bit network
51 broadcast address and the broadcast flag shall be set in the APS frame control field. The source shall include
52 the cluster identifier, profile identifier and source endpoint fields in the APS frame (see sub-clause 1.2.5).
53
5
54 CCB Comment #171, 214

1.1.8 ZigBee device objects 1

2
The ZigBee device objects (ZDO), represents a base class of functionality that provides an interface between 3
the application objects, the device profile and the APS. The ZDO is located between the application 4
framework and the application support sub-layer. It satisfies common requirements of all applications 5
operating in a ZigBee protocol stack. The ZDO is responsible for the following: 6
7
— Initializing the application support sub-layer (APS), the network layer (NWK), the security services 8
specification (SSS). 9
— Assembling configuration information from the end applications to determine and implement dis- 10
covery, security management, network management, and binding management. 11
12
The ZDO presents public interfaces to the application objects in the application framework layer for control 13
of device and network functions by the application objects. The ZDO interfaces to the lower portions of the 14
ZigBee protocol stack, on endpoint 0, through the APSDE-SAP for data and through the APSME-SAP for 15
control messages. The public interface provides address management of the device, discovery, binding, and 16
security functions within the application framework layer of the ZigBee protocol stack. These services are 17
described in the following sub-clauses. The ZDO is fully described in clause 1.5. 18
19
1.1.8.1 Discovery management 20
21
Discovery management is provided to the application objects whereby, when queried, the IEEE address of 22
the requested device shall be returned (if the device is a ZigBee end device), along with the device addresses 23
of all associated devices (if the device is a ZigBee coordinator or router). This is referred to as device 24
discovery, and is used for the discovery of ZigBee devices. 25
26
In addition to device discovery, service discovery is also provided to determine what services are offered on
27
each endpoint, defined in a device, by the respective application objects. A device can discover active
28
endpoints on individual devices or all devices and a device can discover specific services that match a given
29
criteria (profile identifiers and cluster identifiers).
30
31
1.1.8.2 Binding management
32
Binding management is provided to the application objects in order to bind application objects on ZigBee 33
devices to each other for clear and concise connections through all layers of the protocol stack and though 34
the various connections provided by the ZigBee network nodes. Binding tables are constructed and 35
populated according to the binding calls and results. End device bind, bind and unbind commands between 36
devices is supported via the ZigBee device profile. 37
38
1.1.8.3 Security management 39
40
Security management is provided to the application objects for enabling or disabling the security portion of 41
the system. If enabled, key management is performed for master keys, network keys, and the means to 42
establish a link key. Primitives are defined in Chapter 3 to permit key establishment, key transport and 43
authentication. 44
45
46
1.2 The ZigBee application support (APS) sub-layer 47
48
49
1.2.1 Scope 50
51
This clause specifies the portion of the application layer providing the service specification and interface to 52
both the manufacturer-defined application objects and the ZigBee device objects. The specification includes 53
54

1 a data service and methods for discovery and binding, as well as a description of the application support sub-
2 layer frame format and frame type specifications.
3
4
5 1.2.2 Purpose
6
The purpose of this clause is to define the set of requirements for the ZigBee application support (APS) sub-
7
layer protocol. These requirements are based on both the driver functionality necessary to enable correct
8
operation of the ZigBee network layer and the functionality required by the manufacturer-defined
9
application objects. This specification shall provide a solution for all the requirements defined in the ZigBee
10
Network Working Group Requirements Definition document [B4] including a fully specified primitive
11
interface.
12
13
14 1.2.3 Application support (APS) sub-layer overview
15
16 The application support sub-layer provides the interface between the network layer and the application layer
17 through a general set of services for use by both the ZigBee device object (ZDO) and the manufacturer-
18 defined application objects. These services are offered via two entities: the data service and the management
19 service. The APS data entity (APSDE) provides the data transmission service via its associated SAP, the
20 APSDE-SAP. The APS management entity (APSME) provides the management service via its associated
21 SAP, the APSME-SAP, and maintains a database of managed objects known as the APS information base
22 (AIB).
23
24 1.2.3.1 Application support sub-layer data entity (APSDE)
25
26 The APSDE shall provide a data service to the network layer and both the ZDO and the application objects
27 to enable the transport of application PDUs between two or more devices. The devices themselves must be
28 located on the same network.
29 The APSDE will provide the following services:
30
31 — Generation of the Application level PDU (APDU). The APSDE shall take an application PDU and
32 generate an APS PDU by adding the appropriate protocol overhead.
33
34 — Binding. This is the ability to match two devices together based on their services and their needs.
35 Once two devices are bound, the APSDE shall be able to transfer a message received from one
36 bound device over to the second device.
37
38 1.2.3.2 Application support sub-layer management entity (APSME)
39 The APSME shall provide a management service to allow an application to interact with the stack.
40
41 The APSME shall provide the ability to match two devices together based on their services and their needs.
42 This service is called the binding service and the APSME shall be able to construct and maintain a table to
43 store this information.
44
45 In addition, the APSME will provide the following services:
46
47 — AIB Management. The ability to get and set attributes in the device’s AIB.
48 — Security. The ability to set up authentic relationships with other devices through the use of secure
49 keys.
50
51
52
53
54

1.2.4 Service specification 1

2
The APS sub-layer provides an interface between a next higher layer entity (NHLE) and the NWK layer. 3
The APS sub-layer conceptually includes a management entity called the APS sub-layer management entity 4
(APSME). This entity provides the service interfaces through which sub-layer management functions may 5
be invoked. The APSME is also responsible for maintaining a database of managed objects pertaining to the 6
APS sub-layer. This database is referred to as the APS sub-layer information base (AIB). 7
8
Figure 4 depicts the components and interfaces of the APS sub-layer. 9
10
The APS sub-layer provides two services, accessed through two service access points (SAPs). These are the
11
APS data service, accessed through the APS sub-layer data entity SAP (APSDE-SAP), and the APS
12
management service, accessed though the APS sub-layer management entity SAP (APSME-SAP). These
13
two services provide the interface between the NHLE and the NWK layer, via the NLDE-SAP and NLME-
14
SAP interfaces (see clause 2.3). In addition to these external interfaces, there is also an implicit interface
15
between the APSME and the APSDE that allows the APSME to use the APS data service.
16
17
18
Next Higher Layer Entity
19
20
APSDE-SAP APSME-SAP 21
22
23
APSME 24
APSDE 25
APS 26
IB 27
28
29
NLDE-SAP NLME-SAP
30
31
NWK Layer Entity 32
33
34
35
Figure 4 The APS sub-layer reference model 36
37
1.2.4.1 APS data service 38
39
The APS sub-layer data entity SAP (APSDE-SAP) supports the transport of application protocol data units 40
between peer application entities. Table 1 lists the primitives supported by the APSDE-SAP. Each of these 41
primitives will be discussed in the following sub-clauses. 42
Table 1 APSDE-SAP primitives 43
44
APSDE-SAP primitive Request Confirm Indication 45
APSDE-DATA 1.2.4.1.1 1.2.4.1.2 1.2.4.1.3 46
47
48
1.2.4.1.1 APSDE-DATA.request 49
50
This primitive requests the transfer of a NHLE PDU (ASDU) from the local NHLE to a single peer NHLE 51
entity. 52
53
54

1 1.2.4.1.1.1 Semantics of the service primitive

2
3 This semantics of this primitive are as follows:
4
5 APSDE-DATA.request (
6 DstAddrMode,
7 DstAddress,
DstEndpoint,
8 ProfileId,
9 ClusterId,
10 SrcEndpoint,
11 asduLength,
12 asdu,
TxOptions,
13 DiscoverRoute,
14 RadiusCounter
15 )
16
17 Table 2 specifies the parameters for the APSDE-DATA.request primitive.
18
19 Table 2 APSDE-DATA.request parameters
20 Name Type Valid range Description
21
The addressing mode for the destination
22
address used in this primitive and of the
23 APDU to be transferred. This parameter
24 can take one of the non-reserved values
25 from the following list:
26
0x00 = DstAddress and DstEndpoint not
27
present.
28 DstAddrMode Integer 0x00 – 0xff
29 0x01 = 16 bit short address for DstAd-
30 dress and DstEndpoint present.
31
0x02 = 64 bit extended address for
32
DstAddress and DstEndpoint present.
33
34 0x03 – 0xff = reserved.
35
36 The individual device address of the
Device As specified by the DstAd-
DstAddress entity to which the ASDU is being trans-
37 address drMode parameter.
ferred.
38
39 The individual endpoint of the entity to
DstEndpoint Integer 0x00 – 0xff
40 which the ASDU is being transferred.
41 The identifier of the profile for which this
ProfileId Integer 0x0000 – 0xffffa
42 frame is intended.b
43
The identifier of the object to use in the
44 binding operation if the frame is to be
45 ClusterId Integer 0x00 – 0xff sent using indirect addressing. If indirect
46 addressing is not being used, this
47 parameter is ignored.
48
The individual endpoint of the entity from
49 SrcEndpoint Integer 0x00 – 0xfe
which the ASDU is being transferred.
50
51 c The number of octets comprising the
asduLength Integer
52 ASDU to be transferred.
53
54

Table 2 APSDE-DATA.request parameters 1

2
The set of octets comprising the ASDU
Asdu Set of octets - 3
to be transferred.
4
The transmission options for the ASDU 5
to be transferred. These are a bitwise 6
OR of one or more of the following:
7
0000 0xxx
TxOptions Bitmap 0x01 = Security enabled transmission. 8
(Where x can be 0 or 1) 9
0x02 = Use NWK key. 10
11
0x04 = Acknowledged transmission.
12
The DiscoverRoute parameter supplies 13
control information from the application 14
layer to the network layer regarding 15
actions to be taken in route discovery. 16
The possible values are:
17
0x00 = suppress route discovery (use 18
existing routing information for this 19
request). 20
21
DiscoverRoute Integer 0x00-0x02 0x01 = enable route discovery (perform
route discovery if there is not already an 22
existing route for this request). 23
24
0x02 = force route discovery (explicitly 25
request route discovery to occur before 26
routing this request).
27
The DiscoverRoute parameter has a 28
value corresponding to the NLDE- 29
DATA.request (see Chapter 2)d. 30
31
The distance, in hops, that a broadcast
Unsigned 32
RadiusCounter 0x00-0xff frame will be allowed to travel through
Integer 33
the network.
34
aCCB Comment #168
bCCB Comment #208
35
cCCB Comment #336 36
dCCB Comment #256 37
38
39
1.2.4.1.1.2 When generated 40
41
This primitive is generated by a local NHLE whenever a data PDU (ASDU) is to be transferred to a peer
42
NHLE.
43
44
1.2.4.1.1.3 Effect on receipt
45
On receipt of this primitive the APS sub-layer entity begins the transmission of the supplied ASDU. 46
47
If the DstAddrMode parameter is set to 0x00, the DstAddress and DstEndpoint parameters are ignored and 48
the value of the DstEndpoint parameter is not placed in the resulting APDU; this option allows indirect 49
addressing to be used. If the DstAddrMode parameter is set to 0x01, the DstAddress parameter contains a 50
16-bit short address and the DstEndpoint parameters are placed in the resulting APDU. If the DstAddrMode 51
parameter is set to 0x02, the DstAddress parameter contains an extended, 64-bit IEEE address and the 52
DstEndpoint parameters are placed in the resulting APDU. 53
54

1 The DiscoverRoute parameter is set by the application based on requested handling of route discovery at the
2 Network Layer. The application may employ APS Acknowledgement or application-level message
3 responses to determine whether messages are received reliably at the destination. Based on metrics managed
4 within the application, the DiscoverRoute parameter may be used to request route discovery operations at
5 the Network Layer to improve reliable delivery. If NWK broadcast messaging is employed (the DstAddress
6 is set to 0xffff), the application can specify the RadiusCounter (0x00 targets all devices that are part of the
7 network, a value of 0x01-0xff sets the radius of the broadcast message as measured from the source)6
8
9 If the APDU is to be transmitted using direct addressing (a destination address is present), the APSDE
10 transmits the constructed frame by issuing the NLDE-DATA.request primitive to the NWK layer. On receipt
11 of the NLDE-DATA.confirm primitive, the APSDE issues the APSDE-DATA.confirm primitive (see sub-
12 clause 1.2.4.1.2) with a status equal to that received from the NWK layer.
13
If the APDU is to be transmitted using indirect addressing (indirect addressing value specified in the
14
delivery mode sub-field / a destination address is not present) and this primitive was received by the APSDE
15
of the ZigBee coordinator or router, a search is made in the binding table for devices bound to this device
16
with the endpoint information specified in the SrcEndpoint parameter. If no bound devices are found, the
17
APSDE issues the APSDE-DATA.confirm primitive with a status of NO_BOUND_DEVICE. If one or more
18
bound devices were found, the APSDE constructs the ASDU with the destination address and endpoint
19
information of the bound device and transmits the frame by issuing the NLDE-DATA.request primitive to
20
the NWK layer. On receipt of the corresponding NLDE-DATA.confirm, the APSDE constructs and
21
transmits the APDU for the next bound device, as described above; until no more bound devices remain. On
22
receipt of the initial request, the APSDE issues the APSDE-DATA.confirm primitive with a status of
23
SUCCESS to the originator indicating that the message will be reflected to each bound device indicated in
24
the binding table.7
25
26 If the APDU is to be transmitted using indirect addressing and a non-ZigBee coordinator or ZigBee router
27 device received this primitive, the APSDE constructs the ASDU, without a destination endpoint field, and
28 issues the NLDE-DATA.request primitive to the NWK layer. On receipt of the NLDE-DATA.confirm
29 primitive, the APSDE issues the APSDE-DATA.confirm primitive with a status equal to that received from
30 the NWK layer.
31
32 1.2.4.1.2 APSDE-DATA.confirm
33
34 If the TxOptions parameter specifies that secured transmission is required, the ASL sub-layer shall use the
35 security service provider (see sub-clause 3.2.4 ) to secure the ASDU. If the security processing fails, the
36 APSDE shall issue the APSDE-DATA.confirm primitive with a status of SECURITY_FAIL.APSDE-
37 DATA.confirm
38
39 This primitive reports the results of a request to transfer a data PDU (ASDU) from a local NHLE to a single
40 peer NHLE.
41
42
43
44
45
46
47
48
49
50
51
52
53 6CCB Comment #256
7
54 CCB Comment #173, 214, 254

1.2.4.1.2.1 Semantics of the service primitive 1

2
This semantics of this primitive are as follows: 3
4
APSDE-DATA.confirm ( 5
DstAddrMode, 6
DstAddress, 7
DstEndpoint,
SrcEndpoint, 8
Status 9
) 10
11
Table 3 specifies the parameters for the APSDE-DATA.confirm primitive. 12
13
Table 3 APSDE-DATA.confirm parameters 14
Name Type Valid range Description 15
16
The addressing mode for the destina-
17
tion address used in this primitive and
of the APDU to be transferred. This 18
parameter can take one of the non- 19
reserved values from the following list: 20
21
0x00 = DstAddress and DstEndpoint
22
not present.
DstAddrMode Integer 0x00 – 0xff 23
0x01 = 16 bit short address for DstAd- 24
dress and DstEndpoint present. 25
26
0x02 = 64 bit extended address for
27
DstAddress and DstEndpoint present.
28
0x03 – 0xff = reserved. 29
30
The individual device address of the 31
Device As specified by the DstAd-
DstAddress entity to which the ASDU is being
address drMode parameter. 32
transferred.
33
The individual endpoint of the entity to 34
which the ASDU is being transferred. 35
The individual endpoint of the entity 36
SrcEndpoint Integer 0x00 – 0xfe from which the ASDU is being trans- 37
ferred. 38
39
SUCCESS, The status of the corresponding
40
NO_BOUND_DEVICE, request.
SECURITY_FAIL or any 41
Status Enumeration 42
status values returned from
the NLDE-DATA.confirm 43
primitive. 44
45
46
48
This primitive is generated by the local APS sub-layer entity in response to an APSDE-DATA.request
49
primitive. This primitive returns a status of either SUCCESS, indicating that the request to transmit was
50
successful, or an error code of NO_BOUND_DEVICE or SECURITY_FAIL or any status values returned
51
from the NLDE-DATA.confirm primitive. The reasons for these status values are fully described in the next
52
section.
53
54

1 1.2.4.1.2.3 Effect on receipt

2
3 On receipt of this primitive the next higher layer of the initiating device is notified of the result of its request
4 to transmit. If the transmission attempt was successful, the status parameter will be set to SUCCESS.
5 Otherwise, the status parameter will indicate the error.
6
7 1.2.4.1.3 APSDE-DATA.indication
8
This primitive indicates the transfer of a data PDU (ASDU) from the APS sub-layer to the local application
9
entity.
10
11
1.2.4.1.3.1 Semantics of the service primitive
12
14
15
APSDE-DATA.indication (
16 DstEndpoint,
17 SrcAddrMode,
18 SrcAddress,
19 SrcEndpoint,
20 ProfileId,a
ClusterId,
21 asduLength,
22 asdu,
23 WasBroadcast,
24 SecurityStatus
25 )
26 aCCB
Comment #208
27
28 Table 4 specifies the parameters for the APSDE-DATA.indication primitive.
29
30 Table 4 APSDE-DATA.indication parameters
32
The target endpoint on the local entity to
33 DstEndpoint Integer 0x00 – 0xff
which the ASDU is being transferred.
34
35 The addressing mode for the source
36 address used in this primitive and of the
37 APDU to be transferred. This parameter
can take one of the non-reserved values
38 from the following list:
39
40 0x00 = SrcAddress and SrcEndpoint not
41 present.
SrcAddrMode Integer 0x00 – 0xff
42
0x01 = 16 bit short address for SrcAd-
43 dress and SrcEndpoint present.
44
45 0x02 = 64 bit extended address for
46 SrcAddress and SrcEndpoint present.
47
0x03 – 0xff = reserved.
48
49 The individual device address of the
Device As specified by the SrcAd-
50 SrcAddress entity from which the ASDU is being
address drMode parameter.
51 transferred.
52 The source endpoint from which the
53 SrcEndpoint Integer 0x00 – 0xfe
ASDU is being transferred.
54

Table 4 APSDE-DATA.indication parameters 1

The identifier of the profile from which 2
ProfileId Integer 0x0000 - 0xffff 3
this frame originated.a
4
ClusterId Integer 0x00-0xff The identifier of the received object. 5
b The number of octets comprising the 6
asduLength Integer 7
ASDU being indicated by the APSDE.
8
The set of octets comprising the ASDU 9
asdu Set of octets -
being indicated by the APSDE.
10
TRUE if the transmission was a broad- 11
WasBroadcast Boolean TRUE or FALSE
cast, FALSE otherwise. 12
13
UNSECURED if the ASDU was received
without any security. 14
15
UNSECURED, SECURED_NWK_KEY if the received. 16
SecurityStatus Enumeration SECURED_NWK_KEY, 17
SECURED_LINK_KEY ASDU was secured with the NWK key. 18
SECURED_LINK_KEY if the ASDU was 19
secured with a link key. 20
21
aCCB Comment #208
bCCB Comment #336
22
23
24
26
This primitive is generated by the APS sub-layer and issued to the next higher layer on receipt of an 27
appropriately addressed data frame from the local NWK layer entity. If the frame control field of the ASDU 28
header indicates that the frame is secured, then security processing shall be done as specified in sub- 29
clause 3.2.4. 30
31
1.2.4.1.3.3 Effect on receipt 32
33
On receipt of this primitive the next higher layer is notified of the arrival of data at the device. 34
35
1.2.4.2 APS management service 36
The APS management entity SAP (APSME-SAP) supports the transport of management commands 37
between the next higher layer and the APSME. Table 5 summarizes the primitives supported by the APSME 38
through the APSME-SAP interface. See the following sub-clauses for more details on the individual 39
primitives. 40
41
Table 5 Summary of the primitives accessed through the APSME-SAP 42
Name Request Indication Response Confirm 43
44
APSME-BIND 1.2.4.3.1 1.2.4.3.2 45
APSME-GET 1.2.4.4.1 1.2.4.4.2 46
47
APSME-SET 1.2.4.4.3 1.2.4.4.4 48
49
APSME-UNBIND 1.2.4.3.3 1.2.4.3.4
50
51
52
53
54

1 1.2.4.3 Binding Primitives

2
3 This set of primitives defines how the next higher layer of a device can add (commit) a binding record to its
4 local binding table or remove a binding record from its local binding table.8
5
6 1.2.4.3.1 APSME-BIND.request
7
This primitive allows the next higher layer to request to bind two devices together if issued on a ZigBee
8
coordinator or on the device indicated by the SrcAddr of the request.9
9
10
11
12 The semantics of this primitive are as follows:
13
14
APSME-BIND.request (
15 SrcAddr,
16 SrcEndpoint,
17 ClusterId,
18 DstAddr,
19 DstEndpoint
)
20
21
22 Table 6 specifies the parameters for the APSME-BIND.request primitive.
23 Table 6 APSME-BIND.request parameters
24
26 SrcAddr A valid 64-bit IEEE The source IEEE address for the
IEEE address
27 address binding entry.
28
SrcEndpoint The source endpoint for the binding
29 Integer 0x01 – 0xff
entry.
30
31 ClusterId The identifier of the cluster on the
32 Integer 0x00 – 0xff source device that is to be bound to
the destination device.
33
34 DstAddr A valid 64-bit IEEE The destination IEEE address for
IEEE address
35 address the binding entry.
36
DstEndpoint The destination endpoint for the
37 Integer 0x01 – 0xff
binding entry.
38
39
40 1.2.4.3.1.2 When generated
41
42 This primitive is generated by the next higher layer and issued to the APS sub-layer in order to instigate a
43 binding operation on a ZigBee coordinator or on the device indicated by the SrcAddr of the request.10
44
46
47 If the APS on a ZigBee coordinator or the device indicated by the SrcAddr of the request receives this
48 primitive from the NHLE, the APSME attempts to create the specified entry directly in its binding table. If
49 the entry could be created, the APSME issues the APSME-BIND.confirm primitive with the Status
50
51
52 8
CCB Comment #172
10
54 CCB Comment #173

parameter set to SUCCESS. If the entry could not be created due to a lack of capacity in the binding table, 1
the APSME issues the APSME-BIND.confirm primitive with the Status parameter set to TABLE_FULL.11 2
3
1.2.4.3.2 APSME-BIND.confirm 4
5
This primitive allows the next higher layer to be notified of the results of its request to bind two devices 6
directly or by proxy. 7
8
10
The semantics of this primitive are as follows:
11
12
APSME-BIND.confirm ( 13
Status,
14
SrcAddr,
SrcEndpoint, 15
ClusterId, 16
DstAddr, 17
DstEndpoint 18
)
19
20
Table 7 specifies the parameters for the APSME-BIND.confirm primitive. 21
22
Table 7 APSME-BIND.confirm parameters
23
SUCCESS, ILLEGAL_DEVICE, The results of the binding request. 25
Status Enumeration ILLEGAL_REQUEST, TABLE_FULL, 26
NOT_SUPPORTED 27
28
The source IEEE address for the
SrcAddr IEEE address A valid 64-bit IEEE address 29
binding entry.
30
The source endpoint for the binding 31
SrcEndpoint Integer 0x01 – 0xff
entry. 32
The identifier of the cluster on the 33
ClusterId Integer 0x00 – 0xff source device that is to be bound to 34
the destination device. 35
36
The destination IEEE address for
DstAddr IEEE address A valid 64-bit IEEE address 37
the binding entry.
38
The destination endpoint for the 39
binding entry. 40
41
42
44
This primitive is generated by the APSME and issued to its NHLE in response to an APSME-BIND.request
45
primitive. If the request was successful, the Status parameter will indicate a successful bind request.
46
Otherwise, the status parameter indicates an error code of ILLEGAL_DEVICE, ILLEGAL_REQUEST or
47
TABLE_FULL.
48
49
50
51
52
53
11
CCB Comment #173, 264 54


2
3 On receipt of this primitive, the next higher layer is notified of the results of its bind request. If the bind
4 request was successful, the Status parameter is set to SUCCESS. Otherwise, the Status parameter indicates
5 the error.
6
7 1.2.4.3.3 APSME-UNBIND.request
8
This primitive allows the next higher layer on a ZigBee coordinator or on the device indicated by the
9
SrcAddr of the request to request the unbinding of two devices.12
10
11
12
13 The semantics of this primitive are as follows:
14
15
APSME-UNBIND.request (
16 SrcAddr,
17 SrcEndpoint,
18 ClusterId,
19 DstAddr,
20 DstEndpoint
)
21
22
23 Table 8 specifies the parameters for the APSME-UNBIND.request primitive.
24 Table 8 APSME-UNBIND.request parameters
25
27 A valid 64-bit IEEE The source IEEE address for the
SrcAddr IEEE address
28 address binding entry.
29
The source endpoint for the binding
30 SrcEndpoint Integer 0x01 – 0xff
entry.
31
32 The identifier of the cluster on the
33 ClusterId Integer 0x00 – 0xff source device that is bound to the
destination device.
34
35 A valid 64-bit IEEE The destination IEEE address for
DstAddr IEEE address
36 address the binding entry.
37
The destination endpoint for the
38 DstEndpoint Integer 0x01 – 0xff
binding entry.
39
40
42
43 This primitive is generated by the next higher layer and issued to the APS sub-layer in order to instigate an
44 unbind operation on a ZigBee coordinator or on the device indicated by the SrcAddr of the request.13
45
47
48 On receipt of this primitive by a device that is not currently joined to a network, the APSME issues the
49 APSME-UNBIND.confirm primitive with the Status parameter set to ILLEGAL_REQUEST.
50
51
52
13
54 CCB Comment #173

If the APS on a ZigBee coordinator or the device indicated by the SrcAddr of the request receives this 1
primitive from the NHLE, the APSME searches for the specified entry in its binding table. If the entry 2
exists, the APSME removes the entry and issues the APSME-UNBIND.confirm (see sub-clause 1.2.4.3.4) 3
primitive with the Status parameter set to SUCCESS. If the entry could not be found, the APSME issues the 4
APSME-UNBIND.confirm primitive with the Status parameter set to INVALID_BINDING. If the devices 5
do not exist on the network, the APSME issues the APSME-BIND.confirm primitive with the Status 6
parameter set to ILLEGAL_DEVICE.14 7
8
1.2.4.3.4 APSME-UNBIND.confirm 9
10
This primitive allows the next higher layer to be notified of the results of its request to unbind two devices 11
directly or by proxy. 12
13
15
The semantics of this primitive are as follows:
16
17
APSME-UNBIND.confirm ( 18
Status,
19
SrcAddr,
SrcEndpoint, 20
ClusterId, 21
DstAddr, 22
DstEndpoint 23
)
24
25
Table 9 specifies the parameters for the APSME-UNBIND.confirm primitive. 26
27
Table 9 APSME-UNBIND.confirm parameters
28
SUCCESS, ILLEGAL_DEVICE, The results of the unbind request. 30
Status Enumeration ILLEGAL_REQUEST, 31
INVALID_BINDING 32
33
The source IEEE address for the
SrcAddr IEEE address A valid 64-bit IEEE address 34
binding entry.
35
The source endpoint for the binding 36
SrcEndpoint Integer 0x01 – 0xff
entry. 37
The identifier of the cluster on the 38
ClusterId Integer 0x00 – 0xff source device that is bound to the 39
destination device. 40
41
The destination IEEE address for
DstAddr IEEE address A valid 64-bit IEEE address 42
the binding entry.
43
The destination endpoint for the 44
binding entry. 45
46
47
49
This primitive is generated by the APSME and issued to its NHLE in response to an APSME-
50
UNBIND.request primitive. If the request was successful, the Status parameter will indicate a successful
51
52
53
14
CCB Comment #173 54

1 unbind request. Otherwise, the status parameter indicates an error code of ILLEGAL_DEVICE,
2 ILLEGAL_REQUEST, or INVALID_BINDING.
3
5
6 On receipt of this primitive, the next higher layer is notified of the results of its unbind request. If the unbind
7 request was successful, the Status parameter is set to SUCCESS. Otherwise, the Status parameter indicates
8 the error.
9
10 1.2.4.4 Information base maintenance
11
This set of primitives defines how the next higher layer of a device can read and write attributes in the AIB.
12
13
1.2.4.4.1 APSME-GET.request
14
15 This primitive allows the next higher layer to read the value of an attribute from the AIB.
16
18
19 The semantics of this primitive is as follows:
20
21 APSME-GET.request (
22 AIBAttribute
23 )
24
25 Table 10 specifies the parameters for this primitive.
26
27 Table 10 APSME-GET.request parameters
28 Name Type Valid Range Description
29
AIBAttribute Integer See Table 17 The identifier of the AIB attribute to read.
30
31
32
1.2.4.4.1.2 When generated
33
34 This primitive is generated by the next higher layer and issued to its APSME in order to read an attribute
35 from the AIB.
36
38
39 On receipt of this primitive, the APSME attempts to retrieve the requested AIB attribute from its database. If
40 the identifier of the AIB attribute is not found in the database, the APSME issues the APSME-GET.confirm
41 primitive with a status of UNSUPPORTED_ATTRIBUTE.
42
43 If the requested AIB attribute is successfully retrieved, the APSME issues the APSME-GET.confirm
44 primitive with a status of SUCCESS such that it contains the AIB attribute identifier and value.
45
46 1.2.4.4.2 APSME-GET.confirm
47
This primitive reports the results of an attempt to read the value of an attribute from the AIB.
48
49
50
51
52
53
54


2
The semantics of this primitive is as follows: 3
4
APSME-GET.confirm ( 5
Status, 6
AIBAttribute, 7
AIBAttributeValue
) 8
9
10
Table 11 specifies the parameters for this primitive. 11
Table 11 APSME-GET.confirm parameters 12
13
Name Type Valid Range Description
14
SUCCESS or The results of the request to read an AIB 15
Status Enumeration UNSUPPORTED_A attribute value. 16
TTRIBUTE
17
The identifier of the AIB attribute that was 18
AIBAttribute Integer See Table 17.
read. 19
20
Attribute Specific The value of the AIB attribute that was
AIBAttributeValue Various 21
(see Table 17). read.
22
23
25
This primitive is generated by the APSME and issued to its next higher layer in response to an APSME- 26
GET.request primitive. This primitive returns a status of SUCCESS, indicating that the request to read an 27
AIB attribute was successful, or an error code of UNSUPPORTED_ATTRIBUTE. The reasons for these 28
status values are fully described in sub-clause 1.2.4.4.1.3. 29
30
32
On receipt of this primitive, the next higher layer is notified of the results of its request to read an AIB 33
attribute. If the request to read an AIB attribute was successful, the Status parameter will be set to 34
SUCCESS. Otherwise, the status parameter indicates the error. 35
36
1.2.4.4.3 APSME-SET.request 37
38
This primitive allows the next higher layer to write the value of an attribute into the AIB. 39
40
43
44
APSME-SET.request (
45
AIBAttribute,
AIBAttributeValue 46
) 47
48
49
50
51
52
53
54


2
3 Table 12 APSME-SET.request parameters
5 The identifier of the AIB attribute to be writ-
6 AIBAttribute Integer See Table 17.
ten.
7
8 Attribute Specific The value of the AIB attribute that should
AIBAttributeValue Various
(see Table 17). be written.
9
10
11
12
13 This primitive is to be generated by the next higher layer and issued to its APSME in order to write the value
14 of an attribute in the AIB.
15
17
18 On receipt of this primitive the APSME attempts to write the given value to the indicated AIB attribute in its
19 database. If the AIBAttribute parameter specifies an attribute that is not found in the database, the APSME
20 issues the APSME-SET.confirm primitive with a status of UNSUPPORTED_ATTRIBUTE. If the
21 AIBAttributeValue parameter specifies a value that is out of the valid range for the given attribute, the
22 APSME issues the APSME-SET.confirm primitive with a status of INVALID_PARAMETER.
23
24 If the requested AIB attribute is successfully written, the APSME issues the APSME-SET.confirm primitive
25 with a status of SUCCESS.
26
27 1.2.4.4.4 APSME-SET.confirm
28
This primitive reports the results of an attempt to write a value to an AIB attribute.
29
30
31
33
34
APSME-SET.confirm (
35 Status,
36 AIBAttribute
37 )
38
40
41 Table 13 APSME-SET.confirm parameters
43
SUCCESS, The result of the request to write
44
Status Enumeration INVALID_PARAMETER or the AIB Attribute.
45 UNSUPPORTED_ATTRIBUTE
46
47 The identifier of the AIB attribute
AIBAttribute Integer See Table 17.
48 that was written.
49
50
52 This primitive is generated by the APSME and issued to its next higher layer in response to an APSME-
53 SET.request primitive. This primitive returns a status of either SUCCESS, indicating that the requested
54

value was written to the indicated AIB attribute, or an error code of INVALID_PARAMETER or 1
UNSUPPORTED_ATTRIBUTE. The reasons for these status values are fully described in sub- 2
clause 1.2.4.4.3.3. 3
4
6
On receipt of this primitive, the next higher layer is notified of the results of its request to write the value of 7
a AIB attribute. If the requested value was written to the indicated AIB attribute, the Status parameter will be 8
set to SUCCESS. Otherwise, the Status parameter indicates the error. 9
10
1.2.5 Frame formats 11
12
This sub-clause specifies the format of the APS frame (APDU). Each APS frame consists of the following 13
basic components: 14
15
— An APS header, which comprises frame control and addressing information. 16
17
— An APS payload, of variable length, which contains information specific to the frame type.
18
The frames in the APS sub-layer are described as a sequence of fields in a specific order. All frame formats 19
in this sub-clause are depicted in the order in which they are transmitted by the NWK layer, from left to 20
right, where the leftmost bit is transmitted first in time. Bits within each field are numbered from 0 (leftmost 21
and least significant) to k-1 (rightmost and most significant), where the length of the field is k bits. Fields 22
that are longer than a single octet are sent to the NWK layer in the order from the octet containing the lowest 23
numbered bits to the octet containing the highest numbered bits. 24
25
1.2.5.1 General APDU frame format 26
27
The APS frame format is composed of an APS header and an APS payload. The fields of the APS header 28
appear in a fixed order, however, the addressing fields may not be included in all frames. The general APS 29
frame shall be formatted as illustrated in Figure 5. 30
31
Octets: 1 0/1 0/1 0/2 0/1 Variable 32
Destination end- Cluster Profile 33
Frame Source endpoint
point Identifier Identifier Frame payload 34
control 35
Addressing fields
36
APS header APS payload 37
38
39
Figure 5 General APS frame format 40
41
1.2.5.1.1 Frame control Field 42
43
The frame control field is 8-bits in length and contains information defining the frame type, addressing 44
fields and other control flags. The frame control field shall be formatted as illustrated in Figure 6. 45
46
Bits: 0-1 2-3 4 5 6 7
47
Indirect 48
Delivery
Frame type address Security Ack. request Reserved 49
mode
modea
50
aCCB 51
Comment #210
52
53
Figure 6 Format of the frame control field 54

1 1.2.5.1.1.1 Frame type sub-field

2
3 The frame type sub-field is two bits in length and shall be set to one of the non-reserved values listed in
4 Table 14.
5 Table 14 Values of the frame type sub-field
6
7 Frame type value
Frame type name
8 b1 b0
9 00 Data
10
11 01 Command
12
10 Acknowledgement
13
14 11 Reserved
15
16
17 1.2.5.1.1.2 Delivery mode sub-field
18
19 The delivery mode sub-field is two bits in length and shall be set to one of the non-reserved values from
20 Table 15.
21 Table 15 Values of the delivery mode sub-field
22
23 Delivery mode value
Delivery mode name
24 b3 b2
25 00 Normal unicast delivery
26
27 01 Indirect addressing
28
10 Broadcast
29
30 11 Reserved
31
32
33 If the value is 0b01 then indirect addressing is in use and either the destination or source endpoint shall be
34 omitted, depending on the value of the indirect address mode sub-field. If the value is 0b10 then the message
35 is a broadcast. In this case the message will go to all devices and all endpoints.15
36
37 1.2.5.1.1.3 Indirect address mode sub-field
38
The indirect address mode sub-field is one bit in length and specifies whether the source or destination
39
endpoint fields are present in the frame when the delivery mode sub-field is set to indicate indirect
40
addressing. If this sub-field is set to 1, the destination endpoint field shall be omitted from the frame,
41
indicating an indirect transmission to the ZigBee coordinator. If this sub-field is set to 0, the source endpoint
42
field shall be omitted from the frame, indicating an indirect transmission from the ZigBee coordinator. If the
43
delivery mode sub-field of the frame control field does not indicate indirect addressing, the indirect address
44
mode sub-field shall be ignored.16
45
46
1.2.5.1.1.4 Security sub-field
47
48 The Security Services Provider (see Chapter 3) manages the security sub-field.
49
50
51
52
53 15CCB Comment #165. 210
16
54 CCB Comment #210

1.2.5.1.1.5 Acknowledgement request sub-field 1

2
The acknowledgement request sub-field is one bit in length and specifies whether the current transmission 3
requires an acknowledgement frame to be sent be the recipient on receipt of the frame. If this sub-field is set 4
to 1, the recipient shall construct and send an acknowledgement frame back to the originator after 5
determining that the frame is valid. If this sub-field is set to 0, the recipient shall not send an 6
acknowledgement frame back to the originator after determining that the frame is valid. 7
8
1.2.5.1.2 Destination endpoint field 9
10
The destination endpoint field is 8-bits in length and specifies the endpoint of the final recipient of the
11
frame. A destination endpoint value of 0x00 addresses the frame to the ZigBee device object (ZDO),
12
resident in each device. A destination endpoint value of 0x01-0xf0 addresses the frame to an application
13
operating on that endpoint. A destination endpoint value of 0xff addresses the frame to all active endpoints.
14
All other endpoints (0xf1-0xfe) are reserved.
15
16
1.2.5.1.3 Cluster identifier field
17
The cluster identifier field is 8-bits in length and specifies the identifier of the cluster that is to be used in the 18
binding operation on the ZigBee coordinator or on the device indicated by the SrcAddr of the request. The 19
frame type sub-field of the frame control field specifies whether the cluster identifier field is present or not. 20
It will be for data frames, but not for command frames.17 21
22
1.2.5.1.4 Profile identifier field 23
24
The profile identifier is 2 octets in length and specifies the ZigBee profile identifier for which the frame is 25
intended and shall be used during the filtering of messages at each device that takes delivery of the frame. 26
This field shall be present only for data or acknowledgement frames.18 27
28
1.2.5.1.5 Source endpoint field 29
30
The source endpoint field is 8-bits in length and specifies the endpoint of the initial originator of the frame. 31
A source endpoint value of 0x00 indicates that the frame originated from the ZigBee device object (ZDO) 32
resident in each device. A source endpoint value of 0x01-0xf0 indicates that the frame originated from an 33
application operating on that endpoint. All other endpoints (0xf1-0xfe) are reserved. 34
35
If the delivery mode sub-field of the frame control field indicates a delivery mode of indirect addressing and
36
the indirect address mode sub-field is set to 0, this field shall not be included in the frame19
37
38
1.2.5.1.6 Frame payload field
39
The frame payload field has a variable length and contains information specific to individual frame types. 40
41
1.2.5.2 Format of individual frame types 42
43
There are three defined frame types: data, APS command and acknowledgement. Each of these frame types 44
is discussed in the following sub-clauses.20 45
46
47
48
49
50
17
CCB Comment #173 51
18
CCB Comment #186 208 52
19CCB Comment #165, 210 53
20
CCB Comment #230 54

1 1.2.5.2.1 Data frame format

2
3 The data frame shall be formatted as illustrated in Figure 7.
4
5 Octets: 1 0/1 1 2a 0/b1 Variable
6
7 Destination end- Cluster Profile Source
Frame control Data payload
8 point identifier identifier endpoint
9 APS header APS payload
10
a
11 CCBComment #186, 208
b
12 CCB Comment #188
13
14 Figure 7 Data frame format
15 The order of the fields of the data frame shall conform to the order of the general APS frame as illustrated in
16 Figure 3.21
17
18 1.2.5.2.1.1 Data frame APS header field
19
20 The APS header field for a data frame shall contain the frame control, cluster identifier, profile identifier and
21 source endpoint fields. The destination endpoint field shall be included in a data frame according to the
22 value of the delivery mode sub-field of the frame control field.22
23
24 In the frame control field, the frame type sub-field shall contain the value that indicates a data frame, as
25 shown in Table 14. The source endpoint present sub-field shall be set to 1. All other sub-fields shall be set
26 appropriately according to the intended use of the data frame.
27
28 1.2.5.2.1.2 Data payload field
29
30 For an outgoing data frame, the data payload field shall contain the sequence of octets that the next higher
31 layer has requested the APS data service to transmit. For an incoming data frame, the data payload field shall
32 contain the sequence of octets that has been received by the APS data service and that is to be reflected to the
33 destination devices or delivered to the next higher layer if the coordinator is one of the destinations.
34
35 1.2.5.2.2 APS command frame format
36 The APS command frame shall be formatted as illustrated in Figure 8.
37
38
39 Octets: 1 1 Variable
40 APS command APS command
41 Frame control
identifier payload
42
43 APS header APS payload
44
45 Figure 8 APS command frame format
46
47 The order of the fields of the APS command frame shall conform to the order of the general APS frame as
48 illustrated in Figure 5.
49
50
51
52
53 21CCB Comment #186, 208
22
54 ibid

1.2.5.2.2.1 APS command frame APS header field 1

2
The APS header field for an APS command frame shall contain the frame control and an APS Payload. The 3
APS Payload portion of the APS Command Frame shall contain the APS Command Identifier followed by 4
the APS Command Payload. 5
6
In the frame control field, the frame type sub-field shall contain the value that indicates an APS command
7
frame, as shown in Table 14. The APS Command Payload shall be set appropriately according to the
8
intended use of the APS command frame.
9
10
1.2.5.2.2.2 APS command identifier field
11
The APS command identifier field identifies the APS command being used. 12
13
1.2.5.2.2.3 APS command payload field 14
15
The APS command payload field of an APS command frame shall contain the APS command itself. 16
17
1.2.5.2.3 Acknowledgement frame format 18
19
The acknowledgement frame shall be formatted as illustrated in Figure 9. 20
21
22
Octets: 1 0/1 1 2 0/a1
23
Destination Profile identi- Source 24
Frame control Cluster Id
endpoint fierb endpoint 25
APS header 26
27
aCCb Comment #165
28
bCCB Comment #186, 208 29
30
Figure 9 Acknowledgement frame format 31
The order of the fields of the acknowledgement frame shall conform to the order of the general APS frame 32
as illustrated in Figure 5.23 33
34
1.2.5.2.3.1 Acknowledgement frame APS header field 35
36
The APS header field for an acknowledgement frame shall contain the frame control, cluster identifier and 37
profile identifier fields. If the delivery mode indicates direct addressing both the source and destination 38
endpoint fields shall be included in an acknowledgement frame. If the delivery mode indicates indirect 39
addressing the source and destination endpoint fields shall be included in an acknowledgement frame 40
according to the value of the indirect address mode sub-field of the frame control field. 41
42
In the frame control field, the frame type sub-field shall contain the value that indicates an 43
acknowledgement frame, as shown in Table 14. All other sub-fielsds shall be set appropriately according to 44
the intended use of the acknowledgement frame. 45
46
Where present, the source endpoint field shall reflect the value in the destination endpoint field of the frame 47
that is being acknowledged. Similarly, where present, the destination endpoint field shall reflect the value in 48
the source endpoint field of the frame that is being acknowledged.24 49
50
51
52
23CCBComment #186, 208 53
24
CCB Comment #165, 186, 208 54

1 1.2.6 Command frames

2
3 This specification defines no command frames. Refer to sub-clause 3.5.9 for a thorough description of the
4 APS command frames and primitives related to security.
5
6
7
1.2.7 Constants and PIB attributes
8
9 1.2.7.1 APS Constants
10 The constants that define the characteristics of the APS sub-layer are presented in Table 16.
11
12 Table 16 APS sub-layer constants
13 Constant Description Value
14
15 The maximum number of Address Map 1 (minimum value)
entries.
16 apscMaxAddrMapEntries
17 Implementation-specific
18 (maximum value)
19 The maximum number of octets con-
20 apscMaxDescriptorSize 64
tained in a non-complex descriptor.
21
22 The maximum number of octets that can
apscMaxDiscoverySize be returned through the discovery pro- 64
23 cess.
24
25 The maximum number of octets added by 6 (without security)
26 apscMaxFrameOverhead the APS sub-layer to its payload.
27 20 (with security)
28
The maximum number of retries allowed
29 apscMaxFrameRetries 3
after a transmission failure.
30
31 The maximum number of seconds to wait 0.05 * (2*nwkcMaxDepth) +
32 for an acknowledgement to a transmitted (security encrypt/decrypt delay),
frame. where the (security encrypt/
33
apscAckWaitDuration decrypt delay) = 0.1
34
35 (assume 0.05 per encrypt or
36 decrypt cycle)a
37 aCCB
Comment #166, #366
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

1.2.7.2 APS Information Base 1

2
The APS information base comprises the attributes required to manage the APS layer of a device. The 3
attribtues of the AIB are listed in Table 17. The AIB also comprises of some additional attributes that are 4
required to manage the security service provider. These attributes are listed in sub-clause 3.5.10. 5
Table 17 APS IB attributes 6
7
Attribute Identifier Type Range Description Default 8
The current set of 64 bit 9
a IEEE to 16 bit NWK 10
apsAddressMap 0xc0 Set Variable Null set
address maps (see 11
Table 18).
12
The current set of binding 13
b table entries in the device 14
apsBindingTable 0xc1 Set Variable Null set
(see sub- 15
clause 1.2.8.1.1). 16
a
CCB Comment #150 17
bCCB Comment #248 18
19
20
21
Table 18 Address Map 22
23
64 bit IEEE 16 bit NWK 24
Entry Number
address address
25
0x00 - apscMaxAddrMap- 0x00000000 – 0x0000 – 26
Entries 0xffffffff 0xffff 27
28
29
1.2.8 Functional description 30
31
1.2.8.1 Binding 32
33
The APS may maintain a binding table, which allows ZigBee devices to establish a designated destination 34
for frames from a given source endpoint and with a given cluster ID. This table is employed by the indirect 35
addressing mechanism. 36
37
1.2.8.1.1 Binding table implementation 38
39
A ZigBee coordinator or a device designated by as and containing a binding table shall be able to support a
40
binding table of implementation specific length. The binding table shall implement the following mapping:
41
( as, es, cs ) = {( ad1, ed1 ), ( ad2, ed2 ) … ( adn, edn )}25 42
43
Where: 44
45
as = the address of the device as the source of the binding link, 46
47
es = the endpoint identifier of the device as the source of the binding link,
48
49
50
51
52
53
25
CCB Comment #173 54

1 cs = the cluster identifier used in the binding link,

2
3 adi = the ith address of the device as the destination of the binding link,
4
edi = the ith endpoint identifier of the device as the destination of the binding link
5
6
7 1.2.8.1.2 Binding
8
9 The APSME-BIND.request or APSME-UNBIND.request primitive executed on the ZigBee coordinator on
10 the device designated by the SrcAddr initiates the procedure for creating or removing a binding link. Only
11 those devices that are ZigBee coordinator capable and currently operating as the ZigBee coordinator or are
12 the device indicated by the SrcAddr in the request shall initiate this procedure. If this procedure is initiated
13 on any other device, the APSME shall terminate the procedure and notify the NHLE of the illegal request.
14 This is achieved by issuing the APSME-BIND.confirm or APSME-UNBIND.confirm primitive with the
15 Status parameter set to ILLEGAL_REQUEST.
16
17 When this procedure is initiated, the APSME of a ZigBee coordinator or the device designated by SrcAddr
18 shall first extract the address and endpoint for both the source and destination of the binding link. With this
19 information, the APSME shall either create a new entry or remove the corresponding entry from its binding
20 table, depending on whether the bind or unbind procedure, respectively, was initiated.
21
If a bind operation was requested, the APSME shall create a new entry in the binding table. The ZigBee
22
coordinator or device designated by the SrcAddr shall only create a new entry in the binding table if it has
23
the capacity to do so. If capacity is not available, it shall terminate the procedure and notify the NHLE of the
24
unavailable capacity. This is achieved by issuing the APSME-BIND.confirm primitive with the Status
25
parameter set to TABLE_FULL.26
26
27 If an unbind operation was requested, the APSME shall search the binding table for an existing entry that
28 matches the information contained in the initiation request. If an entry was not found, the APSME shall
29 terminate the procedure and notify the NHLE of the invalid binding. This is achieved by issuing the
30 APSME-UNBIND.confirm primitive with the Status parameter set to INVALID_BINDING. If an entry was
31 found, the APSME shall remove the entry in the binding table.
32
33 If the binding link is successfully created or removed, the APSME shall notify the NHLE of the results of
34 the direct binding attempt and the success of the procedure. This is achieved by issuing the APSME-
35 BIND.confirm primitive with the binding results and the status parameter set to SUCCESS.
36
37 The procedure for a successful direct binding is illustrated in the MSC shown in Figure 10.
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
26
54 CCB Comment #173

1
2
ZigBee coord. or ZigBee coord or ZigBee coord or 3
SrcAddr APL SrcAddr. APS SrcAddr. NWK 4
5
APSME- 6
(UN)BIND.request 7
8
Create a new entry or 9
remove an existing entry 10
in the binding table 11
APSME- 12
(UN)BIND.confirm 13
14
15
16
Figure 10 Direct binding on a ZigBee coordinator or SrcAddr device27 17
18
1.2.8.2 Transmission, reception and acknowledgement 19
20
This sub-clause describes the fundamental procedures for transmission, reception and acknowledgement 21
22
1.2.8.2.1 Transmission 23
24
Only those devices that are currently part of a network shall send frames from the APS sub-layer. If any
25
other device receives a request to transmit a frame it shall discard the frame and notify the instigating layer
26
of the error. An APSDE-DATA.confirm primitive with a status of CHANNEL_ACCESS_FAILURE
27
indicates that the attempt at transmission of the frame was unsuccessful due to the channel being busy.
28
All frames handled by or generated within the APS sub-layer shall be constructed according to the general 29
frame format specified in 6.1 and transmitted using the NWK layer data service28 30
31
Transmissions may be either direct or indirect. Direct transmissions shall include both destination and 32
source endpoint fields. In this case, the delivery mode sub-field of the frame control field shall be set to 33
either 0x00 (Normal Unicast) or 0x02 (Broadcast). 34
35
The APS layer of the device originating an indirect transmission where the binding table entry is stored at 36
the ZigBee coordinator shall direct the transmission to the ZigBee coordinator, which shall handle the task 37
of message reflection. 38
39
Indirect transmissions (i.e. those in which the delivery mode sub-field is set to 0b01) shall include only
40
either the source endpoint field or the destination endpoint field, depending on the direction of transmission
41
with respect to the ZigBee coordinator. If the indirect transmission is directed to the ZigBee coordinator, the
42
indirect address mode sub-field shall be set to 1 and the destination endpoint field shall be omitted from the
43
frame. Conversely, if the indirect transmission is directed from the ZigBee coordinator after message
44
reflection, the indirect address mode sub-field shall be set to 0 and the source endpoint field shall be omitted
45
from the frame.
46
For all devices where the binding table is stored on the source device, the APS layer of the source device 47
originating the transmission shall employ direct transmission to the destination addresses indicated by the 48
corresponding binding table entries. In this case, the delivery mode sub-field of the frame control field shall 49
be set to 0x00.29 50
51
52
27ibid 53
28
CCB Comment #208 54

1 The destination endpoint field, if present, shall contain the endpoint of the intended recipient of the APDU.
2 The source endpoint field, if present, shall contain the endpoint of the originator of the APDU.
3
4 If security is required, then the frame shall be processed as described in clause 3.5.
5
When the frame is constructed and ready for transmission, it shall be passed to the NWK data service with a
6
suitable destination and source address. An APDU transmission is initiated by issuing the NLDE-
7
DATA.request primitive to the NWK layer and the results of the transmission returned via the NLDE-
8
DATA.confirm primitive.
9
10
1.2.8.2.2 Reception and rejection
11
12 The APS sub-layer shall be able to filter frames arriving via the NWK layer data service and only present the
13 frames that are of interest to the NHLE.
14
15 If the APSDE receives a secured frame, it shall process the frame as described in clause 3.5 to remove the
16 security.
17
18 If the APSDE receives a frame containing both destination and source endpoints, it shall be assumed to be a
19 direct transmission. In this case, the APSDE shall pass it directly to the NHLE.
20
If the APSDE of the ZigBee coordinator receives a frame containing only the source endpoint with the
21
delivery mode sub-field of the frame control field set to the indirect addressing value (0x01) it shall be
22
assumed to be an indirect transmission. If the device is not a ZigBee coordinator, the frame shall be
23
discarded if the destination endpoint is not present and the delivery mode sub-field of the frame control field
24
is set to the indirect addressing value (0x01).
25
26 If the APSDE of a ZigBee coordinator receives an indirect transmission, it shall search its binding table for
27 an entry that matches the source address communicated from the NWK layer, the cluster identifier included
28 in the received frame and the source endpoint included in the frame. If a match is not found, the frame shall
29 be discarded. If a match is found, the APSDE shall build an APDU for each destination endpoint contained
30 in the matching entry in the binding table. The APSDE shall then transmit each frame using the NWK data
31 service.30
32
33 If the APSDE of a device receives a transmission, it shall pass it directly to the NHLE, unless it needs to be
34 reflected.
35
36 1.2.8.2.3 Use of acknowledgements
37
38 A data or APS command frame shall be sent with its acknowledgement request sub-field set appropriately
39 for the frame. An acknowledgement frame shall always be sent with the acknowledgement request sub-field
40 set to 0. Similarly, any frame that is broadcast shall be sent with its acknowledgement request sub-field set to
41 0.
42
43 1.2.8.2.3.1 No acknowledgement
44
A frame that is received by its intended recipient with its acknowledgement request (AR) sub-field set to 0
45
shall not be acknowledged. The originating device shall assume that the transmission of the frame was
46
successful. Figure 11 shows the scenario for transmitting a single frame of data from an originator to a
47
recipient without requiring an acknowledgement. In this case, the originator transmits the data frame with
48
the AR sub-field equal to 0.
49
50
51
52
53 29CCB Comment #173, 210
30
54 CCB Comment #210

1
2
Originator Recipient 3
next higher Originator Recipient next higher 4
layer APS APS layer 5
APSDE-DATA.request (AR=0) 6
Data (AR=0) 7
APSDE-DATA.confirm APSDE-DATA.indication 8
9
10
11
12
13
14
Figure 11 Successful data transmission without an acknowledgement 15
16
1.2.8.2.3.2 Acknowledgement 17
18
A frame that is received by its intended recipient with its acknowledgement request (AR) sub-field set to 1
19
shall be acknowledged. If the intended recipient correctly receives the frame, it shall generate and send an
20
acknowledgement frame to the originator of the frame that is being acknowledged.
21
If the original transmission used indirect addressing, then the ZigBee coordinator shall send an 22
acknowledgement to the originator, and then for each reflected message shall indicate to the recipient that it 23
requires an acknowledgement by transmitting the data frame with the acknowledgement request sub-field of 24
the frame control field set to 1.31 25
26
The transmission of an acknowledgement frame shall commence when the APS sub-layer determines that 27
the frame is valid. 28
29
Figure 12 shows the scenario for transmitting a single frame of data from an originator to a recipient with an 30
acknowledgement. In this case, the originator indicates to the recipient that it requires an acknowledgement 31
by transmitting the data frame with the AR sub-field set to 1. 32
33
34
Originator Recipient 35
next higher Originator Recipient next higher 36
layer APS APS layer 37
38
APSDE-DATA.request (AR=1) 39
Data (AR=1) 40
41
42
43
Acknowldgement
APSDE-DATA.indication 44
45
APSDE-DATA.confirm 46
47
48
49
50
Figure 12 Successful data transmission with an acknowledgement 51
52
53
31
CCB Comment #215 54

1 1.2.8.2.4 Retransmissions
2
3 A device that sends a frame with its acknowledgement request sub-field set to 0 shall assume that the
4 transmission was successfully received and shall hence not perform the retransmission procedure.
5
A device that sends a frame with its acknowledgement request sub-field set to 1 shall wait for at most
6
apscAckWaitDuration seconds for the corresponding acknowledgement frame to be received.
7
8 If an acknowledgement frame is received within apscAckWaitDuration seconds containing the same cluster
9 identifier and has a source endpoint equal to the destination endpoint to which the original frame was
10 transmitted, the transmission shall be considered successful and no further action shall be taken by the
11 device. If an acknowledgement is not received within apscAckWaitDuration seconds or an
12 acknowledgement is received within apscAckWaitDuration seconds but contains an unexpected cluster
13 identifier or has a source endpoint that is not equal to the destination endpoint to which the original frame
14 was transmitted, the device shall conclude that the single transmission attempt has failed.
15
16 If a single transmission attempt has failed, the device shall repeat the process of transmitting the frame and
17 waiting for the acknowledgement, up to a maximum of apscMaxFrameRetries times. If an
18 acknowledgement is still not received after apscMaxFrameRetries retransmissions, the APS sub-layer shall
19 assume the transmission has failed and notify the next higher layer of the failure.
20
21
22 1.3 The ZigBee application framework
23
24
25 1.3.1 Creating a ZigBee profile
26
27 The key to communicating between devices on a ZigBee network is agreement on a profile.
28
An example of a profile would be home control lighting. This initial ZigBee profile permits a series of
29
(initially) six device types to exchange control messages to form a wireless home automation application.
30
These devices are architected to exchange well known messages (using the KVP service type) to effect
31
control such as turning a lamp on or off, sending a light sensor measurement to a lighting controller or
32
sending an alert message if an occupancy sensor detects movement.
33
34 Another example of a profile is the device profile that defines common actions between ZigBee devices. To
35 illustrate, wireless networks rely on the ability for autonomous devices to join a network and discover other
36 devices and services on devices within the network. Device and service discovery are features supported
37 within the device profile using the MSG service type.
38
39 1.3.1.1 Getting a profile identifier from the ZigBee Alliance
40
41 ZigBee defines profiles in generally three separate classes: private, published and public. The exact
42 definition and criteria for these classes are an administrative issue within the ZigBee Alliance and outside
43 the scope of this document. For the purposes of this technical specification, the only criterion is for profile
44 identifiers to be unique. To that end, every profile effort must start with a request to the ZigBee Alliance for
45 allocation of a profile identifier. Once the profile identifier is obtained, that profile identifier permits the
46 profile designer to define the following:
47
48 — Device descriptions
49 — Cluster identifiers
50
51 — Service types (KVP or MSG)
52
The application of profile identifiers to market space is a key criterion for issuance of a profile identifier
53
from the ZigBee Alliance. The profile needs to cover a broad enough range of devices to permit
54

interoperability to occur between devices without being overly broad and resulting in a shortage of cluster 1
identifiers to describe their interfaces. Conversely, the profile cannot be defined to be too narrow resulting in 2
many devices described by individual profile identifiers resulting in a waste of the profile identifier 3
addressing space and interoperability issues in describing how the devices are interfaced. Policy groups 4
within the ZigBee Alliance will establish criteria on how profiles are to be defined and to help requestors 5
tailor their profile identifier requests. 6
7
1.3.1.2 Defining device descriptions and clusters 8
9
The profile identifier is the main enumeration feature within the ZigBee protocol. Each unique profile 10
identifier defines an associated enumeration of device descriptions and cluster identifiers. For example, for 11
profile identifier “1”, there exists a pool of device descriptions described by a 16-bit value (meaning there 12
are 65,536 possible device descriptions within each profile) and a pool of cluster identifiers described by an 13
8-bit value (meaning there are 256 possible cluster identifiers within each profile). For the KVP service type, 14
each cluster identifier also supports a pool of attributes described by a 16-bit value (meaning, each profile 15
identifier has 256 cluster identifiers and each of those cluster identifiers contains up to 65,536 attributes). It 16
is the responsibility of the profile developer to define and allocate device descriptions, cluster identifiers and 17
attributes within their allocated profile identifier. Note that the definition of device descriptions, cluster 18
identifiers and attribute identifiers must be undertaken with care to ensure efficient creation of simple 19
descriptors and simplified processing when exchanging messages. 20
21
Device descriptions and cluster identifiers must be accompanied by knowledge of the profile identifier to be
22
processed. Prior to any messages being directed to a device, it is assumed by the ZigBee protocol that
23
service discovery has been employed to determine profile support on devices and endpoints. Likewise, the
24
binding process assumes similar service discovery and profile matching has occurred since the resulting
25
match is distilled to source address, source endpoint, cluster identifier, destination address and destination
26
endpoint.
27
28
1.3.1.3 Deploying the profile on endpoints
29
A single ZigBee device may contain support for many profiles, provide for subsets of various cluster 30
identifiers defined within those profiles and may support multiple device descriptions. This capability is 31
defined using a hierarchy of addressing within the device as follows: 32
33
— Device – the entire device is supported by a single radio with a unique IEEE and NWK address. 34
35
— Endpoints – this is an 8-bit field that describes different applications that are supported by a single
36
radio. Endpoint 0x00 is used to address the device profile, which each ZigBee device must employ,
37
endpoint 0xff is used to address all active endpoints (the broadcast endpoint) and endpoints 0xf1-
38
0xfe are reserved. Consequently, a single physical ZigBee radio can support up to 240 applications
39
on endpoints 0x01-0xf0.
40
It is an application decision as to how to deploy applications on a device endpoint and which endpoints to 41
advertise. The only requirement is that simple descriptors be created for each endpoint and those descriptors 42
made available for service discovery. 43
44
1.3.1.4 Enabling service discovery 45
46
Once a device is created to support specific profiles and made consistent with cluster identifier usage for 47
device descriptions within those profiles, the applications can be deployed. To do this, each application is 48
assigned to individual endpoints and each described using simple descriptors. It is via the simple descriptors 49
and other service discovery mechanisms described in the ZigBee device profile that service discovery is 50
enabled, binding of devices is supported and application messaging between complementary devices 51
facilitated. 52
53
54

1 One important point is that service discovery is made on the basis of profile identifier, input cluster identifier
2 list and output cluster identifier list (device description is notably missing). The device description is simply
3 a convention for specifying mandatory and optional cluster identifier support within devices of that type for
4 the indicated profile. Additionally, it is expected that the device description enumeration would be employed
5 within PDAs or other assisted binding devices to provide external descriptions of device capabilities.
6
7 1.3.1.5 Mixing standard and proprietary profiles
8
9 As an example, a ZigBee device could be created with a single endpoint application written for a standard,
10 published ZigBee profile identifier “XX”. If a manufacturer wanted to deploy a ZigBee device supporting
11 the standard profile “XX” and also provide vendor specific extensions, these extensions would be advertised
12 on a separate endpoint. Devices that support the standard profile identifier “XX” but not manufactured with
13 the vendor extensions, would only advertise support for the single profile identifier “XX” and could not
14 respond to or create messages using the vendor extensions.
15
16 1.3.1.6 Enabling backward compatibility
17
In the previous example, a device is created using a standard, published ZigBee profile identifier “XX”
18
which contains the initial version of the standard profile. If the ZigBee Alliance were to update this standard
19
profile to create new features and additions, the revisions would be incorporated into a new standard profile
20
with a new profile identifier (say “XY”). Devices manufactured with just profile identifier “XX” would be
21
backward compatible with newer devices manufactured later by having the newer devices advertise support
22
for both profile identifier “XX” and profile identifier “XY”. In this manner, the newer device may
23
communicate with older devices using profile identifier “XX”, however, also communicate with newer
24
devices using profile identifier “XY” from within the same application. The service discovery feature within
25
ZigBee enables devices on the network to determine the level of support.
26
27
28 1.3.2 Standard data type formats
29
30 ZigBee devices, such as thermostats, lamps, etc, are defined in terms of the attributes they contain, which
31 can be written, read or reported using the set, get and event commands using the KVP service type or
32 combined into application specific messages via the MSG service type. This section describes the data types
33 and formats used for these attributes. Note that the individual device descriptions show valid values, ranges,
34 and units for the attributes they represent.
35
36 ZigBee defines the standard data types listed in Table 19 and described in the following sub-clauses. In a
37 KVP command frame, the attribute data type field (see sub-clause 1.3.4.5.1.2) shall contain the appropriate
38 value of the data type identifier as listed in Table 19 that represents the data type of the attribute being
39 referred to.
40 Table 19 ZigBee standard data types
41
Data type identifier
42 Data type Length of data (octets)
b3b2b1b0
43
44 0000 No data 0
45
46 0001 Unsigned 8-bit integer 1
47 0010 Signed 8-bit integer 1
48
49 0011 Unsigned 16-bit integer 2
50
0100 Signed 16-bit integer 2
51
52 0101 – 1010 Reserved -
53
1011 Semi-precision 2
54

Table 19 ZigBee standard data types 1

2
1100 Absolute time 4
3
1101 Relative time 4 4
5
1110 Character string Defined in first octet 6
1111 Octet string Defined in first octet 7
8
9
1.3.2.1 No data type 10
11
The no data type is a special type to represent an attribute with no associated data. 12
13
1.3.2.2 Unsigned 8-bit integer 14
15
This is an unsigned 8-bit representation. The range is 0 - 255.
16
17
1.3.2.3 Signed 8-bit integer
18
This is an 8-bit twos complement representation. The range is –128 to +127. 19
20
1.3.2.4 Unsigned 16-bit integer 21
22
This is an unsigned 16-bit number. The range is 0 - 65535 and the minimum resolution is fixed at 1-bit. 23
24
1.3.2.5 Signed 16-bit integer 25
26
This is a 16-bit twos complement number. The range is – 32768 to + 32767 and the minimum resolution is 27
fixed at 1-bit. 28
29
1.3.2.6 Semi-precision number 30
31
Some values, such as light level, have a very wide range. In this case, if the ambient light level is 1 Lux, the
32
eye is very sensitive to an increase of light level by 1 Lux. However, if the ambient level is 100 Lux, an
33
increase of 1 Lux is not noticeable. These values are best represented using the ZigBee semi-precision
34
number, which allows the resolution to track the value being represented.
35
The ZigBee semi-precision number format is based on the IEEE 754 standard for binary floating-point 36
arithmetic. This number format should be used very sparingly, when absolutely necessary, keeping in mind 37
the code and processing required supporting it. 38
39
The value is calculated as: 40
41
Value = -1Sign * (Hidden + Mantissa/1024) * 2 (Exponent-15) 42
43
44
45
46
Sign Exponent Hidden Mantissa 47
S E4 E3 E2 E1 E0 H . M9 M8 M7 M6 M5 M4 M3 M2 M1 M0 48
49
bit 15 10 9 0 50
51
Figure 13 – Format of the ZigBee semi-precision number 52
53
Note: The transmission order for the format in Figure 13 is bit 0 first. 54

1 For normalized numbers (>2-14), the hidden bit = 1 and the resolution is constant at 11 bits (1 in 2048).
2
3 For un-normalized numbers, the hidden bit = 0. Note that this does not maintain 11-bit resolution and that
4 the resolution becomes coarser as the number gets smaller.
5
The hidden bit is not sent over the link. It shall have the value ‘1’ (i.e. normalized) in order to be classified as
6
a ZigBee semi-precision number.
7
8 The sign bit is set to 0 for positive values, 1 for negative.
9
10 The exponent is 5 bits. The actual exponent of 2 is calculated as (exponent – 15).
11
12 Certain values are reserved for specific purposes:
13
— Not a Number: this is used for undefined values (e.g. at switch-on and before initialization) and is
14
indicated by an exponent of 31 with a non-zero mantissa.
15
16 — Infinity: this is indicated by an exponent of 31 and a zero mantissa. The sign bit indicates whether
17 this represents + infinity or – infinity, the figure of 0x7c00 representing + ∞ and 0xfc00 representing
18 - ∞.
19
— Zero: this is indicated by both a zero exponent and zero mantissa. The sign bit indicates whether this
20
is + or – zero, the value 0x0000 representing +zero and 0x8000 representing –zero.
21
22 — Un-normalised numbers: numbers <2-14 are indicated by a value of 0 for the exponent. The hidden
23 bit is set to zero.
24
25 The maximum value represented by the mantissa is 0x3ff / 1024. The largest number that can be represented
26 is therefore:
27
28 -1Sign * (1 +1023/1024) * 2 (30 -15) = ± 1.9990234 * 32768 = ± 65504
29
30 Certain applications may choose to scale this value to allow representation of larger values (with a
31 correspondingly more coarse resolution). For details, see the relevant device descriptions.
32
For example, a value of +2 is represented by +2(16-15) * 1.0 = 0x4000, while a value of –2 is represented by
33
0xc000.
34
35 Similarly, a value of +0.625 is represented by +2(17-15) * 1.625 = 0x4680, while –0.625 is represented by
36 0xc680.
37
38 1.3.2.7 Absolute time
39
40 This is an unsigned 32-bit integer representation for absolute time. Absolute time is measured in seconds
41 from midnight, 1st January 2000.
42
43 1.3.2.8 Relative time
44
45 This is an unsigned 32-bit integer representation for relative time. Relative time is measured in milliseconds.
46
47
48
49
50
51
52
53
54

1.3.2.9 Character string 1

2
The character string data type contains data octets encoding characters according to the language and 3
character set field of the complex descriptor. The character string data type shall be formatted as illustrated 4
in Table 13. 5
6
7
Octets: 1 Variable
8
9
Character count Character data
10
11
Figure 13 Format of the character string type 12
13
The character count sub-field is one octet in length and specifies the number of characters, encoded 14
according to the language and character set field of the complex descriptor (see sub-clause 1.3.3.7.1), 15
contained in the character data sub-field. 16
The character data sub-field is e*n octets in length, where e is the size of the character, as specified by the 17
language and character set field of the complex descriptor, and n is the value of the character count sub-field. 18
This sub-field contains the encoded characters that comprise the desired character string. 19
20
1.3.2.10 Octet string 21
22
The octet string data type contains data in an application-defined format, not defined in this specification. 23
The octet string data type shall be formatted as illustrated in Figure 14. 24
25
26
Octets: 1 Variable 27
28
Octet count Octet data 29
30
Figure 14 Format of the octet string type 31
32
The octet count sub-field is one octet in length and specifies the number of octets contained in the freeform 33
data sub-field. 34
35
The octet data sub-field is n octets in length, where n is the value of the octet count sub-field. This sub-field 36
contains the application-defined data. 37
38
1.3.3 ZigBee descriptors 39
40
ZigBee devices describe themselves using descriptor data structures. The actual data contained in these 41
descriptors is defined in the individual device descriptions. There are five descriptors: node, node power, 42
simple, complex and user, shown in Table 20. 43
44
Table 20 ZigBee descriptors 45
Descriptor name Status Description 46
47
Node M Type and capabilities of the node
48
Node power M Node power characteristics 49
50
Simple M Device descriptions contained in node
51
Complex O Further information about the device descriptions 52
53
User O User-definable descriptor 54

1 1.3.3.1 Transmission of descriptors

2
3 The node, node power, simple and user descriptors shall be transmitted in the order that they appear in their
4 respective tables, i.e. the field at the top of the table is transmitted first and the field at the bottom of the table
5 is transmitted last. Each individual field shall follow the transmission order specified in “Transmission
6 order” on page 20.
7
The complex descriptor shall be formatted and transmitted as illustrated in Figure 15.
8
9
10 Octets: 1 Variable … Variable
11
12 Field count Field 1 … Field n
13
14
15 Figure 15 Format of the complex descriptor
16 Each field included in the complex descriptor shall be formatted as illustrated in Figure 16.
17
18
19 Octets: 1 Variable
20
21 Compressed
Field data
22 XML tag
23
24 Figure 16 Format of an individual complex descriptor field
25
26 1.3.3.1.1 Field count field
27
28 The field count field is one octet in length and specifies the number of fields included in the descriptor, each
29 formatted as illustrated in Figure 16.
30
31 1.3.3.1.1.1 Compressed XML tag field
32
The compressed XML tag field is one octet in length and specifies the XML tag for the current field. The
33
compressed XML tags for the complex descriptor are listed in Table 32.
34
35
1.3.3.1.1.2 Field data field
36
37 The field data field has a variable length and contains the information specific to the current field, as
38 indicated by the compressed XML tag field.
39
40 1.3.3.2 Discovery via descriptors
41
42 Descriptor information is queried in the ZDO management entity device and service discovery using the
43 ZigBee device profile request primitive addressed to endpoint 0. For details of the discovery operation, see
44 sub-clause 1.1.5. Information is returned via the ZigBee device profile indication primitive.
45
46 The node and node power descriptors apply to the complete node. The other descriptors must be specified
47 for each endpoint defined in the node. If a node contains multiple subunits, these will be on separate
48 endpoints and the specific descriptors for these endpoints are read by including the relevant endpoint
49 number in the ZigBee device profile primitive.
50
51
52
53
54

1.3.3.3 Composite devices 1

2
A ZigBee node may contain a number of separate subunits, each of which has its own simple, complex or 3
user descriptors. The mechanism for discovering this is described in ZigBee device profile service discovery 4
section. 5
6
1.3.3.4 Node descriptor 7
8
The node descriptor contains information about the capabilities of the ZigBee node and is mandatory for
9
each node. There shall be only one node descriptor in a node.
10
The fields of the node descriptor are shown in Table 21 in their order of transmission. 11
12
Table 21 Fields of the node descriptor 13
Field name Length (bits) 14
15
Logical type 3
16
Reserved 5 17
18
APS flags 3 19
Frequency band 5 20
21
MAC capability flags 8 22
23
Manufacturer code 16
24
Maximum buffer size 8 25
26
Maximum transfer size 16 27
28
29
1.3.3.4.1 Logical type field 30
The logical type field of the node descriptor is three bits in length and specifies the device type of the ZigBee 31
node. The logical type field shall be set to one of the non-reserved values listed in Table 22. 32
33
Table 22 Values of the logical type field 34
Logical type value 35
Description 36
b2b1b0
37
000 ZigBee coordinator 38
001 ZigBee router 39
40
010 ZigBee end device 41
42
011-111 Reserved
43
44
1.3.3.4.2 APS flags field 45
46
The APS flags field of the node descriptor is three bits in length and specifies the application support sub- 47
layer capabilities of the node. 48
49
This field is currently not supported and shall be set to zero. 50
51
52
53
54

1 1.3.3.4.3 Frequency band field

2
3 The frequency band field of the node descriptor is five bits in length and specifies the frequency bands that
4 are supported by the underlying IEEE 802.15.4 radio utilized by the node. For each frequency band
5 supported by the underlying IEEE 802.15.4 radio, the corresponding bit of the frequency band field, as listed
6 in Table 23, shall be set to 1. All other bits shall be set to 0.
7 Table 23 Values of the frequency band field
8
9 Frequency band Supported frequency
field bit number band
10
11 0 868 – 868.6 MHz
12
1 Reserved
13
14 2 902 – 928 MHz
15
16 3 2400 – 2483.5 MHz
17 4 Reserved
18
19
20 1.3.3.4.4 MAC capability flags field
21
22 The MAC capability flags field is eight bits in length and specifies the node capabilities, as required by the
23 IEEE 802.15.4 MAC sub-layer [B1]. The MAC capability flags field shall be formatted as illustrated in
24 Figure 17.
25
26
Bits: 0 1 2 3 4-5 6 7
27
28 Alternate
Power Receiver on Security
29 PAN coordi- Device type Reserved Reserved
source when idle capability
nator
30
31
32 Figure 17 Format of the MAC capability flags field
33
The alternate PAN coordinator sub-field is one bit in length and shall be set to 1 if this node is capable of
34
becoming a PAN coordinator. Otherwise the alternative PAN coordinator sub-field shall be set to 0.
35
36 The device type sub-field is one bit in length and shall be set to 1 if this node is a full function device (FFD).
37 Otherwise the device type sub-field shall be set to 0, indicating a reduced function device (RFD).
38
39 The power source sub-field is one bit in length and shall be set to 1 if the current power source is mains
40 power. Otherwise the power source sub-field shall be set to 0. This information is derived from the node
41 current power source field of the node power descriptor.
42
43 The receiver on when idle sub-field is one bit in length and shall be set to 1 if the device does not disable its
44 receiver to conserve power during idle periods. Otherwise the receiver on when idle sub-field shall be set to
45 0 (see also sub-clause 1.3.3.5.)
46
The security capability sub-field is one bit in length and shall be set to 1 if the device is capable of sending
47
and receiving frames secured using the security suite specified in [B1]. Otherwise the security capability
48
sub-field shall be set to 0.
49
50
1.3.3.4.5 Manufacturer code field
51
52 The manufacturer code field of the node descriptor is sixteen bits in length and specifies a manufacturer
53 code that is allocated by the ZigBee Alliance, relating the manufacturer to the device.
54

1.3.3.4.6 Maximum buffer size field 1

2
The maximum buffer size field of the node descriptor is eight bits in length, with a valid range of 0x00-0x7f, 3
and specifies the maximum size, in octets, of the application support sub-layer data unit (ASDU) for this 4
node. This is the maximum size of data or commands passed to or from the application by the application 5
support sub-layer, before any fragmentation or re-assembly (fragmentation is not currently supported). 6
7
This field can be used as a high level indication for network management.
8
9
1.3.3.4.7 Maximum transfer size field
10
The maximum transfer size field of the node descriptor is sixteen bits in length, with a valid range of 11
0x0000-0x7fff, and specifies the maximum size, in octets, that can be transferred to or from this node in one 12
single message transfer. This value can exceed the value of the node maximum buffer size field (see sub- 13
clause 1.3.3.4.6). 14
15
This field is currently not supported and shall be set to zero. 16
17
1.3.3.5 Node power descriptor 18
19
The node power descriptor gives a dynamic indication of the power status of the node and is mandatory for 20
each node. There shall be only one node power descriptor in a node. 21
22
The fields of the node power descriptor are shown in Table 24 in the order of their transmission.
23
Table 24 Fields of the node power descriptor 24
25
Field name Length (bits)
26
Current power mode 4 27
28
Available power sources 4
29
Current power source 4 30
31
Current power source level 4
32
33
34
1.3.3.5.1 Current power mode field
35
The current power mode field of the node power descriptor is four bits in length and specifies the current 36
sleep/power-saving mode of the node. The current power mode field shall be set to one of the non-reserved 37
values listed in Table 25. 38
39
Table 25 Values of the current power mode field 40
Current power mode value 41
Description 42
b3b2b1b0
43
Receiver synchronized with the receiver on when idle sub-field of 44
0000
the node descriptor.
45
Receiver comes on periodically as defined by the node power 46
0001
descriptor. 47
48
Receiver comes on when stimulated, e.g. by a user pressing a but-
0010 49
ton.
50
0011-1111 Reserved 51
52
53
54

1 1.3.3.5.2 Available power sources field

2
3 The available power sources field of the node power descriptor is four bits in length and specifies the power
4 sources available on this node. For each power source supported on this node, the corresponding bit of the
5 available power sources field, as listed in Table 26, shall be set to 1. All other bits shall be set to 0.
6 Table 26 Values of the available power sources field
7
8 Available power sources
Supported power source
field bit number
9
10 0 Constant (mains) power
11
1 Rechargeable battery
12
13 2 Disposable battery
14
15 3 Reserved
16
17
18 1.3.3.5.3 Current power source field
19
The current power source field of the node power descriptor is four bits in length and specifies the current
20
power source being utilized by the node. For the current power source selected, the corresponding bit of the
21
current power source field, as listed in Table 27, shall be set to 1. All other bits shall be set to 0.
22
23 Table 27 Values of the current power sources field
24 Current power source
field bit number
26
27 0 Constant (mains) power
28 1 Rechargeable battery
29
30 2 Disposable battery
31
3 Reserved
32
33
34 1.3.3.5.4 Current power source level field
35
36 The current power source level field of the node power descriptor is four bits in length and specifies the level
37 of charge of the power source. The current power source level field shall be set to one of the non-reserved
38 values listed in Table 28.
39
40 Table 28 Values of the current power source level field
Charge level
42 level field b3b2b1b0
43
0000 Critical
44
45 0100 33%
46
47 1000 66%
48 1100 100%
49
50 All other values Reserved
51
52
53
54

1.3.3.6 Simple descriptor 1

2
The simple descriptor contains information specific to each endpoint contained in this node. The simple 3
descriptor is mandatory for each endpoint present in the node. 4
5
The fields of the simple descriptor are shown in Table 29 in their order of transmission. As this descriptor
6
needs to be transmitted over air, the overall length of the simple descriptor shall be less than or equal to
7
maxCommandSize.
8
Table 29 Fields of the simple descriptor 9
10
Field name Length (bits)
11
Endpoint 8 12
13
Application profile identifier 16
14
Application device identifier 16 15
16
Application device version 4
17
Application flags 4 18
19
Application input cluster count 8 20
8*i (where i is the value of the application 21
Application input cluster list 22
input cluster count)
23
Application output cluster count 8 24
8*o (where o is the value of the applica- 25
Application output cluster list 26
tion input cluster count)
27
28
1.3.3.6.1 Endpoint field 29
30
The endpoint field of the simple descriptor is eight bits in length and specifies the endpoint within the node 31
to which this description refers. Applications shall only use endpoints 1-240. 32
33
1.3.3.6.2 Application profile identifier field 34
35
The application profile identifier field of the simple descriptor is sixteen bits in length and specifies the 36
profile that is supported on this endpoint. Profile identifiers shall be obtained from the ZigBee Alliance. 37
38
1.3.3.6.3 Application device identifier field 39
The application device identifier field of the simple descriptor is sixteen bits in length and specifies the 40
device description supported on this endpoint. Device description identifiers shall be obtained from the 41
ZigBee Alliance. 42
43
44
45
46
47
48
49
50
51
52
53
54

1 1.3.3.6.4 Application device version field

2
3 The application device version field of the simple descriptor is four bits in length and specifies the version of
4 the device description supported on this endpoint. The application device version field shall be set to one of
5 the non-reserved values listed in Table 30.
6 Table 30 Values of the application device version field
7
8 Application device version value
Description
b3b2b1b0
9
10 0000 Version 1.0
11
12 0001–1111 Reserved
13
14
15 1.3.3.6.5 Application flags field
16 The application flags field of the simple descriptor is four bits in length and specifies application specific
17 flags. For each feature supported by the application on this endpoint, the corresponding bit of the application
18 flags field, as listed in Table 31, shall be set to 1. All other bits shall be set to 0.
19
20 Table 31 Values of the application flags field
21 Application flags
22 Supported feature
field bit number
23
24 0 Complex descriptor available
25 1 User descriptor available
26
27 2-3 Reserved
28
29
30 1.3.3.6.6 Application input cluster count field
31
The application input cluster count field of the simple descriptor is eight bits in length and specifies the
32
number of input clusters, supported on this endpoint, that will appear in the application input cluster list
33
field. If the value of this field is zero, the application input cluster list field shall not be included.
34
35
1.3.3.6.7 Application input cluster list
36
37 The application input cluster list of the simple descriptor is 8*i bits in length, where i is the value of the
38 application input cluster count field, and specifies the list of input clusters supported on this endpoint, used
39 during the binding procedure.
40
41 The application input cluster list field shall be included only if the value of the application input cluster
42 count field is greater than zero.
43
44 1.3.3.6.8 Application output cluster count field
45
46 The application output cluster count field of the simple descriptor is eight bits in length and specifies the
47 number of output clusters, supported on this endpoint, that will appear in the application output cluster list
48 field. If the value of this field is zero, the application output cluster list field shall not be included.
49
50 1.3.3.6.9 Application output cluster list
51
The application output cluster list of the simple descriptor is 8*o bits in length, where o is the value of the
52
application output cluster count field, and specifies the list of output clusters supported on this endpoint,
53
used during the binding procedure.
54

The application output cluster list field shall be included only if the value of the application output cluster 1
count field is greater than zero. 2
3
1.3.3.7 Complex Descriptor 4
5
The complex descriptor contains extended information for each of the device descriptions contained in this 6
node. The use of the complex descriptor is optional. 7
8
Due to the extended and complex nature of the data in this descriptor it is presented in XML form using
9
compressed XML tags. Each field of the descriptor, shown in Table 32, can therefore be transmitted in any
10
order. As this descriptor needs to be transmitted over air, the overall length of the complex descriptor shall
11
be less than or equal to maxCommandSize.
12
Table 32 Fields of the complex descriptor 13
14
Compressed XML tag
Field name XML tag Data type 15
value b3b2b1b0
16
Reserved - 0000 - 17
18
Language and character set See sub-
<languageChar> 0001 19
clause 1.3.3.7.1.
20
Manufacturer name <manufacturerName> 0010 Character string 21
22
Model name <modelName> 0011 Character string
23
Serial number <serialNumber> 0100 Character string 24
25
Device URL <deviceURL> 0101 Character string 26
Icon <icon> 0110 Undefined 27
28
Icon URL <iconURL> 0111 Character string 29
30
Reserved - 1000 – 1111 -
31
32
1.3.3.7.1 Language and character set field 33
34
The language and character set field is three octets in length and specifies the language and character set 35
used by the character strings in the complex descriptor. The format of the language and character set field is 36
illustrated in Figure 18. 37
38
39
Octets: 2 1 40
41
Character set 42
ISO 639-1 language code
identifier
43
44
Figure 18 Format of the language and character set field 45
The ISO 639-1 language code sub-field is two octets in length and specifies the language used for character 46
strings, as defined in [B5]. 47
48
49
50
51
52
53
54

1 The character set identifier sub-field is one octet in length and specifies the encoding used by the characters
2 in the character set. This sub-field shall be set to one of the non-reserved values listed in Table 33.
3
4 Table 33 Values of the character set identifier sub-field
5 Character set Bits per
Description
6 identifier value character
7 ISO 646, ASCII character set. Each character is fitted into
8 0x00 8 the least significant 7 bits of an octet with the most signifi-
9 cant bit set to zero (see also [B6]).
10
0x01 – 0xff - Reserved
11
12
13
If the language and character sets have not been specified, the language shall default to English (language
14
code = “EN”) and the character set to ISO 646.
15
16
1.3.3.7.2 Manufacturer name field
17
18 The manufacturer name field has a variable length and contains a character string representing the name of
19 the manufacturer of the device.
20
21 1.3.3.7.3 Model name field
22
23 The model name field has a variable length and contains a character string representing the name of the
24 manufacturers model of the device.
25
26 1.3.3.7.4 Serial number field
27
28 The serial number field has a variable length and contains a character string representing the manufacturers
29 serial number of the device.
30
31 1.3.3.7.5 Device URL field
32
The device URL field has a variable length and contains a character string representing the URL through
33
which more information relating to the device can be obtained.
34
35
1.3.3.7.6 Icon field
36
37 The icon field has a variable length and contains the data for an icon that can represent the device on a
38 computer, gateway or PDA. The format of the icon data is not specified in this document.
39
40 1.3.3.7.7 Icon URL field
41
42 The icon URL field has a variable length and contains a character string representing the URL through
43 which the icon for the device can be obtained.
44
45 1.3.3.8 User descriptor
46
47 The user descriptor contains information that allows the user to identify the device using a user-friendly
48 character string, such as “Bedroom TV” or “Stairs light”. The use of the user descriptor is optional. This
49 descriptor contains a single field, which uses the character string data type (see sub-clause 1.3.2.9), and shall
50 contain a maximum of 16 characters.
51
52
53
54

The fields of the user descriptor are shown in Table 34 in the order of their transmission. 1
2
Table 34 Fields of the user descriptor 3
Field name Length (octets) 4
User description 16 5
6
7
1.3.4 AF frame formats 8
9
The general AF frame format is illustrated in Figure 19. 10
11
12
Bits: 4 4 Variable Variable Variable 13
14
Transaction 15
Frame type Transaction 1 … Transaction n
count
16
17
Figure 19 Format of the general application framework command frame 18
19
The format of each transaction i field, where 1 ≤ i ≤ n, is illustrated in Figure 20. Each transaction contains a
20
transaction header and a transaction payload, the latter composed of frame type-specific data.
21
22
Bits: 8 Variable 23
24
Transaction 25
Transaction
sequence 26
data
number 27
Transaction Transaction 28
header payload 29
30
Figure 20 Format of a transaction field 31
32
1.3.4.1 Transaction count field 33
34
The transaction count field is four bits in length and specifies the number of transactions, n, appearing in the 35
general frame, each contiguously following the frame type field. 36
37
1.3.4.2 Frame type field 38
39
The frame type field is four bits in length and specifies the service type used by each of the following 40
transactions. This field shall be set to one of the non-reserved values listed in Table 35. 41
42
Table 35 Values of the frame type field
43
Frame type value 44
Description
b3b2b1b0 45
0000 Reserved 46
47
0001 Key value pair (KVP) 48
49
0010 Message (MSG)
50
0011 – 1111 Reserved 51
52
53
54

1 1.3.4.3 Transaction sequence number field

2
3 The transaction sequence number field is eight bits in length and specifies an identification number for the
4 transaction so that a response command frame can be related to the request frame. The application object
5 itself shall maintain an 8-bit counter that is copied into this field and incremented by one for each command
6 sent. When a value of 0xff is reached, the next command shall re-start the counter with a value of 0x00.
7
If a device sends a KVP command requesting an acknowledgement, the target device shall respond with the
8
relevant response command and include the transaction sequence number contained in the original request
9
command. Similarly, this field can be used to implement acknowledged MSG commands in the same way.
10
11 The transaction sequence number field can be used by a controlling device, which may have issued multiple
12 commands, so that it can match the incoming responses to the relevant command.
13
14 1.3.4.4 Transaction data field
15
16 The transaction data field has a variable length and contains the data for the individual transaction. The
17 format and length of this field is dependent on the value of the frame type field and contains either a KVP
18 frame (see sub-clause 1.3.4.5.1) or a MSG frame (see sub-clause 1.3.4.5.2).
19
20 1.3.4.5 Format of individual frame types
21
22 There are two defined frame types: key value pair (KVP) and message (MSG). Each of these frame types is
23 discussed in the following sub-clauses.
24
25 1.3.4.5.1 Key value pair (KVP) frame format
26
The KVP frame type enables an application to manipulate attributes, defined by the application profile.
27
Attributes have a designator (the key) and an associated value, which can be set or requested using the
28
commands specified in sub-clause 1.3.5.
29
30 Commands are sent and received using the APS APSDE-DATA.request and APSDE-DATA.indication
31 primitives, through the ASDU data field, as described in sub-clause 1.2.4.1.
32
33 Commands can be sent (or received) directly to (or from) an attribute in a target using direct addressing, or
34 via the binding table, in a ZigBee coordinator, using indirect addressing. The APS cluster identifier shall
35 match the cluster that contains the attribute being manipulated. The APS security suite shall indicate which
36 security suite is required for the outgoing command.
37
38 The use of this interface changes according to the addressing method in use. More details can be found in
39 clause 1.2.
40
The KVP command frame shall be formatted as illustrated in Figure 21.
41
42
43 Bits: 4 4 16 0/8 Variable
44
45 Command Attribute data Attribute iden-
Error code Attribute data
46 type identifier type tifier
47
48 Figure 21 Format of the general KVP command frame
49
50 1.3.4.5.1.1 Command type identifier field
51
52 The command type identifier field is four bits in length and specifies the type of the command. This field
53 shall be set to one of the non-reserved values listed in Table 36. Note that for messages sent indirectly via the
54 ZigBee coordinator, only the set and event command types are permitted.32

. 1
2
Table 36 Values of the command type identifier field 3
Command type 4
identifier value Description Sub-clause 5
b3b2b1b0 6
0000 Reserved - 7
8
0001 Set 1.3.5.3 9
10
0010 Event 1.3.5.5
11
0011 Reserved - 12
13
0100 Get with acknowledgement 1.3.5.1 14
0101 Set with acknowledgement 1.3.5.3 15
16
0110 Event with acknowledgement 1.3.5.5 17
18
0111 Reserved -
19
1000 Get response 1.3.5.2 20
21
1001 Set response 1.3.5.4
22
1010 Event response 1.3.5.6 23
24
1011 – 1111 Reserved - 25
26
27
1.3.4.5.1.2 Attribute data type field 28
The attribute data type field is four bits in length and specifies the type of the data in the attribute data field. 29
This field shall be set to one of the non-reserved values listed in Table 19. The length of the attribute data 30
field is either implied directly from the type or specified in the first octet of the attribute data field. 31
32
For more details of the available data types, see sub-clause 1.3.2. 33
34
1.3.4.5.1.3 Attribute identifier field 35
36
The attribute identifier field is sixteen bits in length and specifies the attribute within the target device on 37
which the command is to operate. The value of this field is defined in the relevant device description. 38
39
1.3.4.5.1.4 Error code field 40
41
The error code field is eight bits in length and specifies the status of a transaction. This field, included only 42
in response commands, shall be set to one of the non-reserved values listed in Table 37. 43
Table 37 Values of the error code field 44
45
Error code value Description
46
0x00 Success 47
48
0x01 Invalid endpoint
49
0x02 Reserved 50
51
52
53
32
CCB Comment #232 54

1 Table 37 Values of the error code field

2
0x03 Unsupported attribute
3
4 0x04 Invalid command type
5
6 0x05 Invalid attribute data length
7 0x06 Invalid attribute data
8
9 0x07 – 0x0f Reserved
10
0x10-0xff Application defined error
11
12
13 Note that other errors, such as invalid security suite or cluster identifier are signaled by the APS directly. For
14 further details, see clause 1.2.
15
16 1.3.4.5.1.5 Attribute data field
17
18 The attribute data field has a variable length and contains information specific to the attribute referenced in
19 the attribute identifier field. This field is dependent on the particular command, the data type of the attribute
20 and the device description.
21
22 If not defined directly by the data type of the attribute being referred to, the length of this field shall be such
23 that the length of the entire command frame is less than or equal to maxCommandSize, unless both source
24 and destination support fragmentation.
25
For details, see the individual commands in the following sections.
26
27
1.3.4.5.2 MSG frame format
28
29 The MSG frame type enables an application profile to work with free form frame formats, defined by the
30 application profile itself. This allows applications, which do not easily fit into the KVP structure, the
31 flexibility to define commands, which better suit its needs.
32
33 MSG frames are sent using the APS APSDE-DATA.request primitive and received via the APSDE
34 DATA.indication primitive as described in sub-clause 1.2.4.1.
35
36 The application object uses device descriptions to define the service type, and hence the frame type which
37 supports the service, for each cluster. For MSG frames, the device description is also responsible for
38 defining the usage of the message.
39
An MSG transaction frame shall be formatted as illustrated in Figure 22.
40
41
42 Bits: 8 Variable
43
44 Transaction Transaction
45 length data
46
47 Figure 22 Format of the MSG transaction frame
48
49 The MSG transaction frame does not implicitly support application level acknowledgements or command
50 aggregation but is instead of free form frame for transporting data for messages defined in an application
51 profile.
52
53
54

1.3.4.5.2.1 Transaction length field 1

2
The transaction length field is eight bits in length and specifies the number of octets contained in the 3
following transaction data field. 4
5
1.3.4.5.2.2 Transaction data field 6
7
The transaction data field has a variable length, which shall be less than or equal to maxCommandSize,
8
unless both source and destination support fragmentation, and contains message specific information,
9
defined in a particular application profile.
10
11
1.3.5 KVP command frames 12
13
The following KVP commands are supported: 14
15
— Set, set with acknowledgement and get with acknowledgement commands for manipulating attribute 16
values. 17
— Set response and get response command replies initiated by the reception of the set with acknowl- 18
edgement and get with acknowledgement commands, respectively. 19
20
— Event and event with acknowledgement commands for informing another device that the value of an 21
attribute has changed value. 22
— Event response command reply initiated by the reception of the event with acknowledgement com- 23
mand. 24
25
— Aggregations of the above commands for attributes within the same cluster. Aggregation is not cur- 26
rently supported. 27
28
The command format uses compressed XML (extensible markup language) based on WBXML (WAP
29
Binary XML). In this compressed format, textual tags are compressed into a single octet tokenized format.
30
Using the schemas in Annex F, the compressed XML can be inflated to a full textual XML description for
31
use in other systems. It is not expected that uncompressed XML is sent over the ZigBee radio link in normal
32
operation.
33
The set and event commands can be sent with an optional application level acknowledgement, allowing the 34
originator to confirm that a command was actually received by the recipient. There is no get command 35
available without an acknowledgement since the transaction naturally requires a response. Note that for 36
messages sent indirectly via the ZigBee coordinator, only the set and event command types are permitted.33 37
38
1.3.5.1 Get with acknowledgement command frame 39
40
The get with acknowledgement command frame shall be formatted as illustrated in Figure 23. 41
42
43
Bits: 8 4 4 16 44
45
Transaction
Command Attribute data Attribute iden- 46
sequence
type identifier type tifier 47
number
48
Transaction 49
Transaction payload
header
50
51
Figure 23 Format of the get with acknowledgement command frame 52
53
33
CCB Comment #232 54

1 1.3.5.1.1 When generated

2
3 The get with acknowledgement command frame is generated when a device wishes to read an attribute value
4 from another device.
5
The transaction sequence number shall be set to the next value of the sequence number maintained by the
6
application. The command type identifier field shall be set to 0100 (binary). The attribute data type shall be
7
set to the type of the attribute being requested. The attribute identifier field shall contain the identifier of the
8
attribute being requested.
9
10
1.3.5.1.2 Effect on receipt
11
12 On receipt of the get with acknowledgement command frame, the recipient device shall determine whether it
13 defines the requested attribute. If not, the recipient device shall generate and send a get response command
14 frame back to the originator with the error code field set to an appropriate value that indicates the error. If the
15 attribute is defined, the recipient device shall generate and send a get response command frame back to the
16 recipient with the requested attribute data.
17
18 1.3.5.2 Get response command frame
19
20 The get response command frame shall be formatted as illustrated in Figure 24.
21
22
23 Bits: 8 4 4 16 8 Variable
24
Transaction
25 Command Attribute data Attribute
sequence Error code Attribute data
26 type identifier type identifier
number
27
28 Transaction
Transaction payload
29 header
30
31 Figure 24 Format of the get response command frame
32
34
35 The get response command frame is generated in response to the reception of a get with acknowledgement
36 command frame.
37 The transaction sequence number shall be set to value of the transaction sequence number sent with the get
38 with acknowledgement command frame. The command type identifier field shall be set to 1000 (binary).
39 The attribute data type shall be set to the type of the attribute being requested. The attribute identifier field
40 shall contain the identifier of the attribute being requested.
41
42 If the requested attribute was defined and the get with acknowledgement command frame contained no
43 errors, the error code field shall contain 0x00, indicating a successful request. Otherwise, the error code field
44 shall be set to one of the non-reserved values listed in Table 37.
45
46 The attribute data field shall contain the value of the attribute requested in the attribute identifier field and
47 shall be a whole number of octets in the specified data type format. If the length of this field is not defined
48 directly by the data type of the attribute being referred to, the first octet shall contain the length, in octets, of
49 the rest of the data (see also Table 19). The actual meaning of the data is specified in the relevant device
50 description.
51
52
53
54

1.3.5.2.2 Effect on receipt 1

2
On receipt of the get response command frame, the originator is notified of the success of their request to 3
read the value of an attribute. If the error code field contains 0x00, the transaction was successful and the 4
attribute value can be used. If the error code field does not contain the value 0x00, the transaction was 5
unsuccessful. 6
7
1.3.5.3 Set/set with acknowledgement command frame 8
9
The set and set with acknowledgement command frames shall be formatted as illustrated in Figure 25.
10
11
Bits: 8 4 4 16 Variable 12
13
Transaction 14
Command Attribute data Attribute
sequence Attribute data 15
type identifier type identifier
number 16
Transaction 17
Transaction payload 18
header
19
Figure 25 Format of the set/set with acknowledgement command frame 20
21
1.3.5.3.1 When generated 22
23
The set and set with acknowledgement command frames are generated when a device wishes to write an 24
attribute value to another device. The set with acknowledgement command frame is used when a response is 25
required from the recipient. 26
27
The transaction sequence number shall be set to the next value of the sequence number maintained by the 28
application. The command type identifier field shall be set to 0001 or 0101 (binary), for the set or set with 29
acknowledgement command frames, respectively. The attribute data type shall be set to the type of the 30
attribute being written. The attribute identifier field shall contain the identifier of the attribute being written. 31
32
The attribute data field shall contain the value to write to the attribute requested in the attribute identifier 33
field and shall be a whole number of octets in the specified data format. If the length of this field is not 34
defined directly by the data type of the attribute being referred to, the first octet shall contain the length, in 35
octets, of the rest of the data (see also Table 19). The actual meaning of the data is specified in the relevant 36
device description. 37
38
On receipt of the set command frame, the recipient device shall determine whether it defines the requested 40
attribute. If not, the recipient device shall ignore the command. If the attribute is defined, the recipient 41
device shall write the data in the attribute data field to the attribute specified in the attribute identifier field. 42
43
On receipt of the set with acknowledgement command frame, the recipient device shall determine whether it 44
defines the requested attribute. If not, the recipient device shall generate and send a set response command 45
frame back to the originator with the error code field set to an appropriate value that indicates the error. If the 46
attribute is defined, the recipient device shall write the data in the attribute data field to the attribute 47
specified in the attribute identifier field. It shall then generate and send a set response command frame back 48
to the recipient with a suitable error code. 49
50
51
52
53
54

1 1.3.5.4 Set response command frame

2
3 The set response command frame shall be formatted as illustrated in Figure 26.
4
5
Bits: 8 4 4 16 8
6
7 Transaction
8 Command Attribute data Attribute
sequence Error code
9 number
10
Transaction
11 Transaction payload
header
12
13
14 Figure 26 Format of the set response command frame
15
17 The set response command frame is generated in response to the reception of a set with acknowledgement
18 command frame.
19
20 The transaction sequence number shall be set to value of the transaction sequence number sent with the set
21 with acknowledgement command frame. The command type identifier field shall be set to 1001 (binary).
22 The attribute data type shall be set to the type of the attribute that was written. The attribute identifier field
23 shall contain the identifier of the attribute that was written.
24
25 If the requested attribute was defined and the set with acknowledgement command frame contained no
26 errors, the error code field shall contain 0x00, indicating a successful request. Otherwise, the error code field
27 shall be set to one of the non-reserved values listed in Table 37.
28
29 1.3.5.4.2 Effect on receipt
30
31 On receipt of the set response command frame, the originator is notified of the success of their request to
32 write the value of an attribute. If the error code field contains 0x00, the transaction was successful and the
33 attribute value was written. If the error code field does not contain the value 0x00, the transaction was
34 unsuccessful.
35
36 1.3.5.5 Event/event with acknowledgement
37 The event and event with acknowledgement command frames shall be formatted as illustrated in Figure 27.
38
39
40 Bits: 8 4 4 16 Variable
41
42 Transaction
Command Attribute data Attribute
43 sequence Attribute data
number
44
45 Transaction
Transaction payload
46 header
47
48 Figure 27 Format of the event/event with acknowledgement command frame
49
51
52 The event and event with acknowledgement command frames are generated when a device wishes to inform
53 another device that the value of an attribute has changed. The event with acknowledgement command frame
54 is used when a response is required from the recipient.

The transaction sequence number shall be set to the next value of the sequence number maintained by the 1
application. The command type identifier field shall be set to 0010 or 0110 (binary), for the event or event 2
with acknowledgement command frames, respectively. The attribute data type shall be set to the type of the 3
attribute that has changed. The attribute identifier field shall contain the identifier of the attribute that has 4
changed. 5
6
The attribute data field shall contain the changed value of the attribute specified in the attribute identifier 7
field and shall be a whole number of octets in the specified data format. If the length of this field is not 8
defined directly by the data type of the attribute being referred to, the first octet shall contain the length, in 9
octets, of the rest of the data (see also Table 19). The actual meaning of the data is specified in the relevant 10
device description. 11
12
14
On receipt of the event command frame, the recipient device is notified of the new value of the attribute
15
specified in the attribute identifier field.
16
On receipt of the event with acknowledgement command frame, the recipient device is notified of the new 17
value of the attribute specified in the attribute identifier field. It shall then generate and send an event 18
response command frame back to the recipient with a suitable error code. 19
20
1.3.5.6 Event response command frame 21
22
The event response command frame shall be formatted as illustrated in Figure 28 23
24
25
Bits: 8 4 4 16 8 26
27
Transaction
Command Attribute data Attribute 28
sequence Error code
type identifier type identifier 29
number
30
Transaction 31
Transaction payload
header 32
33
Figure 28 Format of the event response command frame 34
35
37
The event response command frame is generated in response to the reception of an event with 38
acknowledgement command frame. 39
The transaction sequence number shall be set to value of the transaction sequence number sent with the 40
event with acknowledgement command frame. The command type identifier field shall be set to 1010 41
(binary). The attribute data type shall be set to the type of the attribute whose change was notified. The 42
attribute identifier field shall contain the identifier of the attribute whose change was notified. 43
44
If the event with acknowledgement command frame contained no errors, the error code field shall contain 45
0x00, indicating a successful notification. Otherwise, the error code field shall contain one of the non- 46
reserved values listed in Table 37. 47
48
50
On receipt of the event response command frame, the originator is notified of the success of their 51
notification of the change in the value of an attribute. If the error code field contains 0x00, the transaction 52
was successful. If the error code field does not contain the value 0x00, the transaction was unsuccessful. 53
54

1 1.3.6 Functional description

2
3 1.3.6.1 Aggregate transactions
4
5 The general application framework frame format allows the grouping individual transactions together in the
6 same frame. Such a grouping of transactions is referred to as aggregation.
7
8 Only those transactions that share the same service type (i.e. KVP or MSG) and cluster identifier shall be
9 aggregated and the combined aggregate frame shall not exceed the maximum permitted size.34
10
On receipt of an aggregated set of KVP transactions, the recipient shall process each transaction in turn and,
11
for those transactions requiring a response, compile an aggregated set of response transactions and send
12
them back to the originator.
13
14 The recipient shall ensure that this set of aggregated response transactions will fit within the size restrictions
15 of an APS frame. If this is not possible, the recipient shall send the aggregated responses split over several
16 frames, with each frame containing as many aggregated responses as will fit within the size restrictions of a
17 single APS frame.35
18
19 1.3.6.2 Reception and rejection
20
21 The application framework shall be able to filter frames arriving via the APS sub-layer data service and only
22 present the frames that are of interest to the applications implemented on each active endpoint.
23
24 The application framework receives data from the APS sub-layer via the APSDE-DATA.indication primitive
25 and is targeted at a specific endpoint (DstEndpoint parameter) and a specific profile (ProfileId parameter).
26
If the application framework receives a frame for an inactive endpoint, the frame shall be discarded.
27
Otherwise, the application framework shall determine whether the specified profile identifier matches the
28
identifier of the profile implemented on the specified endpoint. If the profile identifier does not match, the
29
application framework shall reject the frame. Otherwise, the application framework shall pass the payload of
30
the received frame to the application implemented on the specified endpoint.36
31
32
33
34
1.4 The ZigBee device profile
35
36 1.4.1 Scope
37
38 This ZigBee Application Layer Specification describes how general ZigBee device features such as Binding,
39 Device Discovery and Service Discovery are implemented within ZigBee Device Objects. The ZigBee
40 Device Profile operates like any ZigBee profile by defining Device Descriptions and Clusters. Unlike
41 application specific profiles, the Device Descriptions and Clusters within the ZigBee Device Profile define
42 capabilities supported in all ZigBee devices. As with any profile document, this document details the
43 mandatory and/or optional clusters.
44
45
46 1.4.2 Device Profile overview
47
The Device Profile supports four key inter-device communication functions within the ZigBee protocol:
48
49 — Device and Service Discovery
50
51
52 34
CCB Comment #234
36
54 CCB Comment #208

— End Device Bind Request Processing 1

2
— Bind and Unbind Command Processing
3
— Network Management 4
5
1.4.2.1 Device and service discovery overview 6
7
The following capabilities exist for device and service discovery: 8
9
— Device Discovery – Provides the ability for a device to determine the identity of other devices on the
10
PAN. Device Discovery is supported for both the 64 bit IEEE address and the 16 bit Network
11
address. Device Discovery messages can be used in one of two ways:
12
— Broadcast addressed – All devices on the network shall respond according to the Logical 13
Device Type and match criteria. ZigBee End Devices shall respond with just their address. Zig- 14
Bee Coordinators and ZigBee Routers with associated devices shall respond with their address 15
as the first entry followed by the addresses of their associated devices depending on the type of 16
request. The responding devices shall employ APS acknowledged service on the unicast 17
responses. 18
19
— Unicast addressed – Only the specified device responds. ZigBee End Devices shall respond
20
with just their address. ZigBee Coordinator or Routers shall reply with their address and the
21
addresses of each of their associated devices
22
For ZigBee Version 1.0, Device Discovery is a distributed operation where individual devices or their
23
immediate parent devices respond to discovery requests. To enable future upgrades to a centralized or
24
agent based discovery method, a "device address of interest" field has been added and the broadcast
25
addressed discovery commands may be optionally unicast for ZigBee releases after Version 1.0.37
26
— Service Discovery – Provides the ability for a device to determine services offered by other devices 27
on the PAN. 28
29
— Service Discovery messages can be used in one of two ways:
30
— Broadcast addressed –Due to the volume of information that could be returned, only the 31
individual device shall respond which match criteria established in the request unless that 32
device is a ZigBee Coordinator or ZigBee Router with sleeping associated device. In that 33
case, the ZigBee Coordinator or ZigBee Router shall cache the Service Discovery infor- 34
mation for the sleeping associated devices and respond on their behalf if the sleeping 35
device matches criteria in the request. The responding devices shall also employ APS 36
acknowledged service on the unicast responses. 37
38
— Unicast addressed – Only the specified device shall respond. In the case of a ZigBee Coor-
39
dinator or ZigBee Router, these devices shall cache the Service Discovery information for
40
sleeping associated devices and respond on their behalf.
41
— Service Discovery is supported with the following query types: 42
43
— Active Endpoint – This command permits an enquiring device to determine the active
44
endpoints. An active endpoint is one with an application supporting a single profile,
45
described by a Simple Descriptor. The command may be broadcast or unicast addressed.
46
— Match Simple Descriptor – This command permits enquiring devices to supply a Profile 47
ID and, optionally, lists of input and/or output Cluster IDs and ask for a return of the iden- 48
tity of an endpoint on the destination device which match the supplied criteria. This com- 49
mand may be broadcast or unicast addressed. For broadcast addressed requests, the 50
responding device shall employ APS acknowledged service on the unicast responses. 51
52
53
37
CCB Comment #171 54

1 — Simple Descriptor – This commands permits an enquiring device to return the Simple
2 Descriptor for the supplied endpoint. This command shall be unicast addressed.
3
— Node Descriptor - This commands permits an enquiring device to return the Node
4
Descriptor from the specified device. This command shall be unicast addressed.
5
6 — Power Descriptor - This commands permits an enquiring device to return the Power
7 Descriptor from the specified device. This command shall be unicast addressed.
8
— Complex Descriptor – This optional command permits an enquiring device to return the
9
Complex Descriptor from the specified device. This command shall be unicast addressed.
10
11 — User Descriptor - This optional command permits an enquiring device to return the User
12 Descriptor from the specified device. This command shall be unicast addressed.
13 For ZigBee Version 1.0, Service Discovery is a distributed operation where individual devices or their
14 immediate parent devices respond to discovery requests. To enable future upgrades to a centralized or
15 agent based discovery method, a "device address of interest" field has been added and the broadcast
16 addressed discovery commands may be optionally unicast for ZigBee releases after Version 1.0.38
17
18 1.4.2.2 End device bind overview
19
20 The following capabilities exist for end device bind:
21
— End Device Bind
22
23 — Provides the ability for an application to support “simple binding” where user intervention is
24 employed to identify command/control device pairs. Typical usage would be where a user is
25 asked to push buttons on two devices for installation purposes.
26
— Provides the ability for an application to support a simplified method of binding where user
27
intervention is employed to identify command/control device pairs. Typical usage would be
28
where a user is asked to push buttons on two devices for installation purposes. Using this mech-
29
anism a second time allows the user to remove the binding table entry39
30
31
1.4.2.3 Bind and unbind overview
32
33 The following capabilities exist for directly configuring binding table entries:40
34
35 — Bind
36
— Provides the ability for creation of a Binding Table entry that map control messages to their
37
intended destination.
38
39 — Unbind
40
— Provides the ability to remove Binding Table entries.
41
42
1.4.2.4 Network management overview
43
44 The following capabilities exist for network management:
45
46 Network management:
47
48 — Provides the ability to retrieve management information from the devices including:
49 — Network discovery results
50
51
52 38
CCB Comment #171
53 39CCB Comment #123, 236
40
54 CCB Comment #236

— Link quality to neighbor nodes 1

2
— Routing table contents
3
— Binding table contents 4
5
— Provides the ability to set management information controls including:
6
— Network disassociate 7
8
1.4.2.5 Device Descriptions for the Device Profile 9
10
The ZigBee Device Profile utilizes a single Device Description. Each cluster specified as Mandatory shall 11
be present in all ZigBee devices. The response behavior to some messages is logical device type specific. 12
The support for Optional clusters is not dependent on the logical device type. 13
14
1.4.2.6 Service Type usage 15
16
The ZigBee Device Profile shall employ the Message (MSG) Service Type. See clause 1.3 for details.
17
18
1.4.2.7 Configuration and roles
19
The Device Profile assumes a client/server topology. A device making Device Discovery, Service 20
Discovery, Binding or Network Management requests does so via a client role. A device which services 21
these requests and responds does so via a server role. The client and server roles are non-exclusive in that a 22
given device may supply both client and server roles. 23
24
The Device Profile describes devices in one of two configurations: 25
26
— Client – A client issues requests via Device Profile messages. Based on processing of those requests 27
at the server, the client receives responses to the issued requests 28
— Server – A server is the target of requests via Device Profile messages processes those requests and 29
issues responses. 30
31
1.4.2.8 Cluster ID format within the Device Profile 32
33
The following Cluster ID format shall be used within the Device Profile: 34
35
36
bits: 0 - 6 7
37
Request/Response Bit 38
Message Number Request = 0 39
Response = 1 40
41
Figure 29 Cluster ID Format for the Device Profile 42
43
44
1.4.3 Client services 45
The Device Profile Client Services supports the transport of device and service discovery requests, end 46
device binding requests, bind requests unbind requests and network management requests from client to 47
server. Additionally, Client Services support receipt of responses to these requests from the server. 48
49
50
51
52
53
54

1 1.4.3.1 Device and Service Discovery client services

2
3 Table 381 lists the primitives supported by Device Profile Device and Service Discovery Client Services.
4 Each of these primitives will be discussed in the following sub-clauses.
5 Table 38 Device and Service Discovery Client Services primitives
6
7 Device and Service Client Server
Discovery
8 Transmission Processing
Client Services
9
10 NWK_addr_req O M
11
IEEE_addr_req O M
12
13 Node_Desc_req O M
14
15 Power_Desc_req O M
16 Simple_Desc_req O M
17
18 Active_EP_req O M
19
Match_Desc_req O M
20
21 Complex_Desc_req O Oa
22
User_Desc_req O Ob
23
24 Discovery_Register_req O Oc
25
26 End_Device_annce O O
27 User_Desc_set d
O Oe
28 aMust
minimally return a status of NOT_SUPPORTED
29 bibid
30 c
Ibid
31 dCCB
Comment #176
32 e
Must minimally return a status of NOT_SUPPORTED
33
34
35 1.4.3.1.1 NWK_addr_req
36
38
This semantics of this primitive are as follows:
39
40
41 ClusterID=0x00 NWK_addr_req (
IEEEAddr
42 RequestType
43 StartIndex
44 )
45
46
47
48
49
50
51
52
53
54

Table 39 specifies the parameters for the NWK_addr_req primitive. 1

2
Table 39 NWK_addr_req parameters 3
IEEEAddr IEEE The IEEE address to be matched by the 5
A valid 64-bit IEEE address 6
Address Remote Device
7
RequestType Request type for this command: 8
9
0x00 – Single device response
Integer 0x00-0xff 10
0x01 – Extended response 11
12
0x02-0xff – reserved 13
StartIndex If the Request type for this command is 14
Extended response, the StartIndex pro- 15
Integer 0x00-0xff
vides the starting index for the requested 16
elements of the associated devices list. 17
18
19
21
The NWK_addr_req is generated from Local Device devices wishing to inquire as to the 16 bit address of
22
the Remote Device based on its known IEEE address. The destination addressing on this primitive shall be
23
broadcast.
24
For future upgrade ability, the destination addressing may be permitted to be unicast. This would permit 25
directing the message to a well-known destination that supports centralized or agent-based device discovery. 26
27
29
Upon receipt, a Remote Device shall compare the IEEEAddr to its local IEEE address. If there is no match, 30
the request shall be discarded and no response generated. If a match is detected between the contained 31
IEEEAddr and the Remote Device's IEEE address, the RequestType shall be used to create a response. If the 32
RequestType is one of the reserved values, a status of INV_REQUESTTYPE shall be returned. If the 33
RequestType is Single device response or Extended response, the Remote Device shall create a unicast 34
message to the Local Device and include the Remote Device's 16-bit NWK address as the source address 35
along with the matched IEEE Address in the response payload. If the RequestType was Single device 36
response, the response message shall be sent with a SUCCESS status. Otherwise, if the RequestType was 37
Extended response and the Remote Device is either the ZigBee coordinator or router with associated 38
devices, the Remote Device shall first include the matched IEEE Address and NWK Address in the message 39
payload and shall also supply a list of all 16 bit NWK addresses, starting with the entry StartIndex and 40
continuing with whole entries until the maximum APS packet length is reached, for its associated devices 41
along with a status of SUCCESS.41 42
43
44
45
46
47
48
49
50
51
52
53
41
CCB Comment #171 54

1 1.4.3.1.2 IEEE_addr_req
2
4
6
7 ClusterID=0x01 IEEE_addr_req (
8 NWKAddrOfInterest
9 RequestType
StartIndex
10 )
11
12
13 Table 40 specifies the parameters for the IEEE_addr_req primitive.
14 Table 40 IEEE_addr_req parameters
15
Name Type Valid range Description
16
17 NWKAddrOfInterest Device NWK address that is used for IEEE
16 bit NWK address
18 Address address mapping.
19 RequestType Request type for this command:
20
21 0x00 – Single device response.
22 Integer 0x00-0xff
23 0x01 – Extended response.
24 0x02-0xff – reserved.
25
26 StartIndex If the Request type for this command
27 is Extended response, the StartIndex
Integer 0x00-0xff provides the starting index for the
28
requested elements of the associated
29 devices list.
30
31
33
34 The IEEE_addr_req is generated from Local Device devices wishing to inquire as to the 64 bit IEEE address
35 of the Remote Device based on their known 16 bit address. The destination addressing on this primitive shall
36 be unicast.
37
39
40 Upon receipt, a Remote Device shall create a unicast message to the source indicated by the IEEE_addr_req
41 and include the Remote Device's 64-bit IEEE address as the first field within the IEEE_addr_rsp payload.
42 Additionally, if the RequestType indicates an Extended Response and the Remote Device is the ZigBee
43 coordinator or router with associated devices, the Remote Device shall first include its own 64-bit IEEE
44 address and then shall also supply a list of all 16 bit IEEE addresses for its associated devices, starting with
45 the entry StartIndex and continuing with whole entries until the maximum APS packet length is reached,
46 with a status of SUCCESS.42
47
For ZigBee Version 1.0, the destination address and the NWKAddrofInterest shall be the same. For future
48
upgrade ability, the destination address could be specified as a known address holding device discovery
49
information and the NWKAddrOfInterest could be specified as a query parameter.
50
51
52
53
42
54 Ibid

1.4.3.1.3 Node_Desc_req 1
2
4
6
ClusterID=0x02 Node_Desc_req ( 7
NWKAddrOfInterest 8
) 9
10
Table 41 specifies the parameters for the Node_Desc_req primitive. 11
12
Table 41 Node_Desc_req parameters
13
NWKAddrOfInterest Device NWK address for the request. 15
16 bit NWK address 16
Address
17
18
20
The Node_Desc_req is generated from Local Devices wishing to inquire as to the Node Descriptor of the 21
Remote Device. The destination addressing on this primitive can be unicast only. 22
23
25
Upon receipt, a Remote Device shall create a unicast message to the source indicated by the Node_Desc_req
26
and include the Remote Device’s Node Descriptor (see clause 1.4).
27
For ZigBee Version 1.0, the destination address and the NWKAddrofInterest shall be the same. For future 28
upgrade ability, the destination address could be specified as a known address holding discovery information 29
and the NWKAddrOfInterest could be specified as a query parameter. 30
31
1.4.3.1.4 Power_Desc_req 32
33
35
37
ClusterID=0x03 Power_Desc_req ( 38
NWKAddrOfInterest 39
) 40
41
Table 42 specifies the parameters for the Power_Desc_req primitive. 42
43
Table 42 Power_Desc_req parameters
44
Address
48
49
51
The Power_Desc_req is generated from Local Devices wishing to inquire as to the Power Descriptor of the 52
54


2
3 Upon receipt, a Remote Device shall create a unicast message to the source indicated by the
4 Power_Desc_req and include the Remote Device’s Power Descriptor (see clause 1.4).
5
For ZigBee Version 1.0, the destination address and the NWKAddrofInterest shall be the same. For future
6
upgrade ability, the destination address could be specified as a known address holding discovery information
7
and the NWKAddrOfInterest could be specified as a query parameter.
8
9
1.4.3.1.5 Simple_Desc_req
10
11
12
14
15
ClusterID=0x04 Simple_Desc_req (
16 NWKAddrOfInterest
17 endpoint
18 )
19
20 Table 43 specifies the parameters for the Simple_Desc_req primitive.
21
22 Table 43 Simple_Desc_req parameters
24
NWKAddrOfInterest Device NWK address for the request.
25 16 bit NWK address
Address
26
27 endpoint 8 bits 1-240 The endpoint on the destination.
28
29
31
32 The Simple_Desc_Desc_req is generated from Local Devices wishing to acquire the Simple Descriptor on
33 the Remote Device corresponding to the supplied endpoint. The destination addressing on this primitive can
34 be unicast only.
35
37
Upon receipt, a Remote Device shall create a unicast message to the source indicated by the
38
Simple_Desc_req and include the Remote Device’s Simple Descriptor corresponding to the supplied
39
endpoint (see clause 1.4).
40
41 For ZigBee Version 1.0, the destination address and the NWKAddrofInterest shall be the same. For future
42 upgrade ability, the destination address could be specified as a known address holding discovery information
43 and the NWKAddrOfInterest could be specified as a query parameter.
44
45 1.4.3.1.6 Active_EP_req
46
48
50
51 ClusterID=0x05 Active_EP_req (
53 )
54

Table 44 specifies the parameters for the Active_EP_req primitive. 1

2
Table 44 Active_EP_req parameters 3
Address
7
8
10
The Active_EP_req is generated from Local Devices wishing to acquire the list of endpoints on the Remote 11
Device with Simple Descriptors. The destination addressing on this primitive can be unicast only. 12
13
15
Upon receipt, a Remote Device shall create a unicast message to the source indicated by the Active_EP_req 16
and include the Remote Device’s list of active endpoints. 17
21
1.4.3.1.7 Match_Desc_req 22
23
25
27
ClusterID=0x06 Match_Desc_req ( 28
ProfileID, 30
NumInClusters 31
InClusterList 32
NumOutClusters
OutClusterList 33
) 34
35
36
Table 45 specifies the parameters for the Match_Desc_req primitive.
37
Table 45 Match_Desc_req parameters 38
40
NWKAddrOfInterest Device Address 16 bit NWK address NWK address for the request. 41
ProfileID Profile ID to be matched at the desti- 42
Integer 0x0000-0xffff 43
nation.
44
NumInClusters The number of Input Clusters pro- 45
Integer 0x00-0xff vided for matching within the InClus-
46
terList.
47
48
49
50
51
52
53
54

1 Table 45 Match_Desc_req parameters

2
InClusterList List of Input ClusterIDs to be used for
3 matching. The InClusterList is the
4 1 byte * desired list to be matched by the
5 NumInClusters Remote Device (the elements of the
6 InClusterList are the supported out-
7 put clusters of the Local Device)
8 NumOutClusters The number of Output Clusters pro-
9 Integer 0x00-0xff vided for matching within OutCluster-
10 List.
11
OutClusterList List of Output ClusterIDs to be used
12 for matching. The OutClusterList is
13 1 byte * the desired list to be matched by the
14 NumOutClusters Remote Device (the elements of the
15 OutClusterList are the supported
16 input clusters of the Local Device)
17
18
19
20 The Match_Desc_req is generated from Local Devices wishing to find Remote Devices supporting the
21 match criteria, identified by responses citing the Remote Device address, endpoint supplying the match. The
22 destination addressing on this primitive can be broadcast or unicast.
23
25
26 Upon receipt, a Remote Device shall evaluate the Simple Descriptors on all active endpoints for a match. A
27 match shall be detected if the ProfileID matches and any of the elements of InClusterList or OutClusterList
28 match corresponding elements of the active endpoint Simple Descriptor AppInClusterList or
29 AppOutClusterList (see clause 1.4). Note that the NumInClusters and NumOutClusters fields can be set to 0
30 (zero) and the InClusterList and OutClusterList omitted whereby the match shall be entirely performed on
31 ProfileID. If a match is detected, the Remote Device shall create a unicast message to the Local Device
32 citing the Local Device address, endpoint the match was detected. The elements of InClusterList and
33 OutClusterList are the desired list of clusters to be matched from the Local Device. The Local Device shall
34 provide its input cluster information as OutClusterList and shall provide its output cluster information as
35 InClusterList.
36
40
41 1.4.3.1.8 Complex_Desc_req
42
44
45
46
47 ClusterID=0x10 Complex_Desc_req (
NWKAddrOfInterest
48 )
49
50
51
52
53
54

Table 46 specifies the parameters for the Complex_Desc_req primitive. 1

2
Table 46 Complex_Desc_req parameters 3
Address
7
8
10
The Complex_Desc_req is generated from Local Devices wishing to acquire the Complex Descriptor on the 11
13
15
Upon receipt, a Remote Device shall create a unicast message to the source indicated by the 16
Complex_Desc_req and include the Remote Device’s Complex Descriptor (if this optional descriptor is 17
supported on the Remote Device). If the Remote Device does not support the Complex Descriptor, a status 18
of NOT_SUPPORTED shall be returned. 19
23
1.4.3.1.9 User_Desc_req 24
25
27
29
ClusterID=0x11 User_Desc_req ( 30
) 32
33
Table 47 specifies the parameters for the User_Desc_req primitive. 34
35
Table 47 User_Desc_req parameters 36
38
NWKAddrOfInterest Device NWK address for the request.
Address
40
41
43
The User_Desc_req is generated from Local Devices wishing to acquire the User Descriptor on the Remote 44
Device. The destination addressing on this primitive can be unicast only. 45
46
48
Upon receipt, a Remote Device shall create a unicast message to the source indicated by the User_Desc_req 49
and include the Remote Device’s Complex Descriptor (if this optional descriptor is supported on the Remote 50
Device). If the Remote Device does not support the User Descriptor, a status of NOT_SUPPORTED shall be 51
returned. 52
53
54

4
5 1.4.3.1.10 Discovery_Register_req
6
8
10
11 ClusterID=0x12 Discovery_Register_req (
12 NWKAddr
13 IEEEAddr
)
14
15
16 Table 48specifies the parameters for the Discovery_Register_req primitive.
17 Table 48 Discovery_Register_req parameters
18
20 NWKAddr Device NWK address for the Local Device.
16 bit NWK address
21 Address
22
IEEEAddr Device IEEE address for the Local Device.
23 64 bit IEEE address
Address
24
25
27
28 The Discovery_Register_req is provided as a post Version 1.0 feature to enable devices on the network to
29 notify the ZigBee Coordinator that the device wishes to register its discovery information. The destination
30 addressing on this primitive can be unicast only and the destination address shall be that of the ZigBee
31 Coordinator.
32
34
35 Upon receipt, the Remote Device (ZigBee Coordinator) shall create a unicast message to the source
36 indicated by the Discovery_Register_req and include the status of the request. If the ZigBee Coordinator
37 does not support the Discovery_Register_req, a status of NOT_SUPPORTED shall be returned.
38 Additionally, if the Discovery_Register_req is supported, the Remote Device (ZigBee Coordinator) is
39 expected to utilize the Device and Service Discovery commands described in this document to upload the
40 discovery information from the Local Device. Future discovery requests could then be directed to the
41 ZigBee Coordinator which will be able to describe device and service information for the Local Device.
42
43 1.4.3.1.11 End_Device_annce
44
46
47
48
49 ClusterID=0x13 End_Device_annce (
NWKAddr
50
IEEEAddr
51 )
52
53
54

Table 49 specifies the parameters for the End_Device_annce primitive. 1

2
Table 49 End_Device_annce parameters 3
NWKAddr Device NWK address for the Local Device. 5
Address
7
IEEEAddr Device IEEE address for the Local Device. 8
64 bit IEEE address
Address
9
10
11
12
The End_Device_annce is provided to enable ZigBee end devices on the network to notify the ZigBee 13
coordinator that the end device has joined or re-joined the network, identifying the end devices 64 bit IEEE 14
address and new 16 bit NWK address. The destination addressing on this primitive is broadcast.43 15
16
18
Upon receipt, the Remote Device (ZigBee coordinator or source device for the binding operation) shall 19
utilize the IEEEAddr in the message for a match with any binding table entries held in the Remote Device. If 20
a match is detected, the Remote Device shall update its APS Information Block Address Map with the 21
updated NWKAddr corresponding to the IEEEAddr received. 44 22
23
1.4.3.1.12 User_Desc_set 24
25
27
29
ClusterID=0x14 User_Desc_set ( 30
NWKAddrOfInterest, 31
UserDescription 32
)
33
34
Table 50 specifies the parameters for the User_Desc_req primitive. 35
36
37
Table 50 User_Desc_set parameters 38
39
40
16 bit NWK address
Address 42
UserDescription ASCII char- The user description to configure. 43
16 characters 44
acter string
45
46
48
The User_Desc_set command is generated from a local device wishing to configure the user descriptor on a 49
remote device. This command shall only use unicast destination addressing. 50
51
52
43CCB Comment #169 53
44
Ibid 54


2
3 On receipt of this command, the remote device shall configure the user descriptor with the supplied data.
4 The results of this command shall be communicated back to the local device through the User_Desc_conf
5 command.
6
If this command is not supported or if a user descriptor does not exist, the return status provided with the
7
User_Desc_conf command shall be set to NOT_SUPPORTED. If a user descriptor exists, the remote device
8
shall configure it with the data supplied in the UserDescription field of the User_Desc_set command and the
9
return status provided with the User_Desc_conf command shall be set to SUCCESS.45
10
11
1.4.3.2 End Device Bind, Bind and Unbind client services
12
13 Table 51 lists the primitives supported by Device Profile End Device Bind, Bind and Unbind Client
14 Services. Each of these primitives will be discussed in the following sub-clauses.
15
16 Table 51 End Device Bind, Bind and Unbind Client Services primitives
17 End Device Bind, Client Server
18 Bind and Unbind
19 Transmission Processing
Client Services
20
End_Device_Bind_req O Oa
21
22 Bind_req O Ob
23
Unbind_req O Oc
24
25 a
Shall minimally respond with a status of NOT_SUPPORTED
26 b
27 c Shall minimally respond with a status of NOT_SUPPORTED
28
29
30 1.4.3.2.1 End_Device_Bind_req
31
33
34
35
36 ClusterID=0x20 End_Device_Bind_req (
LocalCoordinator
37
BindingTargeta
38 Endpoint
39 ProfileID
40 NumInClusters
41 InClusterList
NumOutClusters
42
OutClusterList
43 )
44
45 aCCB Comment #171
46
47
48
49
50
51
52
53
45
54 CCB Comment #176

Table 52 specifies the parameters for the End_Device_Bind_req primitive. 1

2
Table 52 End_Device_Bind_req parameters 3
BindingTarget The address of the target for the 5
binding. This can be either the ZigBee 6
Device Address 16 bit address
coordinator or the device itself if it is a 7
router.a 8
Endpoint The endpoint on the generating 9
8 bits 1-240
device.b 10
11
ProfileID ProfileID which is to be matched
between two End_Device_Bind_req 12
Integer 0x0000-0xffff received at the ZigBee Coordinator 13
within the timeout value pre-configured 14
in the ZigBee Coordinator. 15
16
NumInClusters The number of Input Clusters provided
Integer 0x00-0xff for end device binding within the 17
InClusterList. 18
19
InClusterList List of Input ClusterIDs to be used for 20
matching. The InClusterList is the
1 byte * desired list to be matched by the 21
NumInClusters Remote Device (the elements of the 22
InClusterList are the supported output 23
clusters of the Local Device). 24
25
NumOutClusters The number of Output Clusters pro-
Integer 0x00-0xff vided for matching within OutCluster- 26
List. 27
28
OutClusterList List of Output ClusterIDs to be used for 29
matching. The OutClusterList is the
1 byte * desired list to be matched by the 30
NumOutClusters Remote Device (the elements of the 31
InClusterList are the supported output 32
clusters of the Remote Device). 33
aCCB Comment #171 34
36
37
39
The End_Device_Bind_req is generated from Local Device devices wishing to perform End Device Bind 40
with a Remote Device. The End_Device_Bind_req is generated, typically based on some user action like a 41
button press. The destination addressing on this primitive shall be unicast and the destination address shall 42
be that of the ZigBee Coordinator. 43
44
46
The ZigBee Coordinator shall retain the End_Device_Bind_req for a pre-configured timeout duration
47
awaiting a second End_Device_Bind_req. If the second request does not appear within the timeout period,
48
the ZigBee Coordinator shall generate a TIMEOUT status and return it with the End_Device_Bind_rsp to
49
the originating Local Device. Assuming the second End_Device_Bind_req is received within the timeout
50
period, it shall be matched with the first request on the basis of the ProfileID, InClusterList and
51
OutClusterList.
52
If no match of the ProfileID is detected or if the ProfileID matches but none of the InClusterList or 53
OutClusterList elements match, a status of NO_MATCH shall be supplied to both Local Devices via 54

1 End_Device_Bind_rsp to each device. If a match of Profile ID and at least one input or output clusterID is
2 detected, an End_Device_Bind_rsp with status SUCCESS shall be issued to each Local Device which
3 generated the End_Device_Bind_req.
4
5 The ZigBee coordinator shall then determine the 64-bit IEEE address of each local device. If these addresses
6 are not known, the ZigBee coordinator shall determine them by using the IEEE_Addr_req command and
7 corresponding IEEE_Addr_rsp command.
8
In order to facilitate a toggle action the ZigBee Coordinator shall then issue an Unbind_req command to the
9
BindingTarget, specifying any one of the matched ClusterID values. If the returned status value is
10
NO_ENTRY then the ZigBee Coordinator shall issue a Bind_req command for each matched ClusterID
11
value. Otherwise the ZigBee Coordinator shall conclude that the binding records are instead to be removed
12
and shall issue an Unbind_req command for any further matched ClusterID values.
13
14 The initial Unbind_req and any subsequent Bind_reqs or Unbind_reqs, containing the matched clusters,
15 shall be directed to the BindingTarget, specified in the first End_Device_Bind_req command, and
16 constructed as follows. The SrcAddress and DstAddress fields shall contain the 64-bit IEEE addresses
17 derived, as described above, from the network addresses of the originators of the first and second
18 End_Device_Bind_req commands, respectively. Similarly, the SrcEndp and DstEndp fields shall contain the
19 endpoints contained in the first and second End_Device_Bind_req commands, respectively.46
20
21 1.4.3.2.2 Bind_req
22
24
26
27 ClusterID=0x21 Bind_req (
28 SrcAddress,
29 SrcEndp,
30 ClusterID,
DstAddress,
31
DstEndp
32 )
33
34
Table 53 specifies the parameters for the Bind_req primitive.
35
36 Table 53 Bind_req parameters
37
38
39 SrcAddress IEEE The IEEE address for the source.
A valid 64-bit IEEE address
40 Address
41 SrcEndp The source endpoint for the binding
42 Integer 0x01-0xf0
entry.
43
44 ClusterID The identifier of the cluster on the
Integer 0x00-0xff source device that is bound to the des-
45 tination.
46
47 DstAddress IEEE The IEEE address for the destination.
48 Address
49 DstEndp The destination endpoint for the bind-
50 Integer 0x01-0xf0
ing entry.
51
52
53
46
54 CCB Comment #171, 233, 236


2
The Bind_req is generated from Local Device devices wishing to create a Binding Table entry for the source 3
and destination addresses contained as parameters. The destination addressing on this primitive shall be 4
unicast only and the destination address must be that of the ZigBee Coordinator or to the SrcAddress itself. 5
The Binding Manager is optionally supported on the source device (unless that device is also the ZigBee 6
Coordinator) so that device shall issue a NOT_SUPPORTED status to the Bind_req if not supported. 7
8
10
Upon receipt, a Remote Device (ZigBee Coordinator or the device designated by SrcAddress) shall create a
11
Binding Table entry based on the parameters supplied in the Bind_req if the Binding Manager is supported.
12
The Remote Device shall then respond with SUCCESS if the entry has been created by the Binding
13
Manager, else the Remote Device shall respond with NOT_SUPPORTED.
14
15
1.4.3.2.3 Unbind_req
16
17
18
20
21
ClusterID=0x22 Unbind_req (
SrcAddress, 22
SrcEndp, 23
ClusterID, 24
DstAddress, 25
DstEndp 26
)
27
28
Table 54 specifies the parameters for the Unbind_req primitive. 29
Table 54 Unbind_req parameters 30
31
SrcAddress IEEE The IEEE address for the source. 33
Address 34
35
SrcEndp The source endpoint for the binding
Integer 0x01-0xf0 36
entry.
37
ClusterID The identifier of the cluster on the 38
Integer 0x00-0xff source device that is bound to the des- 39
tination.
40
DstAddress IEEE The IEEE address for the destination. 41
Address 42
43
DstEndp The destination endpoint for the bind-
Integer 0x01-0xf0 44
ing entry.
45
46
48
The Unbind_req is generated from Local Device devices wishing to remove a Binding Table entry for the 49
source and destination addresses contained as parameters. The destination addressing on this primitive shall 50
be unicast only and the destination address must be that of the ZigBee Coordinator or the SrcAddress. 51
52
53
54


2
3 The Remote Device shall evaluate whether this request is supported. If the request is not supported, a Status
4 of NOT_SUPPORTED shall be returned. If the request is supported, the Remote Device (ZigBee
5 Coordinator or the SrcAddress) shall remove a Binding Table entry based on the parameters supplied in the
6 Unbind_req. If the SrcAddress is specified and the Binding Manager is unsupported on that remote device,
7 a status of NOT_SUPPORTED shall be returned. If a Binding Table entry for the SrvAddress, SrcEndp,
8 ClusterID, DstAddress, DstEndp contained as parameters does not exist, the Remote Device shall respond
9 with NO_ENTRY. Otherwise, the Remote Device shall delete the indicated Binding Table entry and respond
10 with SUCCESS.
11
12 1.4.3.3 Network Management Client Services
13
Table 55 lists the primitives supported by Device Profile Network Management Client Services. Each of
14
these primitives will be discussed in the following sub-clauses.
15
16 Table 55 Network Management Client Services primitives
17
Network Management Client Server
18
Client Services Transmission Processing
19
20 Mgmt_NWK_Disc_req O Oa
21
Mgmt_Lqi_req O Ob
22
23 Mgmt_Rtg_req O Oc
24
25 Mgmt_Bind_req O Od
26 Mgmt_Leave_req O Oe
27
28 Mgmt_Direct_Join_req O Of
29 a
30 b
31 c Shall minimally respond with a status of NOT_SUPPORTED
32 d
33 e Shall minimally respond with a status of NOT_SUPPORTED
34 f Shall minimally respond with a status of NOT_SUPPORTED
35
36
37 1.4.3.3.1 Mgmt_NWK_Disc_req
38
40
41
42
43 ClusterID=0x30 Mgmt_NWK_Disc_req (
ScanChannels
44
ScanDuration
45 StartIndexa
46 )
47
aCCB
48 Comment #243
49
50
51
52
53
54

Table 56 specifies the parameters for the Mgmt_NWK_Disc_req primitive. 1

2
Table 56 Mgmt_NWK_Disc_req parameters 3
ScanChannels See sub-clause 2.3.2.1 for details on 5
Bitmap 32 bit field NLME-NETWORK-DISCOV- 6
ERY.request ScanChannels parameter. 7
8
ScanDuration A value used to calculate the length of
time to spend scanning each channel. 9
The time spent scanning each channel 10
is (aBaseSuperframeDuration * (2n + 11
Integer 0x00-0x0e 12
1)) symbols, where n is the value of the
ScanDuration parameter. For more 13
information on MAC sub-layer scanning 14
(see [B1]).a 15
StartIndex Starting index within the resulting 16
NLME-NETWORK-DISCOVERY.con- 17
Integer 0x00-0xff
firm NetworkList to begin reporting for 18
the Mgmt_NWK_Disc_rsp. 19
aCCB 20
Comment #243
21
22
24
The Mgmt_NWK_Disc_req is generated from Local Device devices requesting that the Remote Device 25
execute a Scan to report back networks in the vicinity of the Local Device. The destination addressing on 26
this primitive shall be unicast. 27
28
30
The Remote Device shall execute an NLME-NETWORK-DISCOVERY.request using the ScanChannels
31
and ScanDuration parameters supplied with the Mgmt_NWK_Disc_req command. The results of the Scan
32
shall be reported back to the Local Device via the Mgmt_NWK_Disc_rsp command.
33
If this command is not supported in the Remote Device, the return status provided with the 34
Mgmt_NWK_Disc_rsp shall be NOT_SUPPORTED. If the scan was successful, the Mgmt_NWK_Disc_rsp 35
command shall contain a status of SUCCESS and the results of the scan shall be reported, beginning with 36
the StartIndex element of the NetworkList. If the scan was unsuccessful, the Mgmt_NWK_Disc_rsp 37
command shall contain the error code reported in the NLME-NETWORK-DISCOVERY.confirm 38
primitive.47 39
40
1.4.3.3.2 Mgmt_Lqi_req 41
42
44
46
ClusterID=0x31 Mgmt_Lqi_req ( 47
StartIndex 48
) 49
50
51
52
53
47
CCB Comment ##237, 243 54

1 Table 57 specifies the parameters for the Mgmt_Lqi_req primitive.

2
3 Table 57 Mgmt_Lqi_req parameters
5 StartIndex Starting Index for the requested ele-
6 Integer 0x00-0xff
ments of the Neighbor Table.
7
8
10
11 The Mgmt_Lqi_req is generated from Local Device devices wishing to obtain a neighbor list for the Remote
12 Device along with associated LQI values to each neighbor. The destination addressing on this primitive shall
13 be unicast only and the destination address must be that of a ZigBee Coordinator or ZigBee Router.
14
16
17 Upon receipt, a Remote Device (ZigBee Router or ZigBee Coordinator) shall retrieve the entries of the
18 neighbor table and associated LQI values via the NLME-GET.request primitive (for the nwkNeighborTable
19 attribute) and report the resulting neighbor table (obtained via the NLME-GET.confirm primitive) via the
20 Mgmt_Lqi_rsp command.
21 If this command is not supported in the Remote Device, the return status provided with the Mgmt_Lqi_rsp
22 shall be NOT_SUPPORTED. If the neighbor table was obtained successfully, the Mgmt_Lqi_rsp command
23 shall contain a status of SUCCESS and the neighbor table shall be reported, beginning with the element in
24 the list enumerated as StartIndex. If the neighbor table was not obtained successfully, the Mgmt_Lqi_rsp
25 command shall contain the error code reported in the NLME-GET.confirm primitive.48
26
27 1.4.3.3.3 Mgmt_Rtg_req
28
30
32
33 ClusterID=0x32 Mgmt_Rtg_req (
34 StartIndex
35 )
36
37 Table 58 specifies the parameters for the Mgmt_Rtg_req primitive.
38
39 Table 58 Mgmt_Rtg_req parameters
41
StartIndex Starting Index for the requested ele-
ments of the Routing Table.
43
44
46
47 The Mgmt_Rtg_req is generated from Local Device devices wishing to retrieve the contents of the Routing
48 Table from the Remote Device. The destination addressing on this primitive shall be unicast only and the
49 destination address must be that of the ZigBee Router or ZigBee Coordinator.
50
51
52
53
48


2
Upon receipt, a Remote Device (ZigBee Coordinator or ZigBee Router) shall retrieve the entries of the 3
routing table from the NWK layer via the NLME-GET.request primitive (for the nwkRouteTable attribute) 4
and report the resulting routing table (obtained via the NLME-GET.confirm primitive) via the 5
Mgmt_Rtg_rsp command. 6
7
If the Remote Device does not support this optional management request, it shall return a Status of
8
NOT_SUPPORTED. If the routing table was obtained successfully, the Mgmt_Rtg_req command shall
9
contain a status of SUCCESS and the routing table shall be reported, beginning with the element in the list
10
enumerated as StartIndex. If the routing table was not obtained successfully, the Mgmt_Rtg_rsp command
11
shall contain the error code reported in the NLME-GET.confirm primitive.49
12
13
1.4.3.3.4 Mgmt_Bind_req
14
15
16
18
19
ClusterID=0x33 Mgmt_Bind_req (
StartIndex 20
) 21
22
23
Table 59 specifies the parameters for the Mgmt_Bind_req primitive.
24
Table 59 Mgmt_Bind_req parameters 25
27
StartIndex Starting Index for the requested ele- 28
Integer 0x00-0xff
ments of the Binding Table.
29
30
31
32
The Mgmt_Bind_req is generated from Local Device devices wishing to retrieve the contents of the Binding 33
Table from the Remote Device. The destination addressing on this primitive shall be unicast only and the 34
destination address must be that of the ZigBee Router or ZigBee Coordinator. 35
36
38
Upon receipt, a Remote Device (ZigBee Coordinator or ZigBee Router) shall retrieve the entries of the 39
binding table from the APS sub-layer via the APSME-GET.request primitive (for the apsBindingTable 40
attribute) and report the resulting binding table (obtained via the APSME-GET.confirm primitive) via the 41
Mgmt_Bind_rsp command. 42
43
If the Remote Device does not support this optional management request, it shall return a status of 44
NOT_SUPPORTED. If the binding table was obtained successfully, the Mgmt_Bind_rsp command shall 45
contain a status of SUCCESS and the binding table shall be reported, beginning with the element in the list 46
enumerated as StartIndex. If the binding table was not obtained successfully, the Mgmt_Bind_rsp command 47
shall contain the error code reported in the APSME-GET.confirm primitive.50 48
49
50
51
52
49CCBComment #224, 237 53
50

1 1.4.3.3.5 Mgmt_Leave_req
2
4
6
7 ClusterID=0x34 Mgmt_Leave_req (
8 DeviceAddress
9 )
10
11 Table 60 specifies the parameters for the Mgmt_Leave_req primitive.
12
Table 60 Mgmt_Leave_req parameters
13
15 DeviceAddress See sub-clause 2.3.8.1 for details on
16 Device An extended 64 bit, IEEE
the DeviceAddress parameter within
Address address
17 NLME-LEAVE.request.
18
19
21
22 The Mgmt_Leave_req is generated from Local Device devices requesting that a Remote Device leave the
23 network or to request that another device leave the network. The Mgmt_Leave_req is generated by a
24 management application which directs the request to a Remote Device where the NLME-LEAVE.request is
25 to be executed using the parameter supplied by Mgmt_Leave_req.
26
28 Upon receipt, the remote device shall issue the NLME-LEAVE.request primitive using the DeviceAddress
29 parameter supplied with the Mgmt_Leave_req command. The results of the leave attempt shall be reported
30 back to the local device via the Mgmt_Leave_rsp command.
31
32 If the remote device does not support this optional management request, it shall return a status of
33 NOT_SUPPORTED. If the leave attempt was executed successfully, the Mgmt_Leave_rsp command shall
34 contain a status of SUCCESS. If the leave attempt was not executed successfully, the Mgmt_Leave_rsp
35 command shall contain the error code reported in the NLME-LEAVE.confirm primitive.51
36
37 1.4.3.3.6 Mgmt_Direct_Join_req
38
40
42
43 ClusterID=0x35 Mgmt_Direct_Join_req (
44 DeviceAddress
45 CapabilityInformationa
)
46
47 aCCB
Comment #241, 249
48
49
50
51
52
53
51
54 CCB Comment #237

Table 61 specifies the parameters for the Mgmt_Direct_Join_req primitive. 1

2
Table 61 Mgmt_Direct_Join_req parameters 3
DeviceAddress See sub-clause 2.3.6.1 for details on 5
An extended 64 bit, IEEE 6
Device Address the DeviceAddress parameter within
address
NLME-JOIN.request. 7
8
CapabilityInformation The operating capabilities of the device
Bitmap See Figure 32. 9
being directly joined.a
10
a
12
13
14
The Mgmt_Direct_Join_req is generated from Local Device devices requesting that a Remote Device permit 15
a device designated by DeviceAddress to join the network directly. The Mgmt_Direct_Join_req is generated 16
by a management application which directs the request to a Remote Device where the NLME-DIRECT- 17
JOIN.request is to be executed using the parameter supplied by Mgmt_Direct_Join_req. 52 18
19
21
Upon receipt, the remote device shall issue the NLME-DIRECT-JOIN.request primitive using the 22
DeviceAddress and CapabilityInformation parameters supplied with the Mgmt_Direct_Join_req command. 23
The results of the direct join attempt shall be reported back to the local device via the 24
Mgmt_Direct_Join_rsp command. 25
26
If the remote device does not support this optional management request, it shall return a status of 27
NOT_SUPPORTED. If the direct join attempt was executed successfully, the Mgmt_Direct_Join_rsp 28
command shall contain a status of SUCCESS. If the direct join attempt was not executed successfully, the 29
Mgmt_Direct_Join_rsp command shall contain the error code reported in the NLME-DIRECT- 30
JOIN.confirm primitive.53 31
32
1.4.4 Server services 33
34
The Device Profile Server Services supports the processing of device and service discovery requests, end 35
device bind requests, bind requests, unbind requests and network management requests. Additionally, Server 36
Services support transmission of these responses back to the requesting device. Table 6 lists the primitives 37
supported by Device Profile Server Services. 38
39
1.4.4.1 Device and Service Discovery Server Services 40
41
Table 62 lists the primitives supported by Device Profile Device and Service Discovery Server Services. 42
Each of these primitives will be discussed in the following sub-clauses. 43
44
Table 62 Device and Service Discovery Server Services primitives
45
Device and Service 46
Server
Discovery 47
Processing
Server Services
48
NWK_addr_rsp M 49
50
IEEE_addr_rsp M
51
52
53
CCB Comment #237, 241, 249 54

1 Table 62 Device and Service Discovery Server Services primitives

2
Node_Desc_rsp M
3
4 Power_Desc_rsp M
5
6 Simple_Desc_rsp M
7 Active_EP_rsp M
8
9 Match_Desc_rsp M
10
Complex_Desc_rsp Oa
11
12 User_Desc_rsp Ob
13
Discovery_Register_rsp Oc
14
15 User_Desc_confd Oe
16 a Must minimally respond with a status of NOT_SUPPORTED
17 b
Must minimally respond with a status of NOT_SUPPORTED
18 c Must minimally respond with a status of NOT_SUPPORTED
19 dCCB Comment #169, 176
20 eMust minimally respond with a status of NOT_SUPPORTED
21
22
1.4.4.1.1 NWK_addr_rsp
23
24
25
27
28
ClusterID=0x80 NWK_addr_rsp (
29 Status
30 IEEEAddrRemoteDev
31 NWKAddrRemoteDev
32 NumAssocDev
33 StartIndex
NWKAddrAssocDevList
34 )
35
36
37 Table 63 specifies the parameters for the NWK_addr_rsp primitive.
38 Table 63 NWK_addr_rsp parameters
39
40
41 Status Valid status shall be one of the follow-
42 ing:
43
SUCCESS = 0x00.
44
45 SUCCESS, INV_REQUESTTYPE = 0x01.
46 Integer INV_REQUESTTYPE or
47 DEVICE_NOT_FOUND DEVICE_NOT_FOUND = 0x02.
48
Reserved = 0x03-0xff.
49
50 The status of the NWK_addr_req
51 command.a
52
IEEEAddrRemoteDev Device An extended 64 bit, IEEE 64 bit address for the Remote Device.
53 Address address
54

Table 63 NWK_addr_rsp parameters 1

2
NWKAddrRemoteDev Device 16 bit address for the Remote Device.
A 16 bit, NWK address 3
Address
4
NumAssocDev Count of the number of associated 5
devices to the Remote Device and 6
the number of 16 bit short addresses
7
to follow. NumAssocDev shall be 0 if
Integer 0x00-0xff 8
there are no associated devices to
Remote Device and the StartIndex 9
and NWKAddrAssocDevList shall be 10
null in this case. 11
StartIndex Starting index into the list of associ- 12
ated devices for this report.
14
NWKAddrAssocDevList A list of 16 bit addresses, one corre- 15
List of 16 bit short sponding to each associated device
16
Device addresses, each with to the Remote Device. The count of
Address List range 0x0000-ffff, the 16 bit addresses in NWKAddrAs- 17
NumAssocDev in length socDevList is supplied in NumAs- 18
socDev. 19
aCCB
20
Comment #223
21
22
24
The NWK_addr_rsp is generated from Remote Device devices receiving a broadcast NWK_addr_req who 25
detect a match of the IEEEAddr parameter with their own IEEE address. The destination addressing on the 26
response primitive is unicast. 27
28
30
Upon receipt, a Remote Device shall attempt to match the IEEEAddr in the NWK_addr_req with the
31
Remote Device's IEEE address. If no match exists, the request shall be discarded and no response message
32
processing performed. If a match is detected, the Remote Device shall create a unicast message to the source
33
indicated by the NWK_addr_req. Included in the NWK_addr_rsp payload is the IEEE address that matched
34
from the NWK_addr_req and the NWK address of the Remote Device. Additionally, if the Remote Device is
35
the ZigBee coordinator or router with associated devices, the Remote Device shall supply a count of its
36
associated devices along with a list of all 16 bit NWK addresses for its associated devices.54
37
The DEVICE_NOT_FOUND status shall be treated as reserved for Version 1.0 and is to be used only with 38
future unicast forms of the NWK_addr_req primitive. 39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
CCB Comment #171 54

1 1.4.4.1.2 IEEE_addr_rsp
2
4
6
7 ClusterID=0x81 IEEE_addr_rsp (
8 Status
9 IEEEAddrRemoteDev
NWKAddrRemoteDev
10 NumAssocDev
11 StartIndex
12 NWKAddrAssocDevList
13 )
14
15 Table 64 specifies the parameters for the IEEE_addr_rsp primitive.
16
17 Table 64 IEEE_addr_rsp parameters
19 The status of the IEEE_addr_req
Status SUCCESS,
20 command.a
Integer INV_REQUESTTYPE or
21
DEVICE_NOT_FOUND
22
23 IEEEAddrRemoteDev Device An extended 64 bit, IEEE 64 bit address for the Remote
24 Address address Device.
25
NWKAddrRemoteDev Device 16 bit address for the Remote
26 A 16 bit, NWK address
Address Device.
27
28 NumAssocDev Count of the number of associated
29 devices to the Remote Device and
the number of 16 bit short addresses
30 to follow. NumAssocDev shall be 0 if
31 the RequestType in the request is
32 Extended Response and there are
33 no associated devices to Remote
Integer 0x00-0xff
34 Device and the NWKAddrAssocDev-
List shall be null in this case.
35
36 If the RequestType in the request is
37 for a Single Device Response, this
38 field and the ones following shall be
39 NULL.
40 StartIndex Starting index into the list of associ-
ated devices for this report.
42
43 NWKAddrAssocDevList A list of 16 bit addresses, one corre-
sponding to each associated device
44 List of 16 bit short
to Remote Device. The count of the
45 Device addresses, each with
16 bit addresses in NWKAddrAs-
Address List range 0x0000-ffff,
46 socDevList is supplied in NumAs-
NumAssocDev in length
47 socDev. This field shall be NULL if
48 the NumAssocDev is 0 or NULL.
49 aCCB
Comment #223
50
51
52
53
54


2
The IEEE_addr_rsp is generated from Remote Devices in response to the unicast IEEE_addr_req inquiring 3
as to the 64 bit IEEE address of the Remote Device. The destination addressing on this response primitive 4
shall be unicast. 5
6
8
Upon receipt, a Remote Device shall create a unicast message to the source indicated by the IEEE_addr_req
9
and report its IEEE address as the first entry in the response payload. Additionally, if the RequestType is
10
Extended Response and the Remote Device is the ZigBee coordinator or router with associated devices, the
11
Remote Device shall first include its own 64 bit IEEE address and then shall also supply a count of its
12
associated devices along with a list of all 16 bit addresses for its associated devices beginning with
13
StartIndex. If the RequestType is Extended Response and the Remote Device has no associated devices, the
14
NumAssocDev field shall be 0 and the StartIndex plus NWKAddrAssocDevList shall be NULL. If the
15
RequestType is Single Device Response, the NumAssocDev and NKWAddrAssocDevList shall both be
16
NULL.55
17
future forms of the IEEE_addr_req primitive. 19
20
1.4.4.1.3 Node_Desc_rsp 21
22
24
26
ClusterID=0x82 Node_Desc_rsp ( 27
Status 28
NodeDescriptor 30
)
31
32
Table 65 specifies the parameters for the Node_Desc_rsp primitive. 33
34
Table 65 Node_Desc_rsp parameters
35
Status SUCCESS or The status of the Node_Desc_req 37
Integer command.a 38
DEVICE_NOT_FOUND
39
16 bit NWK address
Address
41
NodeDescriptor Node See the Node Descriptor format in sub- 42
Descriptor clause 1.3.3.4. 43
a
44
CCB Comment #223 45
46
48
The Node_Desc_rsp is generated by the Remote Device in response to a Node_Desc_req directed to the 49
Remote Device. A Status of SUCCESS is supplied with the response. 50
51
52
53
55
CCB Comment #171 54


2
3 The Node_Desc_req requests retrieval of the Remote Device’s Node Descriptor. The Remote Device shall
4 formulate a Node_Desc_rsp with a Status of SUCCESS, including the Remote Device’s Node Descriptor
5 and transmit the Node_Desc_rsp to the Local Device.
6
The DEVICE_NOT_FOUND status shall be treated as reserved for Version 1.0 and is to be used only with
7
future forms of the primitive.
8
9
1.4.4.1.4 Power_Desc_rsp
10
11
12
14
15
ClusterID=0x83 Power_Desc_rsp (
16 Status
18 PowerDescriptor
19 )
20
21 Table 66 specifies the parameters for the Power_Desc_rsp primitive.
22
23 Table 66 Power_Desc_rsp parameters
25 The status of the Power_Desc_req
Status SUCCESS or
26 Integer command.a
DEVICE_NOT_FOUND
27
28 NWKAddrOfInterest Device NWK address for the request.
16 bit NWK address
29 Address
30
PowerDescriptor Power See the Node Power Descriptor format
31 Descriptor in sub-clause 1.3.3.5.
32
aCCB
33 Comment #223
34
35
36
37 The Power_Desc_rsp is generated by the Remote Device in response to a Power_Desc_req directed to the
38 Remote Device. A Status of SUCCESS is supplied with the response.
39
41
42 The Power_Desc_req requests retrieval of the Remote Device’s Node Power Descriptor. The Remote Device
43 shall formulate a Power_Desc_rsp with a Status of SUCCESS, including the Remote Device’s Node Power
44 Descriptor and transmit the Power_Desc_rsp to the Local Device.
45
46 The DEVICE_NOT_FOUND status shall be treated as reserved for Version 1.0 and is to be used only with
47 future forms of the primitive.
48
49
50
51
52
53
54

1.4.4.1.5 Simple_Desc_rsp 1
2
4
6
ClusterID=0x84 Simple_Desc_rsp ( 7
Status 8
NWKAddrOfInterest 9
Length
SimpleDescriptor 10
) 11
12
13
Table 67 specifies the parameters for the Simple_Desc_rsp primitive.
14
Table 67 Simple_Desc_rsp parameters 15
17
Status SUCCESS, The status of the Simple_Desc_req
18
INVALID_EP, command.a
Integer 19
NOT_ACTIVE or 20
DEVICE_NOT_FOUND 21
Address
24
Length Length in bytes of the Simple Descrip- 25
Integer 0x00-0xff
tor to follow.
26
SimpleDescriptor See the Simple Descriptor format in 27
sub-clause 1.3.3.6. 28
Simple 29
Descriptor This field shall be NULL if a Status of 30
INVALID_EP or NOT_ACTIVE is sup-
plied. 31
32
aCCB 33
Comment #223
34
35
The Simple_Desc_rsp is generated in response to a Simple_Desc_req. The request contains an endpoint for 37
which the Simple Descriptor is requested. 38
39
41
When the Simple_Desc_req is presented, the endpoint is checked for valid range and then the endpoint 42
parameter is checked with the list of Simple Descriptors in the Remote Device associated with active 43
endpoints. If an endpoint value of 0 (zero) or greater than 240 is detected, the Status is set to INVALID_EP, 44
the SimpleDescriptor field is set NULL and the Simple_Desc_rsp is supplied back to the requestor. If the 45
endpoint field is valid but the endpoint field is not described by a Simple Descriptor on the Remote Device, 46
the Status is set to NOT_ACTIVE, and the Simple Descriptor set to NULL and the response supplied. Else, 47
the Status is set to SUCCESS, and the Simple Descriptor associated with the indicated endpoint is supplied 48
in the response. 49
50
future forms of the primitive. 52
53
54

1 1.4.4.1.6 Active_EP_rsp
2
4
6
7 ClusterID=0x85 Active_EP_rsp (
8 Status
9 NWKAddrOfInterest
ActiveEPCount
10 ActiveEPList
11 )
12
13
Table 68 specifies the parameters for the Active_EP_rsp primitive.
14
15 Table 68 Active_EP_rsp parameters
17
Status SUCCESS or The status of the Active_EP_req
18 Integer
DEVICE_NOT_FOUND command.a
19
21 16 bit NWK address
Address
22
23 ActiveEPCount The count of active endpoints on the
Integer 0x00-0xff
Remote Device.
24
25 ActiveEPList List of bytes each of which represents
26 an 8 bit endpoint.
27 aCCB
28 Comment #223
29
31
32 The Active_EP_rsp is generated in response to an Active_EP_req.
33
35
36 Upon receipt of the Active_EP_req, the Remote Device shall determine all endpoints supporting a Simple
37 Descriptor within the Remote Device and shall provide the count within ActiveEPCount and shall supply the
38 list of active endpoints as a string of bytes of length ActiveEPCount. A Status of SUCCESS is supplied
39 along with the response parameters and returned in the Active_EP_rsp.
40
The DEVICE_NOT_FOUND status shall be treated as reserved for Version 1.0 and is to be used only with
41
future forms of the primitive.
42
43
1.4.4.1.7 Match_Desc_rsp
44
45
46
48
49
ClusterID=0x86 Match_Desc_rsp (
50 Status
52 MatchLength
53 MatchList
54 )

Table 69 specifies the parameters for the Match_Desc_rsp primitive. 1

2
Table 69 Match_Desc_rsp parameters 3
Status SUCCESS or The status of the Match_Desc_req 5
Integer command.a 6
DEVICE_NOT_FOUND
7
16 bit NWK address
Address 9
MatchLength The count of endpoints on the Remote 10
Device that match the request criteria.
12
MatchList List of bytes each of which represents 13
an 8 bit endpoint.
14
a
CCB Comment #223 15
16
17
19
The Match_Desc_rsp is generated when a Remote Device has received a Match_Desc_req and has verified a 20
match of the ProfileID parameter and any of the elements of the InClusterList or OutClusterList with any 21
Simple Descriptor held on the Remote Device. 22
23
When the Match_Desc_req is received, the Remote Device shall attempt to match the ProfileID, 25
InClusterList or OutClusterList with all Simple Descriptors on the Remote Device. The ProfileID must 26
match exactly, however, a match shall still be noted if any of the InClusterList or OutClusterList elements 27
match. If no match is detected, the Match_Desc_req shall be discarded and no response provided. If a match 28
is detected, the Remote Device shall create a response to the Local Device providing the count and list of 29
endpoints along with a status of SUCCESS. 30
31
34
1.4.4.1.8 Complex_Desc_rsp 35
36
38
40
ClusterID=0x90 Complex_Desc_rsp ( 41
Status 42
Length
44
ComplexDescriptor
) 45
46
47
48
49
50
51
52
53
54

1 Table 70 specifies the parameters for the Complex_Desc_rsp primitive.

2
3 Table 70 Complex_Desc_rsp parameters
5 Status SUCCESS or The status of the Complex_Desc_req
6 Integer command.a
NOT_SUPPORTED
7
16 bit NWK address
9 Address
10 Length Length of the Complex Descriptor in
11 bytes.
13 This field shall be omitted if the Status
14 is NOT_SUPPORTED.
15 ComplexDescriptor See the Complex Descriptor format in
16 sub-clause 1.3.3.7.
Complex
17 Descriptor
18 This field shall be NULL if the Status is
NOT_SUPPORTED.
19
20 aCCB
Comment #223
21
22
24
25 The Complex_Desc_rsp is generated by devices receiving the Complex_Desc_req and who support the
26 optional Complex Descriptor (see sub-clause 1.3.3.7).
27
29 Upon receipt of the Complex_Desc_rsp, the Remote Device determines if the Complex Descriptor is
30 supported. If the Complex Descriptor is not supported on the Remote Device, a Status of
31 NOT_SUPPORTED is returned with the Complex_Desc_rsp. If the Complex Descriptor is supported, the
32 Remote Device shall determine the Length of the Complex Descriptor in bytes and store that in the Length
33 parameter of the response. The contents of the Complex Descriptor shall be included in the
34 ComplexDescriptor parameter, a Status of SUCCESS applied and the Complex_Desc_rsp returned to the
35 requesting Local Device.
36
37 The DEVICE_NOT_FOUND status shall be treated as reserved for Version 1.0 and is to be used only with
38 future forms of the primitive.
39
40 1.4.4.1.9 User_Desc_rsp
41
43
45
46 ClusterID=0x91 User_Desc_rsp (
47 Status
Length
49
UserDescriptor
50 )
51
52
53
54

Table 71 specifies the parameters for the User_Desc_rsp primitive. 1

2
Table 71 User_Desc_rsp parameters 3
Status SUCCESS or The status of the User_Desc_req 5
Integer command.a 6
NOT_SUPPORTED
7
16 bit NWK address
Address 9
Length Length of the User Descriptor in bytes. 10
11
Integer 0x00-0xff
This field shall be omitted if the Status 12
is NOT_SUPPORTED. 13
14
UserDescriptor See the User Descriptor format in sub-
clause 1.3.3.8. 15
User 16
Descriptor
This field shall be NULL if the Status is 17
NOT_SUPPORTED. 18
aCCB 19
Comment #223
20
21
23
The User_Desc_rsp is generated by devices receiving the User_Desc_req and who support the optional User 24
Descriptor (see sub-clause 1.3.3.8). 25
26
28
Upon receipt of the User_Desc_rsp, the Remote Device determines if the User Descriptor is supported. If the
29
User Descriptor is not supported on the Remote Device, a Status of NOT_SUPPORTED is returned with the
30
User_Desc_rsp. If the User Descriptor is supported, the Remote Device shall determine the Length of the
31
User Descriptor in bytes and store that in the Length parameter of the response. The contents of the User
32
Descriptor shall be included in the UserDescriptor parameter, a Status of SUCCESS applied and the
33
User_Desc_rsp returned to the requesting Local Device.
34
37
1.4.4.1.10 Discovery_Register_rsp 38
39
41
43
ClusterID=0x92 Discovery_Register_rsp ( 44
Status 45
) 46
47
Table 72 specifies the parameters for the Discovery_Register_rsp primitive. 48
49
Table 72 Discovery_Register_rsp parameters 50
The status of the 52
Status SUCCESS or
Integer Discovery_Register_req command.a 53
NOT_SUPPORTED
54

1 a
CCB Comment #223
2
3
5
6 The Discovery_Register_rsp is generated by devices receiving the Discovery_Register_req and who support
7 the optional post Version 1.0 discovery registration procedure.
8
10 Upon receipt of the Discovery_Register_rsp, the Remote Device determines if discovery registration is
11 supported. For Version 1.0, a status of NOT_SUPPORTED shall be returned.56
12
13 1.4.4.1.11 User_Desc_conf
14
16
18
19 ClusterID=0x94 User_Desc_conf (
20 Status
21 )
22
23 Table 73 specifies the parameters for the User_Desc_conf primitive.
24
25 Table 73 User_Desc_conf parameters
27
Status SUCCESS or The status of the User_Desc_set
28 Integer command.
NOT_SUPPORTED
29
30
31
32
33 The User_Desc_conf command is generated in response to a User_Desc_conf command. If this command is
34 not supported or a user description does not exist, a status of NOT_SUPPORTED shall be returned.
35 Otherwise, the Remote Device shall configure the user descriptor and return a status of SUCCESS.
36
38
39 The local device is notified of the results of its attempt to configure the user descriptor on a remote device.57
40
41
42
43
44
45
46
47
48
49
50
51
52
57
54 CCB Comment #176

1.4.4.2 End Device Bind, Bind and Unbind server services 1

2
Table 74 lists the primitives supported by Device Profile End Device Bind, Bind and Unbind Server 3
Services. Each of these primitives will be discussed in the following sub-clauses. 4
Table 74 End Device Bind, Bind and Unbind Server Services primitives 5
6
End Device Bind, 7
Server
Bind and Unbind
Processing 8
Server Services
9
End_Device_Bind_rsp Oa 10
11
Bind_rsp Ob
12
Unbind_rsp Oc 13
14
a Must minimally respond with a status of NOT_SUPPORTED
b
15
c Must minimally respond with a status of NOT_SUPPORTED
16
17
18
1.4.4.2.1 End_Device_Bind_rsp 19
20
22
24
ClusterID=0xA0 End_Device_Bind_rsp ( 25
Status 26
) 27
28
Table 75 specifies the parameters for the End_Device_Bind_rsp primitive. 29
30
Table 75 End_Device_Bind_rsp parameters 31
The status of the End_Device_Bind_req 33
Status SUCCESS,
command.a 34
NOT_SUPPORTED,
Integer 35
TIMEOUT or
36
NO_MATCH
37
39
40
42
The End_Device_Bind_rsp is generated by the ZigBee Coordinator in response to an End_Device_Bind_req
43
and contains the status of the request. A Status of NOT_SUPPORTED indicates that the request was directed
44
to a device which was not the ZigBee Coordinator or that the ZigBee Coordinator does not support End
45
Device Binding. Else, End_Device_Bind_req processing is performed as described below including
46
transmission of the End_Device_Bind_rsp.
47
48
49
When an End_Device_Bind_req is received, determination is made if a Status of NOT_SUPPORTED is 50
warranted as indicated in the previous section. Assuming this device is the ZigBee Coordinator, if this is the 51
first End_Device_Bind_req submitted for evaluation, it shall be stored and a timer started which expires at a 52
pre-configured timeout value. This timeout values shall be a configurable item on the ZigBee Coordinator. If 53
54

1 the timer expires before a second End_Device_Bind_req is received, a Status of TIMEOUT is returned.
2 Else, if a second End_Device_Bind_req is received within the timeout window, the two
3 End_Device_Bind_req's are compared for a match. A Status of NO_MATCH indicates that two
4 End_Device_Bind_req were evaluated for a match but either the ProfileID parameters did not match or the
5 ProfileID parameter matched but there was no match of any element of the InClusterList or OutClusterList.
6 A Status of SUCCESS means that a match was detected and that a resulting Bind_req has been directed to
7 the parent device of the Local Device supplying the End_Device_Bind_req which supplied matched
8 elements of the OutClusterList.58
9
10 1.4.4.2.2 Bind_rsp
11
13
15
16 ClusterID=0xA1 Bind_rsp (
17 Status
18 )
19
20 Table 76 specifies the parameters for the Bind_rsp primitive.
21
Table 76 Bind_rsp parameters
22
24 Status SUCCESS, The status of the Bind_req command.a
25 Integer NOT_SUPPORTED or
26 TABLE_FULL
27
aCCB
28 Comment #223
29
30
31
32 The Bind_rsp is generated in response to a Bind_req. If the Bind_req is processed and the Binding Table
33 entry committed on the Remote Device, a Status of SUCCESS is returned. If the Remote Device is not the
34 ZigBee Coordinator or the SrcAddress, a Status of NOT_SUPPORTED is returned. If the Remote Device is
35 the ZigBee Coordinator or SrcAddress but does not have Binding Table resources for the request, a Status of
36 TABLE_FULL is returned.
37
39
40 Upon receipt, error checking is performed on the request as described in the previous section. Assuming the
41 Status is SUCCESS, the parameters from the Bind_req are entered into the Binding Table at the Remote
42 Device via the APSME-BIND.request primitive.
43
44
45
46
47
48
49
50
51
52
53
58
54 CCB Comment 3171

1.4.4.2.3 Unbind_rsp 1
2
4
6
ClusterID=0xA2 Unbind_rsp ( 7
Status 8
) 9
10
Table 77 specifies the parameters for the Unbind_req primitive. 11
12
Table 77 Unbind_rsp parameters
13
Status SUCCESS, The status of the Bind_req command.a 15
Integer NOT_SUPPORTED or 16
TABLE_FULL 17
18
aCCB
Comment #223 19
20
21
22
The Unbind_rsp is generated in response to an Unbind_req. If the Unbind_req is processed and the 23
corresponding Binding Table entry is removed from the Remote Device, a Status of SUCCESS is returned. 24
If the Remote Device is not the ZigBee Coordinator or the SrcAddress, a Status of NOT_SUPPORTED is 25
returned. If the Remote Device is the ZigBee Coordinator or SrcAddress but does not have a Binding Table 26
entry corresponding to the parameters received in the request, a Status of NO_ENTRY is returned. 27
28
30
Upon receipt, error checking is performed on the request as described in the previous section. Assuming the 31
Status is SUCCESS, the parameters from the Unbind_req are used to find the corresponding entry to remove 32
from the Binding Table at the Remote Device via the APSME-UNBIND.request primitive. 33
34
1.4.4.3 Network Management server services 35
36
Table 78 lists the primitives supported by Device Profile Network Management Server Services. Each of 37
these primitives will be discussed in the following sub-clauses. 38
Table 78 Network Management Server Services primitives 39
40
Network Management Server 41
Server Services Processing 42
Mgmt_NWK_Disc_rsp Oa 43
44
Mgmt_Lqi_rsp Ob 45
Mgmt_Rtg_rsp Oc 46
47
Mgmt_Bind_rsp Od 48
49
Mgmt_Leave_rsp Oe
50
Mgmt_Direct_Join_rsp Of 51
52
a
Must minimally respond with a status of NOT_SUPPORTED 53
b
54

c
1 Must minimally respond with a status of NOT_SUPPORTED
d Must minimally respond with a status of NOT_SUPPORTED
2
e Must minimally respond with a status of NOT_SUPPORTED
3 f
4
5
6 1.4.4.3.1 Mgmt_NWK_Disc_rsp
7
9
11
12 ClusterID=0xB0 Mgmt_NWK_Disc_rsp (
13 Status
14 NetworkCount
15 StartIndex
NetworkListCount
16 NetworkList
17 )
18
19
Table 79 specifies the parameters for the Mgmt_NWK_Disc_rsp primitive.
20
21 Table 79 Mgmt_NWK_Disc_rsp parameters
23
Status NOT_SUPPORTED or any The status of the Mgmt_NWK_Disc_req
24
status code returned from command.a
25
Integer the
26
NLME-NETWORK-DIS-
27 COVERY.request primitive.
28
29 NetworkCount The total number of networks reported
30 Integer 0x00-0xff by the NLME-NETWORK-DISCOV-
ERY.confirm.
31
32 StartIndex The starting point in the NetworkList
33 from the NLME-NETWORK-DISCOV-
Integer 0x00-0xff
34 ERY.confirm where reporting begins for
this response.
35
36 NetworkListCount The number of network list descriptors
Integer 0x00-0xff
37 reported within this response.
38
NetworkList A list of descriptors, one for each of the
39
networks discovered by the NLME-NET-
40 WORK-DISCOVERY primitive. The list
41 returned by NLME-NETWORK-DIS-
The list shall contain the
42 List of Net- COVERY.confirm shall be used for refer-
number of elements given
43 work Descrip- ence and this response shall begin with
by the NetworkListCount
tors the StartIndex element and continue for
44 parameter.
NetworkListCount which shall be defined
45 to ensure that the resultant MSDU will
46 be no greater than aMaxMACFrameSize
47 octets in size (see [B1]).b
48 a
CCB Comment #223, 237
49 bCCB Comment #366
50
51
52
53
54


2
The Mgmt_NWK_Disc_rsp is generated in response to an Mgmt_NWK_Disc_req. If this management 3
command is not supported, a status of NOT_SUPPORTED shall be returned and all parameter fields after 4
the Status field shall be omitted. Otherwise, the Remote Device shall implement the following processing: 5
6
"Perform an NLME-NETWORK-DISCOVERY.request using the ScanChannels parameter
7
supplied with the Mgmt_NWK_Disc_req.
8
"Upon receipt of the NLME-NETWORK-DISCOVERY.confirm, report the NetworkList results, 9
starting with the StartIndex element, via the Mgmt_NWK_Disc_rsp. Include the NetworkCount parameter 10
from the NLME-NETWORK-DISCOVERY.confirm as the same parameter within Mgmt_NWK_Disc_rsp. 11
12
"Include as many NetworkList elements as possible while ensuring that the resulting MSDU will 13
no greater than aMaxMACFrameSize octets in size59. Report the number of included NetworkList entries 14
within NetworkListCount.60 15
16
18
The local device is notified of the results of its attempt to perform a remote network discovery.61 19
20
1.4.4.3.2 Mgmt_Lqi_rsp 21
22
24
25
26
ClusterID=0xB1 Mgmt_Lqi_rsp ( 27
Status
28
NeighborTableEntries
StartIndex 29
NeighborTableListCount 30
NeighborTableList 31
) 32
33
Table 81 specifies the parameters for the Mgmt_Lqi_rsp primitive. 34
35
Table 80 Mgmt_Lqi_rsp parameters 36
Status NOT_SUPPORTED or any The status of the Mgmt_Lqi_req 38
status code returned from command.a 39
Integer
the NLME-GET.confirm 40
primitive 41
42
NeighborTableEntries Total number of Neighbor Table
entries within the Remote Device.
44
45
46
47
48
49
50
51
59
CCB COmment #366 52
60CCB Comment #237, 250 53
61
CCB Comment #250 54

1 Table 80 Mgmt_Lqi_rsp parameters

2
StartIndex Starting index within the Neighbor
3 Integer 0x00-0xff Table to begin reporting for the
4 NeighborTableList.
5
6 NeighborTableListCount Number of Neighbor Table entries
Integer 0x00-0xff
included within NeighborTableList.
7
8 NeighborTableList A list of descriptors, beginning with
9 the StartIndex element and
10 The list shall contain the continuing for
List of Neigh- NeighborTableListCount, of the
11 number elements given by
bor Descrip-
12 the NeighborTableList- elements in the Remote Device's
tors
Count Neighbor Table including the device
13
address and associated LQI (see
14
Table 81 for details).b
15
aCCB Comment #223
16
bCCB Comment #237,
17 239
18
19 Table 81 NeighborTableList record format
20
21
22 PAN Id The 16-bit PAN identifier of the
Integer 0x0000-0x3fff
23 neighboring device.
24 Extended address An extended 64-bit, IEEE 64-bit IEEE address that is unique
25 Integer
address to every device.
26
27 Network address Network The 16-bit network address of the
Network address
address neighboring device.
28
29 Device type The type of the neighbor device:
30
31 0x00 = ZigBee coordinator.
32 Integer 0x00-0x03
0x01 = ZigBee router.
33
34 0x02 = ZigBee end device.
35
36 RxOnWhenIdle Indicates if neighbor's receiver is
enabled during idle portions of the
37
CAPa:
38 Boolean TRUE or FALSE
39 TRUE = Receiver is off.
40
41 FALSE = Receiver is on.
42 Relationship The relationship between the
43 neighbor and the current device:
44
45 0x00=neighbor is the parent.
46 Relationship 0x00-0x03
0x01 = neighbor is a child.
47
48 0x02 = neighbor is a sibling.
49
50 0x03 = None of the above.
51
52
53
54

Table 81 NeighborTableList record format 1

2
Depth The tree depth of the neighbor
device. A value of 0x00 indicates 3
Integer 0x00-nwkcMaxDepth 4
that the device is the ZigBee coor-
dinator for the network. 5
6
Permit joining An indication of whether the neigh-
7
bor device is accepting join
requests: 8
9
Boolean TRUE or FALSE TRUE = neighbor is accepting join 10
requests. 11
12
FALSE = neighbor is not accepting
join requests. 13
14
LQI The estimated link quality for RF 15
transmissions from this device. See 16
Integer 0x00-0xff
[B1] for discussion of how this is
calculated.b 17
18
aCCB Comment 138 19
bCCB Comment #239
20
21
23
The Mgmt_Lqi_rsp is generated in response to an Mgmt_Lqi_req. If this management command is not 24
supported, a status of NOT_SUPPORTED shall be returned and all parameter fields after the Status field 25
shall be omitted. Otherwise, the Remote Device shall implement the following processing. 26
27
Upon receipt of and after support for the Mgmt_Lqi_req has been verified, the Remote Device shall perform 28
an NLME-GET.request (for the nwkNeighborTable attribute) and process the resulting neighbor table 29
(obtained via the NLME-GET.confirm primitive) to create the Mgmt_Lqi_rsp command. If 30
nwkNeighborTable was successfully obtained but one or more of the fields required in the 31
NeighborTableList record (see Table 81) are not supported (as they are optional), the Mgmt_Lqi_rsp shall 32
return a status of NOT_SUPPORTED and all parameter fields after the Status field shall be omitted. 33
Otherwise, the Mgmt_Lqi_rsp command shall contain the same status that was contained in the NLME- 34
GET.confirm primitive and if this was not SUCCESS, all parameter fields after the status field shall be 35
omitted. 36
37
From the nwkNeighborTable attribute, the neighbor table shall be accessed, starting with the index specified
38
by StartIndex, shall be moved to the NeighborTableList field of the Mgmt_Lqi_rsp command. The entries
39
reported from the neighbor table shall be those, starting with StartIndex and including whole
40
NeighborTableList records (see Table 81) until the limit on MSDU size, i.e. aMaxMACFrameSize (see
41
[B1])62, is reached. Within the Mgmt_Lqi_Rsp command, the NeighborTableEntries field shall represent the
42
total number of Neighbor Table entries in the Remote Device. The parameter NeighborTableListCount shall
43
be the number of entries reported in the NeighborTableList field of the Mgmt_Lqi_rsp command.63
44
45
46
The local device is notified of the results of its attempt to obtain the neighbor table.64 47
48
49
50
51
62
CCB Comment #366 52
63CCB Comment #239, 247, 250 53
64
CCB Comment #250 54

1 1.4.4.3.3 Mgmt_Rtg_rsp
2
4
6
7 ClusterID=0xB2 Mgmt_Rtg_rsp (
8 Status
9 RoutingTableEntries
StartIndex
10 RoutingTableListCount
11 RoutingTableList
12 )
13
14 Table 82 specifies the parameters for the Mgmt_Rtg_rsp primitive.
15
16 Table 82 Mgmt_Rtg_rsp parameters
18
Status NOT_SUPPORTED or any The status of the Mgmt_Rtg_req
19 command.a
status code returned from
20 Integer
the NLME-GET.confirm
21 primitive
22
23 RoutingTableEntries Total number of Routing Table
Integer 0x00-0xff
24
25 StartIndex Starting index within the Routing
26 Integer 0x00-0xff Table to begin reporting for the Rout-
27 ingTableList.
28 RoutingTableListCount Number of Routing Table entries
included within RoutingTableList.
30
RoutingTableList A list of descriptors, beginning with
31
the StartIndex element and
32
List of Rout- The list shall contain the continuing for
33 ing Descrip- number elements given by RoutingTableListCount, of the
34 tors the RoutingTableListCount elements in the Remote Device's
35 Routing Table (see the Table 83 for
36 details).b
38 bCCB Comment #237, 239
39
40
41
42 Table 83 RoutingTableList record format
44
Destination address The 16-bit network address Destination address.
45 2 bytes
of this route.
46
47 Status 0x0=ACTIVE.
48
49 0x1=DISCOVERY_UNDERWAY.
50 3 bits The status of the route. 0x2=DISCOVERY_FAILED.
51
52 0x3=INACTIVE.
53
54 0x4-0x7=RESERVED.

Next-hop address The 16-bit network address Next-hop address.a 1

2 bytes of the next hop on the way 2
to the destination. 3
a
4
CCB Comment #239 5
6
The Mgmt_Rtg_rsp is generated in response to an Mgmt_Rtg_req. If this management command is not 8
supported, a status of NOT_SUPPORTED shall be returned and all parameter fields after the Status field 9
shall be omitted. Otherwise, the Remote Device shall implement the following processing. 10
11
Upon receipt of and after support for the Mgmt_Rtg_req has been verified, the Remote Device shall perform 12
an NLME-GET.request (for the nwkRouteTable attribute) and process the resulting NLME-GET.confirm 13
(containing the nwkRouteTable attribute) to create the Mgmt_Rtg_rsp command. The Mgmt_Rtg_rsp 14
command shall contain the same status that was contained in the NLME-GET.confirm primitive and if this 15
was not SUCCESS, all parameter fields after the status field shall be omitted. 16
17
From the nwkRouteTable attribute, the routing table shall be accessed, starting with the index specified by 18
StartIndex, and moved to the RoutingTableList field of the Mgmt_Rtg_rsp command. The entries reported 19
from the routing table shall be those, starting with StartIndex and including whole RoutingTableList records 20
(see Table 82) until MSDU size limit, i.e aMaxMACFrameSize (see [B1])65, is reached. Within the 21
Mgmt_Rtg_Rsp command, the RoutingTableEntries field shall represent the total number of Routing Table 22
entries in the Remote Device. The RoutingTableListCount field shall be the number of entries reported in the 23
RoutingTableList field of the Mgmt_Rtg_req command.66 24
25
27
The local device is notified of the results of its attempt to obtain the routing table.67 28
29
1.4.4.3.4 Mgmt_Bind_rsp 30
31
34
35
ClusterID=0xB3 Mgmt_Bind_rsp (
36
Status
BindingTableEntries 37
StartIndex 38
BindingTableListCount 39
BindingTableList 40
)
41
42
43
44
45
46
47
48
49
50
51
65
CCB Comment #366 52
66CCB Comment #224, 237, 239, 250 53
67
CCB Comment #250 54

1 Table 84 specifies the parameters for the Mgmt_Bind_rsp primitive.

2
3 Table 84 Mgmt_Bind_rsp parameters
5 NOT_SUPPORTED or any The status of the Mgmt_Bind_req
6 status code returned from command.a
Status Integer
7 the APSME-GET.confirm
8 primitive
9
Total number of Binding Table
10 BindingTableEntries Integer 0x00-0xff
11
12 Starting index within the Binding
13 StartIndex Integer 0x00-0xff Table to begin reporting for the Bind-
ingTableList.
14
15 Number of Binding Table entries
BindingTableListCount Integer 0x00-0xff
16 included within BindingTableList.
17 A list of descriptors, beginning with
18 the StartIndex element and
19 List of Bind- The list shall contain the continuing for
20 BindingTableList ing Descrip- number elements given by BindingTableListCount, of the
21 tors the BindingTableListCount elements in the Remote Device's
22 Binding Table (see Table 85 for
23 details).b
25 bCCB Comment #237,
239
26
27
28
Table 85 BindingTableList record format
29
31 SrcAddr The source IEEE address for the
32 IEEE address A valid 64-bit IEEE address
binding entry.
33
34 SrcEndpoint The source endpoint for the binding
Integer 0x01 - 0xff
entry.
35
36 ClusterId The identifier of the cluster on the
37 Integer 0x00 - 0xff source device that is bound to the
38 destination device.
39
DstAddr The destination IEEE address for the
40 IEEE address A valid 64-bit IEEE address
binding entry.
41
42 DstEndpoint The destination endpoint for the bind-
Integer 0x01 - 0xff
43 ing entry.a
44 aCCB
Comment #239
45
46
47
48 The Mgmt_Bind_rsp is generated in response to a Mgmt_Bind_req. If this management command is not
49 supported, a status of NOT_SUPPORTED shall be returned and all parameter fields after the Status field
50 shall be omitted. Otherwise, the Remote Device shall implement the following processing.
51
52 Upon receipt of and after support for the Mgmt_Bind_req has been verified, the Remote Device shall
53 perform an APSME-GET.request (for the apsBindingTable attribute) and process the resulting APSME-
54 GET.confirm (containing the apsBindingTable attribute) to create the Mgmt_Bind_rsp command. The

Mgmt_Bind_rsp command shall contain the same status that was contained in the APSME-GET.confirm 1
primitive and if this was not SUCCESS, all parameter fields after the status field shall be omitted. 2
3
From the apsBindingTable attribute, the binding table shall be accessed, starting with the index specified by 4
StartIndex, and moved to the BindingTableList field of the Mgmt_Bind_rsp command. The entries reported 5
from the binding table shall be those, starting with StartIndex and including whole BindingTableList records 6
(see Table 85) until the MSDU size limit, i.e. aMaxMACFrameSize (see [B1])68, is reached. Within the 7
Mgmt_Bind_Rsp command, the BindingTableEntries field shall represent the total number of Binding Table 8
entries in the Remote Device. The BindingTableListCount field shall be the number of entries reported in the 9
BindingTableList field of the Mgmt_Bind_req command.69 10
11
13
The local device is notified of the results of its attempt to obtain the binding table.70
14
15
1.4.4.3.5 Mgmt_Leave_rsp
16
17
18
20
21
ClusterID=0xB4 Mgmt_Leave_rsp (
Status 22
) 23
24
25
Table 86 specifies the parameters for the Mgmt_Leave_rsp primitive.
26
Table 86 Mgmt_Leave_rsp parameters 27
29
NOT_SUPPORTED or any The status of the Mgmt_Leave_req
30
status code returned from command.a
Status Integer 31
the NLME-LEAVE.confirm
primitive 32
33
aCCB
Comment #223, 237 34
35
36
37
The Mgmt_Leave_rsp is generated in response to a Mgmt_Leave_req. If this management command is not 38
supported, a status of NOT_SUPPORTED shall be returned. Otherwise, the Remote Device shall implement 39
the following processing. 40
41
Upon receipt of and after support for the Mgmt_Leave_req has been verified, the Remote Device shall 42
execute the NLME-LEAVE.request to disassociate from the currently associated network. The 43
Mgmt_Leave_rsp shall contain the same status that was contained in the NLME-LEAVE.confirm primitive. 44
45
Once a device has disassociated, it shall execute pre-programmed logic to perform NLME-NETWORK- 46
DISCOVERY and NLME-JOIN to join/re-join a network.71 47
48
49
50
68
CCB Comment #366 51
69
CCB Comment #237, 239, 248, 250 52
71


2
3 The local device is notified of the results of its attempt to cause a remote device to leave the network.72
4
5 1.4.4.3.6 Mgmt_Direct_Join_rsp
6
8
9
10
ClusterID=0xB5 Mgmt_Direct_Join_rspa (
11
Status
12
)
13
14 a
CCB Comment #209
15
16 Table 87 specifies the parameters for the Mgmt_Direct_Join_rsp primitive.
17
18 Table 87 Mgmt_Direct_Join_rsp parameters
20 NOT_SUPPORTED or any The status of the Mgmt_Direct_Join_req
21 status code returned from command.a
Status Integer
22 the NLME-DIRECT-
23 JOIN.confirm primitive
24 aCCB
Comment #223, 237
25
26
28
29 The Mgmt_Direct_Join_rsp is generated in response to a Mgmt_Direct_Join_req. If this management
30 command is not supported, a status of NOT_SUPPORTED shall be returned. Otherwise, the Remote Device
31 shall implement the following processing.
32
33 Upon receipt of and after support for the Mgmt_Direct_Join_req has been verified, the Remote Device shall
34 execute the NLME-DIRECT-JOIN.request to directly associate the DeviceAddress contained in the
35 Mgmt_Direct_Join_req to the network. The Mgmt_Direct_Join_rsp shall contain the same status that was
36 contained in the NLME-DIRECT-JOIN.confirm primitive.73
37
39 Upon receipt and after support for the Mgmt_Direct_Join_req has been verified, the Remote Device shall
40 execute the NLME-JOIN.request using the JoinDirectly parameter set to TRUE to directly associate the
41 DeviceAddress contained in the Mgmt_Direct_Join_req to the network.
42
43
44 1.4.5 ZDP enumeration description
45
46 This sub-clause explains the meaning of the enumerations used in the ZDP. Table 88 shows a description of
47 the ZDP enumeration values.74
48
49
50
51
52 72
CCB Comment #250
53 73CCB Comment #237, 250
74
54 CCB Comment #223

Table 88 ZDP enumerations description 1

2
Enumeration Value Description
3
SUCCESS The requested operation or transmission was completed 4
0x00
successfully. 5
- 0x01-0x7f Reserved 6
7
INV_REQUESTTYPE 0x80 The supplied request type was invalid. 8
9
DEVICE_NOT_FOUND 0x81 Reserved
10
INVALID_EP The supplied endpoint was equal to 0x00 or between 11
0x82
0xf1and 0xff. 12
13
NOT_ACTIVE The requested endpoint is not described by a simple
0x83 14
descriptor.
15
NOT_SUPPORTED The requested optional feature is not supported on the 16
0x84
target device. 17
TIMEOUT 0x85 A timeout has occurred with the requested operation. 18
19
NO_MATCH The end device bind request was unsuccessful due to a 20
0x86
failure to match any suitable clusters. 21
TABLE_FULL The bind request was unsuccessful due to the coordina- 22
0x87 23
tor or source device not having sufficient resources.
24
NO_ENTRY The unbind request was unsuccessful due to the coordi- 25
0x88 nator or source device not having an entry in its binding
26
table to unbind.
27
- 0x89-0xff Reserved 28
29
30
1.4.6 Conformance 31
32
When conformance to this Profile is claimed, all capabilities indicated mandatory for this Profile shall be 33
supported in the specified manner (process mandatory). This also applies to optional and conditional 34
capabilities, for which support is indicated, and subject to verification as part of the ZigBee certification 35
program. 36
37
38
1.5 The ZigBee device objects (ZDO) 39
40
41
1.5.1 Scope 42
43
This document describes the concepts, structures and primitives needed to implement a ZigBee Device
44
Objects application on top of a ZigBee Application Support Sub-layer (Reference [1]) and ZigBee Network
45
Layer (Chapter 2).
46
ZigBee Device Objects is an application which employs network and application support layer primitives to 47
implement ZigBee End Devices, ZigBee Routers and ZigBee Coordinators in Release 0.75 of the ZigBee 48
protocol. 49
50
51
52
53
54

1 1.5.2 Device Object Descriptions

2
3 — The ZigBee Device Objects are an application solution residing within the Application Layer (APL)
4 and above the Application Support Sub-layer (APS) in the ZigBee stack architecture as illustrated in
5 Figure 1
6
. The ZigBee Device Objects are responsible for the following functions:
7
8 — Initializing the Application Support Sublayer (APS), Network Layer (NWK), Security Service Pro-
9 vider (SSP) and any other ZigBee device layer other than the end applications residing over End-
10 points 1-240.
11
12 — Assembling configuration information from the end applications to determine and implement the
13 functions described in the following sub-clauses.
14
15 1.5.2.1 Device and Service Discovery
16
This function shall support device and service discovery within a single PAN. Additionally, for ZigBee
17
Coordinator, ZigBee Router and ZigBee End Device types, this function shall perform the following:
18
19 — For ZigBee End Devices which intend to sleep as indicated by :Config_Node_Power, Device and
20 Service Discovery shall manage upload and storage of the NWK Address, IEEE Address, Active
21 Endpoints, Simple Descriptors, Node Descriptor and Power Descriptor onto the associated ZigBee
22 Coordinator or ZigBee Router to permit device and service discovery operations on these sleeping
23 devices .
24
25 — For the ZigBee Coordinator and ZigBee Routers, this function shall respond to discovery requests on
26 behalf of their associated sleeping ZigBee End Devices.
27 — For all ZigBee devices, Device and Service Discovery shall support device and service discovery
28 requests from other devices and permit generation of requests from their local Application Objects.
29 The following discovery features shall be supported:
30
31 — Device Discovery
32 — Based on a unicast inquiry of a ZigBee Coordinator or ZigBee Router’s IEEE address, the
33 IEEE Address of the requested device plus, optionally, the NWK Addresses of all associ-
34 ated devices shall be returned.
35
36 — Based on a unicast inquiry of a ZigBee End Device’s IEEE address, the IEEE Address of
37 the requested device shall be returned.
38 — Based on a broadcast inquiry of a ZigBee Coordinator or ZigBee Router’s NWK Address
39 with a supplied IEEE Address, the NWK Address of the requested device plus, optionally,
40 the NWK Addresses of all associated devices shall be returned.
41
42 — Based on a broadcast inquiry of a ZigBee End Device’s NWK Address with a supplied
43 IEEE Address, the NWK Address of the requested device shall be returned. The respond-
44 ing device shall employ APS acknowledged service for the unicast response to the broad-
45 cast inquiry.
46 — Service Discovery - Based on the following inputs, the corresponding responses shall be sup-
47 plied:
48
49 — NWK address plus Active Endpoint query type – Specified device shall return the end-
50 point number of all applications residing in that device.
51 — NWK address or broadcast address plus Service Match including Profile ID and, option-
52 ally, Input and Output Clusters – Specified device matches Profile ID with all active end-
53 points to determine a match. If no input or output clusters are specified, the endpoints that
54 match the request are returned. If input and/or output clusters are provided in the request,

those are matched as well and any matches are provided in the response with the list of 1
endpoints on the device providing the match. The responding device shall employ APS 2
acknowledged service for the unicast response to the broadcast inquiry. 3
4
— NWK address plus Node Descriptor or Power Descriptor query type – Specified device
5
shall return the Node or Power Descriptor for the device.
6
— NWK address, Endpoint Number plus Simple Descriptor query type – Specified address 7
shall return the Simple Descriptor associated with that Endpoint for the device. 8
9
— Optionally, NWK address plus Complex or User Descriptor query type – If supported,
10
specified address shall return the Complex or User Descriptor for the device
11
12
1.5.2.2 Security Manager
13
This function determines whether security is enabled or disabled and, if enabled, shall perform the 14
following: 15
16
— Establish Key 17
18
— Transport Key
19
— Authentication 20
21
The Security Manager function addresses the Security Services Specification (Reference [5]). Security 22
Management, implemented by APSME primitive calls by ZDO, performs the following: 23
24
— Contacts the Trust Center (assumed to be located on the ZigBee Coordinator) to obtain the Master
25
Key between this device and the Trust Center (step is omitted if this device is the ZigBee Coordina-
26
tor or the Master Key with the Trust Center has been pre-configured). This step employs the Trans-
27
port Key primitive.
28
— Establishes a Link Key with the Trust Center. This step employs the APSME-Establish-Key primi- 29
tive. 30
31
— Obtains the NWK Key from the Trust Center using secured communication with the Trust Center.
32
This step employs the APSME-Transport-Key primitive.
33
— Establishes Link Keys and master keys, as required, with specific devices in the network identified 34
as messaging destinations. These steps employ the APSME-Key and APSME-Establish-Key primi- 35
tives. 36
37
— Informs the trust center of any devices that join the network using the APSME-Device-Update prim-
38
itives. This function is only performed if the device is a ZigBee router.
39
40
1.5.2.3 Network Manager
41
This function shall implement the ZigBee Coordinator, ZigBee Router or ZigBee End Device logical device 42
types according to configuration settings established either via a programmed application or during 43
installation. If the device type is a ZigBee Router or ZigBee End Device, this function shall provide the 44
ability to select an existing PAN to join and implement orphaning procedures which permit the device to re- 45
associate with the same ZigBee Coordinator or ZigBee Router if network communication is lost. If the 46
device type is a ZigBee Coordinator or ZigBee Router, this function shall provide the ability to select an 47
unused channel for creation of a new PAN. Note that is possible to deploy a network without a device pre- 48
designated as ZigBee Coordinator where the first Full Function Device (FFD) activated device assumes the 49
role of ZigBee Coordinator. The following description covers processing addressed by Network 50
Management: 51
52
— Permits specification of a channel list for network scan procedures. Default is to specify use of all 53
channels in the selected band of operation. 54

1 — Manages network scan procedures to determine neighboring networks and the identity of their Zig-
2 Bee coordinators and routers.75
3
— Permits selection of a channel to start a PAN (ZigBee Coordinator) or selection of an existing PAN to
4
join (ZigBee Router or ZigBee End Device).
5
6 — Supports orphaning procedures to rejoin the network.
7
— Supports direct join and join by proxy features provided by the Network Layer. For ZigBee Coordi-
8
nators and ZigBee Routers, a local version of direct join shall be supported to enable the device to
9
join via orphaning procedures.
10
11 — May support Management Entities that permit external network management.
12
13 1.5.2.4 Binding Manager
14
15 The Binding Manager performs the following:
16
— Establishes resource size for the Binding Table. The size of this resource is determined via a pro-
17
grammed application or via a configuration parameter defined during installation.
18
19 — Processes bind requests for adding or deleting entries from the APS binding table.
20
— Supports Bind and Unbind commands from external applications such as those that may be hosted on
21
a PDA to support assisted binding. Bind and Unbind commands shall be supported via the ZigBee
22
Device Profile (Reference [6]).
23
24 — For the ZigBee Coordinator, supports the End Device Bind that permits binding on the basis of but-
25 ton presses or other manual means.
26
27 1.5.2.5 Node Manager
28
29 For ZigBee Coordinators and ZigBee Routers, the Node Management function performs the following:
30
— Permits remote management commands to perform network discovery.
31
32 — Provides remote management commands to retrieve the routing table.
33
— Provides remote management commands to retrieve the binding table.
34
35 — Provides a remote management command to have the device leave the network or to direct that
36 another device leave the network.
37
— Provides a remote management command to retrieve the LQI for neighbors of the remote device.
38
39
40 1.5.3 Layer Interface Description
41
42 Unlike other device descriptors for applications residing above Endpoints 1-240, the ZigBee Device Objects
43 (ZDO) interface to the APS via the APSME-SAP and to NWK via the NLME-SAP in addition to the
44 APSDE-SAP. ZDO communicates over Endpoint 0 using the APSDE-SAP via Profiles like all other
45 applications. The Profile used by ZDO is the ZigBee Device Profile (Reference [6]).
46
47
48
49
50
51
52
53
75
54 CCB Comment #171

1.5.4 System Usage 1

2
3
4
5
6
Device and Service 7
Discovery Object Binding Manager Object 8
9
Mandatory Optional
10
Mandatory Attributes Mandatory Attributes 11
12
NWK_addr_rsp 13
IEEE_addr_rsp 14
15
Node_Desc_rsp
16
Active_EP_rsp 17
Match_Desc_rsp 18
19
Power_Desc_rsp
20
Simple_Desc_rsp 21
22
23
Optional Attributes Optional Attributes
24
25
NWK_addr_req End_Device_Bind_req
26
IEEE_addr_req End_Device_Bind_rsp 27
Node_Desc_req Bind_req 28
29
Power_Desc_req Bind_rsp
30
Simple_Desc_req Unbind_req 31
Active_EP_req Unbind_rsp 32
33
Match_Desc_req
34
Complex_Desc_req 35
Complex_Desc_rsp 36
37
User_Desc_req 38
User_Desc_rsp 39
Discovery_Register_req 40
41
Discovery_Register_rsp 42
End_Device_annce 43
44
User_Desc_set
45
User_Desc_conf
46
47
48
49
50
51
52
53
54

1
2
3 Network Manager Object Node Manager Object
4
5 O tional
Mandator
6 Optional Attributes
7 Mandatory Attributes
8 Mgmt_NWK_Disc_req
9 Mgmt_NWK_Disc_rsp
10 NLME-NETWORK-
11 DISCOVERY.request Mgmt_Lqi_req
12 NLME-NETWORK- Mgmt_Lqi_rsp
13 DISCOVERY.confirm Mgmt_Rtg_req
14
15 NLME-GET.request Mgmt_Rtg_rsp
16 NLME-GET.confirm Mgmt_Bind_req
17 NLME-SET.request Mgmt_Bind_rsp
18
NLME-SET.confirm Mgmt_Leave_req
19
20 Mgmt_Leave_rsp
21 Optional Attributes Mgmt_Direct_Join_req
22
23 NLME-NETWORK- Mgmt_Direct_Join_rsp
24 FORMATION.re uest
25 NLME-NETWORK-
26 FORMATION.confirm
27 NLME-DIRECT-
28 JOIN.re ues
29 NLME-DIRECT-
30 JOIN.confirm
31
NLME-JOIN.request
32
33 NLME-JOIN.confirm
34 NLME-JOIN.indication
35
NLME-START-
36
ROUTER.request
37
38 NLME-START-
39 ROUTER.confirm
40 NLME-LEAVE.request
41 NLME-LEAVE.confirm
42 NLME-LEAVE.indication
43
44 NLME-SYNC.request
45 NLME-SYNC.indication
46 NLME-PERMIT-
47 JOINING.re uest
48 NLME-PERMIT-
49 JOINING.confirm
50
NLME-RESET.request
51
52 NLME-RESET.confirm
53
54

1
2
3
4
Configuration Attributes 5
Security Manager Object 6
Mandatory 7
Optional 8
:Config_Node_Descriptor 9
Mandatory Attributes
:Config_Power_Descriptor 10
11
APSME-ESTABLISH- :Config_Simple_Descriptors 12
KEY.cnf
:Config_NWK_Mode_and_Params 13
APSME-ESTAB 14
:Config_NWK_Scan_Attempts
LISH-KEYre 15
APSME-ESTABLISH- :Config_NWK_Time_btwn_Scans
16
KEY.ind 17
APSME-ESTAB 18
Optional
LISH-KEY.rs 19
:Config_Complex_Descriptor 20
APSME-TRANSPORT-
21
KEY.ind :Config_User_Descriptor
22
APSME-TRANS :Config_Max_Bind 23
PORT-KEYre 24
:Config_Master_Key
APSME- 25
:Config_NWK_Join_Direct_Addrs
UTHENTICATE.cnf 26
:Config_Max_Assoc 27
APSME-AUTHEN
:Config_EndDev_Bind_Timeout 28
APSME- TICATE.re 29
UTHENTICATE.ind :Config_Permit_Join_Duration 30
APSME-AUTHEN :Config_Nwk_Security_Level 31
TICATE.rs :Config_Nwk_Secure_All_Frames 32
33
APSME-DEVICE- :Config_NWK_Leave_removeChildren
34
UPDATE.ind :Config_NWK_BroadcastDeliveryTime 35
APSME-DEVICE- 36
:Config_NWK_TransactionPersistenceTime
UPDATE.re 37
APSME-REMOVE- 38
DEVICE.ind 39
APSME-REMOVE- 40
DEVICE.re 41
42
APSME-KEY.ind 43
APSME-KEY.req 44
45
46
47
48
Figure 30 ZigBee Device Object details 49
50
51
52
53
54

1 1.5.5 Object Definition and Behavior

2
3 1.5.5.1 Object Overview
4
5 ZigBee Device Objects contains five Objects:
6
7 — Device and Service Discovery
8 — Network Manager
9
10 — Binding Manager
11 — Security Manager
12
13 — Node Manager
14 Table 89 ZigBee Device Objects
15
16 Object Description
17
18
19 Name Status
20
21
Handles device and service discovery.
22 :Device_and_Service_Discovery M
23
24
25 Handles network activities such as network discovery, leaving/joining
:Network_Manager M a network, resetting a network connection and creating a network.
26
27
28 Handles end device binding, binding and unbinding activities.
:Binding_Manager O
29
30
31 Handles security services such as key loading, key establishment,
:Security_Manager O key transport and authentication.
32
33
34 Handles management functions.
35 :Node_Manager O
36
37
38 1.5.5.2 Optional and Mandatory Objects and Attributes
39
40 Objects listed as Mandatory shall be present on all ZigBee devices. However, for certain ZigBee logical
41 types, Objects listed as Optional for all ZigBee devices may be Mandatory in specific logical device types.
42 For example, the NWK_Formation_req within the Network_Manager object is in a Mandatory object and is
43 an Optional attribute, though the attribute is required for ZigBee Coordinator logical device types. The
44 introduction section of each Device Object section will detail the support requirements for Objects and
45 Attributes by logical device type.
46
47 1.5.5.3 Security key usage
48
49 ZigBee Device Objects may employ security for packets created by ZigBee Device Profile primitives. These
50 application packets using APSDE on Endpoint 0 shall utilize the Network Key, as opposed to individual
51 Link Keys.
52
53 Public and Private Methods
54

Methods that are accessible to any endpoint application on the device are called public methods. Private 1
methods are only accessible to the Device Application on endpoint 0 and not to the end applications (which 2
run on endpoints 1 through 240). 3
4
1.5.5.4 State Machine Functional Descriptions 5
6
1.5.5.4.1 ZigBee Coordinator 7
8
1.5.5.4.1.1 Initialization 9
10
Provision shall be made within the implementation to supply a single copy of desired network configuration 11
parameters (:Config_NWK_Mode_and_Params) to the Network Object of ZigBee Device Objects. 12
Additionally, provision shall be made to provide configuration elements to describe the Node Descriptor, 13
Power Descriptor, Simple Descriptor for each active endpoint and application plus the list of active 14
endpoints. These configuration shall be embodied in :Config_Node_Descriptor, :Config_Power_Descriptor 15
and :Config_Simple_Descriptors. 16
17
If supported, provision shall be made to supply configuration elements for the Complex Descriptor, User
18
Descriptor, the maximum number of bind entries and the master key. These elements shall be embodied in
19
:Config_Complex_Descriptor, :Config_User_Descriptor, :Config_Max_Bind and :Config_Master_Key.
20
The device application shall use NLME-NETWORK-DISCOVERY.request with the ChannelList portion of 21
:Config_NWK_Mode_and_Params to scan the specified channels. The resulting NLME-NETWORK- 22
DISCOVERY.confirm shall supply a NetworkList detailing active PANs within that range. The device 23
application shall compare the ChannelList to the NetworkList and select an unused channel. Specification of 24
the algorithm for selection of the unused channel shall be left to the implementer. Once the unused channel 25
is identified, the device application shall set the nwkSecurityLevel and nwkSecureAllFrames NIB attributes 26
according to the values contained in the corresponding :Config attributes. It shall then employ the NLME- 27
NETWORK-FORMATION.request using the parameters specified within 28
:Config_NWK_Mode_and_Params to establish a PAN on that channel. The device application shall check 29
the return status via the NLME-NETWORK-FORMATION.confirm to verify successful creation of the 30
PAN. The :Config_Permit_Join_Duration shall be set according to the default parameter value supplied 31
using the NLME-PERMIT-JOINING.request. Additionally, the nwkNetworkBroadcastDeliveryTime and 32
nwkTransactionPersistenceTime Network Information Block parameters shall be set with 33
:Config_NWK_BroadcastDeliveryTime and :Config_NWK_TransactionPersistenceTime respectively (see 34
Chapter 2). 35
36
Provision shall be made to ensure APS primitive calls from the end applications over EP 1 through EP 240 37
return appropriate error status values prior to completion of the Initialization state by ZigBee Device Objects 38
and transition to the normal operating state.76 39
40
1.5.5.4.1.2 Normal operating state 41
42
In this state, the ZigBee coordinator shall allow other devices to join the network based on the configuration 43
items :Config_Permit_Join_Duration and :Config_Max_Assoc. When a new device joins the network, the 44
device application shall be informed via the NLME-JOIN.indication. Should the device be admitted to the 45
PAN, the ZigBee coordinator shall indicate this via the NLME-JOIN.confirm with success status. 46
47
The ZigBee coordinator shall respond to any device discovery or service discovery operations requested of
48
its own device or any of its sleeping associated devices using the attributes described in Sections 5.4 of this
49
document. The device application shall also ensure that the number of binding entries does not exceed the
50
:Config_Max_Bind attribute.
51
52
53
76
CCB Comment #169, 196, 252, 269 54

1 The ZigBee coordinator shall support the NLME-PERMIT-JOINING.request and NLME-PERMIT-

2 JOINING.confirm to permit application control of network join processing.
3
4 The ZigBee coordinator shall support the NLME-LEAVE.request and NLME-LEAVE.indication employing
5 the :Config_NWK_Leave_removeChildren attribute where appropriate to permit removal of associated
6 devices under application control. Conditions that lead to removal of associated devices may include lack of
7 security credentials, removal of the device via a privileged application or detection of exception.
8
The ZigBee coordinator shall maintain a list of currently associated devices and facilitate support of orphan
9
scan processing to enable previously associated devices to rejoin the network. The ZigBee coordinator shall
10
support the ability for devices to be directly included in the network via the NLME-DIRECT-JOIN.request
11
and NLME-DIRECT-JOIN.confirm. This feature shall permit lists of ZigBee IEEE addresses to be provided
12
to the ZigBee coordinator and for those addresses to be included as previously associated devices. It shall be
13
possible for ZigBee devices with those addresses to directly join the network via orphaning procedures
14
rather than associating directly.
15
16 The ZigBee coordinator shall process End_Device_Bind_req from ZigBee Routers and ZigBee End
17 Devices. Upon receipt of an End_Device_Bind_req, the ZigBee Coordinator shall use the
18 :Config_EndDev_Bind_Timeout value in the attribute and await a second End_Device_Bind_req. Should
19 the second indication arrive within the timeout period, the ZigBee coordinator shall match the Profile ID in
20 the two indications. If the Profile IDs in the two indications do not match, an appropriate error status is
21 returned to each device via End_Device_Bind_rsp. Should the Profile IDs match, the ZigBee Coordinator
22 shall match the AppInClusterLists and AppOutClusterLists in the two indications. Cluster IDs in the
23 AppInClusterList of the first indication which match Cluster IDs in the AppOutClusterList of the second
24 indication shall be saved in a list for inclusion in the End_Dev_Bind_rsp.
25
26 The ZigBee coordinator shall process End_Device_annce messages from ZigBee End Devices. Upon receipt
27 of an End_Device_annce, the ZigBee coordinator shall check all internal tables holding 64 bit IEEE
28 addresses for devices within the PAN for a match with the address supplied in the End_Device_annce
29 message. At minimum, the Binding Table and Trust Center tables shall be checked. If a match is detected,
30 the ZigBee coordinator shall update its APS Information Block address map entries corresponding to the
31 matched 64 bit IEEE address to reflect the updated 16 bit NWK address contained in the
32 End_Device_annce.77
33
34 1.5.5.4.1.3 Trust center operation
35
36 The Zigbee coordinator shall also function as the trust center when security is enabled on the network.
37
The trust center is notified of new devices on the network via the APSME-DEVICE-UPDATE.indication.
38
The trust center can either choose to allow the device to remain on the network or force it out of the network
39
using the APSME-REMOVE-DEVICE.req. This choice is made using a network access control policy that
40
is beyond the scope of this specification.
41
42 If the trust center decides to allow the device to remain in the network, it shall establish a master key with
43 that device using APSME-TRANSPORT-KEY.req, unless the master key is already available to both the
44 device and trust center using out-of-band mechanisms.Upon exchange of the master key, the trust center
45 shall use APSME-ESTABLISH-KEY.req to set up a link key with the device and shall respond to request for
46 link key establishment using the APSME-ESTABLISH-KEY.rsp.
47
48 The trust center shall then provide the device with the NWK key using APSME-TRANSPORT-KEY.req. It
49 shall also provide the NWK key upon receiving a request from the device via the APSME-KEY.indication.
50
51 The trust center shall support the establishment of link keys between any two devices by providing them
52 with a common master key. Upon receipt of a APSME-KEY.indication requesting an application master key,
53
77
54 CCB Comment #107, 169, 196

the trust center shall create a master key and transport it to both devices using the APSME-TRANSPORT- 1
KEY.req. 2
3
The trust center shall periodically update the NWK key according to a policy whose details are beyond the 4
scope of this specification. All devices on the network shall be updated with the new NWK key using the 5
APSME-TRANSPORT-KEY.req 6
7
1.5.5.4.2 ZigBee Router 8
9
1.5.5.4.2.1 Initialization 10
11
Provision shall be made within the implementation to supply a single copy of desired network configuration
12
parameters (:Config_NWK_Mode_and_Params) to the Network Object of ZigBee Device Objects.
13
If supported, provision shall be made to supply configuration elements for the Complex Descriptor, User 14
Descriptor, the maximum number of bind entries and the master key. These elements shall be embodied in 15
:Config_Complex_Descriptor, :Config_User_Descriptor, :Config_Max_Bind and :Config_Master_Key. 16
17
:Config_NWK_Mode_and_Params then use the NLME-NETWORK-DISCOVERY.request attribute to scan 19
the specified channels. The resulting NLME-NETWORK-DISCOVERY.confirm shall supply a NetworkList 20
detailing active PANs within that range. The NLME-NETWORK-DISCOVERY.request procedure shall be 21
implemented :Config_NWK_Scan_Attempts, each separated in time by :Config_NWK_Time_btwn_Scans. 22
The purpose of repeating the NLME-NETWORK-DISCOVERY.request is to provide a more accurate 23
neighbor list and associated link quality indications to the NWK layer. The device application shall compare 24
the ChannelList to the NetworkList and select an existing PAN to join. Specification of the algorithm for 25
selection of the PAN shall be left to the profile description and may include use of the PAN ID, operational 26
mode of the network, identity of the ZigBee Router or Coordinator identified on the PAN, depth of the 27
ZigBee Router on the PAN from the ZigBee Coordinator for the PAN, capacity of the ZigBee Router or 28
Coordinator or the routing cost (these parameters are supplied by the NLME-NETWORK- 29
DISCOVERY.confirm). Once the PAN to join is identified, the device application shall employ the NLME- 30
JOIN.request to join the PAN on that channel. The device application shall check the return status via the 31
NLME-JOIN.confirm to verify association to the selected ZigBee Router or ZigBee Coordinator on that 32
PAN. The :Config_Permit_Join_Duration shall be set according to the default parameter value supplied 33
using NLME-PERMIT-JOINING.request. The router shall support the NLME-START-ROUTER.request 34
and NLME-START-ROUTER.confirm to begin operations as a router within the PAN it has joined. 35
Additionally, the nwkNetworkBroadcastDeliveryTime and nwkTransactionPersistenceTime Network 36
Information Block parameters shall be set with :Config_NWK_BroadcastDeliveryTime and 37
:Config_NWK_TransactionPersistenceTime respectively (see Chapter 2).78 38
39
Provision shall be made to ensure APS primitive calls from the end applications over EP 1 through EP 240 40
return appropriate error status values prior to completion of the Initialization state by ZigBee Device Objects 41
and transition to the normal operating state. 42
43
If the network has security enabled, the device shall wait for the trust center to supply it with a master key
44
via the APSME-TRANSPORT-KEY.ind and then respond to a request from the trust center to establish a
45
link key using the APSME-ESTABLISH-KEY.rsp. The device shall then wait for the trust center to provide
46
it with a NWK key using APSME-TRANSPORT-KEY.ind. Upon successful ac cquisition of the NWK key,
47
the device is authenticated and can start functioning as a router in the network.
48
The device application shall set the nwkSecurityLevel and nwkSecureAllFrames NIB attributes to the values 49
used in the network and then start functioning as a router using NLME-START-ROUTER.req 50
51
52
53
78
CCB Comment #169, 194, 196, 252, 269 54

1 1.5.5.4.2.2 Normal operating state

2
3 In this state, the ZigBee router shall allow other devices to join the network based on the configuration items
4 :Config_Permit_Join_Duration and :Config_Max_Assoc. When a new device joins the network, the device
5 application shall be informed via the NLME-JOIN.indication attribute. Should the device be admitted to the
6 PAN, the ZigBee router shall indicate this via the NLME-JOIN.confirm with success status. If security is
7 enabled on the network, the device application shall inform the trust center via the APSME-DEVICE-
8 UPDATE.req.
9
The ZigBee router shall respond to any device discovery or service discovery operations requested of its
10
own device or any of its sleeping associated devices using the attributes described in Sections 5.4 of this
11
document. The device application shall also ensure that the number of binding entries does not exceed the
12
:Config_Max_Bind attribute.
13
14 If security is supported, the ZigBee router shall support the :Config_Master_Key and shall employ the
15 Master Key in key establishment procedures for Link Keys. Upon presentation of a remote destination
16 address requiring secure communications, the ZigBee router shall support APSME-KEY.req to establish a
17 master key with the remote device and APSME-ESTABLISH-KEY.request to present the request to the
18 destination and shall support APSME-KEY-ESTABLISH.confirm and APSME-KEY-ESTABLISH.response
19 to complete the key establishment of the Link Key. The ZigBee router shall provide the ability to store Link
20 Keys for known destinations requiring secure communications and shall manage key storage for addition or
21 deletion of Link Keys. The ZigBee router shall support APSME-TRANSPORT-KEY.ind to receive keys
22 from the trust center. The ZigBee router shall request the trust center to update its NWK key via the
23 APSME-KEY.req
24
25 The ZigBee router shall support the NLME-PERMIT-JOINING.request and NLME-PERMIT-
26 JOINING.confirm to permit application control of network join processing.
27
28 The ZigBee router shall support the NLME-LEAVE.request and NLME-LEAVE.confirm employing the
29 :Config_NWK_Leave_removeChildren attribute where appropriate to permit removal of associated devices
30 under application control. Conditions that lead to removal of associated devices may include lack of security
31 credentials, removal of the device via a privileged application or detection of exception.
32
The ZigBee router shall process End_Device_annce messages from ZigBee End Devices. Upon receipt of an
33
End_Device_annce, the ZigBee router shall check all internal tables holding 64 bit IEEE addresses for
34
devices within the PAN for a match with the address supplied in the End_Device_annce message. At
35
minimum, any Binding Table entries held by the ZigBee router shall be checked. If a match is detected, the
36
ZigBee router shall update its APS Information Block address map entries corresponding to the matched 64
37
bit IEEE address to reflect the updated 16 bit NWK address contained in the End_Device_annce.
38
39 The ZigBee router shall maintain a list of currently associated devices and facilitate support of orphan scan
40 processing to enable previously associated devices to rejoin the network.79
41
42 1.5.5.4.3 ZigBee End Device
43
44 1.5.5.4.3.1 Initialization
45
46 Provision shall be made within the implementation to supply a single copy of desired network configuration
47 parameters (:Config_NWK_Mode_and_Params) to the Network Object of ZigBee Device Objects.
48
49 If supported, provision shall be made to supply configuration elements for the Complex Descriptor, User
50 Descriptor, the maximum number of bind entries and the master key. These elements shall be embodied in
51 :Config_Complex_Descriptor, :Config_User_Descriptor, :Config_Max_Bind and :Config_Master_Key.
52
53
79

:Config_NWK_Mode_and_Params then use the NLME-NETWORK-DISCOVERY.request attribute to scan 2
the specified channels. The resulting NLME-NETWORK-DISCOVERY.confirm shall supply a NetworkList 3
detailing active PANs within that range. The NLME-NETWORK-DISCOVERY.request procedure shall be 4
implemented :Config_NWK_Scan_Attempts, each separated in time by :Config_NWK_Time_btwn_Scans. 5
The purpose of repeating the NLME-NETWORK-DISCOVERY.request is to provide a more accurate 6
neighbor list and associated link quality indications to the NWK layer. The device application shall compare 7
the ChannelList to the NetworkList and select an existing PAN to join. Specification of the algorithm for 8
selection of the PAN shall be left to the profile descriptions and may include use of the PAN ID, operational 9
mode of the network, identity of the ZigBee Router or Coordinator identified on the PAN, depth of the 10
ZigBee Router on the PAN from the ZigBee Coordinator for the PAN, capacity of the ZigBee Router or 11
Coordinator or the routing cost (these parameters are supplied by the NLME-NETWORK- 12
DISCOVERY.confirm). Once the PAN to join is identified, the device application shall employ the NLME- 13
JOIN.request to join the PAN on that channel. The device application shall check the return status via the 14
NLME-JOIN.confirm to verify association to the selected ZigBee Router or ZigBee Coordinator on that 15
PAN. 16
17
Once the End Device has successfully joined a network, the device shall issue an End_Device_annce 18
providing its 64 bit IEEE address and 16 bit NWK address. 19
20
Provision shall be made to ensure APS primitive calls from the end applications over EP 1 through EP 240
21
return appropriate error status values prior to completion of the Initialization state by ZigBee Device Objects
22
and transition to the normal operating state.
23
If the network has security enabled, the device shall wait for the trust center to supply it with a master key 24
via the APSME-TRANSPORT-KEY.ind and then respond to a request from the trust center to establish a 25
link key using the APSME-ESTABLISH-KEY.rsp. The device shall then wait for the trust center to provide 26
it with a NWK key using APSME-TRANSPORT-KEY.ind. Upon succesful acquisition of the NWK key, the 27
device is joined and authenticated.80 28
29
1.5.5.4.3.2 Normal operating state 30
31
The ZigBee end device shall respond to any device discovery or service discovery operations requested of 32
its own device using the attributes described in Sections 5.4 of this document. 33
34
If security is enabled, the ZigBee end device shall support the :Config_Master_Key and shall employ the 35
Master Key in key establishment procedures for Link Keys. Upon presentation of a remote destination 36
address requiring secure communications, the ZigBee end device shall support APSME-KEY.req to 37
establish a master key with the remote device and support APSME-ESTABLISH-KEY.request to present the 38
request to the destination and shall support APSME-ESTABLISH-KEY.confirm and APSME-ESTABLISH- 39
KEY.response to complete the key establishment of the Link Key. The ZigBee end device shall provide the 40
ability to store Link Keys for known destinations requiring secure communications and shall manage key 41
storage for addition or deletion of Link Keys. The ZigBee end device shall support APSME-TRANSPORT- 42
KEY.ind to receive keys from the trust center. The ZigBee end device shall request the trust center to update 43
its NWK key via the APSME-KEY.req 44
45
The ZigBee End Device shall process End_Device_annce messages from other ZigBee End Devices. Upon
46
receipt of an End_Device_annce, the ZigBee End Device shall check all internal tables holding 64 bit IEEE
47
addresses for devices within the PAN for a match with the address supplied in the End_Device_annce
48
message. At minimum, any Binding Table entries held by the ZigBee End Device shall be checked. If a
49
match is detected, the ZigBee End Device shall update its APS Information Block address map entries
50
corresponding to the matched 64 bit IEEE address to reflect the updated 16 bit NWK address contained in
51
the End_Device_annce.81
52
53
80

1 1.5.5.5 Device and Service Discovery

2
3 The Device and Service Discovery function supports:
4
— Device Discovery
5
6 — Service Discovery
7
8 Device Management performs the above functions with the ZigBee Device Profile (Reference [6]).
9
10 1.5.5.5.1 Optional and Mandatory Attributes within Device and Service Discovery
11
All of the request attributes within the Device and Service Discovery Object are optional for all ZigBee
12
logical device types. The responses listed as mandatory are mandatory for all ZigBee logical device types
13
and the responses listed as optional are optional for all ZigBee logical device types. See clause 1.4 for a
14
description of any of these attributes.
15
16 Table 90 Device and Service Discovery Attributes
17
Attribute M/O Type
18
19 NWK_addr_req O Public
20
NWK_addr_rsp M Public
21
22 IEEE_addr_req O Public
23
IEEE_addr_rsp M Public
24
25 Node_Desc_req O Public
26
27 Node_Desc_rsp M Public
28 Power_Desc_req O Public
29
30 Power_Desc_rsp M Public
31
Simple_Desc_req O Public
32
33 Simple_Desc_rsp M Public
34
35 Active_EP_req O Public
36 Active_EP_rsp M Public
37
38 Match_Desc_req O Public
39
Match_Desc_rsp M Public
40
41 Complex_Desc_req O Public
42
Complex_Desc_rsp O Public
43
44 User_Desc_req O Public
45
46 User_Desc_rsp O Public
47 Discovery_Register_r Public
48 O
eq
49
50 Discovery_Register_r Public
O
sp
51
52
53
81

Table 90 Device and Service Discovery Attributes 1

2
End_Device_annce O Public
3
End_Device_annce_r Public 4
O
sp 5
6
User_Desc_set O Public
7
User_Desc_conf O Publica 8
9
a
11
1.5.5.6 Security Manager 12
13
The security manager determines whether security is enabled or disabled and, if enabled, shall perform the 14
following: 15
16
— Establish Key 17
— Transport Key 18
19
— Authentication 20
21
1.5.5.6.1 Optional and Mandatory Attributes within Security Manager 22
23
The Security Manager itself is an optional object for all ZigBee Device Types. If the Security Manager is
24
present, all requests and responses are mandatory for all ZigBee device types. If the Security Manager is not
25
present, none of the attributes in the Security Manager are present for any ZigBee logical device type. See
26
Chapter 3 for a description of any of the primitives listed in Table 91.
27
Table 91 Security Manager Attributes 28
Attribute M/O Type 29
30
APSME-ESTABLISH- M Public 31
KEY.request
32
APSME-ESTABLISH- M Public 33
KEY.response 34
35
APSME-TRANSPORT- M Public
36
KEY.request
37
APSME-TRANSPORT- M Public 38
KEY.response 39
40
APSME-AUTHENTI- M Public
CATE.request 41
42
APSME-AUTHENTI- M Public 43
CATE.response 44
APSME-DEVICE- M Private 45
UPDATE.request 46
47
APSME-REMOVE- M Private 48
DEVICE.request
49
APSME-KEY.request M Private 50
51
52
53
54

1 1.5.5.7 Binding Manager

2
3 The Binding Management function supports:
4
— End Device Binding
5
6 — Bind and Unbind
7
8 Binding Management performs the above functions with ZigBee Device Profile commands plus APSME-
9 SAP primitives to commit/remove binding table entries once the indication arrives on the Zigbee
10 coordinator or router, supporting the binding table. 82
11
12 1.5.5.7.1 Optional and Mandatory Attributes within Binding Manager
13
The Binding Manager is an optional object for all ZigBee Device Types.
14
15 If the Binding Manager is present, all requests are optional for all ZigBee logical device types. Additionally,
16 responses shall be supported on the ZigBee Coordinator or responses shall be supported on ZigBee Routers
17 and ZigBee End Devices which correspond to the source address for the binding table entries held on those
18 devices.83
19
20 If the Binding Manager is not present, all requests and all responses for all ZigBee logical device types shall
21 not be supported.
22
23 Table 92 Binding Manager Attributes
24 Attribute Method M/O Type
25 End_Device_Bind_req See clause 1.4. O Public
26
27 End_Device_Bind_rsp See clause 1.4. O Public
28
Bind_req See clause 1.4. O Public
29
30 Bind_rsp See clause 1.4. O Public
31
32 Unbind_req See clause 1.4. O Public
33 Unbind_rsp See clause 1.4. O Public
34
35 APSME-BIND.request See clause 1.2. O Private
36
APSME-BIND.confirm See clause 1.2. O Private
37
38 APSME-UNBIND.request See clause 1.2. O Private
39
APSME-UNBIND.confirm See clause 1.2. O Private
40
41
42
1.5.5.8 Network Manager
43
44 The Network Management function supports:
45
46 — Network Discovery
47
— Network Formation
48
49 — Permit/Disable Associations
50
— Association and Disassociation
51
52
83
54 CCB Comment #213

— Route Discovery 1
2
— Network Reset
3
— Radio Receiver State Enable/Disable 4
5
— Get and Set of Network Management Information Block Data
6
Network Management performs the above functions with NLME-SAP primitives (see Chapter 2). 7
8
1.5.5.8.1 Optional and Mandatory Attributes within Network Manager 9
10
The Network Manager is a mandatory object for all ZigBee Device Types. 11
12
The Network Discovery, Get and Set attributes (both requests and confirms) are mandatory for all ZigBee 13
logical device types. 14
15
If the ZigBee logical device type is ZigBee Coordinator, the NWK Formation request and confirm, the
16
NWK Leave request, NWK Leave indication, NWK Leave confirm, NWK Join indication, NWK Permit
17
Joining request, NWK Permit Joining confirm, NWK Direct Join request, NWK Direct Join confirm plus the
18
NWK Permit Joining request and NWK Permit Joining confirm shall be supported. The NWK Join request,
19
NWK Join response, NWK Leave request and NWK Leave confirm shall not be supported.
20
If the ZigBee logical device type is ZigBee Router, the NWK Formation request and confirm shall not be 21
supported. Additionally, the NWK Start Router request, NWK Start Router confirm, NWK Join request, 22
NWK Join confirm, NWK Join indication, NWK Leave request, NWK Leave confirm, NWK Leave 23
indication, NWK Direct Join request, NWK Direct Join confirm, NWK Permit Joining request and NWK 24
Permit Joining confirm shall be supported. 25
26
If the ZigBee logical device type is ZigBee End Device, the NWK Formation request and confirm plus the 27
NWK Start Router request and confirm shall not be supported. Additionally, the NWK Join indication, 28
NWK Leave indication and NWK Permit Joining request shall not be supported. The NWK Join request, 29
NWK Join confirm, NWK Leave request, NWK Leave confirm shall be supported. 30
31
For all ZigBee logical devices types, the NWK Sync request, indication and confirm plus NWK Reset 32
request and confirm shall be optional.84 See Chapter 2 for a description of any of the primitives listed in 33
Table 93. 34
Table 93 Network Manager Attributes 35
36
NLME-GET.request M Private 38
NLME-GET.confirm M Private 39
40
NLME-SET.request M Private 41
NLME-SET.confirm M Private 42
NLME-NETWORK- M Public 43
DISCOVERY.request 44
45
NLME-NETWORK- M Public 46
DISCOVERY.confirm 47
NLME-NETWORK- O Private 48
FORMATION.request 49
NLME-NETWORK- O Private 50
FORMATION.confirm 51
52
53
84
CCB Comment #196 54

1 Table 93 Network Manager Attributes

2
NLME-JOIN.request O Private
3
4 NLME-JOIN.confirm O Private
5 NLME-DIRECT- O Public
6 JOIN.request
7
NLME-DIRECT- O Publica
8
JOIN.confirm
9
10 NLME_LEAVE.request O Private
11 NLME-LEAVE.confirm O Private
12
NLME-RESET.request O Private
13
14 NLME-RESET.confirm O Private
15 NLME-SYNC.request O Public
16
NLME-SYNC.indication O Publicb
17
18 NLME-SYNC.confirm O Public
20 bIbid
21
22
23 1.5.5.9 Node Manager
24
The node manager supports the ability to request and respond to management functions. These management
25
functions only provide visibility to external devices regarding the operating state of the device receiving the
26
request.
27
28
1.5.5.9.1 Optional and Mandatory Attributes within Node Manager
29
30 The Node Manager is an optional object for all ZigBee Device Types. All request and response attributes
31 within Node Manager are also optional if the Node Manager object is present. See clause 1.4 for a
32 description of these attributes.
33
34 Table 94 Node manager attributes
35 Attribute M/O Type
36
Mgmt_NWK_Disc_req O Public
37
38 Mgmt_NWK_Disc_rsp O Public
39
40 Mgmt_Lqi_req O Public
41 Mgmt_Lqi_rsp O Public
42
43 Mgmt_Rtg_req O Public
44
Mgmt_Rtg_rsp O Public
45
46 Mgmt_Bind_req O Public
47
48 Mgmt_Bind_rsp O Public
49 Mgmt_Leave_req O Public
50
51
52
53
54

Table 94 Node manager attributes 1

2
Mgmt_Leave_rsp O Public
3
Mgmt_Direct_Join_req O Public 4
5
Mgmt_Direct_Join_rsp O Public 6
7
8
1.5.6 Configuration Attributes 9
This attribute is used to represent the minimum mandatory and/or optional attributes used as configuration 10
attributes for a device. 11
12
Table 95 Configuration Attributes 13
14
16
:Config_Node_Descriptor M Public 17
18
:Config_Power_Descriptor M Public 19
20
21
:Config_Simple_Descriptors M Public 22
23
:Config_NWK_Mode_and_Params M Public 24
25
26
:Config_NWK_Scan_Attempts M Private
27
28
:Config_NWK_Time_btwn_Scans M Private 29
30
:Config_Complex_Descriptor O Public 31
32
33
:Config_User_Descriptor O Public 34
35
:Config_Max_Bind O Private 36
37
38
:Config_Master_Key O Private
39
40
:Config_EndDev_Bind_Timeout O Private 41
42
:Config_Permit_Join_Duration O Public 43
44
45
:Config_NWK_Security_Level O Private 46
47
:Config_NWK_Secure_All_Frames O Private 48
49
50
51
52
53
54

1 Table 95 Configuration Attributes

2
:Config_NWK_Leave_removeChildre O Privatea
3 n
4
5 :Config_NWK_BroadcastDeliveryTim O Privateb
6 e
7 :Config_NWK_TransactionPersistenc O Privatec
8 eTime
9
a
10 CCB Comment #107
b
11 CCB Comment #269
c
CCB Comment #252
12
13
14 1.5.6.1 Configuration Attribute Definitions
15
16
17
Attribute Description When updated
18
19 :Config_Node_Descriptor Contents of the Node The :Config_Node_Descriptor is
20 Descriptor for this either created when the application
device (see sub- is first loaded or initialized with a
21 clause 1.3.3.4). commissioning tool prior to when
22 the device begins operations in the
23 network. It is used for service dis-
24 covery to describe node features to
25 external inquiring devices.
26 :Config_Power_Descriptor Contents of the The :Config_Power_Descriptor is
27 Power Descriptor for either created when the application
28 this device (see sub- is first loaded or initialized with a
29 clause 1.3.3.5). commissioning tool prior to when
the device begins operations in the
30
network. It is used for service dis-
31 covery to describe node power fea-
32 tures to external inquiring devices.
33
34 :Config_Simple_Descriptors Contents of the Sim- The :Config_Simple_Descriptors
ple Descriptor(s) for are created when the application is
35 each active endpoint first loaded and are treated as
36 for this device (see “read-only”. The Simple Descriptor
37 sub-clause 1.3.3.6). are used for service discovery to
38 describe interfacing features to
39 external inquiring devices.
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

:Config_NWK_Mode_and_Params Consists of the fol- The :Config_Node_Descriptor con- 1

lowing fields: tains a field describing this devices 2
Channel List – The Logical Device Type. That informa- 3
list of channels to be tion plus the specific logic 4
scanned when using employed in this devices ZDO per- 5
NLME-NETWORK- mits the device application to use
DISCOVERY. the parameters in 6
:Config_NWK_Mode_and_Params 7
Protocol Version – to form or join a network consistent 8
Used in NLME-NET- with the applications supported on 9
WORK-FORMA- the device. 10
TION and NLME-
JOIN (Chapter 2). 11
12
Stack Profile – Used 13
in NLME-NET- 14
WORK-FORMA- 15
TION and NLME-
JOIN (Chapter 2). 16
17
Beacon Order – 18
Used in NLME-NET- 19
WORK-FORMA- 20
TION (Chapter 2).
21
Superframe Order – 22
Used in NLME- 23
NETORK-FORMA- 24
TION (Chapter 2). 25
BatteryLifeExten- 26
sion – TRUE or 27
FALSE (sub- 28
clause 2.3.3) 29
30
Security Setting –
Used in NLME-NET- 31
WORK-FORMA- 32
TION (sub- 33
clause 2.3.3) 34
35
:Config_NWK_Scan_Attempts Integer value repre- The :Config_NWK_Scan_Attempts
senting the number is employed within ZDO to call the 36
of scan attempts to NLME-NETWORK-DISCOV- 37
make before the ERY.request primitive the indi- 38
NWK layer decides cated number of times (for routers 39
which ZigBee coordi- and end devices).
40
nator or router to
associate with (see 41
sub-clause 1.5.5.4).a 42
43
This attribute has 44
default value of 5
45
and valid values
between 1 and 255. 46
47
48
49
50
51
52
53
54

1 :Config_NWK_Time_btwn_Scans Integer value repre- The

2 senting the time :Config_NWK_Time_btwn_Scans
3 duration (in seconds) is employed within ZDO to provide
4 between each NWK a time duration between the NLME-
5 discovery attempt NETWORK-DISCOVERY.request
described by attempts.
6 :Config_NWK_Scan
7 _Attempts (see sub-
8 clause 1.5.5.4).
9
10 This attrubue has a
default value of 1
11 (second) and valid
12 values between 1
13 and 255 (seconds).
14
:Config_Complex_Descriptor Contents of the The :Config_Complex_Descriptor
15
(optional) Complex is either created when the applica-
16 Descriptor for this tion is first loaded or initialized with
17 device (see sub- a commissioning tool prior to when
18 clause 1.3.3.7). the device begins operations in the
covery to describe extended device
20
features for external inquiring
21 devices.
22
23 :Config_User_Descriptor Contents of the The :Config_User_Descriptor is
24 (optional) User either created when the application
Descriptor for this is first loaded or initialized with a
25 device (see sub- commissioning tool prior to when
26 clause 1.3.3.8). the device begins operations in the
28 covery to provide a descriptive
29 character string for this device to
external inquiring devices.
30
31 :Config_Max_Bind A constant which The :Config_Max_Bind is a maxi-
32 describes the maximum number of supported Binding
33 mum number of Table entries for this device.
binding entries per-
34
mitted if this device
35 is a ZigBee Coordi-
36 nator or ZigBee
37 Router.
38
:Config_Master_Key Master Key used if The :Config_Master_Key is either
39 security is enabled present when the application is first
40 for this device (see loaded or initialized with a commis-
41 Chapter 3). sioning tool prior to when the
42 device begins operations in the
43 network. It is used for security
operations on the device if security
44 is supported and enabled.
45
46 :Config_EndDev_Bind_Timeout Timeout value in The
47 seconds employed in :Config_EndDev_Bind_Timeout is
End Device Binding employed only on ZigBee Coordi-
48
(see sub- nators and used to determine
49 clause 1.4.3.2). whether end device bind requests
50 have been received within the time-
51 out window.
52
53
54

:Config_Permit_Join_Duration Permit Join Duration The default value for 1

value set by the :Config_Permit_Join_Duration is 2
NLME-PERMIT- 0x00, however, this value can be 3
JOINING.request established differently according to 4
primitive (see Chap- the needs of the profile. 5
ter 2).
6
:Config_NWK_Security_Level Security level of the This attribute is used only on the 7
network (see Chap- trust center and is used to set the 8
ter 2). level of security on the network. 9
:Config_NWK_Secure_All_Frames If all network frames This attribute is used only on the 10
should be secured trust center and is used to deter- 11
(see Chapter 2). mine if network layer security shall 12
be applied to all frames in the net- 13
work. 14
:Config_NWK_Leave_removeChildr Sets the policy as to The policy for setting this parame- 15
en whether child ter is found in the Stack Profile 16
devices are to be employed.b 17
removed if the 18
device is asked to
19
leave the network via
NLME-LEAVE (see 20
Chapter 2). 21
22
:Config_NWK_BroadcastDeliveryTi See Table 132. The value for this configuration 23
me attribute is established in the Stack
Profile.c 24
25
:Config_NWK_TransactionPersiste See Table 132. The value for this configuration 26
nceTime attribute is established in the Stack 27
This attribute is man- Profile.d
28
datory for the ZigBee
coordinator and Zig- 29
Bee routers and not 30
used for ZigBee End 31
Devices. 32
cCCB Comment #269 35
dCCB Comment #252
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Chapter 2 Network Specification 1
2
3
4
5
6
2.1 NWK layer status values 7
8
Network (NWK) layer confirmation primitives often include a parameter that reports on the status of the 9
request to which the confirmation applies. Values for NWK layer status parameters appear in Table 96. 10
11
Table 96 NWK layer status values 12
Name Value Description 13
SUCCESS 0x00 A request has been executed successfully. 14
15
INVALID_PARAMETER An invalid or out-of-range parameter has been passed to a 16
0xc1
primitive from the next higher layer. 17
INVALID_REQUEST The next higher layer has issued a request that is invalid 18
0xc2 or cannot be executed given the current state of the NWK 19
layer. 20
21
NOT_PERMITTED 0xc3 An NLME-JOIN.request has been disallowed.
22
STARTUP_FAILURE An NLME-NETWORK-FORMATION.request has failed to 23
0xc4
start a network. 24
25
ALREADY_PRESENT A device with the address supplied to the NLME-DIRECT-
26
JOIN.request is already present in the neighbor table of
0xc5 27
the device on which the NLME-DIRECT-JOIN.request was
issued. 28
29
SYNC_FAILURE Used to indicate that an NLME-SYNC.request has failed 30
0xc6
at the MAC layer.
31
TABLE_FULL An NLME-JOIN-DIRECTLY.request has failed because 32
0xc7
there is no more room in the neighbor table. 33
34
UNKNOWN_DEVICE An NLME-LEAVE.request has failed because the device
0xc8 addressed in the parameter list is not in the neighbor table 35
of the issuing device. 36
37
UNSUPPORTED_ATTRIBUTE An NLME-GET.request or NLME-SET.request has been 38
0xc9
issued with an unknown attribute identifier.
39
NO_NETWORKS An NLME-JOIN.request has been issued in an environ- 40
0xca ment where no networks are detectable.a 41
42
LEAVE_UNCONFIRMED 0xcb A device failed to confirm its departure from the network.b
43
MAX_FRM_CNTR Security processing has been attempted on an outgoing 44
0xcc frame, and has failed because the frame counter has 45
reached its maximum value.c
46
NO_KEY Security processing has been attempted on an outgoing 47
0xcd frame, and has failed because no key was available with 48
which to process it.d 49
BAD_CCM_OUTPUT Security processing has been attempted on an outgoing 50
0xce frame, and has failed because security engine produced 51
erroneous output.e 52
aCCB 53
Comment #105
54

b
1 CCB Comment #107
c
2 CCB Comment #159
d
Ibid
3 e
Ibid
4
5
6 2.2 General description
7
8
9 2.2.1 Network (NWK) layer overview
10
11 The network layer is required to provide functionality to ensure correct operation of the IEEE 802.15.4-2003
12 MAC sub-layer and to provide a suitable service interface to the application layer. To interface with the
13 application layer, the network layer conceptually includes two service entities that provide the necessary
14 functionality. These service entities are the data service and the management service. The NWK layer data
15 entity (NLDE) provides the data transmission service via its associated SAP, the NLDE-SAP, and the NWK
16 layer management entity (NLME) provides the management service via its associated SAP, the NLME-
17 SAP. The NLME utilizes the NLDE to achieve some of its management tasks and it also maintains a
18 database of managed objects known as the network information base (NIB).
19
20 2.2.1.1 Network layer data entity (NLDE)
21
22 The NLDE shall provide a data service to allow an application to transport application protocol data units
23 (APDU) between two or more devices. The devices themselves must be located on the same network.
24
The NLDE will provide the following services:
25
26 — Generation of the Network level PDU (NPDU). The NLDE shall be capable of generating an NPDU
27 from an application support sub-layer PDU through the addition of an appropriate protocol header.
28
29 — Topology specific routing. The NLDE shall be able to transmit an NPDU to an appropriate device
30 that is either the final destination of the communication or the next step towards the final destination
31 in the communication chain.
32
33 2.2.1.2 Network layer management entity (NLME)
34
The NLME shall provide a management service to allow an application to interact with the stack.
35
36 The NLME shall provide the following services:
37
38 — Configuring a new device. The ability to sufficiently configure the stack for operation as required.
39 Configuration options include beginning operation as a ZigBee coordinator or joining an existing net-
40 work.
41
— Starting a network. The ability to establish a new network.
42
43 — Joining and leaving a network. The ability to join or leave a network as well as the ability for a Zig-
44 Bee coordinator or ZigBee router to request that a device leave the network.
45
— Addressing. The ability of ZigBee coordinators and routers to assign addresses to devices joining the
46
network.
47
48 — Neighbor discovery. The ability to discover, record and report information pertaining to the one-hop
49 neighbors of a device
50
— Route discovery. The ability to discover and record paths through the network whereby messages
51
may be efficiently routed.
52
53 — Reception control. The ability for a device to control when the receiver is activated and for how long,
54 enabling MAC sub-layer synchronization or direct reception.

Network Specification
2.3 Service specification 1

2
3
Figure 31 depicts the components and interfaces of the NWK layer. 4
5
The NWK layer provides two services, accessed through two service access points (SAPs). These are the
6
NWK data service, accessed through the NWK layer data entity SAP (NLDE-SAP) and the NWK
7
management service, access though the NWK layer management entity SAP (NLME-SAP). These two
8
services provide the interface between the application and the MAC sub-layer, via the MCPS-SAP and
9
MLME-SAP interfaces (see [B1]). In addition to these external interfaces, there is also an implicit interface
10
between the NLME and the NLDE that allows the NLME to use the NWK data service.
11
12
13
14
Next Higher Layer Entity 15
16
NLDE-SAP NLME-SAP 17
18
NLME 19
NLDE 20
NWK
IB 21
22
MCPS-SAP MLME -SAP 23
24
MAC Sub-Layer Entity 25
26
27
28
Figure 31 The NWK layer reference model 29
30
31
2.3.1 NWK data service 32
33
The NWK layer data entity SAP (NLDE-SAP) supports the transport of application protocol data units 34
(APDUs) between peer application entities. Table 97 lists the primitives supported by the NLDE-SAP. Each 35
of these primitives will be discussed in the following sub-clauses. 36
Table 97 NLDE-SAP Primitives 37
38
NLDE-SAP primitive Request Confirm Indication
39
NLDE-DATA 2.3.1.1 2.3.1.2 2.3.1.3 40
41
42
2.3.1.1 NLDE-DATA.request 43
44
This primitive requests the transfer of a data PDU (NSDU) from the local APS sub-layer entity to a single or 45
multiple peer APS sub-layer entities. 46
47
48
49
50
51
52
53
54

1 2.3.1.1.1 Semantics of the service primitive

2
4
5 NLDE-DATA.request (
6 DstAddr,
7 NsduLength,
Nsdu,
8 NsduHandle,
9 Radiusa,
10 DiscoverRoute,
11 SecurityEnable
12 )
13 a
CCB Comment #125
14
15 Table 98 specifies the parameters for the NLDE-DATA.request primitive.
16
17 Table 98 NLDE-DATA.request parameters
19
DstAddr Network 0x0000 – 0xffff The network address of the entity or entities
20
address to which the NSDU is being transferred.
21
22 NsduLength Integer < aMaxMACFrameSize - The number of octets comprising the NSDU
23 nwkcMinHeaderOver- to be transferred.
24 heada
25 Nsdu Set of - The set of octets comprising the NSDU to be
26 octets transferred.
27
28 NsduHandle Integer 0x00 – 0xff The handle associated with the NSDU to be
transmitted by the NWK layer entity.
29
30 Radiusb Unsigned 0x00—0xff The distance, in hops, that a frame will
31 integer be allowed to travel through the net-
32 work.c
33
DiscoverRoute Integer 0x00-0x02 The DiscoverRoute parameter may be used
34
to control route discovery operations for the
35 transit of this frame (see sub-clause 2.7.3.4).
36
37 0x00 = suppress route discovery
38
0x01 = enable route discovery
39
40 0x02 = force route discoveryd
41
42
43 SecurityEnable Boolean TRUE or FALSE The SecurityEnable parameter may be used
to enable NWK layer security processing for
44 the current frame. If the security level speci-
45 fied in the NIB is 0, meaning no security, then
46 this parameter will be ignored. Otherwise, a
47 value of TRUE denotes that the security pro-
48 cessing specified by the security level will be
applied and a value of FALSE denotes that
49 no security processing will be applied.
50
bCCB Comment #125
52 cIbid
53 dCCB Comment #256
54


2
This primitive is generated by a local APS sub-layer entity whenever a data PDU (NSDU) is to be 3
transferred to a peer APS sub-layer entity. 4
5
7
On receipt of this primitive on a device that is not currently associated, the NWK layer will issue an NLDE-
8
DATA.confirm primitive with a status of INVALID_REQUEST.
9
On receipt of this primitive, the NLDE first constructs an NPDU in order to transmit the supplied NSDU. If, 10
during processing, the NLDE issues the NLDE-DATA.confirm primitive prior to transmission of the 11
NSDU, all further processing is aborted. In constructing the new NPDU, the destination address field of the 12
NWK header will be set to the value provided in the DstAddr parameter and the source address field will 13
have the value of the macShortAddress attribute in the MAC PIB. The discover route sub-field of frame 14
control field of the NWK header will be set to the value provided in the DiscoverRoute parameter. If a value 15
has been supplied for the Radius parameter, that will be placed in the radius field of the NWK header. If a 16
value is not supplied, then the radius field of the NWK header will be set to twice the value of the 17
nwkMaxDepth attribute of the NWK IB. The NWK layer will generate a sequence number for the frame as 18
described in sub-clause 2.7.2.1. The sequence number value shall be inserted into the sequence number field 19
of the NWK header of the frame.85 Once the NPDU is constructed, the NSDU is routed using the procedure 20
outline in Figure 57 and described in sub-clause 2.7.3.3. When the routing procedure specifies that the 21
NSDU is to be transmitted, this is accomplished by issuing the MCPS-DATA.request primitive with both 22
the SrcAddrMode and DstAddrMode parameters set to 0x02 indicating the use of 16-bit network addresses. 23
The SrcPANId and DstPANId parameters should be set to the current value of macPANId from the MAC 24
PIB. The SrcAddr parameter will be set to the value of macShortAddr from the MAC PIB. The value of the 25
DstAddr parameter is the next hop address determined by the routing procedure. The TxOptions parameter 26
should always be non-zero when bitwise ANDed with the value 0x01, denoting that acknowledged 27
transmission is required. On receipt of the MCPS-DATA.confirm primitive, the NLDE issues the NLDE- 28
DATA.confirm primitive with a status equal to that received from the MAC sub-layer. 29
30
If the network-wide security level specified in the NIB has a non-zero value and the SecurityEnable 31
parameter has a value of TRUE then NWK layer security processing will be applied to the frame before 32
transmission as described in clause 3.4. Otherwise no security processing will be performed at the NWK 33
layer for this frame. If security processing is done and it fails for any reason, then the frame is discarded and 34
the NLDE issues the NLDE-DATA.confirm primitive with a status parameter value equal to that returned by 35
the security suite. 36
37
2.3.1.2 NLDE-DATA.confirm 38
39
This primitive reports the results of a request to transfer a data PDU (NSDU) from a local APS sub-layer 40
entity to a single peer APS sub-layer entity. 41
42
2.3.1.2.1 Semantics of the service primitive 43
44
The semantics of this primitive is as follows:
45
46
NLDE-DATA.confirm ( 47
NsduHandle,
48
Status
) 49
50
51
52
53
85
CCB Comment #101, 109, 125, 111, 256 54

1 Table 99 specifies the parameters for the NLDE-DATA.confirm primitive.

2
3 Table 99 NLDE-DATA.confirm parameters
5 The handle associated with the NSDU
6 NsduHandle Integer 0x00 – 0xff
being confirmed.
7
8 INVALID_REQUEST, The status of the corresponding
MAX_FRM_COUNTER, request.
9
NO_KEY,
10 BAD_CCM_OUTPUTa or any
11 Status Status
status values returned from
12 security suite or the MCPS-
13 DATA.confirm primitive (see
14 [B1]).
15 a
CCB Comment #159
16
17
19
20 This primitive is generated by the local NLDE in response to the reception of an NLDE-DATA.request
21 primitive.
22 The Status field will reflect the status of the corresponding request, as described in sub-clause 2.3.1.1.3.
23
25
26 On receipt of this primitive the APS sub-layer of the initiating device is notified of the result of its request to
27 transmit. If the transmission attempt was successful, the status parameter will be set to SUCCESS.
28 Otherwise, the status parameter will indicate the error.
29
30 2.3.1.3 NLDE-DATA.indication
31
32 This primitive indicates the transfer of a data PDU (NSDU) from the NWK layer to the local APS sub-layer
33 entity.
34
36
38
39 NLDE-DATA.indication (
40 SrcAddress,
NsduLength,
41 Nsdu,
42 LinkQuality
43 }
44
45
46
47
48
49
50
51
52
53
54

Table 100 specifies the parameters for the NLDE-DATA.indication primitive. 1

2
Table 100 NLDE-DATA.indication parameters 3
Any valid device address The individual device address 5
16-bit Device 6
SrcAddress except the broadcast from which the NSDU origi-
address
address. nated. 7
8
< aMaxMACFrameSize - The number of octets compris-
NsduLength Integer 9
nwkcMinHeaderOverheada ing the NSDU being indicated.
10
The set of octets comprising the 11
Nsdu Set of octets -
NSDU being indicated. 12
13
The link quality indication deliv-
14
ered by the MAC on receipt of
LinkQuality Integer 0x00 – 0xff this frame as a parameter of the 15
MCPS-DATA.indication primti- 16
tive (see [B1]). 17
aCCB
18
Comment #336
19
20
22
This primitive is generated by the NLDE and issued to the APS sub-layer on receipt of an appropriately 23
addressed data frame from the local MAC sub-layer entity. 24
25
27
On receipt of this primitive the APS sub-layer is notified of the arrival of data at the device. 28
29
2.3.1.3.4 NWK management service 30
31
The NWK layer management entity SAP (NLME-SAP) allows the transport of management commands
32
between the next higher layer and the NLME. Table 101 summarizes the primitives supported by the NLME
33
through the NLME-SAP interface. See the following sub-clauses for more details on the individual
34
primitives.
35
Table 101 Summary of the primitives accessed through the NLME-SAP 36
Name Request Indication Response Confirm 37
38
NLME-NETWORK-DISCOVERY 2.3.2.1 2.3.2.2 39
NLME-NETWORK-FORMATION 2.3.2.2 2.3.3.2 40
41
NLME-PERMIT-JOINING 2.3.6.1 2.3.6.2 2.3.6.3 42
43
NLME-START-ROUTER 2.3.5.1 2.3.5.2
44
NLME-JOIN 2.3.6.1 2.3.6.2 2.3.6.3 45
46
NLME-DIRECT-JOIN 2.3.7.1 2.3.7.2 47
NLME-LEAVE 2.3.8.1 2.3.8.2 2.3.8.3 48
49
NLME-RESET 2.3.9.1 2.3.9.2 50
51
52
53
54

1 Table 101 Summary of the primitives accessed through the NLME-SAP

2
NLME-SYNC 2.3.10.1 2.3.10.2
3
4 NLME-GET 2.3.11.1 2.3.11.2
5
6 NLME-SET 2.3.11.3 2.3.11.4
7
8
9
2.3.2 Network discovery
10 The NWK layer management entity SAP (NLME-SAP) supports the discovery of operating networks. The
11 primitives employed in network discovery are the NLME-NETWORK-DISCOVERY primitives.
12
13 2.3.2.1 NLME-NETWORK-DISCOVERY.request
14
15 This primitive allows the next higher layer to request that the NWK layer discover networks currently
16 operating within the POS.
17
19
21
22 NLME-NETWORK-DISCOVERY.request {
23 ScanChannels,
24 ScanDuration
}
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Table 102 specifies the parameters for the NLME-NETWORK-DISCOVERY.request primitive. 1

2
Table 102 NLME-NETWORK-DISCOVERY.request parameters 3
The five most significant bits (b27,..., 5
b31) are reserved. The 27 least signifi- 6
cant bits (b0, b1,... b26) indicate which 7
ScanChannels Bitmap 32 bit field
channels are to be scanned (1 = scan, 8
0 = do not scan) for each of the 27 valid 9
channels (see [B1]).
10
A value used to calculate the length of 11
time to spend scanning each channel. 12
is (aBaseSuperframeDuration * (2n +
ScanDuration Integer 0x00-0x0e 14
1)) symbols, where n is the value of the
ScanDuration parameter. For more 15
information on MAC sub-layer scanning 16
see [B1]. 17
18
19
21
This primitive is generated by the next higher layer of a ZigBee device and issued to its NLME to request the 22
discovery of networks operating within the device’s personal operating space (POS). 23
24
On receipt of this primitive, the NWK will attempt to discover networks operating within the device’s POS 26
by scanning over the channels specified in the ScanChannels argument for the period specified in the 27
ScanDuration parameter. 28
29
If the device is an IEEE 802.15.4-2003 FFD [B1], then it will perform an active scan. If it is an RFD, it will 30
perform an active scan provided that the device implements active scan. Otherwise it will perform a passive 31
scan using the MLME-SCAN.request primitive. On receipt of the MLME-SCAN.confirm primitive the 32
device’s neighbor table (see sub-clause 2.7.1.3.4) is updated to reflect the information returned by the scan 33
and a network descriptor list is assembled and the NLME issues the NLME-NETWORK- 34
DISCOVERY.confirm primitive containing the information about the discovered networks and with a 35
Status parameter value equal to that returned with the MLME-SCAN.confirm. 36
37
2.3.2.2 NLME-NETWORK-DISCOVERY.confirm 38
39
This primitive reports the results of a network discovery operation. 40
41
43
45
NLME-NETWORK-DISCOVERY.confirm { 46
NetworkCount, 47
NetworkDescriptor,
Status 48
} 49
50
51
52
53
54

1 Table 103 describes the arguments of the NLME-NETWORK-DISCOVERY.confirm primitive.

2
3 Table 103 NLME-NETWORK-DISCOVERY.confirm parameters
5 Gives the number of networks dis-
6 NetworkCount Integer 0x00—0xff
covered by the search.
7
8 A list of descriptors, one for each of
List of net- The list contains the number of
the networks discovered. Table 104
9 NetworkDescriptor work elements given by the Network-
gives a detailed account of the con-
10 descriptors Count parameter.
tents of each item.
11
12 Any Status value returned with See [B1].
13 Status Status the MLME-SCAN.confirm primi-
tive.
14
15
16
Table 104 gives a detailed account of the contents of a network descriptor from the NetworkDescriptor
17
parameter.
18
19 Table 104 Network descriptor information fieldsa
21
22 The 16-bit PAN identifier of the dis-
covered network. The 2 highest-order
23 PanID Integer 0x0000—0x3fff
bits of this parameter are reserved
24 and shall be set to 0.
25
26 Selected from the available logi- The current logical channel occupied
27 LogicalChannel Integer cal channels supported by the by the network.
PHY (see [B1]).
28
29 A ZigBee stack profile identifier indi-
30 StackProfile Integer 0x00 – 0x0f cating the stack profile in use in the
31 discovered network.
32 The version of the ZigBee protocol in
33 ZigBeeVersion Integer 0x00 – 0x0f
use in the discovered network.
34
35 This specifies how often the MAC
sub-layer beacon is to be transmitted
36
BeaconOrder Integer 0x00-0x0f by a given device on the network. For
37 a discussion of MAC sub-layer bea-
38 con order see [B1].
39
40 For beacon-oriented networks, i.e.
beacon order < 15, this specifies the
41 SuperframeOrder Integer 0x00-0x0f length of the active period of the
42 superframe. For a discussion of MAC
43 sub-layer superframe order see [B1].
44
A value of TRUE indicates that at
45
least one ZigBee router on the net-
46 work currently permits joining, i.e. its
47 PermitJoining Boolean TRUE or FALSE
NWK has been issued an NLME-
48 PERMIT-JOINING primitive and the
49 time limit, if given, has not yet expired.
51
52
53
54


2
This primitive is generated by the NLME and issued to its next higher layer on completion of the discovery 3
task initiated by an NLME-NETWORK-DISCOVERY.request primitive. 4
5
7
On receipt of this primitive, the next higher layer is notified of the results of a network search.
8
9
2.3.3 Network formation 10
11
This set of primitives defines how the next higher layer of a device can initialize itself as the ZigBee 12
coordinator of a new network and subsequently make changes to its superframe configuration86. 13
14
2.3.3.1 NLME-NETWORK-FORMATION.request 15
16
This primitive allows the next higher layer to request that the device start a new ZigBee network with itself 17
as the coordinator and subsequently, to make changes to its superframe configuration87. 18
19
21
22
23
NLME-NETWORK-FORMATION.request ( 24
ScanChannels,
ScanDuration, 25
BeaconOrder, 26
SuperframeOrder, 27
PANId, 28
BatteryLifeExtension 29
)
30
31
Table 105 specifies the parameters for the NLME-NETWORK-FORMATION.request primitive. 32
Table 105 NLME-NETWORK-FORMATION.request parameters 33
34
The five most significant bits (b27,..., 36
b31) are reserved. The 27 least signifi- 37
cant bits (b0, b1,... b26) indicate which 38
ScanChannels Bitmap 32 bit field channels are to be scanned in prepa-
39
ration for starting a network (1=scan,
0=do not scan) for each of the 27 valid 40
channels (see [B1]). 41
42
A value used to calculate the length of 43
time to spend scanning each channel.
ScanDuration Integer 0x00-0x0e 45
1)) symbols, where n is the value of 46
the ScanDuration parameter [B1]. 47
48
The beacon order of the network that
BeaconOrder Integer 0x00—0x0f 49
the higher layers wish to form.
50
51
52
87
Ibid 54

1 Table 105 NLME-NETWORK-FORMATION.request parameters

2
The superframe order of the network
3 SuperframeOrder Integer 0x00—0x0f
that the higher layers wish to form.
4
5 An optional PAN identifier that may be
6 supplied if higher layers wish to
establish this network with a
7
0x0000—0x3fff predetermined identifier. If PANId is
8 PANId Integer not specified, i.e. a NULL value is
9 or NULL given, then the NWK layer will choose
10 a PAN ID. The 2 highest-order bits of
11 this parameter are reserved and shall
be set to 0.
12
13 If this value is TRUE, the NLME will
14 request that the ZigBee coordinator is
15 started supporting battery life exten-
16 BatteryLifeExtension Boolean TRUE or FALSE sion mode. If this value is FALSE, the
NLME will request that the ZigBee
17 coordinator is started without support-
18 ing battery life extension mode.
19
20
22
23 This primitive is generated by the next higher layer of a ZigBee coordinator-capable device and issued to its
24 NLME to request the initialization of itself as the ZigBee coordinator of a new network and subsequently, to
25 make changes to its superframe configuration88.
26
28
On receipt of this primitive by a device that is not capable of being a ZigBee coordinator or else already
29
initialized as the ZigBee coordinator89 of a network, the NLME issues the NLME-NETWORK-
30
FORMATION.confirm primitive with the Status parameter set to INVALID_REQUEST
31
32 If the device is to be initialized as a ZigBee coordinator, the NLME requests that the MAC sub-layer first
33 perform an energy detection scan and then an active scan on the specified set of channels. To do this, the
34 NLME issues the MLME-SCAN.request primitive to the MAC sub-layer with the ScanType parameter set
35 to indicate an energy detection scan and then issues the primitive again with the ScanType parameter set to
36 indicate an active scan. After the completion of the active scan, on receipt of the MLME-SCAN.confirm
37 primitive from the MAC sub-layer, the NLME selects a suitable channel. If the next higher layer has
38 specified the PANId parameter, then the NWK layer confirms that the given PAN identifier does not conflict
39 with the PAN identifier of an already established network on the chosen channel. If a conflict is discovered,
40 then another channel will be chosen from the specified set, if possible. If no channel can be chosen such that
41 the given PAN identifier does not conflict with another network on that channel, then the NWK layer issues
42 the NLME-NETWORK-FORMATION.confirm primitive with a status of STARTUP_FAILURE. If the
43 PANId parameter has not been specified, then the NWK layer will pick a PAN identifier that does not
44 conflict with that of any network known to be operating on the chosen channel. Once a suitable channel and
45 PAN identifier are found, the NLME will choose 0x0000 as the 16-bit short MAC address and inform the
46 MAC sub-layer. To do this the NLME issues the MLME-SET.request primitive to the MAC sub-layer to set
47 the MAC PIB attribute macShortAddress. If no suitable channel or PAN identifier can be found, the NLME
48 issues the NLME-NETWORK-FORMATION.confirm primitive with the Status parameter set to
49 STARTUP_FAILURE.
50
51
52
89
54 Ibid

To initialize a new superframe configuration or modify an existing one90, the NLME issues the MLME- 1
START.request primitive to the MAC sub-layer. The PANCoordinator parameter of the MLME- 2
START.request primitive is set to TRUE91. The BeaconOrder and SuperframeOrder given to the MLME- 3
START.request primitive will be the same as those given to the NLME-NETWORK-FORMATION.request. 4
The CoordRealignment parameter in the MLME-START.request primitive is set to FALSE if the primitive 5
is issued to initialize a new superframe. The CoordRealignment parameter is set to TRUE if the primitive is 6
issued to change any of the PAN configuration attributes.92 On receipt of the associated MLME- 7
START.confirm primitive, the NLME issues the NLME-NETWORK-FORMATION.confirm primitive to 8
the next higher layer with the status returned from the MLME-START.confirm primitive. 9
10
2.3.3.2 NLME-NETWORK-FORMATION.confirm 11
12
This primitive reports the results of the request to initialize a ZigBee coordinator in a network. 13
14
16
17
18
NLME-NETWORK-FORMATION.confirm ( 19
Status
20
)
21
22
Table 106 specifies the parameters for the NLME-NETWORK-FORMATION.confirm primitive. 23
Table 106 NLME-NETWORK-FORMATION.confirm parameters 24
25
26
INVALID_REQUEST, The result of the attempt to initialize 27
STARTUP_FAILURE a ZigBee coordinator or request a 28
Status Status or any status value returned change to the superframe configu- 29
from the MLME-START.con- rationa.
30
firm primitive.
31
aCCB
Comment #137 32
33
34
36
This primitive is generated by the NLME and issued to its next higher layer in response to an NLME-
37
NETWORK-FORMATION.request primitive. This primitive returns a status value of
38
INVALID_REQUEST, STARTUP_FAILURE or any status value returned from the MLME-
39
START.confirm primitive. Conditions under which these values may be returned are described above in
40
sub-clause 2.3.3.1.3.
41
42
43
On receipt of this primitive, the next higher layer is notified of the results of its request to initialize the 44
device as a ZigBee coordinator or request a change to the superframe configuration93. If the NLME has been 45
successful, the status parameter will be set to SUCCESS. Otherwise, the status parameter indicates the error. 46
47
48
49
50
90
CCB Comment #137 51
91
Ibid 52
92CCB Comment #102, 137 53
93
CCB Comment #137 54

1 2.3.4 Allowing devices to join

2
3 This primitive defines how the next higher layer of a ZigBee coordinator or router can request that devices
4 be permitted to join its network.
5
6 2.3.4.1 NLME-PERMIT-JOINING.request
7
8 This primitive allows the next higher layer of a ZigBee coordinator or router to set its MAC sub-layer
9 association permit flag for a fixed period during which it may accept devices onto its network.
10
12
13
14
15 NLME-PERMIT-JOINING.request (
PermitDuration
16 )
17
18
19 Table 107 specifies the parameters for the NLME-PERMIT-JOINING.request primitive.
20 Table 107 NLME-PERMIT-JOINING.request parameters
21
22
23 The length of time in seconds during
24 which the ZigBee coordinator or router
will allow associations. The values
25 PermitDuration Integer 0x00 – 0xff
0x00 and 0xff indicate that permission
26 is disabled or enabled, respectively,
27 without a specified time limit.
28
29
31
32 This primitive is generated by the next higher layer of a ZigBee coordinator or router and issued to its
33 NLME whenever it is desired to allow devices to join its network.
34
36
It is only permissible that the next higher layer of a ZigBee coordinator or router issue this primitive. On
37
receipt of this primitive by the NWK layer of a ZigBee end device, the NLME-PERMIT-JOINING.confirm
38
primitive returns a status of INVALID_REQUEST.
39
40 On receipt of this primitive with the PermitDuration parameter set 0x00, the NLME sets the MAC PIB
41 attribute, macAssociationPermit, to FALSE by issuing the MLME-SET.request primitive to the MAC sub-
42 layer. Once the MLME-SET.confirm primitive is received, the NLME issues the NLME-PERMIT-
43 JOINING.confirm primitive with a status equal to that received from the MAC sub-layer.
44
45 On receipt of this primitive with the PermitDuration parameter set to 0xff, the NLME sets the MAC PIB
46 attribute, macAssociationPermit, to TRUE by issuing the MLME-SET.request primitive to the MAC sub-
47 layer. Once the MLME-SET.confirm primitive is received, the NLME issues the NLME-PERMIT-
48 JOINING.confirm primitive with a status equal to that received from the MAC sub-layer.
49
50 On receipt of this primitive with the PermitDuration parameter set to any value other than 0x00 or 0xff, the
51 NLME sets the MAC PIB attribute, macAssociationPermit, to TRUE as described above. Following the
52 receipt of the MLME-SET.confirm primitive, the NLME starts a timer to expire after PermitDuration
53 seconds. Once the timer is set, the NLME issues the NLME-PERMIT-JOINING.confirm primitive with a
54

status equal to that received by the MAC sub-layer. On expiration of the timer, the NLME sets 1
macAssociationPermit to FALSE by issuing the MLME-SET.request primitive. 2
3
Every NLME-PERMIT-JOINING.request primitive issued by the next higher layer supersedes all previous 4
requests. 5
6
2.3.4.2 NLME-PERMIT-JOINING.confirm 7
8
This primitive allows the next higher layer of a ZigBee coordinator or router to be notified of the results of
9
its request to permit the acceptance of devices onto the network.
10
11
2.3.4.2.1 Semantics of the service primitive
12
14
15
NLME-PERMIT-JOINING.confirm (
Status 16
) 17
18
19
Table 108 specifies the parameters for the NLME-PERMIT-JOINING.confirm primitive.
20
Table 108 NLME-PERMIT-JOINING.confirm parameters 21
23
INVALID_REQUEST The status of the corresponding 24
or any status returned request.
Status Status 25
from the MLME-SET.con-
26
firm primitive (see [B1]).
27
28
30
This primitive is generated by the initiating NLME of a ZigBee coordinator or router and issued to its next 31
higher layer in response to an NLME-PERMIT-JOINING.request. The status parameter either indicates the 32
status received from the MAC sub-layer or an error code of INVALID_REQUEST. The reasons for these 33
status values are described in sub-clause 2.3.4.1. 34
35
37
On receipt of this primitive, the next higher layer of the initiating device is notified of the results of its 38
request to permit devices to join the network. 39
40
41
2.3.5 Begin as a router
42
This set of primitives allows a ZigBee router that is newly joined to a network to setup its superframe 43
configuration. It may also be used by a ZigBee router94 to reconfigure its superframe. 44
45
2.3.5.1 NLME-START-ROUTER.request 46
47
This primitive allows the next higher layer of a ZigBee router to initialize or change its superframe 48
configuration.95 49
50
51
52
95
Ibid 54


2
4
5 NLME-START-ROUTER.request (
6 BeaconOrder,
7 SuperframeOrder,
BatteryLifeExtension
8 )
9
10
11 Table 109 specifies the parameters for NLME-START-ROUTER.request.
12 Table 109 NLME-START-ROUTER.request parameters
13
14
15 The beacon order of the network that
BeaconOrder Integer 0x00—0x0f
16 the higher layers wish to form.
17 The superframe order of the network
18 SuperframeOrder Integer 0x00—0x0f
that the higher layers wish to form.
19
20 If this value is TRUE, the NLME will
request that the ZigBee routera is
21
started supporting battery life exten-
22 BatteryLifeExtension Boolean TRUE or FALSE sion mode. If this value is FALSE, the
23 NLME will request that the ZigBee
24 routerb is started without supporting
25 battery life extension mode.
26 aCCB
Comment #137
27 bIbid
28
29
31
32 This primitive is generated by the next higher layer of a new device and issued to its NLME to request the
33 initialization of itself as a ZigBee router. It may also be issued to the NLME of a device that is already
34 operating as a ZigBee router96 to adjust the configuration of its superframe.
35
37 On receipt of this primitive by a device that is not already joined to a ZigBee network as a router, the NLME
38 issues the NLME-START-ROUTER.confirm primitive with the Status parameter set to
39 INVALID_REQUEST.
40
41 To initialize a new superframe configuration or to reconfigure an already existing one, the NLME issues the
42 MLME-START.request primitive to the MAC sub-layer. The CoordRealignment parameter in the MLME-
43 START.request primitive is set to FALSE if the primitive is issued to initialize a new superframe. The
44 CoordRealignment parameter is set to TRUE if the primitive is issued to change any of the PAN
45 configuration attributes.
46
47 On receipt of the associated MLME-START.confirm primitive, the NLME issues the NLME-START-
48 ROUTER.confirm primitive to the next higher layer with the status returned from the MLME-
49 START.confirm primitive. If, and only if, the status returned from the MLME-START.confirm primitive is
50 SUCCESS, the device may then begin to engage in the activities expected of a ZigBee router including the
51 routing of data frames, route discovery, route repair and the accepting of requests to join the network from
52 other devices. Otherwise the device is expressly forbidden to engage in these activities.97
53
96
54 CCB Comment #137

2.3.5.2 NLME-START-ROUTER.confirm 1
2
This primitive reports the results of the request to initialize or change the superframe configuration of a 3
ZigBee router.98 4
5
7
8
9
NLME-START-ROUTER.confirm ( 10
Status
11
)
12
13
Table 110 specifies the parameters for NLME-START-ROUTER.confirm. 14
Table 110 NLME-START-ROUTER.confirm parameters 15
16
17
INVALID_REQUEST The result of the attempt to initialize a 18
or any status value returned ZigBee routera. 19
Status Status
from the MLME-START.con- 20
firm primitive. 21
aCCB
Comment #137 22
23
24
26
This primitive is generated by the NLME and issued to its next higher layer in response to an NLME- 27
START-ROUTER.request primitive. This primitive returns a status value of INVALID_REQUEST or any 28
status value returned from the MLME-START.confirm primitive. Conditions under which these values may 29
be returned are described above in sub-clause 2.3.5.1.3. 30
31
33
On receipt of this primitive, the next higher layer is notified of the results of its request to initialize or change
34
the superframe configuration of a ZigBee router99. If the NLME has been successful, the status parameter
35
will be set to SUCCESS. Otherwise, the status parameter indicates the error.
36
37
2.3.6 Joining a network 38
39
This set of primitives defines how the next higher layer of a device can: 40
41
— request to join a network through association.
42
— request to join a network directly. 43
44
— request to re-join a network if orphaned.
45
46
2.3.6.1 NLME-JOIN.request 47
This primitive allows the next higher layer to request to join a network either through association or directly 48
or to re-join a network if orphaned. 49
50
51
97
CCB Comment #193 52
99
CCB Ibid 54


2
4
5 NLME-JOIN.request (
6 PANId,
7 JoinAsRouter,
RejoinNetwork,
8 ScanChannels,
9 ScanDuration,
10 PowerSource,
11 RxOnWhenIdle,
12 MACSecurity
)
13
14
15 Table 111 specifies the parameters for the NLME-JOIN.request primitive.
16 Table 111 NLME-JOIN.request parameters
17
19 The PAN identifier of the network to
20 attempt to join or re-join. The 2 high-
PANId Integer 0x0000—0x3fff
21 est-order bits of this parameter are
reserved and shall be set to 0
22
23 The parameter is TRUE if the device is
24 attempting to join the network in the
25 capacity of a ZigBee router. It is
26 FALSE otherwise.
JoinAsRouter Boolean TRUE or FALSE
The parameter is valid in requests to
27 join through association and ignored in
28 requests to join directly or to re-join
29 through orphaning.
30
The parameter is TRUE if the device is
31
joining directly or rejoining the network
32 using the orphaning procedure.
33 RejoinNetwork Boolean TRUE or FALSE
The parameter is FALSE if the device
34 is requesting to join a network through
35 association.
36 The five most significant bits (b27,...,
37 b31) are reserved. The 27 least signifi-
38 cant bits (b0, b1,... b26) indicate which
39 channels are to be scanned (1=scan,
ScanChannels Bitmap 32 bit field
40 0=do not scan) for each of the 27 valid
channels (see [B1]).
41 This parameter is ignored for requests
42 to join through association.
43
44 A value used to calculate the length of
time to spend scanning each channel.
45
The time spent scanning each channel
46 ScanDuration Integer 0x00-0x0e
47 1)) symbols, where n is the value of
48 the ScanDuration parameter [B1].
49
50
51
52
53
54

Table 111 NLME-JOIN.request parameters 1

2
This parameter becomes a part of the
CapabilityInformation parameter 3
passed to the MLME-ASSOCI- 4
ATE.request primitive that is gener- 5
ated as the result of a successful 6
executing of a NWK join. The values 7
PowerSource Integer 0x00 – 0x01
are:
8
0x01 = Mains-powered device. 9
10
0x00 = other power source. (see 11
[B1]). 12
This parameter indicates whether the 13
device can be expected to receive 14
packets over the air during idle por- 15
tions of the CAPa. The values are: 16
17
0x01 = The receiver is enabled when
the device is idle. 18
RxOnWhenIdle Integer 0x00 – 0x01 19
0x00 = The receiver may be disabled 20
when the device is idle. 21
22
RxOnWhenIdle shall have a value of
0x01 for ZigBee coordinators and Zig- 23
Bee routers operating in a non-bea- 24
con-oriented network. 25
26
This parameter becomes a part of the
CapabilityInformation parameter 27
passed to the MLME-ASSOCI- 28
ATE.request primitive that is gener- 29
ated as the result of a successful 30
executing of a NWK join. The values 31
MACSecurity Integer 0x00 – 0x01
are:
32
0x01 = MAC security enabled. 33
34
0x00 = MAC security disabled (see 35
[B1]). 36
aCCB
Comment #138 37
38
39
41
The next higher layer of a device generates this primitive to request to join a new network using the MAC
42
sub-layer association procedure, to join a new network directly using the MAC sub-layer orphaning
43
procedure or to locate and re-join a network after being orphaned.
44
45
46
On receipt of this primitive by a device that is currently joined to a network, the NLME issues an NLME- 47
JOIN-confirm primitive with the status parameter set to INVALID_REQUEST. 48
49
On receipt of this primitive by a device that is not currently joined to a network, the device attempts to join 50
the network specified by the PANId parameter. 51
52
53
54

1 If the RejoinNetwork parameter is FALSE, the NLME issues an MLME-ASSOCIATE.request with its
2 CoordAddress parameter set to the address of a router in its neighbor table for which following conditions
3 are true:
4
5 1) The router belongs to the network identified by the PANId parameter.
6 2) The router is open to join requests.
7 3) The link quality for frames received from this device is such that a link cost of at most 3 is pro-
8 duced when calculated as described in sub-clause 2.7.3.1.
9
If a device exists in the neighbor table for which these conditions are true, the LogicalChannel parameter of
10
the MLME-ASSOCIATE.request primitive is set to that found in the neighbor table entry corresponding to
11
the coordinator address of the potential parent. The bit-fields of the CapabilityInformation parameter shall
12
have the values shown in Table 112 and the capability information assembled here shall be stored as the
13
value of the nwkCapabilityInformation NIB attribute (see Table 132). If more than one device meets the
14
requirements outlined above then the joining device shall select the parent with the smallest tree depth.
15
16 Table 112 CapabilityInformation bit-fields
17
Bit Name Description
18
19 This field will always have a value of 0
Alternate PAN coordi-
20 0 in implementations of this specifica-
nator
tion.
21
22 This field will have a value of 1 if the
23 joining device is a ZigBee router and
24 the JoinAsRouter parametera has a
1 Device type value of TRUE. It will have a value of 0
25
if the device is a ZigBee end device or
26 else a router-capable device that is
27 joining as an end device.
28
29 This field shall be set to the value of
lowest-order bit of the PowerSource
30 parameter passed to the NLME-JOIN-
31 request primitive. The values are:
2 Power source
32
33 0x01 = Mains-powered device.
34
0x00 = other power source.
35
36 This field shall be set to the value of
37 the lowest-order bit of the RxOn-
38 WhenIdle parameter passed to the
NLME-JOIN.request primitive.
39
40 3 Receiver on when idle
0x01 = The receiver is enabled when
41 the device is idle.
42
43 0x00 = The receiver may be disabled
when the device is idle.
44
45
46
47
48
49
50
51
52
53
54

Table 112 CapabilityInformation bit-fields 1

2
This field will always have a value of 0
4–5 Reserved in implementations of this specifica- 3
tion. 4
5
This field shall be set to the value of 6
lowest-order bit of the MACSecurity
7
parameter passed to the NLME-JOIN-
request primitive. The values are: 8
6 Security capability 9
0x01 = MAC security enabled. 10
11
0x00 = MAC security disabled.
12
This field will always have a value of 1 13
in implementations of this specifica- 14
7 Allocate address
tion, indicating that the joining device 15
must be issued a 16-bit short address. 16
a
CCB Comment #118 17
18
19
If no device exists in the neighbor table for which the conditions are true, then the NWK layer will issue an 20
NLME-JOIN.confirm with the Status parameter set to NOT_PERMITTED. Otherwise, the NLME issues the 21
NLME-JOIN.confirm with the Status parameter set to the status parameter value returned from the MLME- 22
ASSOCIATE.confirm primitive. 23
24
If the RejoinNetwork parameter is FALSE and the JoinAsRouter parameter is set to TRUE, the device will
25
function as a ZigBee router in the network. If the JoinAsRouter parameter is FALSE, then it will join as an
26
end device and not participate in routing.
27
If a device that is not joined to a network receives this primitive and the RejoinNetwork parameter is equal 28
to TRUE, then it issues an MLME-SCAN.request with the ScanType parameter set to indicate an orphan 29
scan and the scan duration set to the value provided by the ScanDuration parameter. Upon receipt of the 30
MLME-SCAN.confirm primitive, the NLME issues the NLME-JOIN.confirm with the Status parameter set 31
to NO_NETWORKS, if the device was unable to find a network to join, or else to the status parameter value 32
returned from by scan.100 33
34
2.3.6.2 NLME-JOIN.indication 35
36
This primitive allows the next higher layer of a ZigBee coordinator or ZigBee router to be notified when a 37
new device has successfully joined its network by association. 38
39
41
43
NLME-JOIN.indication ( 44
ShortAddress, 45
ExtendedAddress, 46
CapabilityInformation
SecureJoina 47
) 48
49
51
52
53
100
CCB Comment #105 54

1 Table 113 specifies the parameters for the NLME-JOIN.indication primitive.

2
3 Table 113 NLME-JOIN.indication parameters
5 Network The network address of an entity that
6 ShortAddress 0x0000 – 0xffff
address has been added to the network.
7
8 64-bit IEEE The 64-bit IEEE address of an entity
ExtendedAddress Any 64-bit, IEEE address.
address that has been added to the network.
9
10 Specifies the operational capabilities
CapabilityInformation Bitmap See [B1].
11 of the joining device.
12
This parameter will be TRUE if the
13
underlying MAC association was per-
14 SecureJoin Boolean TRUE or FALSE
formed in a secure manner and
15 FALSE otherwise.a
16
aCCB
17 Comment #203
18
20
21 This primitive is generated by the NLME of a ZigBee coordinator or router and issued to its next higher
22 layer on successfully adding a new device to the network using the MAC association procedure. An
23 association attempt initiates this primitive following the reception by the NLME of the MLME-
24 ASSOCIATE.indication primitive, the subsequent acceptance of the new device as a network member and
25 the issuance of the MLME-ASSOCIATION.response primitive.
26
28
29 On receipt of this primitive, the next higher layer of a ZigBee coordinator or ZigBee router is notified that a
30 new device has joined its network.
31
32 2.3.6.3 NLME-JOIN.confirm
33
34 This primitive allows the next higher layer to be notified of the results of its request to join a network.
35
38
39
NLME-JOIN.confirm (
40
PANId,
41 Status
42 )
43
44
45
46
47
48
49
50
51
52
53
54

Table 114 specifies the parameters for the NLME-JOIN.confirm primitive. 1

2
Table 114 NLME-JOIN.confirm parameters 3
The PAN identifier from the NLME- 5
JOIN.request to which this is a confir- 6
PANId Integer 0x0000—0x3fff mation. The 2 highest-order bits of 7
this parameter are reserved and 8
should be set to 0. 9
INVALID_REQUEST, The status of the corresponding 10
NOT_PERMITTED, request. 11
NO_NETWORKSa 12
Status Status or any status value returned 13
from the MLME-ASSOCI- 14
ATE.confirm primitive or the
15
MLME-SCAN.confirm primi-
tive. 16
17
aCCB
Comment #105 18
19
20
2.3.6.3.2 When generated
21
This primitive is generated by the initiating NLME and issued to its next higher layer in response to an 22
NLME-JOIN.request primitive. If the request was successful, the status parameter indicates a successful join 23
attempt. Otherwise, the status parameter indicates an error code of INVALID_REQUEST, 24
NOT_PERMITTED, NO_NETWORKS101 or any status value returned from either the MLME- 25
ASSOCIATE.confirm primitive or the MLME-SCAN.confirm primitive. The reasons for these status values 26
are fully described in sub-clause 2.3.6.1.3. 27
28
30
request to join a network using the MAC sub-layer association procedure, to join directly using the MAC 32
sub-layer orphaning procedure or to re-join a network once it has been orphaned. 33
34
35
2.3.7 Joining a device directly to a network 36
37
This set of primitives defines how the next higher layer of a ZigBee coordinator or router can request to
38
directly join another device to its network.
39
40
2.3.7.1 NLME-DIRECT-JOIN.request
41
This primitive allows the next higher layer of a ZigBee coordinator or router to request to directly join 42
another device to its network. 43
44
45
46
47
48
49
50
51
52
53
101
CCB Comment #105 54


2
4
5 NLME-DIRECT-JOIN.request (
6 DeviceAddress,
7 CapabilityInformation
)
8
9
10 Table 115 specifies the parameters for the NLME-DIRECT-JOIN.request primitive.
11 Table 115 NLME-DIRECT-JOIN.request parameters
12
14 64-bit IEEE The IEEE address of the device to be
DeviceAddress Any 64-bit, IEEE address.
15 address directly joined.
16
The operating capabilities of the
17 CapabilityInformation Bitmap See Table 112.
device being directly joined.
18
19
20 Figure 32 illustrates the formatting of the CapabilityInformation parameter.
21
22
23 bits: 0 1 2 3 4-5 6 7
24 Alternate
Device Power Receiver on Security
25 PAN coordi- Reserved Reserved
type source when idle capability
26 nator
27
28 Figure 32 Capability Information parameter format
29
31
32 The next higher layer of a ZigBee coordinator or router generates this primitive to add a new device directly
33 to its network. This process is completed without any over the air transmissions.
34
36
On receipt of this primitive, the NLME will attempt to add the device specified by the DeviceAddress
37
parameter to its neighbor table. The CapabilityInformation parameter will contain a description of the device
38
being joined. The alternate PAN coordinator bit is set to 0 in devices implementing this specification. The
39
device type bit is set to 1 if the device is a ZigBee router or to 0 if it is an end device. The power source bit is
40
set to 1 if the device is receiving power from the alternating current mains or to 0 otherwise. The receiver on
41
when idle bit is set to 1 if the device does not disable its receiver during idle periods or to 0 otherwise. The
42
security capability bit is set to 1 if the device is capable of secure operation or to 0 otherwise.
43
44 If the NLME successfully adds the device to its neighbor table, the NLME issues the NLME-DIRECT-
45 JOIN.confirm primitive with a status of SUCCESS. If the NLME finds that the requested device is already
46 present in its neighbor tables, the NLME issues the NLME-DIRECT-JOIN.confirm primitive with a status
47 of ALREADY_PRESENT. If no capacity is available to add a new device to the device list, the NLME
48 issues the NLME-DIRECT-JOIN.confirm primitive with a status of TABLE_FULL.
49
50 2.3.7.2 NLME-DIRECT-JOIN.confirm
51
52 This primitive allows the next higher layer of a ZigBee coordinator or router to be notified of the results of
53 its request to directly join another device to its network.
54


2
4
NLME-DIRECT-JOIN.confirm ( 5
DeviceAddress, 6
Status 7
)
8
9
Table 116 specifies the parameters for the NLME-DIRECT-JOIN.confirm primitive. 10
Table 116 NLME-DIRECT-JOIN.confirm parameters 11
12
64-bit IEEE The 64-bit IEEE address in the 14
DeviceAddress Any 64-bit, IEEE address
address request to which this is a confirmation. 15
16
SUCCESS, The status of the corresponding
Status Status ALREADY_PRESENT, request. 17
TABLE_FULL 18
19
20
22
This primitive is generated by the initiating NLME and issued to its next higher layer in response to an 23
NLME-DIRECT-JOIN.request primitive. If the request was successful, the status parameter indicates a 24
successful join attempt. Otherwise, the status parameter indicates an error code of ALREADY_PRESENT 25
or TABLE_FULL. The reasons for these status values are fully described in sub-clause 2.3.7.1.3. 26
27
29
request to directly join another device to a network. 31
32
2.3.8 Leaving a network 33
34
This set of primitives defines how the next higher layer of a device can request to leave or request that 35
another device leaves a network. This set of primitives also defines how the next higher layer of a ZigBee 36
coordinator device can be notified of a successful attempt by a device to leave its network. 37
38
2.3.8.1 NLME-LEAVE.request 39
40
This primitive allows the next higher layer to request that it or another device leaves the network. 41
42
44
This semantics of this primitive is as follows:
45
46
NLME-LEAVE.request ( 47
DeviceAddress
48
RemoveChildrena
MACSecurityEnableb 49
) 50
51
aCCB Comment #107
bCCB Comment #297
52
53
54

1 Table 117 specifies the parameters for the NLME-LEAVE.request primitive.

2
3 Table 117 NLME-LEAVE.request parameters
5 The 64-bit IEEE address of the entity to
6 Device be removed from the network or NULL if
DeviceAddress Any 64-bit, IEEE address
7 address the device removes itself from the net-
8 work.
9
This parameter has a value of TRUE if
10 the device being asked to leave the net-
11 RemoveChildren Boolean TRUE or FALSE work is also being asked to remove its
12 child devices, if any. Otherwise it has a
13 value of FALSE.a
14 If, as a result of the receipt of an NLME-
15 LEAVE.request primitive, the NWK layer
16 opts to issue an MLME-DISASSOCI-
17 ATE.request primitive to the MAC layer
18 as described in sub-clause 2.7.1.7.1,
this parameter allows higher-layer con-
19 trol of the MAC layer SecurityEnable
20 parameter (see [B1]). In effect, this
21 parameter act as an override for the
22 SecurityEnable parameter of the MAC
23 layer primitive. If the NWK layer, as
MACSecurityEnable Boolean TRUE or FALSE implemented, would normally request
24 that security be applied to the outgoing
25 disassociation notification command
26 frame then a TRUE value for this param-
27 eter allows the required security pro-
28 cessing to go forward and a FALSE
value suppresses it. If the NWK layer, as
29 implemented, would not normally
30 request security processing for the out-
31 going disassociate notification com-
32 mand frame then the value of this
33 parameter is ignored.b
36
37
39
The next higher layer of a device generates this primitive to request to leave the network. The next higher
40
layer of a ZigBee coordinator or router may also generate this primitive to remove a device from the
41
network.
42
43
44
45 On receipt of this primitive by the NLME of a device that is not currently joined to a network, the NLME
46 issues the NLME-LEAVE.confirm primitive with a status of INVALID_REQUEST.
47
48 On receipt of this primitive by the NLME of a device that is currently joined to a network, with the
49 DeviceAddress parameter equal to NULL and the RemoveChildren parameter equal to FALSE, the NLME
50 will remove the device itself from the network using the procedure described in sub-clause 2.7.1.7.1.
51 Following this, the NLME will clear its routing table and issue an MLME-RESET.request primitive to the
52 MAC sub-layer. If the NLME receives an MLME-RESET.confirm primitive with the Status parameter set to
53 anything other than SUCCESS, the NLME may choose to re-issue the reset request. The NLME will also set
54 the relationship field of the neighbor table entry corresponding to its former parent to 0x03, indicating no

relationship. If the NLME-LEAVE.request primitive is received with the DeviceAddress parameter equal to 1
NULL and the RemoveChildren parameter equal to TRUE, then the NLME will attempt to remove the 2
device's children, as described in sub-clause 2.7.1.7.2, before removing itself. Each time the removal of a 3
child is completed, the NLME will issue the NLME-LEAVE.confirm with the DeviceAddress parameter 4
equal to the 64-bit IEEE address of the device just removed and the Status parameter equal to SUCCESS if 5
the removal was successful, or LEAVE_UNCONFIRMED if the removal failed for any reason. It will also 6
set the relationship field of the corresponding neighbor table entry to 0x03, indicating no relationship. After 7
attempting to remove all of its children, the NLME will remove the device itself as described above.102 8
9
On receipt of this primitive by a ZigBee coordinator or ZigBee router and with the DeviceAddress parameter 10
not equal to NULL, the NLME determines whether the specified device exists in its neighbor tables. If the 11
requested device does not exist, the NLME issues the NLME-LEAVE.confirm primitive with a status of 12
UNKNOWN_DEVICE. If the requested device exists, the NLME will attempt to remove it from the 13
network using the procedure described in sub-clause 2.7.1.7.2. If the RemoveChildren parameter is equal to 14
TRUE then the device will be requested to remove its children as well. Following the removal, the NLME 15
will issue the NLME-LEAVE.confirm primitive with the DeviceAddress equal to the 64-bit IEEE address of 16
the removed device and the Status parameter equal to SUCCESS if the removal was successful and 17
LEAVE_UNCONFIRMED otherwise. Then the relationship field for the neighbor table entry corresponding 18
to the removed device will then be set to 0x03, indicating no relationship.103 19
20
2.3.8.2 NLME-LEAVE.indication 21
22
This primitive allows the next higher layer of a ZigBee device to be notified if that device has been removed
23
from the network by its parent. It also allows the next higher layer on a ZigBee router or ZigBee coordinator
24
to be informed if one of its associated devices has left the network by disassociation.
25
26
27
29
30
NLME-LEAVE.indication (
DeviceAddress 31
) 32
33
34
Table 118 specifies the parameters for the NLME-LEAVE.indication primitive.
35
Table 118 NLME-LEAVE.indication parameters 36
38
The 64-bit IEEE address of an entity 39
that has removed itself from the
40
64-bit IEEE network or NULL in the case that the
DeviceAddress Any 64-bit, IEEE address 41
address device issuing the primitive has been
removed from the network by its par- 42
ent. 43
44
45
47
This primitive is generated by the NLME of a ZigBee coordinator or ZigBee router and issued to its next 48
higher layer on the successful exit of one of that device’s associated children from the network. It is also 49
generated by the NLME of a ZigBee router or end device and issued to its next higher layer to indicate that 50
it has been successfully removed from the network by its associated router or ZigBee coordinator.104 51
52
103
CCB Comment #107 54


2
3 On receipt of this primitive, the next higher layer of a ZigBee coordinator or ZigBee router is notified that a
4 device that was formerly associated with it has left the network. The primitive can also indicate that the next
5 higher layer of a ZigBee router or end device is informed that it has been removed from the network by its
6 associated ZigBee router or ZigBee coordinator.
7
8 2.3.8.3 NLME-LEAVE.confirm
9
This primitive allows the next higher layer to be notified of the results of its request for itself or another
10
device to leave the network.
11
12
13
15
16
NLME-LEAVE.confirm (
17 DeviceAddress,
18 Status
19 )
20
21 Table 119 specifies the parameters for the NLME-LEAVE.confirm primitive.
22
23 Table 119 NLME-LEAVE.confirm parameters
25
The 64-bit IEEE address in the
26
64-bit IEEE request to which this is a confirma-
27 DeviceAddress Any 64-bit, IEEE address.
address tion or null if the device requested to
28 remove itself from the network.
29
30 SUCCESS, The status of the corresponding
Status Status INVALID_REQUEST, request.
31 UNKNOWN_DEVICE or
32 LEAVE_UNCONFIRMED.a
33 aCCB
Comment #107
34
35
37
38 This primitive is generated by the initiating NLME and issued to its next higher layer in response to an
39 NLME-LEAVE.request primitive. If the request was successful, the status parameter indicates a successful
40 leave attempt. Otherwise, the status parameter indicates an error code of INVALID_REQUEST,
41 UNKNOWN_DEVICE or LEAVE_UNCONFIRMED105. The reasons for these status values are fully
42 described in sub-clause 2.3.8.1.3.
43
45
46 On receipt of this primitive, the next higher layer of the initiating device is notified of the results of its
47 request for itself or another device to leave the network.
48
49 2.3.9 Resetting a device
50
51 This set of primitives defines how the next higher layer of a device can request that the NWK layer is reset.
52
53 104Ibid
105
54 CCB Comment #107

2.3.9.1 NLME-RESET.request 1
2
This primitive allows the next higher layer to request that the NWK layer performs a reset operation. 3
4
6
7
8
NLME-RESET.request ( 9
)
10
11
This primitive has no parameters. 12
13
15
This primitive is generated by the next higher layer and issued to its NLME to request the reset of the NWK 16
layer to its initial condition. 17
18
On receipt of this primitive, the NLME issues the MLME-RESET.request primitive to the MAC sub-layer 20
with the SetDefaultPIB parameter set to TRUE. On receipt of the corresponding MLME-RESET.confirm 21
primitive, the NWK layer resets itself by clearing all internal variables and route discovery table entries and 22
by setting all NIB attributes to their default values. Once the NWK layer is reset, the NLME issues the 23
NLME-RESET.confirm with the Status parameter set to SUCCESS if the MAC sub-layer was successfully 24
reset or DISABLE_TRX_FAILURE otherwise. 25
26
If this primitive is issued to the NLME of a device that is currently joined to a network, any required leave 27
attempts using the NLME-LEAVE.request primitive should be made a-priori at the discretion of the next 28
higher layer. 29
30
2.3.9.2 NLME-RESET.confirm 31
32
This primitive allows the next higher layer to be notified of the results of its request to reset the NWK layer. 33
34
36
The semantics for this primitive are as follows:
37
38
NLME-RESET.confirm ( 39
Status
) 40
41
42
Table 120 NLME-RESET.confirm parameters 44
45
46
Any status value The result of the reset operation. 47
returned from the 48
Status Status
MLME-RESET.confirm
49
primitive (see [B1]).
50
51
52
53
54


2
3 This primitive is generated by the NLME and issued to its next higher layer in response to an NLME-
4 RESET.request primitive. If the request was successful, the status parameter indicates a successful reset
5 attempt. Otherwise, the status parameter indicates an error code of DISABLE_TRX_FAILURE. The reasons
6 for these status values are fully described in sub-clause 2.3.9.1.3.
7
9
On receipt of this primitive, the next higher layer is notified of the results of its request to reset the NWK
10
layer.
11
12
2.3.9.3 Network layer reset message sequence chart
13
14 Figure 33 illustrates the sequence of messages necessary for resetting the NWK layer.
15
16
17
18 Device Device Device
19
20
APL NWK MAC
21 NLME-
22 RESET.reques MLME -
23 RESET.reques
24
25
26 MLME -RESET.confirm
(SUCCESS)
27
28
29 Clear internal
30 variables, empty
31 routing table, reset
NIB
32
33 NLME-RESET.confirm
34 (SUCCESS)
35
36
37
38 Figure 33 Message sequence chart for resetting the network layer
39
40
41 2.3.10 Receiver synchronization
42
This set of primitives defines how the next higher layer of a device can synchronize with a ZigBee
43
coordinator or router and extract pending data from it.
44
45
2.3.10.1 NLME-SYNC.request
46
47 This primitive allows the next higher layer to synchronize or extract data from its ZigBee coordinator or
48 router.
49
50
51
52
53
54

2.3.10.1.1 Semantics of the Service Primitive 1

2
4
NLME-SYNC.request ( 5
Track 6
) 7
8
10
Table 121 NLME-SYNC.request parameters
11
Name Type Valid Range Description 12
Whether the synchronization should be 13
Track Boolean TRUE or FALSE 14
maintained for future beacons or not.
15
16
18
This primitive is generated whenever the next higher layer wishes to achieve synchronization or check for 19
pending data at its ZigBee coordinator or router. 20
21
23
If the TRACK parameter is set to FALSE and the device is operating on a non-beacon enabled network, the
24
NLME issues the MLME-POLL.request primitive to the MAC sub-layer. On receipt of the corresponding
25
MLME-POLL.confirm primitive, the NLME issues the NLME-SYNC.confirm primitive with the Status
26
parameter set SUCCESS if the MAC primitive was successful, or SYNC_FAILURE otherwise.
27
If the TRACK parameter is set to FALSE and the device is operating on a beacon enabled network, the 28
NLME first sets the macAutoRequest PIB attribute in the MAC sub-layer to TRUE by issuing the MLME- 29
SET.request primitive. It then issues the MLME-SYNC.request primitive with the TrackBeacon parameter 30
set to FALSE. The NLME then issues the NLME-SYNC.confirm primitive with the Status parameter set to 31
SUCCESS. 32
33
If the TRACK parameter is set to TRUE and the device is operating on a non-beacon enabled network, the 34
NLME will issue the NLME-SYNC.confirm primitive with a status parameter set to 35
INVALID_PARAMETER. 36
37
If the TRACK parameter is set to TRUE and the device is operating on a beacon enabled network, the 38
NLME first sets the macAutoRequest PIB attribute in the MAC sub-layer to TRUE by issuing the MLME- 39
SET.request primitive. It then issues the MLME-SYNC.request primitive with the TrackBeacon parameter 40
set to TRUE. The NLME then issues the NLME-SYNC.confirm primitive with the Status parameter set to 41
SUCCESS. 42
43
2.3.10.2 NLME-SYNC.indication 44
45
This primitive allows the next higher layer to be notified of the loss of synchronization at the MAC sub-
46
layer.
47
48
49
51
52
NLME-SYNC.indication (
) 53
54

1 This primitive has no parameters.

2
4
5 This primitive is generated following a loss of synchronization notification from the MAC sub-layer via the
6 MLME-SYNC-LOSS.indication primitive with a LossReason of BEACON_LOST. This follows a prior
7 NLME-SYNC.request primitive being issued to the NLME.
8
10
The next higher layer is notified of the loss of synchronization with the beacon.
11
12
2.3.10.3 NLME-SYNC.confirm
13
14 This primitive allows the next higher layer to be notified of the results of its request to synchronize or extract
15 data from its ZigBee coordinator or router.
16
17 2.3.10.3.1 Semantics of the Service Primitive
18
20
21 NLME-SYNC.confirm (
22 Status
23 )
24
26
27 Table 122 NLME-SYNC.confirm parameters
29
SUCCESS, The result of the request to synchronize
30 SYNC_FAILURE, with the ZigBee coordinator or router.
31 Status Status
INVALID_PARAMET
32 ER
33
34
36
37 This primitive is generated by the initiating NLME and issued to its next higher layer in response to an
38 NLME-SYNC.request primitive. If the request was successful, the status parameter indicates a successful
39 state change attempt. Otherwise, the status parameter indicates an error code of SYNC_FAILURE. The
40 reasons for these status values are fully described in sub-clause 2.3.10.1.3.
41
43
44 On receipt of this primitive, the next higher layer is notified of the results of its request to synchronize or
45 extract data from its ZigBee coordinator or router. If the NLME has been successful, the Status parameter
46 will be set to SUCCESS. Otherwise, the Status parameter indicates the error.
47
48 2.3.10.4 Message sequence charts for synchronizing with a coordinator
49 Figure 34 and Figure 35 illustrate the sequence of messages necessary for a device to successfully
50 synchronize with a ZigBee coordinator. Figure 34 illustrates the case for a non-beaconing network, and
51 Figure 35 illustrates the case for a beaconing network.
52
53
54

1
2
3
Device Device Device 4
APL NWK MAC 5
6
NLME-SYNC.request
7
(TRACK=FALSE)
8
9
MLME - 10
POLL.request 11
12
13
MLME -POLL.confirm 14
(SUCCESS) 15
16
17
NLME-SYNC.confirm 18
(SUCCESS) 19
20
21
22
23
24
Figure 34 Message sequence chart for synchronizing in a non-beaconing network
25
26
27
Device Device Device 28
APL NWK MAC 29
30
NLME- 31
SYNC.request ML ME- 32
SET.request 33
34
Set 35
macAutoRequest to 36
TRUE
37
ML ME-SET.confirm 38
(SUCCESS) 39
40
ML ME- 41
SYNC.request 42
43
NLME-SYNC.confirm 44
(SUCCESS) 45
46
47
48
Figure 35 Message sequence chart for synchronizing in a beacon-enabled network 49
50
51
52
53
54

1 2.3.11 Information base maintenance

2
3 This set of primitives defines how the next higher layer of a device can read and write attributes in the NIB.
4
5 2.3.11.1 NLME-GET.request
6
7 This primitive allows the next higher layer to read the value of an attribute from the NIB.
8
10
11
12
13 NLME-GET.request (
NIBAttribute
14 )
15
16
18 Table 123 NLME-GET.request parameters
19
Name Type Valid Range Description
20
21 NIBAttribute Integer See Table 132 The identifier of the NIB attribute to read.
22
23
24 2.3.11.1.2 When Generated
25
26 This primitive is generated by the next higher layer and issued to its NLME in order to read an attribute from
27 the NIB.
28
29 2.3.11.1.3 Effect on Receipt
30 On receipt of this primitive, the NLME attempts to retrieve the requested NIB attribute from its database. If
31 the identifier of the NIB attribute is not found in the database, the NLME issues the NLME-GET.confirm
32 primitive with a status of UNSUPPORTED_ATTRIBUTE.
33
34 If the requested NIB attribute is successfully retrieved, the NLME issues the NLME-GET.confirm primitive
35 with a status of SUCCESS and the NIB attribute identifier and value.
36
37 2.3.11.2 NLME-GET.confirm
38
39 This primitive reports the results of an attempt to read the value of an attribute from the NIB.
40
42
44
45 NLME-GET.confirm (
46 Status,
NIBAttribute,
47 NIBAttributeLength,
48 NIBAttributeValue
49 )
50
51
52
53
54


2
Table 124 NLME-GET.confirm parameters 3
SUCCESS or The results of the request to read a NIB 5
Status Enumeration UNSUPPORTED_A attribute value. 6
TTRIBUTE 7
8
The identifier of the NIB attribute that was
NIBAttribute Integer See Table 132 9
read.
10
The length, in octets, of the attribute value 11
NIBAttributeLength Integer 0x0000 – 0xffff
being returned. 12
13
Attribute Specific The value of the NIB attribute that was
NIBAttributeValue Various 14
(see Table 132) read.
15
16
2.3.11.2.2 When Generated 17
18
This primitive is generated by the NLME and issued to its next higher layer in response to an NLME- 19
GET.request primitive. This primitive returns a status of SUCCESS, indicating that the request to read a 20
NIB attribute was successful, or an error code of UNSUPPORTED_ATTRIBUTE. The reasons for these 21
status values are fully described in sub-clause 2.3.11.1.3. 22
23
2.3.11.2.3 Effect on Receipt 24
25
On receipt of this primitive, the next higher layer is notified of the results of its request to read a NIB 26
attribute. If the request to read a NIB attribute was successful, the Status parameter will be set to SUCCESS. 27
Otherwise, the status parameter indicates the error. 28
29
2.3.11.3 NLME-SET.request 30
31
This primitive allows the next higher layer to write the value of an attribute into the NIB.
32
33
2.3.11.3.1 Semantics of the Service Primitive
34
36
37
NLME-SET.request (
NIBAttribute, 38
NIBAttributeLength, 39
NIBAttributeValue 40
) 41
42
44
Table 125 NLME-SET.request parameters 45
The identifier of the NIB attribute to be writ- 47
NIBAttribute Integer See Table 132 48
ten.
49
NIBAttribute- The length, in octets, of the attribute value 50
Integer 0x0000 – 0xffff
Length being set.
51
Attribute Specific The value of the NIB attribute that should 52
NIBAttributeValue Various
(see Table 132) be written. 53
54


2
3 This primitive is to be generated by the next higher layer and issued to its NLME in order to write the value
4 of an attribute in the NIB.
5
7
On receipt of this primitive the NLME attempts to write the given value to the indicated NIB attribute in its
8
database. If the NIBAttribute parameter specifies an attribute that is not found in the database, the NLME
9
issues the NLME-SET.confirm primitive with a status of UNSUPPORTED_ATTRIBUTE. If the
10
NIBAttributeValue parameter specifies a value that is out of the valid range for the given attribute, the
11
NLME issues the NLME-SET.confirm primitive with a status of INVALID_PARAMETER.
12
13 If the requested NIB attribute is successfully written, the NLME issues the NLME-SET.confirm primitive
14 with a status of SUCCESS.
15
16 2.3.11.4 NLME-SET.confirm
17
18 This primitive reports the results of an attempt to write a value to a NIB attribute.
19
21
23
24 NLME-SET.confirm (
25 Status,
26 NIBAttribute
)
27
28
30 Table 126 NLME-SET.confirm parameters
31
33 SUCCESS, The result of the request to write
34 Status Enumeration INVALID_PARAMETER or the NIB Attribute.
35 UNSUPPORTED_ATTRIBUTE
36 The identifier of the NIB attribute
37 NIBAttribute Integer See Table 132
that was written.
38
39
41
42 This primitive is generated by the NLME and issued to its next higher layer in response to an NLME-
43 SET.request primitive. This primitive returns a status of either SUCCESS, indicating that the requested
44 value was written to the indicated NIB attribute, or an error code of INVALID_PARAMETER or
45 UNSUPPORTED_ATTRIBUTE. The reasons for these status values are fully described in sub-
46 clause 2.3.11.3.3.
47
49
50 On receipt of this primitive, the next higher layer is notified of the results of its request to write the value of
51 a NIB attribute. If the requested value was written to the indicated NIB attribute, the Status parameter will be
52 set to SUCCESS. Otherwise, the Status parameter indicates the error.
53
54

2.4 Frame formats 1

2
3
This sub-clause specifies the format of the NWK frame (NPDU). Each NWK frame consists of the 4
following basic components: 5
6
— A NWK header, which comprises frame control, addressing and sequencing information.
7
— A NWK payload, of variable length, which contains information specific to the frame type. 8
9
The frames in the NWK layer are described as a sequence of fields in a specific order. All frame formats in 10
this sub-clause are depicted in the order in which they are transmitted by the MAC sub-layer, from left to 11
right, where the leftmost bit is transmitted first in time. Bits within each field are numbered from 0 (leftmost 12
and least significant) to k-1 (rightmost and most significant), where the length of the field is k bits. Fields 13
that are longer than a single octet are sent to the MAC sub-layer in the order from the octet containing the 14
lowest numbered bits to the octet containing the highest numbered bits. 15
16
2.4.1 General NPDU frame format 17
18
The NWK frame format is composed of a NWK header and a NWK payload. The fields of the NWK header 19
appear in a fixed order, however, the addressing and sequencing fields may not be included in all frames. 20
The general NWK frame shall be formatted as illustrated in Figure 36. 21
22
23
Octets: 2 2 2 1 1 Variable 24
Destination Source Sequence 25
Radiusa Frame Payload
Frame Con- Address Address Numberb 26
trol 27
Routing Fields
28
NWK Header NWK Payload 29
30
aCCB Comment #125
bCCB Comment #111
31
32
33
Figure 36 General NWK frame format
34
35
2.4.1.1 Frame control Field
36
The frame control field is 16-bits in length and contains information defining the frame type, addressing and 37
sequencing fields and other control flags. The frame control field shall be formatted as illustrated in 38
Figure 37. 39
40
41
Bits: 0-1 2-5 6-7a 8 9 10-15 42
43
Frame type Protocol version Discover route Reserved Security Reserved 44
45
aCCB Comment #56 46
47
Figure 37 Frame control field 48
49
50
51
52
53
54

1 2.4.1.1.1 Frame type sub-field

2
3 The frame type sub-field is two bits in length and shall be set to one of the non-reserved values listed in
4 Table 127.
5 Table 127 Values of the frame type sub-field
6
7 Frame type value
Frame type name
8 b1 b0
9 00 Data
10
11 01 NWK command
12
10 – 11 Reserved
13
14
15 2.4.1.1.2 Protocol version sub-field
16
17 The protocol version sub-field is four bits in length and shall be set to a number reflecting the ZigBee NWK
18 protocol version in use. The protocol version in use on a particular device shall be made available as the
19 value of the NWK constant nwkcProtocolVersion, and shall have the value of 0x01 for all implementations
20 based on this specification draft version.
21
22 2.4.1.1.3 Discover route sub-field
23
24 The DiscoverRoute parameter may be used to control route discovery operations for the transit of this frame
25 (see sub-clause 2.7.3.4).106.
26
Table 128 Values of the discover route sub-fielda
27
28 Discover route field value
Field meaning
29 b7 b6
30
0x00 Suppress route discovery
31
32 0x01 Enable route discovery
33
0x02 Force route discovery
34
35 0x03 Reserved
36
a
37 CCB Comment #256
38
39 2.4.1.1.4 Security sub-field
40
41 The security sub-field shall have a value of 1 if and only if the frame is to have NWK security operations
42 enabled. If security for this frame is implemented at another layer or disabled entirely, it shall have a value
43 of 0.
44
45 2.4.1.2 Destination address field
46
47 The destination address field shall always be present. It shall be 2 octets in length and shall hold the 16-bit
48 network address of the destination device or the broadcast address (0xffff). Note that the network address of
49 a device shall always be the same as its IEEE 802.15.4-2003 MAC short address.
50
51
52
53
106
54 CCB Comment #256

2.4.1.3 Source address field 1

2
The source address field shall always be present. It will always be 2 octets in length and shall hold the 3
network address of the source device of the frame. Note that the network address of a device shall always be 4
the same as its IEEE 802.15.4-2003 MAC short address. 5
6
2.4.1.4 Radius field107 7
8
The radius field shall always be present. It will be one octet in length and specifies the range of a radius
9
transmission. The field shall be decremented by 1 by each receiving device.108
10
11
2.4.1.5 Sequence number field109
12
The sequence number field is present in every frame and is 1 octet in length. The sequence number value 13
will be incremented by 1 with each new transmitted frame and the values of the source address field and the 14
sequence number field of a frame, taken as a pair, may be used to uniquely identify a frame within the 15
constraints imposed by the sequence number's 1-octet range. For more detail on the use of the sequence 16
number field see sub-clause 2.7.2.110 17
18
2.4.1.6 Frame payload field 19
20
The frame payload field has a variable length and contains information specific to individual frame types. 21
22
23
2.4.2 Format of individual frame types 24
25
There are two defined NWK frame types: data and NWK command. Each of these frame types is discussed
26
in the following sub-clauses.
27
28
2.4.2.1 Data frame format
29
The data frame shall be formatted as illustrated in Figure 38. 30
31
32
Octets: 2 See Figure 36 Variable 33
Frame control Routing fields Data payload 34
35
NWK header NWK payload 36
37
Figure 38 Data frame format 38
39
The order of the fields of the data frame shall conform to the order of the general NWK frame format as 40
illustrated in Figure 36. 41
42
2.4.2.1.1 Data frame NWK header field 43
The NWK header field of a data frame shall contain the frame control field and an appropriate combination 44
of routing fields as required. 45
46
In the frame control field, the frame type sub-field shall contain the value that indicates a data frame, as 47
shown in Table 127. All other sub-fields shall be set according to the intended use of the data frame. 48
49
50
107
CCB Comment #125 51
108
Ibid 52
110
CCB Comment #111, 113, 114 54

1 The routing fields shall contain an appropriate combination of address and broadcast fields, depending on
2 the settings in the frame control field (see Figure 37).
3
4 2.4.2.1.2 Data payload field
5
6 The data payload field of a data frame shall contain the sequence of octets, which the next higher layer has
7 requested the NWK layer to transmit.
8
9 2.4.2.2 NWK command frame format
10
The NWK command frame shall be formatted as illustrated in Figure 39.
11
12
13 Octets: 2 See Figure 36 1 Variable
14
NWK command NWK command
15 Frame control Routing fields
identifier payload
16
17 NWK header NWK payload
18
19 Figure 39 NWK command frame format
20
21 The order of the fields of the NWK command frame shall conform to the order of the general NWK frame as
22 illustrated in Figure 36.
23
24 2.4.2.2.1 NWK command frame NWK header field
25
The NWK header field of a NWK command frame shall contain the frame control field and an appropriate
26
combination of routing fields as required.
27
28 In the frame control field, the frame type sub-field shall contain the value that indicates a NWK command
29 frame, as shown in Table 127. All other sub-fields shall be set according to the intended use of the NWK
30 command frame.
31
32 The routing fields shall contain an appropriate combination of address and broadcast fields, depending on
33 the settings in the frame control field.
34
35 2.4.2.2.2 NWK command identifier field
36
37 The NWK command identifier field indicates the NWK command being used. This field shall be set to one
38 of the non-reserved values listed in Table 129.
39
40 2.4.2.2.3 NWK command payload field
41
The NWK command payload field of a NWK command frame shall contain the NWK command itself.
42
43
44
45
2.5 Command frames
46
47 The command frames defined by the NWK layer are listed in Table 129. The following sub-clauses detail
48 how the NLME shall construct the individual commands for transmission.
49
50 Table 129 NWK command frames
51 Command frame identifier Command name Reference
52
53 0x01 Route request 2.5.1
54

Table 129 NWK command frames 1

2
0x02 Route reply 2.5.2
3
0x03 Route Error 2.5.3 4
5
0x04a Leave 2.5.4 6
0x00, 0x05b—0xff Reserved — 7
8
a 9
CCB Comment #107
b
Ibid 10
11
2.5.1 Route request command 12
13
The route request command allows a device to request that other devices within radio range engage in a 14
search for a particular destination device and establish state within the network that will allow messages to 15
be routed to that destination more easily and economically in the future. The payload of a route request 16
command shall be formatted as illustrated in Figure 40. 17
18
19
Octets: 1 1 1 2 1 20
Command 21
frame identifier Route
Command Destination 22
request Path cost
(see options address 23
identifier
Table 129) 24
NWK payload 25
26
27
Figure 40 Route request command frame format
28
29
2.5.1.1 MAC data service requirements
30
In order to transmit this command using the MAC data service, specified in [B1], the following information 31
shall be included in the MAC frame header. 32
33
The destination PAN identifier shall be set to the PAN identifier of the device sending the route request 34
command. The destination address must be set to the broadcast address of 0xffff. 35
36
The source MAC address and PAN identifier shall be set to the address and PAN identifier of the device 37
sending the route request command, which may or may not be the device from which the command 38
originated. 39
40
The frame control field shall be set to specify that the frame is a MAC data frame with MAC security
41
disabled, since any secured frame originating from the NWK layer shall use NWK layer security. Because
42
the frame is broadcast, no acknowledgment request shall be specified. The addressing mode and intra-PAN
43
flags shall be set to support the addressing fields described here.
44
45
2.5.1.2 NWK header fields
46
In order to send the route request command frame, the source address field in the NWK header shall be set to 47
the address of the originating device. 48
49
The destination address in the NWK header shall be set to the broadcast address. 50
51
52
53
54

1 2.5.1.3 NWK payload fields

2
3 The NWK frame payload contains a command identifier field, a command options field, the route request
4 identifier field, the address of the intended destination, and an up-to-date summation of the path cost.
5
The command frame identify shall contain the value indicating a route request command frame.
6
7
2.5.1.3.1 Command options field
8
9 The format of the 8-bit command options field is shown in Figure 41.
10
11
12 Bit: 0—6 7
13
14 Reserved Route repair
15
16 Figure 41 Route request command options field
17
18 The route repair sub-field is a single-bit field. It shall have a value of 1 if and only if the route request
19 command frame is being generated as part of a route repair operation for mesh network topology (see sub-
20 clause 2.7.3.5.1).
21
22 2.5.1.3.2 Route request identifier
23
24 The route request identifier is an 8-bit sequence number for route requests and is incremented by one every
25 time the NWK layer on a particular device issues a route request.
26
27 2.5.1.3.3 Destination address
28
The destination address shall be 2 octets in length and represents the intended destination of the route
29
request command frame.
30
31
2.5.1.3.4 Path cost
32
33 The path cost field is 8 bits in length and is used to accumulate routing cost information as a route request
34 command frame moves through the network (see sub-clause 2.7.3.4.2).
35
36
37 2.5.2 Route reply command
38
39 The route reply command allows the specified destination device of a route request command to inform the
40 originator of the route request that the request has been received. It also allows ZigBee routers along the path
41 taken by the route request to establish state information that will enable frames sent from the source device
42 to the destination device to travel more efficiently. The payload of the route reply command shall be
43 formatted as illustrated in Figure 42.
44
45 Octets: 1 1 1 2 2 1
46
Command
47 Route
frame identifier Command Originator Responder
48 request Path cost
(see options address address
49 identifier
Table 129)
50
51 NWK payload
52
53 Figure 42 Route reply command format
54

2.5.2.1 MAC data service requirements 1

2
shall be included in the MAC frame header. 4
5
The destination MAC address and PAN identifier shall be set to the network address and PAN identifier,
6
respectively, of the first hop in the path back to the originator of the corresponding route request command
7
frame. The destination PAN identifier shall be the same as the PAN identifier of the originator.
8
sending the route reply command, which may or may not be the device from which the command originated. 10
11
The frame control field shall be set to specify that the frame is a MAC data frame with MAC security 12
disabled, since any secured frame originating from the NWK layer shall use NWK layer security. The 13
transmission options shall be set to require acknowledgment. The addressing mode and intra-PAN flags 14
shall be set to support the addressing fields described here. 15
16
2.5.2.2 NWK header fields 17
18
In order for this route reply to reach its destination and for the route discovery process to complete correctly, 19
the following information must be provided. 20
21
The frame type subfield of the NWK frame control field should be set to indicate that this frame is a NWK
22
layer command frame.
23
The destination address field in the NWK header shall be set to the network address of the first hop in the 24
path back to the originator of the corresponding route request. 25
26
The source address in the NWK header shall be set to the NWK 16-bit network address of the device that is 27
transmitting the frame. 28
29
2.5.2.3 NWK payload fields 30
31
The NWK frame payload contains a command identifier field, a command options field, the route request 32
identifier, originator and responder addresses and an up-to-date summation of the path cost. 33
34
The command frame identifier shall contain the value indicating a route reply command frame.
35
36
2.5.2.3.1 Command options field
37
The format of the 8-bit command options field is shown in Figure 43. 38
39
40
Bit: 0—6 7 41
Reserved Route repair 42
43
Figure 43 Route reply command options field 44
45
The route repair sub-field is a single-bit field. It shall have a value of 1 if and only if the route request 46
command frame is being generated as part of a route repair operation for mesh network topology (see sub- 47
clause 2.7.3.5.1). 48
49
2.5.2.3.2 Route request identifier 50
51
The request identifier field shall be set to the request identifier value from the corresponding route request 52
command frame. 53
54

1 2.5.2.3.3 Originator address

2
3 The originator address field shall be 2 octets in length and shall contain the 16-bit network address of the
4 originator of the route request command frame to which this frame is a reply.
5
6 2.5.2.3.4 Responder address
7
The responder address field shall be 2 octets in length and shall contain the 16-bit network address of the
8
device for whom the route is being discovered. The value in this field shall always be the same as the value
9
in the destination address field of the corresponding route request command frame.111
10
11
2.5.2.3.5 Path cost
12
13 The path cost field is used to sum link cost as the route reply command frame transits the network (see sub-
14 clause 2.7.3.4.3).
15
16
17 2.5.3 Route error command
18
19 A device uses the route error command when it is unable to forward a data frame. The command notifies the
20 source device of the data frame about the failure in forwarding the frame. The payload of a route error
21 command shall be formatted as illustrated in Figure 44.
22
23 Octets: 1 1 2
24
Command
25
frame identifier Destination
26 Error code
(see address
27 Table 129)
28
29
Figure 44 Route error command frame format
30
31
2.5.3.1 MAC data service requirements
32
33 In order to transmit this command using the MAC data service, specified in [B1], the following information
34 shall be provided.
35
36 The destination MAC address and PAN identifier shall be set to the address and PAN identifier,
37 respectively, of the first hop in the path back to the source of the data frame that encountered a forwarding
38 failure.
39
40 The source MAC address and PAN identifier shall be set to the address and PAN identifier of the device
41 sending the route error command.
42
The frame control field shall be set to specify that the frame is a MAC data frame with MAC security
43
disabled, since any secured frame originating from the NWK layer shall use NWK layer security. The
44
implementer shall determine whether an acknowledgment shall be requested. The addressing mode and
45
intra-PAN flags shall be set to support the addressing fields described here.
46
47
2.5.3.2 NWK header fields
48
49 In order to send the route error command frame, the destination address field in the NWK header shall be set
50 to the same value as the source address field of the data frame that encountered a forwarding failure.
51
52
53
111
54 CCB Comment #132

The source address in the NWK header shall be set to the address of the device sending the route error 1
command. 2
3
2.5.3.3 Error code 4
5
The error code shall be set to one of the non-reserved values shown in Table 130. 6
Table 130 Error codes for route error command frame 7
8
Value Error code 9
0x00 No route available 10
11
0x01 Tree link failure 12
0x02 Non-tree link failure 13
14
0x03 Low battery level 15
16
0x04 No routing capacity
17
0x05 -- 0xff Reserved 18
19
20
2.5.3.4 Destination address 21
22
The destination address is 2 octets in length and shall contain the destination address from the data frame 23
that encountered the forwarding failure. 24
25
2.5.4 Leave command 26
27
The leave command is used by the NLME to inform the parent and children of a device that it is leaving the 28
network or else to request that a device leave the network. The payload of the leave command shall be 29
formatted as shown in Figure 45 30
31
32
Octets: 1 1
33
Command 34
frame identifier Command 35
(see options 36
Table 129) 37
38
Figure 45 Leave command frame format 39
40
2.5.4.1 MAC data service requirement 41
42
shall be provided. 44
The destination MAC address and PAN identifier shall be set to the address and PAN identifier, 45
respectively, of the neighbor device to which the frame is being sent. 46
47
sending the leave command. 49
50
The frame control field shall be set to specify that the frame is a MAC data frame with MAC security 51
disabled, since any secured frame originating from the NWK layer shall use NWK layer security. 52
Acknowledgment shall be requested. The addressing mode and intra-PAN flags shall be set to support the 53
addressing fields described here. 54

1 2.5.4.2 NWK header fields

2
3 In order to send the leave command frame, the destination address field in the NWK header shall be set to
4 the network address of the neighbor to which the frame is being sent. The source address in the NWK header
5 shall be set to the address of the device sending the leave command. The radius field in the NWK header
6 shall be set to 1.
7
8 2.5.4.3 Command options
9
The format of the 8-bit command options field is shown in figure 17.
10
11
12 Bit: 0—5 6 7
13
Reserved Request/indication Remove children
14
15
16 Figure 46 Leave command options field
17
18 2.5.4.3.1 Request/indication sub-field
19 The request/indication sub-field is a single bit field located at bit 6. If the value of this sub-field is 1 then the
20 leave command frame is a request for another device to leave the network. If the value of this sub-field is 0
21 then the leave command frame is an indication that the sending device plans to leave the network.
22
23 2.5.4.3.2 Remove children sub-field
24
25 The remove children sub-field is a single bit field located at bit 7. If this sub-field has a value of 1 then the
26 children of the device that is leaving the network will also be removed.112
27
28
29 2.6 Constants and NIB attributes
30
31
32 2.6.1 NWK constants
33
34 The constants that define the characteristics of the NWK layer are presented in Table 131.
35 Table 131 NWK layer constants
36
37 Constant Description Value
38 A Boolean flag indicating whether the
39 device is capable of becoming the ZigBee
40 coordinator. A value of 0x00 indicates that
nwkcCoordinatorCapable the device is not capable of becoming a Set at build time.
41
coordinator while a value of 0x01 indi-
42 cates that the device is capable of
43 becoming a coordinator.
44
45 The default security level to be used (see
nwkcDefaultSecurityLevel ENC-MIC-64
Chapter 3)
46
47 The maximum number of times a route
nwkcDiscoveryRetryLimit 0x03
48 discovery will be retried.
49
The maximum depth (minimum number of
50 nwkcMaxDepth logical hops from the ZigBee coordinator) 0x0fa
51 a device can have.
52
53
112
54 CCB Comment #107

Table 131 NWK layer constants 1

2
The minimum number of octets added by
nwkcMinHeaderOverhead 0x08b 3
the NWK layer to a NSDU.
4
The version of the ZigBee NWK protocol 5
nwkcProtocolVersion 0x01
in the device. 6
Maximum number of allowed communica- 7
nwkcRepairThreshold tion errors after which the route repair 0x03 8
mechanism is initiated. 9
10
Time duration in milliseconds until a route
nwkcRouteDiscoveryTime 0x2710 11
discovery expires.
12
The maximum broadcast jitter time mea- 13
nwkcMaxBroadcastJitter 0x40
sured in milliseconds. 14
15
The number of times the first broadcast
nwkcInitialRREQRetries transmission of a route request command 0x03 16
frame is retried. 17
18
The number of times the broadcast trans- 19
mission of a route request command
nwkcRREQRetries 0x02 20
frame is retried on relay by an intermedi-
ate ZigBee router or ZigBee coordinator. 21
22
The number of milliseconds between 23
nwkcRREQRetryInterval retries of a broadcast route request com- 0xfe
24
mand frame.
25
The minimum jitter, in 2 millisecond slots, 26
nwkcMinRREQJitter for broadcast retransmission of a route 0x01 27
request command frame. 28
The maximum jitter, in 2 millisecond slots, 29
nwkcMaxRREQJitter for broadcast retransmission of a route 0x40 30
request command frame. 31
aCCB Comment #229
32
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

1 2.6.2 NWK information base

2
3 The NWK information base (NIB) comprises the attributes required to manage the NWK layer of a device.
4 Each of these attributes can be read or written using the NLME-GET.request and NLME-SET.request
5 primitives, respectively. The attributes of the NIB are presented in Table 132.
6
Table 132 NWK IB attributesa
7
8 Attribute Id Type Range Description Default
9 A sequence number Random
10 used to identify outgoing value from
nwkSequenceNumber 0x81 Integer 0x00-0xff
frames (see sub- within the
11
12 clause 2.7.2)b range.
13 The maximum time
14 duration in seconds
15 allowed for the parent
16 and all child devices to
nwkPassiveAckTimeout 0x82 Integer 0x00-0x0a 0x03
17 retransmit a broadcast
message (passive
18 acknowledgment time-
19 out).
20
21 The maximum number
of retries allowed after a
22 nwkMaxBroadcastRetries 0x83 Integer 0x00-0x5 0x03
broadcast transmission
23 failure.
24
25 The number of children
26 a device is allowed to
nwkMaxChildren 0x84 Integer 0x00 – 0xff 0x07
have on its current net-
27 work.
28
29 0x01- nwkc- The depth a device can
nwkMaxDepth 0x85 Integer 0x05
30 MaxDepth have.
31 The number of routers
32 any one device is
33 allowed to have as chil-
34 dren.
35 nwkMaxRouters 0x86 Integer 0x01-0xff 0x05
This value is determined
36 by the ZigBee coordina-
37 tor for all devices in the
38 network.
39
The current set of neigh-
40
nwkNeighborTable 0x87 Set Variable bor table entries in the Null set
41 device (see Table 133).
42
43 Time duration in sec- nwkPas-
44 (nwkPassiveAck- onds that a broadcast siveAck-
nwkNetworkBroadcastDeliv- Timeout * nwk- message needs to Timeout *
45 0x88 Integer
eryTime BroadcastRetries encompass the entire nwkBroad-
46 ) – 0xff network. castRe-
47 tries
48
49
50
51
52
53
54

Table 132 NWK IB attributesa 1

2
If this is set to zero, the
NWK layer shall calcu- 3
late link cost from all 4
neighbor nodes using 5
nwkReportConstantCost 0x89 Integer 0x00-0x01 0x00
the LQI values reported 6
by the MAC layer. Oth- 7
erwise it shall report a
constant value 8
9
The number of retries nwkcDis- 10
nwkRouteDiscoveryRetries-
Permitted
0cx8a Integer 0x00-x03 allowed after an unsuc- coveryRe- 11
cessful route request. tryLimit
12
The current set of rout- 13
nwkRouteTable 0x8b Set Variable ing table entries in the Null set 14
device (see Table 135). 15
16
The current route sym-
metry setting: 17
18
TRUE means that 19
routes are considers to 20
be comprised of sym-
21
metric links. Backward
and forward routes are 22
created during one route 23
nwkSymLink 0x8e Boolean TRUE or FALSE FALSE
discovery and they are 24
identical. 25
26
FALSE indicates that
routes are not consider 27
to be comprised of sym- 28
metric links. Only the 29
forward route is stored 30
during route discovery
31
This field shall contain 32
the capability device 33
Bit vec-
nwkCapabilityInformation 0x8f See Table 112 capability information 0x00 34
tor
established at network 35
joining time.
36
A flag that determines 37
whether the NWK layer 38
should use the default 39
distributed address allo-
40
cation scheme or allow
the next higher layer to 41
define a block of 42
addresses for the NWK 43
layer to allocate to its 44
nwkUseTreeAddrAlloc 0x90 Boolean TRUE or FALSE TRUE
children:
45
TRUE = use distributed 46
address allocation. 47
48
FALSE = allow the next 49
higher layer to define
50
address allocation.
51
52
53
54

1 Table 132 NWK IB attributesa

2
A flag that determines
3 whether the NWK layer
4 should assume the abil-
5 ity to use hierarchical
6 routing:
7
nwkUseTreeRouting 0x91 Boolean TRUE or FALSE TRUE = assume the TRUE
8 ability to use hierarchical
9 routing.
10
11 FALSE = never use hier-
12 archical routing.
13
14 The next network
15 address that will be
16 assigned to a device
requesting association.
17
nwkNextAddress 0x92 Integer 0x0000 - 0xfffd This value shall be 0x0000
18 incremented by nwkAd-
19 dressIncrement every
20 time an address is
21 assigned.
22 The size of remaining
23 block of addresses to be
24 assigned. This value will
25 be decremented by 1
26 nwkAvailableAddresses 0x93 Integer 0x0000 - 0xfffd every time an address is 0x0000
assigned. When this
27 attribute has a value of
28 0, no more associations
29 may be accepted.
30
The amount by which
31
nwkNextAddress is
32 nwkAddressIncrement 0x94 Integer 0x0000 - 0xfffd 0x0001
incremented each time
33 an address is assigned.
34
35 The maximum time (in
superframe periods) that
36 a transaction is stored
37 by a coordinator and
38 indicated in its beacon.
39 This attribute reflects the
nwkTransactionPersisten- value of the MAC PIB
40 0x95 Integer 0x0000-0xffff 0x01f4d
ceTime attribute macTransac-
41 tionPersistenceTime
42 (see [B1]) and any
43 changes made by the
44 higher layer will be
45 reflected in the MAC PIB
attribute value as well.
46
47 a
CCB Comment #120
cCCB Comment #115
49 dCCB Comment #252
50
51
52
53
54

2.7 Functional description 1

2
3
2.7.1 Network and device maintenance 4
5
All ZigBee devices shall provide the following functionality: 6
7
— Join a network.
8
— Leave a network. 9
10
Both ZigBee coordinators and routers shall provide the following additional functionality: 11
12
— Permit devices to join the network using the following:
13
— Association indications from the MAC. 14
15
— Explicit join requests from the application. 16
— Permit devices to leave the network using the following: 17
18
— Disassociation indications from the MAC. 19
— Explicit leave requests from the application. 20
21
— Participate in assignment of logical network addresses.
22
— Maintain a list of neighboring devices. 23
24
ZigBee coordinators shall provide functionality to establish a new network. 25
26
2.7.1.1 Establishing a new network 27
28
The procedure to establish a new network is initiated through the use of the NLME-NETWORK- 29
FORMATION.request primitive. Only devices that are ZigBee coordinator capable and not currently joined 30
to a network shall attempt to establish a new network. If this procedure is initiated on any other device, the 31
NLME shall terminate the procedure and notify the next higher layer of the illegal request. This is achieved 32
by issuing the NLME-NETWORK-FORMATION.confirm primitive with the Status parameter set to 33
INVALID_REQUEST. 34
When this procedure is initiated, the NLME shall first request that the MAC sub-layer perform an energy 35
detection scan over either a specified set of channels or, by default, the complete set of available channels, as 36
dictated by the PHY layer [B1], to search for possible interferers. A channel scan is initiated by issuing the 37
MLME-SCAN.request primitive, with the ScanType parameter set to energy detection scan, to the MAC 38
sub-layer and the results are communicated back via the MLME-SCAN.confirm primitive. 39
40
On receipt of the results from a successful energy detection scan, the NLME shall order the channels 41
according to increasing energy measurement and discard those channels whose energy levels are beyond an 42
acceptable level. The choice of an acceptable energy level is left to the implementation. The NLME shall 43
then perform an active scan, by issuing the MLME-SCAN.request primitive with a ScanType parameter set 44
to active scan and ChannelList set to the list of acceptable channels to search for other ZigBee devices. To 45
determine the best channel on which to establish a new network, the NLME shall review the list of returned 46
PAN descriptors and find the first channel with the lowest number of existing networks, favoring a channel 47
with no detected networks. 48
49
If no suitable channel is found, the NLME shall terminate the procedure and notify the next higher layer of 50
the startup failure. This is achieved by issuing the NLME-NETWORK-FORMATION.confirm primitive 51
with the Status parameter set to STARTUP_FAILURE. 52
53
54

1 If a suitable channel is found, the NLME shall select a PAN identifier for the new network. To do this, check
2 if the optional PANId parameter was specified in the NLME-NETWORK-FORMATION.request was
3 specified. If present and there is no conflict with existing PANIds this value will become the new network’s
4 PANId. Otherwise the device shall choose a random PAN identifier such that it is not the broadcast PAN
5 identifier (0xffff) and it is unique amongst the networks found on the selected channel. Additionally, the
6 PAN identifier shall be less than or equal to 0x3fff as the two most significant bits of the 16-bit PAN
7 identifier are reserved for future use. Once the NLME makes its choice, it shall set the macPANID attribute
8 in the MAC sub-layer to this value by issuing the MLME-SET.request primitive.
9
10 If no unique PAN identifier can be chosen, the NLME shall terminate the procedure and notify the next
11 higher layer of the startup failure by issuing the NLME-NETWORK-FORMATION.confirm primitive with
12 the Status parameter set to STARTUP_FAILURE.
13
Once a PAN identifier is selected, the NLME shall select a 16-bit network address equal to 0x0000 and set
14
the macShortAddress PIB attribute in the MAC sub-layer so that it is equal to the selected network address.
15
16 Once a network address is selected, the NLME shall begin operation of the new PAN by issuing the MLME-
17 START.request primitive to the MAC sub-layer. The parameters of the MLME-START.request primitive
18 shall be set according to those passed in the NLME-NETWORK-FORMATION.request, the results of the
19 channel scan, and the chosen PAN identifier. The status of the PAN startup is communicated back via the
20 MLME-START.confirm primitive.
21
22 On receipt of the status of the PAN startup, the NLME shall inform the next higher layer of the status of its
23 request to initialize the ZigBee coordinator. This is achieved by issuing the NLME-NETWORK-
24 FORMATION.confirm primitive with the Status parameter set to that returned in the MLME-
25 START.confirm from the MAC sub-layer.
26
27 The procedure to successfully start a new network is illustrated in the message sequence chart (MSC) shown
28 in Figure 47.
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

1
2
ZigBee Coord. ZigBee Coord. ZigBee Coord. 3
APL NWK MAC 4
5
NLME-NETWORK-
FORMATION.request 6
MLME-
SCAN.request 7
8
Perform energy 9
MLME- detection scan 10
SCAN.confir m
11
MLME- 12
SCAN.request 13
14
Perform active scan 15
MLME-
SCAN.confir m 16
17
Select channel, PAN ID 18
and logical address MLME-
SET.request 19
20
MLME- 21
SET.confir m 22
MLME- 23
START.request 24
25
MLME- 26
NLME-NETWORK- START.confirm
FORMATION.confirm 27
28
29
30
31
Figure 47 Establishing a new network 32
33
34
35
2.7.1.2 Permitting devices to join a network 36
37
The procedure for permitting devices to join a network is initiated through the NLME-PERMIT-
38
JOINING.request primitive. Only devices that re either the ZigBee coordinator or a ZigBee router shall
39
attempt to permit devices to join the network. If this procedure is initiated on any other device, the NLME
40
shall terminate the procedure.
41
When this procedure is initiated with the PermitDuration parameter set to 0x00, the NLME shall set the 42
macAssociationPermit PIB attribute in the MAC sub-layer to FALSE. A MAC sub-layer attribute setting is 43
initiated by issuing the MLME-SET.request primitive. 44
45
When this procedure is initiated with the PermitDuration parameter set to a value between 0x01 and 0xfe, 46
the NLME shall set the macAssociationPermit PIB attribute in the MAC sub-layer to TRUE. The NLME 47
shall then start a timer to expire after the specified duration. On expiry of this timer, the NLME shall set the 48
macAssociationPermit PIB attribute in the MAC sub-layer to FALSE. 49
50
When this procedure is initiated with the PermitDuration parameter set to 0xff, the NLME shall set the 51
macAssociationPermit PIB attribute in the MAC sub-layer to TRUE for an unlimited amount of time, unless 52
another NLME-PERMIT-JOINING.request primitive is issued. 53
54

1 The procedure for permitting devices to join a network is illustrated in the MSC shown in Figure 48.
2
3
4
Device Device Device
5
6 APL NWK MAC
7 NLME-
8 PERMIT-JOINING.reques MLME -
SET.reques
9
10 MLME -
SET.confirm
11
12
13 Duration to permit
14 joining
15 MLME -
16 SET.reques
17
18 MLME -
19 NLME- SET.confirm
PERMIT-JOINING.confirm
20
21
22 Figure 48 Permitting devices to join a network
23
24 2.7.1.3 Joining a network
25
26 A parent-child relationship is formed when a device having membership in the network allows a new device
27 to join. The new device becomes the child, while the first device becomes the parent. A child can be added
28 to a network in the following two ways: the child can join the network using the MAC layer association
29 procedure or the child can be added to the network directly by a previously designated parent device.
30
31 2.7.1.3.1 Joining a network through association
32
33 This sub-clause specifies the procedure a device (child) shall follow to join a network, as well as the
34 procedure a ZigBee coordinator or router (parent) shall follow upon receipt of a join request. Any device
35 may accept a join request from a new device so long as it has the necessary physical capabilities and the
36 available network address space. Only a ZigBee coordinator or a router is physically capable of accepting a
37 join request, while an end device is not.
38
39 2.7.1.3.1.1 Child procedure
40
41 The procedure for joining a network using the MAC layer association procedure shall be initiated by issuing
42 the NLME-NETWORK-DISCOVERY.request primitive with the ScanChannels parameter set to indicate
43 which channels are to be scanned for networks and the ScanDuration parameter set to indicate the length of
44 time to be spent scanning each channel. Upon receipt of this primitive, the NWK layer shall issue an
45 MLME-SCAN.request primitive asking the MAC sub-layer to perform a passive or113 active scan.
46 Every beacon frame received during the scan having a non-zero length payload shall cause the MLME-
47 BEACON-NOTIFY.indication primitive to be issued from the MAC sub-layer of the scanning device to its
48 NLME. This primitive includes information such as the addressing information of the beaconing device,
49 whether it is permitting association and the beacon payload (see [B1] for the complete list of parameters).
50 The NLME of the scanning device shall check the protocol ID field in the beacon payload and verify that it
51 matches the ZigBee protocol identifier. If not, the beacon is ignored. Othewise, the device shall copy the
52
53
113
54 CCB Comment #117

relevant information from each received beacon (see Figure 63 for the structure of the beacon payload) into 1
its neighbor table (see Table 133 for the contents of a neighbor table entry). 2
3
Once the MAC sub-layer signals the completion of the scan by issuing the MLME-SCAN.confirm primitive 4
to the NLME, the NWK layer shall issue the NLME-NETWORK-DISCOVERY.confirm primitive 5
containing a description of each network that was heard. Every network description contains the ZigBee 6
version, stack profile, PAN ID, logical channel114, and information on whether it is permitting joining (see 7
Table 104). 8
9
Upon receipt of the NLME-NETWORK-DISCOVERY.confirm primitive, the next higher layer is informed
10
of the networks present in the neighborhood. The next higher layer may choose to redo the network
11
discovery to discover more networks or for other reasons. If not, it shall choose a network to join from the
12
discovered networks. It shall then issue the NLME-JOIN.request with the PANId parameter set to the PAN
13
identifier of the desired network, the RejoinNetwork parameter set to FALSE and the JoinAsRouter
14
parameter set to indicate whether the device wants to join as a routing device.
15
Only those devices that are not already joined to a network shall initiate the join procedure. If any other 16
device initiates this procedure, the NLME shall terminate the procedure and notify the next higher layer of 17
the illegal request by issuing the NLME-JOIN.confirm primitive with the Status parameter set to 18
INVALID_REQUEST. 19
20
For a device that is not already joined to a network, the NLME-JOIN.request primitive shall cause the NWK 21
layer to search its neighbor table for a suitable parent device. A suitable parent device shall have the desired 22
PAN ID and shall be permitting association and shall have a link cost (see sub-clause 2.7.3.1 for details on 23
link cost) of at most 3. It shall also have the potential parent field set to one, if that field is present in the 24
neighbor table entry. 25
26
If the neighbor table contains no devices that are suitable parents, the NLME shall respond with an NLME- 27
JOIN-CONFIRM with a status parameter of NOT_PERMITTED. If the neighbor table has more than one 28
device that could be a suitable parent, the device which is at a minimum depth from the ZigBee coordinator 29
shall be chosen. If more than device has a minimum depth, the implementation is free to choose from among 30
them. 31
32
Once a suitable parent is identified, the NLME shall issue an MLME-ASSOCIATE.request primitive to the
33
MAC sub-layer. The addressing parameters in the MLME-ASSOCIATE.request primitive (see Chapter 1)
34
shall be set to contain the addressing information for the device chosen from the neighbor table. The status
35
of the association is communicated back to the NLME via the MLME-ASSOCIATE.confirm primitive.
36
If the attempt to join was unsuccessful, the NWK layer shall receive an MLME-ASSOCIATE.confirm 37
primitive from the MAC sub-layer with the status parameter indicating the error. If the status parameter 38
indicates a refusal to permit joining on the part of the neighboring device (i.e., PAN at capacity or PAN 39
access denied), then the device attempting to join should set the Potential parent bit to zero in the 40
corresponding neighbor table entry to indicate a failed join attempt. Setting the Potential parent bit to zero 41
ensures that the NWK layer shall not issue another request to associate to the same neighboring device. The 42
Potential parent bit should be set to one for every entry in the neighbor table each time an MLME- 43
SCAN.request primitive is issued. 44
45
A join request may also be unsuccessful, if the potential parent is not allowing new routers to associate (e.g. 46
the max number of routers, nwkMaxRouters may already have associated with the device) and the joining 47
device has set the JoinAsRouter parameter to TRUE. In this case the NLME-JOIN.confirm primitive will 48
indicate a status of NOT_PERMITTED. In this case the child device’s application may wish to attempt to 49
join again but as an end device by issuing another NLME-JOIN.request with the JoinAsRouter parameter set 50
to FALSE. 51
52
53
114
CCB Comment #267 54

1 If the attempt to join was unsuccessful, the NLME shall attempt to find another suitable parent from the
2 neighbor table. If no such device could be found, the NLME shall issue the NLME-JOIN.confirm primitive
3 with the Status parameter set to the value returned in the MLME-ASSOCIATE.confirm primitive.
4
5 If the attempt to join was unsuccessful and there is a second neighboring device that could be a suitable
6 parent, the NWK layer shall initiate the MAC sub-layer association procedure with the second device. The
7 NWK layer shall repeat this procedure until it either joins the PAN successfully or exhausts its options to
8 join the PAN.
9
If the device cannot successfully join the PAN specified by the next higher layer, the NLME shall terminate
10
the procedure by issuing the NLME-JOIN.confirm primitive with the Status parameter set to the value
11
returned in the last received MLME-ASSOCIATE.confirm primitive. In this case, the device shall not
12
receive a valid logical address and shall not be permitted to transmit on the network.
13
14 If the attempt to join was successful, the MLME-ASSOCIATE.confirm primitive received by the NWK
15 layer shall contain a 16-bit logical address unique to that network that the child can use in future
16 transmissions. The NWK layer shall then set the Relationship field in the corresponding neighbor table entry
17 to indicate that the neighbor is its parent. By this time, the parent shall have each added the new device to its
18 neighbor table.
19
20 If the device is attempting to join a secure network and it is a router it will need to wait until its parent has
21 authenticated it before transmitting beacons. The device shall therefore, wait for an NLME-START-
22 ROUTER.request primitive to be issued from the next higher layer. Upon receipt of this primitive the
23 NLME shall issue an MLME-START.request primitive as described below if it is a router. If the NLME-
24 START.ROUTER.request primitive is issued on an end device, the NWK layer shall issue an NLME-
25 START-ROUTER.confirm primitive with the status value set to INVALID_REQUEST.
26
27 Once the device has successfully joined the network and the next higher layer has issued a NLME-START-
28 ROUTER.request, if it is a router, the NWK layer shall issue the MLME-START.request primitive to its
29 MAC sub-layer to setup its superframe configuration and begin transmitting beacon frames, if applicable.
30 Beacon frames are only transmitted if the BeaconOrder parameter is not equal to fifteen [B1]. The PANId,
31 LogicalChannel, BeaconOrder and SuperframeOrder parameters shall be set equal to the corresponding
32 values held in the neighbor table entry for its parent. The PANCoordinator and CoordRealignment
33 parameters shall both be set to FALSE. Upon receipt of the MLME-START.confirm primitive, the NWK
34 layer shall issue an NLME-START-ROUTER.confirm primitive with the same status value.
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

1
2
Child Child Child 3
APL NWK MAC 4
5
6
NLME-NETWORK-
MLME -
7
DISCOVERY.reques
SCAN.reques 8
9
Perform active or passive sca 10
MLME -BEACON-
11
NOTIFY.indication 12
. 13
. 14
. 15
16
MLME -BEACON-
NOTIFY.indication
17
18
MLME -
19
SCAN.confirm 20
NLME-NETWORK- 21
DISCOVERY.confirm
22
23
Select suitable PAN 24
NLME- 25
JOIN.reques MLME - 26
ASSOCIATE.reques 27
28
Association procedure 29
MLME -
NLME- ASSOCIATE.confirm 30
JOIN.confirm 31
32
Authentication procedur 33
NLME- 34
START-ROUTER.reques MLME -
START.reques 35
36
MLME -
NLME- 37
START.confirm
START-ROUTER.confirm 38
39
40
Figure 49 Procedure for joining a network through association 41
42
2.7.1.3.1.2 Parent procedure 43
44
The procedure for a ZigBee coordinator or router to join a device to its network using the MAC sub-layer 45
association procedure is initiated by the MLME-ASSOCIATE.indication primitive arriving from the MAC 46
sub-layer. Only those devices that are either a ZigBee coordinator or a ZigBee router and that are permitting 47
devices to join the network shall initiate this procedure. If this procedure is initiated on any other device, the 48
NLME shall terminate the procedure. 49
50
When this procedure is initiated, the NLME of a potential parent shall first determine whether the device 51
wishing to join already exists on its network. To do this, the NLME shall search its neighbor table in order to 52
determine whether a matching 64-bit, extended address can be found. If a match is found, the NLME shall 53
obtain the corresponding 16-bit network address and issue an association response to the MAC sub-layer. If 54

1 a match is not found, the NLME shall, if possible, allocate a 16-bit network address for the new device that
2 is unique to that network. A finite address space is allocated to every potential parent device, and a device
3 may disallow a join request once this address space is exhausted. The ZigBee coordinator determines the
4 amount of address space given. See sub-clause 2.7.1.4 and sub-clause 2.7.1.5115 for an explanation of the
5 address assignment mechanism.
6
7 If the potential parent has exhausted its allocated address space, the NLME shall terminate the procedure
8 and indicate the fact in the subsequent MLME-ASSOCIATE.response primitive to the MAC sub-layer. The
9 Status parameter of this primitive shall indicate that the PAN is at capacity. This status value uses MAC sub-
10 layer terminology and only indicates that the potential parent does not have the capacity to accept any more
11 children. It is possible in a multihop network that other potential parents still having sufficient address space
12 exist within the same network.
13
If the request to join is granted, the NLME of the parent shall create a new entry for the child in its neighbor
14
table using the supplied device information and indicate a successful association in the subsequent MLME-
15
ASSOCIATE.response primitive to the MAC sub-layer. The status of the response transmission to the child
16
is communicated back to the network layer via the MLME-COMM-STATUS.indication primitive.
17
18 If the transmission was unsuccessful (the MLME-COMM-STATUS.indication primitive contained a Status
19 parameter not equal to SUCCESS), the NLME shall terminate the procedure. If the transmission was
20 successful, the NLME shall notify the next higher layer that a child has just joined the network by issuing
21 the NLME-JOIN.indication primitive.
22
23 The procedure for successfully joining a device to the network is illustrated in the MSC shown in Figure 50
24 – Procedure for handling a join request.
25
26
27
Parent Parent Parent
28
29
APL NWK MAC
30 MLME-
31 ASSOCIATE.indication
32
33 Check extended address and
34 assign logical address
35
MLME-
36
ASSOCIATE.response
37
38
39 MLME-
NLME- COMM-STATUS.i ndication
40 JOIN.indication
41
42
43
44 Figure 50 Procedure for handling a join request
45
46
47
48 2.7.1.3.2 Joining a network directly
49
This sub-clause specifies how a child can be directly added to a network by a previously designated parent
50
device (ZigBee coordinator or router). In this case, the parent device is preconfigured with the 64-bit address
51
52
53
115
54 CCB Comment #122

of the child device. The following text describes how this prior address knowledge shall be used to establish 1
the parent-child relationship. 2
3
The procedure for a ZigBee coordinator or router to directly join a device to its network is initiated by 4
issuing the NLME-DIRECT-JOIN.request primitive with the DeviceAddress parameter set to the address of 5
the device to be joined to the network. Only those devices that are either a ZigBee coordinator or a ZigBee 6
router shall initiate this procedure. If this procedure is initiated on any other device, the NLME shall 7
terminate the procedure and notify the next higher layer of the illegal request by issuing the NLME- 8
DIRECT-JOIN.confirm primitive with the Status parameter set to INVALID_REQUEST. 9
10
When this procedure is initiated, the NLME of the parent shall first determine whether the specified device
11
already exists on its network. To do this, the NLME shall search its neighbor table in order to determine
12
whether a matching 64-bit, extended address can be found. If a match is found, the NLME shall terminate
13
the procedure and notify the next higher layer that the device is already present in the device list by issuing
14
the NLME-DIRECT-JOIN.confirm primitive with the Status parameter set to ALREADY_PRESENT.
15
If a match is not found, the NLME shall, if possible, allocate a 16-bit network address for the new device, 16
which is unique to that network. A finite address space is allocated to every potential parent device, and the 17
potential parent shall only create a new entry for the device in its neighbor table if it has the capacity to do 18
so. If capacity is not available, the NLME shall terminate the procedure and notify the next higher layer of 19
the unavailable capacity by issuing the NLME-DIRECT-JOIN.confirm primitive with the Status parameter 20
set to TABLE_FULL. If capacity is available, the NLME shall inform the next higher layer that the device 21
has joined the network by issuing the NLME-DIRECT-JOIN.confirm primitive with the Status parameter 22
set to SUCCESS. 23
24
The ZigBee coordinator determines the amount of address space given to every potential parent device. See 25
sub-clause 2.7.1.4 and sub-clause 2.7.1.5116 for an explanation of the address assignment mechanism. 26
27
Once the parent has added the child to its network, it is still necessary for the child to make contact with the 28
parent to complete the establishment of the parent-child relationship. The child shall fulfill this requirement 29
by initiating the orphaning procedure, which is described in sub-clause 2.7.1.3. 30
31
The procedure a parent shall follow to successfully join a device to the network directly is illustrated in the
32
MSC shown in Figure 51. This procedure does not require any over-the-air transmissions.
33
34
35
Parent Parent Parent 36
37
APL NWK MAC
38
NLME-DIRECT- 39
JOIN.request(DeviceAddress) 40
41
Check extended address and 42
assign logical address 43
NLME-DIRECT- 44
JOIN.confirm 45
46
47
48
Figure 51 Joining a device to a network directly
49
50
51
52
53
116
CCB Comment #122 54

1 2.7.1.3.3 Joining or re-joining a network through orphaning

2
3 This sub-clause specifies how the orphaning procedure can be initiated by a device that has been directly
4 joined to a network (joining through orphaning) or by a device that was previously joined to a network but
5 has lost contact with its parent (re-joining through orphaning).
6
A device that has been added to a network directly shall initiate the orphan procedure in order to complete
7
the establishment of its relationship with its parent. The application on the device will determine whether to
8
initiate this procedure and, if so, will notify the network layer upon power up.
9
10 A device that was previously joined to a network has the option of initiating the orphan procedure if its
11 NLME repeatedly receives communications failure notifications from its MAC sub-layer.
12
13 2.7.1.3.3.1 Child procedure
14
15 The joining through orphaning procedure is initiated by a child device through the NLME-JOIN.request
16 primitive with RejoinNetwork parameter set to TRUE.
17
18 When this procedure is initiated, the NLME shall first request that the MAC sub-layer perform an orphan
19 scan over the complete set of available channels, as dictated by the PHY layer [B1]. An orphan scan is
20 initiated by issuing the MLME-SCAN.request primitive to the MAC sub-layer, and the result is
21 communicated back to the NLME via the MLME-SCAN.confirm primitive.
22
If the orphan scan was successful (the child has found its parent), the NLME shall inform the next higher
23
layer of the success of its request to join or re-join the network by issuing the NLME-JOIN.confirm
24
primitive with the Status parameter set to SUCCESS.
25
26 If the orphan scan was unsuccessful (the parent has not been found), the NLME shall terminate the
27 procedure and notify the next higher layer that no networks were found. This is achieved by issuing the
28 NLME-JOIN.confirm primitive with the Status parameter set to NO_NETWORKS.
29
30 The procedure for a child to successfully join or re-join a network through orphaning is illustrated in the
31 MSC shown in Figure 52.
32
33
34 Child Child Child
35 APL NWK MAC
36
37 NLME-
JOIN.request(True)
38 MLME-
39 SCAN.request
40
41 Perform orphan scan
42
43 MLME -
NLME- SCAN.confirm
44 JOIN.confirm
45
46
47
48
Figure 52 Child procedure for joining or re-joining a network through orphaning
49
50
2.7.1.3.3.2 Parent procedure
51
52 A device is notified of the presence of an orphaned device when it receives the MLME-ORPHAN.indication
53 primitive from the MAC sub-layer. Only those devices that are either a ZigBee coordinator or a ZigBee
54

router (a device with parental capabilities) shall initiate this procedure. If this procedure is initiated on any 1
other device, the NLME shall terminate the procedure. 2
3
When this procedure is initiated, the NLME shall first determine whether the orphaned device is its child. 4
This is accomplished by comparing the extended address of the orphaned device with the addresses of its 5
children, as recorded in its neighbor table. If a match is found (the orphaned device is its child), the NLME 6
shall obtain the corresponding 16-bit network address and include it in its subsequent orphan response to the 7
MAC sub-layer. The orphan response to the MAC sub-layer is initiated by issuing the MLME- 8
ORPHAN.response primitive, and the status of the transmission is communicated back to the NLME via the 9
MLME-COMM-STATUS.indication primitive. 10
11
If an address match is not found (the orphaned device is not its child), the NLME shall indicate the fact in its
12
subsequent orphan response to the MAC sub-layer.
13
The procedure for a parent to join or re-join its orphaned child to the network is illustrated in the MSC 14
shown in Figure 53. 15
16
17
18
19
Parent Parent Parent
20
APL NWK MAC 21
MLME- 22
ORPHAN.indication 23
24
Search for address in 25
device table 26
MLME- 27
ORPHAN.response
28
29
MLME- 30
COMM-STATUS.i ndication
31
32
33
34
35
Figure 53 Parent procedure for joining or re-joining a device to its network through 36
orphaning 37
38
2.7.1.3.4 Neighbor tables 39
The neighbor table of a device shall contain information on every device within transmission range up to 40
some implementation-dependent limit. The information in stored in the neighbor table is used for a variety 41
of purposes, however, not all fields described in this subsection are required for the operation of a ZigBee 42
device. Each entry in the table shall contain the following information about a neighboring device: 43
44
— PAN identifier 45
46
— Extended address if device is parent or child
47
— Network address 48
49
— Device type
50
— Relationship 51
52
53
54

1 The following are not required but implementers may wish to include the following information in each
2 neighbor table. Additionally, it should be noted that implementers may wish to record additional information
3 in the neighbor table and the following list is not intended to exclude this possibility.
4
5 — RxOnWhenIdle
6 — Extended address (any neighbor)
7
8 — Beacon Order
9 — Depth
10
11 — Permit joining
12 — Transmit Failure
13
14 — Potential parent
15 — Average LQI
16
17 — Logical Channel
18 — Incoming beacon frame timestamp
19
20 — Beacon transmission time offset
21
22
23 A table entry shall be updated every time a device receives any frame from the corresponding neighbor. The
24 contents of a neighbor table entry are shown in Table 133.
25
26 Table 133 Neighbor table entry format
27 Field name Field type Valid range Description
28
The 16-bit PAN identifier of the
29
neighboring device.
30 PAN Id Integer 0x0000—0x3fff
31 This field shall be present in
32 every neighbor table entry.
33
64-bit IEEE address that is
34 unique to every device.
35 An extended 64-bit, IEEE
Extended address Integer
36 address This field shall be present if the
37 neighbor is a parent or child of
38 the device
39 The 16-bit network address of
40 the neighboring device.
Network address Network address 0x0000—0xffff
43 The type of the neighbor
44 device.:
45
46 0x00 = ZigBee coordinator
47
Device type Integer 0x00—0x02 0x01 = ZigBee router
48
49 0x02 = ZigBee end device
50
53
54

Table 133 Neighbor table entry format 1

2
Indicates if neighbor’s receiver
is enabled during idle portions 3
of the CAPa: 4
5
TRUE = Receiver is off 6
RxOnWhenIdle Boolean TRUE or FALSE 7
FALSE = Receiver is on
8
This field should be present for 9
entries that record the parent or 10
children of a ZigBee router or 11
ZigBee coordinator. 12
The relationship between the 13
neighbor and the current 14
device: 15
16
0x00=neighbor is the parent
17
0x01=neighbor is a child 18
Relationship Integer 0x00—0x03 19
0x02=neighbor is a sibling 20
21
0x03=None of the above.
22
This field shall be present in 23
every neighbor table entry. 24
25
The tree depth of the neighbor 26
device. A value of 0x00 indi-
cates that the device is the Zig- 27
Depth Integer 0x00—nwkcMaxDepth Bee coordinator for the 28
network. 29
30
This field is optional. 31
This specifies how often the 32
beacon is to be transmitted. For 33
a definition and discussion of 34
Beacon order Integer 0x00—0x0f
beacon order see [B1]. 35
36
This field is optional.
37
An indication of whether the 38
neighbor device is accepting 39
join requests. 40
TRUE = neighbor is accepting
Permit joining Boolean TRUE or FALSE join requests 41
FALSE = neighbor is not 42
accepting join requests 43
44
This field is optional. 45
A value indicating if previous 46
transmissions to the device 47
were successful or not. Higher 48
Transmit Failure Integer 0x00—0xff
values indicate more failures. 49
50
51
52
53
54

1 Table 133 Neighbor table entry format

2
An indication of whether the
3 neighbor has been ruled out as
4 a potential parent due to a
5 failed join attempt:
6
7 0x00 indicates that the neigh-
Potential parent Integer 0x00—0x01
bor is not a potential parent
8
9 0x01 indicates that the neigh-
10 bor is a potential parent.
11
12 This field is optional.
13 The estimated link quality for
14 RF transmissions from this
15 device. See sub-clause 2.7.3.1
16 LQI Integer 0x00—0xff for discussion of how this is cal-
culated.
17
18 This field is optional.
19
20 The logical channel on which
Selected from the available logi-
21 the neighbor is operating.
Logical channel Integer cal channels supported by the
22 PHY
23
24 The time, in symbols, at which
25 the last beacon frame was
received from the neighbor.
26 Incoming beacon
Integer 0x000000-0xffffff This value is equal to the times-
27 timestamp
tamp taken when the beacon
28 frame was received, as
29 described in [B1].
30
The transmission time differ-
31 ence, in symbols, between the
32 neighbor’s beacon and its par-
33 ent’s beacon. This difference
Beacon transmis-
34 Integer 0x000000-0xffffff may be subtracted from the
sion time offset
35 corresponding incoming bea-
con timestamp to calculate the
36 beacon transmission time of the
37 neighbor’s parent.
38
aCCB
39 Comment #138
40
41
42
43 2.7.1.4 Distributed117 address assignment mechanism
44
45 By default, i.e. when the NIB attribute nwkUseTreeAddrAlloc has a value of TRUE118, network addresses
46 are assigned using a distributed addressing scheme that is designed to provide every potential parent with a
47 finite sub-block of network addresses. These addresses are unique within a particular network and are given
48 by a parent to its children. The ZigBee coordinator determines the maximum number of children that any
49 device within its network is allowed. Of these children, a maximum of nwkMaxRouters can be router-
50 capable devices while the rest shall be reserved for end devices. Every device has an associated depth, which
51 indicates the minimum number of hops a transmitted frame must travel, using only parent-child links, to
52
118
54 Ibid

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

1
2
3 Table 134 Example addressing offset values for each given depth within the network
4 Depth in the network, d Offset value, Cskip(d)
5 0 21
6
7 1 5
8
2 1
9
10 3 0
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 Figure 54 Address assignment in an example network
38
Because an address sub-block cannot be shared between devices, it is possible that one parent exhausts its
39
list of addresses while a second parent has addresses that go unused. A parent having no available addresses
40
shall not permit a new device to join the network. In this situation, the new device shall find another parent.
41
If no other parent is available within transmission range of the new device, the device shall be unable to join
42
the network unless it is physically moved or there is some other change.
43
44
2.7.1.5 Higher-layer address assignment mechanism
45
46 When the NIB attribute nwkUseTreeAddrAlloc has a value of FALSE, an alternate addressing scheme is
47 used where the block of addresses to be assigned by a device is set by the next higher layer using the NIB
48 attributes nwkNextAddress, nwkAvailableAddresses and nwkAddressIncrement. In this scheme, when a
49 device has nwkAvailableAddresses equal to 0 it shall be incapable of accepting association requests. The
50 NLME of such a device shall set the macAssociationPermit PIB attribute in the MAC sub-layer to FALSE
51 by issuing the MLME-SET.request primitive and shall respond to future NLME-PERMIT-JOINING.request
52 primitives with a PermitDuration of equal to or greater than 0x01 with a NLME-PERMIT-
53 JOINING.confirm primitive with a Status parameter of INVALID_REQUEST and shall terminate the
54

permit joining procedure. If the device has nwkAvailableAddresses greater than 0, it shall accept association 1
requests by setting the macAssociationPermit PIB attribute in the MAC sub-layer to TRUE and by issuing 2
the MLME-SET.request primitive and it shall respond to future NLME-PERMIT-JOINING.request 3
primitives with a PermitDuration of equal to or greater than 0x01 with a Status parameter of SUCCESS. 4
While a device is accepting associations it shall use the value of nwkNextAddress as the address to be 5
assigned to the next device that successfully associates. After a successful association, the value of 6
nwkNextAddress shall be incremented by the value of nwkAddressIncrement and the value of 7
nwkAvailableAddresses shall be decremented by 1. 8
9
2.7.1.6 Installation and addressing 10
11
It should be clear that nwkMaxDepth roughly determines the “distance” in network terms from the root of 12
the tree to the farthest end device. In principal nwkMaxDepth also determines the overall network diameter. 13
In particular, for an ideal network layout where the ZigBee coordinator is located in the center of the 14
network, as in Figure 54, the network diameter should be 2 * nwkMaxDepth. In practice, application-driven 15
placement decisions and order of deployment may lead to a smaller diameter. In this case, nwkMaxDepth 16
provides a lower bound on the network diameter while the 2* nwkMaxDepth provides the upper bound. 17
18
Finally, due to the fact that the tree is not dynamically balanced in ZigBee 1.0, the possibility exists that
19
certain installation scenarios, such as long lines of devices, may exhaust the address capacity of the network
20
long before the real capacity is reached.
21
22
2.7.1.7 Leaving a network
23
This sub-clause specifies two methods for removing a child from a network that both use the MAC layer 24
disassociation procedure. The first is initiated by a child as a request to its parent, while the second is 25
initiated by a parent as a request to its child. 26
27
2.7.1.7.1 Method for a child to initiate its own removal from a network 28
29
This sub-clause describes how a device can initiate its own removal from the network in response to the 30
receipt of an NLME-LEAVE.request primitive from the next higher layer or in response to the receipt of a 31
leave command frame from its parent with the request/indication sub-field of the command options field of 32
the command frame payload set to 1. 33
34
When this procedure is initiated, the NLME shall transmit a leave request command frame to each of its 35
children, if any. If the procedure was initiated from the next higher layer and the RemoveChildren parameter 36
of the NLME-LEAVE.request that initiated the procedure is equal to FALSE then the remove children sub- 37
field of the command options field in the command frame payload of each outgoing frame shall be set to 0. 38
If the RemoveChildren parameter has a value of TRUE the remove children sub-field shall be set to 1. If the 39
procedure was initiated by the receipt of a leave command frame then the remove children sub-field of each 40
outgoing command frame's payload should match that of the received frame. If removal of children is called 41
for, and the device has children, the NLME shall attempt to remove each of the device's children in turn 42
using the procedure described in sub-clause 2.7.1.7.2. The NLME shall then transmit a leave command 43
frame to the device's parent, using the MCPS-DATA.request primitive of the MAC sub-layer, with the 44
request/indication sub-field of the command options field of the command frame payload set to 0. If removal 45
of children was not called for then the remove children sub-field of the command options field in the 46
command frame payload shall be set to 0. If removal of children was called for the remove children sub-field 47
of the command options field in the command frame payload shall be set to 1 if the device has no children or 48
else if the device has children and all of the device's children were successfully removed and to 0 otherwise. 49
The NLME may then issue the MLME-DISASSOCIATE.request primitive to the MAC sub-layer with the 50
DeviceAddress parameter equal to the address of the device's parent and the DisassociateReason parameter 51
equal to 0x02. On receipt of the MLME-DISASSOCIATE.confirm primitive, the NLME shall issue the 52
NLME-LEAVE.confirm primitive to the next higher layer with the DeviceAddress parameter equal to 0. 53
The Status parameter of the NLME-LEAVE.confirm primitive shall have a value of SUCCESS if: 54

1 1) The status returned by the initial MCPS-DATA.confirm above has a value of SUCCESS, and
2 2) If the NLME attempts to remove the children of the device in turn, then each of the children is
3 successfully removed, and
4 3) The status returned by the MLME.DISASSOCIATE.confirm primitive, if any, is also SUC-
5 CESS.
6
7 Otherwise it shall have a value of LEAVE_UNCONFIRMED.
8
When the NLME of any device receives one of the leave command frames issued by the leaving device as
9
described above, it must check its relationship to the sender. If the device receiving the leave command
10
frame is the parent of the leaving device then it shall check the value of the remove children sub-field of the
11
command options field in the command frame payload. If this sub-field has a value of 1 then the parent may
12
be able to reuse the 16-bit network address previously in use by the leaving device. If the remove children
13
sub-field has a value of 0 then the parent shall not reuse the 16-bit network address of the leaving device. In
14
either case, it shall set the relationship field of its neighbor table entry corresponding to the leaving device to
15
0x03 indicating no relationship. If the device receiving a leave command frame is a child of the leaving
16
device then it shall check the value of the request/indication sub-field of the command options field in the
17
command frame header. If this sub-field has a value of 1, the NLME shall execute the procedure outlined in
18
this sub-clause. If the request/indication sub-field has a value of 0, the NLME shall issue a
19
NLME.LEAVE.indication primitive to the next higher layer with the DeviceAddress set to the 64-bit
20
address of the sender of the leave command frame.120
21
22
2.7.1.7.2 Method for a parent to force a child to leave its network
23
24 This sub-clause specifies how a parent can force a child to leave its network employing the leave command
25 frame and MAC sub-layer disassociation.
26
27 The procedure for a parent to remove a child from its network is initiated by issuing the NLME-
28 LEAVE.request primitive with the DeviceAddress parameter set to the address of the device to be removed
29 from the network. Only those devices that are either a ZigBee coordinator or a ZigBee router shall initiate
30 this procedure. If this procedure is initiated on any other device, the NLME shall terminate the procedure
31 and notify the next higher layer of the illegal request by issuing the NLME-LEAVE.confirm primitive with
32 the Status parameter set to INVALID_REQUEST.
33
34 When this procedure is initiated by the next higher layer the NLME shall first determine whether the
35 specified device already exists on its network. To do this, the NLME shall search its neighbor table in order
36 to determine whether a matching extended address can be found. If a match is not found, the NLME shall
37 terminate the procedure and inform the next higher layer of the unknown device by issuing the NLME-
38 LEAVE.confirm primitive with the Status parameter set to UNKNOWN_DEVICE. The NLME shall then
39 transmit a leave command frame to the child device, using the MCPS-DATA.request primitive of the MAC
40 sub-layer, with the request/indication sub-field of the command options field of the command frame payload
41 set to 1. If the recursive removal of children is called for, then the remove children sub-field of the outgoing
42 leave command payload will have a value of 1. Otherwise it will have a value of 0. After issuing the leave
43 command frame the NLME shall wait for a time-out period that is equal to:
44
45
46 nwkTransactionPersistenceTime, if removal of children is not called for
47 
48 nwkTransactionPersistenceTime • Cskip(d ), if it is
49
50 to receive a leave command frame from the MAC, via the MCPS-DATA.indication, where the source
51 address of the frame is that of the child being asked to leave the network the request/indication subfield of
52
53
120
54 CCB Comment #107

the command options field of the command frame payload has a value of 0. It may also wait for the receipt 1
of an MLME-DISSSOCIATE.indication from the leaving device. At this point it shall issue the NLME- 2
LEAVE.confirm primitive with the DeviceAddress parameter set to the 64-bit IEEE address of the leaving 3
device. The Status parameter shall have a value of SUCCESS if: 4
5
1) The status value returned by the MLME-DATA.confirm resulting from the transmission of the 6
leave command frame was SUCCESS, and 7
2) The leave command frame issued by the device's was received before the time-out, and 8
3) The recursive removal of children was not called for, or else recursive removal of children was 9
called for and the remove children subfield of the command options field of the command 10
frame payload of the received leave command frame above had a value of 1. 11
12
Otherwise it shall have a value of LEAVE_UNCONFIRMED.
13
Child devices receiving the leave command frame will execute the procedure described in sub- 14
clause 2.7.1.7.1.121 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
46
47
48
49
50
51
52
53
121
CCB Comment #107 54

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51 Figure 55 Sequence diagrams for NLME-LEAVE.request, various scenarios122
52
53
122
54 CCB Comment #107

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
Figure 56 Leave command, various scenarios123
45
46
2.7.1.8 Changing the ZigBee coordinator configuration
47
If the next higher layer of a ZigBee coordinator device wishes to change the configuration of the network, it 48
shall request that the MAC sub-layer instigate the changes in its PIB. The ZigBee coordinator configuration 49
is composed of the following items: 50
51
— Whether the device wishes to be the ZigBee coordinator. 52
53
123
CCB Comment #107 54

1 — The beacon order of the MAC super-frame.

2
— The super-frame order of the MAC super-frame.
3
4 — Whether battery life extension mode is to be used.
5
6 A change to the ZigBee coordinator configuration is initiated by issuing the NLME-NETWORK-
7 FORMATION.request primitive to the NLME. The status of the attempt is communicated back via the
8 NLME-NETWORK-FORMATION.confirm primitive.124
9
The impact of such changes imposed on the MAC sub-layer is out of the scope of this specification. For
10
more details on these changes see [B1].
11
12
2.7.1.9 Resetting a device
13
14 The NWK layer of a device shall be reset immediately following power-up, before a join attempt by
15 association and after a leave attempt by disassociation. A reset is initiated by issuing the NLME-
16 RESET.request primitive to the NLME and the status of the attempt is communicated back via the NLME-
17 RESET.confirm primitive. The reset process shall clear the routing table entries of the device. Some devices
18 may store NWK layer quantities in non-volatile memory and restore them after a reset. However, a device
19 shall discard its network address after the reset. Such a device shall look for an association and get a network
20 address from its coordinator. The new network address may be different from its old network address. In
21 such a case, any device that is communicating with the device that has been reset must rediscover the device
22 using higher-layer protocols and procedures that are out of scope for this specification.
23
24
25 2.7.2 Transmission and reception
26
27 2.7.2.1 Transmission
28
29 Only those devices that are currently associated shall send data frames from the NWK layer. If a device that
30 is not associated receives a request to transmit a frame, it shall discard the frame and notify the higher layer
31 of the error by issuing an NLDE-DATA.confirm primitive with a status of INVALID_REQUEST.
32
All frames handled by or generated within the NWK layer shall be constructed according to the general
33
frame format specified in Figure 36 and transmitted using the MAC sub-layer data service.
34
35 In addition to source address and destination address fields, all NWK layer transmissions shall include a
36 radius field and a sequence number field. For data frames originating at a higher layer, the value of the
37 radius field may be supplied using the Radius parameter of the NLDE-DATA.request primitive. If a value is
38 not supplied, then the radius field of the NWK header shall be set to twice the value of the nwkMaxDepth
39 attribute of the NWK IB (see clause 2.6). The NWK layer on every device shall maintain a sequence number
40 that is initialized with a random value. The sequence number shall be incremented by one, each time the
41 NWK layer constructs a new NWK frame, either as a result of a request from the next higher layer to
42 transmit a new NWK data frame or when it needs to construct a new NWK layer command frame. After
43 being incremented the value of the sequence number shall be inserted into the sequence number field of the
44 frame's NWK header125. Once an NPDU is complete, if security is required for the frame, it shall be passed
45 to the security service provider for subsequent processing according to the specified security suite (see sub-
46 clause 3.2.3). Security processing is not required if the SecurityEnable parameter of the NDLE-
47 DATA.request is EQUAL to FALSE or if the NWK security level as specified in nwkSecurityLevel is equal
48 to 0. In this case the security sub-field of the frame control field shall always be set to 0. On successful
49 completion of the secure processing, the security suite returns the frame to the NWK layer for transmission.
50 The processed frame will have the correct auxiliary header attached. If security processing of the frame fails
51
52
125

and the frame was a data frame then the higher layer will be informed via the NDLE-DATA.confirm 1
primitive’s status. If security processing of the frame fails and the frame is a network command frame then it 2
is discarded and no further processing shall take place 3
4
When the frame is constructed and ready for transmission, it shall be passed to the MAC data service. An 5
NPDU transmission is initiated by issuing the MCPS-DATA.request primitive to the MAC sub-layer and the 6
results of the transmission returned via the MCPS-DATA.confirm primitive. 7
8
2.7.2.2 Reception and rejection 9
10
In order to receive data, a device must enable its receiver. The next higher layer may initiate reception using
11
the NLME-SYNC.request primitive. On a beacon-enabled network, receipt of this primitive by the NWK
12
layer will cause a device to synchronize with its parent’s next beacon and, optionally, to track future
13
beacons. The NWK layer shall accomplish this by issuing an MLME-SYNC.request to the MAC sub-layer.
14
On a non-beacon-enabled network the NLME-SYNC.request will cause the NWK layer to poll the device’s
15
parent using the MLME-POLL.request primitive.
16
On a non-beacon-enabled network, the NWK layer on a ZigBee coordinator or ZigBee router shall ensure, to 17
the maximum extent feasible, that the receiver is enabled whenever the device is not transmitting. On a 18
beacon-enabled network, the NWK layer should ensure that the receiver is enabled when the device is not 19
transmitting during the active period of its own superframe and of its parent’s superframe. The NWK layer 20
may use the macRxOnWhenIdle attribute of the MAC PIB for this purpose. 21
22
Once the receiver is enabled, the NWK layer will begin to receive frames via the MAC data service. On 23
receipt of each frame, the Radius field of the NWK header shall be decremented by 1. If, as a result of being 24
decremented, this value falls to 0 then the frame shall not, under any circumstances, be retransmitted, 25
although it may be passed to the next higher layer or otherwise processed by the NWK layer as outlined 26
elsewhere in this specification.126 Data frames for which the destination address matches the device’s 27
network address shall be passed to the next higher layer. Broadcast data frames shall also be passed to the 28
next higher layer. Broadcast data frames shall also be relayed according to the procedure outlined in sub- 29
clause 2.7.5. If the receiving device is a ZigBee coordinator or an operating ZigBee router, i.e. a router that 30
has already invoked the NLME-START-ROUTER.request primitive, then it may relay data frames for 31
which the destination address does not match the device's network address according to the procedures 32
outlined in sub-clause 2.7.3.3. Under all other circumstances, data frames shall be discarded immediately. 33
The procedure for handling route request frames is outlined in sub-clause 2.7.3.4.2. The procedure for 34
handling route reply command frames for which the destination address matches the device's network 35
address is outlined in sub-clause 2.7.3.4.3. Route reply command frames for which the destination address 36
does not match the device's network address shall be discarded immediately. Route error command frames 37
shall be handled in the same manner as data frames.127 38
39
The NWK layer shall indicate the receipt of a data frame to the next higher layer using the NLDE- 40
DATA.indication primitive. 41
42
On receipt of a frame, the NLDE shall check the value of the security sub-field of the frame control field. If
43
this value is non-zero, the NLDE shall pass the frame to the security service provider (see sub-clause 3.2.3)
44
for subsequent processing according to the specified security suite.
45
46
2.7.3 Routing 47
48
ZigBee coordinators and routers shall provide the following functionality: 49
50
— Relay DATA frames on behalf of higher layers.
51
52
127
CCB Comment #134 54

1 — Relay DATA frames on behalf of other ZigBee routers.

2
— Participate in route discovery in order to establish routes for subsequent DATA frames.
3
4 — Participate in route discovery on behalf of end devices.
5
— Participate in end-to-end route repair.
6
7 — Participate in local route repair.
8
— Employ the ZigBee path cost metric as specified in route discovery and route repair.
9
10 ZigBee coordinators or routers may provide the following functionality:
11
12 — Maintain routing tables in order to remember best available routes.
13
— Initiate route discovery on behalf of higher layers.
14
15 — Initiate route discovery on behalf of other ZigBee routers.
16
— Initiate end-to-end route repair.
17
18 — Initiate local route repair on behalf of other ZigBee routers.
19
20 2.7.3.1 Routing cost
21
22 The ZigBee routing algorithm uses a path cost metric for route comparison during route discovery and
23 maintenance. In order to compute this metric, a cost, known as the link cost, is associated with each link in
24 the path and link cost values are summed to produce the cost for the path as a whole.
25
More formally, if we define a path P of length L as an ordered set of devices [D1,D2 ...DL ] and a link,
26
27 [Di ,Di+1] , as a sub-path of length 2, then the path cost
28
29 L−1
30 C{P} = ∑ C{[Di ,Di+1 ]}

i=1
31
32
33
where each of the values C{[Di ,Di+1 ]} is referred to as a link cost. The link cost C{l} for a link l is a
34
35
36 function with values in the interval [0...7] defined as:128
37
38
39 7,
40 
C{l} =    1 
41  
min 7, round p 4  
42
   l  
43
44
45 where pl is defined as the probability of packet delivery on the link l .
46
47
48
49
128
50 CCB Comment #133 mandates a change in value for this formula. The previous value was:
51  7,
52 
C{l} =    1 
53 min 7, p 
   l 
54

Thus, implementers may report a constant value of 7 for link cost or they may report a value that reflects the 1
probability pl of reception - specifically, the reciprocal of that probability – which should, in turn, reflect129 2
the number of expected attempts required to get a packet through on that link each time it is used. A device 3
that offers both options may be forced to report a constant link cost by setting the value of the NIB attribute 4
nwkReportConstantCost to TRUE. 5
6
The question that remains, however, is how pl is to be estimated or measured. This is primarily an 7
implementation issue and implementers are free to apply their ingenuity. pl may be estimated over time by 8
actually counting received beacon and data frames, observing the appropriate sequence numbers to detect 9
lost frames, and this is generally regarded as the most accurate measure of reception probability. However, 10
the most straightforward method, available to all, is to form estimates based on an average over the per- 11
frame LQI value provided by the IEEE 802.15.4-2003 MAC and PHY. Even if some other method is used, 12
the initial cost estimates shall be based on average LQI. A table-driven function may be used to map average 13
LQI values onto C{l} values. It is strongly recommended that implementers check their tables against data 14
derived from tests on production hardware, as inaccurate costs will hamper the ability of the ZigBee routing 15
algorithm to operate130 16
17
2.7.3.2 Routing tables 18
19
A ZigBee router or ZigBee coordinator may maintain a routing table. The information that shall be stored in
20
a ZigBee routing table is shown in Table 135. A ZigBee router or ZigBee coordinator may also reserve a
21
number of routing table entries to be used only for route repair and only in case all other routing capacity has
22
been exhausted. The aging and retirement of routing table entries in order to reclaim table space from entries
23
that are no longer in use, while it is a recommended practice, is out of scope of this specification.131.
24
Table 135 Routing table 25
26
Field Name Size Description
27
Destination address 2 bytes The 16-bit network address of this route. 28
29
Status 3 bits The status of the route. See Table 136 below for values.
30
The 16-bit network address of the next hop on the way to 31
Next-hop address 2 bytes
the destination. 32
33
34
Table 136 enumerates the values for the route status field. 35
Table 136 Route status values 36
37
Numeric Value Status 38
0x0 ACTIVE 39
40
0x1 DISCOVERY_UNDERWAY 41
0x2 DISCOVERY_FAILED 42
43
0x3 INACTIVE 44
45
0x4 – 0x7 Reserved
46
47
48
49
50
51
129
CCB Comment #133 52
131
CCB Comment #255 54

1 In the text below that describes the routing algorithm the term “routing table capacity” is used to describe the
2 situation in which a device has the ability to use its routing table to establish a route to a particular
3 destination device. A device is said to have routing table capacity if:
4
5 — It is a ZigBee coordinator or ZigBee router.
6 — It maintains a routing table.
7
8 — It has a free routing table entry or it already has a routing table entry corresponding to the destination.
9 — The device is attempting route repair and it has reserved some entries for this purpose as described
10 above.
11
12 If a ZigBee router or ZigBee coordinator maintains a routing table it shall also maintain a route discovery
13 table containing the information shown in Table 137. Routing table entries are long-lived and persistent,
14 while route discovery table entries last only as long as the duration of a single route discovery operation and
15 may be reused.
16
17 Table 137 Route discovery table
18 Field Name Size Description
19
A sequence number for a route request command frame that is
20 Route request ID 1 byte
incremented each time a device initiates a route request.
21
22 Source address 2 bytes The 16-bit network address of the route request’s initiator.
23
The 16-bit network address of the device that has sent the most
24 recent lowest cost route request command frame corresponding
25 Sender address 2 bytes to this entry’s Route request identifier and Source address. This
26 field is used to determine the path that an eventual route reply
27 command frame should follow.
28 The accumulated path cost from source of the route request to
29 Forward Cost 1 byte
the current device.
30
31 The accumulated path cost from the current device to the desti-
Residual cost 1 byte
nation device.
32
33 A countdown timer indicating the number of milliseconds until
34 Expiration time 2 bytes route discovery expires. The initial value is nwkcRouteDiscovery-
35 Time.
36
37
38 A device is said to have “route discovery table capacity” if:
39
— It maintains a route discovery table.
40
41 — It has a free entry in its route discovery table.
42
43 If a device has both routing table capacity and route discovery table capacity then it may be said the have
44 “routing capacity”.
45
46 2.7.3.3 Upon receipt of a data frame
47
On receipt of a data frame the NWK layer routes it according to the following procedure, which is also
48
outlined in Figure 57.
49
50 If a data frame is received by the NWK layer from its next higher layer and the destination address is equal
51 to the broadcast address, the NWK layer shall broadcast the frame according to the procedures described in
52 sub-clause 2.7.5.
53
54

If the receiving device is a ZigBee router or ZigBee coordinator and the destination of the frame is a ZigBee 1
end device which is also the child of the receiving device then the frame shall be routed directly to the 2
destination using the MCPS132-DATA.request primitive as described in sub-clause 2.7.2.1 and setting the 3
next hop destination address equal to the final destination address. 4
5
A device that has routing capacity shall examine the discover route sub-field of the NWK header frame 6
control field, If the discover route sub-field has a value of 0x02 then the device shall initiate route discovery 7
immediately as described below in sub-clause 2.7.3.4.1. If the discover route sub-field does not have a value 8
of 0x02, the device shall check its routing table for an entry corresponding to the destination of the frame. If 9
there is such an entry, and if the value of the route status field for that entry is ACTIVE, then the device shall 10
relay the frame using the MCPS-DATA.request primitive. When relaying a data frame, the SrcAddrMode 11
and DstAddrMode parameters of the MCPS-DATA.request primitive shall both have a value of 0x02, 12
indicating 16-bit addressing. The SrcPANId and DstPANId parameters shall both have the value provided 13
by the macPANId attribute of the MAC PIB for the relaying device. The SrcAddr parameter will be set to 14
the value of macShortAddress from the MAC PIB of the relaying device, and the DstAddr parameter shall 15
be the value provided by the next-hop address field of the routing table entry corresponding to the 16
destination. The TxOptions parameter should always be non-zero when bitwise ANDed with the value 0x01, 17
indicating acknowledged transmission. If the device has a routing table entry corresponding to the 18
destination of the frame but the value of the route status field for that entry is DISCOVERY_UNDERWAY, 19
then the frame shall be treated as though route discovery has been initiated for this frame, as described 20
below in sub-clause 2.7.3.4.1. The frame may optionally be buffered pending route discovery or else routed 21
along the tree using hierarchical routing, provided that the NIB attribute nwkUseTreeRouting has a value of 22
TRUE. If the frame is routed along the tree, the discover route sub-field of the NWK header frame control 23
field shall be set to 0x00. If the device has a routing table entry corresponding to the destination of the frame 24
but value of the route status field for that entry has a value of DISCOVERY_FAILED or INACTIVE, the 25
device may route the frame along the tree using hierarchical routing, again provided that the NIB attribute 26
nwkUseTreeRouting has a value of TRUE. If the device does not have a routing table entry for the 27
destination, it shall examine the discover route sub-field of the NWK header frame control field. If the 28
discover route sub-field has a value of 0x01 then the device shall initiate route discovery as described below 29
in sub-clause 2.7.3.4.1. If the discover route sub-field has a value of 0 and the NIB attribute 30
nwkUseTreeRouting has a value of TRUE then the device shall route along the tree using hierarchical 31
routing. If the discover route sub-field has a value of 0, the NIB attribute nwkUseTreeRouting has a value of 32
FALSE and there is no routing table corresponding to the destination of the frame, the frame shall be 33
discarded and the NLDE shall issue the NLDE-DATA.confirm primitive with a Status value of 34
INVALID_REQUEST.133 35
36
A device without routing capacity shall route along the tree using hierarchical routing, again provided that
37
the value of the NIB attribute nwkUseTreeRouting is TRUE.134
38
For hierarchical routing, if the destination is a descendant of the device, the device shall route the frame to 39
the appropriate child. If the destination is a child, and it is also and end device, delivery of the frame can fail 40
due to the macRxOnWhenIdle state of the child device. In the case when the child has macRxOnWhenIdle set 41
to FALSE, indirect transmission as described in [B1] may be used be used to deliver the frame. If the 42
destination is not a descendant, the device shall route the frame to its parent. 43
44
Trivially every other device in the network is a descendant of the ZigBee coordinator and no device in the 45
network is the descendant of any ZigBee end device. For a ZigBee router with address An at depth d , if 46
the following logical expression is true, then a destination device with address D is a descendant: 47
48
49
50
51
132
CCB Comment #119 52
133CCB Comment #129, 258, 122 53
134
CCB Comment #129 54

1
2 A < D < A + Cskip(d −1) .
3
4 For a definition of Cskip(d) , see sub-clause 2.7.1.4.
5
6 If it is determined that the destination is a descendant of the receiving device, the address N of the next
7 hop device is given by:
8
9
10 N=D
11
12
13 for ZigBee end devices, where D > A + Rm × Cskip(d) , and135
14
15
16
17  D − ( A + 1) 
18 N = A +1+   × Cskip (d )
19  Cskip (d ) 
20
21 otherwise.
22
23 If a data frame is received by the NWK layer from the MAC sub-layer and the destination address is equal to
24 the broadcast address, the NWK layer shall first re-broadcast the frame and then send it to its next higher
25 layer for processing. If the data frame is received by the MAC and is not to be broadcast, the NWK layer
26 shall determine whether the destination address is equal to its own logical address. If so, the NWK layer
27 shall send the frame to its next higher layer for processing. Otherwise the device is an intermediate device.
28 In this case, the device shall follow the same procedure outlined above for the case of receiving a unicast
29 frame from the next higher layer.
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
135
49 CCB Comment #228 specifies a modified formula here. The original was:
50
51  D − A + 1
A + 1+   × Cskip(d)
52  Cskip(d) 
53
54

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
Figure 57 Basic routing algorithm 43
44
2.7.3.4 Route discovery 45
46
Route discovery is the procedure whereby network devices cooperate to find and establish routes through
47
the NWK and is always performed with regard to a particular source and destination device.
48
49
2.7.3.4.1 Initiation of route discovery
50
The route discovery procedure shall be initiated by the NWK layer on receipt of an NLDE-DATA.request 51
primitive from a higher layer with the DiscoverRoute parameter set to 0x02, or on receipt of an NLDE- 52
DATA.request primitive from a higher layer with the DiscoverRoute parameter set to 0x01for which there is 53
54

1 no routing table entry corresponding to the DstAddr parameter, or on receipt of a frame from the MAC sub-
2 layer for which the value of the destination address field in the NWK header is not that of the current device
3 or the broadcast address and in which either the discover route sub-field of the frame control field has a
4 value of 0x02 or the discover route sub-field of the frame control field has a value of 0x01 and there is no
5 routing table entry corresponding to the value of the destination address field of the NWK header. In either
6 case, if the device does not have routing capacity and the NIB attribute nwkUseTreeRouting has a value of
7 TRUE, the data frame in question shall be routed along the tree using hierarchical routing. If the device does
8 not have routing capacity and the NIB attribute nwkUseTreeRouting has a value of FALSE, then the frame
9 shall be discarded.136
10
11 If the device has no existing routing table entry for the destination it shall establish a routing table entry with
12 status equal to DISCOVERY_UNDERWAY. If the device has an existing routing table entry corresponding
13 to the destination address with status equal to ACTIVE, then that entry shall be used and the status field of
14 that entry shall remain ACTIVE. If it has an existing routing table entry with some other status value than
15 ACTIVE then that entry shall be used and the status of that entry shall be set to
16 DISCOVERY_UNDERWAY. The device shall also establish the corresponding route discovery table entry
17 if one does not already exist.137
18
Each device issuing a route request command frame shall maintain a counter used to generate route request
19
identifiers. When a new route request command frame is created the route request counter is incremented
20
and the value is stored in the device’s route discovery table in the Route request identifier field. Other fields
21
in the routing table and route discovery table are set as described in sub-clause 2.7.3.2. The route request
22
timer in the route discovery table shall be set to expire in nwkcRouteDiscoveryTime milliseconds when the
23
timer expires, the device shall delete the route request entry from the route discovery table. When this
24
happens, the routing table entry corresponding to the destination address shall also be deleted if its Status
25
field still has a value of DISCOVERY_UNDERWAY and there are no other entries with the same
26
destination field value in the route discovery table138.
27
28 The NWK layer may choose to buffer the received frame pending route discovery or else, if the NIB
29 attribute nwkUseTreeRouting has a value of TRUE, set139 the discover route sub-field of the frame control
30 field in the NWK header to 0 and forward the data frame along the tree.
31
32 Once the device creates the route discovery table and routing table entries, the route request command frame
33 shall be created with the payload depicted in Figure 41. The individual fields are populated as follows. The
34 command frame identifier field shall be set to indicate the command frame is a route request, see Figure 129.
35 The Route request identifier field shall be set to the value stored in the route discovery table entry. The
36 destination address field shall be set to the 16-bit network address of the device for which the route is to be
37 discovered. The path cost field shall be set to 0. Once created the route request command frame is ready for
38 broadcast and is passed to the MAC sub-layer using the MCPS-DATA.request primitive.
39
40 When broadcasting a route request command frame at the initiation of route discovery, the NWK layer shall
41 retry the broadcast nwkcInitialRREQRetries times after the initial broadcast, resulting in a maximum of
42 nwkcInitialRREQRetries + 1 transmission. The retries will be separated by a time interval of
43 nwkcRREQRetryInterval milliseconds.
44
45 2.7.3.4.2 Upon receipt of a route request command frame
46
Upon receipt of a route request command frame the device shall determine if it has routing capacity.
47
48 If the device does not have routing capacity, it shall check if the frame was received along a valid path. A
49 path is valid if the frame was received from one of the device’s child devices and the source device is a
50
51 136
CCB Comment #122, 256
52 137
CCB Comment #136, #260
139
54 CCB Comment #122

descendant of that child device or if the frame was received from the device’s parent device and the source 1
device is not a descendant of the device. If the route request command frame was not received along a valid 2
path, it shall be discarded. Otherwise the device shall check if it is the intended destination. It shall also 3
check if the destination of the command frame is one of its end-device children by comparing the destination 4
address field of the route request command frame payload with the address of each of its end-device 5
children, if any. If either the device or one of its end-device children is the destination of the route request 6
command frame, it shall reply with a route reply command frame. When replying to a route request with a 7
route reply command frame, the device shall construct a frame with the frame type field set to 0x01. The 8
route reply’s source address shall be set to the 16-bit network address of the device creating the route reply 9
and the destination address shall be set to the calculated next hop address, considering the originator of the 10
route request as a destination. The link cost from the next hop device to the current device shall be computed 11
as described in sub-clause 2.7.3.1 and inserted into the path cost field of the route reply command frame. 12
The route reply command frame shall be unicast to the next hop device by issuing an MCPS-DATA.request 13
primitive. If the device is not the destination of the route request command frame, the device shall compute 14
the link cost from the previous device that transmitted the frame, as described in sub-clause 2.7.3.1. This 15
value shall be added to the path cost value stored in the route request command frame. The route request 16
command frame shall then be unicast towards the destination using the MCPS-DATA.request service 17
primitive. The next hop for this unicast transmission is determined in the same manner as if the frame were a 18
data frame addressed to the device identified by the destination address field in the payload. 19
20
If the device does have routing capacity (see Figure 58), it shall check if it is the destination of the command 21
frame by comparing the destination address field of the route request command frame payload with its own 22
address. It shall also check if the destination of the command frame is one of its end-device children by 23
comparing the destination address field of the route request command frame payload with the address of 24
each of its end-device children, if any. If either the device or one of its end-device children is the destination 25
of the route request command frame, the device shall determine if a route discovery table (see Table 137) 26
entry exists with the same route request identifier and source address field. If no such entry exits then one 27
shall be created. When creating the route discovery table entry, the fields are set to the corresponding values 28
in the route request command frame. The only exception is the forward cost field, which is determined by 29
using the previous sender of the command frame to compute the link cost as described in sub-clause 2.7.3.1 30
and adding it to the path cost contained the route request command frame. The result of the above 31
calculation is stored in the forward cost field of the newly created route discovery table entry. If the 32
nwkSymLink attribute is set to true, the device shall also create a routing table entry with the destination 33
address field set to the source address of the route request command frame and the next hop field set to the 34
address of the previous device that transmitted the command frame. The status field shall be set to ACTIVE. 35
The device shall then issue a route reply command frame to the source of the route request command frame. 36
In the case where the device already has a route discovery table entry for the source address and route 37
request identifier pair, the device shall determine if the path cost in the route request command frame is less 38
than the forward cost stored in the route discovery table entry. The comparison is made by first computing 39
the link cost from the previous device that sent this frame as described in sub-clause 2.7.3.1 and adding it to 40
the path cost value in the route request command frame. If this value is greater than the value in the route 41
discovery table entry then the frame shall be dropped and no further processing is required. Otherwise the 42
forward cost and sender address fields in the route discovery table are updated with the new cost and the 43
previous device address from the route request command frame. If the nwkSymLink attribute is set to true, 44
the device shall also create a routing table entry with the destination address field set to the source address of 45
the route request command frame and the next hop field set to the address of the previous device that 46
transmitted the command frame. The status field shall be set to ACTIVE. The device shall then respond with 47
a route reply command frame. In either of the above cases, if the device is responding on behalf of one of its 48
end-device children, the responder address in the route reply command frame payload shall be set equal to 49
the address of the end device child and not of the responding device. 50
51
When a device with routing capacity is not the destination of the received route request command frame, it
52
shall determine if a route discovery table entry (see Table 137) exists with the same route request identifier
53
and source address field. If no such entry exits then one shall be created. The route request timer shall be set
54

1 to expire in nwkcRouteDiscoveryTime milliseconds. If a routing table entry corresponding to the destination

2 exists and its status is not ACTIVE, the status shall be set to DISCOVERY_UNDERWAY.140 If no such
3 entry exists, it shall be created and its status set to DISCOVERY_UNDERWAY. If the nwkSymLink
4 attribute is set to true, the device shall also create a routing table entry with the destination address field set
5 to the source address of the route request command frame and the next hop field set to the address of the
6 previous device that transmitted the command frame. The status field shall be set to ACTIVE. When the
7 route request timer expires, the device deletes the route request entry from the route discovery table. When
8 this happens, the routing table entry corresponding to the destination address shall also be deleted if its status
9 field has a value of DISCOVERY_UNDERWAY and there are no other entries in the route discovery table
10 created as a result of a route discovery for that destination address.141 If an entry in the route discovery table
11 already exists then the path cost in the route request command frame shall be compared to the forward cost
12 value in the route discovery table entry. The comparison is made by computing the link cost from the
13 previous device, as described in sub-clause 2.7.3.1, and adding it to the path cost value in the route request
14 command frame. If this path cost is greater, the route request command frame is dropped and no further
15 processing is required. Otherwise the forward cost and sender address fields in the route discovery table are
16 updated with the new cost and the previous device address from the route request command frame.
17 Additionally, the path cost field in the route request command frame shall be updated with the cost
18 computed for comparison purposes. If the nwkSymLink attribute is set to true, the device shall also update
19 any routing table entry with the destination address field set to the source address of the route request
20 command frame and the next hop field set to the address of the previous device that transmitted the
21 command frame. The status field shall be set to ACTIVE. The device shall then rebroadcast the route request
22 command frame using the MCPS-DATA.request primitive.
23
24 When rebroadcasting a route request command frame, the NWK layer shall delay retransmission by a
25 random jitter amount calculated using the formula:
26
27 2 × R[nwkcMinRREQJitter,nwkcMaxRREQJitter]
28
29
where R[a,b] is a random function on the interval [a,b] . The units of this jitter amount are
30
milliseconds. Implementers may adjust the jitter amount so that route request command frames arriving with
31
large path cost are delayed more than frames arriving with lower path cost. The NWK layer shall retry the
32
broadcast nwkcRREQRetries times after the original relay resulting in a maximum of nwkcRREQRetries + 1
33
relays per relay attempt. Implementers may choose to discard route request command frames awaiting
34
retransmission in the case that a frame with the same source and route request identifier arrives with a lower
35
path cost than the one awaiting retransmission.
36
37 The device shall also set the status field of the routing table entry corresponding to the destination address
38 field in the payload to DISCOVERY_UNDERWAY. If no such entry exists, it shall be created.
39
40 When replying to a route request with a route reply command frame, a device that has a route discovery
41 table entry corresponding to the source address and route request identifier of the route request shall
42 construct a command frame with the frame type field set to 0x01. The source address field of the network
43 header shall be set to the 16-bit network address of the current device and the destination address field shall
44 be set to the the value of the sender address field from the corresponding route discovery table entry. The
45 device constructing the route reply shall populate the payload fields in the following manner. The NWK
46 command identifier shall be set to route reply. The route request identifier field shall be set to the same value
47 found in the route request identifier field of the route request command frame. The originator address field
48 shall be set to the source address in the network header of route request command frame. Using the sender
49 address field from the route discovery table entry corresponding to the source address in the network header
50 of route request command frame, the device shall compute the link cost as described in sub-clause 2.7.3.1.
51 This link cost shall be entered in the path cost field. The route reply command frame is then unicast to the
52
141
54 Ibid

destination by using MCPS-DATA.request primitive and the sender address obtained from the route 1
discovery table as the next hop. 2
3
4
5
6
7
Create table entries
Am I the 8
destination? No
No 9
10
Existing route
Yes 11
RREQ received Routing capacity? Yes discovery table 12
entry?
Respond with RREP

13
No Yes
14
15
16
Am I the
destination or is 17
Discard RREQ No Valid path? Forward RREQ
one of my end- Yes 18
devices?
19
Yes 20
RREQ has lower 21
No path cost than Yes 22
tables?
Am I the 23
Unicast RREQ No
destination?
Update tables and
24
respond with RREP 25
RREQ has lower
path cost than Yes 26
tables? No 27
28
No 29
Reply with RREP Yes Update tables and
forward RREQ 30
31
Discard RREQ 32
33
34
35
Figure 58 Receipt of route request
36
37
2.7.3.4.3 Upon receipt of route reply command frame
38
On receipt of a route reply command frame, a device performs the procedure outlined in Figure 59. 39
40
If the receiving device has no routing capacity and its NIB attribute nwkUseTreeRouting has a value of 41
TRUE, it shall forward the route reply using tree routing. If the receiving device has no routing capacity and 42
its NIB attribute nwkUseTreeRouting has a value of FALSE, it shall discard the command frame.142 Before 43
forwarding the route reply command frame the device shall update the path cost field in the payload by 44
computing the link cost from the next hop device to itself as described in sub-clause 2.7.3.1 and adding this 45
to the value in the route reply path cost field. 46
47
If the receiving device has routing capacity, it shall check whether it is the destination of the route reply 48
command frame by comparing the contents of the originator address field of the command frame payload 49
with its own address. If so, it shall search its route discovery table for an entry corresponding to the route 50
request identifier in the route reply command frame payload. If there is no such entry, the route reply 51
command frame shall be discarded and route reply processing shall be terminated. If a route discovery table 52
53
142
CCB Comment #122 54

1 entry exists, the device shall search its routing table for an entry corresponding to the responder address in
2 the route reply command frame. If there is no such routing table entry the route reply command frame shall
3 be discarded and, if a route discovery table entry corresponding to the route request identifier in the route
4 reply command frame exists, it shall also be removed, and route reply processing shall be terminated. If a
5 routing table entry and a route discovery table entry exist and if the status field of the routing table entry is
6 set to DISCOVERY_UNDERWAY, it shall be changed to active and the next hop field in the routing table
7 shall be set to the previous device that forwarded the route reply command frame. The residual cost field in
8 the route discovery table entry shall be set to the path cost field in the route reply payload.
9
10 If the status field was already set to ACTIVE, the device shall compare the path cost in the route reply
11 command frame to the residual cost recorded in the route discovery table entry, and update the residual cost
12 field and next hop field in the routing table entry if the cost in the route reply command frame is smaller. If
13 the path cost in the route reply is not smaller, the route reply shall be discarded and no further processing
14 shall take place.
15
If the device receiving the route reply is not the destination, the device shall find the route discovery table
16
entry corresponding to the originator address and route request identifier in the route reply command frame
17
payload. If no such route discovery table entry exists, the route reply command frame shall be discarded. If a
18
route discovery table entry exists, the path cost value in the route reply command frame and the residual cost
19
field in the route discovery table entry shall be compared. If the route discovery table entry value is less than
20
the route reply value, the route reply command frame shall be discarded. Otherwise, the device shall find the
21
routing table entry corresponding to the responder address in the route reply command frame. It is an error
22
here if the route discovery table entry exists and there is no corresponding routing table entry, and the route
23
reply command frame should be discarded. The routing table entry shall be updated by replacing the next
24
hop field with the address of the previous device that forwarded the route reply command frame. The route
25
discovery table entry shall also be updated by replacing the residual cost field with the value in the route
26
reply command frame.
27
28 After updating its own route entry, the device shall forward the route reply to the destination. Before
29 forwarding the route reply, the path cost value shall be updated. The sender shall find the next hop to the
30 route reply’s destination by searching its route discovery table for the entry matching the route request
31 identifier and the source address and extracting the sender address. It shall use this next hop address to
32 compute the link cost as described in sub-clause 2.7.3.1. This cost shall be added to the path cost field in the
33 route reply. The destination address in the command frame network header shall be set to the next hop
34 address and the frame shall be unicast to the next hop device using the MCPS-DATA.request primitive.The
35 DstAddr parameter of the MCPS-DATA.request primitive shall be set to the next-hop address from the route
36 discovery table.143
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
143
54 CCB Comment #131

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Figure 59 Receipt of route reply
31
32
2.7.3.5 Route maintenance
33
A device NWK layer shall maintain a failure counter for each neighbor to which it has an outgoing link, i.e. 34
to which it has been required to send data frames. If the value of the outgoing link failure counter ever 35
exceeds nwkcRepairThreshold then the device shall initiate route repair as described in the following 36
paragraphs. Implementers may choose a simple failure-counting scheme to generate this failure counter 37
value or they may use a more accurate time-windowed scheme. Note that it is important not to initiate repair 38
too frequently since repair operations may flood the network and cause other traffic disruptions. The 39
procedure for retiring links and ceasing to keep track of their failure counter is out of the scope of this 40
specification. 41
42
2.7.3.5.1 Route repair for mesh network topology 43
44
When a link or a device fails in mesh network topology, the upstream device shall initiate route repair. If the 45
upstream device is unable to initiate route repair due to a lack of routing capacity or some other limitation, 46
the device shall issue a route error command frame back to the source device with the error code indicating 47
the reason for the failure (see Table 130). 48
49
If the upstream device is able to initiate route repair, it shall do so by broadcasting a route request command 50
frame with the source address set to its own address and the destination address set to the destination address 51
of the frame that failed in transmission. The route request command frame shall have the route repair sub- 52
field in the command options field of the command frame payload set to 1 indicating route repair. 53
54

1 While a device is performing route repair for a particular destination, a device shall not forward frames to
2 that destination. Any frames that it has pending for that destination at the time route repair is initiated and
3 any frames for that destination that arrive before the completion of route repair shall either be buffered until
4 the completion of route repair or discarded depending on the capabilities of the device.144
5
6 On receipt of a route request command frame a routing node shall perform the procedure outlined in sub-
7 clause 2.7.3.4.2. If the routing node is the destination of the route request command frame or the destination
8 is one of its end-device children, it shall reply with a route reply command frame. The route reply command
9 frame shall have the route repair sub-field in the command options field of the command frame payload set
10 to 1 indicating route repair.
11
If a route reply command frame does not arrive at the upstream device within nwkcRouteDiscoveryTime
12
milliseconds, the upstream device shall send a route error command frame to the source device. If the
13
upstream device does receive a route reply within the designated time, it will forward any data that it may
14
have buffered pending the repair to the destination.
15
16 If the source device receiving a route error command frame does not have routing capacity and its NIB
17 attribute nwkUseTreeRouting has a value of TRUE145, it shall construct a route request command frame as
18 described in sub-clause 2.7.3.4.1 and unicast the command frame towards its destination along the tree using
19 hierarchical routing. If the source device does have routing capacity, it shall initiate normal route discovery
20 as described in sub-clause 2.7.3.4.1.
21
22 If an end device that is also an RFD is unable to transmit messages to its parent, the end device shall initiate
23 the orphaning procedure, as described in [B1]. If the orphaning procedure is successful and the end device
24 re-establishes communications with its parent, the end device shall resume operation on the network as
25 before. If the orphaning procedure fails, the end device shall attempt to re-join the network through a new
26 parent. In this case the new parent shall issue the end device a new 16-bit network address. If the end device
27 is unable to locate a new parent because there is no other device in its neighborhood with the capacity to
28 accept an additional child device, the end device will not be able to re-join the network. In this case, user
29 intervention may be necessary to enable the end device to re-join.
30
31 2.7.3.5.2 Route repair for tree network topology
32
33 When a downstream device loses synchronization with its parent beacon, indicated by the MAC sub-layer
34 through the MLME-SYNC-LOSS.indication primitive, or is unable to transmit a message to its parent, the
35 device may either initiate the orphaning procedure to search for its parent or the association procedure to
36 find a new parent.[B1] If either the orphaning procedure fails or the device associates with a new upstream
37 device, the downstream device will receive a new 16-bit network address from its new parent and resume
38 operation on the network. This allows the network to continue operating in a true tree configuration.
39
Before a device attempts to re-join the network and receive a new 16-bit network address, the device shall
40
use the MAC sub-layer disassociation procedure to disassociate all of its children. If the device is unable to
41
reach one or more of its children, it shall consider the child(ren) disassociated from the network and remove
42
the 16-bit addresses of the children from its neighbor table. The device shall then re-join the network and
43
begin operation with its new address.
44
45 Similarly if a disassociated child has its own children, it shall disassociate them from the network before
46 attempting re-association. If the child is able to re-associate either through a new parent or through its
47 original parent, the child shall receive a new 16-bit network address and begin operation on the network
48 using the new address.
49
50
51
52
145
54 CCB Comment #122

Optionally, if the implementer chooses not to seek a new 16-bit network address, the network will be 1
partitioned by a link failure. The remaining portions of the partitioned network would then operate 2
separately. 3
4
If an upstream device is unable to transmit a message to one of its children it may drop the message and send 5
a route error command frame to the originating device to indicate that the message has not been delivered. 6
7
2.7.4 Scheduling beacon transmissions 8
9
Beacon scheduling is necessary in a multihop topology to prevent the beacon frames of one device from 10
colliding with either the beacon frames or data transmissions of its neighboring devices. Beacon scheduling 11
is necessary when implementing a tree topology but not a mesh topology, as beaconing is not permitted in 12
ZigBee mesh networks. 13
14
2.7.4.1 Scheduling method 15
16
The ZigBee coordinator shall determine the beacon order and superframe order for every device in the 17
network (see [B1] for more information on these attributes). Because one purpose of multihop beaconing 18
networks is to allow routing nodes the opportunity to sleep in order to conserve power, the beacon order 19
shall be set much larger than the superframe order. Setting the attributes in this manner makes it possible to 20
schedule the active portion of the superframes of every device in any neighborhood such that they are non- 21
overlapping in time. In other words, time is divided into approximately (macBeaconInterval/ 22
macSuperframeDuration) non-overlapping time slots, and the active portion of the superframe of every 23
device in the network shall occupy one of these non-overlapping time slots. An example of the resulting 24
frame structure for a single beaconing device is shown in Figure 60. 25
26
27
28
29
Beacon Interval Beacon CAP 30
31
32
33
Inactive Period 34
Superframe Duration 35
36
Figure 60 Typical frame structure for a beaconing device 37
38
The beacon frame of a device shall be transmitted at the start of its non-overlapping time slot, and the 39
transmit time shall be measured relative to the beacon transmit time of the parent device. This time offset 40
shall be included in the beacon payload of every device in a multihop beaconing network (see sub- 41
clause 2.7.6 for a complete list of beacon payload parameters). Therefore a device receiving a beacon frame 42
shall know the beacon transmission time of both the neighboring device and the parent of the neighboring 43
device, since the transmission time of the parent may be calculated by subtracting the time offset from the 44
timestamp of the beacon frame. The receiving device shall store both the local timestamp of the beacon 45
frame and the offset included in the beacon payload in its neighbor table. The purpose of having a device 46
know when the parent of its neighbor is active is to maintain the integrity of the parent-child communication 47
link by alleviating the hidden node problem. In other words, a device will never transmit at the same time as 48
the parent of its neighbor. 49
Communication in a tree network shall be accomplished using the parent-child links to route along the tree. 50
Since every child tracks the beacon of its parent, transmissions from a parent to its child shall be completed 51
using the indirect transmission technique. Transmissions from a child to its parent shall be completed during 52
the CAP of the parent. Details for the communication procedures can be found in [B1]. 53
54

1 A new device wishing to join the network shall follow the procedure outlined in sub-clause 2.3.6. In the
2 process of joining the network, the new device shall build its neighbor table based on the information
3 collected during the MAC scan procedure. Using this information, the new device shall choose an
4 appropriate time for its beacon transmission and CAP (the active portion of its superframe structure) such
5 that the active portion of its superframe structure does not overlap with that of any neighbor or of the parent
6 of any neighbor. If there is no available non-overlapping time slot in the neighborhood, the device shall not
7 transmit beacons and shall operate on the network as an end device. If a non-overlapping time slot is
8 available, the time offset between the beacon frames of the parent and of the new device shall be chosen and
9 included in the beacon payload of the new device. Any algorithm for selecting the beacon transmission time
10 that avoids beacon transmission during the active portion of the superframes of its neighbors and their
11 parents may be employed, as interoperability will be ensured.
12
13 To counteract drift, the new device shall track the beacon of its parent and adjust its own beacon
14 transmission time such that the time offset between the two remains constant. Therefore the beacon frames
15 of every device in the network are essentially synchronized with those of the ZigBee coordinator. Figure 61
16 illustrates the relationship between the active superframe portions of a parent and its child.
17
18
19
20
21
22 Beacon Tracking
23
24
25
26 Beacon
27 Tx Offset
28
29 Figure 61 Parent-child superframe positioning relationship
30 The density of devices that can be supported in the network is inversely proportional to the ratio of the
31 superframe order to the beacon order. The smaller the ratio, the longer the inactive period of each device and
32 the more devices that can transmit beacon frames in the same neighborhood. It is recommended that a tree
33 network utilize a superframe order of 0, which gives a superframe duration of 15.36 ms, and a beacon order
34 of between 6 and 10, which gives a beacon interval between 0.98304s and 15.72864s. Using these
35 superframe and beacon order values, a typical duty cycle for devices in the network will be between ~2%
36 and ~0.1%.
37
38 2.7.4.2 MAC enhancement
39
40 In order to employ the beacon scheduling algorithm just described, it is necessary to implement the
41 following enhancement to the IEEE Std 802.15.4-2003146 MAC sub-layer.
42
43
44
45
46
47
48
49
50
51
52
53
146
54 CCB Comment #265

A new parameter, StartTime, shall be added to the MLME-START.request primitive to specify the time to 1
begin transmitting beacons. The new format of the primitive is as follows: 2
3
MLME-START.request ( 4
PANID, 5
LogicalChannel, 6
BeaconOrder, 7
SuperframeOrder,
8
PANCoordinator,
BatteryLifeExtention, 9
CoordRealignment, 10
SecurityEnable, 11
StartTimea 12
)
13
15
The StartTime parameter is fully described in Table 138, and the description of all other parameters can be 16
found in [B1]. 17
18
Table 138 Start time for beacon transmissions 19
21
The time at which to begin transmitting
22
beacons. If the device issuing the primi-
tive is the PAN coordinator, this param- 23
eter is ignored and beacon 24
transmissions will begin immediately. 25
Otherwise, this parameter specifies the 26
time relative to the received beacon of
StartTime Integer 0x000000-0xffffff 27
the device with which it is associated.
28
The parameter is specified in symbols 29
and is rounded to a backoff slot bound- 30
ary. The precision of this value is a min- 31
imum of 20 bits, with the lowest 4 bits
32
being the least significant.a
33
aCCB 34
Comment #265
35
36
2.7.5 Broadcast communication 37
38
This sub-clause specifies how a broadcast transmission is accomplished within a ZigBee network. This 39
mechanism is used to broadcast all network layer data frames147. Any device within a network may initiate 40
a broadcast transmission intended for all other devices that are part of the same network. A broadcast 41
transmission is initiated by the local APS sub-layer entity through the use of the NLDE-DATA.request 42
primitive by setting the DstAddr parameter to 0xffff.148 43
To transmit a broadcast MSDU, the NWK layer issues an MCPS-DATA.request primitive to the MAC sub- 44
layer with the DstAddrMode parameter set to 0x02 (16-bit network address) and the DstAddr parameter set 45
to 0xffff, which is the broadcast network address. The PANId parameter shall be set to the PANId of the 46
ZigBee network. This specification does not support broadcasting across multiple networks. Broadcast 47
transmissions shall not use the MAC sub-layer acknowledgement; instead a passive acknowledgement 48
mechanism is used in the case of non-beacon-enabled ZigBee networks. Passive acknowledgement means 49
that every device keeps track if its neighboring devices have successfully relayed the broadcast 50
51
52
148
CCB Comment #125 54

transmission. The MAC sub-layer acknowledgement is disabled by setting the acknowledged transmission 1
flag of the TxOptions parameter to FALSE. All other flags of the TxOptions parameter shall be set based on 2
the network configuration. 3
4
. Each device shall keep a record of any new broadcast transaction that is either initiated locally or received 5
from a neighboring device. This record is called the broadcast transaction record (BTR) and shall contain at 6
least the sequence number and the source address of the broadcast frame. The broadcast transaction records 7
are stored in the broadcast transaction table (BTT).149 8
9
When a device receives a broadcast frame from a neighboring device, it shall compare the Sequence
10
number150 and the source address of the broadcast frame with the records in its BTT. If the device has a
11
BTR of this particular broadcast frame in its BTT, it shall update the BTR to mark the neighboring device as
12
having relayed the broadcast frame. It shall then drop the frame. If no record is found, it shall create a new
13
BTR in its BTT and shall mark the neighboring device as having relayed the broadcast. The NWK layer
14
shall then indicate to the higher layer that a new broadcast frame has been received. If the radius151 field
15
value is greater than 0 it shall retransmit the frame. Otherwise it shall drop the frame. Before the
16
retransmission, it shall wait for a random time period called broadcast jitter. This time period shall be
17
bounded by the value of the nwkcMaxBroadcastJitter attribute.
18
If, on receipt of a broadcast frame, the NWK layer finds that the BTT is full and contains no expired entries, 19
then the frame should be ignored. In this situation the frame should not be retransmitted, nor should it be 20
passed up to the next higher layer.152 21
22
A device, operating in a non-beacon-enabled ZigBee network, shall retransmit a previous broadcast frame if 23
any of its neighboring devices have not relayed the broadcast frame within nwkPassiveAckTimeout seconds. 24
In this case a device shall retransmit a broadcast frame for at most nwkMaxBroadcastRetries times. 25
26
A device should change the status of a BTT entry after nwkNetworkBroadcastDeliveryTime seconds have 27
elapsed since its creation. The entry should change status to expired and thus the entry can be overwritten if 28
required when a new broadcast is received.153 29
30
When a ZigBee router that has the macRxOnWhenIdle MAC PIB attribute set to FALSE receives a
31
broadcast transmission, it shall use a different procedure for retransmission than the one outlined above. It
32
shall retransmit the frame without delay to each of its neighbors individually, using a MAC layer unicast, i.e.
33
with the DstAddr parameter of the MCPS-DATA.request primitive set to the address of the receiving device
34
and not to the broadcast address. Similarly, a router with the macRxOnWhenIdle MAC PIB attribute set to
35
TRUE, which has one or more neighbors with the macRxOnWhenIdle MAC PIB parameter set to FALSE,
36
shall retransmit the broadcast frame to each of these neighbors in turn as a MAC layer unicast in addition to
37
performing the more general broadcast procedure spelled out in the previous paragraphs. Indirect
38
transmission, as described in [B1], may be employed to ensure that these unicasts reach their destination.
39
Every ZigBee router shall have the ability to buffer at least 1 frame at the NWK layer in order to facilitate 40
retransmission of broadcasts. 41
42
Figure 62 shows a broadcast transaction between a device and two neighboring devices. 43
44
45
46
47
48
49
150
Ibid 51
151
Ibid 52
152CCB Comment #108, 110 53
153
CCB Comment #110 54

1
Neighbor 1 Device Neigbor 2 2
NWK NWK NWK 3
4
5
Broadcast Transmission
6
Add new BTR 7
Mark neighbor 1 as having
relayed the message 8
9
Random 10
broadcast
delay
11
12
13
Mark device as having Add new BTR 14
relayed the message Mark device as having 15
relayed the message
16
Broadcast
Random
17
retry timer 18
broadcast
delay 19
20
21
Ignore
22
broadcast Mark neighbor 2 as having 23
relayed the message
24
25
26
27
28
Figure 62 Broadcast transaction message sequence chart 29
30
31
2.7.6 NWK information in the MAC beacons 32
33
This sub-clause specifies how the NWK layer uses the beacon payload of a MAC sub-layer beacon frame to 34
convey NWK layer-specific information to neighboring devices. 35
36
When the association permit subfield of the superframe specification field of the beacon frame of the device,
37
as defined in [B1], is set to 1 indicating that association is permitted, then the beacon payload shall contain
38
the information shown in Table 139. This enables the NWK layer to provide additional information to new
39
devices that are performing network discovery and allows these new devices to more efficiently select a
40
network and particular neighbor to join. Refer to sub-clause 2.7.1.3.1.1 for a detailed description of the
41
network discovery procedure. This information is not required to be in the beacon payload when the
42
43
44
45
46
47
48
49
50
51
52
53
54

association permit subfield of the superframe specification field of the beacon frame of the device is set to 0 1
indicating that association is not permitted. 2
3
Table 139 NWK layer information fieldsa 4
This field identifies the network 6
layer protocols in use and, for pur- 7
poses of this specification shall 8
Protocol ID Integer 0x00 – 0xff always be set to 0, indicating the 9
ZigBee protocols. The value 0xff 10
shall also be reserved for future
use by the ZigBee alliance. 11
12
Stack profile Integer 0x00 – 0x0f A ZigBee stack profile identifier. 13
14
The version of the ZigBee proto-
nwkcProtocolVersion Integer 0x00 – 0x0f 15
col.
16
This value is set to TRUE if this 17
device is capable to accept join 18
Router capacityb Boolean TRUE or FALSE requests from router-capable
19
devices and is set to FALSE oth-
erwise. 20
21
The tree depth of this device. A 22
value of 0x00 indicates that this
Device depth Integer 0x00 – nwkMaxDepthc 23
device is the ZigBee coordinator
for the network. 24
25
This value is set to TRUE if the 26
device is capable of accepting 27
Endd device capacity Boolean TRUE or FALSE join requests from end devices 28
seeking to join the network and 29
is set to FALSE otherwise.e 30
This value indicates the difference 31
in time, measured in symbols, 32
between the beacon transmission 33
time of the device and the beacon 34
transmission time of its parent.
35
This offset may be subtracted
from the beacon transmission time 36
TxOffset Integer 0x000000 – 0xffffff 37
of the device to calculate the bea-
con transmission time of the par- 38
ent. 39
40
This parameter is only included
when implementing a multihop 41
beaconing network. 42
43
aCCB Comment #129
bIbid
44
c 45
CCB Comment #229
dCCB Comment #129 46
eIbid 47
48
49
The NWK layer of the ZigBee coordinator shall update the beacon payload immediately following network 50
formation. All other ZigBee devices shall update it immediately after the association is completed and 51
anytime the network configuration (any of the parameters specified in Table 106) changes. 52
53
54

The beacon payload is written into the MAC sub-layer PIB using the MLME-SET.request primitive. The 1
macBeaconPayloadLength attribute is set to the length of the beacon payload, and the byte sequence 2
representing the beacon payload is written into the macBeaconPayload attribute. The formatting of the byte 3
sequence representing the beacon payload is shown in Figure 63. 4
5
6
Bits: 0-7 8-11 12-15 16-17 18 19a-22 23 24-47 7
Endd 8
Protocol Stack nwkcProtocol- Router Device Tx Offset
ID profile Version
Reservedb capacityc depth
device 9
capacity (optional)
10
c
Ibid 13
dIbid 14
15
Figure 63 Format of the MAC sub-layer beacon payload 16
17
18
2.7.7 Persistent data
19
Devices operating in the field may be reset manually or programmatically by maintenance personnel, or may 20
be reset accidentally for any number of reasons, including localized or network-wide power failures, battery 21
replacement during the course of normal maintenance, impact and so on. At a minimum, the following 22
information must be preserved across resets in order to maintain an operating network: 23
24
— The device's PAN ID. 25
26
— The device's 16-bit network address.
27
— The 64-bit IEEE address and 16-bit network address of each associated child. 28
29
— The stack profile in use.
30
— The values of nwkNextAddress and nwkAvailableAddresses NIB attributes, if the alternative address- 31
ing is in use. 32
33
— The device's tree depth, if the distributed addressing scheme is in use.
34
The method by which these data are made to persist is beyond the scope of this specification.154 35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
154
CCB Comment #183 54

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Chapter 3 Security Services Specification 1
2
3
4
5
6
3.1 Document Organization 7
8
The remaining portions of this document specify in greater detail the various security services available 9
within the ZigBee stack. Basic definitions and references are given in clause 3.2. A general description of 10
the security services is given in sub-clause 3.2.1. In this clause, the overall security architecture is discussed; 11
basic security services provided by each layer of this architecture are introduced. Clauses 3.2.2, 3.2.3, and 12
3.2.4 give the ZigBee Alliance’s security specifications for the Medium Access Control (MAC) layer, the 13
Network (NWK) layer, and the Application Support Sub-layer (APS) layer, respectively. These clauses 14
introduce the security mechanisms, give the primitives, and define any frame formats used for security 15
purposes. Clause 3.6 describes security elements common to the MAC, NWK, and APS layers. Clause 3.7 16
provides a basic functional description of the available security features. Finally, annexes provide technical 17
details and test vectors needed to implement and test the cryptographic mechanisms and protocols used by 18
the MAC, NWK, and APS layers. 19
20
21
3.2 General Description 22
23
24
Security services provided for ZigBee include methods for key establishment, key transport, frame 25
protection, and device management. These services form the building blocks for implementing security 26
policies within a ZigBee device. Specifications for the security services and a functional description of how 27
these services shall be used are given in this document. 28
29
3.2.1 Security Architecture and Design 30
31
In this clause, the security architecture is described. Where applicable, this architecture complements and 32
makes use of the security services that are already present in the 802.15.4 security specification. 33
34
3.2.1.1 Security Assumptions 35
36
The level of security provided by the ZigBee security architecture depends on the safekeeping of the 37
symmetric keys, on the protection mechanisms employed, and on the proper implementation of the 38
cryptographic mechanisms and associated security policies involved. Trust in the security architecture 39
ultimately reduces to trust in the secure initialization and installation of keying material and to trust in the 40
secure processing and storage of keying material. In the case of indirect addressing, it is assumed that the 41
binding manager is trusted. 42
43
Implementations of security protocols, such as key establishment, are assumed to properly execute the
44
complete protocol and do not leave out any steps hereof. Random number generators are assumed to operate
45
as expected. Furthermore, it is assumed that secret keys do not become available outside the device in an
46
unsecured way. That is, a device will not intentionally or inadvertently transmit its keying material to other
47
devices, unless the keying material is protected, such as during key-transport. An exception to this
48
assumption occurs when a device that has not been preconfigured joins the network. In this case, a single
49
key may be sent unprotected, thus resulting in a brief moment of vulnerability.
50
The following caveat in these assumptions applies: due to the low-cost nature of ad hoc network devices, 51
one cannot generally assume the availability of tamper-resistant hardware. Hence, physical access to a 52
53
54

1 device may yield access to secret keying material and other privileged information and access to the security
2 software and hardware.
3
4 Due to cost constraints, ZigBee has to assume that different applications using the same radio are not
5 logically separated (e.g., by using a firewall). In addition, from the perspective of a given device, it is even
6 not possible (barring certification) to verify whether cryptographic separation between different applications
7 on another device, or even between different layers of the communication stack hereof, is indeed properly
8 implemented. Hence, one has to assume that separate applications using the same radio trust each other (i.e.,
9 there is no cryptographic task separation). In addition, lower layers (e.g., APS, NWK, or MAC) are fully
10 accessible by any of the applications. These assumptions lead to an open trust model for a device: different
11 layers of the communication stack and all applications running on a single device trust each other.
12
In summary: the provided security services cryptographically protect the interfaces between different
13
devices only; separation of the interfaces between different stack layers on the same device is arranged non-
14
cryptographically, via proper design of security service access points.
15
16
3.2.1.2 Security Design Choices
17
18 The open trust model (as described in sub-clause 3.2.1.1) on a device has far-reaching consequences. It
19 allows re-use of the same keying material among different layers on the same device and it allows end-to-
20 end security to be realized on a device-to-device basis rather than between pairs of particular layers (or even
21 pairs of applications) on two communicating devices.
22
23 Another consideration is whether one is concerned with the ability of malevolent network devices to use the
24 network to transport frames across the network without permission.
25
26 These observations lead to the following architectural design choices.
27
First, the principle that “the layer that originates a frame is responsible for initially securing it” is
28
established. For example, if a MAC layer disassociate frame needs protection, MAC layer security shall be
29
used. Likewise, if a NWK command frame needs protection, NWK layer security shall be used.
30
31 Second, if protection from theft of service is required (i.e., malevolent network devices), NWK layer
32 security shall be used for all frames except those communicated between a router and a newly joined device
33 (until the newly joined device received the Network key). Thus, only a device that has joined the network
34 and successfully received the Network key will be able to have its messages communicated more than one
35 hop across the network.
36
37 Third, due to the open trust model, security can be based on the reuse of keys by each layer. For example, the
38 active Network key shall be used to secure APS layer broadcast frames, NWK layer frames, or MAC layer
39 commands. Reuse of keys helps reduce storage costs.
40
41 Fourth, end-to-end security is enabled such as to make it possible that only source and destination devices
42 have access to their shared key. This limits the trust requirement to those devices whose information is at
43 stake. Additionally, this ensures that routing of messages between devices can be realized independent of
44 trust considerations (thus, facilitating considerable separation of concern).
45
Fifth, to simplify interoperability of devices, the security level used by all devices in a given network and by
46
all layers of a device shall be the same. In particular, the security level indicated in the PIB and NIB shall be
47
the same. If an application needs more security than is provided by a given network, it shall form its own
48
separate network with a higher security level.
49
50 There are several policy decisions which any real implementation must address correctly. Application
51 profiles should include these policies:
52
53 — Handling error conditions arising from securing and unsecuring packets. Some error conditions may
54 indicate loss of synchronization of security material, or may indicate ongoing attacks.

Security Services Specification
— Detecting and handling loss of counter synchronization and counter overflow. 1

2
— Detecting and handling loss of key synchronization.
3
— Expiration and periodic update of keys, if desired. 4
5
3.2.1.3 Security Keys 6
7
Security amongst a network of ZigBee devices is based on ‘link’ keys and a “network” key. Unicast 8
communication between APL peer entities is secured by means of a 128-bit link key shared by two devices, 9
while broadcast communications are secured by means of a 128-bit Network key shared amongst all devices 10
in the network. The intended recipient is always aware of the exact security arrangement (i.e., the recipient 11
knows whether a frame is protected with a link or a Network key). 12
13
A device shall acquire link keys either via key-transport, key-establishment, or pre-installation (e.g., factory
14
installation). A device shall acquire a Network key via key-transport or pre-installation (e.g., factory
15
installation). The key-establishment technique for acquiring a link key (see sub-clause 3.2.4.1) is based on a
16
'master' key. A device shall acquire a master key (for purposes of establishing corresponding link keys) via
17
key-transport or pre-installation (e.g., factory installation). Ultimately, security between devices depends on
18
the secure initialization and installation of these keys.
19
In a secured network there are a variety of security services available. Prudence dictates that one would like 20
to avoid re-use of keys across different security services, which may cause security leaks due to unwanted 21
interactions. As such, these different services use a key derived from a one-way function using the link key 22
(as specified in sub-clause 3.6.3). The use of uncorrelated keys ensures the logical separation of executions 23
of different security protocols. he key-load key is used to protect transported master keys; the key-transport 24
key is used to protect other transported keys. 25
26
The Network key may be used by the MAC, NWK, and APL layers of ZigBee. As such, the same Network 27
key and associated outgoing and incoming frame counters shall be available to all of these layers. The link 28
and master keys may be used only by the APS sub-layer. As such, the link and master keys shall be available 29
only to the APL layer. 30
31
3.2.1.4 ZigBee Security Architecture 32
33
ZigBee applications communicate using the IEEE 802.15.4 wireless standard [B1], which specifies two 34
layers, the Physical (PHY) and Medium Access Control (MAC) layers. ZigBee builds on these layers a 35
Network (NWK) layer and an Application (APL) layer. The PHY layer provides the basic communication 36
capabilities of the physical radio. The MAC layer provides services to enable reliable, single-hop 37
communication links between devices. The ZigBee NWK layer provides routing and multi-hop functions 38
needed for creating different network topologies (e.g., star, tree, and mesh structures). The APL layer 39
includes an Application Support (APS) sublayer, the ZigBee Device Object (ZDO), and applications. The 40
ZDO is responsible for overall device management. The APS layer provides a foundation for servicing the 41
ZDO and ZigBee applications. 42
43
The architecture includes security mechanisms at three layers of the protocol stack. The MAC, NWK, and
44
APS layers are responsible for the secure transport of their respective frames. Furthermore, the APS
45
sublayer provides services for the establishment, and maintenance of security relationships. The ZigBee
46
Device Object (ZDO) manages the security policies and the security configuration of a device. Figure 1
47
shows a complete view of the ZigBee protocol stack. The security mechanisms provided by the APS and
48
NWK layers are described in this version of the specification, as is the processing of secure MAC frames.
49
50
3.2.2 MAC Layer Security 51
52
When a frame originating at the MAC layer needs to be secured, ZigBee shall use MAC layer security as 53
specified by the 802.15.4 specification [B1] and augmented by clause 3.3. A security corrigendum 54

1 proposal [B3] is being developed to augment the MAC layer specification and include the security elements
2 needed by ZigBee. Specifically, at least one of ZigBee’s security needs is the ability to protect incoming and
3 outgoing frames using the security levels based on CCM* (see sub-clause 3.6.2.1, and Table 169 for a
4 description of ZigBee security levels). CCM* is a minor modification of CCM specified in Clause 7 and
5 Annex B of the 802.15.4 MAC layer specification [B1]. CCM* includes all of the features of CCM and
6 additionally offers encryption-only and integrity-only capabilities. These extra capabilities simplify security
7 by eliminating the need for CTR and CBC-MAC modes. Also, unlike other MAC layer security modes
8 which require a different key for every security level, the use of CCM* enables the use of a single key for all
9 CCM* security levels. With the use of CCM* throughout the ZigBee stack, the MAC, NWK, and APS
10 layers can reuse the same key.
11
12 The MAC layer is responsible for its own security processing, but the upper layers shall determine which
13 security level to use. For ZigBee, MAC layer frames requiring security processing shall be processed using
14 the security material from the macDefaultSecurityMaterial or the macACLEntryDescriptorSet attributes of
15 the MAC PIB. The upper layer (e.g., APL) shall set macDefaultSecurityMaterial to coincide with the active
16 Network key and counters from the NWK layer and shall set macACLEntryDescriptorSet to coincide with
17 any link keys from the APS layer that are shared with neighboring devices (e.g., a parent and child). The
18 security suite shall be CCM* and the upper layers shall set the security level to coincide with the
19 nwkSecurityLevel attribute in the NIB. For ZigBee, MAC layer link keys shall be preferred, but if not
20 available, the default key (i.e., macDefaultSecurityMaterial) shall be used. Figure 64 shows an example of
21 the security fields that may be included in an outgoing frame with security applied at the MAC level.
22
23 Application of security suite adds auxiliary security
24 information, and may add an integrity code
25
26
PHY MAC Auxiliary
27 SYNC Encrypted MAC Payload MIC
HDR HDR HDR
28
29
30 When integrity protection is employed, the entire MAC frame is protected
31
32 Figure 64 ZigBee frame with security at the MAC level
33
34
35 3.2.3 NWK Layer Security
36
37 When a frame originating at the NWK layer needs to be secured or when a frame originates at a higher layer
38 and the nwkSecureAllFrames attribute in the NIB is TRUE, ZigBee shall use the frame protection
39 mechanism specified in sub-clause 3.4.1 of this specification, unless the SecurityEnable parameter of the
40 NLDE-DATA.request primitive is FALSE, explicitly prohibiting security155. Like the MAC layer, the
41 NWK layer's frame protection mechanism shall make use of the Advanced Encryption Standard (AES) [B8]
42 and use CCM* as specified in Annex A. The security level applied to a NWK frame shall be given by the
43 nwkSecurityLevel attribute in the NIB. Upper layers manage NWK layer security by setting up active and
44 alternate Network keys and by determining which security level to use.
45 One responsibility of the NWK layer is to route messages over multi-hop links. As part of this responsibility,
46 the NWK layer will broadcast route request messages and process received route reply messages. Route
47 request messages are simultaneously broadcast to nearby devices and route reply messages originate from
48 nearby devices. If the appropriate link key is available, the NWK layer shall use the link key to secure
49 outgoing NWK frames. If the appropriate link key is not available, in order to secure messages against
50 outsiders the NWK layer shall use its active Network key to secure outgoing NWK frames and either its
51 active or an alternate Network key to secure incoming NWK frames. In this scenario, the frame format
52
53
155
54 CCB Comment #148

explicitly indicates the key used to protect the frame, thus intended recipients can deduce which key to use 1
for processing an incoming frame and also determine if the message is readable by all network devices, 2
rather than just by itself. 3
4
Figure 65 shows an example of the security fields that may be included in a NWK frame. 5
6
Application of security suite adds auxiliary header 7
and also an integrity code 8
9
10
PHY MAC NWK Auxiliary
SYNC Encrypted NWK Payload MIC 11
HDR HDR HDR HDR
12
13
14
All of the above NWK frame is integrity-protected
15
Figure 65 ZigBee frame with security on the NWK level 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
46
47
48
49
50
51
52
53
54

1 3.2.4 APL Layer Security

2
3 When a frame originating at the APL layer needs to be secured, the APS sublayer shall handle security. The
4 APS layer's frame protection mechanism is specified in sub-clause 3.5.1 of this specification. The APS layer
5 allows frame security to be based on link keys or the Network key. Figure 66 shows an example of the
6 security fields that may be included in an APL frame. Another security responsibility of the APS layer is to
7 provide applications and the ZDO with key establishment, key transport, and device management services.
8
9
10 Application of security suite adds auxiliary header
11 and also an integrity code
12
13
14 SYNC
PHY MAC NWK APS Auxiliary
Encrypted APS Payload MIC
15 HDR HDR HDR HDR HDR
16
17
18 All of the above APS frame is integrity-protected
19
20 Figure 66 ZigBee frame with security on the APS level
21
22 3.2.4.1 Key Establishment
23
24 The APS sublayer's key establishment services provide the mechanism by which a ZigBee device may
25 derive a shared secret key, the so-called link key (see sub-clause 3.2.1.3) with another ZigBee device. Key
26 establishment involves two entities, an initiator device and a responder device, and is prefaced by a trust-
27 provisioning step. Trust information (e.g., a master key) provides a starting point for establishing a link key
28 and can be provisioned in-band or out-band. Once trust information is provisioned, a key-establishment
29 protocol involves three conceptual steps: the exchange of ephemeral data, the use of this ephemeral data to
30 derive the link key, and the confirmation that this link key was correctly computed.
31
32 In the Symmetric-Key Key Establishment (SKKE) protocol, an initiator device establishes a link key with a
33 responder device using a master key. This master key, for example, may be pre-installed during
34 manufacturing, may be installed by a trust center (e.g., from the initiator, the responder, or a third party
35 device acting as a trust center), or may be based on user-entered data (e.g., PIN, password, or key). The
36 secrecy and authenticity of the master key needs to be upheld in order to maintain a trust foundation.
37
38 3.2.4.2 Transport Key
39
40 The transport-key service provides secured and unsecured means to transport a key to another device or
41 other devices. The secured transport-key command provides a means to transport a master, link, Network
42 key from a key source (e.g., trust center) to other devices. The unsecured transport-key command provides a
43 means for loading a device with an initial key. This command does not cryptographically protect the key
44 being loaded. In this case, the security of the transported key can be realized by non-cryptographic means,
45 e.g., by communicating the command via an out-of-band channel.
46
47 3.2.4.3 Update Device
48 The update-device service provides a secure means for a device (e.g., a router) to inform a second device
49 (e.g., a trust center) that a third device has had a change of status that must be updated (e.g., the device
50 joined or left the network). This is the mechanism by which the trust center maintains an accurate list of
51 active network devices.
52
53
54

3.2.4.4 Remove Device 1

2
The remove device service provides a secure means by which a device (e.g., a trust center) may inform 3
another device (e.g., a router) that one of its children should be removed from the network. This may be 4
employed, for example, to remove a device from the network that has not satisfied the trust center’s security 5
requirements for network devices. 6
7
3.2.4.5 Request Key 8
9
The request-key service provides a secure means for a device to request the current Network key, or an end-
10
to-end application master key, from another device (e.g., its trust center).
11
12
3.2.4.6 Switch Key
13
The switch-key service provides a secure means for a device (e.g., a trust center) to inform another device 14
that it should switch to a different active Network key. 15
16
17
3.2.5 Trust Center Role 18
19
For security purposes, ZigBee defines the role of trust center. The trust center is the device trusted by 20
devices within a network to distribute keys for the purpose of network and end-to-end application 21
configuration management. All members of the network shall recognize exactly one trust center, and there 22
shall be exactly one trust center in each secure network. 23
24
In high-security, commercial applications (see sub-clause 3.7.2.1) a device can be preloaded with the trust
25
center address and initial master key (e.g., via an unspecified mechanism). Alternatively, if the application
26
can tolerate a moment of vulnerability, the master key can be sent via an in-band unsecured key transport. If
27
not preloaded, a device’s trust center defaults to the PAN coordinator or a device designated by the PAN
28
coordinator.
29
In low-security, residential applications (see sub-clause 3.7.2.2) a device securely communicates with its 30
trust center using the Network key, which can be preconfigured or sent via an in-band unsecured key 31
transport. 32
33
The functions performed by the trust center can be subdivided into three sub-roles: trust manager, network 34
manager, and configuration manager. A device trusts its trust manager to identify the device(s) that take on 35
the role of its network and configuration manager. A network manager is responsible for the network and 36
distributes and maintains the Network key to devices it manages. A configuration manager is responsible for 37
binding two applications and enabling end-to-end security between devices it manages (e.g., by distributing 38
master keys or link keys). To simplify trust management, these three sub-roles are contained within a single 39
device – the trust center. 40
41
For purposes of trust management, a device shall accept an initial master or Network key originating from 42
its trust center via unsecured key transport. For purposes of network management, a device shall accept an 43
initial Network key and updated Network keys only from its trust center (i.e., network manager). For 44
purpose of configuration, a device shall accept master keys or link keys for the purpose of establishing end- 45
to-end security between two devices only from its trust center (i.e., configuration manager). Aside from the 46
initial master key, additional link, master, and Network keys shall only be accepted if they originate from a 47
device’s trust center via secured key transport. 48
49
50
51
52
53
54

1 3.3 MAC Layer Security

2
3
4 The MAC layer is responsible for the processing steps needed to securely transmit outgoing MAC frames
5 and securely receive incoming MAC frames. Upper layers control the security processing operations, by
6 setting up the appropriate keys and frame counters and establishing which security level to use.
7
8 3.3.1 Frame Security
9
10 The detailed steps involved in security processing of outgoing and incoming MAC frames are described in
11 sub-clause 3.3.1.1 and sub-clause 3.3.1.2, respectively.
12
13 3.3.1.1 Security Processing of Outgoing Frames
14
15 If the MAC layer has a frame, consisting of a header MacHeader and payload Payload, that needs security
16 protection it shall apply security as follows:
17
18 1. Obtain the security material (as specified in sub-clause 3.3.2), including the key, outgoing frame
19 counter FrameCount, key sequence count SeqCount, and security level identifier (as specified in
20 Table 169) from the MAC PIB using the following procedure. If the outgoing frame counter has as its
21 value the 4-octet representation of the integer 232-1 or any of this security material cannot be
22 determined, then security processing shall fail and no further security processing shall be done on this
23 frame.
24 a) First, an attempt shall be made to retrieve the security material and security level identifier associ-
25 ated with the destination address of the outgoing frame from the macACLEntryDescriptorSet
26 attribute in the MAC PIB.
27
28 b) If the first attempt fails, then security material shall be obtained by using the macDefaultSecurity-
29 Material attribute from the MAC PIB and the security level identifier shall be obtained from the
30 MacDefaultSecuritySuite attribute from the MAC PIB.
31 2. The Security Control Field SecField is the 1-octet field formatted as in sub-clause 3.6.1.1, with the
32 following settings:
33
a) The security level subfield shall be set to the security level obtained in Step 1 above;
34
35 b) The key identifier subfield shall be set to the 2-bit field '00';
36 c) The extended nonce subfield shall be set to the 1-bit field '0';
37
38 d) The reserved bits shall be set to the 2-bit field '00'.156
39 3. Execute the CCM* mode encryption and authentication operation, as specified in Annex A, with the
40 following instantiations:
41
42 a) The parameter M shall be obtained from Table 169 corresponding to the security level from step 1;
43 b) The bit string Key shall be the key obtained from step 1;
44
c) The nonce N shall be the 13-octet string constructed using the local device’s 64-bit extended
45
address, SecField from Step 1157, and FrameCount from step 1 (see Figure 72 from [B1]);
46
47 d) If the security level requires encryption, the octet string a shall be the string MacHeader and the
48 octet string m shall be the string Payload. Otherwise, the octet string a shall be the string Mac-
49 Header || Payload and the octet string m shall be a string of length zero. Note that ZigBee interprets
50 [B1] to mean that frame counters are authenticated.158
51
52 156
CCB Comment #195
53 157Ibid
158
54 CCB Comment #180

4. If the CCM* mode invoked in step 3159 outputs ‘invalid’, security processing shall fail and no further 1
security processing shall be done on this frame. 2
3
5. Let c be the output from step 4160 above. If the security level requires encryption, the secured outgoing 4
frame shall be MacHeader || FrameCount || SeqCount || c, otherwise the secured outgoing frame shall be 5
MacHeader || FrameCount || SeqCount || Payload || c. 6
6. If the secured outgoing frame size is greater than aMaxPHYPacketSize (from [B1]), security processing 7
shall fail and no further security processing shall be done on this frame. 8
9
7. The outgoing frame counter from step 1 shall be incremented by one and stored in the location from 10
which the security material was obtained in step 1 (i.e., either the macDefaultSecurityMaterial attribute 11
or the MacDefaultSecuritySuite attribute). 12
13
3.3.1.2 Security Processing of Incoming Frames 14
15
If the MAC layer receives a secured frame (consisting of a header MacHeader, frame count
16
ReceivedFrameCount, sequence count ReceivedSeqCount, and payload SecuredPayload) it shall perform
17
security processing as follows:
18
19
1. If ReceivedFrameCount has as value the 4-octet representation of the integer 232-1, security processing
20
shall fail and no further security processing shall be done on this frame.
21
2. Obtain the security material (as specified in sub-clause 3.3.2), including the key, optional external frame 22
counter FrameCount, optional key sequence count SeqCount, and security level identifier (as specified 23
in Table 169) from the MAC PIB using the following procedure. If the security material cannot be 24
obtained or if SeqCount exists and does not match ReceivedSeqCount, security processing shall fail and 25
no further security processing shall be done on this frame. 26
a) First, an attempt shall be made to retrieve the security material and security level identifier associ- 27
ated with the source address of the incoming frame from the macACLEntryDescriptorSet attribute 28
in the MAC PIB. 29
30
b) If the first attempt fails, then security material shall be obtained by using the macDefaultSecurity- 31
Material attribute from the MAC PIB and the security level identifier shall be obtained from the 32
MacDefaultSecuritySuite attribute from the MAC PIB. 33
3. If FrameCount exists and if ReceivedFrameCount is less than FrameCount, security processing shall 34
fail and no further security processing shall be done on this frame. 35
36
4. The Security Control Field SecField is the 1-octet field formatted as in Clause 7.1.1, Figure 18, with the
37
following settings:
38
a) The security level subfield shall be set to the security level from the MACPIB (as specified in Table 39
29); 40
b) The key identifier subfield shall be set to the 2-bit field '00'; 41
42
c) The extended nonce subfield shall be set to the 1-bit field '0'; 43
d) The reserved bits shall be set to the 2-bit field '00'.161 44
45
5. Execute the CCM* mode decryption and authentication checking operation, as specified in Annex A.3, 46
with the following instantiations: 47
a) The parameter M shall be obtained from Table 169 corresponding to the security level from step 1; 48
49
b) The bit string Key shall be the key obtained from step 2;
50
51
159
CCB Comment #195 52
160Ibid 53
161
Ibid 54

1 c) The nonce N shall be the 13-octet string constructed using the 64-bit extended sender address,
2 SecField from Step 4162, and ReceivedFrameCount from step 1 (see Figure 72 from [B1]);The
3 nonce N shall be formatted according to the endianness convention used in this specification (the
4 octet containing the lowest numbered bits first to the octet containing the higher numbered bits).163
5
d) Parse the octet string SecuredPayload as Payload1 || Payload2, where the right-most string Payload2
6
is an M-octet string. If this operation fails, security processing shall fail and no further security pro-
7
cessing shall be done on this frame;
8
9 e) If the security level requires encryption, the octet string a shall be the string MacHeader || Received-
10 FrameCount || ReceivedSeqCount and the octet string c shall be the string SecuredPayload. Other-
11 wise, the octet string a shall be the string MacHeader || ReceivedFrameCount || ReceivedSeqCount
12 || Payload1 and the octet string c shall be the string Payload2.
13 6. Return the results of the CCM* operation:
14
15 a) If the CCM* mode invoked in step 5164 outputs ‘invalid’, security processing shall fail and no fur-
16 ther security processing shall be done on this frame;
17 b) Let m be the output of step 5165 above. If the security level requires encryption, set the octet string
18 UnsecuredMacFrame to the string a || m. Otherwise, set the octet string UnsecuredMacFrame to
19 the string a;
20
7. If the optional FrameCount (obtained in step 2) exists, set it to ReceivedFrameCount and update MAC
21
PIB. UnsecuredMacFrame now represents the unsecured received MAC layer frame.
22
23
24 3.3.2 Security-Related MAC PIB Attributes
25
26 The security-related MAC PIB attributes shall be those as defined in Table 72 of [B1]. The security material
27 used for CCM* mode shall the same as given for CCM mode in Figure 70 of [B1].
28
29 For the macDefaultSecurityMaterial attribute from the MAC PIB, the upper layer shall set the symmetric
30 key, outgoing frame counter, and optional external key sequence counter equal to the corresponding
31 elements of the network security material descriptor in the nwkSecurityMaterialSet of the NIB referenced by
32 the nwkActiveKeySeqNumber attribute of the NIB. The optional external frame counter shall not be used and
33 the optional external key sequence counter shall correspond to the sequence number of the Network key.
34
For the macACLEntryDescriptorSet attribute from the MAC PIB, the upper layer shall set the symmetric
35
key, and outgoing frame counter equal to the corresponding elements of the Network key-pair descriptor in
36
the apsDeviceKeyPairSet of the AIB. The optional external frame counter shall be set to the incoming frame
37
counter, The key sequence counter shall be set to 0x00, and the optional external key sequence counter shall
38
not be used.
39
40
41
42
3.4 NWK Layer Security
43
44 The NWK layer is responsible for the processing steps needed to securely transmit outgoing frames and
45 securely receive incoming frames. Upper layers control the security processing operations, by setting up the
46 appropriate keys and frame counters and establishing which security level to use. The formatting of all
47 frames and fields in this specification are depicted in the order in which they are transmitted by the NWK
48 layer, from left to right, where the leftmost bit is transmitted first in time. Bits within each field are
49 numbered from 0 (leftmost and least significant) to k-1 (rightmost and most significant), where the length of
50
51 162
CCB Comment #195
52 163
CCB Comment #98
165
54 Ibid

the field is k bits. Fields that are longer than a single octet are sent to the next layer in the order from the 1
octet containing the lowest numbered bits to the octet containing the highest numbered bits.166 2
3
4
3.4.1 Frame Security 5
6
The detailed steps involved in security processing of outgoing and incoming NWK frames are described in
7
sub-clause 3.4.1.1 and sub-clause 3.4.1.2, respectively.
8
9
3.4.1.1 Security Processing of Outgoing Frames
10
If the NWK layer has a frame, consisting of a header NwkHeader and payload Payload, that needs security 11
protection and nwkSecurityLevel > 0, it shall apply security as follows: 12
13
1. Obtain the nwkActiveKeySeqNumber from the NIB and use it to retrieve the active Network key key, 14
outgoing frame counter OutgoingFrameCounter, and key sequence number KeySeqNumber from the 15
nwkSecurityMaterialSet attribute in the NIB. Obtain the security level from the nwkSecurityLevel 16
attribute from the NIB. If the outgoing frame counter has as its value the 4-octet representation of the 17
integer 232-1, or if the key cannot be obtained, security processing shall fail and no further security 18
processing shall be done on this frame. 19
20
2. Construct auxiliary header AuxiliaryHeader (see sub-clause 3.6.1):
21
a) The security control field shall be set as follows: 22
1) The security level sub-field shall be the security level obtained from step 1. 23
2) The key identifier sub-field shall be set to ‘01’ (i.e., the Network key). 24
3) The extended nonce sub-field shall be set to 1. 25
b) The source address field shall be set to the 64-bit extended address of the local device. 26
27
c) The frame counter field shall be set to the outgoing frame counter from step 1. 28
d) The key sequence number field shall be set to the sequence number from step 1. 29
30
3. Execute the CCM* mode encryption and authentication operation, as specified in Annex A, with the 31
following instantiations: 32
a) The parameter M shall be obtained from Table 169 corresponding to the security level from step 1; 33
34
35
c) The nonce N shall be the 13-octet string constructed using the security control field from step 2a, the 36
frame counter field from step 2c, and the source address field from step 2b (see sub-clause 3.6.2.2); 37
d) If the security level requires encryption, the octet string a shall be the string NwkHeader || Auxiliar- 38
yHeader and the octet string m shall be the string Payload. Otherwise, the octet string a shall be the 39
string NwkHeader || AuxiliaryHeader || Payload and the octet string m shall be a string of length 40
zero. 41
42
frame shall be NwkHeader || AuxiliaryHeader || c, otherwise the secured outgoing frame shall be 46
NwkHeader || AuxiliaryHeader || Payload || c. 47
48
6. If the secured outgoing frame size is greater than aMaxMACFrameSize (see [B1]), security processing
49
50
7. The outgoing frame counter from step 1 shall be incremented by one and stored in the 51
OutgoingFrameCounter element of the network security material descriptor referenced by the 52
53
166
CCB Comment #98 54

1 nwkActiveKeySeqNumber in the NIB (i.e., the outgoing frame counter value associated with the key
2 used to protect the frame is updated).
3
4 8. Over-write the security level subfield of the security control field by the 3-bit all-zero string '000'.167
5
6 3.4.1.2 Security Processing of Incoming Frames
7 If the NWK layer receives a secured frame (consisting of a header NwkHeader, auxiliary header
8 AuxiliaryHeader, and payload SecuredPayload) as indicated by the security sub-field of the NWK header
9 frame control field it shall perform security processing as follows:
10
11 1. Determine the security level from the nwkSecurityLevel attribute from the NIB. Over-write the 3-bit
12 security level subfield of the security control field of the AuxillaryHeader with this value. Determine
13 the sequence number SequenceNumber, sender address SenderAddress, and received frame count
14 ReceivedFrameCount from the auxiliary header AuxiliaryHeader (see sub-clause 3.6.1). If
15 ReceivedFrameCounter has as value the 4-octet representation of the integer 232-1, security processing
16 shall fail and no further security processing shall be done on this frame.168
17
18 2. Obtain the appropriate security material (consisting of the key and other attributes) by matching
19 SequenceNumber to the sequence number of any key in the nwkSecurityMaterialSet attribute in the
20 NIB. If the security material cannot be obtained, security processing shall fail and no further security
21 processing shall be done on this frame. If the sequence number of the received frame belongs to a newer
22 entry in the nwkSecurityMaterialSet, and the source address of the packet is the trust center, then the
23 nwkActiveKeySeqNumber shall be set to received sequence number.169
24
3. If there is an incoming frame count FrameCount corresponding to SenderAddress from the security
25
material obtained in step 2 and if ReceivedFrameCount is less than FrameCount, security processing
26
27
28 4. Execute the CCM* mode decryption and authentication checking operation, as specified in Annex A.3,
29 with the following instantiations:
30 a) The parameter M shall obtained from Table 169 corresponding to the security level from step 1;
31
32 b) The bit string Key shall be the key obtained from step 2;
33 c) The nonce N shall be the 13-octet string constructed using the security control, the frame counter,
34 and the source address fields from AuxiliaryHeader (see sub-clause 3.6.2.2). Note that the security
35 level subfield of the security control field has been overwritten in step 1 and now contains the value
36 determined from the nwkSecurityLevel attribute from the NIB.170
37
d) Parse the octet string SecuredPayload as Payload1 || Payload2, where the right-most string Payload2
38
is an M-octet string. If this operation fails, security processing shall fail and no further security pro-
39
cessing shall be done on this frame;
40
41 e) If the security level requires encryption, the octet string a shall be the string NwkHeader || Auxiliar-
42 yHeader and the octet string c shall be the string SecuredPayload. Otherwise, the octet string a
43 shall be the string NwkHeader || AuxiliaryHeader || Payload1 and the octet string c shall be the
44 string Payload2.
46
47 a) If the CCM* mode invoked in step 4 outputs ‘invalid’, security processing shall fail and no further
48 security processing shall be done on this frame;
49
50
51 167
CCB Comment #245
52 168
Ibid
170
54 CCB Comment #245

b) Let m be the output of step 4 above. If the security level requires encryption, set the octet string 1
UnsecuredNwkFrame to the string a || m. Otherwise, set the octet string UnsecuredNwkFrame to 2
the string a; 3
4
6. Set FrameCount to (ReceivedFrameCount + 1)171 and store both FrameCount and SenderAddress in 5
the NIB. UnsecuredNwkFrame now represents the unsecured received network frame and security 6
processing shall succeed. So as to never cause the storage of the frame count and address information to 7
exceed the available memory, the memory allocated for incoming frame counters needed for NWK 8
layer security shall be bounded by M*N, where M and N represent the cardinality of 9
nwkSecurityMaterialSet and nwkNeighborTable in the NIB, respectively. 10
11
3.4.2 Secured NPDU Frame 12
13
The NWK layer frame format from [B3] consists of a NWK header and NWK payload field. The NWK 14
header consists of frame control and routing fields. When security is applied to an NPDU frame, the security 15
bit in the NWK frame control field shall be set to 1 to indicate the presence of the auxiliary frame header. 16
The format for the auxiliary frame header is given in sub-clause 3.6.1. The format of a secured NWK layer 17
frame is shown in Figure 67. The auxiliary frame header is situated between the NWK header and payload 18
fields. 19
20
Figure 67 Secured NWK layer frame format 21
Octets: Variable 14 Variable 22
23
Original NWK Encrypted 24
Auxiliary Encrypted Message Integrity Code (MIC)
Header Payload
frame header 25
([B3], Clause 7.1) Secure frame payload = Output of CCM* 26
27
Full NWK header Secured NWK payload 28
29
30
31
32
3.4.3 Security-Related NIB Attributes 33
34
The NWK PIB contains attributes that are required to manage security for the NWK layer. Each of these 35
attributes can be read and written using the NLME-GET.request and NLME-SET.request primitives, 36
respectively. The security-related attributes contained in the NWK PIB are presented in Table 140 through 37
Table 142. 38
39
Table 140 NIB security attributes
40
Attribute Identifier Type Range Description Default 41
The security level for outgo- 42
ing and incoming NWK 43
nwkSecurityLevel 0xa0a Octet 0x00-07 frames. The allowable secu- 0x06 44
rity level identifiers are pre- 45
sented in Table 169. 46
A set of 0, 1, or Set of network security 47
2 network material descriptors capa- 48
nwkSecurity-Mate- security mate- ble of maintaining an active 49
0xa1b Variable -
rialSet rial descrip- and alternate Network key. 50
tors. See
51
Table 141.
52
53
171
CCB Comment #160 54

1 Table 140 NIB security attributes

2
The sequence number of
3 nwkActiveKey- 0x00-
0xa2c Octet the active Network key in 0x00
4 SeqNumber 0xFF
nwkSecurityMaterialSet.
5
6 Indicates whether incoming
NWK frames must be all
7 TRUE |
nwkAllFresh 0xa3d Boolean checked for freshness when TRUE
8 FALSE
the memory for incoming
9 frame counts is exceeded.
10
11 This indicates if security
shall be applied to incoming
12 and outgoing NWK frames.
13 If set to 0x01 security pro-
14 cessing shall be applied to
15 all incoming and outgoing
16 frames except data frames
destined for the current
17 device that have the security
18 nwkSecureAll- TRUE | sub-field of the frame control
0xa5 Boolean TRUE
19 Framese FALSE field set to 0. If this attribute
20 has a value of 0x01 the
21 NWK layer shall not relay
frames that have the secu-
22 rity sub-field of the frame
23 control field set to 0. The
24 SecurityEnable parameter
25 of the NLDE-DATA.request
26 primitive shall override the
setting of this attribute.
27
28 aCCB
Comment #151
29 bIbid
cIbid
30 dIbid
31 eIbid
32
33
34
35
Table 141 Elements of the network security material descriptor
36
37 Name Type Range Description Default
38 A sequence number assigned to a
39 Network key by the trust center and
40 KeySeqNumber Octet 0x00-0xFF used to distinguish Network keys 00
41 for purposes of key updates, and
incoming frame security operations.
42
43 OutgoingFrame- Ordered set 0x00000000- Outgoing frame counter used for
0x00000000
44 Counter of 4 octets 0xFFFFFFFF outgoing frames.
45
Set of incom-
46
ing frame
47 Set of incoming frame counter val-
IncomingFrame- counter
48 Variable ues and corresponding device Null set
CounterSet descriptor
addresses.
49 values. See
50 Table 142.
51 Ordered set
52 Key - The actual value of the key. -
of 16 octets
53
54

1
2
Table 142 Elements of the incoming frame counter descriptor 3
Name Type Range Description Default 4
SenderAddress Device Any valid 64-bit Extended device address. 5
Device specific 6
address address
7
IncomingFrame- Ordered set of 0x00000000- Incoming frame counter 8
0x00000000
Counter 4 octets 0xFFFFFFFF used for incoming frames.
9
10
11
3.5 APS Layer Security 12
13
14
The APS layer is responsible for the processing steps needed to securely transmit outgoing frames, securely 15
receive incoming frames, and securely establish and manage cryptographic keys. Upper layers control the 16
management of cryptographic keys by issuing primitives to the APS layer. Table 143 lists the primitives 17
available for key management and maintenance. Upper layers also determine which security level to use 18
when protecting outgoing frames. The formatting of all frames and fields in this specification are depicted in 19
the order in which they are transmitted by the NWK layer, from left to right, where the leftmost bit is 20
transmitted first in time. Bits within each field are numbered from 0 (leftmost and least significant) to k-1 21
(rightmost and most significant), where the length of the field is k bits. Fields that are longer than a single 22
octet are sent to the next layer in the order from the octet containing the lowest numbered bits to the octet 23
containing the highest numbered bits.172 24
Table 143 The APS layer security primitives 25
26
APSME
Request Confirm Indication Response Description 27
Security Primitives
28
Establish link key with 29
APSME-ESTABLISH-
3.5.2.1 3.5.2.2 3.5.2.3 3.5.2.4 another ZigBee device 30
KEY
using the SKKE method.
31
Transport security mate- 32
APSME-TRANS-
3.5.3.1 - 3.5.3.2 - rial from one device to 33
PORT-KEY
another. 34
Notifies the trust center 35
APSME- when a new device joined 36
3.5.4.1 - 3.5.4.2 -
UPDATE-DEVICE or an existing device left 37
the network. 38
39
Used by the trust center to
notify a router that one of 40
APSME- 41
3.5.5.1 - 3.5.5.2 - the router’s child devices
REMOVE-DEVICE
should be removed from 42
the network. 43
Used by a device to 44
request that the trust cen- 45
APSME-REQUEST-
3.5.6.1 - 3.5.6.2 - ter send an application 46
KEY
master key or current Net- 47
work key. 48
Used by the trust center to 49
APSME- 50
3.5.7.1 - 3.5.7.2 - tell a device to switch to a
SWITCH-KEY
new Network key. 51
52
53
172
CCB Comment #98 54

1 3.5.1 Frame Security

2
3 The detailed steps involved in security processing of outgoing and incoming APS frames are described in
4 sub-clause 3.5.1.1 and sub-clause 3.5.1.2, respectively.
5
6 3.5.1.1 Security Processing of Outgoing Frames
7
8 If the APS layer has a frame, consisting of a header ApsHeader and payload Payload, that needs security
9 protection and nwkSecurityLevel > 0, it shall apply security as follows:
10
1. Obtain the security material and key identifier KeyIdentifier using the following procedure. If security
11
material or key identifier cannot be determined, then security processing shall fail and no further
12
security processing shall be done on this frame.
13
14 a) If the frame is a result of a APSDE-DATA.request primitive:
15 i) If the useNwkKeyFlag parameter is TRUE, then security material shall be obtained by
16 using the nwkActiveKeySeqNumber from the NIB to retrieve the active Network key, out-
17 going frame counter, and sequence number from the nwkSecurityMaterialSet attribute in
18 the NIB. KeyIdentifier shall be set to ‘01’ (i.e., the Network key).
19 ii) Otherwise, the security material associated with the destination address of the outgoing
20 frame shall be obtained from the apsDeviceKeyPairSet attribute in the AIB. KeyIdentifier
21 shall be set to ‘00’ (i.e., a data key). Note, if the frame is being transmitted using indirect
22 addressing, the destination address shall be the address of the binding manager.
23 b) If the frame is a result of an APS command:
24
25 i) First, an attempt shall be made to retrieve the security material associated with the destina-
26 tion address of the outgoing frame from the apsDeviceKeyPairSet attribute in the AIB. For
27 all cases, except transport-key commands, KeyIdentifier shall be set to ‘00’(i.e., a data
28 key). For the case of transport-key commands, KeyIdentifier shall be set to ‘02’ (i.e., the
29 key-transport key) when transporting a Network key and shall be set to ‘03’ (i.e., the key-
30 load key) when transporting an application link key, application master key, or trust center
31 master key. See sub-clause 3.6.3 for a description of the key-transport and key-load keys.
32 ii) If the first attempt fails, then security material shall be obtained by using the nwkAc-
33 tiveKeySeqNumber from the NIB to retrieve the active Network key, outgoing frame
34 counter, and sequence number from the nwkSecurityMaterialSet attribute in the NIB. Key-
35 Identifier shall be set to ‘01’ (i.e., the Network key).
36 2. If the key identifier is equal to 01 (i.e. network key), the APS layer shall first verify that the NWK layer
37 is not also applying security. If the NWK layer is applying security, then the APS layer shall not apply
38 any security. The APS layer can determine that the NWK layer is applying security by verifying that the
39 value of the nwkSecureAllFrames attribute of the NIB has a value of TRUE and the nwkSecurityLevel
40 NIB attribute has a non-zero value.173
41 3. Extract the outgoing frame counter (and, if KeyIdentifier is 01, the key sequence number) from the
42 security material obtained from step 1. If the outgoing frame counter has as its value the 4-octet
43
representation of the integer 232-1, or if the key cannot be obtained, security processing shall fail and no
44
further security processing shall be done on this frame.
45
46 4. Obtain the security level from the nwkSecurityLevel attribute from the NIB. If the frame is a result of an
47 APS command, the security level shall be forced to 7 (ENC-MIC-128).
48 5. Construct auxiliary header AuxiliaryHeader (see sub-clause 3.6.1):
49
50 a) The security control field shall be set as follows:
51 i) The security level sub-field shall be the security level obtained from step 3.
52
53
173
54 CCB Comment #145

ii) The key identifier sub-field shall be set to KeyIdentifier. 1

iii) The extended nonce sub-field shall be set to 0. 2
b) The frame counter field shall be set to the outgoing frame counter from step 2. 3
4
c) If KeyIdentifier is 1, the key sequence number field shall be present and set to the key sequence
5
number from step 2. Otherwise, the key sequence number field shall not be present.
6
6. Execute the CCM* mode encryption and authentication operation, as specified in Annex A.2, with the 7
following instantiations: 8
a) The parameter M shall obtained from Table 169 corresponding to the security level from step 3; 9
10
b) The bit string Key shall be the key obtained from step 1; 11
c) The nonce N shall be the 13-octet string constructed using the security control and frame counter 12
fields from step 4 and the 64-bit extended address of the local device (see sub-clause 3.6.2.2); 13
14
d) If the security level requires encryption, the octet string a shall be the string ApsHeader || Auxiliary-
15
Header and the octet string m shall be the string Payload. Otherwise, the octet string a shall be the
16
string ApsHeader || AuxiliaryHeader || Payload and the octet string m shall be a string of length
17
zero.
18
frame shall be ApsHeader || AuxiliaryHeader || c, otherwise the secured outgoing frame shall be 22
ApsHeader || AuxiliaryHeader || Payload || c. 23
24
9. If the secured outgoing frame size will result in the MSDU being greater than aMaxMACFrameSize 25
octets174 (see [B1]), security processing shall fail and no further security processing shall be done on 26
this frame. 27
10. The outgoing frame counter from step 1 shall be incremented and stored in the appropriate location(s) 28
of the NIB, AIB, and MAC PIB corresponding to the key that was used to protect the outgoing frame. 29
30
11. Over-write the security level subfield of the security control field by the 3-bit all-zero string '000'.175 31
32
3.5.1.2 Security Processing of Incoming Frames 33
34
If the APS layer receives a secured frame (consisting of a header ApsHeader, auxiliary header 35
AuxiliaryHeader, and payload SecuredPayload) as indicated by the security sub-field of the APS header 36
frame control field it shall perform security processing as follows: 37
38
1. Determine the sequence number SequenceNumber, key identifier KeyIdentifier, and received frame
39
counter value ReceivedFrameCounter from the auxiliary header AuxiliaryHeader. If
40
ReceivedFrameCounter is the 4-octet representation of the integer 232-1, security processing shall fail
41
and no further security processing shall be done on this frame.176 42
2. Determine the source address SourceAddress from the address-map table in the AIB, using the source 43
address in the APS frame as the index. If the source address is incomplete or unavailable, security 44
processing shall fail and no further security processing shall be done on this frame. If the delivery-mode 45
sub-field of the frame control field of ApsHeader has a value of 1 (i.e., indirect addressing), the source 46
address shall be the address of the binding manager, as described in the APS specification [B7]. 47
48
3. Obtain the appropriate security material in the following manner. If the security material cannot be 49
obtained, security processing shall fail and no further security processing shall be done on this frame. 50
51
174
CCB Comment #366 52
176
Ibid 54

1 a) If KeyIdentifier is ‘00’ (i.e., data key), the security material associated with the SourceAddress of the
2 incoming frame shall be obtained from the apsDeviceKeyPairSet attribute in the AIB.
3
b) If KeyIdentifier is ‘01’ (i.e., Network key), the security material shall be obtained by matching
4
SequenceNumber to the sequence number to the sequence number of any key in the nwkSecurity-
5
MaterialSet attribute in the NIB. If the sequence number of the received frame belongs to a newer
6
entry in the nwkSecurityMaterialSet, then the nwkActiveKeySeqNumber may be set to the received
7
sequence number. If the security material associated with the SourceAddress of the incoming frame
8
can be obtained from the attribute in the AIB, then security processing shall fail and no further
9
security processing shall be done on this frame.177
10
11 c) If KeyIdentifier is ‘02’ (i.e., key-transport key), the security material associated with the SourceAd-
12 dress of the incoming frame shall be obtained from the apsDeviceKeyPairSet attribute in the AIB
13 and the key for this operation shall be derived from the security material as specified in sub-clause
14 3.6.3 for the key-transport key.
15 d) If KeyIdentifier is ‘03’ (i.e., key-load key), the security material associated with the SourceAddress
16 of the incoming frame shall be obtained from the apsDeviceKeyPairSet attribute in the AIB and the
17 key for this operation shall be derived from the security material as specified in sub-clause 3.6.3 for
18 the key-load key.
19
20 4. If there is an incoming frame count FrameCount corresponding to SourceAddress from the security
21 material obtained in step 3 and if ReceivedFrameCount is less than FrameCount, security processing
22 shall fail and no further security processing shall be done on this frame.
23 5. Determine the security level SecLevel as follows. If the frame type subfield of the frame control field of
24 ApsHeader indicates an APS data frame, then SecLevel shall be set to the nwkSecurityLevel attribute in
25 the NIB. Otherwise SecLevel shall be set to 7 (ENC-MIC-128). Overwrite the security level subfield of
26 the security control field in the AuxillaryHeader with the value of SecLevel.178
27
28 6. Execute the CCM* mode decryption and authentication checking operation, as specified in Annex A.3,
29 with the following instantiations:
30 a) The parameter M shall obtained from Table 169 corresponding to the security level from step 5;
31
32
33 c) The nonce N shall be the 13-octet string constructed using the security control and frame counter
34 fields from AuxiliaryHeader, and SourceAddress from step 2 (see sub-clause 3.6.2.2);
35 d) Parse the octet string SecuredPayload as Payload1 || Payload2, where the right-most string Payload2
36 is an M-octet string. If this operation fails, security processing shall fail and no further security pro-
37 cessing shall be done on this frame;
38
39 e) If the security level requires encryption, the octet string a shall be the string ApsHeader || Auxiliary-
40 Header and the octet string c shall be the string SecuredPayload. Otherwise, the octet string a shall
41 be the string ApsHeader || AuxiliaryHeader || Payload1 and the octet string c shall be the string
42 Payload2.
44
45 a) If the CCM* mode invoked in step 4 outputs ‘invalid’, security processing shall fail and no further
46 security processing shall be done on this frame;
47 b) Let m be the output of step 4 above. If the security level requires encryption, set the octet string
48 UnsecuredApsFrame to the string a || m. Otherwise, set the octet string UnsecuredApsFrame to the
49 string a;
50
51
52
178
54 CCB Comment #245

8. Set FrameCount to (ReceivedFrameCount + 1)179 and store both FrameCount and SourceAddress in 1
the appropriate security material as obtained in step 3. If storing this frame count and address 2
information will cause the memory allocation for this type of information to be exceeded and the 3
nwkAllFresh attribute in the NIB is TRUE, then security processing shall fail and no further security 4
processing shall be done on this frame; otherwise security processing shall succeed. 5
6
7
3.5.2 Key-Establishment Services 8
9
The APSME provides services that allow two devices to mutually establish a link key. Initial trust 10
information (e.g., a master key) must be installed in each device prior to running the key establishment 11
protocol (see sub-clause 3.5.3 for mechanisms to provision initial trust information). 12
13
3.5.2.1 APSME-ESTABLISH-KEY.request 14
The APSME-ESTABLISH-KEY.request primitive is used for initiating a key-establishment protocol. This 15
primitive can be used when there is a need to securely communicate with another device. One device will act 16
as an initiator device and another device will act as the responder. The initiator shall start the key- 17
establishment protocol by issuing the APSME-ESTABLISH-KEY.request with parameters indicating the 18
address of the responder device and which key-establishment protocol to use (i.e., SKKE direct or indirect). 19
20
22
This primitive shall provide the following interface: 23
24
25
APSME-ESTABLISH-KEY.request {
ResponderAddress, 26
UseParent, 27
ResponderParentAddress, 28
KeyEstablishmentMethod 29
}
30
31
Table 144 specifies the parameters for the APSME-ESTABLISH-KEY.request primitive. 32
Table 144 APSME-ESTABLISH-KEY.request parameters 33
34
Parameter Name Type Valid Range Description 35
Any valid The extended 64-bit address of the responder 36
Device
Responder-Address 64-bit device. 37
Address
address 38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
179
CCB Comment #160 54

1 Table 144 APSME-ESTABLISH-KEY.request parameters

2
This parameter indicates if the responder’s
3 parent shall be used to forward messages
4 between the initiator and responder devices:
TRUE |
5 UseParent Boolean
FALSE
6 TRUE: Use parent.
7
FALSE: Do not use parent.
8
9 If the UseParent is TRUE, then Responder-
10 Any valid ParentAddress parameter shall contain the
Responder-ParentAd- Device
11 64-bit extended 64-bit address of the responder’s
dress Address
address parent device. Otherwise, this parameter is not
12
used and need not be set.
13
14 The requested key-establishment method shall
15 be one of the following:
16 KeyEstablishment-
Integer 0x00 - 0x03
Method 0x00 = SKKE method.
17
18 0x01-0x03: reserved.
19
20
22
23 A higher layer on an initiator device shall generate this primitive when it requires a link key to be established
24 with a responder device. If the initiator device wishes to use the responder’s parent as a liaison (for NWK
25 security purposes), it shall set the UseParent parameter to TRUE and shall set the ResponderParentAddress
26 parameter to the 64-bit extended address of the responder’s parent.
27
29
The receipt of an APSME-ESTABLISH-KEY.request primitive, with the KeyEstablishmentMethod
30
parameter equal to SKKE, shall cause the APSME to execute the SKKE protocol, described in sub-clause
31
3.5.2.6. The local APSME shall act as the initiator of this protocol, the APSME indicated by the
32
ResponderAddress parameter shall act as the responder of this protocol, and the UseParent parameter will
33
control whether the messages are sent indirectly via the responder’s parent device given by the
34
ResponderParentAddress parameter.
35
36
3.5.2.2 APSME-ESTABLISH-KEY.confirm
37
38 This primitive is issued to the ZDO upon completion or failure of a key-establishment protocol.
39
41
42 This primitive shall provide the following interface:
43
44 APSME-ESTABLISH-KEY.confirm {
45 Address,
Status
46
}
47
48
49 Table 145 specifies the parameters of the APSME-ESTABLISH-KEY.confirm primitive. Table 149 gives a
50 description of some codes that can be returned in the Status parameter of this primitive. In addition to these
51 codes, if when sending one of the protocol messages, an NLDE-DATA.confirm primitive with a Status
52
53
54

parameter set to a value other than SUCCESS is issued, the Status parameter of the APSME-ESTABLISH- 1
KEY.confirm primitive shall be set to that received from the NWK layer. 2
3
Table 145 APSME-ESTABLISH-KEY.confirm parameters 4
The extended 64-bit address of the device 6
Device 7
Address Any valid 64-bit address with which the key-establishment protocol
Address
was executed. 8
9
Value given by Table 149 or This parameter indicates the final status of
10
any status value returned the key-establishment protocol.
Status Enumeration 11
from the NLDE-DATA.con-
firm primitive. 12
13
14
16
The APSME in both the responder and initiator devices shall issue this primitive to the ZDO upon 17
completion of a key-establishment protocol. 18
19
21
If key establishment is successful, the AIB of the initiator and responder shall be updated with the new link
22
key and the initiator shall be able to securely communicate with the responder. If the key establishment was
23
not successful, then the AIB shall not be changed.
24
25
3.5.2.3 APSME-ESTABLISH-KEY.indication
26
The APSME in the responder shall issue this primitive to its ZDO when it receives an initial key- 27
establishment message (e.g., an SKKE-1 frame) from an initiator. 28
29
31
33
APSME-ESTABLISH-KEY.indication { 34
InitiatorAddress, 35
KeyEstablishmentMethod 36
} 37
38
Table 146 specifies the parameters of the APSME-ESTABLISH-KEY.indication primitive. 39
40
Table 146 APSME-ESTABLISH-KEY.indication parameters 41
Device Any valid 64-bit The extended 64-bit address of the initiator 43
InitiatorAddress 44
Address address device.
45
The requested key-establishment method 46
shall be one of the following:
47
KeyEstablishmentMethod Integer 0x00 - 0x03 48
0x00 = SKKE method.
49
0x01-0x03: reserved. 50
51
52
53
54


2
3 The APSME in the responder device shall issue this primitive to the ZDO when a request to start a key-
4 establishment protocol (e.g., an SKKE-1 frame) is received from an initiator and a master key associated
5 with the initiator device is present in the AIB.
6
8
Upon receiving the APSME-ESTABLISH-KEY.indication primitive, the ZDO may use the
9
KeyEstablishmentMethod and InitiatorAddress parameters to determine whether to establish a key with the
10
initiator. The ZDO shall respond using the APSME-ESTABLISH-KEY.response primitive.
11
12
3.5.2.4 APSME-ESTABLISH-KEY.response
13
14 The ZDO of the responder device shall use the APSME-ESTABLISH-KEY.response primitive to respond to
15 an APSME-ESTABLISH-KEY.indication primitive. The ZDO determines whether to continue with the key
16 establishment or halt it. This decision is indicated in the Accept parameter of the APSME-ESTABLISH-
17 KEY.response primitive.
18
20
22
23 APSME-ESTABLISH-KEY.response {
24 InitiatorAddress,
25 Accept
26 }
27
28 Table 147 specifies the parameters of the APSME-ESTABLISH-KEY.response primitive
29
30 Table 147 APSME-ESTABLISH-KEY.response parameters .
32 Device Any valid The extended 64-bit address of the device that
33 InitiatorAddress
Address 64-bit address initiated key establishment.
34
35 This parameter indicates the response to an ini-
tiator's request to execute a key-establishment
36
protocol. The response shall be either:
37 TRUE |
Accept Boolean
38 FALSE
TRUE = Accept.
39
40 FALSE = Reject.
41
42
44
The APSME-ESTABLISH-KEY.response primitive shall be generated by the ZDO and provided to the
45
APSME following a request from an initiator device to start a key-establishment protocol (i.e., after receipt
46
of an APSME-ESTABLISH-KEY.indication). This primitive provides the responder's ZDO with an
47
opportunity to determine whether to accept or reject a request to establish a key with a given initiator.
48
49
50
51 If the Accept parameter is TRUE, then the APSME of the responder will attempt to execute the key
52 establishment protocol indicated by the KeyEstablishmentMethod parameter. If KeyEstablishmentMethod is
53 equal to SKKE, the APSME shall execute the SKKE protocol, described in sub-clause 3.5.2.6. The local
54

APSME shall act as the responder of this protocol and the APSME indicated by the InitiatorAddress 1
parameter shall act as the initiator of this protocol. 2
3
If the Accept parameter is FALSE, the local APSME shall halt and erase all intermediate data pertaining to 4
the pending key-establishment protocol. 5
6
3.5.2.5 Data Service Message Sequence Chart 7
8
Figure 68 illustrates the sequence of primitives necessary for a successful key establishment between two
9
devices.
10
11
Initiator Responder 12
Device Device 13
14
ZDO APSME APSME ZDO 15
16
1. APSME-ESTABLISH-KEY.request 2. APSME-ESTABLISH-KEY.indication 17
3. APSME-ESTABLISH-KEY.response
18
19
SKKE
4. APSME-ESTABLISH-KEY.confirm Protocol 20
5. APSME-ESTABLISH-KEY.confirm
21
22
23
Figure 68 Sequence chart for successful APSME-ESTABLISH-KEY primitives 24
25
3.5.2.6 The SKKE Protocol 26
27
The APSME on the initiator and responder execute the symmetric-key key-agreement scheme instantiated in 28
B.2.1 and specified in B.7. The shared key, as specified in B.7 prerequisite step 2, shall be the master key 29
shared between the initiator and responder devices as obtained from the appropriate master key element in 30
the DeviceKeyPairSet attribute in the AIB. The messages sent during the scheme specified in B.7 shall be 31
assigned to the frame names given in Table 148. The formats for these SKKE frames are given in sub-clause 32
3.5.9.1. The initiator device is responsible for sending the SKKE-1 and SKKE-3 frames and the responder 33
device is responsible for sending the SKKE-2 and SKKE-4 frames. Additionally, if the UseParent parameter 34
to the APSME-ESTABLISH-KEY.request primitive is TRUE, the responder device’s parent (as indicated 35
by the ResponderParentAddress parameter to the APSME-ESTABLISH-KEY.request primitive) shall act as 36
a liaison and forward messages between the initiator and responder devices. 37
38
During the key-establishment scheme, if the responder or initiator device detects any error condition listed 39
in Table 149, the scheme shall be aborted and the local APSME shall issue the APSME-ESTABLISH- 40
KEY.confirm primitive with the Status parameter set as indicated in Table 149. If no error conditions occur 41
(i.e., the key-agreement scheme outputs 'valid'), then the initiator and responder shall consider the derived 42
key (i.e., KeyData) as their newly shared link key. Both the initiator and responder shall update or add this 43
link key to their AIB, set the corresponding incoming and outgoing frame counts to zero, and issue the 44
APSME-ESTABLISH-KEY.confirm primitive with the Status parameter set to SUCCESS. 45
Table 148 Mapping of frame names to symmetric-key key agreement scheme messages 46
47
Frame 48
Description Reference
Name
49
SKKE-1 Sent by initiator during action step 1. (B.7.1) 3.5.2.6.2 50
51
52
53
54

1 Table 148 Mapping of frame names to symmetric-key key agreement scheme messages
2
SKKE-2 Sent by responder during action step 2. (B.7.2) 3.5.2.6.3
3
4 SKKE-3 Sent by initiator during action step 11. (B.7.1) 3.5.2.6.4
5
6 SKKE-4 Sent by responder during action step 8. (B.7.2) 3.5.2.6.5
7
8
9
10 Table 149 Mapping of symmetric-key key agreement error conditions to status codes
11 Status Description Status Code Value
12
13 No errors occur SUCCESS 0x00
14 An invalid parameter was input to one of the key establish-
15 INVALID_PARAMETER 0x01
ment primitives.
16
17 No master key is available NO_MASTER_KEY 0x02
18 Challenge is invalid:
19 Initiator during action step 4. (B.7.1) INVALID_CHALLENGE 0x03
20 Responder during action step 1. (B.7.2)
21
SKG outputs invalid:
22
Initiator during action step 5. (B.7.1) INVALID_SKG 0x04
24
25 MAC transformation outputs invalid:
26 Initiator during action step 11. (B.7.1) INVALID_MAC 0x05
Responder during action step 7. (B.7.2)
27
28 Tag checking transformation outputs invalid:
29 Initiator during action step 9. (B.7.1) INVALID_KEY 0x06
31 Either the initiator or responder waits for an expected incom-
32 ing message for time greater than the apsSecurityTimeOut- TIMEOUT 0x07
33 Period attribute of the AIB.
34
Either the initiator or responder receives an SKKE frame out
35 BAD_FRAME 0x08
of order.
36
37
38 3.5.2.6.1 Generating and sending the initial SKKE-1 frame
39
40 The SKKE protocol begins with the initiator device sending an SKKE-1 frame. The SKKE-1 command
41 frame shall be constructed as specified in sub-clause 3.5.9.1.
42
43 If the UseParent parameter to the APSME-ESTABLISH-KEY.request primitive is FALSE, the initiator
44 device shall begin the protocol by sending this SKKE-1 frame directly to the responder device (as indicated
45 by the ResponderAddress parameter to the APSME-ESTABLISH-KEY.request primitive). Otherwise, the
46 initiator device shall begin the protocol by sending this SKKE-1 frame to the responder device’s parent (as
47 indicated by the ResponderParentAddress parameter to the APSME-ESTABLISH-KEY.request primitive).
48 The SKKE-1 frame shall be sent using the NLDE-DATA.request primitive with NWK layer security set to
49 the default NWK layer security level.
50
51 3.5.2.6.2 On receipt of the SKKE-1 frame
52
53 If the responder address field of the SKKE-1 frame does not equal the local device address, the APSME
54 shall perform the following steps:

1. If the device given by the responder address field is not a child of the local device, the SKKE-1 frame 1
shall be discarded. 2
3
2. Otherwise, the APSME of the local device shall send the SKKE-1 frame to the responder device using
4
the NLDE-DATA.request primitive, with the DestAddr parameter set to the 16-bit address
5
corresponding to the 64-bit address in the responder address field of the SKKE-1 frame, the
6
DiscoverRoute parameter set to 0x01180, and the SecurityEnable parameter set to FALSE. 7
3. Otherwise, the APSME shall perform the following steps: 8
9
4. If the device does not have a master key corresponding to the initiator address field, the SKKE-1 10
frame shall be discarded and the APSME-ESTABLISH-KEY.confirm primitive shall be issued with the 11
Status parameter set to NO_MASTER_KEY (see Table 149). The APSME should halt processing for 12
this SKKE protocol. 13
5. Otherwise, the APSME shall issue an APSME-ESTABLISH-KEY.indication primitive with the 14
InitiatorAddress parameter set to the initiator address field of the SKKE-1 frame and the 15
KeyEstablishmentMethod parameter set to 0 (i.e., the SKKE protocol). 16
17
6. After issuing the APSME-ESTABLISH-KEY.indication primitive, and upon receipt of the
18
corresponding APSME-ESTABLISH-KEY.response primitive, the APSME shall evaluate the
19
InitiatorAddress and Accept parameters of the received APSME-ESTABLISH-KEY.response
20
primitive. If the InitiatorAddress parameter is set to the initiator address of the SKKE-1 frame and the
21
Accept parameter set to FALSE, the APSME shall halt the SKKE protocol and discard the SKKE-1
22
frame.
23
7. Otherwise, it shall construct an SKKE-2 frame as specified in sub-clause 3.5.9.1. If the source of the 24
SKKE-1 frame indicates the same device as the initiator address field of the SKKE-1 frame, the device 25
shall send this SKKE-2 frame directly to the initiator device using the NLDE-DATA.request primitive, 26
with the DestAddr parameter set to the source of the SKKE-1 frame, the DiscoverRoute parameter set to 27
0x01181, and the SecurityEnable parameter set to TRUE. Otherwise, the device shall send the SKKE-2 28
frame to its parent using the NLDE-DATA.request primitive, with the DiscoverRoute parameter set to 29
182
, and the SecurityEnable parameter set to FALSE. 30
31
3.5.2.6.3 On receipt of the SKKE-2 frame 32
33
If the initiator address field of the SKKE-2 frame does not equal the local device address, the APSME shall 34
perform the following steps: 35
36
1. If the device given by the responder address field is not a child of the local device, the SKKE-2 frame 37
shall be discarded. 38
2. Otherwise, the device shall send the SKKE-2 to the initiator device using the NLDE-DATA.request 39
primitive with NWK layer set to the default level. 40
41
Otherwise, the device shall construct an SKKE-3 frame as specified in sub-clause 3.5.9.1. If the source of 42
the SKKE-2 frame is the same as the responder address field of the SKKE-2 frame, the device shall send this 43
SKKE-3 frame directly to the responder device. Otherwise, the device shall send the SKKE-3 frame to the 44
responder’s parent. The SKKE-3 frame shall be sent using the NLDE-DATA.request primitive with NWK 45
layer security set to the default NWK layer security level. 46
47
48
49
50
51
180
CCB Comment #256 52
181Ibid 53
182
Ibid 54

1 3.5.2.6.4 On receipt of the SKKE-3 frame

2
3 If the responder address field of the SKKE-3 frame does not equal the local device address, the APSME
4 shall perform the following steps:
5
1. If the device given by the responder address field is not a child of the local device, the SKKE-3 frame
6
shall be discarded.
7
8 2. Otherwise, the device shall send the SKKE-3 to the responder device using the NLDE-DATA.request
9 primitive with NWK layer security disabled.
10
11 Otherwise, the device shall process the SKKE-3 data field and if the protocol was not a success it shall issue
12 an APSME-ESTABLISH-KEY.confirm primitive with the Address parameter set to the initiator’s address
13 and the Status parameter set appropriately.
14
If, from the device’s perspective, the protocol was a success, the device shall construct an SKKE-4 frame as
15
specified in sub-clause 3.5.9.1. If the source of the SKKE-3 frame is the same as the initiator address field of
16
the SKKE-3 frame, the device shall send this SKKE-4 frame directly to the initiator device using the NLDE-
17
DATA.request primitive with NWK layer security set to the default level. Otherwise, the device shall send
18
the SKKE-4 frame to its parent using the NLDE-DATA.request primitive with NWK layer security
19
disabled. Finally, the device shall issue an APSME-ESTABLISH-KEY.confirm primitive with the Address
20
parameter set the initiator’s address and the Status parameter set to success.
21
22
3.5.2.6.5 On receipt of the SKKE-4 frame
23
24 If the initiator address field of the SKKE-4 frame does not equal the local device address, the APSME shall
25 perform the following steps:
26
27 1. If the device given by the responder address field is not a child of the local device, the SKKE-4 frame
28 shall be discarded.
29 2. Otherwise, the APSME of the local device shall send the SKKE-4 to the initiator device using the
30 NLDE-DATA.request primitive with NWK layer set to the default level.
31
32 Otherwise, the APSME shall process the SKKE-4 frame and issue an APSME-ESTABLISH-KEY.confirm
33 primitive with the Address parameter set the responder’s address and the Status parameter set appropriately.
34
35
36 3.5.3 Transport-Key Services
37
The APSME provides services that allow an initiator to transport keying material to a responder. The
38
different types of keying material that can be transported are shown in Table 151.
39
40
3.5.3.1 APSME-TRANSPORT-KEY.request
41
42 The APSME-TRANSPORT-KEY.request primitive is used for transporting a key to another device.
43
45
47
48 APSME-TRANSPORT-KEY.request {
49 DestAddress,
50 KeyType,
51 TransportKeyData
}
52
53
54

Table 150 specifies the parameters for the APSME-TRANSPORT-KEY.request primitive. 1

2
Table 150 APSME-TRANSPORT-KEY.request parameters 3
Device Any valid The extended 64-bit address of the destination 5
DestAddress 6
address 64-bit address device.
7
Identifies the type of key material that should 8
KeyType Integer 0x00 – 0x03
be transported. See Table 151.
9
The key being transported along with identifi- 10
cation and usage parameters. The type of this 11
parameter depends on the KeyType parameter 12
as follows: 13
KeyType = 0x00 see Table 152 14
TransportKeyData Variable Variable 15
17
20
21
22
23
Table 151 KeyType parameter of the transport-key primitive 24
Enumeration Value Description 25
26
Indicates the key is a master key which is used to set up link keys
Trust-center master key 0x00 27
between the trust center and another device.
28
Network key 0x01 Indicates the key is a Network key. 29
30
Indicates the key is a master key which is used to set up link keys
Application master key 0x02 31
between two devices.
32
Indicates the key is a link key which is used as a basis of security 33
Application link key 0x03
between two devices. 34
35
36
37
Table 152 TransportKeyData parameter for a trust-center master key 38
39
The extended 64-bit address of the parent of the 41
Device Any valid
ParentAddress destination device given by the DestAddress 42
address 64-bit address
parameter. 43
TrustCenter-Master- Set of 16 The trust center master key. 44
Variable 45
Key octets
46
47
48
49
50
51
52
53
54

1
2
3 Table 153 TransportKeyData parameter for a Network key
4 Parameter Name Type Valid Range Description
5 A sequence number assigned to a Network key by
6 the trust center and used to distinguish Network
KeySeqNumber Octet 0x00-0xFF
7 keys for purposes of key updates, and incoming
8 frame security operations.
9
Set of 16 The Network key.
10 NetworkKey Variable
octets
11
12 This parameter indicates if the destination device’s
13 parent shall be used to forward the key to the des-
tination device:
14 UseParent Boolean TRUE | FALSE
15 TRUE: Use parent
16
17 FALSE: Do not use parent
18
If the UseParent is TRUE, then ParentAddress
19 parameter shall contain the extended 64-bit
20 Device Any valid 64-bit
ParentAddress address of the destination device’s parent device.
address address
21 Otherwise, this parameter is not used and need not
22 be set.
23
24
25
26 Table 154 TransportKeyData parameter for an application master or link key
27
Parameter Name Type Valid Range Description
28
29 Device Any valid 64-bit The extended 64-bit address of the device that was
PartnerAddress
30 address address also sent this master key.
31
This parameter indicates if the destination device of
32 this master key requested it:
33
Initiator Boolean TRUE | FALSE
34 TRUE: If the destination requested the key.
35
FALSE: otherwise.
36
37 Set of 16 The master or link key (as indicated by the Key-
Key Variable
38 octets Type parameter).
39
40
42
43 The ZDO on an initiator device shall generate this primitive when it requires a key to be transported to a
44 responder device.
45
47
The receipt of an APSME-TRANSPORT-KEY.request primitive shall cause the APSME to create a
48
transport-key command packet (see sub-clause 3.5.9.2)
49
50 If the KeyType parameter is 0x00 (i.e., trust center master key), the key descriptor field of the transport-key
51 command shall be set as follows. The key sub-field shall be set to the Key sub-parameter of the
52 TransportKeyData parameter, the destination address sub-field shall be set to the DestinationAddress
53 parameter, and the source address sub-field shall be set to the local device address. This command frame
54 shall be security protected as specified in sub-clause 3.5.1.1 and then, if security processing succeeds, sent to

the device specified by the ParentAddress sub-parameter of the TransportKeyData parameter by issuing a 1
NLDE-DATA.request primitive. 2
3
If the KeyType parameter is 0x01 (i.e., Network key), the key descriptor field of the transport-key command 4
shall be set as follows. The key sub-field shall be set to the Key sub-parameter of the TransportKeyData 5
parameter, the sequence number sub-field shall be set to the KeySeqNumber sub-parameter of the 6
TransportKeyData parameter, the destination address sub-field shall be set to the DestinationAddress 7
parameter, and the source address sub-field shall be set to the local device address. This command frame 8
shall be security protected as specified in sub-clause 3.5.1.1 and then, if security processing succeeds, sent to 9
the device specified by the ParentAddress sub-parameter of the TransportKeyData parameter (if the 10
UseParent sub-parameter of the TransportKeyData parameter is TRUE183) or the DestinationAddress 11
parameter (if the UseParent sub-parameter of the TransportKeyData parameter is FALSE184) by issuing a 12
NLDE-DATA.request primitive. 13
14
If the KeyType parameter is 0x02 or 0x03 (i.e., an application master or link key), the key descriptor field of
15
the transport-key command shall be set as follows. The key sub-field shall be set to the Key sub-parameter of
16
the TransportKeyData parameter, the partner address sub-field shall be set to the PartnerAddress sub-
17
parameter of the TransportKeyData parameter, and the initiator sub-field shall be set 1 (if the Initiator sub-
18
parameter of the TransportKeyData parameter is TRUE) or 0 (if the Initiator sub-parameter of the
19
TransportKeyData parameter is FALSE). This command frame shall be security protected as specified in
20
sub-clause 3.5.1.1 and then, if security processing succeeds, sent to the device specified by the
21
DestinationAddress parameter by issuing a NLDE-DATA.request primitive.
22
23
3.5.3.2 APSME-TRANSPORT-KEY.indication
24
The APSME-TRANSPORT-KEY.indication primitive is used to inform the ZDO of the receipt of keying 25
material. 26
27
29
31
APSME-TRANSPORT-KEY.indication { 32
SrcAddress, 33
KeyType, 34
TransportKeyData 35
}
36
37
Table 155 specifies the parameters of the APSME-TRANSPORT-KEY.indication primitive. 38
39
Table 155 APSME-TRANSPORT-KEY.indication parameters
40
42
43
44
45
46
47
48
49
50
51
52
184
Ibid 54

1 Table 155 APSME-TRANSPORT-KEY.indication parameters

2
Device Any valid 64-bit The extended 64-bit address of the device that is the
3 SrcAddress
Address address original source of the transported key.
4
5 Identifies the type of key material that was be trans-
KeyType Octet 0x00 – 0x03
6 ported. See Table 151.
7 The key that was transported along with identifica-
8 tion and usage parameters. The type of this parame-
9 ter depends on the KeyType parameter as follows:
10
11 KeyType = 0x00 see Table 156.
TransportKeyData Variable Variable
13
15
17
18
19
20 Table 156 TransportKeyData parameter for a trust-center master key
22
23 TrustCenter-Master- Set of 16 The trust center master key.
Variable
Key octets
24
25
26
27
28 Table 157 TransportKeyData parameter for a Network key
29
30
31 A sequence number assigned to a Network key by
32 the trust center and used to distinguish Network
KeySeqNumber Octet 0x00-0xFF
keys for purposes of key updates, and incoming
33 frame security operations.
34
35 Set of 16 The Network key.
NetworkKey Variable
36 octets
37
38
40
The APSME shall generate this primitive when it receives a transport-key command that is successfully
41
decrypted and authenticated, as specified in sub-clause 3.5.1.2, that has the key type field set to 2 or 3 (i.e.,
42
application link or master key).
43
44 Alternatively, the APSME shall generate this primitive when it receives a transport-key command that is
45 successfully decrypted and authenticated, as specified in sub-clause 3.5.1.2, that has the key type field set to
46 0 or 1 (i.e., a trust center master key or Network key) and the destination address sub-field of the key
47 descriptor field is equal to the local address.
48
50
51 Upon receipt of this primitive, the ZDO is informed of the receipt of the keying material.
52
53
54

3.5.3.3 Upon Receipt of a Transport-Key Command 1

2
Upon receipt of a transport-key command, the APSME shall execute security processing as specified in sub- 3
clause 3.5.1.2 and then check the key type sub-field. 4
5
If the key type field is set to 2 or 3 (i.e., application link or master key), the APSME shall issue the APSME-
6
TRANSPORT-KEY.indication185 primitive with the SrcAddress parameter set to the source of the key-
7
transport command (as indicated by the NLDE-DATA.indication SrcAddress parameter), the KeyType
8
parameter set to the key type field. The TransportKeyData parameter shall be set as follows: the Key sub-
9
parameter shall be set to the key field, PartnerAddress sub-parameter shall be set to the partner address field,
10
the Initiator parameter shall be set to TRUE if the initiator field is 1, otherwise 0.
11
If the key type field is set to 0 or 1 (i.e., trust center master key or NWK key186) and the destination address 12
field is equal to the local address, the APSME shall issue the APSME-TRANSPORT-KEY.indication187 13
primitive. The SrcAddress parameter set to the source address field of the key-transport command, the 14
KeyType parameter set to the key type field. The TransportKeyData parameter shall be set as follows: the 15
Key sub-parameter shall be set to the key field and, in the case of a Network key (i.e., the key type field is set 16
to 1), the KeySeqNumber sub-parameter shall be set to the sequence number field. 17
18
If the key type field is set to 0 or 1 (i.e., trust center master key or NWK key188) and the destination address 19
field is not equal to the local address, the APSME shall send the command to the address indicated by the 20
destination address field by issuing the NLDE-DATA.request primitive with security disabled. 21
22
Upon receipt of an unsecured transport-key command, the APSME shall check the key type sub-field. If the 23
key type field is set to 0 (i.e., a trust center master key), the destination address field is equal to the local 24
address, and the device does not have a trust center master key and address (i.e., the apsTrustCenterAddress 25
in the AIB), then the APSME shall issue the APSME-TRANSPORT-KEY.indication primitive. Also, if the 26
key type field is set to 1 (i.e., Network key), the destination address field is equal to the local address, and 27
the device does not have a Network key, then the APSME shall issue the APSME-TRANSPORT- 28
KEY.indication primitive. If an APSME-TRANSPORT-KEY.indication primitive is issued, the SrcAddress 29
parameter shall be set to the source address field of the key-transport command, and the KeyType parameter 30
shall be set to the key type field. The TransportKeyData parameter shall be set as follows: the Key sub- 31
parameter shall be set to the key field and, in the case of a Network key (i.e., the key type field is set to 1), 32
the KeySeqNumber sub-parameter shall be set to the sequence number field.189 33
34
3.5.4 Update-Device Services 35
36
The APSME provides services that allow a device (e.g., a router) to inform another device (e.g., a trust 37
center) that a third device has changed its status (e.g., joined or left the network). 38
39
3.5.4.1 APSME-UPDATE-DEVICE.request 40
41
The ZDO shall issue this primitive when it wants to inform a device (e.g., a trust center) that another device 42
has a status that needs to be updated (e.g., the device joined or left the network). 43
44
45
46
47
48
49
186
CCB Comment #162 51
187
CCB Comment #163 52
189
CCB Comment #161 54


2
4
5 APSME-UPDATE-DEVICE.request {
6 DestAddress,
7 DeviceAddress,
Status,
8 DeviceShortAddress
9 }
10
11
Table 158 specifies the parameters for the APSME- UPDATE-DEVICE.request primitive.
12
13 Table 158 APSME-UPDATE-DEVICE.request parameters
14
15
16 Device Any valid 64-bit The extended 64-bit address of the device that
DestAddress
17 Address address shall be sent the update information.
18
Device Any valid 64-bit The extended 64-bit address of the device
19 DeviceAddress
Address address whose status is being updated.
20
21 Indicates the updated status of the device
22 given by the DeviceAddress parameter.
23 0x00: device secured join.
24
Status Integer 0x00 – 0x08
25 0x01: device unsecured join.
26
27 0x02: device left.
28 0x03-0x08 reserved.
29
30 Network The 16-bit network address of the device
DeviceShortAddress 0x0000 - 0xffff
31 address whose status is being updated.a
32 aCCB
Comment
33
34
36
37 The ZDO (e.g., on a router or coordinator) shall initiate the APSME-UPDATE-DEVICE.request primitive
38 when it wants to send updated device information to another device (e.g., the trust center).
39
41
Upon receipt of the APSME-UPDATE-DEVICE.request primitive the device shall first create an update-
42
device command frame (see sub-clause 3.5.9.4). The device address field of this command frame shall be set
43
to the DeviceAddress parameter and the status field shall be set according to the Status parameter and the
44
device short address field shall be set to the DeviceShortAddress parameter190. This command frame shall
45
be security protected as specified in sub-clause 3.5.1.1 and then, if security processing succeeds, sent to the
46
device specified by the DestAddress parameter by issuing a NLDE-DATA.request primitive.
47
48
3.5.4.2 APSME-UPDATE-DEVICE.indication
49
50 The APSME shall issue this primitive to inform the ZDO that it received an update-device command frame.
51
52
53
190
54 CCB Comment #142


2
4
APSME-UPDATE-DEVICE.indication { 5
SrcAddress, 6
DeviceAddress, 7
Status,
DeviceShortAddress 8
} 9
10
11
Table 159 specifies the parameters for the APSME-UPDATE-DEVICE.indication primitive.
12
Table 159 APSME-UPDATE-DEVICE.indication parameters 13
14
15
Device Any valid 64-bit The extended 64-bit address of the device 16
SrcAddress
Address address originating the update-device command. 17
18
DeviceAddress 19
Address address whose status is being updated.
20
Indicates the updated status of the device 21
given by the DeviceAddress parameter. 22
0x00: device secured join. 23
24
Status Octet 0x00 – 0xFF
0x01: device unsecured join. 25
26
0x02: device left. 27
0x03-0xFF reserved. 28
29
Network The 16-bit network address of the device 30
DeviceShortAddress 0x0000 - 0xffff
address whose status is being updated.a 31
aCCB 32
Comment #142
33
34
36
The APSME shall generate this primitive when it receives an update-device command frame that is 37
successfully decrypted and authenticated, as specified in sub-clause 3.5.1.2. 38
39
41
Upon receipt of the APSME-UPDATE-DEVICE.indication primitive the ZDO will be informed that the
42
device referenced by the DeviceAddress parameter has undergone a status update according to the Status
43
parameter.
44
45
3.5.5 Remove Device Services 46
47
The APSME provides services that allow a device (e.g., a trust center) to inform another device (e.g., a 48
router) that one of its children should be removed from the network. 49
50
51
52
53
54

1 3.5.5.1 APSME-REMOVE-DEVICE.request
2
3 The ZDO of a device (e.g., a trust center) shall issue this primitive when it wants to request that a parent
4 device (e.g., a router) remove one of its children from the network. For example, a trust center can use this
5 primitive to remove a child device that fails to authenticate properly.
6
8
This primitive shall provide the following interface:
9
10
11 APSME-REMOVE-DEVICE.request {
ParentAddress,
12
ChildAddress
13 }
14
15
Table 160 specifies the parameters for the APSME-REMOVE-DEVICE.request primitive.
16
17 Table 160 APSME- REMOVE-DEVICE.request parameters
18
20 The extended 64-bit address of the device that
Device Any valid 64-bit
21 ParentAddress is the parent of the child device that is
Address address
22 requested to be removed.
23 Device Any valid 64-bit The extended 64-bit address of the child
24 ChildAddress
Address address device that is requested to be removed.
25
26
28
29 The ZDO (e.g., on a trust) shall initiate the APSME-REMOVE-DEVICE.request primitive when it wants to
30 request that a parent device (specified by the ParentAddress parameter) remove one of its child devices (as
31 specified by the ChildAddress parameter).
32
34
35 Upon receipt of the APSME-REMOVE-DEVICE.request primitive the device shall first create a remove-
36 device command frame (see sub-clause 3.5.9.4). The child address field of this command frame shall be set
37 to the ChildAddress parameter. This command frame shall be security protected as specified in sub-clause
38 3.5.1.1 and then, if security processing succeeds, sent to the device specified by the ParentAddress
39 parameter by issuing a NLDE-DATA.request primitive.
40
41 3.5.5.2 APSME-REMOVE-DEVICE.indication
42 The APSME shall issue this primitive to inform the ZDO that it received a remove-device command frame.
43
45
47
48 APSME-REMOVE-DEVICE.indication {
49 SrcAddress,
50 ChildAddress
51 }
52
53
54

Table 161 specifies the parameters for the APSME-REMOVE-DEVICE.indication primitive. 1

2
Table 161 APSME-REMOVE-DEVICE.indication parameters 3
5
SrcAddress 6
Address address requesting that a child device be removed.
7
Device Any valid 64-bit The extended 64-bit address of the child 8
ChildAddress
Address address device that is requested to be removed. 9
10
11
13
The APSME shall generate this primitive when it receives a remove-device command frame that is
14
successfully decrypted and authenticated, as specified in sub-clause 3.5.1.2.
15
16
17
Upon receipt of the APSME-REMOVE-DEVICE.indication primitive the ZDO shall be informed that the 18
device referenced by the SrcAddress parameter is requesting that the child device referenced by the 19
ChildAddress parameter be removed from the network. 20
21
22
3.5.6 Request Key Services 23
24
The APSME provides services that allow a device to request the current Network key or a master key from 25
another device (e.g., its trust center). 26
27
3.5.6.1 APSME-REQUEST-KEY.request 28
29
This primitive allows the ZDO to request either the current Network key or a new end-to-end application
30
master key.
31
32
33
35
36
APSME-REQUEST-KEY.request {
DestAddress, 37
KeyType, 38
PartnerAddress 39
} 40
41
Table 162 specifies the parameters for the APSME-REQUEST-KEY.request primitive. 42
43
Table 162 APSME-REQUEST-KEY.request parameters 44
46
The extended 64-bit address of the device to
Device Any valid 64-bit 47
DestAddress which the request-key command should be
Address address 48
sent.
49
50
51
52
53
54

1 Table 162 APSME-REQUEST-KEY.request parameters

2
The type of key being requested:
3 0x01 = Network key
4 KeyType Octet 0x00-0xFF
0x02 = Application key
5 0x00 and 0x03-0xFF = Reserved
6
In the case that KeyType parameter indicates
7
an application key, this parameter shall indi-
8 Device Any valid 64-bit
PartnerAddress cate an extended 64-bit address of a device
9 Address address
that shall receive the same key as the device
10 requesting the key.
11
12
14
The ZDO of a device shall generate the APSME-REQUEST-KEY.request primitive when it requires either
15
the current Network key or a new end-to-end application master key.
16
17
18
19 Upon receipt of the APSME-REQUEST-KEY.request primitive the device shall first create a request-key
20 command frame (see sub-clause 3.5.9.6). The key type field of this command frame shall be set to the same
21 value as the KeyType parameter. If the KeyType parameter is 0x02 (i.e., an application key), then the partner
22 address field of this command frame shall be the PartnerAddress parameter. Otherwise, the partner address
23 field of this command frame shall not be present.
24
25 This command frame shall be security protected as specified in sub-clause 3.5.1.1 and then, if security
26 processing succeeds, sent to the device specified by the DestAddress parameter by issuing a NLDE-
27 DATA.request primitive.
28
29 3.5.6.2 APSME-REQUEST-KEY.indication
30
31 The APSME shall issue this primitive to inform the ZDO that it received a request-key command frame.
32
34
This primitive shall provide the following interface:
35
36
37 APSME-REQUEST-KEY.indication {
SrcAddress,
38 KeyType,
39 PartnerAddress
40 }
41
42 Table 163 specifies the parameters for the APSME-REQUEST-KEY.indication primitive.
43
44 Table 163 APSME-REQUEST-KEY.indication parameters
45
46
SrcAddress
48 Address address sent the request-key command.
49
50
51
52
53
54

Table 163 APSME-REQUEST-KEY.indication parameters 1

2
The type of key being requested:
0x01 = Network key 3
KeyType Octet 0x00-0xFF 4
0x02 = Application key
0x00 and 0x03-0xFF = Reserved 5
6
In the case that KeyType parameter indicates
7
an application key, this parameter shall indi-
Device Any valid 64-bit 8
PartnerAddress cate an extended 64-bit address of a device
Address address 9
that shall receive the same key as the device
requesting the key. 10
11
12
14
The APSME shall generate this primitive when it receives a request-key command frame that is successfully
15
decrypted and authenticated, as specified in sub-clause 3.5.1.2.
16
17
18
Upon receipt of the APSME-REQUEST-KEY.indication primitive the ZDO shall be informed that the 19
device referenced by the SrcAddress parameter is requesting a key. The type of key being requested shall be 20
indicated by the KeyType parameter and if the KeyType parameter is 0x02 (i.e., an application key), the 21
PartnerAddress parameter shall indicate a partner device that shall receive the same key as the device 22
requesting the key (i.e., the device indicated by the SrcAddress parameter). 23
24
25
3.5.7 Switch Key Services 26
27
The APSME provides services that allow a device (e.g., a trust center) to inform another device that it 28
should switch to a new active Network key. 29
30
3.5.7.1 APSME-SWITCH-KEY.request 31
This primitive allows a device (e.g., the trust center) to request that another device switch to a new active 32
Network key. 33
34
36
38
APSME-SWITCH-KEY.request { 39
DestAddress, 40
KeySeqNumber 41
} 42
43
Table 164 specifies the parameters for the APSME-SWITCH-KEY.request primitive. 44
45
Table 164 APSME-SWITCH-KEY.request parameters 46
48
Device Any valid 64-bit The extended 64-bit address of the device to 49
DestAddress
Address address which the switch-key command is sent.
50
A sequence number assigned to a Network 51
KeySeqNumber Octet 0x00-0xFF key by the trust center and used to distinguish 52
Network keys. 53
54


2
3 The ZDO of a device (e.g., the trust center) shall generate the APSME-SWITCH-KEY.request primitive
4 when it wants to inform a device to switch to a new active Network key.
5
7
Upon receipt of the APSME-SWITCH-KEY.request primitive the device shall first create a switch-key
8
command frame (see sub-clause 3.5.9.7). The sequence number field of this command frame shall be set to
9
the same value as the KeySeqNumber parameter.
10
11 This command frame shall be security protected as specified in sub-clause 3.5.1.1 and then, if security
12 processing succeeds, sent to the device specified by the DestAddress parameter by issuing a NLDE-
13 DATA.request primitive.
14
15 3.5.7.2 APSME-SWITCH-KEY.indication
16
17 The APSME shall issue this primitive to inform the ZDO that it received a switch-key command frame.
18
20
22
23 APSME-SWITCH-KEY.indication {
24 SrcAddress,
25 KeySeqNumber
}
26
27
28 ATable 165 specifies the parameters for the APSME-SWITCH-KEY.indication primitive.
29
30 Table 165 APSME-SWITCH-KEY.indication parameters
33 SrcAddress
Address address sent the switch-key command.
34
35 A sequence number assigned to a Network key
KeySeqNumber Octet 0x00-0xFF by the trust center and used to distinguish Net-
36
work keys.
37
38
39
40
42
43 The APSME shall generate this primitive when it receives a switch-key command frame that is successfully
44 decrypted and authenticated, as specified in sub-clause 3.5.1.2.
45
47
48 Upon receipt of the APSME-SWITCH-KEY.indication primitive the ZDO shall be informed that the device
49 referenced by the SrcAddress parameter is requesting that the Network key referenced by the
50 KeySeqNumber parameter become the new active Network key.
51
52
53
54

3.5.8 Secured APDU Frame 1

2
The APS layer frame format from [B7] consists of APS header and APS payload fields. The APS header 3
consists of frame control and addressing fields. When security is applied to an APDU frame, the security bit 4
in the APS frame control field shall be set to 1 to indicate the presence of the auxiliary frame header. The 5
format for the auxiliary frame header is given in sub-clause 3.6.1. The format of a secured APS layer frame 6
is shown in Table 69. The auxiliary frame header is situated between the APS header and payload fields. 7
8
Figure 69 Secured APS layer frame format 9
Octets: variable 5 or 6 Variable 10
11
Auxiliary Encrypted Message
Original APS Header Encrypted Payload 12
frame Integrity Code (MIC)
([B7], Clause 7.1) 13
header Secure frame payload = Output of CCM* 14
15
Full APS header Secured APS payload
16
17
18
3.5.9 Command Frames 19
The APS layer command frame formats are given in this clause. 20
21
Command identifier values are shown in Table 166)191. 22
23
Table 166 Command identifier values 24
Command identifier Value 25
26
APS_CMD_SKKE_1 0X01 27
29
31
APS_CMD_SKKE_4 0X04
32
APS_CMD_TRANSPORT_KEY 0X05 33
34
APS_CMD_UPDATE_DEVICE 0X06
35
APS_CMD_REMOVE_DEVICE 0X07 36
37
APS_CMD_REQUEST_KEY 0X08 38
APS_CMD_SWITCH_KEY 0X09 39
40
41
3.5.9.1 Key-Establishment Commands 42
43
The APS command frames used during key establishment is specified in this clause. The optional fields of 44
the APS header portion of the general APS frame format shall not be present. 45
46
47
48
49
50
51
52
53
191
CCB Comment #205 54

1 The generic SKKE command frame shall be formatted as illustrated in Table 70.
2
3 Figure 70 Generic SKKE frame command format
4 Octets: 1 1 8 8 16
5
Command Initiator Responder
6 Frame control Data
identifier Address Address
7
8 APS Header Payload
9
10
11 3.5.9.1.1 Command identifier field
12
13 The command identifier field shall indicate the APS command type. For SKKE frames, the command
14 identifier shall indicate either an SKKE-1, SKKE-2, SKKE-3, or SKKE-4 frame, depending on the frame
15 type (see Table 166)192.
16
17 3.5.9.1.2 Initiator address field
18
The initiator address field shall be the 64-bit extended address of the device that acts as the initiator in the
19
key-establishment protocol.
20
21
3.5.9.1.3 Responder address field
22
23 The responder address field shall be the 64-bit extended address of the device that acts as the responder in
24 the key-establishment protocol.
25
26 3.5.9.1.4 Data field
27
28 The content of the data field depends on the command identifier field (i.e., SKKE-1, SKKE-2, SKKE-3, or
29 SKKE-4). The following clauses describe the content of the data field for each command type.
30
31 3.5.9.1.4.1 SKKE-1 frame
32
33 The data field shall be the octet representation of the challenge QEU generated by the initiator during action
34 step 1. of clause B.7.1.
35
36 3.5.9.1.4.2 SKKE-2 frame
37
The data field shall be the octet representation of the challenge QEV generated by the responder during
38
action step 2. of clause B.7.2.
39
40
3.5.9.1.4.3 SKKE-3 frame
41
42 The data field shall be the octet representation of the string MacTag2 generated by the initiator during action
43 step 11. of clause B.7.1.
44
45 3.5.9.1.4.4 SKKE-4 frame
46
47 The data field shall be the octet representation of the string MacTag1 generated by the responder during
48 action step 7. of clause B.7.2.
49
50
51
52
53
192
54 Ibid

3.5.9.2 Transport-Key Commands 1

2
The transport-key command frame shall be formatted as illustrated in Table 71. The optional fields of the 3
APS header portion of the general APS frame format shall not be present. 4
5
Figure 71 Transport-key command frame 6
Octets: 1 1 1 variable 7
APS command 8
Frame control Key Type Key descriptor 9
identifier
10
APS Header Payload 11
12
13
3.5.9.3 Command identifier field 14
15
This field is 8-bits in length shall be set to indicate that this is a transport-key command frame (see
16
Table 166)193.
17
18
3.5.9.3.1 Key type field
19
This field is 8-bits in length and describes the type of key being transported. The different types of keys are 20
enumerated in Table 151. 21
22
3.5.9.3.2 Key descriptor field 23
24
This field is variable in length and shall contain the actual (unprotected) value of the transported key along 25
with any relevant identification and usage parameters. The information in this field depends on the type of 26
key being transported (as indicated by the key type field – see sub-clause 3.5.9.3.1) and shall be set to one of 27
the formats described in the following subsections. 28
29
3.5.9.3.2.1 Trust center master key descriptor field 30
31
If the key type field is set to 0, the key descriptor field shall be formatted as shown in Table 72. 32
33
Figure 72 Trust center master key descriptor field in transport-key command
34
Octets: 16 8 8 35
Key Destination address Source address 36
37
38
The key sub-field shall contain the master key that should be used to set up link keys with the trust center. 39
40
The destination address sub-field shall contain the address of the device which should use this master key. 41
42
The source address sub-field shall contain the address of the device (e.g., the trust center) which originally 43
sent this master key. 44
45
46
47
48
49
50
51
52
53
193
CCB Comment #205 54

1 3.5.9.3.2.2 Network key descriptor field

2
3 If the key type field is set to 1, this field shall be formatted as shown in Table 73.
4
5 Figure 73 Network key descriptor field in transport-key command
6 Octets: 16 1 8 8
7 Key Sequence number Destination address Source address
8
9
10 The key sub-field shall contain a Network key.
11
12 The sequence number sub-field shall contain the sequence number associated with this Network key.
13
14 The destination address sub-field shall contain the address of the device which should use this Network key.
15
The source address field sub-shall contain the address of the device (e.g., the trust center) which originally
16
sent this Network key.
17
18
3.5.9.3.2.3 Application master and link key descriptor field
19
20 If the key type field is set to 2 or 3, this field shall be formatted as shown in Table 74.
21
22 Figure 74 Application master key descriptor in transport-key command
23
Octets: 16 8 1
24
25 Key Partner address Initiator flag
26
27
28 The key sub-field shall contain a master or link key that is shared with the device identified in the partner
29 address field.
30
The partner address sub-field shall contain the address of the other device that was sent this link or master
31
key.
32
33 The initiator flag sub-field shall be set to 1 if the device receiving this packet requested this key. Otherwise,
34 this sub-field shall be set to 0.
35
36 3.5.9.4 Update-Device Commands
37
38 The APS command frame used for device updates is specified in this clause. The optional fields of the APS
39 header portion of the general APS frame format shall not be present.
40
41 The update-device command frame shall be formatted as illustrated in Table 75.
42
43 Figure 75 Update-device command frame format
44 Octets: 1 1 8 2 1
45 Device short
46 Frame control Command identifier Device Address Status
addressa
47
50
51
53
54 The command identifier field shall indicate the APS command type update-device (see Table 166)194.

3.5.9.4.2 Device address field 1

2
The device address field shall be the 64-bit extended address of the device whose status is being updated. 3
4
3.5.9.4.3 Device short address field 5
6
The device short address field shall be the 16-bit network address of the device whose status is being
7
updated.195
8
9
3.5.9.4.4 Status field
10
The status field shall be assigned a value as described for the Status parameter in Table 149.196 11
12
3.5.9.5 Remove Device Commands 13
14
The APS command frame used for removing a device is specified in this clause. The optional fields of the 15
APS header portion of the general APS frame format shall not be present. 16
17
The remove-device command frame shall be formatted as illustrated in Table 76. 18
19
Figure 76 Remove-device command frame format 20
Octets: 1 1 8 21
Frame control Command identifier Child address 22
23
25
26
3.5.9.5.1 Command identifier field 27
28
The command identifier field shall indicate the APS command type remove-device (see Table 166)197. 29
30
3.5.9.5.2 Child address field 31
The child address field shall be the 64-bit extended address of the device that is requested to be removed 32
from the network. 33
34
3.5.9.6 Request-Key Commands 35
36
The APS command frame used by a device for requesting a key is specified in this clause. The optional 37
fields of the APS header portion of the general APS frame format shall not be present. 38
39
The request-key command frame shall be formatted as illustrated in Figure 77 40
41
Figure 77 Request-key command frame format 42
Octets: 1 1 1 0/8a 43
44
Frame control Command identifier Key type Partner address 45
47
49
50
194
CCB Comment #205 51
195
CCB Comment #142 52
197
CCB Comment #205 54


2
3 The command identifier field shall indicate the APS command type request-key (see Table 166)198.
4
5 3.5.9.6.2 Key type field
6
The key type field shall be set to 1 when the Network key is being requested and shall be set to 2 when an
7
application key is being requested.
8
9
3.5.9.6.3 Partner address field
10
11 When the key type field is 2 (i.e., an application key), the partner address field shall contain the extended 64-
12 bit address of the partner device that shall be sent the key. Both the partner device and the device originating
13 the request-key command will be sent the key.
14
15 When the key-type field is 1 (i.e., Network key), the partner address field will not be present.
16
17 3.5.9.7 Switch-Key Commands
18
19 The APS command frame used by a device for requesting a key is specified in this clause. The optional
20 fields of the APS header portion of the general APS frame format shall not be present.
21
The switch-key command frame shall be formatted as illustrated in Table 78.
22
23 Figure 78 Switch-key command frame format
24
25 Octets: 1 1 1
26 Frame control Command identifier Sequence number
27
29
30
32 The command identifier field shall indicate the APS command type switch-key (see Table 166)199.
33
34 3.5.9.7.2 Sequence number field
35
36 The sequence number field shall contain the sequence number identifying the Network key to make active.
37
38
39 3.5.10 Security-Related AIB Attributes
40
The AIB contains attributes that are required to manage security for the APS layer. Each of these attributes
41
can be read or written using the APSME-GET.request and APSME-SET.request primitives, respectively.
42
The security-related attributes contained in the APS PIB are presented in Table 167 and Table 168.
43
44 Table 167 AIB security attributes
45
46 Attribute Identifier Type Range Description Default
47 Set of Key- A set of key-pair
48 Pair Descrip- descriptors containing
49 apsDeviceKeyPairSet 0xaaa tor entries. Variable master and link key -
See pairs shared with other
50
Table 168 devices.
51
52
53 198Ibid
199
54 CCB Comment #205

Table 167 AIB security attributes 1

2
Any valid Identifies the address
Device 3
apsTrustCenterAddress 0xabb 64-bit of the device’s trust -
address 4
address center
5
The period of time a 6
device will wait for an
apsSecurityTime-OutPe- 0x0000- 7
0xacc Integer expected security pro- 1000
riod 0xFFFF 8
tocol frame (in milli-
seconds). 9
10
a
CCB Comment #150 11
b
Ibid
c 12
Ibid
13
14
15
16
Table 168 Elements of the key-pair descriptor 17
Name Type Range Description Default 18
19
DeviceAddress Device Any valid 64-bit Identifies the address of the entity with -
address address which this key-pair is shared. 20
21
MasterKey Set of 16 - The actual value of the master key. - 22
octets 23
LinkKey Set of 16 - The actual value of the link key. - 24
octets 25
26
OutgoingFrame- Set of 4 0x00000000- Unique identifier of the key originating 0x00000000 27
Counter octets 0xFFFFFFFF with the device indicated by KeySr-
cAddress. 28
29
IncomingFrame- Set of 4 0x00000000- Incoming frame counter value corre- 0x00000000 30
Counter octets 0xFFFFFFFF sponding to DeviceAddress. 31
32
33
3.6 Common Security Elements 34
35
36
This clause describes security-related features that are used in more than one ZigBee layer. The NWK and 37
APS layers shall use the auxiliary header as specified in sub-clause 3.6.1. The MAC, NWK, and APS layers 38
shall use the security parameters specified in sub-clause 3.6.2. The formatting of all frames and fields in this 39
specification are depicted in the order in which they are transmitted by the NWK layer, from left to right, 40
where the leftmost bit is transmitted first in time. Bits within each field are numbered from 0 (leftmost and 41
least significant) to k-1 (rightmost and most significant), where the length of the field is k bits. Fields that are 42
longer than a single octet are sent to the next layer in the order from the octet containing the lowest 43
numbered bits to the octet containing the highest numbered bits.200 44
45
46
47
48
49
50
51
52
53
200
CCB Comment #98 54

1 3.6.1 Auxiliary Frame Header Format

2
3 The auxiliary frame header, as illustrated by Table 79, shall include a security control field and a frame
4 counter field, and may include a sender address field and key sequence number field.
5
6 Figure 79 Auxiliary frame header format
7 Octets: 1 4 0/8 0/1
8
Security control Frame Counter Source Address Key Sequence Number
9
10
11
3.6.1.1 Security Control Field
12
13 The security control field shall consist of a security level, a key identifier, and an extended nonce sub-field
14 and shall be formatted as shown in Table 80.
15
16 Figure 80 Security control field format
17 Bit: 0-2 3-4 5 6-7
18
19 Security level Key identifier Extended Nonce Reserved
20
21
22 3.6.1.1.1 Security level sub-field
23
The security level identifier indicates how an outgoing frame is to be secured, respectively, how an
24
incoming frame purportedly has been secured: it indicates whether or not the payload is encrypted and to
25
what extent data authenticity over the frame is provided, as reflected by the length of the message integrity
26
code (MIC). The bit-length of the MIC may take the values 0, 32, 64 or 128 and determines the probability
27
that a random guess of the MIC would be correct. The security properties of the security levels are listed in
28
Table 169.
29
30 Table 169 Security levels available to the MAC, NWK, and APS layers
31
Security Frame Integrity
32 Security Level Sub- Security Data (length M of MIC,
33 level Field Attributes Encryption in number of
34 identifier
(Table 80) octets)
35
36 0x00 ‘000’ None OFF NO (M = 0)
37
0x01 ‘001’ MIC-32 OFF YES (M=4)
38
39 0x02 ‘010’ MIC-64 OFF YES (M=8)
40
41 0x03 ‘011’ MIC-128 OFF YES (M=16)
42 0x04 ‘100’ ENC ON NO (M = 0)
43
44 0x05 ‘101’ ENC-MIC-32 ON YES (M=4)
45
0x06 ‘110’ ENC-MIC-64 ON YES (M=8)
46
47 0x07 ‘111’ ENC-MIC-128 ON YES (M=16)
48
49
50
51
52
53
54

3.6.1.1.2 Key identifier sub-field 1

2
The key identifier sub-field consists of two bits that are used to identify the key used to protect the frame. 3
The encoding for the key identifier sub-field shall be as listed in Table 170. 4
5
Table 170 Encoding for the key identifier sub-field 6
Key Identifier Sub-Field 7
Key Identifier Description
(Table 80) 8
9
0x00 ‘00’ A link key.
10
0x01 ‘01’ A Network key. 11
12
0x02 ‘10’ A key-transport key. 13
0x03 ‘11’ A key-load key. 14
15
16
3.6.1.1.3 Extended nonce sub-field 17
18
The extended nonce sub-field shall be set to 1 if the sender address field of the auxiliary header is present. 19
Otherwise, it shall be set to 0. 20
21
3.6.1.2 Source Address Field 22
23
The source address field shall only be present when the extended nonce sub-field of the security control field 24
is 1. When present, the source address field shall indicate the extended 64-bit address of the device 25
responsible for securing the frame. 26
27
3.6.1.3 Counter Field 28
29
The counter field is used to provide for frame freshness and to prevent processing of duplicate frames.
30
31
3.6.1.4 Key Sequence Number Field
32
The key sequence number field shall only be present when the key identifier sub-field of the security control 33
field is 1 (i.e., the Network key). When present, the key sequence number field shall indicate the key 34
sequence number of the Network key used to secure the frame. 35
36
37
3.6.2 Security Parameters 38
39
This clause specifies the parameters used for the CCM* security operations. 40
41
3.6.2.1 CCM* Mode of Operation and Parameters 42
Applying security to a MAC, NWK, or APS frame on a particular security level corresponds to a particular 43
instantiation of the AES-CCM* mode of operation as specified in section B.1.2. The AES-CCM* mode of 44
operation is an extension of the AES-CCM mode that is used in the 802.15.4-2003 MAC specification and 45
provides capabilities for authentication, encryption, or both. 46
47
The nonce shall be formatted as specified in sub-clause 3.6.2.2. 48
49
Table 169 gives the relationship between the security level subfield of the security control field (Table 80), 50
the security level identifier, and the CCM* encryption/authentication properties used for these operations. 51
52
53
54

1 3.6.2.2 CCM* Nonce

2
3 The nonce input used for the CCM* encryption and authentication transformation and for the CCM*
4 decryption and authentication checking transformation consists of data explicitly included in the frame and
5 data that both devices can independently obtain. Figure 81 specifies the order and length of the subfields of
6 the CCM* nonce. The nonce's security control and frame counter fields shall be the same as the auxiliary
7 header’s security control and frame counter fields (as defined in sub-clause 3.6.1) of the frame being
8 processed. The nonce’s source address field shall be set to the extended 64-bit MAC address of the device
9 originating security protection of the frame. When the extended nonce sub-field of the auxiliary header’s
10 security control field is 1, the extended 64-bit MAC address of the device originating security protection of
11 the frame shall correspond to the auxiliary header’s source address field (as defined in sub-clause 3.6.1) of
12 the frame being processed.
13
14 Figure 81 CCM* nonce
15 Octets: 8 4 1
16 Source address Frame counter Security control
17
18
19 3.6.3 Cryptographic Key Hierarchy
20
21 The link key established between two (or more) devices via one of the key-establishment schemes specified
22 in sub-clause 3.5.2 (or transport-key commands specified in sub-clause 3.5.3) is used to determine related
23 secret keys, including data keys, key-transport keys, and key-load keys. These keys are determined as
24 follows:
25
26 1. Key-Transport Key. This key is the outcome of executing the specialized keyed hash function specified
27 in clause B.1.5 under the link key with as input string the 1-octet string ‘0x00’.
28 2. Key-Load Key. This key is the outcome of executing the specialized keyed hash function specified in
29 clause B.1.5 under the link key with as input string the 1-octet string ‘0x02’.
30
31 3. Data Key. This key is equal to the link key.
32
All keys derived from the link key shall share the associated frame counters. Also, all layers of ZigBee shall
33
share the Network key and associated outgoing and incoming frame counters.
34
35
36 3.6.4 Implementation Guidelines (Informative)
37
38 This clause provides general guidelines that should be followed to ensure a secure implementation.
39
40 3.6.4.1 Random Number Generator
41
42 A ZigBee device implementing the key-establishment (i.e., see sub-clause 3.2.4.1) security service may
43 need a strong method of random number generation. For example, when link keys are pre-installed (e.g., in
44 the factory), a random number may not be needed.
45
In all cases that require random numbers, it is critical that the random numbers are not predictable or have
46
enough entropy, so an attacker will not be able determine them by exhaustive search. The general
47
recommendation is that the random number generation shall meet the random number tests specified in
48
FIPS140-2 [B12]. There are methods for generation of random numbers:
49
50 1. Base the random number on random clocks and counters within the ZigBee hardware
51
52 2. Base the random number on random external events
53 3. Seed each ZigBee device with a good random number from an external source during production. This
54 random number can then used as a seed to generate additional random numbers.

A combination of these methods can be used. Since the random number generation is likely integrated into 1
the ZigBee IC, its design and hence the ultimate viability of any encryption/security scheme is left up to the 2
IC manufacturers. 3
4
3.6.4.2 Security Implementation 5
6
It is very important security be well implemented and tested so that no “bugs” exist that an attacker can use 7
to his advantage. It is also desirable that the security implementation does not need to be re-certified for 8
every application. Security services should be implemented and tested by security experts and should not be 9
re-implemented or modified for different applications. 10
11
3.6.4.3 Conformance 12
13
Conformance shall be defined by the profile inheriting from this specification. Correct implementation of
14
selected cryptographic protocols should be verified as part of the ZigBee certification process. This
15
verification shall include known value tests: an implementation must show that given particular parameters,
16
it will correctly compute the corresponding results.
17
18
19
3.7 Functional Description 20
21
This subclause provides detailed descriptions of how the security services shall be used in a ZigBee 22
network. A description of the ZigBee coordinator’s security initialization responsibilities is given in sub- 23
clause 3.7.1. A brief description of the trust center application is given in sub-clause 3.7.2. Detailed security 24
procedures are given in sub-clause 3.7.3. 25
26
27
3.7.1 ZigBee Coordinator 28
29
The coordinator shall configure the security level of the network by setting the NwkSecurityLevel attribute in
30
the NWK layer PIB table. If the NwkSecurityLevel attribute is set to zero, the network will be unsecured,
31
otherwise it will be secured.
32
The coordinator shall configure the address of the trust center by setting the AIB attribute 33
apsTrustCenterAddress. The default value of this address is the coordinator’s address itself, otherwise, the 34
coordinator may designate an alternate trust center. 35
36
37
3.7.2 Trust Center Application 38
39
The trust center application runs on a device trusted by devices within a ZigBee network to distribute keys 40
for the purpose of network and end-to-end application configuration management. The trust center shall be 41
configured to operate in either commercial or residential mode and may be used to help establish end-to-end 42
application keys either by sending out link keys directly (i.e., key-escrow capability) or by sending out 43
master keys. 44
45
3.7.2.1 Commercial Mode 46
47
The commercial mode of the trust center is designed for high-security commercial applications. In this
48
mode, the trust center shall maintain a list of devices, master keys, link keys, and Network keys that it needs
49
to control and enforce the policies of Network key updates and network admittance. In this mode, the
50
memory required for the trust center grows with the number of devices in the network and the nwkAllFresh
51
attribute in the NIB shall be set to TRUE.
52
53
54

1 3.7.2.2 Residential Mode

2
3 The residential mode of the trust center is designed for low-security residential applications. In this mode,
4 the trust center may maintain a list of devices, master keys, or link keys with all the devices in the network;
5 however, it shall maintain the Network key and controls policies of network admittance. In this mode, the
6 memory required for the trust center does not grow with the number of devices in the network and the
7 nwkAllFresh attribute in the NIB shall be set to FALSE.
8
9 3.7.3 Security Procedures
10
11 This subclause gives message sequence charts for joining a secured network, authenticating a newly joined
12 device, updating the Network key, recovering the Network key, establishing end-to-end application keys,
13 and leaving a secured network.
14
15 3.7.3.1 Joining a Secured Network
16
17 Figure 82 shows an example message sequence chart ensuing from when a joiner device communicates with
18 a router device to join a secured network.
19
20 Router Joiner
21 ZDO NWK MAC MAC NWK ZDO
22
23 NLME-PERMIT-JOINING.request NLME-NETWORK-DISCOVERY.request
24 MLME-SCAN.request
MLME-SET.request(macAssociationPermit = TRUE)
25
26 Beacon request command (unsecured)
27
Beacon (unsecured)
28 MLME-SCAN.confirm
29 NLME-NETWORK-DISCOVERY.confirm
30
NLME-JOIN.request
31
32 MLME-ASSOCIATE.request
Association request command
33
34 MLME-ASSOCIATE.indication
35 NLME-JOIN.indication
36
MLME-ASSOCIATE.response
37
Association response command
38
39 MLME-ASSOCIATE.confirm
40 NLME-JOIN.confirm
41
Joined (unauthenticated)
42
43
44 Successful Authenticate Routine (see 8.3.2)
45
46 NLME-START-ROUTER.request (only if B is a router)
47
MLME-START.request (only if B is a router)
48
49
Joined (authenticated)
50
51
52
Figure 82 Example of joining a secured network
53
54

The joiner device may begin the join procedure by issuing an NLME-NETWORK-DISCOVERY.request 1
primitive. This primitive will invoke an MLME-SCAN.request primitive which may cause the transmission 2
of an unsecured beacon request frame (depending on whether the scan is an active or passive scan). 3
4
The joiner device receives beacons from nearby routers and the NWK layer will issue an NLME- 5
NETWORK-DISCOVERY.confirm primitive. The NetworkList parameter of this primitive will indicate all 6
of the nearby PANs along with their nwkSecurityLevel and nwkSecureAllFrames nwkSecureAllFrames 7
attributes. In Figure 82, the shown router device has already been placed in a state such that its beacons have 8
the “association permit” sub-field set to “1” (permit association). 9
10
The joiner device shall decide which PAN to join (e.g., based on the security attributes received in NLME-
11
NETWORK-DISCOVERY.confirm primitive) and shall issue the NLME-JOIN.request primitive to join
12
that PAN. If the joiner already has a Network key for this PAN, the SecurityEnable parameter for the
13
NLME-JOIN.request primitive shall be set to TRUE; otherwise it shall be set to FALSE. As shown in
14
Figure 82, the NLME-JOIN.request primitive causes an association request command to be sent to the
15
router.
16
Upon receipt of the association request command, the router shall issue an MLME-ASSOCIATE.indication 17
primitive with the SecurityUse parameter set to TRUE or FALSE, according to whether the association 18
request command was secured or not. Next, the NWK layer will issue an NLME-JOIN.indication primitive 19
to the router’s ZDO. The router shall now know the joiner device’s address and whether the Network key 20
was used to secure the association request command. The router will also issue an MLME- 21
ASSOCIATE.response primitive with the SecurityEnable parameter set to TRUE or FALSE, according to 22
whether the association request command was secured or not, respectively. This primitive will cause an 23
association response command to be sent to the joiner. 24
25
Upon receipt of the association response command, the joiner shall issue the NLME-JOIN.confirm primitive 26
The joiner is now declared “joined, but unauthenticated” to the network. The authentication routine (see sub- 27
clause 3.7.3.2) shall follow. 28
29
If the joiner is not a router, it is declared “joined and authenticated” immediately following the successful 30
completion of the authentication routine. 31
32
If the joiner is a router, it is declared “joined and authenticated” only after the successful completion of the
33
authentication routine followed by the initiation of routing operations. Routing operations shall be initiated
34
by the joiner’s ZDO issuing the NLME-START.request201 primitive to cause the MLME-START.request
35
primitive to be sent to the MAC layer of the joiner.
36
If the router refuses the joiner, its association response frame shall contain the association status field set to 37
a value other than “0x00”, and, after this parameter reaches the ZDO of the joiner in the NLME- 38
JOIN.confirm primitive, the joiner shall not begin the authentication routine. 39
40
3.7.3.2 Authentication 41
42
Once a device joins a secured network and is declared “joined but unauthenticated”, it must be authenticated 43
as specified in this sub-clause. 44
45
3.7.3.2.1 Router operation 46
47
If the router is not the trust center, it shall begin the authentication procedure immediately after receipt of the 48
NLME-JOIN.indication202 primitive by issuing an APSME-UPDATE-DEVICE.request primitive with the 49
DestAddress parameter set to the apsTrustCenterAddress in the AIB and the DeviceAddress parameter set to 50
the address of the newly joined device. The Status parameter of this primitive shall be set to 0x00 (i.e., 51
52
202
CCB Comment #217 54

1 secured join) if the newly joined device secured the associate request command. Otherwise, the Status
2 parameter shall be set to 0x01 (i.e., unsecured join).
3
4 If the router is the trust center, it shall begin the authentication procedure by simply operating as a trust
5 center.
6
7 3.7.3.2.2 Trust center operation
8
The trust center role in the authentication procedure shall be activated upon receipt of an incoming update-
9
device command or immediately after receipt of the NLME-JOIN.indication203 primitive (in the case where
10
the router is the trust center). The trust center behaves differently depending on at least five factors:
11
12 — Whether the trust center decides to allow the new device to join the network (e.g., the trust center is
13 in a mode that allows new devices to join).
14
15 — Whether the trust center is operating in residential or commercial mode (see sub-clause 3.7.2.1 and
16 sub-clause 3.7.2.2, respectively).
17 — If in residential mode, whether the device is joining unsecured or secured (i.e., as indicated by the
18 Status sub-field of the update-device command).
19
20 — If in commercial mode, whether the trust center has a master key corresponding to the newly joined
21 device.
22 — The nwkSecureAllFrames parameter of the NIB.
23
24 If, at any time during the authentication procedure, the trust center decides not to allow the new device to
25 join the network (e.g., a policy decision or a failed key-establishment protocol), it shall take actions to
26 remove the device from the network. If the trust center is not the router of the newly joined device, it shall
27 remove the device from the network by issuing the APSME-REMOVE-DEVICE.request primitive with the
28 ParentAddress parameter set to the address of the router originating the update-device command and the
29 ChildAddress parameter set to the address of the joined (but unauthenticated) device. If the trust center is the
30 router of the newly joined device, it shall remove the device from the network by issuing the NLME-
31 LEAVE.request primitive with the DeviceAddress parameter set to the address of the joined (but
32 unauthenticated) device.
33
34 3.7.3.2.2.1 Residential mode
35
36 After being activated for the authentication procedure the trust center shall send the device the active
37 Network key by issuing the APSME-TRANSPORT-KEY.request primitive with the DestAddress parameter
38 set to the address of the newly joined device, and the KeyType parameter to 0x01 (i.e., Network key).
39
If the joining device already has the Network key (i.e., the Status sub-field of the update-device command is
40
0x00), the TransportKeyData sub-parameters shall be set as follows: the KeySeqNumber sub-parameter
41
shall be set to 0, the NetworkKey sub-parameter shall be set to all zeros, and the UseParent sub-parameter
42
shall be set to FALSE.
43
44 Otherwise, the KeySeqNumber sub-parameter shall be set to the sequence count value for this Network key,
45 the NetworkKey sub-parameter shall be set to Network key. The UseParent sub-parameter shall be set to
46 FALSE if the trust center is the router; otherwise, the UseParent sub-parameter shall be set to TRUE and the
47 ParentAddress sub-parameter shall be set to the address of the router originating the update-device
48 command.
49
50 In the case of a joining device that is not preconfigured with a Network key, the issuance of this transport-
51 key primitive will cause the Network key to be sent unsecured from the router to the newly joined device—
52
53
203
54 CCB Comment #218

security is assumed to be present here via non-cryptographic means, such as only sending this key once, at 1
low power, immediately after external input to both router and joiner, etc. 2
3
3.7.3.2.2.2 Commercial mode 4
5
After being activated for the authentication procedure, the trust center operation in commercial mode 6
depends on if the device joining the network is preconfigured with a trust center master key. 7
8
If the trust center does not already share a master key with the newly joined device, it shall send the device a
9
master key by issuing the APSME-TRANSPORT-KEY.request primitive with the DestAddress parameter
10
set to the address of the newly joined device, and the KeyType parameter to 0x00 (i.e., trust center master
11
key). The TransportKeyData sub-parameters shall be set as follows: the TrustCenterMasterKey sub-
12
parameter shall be set to trust center master key, and the ParentAddress sub-parameter shall set to the
13
address of the local device if the trust center is the router; otherwise, the ParentAddress sub-parameter shall
14
set to the address of the router originating the update-device command. The issuance of this primitive will
15
cause the master key to be sent unsecured from the router to the newly joined device—security is assumed to
16
be present here via non-cryptographic means, such as only sending this key once, at low power, immediately
17
after external input to both router and joiner, etc.
18
The trust center shall initiate the establishment of a link key by issuing the APSME-ESTABLISH- 19
KEY.request primitive with the ResponderAddress parameter set to the address of the newly joined device 20
and the KeyEstablishmentMethod set to 0x00 (i.e., SKKE). Additionally, if the nwkSecureAllFrames 21
parameter of the NIB is FALSE or the trust center is the router, the UseParent parameter shall be set to 22
FALSE; otherwise, the UseParent parameter shall be set to TRUE and the ResponderParentAddress 23
parameter shall be set to the address of the router originating the update-device command. 24
25
Upon receipt of the corresponding APSME-ESTABLISH-KEY.confirm primitive with Status equal to 0x00 26
(i.e., success), the trust center shall send the new device the Network key by issuing the APSME- 27
TRANSPORT-KEY.request primitive with the DestAddress parameter set to the address of the newly joined 28
device, and the KeyType parameter to 0x01 (i.e., Network key). The TransportKeyData sub-parameters shall 29
be set as follows. The KeySeqNumber sub-parameter shall be set to the sequence count value for this 30
Network key, the NetworkKey sub-parameter shall be set to Network key, and the UseParent sub-parameter 31
shall be set to FALSE. 32
33
3.7.3.2.3 Joining device operation 34
35
After successfully associating to a secured network, the joining device shall participate in the authentication 36
procedure described in this sub-clause. Following a successful authentication procedure, the joining device 37
shall set the nwkSecurityLevel and nwkSecureAllFrames attributes in the NIB to the values indicated in the 38
beacon from the router. 39
40
A joined and authenticated device in a secured network with nwkSecureAllFrames equal to TRUE shall
41
always apply NWK layer security to outgoing (incoming) frames unless the frame is destined for (originated
42
from) a newly joined but unauthenticated child. No such restrictions exist if nwkSecureAllFrames is equal to
43
FALSE.
44
The joining device’s participation in the authentication procedure depends on the state of the device. There 45
are three possible initial states to consider: 46
47
— Preconfigured with a Network key (i.e., residential mode) 48
49
— Preconfigured with a trust center master key and address (i.e., commercial mode)
50
— Not preconfigured (i.e., undetermined mode – either residential or commercial mode) 51
52
In a secured network, if the device does not become authenticated within a preconfigured amount of time, it 53
shall leave the network. 54

1 3.7.3.2.3.1 Preconfigured Network key

2
3 If the joining device was preconfigured with just a Network key (and the association was successful), it shall
4 set the outgoing frame counter for this key to zero, and empty the incoming frame counter set for this key,
5 and wait to receive a dummy (all zero) Network key from the trust center. Upon receipt of the APSME-
6 TRANSPORT-KEY.indication primitive with the KeyType parameter set to 0x01 (i.e., the Network key),
7 the joining device shall set the apsTrustCenterAddress attribute in its AIB to the SrcAddress parameter of
8 the APSME-TRANSPORT-KEY.indication primitive. The joining device is now considered authenticated
9 and shall enter the normal operating state for residential mode.
10
11 3.7.3.2.3.2 Preconfigured trust center key
12
If the joining device is preconfigured with a trust center master key and address (i.e., the
13
apsTrustCenterAddress attribute in the AIB) it shall wait to establish a link key and receive a Network key
14
from the trust center. Therefore, upon receipt of the APSME-ESTABLISH-KEY.indication primitive with
15
the InitiatorAddress parameter set to the trust center’s address and the KeyEstablishmentMethod parameter
16
set to SKKE, the joining device shall respond with the APSME-ESTABLISH-KEY.response primitive with
17
the InitiatorAddress parameter set to the trust center’s address and the Accept parameter set to TRUE. After
18
receipt of the APSME-ESTABLISH-KEY.confirm primitive with the Address parameter set to the trust
19
center’s address and the Status parameter set to 0x00 (i.e., success), the joining device shall expect to receive
20
the Network key. Upon receipt of the APSME-TRANSPORT-KEY.indication primitive with
21
SourceAddress parameter set to the trust center’s address, the KeyType parameter set to 0x01 (i.e., the
22
Network key), the joining device shall use the data in the TransportKeyData parameter for configuring the
23
Network key. The joining device is now considered authenticated and shall enter the normal operating state
24
for commercial mode.
25
26
3.7.3.2.3.3 Not preconfigured
27
28 If the joining device is not preconfigured with a Network key nor a trust center master key and address (i.e.,
29 the apsTrustCenterAddress attribute in the AIB) it shall wait to receive either an unsecured trust center
30 master key or a Network key. Implementers should note that transmission of an unsecured key represents a
31 security risk and that if security is a concern, keys should be preconfigured – preferable via an out-of-band
32 mechanism.
33
34 Upon receipt of the APSME-TRANSPORT-KEY.indication primitive with the KeyType parameter set to
35 0x01 (i.e., the Network key), the joining device shall make the data in the TransportKeyData parameter its
36 active Network key and shall set the apsTrustCenterAddress attribute in its AIB to the SrcAddress parameter
37 of the APSME-TRANSPORT-KEY.indication primitive. The joining device is now considered
38 authenticated and shall enter the normal operating state for residential mode.
39
40 Upon receipt of the APSME-TRANSPORT-KEY.indication primitive with the KeyType parameter set to
41 0x00 (i.e., the trust center master key), the joining device shall make its trust center master key the data in
42 the TransportKeyData parameter and the apsTrustCenterAddress attribute in its AIB the SrcAddress
43 parameter. Next, upon receipt of the APSME-ESTABLISH-KEY.indication primitive with the
44 InitiatorAddress parameter set to the trust center’s address and the KeyEstablishmentMethod parameter set
45 to SKKE, the joining device shall respond with the APSME-ESTABLISH-KEY.response primitive with the
46 InitiatorAddress parameter set to the trust center’s address and the Accept parameter set to TRUE. After
47 receipt of the APSME-ESTABLISH-KEY.confirm primitive with the Address parameter set to the trust
48 center’s address and the Status parameter set to 0x00 (i.e., success), the joining device shall expect to receive
49 the Network key. Upon receipt of the APSME-TRANSPORT-KEY.indication primitive with
50 SourceAddress parameter set to the trust center’s address, the KeyType parameter set to 0x01 (i.e., the
51 Network key), the joining device shall use the data in the TransportKeyData parameter for configuring the
52 Network key. The joining device is now considered authenticated and shall enter the normal operating state
53 for commercial mode.
54

3.7.3.2.4 Message sequence charts 1

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

1
2 Trust Center Router Joiner
3
4 Joined (unauthenticated)
5
6 Update-Device Command
7
Decision to accept
8 new device
9 1
Secured Transport-Key Command (Master key)
10
1
11 Unsecured Transport-Key Command (Master key)
12 SKKE-1 Command
13
SKKE-2 Command
14 See
15 SKKE-3 Command Note 2
16 SKKE-4 Command
17
Secured Transport-Key Command(NWK key)
18
19
20
21 Notes:
22 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)
23 2. SKKE commands shall be sent using the router as a liaison 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).
24
25
26 Figure 84 Example commercial-mode authentication procedure
27
28 3.7.3.3 Network Key Update
29
30 The trust center and network device shall follow the procedures described in this sub-clause when updating
31 the Network key.
32
33 3.7.3.3.1 Trust center operation
34
35 When operating in residential mode, the trust center shall never update the network. This is a tradeoff to
36 limit implementation complexity, at the cost of reduced security.
37 When operating in commercial mode, the trust center shall maintain a list of all devices in the network. To
38 update the Network key, the trust center shall first send the new Network key to each device on this list and
39 then ask each device to switch to this new key. The new Network key shall be sent to a device on the list by
40 issuing the APSME-TRANSPORT-KEY.request primitive with the DestAddress parameter set to the
41 address of the device on the list and the KeyType parameter set to 0x01 (i.e., Network key). The
42 TransportKeyData sub-parameters shall be set as follows. The KeySeqNumber sub-parameter shall be set to
43 the sequence count value for this Network key, the NetworkKey sub-parameter shall be set to the Network
44 key, and the UseParent sub-parameter shall be set to FALSE. If the sequence count for the previously
45 distributed Network key is represented as N, then the sequence count for this new Network key shall be
46 (N+1) mod 256. The trust center shall ask a device to switch to this new key by issuing the APSME-
47 SWITCH-KEY.request primitive with the DestAddress parameter set to the address of the device on the list
48 and the KeySeqNumber parameter set to the sequence count value for the updated Network key.
49
50 3.7.3.3.2 Network device operation
51
52 When in normal operating state for residential mode (i.e., a trust center master key is not present), a device
53 shall not accept an updated Network key. Thus, in this mode, transport-key or a switch-key commands with
54 the KeyType parameter set to 0x01 (i.e., Network key) shall be ignored.

When in the normal operating state for commercial mode (i.e., a trust center master key is present) and upon 1
receipt of a APSME-TRANSPORT-KEY.indication primitive with the KeyType parameter set to 0x01 (i.e., 2
Network key), a device shall accept the TransportKeyData parameters as a Network key only if the 3
SrcAddress parameter is the same as the trust center’s address (as maintained in the apsTrustCenterAddress 4
attribute of the AIB). If accepted and if the device is capable of storing an alternate Network key, the key 5
and sequence number data contained in the TransportKeyData parameter shall replace the alternate Network 6
key. Otherwise, the key and sequence number data contained in the TransportKeyData parameter shall 7
replace the active Network key. 8
9
When in the normal operating state for commercial mode (i.e., a trust center master key is present) and upon 10
receipt of a APSME-SWITCH-KEY.indication primitive, a device shall switch its active Network key to the 11
one designated by the KeySeqNumber parameter only if the SrcAddress parameter is the same as the trust 12
center’s address (as maintained in the apsTrustCenterAddress attribute of the AIB). 13
14
3.7.3.3.3 Message sequence chart 15
16
An example of a successful Network key-update procedure for two devices is shown in Figure 85. In this
17
example, the trust center sends the Network key with sequence number N to devices 1 and 2. In this
18
example, device 1 is an FD capable of storing two Network keys, an active and alternate, and device 2 is an
19
RFD that can store only a single Network key. Upon receipt of the transport-key command, device 1
20
replaces its alternate Network key with the new Network key; however device 2 must replace its active
21
Network key with the new key. Next, upon receipt of the switch-key command, device 1 makes the new
22
Network key the active Network key; however device 2 has just one active Network key, so it ignores this
23
command.
24
25
Trust Center Device 1 Device 2
26
27
Transport-Key Command(NWK key, N) 28
29
Replace alternate network
key with network key N. 30
31
Transport-Key Command(NWK key, N)
32
Switch-Key Command(N) Replace active network 33
key with network key N. 34
Make network key N the 35
active network key.
36
Switch-Key Command(N)
37
38
Ignore command.
39
40
Figure 85 Example Network key-update procedure 41
42
3.7.3.4 Network Key Recovery 43
44
A network device and trust center shall follow the procedures described in this sub-clause when recovering 45
the Network key. 46
47
3.7.3.4.1 Network device operation 48
49
When in the normal operating state for residential mode (i.e., a trust center master key is not present), a 50
device shall not generate a request for an updated Network key. 51
52
When in the normal operating state for commercial mode (i.e., a trust center master key is present) a network 53
device shall request the current Network key by issuing the APSME-REQUEST-KEY.request primitive 54

1 with the DestAddress parameter204 set to the trust center’s address (as maintained in the
2 apsTrustCenterAddress attribute of the AIB), the KeyType parameter set to 0x01 (i.e., Network key), and the
3 PartnerAddress parameter set to 0.
4
5 3.7.3.4.2 Trust Center operation
6
7 When operating in residential mode, the trust center shall ignore the receipt of APSME-REQUEST-
8 KEY.indication primitives with the KeyType parameter set to 0x01205 (i.e., Network key).
9
When operating in commercial mode and receipt of APSME-REQUEST-KEY.indication primitives with the
10
KeyType parameter set to 0x01 (i.e., Network key), the trust center shall determine whether the device
11
indicated by the SrcAddress parameter is present on its list of all device on the network. If the device is
12
present on this list, the trust center shall issue the APSME-TRANSPORT-KEY.request primitive with the
13
DestAddress parameter set to the address of the device requesting the key and the KeyType parameter set to
14
0x01 (i.e., Network key). The TransportKeyData sub-parameters shall be set as follows. The
15
KeySeqNumber sub-parameter shall be set to the sequence count value for this Network key, the
16
NetworkKey sub-parameter shall be set to the Network key, and the UseParent sub-parameter shall be set to
17
FALSE. Next, the trust center shall ask a device to switch to this new key by issuing the APSME-SWITCH-
18
KEY.request primitive with the DestAddress parameter set to the address of the device that requested the
19
key and the KeySeqNumber parameter set to the sequence count value for the updated Network key.
20
21
3.7.3.4.3 Message sequence chart
22
23 An example of a successful Network key-recovery procedure is shown in Figure 86. In this example, the
24 network device requests the current Network key from the trust center. The trust center responds with
25 current key and then tells the device to switch to this key.
26
27
Trust Center Device A
28
Request-Key Command(NWK key)
29
30 Make sure device A is
part of the network.
31
Transport-Key Command(NWK key, N)
32
33 Replace alternate network
key with network key N.
34 Switch-Key Command(N)
35
Make network key N the
36 active network key.
37
38
39
40 Figure 86 Example Network key-recovery procedure
41
42 3.7.3.5 End-to-End Application Key Establishment
43
44 An initiator device, a trust center, and a responder device shall follow the procedures described in this sub-
45 clause when establishing a link key for purposes of end-to-end application security between initiator and
46 responder devices.
47
48 3.7.3.5.1 Device operation
49
50 The initiator device shall begin the procedure to establish a link key with a responder device by issuing the
51 APSME-REQUEST-KEY.request primitive. The DstDevice parameter shall be set to the address of its trust
52
205
54 CCB Comment #220

center, the KeyType parameter shall be set to 0x02 (i.e., application key), and the PartnerAddress parameter 1
shall be set to the address of the responder device. 2
3
3.7.3.5.1.1 Upon receipt of link key 4
5
Upon receipt of an APSME-TRANSPORT-KEY.indication primitive with the KeyType parameter set to 6
0x03 (i.e., application link key), a device may accept the TransportKeyData parameters as a link key with 7
the device indicated by the PartnerAddress parameter only if the SrcAddress parameter is the same as the 8
apsTrustCenterAddress attribute of the AIB. If accepted, the DeviceKeyPairSet attribute in AIB table will be 9
updated. A key-pair descriptor in the AIB shall be created (or updated if already present), for the device 10
indicated by the PartnerAddress parameter, by setting the DeviceAddress element to the PartnerAddress 11
parameter, the LinkKey element to the link key from the TransportKeyData parameter, and the 12
OutgoingFrameCounter and IncomingFrameCounter elements to 0. 13
14
3.7.3.5.1.2 Upon receipt of a master key 15
16
Upon receipt of an APSME-TRANSPORT-KEY.indication primitive with the KeyType parameter set to
17
0x02 (i.e., application master key), a device may accept the TransportKeyData parameters as a master key
18
with the device indicated by the PartnerAddress sub-parameter only if the SrcAddress parameter is the same
19
as the apsTrustCenterAddress attribute of the AIB. If accepted, the DeviceKeyPairSet attribute in AIB table
20
will be updated. A key-pair descriptor shall be created (or updated if already present), for the device
21
indicated by the PartnerAddress parameter, by setting the DeviceAddress element to the PartnerAddress
22
parameter, the MasterKey element to the master key from the TransportKeyData parameter, and the
23
OutgoingFrameCounter and IncomingFrameCounter elements to 0.
24
Next, if the Initiator sub-parameter of the TransportKeyData parameter of the APSME-TRANSPORT- 25
KEY.indication primitive was TRUE, the device shall issue the APSME-ESTABLISH-KEY.request 26
primitive. The ResponderAddress206 parameter shall be set to the PartnerAddress sub-parameter of the 27
TransportKeyData parameter, the UseParent parameter shall be set to FALSE, and the 28
KeyEstablishmentMethod shall be set to 0x00 (i.e., SKKE). 29
30
Upon receipt of the APSME-ESTABLISH-KEY.indication primitive, the responder device shall be 31
informed that the initiator device wishes to establish a link key. If the responder decides to establish a link 32
key, it shall issue the APSME-ESTABLISH-KEY.response207 primitive with the InitiatorAddress 33
parameter set to the address of the initiator and the Accept parameter set to TRUE. Otherwise, it shall set the 34
Accept parameter set to FALSE. 35
36
If the responder decided to set up a key with the initiator, the SKKE protocol will ensue and the APSME- 37
ESTABLISH-KEY.confirm primitive will be issued to both the responder and initiator. 38
39
3.7.3.5.2 Trust center operation 40
41
Upon receipt of APSME-REQUEST-KEY.indication primitives with the KeyType parameter set to 0x02
42
(i.e., application key), the trust center behavior depends on if it has been configured to send out application
43
link keys or master keys.
44
The trust center shall issue two APSME-TRANSPORT-KEY.request primitives. If configured to send out 45
application link keys the KeyType parameter shall be set to 0x03 (i.e., application link key); otherwise, the 46
KeyType parameter shall be set to 0x02 (i.e., application master key). The first primitive shall have the 47
DestAddress parameter set to the address of the device requesting the key. The TransportKeyData sub- 48
parameters shall be set as follows: the PartnerAddress sub-parameter shall be set to the PartnerAddress sub- 49
parameter of the APSME-REQUEST-KEY.indication primitive’s TransportKeyData parameter, the 50
51
52
207
CCB Comment #222 54

Initiator sub-parameter shall be set to TRUE, and the Key sub-parameter shall be set to a new key K (a
master or link key). The second primitive shall have the DestAddress parameter set to the PartnerAddress
sub-parameter of the APSME-REQUEST-KEY.indication primitive’s TransportKeyData parameter. The
TransportKeyData sub-parameters shall be set as follows: the PartnerAddress sub-parameter shall be set to
the address of the device requesting the key, the Initiator sub-parameter shall be set to FALSE, and the Key
sub-parameter shall be set to K.
3.7.3.5.3 Message sequence chart
An example message sequence chart of the end-to-end application key establishment procedure is shown in
Figure 87. The procedure begins with the transmission of the request-key command from the initiator to the
trust center. Next, the trust center starts a time-out timer. For the duration of this timer (i.e., until it expires),
the trust center shall discard any new request-key commands for this pair of devices unless they are from the
initiator.
The trust center shall now send transport-key commands containing the application link or master key to the
initiator and responder devices. Only the initiator’s transport-key command will have the Initiator field set
to 1 (i.e., TRUE), so if a master key was sent, only the initiator device will begin the key-establishment
protocol by sending the SKKE-1 command. If the responder decides to accept establishing a key with the
initiator, the SKKE protocol will progress via the exchange of the SKKE-2, SKKE-3, and SKKE-4
commands. Upon completion (or time-out), the status of the protocol is reported to the ZDO’s of the initiator
and responder devices. If successful, the initiator and responder will now share a link key and secure
communications will be possible.
Initiator Trust Center Responder
Learn address of responder via discovery

or other means (e.g., preloaded)
Request-Key Command(key, responder address)
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
devices, unless they are from the initiator, until after the timer expires.
Transport-Key Command(key, Initiator=TRUE,

PartnerAddress = Responder’s address) Transport-Key Command(key, Initiator=FALSE,
PartnerAddress = Initiator’s address)
Stores key and, if a master key, Decides whether

initiates key establishment to the store key
SKKE-1 Command
Responder decides whether to run

key-establishment protocol
SKKE-2 Command
SKKE-3 Command
SKKE-4 Command
Status of SKKE reported to ZDO Status of SKKE reported to ZDO
Figure 87 Example end-to-end application key establishment procedure

3.7.3.6 Network Leave 1

2
A device, its router, and the trust center shall follow the procedures described in this sub-clause when the 3
device is to leave the network. 4
5
3.7.3.6.1 Trust center operation 6
7
If a trust center wants a device to leave and if the trust center is not the router for that device, the trust center
8
shall send issue the APSME-REMOVE-DEVICE.request primitive, with the ParentAddress parameter set to
9
the router’s address and the ChildAddress parameter set to the address of the device it wishes to leave the
10
network.
11
The trust center will also be informed of devices that leave the network. Upon receipt of an APSME- 12
UPDATE-DEVICE.indication primitive with the Status parameter set to 0x02 (i.e., device left), the 13
DeviceAddress parameter shall indicate the address of the device that left the network and the SrcAddress 14
parameter shall indicate the address of parent of this device. If operating in commercial mode, the trust 15
center shall delete the leaving device from its list of network devices. 16
17
3.7.3.6.2 Router operation 18
19
Routers are responsible for receiving remove-device commands and for sending update-device commands. 20
21
Upon receipt of an APSME-REMOVE-DEVICE.indication primitive, if the SrcAddress parameter is equal 22
to the apsTrustCenterAddress attribute of the AIB, a router shall issue an NLME-LEAVE.request primitive 23
with the DeviceAddress parameter the same as the DeviceAddress parameter of the APSME-REMOVE- 24
DEVICE.indication primitive. The router shall ignore REMOVE-DEVICE.indication primitives with the 25
SrcAddress parameter not equal to the apsTrustCenterAddress attribute of the AIB. 26
27
Upon receipt of an NLME-LEAVE.indication primitive with the DeviceAddress parameter set to one of its
28
children, a router that is not also the trust center shall issue an APSME-UPDATE-DEVICE.request
29
primitive with, the DstAddress parameter set to the address of the trust center, the Status parameter set to
30
0x02 (i.e., device left), and the DeviceAddress parameter set to the DeviceAddress parameter of the NLME-
31
LEAVE.indication primitive. If the router is the trust center, it should simply operate as the trust center and
32
shall not issue the APSME-UPDATE-DEVICE.request primitive (see sub-clause 3.7.3.6.1).
33
34
3.7.3.6.3 Leaving device operation
35
Devices are responsible for receiving and sending disassociation notification commands. 36
37
In a secured ZigBee network, disassociation notification commands shall be secured with the Network key 38
and sent with security enabled at the level indicated by the nwkSecurityLevel attribute in the NIB. 39
40
In a secured ZigBee network, disassociation notification commands shall be received and processed only if 41
secured with the Network key and received with security enabled at the level indicated by the 42
nwkSecurityLevel attribute in the NIB. 43
44
3.7.3.6.4 Message sequence charts 45
46
Figure 88 shows an example message sequence chart in which a trust center asks a router to remove one of
47
its children from the network. If a trust center wants a device to leave and if the trust center is not the router
48
for that device, the trust center shall send the router a remove-device command with the address of the
49
device it wishes to leave the network. In a secure network, the remove-device command shall be secured
50
with a link key if present; otherwise shall be secured with the Network key. Upon receipt of the remove-
51
device command, a router shall send a disassociation notification command to the device to leave the
52
network.
53
54

1
Trust Center Router Device
2
1
3 Remove-Device Command
4
2
5 Disassociation Notification Command
6
Note:
7 1. If a trust center wants a device to leave and if the trust center is not the router for that device, the trust center shall send the router
8 a remove-device command with the address of the device it wishes to leave the network.
9 2. A router shall send a disassociation command to cause one of its children to leave the network.
10
11
Figure 88 Example remove-device procedure
12
13 Figure 89 shows an example message sequence chart whereby a device notifies its router that it is
14 disassociating from the network. In this example, the device sends a disassociation notification command
15 (secured with the Network key) to its router. The router then sends a device-update command to the trust
16 center. In a secured network, the device-update command must be secured with the link key, if present, or
17 the Network key.
18
19
Trust Center Router Device
20 1
Disassociation Notification Command
21 2
22 Update-Device Command
23
24
Note:
25 1. A device leaving the network shall send a disassociation command to its router.
26
2. Upon receipt of a valid disassociation command, a router shall send an update-device command to the trust center to inform it
27 that a device has left the network.
28
29 Figure 89 Example device-leave procedure
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Annex A CCM* Mode of Operation 1
2
3
CCM* is a generic combined encryption and authentication block cipher mode. CCM* is only defined for 4
use with block ciphers with a 128-bit block size, such as AES-128 [B8]. The CCM* ideas can easily be 5
extended to other block sizes, but this will require further definitions. 6
7
The CCM* mode coincides with the original CCM mode specification [B20] for messages that require 8
authentication and, possibly, encryption, but does also offer support for messages that require only 9
encryption. As with the CCM mode, the CCM* mode requires only one key. The security proof for the CCM 10
mode [B21], [B22] carries over to the CCM* mode described here. The design of the CCM* mode takes into 11
account the results of [B23], thus allowing it to be securely used in implementation environments for which 12
the use of variable-length authentication tags, rather than fixed-length authentication tags only, is beneficial. 13
14
Prerequisites: The following are the prerequisites for the operation of the generic CCM* mode:
15
1. A block-cipher encryption function E shall have been chosen, with a 128-bit block size. The length in 16
bits of the keys used by the chosen encryption function is denoted by keylen. 17
18
2. A fixed representation of octets as binary strings shall have been chosen (e.g., most-significant-bit first 19
order or least-significant-bit-first order). 20
3. The length L of the message length field, in octets, shall have been chosen. Valid values for L are the 21
integers 2, 3,..., 8 (the value L=1 is reserved). 22
23
4. The length M of the authentication field, in octets, shall have been chosen. Valid values for M are the
24
integers 0, 4, 6, 8, 10, 12, 14, and 16. (The value M=0 corresponds to disabling authenticity, since then
25
the authentication field is the empty string.)
26
27
28
A.1 Notation and representation 29
30
Throughout this specification, the representation of integers as octet strings shall be fixed. All integers shall 31
be represented as octet strings in most-significant-octet first order. This representation conforms to the 32
conventions in Section 4.3 of ANSI X9.63-2001 [B7]. 33
34
35
A.2 CCM* mode encryption and authentication transformation 36
37
The CCM* mode forward transformation involves the execution, in order, of an input transformation 38
(A.2.1), an authentication transformation (A.2.2), and encryption transformation (A.2.3). 39
40
Input: The CCM* mode forward transformation takes as inputs:
41
1. A bit string Key of length keylen bits to be used as the key. Each entity shall have evidence that access to 42
this key is restricted to the entity itself and its intended key sharing group member(s). 43
44
2. A nonce N of 15-L octets. Within the scope of any encryption key Key, the nonce value shall be unique. 45
3. An octet string m of length l(m) octets, where 0 ≤ l(m) < 28L. 46
47
4. An octet string a of length l(a) octets, where 0 ≤ l(a) < 264. 48
49
The nonce N shall encode the potential values for M such that one can uniquely determine from N the 50
actually used value of M. The exact format of the nonce N is outside the scope of this specification and shall 51
be determined and fixed by the actual implementation environment of the CCM* mode. 52
53
54

ZigBee Specification, Annex A
1 Note: The exact format of the nonce N is left to the application, to allow simplified hardware and software
2 implementations in particular settings. Actual implementations of the CCM* mode may restrict the values of
3 M that are allowed throughout the life-cycle of the encryption key Key to a strict subset of those allowed in
4 the generic CCM* mode. If so, the format of the nonce N shall be such that one can uniquely determine from
5 N the actually used value of M in that particular subset. In particular, if M is fixed and the value M=0 is not
6 allowed, then there are no restrictions on N, in which case the CCM* mode reduces to the CCM mode.
7
8
9
A.2.1 Input transformation
10 This step involves the transformation of the input strings a and m to the strings AuthData and
11 PlainTextData, to be used by the authentication transformation and the encryption transformation,
12 respectively.
13
14 This step involves the following steps, in order:
15
16 1. Form the octet string representation L(a) of the length l(a) of the octet string a, as follows:
17 a) If l(a)=0, then L(a) is the empty string.
18
19 b) If 0 < l(a) < 216-28, then L(a) is the 2-octets encoding of l(a).
20 c) If 216-28 ≤ l(a) < 232, then L(a) is the right-concatenation of the octet 0xff, the octet 0xfe, and the 4-
21 octets encoding of l(a).
22
d) If 232 ≤ l(a) < 264, then L(a) is the right-concatenation of the octet 0xff, the octet 0xff, and the 8-
23
octets encoding of l(a).
24
25 2. Right-concatenate the octet string L(a) with the octet string a itself. Note that the resulting string
26 contains l(a) and a encoded in a reversible manner.
27 3. Form the padded message AddAuthData by right-concatenating the resulting string with the smallest
28 non-negative number of all-zero octets such that the octet string AddAuthData has length divisible by
29 16.
30
31 4. Form the padded message PlaintextData by right-concatenating the octet string m with the smallest
32 non-negative number of all-zero octets such that the octet string PlaintextData has length divisible by
33 16.
34 5. Form the message AuthData consisting of the octet strings AddAuthData and PlaintextData:
35
36 AuthData = AddAuthData || PlaintextData. (1)
37
38
39
A.2.2 Authentication transformation
40 The data AuthData that was established above shall be tagged using the tagging transformation as follows:
41
42 1. Form the 1-octet Flags field consisting of the 1-bit Reserved field, the 1-bit Adata field, and the 3-bit
43 representations of the integers M and L, as follows:
44
45 Flags = Reserved || Adata || M || L. (2)
46
47 Here, the 1-bit Reserved field is reserved for future expansions and shall be set to ‘0’. The 1-bit Adata
48 field is set to ‘0’ if l(a)=0, and set to ‘1’ if l(a)>0. The L field is the 3-bit representation of the integer L-
49 1, in most-significant-bit-first order. The M field is the 3-bit representation of the integer (M-2)/2 if
50 M>0 and of the integer 0 if M=0, in most-significant-bit-first order.
51
2. Form the 16-octet B0 field consisting of the 1-octet Flags field defined above, the 15-L octet nonce field
52
N, and the L-octet representation of the length field l(m), as follows:
53
54 B0 = Flags || Nonce N || l(m).

CCM* Mode of Operation
3. Parse the message AuthData as B1 || B2 || ... ||Bt, where each message block Bi is a 16-octet string. 1
2
The CBC-MAC value Xt+1 is defined by
3
4
X0 := 0128; Xi+1 := E(Key, Xi ⊕ Bi ) for i=0, ... , t. (3) 5
6
Here, E(K, x) is the cipher-text that results from encryption of the plaintext x using the established 7
block-cipher encryption function E with key Key; the string 0128 is the 16-octet all-zero bit string. 8
The authentication tag T is the result of omitting all but the leftmost M octets of the CBC-MAC value 9
Xn+1 thus computed. 10
11
12
A.2.3 Encryption transformation 13
14
The data PlaintextData that was established in sub-clause A.2.1 (step 4) and the authentication tag T that 15
was established in sub-clause A.2.2 (step 3) shall be encrypted using the encryption transformation as 16
follows: 17
1. Form the 1-octet Flags field consisting of two 1-bit Reserved fields, and the 3-bit representations of the 18
integers 0 and L, as follows: 19
20
Flags = Reserved || Reserved || 0 || L. (4) 21
22
Here, the two 1-bit Reserved fields are reserved for future expansions and shall be set to ‘0’. The L field 23
is the 3-bit representation of the integer L-1, in most-significant-bit-first order. The ‘0’ field is the 3-bit 24
representation of the integer 0, in most-significant-bit-first order. 25
26
Define the 16-octet Ai field consisting of the 1-octet Flags field defined above, the 15-L octet nonce 27
field N, and the L-octet representation of the integer i, as follows: 28
29
Ai = Flags || Nonce N || Counter i, for i=0, 1, 2, … (5) 30
31
Note that this definition ensures that all the Ai fields are distinct from the B0 fields that are actually used, 32
as those have a Flags field with a non-zero encoding of M in the positions where all Ai fields have an 33
all-zero encoding of the integer 0 (see sub-clause A.2.2, step 2). 34
Parse the message PlaintextData as M1 || ... ||Mt, where each message block Mi is a 16-octet string. 35
36
The ciphertext blocks C1, ... , Ct are defined by 37
38
Ci := E( Key, Ai ) ⊕ Mi for i=1, 2, ... , t. (6) 39
40
The string Ciphertext is the result of omitting all but the leftmost l(m) octets of the string C1 || ... || Ct. 41
Define the 16-octet encryption block S0 by 42
43
S0:= E( Key, A0 ). (7) 44
45
2. The encrypted authentication tag U is the result of XOR-ing the string consisting of the leftmost M 46
octets of S0 and the authentication tag T. 47
48
Output: If any of the above operations has failed, then output ‘invalid’. Otherwise, output the right- 49
concatenation of the encrypted message Ciphertext and the encrypted authentication tag U. 50
51
52
53
54

ZigBee Specification, Annex A
1 A.3 CCM* mode decryption and authentication checking transformation

2
3 Input: The CCM* inverse transformation takes as inputs:
4
5 1. A bit string Key of length keylen bits to be used as the key. Each entity shall have evidence that access to
6 this key is restricted to the entity itself and its intended key-sharing group member(s).
7 2. A nonce N of 15-L octets. Within the scope of any encryption key Key, the nonce value shall be unique.
8
9 3. An octet string c of length l(c) octets, where 0 ≤ l(c)-M < 28L.
10
11 4. An octet string a of length l(a) octets, where 0 ≤ l(a) < 264.
12
13 A.3.1 Decryption transformation
14
15 The decryption transformation involves the following steps, in order:
16
17 1. Parse the message c as C ||U, where the right-most string U is an M-octet string. If this operation fails,
18 output ‘invalid’ and stop. U is the purported encrypted authentication tag. Note that the leftmost string
19 C has length l(c)-M octets.
20 2. Form the padded message CiphertextData by right-concatenating the string C with the smallest non-
21 negative number of all-zero octets such that the octet string CiphertextData has length divisible by 16.
22
3. Use the encryption transformation in sub-clause A.2.3, with as inputs the data CipherTextData and the
23
tag U.
24
25 4. Parse the output string resulting from applying this transformation as m || T, where the right-most string
26 T is an M-octet string. T is the purported authentication tag. Note that the leftmost string m has length
27 l(c)-M octets.
28
29
A.3.2 Authentication checking transformation
30
31 The authentication checking transformation involves the following steps:
32
33 1. Form the message AuthData using the input transformation in sub-clause A.2.1, with as inputs the
34 string a and the octet string m that was established in sub-clause A.3.1 (step 4).
35
2. Use the authentication transformation in sub-clause A.2.2, with as input the message AuthData.
36
37 3. Compare the output tag MACTag resulting from this transformation with the tag T that was established
38 in sub-clause A.3.1 (step 4). If MACTag=T, output ‘valid’; otherwise, output ‘invalid’ and stop.
39 Output: If any of the above verifications has failed, then output ‘invalid’ and reject the octet string m.
40 Otherwise, accept the octet string m and accept one of the key sharing group member(s) as the source of
41 m.
42
43
44 A.4 Restrictions
45
46
All implementations shall limit the total amount of data that is encrypted with a single key. The CCM*
47
encryption transformation shall invoke not more than 261 block-cipher encryption function operations in
48
total, both for the CBC-MAC and for the CTR encryption operations.
49
50 At CCM* decryption, one shall verify the (truncated) CBC-MAC before releasing any information, such as,
51 e.g., plaintext. If the CBC-MAC verification fails, only the fact that the CBC-MAC verification failed shall
52 be exposed; all other information shall be destroyed.
53
54

Annex B Security Building Blocks 1
2
3
This annex specifies the cryptographic primitives and mechanisms that are used to implement the security 4
protocols in this standard. 5
6
7
B.1 Symmetric-key cryptographic building blocks 8
9
The following symmetric-key cryptographic primitives and data elements are defined for use with all 10
security-processing operations specified in this standard. 11
12
13
B.1.1 Block-cipher 14
15
The block-cipher used in this specification shall be the Advanced Encryption Standard AES-128, as
16
specified in FIPS Pub 197 [B8]. This block-cipher has a key size keylen that is equal to the block size, in
17
bits, i.e., keylen=128.
18
19
B.1.2 Mode of operation 20
21
The block-cipher mode of operation used in this specification shall be the CCM* mode of operation, as 22
specified in Annex A, with the following instantiations: 23
24
1. Each entity shall use the block-cipher E as specified in sub-clause B.1.1;
25
2. All octets shall be represented as specified in section "Preface"; 26
3. The parameter L shall have the integer value 2; 27
28
4. The parameter M shall have one of the following integer values: 0, 4, 8, or 16. 29
30
B.1.3 Cryptographic hash function 31
32
The cryptographic hash function used in this specification shall be the block-cipher based cryptographic 33
hash function specified in clause B.6, with the following instantiations: 34
35
1. Each entity shall use the block-cipher E as specified in section sub-clause B.1.1; 36
2. All integers and octets shall be represented as specified in section "Preface". 37
38
The Matyas-Meyer-Oseas hash function (specified in clause B.6) has a message digest size hashlen that is 39
equal to the block size, in bits, of the established block-cipher. 40
41
42
B.1.4 Keyed hash function for message authentication 43
The keyed hash message authentication code (HMAC) used in this specification shall be HMAC, as 44
specified in the FIPS Pub 198 [B9], with the following instantiations: 45
46
1. Each entity shall use the cryptographic hash H function as specified in sub-clause B.1.3; 47
48
2. The block size B shall have the integer value 16 (this block size specifies the length of the data integrity
49
key, in bytes, that is used by the keyed hash function, i.e., it uses a 128-bit data integrity key);
50
3. The output size HMAClen of the HMAC function shall have the same integer value as the message 51
digest parameter hashlen as specified in sub-clause B.1.3. 52
53
54

ZigBee Specification, Annex B
1 B.1.5 Specialized keyed hash function for message authentication

2
3 The specialized208 keyed hash message authentication code used in this specification shall be the keyed hash
4 message authentication code, as specified in sub-clause B.1.4.
5
6 B.1.6 Challenge domain parameters
7
8 The challenge domain parameters used in the specification shall be as specified in sub-clause B.3.1, with the
9 following instantiation: (minchallengelen, maxchallengelen)=(128,128).
10
11 All challenges shall be validated using the challenge validation primitive as specified in clause B.4.
12
13
14 B.2 Key Agreement Schemes
15
16
17 B.2.1 Symmetric-key key agreement scheme
18
The symmetric-key key agreement protocols in this standard shall use the full symmetric-key with key
19
confirmation scheme as specified in clause B.7, with the following instantiations:
20
21 1. Each entity shall be identified as specified in "Preface";
22
23 2. Each entity shall use the HMAC-scheme as specified in sub-clause B.1.4;
24 3. Each entity shall use the specialized HMAC-scheme as specified in sub-clause B.1.5;
25
4. Each entity shall use the cryptographic hash function as specified in sub-clause B.1.3.,
26
27 5. The parameter keydatalen shall have the same integer value as the key size parameter keylen as
28 specified in sub-clause B.1.1;
29 6. The parameter SharedData shall be the empty string; parameter shareddatalen shall have the integer
30 value 0;
31
32 7. The optional parameters Text1 and Text2 as specified in sub-clause B.7.1 and sub-clause B.7.2 shall
33 both be the empty string.
34 8. Each entity shall use the challenge domain parameters as specified in sub-clause B.1.6.
35
36 9. All octets shall be represented as specified in section "Preface".
37
38
39 B.3 Challenge Domain Parameter Generation and Validation
40
41 This section specifies the primitives that shall be used to generate and validate challenge domain parameters.
42
Challenge domain parameters impose constraints on the length(s) of bit challenges a scheme expects. As
43
such, this determine a bound on the entropy of challenges and, thereby, on the security of the cryptographic
44
schemes in which these challenges are used. In most schemes, the challenge domain parameters will be such
45
that only challenges of a fixed length will be accepted (e.g., 128-bit challenges). However, one may define
46
the challenge domain parameters such that challenges of varying length might be accepted. The latter is
47
useful in contexts where entities that wish to engage in cryptographic schemes might have a bad random
48
49
50
51 208This refers to a MAC scheme where the MAC function has the additional property that it is also pre-image and collision resistant for
52 parties knowing the key (see also Remark 9.8 of [B18]). Such MAC functions allow key derivation in contexts where unilateral key
53 control is undesirable.
54

Security Building Blocks
number generator on-board. Allowing both entities that engage in a scheme to contribute sufficiently long 1
inputs enables each of these to contribute sufficient entropy to the scheme at hand. 2
3
In this standard, challenge domain parameters will be shared by a number of entities using a scheme of the 4
standard. The challenge domain parameters may be public; the security of the system does not rely on these 5
parameters being secret. 6
7
B.3.1 Challenge Domain Parameter Generation 8
9
Challenge domain parameters shall be generated using the following routine. 10
11
Input: This routine does not take any input. 12
13
Actions: The following actions are taken: 14
1. Choose two nonnegative integers minchallengelen and maxchallengelen, such that minchallengelen ≤ 15
maxchallengelen. 16
17
Output: Challenge domain parameters D=(minchallengelen, maxchallengelen). 18
19
20
B.3.2 Challenge Domain Parameter Verification 21
22
Challenge domain parameters shall be verified using the following routine.
23
Input: Purported set of challenge domain parameters D=(minchallengelen, maxchallengelen). 24
25
Actions: The following checks are made: 26
27
1. Check that minchallengelen and maxchallengelen are nonnegative integers. 28
2. Check that minchallengelen ≤ maxchallengelen. 29
30
Output: If any of the above verifications has failed, then output ‘invalid’ and reject the challenge domain 31
parameters. Otherwise, output ‘valid’ and accept the challenge domain parameters. 32
33
34
B.4 Challenge Validation Primitive 35
36
Challenge validation refers to the process of checking the length properties of a challenge. It is used to check 37
whether a challenge to be used by a scheme in the standard has sufficient length (e.g., messages that are too 38
short are discarded, due to insufficient entropy). 39
40
The challenge validation primitive is used in clause B.7. 41
42
Input: The input of the validation transformation is a valid set of challenge domain parameters
43
D=(minchallengelen, maxchallengelen), together with the bit string Challenge.
44
Actions: The following actions are taken: 45
46
1. Compute the bit-length challengelen of the bit string Challenge. 47
48
2. Verify that challengelen ∈ [minchallengelen, maxchallengelen]. (That is, verify that the challenge has
49
an appropriate length.)
50
Output: If the above verification fails, then output ‘invalid’ and reject the challenge. Otherwise, output 51
‘valid’ and accept the challenge. 52
53
54

1 B.5 Secret Key Generation (SKG) Primitive

2
3 This section specifies the SKG primitive that shall be used by the symmetric-key key agreement schemes
4 specified in this standard.
5
6 This primitive derives a shared secret value from a challenge owned by an entity U1 and a challenge owned
7 by an entity U2 when all the challenges share the same challenge domain parameters. If the two entities both
8 correctly execute this primitive with corresponding challenges as inputs, the same shared secret value will
9 be produced.
10
11 The shared secret value shall be calculated as follows:
12
Prerequisites: The following are the prerequisites for the use of the SKG primitive:
13
14 1. Each entity shall be bound to a unique identifier (e.g., distinguished names). All identifiers shall be bit
15 strings of the same length entlen bits. Entity U1’s identifier will be denoted by the bit string U1. Entity
16 U2’s identifier will be denoted by the bit string U2.
17
18 2. A specialized209 MAC scheme shall have been chosen, with tagging transformation as specified in
19 Section 5.7.1 of ANSI X9.63-2001 [B7]. The length in bits of the keys used by the specialized MAC
20 scheme is denoted by mackeylen.
21
22 Input: The SKG primitive takes as input:
23
24 1. A bit string MACKey of length mackeylen bits to be used as the key of the established specialized MAC
25 scheme.
26 2. A bit string QEU1 owned by U1.
27
28 3. A bit string QEU2 owned by U2.
29
Actions: The following actions are taken:
30
31 1. Form the bit string consisting of U1’s identifier, U2’s identifier, the bit string QEU1 corresponding to
32 U1’s challenge, and the bit string QEU2 corresponding to QEU2’s challenge:
33
34
MacData = U1 || U2 || QEU1 || QEU2. (8)
35
36
2. Calculate the tag MacTag for MacData under the key MacKey using the tagging transformation of the
37
established specialized MAC scheme:
38
39
MacTag = MACMacKey(MacData). (9)
40
41
3. If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop.
42
43 4. Set Z=MacTag.
44
45 Output: The bit string Z as the shared secret value.
46
47
48
49
50
51
209This refers to a MAC scheme where the MAC function has the additional property that it is also pre-
52
53 image and collision resistant for parties knowing the key (see also Remark 9.8 of [B18]). Such MAC
54 functions allow key derivation in contexts where unilateral key control is undesirable.

B.6 Block-Cipher-Based Cryptographic Hash Function 1

2
This section specifies the Matyas-Meyer-Oseas hash function, a cryptographic hash function based on 3
block-ciphers. We define this hash function for block-ciphers with a key size that is equal to the block size, 4
such as AES-128, and with a particular choice for the fixed initialization vector IV (we take IV=0). For a 5
more general definition of the Matyas-Meyer-Oseas hash function, we refer to Section 9.4.1 of [B18]. 6
7
Prerequisites: The following are the prerequisites for the operation of Matyas-Meyer-Oseas hash function: 8
9
1. A block-cipher encryption function E shall have been chosen, with a key size that is equal to the block 10
size. The Matyas-Meyer-Oseas hash function has a message digest size that is equal to the block size of 11
the established encryption function. It operates on bit strings of length less than 2n, where n is the block 12
size, in octets, of the established block-cipher. 13
2. A fixed representation of integers as binary strings or octet strings shall have been chosen. 14
15
Input: The input to the Matyas-Meyer-Oseas hash function is as follows: 16
17
1. A bit string M of length l bits, where 0≤ l < 2n. 18
19
Actions: The hash value shall be derived as follows: 20
21
1. Pad the message M according to the following method:
22
a) Right-concatenate to the message M the binary consisting of the bit ‘1’ followed by k ‘0’ bits, where 23
k is the smallest non-negative solution to the equation 24
25
l+1+k ≡ 7n (mod 8n). (10) 26
27
b) Form the padded message M’ by right-concatenating to the resulting string the n-bit string that is 28
equal to the binary representation of the integer l. 29
2. Parse the padded message M’ as M1 || M2|| … || Mt where each message block Mi is an n-octet string. 30
31
3. The output Hasht is defined by 32
33
Hash0 =08n; Hashj =E(Hashj-1, Mj) ⊕ Mj for j=1,…,t. (11) 34
35
Here, E(K, x) is the ciphertext that results from encryption of the plaintext x, using the established 36
block-cipher encryption function E with key K; the string 08n is the n-octet all-zero bit string. 37
38
Output: The bit string Hasht as the hash value. 39
40
Note that the cryptographic hash function operates on bit strength of length less than 2n bits, where n is the 41
block size (or key size) of the established block cipher, in bytes. For example, the Matyas-Meyer-Oseas hash 42
function with AES-128 operates on bit strings of length less than 216 bits. It is assumed that all hash function 43
calls are on bit strings of length less than 2n bits. Any scheme attempting to call the hash function on a bit 44
string exceeding 2n bits shall output ‘invalid’ and stop. 45
46
47
B.7 Symmetric-Key Authenticated Key Agreement Scheme 48
49
This section specifies the full symmetric-key key agreement with key confirmation scheme. A MAC scheme 50
is used to provide key confirmation. 51
52
Figure 90 illustrates the messaging involved in the use of the full symmetric-key key agreement with key
53
confirmation scheme.
54

1
2
3 Key
4
5
6
QEU
7
8 U V
9
10 QEV, MACMacKey(0216 || V || U || QEV || QEU || [Text1]), [Text1]
11
12
13
14 MACMacKey(0316 || U || V || QEU || QEV || [Text2]), [Text2]
15
16
Figure 90 Symmetric-Key Authenticated Key Agreement Scheme
17
18 The scheme is ‘asymmetric’ so two transformations are specified. U uses the transformation specified in
19 sub-clause B.7.1 to agree on keying data with V if U is the protocol’s initiator, and V uses the transformation
20 specified in sub-clause B.7.2 to agree on keying data with U if V is the protocol’s responder.
21
22 The essential difference between the role of the initiator and the role of the responder is merely that the
23 initiator sends the first pass of the exchange.
24
25 If U executes the initiator transformation, and V executes the responder transformation with the shared
26 secret keying material as input, then U and V will compute the same keying data.
27
Prerequisites: The following are the prerequisites for the use of the scheme:
28
29 1. Each entity has an authentic copy of the system’s challenge domain parameters D=(minchallengelen,
30 maxchallengelen).
31
32 2. Each entity shall have access to a bit string Key of length keylen bits to be used as the key. Each party
33 shall have evidence that access to this key is restricted to the entity itself and the other entity involved in
34 the symmetric-key authenticated key agreement scheme.
35 3. Each entity shall be bound to a unique identifier (e.g., distinguished names). All identifiers shall be bit
36 strings of the same length entlen bits. Entity U’s identifier will be denoted by the bit string U. Entity V’s
37 identifier will be denoted by the bit string V.
38
4. Each entity shall have decided which MAC scheme to use as specified in Section 5.7 of ANSI X9.63-
39
2001 [B7]. The length in bits of the keys used by the chosen MAC scheme is denoted by mackeylen.
40
41 5. A cryptographic hash function shall have been chosen for use with the key derivation function.
42
6. A specialized210 MAC scheme shall have been chosen for use with the secret key generation primitive
43
with tagging transformation as specified in Section 5.7.1 of ANSI X9.63-2001 [B7]. The length in bits
44
of the keys used by the specialized MAC scheme is denoted by keylen.
45
46 7. A fixed representation of octets as binary strings shall have been chosen. (e.g., most-significant-bit-first
47 order or least-significant-bit-first order).
48
49
50
51
52 210
This refers to a MAC function with the additional property that it is also pre-image and collision resistant for parties knowing the
53 key (see also Remark 9.8 of [B18]. Specialized MAC functions allow key derivation in contexts where unilateral key control is undesir-
54 able.

B.7.1 Initiator Transformation 1

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

1 11. Calculate the tag MacTag2 on MacData2 under the key MacKey using the tagging transformation of the
2 appropriate MAC scheme specified in Section 5.7.1 of ANSI X9.63-2001 [B7]:
3
4 MacTag2 = MACMacKey(MacData2). (14)
5
6 12. If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send MacTag2 and, if present,
7 Text2 to V.
8
9 Output: If any of the above verifications has failed, then output ‘invalid’ and reject the bit strings KeyData
10 and Text1. Otherwise, output ‘valid’, accept the bit string KeyData as the keying data of length keydatalen
11 bits shared with V and accept V as the source of the bit string Text1 (if present).
12
13
14 B.7.2 Responder Transformation
15
V shall execute the following transformation to agree on keying data with U if V is the protocol’s responder.
16
V shall obtain an authentic copy of U’s identifier and an authentic copy of the static secret key Key shared
17
with U.
18
19 Input: The input to the responder transformation is:
20
21 1. A challenge QEU’ purportedly owned by U.
22
2. An integer keydatalen that is the length in bits of the keying data to be generated.
23
24 3. (Optional) A bit string SharedData of length shareddatalen bits that consists of some data shared by U
25 and V.
26 4. (Optional) A bit string Text1 that consists of some additional data to be provided from V to U.
27
28 Ingredients: The responder transformation employs the challenge generation primitive in Section 5.3 of
29 ANSI X9.63-2001 [B7], the challenge validation primitive in sub-clause B.3.2, the SKG primitive in
30 clause B.5, the key derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7], and one of the MAC
31 schemes in Section 5.7 of ANSI X9.63-2001 [B7].
32
33 Actions: Keying data shall be derived as follows:
34
35 1. Verify that QEU’ is a valid challenge for the challenge domain parameters D as specified in sub-
36 clause B.3.2. If the validation primitive rejects the challenge, output ‘invalid’ and stop.
37 2. Use the challenge generation primitive in Section 5.3 of ANSI X9.63-2001 [B7] to generate a challenge
38 QEV for the challenge domain parameters D. Send to U the challenge QEV.
39
3. Use the SKG primitive in clause B.5 to derive a shared secret bit string Z from the challenges Q1=QEU’
40
41 owned by U and Q2=QEV owned by V, using as key the shared key Key. If the SKG primitive outputs
42 ‘invalid’, output ‘invalid’ and stop.
43 4. Use the key derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7] with the established hash
44 function to derive keying data KKeyData of length mackeylen+keydatalen bits from the shared secret
45 value Z and the shared data [SharedData].
46
47 5. Parse the leftmost mackeylen bits of KKeyData as a MAC key MacKey and the remaining bits as keying
48 data KeyData.
49 6. Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the bit string QEV, the bit
50 string QEU’, and, optionally, a bit string Text1:
51
52 MacData1 = 0216 || V || U || QEV || QEU’ || [Text1]. (15)
53
54

7. Calculate the tag MacTag1 for MacData1 under the key MacKey using the tagging transformation of the 1
appropriate MAC scheme specified in Section 5.7 of ANSI X9.63-2001 [B7]: 2
3
MacTag1 = MACMacKey(MacData1). (16) 4
5
If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send to U, if present the bit 6
string Text1, and MacTag1. 7
8
8. Then receive from U an optional bit string Text2 and a purported tag MacTag2’. If this data is not 9
9. Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the bit string QEU’ 11
corresponding to U’s purported challenge, the bit string QEV corresponding to V’s challenge, and the 12
bit string Text2 (if present): 13
14
15
MacData2 = 0316 || U || V || QEU’ || QEV || [Text2]. (17)
16
17
10. Verify that MacTag2’ is the valid tag on MacData2 under the key MacKey using the tag checking
18
transformation of the appropriate MAC scheme specified in Section 5.7 ANSI X9.63-2001 [B7]. If the 19
tag checking transformation outputs ‘invalid’, output ‘invalid’ and stop. 20
Output: If any of the above verifications has failed, then output ‘invalid’ and reject the bit strings KeyData 21
and Text2. Otherwise, output ‘valid’, accept the bit string KeyData as the keying data of length keydatalen 22
bits shared with U and accept U as the source of the bit string Text2 (if present). 23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Annex C Test Vectors for Cryptographic Building 1
2
Blocks 3
4
5
This annex provides sample test vectors for the ZigBee community, aimed at assisting in building 6
interoperable security implementations. The sample test vectors are provided as is, pending independent 7
validation. 8
9
10
C.1 Data Conversions 11
12
For test vectors, see Appendix J1 of ANSI X9.63-2001 [B7]. 13
14
15
C.2 AES Block Cipher 16
17
This annex provides sample test vectors for the block-cipher specified in sub-clause B.1.1. 18
19
For test vectors, see FIPS Pub 197 [B8]. 20
21
22
C.3 CCM* Mode Encryption and Authentication Transformation 23
24
This annex provides sample test vectors for the mode of operation as specified in sub-clause B.1.2. 25
26
Prerequisites: The following prerequisites are established for the operation of the mode of operation: 27
1. The parameter M shall have the integer value 8. 28
29
Input: The inputs to the mode of operation are: 30
31
1. The key Key of size keylen=128 bits to be used: 32
33
Key = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF. (18) 34
35
2. The nonce N of 15-L=13 octets to be used: 36
37
Nonce = A0 A1 A2 A3 A4 A5 A6 A7 || 03 02 01 00 || 06. (19) 38
39
3. The octet string m of length l(m)=23 octets to be used:
40
41
m = 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E. (20)
42
4. The octet string a of length l(a)=8 octets to be used: 43
44
a = 00 01 02 03 04 05 06 07. (21) 45
46
47
C.3.1 Input Transformation 48
49
This step involves the transformation of the input strings a and m to the strings AuthData and
50
PlainTextData, to be used by the authentication transformation and the encryption transformation,
51
respectively.
52
1. Form the octet string representation L(a) of the length l(a) of the octet string a: 53
54

ZigBee Specification, Annex C
1 L(a) = 00 08.
2
3 2. Right-concatenate the octet string L(a) and the octet string a itself:
4
L(a) || a = 00 08 || 00 01 02 03 04 05 06 07.
5
6 3. Form the padded message AddAuthData by right-concatenating the resulting string with the smallest
7 non-negative number of all-zero octets such that the octet string AddAuthData has length divisible by
8 16:
9
10 AddAuthData = 00 08 || 00 01 02 03 04 05 06 07 || 00 00 00 00 00 00.
11
12 4. Form the padded message PlaintextData by right-concatenating the octet string m with the smallest
13 non-negative number of all-zero octets such that the octet string PlaintextData has length divisible by
14 16:
15
PlaintextData = 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 ||
16
17 18 19 1A 1B 1C 1D 1E || 00 00 00 00 00 00 00 00 00.
18
19 5. Form the message AuthData consisting of the octet strings AddAuthData and PlaintextData:
20
21 AuthData = 00 08 00 01 02 03 04 05 06 07 00 00 00 00 00 00 ||
22
08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17
23
24 18 19 1A 1B 1C 1D 1E 00 00 00 00 00 00 00 00 00.
25
26
27 C.3.2 Authentication Transformation
28
29 The data AuthData that was established above shall be tagged using the tagging transformation as follows:
30 1. Form the 1-octet Flags field as follows:
31
32 Flags = 59.
33
34 2. Form the 16-octet B0 field as follows:
35
36 B0 = 59 || A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 || 00 17.
37
3. Parse the message AuthData as B1 || B2 ||B3, where each message block Bi is a 16-octet string.
38
39 4. The CBC-MAC value X4 is computed as follows:
40
41 i Bi Xi
42
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
43
44 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
45
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
46
47 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
48
49 4 æ B9 D7 89 67 04 BC FA 20 B2 10 36 74 45 F9 83 D6
50
51
52 The authentication tag T is the result of omitting all but the leftmost M=8 octets of the CBC-MAC value X4:
53 T = B9 D7 89 67 04 BC FA 20.
54

This is an unapproved Standards Draft, subject to change.
Test Vectors for Cryptographic Building Blocks
C.3.3 Encryption Transformation 1

2
The data PlaintextData shall be encrypted using the encryption transformation as follows: 3
4
1. Form the 1-octet Flags field as follows: 5
Flags = 01. 6
7
2. Define the 16-octet Ai field as follows: 8
9
i Ai 10
11
0 01 || A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 || 00 00
12
1 01 || A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 || 00 01 13
14
2 01 || A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 || 00 02 15
16
17
3. Parse the message PlaintextData as M1 ||M2, where each message block Mi is a 16-octet string.
18
4. The ciphertext blocks C1, C2 are computed as follows: 19
20
i AES(Key,Ai) Ci = AES(Key,Ai) ⊕ Mi 21
22
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
23
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 24
25
26
5. The string Ciphertext is the result of omitting all but the leftmost l(m)=23 octets of the string C1 ||C2: 27
28
CipherText = 1A 55 A3 6A BB 6C 61 0D 06 6B 33 75 64 9C EF 10 || D4 66 4E CA D8 54 A8. 29
30
6. Define the 16-octet encryption block S0 by 31
32
S0 = E(Key, A0 )= B3 5E D5 A6 DC 43 6E 49 D6 17 2F 54 77 EB B4 39.
33
7. The encrypted authentication tag U is the result of XOR-ing the string consisting of the leftmost M=8 34
octets of S0 and the authentication tag T: 35
36
U = 0A 89 5C C1 D8 FF 94 69. 37
38
Output: the right-concatenation c of the encrypted message Ciphertext and the encrypted authentication tag 39
U: 40
41
c = 1A 55 A3 6A BB 6C 61 0D 06 6B 33 75 64 9C EF 10 || D4 66 4E CA D8 54 A8 || 42
43
0A 89 5C C1 D8 FF 94 69.
44
45
46
C.4 CCM* Mode Decryption and Authentication Checking Transformation
47
48
This annex provides sample test vectors for the inverse of the mode of operation as specified in sub-clause
49
B.1.2.
50
Prerequisites: The following prerequisites are established for the operation of the mode of operation: 51
52
1. The parameter M shall have the integer value 8. 53
54

1 Input: The inputs to the inverse mode of operation are:

2
3 1. The key Key of size keylen=128 bits to be used:
4
Key = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF.
5
6 2. The nonce N of 15-L=13 octets to be used:
7
8 Nonce = A0 A1 A2 A3 A4 A5 A6 A7 || 03 02 01 00 || 06.
9
10 3. The octet string c of length l(c)=31 octets to be used:
11
c= 1A 55 A3 6A BB 6C 61 0D 06 6B 33 75 64 9C EF 10 || D4 66 4E CA D8 54 A8 ||
12
0A 89 5C C1 D8 FF 94 69.
13
14 4. The octet string a of length l(a)=8 octets to be used:
15
16 a = 00 01 02 03 04 05 06 07.
17
18
19
C.4.1 Decryption Transformation
20 The decryption transformation involves the following steps, in order:
21
22 1. Parse the message c as C ||U, where the right-most string U is an M-octet string:
23
24 C = 1A 55 A3 6A BB 6C 61 0D 06 6B 33 75 64 9C EF 10 || D4 66 4E CA D8 54 A8;
25
26 U = 0A 89 5C C1 D8 FF 94 69.
27 2. Form the padded message CiphertextData by right-concatenating the string C with the smallest non-
28 negative number of all-zero octets such that the octet string CiphertextData has length divisible by 16.
29
30 CipherTextData = 1A 55 A3 6A BB 6C 61 0D 06 6B 33 75 64 9C EF 10 ||
31 D4 66 4E CA D8 54 A8 || 00 00 00 00 00 00 00 00.
32
33 3. Form the 1-octet Flags field as follows:
34
35 Flags = 01.
36 4. Define the 16-octet Ai field as follows:
37
38 i Ai
39
40 0 01 || A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 || 00 00
41 1 01 || A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 || 00 01
42
43 2 01 || A0 A1 A2 A3 A4 A5 A6 A7 03 02 01 00 06 || 00 02
44
45
46 5. Parse the message CiphertextData as C1 ||C2, where each message block Ci is a 16-octet string.
47 6. The ciphertext blocks P1, P2 are computed as follows:
48
49 i AES(Key,Ai) Pi= AES(Key,Ai) ⊕ Ci
50
51 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
52 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
53
54

7. The octet string m is the result of omitting all but the leftmost l(m)=23 octets of the string P1 || P2: 1
2
m = 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 || 18 19 1A 1B 1C 1D 1E. 3
4
8. Define the 16-octet encryption block S0 by 5
6
S0 = E(Key, A0 )= B3 5E D5 A6 DC 43 6E 49 D6 17 2F 54 77 EB B4 39.
7
9. The purported authentication tag T is the result of XOR-ing the string consisting of the leftmost M=8 8
octets of S0 and the octet string U: 9
10
T = B9 D7 89 67 04 BC FA 20. 11
12
13
C.4.2 Authentication Checking Transformation 14
15
The authentication checking transformation involves the following steps:
16
1. Form the message AuthData using the input transformation in sub-clause C.3.1, with as inputs the string 17
a and the octet string m that was established in sub-clause C.4.1(step 7.): 18
19
AuthData = 08 00 01 02 03 04 05 06 07 00 00 00 00 00 00 00 || 20
08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 21
18 19 1A 1B 1C 1D 1E 00 00 00 00 00 00 00 00 00. 22
23
2. Use the authentication transformation in sub-clause C.3.2, with as input the message AuthData to 24
compute the authentication tag MACTag: 25
26
MACTag = B9 D7 89 67 04 BC FA 20.
27
3. Compare the output tag MACTag resulting from this transformation with the tag T that was established 28
in sub-clause C.4.1(step 9.): 29
30
T = B9 D7 89 67 04 BC FA 20 = MACTag. 31
32
Output: Since MACTag=T, output ‘valid’ and accept the octet string m and accept one of the key sharing 33
group member(s) as the source of m. 34
35
36
C.5 Cryptographic Hash Function 37
38
This annex provides sample test vectors for the cryptographic hash function specified in clause C.5. 39
40
41
C.5.1 Test Vector Set 1
42
Input: The input to the cryptographic hash function is as follows: 43
44
1. The bit string M of length l=8 bits to be used: 45
46
M=C0. 47
48
Actions: The hash value shall be derived as follows:
49
1. Pad the message M by right-concatenating to M the bit ‘1’ followed by the smallest non-negative 50
number of ‘0’ bits, such that the resulting string has length 14 (mod 16) octets: 51
52
C0 || 80 00 00 00 00 00 00 00 00 00 00 00 00. 53
54

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

C.6 Keyed Hash Function for Message Authentication 1

2
This annex provides sample test vectors for the keyed hash function for message authentication as specified 3
in clause C.6. 4
5
6
C.6.1 Test Vector Set 1 7
8
Input: The input to the keyed hash function is as follows:
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
13
2. The bit string M of length l=8 bits to be used: 14
15
M=C0.
16
Actions: The keyed hash value shall be derived as follows: 17
18
1. Create the 16-octet string ipad (inner pad) as follows: 19
20
ipad = 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36. 21
22
2. Form the inner key Key1 by XOR-ing the bit string Key and the octet string ipad:
23
Key1 = Key ⊕ ipad = 76 77 74 75 72 73 70 71 7E 7F 7C 7D 7A 7B 78 79. 24
25
3. Form the padded message M1 by right-concatenating the bit string Key1 with the bit string M: 26
27
M1 = Key1 || M = 76 77 74 75 72 73 70 71 7E 7F 7C 7D 7A 7B 78 79 || C0. 28
29
4. Compute the hash value Hash1 of the bit string M1: 30
31
Hash1 = 3C 3D 53 75 29 A7 A9 A0 3F 66 9D CD 88 6C B5 2C. 32
33
5. Create the 16-octet string opad (outer pad) as follows:
34
opad = 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C. 35
36
6. Form the outer key Key2 by XOR-ing the bit string Key and the octet string opad: 37
38
Key2 = Key ⊕ opad = 1C 1D 1E 1F 18 19 1A 1B 14 15 16 17 10 11 12 13. 39
40
7. Form the padded message M2 by right-concatenating the bit string Key2 with the bit string Hash1: 41
42
M2 = Key2 || Hash1 =1C 1D 1E 1F 18 19 1A 1B 14 15 16 17 10 11 12 13 ||
43
3C 3D 53 75 29 A7 A9 A0 3F 66 9D CD 88 6C B5 2C.
44
8. Compute the hash value Hash2 of the bit string M2: 45
46
Hash2 = 45 12 80 7B F9 4C B3 40 0F 0E 2C 25 FB 76 E9 99. 47
48
Output: the 16-octet string HMAC = Hash2 = 45 12 80 7B F9 4C B3 40 0F 0E 2C 25 FB 76 E9 99. 49
50
51
52
Input: The input to the keyed hash function is as follows: 53
54

1 1. The key Key of size keylen=256 bits to be used:

2
3 Key = 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F ||
4 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F.
5
2. The bit string M of length l=128 bits to be used:
6
7 M = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF.
8
9 Actions: The keyed hash value shall be derived as follows:
10
11 1. Compute the hash value Key0 of the bit string Key:
12
13 Key0 = 22 F4 0C BE 15 66 AC CF EB 77 77 E1 C4 A9 BB 43.
14 2. Create the 16-octet string ipad (inner pad) as follows:
15
16 ipad = 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36.
17
18 3. Form the inner key Key1 by XOR-ing the bit key Key0 and the octet string ipad:
19
20 Key1 = Key0 ⊕ ipad = 14 C2 3A 88 23 50 9A F9 DD 41 41 D7 F2 9F 8D 75.
21
4. Form the padded message M1 by right-concatenating the bit string Key1 with the bit string M:
22
23
M1 = Key1 || M = 14 C2 3A 88 23 50 9A F9 DD 41 41 D7 F2 9F 8D 75 ||
24
C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF.
25
26 5. Compute the hash value Hash1 of the bit string M1:
27
28 Hash1 = 42 65 BE 29 74 55 8C A2 7B 77 85 AC 73 F2 22 10.
29
30 6. Create the 16-octet string opad (outer pad) as follows:
31
32 opad = 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C 5C.
33 7. Form the outer key Key2 by XOR-ing the bit string Key0 and the octet string opad:
34
35 Key2 = Key0 ⊕ opad = 7E A8 50 E2 49 3A F0 93 B7 2B 2B BD 98 F5 E7 1F.
36
37 8. Form the padded message M2 by right-concatenating the bit string Key2 with the bit string Hash1:
38
39 M2 = Key2 || Hash1 = 7E A8 50 E2 49 3A F0 93 B7 2B 2B BD 98 F5 E7 1F ||
40 42 65 BE 29 74 55 8C A2 7B 77 85 AC 73 F2 22 10.
41
42 9. Compute the hash value Hash2 of the bit string M2:
43
Hash2 = A3 B0 07 99 84 BF 15 57 F7 4A 0D 63 87 E0 A1 1A.
44
45 Output: the 16-octet string HMAC = Hash2 = A3 B0 07 99 84 BF 15 57 F7 4A 0D 63 87 E0 A1 1A.
46
47
48
C.7 Specialized Keyed Hash Function for Message Authentication
49
50
This annex provides sample test vectors for the specialized keyed hash function for message authentication
51
as specified in clause C.7.
52
53 For test vectors, see clause C.6.
54

C.8 Symmetric-Key Key Agreement Scheme 1

2
This annex provides sample test vectors for the symmetric-key key agreement scheme as specified in clause 3
C.8. 4
5
Prerequisites: The following are the prerequisites for the use of the scheme: 6
7
1. The unique identifiers of the entities U and V to be used: 8
9
U’s identifier: U=55 73 65 72 20 55 0D 0A;
10
V’s identifier: V=55 73 65 72 20 56 0D 0A. 11
12
2. The key Key of length keylen=128 bits to be used: 13
14
Key = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF. 15
16
3. The optional parameter SharedData of length shareddatalen=48 bits to be used:
17
SharedData = D0 D1 D2 D3 D4 D5. 18
19
20
C.8.1 Initiator Transformation 21
22
U obtains an authentic copy of V’s identifier and an authentic copy of the static secret key Key shared with
23
V.
24
Input: The input to the initiator transformation is: 25
26
1. The length keydatalen in bits of the keying data to be generated: keydatalen=128. 27
28
2. The optional bit string Text2 to be used is not present, i.e., Text2 = ε (the empty string).
29
Actions: U derives keying data as follows: 30
31
QEU for the challenge domain parameters D. Send QEU to V. 33
34
QEU = 9E 3F 0C 19 05 4B 05 44 D5 A7 17 62 0A F2 7D 96.
35
2. Then receive from V a challenge QEV’ purportedly owned by V. If this value is not received, output 36
‘invalid’ and stop. 37
QEV’ = BF 14 DF 94 94 39 D2 CE 24 C9 09 53 B5 72 D6 53. 38
39
3. Receive from V an optional bit string Text1, and a purported tag MacTag1’. If these values are not
40
Text1 = ε (the empty string); 42
43
MacTag1’ = E6 C3 DE 1F E8 63 15 B9 E6 A0 2B 44 FF 63 D8 D0.
44
4. Verify that QEV’ is a valid challenge for the challenge domain parameters D as specified in sub-clause 45
B.3.2. If the validation primitive rejects the challenge, output ‘invalid’ and stop. 46
5. Use the SKG primitive in clause B.5 to derive a shared secret bit string Z from the challenges Q1=QEU 47
owned by U and Q2=QEV’ owned by V, using as key the shared key Key. If the SKG primitive outputs 48
49
‘invalid’, output ‘invalid’ and stop.
50
a) Form the bit string MACData = U || V || QEU || QEV’: 51
MACData = 55 73 65 72 20 55 0D 0A || 55 73 65 72 20 56 0D 0A || 52
9E 3F 0C 19 05 4B 05 44 D5 A7 17 62 0A F2 7D 96 || 53
BF 14 DF 94 94 39 D2 CE 24 C9 09 53 B5 72 D6 53. 54

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

Output: output ‘valid’ and accept the 128-bit string KeyData = 72 57 7D 02 CC E1 39 33 1A BF F4 0B C5 6E 1

A3 7F as the keying data shared with V. 2
3
4
C.8.2 Responder Transformation 5
V obtains an authentic copy of U’s identifier and an authentic copy of the static secret key Key shared with 6
U. 7
8
Input: The input to the responder transformation is: 9
10
1. A challenge QEU’ purportedly owned by U. 11
QEU’ = 9E 3F 0C 19 05 4B 05 44 D5 A7 17 62 0A F2 7D 96. 12
13
2. The length keydatalen in bits of the keying data to be generated: keydatalen=128. 14
3. The optional bit string Text1 to be used is not present, i.e., Text1 = ε (the empty string). 15
16
Actions: V derives keying data as follows: 17
18
1. Verify that QEU’ is a valid challenge for the challenge domain parameters D as specified in sub-clause 19
B.3.2. If the validation primitive rejects the challenge, output ‘invalid’ and stop. 20
QEV for the challenge domain parameters D. Send to U the challenge QEV. 22
23
QEV = BF 14 DF 94 94 39 D2 CE 24 C9 09 53 B5 72 D6 53.
24
3. Use the SKG primitive in clause B.5 to derive a shared secret bit string Z from the challenges Q1=QEU’ 25
owned by U and Q2=QEV owned by V, using as key the shared key SharedKey. If the SKG primitive 26
outputs ‘invalid’, output ‘invalid’ and stop. 27
28
a) Form the bit string MACData=U || V || QEU’ || QEV:
29
MACData= 55 73 65 72 20 55 0D 0A || 55 73 65 72 20 56 0D 0A || 30
9E 3F 0C 19 05 4B 05 44 D5 A7 17 62 0A F2 7D 96 || 31
BF 14 DF 94 94 39 D2 CE 24 C9 09 53 B5 72 D6 53. 32
b) Calculate the MACTag for MACData under the key Key using the tagging transformation of the 33
HMAC-Matyas-Meyer-Oseas MAC scheme: 34
35
MACTag = MACKey (MACData) = 78 7C DE F6 80 13 12 CD 41 1B CD 62 14
91 F8 6D.
36
37
c) Set Z=MACTag: 38
Z = 78 7C DE F6 80 13 12 CD 41 1B CD 62 14 91 F8 6D. 39
40
4. Use the key derivation function in Section 5.6.3 of ANSI X9.63-2001 [B7] with the Matyas-Meyer-
41
Oseas hash function to derive keying data KKeyData of length 256 bits from the shared secret value Z
42
and the shared data SharedData:
43
a) The hash values Hash1, Hash2 are computed as follows: 44
45
i Hashi=H(Xi) Xi
46
E4 D4 5F 76 2A 36 B7 99 F9 5E C2 C6 FD E9 78 7C DE F6 80 13 12 CD 41 1B CD 62 14 91 F8 47
1
A1 50 6D || 00 00 00 01 || D0 D1 D2 D3 D4 D5 48
49
72 57 7D 02 CC E1 39 33 1A BF F4 0B C5 6E 78 7C DE F6 80 13 12 CD 41 1B CD 62 14 91 F8
2 50
A3 7F 6D || 00 00 00 02 || D0 D1 D2 D3 D4 D5
51
52
b) Set KKeyData=Hash1 || Hash2: 53
54

1 KKeyData = E4 D4 5F 76 2A 36 B7 99 F9 5E C2 C6 FD E9 A1 50 ||
2 72 57 7D 02 CC E1 39 33 1A BF F4 0B C5 6E A3 7F.
3 5. Parse the leftmost 128 bits of KKeyData as a MAC key MacKey and the remaining bits as keying data
4 KeyData.
5
MacKey = E4 D4 5F 76 2A 36 B7 99 F9 5E C2 C6 FD E9 A1 50;
6
7 KeyData = 72 57 7D 02 CC E1 39 33 1A BF F4 0B C5 6E A3 7F.
8 6. Form the bit string MacData1 = 0216 || V || U || QEV || QEU’ || [Text1]:
9
10 MacData1 = 02 || 55 73 65 72 20 56 0D 0A || 55 73 65 72 20 55 0D 0A ||
11 BF 14 DF 94 94 39 D2 CE 24 C9 09 53 B5 72 D6 53 ||
12 9E 3F 0C 19 05 4B 05 44 D5 A7 17 62 0A F2 7D 96.
13 7. Calculate the tag MacTag1 for MacData1 under the key MacKey using the tagging transformation
14 specified in Section 5.7 of ANSI X9.63-2001 [B7] with the HMAC-Matyas-Meyer-Oseas MAC
15 scheme:
16
MacTag1 = MACMacKey(MacData1)= E6 C3 DE 1F E8 63 15 B9 E6 A0 2B 44
17
63 D8 D0.
18
19 8. If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send to U, if present the bit
20 string Text1, and MacTag1.
21
9. Then receive from U an optional bit string Text2 and a purported tag MacTag2’. If this data is not
22
23 received, output ‘invalid’ and stop.
24 Text2 = ε (the empty string);
25 MacTag2’ = 66 36 8D 61 0F E0 0B 7F 06 3E 74 C4 78 0A A3 6D.
26
27 10. Form the bit string MacData2 = 0316 || U || V || QEU’ || QEV || [Text2]:
28 MacData2 = 03 || 55 73 65 72 20 55 0D 0A || 55 73 65 72 20 56 0D 0A ||
29 9E 3F 0C 19 05 4B 05 44 D5 A7 17 62 0A F2 7D 96 ||
30 BF 14 DF 94 94 39 D2 CE 24 C9 09 53 B5 72 D6 53.
31
11. Verify that MacTag2’ is the valid tag on MacData2 under the key MacKey using the tag checking
32
33 transformation specified in Section 5.7 ANSI X9.63-2001 [B7]. If the tag checking transformation
34 outputs ‘invalid’, output ‘invalid’ and stop.
35 a) Calculate MacTag2=MACMacKey (MacData2) = 66 36 8D 61 0F E0 0B 7F 06 3E 74 C4 78 0A A3
36 6D.
37
b) Verify that MacTag2=MacTag2’.
38
39 Output: output ‘valid’ and accept the 128-bit string KeyData = 72 57 7D 02 CC E1 39 33 1A BF F4 0B C5 6E
40 A3 7F as the keying data shared with U.
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Annex D ZigBee Protocol Stack, Settable Values 1
2
(Knobs) 3
4
5
This white paper details the settable parameters within the ZigBee protocol stack. 6
The goal of this document is to list the various settings that need to be chosen so that differing ZigBee 7
implementations and networks will be able to interoperate. Along with the specific “knobs”/settings a 8
description and potential “cost” be that volatile or non-volatile memory, network constraints or other costs. 9
10
These settings fall into three major categories: Network settings, Application Settings, and Security Settings. 11
Each will be covered in a separate section. 12
13
D.1 Network Settings 14
15
16
The settable parameters for the Network Layer include:
17
— nwkMaxDepth and nwkMaxChildren 18
19
— nwkMaxRouters 20
— Size of the routing table 21
22
— Size of neighbor table 23
— Size of route discovery table 24
25
— Number of reserved routing table entries 26
— How many packets to buffer pending route discovery 27
28
— How many packets to buffer on behalf of end devices 29
— Routing cost calculation 30
31
— nwkSymLink 32
33
D.1.1 nwkMaxDepth and nwkMaxChildren 34
35
D.1.1.1 Description 36
37
The network formation procedure in ZigBee naturally forms trees of association starting with the ZigBee 38
coordinator. In star mode, of course, the tree is a degenerate one with unit depth but tree and mesh mode 39
allow for deeper trees. The NWK Information Base (NIB) attribute nwkMaxDepth specifies the maximum 40
number of allowable levels in a particular tree and the attribute nwkMaxChildren specifies the maximum 41
number of children that any node in the tree may have. By convention, values for these NIB attributes are 42
chosen by the ZigBee coordinator at network startup and shared by all devices in the network. 43
44
The network diameter, which is the maximum number of hops a packet will have to travel to reach any other 45
device in the network, is just 2*nwkMaxDepth, while the total address block size, assuming that all the 46
children are routers, which is given by: 47
48
49
1 − nwkMaxChildre nn wkM a xD epth+ 1 50
1− nwkMaxChildren 51
52
must be less than or equal to the size of the address space. See sub-clause D.1.2 for a discussion of 53
nwkMaxRouters and of networks containing ZigBee end devices. 54

ZigBee Specification, Annex D
1 D.1.1.2 Cost impact

2
3
4
Cost Item Impact (High/Medium/Low)
5
6 Network size. High – As a network grows, the amount of address space that is allocated at
7 each level is exponential over nwkMaxChildren. Thus a large nwkMaxChil-
dren will rapidly deplete whatever address space is available. Conversely, a
8
“rangy” network with a large diameter must have a relatively small value for
9 nwkMaxChildren.
10
11 Device cost. The chosen values of nwkMaxChildren and nwkMaxDepth may affect device
12 cost in two ways.
13 High – A device must have enough RAM to store a neighbor table entry for
14 each of its children and its parent. Large values for nwkMaxChildren will
15 mandate large neighbor tables.
16 Medium – Network designers may wish to maintain a high ratio of inexpen-
17 sive end devices to routers in order keep total installation cost low. This, in
turn, mandates a large value for nwkMaxChildren.
18
19
20
D.1.1.3 Value range
21
22
23
24 NwkMaxDepth 2…7
25
26 NwkMaxChildren 1…32
27
28
29 Network sizes given here assume a total address space of 4K addresses corresponding to a 16-bit address
30 word with 4 reserved bits and further assume that all devices are ZigBee routers.
31 Value Setting Tradeoff
32
33 “rangy” network Network diameter = 14
{nwkMaxChildren = 3, nwkMaxDepth = 7} Maximum devices in network = 3280
34
Neighbor table entries per router = 4
35
36 Nominal network Network diameter = 6
37 {nwkMaxChildren = 15, nwkMaxDepth = 3} Maximum devices in network = 3616
38 Neighbor table entries per router = 16
39 “bushy” network Network diameter = 4
40 {nwkMaxChildren = 32, nwkMaxDepth = 2} Maximum devices in network = 1057
41 Neighbor table entries per router = 33
42
43
44 D.1.2 NwkMaxRouters
45
46 D.1.2.1 Description
47
48 The NIB attribute nwkMaxRouters may be used to limit the number of ZigBee routers that a ZigBee router
49 or ZigBee coordinator may take on as children thereby permitting a degree of control over the ratio of
50 ZigBee routers to Zigbee end devices. Like nwkMaxDepth and nwkMaxChildren its value is assigned by the
51 ZigBee coordinator at network startup time and distributed to all other devices in the network.
52
53
54

ZigBee Protocol Stack, Settable Values (Knobs)
D.1.2.2 Cost impact 1

2
3
4
Network coverage, Medium – Routers are needed to move traffic around the network. End 5
devices, by definition, perform no routing. Thus, in order to assure that traf- 6
fic is able to move around the network and to prevent communications bot-
7
tlenecks, the largest possible value for nwkMaxRouters should be used.
8
Total installation cost. High – It is presumed that ZigBee routers will be more expensive than Zig- 9
Bee end devices. One way to control the total cost of an installation is to 10
make as many of the devices in a network as possible, end devices. 11
Power consumption. High – ZigBee routers are generally presumed to be mains-powered 12
devices. In fact, ZigBee supports beacon-enabled routers and, for some 13
applications, this may be enough to allow battery-powered routers as well, 14
but, certainly for the residential and commercial building control application 15
areas, routers will be mains-powered. End devices, on the other hand, may
16
be battery powered and so, if the application calls for a device to be battery
powered, it will most likely be an end device. 17
18
19
D.1.2.3 Value range 20
21
22
NwkMaxRouters 1-32 23
24
25
The values in the following table the effect of varying nwkMaxRouters in what might be considered a 26
typical home control network – nwkMaxChildren = 20, nwkMaxDepth = 4. In each case, the value for end 27
devices per router holds for routers in the “middle” of the tree. All leaf nodes may be end devices if so 28
desired. 29
30
31
Value Setting Tradeoff 32
33
4 Maximum devices in network = 1701 34
End devices per router = 16
35
6 Maximum devices in network = 5181 36
End devices per router = 14 37
38
8 Maximum devices in network = 11701
End devices per router = 12 39
40
41
The values in the table below are comparable values for wider-ranging network that might be used in 42
building control {nwkMaxChildren = 22, nwkMaxDepth = 5}. 43
44
45
46
47
48
49
50
51
52
53
54

1
2
4 4 Maximum devices in network = 7503
5 End devices per router = 18
6
6 Maximum devices in network = 34211
7
End devices per router = 16
8
9 7 Maximum devices in network = 61623
10 End devices per router = 15
11
12
13 D.1.3 Size of routing table
14
16
17 ZigBeeevices may set aside storage for routing entries that record the next hop in the multi-hop chain
18 required to deliver a packet to a particular destination. The minimum required information to be stored in
19 routing tables, as described in the current version of the specification, is as follows:
20
21
23
Destination address 2 bytes The 16-bit network address of this route.
24
25 Status 3 bits The status of the route. See sub-clause D.1.3.3 for values.
26
27 Next-hop address 2 bytes The 16-bit network address of the next hop on the way to the des-
tination.
28
29
30
In estimating the size of the entries we can a 5-byte entry.
31
32
D.1.3.2 Cost impact
33
34
35
36 Cost Item Impact (High/Medium/Low)
37 Device cost. Medium – Every routing table entry adds 5 bytes of RAM to the ZigBee device.
38
39 Routing optimality. Low – A small number of routing entries will result in a greater preponderance
40 of tree routing. The routes chosen in this way may require more hops and
therefore generate more traffic than the tree routes that would be used if
41
devices had room for them.
42
43 Network reliability. Medium – Tree routes have no choice but to use tree links and are therefore
44 more liable to fail in the case of a flaky or asymmetrical tree link. Mesh routes
45 should be more robust since they have the opportunity to pick the best avail-
able links and apply LQI measurement to improve their performance over time.
46
47
48
D.1.3.3 Value range
49
50
51
52 Routing Table Size 0…Unspecified Maximum.
53
54

1
2
0 (minimum) 0 bytes of RAM This minimum value may be sufficient for networks where the 4
placement of routers is flexible enough that the resulting tree routes may be tuned 5
for optimal performance and the traffic load is low enough that bottlenecks are not 6
likely to develop near the ZigBee coordinator. 7
32 (typical) 160 bytes of RAM. This is a number that will probably suffice for Resi-Light-Comm 8
installations with localized control. 9
10
11
D.1.4 Size of neighbor table 12
13
15
The neighbor table is used for keeping track of a device’s neighbors in the network. There are several classes 16
of neighbor table entry that may be used by implementers for this task. 17
18
— Every device must keep track of its children in the tree and its parent. It may want to track the link 19
quality of packets received from each to support routing cost calculation. 20
— A device may keep track of neighbors from which it has received or may receive route requests. It 21
may also track LQI for packets received from each of these neighbors. 22
23
— When a device joins (or forms) a network it performs a sequence of scans and the data from these 24
scans must be stored, at least temporarily, while it evaluates which network to join and so on. 25
In a practical implementation, the information stored here may be stored in a single table or multiple tables 26
at the implementer’s discretion. A rough size for each of these types of table entry follows: 27
28
29
30
Entry Size in bytes 31
Parent/Child. 11 bytes without LQI. 32
12 bytes with LQI. 33
34
Routing neighbor. 2 bytes without LQI. 35
3 bytes with LQI.
36
Temporary entry during startup and joining. 15 bytes. 37
38
39
Notes that these are minimum numbers. Implementers may choose to store more information about a 40
device’s neighbors, e.g. a timestamp recording when how recently the device has been heard from. 41
42
The discussion here will center on permanent storage only. 43
44
46
47
Cost Item Impact (High/Medium/Low) 48
49
Device cost. Medium – Every neighbor table entry requires a fixed amount of RAM 50
depending on its type as described above. The number of entries for storing
parents and children is not completely at the discretion of the developer since 51
it is equal to nwkMaxChildren + 1. An implementer may set aside any number 52
of 3-byte entries for additional neighbors to be used in routing. 53
54

1 D.1.4.3 Value range

2
3
4
5 Neighbor Table Size NwkMaxChildren + 1 entries for children/parent.
6 [0… Unspecified Maximum] entries for other neighbors.
7
8
9
10
12
Sample minimum for nwkMaxChildren = 15 192 bytes of RAM including LQI values.
13
14 nwkMaxChildren = 15, 16 additional neighbors 240 bytes of RAM including LQI values.
15
16
17 D.1.5 Size of route discovery table
18
20
21 The route discovery table is used to temporarily store information that is needed during route discovery. The
22 contents of the route discovery table, as excerpted from the most recent version of the specification are:
23
24
26
27 Route request ID A sequence number for a route request command frame that is incre-
1 byte
mented each time a device initiates a route request.
28
29 Source address 2 bytes The 16-bit network address of the route request’s initiator.
30
31 Sender address The 16-bit network address of the node that has sent the most recent low-
est cost route request command frame corresponding to this entry’s Route
32 2 bytes
request ID and Source address. This field is used to determine the path
33 that an eventual route reply command frame should follow
34
35 Residual Cost The accumulated path cost from source of the route request to the current
1 byte
36 device
37 Forward routing The accumulated path cost from the current device to the destination
38 1 byte
cost device
39
40 Path cost 1 byte The accumulated PCM value
41 Expiration time A countdown timer indicating the number of milliseconds until route discov-
42 2 bytes
ery expires. The initial value is nwkcRouteDiscoveryTime.
43
44
45 Minor changes may occur in the definition table during the next few revisions of the specification but it will
46 stay at roughly this size, i.e. around 10 bytes per entry.
47
48 Entries in this table are only valid during route discovery and may be reused.
49
50
51
52
53
54


2
3
4
5
Device cost. Low – Every route discovery table entry takes up about 10 bytes of RAM. 6
7
8
10
11
12
Route Discovery Table Size 1…Unspecified Maximum
13
14
15
16
18
1 (minimum) 10 bytes of RAM. The device may only process one route discovery at a time
19
and some routes will not be discovered.
20
8 (recommended) 80 bytes of RAM. This is enough to handle 8 route discoveries at once and 21
should be enough for most networks. More testing should be performed to 22
fine-tune this number. 23
24
25
D.1.6 Number of reserved routing table entries 26
27
29
A device may set aside some number of routing table entries to be used in the “dire” case where a route is
30
broken and the device that wants to repair it has no routing capacity to do so. This is most likely to happen
31
when the link is a parent-child link.
32
33
D.1.6.2 Cost impact
34
35
36
Device cost. Low – As with the standard routing table, every reserved entry takes up 38
about 5 bytes of RAM. 39
40
Network reliability. High – For tree networks and mesh networks containing a large num- 41
ber of devices with small routing capacity, having a small repair table
42
may spell the difference between having a portion of the network
become available due to a broken tree link and being able to repair 43
around that link. 44
45
46
48
49
Repair Table Size 0…Unspecified Maximum 50
51
52
53
54

1
2
4 0 (minimum) With no repair table, a device will not be able to participate in tree repair
5 and, if one of its forward links breaks, network partition may result.
6
7 1 5 bytes of RAM. This is enough to repair a single route across a single
broken link and may be sufficient in some cases.
8
9 8 (recommended) 40 bytes of RAM More testing is require to fine tune this number.
10
11
12 D.1.7 Buffering pending route discovery
13
15
16 An RN+ may choose to buffer a frame pending route discovery or it may relay it directly along the tree and,
17 preferably after a short delay, initiate route discovery.
18
20
21
23
24 Device cost. High– Each frame buffered may take up
as much as the standard ZigBee pay-
25 load size (TBD) plus the network
26 header. This may be on the order of 100
27 bytes per frame.
28
29 Network reliability. Low – Frames relayed in this way stand
a slightly larger chance of being
30 dropped in transit due to bad tree links
31 or interference from route discovery traf-
32 fic.
33
34
36
37
38
Number of frames buffered 0…Unspecified Maximum
39
40
41
42
44
45 0 (minimum) With no buffering, all frames are relayed along the tree before route
discovery is initiated.
46
47 2 (suggested maximum for 8-bit Most 8-bit processors with a RAM complement of 2-4K will not be able
48 implementations) to afford more than 200 bytes of buffering for this purpose.
49
50
51
52
53
54

D.1.8 Buffering on behalf of end devices 1

2
4
A ZigBee coordinator or ZigBee router may choose to buffer broadcast frames on behalf of sleeping end 5
devices to be transmitted in response to a later data request or a poll request. The alternative is to leave the 6
responsibility of relaying broadcasts to end devices to the application. 7
8
10
11
13
Device cost. High– Each frame buffered may take up 14
as much as the standard ZigBee pay-
15
load size (TBD) plus the network
header. This may be on the order of 100 16
bytes per frame. 17
18
19
21
22
23
Number of frames buffered 0…Unspecified Maximum 24
25
26
27
29
0 (minimum) With no buffering, broadcasts to end 30
devices must be relayed by the appli-
31
cation. Another way of saying this is
that routers and coordinators must act 32
as proxies for sleeping end devices at 33
the application layer. 34
35
2 (suggested maximum for 8-bit implementations) Again, most 8-bit processors with a
RAM complement of 2-4K will not be 36
able to afford more than 200 bytes of 37
buffering for this purpose. In this case, 38
two broadcasts may be held until they 39
are delivered to all sleeping children. 40
41
42
D.1.9 Routing cost calculation 43
44
46
In order to allow the comparison of possible routes, ZigBee routers are required to add a link cost value to
47
the path cost field of route request and route reply command frames. Implementers are allowed wide latitude
48
with regard to the technique for producing this link cost value. They may actual opt out and report a fixed
49
value (TBD) or they may use instantaneous LQI, an LQI value that has been averaged over time or, in fact,
50
any other scheme to derive the probability that a packet will be delivered over the link in question. The link
51
cost, then should be the reciprocal of that probability.
52
53
54


2
3
4
5
6 Device cost. Low – A device that calculates link cost
7 must perform a simple computation for
each packet received and store the
8
result in the neighbor table entry corre-
9 sponding to the sender of that packet. It
10 must also use table-lookup or some
11 other method to derive a link cost from
12 that value at route discovery time. The
example table in the specification for
13
this purpose is 8 bytes long.
14
15 Network reliability. High – The primary reason to rate link
16 quality is that it protects the routing algo-
17 rithm from choosing unreliable routes
that are shorter over reliable routes that
18 happen to be longer and it gives the
19 algorithm a rationale for choosing
20 between multiple paths of the same
21 length some of which may be more reli-
22 able than others.
23
24
26
27
28 Calculate link cost YES or NO
29
30
31
32
34 Yes A device may rate the quality of a link
35 and that rating may improve over time
36 so that routing choices reflect the oper-
37 ational conditions of the network.
38
No A device can neither rate link reliability
39 or improve its rating over time. In a net-
40 work where all devices use this tech-
41 nique the probability that flaky,
42 unreliable and expensive routes will be
43 chosen is greatly increased.
44
45
46
D.1.10 nwkSymLink
47
49 In most network environments, we can assume that some percentage of the links presented to any given
50 device in the network will be asymmetrical in the sense that the link quality to be had by communicating in
51 one direction will differ, often substantially, from the link quality in the other direction. The reasons for this
52 are unsurprising and have to do with the physical characteristics of the wireless medium as well as with the
53 characteristics of the devices being employed. In the case where link symmetry can, for the most part, be
54

assumed, an optimization becomes available whereby the forward and reverse path of a route can be 1
established at the same time. The nkSymLink NIB attribute determines whether this assumption, and the 2
resulting optimization are made during route discovery. 3
4
D.1.10.2 Cost Impact 5
6
7
8
9
Network traffic load Medium – The traffic load on a network 10
that is performing route discovery is 11
substantial. This traffic may cause regu-
12
lar data traffic in transit at the same time
to be lost. A mitigating factor is that the 13
bulk of route establishment operations 14
will happen at network startup or at 15
times when the network restarts due to 16
wide-area failures.
17
Network reliability High – Erroneous assumptions about 18
link symmetry can have disastrous 19
results since it may cause the establish- 20
ment of unviable routes, which may be 21
impossible to repair since forward and
reverse route discovery will always be 22
performed together but link quality will 23
only be measured in the forward direc- 24
tion. 25
26
27
D.1.10.3 Value Range 28
29
30
31
nwkSymLink TRUE or FALSE
32
33
34
35
37
TRUE A device may assume link symmetry
and perform forwards and backwards 38
route discovery at the same time, at the 39
risk of establishing unusable routes. 40
41
FALSE A device must perform forward and
42
reverse route discovery separately
thereby loading the network with more 43
discovery traffic in the case where 44
routes are needed in both directions 45
but both routes are much more likely to 46
be viable in the presence of asymmet-
47
ric links
48
49
50
D.2 Application Settings 51
52
The settable parameters for the Application Layer include: 53
54

1 — Logical device type

2
— Stack profile and beacon payload parameters
3
4 — Number of active endpoints per device (maximum)
5
— Discovery information cache size (minimum)
6
7 — Binding table size (minimum)
8
— End to end response messaging
9
10 — Acknowledged service in APS
11
12 D.2.0.1 Logical device type
13
15
16 ZigBee coordinator – Device will scan to find an unused channel and start a new network.
17
ZigBee router – Device will scan to find an existing network and join as a router
18
19 ZigBee end device – Device will scan to find an existing network and join as an end device.
20
22
23
25
ZigBee coordinator High – Designating a specific device to be the ZigBee coordinator places
26 a requirement on system deployment to install a special device in the net-
27 work capable of starting the network. Additionally, the ZigBee coordinator
28 must have resources for a binding table and trust center (if security is
29 used). The amount of resources allocated must match the expected size
30 of the network it serves (including growth).
31 ZigBee router High – To provide mesh routing, ZigBee routers must be deployed such
32 that at least one has connectivity to the ZigBee coordinator and there is
33 continuous connectivity from router to router to the edge of the network.
34 This implies a set of installation and deployment requirements tied to logi-
cal device type. Each ZigBee router must contain network routing soft-
35 ware and some resource allocation for routing tables or tree repair tables.
36
37 ZigBee end device Low – Each ZigBee end device may be minimally configured as long as
38 provisions have been made above for the ZigBee coordinator and routers.
39
40
41 D.2.0.4 Value Range
42
43
44 Logical Device Type Coordinator, router or end device
45
46
47
48
49
50
51
52
53
54

1
2
ZigBee coordinator Need at least 1 4
5
ZigBee router Need to deploy such that entire network spans no more than 6
nwkMaxDepth
7
ZigBee end device Need to deploy in such a way that all ZigBee end devices are 8
serviced by some router out to nwkMaxDepth. 9
10
11
D.2.0.5 Stack profile and beacon payload parameters 12
13
15
This setting is applicable to all ZigBee devices. The application will have some desired network settings 16
provided as configuration settings to ZDO. These settings will either be used to configure the network to be 17
created (ZigBee coordinator) or will be used to select a network to join (ZigBee router and end device). 18
These parameters will be established by the specific needs of the Profile or Profiles supported in the device. 19
For devices with multiple applications running on different endpoints, there must be agreement on a single 20
stack profile and set of network settings. The following parameters are settable: 21
22
— Stack Profile – Network Specific, Home Controls, Building Automation or Plant Control
23
— NwkcProtocolVersion – Specifies the ZigBee protocol version. The rules for joining (or not joining) 24
networks with specific Protocol Versions will be established in later versions of this specification. 25
26
— NwkSecurityLevel – Specifies the security level of the network.
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


2
3
4
5
6 Stack Profile of Network Specific High – For devices employing network
7 specific stack profiles or wanting to join
networks advertised as network specific,
8
the device must first join the network to
9 determine whether parameters not adver-
10 tised in the beacon payload are operation-
11 ally acceptable. Parameters such as the
12 (minimum) size of the neighbor table, (min-
imum) size of the route discovery table,
13
etc. are key to a fully interoperable net-
14 work.
15
16 NwkcProtocolVersion Low – For now, this is a benign parameter
17 value. If it is needed in later versions, it
could become a parameter with very high
18 cost (for example, if v1.1 features are
19 defined such that they are not compatible
20 with v1.0).
21
NwkSecurityLevel High - This parameter has values from 0x0
22
(security off) to 0x7 (highest security).
23 Each of the security levels applies to each
24 of the stack profiles. If application profiles
25 are written such that they require a specific
26 security level, then we will end up with
another dimension on the stack profile that
27
will complicate interoperability.
28
29
31
32
33 Stack Profile Network Specific – 0x0
34 Home Controls – 0x1
35 Building Automation – 0x2
36 Plant Control – 0x3
37 NwkSecurityLevel Security off – 0x0
38 Security level – 0x1 – 0x7
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

1
2
Stack Profile Selection of a single stack profile, assum- 4
ing there are a small number of stack pro- 5
files, greatly simplifies network selection 6
and aids in interoperability. If, however, 7
stack profiles proliferate and are used as
multiple variations on stack parameter set- 8
tings, then the same interoperability con- 9
cerns will surface which led to creation of 10
stack profiles to begin with. 11
12
Stack Profile of Network Specific This parameter setting should really only
be selected for closed networks. Use of 13
this parameter for networks where interop- 14
erability is desired will result in complex 15
join procedures where devices must deter- 16
mine if the network settings can support
17
their applications.
18
NwkSecurityLevel Rules must be established on how this 19
parameter is used. For example, suppose 20
a Home Controls stack profile specifies 21
nwkSecurityLevel of 0x3 (vs. 0x4 wanted
by a prospective joining device). The nwk- 22
SecurityLevel should not be permitted to 23
become another dimension on the stack 24
profile (else, the security level should 25
become a setting WITHIN the stack profile 26
and not a separate parameter).
27
28
29
D.2.0.9 Number of active endpoints per device (maximum)
30
31
D.2.0.10 Description
32
Each endpoint needs a descriptor/description for use with Service Discovery. These descriptors can be up to 33
Zigbee network payload size. For any sleeping devices the coordinator must cache these values so it can act 34
as a proxy for Service Discovery. 35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


2
3
4
5
6 Non-volitile memory on end device to store description for High – Each endpoint must have a Simple
7 each interface Descriptor. Worst case, the Simple
Descriptor can be as large as a single Zig-
8
Bee application packet (64 bytes with
9 security). With a maximum 240 endpoints/
10 interfaces * 64 bytes this is a storage
11 requirement of 15.360 bytes!
12
Non-volitile or volitile memory on coordinator to be able to High – Each coordinator/router can have
13 cache descriptors for each “child” device and each interface nwkMaxChildren. If they all wanted to
14 on each child sleep, they would want their coordinator/
15 router to cache their service discovery
16 information. This would include a Node
17 Descriptor, Power Descriptor for each
device plus as many Simple Descriptors as
18 each device had for every active endpoint
19 (see above item – this is a very substantial
20 number).
21
22
24
25
26
Number of endpoints/interfaces per device 1-240
27
28
29
30
32
33 1 (minimum)
34 2? (typical)
35
36 240 (maximum)
37
38
39 D.2.0.13 Discovery Information Cache Size
40
42
Each device holds the following descriptors:
43
44 — Node Descriptor – 6 bytes (mandatory)
45
46 — Power Descriptor – 2 bytes (mandatory)
47 — Simple Descriptor – variable, one per active endpoint/interface (mandatory)
48
49 — Complex Descriptor – variable (optional)
50 — User Descriptor – variable (optional).
51
52 For each end device that intends to sleep, the ZigBee coordinator or router it associates to must cache the
53 above information for the device and respond to service discovery. In addition to the nwkMaxChildren and
54 nwkMaxRouters parameters, this cache size must be considered when permitting a device to associate.


2
3
4
5
Cache size High – Though nwkMaxChildren may indi- 6
cate that a given router or coordinator 7
could support additional children, the size
8
of the cache available to support sleeping
devices along with the application require- 9
ments of the sleeping device must be con- 10
sidered. 11
12
13
15
16
17
Discovery Information cache size
18
19
20
21
23
? Need to establish values for this parame-
24
ter. Currently, there is no indication from a
joining device as to the number and size of 25
Simple Descriptors they support. 26
27
28
D.2.0.17 Binding Table Size 29
30
32
The Binding Table is held by the ZigBee coordinator and contains entries with the following information: 33
34
— Source address (64 bits)
35
— Source endpoint/interface (8 bits) 36
37
— Cluster ID (8 bits)
38
— Destination address (64 bits) 39
40
— Destination endpoint/interface (8 bits)
41
The above information is provided per entry. The number of entries is a function of the number of devices in 42
the network and the number of expected bindings per device. 43
44
45
46
47
48
49
50
51
52
53
54


2
3
4
5
6 Binding Table Size High – Assume a network of 400 devices,
7 what assumptions are required to set an
appropriate binding table size? The size is
8
a function of the devices in the network
9 and the application needs of those
10 devices. For example, a sensor application
11 may use 0 Binding Table entries. A Light-
12 ing solution may have 1 entry per device.
In some extreme cases (like theatre light-
13
ing), there may be multiples of Binding
14 Table entries per device (if a given set of
15 lights were controlled by multiples of
16 switches).
17
18
20
21
22
Number of pairings the binding coordinator can
23 hold
24
25
26
27
29
0 (minimum) Devices requiring Binding Table support
30 should not join this type of network.
31
32 1 per network device? (typical) It must be known if this type of Binding
33 Table size can support the needs of the
application on the device joining the net-
34 work.
35
36 ? (maximum) For some specialized applications, the
37 Binding Table size may need to be larger
than 1 per device on the network.
38
39
40
D.2.0.21 End to End Response Messaging
41
42
43
44 According to the Application Framework, response messaging is optional. It would appear to be perfectly
45 legal to define all messaging within a given application as not requiring responses. In fact, given that the
46 NWK layer is non-guaranteed delivery, it would not be possible to determine if the application was
47 successfully sending any messages to its intended destination.
48
49
50
51
52
53
54


2
3
4
5
End to end messaging on all requests High – Each application would be respon- 6
sible for creating a timer to ensure that 7
response messages are received for every
8
command. A retry mechanism would need
to be instituted for messages that are not 9
acknowledged along with error handling in 10
cases where the retry limit is exceeded. 11
12
End to end messaging on some requests Medium – The application could utilize
APS level acknowledgement that provides 13
assurance that messages are being 14
received at the destination, then use non- 15
guaranteed delivery for intervening com- 16
mands. Use of this feature would depend 17
on the application nature of the commands
being sent and the relative importance on 18
the destination receiving all commands 19
reliably (ie. Whether the message is 20
repeated like a measurement or whether it 21
is a control command) 22
23
24
26
27
End to End Response Messaging 28
29
30
31
32
End to end application messaging used at all times Application must implement timeouts and 34
retries. Application must handle error con- 35
ditions when retry limits are exceeded. 36
37
End to end application messaging is used periodically Application must still implement timeouts
38
and handle error conditions. Additionally,
application must assume that failures of 39
application commands/responses are also 40
occurring and be designed to be immune 41
from such failure. 42
End to end application messaging is not used. Application has no feedback that any mes- 43
sages sent are received at the destination. 44
45
46
D.2.0.25 Acknowledged Service in APS 47
48
50
An acknowledged service was added to APS. This optional service is required in cases such as replies to 51
broadcast service or device discovery commands, however, may be employed for other application 52
messaging under application control. 53
54


2
3
4
5
6 Acknowledgements on all APS data requests Medium – Each APS data request would
7 need to receive an acknowledgement. This
could cause a need to either buffer
8
requests or to discard data requests within
9 APS (depends on applications communi-
10 cation requirements)
11
12 Acknowledgements on some APS data requests Low – The only required acknowledge-
ments will be for unicast responses to
13 broadcast requests (such as for the Device
14 Profile primitives NWK_addr_req and
15 Match_Desc_req).
16
17
19
20
21
Acknowledgements on APS Data Requests
22
23
24
25
27
28 Acknowledgements used at all times Application must implement timeouts and
retries. Application must handle error con-
29 ditions when retry limits are exceeded.
30
31 Acknowledgements are used only for required actions None.
32 (NWK_addr_rsp, Match_Desc_rsp and any other unicast
responses to a broadcast device or service discovery
33
request).
34
35
36
37 D.3 Security Settings
38
39 The settable parameters for the Security Services Provider include:
40
41 — Security level
42 — Master key source
43
44 — Always use NWK-layer security
45 — Number of NWK keys
46
47 — Number of application keys
48 — Number of frame counters used
49
50 — SecurityTimeoutPeriod
51
52
53
54

D.3.0.1 Security level 1

2
4
The type of security used by the device (if any). 5
6
8
9
11
NVM if security is used 12
13
14
15
16
17
19
20
21
Security level 0x00-0x07
22
23
24
25
27
0x00-none No security; no cost of security
28
0x01-MIC-32 (32-bit Message Integrity Code) Moderate integrity protection; longer 29
packet length, NVM key storage needed 30
31
0x02-MIC-64 (64-bit Message Integrity Code) Strong integrity protection; longer packet
length, NVM key storage needed 32
33
0x03-MIC-128 (128-bit Message Integrity Code) Strongest integrity protection; longest 34
packet length, NVM key storage needed 35
0x04-ENC (Encryption only) Message privacy; NVM key storage 36
needed 37
38
0x05-ENC-MIC-32 (Encryption and 32-bit Message Integrity Encryption with moderate integrity protec- 39
Code) tion; longer packet length, NVM key stor-
40
age needed
41
0x06-ENC-MIC-64 (Encryption and 64-bit Message Integrity Encryption with strong integrity protection; 42
Code) longer packet length, NVM key storage 43
needed 44
0x07-ENC-MIC-128 (Encryption and 128-bit Message Integ- Encryption with strongest integrity protec- 45
rity Code) tion; longer packet length, NVM key stor- 46
age needed 47
48
49
50
51
52
53
54

1 D.3.0.5 Master key source

2
4
5 The master key for the trust center may come from several places; this affects the behavior of the network
6 device.
7
9
10
12
13 Factory installation High-difficult to control through distribution
chain
14
15 User interface High-effects BoM, product design, user
16 experience
17
18
20
21
22
Master key source Factory installation, installed by network trust center, or
23 entered by user
24
25
26
27
29
Factory installation Easy to use by user, as long as network is
30 as envisioned by factory; difficult to track
31 through distribution chain, difficult to add
32 new devices, difficult to deploy in industrial
33 settings
34 Installed by trust center Easy to use by user; onus on ZigBee to
35 minimize algorithm complexity
36
37 Entered by user Flexible, responsive to varied network
designs
38
39
40
D.3.0.9 Always use Network layer security – on or off
41
42
43
44 Network layer security is needed to prevent theft of network service—“freeloading” devices using the
45 network to route frames between themselves.
46
47
48
49
50
51
52
53
54


2
3
? 5
6
7
8
9
10
12
13
14
Network layer security ON or OFF 15
16
17
18
19
ON No theft of service; longer frames 21
22
OFF Shorter frames; possible theft of service 23
24
25
D.3.0.13 Number of NWK Keys
26
27
28
The network key is used to secure MAC and NWK-layer frames. 29
30
32
33
34
NVM storage Low 36
37
38
40
41
42
Keys 0, 1, 2 43
44
45
46
47
48
49
50
51
52
53
54

1
2
4 0 No NVM; network not secure
5
6 1 Network packets secure; NVM, possible
loss of network function for short period
7
while key updates
8
9 2 Network packets secure, no loss of net-
10 work function for short period while key
11 updates; NVM
12
13
14 D.3.0.17 Number of Application Keys
15
17 Application keys are used to secure end-to-end links.
18
20
21
22
24 NVM storage Medium
25
26
28
29
30
31 Application Keys 0-16?
32
33
34
35
Value Setting Tradeoff
36
37 ? The more keys, the more NVM, but the
38 more flexible and powerful the device.
39
40
41 D.3.0.21 Number of Frame Counters Used
42
44
A frame counter must be used for each device with which a network node communicates securely.
45
46
D.3.0.23 Cost impact
47
48
49
51 NVM storage Medium
52
53
54


2
3
4
Frame counters--RFD 1 5
Frame counters--FFD 16 6
7
8
9
10
1 Low cost; minimal functionality 12
13
16 Can communicate securely with 15 chil- 14
dren plus parent; more NVM 15
16
17
D.3.0.25 Security timeout periods 18
19
— Maximum length of time either an initiator (e.g., a joining device) or a responder (e.g., a beaconing 21
device) may wait for an expected incoming SKKE message before generating an error code. 22
23
— Maximum length of time either an initiator or a responder may wait for an expected incoming mes- 24
sage in the entity authentication protocol before generating an error code. 25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Annex E ZigBee Stack Profiles 1
2
3
This Annex details the stack profiles for ZigBee protocol stack. 4
5
6
E.1 Stack Profiles 7
8
Stack Profiles are a convention on specific ZigBee stack settable values established to provide 9
interoperability in specified markets. See Annex D for descriptions on the various settings. 10
11
The following stack profiles have been identified: 12
13
a) Home Controls 14
b) Building Automation 15
16
c) Plant Control
17
Additionally, a category of stack profile called “Network Specific” is proposed which indicates that no 18
specific Stack Profile is in use, rather, the stack parameters are defined by the elemental values employed as 19
stack parameters. 20
21
22
E.2 Stack Profile Definitions 23
24
The ZigBee Network (NWK) Specification provides for identification of the Stack Profile within the beacon 25
payload. 26
27
28
29
Stack Profile Name Stack Profile Identifier (02130r7) 30
Network Specific 0x0 31
32
Home Controls 0x1 33
34
Building Automation 0x2
35
Plant Control 0x3 36
37
Reserved 0x4-0xf
38
39
40
E.3 Home Controls Stack Profile 41
42
The Home Controls Stack Profile is intended for use with the Home Controls-Lighting profile and all 43
profiles written for complementary use with Home Controls-Lighting. 44
45
46
47
48
49
50
51
52
53
54

ZigBee Specification, Annex E
1 E.3.1 Network Settings

2
3
4 Parameter Name Setting
5
6 Beacon Order 0x0f (no beacon)
7 Superframe Order 0x0f (ignored)
8 NwkMaxDepth and nwkMaxChildren 5
9 20
10
11 NwkMaxRouters 6
12 Size of the routing table (minimum) 8
13
14 Size of the neighbor table (minimum) ZigBee coordinator: 24
15 ZigBee router: 25
ZigBee end device: 1
16
17 Size of the route discovery table (mini- 4
18 mum)
19
Number of reserved routing table entries 8
20 (minimum)
21
22 Number of packets buffered pending route 0
23 discovery (minimum)
24 Number of packets buffered on behalf of 1
25 end devices (minimum)
26
27 Routing cost calculation True
28 NwkSymLink False
29
30
31 E.3.2 Application Settings
32
33
34
Parameter Name Setting
35
36 Logical device type ZigBee Coordinator – 1
37 ZigBee Router – no more than 6 per
38 coordinator/router to join at the higher
level of the tree
39 ZigBee End Device – no more than 20
40 per coordinator/router
41
42 Stack profile and beacon payload parame- Stack profile – 0x1
ters NwkcProtocolVersion – 0x0
43 NwkSecurityLevel – 0x5
44
45 Number of active endpoints per device 3
46 (minimum)
47 Discovery information cache size (mini- 1036 bytesa
48 mum, coordinator/routers only, per sleep-
49 ing child devices)
50
51
52
53
54

ZigBee v1.0 Stack Profiles
Binding table size (minimum, coordinator 100 entries (1900 bytes)b 1

only) 2
3
End to end response messaging (per clus- Agreed to for each cluster in each profile 4
ter/attribute per profile) within Home Controls.
5
Acknowledged service in APS Agreed to for each cluster in each profile 6
within Home Controls. 7
8
aAssumptions: nwkMaxChildren of 20 minus nwkMaxRouters of 6 (net of 14), 9
each with: Node Descriptor – 6 bytes, Power Descriptor – 2 bytes, Simple 10
Descriptor (3 each, max of 10 input/output clusters per), User Descriptor of 12 = 11
1036 bytes 12
bAssumptions: 13
Each Binding Table entry is: Source Address (8 bytes)+Source 14
Endpoint(1 byte)+ClusterID(1 byte)+Dest Address (8 bytes)+Dest Endpoint (1 15
byte) = 19 bytes 16
17
E.3.3 Security Settings 18
19
20
21
Parameter Name Setting 22
Security Level 0x5 23
24
Master Key Source Entered by user (includes key pad, but- 25
ton press, low RF “learn mode” or other
user initiated action) 26
27
Always use Network layer security – on or ON 28
off 29
Number of NWK Keys 2 30
31
Number of Application Keys 0 32
33
Number of Frame Counters used 1 for RFD, 20 for FFD
34
Security timeout periods 50ms * (2*nwkMaxDepth) + (AES 35
Encrypt/Decrypt times) 36
37
38
E.4 Building Automation Stack Profile 39
40
41
The Building Automation Stack Profile is intended for use with future profiles targeted to 42
building automation solutions. 43
44
45
E.4.1 Network Settings
46
47
48
Beacon Order 0x0f (no beacon) 50
Superframe Order 0x0f (ignored) 51
52
NwkMaxDepth and nwkMaxChildren 9 (2nd choice: 7) 53
6 (2nd choice: 12)
54

1 NwkMaxRouters 3 (2nd choice: 4)

2
3 Size of the routing table (minimum) 16
4
Size of the neighbor table (minimum) ZigBee coordinator: 15
5 ZigBee router: 16
6 ZigBee end device: 1
7
8 Size of the route discovery table (mini- 8
mum)
9
10 Number of reserved routing table entries 8
11 (minimum)
12
Number of packets buffered pending route 0
13
discovery (minimum)
14
17
Routing cost calculation True
18
19 NwkSymLink False
20
21
23
24
25 Parameter Name Setting
26
Logical device type ZigBee Coordinator – 1
28 coordinator/router to join at the higher
29 level of the tree
30 ZigBee End Device – no more than 9 per
31 coordinator/router
33 ters NwkcProtocolVersion – 0x0
35
Number of active endpoints per device 7
36 (minimum)
37
38 Discovery information cache size (mini- 588 bytes
41 Binding table size (minimum, coordinator 50 entries (950 bytes)
42 only)
43
44 End to end response messaging (per clus- Agreed to for each cluster in each profile
ter/attribute per profile) within Building Automation.
45
46 Acknowledged service in APS Agreed to for each cluster in each profile
47 within Building Automation.
48
49
50
51
52
53
54

ZigBee v1.0 Stack Profiles
E.4.3 Security Settings 1

2
3
4
5
Security Level 0x6 6
Master Key Source Installed by trust center
7
8
Always use Network layer security – on or ON 9
off 10
Number of NWK Keys 2
11
12
Number of Application Keys 20 13
14
Number of Frame Counters used 1 for RFD, 6 for FFD
15
Security timeout periods 50ms * (2*nwkMaxDepth) + (AES 16
Encrypt/Decrypt times) 17
18
19
20
E.5 Plant Control Stack Profile
21
22
Editor’s Note: This section was not reviewed as of Release 1 of the document.
23
24
The Plant Control Stack Profile is intended for use with future profiles targeted to plant 25
control solutions. 26
27
E.5.1 Network Settings 28
29
30
31
Beacon Order 0x0f (no beacon) 33
Superframe Order 0x0f (ignored) 34
35
NwkMaxDepth and nwkMaxChildren 5
22 36
37
NwkMaxRouters 7 38
39
Size of the routing table (minimum) 16
40
Size of the neighbor table (minimum) ZigBee coordinator: 30 41
ZigBee router: 31 42
ZigBee end device: 1 43
Size of the route discovery table (mini- 8 44
mum) 45
46
Number of reserved routing 8 47
table entries (minimum) 48
49
Number of packets buffered pending route 0 50
discovery (minimum)
51
52
53
54


3
4 Routing cost calculation True
5 NwkSymLink False
6
7
9
10
11
12
13 Logical device type ZigBee Coordinator – 1
coordinator/router to join at the higher
15 level of the tree
16 ZigBee End Device – no more than 22
17 per coordinator/router
18
ters NwkcProtocolVersion – 0x0
21
22 Number of active endpoints per device 7
23 (minimum)
24 Discovery information cache size (mini- 2940 bytes
27
Binding table size (minimum, coordinator 100 entries (1900 bytes)
28 only)
29
30 End to end response messaging (per clus- Agreed to for each cluster in each profile
31 ter/attribute per profile) within Plant Control.
32 Acknowledged service in APS Agreed to for each cluster in each profile
33 within Plant Control.
34
35
36 E.5.3 Security Settings
37
38
39
40
41 Security Level 0x6
42
Master Key Source Installed by trust center
43
44 Always use Network layer security – on or ON
45 off
46
Number of NWK Keys 2
47
48 Number of Application Keys 23
49
50 Number of Frame Counters used 1 for RFD, 22 for FFD
51 Security timeout periods 50ms * (2*nwkMaxDepth) + (AES
52 Encrypt/Decrypt times)
53
54

Annex F KVP XML schemas 1
2
3
This annex contains the XML schemas for the ZigBee ZVP commands. 4
5
6
F.1 XML schema for the get command 7
8
9
<?xml version="1.0" encoding="UTF-8"?>
10
<xs:schema targetNamespace="http://www.zigbee.org/v1.0/AF" xmlns="http://www.zigbee.org/v1.0/AF"
11
xmlns:xs="http://www.w3.org/2001/XMLSchema"> 12
<xs:element name="GetCommand"> 13
<xs:annotation> 14
<xs:documentation>Schema for AF get command</xs:documentation> 15
</xs:annotation> 16
<xs:complexType> 17
<xs:sequence> 18
<xs:element name="AttribDataType" type="xs:unsignedByte"/> 19
<xs:element name="AttribId" type="xs:unsignedShort"/> 20
21
</xs:sequence>
22
</xs:complexType>
23
</xs:element> 24
</xs:schema> 25
26
27
F.2 XML schema for the get response command 28
29
<?xml version="1.0" encoding="UTF-8"?> 30
<xs:schema targetNamespace="http://www.zigbee.org/v1.0/AF “xmlns="http://www.zigbee.org/v1.0/AF" 31
xmlns:xs="http://www.w3.org/2001/XMLSchema"> 32
33
<xs:element name="Get_ResponseCommand">
34
<xs:annotation>
35
<xs:documentation>Schema for AF get response command</xs:documentation> 36
</xs:annotation> 37
<xs:complexType> 38
<xs:sequence> 39
<xs:element name="ErrorCode" type=" xs:unsignedByte "/> 42
<xs:element name="AttribData" type="xs:anyType"/> 43
</xs:sequence> 44
</xs:complexType> 45
46
</xs:element>
47
</xs:schema>
48
49
50
51
52
53
54

ZigBee Specification, Annex F
1 F.3 XML schema for the set command

2
3 <?xml version="1.0" encoding="UTF-8"?>
4 <xs:schema targetNamespace="http://www.zigbee.org/v1.0/AF “xmlns="http:/
5 /www.zigbee.org/v1.0/AF" xmlns:xs="http://www.w3.org/2001/XMLSchema">
6 <xs:element name="SetCommand">
7 <xs:annotation>
8 <xs:documentation>Schema for AF set command</xs:documentation>
9 </xs:annotation>
10 <xs:complexType>
11 <xs:sequence>
12 <xs:element name="AttribDataType" type="xs:unsignedByte"/>
13 <xs:element name="AttribId" type="xs:unsignedShort"/>
14 <xs:element name="AttribData" type="xs:anyType"/>
15 </xs:sequence>
16 </xs:complexType>
17 </xs:element>
18 </xs:schema>
19
20
21 F.4 XML schema for the set response command
22
23 <?xml version="1.0" encoding="UTF-8"?>
24 <xs:schema targetNamespace="http://www.zigbee.org/v1.0/AF “xmlns="http:/
25 /www.zigbee.org/v1.0/AF" xmlns:xs="http://www.w3.org/2001/XMLSchema">
26 <xs:element name="Set_ResponseCommand">
27 <xs:annotation>
28 <xs:documentation>Schema for AF set response command</xs:docu-
29 mentation>
30 </xs:annotation>
31 <xs:complexType>
32 <xs:sequence>
33 <xs:element name="AttribDataType" type="xs:unsignedByte"/>
34 <xs:element name="AttribId" type="xs:unsignedShort"/>
35 <xs:element name="ErrorCode" type=" xs:unsignedByte "/>
36 </xs:sequence>
37 </xs:complexType>
38 </xs:element>
39 </xs:schema>
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

KVP XML schemas
F.5 XML schema for the event command 1

2
<xs:schema targetNamespace="http://www.zigbee.org/v1.0/AF “xmlns="http:/ 4
/www.zigbee.org/v1.0/AF" xmlns:xs="http://www.w3.org/2001/XMLSchema"> 5
<xs:element name="EventCommand"> 6
<xs:annotation> 7
<xs:documentation>Schema for AF event command</xs:documenta- 8
tion> 9
</xs:annotation> 10
<xs:complexType> 11
<xs:sequence> 12
<xs:element name="AttribData" type="xs:anyType"/> 15
</xs:sequence> 16
</xs:element> 18
</xs:schema> 19
20
21
F.6 XML schema for the event response command 22
23
<xs:schema targetNamespace="http://www.zigbee.org/v1.0/AF “xmlns="http:/ 25
/www.zigbee.org/v1.0/AF" xmlns:xs="http://www.w3.org/2001/XMLSchema"> 26
<xs:element name="Event_ResponseCommand"> 27
<xs:annotation> 28
<xs:documentation>Schema for AF event response command</ 29
xs:documentation> 30
</xs:annotation> 31
<xs:complexType> 32
<xs:sequence> 33
<xs:element name="ErrorCode" type=" xs:unsignedByte "/> 36
</xs:sequence> 37
</xs:element> 39
</xs:schema> 40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

1 F.7 Example KVP commands

2
3 Consider a lighting profile in which a device description for a lamp defines a cluster with an unsigned 8-bit
4 attribute called “LampOnOff”, which has an identifier of 0x0000. This attribute can be set to either 0x00, to
5 represent its off state, or 0xff, to represent its on state. In order for a light switch to turn on the lamp, it would
6 need to send a command to the lamp device such as the set with acknowledgement command illustrated in
7 Figure 91.
8
9 Bits: 8 4 4 16 8
10
11 Transaction Command Attribute data
Attribute
12 sequence type identifier type Attribute data
identifier
13 number b3b2b1b0 b3b2b1b0
14
0x42 0101 0001 0x0000 0xff
15
16
17
Figure 91 Example of a set with acknowledgement command frame
18
19 As the command was a set with acknowledgement command, the lamp responds with the set response
20 command illustrated in Figure 92.
21
22 Bits: 8 4 4 16 8
23
Attribute
25 sequence type identifier type Error code
identifier
27
0x42 1001 0001 0x0000 0x00
28
29
30
31 Figure 92 Example of a set response command frame
32 The device description for the lamp also defines another cluster with a character string attribute called
33 “LampMoreInfo”, which has an identifier of 0x0001. In order for a PDA to set this attribute to the 4-
34 character ASCII character string “3NSF”, it would need to send a command to the lamp device such as the
35 set command illustrated in Figure 93.
36
37
Bits: 8 4 4 16 8 4
38
Attribute
40 sequence type identifier type Attribute data
identifier
42
0x56 0001 1110 0x0001 0x04 0x334e5346
43
44
45
46 Figure 93 Example of a KVP set command frame
47
Note that the character string type requires a character length field (equal to 0x04, in this case) as the first
48
octet of the attribute data and that no acknowledgement is required with this command.
49
50
51
52
53
54

KVP XML schemas
F.8 Example MSG command 1

2
Consider an HVAC profile in which a device description for a cooling fan defines a message to set the fan 3
speed to a number of settings. To set the fan to its third speed, a remote control device would need to send a 4
message as illustrated in Figure 94. 5
6
Bits: 8 8 8 7
8
Transaction 9
Transaction Transaction
sequence 10
length data
number 11
12
0x7d 0x01 0x02
13
14
15
Figure 94 Example of an MSG command frame to set the speed of a fan
16
Consider an agricultural sensor profile in which a device description for a soil moisture sensor defines a 17
message to configure the relative coordinates of the device using two 16-bit values. To set the coordinates 18
on the sensor, a configuration device would need to send a message as illustrated in Figure 95. 19
20
Bits: 8 8 32 21
22
Transaction 23
Transaction Transaction
sequence 24
length data
number 25
26
0xe8 0x04 0x02fe3321
27
28
29
Figure 95 Example of an MSG command frame to set x and y coordinates of a sensor 30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

Zigbee Specification: June 27, 2005

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Zigbee Specification: June 27, 2005

Uploaded by

Copyright:

Available Formats

ZigBee Specification

ZigBee Document 053474r06, Version 1.0

December 14th, 2004

Sponsored by: ZigBee Alliance

Accepted by ZigBee Alliance Board of Directors.

June 27, 2005

2 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

3 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

4 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 5

1 2.3 Service specification....................................................................................................... 161

6 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

3.5.2 Key-Establishment Services .............................................................................. 271 1

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 7

1 B.6 Block-Cipher-Based Cryptographic Hash Function.......................................................... 323

8 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

E.1 Stack Profiles ................................................................................................................... 367 1

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 9

10 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 11

Figure 47 Establishing a new network....................................................................................... 211 1

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 12

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 13

1 Table 47 User_Desc_req parameters ...................................................................................... 97

14 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 15

1 Table 155 APSME-TRANSPORT-KEY.indication parameters................................................. 281

16 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 17

Endpoint 240 Endpoint 1 Endpoint 0

ZDO Management Plane

34 Physical (PHY) Layer

18 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 19

20 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 21

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 22

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 23

24 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

MIC Message integrity code 1

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 25

WPAN Wireless personal area network 1

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 26

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 27

28 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 29

1 1.1.2.1 Key value pair service

30 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 31

32 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 33

34 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

1.1.8 ZigBee device objects 1

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 35

36 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

1.2.4 Service specification 1

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 37

1 1.2.4.1.1.1 Semantics of the service primitive

38 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

Table 2 APSDE-DATA.request parameters 1

Copyright © 2005 ZigBee Standards Organization. All rights reserved. 39

40 Copyright © 2005 ZigBee Standards Organization. All rights reserved.

1.2.4.1.2.1 Semantics of the service primitive 1