The Ideal Device Management Environment

In an ideal world the OSS/BSS just sends high level calls like 'upgradeSubscriberToGold' to the Device Management (DM) Platform or puts them on a service bus.

The DM platform knows what to do, involving all affected devices and interfaces with other northbound or westbound systems. Exceptions should only occur if the devices involved are not physically fit to deliver the service due to hardware or network restrictions but independent of how the features are to be addressed and even how they are transferred to the devices by the DM.
Device replacement processes should include automatic restore of the last working personalized configuration at time of cable connect, including all special settings of the subscriber like Wifi Keys and this even across devices of different vendors.
Further the DM should be able to pull meaningful, business relevant data out from the field, in a secure way, supplying first & second line support and management not only with snapshots of the current situation but also with history data and trends about service adoption, problem areas and device utilization.

Can This Goal Be Reached By Directly Addressing The Devices Via TR-069 Data Models?

The TR-069 transfer protocol of the Broadband Forum was a historic milestone for IP service provisioning in the consumer world, looking at its scalability, transparency, openness and security. So aren't the data models of the Broadband Forum just as important, perfectly suited for service abstraction?

The people from the Forum did a great job inventing generic parametrizations for device features and CPE vendors support them directly on the devices - so wouldn't it all be perfectly simple if the OSS/BSS adopts those parameters just directly? The ACS then just has to shovel the parameters back and forth via the TR-069 transfer protocol and keep its records clean.

Well the data models are for sure nicely suited to be used for some simple tasks of the DM, like getting knowledge about general device type and vendor, software and hardware version or uptime. Those settings are in general addressed the same no matter the device.
But if it's getting more complex, e.g. when features are to be explored and managed which have index numbers or which are interdependent (like an IP address, whose change has effect on many other device features) the synchronization between server and device via hierarchical tree like structures has severe limitations. These in general can't be overcome without propagating device specific differences into the OSS - which in our view has to be avoided in any case. Engineers which ever tried to restore a TR-069 data object tree for backup and restore purposes know it already: It's in general impossible even for one and the same device (the index numbers just don't match), not to talk of synchronizing device features of different vendors. Sometimes this is tried to overcome by preinstantiating any possible manageable feature setting, resulting in device trees in the size of megabytes, with thousands of nodes. The impact on device cost (flash, RAM), server I/O, device CPU performance and complexities in workflows are discouraging. Further, the performance impact is severe: Especially in real time support workflows where every second counts, it is in our view not tolerable that devices have response times in the area of a minute to synthesise a complete parameter tree.

Another problem, just as severe, is that CPE vendors don't even want to become exchangable, resulting in data models full of vendor specific parameters, which exactly reflects what has been happening in SNMP, where the MIBs are heavily vendor specific. At present, the first TR-069 devices are on the market with more vendor specific parameters than standard parameters! And since the server processes far more hits from the devices than from the northbound, those vendor specfics will sooner or later propagate into queries from the server into the OSS.

The Paradigm Shift: TR-069 Is Transfer And Not Data Models - Addressing the Devices in Their Native Way

So how the make the setup generic, overcoming the constraints of the data model centric approach?

Answer: Take the best of both worlds. Combine the excellent TR-069 transfer protocol with the device addressing mode the device experts would use also: Their native configuration language. The Device Managment system must do device specific mapping anyway, so map services to native configuration mechanics directly, omitting the bottlenecks of TR-069 data models in general.

What you get is nothing less than:

There are no known downsides of this new approach.

For the reader interested deeper in how this new Device Management design is deployed we refer to our workshops and our Best Practices for Generic Device Management paper.

 

The Axess Architecture - Foundation for Data Model Independent Service Aware Device Management

Axess core technology is a data model independent signal processing engine, which consolidates southbound and northbound stimuli into responses in any direction, using any protocol, synchronous and asynchronous. 

Processing of signals, TR-069, legacy or northbound, is done at lightning speed, at thousands of transactions per second.

There is only one framework for the job - the Axess server, developed by Axiros since 2002, with sole focus on open large scale service aware Device Management.