Application Paper: UMTS Throughput Measurements for Single Call Analysis in NSA Call Analysis Radio Chart

Contents of this Document

This document contains a brief description of detailed algorithms on how the throughput graphs for different user plane layers in the Radio Measurement Chart of NSA Call Analysis shown in the figure below are calculated.

Figure: DL Throughput Measurement Graphs in NSA Call Analysis Radio Measurement Chart

RLC throughput = Transport Channel throughput

Transport Channel Throughput is defined as the sum of all bits of all transferred transport blocks in FP DATA frames that provide transport services for a single radio bearer (DTCH) or to a set of coordinated radio bearers in case of AMR voice call (one RB for each AMR bit class).

The throughput of transport channels used to transmit signalling radio bearer (SRB) info is NOT measured in NSA and OptiMon Single Call Analysis

23-Sep-09, Page 1

UMTS Throughput Measurements for Single Call Analysis in NSA Call Analysis Radio Chart

Graphs. Throughput of single calls is measured for user plane information only.

If a call is in soft handover it must be ensured that duplicated transport blocks received/send on the involved Iub interfaces are not taken into account for throughput measurements. The measurement must reflect the throughput on the level of direct connection between UE and SRNC. On this level each transport block is sent/received only once although this one transport block in soft handover situations can be monitored on multiple Iub/Iur logical links.

For discarding duplicated UL transport blocks the macro-diversity combining algorithm may be used. Otherwise the same algorithm as for DL filtering can be used. For DL filtering a simple proprietary algorithm based on comparision of FP connection frame number (CFN) shall be implemented.

Since the size of RLC transport blocks cannot be derived from any protocol information in the RLC PDU itself the number of occurrence of Transport Format Index during the sampling period must be counted. The transport block size belonging to a TFI must be derived from NBAP signalling information and stored as a context value as long as the call is active. Following NBAP RL reconfigurations the stored transport format information need to be updated. See screenshot below for necessary information elements:

For connections using HS-DSCH and/or E-DCH the PDU size is found in FP header as MAC-d PDU length (see screenshot below).

23-Sep-09, Page 2

UMTS Throughput Measurements for Single Call Analysis in NSA Call Analysis Radio Chart

The data volume used to compute the transport channel throughput includes all bits of data frames transmitted on Uu interface. The RLC/MAC header, padding bits and retransmitted RLC transport blocks are included. RLC Status messages are not included.

User Perceived IP Throughput

This is the throughput measured for successfully transmitted user plane RLC SDUs. Separate measurements for uplink and downlink IP traffic are required.

The measurement must reflect the throughput on the level of direct connection between UE and SRNC. On this level each RLC SDU is sent/received only once although this one R RLC throughput = Transport Channel throughput

Transport Channel Throughput is defined as the sum of all bits of all transferred transport blocks in FP DATA frames that provide transport services for a single radio bearer (DTCH) or to a set of coordinated radio bearers in case of AMR voice call (one RB for each AMR bit class).

The throughput of transport channels used to transmit signalling radio bearer (SRB) info is NOT measured! This means: throughput of single calls is measured for user plane information only.

If a call is in soft handover it must be ensured that duplicated transport blocks received/send on the involved Iub interfaces are not taken into account for throughput measurements. The measurement must reflect the throughput on the level of direct connection between UE and SRNC. On this level each

23-Sep-09, Page 3

UMTS Throughput Measurements for Single Call Analysis in NSA Call Analysis Radio Chart

transport block is sent/received only once although this one transport block in soft handover situations can be monitored on multiple Iub/Iur logical links.

For discarding duplicated UL transport blocks the macro-diversity combining algorithm may be used. Otherwise the same algorithm as for DL filtering can be used. For DL filtering a simple proprietary algorithm based on comparision of FP connection frame number (CFN) shall be implemented.

Since the size of RLC transport blocks cannot be derived from any protocol information in the RLC PDU itself the number of occurrence of Transport Format Index during the sampling period must be counted. The transport block size belonging to a TFI must be derived from NBAP signalling information and stored as a context value as long as the call is active. Following NBAP RL reconfigurations the stored transport format information need to be updated. See screenshot below for necessary information elements:

For connections using HS-DSCH and/or E-DCH the PDU size is found in FP header as MAC-d PDU length (see screenshot below).

23-Sep-09, Page 4

UMTS Throughput Measurements for Single Call Analysis in NSA Call Analysis Radio Chart

The data volume used to compute the transport channel throughput includes all bits of data frames transmitted on Uu interface. The RLC/MAC header, padding bits and retransmitted RLC transport blocks are included. RLC Status messages are not included.

User Perceived IP Throughput

This is the throughput measured for successfully transmitted user plane RLC SDUs. Separate measurements for uplink and downlink IP traffic are required.

The measurement must reflect the throughput on the level of direct connection between UE and SRNC. On this level each RLC SDU is sent/received only once although this one RLC SDU in soft handover situations can theoretically be reassembled on multiple Iub/Iur logical links.

The SDU size can be derived from Total Length value found in the IP header (see figure below):

User Perceived Throughput formula: # RLC SDUs * SDU size (bit) / time interval (sec)

TCP Throughput

23-Sep-09, Page 5

UMTS Throughput Measurements for Single Call Analysis in NSA Call Analysis Radio Chart

Since on TCP layer no length field is found that indicates the size of the TCP block to only way to measure the data volume of TCP blocks is do it using SDO information as already explained in case of FP throughput before.

TCP and FTP Data Frame In the example screenshot the data volume of the TCP block is 1480 byte.

FTP Application Throughput

The FTP frame contains pure data and there is not length field in TCP, but data offset information field. This data offset indicates related to first bit of TCP frame where payload field of TCP frame begins. Since whole TCP frame is organized in multiples of 32 bits (4 Byte) it is clear that 5 x 4 Bytes = 20 Byte that need to be subtracted from total TCP frame length to get payload field size. This payload field size is equal with the data volume of the FTP header.

UDP Throughput

23-Sep-09, Page 6

UMTS Throughput Measurements for Single Call Analysis in NSA Call Analysis Radio Chart

In case of UDP it is easier, because UDP header has a fixed size of 8 Byte that can be subtracted from length field that indicates size of whole UDP frame: header plus UDP contents (= UDP payload).

UDP Datagram with Length Indicator

Sampling Period - Common Definition

The sampling period (time interval) of all throughput measurements in the Radio Measurement Chart is 1 second.

23-Sep-09, Page 7

UMTS Throughput Measurements for Single Call Analysis in NSA Call Analysis Radio Chart

Author: Ralf Kreher, Tektronix Berlin; email: ralf.kreher@tektronix.com

This document provides internal information on a product solution to employees of Tektronix, Inc. and is not intended for wider publication. Whilst the information is prepared in good faith, no warranty is given as to its accuracy or completeness. Tektronix reserves the right to change the contents of this document in any way for any reason and at any time. Copyright (c) Tektronix, Inc. 2002. All rights reserved. Licensed software products are owned by Tektronix or its suppliers and are protected by United States copyright laws and international treaty provisions. Tektronix products are covered by U.S. and foreign patents, issued and pending. Information in this publication supercedes that in all previously published material. Specifications and price change privileges reserved. TEKTRONIX and TEK are registered trademarks of Tektronix, Inc.

Tektronix Berlin Wernerwerkdamm 5 13629 Berlin GERMANY

23-Sep-09, Page 8