Articles

Features of the Device 2.12 data model for TR-069 and USP

6 min read

In alignment with the release of TR-069 Amendment 6 and the User Services Platform/TR-369, the Broadband Forum updated its comprehensive data model that describes CWMP endpoints or USP agents. There’s a number of new features, some of which are tied to updates to CWMP, as well as new interfaces and applications that are managed by CWMP or USP. Here’s a short overview of the changes in Device:2.12.

Support for USP/TR-369

The User Services Platform, specified in TR-369, was released in April 2018. It makes use of the Device:2 data model, with some minor differences in the way that features like firmware updates, events and notifications, and object-defined commands (like diagnostics) are handled.

To facilitate this, the Device:2 data model is now generated separately for USP and CWMP. Starting from the same base, the models are built in their entirety when they are released. You can find the USP data model and CWMP data model on their respective websites.

How do data models work?

Data models are documents in a particular markup language (for example, XML) that are used to describe the objects, parameters, and arguments of certain software solutions - a type of API.

For TR-069 and USP, these models describe the interfaces, features, and operations that can be read and manipulated by these protocols. You can learn more about the data model for TR-069 and the data model for USP in our training series.

Firmware image table

TR-069 Amendment 6 introduced a new way to handle upgrading the firmware on a device. Commonly known as “firmware banks”, a device can now be told (using the 6 Stored Firmware Image file type in the Download RPC) to download firmware and store it locally in a non-active firmware location for an upgrade window in the future. This lets the device store the older image, if necessary, for rollback purposes.

This is managed in the data model using the Device.DeviceInfo.FirmwareImage.{i}. object to store information about the available firmware images. In CWMP, an ACS can set which firmware to be activated upon the next reboot of the device by using the Device.DeviceInfo.BootFirmwareImage parameter, which sets a reference to one of the object instances in the FirmwareImage table. The ACS can then use the Reboot RPC to trigger the device to load the new firmware.

In USP, things operate a little differently; with the addition of commands, a USP Controller can use the Operate message to perform the Device.DeviceInfo.FirmwareImage.{i}.Download() command, then when it is ready for the Agent to update its firmware, it can use the Device.DeviceInfo.FirmwareImage.{i}.Activate() command. Like in CWMP, you can find the whole object definition here.

Heartbeat event support

TR-069 Amendment 6 also introduced a new event code: 14 HEARTBEAT. Similar to 2 PERIODIC, the heartbeat event is designed to trigger the CWMP endpoint to contact the ACS when certain heartbeat policies are met. Heartbeat is built mostly around using an absolute time reference to configure the “phase” the heartbeat policy (for example, at midnight), and the interval at which it should call the Inform RPC reporting the 14 HEARTBEAT event.

The key to the HEARTBEAT event, versus the PERIODIC event, is that the CPE must not deliver any other events with the heartbeat. This was designed to remove the burden from the ACS to process other events when it simply requires a periodic notification from the CPE.

An outline of how HEARTBEAT is meant to behave is specified in Annex O of TR-069 Amendment 6. The initiation time and interval are set in the data model, handled by the Device.ManagementServer.HeartbeatPolicy. object.

L2TPv3 interface

The Layer 2 Tunneling Protocol Version 3 is a type of L2TP implementation specifically designed to fit the requirements of broadband carriers, often as an alternative to MPLS to encapsulate layer 2 traffic.

Device:2.12 provides an interface definition of this protocol so that it can be managed by a TR-069 ACS or USP controller. You can find the whole object as defined for CWMP here or for USP here.

VXLAN tunnels

Virtual Extensible LAN is a type of virtual LAN system designed to be scalable for cloud environments. It provides a layer 2 overlay network on top of a layer 3 network by encapsulating MAC addresses in a special UDP frame (MAC-in-UDP).

Device:2.12 provides an interface definition of this protocol so that it can be managed by a TR-069 ACS or USP controller. You can find the whole object as defined for CWMP here or for USP here.

Large-scale measurement of broadband performance (LMAP) support

The other major feature support added in Device:2.12 is for the LMAP protocol. This protocol was designed by the IETF as a standardized implementation of the measurement architecture defined by the Broadband Forum in TR-304, or “Broadband Access Service Attributes and Performance Metrics”.

This works by having a system of measurement agents (MAs), and measurement controllers that coordinate the sourcing and sinking of performance test traffic between measurement agents (or measurement peers), who then deliver the results to a data collector. You can see the layout of these components here:

 tr 304 diagram

The Device:2.12 data model specifies the objects and parameters for a TR-069 ACS or USP controller to manage measurement controllers and to create, manage, and initiate the tests performed by measurement agents..

You can find the whole object as defined for CWMP here or for USP here.

Can I see the changes myself?

Is it too much to look at in the full data model? With each new version of the Device:2 data model, the Broadband Forum produces both a full version of the data model in html, plus a “diffs” version that will show you just the changes since the last version. Take a look at the differences yourself with these links (keep in mind the USP diffs contain the full data model, since it’s all new support!):

  • CWMP Device:2.12 data model changes
  • USP Device:2.12 data model changes.

Are you developing TR-069 or USP solutions? CDRouter is the industry standard for testing both of these powerful management protocols. Contact us for a free demo and power through your test process even faster.