What is TR-369, the User Services Platform (USP)?

If you manage ONTs, home gateways or Wi-Fi systems, you will keep running into two numbers: TR-069 and TR-369. The first is the protocol most customer devices in the field speak today. The second, TR-369, is the Broadband Forum specification of the User Services Platform (USP). This guide explains what it defines, how it works and where it meets TR-069, using only what the specification itself says.

What does TR-369 actually define?

TR-369 describes “the architecture, protocol, and data model that build an intelligent User Services Platform” (§1.1). Its stated purpose is broad: USP is designed for consumer electronics and IoT, home networks and gateways, smart Wi-Fi systems, and for deploying and managing other value-added services and applications (§1.2.1).

The specification lists the use cases it supports (§1.1):

• Managing IoT devices through re-usable data model objects.
• Letting users interact with their devices and services through customer portals or control points on their own smart devices.
• Deploying and managing containerized microservices through software modularization and USP-enabled applications.
• Letting both the application provider and the network service provider manage the parts of a service they are responsible for, which enables partnerships between providers.
• A consistent user experience from mobile to home.
• Simple migration from CWMP (TR-069), through the same data model and data modeling tools.

Within that scope it covers the architecture, how Controllers interact with a device’s data model, the structure of Records and Messages, the bindings to the transports that carry them, discovery, security and encryption, and a set of extensions: proxying, software module management, firmware lifecycle management, bulk data collection and an IoT theory of operations (§1.2.2).

Who talks to whom: Agents and Controllers

Everything in USP is an Endpoint, and every Endpoint acts as one of two roles (§2.1):

• An Agent “is an Endpoint that exposes Service Elements to one or more Controllers” (§1.4). In practice it is the software on the managed device. It holds an Instantiated Data Model, the current state of what it represents, and a Supported Data Model, what it is able to represent (§2.1.1).
• A Controller “is an Endpoint that manipulates Service Elements through one or more Agents” (§1.4). It may keep a database of Agents, their capabilities and their states, and it usually serves a user application or a policy engine (§2.1.2).

The direction is fixed: Controllers only send messages to Agents, and Agents send messages to Controllers (§2.1).

1. ControllersOperator platform, customer app, partner serviceRead, configure and operate the device, each with its own role.
2. Message Transfer ProtocolThe channel
   • WebSocket
   • MQTT
   • STOMP
   • UNIX Domain Socket
3. AgentOn the deviceExposes Service Elements: the Objects, Parameters, Commands and Events of its data model.

That “one or more” matters. In TR-069, a device reports to a single Auto-Configuration Server (ACS). The specification points out the difference itself: because CWMP has only one ACS, a device does not notify the ACS of value changes the ACS caused, while in USP an Agent follows each subscription “regardless of the originator” (§7.6.1). A device can serve the operator, the customer’s app and a partner at the same time, each with its own permissions.

Each Endpoint is identified by an Endpoint ID built as authority-scheme:[authority-id]:instance-id, for example oui:00256D:my-unique-bbf-id-42 (§2.2). We break down the format in USP Agent vs Controller.

How do USP messages travel?

USP separates what is said from how it is carried. Three layers sit inside each other:

Message Transfer ProtocolWebSocket, MQTT, STOMP or UNIX Domain Socket carries the Record as its payload.

USP RecordCarries the USP version and the source and target Endpoint IDs, plus metadata for integrity, payload protection and segmentation.

• version
• to_id
• from_id

USP MessageExactly one header and one body. The body is a Request, a Response or an Error.

• header
• body

The Message Transfer Protocol (MTP) is the protocol below USP that carries it. The name was chosen “to avoid confusion with the term ‘Transport’”, which is often used for both the application layer, such as WebSocket, and the OSI transport layer, such as TCP (§4). The current specification defines four MTPs: WebSocket, STOMP, MQTT and UNIX Domain Socket. A fifth, CoAP, was deprecated in USP 1.2 because it “can only be used in local area networks under narrow conditions”, and obsoleted in USP 1.3 (§4.2).

An Agent and a Controller may support more than one MTP, and Endpoints always answer on the same MTP the message arrived on (§4.1.1). Records and Messages are serialized with Protocol Buffers version 3, using the schemas usp-record-1-5.proto and usp-msg-1-5.proto (§5). For a side-by-side look at the four transports, read USP transports compared.

Which messages does USP use?

USP is built on a CRUD model, create, read, update and delete, plus an operations mechanism and a notification mechanism: CRUD-ON (§2). The specification defines eleven request types (§7.3.3.2):

Each request gets a Response or an Error. Register and Deregister arrived in USP 1.3, mainly for software modularization (Issue History). Notifications are covered in USP notifications and subscriptions.

What does TR-369 have to do with TR-069?

TR-069 is the CPE WAN Management Protocol (CWMP). The TR-369 specification names “simple migration from the CPE WAN Management Protocol (CWMP) – commonly known by its document number, ‘TR-069’ – through use of the same data model and data modeling tools” as one of its use cases (§1.1). USP supports the Device:2 Data Model, specified in TR-181 Issue 2, with the schema and rules for Objects, Parameters, Events and Commands defined in TR-106 (§2.4).

So a support engineer who knows where TR-069 keeps a device’s Wi-Fi or WAN settings will find them under the same Device. paths in USP. What changes is everything around the data model: who can talk to the device, how messages travel, and how they are secured. The specification even keeps a CWMP mechanism, the exchange of GatewayInfo over DHCP, so that a USP Agent and a CWMP client on the same LAN can recognize each other (§3.4).

We compare the two side by side in TR-069 vs TR-369.

How is USP secured?

The specification treats security as part of the protocol, not an add-on. Because USP links components that may also use protocols outside its scope, “security must be considered from end-to-end”, so “USP contains its own security mechanisms” (§1.6.2). It works at three levels:

• The transport. An MTP must use secure transport when messages cross inter-network boundaries, and MTPs that run over TCP are expected to implement at least TLS 1.2 (§4.1.2).
• End to end. Secure Message Exchange runs TLS inside USP Records, so a message stays protected between the two Endpoints even when it passes through brokers or proxies (§6.4).
• Authorization. Controllers are authenticated, and every Controller is granted roles that set what it may read, write, operate or subscribe to (§8).

On privacy, the specification states that USP contains “rigorous access control and authorization mechanisms to ensure that data is only used by those that have been enabled by the user” (§1.6.3). The details are in TR-369 security.

What else does the specification cover?

Beyond the core protocol, TR-369 includes theories of operation for jobs that operators run every day:

• Firmware lifecycle management: downloading and activating firmware images, including devices with more than one image. See firmware upgrades with USP.
• Bulk data collection: periodic reporting of large sets of data model values (Annex A).
• Software module management: installing, updating and removing software on the device (Appendix I).
• Proxying and IoT: Agents that represent devices reached through other protocols (Appendices IV and V).
• Software modularization: services on the device that expose their own data model through a USP Broker (Appendix VI).

And before any of this, an Agent has to find its Controller. That process, discovery through DHCP, DNS or mDNS, is explained in how a USP Agent finds its Controller.