Whitepaper AXTRACT d00606

Axiros White Paper
On-Device QoE Monitoring Via TR-069
Axiros GmbH
Germany Altlaufstr. 34 85635 Munich Hoehenkirchen T +49 8102 80655 - 00 F +49 8102 80655 - 01 www.axiros.com info@axiros.com
On-Device QoE Monitoring

Introducing Axiros AXTRACT TR-069 Monitoring Appliance
Executive Summary
The Strategic Importance of On-Device Monitoring
executive summary
Axiros GmbH
Altlaufstr. 34 85635 Munich Hoehenkirchen Germany T +49 8102 80655 - 00 F +49 8102 80655 - 01 www.axiros.com info@axiros.com
Transparency about Quality of Experience is accepted as critical success factor for IP service delivery within the consumer world, not only for IPTV but also for Voice and other IP services. Within the paper we demonstrate, that a new highly specialized component, the Axiros AXTRACT server, can be utilized in a 100% non intrusive way, to turn the delivery devices (CPEs) into sophisticated probes for the service quality.
It will be shown that existing auto provisioning infrastructures, based on the TR-069 protocol suite, are an ideal basis to start On-Device QoE monitoring right away, using the Axiros AXTRACT appliance. Further, AXTRACT can signicantly help the support in troubleshooting processes by supplying a historic view on the service quality, on the average for arbitrary groups or down to a single device, including changes of service related parameters near realtime. It can deliver on time information about quality status from other devices in the service delivery chain, when one device reported an error. AXTRACT is answering KPI related investigations like
Which gateways in the eld deliver the best/worst WAN quality Is packet loss on the uplink the major source for streaming errors on the set top box Is there signicant difference in how different STB vendors handle packet loss
which might inuence purchasing decisions. Further AXTRACT, equipped with meta data can deliver service usage related information like

How quickly are customers zapping away in advertisement periods To which extent is zapping related to WAN quality Is there a signicant portion of unconnected HDMI cables How often are subscribers redialing the same number on their voice handsets
Answers to questions related to information from the devices themselves can contribute signicantly to QoE analyses, turning the CPEs themselves to probes for the overall service quality.
AXTRACT Monitoring Appliance
executive summary
AXTRACT can also support existing ACS processes when raw performance is needed, e.g. at mass rmware downloads or emergency updates. It takes care of shielding the ACS as an increasingly critical component from potential attacks from the eld. Last but not least, AXTRACTs ultra fast data aggregation, consolidation and visualization performance is key for delivering value added services, including but not restricted to central subscriber portals, smart metering or intelligent home applications, completely centrally managed.
About This Document

Table of Contents / Revision History
meta information
Scope and Prerequisites
Collected Data / QoE .....................................................................................................5 Beyond Data Models: RunCommand .............................................................................7

Conguration vs. On-Device Monitoring What Is QoE And (How) Can It Be Monitored On-Device? Troubleshooting and Support Besides QoE: General Relevance of Southbound Performance
9
9 10 11 12
AXTRACT Key Features

Built In Features of AXTRACT Legacy Device Support Extension Modules (APPS)
15
16 20 21
Deployment Strategies
Requirements Actively Sending Connection Requests Passively Awaiting and Processing Periodic TR-069 Informs
26
26 27 28
Discussion ....................................................................................................................28 Deployment Topologies 29
Proxying Productive TR-069 .........................................................................................30 Setup Parallel to the ACS .............................................................................................32
Appliance Specications
Monitoring Server: AXTRACT Appliance (AXTRACT.5K)
Axiros GmbH
33
33
About Axiros
35
Revision History
Version
Date 10 / 2008 11 / 2009
Remarks Initial Version Design Change / New CI Rebranding to AXTRACT. Transparent mode.
Release Status Draft, Internal Draft, Restricted Access
meta information
0,1 0,2
0,3
05 / 2010
New Use Cases based on Input from 2010s TM Forum Management World Slight Information and Design Improvements
Draft, Restricted Access
0.3.1
05 / 2010
Draft, Restricted Access
Audience
Operator Network / Support / IT / Marketing Decision Makers & Technical Experts Operator Product Management Device Management Experts In General (Design, Implementation, Testing)
Scope and Prerequisites

This paper focusses on explaining how but also why existing TR-069 ACS setups can and should be rened by adding the Axiros AXTRACT monitoring appliance to collect QoE / QoS monitoring data in large quantities from the managed devices, without overloading the ACS. The following sections outline that AXTRACT is a generic and open approach to on-device monitoring, not dependent on specic KPIs or proprietary protocols but by making full use of industry standard vendor independent methods and possibilities. 1. Collected Data / QoE In the paper it is not illustrated which data is available on which device classes.
Axiros GmbH

Axiros GmbH . www.axiros.com . info.axiros.com
In general there is to say that the TR-069 standard suite - Technical Reports (TRs) and Working Texts (WTs) - denes a vast amount of low and high level relevant monitoring KPIs, including link status, packet statistics but also data, voice and video quality.
meta information
As an example from the area IPTV the following KPI/KPQ table shall demonstrate which areas of QoE (as dened by TR-126 as as the overall performance of a system from the point of view of the users) are covered by on-device available data
WT-160 Categories IPTV Portal Information Retrieval Time IPTV Service Access Time IPTV Channel Switching Time IPTV Video on Demand Access Time IPTV Video on Demand Access Success Ratio IPTV Video on Demand Completion Ratio IPTV Video on Demand Control Response IPTV Media Quality
TR-126 QoE Objective TR-135 Support Global Operation Average Response Time Global Operation Service Access Time Video Response Stats Average Video System Response Video Response Stats Average Video System Response Video Response Stats Access Successes, Access Failures Video Response Stats Access Successes, Completion Count Video Response Stats Average VoD Control Response Metric Data Metric Value RTP Stats
IPTV Packet Loss
Packets Expected, Packets Received, Gmin, Loss Event, Severe Loss N.A. N.A.
IPTV Channel Availability IPTV Video without Disturbance
Note that the right column shows only a small subset of available parameters on a TR-135
Axiros GmbH
STB.

We refer to the relevant parameter specications available to be downloaded from the broadband world forums site1 for a full overview of which data is already well dened within data models of the TR-069 suite. 2. Beyond Data Models: RunCommand
meta information
Axiros GmbH
For the reader totally unfamiliar with the RunCommand TR-069 extension, we give a short overview within this section. Please contact Axiros in case further technical information is required. By dening the data models for various device types the Broadband Forum achieved great clarity in specifying what diagnostic tooling can be expected at minimum from a certain device type today. Device vendors usually deliver also a vast amount of vendor specic parameters, extending the specied standard data models. Still, there remains a critical gap between information available within data models plus their vendor specic parameters and the real state of the device and its natively available features. The solution is to realize that TR-069 is not restricted to data models and vendor specic parameters only - vendor specic calls can as well be added, when extended management functionality is required within operators environments. That possibility was not heavily used in auto provisioning until Axiros suggested a RunCommand extension, which is a vendor specic call, trivially to implement for the vendor. RunCommand is a bridge to the native command ow via TR-069, so that the ACS has full access to the underlying OS, doing away with the need for vendor specic parameters covering special needs. We summarize the main advantages of RunCommand:
Slim and reliable device communication stacks, saving development cost, CPU and space on the devices
Efcient utilization of network, consolidating information already on the devices instead of on the server (e.g. log les but also decisions on how to handle multiple state changes)
http://www.broadband-forum.org/technical/trlist.php

Normalizes available device information, drastically reducing normalization effort within the server workows and vendor specic differences on its northbound interfaces 2 Key for proactive monitoring, i.e. directly on the devices, e.g. to restart a process when CPU consumption is over upper boundaries
meta information
Axiros GmbH
Key for triggering management ows at arbitrary state changes on the devices, far beyond TR-069s change notications
Key enabling technology for business router management via TR-069 as well as centralizing the device portal allowing management access to all features of the devices
Turns TR-069 into a carrier for non IP based smart home protocols (Z-Wave, ZigBee, others) driven via the TR-069 gateway from the central ofce RunCommand, due to its trivial implementation and negligible stack size, is further key for getting devices into the managed set where no data model yet is dened, e.g. personal computers and even smart home / smart metering equipment
Solves TR-069s index number uncertainties Solves the problem of disconnects between devices data model conguration state and real state
Axiros AXTRACT is fully supporting RunCommand, i.e. can synthesize and parse arbitrary command ows and results as well as arbitrary TR-069 Data Models.
This refers to the fact that offered data models at the devices are increasingly different from each other - data models are (like SNMP MIBs) subject to heavy insertion of vendor specic parameters. Since also the index numbers of parameters are not x in TR-069, the normalization effort is signicant from device to device.


Introducing Axiros AXTRACT TR-069 Monitoring Appliance
Consumer IP service provisioning on the one hand and monitoring of IP services on the other require very different technical challenges to be overcome. Provisioning involves tight integration with OSS/BSS services and operator specic business logics to be able put the right conguration at the right time onto the right device(s). Whereas sufciently frequent monitoring of Voice Video and/or Data consumer type services involves mainly one problem: The ability to handle and consolidate a vast amount of data from the eld. In this proposal Axiros advances its AXTRACT solution3 , which handles large scale monitoring of devices when a provisioning solution is already in place, without interfering with its provisioning and real time support ows.
Conguration vs. On-Device Monitoring
With the advent of TR-069 in late 2004, centralized consumer device provisioning became feasible on a large scale and quickly found its way into the centralized infrastructures of carriers and ISPs. TR-069 ACS servers today take care for handling
introduction
Axiros GmbH
Association of factory reset devices to subscriber proles by means of network port detection, subscriber self identication or preregistration of devices
Provisioning of initial personal settings for data, voice, video and other services onto those devices Enabling real time support ows, i.e. online checks, conguration checks whenever the subscriber calls with a problem Firmware upgrades
Flexibility counts here, i.e. the ability of the ACS to adapt to the OSS/BSS service parametrization and the different ways those services are to be enabled on those devices.
3
See also Proceedings Broadband World Forum 2008, Brussels: Invited Speech Gunther Klessinger, Axiros, at JDSU Panel (D4): Service Assurance in the Home Network The End-to-End Service View and Its Most Critical Component. After extensive tests in production in Q1/Q2 2010 the solution was commercially released during the 2010 Management World of TM Forum in Nice, winning a catalyst project together with JDSU and Bull (Driving the costs out of IPTV)
Signaling back and forth between ACS and OSS/BSS, both synchronous and asynchronous, is vital. The ability of the ACS to pass every hit from a device through a sophisticated set of operator specic rules, which might involve communication with backend resources is key for service aware Device Management. Naturally, these requirements have signicant impact of overall turnaround times of device
introduction
Axiros GmbH
transactions - ACS servers serve at roughly at round about 100 requests per second which is enough for even very high scale provisioning setups, where around 1-5 transactions per device per day are to be expected. Not so for IP service level monitoring: When rolling out data, video or voice services on a large scale, very high frequent service related KPI measurements on the devices themselves and consolidation of that data against reference and quality data from backend resources like service delivery platforms or backend network related data into meaningful and ne grained statistics has turned out to be a key success factor. Therefore desired granularity of measurements to be able to backtrack QoE problems sufciently well is in the range of minutes per device4 , leading to transaction rates of 100 1500 transactions per device per day !
What Is QoE And (How) Can It Be Monitored On-Device?

Broadband Forum TR-126 Quality of Experience for Triple Play Services denes Quality of Experience (QoE) as the overall performance of a system from the point of view of the users. QoE is a measure of end-to-end performance at the services level from the user perspective and an indication of how well the system meets the users needs. QoE is thus in a sense the only gure of merit that truly matters to the customer of any broadband delivery system. Do I, the user enjoy this experience, does it meet my needs. QoE is inherently subjective, objective measures of service quality, QoS measurements, such as error seconds, degraded packets, latency times, jitter and so forth only have importance when they can be related to the experiences of real viewers of video programming in their own homes. So the answer to the headline question is: QoE cant be measured on the devices alone. It must be correlated and consolidated against information from systems other than the service delivering devices in the homes like the service delivery platform or probes within the trafc path. But it is a trivial to see, that any approach to deliver information about end user experience is highly dependent on information very frequently measured on that same device the end user is directly connected to, when consuming the service.
4
In general the more the better. 5 minute polling intervals per device have turned out to be a good compromise between polling load and analytic possibilities.

10
As an example we show a screenshot from JDSUs Home PM umbrella monitoring system5 :
introduction
The most relevant data for the conclusions of such a QoE expert system is delivered from the remote gateway (RG Stats). From these it can derive precise error prevention measures - without that information from the delivery device itself the systems would be restricted to information from backend resources and a (restricted) set of probes in the eld.
Troubleshooting and Support

What about the relevance of on-device data for troubleshooting and customer support? The following graph (kindly forwarded from JDSU) depicts the fact that around 50% of all problems in triple and quad play offerings happen within the homes, due to the heterogenous environments found there.
Axiros GmbH
The product introduced in this white paper ships with JDSU Home PM interfaces by default

11
introduction
Axiros GmbH
Furthermore problems within the customer premises are very expensive to x as well, often involving truck rolls and / or technicians on site. Therefore, ongoing service quality monitoring directly on the end devices, within the customer premises themselves is a most obvious thing to do - if the performance to do it would be available on the central ofce.
Besides QoE: General Relevance of Southbound Performance

More and more devices within the homes are shipped with IP stacks, making them ready running business logic dened elsewhere, in management applications, local or central. TR-069 stacks have been dened for printers, NAS devices or power plugs. Even whiteware (refrigerators, ovens, others) is getting into the manageable set of devices. Building centrally managed infrastructures alone for value added services in the eld of home device management (the managed fridge) was never justied be a solid business case. But with the advent of TR-069 that infrastructure is there anyway - so that putting VAS on top of it is now obvious.
Centralized management of the router, although deployed for different reasons 6 has become a key technology for centrally managed home network applications involving a multitude of devices. Centralized subscriber portals allow convenient access to those applications. Content served by those central portals is mediated for different consumer devices, turning e.g. the mobile phone into a remote control for the home.
The classical TR-069 ACS tasks: Plug and Play provisioning of basic data and voice services, rmware upgrades and real time support

12
introduction
Axiros GmbH
Central help desks can now fully support the customers in case of problems.
TR-069 and the RunCommand call are key for non IP based 7 smart home applications, based on sensors reading out volume, temperature, humidity (...), with the information transferred to and from the server, via the TR-069 gateway.
ZigBee, Z-Wave, others

13
Summary: The industry migration towards centrally managed smart home applications and / or smart metering offerings is increasing the shear amount of data to be read from the eld drastically, with amounts of managed devices often in the two digit range per managed home environment and granularity of readings within the minutes range.
introduction
Axiros GmbH
To enable and drive all of these applications Axiros has developed technologies to...
process inspect DB write load balance / proxy consolidate
...TR-069 application layer calls at a rate of over 5000 transactions per second per node the Axiros AXTRACT server.
AXTRACT technology is available as appliance8 or as software package to run on third party server hardware9 .
In the paper we refer to the appliance solution throughout. Intel Architecture, 2 (XEON) CPU 4 Core, 4Gig RAM

14
AXTRACT Key Features

Transparent Data Aggregation At Ultra High Performance
features
Guiding design policy for AXTRACT was transparency to any given ACS. Further there should be no need to adjust settings on the ACS when deploying AXTRACT. AXTRACT renes any given TR-069 setup but not collides with anything the ACS does. That goal was reached.
The principal process of inserting the appliance leaves the ACS server(s) untouched as schematically depicted below.
Management / Internet
Provisioning / Real Time Support Load
TR-069 ACS (Provisioning, Real Time Support))
Axiros AXTRACT
(Transparent for ACS)
Monitoring Load
TR-069 ACS (unchanged)
Data Storage / Dashboard
Data Consumers e.g. Umbrella Monitoring (JDSU)
Axiros GmbH
15
Built In Features of AXTRACT
Scalability to thousands of interactions and consolidation runs per second, suitable for millions of devices
Fully transparent to existing ACS trafc The properties to be collected can be freely dened per device group, so AXTRACT can monitor any attribute the device offers and can be used in various service scenarios like VoIP, IPTV but also Smart Home / Smart Metering, to collect information delivered by various sensors within the home networks
features
Axiros GmbH
Fully redundant cluster setup supported for HA and further increased performance. High availability in non cluster mode through IP failover to a secondary AXTRACT server Setup Wizard for convenient and straight forward base setup

16
Integrated Dashboard to control the appliance as well as to create reports on the collected data
features
Flexibility in aggregation, storage and export of the collected data
Axiros GmbH

17
Cross device analyses, taking into account all devices of a service chain (e.g. gateway and set top box)
Axiros GmbH
features
18
Out of the box support for JDSUs Home PM umbrella monitoring and QoE expert system10 as data consumer on AXTRACTs northbound side.
features
The illustration demonstrates the principal architecture for the case of IPTV QoE end to end monitoring, as shown in 2010s Telemanagement Forums Management World convention, within a Catalyst 11 project (Driving the Costs out of IPTV).
Axiros GmbH
10
http://www.jdsu.com/products/communications-test-measurement/products/a-z-product-list/sas-pm.html http://www.tmforum.org/DrivingtheCostsOut/8482/home.html
11

19
Legacy Device Support

AXTRACT can be equipped with legacy device handlers, turning open synchronous management protocols into asynchronous TR-069 on the AXTRACT server.
features
TR-069 Primary ACS Cluster
TR-069, TR-098 Non TR-069 Management / Internet TR-069 Loadbalancer(s) OSS/BSS HTML SSH / SNMP
AXTRACT Cluster
Telnet PC With TR-069 Client TR-069
Secondary ACS Cluster
Supported protocols:
SNMP TELNET SSH HTTP
In contrast to using TR-069 as monitoring protocol, there are ow handlers needed for the various device vendors. See next section.
Axiros GmbH

20
Extension Modules (APPS)

AXTRACT ships support for adding extensions (APPS) on southbound collection, consolidation and charting but also northbound side. APPS can be downloaded and installed by the customer.
features
Axiros GmbH
Southbound legacy ow handlers based on the AXTRACT TR-069 to legacy converter. Currently APPS are available for adding various SNMP, TELNET, SSH or HTTP devices into the monitored set. Shown below is the application of an APP, which added a non TR-069 ADB Set-TopBox into the managed set via TELNET:
This is the featured data set on a remote gateway device, fetched via TELNET and mapped to TR-069 vendor specic data objects.
InternetGatewayDevice.WANDevice.1.WANDSLInterfaceCong.DownstreamCurrentRate InternetGatewayDevice.WANDevice.1.WANDSLInterfaceCong.UpstreamCurrentRate InternetGatewayDevice.X_XAVI_Port_A1_ACTPSDDs InternetGatewayDevice.X_XAVI_Port_A1_ACTPSDUs

21
InternetGatewayDevice.X_XAVI_Port_A1_APIVersion InternetGatewayDevice.X_XAVI_Port_A1_ATUCANSIId InternetGatewayDevice.X_XAVI_Port_A1_ATUCANSIRev InternetGatewayDevice.X_XAVI_Port_A1_ATUCANSISTD InternetGatewayDevice.X_XAVI_Port_A1_ATUCCountry InternetGatewayDevice.X_XAVI_Port_A1_ATURANSIRev InternetGatewayDevice.X_XAVI_Port_A1_ATURANSISTD InternetGatewayDevice.X_XAVI_Port_A1_ATURVendor InternetGatewayDevice.X_XAVI_Port_A1_AnnexType InternetGatewayDevice.X_XAVI_Port_A1_BisBDn InternetGatewayDevice.X_XAVI_Port_A1_BisBUp InternetGatewayDevice.X_XAVI_Port_A1_BisDelayDn InternetGatewayDevice.X_XAVI_Port_A1_BisDelayUp InternetGatewayDevice.X_XAVI_Port_A1_BisLDn InternetGatewayDevice.X_XAVI_Port_A1_BisLUp InternetGatewayDevice.X_XAVI_Port_A1_BisMDn InternetGatewayDevice.X_XAVI_Port_A1_BisMUp InternetGatewayDevice.X_XAVI_Port_A1_BisRDn InternetGatewayDevice.X_XAVI_Port_A1_BisRUp InternetGatewayDevice.X_XAVI_Port_A1_BisSDn InternetGatewayDevice.X_XAVI_Port_A1_BisSUp InternetGatewayDevice.X_XAVI_Port_A1_BisTDn InternetGatewayDevice.X_XAVI_Port_A1_BisTEQError InternetGatewayDevice.X_XAVI_Port_A1_BisTUp InternetGatewayDevice.X_XAVI_Port_A1_CommonHandshake InternetGatewayDevice.X_XAVI_Port_A1_Connected InternetGatewayDevice.X_XAVI_Port_A1_DataBoost InternetGatewayDevice.X_XAVI_Port_A1_DeltACTATPds InternetGatewayDevice.X_XAVI_Port_A1_DeltACTATPus InternetGatewayDevice.X_XAVI_Port_A1_DeltHLINscds InternetGatewayDevice.X_XAVI_Port_A1_DriverVersion InternetGatewayDevice.X_XAVI_Port_A1_DspVersion InternetGatewayDevice.X_XAVI_Port_A1_FastRDn InternetGatewayDevice.X_XAVI_Port_A1_FastRUp InternetGatewayDevice.X_XAVI_Port_A1_FirmwareVersion InternetGatewayDevice.X_XAVI_Port_A1_INPdown InternetGatewayDevice.X_XAVI_Port_A1_INPup InternetGatewayDevice.X_XAVI_Port_A1_InterleaveDpDn InternetGatewayDevice.X_XAVI_Port_A1_InterleaveDpUp InternetGatewayDevice.X_XAVI_Port_A1_InterleaveRDn InternetGatewayDevice.X_XAVI_Port_A1_InterleaveRUp InternetGatewayDevice.X_XAVI_Port_A1_InterleaveSDn InternetGatewayDevice.X_XAVI_Port_A1_InterleaveSUp
Axiros GmbH
features
InternetGatewayDevice.X_XAVI_Port_A1_LastFailed InternetGatewayDevice.X_XAVI_Port_A1_LocalEndLOS InternetGatewayDevice.X_XAVI_Port_A1_LocalFastChannelRxRate

22
InternetGatewayDevice.X_XAVI_Port_A1_LocalITUCountryCode InternetGatewayDevice.X_XAVI_Port_A1_LocalLineAttn InternetGatewayDevice.X_XAVI_Port_A1_LocalSEF InternetGatewayDevice.X_XAVI_Port_A1_LocalSNRMargin InternetGatewayDevice.X_XAVI_Port_A1_LocalTxPower InternetGatewayDevice.X_XAVI_Port_A1_OperationProgress InternetGatewayDevice.X_XAVI_Port_A1_OperationalMode InternetGatewayDevice.X_XAVI_Port_A1_OverallFailure InternetGatewayDevice.X_XAVI_Port_A1_PMstatus InternetGatewayDevice.X_XAVI_Port_A1_PhyCellDropCount InternetGatewayDevice.X_XAVI_Port_A1_PhyRXCellCount InternetGatewayDevice.X_XAVI_Port_A1_PhyTXCellCount InternetGatewayDevice.X_XAVI_Port_A1_RSCorrectedErrorsDn InternetGatewayDevice.X_XAVI_Port_A1_RSCorrectedErrorsUp InternetGatewayDevice.X_XAVI_Port_A1_RSUnCorrectedErrorsDn InternetGatewayDevice.X_XAVI_Port_A1_RSUnCorrectedErrorsUp InternetGatewayDevice.X_XAVI_Port_A1_RawAttn InternetGatewayDevice.X_XAVI_Port_A1_RxATTNDR InternetGatewayDevice.X_XAVI_Port_A1_RxCellRate InternetGatewayDevice.X_XAVI_Port_A1_ShowtimeStart InternetGatewayDevice.X_XAVI_Port_A1_State InternetGatewayDevice.X_XAVI_Port_A1_SuperFramesDn InternetGatewayDevice.X_XAVI_Port_A1_SuperFramesUp InternetGatewayDevice.X_XAVI_Port_A1_TxATTNDR InternetGatewayDevice.X_XAVI_Port_A1_TxCellRate InternetGatewayDevice.X_XAVI_Port_A1_Watchdog InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_Addr InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_FullDuplexEnable InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_HashHigh InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_HashLow InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_MAC InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_MaxMulticastListsize InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_MaxQueue InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_PhysicalPort InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_PortClassEthernet InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_PromiscuousEnable InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_RxBuffError InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_RxCRCError InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_RxFrameError InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_RxLockupFixApplied InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_RxMissedFrames InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_RxMulticastAllEnable InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_RxNotFirstError
Axiros GmbH
features
InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_RxNotLastError InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_RxOverowError InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_RxShortPacketError

23
InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_TxExcessiveRetryError InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_TxManyRetries InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_TxNoCarrierError InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_TxNoRetries InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_TxOneRetry InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_TxUnderowError InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_Version InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_portSnmpIfIndex InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_portSnmpIfType InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_resetDefaults
features
Axiros GmbH
Note that the offered quality stats are exceeding TR-069 standard data models (refer also to the RunCommand RPC, illustrated in the rst chapter of this paper ).
Another App is the congurable rule engine, which, when deployed in proxy mode for the productive ACS (see next chapter), takes away from the ACS static mass jobs, which need no OSS/BSS integration. This can further signicantly relief the productive ACS.

24
Consolidation backends are available for application specic processing and dashboarding in specic use cases. Shown below is an APP for PC support and inventory over large subscriber base:
features
25
Deployment Strategies
How to Deploy a Dedicated Probing Appliance
deployment
In TR-069 KPI data collection can be done by actively sending connection requests to the devices and process the subsequent TR-069 inform packets or by waiting for the devices to send periodic informs. We discuss the two approaches, given that a dedicated monitoring appliance is to be inserted without integration needs and without interfering with the productive ACS.
Requirements
The ACS server, due to its exibility needs regarding provisioning business logic can not process monitoring load order of magnitudes higher than provisioning and real time support trafc. Simply gathering KPI data from its northbound interfaces is therefore not feasible on a larger scale. A monitoring server clearly must be inserted in a way that it handles the trafc without passing it through the ACS.
Devices
Monitoring Appliance
Low Volume Provisioning Calls (~1 hit / device / day)
ACS
High Volume KPI Data

(~100-1000 Hits / device / day)
The following goals are to be reached:
Monitoring trafc does not interfere at all with productive ACS ows Monitoring cycle times of around 10 minutes should be feasible for devices in the 1 Mio range
Axiros GmbH
Monitoring trafc does not hit the productive ACS
26
Monitoring server can be simply plugged in, without the need to integrate with ACS or OSS/BSS
We are going to discuss how these can be accomplished in a TR-069 enabled network.
deployment
Actively Sending Connection Requests

In TR-069, the straight forward way to gather KPI data from a device which is to be studied, is to send a connection request12 to it and handle the subsequent TR-069 inform packet by a GetParameterValues job for the interesting values.
Device
Connection Request
(Digest Authed Empty HTTP Request)
TR-069 Inform (Event: ConnectionReq.) GetParameterValues GetParameterValuesResult Ack (Empty Reply) Data Consolidation
This approach has the advantage of keeping network load to a minimum since only those devices where KPIs have to fetched cause trafc in the network and Inform processing load on the ACS. However, a dedicated monitoring server, to act independently from the ACS, would need to send the connection requests in case KPI data is to be fetched. This is due to the fact that TR-069 informs will always be sent to the same server from the devices, regardless of origin and parameters of a connection request. Therefore the monitoring server would need to be aware of IP, connection request URLs and credentials of every device. That clearly violates the goal that the monitoring appliance is to be added by simply plugging it in, without any integration with the ACS.
Axiros GmbH
12
http://axiros.com/leadmin/media/home/knowledge_base/faqs/TR-069Amendment2.pdf

27
Passively Awaiting and Processing Periodic TR-069 Informs

Alternatively to actively requesting the devices to send TR-069 informs the devices can be set to high frequent periodic inform intervals, with the data gathering possible then only at those periodic times:
deployment
Device
TR-069 Inform (Event: Periodic) GetParameterValues GetParameterValuesResult Ack (Empty Reply)
Data Consolidation
A clear advantage is that the monitoring server does not need to know how to send connection requests to the devices. But there are also disadvantages:
Inform load is on the network even for devices which may not be interesting at a given time (i.e. not under study).
Data gathering can only happen at periodic inform cycle times of devices.
Discussion A typical TR-069 inform has, conservatively estimated, 2 kBytes of data. The monitoring appliance would only react with GetParameterValues (GPVs) jobs if the device is under study. Assumed that minimum data gathering interval for devices under study mode is 10 minutes, 1 Mio devices would caused around 3 Megabyte13 / second on the management network, corresponding to around 1700 TR-069 informs per second. If we calculate around 10% of the devices under study mode we are still under 2000 TR-069 transactions per second and cause a load of < 5 Megabyte / second on the
Axiros GmbH
management network, assuming GetParameterValuesResponse sizes of < 20KBytes.
13
1000000 * 2048 / (1024 * 1024) / (60 * 10)

28
Load capacity of the AXTRACT Monitoring Appliance is around 5k transactions per second, in proxy mode, with inline data consolidation. Therefore one appliance node is very well tting to handle the load of 1 Mio devices at 10 minute inform intervals and around 10% under study mode. When we want to have more devices under study / even smaller collection intervals the
deployment
Axiros GmbH
bottleneck to overcome is the size of the GetParameterValuesResponse packets and not if the GetParameterValues jobs are sent actively or passively.
Besides simply adding more AXTRACT servers, Axiros suggests as scaling strategy to preconsolidate KPIs already on the devices themselves by means of using X_<vendor>_RunCommand TR-069 RPCs 14, which consolidates the information sent over to the server already on the devices by standard OS specic means. Further the devices can be set to send data only at interesting state changes.
The second disadvantage in passively awaiting informs is that data can only be gathered at periodic inform cycles. But since the Monitoring appliance is intended to collect high volume statistical data for a large quantity of devices it should be no problem that the single device hits are not up to the minute. Single CPE interactions can still be handled by the ACS itself, when needed in a timely manner, for example by real time support.
Deployment Topologies
Having discussed why the Monitoring Appliance acts on passive TR-069 informs, lets now highlight how to deploy it into an existing provisioning TR-069 setup, with the goal of zero interference with the productive ACS.
14
See Generic Device Management - Best Practices.

29
1. Proxying Productive TR-069 The graph below depicts an architecture where the Monitoring server is the handling all TR-069 remote procedure calls. It processes all periodic inform packets and KPI collection call responses while forwarding the rest to the productive ACS server(s).
deployment
On congurable intervals AXTRACT can also send periodic informs to the ACS.
TR-069 (proxied) Provisioning RealTime Support
Primary ACS Cluster
Non TR-069 TR-069 Loadbalancer(s) OSS/BSS
AXTRACT Cluster
TR-069 (proxied)
That approach has the advantage that the Monitoring appliance can also run non monitoring related tasks on the TR-069 RPCs before forwarding to the productive ACS:
Filter malicious TR-069 payload, i.e. act as an application level rewall for TR-069 Streamline broken/non compliant TR-069 payload, to be consumed by the ACS, making the device stacks look alike Run static mass actions, like rmware downloads or initial pre provisioning preparation tasks autonomous of the ACS
Axiros GmbH

30
AXTRACT
Total TR-069 Load
Appliance
TR-069 KPI Analyzer
deployment
KPI Data parsing normalization & consolidation
yes
KPI Data ?
Run static TR-069 jobs (mass FW downloads, schedule Inform, ...)
yes
Filter rules match?
ACS Support Engine
Drop packets
no
Security checks passed?
TR-069 Firewall
Productive TR-069 ACS
A summarized description of that setup is that the monitoring appliance is interfering with the productive TR-069 payload and can therefore also handle further supportive tasks for the ACS, rather than monitoring only.
If the appliance should not interfere at all with productive ACS trafc we suggest the second deployment type - forwarding the monitoring TR-069 trafc to the appliance and the rest to the ACS via standard web based load balancers.
Axiros GmbH

31
2. Setup Parallel to the ACS
deployment
DB Monitoring Traffic
Dashboard
Service Assurance (JDSU)
Provisioning Traffic Web Loadbalancer (e.g. F5, or ACS specific one) TR-069 Cluster
In this setup the whole ACS infrastructure, including potential load balancer and CPEs ACS URL is not touched at all. Southbound of the ACS (incl. a potential load balancer) there is introduced a standard web load balancer, which forwards productive inbound ACS trafc (RPCs from the devices) to the ACS and the rest to the appliance, matching on request contents. That way the ACS is shielded securely from the southbound monitoring load without touching productive trafc streams. The whole solution can be inserted simply, without reconguration of the ACS load balancer / productive ACS server(s). The monitoring appliance immediately begins to collect data on periodic informs and therefore lls its database automatically with productive devices information. An umbrella service assurance solution like JDSUs NetComplete Home PM15 as a potential data consumer would be connected to the northbound interface of AXTRACT.
Axiros GmbH
15
http://www.jdsu.com/products/communications-test-measurement/products/a-z-product-list/sas-pm.html

32
Appliance Specications
Performance Information From Tested Setups
specications
Axiros GmbH
Following we present performance gures for the second deployment type only, since the rst types performance is heavily dependent on the character of TR-069 packet manipulation jobs. If no such manipulation are to be performed, than the simply proxying of unmodied packets to the ACS is causing only negligible overhead.
Monitoring Server: AXTRACT Appliance (AXTRACT.5K)

The server is able to process and consolidate TR-069 KPI RPCs from large quantities of devices. Secondary it can act as a CWMP (TR-069) proxy for the productive ACS, taking away from it static mass jobs, which need no OSS/BSS integration. This can further signicantly relief the productive ACS.
Performance (KPI Analyzer): > 5000 KPI RPCs per second per server (at 20 non SSL TR-069 KPI parameters per hit and direct storage)
Performance (requires optional non TR-069 Proxy): > 1200 concurrent southbound data gathering operations (TELNET, SSH) per server
Scaling: Clusterable < 10% performance loss per node Conguration: Web (graphic user interface), XMLRPC, SOAP, REST, CSV/XML upload Monitoring, Alerting: SNMP, Syslog, custom triggers Data visualization: Congurable Web2.0 dashboard Parameter Support: Any Broadband-Forum device parameter specication RunCommand Support (parsing of native device information into service quality parameters)
TR-069 Interoperability: Comes with Axiros Interoperation Guarantee (http://axiros.com/ axiros/interoperability-statement-the-axiros-guarantee.html) Statistics: Via Web GUI / Northbound Interfaces (SOAP, XMLRPC, CSV Export, REST, Direct DB) Dimensions: 2 HU
33
Operating temperature: 0 to 35C, humidity: 90% maximum relative humidity, noncondensing Redundant power supplies Optional hardware SSL acceleration CPU: 2 Intel Xeon X5460 Quad Core Processor 3,16 GHz RAM: 32GB HD: Four (4) PCI-Express Slots Interfaces: LAN Ports: 4 x 10/100/1000 Mbps
specications
Axiros GmbH

34
About Axiros
Inventing the Future of Device Management - Since 2002
about axiros
Axiros GmbH
Position
With over 40 operators within the European, South American and Russian broadband market, Axiros is market leader in open Device Managementsolutions - technically, basedon the number of supported devices and protocols but also regarding number of operators using Axiros productsexclusively for their Device Management, both TR-069 and non TR-069. Axiros claims technology leadership in open carrier grade Device Management - based on benchmarks regarding performance, scalability and exibility. Since its founding the company is solely management owned, with no external investment.
History
2002: Founding of company. Know how based on developing broadband network and policy management solutions for BRASes.
2003: First large deployments for open CPE Management (T-Systems International, others).
2004: Integration of TR-069, at time of specication release. 2005: First European carrier grade TR-069 ACS product - Axiros AXESS. 2006: First European fully standard compliant TR-069 large scale productive deployments. 2007: European market leader in TR-069 technology based solutions with over 20 operators. Invented the RunCommand approach, to manage arbitrary complex feature sets using trivial to implement device stacks.
2008: Worldwide rst TR-069 deployments for Cable, with Germany's two top players (Kabel Deutschland, Unity Media). Integration with Docsis environments. 2009: Worldwide rst hybrid TR-069 / non TR-069 productive large scale deployment of Cisco business routers and Metro switches at Dutch incumbent KPN. 2010: Real-Time Quality of Experience Monitoring via TR-069. Axiros invented technologies allowing not only to continuously monitor millions of devices but also to do thisfully transparent to any existing ACS.
35
thank you
Axiros GmbH
Please contact Axiros regarding demonstration of Axiros AXTRACT via webcasts and / or a trial installation within your premises.
2010 All Rights Reserved by Axiros
36

Whitepaper AXTRACT d00606

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Whitepaper AXTRACT d00606

Transféré par

Droits d'auteur :

Formats disponibles

Axiros White Paper

On-Device QoE Monitoring Via TR-069

On-Device QoE Monitoring

AXTRACT Monitoring Appliance

AXTRACT Monitoring Appliance

About This Document

Scope and Prerequisites

Collected Data / QoE .....................................................................................................5 Beyond Data Models: RunCommand .............................................................................7

On-Device QoE Monitoring

AXTRACT Key Features

Discussion ....................................................................................................................28 Deployment Topologies 29

Proxying Productive TR-069 .........................................................................................30 Setup Parallel to the ACS .............................................................................................32

AXTRACT Monitoring Appliance

Date 10 / 2008 11 / 2009

Release Status Draft, Internal Draft, Restricted Access

Draft, Restricted Access

Draft, Restricted Access

Scope and Prerequisites

AXTRACT Monitoring Appliance

IPTV Packet Loss

IPTV Channel Availability IPTV Video without Disturbance

AXTRACT Monitoring Appliance

AXTRACT Monitoring Appliance

AXTRACT Monitoring Appliance

On-Device QoE Monitoring

AXTRACT Monitoring Appliance

What Is QoE And (How) Can It Be Monitored On-Device?

AXTRACT Monitoring Appliance

As an example we show a screenshot from JDSUs Home PM umbrella monitoring system5 :

Troubleshooting and Support

AXTRACT Monitoring Appliance

Besides QoE: General Relevance of Southbound Performance

AXTRACT Monitoring Appliance

ZigBee, Z-Wave, others

AXTRACT Monitoring Appliance

process inspect DB write load balance / proxy consolidate

AXTRACT Monitoring Appliance

AXTRACT Key Features

Provisioning / Real Time Support Load

TR-069 ACS (Provisioning, Real Time Support))

TR-069 ACS (unchanged)

Data Storage / Dashboard

Data Consumers e.g. Umbrella Monitoring (JDSU)

AXTRACT Monitoring Appliance

Built In Features of AXTRACT

AXTRACT Monitoring Appliance

Flexibility in aggregation, storage and export of the collected data

AXTRACT Monitoring Appliance

AXTRACT Monitoring Appliance

Legacy Device Support

TR-069 Primary ACS Cluster

Telnet PC With TR-069 Client TR-069

Secondary ACS Cluster

SNMP TELNET SSH HTTP

AXTRACT Monitoring Appliance

Extension Modules (APPS)

AXTRACT Monitoring Appliance

InternetGatewayDevice.X_XAVI_Port_A1_LastFailed InternetGatewayDevice.X_XAVI_Port_A1_LocalEndLOS InternetGatewayDevice.X_XAVI_Port_A1_LocalFastChannelRxRate

AXTRACT Monitoring Appliance

InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_RxNotLastError InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_RxOverowError InternetGatewayDevice.X_XAVI_Port_Raw_ethernet_RxShortPacketError

AXTRACT Monitoring Appliance

AXTRACT Monitoring Appliance

High Volume KPI Data