1 of 33

CONNECTIONS 2022

Device Management Standards and Technology

Jason Walls

QA Cafe

Broadband User Services Work Area Director at BBF

2 of 33

Let’s talk about SNMP and NETCONF

  • Simple Network Management Protocol evolved to NETCONF
  • Management Information Base became YANG data models
  • Well known by IETF
  • Push and apply configurations
  • Read data
  • XML based with JSON support
  • Runs over TCP

3 of 33

Things change the closer you get to consumer networking

  • Security systems
  • Other IoT/automation products
  • User devices
  • Wi-Fi access points and mesh

4 of 33

Device management has different needs

  • Real-time, incremental configuration
  • Onboarding/bootstrap
  • Lifecycle management
  • “Sleepy” or intermittent connection
  • Crossing network boundaries/NAT
    • Can’t rely solely on TCP

5 of 33

The User Services Platform is a system of Controllers and Agents that enables remote manipulation of software and hardware capabilities.

6 of 33

A bit of history

ISPs see need for life-cycle management, monitoring, and provisioning for gateway routers. CWMP (TR-069) is born.

TR-069 expands to manage more interfaces and more devices, like STB, VoIP, Wi-Fi, and more.

Cable/MSOs incorporate TR-069 for management of advanced gateways/Wi-Fi using Device:2 data model.

Explosion of new technologies and challenges for both networking and consumer electronics: IoT, Wi-Fi/Mesh, handling over-the-top and third party services, and desire for end-user control. USP created in 2018.

2016

2014

2012

2010

2008

2006

2004

2018

USP 1.2 released with Device:2.15. Valuable for consumer electronics as well as CSPs for analytics, customer self-care, onboarding, real-time IoT control, managed Wi-Fi, and more.

USP 1.2

CPE

ACS

CWMP

7 of 33

A little TR-069 history

  • SOAP over HTTP to make Remote Procedure Calls
  • Single Autoconfiguration Server (ACS)
  • ConnectionRequest mechanism (later expanded to XMPP)
  • RPCs defined in XML schema
  • Legacy TR-098 data model moved to TR-181 Device:2
  • NBI not standardized
  • Over 1 billion deployments today

8 of 33

USP features

  • Multi-USP-controller, multi-USP-agent architecture
  • Secure, end-to-end messaging
  • Flexible, extensible commands and events
  • No dependency on cloud
  • Co-existence with TR-069
  • Robust proxy mechanism
  • Northbound REST API into USP Controllers
  • Clear lines between layers

9 of 33

10 of 33

What makes up the User Services Platform?

TR-369

User Services Platform

https://usp.technology/

TR-181 Issue 2

Device:2 Data Model

BBF.369 Certification

Self-certification program (TP-469)

OB-USP-Agent

Open-source reference implementation (if desired)

Standards

Testing

Open-source

11 of 33

USP enables all uses to coexist within single ecosystem

Internet

Broadband Network

USP Controller as ACS, or co-existence with TR-069

Third party MSP, vendor, or application provider

Mobile end-user with app on computing device

Local end-user with app on computing device

Data collector

Device and application capabilities managed and controlled with standard TR-181 data model, directly or by proxy

USP messages

JSON bulk data over HTTP, MQTT, or over USP Notify messages

USP messages

USP messages

USP messages

USP messages

Non-USP Device

  • Network setup and config
  • Network, security and privacy control
  • Software container management
  • Wi-Fi management
  • Firmware and software upgrades
  • Diagnostic commands
  • Bulk data telemetry
  • Custom commands & events
  • IoT sensors and controls

TR-181/Device:2 Data Model Capabilities

USP Controllers and USP Agents have:

  • Persistent connections to reduce handshakes
  • Clear trust relationship establishment
  • Optional end-to-end application layer TLS session context
  • Rule-based access control to service elements for privacy and security
  • Flexible transport that can be cloud independent or not

USP Agents

Modeled proxy device

12 of 33

TCP or UDP�(depending on MTP)

TLS or DTLS�(depending on MTP)

Message Transfer Protocol

(STOMP, MQTT, WebSocket)

Optional Session Context with TLS

USP Record

(Protobuf encoding with

schema usp-record.proto)

USP Message

(Protobuf encoding with schema usp-msg.proto)

Controller A

Controller Endpoint

Message Transfer

Protocol

Agent Database

Application/

Policy Engine

Data Collector

Controller B

MTP

Agent Endpoint

Supported

Data

Model

Instantiated

Data

Model

Service Elements

Network Interfaces, Managed Services, Software Modules, Firmware, Proxied Devices modeled in Device:2 (TR-181)

USP Agent

MTP Proxy

  • Add
  • Set
  • Delete
  • Get
  • GetSupportedDM
  • GetInstances
  • Operate
  • Notify

USP 1.2 Architecture

USP 1.2 Protocol Stack

Optional REST API

Other applications/automation

Bulk Data Collector Endpoint

Optional

HTTP Bulk Data Client

TR-069 ACS

Co-existing TR-069 Endpoint

13 of 33

USP specification

  • General architecture and Object Path syntax for Service Elements (in context of TR-181 device data model)
  • Endpoint discovery
  • Message transfer protocols
  • Message encoding
  • End-to-end message exchange
    • USP Record

  • Messages
    • Types, syntax, and expected behavior
    • Error handling
    • Notifications and operations
  • Authentication & Authorization
  • Theories of operation for common features (bulk data, software module management, firmware management, IoT)

14 of 33

What is a Service Element?

  • Objects
    • Parameters
    • Events
    • Commands

Wi-Fi Configuration

Performance Diagnostics

Smart Home Functions

15 of 33

Object path syntax

  • Defines how to address objects and parameters in the data model
    • Single objects vs. multi-instance objects (table)
  • Object Path, Object Instance Path, Parameter Path, Command Path, Event Path
  • Address by instance ID or by defined unique keys
  • Search Paths allow for criteria based selection of table rows

[Stats.ErrorCount>1000]

Device

.

WiFi

.

Radio

.

.

Stats.

16 of 33

TR-181 Device:2 Data Model

  • Defined in XML according to TR-106 data model schema
  • Re-used to allow for compatibility and co-existence with TR-069
  • Common components the same for TR-069 and USP built into different data models for each protocol
    • Relevance of core protocol objects/parameters/features
    • USP allows for data model definition of commands and events
  • Allows for vendor extensions, but updated frequently by BBF
  • Some work in BBF on TR-181 to YANG translation

17 of 33

Supported Data Model

Defines which Service Elements an Agent understands

Retrieved with the GetSupportedDM message

18 of 33

Describes the Agent’s current state

Retrieved with Get and GetInstances messages

Instantiated Data Model

19 of 33

Role Based Access Control

  • Defines what a controller can do with the instantiated data model
  • Key difference from TR-069 and other protocols
  • Necessary for multi-use-case (multi-controller) architecture
  • Controllers have role-based Read/Write/Execute access on a granular (down to the parameter, if necessary) level
  • Ties in with authentication and authorization mechanisms

20 of 33

Message Transfer Protocols (MTP)

  • Not to confuse with “transport”
  • Three available for different deployments and use cases
  • MQTT, STOMP, Websocket
  • CoAP deprecated in 1.2
  • TLS at MTP layer or E2E TLS session context

21 of 33

Why end-to-end session context?

  • Message integrity and encryption at USP layer
  • Used when crossing message brokers or proxies
  • Protection from MITM attacks
  • Uses USP records to manage

22 of 33

Google Protocol Buffers

message Get {

repeated string param_paths = 1;

}

message GetResp {

repeated RequestedPathResult req_path_results = 1;

message RequestedPathResult {

string requested_path = 1;

fixed32 err_code = 2;

string err_msg = 3;

repeated ResolvedPathResult resolved_path_results = 4;

}

message ResolvedPathResult {

string resolved_path = 1;

map<string, string> result_params = 2;

}

}

23 of 33

The USP Record

  • Specified in usp-record.proto

  • Source and destination

  • Session context

  • Security

24 of 33

The USP Record

Record {

version 1.2

to_id proto::<agent-id>

from_id proto::<controller-id>

payload_security PLAINTEXT

record_type {

no_session_context {

payload .. .. ..

25 of 33

The USP Message

  • Specified in usp-msg.proto
  • Requests
  • Responses
  • Errors
  • Use “allow_partial” and “required parameters” to determine state flexibility

26 of 33

header {

msg_id: "52867"

msg_type: ADD

}

body {

request {

add {

allow_partial: true

create_objs {

obj_path: "Device.WiFi.SSID."

param_settings {

{

param: "LowerLayers"

value: "Device.WiFi.Radio.1."

required: true

}

{

param: "SSID"

value: "NewSSIDName“

required: true

}

}

}

}

}

}

header {

msg_id: "52867"

msg_type: ADD_RESP

}

body {

response {

add_resp {

created_obj_results {

requested_path: "Device.WiFi.SSID."

oper_status {

oper_success {

instantiated_path: ""Device.WiFi.SSID.4."

{

unique_keys {

{

key: "BSSID"

value: "112233445566"}

{

key: "Name"

value: "GuestNetwork1"}

{

key: "Alias"

value: "cpe-alias-1"}

}

}

}

}

}

}

Add Request

Add Response

27 of 33

Message flexibility with allow_partial & required_parameter

Add

Set

Delete

allow_partial?

required_parameter?

28 of 33

Agent

Controller

allow_partial: false

USP Add/Set/Delete

“Don’t do any of this if at least one object fails.”

“At least one object failed.”

USP Error

29 of 33

Agent

Controller

allow_partial: true

USP Add/Set/Delete

“Do what you can even if some of it fails.”

“At least one object failed.”

USP AddResp/SetResp/DeleteResp

w/oper_failure

30 of 33

Bulk data collection

  • Configure using the Device.BulkData. object
  • Set target and format (JSON or CSV)
  • Can be done over HTTP, MQTT, or via USP notify
  • Very useful mass telemetry and network optimization, particularly Wi-Fi

31 of 33

But let’s talk about Wi-Fi management

  • The biggest pain point right now
  • BBF collaboration with WFA through join members
  • Wi-Fi Alliance Data Elements KPIs and configuration capabilities now modeled in Device:2.15

32 of 33

USP enables all uses to coexist within single ecosystem

Internet

Broadband Network

USP Controller as ACS, or co-existence with TR-069

Third party MSP, vendor, or application provider

Mobile end-user with app on computing device

Local end-user with app on computing device

Data collector

Device and application capabilities managed and controlled with standard TR-181 data model, directly or by proxy

USP messages

JSON bulk data over HTTP, MQTT, or over USP Notify messages

USP messages

USP messages

USP messages

USP messages

Non-USP Device

  • Network setup and config
  • Network, security and privacy control
  • Software container management
  • Wi-Fi management
  • Firmware and software upgrades
  • Diagnostic commands
  • Bulk data telemetry
  • Custom commands & events
  • IoT sensors and controls

TR-181/Device:2 Data Model Capabilities

USP Controllers and USP Agents have:

  • Persistent connections to reduce handshakes
  • Clear trust relationship establishment
  • Optional end-to-end application layer TLS session context
  • Rule-based access control to service elements for privacy and security
  • Flexible transport that can be cloud independent or not

USP Agents

Modeled proxy device

33 of 33

Resources

  • usp.technology
  • github.com/BroadbandForum/obuspa
  • Members can participate at any time!
    • info@broadband-forum.org
  • Ask to be a guest at our Q2 2022 virtual meeting