Mobile Device Agents

By | March 22, 2012

Today, I want to talk about a new trend that seems to popped up in the SQM/CEM field: Mobile Device Agents.

Mobile Device agents are software components that reside on user devices and collect statistics about the quality of user experience which will enable the operator to act upon service degradation. Operator can also have the same data correlated with service quality data to plan future service improvements.

Device agent term is fairly new for the mobile industry. However, this is not the case for the fixed line. In fixed line, operators have been collecting metrics about the given end-to-end service for years. These metrics are collected from CPE(Customer Premises Equipment) devices (mostly routers and L2 switches) that reside on the customer premises. Ideally, but not necessarily, these devices are also managed by the operator, taking the name Managed CPE. By utilizing data coming from these CPEs, operators are able to measure not only the core network health, but also the Access side.

In order to increase user perceived quality,  service providers continuously seek new datasources that will give clues about the customer’s service perception. Customer usage data can be collected in several places:

–          Probe systems

–          DPI systems

–          Device Agent systems

Probe system and DPI system can provide the top most visited URLs, throughput/speed kind of statistics that will give clues about the service usage. Probe systems can additionaly provide call drop statatistics and catch device configuration errors.

Device agents can do both. But, they also provide device related information such as signal strength or battery status. They even can tell which software along with their versions are installed on the phone.

If we collect all this data (usage + device + signalling) and correlate successfully, we can do lot’s of customer experience related analysis with it. We can detect that a specific service usage drop from the DPI system and correlate this with mobile phone configuration errors.  The dropped calls can be correlated with device battery information to see if the dropped call has occurred because of a device problem. In some cases where the operator has not done any investment to DPI and probe systems, just the Device Agent system can provide all that data.

But why device agents are not so popular? First answer is the privacy. Most people will not want agents on their phones that are sending their usage patterns to somewhere else. There are not so many regulations around this but we should expect to see them soon.

The second answer is more technical. The agents consume processing power and drain the batteries soon. In order to get rid of this, agents should not always be on-line, and collected statistics should be uploaded in relatively longer intervals (a couple hours). That late data cannot be utilized by SQM systems so it can only be used for late correlation and planning purposes.

Device agents use push mechanism and upload their statistics to a central server where further correlation and reporting functions can be executed. However, because of the reasons I have provided, they cannot be real-time data sources which are required by most SQM/CEM systems.

3 thoughts on “Mobile Device Agents

  1. Bryan

    Hi Murat,

    Its only becoming technically feasible and commercially attractive to consider mobile UE as a data source.

    I think privacy is best resolved with an opt-in policy, and transparent business models.

    Though a consideration (clear and present design challenge), I don’t think UE power consumption or data latency are intractable.

    Best Regards,
    Bryan

  2. Hua Fei

    Hi Murat,

    It’s interesting topic.

    I wonder how to collect 7*24 DPI data and signalling of chipset level in passive mode for smart phones of various brands. The problem is to get root rights to collect DPI data for Android/iOS/RIM, and to get the general interface for signalling, which makes it hard to support various cell phones.
    Otherwise, OS level API can not support signalling and further KQI inspection.

    Is there any way out?

    Kind Regards,
    Huafei

  3. M.Saad

    What about switch based call trace data that is quite common as a feature and a data source provided the the NEP’s, some very attractive solutions that can geo-locate this type of data can provide accurate information regarding subscribers location (within 50-100m accuracy) and provide information on signaling, coverage, drops, throughput as well as type of service…..

Comments are closed.