DT GPRS Radio Link Performance Analysis This application allows analysis of the radio link performances, and contains these reports:

Coding Schemes and Throughput per TS

Timeslot allocation statistics

Level and Quality

RLC and LLC Throughput Stats

RLC Throughput and Coding Scheme

RLC Throughput and Level

RLC Throughput and Quality

RLC and LLC Throughput per TBF

BLER and Retransmissions

From the metrics in the Cell Explorer, you can identify any cells that need specific analysis. Then by going through the reports on the selected cells, you can investigate the possible causes. For example, if the BLER is showing a bad behavior, it is possible to analyze the signal level and the quality or of the interference, then see the impact on the throughput, the relation with coding scheme usage, and so on.

DT Radio Link reports Coding Schemes and Throughput per TS report In this report, the value of the throughput (orange line) and the coding scheme usage (CS1 and CS2 columns) is presented for every possible number of allocated timeslots in downlink (from 1 to 4, for the present mobiles).

It is important to note that coding scheme 1 is used for signaling, while coding scheme 2 is preferably used by the allocation algorithms to give higher throughput values, especially in good radio conditions. Some vendors use dynamic algorithms to move from CS1 to CS2 depending on the radio conditions, while others have a fixed CS2 allocation. In this last case, CS1 is only given by the signaling traffic.

Timeslot allocation statistics report This report shows the percentage usage for the different number of allocated timeslots, which can be combined with the results of the previous report.

Level and Quality report This report gives an overview of the radio conditions on the cells tested during the drive. Three graphs are shown: The distribution (vertical bars) and cumulative distribution function or total (dotted line) of the samples of C value (signal strength)

The distribution (vertical bars) and CDF (dotted line) of the samples of the received quality

The interference analysis (obtained combining level and quality measurements)

The last graph highlights the possible presence of interference, when bad quality is shown in combination of good signal strength. The information about C value and Quality are taken from the acknowledge messages. For any given signal strength interval, the number of occurrences (to weight the importance) and the mean received level is presented.

RLC and LLC Throughput Stats report This report provides statistics for the throughput for the RLC/MAC and LLC layers, in both Uplink and Downlink directions.

The first two graphs give the minimum, mean and maximum values for the bit rate, and are useful as general references for radio link performance.

The distributions of the throughput values—the bars indicate the number of occurrences— are useful for studying the nature of the traffic supported. FTP traffic will have a profile similar to that shown below with a throughput concentrated in the higher intervals, while the profile generated by web browsing will be more scattered on the different values, given the less regular pattern of the application level. Accordingly, the Uplink throughput values of an FTP download will be concentrated on low intervals, given by the acknowledge messages.

RLC Throughput and Coding Scheme report This report displays the coding scheme distribution correlated to the throughput values of the RLC/MAC layer transmitted on the radio interface. High throughput values usually correspond to a high percentage of Coding Scheme 2, while for lower levels of throughput CS1 usually prevails, as signaling traffic is low throughput and uses the power coding scheme. In the combined graph, the RLC throughput distribution and cumulative value are shown as colored areas. The trend lines represent the percentage of the coding schemes. In case there is no throughput in a certain interval, a default value of 50% is assigned to CS1 and CS2.

RLC Throughput and Level report The aim of this report is to show the mean signal level (right vertical axis) for the different throughput values. The distribution of occurrences is also reported to weight the importance of the given results (left vertical axis).

RLC Throughput and Quality report The aim of this report is to show the mean received quality (right vertical axis) for the different throughput values. The distribution of occurrences (left vertical axis) is also reported to weight the importance of the given results.

RLC and LLC Throughput per TBF report This graph shows the mean DL throughput at RLC and LLC level for any given TFI number.

BLER and Retransmissions report This report shows the effect of the radio link quality in terms of retransmissions in Uplink and Downlink (not all drive test collection tools support this) and Block Error Rate (BLER). For any interval of retransmission rate values (0 ≤ x < 1%, 1 ≤ x < 2%, etc.), the distribution (vertical bars) and the cumulative (trend line) are represented. A similar approach applies to Block Error Rate.

4 Combined analysis User applications, IP protocols and radio link A complete set of indicators is available for the analysis of user applications (http, WAP, e-mail, FTP, etc.) and the protocols (TCP, UDP, ICMP, etc. on top of IP). These let you investigate the user perception of the quality of the offered services. You can build specific queries and reports to combine the performances with the radio link status. The different equipment vendors use similar methodologies for their drive test data testing products. However, they do use different terminology. Analyzer uses a common terminology, independent from any individual vendor terminology.

From the drive test files you can obtain the following attributes (the actual number of available attributes will depend on the collection device):

Measurements AttributesConnection Measurements Connection Setup Time

Connection DurationConnection FailuresSuccessful ConnectionsDropped ConnectionsConnection IP Address

Application Measurements Application Throughput UL and DL (Average, Peak, Minimum, Instantaneous)Application Received BytesApplication Transmitted Bytes

Application Elapsed TimeApplication Delay UL and DL (Average, Peak, Minimum, Instantaneous)Application Round Trip Time (RTT)Application Round Trip Time Max

Measurements AttributesProtocol Measurements IP Throughput

ICMP ThroughputPPP ThroughputTCP ThroughputProtocol Received BytesProtocol Transmitted BytesProtocol Elapsed Time

…and others specific to single applications (Wen, Ping, FTP, WAP).

Using an IP sniffer allows an independent collection of many of the previous attributes, complementing them with other parameters such as:

For IP IP Address (source and destination

Header and Payload Length

Indicators of QoS class (precedence, delay, reliability)

For TCP TCP port number (source and destination: it allows the identification of the application)TCP connection establishmentTCP connection closureTCP connection establishment abortTCP retransmissionsTCP transmissions timeoutSession Payload LengthAcknowledgesTime with no acknowledgeTCP Session duration…and others.

Radio network and IP/application layers 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.

User-definable reports to build ad-hoc statistical summaries of subscriber-perceived performance matrices.

While investigating the data, users can also benefit from the complete set of internal tools and features provided with Analyzer, such as:

Mapping, charting and reporting modules

Message and protocol stack browsers

Time-series and multi-dimensional statistical query module

Network element database

Filtering and binning module

Finite-state event detection engine

Data merging and synchronization / correlation module

Open data import and export module

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):

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).

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):

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.

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:

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):

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:

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:

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.

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):

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 (the uplink packets maintain the same acknowledgement number): the FTP application on the PC is probably causing this. When it is able to send the updated acknowledge, the transmission restarts.

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.