Next big industry trends regarding centralized large scale subscriber Device Management as embraced by Axiros are listed below:

• Centralized personalization of the home devices features, via convenient branded Central Subscriber Portals that can create the service and configure the service delivery devices within one workflow.

• Converged Inter Device Management, for value added solutions which touch more than just one device in one workflow - via TR-069 but also other protocols typical for the WAN type (DSL, FTTx, Cable or Mobile).
  Furthermore also within the homes, besides TR-111, there is demand for seamless support for other protocols, specialized e.g. for completely centrally managed smarthome solutions.

• Device Management architectures that reflect the growing together of Network and IT departments. Since the offered services become more network centric - so does Device Management.

• IP Service Level Assurance, i.e. proactive large scale monitoring of service quality and consumer behaviour in the field, directly on the devices, for data, voice and video.

Further, at Axiros we do recognize the need to transfer the benefits of centralized Device Management into the business router area and to unify interfacing with it.

And as very promising regarding value added services and service quality assurance we regard highly dynamic end user based policy management, i.e. assigning the properties of an IP service with the user in the home or enterprise network which currently consumes it.

In the traditional ACS architecture none of these next level Device Management challenges can be adequately coped with.

_{Traditional ACS Design}

Why? The ACS is bookkeeping device settings and has, if any, only rudimentary and static knowledge about the services related to those settings. Adaption to the OSS/BSS systems are done at the northbound periphery, via separate instances ("service abstraction layer").

That architecture neglects the facts that in asynchronous protocols like TR-069 or OMA's SyncML DM, the devices are (constantly) challenging the server and not vice versa.

Handling those requests autonomously w/o flooding the backend with service related queries could only be done via static rulesets ("if you see this, do that").  But since the addressing of features heavily differs from device to device (a fact which also data model specifications like SNMP MIBs or TR-xxx specs cannot resolve), those rulesets will increase with exponential order, the more device types are out there and the more features are to be managed. Moreover, keeping the OSS/BSS service related parameters and those rulesets and differing device settings in sync is nearly impossible, when managing more than a few trivial settings.

Generic Device Management is a key design concept of all Axiros Axess Server products, doing away with those problems.

Creating Axess we were led by the perception, that a subscriber's service specific settings in OSS/BSS systems and the set of settings and state on his managed devices are to be treated as logically equal. Both are representations of the services the subscriber enjoys and the ACS should be able to understand them both - the instance which speaks the device's language and the one which transcends services into features should not be separated.

That perception has far-ranging consequences: We created a unique adaptive core technology, i.e. we designed Axess in way that its inner core 'thinks' operator service aware, independent of any data model, like TR-098 or TR-104. Once the primary data structures and signal processing logic are service aware, there is no fundamental difference anymore between processing northbound and southbound signals, like in the traditional ACS model.

High level benefits of this approach are pure business values.

• The increasingly complex synchronization effort between ACS and OSS business logic, when the ACS is only aware of data model for the settings is drastically simplified
• No need to program static reaction rulesets on the ACS anymore
• Administrative actions involve changing service parameters and high level provisioning logic only
• Inherent deeply integrated support for any device, TR-069 and non TR-069 without break - and with no difference at the northbound side
• Interdependent inter device workflows for complex smart home value added services
• Services involving highly dynamic policies, like bandwidth management according to the user in the home currently using a service
• Access to all features of the devices, since the ACS is not bound to TR-xx data models only
• Services involving hundreds of different settings like in the business router area are conveniently managed via the relevant service parameters only
• Unmatched performance, robustness and scalability since the ACS can run its tasks mainly autonomously, including the consolidation of diagnostic and service assurance data from the field
• Perfectly matching user interfaces and northbound APIs, speaking the language of the OSS/BSS

All this Advantages Are Making the ACS Truly Fit as an Integral Generic Service Within a Service Delivery Environment.