TR-069 Review

Overall review of TR-069 to understand if we can use it as a provisioning / update protocol and if yes how we would implement it.

Glossary

Primary Capabilities

End-to-end Architecture

Base Model

Proxy Management

Virtual CWMP Device

Embedded Object

Virtual CWMP Device vs Embedded Object

Object Model and Operations

Baseline Operations

Implemented by the CPE

Implemented by the ACS

Additional Operations

Implemented by the CPE

Implemented by the ACS

Session Handling

CPE Initiated Session

ACS Initiated Session

ACS Discovery

OpenTRV Commissioning

Future Use Cases for OpenTRV

Limitations

Glossary

Acronym

Expanded

Details

CPE

Customer Premises Equipment

Equipment on customer premises that is being managed by the TR-069 protocol

ACS

Auto-Configuration Server

Server that orchestrate secure auto-configuration and general management of CPE

CWMP

CPE WAN Management Protocol

 

Primary Capabilities

End-to-end Architecture

Base Model

Selection_823.png

CWMP assumes that all managed devices are connected to an IP network and have a full network stack. At first glance, this disqualifies low power devices that run on a different communication protocol. However, CWMP also includes a proxy model for just that situations.

Proxy Management

Selection_828.png

In this deployment model, the CPE Proxier acts as a bridge between the IP network and the proxied devices using a non-IP protocol (such as RF radio). This fits the device + concentrator model of OpenTRV. Each proxied device can be exposed to the ACS using one of two mechanisms:

Virtual CWMP Device

The proxier acts on behalf of the device and any virtual device operates exactly as a normal device as far as the ACS is concerned. This is done through a special data structure:

Selection_829.png

Embedded Object

The proxier exposes proxied devices through a collection of embedded objects, i.e. special data structures that holds the configuration of each proxied device.

Virtual CWMP Device vs Embedded Object

Guidelines on how to choose the implementation (the same proxy can implement a mix of both):

  1. The Proxied Devices that are not able to uniquely be identified by their local Proxy Protocol beyond the transport assigned address (such that they are not uniquely identified when removed and re-inserted into the Proxy Protocol network) MUST use Data Model Objects to provide proxy support.
  2. The Proxied Devices that do not use an interface stack to model their connectivity or features SHOULD use Data Model Objects to provide proxy support.
  3. The Proxied Devices that might provide no support of a reboot, factory reset and/or a download command SHOULD use Data Model Objects to provide proxy support. If such a command is needed it could be reflected in the associated Data Model, see Section I.3.4.
  4. The Proxied Devices that support optional RPCs such as ChangeDUState SHOULD NOT use Data Model Objects to provide proxy support.

Object Model and Operations

Device management is done through an object model, which works in a very similar way to a Java properties object: each parameter is a key/value pair with key hierarchy identified by a dot notation (e.g. Device.ProxierInfo.SerialNumber).

Configuration is done via SOAP RPC calls between the ACS and CPE. As most of them intend to modify the configuration of the CPE, they are implemented by the CPE. The ACS implements a small number of notification methods.

Baseline Operations

Baseline operations are mainly get and set operations on parameters or meta-parameters (e.g. whether a given parameter is read-only or read-write) plus generic download and reboot operations.

Implemented by the CPE

Method

Use in OpenTRV context

SetParameterValues

Modify config

GetParameterValues

Read config

GetParameterNames

Read list of accessible config parameters

SetParameterAttributes

Modify attributes of config parameters (access permissions)

GetParameterAttributes

Read attributes of config parameters (access permissions)

AddObject

Add items in list

DeleteObject

Remove items from list

Download

Download file (e.g. full config)

Reboot

Reboot the device

Implemented by the ACS

Method

Use in OpenTRV context

Inform

Initiate session

TransferComplete

Notify of completion of transfer

AutonomousTransferComplete

Notify of completion of transfer when initiated by CPE

Additional Operations

Additional operations allow more complex interactions between ACS and CPE such as scheduling and optional package management.

Implemented by the CPE

Method

Use in OpenTRV context

ScheduleInform

Ask the device to schedule communication at a later time

Upload

Ask the CPE to upload data to specified location

FactoryReset

GetAllQueuedTransfers

Request status of all queued transfers

ScheduleDownload

Request download at a later time

CancelTransfer

Cancel an ongoing or scheduled file transfer

ChangeDUState

Plugin or optional package management

Implemented by the ACS

Method

Use in OpenTRV context

RequestDownload

Enables the CPE to explicitly request a file download

DUStateChangeComplete

Notification of DU state change

AutonomousDUStateChangeComplete

Same as above when initiated by CPE

Session Handling

Communication between a CPE and ACS is done through a session mechanism. This can either be initiated by the  CPE or the ACS.

CPE Initiated Session

A CPE initiates a session using an Inform message. The CPE is expected to authenticate with the ACS using pre-shared credentials. Authentication methods can be:

The CPE user name is expected to be one of the following forms:

Password should be unique per CPE and known by both CPE and ACS.

tr-069-connection-establishment-cpe.png

ACS Initiated Session

The ACS can issue a connection request to a CPE, in which case the CPE is expected to reply with an Inform message within 30 seconds.

tr-069-connection-establishment-ACS.png

In cases where there is no inbound connection to the CPE (e.g. behind a firewall or NAT gateway), regular polling can be used by the CPE but the protocol doesn’t rely on this and proposes an alternative solution based on XMPP.

Selection_830.png

ACS Discovery

OpenTRV Commissioning

The primary goal for OpenTRV using TR-069 is to simplify commissioning. One way to implement this would be through the following process:

  1. CPE holds a bootstrap configuration file with pre-shared password and URL of the ACS,
  2. CPE (concentrator) initiates connection to ACP on boot with pre-shared password,
  3. ACS sends download query to CPE so that the CPE downloads a complete configuration file,
  4. CPE restarts with new configuration file.

This process could then be improved further in subsequent releases to allow the ACS to auto-detect what devices are connected and configure each parameter individually.

Future Use Cases for OpenTRV

Implementing such a protocol could also unlock a number of future use cases for OpenTRV:

Limitations

As the protocol relies on SOAP-RCP, it can be quite onerous to implement. This is mitigated by the fact that the list of essential functions is small and targets very simple operations on the CPE.

The initial mechanism to share the CPE password is not specified and feels like the weakest link in the security chain. How this is implemented with require careful consideration both in terms of security and usability for installers.

Security

Should OpenTRV implement TR-069, we will need a security review of the implementation: http://www.pcworld.com/article/2463480/many-home-routers-supplied-by-isps-can-be-compromised-en-masse-researchers-say.html