115552r00ZB BoD-ZigBee Network Device - ZigBee Gateway Standard Version 1 PDF

1
3
4
5
ZigBee Document 075468r35
Network Device: Gateway Specification
7
8
9
Revision 35
Version Number: 1.0
10
March 23rd, 2011
11
12
Sponsored by:
ZigBee Alliance
13
14
Accepted for release by:

This document has not yet been accepted for release by the ZigBee Alliance Board of Directors.
15
16
17
Abstract:
This document specifies the protocols, requirements, and standards applying to ZigBee Gateway
Devices (ZGDs)
18
19
Keywords:
ZigBee, Gateway.
20
Copyright 1996-2011 by the ZigBee Alliance.

2400 Camino Ramon, Suite 375, San Ramon, CA 94583, USA
http://www.zigbee.org
All rights reserved.
Permission is granted to members of the ZigBee Alliance to reproduce this document for their own use or the use of other ZigBee Alliance members
only, provided this notice is included. All other rights reserved. Duplication for sale, or for commercial or for-profit use is strictly prohibited without
the prior written consent of the ZigBee Alliance.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
ZigBee Document 075468r33, March 23rd, 2011
Copyright ZigBee Alliance, Inc. (2007-2011). All rights Reserved. This information within this document is the property of the
ZigBee Alliance and its use and disclosure are restricted.
Elements of ZigBee Alliance specifications may be subject to third party intellectual property rights, including without limitation,
patent, copyright or trademark rights (such a third party may or may not be a member of ZigBee). ZigBee is not responsible and shall
not be held responsible in any manner for identifying or failing to identify any or all such third party intellectual property rights.
This document and the information contained herein are provided on an AS IS basis and ZigBee DISCLAIMS ALL WARRANTIES
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO (A) ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OF THIRD PARTIES (INCLUDING WITHOUT LIMITATION ANY INTELLECTUAL
PROPERTY RIGHTS INCLUDING PATENT, COPYRIGHT OR TRADEMARK RIGHTS) OR (B) ANY IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NON-INFRINGEMENT. IN NO EVENT WILL
ZIGBEE BE LIABLE FOR ANY LOSS OF PROFITS, LOSS OF BUSINESS, LOSS OF USE OF DATA, INTERRUPTION OF
BUSINESS, OR FOR ANY OTHER DIRECT, INDIRECT, SPECIAL OR EXEMPLARY, INCIDENTIAL, PUNITIVE OR
CONSEQUENTIAL DAMAGES OF ANY KIND, IN CONTRACT OR IN TORT, IN CONNECTION WITH THIS DOCUMENT OR
THE INFORMATION CONTAINED HEREIN, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE. All
Company, brand and product names may be trademarks that are the sole property of their respective owners.
The above notice and this paragraph must be included on all copies of this document that are made.
ZigBee Alliance, Inc.
19
2400 Camino Ramon, Suite 375
20
San Ramon, CA 94583, USA
21
Page ii
Copyright 2011, The ZigBee Alliance. All rights reserved.

This is an unaccepted ZigBee specification draft, subject to change.
Contact informati on
2
3
4
Much of the information in this document is preliminary and subject to change. Members of the ZigBee
Working Group are encouraged to review and provide inputs for this proposal. For document status
updates, please contact:
5
6
7
8
9
10
11
12
13
14
15
16
Leslie Mulder
Exegin Technologies Limited
401 - 2071 Kingsway Ave.
Port Coquitlam, B.C.
Canada V3C 6N2
Voice: +1 604.468.2552
Fax: +1 604.468.2445
E-mail: ljm@exegin.com
You can also submit comments using the ZigBee Alliance reflector. Its web site address is:
www.zigbee.org
The information on this page should be removed when this document is accepted.

Page iii
Participants
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
The following is a list of those who were members of the ZigBee Alliance Gateway Working Group when
this document was released:
Pat Kinney, Chair, Kinney Consulting
Robert C. Hall, Jr., Vice Chair, RF Technologies
Christopher D. Leidigh, Chief Technical Editor, Alektrona Corporation
Leslie J. Mulder, Chair of the ZigBee Gateway Device Task Group, Exegin Technologies Limited
Wan Chin Annie Wu, Exegin Technologies Limited
Gabriel Chegaray, France Telecom
Alexis Martin, France Telecom
Giyyarpuram Madhusudan, France Telecom
Juan Agi Martin, Atalum
Claudio Borean, Telecom Italia
Roberta Giannantonio, Telecom Italia
Alberto Cuda, Telecom Italia
Andrea Ranalli, Telecom Italia
Ennio Grasso, Telecom Italia
James Higgins, Alektrona
Zachary Smith, Daintree Networks
20
21
22
23
24
The editing team was composed of the following individuals when this document was released:
Leslie Mulder
James Higgins
Wan Chin Annie Wu
Andrea Ranalli
25
26
27
28
29
30
31
32
Major contributions were received from the following individuals:

Leslie Mulder
Gabriel Chegaray
Juan Agi Martin
Alberto Cuda
Zachary Smith
James Higgins
Andrea Ranalli
Page iv

Table of Contents
ZigBee Document 075468r35 .......................................................................................................................... i
Network Device: Gateway Specification ......................................................................................................... i
Revision 35....................................................................................................................................................... i
5
6
7
Introduction .............................................................................................................................................. 1
1.1 Scope ............................................................................................................................................... 1
1.2 Purpose ............................................................................................................................................ 1
8
9
10
11
Definitions ................................................................................................................................................ 2
2.1 Conformance Levels ....................................................................................................................... 2
2.2 Definitions ....................................................................................................................................... 2
2.3 Acronyms and Abbreviations .......................................................................................................... 3
12
13
14
15
16
17
References ................................................................................................................................................ 4
3.1 ZigBee Alliance documents ............................................................................................................ 4
3.2 ISO Documents ............................................................................................................................... 4
3.3 IEEE Documents ............................................................................................................................. 4
3.4 IETF Documents ............................................................................................................................. 4
3.5 Other Normative Documents........................................................................................................... 5
18
19
20
21
22
23
24
25
ZigBee Gateway Device........................................................................................................................... 6

4.1 General Description......................................................................................................................... 6
4.1.1
ZigBee Behavior ................................................................................................................. 7
4.1.2
Compatibility ...................................................................................................................... 7
4.1.2.1 ZigBee ........................................................................................................................7
4.1.2.2 Commisioning Cluster................................................................................................8
4.1.2.3 IP ................................................................................................................................8
4.1.3
Architecture ........................................................................................................................ 8
26
27
28
29
30
31
32
33
Communication ...................................................................................................................................... 10
5.1 General Description....................................................................................................................... 10
5.2 Functions ....................................................................................................................................... 10
5.2.1
RequestIdentifier............................................................................................................... 10
5.2.2
CallbackDestination .......................................................................................................... 11
5.2.3
Timeout ............................................................................................................................. 11
5.2.4
Status ................................................................................................................................ 11
5.3 Callback Handlers ......................................................................................................................... 12
34
35
36
37
38
39
40
41
42
43
Functions ................................................................................................................................................ 13
6.1 General Description....................................................................................................................... 13
6.2 Common Function Behavior ......................................................................................................... 13
6.2.1
Effect on Invocation of a ZGD Procedure ........................................................................ 13
6.2.2
Effect on Invocation of an IPHA Event Handler .............................................................. 14
6.3 Alias Addressing ........................................................................................................................... 14
6.4 Gateway Management Object (GMO) .......................................................................................... 14
6.4.1
GetVersion Procedure ....................................................................................................... 16
6.4.1.1 When Invoked .......................................................................................................... 16
6.4.1.2 Effect on Invocation ................................................................................................. 16
Page v
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
55
6.4.2
Get Procedure....................................................................................................................17
6.4.2.1 When Invoked ......................................................................................................... 17
6.4.2.2 Effect on Invocation ................................................................................................ 17
6.4.3
Set Procedure ....................................................................................................................18
6.4.3.1 When Invoked ......................................................................................................... 18
6.4.4
CreateCallback Procedure .................................................................................................19
6.4.4.1 Filter Parameter ....................................................................................................... 19
6.4.4.2 Action Parameter ..................................................................................................... 22
6.4.4.3 When Invoked ......................................................................................................... 23
6.4.5
PollCallback procedure .....................................................................................................23
6.4.5.1 When Invoked ......................................................................................................... 24
6.4.6
DeleteCallback procedure .................................................................................................24
6.4.6.1 When Invoked ......................................................................................................... 24
6.4.7
ListCallbacks procedure ....................................................................................................25
6.4.7.1 When Invoked ......................................................................................................... 25
6.4.8
PollResults procedure .......................................................................................................25
6.4.8.1 When Invoked ......................................................................................................... 26
6.4.9
UpdateTimeout procedure .................................................................................................26
6.4.9.1 When Invoked ......................................................................................................... 26
6.4.10 StartNodeDiscovery Procedure .........................................................................................27
6.4.10.1 When Invoked ....................................................................................................... 27
6.4.10.2 Effect on Invocation .............................................................................................. 27
6.4.11 NodeDiscoveryEvent Event Handler ................................................................................28
6.4.11.1 Definition of NODE_DISCOVERY_EVENT....................................................... 28
6.4.11.2 When Invoked ....................................................................................................... 29
6.4.12 NodeLeaveEvent Event Handler .......................................................................................29
6.4.12.1 Definition of NODE_LEAVE_EVENT ................................................................ 29
6.4.12.2 When Invoked ....................................................................................................... 30
6.4.13 ReadNodeCache Procedure ...............................................................................................30
6.4.13.1 When Invoked ....................................................................................................... 32
6.4.14 StartServiceDiscovery Procedure ......................................................................................32
6.4.14.1 When Invoked ....................................................................................................... 32
6.4.15 ServiceDiscoveryEvent Event Handler .............................................................................34
6.4.15.1 Definition of SERVICE_DISCOVERY_EVENT ................................................. 34
6.4.15.2 When Invoked ....................................................................................................... 34
6.4.16 GetServiceDescriptor Procedure .......................................................................................35
6.4.16.1 When Invoked ....................................................................................................... 35
6.4.17 ServiceDescriptorEvent Event Handler ............................................................................36
6.4.17.1 Definition of SERVICE_DESCRIPTOR_EVENT ............................................... 36
6.4.17.2 When Invoked ....................................................................................................... 36
6.4.18 ReadServiceCache Procedure ...........................................................................................37
Page vi

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
55
6.4.18.1 When Invoked ........................................................................................................ 37

6.4.18.2 Effect on Invocation ............................................................................................... 37
6.4.19 StartGatewayDevice Procedure ........................................................................................ 37
6.4.19.1 When Invoked ........................................................................................................ 39
6.4.20 StartGatewayDeviceEvent Event Handler ........................................................................ 40
6.4.20.1 Definition of START_GATEWAY_DEVICE_EVENT ........................................ 40
6.4.20.2 When Invoked ........................................................................................................ 40
6.4.21 ConfigureStartupAttributeSet Procedure .......................................................................... 40
6.4.21.1 When Invoked ........................................................................................................ 42
6.4.22 ReadStartupAttributeSet Procedure .................................................................................. 42
6.4.22.1 When Invoked ........................................................................................................ 44
6.4.23 CreateAliasAddress Procedure ......................................................................................... 44
6.4.23.1 When Invoked ........................................................................................................ 45
6.4.24 DeleteAliasAddress Procedure ......................................................................................... 45
6.4.24.1 When Invoked ........................................................................................................ 45
6.4.25 ListAddresses Procedure................................................................................................... 45
6.4.25.1 When Invoked ........................................................................................................ 46
6.4.26 Leave Procedure ............................................................................................................... 46
6.4.26.1 When Invoked ........................................................................................................ 47
6.4.27 LeaveEvent Event Handler ............................................................................................... 47
6.4.27.1 Definition of LEAVE_EVENT .............................................................................. 47
6.4.27.2 When Invoked ........................................................................................................ 48
6.4.28 PermitJoin Procedure ........................................................................................................ 48
6.4.28.1 When Invoked ........................................................................................................ 49
6.4.29 PermitJoinEvent Event Handler ........................................................................................ 49
6.4.29.1 Definition of PERMITJOIN_EVENT .................................................................... 49
6.4.29.2 When Invoked ........................................................................................................ 50
6.5 ZigBee Device Profile ................................................................................................................... 50
6.5.1
SendZDPCommand Procedure ......................................................................................... 50
6.5.1.1 When Invoked .......................................................................................................... 52
6.5.2
NotifyZDPEvent Event Handler ....................................................................................... 54
6.5.2.1 Definition of ZDP_Event ......................................................................................... 54
6.5.2.2 When Invoked .......................................................................................................... 54
6.6 ZigBee Cluster Library.................................................................................................................. 55
6.6.1
SendZCLCommand Procedure ......................................................................................... 55
6.6.1.1 When Invoked .......................................................................................................... 59
6.6.2
NotifyZCLEvent Event Handler ....................................................................................... 60
6.6.2.1 When Invoked .......................................................................................................... 60
6.7 Application Support Sub-Layer..................................................................................................... 61
6.7.1
ConfigureNodeDescriptor procedure ................................................................................ 61
Page vii
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
55
6.7.1.1 When Invoked ......................................................................................................... 61

6.7.2
GetNodeDescriptor procedure ..........................................................................................62
6.7.2.1 When Invoked ......................................................................................................... 62
6.7.3
GetNodePowerDescriptor procedure ................................................................................62
6.7.3.1 When Invoked ......................................................................................................... 63
6.7.4
ConfigureUserDescriptor procedure .................................................................................63
6.7.4.1 When Invoked ......................................................................................................... 64
6.7.5
GetUserDescriptor procedure............................................................................................64
6.7.5.1 When Invoked ......................................................................................................... 64
6.7.6
ConfigureEndpoint procedure ...........................................................................................64
6.7.6.1 When Invoked ......................................................................................................... 65
6.7.7
ClearEndpoint Procedure ..................................................................................................66
6.7.7.1 When Invoked ......................................................................................................... 66
6.7.8
SendAPSMessage Procedure ............................................................................................66
6.7.8.1 When Invoked ......................................................................................................... 68
6.7.9
NofitySendAPSMessage Event Handler ...........................................................................68
6.7.10 NotifyAPSMessageEvent Event Handler..........................................................................69
6.7.10.1 When Invoked ....................................................................................................... 71
6.7.11 AddGroup Procedure ........................................................................................................71
6.7.11.1 When Invoked ....................................................................................................... 71
6.7.12 RemoveGroup Procedure ..................................................................................................72
6.7.12.1 When Invoked ....................................................................................................... 72
6.7.13 RemoveAllGroups Procedure ...........................................................................................72
6.7.13.1 When Invoked ....................................................................................................... 73
6.7.14 GetGroupList Procedure ...................................................................................................73
6.7.14.1 When Invoked ....................................................................................................... 73
6.7.15 GetBindingList Procedure.................................................................................................74
6.7.15.1 When Invoked ....................................................................................................... 75
6.8 Inter-PAN ......................................................................................................................................75
6.8.1
SendInterPANMessage Procedure ....................................................................................75
6.8.1.1 When Invoked ......................................................................................................... 77
6.8.2
NotifyInterPANMessageEvent .........................................................................................77
6.8.2.1 When Invoked ......................................................................................................... 79
6.9 Network Layer ...............................................................................................................................79
6.9.1
FormNetwork Procedure ...................................................................................................79
6.9.1.1 When Invoked ......................................................................................................... 80
6.9.2
FormNetworkEvent Event Handler ...................................................................................81
6.9.2.1 Definition of FORM_NETWORK_EVENT ........................................................... 81
Page viii

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
55
6.9.2.2 When Invoked .......................................................................................................... 81

6.9.3
StartRouter Procedure ....................................................................................................... 81
6.9.3.1 When Invoked .......................................................................................................... 82
6.9.4
StartRouterEvent Event Handler....................................................................................... 83
6.9.4.1 Definition of START_ROUTER_EVENT ............................................................... 83
6.9.4.2 When Invoked .......................................................................................................... 83
6.9.5
Join Procedure .................................................................................................................. 83
6.9.5.1 When Invoked .......................................................................................................... 84
6.9.6
JoinEvent Event Handler .................................................................................................. 85
6.9.6.1 Definition of JOIN_EVENT .................................................................................... 85
6.9.6.2 When Invoked .......................................................................................................... 85
6.9.7
Leave Procedure ............................................................................................................... 85
6.9.7.1 When Invoked .......................................................................................................... 86
6.9.8
LeaveEvent Event Handler ............................................................................................... 87
6.9.8.1 Definition of LEAVE_EVENT ................................................................................ 87
6.9.8.2 When Invoked .......................................................................................................... 87
6.9.9
DiscoverNetworks Procedure ........................................................................................... 87
6.9.9.1 When Invoked .......................................................................................................... 88
6.9.10 DiscoverNetworksEvent Event Handler ........................................................................... 89
6.9.10.1 Definition of DISCOVER_NETWORKS_EVENT ............................................... 89
6.9.10.2 When Invoked ........................................................................................................ 89
6.9.11 Reset Procedure ................................................................................................................ 89
6.9.11.1 When Invoked ........................................................................................................ 90
6.9.12 Reset Event Handler ......................................................................................................... 90
6.9.12.1 Definition of RESET_EVENT ............................................................................... 90
6.9.12.2 When Invoked ........................................................................................................ 90
6.9.13 PerformEnergyScan Procedure ......................................................................................... 91
6.9.13.1 When Invoked ........................................................................................................ 91
6.9.14 PerformEnergyScanEvent Event Handler ......................................................................... 92
6.9.14.1 Definition of PERFORM_ENERGY_SCAN_EVENT .......................................... 92
6.9.14.2 When Invoked ........................................................................................................ 92
6.9.15 NetworkStatusEvent Event Handler ................................................................................. 93
6.9.15.1 Definition of NETWORK_STATUS_EVENT ...................................................... 93
6.9.15.2 When Invoked ........................................................................................................ 93
6.9.16 PerformRouteDiscovery Procedure .................................................................................. 93
6.9.16.1 When Invoked ........................................................................................................ 94
6.9.17 PerformRouteDiscovery Event Handler ........................................................................... 95
6.9.17.1 Definition of PERFORM_ROUTE_DISCOVERY_EVENT ................................. 95
6.9.17.2 When Invoked ........................................................................................................ 95
Page ix
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
6.9.18 SendNWKMessage Procedure ..........................................................................................95

6.9.18.1 When Invoked ....................................................................................................... 97
6.9.19 NotifyNWKMessageEvent Event Handler .......................................................................97
6.9.19.1 When Invoked ....................................................................................................... 98
7
Secured Connection Protocol ( ScoP) ....................................................................................................99

7.1 General Description .......................................................................................................................99
7.1.1
SCoP Layer Overview ......................................................................................................99
7.1.1.1 SCoP Data Entity (SCDE) ....................................................................................... 99
7.1.1.2 SCoP Management Entity (SCME) ......................................................................... 99
7.1.1.3 SCoP Security Service (SCoSS) .............................................................................. 99
7.1.2
IP Routing .........................................................................................................................99
7.2 Services Specification ...................................................................................................................99
7.2.1
SCoP Management Service .............................................................................................100
7.2.1.1 Socket Management Primitives ............................................................................. 100
7.2.1.2 Information Base Maintenance .............................................................................. 108
7.2.2
SCoP Data Service Primitives .........................................................................................111
7.2.2.1 SCDE-DATA.request ............................................................................................ 111
7.2.2.2 SCDE-DATA.indication........................................................................................ 112
7.2.2.3 SCDE-DATA.confirm ........................................................................................... 113
7.3 SCoP Frame Formats ...................................................................................................................114
7.3.1
Protocol Conventions ......................................................................................................114
7.3.1.1 Transmission order ................................................................................................ 114
7.3.1.2 Integers, octets, and their representation ............................................................... 114
7.3.2
General Frame Format ....................................................................................................115
7.3.2.1 Transport Type Field ............................................................................................. 115
7.3.2.2 Protocol Version Field ........................................................................................... 116
7.3.2.3 Packet Length Field ............................................................................................... 116
7.3.2.4 Fragmentation Header ........................................................................................... 116
7.3.2.5 Security Header ..................................................................................................... 117
7.3.2.6 Service Identifier Field .......................................................................................... 119
7.3.2.7 Payload .................................................................................................................. 119
7.3.2.8 Message Integrity Code ......................................................................................... 119
7.3.3
Format of Individual Frame Types .................................................................................119
7.3.3.1 SCoP Data Frame Format ...................................................................................... 119
7.3.3.2 SCoP Command Frame Format (Service 0) .......................................................... 120
7.4 Functional Description ................................................................................................................121
7.4.1
Transport Modes: ............................................................................................................121
7.4.1.1 Connection using UDP transport mode ................................................................. 121
7.4.1.2 Security Services ................................................................................................... 121
7.4.2
Socket Initialization ........................................................................................................122
7.4.3
Connection Establishment ...............................................................................................122
7.4.4
Connection Maintenance .................................................................................................123
7.4.4.1 NAT Terminology ................................................................................................. 123
7.4.4.2 NAT issues with Transport Mode 0....................................................................... 123
7.4.4.3 Sending Keep Alive Message ................................................................................ 124
7.4.4.4 Receiving Keep Alive Ping Message .................................................................... 124
7.4.4.5 Receiving Keep Alive Pong Message and time out ............................................... 124
7.4.4.6 Security Considerations on Keep Alive Messages ................................................ 125
7.4.5
Connection Termination .................................................................................................125
7.4.5.1 Sending Goodbye command .................................................................................. 127
7.4.6
Transmission and Reception ...........................................................................................127
7.4.6.1 Data Transmission and Reception ......................................................................... 127
Page x

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
7.4.6.2 Transmission of SCoP frames ................................................................................ 127

7.4.6.3 Reception of SCoP frames ..................................................................................... 128
7.5 Constants and SCIB Attributes.................................................................................................... 129
7.5.1
SCoP Constants .............................................................................................................. 129
7.5.2
SCoP Information Base .................................................................................................. 129
7.6 SCoP Security Service ................................................................................................................ 130
7.6.1
General Description ........................................................................................................ 130
7.6.1.1 Security Architecture and Design ........................................................................... 130
7.6.1.2 CCM* Security....................................................................................................... 131
7.6.1.3 TLS Security .......................................................................................................... 131
7.6.2
Frame Security using CCM* .......................................................................................... 131
7.6.2.1 Security-Related SCIB Attributes .......................................................................... 131
7.6.2.2 Security Processing of Outgoing Frames ............................................................... 132
7.6.2.3 Security Processing of Incoming Frames ............................................................... 133
7.7 SCoP Layer Status Values........................................................................................................... 134
8
Gateway Remote Interface Protocol (GRIP) ........................................................................................ 136

8.1 General Description..................................................................................................................... 136
8.1.1
GRIP Overview .............................................................................................................. 136
8.1.1.1 GRIP Data Entity (GRIDE).................................................................................... 136
8.1.1.2 GRIP Management Entity ( GRIME) ..................................................................... 136
8.2 Service Specification ................................................................................................................... 136
8.2.1
GRIP Data Service .......................................................................................................... 136
8.2.1.1 GRIDE-DATA.request ........................................................................................... 137
8.2.1.2 GRIDE-DATA.indication ...................................................................................... 139
8.2.1.3 GRIDE-DATA.response ........................................................................................ 141
8.2.1.4 GRIDE-DATA.confirm.......................................................................................... 142
8.2.2
GRIP Management Service ............................................................................................ 143
8.2.2.1 GRIME-GET.request ............................................................................................. 143
8.2.2.2 GRIME-GET.confirm ............................................................................................ 144
8.2.2.3 GRIME-SET.request .............................................................................................. 145
8.2.2.4 GRIME-SET.confirm ............................................................................................. 146
8.3 Frame Formats ............................................................................................................................ 147
8.3.1
Transmission Order ........................................................................................................ 147
8.3.2
Reserved ......................................................................................................................... 147
8.3.3
General PDU Frame Format ........................................................................................... 147
8.3.3.1 Version field ........................................................................................................... 148
8.3.3.2 Frame Control field ................................................................................................ 148
8.3.3.3 Transaction Identifier Field .................................................................................... 148
8.3.3.4 Function Domain Field........................................................................................... 148
8.3.3.5 Function Category Field ......................................................................................... 149
8.3.3.6 Manufacturer code field ......................................................................................... 149
8.3.3.7 Function identifier field .......................................................................................... 149
8.3.3.8 Payload ................................................................................................................... 149
8.3.4
Format of Individual Frame Types ................................................................................. 149
8.3.4.1 Request frame format ............................................................................................. 149
8.3.4.2 Response frame format........................................................................................... 150
8.4 Functional Description ................................................................................................................ 151
8.4.1
Request and Response Transaction ................................................................................. 151
8.4.1.1 Request Emission and Response Reception ........................................................... 151
8.4.1.2 Request Reception and Response Reply ................................................................ 152
8.4.2
Transmission ................................................................................................................... 153
8.4.3
Reception and Rejection ................................................................................................. 154
8.4.4
Closing the Connection with a Peer ................................................................................ 154
8.5 GRIP Information Base ............................................................................................................... 154
Page xi
8.6
GRIP Layer Status Values ...........................................................................................................155
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
GRIP Binding for ZGD ........................................................................................................................156

9.1 General Description .....................................................................................................................156
9.2 RPC Protocol Description ...........................................................................................................156
9.2.1
Transport .........................................................................................................................156
9.2.2
ZGD and IPHA Applications ..........................................................................................156
9.2.3
ZGD implementing a GRIP Server .................................................................................156
9.2.3.1 Functions Supported .............................................................................................. 158
9.2.4
ZGD implementing a GRIP Client ..................................................................................159
9.2.4.1 Functions Supported .............................................................................................. 160
9.2.5
Security Operations .........................................................................................................161
9.3 ZGD Functions ............................................................................................................................161
9.3.1
Parameters and Results Encoding ...................................................................................161
9.3.1.1 General Encoding Rules ........................................................................................ 161
9.3.1.2 Functions Specific Parameters and Results Encoding ........................................... 162
9.3.2
Function Identification ....................................................................................................179
9.3.2.1 Function Domain ................................................................................................... 179
9.3.2.2 Function Categories ............................................................................................... 179
9.3.2.3 Function Identifiers ............................................................................................... 179
20
21
22
23
24
10 SOAP Binding ......................................................................................................................................184

10.2 Transport .....................................................................................................................................184
10.3 WSDL..........................................................................................................................................184
10.3.1 Information Base Attribute Types ...................................................................................184
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
11 REST Binding ......................................................................................................................................186

11.2 Resources.....................................................................................................................................186
11.3 REST Interface ............................................................................................................................190
11.3.1 Procedures .......................................................................................................................190
11.3.2 Events..............................................................................................................................191
11.3.3 General Parameters and Results ......................................................................................192
11.4 Function Mappings ......................................................................................................................192
11.4.1 General Description ........................................................................................................192
11.4.2 Gateway Management Profile (GMP).............................................................................194
GetVersion Procedure ........................................................................................................... 194
Get Procedure ........................................................................................................................ 194
Set Procedure ........................................................................................................................ 194
CreateCallback Procedure ..................................................................................................... 194
UpdateTimeout Procedure..................................................................................................... 195
PollCallback Procedure ......................................................................................................... 195
PollResults Procedure ........................................................................................................... 196
DeleteCallback Procedure ..................................................................................................... 196
ListCallbacks Procedure ........................................................................................................ 196
StartNodeDiscovery Procedure ............................................................................................. 196
NodeDiscoveryEvent Event Handler .................................................................................... 197
NodeLeaveEvent Event Handler ........................................................................................... 197
ReadNodeCache Procedure ................................................................................................... 197
StartServiceDiscovery Procedure .......................................................................................... 197
ServiceDiscoveryEvent Event Handler ................................................................................. 197
GetServiceDescriptor Procedure ........................................................................................... 197
ServiceDiscoveryEvent Event Handler ................................................................................. 198
ReadServiceCache Procedure ............................................................................................... 198
Page xii

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
StartGatewayDevice Procedure ............................................................................................. 198

StartGatewayDeviceEvent Event Handler ............................................................................. 198
ConfigureStartupAttributeSet Procedure ............................................................................... 199
ReadStartupAttributeSet Procedure ....................................................................................... 199
CreateAliasAddress Procedure .............................................................................................. 199
DeleteAliasAddress Procedure .............................................................................................. 199
ListAddresses Procedure ........................................................................................................ 199
Leave Procedure .................................................................................................................... 200
LeaveEvent Event Handler .................................................................................................... 200
PermitJoin Request ................................................................................................................ 200
PermitJoinEvent Event Handler ............................................................................................. 200
11.4.3 ZigBee Device Profile .................................................................................................... 200
SendZDPCommand Procedure .............................................................................................. 200
NotifyZDPEvent Event Handler ............................................................................................ 201
11.4.4 ZigBee Cluster Library ................................................................................................... 201
SendZCLCommand Procedure .............................................................................................. 201
NotifyZCLEvent Event Handler ............................................................................................ 201
11.4.5 Application Support Sub-Layer ...................................................................................... 201
ConfigureNodeDescriptor Procedure ..................................................................................... 201
GetNodeDescriptor Procedure ............................................................................................... 202
GetNodePowerDescriptor Procedure ..................................................................................... 202
ConfigureUserDescriptor Procedure ...................................................................................... 202
GetUserDescriptor Procedure ................................................................................................ 202
ConfigureEndpoint Procedure................................................................................................ 202
ClearEndpoint Procedure ....................................................................................................... 202
SendAPSMessage Procedure ................................................................................................. 203
NofitySendAPSMessageEvent Handler ................................................................................. 203
NotifyAPSMessageEvent Event Handler .............................................................................. 203
AddGroup Procedure ............................................................................................................. 203
RemoveGroup Procedure ....................................................................................................... 203
RemoveAllGroups Procedure ................................................................................................ 203
GetGroupList Procedure ........................................................................................................ 203
GetBindingList Procedure ..................................................................................................... 204
SendInterPANMessage Procedure ......................................................................................... 204
NotifyInterPANMessageEvent Event Handler ...................................................................... 204
11.4.6 Network Layer ................................................................................................................ 204
FormNetwork Procedure ........................................................................................................ 204
FormNetworkEvent Event Handler ....................................................................................... 205
StartRouter Procedure ............................................................................................................ 205
Join Procedure........................................................................................................................ 205
JoinEvent Event Handler ....................................................................................................... 205
Reset Procedure ..................................................................................................................... 205
DiscoverNetworks Procedure ................................................................................................ 205
DiscoverNetworksEvent Event Handler ................................................................................ 206
PerformEnergyScan Procedure .............................................................................................. 206
PerformEnergyScanEvent Event Handler .............................................................................. 206
NetworkStatusEvent Event Handler ...................................................................................... 206
PerformRouteDiscovery Procedure ....................................................................................... 206
PerformRouteDiscoveryEvent Event Handler ....................................................................... 206
SendNWKMessage Procedure ............................................................................................... 207
NotifyNWKMessageEvent Event Handler ............................................................................ 207
52
53
Information Base Attributes ........................................................................................................................ 208

Gateway Information Base ................................................................................................................... 208
Page xiii
GRIP ASN.1 ................................................................................................................................................209
SOAP & Rest Schema .................................................................................................................................217
SOAP WSDL...............................................................................................................................................228
REST Schema ..............................................................................................................................................265
5
6
7
8
9
Gateway Management Cluster .....................................................................................................................272

General Description ..............................................................................................................................272
Gateway Management Cluster..............................................................................................................272
Gateway Data Interface Cluster ............................................................................................................273
Common Data Sink Cluster ..................................................................................................................275
10
Page xiv

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
List of Figures
Figure 3: Procedure and Event Handler Function Invocations ...................................................................... 10
Figure 4: ClusterGroup Logical Identifier Hierarcy ...................................................................................... 22
Figure 5: The SCoP Layer Reference Model .............................................................................................. 100
Figure 6: General SCoP Frame Format ....................................................................................................... 115
Figure 7: Unsecured and secured SCoP Packet Structure ........................................................................... 115
Figure 8: Fragmentation Header Field Format ............................................................................................ 116
Figure 9: Fragmentation Frame Control field format .................................................................................. 116
Figure 10: Security Header Field Format .................................................................................................... 117
Figure 11: Security Control Sub-Field Format ............................................................................................ 118
Figure 12: SCoP Command Frame Format ................................................................................................. 120
Figure 13: SCoP Connection Establishment Sequence ............................................................................... 123
Figure 14: SCoP Connection Keep Alive .................................................................................................... 125
Figure 15: SCoP Connection Termination .................................................................................................. 126
Figure 16: SCoP Data Transmission ........................................................................................................... 127
Figure 17: GRIP Reference Model .............................................................................................................. 136
Figure 18: General GRIP Frame Format ..................................................................................................... 147
Figure 19: Format of the Frame Control Field ............................................................................................ 148
Figure 20: GRIP Request Frame Payload.................................................................................................... 150
Figure 21: GRIP Response Frame Payload ................................................................................................. 150
Figure 22: GRIP Request and Response Transaction .................................................................................. 151
Figure 23: GRIP Request with Connection Establishment .......................................................................... 152
Figure 24: GRIP Request on an Established Connection ............................................................................ 152
Figure 25: GRIP Request Reception and Response Reply .......................................................................... 153
Figure 26: Procedure call using GRIP ......................................................................................................... 157
Figure 27: Operations of a ZGD Application Implementing the GRIP Server ........................................... 158
Figure 28: Event Handler Call using GRIP ................................................................................................. 159
Figure 29: Operations of a ZGD Application implementing the GRIP client ............................................. 160

Page xv
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
List of Tables
Table 1: Document revision change history ................................................................................................ xxi
Table 2 Status Codes ....................................................................................................................................12
Table 3 GMO Functions ................................................................................................................................14
Table 4 GMO GetVersion Procedure Results ................................................................................................16
Table 5 GMO Get Procedure Parameters ......................................................................................................17
Table 6 GMO Get Procedure Results ............................................................................................................17
Table 7 GMO Set Procedure Parameters .......................................................................................................18
Table 8 GMO Set Procedure Results .............................................................................................................18
Table 9 GMO CreateCallback Procedure Parameters ..................................................................................19
Table 10 GMO CreateCallback Procedure Results .......................................................................................19
Table 11 LevelSpecification Element .........................................................................................................19
Table 12 - AddressSpecification Elements ....................................................................................................19
Table 13 - MessageSpecification Elements ...................................................................................................20
Table 14 DecodeSpecification Element ......................................................................................................22
Table 15 ForwardingSpecification Element ...............................................................................................23
Table 16 GMO PollCallback Procedure Parameters....................................................................................23
Table 17 GMO PollCallback Procedure Results ...........................................................................................24
Table 18 GMO DeleteCallback Procedure Parameters ..................................................................................24
Table 19 GMO DeleteCallback Procedure Results .......................................................................................24
Table 20 GMO ListCallbacks Procedure Results ..........................................................................................25
Table 21 GMO PollResults Procedure Parameters ......................................................................................25
Table 22 GMO PollResults Procedure Results ..............................................................................................25
Table 23 GMO UpdateTimeout Procedure Parameters ...............................................................................26
Table 24 GMO UpdateTimeout Procedure Results .......................................................................................26
Table 25: StartNodeDiscovery Procedure Parameters ...................................................................................27
Table 26: StartNodeDiscovery Procedure Results .........................................................................................27
Table 27: NodeDiscoveryEvent Event Handler Parameters ..........................................................................28
Table 28: NodeDiscoveryEvent Event Handler Results ................................................................................28
Table 29: NodeLeaveEvent Event Handler Parameters .................................................................................29
Table 30: NodeLeaveEvent Event Handler Results .......................................................................................29
Table 31: ReadNodeCache Procedure Results ..............................................................................................31
Table 32: Node Addresses Structure .............................................................................................................31
Table 33: StartServiceDiscovery Procedure Parameters ...............................................................................32
Table 34: StartServiceDiscovery Procedure Results .....................................................................................32
Table 35: ServiceDiscoveryEvent Event Handler Parameters .......................................................................34
Table 36: ServiceDiscoveryEvent Event Handler Results .............................................................................34
Table 37: GetServiceDescriptor Procedure Parameters .................................................................................35
Table 38: GetServiceDescriptor Procedure Results .......................................................................................35
Table 39: ServiceDescriptorEvent Event Handler Parameters ......................................................................36
Table 40: ServiceDescriptorEvent Event Handler Results ............................................................................36
Table 41: ReadServiceCache Procedure Results ...........................................................................................37
Table 42: Node Service Structure ..................................................................................................................37
Table 43: StartGatewayDevice Procedure Parameters ..................................................................................38
Table 44: StartGatewayDevice Procedure Results and StartGatewayDeviceEvent Event Handler Parameters39
Table 45 StartGatewayDeviceEvent Event Handler Results .........................................................................40
Table 46: ConfigureStartupAttributeSet Procedure Parameters ....................................................................41
Table 47 ConfigureStartupAttributeSet Procedure Results ...........................................................................42
Table 48 ReadStartupAttributeSet Procedure Parameters .............................................................................43
Table 49: ReadStartupAttributeSet Procedure Results ..................................................................................43
Table 50 GMO CreateAliasAddress Procedure Parameters ..........................................................................44
Table 51 GMO CreateAliasAddress Procedure Results ................................................................................44
Table 52 GMO DeleteAliasAddress Procedure Parameters ..........................................................................45
Page xvi
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
55
Table 53 GMO DeleteAliasAddress Procedure Results ................................................................................ 45

Table 54 GMO ListAddresses Procedure Parameters ................................................................................... 45
Table 55 GMO ListAddresses Procedure Results ......................................................................................... 46
Table 56: Leave Procedure Parameters ......................................................................................................... 46
Table 57: Leave Procedure Results and Leave Event Handler Parameters ................................................... 47
Table 58 LeaveEvent Event Handler Results ................................................................................................ 47
Table 59: PermitJoin Procedure Parameters .................................................................................................. 48
Table 60: PermitJoin Procedure Results and PermitJoinEvent Event Handler Parameters ........................... 49
Table 61 PermitJoinEvent Event Handler Results......................................................................................... 49
Table 62: ZigBee Device Profile Functions .................................................................................................. 50
Table 63: SendZDPCommand Procedure Parameters ................................................................................... 51
Table 64: SendZDPCommand Procedure Results and NotifyZDPEvent Event Handler Parameters ........... 52
Table 65: NotifyZDPEvent Event Handler Results ....................................................................................... 54
Table 66: ZigBee Cluster Library Functions ................................................................................................. 55
Table 67: SendZCLCommand Parameters .................................................................................................... 56
Table 68: SendZCLCommand Procedure Results ......................................................................................... 57
Table 69: NotifyZCLEvent Event Handler Results ....................................................................................... 60
Table 70: Application Support Sub-Layer Functions .................................................................................... 61
Table 71: ConfigureNodeDescriptor Procedure Parameters ......................................................................... 61
Table 72: ConfigureNodeDescriptor Procedure Results ............................................................................... 61
Table 73: GetNodeDescriptor Procedure Results .......................................................................................... 62
Table 74: GetNodePowerDescriptor Procedure Results ................................................................................ 63
Table 75: ConfigureUserDescriptor Procedure Parameters........................................................................... 63
Table 76: ConfigureUserDescriptor Procedure Results ................................................................................ 63
Table 77: GetUserDescriptor Procedure Results ........................................................................................... 64
Table 78: ConfigureEndpoint Procedure Parameters .................................................................................... 65
Table 79: ConfigureEndpoint Procedure Results .......................................................................................... 65
Table 80: ClearEndpoint Procedure Parameters ............................................................................................ 66
Table 81: ClearEndpoint Procedure Results .................................................................................................. 66
Table 82: SendAPSMessage Procedure Parameters ...................................................................................... 67
Table 83: SendAPSMessage Procedure Results ............................................................................................ 68
Table 84: NotifyAPSMessageEvent EventHandler Parameters .................................................................... 70
Table 85: NotifyAPSMessageEvent Event Handler Results ......................................................................... 71
Table 86: AddGroup Procedure Parameters .................................................................................................. 71
Table 87: AddGroup Procedure Results ........................................................................................................ 71
Table 88: RemoveGroup Procedure Parameters............................................................................................ 72
Table 89: RemoveGroup Procedure Results ................................................................................................. 72
Table 90: RemoveAllGroups Procedure Parameters ..................................................................................... 72
Table 91: RemoveAllGroups Procedure Results ........................................................................................... 72
Table 92: GetGroupList Procedure Results ................................................................................................... 73
Table 93: Groups Per Endpoint Entry ........................................................................................................... 73
Table 94: GetBindingList Procedure Results ................................................................................................ 74
Table 95: Binding Entry ................................................................................................................................ 74
Table 96: Binding Device Destination Entry ................................................................................................ 75
Table 97 Inter-PAN Functions .................................................................................................................... 75
Table 98: SendInterPANMessage Procedure Parameters .............................................................................. 76
Table 99: SendInterPANMessage Procedure Results.................................................................................... 76
Table 100: NotifyInterPANMessageEvent Event Handler Parameters ......................................................... 78
Table 101: NotifyInterPANMessageEvent Event Handler Results ............................................................... 78
Table 102 Network Layer Functions ........................................................................................................... 79
Table 103: FormNetwork Procedure Parameters .......................................................................................... 80
Table 104: FormNetwork Procedure Results and FormNetworkEvent Event Handler Parameters .............. 80
Table 105 FormNetworkEvent Event Handler Results ................................................................................. 81
Table 106: StartRouter Procedure Parameters ............................................................................................... 82
Table 107: StartRouter Procedure Results..................................................................................................... 82
Page xvii
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
55
Table 108 StartRouterEvent Event Handler Results ......................................................................................83

Table 109: Join Procedure Parameters ...........................................................................................................84
Table 110: Join Procedure Results and JoinEvent Event Handler Parameters ..............................................84
Table 111 JoinEvent Event Handler Results .................................................................................................85
Table 112: Leave Procedure Parameters .......................................................................................................86
Table 113: Leave Procedure Results and Leave Event Handler Parameters .................................................86
Table 114 LeaveEvent Event Handler Results ..............................................................................................87
Table 115: DiscoverNetworks Procedure Parameters ...................................................................................87
Table 116: DiscoverNetworks Procedure Results and DiscoverNetworksEvent Event Handler Parameters 88
Table 117 DiscoverNetworksEvent Event Handler Results ..........................................................................89
Table 118: Reset Procedure Parameters ........................................................................................................89
Table 119: Reset Procedure Results ..............................................................................................................90
Table 120 ResetEvent Event Handler Results ...............................................................................................90
Table 121: PerformEnergyScan Procedure Parameters .................................................................................91
Table 122: PerformEnergyScan Procedure Results and PerformEnergyScanEvent Event Handler
Parameters .............................................................................................................................................91
Table 123 PerformEnergyScanEvent Event Handler Results ........................................................................92
Table 124: NetworkStatusEvent Event Handler Parameters .........................................................................93
Table 125: NetworkStatusEvent Event Handler Results ...............................................................................93
Table 126: PerformRouteDiscovery Procedure Parameters ..........................................................................94
Table 127: PerformRouteDiscovery Procedure Results and PerformRouteDiscoveryEvent Event Handler
Parameters .............................................................................................................................................94
Table 128 PerformRouteDiscoveryEvent Event Handler Results .................................................................95
Table 129: SendNWKMessage Procedure Parameters ..................................................................................96
Table 130: SendNWKMessage Procedure Results ........................................................................................96
Table 131: NotifyNWKMessageEvent Event Handler Parameters ...............................................................98
Table 132 NotifyZDPEvent Event Handler Results ......................................................................................98
Table 133: SCDE-SAP and SCME-SAP primitives ....................................................................................100
Table 134: SCME-OPEN.request Parameters .............................................................................................101
Table 135: SCME-OPEN.indication Parameters .........................................................................................102
Table 136: SCME-OPEN.confirm Parameters ............................................................................................104
Table 137: SCME-CLOSE.request Parameters ...........................................................................................105
Table 138: SCME-CLOSE.indication Parameters .......................................................................................105
Table 139: SCME-CLOSE.confirm Parameters ..........................................................................................106
Table 140: SCME-LISTEN.request Parameters ..........................................................................................107
Table 141: SCME-LISTEN.confirm Parameters .........................................................................................108
Table 142: SCME-GET.request Parameters ................................................................................................109
Table 143: SCDE-GET.confirm Parameters................................................................................................110
Table 144: SCDE-SET.request Parameters .................................................................................................110
Table 145: SCDE-SET.confirm Parameters ................................................................................................111
Table 146: SCDE-DATA.request Parameters .............................................................................................112
Table 147: SCDE-DATA.indication Parameters .........................................................................................113
Table 148: SCDE-DATA.confirm Parameters ............................................................................................114
Table 149: SCoP Transport Type field ........................................................................................................116
Table 150: CCM* Security Levels available to the SCoP ...........................................................................118
Table 151: Encoding Values for the Service Identifier field .......................................................................119
Table 152: Command Type Values .............................................................................................................120
Table 153: SCoP Transport Modes ..............................................................................................................121
Table 154: IANA port number assignment for SCoP ..................................................................................122
Table 155: SCoP Protocol Constants ...........................................................................................................129
Table 156: SCIB Attributes .........................................................................................................................130
Table 157: SCoP Security-related SCIB Attributes .....................................................................................132
Table 158: Attributes of an Incoming Frame Counter Descriptor ...............................................................132
Table 159: Attributes of a Security Material Descriptor ..............................................................................132
Table 160: SCoP Layer Status Values .........................................................................................................135
Page xviii

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
Table 161: GRIDE-SAP primitives ............................................................................................................. 137

Table 162: GRIDE-DATA.request Parameters ........................................................................................... 138
Table 163: GRIDE-DATA.indication Parameters ....................................................................................... 140
Table 164: GRIDE-DATA.response Parameters ......................................................................................... 141
Table 165: GRIDE-DATA.confirm Parameters .......................................................................................... 142
Table 166: GRIDE-GET.request Parameters .............................................................................................. 144
Table 167: GRIDE-GET.confirm Parameters ............................................................................................. 145
Table 168: GRIDE-SET.request Parameters ............................................................................................... 146
Table 169: GRIDE-SET.confirm Parameters .............................................................................................. 146
Table 170: Values of the Frame Type Sub-Field ........................................................................................ 148
Table 171: Values of the Function Category Field ...................................................................................... 149
Table 172: RPC Table Entry Format ........................................................................................................... 153
Table 173: GRIP Information Base ............................................................................................................. 155
Table 174: GRIP Layer Extra Status Values ............................................................................................... 155
Table 175: Functions Supported by a ZGD implementing the GRIP Server............................................... 158
Table 176: Functions Supported by a ZGD implementing the GRIP Client ............................................... 161
Table 177: Values of the Function Category Field for ZGD ....................................................................... 179
Table 178: Function Identifiers of ZGD domain for GRIP Binding ........................................................... 179
Table 179: SOAP Simple Information BaseType Mappings ....................................................................... 184
Table 180: Gateway Resources ................................................................................................................... 187
Table 181: Network Resources ................................................................................................................... 188
Table 182: Network Resources: /wsnnodes subtree .................................................................................... 189
Table 183: Network Resources: /wsnnodes/services subtree ...................................................................... 189
Table 184: REST Parameters Syntax .......................................................................................................... 192
Table 185 GMO Attributes ......................................................................................................................... 208
Table 186 ZigBee Network Status GMO Attribute Enumeration .............................................................. 208

Page xix
Change history
Table 1 shows the change history for this specification.
Page xx

Table 1: Document revision change history

Revision
Date
Comment
00
October 8, 2007
- Preliminary release.
01
October 11, 2007
- Removal of the majority of the items in the document that were deemed to be
priority 3.
- Changes to the Normal style from Times Roman to Arial
- Minor spelling corrections.
02
November 26, 2007
- New proposed Table of Contents.
03
November 27, 2007
- Expanded template examples.
04
November 27, 2007
- Revised Table of Contents.

- Applied MS Word specification template.
- Operation template for ZDP completed.
05
November 28, 2007
- Rough draft of Communications Mode section.

- Rough draft of Operations overview sections.
- Completed outline.
06
November 29, 2007
- Communication Transactions section cleaned up and sequence diagrams

added.
07
November 30, 2007
- Added more description of callbacks and abstract callback operations.

- SOAP binding overview.
08
December 3, 2007
-Includes ZIPT frame descriptions
09
December 26, 2007
- Move Communication Transactions section before Operations section

- Update Mapped Transaction diagram in Communication Transactions section
- Added TimeoutEvent and ExpireTimeout abstract operations for mapped
transactions
- Updated Device Profile section to describe support for mapped transaction
mode
10
December 27, 2007
- Add REST section per Telecom Italia

- Add Application abstract operations for Register, Un-register endpoints and
Send Message
11
December 30, 2007
- Add abstract operations for read and write mac/network/application/gateway

attributes
- Add abstract operations for cluster library
12
January 6, 2008
- Add network discovery abstract operation

- Add ZGD formation, start router, join, leave, and reset abstract operations
13
January 22, 2008
- Imported FTs 075468r05 ZIPT and GRIP sections.

- Imported Exegins security layer document.
- Imported TIs Node and Service Discovery, UpdateTimeout, and REST
Binding
14
January 25, 2008
- Resolve formatting issues

- Update ZIPT section

Page xxi
15
February 4, 2008
- Update SOAP binding section

- Replace GCA with IPHA
- Template for operation definitions
- Renew timeout operation
- Gateway version operation
- Integrate AIB, NIB, and PIB Read/Write operations from Juans document.
16
February 11, 2008
- Section 5 Communication overhaul

- New function skeleton examples
- Search and replace CGA with IPHA
- Editorial cleanup on some table and figure headings
17
February 19, 2008
- Updated section 5 with Telecom Italias comments

- Updated gateway management functions Callback Create, Callback Destroy,
Callback Poll, Callback Update Timeout to new function format.
- Added details to callback filters and actions.
- Removed Callback Expire and Timeout Event functions.
- Renamed Callback Name parameter to CallbackIdentifier and it is now
returned by the Callback Create call, rather than supplied as a parameter.
18
February 23, 2008
- ASN.1 ISO references and IETF TLS reference

- Update ZIPT, GRIP and GRIP binding sections
19
March 7, 2008
- Incorporate Leslies preliminary introduction

- Address Alexis comments (Section 5 only) from Feb 26
- Update REST section per Alberto from Feb 21
- Added Generic Function operation in section 5 with comment resolution.
- Update with Gabriels ZDP functions
- Updated tables, indexes, etc.
20
April 11, 2008
- Add Implementation Status tables at the beginning of each Function section.

- Updated ZIPT/GRIP/GRIP Binding sections to 08143r01
- Renamed queue to buffer and removed requirement for FIFO and made it a
recommendation.
- Updated callback sections, adds filtering, levels, etc.
- Updated generic ZDP functions
- First pass generic ZCL functions
- Removed Security Layer functions and put into another document (084826) for
updating and review.
- Updated GMP functions
- Removed detailed ZDP and ZCL functions and put into another document
(084813r00) for updating and review
- Combine IB functions into one put into Annex
- Update NWK section
Deferred to Rev 21:
Page xxii

- Startup attribute set and gateway cluster

- ConfigureZigBee Function
- IB attributes cleanup in 0
- Possible reintroduction of IPHA invokable trust center functions
- SOAP Update based on stable abstract function list.
- Resolve open comments in document.
- Update introductory sections
21
May 13, 2008
- Updated contributors section

- Update mandatory and optional function implementation status according to
M_O_Functions_ALL_2-1.xls, 3 votes and higher is M
- Update REST with Albertos document
Added Get (NodeDescriptor, NodePowerDescriptor, UserDescriptor) support
functions.
- Fixup IB Get and Set functions. Removed IB type parameter from Get and Set
functions. Removed duplicated Information base tables from document.
Updated Get and Set abstract functions to reference IB tables in [R1]. SOAP
binding indicates how base IB types are mapped.
- APS Acks No change. ZGD controls APS acks and it is not offloadable to
IPHA. An IPHA sending an APS packets with ACK requested will not receive a
notification event until the APS ack is received.
- Function to receive APS messages
- Defined ConfigureZigBee abstract function.
- Additions to NodeDiscoveryEvent handler (Parent addr, MAC capability)
- SOAP section up to date with all abstract functions.
- SOAP WSDL in Annex
- SOAP/REST Schema in Annex
- Comment resolution
- Update all headers/dates and figures and tables.
Deferred to r22:
- Update to introduction
- Define gateway cluster
- Update to GRIP binding
- Update to REST as necessary
- Continue to resolve open comments
22
June 3, 2008
Updated GRIP section/ASN.1, copied other comments to this document.

Updated SOAP WSDL with new Network layer functions.
Updated SOAP/REST schema.
Updated Network section, small fixes plus two new functions to send and
receive nwk commands, and event handler functions.
Updated REST schema.
Added initial gateway cluster definition.

Page xxiii
Updated tables/figures/doc info.

Deferred to r23:
Update to introduction.
23
June 4, 2008
Updated introduction.
Renamed SendNWKCommand function to SendNWKMessage.
Renamed ConfigureZigBee function to StartGatewayDevice.
Added AddressMode parameter to Send/Notify command and message
functions to allow for all addressing modes supported by [R1].
Added ZCLHeader param to SendZCLCommand for full ZCL header setup
Indicate that not only are zigbee frames buffered in a callback, but also the
results of Event Handlers which allows for pollable systems. Most functions that
supported CallbackIdentifier now support CallbackDestination, but now all since
some return many results.
Propagate URIListener concept, created CallbackDestination general parameter
that allows ephemeral callback handler to be easily created.
Rename GMP to GMO.
Added ConfigureStartupAttributeSet and ReadStartupAttributeSet functions.
Updated REST binding section and REST schema.
Updated ZIPT/GRIP binding section and ASN.1.
- remove status colum of table 143 & 144
- add the encoding for LeaveEvent, SendNWKMessage & NotifyNWKMessageEvent
functions
- updated encodings for functions with optional parameters with an ASN1 structure as
discussed during the meeting
- update ZCL functions parameters (address mode and ZCLheader)
- remove configureNodePowerDescriptor, discovery and binding cache functions
- change configureZigBee with startGatewayDevice functions
Fixed APSMessage and APSMessageEvent definitions (missing/misspelled

profile & cluster IDs)
Resolve open comments
gal schema changes:
- Add ConfigureZigBee index param
- types for Configure/ReadStartupAttributeSet, may be the same as ConfigZB
- APSMessageEvent empty
- fix Messages choice => NetworkMessage to NetworkMessageEvent
- Remove complex descriptor type
Updated SOAP binding/WSDL.

Update indexes, tables, versions, header, footers, etc.
Updated Gateway Cluster
24
Sept 25, 2008
- Important clarifications in the communication section. Removed all references

to buffering in callback handlers, decoupled callback handlers and non-blocking
procedure invocations. CHANGES MUST BE PROPAGATED TO ALL
BINDINGS
- Bunch of addressing extensions. Basically allow IPHA to use IEEE or alias
address to send a ZigBee frame and supply IEEE and/or alias address along with
short address when supplying results to the IPHA. In some cases, such as with
associated device lists, only 16-bit addresses are returned, the IPHA can resolve
Page
xxiv

them to ieee or alias addresses if desired. Some additional address management

procedures added. CHANGES MUST BE PROPAGATED TO ALL
BINDINGS
- Incorporated Inter-PAN functions from Dan. CHANGES MUST BE
PROPAGATED TO ALL BINDINGS
- Moved Gateway Cluster to Annex. UPDATES STILL NEEDED FOR THIS
SECTION
25
November 24, 2008
Updated for ZIPT SCoP protocol name change

Incorporated revised Scop, GRIP, GRIP Binding sections and GRIP ASN.1
encoding schema annex.
Incorporated revised REST binding section and REST schema annex
26
November 25, 2008
Updated revision number due to failed document repository upload.

No material changes were made to R25
27
December 23, 2008
- Made fixes to gateway profile annex and reference from main document.
- Updated revision, headers, tables, etc.
- Localhost => Empty string for Polling DONE
- Updated SOAP WSDL Annex, added SOAP XSD
- Add CallbackIdentifier as optional parameter to NotifyAPSMessage,
NotifyZCLEvent, NotifyInterPANMessage, and NotifyZDPEvent. DONE
- Make APS parameters optional like ZCLCommand for indirect messages.
DONE
- Clarified the meaning of mandatory and optional for filter elements. DONE
- Fixed editorial error, <MessageEventtype> replaced by <ClusterGroup>.
DONE
- Added section to describe the purpose of ForwardingSpecification. DONE
- Removed duplicate SourceEndpoint result and unnecessary CommandId from
ZCL procedure results. DONE
- Made rxtime, destep, zclheader, zclpayload optional results of ZCL command
procedure since they may not always be returned. DONE
- #15 we could combine ZCLHeader and ZCLPayload into a
ZCLFrame parameter as the ZGD do not have to decode the ZCLFrame.: We
could do this, but would require updates to all bindings, not changing for now
DONE
- chapter 6.6 ZDP command Procedure parameter (table 53 p45)
#16 Shouldnt the DestinationAddressMode be a mandatory parameter?( if not
present what is the reatment to do ? ) A: It is optional for APS type send
requests that could use a binding table, otherwise it is mandatory. DONE
- CallbackIdentifier removed from SendAPSMessage parameters. DONE
- Added InterPAN support to PollCallback results. DONE
- Created a name AliasAddress for value 0x10 of destination address mode, we
have to ask CSG to reserve official value. DONE
Made clarifications to the Filter parmeter description. DONE

Page xxv
28
February 28, 2009
- Significant editorial fixes and updates.

- Updated schema.
- Updated SOAP WSDL.
- Updated REST
- Updated ScoP/ASN.1 encoding
- Revisioned of all on invocation sections to include reference to
common/default behaviour..
- Resolved Alexis comment 8.3.3.4
- Accepted Alexis comment
- Incorporated updated ZGD Profile and Clusters.
- GRIP LeaveEvent missing, fixed.
Requires Resolution:
- Assign a non-overlapping ID for GIB ZigBee Network Status attribute.
- Assign an id for AliasAddress a DestinationAddressMode type
subclause 6.3
29
May 3, 2010
30
July, 2010
31
Semptember, 2010
32
October, 2010
33
November, 17th 2010
34
February, 10th 2011
35
March, 10th 2011
Page
xxvi
-Significant editorial fixes and updates

- Inserted a new reference for the recently approved Gateway White
Paper
- Added a new paragraph in the General Description section
- Updated Annex schemas based on the lastest xsd document used by
Exegin and Telecom Italia
- Updated WSDL
- Modified ZGD Procedure Description
- Added the NotifySendAPSEvent Procedure
- Added a new paragraph (4.1.1 ZigBee Behavior) to solve comments
5 and 7 of ZARC.
- Updated ZigBee logo
- Renamed in some commands the element profile with ProfileID
and cluster with ClusterID
- Modifies made to the ListAddress procedure at REST level in order to
request only one of the ShortAddress, ExtendedAddress or
AliasAddress.
- Fixed the following CCB comments: 1229, 1231, 1232, 1233, 1245,
1247, 1249, 1250, 1251, 1253, 1254, 1255, 1256, 1257 and 1259.
- Inserted extra text on page 63, "ConfigureEndpoint procedure, to
fixed a known bug for some chipset vendors.
- UpdateTimeout procedure is now optional since during many remote
test event it became clear that it is not possible to test such procedure
with the current Test Harness tool.
- Updated the SOAP schemas
- Correct the Leave procedure within the REST section
- Inserted the PermitJoin procedure
Small updates done in order to reflect some discussions had during the
last remote test event before the certification event (test specification
document updated as well)
Updated the Schemas. This release has been used in Dublin, November
2010, to officially certify the gateway devices.
Small editorial changes following the feedbacks received when
converting the spec from word to FileMaker.
Final editorial changes before the publication of this document

Introduction
1.1
3
4
5
6
This draft describes how ZigBee Gateway Devices (ZGD) and IP based host applications (IPHAs)
communicate using the specified protocols. The ZigBee functionality exposed to the external
application is described in the abstract along with a set of bindings to those functions and the semantics
of the bindings
1.2
8
9
The purpose of this document is to describe the operation of a ZGD to:

Provide exposure of ZigBee based functions of a ZigBee node or nodes to external IPHAs.
Scope
Purpose
10
11
Provide discovery and management mechanisms of components of a ZigBee PAN for the external
IPHAs;
12
Provide mechanisms that allow ZigBee nodes to communicate with external IPHAs

Page 1
Definitions
2.1
3
4
5
Expected
A key word used to describe the behavior of the hardware or software in the design
models assumed by this Draft. Other hardware and software design models may
also be implemented.
May
A key word that indicates flexibility of choice with no implied preference.
7
8
Shall
A key word indicating a mandatory requirement. Designers are required to

implement all such mandatory requirements.
9
10
Should
A key word indicating flexibility of choice with a strongly preferred alternative.

Equivalent to the phrase is recommended.
11
12
13
Reserved Codes
A set of codes for a reserved field that are defined in this specification, but not
otherwise used. Future specification may implement the use of these codes. A
product implementing this specification shall not generate these codes.
14
15
16
17
18
Reserved Field
A set of bits for a reserved field that are defined in the specification, but are not
otherwise used products that implement this specification shall zero these fields.
Products that implement future revisions of this specification may set these codes
as defined by the specification, but shall make no assumptions on the values of
these fields nor perform processing based upon their content.
19
2.2
20
21
22
For the purposes of this standard, the following terms and definitions apply.
NULL
A parameter or variable value that mean unspecified, undefined or unknown.
23
Octet
Eight bits of data, used as a synonym for a byte.
24
One-way function A function that is computationally much easier to perform than its inverse.
25
Protocol data unit The unit of data that is exchanged between two peer entities.
26
Function
An RPC command that exists either on a ZGD or an IPHA.
27
Procedure
An function on a ZGD.
28
Event Handler
A function on an IPHA.
29
Parameters
An input data set.
30
Results
An output data set.
31
Request
The initiating step of a function invocation that supplies the parameters.
32
Response
The concluding step of a function invocation that returns results.
33
Processing Task
The work that is performed to fulfill a function request.
34
35
Blocking
Describes a function that it does not return a response until its processing task
completes or its timeout is exceeded.
36
37
38
39
40
Non-blocking
Describes a procedure that it performs its processing task after returning a response
and performs the processing task in such a manner as to not inhibit subsequent
procedure invocations. When the processing task completes or its timeout is
exceeded, the results are supplied to the IPHA as per the CallbackDestination
parameter of the actuating procedure invocation.
Conformance Levels
Definitions
41
Page 2

2.3
Acronyms and Abbreviations
CCM*
Enhanced counter with CBC-MAC mode of operation
GMO
Gateway Management Object
GRIDE
Gateway Remote Interface Data Entity
GRIP
Gateway Remote Interface Protocol
IB
Information base
IP
Internet Protocol
IPHA
IP Host Application
MIC
Message integrity code
10
NAT
Network Address and port Translation
11
NHLE
Next Higher Layer Entity
12
PDU
Protocol data unit
13
RPC
Remote Procedure Call
14
SAP
Service access point
15
SCDE
Secured Connection Protocol Data Entity
16
SCIB
Secured Connection Protocol Information Base
17
SCME
Secured Connection Protocol Management Entity
18
SCoP
Secured Connection Protocol
19
SSL
SSL
20
TCP
Transmission Control Protocol
21
TLS
TLS
22
UDP
User Datagram Protocol
23
WPAN
Wireless personal area network
24
ZBD
ZigBee Bridge Device
25
ZGD
ZigBee Gateway Device
26

Page 3
References
2
3
4
5
6
7
The following standards and specifications contain provisions, which through reference in this
document constitute provisions of this specification. All the standards and specifications listed are
normative references. At the time of publication, the editions indicated were valid. All standards and
specifications are subject to revision, and parties to agreements based on this specification are
encouraged to investigate the possibility of applying the most recent editions of the standards and
specifications indicated below.
3.1
ZigBee Alliance documents
9
10
[r1] ZigBee document 053474r17, ZigBee specification release 17, ZigBee Technical Steering
Committee
11
12
[r2] ZigBee document 053820r18, ZigBee Bridge Device Specification, ZigBee Gateway Working
Group
13
14
[r3] ZigBee document 075329r08, ZigBee Gateway Device Specification, ZigBee Gateway Working
Group
15
[r4] ZigBee document 064699r12, ZigBee Commissioning Cluster, Application Framework Group
16
17
[r5] ZigBee document 075123r02, ZigBee Cluster Library Specification, Application Framework
Group
18
[r6] ZigBee document 095465r10, ZigBee Gateway White Paper, Understanding ZigBee Gateway
19
3.2
20
21
[r7] ISO 8824, 1998: Information Technology. Abstract Syntax Notation One (ASN.1): Specification
of Basic Notation. International Standard ITU-T Rec X680 | ISO/IEC 8824-1:1998.
22
23
24
[r8] ISO 8825, 1998: Information Technology. ASN.1 Encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
International Standard ITU-T X690 (1997) | ISO/IEC 8825-1:1998.
25
3.3
26
27
[r9] IEEE Standard for Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY)
specifications for Low Rate Wireless Personal Area Networks (LR-WPANs), 2003.
ISO Documents
IEEE Documents
28
29
3.4
30
[r10] IETF RFC 791, RFC 1122, RFC 1812: Internet Protocol and IPv4.
31
[r11] IETF RFC 793, RFC 1122: Transmission Control Protocol.
32
[r12] IETF RFC 792, RFC 1122: User Datagram Protocol.
33
[r13] IETF RFC 4346, Transport Layer Security (TLS) Protocol Version 1.0
34
[r14] IETF RFC 3489, Simple Traversal UDP for NAT.

Page 4
IETF Documents

[r15] IETF RFC 4787, Network, NAT Behavioral Requirements for Unicast UDP
[r16] IETF DRAFT r11, Behave, RFC 3489 bis, Session Traversal Utilities for NAT
[r17] IETF DRAFT r02, Behave, NAT Behavior Discovery using STUN
4
5
3.5
Other Normati ve Documents
6
7
8
[r18] ANSI X9.63-2001, Public Key Cryptography for the Financial Services Industry - Key
Agreement and Key Transport Using Elliptic Curve Cryptography, American Bankers
Association, November 20, 2001.

Page 5
4.1
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
55
ZigBee Gatew ay Device

General Description
A ZigBee gateway device provides a communication conduit into a ZigBee PAN or PANs using a
TCP/IP based host application (IPHA) and vice versa; a mechanism whereby external applications can
interact with individual ZigBee nodes to exert control over or to obtain data from those nodes or
conversely a mechanism whereby the nodes can communicate some information to the external
applications. The various visions of what a gateway should be ranged from, at one end, a machine that
provided binary encoded remote procedure calls to an API that exposed all of the Service Access
Procedures (SAPs), as defined by the ZigBee stack and IEEE 802.15.4 MAC layer specification, over a
UDP based transport layer, on the one hand, through to a fully featured engine that would provide a
graphically based representation of the PAN and allow the user to interact with all of the leaf nodes at
the device profile level through the use of an ordinary web browser, on the other hand. This document
represents a compromise between those two poles that attempts to retain the best of each representation
without suffering either the complexities or the limitations of either of them.
The consumer market segment requires that implementers build inexpensive ZGDs, therefore the ZGD
specification will ensure that the minimum required set of features and their computation complexity
(CPU cycles/memory usage) is appropriate while providing compelling functionality for most
home/consumer applications. A minimal ZGD implementation trades unit cost for increased
implementation complexity of Host Applications.
In contrast, commercial, industrial, and enterprise applications may require implementers to build
feature rich ZGDs that can be accessed using protocols typical of those environments. Therefore the
ZGD specification ensures that the optional set of features and functions provides a set of compelling
functionality that is not necessarily restricted by computional complexity. A feature rich ZGD
implementation may reduce the implementation complexity of Host Applications and will allow
operational modes not possible in a minimal implementation.
In order to meet these criteria and the diverse requirements contemplated by the members of the group
and the alliance, in general, a set of common features based on the core functionality of the ZigBee
stack and the requirement of exposing the ZigBee Cluster Library (ZCL) functionality was defined.
This set represents a minimal gateway instantiation and includes:
ZCL operations to read and write attributes, and configure and report events;
ZDO and macro operations for network and service discovery;
Endpoint management;
Access to a ZGD's AIB, NIB, and PIB attributes;
Flexible start-up and network join operations;
Ability to control ZigBee security material and operation;
Bi-directional communication mechanisms between a ZGD and IPHA;
Within a ZGD these operations and functions form a nearly identical mapping to the underlying ZigBee
SAPs and as such a ZGD acts a medium through which API calls are performed. A number of
exceptions exist to this design in the form of so called macro functions that comprise aggregates of
specific stack functions. These include, specifically, the network and service discovery functions. This
type of aggregation, for example, allows the host applications to discover all of the members of a PAN
with a single request without having to bother with the underlying details of traversing the entire PAN.
A number of methods are contemplated in order to meet the varying communication needs of the
functions comprising the core ZGD. ZGDs and IPHAs will communicate with each other by invoking
remote functions on each other; in essence both ZGD and IPHA will act as clients and servers,
simultaneously. Each interaction follows the standard request response format with an optional
timeout parameter. Through this methodology each, ZGD or IPHA, will be able to send messages to
their counterparts whenever required. An additional communications method, in the form of a call back
handler, has been included to allow gateways to handle messages that originate from within the ZigBee
Page 6

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
PAN that need to be forwarded to the IPHA. These callback handlers provide flexibility to handle a
broad range of situations however their canonical use is to forward messages of interest to an IPHA.
33
4. 1. 1
34
35
36
37
38
39
40
41
42
43
44
The traffic pattern of a ZigBee network containing one or more ZGDs depend on the IPHAs connected
to them. Therefore IPHAs should take care of adhering to the guidelines specified by [R1] for the role
they are covering.
In the common case an IPHA performs data collection, then it will make the ZGD behave as a
concentrator. As such, all the rules specified in section 3.6.3.5 of [R1] should be applied; in particular,
either the IPHA (through the PerformRouteDiscovery procedure), or the ZGD (through some
configuration, if supported by the implementation) should advertise the presence of a concentrator by
sending periodical (typically one at a minute) MTORR frames.
This should be done by setting DstAddrMode parameter to zero, DstAddr parameter to 0xfffc. Radius
should be set to a reasonable value that depends on the size of the network and the presence of other
concentrators, and NoRouteCache to the amount of RAM of the ZGD w.r.t. the size of the network.
45
4. 1. 2
46
47
The ZGD must support both ZigBee and IP protocols and functionality, to that end it must be
compatible with both domains.
48
4. 1. 2 .1 ZigB e e
49
50
A ZigBee gateway will be compatible with the version of the ZigBee stack that it was designed to
service.
The presentation of the functionality of a gateway and the attendant ZigBee network to the TCP/IP
based application is embodied in three variants. These include two web services presentation bindings,
based respectively on SOAP (Simple Object Access Protocol) and REST (Representational State
Transfer), both widely adopted methodologies for presenting structured data to a host or client
application using XML based documents. The third presentation binding, the Gateway Remote
Interface Protocol (GRIP) rides on top of an extension of the ZIPT protocol devised by this group for
ZigBee bridge devices that allows for informationally dense binary messages to be exchanged over
potential secure UDP channels using an ASN.1 encoding scheme (the excursion from the standard
IETF protocols was dictated by the fact that no secure purely UDP based protocol existed).
The breadth of the presentation bindings provides developers of ZigBee gateways and the agencies that
will support and interface to ZigBee gateways with options regarding development ease, infrastructure
cost, network capacity , message latency etc. thereby providing them with the ability to optimize their
costs. The heavier web services based bindings provide relatively quick development paths at the
expense of heavier infrastructure costs in contrast to the binary ZIPT presentation which will require
higher development costs but offer potentially lower infrastructure and network costs.
A ZGD allows profile specific logic to be externalized to an IPHA by providing a set of profile neutral
operations and capabilities. The expectation is that IPHAs may be certified compliant, as required, with
a particular standard profile. Likewise vendor value-add profile specific functionality on the ZGD
requires certification and testing like any other device.
To address diverse applications in an efficient manner, a compliant gateway doesnt need to implement
all the RPC bindings; it is enough to implement only one of them, or possibly more than one, if desired.
Application specific gateways that build on the general ZigBee gateway specification can indicate
which binding must be implemented, depending on the specific use case and/or the typical scenario.
This way , a profile could mandate one of the bindings for specific use cases or just leave free the
vendor to decide which binding to implement (or define a fourth binding not described in the
specification).
ZigB e e B ehav io r
Comp at ibi lit y

Page 7
4. 1. 2 .2 Com mi si oni ng Clu st e r
A ZGD shall support the ZigBee Commissioing Cluster, as defined in [R4].
4. 1. 2 .3 IP
4
5
The specification is silent with respect to the details of the IP stack that gateway vendors might use;
hence a gateway will be compatible with IPv4 and potentially IPv6 but not necessarily both.
4. 1. 3
7
8
9
At the level of the application the following figure shows conceptually how a ZigBee IP gateway could
be used in an IPHA driven application.
Ar c h it e ct u r e
Host Application
RPC
Server/Client
IP Network
RPC
Server/Client
ZigBee Stack
ZigBee
Gateway
IP Host
Application
ZigBee End
Node
10
11
Figure 1: Generic ZigBee Gateway Deployment
12
13
14
15
16
17
18
19
20
21
22
23
24
25
ZigBee Stack
Through the various presentation bindings (GRIP, SOAP or REST) the IPHA or the Gateway
communicate with each other through the execution of remote procedure calls (RPC) across the IP
network. The message exchanges are for the most part of the request-response format, with either
device being capable of generating the request and receiving the responses. The request directed to the
gateway from the IPHA can be commands that are executed specifically on the gateway itself or are
forwarded to the addressed ZigBee end node through the gateways radio interface for execution on the
remote node. Conversely, requests directed by the gateway to the IPHA would be serviced by the IPHA
as would messages originating at the end nodes that are redirected by the gateway through its callback
capability and being forwarded to the IPHA.
The following figure provides a conceptual view of the gateway architecture:
Page 8

SOAP
APS
REST
ZDO
ZCL
GRIP
COMM
GMO
Discovery mgmt
Call-back mgmt
GIB
ZigBee Stack
ZigBee Gateway
Generic Gateway
Figure 2: Conceptual Gateway Architecture
3
4
5
6
7
8
9
With the presentation binding represented at the top of the figure providing the interfaces to the IP
Network. Below that the Gateway application provides interfaces to Application (APS), ZigBee Device
Object (ZDO), ZigBee Cluster Library (ZCL) and other Communication (COMM) layers, such as the
Network and MAC layers, as well as the Gateway Management Object (GMO). All of these layers
provide access to the ZigBee stack resident on the gateway and exercise functions of the stack.

Page 9
5.1
Communication
General Description
3
4
5
6
7
8
9
10
11
12
13
14
15
16
ZGDs and IPHAs communicate by invoking remote functions on each other. A procedure is a ZGD
function that is invoked by an IPHA, while an event handler is an IPHA function that is invoked by a
ZGD. Functions are invoked with a request and conclude when a response is returned. The work
performed by a function is called its processing task.
17
5.2
18
19
20
21
22
Functions are RPC commands that exist either on a ZGD or an IPHA. They are invoked with a request,
passed zero or more parameters, and conclude when a response returns one or more results.
Procedures that support CallbackDestination can operate in either a blocking or a non-blocking mode.
Non-blocking mode allows an IPHA to make additional procedure invocations while the potentially
lengthy processing tasks of previous procedure invocations are performed simultaneously. In contrast
all event handlers, and procedures that do not support CallbackDestination only operate in a blocking
mode.
Since a ZGD may implement one of several RPC bindings, functions are described in a protocolneutral manner. The bindings define function instantiations within the context of specific transport and
RPC protocols. A ZGD shall implement at least one RPC binding.
Functions
A ZGD function is termed a procedure and is invoked by an IPHA, as illustrated in Figure 3 (a). An
IPHA function is termed an event handler and is invoked by a ZGD, as illustrated in Figure 3 (b).
ZGD
IPHA
Request(parameters...)
Response(results...)
(a)
Request(parameters...)
(b)
Response(results...)
23
24
25
26
27
28
29
30
Figure 3: Procedure and Event Handler Function Invocations
5. 2. 1 Req ue st Id ent if i er
RequestIdentifier links the results from completed processing tasks to their actuating non-blocking
procedure invocations. RequestIdentifier shall be a string, minimally 4 octets in length with an
implementation defined maximum, and shall be generated using an algorithm that guarantees its
uniqueness within a ZGD. The ZGD shall ensure that no duplicate request identifiers are used
simultaneously and it should minimize the reuse of request identifiers.
Page 10

1
2
3
4
5
6
7
5. 2. 2 Ca llb a ck D est in at i on
CallbackDestination allows an IPHA to invoke a procedure in non-blocking mode.
CallbackDestination is an octet string that shall represent either the Internet URL of the IPHA hosting
the event handler to be invoked when returning the processing task results or, optionally, an empty
string if the IPHA will poll for the processing task results using the PollResults procedure. It is
recommended that processing task results not polled by an IPHA be discarded after a configurable
amount of time.
5. 2. 3 T imeout
9
10
The Timeout parameter shall be a 32-bit unsigned integer measured in milliseconds where the value of
0xffffffff shall indicate an infinite amount of time.
11
12
When not used in conjunction with CallbackDestination, Timeout shall limit the maximum duration
that a procedure operates in a blocking mode before returning a response.
13
14
15
16
When used in conjunction with CallbackDestination, Timeout shall limit the maximum duration of the
processing task of a non-blocking procedure invocation. In the case when a timeout occurs, the ZGD
shall ensure that its internal state is valid before the results are supplied to the IPHA as per the
CallbackDestination parameter of the actuating procedure invocation.
17
18
19
5. 2. 4 St at u s
Status shall be an 8-bit unsigned integer where any non-zero value indicates that the function did not
successfully complete. Table 2 Status Codes indicates the valid values of the Status result.

Page 11
Table 2 Status Codes

Name
Value
Description
0x00
Indicates that a function successfully

completed.
TIMEOUT
0x01
Indicates that the amount of time to

complete the processing task was
longer than the amount of time
limited by the Timeout parameter
GENERAL ERROR
0x02
Indicates that a general error

occurred and the function did not
complete successfully.
PARAMETER_MISSING
0x03
Indicates that one or more required

parameters were missing from the
request.
PARAMETER_INVALID_VALUE
0x04
Indicates that one or more supplied

parameters had an invalid value.
NETWORK_NOT_READY
0x05
Indicates that the ZigBee interface is

not in a state to process the request.
EMPTY
0x06
Indicates that there are no results to

be retrieved.
NOT_ALLOWED
0x07
Indicates that the action requested by

the function is not allowed
MEMORY_ERROR
0x08
Indicates that the function has not

been successfully completed dur to a
memory error
APS_FAILURE
0x09
Indicates a specific APS error
NETWORK_FAILURE
0x0A
Indicates a network error, and the

optional NwkStatus will report the
specific network error code.
SUCCESS
5.3
Callback Handlers
3
4
5
6
7
8
Callback handlers are ZGD entities that allow ZigBee frames received by the ZGD to be collected,
decoded, and subsequently supplied as results to an IPHA.
A ZGD shall support at least one callback handler, while the maximum number shall be
implementation defined. It is recommended that ZGDs maintain callback handlers through power
cycles, resets, and temporary communication failures.
Page 12

6.1
3
4
5
The set of ZGD functions are organized into the following categories: Gateway Management Object,
ZigBee Device Profile, ZigBee Cluster Library, Application Support Sub-Layer, Inter-PAN, and
Network Layer.
6
7
8
A table at the beginning of each category section lists the functions and their implementation status.
An implementation status of M indicates that a ZGD shall implement the function. An implementation
status of O indicates that a ZGD may optionally implement the function.
9
10
11
12
13
14
15
Each function sub-clause describes its parameters and results in table format. Within each table
individual parameters and results are either marked with a Status of M or O. A parameter with a status
of M shall be passed in every function invocation. A result with a status of M shall be returned by
every function invocation. A parameter with a Status of O indicates that it may be omitted in a
function invocation and that a default value or behavior is requested. A result with a Status of O
indicates that under certain conditions it will not be supplied as specified by the functions Effect on
Invocation sub-clause.
16
6.2
17
18
Functions have common behaviors when invoked. Sub-clause 6.2.1 and 6.2.2 describe the common
behaviors of procedures and event handlers respectively.
19
Functions
General Description
Common Function Behavior
6. 2. 1 Ef f ec t o n I nv oc at ion of a ZG D P ro c edu r e
20
21
22
23
24
Upon invocation of a procedure, a ZGD shall ignore supplied parameters that are neither mandatory
nor optional. Next a ZGD shall validate that all mandatory parameters are supplied. If one or more
mandatory parameters are not supplied then it shall return a Status result of PARAMETER_MISSING.
Next the ZGD shall validate that all supplied parameters have a valid value. If one or more parameters
have an invalid value then it shall return a Status result of PARAMETER_INVALID_VALUE.
25
26
27
28
If the CallbackDestination parameter is not supplied in a request then the procedure shall operate in a
blocking mode. The ZGD shall then behave as specified for each procedure in the "Effect on
Invocation" sub-clause and it shall return a Status of TIMEOUT if the total time of the processing task
exceeds Timeout milliseconds and in no case shall it return a RequestIdentifier result.
29
30
31
32
33
34
35
If the CallbackDestination parameter is supplied and equals to an empty string, then the procedure
shall operate in a nonblocking mode. The processing task, as specified in the "Effect on Invocation"
sub-clause, shall be performed after the procedure returns a response containing only a Status of
SUCCESS and a newly generated RequestIdentifier. The IPHA will need to poll for the processing task
results using the PollResults procedure. Later, when the processing task task completes or the total time
of the processing task exceeds Timeout milliseconds, the results, including the RequestIdentifier used
for processing task shall be freed.
36
37
38
39
40
41
42
43
If the CallbackDestination parameter is supplied and not equals to an empty string then the procedure
shall operate in a non-blocking mode. The processing task, as specified in the "Effect on Invocation"
sub-clause, shall be performed after the procedure returns a response containing only a Status of
SUCCESS and a newly generated RequestIdentifier. Later, when the processing task completes or the
total time of the processing task exceeds Timeout milliseconds, the results, including the
RequestIdentifier, shall be supplied to the IPHA as per the CallbackDestination parameter supplied in
the actuating procedure invocation Finally, the RequestIdentifier used for the processing task shall be
freed.
Page 13
1
2
In any case, if the Status result is not SUCCESS then the optional processing task results, excluding
RequestIdentifier for a non-blocking procedure invocation, shall not be supplied to the IPHA.
6. 2. 2 Eff ec t o n I nv oc at ion of an I PH A E v e nt Ha n dle r
4
5
6
7
8
9
Upon invocation of an event handler, an IPHA shall ignore supplied parameters that are neither
mandatory nor optional. Next an IPHA shall validate that all mandatory parameters are present. If one
or more mandatory parameters are not present then it shall return a Status of
PARAMETER_MISSING. Next the IPHA shall validate that all supplied parameters have a valid
value. If one or more parameters have an invalid value then it shall return a Status of
PARAMETER_INVALID_VALUE.
10
11
The IPHA shall then behave as specified for each event handler in the "Effect on Invocation" subclause.
12
6.3
13
14
15
16
The 16-bit network address of a ZigBee node may change and pose potentially perturbing problems for
IPHAs using the address as a reliable means of transmitting and receiving communications.
Alternatively, an IPHA may utilize the EUI-64 of a ZigBee node instead of its 16-bit network address
to ensure reliable communication.
17
18
19
20
21
22
23
24
25
A ZGD may additionally support an alias addressing scheme. In this scheme the IPHA can assign an
arbitrary octet string, the alias, to a specific device EUI-64. The ZGD shall be responsible for
maintaining the up-to-date mapping of the 16-bit network to alias address based on the EUI-64. The
logic for maintaining the mapping is implementation specific. It is recommended that a ZGD maintain
alias address configuration through power cycles, resets, and temporary communication failures.
26
6.4
27
28
29
The Gateway Management Object provides the facilities to automatically invoke event handlers based
on received ZigBee frames, get and set GIB, AIB, NIB, and PIB attributes, determine ZGD functional
capabilities, and perform bulk device and service discovery.
30
Table 3 GMO Functions
Al ias Addressing
DestinationAddressMode shall conform to the referenced sub-clauses in [R1] and shall be extended
with the value 0x10 = AliasAddress. The behavior of AliasAddress shall be the same as 0x03 with the
exception that an arbitrary octet string is used in substitution of a 64-bit extended address.
Gatew ay Management Object (GMO)
Function
Implementation Status
GetVersion
Get
Set
CreateCallback
DeleteCallback
ListCallbacks
PollCallback
PollResults
M
O
M
M
M
O
O
UpdateTimeout
StartNodeDiscovery
NodeDiscoveryEvent
NodeLeaveEvent
ReadNodeCache
StartServiceDiscovery
O
O
O
O
O
Page 14
Description
Returns ZGD version and feature set
information.
Allows getting and setting of information base
attributes.
Callback handler creation and management
functions.
Allows an IPHA to poll for non-blocking
procedure results or update a timeout for a nonblocking procedures processing task.
Bulk device discovery functions.
Bulk service discovery functions.

ServiceDiscoveryEvent
GetServiceDescriptor
ReadServiceCache
StartGatewayDevice
StartGatewayDeviceEvent
ConfigureStartupAttributeSet
ReadStartupAttributeSet
CreateAliasAddress
DeleteAliasAddress
ListAddresses
O
O
O
O
M
M
O
O
O
O
M
Functions that encapsulate and simplify the

multi-step network formation or joining
sequence that normally require multiple granular
function invocations.
Address management functions.

Page 15
1
2
6. 4. 1 G et V er si on P ro c edu r e
The GetVersion procedure has no parameters and returns the results in Table 4.
Table 4 GMO GetVersion Procedure Results

Name
Status
Type
Valid
Range
Status
VersionIdentifier
8-bit Integer
0x01
FeatureSetIdentifier
8-bit Integer
0x00 0xff
RPCProtocols
16-bit Bitmask
ManufacturerVersion
String
Description
(see sub-clause 5.2.4)
The ZGD Specification version identifier.
This specifications version is 0x01.
0x00 - Basic Feature Set - All mandatory
functions and features are implemented
per the particular ZGD specification
version in the RPC binding used to
invoke this procedure; some optional
functions and features may be
implemented
0x01 Full Feature Set All functions
and features are implemented per the
particular ZGD specification version in
the RPC binding used to invoke this
procedure
0x02 - 0xff Reserved
Indicates the RPC protocols supported by
the ZGD.
0x0001: GRIP
0x0002: SOAP
0x0004: REST
0xFFF8: Reserved, must be set 0.
A manufacturer specific version string.
6. 4. 1 .1 W hen Inv o k ed
The GetVersion procedure is invoked by an IPHA that wants to determine the capabilities of a ZGD.
6. 4. 1 .2 Eff ec t o n I nv oc at ion
7
8
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
return Status of SUCCESS, its VersionIdentifier, FeatureSetIdentifier, and ManufacturerVersion.
Page 16

1
2
6. 4. 2 G et P ro c edu r e
The Get procedure shall support the parameters in Table 5 and the results in Table 6.
Table 5 GMO Get Procedure Parameters

Name
AttributeId
Status
Default
Type
Valid
Range
Description
The attributes ID and type of the
attributes value shall be as defined in
[R1] sub-clause APS Information Base
or NWK Information Base or [R7] subclause PHY PIB attributes. A binding
declares the mapping for the abstract
types to RPC specific ones.
Table 6 GMO Get Procedure Results

Name
Status
Value
Status
Type
Valid
Range
Description

[R1] sub-clause APS Information Base or
NWK Information Base or [R7] subclause PHY PIB attributes. A binding
The Get procedure allows an IPHA to read information base attributes.
6. 4. 2 .2 Ef f ec t o n I nv oc at ion
8
9
10
return a Status of SUCCESS and the Value.of the requested information base AttributeId.

Page 17
1
2
6. 4. 3 S et P ro ce du re
The Set procedure shall support the parameters in Table 7 and the results in Table 8.
Table 7 GMO Set Procedure Parameters

Name
Status
AttributeId
Value
Default
Type
Valid
Range
Description
[R1] sub-clause APS Information Base
or NWK Information Base or [R7] subclause PHY PIB attributes. A binding
Table 8 GMO Set Procedure Results

Name
Status
Status
M
Type
Valid
Range
Description
The Set procedure allows an IPHA to write information base attributes.
8
9
10
write the information base AttributeId with the requested Value and then return a Status of SUCCESS.
Page 18

1
2
6. 4. 4 Cr e at e C al lb ac k P ro c edu r e
The CreateCallback procedure shall support the parameters Table 9 in and the results in Table 10.
Table 9 GMO CreateCallback Procedure Parameters

Name
Status
Filter
Action
Default
Type
Valid
Range
O
O
Description
(see sub-clause 6.4.4.1)
(see sub-clause 6.4.4.2)
Table 10 GMO CreateCallback Procedure Results

Name
Status
Status
CallbackIdentifier
Type
Valid
Range
Description
Unsigned 32-bit
integer
0-0xffffffff
A unique number used to reference and

manage the callback handler.
6. 4. 4 .1 Filt e r P a ra me t e r
6
7
The Filter parameter allows a callback handler to selectively match and subsequently retain frames
received from the ZigBee network as undecoded results.
8
9
10
11
12
13
14
15
If the Filter parameter is not supplied then the default behavior shall be that all ZigBee frames received
by the ZGD at its APSDE-DATA.indication SAP shall be retained as results. When the Filter
parameter is supplied the it shall be composed of the LevelSpecification, AddressSpecification, and
MessageSpecification abstract elements described in Table 11, Table 12, and Table 13. A received
ZigBee frame shall be retained results by the callback handler if all filter address and message
specification element sub-clauses evaluate to TRUE else it shall not be retained. Retained results are
eventually decoded according to the DecodeSpecification of the Action parameter as per sub-clause
6.4.4.2.1.
16
17
LevelSpecification and AddressSpecification elements marked as optional may be implemented by a

ZGD and those marked as mandatory shall be implemented by a ZGD.
18
Table 11 LevelSpecification Element

Level
Status
MACLevel
NWKLevel
INTRPLevel
APSLevel
19
Description
Valid frames received at the MCPS-DATA.indication SAP shall be retained
as undecoded results.
Valid frames received at the NLDE-DATA.indication SAP shall be
evaluated against the NWKSourceAddress AddressSpecification element.
Valid frames received at the INTRP-DATA.indication SAP shall be
evaluated against all AddressSpecification and MessageSpecification
elements.
Valid frames received at the APSDE-DATA.indication SAP shall be
evaluated against all AddressSpecification and MessageSpecification
elements.
Table 12 - AddressSpecification Elements

Name
Status
Type
Valid
Range
Description

Page 19
The NWK source address field of a

valid NWK frame.
If NWKSourceAddress is not supplied in
an AddressSpecification then all frames
shall cause the filter sub-clause to
evaluate to TRUE.
NWKSourceAddress
If NWKSourceAddress is either an
extended address or an alias address
then the ZGD shall resolve the 16-bit
short address from its address manager
table at the time of comparing a ZigBee
frame to the filter criteria. If the
address cannot be resolved then the
filter sub-clause shall evaluate to
FALSE.
16-bit Network
Address or
ExtendedAddress
or AliasAddress
Finally, frames that match

NWKSourceAddress shall cause the
filter sub-clause to evaluate to TRUE
otherwise it shall evaluate to FALSE.
The APS source endpoint field of a
valid APS frame.
APSSourceEndpoint
If APSSourceEndpoint is not supplied in

an AddressSpecification then the filter
sub-clause shall evaluate to TRUE.
Finally, frames from

APSSourceEndpoint shall cause the
filter sub-clause to evaluate to TRUE,
The APS destination endpoint field of a
valid APS frame.
APSDestinationEndpoint
If APSDestinationEndpoint is not
supplied in an AddressSpecification
then the filter sub-clause shall evaluate
to TRUE.
Finally, frames sent to

APSDestinationEndpoint shall cause the
filter sub-clause to evaluate to TRUE,
Table 13 - MessageSpecification Elements

Name
Status
Type
Valid
Range
Description
The APS cluster identifier field of a valid
APS frame.
APSClusterIdentifier
If the frame is not a valid APS frame then

the filter sub-clause shall evaluate to
FALSE.
Finally, frames sent to
APSClusterIdentifier shall cause the filter
sub-clause to evaluate to TRUE,
Page 20

A logical set of APSClusterIdentifiers

organized as shown in Figure 4.
APSClusterGroup
If APSClusterGroup is not supplied in a

MessageSpecification then the filter subclause shall evaluate to TRUE.
Finally, frames sent to any cluster
indentifer in APSClusterGroup or below
in the hierarcy tree shall cause the filter
sub-clause to evaluate to TRUE,

Page 21
Figure 4: ClusterGroup Logical Identifier Hierarcy
6. 4. 4 .1 .1 Filt e r S ynt a x
The abstract filter elements shall be organized into a valid Filter syntax:
Filter ::= <LevelSpecification> <AddressingSpecification> * [<MessageSpecification>]*
<AddressingSpecification> ::= [<SourceAddress>] [<SourceEndpoint>] [<DestinationEndpoint>]
<MessageSpecification> = <ClusterIdentifier> + | <ClusterGroup>
7
8
9
10
A star (*) indicates that zero or more of the preceeding element may be specified. A plus sign (+)
indicates that one or more of the preceeding element may be specified. A pipe (|) indicates that
only one of either the preceeding element or the next element may be specified. Square brackets ([
]) indicate optional elements and angled brackets (< >) are used to indicate mandatory elements.
11
6. 4. 4 .2 Ac t ion Pa r am et er
12
13
Action consists of the DecodeSpecification and the ForwardingSpecification abstract elements in Table
14 and Table 15.
14
6. 4. 4 .2 .1 De cod e Sp e cif ic at ion
15
16
17
18
19
20
21
22
23
24
The DecodeSpecification is a 32-bit Bitmask used by the ZGD to determine how ZigBee frames will be
decoded when the Action is applied. At least one decode bit shall be set in the DecodeSpecification.
When multiple bits are set then the ZGD shall decode the ZigBee frame to the most specific level
possible according to the following rules applied in sequence: If the DecodeZDPBit is set and the
ZigBee frame is a valid APS frame containing source and destination endpoints that are both zero then
it shall be decoded as a NotifyZDPEvent. If the DecodeZCLBit is set and the ZigBee frame is a valid
APS frame and the APS payload length is greater than or equal to the minimum size of the ZCL Header
(3 octets) then it shall be decoded as a NotifyZCLEvent. If the DecodeAPSBit is set and the ZigBee
frame is a valid APS frame then it shall be decoded as a NotifyAPSEvent. If a ZigBee frame cannot be
decoded to the one of the requested levels in the DecodeSpecification then it shall be discarded.
25
26
DecodeSpecification elements marked as optional may be supported by a ZGD and those marked as
mandatory shall be supported by a ZGD.
27
Table 14 DecodeSpecification Element

Name
Status
Description
DecodeMACBit
Reserved.
DecodeNWKBit
Reserved.
DecodeInterPANBit
DecodeAPSBit
DecodeZCLBit
DecodeZDPBit
Page 22
Results shall be decoded as NotifyInterPANMessageEvent

parameters
Frames shall be decoded as NotifyAPSMessageEvent
parameters
Frames shall be decoded as NotifyZCLEvent parameters or
SendZCLCommand results.
Frames shall be decoded as NotifyZDPEvent parameters or
SendZDPCommand results.

6. 4. 4 .2 .2 Forw a rd ing Sp e cif ic at ion
2
3
4
5
6
7
8
The ForwardingSpecification element behaves the same as the callback destination field in the
nonblocking implementation. It specifies the IPHA by which a callback handler will return received
ZigBee frames to an IPHA. If an empty string was defined, the messages are expected to be stored in
the ZGD with the corresponding callback ID. The IPHA retrieves the message using the PollCallback
Procedure. The forwarding method is implicitly defined upon the callback creation. For example, if the
callback is created using SOAP , then the SOAP protocol will be used to forward the response back to
IPHA .
9
10
A ZGD shall support at least one of GRIP, SOAP, or REST methods for its ForwardingSpecification
element. A ZGD may optionally support additional ForwardingSpecification methods.
11
Table 15 ForwardingSpecification Element

RPC
Status
Description
POLLED
The IPHA will use PollCallback procedure to retrive retained ZigBee frames.
GRIP
Forward ZigBee frames by invoking an IPHA event handler via GRIP.
SOAP
Forward ZigBee frames by invoking an IPHA event handler via SOAP.
REST
Forward ZigBee frames by invoking an IPHA event handler via REST.
12
6. 4. 4 .2 .3 Ac t ion S ynt a x
13
The abstract action elements shall be organized into a valid Action syntax:
14
Action ::= <DecodeSpecification> <ForwardingSpecification>
15
Action is composed of a single DecodeSpecification and a single ForwardingSpecification.
16
17
The CreateCallback procedure is invoked by an IPHA to create a callback handler.
18
19
20
21
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next if the ZGD is
unable to create a callback then a Status of GENERAL_ERROR is returned. Otherwise, a Status of
SUCCESS is returned along with a CallbackIdentifier.
22
23
6. 4. 5 Po ll Ca ll ba c k p ro c edu re
The PollCallback procedure shall support the parameters in Table 16 and the results in Table 17.
24
Table 16 GMO PollCallback Procedure Parameters

Name
Status
CallbackIden
tifier
Default
Type
Valid
Range
Unsigned 32-bit
integer
0-0xffffffff
Description

Page 23
Table 17 GMO PollCallback Procedure Results

Name
Status
Status
Valid
Range
Type
AppliedDecodeSpecification
SendZDPCommandResults
SendZCLCommandResults
SendAPSCommandResults
SendInterPANCommandResults
Description
Indicates how the message is
decoded. Only the bit for the applied
decode level (see Table 14) shall be
set.
One or more results of the
SendZDPCommand procedure. (see
sub-clause 6.5.5.2 )
SendZCLCommand procedure. (see
sub-clause 6.5.5.2 )
One or more parameters of the
NotifyAPSMessageEvent event
handler. (see sub-clause 6.5.5.2)
NotifyInterPANMessageEvent event
handler. (see sub-clause 6.5.5.2)
32-bit Bitmask
3
4
The PollCallback procedure is invoked by an IPHA to read retained messages from a particular
callback handler.
6
7
8
9
10
11
12
13
return a Status of EMPTY if no messages are being retained. Otherwise the ZGD shall decode the
message according to the DecodeSpecification, set AppliedDecodeSpecification, and return one of the
following
procedure
result
sets:
SendZDPCommandResults,
SendZCLCommandResults,
SendAPSCommandResults, or SendNWKMessageResults. The value of the Status result shall indicate
the status of the decoded message and it shall not indicate the status of the PollCallback procedure.
6. 4. 6 De let e Ca ll ba c k p ro c e dur e
The DeleteCallback procedure shall support the parameters in Table 18 and the results in Table 19.
14
Table 18 GMO DeleteCallback Procedure Parameters

Name
Status
CallbackIden
tifier
15
Default
Type
Valid
Range
Unsigned 32-bit
integer
0-0xffffffff
Description
Table 19 GMO DeleteCallback Procedure Results

Name
Status
Status
M
Type
Valid
Range
Description
16
17
The DeleteCallback procedure is invoked by an IPHA to create a callback handler.
Page 24

2
3
4
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the callback
handler indicated by CallbackIdentifier shall be immediately removed and a Status of SUCCESS
returned.
5
6
6. 4. 7 Lis t C al lb ac k s p ro c ed ur e
The ListCallbacks procedure has no parameters and returns the results in Table 20.
Table 20 GMO ListCallbacks Procedure Results
7
Name
Status
Status
Valid
Range
Type
Description
0x000xffffffff
NumberOfCallbacks
Integer
CallbackList
Array of
CallbackIdentifiers
The total number of active callbacks.

List of configured CallbackIdentifiers.
The ListCallbacks procedure is invoked by an IPHA to get a list of configured callback handlers.
10
11
12
return a Status of SUCCESS and an array of configured callback handler identifiers.
13
14
6. 4. 8 Po ll Re su lt s p ro c edu r e
The PollResults procedure shall support the parameters in Table 21 and the results in Table 22.
Table 21 GMO PollResults Procedure Parameters
15
Name
Status
RequestIdent
ifier
Default
Type
Valid
Range
Description
Table 22 GMO PollResults Procedure Results
16
Name
Status
Type
Valid
Range
Description
Results
The processing task results,

including Status and
RequestIdentifer, from the
actuating procedure invocation.
SendZDPCommandResults

SendZDPCommand procedure.
SendZCLCommandResults

SendZCLCommand procedure.

Page 25
SendAPSCommandResults
SendInterPANCommandResults

NotifyAPSMessageEvent event
handler.
NotifyInterPANMessageEvent
event handler.
2
3
The PollResults procedure is invoked by an IPHA to read retained results from a particular nonblocking procedure invocation.
5
6
7
8
9
10
11
12
only return a Status of PROCESSING if processing task results for the RequestIdeintifer are not ready.
Next the ZGD shall only return a Status of EMPTY if there are no processing task results matching the
supplied RequestIdentifer. Otherwise the value of the Status result shall indicate the status of the
processing task and the remaining processing task results are returned as specificed by the Effect on
Invocation sub-clause of the actuating procedure invocation.
6. 4. 9 Upd at eT i me out pr oc e dur e

The UpdateTimeout procedure shall support the parameters in Table 23 and the results in Table 24.
Table 23 GMO UpdateTimeout Procedure Parameters
13
Name
Request
Identifier
Timeout
Status
Default
Type
Valid
Range
Description
Table 24 GMO UpdateTimeout Procedure Results
14
Name
Status
Status
M
Type
Valid
Range
Description
15
16
17
The UpdateTimeout procedure is invoked by an IPHA to change the timeout of a non-blocking

procedure invocations processing task.
18
19
20
21
22
23
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next a ZGD shall
validate that the RequestIdentifier parameter is associated with an processing task that has not
completed. If it has not completed then a Status of PARAMETER_INVALID_VALUE shall be
returned. Otherwise the timeout shall be updated to the value of the Timeout parameter and a Status of
SUCCESS shall be returned.
Page 26

6. 4. 1 0 St ar t No de Di s cov e r y P ro ce du re
2
3
The StartNodeDiscovery procedure shall support the parameters specified in Table 25 and the results
specified in Table 26.
Table 25: StartNodeDiscovery Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
CallbackDestination
ReportOnExistingNodes
Boolean
TRUE or
FALSE
ReportAnnouncements
Boolean
TRUE or
FALSE
ReportLeave
Boolean
TRUE or
FALSE
When TRUE the ZGD shall invoke the

NodeDiscoveryEvent event handler to
report on every existing node in the
network.
When FALSE the ZGD shall only
invoke the NodeDiscoveryEvent event
handler when new nodes join the
network.
If TRUE, the ZGD shall start reporting
to the IPHA all the annce messages
coming from devices joining the
network.
If TRUE, the ZGD shall start reporting
to the IPHA whenever a node leaves the
network, generating a
NODE_LEAVE_EVENT.
5
6
Table 26: StartNodeDiscovery Procedure Results

Name
Status
Type
Valid Range
Description
Status
RequestIdentifier
7
8
6. 4. 1 0. 1
W hen Inv o k ed
9
10
The StartNodeDiscovery procedure is invoked by an IPHA to report all the devices present in the
network.
11
6. 4. 1 0. 2
12
13
14
15
16
17
18
19
20
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next this message
starts a transaction, and the ZGD issues a NODE_DISCOVERY_EVENT Event for each discovered
node. Depending on the value of the ReportOnExistingNodes and ReportAnnouncements parameters,
the ZGD may actually start a discovery operation or report announce messages from devices joining
the network.
The ReportLeave parameter, if specified, requires the ZGD to generate
NODE_LEAVE_EVENT events when a node leaves the network. However, if the ZGD is not
behaving as Trust Center, it may not be able to detect when a node is leaving the network, since it
requires the reception of an APSME-UPDATE-DEVICE indication. If so, the ZGD shall report a
failure, setting the Status result to the PARAMETER_INVALID_VALUE code.
Ef f ec t o n I nv oc at ion

Page 27
6. 4. 1 1 Nod eD is cov er yE v e nt Ev e nt Ha ndl e r
2
3
The NodeDiscoveryEvent event handler shall support the parameters specified in Table 27, and shall
support the results specified in Table 28.
Table 27: NodeDiscoveryEvent Event Handler Parameters

Name
Status
Type
Valid Range
Description
RequestIdentifer
ShortAddress
16-bit Device
Address
ZigBee NWK
Address
The network address of the device
ExtendedAddress
64-bit Device
Address
IEEE Address
The IEEE address of the device
AliasAddress
Octet String
The alias address of the device.
16-bit Device
Address
ZigBee NWK
Address
The network address of the parent

node. This field shall not be
present if the node is the
coordinator, otherwise it shall be
present.
ParentNodeShortAddr
ess
ParentNodeFullAddre
ss
64-bit Device
Address
IEEE Address
The IEEE address of the parent

node. This field shall not be
present if the node is the
coordinator, otherwise it shall be
present.
CapabilityInformation
8-bit Bitmask
0x00 to 0xff
The MAC capabilities of the

device. See [R1] Table 3.47.
0x00 to 0xff
The starting index of the

Associated Device List. This field
is only present when Request
Type is Extended Response and
there are associated devices.
StartIndex
AssociatedDevicesLis
t
8-bit Integer
List of 16 bit network addresses

that are associated to the Address
Of Interest. This field is only
present when Request Type is
Extended Response and there are
associated devices.
List of 16-bit
Device
Addresses
5
6
Table 28: NodeDiscoveryEvent Event Handler Results

Name
Status
Status
M
Type
Valid Range
Description
7
8
9
10
6. 4. 1 1. 1
Def in it io n of N O D E _D IS CO V ERY _ E V ENT
A NODE_DISCOVERY_EVENT occurs when a node has been discovered as an effect of a pending

StartNodeDiscovery procedure.
Page 28

6. 4. 1 1. 2
2
3
The NodeDiscoveryEvent event handler is invoked by a ZGD upon reception of an event of type
NODE_DISCOVERY_EVENT.
4
5
The RequestIdentifier parameter of the function shall be equal to the RequestIdentifier parameter of the
StartNodeDiscovery procedure that triggered the discovery process.
6
7
8
9
10
11
12
13
The ShortAddress and ExtendedAddress parameters shall be respectively equal to the Zigbee Network
Address and IEEE address of the discovered node. The Capability parameter shall contain the MAC
capabilities of the device. If available to the ZGD, it shall also report the list of associated devices: in
that case, depending on the gateway implementation, it may report the complete list of associated
devices, or invoke the NodeDiscoveryEvent multiple times, sending each time a subset of that list. In
both cases, StartIndex contains the index of the first entry of AssociatedDevicesList in the complete
devices list. If the node is not a coordinator, the ParentNodeShortAddress and ParentNodeFullAddress
shall be respectively equal to its parent node (i.e. the router or coordinator).
14
6. 4. 1 1. 3
15
16
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA
shall return a Status of SUCCESS.
17
W hen Inv o k ed
6. 4. 1 2 Nod eL eav e Ev ent Ev e nt H an dl er
18
19
The NodeLeaveEvent event handler shall support the parameters specified in Table 29, and shall
20
Table 29: NodeLeaveEvent Event Handler Parameters

Name
Status
Type
Valid Range
Description
RequestIdentifer
ShortAddress
16-bit Device
Address
ZigBee NWK
Address
ExtendedAddress
64-bit Device
Address
IEEE Address
AliasAddress
Octet String
21
22
Table 30: NodeLeaveEvent Event Handler Results

Name
Status
Status
Type
Valid Range
Description
23
24
6. 4. 1 2. 1
Def in it io n of N O D E _L E AV E _ E V E NT
25
26
A NODE_LEAVE_EVENT occurs when a node is leaving the network and the IPHA has subscribed
reception of this events using the StartNodeDiscovery procedure.

Page 29
6. 4. 1 2. 2
2
3
The NodeLeaveEvent event handler is invoked by a ZGD upon reception of an event of type
NODE_LEAVE_EVENT.
4
5
StartNodeDiscovery procedure that triggered the discovery process.
6
7
The ShortAddress and ExtendedAddress parameters shall be respectively equal to the Zigbee Network
Address and IEEE address of the discovered node.
6. 4. 1 2. 3
9
10
11
12
13
W hen Inv o k ed
6. 4. 1 3 Re ad Nod eC a ch e P ro c edu r e
The ReadNodeCache procedure does not support any parameters, and shall support the results specified
in Table 31.
Page 30

Table 31: ReadNodeCache Procedure Results

Name
Status
Type
Status
Nodes
8-bit Integer
Array of Node
structures (see
Table 32)
NodeInformation
Valid Range
Description
0x00 to 0xff
Number of nodes that are reported in

this message.
A list of Node Addresses structures,
one for every node that has been found
in the network and stored into the ZGD
cache.
Table 32: Node Addresses Structure

Name
Status
Type
Valid
Range
Description
ShortAddress
16-bit
Device
Address
ZigBee
NWK
Address
The network address

of the device
ExtendedAddress
64-bit
Device
Address
IEEE
Address
The IEEE address of

the device
AliasAddress
Octet String
The alias address of

the device.
16-bit
Device
Address
ZigBee
NWK
Address
The network address

of the parent node.
This field shall not be
present if the node is
the coordinator,
otherwise it shall be
present.
ParentNodeShortAddress
ParentNodeFullAddress
StartIndex
64-bit
Device
Address
IEEE
Address
The IEEE address of

the parent node. This
field shall not be
present if the node is
the coordinator,
otherwise it shall be
present.
8-bit
Bitmask
0x00 to
0xff
The MAC
capabilities of the
device. See [R1]
Table 3.47.
0x00 to
0xff
The starting index of

the Associated
Device List. This
field is only present
when Request Type
is Extended Response
and there are
associated devices.
8-bit Integer

Page 31
AssociatedDevicesList
List of 16 bit network

addresses that are
associated to the
Address Of Interest.
This field is only
present when Request
Type is Extended
Response and there
are associated
devices.
Array of 16bit Device

Addresses
6. 4. 1 3. 1
2
3
The ReadNodeCache procedure is invoked by an IPHA to read the contents of the node cache present
in the ZGD.
6. 4. 1 3. 2
5
6
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the full
contents of the node cache are returned by the ZGD to the IPHA, without sending any message OTA.
W hen Inv o k ed
6. 4. 1 4 St ar t S e rv i ce Di s cov e r y P ro ce du re
8
9
The StartServiceDiscovery procedure shall support the parameters specified in Table 33 and the results
10
Table 33: StartServiceDiscovery Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
CallbackDestination
If AddressofInterest is either an
extended address or an alias address
then the ZGD shall resolve the 16-bit
short address from its address manager
table.
AddressOfInterest
16-bit Device
Address or
Extended
Address or
AliasAddress
If 0xffff, it means that services on all

the devices in the nwk should be
discovered.
11
12
Table 34: StartServiceDiscovery Procedure Results

Name
Status
Type
Valid Range
Description
Status
RequestIdentifier
13
14
6. 4. 1 4. 1
15
16
The StartServiceDiscovery procedure is invoked by an IPHA to perform a service discovery on the

network to know which services could be offered by the devices in the ZigBee net.
Page 32
W hen Inv o k ed

6. 4. 1 4. 2
2
3
4
starts a transaction, and the ZGD issues a SERVICE_DISCOVERY_EVENT for each discovered
service.

Page 33
6. 4. 1 5 S erv ic eD i sc ov e r yEv e nt Ev ent H an dl e r
2
3
The ServiceDiscoveryEvent event handler shall support the parameters specified in Table 35, and shall
Table 35: ServiceDiscoveryEvent Event Handler Parameters

Stat
us
Name
Type
Valid Range
Description
RequestIdentifer
ShortAddress
16-bit Device Address
ZigBee NWK
Address
ExtendedAddress
IEEE Address
AliasAddress
Octet String
ActiveEndpoints
8-bit Integer
SimpleDescriptors
List of SimpleDescriptors

0x00 to 0xff
Number of active endpoints present on

the device
A list of simple descriptors, one for
each active endpoint
5
6
Table 36: ServiceDiscoveryEvent Event Handler Results

Name
Status
Status
Type
Valid Range
Description
7
8
6. 4. 1 5. 1
Def in it io n of S ER V IC E _D I SCO V E RY _ E V EN T
9
10
A SERVICE_DISCOVERY_EVENT occurs when a service has been discovered as an effect of a

pending StartServiceDiscovery procedure.
11
6. 4. 1 5. 2
12
13
The ServiceDiscoveryEvent event handler is invoked by a ZGD upon reception of an event of type
SERVICE_DISCOVERY_EVENT.
14
15
StartServiceDiscovery procedure that triggered the discovery process.
16
17
18
19
The ShortAddress parameter shall be equal to the Zigbee Network Address of the node that exposes the
services described in this event. The ActiveEndpoints parameter contains the number of endpoints
beloning to that node, and shall match the length of the SimpleDescriptors list, giving detailed
information about each endpoint.
20
6. 4. 1 5. 3
21
22
Page 34
W hen I nv o k ed

1
2
3
6. 4. 1 6 G et S erv i c e D e sc r ipto r P ro c edu r e

The GetServiceDescriptor procedure support the following parameters, and shall support the results
Table 37: GetServiceDescriptor Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
CallbackDestination
DestinationAddressMode
Integer
0x00 - 0xff
The addressing mode used for the

DestinationAddress parameter A
value of AliasAddress indicates that
the DestinationAddress is an alias
address.
If this parameter is omitted then it is
interpreted as a short address
DestinationAddress
Address
As specified by
the
DstAddrMode
parameter
If DestinationAddress is an alias
address then it shall be resolved to a
16-bit network address.
interpreted as a broadcast address
0xffff.
Table 38: GetServiceDescriptor Procedure Results

Name
Status
Type
Valid Range
Description
Status
RequestIdentifier
6
7
6. 4. 1 6. 1
W hen Inv o k ed
8
9
The GetServiceDescriptor procedure is invoked by an IPHA to retrieve the Service Descriptor related
to a specific node identified by its address) and active endpoint.
10
6. 4. 1 6. 2
11
12
13
starts a transaction, and the ZGD issues a SERVICE_DESCRIPTOR_EVENT for the specified active
endpoint supported by the node of interest.
14

Page 35
6. 4. 1 7 S erv ic e D e sc r ipt o r Ev ent Ev ent H and le r
2
3
The ServiceDescriptorEvent event handler shall support the parameters specified in Table 35,
and shall support the results specified in Table 36.
Table 39: ServiceDescriptorEvent Event Handler Parameters

Stat
us
Name
Type
Valid Range
Description
RequestIdentifer
ShortAddress
ZigBee NWK
Address
ExtendedAddress
IEEE Address
AliasAddress
Octet String
ActiveEndpoint
8-bit Integer
The active endpoint on the device
SimpleDescriptor
SimpleDescriptor
The simple descriptor of the active

endpoint
5
6
Table 40: ServiceDescriptorEvent Event Handler Results

Name
Status
Status
Type
Valid Range
Description
7
8
6. 4. 1 7. 1
Def in it io n of S ER V IC E _D E SC RI PT O R _ E V E NT
9
10
A SERVICE_DESCRIPTOR_EVENT occurs when the SimpleDescriptor for a service has

been retrieved as an effect of a pending GetServiceDescriptor procedure.
11
6. 4. 1 7. 2
12
13
The ServiceDescriptorEvent event handler is invoked by a ZGD upon reception of an event of

type SERVICE_DESCRIPTOR_EVENT.
14
15
The RequestIdentifier parameter of the function shall be equal to the RequestIdentifier

parameter of the GetServiceDescriptor procedure.
16
17
18
19
The ShortAddress parameter shall be equal to the Zigbee Network Address of the node that
exposes the service described in this event. The ActiveEndpoint parameter contains the
endpoint belonging to that node, and shall match the SimpleDescriptor giving detailed
information about that endpoint.
20
6. 4. 1 7. 3
21
22
Page 36
W hen Inv o k ed

1
2
3
6. 4. 1 8 Re ad S erv ic e Ca ch e P r oc edu r e
The ReadServiceCache procedure does not support any parameters, and shall support the results
Table 41: ReadServiceCache Procedure Results

Name
Status
Type
Status
Nodes
8-bit Integer
List of Node
Service
structures (see
Table 42)
ServiceInformation
Valid Range
Description
0x00 to 0xff
Number of nodes that are reported in

this message.
A list of Node Service structures, one
for every node that has been found in
the network and stored into the ZGD
cache.
Table 42: Node Service Structure

Name
Status
Type
Valid Range
Description
ShortAddress
16-bit Device
Address
ZigBee NWK
Address
ExtendedAddress
64-bit Device
Address
IEEE Address
AliasAddress
Octet String
ActiveEndpoints
8-bit Integer
SimpleDescriptors
List of
SimpleDescripto
rs

0x00 to 0xff
Number of active endpoints present on

the device
A list of simple descriptors, one for
each active endpoint
6. 4. 1 8. 1
7
8
The ReadServiceCache procedure is invoked by an IPHA to read the contents of the service cache
present in the ZGD.
6. 4. 1 8. 2
10
11
12
13
14
W hen Inv o k ed
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the full
contents of the service cache are returned by the ZGD to the IPHA, without sending any message OTA.
6. 4. 1 9 St ar t G at ew a yD ev i ce P ro ce du re
The StartGatewayDevice procedure shall support the parameters specified in Table 43 and the results

Page 37
Table 43: StartGatewayDevice Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
CallbackDestination
StartupAttributeSetIndex
8-bit
0x00-0xff
Index of a previously configured

Startup Attribute Set.
Defines the device type of the ZGD:
DeviceType
8-bit
Enumeration
0x00 Current device type

configuration
0x00-0x03
0x01 ZigBee coordinator

0x02 ZigBee Router
0x03 ZigBee End Device
ProtocolVersion
[R4] Startup parameters and Security

attributes set sub-clause
StackProfile

ChannelMask

ExtendedPANId

PANId

ShortAddress

TrustCenterAddress

TrustCenterMasterKey

NetworkKey

UseInsecureJoin

PreconfiguredLinkKey

NetworkKeySeqNum

NetworkKeyType

NetworkManagerAddress

StartupControl

ScanAttempts
[R4] Join Parameters attribute set

sub-clause
TimeBetweenScans

sub-clause
Page 38

RejoinInterval

sub-clause
MaxRejoinInterval

sub-clause
IndirectPollRate
[R4] End Device Parameters attribute

set sub-clause
ParentRetryThreshold

set sub-clause
ConcentratorFlag
[R4] Concentrator Parameters

attribute set sub-clause
ConcentratorRadius

ConcentratorDiscoveryTi
me

1
2
3
Table 44: StartGatewayDevice Procedure Results and StartGatewayDeviceEvent Event Handler

Parameters
Name
Status
Type
N/A
Valid Range
N/A
Description
Status
RequestIdentifier
NWKStatus
An optional network error code.
4
5
6. 4. 1 9. 1
W hen Inv o k ed
6
7
8
9
10
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the
StartGatewayDevice procedure is invoked by an IPHA to startup a ZGD contextually giving all the
information needed to configure its stack. If the ZGD receives from the network layer a status
indicating that the NLME request has failed, the procedure shall return with a Status equal to
NETWORK_FAILURE and NwkStatus equal to that status code.
11
6. 4. 1 9. 2
12
13
14
15
16
All the attribute parameters are optional, which means that the ZGD should be able to provide a default
value for each of them, in case they are not specified in the command request. To improve flexibility,
multiple sets of default attribute values can be preconfigured at the ZGD, and the IPHA can use the
StartupAttributeSetIndex parameter to choose which set of attributes to use. All implementations of
ZGDs shall support at least one attribute set, addressable using the value 0.
17
18
19
20
21
22
When receiving this command, the ZGD shall check if a start command is already in progress. If a
start command is already in progress then it shall return a Status of GENERAL_ERROR. Next, the
ZGD shall check if the StartupAttributeSetIndex parameter has been supplied. If supplied the ZGD
shall utilize the attributes in this set to configure the stack and it shall override any of the parameters in
this set if other configuration parameters are supplied as parameters. If the ZGD does not support an
attribute set index, then the function shall fail returning an INVALID_PARAMETER Status code.
23
24
After that, it shall check the contents of the parameters using the same rules outlined in [R4]: if any
inconsistencies or lacks are detected, it shall fail returning an INVALID_PARAMETER error code.

Page 39
1
2
After parameter checking, it shall update its startup parameters using the default values from the
appropriate attribute set, and restart, as if a Restart Device Request (see [R4]) had been received.
6. 4. 2 0 St ar t G at ew a yD ev i ce E v ent Ev e nt Ha ndl e r
4
5
The StartGatewayDeviceEvent event handler shall support the parameters specified in Table 45, and
shall support the results specified in Table 45.
Table 45 StartGatewayDeviceEvent Event Handler Results

Name
Status
Status
RequestIdentifier
NWKStatus
Type
Valid Range
Description
An optional network error code.
7
8
6. 4. 2 0. 1
Def in it io n of ST ART _ G AT EW AY _D E V IC E _ E V ENT
9
10
A START_GATEWAY_DEVICE_EVENT occurs when the ZGD completes its startup procedure,

either succesfully or when failing due to an error.
11
6. 4. 2 0. 2
12
13
The StartGatewayDeviceEvent event handler is invoked by a ZGD upon reception of an event of type
START_GATEWAY_DEVICE_EVENT.
14
15
The NwkStatus parameter shall be present only if the Status is different set to NETWORK_ERROR,
i.e. when an error at network level has occurred, and shall contain the specific network error code.
16
6. 4. 2 0. 3
17
18
19
20
21
W hen Inv o k ed
6. 4. 2 1 Conf igu r eS t a rt u p At t r ibut e Set P ro ced ur e

The ConfigureStartupAttributeSet procedure shall support the parameters specified in Table 46 and the
results specified in Table 47.
Page 40

Table 46: ConfigureStartupAttributeSet Procedure Parameters

Name
Status
M
Type
8-bit
Valid Range
0x00-0xff
Description
Index of a previously of the Startup
Attribute Set to modify.
DeviceType
8-bit
Enumeration

configuration
0x00-0x03

0x02 ZigBee Router
ProtocolVersion

StackProfile

ChannelMask

ExtendedPANId

PANId

ShortAddress

TrustCenterAddress


NetworkKey

UseInsecureJoin


NetworkKeySeqNum

NetworkKeyType


StartupControl

ScanAttempts

sub-clause
TimeBetweenScans

sub-clause
RejoinInterval

sub-clause

Page 41
MaxRejoinInterval

sub-clause
IndirectPollRate

set sub-clause

set sub-clause
ConcentratorFlag

ConcentratorRadius

me

Table 47 ConfigureStartupAttributeSet Procedure Results

Name
Status
Status
Type
Valid Range
Description
6. 4. 2 1. 1
3
4
The ConfigureStartupAttributeSet procedure is invoked by an IPHA to configure one of the startup

attribute sets supported by the ZGD.
6. 4. 2 1. 2
6
7
8
set the startup values of any supplied attributes for the StartupAttributeSetIndex supplied with the new
value and may ignore unsupported attributes, and shall return a Status of SUCCESS.
9
10
11
W hen Inv o k ed
6. 4. 2 2 Re ad St a rt up At t rib ut e S et P ro ce du re
The ReadStartupAttributeSet procedure shall support the parameters specified in Table 48 and the
Page 42

Table 48 ReadStartupAttributeSet Procedure Parameters

Name
Status
StartupAttributeSetIn
dex
Type
8-bit
Valid Range
0x00-0xff
Description
Index of a previously of the Startup
Attribute Set to read.
Table 49: ReadStartupAttributeSet Procedure Results

Name
Status
Status
Type
Valid Range
Description
DeviceType
8-bit
Enumeration

configuration
0x00-0x03

0x02 ZigBee Router
ProtocolVersion

StackProfile

ChannelMask

ExtendedPANId

PANId

ShortAddress

TrustCenterAddress


NetworkKey

UseInsecureJoin


NetworkKeySeqNum

NetworkKeyType


StartupControl

ScanAttempts

sub-clause

Page 43
TimeBetweenScans

sub-clause
RejoinInterval

sub-clause
MaxRejoinInterval

sub-clause
IndirectPollRate

set sub-clause

set sub-clause
ConcentratorFlag

ConcentratorRadius

me

6. 4. 2 2. 1
2
3
The ReadStartupAttributeSet procedure is invoked by an IPHA to read one of the startup attribute sets
supported by the ZGD.
6. 4. 2 2. 2
5
6
7
return the startup values of all attributes, that are supported by the ZGD, for the supplied
StartupAttributeSetIndex and shall return a Status of SUCCESS.
8
9
10
W hen Inv o k ed
Ef f ec t o n I nv o c at ion
6. 4. 2 3 Cr e at e Al i a s Ad d r es s P ro ce du re
The CreateAliasAddress procedure shall support the parameters in Table 50 and the results in Table
51.
11
Table 50 GMO CreateAliasAddress Procedure Parameters

Name
Status
Default
Type
Alias
Octet String
ExtendedAd
dress
64-bit Integer
12
Valid
Range
Description
An arbitrary binary string used to
reference a specific device in future
requests to send a ZigBee frame OTA or
when the ZGD indicates the source of a
ZigBee frame.
referenced by the Alias.
Table 51 GMO CreateAliasAddress Procedure Results

Name
Status
Page 44
Status
M
Type
Valid
Range
Description

6. 4. 2 3. 1
2
3
The CreateAliasAddress procedure allows an IPHA to configure an alias mapping between an arbitrary
binary string and a specific ZigBee device.
6. 4. 2 3. 2
5
6
7
8
9
10
11
12
13
W hen Inv o k ed
verify if the Alias is already configured. If the Alias is already configured then the ZGD shall update
the associated extended address with the new one supplied by the ExtendedAddress parameter and shall
return a Status of SUCCESS. If the Alias is not configured and the ZGD cannot provision for a new
Alias entry then it shall return a Status of GENERAL_ERROR. Otherwise, the ZGD shall create a
new entry for the Alias and ExtendedAddress and return a Status of SUCCESS.
6. 4. 2 4 De let e Al i a s Ad d re s s P ro ce du re
The DeleteAliasAddress procedure shall support the parameters in Table 52 and the results in Table
53.
14
Table 52 GMO DeleteAliasAddress Procedure Parameters

Name
Alias
Status
Default
15
Type
Octet String
Valid
Range
Description
Non-NULL
An arbitrary binary string used to

reference a specific device in future
requests to send a ZigBee frame OTA or
when the ZGD indicates the source of a
ZigBee frame.
Table 53 GMO DeleteAliasAddress Procedure Results

Name
Status
Status
Type
Valid
Range
Description
16
6. 4. 2 4. 1
17
The DeleteAliasAddress procedure allows an IPHA to remove an alias mapping.
18
6. 4. 2 4. 2
19
20
21
22
verify if the Alias is already configured. If the Alias is not already configured then the ZGD shall
return a Status of GENERAL_ERROR. Otherwise, the ZGD shall remove the Alias from its
configured mappings and shall return a Status of SUCCESS.
23
24
W hen Inv o k ed
6. 4. 2 5 Lis t Ad dr e ss e s P ro ce dur e
The ListAddresses procedure shall support the parameters in Table 54.and results in Table 55.
25
Table 54 GMO ListAddresses Procedure Parameters

Name
ShortAddres
s
ExtendedAd
dress
AliasAddress
Status
Default
Type
16-bit Network
Address
EUI-64
Octet String
Valid
Range
Description
Only the address tuple containing this

address shall be returned.

Page 45
Table 55 GMO ListAddresses Procedure Results

Name
Status
Type
Valid Range
Description
Status
NumberOfAddresses
32-bit Integer
AddressList
Address List
Structure
6. 4. 2 5. 1
W hen Inv o k ed
The ListAddresses procedure allows an IPHA to read the current set of address mappings.
6. 4. 2 5. 2
5
6
7
8
9
10
11
12
13

0x000000000xffffffff
The total number of tuples in

AddressList.
A list of known alias, extended address,
and 16-bit network address tuples. If the
16-bit network address is not known then
it shall be reported as 0xfffe. If an alias
is not assigned then it shall be reported as
a NULL string.
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next if more than
one of ShortAddress, ExtendedAddress, or AliasAddress parameters are supplied then a Status of
INVALID_PARAMETER shall be returned. If one of ShortAddress, ExtendedAddress, AliasAddress
is supplied then the ZGD shall return an AddressList containing only the matching address tuple if
present and a Status of SUCCESS. Otherwise, the ZGD shall return a list of all known address tuples
in the AddressList result and a Status of SUCCESS. An address tuple is considered known if an
extended address and short address is contained in one of the ZGD ZigBee stack tables or an alias has
been configured for an extended address.
6. 4. 2 6 Le av e P ro c edu r e
14
15
The Leave procedure shall support the parameters specified in Table 56 and the results specified in
Table 57.
16
Table 56: Leave Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
CallbackDestination

The Mgmt_Leave_req command
frame is sent to this address.
DeviceAddress
Address
RemoveChildren
Boolean
(see [R1] Mgmt_Leave_req subclause)
Rejoin
Boolean
17
Page 46

Table 57: Leave Procedure Results and Leave Event Handler Parameters
Name
Status
Type
Valid Range
N/A
N/A
Description
Status
RequestIdentifier
MgmtCommandStatus
The status of the Mgmt_Leave_req

command (see [R1]
Mgmt_Leave_rsp sub-clause)
2
3
6. 4. 2 6. 1
The Leave procedure is invoked by an IPHA to issue a Mgmt_Leave_req command.
6. 4. 2 6. 2
6
7
8
construct a Mgmt_Leave_req command frame (see [R1] Mgmt_Leave_req sub-clause) using the
supplied parameters, and use the APSDE-SAP to send this command.
9
10
11
12
If the CallbackDestination parameter was supplied, the ZGD shall report the resulting
Mgmt_Leave_rsp command (see [R1] Mgmt_Leave_rsp sub-clause) to the IPHA through the
LeaveEvent event handler and including the same unique identifier value in the RequestIdentifier of the
function.
13
14
15
16
17
18
19
If the CallbackDestination parameter is not supplied, the procedure shall wait for the resulting
Mgmt_Leave_rsp command. When the timer that was set elapses, the ZGD shall stop to keep track of
the resulting response and the procedure should return with a Status of TIMEOUT. If the expected
response command is received from the APSDE-SAP and the status is not SUCCESS, the procedure
shall return with a Status equal to APS_FAILURE and MgmtCommandStatus equal to that status code.
Otherwise if the status is SUCCESS, the procedure shall return with a Status of SUCCESS and
MgmtCommandStatus parameter shall not be present.
20
W hen Inv o k ed
6. 4. 2 7 Le av e Ev e nt Ev e nt Ha ndl er
21
22
The LeaveEvent event handler shall support the parameters specified in Table 57, and shall support the
23
Table 58 LeaveEvent Event Handler Results

Name
Status
Status
Type
Valid Range
Description
24
25
6. 4. 2 7. 1
Def in it io n of L E AV E _ E V ENT
26
27
A LEAVE_EVENT occurs when the ZGD receives a Mgmt_Leave_rsp command and the conditions
described in clause 6.4.26.2 are met.

Page 47
6. 4. 2 7. 2
2
3
The LeaveEvent event handler is invoked by a ZGD upon reception of an event of type
LEAVE_EVENT.
4
5
The MgmtCommandStatus parameter shall be equal to the Status field of the Mgmt_Leave_rsp
command.
6. 4. 2 7. 3
7
8
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA shall
return a Status of SUCCESS.
W hen Inv o k ed
6. 4. 2 8 P er mit Jo in P ro c edu r e
10
11
The PermitJoin procedure shall support the parameters specified in Table 59 and the results specified in
Table 60.
12
Table 59: PermitJoin Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
CallbackDestination

DestinationAddress parameter (see
[R1] sub-clause APSDEDATA.request DstAddrMode
parameter.) A value of AliasAddress
indicates that the DestinationAddress
is an alias address.
DestinationAddressMo
de
DestinationAddress
PermitDuration
Integer
Address
Unsigned int 8
0x00 - 0xff
As specified by
the
DstAddrMode
parameter
0x00 0xff
16-bit network address before it is
supplied to the APSDEDATA.request SAP.
The Mgmt_Permit_Joining_req
command frame is sent to this
address. (see [R1] sub-clause
APSDE-DATA.request DstAddress
parameter)
The value expressed in seconds to
allow nodes to join the network. The
0x00 value leaves the network
indefinitely closed, whereas 0xff
leaves the network indefinitely open.
(see [R1]
Mgmt_Permit_Joining_req subclause)
TCSignificance
Boolean
(see [R1]
Mgmt_Permit_Joining_req subclause)
13
Page 48

Table 60: PermitJoin Procedure Results and PermitJoinEvent Event Handler Parameters
Name
Status
Valid
Range
Type
Status
RequestIdentifier
The status of the

Mgmt_Permit_Joining_req
command (see [R1]
Mgmt_Permit_Joining_rsp subclause)
MgmtCommandStatus
N/A
Description
N/A
2
3
6. 4. 2 8. 1
The PermitJoin procedure is invoked by an IPHA to issue a Mgmt_Permit_Joining_req.
6. 4. 2 8. 2
6
7
8
construct a Mgmt_Permit_Joining_req command frame (see [R1] Mgmt_Permit_Joining_req subclause) using the supplied parameters, and use the APSDE-SAP to send this command.
9
10
11
12
If the CallbackDestination parameter was supplied, the ZGD shall report the resulting
Mgmt_Permit_Joining_rsp command (see [R1] Mgmt_Permit_Joining_rsp sub-clause) to the IPHA
through the PermitJoinEvent event handler and including the same unique identifier value in the
RequestIdentifier of the function.
13
14
15
16
17
18
19
If the CallbackDestination parameter is not supplied, the procedure shall wait for the resulting
Mgmt_Permit_Joining_rsp command. When the timer that was set elapses, the ZGD shall stop to keep
track of the resulting response and the procedure should return with a Status of TIMEOUT. If the
expected response command is received from the APSDE-SAP and the status is not SUCCESS, the
procedure shall return with a Status equal to APS_FAILURE and MgmtCommandStatus equal to that
status code. Otherwise if the status is SUCCESS, the procedure shall return with a Status of SUCCESS
and MgmtCommandStatus parameter shall not be present.
20
W hen Inv o k ed
6. 4. 2 9 P er mit Jo in Ev e nt Ev e nt H an dl er
21
22
The PermitJoinEvent event handler shall support the parameters specified in Table 60, and shall
23
Table 61 PermitJoinEvent Event Handler Results

Name
Status
Status
Type
Valid Range
Description
24
25
6. 4. 2 9. 1
Def in it io n of P ERM IT JO I N _E V E NT
26
27
A PERMITJOIN_EVENT occurs when either the ZGD receives a Mgmt_Permit_Joining_rsp

command and the conditions described in clause 6.4.28.2 are met.

Page 49
6. 4. 2 9. 2
W hen Inv o k ed
2
3
The PERMITJOIN_EVENT handler is invoked by a ZGD upon reception of an event of type

PERMITJOIN_EVENT.
4
5
The MgmtCommandStatus parameter

Mgmt_Permit_Joining_rsp command.
6. 4. 2 9. 3
7
8
shall
be
equal
to
the
Status
field
of
the
10
6.5
ZigBee Devi ce Profile
11
12
13
As a fully compliant ZigBee device, a ZGD shall implement the mandatory ZDO client and server
services as required in [R1] and may optionally implement the optional ZDO client and server services.
Additionally, a ZGD shall expose the Device Profile functions, listed in Table 62, to an IPHA.
14
Table 62: ZigBee Device Profile Functions

Function
SendZDPCommand
NotifyZDPEvent
15
16
17
O
O
Description
Allows an IPHA to send and receive arbitrary
ZDP frames.
6. 5. 1 S endZ D PC omm an d P ro ce du re
The SendZDPCommand procedure shall support the parameters specified in Table 63 and the results
Page 50

Table 63: SendZDPCommand Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
CallbackDestination
Octet string
Variable
0x00 - 0xff

DestinationAddress parameter (see [R1]
sub-clause APSDE-DATA.request
DstAddrMode parameter.) A value of
AliasAddress indicates that the
DestinationAddress is an alias address.
DestinationAddress
Mode
Integer

assumed that a binding table entry
exists in the GW that determines the
destination.
address then it shall be resolved to a 16bit network address before it is supplied
to the APSDE-DATA.request SAP.
DestinationAddress
Address
As specified by
the
DstAddrMode
parameter
The ZDP command frame is sent to this

address. (see [R1] sub-clause APSDEDATA.request DstAddress parameter)
destination.
TxOptions
8-bit Bitmap
0x00 to 0x07
Same parameter as in [R1] Table 2.2.
Radius
8-bit Integer
0x00 to 0xff
ClusterID
16-bit Integer
ZigBee Cluster
ID
The cluster identifier associated to the

ZDP command to send in the request in
[R1]
Variable
This is the transaction data field as

described in [R1] sub-clause 2.4.2.8.2.
It shall be one of the client services
([R1] sub-clause 2.4.3)
Command
Octet string

Page 51
Table 64: SendZDPCommand Procedure Results and NotifyZDPEvent Event Handler Parameters
Name
Status
Type
Valid Range
Status
Enumeration
SUCCESS,
PARAMETER_INVALID_VALUE,
TIMEOUT, APS_FAILURE or
another status Code from Table 2
RequestIdentifier
32-bit
unsigned
Integer
0x00000000-0xffffffff
CallbackIdentifier
32-bit
unsigned
Integer
Description
When invoked from a

Callback Handler then
this parameter shall be
supplied and shall match
the identifier of the
invoking Callback
Handler. Otherwise this
parameter shall not be
supplied.
Source
16-bit Device
Address
ZigBee NWK Address
The network address of

the cache device
responding on behalf of
an end device.
SecurityStatus
8-bit Integer
0xab to 0xad
Same parameter as in
[R1] Table 2.4. Values
are defined in [R1] Table
2.26
LinkQuality
8-bit Integer
0x00 to 0xff
Same parameter as in
[R1] Table 2.4
RxTime
32-bit Integer
0 to 232 -1
Timestamp in
milliseconds. Because it
is implementation
specific in [R1], it is only
relevant relatively as
other timestamp from the
same ZGD
ClusterID
16-bit Integer
ZigBee Cluster ID
The cluster identifier

associated to the ZDP
command received in the
response
Variable
This is the transaction

data field as described in
[R1] sub-clause
2.4.2.8.2. It shall one of
the client services ([R1]
sub-clause 2.4.3)
Command
Octet string
2
3
4
5
The SendZDPCommand procedure is invoked by an IPHA in order to have the ZGD sending a ZDP
request command frame as described in [R1] sub-clause 2.4.3.
Page 52

2
3
4
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next if the
CallbackDestination parameter was not supplied and the Destination parameter indicates a broadcast
address, the procedure shall return a Status of PARAMETER_INVALID_VALUE.
5
6
7
8
9
10
11
12
Next the ZGD shall construct a ZDP command frame using the Command parameter as the Transaction
Data Field (see [R1] sub-clause 2.4.2.8). Then it shall use the APSDE-SAP to send this command. The
destination address mode shall be set to the DesinationAddressMode parameter if present, otherwise set
the default to 0x03. The destination endpoint and source endpoint shall be set to 0, the profile identifier
shall be set to 0, the cluster identifier shall be set to the value of the Cluster parameter, the ASDU shall
be the ZDP command frame, and the TxOptions shall be set to the value of the TxOptions parameter. If
the ZGD receives from the APSDE-SAP a status indicating that the APS request has failed, the
procedure should return with a status of APS_FAILURE.
13
14
15
16
17
If the CallbackDestination parameter was supplied, the ZGD shall report the resulting ZDP responses
to the IPHA through the NotifyZDPEvent event handler and including the same unique identifier value
in the RequestIdentifier of the function. The ZGD shall use the Transaction Sequence Number of the
ZDP command to manage the correspondence between the ZigBee frames and the RequestIdentifier of
the functions.
18
19
20
21
22
23
24
25
26
27
28
29
If the CallbackDestination parameter is not supplied, the procedure shall wait for the expected response
ZDP command frame by using the Transaction Sequence Number. When the timer that was set
elapses, the ZGD shall stop to keep track of the resulting response and the procedure should return with
a Status of TIMEOUT. If the expected resulting response command frame is received from the
APSDE-SAP and the status is not SUCCESS, the procedure shall return with a Status of
APS_FAILURE. Otherwise if the status of is SUCCESS, the procedure shall return with a Status of
SUCCESS, the Source result equal to the source address of the ZigBee node that issued the received
command, the Cluster result equal to the cluster identifier indicated by the APS, the SecurityStatus and
LinkQuality shall be equal to the same parameters indicated by the APS, the RxTime shall be equal to a
relative timestamp value in milliseconds according to the RxTime parameter indicated by the APS and
the Command result equal to the portion of the APSDU representing the ZDP command received and
excluding the Transaction Sequence Number of the ZDP command.
30

Page 53
6. 5. 2 Not if yZ D P Ev ent Ev en t H and le r
2
3
The NotifyZDPEvent event handler shall support the parameters specified in Table 64, and shall
Table 65: NotifyZDPEvent Event Handler Results

Name
Status
Status
M
Type
Enumeration
Valid Range
SUCCESS
Description
5
6
6. 5. 2 .1 Def in it io n of Z D P_ Ev ent
7
8
9
10
A ZDP_EVENT occurs when the ZGD receives successfully a ZDP command frame on one of the
ZDP Server Services as described in [R1] sub-clause 2.4.4. The ZDP command frame is received
through the APSDE-SAP of the ZGD. If the status of the APSDE-DATA.indication primitive is not
SUCCESS, the ZDP_EVENT does not occur.
11
12
13
The NotifyZDPEvent event handler is invoked by a ZGD upon reception of an event of type
ZDP_EVENT.
14
15
16
The ZGD first check whether the Transaction Sequence Number refers to a unique request identifier
that was created by a prior call of the SendZDPCommand on this ZGD. If such identifier exists, its
value shall be supplied in the RequestIdentifier parameter of the function.
17
18
19
20
21
22
23
The Source parameter shall be equal to the source address of the ZigBee node that issued the received
command, the Cluster parameter shall be equal to the cluster identifier indicated by the APS, the
SecurityStatus and LinkQuality shall be equal to the same parameters indicated by the APS, the
RxTime shall be equal to a relative timestamp value in milliseconds according to the RxTime
parameter indicated by the APS and the Command parameter shall be equal to the portion of the
APSDU representing the ZDP command received and excluding the Transaction Sequence Number of
the ZDP command.
24
25
26
27
Page 54

6.6
ZigBee Clust er Library
2
3
4
The functions in this sub-clause are used to send and receive ZCL commands in a generic manner.
They are intended to be part of the minimum required functionality for any GW since they supply one
of the core required pieces of GW functionality in a simple form.
Table 66: ZigBee Cluster Library Functions

Function
SendZCLCommand
NotifyZCLEvent
6
7
8
O
O
Description
Allows an IPHA to send and receive arbitrary
ZCL frames.
6. 6. 1 S endZ CL Com ma nd P ro ce du re
The SendZCLCommand procedure shall support the parameters specified in Table 67 and the results

Page 55
Table 67: SendZCLCommand Parameters

Name
Status
Type
Valid Range
Description
Timeout
32-bit
unsigned
integer
CallbackDestination
Octet string
Variable
0x00 - 0xff

DestinationAddress parameter (see
[R1] sub-clause APSDE-DATA.request
DestinationAddressMo
de
Integer

destination.
DestinationAddress
Address
As specified by
the
DstAddrMode
parameter
16-bit network address before it is
supplied to the APSDE-DATA.request
SAP.
destination.
The identifier for the endpoint on the
destination device to which the ZCL
command is directed.
DestinationEndpoint
Endpoint ID
Any valid
endpoint ID

destination endpoint.
See the APSDE-DATA.request
parameter list and description in [R1]
Table 2.2 for a description of the
corresponding primitive parameter
The ZigBee application profile under
which the contents of this ZCL
command are to be interpreted.
ProfileID
16-bit Integer
Any valid
profile ID
This parameter may be omitted in the

case where a source endpoint, is
supplied, since the source endpoint can
be used to determine the profile.
ClusterID
16-bit Integer
Any cluster ID
The cluster identifier associated to the

ZCL command to send in the request in
[R1].
Page 56

Name
Status
Type
Valid Range
Description
The intended source endpoint on the
ZGD for ZCL command.
SourceEndpoint
Endpoint ID
Any valid
endpoint ID
This parameter may be omitted in the

case where a profile identifier is
supplied as the ZGD may, under certain
circumstances, be able to determine the
source endpoint from the profile and
cluster used.
0000 xxxx
TxOptions
Radius
Bitmap
ZCLHeader
Integer
(Where x can be
0 or 1)
Any number up
to the maximum
radius of the
network.
Octet String
ZCLHeader
Octet string
Any valid ZCL

command

A transmission radius for the ZCL
command. This may be thought of,
roughly speaking, as a distance that
the command will travel through the
network.
(see [R5] General ZCL Frame Format)
The body of the command.
ZCLPayload
See the ZCL frame format description

in [R5] for a description of the
corresponding frame field.
Table 68: SendZCLCommand Procedure Results

Name
Status
Type
Status
8-bit unsigned
Integer
RequestIdentifier
32-bit unsigned
Integer
CallbackIdentifier
32-bit unsigned
Integer
Valid Range
status Code from
Table 2
Description
When invoked from a Callback
Handler then this parameter shall
be supplied and shall match the
identifier of the invoking
Callback Handler. Otherwise this
parameter shall not be supplied.

Page 57
The Status reported by APSDEDATA.indication that delivered

the ZCL command.
APSStatus
Status
Enumeration
Any valid status
Note that if this parameter has

any other value than SUCCESS
then none of the optional
parameters below will be
delivered.
See the APSDE-DATA.indication
parameter list and description in
[R1] Table 2.4 for a description
of the corresponding primitive
parameter.
An implementation-specific time
value for the time of receipt of
this ZCL command.
RxTime
Integer
Implementation
specific

parameter.
The endpoint on the ZGC to
which the ZCL command was
directed.
DestinationEP
SourceAddressMode
SourceAddress
Endpoint ID
Integer
Address
SourceExtendedAddress
64-bit
IEEE
address
SourceAliasAddress
Octet String
Page 58
Any valid endpoint
0x00 - 0xff
As specified by
the
SourceAddressMode
parameter
Any 64-bit, IEEE

address

parameter.
DestinationAddress parameter
(see [R1] Table 2.4 sub-clause
APSDE-DATA.indication
SrcAddrMode parameter)
The ZDP response command
frame was sent from this address.
(see [R1] sub-clause APSDEDATA.indication SrcAddress
parameter)
This parameter may be omitted in
the case where the Status
parameter indicates unsuccessful
receipt of the command.
The extended address of the
source device if it is known in the
ZGD address manager tables.
The alias address of the source
address if known in the ZGD
address manager tables.

An identifier for the endpoint on

the sending device that issued the
command.
SourceEP
Endpoint ID
Any valid endpoint

ID

parameter.
An identifier for the profile under
which this command is to be
interpreted.
ProfileID
16-bit Integer
Any valid ZigBee

profile ID

receipt of the command. Also, if
the profile is unambiguously
identified by other means, e.g. the
destination endpoint, then this
parameter may be omitted.
parameter.
This may be any valid cluster
identifier under the commands
profile.
ClusterID
16-bit Integer
Any valid cluster

ID.

parameter.
ZCLHeader
(see [R5] General ZCL Frame

Format)
Octet String
The body of the command.

ZCLPayload
Octet string
Any valid ZCL

command
See the ZCL frame format

description in [R5] for a
description of the corresponding
frame field.
The SendZCLCommand procedure is invoked by an IPHA to send an arbitrary ZCL frame OTA.

Page 59
2
3
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZCL
command is assembled and sent using the APSDE-SAP and Status is returned as SUCCESS.
6. 6. 2 Not if yZ CL Ev e nt Ev en t H and le r
5
6
The NotifyZCLEvent event handler shall support the parameters in Table 68 and the results listed in
Table 69.
Table 69: NotifyZCLEvent Event Handler Results

Name
Status
Type
Valid Range
Description
Status
Status
Enumeration
SUCCESS
The IP host always acknowledges a

ZCL event with a status of SUCCESS.
9
10
The NotifyZCLEvent event handler is invoked by the ZGD on receipt of ZCL command from the
ZigBee network.
11
12
13
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA will
14
Page 60

6.7
Application Support Sub -La yer
Table 70: Application Support Sub-Layer Functions

Function
ConfigureNodeDescriptor
GetNodeDescriptor
GetNodePowerDescriptor
ConfigureUserDescriptor
GetUserDescriptor
ConfigureEndpoint
O
O
O
O
O
M
ClearEndpoint
SendAPSMessage
NotifyAPSMessageEvent
AddGroup
RemoveGroup
RemoveAllGroups
GetGroupList
M
M
O
O
O
O
GetBindingList
Description
Functions to allow an IPHA to read
and configure the ZGDs
descriptiors.
Functions to allow an IPHA to
manage ZGD endpoints.
Allows an IPHA to send or receive
an APS frame.
Functions to allow an IPHA to
manage the ZGDs group
configuration.
Allows an IPHA to read the ZGDs
binding table.
6. 7. 1 Conf igu r eNo de De s c ri ptor p ro ce du re
4
5
The ConfigureNodeDescriptor procedure shall support the parameters specified in Table 71 and the
Table 71: ConfigureNodeDescriptor Procedure Parameters

Name
NodeDescriptor
Status
Type
Default type:
Octet String
ZigBee Node
Descriptor
Valid Range
Variable
Description
The information required to build a
ZigBee node descriptor. The default
encoding shall be [R1] Table 2.28
except otherwise specified for a specific
RPC binding in the present
specification.
7
8
Table 72: ConfigureNodeDescriptor Procedure Results

Name
Status
Status
Type
8-bit unsigned
Integer
Valid Range
SUCCESS,
NOT_ALLOWED,
MEMORY_ERROR
or any Status Code
defined in Table 2
Description
9
10
11
12
The ConfigureNodeDescriptor procedure is invoked by an IPHA in order to configure the ZigBee Node
Descriptor in the ZDO of the ZGD.

Page 61
2
3
4
update its ZDO as follows. The node descriptor stored in the ZDO as defined in [R1] 2.3.2.3 shall be
replaced by the node descriptor supplied in the NodeDescriptor parameter of the procedure.
5
6
7
8
9
If the ZGD does not allow the configuration of this descriptor, the procedure shall return with a Status
of NOT_ALLOWED and none of the aforementioned change in the ZDO configuration occurs. If the
ZGD does not have enough memory to store the descriptor supplied, the procedure shall return with a
Status of MEMORY_ERROR and none of the aforementioned change in the ZDO configuration
occurs. Otherwise the procedure shall return with a Status of SUCCESS.
10
11
Any subsequent ZDP service discovery request received by the ZGD from any ZigBee node in its
network shall be replied, if supported, to reflect the updated ZDO information.
12
6. 7. 2 G et N od eD e sc ri pt o r p ro ce du re
13
14
The GetNodeDescriptor procedure has no parameters and shall support the results specified in Table
72.
15
Table 73: GetNodeDescriptor Procedure Results

Name
Status
Status
NodeDescriptor
Type
8-bit unsigned
Integer
Default type:
Octet String
ZigBee Node
Descriptor
Valid Range
Description
A Status Code
defined in Table
2
Variable

ZigBee node descriptor. The default
specification.
16
17
18
19
The GetNodeDescriptor procedure is invoked by an IPHA in order to read the current ZigBee Node
20
21
22
return the node descriptor stored in the ZDO as defined in [R1] 2.3.2.3.
23
24
25
6. 7. 3 G et N od e Pow er D es c ri pt or p ro ce du re
The GetNodePowerDescriptor procedure has no parameters and shall support the results specified in
Table 74.
Page 62

Table 74: GetNodePowerDescriptor Procedure Results

Name
Status
Status
NodePowerDescriptor
Type
8-bit unsigned
Integer
Default type:
Octet String
ZigBee Node
Power
Descriptor
Valid Range
Description
A Status Code
defined in Table
2
Variable

ZigBee node power descriptor. The
default encoding shall be [R1] Table
2.33 except otherwise specified for a
specific RPC binding in the present
specification.
2
3
4
5
The GetNodePowerDescriptor procedure is invoked by an IPHA in order to read the current ZigBee
Node Power Descriptor in the ZDO of the ZGD.
7
8
return the node power descriptor stored in the ZDO as defined in [R1] 2.3.2.4.
6. 7. 4 Conf igu r eU se r De s cr i ptor p ro ce du re
10
11
The ConfigureUserDescriptor procedure shall support the parameters specified in Table 75 and the
12
Table 75: ConfigureUserDescriptor Procedure Parameters

Name
UserDescriptor
Status
Type
Default type:
Octet String
ZigBee User
Descriptor
Valid Range
Variable
Description
ZigBee user descriptor. The default
specification.
13
14
Table 76: ConfigureUserDescriptor Procedure Results

Name
Status
Status
Type
8-bit unsigned
Integer
Valid Range
SUCCESS,
MEMORY_ERROR,
NOT8ALLOWED or
any Status Code
defined in Table 2
Description
15

Page 63
2
3
The ConfigureUserDescriptor procedure is invoked by an IPHA in order to configure the ZigBee User
5
6
7
update its ZDO as follows. The user descriptor stored in the ZDO as defined in [R1] 2.3.2.7 shall be
replaced by the user descriptor supplied in the UserDescriptor parameter of the procedure.
8
9
10
11
12
If the ZGD does not allow the configuration of this descriptor, the procedure shall return with a Status
of NOT_ALLOWED and none of the aforementioned change in the ZDO configuration occurs. If the
ZGD does not have enough memory to store the descriptor supplied, the procedure shall return with a
Status of MEMORY_ERROR and none of the aforementioned change in the ZDO configuration
occurs. Otherwise the procedure shall return with a Status of SUCCESS.
13
14
15
6. 7. 5 G et U s e rD es c ri pt o r p r oc edu r e
16
The GetUserDescriptor procedure has no parameters and shall support the results specified in Table 77.
17
Table 77: GetUserDescriptor Procedure Results

Name
Status
Status
UserDescriptor
Type
8-bit unsigned
Integer
Default type:
Octet String
ZigBee User
Descriptor
Valid Range
Description
A Status Code
defined in Table
2
Variable

ZigBee user descriptor. The default
specification.
18
19
20
21
The GetUserDescriptor procedure is invoked by an IPHA in order to read the current ZigBee User
22
23
24
return the User Descriptor stored in the ZDO as defined in [R1] 2.3.2.7.
25
26
27
6. 7. 6 Conf igu r eE ndpo int p ro ce du re

The ConfigureEndpoint procedure shall support the parameters specified in Table 78 and the results
Page 64

Table 78: ConfigureEndpoint Procedure Parameters

Name
Status
Endpoint
SimpleDescriptor
Type
8-bit Integer
Default type:
Octet String
ZigBee Simple
Descriptor
Valid Range
Description
0x01-0xf0
Endpoint to mark as active with the

simple descriptor supplied
Variable

ZigBee simple descriptor. The default
specification.
2
3
Table 79: ConfigureEndpoint Procedure Results

Name
Status
Status
Type
Enumeration
Valid Range
SUCCESS,
NOT_ALLOWED,
MEMORY_ERROR
or any Status Code
defined in Table 2
Description
4
5
6
7
8
9
10
11
12
13
14
The ConfigureEndpoint procedure is invoked by an IPHA in order to include an endpoint in the list of
active endpoints and to set a simple descriptor for this endpoint in the ZDO of the ZGD. Consequently,
if a ZigBee node issues a request to discover the active endpoints on the ZGD, the ZGD will indicate
that the list of active endpoints includes the endpoint supplied in parameter of this procedure. If a
ZigBee node issues a request to discover the simple descriptor supported by this endpoint on the ZGD,
the ZGD will respond with the simple descriptor supplied in parameter of this procedure. An IPHA
normally call such procedure when it implements a ZigBee application object on behalf of the ZigBee
node of the ZGD so that from a node in the ZigBee network, the ZGD behaves exactly as if the
application object was implemented on this device.
15
16
17
18
19
20
21
update its ZDO as follows. The endpoint equal to the value of the Endpoint parameter shall be added in
the list of active endpoints and the simple descriptor defined by the value of the SimpleDescriptor
parameter shall be associated with this endpoint. If this endpoint was already in the list of active
endpoint, the previous simple descriptor associated with this endpoint shall be replaced by the one
supplied in the SimpleDescriptor parameter of this procedure.
22
23
24
25
26
27
28
If the ZGD does not allow the configuration of this endpoint (this could happen especially at run time
since some chipset vendors do not support the adding or removing of active end points after the ZigBee
stack is started), the procedure shall return with a Status of NOT_ALLOWED and none of the
aforementioned change in the ZDO configuration occurs. If the ZGD does not have enough memory to
store the simple descriptor supplied, the procedure shall return with a Status of MEMORY_ERROR
and none of the aforementioned change in the ZDO configuration occurs. Otherwise the procedure
shall return with a Status of SUCCESS.
29
30

Page 65
6. 7. 7 Cl ea r En dpo int P ro c e dur e
2
3
The ClearEndpoint procedure shall support the parameters specified in Table 80 and the results
Table 80: ClearEndpoint Procedure Parameters

Name
Endpoint
Status
M
Type
8-bit Integer
Valid Range
0x01 to 0xf0
Description
The endpoint to clear from the list of
active endpoints
5
6
Table 81: ClearEndpoint Procedure Results

Name
Status
Status
Type
Enumeration
Valid Range
SUCCESS,
NOT_ALLOWED,
or any Status Code
defined in Table 2
Description
(see sub-clause 5.2.4 )
7
8
9
10
11
12
13
14
15
16
The ClearEndpoint procedure is invoked by an IPHA in order to exclude an endpoint in the list of
active endpoints and to remove any simple descriptor for this endpoint in the ZDO of the ZGD.
Consequently, if a ZigBee node issues a request to discover the active endpoints on the ZGD, the ZGD
will not indicate the endpoint supplied in parameter of this procedure in the list of active endpoints. If a
ZigBee node issues a request to discover the simple descriptor supported by this endpoint on the ZGD,
the ZGD will not report any simple descriptor supported. An IPHA normally call such procedure when
a previous configuration of the ZDO indicated some services supported by this endpoint for instance
due to a prior call to the ConfigureEndpoint procedure.
17
18
19
20
21
update its ZDO as follows. The endpoint equal to the value of the Endpoint parameter shall be removed
from the list of active endpoints and if a simple descriptor was associated with this endpoint in the
ZDO, it shall be disassociated from this endpoint.
22
23
24
If the ZGD does not allow clearing the configuration of this endpoint, the procedure shall return with a
Status of NOT_ALLOWED and none of the aforementioned change in the ZDO configuration occurs.
Otherwise the procedure shall return with a Status of SUCCESS.
25
26
27
28
29
6. 7. 8 S end AP SM e ss ag e P r oc edu r e
The SendAPSMessage procedure shall support the parameters specified in Table 82 and the results
Page 66

Table 82: SendAPSMessage Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
CallbackDestination
Octet string
Variable
0x00 - 0xff

sub-clause APSDE-DATA.request
DestinationAddress
Mode
Integer

destination.
address then it shall be resolved to a 16bit network address before it is supplied
to the APSDE-DATA.request SAP.
DestinationAddress
Address
As specified by
the
DstAddrMode
parameter

destination.
The identifier for the endpoint on the
destination device to which the ZCL
command is directed.
DestinationEndpoint
Endpoint ID
Any valid
endpoint ID

destination endpoint.
parameter list and description in [RX]
for a description of the corresponding
primitive parameter
SourceEndpoint
8-bit Integer
ZigBee
Endpoint
The ZGD endpoint to use as the source.
ClusterID
16-bit Integer
ZigBee Cluster
Identifier
The cluster ID to send to.
DataLength
16-bit Integer
Data
Octet String
Variable
The data to send.
TxOptions
8-bit Bitmap
0x00 to 0x07
Radius
8-bit Integer
0x00 to 0xff
The length of the data message.

Page 67
Table 83: SendAPSMessage Procedure Results

Name
Status
Status
Type
Valid Range
Description
Enumeration
A Status Code
defined in Table
2
(see sub-clause 5.2.4 )

The Status parameter returned by in the
APSDE-DATA.confirm. (see [R1]
APSDE-DATA.confirm Parameters
table).
The TxTime parameter in milliseconds.
(see [R1] APSDE-DATA.confirm
Parameters table)
ConfirmStatus
Enumeration
See APSDEDATA.confirm
status Parameter
TxTime
Integer
Implementation
specific
2
3
4
5
The SendAPSMessage procedure is invoked by an IPHA in order to send an APS message in the
ZigBee network and to control the details of the ASDU from the IPHA.
7
8
9
10
11
12
13
14
15
16
17
18
use the APSDE-DATA.request primitive with the parameters supplied in the procedure and return the
results retrieved from the APSDE-DATA.confirm succeeding to the APSDE-DATA.request primitive
call and shall return a Status of SUCCESS. If the ConfirmStatus parameter is supported, it will return a
status indicating if the APSDE-DATA command was send successfully or not, otherwise it is supposed
that the message is sent in a best effort way. If the callback destination is present (nonblocking
invocation), the NofitySendAPSMessage Event shall use this callback to provide a notification.
6. 7. 9 Nof it yS e nd AP SM e ss a ge Ev ent H and le r

If the SendAPSMessage procedure invocation is nonblocking, ZGD is required to send a notification
response to the IPHA after the APSDE-DATA.request procedure is completed . The
NotifySendAPSEvent Event Handler shall support parameters specified in Table 84 and results in and
Table 85.
Page 68

Table 74: NotifySendAPSMessage Event Handler Parameters

Name
Status
Status
M
ConfirmStatus
Type
Description
8-bit unsigned
Integer
status Code from

Table 2
Enumeration
See APSDEDATA.confirm
status Parameter
The Status parameter returned by in

the APSDE-DATA.confirm. (see
[R1] APSDE-DATA.confirm
Parameters table).
Implementation
specific
TxTime
Integer
RequestIdentifier
32-bit unsigned
Integer
Valid Range
The TxTime parameter in

milliseconds. (see [R1] APSDEDATA.confirm Parameters table)
Table 75: NotifySendAPSMesage Event Handler Response

Name
Status
Status
M
Type
8-bit unsigned
Integer
Valid Range
status Code from
Table 2
Description
4
5
6
6. 7. 1 0 Not if y AP SM e ss ag e Ev ent Ev ent H and le r

The NotifyAPSMessageEvent event handler shall support the parameters specified in Table 84 and the

Page 69
Table 84: NotifyAPSMessageEvent EventHandler Parameters

Name
CallbackIdentifier
Status
Type
32-bit
unsigned
Integer
Valid Range
Description
Handler then this parameter
shall be supplied and shall
match the identifier of the
invoking Callback Handler.
Otherwise this parameter shall
not be supplied.
DestinationAddressMode
Integer
0x00 - 0xff
(see [R1] sub-clause APSDEDATA.indication Parameters)

DestinationAddress
Address
As specified by
the
DstAddrMode
parameter
DestinationEndpoint
Endpoint ID
Any valid
endpoint ID
SourceAddressMode
Integer
0x00 - 0xff
Address
As specified by
the
SourceAddress
Mode parameter
SourceExtendedAddress
64-bit
IEEE
address
Any 64-bit,
IEEE
address
The extended address of the

source device if it is known in
the ZGD address manager
tables.
SourceAliasAddress
Octet String
SourceEndpoint
Endpoint ID
Any valid
endpoint ID
ProfileID
Profile ID
Any valid
ZigBee profile
ID
ClusterID
Cluster ID
Any valid
cluster ID.
DataLength
Integer
Data
Octet string
Variable
APSStatus
Enumeration
APS Status
SecurityStatus
Enumeration
Security Status
LinkQuality
Integer
0x00 - 0xff
RxTime
Integer
Implementation
specific
SourceAddress
The alias address of the source

address if known in the ZGD
address manager tables.
Page 70

Table 85: NotifyAPSMessageEvent Event Handler Results

Name
Status
Status
Type
Enumeration
Valid Range
A Status Code
defined in
Table 2
Description
2
3
6. 7. 1 0. 1
4
5
The NotifyAPSMessageEvent event handler is invoked by a ZGD in order to send the contents of a
received APS message to an IPHA.
6. 7. 1 0. 2
7
8
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the ZGD shall
use the APSDE-DATA.indication parameters for the request parameters of the function.
W hen Inv o k ed
6. 7. 1 1 Ad dG rou p P ro ce du re
10
11
The AddGroup procedure shall support the parameters specified in Table 86 and the results specified in
Table 87.
12
Table 86: AddGroup Procedure Parameters

Name
Status
Type
Valid Range
Description
GroupAddress
16-bit Integer
ZigBee Group
Address
The group address to associate to the

supplied endpoint.
Endpoint
8-bit Integer
0x01 0xf0
A endpoint on the ZGD.
13
14
Table 87: AddGroup Procedure Results

Name
Status
Status
Type
Enumeration
Valid Range
A Status Code
defined in Table
2
Description
15
16
6. 7. 1 1. 1
W hen Inv o k ed
17
18
19
The AddGroup procedure is invoked by an IPHA in order to add the specified endpoint on the ZGD to
the provided group address so that future group-addressed frames or multicast frames will be delivered
to the endpoint.
20
6. 7. 1 1. 2
21
22
23
24
use the ASME-ADD-GROUP.request primitive with the parameters supplied in the procedure and
return the results retrieved from the ASME-ADD-GROUP.confirm succeeding to the ASME-ADDGROUP.request primitive call.

Page 71
6. 7. 1 2 Re mov eG ro up P ro c e dur e
2
3
The RemoveGroup procedure shall support the parameters specified in Table 88 and the results
Table 88: RemoveGroup Procedure Parameters

Name
Status
Type
Valid Range
Description
GroupAddress
16-bit Integer
ZigBee Group
Address
The group address to disassociate from

the supplied endpoint
Endpoint
8-bit Integer
0x01 0xf0
A endpoint on the ZGD
5
6
Table 89: RemoveGroup Procedure Results

Name
Status
Status
Type
Enumeration
Valid Range
A Status Code
defined in Table
2
Description
7
8
6. 7. 1 2. 1
W hen Inv o k ed
9
10
11
The RemoveGroup procedure is invoked by an IPHA in order to remove the specified endpoint on the
ZGD from the provided group address so that future group-addressed frames or multicast frames will
not be delivered to the endpoint.
12
6. 7. 1 2. 2
13
14
15
16
use the ASME-REMOVE-GROUP.request primitive with the parameters supplied in the procedure and
return the results retrieved from the ASME-REMOVE-GROUP.confirm succeeding to the ASMEREMOVE-GROUP.request primitive call.
17
6. 7. 1 3 Re mov e Al l G roup s P r oc edu r e
18
19
The RemoveAllGroups procedure shall support the parameters specified in Table 90 and the results
20
Table 90: RemoveAllGroups Procedure Parameters

Name
Endpoint
Status
M
Type
8-bit Integer
Valid Range
0x01 0xf0
Description
A endpoint on the ZGD
21
22
Table 91: RemoveAllGroups Procedure Results

Name
Status
Status
Type
Enumeration
Valid Range
A Status Code
defined in Table
2
Description
23
Page 72

6. 7. 1 3. 1
2
3
4
The RemoveAllGroups procedure is invoked by an IPHA in order to remove the specified endpoint on
the ZGD from all group addresses so that no future group-addressed frames or multicast frames will be
delivered to the endpoint.
6. 7. 1 3. 2
6
7
8
9
use the ASME-REMOVE-ALL-GROUP.request primitive with the parameters supplied in the
procedure and return the results retrieved from the ASME-REMOVE-ALL-GROUP.confirm
succeeding to the ASME-REMOVE-ALL-GROUP.request primitive call.
10
11
W hen Inv o k ed
6. 7. 1 4 G et G rou pLi st P ro c ed ur e
The GetGroupList procedure shall support the results specified in Table 92.
12
Table 92: GetGroupList Procedure Results

Name
Status
Type
Valid Range
Description
Status
Enumeration
A Status Code
defined in Table
2
GroupCount
16-bit Integer
0x0000 to 0xffff
Number of entries in GroupList
Default type:
Octet String
Array of
Endpoints Per
Group Entry
Variable
List all the groups supporting endpoints

and the list of endpoints for each group.
The default encoding is an array of
Endpoints Per Group Entry as defined
in Table 93
GroupList
13
14
Table 93: Groups Per Endpoint Entry

Name
Type
Valid Range
Description
GroupAddress
16-bit Integer
0x0000 to 0xffff
ZigBee Group Address associated with

at least an endpoint
EndpointCount
8-bit Integer
0x00 to 0xff
Number of endpoints associated with

the group address
EndpointList
Array of 8-bit
Integer
Variable
List of the endpoints associated with the

group address
15
16
6. 7. 1 4. 1
W hen Inv o k ed
17
18
The GetGroupList procedure is invoked by an IPHA in order to retrieve the list of groups and their
associated group addresses (as defined in [R1] 2.2.8.3) which are set on the ZGD.

Page 73
6. 7. 1 4. 2
2
3
4
5
retrieve the list of group addresses and their associated endpoints from the apsGroupTable attribute in
the AIB of the ZGD (see [R1] Table 2.24) and return a status of SUCCESS. If the number of groups is
0, the GroupList result shall not be supplied.
6
7
6. 7. 1 5 G et B ind ing Li st P ro c e dur e

The GetBindingList procedure shall support the results specified in Table 94.
Table 94: GetBindingList Procedure Results

Name
Status
Type
Valid Range
Description
Status
Enumeration
A Status Code
defined in Table
2
BindingCount
16-bit Integer
0x0000 to 0xffff
Number of entries in BindingList
Default type:
Octet String
Array of
Binding Entry
Variable
List all the bindings on the ZGD. The

default encoding is an array of Binding
Entry as defined in Table 95
BindingList
9
10
Table 95: Binding Entry

Name
Type
Valid Range
Description
SourceAddress
64-bit Integer
ZigBee
Extended
Address
ZigBee 64-bit extended address of the

device which is the source for this
binding
SourceEndpoint
8-bit Integer
0x01 to 0xf0
ZigBee Endpoint which is the source

endpoint for this binding
ClusterID
16-bit Integer
ZigBee Cluster
Identifier
ZigBee cluster identifier use as the

binding link
GroupDestCount
16-bit Integer
0 to 216 -1
Number of group address destinations

for the binding
GroupDestinations
Octet String List

of ZigBee
Group Address
Variable
List of 16-bit group address

destinations for the binding
DeviceDestCount
16-bit Integer
0 to 216 -1
Number of device destinations for the

binding
DeviceDestinations
Octet String List

of Binding
Device
Destination
Entry
Variable
List of device destinations for the

binding. Each entry of the list is
described in Table 96
11
Page 74

Table 96: Binding Device Destination Entry

Name
Type
Valid Range
Description
Address
64-bit Integer
ZigBee
Extended
Address
Extended address of a device which is a

destination for the binding
Endpoint
8-bit Integer
ZigBee
Endpoint
Endpoint on the destination device

which is a destination for the binding
2
3
6. 7. 1 5. 1
W hen Inv o k ed
4
5
The GetBindingList procedure is invoked by an IPHA in order to retrieve the list of ZigBee device
bindings (as defined in [R1] 2.2.8.2) which are set on the ZGD.
6. 7. 1 5. 2
Ef f ec t o n I nv oc at i on
7
8
9
10
11
12
13
retrieve the list of bindings from the apsBindingTable attribute in the AIB of the ZGD (see [R1] Table
2.24), set the BindingCount result with the number of bindings (following the definition of a binding in
[R1] 2.2.8.2), set the BindingList result with the list of bindings and return a status of SUCCESS. If the
number of bindings is 0, the BindingList result shall not be supplied. For a BindingEntry, if the
GroupDestCount field, respectively the DeviceDestCount field is equal to 0, the GroupDestinations
field, respectively the DeviceDestinations field shall not be supplied.
14
6.8
15
The Inter-PAN functions provide access to the INTR-PAN SAP of a ZGD.
Inter-P AN
16
Table 97 Inter-PAN Functions

Function
SendInterPANMessage
17
18
19
O
O
Description
Functions that allow transmission and
reception of Inter-PAN messages.
6. 8. 1 S end I nt er P ANM es s ag e P ro ce du re
The SendInterPANMessage procedure shall support the parameters specified in Table 98 and the

Page 75
Table 98: SendInterPANMessage Procedure Parameters

Name
Status
Type
Valid Range
Timeout
32-bit unsigned
integer
CallbackDestination
Octet string
Variable
SrcAddressMode
Integer
0x03
Description

SourceAddress parameter (see [R1]
Annex B INTRP-DATA.request
SrcAddrMode parameter)
Annex B INTRP-DATA.request
DstAddrMode parameter).
DestinationAddress
Mode
Integer
0x01 0x03
DestinationAddress
16-bit or 64-bit
address
As specified by
the AddrMode
parameter
(see [R1] Annex B INTRPDATA.request DstAddress parameter)
DestPANID
16-bit PAN Id
0x0000 0xffff
(see [R1] Annex B INTRPDATA.request DstPANID parameter)
ProfileID
Integer
0x0000 0xffff
(see [R1] Annex B INTRPDATA.request ProfileId parameter)
ClusterID
Integer
0x0000 0xffff
(see [R1] Annex B INTRPDATA.request ClusterId parameter)
ASDULength
Integer
0x00
(aMaxMACFra
meSize 9)
(see [R1] Annex B INTRPDATA.request ASDULenth parameter)
ASDU
Set of octets
ASDUHandle
Integer
0x00 0xff
(see [R1] Annex B INTRPDATA.request ASDU parameter)

(see [R1] Annex B INTRPDATA.request ASDUHandle
parameter)
2
3
Table 99: SendInterPANMessage Procedure Results

Name
Status
Status
ASDUHandle
ConfirmStatus
Type
Valid Range
Description
Integer
0x00 0xff
(see [R1] Annex B INTRPDATA.confirm ASDUHandle

parameter).
The Status parameter returned by in the
INTRP-DATA.confirm. (see [R1]
INTRP-DATA.confirm Parameters
table).
4
5
Page 76

2
3
The SendInterPANMessage procedure is invoked by an IPHA in order to send an Inter-PAN message

in the ZigBee network and to control the details of the Inter-PAN ASDU from the IPHA.
5
6
7
use the INTRP-DATA.request primitive with the parameters supplied in the procedure. If the required
Inter-PAN stub APS is not supported the ZGD shall return a INTR-SAP-NOT-SUPPORTED Status.
8
9
10
6. 8. 2 Not if yI nt er P ANM es s a ge Ev en t
The NotifyInterPANMessageEvent event handler shall support the parameters specified in Table 100
and the results specified in Table 101.

Page 77
Table 100: NotifyInterPANMessageEvent Event Handler Parameters

Name
Status
RequestIdentifier
Type
Unsigned 32bit integer
Valid Range
0-0xffffffff
Description
Handler then this parameter shall
be supplied and shall match the
identifier of the invoking
Callback Handler. Otherwise this
parameter shall not be supplied.
SrcAddrMode
Integer
0x03
(see [R1] Annex B INTRPDATA.indication parameters)
SrcPANId
16-bit PAN
Id
0x0000
0xffff
SrcAddress
64-bit
address
As specified
by the
SrcAddrMod
e parameter
DstAddrMode
Integer
0x01 0x03
DstAddress
16-bit or 64bit address
As specified
by the
DstAddrMod
e parameter
DstPANID
16-bit PAN
Id
0x0000
0xffff
ProfileID
Integer
0x0000
0xffff
ClusterID
Integer
0x0000
0xffff
ASDULength
Integer
0x00
(aMaxMACF
rameSize - 9)
ASDU
Set of octets
LinkQuality
Integer
0x00 0xff
2
3
Table 101: NotifyInterPANMessageEvent Event Handler Results

Name
Status
Status
M
Type
Valid Range
Description
Page 78

2
3
The NotifyInterPANMessageEvent event handler is invoked by a ZGD in order to send the contents of
a received Inter-PAN message to an IPHA.
5
6
use the INTRP-DATA.indication parameters for the request parameters of the function.
6.9
Netw ork Layer
8
9
10
11
12
The network layer functions provide access to the Network Layer Management Entity (NLME) of the
ZGD, so they permit an IPHA precise control over network discovery, formation, joining, and leaving.
In particular, the SendNWKMessage and NotifyNWKMessageEvent functions allow ZGDs to send and
to receive messages using the NLDE-SAP, and all the other functions closely map to primitives offered
by the NLME-SAP.
13
Table 102 Network Layer Functions

Function
FormNetworkProcedure
FormNetworkEvent
StartRouter
StartRouterEvent
Join
JoinEvent
Leave
LeaveEvent
Reset
ResetEvent
DiscoverNetworks
DiscoverNetworksEvent
PerformEnergyScan
PerformEnergyScanEvent
NetworkStatusEvent
PerformRouteDiscovery
PerformRouteDiscoveryEvent
SendNWKMessage
NotifyNWKMessageEvent
14
15
16
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
Description
Granular functions to form, join, and leave a

ZigBee network.
Allows available ZigBee networks to be

enumerated.
Detects amount of energy on selected
channels.
Indicates status changes in the network layer.
Perform route discovery.
Allows an IPHA to send or receive a NWK
frame.
6. 9. 1 For mN et w or k P ro c ed ur e
The FormNetwork procedure shall support the parameters specified in Table 103 and the results

Page 79
Table 103: FormNetwork Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
CallbackDestination
Octet string
Variable
ScanChannels
Bitmap
32-bit field
(see [R1] NLME-NETWORKFORMATION.request subclause)
ScanDuration
Integer
0x00 0x0e
BeaconOrder
Integer
0x00 0x0f
SuperframeOrder
Integer
0x00 0x0f
BatteryLifeExtension
Boolean
TRUE or
FALSE
2
3
Table 104: FormNetwork Procedure Results and FormNetworkEvent Event Handler Parameters
Name
Status
Type
Valid Range
Description
Status
N/A
N/A
RequestIdentifier
32-bit
unsigned
Integer
Status
INVALID_REQUEST,
STARTUP_FAILURE
or any status value
returned from
the MLMESTART.confirm
primitive
NLME-NETWORKFORMATION.confirm Status
parameter
NWKStatus
4
5
The FormNetwork procedure is invoked by an IPHA to issue a NLME Network Formation Command.
8
9
10
11
12
construct a NLME Network Formation Request using the supplied parameters, and use the NLME-SAP
to send this command. If the ZGD receives from the NLME-SAP a status indicating that the NLME
request has failed, the procedure shall return with a Status equal to NETWORK_FAILURE and
NwkStatus equal to that status code.
13
14
15
If the CallbackDestination parameter was supplied, the ZGD shall report the resulting NLME Network
Formation Confirm primitive to the IPHA through the FormNetworkEvent event handler and including
the same unique identifier value in the RequestIdentifier of the function.
Page 80

1
2
3
4
5
6
7
If the CallbackDestination parameter is not supplied, the procedure shall wait for the resulting NLME
Network Formation Confirm primitive. When the timer that was set elapses, the ZGD shall stop to keep
track of the resulting response and the procedure should return with a Status of TIMEOUT and
NwkStatus parameter shall not be present. If the expected confirm primitive is received from the
NLME-SAP and the status is not SUCCESS, the procedure shall return with a Status equal to
NETWORK_FAILURE and NwkStatus equal that status code. Otherwise if the status is SUCCESS, the
procedure shall return with a Status of SUCCESS and NwkStatus parameter shall not be present.
6. 9. 2 For mN et w or k Ev ent E v ent Ha ndl e r
9
10
The FormNetworkEvent event handler shall support the parameters specified in Table 104, and shall
11
Table 105 FormNetworkEvent Event Handler Results

Name
Status
Status
M
Type
N/A
Valid Range
N/A
Description
12
13
6. 9. 2 .1 Def in it io n of FO RM _NET W O R K _E V E NT
14
15
A FORM_NETWORK_EVENT occurs when the ZGD receives a NLME Network Formation Confirm
primitive and the conditions described in clause 6.9.1.2 are met.
16
17
18
The FormNetworkEvent event handler is invoked by a ZGD upon reception of an event of type
FORM_NETWORK_EVENT.
19
20
The NwkStatus parameter shall be equal to the Status field of the Network Formation Confirm
primitive.
21
22
23
24
25
26
6. 9. 3 St ar t Ro ut e r P r oc edu r e
The StartRouter procedure shall support the parameters specified in Table 106 and the results specified
in Table 107.

Page 81
Table 106: StartRouter Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
CallbackDestination
Octet string
Variable
BeaconOrder
Integer
0x00 0x0f
(see [R1] NLME-STARTROUTER.request subclause)
SuperframeOrder
Integer
0x00 0x0f
BatteryLifeExtension
Boolean
TRUE or
FALSE
2
3
Table 107: StartRouter Procedure Results

Name
Status
Type
Valid Range
Description
Status
N/A
N/A
RequestIdentifier
32-bit
unsigned
Integer
Status
INVALID_REQUEST
or any status value
returned
from the
MLMESTART.
confirm primitive.
NLME-START-ROUTER.confirm
Status parameter
NWKStatus
4
5
The StartRouter procedure is invoked by an IPHA to issue a NLME Network Start Router Command.
8
9
10
11
12
construct a NLME Network Start Router Request using the supplied parameters, and use the NLMESAP to send this command. If the ZGD receives from the NLME-SAP a status indicating that the
NLME request has failed, the procedure shall return with a Status equal to NETWORK_FAILURE and
NwkStatus equal to that status code.
13
14
15
16
17
18
19
Next, the procedure shall wait for the resulting NLME Network Start Router Confirm primitive. When
the timer that was set elapses, the ZGD shall stop to keep track of the resulting response and the
procedure should return with a Status of TIMEOUT and NwkStatus parameter shall not be present. If
the expected confirm primitive is received from the NLME-SAP and the status is not SUCCESS, the
procedure shall return with a Status equal to NETWORK_FAILURE and NwkStatus equal that status
code. Otherwise if the status is SUCCESS, the procedure shall return with a Status of SUCCESS and
NwkStatus parameter shall not be present.
Page 82

6. 9. 4 St ar t Ro ut e r Ev e nt Ev e nt H an dl er
2
3
The StartRouterEvent event handler shall support the parameters specified in Table 106, and shall
Table 108 StartRouterEvent Event Handler Results

Name
Status
Status
M
Type
N/A
Valid Range
N/A
Description
5
6
6. 9. 4 .1 Def in it io n of ST ART _ RO UT E R _E V E NT
7
8
A START_ROUTER_EVENT occurs when the ZGD receives a NLME Network Start Router Confirm
10
11
The StartRouterEvent event handler is invoked by a ZGD upon reception of an event of type
START_ROUTER_EVENT.
12
13
The NwkStatus parameter shall be equal to the Status field of the Network Start Router Confirm
primitive.
14
15
16
17
18
19
20
6. 9. 5 Joi n P ro ce du re
The Join procedure shall support the parameters specified in Table 109 and the results specified in
Table 110.

Page 83
Table 109: Join Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
CallbackDestination
Octet string
Variable
ExtendedPanID
Integer
0x00000000000
00001
0xfffffffffffffffe
(see [R1] NLME-JOIN.request

subclause)
RejoinNetwork
Integer
0x00-0x03

subclause)
ScanChannels
Bitmap
32-bit field

subclause)
ScanDuration
Integer
0x00-0x0e

subclause)
Bitmap
See Table 3.47

in [R1]

subclause)
SecurityEnable
Boolean
TRUE or
FALSE

subclause)
2
3
Table 110: Join Procedure Results and JoinEvent Event Handler Parameters
Name
Status
Type
Valid Range
Description
Status
N/A
N/A
RequestIdentifier
32-bit
unsigned
Integer
Status Status
INVALID_REQUEST,
NOT_PERMITTED,
NO_NETWORKS
or any status value
returned from the
MLMEASSOCIATE.
confirm
primitive or the
MLMESCAN.
confirm primitive.
NLME-JOIN.confirm Status
parameter
NWKStatus
4
5
The Join procedure is invoked by an IPHA to issue a NLME Join Command.
8
9
10
11
12
construct a NLME Join Request using the supplied parameters, and use the NLME-SAP to send this
command. If the ZGD receives from the NLME-SAP a status indicating that the NLME request has
failed, the procedure shall return with a Status equal to NETWORK_FAILURE and NwkStatus equal to
that status code.
Page 84

1
2
3
If the CallbackDestination parameter was supplied, the ZGD shall report the resulting NLME Join
Confirm primitive to the IPHA through the JoinEvent event handler and including the same unique
identifier value in the RequestIdentifier of the function.
4
5
6
7
8
9
10
Join Confirm primitive. When the timer that was set elapses, the ZGD shall stop to keep track of the
resulting response and the procedure should return with a Status of TIMEOUT. If the expected confirm
primitive is received from the NLME-SAP and the status is not SUCCESS, the procedure shall return
with a Status equal to NETWORK_FAILURE and NwkStatus equal to that status code. Otherwise if
the status is SUCCESS, the procedure shall return with a Status of SUCCESS and NwkStatus parameter
shall not be present.
11
6. 9. 6 Joi n Ev ent Ev ent H an dle r
12
13
The JoinNetworkEvent event handler shall support the parameters specified in Table 110, and shall
14
Table 111 JoinEvent Event Handler Results

Name
Status
Status
M
Type
N/A
Valid Range
N/A
Description
15
16
6. 9. 6 .1 Def in it io n of JO I N_ E V ENT
17
18
A JOIN_EVENT occurs when the ZGD receives a NLME Join Confirm primitive and the conditions
described in clause 6.9.5.2 are met.
19
20
The JoinEvent event handler is invoked by a ZGD upon reception of an event of type JOIN_EVENT.
21
The NwkStatus parameter shall be equal to the Status field of the Join Confirm primitive.
22
23
24
25
26
27
6. 9. 7 Le av e P ro c edu r e
The Leave procedure shall support the parameters specified in Table 112 and the results specified in
Table 113.

Page 85
Table 112: Leave Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
CallbackDestination
The NLME-LEAVE.request
command frame is sent to this
address.
Address
DeviceAddress
(see [R1] NLME-LEAVE.request

sub-clause)
RemoveChildren
Boolean

sub-clause)
Rejoin
Boolean

sub-clause)
2
3
Table 113: Leave Procedure Results and Leave Event Handler Parameters
Name
Status
Status
RequestIdentifier
NWKStatus
Type
N/A
Valid Range
N/A
Description
Status
INVALID_REQUEST,
UNKNOWN_DEVICE,
or any status value
returned from the
MCPS-DATA.confirm
primitive.
NLME-LEAVE.confirm
Status parameter
4
5
The Leave procedure is invoked by an IPHA to issue a NLME-LEAVE.request command.
8
9
10
construct a NLME-LEAVE.request command frame using the supplied parameters, and use the
NLME-SAP to send this command.
11
12
13
If the CallbackDestination parameter was supplied, the ZGD shall report the resulting NLME Leave
command to the IPHA through the LeaveEvent event handler and including the same unique identifier
value in the RequestIdentifier of the function.
14
15
16
17
18
19
20
Leave command. When the timer that was set elapses, the ZGD shall stop to keep track of the resulting
response and the procedure should return with a Status of TIMEOUT. If the expected response
command is received from the NLME-SAP and the status is not SUCCESS, the procedure shall return
with a Status equal to NETWORK_FAILURE and NWKStatus equal to that status code. Otherwise if
the status is SUCCESS, the procedure shall return with a Status of SUCCESS and NWKStatus
parameter shall not be present.
Page 86

6. 9. 8 Le av e Ev e nt Ev e nt Ha ndl er
2
3
The LeaveEvent event handler shall support the parameters specified inTable 57 Table 112 along with
RequestIdentifier, and shall support the results specified in Table 114.
Table 114 LeaveEvent Event Handler Results

Name
Status
Status
Type
Valid Range
Description
5
6
6. 9. 8 .1 Def in it io n of L E AV E _ E V ENT
7
8
A LEAVE_EVENT occurs when the ZGD receives a NLME Leave Confirm command and the
conditions described in clause 6.4.26.2 are met.
10
11
The LeaveEvent event handler is invoked by a ZGD upon reception of an event of type
LEAVE_EVENT.
12
The NwkStatus parameter shall be equal to the Status field of the Leave Confirm command.
13
14
15
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA shall
16
6. 9. 9 Di sc ov e rN et w or k s P r oc edu r e
17
18
The DiscoverNetworks procedure shall support the parameters specified in Table 115 and the results
19
Table 115: DiscoverNetworks Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
CallbackDestination
Octet string
Variable
ScanChannels
Bitmap
32-bit field
(see [R1] NLME-NETWORKDISCOVERY.request subclause)
ScanDuration
Integer
0x00 0x0e
(see [R1] NLME-NETWORKDISCOVERY.request subclause)
20

Page 87
1
2
Table 116: DiscoverNetworks Procedure Results and DiscoverNetworksEvent Event Handler

Parameters
Name
Status
Status
M
Type
Valid Range
Description
N/A
N/A
NLME-NETWORKDISCOVERY.confirm Status
parameter
NWKStatus
Status
Any status
value returned
with the
MLMESCAN.
confirm
primitive.
RequestIdentifier
32-bit unsigned
Integer
NetworkCount
Integer
0x00 0xff
(see [R1] NLME-NETWORKDISCOVERY.confirm subclause)
The list
contains the
number of
elements given
by the
NetworkCount
parameter
(see [R1] NLME-NETWORKDISCOVERY.confirm subclause)
NetworkDescriptorList
List of
network
descriptors
3
4
5
6
The DiscoverNetworks procedure is invoked by an IPHA to issue a NLME Network Discovery

Command.
8
9
10
11
12
construct a NLME Network Discovery Request using the supplied parameters, and use the NLME-SAP
to send this command. If the ZGD receives from the NLME-SAP a status indicating that the NLME
request has failed, the procedure shall return with a Status equal to NETWORK_FAILURE and
NwkStatus equal to that status code, NetworkCount set to zero and an empty NetworkDiscriptorList.
13
14
15
If the CallbackDestination parameter was supplied, the ZGD shall report the resulting NLME Network
Discovery Confirm primitive to the IPHA through the NetworkDiscoveryEvent event handler and
including the same unique identifier value in the RequestIdentifier of the function.
16
17
18
19
20
21
22
23
24
25
Network Discovery Confirm primitive. When the timer that was set elapses, the ZGD shall stop to keep
track of the resulting response and the procedure should return with a Status of TIMEOUT and
NwkStatus parameter shall not be present, NetworkCount set to zero and an empty
NetworkDescriptorList. If the expected confirm primitive is received from the NLME-SAP and the
status is not SUCCESS, the procedure shall return with a Status equal to NETWORK_FAILURE and
NwkStatus equal to that status code, NetworkCount set to zero and an empty NetworkDesctiptorList.
Otherwise if the status is SUCCESS, the procedure shall return with a Status of SUCCESS, the
NetworkCount and NetworkDescriptorList parameters shall be equal to the corresponding Network
Descriptor Confirm parameters and NwkStatus parameter shall not be present.
Page 88

6. 9. 1 0 Di sc ov e rN et w o r k sEv ent Ev ent H and le r
2
3
The DiscoverNetworksEvent event handler shall support the parameters specified in Table 116, and
Table 117 DiscoverNetworksEvent Event Handler Results

Name
Status
Status
Type
N/A
Valid Range
N/A
Description
5
6
6. 9. 1 0. 1
Def in it io n of D I SCO V ER _ N ET W O RK S _ EV E NT
7
8
A DISCOVER_NETWORKS_EVENT occurs when the ZGD receives a NLME Network Discovery

Confirm primitive and the conditions described in clause 6.9.9.2 are met.
6. 9. 1 0. 2
W hen Inv o k ed
10
11
The DiscoverNetworksEvent event handler is invoked by a ZGD upon reception of an event of type
DISCOVER_NETWORKS_EVENT.
12
13
14
15
16
17
If the status of the Discovery Networks Confirm primitive is not SUCCESS, the Status equal to
NETWORK_FAILURE and NwkStatus parameter shall be equal to that status code, NetworkCount
shall be set to zero and the NetworkDesctiptorList shall be empty. Otherwise if the status is SUCCESS,
the Status parameter shall be set to SUCCESS, the NetworkCount and NetworkDescriptorList
parameters shall be equal to the corresponding Discover Networks Confirm primitive and NwkStatus
parameter shall not be present.
18
6. 9. 1 0. 3
19
20
21
6. 9. 1 1 Re s et P ro ce du re
22
23
The Reset procedure shall support the parameters specified in Table 118 and the results specified in
Table 119.
24
Table 118: Reset Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
CallbackDestination
Octet string
Variable
WarmStart
Boolean
TRUE or
FALSE
(see [R1] NLME-RESET.request

subclause)
25

Page 89
Table 119: Reset Procedure Results

Name
Status
Status
M
NWKStatus
Type
Valid Range
Description
N/A
N/A
Status
Any status value

returned
from the
MLMERESET.
confirm
primitive
(see [B1])
NLME-RESET.confirm Status
parameter
2
3
6. 9. 1 1. 1
W hen Inv o k ed
The Reset procedure is invoked by an IPHA to issue a NLME Reset Command.
6. 9. 1 1. 2
6
7
8
9
10
construct a NLME Reset Request using the supplied parameters, and use the NLME-SAP to send this
command. If the ZGD receives from the NLME-SAP a status indicating that the NLME request has
that status code.
11
12
13
14
15
16
Next, the procedure shall wait for the resulting NLME Network Reset Confirm primitive. When the
timer that was set elapses, the ZGD shall stop to keep track of the resulting response and the procedure
should return with a Status of TIMEOUT. If the expected confirm primitive is received from the
NLME-SAP and the status is not SUCCESS, the procedure shall return with a Status equal to
NETWORK_FAILURE and NwkStatus equal that status code. Otherwise if the status is SUCCESS, the
procedure shall return with a Status of SUCCESS and NwkStatus parameter shall not be present.
17
6. 9. 1 2 Re s et Ev e nt Ha ndl e r
18
19
The ResetEvent event handler shall support the parameters specified in Table 119, and shall support the
20
Table 120 ResetEvent Event Handler Results

Name
Status
Status
M
Type
N/A
Valid Range
N/A
Description
21
22
6. 9. 1 2. 1
23
24
A RESET_EVENT occurs when the ZGD receives a NLME Reset Confirm primitive and the
conditions described in clause 6.9.11.2 are met.
25
6. 9. 1 2. 2
26
27
The ResetEvent event handler is invoked by a ZGD upon reception of an event of type
RESET_EVENT.
Page 90
Def in it io n of R E S ET _ E V ENT
W hen Inv o k ed

The NwkStatus parameter shall be equal to the Status field of the Reset Confirm primitive.
6. 9. 1 2. 3
3
4
6. 9. 1 3 P erf or m En e rg yS c an P ro ce du re
6
7
The PerformEnergyScan procedure shall support the parameters specified in Table 121 and the results
Table 121: PerformEnergyScan Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
CallbackDestination
Octet string
Variable
ScanChannels
Bitmap
32-bit field
(see [R1] NLME-ED-SCAN.request

subclause)
ScanDuration
Integer
0x00-0x0e
(see [R1] NLME-ED-SCAN.request

subclause)
9
10
11
Table 122: PerformEnergyScan Procedure Results and PerformEnergyScanEvent Event Handler

Parameters
Name
Status
Status
Type
Valid Range
Description
N/A
N/A

NLME-ED-SCAN.confirm Status
parameter
NWKStatus
Status
SUCCESS,
or any valid
code from
the MAC
RequestIdentifier
32-bit unsigned
Integer
ScannedChannels
EnergyDetectList
(see [R1] NLME-EDSCAN.confirm subclause)

List of 8-bit
Integers
0x00 to 0xff
A list of energy measurements for

each channel provided in the
ScannedChannels mask.
12
13
6. 9. 1 3. 1
W hen Inv o k ed
14
The PerformEnergyScan procedure is invoked by an IPHA to issue a NLME ED Scan Command.

Page 91
6. 9. 1 3. 2
2
3
4
5
6
construct a NLME ED Scan Request using the supplied parameters, and use the NLME-SAP to send
this command. If the ZGD receives from the NLME-SAP a status indicating that the NLME request has
that status code, ScannedChannels set to zero and an empty EnergyDetectList.
7
8
9
If the CallbackDestination parameter was supplied, the ZGD shall report the resulting NLME ED Scan
Confirm primitive to the IPHA through the PerformEnergyScanEvent event handler and including the
same unique identifier value in the RequestIdentifier of the function.
10
11
12
13
14
15
16
17
18
19
20
ED Scan Confirm primitive. When the timer that was set elapses, the ZGD shall stop to keep track of
the resulting response and the procedure should return with a Status of TIMEOUT, ScannedChannels
set to zero, an empty EnergyDetectList and NwkStatus parameter shall not be present. If the expected
confirm primitive is received from the NLME-SAP and the status is not SUCCESS, the procedure shall
return with a Status equal to NETWORK_FAILURE and NwkStatus equal to that status code,
ScannedChannels set to zero and an empty EnergyDetectList. Otherwise if the status is SUCCESS, the
procedure shall return with a Status of SUCCESS, the EnergyDetectList parameters shall be equal to
the Energy Detect List and the ScannedChannels parameter equal to the expression (ScanChannel
AND NOT UnscannedChannels) built from the ScanChannel procedure parameter and Unscanned
Channel ED Scan Confirm parameter and NwkStatus parameter shall not be present.
21
6. 9. 1 4 P erf or m En e rg yS c an E v ent Ev e nt Ha ndl e r
22
23
The PerformEnergyScanEvent event handler shall support the parameters specified in Table 122, and
24
Table 123 PerformEnergyScanEvent Event Handler Results

Name
Status
Status
M
Type
N/A
Valid Range
N/A
Description
25
26
6. 9. 1 4. 1
27
28
A PERFORM_ENERGY_SCAN_EVENT occurs when the ZGD receives a NLME ED Scan Confirm

29
6. 9. 1 4. 2
30
31
The PerformEnergyScanEvent event handler is invoked by a ZGD upon reception of an event of type
PERFORM_ENERGY_SCAN_EVENT.
32
33
34
35
36
37
38
39
If the status of the ED Scan Confirm primitive is not SUCCESS, the Status equal to
NETWORK_FAILURE and NwkStatus parameter shall be equal to that status code, ScannedChannels
shall be set to zero and the EnergyDetectList shall be empty. Otherwise if the status is SUCCESS, the
Status parameter shall be set to SUCCESS, the EnergyDetectList parameters shall be equal to the
Energy Detect List and the ScannedChannels parameter equal to the expression (ScanChannel AND
NOT UnscannedChannels) built from the ScanChannel parameter of the initial PerformEnergyScan
procedure and Unscanned Channel ED Scan Confirm parameter and NwkStatus parameter shall not be
present.
Page 92
Def in it io n of P ERF O R M _EN ERG Y _ S C AN _ E V ENT
W hen Inv o k ed

6. 9. 1 4. 3
2
3
6. 9. 1 5 Net w or k St at u s Ev ent Ev e nt Ha ndl e r
5
6
The NetworkStatusEvent event handler shall support the parameters specified in Table 27, and shall
Table 124: NetworkStatusEvent Event Handler Parameters

Name
Status
Status
M
Type
Valid Range
Description
N/A
N/A

NLME-NWK-STATUS.indication
Status parameter
(see [R1] NLME-NWKSTATUS.indication subclause)
NWKStatus
Status
Any network
status code (see
Table 3.42 in
R[1])
NetworkAddr
Integer
0x0000 0xfff7
8
9
Table 125: NetworkStatusEvent Event Handler Results

Name
Status
Status
M
Type
N/A
Valid Range
N/A
Description
10
11
6. 9. 1 5. 1
12
13
A NETWORK_STATUS_EVENT occurs when the ZGD receives a NLME NWK Status Indication
primitive.
14
6. 9. 1 5. 2
15
16
The NetworkStatusEvent event handler is invoked by a ZGD upon reception of an event of type
NETWORK_STATUS_EVENT.
17
18
19
The NwkStatus result shall be equal to the Status parameter of the NWK Status Indication parameter,
and the NetworkAddr parameter shall be equal to the corresponding parameters of the NWK Status
Indication primitive.
20
6. 9. 1 5. 3
21
22
23
24
25
Def in it io n of N ET W O RK _ ST AT U S _ E V ENT
W hen Inv o k ed
6. 9. 1 6 P erf or mR out eD is cov er y P r oc edu r e

The PerformRouteDiscovery procedure shall support the parameters specified in Table 126 and the
Page 93
Table 126: PerformRouteDiscovery Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
CallbackDestination
Octet string
Variable
DstAddrMode
Integer
0x00 0x02
(see [R1] NLME-ROUTEDISCOVERY.request subclause)
DstAddr
16-bit
network
address
Any network
address or
multicast
address
Radius
Integer
0x00 0xff
NoRouteCache
Boolean
TRUE or
FALSE
2
3
4
Table 127: PerformRouteDiscovery Procedure Results and PerformRouteDiscoveryEvent Event

Handler Parameters
Name
Status
Type
Valid Range
Description
Status
N/A
N/A
RequestIdentifier
32-bit
unsigned
Integer
NLME-ROUTEDISCOVERY.confirm Status
parameter
(see [R1] NLME-ROUTEDISCOVERY.confirm

subclause)
NWKStatus
status value
INVALID_REQUEST,
ROUTE_ERROR or
any status
value returned by the
MCPSDATA.
confirm primitive
NetworkStatusCode
Network
status code
See Table 3.42 in [R1]
5
6
6. 9. 1 6. 1
W hen Inv o k ed
7
8
The PerformRouteDiscovery procedure is invoked by an IPHA to issue a NLME Route Discovery

Command.
6. 9. 1 6. 2
10
11
12
13
14
construct a NLME Network Route Discovery Request using the supplied parameters, and use the
NLME-SAP to send this command. If the ZGD receives from the NLME-SAP a status indicating that
the NLME request has failed, the procedure shall return with a Status equal to NETWORK_FAILURE
and NwkStatus equal that status code, and no NetworkStatusCode result.
15
16
17
If the CallbackDestination parameter was supplied, the ZGD shall report the resulting NLME Route
Discovery Confirm primitive to the IPHA through the RouteDiscoveryEvent event handler and
including the same unique identifier value in the RequestIdentifier of the function.
Page 94

1
2
3
4
5
6
7
8
9
10
11
Route Discovery Confirm primitive. When the timer that was set elapses, the ZGD shall stop to keep
track of the resulting response and the procedure should return with a Status of TIMEOUT, and no
NetworkStatusCode result. If the expected confirm primitive is received from the NLME-SAP and the
status is ROUTE_ERROR, the procedure shall return with the Status equal to NETWORK_FAILURE,
NwkStatus parameter equal to ROUTE_ERROR, and NetworkStatusCode equal to the corresponding
Route Discovery Confirm primitive. Otherwise, if Status is different from SUCCESS, the procedure
shall return with the Status result equal to NETWORK_FAILURE and the NwkParameter set to the
Status parameter. Finally, if Status is SUCCESS, the procedure shall return with a Status equal to the
SUCCESS and no NetworkStatusCode nor NwkStatus results.
6. 9. 1 7 P erf o r mR out eD is cov er y Ev ent H and l er
12
13
The PerformRouteDiscoveryEvent event handler shall support the parameters specified in Table 127,
and shall support the results specified in Table 128.
14
Table 128 PerformRouteDiscoveryEvent Event Handler Results

Name
Status
Status
M
Type
N/A
Valid Range
N/A
Description
15
16
6. 9. 1 7. 1
17
18
A PERFORM_ROUTE_DISCOVERY_EVENT occurs when the ZGD receives a NLME Route

Discovery Confirm primitive and the conditions described in clause 3.2.2.32 in [R1] are met.
19
6. 9. 1 7. 2
20
21
The PerformRouteDiscoveryEvent event handler is invoked by a ZGD upon reception of an event of

type PERFORM_ROUTE_DISCOVERY_EVENT.
22
23
24
25
26
If the status of the Route Discovery Confirm primitive is not ROUTE_ERROR, the Status shall be
equal to NETWORK_FAILURE and NwkStatus parameter shall be equal to that status code,
NetworkStatusCode equal to the corresponding Route Discovery Confirm primitive. Otherwise the
Status parameter shall be set to the Route Discovery Confirm Parameter and the NetworksStatusCode
parameter and NwkStatus parameters shall not be present.
27
6. 9. 1 7. 3
28
29
30
31
32
Def in it io n of P ERF O R M _RO UT E_ DI S CO V ER Y _ EV E NT
W hen Inv o k ed
6. 9. 1 8 S end NW KM es s ag e P r oc edu r e
The SendNWKMessage procedure shall support the parameters specified in Table 129 and the results

Page 95
Table 129: SendNWKMessage Procedure Parameters

Name
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
CallbackDestination
Octet string
Variable
DestinationAddress
Mode
Integer
0x01 or 0x02
(see [R1] NLDE-DATA.request

Parameters table)
DestinationAddress
16-bit
Address
0x0000-0xffff

Parameters table)
aMaxMACFram
eSize (nwkcMACFra
m
eOverhead +
nwkcMinHeader
Overhead)
Integer

Parameters table)
NsduLength
Nsdu
Set of
Octets

Parameters table)
NsduHandle
Integer
0x00 0xFF

Parameters table)
Radius
Unsigned
Integer
0x00 0xFF

Parameters table)
NonmemberRadius
Integer
0x00 0x07

Parameters table)
DiscoverRoute
Integer
0x00 0x01

Parameters table)
SecurityUse
Boolean
TRUE or
FALSE
(see [R1] NLE-DATA.indication

Parameters table)
2
3
Table 130: SendNWKMessage Procedure Results

Name
Status
Status
M
Type
Valid Range
Description
N/A
N/A
NLE-DATA.confirm Status
parameter.
NWKStatus
Status
INVALID_REQUEST,
MAX_FRM_COUNTER,
NO_KEY,
BAD_CCM_OUTPUT,
ROUTE_ERROR,
BT_TABLE_FULL,
FRAME_NOT_BUFFERED
or any status values returned
from security suite or the
MCPS-DATA.confirm
primitive (see [B1])
NsduHandle
Integer
0x00 0xff
(see [R1] NLE-DATA.confirm

Parameters table)
TxTime
Integer
Implementation specific
(see [R1] NLE-DATA.confirm

Parameters table)
Page 96

6. 9. 1 8. 1
2
3
The SendNWKMessage procedure is invoked by an IPHA in order to send a NWK message in the
ZigBee network and to control the details of the NSDU from the IPHA.
6. 9. 1 8. 2
5
6
7
8
9
10
11
12
13
14
15
W hen Inv o k ed
use the NLE-DATA.request primitive with the parameters supplied in the procedure and return the
results retrieved from the NLE-DATA.confirm succeeding to the NLE-DATA.request primitive call.
If the NLE-DATA.confirm returns a Status value equal to SUCCESS, then the SendNWKMessage
procedure shall return a Status of success.
If the NLE-DATA.confirm returns a Status value different from SUCCESS, then the
SendNWKMessage procedure shall return a Status equal to NETWORK_FAILURE and report its
contents in the NwkStatus reults
6. 9. 1 9 Not if yN W KM es s ag eE v ent Ev e nt Ha ndl e r
The NotifyNWKMessageEvent event handler shall support the parameters specified in Table 131 and
the results specified in Table 132.

Page 97
Table 131: NotifyNWKMessageEvent Event Handler Parameters

Name
Status
Type
Valid Range
Description
Status
N/A
N/A
RequestIdentifier
32-bit
unsigned
Integer
DstAddrMode
Integer
0x01 or 0x02
(see [R1] NLEDATA.indication Parameters

table)
DstAddr
0x0000-0xffff

table)
SrcAddr
Any valid device address

except a broadcast address

table)
table)
16-bit
Address
16-bit
Device
address
NsduLength
Integer
< aMaxMACFrameSize
(nwkcMACFrameOverhea
d+
nwkcMinHeaderOverhead)
Nsdu
Set of octets

table)
LinkQuality
Integer
0x00 0xff

table)
RxTime
Integer
Implementation specific

table)
SecurityUse
Boolean
TRUE or FALSE

table)
2
3
Table 132 NotifyZDPEvent Event Handler Results

Name
Status
Status
M
Type
N/A
Valid Range
N/A
Description
6. 9. 1 9. 1
W hen Inv o k ed
5
6
The NotifyNWKMessageEvent event handler is invoked by a ZGD in order to send the contents of a
received NWK message to an IPHA.
6. 9. 1 9. 2
8
9
use the NLE-DATA.indication parameters for the request parameters of the function.
10
Page 98

7.1
Secured Connection Protocol ( ScoP)

General Description
7. 1. 1 SC o P L a ye r O v e rv i ew
4
5
6
7
8
9
10
11
12
13
14
The Secured Connection Protocol (SCoP) is an adaptation layer on top of miscellaneous transport
protocols available over the Internet Protocol such as UDP, TCP and TLS, for the purpose of managing
interconnections between remote entities which are both connected to an IP network. Initially SCoP
was designed to exchange ZigBee frames over IP in the scope of the ZigBee Bridge Device. It was then
extended to the ZigBee Gateway Device and designed in a more generic manner so that it could also be
used for many applications even beyond the scope of ZigBee devices. The SCoP layer is designed to be
a generic IP transport layer for any kind of interconnection over IP so that the underlying mechanisms
such as connections, security and management remain consistent regardless of the intended
interconnection. The main function of the SCoP layer is to provide a generic upper layer encapsulation
point with datagram and stream transport modes and security services. In addition the SCoP layer is
designed to support fragmentation.
15
7. 1. 1 .1 SC o P Dat a E nt it y ( SC DE )
16
The SCoP layer data entity provides the data transmission service via its SAP, the SCDE-SAP.
17
7. 1. 1 .2 SC o P M ana ge m ent E n tit y ( S CM E)
18
19
The SCoP layer management entity provides the ScoP management service (connection management
service and information base maintenance) via its SAP, the SCME-SAP.
20
7. 1. 1 .3 SC o P S ec ur it y S e rv ic e ( S Co S S)
21
22
A SCoP security service is provided for encryption, authentication and integrity check of the SCoP
communications.
23
7. 1. 2 IP R out i ng
24
25
26
The SCoP layer operates as a typical IP application protocol and therefore relies on routing from the
TCP/IP stack. SCoP frames are passed to the UDP or TCP layers with either unicast or broadcast
addresses as requested by the originator of the SCoP frames.
27
7.2
28
Figure 5 depicts the components and interface of the SCoP layer.
Services Specificat ion

Page 99

SCDE-SAP
SCME-SAP
SCDE
SCME
TCP
UDP
Internet Protocol
1
2
Figure 5: The SCoP Layer Reference Model
3
4
5
The Table 133 lists the primitives supported by the SCDE-SAP and the SCME-SAP and the subclauses in which the primitives are discussed.
Table 133: SCDE-SAP and SCME-SAP primitives
Name
SCME-OPEN
SCME-CLOSE
SCME-LISTEN
SCME-GET
SCME-SET
SCDE-DATA
Request
7.2.1.1.1
7.2.1.1.4
7.2.1.1.7
7.2.1.2.1
7.2.1.2.3
7.2.2.1
Indication
7.2.1.1.2
7.2.1.1.5
Response
7.2.2.2
Confirm
7.2.1.1.3
7.2.1.1.6
7.2.1.1.8
7.2.1.2.2
7.2.1.2.4
7.2.2.3
7
8
7. 2. 1 SC o P M ana ge me nt S erv ic e
9
10
7. 2. 1 .1 So c ket M anag e men t P ri mit iv e s
11
12
13
14
15
16
SCME-SAP open, close and listen primitives control the establishment of communications between
SCoP transport enabled entities.
ZGD and ZBD shall provide for SCoP layer communication establishment per the over the wire and
state machine specifications, however, the SAP interface defined here is for reference only and is not
intended to define implementation.
17
7. 2. 1 .1 .1 SCM E- O P E N. r equ e st
18
19
The SCME-OPEN.request primitive requests the SCoP layer to establish a communication path with
a peer entity.
20
7. 2. 1 .1 .1 . 1
21
The semantics of the service primitive are as follows:
S em ant ic s of th e s er v i c e pr im it i ve
SCME-OPEN.request {
22
23
24
25
26
27
IPVersion,
IPAddress,
Port,
TransportMode,
SecurityLevel
Page 100

1
2
3
The table below specifies the parameters of the SCME-OPEN.request primitive.
Table 134: SCME-OPEN.request Parameters

Name
Type
Valid Range
Description
IPversion
Octet
0x00 to 0x01
IP version
0x00 : IPv4
0x01 : IPv6
IPAddress
IP
Address
0.0.0.0 to 255.255.255.255 (IPv4)

or
0000:0000:0000:0000:0000:0000:0000:0000
to
ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff (IPv6)
IP address of the peer entity

with which the connection is to
be open
Port
IP port
1 to 65535
Port of the peer entity with

which the connection is to be
open
TransportMode
Octet
0x00 to 0x02
A valid SCoP transport mode

among the values defined in
Table 153 to use for the
connection
SecurityLevel
Octet
0x00 to 0x07
A valid CCM* security level

among the values defined in
Table 150 to use for the
connection
5
6
7. 2. 1 .1 .1 . 2
W hen g e ner a te d
7
8
The primitive is called by the NHLE and issued to the SCoP layer when the NHLE wants to open a
communication with a peer entity.
7. 2. 1 .1 .1 . 3
Ef f ec t of r ec e ip t
10
11
When the SCoP Layer receives the SCME-OPEN.request primitive, the request parameters are used
to establish the appropriate transport mode and security level connection to the requested IP peer.
12
13
14
15
If the connection is already open, the SCoP layer shall issue the SCME-OPEN.confirm primitive with
the same IPAddress, Port, TransportMode and SecurityLevel parameters as in the request and set the
Handle parameter to the value representing the existing connection. The Status parameter shall be set to
ALREADY_CONNECTED.
16
17
18
19
20
21
22
23
24
25
26
27
If the connection cannot be open, the SCoP layer shall issue the SCME-OPEN.confirm primitive with
the same IPAddress, Port, TransportMode and SecurityLevel parameters as in the request and a value
of 0 for the Handle parameter. If the IP address or port is invalid the Status parameter shall be set to
INVALID_DESTINATION. If the TransportMode specified is not supported the Status parameter shall
be set to UNSUPPORTED_TRANSPORT. If the TransportMode has a value of 0x01 and the TCP
connection cannot be established the Status parameter shall be set to TCP_CNX_FAILED. If the
TransportMode has a value of 0x02 and the TLS connection cannot be established the Status parameter
shall be set to TLS_CNX_FAILED. If the SCoP handshake defined for the connection establishment
fails, the Status parameter shall be set to HANDSHAKE_FAILED. If the SecurityLevel requested is
not supported or if an error occurs when processing the security service, the Status parameter shall be
set to SECURITY_FAILED. If the security material is not found in the SCIB to process the request, the
Status parameter shall be set to NO_KEY.

Page 101
1
2
3
4
Otherwise if the connection is open successfully, the SCoP layer shall issue the SCME-OPEN.confirm
primitive with the same IPAddress, Port, TransportMode and SecurityLevel parameters as in the
request and the Handle parameter shall be set to a unique value representing the connection. The Status
parameter shall be set to SUCCESS.
7. 2. 1 .1 .2 SCM E- O P E N. ind ic at i on
6
7
The SCME-OPEN.indication is generated by the SCoP layer to indicate to the NHLE that a
connection has been established on demand from a peer entity.
7. 2. 1 .1 .2 . 1

SCDE-OPEN.indication
10
11
12
13
14
15
16
17
18
19
{
Handle,
IPVersion,
IPAddress,
Port,
TransportMode,
SecurityLevel
}
The table below specifies the parameters of the SCME-OPEN.indication primitive.
20
Table 135: SCME-OPEN.indication Parameters

Name
Type
Valid Range
Description
Handle
unsigned
32 bit
integer
0 to 232 -1
Identifier of the SCoP

connection that has
been opened upon
request from a SCoP
peer entity.
IPversion
Octet
0x00 to 0x01
IP version
0x00 : IPv4
0x01 : IPv6
IPAddress
IP Address
0.0.0.0 to 255.255.255.255 (IPv4)

or
0000:0000:0000:0000:0000:0000:0000:0000
to
IP address of the peer

entity that requested the
connection
Port
IP port
1 to 65535
Port of the peer entity
TransportMode
Octet
0x00 to 0x02
Transport mode of the

connection. A valid
SCoP transport mode
among the values
defined in Table 153
SecurityLevel
Octet
0x00 to 0x07
Security level of the

connection. A valid
CCM* security level
among the values
defined in Table 150
21
22
7. 2. 1 .1 .2 . 2
Page 102

1
2
The SCDE-OPEN.indication primitive is generated by the SCoP Layer and issued to the NHLE when
a connection has been opened on demand by a peer entity.
3
4
7. 2. 1 .1 .2 . 3 Ef f ec t of r ec e ip t
The parameters of the connection that has been opened are transmitted to the NHLE.
7. 2. 1 .1 .3 SCM E- O P E N. conf i rm
6
7
The SCME-OPEN.confirm primitive reports the status of the SCME-OPEN request to the next higher
layer.
7. 2. 1 .1 .3 . 1
10
11
12
13
14
15
16
17
18
19
20
SCME-OPEN.confirm {
Status
Handle,
IPVersion,
IPAddress,
Port,
TransportMode,
SecurityLevel
}
The table below specifies the parameters of the SCME-OPEN.confirm primitive.

Page 103
Table 136: SCME-OPEN.confirm Parameters

Name
Type
Status
Valid Range
Description
unsigned
16 bit
integer
0 to 65535
Status of the connection that has been

requested to be open.
Handle
unsigned
32 bit
integer
0 to 232 -1
Identifier of the SCoP connection if the

connection is successful otherwise this
parameter shall be ignored
IPversion
Octet
0x00 to 0x01
IP version
0x00 : IPv4
0x01 : IPv6
IPAddress
IP Address
0.0.0.0 to 255.255.255.255(IPv4)
or
0000:0000:0000:0000:0000:0000:0000:0
000
to
IP address of the peer entity for this

connection
Port
IP port
1 to 65535
Port of the peer entity for this connection
TransportMode
Octet
0x00 to 0x02
Connection transport mode. A valid SCoP

transport mode among the values defined
in Table 153
SecurityLevel
Octet
0x00 to 0x07
Connection security level. A valid CCM*

security level among the values defined in
Table 150
The possible values are SUCCESS,

ALREADY_CONNECTED,
INVALID_DESTINATION,
INVALID_ADDRESS,
UNSUPPORTED_TRANSPORT,
TCP_CNX_FAILED,
TLS_CNX_FAILED,
HANDSHAKE_FAILED, NO_KEY,
SECURITY_FAILED ,which are defined
in Table 160.
2
3
4
5
6
7. 2. 1 .1 .3 . 2 W hen g e ner a te d
The primitive is generated by the SCoP Layer and issued to the NHLE when a connection with a peer
entity has been established in response to a SCME-OPEN.request primitive.
7
8
9
The handler to the connection that has been opened is transmitted to the NHLE with the status of this
connection.
10
7. 2. 1 .1 .4 SCM E- CLO S E. r equ e s t
11
12
The SCME-CLOSE.request primitive requests the SCoP layer to close a connection with a peer
entity.
13
7. 2. 1 .1 .4 . 1
14
SCME-CLOSE.request
15
16
Page 104
{
Handle

1
2
3
The table below specifies the parameters of the SCME-CLOSE.request primitive.
Table 137: SCME-CLOSE.request Parameters

Name
Handle
Type
unsigned
32 bit
integer
Valid Range
0 to 232 -1
Description
Identifier of an open SCoP connection
5
6
7
8
7. 2. 1 .1 .4 . 2 W hen g e ner a te d
The primitive is generated by the NHLE and issued to the SCoP layer to close a connection with a peer
entity.
9
10
11
12
13
14
15
16
The connection identified by the parameters is closed and the handle is freed from any association with
a SCoP connection. The SCoP layer shall issue the SCME-CLOSE.confirm primitive with the same
Handle parameter as in the request and a Status parameter set to SUCCESS if the connection
termination was performed as described in this specification. If the termination of the connection has
been forced without respect to normal operations described in this specification, the Status parameter
shall be set to the relevant error status as specified in the functional description of the connection
termination.
17
7. 2. 1 .1 .5 SCM E- CLO S E. ind i cat ion
18
19
The SCME-CLOSE.indication primitive is generated by the SCoP layer to indicate that a connection
with a peer entity has been closed.
20
7. 2. 1 .1 .5 . 1
21

SCME-CLOSE.indication
22
23
24
25
26
27
{
Handle,
Status
}
The table below specifies the parameters of the SCME-CLOSE.indication primitive.
28
Table 138: SCME-CLOSE.indication Parameters

Name
Type
Valid Range
32
Description
Handle
unsigned 32
bit integer
0 to2 -1
Identifier of a SCoP connection that has been closed
Status
unsigned 16
bit integer
0 to 65535
Status of termination of the connection.The possible

values are SUCCESS, TERMINATION_FORCED,
ABNORMAL_TERMINATION which are defined
in Table 160.
29
30
7. 2. 1 .1 .5 . 2
Page 105
The primitive is generated by the SCoP layer to indicate the closing a SCoP connection.
2
3
The Status parameter shall be set to the relevant error status as specified in the functional description of
the connection termination.
7. 2. 1 .1 .5 . 3
The handle to the connection that has been closed is transmitted to the NHLE.
7. 2. 1 .1 .6 SCM E- CLO S E. co nf i r m
The SCME-CLOSE.confirm primitive reports the status of the SCME-CLOSE.request to the NHLE.
7. 2. 1 .1 .6 . 1
SCME-CLOSE.confirm
10
11
12
13
14
15
{
Handle,
Status
}
The table below specifies the parameters of the SCME-CLOSE.confirm primitive.
16
Table 139: SCME-CLOSE.confirm Parameters

Name
Type
Valid Range
32
Description
Handle
unsigned 32
bit integer
0 to 2 -1
Identifier of the SCoP connection that has been

requested to be closed
Status
unsigned 16
bit integer
0 to 65535
Status of termination of the connection. The possible

values are SUCCESS, TERMINATION_FORCED,
INVALID_CONNECTION which are defined in
Table 160.
17
18
19
20
7. 2. 1 .1 .6 . 2 W hen g e ner a te d
The SCME-CLOSE.confirm primitive is generated by the SCoP Layer and issued to the NHLE in
response to a SCME-CLOSE.request primitive.
21
22
The handle to the connection that has been closed is transmitted to the NHLE.
23
7. 2. 1 .1 .7 SCM E- L I ST E N. re qu es t
24
25
The SCME-LISTEN.request primitive requests the SCoP layer to listen to incoming requests to open
a connection with a peer entity.
26
7. 2. 1 .1 .7 . 1
27
SCME-LISTEN.request
28
29
30
31
Page 106
{
IPVersion,
IPAddress,
Port,

TransportMode,
SecurityLevel
1
2
3
4
5
}
The table below specifies the parameters of the SCME-LISTEN.request primitive.
Table 140: SCME-LISTEN.request Parameters

Name
Type
Valid Range
Description
IPversion
Octet
0x00 to 0x01
IP version
0x00 : IPv4
0x01 : IPv6
IPAddress
IP
Address
0.0.0.0 to 255.255.255.255(IPv4)
or
0000:0000:0000:0000:0000:0000:0000:0000
to
IP address of the local entity
Port
IP port
1 to 65535
Port of the local entity that is

listening to request for opening
a connection
TransportMode
Octet
0x00 to 0x03
Indicate which SCoP transport

modes are accepted. Transport
mode shall have a valid value
among those defined in Table
153 or have the value 0x03 if
mode 0 and mode 1 are
supported simultaneously
SecurityEnabled
Octet
0x00 to 0x01
Indicate if the CCM* security

shall be checked for any
incoming connection according
to the security policy defined by
the SCIB attributes
7
8
9
10
11
7. 2. 1 .1 .7 . 2 W hen g e ner a te d
The SCME-LISTEN.request primitive is generated by the NHLE to listen to incoming request to
open a connection with a peer entity and filter on the SCoP transport mode and with an expected
security level of encryption and authentication.
12
7. 2. 1 .1 .7 . 3
13
14
15
When the SCoP Layer receives the SCME-LISTEN.request primitive, the SCME starts listening to
incoming requests of connection from a peer entity. The request parameters are used to match the
appropriate transport mode and security level of an incoming connection request.
16
17
18
If the SCoP layer is already listening, the SCoP layer shall issue the SCME-LISTEN.confirm primitive
with the same IPAddress and Port parameters as in the request. The Status parameter shall be set to
SUCCESS.
19
20
21
22
23
24
If the SCoP layer cannot listen to incoming request of connection, the SCoP layer shall issue the
SCME-LISTEN.confirm primitive with the same IPAddress and Port parameters as in the request. If
the IP address or port is invalid the Status parameter shall be set to INVALID_ADDRESS. If the
TransportMode specified are not supported the Status parameter shall be set to
UNSUPPORTED_TRANSPORT. If the SecurityLevel requested is not supported, the Status parameter
shall be set to SECURITY_FAILED.

Page 107
1
2
Otherwise the SCoP layer shall issue the SCME-LISTEN.confirm primitive with the same IPAddress,
and Port parameters as in the request. The Status parameter shall be set to SUCCESS.
7. 2. 1 .1 .8 SCM E- L I ST E N. conf i r m
The SCME-LISTEN.confirm primitive reports the status of the SCME-LISTEN request to the NHLE.
7. 2. 1 .1 .8 . 1

SCME-LISTEN.confirm
7
8
9
10
11
12
13
14
{
Status,
IPVersion,
IPAddress,
Port
}
The table below specifies the parameters of the SCME-LISTEN.confirm primitive.
15
Table 141: SCME-LISTEN.confirm Parameters

Name
Type
Valid Range
Description
Status
unsigned
16 bit
integer
0 to 65535
Status of the request to listen for

incoming connection
IPversion
Octet
0x00 to 0x01
IP version
0x00 : IPv4
0x01 : IPv6
IPAddress
IP
Address
0.0.0.0 to 255.255.255.255(IPv4)
or
0000:0000:0000:0000:0000:0000:0000:0000
to
IP address of the local entity
Port
IP port
1 to 65535
Port of the local entity
16
17
18
19
7. 2. 1 .1 .8 . 2 W hen g e ner a te d
The primitive is generated by the SCoP Layer and issued to the NHLE in response to a SCMELISTEN.request primitive.
20
21
22
23
The NHLE is informed of the status of the SCME-LISTEN.request.
24
7. 2. 1 .2 Inf o rm at i on B as e M aint en an c e
25
26
27
This set of primitives defines how the next higher layer of a device can read and write attributes in the
SCIB.
Page 108

7. 2. 1 .2 .1 SCM E- G ET . re qu est
7. 2. 1 .2 .1 . 1
4
5
6
7
8
S em ant ic s of th e S er v i c e Pr im it i v e
SCME-GET.request
{
SCIBAttribute
}
The table below specifies the parameters of the SCME-GET.request primitive.
Table 142: SCME-GET.request Parameters

Name
SCIBAttribute
Type
Integer
Valid Range
See Table 156 and
Table 157
Description
The identifier of the SCIB attribute to read.
10
7. 2. 1 .2 .1 . 2
11
12
This primitive is generated by the next higher layer and issued to its SCME in order to read an attribute
from the SCIB.
13
7. 2. 1 .2 .1 . 3
14
15
16
17
18
On receipt of this primitive, the SCME attempts to retrieve the requested SCIB attribute from its
database. If the identifier of the SCIB attribute is not found in the database, the SCME issues the
SCME-GET.confirm primitive with a status of UNSUPPORTED_ATTRIBUTE. If the requested SCIB
attribute is successfully retrieved, the SCME issues the SCME-GET.confirm primitive with a status of
SUCCESS such that it contains the SCIB attribute identifier and value.
19
7. 2. 1 .2 .2 SCM E- G ET . conf i rm
20
This primitive reports the results of an attempt to read the value of an attribute from the SCIB.
21
7. 2. 1 .2 .2 . 1
22
23
24
25
26
27
28
29
30
W hen G e n er a t ed
Ef f ec t o n R ec e i pt
SCME-GET.confirm
{
Status,
SCIBAttribute,
SCIBAttributeLength,
SCIBAttributeValue
}
The table below specifies the parameters of the SCME-GET.confirm primitive.

Page 109
Table 143: SCDE-GET.confirm Parameters

Name
Type
Valid Range
Description
Status
Enumeration
SUCCESS or
UNSUPPORTED_ATTRIBUTE
The result of the request to read an

SCIB attribute value.
SCIBAttribute
Integer
See Table 156 and Table 157
The identifier of the SCIB attribute

that was read
SCIBAttributeLength
Integer
0x0001-0xffff
The length, in octets, of the attribute

value being returned.
SCIBAttributeValue
Various
Attribute Specific
The value of the SCIB attribute that

was read
7. 2. 1 .2 .2 . 2
3
4
5
6
This primitive is generated by the SCME and issued to its next higher layer in response to an SCMEGET.request primitive. This primitive returns a status of SUCCESS, indicating that the request to read
an SCIB attribute was successful, or an error code of UNSUPPORTED_ATTRIBUTE. The reasons for
these status values are fully described in sub-clause .
7. 2. 1 .2 .2 . 3
8
9
10
On receipt of this primitive, the next higher layer is notified of the results of its request to read an SCIB
attribute. If the request to read an SCIB attribute was successful, the Status parameter will be set to
SUCCESS. Otherwise, the Status parameter indicates the error.
11
7. 2. 1 .2 .3 SCM E- S ET . req ue st
12
7. 2. 1 .2 .3 . 1
13

SCME-SET.request
14
15
16
17
18
19
20
{
SCIBAttribute,
SCIBAttributeLength,
SCIBAttributeValue
}
The table below specifies the parameters of the SCME-GET.request primitive.
21
Table 144: SCDE-SET.request Parameters

Name
Type
Valid Range
Description
SCIBAttribute
Integer
See table Table

156 and Table 157
The identifier of the SCIB attribute to read.
SCIBAttributeLength
Integer
0x0001-0xffff
The length, in octets, of the attribute value being set.
SCIBAttributeValue
Various
Attribute Specific
The value of the SCIB attribute that should be

written
22
7. 2. 1 .2 .3 . 2
23
24
This primitive is to be generated by the next higher layer and issued to its SCME in order to write the
value of an attribute in the SCIB.
Page 110

7. 2. 1 .2 .3 . 3
2
3
4
5
6
7
8
On receipt of this primitive, the SCME attempts to write the given value to the indicated SCIB attribute
in its database. If the SCIBAttribute parameter specifies an attribute that is not found in the database,
the SCME issues the SCME-SET.confirm primitive with a status of UNSUPPORTED_ATTRIBUTE.
If the SCIBAttributeValue parameter specifies a value that is outside the valid range for the given
attribute, the SCME issues the SCME-SET.confirm primitive with a status of
INVALID_PARAMETER. If the requested SCIB attribute is successfully written, the SCME issues the
SCME-SET.confirm primitive with a status of SUCCESS.
7. 2. 1 .2 .4 SCM E- S ET .c onf ir m
10
7. 2. 1 .2 .4 . 1
11

SCME-SET.confirm
12
13
14
15
16
17
{
Status,
SCIBAttribute
}
The table below specifies the parameters of the SCME-SET.confirm primitive.
18
Table 145: SCDE-SET.confirm Parameters

Name
Type
Valid Range
Description
Status
Enumeration
SUCCESS,
INVALID_PARAMETER or
The result of the request to write the

SCIB Attribute.
SCIBAttribute
Integer
See table
The identifier of the SCIB attribute that

was written
19
20
21
22
23
24
7. 2. 1 .2 .4 . 2 W hen G e n er a t ed
This primitive is generated by the SCME and issued to its next higher layer in response to an SCMESET.request primitive. This primitive returns a status of either SUCCESS, indicating that the requested
value was written to the indicated SCIB attribute, or an error code of INVALID_PARAMETER or
UNSUPPORTED_ATTRIBUTE. The reasons for these status values are completely described in subclause 7.2.1.2.3.3.
25
26
27
28
29
30
31
7. 2. 1 .2 .4 . 3 Ef f ec t o n R ec e i pt
On receipt of this primitive, the next higher layer is notified of the results of its request to write the
value of a SCIB attribute. If the requested value was written to the indicated SCIB attribute, the Status
parameter will be set to SUCCESS. Otherwise, the Status parameter indicates the error.
32
7. 2. 2 SC o P Dat a S e rv i ce P ri mit iv e s
33
7. 2. 2 .1 SC D E- D AT A. r e qu e st
34
The SCDE-DATA.request primitive requests the SCoP layer to send data on an available connection.

Page 111
7. 2. 2 .1 .1 S em ant ic s of t he s e r v ic e p r imi tiv e

SCDE-DATA.request {
3
4
5
6
7
8
9
Handle,
Service,
Data
}
The table below specifies the parameters of the SCDE-DATA.request primitive.
10
Table 146: SCDE-DATA.request Parameters

Name
Type
Valid Range
Description
Handle
unsigned
32 bit
integer
0 to 232 -1
Service
unsigned 8
bit integer
0x01 to 0x02
The data service used for the SDU according to

Table 151
Data
Set of
octets
Variable
SCoP Service Data Unit (SDU) to transmit
11
12
7. 2. 2 .1 .2 W hen g ene r at ed
13
14
The primitive is generated by the NHLE when it needs to send data to a peer entity using an available
connection with this peer entity.
15
7. 2. 2 .1 .3 Ef f ec t of re c eipt
16
17
When the SCoP Layer receives the primitive, the SCDE creates a data frame with the data in the
payload and sends the frame over the connection identified by the handle.
18
19
20
If the Handle parameter has a value that is not recognized as identifying an established connection with
a SCoP peer entity, the SCoP layer shall issue the SCDE-DATA.confirm primitive with the same
Handle parameter as in the request and the Status parameter shall be set to INVALID_CONNECTION.
21
22
23
24
The formation of the frame and its transmission follows the general process of SCoP frame
transmission described in 7.4.6.2. If an error status is reported during this process, the SCoP layer shall
issue the SCDE-DATA.confirm primitive with the same Handle parameter as in the request and the
Status parameter shall be set to the appropriate error status.
25
26
Otherwise the SCoP layer shall issue the SCDE-DATA.confirm primitive with the same Handle
parameters as in the request. The Status parameter shall be set to SUCCESS.
27
7. 2. 2 .2 SC D E- D AT A. i nd ic at io n
28
29
The SCDE-DATA.indication is generated by the SCoP layer when data is received on a given
connection.
30
31

Page 112

SCDE-DATA.indication
1
2
3
4
5
6
7
8
{
Handle,
Status,
Service,
Data
}
The table below specifies the parameters of the SCDE-DATA.indication primitive.
Table 147: SCDE-DATA.indication Parameters

Name
Type
Valid Range
Description
Handle
unsigned
32 bit
integer
0 to 232 -1
Status
unsigned
16 bit
integer
0 to 65535
Status of data reception
Service
unsigned 8
bit integer
0x01 to 0xff
The service used for the SDU according to Table

151 or 0xff
Data
Set of
octets
Variable
SCoP Service Data Unit (SDU) received
10
11
7. 2. 2 .2 .2 W hen g ene r at ed
12
13
14
15
The primitive is generated by the SCoP Layer and issued to the NHLE upon reception of appropriately
addressed incoming data frames on a previously open connection which shall be identified in the SCoP
layer by a unique handle. The Handle parameter shall be set to the value of the handle identifying the
connection where the frame is received.
16
17
18
19
The reception of the frame follows the general process of SCoP frame reception described in 7.4.6.3. If
an error status is reported during this process, the SCoP layer shall issue the SCDE-DATA.indication
primitive with the same Handle parameter as in the request and the Status parameter shall be set to the
appropriate error status.
20
21
In any of the error cases, the Service parameter is set to 0xff to indicate a non-significant value and the
Data parameter is left empty and the primitive is generated without any further processing.
22
23
24
If the SCoSS processing is successful, the Service parameter is set with the value of the service
identifier field of the unsecured SCoP frame and the Data parameter is set with the data payload field
of the unsecured SCoP frame and the Status parameter is set to SUCCESS.
25
26
On receipt of this primitive the NHLE is notified of the arrival of data from a remote SCoP peer entity.
27
7. 2. 2 .3 SC D E- D AT A. c on f i rm
28
The SCDE-DATA.confirm primitive reports the status of the SCDE-DATA.request to the NHLE.

Page 113

SCDE-DATA.confirm {
3
4
5
6
7
8
Handle,
Status
}
The table below specifies the parameters of the SCDE-DATA.confirm primitive.
Table 148: SCDE-DATA.confirm Parameters

Name
Type
Valid Range
Description
Handle
unsigned
32 bit
integer
0 to 232 -1
Identifier of a SCoP connection
Status
unsigned
16 bit
integer
0 to 65535
Status of transmission of data on this connection
10
11
7. 2. 2 .3 .2 W hen g ene r at ed
12
13
The primitive is generated by the SCoP Layer and issued to the NHLE in response to a SCDEDATA.request primitive.
14
15
The NHLE receives the status of the data transmission.
16
7.3
17
SCoP Frame Format s
7. 3. 1 P rot o co l Conv ent i on s
18
7. 3. 1 .1 T ran sm is si on or de r
19
20
21
22
23
24
The SCoP frames are described as a sequence of fields in a specific order. All frame formats in this
sub-clause are depicted in the order in which they are transmitted by the TCP or UDP layer, from left
to right, where the leftmost bit is transmitted first in time. Bits within each field are numbered from 0
(leftmost and least significant) to k-1 (rightmost and most significant), where the length of the field is k
bits. Fields that are longer than a single octet are sent to the TCP or UDP layer in order from the octet
containing the lowest-numbered bits to the octet containing the highest-numbered bits.
25
7. 3. 1 .2 Int ege r s, o ct et s , and t he ir rep r e se ntat ion
26
27
28
29
30
31
Throughout this specification, the representation of integers as octet strings and of octet strings as
binary strings shall be fixed. All integers shall be represented as octet strings in most-significant-octet
first order. This representation conforms to the convention in Section 4.3 of ANSI X9.63-2001 0. All
octets shall be represented as binary strings in most-significant-bit first order unless otherwise
specified. Unless otherwise indicated, all multi-byte numeric values shall be represented in mostsignificant-octet first order (big endian).
Page 114

1
2
3
7. 3. 2 G en e ra l F r am e Fo rm a t
A ZGD shall use the following frame format and the attendant field values. The figure 8 describes the
basic layout of the SCoP protocol.
Octets: 1
0/5/13
1/2
Variable
0/4/8/16
Transport
type
Protocol
version
Packet
length
Security
Header
Service
identifier
Fragmentation
Header
Payload
MIC
SCoP payload
SCoP footer
SCoP header
4
5
Figure 6: General SCoP Frame Format
6
7
The SCoP frame structure is either unsecured or secured according to the value of the transport type
field. The figure 9 presents the SCoP Packet Structure either in unsecured or secured mode.
Length
Transport
type
SCoP
Unsecured
Protocol
Packet length
version
Service
identifier
Fragmentation
Header
Payload
SCoP Secured
Security
Header
Service
identifier
Fragmentation
Header
Payload
MIC
Encrypted data
MIC inputs range
8
9
Figure 7: Unsecured and secured SCoP Packet Structure
10
11
12
13
14
7. 3. 2 .1 T ran spo rt T ype F ie ld
1 octet total size

MSB of octet defines a secure mode (security header included)
The possible values for the transport type are defined in the following table:

Page 115
Table 149: SCoP Transport Type field

Value
Transport Type
0x01
UDP Message (Mode 0)
0x02
TCP Message (Mode 1)
0x03
TCP Message with SSL/TLS Tunnel (Mode 2)
0x81
UDP Message and CCM* Security (Mode 0+CCM*)
0x82
TCP Message and CCM * Security (Mode 1+CCM*)
0x83
TCP Message with SSL/TLS Tunnel and CCM * Security (Mode 2+CCM*)
3
4
5
6
7
8
9
7. 3. 2 .2 P rot o co l V e rs ion Fi e l d
1 octet total size

The value of 1 is obsolete in this version.
Fixed value of 2 for this version
7. 3. 2 .3 P ac k et L en gt h Fi el d
2 octets total size

16 bit unsigned value
10
The length of the packet is the total number of bytes of the SCoP frame as indicated on Figure 7.
11
7. 3. 2 .4 Fr agm ent at ion H ea de r
12
13
The Fragmentation Header contains IP packets fragmentation information sub-fields and shall be
formatted as illustrated in Figure 10.
Octets: 1
0/2
0/1
Fragmentation frame control
Frame Id
Block number
Fragmentation Header
14
15
Figure 8: Fragmentation Header Field Format
16
7. 3. 2 .4 .1 Fr agm ent at ion F ra me Con tr ol fi el d
17
18
The fragmentation frame control field is eight-bits in length and contains information defining the use
of fragmentation. The fragmentation frame control field shall be formatted as illustrated in Figure 11.
Bits: 0-1
2-7
Fragmentation
Reserved
Fragmentation frame control
19
20
Figure 9: Fragmentation Frame Control field format
Page 116

1
2
The fragmentation sub-field is two bits in length and shall be set to one of the nonreserved values listed
in Table 125.
Fragmentation
Value
Description
00
Transmission is not fragmented.
01
Frame is first fragment of a fragmented transmission.
10
Frame is part of a fragmented transmission but not the first block.
11
Reserved.
7. 3. 2 .4 .2 Fr am e Id
4
5
6
7
8
9
The Frame Id fields is two octets in length and specifies a unique identifier for the frame as follows : If
the fragmentation sub-field is set to indicate that the transmission is not fragmented then the Frame Id
field shall not be included in the sub-frame. If the fragmentation sub-field is set to 01 or 10, then the
Frame Id field shall be included in the sub-frame and shall indicate an unsigned integer as identifier of
the fragmented transmission. This value shall be incremented by one for each new SCoP frame. When
the maximum value is reached the next value shall be set back to 0.
10
7. 3. 2 .4 .3 Blo c k Num be r
11
12
13
14
15
16
17
The block number field is one octet in length and is used for fragmentation control as follows: If the
fragmentation sub-field is set to indicate that the transmission is not fragmented then the block number
field shall not be included in the sub-frame. If the fragmentation sub-field is set to 01, then the block
number field shall be included in the sub-frame and shall indicate the number of blocks in the
fragmented transmission. If the fragmentation sub-field is set to 10, then the block number field shall
be included in the sub-frame and shall indicate which block number of the transmission the current
frame represents, taking the value 0x01 for the second fragment, 0x02 for the third, etc.
18
7. 3. 2 .5 S ec ur it y He ad e r
19
20
21
The Security Header is optional. If present, then the remainder of the packet is secured using the SCoP
CCM* security. The security header, as illustrated by Figure 10, shall include a security control field
and a frame counter field, and may include a source identifier field.
Octets: 1
0/8
Security control
Frame counter
Source identifier
Security header
22
23
Figure 10: Security Header Field Format
24
7. 3. 2 .5 .1 S ec ur it y Cont ro l F i el d
25
26
The security control field shall consist of a security level sub-field and an extended nonce sub-field and
shall be formatted as shown in Figure 11: Security Control Sub-Field Format
27

Page 117
Bits: 0-2
4-7
Security level
Extended nonce
Reserved
Security control
1
2
Figure 11: Security Control Sub-Field Format
7. 3. 2 .5 .1 . 1
4
5
6
7
8
9
The security level identifier indicates how an outgoing frame is to be secured, and respectively, how an
incoming frame purportedly has been secured: it indicates whether or not the payload is encrypted and
to what extent data authenticity over the frame is provided, as reflected by the length of the message
integrity code (MIC). The bit-length of the MIC may take the values 0, 32, 64 or 128 and determines
the probability that a random guess of the MIC would be correct. The security properties of the security
levels are listed in Table 150.
10
Table 150: CCM* Security Levels available to the SCoP

Security Level
Identifier
S ec ur i t y L e ve l Su b - F i e l d
Security Level
Sub-Field Value
Security
Attributes
Data
Encryption
Frame Integrity (length M of

MIC in number of octets)
0x00
000
None
OFF
NO (M = 0)
0x01
001
MIC-32
OFF
YES (M=4)
0x02
010
MIC-64
OFF
YES (M=8)
0x03
011
MIC-128
OFF
YES (M=16)
0x04
100
ENC
ON
NO (M = 0)
0x05
101
ENC-MIC-32
ON
YES (M=4)
0x06
110
ENC-MIC-64
ON
YES (M=8)
0x07
111
ENC-MIC-128
ON
YES (M=16)
11
12
7. 3. 2 .5 .1 . 2
13
14
The extended nonce sub-field indicates if the source identifier is present in the security header. If it is
set to 0, the source identifier is not present in the security header. If it is set to 1, it is present.
15
7. 3. 2 .5 .2 Fr am e Cou nt e r Fi el d
16
The counter field is used to provide for frame freshness and to prevent processing of duplicate frames.
17
7. 3. 2 .5 .3 Sou r c e Ide n t if i er Fi e l d
18
19
20
21
The source identifier field shall only be present when the extended nonce sub-field of the security
control field is set to 1. When present, the extended nonce field shall contain a value of 64-bits in
length identifying the source of the frame. How this value is defined is out of the scope of this
specification.
Page 118
Ex t e nd e d N onc e S u b - Fi e ld

7. 3. 2 .6 S erv ic e Id ent if i e r F i e ld
2
3
The service identifier field is 1 octet in length, and is used to distinguish the destination service of the
payload. Table 151 lists those services currently defined.
Table 151: Encoding Values for the Service Identifier field

Service Identifier
Description
0x00
SCoP Service
0x01
Bridge Service
0x02
GRIP Service
0x03-0xFF
Reserved for future use
7. 3. 2 .7 P a ylo ad
Variable number of octets.
8
9
The payload field contains information specific to individual frame types. Each of these is defined in
subsequent sections.
10
11
12
If the fragmentation sub-field is set to indicate that the transmission is fragmented then the payload
field contains one block of the fragmented transaction identified by the Frame Id and the Block
Number of the fragmentation header field.
13
7. 3. 2 .8 M essa ge I nt e gr it y Co de
14
The Message Integrity Code length can be 0, 4, 8 or 16 octets depending on security mode in effect.
15
7. 3. 3 For mat of In div i du al Fr am e T yp e s
16
There are two individual frame types: data frames and command frames.
17
7. 3. 3 .1 SC o P Dat a F ra me Fo r mat
18
7. 3. 3 .1 .1 SC o P Dat a F ra me H e ad er
19
20
The SCoP data frame header shall conform to the general SCoP frame and has its service identifier
field different from 0.
21
7. 3. 3 .1 .2 SC o P Dat a F ra me Pa ylo ad
22
23
24
25
For an outgoing data frame, the data payload field shall contain part or all of the sequence of octets that
the next higher layer has requested the SCoP data service to transmit. For an incoming data frame, the
data payload field shall contain all or part of the sequence of octets that has been received by the SCoP
data service and that is to be delivered to the next higher layer.
26

Page 119
7. 3. 3 .2 SC o P Com ma nd Fr a m e F or m at ( S e rv ic e 0)
7. 3. 3 .2 .1 SC o P Com ma nd Fr a m e He ad e r
3
4
The SCoP command frame header shall conform to the general SCoP frame and has its service
identifier field equal to 0.
7. 3. 3 .2 .2 SC o P Com ma nd Fr a m e P a ylo ad
The SCoP payload of a command frame shall use the following format and the attendant field values.
Octets: 1
0/2
Command type
Command value
ZIPT payload
7
8
9
Figure 12: SCoP Command Frame Format
7. 3. 3 .2 .2 . 1
Com m and T yp e Fi e l d
10
11
The command type field is 1 octet in length, and is used to indicate the command type and to
distinguish the subsequent command value of the payload.
12
Table 152: Command Type Values

Command type
Description
0x00
Hello
0x01
Hello Response
0x02
Hello Acknowledgement
0x04
Goodbye
0x05
Goodbye Response
0x06
Keep Alive Ping
0x07
Keep Alive Pong
0x03, 0x08-0xff
Reserved for future use
13
14
15
7. 3. 3 .2 .2 . 2 Com m and V a lu e F ie l d
Variable number of octets.
16
For all command types other than 0x01 (Hello Response) the command value field is absent.
17
18
19
For command type 0x01 (Hello Response) the command value is a two octet field, the currently
support values are 0x0000 to indicate a successful response to a command of type 0x00 (Hello) and
0xFFFF to indicate a failure of a command of type 0x00 (Hello).
Page 120

7.4
Functional Descript ion
7. 4. 1 T ran spo rt M ode s:
3
4
Three different transport modes may be used for a communication between SCoP entities. These
transport modes are defined in the table below.
Table 153: SCoP Transport Modes

Transport
Mode
Transport Mode Name
Description
0x00
UDP transport mode or

Mode 0
Transport mode 0 is UDP from the Internet suite (see reference

0), a lightweight, datagram transport with the ability to use
CCM* security for integrity, authentication and payload
encryption. Transport mode 0 provides neither
acknowledgement nor retransmission.
0x01
TCP transport mode or

Mode 1
Transport mode 1 is TCP from the Internet suite (see reference

0), the connection oriented transport protocol with the ability to
use CCM* security for integrity, authentication and payload
encryption. Transport mode 1 thus inherits the reliability
features of TCP such as acknowledgements, data retries and data
integrity checks.
0x02
TCP transport mode with

SSL/TLS or Mode 2
Transport mode 2 is TLS Protocol (see reference 0) over TCP

from the Internet suite (see reference 0). It provides for a TLS
pipe to be used for all communication between SCoP entities
with the ability to use CCM* security in addition. The TLS
security modes and authentication methods are not covered or
defined by this specification, but should follow TLS norms.
7. 4. 1 .1 Conn e ct io n u s ing U D P t r an spo rt mo de
8
9
10
11
SCoP allows to use UDP transport mode while defining a connection oriented protocol. The two
entities using the UDP transport mode shall use the same IP socket during the whole time of the SCoP
connection as defined by SCoP. This is assumed in the following sections concerning SCoP
connections using UDP transport mode.
12
13
If one of the entity is behind a NAT, this entity shall use the connection maintenance mechanism to
keep the NAT binding (cf. following sections).
14
7. 4. 1 .2 S ec ur it y S erv ic e s
15
16
17
18
19
The SCoP layer shall include a security service. The service shall implement a CCM* set of security
levels. The SCoP layer may use appropriate functions from the main ZigBee Specification described in
the Annex A (CCM* Mode of Operation). In addition the SCoP Layer may use a TLS pipe as offered
in transport Mode 2. The security level used may be determined globally or on a connection by
connection basis. The full security services and their operation are described in Section 7.6.

Page 121
7. 4. 2 So c ket I nit ia liz at ion
2
3
4
5
6
7
8
In order to be able to accept communication from other entity, a SCoP entity shall set up the IP sockets
that will be ready to receive IP packets. The ZLME-LISTEN.request procedure is provided for this
purpose. The port that is used to wait for a connection using transport mode 0 or 1 is the port assigned
by IANA for SCoP Service. The port that is used to wait for a connection using transport mode 2 is the
port assigned by IANA for SCoP Secured Service. A SCoP entity may be configured to wait for
connections on other ports if the NHLE explicitly defines alternate ports for the connection; this is out
of the scope of this specification.
Table 154: IANA port number assignment for SCoP

Port number
Description
Supported Transport Modes
17755
SCoP Service
Mode 0 and 1
17756
SCoP Secured Service
Mode 2
10
11
7. 4. 3 Conn e ct io n E st abl is h ment
12
13
14
15
16
17
Before communicating data from the NHLE between any two entities in the Internet using SCoP, a
SCoP connection must be established by a handshake sequence. The connection establishment assumes
that one SCoP entity, called here the client, is requested by the NHLE to open a connection with a
SCoP peer entity, called here the server. For a successful connection establishment, the server shall be
previously initialized with a socket listening to incoming message as specified in section 7.4.2. The
client uses the SCME-OPEN.request primitive to start the connection establishment process.
18
A SCoP handshake sequence is described below:
19
20
21
22
1.
For transport mode 0 connections, the SCoP commands will be sent as UDP datagrams. For
transport modes 1 and 2 a TCP connection will first be established between the client and
server SCoP entities with a subsequent TLS connection in Mode 2 (the client being the
initiator of the TCP and if applicable TLS handshakes).
23
24
2.
The client starts the SCoP handshake sequence by sending a SCoP command frame with
command type 0x00 (Hello command) to the server.
25
26
27
3.
Once the server receives the incoming Hello command, it responds with a SCoP command
frame of type 0x01 (Hello Response command) including a connection status response in the
command value field.
28
29
30
31
32
33
34
35
36
37
38
4.
Upon receipt of the server Hello Response command, the client completes the connection by
sending a SCoP command frame with command type 0x02 (Hello Acknowledgement
command). At this point the SCoP connection is fully established on the client and the SCoP
layer shall issue the SCME-OPEN.confirm primitive to the NHLE with a unique client
identifier for the connection in the Handle parameter.
For transport mode 0 (UDP) , if the client does not receive the Hello Response command after
scopTurnaroundTimeout, the client shall retry with step 2 for a maximum number of
scopcHelloRetries retries. If all retries have failed, the client shall abort the connection.
For transport modes 1 or 2, the frame shall be sent only once, but if no response is received
within the ~scopTurnaroundTimeout*(1 + scopcHelloRetries) timeout, the client shall abort
the connection.
39
40
41
42
43
44
5.
Upon receipt of the client Hello Acknowledgement command, the SCoP connection is fully
established on the server and the SCoP layer shall issue the SCME-OPEN.indication primitive
to the NHLE with a unique server identifier for the connection in the Handle parameter. If the
server does not receive the Hello Acknowledgement command after scopTurnaroundTimeout,
the server shall retry with step 3 for a maximum number of scopcHelloRetries retries using the
specified back off method hereafter. If all retries have failed, the server shall abort the
Page 122

1
2
3
4
5
6
7
8
9
connection and close TLS connections if transport mode 2 was requested and TCP connection
if transport mode 1 or 2 was requested.
6.
Once the connection is established the SCoP layer may transmit and receive SCoP data
messages across the connection.
If the SCME-OPEN.request primitive indicates that the CCM* security applies on this connection, all
command frames shall be sent securely according to the process described here after for the
transmission and reception of SCoP frames. Any error that would occur while processing the SCoP
commands of the handshake procedure shall interrupt the procedure and shall be reported to the NHLE
in the Status parameter of the SCME-OPEN.confirm primitive.
NHLE
Initiator
SCoP
Client
SCoP
Server
NHLE
Listener
SCME-LISTEN.request
SCME-LISTEN.confirm
Wait for Hello
SCME-OPEN.request
SCoP Hello
SCoP Hello Response
SCoP Hello Ack
SCME-OPEN.confirm
SCME-OPEN.indication
10
11
12
Figure 13: SCoP Connection Establishment Sequence
7. 4. 4 Conn e ct io n M aint en a nc e
13
7. 4. 4 .1 N AT T er mi nol og y
14
15
16
Behind a NAT means that an IP endpoint is in the side of the NAT where private IP address and port
are allocated. This side of the NAT is called the internal side of the NAT. The other side of the NAT is
called the external side of the NAT.
17
7. 4. 4 .2 N AT i s su es w it h T r an spo rt M ode 0
18
19
20
21
22
23
24
25
In Transport Mode 0 (UDP) the communication with a SCoP peer entity may be broken due to NAT
mapping issues with UDP. The NAT behaviors may vary and cause the UDP mapping between the IP
address and port of an internal endpoint and the external IP address and port attributed to this endpoint
to be lost thus breaking the communication with any external endpoint. Therefore a mapping refresh
may be required to maintain the communication between these IP endpoints which are SCoP entities in
the scope of this SCoP specification. The reference for describing NAT issues and behavior is 0. The
recommended strategy to maintain the UDP mapping in the NAT is to send keep alive messages on a
periodic basis from the internal SCoP entity of the NAT.

Page 123
7. 4. 4 .3 S end ing K ee p Al iv e M essa ge
2
3
4
5
6
A SCoP Layer connection may be maintained using the Keep Alive command messages if the
Transport Mode is 0. When a SCoP entity has the ability to detect whether it is behind a NAT, the
SCoP entity shall determine if it is behind a NAT prior to any SCoP connection. The detection of the
situation of the SCoP entity regarding NAT is out of the scope of SCoP. Nevertheless it is
recommended to use the STUN usage given in the reference 0
7
8
9
10
11
If the SCoP entity detects that it is behind a NAT and a SCoP connection using mode 0 has been open
with a SCoP peer entity on the external side of the NAT, the SCoP entity on the internal side of the
NAT shall send SCoP command frames with command type 0x06 (keep alive ping) and no command
value to the SCoP peer entity on the external side of the NAT. The periodicity of these command frame
transmission shall be equal to the scopcNATMappingRefreshPeriod constant.
12
7. 4. 4 .4 Re c eiv in g Ke ep Al iv e P ing M es sa ge
13
14
15
16
17
18
Upon reception of a command frame with command type 0x06 (keep alive ping), the SCoP entity on
the external side of the NAT shall process the frame. If the frame is a valid command frame with
command type 0x06 and if a SCoP connection corresponding to the SCoP peer entity is still open, the
SCoP entity shall prepare a SCoP command with command type 0x07 and no command value. If the
frame is not valid or if the connection with the SCoP peer entity does not exist, the SCoP entity shall
drop the frame.
19
20
21
22
23
24
After the reception of the first keep alive ping command, the SCoP entity shall follow up the successful
reception of the upcoming keep alive ping command. If the SCoP entity does not receive a keep alive
ping after scopcLostConnectionTimeout and the connection with the SCoP peer entity is still marked as
open, it shall consider the connection lost with the SCoP peer entity and report the termination of the
connection by issuing the SCME-CLOSE.indication primitive to the NHLE with a Status set to
PING_NOT_RECEIVED.
25
7. 4. 4 .5 Re c eiv in g Ke ep Al iv e P ong M ess ag e an d t i me out
26
27
28
29
Upon reception of a command frame with command type 0x07 (keep alive pong), the SCoP entity shall
check that a command frame with command type 0x06 was previously sent to the SCoP source entity
of the keep alive pong and wait for scopcNATMappingRefreshPeriod before sending a new keep alive
ping.
30
31
32
33
If the SCoP entity does not receive a keep alive pong after scopcLostConnectionTimeout and the
connection with the SCoP peer entity is still marked as open, it shall consider the connection lost with
the SCoP peer entity and report the termination of the connection by issuing the SCMECLOSE.indication primitive to the NHLE with a Status set to PONG_NOT_RECEIVED.
Page 124

NHLE
Initiator
SCoP
behind NAT
SCoP
Peer
NHLE
Recipient
SCoP Keep Alive Ping

SCoP Keep Alive Pong
Wait for
scopcNATMappingRefreshPeriod
SCoP Keep Alive Ping
Timeout after
scopcLostConnectionTimeout
1
2
Figure 14: SCoP Connection Keep Alive
7. 4. 4 .6 S ec ur it y Con sid e r ati ons on K e ep Al iv e M es s ag es
4
5
6
7
8
9
If the connection to maintain indicates that the CCM* security applies on this connection, all command
frames shall be sent securely according to the process described here after for the transmission and
reception of SCoP frames. If an error occurs due to the security processing while sending a SCoP Keep
Alive Ping or Pong command, the command shall not be sent until the time comes of the next
command for a Ping or until the next Ping is received for a Pong. The error is not reported to the
NHLE.
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
7. 4. 5 Conn e ct io n T e rm in ati on
A SCoP connection may be terminated if any of the following cases occurs:
The NHLE issued the SCME-CLOSE.request primitive

A Goodbye command message is received by the SCoP layer from the peer entity of the
connection
The duration of the connection is limited by the scopMaxConnectionDuration and no
transmission of frame with a service identifier field different from 0x00 (i.e. a frame which
is not a SCoP service frame) occurred during a period of time equal or greater than
scopMaxConnectionDuration
When applying the connection maintenance process as described above, the SCoP layer
detects that the keep alive ping or keep alive pong are not received and consider that the
connection is lost
The transport layer used for the connection reports a connection termination to the SCoP
layer
A SCoP connection shall be terminated by either entity at anytime by the requesting entity from the
NHLE issuing a SCME-CLOSE.request primitive. If the handle parameter does not correspond to an
open SCoP connection, the Status shall be INVALID_CONNECTION. The SCoP layer of this entity
shall send a Goodbye command message on this connection. The process of sending a Goodbye
command is described in sub-clause 7.4.5.1. The status of the termination shall be reported to the
NHLE through the SCME-CLOSE.confirm primitive.

Page 125
1
2
3
4
5
6
7
8
When a SCoP layer receives a Goodbye command message it shall reply immediately with a Goodbye
Response command message and terminate any data transmission and reception on the connection. If
the Goodbye Response command message is not successfully sent through the connection or the
connection is not successfully closed by the transport layer in use for the connection, the status of the
connection termination is TERMINATION_FORCED, otherwise if the Goodbye Response is
successfully sent and the connection is successfully close by the transport layer in use for the
connection, the status is SUCCESS. The status of the termination shall be reported to the NHLE
through the SCME-CLOSE.indication primitive.
9
10
The sequence illustrated in Figure 15 presents the connection termination initiated by an entity issuing
a SCME-CLOSE.request.
NHLE
Initiator
SCoP
Originator
SCoP
Recipient
NHLE
Recipient
SCME-CLOSE.request
SCoP Goodbye
SCoP Goodbye Response
SCME-CLOSE.confirm
11
12
Figure 15: SCoP Connection Termination
13
14
The connection may also be terminated due to NAT issues detected by the keep alive mechanism as
described in the sub-clause 7.4.4.
15
16
17
18
19
20
21
22
23
It shall be possible to limit the duration of a connection from any SCoP entity by setting the SCIB
attribute scopMaxConnectionDuration to a non-zero value in milliseconds representing the timeout of
the connection. In this case when a connection is open or when a frame with the service identifier field
different from 0x00 (i.e. not a SCoP command frame) is received on this connection, a timer shall be
started or respectively re-started. If the timer elapses after scopMaxConnectionDuration, the
connection shall be automatically closed with the SCoP peer entity by sending a Goodbye command
message. The process of sending a Goodbye command is described in sub-clause 7.4.5.1. The status of
the termination shall be reported to the NHLE using the SCME-CLOSE.indication primitive with the
Status parameter set to TERMINATION_FORCED.
24
25
26
27
If the transport layer in use for the connection notifies the SCoP layer that the connection has been
closed due to an unexpected event occurring in the transport layer, the SCoP layer shall consider that
the connection is closed and report the termination to the NHLE using the SCME-CLOSE.indication
primitive with the Status parameter set to ABNORMAL_TERMINATION.
28
29
30
31
32
If the CCM* security applies on this connection, all command frames shall be sent securely according
to the process described here after for the transmission and reception of SCoP frames. Any error that
would occur while sending the SCoP commands shall interrupt the procedure. If the command is the
Goodbye command, the Status parameter of the SCME-CLOSE.confirm primitive shall be set to
TERMINATION_FORCED.
Page 126

7. 4. 5 .1 S end ing G ood b ye co mm and
2
3
4
5
6
7
8
9
When sending a Goodbye command message, the sending entity shall wait a maximum duration of
scopTurnaroundTimeout for a Goodbye Response command message on the same connection and
close the connection through the transport layer in use for this connection. If the Goodbye Response
command message is not received after scopTurnaroundTimeout or the connection is not successfully
closed by the transport layer in use for the connection, the status of the connection termination is
TERMINATION_FORCED, otherwise if the Goodbye Response is successfully received within
scopTurnaroundTimeout and the connection is successfully close by the transport layer in use for the
connection, the status is SUCCESS.
10
7. 4. 6 T ran sm is si on an d Re ce ptio n
11
7. 4. 6 .1 Dat a T r an s mi ss ion a nd R e c epti on
12
13
14
15
16
Once a SCoP connection has been established the SCoP layer may transmit and receive ZSDU. The
SCoP layer will add security according to the security level defined for the connection and connection
setup. The NHLE shall use the SCDE-DATA.request primitive to send a SCoP data frame and the
result is reported through the SCDE-DATA.confirm primitive to the NHLE. A SCoP recipient is
notified of the arrival of SCoP data frame through the SCDE-DATA.indication primitive.
NHLE
Originator
SCoP
Originator
SCoP
Recipient
NHLE
Recipient
SCDE-DATA.request
SCoP Data
SCDE-DATA.confirm
17
18
Figure 16: SCoP Data Transmission
19
7. 4. 6 .2 T ran sm is si on of S Co P f r am e s
20
21
22
The SCoP layer shall build the outgoing frame with the transport type field corresponding to the
transport mode and to the security level of the connection as specified in Table 149. The protocol
version field shall be equal to 2.
23
24
25
The packet length field shall be set according to the total length of the SCoP frame including all
headers and footers depending on whether the fragmentation is used or not and the security options
selected.
26
27
28
29
30
31
32
33
34
If fragmentation is used , the fragmentation sub-field of the fragmentation frame control field shall be
set to 01 for the first block and 10 for all subsequent blocks of the a fragmented transmission. The
Frame Id shall be set with 0x0000 for the first transaction and be incremented by one for each
following frame. The block number field shall indicate the total number of blocks in the transmission in
the first block, shall take the value 0x01 in the second block, and thereafter shall be incremented for
each subsequent block. Then each block shall be transmitted independently. If fragmentation is not
used, the fragmentation frame control field shall be set to 0x00 and the block number shall not be
included in the fragmentation header.
35
36
37
If the security level of the connection is more than 0x00, the frame shall be secured and shall include a
security header and the security control sub-field shall indicate that the source identifier sub-field is
present.
Page 127
1
2
3
4
5
6
The service identifier field shall be 0x00 for a SCoP command or shall be specified by the NHLE for a
data frame. The security applies as specified in the SCoSS for the security processing of outgoing
frames with the payload processed in the SCoSS being the service identifier field plus the payload field
of the SCoP PDU and the header processed in the SCoSS being SCoP header excluding the service
identifier field. If the frame is successfully built, the SCoP layer shall attempt to send the frame over
the open connection using the transport protocol defined for this connection.
7
8
9
10
11
12
If the SCoP layer cannot form the frame or send the frame on this connection, an error shall be reported
to the NHLE except otherwise specified in the specification for specific frames. If an error occurs when
processing the security service, the error status is SECURITY_FAILED. If the security material is not
found in the SCIB to process the request, the error status is NO_KEY. If the security level of the
connection is not the same as the security level of the SCIB associated with the destination entity, the
error status is BAD_SECURITY_LEVEL.
13
14
15
16
17
18
19
20
For transport mode 0 connections, the SCoP frames will be sent as UDP datagrams, so an optional
reliability mechanism may be implemented: if the client does not receive the SCDE-DATA.confirm
frame after scopTurnaroundTimeout, the client shall retry sending the same message for a maximum
number of scopcHelloRetries retries. If all retries have failed, the client shall fail with an error status set
to TRANSMISSION_FAILED.
.
For transport modes 1 or 2, the frame shall be sent only once, but if no response is received within the
~scopTurnaroundTimeout*(1 + scopcHelloRetries) timeout, the client shall fail with an error status set
to TRANSMISSION_FAILED.
21
If the transmission fails for another reason, the error status is TRANSMISSION_FAILED.
22
7. 4. 6 .3 Re c ept i on of S Co P f r am es
23
24
The reception of SCoP frame is notified by the transport protocol on an established SCoP connection.
The SCoP frame is the payload reported by the transport protocol.
25
26
27
28
29
30
31
32
33
34
The SCoP layer shall check the transport type field and determine whether it has a valid value and
whether it indicates a secured frame using CCM* or not. If the transport type field is not a valid value,
the error status is INVALID_TRANSPORT_TYPE and the no further processing is done. If the
transport type field indicates a different transport mode than the transport mode of the connection
where the frame has been received, the error status is BAD_TRANSPORT_MODE and no further
processing is done. The SCoP layer shall check that the protocol version field is equal to 2. If the
protocol version field is not a valid value, the error status is INVALID_PROTOCOL_VERSION and
no further processing is done. The SCoP layer shall check that the packet length field is equal to the
number of bytes of the frame. If the packet length field has not the expected value, the error status is
FRAME_LENGTH_ERROR and no further processing is done.
35
36
37
38
39
40
The SCoP layer shall check whether the CCM* security processing applies according to the transport
type field and to the security header if present. The security applies as specified in the SCoSS for the
security processing of incoming frames with the header as processed in the SCoSS being SCoP header
including the security header and excluding the service identifier field and the payload as processed in
the SCoSS being all the remaining bytes of the SCoP PDU including the service identifier field. The
output of the SCoSS is the unsecured SCoP frame.
41
42
43
44
45
46
If an error occurs when processing the security service, the error status is SECURITY_FAILED. If the
security material is not found in the SCIB to process the request, the error status is NO_KEY. If the
security level of the connection is not the same as the security level of the SCIB associated with the
destination entity, the error status is BAD_SECURITY_LEVEL. In any of the error case mentioned
above, no further processing is performed. If the SCoSS processing is successful, the processing of the
frame continues with the unsecured SCoP frame output of the SCoSS.
Page 128

1
2
3
4
5
The SCoP layer shall check wether fragmentation is used. If an incoming fragmented transaction is
already in progress but the next expected block number do not match the one of the received frame,
then the received frame may optionally be rejected or handled independently as a further transaction.
Once all blocks in the transaction have been received, reassembly shall be processed. If no transaction
is in progress and a fragmented frame is received, then reassembly shall be attempted.
6
7
If the service identifier field is equal to 0x00, it indicates a command frame, the frame shall be further
processed according to the command type of the payload as specified in Table 152:
8
9
10
11
12
13
14
15
16
Hello or Hello Response or Hello Acknowledgement: process a Hello command, a Hello

Response Command or an Hello Acknowledgement command as described in the process
of connection establishment
Goodbye or Goodbye response: process Goodbye command or Goodbye response
command as described in the process of connection termination
Keep Alive Ping or Keep Alive Pong: process Keep Alive Ping command or Keep Alive
Pong command as described in the process of connection maintenance
Other commands: any other command shall be dropped and no further processing
performed.
17
18
19
20
21
If the service identifier field is more than 0x00, it indicates a data frame, and the ScoP layer shall check
for duplicate reception of the same message, by looking at the Frame Id field of the SCoP header. If it
matches the identifier of a frame received at most scopTurnaroundTimeout*(1 + scopcHelloRetries)
seconds ago, it shall be discarded, otherwise the frame is reported to the NHLE using the SCDEDATA.indication primitive.
22
7.5
23
Constants and SCI B Attributes
7. 5. 1 SC o P Con st ant s
24
Table 155: SCoP Protocol Constants

Constant
Description
Value
scopcMaxPacketSize
The maximum number of octets of a SCoP PDU.
1500
scopcNATMappingRefreshPeriod
The time in seconds between two keep alive command

frames when NAT mapping refresh is required
20
scopcLostConnectionTimeout
The time in seconds to consider that a connection is lost
10
scopcHelloRetries
The number of retries of Hello commands during

connection establishment
25
26
27
28
7. 5. 2 SC o P Inf o rm at ion B a se
The SCoP information base (SCIB) comprises the attributes required to manage the SCoP protocol for
a SCoP entity.

Page 129
Table 156: SCIB Attributes

Attribute
Identifier
Type
Range
Description
Default
scopTurnaroundTime
out
0xd0
16-bits Integer
0 to 65535
The maximum duration to

send a command (Hello,
Hello Response or
Goodbye) and receive the
reply command
(respectively Hello
Response, Hello
Acknowledgement,
Goodbye Response) in
milliseconds
30000
scopMaxConnections
0xd1
32-bits Integer
0 to 232 -1
The maximum number of

simultaneous connections
with peer entities
scopMaxConnection
Duration
0xd2
32-bits Integer
0 to 232 -1
The maximum duration of a

connection if this duration
is limited or a value of zero
if this duration is not
limited
2
3
The SCIB also contains attributes for the SCoP security service defined in the next section.
7.6
SCoP Securit y Service
7. 6. 1 G en e ra l De s c ript ion
The SCoP Security Service describes how the security is applied in the SCoP protocol.
7. 6. 1 .1 S ec ur it y Ar c h it ect ur e an d De s ign
8
9
10
11
There are two dimensions to the security mode, the message based CCM* security level and the
Transport Mode security. All transport modes 0, 1 and 2 shall implement the full seven modes defined
for CCM* within the Table 150. For the transport Mode 2 there is an additional TLS service providing
a secure pipe for SCoP Layer communication.
12
13
The message based CCM* security level is using the security operating mode defined in the Annex A
of the ZigBee specification, document [R1].
14
7. 6. 1 .1 .1 S ec ur it y M at e r ia l
15
16
17
The keying materials required for any security procedure of SCoP shall be provisioned and managed by
the application using SCoP. Therefore it is out of the scope of SCoP to specify how this keying
material is provisioned and maintained.
Page 130

7. 6. 1 .2 CCM * S ec ur it y
2
3
4
5
6
7
SCoP PDUs can be secured by using the security procedures of CCM* for authentication, encryption
and decryption defined for the ZigBee protocol. Using CCM* between SCoP peer entities may require
managing a unique identifier for each of these SCoP entities. The CCM* security level and security key
may be defined by a global security level and key or by a per SCoP peer entity security descriptor
where the SCoP peer entity is designated by its unique identifier. CCM* also requires managing
outgoing and incoming counters. These security materials are stored as attributes in the SCIB.
8
9
10
The different CCM* security levels define both the bit length of message authentication for the MIC as
well as the AES encryption control. The MIC can be 0, 4, 8 or 16 byte length (0 being no frame
authentication) and encryption can be on or off as described in Table 150.
11
7. 6. 1 .2 .1 Ide nt if ie r a nd K e y M anag em ent
12
13
14
15
16
17
This specification makes no requirements for any type of identifier and key distribution mechanism and
key maintenance mechanism. It is up to the NHLE to manage the identifiers of SCoP entities and the
related keys and to decide whether to use global security material or per SCoP peer entities security
material when applying security to a SCoP frame. Managing identifiers and keys are not required if the
CCM* security is not used in the communications between SCoP peer entities. It is also possible to use
a global key without using a unique identifier
18
19
20
If security applies, the SCoP protocol shall manage the relationship between the CCM* unique
identifiers and the IP address of a SCoP peer entity. It is considered an implementation issue to manage
this relationship and is out of scope of the SCoP specification.
21
7. 6. 1 .3 T LS Se cu r it y
22
23
24
In Transport Mode 2, all SCoP frames shall be transported through a TLS pipe independent of whether
those frames use CCM*. The TLS authentication (from either a client or server perspective) is not
defined. Using X.509 certificates is a possible choice.
25
7. 6. 2 Fr am e S e cu rit y us ing C CM *
26
7. 6. 2 .1 S ec ur it y - R el at ed S CI B At tr ibu te s
27
28
29
30
31
The SCoP Information Base contains attributes that are required to manage security for the SCoP
Layer. These attributes are used to manage the CCM* authentication and encryption mechanism
between SCoP entities. Either a SCoP entity is able to secure the frames with CCM* using a single key
or a SCoP entity is able to secure the frames with CCM* using a different key for each SCoP peer
entity.

Page 131
Table 157: SCoP Security-related SCIB Attributes

Attribute
Identifier
Type
Range
Description
Default
scopCCMSecurityLevel
0xe0
Octet
0x00-07
The security level for all

SCoP peer entities as
0x07
scopLocalIdentifier
0xe1
Unsigned 64
bit integer
0 to 264 -1
Identifier of the SCoP local

entity
scopKey
0xe2
Ordered set of
16 octets
Key for CCM* security.
scopOutgoingFrameCounter
0xe3
Ordered set of
4 octets
Outgoing frames counter

used for all the frames
scopIncomingFrameCounterS
et
0xe4
Set of
incoming
frame counter
descriptor
values
Variable
Set of incoming frame

counter values and
corresponding sender
identifiers
scopPeerSecurityMaterialSet
0xe5
Set of security
material and
peer entity
identification
Variable
Set of SCoP peer entity

identification and security
material for CCM* security
per peer entity
2
3
Table 158: Attributes of an Incoming Frame Counter Descriptor

Attribute
Type
Range
Description
Default
SenderIdentifier
Unsigned 64
bit integer
0 to 264 -1
Identifier of a SCoP peer

entity
IncomingFrameCounter
Ordered set of
4 octets
0 to 232 -1
Incoming frame counter
4
5
Table 159: Attributes of a Security Material Descriptor

Attribute
Type
CCMSecurityLevel
Octet
Key
Ordered set of
16 octets
PeerIdentifier
Unsigned 64
bit integer
OutgoingFrameCounter
IncomingFrameCounter
Range
0x00-07
Description
Default
The security level for all

SCoP peer entity.
0x00
Key for CCM* security
0 to 264 -1
Identifier of a SCoP peer

entity
unsigned 32
bit integer
0 to 232 -1
Outgoing frame counter
unsigned 32
bit integer
0 to 232 -1
Incoming frame counter
7. 6. 2 .2 S ec ur it y P ro ce s sin g of O ut goi ng F r am e s
8
9
If the SCoP layer has a frame, consisting of a header Header and payload Payload, that needs security
protection it shall apply security as follows:
Page 132

1
2
3
4
5
1.
Obtain the security material, including the key, outgoing frame counter FrameCount, and
security level (as specified in Table 150) using the following procedure. If the outgoing frame
counter has as its value the 4-octet representation of the integer 2^32-1 or any of this security
material cannot be determined, then security processing shall fail and no further security
processing shall be done on this frame.
6
7
8
9
10
a.
First, an attempt shall be made to retrieve the security material from the
scopPeerSecurityMaterialSet attribute of the SCIB by looking for a
SecurityMaterialDescriptor where the PeerIdentifier value is matching the identifier
of the destination of the outgoing frame. This SecurityMaterialDescriptor shall
contain a valid CCM* security level, a key and an outgoing frame counter.
11
12
13
b.
If the first attempt fails, then the security material shall be obtained by using
scopCCMSecurityLevel attribute for the security level, the scopKey attribute for the
key and the scopOutgoingFrameCounter attribute for the outgoing frame counter.
14
2.
15
Construct the security header and update Header

a.
Set the security control field SecurityControl as follows:
16
i. The security level shall be the security level obtained from step 1
17
ii. The extended nonce sub-field shall be set to 1
18
19
b.
Set the source identifier field to the 64-bit identifier associated with the local SCoP
entity
20
21
c.
Set the frame counter field to the outgoing frame counter FrameCount obtained from
step 1.
22
23
24
3.
Execute the CCM* mode encryption and authentication operation, as specified in the ZigBee
Specification described in the Annex A.2 of [R1] (in CCM* Mode of Operation), with the
following instantiations:
25
26
a.
The parameter M shall be obtained from Table 150 corresponding to the security
level from step 1;
27
b.
The bit string Key shall be the key obtained from step 1;
28
29
c.
The nonce N shall be the 13-octet string constructed using the security control field,
64-bit identifier associated with the local SCoP entity and FrameCount from step 1;
30
31
32
d.
If the security level requires encryption, the octet string a shall be the string Header
and the octet string m shall be the string Payload. Otherwise, the octet string a shall
be the string Header || Payload and the octet string m shall be a string of length zero.
33
34
4.
If the CCM* mode invoked in step 2 outputs invalid, security processing shall fail and no
further security processing shall be done on this frame.
35
36
37
5.
Let c be the output from step 3 above. If the security level requires encryption, the secured
outgoing frame shall be Header || c, otherwise the secured outgoing frame shall be Header ||
Payload || c.
38
39
6.
If the secured outgoing frame size is greater than scopcMaxPacketSize, security processing
shall fail and no further security processing shall be done on this frame.
40
41
7.
The outgoing frame counter FrameCount from step 1 shall be incremented by one and stored
in the location from which the security material was obtained in step 1.
42
43
44
45
46
47
48
7. 6. 2 .3 S ec ur it y P ro ce s sin g of I nco mi ng Fr am e s
If the SCoP layer receives a secured frame, consisting of a header Header and a payload
SecuredPayload, it shall perform security processing as follows:
1. Determine the received frame counter ReceivedFrameCount by the value of the frame counter
field in the frame header Header. If ReceivedFrameCount has as its value the 4-octet
representation of the integer 2^32-1, security processing shall fail and no further security
processing shall be done on this frame.
Page 133
1
2
2.
Obtain the security material, including the key, incoming frame counter FrameCount, and
security level (as specified in Table 150) using the following procedure.
3
4
5
6
7
a.
First, an attempt shall be made to retrieve the security material from the
scopPeerSecurityMaterialSet attribute of the SCIB by looking for a
SecurityMaterialDescriptor where the PeerIdentifier value matches the value of the
source identifier field of the incoming frame. This SecurityMaterialDescriptor shall
contain a valid CCM* security level, a key and an incoming frame counter.
8
9
10
11
12
13
14
15
16
b.
If the first attempt fails, then the security material shall be obtained by using
scopCCMSecurityLevel attribute for the the security level and the scopKey attribute
for the key. The incoming frame counter shall be obtained by looking for an entry in
the scopIncomingFrameCounterSet attribute where the SenderIdentifier matches the
source identifier of the incoming frame. If such entry is found, the incoming frame
counter shall be the IncomingFrameCounter value of this entry. If such entry is not
found, the incoming frame counter shall be set to 0 and an entry shall be created with
the SenderIdentifier equal to the source identifier of the incoming frame and the
IncomingFrameCounter equal to 0.
17
18
3.
If FrameCount exists and if ReceivedFrameCount is less than FrameCount, security

processing shall fail and no further security processing shall be done on this frame.
19
20
4.
Execute the CCM* mode decryption and authentication checking operation, as specified in the
Annex A.3 of [R1] (in CCM* Mode of Operation), with the following instantiations:
21
22
a.
The parameter M shall be obtained from Table 150 corresponding to the security
level from step 2;
23
b.
The bit string Key shall be the key obtained from step 2;
24
25
26
c.
The nonce N shall be the 13-octet string constructed using the security control field
and the source identifier from the header of the incoming frame, and
ReceivedFrameCount from step 1;
27
28
29
d.
Parse the octet string SecuredPayload as Payload1 || Payload2, where the right-most
string Payload2 is an M-octet string. If this operation fails, security processing shall
fail and no further security processing shall be done on this frame;
30
31
32
33
e.
If the security level requires encryption, the octet string a shall be the string Header
and the octet string c shall be the string SecuredPayload. Otherwise, the octet string
a shall be the string Header || Payload1 and the octet string c shall be a string
Payload2.
34
5.
Return the results CCM* operation:
35
36
a.
If the CCM* mode invoked in step 4 outputs invalid, security processing shall fail
and no further security processing shall be done on this frame.
37
38
39
b.
Let m be the output from step 4 above. If the security level requires encryption, set
the octet string UnsecuredFrame to the string Header || m . Otherwise, set the octet
string UnsecuredFrame to the string Header || Payload1;
40
41
6.
Set FrameCount (obtained in step 2) to (ReceivedFrameCount + 1) and update FrameCount in

the SCIB. UnsecuredFrame now represents the unsecured SCoP layer frame.
42
7.7
SCoP La yer Stat us Values
43
44
45
SCoP layer confirmation primitives often include a parameter that reports on the status of the request to
which the confirmation applies. Values for SCoP layer Status parameters appear in Table 160. These
values shall be comprised between 0x0000 and 0x00ff.
Page 134

Table 160: SCoP Layer Status Values

Name
Value
Description
SUCCESS
0x0000
A request has been executed successfully
ALREADY_CONNECTED
0x0001
A request to open a connection has been issued while a

connection already existed for the given input parameters
INVALID_DESTINATION
0x0002
The IP address and port of the request is an invalid destination
INVALID_ADDRESS
0x0003
The IP address and port of the request is an invalid address and

port on the SCoP entity
UNSUPPORTED_TRANSPORT
0x0004
The SCoP transport mode is not supported
INVALID_TRANSPORT_TYPE
0x0005
The transport type of a received SCoP frame is not valid
BAD_TRANSPORT_MODE
0x0006
The transport type of a received SCoP frame does not indicate

the same transport mode as the transport mode of the
connection where this frame was received
FRAME_LENGTH_ERROR
0x0007
The length of the received frame is not the expected one
INVALID_PROTOCOL_VERSION
0x0008
The protocol version of a received SCoP frame is not valid
TCP_CNX_FAILED
0x0009
The TCP connection cannot be established
TLS_CNX_FAILED
0x000a
The TLS connection cannot be established
HANDSHAKE_FAILED
0x000b
The handshake defined by SCoP when a connection is open

resulted in an error
TERMINATION_FORCED
0x000c
The request to close a connection had to be forced and may not

have been performed in accordance to the normal termination
described in the specification.
PING_NOT_RECEIVED
0x000d
An expected keep alive ping command is not received when

applying the connection maintenance
PONG_NOT_RECEIVED
0x000e
An expected keep alive pong command is not received when

applying the connection maintenance
ABNORMAL_TERMINATION
0x000f
The connection is closed due to an unexpected event occurring

in the transport layer used by the SCoP layer
LISTEN_FAILED
0x0010
Attempt to start listening to incoming connection request failed
INVALID_CONNECTION
0x0011
A request to send commands or data on an invalid connection

is received
TRANSMISSION_FAILED
0x0012
The transmission of a data frame on an established connection

failed
NO_KEY
0x0020
The CCM* security material was missing to process a request
BAD_SECURITY_LEVEL
0x0021
A frame is received with a CCM* security level that is not the

security level expected on the connection
SECURITY_FAILED
0x0022
The CCM* security processing failed on a request
MAX_CONNECTIONS_REACHED
0x0023
The maximum number of simultaneous connections

scopMaxConnections value is reached
0x0024
An GET request or SET request has been issued with an

unknown attribute identifier.
INVALID_PARAMETER
0x0025
A parameter value was invalid or out of range

Page 135
8.1
Gatew ay Remote Interface Protocol (GRIP)

General Description
8. 1. 1 G RI P O v e rv i ew
4
5
6
7
8
9
10
11
The Gateway Remote Interface Protocol is a lightweight RPC protocol used for the purpose of calling a
remote function and retrieving the results between a ZigBee Gateway Device (ZGD) and an IP Host
Application (IPHA). The IPHA and ZGD can play both roles of client and server for GRIP. GRIP is
built over SCoP. The mechanism of GRIP is a simple request and response protocol. The ZGD or
respectively the IPHA can send a request to the IPHA or respectively to the ZGD and receive a
response from the IPHA or respectively from the ZGD back. GRIP provides a data service to send
requests and receive responses. The connection management is relying on SCoP and is built in GRIP
data service.
12
8. 1. 1 .1 G RI P D at a Ent it y ( G R ID E)
13
GRIP data entity provides the data transmission service via its SAP, the GRIDE-SAP.
14
8. 1. 1 .2 G RI P M anag em ent En t it y ( G R IM E)
15
16
GRIP Management Entity provides a management service to allow an application to access the GRIP
Information Base (GRIB)via its SAP, the GRIME-SAP.
17
18
8.2
Service Specificati on
19
Figure 17 depicts the components and interface of GRIP.

GRIDE-SAP
GRIDE
SCDE-SAP
GRIME-SAP
GRIME
SCME-SAP
SCoP Sub-Layer Entity
20
21
Figure 17: GRIP Reference Model
22
23
24
8. 2. 1 G RI P D at a S erv ic e
25
26
Page 136

1
2
3
The Table 161 lists the primitives supported by the GRIDE-SAP and the sub-clauses in which the
primitives are discussed.
Table 161: GRIDE-SAP primitives

Name
GRIDE-DATA
Request
8.2.1.1
Indication
8.2.1.2
Response
8.2.1.3
Confirm
8.2.1.4
8. 2. 1 .1 G RI D E- D AT A. r e qu est
7
8
The GRIDE-DATA.request primitive is used by the NHLE to call remotely a function on a peer entity
using GRIP. The call to the function is performed by sending a request frame to the peer entity.
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

GRIDE-DATA.request
{
DestIPVersion,
DestIPAddress,
DestPort,
TransportMode,
SecurityLevel,
FunctionDomain,
FunctionCategory,
ManufacturerCode,
FunctionIdentifier,
FunctionParameters
}
The table below specifies the parameters of the GRIDE-DATA.request primitive.

Page 137
Table 162: GRIDE-DATA.request Parameters

Name
Type
Valid Range
Description
DestIPVersion
unsigned 8 bit
integer
0x00 to 0x01
IPVersion
0x00 : IPv4
0x01 : IPv6
DestIPAddress
IP Address
0.0.0.0 to
255.255.255.255
IP address of the peer entity destination of the request

frame
DestPort
IP port
1 to 65535
Port of the peer entity
TransportMode
unsigned 8 bit
integer
0-2 and 129-131
A valid transport mode for the SCoP protocol
SecurityLevel
unsigned 8 bit
integer
0 to 7
Level of security indicating the level of encryption

and authentication for the frames
FunctionDomain
unsigned 8 bit
integer
0 to 255
The function domain defining the scope of the API

used
FunctionCategory
unsigned 8 bit
integer
0 to 255
A valid function category as defined by the

application using GRIP
ManufacturerCode
unsigned 16
bit integer
0 to 65535
If the function category is equal to 0x00, a

manufacturer code shall be provided.
FunctionIdentifier
unsigned 16
bit integer
0 to 65535
A function identifier as defined by the application

using GRIP
FunctionParameters
Octet String
Variable
The parameters of the function called on the remote

entity
2
3
8. 2. 1 .1 .2 W hen g ene r at ed
The primitive is generated by the NHLE when a request is sent to call a function on the remote entity.
6
7
8
9
10
11
12
13
When this primitive is generated, the GRIDE issues the SCME-OPEN.request primitive to open a
connection with a peer entity. The DestIPAddress, DestPort, TransportMode and SecurityLevel
parameters are copied in the IPAddress, Port, TransportMode and SecurityLevel of the SCMEOPEN.request primitive. Then the GRIDE waits for the SCME-OPEN.confirm primitive to be
generated from the SCoP layer in response to this request. If the Status of the SCME-OPEN.confirm
primitive is not equal to SUCCESS or ALREADY_CONNECTED, i.e. the SCoP layer failed to open
the connection, the GRIDE issues the GRIDE-DATA.confirm primitive with the Status parameter of
the SCME-OPEN.confirm primitive and leaves the FunctionResults parameter empty.
14
15
16
17
18
19
20
21
22
If the connection is successfully opened or if a connection was already open, the GRIDE builds the
GRIP PDU. The GRIDE picks up a transaction identifier that is not already associated with an ongoing
transaction. The RPC function header of the frame is built using the FunctionDomain,
FunctionCategory, ManufacturerCode and FunctionIdentifier. If the FunctionCategory is equal to 0x00
the manufacturer code is provided in the frame header, otherwise the manufacturer code field is
omitted in the frame header. The frame payload shall be equal to the FunctionParameters provided.
Then the GRIDE issues the SCDE-DATA.request primitive with the Handle retrieved from the SCMEOPEN.confirm primitive and with the Data equal to the GRIP PDU and waits for the SCDEDATA.confirm primitive to be generated from the SCoP layer in response to this request.
Page 138

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
On reception of the SCDE-DATA.confirm, if the Status parameter is not equal to SUCCESS , i.e. the
SCoP layer failed to send the GRIP request frame, the GRIDE issues the GRIDE-DATA.confirm
primitive with the Status parameter of the SCDE-DATA.confirm primitive and leaves the
FunctionResults parameter empty. Otherwise if the Status parameter is equal to SUCCESS, the GRIDE
waits for a GRIP response frame which transaction identifier matches the transaction identifier of the
initial GRIP request. The GRIDE waits for a SCDE-DATA.indication with a Status parameter equal to
SUCCESS and a Service parameter indicating a GRIP service and a Data parameter containing a GRIP
response frame where the transaction identifier field and the RPC header matches those of the initial
request. If the SCoP layer reports a SCME-CLOSE.indication or a SCME-CLOSE.confirm primitive
before the matching GRIP response is received, the GRIDE issues the GRIDE-DATA.confirm
primitive with the Status parameter set to CONNECTION_CLOSED. If the GRIP response is not
received
after
duration
equal
to
the
sum
of
the
attributes
gripFunctionTimeout+scopTurnaroundTimeout, the GRIP layer shall not keep track of the GRIP
response frame any longer and the GRIDE issues the GRIDE-DATA.confirm primitive with the Status
parameter set to RPC_TIMEOUT.
16
17
18
19
20
If a GRIP response frame matching the initial request is received successfully, the GRIDE shall issue a
GRIDE-DATA.confirm primitive and set the parameters of this primitive as follows. The Status
parameter shall be set with the value of the RPC status field from the GRIP response frame payload.
The FunctionResults parameter shall be set with the RPC result payload from the GRIP response frame
payload.
21
8. 2. 1 .2 G RI D E- D AT A. i ndi c ati on
22
23
24
The GRIDE-DATA.indication is generated by the GRIDE when a request is received in order for the
recipient entity to perform a function and return the results in a response to the originator of the
request.
25
26
27
28
29
30
31
32
33
34
35
GRIDE-DATA.indication
{
RPCId,
FunctionDomain,
FunctionCategory,
ManufacturerCode,
FunctionIdentifier,
FunctionParameters
}
The table below specifies the parameters of the GRIDE-DATA.indication primitive.

Page 139
Table 163: GRIDE-DATA.indication Parameters

Name
Type
Valid Range
Description
RPCId
Integer
Implementation
specific
Identifier of the remote procedure call

corresponding to the received request frame
FunctionDomain
unsigned 8 bit
integer
0 to 255

used
FunctionCategory
unsigned 8 bit
integer
0 to 255
A valid function category as defined by the

application using GRIP received in the request
frame
ManufacturerCode
unsigned 16 bit
integer
0 to 65535
If the function category is equal to 0x00, the

manufacturer code provided in the received request
FunctionIdentifier
unsigned 16 bit
integer
0 to 65535
A function identifier as defined by the application

using GRIP in the request received in the request
frame
FunctionParameters
Octet String
Variable
The parameters of the function called on the local

entity
8. 2. 1 .2 .2 W hen g ene r at ed
4
5
The primitive is generated by the GRIP layer and issued to the NHLE on receipt an appropriately
addressed and secured frame by the SCoP layer via the SCDE-DATA.indication primitive.
6
7
8
9
The Service parameter of the SCDE-DATA.indication shall indicate the GRIP service and the Data
parameter shall be well formatted to represent a GRIP request frame with the frame control field
indicating a request otherwise the received frame is discarded and the GRIDE-DATA.indication is not
generated.
10
11
12
13
14
15
16
17
18
The GRIDE shall check that the transaction identifier field is not already in use by checking the entry
of the RPC table defined in 8.4.1.2.1. If an entry matching both the handle of the SCDEDATA.indication Handle parameter and the transaction identifier field of the GRIP request frame, the
GRIDE shall not generate the GRIDE-DATA.indication primitive. Then the GRIDE shall check that
the value of the RPC header are correctly formatted and copy these fields into the FunctionDomain,
FunctionCategory, ManufacturerCode and FunctionIdentifier respectively. If the FunctionCategory is
not 0x00, the manufacturer code field shall be omitted in the frame and the ManufacturerCode
parameter is non-significant. The GRIP request payload shall be copied into the FunctionParameters
parameter of the primitive.
19
20
21
An entry shall be created by the GRIDE in the RPC table with a unique RPC identifier field, the handle
of the SCoP connection where the GRIP request has been received, the transaction identifier field and
all the fields of the RPC header from the GRIP request.
22
23
24
25
26
27
When this primitive is received, the NHLE is notified that a remote GRIP entity is calling a function on
the local entity. The NHLE is in charge of identifying the function and eventually of performing it or
not according to the NHLE capability, policy and RPC binding specification. Upon execution of the
NHLE operations, the NHLE is in charge of generating the GRIDE-DATA.response primitive with the
RPCId parameter equal to the RPCId parameter of the received indication.
Page 140

8. 2. 1 .3 G RI D E- D AT A. r e sp on s e
2
3
4
5
6
The primitive is generated by the NHLE in order to send a GRIP response frame after reception of a
prior GRIP request through the GRIDE-DATA.indication primitive normally followed by the
execution of the function identified by this request. The response is sent back to the originator of the
request to complete the transaction and return the status of the RPC operation and if available the
results of the function called by the originator of the request.

GRIDE-DATA.response
9
10
11
12
13
14
15
{
RPCId,
Status,
FunctionResults
}
The table below specifies the parameters of the GRIDE-DATA.response primitive.
16
Table 164: GRIDE-DATA.response Parameters

Name
Type
Valid Range
Description
RPCId
Integer
Implementation
specific
Identifier of the remote procedure call that matches

the initial request received
Status
unsigned 16
bit integer
0 to 65535
Status code indicating the current status of the RPC

call and being one of the following values defined in
Table 174: SUCCESS,
UNSUPPORTED_FUNCTION,
BAD_PARAM_FORMAT
FunctionResults
Octet String
Variable
The results of the function called on the local entity
17
18
8. 2. 1 .3 .2 W hen g ene r at ed
19
20
21
The primitive is generated by the NHLE and issued to the GRIDE after reception and processing of a
GRIP request frame as described in the GRIDE-DATA.indication primitive. The value of the RPCId in
the response shall match the one issued by the indication.
22
23
24
25
26
27
28
29
If the NHLE did not recognize the function to perform because the function identified did not match a
supported function, the Status parameter shall be set to UNSUPPORTED_FUNCTION. If the NHLE
finds out that the FunctionParameters of the initial GRIDE-DATA.indication primitive did not match
the expected format for the parameters of the function to perform, the Status parameter shall be set to
BAD_PARAM_FORMAT. For any other case of error occurring in the NHLE while attempting to
perform the function and retrieve its results, the Status parameter shall be set to FUNCTION_ERROR.
If any of these errors occurs, the NHLE should generate the GRIDE-DATA.response primitive with the
FunctionResults parameter left empty.
30
31
32
If the NHLE successfully performs the function identified in the request, the Status parameter shall be
set to SUCCESS and the FunctionResults shall be set with the results returned by the function
according to the specific binding specification to be used by the NHLE.

Page 141
2
3
4
When this primitive is generated, the GRIDE shall look into the RPC table for an entry whose RPC
identifier field matches the value of the RPCId parameter of the primitive. If such entry cannot be
found, no further processing shall be done.
5
6
7
8
9
10
11
12
13
14
15
The GRIDE shall retrieve from this entry the transaction identifier and the identifier fields of the
function performed and use the Status and FunctionResults parameters of the primitive to build the
GRIP PDU of the response frame as follows. The RPC function header of the frame is built using the
FunctionDomain, FunctionCategory, ManufacturerCode and FunctionIdentifier. If the
FunctionCategory is equal to 0x00 the manufacturer code is provided in the frame header, otherwise
the manufacturer code field is omitted in the frame header. The frame payload shall be formatted with
the RPC status field and results payload field respectively equal to the Status parameter and to the
FunctionResults parameter of the primitive. The GRIDE shall then issue the SCDE-DATA.request
primitive with the Handle equal to the connection open with the peer entity and with the Data equal to
the GRIP PDU. Upon reception of the SCDE-DATA.confirm the entry of the RPC table shall be
erased.
16
8. 2. 1 .4 G RI D E- D AT A. c onf ir m
17
18
The primitive reports the results received in the response from a remote entity to a previous function
call to the next higher layer.
19
20

GRIDE-DATA.confirm
21
22
23
24
25
26
{
Status,
FunctionResults
}
The table below specifies the parameters of the GRIDE-DATA.confirm primitive.
27
Table 165: GRIDE-DATA.confirm Parameters

Name
Type
Valid Range
Description
Status
unsigned 8
bit integer
0 to 255
Status code indicating the current status of the

transaction.
FunctionResults
Octet String
Variable
The parameters of the function called on the remote

peer
28
Page 142

8. 2. 1 .4 .2 W hen g ene r at ed
2
3
4
5
6
7
8
9
10
11
The GRIDE-DATA.confirm primitive may be generated by the GRIP layer on receipt of an

appropriately addressed and secured GRIP response frame by the SCoP sub-layer via the SCDEDATA.indication under the following conditions. The Status parameter shall be equal to SUCCESS,
the Service parameter shall indicate a GRIP service frame and the Data parameter represents the GRIP
PDU. The frame control field of the GRIP PDU shall indicate that the frame is a GRIP response frame.
The transaction identifier field of the GRIP PDU shall be matched with the transaction identifier of an
initial request to match the initial GRIDE-DATA.request. The Status parameter of the GRIDEDATA.confirm primitive shall be the value of the RPC status field of the GRIP response payload. If
this status is not equal to SUCCESS, the FunctionResults shall be left empty. Otherwise the result data
field of the GRIP response payload shall be copied into the FunctionResults parameter.
12
13
14
15
This primitive may also be generated by the GRIDE if the SCoP sub-layer reports a termination of the
SCoP connection with the peer entity that was addressed by the initial GRIP request through the
SCME-CLOSE.confirm primitive or through the SCME-CLOSE.indication primitive. The Status
parameter shall be set to CONNECTION_CLOSED and the FunctionResults is left empty.
16
17
18
19
This primitive may also be generated by the GRIDE if the GRIP response corresponding to the initial
GRIP request is not received after duration equal to the sum of the attributes
gripFunctionTimeout+scopTurnaroundTimeout. The Status parameter shall be set to RPC_TIMEOUT
and the FunctionResults is left empty.
20
21
22
The GRIDE-DATA.confirm primitive shall be synchronized after the initial GRIDE-DATA.request in

order for the NHLE to maintain the relationship between the initial function call on the remote entity
and the results returned or the error code returned.
23
24
25
26
27
On receipt of this primitive, the NHLE is notified of the results of the function previously called or of
the error code returned. If the reception of the results was successful, the Status parameter will be set to
SUCCESS and the FunctionResults will indicate the results of the function performed remotely.
Otherwise, the Status parameter indicates the error status and the FunctionResults is left empty.
28
29
8. 2. 2 G RI P M anag em ent Se rv i ce
30
31
This set of primitives defines how the next higher layer of a device can read and write attributes in the
GRIB.
32
8. 2. 2 .1 G RIM E- G ET . req ue st
33
8. 2. 2 .1 .1 S em ant ic s of t he Se r v ic e P ri mit iv e
34
35
36
37
38
39
GRIME-GET.request
{
GRIBAttribute
}
The table below specifies the parameters of the GRIME-GET.request primitive.

Page 143
Table 166: GRIDE-GET.request Parameters

Name
GRIBAttribute
Type
Integer
Valid Range
See Table 173:
GRIP Information
Base
Description
The identifier of the GRIB attribute to read.
8. 2. 2 .1 .2 W hen G ene r at ed
3
4
This primitive is generated by the next higher layer and issued to its GRIME in order to read an
attribute from the GRIB.
8. 2. 2 .1 .3 Ef f ec t o n Re c eipt
6
7
8
9
10
On receipt of this primitive, the GRIME attempts to retrieve the requested GRIB attribute from its
database. If the identifier of the GRIB attribute is not found in the database, the GRIME issues the
GRIME-GET.confirm primitive with a status of UNSUPPORTED_ATTRIBUTE. If the requested
GRIB attribute is successfully retrieved, the GRIME issues the GRIME-GET.confirm primitive with a
status of SUCCESS such that it contains the GRIB attribute identifier and value.
11
8. 2. 2 .2 G RIM E- G ET .c onf ir m
12
This primitive reports the results of an attempt to read the value of an attribute from the GRIB.
13
14

GRIME-GET.confirm
15
16
17
18
19
20
21
22
{
Status,
GRIBAttribute,
GRIBAttributeLength,
GRIBAttributeValue
}
The table below specifies the parameters of the GRIME-GET.confirm primitive.
Page 144

Table 167: GRIDE-GET.confirm Parameters

Name
Type
Valid Range
Description
Status
Enumeration
SUCCESS or
The result of the request to read an

GRIB attribute value.
GRIBAttribute
Integer
See Table 173: GRIP

Information Base
The identifier of the GRIB attribute

that was read
GRIBAttributeLength
Integer
0x0001-0xffff
The length, in octets, of the attribute

value being returned.
GRIBAttributeValue
Various
Attribute Specific
The value of the GRIB attribute that

was read
8. 2. 2 .2 .2 W hen G ene r at ed
3
4
5
6
This primitive is generated by the GRIME and issued to its next higher layer in response to an GRIMEGET.request primitive. This primitive returns a status of SUCCESS, indicating that the request to read
an GRIB attribute was successful, or an error code of UNSUPPORTED_ATTRIBUTE. The reasons for
these status values are fully described in sub-clause 8.2.2.1.3 .
8
9
10
On receipt of this primitive, the next higher layer is notified of the results of its request to read an
GRIB attribute. If the request to read an GRIB attribute was successful, the Status parameter will be set
to SUCCESS. Otherwise, the Status parameter indicates the error.
11
8. 2. 2 .3 G RIM E- S ET .r equ e st
12
13
14
15
16
17
18
19
20
GRIME-SET.request
{
GRIBAttribute,
GRIBAttributeLength,
GRIBAttributeValue
}
The table below specifies the parameters of the GRIME-GET.request primitive.

Page 145
Table 168: GRIDE-SET.request Parameters

Name
Type
Valid Range
Description
GRIBAttribute
Integer
See Table 173:

GRIP Information
Base
The identifier of the GRIB attribute to read.
GRIBAttributeLength
Integer
0x0001-0xffff
The length, in octets, of the attribute value being set.
GRIBAttributeValue
Various
Attribute Specific
The value of the GRIB attribute that should be

written
8. 2. 2 .3 .2 W hen G ene r at ed
3
4
This primitive is to be generated by the next higher layer and issued to its GRIME in order to write the
value of an attribute in the GRIB.
6
7
8
9
10
11
12
On receipt of this primitive, the GRIME attempts to write the given value to the indicated GRIB
attribute in its database. If the GRIBAttribute parameter specifies an attribute that is not found in the
database, the GRIME issues the GRIME-SET.confirm primitive with a status of
UNSUPPORTED_ATTRIBUTE. If the GRIBAttributeValue parameter specifies a value that is outside
the valid range for the given attribute, the GRIME issues the GRIME-SET.confirm primitive with a
status of INVALID_PARAMETER. If the requested GRIB attribute is successfully written, the
GRIME issues the GRIME-SET.confirm primitive with a status of SUCCESS.
13
8. 2. 2 .4 G RIM E- S ET .co nf i rm
14
15

GRIME-SET.confirm
16
17
18
19
20
21
{
Status,
GRIBAttribute
}
The table below specifies the parameters of the GRIME-SET.confirm primitive.
22
Table 169: GRIDE-SET.confirm Parameters

Name
Type
Valid Range
Description
Status
Enumeration
SUCCESS,
INVALID_PARAMETER or
The result of the request to write the

GRIB Attribute.
GRIBAttribute
Integer
See Table 173
The identifier of the GRIB attribute that

was written
23
8. 2. 2 .4 .2 W hen G ene r at ed
24
25
This primitive is generated by the GRIME and issued to its next higher layer in response to an GRIMESET.request primitive. This primitive returns a status of either SUCCESS, indicating that the requested
Page 146

1
2
3
value was written to the indicated GRIB attribute, or an error code of INVALID_PARAMETER or
UNSUPPORTED_ATTRIBUTE. The reasons for these status values are completely described in subclause 8.2.2.3.3.
5
6
7
On receipt of this primitive, the next higher layer is notified of the results of its request to write the
value of a GRIB attribute. If the requested value was written to the indicated GRIB attribute, the Status
parameter will be set to SUCCESS. Otherwise, the Status parameter indicates the error.
8.3
This sub-clause specifies the format of the GRIP frame (GPDU).
10
Frame Format s
Each GRIP frame consists of the following basic components:
11
A GRIP header which comprises frame controls and RPC controls
12
A GRIP payload which contains information specific to the frame type
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
8. 3. 1 T ran sm is si on O r de r
The GRIP frames are described as a sequence of fields in a specific order. All frame formats in this
sub-clause are depicted in the order in which they are transmitted by the SCoP layer, from left to right,
where the leftmost bit is transmitted first in time (big endian). Bits within each field are numbered
from 0 (leftmost and least significant) to k-1 (rightmost and most significant), where the length of the
field is k bits. Fields that are longer than a single octet are sent to the SCoP layer in order from the octet
containing the lowest-numbered bits to the octet containing the highest-numbered bits.
8. 3. 2 Re s erv ed
On transmission, all fields marked as reserved shall be set to zero. On reception, all fields marked as
reserved in this version of the specification shall be ignored.
8. 3. 3 G en e ra l P DU F ra me F orm at
The GRIP frame format is composed of a GRIP header and a GRIP payload. The GRIP header
encompasses a general header and the RPC function identification fields. The fields of the GRIP header
appear in a fixed order. The Options header will be defined in a future release of this specification and
shall be omitted until then. The manufacturer code may not be included in all frames. The general
GRIP frame shall be formatted as illustrated in figure 18.
Octets: 1
undefined
Version
Frame
control
Transaction
identifier
Options
header
General Header
29
0/2
Variable
Function Function Manufacturer Function RPC function

domain category
code
identifier
payload
RPC function identification fields
GRIP Header
GRIP payload
30
31
Figure 18: General GRIP Frame Format

Page 147
8. 3. 3 .1 V er s ion f i el d
2
3
The version field is 8-bits in length and specifies the version of the GRIP used by the sender of the
frame. The value of the version shall be set to 0x00.
8. 3. 3 .2 Fr am e Cont ro l f i eld
5
6
The frame control field is 8bits in length and contains information defining the use of other fields of the
frame and the type of frame. The frame control field shall be formatted as illustrated in figure 19.
Bits: 0-1
3-7
Frame type
Option flag
Reserved
Frame control
7
8
Figure 19: Format of the Frame Control Field
8. 3. 3 .2 .1 Fr am e T yp e Sub - F i el d
10
11
The frame type sub-field is two bits in length and shall be set to one of the non reserved values listed in
Table 170.
12
Table 170: Values of the Frame Type Sub-Field

Frame Type Value
b1 b0
Frame Type Name
00
Reserved
01
Request
10
Response
11
Reserved
13
14
15
16
A request frame type specifies that the frame is a request from a GRIP entity to a peer entity. A
response frame type specifies that the frame is a response from a GRIP entity to prior request from a
peer entity and whose destination is the peer entity originator of the initial request.
17
18
The format of the frame payload depends on this sub-field as described in the sub-clause format of
individual frame types for Request Frame and Response Frame.
19
8. 3. 3 .3 T ran sa ct ion Id ent if i e r F i eld
20
21
22
23
The transaction identifier is 16-bits in length and is used to match a frame of type response with a
frame of type request on the same communication channel between the same entities one being a ZGD
and the other being a IPHA. The transaction identifier is selected by the originator of the request and
shall be unique for this request until the response is received or the transaction failed.
24
25
26
8. 3. 3 .4 Funct ion D om a i n F ie l d
27
28
The function domain field is 8-bits in length and specifies the scope of the API used to identify the
function. The function domain ZigBee Gateway Device API has a value of 0x01.
Page 148

8. 3. 3 .5 Funct ion C at ego r y Fi eld
2
3
The function category field is 8-bits in length and specifies the category of an RPC function to be used
with this protocol. It shall be set to one of the non-reserved values listed in Table 171.
Table 171: Values of the Function Category Field

Function Category Value
Function Category Name
0x00
Manufacturer
0x01-0xff
Defined for each function domain
5
6
8. 3. 3 .6 M anuf act ur e r co de fi eld
7
8
9
The manufacturer code field is 16-bits in length and specifies the ZigBee assigned manufacturer code
for proprietary extensions to a profile. This field shall only be included in the frame if the function
category field of the frame is set to 0x00.
10
8. 3. 3 .7 Funct ion i de nt if ie r fi eld
11
12
The function identifier field is 16-bits in length and specifies a unique identifier for a function that can
be used by this RPC protocol.
13
8. 3. 3 .8 P a ylo ad
14
15
The payload field is of a variable number of octets in length and contains information specific to
individual frame types. Each of these is defined in subsequent sections.
16
8. 3. 4 For mat of In div i du al Fr am e T yp e s
17
18
GRIP is designed for data exchanged using an RPC model. There are two types of frames: the request
frames and the response frames.
19
8. 3. 4 .1 Req ue st f r a me f o rm a t
20
21
The request frame format contains the payload of a request from a GRIP entity to another GRIP entity.
A request frame carries the function called on the remote peer and its input parameters.
22
8. 3. 4 .1 .1 Req ue st F ra me H e ad er
23
24
The GRIP request frame header shall conform to the general GRIP frame. The frame type sub-field
shall be equal to 0b01.
25
8. 3. 4 .1 .2 Req ue st F ra me P a ylo ad
26
27
28
29
the next higher layer has requested the GRIP data service to transmit. For an incoming data frame, the
data payload field shall contain all or part of the sequence of octets that has been received by the SCoP
data service and that is to be delivered to the next higher layer.

Page 149
1
2
3
The payload of a request frame contains the input parameter of the remote function that is called by the
originator of the frame as illustrated in figure 20. The format of the payload for a request frame is
defined in the specific binding specification used at the NHLE.
Octets: Variable
Parameter Payload
RPC Function Payload
4
5
Figure 20: GRIP Request Frame Payload
8. 3. 4 .2 Re spo ns e f r am e f o rm at
8
9
10
The response frame format contains the payload of a response from a GRIP entity to another GRIP
entity. A response frame is sent after prior reception of a request frame and contains the results of the
function that has been called on the device emitting the response to the originator of the request.
11
8. 3. 4 .2 .1 Re spo ns e Fr a me H e a de r
12
13
The GRIP request frame header shall conform to the general GRIP frame. The frame type sub-field
shall be equal to 0b10.
14
8. 3. 4 .2 .2 Re spo ns e Fr a me Pa y loa d
15
16
17
18
19
the next higher layer has requested the GRIP data service to transmit which results in the concatenation
of an RPC Status and the results of a function. For an incoming data frame, the data payload field shall
contain all or part of the sequence of octets that has been received by the GRIP data service and that is
to be delivered to the next higher layer.
20
21
22
23
24
The payload of a response frame contains an RPC Status and the results of the function that has been
performed by the originator of the frame upon reception of a prior request frame as illustrated in figure
21. In case of error occurring after the reception of the request, the response payload will contain
information about the error. The format of the result payload is defined by the specific binding
specification used at the NHLE.
Variable
RPC Status
Result Payload
RPC Function Payload
25
26
27
Octets: 2
Figure 21: GRIP Response Frame Payload
8. 3. 4 .2 .2 . 1
Page 150
RP C S t at us F i e l d

1
2
3
4
5
6
The RPC status field is an unsigned 16 bit integer and specifies the status of the function which has
been called in a prior request. The status is either a success value or an error value. The success value is
unique and indicates that the prior request associated with this response was successfully received and
well formatted, that the function in this request has been successfully performed and that the payload of
the response contains the result of the function. It does not have any relation with the content of the
function itself.
7
8
9
The RPC status field may have the values: SUCCESS, BAD_PARAM_FORMAT,
TRANSACTION_ERROR, UNSUPPORTED_FUNCTION or FUNCTION_TIMEOUT which are
10
11
8.4
Functional Descript ion
12
13
14
15
16
17
18
8. 4. 1 Req ue st a nd Re sp on se T r ans a cti on

GRIP is designed to perform request and response transactions driven from the application layer of two
distinct entities through the GRIP data SAP as illustrated in Figure 22. It is usually required to have
some configuration and set up operation before using the GRIP data SAP like configuring attributes
and listening to incoming connection at the SCoP level. Those configuration and set up are out of the
scope of GRIP.
Originator
Application
Originator
Peer
Recipient
Peer
Recipient
Application
GRIDE-DATA.request
Request
GRIDE-DATA.response
Response
GRIDE-DATA.confirm
19
20
Figure 22: GRIP Request and Response Transaction
21
The transmission and reception of GRIP PDU is described in the next sub-clauses.
22
8. 4. 1 .1 Req ue st Emi s si on an d R e spon s e Re c ept io n
23
24
25
26
The transmission of a GRIP request PDU requires an open SCoP connection with a peer entity. SCoP
connections are managed independently of the GRIP layer and may be permanent or limited according
to the settings of the SCIB attributes. When a GRIDE-DATA.request primitive is called with valid
parameters the transmission can be accomplished through one of the following processes:
27
28
29
30
Either no SCoP connection is already available with the destination of the GRIP request and the
process is the request with connection establishment
Or a SCoP connection is already available with the destination of the GRIP request using the same
transport conditions and the process is the request through an established connection

Page 151
1
2
3
4
Figure 23 illustrates a scenario of a request with connection establishment followed by the reception of
the response and Figure 24 illustrates a scenario of a request on an established connection followed by
the reception of the response. The full specification is available in the respective sub-clause describing
the GRIDE-DATA.request and GRIDE-DATA.confirm primitives.
Application
GRIP
SCoP
GRIDE-DATA.request
SCME-OPEN.request
SCME-OPEN.confirm
SCDE-DATA.request
SCDE-DATA.confirm
GRIDE-DATA.confirm
5
6
Figure 23: GRIP Request with Connection Establishment
Application
GRIP
SCoP
GRIDE-DATA.request
SCDE-DATA.request
SCDE-DATA.confirm
GRIDE-DATA.confirm
7
8
Figure 24: GRIP Request on an Established Connection
10
8. 4. 1 .2 Req ue st R e cep t ion a nd R e spo ns e R epl y
11
12
13
Figure 25 illustrates a scenario of reception of a GRIP request and reply with a GRIP response. The full
specification is available in the respective sub-clause describing the GRIDE-DATA.indication and
GRIDE-DATA.response primitives.
Page 152

Application
GRIP
SCoP
GRIDE-DATA.response
SCDE-DATA.request
SCDE-DATA.confirm
1
2
Figure 25: GRIP Request Reception and Response Reply
8. 4. 1 .2 .1 RP C T a bl e
4
5
6
7
8
The RPC Table is used when a GRIP request is received on a recipient application to store the
information required to send back the results to the originator application. In the GRIDEDATA.response the recipient application provides an identifier which is a key to find the proper entry
in this table. The information of this entry are used to build the GRIP response frame and to transmit
the frame through the SCoP entity.
Table 172: RPC Table Entry Format

Field Name
Field Type
Valid Range
Description
RPC Identifier
Integer
Implementation
specific
Key for the RPC table entry
SCoP Handle
Integer
Implementation
specific
Handle on the communication connection managed

by the SCoP layer
Transaction Identifier
2 Octets
0x0000 to 0xffff
Transaction identifier used in the request and in the

response frames to match them
Function Domain
unsigned 8
bit integer
0 to 255

used
Function Category
unsigned 8
bit integer
0 to 255
The function category used in the request and in the

response frames
Manufacturer Code
unsigned 16
bit integer
0 to 65535
If the function category is equal to 0x00, a

manufacturer code used in the request and in the
response frames
Function Identifier
unsigned 16
bit integer
0 to 65535
The function identifier used in the request and in the

response frames
10
11
12
13
8. 4. 2 T ran sm is si on
A transmission may occur only if a SCoP connection is successfully open with the destination of the
data to transmit.

Page 153
1
2
All frames handled by or generated within the GRIP layer shall be constructed according to the general
frame format specified in Figure 18 and transmitted using the SCoP sub-layer data service.
3
4
5
6
If the frame is a GRIP request, the frame type sub-field of the frame control field shall be set to 0b01
and the transaction identifier field shall be an integer value that is not used for the frames of another
GRIP request being processed. Otherwise if the frame is a GRIP response, it shall be set to 0b10 and
the transaction identifier field shall be the transaction field from a previous request.
7
8
When the frame is constructed and ready for transmission, it shall be passed to the SCoP data service.
A GRIP PDU transmission is initiated by issuing the SCDE-DATA.request primitive
9
10
e to the SCoP sub-layer. The SCDE-DATA.confirm primitive then returns the status of the
transmission.
11
8. 4. 3 Re c ept i on an d Re je ct ion
12
In order to receive data, an entity shall have an open SCoP connection with one or more entities.
13
14
15
Once one or more SCoP connections are open, the GRIP layer will begin to receive frames via the
SCoP data service through the SCDE-DATA.indication. If the Service parameter does not indicate a
GRIP service frame, the frame shall be discarded and no further processing shall be performed.
16
If the frame type sub-field of the frame control field is not 0b01 or 0b10, the frame shall be discarded.
17
18
19
20
21
22
23
If the frame type sub-field is 0b01, the frame is a request. The GRIDE shall check that the transaction
identifier field is not already in use by checking the entry of the RPC table. If an entry matching both
the handle of the SCDE-DATA.indication Handle parameter and the transaction identifier field of the
GRIP request frame, the GRIDE shall build a GRIP response frame by copying the header fields of the
request except the frame type sub-field which is set to 0b10 and set the RPC status field of the payload
to TRANSACTION_ERROR. The response frame shall be sent through the connection where the
request were received using the SCDE-DATA.request primitive of the SCoP sub-layer.
24
25
26
27
28
29
30
31
32
If there isn't any entry in the RPC table matching the handle and the transaction identifier field, the
frame is processed as specified for the GRIDE-DATA.indication primitive. If the GRIDEDATA.response is not generated with the same RPCId parameter as the one issued in the GRIDEDATA.indication primitive after gripFunctionTimeout, the transaction shall be considered aborted by
the GRIDE and the GRIDE shall build a GRIP response frame by copying the header fields of the
request stored in the RPC table, the frame type sub-field shall be set to 0b10 and the RPC status field of
the payload shall be set to FUNCTION_TIMEOUT. The response frame shall be sent through the
connection where the request were received using the SCDE-DATA.request primitive of the SCoP sublayer.
33
34
If the frame sub-field is 0b10, the frame is a response. The frame is processed as specified for the
GRIDE-DATA.confirm primitive.
35
8. 4. 4 Clo si ng t he C onn e ct i on w ith a Pe e r
36
37
The connection with a peer entity is not explicitly closed by the GRIP layer. It shall be possible for the
application layer to configure a timeout for a SCoP connection using the SCIB configuration attributes.
38
8.5
39
The GRIP Information base (GRID) comprised the attributes required to manage the GRIP protocol.
GRIP Information Base
Page 154

Table 173: GRIP Information Base

Attribute
Identifier
gripFunctionTimeout
0xf0
Type
16-bits Integer
Range
Description
0 to 65535
The maximum duration in

milliseconds to wait for the
execution of a function on a
local entity.
Default
10000
2
3
8.6
GRIP Laye r Status Values
5
6
7
8
GRIP layer response primitive and confirmation primitives include a parameter that reports on the
status of the request to which the response or the confirmation applies. Values for GRIP layer Status
parameters are either the status value reported from the SCoP layer specified in Table 160 or appear in
Table 174.
Table 174: GRIP Layer Extra Status Values

Name
Value
Description
SUCCESS
0x0000
An RPC operation has been executed successfully
Reserved for SCoP status values
0x00010x00ff
See Table 160.
CONNECTION_CLOSED
0x0100
The connection with a remote entity has been closed during an

RPC operation
RPC_TIMEOUT
0x0101
The maximum duration allowed for an RPC operation elapsed

without returning the results of the function that was called
TRANSACTION_ERROR
0x0200
A GRIP request is received with a transaction identifier which

already matches a function being performed by the NHLE on
this entity
FUNCTION_TIMEOUT
0x0201
The maximum duration allowed to wait for the execution of a

function on the local entity where the function is performed
elapsed
UNSUPPORTED_FUNCTION
0x0300
The RPC header of a GRIP request which has been received

refers to a function that is not supported by the NHLE on this
entity
BAD_PARAM_FORMAT
0x0301
The parameters received to execute the function have a bad

format
FUNCTION_ERROR
0x0302
Any error occurring in the NHLE when attempting to perform

the function and retrieve its results which differs from the
UNSUPPORTED_FUNCTION and the
BAD_PARAM_FORMAT error status
10
11

Page 155
9.1
3
4
5
6
A ZGD application may be used as a GRIP server to allow an IPHA application to remotely call a
function on the ZGD and get back the results. A ZGD application may also be used as a GRIP client in
order to remotely call a function on the IPHA in relationship with an event occurring on the ZGD and
get back the results from the IPHA.
7
8
9
The GRIP binding with a remote function is done by identifying uniquely a function by function
domain, function category and function identifier and by sending the parameters in a GRIP request and
receiving the results in a GRIP response.
10
11
12
GRIP is an RPC protocol intended for lightweight gateway devices like the ZGD. The GRIP stack is
defined in section 7 of this document. It is based on the SCoP protocol defined in section 7 of this
document.
13
9.2
14
GRIP Binding for ZGD

General Description
RPC Protocol Descri ption
9. 2. 1 T ran spo rt
15
16
17
18
The transport and format of the RPC exchanges in the all the GRIP binding section are assumed to use
GRIP. GRIP specifies the GRIDE-SAP which defines how a request is issued by a client entity and
how it is formatted, how the server entity processes the request and prepares the response and how the
client entity receives back the response. GRIP stack is defined in section 7 of this document.
19
20
21
GRIP is based on SCoP which offers a socket management layer and a security service. The security
service (SCoSS) can be configured in the SCIB. SCoP protocol is defined in section 7 of this
document.
22
9. 2. 2 ZG D an d IP H A Ap pl i c at i ons
23
A ZGD may support procedures and event handlers described in section 4.1 of this document.
24
25
26
In order to support procedures with GRIP, a ZGD application shall support the GRIP server
implementation for ZGD. An IPHA that wants to call procedures on such ZGD shall support the GRIP
client specification for IPHA. Section 9.2.3 specifies the ZGD implementing a GRIP server.
27
28
29
30
31
To support event handler with GRIP a ZGD shall allow callbacks with GRIP as RPC protocol.
Defining a callback with GRIP as RPC protocol specifies that the ZGD shall use GRIP when calling an
event handler on the IPHA. The ZGD application shall also support the GRIP client implementation for
ZGD in order to be able to call an event handler on an IPHA and the IPHA shall support the GRIP
server specification for IPHA. Section 9.2.4 specifies the ZGD implementing a GRIP client.
32
33
34
35
9. 2. 3 ZG D im pl em ent ing a G RI P S e rv e r
A ZGD application implementing the GRIP server allows an IPHA implementing the GRIP client to
call a procedure on the ZGD using a GRIP request and is able to send back the results using a GRIP
response. Figure 26 illustrates a procedure call using GRIP.
Page 156

IPHA
Application
IPHA
GRIP Client
ZGD
GRIP Server
ZGD
Application
Call procedure f(p)

GRIDE-DATA.request
GRIP Request
Execute f(p) and

return results r=f(p)
GRIDE-DATA.response
GRIP Response
Process results
r=f(p)
GRIDE-DATA.confirm
1
2
Figure 26: Procedure call using GRIP
3
4
GRIP security is provided by the SCoP layer within SCoSS. Configuring the security is detailed in
9.2.5.
5
6
7
8
9
10
11
12
By default the GRIP server of the ZGD application shall listen to incoming requests on SCoP Transport
Mode 0 and 1 (UDP and TCP) on the assigned IANA port as specified in Table 154. If the ZGD
supports SCoP Transport Mode 2, by default the GRIP server of the ZGD application shall also listen
to secured connection using TLS on the assigned IANA port. The ZGD may be configured by an
unspecified mean to listen to other ports than the assigned IANA ports or to listen to only specific
SCoP Transport Modes. The ZGD application shall set up its SCoP entity in order to listen to the
incoming requests by using the SCME-LISTEN.request and by proceeding as described in section
7.2.1.1.7.2.
13
14
15
16
17
18
19
20
21
22
When an IPHA sends a GRIP request to the ZGD, the ZGD application is notified of the incoming
request by the GRIDE-DATA.indication primitive and shall identify the function, extract the
parameters of the function and execute the function as described in section 8.4.1.2. To identify the
function the ZGD application first considers the FunctionCategory parameter of the primitive. If the
FunctionCategory doesn't indicate a vendor specific function, the FunctionIdentifier indicates the one
associated with the procedure called as indicated in Table 178. If the request is successfully received
and the function successfully performed, the ZGD application shall invoke the GRIDE-DATA.response
primitive as described in section 8.2.1.3.2 with the FunctionResults parameter of this primitive set to
the results of the function as defined in the abstract definition of the function. The encoding of the
results is given in Table 178 and specified in section 9.3.1.
23
24
If the ZGD application is able to detect that it is configured behind a NAT, it may configure the SCoP
entity to send keep alive messages when connections are open (see 7.4.4).
25
26
The following figure describes the typical operations of a ZGD application implementing the GRIP
server.

Page 157
ZGD
Application
ZGD
GRIP Server
ZGD
SCoP Server
Configure SCoP security

SCME-LISTEN.request
SCME-LISTEN.confirm
Perform the
function
GRIDE-DATA.response
Perform the
function
GRIDE-DATA.response
...
1
2
3
4
5
6
7
8
9
10
11
Figure 27: Operations of a ZGD Application Implementing the GRIP Server
In summary, a ZGD implementing the GRIP server:

Shall support the SCoSS of SCoP
Shall support SCME-LISTEN.request and SCME-LISTEN.confirm primitives of SCoP SAP
Shall support GRIDE-DATA.indication and GRIDE-DATA.response primitives of GRIP SAP
9. 2. 3 .1 Funct ion s Supp ort ed

A ZGD application implementing the GRIP server shall be able to execute the functions listed in Table
175 which have a status of mandatory (M) and may support the functions which have a status of
optional (O).
12
13
Table 175: Functions Supported by a ZGD implementing the GRIP Server

Function Name
GetVersion
Get
Set
CreateCallback
PollCallback
DeleteCallback
ListCallbacks
PollResults
Updatetimeout
StartNodeDiscovery
ReadNodeCache
ReadServiceCache
StartGatewayDevice
Page 158
Function Category
Implementation
status
GMO
GMO
GMO
GMO
GMO
GMO
GMO
GMO
GMO
GMO
GMO
GMO
GMO
GMO
GMO
GMO
M
M
O
M
O
M
M
O
O
O
O
O
O
O
O
M

CreateAliasAddress
DeleteAliasAddress
ListAliasAddresses
SendZDPCommand
SendZCLCommand
GetNodeDescriptor
GetNodePowerDescriptor
GetUserDescriptor
ConfigureEndpoint
ClearEndpoint
SendAPSMessage
AddGroup
RemoveGroup
RemoveAllGroups
GetGroupList
GetBindingList
SendInterPANMessage
FormNetwork
StartRouter
Join
Leave
DiscoverNetworks
Reset
PerformEnergyScan
SendNWKMessage
GMO
GMO
GMO
GMO
GMO
ZDP
ZCL
APS
APS
APS
APS
APS
APS
APS
APS
APS
APS
APS
APS
APS
INTRPAN
NWK
NWK
NWK
NWK
NWK
NWK
NWK
NWK
NWK
O
O
O
O
O
O
O
O
O
O
O
O
M
M
M
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
2
3
4
5
9. 2. 4 ZG D im pl em ent ing a G RI P C li ent

A ZGD application implementing the GRIP client is able to call an event handler on an IPHA using a
GRIP request and to get back the results in a GRIP response. Figure 28 illustrates an event handler call
using GRIP.
ZGD
Application
Call event handler
f(p)
ZGD
GRIP Client
IPHA
GRIP Server
IPHA
Application
GRIDE-DATA.request
GRIP Request
Execute f(p) and

return results r=f(p)
GRIDE-DATA.response
GRIP Response
Process results
r=f(p)
GRIDE-DATA.confirm
6
7
Figure 28: Event Handler Call using GRIP

Page 159
1
2
GRIP security is provided by the SCoP layer within SCoSS. Configuring the security is detailed in
9.2.5.
3
4
5
6
7
Each function that a ZGD application implementing the GRIP client supports shall be called using the
GRIP client under two conditions. The first condition is that an event associated with the function in
the present specification occurs in the ZGD. The second condition is that at least a callback exists
whose filter is matching the event and whose action specifies using the GRIP client. Such callbacks
will be used by the ZGD to call the function specified by the event on a remote IPHA.
8
9
10
11
12
13
14
15
When these conditions are fulfilled, the ZGD application shall use the GRIDE-DATA.request primitive
with the parameters DestIPAddress, DestPort, TransportMode and SecurityLevel set according to the
the value of the callback action. The FunctionCategory, ManufacturerCode and FunctionIdentifier
parameters shall be set to identify the function being called. If the FunctionCategory doesn't indicate a
vendor specific function, the FunctionIdentifier shall be the one associated with the event handler to
call as indicated in Table 178. Furthermore FunctionParameter shall be set to the value of the
parameters of the event handler as specified in the abstract definition of the event handler. The
encoding of these parameters is given in Table 178 and specified in section 9.3.1.
16
17
18
19
20
21
22
After issuing the GRIDE-DATA.request primitive, the ZGD application shall expect the GRIDE to
issue a GRIDE-DATA.confirm primitive. If the Status of the GRIDE-DATA.confirm primitive is
SUCCESS the ZGD application shall check that the FunctionCategory, ManufacturerCode and
FunctionIdentifier parameters are identical to those of the initial GRIDE-DATA.request and shall
decode the FunctionResults parameter according to the general description of result decoding specified
in 9.3.1 and to the encoding of the result of the event handler given in Table 178. Figure 29 illustrates
these operations of a ZGD Application implementing a GRIP client.
ZGD
Application
ZGD
GRIP Client
ZGD
SCME
Configure ZISS security
Call a
function
GRIDE-DATA.request
GRIDE-DATA.confirm
Call a
function
GRIDE-DATA.request
GRIDE-DATA.confirm
23
24
Figure 29: Operations of a ZGD Application implementing the GRIP client
25
9. 2. 4 .1 Funct ion s Supp ort ed
26
27
28
A ZGD application implementing the GRIP client shall support the functions listed in Table 176 which
have a status of mandatory (M) and may support the functions which have a status of optional (O).
Page 160

Table 176: Functions Supported by a ZGD implementing the GRIP Client

Function Name
Function Category
Implementation
status
GMO
GMO
GMO
GMO
GMO
ZDP
ZCL
APS
INTRPAN
NWK
NWK
NWK
NWK
NWK
NWK
NWK
O
O
O
O
M
M
M
M
O
O
O
O
O
O
O
O
NodeDiscoveryEvent
NodeLeaveEvent
LeaveEvent
StartGatewayDeviceEvent
NotifyZDPEvent
NotifyZCLEvent
NotifyAPSMessageEvent
FormNetworkEvent
JoinEvent
DiscoverNetworksEvent
PerformEnergyScanEvent
NetworkStatusEvent
PerformRouteDiscoveryEvent
NotifyNWKMessageEvent
2
9. 2. 5 S ec ur it y O p e r at io ns
3
4
5
6
7
8
A ZGD shall support the global CCM* security using the SCIB attributes scopCCMSecurityLevel,
scopKey, scopOutgoingFrameCounter and scopIncomingFrameCounterSet and may support the CCM*
security per peer entity using the SCIB attributes scopPeerSecurityMaterialSet. For both client and
server configuration on the ZGD, if CCM* security shall be used, the SCIB shall be configured with
the security materials to be used in the communication with the IPHA. The configuration of CCM*
security material in the ZGD is out of the scope of this specification.
9
10
11
For both client and server configuration on the ZGD, if the SCoP Transport Mode 2 (TLS) shall be
used, the ZGD shall be configured with the security materials to be used in the communication with the
IPHA. The configuration of TLS security material in the ZGD is out of the scope of this specification.
12
9.3
13
ZGD Functions
9. 3. 1 P ar am et e rs and R es u lts En cod ing
14
9. 3. 1 .1 G en e ra l En co ding Ru le s
15
16
17
Using the GRIP binding, the parameters and respectively the results of the functions are encoded and
decoded using the rules defined in this sub-clause before being used in the GRIDE primitives in the
FunctionParameters parameter and respectively in the FunctionResults parameter.
18
19
20
21
The encoding and decoding rules for the parameters and results are the Distinguished Encoding Rules
of ASN.1 (DER) which are described in 0. In order to be able to perform this encoding and decoding
the parameters and results are described using ASN.1 (ASN.1 reference is 0). The module describing
the function parameters and results using ASN.1 is given in Annex B of this document.

Page 161
1
2
3
4
5
6
7
8
The function parameters (FunctionParams) are either procedure parameters (ProcedureParams) or

event handler parameters (EvtHandlerParams). The procedure parameters are composed of some
general parameters (GeneralProcParams) as defined in sub-clause 5.2 and specific parameters
(DataParams). The general procedure parameters may be either none or a timeout ( Timeout)
parameter or a timeout plus a callback name (CallbackParams). The event handler parameters are
composed of some general parameters (GeneralEvthParams) as defined in sub-clause 5.2 and
specific parameters (DataParams). The general event handler parameters may be either none or a
timeout (Timeout) or a request identifier (RequestId).
9
10
11
12
13
14
15
The function results (FunctionResults) are either procedure results (ProcedureResults) or event
handler results (EvtHandlerResults). The procedure results are composed of some general results
(GeneralProcResults) as defined in sub-clause 5.2 and specific results (DataResults). The
general procedure results may be either a status code (Status) or a status plus a request identifier
(RequestId) results. The event handler results are composed of some general results
(GeneralEvthResults) as defined in sub-clause 5.2 and specific results (DataResults). The
general event handler results are always a status code (Status).
16
17
The use of general parameters and respectively general results in a function with the GRIP binding
shall comply with the abstract definition of the functions in section 6.
18
19
20
21
22
23
24
25
26
27
The specific parameters and results of a function are either described with subsequent ASN.1 notation
with the StructParams respectively the StructResults definition or with a SimpleType (integer
or a string of octets). For any function supported by the GRIP binding the corresponding encoding style
of the parameters and of the results is specified as simple type or as structure. If they are defined
as a simple type, the encoding of the parameters respectively the results is either an integer or an octet
string. If they are defined using a structure in ASN.1, the encoding of the parameters respectively the
results is given for each function by specifying how the ASN.1 definition of the parameters
respectively the results is one of the possible choice for the StructParams and respectively the
StructResults ASN.1 definition. The specification of these encodings function by function is given
in the next sub-clause.
28
9. 3. 1 .2 Funct ion s Spe c if i c P ar a met e rs and R e sult s En co ding
29
30
The following subclauses specify the rules of encoding for the data parameters and data results of the
functions.
31
32
If a structure contains a field that is encoded as an octet string that reference to a field in the ZigBee
specification, this field shall be encoded according to ZigBee Specification.
33
9. 3. 1 .2 .1 G at ew a y M anag em en t P r ofi le
34
9. 3. 1 .2 .1 . 1
35
Parameters Encoding
36
There is no parameter.
37
Results Encoding
38
Style: structure
39
The GetVersionResults structure shall be used to encode the parameters.
G et V er s i on
40
Page 162

9. 3. 1 .2 .1 . 2
G et
Parameters Encoding
Style: simple type
The AttributeId field is a 8-bit Integer.
Results Encoding
Style: simple type
7
8
The Value field is an octet string. Integers that are encoded as octet string shall be represented as octet
string in most-significant-order first order.
9
10
9. 3. 1 .2 .1 . 3
S et
11
Parameters Encoding
12
Style: structure
13
14
15
The SetParams structure shall be used to encode the parameters. The Value field is an octet string.
Integers that are encoded as octet string shall be represented as octet string in most-significant-order
first order.
16
Results Encoding
17
There is no specific results.
18
19
9. 3. 1 .2 .1 . 4
Cr e at e Ca l l bac k
20
Parameters Encoding
21
Style: structure
22
The FilterAction structure shall be used to encode the parameters.
23
Results Encoding
24
Style:simple type blob
25
The callbackId field is 32-bit integer. The Integer32 simple type is used to encode the result.
26
27
9. 3. 1 .2 .1 . 5
P ol l C al l b ac k
28
Parameters Encoding
29
Style: simple type
30
The CallbackId field is 32-bit integer. The Integer32 simple type is used to encode the parameter.
31
Results Encoding
Page 163
Style: structure
The PollCallbackResults structure shall be used to encode the results.
3
4
9. 3. 1 .2 .1 . 6
De l et eC a l lb ac k
Parameters Encoding
Style: simple type
The CallbackId field is 32-bit integer. The Integer32 simple type is used to encode the parameter.
Results Encoding
10
11
9. 3. 1 .2 .1 . 7
L is t Ca l l B ac k s
12
Parameters Encoding
13
14
Results Encoding
15
Style: structure
16
The ListCallbacksResults structure shall be used to encode the results.
17
18
9. 3. 1 .2 .1 . 8
P ol l R es u l ts
19
Parameters Encoding
20
Style: simple type
21
The RequestId field is 32-bit integer. The Integer32 simple type is used to encode the parameter.
22
Results Encoding
23
Style:structure.
24
This depends on the actuating procedure results encoding.
25
26
9. 3. 1 .2 .1 . 9
27
Parameters Encoding
28
Style: structure
Page 164
Up d at eT im eo ut

The UpdateTimeoutParams structure shall be used to encode the results.
Results Encoding
4
5
9. 3. 1 .2 .1 . 10 St ar tN o de D is c o v er y
Parameters Encoding
Style: structure
The StartNodeDiscoveryParams structure shall be used to encode the parameters.
Results Encoding
10
11
12
9. 3. 1 .2 .1 . 11 No d eD is c o ver yE v e n t
13
Parameters Encoding
14
Style: structure
15
The NodeDiscoveryEventParams structure shall be used to encode the parameters.
16
Results Encoding
17
18
19
9. 3. 1 .2 .1 . 12 No d eL e a ve E v e nt
20
Parameters Encoding
21
Style: structure
22
The NodeLeaveEventParams structure shall be used to encode the parameters.
23
Results Encoding
24
25
26
9. 3. 1 .2 .1 . 13 Re a dN od e Cac h e
27
Parameters Encoding
28

Page 165
Results Encoding
Style: structure
The NodeCacheResults structure shall be used to encode the results.
4
5
9. 3. 1 .2 .1 . 14 St ar t Ser v ic eD is c o v er y
Parameters Encoding
Style: structure
The DestinationAddress structure shall be used to encode the parameters.
Results Encoding
10
There is no specific result.
11
12
9. 3. 1 .2 .1 . 15 S er v ic e D is c o v er yE v e n t
13
Parameters Encoding
14
Style: structure
15
The structure ServiceDiscoveryEventParams shall be used to encode the parameters.
16
Results Encoding
17
18
9. 3. 1 .2 .1 . 16 G et S er v ic eD es c r ip t or
19
Parameters Encoding
20
21
Results Encoding
22
23
9. 3. 1 .2 .1 . 17 S er v ic e D is c o v er yE v e n t
24
Parameters Encoding
25
Style: structure
26
The structure ServiceDescriptor shall be used to encode the parameters.
27
Results Encoding
28
Page 166

9. 3. 1 .2 .1 . 18 Re a dS er v ic eC ac he
Parameters Encoding
Results Encoding
Style: structure
The structure ReadServiceCacheResults shall be used to encode the parameters.
7
8
9. 3. 1 .2 .1 . 19 St ar tG at e wa yD e v ic e
Parameters Encoding
10
Style: structure
11
The structure GatewayStartParams shall be used to encode the parameters.
12
Results Encoding
13
Style: simple type
14
The NWKStatus field is a 8-bit Integer. The Integer8 simple type is used to encode the result.
15
16
9. 3. 1 .2 .1 . 20 St ar tG at e wa yD e v ic e E v en t
17
Parameters Encoding
18
Style: simple type
19
The NWKStatus field is a 8-bit Integer. The Integer8 simple type is used to encode the parameter.
20
Results Encoding
21
22
23
9. 3. 1 .2 .1 . 21 Co nf i g ur e S ta r t up A ttr i b ut e Se t
24
Parameters Encoding
25
Style: structure
26
The structure GatewayStartParams shall be used to encode the parameters.
27
Results Encoding
28
29
Page 167
9. 3. 1 .2 .1 . 22 Re a dS t ar t u p At tr i b ut e S et
Parameters Encoding
Style: simple type
4
5
The StartupAttributeSetIndex field is a 8-bit Integer. The Integer8 simple type is used to encode this
parameter.
Results Encoding
Style: structure
The structure StartupAttributeSet shall be used to encode the parameters.
9
10
9. 3. 1 .2 .1 . 23 Cr e at e A l ias A d dr es s
11
Parameters Encoding
12
Style: structure
13
The CreateAliasAddressParams structure shall be used to encode the parameters.
14
Results Encoding
15
16
17
9. 3. 1 .2 .1 . 24 De l et e A l ias A d dr es s
18
Style: simple type
19
The Alias field is an octet string.. The Octet string simple type is used to encode this parameter.
20
Results Encoding
21
22
23
9. 3. 1 .2 .1 . 25 L is t A ddr es s es
24
Style: structure
25
The structure ListAddressesParams shall be used to encode the results.
26
Results Encoding
27
Style: structure
28
The structure ListAddressesResults shall be used to encode the results.
29
Page 168

9. 3. 1 .2 .2 ZigB e e D ev ic e P r ofi l e
9. 3. 1 .2 .2 . 1
Parameters Encoding
Style: structure
The structure ZDPCommandParams shall be used to encode the results.
Results Encoding
Style: structure
The structure ZDPCommandResults shall be used to encode the results.
S en dZ D PC om m and
9
10
9. 3. 1 .2 .2 . 2
No t if yZ D P E ve nt
11
Parameters Encoding
12
Style: structure
13
The structure ZDPCommandResults shall be used to encode the parameters.
14
Results Encoding
15
16
17
9. 3. 1 .2 .3 ZigB e e Cl ust e r Lib r ar y
18
9. 3. 1 .2 .3 . 1
19
Parameters Encoding
20
Style: structure
21
The structure ZCLCommandParams shall be used to encode the parameters.
22
Results Encoding
23
Style: structure
24
The structure ZCLCommandResults shall be used to encode the parameters.
S en dZ CL C om m and
25
26
9. 3. 1 .2 .3 . 2
No t if yZ CL E v e nt
27
Parameters Encoding
28
Style: structure
Page 169
The structure ZCLCommandResults shall be used to encode the parameters.
Results Encoding
9. 3. 1 .2 .4 Ap pl i cat ion Sup po rt La ye r
9. 3. 1 .2 .4 . 1
Parameters Encoding
Style: structure
The structure NodeDescriptor shall be used to encode the parameters.
Co nf i g ur e N od eD es c r i p tor
10
Results Encoding
11
12
13
9. 3. 1 .2 .4 . 2
G et N od eD es c r i pt or
14
Parameters Encoding
15
16
Results Encoding
17
Style: structure
18
The structure NodeDescriptor shall be used to encode the results.
19
20
9. 3. 1 .2 .4 . 3
G et N od e P o wer D ec r i pt or
21
Parameters Encoding
22
23
Results Encoding
24
Style: structure
25
The structure NodePowerDescriptor shall be used to encode the results.
26
27
9. 3. 1 .2 .4 . 4
28
Parameters Encoding
Page 170
Co nf i g ur e Us er D es c r ip t or

Style: simple type
The User Descriptor is an octet string. The Octet String simple type is used to encode the parameter.
Results Encoding
5
6
9. 3. 1 .2 .4 . 5
G et Us er D es c r ip t or
Parameters Encoding
Results Encoding
10
Style: simple type
11
The User Descriptor is an octet string. The Octet String simple type is used to encode the result.
12
13
9. 3. 1 .2 .4 . 6
Co nf i g ur e E n d Po i nt
14
Parameters Encoding
15
Style: structure
16
The structure ConfigureEndpointParams shall be used to encode the parameters.
17
Results Encoding
18
19
20
9. 3. 1 .2 .4 . 7
Cl e ar En d P o in t
21
Parameters Encoding
22
Style: simple type
23
The ZigBeeEndpoint field is a 8-bit Integer. The Integer8 simple type is used to encode the parameter.
24
Results Encoding
25
26
27
9. 3. 1 .2 .4 . 8
S en d A P SM es s a ge
28
Parameters Encoding

Page 171
Style: structure
The structure APSCommandParams shall be used to encode the results.
Results Encoding
Style: structure
The structure APSMessageResults shall be used to encode the results.
6
7
9. 3. 1 .2 .4 . 9
No t if yA P S M e s s a ge E v e nt
Parameters Encoding
Style: structure
10
The structure NotifyAPSMessageEventParams shall be used to encode the results.
11
Results Encoding
12
13
14
9. 3. 1 .2 .4 . 10 A ddG r o u p
15
Parameters Encoding
16
Style: structure
17
The structure GroupParams shall be used to encode the parameters.
18
Results Encoding
19
20
21
9. 3. 1 .2 .4 . 11 Rem o veG r o u p
22
Parameters Encoding
23
Style: structure
24
The structure GroupParams shall be used to encode the parameters.
25
Results Encoding
26
27
28
9. 3. 1 .2 .4 . 12 Rem o ve A l lG r o ups
Page 172

Parameters Encoding
Style: simple type.
The ZigBeeEndpoint field is a 8-bit Integer. The Integer8 simple type is used to encode this parameter.
Results Encoding
6
7
9. 3. 1 .2 .4 . 13 G etG r o u pL is t
Parameters Encoding
10
Results Encoding
11
Style: structure
12
The structure GetGroupListResults shall be used to encode the results.
13
14
9. 3. 1 .2 .4 . 14 G et B i nd i n gL is t
15
Parameters Encoding
16
17
Results Encoding
18
Style: structure
19
The structure GetBindingListResults shall be used to encode the results.
20
21
9. 3. 1 .2 .5 Int er P AN M e s sag e
22
9. 3. 1 .2 .5 . 1
23
Parameters Encoding
24
Style: structure
25
The structure SendInterPANMessageParams shall be used to encode the parameters.
26
Results Encoding
27
Style: structure
28
The structure INTRPANCommandResults shall be used to encode the results.
S en dI n ter P A N Mes s a g e

Page 173
1
2
9. 3. 1 .2 .5 . 2
No t if yI n ter P A N Mes s a g e E ve nt
Parameters Encoding
Style: structure
The structure NotifyInterPANMessageEventParams shall be used to encode the parameters.
Results Encoding
9. 3. 1 .2 .6 Net w or k L a ye r
10
9. 3. 1 .2 .6 . 1
For m Net wo r k
11
Parameters Encoding
12
Style: structure
13
The structure FormNetworkParams shall be used to encode the parameters.
14
Results Encoding
15
Style: simple type
16
The NWKStatus field is 8-bit Integer. The Integer8 simple type is used to encode the result.
17
18
9. 3. 1 .2 .6 . 2
For m Net wo r k E ve n t
19
Parameters Encoding
20
Style: simple type
21
The NWKStatus field is 8-bit Integer. The Integer8 simple type is used to encode the parameter.
22
Results Encoding
23
24
25
9. 3. 1 .2 .6 . 3
26
Parameters Encoding
27
Style: structure
28
The structure StartRouterParams shall be used to encode the parameters.

Page 174
St ar tR o ut er

Results Encoding
Style: simple type
4
5
9. 3. 1 .2 .6 . 4
Parameters Encoding
Style: simple type
Results Encoding
10
St ar tR o ut er E ve n t
There is no specific result..
11
12
9. 3. 1 .2 .6 . 5
J o in
13
Parameters Encoding
14
Style: structure
15
The structure JoinParams shall be used to encode the parameters.
16
Results Encoding
17
Style: simple type
18
19
20
9. 3. 1 .2 .6 . 6
J o in E v e nt
21
Parameters Encoding
22
Style: simple type
23
The NWKStatus field is 8-bit Integer. The Integer8 simple type is used to encode this parameter.
24
Results Encoding
25
26
27
9. 3. 1 .2 .6 . 7
Le a v e
28
Parameters Encoding

Page 175
Style: structure
The structure LeaveParams shall be used to encode the parameters.
Results Encoding
Style: simple type
6
7
9. 3. 1 .2 .6 . 8
Le a v e E ve n t
Parameters Encoding
Style: simple type
10
The NWKStatus field is 8-bit Integer. The Integer8 simple type is used to encode the parameters.
11
Results Encoding
12
13
14
9. 3. 1 .2 .6 . 9
Dis c o v er N e t wor k s
15
Parameters Encoding
16
Style: structure
17
The structure DiscoverNetworksParams shall be used to encode the parameters.
18
Results Encoding
19
Style: structure
20
The structure DiscoverNetworksResults shall be used to encode the results.
21
22
9. 3. 1 .2 .6 . 10 Dis c o v er N e t wor k s E ve nt
23
Parameters Encoding
24
Style: structure
25
The structure DiscoverNetworksResults shall be used to encode the parameters.
26
Results Encoding
27
28
29
9. 3. 1 .2 .6 . 11 Res et
Page 176

Parameters Encoding
Style: simple type
The WarmStart field is a BOOLEAN. The BOOLEAN simple type is used to encode the parameter.
Results Encoding
Style: simple type
7
8
9. 3. 1 .2 .6 . 12 Res et E ve n t Ha n d ler
Parameters Encoding
10
Style: simple type
11
12
Results Encoding
13
14
15
16
9. 3. 1 .2 .6 . 13 P er f or m En er g yS c a n
17
Parameters Encoding
18
Style: structure
19
The structure DiscoverNetworksParams shall be used to encode the parameters.
20
Results Encoding
21
Style: structure
22
23
The structure PerformEnergyScanResults shall be used to encode the results.
24
9. 3. 1 .2 .6 . 14 P er f or m En er g yS c a n E v en t
25
Parameters Encoding
26
Style: structure
27
The structure PerformEnergyScanResults shall be used to encode the parameters.
28
Results Encoding
29
30
31
9. 3. 1 .2 .6 . 15 Ne t wor k St a t us E v e nt
Page 177
Parameters Encoding
Style: structure
The structure NetworkStatusEventParams shall be used to encode the parameters.
Results Encoding
6
7
9. 3. 1 .2 .6 . 16 P er f or m Ro ut eD is c o v er y
Parameters Encoding
Style: structure
10
The structure PerformRouteDiscoveryParams shall be used to encode the parameters.
11
Results Encoding
12
Style: structure
13
The structure PerformRouteDiscoveryResults shall be used to encode the results.
14
15
9. 3. 1 .2 .6 . 17 P er f or m Ro ut eD is c o v er yE v e n t
16
Parameters Encoding
17
Style: structure
18
The structure PerformRouteDiscoveryResults shall be used to encode the parameters.
19
Results Encoding
20
21
22
9. 3. 1 .2 .6 . 18 S en dNW KMes s ag e
23
Parameters Encoding
24
Style: structure
25
The structure SendNWKMessageParams shall be used to encode the parameters..
26
Results Encoding
27
Style: structure
28
The structure SendNWKMessageResults shall be used to encode the results.
29
30
9. 3. 1 .2 .6 . 19 No t if yNW KMes s ag e E v en t
Page 178

1
2
Parameters Encoding
Style: structure
The structure NotifyNWKMessageEventParams shall be used to encode the results.
Results Encoding
7
8
9. 3. 2 Funct ion I de nt if ic at i on
9. 3. 2 .1 Funct ion D om ai n
10
The function domain shall be the ZigBee Gateway Device domain as defined by GRIP.
11
9. 3. 2 .2 Funct ion C at ego r ie s
12
13
The Table 177 defines the function categories available for the ZigBee Gateway Device and the range
for the identifiers of the functions within each category.
14
Table 177: Values of the Function Category Field for ZGD

Function Category
Value
Function Category Name
Function identifiers range
0x00
Manufacturer
0x0000 to 0x00FF
0x01
GMO
0x0100 to 0x01FF
0x02
ZDP
0x0200 to 0x02FF
0x03
ZCL
0x0300 to 0x03FF
0x04
APS
0x0400 to 0x04FF
0x05
INTERPAN
0x0500 to 0x05FF
0x06
NWK
0x0600 to 0x06FF
0x07-0xFF
Reserved
0x0600 to 0xFFFF
15
16
9. 3. 2 .3 Funct ion I de nt if ie r s
17
18
The Table 178 defines the function identifiers available for the GRIP RPC binding with the
corresponding abstract functions defined in section 8.4 and the parameters and results encoding style.
19
Table 178: Function Identifiers of ZGD domain for GRIP Binding
Abstract
Function
Reference
Function
Category
Function
Identifier
Parameters Encoding
Results Encoding

Page 179
GetVersion
GMO
0x0100
Get
Set
GMO
GMO
CreateCallback
GetVersionParams structure
0x0101
0x0102
No param
Octet String simple
type
SetParams structure
GMO
0x0103
FilterAction structure
Integer32 simple type
PollCallback
GMO
0x0104
PollCallbackResults structure
DeleteCallback
GMO
0x0105
No specific result.
ListCallbacks
GMO
0x0106
No param
PollResults
GMO
0x0107
ListCallbacksResult structure
structure, depends on the
procdedure results to be
polled
UpdateTimeout
GMO
0x0108
No specific result
StartNodeDiscov
ery
GMO
0x0109
StartNodeDiscoveryPar
ams structure
No specific result
NodeDiscoveryE
vent
GMO
0x010A
NodeDiscoveryEventPa
rams structure
No specific result
No specific result
Octet String simple type

No specific result.
NodeLeaveEvent
GMO
0x010B
NodeLeaveParams
structure
ReadNodeCache
GMO
0x010C
No parameter
NodeCacheResults structure
StartServiceDisc
overy
GMO
0x010D
DestinationAddress
structure
No specific result
ServiceDiscover
yEvent
GMO
0x010E
Params structure
No specific result
ReadServiceCac
he
GMO
0x010F
No param
ReadServiceCacheResults
structure
StartGatewayDe
vice
GMO
0x0110
GatewayStartParams
structure
Page 180

StartGatewayDe
viceEvent
GMO
0x0111
No specific result.
ConfigureStartup
AttributeSet
GMO
0x0112
GatewayStartParams
structure
No specific result.
ReadStartupAttri
buteSet
GMO
0x0113
StartupAttributeSet structure
CreateAliasAddr
ess
GMO
0x0114
CreateAliasAddressPar
ams structure
No specific result.
DeleteAliasAddr
ess
GMO
0x0115
Octet String simple

type
No specific result.
ListAliasAddress
es
GMO
0x0116
ListAddressesParams
structure
ListAddressesResults
SendZDPComma
nd
ZDP
0x0200
ZDPCommandParams
structure
ZDPCommandResults
structure
NotifyZDPEvent
ZDP
0x0201
ZDPCommandResults
structure
No specific result.
SendZCLComma
nd
ZCL
0x0300
ZCLCommandParams
structure
ZCLCommandResults
structure
NotifyZCLEvent
ZCL
0x0301
ZCLCommandResults
structure
No specific result.
ConfigureNodeD
escriptor
APS
0x0400
NodeDescriptor
structure
No specific result.
GetNodeDescript
or
APS
0x0401
No param
NodeDescriptor structure
GetNodePowerD
escriptor
APS
0x0402
No param
NodePowerDescriptor
structure
ConfigureUserD
escriptor
APS
0x0403
Octet String simple

type
No specific result.
GetUserDescript
or
APS
0x0404
No param
Octet String simple type

Page 181
ConfigureEndpoi
nt
APS
0x0405
ConfigureEndpointPara
ms structure
No specific result.
ClearEndpoint
APS
0x0406
No specific result.
SendAPSMessag
e
APS
0x0407
APSCommandParams
structure
APSCommandResults
structure
NotifyAPSMessa
geEvent
APS
0x0408
NotifyAPSMessageEve
ntParams structure
No specific result.
AddGroup
APS
0x0409
GroupParams structure
No specific result.
RemoveGroup
APS
0x040A
GroupParams structure
No specific result.
RemoveAllGrou
ps
APS
0x040B
No specific result.
GetGroupList
APS
0x040C
No param
GetGroupListResults
structure
GetBindingList
APS
0x040D
GetBindingListResults
structure
GetBindingListResults
structure
SendInterPANM
essage
INTRPAN
0x0500
SendInterPANMessage
Params structure
SendInterPANMessageResult
s structure
NotifyInterPAN
MessageEvent
INTRPAN
0x0501
NotifyInterPANMessag
eEventParams structure
No specific result.
FormNetwork
NWK
0x0600
FormNetworkParams
structure
FormNetworkEv
ent
NWK
0x0601
No specific result
StartRouter
Join
JoinEvent
NWK
NWK
NWK
0x0602
0x0603
0x0604
StartRouterParams
structure
JoinParams structure

No specific result
Leave
NWK
0x0605
LeaveParams structure
LeaveEvent
NWK
0x0606
No specific result.
Page 182

DiscoverNetwor
ks
NWK
0x0607
DiscoverNetworksPara
ms structure
DiscoverNetworksResults
structure
DiscoverNetwor
ksEvent
Reset
NWK
NWK
0x0608
0x0609
DiscoverNetworksResu
lts structure
Boolean simple type
No specific result.
PerformEnergyS
can
NWK
0x060A
DiscoverNetworksPara
ms structure
PerformEnergyScanResults
structure
PerformEnergyS
canEvent
NWK
0x060B
PerformEnergyScanRes
ults structure
No specific result.
NetworkStatusEv
ent
NWK
0x060C
NetworkStatusEventPar
ams structure
No specific result.
PerformRouteDis
covery
NWK
0x060D
PerformRouteDiscover
yParams structure
PerformRouteDiscoveryResu
lts structure
PerformRouteDis
coveryEvent
NWK
0x060E
PerformRouteDiscover
yResults structure
No specific result.
SendNWKMessa
ge
NWK
0x060F
SendNWKMessagePara
ms structure
SendNWKMessageResults
structure
NotifyNWKMes
sageEvent
NWK
0x0610
NotifyNWKMessageEv
entParams structure
No specific result.

Page 183
10 SO AP Binding
10.1 General Description
3
4
5
6
SOAP is a protocol for exchanging XML-based messages over computer networks, normally using
HTTP/HTTPS. SOAP forms the foundation layer of the Web services stack, providing a basic
messaging framework upon which abstract layers can be built. SOAP is widely supported by nearly all
modern operating systems and programming languages and is a canonical web service protocol.
10.2 Transport
8
9
The ZGD shall support SOAP on HTTP transport and may support SOAP on HTTPS transport. The
configuration of SSL security material is implementation specific.
10
10.3 WSDL
11
12
13
14
15
A ZGD and IPHA shall implement their SOAP services using the XML Schema document in 0 and the
ZGD SOAP WSDL in 0. The WSDL specifies a ZGDService and an IPHAService service. The
ZGDService server-side is instantiated on the ZGD and the IPHA acts as a client accessing the service
to invoke procedures. The IPHAService server-side is instantiated on the IPHA and the ZGD acts as a
client accessing the service to invoke event handlers.
16
10 . 3. 1 Inf o rm at ion B as e At t rib ut e T yp e s
17
18
19
The SOAP interface will map basic Information Base attribute types to simple types according to Table
179. Attributes that are sets of information are declared as a complex type with elements declared as
simple types.
20
Table 179: SOAP Simple Information BaseType Mappings

Information Base Type
SOAP Type
Boolean
xsd::Boolean
IEEE 802.15.4 channel mask
gal::unsigned32Bit
64-bit extended address
gal::IeeeAddress
Integer
Smallest type of the following that can represent the range of the attribute:
Bit vector
unsigned64Bit, unsigned32Bit, unsigned16Bit, unsigned8Bit
16-bit PAN ID
gal::PanId
21
Page 184


Page 185
11 REST Binding
11.1 General Description
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Representational State Transfer (REST) is a software architectural style that refers to the following
principles: application state and functionality are divided into resources, every resource is uniquely
addressable using a universal syntax for use in hypermedia links, and all resources share a uniform
interface for transferring a state between client and resource.
State transfer is accomplished by using the HTTP (or HTTPS) protocol, so these resources can be
manipulated by using the four basic operations: Create, Read, Update, Delete (CRUD- using HTTP
methods POST, GET, PUT and DELETE)
This principle is applied to the communication between IPHA and ZGD by defining a set of resources
(specifying for ZGD, a Zigbee network or a Zigbee node), tagging them with an URI, and identifying
each function with a state transfer between the IPHA and that resource. For instance the GetVersion
function, used by the IPHA to discover the features of a ZGD, is identified as a read operation on the
version resource of the ZGD.
As usual with REST interfaces, state information is transferred by using XML documents, so attached
to this document is an XML schema that defines the contents and structure of the messages exchanged
between the IPHA and the ZGD. Of course most tags defined in this schema are shared with the XML
schema the SOAP binding defines.
This clause is structured in this way: first of all all the resouces relevant to the function bindings are
identified; each of them is associated to a specific URI and supports a subset of the four possible HTTP
methods. After that, this annex will define the protocol rules specific for this binding, i.e. how to map
request and responses, how to handle callbacks and events. Finally, each function defined in the former
sections of this document is mapped to an HTTP operation, using the resources and rules defined in the
first part of the annex.
25
11.2 Resources
26
27
28
29
This subclause defines the set of resources on which the IPHA can operate. Since REST interfaces use
the HTTP protocol, in order to address them, each resource must be associated to an HTTP URL. The
object of an HTTP URL is to identify which IP host (and port) to contact and the path to a resource on
that host that the client needs to access. For instance, the following URL:
30
http://192.168.15.2:1792/restifc/zgd/version
31
32
points to the zgd/restifc/version resource of the HTTP server listening at the port 1792 of
the host owning the network interface 192.168.15.2.
33
34
Regarding the path to the resource (i.e. /restifc/zgd/version in our example), it can be
further divided into two subparts:
35
The path shared by all the resources of the ZGD (/restifc/zgd);
36
The path of the resource actually accessed (/version).
37
38
39
40
41
42
The first subpath (prefix) is typically needed when offering many different services on the same HTTP
interface (e.g. /mgmt/index.html may be the path to an administrative web interface), and can
be used to give a scope the the set of resources being accessed. In this specification, this scoping
techinque is used to separate the addressing space of ZGD resources from the addressing space of
Zigbee networks and Zigbee nodes resources. Proceeding with the same example, the following
URLs:
43
44
http://192.168.15.2:1792/restifc/zgd/net/default/callbacks
http://192.168.15.2:1792/restifc/zgd/net/default/wsnnodes/12/services
Page 186

1
2
3
4
can be used to access the list of callbacks active on a specific network, and the services offered by node
12 on that network. These resources use a different prefix (/restifc/zgd/net/default) that
prevents overlapping of resources belonging to the ZGD and a network or belonging to two different
networks.
5
6
From now on, the hostport and the prefix will be called Gateway Root URI when used to access the
ZGD resources or Network Root URI when accessing a network, e. g. in the example above:
http://192.168.15.2:1792/restifc/zgd/
http://192.168.15.2:1792/restifc/zgd/net/default
9
10
are respectively a Gateway Root URI and a Network Root URI. Note that in most cases, a ZGD will
provide a single Gateway Root URI and one Network Root URI for each Zigbee network it can reach.
11
12
13
This version of the document does not specify any rule about the format of a Gateway Root URI: it is
expected that the host part will be the address of a network interface of the ZGD, but it does not specify
any preferred port or path prefix.
14
15
16
17
The IPHA shall know the Gateway Root URI by means that are beyond the scope of this specification
(e.g. local configuration, DNS techinques). The Network Root URI, on the other hand, can be
obtained by appending the net/network-id suffix. The string network-id , here, is a
placeholder for:
18
19
20
The string default when the IPHA delegates the ZGD to choose one of the network it can
reach. This is typically used when the ZGD is equipped with only one transceiver, so it can
only reach a network at a time, however it may also be used in other cases;
21
22
23
24
The Extended PAN ID of the network the IPHA whishes to reach. This identifier shall be
expressed as a zero-padded number of 16 hex digit (e.g. 0011223344556677). If the
ZGD cannot reach any network with a corresponding Extended PAN ID, the HTTP request
shall fail with a 404 (Not found) status code.
25
26
27
The following table contains the list of resources associated to a ZGD; all the paths are relative to the
Gateway Root URI. The paths may contain some placeholders (e.g. [attr]) whose format is
described in detail in the last subclause of this annex.
28
Table 180: Gateway Resources

Resource Path
Description
Method
Function
/version
Gateway version
GET
GetVersion
/ib/[attr]
Information Base
GET
Get
PUT
Set
PUT
UpdateCallbackTimeout
GET
PollResultsProcedure
POST
FormNetwork
/requests/[rid]
/networks
Pending REST requests
Networks attached to the

ZGD
StartRouter
Join

Page 187
GET
DiscoverNetworks
/energy
Energy scan reports
GET
PerformEnergyScan
/networks/[addr]
A specific network attached

to the ZGD
DELETE
Leave
/reset
Reset command
PUT
Reset
/startup
Startup attribute sets
POST
StartGatewayDevice
GET
/net/[epid]
Network resources
1
Table 181: Network Resources
2
Resource Path
Description
Method
Function
/ib/[attr]
Information Base
GET
Get
PUT
Set
POST
CreateCallback
GET
ListCallbacks
GET
PollCallback
DELETE
DeleteCallback
POST
CreateAliasAddress
GET
ListAddresses
/callbacks
/callbacks/[name]
/aliases
Active Callbacks for a network
Callback
Address aliases
/aliases/[alias]
Address Alias
DELETE
DeleteAliasAddress
/discovery
Route Discovery function
POST
/wsnnodes
ZigBee nodes in a network
GET
StartNodeDiscovery
ReadNodeCache
/wsnnodes/[addr]
/localnode
/allwsnnodes
A ZigBee node identified by

address, the ZGD as a Zigbee
node, or broadcast to all the
nodes. See Table 182 for
subtree.
POST
SendZDPCommand
SendNWKMessage
SendInterPANMessage
Page 188

Table 182: Network Resources: /wsnnodes subtree
1
Resource Path
Description
Method
Function
Leave network
DELETE
Leave procedure
/services
Active Services.
GET
ReadServiceCache
POST
ConfigureEndpoint
Active service
(endpoint)
GET
See Table 183 for

subtree
DELETE
ClearEndpoint
Node Descriptor
PUT
GET
GetNodeDescriptor
PUT
ConfigureNodePowerDescriptor
GET
PUT
GET
GetUserDescriptor
Group Addresses
and associated
endpoints
GET
GetGroupList
POST
AddGroup
/epgroups/[ep]
Group Addresses
associated to a
specific endpoint
DELETE
RemoveAllGroups
/epgroups/[ep]/[group]
Group Address to
endpoint
association
DELETE
RemoveGroup
/bindings
Device Bindings
GET
GetBindingList
/permitjoin
Permit join
POST
PermitJoin
/services/[ep]
/nodedescriptor
/powerdescriptor
/userdescriptor
/epgroups
Power Descriptor
User Descriptor
2
Table 183: Network Resources: /wsnnodes/services subtree
3
Resource Path
Description
Method
Function
/wsnconnection
Active Callbacks on a network
POST
CreateCallback
/wsconnection/message
Message I/O
POST
SendZCLCommand

Page 189
SendAPSMessage
1
11.3 REST Interface
11 . 3. 1 P ro ce du re s
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
As a natural consequence of the model described so far, a procedure (i.e. a function invoked by an
IPHA on a ZGD) maps to an HTTP transaction accessing one of the resources listed in the above
sections. In particular, a procedure request maps to an HTTP request and a procedure response maps to
an HTTP response. The ZGD shall support REST on HTTP and may support REST on HTTPS
transports.
The method of HTTP requests (GET, POST, PUT or DELETE), the request parameters and (in case the
method is POST) the root XML type forming the body of the request depend on the specific function,
so they are specified in the subsections below. Command parameters may be conveyed either as
request parameters or be embedded into the XML body posted with the request: the first mechanism is
preferred for parameters that affect how the operation is performed, while the request body is used to
transfer parameters that modify the state of the ZGD.
If an HTTP transaction fails for transport specific reasons (e.g. badly formatted HTTP header, resource
not found, permissions denied), the HTTP response generated by the ZGD shall carry a non-success
status code (i.e. a code geater or equal to 300) and the contents of the body (if present) may contain
additional information about the cause of the failure.
If the HTTP transaction succeeds, or if it fails while the REST binding is processing it, the status code
shall be 200 (Ok) and the XML body shall contain an XML document with root tag of type Info,
defined as:
<complexType name=Info>
<sequence>
<element name=Status type=Status/>
<element name=RequestIdentifier type=unsigned32Bit
minOccurs=0/>
<element name=Detail>
<complexType>
<sequence>
<element name=Version
minOccurs=0 maxOccurs=1>
<element name=Value
minOccurs=0 maxOccurs=1>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
The Detail element shall be used as a choice, i.e. only one of the possible XML tags it contains can
be used to encode the response body. The following rules apply:
If the transaction succeeds, and the CallbackDestination parameter is not supported by the
function, or it is supported but not present in the request, then the element to be used is
function-specific, and is specified for each function in the remainder of this section. The tag to
be used is called Response XML message, and is not used by all the functions;
If the transaction succeeds, and the CallbackDestination parameter is supported and present in
the request, then the element is RequestIdentifier;
If the transaction fails, the Detail element shall be omitted.
Page 190

1
2
3
4
5
6
The Status result/parameter is encoded using a complex type (Status), containing the following
elements:
Code, a mandatory integer which shall contain the value of the Status parameter;
Message, an optional message that may be used for diagnistic purposes.
A schematic representation of the encoding rules for the Detail tag is (note that these are just
examples, and the Info tag may contain additional elements besides Status and Detail):
CallbackDestination present
CallbackDestination not present
<Info>
<Info>
Successful Procedure response,
<Status>
<Status>
Response XML message is
<Code>0</Code>
<Code>0</Code>
Example
</Status>
</Status>
Successful Procedure response.

The procedure does not use a
Response XML message.
Procedure fails while processing

the request.
<Detail>
<CallbackDestination>
http://192.168.15.2/dklem
</CallbackDestination>
</Detail>
</Info>
<Info>
<Status>
<Code>0</Code>
</Status>
<Detail>
<CallbackDestination>
http://192.168.15.2/dklem
</CallbackDestination>
</Detail>
</Info>
<Info>
<Status>
<Code>3</Code>
<Message>Parameter xyz
is missing</Message>
</Status>
</Info>
<Detail>
<Example></Example>
</Detail>
</Info>
<Info>
<Status>
<Code>0</Code>
</Status>
<Detail>
<Example></Example>
</Detail>
</Info>
<Info>
<Status>
<Code>3</Code>
</Status>
</Info>
A similar representation for Events:

Event request or Event response
Success
Response XML message is Example
Success. The Event does not use a Response

XML message.
Failure
8
9
10
11
12
13
14
15
16
17
<Info>
<Status>
<Code>0</Code>
</Status>
<Detail>
<Example></Example>
</Detail>
</Info>
<Info>
<Status>
<Code>0</Code>
</Status>
</Info>
<Info>
<Status>
<Code>3</Code>
</Status>
</Info>
11 . 3. 2 Ev e nt s
An Event (i.e. a function invoked by a ZGD on an IPHA) maps to an HTTP transaction, yet it does not
access a specific resource (in fact, there are no resources associated to an IPHA), but the ZGD uses an
URI that the IPHA has previously sent to the ZGD. In particular:
When an Event is delivered to an IPHA after creating a callback, one of the parameters of the
CreateCallback REST operation will be the URI of the IPHA;
Otherwise the URI is the CallbackDestination parameter.
The only supported URIs that the IPHA can specify are HTTP or HTTPS URLs, and there are no
restrictions on its path component. The same IPHA may use different URIs when creating different
callbacks and starting different operations, for instance as a means to disambiguate events coming from
Page 191
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
different actions; however, this behaviour is not mandated, so the same an IPHA can reuse the same
URI and use other means to disambiguate.
The HTTP method the ZGD uses to deliver an Event is always POST and the parameters are always
encoded in the XML body, which is of type Info. If the Event is delivered as an outcome of a procedure
with CallbackDestination, then the body of the Event HTTP request shall be the same as the HTTP
response that would have been generated if that procedure had no CallbackDestination.
If the Event is not generated by a previous procedure with CallbackDestination, then the XML body is
of type Info, and the element to be used in the Detail choice is event-specific, and is specified for
each function in the remainder of this section.
If an HTTP event transaction fails for transport specific reasons (e.g. badly formatted HTTP header,
resource not found, permissions denied), the HTTP response generated by the IPHA shall carry a
non-success status code (i.e. a code geater or equal to 300) and the contents of the body (if present)
may contain additional information about the cause of the failure.
If the HTTP transaction succeeds, or if it fails while the REST binding is processing it, the status code
shall be 200 (Ok) and the XML body shall contain an XML document with root tag of type Info,
11 . 3. 3 G en e ra l P a ra met e r s and R e sult s
General parameters follow the same encoding rules of function-specific parameters; since they only
affect how to perform the operation, without being part of the state transferred, they are
19
Encoded as HTTP URI parameters when sent in a procedure request;
20
Encoded in the Info tag when sent in an event request;
21
22
General results follow the same encoding rules of function-specific results as well: they are always part
of the XML body as elements of the Info tag.
23
11.4 Function Mappings
24
11 . 4. 1 G en e ra l De s c ript ion
25
26
27
28
This section contains the actual bindings of functions to HTTP requests and responses according to the
rules described in the sections above. Mappings are specified by using tables, each one describing the
contents of an HTTP request or of an HTTP response.
In these mappings, the syntax of a parameter is specified by using one of these tokens:
29
Table 184: REST Parameters Syntax

Token
string
unsigned8
Range
[a-zA-Z0-9]+
0x00-0xff
unsigned16
0x0000-0xffff
unsigned32
unsigned64
0x00000000000000000xffffffffffffffff
Page 192
Description
An UTF-8 string
An 8-bit unsigned int, in
hexadecimal form, lowercase,
zero-padded and without leading
0x or trailing h.
A 16-bit unsigned int, in
0x or trailing h.
0x or trailing h.
Examples
tz9hG4bkc
f2
0f24
00f02440
00f0244000f02440

address
1
2
3
0000-sa:ffff
0000000000000000ffffffffffffffff
[a-zA-Z0-9]*
0x or trailing h.
When the Alias Address is
created the ZGD returns an error
if the chosen character sequence
could be interpreted as either a
short or extended address. Doing
so will avoid the need of any
disambiguating character for the 3
kinds of address. [a-zA-Z0-9]+
b9e2
0eac
0a0001c922a2bfe70
o4pfg249
A table which specifies a procedure contains the following entries:

URI: the HTTP Request-URI of the request, optionally followed by constant parameters.
HTTP method: the HTTP method
Request XML message: the root XML entry that shall be contained in the request body. ;
6
7
8
9
10
Response XML message: the Detail element that shall be used in the Info tag of the XML
document contained in the procedure HTTP response body (if the CallbackDestination
parameter is not supported or supported but not used) or in the event HTTP request body (in
case the CallbackDestination parameter is supported and used). If None, then the Detail
element shall be omitted.
11
12
13
14
The URI entry of this table may contain some bracketed placeholders, like [aoi]: these placeholders are
described in a subsequent table containing the following entries:
Component: the placeholder tag;
15
16
17
Syntax: the syntax of the string of characters that should be placed there. Note that string
characters must be encoded according to HTTP specification, when using special characters
(like spaces or non-ASCII chars);
18
Meaning: the function parameter this placeholder stands for.
19
20
21
22
23
24
25
Every URL contains at least one of the following placeholders (see 11.2 for their meaning):
[GwRootURI] indicating the Gateway Root URI
[NwkRootURI] indicating the Network Root URI
If the function contains any parameters, an additional table referring to the same function. These tables
map the value of each function parameter to additional HTTP parameters, and their entries are:
Function parameter name: the name of the function parameter name;
26
27
Status: M for mandatory, O for optional (this value reflects the status for the corresponding
parameter in the function definition clause);
28
29
30
URI parameter syntax: the syntax of the parameter. Note that string characters must be
encoded according to HTTP specification, when using special characters (like spaces or nonASCII chars)
31
32
33
34
35
36
37
38
39
To improve readability, general parameters, are shaded.

A table which specifies an event contains the following entries:
Request XML message: the Detail element that shall be used in the Info tag of the XML
document contained in the event HTTP resquest body;
Response XML message: the Detail element that shall be used in the Info tag of the XML
document contained in the event HTTP response body.
Note that events generated by procedures with CallbackDestination are not described using a
standalone table because all the details needed to generate the HTTP transaction are defined in the
specification of that procedure.

Page 193
11 . 4. 2 G at ew a y M anag em en t P r ofi le (G M P)
2
URI
HTTP method
Request XML message
Response XML message
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
G et V er si on P ro c edu r e
[GwRootURI]/version
GET
None
Version
G et P ro c edu r e
URI
[GwRootURI]/ib/[attr]
or
[NwkRootURI]/ib/[attr]
HTTP method
GET
Request XML message
None
Value
The first form (i.e. [GwRootURI]/ib/attr) shall be used when accessing the following information
bases:
Gateway Information Base;
The second form (i.e. [NwkRootURI]/ib/attr) shall be used when accessing the following information
bases:
Application Information Base;
Network Information Base;
Physical Information Base.
URI components:
Component
[attr]
Syntax
unsigned8
Meaning
Attribute parameter
S et P ro ce du re
URI
[GwRootURI]/ib/[attr]
HTTP method
PUT
XML message
Value
None
The first form (i.e. [GwRootURI]/ib/attr) shall be used when accessing the following information
bases:
Gateway Information Base;
The second form (i.e. [NwkRootURI]/ib/attr) shall be used when accessing the following information
bases:
Application Information Base;
Network Information Base;
Physical Information Base.
URI components:
Component
Syntax
Meaning
[attr]
Unsigned8
Attribute function parameter
Cr e ate C al lb ac k P ro c edu r e
URI
[NwkRootURI]/callbacks
HTTP method
POST
Request XML message
Callback
CallbackIdentifier
Two shorthand forms are provided:
URI
[NwkRootURI]/localnode/services/[ep]/wsnconnection
[NwkRootURI]/localnode/allservices/wsnconnection
Page 194

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
HTTP method
POST
Request XML message
None
Response
None
The first form registers a callback on incoming messages for a specific endpoint, and the second one
for incoming messages for all the endpoints. Therefore:
The first form is equivalent to a CreateCallback procedure with the following parameters:
o Filter:
LevelSpecification: APSLevel
AddressSpecification:
NwkSourceAddress unset
APSSourceEndpoint unset
APSDestinationEndpoint equal to the [ep] URI component
MessageSpecification:
APSClusterIdentifier unset
APSClusterGroup unset
o Action Parameter:
DecodeSpecification: DecodeAPSBit
ForwardingSpecification: REST, using the urilistener parameter as
CallbackDestination
The second form is equivalent to a CreateCallback procedure with the following parameters:
o Filter:
LevelSpecification: APSLevel
AddressSpecification:
NwkSourceAddress unset
APSSourceEndpoint unset
APSDestinationEndpoint unset
MessageSpecification:
APSClusterIdentifier unset
APSClusterGroup unset
o Action Parameter:
DecodeSpecification: DecodeAPSBit
ForwardingSpecification: REST, using the urilistener parameter as
CallbackDestination
URI components:
Component
Syntax
Meaning
[ep]
Unsigned8
Endpoint
URI parameters:
Function Parameter
Status
URI Pararameter Syntax Notes
name
URIListener
M
urilistener=string
The URI where incoming
messages will be posted.
Upd ateT i me out P ro c e dur e
URI
[GwRootURI]/requests/[request]
HTTP method
PUT
Request XML message
Value
None
The Value tag contains the Timeout parameter, using unsigned64 format.
URI components:
Component
Syntax
Meaning
[request]
string
Request identifier
36
URI
HTTP method
Po ll Ca ll ba c k P ro ce du re
[NwkRootURI]/callbacks/[callback]
GET
Page 195
3
4
5
6
Request XML message

URI components:
Component
[callback]
Meaning
CallbackIdentifier parameter
None
PolledMessage
Syntax
unsigned32
Po ll Re su lt s P ro ce du r e
URI
[NwkRootURI]/requests/[request]
HTTP method
GET
Request XML message
None
Same as procedure identified by RequestIndentifier
The Response XML message shall be the same as the procedure being polled, e.g. if the PollResult is
performed to check the results of a DiscoverNetworks procedure, the Response XML message tag shall
be NetworkDescriptors.
URI components:
Component
Syntax
Meaning
[request]
string
Request identifier
De let e Ca ll ba c k P ro ce dur e
[NwkRootURI]/callbacks/[callback]
DELETE
None
None
URI
HTTP method
Request XML message
URI components:
Component
[callback]
Syntax
unsigned32
URI
HTTP method
Request XML message
Lis tC al l b ac k s P ro ce d ur e
[NwkRootURI]/callbacks
GET
None
Callbacks
URI
HTTP method
Request XML message
St ar tNo de Di s cov e r y P ro ce du re
[NwkRootURI]/wsnnodes
GET
None
None
10
11
12
Meaning
CallbackIdentifier parameter
URI parameters:
Function Parameter
name
Timeout
CallbackDestination
ReportOnExistingNodes
ReportAnnountements
Page 196
Status
URI Pararameter Syntax
M
M
O
Timeout=unsigned16
urilistener=string
Inquiry
announcements
Notes
If present,
ReportOnExistingNodes is
TRUE. If not,
ReportOnExistingNodes is
FALSE
If present,
ReportAnnouncements is
TRUE. If not,
ReportAnnouncements is

ReportLeave
FALSE
If present, ReportLeave is
TRUE. If not, ReportLeave is
FALSE
leave
1
Nod eD is cov er yE v e nt Ev e nt Ha ndl e r
2
Request XML message
WSNNode
None
Nod eL eav e Ev ent Ev e nt H an dl er
3
Request XML message
WSNNode
WSNNode
URI
HTTP method
Request XML message
Re ad Nod eC a ch e P ro c edu r e
[NwkRootURI]/wsnnodes?mode=cache
GET
None
WSNNodes
5
6
7
St ar tS e rv i ce Di s cov e r y P ro ce du re
If the parameter Nwk-Address-of-Interest is unset or its value is 0xffff (i.e. broadcast), then the
request takes this format:
URI
[NwkRootURI]/allwsnnodes/services
HTTP method
GET
Request XML message
None
None
8
9
10
11
12
URI
HTTP method
Request XML message
URI components:
Component
[aoi]
[NwkRootURI]/wsnnodes/[aoi]/services
GET
None
None
Syntax
address
In both cases, URI parameters are:

Function Parameter
Status
name
Timeout
M
CallbackDestination
O
Meaning
Address-Of-Interest function parameter
Notes
timeout=unsigned16
urilistener=string
13
S erv ic eD i sc ov e r yEv e nt Ev ent H an dl e r
14
Request XML message
NodeServices
None
URI
HTTP method
Request XML message
G et S erv i c eD e sc r ipt o r P ro c edu r e

[NwkRootURI]/wsnnodes/[aoi]/services/[service]
GET
None
15

Page 197
2
3

URI components:
Component
[aoi]
[service]
None
Syntax
Address
unsigned8
In both cases, URI parameters are:

Function Parameter name
Status
Timeout
M
CallbackDestination
O
4
Request XML message
5
6
7
Meaning
Address-Of-Interest function parameter
Active Endpoint parameter

timeout=unsigned16
urilistener=string
Notes
S erv ic eD i sc ov e r yEv e nt Ev ent H an dl e r

ServiceDescriptor
None
Re ad S erv ic e Ca ch e P r oc edu r e
If the parameter Nwk-Address-of-Interest is unset or its value is 0xffff (i.e. broadcast), then the
request takes this format:
URI
[NwkRootURI]/allwsnnodes/services?mode=cache
HTTP method
GET
Request XML message
None
NodeServicesList
8
9
10
URI
HTTP method
Request XML message
URI components:
Component
[aoi]
11
12
URI
HTTP method
Request XML message
URI parameters:
Function Parameter
name
Timeout
CallbackDestination
[NwkRootURI]/wsnnodes/[aoi]/services?mode=cache
GET
None
NodeServicesList
Syntax
address
Meaning
AddressOfInterest parameter
St ar tG at ew a yD ev i ce P ro ce du re
[GwRootURI]/startup
POST
StartupAttributeInfo
None
Status
M
O
M
Timeout=unsigned16
urilistener=string
start=true
Notes
This parameter is used to

disambiguate between this
function and
St ar tG at ew a yD ev i ce E v ent Ev e nt
Han dl e r
13
14
Request XML message
Page 198
None
None

1
2
URI
HTTP method
Request XML message
URI parameters:
Function Parameter
name
4
URI
HTTP method
Request XML message
5
6
URI parameters:
Function Parameter
name
Notes
start=false

disambiguate between this
function and
StartGatewayDevice
Re ad St a rtup At t rib ute S et P ro ce du re

[GwRootURI]/startup
GET
None
Status
index=unsigned8
Notes
URI
HTTP method
Request XML message
De let e Al i a s Ad d re s s P ro ce du re
[NwkRootURI]/aliases/[alias]
DELETE
None
None
URI components:
Component
[alias]
11
13
14
15
16
Status
URI
HTTP method
Request XML message
8
12
Conf igu r eS ta rtu p Att r ibut e Set

P ro ce du re
[GwRootURI]/startup
POST
None
Cr e ate Al i a s Ad d r es s P ro ce du re
[NwkRootURI]/aliases
PUT
Alias
None
9
10
URI
HTTP method
Request XML message
URI components:
Component
[aoi]
Syntax
string
Meaning
Alias parameter
Lis t Ad dr e ss e s P ro ce dur e
[NwkRootURI]/aliases/[aoi]
GET
None
Aliases
Syntax
address
Meaning
Address of interest
By default, the URI [NwkRootURI]/aliases lists out all of the addresses. If AddressOfInterest[aoi] is
supplied then the ZGD shall return an AddressList containing only the matching address tuple if
present.
Page 199
Le av e P ro c edu r e
[NwkRootURI]/wsnnodes/[aoi]
DELETE
None
None
URI
HTTP method
Request XML message
URI components:
Component
[aoi]
URI parameters:
Function Parameter
name
Timeout
CallbackDestination
RemoveChildren
Rejoin
Syntax
address
Meaning
DeviceAddress parameter
Status
M
O
O
timeout=unsigned16
urilistener=string
remove-children
Rejoin
Request XML message

None
None
P er mit Jo in R equ e st
If the parameter Address-of-Interest is unset or its value is 0xfffc (i.e. broadcast to all routers and
coordinator), then the request takes the first format indicated below, otherwise it takes the other format.
URI
HTTP method
Request XML message
9
10
If present, the RemoveChildren function parameter is

true, otherwise it is false
If present, the Rejoin function
parameter is true, otherwise it
is false
Le av e Ev e nt Ev e nt Ha ndl er
5
6
7
8
Notes
The URI parameters are:

Function Parameter
name
Timeout
CallbackDestination
[NwkRootURI]/allwsnnodes/permitjoin
[NwkRootURI]/wsnnodes/[aoi]/permitjoin
POST
JoiningInfo
None
Status
M
O
timeout=unsigned16
urilistener=string
Notes
P er mit Jo in Ev e nt Ev e nt H an dl er
11
Request XML message
None
None
12
13
11 . 4. 3 ZigB e e D ev ic e P r of i l e
14
URI
HTTP method
Page 200
S endZ D PC omm an d P ro ce du re
POST

Request XML message

URI components:
Component
[aoi]
URI parameters:
Function Parameter
name
Timeout
CallbackDestination
ZDPCommand
ZDPMessage
Syntax
address
Meaning
Destination parameter
Status
M
O
timeout=unsigned16
urilistener=string
Request XML message

ZDPMessage
None
11 . 4. 4 ZigB e e Cl ust e r Lib r ar y
S endZ CL Com ma nd P ro ce du re
[NwkRootURI]/localnode/services/[service]/wsnconnection/message
POST
ZCLCommand
ZCLMessage
Notes
Notif yZ D P Ev ent Ev en t H and l e r
URI
HTTP method
Request XML message
URI components:
Component
[service]
URI parameters:
Function Parameter
name
Timeout
CallbackDestination
Syntax
unsigned8
Meaning
DestinationEndpoint parameter
Status
M
O
timeout=unsigned16
urilistener=string
Notes
Notif yZ CL Ev e nt Ev en t H and le r
8
Request XML message
ZCLMessage
None
9
10
11 . 4. 5 Ap pl i cat ion Sup po rt Sub - La ye r
Conf igu r eNo de De s c ri ptor P roc ed ur e

[NwkRootURI]/localnode/nodedescriptor
PUT
NodeDescriptor
None
11
URI
HTTP method
Request XML message
12
13
URI parameters:
Function Parameter
name
Timeout
Status
timeout=unsigned16
Notes

Page 201
URI
HTTP method
Request XML message
G etN od eD e sc ri pto r P ro ce du re
[NwkRootURI]/localnode/nodedescriptor
GET
None
NodeDescriptor
URI
HTTP method
Request XML message
G etN od e Pow er D es c ri ptor P roc ed ur e

[NwkRootURI]/localnode/powerdescriptor
GET
None
PowerDescriptor
3
Conf igu r eU se r De s cr i ptor P roc ed ur e
[NwkRootURI]/localnode/userdescriptor
PUT
UserDescriptor
None
URI
HTTP method
Request XML message
URI parameters:
Function Parameter
name
Timeout
6
URI
HTTP method
Request XML message
7
8
9
10
11
12
13
timeout=unsigned16
Notes
G etU s e rD es c ri pto r P r oc edu r e

[NwkRootURI]/localnode/userdescriptor
GET
None
UserDescriptor
Conf igu r eE ndpo int P ro ce du re

URI
[NwkRootURI]/localnode/services
HTTP method
POST
Request XML message
SimpleDescriptor
Endpoint
The Endpoint tag of the input SimpleDescriptor may not be present. In this case it is up to the ZGD
to choose an unused Endpoint and associate the SimpleDescriptor to that endpoint.
The ZGD shall return to the IPHA the Endpoint identifier this SimpleDescriptor has been associated to
(either the one specified by the IPHA in its SimpleDescriptor, or the Endpoint chosen by the ZGD if
the IPHA has not specified one).
URI parameters:
Function Parameter
Status
URI Pararameter Syntax Notes
name
Timeout
O
timeout=unsigned16
14
15
Status
URI
HTTP method
Request XML message
URI components:
Component
[service]
Page 202
Cl ea r En dpo int P ro c e dur e

[NwkRootURI]/localnode/services/[service]
DELETE
None
None
Syntax
unsigned8
Meaning
Endpoint parameter

URI
HTTP method
Request XML message
Response XML
message
URI components:
Component
Timeout
CallbackDestination
[service]
Meaning
timeout=unsigned16
urilistener=string
SourceEndpoint parameter
Request XML message

Notif y AP SM e ss ag e Ev ent Ev ent

Han dl e r
APSMessageEvent
None
6
URI
HTTP method
Request XML message
URI components:
Component
[endpoint]
8
URI
HTTP method
Request XML message
URI components:
Component
[endpoint]
[group]
10
11
Syntax
M
O
Unsigned8
Request XML message

4
5
S end AP SM e ss ag e P r oc edu r e
[NwkRootURI]/localnode/services/[service]/wsnconnection/message
POST
APSMessage
APSMessageResult
Nofit yS e nd AP SM e ss a ge Ev en t Han dl e r
APSMessageResult
None
URI
HTTP method
Request XML message
URI components:
Component
[endpoint]
12
URI
Ad d G rou p P ro ce du re
[NwkRootURI]/localnode/epgroups
POST
Group
None
Syntax
unsigned8
Meaning
Endpoint parameter
Re mov eG ro up P ro c e dur e
[NwkRootURI]/localnode/epgroups/[endpoint]/[group]
DELETE
None
None
Syntax
unsigned8
unsigned16
Meaning
Endpoint function parameter
GroupAddress parameter
Re mov e Al l G roup s P r oc edu r e

[NwkRootURI]/localnode/epgroups/[endpoint]
DELETE
None
None
Syntax
unsigned8
Meaning
Endpoint parameter
G etG rou pLi st P ro c ed ur e

[NwkRootURI]/localnode/epgroups
Page 203
HTTP method
Request XML message
URI parameters:
Function Parameter
name
Timeout
GET
None
Groups
Status
timeout=unsigned16
Notes
G etB ind ing Li st P ro c e dur e

[NwkRootURI]/localnode/bindings
GET
None
Bindings
2
URI
HTTP method
Request XML message
URI parameters:
Function Parameter
name
Timeout
Status
timeout=unsigned16
Notes
4
S end Int er P ANM es s ag e P ro ce du re
POST
InterPANMessage
InterPANMessageResult
URI
HTTP method
Request XML message
URI components:
Component
[aoi]
URI parameters:
Function Parameter
name
Timeout
CallbackDestination
Syntax
address
Status
M
O
timeout=unsigned16
urilistener=string
Request XML message

11 . 4. 6 Net w or k L a ye r
For mN etw or k P ro c ed ur e
[GwRootURI]/networks
POST
NetworkConfiguration
None
11
12
Notes
Notif yI nt er P ANM es s a ge Ev en t Ev e nt
Han dl e r
InterPANMessageEvent
None
8
9
10
Meaning
URI
HTTP method
Request XML message
URI parameters:
Function Parameter
name
Timeout
CallbackDestination
Page 204
Status
O
O
M
timeout=unsigned16
urilistener=string
operation=formation
Notes

disambiguate this function from

other REST operations sharing

the same method and URI.
For mN etw or k Ev ent E v ent Ha ndl e r
1
Request XML message
None
None
St ar tRo ute r P r oc edu r e
POST
NetworkConfiguration
None
URI
HTTP method
Request XML message
URI parameters:
Function Parameter
name
Timeout
CallbackDestination
Status
O
O
M
timeout=unsigned16
urilistener=string
operation=start-router
Status
O
O
timeout=unsigned16
urilistener=string
Notes
Joi n Ev ent Ev ent H an dle r
6
Request XML message
None
None
Re s et P ro ce du re
[GwRootURI]/reset
PUT
ResetInfo
None

disambiguate this function from
other REST operations sharing
the same method and URI.
Joi n P ro ce du re
POST
JoinConfiguration
None
4
URI
HTTP method
Request XML message
URI parameters:
Function Parameter
name
Timeout
CallbackDestination
Notes
URI
HTTP method
Request XML message
URI parameters:
Function Parameter
name
Timeout
CallbackDestination
9
URI
HTTP method
Request XML message
Status
O
O
timeout=unsigned16
urilistener=string
Notes
Di sc ov e rN etw or k s P r oc edu r e
GET
None

Page 205

URI parameters:
Function Parameter
name
Timeout
CallbackDestination
Scan-Channel
Scan-Duration
NetworkDescriptors
Status
O
O
M
timeout=unsigned16
urilistener=string
channel=unsigned32
duration=unsigned8
Request XML message

Scan-Duration
Scan-Channel function
parameter
Scan-Duration function
parameter
P erf or m En e rg yS c an P ro ce du re
[GwRootURI]/energy
GET
None
EnergyScanResult
Notes
Di sc ov e rN etw or k sEv ent Ev ent

Han dl e r
NetworkDescriptors
None
2
3
URI
HTTP method
Request XML message
URI parameters:
Function Parameter
name
Timeout
CallbackDestination
Scan-Channel
Status
O
O
M
timeout=unsigned16
urilistener=string
channel=unsigned32
duration=unsigned8
Notes
Scan-Channel function
parameter
Scan-Duration function
parameter
Request XML message

P erf or m En e rg yS c an E v ent Ev e nt
Han dl e r
EnergyScanResult
None
Request XML message

Netw or k St atu s Ev ent Ev e nt Ha ndl e r

DeviceNetworkStatus
None
URI
HTTP method
Request XML message
P erf or mR out eD is cov er y P r oc edu r e

[NwkRootURI]/discovery
POST
RouteDiscoveryInfo
NetworkStatusCode
Request XML message

P erf or mR out eD is cov er yE v e nt Ev ent

Han dl e r
NetworkStatusCode
None
6
7
10
11
Page 206

URI
HTTP method
Request XML message
URI components:
Component
[aoi]
3
4
Request XML message
S end NW KM es s ag e P r oc edu r e
POST
NWKMessage
NWKMessageResult
Syntax
address
Meaning
Notif yN W KM es s ag eE v ent Ev e nt
Han dl e r
NWKMessageEvent
None
5
6
7
8

Page 207
Information Base Attributes
Gatew ay Inf ormation Base
Table 185 GMO Attributes

Attribute
Id
ZigBee
Network
Status
0x00
Read
Only
Type
Byte
Yes
Range
(see Table 186)
Description
Default
Indicates the current ZigBee

network status of the ZGDs
radio interface.
Table 186 ZigBee Network Status GMO Attribute Enumeration

Name
HOLDING
Value
Description
0x00
The ZGD is waiting to be commanded to either form, join, or rejoin a

network.
INITIALIZING
0x01
The ZGD is preparing to form or join a network.
DISCOVERING
0x02
The ZGD is discovering networks within its POS.
JOINING
0x03
The ZGD is joining a network.
REJOINING
0x04
The ZGD is rejoining a network.
FORMING
0x05
The ZGD is forming a network.
AUTHENTICATING
0x06
The ZGD is authenticating itself on a network.
FORMED
0x07
The ZGD has formed a network.
JOINED
0x08
The ZGD has joined a network and if required was authenticated.
ORPHANED
0x09
The ZGD has been orphaned from a network.
UNAUTHENTICATED
0x0a
The ZGD has joined a network but was not authenticated as required.
Page 208

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
GRIP ASN.1
ZIGBEE-GATEWAY-GRIPEncoding DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
FunctionCall ::= CHOICE { parameters FunctionParams,
results FunctionResults }
FunctionParams ::= CHOICE { proc-params ProcedureParams,
evth-params EvtHandlerParams }
ProcedureParams ::= SEQUENCE { g-params GeneralProcParams,
d-params DataParams }
EvtHandlerParams ::= SEQUENCE { g-params GeneralEvthParams,
d-params DataParams }
GeneralProcParams ::= CHOICE { none NULL,
timeout Timeout,
with-callback CallbackParams }
GeneralEvthParams ::= CHOICE {
status Status8,
request-id RequestId,
with-reqId StatusRequestId,
callback-id CallbackId ,
with-callbackid StatusCallbackId }
CallbackParams ::= SEQUENCE { timeout Timeout,
callback-dest CallbackDest }
FunctionResults ::= CHOICE { proc-results ProcedureResults,
evth-results EvtHandlerResults }
ProcedureResults ::= SEQUENCE { g-results GeneralProcResults,
d-results DataResults }
EvtHandlerResults ::= SEQUENCE { g-results GeneralEvthResults,
d-results DataResults }
GeneralProcResults ::= CHOICE { status Status8,
with-reqId StatusRequestId }
GeneralEvthResults ::= Status8
StatusRequestId ::= SEQUENCE { status Status8,
request-id RequestId }
StatusCallbackId ::= SEQUENCE { status Status8,
callback-id CallbackId }
DataParams ::= CHOICE {
void NULL,
simple-type SimpleType,
struct StructParams }
SimpleType ::= CHOICE {
integer8 Integer8,
integer16 Integer16,
integer32 Integer32,
flag BOOLEAN,
octetString OCTET STRING }
StructParams ::= CHOICE {
none NULL,
get-params GetParams,
set-params SetParams,
filter-action FilterAction,
updateTimeout UpdateTimeoutParams,
start-nodeDiscovery StartNodeDiscoveryParams,
nodeLeave-event NodeLeaveEventParams,
startServiceDiscovery DestinationAddress,
nodeDiscovery-event NodeDiscoveryEventParams,
service-discovery-event ServiceDiscoveryEventParams,
startGatewayDevice GatewayStartParams,
configureStartupAttributeSet GatewayStartParams,
create-AliasAddress CreateAliasAddressParams,
list-addresses ListAddressesParams,
zdp-command ZDPCommandParams,
zdp-event ZDPCommandResults,
zcl-command ZCLCommandParams,
zcl-event ZCLCommandResults,
configure-node-descriptor NodeDescriptor,
configure-endpoint ConfigureEndpointParams,
aps-command APSCommandParams,
aps-event NotifyAPSMessageEventParams,
addGroup GroupParams,
removeGroup GroupParams,
interPAN-command SendInterPANMessageParams,
notifyInterPANMessage-event
NotifyInterPANMessageEventParams,
formNetwork-params FormNetworkParams,

Page 209
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
startRouter-params StartRouterParams,
join-params JoinParams,
leave-params LeaveParams,
discoverNetworks-params DiscoverNetworksParams,
discoverNetworks-event DiscoverNetworksResults,
performEnergyScan-params DiscoverNetworksParams,
networkStatus-event NetworkStatusEventParams,
performEnergyScan-event PerformEnergyScanResults,
performRouteDiscovery-params PerformRouteDiscoveryParams,
performRouteDiscovery-event PerformRouteDiscoveryResults,
sendNWKMessage-params SendNWKMessageParams,
notifyNWKMessage-event NotifyNWKMessageEventParams
}
DataResults ::= CHOICE {
StructResults ::= CHOICE {
void NULL,
simple-type SimpleType,
struct StructResults }
void NULL,
getVersion-results GetVersionResults,
listCallbacks-results ListCallbacksResults,
pollcallback-results PollCallbackResults,
nodecache-results NodeCacheResults,
readservicecache-results ReadServiceCacheResults,
read-startupAttributeSet StartupAttributeSet,
list-addresses-results ListAddressesResults,
zdp-results ZDPCommandResults,
zcl-results ZCLCommandResults,
get-node-descriptor NodeDescriptor,
get-node-power-descriptor NodePowerDescriptor,
sendAPSMessage-results APSCommandResults,
getGroupList-results GetGroupListResults,
getBindingList-results GetBindingListResults,
intrPAN-results INTRPANCommandResults,
discoverNetworks-results DiscoverNetworksResults,
performEnergyScan-results PerformEnergyScanResults,
performRouteDiscovery-results
PerformRouteDiscoveryResults,
sendNWKMessage-results SendNWKMessageResults
}
-- Parameters structures :
GetParams ::= SEQUENCE { attributeId Integer8,
useGIB BOOLEAN}
SetParams ::= SEQUENCE {
attributeId Integer8,
value OCTET STRING,
useGIB BOOLEAN}
FilterAction ::= SEQUENCE { filter Filter OPTIONAL,
action Action OPTIONAL}
UpdateTimeoutParams ::= SEQUENCE {
requestId RequestId,
timeout Timeout}
StartNodeDiscoveryParams ::= SEQUENCE {
reportOnExistingNodes BOOLEAN OPTIONAL,
reportAnnouncements BOOLEAN OPTIONAL,
reportLeave BOOLEAN OPTIONAL}
NodeDiscoveryEventParams ::= SEQUENCE { node-addresses NodeAddressesStruct }
NodeLeaveEventParams ::= SEQUENCE { device-nwkAddress ZigBeeNetworkAddress,
device-ieeeAddress ZigBeeIEEEAddress,
device-aliasAddress ZigBeeAliasAddress OPTIONAL}
ServiceDiscoveryEventParams ::= SEQUENCE {
device-nwkAddress ZigBeeNetworkAddress,
device-ieeeAddress ZigBeeIEEEAddress
OPTIONAL,
device-aliasAddress ZigBeeAliasAddress
OPTIONAL,
active-endpoints Integer8,
simple-descriptors SimpleDescriptorList
OPTIONAL
}
GatewayStartParams ::= SEQUENCE {
startupset-index Integer8,
startup-attributeset StartupAttributeSet }
CreateAliasAddressParams ::= SEQUENCE {
aliasAddress ZigBeeAliasAddress,
ieeeAddress ZigBeeIEEEAddress
}
ListAddressesParams ::= CHOICE {
null NULL,
nwk-address ZigBeeNetworkAddress ,
ieeeAddress ZigBeeIEEEAddress ,
Page 210

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
aliasAddress ZigBeeAliasAddress
}
ZDPCommandParams ::= SEQUENCE {
dstAddress-mode Integer8 OPTIONAL,
dst-address DestinationAddress OPTIONAL,
txoption Integer8,
radius Integer8,
clusterID ZigBeeClusterID,
command OCTET STRING }
ZCLCommandParams ::= SEQUENCE {
dst-endpoint ZigBeeEndpoint OPTIONAL,
profileID ZigBeeProfileID OPTIONAL,
src-endpoint ZigBeeEndpoint OPTIONAL,
txoption Integer8,
radius Integer8 OPTIONAL,
zcl-header OCTET STRING,
zcl-payload OCTET STRING}
ConfigureEndpointParams ::= SEQUENCE {
endpoint ZigBeeEndpoint,
simple-descriptor SimpleDescriptor
}
APSCommandParams ::= SEQUENCE {
src-endpoint ZigBeeEndpoint ,
--profileID ZigBeeProfileID ,
txoption Integer8,
radius Integer8,
dataLength Integer8,
data OCTET STRING}
GroupParams ::= SEQUENCE {
group-address Integer16,
endpoint ZigBeeEndpoint}
NotifyAPSMessageEventParams ::= SEQUENCE {
dstAddress-mode Integer8,
dst-address DestinationAddress,
srcAddress-mode Integer8,
src-address ZigBeeNetworkAddress,
src-ieeeAddress ZigBeeIEEEAddress
OPTIONAL,
src-aliasAddress ZigBeeAliasAddress
OPTIONAL,
src-endpoint ZigBeeEndpoint,
profileID ZigBeeProfileID ,
dataLength Integer8,
data OCTET STRING,
aps-status Status8,
security-status Status8,
link-quality Integer8,
rxtime TimeStamp}
SendInterPANMessageParams ::= SEQUENCE {
dst-panId Integer16,
profileID ZigBeeProfileID,
asdu-length Integer16,
asdu OCTET STRING,
asdu-handle Integer8}
NotifyInterPANMessageEventParams ::= SEQUENCE {
src-panId Integer16,
dst-address ZigBeeNetworkAddress,
dst-panId Integer16,
profileID ZigBeeProfileID ,
asdu-length Integer8,
asdu OCTET STRING,
link-quality Integer8 }
FormNetworkParams ::= SEQUENCE {
scanned-channels Integer32,
scan-duration Integer8,

Page 211
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
beacon-order Integer8,
superFrame-order Integer8,
batteryLifeExtension BOOLEAN}
StartRouterParams ::= SEQUENCE {
batteryLifeExtension BOOLEAN}
JoinParams ::= SEQUENCE {
extendedPANId ZigBeeExtendedPanId,
rejoin Integer8,
scan-duration Integer8,
capability-info Integer8,
security-enable BOOLEAN}
LeaveParams ::= SEQUENCE {
device-address DestinationAddress OPTIONAL,
remove-children RemoveChildren OPTIONAL,
rejoin Rejoin OPTIONAL}
DiscoverNetworksParams ::= SEQUENCE {
scan-duration Integer8}
NetworkStatusEventParams ::= SEQUENCE {
nwk-status Status8,
nwk-address ZigBeeNetworkAddress
OPTIONAL}
PerformRouteDiscoveryParams ::= SEQUENCE {
dst-address ZigBeeNetworkAddress
OPTIONAL,
radius Integer8 OPTIONAL,
noRoute-cache BOOLEAN OPTIONAL }
SendNWKMessageParams ::= SEQUENCE { dstAddress-mode Integer8,
nsdu-length Integer8 OPTIONAL,
nsdu OCTET STRING OPTIONAL,
nsdu-handle Integer8,
radius Integer8,
radius-nonmember Integer8,
discover-route Integer8,
security-enable BOOLEAN}
NotifyNWKMessageEventParams ::= SEQUENCE {
dstAddress-mode Integer8 ,
dst-address ZigBeeNetworkAddress ,
nsdu-length Integer8,
nsdu OCTET STRING,
link-quality Integer8 OPTIONAL,
rxtime TimeStamp OPTIONAL,
security-use BOOLEAN OPTIONAL}
-- Results structures :
GetVersionResults ::= SEQUENCE {
versionIdentifier Integer8,
featureSetIdentifier Integer8,
rpcProtocols Integer16,
manufacturerVersion OCTET STRING}
ListCallbacksResults ::= SEQUENCE { callback-number Integer32,
callback-list CallbackList}
PollCallbackResults ::= SEQUENCE {
decode ActionDecodeSpec,
sendZDPCommandResults ZDPCommandResults OPTIONAL,
sendZCLCommandResults ZCLCommandResults OPTIONAL,
sendINTERPANMessageResults INTRPANCommandResults
OPTIONAL,
sendAPSCommandResults NotifyAPSMessageEventParams
OPTIONAL }
NodeCacheResults ::= SEQUENCE {
nodes-number Integer8,
node-info NodeAddressesList }
ReadServiceCacheResults ::= SEQUENCE {
ListAddressesResults
::= SEQUENCE
ZDPCommandResults ::= SEQUENCE {
ZCLCommandResults ::= SEQUENCE {
Page 212
number-nodes Integer8 ,
service-info ServiceInformation
}
{ nb-addresses Integer32,
addressList AddressesStructList
}
src-address ZigBeeNetworkAddress OPTIONAL,
security-status Status8 OPTIONAL,
link-status Status8 OPTIONAL,
rxtime TimeStamp OPTIONAL,
clusterID ZigBeeClusterID OPTIONAL,
command OCTET STRING OPTIONAL}
aps-status Status8,
rxtime TimeStamp,
dst-endpoint ZigBeeEndpoint,

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
srcAddress-mode Integer8 OPTIONAL,

src-address ZigBeeNetworkAddress
OPTIONAL,
src-ieeeAddress ZigBeeIEEEAddress
OPTIONAL,
src-aliasAddress ZigBeeAliasAddress
OPTIONAL,
profileID ZigBeeProfileID OPTIONAL,
clusterID ZigBeeClusterID OPTIONAL,
zcl-header OCTET STRING OPTIONAL,
zcl-payload OCTET STRING OPTIONAL}
APSCommandResults ::= SEQUENCE {
confirmStatus Status8 OPTIONAL,
txtime TimeStamp OPTIONAL}
GetGroupListResults ::= SEQUENCE {
group-count Integer16 OPTIONAL,
group-list GroupList OPTIONAL}
GetBindingListResults ::= SEQUENCE { binding-count Integer16 OPTIONAL,
binding-list BindingList OPTIONAL}
INTRPANCommandResults ::= SEQUENCE { asdu-handle Integer8 OPTIONAL,
confirm-status Integer8 OPTIONAL
}
DiscoverNetworksResults ::= SEQUENCE { nwk-status Status8,
nwk-count Integer8,
nwkDescriptors-list NetworkDescriptorList }
PerformEnergyScanResults ::= SEQUENCE {
nwk-status Status8 OPTIONAL,
energyDetect-list EnergyMeasurementsList
OPTIONAL}
PerformRouteDiscoveryResults ::= SEQUENCE { nwk-status Status8 OPTIONAL,
nwkStatus-code Status8 OPTIONAL}
SendNWKMessageResults ::= SEQUENCE { nwk-status Status8 OPTIONAL,
nsdu-handle Integer8 OPTIONAL,
txtime TimeStamp OPTIONAL}
-- Sub Structures
Filter ::= SEQUENCE { level FilterLevelSpec,
addressing FilterAddressingList OPTIONAL,
message FilterMessageList OPTIONAL}
FilterLevelSpec ::= ENUMERATED {mac-level(1), nwk-level(2), intrp-level(3), apslevel(4)}
FilterAddressingList ::= SEQUENCE OF FilterAddressing
FilterMessageList ::= SEQUENCE OF FilterMessage
FilterAddressing ::= SEQUENCE {src-address ZigBeeNetworkAddress OPTIONAL,
dst-endpoint ZigBeeEndpoint OPTIONAL}
FilterMessage ::= CHOICE {
cluster-id ZigBeeClusterID,
cluster-group ZigBeeClusterGroup}
Action ::= SEQUENCE { decode ActionDecodeSpec,
forward ActionForwardSpec }
StartupAttributeSet ::= SEQUENCE {
deviceType DeviceType OPTIONAL,
protocolVersion Integer8 OPTIONAL,
stackProfile Integer8 OPTIONAL,
channelMask Integer32 OPTIONAL,
extendedPANId ZigBeeExtendedPanId OPTIONAL,
panId Integer16 OPTIONAL,
shortAddress ZigBeeNetworkAddress OPTIONAL,
trustCenterAddress ZigBeeIEEEAddress OPTIONAL,
trustCenterMasterKey ZigBeeSecurityKey OPTIONAL,
networkKey ZigBeeSecurityKey OPTIONAL,
useInsecureJoin Integer8 OPTIONAL,
preconfiguredLinkKey ZigBeeSecurityKey OPTIONAL,
networkKeySeqNum Integer8 OPTIONAL,
networkKeyType Integer8 OPTIONAL,
networkManagerAddress ZigBeeNetworkAddress
OPTIONAL,
startupControl Integer8 OPTIONAL,
scanAttempts Integer8 OPTIONAL,
timeBetweenScans Integer16 OPTIONAL,
rejoinInterval Integer16 OPTIONAL,
maxRejoinInterval Integer16 OPTIONAL,
indirectPollRate Integer16 OPTIONAL,
parentRetryThreshold Integer8 OPTIONAL,
concentratorFlag BOOLEAN OPTIONAL,
concentratorRadius Integer8 OPTIONAL,

Page 213
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
concentratorDiscoveryTime Integer8 OPTIONAL}

NodeAddressesStruct ::= SEQUENCE {
device-nwkAddress ZigBeeNetworkAddress,
device-ieeeAddress ZigBeeIEEEAddress,
device-aliasAddress ZigBeeAliasAddress OPTIONAL,
parent-nwkAddress ZigBeeNetworkAddress OPTIONAL,
parent-ieeeAddress ZigBeeIEEEAddress OPTIONAL,
capability-info Integer8,
associated-devices Integer8 OPTIONAL,
start-index Integer8 OPTIONAL,
associatedDevices-list AssociatedDevicesList
OPTIONAL}
NodeDescriptor ::=SEQUENCE { logical-type ENUMERATED { coordinator(0),router(1),
endDevice(2)},
complex-descriptorBit BOOLEAN,
user-descriptorBit
BOOLEAN,
reserved
BIT STRING (SIZE(3)),
aps-flags
BIT STRING (SIZE(3)),
frequency-band
BIT STRING {
f868MHz
(0),
reserved1 (1),
f902MHz
(2),
f2400MHz (3)} (SIZE(5)),
mac-capability-flags BIT STRING {
alternatePanCoordinator
(0),
deviceIsFFD
(1),
mainsPowered
(2),
receiverOnWhenIdle
(3),
securitySupported
(6),
allocateAddress
(7) }
(SIZE(8)),
manufacturer-code Integer16,
max-buffer-size Integer8,
max-in-transfer-size Integer16,
server-mask BIT STRING {
primaryTrustCenter
(0),
backupTrustCenter
(1),
primaryBindingTableCache
(2),
backupBindingTableCache
(3),
primaryDiscoveryCache
(4),
backupDiscoveryCache
(5),
networkManager
(6) }
(SIZE(16)),
max-out-transfer-size Integer16,
descriptor-capability-field Integer8
}
NodePowerDescriptor ::= SEQUENCE { current-power-mode ENUMERATED {
synchronized(0),
seriodic(1) ,
stimulated(2) },
available-power-sources PowerSources,
current-power-source PowerSources,
current-power-source-level ENUMERATED {
myCritical(0),
percent33(4),
percent66(8),
percent100(12) }
}
PowerSources ::= BIT STRING {constant (0), rechargeable (1), disposable (2)} (SIZE(4))
SimpleDescriptor ::= SEQUENCE {
endpoint ZigBeeEndpoint,
profile ZigBeeProfileID ,
device-id ZigBeeDeviceID,
device-version Integer8,
inputcluster-count Integer8,
inputcluster-lists ClusterList,
outputcluster-count Integer8,
outputcluster-lists ClusterList
}
NetworkDescriptor ::= SEQUENCE {
extended-panId ZigBeeExtendedPanId,
logical-channel Integer8,
stack-profile Integer8,
zigbee-version Integer8,
permit-joining BOOLEAN,
Page 214

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
router-capacity BOOLEAN,
endDevice-capacity BOOLEAN }
ServiceInformation ::= SEQUENCE OF NodeServiceStructure
NodeServiceStructure ::= SEQUENCE
{
nwk-address ZigBeeNetworkAddress,
ieeeAddress ZigBeeIEEEAddress,
aliasAddress ZigBeeAliasAddress OPTIONAL,
active-endpoints Integer8,
simple-descriptors SimpleDescriptorList
OPTIONAL
}
AddressesStruct ::= SEQUENCE {
short-address ZigBeeNetworkAddress,
ieee-address ZigBeeIEEEAddress ,
alias-address ZigBeeAliasAddress OPTIONAL}
BindingList ::= SEQUENCE OF BindingEntry
BindingEntry ::= SEQUENCE { src-address ZigBeeIEEEAddress,
src-endpoint ZigBeeEndpoint,
ClusterID ZigBeeClusterID,
groupDest-count Integer16,
groupDest ZigBeeGroupAddressList,
deviceDest-count Integer16,
device-destinations
BindingDeviceDestEntry }
ZigBeeGroupAddressList ::= SEQUENCE OF Integer16
BindingDeviceDestEntry ::= SEQUENCE { src-address ZigBeeIEEEAddress,
src-endpoint
ZigBeeEndpoint }
GroupList ::= SEQUENCE OF GroupEntry
GroupEntry ::= SEQUENCE {
group-address Integer16,
endpoint-count Integer8,
endpoint-list EndpointList }
CallbackList ::= SEQUENCE OF CallbackId
ClusterList
::= SEQUENCE OF ZigBeeClusterID
EndpointList ::= SEQUENCE OF ZigBeeEndpoint
NodeAddressesList ::= SEQUENCE OF NodeAddressesStruct
NetworkDescriptorList ::= SEQUENCE OF NetworkDescriptor
SimpleDescriptorList ::= SEQUENCE OF SimpleDescriptor
EnergyMeasurementsList ::= SEQUENCE OF EnergyMeasurements
AssociatedDevicesList ::= SEQUENCE OF ZigBeeNetworkAddress
AddressesStructList ::= SEQUENCE OF AddressesStruct
-- general proc
Timeout ::= Integer32 (0..600000)
CallbackId ::= Integer32
CallbackDest ::= OCTET STRING
RequestId ::= Integer32
-- params
ActionDecodeSpec ::= ENUMERATED {decodeMACBit(0), decodeNWKBit(1),
decodeInterPANBit(2), decodeAPSBit(3), decodeZCLBit(4), decodeZDPBit(5)}
ActionForwardSpec ::= ENUMERATED {polled(0), grip(1), soap(2), rest(3)}
--ActionForwardSpec ::= CallbackDest
ZigBeeNetworkAddress ::= Integer16
ZigBeeIEEEAddress
::= OCTET STRING (SIZE(8)) -- Order of transmission is same as
ZigBeeExtendedPanId ::= OCTET STRING (SIZE(8)) -- defined in ZigBee spec
ZigBeeSecurityKey
::= OCTET STRING (SIZE(16)) -ZigBeeAliasAddress ::= OCTET STRING
ZigBeeEndpoint ::= Integer8
ZigBeeClusterID ::= Integer16
ZigBeeClusterGroup ::= ENUMERATED {all(0), zdp(1), zcl(2), discovery(10), binding(11),
network-management(12)}
ZigBeeProfileID ::= Integer16
ZigBeeDeviceID ::= Integer16
RemoveChildren ::= ENUMERATED {keepChildren(0), removeChildren(1)}
Rejoin ::= ENUMERATED {no-rejoin(0), rejoin(1)}
EnergyMeasurements ::= Integer8
DeviceType ::= ENUMERATED { currentDevice(0), zc(1), zr(2), zed(3)}
DestinationAddress ::= CHOICE { alias-address ZigBeeAliasAddress,
short-address ZigBeeNetworkAddress,
ieee-address ZigBeeIEEEAddress }
--results
Status8 ::= Integer8
TimeStamp ::=Integer32
ZCLCommandID ::= Integer8

Page 215
1
2
3
4
5
Integer32 ::= INTEGER (0..4294967295)

Integer16 ::= INTEGER (0..65535)
Integer8 ::= INTEGER (0..255)
END
Page 216

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
SO AP & Rest Schema

<?xml version="1.0" encoding="UTF-8"?>
<schema elementFormDefault="qualified" targetNamespace="http://www.zigbee.org/GWGSchema"
xmlns="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://www.zigbee.org/GWGSchema">

<simpleType name="unsignedNibble">
<restriction base="unsignedByte">
<minInclusive value="0"/>
<maxInclusive value="15"/>
</restriction>
</simpleType>
<simpleType name="unsigned16Bit">
<annotation>
<documentation>16bit Hexadecimal Number</documentation>
</annotation>
<restriction base="unsignedShort"/>
</simpleType>
<annotation>
</annotation>
<restriction base="unsignedInt"/>
</simpleType>
<annotation>
</annotation>
<restriction base="unsignedLong"/>
</simpleType>
<annotation>
</annotation>
<restriction base="hexBinary">
<length value="16"/>
</restriction>
</simpleType>

<simpleType name="IeeeAddress">
<restriction base="tns:unsigned64Bit"/>
</simpleType>
<simpleType name="NetworkAddress">
</simpleType>
<simpleType name="AliasAddress">
<restriction base="string"/>
</simpleType>
<complexType name="Address">
<sequence>
<element maxOccurs="1" minOccurs="0" name="NetworkAddress"
type="tns:NetworkAddress"/>
<element maxOccurs="1" minOccurs="0" name="IeeeAddress"
type="tns:IeeeAddress"/>
<element maxOccurs="1" minOccurs="0" name="AliasAddress"
type="tns:AliasAddress"/>
</sequence>
</complexType>
<simpleType name="Endpoint">
<restriction base="unsignedByte"/>
</simpleType>
<simpleType name="ClusterIdentifier">
</simpleType>
<simpleType name="ClusterGroup">
<restriction base="string"/>
</simpleType>
<simpleType name="ProfileIdentifier">
</simpleType>
<simpleType name="DeviceIdentifier">
</simpleType>
<simpleType name="CommandIdentifier">
</simpleType>
<complexType name="Group">
<sequence>
<element maxOccurs="1" minOccurs="1" name="GroupAddress"
type="tns:unsigned16Bit"/>
<element maxOccurs="unbounded" minOccurs="0" name="Endpoint"
type="tns:Endpoint"/>
</sequence>
</complexType>

Page 217
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<complexType name="GroupList">
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="Group"
type="tns:Group"/>
</sequence>
</complexType>
<complexType name="Device">
<sequence>
<element maxOccurs="1" minOccurs="1" name="Address"
<element maxOccurs="1" minOccurs="1" name="Endpoint"
</sequence>
</complexType>
<complexType name="NetworkStatusCode">
<sequence>
<element maxOccurs="1" minOccurs="1" name="Status" type="unsignedInt"/>
<element maxOccurs="1" minOccurs="0" name="NetworkStatusCode"
type="unsignedInt"/>
</sequence>
</complexType>
<simpleType name="LogicalType">
<restriction base="string">
<enumeration value="Current"/>
<enumeration value="Coordinator"/>
<enumeration value="Router"/>
<enumeration value="EndDevice"/>
</restriction>
</simpleType>
<simpleType name="KeyType">
<enumeration value="Standard"/>
<enumeration value="HighSecurity"/>
</restriction>
</simpleType>
<complexType name="MACCapability">
<sequence>
<element name="AlternatePanCoordinator" type="boolean"/>
<element name="DeviceIsFFD" type="boolean"/>
<element name="MainsPowered" type="boolean"/>
<element name="ReceiverOnWhenIdle" type="boolean"/>
<element name="SecuritySupported" type="boolean"/>
<element name="AllocateAddress" type="boolean"/>
</sequence>
</complexType>
<complexType name="ServerMask">
<sequence>
<element name="PrimaryTrustCenter" type="boolean"/>
<element name="BackupTrustCenter" type="boolean"/>
<element name="PrimaryBindingTableCache" type="boolean"/>
<element name="BackupBindingTableCache" type="boolean"/>
<element name="PrimaryDiscoveryCache" type="boolean"/>
<element name="BackupDiscoveryCache" type="boolean"/>
<element name="NetworkManager" type="boolean"/>
</sequence>
</complexType>
<complexType name="DescriptorCapability">
<sequence>
<element name="ExtendedActiveEndpointListAvailable" type="boolean"/>
<element name="ExtendedSimpleDescriptorListAvailable" type="boolean"/>
</sequence>
</complexType>
<complexType name="PowerSources">
<sequence>
<element name="ConstantMains" type="boolean"/>
<element name="RechargeableBattery" type="boolean"/>
<element name="DisposableBattery" type="boolean"/>
</sequence>
</complexType>
<complexType name="LanguageAndCharacterSet">
<sequence>
<element name="LanguageCode" type="string"/>
<element name="CharacterSet" type="string"/>
</sequence>
</complexType>
<simpleType name="RPCProtocol">
<enumeration value="GRIP"/>
<enumeration value="SOAP"/>
<enumeration value="REST"/>
</restriction>
</simpleType>
<simpleType name="Level">
<enumeration value="MACLevel"/>
Page 218

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
<enumeration value="NWKLevel"/>
<enumeration value="APSLevel"/>
<enumeration value="INTRPLevel"/>
</restriction>
</simpleType>
<complexType name="Filter">
<sequence>
<element maxOccurs="1" minOccurs="1" name="LevelSpecification">
<complexType>
<sequence>
<element maxOccurs="unbounded" minOccurs="1"
name="Level" type="tns:Level"/>
</sequence>
</complexType>
</element>
<element maxOccurs="unbounded" minOccurs="0" name="AddressSpecification">
<complexType>
<sequence>
<element maxOccurs="1" minOccurs="0"
name="NWKSourceAddress" type="tns:Address"/>
name="APSSourceEndpoint" type="tns:Endpoint"/>
name="APSDestinationEndpoint" type="tns:Endpoint"/>
</sequence>
</complexType>
</element>
<element maxOccurs="unbounded" minOccurs="0" name="MessageSpecification">
<complexType>
<sequence>
name="APSClusterIdentifier" type="tns:ClusterIdentifier"/>
name="APSClusterGroup" type="tns:ClusterGroup"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
<complexType name="Buffer">
<sequence/>
</complexType>
<simpleType name="DecodeLevel">
<enumeration value="DecodeMAC"/>
<enumeration value="DecodeNWK"/>
<enumeration value="DecodeInterPAN"/>
<enumeration value="DecodeAPS"/>
<enumeration value="DecodeZCL"/>
<enumeration value="DecodeZDP"/>
</restriction>
</simpleType>
<complexType name="Action">
<sequence>
<element maxOccurs="1" minOccurs="1" name="DecodeSpecification">
<complexType>
<sequence>
name="DecodeLevel" type="tns:DecodeLevel"/>
</sequence>
</complexType>
</element>
<element maxOccurs="1" minOccurs="1" name="ForwardingSpecification"
type="string"/>
</sequence>
</complexType>
<complexType name="TxOptions">
<sequence>
<element name="SecurityEnabled" type="boolean"/>
<element name="UseNetworkKey" type="boolean"/>
<element name="Acknowledged" type="boolean"/>
<element name="PermitFragmentation" type="boolean"/>
</sequence>
</complexType>
<simpleType name="SecurityStatus">
<enumeration value="Unsecured"/>
<enumeration value="SecuredNwkKey"/>
<enumeration value="SecuredLinkKey"/>
</restriction>
</simpleType>

<complexType name="Version">
<sequence>

Page 219
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<element maxOccurs="1" minOccurs="1" name="VersionIdentifier"

type="unsignedByte"/>
<element maxOccurs="1" minOccurs="1" name="FeatureSetIdentifier"
<element maxOccurs="unbounded" minOccurs="1" name="RPCProtocol"
type="tns:RPCProtocol"/>
<element maxOccurs="1" minOccurs="1" name="ManufacturerVersion"
type="string"/>
</sequence>
</complexType>
<complexType name="Callback">
<sequence>
<element maxOccurs="1" minOccurs="0" name="Filter" type="tns:Filter"/>
<element maxOccurs="1" minOccurs="0" name="Buffer" type="tns:Buffer"/>
<element maxOccurs="1" minOccurs="0" name="Action" type="tns:Action"/>
</sequence>
</complexType>
<complexType name="CallbackIdentifierList">
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="CallbackIdentifier"
type="tns:CallbackIdentifier"/>
</sequence>
</complexType>
<complexType name="Aliases">
<sequence>
<element maxOccurs="1" minOccurs="0" name="NumberOfAlias"
<element maxOccurs="unbounded" minOccurs="0" name="Alias"
type="tns:Address"/>
</sequence>
</complexType>
<complexType name="ZDPCommand">
<sequence>
<element maxOccurs="1" minOccurs="1" name="Destination"
<element maxOccurs="1" minOccurs="0" name="TxOptions"
type="tns:TxOptions"/>
<element maxOccurs="1" minOccurs="0" name="Radius" type="unsignedByte"/>
<element maxOccurs="1" minOccurs="1" name="ClusterID"
type="tns:ClusterIdentifier"/>
<element maxOccurs="1" minOccurs="1" name="Command" type="hexBinary"/>
<element maxOccurs="1" minOccurs="1" name="DestinationAddrMode"
</sequence>
</complexType>
<complexType name="ZDPMessage">
<sequence>
<element maxOccurs="1" minOccurs="0" name="SourceAddress"
<element name="SourceAddressMode" type="unsignedInt"/>
<element maxOccurs="1" minOccurs="0" name="SecurityStatus"
type="tns:SecurityStatus"/>
<element maxOccurs="1" minOccurs="0" name="LinkQuality"
<element maxOccurs="1" minOccurs="0" name="RxTime"
<element maxOccurs="1" minOccurs="1" name="Command" type="hexBinary"/>
</sequence>
</complexType>
<complexType name="ZCLCommand">
<sequence>
<element name="DestinationAddressMode" type="unsignedInt"/>
<element maxOccurs="1" minOccurs="0" name="DestinationAddress"
<element maxOccurs="1" minOccurs="0" name="DestinationEndpoint"
<element maxOccurs="1" minOccurs="0" name="ProfileID"
type="tns:ProfileIdentifier"/>
<element maxOccurs="1" minOccurs="0" name="SourceEndpoint"
<element maxOccurs="1" minOccurs="1" name="ZCLPayload" type="hexBinary"/>
<element maxOccurs="1" minOccurs="1" name="ZCLHeader" type="hexBinary"/>
</sequence>
</complexType>
<complexType name="ZCLCommandResult">
<sequence>
Page 220

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<element maxOccurs="1" minOccurs="1" name="CommandID"

type="tns:CommandIdentifier"/>
</sequence>
</complexType>
<complexType name="ZCLMessage">
<sequence>
<element maxOccurs="1" minOccurs="1" name="ZCLPayload" type="hexBinary"/>
<element name="APSStatus" type="tns:unsigned32Bit"/>

<element name="SourceAddressMode" type="unsignedInt"/>
<element maxOccurs="1" minOccurs="1" name="ZCLHeader" type="hexBinary"/>
</sequence>
</complexType>
<complexType name="APSMessage">
<sequence>
<element maxOccurs="1" minOccurs="0" name="DestinationAddressMode"
<element maxOccurs="1" minOccurs="1" name="Data" type="hexBinary"/>
</sequence>
</complexType>
<complexType name="APSMessageResult">
<sequence>
<element maxOccurs="1" minOccurs="1" name="ConfirmStatus"
type="unsignedShort"/>
<element maxOccurs="1" minOccurs="1" name="TxTime"
</sequence>
</complexType>
<complexType name="APSMessageEvent">
<sequence>
<element maxOccurs="1" minOccurs="0" name="DestinationAddressMode"
<element maxOccurs="1" minOccurs="0" name="SourceAddressMode"
<element maxOccurs="1" minOccurs="1" name="Data" type="hexBinary"/>
<element maxOccurs="1" minOccurs="1" name="APSStatus"
<element maxOccurs="1" minOccurs="0" name="SecurityStatus"
type="tns:SecurityStatus"/>
</sequence>
</complexType>
<complexType name="ServiceDescriptor">
<sequence>
<element name="Address" type="tns:Address"/>

Page 221
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
<element name="EndPoint" type="tns:Endpoint"/>

<element name="SimpleDescriptor" type="tns:SimpleDescriptor"/>
</sequence>
</complexType>
<complexType name="InterPANMessage">
<sequence>
<element maxOccurs="1" minOccurs="1" name="SrcAddressMode"
<element name="SrcAddress" type="tns:Address"/>
<element maxOccurs="1" minOccurs="1" name="SrcPANID"
<element maxOccurs="1" minOccurs="1" name="DstAddressMode"
<element maxOccurs="1" minOccurs="1" name="DestPANID"
<element name="ASDULength" type="unsignedInt"/>
<element maxOccurs="1" minOccurs="1" name="ASDU" type="hexBinary"/>
<element maxOccurs="1" minOccurs="1" name="ASDUHandle"
</sequence>
</complexType>
<complexType name="InterPANMessageResult">
<sequence>
<element maxOccurs="1" minOccurs="0" name="ASDUHandle"
<element maxOccurs="1" minOccurs="0" name="ConfirmStatus"
</sequence>
</complexType>
<complexType name="InterPANMessageEvent">
<sequence>
<element maxOccurs="1" minOccurs="0" name="CallbackIdentifier"
type="tns:CallbackIdentifier"/>
<element maxOccurs="1" minOccurs="1" name="SrcAddressMode"
<element maxOccurs="1" minOccurs="1" name="SrcAddress"
<element maxOccurs="1" minOccurs="1" name="DstAddress"
<element maxOccurs="1" minOccurs="1" name="SrcPANID"
<element maxOccurs="1" minOccurs="1" name="DstPANID"
<element name="ASDULength" type="unsignedInt"/>
<element maxOccurs="1" minOccurs="1" name="ASDU" type="hexBinary"/>
</sequence>
</complexType>
<complexType name="NWKMessage">
<sequence>
<element maxOccurs="1" minOccurs="1" name="Destination"
<element maxOccurs="1" minOccurs="1" name="Nsdu" type="hexBinary"/>
<element maxOccurs="1" minOccurs="1" name="NsduHandle"
<element maxOccurs="1" minOccurs="1" name="NonmemberRadius"
<element maxOccurs="1" minOccurs="1" name="DiscoverRoute"
<element maxOccurs="1" minOccurs="1" name="SecurityEnable"
type="boolean"/>
<element name="NsduLength" type="unsignedInt"/>
</sequence>
</complexType>
<complexType name="NWKMessageResult">
<sequence>
<element maxOccurs="1" minOccurs="1" name="NWKStatus"
Page 222

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
<element maxOccurs="1" minOccurs="1" name="NsduHandle"

<element maxOccurs="1" minOccurs="1" name="TxTime"
</sequence>
</complexType>
<complexType name="NWKMessageEvent">
<sequence>
<element maxOccurs="1" minOccurs="1" name="DstAddrMode"
<element maxOccurs="1" minOccurs="1" name="DstAddr"
<element maxOccurs="1" minOccurs="1" name="SrcAddr"
<element maxOccurs="1" minOccurs="1" name="Nsdu" type="hexBinary"/>
<element maxOccurs="1" minOccurs="1" name="SecurityUse" type="boolean"/>
</sequence>
</complexType>
<complexType name="MACMessage"/>
<complexType name="Message">
<sequence>
<element name="ZCLMessage" type="tns:ZCLMessage"/>
<element name="ZDPMessage" type="tns:ZDPMessage"/>
<element name="APSMessage" type="tns:APSMessageEvent"/>
<element name="NWKMessage" type="tns:NWKMessageEvent"/>
<element name="InterPANMessage" type="tns:InterPANMessageEvent"/>
<element name="MACMessage" type="tns:MACMessage"/>
</sequence>
</complexType>
<complexType name="SonNode">
<attribute name="ShortAddr" type="tns:NetworkAddress"/>
</complexType>
<complexType name="AssociatedDevices">
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="SonNode"
type="tns:SonNode"/>
</sequence>
<attribute name="TotalNumber" type="unsignedShort"/>
</complexType>
<complexType name="WSNNode">
<sequence>
<element maxOccurs="1" minOccurs="1" name="Address" type="tns:Address"/>
<element maxOccurs="1" minOccurs="0" name="ParentAddress"
<element name="StartIndex" type="unsignedInt"/>
<element maxOccurs="unbounded" minOccurs="0" name="AssociatedDevices"
type="tns:AssociatedDevices"/>
<element maxOccurs="1" minOccurs="0" name="CapabilityInformation"
type="tns:MACCapability"/>
</sequence>
</complexType>
<complexType name="WSNNodeList">
<sequence>
<element maxOccurs="unbounded" minOccurs="1" name="WSNNode"
type="tns:WSNNode"/>
</sequence>
</complexType>
<complexType name="NodeServices">
<sequence>
<element maxOccurs="1" minOccurs="1" name="Address" type="tns:Address"/>
<element maxOccurs="unbounded" minOccurs="0" name="ActiveEndpoints">
<complexType>
<sequence>
name="EndPoint" type="tns:Endpoint"/>
name="SimpleDescriptor" type="tns:SimpleDescriptor"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
<complexType name="NodeServicesList">
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="NodeServices"
type="tns:NodeServices"/>
</sequence>
</complexType>
<complexType name="StartupAttributeInfo">
<sequence>

Page 223
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<element maxOccurs="1" minOccurs="1" name="StartupAttributeSetIndex"

<element maxOccurs="1" minOccurs="0" name="DeviceType"
type="tns:LogicalType"/>
<element maxOccurs="1" minOccurs="0" name="ProtocolVersion"
<element maxOccurs="1" minOccurs="0" name="StackProfile"
<element maxOccurs="1" minOccurs="0" name="ChannelMask"
<element maxOccurs="1" minOccurs="0" name="ExtendedPANId"
<element maxOccurs="1" minOccurs="0" name="PANId"
<element maxOccurs="1" minOccurs="0" name="ShortAddress"
<element maxOccurs="1" minOccurs="0" name="TrustCenterAddress"
<element maxOccurs="1" minOccurs="0" name="TrustCenterMasterKey"
<element maxOccurs="1" minOccurs="0" name="NetworkKey"
<element maxOccurs="1" minOccurs="0" name="UseInsecureJoin"
type="boolean"/>
<element maxOccurs="1" minOccurs="0" name="PreconfiguredLinkKey"
<element maxOccurs="1" minOccurs="0" name="NetworkKeySeqNum"
<element maxOccurs="1" minOccurs="0" name="NetworkKeyType"
type="tns:KeyType"/>
<element maxOccurs="1" minOccurs="0" name="NetworkManagerAddress"
<element maxOccurs="1" minOccurs="0" name="StartupControl"
<element maxOccurs="1" minOccurs="0" name="ScanAttempts"
<element maxOccurs="1" minOccurs="0" name="TimeBetweenScans"
<element maxOccurs="1" minOccurs="0" name="RejoinInterval"
<element maxOccurs="1" minOccurs="0" name="maxRejoinInterval"
<element maxOccurs="1" minOccurs="0" name="IndirectPollRate"
<element maxOccurs="1" minOccurs="0" name="ParentRetryThreshold"
<element maxOccurs="1" minOccurs="0" name="ConcentratorFlag"
type="boolean"/>
<element maxOccurs="1" minOccurs="0" name="ConcentratorRadius"
<element maxOccurs="1" minOccurs="0" name="ConcentratorDiscoveryTime"
</sequence>
</complexType>

<complexType name="NodeDescriptor">
<sequence>
<element maxOccurs="1" minOccurs="0" name="LogicalType"
type="tns:LogicalType"/>
<element maxOccurs="1" minOccurs="0" name="ComplexDescriptorAvailable"
type="boolean"/>
<element maxOccurs="1" minOccurs="0" name="UserDescriptorAvailable"
type="boolean"/>
<element maxOccurs="1" minOccurs="0" name="FrequencyBand">
<simpleType>
<enumeration value="868MHz"/>
</restriction>
</simpleType>
</element>
<element maxOccurs="1" minOccurs="0" name="MACCapabilityFlag"
<element maxOccurs="1" minOccurs="0" name="ManufacturerCode"
<element maxOccurs="1" minOccurs="0" name="MaximumBufferSize">
<simpleType>
</restriction>
</simpleType>
</element>
<element maxOccurs="1" minOccurs="0" name="MaximumIncomingTransferSize">
Page 224

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<simpleType>
<restriction base="unsignedShort">
</restriction>
</simpleType>
</element>
<element maxOccurs="1" minOccurs="0" name="ServerMask"
type="tns:ServerMask"/>
<element maxOccurs="1" minOccurs="0" name="MaximumOutgoingTransferSize">
<simpleType>
<restriction base="unsignedShort">
</restriction>
</simpleType>
</element>
<element maxOccurs="1" minOccurs="0" name="DescriptorCapabilityField"
type="tns:DescriptorCapability"/>
</sequence>
</complexType>
<complexType name="PowerDescriptor">
<sequence>
<element maxOccurs="1" minOccurs="0" name="CurrentPowerMode">
<simpleType>
<enumeration value="Synchronized"/>
<enumeration value="Periodic"/>
<enumeration value="Stimulated"/>
</restriction>
</simpleType>
</element>
<element maxOccurs="1" minOccurs="0" name="AvailablePowerSources"
type="tns:PowerSources"/>
<element maxOccurs="1" minOccurs="0" name="CurrentPowerSources"
type="tns:PowerSources"/>
<element maxOccurs="1" minOccurs="0" name="CurrentPowerSourceLevel">
<simpleType>
<enumeration value="Critical"/>
<enumeration value="33Percent"/>
</restriction>
</simpleType>
</element>
</sequence>
</complexType>
<complexType name="UserDescriptor">
<sequence>
<element maxOccurs="1" minOccurs="1" name="Description">
<simpleType>
<maxLength value="16"/>
</restriction>
</simpleType>
</element>
</sequence>
</complexType>
<complexType name="SimpleDescriptor">
<sequence>
<element maxOccurs="1" minOccurs="0" name="EndPoint">
<simpleType>
</restriction>
</simpleType>
</element>
<element maxOccurs="1" minOccurs="0" name="ApplicationProfileIdentifier"
<element maxOccurs="1" minOccurs="0" name="ApplicationDeviceIdentifier"
type="tns:DeviceIdentifier"/>
<element maxOccurs="1" minOccurs="0" name="ApplicationDeviceVersion"
type="tns:unsignedNibble"/>
name="ApplicationInputCluster" type="tns:ClusterIdentifier"/>
name="ApplicationOutputCluster" type="tns:ClusterIdentifier"/>
</sequence>
</complexType>
<complexType name="Binding">
<sequence>
<element maxOccurs="1" minOccurs="1" name="SourceIEEEAddress"

Page 225
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85

<element maxOccurs="unbounded" minOccurs="0" name="GroupDestination"
<element maxOccurs="unbounded" minOccurs="0" name="DeviceDestination"
type="tns:Device"/>
</sequence>
</complexType>
<complexType name="BindingList">
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="Binding"
type="tns:Binding"/>
</sequence>
</complexType>

<complexType name="NetworkConfiguration">
<sequence>
<element maxOccurs="1" minOccurs="0" name="ScanChannels"
<element maxOccurs="1" minOccurs="0" name="ScanDuration"
<element maxOccurs="1" minOccurs="1" name="BeaconOrder"
<element maxOccurs="1" minOccurs="1" name="SuperFrameOrder"
<element maxOccurs="1" minOccurs="1" name="BatteryLifeExtension"
type="boolean"/>
</sequence>
</complexType>
<complexType name="JoinConfiguration">
<sequence>
<element maxOccurs="1" minOccurs="1" name="ExtendedPanId"
<element maxOccurs="1" minOccurs="1" name="RejoinNetwork"
<element maxOccurs="1" minOccurs="1" name="ScanChannel"
<element maxOccurs="1" minOccurs="1" name="ScanDuration"
<element maxOccurs="1" minOccurs="1" name="CapabilityInformation"
<element maxOccurs="1" minOccurs="1" name="SecurityEnable"
type="boolean"/>
</sequence>
</complexType>
<complexType name="ResetInfo">
<sequence>
<element maxOccurs="1" minOccurs="1" name="WarmStart" type="boolean"/>
</sequence>
</complexType>
<complexType name="NetworkDescriptor">
<sequence>
<element maxOccurs="1" minOccurs="0" name="ExtendedPanId"
<element maxOccurs="1" minOccurs="0" name="LogicalChannel"
<element maxOccurs="1" minOccurs="0" name="StackProfile"
<element maxOccurs="1" minOccurs="0" name="ZigBeeVersion"
<element maxOccurs="1" minOccurs="0" name="BeaconOrder"
<element maxOccurs="1" minOccurs="0" name="SuperFrameOrder"
<element maxOccurs="1" minOccurs="0" name="PermitJoining"
type="boolean"/>
<element maxOccurs="1" minOccurs="0" name="RouterCapacity"
type="boolean"/>
<element maxOccurs="1" minOccurs="0" name="EndDeviceCapacity"
type="boolean"/>
<element maxOccurs="1" minOccurs="0" name="NWKRootURI" type="anyURI"/>
</sequence>
</complexType>
<complexType name="NetworkDescriptorList">
<sequence>
<element name="NetworkDescriptor" type="tns:NetworkDescriptor"/>
</sequence>
</complexType>
<complexType name="EnergyScanResult">
<sequence>
<element maxOccurs="unbounded" minOccurs="0" name="ScannedChannel">
<complexType>
<sequence>
Page 226

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
55
56
57
58

name="Channel" type="unsignedByte"/>
name="Energy" type="unsignedByte"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
<complexType name="RouteDiscoveryInfo">
<sequence>
<element minOccurs="0" name="DstAddrMode" type="unsignedByte"/>
<element maxOccurs="1" minOccurs="0" name="DstAddr" type="tns:Address"/>
<element maxOccurs="1" minOccurs="0" name="NoRouteCache" type="boolean"/>
</sequence>
</complexType>

<complexType name="JoiningInfo">
<sequence>
<element maxOccurs="1" minOccurs="1" name="PermitDuration"
<element maxOccurs="1" minOccurs="1" name="TCSignificance"
type="boolean"/>
</sequence>
</complexType>
<restriction base="unsignedByte"/>
</simpleType>
<simpleType name="ForwardScheme">
<enumeration value="POLLED"/>
<enumeration value="GRIP"/>
<enumeration value="SOAP"/>
<enumeration value="REST"/>
</restriction>
</simpleType>
<simpleType name="CallbackIdentifier">
</simpleType>
<simpleType name="Timeout">
</simpleType>
<complexType name="PolledMessage">
<sequence>
<element name="AppliedDecodeSpecification" type="string"/>
<element name="Message" type="tns:Message"/>
</sequence>
</complexType>
<simpleType name="RequestIdentifier">
<restriction base="hexBinary">
<minLength value="4"/>
</restriction>
</simpleType>
<simpleType name="PanId">
</simpleType>
</schema>

Page 227
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
SO AP WSDL
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://www.zigbee.org/zgd/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:ns="http://www.zigbee.org/GWGSchema"
xmlns:ns1="http://schemas.xmlsoap.org/soap/encoding/" name="zgd"
targetNamespace="http://www.zigbee.org/zgd/">
<wsdl:types>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.zigbee.org/zgd/" xmlns:Q1="http://www.w3.org/2001/XMLSchema"
xmlns:Q2="http://www.zigbee.org/GWGSchema" xmlns:auto1="http://www.zigbee.org/zgd/">
<xsd:import schemaLocation="../zbGateway.xsd"
namespace="http://www.zigbee.org/GWGSchema"/>
<xsd:element name="GetVersion">
<xsd:complexType>
</xsd:complexType>
</xsd:element>
<xsd:element name="GetVersionResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
<xsd:element name="Version"
type="Q2:Version" maxOccurs="1" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Get">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="attrId"
type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GetResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="value"
type="xsd:hexBinary"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Set">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="attrId"
type="xsd:string"/>
<xsd:element name="value"
type="xsd:hexBinary"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SetResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="CreateCallback">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Filter"
type="Q2:Filter"/>
<xsd:element name="Action"
type="Q2:Action"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="CreateCallbackResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="CallbackIdentifier" type="Q2:CallbackIdentifier"/>
</xsd:sequence>
Page 228

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
</xsd:complexType>
</xsd:element>
<xsd:element name="PollCallback">
<xsd:complexType>
<xsd:sequence>
<xsd:element
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PollCallbackResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="AppliedDecodeSpecification" type="ns:DecodeLevel"/>
<xsd:element name="SendZDPResult"
minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ZDPMessage" type="ns:ZDPMessage" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendZCLResult"
minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ZCLMessage" type="ns:ZCLMessage" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendAPSResult"
minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="APSMessage" type="Q2:APSMessageEvent"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendInterPANResult"
minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="InterPANMessage" type="Q2:InterPANMessageEvent"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="DeleteCallback">
<xsd:complexType>
<xsd:sequence>
<xsd:element
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="DeleteCallbackResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ListCallbacks">
<xsd:complexType>
</xsd:complexType>
</xsd:element>
<xsd:element name="ListCallbacksResponse">

Page 229
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="CallbackIdentiferList" type="Q2:CallbackIdentifierList"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PollResults">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="RequestIdentifier" type="ns:RequestIdentifier"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PollResultsResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="RequestIdentifier"
type="Q2:RequestIdentifier" maxOccurs="1" minOccurs="0"/>
<xsd:element
name="AppliedDecodeSpecification" type="ns:DecodeLevel"/>
<xsd:element name="SendZDPResult"
minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ZDPMessage" type="ns:ZDPMessage" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendZCLResult"
minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ZCLMessage" type="ns:ZCLMessage" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element
name="SendAPSResult">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="APSMessageEvent" type="Q2:APSMessageEvent" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element
name="SendInterPANResult">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="InterPANMessageEvent" type="Q2:InterPANMessageEvent" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="UpdateTimeout">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="RequestIdentifier" type="Q2:RequestIdentifier"/>
<xsd:element name="Timeout"
type="Q2:Timeout"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="UpdateTimeoutResponse">
<xsd:complexType>
Page 230

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartNodeDiscovery">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="CallbackDestination"
type="xsd:string" minOccurs="0"/>
type="Q2:Timeout"/>
<xsd:element
name="ReportOnExistingNodes" type="xsd:boolean" minOccurs="0"/>
<xsd:element
name="ReportAnnouncements" type="xsd:boolean" minOccurs="0"/>
<xsd:element name="ReportLeave"
type="xsd:boolean" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartNodeDiscoveryResponse">
<xsd:complexType>
<xsd:sequence>
type="ns:RequestIdentifier" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NodeDiscoveryEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element
<xsd:element name="NodeInfo"
minOccurs="1" type="ns:WSNNode"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NodeDiscoveryEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NodeLeaveEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element
<xsd:element name="Address"
type="ns:Address"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NodeLeaveEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ReadNodeCache">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ReadNodeCacheResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="NodeInformation" type="Q2:WSNNodeList"/>
<xsd:element name="Node"
type="ns:unsigned32Bit"/>
</xsd:sequence>
</xsd:complexType>

Page 231
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
</xsd:element>
<xsd:element name="StartServiceDiscovery">
<xsd:complexType>
<xsd:sequence>
type="Q2:Timeout"/>
<xsd:element
name="AddressOfInterest" type="Q2:NetworkAddress"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartServiceDiscoveryResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ServiceDiscoveryEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element
type="ns:Address"/>
<xsd:element name="ActiveEndpoints"
type="ns:Endpoint"/>
<xsd:element name="SimpleDescriptors"
type="ns:SimpleDescriptor" maxOccurs="unbounded" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ServiceDiscoveryEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GetServiceDescriptor">
<xsd:complexType>
<xsd:sequence>
type="ns:Timeout"/>
type="ns:Address" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GetServiceDescriptorResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ServiceDiscriptorEvent">
<xsd:complexType>
<xsd:sequence>
type="ns:RequestIdentifier"/>
type="ns:Address"/>
<xsd:element
name="ActiveEndpoints" type="ns:Endpoint"/>
<xsd:element name="SimpleDescriptors"
type="ns:SimpleDescriptor" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ServiceDiscriptorEventResponse">
<xsd:complexType>
<xsd:sequence>
Page 232

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ReadServiceCache">
<xsd:complexType>
</xsd:complexType>
</xsd:element>
<xsd:element name="ReadServiceCacheResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="ServiceInformation" type="Q2:NodeServicesList"/>
<xsd:element name="Node"
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartGatewayDevice">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Request"
type="Q2:StartupAttributeInfo"/>
type="ns:Timeout"/>
<xsd:element
name="CallbackDestination" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartGatewayDeviceResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="RequestIdentifier" type="Q2:RequestIdentifier" maxOccurs="1" minOccurs="0"/>
<xsd:element name="NWKStatus"
type="Q2:unsigned8Bit"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartGatewayDeviceEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartGatewayDeviceEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ConfigureStartupAttributeSet">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="StartupAttrInfo" type="ns:StartupAttributeInfo"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ConfigureStartupAttributeSetResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ReadStartupAttributeSet">
<xsd:complexType>
<xsd:sequence>

Page 233
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<xsd:element
name="StartAttrSetIndex" type="ns:unsigned32Bit"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ReadStartupAttributeSetResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="StartupAttributeInfo" type="ns:StartupAttributeInfo" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="CreateAliasAddress">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Alias"
type="xsd:string"/>
<xsd:element
name="ExtendedAddress" type="ns:IeeeAddress"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="CreateAliasAddressResponse">
<xsd:complexType>
<xsd:sequence>
type="xsd:unsignedByte">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="DeleteAliasAddress">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Alias"
type="ns:AliasAddress"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="DeleteAliasAddressResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ListAddresses">
<xsd:complexType>
<xsd:sequence>
type="ns:Address"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ListAddressesResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
<xsd:element name="NumOfAddr"
<xsd:element name="AddrList"
type="ns:Address" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GmoLeave">
<xsd:complexType>
<xsd:sequence>
type="ns:Timeout"/>
<xsd:element name="DeviceAddress"
<xsd:element name="RemoveChildren"
<xsd:element name="Rejoin"
Page 234

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GmoLeaveResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
<xsd:element name="MgmtCommandStatus"
type="Q2:unsigned8Bit" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GmoLeaveEvent">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GmoLeaveEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PermitJoin">
<xsd:complexType>
<xsd:sequence>
type="ns:Timeout"/>
<xsd:element name="DestinationAddress"
<xsd:element name="DestinationAddressMode"
type="ns:unsigned32Bit" minOccurs="0"/>
<xsd:element name="PermitDuration"
<xsd:element name="TCSignificane"
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PermitJoinResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PermitJoinEvent">
<xsd:complexType>
<xsd:sequence>
type="Q2:RequestIdentifier" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PermitJoinEventResponse">
<xsd:complexType>
<xsd:sequence>

Page 235
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:element name="SendZDPCommand">
<xsd:complexType>
<xsd:sequence>
type="ns:Timeout"/>
<xsd:element
name="CallbackDestination" type="xsd:string" maxOccurs="1" minOccurs="0"/>
<xsd:element name="Command"
type="Q2:ZDPCommand"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendZDPCommandResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
<xsd:element
name="RequestIdentifier" type="Q2:RequestIdentifier" maxOccurs="1" minOccurs="0">
</xsd:element>
<xsd:element name="Message"
type="Q2:ZDPMessage" minOccurs="0">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifyZDPEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element
type="ns:ZDPMessage" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifyZDPEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:element name="SendZCLCommand">
<xsd:complexType>
<xsd:sequence>
type="Q2:Timeout"/>
<xsd:element
<xsd:element name="Command"
type="Q2:ZCLCommand"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendZCLCommandResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element
type="Q2:ZCLMessage"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifyZCLEvent">
<xsd:complexType>
<xsd:sequence>
type="Q2:ZCLMessage"/>
<xsd:element
name="RequestIdentifier" type="Q2:RequestIdentifier" maxOccurs="1"/>
Page 236

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifyZCLEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:element name="ConfigureNodeDescriptor">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="NodeDescriptor" type="Q2:NodeDescriptor"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ConfigureNodeDescriptorResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GetNodeDescriptor">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GetNodeDescriptorResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="NodeDescriptor" type="Q2:NodeDescriptor"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GetNodePowerDescriptor">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GetNodePowerDescriptorResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="PowerDescriptor" type="Q2:PowerDescriptor"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ConfigureUserDescriptor">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="UserDescriptor" type="Q2:UserDescriptor"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ConfigureUserDescriptorResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GetUserDescriptor">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GetUserDescriptorResponse">
<xsd:complexType>
<xsd:sequence>

Page 237
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<xsd:element
name="UserDescriptor" type="Q2:UserDescriptor"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ConfigureEndpoint">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="SimpleDescriptor" type="Q2:SimpleDescriptor"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ConfigureEndpointResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ClearEndpoint">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Endpoint"
type="Q2:Endpoint"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ClearEndpointResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendAPSMessage">
<xsd:complexType>
<xsd:sequence>
type="Q2:APSMessage" maxOccurs="1" minOccurs="0"/>
type="Q2:Timeout"/>
<xsd:element
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendAPSMessageResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element
<xsd:element name="ConfirmStatus"
<xsd:element name="TxTime"
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifySendAPSMessageEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element
<xsd:element name="TxTime"
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifySendAPSMessageEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
Page 238

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifyAPSMessageEvent">
<xsd:complexType>
<xsd:sequence>
type="Q2:APSMessageEvent"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifyAPSMessageEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="AddGroup">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Group"
type="Q2:Group"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="AddGroupResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="RemoveGroup">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Group"
type="Q2:Group"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="RemoveGroupResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="RemoveAllGroups">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Endpoint"
type="Q2:Endpoint"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="RemoveAllGroupsResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GetGroupList">
<xsd:complexType>
</xsd:complexType>
</xsd:element>
<xsd:element name="GetGroupListResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="GroupList"
type="Q2:GroupList" minOccurs="0"/>
<xsd:element name="GroupCount"
type="xsd:unsignedInt" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GetBindingList">
<xsd:complexType>
</xsd:complexType>

Page 239
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
</xsd:element>
<xsd:element name="GetBindingListResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="BindingList"
type="Q2:BindingList" minOccurs="0"/>
<xsd:element name="BindingCount"
type="xsd:unsignedInt" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:element name="SendInterPANMessage">
<xsd:complexType>
<xsd:sequence>
type="ns:Timeout">
</xsd:element>
<xsd:element
name="CallbackDestination" type="xsd:string" minOccurs="0">
</xsd:element>
type="ns:InterPANMessage"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendInterPANMessageResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
type="xsd:unsignedByte" minOccurs="0">
</xsd:element>
<xsd:element name="ASDUHandle"
type="xsd:unsignedByte" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifyInterPANMessageEvent">
<xsd:complexType>
<xsd:sequence>
type="ns:InterPANMessage"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifyInterPANMessageEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:element name="FormNetwork">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="NetworkConfiguration" type="Q2:NetworkConfiguration">
</xsd:element>
type="ns:Timeout"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="FormNetworkResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
<xsd:element
</xsd:element>
Page 240

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
type="Q2:NetworkStatusCode" maxOccurs="1" minOccurs="0">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="FormNetworkEvent">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
<xsd:element
name="RequestIdentifier" type="Q2:RequestIdentifier" maxOccurs="1">
</xsd:element>
type="Q2:NetworkStatusCode" maxOccurs="1" minOccurs="0">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="FormNetworkEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartRouter">
<xsd:complexType>
<xsd:sequence>
type="Q2:Timeout"/>
<xsd:element name="CallBackDestination"
type="xsd:string" minOccurs="0">
</xsd:element>
<xsd:element
name="NetworkConfiguration" type="Q2:NetworkConfiguration">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartRouterResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
type="Q2:NetworkStatusCode" minOccurs="0">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartRouterEvent">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:element>
<xsd:element
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartRouterEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Join">
<xsd:complexType>
<xsd:sequence>

Page 241
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
type="ns:Timeout">
</xsd:element>
<xsd:element name="Options"
type="ns:JoinConfiguration"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="JoinResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="JoinEvent">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="JoinEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Leave">
<xsd:complexType>
<xsd:sequence>
type="Q2:Timeout"/>
<xsd:element
name="CallbackDestination" type="xsd:string">
</xsd:element>
<xsd:element name="DeviceAddress"
type="ns:Address">
</xsd:element>
<xsd:element name="RemoveChildren"
type="xsd:boolean" minOccurs="0">
</xsd:element>
<xsd:element name="Rejoin"
type="xsd:boolean" minOccurs="0">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="LeaveResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="LeaveEvent">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
Page 242

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="LeaveEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="DiscoverNetworks">
<xsd:complexType>
<xsd:sequence>
type="Q2:Timeout"/>
</xsd:element>
<xsd:element name="ScanChannels"
type="xsd:string">
</xsd:element>
<xsd:element name="ScanDuration"
type="xsd:string">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="DiscoverNetworksResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
type="Q2:RequestIdentifier" minOccurs="0">
</xsd:element>
</xsd:element>
<xsd:element name="NetworkDescriptors"
type="Q2:NetworkDescriptorList" minOccurs="0">
</xsd:element>
<xsd:element name="NetworkCount"
type="xsd:unsignedInt"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="DiscoverNetworksEvent">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
<xsd:element
name="RequestIdentifier" type="Q2:RequestIdentifier">
</xsd:element>
type="Q2:NetworkStatusCode">
</xsd:element>
<xsd:element name="NetworkDescriptors"
type="Q2:NetworkDescriptorList" minOccurs="0">
</xsd:element>
<xsd:element name="NetworkCount"
type="xsd:unsignedInt"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="DiscoverNetworksEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Reset">
<xsd:complexType>
<xsd:sequence>

Page 243
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
type="Q2:Timeout"/>
</xsd:element>
<xsd:element name="WarmStart"
type="xsd:boolean">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ResetResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:element>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ResetEvent">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
<xsd:element
</xsd:element>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ResetEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PerformEnergyScan">
<xsd:complexType>
<xsd:sequence>
type="Q2:Timeout"/>
</xsd:element>
type="Q2:unsigned32Bit">
</xsd:element>
<xsd:element name="ScanDuration"
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PerformEnergyScanResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:element>
</xsd:element>
</xsd:element>
<xsd:element
name="EnergyDetectedList" type="ns:EnergyScanResult" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
Page 244

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
</xsd:complexType>
</xsd:element>
<xsd:element name="PerformEnergyScanEvent">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:element>
</xsd:element>
</xsd:element>
<xsd:element
name="EnergyDetectedList" type="ns:EnergyScanResult" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PerformEnergyScanEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NetworkStatusEvent">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:element>
<xsd:element name="NetworkAddr"
type="ns:NetworkAddress"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NetworkStatusEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PerformRouteDiscovery">
<xsd:complexType>
<xsd:sequence>
type="Q2:Timeout"/>
</xsd:element>
type="Q2:RouteDiscoveryInfo">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PerformRouteDiscoveryResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:element>
</xsd:element>
<xsd:element name="NetworkStatusCode"
</xsd:element>
</xsd:sequence>
</xsd:complexType>

Page 245
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
</xsd:element>
<xsd:element name="PerformRouteDiscoveryEvent">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
<xsd:element
</xsd:element>
</xsd:element>
<xsd:element name="NetworkStatusCode"
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PerformRouteDiscoveryEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendNWKCommand">
<xsd:complexType>
<xsd:sequence>
type="ns:Timeout">
</xsd:element>
</xsd:element>
type="ns:NWKMessageEvent">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendNWKCommandResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
type="ns:NWKMessageResult">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifyNWKMessageEvent">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
<xsd:element
</xsd:element>
type="ns:NWKMessageEvent"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifyNWKMessageEventResponse">
<xsd:complexType>
<xsd:sequence>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>


<wsdl:message name="CreateCallbackRequest">
<wsdl:part name="parameters" element="tns:CreateCallback"/>
</wsdl:message>
Page 246

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<wsdl:message name="CreateCallbackResponse">
<wsdl:part name="parameters" element="tns:CreateCallbackResponse"/>
</wsdl:message>
<wsdl:message name="SendZDPCommandRequest">
<wsdl:part name="parameters" element="tns:SendZDPCommand"/>
</wsdl:message>
<wsdl:message name="SendZDPCommandResponse">
<wsdl:part name="parameters" element="tns:SendZDPCommandResponse"/>
</wsdl:message>
<wsdl:message name="NotifyZDPEventRequest">
<wsdl:part name="parameters" element="tns:NotifyZDPEvent"/>
</wsdl:message>
<wsdl:message name="NotifyZDPEventResponse">
<wsdl:part name="parameters" element="tns:NotifyZDPEventResponse"/>
</wsdl:message>
<wsdl:message name="GetVersionRequest">
<wsdl:part name="parameters" element="tns:GetVersion"/>
</wsdl:message>
<wsdl:message name="GetVersionResponse">
<wsdl:part name="parameters" element="tns:GetVersionResponse"/>
</wsdl:message>
<wsdl:message name="GetRequest">
<wsdl:part name="parameters" element="tns:Get"/>
</wsdl:message>
<wsdl:message name="GetResponse">
<wsdl:part name="parameters" element="tns:GetResponse"/>
</wsdl:message>
<wsdl:message name="SetRequest">
<wsdl:part name="parameters" element="tns:Set"/>
</wsdl:message>
<wsdl:message name="SetResponse">
<wsdl:part name="parameters" element="tns:SetResponse"/>
</wsdl:message>
<wsdl:message name="DeleteCallbackRequest">
<wsdl:part name="parameters" element="tns:DeleteCallback"/>
</wsdl:message>
<wsdl:message name="DeleteCallbackResponse">
<wsdl:part name="parameters" element="tns:DeleteCallbackResponse"/>
</wsdl:message>
<wsdl:message name="ListCallbacksRequest">
<wsdl:part name="parameters" element="tns:ListCallbacks"/>
</wsdl:message>
<wsdl:message name="ListCallbacksResponse">
<wsdl:part name="parameters" element="tns:ListCallbacksResponse"/>
</wsdl:message>
<wsdl:message name="UpdateTimeoutRequest">
<wsdl:part name="parameters" element="tns:UpdateTimeout"/>
</wsdl:message>
<wsdl:message name="UpdateTimeoutResponse">
<wsdl:part name="parameters" element="tns:UpdateTimeoutResponse"/>
</wsdl:message>
<wsdl:message name="PollCallbackRequest">
<wsdl:part name="parameters" element="tns:PollCallback"/>
</wsdl:message>
<wsdl:message name="PollCallbackResponse">
<wsdl:part name="parameters" element="tns:PollCallbackResponse"/>
</wsdl:message>
<wsdl:message name="StartNodeDiscoveryRequest">
<wsdl:part name="parameters" element="tns:StartNodeDiscovery"/>
</wsdl:message>
<wsdl:message name="StartNodeDiscoveryResponse">
<wsdl:part name="parameters" element="tns:StartNodeDiscoveryResponse"/>
</wsdl:message>
<wsdl:message name="ReadNodeCacheRequest">
<wsdl:part name="parameters" element="tns:ReadNodeCache"/>
</wsdl:message>
<wsdl:message name="ReadNodeCacheResponse">
<wsdl:part name="parameters" element="tns:ReadNodeCacheResponse"/>
</wsdl:message>
<wsdl:message name="StartServiceDiscoveryRequest">
<wsdl:part name="parameters" element="tns:StartServiceDiscovery"/>
</wsdl:message>
<wsdl:message name="StartServiceDiscoveryResponse">
<wsdl:part name="parameters" element="tns:StartServiceDiscoveryResponse"/>
</wsdl:message>
<wsdl:message name="GetServiceDescriptorRequest">
<wsdl:part name="parameters" element="tns:GetServiceDescriptor"/>
</wsdl:message>
<wsdl:message name="GetServiceDescriptorResponse">
<wsdl:part name="parameters" element="tns:GetServiceDescriptorResponse"/>
</wsdl:message>
<wsdl:message name="ReadServiceCacheRequest">
<wsdl:part name="parameters" element="tns:ReadServiceCache"/>
</wsdl:message>
<wsdl:message name="ReadServiceCacheResponse">

Page 247
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<wsdl:part name="parameters" element="tns:ReadServiceCacheResponse"/>

</wsdl:message>
<wsdl:message name="StartGatewayDeviceRequest">
<wsdl:part name="parameters" element="tns:StartGatewayDevice"/>
</wsdl:message>
<wsdl:message name="StartGatewayDeviceResponse">
<wsdl:part name="parameters" element="tns:StartGatewayDeviceResponse"/>
</wsdl:message>
<wsdl:message name="ConfigureStartupAttributeSetRequest">
<wsdl:part name="parameters" element="tns:ConfigureStartupAttributeSet"/>
</wsdl:message>
<wsdl:message name="ConfigureStartupAttributeSetResponse">
<wsdl:part name="parameters"
element="tns:ConfigureStartupAttributeSetResponse"/>
</wsdl:message>
<wsdl:message name="ReadStartupAttributeSetRequest">
<wsdl:part name="parameters" element="tns:ReadStartupAttributeSet"/>
</wsdl:message>
<wsdl:message name="ReadStartupAttributeSetResponse">
<wsdl:part name="parameters" element="tns:ReadStartupAttributeSetResponse"/>
</wsdl:message>
<wsdl:message name="SendZCLCommandRequest">
<wsdl:part name="parameters" element="tns:SendZCLCommand"/>
</wsdl:message>
<wsdl:message name="SendZCLCommandResponse">
<wsdl:part name="parameters" element="tns:SendZCLCommandResponse"/>
</wsdl:message>
<wsdl:message name="NotifyZCLEventRequest">
<wsdl:part name="parameters" element="tns:NotifyZCLEvent"/>
</wsdl:message>
<wsdl:message name="NotifyZCLEventResponse">
<wsdl:part name="parameters" element="tns:NotifyZCLEventResponse"/>
</wsdl:message>
<wsdl:message name="ConfigureNodeDescriptorRequest">
<wsdl:part name="parameters" element="tns:ConfigureNodeDescriptor"/>
</wsdl:message>
<wsdl:message name="ConfigureNodeDescriptorResponse">
<wsdl:part name="parameters" element="tns:ConfigureNodeDescriptorResponse"/>
</wsdl:message>
<wsdl:message name="ConfigureUserDescriptorRequest">
<wsdl:part name="parameters" element="tns:ConfigureUserDescriptor"/>
</wsdl:message>
<wsdl:message name="ConfigureUserDescriptorResponse">
<wsdl:part name="parameters" element="tns:ConfigureUserDescriptorResponse"/>
</wsdl:message>
<wsdl:message name="ConfigureEndpointRequest">
<wsdl:part name="parameters" element="tns:ConfigureEndpoint"/>
</wsdl:message>
<wsdl:message name="ConfigureEndpointResponse">
<wsdl:part name="parameters" element="tns:ConfigureEndpointResponse"/>
</wsdl:message>
<wsdl:message name="ClearEndpointRequest">
<wsdl:part name="parameters" element="tns:ClearEndpoint"/>
</wsdl:message>
<wsdl:message name="ClearEndpointResponse">
<wsdl:part name="parameters" element="tns:ClearEndpointResponse"/>
</wsdl:message>
<wsdl:message name="SendAPSMessageRequest">
<wsdl:part name="parameters" element="tns:SendAPSMessage"/>
</wsdl:message>
<wsdl:message name="SendAPSMessageResponse">
<wsdl:part name="parameters" element="tns:SendAPSMessageResponse"/>
</wsdl:message>
<wsdl:message name="AddGroupRequest">
<wsdl:part name="parameters" element="tns:AddGroup"/>
</wsdl:message>
<wsdl:message name="AddGroupResponse">
<wsdl:part name="parameters" element="tns:AddGroupResponse"/>
</wsdl:message>
<wsdl:message name="RemoveGroupRequest">
<wsdl:part name="parameters" element="tns:RemoveGroup"/>
</wsdl:message>
<wsdl:message name="RemoveGroupResponse">
<wsdl:part name="parameters" element="tns:RemoveGroupResponse"/>
</wsdl:message>
<wsdl:message name="RemoveAllGroupsRequest">
<wsdl:part name="parameters" element="tns:RemoveAllGroups"/>
</wsdl:message>
<wsdl:message name="RemoveAllGroupsResponse">
<wsdl:part name="parameters" element="tns:RemoveAllGroupsResponse"/>
</wsdl:message>
<wsdl:message name="GetGroupListRequest">
<wsdl:part name="parameters" element="tns:GetGroupList"/>
</wsdl:message>
<wsdl:message name="GetGroupListResponse">
Page 248

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<wsdl:part name="parameters" element="tns:GetGroupListResponse"/>

</wsdl:message>
<wsdl:message name="GetBindingListRequest">
<wsdl:part name="parameters" element="tns:GetBindingList"/>
</wsdl:message>
<wsdl:message name="GetBindingListResponse">
<wsdl:part name="parameters" element="tns:GetBindingListResponse"/>
</wsdl:message>
<wsdl:message name="FormNetworkRequest">
<wsdl:part name="parameters" element="tns:FormNetwork"/>
</wsdl:message>
<wsdl:message name="FormNetworkResponse">
<wsdl:part name="parameters" element="tns:FormNetworkResponse"/>
</wsdl:message>
<wsdl:message name="StartRouterRequest">
<wsdl:part name="parameters" element="tns:StartRouter"/>
</wsdl:message>
<wsdl:message name="StartRouterResponse">
<wsdl:part name="parameters" element="tns:StartRouterResponse"/>
</wsdl:message>
<wsdl:message name="JoinRequest">
<wsdl:part name="parameters" element="tns:Join"/>
</wsdl:message>
<wsdl:message name="JoinResponse">
<wsdl:part name="parameters" element="tns:JoinResponse"/>
</wsdl:message>
<wsdl:message name="LeaveRequest">
<wsdl:part name="parameters" element="tns:Leave"/>
</wsdl:message>
<wsdl:message name="LeaveResponse">
<wsdl:part name="parameters" element="tns:LeaveResponse"/>
</wsdl:message>
<wsdl:message name="DiscoverNetworksRequest">
<wsdl:part name="parameters" element="tns:DiscoverNetworks"/>
</wsdl:message>
<wsdl:message name="DiscoverNetworksResponse">
<wsdl:part name="parameters" element="tns:DiscoverNetworksResponse"/>
</wsdl:message>
<wsdl:message name="ResetRequest">
<wsdl:part name="parameters" element="tns:Reset"/>
</wsdl:message>
<wsdl:message name="ResetResponse">
<wsdl:part name="parameters" element="tns:ResetResponse"/>
</wsdl:message>
<wsdl:message name="PerformEnergyScanRequest">
<wsdl:part name="parameters" element="tns:PerformEnergyScan"/>
</wsdl:message>
<wsdl:message name="PerformEnergyScanResponse">
<wsdl:part name="parameters" element="tns:PerformEnergyScanResponse"/>
</wsdl:message>
<wsdl:message name="PerformRouteDiscoveryRequest">
<wsdl:part name="parameters" element="tns:PerformRouteDiscovery"/>
</wsdl:message>
<wsdl:message name="PerformRouteDiscoveryResponse">
<wsdl:part name="parameters" element="tns:PerformRouteDiscoveryResponse"/>
</wsdl:message>
<wsdl:message name="FormNetworkEventRequest">
<wsdl:part name="parameters" element="tns:FormNetworkEvent"/>
</wsdl:message>
<wsdl:message name="FormNetworkEventResponse">
<wsdl:part name="parameters" element="tns:FormNetworkEventResponse"/>
</wsdl:message>
<wsdl:message name="JoinEventRequest">
<wsdl:part name="parameters" element="tns:JoinEvent"/>
</wsdl:message>
<wsdl:message name="JoinEventResponse">
<wsdl:part name="parameters" element="tns:JoinEventResponse"/>
</wsdl:message>
<wsdl:message name="DiscoverNetworksEventRequest">
<wsdl:part name="parameters" element="tns:DiscoverNetworksEvent"/>
</wsdl:message>
<wsdl:message name="DiscoverNetworksEventResponse">
<wsdl:part name="parameters" element="tns:DiscoverNetworksEventResponse"/>
</wsdl:message>
<wsdl:message name="PerformEnergyScanEventRequest">
<wsdl:part name="parameters" element="tns:PerformEnergyScanEvent"/>
</wsdl:message>
<wsdl:message name="PerformEnergyScanEventResponse">
<wsdl:part name="parameters" element="tns:PerformEnergyScanEventResponse"/>
</wsdl:message>
<wsdl:message name="NetworkStatusEventRequest">
<wsdl:part name="parameters" element="tns:NetworkStatusEvent"/>
</wsdl:message>
<wsdl:message name="NetworkStatusEventResponse">
<wsdl:part name="parameters" element="tns:NetworkStatusEventResponse"/>

Page 249
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
</wsdl:message>
<wsdl:message name="PerformRouteDiscoveryEventRequest">
<wsdl:part name="parameters" element="tns:PerformRouteDiscoveryEvent"/>
</wsdl:message>
<wsdl:message name="PerformRouteDiscoveryEventResponse">
element="tns:PerformRouteDiscoveryEventResponse"/>
</wsdl:message>
<wsdl:message name="GetNodeDescriptorRequest">
<wsdl:part name="parameters" element="tns:GetNodeDescriptor"/>
</wsdl:message>
<wsdl:message name="GetNodeDescriptorResponse">
<wsdl:part name="parameters" element="tns:GetNodeDescriptorResponse"/>
</wsdl:message>
<wsdl:message name="GetNodePowerDescriptorRequest">
<wsdl:part name="parameters" element="tns:GetNodePowerDescriptor"/>
</wsdl:message>
<wsdl:message name="GetNodePowerDescriptorResponse">
<wsdl:part name="parameters" element="tns:GetNodePowerDescriptorResponse"/>
</wsdl:message>
<wsdl:message name="GetUserDescriptorRequest">
<wsdl:part name="parameters" element="tns:GetUserDescriptor"/>
</wsdl:message>
<wsdl:message name="GetUserDescriptorResponse">
<wsdl:part name="parameters" element="tns:GetUserDescriptorResponse"/>
</wsdl:message>
<wsdl:message name="NotifySendAPSMessageEventRequest">
<wsdl:part name="parameters" element="tns:NotifySendAPSMessageEvent"/>
</wsdl:message>
<wsdl:message name="NotifySendAPSMessageEventResponse">
element="tns:NotifySendAPSMessageEventResponse"/>
</wsdl:message>
<wsdl:message name="NotifyAPSMessageEventRequest">
<wsdl:part name="parameters" element="tns:NotifyAPSMessageEvent"/>
</wsdl:message>
<wsdl:message name="NotifyAPSMessageEventResponse">
<wsdl:part name="parameters" element="tns:NotifyAPSMessageEventResponse"/>
</wsdl:message>
<wsdl:message name="StartRouterEventRequest">
<wsdl:part name="parameters" element="tns:StartRouterEvent"/>
</wsdl:message>
<wsdl:message name="StartRouterEventResponse">
<wsdl:part name="parameters" element="tns:StartRouterEventResponse"/>
</wsdl:message>
<wsdl:message name="LeaveEventRequest">
<wsdl:part name="parameters" element="tns:LeaveEvent"/>
</wsdl:message>
<wsdl:message name="LeaveEventResponse">
<wsdl:part name="parameters" element="tns:LeaveEventResponse"/>
</wsdl:message>
<wsdl:message name="ResetEventRequest">
<wsdl:part name="parameters" element="tns:ResetEvent"/>
</wsdl:message>
<wsdl:message name="ResetEventResponse">
<wsdl:part name="parameters" element="tns:ResetEventResponse"/>
</wsdl:message>
<wsdl:message name="NotifyNWKMessageEventRequest">
<wsdl:part name="parameters" element="tns:NotifyNWKMessageEvent"/>
</wsdl:message>
<wsdl:message name="NotifyNWKMessageEventResponse">
<wsdl:part name="parameters" element="tns:NotifyNWKMessageEventResponse"/>
</wsdl:message>
<wsdl:message name="SendNWKCommandRequest">
<wsdl:part name="parameters" element="tns:SendNWKCommand"/>
</wsdl:message>
<wsdl:message name="SendNWKCommandResponse">
<wsdl:part name="parameters" element="tns:SendNWKCommandResponse"/>
</wsdl:message>
<wsdl:message name="StartGatewayDeviceEventRequest">
<wsdl:part name="parameters" element="tns:StartGatewayDeviceEvent"/>
</wsdl:message>
<wsdl:message name="StartGatewayDeviceEventResponse">
<wsdl:part name="parameters" element="tns:StartGatewayDeviceEventResponse"/>
</wsdl:message>
<wsdl:message name="PollResultsRequest">
<wsdl:part name="parameters" element="tns:PollResults">
</wsdl:part>
</wsdl:message>
<wsdl:message name="PollResultsResponse">
<wsdl:part name="parameters" element="tns:PollResultsResponse"/>
</wsdl:message>
<wsdl:message name="NodeDiscoveryEventRequest">
<wsdl:part name="parameters" element="tns:NodeDiscoveryEvent">
</wsdl:part>
Page 250

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
</wsdl:message>
<wsdl:message name="NodeDiscoveryEventResponse">
<wsdl:part name="parameters" element="tns:NodeDiscoveryEventResponse"/>
</wsdl:message>
<wsdl:message name="NodeLeaveEventRequest">
<wsdl:part name="parameters" element="tns:NodeLeaveEvent">
</wsdl:part>
</wsdl:message>
<wsdl:message name="NodeLeaveEventResponse">
<wsdl:part name="parameters" element="tns:NodeLeaveEventResponse"/>
</wsdl:message>
<wsdl:message name="ServiceDiscoveryEventRequest">
<wsdl:part name="parameters" element="tns:ServiceDiscoveryEvent">
</wsdl:part>
</wsdl:message>
<wsdl:message name="ServiceDiscoveryEventResponse">
<wsdl:part name="parameters" element="tns:ServiceDiscoveryEventResponse"/>
</wsdl:message>
<wsdl:message name="ServiceDiscriptorEventRequest">
<wsdl:part name="parameters" element="tns:ServiceDiscriptorEvent">
</wsdl:part>
</wsdl:message>
<wsdl:message name="ServiceDiscriptorEventResponse">
<wsdl:part name="parameters" element="tns:ServiceDiscriptorEventResponse"/>
</wsdl:message>
<wsdl:message name="CreateAliasAddressRequest">
<wsdl:part name="parameters" element="tns:CreateAliasAddress">
</wsdl:part>
</wsdl:message>
<wsdl:message name="CreateAliasAddressResponse">
<wsdl:part name="parameters" element="tns:CreateAliasAddressResponse"/>
</wsdl:message>
<wsdl:message name="DeleteAliasAddressRequest">
<wsdl:part name="parameters" element="tns:DeleteAliasAddress">
</wsdl:part>
</wsdl:message>
<wsdl:message name="DeleteAliasAddressResponse">
<wsdl:part name="parameters" element="tns:DeleteAliasAddressResponse"/>
</wsdl:message>
<wsdl:message name="ListAddressesRequest">
<wsdl:part name="parameters" element="tns:ListAddresses">
</wsdl:part>
</wsdl:message>
<wsdl:message name="ListAddressesResponse">
<wsdl:part name="parameters" element="tns:ListAddressesResponse"/>
</wsdl:message>
<wsdl:message name="GmoLeaveRequest">
<wsdl:part name="parameters" element="tns:GmoLeave">
</wsdl:part>
</wsdl:message>
<wsdl:message name="GmoLeaveResponse">
<wsdl:part name="parameters" element="tns:GmoLeaveResponse"/>
</wsdl:message>
<wsdl:message name="GmoLeaveEventRequest">
<wsdl:part name="parameters" element="tns:GmoLeaveEvent">
</wsdl:part>
</wsdl:message>
<wsdl:message name="GmoLeaveEventResponse">
<wsdl:part name="parameters" element="tns:GmoLeaveEventResponse"/>
</wsdl:message>
<wsdl:message name="PermitJoinRequest">
<wsdl:part name="parameters" element="tns:PermitJoin">
</wsdl:part>
</wsdl:message>
<wsdl:message name="PermitJoinResponse">
<wsdl:part name="parameters" element="tns:PermitJoinResponse"/>
</wsdl:message>
<wsdl:message name="PermitJoinEventRequest">
<wsdl:part name="parameters" element="tns:PermitJoinEvent">
</wsdl:part>
</wsdl:message>
<wsdl:message name="PermitJoinEventResponse">
<wsdl:part name="parameters" element="tns:PermitJoinEventResponse"/>
</wsdl:message>

<wsdl:message name="SendInterPANMessageRequest">
<wsdl:part name="parameters" element="tns:SendInterPANMessage"/>
</wsdl:message>
<wsdl:message name="SendInterPANMessageResponse">
<wsdl:part name="parameters" element="tns:SendInterPANMessageResponse"/>
</wsdl:message>
<wsdl:message name="NotifyInterPANMessageEventRequest">
<wsdl:part name="parameters" element="tns:NotifyInterPANMessageEvent"/>
</wsdl:message>

Page 251
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<wsdl:message name="NotifyInterPANMessageEventResponse">
element="tns:NotifyInterPANMessageEventResponse"/>
</wsdl:message>

<wsdl:portType name="gmo">
<wsdl:operation name="GetVersion">
<wsdl:input message="tns:GetVersionRequest"/>
<wsdl:output message="tns:GetVersionResponse"/>
</wsdl:operation>
<wsdl:operation name="CreateCallback">
<wsdl:input message="tns:CreateCallbackRequest"/>
<wsdl:output message="tns:CreateCallbackResponse"/>
</wsdl:operation>
<wsdl:operation name="Get">
<wsdl:input message="tns:GetRequest"/>
<wsdl:output message="tns:GetResponse"/>
</wsdl:operation>
<wsdl:operation name="Set">
<wsdl:input message="tns:SetRequest"/>
<wsdl:output message="tns:SetResponse"/>
</wsdl:operation>
<wsdl:operation name="DeleteCallback">
<wsdl:input message="tns:DeleteCallbackRequest"/>
<wsdl:output message="tns:DeleteCallbackResponse"/>
</wsdl:operation>
<wsdl:operation name="ListCallbacks">
<wsdl:input message="tns:ListCallbacksRequest"/>
<wsdl:output message="tns:ListCallbacksResponse"/>
</wsdl:operation>
<wsdl:operation name="UpdateTimeout">
<wsdl:input message="tns:UpdateTimeoutRequest"/>
<wsdl:output message="tns:UpdateTimeoutResponse"/>
</wsdl:operation>
<wsdl:operation name="PollCallback">
<wsdl:input message="tns:PollCallbackRequest"/>
<wsdl:output message="tns:PollCallbackResponse"/>
</wsdl:operation>
<wsdl:operation name="StartNodeDiscovery">
<wsdl:input message="tns:StartNodeDiscoveryRequest"/>
<wsdl:output message="tns:StartNodeDiscoveryResponse"/>
</wsdl:operation>
<wsdl:operation name="ReadNodeCache">
<wsdl:input message="tns:ReadNodeCacheRequest"/>
<wsdl:output message="tns:ReadNodeCacheResponse"/>
</wsdl:operation>
<wsdl:operation name="StartServiceDiscovery">
<wsdl:input message="tns:StartServiceDiscoveryRequest"/>
<wsdl:output message="tns:StartServiceDiscoveryResponse"/>
</wsdl:operation>
<wsdl:operation name="GetServiceDescriptor">
<wsdl:input message="tns:GetServiceDescriptorRequest"/>
<wsdl:output message="tns:GetServiceDescriptorResponse"/>
</wsdl:operation>
<wsdl:operation name="ReadServiceCache">
<wsdl:input message="tns:ReadServiceCacheRequest"/>
<wsdl:output message="tns:ReadServiceCacheResponse"/>
</wsdl:operation>
<wsdl:operation name="StartGatewayDevice">
<wsdl:input message="tns:StartGatewayDeviceRequest"/>
<wsdl:output message="tns:StartGatewayDeviceResponse"/>
</wsdl:operation>
<wsdl:operation name="ConfigureStartupAttributeSet">
<wsdl:input message="tns:ConfigureStartupAttributeSetRequest"/>
<wsdl:output message="tns:ConfigureStartupAttributeSetResponse"/>
</wsdl:operation>
<wsdl:operation name="ReadStartupAttributeSet">
<wsdl:input message="tns:ReadStartupAttributeSetRequest"/>
<wsdl:output message="tns:ReadStartupAttributeSetResponse"/>
</wsdl:operation>
<wsdl:operation name="PollResults">
<wsdl:input message="tns:PollResultsRequest"/>
<wsdl:output message="tns:PollResultsResponse"/>
</wsdl:operation>
<wsdl:operation name="CreateAliasAddress">
<wsdl:input message="tns:CreateAliasAddressRequest"/>
<wsdl:output message="tns:CreateAliasAddressResponse"/>
</wsdl:operation>
<wsdl:operation name="DeleteAliasAddress">
<wsdl:input message="tns:DeleteAliasAddressRequest"/>
<wsdl:output message="tns:DeleteAliasAddressResponse"/>
</wsdl:operation>
<wsdl:operation name="ListAddresses">
<wsdl:input message="tns:ListAddressesRequest"/>
<wsdl:output message="tns:ListAddressesResponse"/>
Page 252

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
</wsdl:operation>
<wsdl:operation name="GmoLeave">
<wsdl:input message="tns:GmoLeaveRequest"/>
<wsdl:output message="tns:GmoLeaveResponse"/>
</wsdl:operation>
<wsdl:operation name="PermitJoin">
<wsdl:input message="tns:PermitJoinRequest"/>
<wsdl:output message="tns:PermitJoinResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="zdp">
<wsdl:operation name="SendZDPCommand">
<wsdl:input message="tns:SendZDPCommandRequest"/>
<wsdl:output message="tns:SendZDPCommandResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="zdpEvent">
<wsdl:operation name="NotifyZDPEvent">
<wsdl:input message="tns:NotifyZDPEventRequest"/>
<wsdl:output message="tns:NotifyZDPEventResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="zcl">
<wsdl:operation name="SendZCLCommand">
<wsdl:input message="tns:SendZCLCommandRequest"/>
<wsdl:output message="tns:SendZCLCommandResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="zclEvent">
<wsdl:operation name="NotifyZCLEvent">
<wsdl:input message="tns:NotifyZCLEventRequest"/>
<wsdl:output message="tns:NotifyZCLEventResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="aps">
<wsdl:operation name="ConfigureNodeDescriptor">
<wsdl:input message="tns:ConfigureNodeDescriptorRequest"/>
<wsdl:output message="tns:ConfigureNodeDescriptorResponse"/>
</wsdl:operation>
<wsdl:operation name="ConfigureUserDescriptor">
<wsdl:input message="tns:ConfigureUserDescriptorRequest"/>
<wsdl:output message="tns:ConfigureUserDescriptorResponse"/>
</wsdl:operation>
<wsdl:operation name="ConfigureEndpoint">
<wsdl:input message="tns:ConfigureEndpointRequest"/>
<wsdl:output message="tns:ConfigureEndpointResponse"/>
</wsdl:operation>
<wsdl:operation name="ClearEndpoint">
<wsdl:input message="tns:ClearEndpointRequest"/>
<wsdl:output message="tns:ClearEndpointResponse"/>
</wsdl:operation>
<wsdl:operation name="SendAPSMessage">
<wsdl:input message="tns:SendAPSMessageRequest"/>
<wsdl:output message="tns:SendAPSMessageResponse"/>
</wsdl:operation>
<wsdl:operation name="AddGroup">
<wsdl:input message="tns:AddGroupRequest"/>
<wsdl:output message="tns:AddGroupResponse"/>
</wsdl:operation>
<wsdl:operation name="RemoveGroup">
<wsdl:input message="tns:RemoveGroupRequest"/>
<wsdl:output message="tns:RemoveGroupResponse"/>
</wsdl:operation>
<wsdl:operation name="RemoveAllGroups">
<wsdl:input message="tns:RemoveAllGroupsRequest"/>
<wsdl:output message="tns:RemoveAllGroupsResponse"/>
</wsdl:operation>
<wsdl:operation name="GetGroupList">
<wsdl:input message="tns:GetGroupListRequest"/>
<wsdl:output message="tns:GetGroupListResponse"/>
</wsdl:operation>
<wsdl:operation name="GetBindingList">
<wsdl:input message="tns:GetBindingListRequest"/>
<wsdl:output message="tns:GetBindingListResponse"/>
</wsdl:operation>
<wsdl:operation name="GetNodeDescriptor">
<wsdl:input message="tns:GetNodeDescriptorRequest"/>
<wsdl:output message="tns:GetNodeDescriptorResponse"/>
</wsdl:operation>
<wsdl:operation name="GetNodePowerDescriptor">
<wsdl:input message="tns:GetNodePowerDescriptorRequest"/>
<wsdl:output message="tns:GetNodePowerDescriptorResponse"/>
</wsdl:operation>
<wsdl:operation name="GetUserDescriptor">

Page 253
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<wsdl:input message="tns:GetUserDescriptorRequest"/>
<wsdl:output message="tns:GetUserDescriptorResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="apsEvent">
<wsdl:operation name="NotifyAPSMessageEvent">
<wsdl:input message="tns:NotifyAPSMessageEventRequest"/>
<wsdl:output message="tns:NotifyAPSMessageEventResponse"/>
</wsdl:operation>
<wsdl:operation name="NotifySendAPSMessageEvent">
<wsdl:input message="tns:NotifySendAPSMessageEventRequest"/>
<wsdl:output message="tns:NotifySendAPSMessageEventResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="nwk">
<wsdl:operation name="FormNetwork">
<wsdl:input message="tns:FormNetworkRequest"/>
<wsdl:output message="tns:FormNetworkResponse"/>
</wsdl:operation>
<wsdl:operation name="StartRouter">
<wsdl:input message="tns:StartRouterRequest"/>
<wsdl:output message="tns:StartRouterResponse"/>
</wsdl:operation>
<wsdl:operation name="Join">
<wsdl:input message="tns:JoinRequest"/>
<wsdl:output message="tns:JoinResponse"/>
</wsdl:operation>
<wsdl:operation name="Leave">
<wsdl:input message="tns:LeaveRequest"/>
<wsdl:output message="tns:LeaveResponse"/>
</wsdl:operation>
<wsdl:operation name="DiscoverNetworks">
<wsdl:input message="tns:DiscoverNetworksRequest"/>
<wsdl:output message="tns:DiscoverNetworksResponse"/>
</wsdl:operation>
<wsdl:operation name="Reset">
<wsdl:input message="tns:ResetRequest"/>
<wsdl:output message="tns:ResetResponse"/>
</wsdl:operation>
<wsdl:operation name="PerformEnergyScan">
<wsdl:input message="tns:PerformEnergyScanRequest"/>
<wsdl:output message="tns:PerformEnergyScanResponse"/>
</wsdl:operation>
<wsdl:operation name="PerformRouteDiscovery">
<wsdl:input message="tns:PerformRouteDiscoveryRequest"/>
<wsdl:output message="tns:PerformRouteDiscoveryResponse"/>
</wsdl:operation>
<wsdl:operation name="SendNWKCommand">
<wsdl:input message="tns:SendNWKCommandRequest"/>
<wsdl:output message="tns:SendNWKCommandResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="nwkEvent">
<wsdl:operation name="FormNetworkEvent">
<wsdl:input message="tns:FormNetworkEventRequest"/>
<wsdl:output message="tns:FormNetworkEventResponse"/>
</wsdl:operation>
<wsdl:operation name="JoinEvent">
<wsdl:input message="tns:JoinEventRequest"/>
<wsdl:output message="tns:JoinEventResponse"/>
</wsdl:operation>
<wsdl:operation name="DiscoverNetworksEvent">
<wsdl:input message="tns:DiscoverNetworksEventRequest"/>
<wsdl:output message="tns:DiscoverNetworksEventResponse"/>
</wsdl:operation>
<wsdl:operation name="PerformEnergyScanEvent">
<wsdl:input message="tns:PerformEnergyScanEventRequest"/>
<wsdl:output message="tns:PerformEnergyScanEventResponse"/>
</wsdl:operation>
<wsdl:operation name="NetworkStatusEvent">
<wsdl:input message="tns:NetworkStatusEventRequest"/>
<wsdl:output message="tns:NetworkStatusEventResponse"/>
</wsdl:operation>
<wsdl:operation name="PerformRouteDiscoveryEvent">
<wsdl:input message="tns:PerformRouteDiscoveryEventRequest"/>
<wsdl:output message="tns:PerformRouteDiscoveryEventResponse"/>
</wsdl:operation>
<wsdl:operation name="StartRouterEvent">
<wsdl:input message="tns:StartRouterEventRequest"/>
<wsdl:output message="tns:StartRouterEventResponse"/>
</wsdl:operation>
<wsdl:operation name="LeaveEvent">
<wsdl:input message="tns:LeaveEventRequest"/>
<wsdl:output message="tns:LeaveEventResponse"/>
Page 254

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
</wsdl:operation>
<wsdl:operation name="ResetEvent">
<wsdl:input message="tns:ResetEventRequest"/>
<wsdl:output message="tns:ResetEventResponse"/>
</wsdl:operation>
<wsdl:operation name="NotifyNWKMessageEvent">
<wsdl:input message="tns:NotifyNWKMessageEventRequest"/>
<wsdl:output message="tns:NotifyNWKMessageEventResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="gmoEvent">
<wsdl:operation name="StartGatewayDeviceEvent">
<wsdl:input message="tns:StartGatewayDeviceEventRequest"/>
<wsdl:output message="tns:StartGatewayDeviceEventResponse"/>
</wsdl:operation>
<wsdl:operation name="NodeDiscoveryEvent">
<wsdl:input message="tns:NodeDiscoveryEventRequest"/>
<wsdl:output message="tns:NodeDiscoveryEventResponse"/>
</wsdl:operation>
<wsdl:operation name="NodeLeaveEvent">
<wsdl:input message="tns:NodeLeaveEventRequest"/>
<wsdl:output message="tns:NodeLeaveEventResponse"/>
</wsdl:operation>
<wsdl:operation name="ServiceDiscoveryEvent">
<wsdl:input message="tns:ServiceDiscoveryEventRequest"/>
<wsdl:output message="tns:ServiceDiscoveryEventResponse"/>
</wsdl:operation>
<wsdl:operation name="ServiceDiscriptorEvent">
<wsdl:input message="tns:ServiceDiscriptorEventRequest"/>
<wsdl:output message="tns:ServiceDiscriptorEventResponse"/>
</wsdl:operation>
<wsdl:operation name="GmoLeaveEvent">
<wsdl:input message="tns:GmoLeaveEventRequest"/>
<wsdl:output message="tns:GmoLeaveEventResponse"/>
</wsdl:operation>
<wsdl:operation name="PermitJoinEvent">
<wsdl:input message="tns:PermitJoinEventRequest"/>
<wsdl:output message="tns:PermitJoinEventResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="interPAN">
<wsdl:operation name="SendInterPANMessage">
<wsdl:input message="tns:SendInterPANMessageRequest"/>
<wsdl:output message="tns:SendInterPANMessageResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:portType name="interPANEvent">
<wsdl:operation name="NotifyInterPANMessageEvent">
<wsdl:input message="tns:NotifyInterPANMessageEventRequest"/>
<wsdl:output message="tns:NotifyInterPANMessageEventResponse"/>
</wsdl:operation>
</wsdl:portType>

<wsdl:binding name="ZDP" type="tns:zdp">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="SendZDPCommand">
<soap:operation soapAction="http://www.zigbee.org/"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="ZDPEvent" type="tns:zdpEvent">
<wsdl:operation name="NotifyZDPEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/NotifyZDPEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="ZCLEvent" type="tns:zclEvent">
<wsdl:operation name="NotifyZCLEvent">

Page 255
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<soap:operation
soapAction="http://www.zigbee.org/zgd/NotifyZCLEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="APSEvent" type="tns:apsEvent">
<wsdl:operation name="NotifyAPSMessageEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/NotifyAPSMessageEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="NotifySendAPSMessageEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/NotifySendAPSMessageEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="NWKEvent" type="tns:nwkEvent">
<wsdl:operation name="FormNetworkEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/FormNetworkEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="StartRouterEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/StartRouterEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ResetEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ResetEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="LeaveEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/LeaveEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="JoinEvent">
<soap:operation soapAction="http://www.zigbee.org/zgd/JoinEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
Page 256

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
</wsdl:operation>
<wsdl:operation name="NotifyNWKMessageEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/NotifyNWKMessageEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="DiscoverNetworksEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/DiscoverNetworksEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PerformEnergyScanEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/PerformEnergyScanEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="NetworkStatusEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/NetworkStatusEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PerformRouteDiscoveryEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/PerformRouteDiscoveryEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="ZCL" type="tns:zcl">
<wsdl:operation name="SendZCLCommand">
<soap:operation
soapAction="http://www.zigbee.org/zgd/SendZCLCommand"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="APS" type="tns:aps">
<wsdl:operation name="ConfigureNodeDescriptor">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ConfigureNodeDescriptor"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ConfigureUserDescriptor">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ConfigureUserDescriptor"/>
<wsdl:input>
</wsdl:input>

Page 257
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ConfigureEndpoint">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ConfigureEndpoint"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ClearEndpoint">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ClearEndpoint"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="SendAPSMessage">
<soap:operation
soapAction="http://www.zigbee.org/zgd/SendAPSMessage"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="AddGroup">
<soap:operation soapAction="http://www.zigbee.org/zgd/AddGroup"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="RemoveGroup">
<soap:operation
soapAction="http://www.zigbee.org/zgd/RemoveGroup"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="RemoveAllGroups">
<soap:operation
soapAction="http://www.zigbee.org/zgd/RemoveAllGroups"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GetGroupList">
<soap:operation
soapAction="http://www.zigbee.org/zgd/GetGroupList"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GetBindingList">
<soap:operation
soapAction="http://www.zigbee.org/zgd/GetBindingList"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GetNodeDescriptor">
Page 258

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<soap:operation
soapAction="http://www.zigbee.org/zgd/GetNodeDescriptor"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GetNodePowerDescriptor">
<soap:operation
soapAction="http://www.zigbee.org/zgd/GetNodePowerDescriptor"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GetUserDescriptor">
<soap:operation
soapAction="http://www.zigbee.org/zgd/GetUserDescriptor"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="NWK" type="tns:nwk">
<wsdl:operation name="SendNWKCommand">
<soap:operation
soapAction="http://www.zigbee.org/zgd/SendNWKCommand"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="FormNetwork">
<soap:operation
soapAction="http://www.zigbee.org/zgd/FormNetwork"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="StartRouter">
<soap:operation
soapAction="http://www.zigbee.org/zgd/StartRouter"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="Join">
<soap:operation soapAction="http://www.zigbee.org/zgd/Join"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="Leave">
<soap:operation soapAction="http://www.zigbee.org/zgd/Leave"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="DiscoverNetworks">
<soap:operation
soapAction="http://www.zigbee.org/zgd/DiscoverNetworks"/>
<wsdl:input>

Page 259
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="Reset">
<soap:operation soapAction="http://www.zigbee.org/zgd/Reset"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PerformEnergyScan">
<soap:operation
soapAction="http://www.zigbee.org/zgd/PerformEnergyScan"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PerformRouteDiscovery">
<soap:operation
soapAction="http://www.zigbee.org/zgd/PerformRouteDiscovery"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="GMO" type="tns:gmo">
<wsdl:operation name="GetVersion">
<soap:operation
soapAction="http://www.zigbee.org/zgd/GetVersion"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="CreateCallback">
<soap:operation
soapAction="http://www.zigbee.org/zgd/CreateCallback"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="Get">
<soap:operation soapAction="http://www.zigbee.org/zgd/Get"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="Set">
<soap:operation soapAction="http://www.zigbee.org/zgd/Set"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="DeleteCallback">
<soap:operation
soapAction="http://www.zigbee.org/zgd/DeleteCallback"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
Page 260

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ListCallbacks">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ListCallbacks"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="UpdateTimeout">
<soap:operation
soapAction="http://www.zigbee.org/zgd/UpdateTimeout"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PollCallback">
<soap:operation
soapAction="http://www.zigbee.org/zgd/PollCallback"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="StartNodeDiscovery">
<soap:operation
soapAction="http://www.zigbee.org/zgd/StartNodeDiscovery"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ReadNodeCache">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ReadNodeCache"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="StartServiceDiscovery">
<soap:operation
soapAction="http://www.zigbee.org/zgd/StartServiceDiscovery"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GetServiceDescriptor">
<soap:operation
soapAction="http://www.zigbee.org/zgd/GetServiceDescriptor"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ReadServiceCache">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ReadServiceCache"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="StartGatewayDevice">
<soap:operation
soapAction="http://www.zigbee.org/zgd/StartGatewayDevice"/>

Page 261
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PollResults">
<soap:operation
soapAction="http://www.zigbee.org/zgd/PollResults"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ConfigureStartupAttributeSet">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ConfigureStartupAttributeSet"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ReadStartupAttributeSet">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ReadStartupAttributeSet"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="CreateAliasAddress">
<soap:operation
soapAction="http://www.zigbee.org/zgd/CreateAliasAddress"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="DeleteAliasAddress">
<soap:operation
soapAction="http://www.zigbee.org/zgd/DeleteAliasAddress"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ListAddresses">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ListAddresses"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GmoLeave">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ListAddresses"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PermitJoin">
<soap:operation
soapAction="http://www.zigbee.org/zgd/PermitJoin"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
Page 262

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="GMOEvent" type="tns:gmoEvent">
<wsdl:operation name="StartGatewayDeviceEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/StartGatewayDeviceEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="NodeDiscoveryEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/NodeDiscoveryEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="NodeLeaveEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/NodeLeaveEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ServiceDiscoveryEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ServiceDiscoveryEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ServiceDiscriptorEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ServiceDiscriptorEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GmoLeaveEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/GmoLeaveEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PermitJoinEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/PermitJoinEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="INTERPAN" type="tns:interPAN">
<wsdl:operation name="SendInterPANMessage">
<soap:operation
soapAction="http://www.zigbee.org/zgd/SendInterPANMessage"/>
<wsdl:input>

Page 263
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
55
56
57
58
59
60
61
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="INTERPANEvent" type="tns:interPANEvent">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http"
style="document"/>
<wsdl:operation name="NotifyInterPANMessageEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/NotifyInterPANMessageEvent"/>
<wsdl:input>
</wsdl:input>
<wsdl:output>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="ZGDService">
<wsdl:port name="gmo" binding="tns:GMO">
<soap:address location="http://www.zigbee.org/"/>
</wsdl:port>
<wsdl:port name="zdp" binding="tns:ZDP">
<soap:address location="http://www.zigbee.org"/>
</wsdl:port>
<wsdl:port name="zcl" binding="tns:ZCL">
</wsdl:port>
<wsdl:port name="aps" binding="tns:APS">
</wsdl:port>
<wsdl:port name="nwk" binding="tns:NWK">
</wsdl:port>
<wsdl:port name="interPAN" binding="tns:INTERPAN">
</wsdl:port>
</wsdl:service>
<wsdl:service name="IPHAService">
<wsdl:port name="zdpEvent" binding="tns:ZDPEvent">
</wsdl:port>
<wsdl:port name="zclEvent" binding="tns:ZCLEvent">
</wsdl:port>
<wsdl:port name="apsEvent" binding="tns:APSEvent">
</wsdl:port>
<wsdl:port name="nwkEvent" binding="tns:NWKEvent">
</wsdl:port>
<wsdl:port name="gmoEvent" binding="tns:GMOEvent">
</wsdl:port>
<wsdl:port name="interPANEvent" binding="tns:INTERPANEvent">
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Page 264

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
REST Schema
<schema targetNamespace="http://www.zigbee.org/GWGRESTSchema"
elementFormDefault="qualified" xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://www.zigbee.org/GWGRESTSchema"
xmlns:crt="http://www.zigbee.org/GWGSchema">
<import namespace="http://www.zigbee.org/GWGSchema"
schemaLocation="CommonSchema.xsd"/>

<element name="Value" type="string">
<annotation>
<documentation>
Value element: sent with Get and UpdateCallbackTimeout
</documentation>
</annotation>
</element>
<element name="Callback" type="crt:Callback">
<annotation>
<documentation>
Callback element: sent with CreateCallback
</documentation>
</annotation>
</element>
<element name="Alias" type="crt:Address">
<annotation>
<documentation>
Alias element: sent with CreateAliasAddress
</documentation>
</annotation>
</element>
<element name="StartupAttributeInfo" type="crt:StartupAttributeInfo">
<annotation>
<documentation>
StartupAttributeInfo element: sent with
StartGatewayDevice and ConfigureStartupAttributeSet
</documentation>
</annotation>
</element>

<element name="ZDPCommand" type="crt:ZDPCommand">
<annotation>
<documentation>
ZDPCommand element: sent with SendZDPCommand
</documentation>
</annotation>
</element>

<element name="ZCLMessage" type="crt:ZCLMessage">
<annotation>
<documentation>
ZCLMessage element: sent with SendZCLCommand
</documentation>
</annotation>
</element>
<element name="NodeDescriptor" type="crt:NodeDescriptor">
<annotation>
<documentation>
NodeDescriptor element: sent with
</documentation>
</annotation>
</element>
<element name="PowerDescriptor" type="crt:PowerDescriptor">
<annotation>
<documentation>
PowerDescriptor element: sent with
</documentation>
</annotation>
</element>

Page 265
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<element name="UserDescriptor" type="crt:UserDescriptor">

<annotation>
<documentation>
UserDescriptor element: sent with
</documentation>
</annotation>
</element>
<element name="SimpleDescriptor" type="crt:SimpleDescriptor">
<annotation>
<documentation>
SimpleDescriptor element: sent with ConfigureEndpoint
</documentation>
</annotation>
</element>
<element name="APSMessage" type="crt:APSMessage">
<annotation>
<documentation>
APSMessage element: sent with SendAPSMessage
</documentation>
</annotation>
</element>
<element name="Group" type="crt:Group">
<annotation>
<documentation>
Group element: sent with AddGroup
</documentation>
</annotation>
</element>
<element name="NetworkConfiguration" type="crt:NetworkConfiguration">
<annotation>
<documentation>
NetworkConfiguration element: sent with FormNetwork and
StartRouter
</documentation>
</annotation>
</element>
<element name="JoinConfiguration" type="crt:JoinConfiguration">
<annotation>
<documentation>
JoinConfiguration element: sent with Join
</documentation>
</annotation>
</element>
<element name="ResetInfo" type="crt:ResetInfo">
<annotation>
<documentation>
ResetInfo element: sent with Reset
</documentation>
</annotation>
</element>
<element name="RouteDiscoveryInfo" type="crt:RouteDiscoveryInfo">
<annotation>
<documentation>
RouteInfo element: sent with PerformRouteDiscovery
</documentation>
</annotation>
</element>
<element name="NWKMessage" type="crt:NWKMessage">
<annotation>
<documentation>
NWKMessage element: sent with SendNWKMessage
</documentation>
</annotation>
</element>

<complexType name="Status">
<annotation>
<documentation>
The status complex type used in the REST bindings is a
composition of a status code whose values are common to
all bindings (see clause 5.2.1.3) and an optional
message that may be used by implementation for
diagnostic purposes.
Page 266

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
</documentation>
</annotation>
<sequence>
<element name="Code"
type="unsignedByte"
minOccurs="1" maxOccurs="1">
<annotation>
<documentation>
The status code.
</documentation>
</annotation>
</element>
<element name="Message"
type="string"
<annotation>
<documentation>
An optional message string that may clarify the
causes of an error condition.
</documentation>
</annotation>
</element>
</sequence>
</complexType>

<element name="Info" type="tns:Info"/>
<complexType name="Info">
<annotation>
<documentation>
This type is the XML root type of procedure responses, event
requests and event responses. It contains pertinent general
parameters and results, some recurrent result types and the
"Detail" choice, which contains the actual information being
conveyed.
</documentation>
</annotation>
<sequence>
<element name="Status"
type="tns:Status"
<annotation>
<documentation>
The Status general result. It is mandatory for all
procedure
results, event requests and event responses.
</documentation>
</annotation>
</element>
<element name="RequestIdentifier"
type="crt:RequestIdentifier"
<annotation>
<documentation>
The RequestIdentifier general parameter or general
result. See 5.2.1.4 for usage and status.
</documentation>
</annotation>
</element>
<element name="EventCallbackIdentifier"
type="crt:CallbackIdentifier"
<annotation>
<documentation>
The CallbackIdentifier of a previously registerd callback which
this event
must be notified.
</documentation>
</annotation>
</element>
<element name="NWKStatus" type="unsignedShort"
<annotation>
<documentation>
The NWKStatus result, typically returned
by many network layer procedures
</documentation>
</annotation>
</element>
<element name="Detail"

Page 267
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<annotation>
<documentation>
This element contains the actual information
exchanged between the ZGD and the IPHA. Being it
a choice, only one element shall be used at a
time: for the correct tag to use see the
documentation of each command in the
REST bindings section.
</documentation>
</annotation>
<complexType>
<sequence>
<element name="Version"
type="crt:Version"
<annotation>
<documentation>
Version element: returned by
GetVersion
</documentation>
</annotation></element>
<element name="Value"
type="string"
minOccurs="0" maxOccurs="unbounded">
<annotation>
<documentation>Value element: returned by
Get</documentation>
</annotation>
</element>
<element name="PolledMessage"
type="crt:PolledMessage"
<annotation>
<documentation>Message element: returned by
PollCallback</documentation>
</annotation>
</element>
<element name="CallbackIdentifier"
type="crt:CallbackIdentifier"
<annotation>
<documentation>
CallbackIdentifier element:
returned by CreateCallback
</documentation>
</annotation>
</element>
<element name="Callbacks"
type="crt:CallbackIdentifierList"
<annotation>
<documentation>
Callbacks element: returned by
ListCallbacks
</documentation>
</annotation>
</element>
<element name="Aliases"
type="crt:Aliases"
<annotation>
<documentation>
Aliases element: returned by
ListAddresses
</documentation>
</annotation>
</element>
<element name="WSNNode"
type="crt:WSNNode"
<annotation>
<documentation>
WSNNode element: sent with
NodeDiscoveryEvent
</documentation>
</annotation>
</element>
Page 268

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<element name="WSNNodes"
type="crt:WSNNodeList"
<annotation>
<documentation>
WSNNodes element: returned by
ReadNodeCache
</documentation>
</annotation>
</element>
<element name="NodeServices"
type="crt:NodeServices"
<annotation>
<documentation>
NodeServices element: sent with
</documentation>
</annotation>
</element>
<element name="ServiceDescriptor"
type="crt:ServiceDescriptor"
<annotation>
<documentation>
ServiceDescriptor element: sent
with ServiceDescriptorEvent
</documentation>
</annotation>
</element>
<element name="NodeServicesList"
type="crt:NodeServicesList"
<annotation>
<documentation>
NodeServicesList element:
returned by ReadServiceCache
</documentation>
</annotation>
</element>
<element name="StartupAttributeInfo"
type="crt:StartupAttributeInfo" minOccurs="0" maxOccurs="1">
<annotation>
<documentation>
StartupAttributeInfo element:
returned by ReadStartupAttributeSet
</documentation>
</annotation>
</element>

<element name="ZDPMessage"
type="crt:ZDPMessage"
<annotation>
<documentation>
ZDPMessage element: returned by SendZDPCommand
</documentation>
</annotation>
</element>

<element name="ZCLCommandResult"
type="crt:ZCLCommandResult"
<annotation>
<documentation>
ZCLCommandResult element: returned by SendZCLCommand
</documentation>
</annotation>
</element>
<element name="ZCLMessage"
type="crt:ZCLMessage"
<annotation>
<documentation>
ZCLMessage element: sent with NotifyZCLEvent
</documentation>
</annotation>
</element>

Page 269
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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85

<element name="Endpoint"
type="crt:Endpoint"
<annotation>
<documentation>
Endpoint: returned by
ConfigureEndpoint
</documentation>
</annotation>
</element>
<element name="Groups"
type="crt:GroupList"
<annotation>
<documentation>
Groups element: returned by
GetGroupList
</documentation>
</annotation>
</element>
<element name="Bindings"
type="crt:BindingList"
<annotation>
<documentation>
Bindings element: returned by
GetBindingList
</documentation>
</annotation>
</element>
<element name="APSMessageEvent"
type="crt:APSMessageEvent"
<annotation>
<documentation>
APSMessageEvent element: sent
with NotifyAPSEvent
</documentation>
</annotation>
</element>
<element name="APSMessageResult"
type="crt:APSMessageResult"
<annotation>
<documentation>
APSMessage element: returned by
SendAPSMessage
</documentation>
</annotation>
</element>
<element name="NodeDescriptor" type="crt:NodeDescriptor"
<annotation>
<documentation>
NodeDescriptor element: returned
by GetNodeDescriptor
</documentation>
</annotation>
</element>
<element name="PowerDescriptor" type="crt:PowerDescriptor"
<annotation>
<documentation>
PowerDescriptor element: returned
by GetNodePowerDescriptor
</documentation>
</annotation>
</element>
<element name="UserDescriptor" type="crt:UserDescriptor"
<annotation>
<documentation>
UserDescriptor element: returned
by GetUserDescriptor
</documentation>
</annotation>
</element>
Page 270

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

<element name="NetworkDescriptors"
type="crt:NetworkDescriptorList"
minOccurs="0" maxOccurs="unbounded"/>
<element name="EnergyScanResult"
type="crt:EnergyScanResult"
minOccurs="0" maxOccurs="1"/>
<element name="NetworkStatusCode"
type="crt:NetworkStatusCode"
minOccurs="0" maxOccurs="1"/>
<element name="NWKMessageEvent"
type="crt:NWKMessageEvent"
<annotation>
<documentation>
NWKMessageEvent element: sent
with NotifyNWKMessageEvent
</documentation>
</annotation>
</element>
<element name="NWKMessageResult"
type="crt:NWKMessageResult"
<annotation>
<documentation>
APSMessage element: returned by
SendNWKMessage
</documentation>
</annotation>
</element>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</schema>

Page 271
Gatew ay Management Cluster
General Description
Profile ID: 0xa1e0
4
5
6
7
8
9
10
11
12
13
14
15
The main gateway use modes described in the specification focus on gateway functionality where the
gateway is configured to look like devices in the profiles within which the gateway is being used. In
these scenarios the ZigBee devices do not need to know about the gateway from a device perspective
and they do not need to use any gateway specific clusters in the gateway profile.
16
17
18
19
20
Finally, a third cluster called Common Data Sink (CDSC) is defined within this section and it is the
only mandatory cluster that a gateway device shall implement. This cluster is required in order to allow
to communicate from any profile or cluster for applications that want common network points for
sending data. The CDSC is under the gateway device profile and thus it can be discovered
independently of any network application profile.
21
Gatew ay Management Cluster
22
Cluster ID: 0x0100
23
24
25
26
27
28
29
30
31
32
33
34
35
The other way a gateway can be used is as a universal data sink where ZigBee devices do understand a
gateway device and its role. In order to facilitate this a gateway profile ID of 0xa1e0 can be used in
match descriptor requests to search for gateways and their mangament clusters. The devices can then
use the universal sink clusters to send data out of the ZigBee network. This mode would typically be
setup for reporting and data sensor networks. The two clusters in the gateway profile are the Gateway
management Cluster and the Data Interface Cluster described below.
The gateway management cluster (GMC) provides a framework for the status, configuration and
control of the data endpoints used on gateways, it also provides gateway specific information to the
ZigBee network. The GMC is the primary public cluster in the gateway profile. For ZigBee systems
where a gateway is being used as a universal data sink, this allows any ZigBee device to discover a
gateway and which endpoints it has for receiving traffic to be forwarded on to one of its external
interfaces.
A gateway should not have both the GMC and a data interface cluster on the same endpoint as the
GMC requires ZCL processing and the universal data interfaces are typically meant to be raw and
not necessarily requiring a ZCL format.
G at ew a y M anag em en t C lu st e r At t ri but es
36
37
The following are the global (interface independent) Gateway Management cluster attributes.
38
Attribute
GW Mgmt Cluster
Version
GW Status
Page 272
Attribute ID
0x0000
Type
Uint8
Values
1 version 1
0x0001
BMP16
Bit 0 Status OK
Bit 1 GW General
Error
Bit 2 GW in standby
Bits 3 15 reserved

Number of interfaces
0x0002
Uint8
0 reserved
1-255
1
2
Gatew ay Data Interf ace Cluster
Cluster ID: 0x0200
4
5
6
7
8
9
The Data Interface Cluster (DIC) is used to describe the available universal data sink endpoints
associated with an external interface. This provides a discovery mechanism as well as a container for
status and control attributes and commands. The DIC contains the per interface attribute sets organized
as blocks of 256 attributes for each interface. Commands are also available to enable devices in the
ZigBee network to control interfaces such as creating a dial out connection for a non permenant
interface type.
10
11
12
13
The data endpoint type attribute listed below defines the type of endpoint usage for the data endpoint.
The universal data endpoints can be either ZCL based or raw where no assumption is made on the
incoming data. The last type is proxied profile which is the mode where the gateway is representing
itself as a device in a particular application profile.
14
G at ew a y D at a Int erf a ce C l u st er I nte rf a ce Blo c ks a nd At t ri but e s
15
16
The following are per interface attributes. There is one set for each interface in blocks of 0x100 (256d)
starting at attribute identifier 0x0000:
Interface 1
Attribute IDs 0x0000 0x00ff
Interface 2
Attribute IDs 0x0100 0x01ff
17
18
Attribute
Interface endpoint
External Interface
Type
Attribute ID
0x0000
0x0001
Type
Uint8
Uint16
Data Endpoint Type
0x0002
Uint8
Values
Endpoint for interface
0 - Undefined
1 Ethernet
2 RS-232
3 POTS
4 RS-485
5 Cellular
6 WiFi
7 HOMEPlug
8 Modbus
9 BACNet
10 WiMax
11 - LON
0xffff reserved
1 Universal Sink (GW
profile GW data cluster)
Non-ZCL based
2 Universal Sink (Raw,
Non-ZCL based)
3 Proxied profile

Page 273
External Interface
Speed
External Interface
Status
0x0003
Uint32
0x0004
Bmp16
4- 0xff reserved
bps
Bit 0 enabled\disabled
Bit 1
connected\disconnected
Bit 2 Link error
Bits 3-7 reserved
G at ew a y D at a Int erf a ce C li ent C omm an ds
2
3
4
5
6
The Data Interface Cluster defines commands that can be used for status, configuration and control of
the outbound interfaces from the ZigBee network. The commands can be used by any ZigBee network
device to control the gateway interfaces. These commands conform to the ZCL message style.
Cli en t Com ma nds D e f in ed
8
Command
Interface Control
Link Control
9
10
11
12
13
14
15
Command Id
0x00
0x01
Int erf a ce C ont rol C o mm and
The interface control command allows for the general control (enable\disable and low power state) of
an interface. This command can be used by some node on the ZigBee network should it need to
control the gateway interfaces.
Frame Format:
Interface Control SubCmd
1 octet
16
SubCommand
Disable
Enable
Low Power State
17
18
19
20
21
22
23
24
Value
0x00
0x01
0x02
Lin k Cont ro l Com m a nd
The Link control command is primarily used to control interfaces that may not have permenant
connections such as radio, cellular or POTS (plain old telephone set). These commands enable a
ZigBee node to have the gateway initiate or terminate a connection on one of its interfaces.
Frame Format:
Interface Link Control Cmd
1 octet
UINT8 SubCommand
Outgoing connection Id (only on

cmd 0x02)
1 octet
UINT8
Connection Time (Seconds)

2 octets
UINT16
(0 maintain until closed)
25
26
Page 274

SubCommand
Disable incoming connections
Enable incoming connections
Initiate outgoing connection
Terminate outgoing ocnnection
Value
0x00
0x01
0x02
0x03
Common Data Sink Cluster
Cluster ID: 0x0300
4
5
6
7
The Common Data Sink Cluster (CDSC) is the actual data cluster that can receive data from any profile
or cluster for applications that want common network points for sending data that can then be
forwarded out to one or more external interfaces. Since the CDSC is under the gateway device profile,
it can be discovered independently of any network application profile.
The CDSC does not have any attributes or commands associated with it .

Page 275

115552r00ZB BoD-ZigBee Network Device - ZigBee Gateway Standard Version 1 PDF

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

115552r00ZB BoD-ZigBee Network Device - ZigBee Gateway Standard Version 1 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

1

ZigBee Document 075468r35

Network Device: Gateway Specification

March 23rd, 2011

Accepted for release by:

Copyright 1996-2011 by the ZigBee Alliance.

Network Device: Gateway Specification

ZigBee Document 075468r33, March 23rd, 2011

ZigBee Alliance, Inc.

2400 Camino Ramon, Suite 375

San Ramon, CA 94583, USA

Copyright 2011, The ZigBee Alliance. All rights reserved.

ZigBee Document 075468r35, March 23rd, 2011

Network Device: Gateway Specification

Copyright 2011, The ZigBee Alliance. All rights reserved.

Network Device: Gateway Specification

ZigBee Document 075468r33, March 23rd, 2011

Major contributions were received from the following individuals:

Copyright 2011, The ZigBee Alliance. All rights reserved.

ZigBee Document 075468r35, March 23rd, 2011

Network Device: Gateway Specification

ZigBee Document 075468r35 .......................................................................................................................... i

Network Device: Gateway Specification ......................................................................................................... i

ZigBee Gateway Device........................................................................................................................... 6

Network Device: Gateway Specification

ZigBee Document 075468r33, March 23rd, 2011

Copyright 2011, The ZigBee Alliance. All rights reserved.

ZigBee Document 075468r35, March 23rd, 2011

Network Device: Gateway Specification

6.4.18.1 When Invoked ........................................................................................................ 37

Network Device: Gateway Specification

ZigBee Document 075468r33, March 23rd, 2011

6.7.1.1 When Invoked ......................................................................................................... 61

Copyright 2011, The ZigBee Alliance. All rights reserved.

ZigBee Document 075468r35, March 23rd, 2011

Network Device: Gateway Specification

6.9.2.2 When Invoked .......................................................................................................... 81

Network Device: Gateway Specification

ZigBee Document 075468r33, March 23rd, 2011

6.9.18 SendNWKMessage Procedure ..........................................................................................95

Secured Connection Protocol ( ScoP) ....................................................................................................99

Copyright 2011, The ZigBee Alliance. All rights reserved.

ZigBee Document 075468r35, March 23rd, 2011

Network Device: Gateway Specification

7.4.6.2 Transmission of SCoP frames ................................................................................ 127

Gateway Remote Interface Protocol (GRIP) ........................................................................................ 136

Network Device: Gateway Specification

ZigBee Document 075468r33, March 23rd, 2011

GRIP Layer Status Values ...........................................................................................................155

GRIP Binding for ZGD ........................................................................................................................156

10 SOAP Binding ......................................................................................................................................184

11 REST Binding ......................................................................................................................................186

Copyright 2011, The ZigBee Alliance. All rights reserved.

ZigBee Document 075468r35, March 23rd, 2011

Network Device: Gateway Specification

StartGatewayDevice Procedure ............................................................................................. 198

Information Base Attributes ........................................................................................................................ 208

Network Device: Gateway Specification

ZigBee Document 075468r33, March 23rd, 2011

GRIP ASN.1 ................................................................................................................................................209

SOAP & Rest Schema .................................................................................................................................217

REST Schema ..............................................................................................................................................265