What does TR-369 (USP) unlock for IoT and smart home services?

A home used to have one connected device for the operator to care about. Now it has a gateway, a few access points and a growing crowd of sensors, lights, plugs and thermostats. TR-369 was written for that home. Its executive summary notes that with smart phones, tablets, wearables and the emerging Internet of Things, the number of connected devices a household contains is growing “by several orders of magnitude” (§1.1). This guide covers what the specification gives operators to manage that crowd, and the services it opens up, using only what TR-369 says.

Why is IoT part of TR-369?

Because USP was designed around it. TR-369 says USP is designed for consumer electronics and IoT, home networks and gateways, smart Wi-Fi systems, and other value-added services and applications (§1.2.1). The first use case it lists is the management of IoT devices through re-usable data model objects (§1.1). The others point the same way:

• users who interact with their devices and services through customer portals, or through control points on their own smart devices;
• containerized microservices deployed and managed for end users;
• the application provider and the network service provider each managing the part of the service they are responsible for, which enables provider partnerships;
• a consistent user experience from mobile to home.

The impact the specification claims is just as direct. USP reaches into more and newer connected devices, including the management of their power, and “directly enables smart home, smart building, and other smart energy applications” (§1.6.1). The theory of operations for IoT control arrived with USP 1.1, in October 2019 (Issue History).

How does USP describe thousands of different devices?

With a few building blocks. There are thousands of different IoT devices, so the data model does not define one model per product. It describes each device by what it can sense and what it can control (Appendix V.1). The Device:2 data model defines generic capability Objects, and a small set of them covers a large ecosystem of devices. Each capability is an instance of Device.IoTCapability.{i}., with a Class and one Sub-Object of that class (Appendix V.2.1):

Each capability also carries a Type, a predefined value that says what it represents, such as a switch, a temperature or a battery, and level capabilities carry a Unit (Appendix V.4.1.1, V.4.1.2). A device made of several parts groups its capabilities in Node Objects: in the specification’s ceiling fan, one node is the light and the other is the fan (Appendix V.2.2, V.5.5).

What about devices that don’t speak USP?

Most sensors and lights will never run a USP Agent, and they don’t have to. The specification maps IoT devices in two ways (Appendix V.3):

• Individual devices. A device able to support its own USP Agent provides its own data model, exposes its sensor and control capabilities, and registers with the Controller as an individual entity (V.3.1). The specification’s battery-powered radiator thermostat works this way (V.5.7).
• Proxied devices. A device connected over another protocol, such as ZigBee, is modeled in the data model of the control device that hosts the USP Agent, as an instance of Device.ProxiedDevice.{i}. (V.3.2).

Each ProxiedDevice instance is a mount point for distinct hardware. Device.ProxiedDevice.1.TemperatureStatus. and Device.ProxiedDevice.2.TemperatureStatus. describe temperature sensors on two separate devices, and an IoT gateway can use the table for devices it reaches over Z-Wave, ZigBee, Wi-Fi and other technologies (Appendix III).

1. ControllerOperator or appSends USP Messages to the Agent on the gateway.
2. USP AgentIoT gatewayKeeps a USP representation of each device and translates to its own protocol.
3. Z-Wave · ZigBee · Wi-FiProxied devices
   • ProxiedDevice.1: thermostat
   • ProxiedDevice.2: light
   • ProxiedDevice.3: power strip

The gateway in this picture is what Appendix IV calls a USP to non-USP proxy. It keeps a USP representation of data from another management or control protocol, such as ZigBee, UPnP DM, NETCONF or RESTCONF, and exposes itself to the Controller as a full Agent (Appendix IV.5). Here is part of the specification’s A/C thermostat on Z-Wave, as a Controller sees it (Appendix V.5.1):

Device.ProxiedDevice.1.Type = "Thermostat"
Device.ProxiedDevice.1.ProxyProtocol = "Z-Wave"
Device.ProxiedDevice.1.IoTCapability.1.EnumControl.Value = "Cool"
Device.ProxiedDevice.1.IoTCapability.2.LevelControl.Value = 17
Device.ProxiedDevice.1.IoTCapability.6.LevelSensor.Value = 19.5

The cooling target is a LevelControl that declares a minimum of 14 and a maximum of 25 °C. Implementations have to publish those limits so the Controller can tell which values apply, and a StepUp() or StepDown() that would cross them stops at the limit instead of failing (Appendix V.4.2.2, V.5.1).

Can sensors act on their own?

They can do more than report a value. The sensor objects add thresholds, timing and routing (Appendix V.4.3, V.4.4):

• Thresholds. A BinarySensor with a Sensitivity turns its value to true when the measured value crosses the threshold and back to false when it drops below. The specification’s example is a carbon dioxide alarm (V.4.3.1.2). A LevelSensor can carry low and high thresholds too: a battery at 19 % with a low threshold of 20 reports LowLevel as true (V.4.3.2.2).
• Timing. HoldTime keeps a triggered state active for a minimum period, and RestTime ignores new triggers for a while after the first one, which tames a motion detector in continuous movement (V.4.3.1.3, V.4.3.1.4).
• Bindings. An IoTCapability Binding routes data from a sensor capability to a control capability of the equivalent class, such as BinarySensor to BinaryControl or LevelSensor to LevelControl. While the binding is enabled, each new sensor value updates the control. The specification calls it data flow orchestration between sensors and actuators (V.4.4).

1. SensorMotion detectedThe sensor capability updates its Value.
2. BindingEnabledRoutes the value to a control capability of the equivalent class.
3. ControlAlarm or lightThe control capability takes the new value.

In the specification’s examples, a motion sensor feeds an actuator such as an alarm or a light, whether the sensor is proxied by the gateway or runs its own Agent (Appendix V.5.8, V.5.9). A Controller that needs to know when a value changes subscribes to it like any other Parameter, as explained in USP notifications and subscriptions.

What services can an operator build on it?

This is where the data model turns into revenue. The specification’s own examples read like a product catalogue:

The last row is the one that changes the pace. Devices with execution environments such as Linux containers or Docker are often able to download new applications, possibly from third-party software providers, and USP manages their life cycle: install, activation, configuration, upgrade and removal (Appendix I). The specification is direct about why that matters: such applications can “increase the revenue per customer, help companies differentiate, and reduce churn”, as long as the gain is not offset by growing activation and support costs (Appendix I). Managing them with USP improves service time-to-market and reduces provisioning, support and maintenance costs (Appendix I). And modular software lets operators reduce device firmware versioning lead times, “typically 12 to 18 months”, and introduce new services at a much faster pace (Appendix VI.1).

What about devices that sleep?

Battery devices are not always online, and USP plans for that. The Connectivity Proxy and the MTP Proxy described in Appendix IV may cache USP Messages for Endpoints with intermittent connectivity and deliver them once the Endpoint is connected again. The messages are not altered, so no Endpoint has to know the cache exists (Appendix IV, IV.1, IV.3).

Finding devices is covered too. In the specification’s mDNS example, an Agent advertises itself under an _iot-device subtype with the friendly name “kitchen light” (§3.7.3). How Agents and Controllers find each other is explained in how a USP Agent finds its Controller.

Who controls the data from the home?

A home full of sensors is a home full of personal data. TR-369 defines privacy as the right to control what information is collected, processed and stored, and by whom, and says USP contains “rigorous access control and authorization mechanisms” so data is only used by those the user has enabled (§1.6.3). Security gets the same weight: the specification singles out high-risk smart applications, like medicine or emergency services, and builds its own security mechanisms into USP (§1.6.2). Each Controller, whether the operator’s or a partner’s, works within the Role an Agent grants it, as explained in TR-369 security.

Where should an operator start?

With the gateway. Proxied devices live in the data model of the device that hosts the USP Agent (Appendix V.3.2), and USP uses and expands the same Device:2 data model that TR-069 uses (§1.1, §1.2.2), so the road to IoT services can start from a device operators already manage. How the two protocols compare, and how a fleet can move from one to the other, is in TR-069 vs TR-369. For the foundations, start with what is TR-369.