Content
TR-369, also called User Services Platform (USP), like its predecessor TR-069, is a protocol standard developed by Broadband-Forum for the management and analysis of devices connected to a network.
The User Services Platform is a standardized protocol for managing, monitoring, upgrading, and controlling connected devices. USP allows service providers, consumer electronics manufacturers, and end users to:
- Create interoperable and vendor-independent managed Wi-Fi systems.
- Perform lifecycle management of consumer connected devices and containerized microservices.
- Support independent applications for application-enabled services gateways.
- Enable IoT and consumer electronics upgradability for critical security patches.
- Develop applications that gather the telemetry necessary to mass data processing, AI, and machine learning.
- Bootstrap and configure newly installed or purchased devices and applications.
- Let customer support monitor and troubleshoot connected devices, services, and home network links.
- Easily map the home network to control service quality and monitor threats.
- Securely control IoT, smart home, and smart networking functions locally or from the Cloud.
- Enable multi-tenant (i.e., multi-stakeholder) management and control.
USP represents the natural evolution of the Broadband Forum’s CPE WAN Management Protocol (CWMP), commonly known as TR-069. It uses an expanded version of the Device:2 Data Model to represent device operations (firmware upgrades, reboots, etc.), network interfaces, and service functions (IoT functions, VoIP-phones, etc.).
Index:
Architecture
USP endpoints
The User Services Platform consists of a collection of Endpoints (Agents and Controllers) that allow applications to manipulate Service Elements. These Service Elements are made up of a set of Objects and Parameters that model a given service, such as network interfaces, software modules, device firmware, remote elements proxied through another interface, virtual elements, or other managed services.
A USP Endpoint can act as Agent or a Controller. Controllers only send messages to Agents, and Agents send messages to Controllers. A USP Endpoint communicates with other Endpoints over one or more Message Transfer Protocols (MTP). This communication is secured by the MTP, or by the use of a USP Session Context, or both.
Data models
USP is designed to allow a Controller to manipulate Service Elements on an Agent using a standardized description of those Service Elements. This standardized description is known as an information model, and an information model that is further specified for use in a particular protocol is known as a “Data Model”.
In order to be able to continue to use the old TR-069 protocol, the Device:2 data model was adopted and expanded from its predecessor. TR-369 can therefore act in parallel to TR-069.
USP Controller information
An Agent that has a USP relationship with a Controller needs to obtain information that allows it to determine at least one MTP, IP address, port, and resource path (if required by the MTP) of the Controller. This may be a URL with all of these components, a FQDN that resolves to provide all of these components via DNS-SD records, or mDNS discovery in the LAN.
The Agent can be pre-configured with trusted root certificates or trusted certificates to allow authentication of Controllers. Other trust models are also possible, where an Agent without a current Controller association will trust the first discovered Controller, or where the Agent has a UI that allows a User to indicate whether a discovered Controller is authorized to configure that Agent.
Message Transfer Protocols (MTP)
USP messages are sent between Endpoints over one or more Message Transfer Protocols. Agents and Controllers may support more than one MTP. When an Agent supports multiple MTPs, the Agent may be configured with Parameters for reaching a particular Controller across more than one MTP. When an Agent needs to send a Notification to such a Controller, the Agent can be designed (or possibly configured) to select a particular MTP, to try sending the Notification to the Controller on all MTPs simultaneously, or to try MTPs sequentially. USP has been designed to allow Endpoints to recognize when they receive a duplicate message and to discard any duplicates. Endpoints will always send responses on the same MTP where the message was received.
By using MTPs as an independent transport layer of the USP protocol, the Agent and Controller can agree on the optimal communication protocol for the respective application. The list of MTPs are currently specified for the following standardised protocols: STOMP, CoAP, MQTT, and WebSockets.
USP messages and encoding
All USP Messages are encapsulated by a USP Record. The definition of the USP Record portion of a USP Message can be found in Record Definition section of the USP specification document, and the rules for managing transactional integrity are described in End to End Message Exchange section of the USP specification document.
The three types of USP Messages are Request, Response, and Error. A request is a Message sent from a source USP Endpoint to a target USP Endpoint that includes fields to be processed and returns a response or error. Unless otherwise specified, all requests have an associated response. Though the majority of requests are made from a Controller to an Agent, the Notify and Register Messages follow the same format as a request but is sent from an Agent to a Controller.
The USP Record is defined as the Message Transfer Protocol (MTP) payload, encapsulating a sequence of datagrams that comprise the USP Message as well as providing additional metadata needed for integrity protection, payload protection and delivery of fragmented USP Messages. Additional metadata fields are used to identify the E2E session context, determine the state of the segmentation and reassembly function, acknowledge received datagrams, request retransmissions, and determine the type of encoding and security mechanism used to encode the USP Message.
USP requires a mechanism to serialize data to be sent over a Message Transfer Protocol. The description of each individual USP Message and the USP Record encoding scheme is covered in the Message Encoding section of the USP specification document. The currently used encoding of the specification is Protocol Buffers Version 3. A USP Message consists of a header and body. When using Protocol Buffers, the fields of the header and body for different Messages are defined in a schema and sent in an encoded format from one USP Endpoint to another.
TR-369 Supported Models
- D862
- D865
- D892
- D895
- D787
- D735
- D717
- D713
Common operations
The whole provisioning is built on top of a defined set of simple operations.
| Messages (Request/Response) | Description |
|---|---|
| Get / GetResp | Used to retrieve the values of a set of Object’s Parameters in order to learn an Agent’s current state. It takes a set of Path Names as an input and returns the complete tree of all Objects and Sub-Objects of any Object matched by the specified expressions, along with each Object’s Parameters and their values. The Search Paths specified in a Get request can also target individual Parameters within Objects to be returned. |
GetSupportedDM / GetSupportedDMResp | Used to retrieve the Objects, Parameters, Events, and Commands in the Agent’s Supported Data Model. This allows a Controller to learn what an Agent understands, rather than its current state. |
| GetInstances / GetInstancesResp | Takes a Path Name to an Object and requests that the Agent return the Instances of that Object that exist and possibly any Multi-Instance Sub-Objects that exist as well as their Instances. This is used for getting a quick map of the Multi-Instance Objects (i.e., Tables) the Agent currently represents, and their Unique Key Parameters, so that they can be addressed and manipulated later. |
| Set / SetResp | Used to update the Parameters of existing Objects in the Agent’s Instantiated Data Model. |
| Add / AddResp | Used to create new Instances of Multi-Instance Objects in the Agent’s Instantiated Data Model. |
| Delete / DeleteResp | Used to remove Instances of Multi-Instance Objects in the Agent’s Instantiated Data Model. |
| Operate / OperateResp | Additional methods (operations) are and can be defined in the USP data model. Operations are generally defined on an Object, using the “command” attribute. The mechanism is controlled using the Operate Message in conjunction with the Multi-Instance Request Object. |
| Notify / NotifyResp | A Controller can use the Subscription mechanism to subscribe to certain events that occur on the Agent, such as a Parameter change, Object removal, wake-up, etc. When such event conditions are met, the Agent may either send a Notify Message to the Controller, update its own configuration, or perform both actions depending on the Subscription’s configuration. |
| GetSupportedProtocol / GetSupportedProtocolResp | Used as a simple way for the Controller and Agent to learn which versions of USP each supports to aid in interoperability and backwards compatibility. |
| Register / RegisterResp Deregister / DeregisterResp | An Agent-to-Controller message used to register and deregister new Service Elements. |
High-level operations possible through TR-369
- Service activation and reconfiguration
- Initial configuration of the service as part of zero-touch or one-touch configuration process
- Service re-establishment (ex. after device is factory-reset, exchanged)
- Remote Subscriber Support
- Verification of the device status and functionality
- Manual reconfiguration
- Firmware and Configuration Management
- Firmware upgrade/downgrade
- Configuration backup/restore
- Diagnostics and monitoring
- Throughput (TR-143) and connectivity diagnostics
- Parameter value retrieval
- Log file retrieval
Sources:
Further Information
Related articles
Overview
Content Tools
Tasks
