Академический Документы
Профессиональный Документы
Культура Документы
3
4
5
7
8
9
Revision 35
Version Number: 1.0
10
11
12
Sponsored by:
ZigBee Alliance
13
14
15
16
17
Abstract:
This document specifies the protocols, requirements, and standards applying to ZigBee Gateway
Devices (ZGDs)
18
19
Keywords:
ZigBee, Gateway.
20
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
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.
19
20
21
Page ii
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
Page iv
Table of Contents
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
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
Copyright 2011, The ZigBee Alliance. All rights reserved.
This is an unaccepted ZigBee specification draft, subject to change.
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.3.2 Effect on Invocation ................................................................................................ 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.4.4 Effect on Invocation ................................................................................................ 23
6.4.5
PollCallback procedure .....................................................................................................23
6.4.5.1 When Invoked ......................................................................................................... 24
6.4.5.2 Effect on Invocation ................................................................................................ 24
6.4.6
DeleteCallback procedure .................................................................................................24
6.4.6.1 When Invoked ......................................................................................................... 24
6.4.6.2 Effect on Invocation ................................................................................................ 25
6.4.7
ListCallbacks procedure ....................................................................................................25
6.4.7.1 When Invoked ......................................................................................................... 25
6.4.7.2 Effect on Invocation ................................................................................................ 25
6.4.8
PollResults procedure .......................................................................................................25
6.4.8.1 When Invoked ......................................................................................................... 26
6.4.8.2 Effect on Invocation ................................................................................................ 26
6.4.9
UpdateTimeout procedure .................................................................................................26
6.4.9.1 When Invoked ......................................................................................................... 26
6.4.9.2 Effect on Invocation ................................................................................................ 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.11.3 Effect on Invocation .............................................................................................. 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.12.3 Effect on Invocation .............................................................................................. 30
6.4.13 ReadNodeCache Procedure ...............................................................................................30
6.4.13.1 When Invoked ....................................................................................................... 32
6.4.13.2 Effect on Invocation .............................................................................................. 32
6.4.14 StartServiceDiscovery Procedure ......................................................................................32
6.4.14.1 When Invoked ....................................................................................................... 32
6.4.14.2 Effect on Invocation .............................................................................................. 33
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.15.3 Effect on Invocation .............................................................................................. 34
6.4.16 GetServiceDescriptor Procedure .......................................................................................35
6.4.16.1 When Invoked ....................................................................................................... 35
6.4.16.2 Effect on Invocation .............................................................................................. 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.17.3 Effect on Invocation .............................................................................................. 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
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
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
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
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
Page xi
8.6
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
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
Page xiii
SOAP WSDL...............................................................................................................................................228
5
6
7
8
9
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
Copyright 2011, The ZigBee Alliance. All rights reserved.
This is an unaccepted ZigBee specification draft, subject to change.
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
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
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
Page xix
Change history
Page xx
Date
Comment
00
October 8, 2007
- Preliminary release.
01
- 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
03
04
05
06
07
08
December 3, 2007
09
10
11
12
January 6, 2008
13
14
Page xxi
15
February 4, 2008
16
17
18
19
March 7, 2008
20
Page xxii
22
June 3, 2008
Page xxiii
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
Page
xxiv
26
27
- 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
Page xxv
28
29
May 3, 2010
30
July, 2010
31
Semptember, 2010
32
October, 2010
33
34
35
Page
xxvi
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
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
7
8
Shall
9
10
Should
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
23
Octet
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
27
Procedure
An function on a ZGD.
28
Event Handler
A function on an IPHA.
29
Parameters
30
Results
31
Request
32
Response
33
Processing Task
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
CCM*
GMO
GRIDE
GRIP
IB
Information base
IP
Internet Protocol
IPHA
IP Host Application
MIC
10
NAT
11
NHLE
12
PDU
13
RPC
14
SAP
15
SCDE
16
SCIB
17
SCME
18
SCoP
19
SSL
SSL
20
TCP
21
TLS
TLS
22
UDP
23
WPAN
24
ZBD
25
ZGD
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
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
32
33
[r13] IETF RFC 4346, Transport Layer Security (TLS) Protocol Version 1.0
34
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
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
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
Page 7
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
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
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
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
Value
Description
0x00
TIMEOUT
0x01
GENERAL ERROR
0x02
PARAMETER_MISSING
0x03
PARAMETER_INVALID_VALUE
0x04
NETWORK_NOT_READY
0x05
EMPTY
0x06
NOT_ALLOWED
0x07
MEMORY_ERROR
0x08
APS_FAILURE
0x09
NETWORK_FAILURE
0x0A
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
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.
Copyright 2011, The ZigBee Alliance. All rights reserved.
This is an unaccepted ZigBee specification draft, subject to change.
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.
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
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.
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
ServiceDiscoveryEvent
ReadServiceCache
StartGatewayDevice
StartGatewayDeviceEvent
ConfigureStartupAttributeSet
ReadStartupAttributeSet
CreateAliasAddress
DeleteAliasAddress
ListAddresses
O
O
O
O
M
M
O
O
O
O
M
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.
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.
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.
Value
Status
Type
Valid
Range
Description
6. 4. 2 .1 W hen Inv o k ed
6. 4. 2 .2 Ef f ec t o n I nv oc at ion
8
9
10
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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.
Status
AttributeId
Value
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.
Status
M
Type
Valid
Range
Description
(see sub-clause 5.2.4)
6. 4. 3 .1 W hen Inv o k ed
6. 4. 3 .2 Eff ec t o n I nv oc at ion
8
9
10
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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.
Status
Filter
Action
Default
Type
Valid
Range
O
O
Description
(see sub-clause 6.4.4.1)
(see sub-clause 6.4.4.2)
Status
Status
CallbackIdentifier
Type
Valid
Range
Description
(see sub-clause 5.2.4)
Unsigned 32-bit
integer
0-0xffffffff
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
18
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.
Status
Type
Valid
Range
Description
Page 19
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
APSSourceEndpoint
APSDestinationEndpoint
If APSDestinationEndpoint is not
supplied in an AddressSpecification
then the filter sub-clause shall evaluate
to TRUE.
Status
Type
Valid
Range
Description
The APS cluster identifier field of a valid
APS frame.
APSClusterIdentifier
Page 20
APSClusterGroup
Page 21
6. 4. 4 .1 .1 Filt e r S ynt a x
The abstract filter elements shall be organized into a valid Filter syntax:
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
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
Status
Description
DecodeMACBit
Reserved.
DecodeNWKBit
Reserved.
DecodeInterPANBit
DecodeAPSBit
DecodeZCLBit
DecodeZDPBit
Page 22
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
Status
Description
POLLED
The IPHA will use PollCallback procedure to retrive retained ZigBee frames.
GRIP
SOAP
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
15
16
6. 4. 4 .3 W hen Inv o k ed
17
18
6. 4. 4 .4 Ef f ec t o n I nv oc at ion
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
Status
CallbackIden
tifier
Default
Type
Valid
Range
Unsigned 32-bit
integer
0-0xffffffff
Description
A unique number used to reference and
manage the callback handler.
Page 23
Status
Status
Valid
Range
Type
AppliedDecodeSpecification
SendZDPCommandResults
SendZCLCommandResults
SendAPSCommandResults
SendInterPANCommandResults
Description
(see sub-clause 5.2.4)
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 )
One or more results of the
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)
One or more parameters of the
NotifyInterPANMessageEvent event
handler. (see sub-clause 6.5.5.2)
32-bit Bitmask
6. 4. 5 .1 W hen Inv o k ed
3
4
The PollCallback procedure is invoked by an IPHA to read retained messages from a particular
callback handler.
6. 4. 5 .2 Eff ec t o n I nv oc at ion
6
7
8
9
10
11
12
13
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
Status
CallbackIden
tifier
15
Default
Type
Valid
Range
Unsigned 32-bit
integer
0-0xffffffff
Description
A unique number used to reference and
manage the callback handler.
Status
M
Type
Valid
Range
Description
(see sub-clause 5.2.4)
16
6. 4. 6 .1 W hen Inv o k ed
17
Page 24
6. 4. 6 .2 Ef f ec t o n I nv oc at ion
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
(see sub-clause 5.2.4)
0x000xffffffff
NumberOfCallbacks
Integer
CallbackList
Array of
CallbackIdentifiers
6. 4. 7 .1 W hen Inv o k ed
The ListCallbacks procedure is invoked by an IPHA to get a list of configured callback handlers.
10
6. 4. 7 .2 Ef f ec t o n I nv oc at ion
11
12
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
(see sub-clause 5.2.1)
16
Name
Status
Type
Valid
Range
Description
Results
SendZDPCommandResults
SendZCLCommandResults
Page 25
SendAPSCommandResults
SendInterPANCommandResults
6. 4. 8 .1 W hen Inv o k ed
2
3
The PollResults procedure is invoked by an IPHA to read retained results from a particular nonblocking procedure invocation.
6. 4. 8 .2 Eff ec t o n I nv oc at ion
5
6
7
8
9
10
11
12
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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.
13
Name
Request
Identifier
Timeout
Status
Default
Type
Valid
Range
Description
14
Name
Status
Status
M
Type
Valid
Range
Description
(see sub-clause 5.2.4)
15
6. 4. 9 .1 W hen Inv o k ed
16
17
18
6. 4. 9 .2 Eff ec t o n I nv oc at ion
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.
Status
Type
Valid Range
Description
Timeout
CallbackDestination
ReportOnExistingNodes
Boolean
TRUE or
FALSE
ReportAnnouncements
Boolean
TRUE or
FALSE
ReportLeave
Boolean
TRUE or
FALSE
5
6
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
2
3
The NodeDiscoveryEvent event handler shall support the parameters specified in Table 27, and shall
support the results specified in Table 28.
Status
Type
Valid Range
Description
RequestIdentifer
ShortAddress
16-bit Device
Address
ZigBee NWK
Address
ExtendedAddress
64-bit Device
Address
IEEE Address
AliasAddress
Octet String
16-bit Device
Address
ZigBee NWK
Address
ParentNodeShortAddr
ess
ParentNodeFullAddre
ss
64-bit Device
Address
IEEE Address
CapabilityInformation
8-bit Bitmask
0x00 to 0xff
0x00 to 0xff
StartIndex
AssociatedDevicesLis
t
8-bit Integer
List of 16-bit
Device
Addresses
5
6
Status
M
Type
Valid Range
Description
(see sub-clause 5.2.4)
7
8
9
10
6. 4. 1 1. 1
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
Ef f ec t o n I nv oc at ion
18
19
The NodeLeaveEvent event handler shall support the parameters specified in Table 29, and shall
support the results specified in Table 30.
20
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
Status
Type
Valid Range
Description
(see sub-clause 5.2.4)
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
The RequestIdentifier parameter of the function shall be equal to the RequestIdentifier parameter of the
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
Ef f ec t o n I nv oc at ion
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA
shall return a Status of SUCCESS.
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
Status
Type
Status
Nodes
8-bit Integer
Array of Node
structures (see
Table 32)
NodeInformation
Valid Range
Description
(see sub-clause 5.2.4)
0x00 to 0xff
Status
Type
Valid
Range
Description
ShortAddress
16-bit
Device
Address
ZigBee
NWK
Address
ExtendedAddress
64-bit
Device
Address
IEEE
Address
AliasAddress
Octet String
16-bit
Device
Address
ZigBee
NWK
Address
ParentNodeShortAddress
ParentNodeFullAddress
CapabilityInformation
StartIndex
64-bit
Device
Address
IEEE
Address
8-bit
Bitmask
0x00 to
0xff
The MAC
capabilities of the
device. See [R1]
Table 3.47.
0x00 to
0xff
8-bit Integer
Page 31
AssociatedDevicesList
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
Ef f ec t o n I nv oc at ion
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
specified in Table 34.
10
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
11
12
Status
Type
Valid Range
Description
Status
RequestIdentifier
13
14
6. 4. 1 4. 1
15
16
W hen Inv o k ed
6. 4. 1 4. 2
Ef f ec t o n I nv oc at ion
2
3
4
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 SERVICE_DISCOVERY_EVENT for each discovered
service.
Page 33
2
3
The ServiceDiscoveryEvent event handler shall support the parameters specified in Table 35, and shall
support the results specified in Table 36.
Name
Type
Valid Range
Description
RequestIdentifer
ShortAddress
ZigBee NWK
Address
ExtendedAddress
IEEE Address
AliasAddress
Octet String
ActiveEndpoints
8-bit Integer
SimpleDescriptors
List of SimpleDescriptors
5
6
Status
Type
Valid Range
Description
(see sub-clause 5.2.4)
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
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
The RequestIdentifier parameter of the function shall be equal to the RequestIdentifier parameter of the
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
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA
shall return a Status of SUCCESS.
Page 34
W hen I nv o k ed
Ef f ec t o n I nv oc at ion
1
2
3
Status
Type
Valid Range
Description
Timeout
CallbackDestination
DestinationAddressMode
Integer
0x00 - 0xff
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.
If this parameter is omitted then it is
interpreted as a broadcast address
0xffff.
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
Ef f ec t o n I nv oc at ion
11
12
13
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 SERVICE_DESCRIPTOR_EVENT for the specified active
endpoint supported by the node of interest.
14
Page 35
2
3
The ServiceDescriptorEvent event handler shall support the parameters specified in Table 35,
and shall support the results specified in Table 36.
Name
Type
Valid Range
Description
RequestIdentifer
ShortAddress
ZigBee NWK
Address
ExtendedAddress
IEEE Address
AliasAddress
Octet String
ActiveEndpoint
8-bit Integer
SimpleDescriptor
SimpleDescriptor
5
6
Status
Type
Valid Range
Description
(see sub-clause 5.2.4)
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
11
6. 4. 1 7. 2
12
13
14
15
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
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA
shall return a Status of SUCCESS.
Page 36
W hen Inv o k ed
Ef f ec t o n I nv oc at ion
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
specified in Table 41.
Status
Type
Status
Nodes
8-bit Integer
List of Node
Service
structures (see
Table 42)
ServiceInformation
Valid Range
Description
(see sub-clause 5.2.4)
0x00 to 0xff
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
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
Ef f ec t o n I nv oc at ion
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
specified in Table 44.
Page 37
Status
Type
Valid Range
Description
Timeout
CallbackDestination
StartupAttributeSetIndex
8-bit
0x00-0xff
DeviceType
8-bit
Enumeration
ProtocolVersion
StackProfile
ChannelMask
ExtendedPANId
PANId
ShortAddress
TrustCenterAddress
TrustCenterMasterKey
NetworkKey
UseInsecureJoin
PreconfiguredLinkKey
NetworkKeySeqNum
NetworkKeyType
NetworkManagerAddress
StartupControl
ScanAttempts
TimeBetweenScans
Page 38
RejoinInterval
MaxRejoinInterval
IndirectPollRate
ParentRetryThreshold
ConcentratorFlag
ConcentratorRadius
ConcentratorDiscoveryTi
me
1
2
3
Status
Type
N/A
Valid Range
N/A
Description
Status
RequestIdentifier
NWKStatus
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.
Ef f ec t o n I nv oc at ion
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.
Status
Status
RequestIdentifier
NWKStatus
Type
Valid Range
Description
(see sub-clause 5.2.4)
(see sub-clause 5.2.1)
7
8
6. 4. 2 0. 1
9
10
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
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA
shall return a Status of SUCCESS.
19
20
21
W hen Inv o k ed
Ef f ec t o n I nv oc at ion
Page 40
Status
M
Type
8-bit
Valid Range
0x00-0xff
Description
Index of a previously of the Startup
Attribute Set to modify.
Defines the device type of the ZGD:
DeviceType
8-bit
Enumeration
ProtocolVersion
StackProfile
ChannelMask
ExtendedPANId
PANId
ShortAddress
TrustCenterAddress
TrustCenterMasterKey
NetworkKey
UseInsecureJoin
PreconfiguredLinkKey
NetworkKeySeqNum
NetworkKeyType
NetworkManagerAddress
StartupControl
ScanAttempts
TimeBetweenScans
RejoinInterval
Page 41
MaxRejoinInterval
IndirectPollRate
ParentRetryThreshold
ConcentratorFlag
ConcentratorRadius
ConcentratorDiscoveryTi
me
Status
Type
Valid Range
Description
(see sub-clause 5.2.4)
6. 4. 2 1. 1
3
4
6. 4. 2 1. 2
6
7
8
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
Ef f ec t o n I nv oc at ion
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
results specified in Table 49.
Page 42
Status
StartupAttributeSetIn
dex
Type
8-bit
Valid Range
0x00-0xff
Description
Index of a previously of the Startup
Attribute Set to read.
Status
Type
Valid Range
Description
(see sub-clause 5.2.4)
Defines the device type of the ZGD:
DeviceType
8-bit
Enumeration
ProtocolVersion
StackProfile
ChannelMask
ExtendedPANId
PANId
ShortAddress
TrustCenterAddress
TrustCenterMasterKey
NetworkKey
UseInsecureJoin
PreconfiguredLinkKey
NetworkKeySeqNum
NetworkKeyType
NetworkManagerAddress
StartupControl
ScanAttempts
Page 43
TimeBetweenScans
RejoinInterval
MaxRejoinInterval
IndirectPollRate
ParentRetryThreshold
ConcentratorFlag
ConcentratorRadius
ConcentratorDiscoveryTi
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
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
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.
The IEEE address of the device
referenced by the Alias.
Page 44
Status
M
Type
Valid
Range
Description
(see sub-clause 5.2.4)
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
Ef f ec t o n I nv oc at ion
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
Alias
Status
Default
15
Type
Octet String
Valid
Range
Description
Non-NULL
Status
Status
Type
Valid
Range
Description
(see sub-clause 5.2.4)
16
6. 4. 2 4. 1
17
18
6. 4. 2 4. 2
19
20
21
22
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
Ef f ec t o n I nv oc at ion
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
Status
Default
Type
16-bit Network
Address
EUI-64
Octet String
Valid
Range
Description
Page 45
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
Ef f ec t o n I nv oc at ion
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
Status
Type
Valid Range
Description
Timeout
CallbackDestination
DeviceAddress
Address
RemoveChildren
Boolean
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
2
3
6. 4. 2 6. 1
6. 4. 2 6. 2
6
7
8
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
Ef f ec t o n I nv oc at ion
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
results specified in Table 58.
23
Status
Type
Valid Range
Description
(see sub-clause 5.2.4)
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
Ef f ec t o n I nv oc at ion
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
Status
Type
Valid Range
Description
Timeout
CallbackDestination
DestinationAddressMo
de
DestinationAddress
PermitDuration
Integer
Address
Unsigned int 8
0x00 - 0xff
As specified by
the
DstAddrMode
parameter
0x00 0xff
If DestinationAddress is an alias
address then it shall be resolved to a
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
MgmtCommandStatus
N/A
Description
N/A
2
3
6. 4. 2 8. 1
6. 4. 2 8. 2
6
7
8
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
Ef f ec t o n I nv oc at ion
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
support the results specified in Table 61.
23
Status
Type
Valid Range
Description
(see sub-clause 5.2.4)
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
Page 49
6. 4. 2 9. 2
W hen Inv o k ed
2
3
4
5
6. 4. 2 9. 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.
shall
be
equal
to
the
Status
field
of
the
Ef f ec t o n I nv oc at ion
10
6.5
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
15
16
17
Implementation Status
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
specified in Table 64.
Page 50
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
0x000000000xffffffff
CallbackDestination
Octet string
Variable
0x00 - 0xff
DestinationAddress
Mode
Integer
Address
As specified by
the
DstAddrMode
parameter
TxOptions
8-bit Bitmap
0x00 to 0x07
Radius
8-bit Integer
0x00 to 0xff
ClusterID
16-bit Integer
ZigBee Cluster
ID
Variable
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
0x00000000-0xffffffff
Description
Source
16-bit Device
Address
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
Variable
Command
Octet string
2
3
6. 5. 1 .1 W hen Inv o k ed
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
6. 5. 1 .2 Ef f ec t o n I nv oc at ion
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
2
3
The NotifyZDPEvent event handler shall support the parameters specified in Table 64, and shall
support the results specified in Table 65.
Status
M
Type
Enumeration
Valid Range
SUCCESS
Description
(see sub-clause 5.2.4)
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
6. 5. 2 .2 W hen Inv o k ed
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
6. 5. 2 .3 Eff ec t o n I nv oc at ion
25
26
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA
shall return a Status of SUCCESS.
27
Page 54
6.6
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.
6
7
8
Implementation Status
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
specified in Table 68.
Page 55
Status
Type
Valid Range
Description
Timeout
32-bit
unsigned
integer
0x000000000xffffffff
CallbackDestination
Octet string
Variable
0x00 - 0xff
DestinationAddressMo
de
Integer
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 before it is
supplied to the APSDE-DATA.request
SAP.
The ZDP command frame is sent to this
address. (see [R1] sub-clause APSDEDATA.request DstAddress parameter)
If this parameter is omitted then it is
assumed that a binding table entry
exists in the GW that determines the
destination.
The identifier for the endpoint on the
destination device to which the ZCL
command is directed.
DestinationEndpoint
Endpoint ID
Any valid
endpoint ID
ProfileID
16-bit Integer
Any valid
profile ID
ClusterID
16-bit Integer
Any cluster ID
Page 56
Name
Status
Type
Valid Range
Description
parameter list and description in [R1]
Table 2.2 for a description of the
corresponding primitive parameter
The intended source endpoint on the
ZGD for ZCL command.
SourceEndpoint
Endpoint ID
Any valid
endpoint ID
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
ZCLPayload
Status
Type
Status
8-bit unsigned
Integer
RequestIdentifier
32-bit unsigned
Integer
CallbackIdentifier
32-bit unsigned
Integer
Valid Range
status Code from
Table 2
0x000000000xffffffff
0x000000000xffffffff
Description
(see sub-clause 5.2.4)
(see sub-clause 5.2.1)
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.
(see sub-clause 6.4.4)
Page 57
APSStatus
Status
Enumeration
RxTime
Integer
Implementation
specific
DestinationEP
SourceAddressMode
SourceAddress
Endpoint ID
Integer
Address
SourceExtendedAddress
64-bit
IEEE
address
SourceAliasAddress
Octet String
Page 58
0x00 - 0xff
As specified by
the
SourceAddressMode
parameter
SourceEP
Endpoint ID
ProfileID
16-bit Integer
ClusterID
16-bit Integer
ZCLHeader
Octet String
Octet string
6. 6. 1 .1 W hen Inv o k ed
The SendZCLCommand procedure is invoked by an IPHA to send an arbitrary ZCL frame OTA.
Page 59
6. 6. 1 .2 Eff ec t o n I nv oc at ion
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.
Status
Type
Valid Range
Description
(see sub-clause 5.2.4)
Status
Status
Enumeration
SUCCESS
6. 6. 2 .1 W hen Inv o k ed
9
10
The NotifyZCLEvent event handler is invoked by the ZGD on receipt of ZCL command from the
ZigBee network.
11
6. 6. 2 .2 Eff ec t o n I nv oc at ion
12
13
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA will
return a Status of SUCCESS.
14
Page 60
6.7
Implementation Status
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.
4
5
The ConfigureNodeDescriptor procedure shall support the parameters specified in Table 71 and the
results specified in Table 72.
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
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
6. 7. 1 .1 W hen Inv o k ed
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
6. 7. 1 .2 Eff ec t o n I nv oc at ion
2
3
4
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
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
16
17
6. 7. 2 .1 W hen Inv o k ed
18
19
The GetNodeDescriptor procedure is invoked by an IPHA in order to read the current ZigBee Node
Descriptor in the ZDO of the ZGD.
20
6. 7. 2 .2 Eff ec t o n I nv oc at ion
21
22
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
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
2
3
6. 7. 3 .1 W hen Inv o k ed
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.
6. 7. 3 .2 Ef f 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 the node power descriptor stored in the ZDO as defined in [R1] 2.3.2.4.
10
11
The ConfigureUserDescriptor procedure shall support the parameters specified in Table 75 and the
results specified in Table 76.
12
UserDescriptor
Status
Type
Default type:
Octet String
ZigBee User
Descriptor
Valid Range
Variable
Description
The information required to build a
ZigBee user descriptor. The default
encoding shall be [R1] Table 2.42
except otherwise specified for a specific
RPC binding in the present
specification.
13
14
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
6. 7. 4 .1 W hen Inv o k ed
2
3
The ConfigureUserDescriptor procedure is invoked by an IPHA in order to configure the ZigBee User
Descriptor in the ZDO of the ZGD.
6. 7. 4 .2 Eff ec t o n I nv oc at ion
5
6
7
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
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.
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
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
18
19
6. 7. 5 .1 W hen Inv o k ed
20
21
The GetUserDescriptor procedure is invoked by an IPHA in order to read the current ZigBee User
Descriptor in the ZDO of the ZGD.
22
6. 7. 5 .2 Eff ec t o n I nv oc at ion
23
24
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
return the User Descriptor stored in the ZDO as defined in [R1] 2.3.2.7.
25
26
27
Status
Endpoint
SimpleDescriptor
Type
8-bit Integer
Default type:
Octet String
ZigBee Simple
Descriptor
Valid Range
Description
0x01-0xf0
Variable
2
3
Status
Status
Type
Enumeration
Valid Range
SUCCESS,
NOT_ALLOWED,
MEMORY_ERROR
or any Status Code
defined in Table 2
Description
4
5
6. 7. 6 .1 W hen Inv o k ed
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
6. 7. 6 .2 Ef f ec t o n I nv oc at ion
16
17
18
19
20
21
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
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.
Page 65
2
3
The ClearEndpoint procedure shall support the parameters specified in Table 80 and the results
specified in Table 81.
Status
M
Type
8-bit Integer
Valid Range
0x01 to 0xf0
Description
The endpoint to clear from the list of
active endpoints
5
6
Status
Status
Type
Enumeration
Valid Range
SUCCESS,
NOT_ALLOWED,
or any Status Code
defined in Table 2
Description
7
8
6. 7. 7 .1 W hen Inv o k ed
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
6. 7. 7 .2 Eff ec t o n I nv oc at ion
18
19
20
21
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
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.
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
specified in Table 83.
Page 66
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
0x000000000xffffffff
CallbackDestination
Octet string
Variable
0x00 - 0xff
DestinationAddress
Mode
Integer
Address
As specified by
the
DstAddrMode
parameter
DestinationEndpoint
Endpoint ID
Any valid
endpoint ID
SourceEndpoint
8-bit Integer
ZigBee
Endpoint
ClusterID
16-bit Integer
ZigBee Cluster
Identifier
DataLength
16-bit Integer
Data
Octet String
Variable
TxOptions
8-bit Bitmap
0x00 to 0x07
Radius
8-bit Integer
0x00 to 0xff
Page 67
Status
Status
Type
Valid Range
Description
Enumeration
A Status Code
defined in Table
2
ConfirmStatus
Enumeration
See APSDEDATA.confirm
status Parameter
TxTime
Integer
Implementation
specific
2
3
6. 7. 8 .1 W hen Inv o k ed
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.
6. 7. 8 .2 Eff ec t o n I nv oc at ion
7
8
9
10
11
12
13
14
15
16
17
18
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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.
Page 68
Status
Status
M
ConfirmStatus
Type
Description
8-bit unsigned
Integer
Enumeration
See APSDEDATA.confirm
status Parameter
Implementation
specific
TxTime
Integer
RequestIdentifier
32-bit unsigned
Integer
Valid Range
0x000000000xffffffff
Status
M
Type
8-bit unsigned
Integer
Valid Range
status Code from
Table 2
Description
(see sub-clause 5.2.4)
4
5
6
Page 69
CallbackIdentifier
Status
Type
32-bit
unsigned
Integer
Valid Range
0x000000000xffffffff
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.
(see sub-clause 6.4.4)
DestinationAddressMode
Integer
0x00 - 0xff
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
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
Page 70
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
Ef f ec t o n I nv oc at ion
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
Status
Type
Valid Range
Description
GroupAddress
16-bit Integer
ZigBee Group
Address
Endpoint
8-bit Integer
0x01 0xf0
13
14
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
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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.
Ef f ec t o n I nv oc at ion
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
specified in Table 89.
Status
Type
Valid Range
Description
GroupAddress
16-bit Integer
ZigBee Group
Address
Endpoint
8-bit Integer
0x01 0xf0
5
6
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
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
Ef f ec t o n I nv oc at ion
18
19
The RemoveAllGroups procedure shall support the parameters specified in Table 90 and the results
specified in Table 91.
20
Status
M
Type
8-bit Integer
Valid Range
0x01 0xf0
Description
A endpoint on the ZGD
21
22
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
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
Ef f ec t o n I nv oc at ion
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
Status
Type
Valid Range
Description
Status
Enumeration
A Status Code
defined in Table
2
GroupCount
16-bit Integer
0x0000 to 0xffff
Default type:
Octet String
Array of
Endpoints Per
Group Entry
Variable
GroupList
13
14
Type
Valid Range
Description
GroupAddress
16-bit Integer
0x0000 to 0xffff
EndpointCount
8-bit Integer
0x00 to 0xff
EndpointList
Array of 8-bit
Integer
Variable
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
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
Ef f ec t o n I nv oc at ion
Status
Type
Valid Range
Description
Status
Enumeration
A Status Code
defined in Table
2
BindingCount
16-bit Integer
0x0000 to 0xffff
Default type:
Octet String
Array of
Binding Entry
Variable
BindingList
9
10
Type
Valid Range
Description
SourceAddress
64-bit Integer
ZigBee
Extended
Address
SourceEndpoint
8-bit Integer
0x01 to 0xf0
ClusterID
16-bit Integer
ZigBee Cluster
Identifier
GroupDestCount
16-bit Integer
0 to 216 -1
GroupDestinations
Variable
DeviceDestCount
16-bit Integer
0 to 216 -1
DeviceDestinations
Variable
11
Page 74
Type
Valid Range
Description
Address
64-bit Integer
ZigBee
Extended
Address
Endpoint
8-bit Integer
ZigBee
Endpoint
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
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
Inter-P AN
16
17
18
19
Implementation Status
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
results specified in Table 99.
Page 75
Status
Type
Valid Range
Timeout
32-bit unsigned
integer
0x000000000xffffffff
CallbackDestination
Octet string
Variable
SrcAddressMode
Integer
0x03
Description
DestinationAddress
Mode
Integer
0x01 0x03
DestinationAddress
16-bit or 64-bit
address
As specified by
the AddrMode
parameter
DestPANID
16-bit PAN Id
0x0000 0xffff
ProfileID
Integer
0x0000 0xffff
ClusterID
Integer
0x0000 0xffff
ASDULength
Integer
0x00
(aMaxMACFra
meSize 9)
ASDU
Set of octets
ASDUHandle
Integer
0x00 0xff
2
3
Status
Status
ASDUHandle
ConfirmStatus
Type
Valid Range
Description
(see sub-clause 5.2.4)
Integer
0x00 0xff
4
5
Page 76
6. 8. 1 .1 W hen Inv o k ed
2
3
6. 8. 1 .2 Ef f ec t o n I nv oc at ion
5
6
7
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
Status
RequestIdentifier
Type
Valid Range
0-0xffffffff
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.
(see sub-clause 6.4.4)
SrcAddrMode
Integer
0x03
SrcPANId
16-bit PAN
Id
0x0000
0xffff
SrcAddress
64-bit
address
As specified
by the
SrcAddrMod
e parameter
DstAddrMode
Integer
0x01 0x03
DstAddress
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
Status
M
Type
Valid Range
Description
(see sub-clause 5.2.4)
Page 78
6. 8. 2 .1 W hen Inv o k ed
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.
6. 8. 2 .2 Ef f ec t o n I nv oc at ion
5
6
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the ZGD shall
use the INTRP-DATA.indication parameters for the request parameters of the function.
6.9
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
14
15
16
Implementation Status
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
Description
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
specified in Table 104.
Page 79
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
0x000000000xffffffff
CallbackDestination
Octet string
Variable
ScanChannels
Bitmap
32-bit field
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
0x00000000-0xffffffff
Status
INVALID_REQUEST,
STARTUP_FAILURE
or any status value
returned from
the MLMESTART.confirm
primitive
NLME-NETWORKFORMATION.confirm Status
parameter
NWKStatus
4
5
6. 9. 1 .1 W hen Inv o k ed
The FormNetwork procedure is invoked by an IPHA to issue a NLME Network Formation Command.
6. 9. 1 .2 Eff ec t o n I nv oc at ion
8
9
10
11
12
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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.
9
10
The FormNetworkEvent event handler shall support the parameters specified in Table 104, and shall
support the results specified in Table 105.
11
Status
M
Type
N/A
Valid Range
N/A
Description
(see sub-clause 5.2.4)
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
6. 9. 2 .2 W hen Inv o k ed
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
6. 9. 2 .3 Ef f ec t o n I nv oc at ion
22
23
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA
shall return a Status of SUCCESS.
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
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
0x000000000xffffffff
CallbackDestination
Octet string
Variable
BeaconOrder
Integer
0x00 0x0f
SuperframeOrder
Integer
0x00 0x0f
BatteryLifeExtension
Boolean
TRUE or
FALSE
2
3
Status
Type
Valid Range
Description
Status
N/A
N/A
RequestIdentifier
32-bit
unsigned
Integer
0x00000000-0xffffffff
Status
INVALID_REQUEST
or any status value
returned
from the
MLMESTART.
confirm primitive.
NLME-START-ROUTER.confirm
Status parameter
NWKStatus
4
5
6. 9. 3 .1 W hen Inv o k ed
The StartRouter procedure is invoked by an IPHA to issue a NLME Network Start Router Command.
6. 9. 3 .2 Eff ec t o n I nv oc at ion
8
9
10
11
12
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
support the results specified in Table 108.
Status
M
Type
N/A
Valid Range
N/A
Description
(see sub-clause 5.2.4)
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
primitive and the conditions described in clause 6.9.5.2 are met.
6. 9. 4 .2 W hen Inv o k ed
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
6. 9. 4 .3 Ef f ec t o n I nv oc at ion
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
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
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
0x000000000xffffffff
CallbackDestination
Octet string
Variable
ExtendedPanID
Integer
0x00000000000
00001
0xfffffffffffffffe
RejoinNetwork
Integer
0x00-0x03
ScanChannels
Bitmap
32-bit field
ScanDuration
Integer
0x00-0x0e
CapabilityInformation
Bitmap
SecurityEnable
Boolean
TRUE or
FALSE
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
0x00000000-0xffffffff
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
6. 9. 5 .1 W hen Inv o k ed
6. 9. 5 .2 Eff ec t o n I nv oc at ion
8
9
10
11
12
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
If the CallbackDestination parameter is not supplied, the procedure shall wait for the resulting NLME
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
12
13
The JoinNetworkEvent event handler shall support the parameters specified in Table 110, and shall
support the results specified in Table 111.
14
Status
M
Type
N/A
Valid Range
N/A
Description
(see sub-clause 5.2.4)
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
6. 9. 6 .2 W hen Inv o k ed
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
6. 9. 6 .3 Ef f ec t o n I nv oc at ion
23
24
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA
shall return a Status of SUCCESS.
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
Status
Type
Valid Range
Description
Timeout
CallbackDestination
The NLME-LEAVE.request
command frame is sent to this
address.
Address
DeviceAddress
Boolean
Rejoin
Boolean
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
(see sub-clause 5.2.4)
(see sub-clause 5.2.1)
Status
INVALID_REQUEST,
UNKNOWN_DEVICE,
or any status value
returned from the
MCPS-DATA.confirm
primitive.
NLME-LEAVE.confirm
Status parameter
4
5
6. 9. 7 .1 W hen Inv o k ed
6. 9. 7 .2 Eff ec t o n I nv oc at ion
8
9
10
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
If the CallbackDestination parameter is not supplied, the procedure shall wait for the resulting NLME
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.
Status
Status
Type
Valid Range
Description
(see sub-clause 5.2.4)
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.
6. 9. 8 .2 W hen Inv o k ed
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
6. 9. 8 .3 Ef f ec t o n I nv oc at ion
14
15
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA shall
return a Status of SUCCESS.
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
specified in Table 116.
19
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
0x000000000xffffffff
CallbackDestination
Octet string
Variable
ScanChannels
Bitmap
32-bit field
ScanDuration
Integer
0x00 0x0e
20
Page 87
1
2
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
0x000000000xffffffff
NetworkCount
Integer
0x00 0xff
The list
contains the
number of
elements given
by the
NetworkCount
parameter
NetworkDescriptorList
List of
network
descriptors
3
4
6. 9. 9 .1 W hen Inv o k ed
5
6
6. 9. 9 .2 Eff ec t o n I nv oc at ion
8
9
10
11
12
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
If the CallbackDestination parameter is not supplied, the procedure shall wait for the resulting NLME
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
2
3
The DiscoverNetworksEvent event handler shall support the parameters specified in Table 116, and
shall support the results specified in Table 117.
Status
Status
Type
N/A
Valid Range
N/A
Description
(see sub-clause 5.2.4)
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
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
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA
shall return a Status of SUCCESS.
21
Ef f ec t o n I nv oc at ion
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
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
0x000000000xffffffff
CallbackDestination
Octet string
Variable
WarmStart
Boolean
TRUE or
FALSE
25
Page 89
Status
M
NWKStatus
Type
Valid Range
Description
N/A
N/A
Status
NLME-RESET.confirm Status
parameter
2
3
6. 9. 1 1. 1
W hen Inv o k ed
6. 9. 1 1. 2
Ef f ec t o n I nv oc at ion
6
7
8
9
10
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
failed, the procedure shall return with a Status equal to NETWORK_FAILURE and NwkStatus equal to
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
results specified in Table 120.
20
Status
M
Type
N/A
Valid Range
N/A
Description
(see sub-clause 5.2.4)
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
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA
shall return a Status of SUCCESS.
Ef f ec t o n I nv oc at ion
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
specified in Table 122.
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
0x000000000xffffffff
CallbackDestination
Octet string
Variable
ScanChannels
Bitmap
32-bit field
ScanDuration
Integer
0x00-0x0e
9
10
11
Status
Status
Type
Valid Range
Description
N/A
N/A
NWKStatus
Status
SUCCESS,
or any valid
code from
the MAC
RequestIdentifier
32-bit unsigned
Integer
0x000000000xffffffff
ScannedChannels
EnergyDetectList
0x00 to 0xff
12
13
6. 9. 1 3. 1
W hen Inv o k ed
14
Page 91
6. 9. 1 3. 2
2
3
4
5
6
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
failed, 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.
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
If the CallbackDestination parameter is not supplied, the procedure shall wait for the resulting NLME
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
Ef f ec t o n I nv oc at ion
22
23
The PerformEnergyScanEvent event handler shall support the parameters specified in Table 122, and
shall support the results specified in Table 123.
24
Status
M
Type
N/A
Valid Range
N/A
Description
(see sub-clause 5.2.4)
25
26
6. 9. 1 4. 1
27
28
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
W hen Inv o k ed
6. 9. 1 4. 3
2
3
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA
shall return a Status of SUCCESS.
Ef f ec t o n I nv oc at ion
5
6
The NetworkStatusEvent event handler shall support the parameters specified in Table 27, and shall
support the results specified in Table 28.
Status
M
Type
Valid Range
Description
N/A
N/A
NWKStatus
Status
Any network
status code (see
Table 3.42 in
R[1])
NetworkAddr
Integer
0x0000 0xfff7
8
9
Status
M
Type
N/A
Valid Range
N/A
Description
(see sub-clause 5.2.4)
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
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA
shall return a Status of SUCCESS.
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
Ef f ec t o n I nv oc at ion
Page 93
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
0x000000000xffffffff
CallbackDestination
Octet string
Variable
DstAddrMode
Integer
0x00 0x02
DstAddr
16-bit
network
address
Any network
address or
multicast
address
Radius
Integer
0x00 0xff
NoRouteCache
Boolean
TRUE or
FALSE
2
3
4
Status
Type
Valid Range
Description
Status
N/A
N/A
RequestIdentifier
32-bit
unsigned
Integer
0x00000000-0xffffffff
NLME-ROUTEDISCOVERY.confirm Status
parameter
NWKStatus
status value
INVALID_REQUEST,
ROUTE_ERROR or
any status
value returned by the
MCPSDATA.
confirm primitive
NetworkStatusCode
Network
status code
5
6
6. 9. 1 6. 1
W hen Inv o k ed
7
8
6. 9. 1 6. 2
Ef f ec t o n I nv oc at ion
10
11
12
13
14
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
If the CallbackDestination parameter is not supplied, the procedure shall wait for the resulting NLME
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.
12
13
The PerformRouteDiscoveryEvent event handler shall support the parameters specified in Table 127,
and shall support the results specified in Table 128.
14
Status
M
Type
N/A
Valid Range
N/A
Description
(see sub-clause 5.2.4)
15
16
6. 9. 1 7. 1
17
18
19
6. 9. 1 7. 2
20
21
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
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the IPHA
shall return a Status of SUCCESS.
30
31
32
W hen Inv o k ed
Ef f ec t o n I nv oc at ion
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
specified in Table 130.
Page 95
Status
Type
Valid Range
Description
Timeout
32-bit unsigned
integer
0x000000000xffffffff
CallbackDestination
Octet string
Variable
DestinationAddress
Mode
Integer
0x01 or 0x02
DestinationAddress
16-bit
Address
0x0000-0xffff
aMaxMACFram
eSize (nwkcMACFra
m
eOverhead +
nwkcMinHeader
Overhead)
Integer
NsduLength
Nsdu
Set of
Octets
NsduHandle
Integer
0x00 0xFF
Radius
Unsigned
Integer
0x00 0xFF
NonmemberRadius
Integer
0x00 0x07
DiscoverRoute
Integer
0x00 0x01
SecurityUse
Boolean
TRUE or
FALSE
2
3
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
TxTime
Integer
Implementation specific
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
Ef f ec t o n I nv oc at ion
Upon invocation the ZGD shall process the request according to sub-clause 6.2.1. Next the ZGD shall
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
Status
Type
Valid Range
Description
Status
N/A
N/A
RequestIdentifier
32-bit
unsigned
Integer
0x00000000-0xffffffff
DstAddrMode
Integer
0x01 or 0x02
DstAddr
0x0000-0xffff
SrcAddr
16-bit
Address
16-bit
Device
address
NsduLength
Integer
< aMaxMACFrameSize
(nwkcMACFrameOverhea
d+
nwkcMinHeaderOverhead)
Nsdu
Set of octets
LinkQuality
Integer
0x00 0xff
RxTime
Integer
Implementation specific
SecurityUse
Boolean
TRUE or FALSE
2
3
Status
M
Type
N/A
Valid Range
N/A
Description
(see sub-clause 5.2.4)
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
Upon invocation the IPHA shall process the request according to sub-clause 6.2.2. Next the ZGD shall
use the NLE-DATA.indication parameters for the request parameters of the function.
Ef f ec t o n I nv oc at ion
10
Page 98
7.1
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
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
Page 99
SCME-SAP
SCDE
SCME
TCP
UDP
Internet Protocol
1
2
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.
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
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
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
Type
Valid Range
Description
IPversion
Octet
0x00 to 0x01
IP version
0x00 : IPv4
0x01 : IPv6
IPAddress
IP
Address
Port
IP port
1 to 65535
TransportMode
Octet
0x00 to 0x02
SecurityLevel
Octet
0x00 to 0x07
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
10
11
12
13
14
15
16
17
18
19
S em ant ic s of th e s er v i c e pr im it i ve
{
Handle,
IPVersion,
IPAddress,
Port,
TransportMode,
SecurityLevel
}
The table below specifies the parameters of the SCME-OPEN.indication primitive.
20
Type
Valid Range
Description
Handle
unsigned
32 bit
integer
0 to 232 -1
IPversion
Octet
0x00 to 0x01
IP version
0x00 : IPv4
0x01 : IPv6
IPAddress
IP Address
Port
IP port
1 to 65535
TransportMode
Octet
0x00 to 0x02
SecurityLevel
Octet
0x00 to 0x07
21
22
7. 2. 1 .1 .2 . 2
Page 102
W hen g e ner a te d
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
S em ant ic s of th e s er v i c e pr im it i ve
SCME-OPEN.confirm {
Status
Handle,
IPVersion,
IPAddress,
Port,
TransportMode,
SecurityLevel
}
The table below specifies the parameters of the SCME-OPEN.confirm primitive.
Page 103
Type
Status
Valid Range
Description
unsigned
16 bit
integer
0 to 65535
Handle
unsigned
32 bit
integer
0 to 232 -1
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
ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff (IPv6)
Port
IP port
1 to 65535
TransportMode
Octet
0x00 to 0x02
SecurityLevel
Octet
0x00 to 0x07
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
7. 2. 1 .1 .3 . 3 Ef f ec t of r ec e ip t
The handler to the connection that has been opened is transmitted to the NHLE with the status of this
connection.
10
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
S em ant ic s of th e s er v i c e pr im it i ve
SCME-CLOSE.request
15
16
Page 104
{
Handle
1
2
3
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
7. 2. 1 .1 .4 . 3 Ef f ec t of r ec e ip t
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
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
22
23
24
25
26
27
S em ant ic s of th e s er v i c e pr im it i ve
{
Handle,
Status
}
The table below specifies the parameters of the SCME-CLOSE.indication primitive.
28
Type
Valid Range
32
Description
Handle
unsigned 32
bit integer
0 to2 -1
Status
unsigned 16
bit integer
0 to 65535
29
30
7. 2. 1 .1 .5 . 2
W hen g e ner a te d
Copyright 2011, The ZigBee Alliance. All rights reserved.
This is an unaccepted ZigBee specification draft, subject to change.
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
S em ant ic s of th e s er v i c e pr im it i ve
SCME-CLOSE.confirm
10
11
12
13
14
15
Ef f ec t of r ec e ip t
{
Handle,
Status
}
The table below specifies the parameters of the SCME-CLOSE.confirm primitive.
16
Type
Valid Range
32
Description
Handle
unsigned 32
bit integer
0 to 2 -1
Status
unsigned 16
bit integer
0 to 65535
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
7. 2. 1 .1 .6 . 3 Ef f ec t of r ec e ip t
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
S em ant ic s of th e s er v i c e pr im it i ve
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.
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)
Port
IP port
1 to 65535
TransportMode
Octet
0x00 to 0x03
SecurityEnabled
Octet
0x00 to 0x01
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.
Ef f ec t of r ec e ip t
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
7
8
9
10
11
12
13
14
S em ant ic s of th e s er v i c e pr im it i ve
{
Status,
IPVersion,
IPAddress,
Port
}
The table below specifies the parameters of the SCME-LISTEN.confirm primitive.
15
Type
Valid Range
Description
Status
unsigned
16 bit
integer
0 to 65535
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)
Port
IP port
1 to 65535
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
7. 2. 1 .1 .8 . 3 Ef f ec t of r ec e ip t
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
}
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
S em ant ic s of th e S er v i c e Pr im it i v e
SCME-GET.confirm
{
Status,
SCIBAttribute,
SCIBAttributeLength,
SCIBAttributeValue
}
Page 109
Type
Valid Range
Description
Status
Enumeration
SUCCESS or
UNSUPPORTED_ATTRIBUTE
SCIBAttribute
Integer
SCIBAttributeLength
Integer
0x0001-0xffff
SCIBAttributeValue
Various
Attribute Specific
7. 2. 1 .2 .2 . 2
W hen G e n er a t ed
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
Ef f ec t o n R ec e i pt
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
14
15
16
17
18
19
20
S em ant ic s of th e S er v i c e Pr im it i v e
{
SCIBAttribute,
SCIBAttributeLength,
SCIBAttributeValue
}
21
Type
Valid Range
Description
SCIBAttribute
Integer
SCIBAttributeLength
Integer
0x0001-0xffff
SCIBAttributeValue
Various
Attribute Specific
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
W hen G e n er a t ed
7. 2. 1 .2 .3 . 3
Ef f ec t o n R ec e i pt
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
12
13
14
15
16
17
S em ant ic s of th e S er v i c e Pr im it i v e
{
Status,
SCIBAttribute
}
18
Type
Valid Range
Description
Status
Enumeration
SUCCESS,
INVALID_PARAMETER or
UNSUPPORTED_ATTRIBUTE
SCIBAttribute
Integer
See table
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
3
4
5
6
7
8
9
Handle,
Service,
Data
}
The table below specifies the parameters of the SCDE-DATA.request primitive.
10
Type
Valid Range
Description
Handle
unsigned
32 bit
integer
0 to 232 -1
Service
unsigned 8
bit integer
0x01 to 0x02
Data
Set of
octets
Variable
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
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.
Type
Valid Range
Description
Handle
unsigned
32 bit
integer
0 to 232 -1
Status
unsigned
16 bit
integer
0 to 65535
Service
unsigned 8
bit integer
0x01 to 0xff
Data
Set of
octets
Variable
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
7. 2. 2 .2 .3 Ef f ec t of re c eipt
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
3
4
5
6
7
8
Handle,
Status
}
The table below specifies the parameters of the SCDE-DATA.confirm primitive.
Type
Valid Range
Description
Handle
unsigned
32 bit
integer
0 to 232 -1
Status
unsigned
16 bit
integer
0 to 65535
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
7. 2. 2 .3 .3 Ef f ec t of re c eipt
15
16
7.3
17
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
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
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
10
11
12
13
14
Page 115
Transport Type
0x01
0x02
0x03
0x81
0x82
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
7. 3. 2 .3 P ac k et L en gt h Fi el d
10
The length of the packet is the total number of bytes of the SCoP frame as indicated on Figure 7.
11
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
Frame Id
Block number
Fragmentation Header
14
15
16
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
19
20
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
01
10
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
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
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
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
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.
Description
0x00
SCoP Service
0x01
Bridge Service
0x02
GRIP Service
0x03-0xFF
7. 3. 2 .7 P a ylo ad
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
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
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
Description
0x00
Hello
0x01
Hello Response
0x02
Hello Acknowledgement
0x04
Goodbye
0x05
Goodbye Response
0x06
0x07
0x03, 0x08-0xff
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
3
4
Three different transport modes may be used for a communication between SCoP entities. These
transport modes are defined in the table below.
Description
0x00
0x01
0x02
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
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.
Description
17755
SCoP Service
Mode 0 and 1
17756
Mode 2
10
11
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
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
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
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
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
1
2
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:
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
SCME-CLOSE.indication
11
12
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
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
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
SCDE-DATA.indication
17
18
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.
Copyright 2011, The ZigBee Alliance. All rights reserved.
This is an unaccepted ZigBee specification draft, subject to change.
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
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
7. 5. 1 SC o P Con st ant s
24
Description
Value
scopcMaxPacketSize
1500
scopcNATMappingRefreshPeriod
20
scopcLostConnectionTimeout
10
scopcHelloRetries
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
Identifier
Type
Range
Description
Default
scopTurnaroundTime
out
0xd0
16-bits Integer
0 to 65535
30000
scopMaxConnections
0xd1
32-bits Integer
0 to 232 -1
scopMaxConnection
Duration
0xd2
32-bits Integer
0 to 232 -1
2
3
The SCIB also contains attributes for the SCoP security service defined in the next section.
7.6
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
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
Identifier
Type
Range
Description
Default
scopCCMSecurityLevel
0xe0
Octet
0x00-07
0x07
scopLocalIdentifier
0xe1
Unsigned 64
bit integer
0 to 264 -1
scopKey
0xe2
Ordered set of
16 octets
scopOutgoingFrameCounter
0xe3
Ordered set of
4 octets
scopIncomingFrameCounterS
et
0xe4
Set of
incoming
frame counter
descriptor
values
Variable
scopPeerSecurityMaterialSet
0xe5
Set of security
material and
peer entity
identification
Variable
2
3
Type
Range
Description
Default
SenderIdentifier
Unsigned 64
bit integer
0 to 264 -1
IncomingFrameCounter
Ordered set of
4 octets
0 to 232 -1
4
5
Type
CCMSecurityLevel
Octet
Key
Ordered set of
16 octets
PeerIdentifier
Unsigned 64
bit integer
OutgoingFrameCounter
IncomingFrameCounter
Range
0x00-07
Description
Default
0x00
0 to 264 -1
unsigned 32
bit integer
0 to 232 -1
unsigned 32
bit integer
0 to 232 -1
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
16
i. The security level shall be the security level obtained from step 1
17
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.
Copyright 2011, The ZigBee Alliance. All rights reserved.
This is an unaccepted ZigBee specification draft, subject to change.
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.
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.
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.
42
7.7
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
Value
Description
SUCCESS
0x0000
ALREADY_CONNECTED
0x0001
INVALID_DESTINATION
0x0002
INVALID_ADDRESS
0x0003
UNSUPPORTED_TRANSPORT
0x0004
INVALID_TRANSPORT_TYPE
0x0005
BAD_TRANSPORT_MODE
0x0006
FRAME_LENGTH_ERROR
0x0007
INVALID_PROTOCOL_VERSION
0x0008
TCP_CNX_FAILED
0x0009
TLS_CNX_FAILED
0x000a
HANDSHAKE_FAILED
0x000b
TERMINATION_FORCED
0x000c
PING_NOT_RECEIVED
0x000d
PONG_NOT_RECEIVED
0x000e
ABNORMAL_TERMINATION
0x000f
LISTEN_FAILED
0x0010
INVALID_CONNECTION
0x0011
TRANSMISSION_FAILED
0x0012
NO_KEY
0x0020
BAD_SECURITY_LEVEL
0x0021
SECURITY_FAILED
0x0022
MAX_CONNECTIONS_REACHED
0x0023
UNSUPPORTED_ATTRIBUTE
0x0024
INVALID_PARAMETER
0x0025
Page 135
8.1
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
GRIDE
SCDE-SAP
GRIME-SAP
GRIME
SCME-SAP
20
21
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.
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
{
DestIPVersion,
DestIPAddress,
DestPort,
TransportMode,
SecurityLevel,
FunctionDomain,
FunctionCategory,
ManufacturerCode,
FunctionIdentifier,
FunctionParameters
}
The table below specifies the parameters of the GRIDE-DATA.request primitive.
Page 137
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
DestPort
IP port
1 to 65535
TransportMode
unsigned 8 bit
integer
SecurityLevel
unsigned 8 bit
integer
0 to 7
FunctionDomain
unsigned 8 bit
integer
0 to 255
FunctionCategory
unsigned 8 bit
integer
0 to 255
ManufacturerCode
unsigned 16
bit integer
0 to 65535
FunctionIdentifier
unsigned 16
bit integer
0 to 65535
FunctionParameters
Octet String
Variable
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.
8. 2. 1 .1 .3 Ef f ec t of re c eipt
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
Type
Valid Range
Description
RPCId
Integer
Implementation
specific
FunctionDomain
unsigned 8 bit
integer
0 to 255
FunctionCategory
unsigned 8 bit
integer
0 to 255
ManufacturerCode
unsigned 16 bit
integer
0 to 65535
FunctionIdentifier
unsigned 16 bit
integer
0 to 65535
FunctionParameters
Octet String
Variable
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
8. 2. 1 .2 .3 Ef f ec t of re c eipt
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.
9
10
11
12
13
14
15
{
RPCId,
Status,
FunctionResults
}
The table below specifies the parameters of the GRIDE-DATA.response primitive.
16
Type
Valid Range
Description
RPCId
Integer
Implementation
specific
Status
unsigned 16
bit integer
0 to 65535
FunctionResults
Octet String
Variable
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
8. 2. 1 .3 .3 Ef f ec t of re c eipt
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
21
22
23
24
25
26
{
Status,
FunctionResults
}
The table below specifies the parameters of the GRIDE-DATA.confirm primitive.
27
Type
Valid Range
Description
Status
unsigned 8
bit integer
0 to 255
FunctionResults
Octet String
Variable
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
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
23
8. 2. 1 .4 .3 Ef f ec t of re c eipt
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
}
Page 143
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
8. 2. 2 .2 .1 S em ant ic s of t he Se r v ic e P ri mit iv e
14
15
16
17
18
19
20
21
22
{
Status,
GRIBAttribute,
GRIBAttributeLength,
GRIBAttributeValue
}
Page 144
Type
Valid Range
Description
Status
Enumeration
SUCCESS or
UNSUPPORTED_ATTRIBUTE
GRIBAttribute
Integer
GRIBAttributeLength
Integer
0x0001-0xffff
GRIBAttributeValue
Various
Attribute Specific
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. 2. 2 .2 .3 Ef f ec t o n Re c eipt
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
8. 2. 2 .3 .1 S em ant ic s of t he Se r v ic e P ri mit iv e
13
14
15
16
17
18
19
20
GRIME-SET.request
{
GRIBAttribute,
GRIBAttributeLength,
GRIBAttributeValue
}
Page 145
Type
Valid Range
Description
GRIBAttribute
Integer
GRIBAttributeLength
Integer
0x0001-0xffff
GRIBAttributeValue
Various
Attribute Specific
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.
8. 2. 2 .3 .3 Ef f ec t o n Re c eipt
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
8. 2. 2 .4 .1 S em ant ic s of t he Se r v ic e P ri mit iv e
15
16
17
18
19
20
21
{
Status,
GRIBAttribute
}
22
Type
Valid Range
Description
Status
Enumeration
SUCCESS,
INVALID_PARAMETER or
UNSUPPORTED_ATTRIBUTE
GRIBAttribute
Integer
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.
8. 2. 2 .4 .3 Ef f ec t o n Re c eipt
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
10
Frame Format s
11
12
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
GRIP Header
GRIP payload
30
31
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
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
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
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
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.
0x00
Manufacturer
0x01-0xff
5
6
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
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
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
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 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
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
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 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
25
26
27
Octets: 2
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
specified in Table 174.
10
11
8.4
12
13
14
15
16
17
18
Originator
Peer
Recipient
Peer
Recipient
Application
GRIDE-DATA.request
Request
GRIDE-DATA.indication
GRIDE-DATA.response
Response
GRIDE-DATA.confirm
19
20
21
The transmission and reception of GRIP PDU is described in the next sub-clauses.
22
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
SCDE-DATA.indication
GRIDE-DATA.confirm
5
6
Application
GRIP
SCoP
GRIDE-DATA.request
SCDE-DATA.request
SCDE-DATA.confirm
SCDE-DATA.indication
GRIDE-DATA.confirm
7
8
10
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
SCDE-DATA.indication
GRIDE-DATA.indication
GRIDE-DATA.response
SCDE-DATA.request
SCDE-DATA.confirm
1
2
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.
Field Type
Valid Range
Description
RPC Identifier
Integer
Implementation
specific
SCoP Handle
Integer
Implementation
specific
Transaction Identifier
2 Octets
0x0000 to 0xffff
Function Domain
unsigned 8
bit integer
0 to 255
Function Category
unsigned 8
bit integer
0 to 255
Manufacturer Code
unsigned 16
bit integer
0 to 65535
Function Identifier
unsigned 16
bit integer
0 to 65535
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
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.
Page 154
Identifier
gripFunctionTimeout
0xf0
Type
16-bits Integer
Range
Description
0 to 65535
Default
10000
2
3
8.6
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.
Value
Description
SUCCESS
0x0000
0x00010x00ff
CONNECTION_CLOSED
0x0100
RPC_TIMEOUT
0x0101
TRANSACTION_ERROR
0x0200
FUNCTION_TIMEOUT
0x0201
UNSUPPORTED_FUNCTION
0x0300
BAD_PARAM_FORMAT
0x0301
FUNCTION_ERROR
0x0302
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
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
GRIDE-DATA.response
GRIP Response
Process results
r=f(p)
GRIDE-DATA.confirm
1
2
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
GRIDE-DATA.indication
Perform the
function
GRIDE-DATA.response
GRIDE-DATA.indication
Perform the
function
GRIDE-DATA.response
...
1
2
3
4
5
6
7
8
9
10
11
12
13
GetVersion
Get
Set
CreateCallback
PollCallback
DeleteCallback
ListCallbacks
PollResults
Updatetimeout
StartNodeDiscovery
ReadNodeCache
StartServiceDiscovery
GetServiceDescriptor
ServiceDiscoveryEvent
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
ConfigureStartupAttributeSet
ReadStartupAttributeSet
CreateAliasAddress
DeleteAliasAddress
ListAliasAddresses
SendZDPCommand
SendZCLCommand
ConfigureNodeDescriptor
GetNodeDescriptor
GetNodePowerDescriptor
ConfigureUserDescriptor
GetUserDescriptor
ConfigureEndpoint
ClearEndpoint
SendAPSMessage
AddGroup
RemoveGroup
RemoveAllGroups
GetGroupList
GetBindingList
SendInterPANMessage
FormNetwork
StartRouter
Join
Leave
DiscoverNetworks
Reset
PerformEnergyScan
PerformRouteDiscovery
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
ZGD
GRIP Client
IPHA
GRIP Server
IPHA
Application
GRIDE-DATA.request
GRIP Request
GRIDE-DATA.indication
GRIDE-DATA.response
GRIP Response
Process results
r=f(p)
GRIDE-DATA.confirm
6
7
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
Call a
function
GRIDE-DATA.request
GRIDE-DATA.confirm
Call a
function
GRIDE-DATA.request
GRIDE-DATA.confirm
23
24
25
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
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
ServiceDiscoveryEvent
LeaveEvent
StartGatewayDeviceEvent
NotifyZDPEvent
NotifyZCLEvent
NotifyAPSMessageEvent
NotifyInterPANMessageEvent
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
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
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
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
G et V er s i on
40
Page 162
9. 3. 1 .2 .1 . 2
G et
Parameters Encoding
Results Encoding
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
18
19
9. 3. 1 .2 .1 . 4
Cr e at e Ca l l bac k
20
Parameters Encoding
21
Style: structure
22
23
Results Encoding
24
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
30
The CallbackId field is 32-bit integer. The Integer32 simple type is used to encode the parameter.
31
Results Encoding
Copyright 2011, The ZigBee Alliance. All rights reserved.
This is an unaccepted ZigBee specification draft, subject to change.
Page 163
Style: structure
3
4
9. 3. 1 .2 .1 . 6
De l et eC a l lb ac k
Parameters Encoding
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
There is no parameter.
14
Results Encoding
15
Style: structure
16
17
18
9. 3. 1 .2 .1 . 8
P ol l R es u l ts
19
Parameters Encoding
20
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
25
26
9. 3. 1 .2 .1 . 9
27
Parameters Encoding
28
Style: structure
Page 164
Up d at eT im eo ut
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
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
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
23
Results Encoding
24
25
26
9. 3. 1 .2 .1 . 13 Re a dN od e Cac h e
27
Parameters Encoding
28
There is no parameter.
Page 165
Results Encoding
Style: structure
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
Results Encoding
10
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
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
There is no parameter.
21
Results Encoding
22
There is no parameter.
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
27
Results Encoding
28
There is no parameter.
Page 166
9. 3. 1 .2 .1 . 18 Re a dS er v ic eC ac he
Parameters Encoding
There is no parameter.
Results Encoding
Style: structure
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
12
Results Encoding
13
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
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
27
Results Encoding
28
29
Copyright 2011, The ZigBee Alliance. All rights reserved.
This is an unaccepted ZigBee specification draft, subject to change.
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
4
5
The StartupAttributeSetIndex field is a 8-bit Integer. The Integer8 simple type is used to encode this
parameter.
Results Encoding
Style: structure
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
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
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
26
Results Encoding
27
Style: structure
28
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
Results Encoding
Style: structure
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
14
Results Encoding
15
16
17
18
9. 3. 1 .2 .3 . 1
19
Parameters Encoding
20
Style: structure
21
22
Results Encoding
23
Style: structure
24
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
Copyright 2011, The ZigBee Alliance. All rights reserved.
This is an unaccepted ZigBee specification draft, subject to change.
Page 169
Results Encoding
9. 3. 1 .2 .4 . 1
Parameters Encoding
Style: structure
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
There is no parameter.
16
Results Encoding
17
Style: structure
18
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
There is no parameter.
23
Results Encoding
24
Style: structure
25
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
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
There is no parameter.
Results Encoding
10
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
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
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
Results Encoding
Style: structure
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
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
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
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
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
There is no parameter.
10
Results Encoding
11
Style: structure
12
13
14
9. 3. 1 .2 .4 . 14 G et B i nd i n gL is t
15
Parameters Encoding
16
There is no parameter.
17
Results Encoding
18
Style: structure
19
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
26
Results Encoding
27
Style: structure
28
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
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
14
Results Encoding
15
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
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
St ar tR o ut er
Results Encoding
The NWKStatus field is 8-bit Integer. The Integer8 simple type is used to encode the result.
4
5
9. 3. 1 .2 .6 . 4
Parameters Encoding
The NWKStatus field is 8-bit Integer. The Integer8 simple type is used to encode the parameter.
Results Encoding
10
St ar tR o ut er E ve n t
11
12
9. 3. 1 .2 .6 . 5
J o in
13
Parameters Encoding
14
Style: structure
15
16
Results Encoding
17
18
The NWKStatus field is 8-bit Integer. The Integer8 simple type is used to encode the result.
19
20
9. 3. 1 .2 .6 . 6
J o in E v e nt
21
Parameters Encoding
22
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
Results Encoding
The NWKStatus field is 8-bit Integer. The Integer8 simple type is used to encode the result.
6
7
9. 3. 1 .2 .6 . 8
Le a v e E ve n t
Parameters Encoding
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
18
Results Encoding
19
Style: structure
20
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
26
Results Encoding
27
28
29
9. 3. 1 .2 .6 . 11 Res et
Page 176
Parameters Encoding
The WarmStart field is a BOOLEAN. The BOOLEAN simple type is used to encode the parameter.
Results Encoding
The NWKStatus field is 8-bit Integer. The Integer8 simple type is used to encode the result.
7
8
9. 3. 1 .2 .6 . 12 Res et E ve n t Ha n d ler
Parameters Encoding
10
11
The NWKStatus field is 8-bit Integer. The Integer8 simple type is used to encode the parameter.
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
20
Results Encoding
21
Style: structure
22
23
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
28
Results Encoding
29
30
31
9. 3. 1 .2 .6 . 15 Ne t wor k St a t us E v e nt
Copyright 2011, The ZigBee Alliance. All rights reserved.
This is an unaccepted ZigBee specification draft, subject to change.
Page 177
Parameters Encoding
Style: structure
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
11
Results Encoding
12
Style: structure
13
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
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
26
Results Encoding
27
Style: structure
28
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
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
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
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
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
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
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
ServiceDiscoveryEvent
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
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
No specific result.
GetUserDescript
or
APS
0x0404
No param
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
Integer8 simple type
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.
Integer8 simple type
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
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
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
SOAP Type
Boolean
xsd::Boolean
gal::unsigned32Bit
gal::IeeeAddress
Integer
Smallest type of the following that can represent the range of the attribute:
Bit vector
16-bit PAN ID
gal::PanId
21
Page 184
Page 185
11 REST Binding
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
36
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
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
StartRouter
Join
Page 187
GET
DiscoverNetworks
/energy
GET
PerformEnergyScan
/networks/[addr]
DELETE
Leave
/reset
Reset command
PUT
Reset
/startup
POST
StartGatewayDevice
ConfigureStartupAttributeSet
GET
/net/[epid]
ReadStartupAttributeSet
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
Callback
Address aliases
/aliases/[alias]
Address Alias
DELETE
DeleteAliasAddress
/discovery
POST
PerformRouteDiscovery
/wsnnodes
GET
StartNodeDiscovery
ReadNodeCache
/wsnnodes/[addr]
/localnode
/allwsnnodes
POST
SendZDPCommand
SendNWKMessage
SendInterPANMessage
Page 188
1
Resource Path
Description
Method
Function
Leave network
DELETE
Leave procedure
/services
Active Services.
GET
StartServiceDiscovery
ReadServiceCache
POST
ConfigureEndpoint
Active service
(endpoint)
GET
GetServiceDescriptor
DELETE
ClearEndpoint
Node Descriptor
PUT
ConfigureNodeDescriptor
GET
GetNodeDescriptor
PUT
ConfigureNodePowerDescriptor
GET
ConfigureNodePowerDescriptor
PUT
ConfigureUserDescriptor
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
POST
CreateCallback
/wsconnection/message
Message I/O
POST
SendZCLCommand
Page 189
SendAPSMessage
1
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>
<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>
<Message>Parameter xyz
is missing</Message>
</Status>
</Info>
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>
<Message>Parameter xyz
is missing</Message>
</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
Copyright 2011, The ZigBee Alliance. All rights reserved.
This is an unaccepted ZigBee specification draft, subject to change.
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
20
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
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
Range
[a-zA-Z0-9]+
0x00-0xff
unsigned16
0x0000-0xffff
unsigned32
0x00000000-0xffffffff
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
hexadecimal form, lowercase,
zero-padded and without leading
0x or trailing h.
A 32-bit unsigned int, in
hexadecimal form, lowercase,
zero-padded and without leading
0x or trailing h.
A 64-bit unsigned int, in
hexadecimal form, lowercase,
zero-padded and without leading
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
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
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
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
Response XML message
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
Response XML message
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
Response XML message
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
Response XML message
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
Copyright 2011, The ZigBee Alliance. All rights reserved.
This is an unaccepted ZigBee specification draft, subject to change.
Page 195
3
4
5
6
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
Response XML message
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
Response XML message
URI components:
Component
[callback]
Syntax
unsigned32
URI
HTTP method
Request XML message
Response 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
Response 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
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
Response XML message
WSNNode
None
Nod eL eav e Ev ent Ev e nt H an dl er
3
Request XML message
Response XML message
WSNNode
WSNNode
URI
HTTP method
Request XML message
Response 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
Response XML message
None
8
9
10
11
12
URI
HTTP method
Request XML message
Response XML message
URI components:
Component
[aoi]
[NwkRootURI]/wsnnodes/[aoi]/services
GET
None
None
Syntax
address
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
Response XML message
NodeServices
None
URI
HTTP method
Request XML message
15
Page 197
2
3
None
Syntax
Address
unsigned8
4
Request XML message
Response XML message
5
6
7
Meaning
Address-Of-Interest function parameter
Active Endpoint parameter
Notes
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
Response XML message
NodeServicesList
8
9
10
URI
HTTP method
Request XML message
Response XML message
URI components:
Component
[aoi]
11
12
URI
HTTP method
Request XML message
Response 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
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
Response XML message
Page 198
None
None
1
2
URI
HTTP method
Request XML message
Response XML message
URI parameters:
Function Parameter
name
4
URI
HTTP method
Request XML message
Response XML message
5
6
URI parameters:
Function Parameter
name
StartupAttributeSetIndex
Notes
start=false
Status
index=unsigned8
Notes
URI
HTTP method
Request XML message
Response 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
Response XML message
8
12
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
Response 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.
Copyright 2011, The ZigBee Alliance. All rights reserved.
This is an unaccepted ZigBee specification draft, subject to change.
Page 199
Le av e P ro c edu r e
[NwkRootURI]/wsnnodes/[aoi]
DELETE
None
None
URI
HTTP method
Request XML message
Response 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
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
Response XML message
9
10
Le av e Ev e nt Ev e nt Ha ndl er
5
6
7
8
Notes
[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
Response 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
[NwkRootURI]/wsnnodes/[aoi]
POST
ZDPCommand
ZDPMessage
Syntax
address
Meaning
Destination parameter
Status
M
O
timeout=unsigned16
urilistener=string
ZDPMessage
None
S endZ CL Com ma nd P ro ce du re
[NwkRootURI]/localnode/services/[service]/wsnconnection/message
POST
ZCLCommand
ZCLMessage
Notes
URI
HTTP method
Request XML message
Response 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
Response XML message
ZCLMessage
None
9
10
11
URI
HTTP method
Request XML message
Response XML message
12
13
URI parameters:
Function Parameter
name
Timeout
Status
timeout=unsigned16
Notes
Page 201
URI
HTTP method
Request XML message
Response 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
Response XML message
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
Response XML message
URI parameters:
Function Parameter
name
Timeout
6
URI
HTTP method
Request XML message
Response XML message
7
8
9
10
11
12
13
timeout=unsigned16
Notes
14
15
Status
URI
HTTP method
Request XML message
Response XML message
URI components:
Component
[service]
Page 202
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
6
URI
HTTP method
Request XML message
Response XML message
URI components:
Component
[endpoint]
8
URI
HTTP method
Request XML message
Response XML message
URI components:
Component
[endpoint]
[group]
10
11
Syntax
M
O
Unsigned8
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
Response 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
Meaning
Endpoint parameter
Page 203
HTTP method
Request XML message
Response XML message
URI parameters:
Function Parameter
name
Timeout
GET
None
Groups
Status
timeout=unsigned16
Notes
2
URI
HTTP method
Request XML message
Response 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
[NwkRootURI]/wsnnodes/[aoi]
POST
InterPANMessage
InterPANMessageResult
URI
HTTP method
Request XML message
Response XML message
URI components:
Component
[aoi]
URI parameters:
Function Parameter
name
Timeout
CallbackDestination
Syntax
address
Status
M
O
timeout=unsigned16
urilistener=string
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
Destination parameter
URI
HTTP method
Request XML message
Response XML message
URI parameters:
Function Parameter
name
Timeout
CallbackDestination
Page 204
Status
O
O
M
timeout=unsigned16
urilistener=string
operation=formation
Notes
1
Request XML message
Response XML message
None
None
St ar tRo ute r P r oc edu r e
[GwRootURI]/networks
POST
NetworkConfiguration
None
URI
HTTP method
Request XML message
Response 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
6
Request XML message
Response XML message
None
None
Re s et P ro ce du re
[GwRootURI]/reset
PUT
ResetInfo
None
Joi n P ro ce du re
[GwRootURI]/networks
POST
JoinConfiguration
None
4
URI
HTTP method
Request XML message
Response XML message
URI parameters:
Function Parameter
name
Timeout
CallbackDestination
Notes
URI
HTTP method
Request XML message
Response 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
[GwRootURI]/networks
GET
None
Page 205
NetworkDescriptors
Status
O
O
M
timeout=unsigned16
urilistener=string
channel=unsigned32
duration=unsigned8
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
2
3
URI
HTTP method
Request XML message
Response 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
P erf or m En e rg yS c an E v ent Ev e nt
Han dl e r
EnergyScanResult
None
URI
HTTP method
Request XML message
Response XML message
6
7
10
11
Page 206
URI
HTTP method
Request XML message
Response XML message
URI components:
Component
[aoi]
3
4
Request XML message
Response XML message
S end NW KM es s ag e P r oc edu r e
[NwkRootURI]/wsnnodes/[aoi]
POST
NWKMessage
NWKMessageResult
Syntax
address
Meaning
Destination parameter
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
Id
ZigBee
Network
Status
0x00
Read
Only
Type
Byte
Yes
Range
Description
Default
Value
Description
0x00
INITIALIZING
0x01
DISCOVERING
0x02
JOINING
0x03
REJOINING
0x04
FORMING
0x05
AUTHENTICATING
0x06
FORMED
0x07
JOINED
0x08
ORPHANED
0x09
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 {
dstAddress-mode Integer8 OPTIONAL,
dst-address DestinationAddress OPTIONAL,
dst-endpoint ZigBeeEndpoint OPTIONAL,
profileID ZigBeeProfileID OPTIONAL,
clusterID ZigBeeClusterID,
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 {
dstAddress-mode Integer8 OPTIONAL,
dst-address DestinationAddress OPTIONAL,
dst-endpoint ZigBeeEndpoint OPTIONAL,
src-endpoint ZigBeeEndpoint ,
--profileID ZigBeeProfileID ,
clusterID ZigBeeClusterID,
txoption Integer8,
radius Integer8,
dataLength Integer8,
data OCTET STRING}
GroupParams ::= SEQUENCE {
group-address Integer16,
endpoint ZigBeeEndpoint}
NotifyAPSMessageEventParams ::= SEQUENCE {
dstAddress-mode Integer8,
dst-address DestinationAddress,
dst-endpoint ZigBeeEndpoint OPTIONAL,
srcAddress-mode Integer8,
src-address ZigBeeNetworkAddress,
src-ieeeAddress ZigBeeIEEEAddress
OPTIONAL,
src-aliasAddress ZigBeeAliasAddress
OPTIONAL,
src-endpoint ZigBeeEndpoint,
profileID ZigBeeProfileID ,
clusterID ZigBeeClusterID,
dataLength Integer8,
data OCTET STRING,
aps-status Status8,
security-status Status8,
link-quality Integer8,
rxtime TimeStamp}
SendInterPANMessageParams ::= SEQUENCE {
srcAddress-mode Integer8,
dstAddress-mode Integer8,
dst-address DestinationAddress,
dst-panId Integer16,
profileID ZigBeeProfileID,
clusterID ZigBeeClusterID,
asdu-length Integer16,
asdu OCTET STRING,
asdu-handle Integer8}
NotifyInterPANMessageEventParams ::= SEQUENCE {
srcAddress-mode Integer8,
src-panId Integer16,
src-address ZigBeeNetworkAddress,
dstAddress-mode Integer8,
dst-address ZigBeeNetworkAddress,
dst-panId Integer16,
profileID ZigBeeProfileID ,
clusterID ZigBeeClusterID,
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 {
beacon-order Integer8,
superFrame-order Integer8,
batteryLifeExtension BOOLEAN}
JoinParams ::= SEQUENCE {
extendedPANId ZigBeeExtendedPanId,
rejoin Integer8,
scanned-channels Integer32,
scan-duration Integer8,
capability-info Integer8,
security-enable BOOLEAN}
LeaveParams ::= SEQUENCE {
device-address DestinationAddress OPTIONAL,
remove-children RemoveChildren OPTIONAL,
rejoin Rejoin OPTIONAL}
DiscoverNetworksParams ::= SEQUENCE {
scanned-channels Integer32,
scan-duration Integer8}
NetworkStatusEventParams ::= SEQUENCE {
nwk-status Status8,
nwk-address ZigBeeNetworkAddress
OPTIONAL}
PerformRouteDiscoveryParams ::= SEQUENCE {
dstAddress-mode Integer8,
dst-address ZigBeeNetworkAddress
OPTIONAL,
radius Integer8 OPTIONAL,
noRoute-cache BOOLEAN OPTIONAL }
SendNWKMessageParams ::= SEQUENCE { dstAddress-mode Integer8,
dst-address DestinationAddress,
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 ,
src-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
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
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
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
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
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"
type="tns:IeeeAddress"/>
<element maxOccurs="1" minOccurs="1" name="Endpoint"
type="tns: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">
<restriction base="string">
<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">
<restriction base="string">
<enumeration value="GRIP"/>
<enumeration value="SOAP"/>
<enumeration value="REST"/>
</restriction>
</simpleType>
<simpleType name="Level">
<restriction base="string">
<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"/>
<element maxOccurs="1" minOccurs="0"
name="APSSourceEndpoint" type="tns:Endpoint"/>
<element maxOccurs="1" minOccurs="0"
name="APSDestinationEndpoint" type="tns:Endpoint"/>
</sequence>
</complexType>
</element>
<element maxOccurs="unbounded" minOccurs="0" name="MessageSpecification">
<complexType>
<sequence>
<element maxOccurs="1" minOccurs="0"
name="APSClusterIdentifier" type="tns:ClusterIdentifier"/>
<element maxOccurs="1" minOccurs="0"
name="APSClusterGroup" type="tns:ClusterGroup"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
<complexType name="Buffer">
<sequence/>
</complexType>
<simpleType name="DecodeLevel">
<restriction base="string">
<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>
<element maxOccurs="unbounded" minOccurs="1"
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">
<restriction base="string">
<enumeration value="Unsecured"/>
<enumeration value="SecuredNwkKey"/>
<enumeration value="SecuredLinkKey"/>
</restriction>
</simpleType>
<!-- Gateway Management Profile (GMP) -->
<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
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
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
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
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
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">
<minInclusive value="0"/>
<maxInclusive value="32767"/>
</restriction>
</simpleType>
</element>
<element maxOccurs="1" minOccurs="0" name="ServerMask"
type="tns:ServerMask"/>
<element maxOccurs="1" minOccurs="0" name="MaximumOutgoingTransferSize">
<simpleType>
<restriction base="unsignedShort">
<minInclusive value="0"/>
<maxInclusive value="32767"/>
</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>
<restriction base="string">
<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>
<restriction base="string">
<enumeration value="Critical"/>
<enumeration value="33Percent"/>
<enumeration value="66Percent"/>
<enumeration value="100Percent"/>
</restriction>
</simpleType>
</element>
</sequence>
</complexType>
<complexType name="UserDescriptor">
<sequence>
<element maxOccurs="1" minOccurs="1" name="Description">
<simpleType>
<restriction base="string">
<maxLength value="16"/>
</restriction>
</simpleType>
</element>
</sequence>
</complexType>
<complexType name="SimpleDescriptor">
<sequence>
<element maxOccurs="1" minOccurs="0" name="EndPoint">
<simpleType>
<restriction base="unsignedByte">
<minInclusive value="1"/>
<maxInclusive value="255"/>
</restriction>
</simpleType>
</element>
<element maxOccurs="1" minOccurs="0" name="ApplicationProfileIdentifier"
type="tns:ProfileIdentifier"/>
<element maxOccurs="1" minOccurs="0" name="ApplicationDeviceIdentifier"
type="tns:DeviceIdentifier"/>
<element maxOccurs="1" minOccurs="0" name="ApplicationDeviceVersion"
type="tns:unsignedNibble"/>
<element maxOccurs="unbounded" minOccurs="0"
name="ApplicationInputCluster" type="tns:ClusterIdentifier"/>
<element maxOccurs="unbounded" minOccurs="0"
name="ApplicationOutputCluster" type="tns:ClusterIdentifier"/>
</sequence>
</complexType>
<complexType name="Binding">
<sequence>
<element maxOccurs="1" minOccurs="1" name="SourceIEEEAddress"
type="tns:IeeeAddress"/>
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
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
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
<?xml version="1.0" encoding="UTF-8"?>
<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>
<!-- GMO Functions -->
<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="Status"
type="xsd:unsignedByte"/>
<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:element name="Status"
type="xsd:unsignedByte"/>
</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="Status"
type="xsd:unsignedByte"/>
<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
name="CallbackIdentifier" type="Q2:CallbackIdentifier"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PollCallbackResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
<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
name="CallbackIdentifier" type="Q2:CallbackIdentifier"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="DeleteCallbackResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
</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="Status"
type="xsd:unsignedByte"/>
<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="Status"
type="xsd:unsignedByte"/>
<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:element name="Status"
type="xsd:unsignedByte"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartNodeDiscovery">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="CallbackDestination"
type="xsd:string" minOccurs="0"/>
<xsd:element name="Timeout"
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>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
<xsd:element name="RequestIdentifier"
type="ns:RequestIdentifier" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NodeDiscoveryEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="RequestIdentifier" type="ns:RequestIdentifier"/>
<xsd:element name="NodeInfo"
minOccurs="1" type="ns:WSNNode"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NodeDiscoveryEventResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NodeLeaveEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="RequestIdentifier" type="ns:RequestIdentifier"/>
<xsd:element name="Address"
type="ns:Address"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NodeLeaveEventResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
</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="Status"
type="xsd:unsignedByte"/>
<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>
<xsd:element name="Timeout"
type="Q2:Timeout"/>
<xsd:element name="CallbackDestination"
type="xsd:string" minOccurs="0"/>
<xsd:element
name="AddressOfInterest" type="Q2:NetworkAddress"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartServiceDiscoveryResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
<xsd:element name="RequestIdentifier"
type="ns:RequestIdentifier" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ServiceDiscoveryEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="RequestIdentifier" type="ns:RequestIdentifier"/>
<xsd:element name="Address"
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:element name="Status"
type="xsd:unsignedByte"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GetServiceDescriptor">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Timeout"
type="ns:Timeout"/>
<xsd:element name="CallbackDestination"
type="xsd:string" minOccurs="0"/>
<xsd:element name="Address"
type="ns:Address" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GetServiceDescriptorResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
<xsd:element name="RequestIdentifier"
type="ns:RequestIdentifier" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ServiceDiscriptorEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="RequestIdentifier"
type="ns:RequestIdentifier"/>
<xsd:element name="Address"
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:element name="Status"
type="xsd:unsignedByte"/>
</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="Status"
type="xsd:unsignedByte"/>
<xsd:element
name="ServiceInformation" type="Q2:NodeServicesList"/>
<xsd:element name="Node"
type="ns:unsigned32Bit"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartGatewayDevice">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Request"
type="Q2:StartupAttributeInfo"/>
<xsd:element name="Timeout"
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="Status"
type="xsd:unsignedByte"/>
<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 name="Status"
type="xsd:unsignedByte"/>
<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="StartGatewayDeviceEventResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
</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:element name="Status"
type="xsd:unsignedByte"/>
</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="Status"
type="xsd:unsignedByte"/>
<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>
<xsd:element name="Status"
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 name="Status"
type="xsd:unsignedByte">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ListAddresses">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Address"
type="ns:Address"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ListAddressesResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="NumOfAddr"
type="ns:unsigned32Bit"/>
<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>
<xsd:element name="Timeout"
type="ns:Timeout"/>
<xsd:element name="CallbackDestination"
type="xsd:string" minOccurs="0"/>
<xsd:element name="DeviceAddress"
type="ns:Address" minOccurs="0"/>
<xsd:element name="RemoveChildren"
type="xsd:boolean" minOccurs="0"/>
<xsd:element name="Rejoin"
type="xsd:boolean" minOccurs="0"/>
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 name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="RequestIdentifier"
type="Q2:RequestIdentifier" maxOccurs="1" minOccurs="0"/>
<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 name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="RequestIdentifier"
type="Q2:RequestIdentifier" maxOccurs="1" minOccurs="0"/>
<xsd:element name="MgmtCommandStatus"
type="Q2:unsigned8Bit" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="GmoLeaveEventResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PermitJoin">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Timeout"
type="ns:Timeout"/>
<xsd:element name="CallbackDestination"
type="xsd:string" minOccurs="0"/>
<xsd:element name="DestinationAddress"
type="ns:Address" minOccurs="0"/>
<xsd:element name="DestinationAddressMode"
type="ns:unsigned32Bit" minOccurs="0"/>
<xsd:element name="PermitDuration"
type="Q2:unsigned8Bit"/>
<xsd:element name="TCSignificane"
type="xsd:boolean" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PermitJoinResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
<xsd:element name="RequestIdentifier"
type="Q2:RequestIdentifier" maxOccurs="1" minOccurs="0"/>
<xsd:element name="MgmtCommandStatus"
type="Q2:unsigned8Bit" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PermitJoinEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
<xsd:element name="RequestIdentifier"
type="Q2:RequestIdentifier" maxOccurs="1"/>
<xsd:element name="MgmtCommandStatus"
type="Q2:unsigned8Bit" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PermitJoinEventResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
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>
<!-- ZDP Functions -->
<xsd:element name="SendZDPCommand">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Timeout"
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 name="Status"
type="xsd:unsignedByte">
</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 name="Status"
type="xsd:unsignedByte"/>
<xsd:element
name="RequestIdentifier" type="Q2:RequestIdentifier" maxOccurs="1" minOccurs="0"/>
<xsd:element name="Message"
type="ns:ZDPMessage" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifyZDPEventResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- ZCL Functions -->
<xsd:element name="SendZCLCommand">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Timeout"
type="Q2:Timeout"/>
<xsd:element
name="CallbackDestination" type="xsd:string" maxOccurs="1" minOccurs="0"/>
<xsd:element name="Command"
type="Q2:ZCLCommand"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendZCLCommandResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
<xsd:element
name="RequestIdentifier" type="Q2:RequestIdentifier" maxOccurs="1" minOccurs="0"/>
<xsd:element name="Message"
type="Q2:ZCLMessage"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifyZCLEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Message"
type="Q2:ZCLMessage"/>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
<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:element name="Status"
type="xsd:unsignedByte"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- Application Support Sub Layer -->
<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:element name="Status"
type="xsd:unsignedByte"/>
</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="Status"
type="xsd:unsignedByte"/>
<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="Status"
type="xsd:unsignedByte"/>
<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:element name="Status"
type="xsd:unsignedByte"/>
</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="Status"
type="xsd:unsignedByte"/>
<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:element name="Status"
type="xsd:unsignedByte"/>
</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:element name="Status"
type="xsd:unsignedByte"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendAPSMessage">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Request"
type="Q2:APSMessage" maxOccurs="1" minOccurs="0"/>
<xsd:element name="Timeout"
type="Q2:Timeout"/>
<xsd:element
name="CallbackDestination" type="xsd:string" maxOccurs="1" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendAPSMessageResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
<xsd:element
name="RequestIdentifier" type="Q2:RequestIdentifier" maxOccurs="1" minOccurs="0"/>
<xsd:element name="ConfirmStatus"
type="Q2:unsigned8Bit"/>
<xsd:element name="TxTime"
type="Q2:unsigned32Bit" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifySendAPSMessageEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
<xsd:element
name="RequestIdentifier" type="Q2:RequestIdentifier" maxOccurs="1" minOccurs="0"/>
<xsd:element name="ConfirmStatus"
type="Q2:unsigned8Bit" minOccurs="0"/>
<xsd:element name="TxTime"
type="Q2:unsigned32Bit" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifySendAPSMessageEventResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
</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>
<xsd:element name="Message"
type="Q2:APSMessageEvent"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifyAPSMessageEventResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte"/>
</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:element name="Status"
type="xsd:unsignedByte"/>
</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:element name="Status"
type="xsd:unsignedByte"/>
</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:element name="Status"
type="xsd:unsignedByte"/>
</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="Status"
type="xsd:unsignedByte"/>
<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="Status"
type="xsd:unsignedByte"/>
<xsd:element name="BindingList"
type="Q2:BindingList" minOccurs="0"/>
<xsd:element name="BindingCount"
type="xsd:unsignedInt" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- InterPAN Interface -->
<xsd:element name="SendInterPANMessage">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Timeout"
type="ns:Timeout">
</xsd:element>
<xsd:element
name="CallbackDestination" type="xsd:string" minOccurs="0">
</xsd:element>
<xsd:element name="Message"
type="ns:InterPANMessage"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendInterPANMessageResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="ConfirmStatus"
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>
<xsd:element name="RequestIdentifier"
type="ns:RequestIdentifier"/>
<xsd:element name="Message"
type="ns:InterPANMessage"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifyInterPANMessageEventResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- Network Functions -->
<xsd:element name="FormNetwork">
<xsd:complexType>
<xsd:sequence>
<xsd:element
name="NetworkConfiguration" type="Q2:NetworkConfiguration">
</xsd:element>
<xsd:element name="Timeout"
type="ns:Timeout"/>
<xsd:element name="CallbackDestination"
type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="FormNetworkResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element
name="RequestIdentifier" type="Q2:RequestIdentifier" maxOccurs="1" minOccurs="0">
</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
<xsd:element name="NWKStatus"
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 name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element
name="RequestIdentifier" type="Q2:RequestIdentifier" maxOccurs="1">
</xsd:element>
<xsd:element name="NWKStatus"
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 name="Status"
type="xsd:unsignedByte">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartRouter">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Timeout"
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 name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="NWKStatus"
type="Q2:NetworkStatusCode" minOccurs="0">
</xsd:element>
<xsd:element name="RequestIdentifier"
type="ns:RequestIdentifier" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartRouterEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="NWKStatus"
type="Q2:NetworkStatusCode" minOccurs="0">
</xsd:element>
<xsd:element
name="RequestIdentifier" type="ns:RequestIdentifier"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="StartRouterEventResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</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
<xsd:element name="Timeout"
type="ns:Timeout">
</xsd:element>
<xsd:element name="Options"
type="ns:JoinConfiguration"/>
<xsd:element name="CallbackDestination"
type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="JoinResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="NWKStatus"
type="Q2:NetworkStatusCode" minOccurs="0">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="JoinEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="NWKStatus"
type="Q2:NetworkStatusCode" minOccurs="0">
</xsd:element>
<xsd:element name="RequestIdentifier"
type="ns:RequestIdentifier"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="JoinEventResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Leave">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Timeout"
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 name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="NWKStatus"
type="Q2:NetworkStatusCode" minOccurs="0">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="LeaveEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="NWKStatus"
type="Q2:NetworkStatusCode" minOccurs="0">
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:element name="RequestIdentifier"
type="ns:RequestIdentifier"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="LeaveEventResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="DiscoverNetworks">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Timeout"
type="Q2:Timeout"/>
<xsd:element name="CallbackDestination"
type="xsd:string" minOccurs="0">
</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 name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="RequestIdentifier"
type="Q2:RequestIdentifier" minOccurs="0">
</xsd:element>
<xsd:element name="NWKStatus"
type="Q2:NetworkStatusCode" minOccurs="0">
</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 name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element
name="RequestIdentifier" type="Q2:RequestIdentifier">
</xsd:element>
<xsd:element name="NWKStatus"
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 name="Status"
type="xsd:unsignedByte">
</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
<xsd:element name="Timeout"
type="Q2:Timeout"/>
<xsd:element name="CallbackDestination"
type="xsd:string" minOccurs="0">
</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 name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="RequestIdentifier"
type="Q2:RequestIdentifier" minOccurs="0">
</xsd:element>
<xsd:element name="NWKStatus"
type="Q2:NetworkStatusCode" minOccurs="0">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ResetEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element
name="RequestIdentifier" type="Q2:RequestIdentifier">
</xsd:element>
<xsd:element name="NWKStatus"
type="Q2:NetworkStatusCode" minOccurs="0">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ResetEventResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PerformEnergyScan">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Timeout"
type="Q2:Timeout"/>
<xsd:element name="CallbackDestination"
type="xsd:string" minOccurs="0">
</xsd:element>
<xsd:element name="ScanChannels"
type="Q2:unsigned32Bit">
</xsd:element>
<xsd:element name="ScanDuration"
type="Q2:unsigned8Bit">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PerformEnergyScanResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="RequestIdentifier"
type="Q2:RequestIdentifier" minOccurs="0">
</xsd:element>
<xsd:element name="NWKStatus"
type="Q2:NetworkStatusCode" minOccurs="0">
</xsd:element>
<xsd:element name="ScanChannels"
type="Q2:unsigned32Bit">
</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 name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="RequestIdentifier"
type="Q2:RequestIdentifier" minOccurs="0">
</xsd:element>
<xsd:element name="NWKStatus"
type="Q2:NetworkStatusCode">
</xsd:element>
<xsd:element name="ScanChannels"
type="Q2:unsigned32Bit">
</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 name="Status"
type="xsd:unsignedByte">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NetworkStatusEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="NWKStatus"
type="Q2:NetworkStatusCode" minOccurs="0">
</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 name="Status"
type="xsd:unsignedByte">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PerformRouteDiscovery">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Timeout"
type="Q2:Timeout"/>
<xsd:element name="CallbackDestination"
type="xsd:string" minOccurs="0">
</xsd:element>
<xsd:element name="Request"
type="Q2:RouteDiscoveryInfo">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PerformRouteDiscoveryResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="RequestIdentifier"
type="Q2:RequestIdentifier" minOccurs="0">
</xsd:element>
<xsd:element name="NWKStatus"
type="Q2:NetworkStatusCode" minOccurs="0">
</xsd:element>
<xsd:element name="NetworkStatusCode"
type="Q2:NetworkStatusCode" minOccurs="0">
</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 name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element
name="RequestIdentifier" type="Q2:RequestIdentifier">
</xsd:element>
<xsd:element name="NWKStatus"
type="Q2:NetworkStatusCode">
</xsd:element>
<xsd:element name="NetworkStatusCode"
type="Q2:NetworkStatusCode" minOccurs="0">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PerformRouteDiscoveryEventResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendNWKCommand">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Timeout"
type="ns:Timeout">
</xsd:element>
<xsd:element name="CallbackDestination"
type="xsd:string" minOccurs="0">
</xsd:element>
<xsd:element name="Message"
type="ns:NWKMessageEvent">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SendNWKCommandResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element name="Message"
type="ns:NWKMessageResult">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifyNWKMessageEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
<xsd:element
name="RequestIdentifier" type="Q2:RequestIdentifier" maxOccurs="1" minOccurs="0">
</xsd:element>
<xsd:element name="Message"
type="ns:NWKMessageEvent"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="NotifyNWKMessageEventResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Status"
type="xsd:unsignedByte">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</wsdl:types>
<!-- End of Type Declaration -->
<!-- Start of Message Declaration -->
<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
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
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">
<wsdl:part name="parameters"
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">
<wsdl:part name="parameters"
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>
<!-- InterPAN Message Declaration -->
<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">
<wsdl:part name="parameters"
element="tns:NotifyInterPANMessageEventResponse"/>
</wsdl:message>
<!-- End of Message Declaration -->
<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>
<!-- End of Port Type -->
<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>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="ZDPEvent" type="tns:zdpEvent">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="NotifyZDPEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/NotifyZDPEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="ZCLEvent" type="tns:zclEvent">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<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>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="APSEvent" type="tns:apsEvent">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="NotifyAPSMessageEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/NotifyAPSMessageEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="NotifySendAPSMessageEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/NotifySendAPSMessageEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="NWKEvent" type="tns:nwkEvent">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="FormNetworkEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/FormNetworkEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="StartRouterEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/StartRouterEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ResetEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ResetEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="LeaveEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/LeaveEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="JoinEvent">
<soap:operation soapAction="http://www.zigbee.org/zgd/JoinEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</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>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="DiscoverNetworksEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/DiscoverNetworksEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PerformEnergyScanEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/PerformEnergyScanEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="NetworkStatusEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/NetworkStatusEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PerformRouteDiscoveryEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/PerformRouteDiscoveryEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="ZCL" type="tns:zcl">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="SendZCLCommand">
<soap:operation
soapAction="http://www.zigbee.org/zgd/SendZCLCommand"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="APS" type="tns:aps">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="ConfigureNodeDescriptor">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ConfigureNodeDescriptor"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ConfigureUserDescriptor">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ConfigureUserDescriptor"/>
<wsdl:input>
<soap:body use="literal"/>
</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>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ConfigureEndpoint">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ConfigureEndpoint"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ClearEndpoint">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ClearEndpoint"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="SendAPSMessage">
<soap:operation
soapAction="http://www.zigbee.org/zgd/SendAPSMessage"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="AddGroup">
<soap:operation soapAction="http://www.zigbee.org/zgd/AddGroup"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="RemoveGroup">
<soap:operation
soapAction="http://www.zigbee.org/zgd/RemoveGroup"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="RemoveAllGroups">
<soap:operation
soapAction="http://www.zigbee.org/zgd/RemoveAllGroups"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GetGroupList">
<soap:operation
soapAction="http://www.zigbee.org/zgd/GetGroupList"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GetBindingList">
<soap:operation
soapAction="http://www.zigbee.org/zgd/GetBindingList"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</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>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GetNodePowerDescriptor">
<soap:operation
soapAction="http://www.zigbee.org/zgd/GetNodePowerDescriptor"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GetUserDescriptor">
<soap:operation
soapAction="http://www.zigbee.org/zgd/GetUserDescriptor"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="NWK" type="tns:nwk">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="SendNWKCommand">
<soap:operation
soapAction="http://www.zigbee.org/zgd/SendNWKCommand"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="FormNetwork">
<soap:operation
soapAction="http://www.zigbee.org/zgd/FormNetwork"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="StartRouter">
<soap:operation
soapAction="http://www.zigbee.org/zgd/StartRouter"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="Join">
<soap:operation soapAction="http://www.zigbee.org/zgd/Join"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="Leave">
<soap:operation soapAction="http://www.zigbee.org/zgd/Leave"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</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
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="Reset">
<soap:operation soapAction="http://www.zigbee.org/zgd/Reset"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PerformEnergyScan">
<soap:operation
soapAction="http://www.zigbee.org/zgd/PerformEnergyScan"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PerformRouteDiscovery">
<soap:operation
soapAction="http://www.zigbee.org/zgd/PerformRouteDiscovery"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="GMO" type="tns:gmo">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="GetVersion">
<soap:operation
soapAction="http://www.zigbee.org/zgd/GetVersion"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="CreateCallback">
<soap:operation
soapAction="http://www.zigbee.org/zgd/CreateCallback"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="Get">
<soap:operation soapAction="http://www.zigbee.org/zgd/Get"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="Set">
<soap:operation soapAction="http://www.zigbee.org/zgd/Set"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="DeleteCallback">
<soap:operation
soapAction="http://www.zigbee.org/zgd/DeleteCallback"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
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>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="UpdateTimeout">
<soap:operation
soapAction="http://www.zigbee.org/zgd/UpdateTimeout"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PollCallback">
<soap:operation
soapAction="http://www.zigbee.org/zgd/PollCallback"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="StartNodeDiscovery">
<soap:operation
soapAction="http://www.zigbee.org/zgd/StartNodeDiscovery"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ReadNodeCache">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ReadNodeCache"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="StartServiceDiscovery">
<soap:operation
soapAction="http://www.zigbee.org/zgd/StartServiceDiscovery"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GetServiceDescriptor">
<soap:operation
soapAction="http://www.zigbee.org/zgd/GetServiceDescriptor"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ReadServiceCache">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ReadServiceCache"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</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>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PollResults">
<soap:operation
soapAction="http://www.zigbee.org/zgd/PollResults"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ConfigureStartupAttributeSet">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ConfigureStartupAttributeSet"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ReadStartupAttributeSet">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ReadStartupAttributeSet"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="CreateAliasAddress">
<soap:operation
soapAction="http://www.zigbee.org/zgd/CreateAliasAddress"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="DeleteAliasAddress">
<soap:operation
soapAction="http://www.zigbee.org/zgd/DeleteAliasAddress"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ListAddresses">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ListAddresses"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GmoLeave">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ListAddresses"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PermitJoin">
<soap:operation
soapAction="http://www.zigbee.org/zgd/PermitJoin"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
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">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="StartGatewayDeviceEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/StartGatewayDeviceEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="NodeDiscoveryEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/NodeDiscoveryEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="NodeLeaveEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/NodeLeaveEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ServiceDiscoveryEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ServiceDiscoveryEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ServiceDiscriptorEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/ServiceDiscriptorEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="GmoLeaveEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/GmoLeaveEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="PermitJoinEvent">
<soap:operation
soapAction="http://www.zigbee.org/zgd/PermitJoinEvent"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:binding name="INTERPAN" type="tns:interPAN">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="SendInterPANMessage">
<soap:operation
soapAction="http://www.zigbee.org/zgd/SendInterPANMessage"/>
<wsdl:input>
<soap:body use="literal"/>
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>
<soap:body use="literal"/>
</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>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</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">
<soap:address location="http://www.zigbee.org"/>
</wsdl:port>
<wsdl:port name="aps" binding="tns:APS">
<soap:address location="http://www.zigbee.org"/>
</wsdl:port>
<wsdl:port name="nwk" binding="tns:NWK">
<soap:address location="http://www.zigbee.org"/>
</wsdl:port>
<wsdl:port name="interPAN" binding="tns:INTERPAN">
<soap:address location="http://www.zigbee.org"/>
</wsdl:port>
</wsdl:service>
<wsdl:service name="IPHAService">
<wsdl:port name="zdpEvent" binding="tns:ZDPEvent">
<soap:address location="http://www.zigbee.org/"/>
</wsdl:port>
<wsdl:port name="zclEvent" binding="tns:ZCLEvent">
<soap:address location="http://www.zigbee.org"/>
</wsdl:port>
<wsdl:port name="apsEvent" binding="tns:APSEvent">
<soap:address location="http://www.zigbee.org/"/>
</wsdl:port>
<wsdl:port name="nwkEvent" binding="tns:NWKEvent">
<soap:address location="http://www.zigbee.org/"/>
</wsdl:port>
<wsdl:port name="gmoEvent" binding="tns:GMOEvent">
<soap:address location="http://www.zigbee.org/"/>
</wsdl:port>
<wsdl:port name="interPANEvent" binding="tns:INTERPANEvent">
<soap:address location="http://www.zigbee.org/"/>
</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
<?xml version="1.0" encoding="UTF-8"?>
<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"/>
<!-- List of elements and complex types used in procedure commands -->
<!-- Gateway Management Profile (GMP) -->
<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>
<!-- ZigBee Device Profile (ZDP) -->
<element name="ZDPCommand" type="crt:ZDPCommand">
<annotation>
<documentation>
ZDPCommand element: sent with SendZDPCommand
</documentation>
</annotation>
</element>
<!-- ZigBee Cluster Library (ZCL) -->
<element name="ZCLMessage" type="crt:ZCLMessage">
<annotation>
<documentation>
ZCLMessage element: sent with SendZCLCommand
</documentation>
</annotation>
</element>
<!-- Application Support Sub-Layer -->
<element name="NodeDescriptor" type="crt:NodeDescriptor">
<annotation>
<documentation>
NodeDescriptor element: sent with
ConfigureNodeDescriptor
</documentation>
</annotation>
</element>
<element name="PowerDescriptor" type="crt:PowerDescriptor">
<annotation>
<documentation>
PowerDescriptor element: sent with
ConfigureNodePowerDescriptor
</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
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"
minOccurs="0" maxOccurs="1">
<annotation>
<documentation>
An optional message string that may clarify the
causes of an error condition.
</documentation>
</annotation>
</element>
</sequence>
</complexType>
<!-- Info element -->
<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"
minOccurs="1" maxOccurs="1">
<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"
minOccurs="0" maxOccurs="1">
<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"
minOccurs="0" maxOccurs="1">
<annotation>
<documentation>
The CallbackIdentifier of a previously registerd callback which
this event
must be notified.
</documentation>
</annotation>
</element>
<element name="NWKStatus" type="unsignedShort"
minOccurs="0" maxOccurs="1">
<annotation>
<documentation>
The NWKStatus result, typically returned
by many network layer procedures
</documentation>
</annotation>
</element>
<element name="Detail"
minOccurs="0" maxOccurs="1">
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>
<!-- Gateway Management Profile (GMP) -->
<element name="Version"
type="crt:Version"
minOccurs="0" maxOccurs="1">
<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"
minOccurs="0" maxOccurs="1">
<annotation>
<documentation>Message element: returned by
PollCallback</documentation>
</annotation>
</element>
<element name="CallbackIdentifier"
type="crt:CallbackIdentifier"
minOccurs="0" maxOccurs="1">
<annotation>
<documentation>
CallbackIdentifier element:
returned by CreateCallback
</documentation>
</annotation>
</element>
<element name="Callbacks"
type="crt:CallbackIdentifierList"
minOccurs="0" maxOccurs="1">
<annotation>
<documentation>
Callbacks element: returned by
ListCallbacks
</documentation>
</annotation>
</element>
<element name="Aliases"
type="crt:Aliases"
minOccurs="0" maxOccurs="1">
<annotation>
<documentation>
Aliases element: returned by
ListAddresses
</documentation>
</annotation>
</element>
<element name="WSNNode"
type="crt:WSNNode"
minOccurs="0" maxOccurs="1">
<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"
minOccurs="0" maxOccurs="1">
<annotation>
<documentation>
WSNNodes element: returned by
ReadNodeCache
</documentation>
</annotation>
</element>
<element name="NodeServices"
type="crt:NodeServices"
minOccurs="0" maxOccurs="1">
<annotation>
<documentation>
NodeServices element: sent with
ServiceDiscoveryEvent
</documentation>
</annotation>
</element>
<element name="ServiceDescriptor"
type="crt:ServiceDescriptor"
minOccurs="0" maxOccurs="1">
<annotation>
<documentation>
ServiceDescriptor element: sent
with ServiceDescriptorEvent
</documentation>
</annotation>
</element>
<element name="NodeServicesList"
type="crt:NodeServicesList"
minOccurs="0" maxOccurs="1">
<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>
<!-- ZigBee Device Profile (ZDP) -->
<element name="ZDPMessage"
type="crt:ZDPMessage"
minOccurs="0" maxOccurs="1">
<annotation>
<documentation>
ZDPMessage element: returned by SendZDPCommand
</documentation>
</annotation>
</element>
<!-- ZigBee Cluster Library (ZCL) -->
<element name="ZCLCommandResult"
type="crt:ZCLCommandResult"
minOccurs="0" maxOccurs="1">
<annotation>
<documentation>
ZCLCommandResult element: returned by SendZCLCommand
</documentation>
</annotation>
</element>
<element name="ZCLMessage"
type="crt:ZCLMessage"
minOccurs="0" maxOccurs="1">
<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
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
Page 271
General Description
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
22
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
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
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
Interface 2
17
18
Attribute
Interface endpoint
External Interface
Type
Attribute ID
0x0000
0x0001
Type
Uint8
Uint16
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
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.
8
Command
Interface Control
Link Control
9
10
11
12
13
14
15
Command Id
0x00
0x01
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
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
25
26
Page 274
SubCommand
Disable incoming connections
Enable incoming connections
Initiate outgoing connection
Terminate outgoing ocnnection
Value
0x00
0x01
0x02
0x03
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