TR 069 Conformance 1 0

Broadband Forum TR-069 (CWMP) CPE Conformance Test Suite
UNH-IOL TR-069 Consortium

Version 1.0 November 22, 2010
iol
Digitally signed by UNH-IOL Date: 2010.11.2 2 14:04:00 -05'00'
Abstract: This test suite contains test cases designed to exercise and validate CWMP enabled Customer Premises Equipment based on the normative requirements defined in Broadband Forum TR-069 Amendment 2.
TR-069 Consortium University of New Hampshire InterOperability Laboratory www.iol.unh.edu
121 Technology Drive, Suite 2 Durham, NH 03824 Phone: +1-603-862-0090 Fax: +1-603-862-4181
Contents
Contents ........................................................................................................................................................ 2 Introduction .................................................................................................................................................. 5 Overview ................................................................................................................................................... 5 Organization of Tests ................................................................................................................................. 5 Purpose ................................................................................................................................................. 5 Target .................................................................................................................................................... 5 References ............................................................................................................................................. 5 Test setup .............................................................................................................................................. 5 Normative Description .......................................................................................................................... 5 Procedure .............................................................................................................................................. 6 Test metrics ........................................................................................................................................... 6 Test Setup ...................................................................................................................................................... 7 General Test Setup .................................................................................................................................... 7 Test Cases ...................................................................................................................................................... 8 ACS Discovery using DHCP .................................................................................................................... 8 ACS Rediscovery using DHCP............................................................................................................... 10 DHCP Inform Retry to the DHCP server .............................................................................................. 11 Handling Null Terminated ACS URL obtained from DHCP Server........................................................ 12 Handling DNS server response ............................................................................................................ 13 ACS Modifies URL ................................................................................................................................ 15 Connection upon Initial Installation .................................................................................................... 16 Connection after Connection Request ................................................................................................ 18 Connection after PeriodicInformInterval ............................................................................................ 20 Connection Establishment using SSL/TLS............................................................................................ 22 Connection Request over SSL/TLS....................................................................................................... 23 Rejection of Invalid SSL Certificate ...................................................................................................... 24 Session Initiation and Termination...................................................................................................... 25 Persistent TCP Connection Across a Single CWMP session ................................................................. 28 2
2010 University of New Hampshire InterOperability Laboratory
Multiple TCP Connections Across a Single CWMP session.................................................................. 29 Use of Session Cookies Across Multiple Transactions in a Session ..................................................... 30 Session Retry ....................................................................................................................................... 31 SOAP Response in an HTTP Request ................................................................................................... 35 HTTP Redirection Test 302 Redirect ................................................................................................. 36 HTTP Redirection Test 307 Redirect ................................................................................................. 38 HTTP Redirection Multiple Redirections ......................................................................................... 40 HTTP Redirection SSL ....................................................................................................................... 41 HTTP Redirection Use of session cookies ......................................................................................... 42 HTTP No Pipelining ........................................................................................................................... 44 HTTP Authentication - Basic Authentication ....................................................................................... 45 HTTP Authentication - Digest Authentication ..................................................................................... 46 SOAP Envelope Format ....................................................................................................................... 47 SOAP Fault Format .............................................................................................................................. 49 SetParameterValues SOAP Fault Format ............................................................................................. 51 GetRPCMethods and Required RPCs................................................................................................... 54 GetParameterNames Complete Path ............................................................................................... 55 GetParameterNames Partial Path Next Level True ........................................................................ 56 GetParameterNames Partial Path Next Level False ....................................................................... 57 GetParameterNames Invalid Path .................................................................................................... 59 GetParameterNames Entire Object Model ...................................................................................... 60 GetParameterValues Simple Complete Path ................................................................................... 61 GetParameterValues Multiple Complete Paths ............................................................................... 62 GetParameterValues Partial Path .................................................................................................... 63 GetParameterValues Complete and Partial Paths ............................................................................ 64 GetParameterValues Entire Object Model ....................................................................................... 65 SetParameterValues Single Parameter ............................................................................................. 66 SetParameterValues Multiple Parameters ....................................................................................... 68 GetParameterAttributes Complete Path .......................................................................................... 70 GetParameterAttributes Multiple Complete Paths .......................................................................... 71 3
GetParameterAttributes Partial Path ............................................................................................... 72 GetParameterAttributes Complete and Partial Path ........................................................................ 73 SetParameterAttributes Active Notifications ................................................................................... 74 SetParameterAttributes Passive Notification Complete Path ...................................................... 75 SetParameterAttributes Passive Notification Partial Path ............................................................ 77 SetParameterAttributes Passive Notification Complete and Partial Path .................................... 79 SetParameterAttributes Disable Notification ................................................................................... 81 AddObject ........................................................................................................................................... 83 DeleteObject ....................................................................................................................................... 85 Reboot ................................................................................................................................................. 87 Download Test Basic Version Upgrade ............................................................................................. 88 Upload ................................................................................................................................................. 91 ScheduleInform Test ............................................................................................................................ 93 FactoryReset........................................................................................................................................ 94 CWMP Faults Basic RPC Faults ......................................................................................................... 95 CWMP Faults - SetParameterValues ................................................................................................... 96 CWMP Faults Download and Upload Failure ................................................................................... 99
4
Introduction
Overview
The University of New Hampshires InterOperability Laboratory (UNH-IOL) is an institution designed to improve the interoperability of standards based products by providing an environment where a product can be tested against other implementations of a standard. This suite of tests has been developed to help implementers determine the conformance of their CWMP enabled CPE to the normative requirements outlined in Broadband Forum Technical Report 069 (TR-069). Due to the limitations on the ability to test all normative requirements in the specification, successful completion of all tests in this test suite does not guarantee that the device under test is compliant with the appropriate specification or that it will interoperate in all environments or scenarios. However, successful completion of these tests should provide a reasonable level of confidence that the device under test will function well in most multi-vendor environments.
Organization of Tests
Each test contains an identification section that describes the test and provides cross-reference information. The discussion section covers background information and specifies why the test is to be performed. Tests are grouped in order to reduce setup time in the lab environment. Each test contains the following information: Purpose The purpose is a brief statement outlining what the test attempts to achieve. This also includes background information on why one needs to perform such a test to show that the device complies with the standard. Target The target section describes the type of DUT that is an appropriate subject for the test. References The references section lists standards and other documentation that might be helpful in understanding and evaluating the test and results. Test setup The setup section describes the configuration of the test environment. Small changes in the configuration should be included in the test procedure. Normative Description The normative description is a general discussion of the test and relevant section of the specification, including any assumptions made in the design or implementation of the test as well as known limitations. 5
Procedure The procedure section of the test description contains the step-by-step instructions for carrying out the test. Test metrics The test metrics section lists occurring events that can be examined by the tester to verify that the DUT is operating properly. When multiple values are possible for a specific event, this section provides a short discussion on how to interpret them. The determination of passing or failing a certain test is often based on the successful (or unsuccessful) detection of a certain predetermined event.
6
Test Setup
General Test Setup
4. DNS/File/ DHCP Servers
1. CPE
3. Internal Test Netowrk
4. CWMP Generator/ Analyzer
7
Test Cases
ACS Discovery using DHCP Purpose: This test is designed to verify that the DUT attempts to use DHCP to discover the ACS URL when the DUT has no value for the ManagementServer.URL Target: Any CWMP enabled CPE that implements DHCP discovery of the ACS URL. References: [1] [2] Broadband Forum TR-069 RFC 2132
Normative Description: According to Broadband Forum TR-069 [1], a CWMP enabled CPE must use DHCP to attempt to discover the ACS URL when the CPE has no value (empty or null) for the parameter ManagementServer.URL . A CPE identifies itself to the DHCP server as supporting this method by including the string dslforum.org (all lower case) anywhere in the Vendor Class Identifier ( DHCP option 60 ). The CPE may then use the values received from the DHCP server in the Vendor Specific Information ( DHCP option 43 )to set the URL of the ACS and the Provisioning Code. Test Setup: 1. Configure the DHCP server or simulator to include the ACS URL in its DHCP options. 2. Configure the DUT to have an empty or null value for the ManagementServer.URL parameter. 3. Connect the DUT, DHCP server or simulator, and CWMP analyzer to the network infrastructure. Procedure: 1. Allow the DUT to request an ACS URL using DHCP. 2. Respond to the DHCP request with a valid response to set the ACS URL. 3. Allow the DUT to use the value received from the DHCP server in the Vendor Specification Information ( DHCP option 43 ) to set the ManagementServer.URL 4. Allow the DUT to establish a CWMP session with the ACS specified by the URL. 5. Allow the DUT to terminate the session. Test Metrics: 1. The DUT attempts to discover the ACS URL via DHCP when its ManagementServer.URL parameter is blank. 8
2. The DUT establishes CWMP session with the ACS specified by the URL.
9
ACS Rediscovery using DHCP Purpose: This test is designed to verify that the DUT consistently utilizes DHCP to discover the ACS URL. Target: Any CWMP enabled CPE that implements DHCP discovery of the ACS URL. References: [1] [2] Broadband Forum TR-069 RFC 2131
Normative Description: According to Broadband Forum TR-069 [1] section 3.1, a CWMP enabled CPE must utilize the same method for acquiring an ACS URL that it was originally configured to use, regardless of the mechanism used to change the ACS URL at a later point. Test Setup: 1. Configure the DHCP server or simulator to include the ACS URL in its DHCP options. 2. Configure the DUT to have an empty or null value for the ManagementServer.URL parameter. 3. Connect the DUT, DHCP server or simulator, and CWMP analyzer to the network infrastructure. Procedure: 1. Allow the DUT to request an ACS URL through DHCP. 2. Respond to the DHCP request using the generator with a valid response to set the ACS URL. 3. Set the ACS URL through a manual mechanism. 4. Allow the DUT to attempt to communicate with the ACS at the new URL, without response. 5. Allow the DUT to attempt to rediscover the ACS URL via DHCP. Test Metrics: 1. The DUT attempts to rediscover the ACS URL via DHCP when it had previously set the ACS URL via DHCP and cannot communicate with the ACS.
10
DHCP Inform Retry to the DHCP server Purpose: This test is designed to verify that the DUT retries its DHCP INFORM message when it does not receive a reply from the DHCP server. Target: Any CWMP enabled CPE that implements DHCP discovery of the ACS URL. References: [1] [2] Broadband Forum TR-069 RFC 2131
Normative Description: According to Broadband Forum TR-069 [1] section 3.1, a CWMP enabled CPE must send a DHCP INFORM if it cannot communicate with the ACS indicated by the negotiated ACS URL value. Further, it must retry its DHCP INFORM message if it does not receive a DHCPACK from the DHCP server within a reasonable time. This requirement is in accordance with RFC 2131 [2]. Test Setup: 1. Configure the DHCP server or simulator to include the ACS URL in its DHCP options. 2. Configure the DUT to have an empty or null value for the ManagementServer.URL parameter. 3. Connect the DUT, DHCP server or simulator, and CWMP analyzer to the network infrastructure. Procedure: 1. Allow the DUT to request an ACS URL through DHCP. 2. Respond to the DHCP request with a valid response to set the ACS URL. 3. Allow the DUT to attempt to communicate with the CWMP analyzer, without response for 300 seconds. 4. Allow the DUT to send a DHCP INFORM, without response for 300 seconds. 5. Allow the DUT to resend the DHCP INFORM. Test Metrics: 1. The DUT sends an initial DHCP INFORM message when receiving no response from the CWMP generator after 300 seconds. 2. The DUT resends the DHCP INFORM message when it receives no response for the DHCP server after 300 seconds.
11
Handling Null Terminated ACS URL obtained from DHCP Server Purpose: This test is designed to verify that the DUT correctly interprets and acts upon the ACS URL used. Target: Any CWMP enabled CPE that implements DHCP discovery of the ACS URL. References: [1] [2] Broadband Forum TR-069 RFC 2131
Normative Description: According to Broadband Forum TR-069 [1] section 3.1, a CWMP enabled CPE must handle a null terminated ACS URL by accepting the URL as valid, without including the null terminating character in the URL. Test Setup: 1. Configure the DHCP server or simulator to include the ACS URL in its DHCP options. 2. Configure the DUT to have an empty or null value for the ManagementServer.URL parameter. 3. Connect the DUT, DHCP server or simulator, and CWMP analyzer to the network infrastructure. Procedure: 1. Allow the DUT to request an ACS URL through DHCP. 2. Respond to the DHCP request with a valid response to set the ACS URL with a URL that is nullterminated. 3. Verify that the DUT has correctly interpreted the URL. 4. Allow the DUT to attempt to communicate with the ACS at the new URL. Test Metrics: 1. The DUT interprets the ACS URL without the null-termination. 2. The DUT attempts a secure connection to the CWMP analyzer.
12
Handling DNS server response Purpose: This test is designed to verify that the DUT does not cache the DNS server response beyond the duration of time to live (TTL) returned by DNS server. Target: The type of CWMP enabled equipment valid for the test. References: [1] [2] Broadband Forum TR-069 DNS RFC 1034
Normative Description: According to Broadband Forum TR-069 [1], the CPE must not cache the DNS server response beyond the duration of time to live (TTL) returned by DNS server unless it cannot contact the DNS server for an update. This behavior is required by DNS RFC 1034 and provides an opportunity for the DNS Server to update stale data. Test Setup: 1. Configure the DHCP server or simulator to include the ACS URL in its DHCP options. 2. Configure the DUT to have an empty or null value for the ManagementServer.URL parameter. 3. Connect the DUT, DNS server, DHCP server, and CWMP analyzer to the network infrastructure. Procedure: 1. Allow the DUT to request an ACS URL through DHCP. 2. Respond to the DHCP request using the generator with a valid response to set the ACS URL. 3. Allow the DUT to contact the DNS server to resolve the ACS URL. 6. Set a new ACS URL through a manual mechanism. 7. Allow the DUT to attempt to communicate with the ACS at the new URL, without response. 8. Allow the DUT to attempt to rediscover the ACS URL via DHCP after the TTL specified in the DNS response has expired. 9. Respond to the rediscover request with a valid response to set the ACS URL. 10. Allow the DUT to contact the DNS server again to resolve the ACS URL. 11. Allow the DUT to establish a CWMP session with the ACS.
13
Test Metrics: 1. The DUT contacts the DNS server again to resolve the ACS URL without caching the previous response from the DNS server.
14
ACS Modifies URL Purpose: This test is designed to verify that the DUT accepts, interprets, and utilizes a new ACS URL set by the ACS via CWMP. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], once the CPE has established a connection to the ACS, the ACS may at any time modify the ACS address Parameter stored within the CPE. Once modified, the CPE must use the modified address for all subsequent connections to the ACS. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Configure an alternate instance or ACS URL on the CWMP analyzer. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a SetParameterValues RPC on the DUT using the CWMP generator, setting the value of the Management.URL parameter to the value of the alternate URL provided in the test setup. 3. Allow the DUT to attempt to communicate with the CWMP analyzer at the new URL. Test Metrics: 1. The DUT accepts, interprets and utilizes the new ACS URL.
15
Connection upon Initial Installation Purpose: This test is designed to verify that the DUT attempts to establish a connection with the ACS upon installation into the network. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], the CPE MUST establish connection to ACS the first time it is connected to the access network on initial installation. All CWMP sessions begin with the use of the Inform RPC. Each Inform RPC contains event codes in its arguments that indicate the event which caused the session to be initiated. In this case, the behavior is indicated by the event code 0 BOOTSTRAP. As this is presumably the first time the CPE is contacting a particular ACS, the 0 BOOTSTRAP event is the only event that may be included in the Inform, unless further events have occurred after an unsuccessful attempt to contact the ACS (that is, if the Session Retry count is greater than 0). This test verifies that the DUT attempts to establish a connection with the ACS upon installation into the network, that it uses the Inform RPC with the correct event codes, and that all CWMP messages in the process are valid. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Stimulate the DUT to send a CWMP Inform message to the CWMP analyzer as if it was contacting the ACS for the first time, such as by changing the ACS URL locally. 2. Respond to the Inform Request with an InformResponse. 3. Allow the DUT to successfully terminate the session. 4. Validate all CWMP messages. Test Metrics: 1. The DUT attempts to establish a session by sending an Inform message. 16
2. The Inform RPC arguments contain the 0 BOOTSTRAP event code. 3. The DUTs CWMP messages are valid. 4. The DUT successfully terminates the session.
17
Connection after Connection Request Purpose: This test is designed to verify that the DUT attempts to establish a connection with the ACS upon receiving a valid connection request from the ACS. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], the CPE MUST establish connection to the ACS after a valid connection request is received from an ACS. This is differentiated from a CPE that is connecting to an ACS in all previous tests. A connection request is an empty HTTP 1.1 GET to a URL predetermined by the CPE. This GET must be authenticated using digest or certificate based authentication. Password information can be pre-configured on the CPE or set by the ACS upon initial communication. All CWMP sessions begin with the use of the Inform RPC. Each Inform RPC contains event codes in its arguments that indicate the event which caused the session to be initiated. In this case, the behavior is indicated by the event code 6 CONNECTION REQUEST. Test Setup: 1. Configure the DUT with a connection request URL, connection request username, and connection request password. 2. Configure the CWMP analyzer to use the preconfigured URL, username, and password for connection requests. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Send a valid Connection RPC on the DUT. 2. Allow the DUT to authenticate the connection request. 3. Allow the DUT to initiate a session with the CWMP analyzer with successful Inform exchanges. 4. Allow the DUT to successfully terminate the session. 5. Validate all CWMP messages. Test Metrics: 1. The DUT uses digest authentication to authenticate the connection request. 18
2. The HTTP response from the DUT contains the 200 (OK) or 204 (No Content) status code. 3. The HTTP response is sent before the DUT attempts to establish the CWMP session. 4. The length of the HTTP response body is zero. 5. The DUT successfully establishes a session with the ACS by sending an Inform Message with an event code of 6 CONNECTION REQUEST. 6. The DUTs CWMP messages are valid. 7. The DUT successfully terminates the session.
19
Connection after PeriodicInformInterval Purpose: This test is designed to verify that the CPE attempts to establish a connection with the ACS after a time period equal to PeriodicInformInterval. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], the CPE MUST establish connection to the ACS after PeriodicInformInterval (example, after every 60 seconds). This is differentiated from a CPE connecting to an ACS for the first time, or a CPE connecting to the ACS after reboot. All CWMP sessions begin with the use of the Inform RPC. Each Inform RPC contains event codes in its arguments that indicate the event which caused the session to be initiated. In this case, the behavior is indicated by the event code 2 PERIODIC. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose a short value for the PeriodicInformInterval, between 60 and 300 seconds. Configure the DUT to use this value for PeriodicInformInterval. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Allow the session to terminate successfully. 3. Wait for the PeriodicInformInterval determined in test setup step 2. 4. Allow the DUT to initiate a session with the CWMP analyzer with successful Inform exchanges. 5. Allow the session to terminate successfully. 6. After the period determined in test setup step 2 has expired, allow the DUT initiate a new session. 7. Respond to the Inform RPC with an appropriate InformResponse. 8. Allow the DUT to successfully terminate the session. 20
9. Validate all CWMP messages. Test Metrics: 1. The DUT attempts to re-establish a CWMP session with the CWMP analyzer after the predetermined PeriodicInformInterval by sending an Inform message with an event code of 2 PERIODIC. 2. The DUTs CWMP messages are valid. 3. The DUT successfully terminates the session.
21
Connection Establishment using SSL/TLS Purpose: This test is designed to verify that the CPE is able to establish a connection with the ACS using SSL or TLS. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1] section 3.3, a CPE must support SSL, TLS, or both, in order to facilitate secure communication. In addition, if at any time the ACS URL is specified with an https prefix, the CPE must attempt to establish a connection utilizing SSL/TLS. This test utilizes this second required functionality to stimulate the DUT to attempt a connection using SSL/TLS. This is included in the test metrics. Test Setup: 1. Configure the CWMP analyzer to use SSL/TLS. 2. Configure the DUT to use the HTTPS URL of the analyzer. 3. Configure the DUT with a pre-determined username and password for authentication. 4. Generate and install on the DUT a valid certificate for use in authentication with the CWMP analyzer. 5. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Stimulate the DUT to send a CWMP Inform message to the CWMP analyzer. 2. Respond to the Inform Request with an InformResponse. 3. Allow the DUT to successfully terminate the session. 4. Validate all CWMP messages. Test Metrics: 1. The DUT attempts to establish a session by sending an Inform message. 2. The DUTs CWMP messages are valid. 3. The DUT successfully terminates the session. 22
Connection Request over SSL/TLS Purpose: This test is designed to verify that the CPE is able to authenticate a Connection Request from the ACS over SSL/TLS. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], a CPE MAY use certificate based authentication to validate Connection Requests from the ACS. Test Setup: 1. Configure the CWMP analyzer to use SSL/TLS for Connection Requests. 2. Configure the DUT and CWMP analyzer with a pre-determined username and password for authentication. 3. Generate and install on the CWMP analyzer a valid certificate for use in authentication with the CPE. 4. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Send a Connection RPC on the DUT over https. 2. Allow the DUT to authenticate the Connection Request. 3. Allow the DUT to initiate a session with the CWMP analyzer with successful Inform exchanges. 4. Allow the DUT to successfully terminate the session. 5. Validate all CWMP messages. Test Metrics: 1. The DUT authenticates the Connection Request. 2. The DUT initiates a CWMP session based on the Connection Request. 3. The DUTs CWMP messages are valid. 4. The DUT successfully terminates the session.
23
Rejection of Invalid SSL Certificate Purpose: This test is designed to verify that the CPE does not authenticate a Connection Request from the ACS when the SSL certificate is invalid. Target: Any CWMP enabled CPE that communicates directly with the ACS and supports certificate authentication of Connection Requests. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], a CPE MAY use certificate based authentication to validate Connection Requests from the ACS. If the DUT implements this functionality, it must not validate Connection Requests from the ACS when the certificate is invalid. Test Setup: 1. Configure the CWMP analyzer to use SSL/TLS. 2. Configure the DUT to use the HTTPS URL of the analyzer. 3. Configure the DUT with a pre-determined username and password for authentication. 4. Install mismatched certificates in the DUT and CWMP analyzer. 5. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Send a Connection RPC on the DUT over https. 2. Allow the DUT to reject the Connection Request from the CWMP analyzer. Test Metrics: 1. The DUT rejects the Connection Request from the CWMP analyzer and does not attempt to establish a session.
24
Session Initiation and Termination Purpose: This test is designed to verify that the CPE is able to initiate and terminate a session properly. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069[1], once a connection between a CPE and an ACS is established, the CPE initiates a session by sending an initial Inform RPC on the ACS in an HTTP POST message. If and only if the CPE receives a successful Inform response to the Inform Request, the CPE considers the session to have been successfully initiated. Once initiated, the CPE must terminate the transaction session only when all of the following conditions are met: The ACS has no further requests to send the CPE. The CPE concludes this if and only if the most recent HTTP response from the ACS was empty. The CPE has no further requests to send to the ACS and the CPE has issued an empty HTTP POST to the ACS while HoldRequests is false (which indicates to the ACS that the CPE has no further requests for the remainder of the session). As defined in Table 6, if this condition has not been met but the CPE has no further requests or responses, it MUST send an empty HTTP POST, which will then fulfill this condition. The CPE has received all outstanding response messages from the ACS. The CPE has sent all outstanding response messages to the ACS resulting from prior requests.
Figure below is an example of a session.
25
Test Setup: 1. Configure the CPE to use the ACS URL set on the CWMP analyzer. 2. Connect the CPE, and CWMP analyzer to the network infrastructure.
Procedure: 1. Stimulate the CPE to initiate a CWMP session with the CWMP analyzer. 2. Reply with a successful Inform Response. 3. Allow the CPE to respond with an empty HTTP POST. 4. Make a valid RPC RPC on the CPE. 5. Allow the CPE to respond with a valid response to the RPC request. 6. Verify if the CPE used the existing TCP connection. 7. Respond with an empty HTTP POST. 8. Allow the CPE to close the connection. 26
Test Metrics: 1. The CPE does not close existing TCP connection when replying to the RPC request. 2. The CPE closes existing TCP connection after receiving empty HTTP POST from the CWMP Analyzer.
27
Persistent TCP Connection Across a Single CWMP session Purpose: The purpose of this test is to verify that the ACS and CPE can maintain a persistent TCP connection across multiple CWMP sessions. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069[1], when a CPE receives an authentication challenge from ACS, the CPE must send the next HTTP request (including the Authorization HTTP header) in the same TCP connection. The authentication challenge from the ACS must not have Connection:close in the HTTP header. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer. 2. Reply with an Authentication Challenge. 3. Allow the DUT to issue an Inform RPC to the ACS again (with the Authentication HTTP header) in order to establish a CWMP session. 4. Respond to the Inform RPC with a successful InformResponse. 5. Allow the DUT to terminate the session.
Test Metrics: 1. The DUT must not close its existing TCP connection and must send the second HTTP request (with the Authentication header) in the same TCP connection.
28
Multiple TCP Connections Across a Single CWMP session Purpose: This test is designed to verify that ACS and CPE can maintain multiple TCP connections over a single CWMP session. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069[1], for a sequence of transactions forming a single session, a CPE should maintain a TCP connection that persists throughout the duration of the session. However, if the TCP connection is cleanly closed after an HTTP request/response round trip, and if the session has not otherwise terminated (either successfully or unsuccessfully) at the time of the last HTTP response, the CPE MUST continue the session by sending the next HTTP request in a new TCP connection. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer. 2. Reply with an Authentication Challenge containing Connection:close in its header. 3. Allow the DUT to close its existing TCP connection. 4. Allow the DUT to issue an Inform RPC to the ACS again ( with the Authentication HTTP header) in order to establish a CWMP session. 5. Respond to the Inform RPC with a successful InformResponse. 6. Allow the DUT to terminate the session. Test Metrics: 1. The DUT closes its existing TCP connection and sends the second HTTP request (with the Authentication header) in a new TCP connection.
29
Use of Session Cookies Across Multiple Transactions in a Session Purpose: This test is designed to verify that the CPE can successfully interact using cookies across multiple CWMP sessions. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069[1], a CPE must support the use of cookies including the return of the cookie value in each subsequent HTTP POST, with the exception that a CPE need not support storage of cookies beyond the duration of a session. The CPE must support the compatibility requirements of section 9.1 of [7]. The CPE must support the use of multiple cookies by the ACS, and must make available at least 512 bytes for storage of cookies. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Configure the CWMP analyzer to use session cookies. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer. 2. Set the HTTP cookie in the HTTP response. 3. Allow the DUT to send an empty HTTP POST or an Inform RPC to the CWMP analyzer. 4. Analyze the HTTP message from the DUT to check if it is using the cookie sent in the POST. 5. Allow the DUT to terminate the session. Test Metrics: 1. The DUT returns the cookie value in each subsequent HTTP POST after the cookie has been set.
30
Session Retry Purpose: This test is designed to verify that the DUT retries a failed session with the ACS. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069[1], a CPE must retry failed sessions to attempt to redeliver events that it has previously failed to deliver and to allow the ACS to make additional requests in a timely fashion. The CPE MUST keep track of the number of times it has attempted to retry a failed session. If the CPE fails to establish a session, this might be because the CPE supports CPE WAN Management Protocol v1.1 (or later) and the ACS supports only v1.0. If this situation is suspected, the CPE MUST revert to v1.0 when retrying the failed session. A CPE MUST retry a failed session after waiting for an interval of time specified in the following Table or when a new event occurs, whichever comes first. The CPE MUST choose the wait interval by randomly selecting a number of seconds from a range given by the post-reboot session retry count. Beginning with the tenth post-reboot session retry attempt, the CPE MUST choose from a range between 2560 and 5120 seconds. The CPE MUST continue to retry a failed session until it is successfully terminated. Once a session terminates successfully, the CPE MUST reset the session retry count to zero and no longer applies the session retry policy to determine when to initiate the next session. This test case tests three different parts: 1. The CPE receives an HTTP layer fault from the ACS notifying it to revert back to CWMP v 1.0. It retries session with the ACS by reverting back to v1.0 when retrying the failed session. 2. The CPE receives an HTTP layer fault from the ACS. It retries the session. 3. The CPE receives a SOAP layer fault from the ACS. It retries the session.
31
Test Setup: Part A: Revert back to previous CWMP version 1. Configure the CPE to use the ACS URL set on the CWMP analyzer. 2. Configure the CWMP Analyzer to use a CWMP version earlier than that of the DUT. If the DUT supports a later CWMP version, configure it to use this version. If it does not, this section of the test can be skipped. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Part B: Session Retry on HTTP Fault and Part C: Session Retry on SOAP Fault 1. Configure the CPE to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure.
Procedure: Part A: Revert back to CWMP v1.0 1. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer. 2. Instruct the CWMP Analyzer to respond with an HTTP response with status code of 400 (Bad Request) instead of 200 OK. 3. Allow the DUT to terminate the session. 4. Allow the DUT to retry the session in accordance to the session retry policy by sending an Inform message after the designated wait period, and with CWMP version set to an earlier version in the SOAP Envelope. 5. Respond to the Inform RPC with a successful InformResponse. 6. Allow the DUT to successfully terminate the connection. 32
Part B: Session Retry on HTTP Fault 1. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer. 2. Respond with an HTTP response with status code of 400 (Bad Request) instead of 200 OK. 3. Allow the DUT to terminate the session. 4. Allow the DUT to retry the session in accordance to the session retry policy by sending an Inform message after the designated wait period. 5. Respond to the Inform RPC with a successful InformResponse. 6. Allow the DUT to successfully terminate the connection.
Part C: Session Retry on SOAP Fault 1. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer. 2. Respond with an HTTP response with a SOAP fault response with fault code other than 8005 (Retry Request). 3. Allow the DUT to terminate the session. 4. Allow the DUT to retry the session in accordance to the session retry policy by sending an Inform message after the designated wait period. 5. Respond to the Inform RPC with a successful InformResponse. 6. Allow the DUT to successfully terminate the connection.
Test Metrics: Part A: Revert back to CWMP v1.0 1. The DUT is capable of successfully handling the HTTP error. 2. The DUT retries the session within the time window of the session retry, and uses CWMP v 1.0 3. The DUT increments the session retry counter in the Inform call. Part B: Session Retry on HTTP Fault Code 1. The DUT is capable of successfully handling the HTTP error. 2. The DUT retries the session within the time window of the session retry. 3. The DUT increments the session retry counter in the Inform call. Part C: Session Retry on SOAP Fault Code 33
1. The DUT is capable of successfully handling the SOAP Fault Code. 2. The DUT retries the session within the time window of the session retry. 3. The DUT increments the session retry counter in the Inform call.
34
SOAP Response in an HTTP Request Purpose: This test is designed to verify that the SOAP Response is encoded properly in an HTTP Request Message. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069[1], when there is a SOAP response in an HTTP Request, or when there is a SOAP Fault response in an HTTP Request, the SOAPAction header in the HTTP Request must have no value, indicating that this header provides no information as to the intent of the message. That is, it must appear as follows: SOAPAction: In addition to that, when an HTTP Request contains a SOAP Envelope, the HTTP Content-Type header must have a type/subtype of text/xml Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer. 2. Instruct the ACS to issue a valid RPC RPC on the DUT. 3. Allow the DUT to respond to the RPC request. 4. Analyze the HTTP POST message containing the SOAP response. Test Metrics: 1. The HTTP POST message has an empty SOAPAction header, and the HTTP Content-type header must have a type/subtype of text/xml.
35
HTTP Redirection Test 302 Redirect Purpose: This test is designed to verify that the CPE supports the use of HTTP redirection by the ACS using the 302 (Found) status code. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], a CPE must support the use of HTTP redirection by the ACS. In doing so, the CPE must support the 302(Found) HTTP status code. In case of redirection, the CPE must attempt to continue the session using the URL provided in the HTTP redirect response. The CPE must resend the HTTP POST that resulted in the redirect response to the ACS at the redirected URL, and the CPE must then attempt to proceed with the session exactly as if no redirection had occurred. The redirected URL must not be saved by the CPE (i.e. as the value of the IGD.ManagementServer.URL) for use in any subsequent session or any subsequent retries of the session. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. If the CWMP analyzer is capable of supporting multiple ACS URLs, configure an alternate ACS URL on the CWMP analyzer. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer. 2. Issue an HTTP response with a 302(Found) Status Code and the location of the new URL. 3. Allow the DUT to issue the same HTTP POST message to the new URL. 4. Using the new URL at the CWMP analyzer, reply back with an Inform Response. 5. Issue a GetParameterValue RPC on InternetGatewayDevice.ManagementServer.URL to the DUT. 6. Allow the DUT to respond with a GetParameterValueResponse. 7. Analyze the response. The value of the parameter should be the old URL before redirection, and not the new URL. 8. Allow the DUT to close the connection. Test Metrics: 1. The DUT properly resends the HTTP POST to the redirected URL. 36
2. The GetParameterValueResponse includes URL of the old ACS.
37
HTTP Redirection Test 307 Redirect Purpose: This test is designed to verify that the CPE supports the use of HTTP redirection by the ACS using the 307 (Temporary Redirect) status code. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], a CPE must support the use of HTTP redirection by the ACS. In doing so, the CPE must support the 307(Temporary) HTTP status code. In case of redirection, the CPE must attempt to continue the session using the URL provided in the HTTP redirect response. The CPE must resend the HTTP POST that resulted in the redirect response to the ACS at the redirected URL, and the CPE must then attempt to proceed with the session exactly as if no redirection had occurred. The redirected URL must not be saved by the CPE (i.e. as the value of the IGD.ManagementServer.URL) for use in any subsequent session or any subsequent retries of the session. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. If the CWMP analyzer is capable of supporting multiple ACS URLs, configure an alternate ACS URL on the CWMP analyzer. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer.Issue an HTTP response with a 307(Temporary Redirect) Status Code and the location of the new URL. 2. Allow the DUT to issue the same HTTP POST message to the new URL. 3. Using the new URL at the CWMP analyzer, reply back with an Inform Response. 4. Issue a GetParameterValue RPC on InternetGatewayDevice.ManagementServer.URL to the DUT. 5. Allow the DUT to respond with a GetParameterValueResponse. 6. Analyze the response. The value of the parameter should be the old URL before redirection, and not the new URL. 7. Allow the DUT to close the connection. Test Metrics: 1. The DUT properly resends the HTTP POST to the redirected URL. 38
2. The GetParameterValueResponse includes URL of the old ACS.
39
HTTP Redirection Multiple Redirections Purpose: This test is designed to verify that the CPE allows up to 5 consecutive redirections. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], a CPE must allow up to 5 consecutive redirections. If the CPE is redirected more than 5 times consecutively, it may consider the session unsuccessfully terminated. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. If the CWMP analyzer is capable of supporting multiple ACS URLs, configure an alternate ACS URL on the CWMP analyzer. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer.
2. Issue an HTTP response with a 307 (Temporary Redirect) Status Code and the location of the new URL. 3. Allow the DUT to issue the same HTTP POST message to the new URL. 4. Issue an HTTP response with a 307 (Temporary Redirect) Status Code and the location of the old URL again. 5. Repeat the back and forth process for two more times, so that the redirection count now is 4. 6. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer.
7. Issue an HTTP response with a 307 (Temporary Redirect) Status Code and the location of the new URL. 8. Using the new URL at the CWMP analyzer, reply back with an Inform Response. 9. Allow the DUT to close the connection. Test Metrics: 1. The DUT honors each redirection request and sends an HTTP post to the redirected URL. 2. The DUT successfully terminates the connection. 40
HTTP Redirection SSL Purpose: This test is designed to verify that the CPE supports the use of HTTP redirection by the ACS to an HTTPS URL. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], if an HTTPS URL is provided in the HTTP redirection by the ACS, the CPE must use SSL/TLS as transport mechanism, and establish connection with the HTTPS URL. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. If the CWMP analyzer is capable of supporting multiple ACS URLs, configure an alternate https ACS URL on the CWMP analyzer. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer. 2. Issue an HTTP response with a 307 (Temporary Redirect) Status Code and the location of the new HTTPS URL. 3. Allow the DUT to establish an SSL connection with the ACS represented by the new URL. 4. Allow the DUT to issue the same HTTP POST message to the new URL. 5. Using the new URL at the CWMP Analzyer, reply back with an Inform Response. 6. Issue a GetParameterValue RPC on InternetGatewayDevice.ManagementServer.URL to the DUT. 7. Allow the DUT to respond with a GetParameterValueResponse. 8. Analyze the response. The value of the parameter should be the old URL before redirection, and not the new URL. Test Metrics: 1. The DUT establishes SSL connection with the new ACS represented by the new URL. 2. The DUT properly resends the HTTP POST to the redirected URL. 3. The GetParameterValueResponse includes URL of the old ACS. 41
HTTP Redirection Use of session cookies Purpose: This test is designed to verify that the CPE can successfully communicate using cookies even after HTTP redirection. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], a CPE must include all cookies associated with the session in subsequent HTTP requests to the redirected ACS. The CPE must consider a redirect from an ACS to be a verifiable transaction and thus it must send cookies to the redirected ACS without performing domain validation of each cookie. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. If the CWMP analyzer is capable of supporting multiple ACS URLs, configure an alternate ACS URL on the CWMP analyzer. 3. Configure the CWMP analyzer to use session cookies. 4. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer. 2. Set the HTTP cookie in the HTTP response. 3. Allow the DUT to send an empty HTTP POST or an Inform RPC to the CWMP analyzer. 4. Analyze the HTTP message from the DUT to check if it is using the cookie sent by the ACS in its POST. 5. Issue an HTTP response with a 307 (Temporary Redirect) Status Code and the location of the new HTTPS URL. 6. Allow the DUT to issue the same HTTP POST message to the new URL. 7. Analyze the HTTP message from the DUT to check if it is using the cookie sent by the previous ACS in its POST. 8. Allow the DUT to close the connection. Test Metrics: 1. The DUT establishes SSL connection with the new ACS represented by the new URL. 42
2. The DUT includes cookie from old ACS to the new ACS in its HTTP POST. 3. The DUT successfully terminates the connection.
43
HTTP No Pipelining Purpose: This test is designed to verify that the CPE does not use pipelining as defined in HTTP 1.1 Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], a CPE must not make use of pipelining when it is using HTTP 1.1. This means, the CPE must not send multiple HTTP requests without getting response for the previous HTTP request. Procedure:
44
HTTP Authentication - Basic Authentication Purpose: This test is designed to verify that the CPE can successfully establish a CWMP session with the ACS using basic authentication. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], a CPE must support Basic Authentication. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Configure both the DUT and the CWMP analyzer to use basic authentication. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer. 2. Send an Authentication Challenge with a status code of 401 Unauthorized in its HTTP response. 3. Allow the DUT to issue an Inform RPC to the CWMP analyzer again with the authentication credentials in its HTTP header. 4. Reply with a successful Inform Response. 5. Allow the DUT to successfully terminate the session. Test Metrics: 1. The DUT passes Authentication Challenge by issuing proper authentication credentials to the ACS. 2. The DUT successfully terminates the session.
45
HTTP Authentication - Digest Authentication Purpose: This test is designed to verify that the CPE can successfully establish a CWMP session with the ACS using digest authentication. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], a CPE must support Basic Authentication. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Configure both the DUT and the CWMP analyzer to use digest authentication. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer. 2. Send an Authentication Challenge with a status code of 401 Unauthorized in its HTTP response. 3. Allow the DUT to issue an Inform RPC to the ACS again with the authentication credentials in its HTTP header. 4. Reply with a successful Inform Response. 5. Allow the DUT to successfully terminate the session. Test Metrics: 1. The DUT passes Authentication Challenge by issuing proper authentication credentials to the ACS. 2. The DUT successfully terminates the session.
46
SOAP Envelope Format Purpose: This test is designed to verify that the SOAP envelope encoded inside HTTP Messages sent by the DUT is properly formed. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069[1], SOAP 1.1 is the encoding syntax to transport the RPC method calls and responses in CPE WAN Management Protocol. In doing so, the encoding must use the standard SOAP 1.1 envelope namespace identifier: http://schemas.xmlsoap.org/soap/envelope, and the standard SOAP 1.1 serialization namespace identifier: http://schemas.xmlsoap.org/soap/encoding. All elements and attributes are associated with the namespace identifier urn:dslforumorg:cwmp-1-1. The namespace identifier for CPE WAN Management Protocol version 1.n is always urn:dslforum-org:cwmp:1-n, e.g. for v1.0 it was urn:dslforum-org:cwmp:1-0 and for v1.42 it will be urn:dslforum-org:cwmp:1-42. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Instruct the CWMP analyzer to issue an arbitrary RPC supported by the DUT. 3. Allow the DUT to respond with a successful response. 4. Analyze the SOAP response from the CPE.
Test Metrics: 1. The SOAP message uses SOAP 1.1 envelope namespace identifier: http://schemas.xmlsoap.org/soap/envelope 2. The SOAP message uses SOAP 1.1 serialization namespace identifier: http://schemas.xmlsoap.org/soap/encoding 47
3. The SOAP message uses a namespace identifier compliant with the CWMP Protocol version.
48
SOAP Fault Format Purpose: This test is designed to verify that the SOAP Fault response enclosed inside a SOAP envelope is formed properly. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069[1], a fault response from the CPE must make use of the following conventions: The SOAP faultcode element must indicate the source of the fault, either Client or Server, as appropriate for the particular fault. In the example used below, Client represents the originator of the SOAP request, and Server represents the SOAP responder. The SOAP faultstring sub-element must contain the string CWMP fault.
49
Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Instruct the CWMP analyzer to issue an arbitrary RPC not supported by the CPE. 3. Allow the DUT to respond with a SOAP Fault. 4. Analyze the SOAP Fault. Test Metrics: 1. The SOAP faultcode element indicates the source of fault with either Server or Client. 2. The SOAP faultstring sub-element contains the string CWMP fault.
50
SetParameterValues SOAP Fault Format Purpose: This test is designed to verify that the SetParameterValuesFault element in a SOAP Fault response is formed properly. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Any referenced documents or RFCs.
Normative Description: According to the Broadband Forum TR-069[1], along with the SOAP fault requirements outlined in the SOAP Fault Format test case, a SOAP Fault error during SetParameterValues must contain a SetParameterValuesFault element. This element is to be used only in an error response to the SetParameterValues method, that contains a list of one or more structures indicating the specific fault associated with each parameter in errror. The structure contains the following elements: A ParameterName element that contains the full path name of the parameter in error. A FaultCode element that contains a single numeric fault code that indicates the fault associated with the particular parameter in error. A FaultString element that contains a human readable description of the fault for the particular parameter in error.
51
Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Instruct the CWMP analyzer to issue a SetParameterValues request on an invalid parameter. 3. Allow the DUT to respond with a SOAP Fault. 4. Analyze the SOAP Fault. Test Metrics: 1. The SOAP faultcode element indicates the source of fault with either Server or Client. 2. The SOAP faultstring sub-element contains the string CWMP fault. 3. The SOAP message consists of a ParameterName element that contains the full path name of the parameter in error.
52
4. The SOAP message consists of a FaultCode element that contains a single numeric fault code that indicates the fault associated with the particular parameter in error. 5. The SOAP message consists of a FaultString element that contains a human readable description of the fault for the particular parameter in error.
53
GetRPCMethods and Required RPCs Purpose: This test is designed to verify that the CPE supports all the required RPCs. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], a CPE must support the following required RPCs, and may optionally support other RPCs: GetRPCMethods, SetParameterValues , SetParameterValues, GetParameterNames, SetParameterAttributes, GetParameterAttributes, AddObject, DeleteObject, Reboot, Download. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a GetRPCMethods RPC on the DUT. 3. Allow the DUT to respond with GetRPCMethodsResponse. 4. Allow the DUT to successfully terminate session with the ACS. 5. Analyze the GetRPCMethodResponse. Test Metrics: 1. The CPE responds to the GetRPCMethods call. 2. The GetRPCMethodsResponse from the DUT must contain all the required RPCs.
54
GetParameterNames Complete Path Purpose: This test is designed to verify that the CPE is capable of responding to a simple complete path request made by the ACS to determine its accessibility. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References According to Broadband Forum TR-069 [1], a CPE must support the following required RPCs, and may optionally support other RPCs: GetRPCMethods, SetParameterValues , SetParameterValues, GetParameterNames, SetParameterAttributes, GetParameterAttributes, AddObject, DeleteObject, Reboot, Download. The GetParameterNames RPC is used to determine the availability of parameters in the CPEs data model and their access level. The RPC can a complete or partial path as its argument; this test exercises the ability to complete the GetParameterNames RPC using a complete parameter path. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Respond with a successful Inform Response. 3. Schedule a GetParameterNames RPC on the DUT using complete path name of any parameter supported by the DUT. 4. Allow the DUT to respond with GetParameterNamesResponse. Test Metrics: 1. The CPE is able to respond to the GetParameterNames request from the CWMP analyzer with a response that includes the complete path of the requested parameter and whether the parameter is writable or not. 55
GetParameterNames Partial Path Next Level True Purpose: This test is designed to verify that the CPE is capable of responding to a partial path request made by the ACS when next level is set to true. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References: According to Broadband Forum TR-069 [1], when next level argument in GetParameterNames is set to true, the response from the DUT must contain all parameters and objects that are next-level children of the object given by the ParameterPath argument, if any. For example, if ParameterPath were InternetGatewayDevice.LANDevice.1.Hosts., the response would include the following: InternetGatewayDevice.LANDevice.1.Hosts.HostNumberOfEntries InternetGatewayDevice.LANDevice.1.Hosts.Host Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a GetParameterNames RPC on the DUT using a partial path and next level set to true. 3. Allow the DUT to respond with GetParameterNamesResponse. Test Metrics: 1. The CPE is able to successfully respond to the partial path request including only the next level.
56
GetParameterNames Partial Path Next Level False Purpose: This test is designed to verify that the CPE is capable of responding to a partial path request made by the ACS when next level is set to false. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References: According to Broadband Forum TR-069 [1], when next level argument in GetParameterNames is set to false, the response must contain the parameter or object whose name exactly matches the ParameterPath argument, if any (all levels below the specified object in the object hierarchy). For example, if ParameterPath were InternetGatewayDevice.LANDevice.1.Hosts, the response may include the following: InternetGatewayDevice.LANDevice.1.Hosts. InternetGatewayDevice.LANDevice.1.Hosts.HostNumberOfEntries InternetGatewayDevice.LANDevice.1.Hosts.Host. InternetGatewayDevice.LANDevice.1.Hosts.Host.1. InternetGatewayDevice.LANDevice.1.Hosts.Host.1.IPAddress InternetGatewayDevice.LANDevice.1.Hosts.Host.1.AddressSource InternetGatewayDevice.LANDevice.1.Hosts.Host.1.LeaseTimeRemaining InternetGatewayDevice.LANDevice.1.Hosts.Host.1.MACAddress InternetGatewayDevice.LANDevice.1.Hosts.Host.1.HostName InternetGatewayDevice.LANDevice.1.Hosts.Host.1.InterfaceType Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 57
2. Schedule a GetParameterNames RPC on the DUT using a partial path and next level set to false. 3. Allow the DUT to respond with GetParameterNamesResponse. Test Metrics: 1. The DUT is able to successfully respond to the partial path request at all levels below the specified partial path.
58
GetParameterNames Invalid Path Purpose: This test is designed to verify that the CPE can identify an invalid path and respond with appropriate error message to a GetParameterNames request on an invalid parameter. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References: According to Broadband Forum[1], when a GetParameterNames is attempted on an invalid parameter, the CPE must respond with a 9005 (Invalid Parameter Name) fault code. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose an incorrect parameter path name that has some contextual meaning to the DUTs supported data model. For example, Device.DeviceInfo.Invalid. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a GetParameterNames RPC on the DUT using the invalid parameter chosen in test setup step 2.. 3. Allow the DUT to respond with GetParameterNamesResponse. Test Metrics: 1. The CPE can identify an invalid path and respond with a 9005 fault code.
59
GetParameterNames Entire Object Model Purpose: This test is designed to verify that the CPE can communicate its entire object model to the ACS. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References: According to Broadband Forum TR-069 [1], when ParameterPath argument in the GetParameterNames is set to the root object in the DUTs data model (i.e., InternetGatewayDevice., or Device.), and next level argument in GetParameterNames is set to false, the response must contain the entire object model supported by the DUT. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a GetParameterNames RPC on the DUT using a partial path and next level set to true. 3. Allow the DUT to respond with GetParameterNamesResponse. Test Metrics: 1. The CPE can respond with its entire object model to the ACS.
60
GetParameterValues Simple Complete Path Purpose: This test is designed to verify that the CPE can respond to a GetParameterValues request by the ACS on a simple complete path. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References: According to BroadBand Forum TR-069 [1], a CPE must be able to respond to a GetParameterValues Request from an ACS when the argument is an array of strings, each representing the name of a requested parameter. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose a valid parameter from the DUTs supported data model. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a GetParameterNames RPC on the DUT using the complete parameter path chosen in test setup step 2. 3. Allow the DUT to respond with GetParameterNamesResponse. Test Metrics: 1. The DUT can properly respond to GetParameterValues request on a simple complete path.
61
GetParameterValues Multiple Complete Paths Purpose: This test is designed to verify that the CPE can respond to a GetParameterValues request by the ACS on a complete path. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References: According to BroadBand Forum[1], a CPE must be able to respond to a GetParameterValues Request from an ACS when the argument is an array of strings, each representing the name of a requested parameter. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose two valid parameters from the DUTs supported data model. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a GetParameterValues RPC on the DUT using the complete parameter paths chosen in test setup step 2. 3. Allow the DUT to respond with GetParameterNamesResponse. Test Metrics: 1. The CPE can properly respond to GetParameterValues request on multiple complete paths.
62
GetParameterValues Partial Path Purpose: This test is designed to verify that the CPE can respond to a GetParameterValues request by the ACS on a partial path. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References: According to BroadBand Forum[1], a CPE must be able to respond to a GetParameterValues Request from an ACS when the argument is an array of strings, each representing the name of a requested parameter. If the parameter name argument is given as a partial path name, the request is to be interpreted as a RPC on return all of the Parameters in the branch of the naming hierarchy that shares the same prefix as the argument. A partial path name must end with a .(dot) after the last node name in the hierarchy. An empty string indicates the top of the name hierarchy. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose a valid partial parameter path from the DUTs supported data model 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a GetParameterValues RPC on the DUT using a partial path. 3. Allow the DUT to respond with GetParameterValuesResponse. Test Metrics: 1. The CPE can properly respond to GetParameterValues request by the ACS on a simple complete path.
63
GetParameterValues Complete and Partial Paths Purpose: This test is designed to verify that the CPE can respond to a GetParameterValues request by the ACS on both complete and partial paths. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References: According to BroadBand Forum[1], a CPE must be able to respond to a GetParameterValues Request from an ACS when the argument is an array of strings, each representing the name of a requested parameter. If the parameter name argument is given as a partial path, the request is to be interpreted as a RPC to return all of the Parameters in the branch of the naming hierarchy that shares the same prefix as the argument. A partial path name must end with a .(dot) after the last node name in the hierarchy. An empty string indicates the top of the name hierarchy. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose two valid parameter paths from the DUTs supported data model, one partial and one complete path. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a GetParameterValues RPC on the DUT using both a complete path and a partial path. 3. Allow the DUT to respond with GetParameterValuesResponse. Test Metrics: 1. The CPE can properly respond to GetParameterValues request by the ACS on both complete and partial path.
64
GetParameterValues Entire Object Model Purpose: This test is designed to verify that the CPE can respond to a GetParameterValues request by the ACS on a partial path representing the top level in the datamodel with the entire object model. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References: According to BroadBand Forum[1], a CPE must be able to respond to a GetParameterValues Request from an ACS when the argument is an array of strings, each representing the name of a requested parameter. If the parameter name argument is given as a partial path name, the request is to be interpreted as a RPC on return all of the Parameters in the branch of the naming hierarchy that shares the same prefix as the argument. A partial path name must end with a .(dot) after the last node name in the hierarchy. An empty string indicates the top of the name hierarchy. Unlike the GetParameterNames RPC, a CPE may reject a GetParameterValues call on the entire object model. However, it may only do so due to a 9004 Resources Exceeded error. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a GetParameterValues RPC on the DUT using a partial path, such the partial path indicates the top level in the data model. 3. Allow the DUT to respond with GetParameterValuesResponse or the 9004 Resources Exceeded error. Test Metrics: 1. The CPE can properly respond to the CWMP analyzer with the entire object model, or throws the correct error if it cannot do so.
65
SetParameterValues Single Parameter Purpose: This test is designed to verify that the CPE supports the required SetParameterValues RPC and can change a single parameter. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References: According to Broadband Forum TR-069[1], if an ACS calls SetParameterValues on a DUT, the DUT must support the request and respond appropriately. On successful receipt of a SetParameterValues RPC, the CPE must apply the changes to all of the specified Parameters atomically. That is, either all of the value changes are applied together, or none of the changes are applied at all. In the latter case, the CPE must return a fault response indicating the reason for the failure to apply the changes. The CPE must not apply any of the specified changes without applying all of them. This requirement must hold true even if the CPE experiences a crash during the process of applying the changes. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose a valid, writable parameter from the DUTs supported data model. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a SetParameterValues RPC on the DUT on a writable parameter. 3. Allow the DUT to respond with SetParameterValuesResponse. a. If the he status code in SetParameterValuesResponse is 0, it means the DUT can change the parameter immediately. b. If the status code in SetParameterValuesResponse is 1, it means the DUT requires a reboot to apply the change to the parameter. In this case: i. Allow the DUT to terminate session with the ACS. ii. Allow the DUT to apply the change and reboot. 4. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 66
5. Schedule a GetParameterValues RPC on the DUT on the same parameter that was used for SetParameterValues. 6. Analyze the value. The value should be the new changed value. Test Metrics: 1. The DUT successfully changes the value of the parameter and reports the correct changed value in subsequent GetParameterValues request.
67
SetParameterValues Multiple Parameters Purpose: T This test is designed to verify that the CPE supports the required SetParameterValues RPC and can change multiple parameters in a single procedure call. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References: According to Broadband Forum TR-069[1], if an ACS calls SetParameterValues on a DUT, the DUT must support the request and respond appropriately. On successful receipt of a SetParameterValues RPC, the CPE must apply the changes to all of the specified Parameters atomically. That is, either all of the value changes are applied together, or none of the changes are applied at all. In the latter case, the CPE must return a fault response indicating the reason for the failure to apply the changes. The CPE must not apply any of the specified changes without applying all of them. This requirement must hold true even if the CPE experiences a crash during the process of applying the changes. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose at least two valid, writable parameters from the DUTs supported data model. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 7. Allow the DUT toEstablish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 8. Instruct the ACS to respond with a successful Inform Response. 9. Schedule a SetParameterValues RPC on the DUT on a writable parameter. 10. Allow the DUT to respond with SetParameterValuesResponse. a. If the he status code in SetParameterValuesResponse is 0, it means the DUT can change the parameter immediately. b. If the status code in SetParameterValuesResponse is 1, it means the DUT requires a reboot to apply the change to the parameter. In this case: i. Allow the DUT to terminate session with the ACS. ii. Allow the DUT to apply the change and reboot. 68
11. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 12. Schedule a GetParameterValues RPC on the DUT on the same parameter that was used for SetParameterValues. 13. Analyze the value. The value should be the new changed value. Test Metrics: 1. The DUT successfully changes the value of the parameter and reports the correct changed value in subsequent GetParameterValues request.
69
GetParameterAttributes Complete Path Purpose: This test is designed to verify that the CPE can provide attribute information of a single complete path. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], if an ACS requests for attribute information of a parameter using GetParameterAttributes method, the CPE must reply to the request with attribute information of the parameter. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose a valid parameter path in the DUTs supported data model. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a GetParameterAttributes request on the single complete path chosen in test setup step 2. 3. Allow the DUT to respond with GetParameterAttributesResponse. Test Metrics: 1. The DUT can properly respond to GetParameterAttributes request on a single path with attribute information of the path.
70
GetParameterAttributes Multiple Complete Paths Purpose: This test is designed to verify that the CPE can provide attribute information of multiple complete paths. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], if an ACS requests for attribute information of an array of parameters using GetParameterAttributes method, the CPE must reply to the request with attribute information of all the parameters in the array. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose two valid parameter paths in the DUTs supported data model. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a GetParameterAttributes request the parameter paths chosen in test setup step 2. 3. Allow the DUT to respond with GetParameterAttributesResponse. Test Metrics: 1. The DUT can properly respond to GetParameterAttributes request on multiple complete paths with attribute information of the paths.
71
GetParameterAttributes Partial Path Purpose: This test is designed to verify that the CPE can return attribute information of all the parameters in the branch of the name hierarchy that shares the same prefix as the partial path argument. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069 [1], if an ACS requests for attribute information of an array of parameters using GetParameterAttributes method, the CPE must reply to the request with attribute information of all the parameters in the array. If a parameter name argument is given as a partial path name, the request is to be interpreted as a RPC on return all of the Parameters in the branch of the naming hierarchy that shares the same prefix as the argument. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose a valid partial parameter path from the DUTs supported data model. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a GetParameterAttributes request on the partial path chosen in test setup step 2. 3. Allow the DUT to respond with GetParameterAttributesResponse. Test Metrics: 1. The DUT can properly respond to GetParameterAttributes request on multiple complete paths with attribute information of the paths.
72
GetParameterAttributes Complete and Partial Path Purpose: This test is designed to verify that the CPE can return attribute information of all the parameters in the branch of the name hierarchy that shares the same prefix as the partial path argument. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069[1], if an ACS requests for attribute information of an array of parameters using GetParameterAttributes method, the CPE must reply to the request with attribute information of all the parameters in the array. If a parameter name argument is given as a partial path name, the request is to be interpreted as a RPC on return all of the Parameters in the branch of the naming hierarchy that shares the same prefix as the argument. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose a valid complete parameter path and a valid partial parameter path in the DUTs supported data model. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a GetParameterAttributes request on the parameter paths selected in test setup step 2. 3. Allow the DUT to respond with GetParameterAttributesResponse. Test Metrics: 1. The DUT can properly respond to GetParameterAttributes request on multiple complete paths with attribute information of the paths.
73
SetParameterAttributes Active Notifications Purpose: This test is designed to verify that the CPE can successfully process SetParameterAttributes request from the ACS on a complete path with notification set to Active. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069[1], when the CPE receives a SetParameterAttributes request from the ACS on a complete path with notification set to Active, the CPE must initiate a session to the ACS, and include the new value in the ParameterList in the associated Inform message when the specified parameter value changes. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose a parameter from the DUTs supported data model that can be altered locally from the DUTs interface and is capable of performing active notification. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a SetParameterAttributes RPC on the selected parameter with notification set to Active (2). 3. Allow the DUT to respond with SetParameterAttributes response. 4. Modify the parameter in the DUT. 5. Allow the DUT to initiate a new session with the ACS by sending an Inform message. Test Metrics: 1. The DUT can respond with a SetParameterAttributesResponse to the request from the ACS. 2. The Inform after the modification of the parameter includes the event code 4 VALUE CHANGE. 3. The Inform after the modification includes the changed parameter in the ParameterList in the Inform Message. 74
SetParameterAttributes Passive Notification Complete Path Purpose: This test is designed to verify that the CPE can successfully process SetParameterAttributes request from the ACS on a complete path with notification set to Passive. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069[1], when the CPE receives a SetParameterAttributes request from the ACS on a complete path with notification set to Passive, 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. If the CPE has rebooted, or the URL of the ACS has changed since the last session, the CPE can choose to not include the changed parameter in the first session established with either the old ACS or the new ACS. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose a parameter from the DUTs supported data model that can be altered locally from the DUTs interface. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a SetParameterAttributes RPC on the DUT on the parameter chosen in test setup step 2. 3. Allow the DUT to respond with a SetParameterAttributes response. 4. Modify the parameter locally in the DUT. 5. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer with a successful Inform exchange. Test Metrics: 1. The DUT can respond with a SetParameterAttributesResponse to the request from the CWMP analyzer. 75
2. The Inform, after the modification of the parameter, includes the event code 4 VALUE CHANGE. 3. The Inform, after modification of the parameter, includes the event code of the event that stimulated the DUT to contact the CWMP analyzer. 4. The Inform after the modification includes the changed parameter in the ParameterList in the Inform Message.
76
SetParameterAttributes Passive Notification Partial Path Purpose: This test is designed to verify that the CPE can successfully process SetParameterAttributes request from the ACS on a partial path with notification set to Passive. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069[1], when the CPE receives a SetParameterAttributes request from the ACS on a particular path with notification set to Passive, 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. If the path is partial, the new attributes are to be applied to all Parameters below this point in the name hierarchy. If the CPE has rebooted, or the URL of the ACS has changed since the last session, the CPE can choose to not include the changed parameter in the first session established with either the old ACS or the new ACS. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose a partial parameter path from the DUTs supported data model that contains parameters that can be altered locally from the DUTs interface. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a SetParameterAttributes RPC on the DUT on the parameter chosen in test setup step 2. 3. Allow the DUT to respond with a SetParameterAttributes response. 4. Modify a parameter changed by the RPC locally in the DUT. 5. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer with a successful Inform exchange. Test Metrics: 1. The DUT can respond with a SetParameterAttributesResponse to the request from the CWMP analyzer. 77
2. The Inform, after the modification of the parameter, includes the event code 4 VALUE CHANGE. 3. The Inform, after modification of the parameter, includes the event code of the event that stimulated the DUT to contact the CWMP analyzer. 4. The Inform after the modification includes the changed parameter in the ParameterList in the Inform Message.
78
SetParameterAttributes Passive Notification Complete and Partial Path Purpose: This test is designed to verify that the CPE can successfully process SetParameterAttributes request from the ACS on both complete and partial paths with notification set to Passive. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069[1], when the CPE receives a SetParameterAttributes request from the ACS on a particular path with notification set to Passive, 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. If the path is partial, the new attributes are to be applied to all Parameters below this point in the name hierarchy. If the CPE has rebooted, or the URL of the ACS has changed since the last session, the CPE can choose to not include the changed parameter in the first session established with either the old ACS or the new ACS. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose two parameter paths, one complete and one partial, from the DUTs supported data model that contain parameters that can be altered locally from the DUTs interface. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a SetParameterAttributes RPC on the DUT on the parameters chosen in test setup step 2. 3. Allow the DUT to respond with a SetParameterAttributes response. 4. Modify the parameters represented by the complete path in the request, and one representing a parameter within the name hierarchy of the partial path specified in the request. 5. Stimulate the DUT to initiate a CWMP session with the CWMP analyzer with a successful Inform exchange. Test Metrics: 79
1. The DUT can respond with a SetParameterAttributesResponse to the request from the CWMP analyzer. 2. The Inform, after the modification of the parameters, includes the event code 4 VALUE CHANGE. 3. The Inform, after modification of the parameter, includes the event code of the event that stimulated the DUT to contact the CWMP analyzer. 4. The Inform after the modification includes the changed parameters in the ParameterList in the Inform Message.
80
SetParameterAttributes Disable Notification Purpose: This test is designed to verify that the CPE is capable of disabling previously set notification attribute. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References: According to Broadband Forum TR-069[1], when the CPE receives a SetParameterAttributes request from the ACS on a particular path with notification set to 0 (disable notification), the CPE must cease informing the ACS of value change events on that parameter. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose a parameter path (complete or partial) in the DUTs supported data model that is current set for either active or passive notification. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Instruct the ACS to respond with a successful Inform Response. 3. Instruct the ACS to send a SetParameterAttributes on a complete path or a partial path with notification set to 0 (disable notification). 4. Allow the DUT to respond with SetParameterAttributes response. 5. Modify the parameters represented by a complete path if specified in the request, or one representing a parameter within the name hierarchy of a partial path if specified in the request. 6. Ensure the DUT does not communicate an event to the CWMP analyzer indicating a change in the parameter. Test Metrics: 1. The DUT can respond with a SetParameterAttributesResponse to the request from the CWMP analyzer.
81
2. The DUT does not communicate an event to the CWMP analyzer indicated a change in the parameter.
82
AddObject Purpose: This test is designed to verify that the CPE is capable of creating an instance of a multi-instance object. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References: According to Broadband Forum TR-069[1], if an ACS uses AddObject RPC to create a new instance of a multi-instance object in the DUT, the DUT should honor the request, perform necessary action, create a new instance, and report back to ACS with the instanceNumber of the newly created object. The AddObject method call from the ACS takes as an argument the path name of the collection of objects for which a new instance is to be created. For example: Top.Group.Object. This path name does not include an instance number for the object to be created. The instance number is assigned by the CPE and returned in the response. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose a multi-instance, writable object within the DUTs supported data model. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule an AddObject RPC on the DUT on a parameter of which another instance can be created. 3. Allow the DUT to respond with AddObjectResponse. 1. If the status code in AddObjectResponse is 0, the DUT was successful in creating the parameter. 2. If the status code in AddObjectResponse is 1, the DUT either requires a reboot or other action to create the object. In such case: 1. Allow the DUT to terminate the session with the ACS. 83
2. Allow the DUT to perform reboot (if required) or other steps necessary to create the object. 3. Allow the DUT to issue an Inform RPC to the CWMP analyzer in order to establish CWMP session. 4. Respond with a successful Inform Response 4. Schedule a GetParameterNames RPC with the newly added object as an argument. 5. Allow the DUT to reply back with a GetParameterNamesResponse. Test Metrics: 1. The DUT successfully responds with an AddObjectResponse containing the InstanceNumber of the newly created object and either a 0 or a 1 as the status code. 2. If the status code is 1, the DUT performs all necessary action for addition and contacts the CWMP analyzer again by issuing an Inform RPC once addition is complete. 3. The DUT successfully responds to the GetParameterNames Request without a fault code.
84
DeleteObject Purpose: This test is designed to verify that the CPE is capable of removing a particular instance of an object. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References: According to Broadband Forum TR-069[1], if an ACS uses DeleteObject RPC to remove a particular instance of an object in the DUT, the DUT must honor the request, delete the particular instance of the object, and disregard the state previously associated with all Parameters(values and attributes) and sub-objects contained within this instance. The DeleteObject method call from the ACS takes as an argument the path name of the object instance including the instance number. For example: Top.Group.Object.2. When an object instance is deleted, the instance numbers associated with any other instances of the same collection of objects remain unchanged. Thus, the instance numbers of object instances in a collection might not be consecutive. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a DeleteObject RPC on the DUT on an accessible parameter. 3. Allow the DUT to respond with DeleteObjectResponse. 1. If the status code in DeleteObjectResponse is 0, the DUT was successful in deleting the instance of the parameter. 2. If the status code in DeleteObjectResponse is 1, the DUT either requires a reboot or other action to delete the object. In such case: 1. Allow the DUT to terminate the session with the ACS. 2. Allow the DUT to perform reboot ( if required ) or other DUT specific actions to delete the object. 85
3. Allow the DUT to issue an Inform RPC to the ACS in order to establish CWMP session. 4. Respond with a successful Inform Response 4. Schedule a GetParameterNames request on the recently deleted parameter. 5. Allow the DUT to send a GetParameterNamesResponse. Test Metrics: 1. The DUT successfully responds with a DeleteObjectResponse with either a 0 or a 1 as the status code. 2. If the status code is 1, the DUT performs all necessary action for deletion. 3. The DUT responds to the GetParameterNames Request with a fault code.
86
Reboot Purpose: This test is designed to verify that the CPE is capable of performing a reboot when instructed by the ACS. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References: According to Broadband Forum TR-069[1], when an ACS instructs the CPE to perform a reboot by issuing the Reboot method call, the CPE must send a successful method response and complete the remainder of the session prior to rebooting. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a Reboot RPC to the DUT. 3. Allow the DUT to reply with a successful RebootResponse. 4. Allow the DUT to terminate the session and perform reboot. 5. Allow the DUT to issue an Inform RPC to the ACS with an event code of 1 BOOT and M Reboot. Test Metrics: 1. The DUT successfully responds with a RebootResponse message. 2. The Inform message from DUT after reboot includes the event codes 1 BOOT and M Reboot.
87
Download Test Basic Version Upgrade Purpose: This test is designed to verify that the CPE is capable of peforming the Download RPC and apply the new software or firmware image. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative References: According to the Broadband Forum TR-069 [1], when Download method call is used by the ACS instructing the CPE to download a specified file from the designated location, the CPE must indicate successful or unsuccessful completion of the download using one of the following three means: A download Response with the status argument having a value of 0 (indicating success), or a fault response to the Download request (indicating failure). A TransferComplete RPC called later in the same session as the Download request(indicating either success or failure). In this case, the Status argument in the corresponding DownloadResponse must have a value of 1. A TransferComplete RPC made in a subsequent session (indicating either a success or failure). In this case, the Status argument in the corresponding DownloadResponse must have a value of 1.
Regardless of which mechanism is used, the CPE must only indicate successful completion of the download after the downloaded file has both been successfully transferred and applied. If the downloaded file is a software image, the CPE must consider the downloaded file to be successfully applied only after the new software image is actually installed and operational. If the software image replaces the overall software of the CPE (which would typically require a reboot to install and begin execution), the SoftwareVersion represented in the data model must already reflect the updated software image in the session in which the CPE makes a TransferComplete RPC on the ACS indicating successful download. If the CPE requires a reboot to apply the downloaded file, then the only appropriate means of indicating successful completion is the third option listed above a TransferComplete message sent in a subsequent session. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Obtain a firmware image for the DUT that, while structurally identical to the operating firmware under test, contains a different image version number. 88
3. Configure and provide a file server (i.e., http or ftp) that can be accessed by DUT through the network infrastructure. Authentication may or may not be configured on the file server. 4. Copy the provided firmware image to the file server. 5. Connect all components of the test setup to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a Download RPC with the following arguments: CommandKey FileType URL Username Password FileSize TargetFileName DelaySeconds SuccessURL FailureURL Empty String 1 Firmware Upgrade Image Location of the firmware image Username to be used by the CPE to authenticate with the file server (if any). Password to be used by the CPE to authenticate with the file server (if any). The size of the file to be downloaded in bytes. The name of the firmware image A random time between 60 and 120 seconds. This exercises the devices ability to wait before performing the download. Empty string Empty string
3. Allow the DUT to respond with DownloadResponse. a) A status code of 0 in the DownloadResponse means the DUT successfully finished download and applied the change. b) A status code of 1 means the DUT will need time to download the file or need certain actions like Reboot to complete the download. In such case: 1. Allow the DUT to finish downloading the firmware image. Allow the DUT to reboot if needed. 2. If the session has not been terminated, allow the DUT to send a TransferComplete message in the same session. 89
3. If the session has been terminated (as a result of reboot or similar action), allow the DUT to initiate a connection with the ACS by sending an Inform message and instruct the ACS to respond with a successful InformResponse. 4. Issue a GetParameterValues request from the ACS to the DUT on SoftwareVersion parameter to verify if the new firmware image has been applied by the DUT. 5. Allow the DUT to respond with a GetParameterValues Response. Test Metrics: 1. The DUT successfully responds to the Download RPC with a DownloadResponse. 2. The DUT performs the Download. 3. The DUT performs the firmware upgrade. 4. If the upgrade was performed after the session has closed, in the Inform following the upgrade, the DUT includes the events 7 TRANSFER COMPLETE and M Download. 5. The version information given in the same Inform contains the NEW firmware version. 6. The DUT makes the TransferComplete RPC to indicate the Download was successful.
90
Upload Purpose: The purpose of this test is to verify DUT's upload functionality. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069[1], if an ACS issues an Upload RPC on the DUT, the DUT may choose to upload the specified file to the designated location. If the file cannot be successfully uploaded, the DUT must not attempt to retry the file upload on its own initiative, but instead must report the failure of the upload to the ACS via either the Upload response Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Install or acquire a vendor configuration or log file that is installed on the DUT. 3. Configure and provide a file server (i.e., http or ftp) that can be accessed by DUT through the network infrastructure. Authentication may or may not be configured on the file server. 4. Connect all components of the test setup to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges.
2. Instruct the CWMP analyzer to issue an Upload Request with the following parameters: CommandKey Empty String An integer followed by a space followed by the file type description. For a vendor configuration file, set this parameter to 1 Vendor Configuration File, and for a vendor log file, set this parameter to 2 Vendor Log File. The URL of the destination server configured in the test setup. Username to be used by the CPE to 91
FileType
URL Username
authenticate with the file server (if any). Password FileSize TargetFileName DelaySeconds Password to be used by the CPE to authenticate with the file server (if any). The size of the file to be downloaded in bytes. The name of the firmware image A random time between 60 and 120 seconds. This exercises the devices ability to wait before performing the upload.
3. Allow the DUT to respond with an UploadResponse message. a) A status code of 0 in the UploadResponse means the Upload has completed. b) A status code of 1 menas the DUT will need time or certain actions to upload the file. i. Allow the DUT to finish uploading the file. Allow the DUT to reboot if needed.
ii. If the session has not been terminated, allow the DUT to send a TransferComplete message in the same session. iii. If the session has been terminated (as a result of reboot or similar action), allow the DUT to initiate a session with the CWMP analyzer. 4. Check the file server to verify if the file has been uploaded. Test Metrics: 1. The DUT successfully responds to the Download RPC with a DownloadResponse. 2. The DUT performs the Download. 3. The DUT performs the firmware upgrade. 4. If the upgrade was performed after the session has closed, in the Inform following the upgrade, the DUT includes the events 7 TRANSFER COMPLETE and M Upload. 5. The DUT makes the TransferComplete RPC to indicate the Upload was successful.
92
ScheduleInform Test Purpose: The purpose of this test is to verify that the CPE is able to schedule a one-time Inform method call when requested by the CWMP analyzer using ScheduleInform Test. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069[1], if an ACS issues a ScheduleInform RPC, the CPE may schedule a one-time Inform method call sometime in the future. The time the CPE must wait before issuing an Inform message is specified as a parameter in the ScheduleInform request. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose a time interval between 60 and 300 seconds for the DUT to perform the scheduled inform. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges.
2. Instruct the CWMP analyzer to issue a ScheduleInform to the DUT. 3. Allow the DUT to respond with a successful ScheduleInformResponse. 4. Wait for the DUT to issue an Inform RPC to the CWMP analyzer. 5. Respond with a successful Inform Response. Test Metrics: 1. The DUT successfully responds with a ScheduleInformResponse message. 2. The DUT issues an Inform RPC to the CWMP analyzer with event code 3 SCHEDULED
93
FactoryReset Purpose: The purpose of this test is to verify that the DUT is capable of performing factory reset procedure upon receipt of FactoryReset RPC from the ACS. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: According to Broadband Forum TR-069[1], if an ACS issues a FactoryReset RPC to the DUT, the DUT can choose to perform factory reset. The DUT must initiate the factory reset procedure only after successful completion of the session. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a FactoryReset RPC on the DUT with the CWMP analyzer. 3. Allow the DUT to respond with FactoryResetResponse message. 4. Allow the session to terminate successfully. 5. Manually check the CPEs state. Test Metrics: 1. The CPE does not attempt the Factory Reset before terminating the session. 2. The CPE has returned to its Factory Reset state.
94
CWMP Faults Basic RPC Faults Purpose: The purpose of this test is to verify that the DUT is capable of rejecting RPCs that it does not support. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: Section A.5.1 of Broadband Forum TR-069[1] specifies the CWMP Fault codes that can be returned by the CPE in a variety of circumstances. These faults, listed in Table 65 of [1], consist of a fault code which must be used as the value of the SOAP fault code element, as well as arguments that may be required as part of the faults functionality. Different fault codes are allowed or required for each of the RPCs described in CWMP. This test exercises the basic fault, 9000 Method not supported. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose a valid RPC that is not listed as supported by the DUT. 3. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a GetRPCMethods RPC on the DUT with the CWMP analyzer. 3. Allow the DUT to respond with GetRPCMethodsResponse message. 4. Ensure that the RPC selected in test setup step 2 is not listed in the GetRPCMethodsResponse. 5. Schedule the RPC selected in test setup step 2 on the DUT with the CWMP analyzer. 6. Allow the DUT to respond with fault 9000 Method not supported. Test Metrics: 1. The DUT rejects an RPC that it does not support. 2. The fault is correctly formed.
95
CWMP Faults - SetParameterValues Purpose: The purpose of this test is to verify that the DUT uses the appropriate and well formed fault codes when the ACS attempts to alter its state. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: Section A.5.1 of Broadband Forum TR-069[1] specifies the CWMP Fault codes that can be returned by the CPE in a variety of circumstances. These faults, listed in Table 65 of [1], consist of a fault code which must be used as the value of the SOAP fault code element, as well as arguments that may be required as part of the faults functionality. Different fault codes are allowed or required for each of the RPCs described in CWMP. This test attempts to exercise as many fault scenarios on the DUT as is possible from a practical test setup. Since it is not necessarily possible to force the DUT to send arbitrary fault codes, the procedure focuses on those faults that can be stimulated through normal CMWP operation. For the SetParameterValues RPC, it is required that changes be applied atomically, that is, either all the changes are made or none of them are made. In the event of a CWMP fault, no changes to the data model should be made when the request is rejected. Specific to the SetParameterValues RPC is the SetParameterValuesFault element in the fault response. For all parameter errors during a SetParameterValues call, the base fault must be 9003 Invalid arguments. Within the fault structure, additional fault codes are conveyed containing information specific to the parameters that failed. When the values would result in an invalid configuration, the error used is 9007 Invalid parameter value. Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Choose a valid, writable parameter from the DUTs supported data model. 3. Construct an invalid parameter name within the context of the DUTs supported data model. 4. Select a non-writable parameter from the DUTs supported data model. 5. Choose a parameter with a restrictive data type in the DUTs supported data model. 6. Choose a parameter with restricted possible values in the DUTs supported data model. 7. Connect the DUT and CWMP analyzer to the network infrastructure. 96
Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a SetParameterValues RPC on the DUT with the CWMP analyzer, using the invalid parameter name determined in test setup step 3. 3. Allow the DUT to respond with fault code 9003 Invalid arguments with the SetParameterValuesFault 9005 Invalid parameter name. 4. Allow the session to terminate successfully. 5. Repeat step 1. 6. Schedule a SetParameterValues RPC on the DUT with the CWMP analyzer, using the non-writable parameter determined in test setup step 4. 7. Allow the DUT to respond with fault code 9003 Invalid arguments with the SetParameterValuesFault 9008 Attempt to set non-writable parameter. 8. Allow the session to terminate successfully. 9. Repeat step 1. 10. Schedule a SetParameterValues RPC on the DUT with the CWMP analyzer, using the parameter determined in test setup step 5. Set the value to be of a data type not supported by the parameter (for example, setting a string in an integer). 11. Allow the DUT to respond with fault code 9003 Invalid arguments with the SetParameterValuesFault 9006 Invalid parameter type. 12. Allow the session to terminate successfully. 13. Repeat step 1. 14. Schedule a SetParameterValues RPC on the DUT with the CWMP analyzer, using the parameter determined in test setup step 6. Set the value to be outside the range of possible values. 15. Allow the DUT to respond with fault code 9003 Invalid arguments with the SetParameterValuesFault 9007 Invalid parameter values. 16. Allow the session to terminate successfully. 17. Repeat step 1. 18. Schedule a SetParameterValues RPC on the DUT with the CWMP analyzer, using the invalid parameter name determined in test setup step 3 and the valid parameter determined in test setup step 2 with a value set to a changed, valid value. 19. Allow the DUT to respond with fault code 9003 Invalid arguments with the SetParameterValuesFault 9005 Invalid parameter name. 97
20. Schedule a GetParameterValues RPC on the DUT with the CWMP analyzer, using the valid parameter determined in test setup step 2. 21. Allow the DUT to respond with a GetParameterValues response. 22. Record the value reported by the DUT. 23. Allow the session to terminate successfully. Test Metrics: 1. The DUT responds with properly formed fault codes. 2. The DUT includes the offending parameters in the SetParameterValuesFault. 3. The DUT does not alter the valid parameter when invalid parameters are included in the same procedure call arguments.
98
CWMP Faults Download and Upload Failure Purpose: The purpose of this test is to verify that the DUT is capable of notifying the ACS of a failed Download or Upload RPC when it calls the TransferComplete RPC. Target: Any CWMP enabled CPE that communicates directly with the ACS. References: [1] Broadband Forum TR-069
Normative Description: Section A.5.1 of Broadband Forum TR-069[1] specifies the CWMP Fault codes that can be returned by the CPE in a variety of circumstances. These faults, listed in Table 65 of [1], consist of a fault code which must be used as the value of the SOAP fault code element, as well as arguments that may be required as part of the faults functionality. Different fault codes are allowed or required for each of the RPCs described in CWMP. This test exercises the faults that arise from a failed file transfer using the Upload and Download RPCs. The CPE attempts the transfer after the ACS makes an Upload or Download RPC on it, and makes the TransferComplete RPC on the ACS when the file transfer is completed or when an error occurs. The TransferComplete RPC contains a FaultStruct which includes any faults associated with the transfer. This test exercises faults 9010 through 9013, though the CPE may also include more detailed error codes for transfer errors (9014-9019). Test Setup: 1. Configure the DUT to use the ACS URL set on the CWMP analyzer. 2. Install or acquire a vendor configuration or log file that is installed on the DUT. 3. Configure and provide a file server (i.e., http or ftp) that can be accessed by DUT through the network infrastructure. Configure the file server both for unauthenticated and authenticated transfers. 4. Connect the DUT and CWMP analyzer to the network infrastructure. Procedure: 1. Establish a CWMP session between the CWMP analyzer and DUT with successful Inform exchanges. 2. Schedule a Download RPC on the DUT with the CWMP analyzer with the URL argument indicating the URL of the file server appended with a non-existent file name. 3. Allow the DUT to respond with a DownloadResponse message. 99
4. Allow the DUT to attempt the file transfer. 5. Allow the DUT to initiate a CWMP session with CWMP analyzer, indicated a TRANSFER COMPLETE event. 6. Allow the DUT to issue the TransferComplete RPC on the CWMP analyzer with the associated error codes (at least 9010 Download failure). 7. Configure the file server to use authentication. 8. Repeat steps 1 and 2. In the Download RPC, configure the Username and Password arguments with values that do not correspond to the authentication requirements of the file server. 9. Repeat steps 3-5. 10. Allow the DUT to issue the TransferComplete RPC on the CWMP analyzer with the associated error codes (at least 9010 Download failure and 9012 File transfer server authentication failure). 11. Repeat steps 1-10 for the Upload RPC. Test Metrics: 3. The DUT responds with appropriate fault codes for the Upload and Download RPCs. 4. The faults are correctly formed.
100

TR 069 Conformance 1 0

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

TR 069 Conformance 1 0

Transféré par

Droits d'auteur :

Formats disponibles

Broadband Forum TR-069 (CWMP) CPE Conformance Test Suite

UNH-IOL TR-069 Consortium

Digitally signed by UNH-IOL Date: 2010.11.2 2 14:04:00 -05'00'

TR-069 Consortium University of New Hampshire InterOperability Laboratory www.iol.unh.edu

4. DNS/File/ DHCP Servers

3. Internal Test Netowrk

4. CWMP Generator/ Analyzer

Figure below is an example of a session.

2. The GetParameterValueResponse includes URL of the old ACS.

2. The GetParameterValueResponse includes URL of the old ACS.

Vous aimerez peut-être aussi