Articles

How Should an ACS Treat Missing CWMP Data Model Objects?

2 min read

TR-069 (CWMP) provides a mechanism for service providers to remotely provision a subscriber’s home network devices, including home gateways, set-top boxes, WiFi, etc. It does this by allowing the service provider’s ACS (Auto Configuration Server) to operate on a device’s “data model” - a conceptual framework containing the set of objects and parameters that describe the CPE’s configuration and capabilities. What happens when those objects or parameters aren’t implemented or don’t exist?

 

The scenario

One of the primary functions of the ACS is to create new instances in the device’s data model. For example, if the service provider wants to configure a port forwarding rule on a gateway that is using NAT, it would perform the following method on the CPE:

  <soapenv:Body>
  <cwmp:AddObject>
    <ObjectName>
      Device.NAT.PortMapping.
    </ObjectName>
    <ParameterKey>
      3544041
    </ParameterKey>
  </cwmp:AddObject>
  </soapenv:Body>




This tells the CPE to make a new instance of the PortMapping object in the table. It will respond with the instance identifier it’s using for the new object. The ACS would then use the SetParameterValues RPC to configure the exact details of the port forwarding entry.

 

The problem

This bug arises when the CPE does not have any port forwarding rules, and so does not have any entries in its Device.NAT.PortMapping. table. As a consequence, some CPE don’t treat the PortMapping object as an existing object when no instances exist! Instead, it sends back a 9005 - Invalid Parameter Name fault code.

This is a problem, because it means the ACS cannot create port forwarding rules without there already being existing port forwarding rules - not a very practical scenario.

 

How is it supposed to work?

It is intended that what the CPE is capable of supporting be maintained seperately from what is currently in its configuration data model. This is often referred to as the difference between a CPE’s Device Type (DT) versus its current data model (DM). In earlier versions of CWMP, device type was conveyed by listing a set of profiles in the DeviceSummary parameter. In more recent versions, this is done by giving the ACS a URL to an XML document that completely describes the CPE’s capabilities through the SupportedDataModel table.

The objects that a device can operate on should not be dependent on the objects and parameters that currently exist and are configured on the device. A device with no PortMapping table entries should still treat the object as valid an allow the ACS to create port forwarding rules by adding instances to the table.