forked from BroadbandForum/cwmp-data-models
-
Notifications
You must be signed in to change notification settings - Fork 0
/
cwmp-1-4.xsd
244 lines (221 loc) · 11 KB
/
cwmp-1-4.xsd
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
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
<?xml version="1.0" encoding="UTF-8"?>
<!--
CWMP XML Schema namespace Version 1.2 for CWMP Version 1.4
Copyright (c) 2006-2017, Broadband Forum
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the following
conditions are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials
provided with the distribution.
3. Neither the name of the copyright holder nor the names of its
contributors may be used to endorse or promote products
derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The above license is used as a license under copyright only.
Please reference the Forum IPR Policy for patent licensing terms
<https://www.broadband-forum.org/ipr-policy>.
Any moral rights which are necessary to exercise under the above
license grant are also deemed granted under this license.
Summary:
XML Schema for TR-069 CPE WAN Management Protocol (CWMP) Version
1.4 RPC requests and responses.
Editors:
John Blackford, Pace
Mike Digdon, Aptean
BroadbandHome™ Working Group Chairs:
John Blackford, Pace
Jason Walls, QACafe
Issue History:
* November 2006: cwmp-1-0.xsd
- extracted from TR-069 Amendment 1
* November 2007: cwmp-1-1.xsd
- extracted from TR-069 Amendment 2
* December 2010: cwmp-1-2.xsd
- extracted from TR-069 Amendment 3
* July 2011: cwmp-1-3.xsd
- extends namespace v1.2 and defines protocol v1.3
* November 2013: cwmp-1-4.xsd
- extends namespace v1.2 and defines protocol v1.4
Publication Date:
* January 8, 2014
-->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tns="urn:dslforum-org:cwmp-1-2"
targetNamespace="urn:dslforum-org:cwmp-1-2"
elementFormDefault="unqualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://schemas.xmlsoap.org/soap/envelope/"
schemaLocation="http://schemas.xmlsoap.org/soap/envelope/"/>
<xs:import namespace="http://schemas.xmlsoap.org/soap/encoding/"
schemaLocation="http://schemas.xmlsoap.org/soap/encoding/"/>
<xs:include schemaLocation="http://www.broadband-forum.org/cwmp/cwmp-1-3.xsd"/>
<!--
New ACS Fault Code Type (8006)
-->
<xs:redefine schemaLocation="http://www.broadband-forum.org/cwmp/cwmp-1-3.xsd">
<xs:simpleType name="ACSFaultCodeType">
<xs:restriction base="tns:ACSFaultCodeType">
<xs:annotation>
<xs:documentation>
ACS Fault Codes from 8000 to 8006
* 8000 - Method not supported
* 8001 - Request denied (no reason specified)
* 8002 - Internal error
* 8003 - Invalid arguments
* 8004 - Resources exceeded
* 8005 - Retry request
* 8006 - ACS version incompatible with CPE
</xs:documentation>
</xs:annotation>
</xs:restriction>
</xs:simpleType>
</xs:redefine>
<!--
New Event Code Type (13 WAKEUP)
-->
<xs:redefine schemaLocation="http://www.broadband-forum.org/cwmp/cwmp-1-3.xsd">
<xs:simpleType name="EventCodeType">
<xs:restriction base="tns:EventCodeType">
<xs:annotation>
<xs:documentation>
This pattern allows the following Event Codes:
* 0 BOOTSTRAP
* 1 BOOT
* 2 PERIODIC
* 3 SCHEDULED
* 4 VALUE CHANGE
* 5 KICKED
* 6 CONNECTION REQUEST
* 7 TRANSFER COMPLETE
* 8 DIAGNOSTICS COMPLETE
* 9 REQUEST DOWNLOAD
* 10 AUTONOMOUS TRANSFER COMPLETE
* 11 DU STATE CHANGE COMPLETE
* 12 AUTONOMOUS DU STATE CHANGE COMPLETE
* 13 WAKEUP
</xs:documentation>
</xs:annotation>
</xs:restriction>
</xs:simpleType>
</xs:redefine>
<!--
Update of enumeration documentation for Parameter Attribute Notification Types
for the new Lightweight Notification mechanism
-->
<xs:redefine schemaLocation="http://www.broadband-forum.org/cwmp/cwmp-1-3.xsd">
<xs:simpleType name="ParameterAttributeNotificationValueType">
<xs:restriction base="tns:ParameterAttributeNotificationValueType">
<xs:annotation>
<xs:documentation>
Parameter Attribute Notification Values (from 0 to 6)
* 0 - Notification off. The CPE need not inform the ACS of a change to the specified parameter(s)
* 1 - Passive notification. Whenever the specified parameter value changes, the CPE MUST include the new value in the ParameterList in the Inform message that is sent the next time a session is established to the ACS
* 2 - Active notification. Whenever the specified parameter value changes, the CPE MUST initiate a session to the ACS, and include the new value in the ParameterList in the associated Inform message
* 3 - Passive lightweight notification. Whenever the specified parameter value changes, the CPE MUST include the new value in the ParameterList in the next Lightweight Notification message that is sent to the ACS
* 4 - Passive notification with passive lightweight notification. This combines the requirements of the values 1 (Passive notification) and 3 (Passive lightweight notification). The two mechanisms operate independently
* 5 - Active lightweight notification. Whenever the specified parameter value changes, the CPE MUST include the new value in the ParameterList in the associated Lightweight Notification message
* 6 - Passive notification with active lightweight notification. This combines the requirements of the values 1 (Passive notification) and 5 (Active lightweight notification). The two mechanisms operate independently
</xs:documentation>
</xs:annotation>
<xs:enumeration value="0">
<xs:annotation>
<xs:documentation>Notification off. The CPE need not inform the ACS of a change to the specified parameter(s)</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="1">
<xs:annotation>
<xs:documentation>Passive notification. Whenever the specified parameter value changes, the CPE MUST include the new value in the ParameterList in the Inform message that is sent the next time a session is established to the ACS</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="2">
<xs:annotation>
<xs:documentation>Active notification. Whenever the specified parameter value changes, the CPE MUST initiate a session to the ACS, and include the new value in the ParameterList in the associated Inform message</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="3">
<xs:annotation>
<xs:documentation>Passive lightweight notification. Whenever the specified parameter value changes, the CPE MUST include the new value in the ParameterList in the next Lightweight Notification message that is sent to the ACS</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="4">
<xs:annotation>
<xs:documentation>Passive notification with passive lightweight notification. This combines the requirements of the values 1 (Passive notification) and 3 (Passive lightweight notification). The two mechanisms operate independently</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="5">
<xs:annotation>
<xs:documentation>Active lightweight notification. Whenever the specified parameter value changes, the CPE MUST include the new value in the ParameterList in the associated Lightweight Notification message</xs:documentation>
</xs:annotation>
</xs:enumeration>
<xs:enumeration value="6">
<xs:annotation>
<xs:documentation>Passive notification with active lightweight notification. This combines the requirements of the values 1 (Passive notification) and 5 (Active lightweight notification). The two mechanisms operate independently</xs:documentation>
</xs:annotation>
</xs:enumeration>
</xs:restriction>
</xs:simpleType>
</xs:redefine>
<!--
New SOAP Header Element (SupportedCWMPVersions)
-->
<xs:element name="SupportedCWMPVersions">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="soapenv:mustUnderstand" use="optional">
<xs:annotation>
<xs:documentation>
NOTE: implementations MUST use a value of 0 for the mustUnderstand
attribute.
This is typically done in the XSD via a 'fixed="0"' attribute, but
there are some problems with SOAP 1.1 that cause schema validation
issues.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<!--
New SOAP Header Element (UseCWMPVersion)
-->
<xs:element name="UseCWMPVersion">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="soapenv:mustUnderstand" use="required">
<xs:annotation>
<xs:documentation>
NOTE: implementations MUST use a value of 1 for the mustUnderstand
attribute.
This is typically done in the XSD via a 'fixed="1"' attribute, but
there are some problems with SOAP 1.1 that cause schema validation
issues.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>