Analyzer provides the following features for advanced evaluation of radio link and subscriber-perceived performance:
Detailed attributes for every network layer up to the application layer.
User-definable queries allow custom metric calculation based on finite-state event detection and time-series attributes.
2 Data merging and synchronization / correlation module
Open data import and export module These features are described in the online help.
Some examples of troubleshooting using ad hoc analysis are provided below. You can use these as the basis for creating other types of analysis, depending on the specific type of investigations required.
Example 1
Operators are focused on verifying the service as perceived by the subscribers. To do that, it is necessary to identify the services used and evaluate the user perceived performance indicators (typically throughput and delay).
It is possible to use predefined queries (provided during the training courses) that give the overall view of the single tasks (FTP sessions in this case):
List of application tasks displayed in the Statistical Explorer
The proposed drive test shows a connection (result of the PdP Context Activation), and then a ping is performed. The ping—although not a user application—is often used to provide an indication of the minimum delay that the network can support.
The actual service used is an FTP download and upload of 30K and 15K. The throughput results are generally good: around 30 kbps using 3 timeslots (see below).
2
Timeslot allocation statistics report
Only one task (row 6, highlighted in the previous screenshot) is not showing a performance in line with the others, and should be investigated in more detail. The following chart enables us to visualize the content of the complete drive test, and shows the user-perceived metrics (application throughput and delay), combined with the corresponding network parameters (LLC and RLC throughput):
2 We can now investigate to see if radio events like cell reselection are responsible for the
throughput degradation. In the screenshot below, the DL TBF number (TFI) is displayed and shows a regular pattern.
Cell reselection impact
The cell reselection has an impact on the next task but not on number 6. We can focus on the task filtering it by selecting the task in the Statistics Explorer and clicking the Filter button:
2 Looking at the DT GPRS Radio link performance analysis module (see below) it is clear that
one of the two cells driven during that task (automatically everything has been filtered in accordance to it) has a quality problem (mean Rx Quality = 3 with mean C-value of –61 dBm):
DT GPRS Radio link performance analysis
To make this more explicit, the report on the level and quality can be run on that cell. The interference analysis graph shows what is clearly an interference problem:
2
DT GPRS Radio link performance analysis
The result of the analysis is, therefore, that the application is showing a good performance, but a specific cell is showing interference. This can be eliminated, for instance by revising the frequency plan.
Example 2
This example focuses on studying the throughput on the different layers (application, TCP, IP and RLC), using the information from the drive test combined with the IP sniffer data. The first step is to display a summary with a query in the Statistics Explorer:
2
Downlink throughput study for the single tasks
The task type (i.e. application in use) is obtained using the TCP source port number (that indicates the type of application that is generating the downlink traffic) and ICMP type (some pings are occurring between the FTP downloads).
The focus is on the first FTP session, filtering it and using the reports of the radio link module. The radio performance is good: level and quality, RLC and LLC throughput, timeslot allocation is 3 TS all the time, the CS used is CS2 92% of the time. However, the throughput is not maintained at the maximum all the time—this is unexpected since FTP is used and 3 timeslots are constantly allocated.
2
2
Throughput and coding scheme per timeslot
If there is no radio problem, let us raise the analysis to the higher layers, displaying the attribute TCP_Data_Pending_AckDL (indicates the total bytes with an acknowledgement pending indownlink), and TCP_Network_Bytes_Acknowledged (indicates the total bytes acknowledged from every acknowledgement message):
2
TCP investigation on a chart
The red ellipse above corresponds to the red square shown below. They show that the packets in downlink are no longer acknowledged, and the pending bytes accumulate until they reach the size of the TCP receiving window (equal to 16072 bytes). At that point, the receiving buffer is full and the packets would be discarded, so the transmission is stopped. In fact, the throughput goes to zero.
The figure below shows that the packets are received on the PC COM port (the sequence number continues to be incremented) but the corresponding acknowledgements do not
2
TCP investigation on sequence numbers, acknowledges and received bytes Also in the rest of the session there are other events like this, but they have a smaller effect on the throughput because the receiving window does not saturate again (the acknowledge restart before the pending bytes reach the window size).
So, in this example, an application problem was found in that the FTP client on the PC was not able to process all the received data.
In case we want to analyze other tasks, we would need to go back to the old query and disable the filter on task number 1, select another task and repeat the analysis.