Compatibility Features
Which parts of TR-369 the controller implements, and how we check
"USP compliant" is easy to print on a slide. This page says exactly which versions of TR-369, TR-181 and TR-106 the controller follows, which transports and message types it handles, and what we test it against.
Every release is run against the Broadband Forum's own OB-USP-Agent before it ships. If your vendor's agent started from that code, which most did, it will work.
Request a demo



Compatibility features
TR-369 version
The controller implements TR-369 Issue 1 Amendment 2 (January 2022) and still accepts agents written against earlier issues. When the Broadband Forum publishes the next amendment, we implement it; that is part of the support agreement, not an upsell.
Data model
TR-106 Amendment 11 and TR-181 Issue 2 Amendment 15. Because TR-069 uses the same Device:2 model, the parameters your ACS already knows carry over, which is what makes running CWMP and USP side by side workable.
TR-181 profiles
Cellular, DHCPv6, FAST, IEEE 802.1x, MQTT, PCP, UPnP, WWC, XMPP, ZigBee and the rest of the profiles in TR-181. If your devices expose it, the controller can read and write it.
Message transfer protocols
All three that the specification defines: MQTT 5.0 and 3.1.1, STOMP 1.2 and WebSocket (RFC 6455). MQTT runs on VerneMQ or Artemis, STOMP on Artemis, both clustered. A mixed fleet with some devices on MQTT and some on WebSocket is a normal configuration.
Message types
Get, Set, Add, Delete, Operate, Notify, GetSupportedDM, GetInstances and GetSupportedProtocol, encoded per usp-msg-1-2.proto and usp-record-1-2.proto. Earlier proto versions are still accepted. New ones are added when the Forum publishes them.
Bulk data
Collection over MQTT, USP EventNotify and HTTP, in CSV or JSON, as defined in Issue 1 Amendment 2. This is how you get telemetry off a million devices without a million Get requests.
Testing against OB-USP-Agent
OB-USP-Agent is the Broadband Forum's open-source reference agent and the starting point for most vendor agents. Our test suite drives it through every transport and message type on every release. If you have a device we have not seen, send it to us and we will add it to the bench.
Who built it
People who had already built a TR-069 ACS, worked with RDK devices and run telecom back ends. We read the specification as implementers, not as marketers, and we maintain TR369.org to share what we learned doing it.
In practice
You are not locked to one vendor's devices
Any agent that follows the specification works. That includes the ones you have not bought yet.
New amendments are our problem, not yours
We implement them as they are published, and old agents keep working.
No adapter layer to debug
There is no ACS underneath translating USP into CWMP. What you see on the wire is what the controller understands.
Odd devices get handled
Vendor-specific parameters and quirks exist. Tell us about yours and we will add support for them.
Have a device fleet in mind?
Send us the device models and the firmware versions. We will tell you which ones we have already tested, which ones we would want on the bench first, and whether anything in your data model needs attention before a pilot.
Write to us, or read how the controller is built.