Troubleshooting Multi-RAB Dropped Calls

The Multi-RAB (Multiple Radio Access Bearer) Dropped Call Problem

With the proliferation of smart phones, the numbers and percentages of multi-Radio Access Bearer calls on your network continue to grow. In fact, youve probably experienced issues that have been born out of Multi-RAB capable handsets. It is actually quite common for multi-RAB calls with circuit switched (CS) and packet switched (PS) services running in parallel to drop more often than calls with a single instance of CS or PS Radio Access Bearer. These types of problems can be quite challenging, because they can go undetected until customers start to complain. And then they take on a new level of challenge as they are assigned to you or your support teams to troubleshoot. About the Case Study This is a case study of a mobile carrier that experienced dropped call complaints for seven months. The RF engineers assigned to the problem were highly skilled, but were not armed with the proper tools to effectively troubleshoot. Tekcomms was enlisted to assist in finding the root causes. This article describes the methodology and tools used troubleshoot the problem. Tools and Tool Operators The are many ways to discover a problem ranging from customer complaints, to analyzing key performance indicators, to testing. But you cant fix a problem until you know the root cause. Finding the source of an issue is the real artwork. The radio environment is an extremely complex ecosystem. The right set of monitoring and troubleshooting tools, coupled with RF Engineering expertise, will take you beyond the symptoms to the source of the problem. Even though the tools are smart and can draw geographical, pictoral and tabular views of network conditions, RF engineering expertise is frequently needed to arrive at the root cause. Arriving at a root cause may require following a series of paths, many of which will end with performing as expected, thus forcing you to pursue alternate routes. Tools coupled with RF expertise will help you negotiate these paths. The Journey to the Root Cause After reviewing the symptoms of the problem with the carriers RF Engineering staff, we looked at the Radio Network Drop Call reports using the Iris Performance Intelligence tool to identify the causes of the dropped calls starting with the Top N Worst Performing eNodeB for Detach Attempts and Failures.

We found that CS and PS calls were dropping at an abnormally high rate, so we filtered the data to isolate the problem. Using Iris Session Analyzers call trace function, we drilled down into the failed CS and PS call record summaries revealing that most failures were for multi-RAB calls vs. single RAB calls.

Drilling into the Multi-RAB Data Next we drilled down into the multi-RAB calls themselves. We opted for a customized report using the Network and Service Analyzer (NSA) tool to allow for deeper root cause analysis. We did this because the customers expert RF engineering staff had deep knowledge of the RF environment, so we choose to go statistical over pictoral. The problem was systemic, so we were able to use historical data. Historical data capture is a nice time-saving benefit of the Tekcomms tool suite because we didnt have to administer a special test environment to capture the data. A quick view of the statistics on "Handset Type" showed that the majority of Dropped Multi-RAB calls were experienced by Apple iPhone users.

To avoid jumping to a conclusion that the iPhone was the source of the problem, we compared this data with the IPI Predefined Top 10 Device Report on handset usage statistics which showed that most of the calls in this network were made using Apple iPhones.

We were able to conclude statistically, that other handsets experienced multi-RAB dropped calls proportionally to the iPhone this eliminated any particular handset as the root contributor and helped us focus on the other potential sources. A Deeper Look at the Multi-RAB Drops To characterize our situation, we looked into RSCP (Received Signal Code Power) and EcNo (Received energy per chip divided by the power density in the band). This first analysis showed protocol causes along with the initial and last measurement results of RSCP and EcNo.

We made an assumption that -100 dBm or higher RSCP was required for good coverage and interference should not generate EcNo levels greater than -14 dB. With these assumptions in place, it was easy to evaluate which of the failed multi-RAB calls dropped due to radio conditions and which must have had other root causes. The next level of analysis brought us to a scatter plot of EcNO vs. RSCP:

So that we could get the executive management team to see things as we saw them, we opted to simplify this visual by drawing a pie chart from scatter plot data. We arrived at the view in Figure 7, which shows that most of the drops occurred despite very good RF conditions.

Narrowing the Path to the Root Cause We had eliminated handsets and RF conditions as major contributors, so we went deeper into the dropped calls report and found the following trends: 50% of the drops were not caused by the phone, but by network elements. We found a 50/50 distribution between NodeB and RNC issues along with multiple types of issues. One example is shown in figure 8 where the multi-RAB call dropped after one of the involved NodeBs was unable to perform the preparation of a serving HSDPA cell change (HSDPA Handover) due to an issue in its state machine. After 5 tries the RNC dropped the call.

Figure 9 shows another contributor to the Multi-RAB drop problem. Activation of compressed mode in the NodeB lead to a NBAP radio link failure resulting in a lost connection with the UE. We doubted that a radio link failure had occurred, because we saw that UL speech frames with good quality were received on the user plane. Even if there had been an issue with the Compressed Mode activation procedure there was no need for the RNC to drop the call.

Next we found that only 20% of the calls dropped due to radio conditions that could be optimized, so we had to look further. Ultimately we found that the chief contributor was that the UE did not increase UL Tx Power after Spreading Factor Reconfigurations or Active Set Update Radio Link Addition Procedures. The typical radio chart for this issue is shown in the figure 10 below:

Stage Conclusion Our conclusion lead us to the equipment manufacturer of the RAN equipment as it was not instructing the mobiles to increase transmit power. We were able to provide all the proof necessary to get the manufacturer to own the issue and commit to a fix. Summary We set out to solve this problem with a top down type of approach. We started with the symptoms and sifted our way through the data until we found potential causes. We used an experienced set of RF engineers along with our Tekcomms toolset to examine the data. This combination of expertise and tools allowed us to narrow our path to the root cause.