Looking at Data Models and Objects

Every data model in TR-069 contains the objects and parameters that represent the functions of a broadband CPE or other device. This includes their addressable name, syntax, data types, and a normative description of how they are to be used.

The Data Model Document

Let’s look at an actual data model XML document for Device:2. First you’ll see a set of comments. These will name the most recent editors and give you an overview of the updates in each version.

Every data model document starts with the dm:document element. This element describes the namespace that the data model pulls from. In this case, you can see that it is an instance of the cwmp data model schema, and defines the spec name as tr-181-2-10-0.

Next comes a list of complex datatypes. In addition to the simple types provided by XML, this is where types specific to CWMP are built. This includes things like IPv4 and IPv6 addresses, MAC address, etc. Use these to determine any type and pattern restrictions on standard BBF datatypes.

Now let’s look at the model itself. This starts with the model element, giving the name of the model, in this case Device:2.10, and immediately starts with the Root object, “Device”.

Object Element Attributes

Every object contains some or all of several attributes. These attributes are important to understanding the purpose and requirements of the object. These include:

• Name: This is the full path name of the object. If it’s a multi-instance object, it will include variable instance signifier, {i} to indicate this. In a path name, child objects of multi-instance objects will also include these in the name in the data model. This signifier, however, is never used over-the-wire; it is always replaced by an actual instance number.
• Access: Indicates whether or not the object is creatable using the AddObject RPC, and can take a value of readOnly or readWrite.
• numEntriesParameter: The name of the parameter in a multi-instance object’s parent that indicates the number of instances of that object that exist. This is usually named by concatenating the name of the object with the phrase “NumberOfEntries”, for example, VendorConfigFileNumberOfEntries.
• minEntries: Describes how many instance of an object MUST exist. If it is zero, this object can be omitted in the device’s instantiated data model.
• maxEntries: Describes how many instances of an object MAY exist. For single instance objects, this has a value of 1. For multi-instance objects, it will be greater than 1, and may be “unbounded”.
• dm:version: Indicates in which version of the data model this object was added or edited.

Unique Keys

Multi-instance objects also contain a few elements other than parameters. Most notable are the “uniqueKey” elements. Since a multi-instance object can be considered a database table, the data model acts as a schema describing structure of entries in that table and the table itself. Unique Key elements are used to describe which parameters must be unique across the entire table; that is, that uniquely identify the object instance.

There are two kinds of unique keys; “functional” and “non-functional”. A functional unique key is a parameter that serves a purpose necessary to the function of the object, such as IPAddress in the IPv4Address table. A non-functional unique key is a parameter whose purpose is to provide a unique key, such as Name or Alias parameters.

An object’s unique key is the Union of all listed unique keys; for example, an IPAddress object has Alias, IPAddress, and SubnetMask all as unique keys.

 

Building or deploying TR-069?

Develop your solution even faster with the industry standard in automated, expert testing.

Learn more