5.1 Basic Setup

5.1.1 Factory Reset

5.1.1.1 Purpose:

5.1.1.2 References:

5.1.1.3 Profiles:

5.1.1.4 Optional Features:

5.1.1.5 Parameters:

For CPE that support the InternetGatewayDevice:1 [9] data model:

5.1.1.6 Test Setup:

1. Refer to Common Test Setup for setup steps.

5.1.1.7 Procedure:

1. ACS performs a GetParameterValues RPC on the above parameter to determine its value.
2. ACS performs a SetParameterValues RPC on the above parameter for a value that is different than the value returned in step 1.
3. ACS performs a FactoryReset RPC to the CPE.
4. Allow the ACS to perform bootstrap procedures on the CPE, if it is configured to do so.
5. ACS performs a GetParameterValues RPC on the above parameter.

5.1.1.8 Test Metrics:

1. Validate that the FactoryReset successfully occurs via FactoryResetResponse and a “0 BOOTSTRAP” Inform RPC is sent by CPE.
2. Validate that the value of the above parameter returned in step 5 is different than it was set to in Procedure step 2.

5.1.2 Time Setting (Device:2 Only)

5.1.2.1 Purpose:

5.1.2.2 References:

5.1.2.3 Profiles:

5.1.2.4 Optional Features:

5.1.2.5 Parameters:

5.1.2.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have two NTP servers accessible on the WAN.
3. Have the ability to block data communications to the NTP Servers.

5.1.2.7 Procedure:

1. ACS performs a SetParameterValues RPC on the NTPServer1, NTPServer2, TimeZone, and Enable parameters.
2. Test setup blocks NTPServer2 address.
3. CPE is rebooted.
4. ACS performs a GetParameterValues RPC on the Status and CurrentLocalTime parameters.
5. Test setup blocks NTPServer1 address and unblocks NTPServer2 address
6. CPE is rebooted
7. ACS performs a GetParameterValues RPC on the Status and LocalTime parameters.

5.1.2.8 Test Metrics:

1. Validate that the SetParameterValuesResponse is received successfully for setting both NTPServer1 and NTPServer2.
2. After the reboot, validate that the Traffic Analyzer shows CPE communication with NTPServer1.
3. Validate that the time is set on the CPE via the GetParameterValuesResponse.
4. After the reboot, validate that the Traffic Analyzer shows CPE communication with NTPServer2.
5. Validate that the time is set on the CPE via the GetParameterValuesResponse.

5.1.3 Time Setting (InternetGatewayDevice:1 Only)

5.1.3.1 Purpose:

5.1.3.2 References:

5.1.3.3 Profiles:

5.1.3.4 Optional Features:

5.1.3.5 Parameters:

5.1.3.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have two NTP servers accessible on the WAN.
3. Have the ability to block data communications to the NTP Servers.

5.1.3.7 Procedure:

1. ACS performs a SetParameterValues RPC on the NTPServer1, NTPServer2, and TimeZone parameters.
2. Test setup blocks NTPServer2 address.
3. CPE is rebooted.
4. ACS performs a GetParameterValues RPC on the LocalTime parameters.
5. Test setup blocks NTPServer1 address and unblocks NTPServer2 address
6. CPE is rebooted
7. ACS performs a GetParameterValues RPC on the CurrentLocalTime parameter.

5.1.3.8 Test Metrics:

1. Validate that the SetParameterValuesResponse is received successfully for setting both NTPServer1 and NTPServer2.
2. After the reboot, validate that the Traffic Analyzer shows CPE communication with NTPServer1.
3. Validate that the time is set on the CPE via the GetParameterValuesResponse.
4. After the reboot, validate that the Traffic Analyzer shows CPE communication with NTPServer2.
5. Validate that the time is set on the CPE via the GetParameterValuesResponse.

5.1.4 Firmware Download

5.1.4.1 Purpose:

5.1.4.2 References:

5.1.4.3 Profiles:

5.1.4.4 Optional Features:

5.1.4.5 Parameters:

For CPE that support the InternetGatewayDevice:1 data model:

5.1.4.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a file server accessible on the WAN with known credentials.
3. Place firmware to download on the file server.

5.1.4.7 Procedure:

1. ACS issues a GetParameterValues RPC on the CPE SoftwareVersion parameter listed in the parameters section to learn the CPEs current software version
2. ACS issues a Download RPC to the CPE with the following arguments set

Allow the CPE to complete firmware download from the file server, apply the firmware, and reboot if necessary After CPE issues a “7 TRANSER COMPLETE” event code, the ACS issues a GetParameterValues RPC on the on the CPE SoftwareVersion parameter listed in the parameters section to learn the CPEs new software version

5.1.4.8 Test Metrics:

1. Ensure the software version reported by the CPE before the firmware download is different than the software version reported by the CPE after the firmware download.

5.1.5 GetRPCMethods

5.1.5.1 Purpose:

5.1.5.2 References:

5.1.5.3 Profiles:

5.1.5.4 Optional Features:

5.1.5.5 Parameters:

5.1.5.6 Test Setup:

1. Refer to Common Test Setup for setup steps.

5.1.5.7 Procedure:

1. ACS schedules a GetRPCMethods RPC on the CPE.
2. Allow the CPE to respond with the GetRPCMethodsResponse

5.1.5.8 Test Metrics:

1. Verify that the CPE responds to the GetRPCMethods RPC
2. Verify that the GetRPCMethodsResponse contains all mandatory RPCs

5.1.6 Configuration Backup and Restoration

5.1.6.1 Purpose:

5.1.6.2 References:

5.1.6.3 Profiles:

5.1.6.4 Optional Features:

5.1.6.5 Parameters:

For CPE that support the InternetGatewayDevice:1 data model:

5.1.6.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a file server accessible on the WAN with known credentials that can accept uploads and downloads.
3. If CPE supports “3 Vendor Configuration File <i>” Upload FileType, perform a GetParameterValues RPC on the partial path above to determine the correct instance number to upload.

5.1.6.7 Procedure:

1. ACS performs a GetParameterValues RPC on PeriodicInformInterval to determine its value.
2. ACS schedules an Upload RPC on the CPE with the parameters above.
3. Allow the upload to complete.
4. ACS performs a SetParameterValues RPC on PeriodicInformInterval for a value that is different than the value returned in step 1.
5. Wait for the CPE to send 2 Periodic Informs and check the interval between them.
6. ACS schedules a download RPC on the CPE with the parameters above.
7. Allow the download to complete.
8. Wait for the CPE to send 2 Periodic Informs and check the interval between them.

5.1.6.8 Test Metrics:

1. Verify that the CPE responds to the Upload RPC with an UploadResponse
2. Verify that the DUT uploaded the configuration to the server
3. Verify that the CPE sends Periodic Informs at the interval set in Step 4.
4. Verify that the CPE responds to the Download RPC with a DownloadResponse
5. Verify that the CPE sends Periodic Informs at the interval returned from the device in Step 1.

5.1.7 PPP Interface Change

5.1.7.1 Purpose:

5.1.7.2 References:

5.1.7.3 Profiles:

5.1.7.4 Optional Features:

5.1.7.5 Parameters:

For CPE that support the InternetGatewayDevice:1 data model:

5.1.7.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Setup two valid sets of credentials on the PPP server, username1/password1 and username2/password2

5.1.7.7 Procedure:

1. ACS determines the instance number of the PPP interface.
2. ACS performs a GetParameterValues RPC on the CPE for Username and Password.
3. Allow the CPE to respond with a GetParameterValuesResponse
4. ACS performs a SetParameterValues RPC on the CPE for Username, Password, and Reset, using the second set of valid credentials, username2/password2.
5. Allow the CPE to respond with a SetParameterValuesResponse and establish a new PPP session.
6. ACS performs a GetParameterValues RPC on the CPE for Username and Password.
7. Allow the CPE to respond with a GetParameterValuesResponse.
8. Reboot the device.
9. ACS performs a GetParameterValues RPC on the CPE for Username and Password.

5.1.7.8 Test Metrics:

1. Validate that the CPE sends a GetParameterValuesResponse in step 3 containing Username=username1 and Password=<empty string>.
2. Validate that the CPE sends a SetParameterValuesResponse in step 5 with Status=1 and that the CWMP session is successfully ended.
3. Validate that the CPE successfully establishes a new PPP session using the new credentials.
4. Validate that the CPE sends a GetParameterValuesResponse in step 7 containing Username=username2 and Password=<empty string>.
5. Validate that the CPE sends a GetParameterValuesResponse in step 9 containing Username=username2 and Password=<empty string>.

5.1.8 DHCP Provisioning

5.1.8.1 Purpose:

5.1.8.2 References:

5.1.8.3 Profiles:

5.1.8.4 Optional Features:

5.1.8.5 Parameters:

5.1.8.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. CPE supports the appropriate DHCP parameters in the parameters section
3. Have a LAN device that can connect to the CPE via DHCP.
4. Have a Network Analyzer to capture traffic between the CPE and LAN device.
5. If the DUT implements the Device:2 root data model, determine whether or not an existing entry exists for the object specified above.

5.1.8.7 Procedure:

1. If the DUT implements the Device:2 root data model, and no entry exists for Device.DHCPv4.Server.Pool.{i}., perform an AddObject RPC on Device.Server.Pool., recording the InstanceNumber value returned in the AddObjectResponse.
2. On the ACS schedule a SetParameterValues RPC on the appropriate Configurable parameters in the Parameters Section, setting the DHCP pool’s minimum and maximum to be completely outside the existing range, if any (for example, by setting the new minimum above the current maximum).
3. Allow the end system to connect to the CPE via DHCP.
4. Perform a reboot of the CPE
5. Allow the end system to connect to the CPE via DHCP

5.1.8.8 Test Metrics:

1. Verify that the SetParameterValuesResponse RPC is correct for all parameters
2. Verify that the end system connects to the CPE within the designated range.
3. Verify that that end system connects to the CPE within the designated range after the reboot

5.1.9 SPV on a Boolean Parameter

5.1.9.1 Purpose:

5.1.9.2 References:

5.1.9.3 Profiles:

5.1.9.4 Optional Features:

5.1.9.5 Parameters:

5.1.9.6 Test Setup:

1. Refer to Common Test Setup for setup steps.

5.1.9.7 Procedure:

1. ACS establishes a session
2. ACS performs a GetParameterValues RPC on the CPE on a Boolean parameter.
3. ACS schedules a SetParameterValues RPC on the CPE, to change the Boolean parameter to the opposite of the value returned in step #2.
4. Allow the CPE to respond with the SetParameterValuesResponse.
5. ACS schedules a GetParameterValues RPC on the CPE, to request the Boolean parameter.
6. Allow the CPE to respond with the GetParameterValuesResponse

5.1.9.8 Test Metrics:

1. Verify that the CPE responds to the SetParameterValues RPC
2. Verify that the SetParameterValuesResponse contains status 0.
3. Verify that the GetParameterValuesResponse contains the changed value.

5.1.10 Encrypted Connection

5.1.10.1 Purpose:

5.1.10.2 References:

5.1.10.3 Profiles:

5.1.10.4 Optional Features:

5.1.10.5 Parameters:

5.1.10.6 Test Setup:

1. Load the appropriate Certificate of Authentication onto the CPE.
2. Have the private portion of the certificate on the ACS.
3. Refer to Common Test Setup for setup steps.

5.1.10.7 Procedure:

1. Allow the CPE to establish an encrypted CWMP session with the ACS.
2. On the ACS schedule a GetParametersValues RPC on the CPE.
3. Allow the CPE to respond with the GetParametersValuesResponse containing the requested parameters.

5.1.10.8 Test Metrics:

1. Verify that the CWMP session is encrypted.
2. Verify that the GetParameterValuesResponse is valid.

5.1.11 GetParameterNames Vendor Specific Parameters

5.1.11.1 Purpose:

5.1.11.2 References:

5.1.11.3 Profiles:

5.1.11.4 Optional Features:

5.1.11.5 Parameters:

5.1.11.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Obtain a list of vendor specific parameters from the vendor

5.1.11.7 Procedure:

1. Allow the CPE to establish an CWMP session with the ACS
2. Schedule a GetParameterNames RPC on the CPE entire data model.

5.1.11.8 Test Metrics:

1. Verify that the ACS can process all vendor specific parameters and objects.

5.1.12 SetParameterValues Vendor Specific Parameters

5.1.12.1 Purpose:

5.1.12.2 References:

5.1.12.3 Profiles:

5.1.12.4 Optional Features:

5.1.12.5 Parameters:

5.1.12.6 Test Setup:

Refer to Common Test Setup for setup steps. Obtain a writable vendor specific parameter, parameter type, and parameter purpose from the vendor.

5.1.12.7 Procedure:

1. ACS performs a GetParameterValues RPC on the parameter in Test Setup #3.
2. ACS performs a SetParameterValues RPC on the parameter in Test Setup #3 for a value that is different than the value returned in Step 1.
3. ACS performs a GetParameterValues RPC on the parameter in Test Setup #3.
4. Reboot the device.
5. ACS performs a GetParameterValues RPC on the parameter in Test Setup #3.

5.1.12.8 Test Metrics:

1. Verify that the SetParameterValues RPC in Step 2 completes and the CPE responds with a correct SetParameterValuesResponse RPC.
2. Verify that the GetParametersValues RPC in Step 3 completes and the CPE responds with a correct GetParameterValuesResponse RPC.
3. Verify that the value in the GetParameterValues in Step 3 matches the value set in Step 2.
4. Verify that the value in the GetParameterValues in Step 5 matches the value set in Step 2.

5.2 Diagnostics

5.2.1 Diagnostics IPPing

5.2.1.1 Purpose:

5.2.1.2 References:

5.2.1.3 Profiles:

5.2.1.4 Optional Features:

5.2.1.5 Parameters:

5.2.1.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a host on the WAN network that can answer pings.
3. Refer to Determine WAN Interface to determine the WAN interface. This will be used for the Interface parameter.

5.2.1.7 Procedure:

1. ACS performs a SetParameterValues RPC on the ping diagnostics parameters in the parameter section above.
2. ACS performs a GetParameterValues on the InternetGatewayDevice.IPPingDiagnostics or Device.IP.Diagnostics.IPPing to determine results of ping test

5.2.1.8 Test Metrics:

1. Verify that the CPE transmitted 3 ICMP Echo Requests to the target Host.
2. Validate that the CPE sends an Inform RPC to the ACS with Event Code “8 DIAGNOSTICS COMPLETE”.
3. Validate that the DiagnosticsState is set to “Complete”.
4. Verify that the SuccessCount and FailureCount match what is seen on the network capture.

5.2.2 Download Diagnostics over HTTP

5.2.2.1 Purpose:

5.2.2.2 References:

5.2.2.3 Profiles:

5.2.2.4 Optional Features:

5.2.2.5 Parameters:

5.2.2.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have an HTTP server and file to perform the download. The file should be big enough for the file transfer to last at least 30 seconds.

5.2.2.7 Procedure:

1. On the ACS schedule a SetParameterValues RPC on the Interface, DownloadURL and DiagnosticsState parameters listed in the parameters section.
2. Allow the CPE to perform the specific diagnostic tests and send an Inform message with an event code of “8 DIAGNOSTICS COMPLETE”.
3. On the ACS schedule a GetParameterValues RPC on the DownloadDiagnostics object.
4. Perform a reboot of the CPE.
5. On the ACS schedule a GetParameterValues RPC on the DownloadDiagnostics object.

5.2.2.8 Test Metrics:

1. Verify that the SetParameterValuesResponse RPC is correct
2. Verify that an Inform message is received with an event code of “8 DIAGNOSTICS COMPLETE”
3. Verify that the GetParameterValuesResponse contains a valid value for the DiagnosticsState parameter.
4. Verify that TestBytesReceived is correct.
5. Verify that EOMTime – BOMTime is within 1 second of the time that the file server reports the transfer took.
6. Verify that the GetParameterValuesResponse contains a valid value for the DiagnosticsState parameter.
   1. If the value is “Completed” verify that the values in the DownloadDiagnostic object are the same as they were before the reboot.
   2. Verify that TotalBytesReceived is within 1% of the measured traffic.

5.2.3 Download Diagnostics over FTP

5.2.3.1 Purpose:

5.2.3.2 References:

5.2.3.3 Profiles:

5.2.3.4 Optional Features:

5.2.3.5 Parameters:

5.2.3.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have an FTP server and file to perform the download. The file should be big enough for the file transfer to last at least 30 seconds.

5.2.3.7 Procedure:

1. On the ACS schedule a SetParameterValues RPC on the Interface, DownloadURL and DiagnosticsState parameters listed in the parameters section.
2. Allow the CPE to perform the specific diagnostic tests and send an Inform message with an event code of “8 DIAGNOSTICS COMPLETE”.
3. On the ACS schedule a GetParameterValues RPC on the DownloadDiagnostics object.
4. Perform a reboot of the CPE.
5. On the ACS schedule a GetParameterValues RPC on the DownloadDiagnostics object.

5.2.3.8 Test Metrics:

1. Verify that the SetParameterValuesResponse RPC is correct
2. Verify that an Inform message is received with an event code of “8 DIAGNOSTICS COMPLETE”
3. Verify that the GetParameterValuesResponse contains a valid value for the DiagnosticsState parameter.
4. Verify that TestBytesReceived is correct.
5. Verify that EOMTime – BOMTime is within 1 second of the time that the file server reports the transfer took.
6. Verify that the GetParameterValuesResponse contains a valid value for the DiagnosticsState parameter.
   1. If the value is “Completed” verify that the values in the DownloadDiagnostic object are the same as they were before the reboot.

5.2.4 Upload Diagnostics over HTTP

5.2.4.1 Purpose:

5.2.4.2 References:

5.2.4.3 Profiles:

5.2.4.4 Optional Features:

5.2.4.5 Parameters:

5.2.4.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have an HTTP server to perform the Upload.
3. Wireshark running between ACS and CPE.

5.2.4.7 Procedure:

1. On the ACS schedule a SetParameterValues RPC on the Interface, UploadURL and DiagnosticsState parameters listed in the parameters section.
2. Allow the CPE to perform the specific diagnostic tests and send an Inform message with an event code of “8 DIAGNOSTICS COMPLETE”.
3. On the ACS schedule a GetParameterValues RPC on the UploadDiagnostics object.
4. Perform a reboot of the CPE
5. On the ACS schedule a GetParameterValues RPC on the UploadDiagnostics object.

5.2.4.8 Test Metrics:

1. Verify that the SetParameterValuesResponse RPC is correct
2. Verify that an Inform message is received with an event code of “8 DIAGNOSTICS COMPLETE”
3. Verify that the GetParameterValuesResponse contains a valid value for the DiagnosticsState parameter.
4. Verify that the test server received a file of TestLengthBytes size.
5. Verify that EOMTime – BOMTime is within 1 second of the time that the file server reports the transfer took.
6. Verify that the GetParameterValuesResponse contains a valid value for the DiagnosticsState parameter.
   1. If the value is “Completed” verify that the values in the UploadDiagnostic object are the same as they were before the reboot.
   2. Verify that TotalBytesSent is within 1% of the measured traffic.

5.2.5 Upload Diagnostics over FTP

5.2.5.1 Purpose:

5.2.5.2 References:

5.2.5.3 Profiles:

5.2.5.4 Optional Features:

5.2.5.5 Parameters:

5.2.5.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have an FTP server to perform the Upload.

5.2.5.7 Procedure:

1. On the ACS schedule a SetParameterValues RPC on the Interface, UploadURL and DiagnosticsState parameters listed in the parameters section.
2. Allow the CPE to perform the specific diagnostic tests and send an Inform message with an event code of “8 DIAGNOSTICS COMPLETE”.
3. On the ACS schedule a GetParameterValues RPC on the UploadDiagnostics object.
4. Perform a reboot of the CPE
5. On the ACS schedule a GetParameterValues RPC on the UploadDiagnostics object.

5.2.5.8 Test Metrics:

1. Verify that the SetParameterValuesResponse RPC is correct
2. Verify that an Inform message is received with an event code of “8 DIAGNOSTICS COMPLETE”
3. Verify that the GetParameterValuesResponse contains a valid value for the DiagnosticsState parameter.
4. Verify that the test server received a file of TestLengthBytes size.
5. Verify that EOMTime – BOMTime is within 1 second of the time that the file server reports the transfer took.
6. Verify that the GetParameterValuesResponse contains a valid value for the DiagnosticsState parameter.
   1. If the value is “Completed” verify that the values in the UploadDiagnostic object are the same as they were before the reboot.

5.2.6 TraceRoute

5.2.6.1 Purpose:

5.2.6.2 References:

5.2.6.3 Profiles:

5.2.6.4 Optional Features:

5.2.6.5 Parameters:

5.2.6.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a host on the WAN network that can answer the CPE’s traceroute mechanism.

5.2.6.7 Procedure:

1. Establish a CWMP session between the CWMP Analyzer and DUT with successful Inform exchanges.
2. Schedule a GetParameterValues RPC on the current WAN interface.
3. Schedule a SetParameterValues RPC on the DUT on the trace route diagnostic parameters listed above.
4. Schedule a GetParameterValues RPC on the DUT on Diagnostic State.
5. Schedule a GetParameterValues RPC on the CPE on the RouteHops table.

5.2.6.8 Test Metrics:

1. The DUT can properly respond to the GetParameterValues request on WAN interface.
2. The DUT is able to properly respond to the SetParameterValues for diagnostics parameter.
3. Verify that the CPE performed the TraceRoute test on the target Host.
4. Validate that the CPE sends an Inform RPC to the ACS with Event Code “8 DIAGNOSTICS COMPLETE”.
5. Validate that the DiagnosticsState is set to “Complete”.
6. Validate that the Entries in the RouteHops table match the traceroute traffic on the WAN.

5.2.7 UDPEcho Test

5.2.7.1 Purpose:

5.2.7.2 References:

5.2.7.3 Profiles:

5.2.7.4 Optional Features:

5.2.7.5 Parameters:

5.2.7.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. UDP client available at source to send UDPEcho packets

5.2.7.7 Procedure:

1. ACS schedules a SetParameterValues RPC on the CPE, setting Enable to false.
2. Allow the CPE to respond with the SetParameterValuesResponse
3. Orderly terminate the session
4. Use the UDP client at source to send n UDP Echo packets to the CPE
5. ACS schedules a SetParameterValues RPC on the CPE, setting the SourceIPAddress and UDPPort that will be used, and setting Enable to true.
6. Allow the CPE to respond with the SetParameterValuesResponse
7. ACS schedules a GetParameterValues RPC on the CPE, reading PacketsReceived and PacketsResponded.
8. Allow the CPE to respond with the GetParameterValuesResponse
9. Orderly terminate the session
10. Use the UDP client at source to send n UDP Echo packets to the CPE
11. ACS schedules a GetParameterValues RPC on the CPE, reading PacketsReceived and PacketsResponded.
12. Allow the CPE to respond with the GetParameterValuesResponse

5.2.7.8 Test Metrics:

1. CPE responds correctly to the various RPCs
2. During step 4, the UPD client receives no response packet
3. During step 7, the counters read have a value of zero
4. During step 10, the UPD client receives n response packets (no loss expected in the closed test network)
5. During step 12, PacketsReceived and PacketsResponded are both n.

5.3 Statistics and Monitoring

5.3.1 Current Interface Configuration (Device:2 Only)

5.3.1.1 Purpose:

5.3.1.2 References:

5.3.1.3 Profiles:

5.3.1.4 Optional Features:

5.3.1.5 Parameters:

5.3.1.6 Test Setup:

1. Refer to Common Test Setup for setup steps.

5.3.1.7 Procedure:

1. On the ACS schedule a GetParameterValues RPC for the InterfaceStack on the CPE.
2. Allow the CPE to respond with a GetParameterValuesResponse
3. On the ACS schedule a GetParameterValues on each interface returned in the InterfaceStack.

5.3.1.8 Test Metrics:

1. Verify that the CPE responds to the GetParameterValues RPC.
2. Verify that the InterfaceStack table refers to objects that exist.
3. Verify that each entry in the InterfaceStack table corresponds to the correct LowerLayer.
4. Verify Enable, IPAddress and SubnetMask or MACAddress from all Interface objects.

5.3.2 Connected LAN Devices (InternetGatewayDevice:1 Only)

5.3.2.1 Purpose:

5.3.2.2 References:

5.3.2.3 Profiles:

5.3.2.4 Optional Features:

5.3.2.5 Parameters:

5.3.2.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have one LAN device connected on each interface that the CPE supports.
3. Have a Network Analyzer to capture traffic between the CPE and each LAN device.

5.3.2.7 Procedure:

1. Connect each LAN device so it is configured with an address.
2. On the ACS schedule a GetParameterValues RPC for InternetGatewayDevice.LANDevice. on the CPE.
3. Allow the CPE to respond with the GetParameterValues

5.3.2.8 Test Metrics:

1. Verify that the CPE responds to the GetParameterValues RPC
2. Verify that the Layer2Interface parameter matches the InterfaceType parameter.
3. Verify that the values of the above parameters returned match each LAN device connected to the CPE.
4. Verify that the Active parameter is set to “true”.

5.3.3 Connected LAN Devices – Wi-Fi (Device:2 Only)

5.3.3.1 Purpose:

5.3.3.2 References:

5.3.3.3 Profiles:

5.3.3.4 Optional Features:

5.3.3.5 Parameters:

5.3.3.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have one LAN device connected on the Wi-Fi interface of the CPE.
3. Have a Network Analyzer to capture traffic between the CPE and the LAN device.

5.3.3.7 Procedure:

1. Connect the LAN device so it is configured with an address.
2. On the ACS schedule a GetParameterValues RPC for Device.Hosts. on the CPE.
3. Allow the CPE to respond
4. On the ACS schedule a GetParameterValues RPC for the AssociatedDevice returned.
5. Allow the CPE to respond

5.3.3.8 Test Metrics:

1. Verify that the CPE responds to the GetParameterValues RPC
2. Verify that the values of the above parameters returned match the LAN device
3. Verify that the Active parameter is set to “true”
4. Verify that the value of SignalStrength is within the valid range
5. Verify that the value of Retransmissions is within the valid range

5.3.4 Connected LAN Devices – DHCP (Device:2 Only)

5.3.4.1 Purpose:

5.3.4.2 References:

5.3.4.3 Profiles:

5.3.4.4 Optional Features:

5.3.4.5 Parameters:

5.3.4.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have one LAN device connected to the CPE.
3. Have a Network Analyzer to capture traffic between the CPE and the LAN device.

5.3.4.7 Procedure:

1. Connect each LAN device so it is configured to use DHCP for its addressing information
2. On the ACS schedule a GetParameterValues RPC for Device.Hosts. on the CPE
3. Allow the CPE to respond
4. On the ACS schedule a GetParameterValues RPC for all the AssociatedDevices returned
5. Allow the CPE to respond
6. On the ACS schedule a GetParameterValues RPC for all the DHCPClient values returned

5.3.4.8 Test Metrics:

1. Verify that the CPE responds to the GetParameterValues RPC
2. Verify that the values of the above parameters returned match the LAN device
3. Verify that Option Tag 61 is the DHCP client id
4. Verify that the Active parameter is set to “true”

5.3.5 Device Connect/Disconnect Notification Test

5.3.5.1 Purpose:

5.3.5.2 References:

5.3.5.3 Profiles:

5.3.5.4 Optional Features:

5.3.5.5 Parameters:

5.3.5.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have one device connectable on each interface that the CPE supports.
3. Have a Network Analyzer to capture traffic between the CPE and each LAN device.

5.3.5.7 Procedure:

1. On the ACS schedule a SetParameterAttributes RPC with active notification on the CPE for HostNumberOfEntries
2. Connect a device to the CPE on each interface the CPE supports.
3. Verify that the ACS receives a notification containing the HostNumberOfEntries parameter.
4. On the ACS schedule a SetParameterAttributes RPC with active notification on the CPE for each host object’s active parameter (Host.{i}.Active).
5. Disconnect a device from the CPE
6. Verify that the ACS receives a notification containing the Active parameter.
7. Schedule a GetParameterNames RPC on the CPE for Host.

5.3.5.8 Test Metrics:

1. Verify that the CPE responds to the SetParameterAttributes RPC
2. Verify the CPE sends an Inform containing a “4 VALUE CHANGE” for each device that is connected to the CPE. Verify the ParameterList includes the HostNumberOfEntries parameter.
3. Verify the CPE sends an Inform containing a “4 VALUE CHANGE” when the device is disconnected from the CPE. Verify the ParameterList includes the Host.{i}.Active parameter. If the CPE does not list inactive host, verify that the GetParameterNames does not include the Host instance of the inactive device.

5.4 Port Mappings

5.4.1 Create a Port Mapping – Single Interface

5.4.1.1 Purpose:

5.4.1.2 References:

5.4.1.3 Profiles:

5.4.1.4 Optional Features:

5.4.1.5 Parameters:

The following parameters are required to be implemented by the CPE for this test:

For devices that support the Device:2 root data model:

For devices that support the InternetGatewayDevice:1 root data model:

5.4.1.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a LAN device connected to the LAN side of the CPE
3. Have a device connected on the WAN side of the CPE that can send UDP traffic.
4. ACS ensures that the port mapping being created doesn’t already exist by retrieving all instances of the PortMapping table via a GetParamterValues RPC
   1. If PortMapping already exists, remove it via the DeleteObject RPC
   2. Refer to Determine WAN Interface to determine the WAN interface.
   3. Have a Network Analyzer to capture traffic between the CPE and the LAN device.

5.4.1.7 Procedure:

1. ACS performs an AddObject RPC to create a new PortMapping instance.
2. ACS performs a SetParameterValues RPC on the parameters above using the returned PortMapping instance number.
3. ACS performs a GetParameterValues RPC on the PortMapping instance.
4. Reboot the CPE.
5. ACS performs a GetParameterValues RPC on the PortMapping instance.
6. Send UDP traffic to the CPE’s IP Address with destination port 1400 from the WAN side of the CPE.

5.4.1.8 Test Metrics:

1. Validate that the values of the PortMapping instance match the values that were set.
2. Validate that the CPE retains the PortMapping instance and configuration across a reboot.
3. Validate that the UDP traffic is forwarded to the LAN Device’s IP address, port 1401.

5.4.2 Create a Port Mapping – All Interfaces (Device:2 only)

5.4.2.1 Purpose:

5.4.2.2 References:

5.4.2.3 Profiles:

5.4.2.4 Optional Features:

5.4.2.5 Parameters:

The following parameters are required to be implemented by the CPE for this test:

5.4.2.6 Test Setup:

1. Refer to Common Test Setup for setup steps. Have a LAN device connected to the LAN side of the CPE Have a device connected on the WAN side of the CPE that can send UDP traffic. ACS ensures that the port mapping being created doesn’t already exist by retrieving all instances of the PortMapping table via a GetParamterValues RPC
   1. If PortMapping already exists, remove it via the DeleteObject RPC
   2. Have a Network Analyzer to capture traffic between the CPE and the LAN device.

5.4.2.7 Procedure:

1. ACS performs an AddObject RPC to create a new PortMapping instance.
2. ACS performs a SetParameterValues RPC on the parameters above using the returned PortMapping instance number.
3. ACS performs a GetParameterValues RPC on the PortMapping instance.
4. Send UDP traffic to the CPE’s IP Address with destination port 1400 from the WAN side of the CPE.

5.4.2.8 Test Metrics:

1. Validate that the values of the PortMapping instance match the values that were set.
2. Validate that the UDP traffic is forwarded to the LAN Device’s IP address, port 1401.

5.4.3 Create a Port Mapping – External Port Range

5.4.3.1 Purpose:

5.4.3.2 References:

5.4.3.3 Profiles:

5.4.3.4 Optional Features:

5.4.3.5 Parameters:

For devices that support the Device:2 root data model:

For devices that support the InternetGatewayDevice:1 root data model:

5.4.3.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a LAN device connected to the LAN side of the CPE
3. Have a device connected on the WAN side of the CPE that can send UDP traffic.
4. ACS ensures that the port mapping being created doesn’t already exist by retrieving all instances of the PortMapping table via a GetParamterValues RPC
   1. If PortMapping already exists, remove it via the DeleteObject RPC.
   2. Refer to Determine WAN Interface to determine the WAN interface.
   3. Have a Network Analyzer to capture traffic between the CPE and the LAN device.

5.4.3.7 Procedure:

1. ACS performs an AddObject RPC to create a new PortMapping instance.
2. ACS performs a SetParameterValues RPC on the parameters above using the returned PortMapping instance number.
3. ACS performs a GetParameterValues RPC on the PortMapping instance.
4. Send UDP traffic to the CPE’s IP Address with destination port 1400 from the WAN side of the CPE.
5. Send UDP traffic to the CPE’s IP Address with destination port 1403 from the WAN side of the CPE.

5.4.3.8 Test Metrics:

1. Validate that the values of the PortMapping instance match the values that were set.
2. Validate that the UDP traffic to port 1400 is forwarded to the LAN Device’s IP address, port 1401.
3. Validate that the UDP traffic to port 1403 is forwarded to the LAN Device’s IP address, port 1401.

5.4.4 Create a Port Mapping – Lease Duration > 0

5.4.4.1 Purpose:

5.4.4.2 References:

5.4.4.3 Profiles:

5.4.4.4 Optional Features:

5.4.4.5 Parameters:

For devices that support the Device:2 root data model:

For devices that support the InternetGatewayDevice:1 root data model:

5.4.4.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a LAN device connected to the LAN side of the CPE
3. Have a device connected on the WAN side of the CPE that can send UDP traffic.
4. ACS ensures that the port mapping being created doesn’t already exist by retrieving all instances of the PortMapping table via a GetParamterValues RPC
   1. If PortMapping already exists, remove it via the DeleteObject RPC.
5. Refer to Determine WAN Interface to determine the WAN interface.
6. Have a Network Analyzer to capture traffic between the CPE and the LAN device.

5.4.4.7 Procedure:

1. ACS performs an AddObject RPC to create a new PortMapping instance.
2. ACS performs a SetParameterValues RPC on the parameters above using the returned PortMapping instance number.
3. ACS performs a GetParameterValues RPC on the PortMapping instance.
4. Send UDP traffic to the CPE’s IP Address with destination port 1400 from the WAN side of the CPE.
5. Wait for the PortMapping Instance to expire.
6. Send UDP traffic to the CPE’s IP Address with destination port 1400 from the WAN side of the CPE.

5.4.4.8 Test Metrics:

1. Validate that the values of the PortMapping instance match the values that were set.
2. Validate that the UDP traffic to port 1400 is forwarded to the LAN Device’s IP address, port 1401.
3. Validate that the UDP traffic to port 1400 is NOT forwarded to the LAN Device after the PortMapping Instance expires.

5.4.5 Create a Port Mapping – Remote Host Restriction

5.4.5.1 Purpose:

5.4.5.2 References:

5.4.5.3 Profiles:

5.4.5.4 Optional Features:

5.4.5.5 Parameters:

For devices that support the Device:2 root data model:

For devices that support the InternetGatewayDevice:1 root data model:

5.4.5.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a LAN device connected to the LAN side of the CPE
3. Have devices connected on the WAN side of the CPE: WANDevice1, and WANDevice2 that can both send UDP traffic.
4. ACS ensures that the port mapping being created doesn’t already exist by retrieving all instances of the PortMapping table via a GetParamterValues RPC
   1. If PortMapping already exists, remove it via the DeleteObject RPC.
   2. Refer to Determine WAN Interface to determine the WAN interface.
   3. Have a Network Analyzer to capture traffic between the CPE and the LAN device.

5.4.5.7 Procedure:

1. ACS performs an AddObject RPC to create a new PortMapping instance.
2. ACS performs a SetParameterValues RPC on the parameters above using the returned PortMapping instance number.
3. ACS performs a GetParameterValues RPC on the PortMapping instance.
4. Send UDP traffic to the CPE’s IP Address with destination port 1400 from WANDevice1.
5. Send UDP traffic to the CPE’s IP Address with destination port 1400 from WANDevice2

5.4.5.8 Test Metrics:

1. Validate that the values of the PortMapping instance match the values that were set.
2. Validate that the UDP traffic to port 1400 from WANDevice1 is forwarded to the LAN Device’s IP address, port 1401.
3. Validate that the UDP traffic to port 1400 from WANDevice2 is NOT forwarded to the LAN Device.

5.4.6 Create a Port Mapping – Multiple Entries – Precedence Rules

5.4.6.1 Purpose:

5.4.6.2 References:

5.4.6.3 Profiles:

5.4.6.4 Optional Features:

5.4.6.5 Parameters:

For devices that support the Device:2 root data model:

For devices that support the InternetGatewayDevice:1 root data model:

5.4.6.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a LAN device connected to the LAN side of the CPE
3. Have two devices connected on the WAN side of the CPE: WANDevice1, and WANDevice2 that can both send UDP traffic.
4. ACS ensures that the port mapping being created doesn’t already exist by retrieving all instances of the PortMapping table via a GetParamterValues RPC
   1. If PortMapping already exists, remove it via the DeleteObject RPC.
   2. Refer to Determine WAN Interface to determine the WAN interface.
   3. Have a Network Analyzer to capture traffic between the CPE and the LAN device.

5.4.6.7 Procedure:

1. ACS performs an AddObject RPC to create a new PortMapping instance.
2. ACS performs a SetParameterValues RPC on the parameters above using the returned PortMapping instance number. ExternalPort is 0, InternalPort is 1401.
3. ACS performs an AddObject RPC to create a new PortMapping instance.
4. ACS performs a SetParameterValues RPC on the parameters above using the returned PortMapping instance number. ExternalPort is 1400, InternalPort is 1402.
5. ACS performs a GetParameterValues RPC on the PortMapping instance.
6. Send UDP traffic to the CPE’s IP Address with destination port 1399 from WANDevice1.
7. Send UDP traffic to the CPE’s IP Address with destination port 1400 from WANDevice2.

5.4.6.8 Test Metrics:

1. Validate that the values of the PortMapping instance match the values that were set.
2. Validate that the UDP traffic to port 1399 from WANDevice1 is forwarded to the LAN Device’s IP address, port 1401.
3. Validate that the UDP traffic to port 1400 from WANDevice2 is forwarded to the LAN Device’s IP address, port 1402.

5.4.7 Modify a Port Mapping

5.4.7.1 Purpose:

5.4.7.2 References:

5.4.7.3 Profiles:

5.4.7.4 Optional Features:

5.4.7.5 Parameters:

For devices that support the Device:2 root data model:

For devices that support the InternetGatewayDevice:1 root data model:

5.4.7.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a LAN device connected to the LAN side of the CPE
3. Have a device connected on the WAN side of the CPE that can send UDP traffic.
4. ACS ensures that the port mapping being created doesn’t already exist by retrieving all instances of the PortMapping table via a GetParamterValues RPC
   1. If PortMapping already exists, remove it via the DeleteObject RPC.
   2. Refer to Determine WAN Interface to determine the WAN interface.
   3. Have a Network Analyzer to capture traffic between the CPE and the LAN device.

5.4.7.7 Procedure:

1. ACS performs an AddObject RPC to create a new PortMapping instance.
2. ACS performs a SetParameterValues RPC on the parameters above using the returned PortMapping instance number. ExternalPort is 1400, InternalPort is 1401.
3. Send UDP traffic to the CPE’s IP Address with destination port 1400 from the WAN side of the CPE.
4. ACS performs a SetParameterValues RPC on the parameters above using the returned PortMapping instance number. ExternalPort is 1401, InternalPort is 1402.
5. ACS performs a GetParameterValues RPC on the PortMapping instance.
6. Send UDP traffic to the CPE’s IP Address with destination port 1401 from the WAN side of the CPE.

5.4.7.8 Test Metrics:

1. Validate that the UDP traffic to port 1400 is forwarded to the LAN Device’s IP address, port 1401.
2. Validate that the values of the PortMapping instance match the values that were set.
3. Validate that the UDP traffic to port 1401 is forwarded to the LAN Device’s IP address, port 1402.

5.4.8 Delete a Port Mapping

5.4.8.1 Purpose:

5.4.8.2 References:

5.4.8.3 Profiles:

5.4.8.4 Optional Features:

5.4.8.5 Parameters:

The following parameters are required to be implemented by the CPE for this test:

For devices that support the Device:2 root data model:

For devices that support the InternetGatewayDevice:1 root data model:

5.4.8.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a LAN device connected to the LAN side of the CPE
3. Have a device connected on the WAN side of the CPE that can send UDP traffic.
4. ACS ensures that the port mapping being altered already exists by retrieving all instances of the PortMapping table via a GetParamterValues RPC
   1. If PortMapping does NOT already exist, add it via the DeleteObject/SetParameterValues RPC: see “Create a PortMapping (single interface)” test for procedures
   2. Have a Network Analyzer to capture traffic between the CPE and the LAN device.

5.4.8.7 Procedure:

1. Send UDP traffic to the CPE’s IP Address with destination port 1400 from the WAN side of the CPE.
2. ACS performs a DeleteObject RPC on the PortMapping Instance.
3. ACS validates that the PortMapping entry no longer exists by retrieving all instances of the PortMapping table via a GetParamterValues RPC
4. Send UDP traffic to the CPE’s IP Address with destination port 1400 from the WAN side of the CPE.

5.4.8.8 Test Metrics:

1. Validate that the UDP traffic to port 1400 is forwarded to the LAN Device’s IP address, port 1401.
2. Validate that the PortMapping Instance no longer exists in the table.
3. Validate that the UDP traffic to port 1400 is NOT forwarded to the LAN Device after the PortMapping has been deleted.

5.4.9 Create a Port Mapping – TCP

5.4.9.1 Purpose:

5.4.9.2 References:

5.4.9.3 Profiles:

5.4.9.4 Optional Features:

5.4.9.5 Parameters:

The following parameters are required to be implemented by the CPE for this test:

For devices that support the Device:2 root data model:

For devices that support the InternetGatewayDevice:1 root data model:

5.4.9.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a LAN device connected to the LAN side of the CPE
3. Have a device connected on the WAN side of the CPE that can send TCP traffic.
4. ACS ensures that the port mapping being created doesn’t already exist by retrieving all instances of the PortMapping table via a GetParamterValues RPC
   1. If PortMapping already exists, remove it via the DeleteObject RPC
   2. Refer to Determine WAN Interface to determine the WAN interface.
   3. Have a Network Analyzer to capture traffic between the CPE and the LAN device.

5.4.9.7 Procedure:

1. ACS performs an AddObject RPC to create a new PortMapping instance.
2. ACS performs a SetParameterValues RPC on the parameters above using the returned PortMapping instance number.
3. ACS performs a GetParameterValues RPC on the PortMapping instance.
4. Reboot the CPE.
5. ACS performs a GetParameterValues RPC on the PortMapping instance.
6. Send TCP traffic to the CPE’s IP Address with destination port 1400 from the WAN side of the CPE.

5.4.9.8 Test Metrics:

1. Validate that the values of the PortMapping instance match the values that were set.
2. Validate that the CPE retains the PortMapping instance and configuration across a reboot.
3. Validate that the TCP traffic is forwarded to the LAN Device’s IP address, port 1401.

5.5 Advanced Firewall

5.5.1 Default Policy (Device:2 Only)

5.5.1.1 Purpose:

5.5.1.2 References:

5.5.1.3 Profiles:

5.5.1.4 Optional Features:

5.5.1.5 Parameters:

5.5.1.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a device that can send and receive TCP and UDP connections connected to the LAN side of the CPE (End Device)
3. Have a device that can send and receive TCP and UDP connections connected on the WAN side of the CPE (WAN Device)
4. Have a Network Analyzer to capture traffic between the CPE and the End Device.

5.5.1.7 Procedure:

1. Configure ACS to send an AddObject RPC for Device.Firewall.Level and record the returned instance number.

2. Configure ACS to send a GetParameterValues RPC for Device.Firewall.Level.{i}.Chain.

3. Configure ACS to send an AddObject RPC for Device.Firewall.Chain.{i}.Rule using the path returned in step 2 and record the returned instance number.

4. ACS performs a SetParameterValues RPC on the parameters above except Device.Firewall.Enable using the returned instance numbers from steps 1-3.

5. ACS enables the Firewall by sending a SetParameterValues RPC for Device.Firewall.Enable with the value set to “true.”

6. End Device attempts to open a TCP connection with WAN Device.

7. WAN Device attempts to open a TCP connection with End Device.

8. ACS configures the Firewall by sending a SetParameterValues RPC with following Name/Value pairs:

   Device.Firewall.Level.{i}.
   DefaultPolicy	Drop

9. End Device attempts to open a TCP connection WAN Device.

10. WAN Device attempts to open a TCP connection with End Device.

5.5.1.8 Test Metrics:

1. In Step 6, CPE forwards traffic to the WAN side.
2. In Step 7, CPE forwards traffic to the LAN side.
3. In Step 9, CPE does not forward traffic to the WAN side.
4. In Step 10, CPE does not forward traffic to the LAN side.

5.5.2 Deny/Allow Outbound Protocols (Device:2 Only)

5.5.2.1 Purpose:

5.5.2.2 References:

5.5.2.3 Profiles:

5.5.2.4 Optional Features:

5.5.2.5 Parameters:

5.5.2.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Refer to Determine WAN Interface to determine the WAN interface.
3. Device that can send and receive TCP and UDP connections connected to the LAN side of the CPE (End Device)
4. Device that can send and receive TCP and UDP connections connected on the WAN side of the CPE (WAN Device)
5. Have a Network Analyzer to capture traffic between the CPE and the End Device.

5.5.2.7 Procedure:

1. Configure ACS to send an AddObject RPC for Device.Firewall.Level and record the returned instance number.

2. Configure ACS to send a GetParameterValues RPC for Device.Firewall.Level.{i}.Chain.

3. Configure ACS to send an AddObject RPC for Device.Firewall.Chain.{i}.Rule using the path returned in step 2 and record the returned instance number.

4. ACS performs a SetParameterValues RPC on the following parameters using the instance numbers returned in steps 1-3.

   Device.Firewall.
   Config	Advanced
   AdvancedLevel	Device.Firewall.Level.{i}.

   Device.Firewall.Level.{i}.
   Chain	Returned from device
   DefaultPolicy	Drop

   Device.Firewall.Chain.{i}.Rule.{i}.
   Target	Accept
   DestIP	<Unused IP Address>
   SourceIP	<Unused IP Address>

5. ACS enables the Firewall by sending a SetParameterValues RPC for Device.Firewall.Enable with the value set to “true.”

6. End Device attempts to open a TCP connection with WAN Device.

7. End Device attempts to open a UDP connection with WAN Device.

8. Configure ACS to send an AddObject RPC for Device.Firewall.Chain.{i}.Rule. and record the returned instance number.

9. ACS Configures the new Firewall Rule by sending a SetParameterValues RPC with the following name/value pairs using the instance number returned in step 8.

   Device.Firewall.Chain.{i}.
   Enable	true

   Device.Firewall.Chain.{i}.Rule.{i}.
   Target	Accept
   DestInterface	Default WAN Interface
   Protocol	6 (TCP)

10. End Device attempts to open a TCP connection with WAN Device.

11. End Device attempts to open a UDP connection with WAN Device.

12. Configure ACS to send an AddObject RPC for Device.Firewall.Chain.{i}.Rule. and record the returned instance number.

13. ACS Configures the new Firewall Rule by sending a SetParameterValues RPC with the following name/value pairs using the instance number returned in step 12.

    Device.Firewall.Chain.{i}.
    Enable	true

    Device.Firewall.Chain.{i}.Rule.{i}.
    Target	Accept
    DestInterface	Default WAN Interface
    Protocol	17 (UDP)

14. End Device attempts to open a TCP connection with WAN Device.

15. End Device attempts to open a UDP connection with WAN Device.

5.5.2.8 Test Metrics:

1. In Step 6, CPE does not forward TCP traffic to the WAN side.
2. In Step 7, CPE does not forward UDP traffic to the WAN side.
3. In Step 10, CPE forwards TCP traffic to the WAN side.
4. In Step 11, CPE does not forward UDP traffic to the WAN side.
5. In Step 14, CPE forwards TCP traffic to the WAN side.
6. In Step 15, CPE forwards UDP traffic to the WAN side.

5.5.3 Deny/Allow Outbound Ports (Device:2 Only)

5.5.3.1 Purpose:

5.5.3.2 References:

5.5.3.3 Profiles:

5.5.3.4 Optional Features:

5.5.3.5 Parameters:

5.5.3.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Refer to Determine WAN Interface to determine the WAN interface.
3. Device that can send and receive TCP and UDP connections connected to the LAN side of the CPE (End Device)
4. Device that can send and receive TCP and UDP connections connected on the WAN side of the CPE (WAN Device)
5. Have a Network Analyzer to capture traffic between the CPE and the End Device.

5.5.3.7 Procedure:

1. Configure ACS to send an AddObject RPC for Device.Firewall.Level and record the returned instance number.

2. Configure ACS to send a GetParameterValues RPC for Device.Firewall.Level.{i}.Chain.

3. Configure ACS to send an AddObject RPC for Device.Firewall.Chain.{i}.Rule using the path returned in step 2 and record the returned instance number.

4. ACS performs a SetParameterValues RPC on the following parameters using the instance numbers returned in steps 1-3.

   Device.Firewall.
   Config	Advanced
   AdvancedLevel	Device.Firewall.Level.{i}.

   Device.Firewall.Level.{i}.
   Chain	Returned from device
   DefaultPolicy	Drop

   Device.Firewall.Chain.{i}.Rule.{i}.
   Target	Accept
   DestIP	<Unused IP Address>
   SourceIP	<Unused IP Address>

5. ACS enables the Firewall by sending a SetParameterValues RPC for Device.Firewall.Enable with the value set to “true.”

6. End Device attempts to open a TCP connection, destination port 80, with WAN Device.

7. End Device attempts to open a TCP connection, destination port 443, with WAN Device.

8. Configure ACS to send an AddObject RPC for Device.Firewall.Chain.{i}.Rule and record the returned instance number.

9. ACS Configures the new Firewall Rule by sending a SetParameterValues RPC with the following name/value pairs using the instance number returned in step 8.

   Device.Firewall.Chain.{i}.
   Enable	true

   Device.Firewall.Chain.{i}.Rule.{i}.
   Target	Accept
   DestInterface	Default WAN Interface
   Protocol
   DestPort	80

10. End Device attempts to open a TCP connection, destination port 80, with WAN Device.

11. End Device attempts to open a TCP connection, destination port 443, with WAN Device.

12. Configure ACS to send an AddObject RPC for Device.Firewall.Chain.{i}.Rule and record the returned instance number.

13. ACS Configures the new Firewall Rule by sending a SetParameterValues RPC with the following name/value pairs using the instance number returned in step 12.

    Device.Firewall.Chain.{i}.
    Enable	true

    Device.Firewall.Chain.{i}.Rule.{i}.
    Target	Accept
    DestInterface	Default WAN Interface
    Protocol
    DestPort	443

14. End Device attempts to open a TCP connection, destination port 80, with WAN Device.

15. End Device attempts to open a TCP connection, destination port 443, with WAN Device.

5.5.3.8 Test Metrics:

1. In Step 6, CPE does not forward TCP traffic with destination port 80 to the WAN side.
2. In Step 7, CPE does not forward TCP traffic with destination port 443 to the WAN side.
3. In Step 10, CPE forwards TCP traffic with destination port 80 to the WAN side.
4. In Step 11, CPE does not forward TCP traffic with destination port 443to the WAN side.
5. In Step 14, CPE forwards TCP traffic with destination port 80 to the WAN side.
6. In Step 15, CPE forwards TCP traffic with destination port 443 to the WAN side.

5.5.4 Deny/Allow Source IP Address (Device:2 Only)

5.5.4.1 Purpose:

5.5.4.2 References:

5.5.4.3 Profiles:

5.5.4.4 Optional Features:

5.5.4.5 Parameters:

5.5.4.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Refer to Determine WAN Interface to determine the WAN interface.
3. Two Devices that can send and receive TCP and UDP connections connected to the LAN side of the CPE (End Device 1 and End Device 2)
4. Device that can send and receive TCP and UDP connections connected on the WAN side of the CPE (WAN Device)
5. Have a Network Analyzer to capture traffic between the CPE and the End Device.

5.5.4.7 Procedure:

1. Configure ACS to send an AddObject RPC for Device.Firewall.Level and record the returned instance number.

2. Configure ACS to send a GetParameterValues RPC for Device.Firewall.Level.{i}.Chain.

3. Configure ACS to send an AddObject RPC for Device.Firewall.Chain.{i}.Rule using the path returned in step 2 and record the returned instance number.

4. ACS performs a SetParameterValues RPC on the following parameters using the instance numbers returned in steps 1-3.

   Device.Firewall.
   Config	Advanced
   AdvancedLevel	Device.Firewall.Level.{i}.

   Device.Firewall.Level.{i}.
   Chain	Returned from device
   DefaultPolicy	Drop

   Device.Firewall.Chain.{i}.Rule.{i}.
   Target	Accept
   DestIP	<Unused IP Address>
   SourceIP	<Unused IP Address>

5. ACS enables the Firewall by sending a SetParameterValues RPC for Device.Firewall.Enable with the value set to “true.”

6. End Device 1 attempts to open a TCP connection, destination port 80, with WAN Device.

7. End Device 2 attempts to open a TCP connection, destination port 80, with WAN Device.

8. Configure ACS to send an AddObject RPC for Device.Firewall.Chain.{i}.Rule and record the returned instance number.

9. ACS Configures the new Firewall Rule by sending a SetParameterValues RPC with the following name/value pairs using the instance number returned in step 8.

   Device.Firewall.Chain.{i}.
   Enable	true

   Device.Firewall.Chain.{i}.Rule.{i}.
   Target	Accept
   DestInterface	Default WAN Interface
   Protocol
   DestPort	80
   SourceIP	End Device1 IP

10. End Device 1 attempts to open a TCP connection, destination port 80, with WAN Device.

11. End Device 2 attempts to open a TCP connection, destination port 80, with WAN Device.

12. Configure ACS to send an AddObject RPC for Device.Firewall.Chain.{i}.Rule and record the returned instance number.

13. ACS Configures the new Firewall Rule by sending a SetParameterValues RPC with the following name/value pairs using the instance number returned in step 12.

    Device.Firewall.Chain.{i}.
    Enable	true

    Device.Firewall.Chain.{i}.Rule.{i}.
    Target	Accept
    DestInterface	Default WAN Interface
    Protocol
    DestPort	80
    SourceIP	End Device2 IP

14. End Device 1 attempts to open a TCP connection, destination port 80, with WAN Device.

15. End Device 2 attempts to open a TCP connection, destination port 80 with WAN Device.

5.5.4.8 Test Metrics:

1. In Step 6, CPE does not forward TCP traffic from End Device 1 to the WAN side.
2. In Step 7, CPE does not forward TCP traffic from End Device 2 to the WAN side.
3. In Step 10, CPE forwards TCP traffic from End Device 1 to the WAN side.
4. In Step 11, CPE does not forward TCP traffic from End Device 2 to the WAN side.
5. In Step 14, CPE forwards TCP traffic from End Device 1 to the WAN side.
6. In Step 15, CPE forwards TCP traffic from End Device 2 to the WAN side.

5.6 Wi-Fi Provisioning

5.6.1 Wi-Fi Setup WEP 64 (InternetGatewayDevice:1 Only)

5.6.1.1 Purpose:

5.6.1.2 References:

5.6.1.3 Profiles:

5.6.1.4 Optional Features:

5.6.1.5 Parameters:

5.6.1.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have an End Device with the ability to connect to wireless networks.

5.6.1.7 Procedure:

1. Perform a GetParameterValues on the WLANConfiguration partial path listed in the parameters section to learn the existing stack hierarchy.
2. Configure the wireless LAN settings on the CPE using a single SetParameterValues.
3. Reboot the CPE.
4. The End Device connects to the CPE’s newly created wireless LAN access point.
5. Stimulate network traffic across the wireless LAN connection

5.6.1.8 Test Metrics:

1. Verify that WEPEncryptionLevel includes “40-bit”.
2. Verify that the SetParameterValuesResponse is valid.
3. Settings persist across reboot.
4. The End Device can connect to the wireless LAN connection.
5. The End Device has appropriate network access through the wireless LAN connection.

5.6.2 Wi-Fi Setup WEP 128 (InternetGatewayDevice:1 Only)

5.6.2.1 Purpose:

5.6.2.2 References:

5.6.2.3 Profiles:

5.6.2.4 Optional Features:

5.6.2.5 Parameters:

5.6.2.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have an End Device with the ability to connect to wireless networks.

5.6.2.7 Procedure:

1. Perform a GetParameterValues on the WLANConfiguration partial path listed in the parameters section to learn the existing stack hierarchy.
2. Configure the wireless LAN settings on the CPE using a single SetParameterValues.
3. Reboot the CPE.
4. The End Device connects to the CPE’s newly created wireless LAN access point.
5. Stimulate network traffic across the wireless LAN connection

5.6.2.8 Test Metrics:

1. Verify that WEPEncryptionLevel includes “104-bit”.
2. Verify that the SetParameterValuesResponse is valid.
3. Settings persist across reboot.
4. The End Device can connect to the wireless LAN connection.
5. The End Device has appropriate network access through the wireless LAN connection.

5.6.3 Wi-Fi Setup WPA Personal (InternetGatewayDevice:1 Only)

5.6.3.1 Purpose:

5.6.3.2 References:

5.6.3.3 Profiles:

5.6.3.4 Optional Features:

5.6.3.5 Parameters:

5.6.3.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have an End Device with the ability to connect to wireless networks.

5.6.3.7 Procedure:

1. Perform a GetParameterValues on the WLANConfiguration partial path listed in the parameters section to learn the existing stack hierarchy.
2. Configure the wireless LAN settings on the CPE using a single SetParameterValues.
3. Reboot the CPE.
4. The End Device connects to the CPE’s newly created wireless LAN access point.
5. Stimulate network traffic across the wireless LAN connection

5.6.3.8 Test Metrics:

1. Verify that the SetParameterValuesResponse is valid.
2. Settings persist across reboot.
3. The End Device can connect to the wifi connection.
4. The End Device has appropriate network access through the wifi connection.

5.6.4 Wi-Fi Setup WPA2 Personal (InternetGatewayDevice:1 Only)

5.6.4.1 Purpose:

5.6.4.2 References:

5.6.4.3 Profiles:

5.6.4.4 Optional Features:

5.6.4.5 Parameters:

5.6.4.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have an End Device with the ability to connect to wireless networks

5.6.4.7 Procedure:

1. Perform a GetParameterValues on the WLANConfiguration partial path listed in the parameters section to learn the existing stack hierarchy.
2. Configure the wireless LAN settings on the CPE using a single SetParameterValues.
3. Reboot the CPE.
4. The End Device connects to the CPE’s newly created wireless LAN access point.
5. Stimulate network traffic across the wireless LAN connection

5.6.4.8 Test Metrics:

1. Verify that the SetParameterValuesResponse is valid.
2. Settings persist across reboot.
3. The End Device can connect to the wifi connection.
4. The End Device has appropriate network access through the wifi connection.

5.6.5 Wi-Fi Setup WPA-WPA2 Personal (InternetGatewayDevice:1 Only)

5.6.5.1 Purpose:

5.6.5.2 References:

5.6.5.3 Profiles:

5.6.5.4 Optional Features:

5.6.5.5 Parameters:

5.6.5.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have an End Device with the ability to connect to wireless networks.

5.6.5.7 Procedure:

1. Perform a GetParameterValues on the WLANConfiguration partial path listed in the parameters section to learn the existing stack hierarchy.
2. Configure the wireless LAN settings on the CPE using a single SetParameterValues.
3. Reboot the CPE.
4. The End Device connects to the CPE’s newly created wireless LAN access point.
5. Stimulate network traffic across the wireless LAN connection

5.6.5.8 Test Metrics:

1. Verify that the SetParameterValuesResponse is valid.
2. Settings persist across reboot.
3. The End Device can connect to the wifi connection.
4. The End Device has appropriate network access through the wifi connection.

5.6.6 Wi-Fi Setup WEP 64 (Device:2 Only)

5.6.6.1 Purpose:

5.6.6.2 References:

5.6.6.3 Profiles:

5.6.6.4 Optional Features:

5.6.6.5 Parameters:

5.6.6.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have an End Device with the ability to connect to wireless networks.

5.6.6.7 Procedure:

1. Perform a GetParameterValues on the root partial path listed in the parameters section to learn the existing stack hierarchy.
2. If no SSID objects exist, perform an AddObject RPC on the Device.Wifi.SSID. partial path.
   1. Record the instance number received in the AddObjectResponse.
   2. If no AccessPoint objects exist, perform an AddObject RPC on the Device.Wifi.AccessPoint. partial path
   3. Record the instance number received in the AddObjectResponse
   4. Configure the Wifi settings on the CPE using a single SetParameterValues.
   5. Reboot the CPE.
   6. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.
   7. The End Device connects to the CPE’s newly created wifi access point.
   8. Stimulate network traffic across the Wifi connection
   9. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.

5.6.6.8 Test Metrics:

1. Verify that the SetParameterValuesResponse is valid.
2. Settings persist across reboot.
3. The End Device can connect to the wireless LAN connection.
4. The End Device has appropriate network access through the wireless LAN connection.
5. The Stats object has updated to reflect the network traffic across the wireless LAN connection.

5.6.7 Wi-Fi Setup WEP 128 (Device:2 Only)

5.6.7.1 Purpose:

5.6.7.2 References:

5.6.7.3 Profiles:

5.6.7.4 Optional Features:

5.6.7.5 Parameters :

5.6.7.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have an End Device with the ability to connect to wireless networks.

5.6.7.7 Procedure:

1. Perform a GetParameterValues on the root partial path listed in the parameters section to learn the existing stack hierarchy.
2. If no SSID objects exist, perform an AddObject RPC on the Device.Wifi.SSID. partial path.
   1. Record the instance number received in the AddObjectResponse.
   2. If no AccessPoint objects exist, perform an AddObject RPC on the Device.Wifi.AccessPoint. partial path
   3. Record the instance number received in the AddObjectResponse
   4. Configure the Wifi settings on the CPE using a single SetParameterValues.
   5. Reboot the CPE.
   6. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.
   7. The End Device connects to the CPE’s newly created wifi access point.
   8. Stimulate network traffic across the Wifi connection
   9. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.

5.6.7.8 Test Metrics:

1. Verify that the SetParameterValuesResponse is valid.
2. Settings persist across reboot.
3. The End Device can connect to the wifi connection.
4. The End Device has appropriate network access through the wifi connection.
5. The Stats object has updated to reflect the network traffic across the wifi connection.

5.6.8 Wi-Fi Setup WPA Personal (Device:2 Only)

5.6.8.1 Purpose:

5.6.8.2 References:

5.6.8.3 Profiles:

5.6.8.4 Optional Features:

5.6.8.5 Parameters:

5.6.8.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have an End Device with the ability to connect to wireless networks.

5.6.8.7 Procedure:

Perform a GetParameterValues on the root partial path listed in the parameters section to learn the existing stack hierarchy. If no SSID objects exist, perform an AddObject RPC on the Device.Wifi.SSID. partial path. #. Record the instance number received in the AddObjectResponse. #. If no AccessPoint objects exist, perform an AddObject RPC on the Device.Wifi.AccessPoint. partial path #. Record the instance number received in the AddObjectResponse #. Configure the Wifi settings on the CPE using a single SetParameterValues. #. Reboot the CPE. #. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values. #. The End Device connects to the CPE’s newly created wifi access point. #. Stimulate network traffic across the Wifi connection #. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.

5.6.8.8 Test Metrics:

1. Verify that the SetParameterValuesResponse to be valid.
2. Settings persist across reboot.
3. The End Device can connect to the wifi connection.
4. The End Device has appropriate network access through the wifi connection.
5. The Stats object has updated to reflect the network traffic across the wifi connection.

5.6.9 Wi-Fi Setup WPA Enterprise (Device:2 Only)

5.6.9.1 Purpose:

5.6.9.2 References:

5.6.9.3 Profiles:

5.6.9.4 Optional Features:

5.6.9.5 Parameters:

5.6.9.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a RADIUS Server set up configured with a secret and a user account with a known username and password.
3. Have an End Device with the ability to connect to wireless networks.

5.6.9.7 Procedure:

1. Perform a GetParameterValues on the root partial path listed in the parameters section to learn the existing stack hierarchy.
2. If no SSID objects exist, perform an AddObject RPC on the Device.Wifi.SSID. partial path.
   1. Record the instance number received in the AddObjectResponse.
   2. If no AccessPoint objects exist, perform an AddObject RPC on the Device.Wifi.AccessPoint. partial path
   3. Record the instance number received in the AddObjectResponse
   4. Configure the Wifi settings on the CPE using a single SetParameterValues.
   5. Reboot the CPE.
   6. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.
   7. The End Device connects to the CPE’s newly created wifi access point, authenticated from the RADIUS Server.
   8. Stimulate network traffic across the Wifi connection
   9. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.

5.6.9.8 Test Metrics:

1. Verify that the SetParameterValuesResponse is valid.
2. Settings persist across reboot.
3. Verify CPE sends a Radius request on End Device connection to the Radius server and receives a valid response.
4. The End Device can connect to the wifi connection.
5. The End Device has appropriate network access through the wifi connection.
6. The Stats object has updated to reflect the network traffic across the wifi connection.

5.6.10 Wi-Fi Setup WPA2 Personal (Device:2 only)

5.6.10.1 Purpose:

5.6.10.2 References:

5.6.10.3 Profiles:

5.6.10.4 Optional Features:

5.6.10.5 Parameters:

5.6.10.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have an End Device with the ability to connect to wireless networks.

5.6.10.7 Procedure:

1. Perform a GetParameterValues on the root partial path listed in the parameters section to learn the existing stack hierarchy.
2. If no SSID objects exist, perform an AddObject RPC on the Device.Wifi.SSID. partial path.
   1. Record the instance number received in the AddObjectResponse.
   2. If no AccessPoint objects exist, perform an AddObject RPC on the Device.Wifi.AccessPoint. partial path
   3. Record the instance number received in the AddObjectResponse
   4. Configure the Wifi settings on the CPE using a single SetParameterValues.
   5. Reboot the CPE.
   6. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.
   7. The End Device connects to the CPE’s newly created wifi access point.
   8. Stimulate network traffic across the Wifi connection
   9. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.

5.6.10.8 Test Metrics:

1. Verify that the SetParameterValuesResponse is valid.
2. Settings persist across reboot.
3. The End Device can connect to the wifi connection.
4. The End Device has appropriate network access through the wifi connection.
5. The Stats object has updated to reflect the network traffic across the wifi connection.

5.6.11 Wi-Fi Setup WPA2 Enterprise (Device:2 Only)

5.6.11.1 Purpose:

5.6.11.2 References:

5.6.11.3 Profiles:

5.6.11.4 Optional Features:

5.6.11.5 Parameters:

5.6.11.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a RADIUS Server set up configured with a secret and a user account with a known username and password.
3. Have an End Device with the ability to connect to wireless networks.

5.6.11.7 Procedure:

1. Perform a GetParameterValues on the root partial path listed in the parameters section to learn the existing stack hierarchy.
2. If no SSID objects exist, perform an AddObject RPC on the Device.Wifi.SSID. partial path.
   1. Record the instance number received in the AddObjectResponse.
   2. If no AccessPoint objects exist, perform an AddObject RPC on the Device.Wifi.AccessPoint. partial path
   3. Record the instance number received in the AddObjectResponse
   4. Configure the Wifi settings on the CPE using a single SetParameterValues.
   5. Reboot the CPE.
   6. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.
   7. The End Device connects to the CPE’s newly created wifi access point, authenticated from the RADIUS Server.
   8. Stimulate network traffic across the Wifi connection
   9. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.

5.6.11.8 Test Metrics:

1. Verify that the SetParameterValuesResponse is valid.
2. Settings persist across reboot.
3. Verify CPE sends a Radius request on End Device connection to the Radius server and receives a valid response.
4. The End Device can connect to the wifi connection.
5. The End Device has appropriate network access through the wifi connection.
6. The Stats object has updated to reflect the network traffic across the wifi connection.

5.6.12 Wi-Fi Setup WPA-WPA2 Personal (Device:2 Only)

5.6.12.1 Purpose:

5.6.12.2 References:

5.6.12.3 Profiles:

5.6.12.4 Optional Features:

5.6.12.5 Parameters:

5.6.12.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have an End Device with the ability to connect to wireless networks.

5.6.12.7 Procedure:

1. Perform a GetParameterValues on the root partial path listed in the parameters section to learn the existing stack hierarchy.
2. If no SSID objects exist, perform an AddObject RPC on the Device.Wifi.SSID. partial path.
   1. Record the instance number received in the AddObjectResponse.
   2. If no AccessPoint objects exist, perform an AddObject RPC on the Device.Wifi.AccessPoint. partial path
   3. Record the instance number received in the AddObjectResponse
   4. Configure the Wifi settings on the CPE using a single SetParameterValues.
   5. Reboot the CPE.
   6. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.
   7. The End Device connects to the CPE’s newly created wifi access point.
   8. Stimulate network traffic across the Wifi connection
   9. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.

5.6.12.8 Test Metrics:

1. Verify that the SetParameterValuesResponse is valid.
2. Settings persist across reboot.
3. The End Device can connect to the wifi connection.
4. The End Device has appropriate network access through the wifi connection.
5. The Stats object has updated to reflect the network traffic across the wifi connection.

5.6.13 Wi-Fi Setup WPA-WPA2 Enterprise (Device:2 Only)

5.6.13.1 Purpose:

5.6.13.2 References:

5.6.13.3 Profiles:

5.6.13.4 Optional Features:

5.6.13.5 Parameters:

5.6.13.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a RADIUS Server set up configured with a secret and a user account with a known username and password.
3. Have an End Device with the ability to connect to wireless networks.

5.6.13.7 Procedure:

1. Perform a GetParameterValues on the root partial path listed in the parameters section to learn the existing stack hierarchy.
2. If no SSID objects exist, perform an AddObject RPC on the Device.Wifi.SSID. partial path.
   1. Record the instance number received in the AddObjectResponse.
   2. If no AccessPoint objects exist, perform an AddObject RPC on the Device.Wifi.AccessPoint. partial path
   3. Record the instance number received in the AddObjectResponse
   4. Configure the Wifi settings on the CPE using a single SetParameterValues.
   5. Reboot the CPE.
   6. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.
   7. The End Device connects to the CPE’s newly created wifi access point.
   8. Stimulate network traffic across the Wifi connection
   9. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.

5.6.13.8 Test Metrics:

1. Verify that the SetParameterValuesResponse is valid.
2. Settings persist across reboot.
3. The End Device can connect to the wifi connection.
4. The End Device has appropriate network access through the wifi connection.
5. The Stats object has updated to reflect the network traffic across the wifi connection.

5.6.14 Wi-Fi Setup WPA3 Personal (Device:2 only)

5.6.14.1 Purpose:

To verify that an ACS can set a valid Wi-Fi configuration on the CPE using WPA3- Personal encryption.

5.6.14.2 References:

Device:2 [10]

5.6.14.3 Profiles:

5.6.14.4 Optional Features:

ModesSupported includes “WPA3-Personal”

5.6.14.5 Parameters:

5.6.14.6 Test Setup:

1. Refer to Section 4.2.1, Common Test Setup, for setup steps.
2. Have an End Device with the ability to connect to wireless networks.

5.6.14.7 Procedure:

1. Perform a GetParameterValues on the root partial path listed in the parameters section to learn the existing stack hierarchy.
2. If no SSID objects exist, perform an AddObject RPC on the Device.Wifi.SSID. partial path.

1. Record the instance number received in the AddObjectResponse.

1. If no AccessPoint objects exist, perform an AddObject RPC on the Device.Wifi.AccessPoint. partial path

1. Record the instance number received in the the AddObjectResponse

1. Configure the Wifi settings on the CPE using a single SetParameterValues.
2. Reboot the CPE.
3. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.
4. The End Device connects to the CPE’s newly created wifi access point.
5. Stimulate network traffic across the Wifi connection
6. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values

5.6.14.8 Test Metrics:

1. Verify that the SetParameterValuesResponse is valid.
2. Settings persist across reboot.
3. The End Device can connect to the wifi connection.
4. The End Device has appropriate network access through the wifi connection.
5. The Stats object has updated to reflect the network traffic across the wifi connection.

5.6.15 Wi-Fi Setup WPA3-Personal-Transition (Device:2 only)

5.6.15.1 Purpose:

To verify that an ACS can set a valid Wi-Fi configuration on the CPE using WPA3- Personal-Transition encryption.

5.6.15.2 References:

Device:2 [10]

5.6.15.3 Profiles:

5.6.15.4 Optional Features:

ModesSupported includes “WPA3-Personal-Transition”

5.6.15.5 Parameters:

5.6.15.6 Test Setup:

1. Refer to Section 4.2.1, Common Test Setup, for setup steps.
2. Have an End Device with the ability to connect to wireless networks.

5.6.15.7 Procedure:

1. Perform a GetParameterValues on the root partial path listed in the parameters section to learn the existing stack hierarchy.
2. If no SSID objects exist, perform an AddObject RPC on the Device.Wifi.SSID. partial path.

1. Record the instance number received in the AddObjectResponse.

1. If no AccessPoint objects exist, perform an AddObject RPC on the Device.Wifi.AccessPoint. partial path

1. Record the instance number received in the the AddObjectResponse

1. Configure the Wifi settings on the CPE using a single SetParameterValues.
2. Reboot the CPE.
3. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.
4. The End Device connects to the CPE’s newly created wifi access point.
5. Stimulate network traffic across the Wifi connection
6. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values

5.6.15.8 Test Metrics:

1. Verify that the SetParameterValuesResponse is valid.
2. Settings persist across reboot.
3. The End Device can connect to the wifi connection.
4. The End Device has appropriate network access through the wifi connection.
5. The Stats object has updated to reflect the network traffic across the wifi connection.

5.6.16 Wi-Fi Setup WPA3-Enterprise (Device:2 only)

5.6.16.1 Purpose:

To verify that an ACS can set a valid Wi-Fi configuration on the CPE using WPA3- Enterprise encryption.

5.6.16.2 References:

Device:2 [10]

5.6.16.3 Profiles:

5.6.16.4 Optional Features:

ModesSupported includes “WPA3-Enterprise”

5.6.16.5 Parameters:

5.6.16.6 Test Setup:

1. Refer to Section 4.2.1, Common Test Setup, for setup steps.
2. Have a RADIUS Server set up configured with a secret and a user account with a known username and password.
3. Have an End Device with the ability to connect to wireless networks.

5.6.16.7 Procedure:

1. Perform a GetParameterValues on the root partial path listed in the parameters section to learn the existing stack hierarchy.
2. If no SSID objects exist, perform an AddObject RPC on the Device.Wifi.SSID. partial path.

1. Record the instance number received in the AddObjectResponse.

1. If no AccessPoint objects exist, perform an AddObject RPC on the Device.Wifi.AccessPoint. partial path

1. Record the instance number received in the the AddObjectResponse

1. Configure the Wifi settings on the CPE using a single SetParameterValues.
2. Reboot the CPE.
3. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.
4. The End Device connects to the CPE’s newly created wifi access point, authenticated from the RADIUS Server.
5. Stimulate network traffic across the Wifi connection
6. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values

5.6.16.8 Test Metrics:

1. Verify that the SetParameterValuesResponse is valid.
2. Settings persist across reboot.
3. Verify CPE sends a Radius request on End Device connection to the Radius server and receives a valid response.
4. The End Device has appropriate network access through the wifi connection.
5. The Stats object has updated to reflect the network traffic across the wifi connection.

5.6.17 Wi-Fi Setup – Add SSID (Device:2 Only)

5.6.17.1 Purpose:

5.6.17.2 References:

5.6.17.3 Profiles:

5.6.17.4 Optional Features:

5.6.17.5 Parameters:

5.6.17.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a pre-existing, working Wi-Fi Configuration on the CPE.
3. Have an End Device with the ability to connect to existing wireless networks.

5.6.17.7 Procedure:

1. Perform a GetParameterValues on the root partial path listed in the parameters section to learn the existing stack hierarchy. Take special note of the existing SSID object’s LowerLayers parameter (Device.Wifi.SSID.{j}.LowerLayers)
2. Perform an AddObject RPC on “Device.Wifi.SSID.” and record the instance number and status returned.
3. If the status of the Add Object RPC returned a 1, reboot the device.
4. Perform a Get Parameter Values RPC on the path from Procedure step 2 and confirm the object was added successfully.
5. Peform an AddObject RPC on “Device.WiFi.AccessPoint.” and record the instance number and status returned.
6. If the status of the Add Object RPC returned a 1, reboot the device.
7. Perform a Get Parameter Values RPC on the path from Procedure step 5 and confirm the object was added successfully.
8. Configure the Wifi settings on the CPE to utilize the new SSID object using the SetParameterValues RPC:
   1. Device.Wifi.SSID.{i}.LowerLayers = <Value returned in Procedure step 1>
   2. Device.Wifi.SSID.{i}.Enable = true
   3. Device.Wifi.SSID.{i}.SSID = <Value different from Device.Wifi.SSID.{j}.SSID>
   4. Device.Wifi.AccessPoint.{k}.SSIDReference = Device.Wifi.SSID.{i}
   5. The End Device connects to the CPE’s newly created Wi-Fi SSID using the same authentication method and credentials that the preexisting configuration uses.
   6. Reboot the CPE
   7. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.
   8. The End Device connects to the CPE’s newly created wifi SSID using the same authentication method and credentials that the preexisting configuration uses.
   9. Stimulate network traffic across the Wifi connection.
   10. Perform a GetParameterValues on the Stats object listed in the Parameters section and note the values.

5.6.17.8 Test Metrics:

1. Verify that the SetParameterValuesResponse is valid.
2. Settings persist across reboot.
3. The End Device can connect to the new SSID.
4. The End Device has appropriate network access using the new SSID.
5. The Stats object has updated to reflect the network traffic across the Wi-Fi connection.

5.6.18 Wi-Fi Setup – Remove SSID (Device:2 Only)

5.6.18.1 Purpose:

5.6.18.2 References:

5.6.18.3 Profiles:

5.6.18.4 Optional Features:

5.6.18.5 Parameters:

5.6.18.6 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have a preexisting, working Wifi configuration on the CPE.
3. Have an End Device (Laptop) with the ability to connect to wireless networks.

5.6.18.7 Procedure:

1. Verify that the existing Wifi configuration is operating correctly by connecting the End Device to it. Note the SSID that was connected to.
2. Perform a GetParameterValues on the root partial path listed in the parameters section to learn the existing stack hierarchy. Note the instance number of the SSID object with the SSID field matching the one connected to in Procedure Step 1 as well as the instance number of the AccessPoint with the SSIDReference field mapped to the appropriate SSID.
3. Peform a DeleteObject RPC on the Device.Wifi.SSID.{instance noted in Procedure Step 2} and Device.Wifi.AccessPoint.{instance noted in Procedure Step 2}, noting the returned value.
4. If the status returned is 1, reboot the CPE.
5. Perform a GetParameterValues on Device.Wifi.SSID. And Device.Wifi.AccessPoint. to confirm deletion.
6. Attempt to re-connect the End Device to the removed SSID.
7. If status returned in the DeleteObject was 0, reboot the CPE and then perform a GetParameterValues on Device.Wifi.SSID. And Device.Wifi.AccessPoint. to confirm deletion persisted across reboot.

5.6.18.8 Test Metrics:

1. End Device can initially connect to the SSID
2. Deletion of SSID object persists across reboot.
3. The End Device cannot connect to the deleted SSID.

5.7 Localized Strings

5.7.1 Non-Printable ASCII Characters in SetParameterValues RPC (Device:2 Only)

5.7.1.1 Purpose:

5.7.1.2 References:

5.7.1.3 Profiles:

5.7.1.4 Optional Features:

5.7.1.5 Parameters:

5.7.1.6 Test Setup:

1. Refer to Common Test Setup for setup steps.

5.7.1.7 Procedure:

1. ACS triggers a new session with the CPE
2. The CPE establishes the session
3. ACS performs a SPV on the above parameter and sets a new value, which is randomly generated and fulfills these criteria:
4. The string contains non-printable ASCII characters
5. The string contains XML characters, which have to be escaped like “<,>, &”
6. ACS ends the session
7. ACS triggers a new session with the CPE
8. The CPE establishes the session
9. ACS performs a GPV on the above parameter
10. ACS ends the session
11. Repeat steps 1-8 with a new randomly generated string.
12. Repeat steps 1-8 with a new randomly generated string.

5.7.1.8 Test Metrics:

1. Validate that both session can be successfully executed
2. Validate that the GPV and SPV are successful
3. Validate that the string returned in step 7 matches the string set in step 3
4. Validate that the string is properly encoded in step 3 and step 7

5.7.2 Multi-Byte Encoding in SetParameterValues RPC (Device:2 Only)

5.7.2.1 Purpose:

5.7.2.2 References:

5.7.2.3 Profiles:

5.7.2.4 Optional Features:

5.7.2.5 Parameters:

5.7.2.6 Test Setup:

1. Refer to Common Test Setup for setup steps.

5.7.2.7 Procedure:

1. ACS triggers a new session with the CPE
2. The CPE establishes the session
3. ACS performs a SPV on the above parameter and sets a new value, which is randomly generated and fulfills these criteria:
4. The string uses a multi-byte encoding
5. The string contains 64 characters
6. ACS ends the session
7. ACS triggers a new session with the CPE
8. The CPE establishes the session
9. ACS performs a GPV on the above parameter
10. ACS ends the session

5.7.2.8 Test Metrics:

1. Validate that both session can be successfully executed
2. Validate that the GPV and SPV are successful
3. Validate that the string returned in step 7 matches the string set in step 3
4. Validate that the string is properly encoded in step 3 and step 7

5.7.3 Non-ASCII Characters in ParameterKey (Device:2 Only)

5.7.3.1 Purpose:

5.7.3.2 References:

5.7.3.3 Profiles:

5.7.3.4 Optional Features:

5.7.3.5 Parameters:

5.7.3.6 Test Setup:

1. Refer to Common Test Setup for setup steps.

5.7.3.7 Procedure:

1. ACS triggers a new session with the CPE.
2. The CPE establishes the session.
3. ACS performs a SetParameterValues RPC on the ProvisioningCode and sets a new value. In the SPV the ACS uses a ParameterKey, which is randomly generated and fulfills these criteria:
4. The string contains non-printable ASCII characters
5. The string contains XML characters, which have to be escaped like “<,>, &”.
6. ACS ends the session.
7. ACS triggers a new session with the CPE.
8. The CPE establishes the session.
9. ACS performs a GetParameterValues on ParameterKey.
10. ACS ends the session.
11. Repeat steps 1-8 with a new randomly generated string.
12. Repeat steps 1-8 with a new randomly generated string.

5.7.3.8 Test Metrics:

1. Validate that both session can be successfully executed.
2. Validate that the GetParameterValues RPC and the SetParameterValues RPC are successful.
3. Validate that the string returned in step 7 matches the string set in step 3.
4. Validate that the string is properly encoded in step 3 and step 7.

5.7.4 Multi-Byte Encoding in ParameterKey (Device:2 Only)

5.7.4.1 Purpose:

5.7.4.2 References:

5.7.4.3 Profiles:

5.7.4.4 Optional Features:

5.7.4.5 Parameters:

5.7.4.6 Test Setup:

1. Refer to Common Test Setup for setup steps.

5.7.4.7 Procedure:

1. ACS triggers a new session with the CPE
2. The CPE establishes the session
3. ACS performs a SetParameterValues RPC on the ProvisioningCode and sets a new value. In the SPV the ACS uses a ParameterKey, which is randomly generated and fulfills these criteria:
4. The string uses a multi-byte encoding
5. The string contains 32 characters
6. ACS ends the session
7. ACS triggers a new session with the CPE
8. The CPE establishes the session
9. ACS performs a GetParameterValues RPC on ParameterKey.
10. ACS ends the session

5.7.4.8 Test Metrics:

1. Validate that both session can be successfully executed
2. Validate that the GetParameterValues RPC and the SetParameterValues RPC are successful
3. Validate that the string returned in step 7 matches the string set in step 3
4. Validate that the string is properly encoded in step 3 and step 7

5.7.5 Non-ASCII Characters in CommandKey (Device:2 Only)

5.7.5.1 Purpose:

5.7.5.2 References:

5.7.5.3 Profiles:

5.7.5.4 Optional Features:

5.7.5.5 Parameters:

5.7.5.6 Test Setup:

1. Refer to Common Test Setup for setup steps.

5.7.5.7 Procedure:

1. ACS triggers a new session with the CPE
2. The CPE establishes the session
3. ACS performs a Reboot RPC with a Commandkey parameter which is randomly generated and fulfills these criteria:
4. The string contains non-printable ASCII characters.
5. The string contains XML characters, which have to be escaped like “<,>, &”
6. ACS ends the session
7. The CPE performs a reboot and reports the CommandKey to the ACS.
8. Repeat steps 1-5 with a new randomly generated string.
9. Repeat steps 1-5 with a new randomly generated string.

5.7.5.8 Test Metrics:

1. Validate that both session can be successfully executed
2. Validate that the Reboot RPC is successful.
3. Validate that the string returned in step 5 matches the string set in step 3 after escaping.
4. Validate that the string is properly encoded in step 3 and step 5

5.7.6 Multi-Byte Encoding in CommandKey (Device:2 Only)

5.7.6.1 Purpose:

5.7.6.2 References:

5.7.6.3 Profiles:

5.7.6.4 Optional Features:

5.7.6.5 Parameters:

5.7.6.6 Test Setup:

1. Refer to Common Test Setup for setup steps.

5.7.6.7 Procedure:

1. ACS triggers a new session with the CPE
2. The CPE establishes the session
3. ACS performs a Reboot RPC with a Commandkey parameter which is randomly generated and fulfills these criteria:
4. The string uses a multi-byte encoding using UTF-8.
5. The string contains 32 characters
6. ACS ends the session
7. The CPE performs a reboot and reports the CommandKey to the ACS.

5.7.6.8 Test Metrics:

1. Validate that both session can be successfully executed
2. Validate that the Reboot RPC is successful
3. Validate that the string returned in step 5 matches the string set in step 3 after escaping.
4. Validate that the string is properly encoded in step 3 and step 5

5.8 Configuration Backup and Restore – Incorrect Backup File

5.8.0.1 Purpose:

This test is designed to verify that the CPE responds to invalid restoration of a configuration with a correct fault code.

5.8.0.2 References:

Section A.4.1.5/TR-069a1 or later [8]

5.8.0.3 Parameters:

These parameters are for the Download RPC:

Download parameters:

CommandKey: a unique value

FileType: "3 Vendor Configuration File"

URL:  location of the invalid file

Username: used to authenticate CPE with file server

Password: used to authenticate CPE with file server

FileSize: size of the file in bytes

TargetFileName: name of file

DelaySeconds: 0

SuccessURL: Empty string

FailureURL: Empty string

5.8.0.4 Test Setup:

1. ACS connected to the network
2. CPE connected to the network and configured with an ACS URL that corresponds to the ACS in #1
3. Have device to capture traffic between the device and both the file server and ACS
4. Establish a server to download files.

5.8.0.5 Procedure:

1. ACS schedules a download RPC on the CPE with the parameters above
2. Allow CPE to respond DownloadResponse or TransferComplete

5.8.0.6 Test Metrics:

1. Verify that the CPE responds to the Download RPC with a DownloadResponse or TransferComplete with one of the following fault codes: 9003 (Invalid argument),

5.9 DHCP Provisioning – Disable DHCP

5.9.0.1 Purpose:

5.9.0.2 References:

5.9.0.3 Parameters:

5.9.0.4 Test Setup:

1. ACS connected to the network
2. CPE connected to the network and configured with an ACS URL that corresponds to the ACS in #1
3. CPE supports the appropriate DHCP parameters in the parameters section
4. If a Device CPE, verify that the Interface parameter is a valid path name in the IP Interface table.
5. Have an end system that can attempt to connect to the CPE via DHCP.

5.9.0.5 Procedure:

1. If the DUT implements the Device:2 root data model, perform an AddObject RPC on Device.Server.Pool., recording the InstanceNumber value returned in the AddObjectResponse
2. On the ACS schedule a SetParameterValues RPC on the appropriate Configurable parameters in the Parameters Section
3. Allow the end system to connect to the CPE via DHCP.
4. Perform a reboot of the CPE
5. Allow the end system to attempt connect to the CPE via DHCP

5.9.0.6 Test Metrics:

1. Verify that the SetParameterValuesResponse RPC is correct for all parameters
2. Verify that the end system doesn’t connect to the CPE within the designated range.
3. Verify that that end system doesn’t connects to the CPE within the designated range after the reboot

5.10 Diagnostics IPPing – Error Condition

5.10.0.1 Purpose:

5.10.0.2 References:

5.10.0.3 Parameters:

5.10.0.4 Test Setup:

1. ACS connected to the network
2. CPE connected to the network and configured with an ACS URL that corresponds to the ACS in Setup #1
3. Wireshark running between ACS and CPE.

5.10.0.5 Procedure:

1. ACS performs a GetParameterValues RPC on the WAN Interface parameter to determine the current interface in the parameter section above.
2. ACS performs a SetParameterValues RPC on the ping diagnostics parameters in the parameter section above.
3. ACS performs a GetParameterValues on the InternetGatewayDevice.IPPingDiagnostics or Device.IP.Diagnostics.IPPing to determine results of ping test

5.10.0.6 Test Metrics:

1. Validate that an Inform RPC is sent from the ACS with Event Code “8 DIAGNOSTICS COMPLETE”
2. Validate that the DiagnosticsState is set to Error_NoRouteToHost.

5.11 TraceRoute Diagnostics – Error Condition

5.11.0.1 Purpose:

5.11.0.2 References:

5.11.0.3 Parameters:

5.11.0.4 Test Setup:

1. ACS connected to the network
2. CPE connected to the network and configured with an ACS URL that corresponds to the ACS in Setup #1
3. Wireshark running between ACS and CPE.
4. Ensure there are at least 2 hops between the CPE and Host

5.11.0.5 Procedure:

1. Establish a CWMP session between the CWMP Analyzer and DUT with successful Inform exchanges.
2. Schedule a GetParameterValues RPC on the current WAN interface.
3. Schedule a SetParameterValues RPC on the DUT on the trace route diagnostic parameters listed above.
4. Schedule a GetParameterValues RPC on the DUT on Diagnostic State.

5.11.0.6 Test Metrics:

1. The DUT can properly respond to the GetParameterValues request on WAN interface.
2. The DUT is able to properly respond to the SetParameterValues for diagnostics parameter.
3. Validate that the DiagnosticsState is set to “Error_MaxHopCountExceeded”

5.12 IPPing Diagnostics – Periodic Inform

5.12.0.1 Purpose:

5.12.0.2 References:

5.12.0.3 Parameters:

5.12.0.4 Test Setup:

1. ACS connected to the network
2. CPE connected to the network and configured with an ACS URL that corresponds to the ACS in Setup #1
3. Wireshark running between ACS and CPE.

5.12.0.5 Procedure:

1. ACS performs a SetParameterValues RPC on the ManagementServer parameters in the parameter section above.
2. ACS performs a GetParameterValues RPC on the WAN Interface parameter to determine the current interface in the parameter section above.
3. ACS performs a SetParameterValues RPC on the ping diagnostics parameters in the parameter section above.
4. ACS performs a GetParameterValues on the InternetGatewayDevice.IPPingDiagnostics or Device.IP.Diagnostics.IPPing to determine results of ping test

5.12.0.6 Test Metrics:

1. During diagnostic: Validate that the Inform RPC does not have a “8 DIAGNOSTICS COMPLETE” Event Code
2. After diagnostic:-Validate that an Inform RPC is sent from the ACS with Event Code “8 DIAGNOSTICS COMPLETE”

5.13 Deny/Allow Inbound IPv6 (Device:2 Only)

5.13.0.1 Purpose:

5.13.0.2 References:

5.13.0.3 Parameters:

5.13.0.4 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Refer to Determine WAN Interface to determine the WAN interface.
3. Two Devices that can send and receive TCP and UDP connections over IPv6 connected to the LAN side of the CPE (End Device 1 and End Device 2)
4. Device that can send and receive TCP and UDP connections over IPv6 connected on the WAN side of the CPE (WAN Device)
5. Have a Network Analyzer to capture traffic between the CPE and the End Device.

5.13.0.5 Procedure:

1. Configure ACS to send an AddObject RPC for Device.Firewall.Level and record the returned instance number.

2. Configure ACS to send a GetParameterValues RPC for Device.Firewall.Level.{i}.Chain.

3. Configure ACS to send an AddObject RPC for Device.Firewall.Chain.{i}.Rule using the path returned in step 2 and record the returned instance number.

4. ACS performs a SetParameterValues RPC on the following parameters using the instance numbers returned in steps 1-3.

   Device.Firewall.
   Config	Advanced
   AdvancedLevel	Device.Firewall.Level.{i}.

   Device.Firewall.Level.{i}.
   Chain	Returned from device
   DefaultPolicy	Drop

   Device.Firewall.Chain.{i}.Rule.{i}.
   Target	Accept
   DestIP	<Unused IP Address>
   SourceIP	<Unused IP Address>

5. ACS enables the Firewall by sending a SetParameterValues RPC for Device.Firewall.Enable with the value set to “true.”

6. WAN Device attempts to open a TCP connection over IPv6, destination port 25, with End Device 1.

7. WAN Device attempts to open a TCP connection over IPv6, destination port 25, with End Device 2.

8. Configure ACS to send an AddObject RPC for Device.Firewall.Chain.{i}.Rule and record the returned instance number.

9. ACS Configures the new Firewall Rule by sending a SetParameterValues RPC with the following name/value pairs using the instance number returned in step 8.

   Device.Firewall.Chain.{i}.
   Enable	true

   Device.Firewall.Chain.{i}.Rule.{i}.
   Target	Accept
   DestInterface	Default WAN Interface
   Protocol
   DestPort	25
   DestIP	End Device1 IP

10. WAN Device attempts to open a TCP connection over IPv6, destination port 25, with End Device 1.

11. WAN Device attempts to open a TCP connection over IPv6, destination port 25, with End Device 2.

12. Configure ACS to send an AddObject RPC for Device.Firewall.Chain.{i}.Rule and record the returned instance number.

13. ACS Configures the new Firewall Rule by sending a SetParameterValues RPC with the following name/value pairs using the instance number returned in step 12.

    Device.Firewall.Chain.{i}.
    Enable	true

    Device.Firewall.Chain.{i}.Rule.{i}.
    Target	Accept
    DestInterface	Default WAN Interface
    Protocol
    DestPort	25
    DestIP	End Device2 IP

14. WAN Device attempts to open a TCP connection over IPv6, destination port 25, with End Device 1.

15. WAN Device attempts to open a TCP connection over IPv6, destination port 25, with End Device 2.

5.13.0.6 Test Metrics:

1. In Step 6, CPE does not forward TCP traffic from WAN Device to End Device1.
2. In Step 7, CPE does not forward TCP traffic from WAN Device to End Device2.
3. In Step 10, CPE forwards TCP traffic from WAN Device to End Device1.
4. In Step 11, CPE does not forward TCP traffic from WAN Device to End Device2.
5. In Step 14, CPE forwards TCP traffic from WAN Device to End Device1.
6. In Step 15, CPE forwards TCP traffic from WAN Device to End Device2.

5.14 Download Diagnostics over HTTPS – TotalBytesReceived

5.14.0.1 Purpose:

5.14.0.2 References:

5.14.0.3 Parameters:

5.14.0.4 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have an HTTP server and file to perform the download over HTTPS. The file should be big enough for the file transfer to last at least 30 seconds.

5.14.0.5 Procedure:

1. On the ACS schedule a SetParameterValues RPC on the Interface, DownloadURL and DiagnosticsState parameters listed in the parameters section.
2. Allow the CPE to perform the specific diagnostic tests and send an Inform message with an event code of “8 DIAGNOSTICS COMPLETE”.
3. On the ACS schedule a GetParameterValues RPC on the DownloadDiagnostics object.
4. Perform a reboot of the CPE.
5. On the ACS schedule a GetParameterValues RPC on the DownloadDiagnostics object.

5.14.0.6 Test Metrics:

1. Verify that the SetParameterValuesResponse RPC is correct
2. Verify that an Inform message is received with an event code of “8 DIAGNOSTICS COMPLETE”
3. Verify that the GetParameterValuesResponse contains a valid value for the DiagnosticsState parameter.
4. Verify that TestBytesReceived is correct.
5. Verify that EOMTime – BOMTime is within 1 second of the time that the file server reports the transfer took.
6. Verify that the GetParameterValuesResponse contains a valid value for the DiagnosticsState parameter.
   1. If the value is “Completed” verify that the values in the DownloadDiagnostic object are the same as they were before the reboot.
   2. Verify that TotalBytesReceived is within 1% of the measured traffic.

5.15 Upload Diagnostics over HTTP - TotalBytesSent

5.15.0.1 Purpose:

5.15.0.2 References:

5.15.0.3 Parameters:

5.15.0.4 Test Setup:

1. Refer to Common Test Setup for setup steps.
2. Have an HTTP server to perform the Upload over HTTPS.
3. Wireshark running between ACS and CPE.

5.15.0.5 Procedure:

1. On the ACS schedule a SetParameterValues RPC on the Interface, UploadURL and DiagnosticsState parameters listed in the parameters section.
2. Allow the CPE to perform the specific diagnostic tests and send an Inform message with an event code of “8 DIAGNOSTICS COMPLETE”.
3. On the ACS schedule a GetParameterValues RPC on the UploadDiagnostics object.
4. Perform a reboot of the CPE
5. On the ACS schedule a GetParameterValues RPC on the UploadDiagnostics object.

5.15.0.6 Test Metrics:

1. Verify that the SetParameterValuesResponse RPC is correct
2. Verify that an Inform message is received with an event code of “8 DIAGNOSTICS COMPLETE”
3. Verify that the GetParameterValuesResponse contains a valid value for the DiagnosticsState parameter.
4. Verify that the test server received a file of TestLengthBytes size.
5. Verify that EOMTime – BOMTime is within 1 second of the time that the file server reports the transfer took.
6. Verify that the GetParameterValuesResponse contains a valid value for the DiagnosticsState parameter.
   1. If the value is “Completed” verify that the values in the UploadDiagnostic object are the same as they were before the reboot.
   2. Verify that TotalBytesSent is within 1% of the measured traffic.