Aayush: weblog

Posts Tagged ‘OSS’

An alternative for RF Drive Tests- NextGen Smartphone Apps that Integrate with OSS.

Posted by Aayush Bhatnagar on January 1, 2011


Usually in telecom operations, iterative RF coverage audits are common. This is facilitated by drive tests carried out by engineers and technicians who cover the length and breadth of the service areas by road.

These drive tests are an expensive business, both in terms of the costs involved and the human resources needed. Drive test equipment has to be carried physically in vehicles and these vehicles are continuously driven across the service areas of the operator. The results are then post processed manually to identify possible “pain points” for RF coverage.

This practice of drive tests still does not provide the operator with much information on how good/bad indoor coverage is for their customers.

Hence, despite spending a lot of money on drive tests, the biggest pain point of indoor coverage issues still remain unresolved.

With the advent of smart phones and mobile applications, there is a smarter way available for operators to get better RF audit results.

Proposed Solution:

The customer’s smart phone can be used as a RF audit device. A mobile application can run in the background which continuously audits the phone’s signal strength. Whenever the signal strength goes below a configured value, logs are generated at stored in the mobile phone’s internal memory. When the signal is strong again, these logs are pushed to the operator’s OSS/BSS infrastructure for post processing.

Some of the details which can be pushed in the logs can be:

– Latitude and Longitude when the signal went weak.

– Timestamp value when the signal went below the configured limit.

– Latitude and Longitude when the signal became normal again

– Timestamp value when the signal became normal

– Customer’s phone model and operating system details.

By using this solution, the operator can have the same effect as RF drive tests. Moreover, by using this technique the operator can also get information regarding the indoor coverage of the RF signal. The log details can be post processed at the OSS and plotted on a map to identify the problem areas with respect to RF coverage.


I discuss here an alternative architecture for RF audits that leverages an application installed on the end-device. This architecture also shows integration with the back-end OSS (NGOSS compliant system) to achieve automation of test results through well defined NGOSS TAM (Telecom Applications Map) software applications.

These TAM applications will be executed by business processes governed by the eTOM model.

The figure above shows the overall architecture needed to implement this architecture. Major touch points between the software application involved are shown in red circles. The explanation of each touchpoint is discussed in this section. Please note, that the architecture above only shows some of the standardized TAM applications which can be leveraged upon for implementing the proposed architecture. If more functionality is needed, more TAM applications may come into the picture.

The major touchpoints are as follows:

Point 1 – This is the interface between the software application on the smartphone and the OSS. This interface can be HTTP or SOAP/XML. The informational logs from the smartphone are fed to the Resource Performance Monitoring TAM application denoted by the TAM Application ID 7.9.1. This TAM application is responsible for performance data collection in near real-time. This application also co-relates events and filters them. Finally, data aggregation is also performed by this application so that it can be fed to the reporting system.

Point 2 – This interface is shared between the resource performance monitoring application and the resource performance analysis application. This application is responsible for performing the root cause analysis of performance degradation based on the information captured by the performance monitoring application. In our case, the degradation refers to the drop in the signal strength.

Point 3 – Based on the performance analysis, this application feeds the data to the performance reporting application where detailed reports are generated periodically and provided to the operator.  These reports can be generated automatically or even by manual intervention. e.g: If the operator wishes to generate a targeted RF report for the New Delhi Circle, a report will be generated on demand.

Point 4 – In case there is frequent degradation of the RF signal in a particular geography, the resource performance analysis application can raise a trouble ticket. The decision to raise a trouble ticket will be governed by a set of pre-configured rules in this application. These trouble tickets are handled by the Service problem reception, monitoring and analysis applications.

Point 5- In case there is a major network outage resulting in the loss of service for many subscribers, the resource performance analysis application can also raise a critical alarm to the Network Management Systems (NMS). These alarms may be escalated to the NoC (Network Operations Center). Based on the seriousness of the fault being reported, an alarm may be escalated to the Network Operations Center using this touch point.

Point 6 – This is the interface between the Resource performance reporting application and the Resource Design/Assign application. Based on the performance reports, there may be design changes required to the RF network. These change requests/enhancements are fed to the resource design application.

Point 7 – This touch point is between the service problem reception, monitoring and analysis applications which process the trouble ticket, perform the root cause analysis of the problem and decide upon the course of action to be taken to tackle the problem.

Point 8- The Service problem correction application is responsible for taking corrective action to the service problem (loss of RF coverage). Problem correction may be automated (configuring the base stations over the EMS), or it may be required to send a field technician to resolve the fault on-site.  This application may provide significant inputs to the Resource Design application to help avoid similar problems in the future.

What this Solution can’t provide:

1. Drive tests are also used for performing competitive analysis amongst operators. This cannot be achieved using this smartphone application technique.

2. This solution requires the end customer to carry a phone which supports installable applications. Hence, rudimentary phones will not be able to participate in this RF audit and a drive test will be necessary in case the bulk of the customer base carries plain phones.


With the advent of 3G/4G networks, smartphones are available in greater volumes. Hence, 2 yrs down the line they will be with more and more customers. Then this technique will really benefit the operators to drive down costs of RF audits.

Posted in airwaves, BSS, OSS, telecom | Tagged: , , , | 1 Comment »