Análisis del mercado

There are different metrics available defining the QoS of data services like throughput, delay, jitter etc. In the PDP Context Activation Request message the UE can optionaly request pre-defined QoS profiles as specified in [5]. The CN can check the requested QoS profile with entries from the HLR. The CN makes these negotiated QoS parameters available to the UTRAN via the RAB Assignment Request [9].

Dedicated and common UTRAN resources can be dynamically assigned depending on traffic measurements or load. The initially assigned PS RB at the beginning of a PDP session depends on the UTRAN configuration. The RB can be dynamically changed (or even the mobile is sent to idle mode/URA_PCH/CELL_PCH mode) depending on the data to be sent in the UL and/or DL. Depending on the status of the RLC queue in the UE the mobile might send a Measurement Report “4a” (in case the transport channel traffic volume exceeds an absolute threshold) or Measurement Report “4b” (in case the transport channel traffic volume becomes smaller than an absolute

threshold). The RNC may or may not react on this Measurement Report by doing a RB reconfiguration (see subsection 5.4.1 and 6.17.1). Furthermore a smaller RB can be assigned in case of overload estimations done by the RNC (subsection 6.5).

Another difference when describing the PS data user perceived QoS is that a drop of the RAB and RRC connection does not (necessarily) mean that the PDP Context is removed from the GGSN or the FTP session drops. After the new establishment of the RRC connection and the new establishment of the RAB the FTP session can be resumed in case the session has not timed out in between. For the user the drop of the RRC and RAB is visible by stalling of the FTP transfer for the particular timeframe and because of low throughput rates. In case of real time applications like video streaming or web radio the drop will be noticed by the user if the buffer of the application is emptied and no new data is received. It might be that the application will re-start with codecs requiring lower bandwidth to fill the internal buffer again.

On the PPP link of the PS data session the TCP/IP header and data can be compressed resulting in a throughput increase. For most Microsoft platforms, the PPP compression is an available option in the PPP settings of the dial-up networking. .

In addition also the PDCP layer is providing header compression for e.g. TCP, UDP, RTP and IP header [40].

Simple FTP-download tests of files with the size of 1MB in the UMTS networks has shown that the throughput for zipped binary files is around 25% less compared with the ASCII files.

7.2.3.2. Failure symptoms, identification and fixes for improvement For analysing low PS data performance the following has to be considered:

• UE state • Chosen RB

• _{Reported failures of the transport network (subsection 6.13)}

• Problems detected on the RLC layer e.g. RLC retransmission or RLC resets (subsection 6.14)

• Reported BLER in UL and/or DL (subsection 7.1)

• _{TCP configuration like TCP window size or MSS (see subsection 6.14.1} and the remarks in the appendix of this document)

• _{Retransmission on TCP layer}

• PPP/PDCP compression used/not-used. Usage of zipped files/unzipped ASCII files

The analysis should follow a top-down-approach:

• _{First the end-to-end data performance should be investigated}

• Then delay measurements should be done indicating the source of the performance degradation (e.g. delay due to non-optimal RLC queue, retransmission on RLC etc.)

One example of an (graphical) analysis is shown in Figure 35 below. The throughput of a FTP transfer is measured by Ethereal [30] and visualised by tcptrace [31] is low. The root cause for the non-optimal performance is ConC:

Figure 35: FTP performance degradation caused by ConC

The FTP throughput is the gradient of the curve; in addition TCP retransmission caused by SDU discards on RLC are shown in the right part of the picture (see also subsection 6.14.1).

It is possible to cross-correlate the UE Ethereal traces with Ethereal traces recorded at the FTP server and also with RF data like Ec/No or Active Set Update messages recorded by the UE by e.g. using Actix [29]. In that way FTP performance degradations can be linked to handover problems, bad radio conditions in terms of Ec/No or neighbour definition problems. When the traces are recorded by different mechanisms, it might be necessary to correlate the PC clocks by using time synchronisation see also subsection B in the appendix. Otherwise tools like Actix can do event-based cross correlation.

Another example for an end-to-end analysis is shown in Figure 36 below; the picture is visualising the delay of an ICMP ping between Internet server and PC client for UL and DL separately. The trace was recorded with Ethereal [30]. Furthermore by tracing on the Iub, Iu and Gn interface it is possible to make similar delay plots for the particular interfaces. This will unveil where the high delay peaks are coming from and will give indications of how to improve the end-to-end performance.

Figure 36: end-to-end delay of an ICMP ping

For the same measurement the delay on the Gn interface were also measured as shown in Figure 37 below. As expected the delay is very small and don’t have a big impact on the overall delay. This trace was recorded using a Tektronix K12 protocol tracer.

Figure 37: delay measured on the Gn interface

Problem Trace Trigger

TCP reset TCP Number of occurrences if the REST flag of the TCP options is set to TRUE. Statistic counted per TCP session

TCP

retransmission

TCP Number of occurrences of TCP retransmissions. Statistic counted per TCP session

TCP SACKs TCP Number of SACK. Statistic counted per TCP session

Table 72: Identification of QoS issues for data service

Table 73 below is listing the data QoS parameter including the trigger points for identifying non-optimal performance:

KPI Counter / KPI

PDP context activation failure [%] NoUnsuccessfulPDPActivation / NoPDPActivationAtt * 100 PDP context activation time [s] t_pdp_activation_complete – t_pdp_request PDP context cut off rate [%] NoPDPLosses / NoSuccessInitiatedPDP * 100

FTP cut off rate [%] NoFTPLosses / NoSuccessStartedFTP * 100

FTP throughput [kbit/s] UserDataTransferred [kbit] / (t_ftpend – t_ftpstart)

Ping delay [s] RTT of a ICMP with a payload of 32 bytes

HTTP failures [%] NoSuccHTTPTasks / NoHTTPTasksStarted *100

RB Assignment Success Rate [%] NoSuccAssignedRB / NoRequestedRB * 100 Table 73: QoS of data services – KPIs