Testing a TR-069 Wi-Fi setup
One of the most important use cases of TR-069 (and its evolution protocol, USP) is in the autoconfiguration, management, and troubleshooting of Wi-Fi networks. Often the source of the most customer service problems, being able to set up an end user’s Wi-Fi and make sure it’s working is critical for a satisfactory “carrier grade” home network.
TR-069 testing often revolves around ensuring the conformance of a device’s CWMP stack to the protocol specification, including the tests that provide certification metrics as part of the Broadband Forum’s official TR-069 certification program. Certification is necessary for making sure your implementation works and will be interoperable, but testing whether or not your device actually does what an ACS has told it to do via TR-069 is equally, if not more, important. That is, whether or not the CWMP stack and the associated data model is correctly bound to your underlying code that configures settings on the device.
Wi-Fi options in TR-069
There are a very large number of options in the Wi-Fi object in the Device:2 data model, or in the .LANDevice.{i}.WLANConfiguration.{i}. object in the (now deprecated) InternetGatewayDevice:1 and Device:1 data models. The WifiRadio, WifiSSID, and WifiAccessPoint profiles give a list of the minimum parameters and objects required by the protocol. As new Wi-Fi standards and features come out, this list is getting larger. Moreover, many vendors and providers have designed their own vendor extensions for Wi-Fi.
New or existing Wi-Fi interfaces?
In Device:2, a networking interface is configured by building objects at each interface layer and then joining them via the LowerLayers parameter (which then gets expressed in the Interface Stack). For Wi-Fi, an SSID object is joined to a Radio object, then associated with an AccessPoint object for configuration of general AP features, like security on the link.
Most devices probably have an existing SSID interface that can be used to verify that changes to it are actually completed by the DUT. In the case that they don’t, creating a new SSID will work just as well.
Basic Wi-Fi configuration tests
CDRouter has several TR-069 specific Wi-Fi test cases to proof a DUT’s Given the number of options, we want to just use the minimum setup required to get a Wi-Fi network up and running. Once configured, we simulate a Wi-Fi station in CDRouter to see if the SSID exists, can be connected to, and can pass network traffic. We then validate that counters present in the Device.WiFi.SSID.{i}.Stats. object have updated based on the traffic we’ve sent.
Steps for setting up Wi-Fi using TR-069 include:
- Set up and enable Radio interface
- Set up and enable an SSID
- Enable beacon advertisement
- Set up desired security
- Connect a simulated station to the DUT
- Send application traffic over the link
- Verify packet count stats in the data model
Testing different security profiles
While the basic settings for SSIDs and test procedure are common to all of the tr69_wireless.tcl test cases in CDRouter, our test cases vary the type of security that is configured to make sure each option works well. Some of these settings apply only to the (deprecated) InternetGatewayDevice:1 data model, but since a good number of deployed devices still use this model, these cases are included. You can see the data model version requirements for each test case in our test summaries.
Testing negative cases
The tr69_wireless.tcl module also tests to make sure that the DUT actually disables a Wi-Fi network when the Radio object is turned off. A disabled radio should not longer send beacon advertisements, giving an indication that it has been turned off and is undetectable.
Repetition, repetition, repetition
Testing the reconfiguration of Wi-Fi using TR-069 using CDRouter lets you run the exercises over and over, which can help expose issues that may build up over time. As we’ve learned from our performance add-on, memory leaks or fragmentation from repeated functional changes can have serious effects on the robustness of a DUT.
More functionality tests like this?
The Broadband Forum is producing an extended test plan (IR-181) for this style of functional verification, including things like firewall/port-mapping setup, diagnostics, data validation, and more. Look for these tests soon in CDRouter 10.6!
