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

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 121 Technology Drive, Suite 2

University of New Hampshire Durham, NH 03824

InterOperability Laboratory Phone: +1-603-862-0090

www.iol.unh.edu Fax: +1-603-862-4181

http://www.iol.unh.edu/

2

© 2010 University of New Hampshire InterOperability Laboratory

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

3


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

4


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

5


Introduction

Overview

The University of New Hampshire’s 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.

6


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.

7


Test Setup

General Test Setup

1. CPE3. Internal Test

Netowrk

4. DNS/File/

DHCP

Servers

4. CWMP

Generator/

Analyzer

8


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] Broadband Forum TR-069

[2] 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.

9


2. The DUT establishes CWMP session with the ACS specified by the URL.

10


ACS Rediscovery using DHCP

Purpose:

This test is designed to verify that the DUT consistently utilizes DHCP to discover the ACS URL.

Target:


References:


[2] RFC 2131


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:




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.

11


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:


References:


[2] RFC 2131


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:




Procedure:


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.

12


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:


References:


[2] RFC 2131


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:




Procedure:


2. Respond to the DHCP request with a valid response to set the ACS URL with a URL that is null-

terminated.

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.

13


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:


[2] DNS RFC 1034


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:



3. Connect the DUT, DNS server, DHCP server, and CWMP analyzer to the network infrastructure.

Procedure:


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.

14


Test Metrics:

1. The DUT contacts the DNS server again to resolve the ACS URL without caching the previous

response from the DNS server.

15


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:



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.

16


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:


References:



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:



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.

17


2. The Inform RPC arguments contain the “0 BOOTSTRAP” event code.

3. The DUT’s CWMP messages are valid.

4. The DUT successfully terminates the session.

18


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:


References:



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.



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.


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.



Test Metrics:

1. The DUT uses digest authentication to authenticate the connection request.

19


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”.



20


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:


References:



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.



behavior is indicated by the event code “2 PERIODIC”.

Test Setup:


2. Choose a short value for the PeriodicInformInterval, between 60 and 300 seconds. Configure

the DUT to use this value for PeriodicInformInterval.


Procedure:


exchanges.

2. Allow the session to terminate successfully.

3. Wait for the PeriodicInformInterval determined in test setup step 2.



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.


21



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”.



22


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:


References:



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.


Procedure:

1. Stimulate the DUT to send a CWMP Inform message to the CWMP analyzer.

2. Respond to the Inform Request with an InformResponse.



Test Metrics:

1. The DUT attempts to establish a session by sending an Inform message.



23


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:


References:



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.


Procedure:

1. Send a Connection RPC on the DUT over https.

2. Allow the DUT to authenticate the Connection Request.




Test Metrics:

1. The DUT authenticates the Connection Request.

2. The DUT initiates a CWMP session based on the Connection Request.



24


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:



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.


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.

25


Session Initiation and Termination

Purpose:

This test is designed to verify that the CPE is able to initiate and terminate a session properly.

Target:


References:



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.

26


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.

27


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.

28


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:


References:



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:



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.


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.

29


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:


References:



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:



Procedure:


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.



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.

30


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:


References:



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:


2. Configure the CWMP analyzer to use session cookies.


Procedure:


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.


Test Metrics:

1. The DUT returns the cookie value in each subsequent HTTP POST after the cookie has been set.

31


Session Retry

Purpose:

This test is designed to verify that the DUT retries a failed session with the ACS.

Target:


References:



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.

32


Test Setup:

Part A: Revert back to previous CWMP version


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.


Part B: Session Retry on HTTP Fault and Part C: Session Retry on SOAP Fault



Procedure:

Part A: Revert back to CWMP v1.0


2. Instruct the CWMP Analyzer to respond with an HTTP response with status code of 400 (Bad

Request) instead of 200 OK.


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.


6. Allow the DUT to successfully terminate the connection.

33


Part B: Session Retry on HTTP Fault


2. Respond with an HTTP response with status code of 400 (Bad Request) instead of 200 OK.



message after the designated wait period.



Part C: Session Retry on SOAP Fault


2. Respond with an HTTP response with a SOAP fault response with fault code other than 8005

(Retry Request).



message after the designated wait period.



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.


Part C: Session Retry on SOAP Fault Code

34


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.


35


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:


References:



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:



Procedure:


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”.

36


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:


References:



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:


2. If the CWMP analyzer is capable of supporting multiple ACS URLs, configure an alternate ACS

URL on the CWMP analyzer.


Procedure:


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.

37


2. The GetParameterValueResponse includes URL of the old ACS.

38


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:


References:



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:


2. If the CWMP analyzer is capable of supporting multiple ACS URLs, configure an alternate ACS

URL on the CWMP analyzer.


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.





6. Analyze the response. The value of the parameter should be the old URL before redirection, and not the new URL.


Test Metrics:


39



40


HTTP Redirection – Multiple Redirections

Purpose:

This test is designed to verify that the CPE allows up to 5 consecutive redirections.

Target:


References:



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:


2. If the CWMP analyzer is capable of supporting multiple ACS URLs, configure an alternate ACS URL on the CWMP analyzer.


Procedure:


2. Issue an HTTP response with a 307 (Temporary Redirect) Status Code and the location of 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.


7. Issue an HTTP response with a 307 (Temporary Redirect) Status Code and the location of the new URL.



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.

41


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:


References:



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:


2. If the CWMP analyzer is capable of supporting multiple ACS URLs, configure an alternate https ACS URL on the CWMP analyzer.


Procedure:


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.


5. Using the new URL at the CWMP Analzyer, reply back with an Inform Response.



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.



42


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:


References:



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:


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.


Procedure:


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.


7. Analyze the HTTP message from the DUT to check if it is using the cookie sent by the previous ACS in its POST.


Test Metrics:

1. The DUT establishes SSL connection with the new ACS represented by the new URL.

43


2. The DUT includes cookie from old ACS to the new ACS in its HTTP POST.

3. The DUT successfully terminates the connection.

44


HTTP – No Pipelining

Purpose:

This test is designed to verify that the CPE does not use pipelining as defined in HTTP 1.1

Target:


References:



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:

45


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:


References:



According to Broadband Forum TR-069 [1], a CPE must support Basic Authentication.

Test Setup:


2. Configure both the DUT and the CWMP analyzer to use basic authentication.


Procedure:


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.



Test Metrics:

1. The DUT passes Authentication Challenge by issuing proper authentication credentials to the ACS.


46


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:


References:



According to Broadband Forum TR-069 [1], a CPE must support Basic Authentication.

Test Setup:


2. Configure both the DUT and the CWMP analyzer to use digest authentication.


Procedure:


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.



Test Metrics:

1. The DUT passes Authentication Challenge by issuing proper authentication credentials to the ACS.


47


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:


References:



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:dslforum-

org: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:



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”

http://schemas.xmlsoap.org/soap/envelope

http://schemas.xmlsoap.org/soap/encoding

http://schemas.xmlsoap.org/soap/envelope

http://schemas.xmlsoap.org/soap/encoding

48


3. The SOAP message uses a namespace identifier compliant with the CWMP Protocol version.

49


SOAP Fault Format

Purpose:

This test is designed to verify that the SOAP Fault response enclosed inside a SOAP envelope is

formed properly.

Target:


References:



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”.

50


Test Setup:



Procedure:


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”.

51


SetParameterValues SOAP Fault Format

Purpose:

This test is designed to verify that the SetParameterValuesFault element in a SOAP Fault

response is formed properly.

Target:


References:

[1] Any referenced documents or RFCs.


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.

52


Test Setup:



Procedure:


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.

53


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.

54


GetRPCMethods and Required RPCs

Purpose:

This test is designed to verify that the CPE supports all the required RPCs.

Target:


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.

Test Setup:



Procedure:


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.

55


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:


References:


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:



Procedure:


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.

56


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:


References:


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:



Procedure:


exchanges.

2. Schedule a GetParameterNames RPC on the DUT using a partial path and next level set to true.


Test Metrics:

1. The CPE is able to successfully respond to the partial path request including only the next level.

57


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:


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:



Procedure:


exchanges.

58


2. Schedule a GetParameterNames RPC on the DUT using a partial path and next level set to false.


Test Metrics:

1. The DUT is able to successfully respond to the partial path request at all levels below the

specified partial path.

59


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:


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:


2. Choose an incorrect parameter path name that has some contextual meaning to the DUT’s

supported data model. For example, “Device.DeviceInfo.Invalid.”


Procedure:


exchanges.

2. Schedule a GetParameterNames RPC on the DUT using the invalid parameter chosen in test

setup step 2..


Test Metrics:

1. The CPE can identify an invalid path and respond with a 9005 fault code.

60


GetParameterNames – Entire Object Model

Purpose:

This test is designed to verify that the CPE can communicate its entire object model to the ACS.

Target:


References:



According to Broadband Forum TR-069 [1], when ParameterPath argument in the

GetParameterNames is set to the root object in the DUT’s 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:



Procedure:


exchanges.

2. Schedule a GetParameterNames RPC on the DUT using a partial path and next level set to true.


Test Metrics:

1. The CPE can respond with its entire object model to the ACS.

61


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:


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:


2. Choose a valid parameter from the DUT’s supported data model.


Procedure:


exchanges.

2. Schedule a GetParameterNames RPC on the DUT using the complete parameter path chosen in

test setup step 2.


Test Metrics:

1. The DUT can properly respond to GetParameterValues request on a simple complete path.

62


GetParameterValues – Multiple Complete Paths

Purpose:


ACS on a complete path.

Target:


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:


2. Choose two valid parameters from the DUTs supported data model.


Procedure:


exchanges.

2. Schedule a GetParameterValues RPC on the DUT using the complete parameter paths chosen in

test setup step 2.


Test Metrics:

1. The CPE can properly respond to GetParameterValues request on multiple complete paths.

63


GetParameterValues – Partial Path

Purpose:


ACS on a partial path.

Target:


References:





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:


2. Choose a valid partial parameter path from the DUT’s supported data model


Procedure:


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.

64


GetParameterValues – Complete and Partial Paths

Purpose:


ACS on both complete and partial paths.

Target:


References:





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:


2. Choose two valid parameter paths from the DUT’s supported data model, one partial and one

complete path.


Procedure:


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.

65


GetParameterValues – Entire Object Model

Purpose:


ACS on a partial path representing the top level in the datamodel with the entire object model.

Target:


References:





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:



Procedure:


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.

66


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:


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:


2. Choose a valid, writable parameter from the DUT’s supported data model.


Procedure:


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.


exchanges.

67


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.

68


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:


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:


2. Choose at least two valid, writable parameters from the DUT’s supported data model.


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.

69



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.

70


GetParameterAttributes – Complete Path

Purpose:

This test is designed to verify that the CPE can provide attribute information of a single complete

path.

Target:


References:



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:


2. Choose a valid parameter path in the DUT’s supported data model.


Procedure:


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.

71


GetParameterAttributes – Multiple Complete Paths

Purpose:

This test is designed to verify that the CPE can provide attribute information of multiple

complete paths.

Target:


References:



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:


2. Choose two valid parameter paths in the DUT’s supported data model.


Procedure:


exchanges.

2. Schedule a GetParameterAttributes request the parameter paths chosen in test setup step 2.


Test Metrics:

1. The DUT can properly respond to GetParameterAttributes request on multiple complete paths

with attribute information of the paths.

72


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:


References:



According to Broadband Forum TR-069 [1], if an ACS requests for attribute information of an


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:


2. Choose a valid partial parameter path from the DUT’s supported data model.


Procedure:


exchanges.

2. Schedule a GetParameterAttributes request on the partial path chosen in test setup step 2.


Test Metrics:



73


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:


References:



According to Broadband Forum TR-069[1], if an ACS requests for attribute information of an


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:


2. Choose a valid complete parameter path and a valid partial parameter path in the DUT’s

supported data model.


Procedure:


exchanges.

2. Schedule a GetParameterAttributes request on the parameter paths selected in test setup step 2.


Test Metrics:



74


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:


References:



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:


2. Choose a parameter from the DUT’s supported data model that can be altered locally from the

DUT’s interface and is capable of performing active notification.


Procedure:


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.

75


SetParameterAttributes – Passive Notification – Complete Path

Purpose:


request from the ACS on a complete path with notification set to Passive.

Target:


References:




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:


2. Choose a parameter from the DUT’s supported data model that can be altered locally from the

DUT’s interface.


Procedure:


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.

76


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.


Inform Message.

77


SetParameterAttributes – Passive Notification – Partial Path

Purpose:


request from the ACS on a partial path with notification set to Passive.

Target:


References:




request from the ACS on a particular path with notification set to Passive, whenever the specified


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:


2. Choose a partial parameter path from the DUT’s supported data model that contains parameters

that can be altered locally from the DUT’s interface.


Procedure:


exchanges.

2. Schedule a SetParameterAttributes RPC on the DUT on the parameter chosen in test setup step

2.


4. Modify a parameter changed by the RPC locally in the DUT.


exchange.

Test Metrics:


analyzer.

78


2. The Inform, after the modification of the parameter, includes the event code “4 VALUE CHANGE”.




Inform Message.

79


SetParameterAttributes – Passive Notification – Complete and Partial Path

Purpose:


request from the ACS on both complete and partial paths with notification set to Passive.

Target:


References:




request from the ACS on a particular path with notification set to Passive, whenever the specified


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:


2. Choose two parameter paths, one complete and one partial, from the DUT’s supported data

model that contain parameters that can be altered locally from the DUT’s interface.


Procedure:


exchanges.

2. Schedule a SetParameterAttributes RPC on the DUT on the parameters chosen in test setup step

2.


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.


exchange.

Test Metrics:

80



analyzer.

2. The Inform, after the modification of the parameters, includes the event code “4 VALUE

CHANGE”.



4. The Inform after the modification includes the changed parameters in the ParameterList in the

Inform Message.

81


SetParameterAttributes – Disable Notification

Purpose:

This test is designed to verify that the CPE is capable of disabling previously set notification

attribute.

Target:


References:




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:


2. Choose a parameter path (complete or partial) in the DUT’s supported data model that is current

set for either active or passive notification.


Procedure:


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:


analyzer.

82


2. The DUT does not communicate an event to the CWMP analyzer indicated a change in the

parameter.

83


AddObject

Purpose:

This test is designed to verify that the CPE is capable of creating an instance of a multi-instance

object.

Target:


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:


2. Choose a multi-instance, writable object within the DUT’s supported data model.


Procedure:


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.

84


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.

85


DeleteObject

Purpose:

This test is designed to verify that the CPE is capable of removing a particular instance of an

object.

Target:


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:



Procedure:


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.

86


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.

87


Reboot

Purpose:

This test is designed to verify that the CPE is capable of performing a reboot when instructed by

the ACS.

Target:


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:



Procedure:


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”.

88


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:


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:


2. Obtain a firmware image for the DUT that, while structurally identical to the operating firmware

under test, contains a different image version number.

89


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:


exchanges.

2. Schedule a Download RPC with the following arguments:

CommandKey Empty String

FileType “1 Firmware Upgrade Image”

URL Location of the firmware image

Username Username to be used by the CPE to

authenticate with the file server (if any).

Password Password to be used by the CPE to


FileSize The size of the file to be downloaded in bytes.

TargetFileName The name of the firmware image

DelaySeconds

A random time between 60 and 120 seconds.

This exercises the device’s ability to wait

before performing the download.

SuccessURL Empty string

FailureURL 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.

90


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.

91


Upload

Purpose:

The purpose of this test is to verify DUT's upload functionality.

Target:


References:



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:


2. Install or acquire a vendor configuration or log file that is installed on the DUT.


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:


exchanges.

2. Instruct the CWMP analyzer to issue an Upload Request with the following parameters:

CommandKey Empty String

FileType

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”.

URL The URL of the destination server configured

in the test setup.

Username Username to be used by the CPE to

92



Password Password to be used by the CPE to


FileSize The size of the file to be downloaded in bytes.

TargetFileName The name of the firmware image

DelaySeconds

A random time between 60 and 120 seconds.

This exercises the device’s 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.

93


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:


References:



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:


2. Choose a time interval between 60 and 300 seconds for the DUT to perform the scheduled

inform.


Procedure:


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”

94


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:


References:



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:



Procedure:


exchanges.

2. Schedule a FactoryReset RPC on the DUT with the CWMP analyzer.

3. Allow the DUT to respond with FactoryResetResponse message.


5. Manually check the CPE’s 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.

95


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:


References:



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 fault’s 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:


2. Choose a valid RPC that is not listed as supported by the DUT.


Procedure:


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.

96


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:


References:








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:


2. Choose a valid, writable parameter from the DUT’s supported data model.

3. Construct an invalid parameter name within the context of the DUT’s supported data model.

4. Select a non-writable parameter from the DUT’s supported data model.

5. Choose a parameter with a restrictive data type in the DUT’s supported data model.

6. Choose a parameter with restricted possible values in the DUT’s supported data model.


97


Procedure:


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”.


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.


SetParameterValuesFault “9008 – Attempt to set non-writable parameter”.


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).


SetParameterValuesFault “9006 – Invalid parameter type”.


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.


SetParameterValuesFault “9007 – Invalid parameter values”.


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.


SetParameterValuesFault “9005 – Invalid parameter name.”

98


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.


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.

99


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:


References:








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:


2. Install or acquire a vendor configuration or log file that is installed on the DUT.


network infrastructure. Configure the file server both for unauthenticated and authenticated

transfers.


Procedure:


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.

100


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.

tr 069 conformance 1 0

Documents

hampshire

broadband

human readable

successful

successful

multiple tcp

cwmp sessions

multiple cwmp