Push-to-Talk over Cellular over High Speed Downlink Packet Access A Performance Evaluation

ERIK KERFELDT A

Master of Science Thesis Stockholm, Sweden 2005-01-31

IR-SB-EX-0503

Push-to-Talk over Cellular over High Speed Downlink Packet Access - A Performance Evaluation
Erik kerfeldt A January 27, 2005

Abstract In this master thesis, the performance of the Push-to-Talk over Cellular (PoC) service will be investigated, when provided over the High Speed Downlink Packet Access (HSDPA) of the WCDMA radio interface. A statistical trac model for PoC trac is derived, and the performance evaluation is carried out using an HSDPA capable WCDMA simulator. The measures used for evaluating performance are delay and throughput, and user satisfaction as a function of delay. Also, the capacity in terms of code usage and interference is studied. To put the HSDPA results into perspective, a comparison is made to a dedicated channel downlink. Also, two dierent uplink congurations are evaluated for use with HSDPA, one of 16-kbps and one of 64-kbps bitrate. The results show that PoC can be relatively well provided over HSDPA, with capacity approximately equal to that of the dedicated channel case, but with slightly lower delay. The main HSDPA issue is the downlink code limitation, which occurs due to the vast number of signaling channels that need to be set up. In the case of the dedicated channel downlink, the limiting factor is rather the uplink interference, especially in the 64-kbps case. It is concluded also that the relatively large protocol overhead of the PoC service is limiting performance.

Contents
1 Introduction 1.1 1.2 1.3 1.4 1.5 Problem Denition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 6 6 6 7 8 8 9 9

2 Universal Mobile Telecommunications System 2.1 2.2 2.3 UMTS Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WCDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 2.3.2 2.4

WCDMA Network Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Layer structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.1 2.4.2 HSDPA Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Code Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 15

3 Push-to-Talk over Cellular 3.1

Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1.1 3.1.2 3.1.3 IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Group And List Management Function . . . . . . . . . . . . . . . . . . . . . . 16

PoC Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 3.3

Session Control Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Floor Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4

Voice Data Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4.1 Bits Transmitted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 20

4 Trac Model 4.1 4.2

Session Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Trac Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.1 Bit Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3

Model Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 24

5 Performance Measures 5.1

Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1.1 5.1.2 5.1.3 Delay Measure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 End-To-End Delay Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Relevance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2

Cell Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2.1 5.2.2 5.2.3 5.2.4 Satised User Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Interference And Code Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Cell Capacity Measure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Relevance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3

System Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.3.1 Relevance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 31

6 Simulation 6.1

Simulator Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1.1 6.1.2 6.1.3 6.1.4 Cell Layout and User Movement . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Radio Link Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 WCDMA Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.2

Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.2.1 6.2.2 Simulations Made . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 RAB Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 37

7 Results

7.1

HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 7.1.1 7.1.2 7.1.3 16-kbps Uplink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 64-kbps Uplink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Varying Number of AMR Frames . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.2

DCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 53

8 Conclusions 8.1

Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 57 59

A Channel Congurations B Detailed Results

B.1 HSDPA with 16-kbps Uplink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 B.2 HSDPA with 64-kbps Uplink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 B.3 DCH 16-kbps Uplink and Downlink . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Abbreviations
16QAM 3GPP AMR ARQ BER BLER CIR CPiCH DCH DL EGPRS GLMS GPRS GSM HS-DSCH HSDPA IMS IP ITU MAC MCS NodeB OTAP PDU PTT PoC QPSK QoS RAB RAN RFC RLC RNC ROHC RRC RTCP RTP SF SIP SRB TTI TrCH UDP UE UL UMTS UTRAN WCDMA 16 Quadrature Amplitude Modulation Third Generation Partnership Project Adaptive Multi-Rate Automatic Repeat Request Bit Error Rate Block Error Rate Carrier-to-Interference Ratio Common Pilot Channel Dedicated Channel Downlink Enhanced General Packet Radio Services Group and List Management Server General Packet Radio Services Global System for Mobile communications High Speed Downlink Shared Channel High Speed Downlink Packet Access IP Multimedia Subsystem Internet Protocol International Telecommunication Union Medium Access Control Modulation Code Scheme Radio base station in UTRAN Over The Air Provisioning Protocol Data Unit Push-to-Talk Push-to-Talk over Cellular Quadrature Phase Shift Keying Quality of Service Radio Access Bearer Radio Access Network Request For Comments Radio Link Control Radio Network Controller Robust Header Compression Radio Resource Control RTP Control Protocol Realtime Transport Protocol Spreading Factor Session Initiation Protocol Signaling Radio Bearer Transmission Time Interval Transport Channel User Datagram Protocol User Equipment Uplink Universal Mobile Telecommunications System UMTS Terrestrial Radio Access Network Wideband Code Division Multiple Access

Chapter 1

Introduction
The third generation of cellular radio networks has enabled several packet switched services in a wireless environment. One such service is Voice over IP (VoIP) and the Push-to-Talk application in particular. Push-to-Talk is a walkie-talkie like service, which allows for using the mobile phone for quick half-duplex communication with just a push of a button. This may be useful for private communication between friends, but also for businesses like delivery rms and taxi companies. The Push-to-Talk service has been available in USA for some years, and rapidly become popular, especially in urban areas as New York [1]. The American systems are based on proprietary vendorspecic solutions dedicated for the Push-to-Talk service and hence cannot be implemented in the existing infrastructure for mobile communications in Europe. However, the American systems, with the largest operator being Nextel, are considered fast and reliable and are used by many. Another approach to providing the Push-to-Talk service is Push-to-Talk over Cellular (PoC), which is a specication of Push-to-Talk in packet switched cellular networks. This specication has been developed by an industry consortium supported by Ericsson and others, and submitted to the Open Mobile Alliance (OMA) as a proposed standard. PoC is based on the Internet Protocol (IP) and is not biased to a particular radio network architecture. Thus, it can be implemented on both European WCDMA networks and American CDMA2000 networks. Currently some pre-standard implementations of PoC are available, which use the General Radio Packet Service (GPRS) of GSM. In this thesis, it will be investigated how PoC operates in the WCDMA network, and more precisely over a high-speed channel called HSDPA. HSDPA is a concept that allows for higher data rates than previous WCDMA versions, but only in the downlink. The aim is to examine how well and ecient PoC can be provided over HSDPA and how large (if any) the improvement is compared to other, slower channels.

1.1

Problem Denition

The problem addressed in this thesis may be formulated as a question: how well can the service Push-to-Talk over Cellular be provided over HSDPA, and what, if any, are the gains compared to standard dedicated channels? HSDPA improves only the downlink, while PoC is a bidirectional service, and thus the limitations of the uplink must be considered and requirements specied. It will also be investigated whether it is the uplink or downlink that limits the HSDPA performance. To put the results into perspective, a comparison will be made to a dedicated WCDMA channel of 5

relatively low bitrate.

1.2

Approach

The word well used in the problem denition needs to be dened, which is done in Chapter 5. The measures used for determining how well PoC is provided are latency (packet delay), cell capacity and throughput, where cell capacity is measured in terms of user satisfaction based on a delay criterion. The approach to getting the performance information is to study the characteristics of PoC trac, based on the OMA specication, in order to learn how packets are generated and transmitted. It will be examined how much data each user need to transmit and receive, how often and for how long. The PoC trac situation will then be modeled in a Matlab-based simulator developed at Ericsson Research. The simulator is capable of simulating WCDMA networks including the HSDPA functionality, but has no specic handling of the PoC service. Hence, a simulator function modeling PoC trac must be added.

1.3

Goal

The goal is to arrive at concrete results (from simulations) showing the characteristics of HSDPA when carrying PoC trac, in terms of the selected performance measures. Also, it is intended that the dierences between HSDPA and a dedicated channel downlink should be made clear. An absolute answer to what channel is better will however not be given, as this to some extent is a matter of preferences. It will be seen, that the choice depends partly on whether delay or capacity (users/cell) is most important. Furthermore, the study aims at highlighting the uplink limitations of HSDPA when carrying PoC trac, and at specifying the uplink requirements.

1.4

Related Work

PoC is a new service, which has not yet been implemented in commercial networks, and this is reected in the fact that the number of published studies of PoC performance seems to be very limited. Also, providing PoC over HSDPA is somewhat unconventional, as HSDPA originally was designed for high-bitrate best-eort downlink applications rather than a relatively narrow-band semirealtime service as PoC. However, PoC has many similarities with the Voice-over-IP (VoIP) service, as both demand transmission of voice with low delay in IP-networks. There are also dierences, mainly that PoC is only a half-duplex service, which will be discussed further in Chapter 3, but nevertheless the numerous studies of VoIP in WCDMA networks may hint about what performance can be expected for PoC. In [2], simulations of VoIP carried by the dedicated channels of WCDMA are made, and it is concluded that it is possible to provide the VoIP service with reasonable quality over such channels. It is assumed that a total end-to-end delay of 250 to 300 ms is acceptable, and shown that this limit is not exceeded. It must however be noted that the delay is closely related to the conguration of the channels used, which will be discussed later in this thesis, and that there may be a trade-o between delay and user capacity. The study includes neither HSDPA nor any other shared channels. Another study of VoIP in WCDMA networks is done in [3], also based on simulations, and the results show that the delays over the dedicated channels are approximately as in [2]. The study includes also 6

a simulation of VoIP over the so called DSCH (Downlink Shared Channel), from which HSDPA partly has developed, and this is probably of more relevance for this thesis. It is concluded that transmission delays are approximately 30% lower for the shared channel compared to the dedicated channels, and that the reason is mainly the shorter transmission time intervals of the DSCH. HSDPA, as will later be described, has even shorter transmission time intervals and several other enhancements, and can thus be expected to decrease delays further. Other studies of VoIP in radio access networks can be found in [4] and [5], both considering (E)GPRS rather than WCDMA. A partially relevant study is done in [6], which investigates the performance of PoC in WCDMA networks. The study is however limited to the setup and termination times of PoC sessions, not the actual voice transmission delays. The setup times are beyond the scope of this thesis, but it may nevertheless be noted that the study concludes that session setup times are on the order of 1500 ms, which is considered suciently low. Finally, there are a large number of studies looking at the HSDPA concept in general, i.e. when used not specically for PoC. Simulations done in [7] show that HSDPA is capable of providing bitrates up to 8-10 Mb/s under favorable conditions, while the study in [8] point at bitrates up to 4 Mb/s on average. A third study can be found in [9], which is focused primarily on to what extent the higher order modulation supported by HSDPA (see Section 2.4) contributes to the performance improvement.

1.5

Thesis Outline

The thesis is outlined as follows. A description of the UMTS/WCDMA system will rst be given, including the HSDPA concept. Next, the PoC service as specied by OMA will described, with focus on the trac pattern and amount of bits generated. This is followed by a detailed explanation of the trac model. The thesis is continued with a description of the performance measures used for evaluating PoC performance, and a review of the simulator. The simulation setup and channel congurations are also covered. Finally, the results are presented and analyzed, followed by conclusions and a discussion of possible improvements and further work.

Chapter 2

Universal Mobile Telecommunications System

The increasing number of wireless users and applications has placed new demands on capacity in the radio networks. The network is required not only to oer services as voice and SMS, but also internet access and streaming video. Applications of this kind call for bitrates signicantly higher than those of second generation systems. To meet these demands, new spectra have been allocated, and a new third generation technology developed. Systems of this kind are by the International Telecommunications Union (ITU) referred to as IMT-2000, and by the European Telecommunications Standards Institute (ETSI) as UMTS. UMTS, the Universal Mobile Telecommunications System, species what services the third generation systems will be capable of providing, and what network architecture should be used.

2.1

UMTS Functionality

UMTS oers both tele-services as speech and SMS, and general bearer services that can transfer any information between two points. These services can be either connection-oriented or connectionless, and can be congured for dierent quality of service parameters and bitrates. The ITU has specied that IMT-2000/UMTS systems should be capable of providing the following bitrates [23]. 144 kbps for rural outdoor environments, 384 kbps for urban outdoor environments and 2048 kbps for indoor and low range outdoor conditions. Four types of bearer classes have been dened for UMTS, specied in terms of their Quality of Service (QoS) parameters. These classes have the following characteristics. Conversational bearer class. Intended mainly for voice telephony, low delay and strict ordering. Streaming bearer class. Used for e.g. watching a video clip, moderate delay and strict ordering. Interactive bearer class. Used for web surng etc, moderate delay but no data ordering. Background bearer class. Used for e.g. le transfer, no delay requirements or ordering. 8

The HSDPA concept, which is studied in this thesis, is designed mainly for the interactive and background bearer classes, and is consequently not intended for realtime trac. The semi-realtime characteristics of PoC, and the fact that it is half-duplex, however makes this service suitable for transport over an interactive bearer as HSDPA.

2.2

Network Architecture

The UMTS network is subdivided into three conceptual subsystems: the Core Network (CN), the UMTS Terrestrial Radio Access Network (UTRAN) and the User Equipment (UE). The responsibilities and scope of these subsystems are described below. The Core Network handles switching, user registration and overall network operation and control. It is divided into a circuit-switched and a packet-switched domain which both use Asynchronous Transfer Mode (ATM) for data transfer. Also, home and visitor location registration, authentication and billing are handled by the core network. The UTRAN handles the connection between the user equipment and the core network. Its main purpose is to isolate the core network from all issues involving radio when communicating with the UE. The interface between the UTRAN and the core network is called Iu, and the interface between UTRAN and UE is called Uu. While the latter interface is considered to be part of the UTRAN, the former is not. The UTRAN consists of a number of base stations, referred to as Node B:s, and a number of Radio Network Controllers (RNC). The Node B:s handle one or more cells of the network, and are controlled by an RNC. Every RNC controls several Node B:s.

Figure 2.1: UMTS architecture

2.3

WCDMA

The radio technology chosen for UTRAN is Wideband Code Division Multiple Access, WCDMA. WCDMA is specied by the 3rd Generation Partnership Project (3GPP) and operates in the 2-GHz frequency band. The outspoken goal is to make WCDMA a global standard for the 3G radio access technology, and it is not unlikely that this will be achieved [10]. WCDMA networks are currently implemented in numerous European countries, as well as in North America, Japan and Asia. In addition to higher bitrates, there are many other improvements in WCDMA compared to second generation systems. Among these are improved coverage and capacity, support for inter-frequency hand-overs, adaptive antennas and multiuser detection, and a fast and ecient packet-access protocol. Also, as WCDMA developed further, the high-rate concept of HSDPA was added. The HSDPA functionality will be described in Section 2.4. 9

2.3.1

WCDMA Network Functionality

In this section, an overview of the the basic functionality of a WCDMA network will be given.

General Principles As the name implies, WCDMA uses code division for multiple access, meaning that orthogonal codes are used for separating logical channels. This is an alternative to frequency or time division multiple access and is more spectral ecient. The principle of CDMA is, somewhat simplied, to multiply each data bit with a code of n bits that is orthogonal to all other codes used, so that the bit sequence to be transmitted becomes n times longer than the original sequence. A broader frequency band is then needed for the transmission, but it can be shared with other channels due to the code orthogonality. At the receiver, the sequence is correlated with the same code, in order to extract the original data [14]. The length n of the code is called the spreading factor, SF, and denes the maximum number of logical channels possible to transmit in parallel. Channels of dierent spreading factors can be present simultaneously, as long as the code resource is not exhausted.

Algorithms A number of algorithms are implemented in the WCDMA network, to ensure secure and ecient operation. Power control is used to regulate the transmission power of the UE:s, so that the received power at the Node B is (approximately) equal for all UE:s. This is to ensure that UE:s close to the Node B do not shout down UE:s more distant by transmitting at excessive power. The power control is carried out at two dierent time-scales, called inner and outer loop power control. As a user roams in the WCDMA network, it is necessary to hand over the control of the UE from one cell to another. This process is called hand-over (or sometimes hand-o). In WCDMA, it is possible for a UE to be simultaneously connected to more than one Node B. In this case, the UE adjusts its output power to the minimum required by the available Node B:s, and may as a consequence switch between cells very quickly. This feature is referred to as soft hand-over, and does not only save power, but also reduces the risk for dropped calls. The admission control function controls how users are admitted into the system, and is needed to avoid overload. In WCDMA, as opposed to e.g. GSM, the aim is to always maintain the QoS of the admitted users, and thus it must be ascertained that there is sucient resources left before a new user can be admitted. Admission control is divided into two parts, the session admission control and the link admission control. Session admission control decides whether there are sucient resources to admit a new user of a certain service, based on knowledge of how many sessions the system can handle without loss of QoS. Link admission control works on a shorter time scale, and checks whether or not it is possible to set up a new link (e.g. a dedicated channel, DCH) for a specic session. Setting up new links may be required during a session if the user is in soft hand-over, or transmits so much data that an up-switch to a broader channel is necessary. In the downlink, the link admission control performs both a code usage check and a load check. The code usage check ensures that there is always sucient code space for all admitted links, i.e. that

10

c=
i

1 <1 SFi

where c is the code usage, and SFi the spreading factor of link i. Link admission control admits new links only if c will remain less than one after the admission. The downlink load check tests if there is enough power available for setting up a new link. This is done by calculating the total power used by the current links, and estimating the power increase that will be caused by the new link. If the total power after admission of the new link exceeds a prescribed limit, admission will be denied. In the uplink, link admission control performs a load check to ensure that the uplink interference does not compromise the coverage. Similar to the downlink, a parameter controls the uplink load limit in terms of power.

2.3.2

Layer structure

The various functions needed to eciently and securely carry data over the WCDMA radio access network, are organized in a layered structure, similar to most other types of networks. The three layers are the Physical Layer (L1) handling the physical radio transmission, the Media Access Control (MAC) layer and the Radio Link Control (RLC) and Radio Resource Control (RRC) layer. Above these is the packet data convergence protocol (PDCP) layer, oering services to the core network and UE, but PDCP is not considered part of the radio access network.

Physical Layer The physical layer of WCDMA includes all functions related to the actual transmission of data over radio. It handles many complex issues as coding, multiplexing, interleaving, rate-matching etc, and hides all this to the above layers. The result is a number of transport channels (TrCH) that are oered to higher layers. For this study, the most important of these are the Dedicated Channel (DCH) which is a bidirectional dedicated channel for data transfer between a UE and the Node B, and the High-speed Downlink Shared Channel (HS-DSCH) which is the downlink TrCH for HSDPA.

Media Access Control Layer The MAC layer oers the service of data transfer to the layers above. It handles the selection of an appropriate bitrate, service multiplexing onto single physical layer TrCH:s and priority handling between multiple user data ows. Also, the MAC layer caters for access control, address control and contention resolution on the RACH (Random Access Channel), which is a shared uplink TrCH.

RLC and RRC Layer The RLC handles the establishment and release of MAC layer connections. RLC can be used in three dierent modes, depending on the characteristics of the service carried. These modes are the Transparent Mode (TM), the Unacknowledged Mode (UM) and the Acknowledged Mode (AM). In TM no header is added at the RLC layer which means that the ordering and error correction of data must be catered for elsewhere, in UM some header information is added but data received in error is not retransmitted, and in AM a header is added and erroneous data is retransmitted. TM is used

11

primarily for speech calls while AM is used for services where delay is less important but data errors are not acceptable, e.g. e-mail. The RRC includes system information broadcasting, radio resource handling, QoS control and UE measurement reporting. The RRC exists at the same level as RLC, but is used for control rather than data transfer.

2.4

HSDPA

As new packet-data services are introduced, and the user terminals become more advanced, higher data rates are required in the wireless networks. The answer to this demand in WCDMA is a concept called High Speed Downlink Packet Access, HSDPA. As the name implies, the HSDPA concept oers higher data rates in the downlink for packet-switched services. In release 99 of WCDMA, the highest bitrates available are 384 kbps for wide area coverage, and a maximum of 2 Mbps for certain hot spot areas like oces and airports. This may be enough for many applications, but as users begin to connect to WCDMA with laptop computers and PDA:s, higher data rates are required throughout the whole cell. Theoretically, HSDPA allows for up to 14 Mbps in the downlink, but also for two to three times higher system capacity and a signicantly reduced delay for some services [15]. However, HSDPA only improves the downlink, and its architecture makes it suitable mainly for non real-time applications. The improvements seen by the user will be most obvious when downloading large les, while the main benet for operators may be the increased capacity. HSDPA is designed to t as easily as possible into the existing WCDMA system, but some changes have been done mainly at the physical layer and the MAC layer. For the latter, a new protocol named MAC-hs have been added.

2.4.1

HSDPA Concepts

Shared Channel Transmission HSDPA introduces a new transport channel called HS-DSCH (High Speed Downlink Shared Channel). The main benet of a shared channel, is that resources can be more eciently utilized, as available codes and power can be shared by many users. The sharing is primarily done in time, but there is also a possibility to use codes. The shared code resource available to the HS-DSCH consists of a total of 15 codes (SF 16 with 1/16 of the code resource reserved for control), but it is the decision of the operator how many will be used for HSDPA. The transmission on the HS-DSCH is done at a constant power level, thus eliminating the need for fast closed loop power control. This mechanism is replaced by fast link adaptation and channeldependent scheduling, as described below.

Higher-Order Modulation The modulation scheme for release 99 WCDMA is QPSK, which can carry two bits per symbol. The QPSK principle is to divide the RF carrier into in-phase and quadrature-phase components, which are orthogonal to each other. This is done in practice by observing that the sine and cosine functions are orthogonal, and thus may be transmitted together without loss of information. In HSDPA there is a possibility to use the 16QAM modulation scheme instead of QPSK, if the channel

12

conditions allow. As illustrated in Figure 2.2, 16QAM extends the idea behind QPSK further, and can carry four bits per symbol and hence double the bitrate compared to QPSK. On the other hand, the bit error probability (BER) increases, as the distance between the constellation points is less compared to QPSK. When channel conditions are good, it is therefore favorable to use 16QAM, while QPSK is better under more dicult channel conditions. HSDPA utilizes this by altering the modulation scheme according to current channel condition estimates.

Figure 2.2: Constellations for a) QPSK and b) 16QAM modulation schemes

Short TTI The Transmission Time Interval (TTI) is the time allocated for transmission to a particular user, before the scheduler moves on to the next user in turn. A long TTI allows more data to be sent in each interval, but on the other hand the time until the next transmission window will also be long. The TTI for the dedicated channels of WCDMA range from 10 ms and up, but for HSDPA this is reduced to 2 ms. This signicantly reduces the round-trip time, which is important when several retransmissions are needed before data can be decoded. Also, the short TTI helps keeping end-to-end transmission delays down.

Fast Link Adaptation The quality of the links in a cell varies rapidly for several reasons, one being that users move. This is exploited in HSDPA by adjusting the data rate and/or changing modulation scheme according to the instantaneous channel conditions. If the channel conditions are good, the 16QAM modulation can be used, together with a high code-rate, while with poor channel conditions, QPSK may be used instead and the code-rate is decreased. In this way, the channel is always utilized as eciently as possible. In order to perform the link adaptation, the Node B must have a means of estimating the instantaneous channel quality, or more specically the current Carrier-to-Interference Ratio (CIR). One way to obtain such information is to send a pilot signal to the UE in question on the CPiCH (Common Pilot Channel) and measure the power needed. The CIR of the CPiCH is then used as an estimate for the CIR of the HS-DSCH which will later be used for data transmission, and thus constitutes a measure of the current channel conditions. This method is used for HSDPA.

Channel-Dependent Scheduling The task of the scheduler is to decide which users data should be transmitted in a given TTI. In HSDPA, this decision may depend on the channel conditions, but also on the QoS class of dierent users and whether a user has data to transmit. The principle of channel-dependent scheduling is to schedule transmission for users who currently 13

have favorable channel conditions. This way, the overall throughput of the system is maximized. The scheduler thus works in close cooperation with the link adaptation function, as channel characteristics are needed for the scheduling decision. However, to only use the channel conditions as a base for the scheduling may lead to unfairness, as users with continuous bad channel conditions will experience a very low QoS. For that reason, one may combine the purely channel-dependent approach with some degree of long-term fairness. One possibility is the proportional fair scheduling principle, but the HSDPA specication allows for any other solution, as there has been no standardization of the scheduling algorithm.

Hybrid ARQ Hybrid Automatic Repeat Request (HARQ) is another important feature of HSDPA which enables fast and ecient retransmission of erroneous data blocks. The principle of ARQ schemes is that the receiver sends a positive or negative acknowledgment for each data block, and in the case of a negative acknowledgment a retransmission is made. HSDPA uses a Stop-And-Wait (SAW) type of ARQ, meaning that the transmitter awaits an acknowledgment for the previous data block before sending the next. The hybrid ARQ mechanism extends the ARQ concept by combining data from the original transmission and every retransmission in order to enable successful decoding. This way, data can be correctly received even if neither the original block nor the retransmission could be decoded individually. The concept is illustrated in Figure 2.3.

Figure 2.3: Hybrid ARQ principle

2.4.2

Code Multiplexing

As indicated, HSDPA uses time division multiplexing inside the code multiplexing, by assigning each user a time slot of 2 ms in which she can transmit. This works well as long as every user has enough data queued to make use of the entire TTI (the actual amount of bits that can be transmitted during the TTI depends on the channel conditions), but if a user only can utilize part of the TTI capacity, resources are wasted. For this reason, HSDPA includes a code multiplexing functionality, which enables code multiplexing of several users within the same TTI. Multiple users will then each be assigned a subset of the codes available for HSDPA, so that the full potential of the channel can be exploited. Some precaution must be taken, however, as code multiplexing will increase the control signaling overhead. Nevertheless, code multiplexing can be expected to increase the capacity of HSDPA for a service as PoC, which requires a relatively low bitrate.

14

Chapter 3

Push-to-Talk over Cellular

Push-to-Talk over Cellular (PoC) is a service which enables the mobile phone to act as a walkietalkie. The principle is that the user, with just a push of a button, gets instantly connected to one or more other users, and may speak to them. The PoC service allows only half-duplex communication, meaning that only one user may speak at a time. Users always push the push-to-talk button before speaking, and may speak only after an acoustic or visual signal is given by the PoC terminal. PoC sessions may be either one-to-one or one-to-many, where in the latter case several users are connected in a fashion similar to conference calls. The terminals hold a so called buddy list, in which the users store the names and addresses of other PoC users. When a user wishes to set up a PoC session, she simply selects an entry in the buddy list and pushes the push-to-talk button. PoC has several advantages over traditional walkie-talkie technologies, where two or more devices communicate directly with each other on frequencies other than those used by the cellular systems. The main advantage is that PoC has the same range as other services oered by the cellular systems, thus enabling PoC communication with users all over the world. Also, the PoC service will be integrated in ordinary mobile phones, which millions of people already carry with them every day. PoC may be used for dispatching in delivery rms etc., and in other cases where traditional walkietalkies are used today. The service can also be assumed to have a widespread private use, as it may be seen as an alternative to SMS and the various text-based instant messaging services. A Push-to-Talk service was rst made available in USA by the operator Nextel. Together with Motorola, Nextel built a completely proprietary network designed only for Push-to-Talk trac. The Nextel service is fast and reliable and has many American subscribers, but the system oers very limited interoperability with other systems [1]. In Europe, the approach to Push-to-Talk has instead been to provide the service over general radio access networks as GSM and UMTS, to benet from the existing infrastructure. PoC can be seen as an implementation of Push-to-Talk based on IP in GPRS and WCDMA networks. An industry consortium consisting of Ericsson, Motorola, Nokia, Siemens and Comneon is currently working on a specication which has been submitted to the Open Mobile Alliance (OMA) for standardization. The specication is now publicly available1 and is expected to be frozen in 2004. In the following sections, PoC as dened in these specications will be described [18, 19, 20].
1 At

OMA website http://www.openmobilealliance.org/

15

3.1

Architecture

PoC is based on IP and relies on the IP Multimedia Subsystem (IMS) specied by 3GPP. It is mandatory to support IP version 4 on all PoC interfaces, and optional to support IP version 6. The three protocols involved in PoC are Session Initiation Protocol (SIP), Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP), which all are standardized by IETF and described in [16] and [17]. The SIP protocol is used for nding PoC users and setting up sessions, while RTP and RTCP are used for the voice data transfer and the so called oor control.

3.1.1

IMS

The IMS (IP Multimedia Subsystem) is a subsystem of the UMTS core network, which handles IP-based multimedia services. PoC is one such service. The functionality for nding, registering and authenticating PoC users is handled in the IMS using SIP. The IMS routes SIP messages between UE:s and PoC servers, and to other IMS networks. It also terminates the SIP compression mechanism, handles authentication and authorization, and maintains the SIP session state. The SIP signaling will be further described in Section 3.2.

3.1.2

Group And List Management Function

The Group and List Management Function (GLMF) is used to manage contact lists, groups and access lists. These lists are stored by the GLMF and used by the PoC user to establish sessions and determine access. The contact list (buddy list) contains the addresses of all other PoC users a user may want to establish a session with, and predened groups of users who all may take part in the same PoC session. The access lists control who are allowed to establish a PoC session with a particular user, and who is allowed to view the users presence information. The presence information indicates whether a PoC user is available for starting a session, i.e. has the UE turned on, has coverage etc. The GLMF is only a functional entity, and may be distributed over multiple servers. The access list for presence information can for example be stored on a separate presence server.

3.1.3

PoC Server

The PoC servers handle the main PoC functionality. Two roles are dened for PoC servers, which are the Controlling PoC Server role and the Participating PoC Server role. The controlling PoC server has the overall control of a PoC session, but UE:s are not directly connected to this server, but rather to a participating PoC server handling a specic UE. Each UE is connected to a participating PoC server, and there may be several participating PoC servers for every session. The participating PoC servers are in turn connected to the controlling PoC server, of which there exists only one per session. This is true even if the UE:s belong to dierent networks. The controlling and participating PoC servers are, as the GLMF, only functional entities, and may in implementations be grouped together on a single physical server.

3.2

Session Control Signaling

The signaling for setting up, terminating and managing PoC sessions is carried in SIP messages. SIP is a text based application layer protocol, which in the PoC case is wrapped in UDP packets 16

for transmission over IP. SIP messages consist in principle of name/value pairs, much like e.g. the well-known HTTP and SMTP protocols. SIP signaling is needed in three phases of the PoC session, at setup, at termination and at session changes. The latter applies only to group sessions, where PoC users may join and leave the group throughout the duration of the session. The study of this thesis will for simplicity be limited to one-to-one sessions, and thus only the SIP signaling for such sessions need to be considered.

3.3

Floor Control

After a PoC session has been established, the controlling PoC server needs to decide which participant is allowed to talk. As PoC is designed to be a half-duplex service, only one participant may talk at a time. The process of controlling this is referred to as oor control and the signaling is carried in RTCP packets. Seven types of oor control messages are dened, but in a typical one-to-one PoC session, only a subset of these messages will be sent. Typically, when a talk-burst nishes and the user releases the push-to-talk button, a Floor Release message is sent in the uplink from the UE to the PoC server. The PoC server responds by sending a Floor Idle message in the downlink, and the other UE of the session may then send an uplink Floor Request message. The PoC server nally responds with a Floor Grant message to the new UE and a Floor Taken message to the other UE. The messages involved in this typical scenario are summarized in Table 3.1, which also indicates the length of each message including RTCP headers. As packets are wrapped in UDP and transmitted over IP, additional bits are added. Type Floor Release Floor Idle Floor Request Floor Grant Floor Taken Subtype bit-pattern 00100 00101 00000 00001 00010 Total bits 128 96 96 96 32(3 + nD ) Direction Uplink Uplink Uplink Downlink Downlink

Table 3.1: Floor control messages. The Floor Taken message, used to inform UE:s that the oor has been taken and who has taken it, will vary in length. When assuming 8-bit ASCII character encoding an approximate mean value may be calculated. From [19] it is seen that the Floor Taken message should include the canonical and common names of the user granted the oor, and the average lengths of these are assumed to be l CN AM E = 8 16 bits and lN AM E = 8 24 respectively. Including header bits, the mean number of 32-bit data sections in 1 the Floor Taken RTCP packet is nD = 32 (16 + lCN AM E + 16 + lN AM E ), resulting in a mean packet length of 32(3 + nD ) = 448 bits. This value will be used in the simulations.

3.4

Voice Data Transmission

The PoC voice data is sent using RTP packets, which in turn are placed in UDP packets and transmitted over IP. The voice codec used is the so called Adaptive Multi-Rate (AMR) codec, which is also used in the GSM and WCDMA systems for traditional voice calls. As the name implies, AMR supports a number of dierent bitrates, with varying voice quality. The parameters controlling the AMR mode are negotiated with SIP signaling during session setup, so that all UE:s participating in a PoC session are capable of encoding and decoding AMR voice data. 17

To ensure that there is always a mode supported by all UE:s, the AMR 5.15 mode is default and mandatory for PoC. This mode have an output bitrate of 5.15 kbps. The AMR codec output is organized in AMR frames, with a xed length of 20 ms. The frames are in turn subdivided into three parts, denoted A, B and C, with decreasing sensitivity to transmission errors. In the PoC case, however, all three parts are transmitted over the same channel, and this division is of no importance. The number of AMR frames placed in each RTP packet is a design parameter, ranging from one up to a maximum of 20 AMR frames per packet. With few frames per packet, delay will be low as packets are arriving frequently and little buering space is required. On the other hand, the protocol header overhead will be large. By just increasing the number of AMR frames per packet slightly, the overhead factor will decrease considerably. The AMR codec used for PoC is also required to support discontinuous transmission (DTX). DTX is used to reduce bandwidth usage when the user is temporarily quiet. The codec detects the silent periods, and sends short control messages every 160 ms, instead of continuously transmitting normal AMR frames with encoded silence. However, DTX will probably have limited impact on PoC performance, as PoC is a half-duplex service. It is likely that the user currently speaking will not be silent for long periods without releasing the push-to-talk button, and the silence of the listening PoC session participants will not be transmitted at all.

3.4.1

Bits Transmitted

To calculate the number of IP bits that need to be transmitted per second, it is noticed that with an AMR frame length of 20 ms the 5.15 kbps mode renders frames of length lAM R = 20103 5.15103 = 103 bits. Furthermore, the number of AMR frames per RTP packet is denoted nAM R . The PoC specication [19] states that the AMR frames should be placed in an RTP packet where the CSRC (contributing source) eld is not used in the header, and the payload is in so called octet aligned mode. The CSRC eld is unnecessary because there is always only one source, namely the PoC UE currently granted the oor. From [17] it can be seen that the RTP header then becomes 3 32 = 96 bits long. The RTP payload consists of an eight-bit payload header, and eight bits TOC information for each AMR frame. As the octet aligned mode is used, each AMR frame of length lAM R is padded with zeros so that the length becomes an integer multiple of 8 bits. The eective length of each AMR frame, when placed in the RTP payload, thus becomes lAM R,ef f = lAM R /8 8 bits where denotes the closest higher integer or the ceiling function. Putting everything together, the total length of the RTP packet is lRT P = 3 32 + 8 + (8 + lAM R,ef f )nAM R bits, which in the 5.15 kbps mode evaluates to lRT P = 104 + 112nAM R bits. The RTP packets are placed in UDP packets with 64 bits of header, and the UDP packets are in turn put into 160-bit header IPv4 packets (the optional IPv6 has a longer header). The n AM R AMR frames bundled together then render a total of lIP = 160 + 64 + 104 + 112nAM R = 328 + 112nAM R bits out from the IP layer. To illustrate the eect of varying the number of AMR frames per RTP packet, an overhead factor may be calculated for dierent values of n AM R . With nAM R = 2 the ratio of total bits to AMR frame bits is fOH = (328 + 112 2)/(103 2) = 2.7, while with nAM R = 8 the overhead factor decreases to fOH = (328 + 112 8)/(103 8) = 1.5. Apparently, the overhead factor can be multiplied with the AMR codec output bitrate, to retrieve the eective average bitrate out of the IP layer. Figure 3.1 illustrates the IP bitrate dependence on nAM R . It is suggested above that there is a trade-o between bandwidth and delay when setting the number of AMR frames per packet, nAM R . With few frames per packet, the header overhead becomes signicant but on the other hand the delays are kept low, while with a large nAM R the bandwidth eciency increases at the cost of larger delays. However, there is a third factor requiring attention when deciding a suitable value for nAM R in the case of PoC, namely the TTI length of the RAB:s used. As will be seen in Chapter 6, the parameter set of the channels (RAB:s) used for radio transmission controls how many bits can be transmitted per TTI, and in order to limit delays it is

18

20 18 16 14 Bitrate [kbit/s] 12 10 8 6 4 2 0

6 n
AMR

10

11

12

Figure 3.1: Average bitrate from IP layer as a function of number of AMR frames per packet n AM R . desirable to utilize the capacity of each TTI as much as possible. For this reason, some values of nAM R are more suitable than others for a given channel conguration, and this will be discussed further in Chapter 6.

19

Chapter 4

Trac Model
The PoC trac needs to modeled as accurately as possible in the simulations, and in this chapter the trac model will be described and motivated. A statistical approach will be used, based on the knowledge from Chapter 3, and the aim is to arrive at a realistic model for the voice transmission. The SIP and oor control signaling models will be relatively idealized. The reason is that the goal of the thesis is to investigate the performance of PoC voice transmission, and that including the control signaling would make the model unnecessarily complex and hard to handle.

4.1

Session Generation

The PoC trac is generated by a number of sessions, each corresponding to one PoC user. A oneto-one PoC call is thus in the trac model made up of two individual sessions. Furthermore, there is no direct connection between the two users of a PoC call, but a session is at every time instant either uplink or downlink and only implicitly paired with some other arbitrary session. The other session may be one in the same cell, but also in another cell or in a completely dierent network, geographically distant (in which case the session is not modeled). Sessions are generated randomly and last for an exponentially distributed amount of time T s . In order to keep the number of active sessions constant on the average, a value for the session arrival intensity is required. This is calculated according to Littles law [11], which states that, under general conditions, N = T where N is the average number of users in the system (oered load), is the arrival intensity and T = E[Ts ] is the mean time in the system for each user. The arrival intensity thus becomes N T

(4.1)

users per second, and this value will be used for the session generation. The session duration time Ts is chosen randomly immediately after the session is created. However, rather than setting Ts directly, the number of (uplink and downlink) talk-bursts ntb of the session is set. The session duration time is then calculated as Ts = ntb ti , where ti is the duration of i=1 talk-burst i. The mean session duration time T of (4.1) will then be 20

ntb

T = E[Ts ] = E
i=1

ti = E[ntb ]E[ti ]

For simplicity, it is assumed that a user always talks equally many times as she listens, so that n tb always is even. The talk-burst times ti are independent and drawn from an exponential distribution 1 with mean E[ti ] = mt , and the number of downlink talk-bursts 2 ntb are drawn from a geometric 1 distribution with mean 1 E[ntb ] = 2 mn . It can be shown that the total session duration time Ts then 2 also is exponentially distributed with mean mt mn . When the session duration time Ts has elapsed, and the session has no undelivered bits in the system, the session is terminated. This is done by setting a ag in the simulator indicating that the user no longer requires any service. However, a session may linger for some time after the user stopped transmitting, due to a WCDMA function used to save channel setup time if the user should start transmitting again after a short idle period. These down-switch timers are implemented in the simulator which results in a situation where the average number of total users in the system is higher than the desired oered load. But, as terminated sessions do not transmit, the average number of active users should correspond to the oered load N used in (4.1). When the simulation starts there are no users in the system, and a considerable amount of time will elapse before the system reaches the desired load. It is however not feasible to wait for the system to stabilize, due to the heavy computations needed, but the simulator oers another solution which will be used. For the rst tstart seconds of the simulation, sessions are generated uniformly over the interval [0, tstart ] so that the oered load at time tstart is the desired value N . After this, sessions are generated according to the normal arrival process. An empirical study indicate that setting tstart = T /2 gives the most rapid load stabilization.

4.2

Trac Generation

As PoC is a packet-switched service, trac is generated as packets which in this case are transmitted with xed intervals. The model handles four types of packets: ordinary voice data packets, oor control packets, SIP session setup packets and SIP session termination packets. The oor control packets are transmitted when a session switches from talking (uplink transmission) to listening (downlink transmission) and vice versa, while the SIP packets are transmitted when the session is initialized and terminated. The SIP model is very simplied, and present mainly for the following reasons. First, there is a xed channel setup delay in WCDMA, which is modeled by the simulator, and packets sent prior to the completion of channel setup will experience very large delays. However, the trac sent during this initial period will be SIP signaling, and voice data transmission will not be aected. By initially generating SIP type packets, this situation is catered for by the trac model. Second, the SIP signaling contributes to the total load oered to the system, which can be modeled by generating an approximate amount of data bits that not necessarily need to follow the exact SIP trac pattern; the average load will still be correct. In addition, the SIP type packets indicate the beginning and end of each session, which is useful for conrming the implementation of the trac model in the simulator. For voice packets, the inter-packet time is xed and deterministic and decided by the number of AMR frames per packet. The inter-packet time would with nAM R AMR frames per packet be 20nAM R ms, as one AMR frame is generated every 20 ms. An exception is made for new users, where the time until the rst packet is sent is chosen randomly from a uniform distribution over the interval [0, 20nAM R ] ms. The reason for randomizing the rst inter-packet time is that all new users otherwise would transmit simultaneously throughout the duration of the session, which is not realistic. The direction of the rst talk-burst is chosen randomly with equal probability for uplink and downlink. When the talk-burst time ti of talk-burst i has elapsed, the session switches from uplink to downlink 21

or vice versa depending on the current direction. When the switch is done, oor control packets are also sent according to the direction of the switch. The oor control packets are sent as described in Section 3.3, and only one packet per type. This means that oor control packets are sent at the same time as the rst voice data packets in the new direction, which is not very realistic. On the other hand, the oor control packets contribute mainly to the background load of the system, and have no direct impact on the voice packet delay of a particular session. The switch from uplink to downlink occurs regardless of whether all bits in the previous direction have been delivered or not, since there is no direct coupling between the trac model and the links that are used to transmit the generated bits. This simplication of the model facilitates the implementation, but also leads to somewhat unexpected eects when evaluating the results. As will be stated in Chapter 5, session admission control is disabled in the simulations, while the downlink code check still is active. If a situation occurs where the downlink code resource is exhausted, so that users are denied links, the trac model will still generate bits which are buered until a link can be set up. Thus, when the link nally is set up, transmission takes place continuously (i.e. not with 20nAM R ms intervals) until the buer is empty. This means that the trac model ceases to model PoC trac under such circumstances. This is not a major problem, since real systems with session admission control activated never experience this, but the phenomenon is important to keep in mind when evaluating the simulation results. All packets sent are time stamped and placed in a log. When bits are delivered for a session, the remaining number of undelivered bits of the oldest packet for that session is decreased. This process continues until all delivered bits have been assigned to an undelivered packet, and when a packet has been delivered completely, it is stamped with the time of delivery. This allows for following each packet through the system, and perform any type of post-processing after the simulation is nished. However, the method for determining when a packet is delivered assumes that all packets are delivered in-sequence, i.e. in exactly the same order as they were sent. This assumption is probably valid as the RLC if necessary will cater for the re-ordering, even if it is theoretically possible that packets fall out of sequence at the IP layer due to the use of UDP.

4.2.1

Bit Generation

Voice Data Bits In Section 3.4.1 an expression for the number of voice data bits necessary to transmit was derived. This depends on the number of AMR frames per packet nAM R which will be varied in the simulations. The DTX functionality will not be included in the model for reasons already stated.

Floor Control Bits The oor control packets are sent at the time when the speaker of the one-to-one PoC session switches, i.e. the previous talker starts listening and vice versa. To see how many bits need to be sent on these occasions, two cases must be considered: when a PoC user rst was talking and then switched to listening and when a PoC user rst was listening and switched to talking. In the case of an uplink (talking) PoC user switching to downlink (listening), the Floor Release message will be sent in the uplink, and the Floor Idle and Floor Taken messages will be received in the downlink. This renders a total of 128 uplink bits and 544 downlink bits. In the case of a downlink (listening) PoC user switching to uplink (talking), the Floor Request message will be sent in the uplink, and the Floor Idle and Floor Grant messages will be received in the downlink. This renders a total of 96 uplink bits and 192 downlink bits. The RTCP oor control packets are wrapped in UDP and transmitted over IP. From the IETF RFC specications of these protocols, it can be seen that (for IPv4) a total header overhead of 224 bits is added to each RTCP packet, assuming

22

that packets are not bundled together at the UDP and IP layers. This gives the nal value for the transmitted uplink and downlink bits for the two cases. It should be noted that, according to the PoC specication, the Floor Idle, Floor Release and Floor Request packets should be sent repeatedly until a Floor Grant or Floor Taken packet is received. The interval for sending these packets is proposed to follow the Fibonacci series, i.e. growing approximately exponentially. For simplicity this is not taken into account in the trac model, which may be acceptable if the initial oor control inter-sending times are larger than the round-trip times. In this case, the participating UE:s will receive the Floor Grant or Floor Taken messages before sending any repeated oor control messages.

SIP Bits The SIP packets are assumed to have a xed length of 500 bits and are generated at a rate of three packets per second. The initial SIP signaling period is assumed to last for one second, and the terminating SIP signaling period for 0.5 s. This means that 1500 SIP bits are generated at session setup, which can be considered rather low compared to real SIP message sizes. However, the SIP signaling is not an important part of the study, and the impact on the results can be assumed to be negligible.

4.3

Model Parameters

The behavior of the trac model is mainly inuenced by the following parameters. Mean number of talk-bursts mn . Mean talk-burst duration time mt . Oered load N . The number of AMR frames per packet nAM R . The parameters mn and mt will decide how long a PoC session lasts, but the session length has little impact on the delay of each voice packet of the session. Regardless of how long a session is, voice packets will be sent with certain xed intervals and are required to arrive within a specied period of time. Nevertheless, a short session duration time will require a longer simulation, as there must be time to smooth out short term variations. In this thesis, it is assumed that mn = 4 and mt = 7 s, which gives an average session length of T = mn mt = 28 s. From experience, a simulation time of approximately 200 seconds is then required. The oered load N will be varied in the simulations to nd the point of maximum system capacity. Also, nAM R will be varied to investigate its impact on performance. See Chapter 6 for details.

23

Chapter 5

Performance Measures
To evaluate the results of the simulations, it must be decided what performance measures to use, how these measures should be dened and what relevance they have to the overall performance of PoC over a specic channel. In this chapter, the performance measures used are described, as well as the methods for calculating them.

5.1

Latency

Latency is the delay through the system, or more precisely, the time a packet needs to travel from its origin to the destination. This time may include not only the actual transmission delay, but also processing delays at dierent points, e.g. in the UE and in the PoC servers. Furthermore, when dening delay, it must be made clear what is meant by origin and destination. When the network transmits queued data to a UE, the origin is in the network and the destination is the receiving UE. However, in the PoC case, data is originally produced in another UE, and hence the total delay should be measured from the time a packet leaves the sending UE until the time it arrives at the receiving UE. This combined uplink and downlink delay will in this thesis be referred to as the end-to-end delay. Packets are in the PoC case generated with xed intervals and are required to arrive with approximately the same intervals. Unfortunately, this will not always be the case in realistic networks, but rather there will be a certain delay variation, or jitter. The jitter may be caused by variations in processing time at dierent points, but the main reason is that data sometimes needs to be retransmitted due to transmission errors. Depending on the number of retransmissions, and how the scheduler handles them, this may result in signicantly increased delays for some packets. To handle this, the UE:s implement a play-out buer in which packets can be held for a short time before they are unpacked, decoded and played out to the PoC user. The size of the play-out buer depends on the delay distribution of the system, and in particular the delay variance. With a certain length of the play-out buer, there is a maximum variation in packet delay that can be tolerated before a packet is outdated, i.e. it is considered not useful at arrival. Late packets must be discarded, and the result is poor sound quality.

5.1.1

Delay Measure

As described in Chapter 4, each packet generated in the simulations will be stamped with its departure and arrival time, thus making it easy to calculate the delay. However, the delay is only measured in either the uplink or downlink direction, and a packet is not followed along its entire path from 24

sending UE to receiving UE. This means that delays can only be measured in uplink and downlink separately. The delay measure used in the study will be the delay distribution in uplink and downlink respectively, which can be seen as an estimate of the delay probability density function (PDF). The PDF:s are calculated for each session individually to illustrate dierences due to e.g. the scheduling, but also for the system in general to show the overall system performance in terms of delay. To obtain a distribution for the end-to-end delay, it would in principle be necessary to measure the end-to-end delay of every packet, but as the simulation is not set up this way, this is not possible. Instead, the method of convolving uplink and downlink distributions will be used, as described in Section 5.1.2. The per-session delay distributions are calculated separately for the uplink and downlink, but all packets sent in one direction of the same session will be included in the same distribution. This means that for a session of e.g. two uplink and two downlink talk-bursts, packets belonging to two dierent talk-bursts will be included in the same delay distribution. This way, it can easily be decided whether or not the delay was suciently low for the particular session, which is useful for determining if the user was satised (see Section 5.2). The delay PDF:s will of course be presented together with their mean and variance values, where the variance (or rather standard deviation) can be viewed as a measure of the delay jitter. However, the standard deviation value must be interpreted with care, as it at least when the system is moderately loaded may be somewhat misleading. It is for non-overloaded systems possible that the vast majority of packets arrive with the shortest possible delay, but that a few packets have signicantly higher delays. The reason for the large delay of a small amount of packets may be many retransmissions for users with poor instantaneous channel conditions. Thus, even with a large delay standard deviation, say 95% of the users may be perfectly satised. Even if ve percent non-satised users is not at all negligible, the conclusion is that the complete delay PDF:s best describe the delay situation. The delay distributions obtained illustrate only the transmission delay over the radio interface, not processing delays in various other nodes of the network. When estimating the total end-to-end delay, these must however be taken into account. Here, the processing delays will be considered xed, and thus it is possible to calculate an additional delay term which must be added to the transmission delay of each packet. It will be assumed1 that the following contribute to the constant delay term. Processing in the sending UE. The UE must collect voice samples, AMR encode them and packetize the AMR frames into RTP packets and so forth. With ve AMR frames per packet, this delay is 105 ms including 5 ms of processing. Also, a 10-ms general processing delay will be assumed. The total delay is hence assumed to be approximately 115 ms. Processing in the participating and controlling PoC servers. This delay is assumed to be approximately 25 ms. General network processing, e.g. in the core network and IMS Core. This delay is assumed to be approximately 25 ms. Processing in the receiving UE. The UE unpacks and decodes data, causing a processing delay which is assumed to be approximately 15 ms. To handle the delay jitter, the play-out buer holds the voice frames for a certain time before playing them. This oset is assumed to be 100 ms, rendering a total delay of 115 ms before the sound is actually played out to the user. In total, a 280-ms delay is assumed to be experienced by each packet, in addition to the actual transmission delay. In the PoC specication [20], it is recommended that the total end-to-end delay does not exceed 650 ms for a vast majority of the users, which means a delay tolerance of maximum 370 ms for the radio transmission. However, the 650-ms recommendation includes the possibility of providing PoC over GPRS, which can be expected to be slower than WCDMA. For this reason, the
1 The

assumed delay values come from experience from and studies of the PoC service.

25

radio transmission delay limit used in this thesis will be lowered to 200 ms. Note that this value should be seen as the accepted average delay, longer delays can be handled due to the play-out buer in the receiving UE. See Section 5.2.

5.1.2

End-To-End Delay Calculation

As indicated above, the end-to-end delay distribution will be estimated by convolving the delay distributions for uplink and downlink. This is because for two independent random variables X and Y with PDF:s fX (x) and fY (x) respectively, the sum Z = X + Y has PDF fZ (x) = fX (x) fY (x) i.e. the convolution of the two original PDF:s. This is valid both for continuous and discrete random variables. The above relation will be used to estimate the end-to-end delay distributions, but it must rst be decided what PDF:s are to be convolved. To simply convolve the total (all sessions combined) uplink and downlink distributions, would not be sucient to decide what sessions were satised according to Section 5.2, nor is it possible to convolve the uplink and downlink distributions of every specic PoC call, as there is no coupling between the sessions. The solution will instead be to look at all possible pairs of uplink and downlink sessions, and convolve the delay distributions of all these. For every pair, it may then be decided whether or not the two involved users would have been satised if they had actually talked to each other. The algorithm is shown below. For every session i i Estimate uplink PDF fU L (x) of session i For all sessions j = i j Estimate downlink PDF fDL (x) of session j j ij i Calculate end-to-end PDF estimation as fEE (x) = fU L (x) fDL (x) Decide whether this combination is satised according to Section 5.2 End End This approximation of the user satisfaction level is valid only if the delays of the two paired sessions are independent. If the sessions exist in dierent cell (far enough to not interfere), there will be no dependency, but for sessions in the same cell the situation is dierent. Such sessions will, if they exist simultaneously, interfere with each other, and thus there is no guarantee that the delays are independent. However, the vast majority of the pairs will have sessions in dierent cells, making the approximation acceptable. One may object that it would have been more benecial to actually model the coupling between sessions, as the end-to-end delay then directly could have been measured. There are, however, several problems with such an approach. First, there is nothing to say that users are coupled within the same cell or even the same network, but this is what would have been modeled with coupled sessions. Second, the estimation of the end-to-end delay characteristics will be based on much more data when using all possible combinations of sessions, rather than just looking at two specic sessions. This way, reliable information can be obtained even if the modeled system is relatively small, and the total number of simulated sessions is limited. Note also the following. Delay distributions for uplink and downlink sessions that existed in the same cell but at dierent times will be convolved. This will model sessions existing at the same time in dierent cells, as there will be no interference between the sessions. 26

 The approach used will also model sessions existing in dierent networks. When convolving distributions for sessions in dierent cells distant enough to not interfere, the result can be expected to be the same as if the sessions existed in dierent networks. This is of course valid only for networks of the same type, i.e. UTRAN/WCDMA. For a simulation including a total of N sessions, the number of combinations used will be N (N 1) as a session is not combined with itself. There is no need to convolve the downlink distribution of session i with the uplink distribution of session j, as this case will already be covered in the above algorithm.

5.1.3

Relevance

The delay characteristics of the PoC system is of very large relevance for the overall performance, since PoC is a semi-real-time service. It is crucial for the user perception of the system that delays are kept as low as possible. Nevertheless, the delay gures of the system must be interpreted in a meaningful way to be used as a performance measure, which may for example be to investigate the ratio of satised users. This will be done in this thesis, and is described in Section 5.2. Thus, the delay characteristics can be seen partly as an auxiliary measure for calculating the satised users ratio. One aim of this thesis is to determine whether it is the uplink or downlink that will be the limitation when providing PoC over HSDPA. The uplink and downlink delay characteristics are relevant for investigating this, as these will show in what direction the delays rst start to increase. If, after an increase in oered load, the mean delay of, say, the uplink also increases while the downlink mean delay is unchanged, there is reason to believe that the uplink is the bottle-neck.

5.2

Cell Capacity

Cell capacity is a measure of the maximum oered load per cell the system can handle before it is overloaded. The oered load is in this case dened as the number of users in the system, N , see Section 4.1. To be able to nd the cell capacity in terms of users per cell, a criterion for the system load limit must be dened. As PoC is a (semi) real-time service where in-time delivery of packets is important, the criterion will be based primarily on delay, and thus will cell capacity be a function of delay. However, the interference levels and code usage of the system will also be taken into account.

5.2.1

Satised User Criterion

The criterion for the load limit of the system, i.e. the point at which the system is so loaded that additional users will cause overload, is formulated in terms of a satised user ratio. Therefore, the notion of a satised user must rst be dened. The voice-carrying packets are, as already described, transmitted regularly with a certain interval decided by the number of AMR frames per packet. Also, they must be made available at the receiving end with approximately the same interval, even if a certain amount of variation is allowed. The variation in delay is handled by a play-out buer in the receiver, which holds incoming packets a short time before playing out the contents. It is the oset time, i.e. the time from when the rst packet was expected to arrive until it is actually played out, that decides exactly how much delay variation can be tolerated before the voice quality is decreased. The situation is depicted in Figure 5.1. If the rst voice packet is transmitted at time t0 , and the oset of the receiving play-out buer is po , the packet must have arrived at the destination at time t0 + d0 + po at the latest, where d0 is the 27

Figure 5.1: Example of packet delay with jitter. The rst three packets arrive in time, while packet 4 is not available in the play-out buer at the time it should be played out. allowed average end-to-end transmission delay. Consecutive packets are sent with xed intervals, and thus must also arrive no later than d0 + po after they were sent. This indicates that the maximum extra delay allowed, i.e. the maximum jitter, is equal to po . Satised users will be those whose probability plate of a late packet is at the most p0 , where a packet is late if its delay is more than po larger than the allowed average delay d0 . The probability of a late packet is hence calculated according to ni p,late i Np

pi = Pr[di > d0 + po ] late

i where di is the packet delay, ni p,late the number of late packets, and Np is the total number of packets for session i.

Finally, the load limit criterion is dened as follows. The system reaches is maximum load when the ratio of satised users Qs drops below a certain value q0 . Formalized mathematically, the load limit is reached when the inequality Ns q0 N

Qs =

holds. Here Ns is the number of users with pi p0 , and N is the total number of users. late A minor complication is, that end-to-end distributions are available only for every possible pair of sessions, as described in Section 5.1.1, and the number of satised users Ns can not be calculated directly. Instead, it will for every combination of uplink and downlink sessions be decided whether the satisfaction criterion is met or not, and the number of satised combinations will be divided by the total number of combinations. The load limit criterion then transforms into Ns q0 N

Qs Q s =

where Ns and N denote the number of satised combinations and the total number of combinations, respectively.

28

5.2.2

Interference And Code Usage

The delay-based satised user criterion is convenient, as it enables comparison of dierent means of providing the PoC service, in this case HSDPA versus conventional DCH:s. However, there are problems with using only this criterion as a measure of the cell capacity. When the system is heavily loaded in terms of interference, the delays will still be kept within limit as long as the system is stable. But if the instantaneous load increases slightly, the interference levels may become too high resulting in a situation where power control tries to increase power to innity and the system will collapse. Consequently, commercial systems are moderated (using admission control) so that the interference levels never become this dangerously high, and this fact should be taken into account when determining the cell capacity in a meaningful way. However, what interference levels are acceptable depends on the preferences of the system operator, and no absolute limit will be assumed here. Instead, the interference levels will simply be measured for every 10-ms radio frame (the average value over each frame), and presented together with the satised user ratio for the specic load. Interference will be monitored only in the uplink, as it can be shown that the downlink is limited rather by the available codes. The code usage in the downlink will also be monitored, so that it can be determined whether the cell capacity is code-limited. Interference is not a clearly dened quantity, but herein it is calculated as the total power received at each base station, taking into account the path-loss from the UE to the base station. Values for all base stations are then averaged to a single value for the entire system. The code usage is calculated as the sum of the inverses of the spreading factors of all channels in a cell (see Section 2.3.1), also averaged over all cells in the system. When the code usage approaches one, the system becomes code-limited.

5.2.3

Cell Capacity Measure

The cell capacity will be measured as the number of users per cell possible to oer to the system before Qs drops below the minimum allowed value q0 . The same measure will be used regardless of channel choice (HS-DSCH/DCH), and to make the comparison fair, the session admission control function will be turned o in the simulations. If session admission control would be active, no new users would be admitted at a certain load point, in principle regardless of whether they would have been satised or not. With session admission control disabled, on the other hand, new users will always be admitted, and at some point Qs will drop too low. This point can be used for setting the session admission threshold for a real system. The same argument can be applied to link admission control, and hence this will also be turned o, except for the downlink code usage check. This check must be enabled, since it is a mathematical fact that there is a limited number of available codes, and trying to use more codes does not make any sense. For the uplink, interference will limit the capacity prior to the codes, and hence there is no need to check the uplink code usage. To determine the level of satisfaction for a user, the upper delay limit d0 + po for a packet needs to be set. From Section 5.1.1 it follows that a maximum of 200 ms is assumed to be allowed for the end-to-end radio transmission, and that the oset of the play-out buer is assumed to be 100 ms. Hence, d0 = 200 ms and po = 100 ms, and the maximum allowed delay for a packet will be 300 ms. The maximum acceptable probability of a late packet will be assumed to be p0 = 0.01. Together with the satised user ratio, the interference and code usage levels are also presented. The former will show whether it is realistic to run the system at the load allowed by the satised user ratio criterion, while the latter will show whether the the system load limit was reached due to downlink code shortage. Note also the following. The delay limit d0 + po = 300 ms is set with HSDPA in mind, where the delays caused by the system architecture (see Section 6.1.4) are relatively low. The 16-kbps DCH used for comparison will have built-in delays considerably higher, and can be 29

expected to reach the load limit in terms of satised users sooner than HSDPA with the 300-ms tolerance. Thus, it may be interesting to increase the maximum allowed delay when providing PoC over this channel, if in turn the capacity in terms of interference and/or code usage is higher. This will be discussed further when presenting the simulation results in Chapter 7.

5.2.4

Relevance

Cell capacity is an important measure, as it indicates how many users the system is capable of handling. This is crucial to operators, since it determines how the networks should be dimensioned, and/or how the PoC service should be priced. Also, to base the cell capacity measure implicitly on user perception, increases its relevance. By using this approach, the cell capacity value hints about how users really experience the PoC service.

5.3

System Throughput

System throughput is a measure of how many bits the system is able to forward per time unit. In this study, the throughput will be measured at the IP layer, i.e. the amount of IP bits per second transmitted. Very straightforwardly, the system throughput is dened as R= nbits Tobs

where R is the throughput in bits/s, nbits is the total number of delivered bits, and Tobs is the observed time period is seconds. Thus, the throughput value will be an average over the duration of the whole simulation. Mean throughput is not dependent on packet delay, but is rather a measure of the amount of bits that passed through the system. In addition to total system throughput, the instantaneous user throughput for every packet will be calculated. In both cases, the uplink and downlink are kept separate, as there is no meaningful way of combining the throughput information for the two cases. The instantaneous user throughput is calculated for each packet, by dividing the packet length in bits by its total transmission time. This gives an indication of the actual capacity in terms of throughput, while the the mean throughput R rather is a measure of the system load. The instantaneous user throughput is dierent from the instantaneous throughput in the way that it indicates the throughput actually experienced by the user. Not only the link transmission time is included, but also any extra delay that may arise when the user is waiting to transmit.

5.3.1

Relevance

While the system throughput value may not indicate how well PoC performs as directly as the other two presented performance measures, it is still relevant. As the throughput is measured at the IP layer, the value reveals how well the channel is utilized. As an example, HSDPA is designed to allow a very high throughput, and it may show that some of the capacity is unused in the case of PoC. Also, if the throughput equals the maximum value for the channel, one might suspect that a broader channel would decrease delays.

30

Chapter 6

Simulation
The simulations made in this study were carried out using an HSDPA capable WCDMA simulator developed at Ericsson Research. The simulator is written in Matlab and covers all UTRAN functionality from radio link characteristics (e.g. shadow and multi-path fading) to the RLC and TCP protocols. An entire WCDMA system, consisting of a number of cells, is simulated and thus modeling of both inter-cell interference and soft/softer hand-over is included. Simulated is also the movement of individual users, as well as the variations in shadow and multi-path fading which occur as a result. The functionalities of each protocol layer of WCDMA is modeled, from the physical layer with channel quality estimation and power control, to RLC and TCP. Also, some models for trac generation are included, among which are standard DTX speech trac and best-eort TCP/IP trac produced by internet users. Any modeling of PoC trac is not present by default. The main simulation loop lasts for one radio frame (10 ms), and in turn contains an HSDPA TTI (2 ms) loop. Finally, the HSDPA TTI loop contains a slot-level loop, so that there are 15 slots for each radio frame. The slot level is the maximum time resolution of the simulator.

6.1
6.1.1

Simulator Model
Cell Layout and User Movement

The simulated cells are laid out in a uniform hexagonal pattern, and are organized in so called sites. Both omni and three-sector antennas can be modeled, where in the former case there is one Node B per cell and thus one cell per site. In the case of three-sector antennas, one Node B controls three cells which together constitute a site. Figure 6.1 illustrates the dierence. In the simulations, the three-sector site alternative will be used, as this is the most commonly used conguration. As the simulations require intensive computation, it is desirable to limit the number of cells modeled. However, with a small number of cells, a large ratio will be a the border of the system and experience an interference situation dierent from cells inside the cell pattern. To alleviate these problems at the boundaries, a wrapping technique is used where the cell pattern is wrapped around in a certain manner so that there are no borders. This way, cells at, say, the south border of the system will experience interference from the cells at the north border, as if were they neighbors, and a fairly large system can be modeled even if the actual number of cells is limited. The users of the system are placed out randomly (uniformly over the simulated area), and persist

31

Figure 6.1: Cell layouts modeled. a) Omni b) Three-sector. until their session has ended. They move according to a Gaussian random walk, with Rayleigh distributed initial velocity. The Gaussian random walk model can be seen as a state space model, with the position and velocity as states. The acceleration is driven by Gaussian white noise, and the velocity and position are calculated according to Newtons laws of motion. This is a common means of modeling user motion.

6.1.2

Radio Link Model

The radio links are characterized mainly by their so called path-gain, which is the inverse of the more conventional path-loss. The path-gain is considered to be made up of the following factors. Antenna Gain. The gain introduced by the antenna. Distance Attenuation (inverse). The radio signal is attenuated as the distance from the transmitter increases, and the attenuation is taken from precomputed look-up tables. Shadow Fading. Fading of the signal due to obstacles as buildings or hills etc. This factor is drawn from a log-normal distribution, so that it is normally distributed when measured in decibels. Multi-path Fading. The radio signal may be reected by buildings and other objects, so that multiple copies of the signal with varying delay reaches the receiver. The multi-path fading factor is taken from a precomputed map, which is indexed by the cumulative moved distance of the user. Dierent maps exist for dierent channel models, and supported are the ITU models Indoor A, Vehicular A and Pedestrian A, as well as the 3GPP models Typical Urban and Rural Area. The total path-gain is the product of the above factors (or sum when measured in decibels).

6.1.3

WCDMA Algorithms

The simulator implements all algorithms necessary in UTRAN as specied by 3GPP and described in Section 2.3.1. The most important of these are listed and commented below. Power Control. Inner loop power control adjusts the transmit power of all UE:s such that the CIR target set by the outer loop power control is maintained. All downlink power remaining after setting up the dedicated and common control channels (non-HSDPA channels), is by 32

default allocated to the HS-DSCH and HS-DCCH:s. However, a maximum allowed power usage for HSDPA is congurable, but this limitation will not be used in the simulations. Admission Control. For the reasons described in Chapter 5, admission control will only consider the downlink code usage. Nevertheless, interference will be logged to be able to interpret the results at high loads. HSDPA scheduling. This is an important part of the simulations, since the performance and suitability of the scheduler have signicant impact on delay. The scheduling policy used will be of proportional fair type, and schedule the user i with maximum DCRi (t) Ri (t) where DCRi (t) is the Data Channel Rate and Ri (t) is the average data rate of user i at time t. Hence, users with long periods of poor channel conditions (low data rate) will eventually be prioritized. Retransmission. The concept of parallel ARQ instances is included, and a default setting of six parallel instances is used. The hybrid ARQ protocol retransmits data a congurable number of times, and if the receiver still was incapable of decoding the data retransmission at the RLC layer is agged. For non-HSDPA channels, retransmission is handled only by the RLC. Channel Quality Estimation. Channel quality is estimated from the CIR of the CPiCH, and used for the scheduling decision and Modulation Code Scheme (MCS) choice. A measurement error consisting of independent noise and a time-varying bias is modeled.

6.1.4

Data Flow

Data transmission is modeled only by keeping track of the amount of data being transmitted per user, the actual bit patterns are not considered. In this section, it will be described how bits travel through the simulated system, and where the delays occur. At every 10-ms radio frame, the trac models used (may be several) generate an amount of bits for every user of the specic service. In the case of PoC, bits are generated every 20n AM R ms with nAM R AMR frames per RTP packet, but as users start transmitting at dierent times, it is likely that some users transmit in every radio frame. The bits from the trac model are stored in uplink and downlink transmission buers, and moved to the respective reception buers as soon as they are correctly received. The trac model function can then, every time it is invoked, investigate the amount of bits delivered for each user and calculate the delay.

Fixed Delays Regardless of channel type (DCH or HS-DSCH) there is always a xed congurable channel setup time. In the simulations, this setup time is assumed to be 400 ms, but since only initial SIP signaling is sent during this time, the delay of voice data will not be aected. The minimum delay experienced by a packet is primarily decided by the TTI length, which denes the length of the window in which data is transmitted. For HSDPA, the downlink TTI is only 2 ms, but as data passes the RLC layer, which operates on the radio frame time scale, the delay increases to at least 10 ms. For the uplink, the TTI is 20 ms for both considered RAB:s (16 resp. 64 kbps), but depending on the channel bitrate, the number of TTI:s necessary to transmit one packet varies. In addition to the above, a xed delay is always added to every packet to model the RLC processing delay. This delay is chosen according to knowledge and observations of RLC operation, and is not 33

Channel 16/HS-DSCH 64/HS-DSCH 16/16 dT T I 1 60 ms 20 ms 60 ms

Uplink RLC 50 ms 50 ms 50 ms

Total 110 ms 70 ms 110 ms

dT T I 10 ms 10 ms 60 ms

Downlink RLC Total 30 ms 40 ms 30 ms 40 ms 40 ms 100 ms

Table 6.1: Fixed delays modeled for the dierent channels.

symmetric for up- and downlink. For the HS-DSCH, the xed RLC delay is set to 3 radio frames (30 ms), while the corresponding value for the 16-kbps DCH downlink is 4 radio frames (40 ms). The uplink RLC delays are set to 5 radio frames (50 ms) for both the 16-kbps and the 64-kbps channels. Table 6.1 summarizes the xed delays experienced by a data packet for three cases: HSDPA with 16-kbps uplink, HSDPA with 64-kbps uplink and the 16-kbps dedicated channel in both downlink and uplink. The delays consider the case nAM R = 5 giving a voice data packet length of 888 bits. This means that three TTI:s are needed for the 16-kbps channel, but only one for the 64-kbps channel (see Section 6.2.2). Hence, the minimum uplink delay will be 3 20 + 50 = 110 ms and 1 20 + 50 = 70 ms for the two cases respectively, when including the RLC delay. Note however that the average bitrate for the 16-kbps channel is sucient for PoC.

Variable Delays The rst source of potential extra delay is the scheduler. Bits are queued until scheduled for transmission, and if a user has poor channel conditions and/or the system is heavily loaded, this delay may be signicant. However, there is no xed processing delay modeled for the scheduler, and at moderate load data is scheduled for transmission immediately. The next possible contribution to extra delay occurs in the hybrid ARQ function, when packets with negative acknowledgment are retransmitted. Retransmissions are scheduled prior to any other data, and thus the delay due to retransmissions may be as low as 2 ms, which is the HSDPA TTI. However, the time resolution of the trac generating function (in which arriving data packets are time stamped and logged) is one 10-ms radio frame, which means that hybrid ARQ retransmission on the border between two radio frames may be interpreted as a delay of 10 ms, while retransmission completely inside a radio frame gives the impression of zero extra delay. This is due to the architecture of the simulator, not the real WCDMA system, but when calculating the average delay, the eect is smoothed out. The above two delays are valid only for HSDPA, while the extra delay due to RLC retransmission is common to all channel types. The RLC protocol assures retransmission of negatively acknowledged packets, which may be a time consuming process for channels with relatively long TTI. Note that RLC retransmission is done only if RLC is in AM (Acknowledged Mode) and that for the HS-DSCH, RLC retransmission occurs only if the hybrid ARQ failed several times. For the simulations made in this thesis, AM is used and a maximum of ve hybrid ARQ retransmissions are allowed before RLC retransmission is done.
1 Delay

caused by the TTI length.

34

6.2
6.2.1

Simulation Setup
Simulations Made

The primary focus of this thesis is to investigate PoC performance when provided over HSDPA, but as already stated, a comparison is also made to a dedicated channel in order to highlight the dierences and potential advantages. As PoC is a relatively narrow-band service (8.88 kbps with 5.15 kbps codec rate and nAM R = 5), the bitrate for the DCH is chosen to be 16 kbps. The reason for not choosing an even lower bitrate is that the PoC trac is packetized, and it is desirable not to use too many TTI:s for every packet in order to keep transmission delays low. With n AM R = 5 each IP packet becomes 888 bits long, and can be transmitted in three TTI:s with one 320-bit RLC payload per TTI. The 320-bit RLC payload size is a conguration parameter, see Section 6.2.2. With a lower bitrate (or larger nAM R ), additional TTI:s would have been necessary, each increasing the delay with 20 ms in each direction, according to Table 6.1. The 16-kbps DCH is also used for the HSDPA uplink, to make the comparison fair. The rst releases of commercial HSDPA systems are expected to use a 64-kbps DCH for the uplink, and not include support for a 16-kbps alternative. Using the 64-kbps uplink for PoC is, however, probably a waste of resources, and there is reason to investigate whether the uplink will be the bottle neck as a relatively limited number of 64-kbps channels may be set up per cell. Nevertheless, the 64-kbps uplink is the only available choice if implementing PoC over HSDPA today, and for this reason simulations are made also for this case. Furthermore, the transmission delay is lower with the 64-kbps alternative, as only one TTI is needed to transmit each voice packet. This is because four 320-bit RLC payloads (1280 bits) are transmitted in each TTI. For both the HSDPA and the pure DCH cases, repeated simulations are made for dierent oered loads (users/cell) in order to nd the system load limit and values for the performance measures dened in Chapter 5. For the load sweep, the number of AMR frames per packet is set to n AM R = 5 and the number of code-multiplexed users for HSDPA is set to four. In order to investigate the impact on the results of these parameters, simulations are also made using other values. These simulations are made only at selected load points and for the following cases. HSDPA with four users code-multiplexed and nAM R = 1. In this case the 64-kbps uplink is used, as the average bitrate is 21.5 kbps, i.e. greater than 16 kbps (see Section 3.4). HSDPA with four users code-multiplexed, nAM R = 5 and the 64-kbps uplink. This is to isolate the eect of varying nAM R . Note nally, that the only trac present in the simulations is PoC trac, i.e. there is no mixture with other types of trac. In real networks this will obviously not be the case, but evaluating and comparing the PoC performance is greatly simplied using this approach. This is because it is, in a mixed trac situation, dicult to determine whether e.g. delays occur as a result of the PoC trac pattern, or because other trac is limiting the system capacity. Also, simulating only one service at a time, enables fair comparison of dierent services.

6.2.2

RAB Conguration

The general characteristics of the RAB:s used in the simulations are given below, while the conguration details are found in Appendix A.

35

16-kbps DCH The DCH used for the main simulations is of 16 kbps and uses a 20-ms TTI. This RAB is included in the 3GPP specication of tested RAB:s [21] but with a TTI of 40 ms, and hence the specication parameters are adjusted to compensate for the shorter TTI. The reason for changing the TTI is the semi-realtime characteristics of PoC; a 40 ms TTI would give relatively large delays in general and for retransmissions in particular. The interleaving gains are on the other hand larger, but low delay is considered more important for PoC. Non-compressed mode is used for both uplink and downlink, which means that all 15 slots are transmitted in every radio frame. Also, the acknowledged mode (AM) is used for RLC, which means that blocks transmitted in error will be retransmitted. Consequently, there will be no packet loss due to transmission errors (assuming block errors can always be detected).

HSDPA The 16-kbps uplink DCH used with HSDPA shares conguration with the above described DCH. The 64-kbps uplink alternative has a similar conguration, with the RLC in acknowledged mode, but obviously adjusted to provide the desired bitrate. The HSDPA downlink, the HS-DSCH, uses eight SF 16 codes (half the code tree) and will allow four code multiplexed users in each TTI. Associated with the HS-DSCH is also a 3.4-kbps signaling radio bearer (SRB) for each user, which is a DCH used for carrying control information.The SRB:s are modeled in the sense that they contribute to power consumption and interference, but no data transmission is modeled. The SRB:s have a standard conguration with 40-ms TTI.

36

Chapter 7

Results
In this chapter, the results will be presented and commented. The focus will be a qualitative analysis and interpretation, while the full details are given in tables in Appendix B. Main conclusions and comparisons are made in Chapter 8.

7.1
7.1.1

HSDPA
16-kbps Uplink

As indicated, HSDPA simulations were carried out for a number of cases, but a full load sweep was done only for the case 16-kbps uplink, 4 users code multiplexed and nAM R = 5, with oered loads ranging from 10 users/cell up to 140 users/cell.

Delay Figure 7.1 shows the mean delays in uplink and downlink, and the mean end-to-end delays. The mean is taken over all nished packets. As expected, the mean delays for light loads are close to 40 ms and 110 ms for the HS-DSCH and uplink DCH respectively, but in the region of 65 users/cell delays start growing. As can be seen, loads above 80 users/cell give average end-to-end delays of more than 300 ms, thus approaching the limit for what can be considered acceptable. It should be noted that delays increase at the same load point for both the downlink and uplink, and in fact follow each other with the only dierence being a multiplicative factor. One may have expected the delays to be uncorrelated, but the eect can be explained in the following way. When a communication channel is set up for a user, links are always set up in both uplink and downlink, as there is a need for bidirectional communication even if the uplink trac may be only control signaling. Hence, it is not possible to assign only a downlink or uplink to a user, and completely exclude the other direction. As is seen in Figure 7.5, the delay increase is caused by limited code 37

resources, meaning that some users eventually are denied downlinks. Consequently, no uplink is setup either which explains the correlation between the downlink and uplink delay curves. When interpreting the delay curves, it should be noted that the steep increase above 65 users/cell is caused by the fact that sessions that were denied links are included in the mean. Such sessions will, due to the architecture of the trac model and the absence of session admission control, generate packets regardless of whether a link is present or not, and experience very large delays if a long time elapses before a link is granted.
500 450 400 350 Mean delay [ms] 300 250 200 150 100 50 0 10 Endtoend HSDSCH Uplink DCH

20

30

40

50 Load [users/cell]

60

70

80

90

Figure 7.1: Mean delay for HSDPA with 16-kbps uplink. Another view of the delay characteristics is shown in Figure 7.2, displaying the delay distributions at a load of 65 users/cell. Packets belonging to all sessions are included. As can be seen, a vast majority of the packets experience a delay lower than the 300 ms limit, but there is also a considerable amount experiencing larger delays. This is due to the code shortage, and contributes to the non-satised user ratio of 5.2% which is seen in Figure 7.3.
1 Uplink (16kbps DCH) Ratio 0.5

0 1

50

100

150

200

250 ms

300

350

400

450

500

Downlink (HSDSCH) Ratio 0.5

0 1

50

100

150

200

250 ms

300

350

400

450

500

Endtoend Ratio 0.5

50

100

150

200

250 ms

300

350

400

450

500

Figure 7.2: Delay distributions for all sessions at 65 users/cell. Dotted lines indicate mean delay.

38

User Satisfaction The user satisfaction level, according to the denition in Chapter 5, is shown in Figure 7.3. The ratio of satised users is very close to one for moderate loads, and starts dropping approximately at the same point where the delays start growing. This is what can be expected, since the satised user criterion is based on delay. Depending on what minimum level of satised users can be accepted, it is seen that the capacity falls in the region of 60 to 68 users/cell. At a load of 90 users/cell, the satised user ratio has dropped almost to zero. This is because the mean end-to-end delay at this point by far exceeds 300 ms, which is the point at which packets are considered too late. The 90-users/cell load case is not included in the graph for clarity reasons.
1.05

0.95 Satisfied User Ratio

0.9

0.85

0.8

0.75

0.7 10

20

30

40

50 Load [users/cell]

60

70

80

90

Figure 7.3: Satised user ratio for HSDPA with 16-kbps uplink. To illustrate the dierence between satised and non-satised users, delay distributions for the two cases are plotted in Figure 7.4. The dierence is rather limited, but the delay spread is clearly larger for the non-satised users. Furthermore, the mean delays are considerably higher for these users, indicating that some packets experience very high delays. For clarity, the plots are cut at 500 ms, but for the non-satised users there exists packets with far higher delays.
Nonsatisfied users (endtoend) 1 1 Satisfied users (endtoend)

0.8

0.8

0.6 Ratio Ratio 0.4

0.6

0.4

0.2

0.2

100

200 ms

300

400

500

100

200 ms

300

400

500

Figure 7.4: Delay distributions for all non-satised and all satised users at 65 users/cell. Dotted lines indicate mean delay. 39

Code Usage and Interference In order to see the reasons for the delay increases above 65 users/cell, the downlink code usage and uplink interference have been logged and are shown in Figure 7.5. The mean and maximum values that are shown are calculated over all 36 simulated cells, meaning than when the mean code usage reaches one, the code resource is practically exhausted in all cells. Apparently, this happens at approximately 80 users/cell, which explains the increase in delay at this load point. When no more codes are available, new links cannot be set up, and it may be argued that delays should increase to innity1 . This is the case for sessions that were denied a link, but as it is the average delays that are plotted in Figure 7.1, i.e. including both sessions granted links and sessions denied links, the curve is smooth. The reason for the shortage of codes is the SRB:s carried over associated DCH:s of spreading factor 256 that are set up in the downlink for every HSDPA user. The HS-DSCH is assigned half the code tree (8/16), ve SF 128 channels are reserved for common control channels, and four SF 128 channels need to be set up to control the HS-DSCH code multiplexing. Thus, 5+4 8 + = 0.430 16 128

cSRB = 1

is the ratio of the code tree made available to the associated DCH:s. When assuming 35% of the users in soft hand-over, this is sucient for nSRB = 256 cSRB /1.35 82 channels and hence approximately 82 users/cell, a result which apparently is conrmed by the simulations. The uplink interference imposes a somewhat softer limitation than the code usage, but on the other hand delays for all sessions will start growing as interference increases. There is however no sharp edge, but delays will rather grow continuously. In this case the interference levels are relatively low (c.f. Figure 7.9 showing the interference for the pure 64-kbps uplink case) and the interpretation must be that delays are caused mainly by the downlink code limitation. Interference continues to grow after the point of code resource exhaustion, while the expected behavior may be that the curve should stabilize because no more links are set up. The eect can be explained by the trac model limitation highlighted in Chapter 4, i.e. that bits are generated even if the session was not granted a link, and buered until a link actually could be set up. Thus, transmission will be made continuously for these sessions until the stored buer if empty, utilizing the full bitrate capacity of the link instead of the average 8.88 kbps used by sessions that did not have to wait. At high enough loads, nearly all sessions will have to wait for a link to become free and nearly all links will be utilized fully, which explains an increase in uplink interference even if the number of active links is constant. Note that this eect is a consequence of the trac model and the deactivated session admission control; the interference gures above the code shortage point have no relevance to real systems.
1 Delays

can in practice not be longer than the simulation time 200 s.

40

Downlink code usage for HSDPA 1.1 1 Code usage 0.9 0.8 0.7 0.6 Mean Max

20

40

60 80 Load [users/cell]

100

120

140

Uplink interference for HSDPA (16kbps uplink) 12 10 Interference [dB] 8 6 4 2 0 0 20 40 60 80 Load [users/cell] 100 120 140 Mean Max

Figure 7.5: Downlink code usage and uplink interference for HSDPA.

Throughput The mean throughput per cell and mean instantaneous user throughput are depicted in Figure 7.6. It is seen that the HS-DSCH is capable of providing an instantaneous user throughput considerably higher than the uplink DCH, but the situation changes drastically after the downlink code limit has been reached. Instantaneous user throughput is calculated only for delivered packets and so one may think that it would remain unchanged even when the code resource is exhausted. However, the session admission control was disabled in the simulations, and thus sessions will be admitted even if no link can be set up. This means that some sessions have to wait for an active session to end before transmission can begin, and the packets generated prior to link setup will experience very large delays. In real systems such situations are prohibited by the use of session admission thresholds, but it is, as already explained, helpful to exclude this in the simulations to see what factor is limiting. The mean throughput per cell indicates the actual capacity of the channels, and continues to grow up to a load of 120 users/cell. Even if the HS-DSCH is limited by code, the capacity in bits per second for links that could be setup is not reached. Rather, it is the uplink that limits in the case of mean throughput, which can be seen in the interference plot of Figure 7.5. At 140 users/cell the uplink interference has peaks above 10 dB, certainly causing excessive RLC retransmissions.

41

Mean Throughput [kbps/cell]

500 400 300 200 100 0 Downlink Uplink

20

40

60 80 Load [users/cell]

100

120

140

Mean Inst User Throughput [kbps]

25 20 15 10 5 0 Downlink Uplink

20

40

60 80 Load [users/cell]

100

120

140

Figure 7.6: Mean throughput per cell and mean instantaneous user throughput for HSDPA.

7.1.2

64-kbps Uplink

For the 64-kbps uplink case, only loads from 50 to 85 users/cell were considered, but the results are sucient to isolate the dierences compared to the 16-kbps uplink. All parameters except the uplink conguration were unchanged, i.e. 64-kbps uplink, 4 users code multiplexed and nAM R = 5.

Delay and User Satisfaction The mean delays for uplink and downlink, and the mean end-to-end delays are shown in Figure 7.7. As can be seen, the graphs are practically identical to the ones of Figure 7.1, except that the mean uplink delays are approximately 70 ms rather than 110 ms, as expected. This suggests that the change of uplink impacts performance only by decreasing delays, while the capacity remains unchanged.

42

500 450 400 350 Mean delay [ms] 300 250 200 150 100 50 0 50 Endtoend HSDSCH Uplink DCH

55

60

65 70 Load [users/cell]

75

80

85

Figure 7.7: Mean delay for HSDPA with 64-kbps uplink. The satised user ratio is shown in Figure 7.8, indicating a capacity of approximately 65 users/cell with 95% satised users. This is practically identical to the 16-kbps uplink result.
1.05

0.95 Satisfied User Ratio

0.9

0.85

0.8

0.75

0.7 50

55

60

65 70 Load [users/cell]

75

80

85

Figure 7.8: Satised user ratio for HSDPA with 64-kbps uplink.

Code Usage and Interference The downlink code usage plot shown in Figure 7.9 is, not surprising, identical to the plot in Figure 7.5. This is because the downlink (HS-DSCH) is unchanged and hence also the code usage. The uplink interference levels are, on the other hand, considerably higher than in the 16-kbps uplink case, which illustrates the main dierence when using the 64-kbps uplink. The interference reaches up to 8 dB already at 60 users/cell, which should be compared to approximately 3 dB for the 16-kbps case. At 85 users/cell the interference levels are unreasonably high and it would not be realistic to run a system under these conditions. 43

The reason that the high uplink interference does not noticeably impact the delay curves, is likely to be that the capacity already is limited by the downlink code shortage. Even if links that are setup experience extra delay due to the interference, this is shadowed by the large delays occurring because of the limited code resource. However, if the downlink code usage could be decreased, the uplink interference would become signicant and thus there is reason to pay attention even if the impact in this specic case is limited.
Downlink code usage for HSDPA 1.02 1 Code usage 0.98 0.96 0.94 0.92 0.9 60 65 70 Load [users/cell] Uplink interference for HSDPA (64kbps uplink) 35 30 Interference [dB] 25 20 15 10 5 60 65 70 Load [users/cell] 75 80 85 Mean Max 75 80 Mean Max

85

Figure 7.9: Downlink code usage and uplink (64 kbps) interference for HSDPA.

Throughput The mean throughput per cell and mean instantaneous user throughput are depicted in Figure 7.10. Similar to in Figure 7.6, the mean throughput per cell is equal for both uplink and downlink, but is saturated already at 85 users/cell compared to 140 users/cell in the 16-kbps uplink case. The reason is the high uplink interference, which limits the capacity in terms of throughput. The mean instantaneous user throughput for the HS-DSCH downlink is unchanged compared to the 16-kbps uplink case, while the instantaneous user throughput in the uplink has increased considerably. This is obviously due to the higher uplink bitrate. When the load increases, the impact of both the downlink code limitation and the uplink interference can be seen as a decrease in instantaneous user throughput.

44

Mean Throughput [kbps/cell]

350 Downlink Uplink 300

250

200 50

55

60

65 70 Load [users/cell]

75

80

85

Mean Inst User Throughput [kbps]

20 18 16 14 12 10 50 Downlink Uplink

55

60

65 70 Load [users/cell]

75

80

85

Figure 7.10: Mean throughput per cell and mean instantaneous user throughput for HSDPA with 64-kbps uplink.

7.1.3

Varying Number of AMR Frames

The eect of using only one AMR frame per packet instead of the usual ve, was studied for the loads 30 to 70 users/cell. To handle the higher bitrate, the 64-kbps uplink was used, resulting in the following set of main parameters. 64-kbps uplink, 4 users code multiplexed and nAM R = 1.

Delay and User Satisfaction Mean delays for uplink and downlink, and mean end-to-end delays are shown in Figure 7.11. Apparently, the higher bitrate rendered for the case nAM R = 1 causes problems already at a load of 30 to 40 users/cell. Furthermore, the delay at moderate load is higher than for the comparable case nAM R = 5 and 64-kbps uplink shown in Figure 7.7. Consequently, the expected gain of using nAM R = 1 to decrease the delays is absent. The uplink and downlink delay curves are not correlated, which is reasonable since there is no code limitation triggering the link admission control. While the uplink delay characteristics can be explained from the interference plot in Figure 7.13, the cause of the HS-DSCH delay increase is less obvious. The probable reason is the relatively high bitrate from many simultaneous users, who each generate 440 bits every 20 ms. With four users code multiplexed and 30 users/cell, on average 30/4 = 7.5 HS-DSCH TTI:s are necessary for the transmission, rendering a maximum queuing time of 7.5 2 = 15 ms. Taking into account also the random variations in session starting time, it is not unreasonable to believe that some extra delay will occur in the scheduler. At 40 users/cell, on average

45

10 HS-DSCH TTI:s corresponding to 20 ms queuing time may be experienced, which explains the further delay increase that is seen at this load.
500 450 400 350 Mean delay [ms] 300 250 200 150 100 50 0 30 Endtoend HSDSCH Uplink DCH

35

40

45

50 Load [users/cell]

55

60

65

70

Figure 7.11: Mean delay for HSDPA with 64-kbps uplink and namr = 1. The large delays impact also the satised user ratio plot, which is shown in Figure 7.12. As can be seen, no more than approximately 30 users/cell can be handled before the satised user ratio drops too low. Even at this relatively light load, only 94% of the users are satised.
1.05

0.95 Satisfied User Ratio

0.9

0.85

0.8

0.75

0.7 30

35

40

45

50 Load [users/cell]

55

60

65

70

Figure 7.12: Satised user ratio for HSDPA with 64-kbps uplink and namr = 1.

Code Usage and Interference The reason for the delay situation is seen in Figure 7.13, which shows the downlink code usage and uplink interference levels. Close to a load of 50 users/cell, the uplink interference grows unreasonably large, and the interpretation must be that this is the maximum uplink capacity for the required 46

bitrate. That the downlink is limiting already at 40 users/cell however makes this uplink limitation less important.
Downlink code usage for HSDPA 1.1 Mean Max 1 Code usage

0.9

0.8

0.7 30

35

40

45

50 Load [users/cell]

55

60

65

70

Uplink interference for HSDPA (64kbps uplink) 40 Mean Max Interference [dB] 30

20

10

0 30

35

40

45

50 Load [users/cell]

55

60

65

70

Figure 7.13: Downlink code usage and uplink interference for HSDPA with 64-kbps uplink and namr = 1.

Throughput The throughput plots shown in Figure 7.14 further conrm that the uplink capacity is reached at 50 users/cell. It is seen that the mean throughput per cell peaks at this load point, and that also the mean instantaneous user throughput starts decreasing here.
Mean Throughput [kbps/cell] 500 450 400 350 300 250 30 Downlink Uplink

35

40

45

50 Load [users/cell]

55

60

65

70

Mean Inst User Throughput [kbps]

10 8 6 4 2 0 30 Downlink Uplink

35

40

45

50 Load [users/cell]

55

60

65

70

Figure 7.14: Mean throughput per cell and mean instantaneous user throughput for HSDPA with 64-kbps uplink and namr = 1. 47

7.2

DCH

For comparison, simulations were also carried out for the pure DCH case, i.e. with a 16-kbps DCH link in both uplink and downlink. A load sweep ranging from 10 to 80 users/cell was made, with main parameters as below. 16-kbps DCH uplink, 16-kbps DCH downlink and nAM R = 5.

Delay The mean delays for uplink and downlink, and the mean end-to-end delays are shown in Figure 7.15. The delays are constant up to a load of approximately 75 users/cell, and then rapidly grows. This indicates a somewhat higher capacity than in the HSDPA case, where delays started increasing in the region of 65 users/cell. On the other hand, the delays at moderate loads are higher than for HSDPA, due to the architecture of the WCDMA dedicated channels. Note also that delays are truly constant before approaching the overload point, while the HSDPA delay curve in Figure 7.1 have a slight positive slope. This illustrates the WCDMA functionality to maintain QoS for admitted dedicated channels, meaning that if a link actually is set up, the quality is equally good regardless of number of other links present. In the HS-DSCH case, on the other hand, delays will slowly increase with higher loads, due to the scheduler.
500 450 400 350 Mean delay [ms] 300 250 200 150 100 50 0 10 Endtoend Downlink Uplink

20

30

40 50 Load [users/cell]

60

70

80

Figure 7.15: Mean delay for 16-kbps DCH uplink and downlink. Figure 7.16 shows the delay density at 50 users/cell with packets for all sessions included. As can be seen, the delay spread is limited, with only a small ratio of packets experiencing delays other than the minimum of 110/100 ms for uplink/downlink. The cause for the delays for some packets is likely to be RLC retransmissions, which may increase delays by several hundreds of milliseconds in some cases. Also, when a negative acknowledgment is to be transmitted after a decoding failure, user data may need to be queued at the RLC layer in order to quickly serve the retransmission request.

48

1 Uplink (16kbps DCH) Ratio 0.5

0 1

50

100

150

200

250 ms

300

350

400

450

500

Downlink (16kbps DCH) Ratio 0.5

0 1

50

100

150

200

250 ms

300

350

400

450

500

Endtoend Ratio 0.5

50

100

150

200

250 ms

300

350

400

450

500

Figure 7.16: Delay distributions for all sessions at 50 users/cell. Dotted lines indicate mean delay.

User Satisfaction Shown in Figure 7.17 is the satised user ratio, and as can be seen approximately 94% of the users are satised with the delay limit set to 300 ms, i.e. the same as was used in the HSDPA case depicted in Figure 7.3. A further comparison of the two cases shows that the ratio of satised users starts dropping around 60 users/cell for both HSDPA and pure DCH, which may be a bit surprising regarding that delays increase at a higher load in the DCH case. However, the DCH delays are from the beginning closer to the 300-ms limit, and thus only a small increase is necessary for users to become non-satised. Neither 99% nor 95% satised users can be reached with a delay limit of 300 ms, while the capacity when accepting only 90% satised users is approximately 73 users/cell. This is 7% more than in the HSDPA case, but on the other hand 90% satised users is probably too low. However, as stated below, increasing the delay limit to 350 ms dramatically changes the situation, indicating that capacity in terms of satised users possibly is higher for DCH than for HSDPA if the delay requirements can be slightly relaxed.

49

1.05

0.95 Satisfied User Ratio

0.9

0.85

0.8

0.75

0.7 10

20

30

40 50 Load [users/cell]

60

70

80

Figure 7.17: Satised user ratio for 16-kbps DCH uplink and downlink. The fact that the 300-ms delay limit is so close to the smallest possible delay of 210 ms (see Section 6.1.4), makes the comparison of capacity in terms of user satisfaction somewhat unfair. If slightly larger delays can be tolerated, the satised user ratio can be expected to reach the same levels as for HSDPA at light loads, i.e. close to 100%. Renewed calculations show that relaxing the delay limit to 350 ms is sucient to reach the same level of user satisfaction as for HSDPA, i.e. above 99%. The calculation with the new 350-ms limit was carried out for a load of 50 users/cell and resulted in 99.7% satised users. For reasons already given, the result can be expected to be the same for other loads prior to the overload point.

Code Usage and Interference Figure 7.18 shows the downlink code usage and uplink interference, and apparently the code resource is exhausted at approximately 80 users/cell. The delay plot of Figure 7.15 indicates a situation of complete overload at the same point, and the delay increase is quicker than in the HS-DSCH case. One explanation for the dierence may be that every new user in the DCH case requires a SF 128 downlink, while only a SF 256 SRB downlink is required in the HS-DSCH case. Hence the probability of being able to set up a new link when the code resource is almost exhausted, is larger in the HS-DSCH case than in the DCH case. The uplink interference at 80 users/cell peaks at 12 dB, which is high compared to the value plotted in Figure 7.5. However, only one of the 200,000 measurements of the interference has this high value, suggesting that random variations may be part of the reason. Furthermore, the code resource is not fully utilized at 80 users/cell (which it is in the HSDPA case), still allowing for new uplinks to be set up at this load. This, in conjunction with the fact that some cells probably already suer from code shortage, may explain the increase also in mean uplink interference. The cells in which the code resource is exhausted will contribute to the interference increase for the same reason as in the HSDPA case, i.e. that sessions denied links will buer bits and transmit using full capacity when a link is granted.

50

Downlink code usage 1 Code usage 0.8 0.6 0.4 0.2 0 10 20 30 40 50 Load [users/cell] Uplink interference 12 10 Interference [dB] 8 6 4 2 0 10 20 30 40 50 Load [users/cell] 60 70 80 Mean Max 60 70 80 Mean Max

Figure 7.18: Downlink code usage and uplink interference for 16-kbps DCH.

Throughput The mean throughput per cell, and the mean instantaneous user throughput are shown in Figure 7.19. For the same reasons as for the delay, the instantaneous user throughput is relatively constant up to the overload point at 80 users/cell, and then rapidly drops. The instantaneous user throughput is somewhat lower for the uplink than for the downlink, and the probable reason is that retransmissions are more common in the uplink due to higher interference levels. This can be seen also from the delay distribution of Figure 7.16, where high-delay packets are more frequent in the uplink. The mean throughput per cell is saturated also at 80 users/cell, due to the code shortage and high uplink interference at this point. The curves are aligned for the reason already described, i.e. the need to set up both uplink and downlink.

51

Mean Throughput [kbps/cell]

400 Downlink Uplink 300 200 100 0 10

20

30

40 50 Load [users/cell]

60

70

80

Mean Inst User Throughput [kbps]

9 8 7 6 Downlink Uplink 5 10 20 30 40 50 Load [users/cell] 60 70 80

Figure 7.19: Mean throughput per cell and mean instantaneous user throughput for 16-kbps DCH uplink and downlink.

Capacity To enable comparison with the HSDPA case, the cell capacity in terms of satised users is shown in Figure 7.20. It is seen that neither 99% nor 95% satised users can be reached with a delay limit of 300 ms, and that the capacity when accepting only 90% satised users is approximately 73 users/cell. This is 7% more than in the HSDPA case, but on the other hand 90% satised users is probably too low. However, it was stated above that increasing the delay limit to 350 ms dramatically changes the situation, indicating that capacity in terms of satised users possibly is higher for DCH than for HSDPA provided that the delay requirements can be slightly relaxed. This standpoint is supported also when looking at the 94% percent satised user ratio. At this level, 65 users/cell can be handled, which is equally many as for HSDPA with 95% of the users satised.
1.05

0.95 Satisfied User Ratio

0.9

0.85

0.8

0.75

0.7 10

20

30

40 50 Load [users/cell]

60

70

80

Figure 7.20: Cell capacity for 16-kbps DCH uplink and downlink in terms of satised user ratio.

52

Chapter 8

Conclusions
The main issue addressed in this study is how well the PoC service can be provided over HSDPA, and it can be concluded that with the performance measures used, approximately 65 users/cell can be served with acceptable quality. The mean delay is in the region of 40 ms for the HS-DSCH downlink and 150 ms for the end-to-end transmission with the 16-kbps uplink included. The main problem with providing PoC over HSDPA is, with the parameter set used in this study, the downlink code shortage. It may have been expected that the uplink would be the limiting factor rather than the high-bitrate HS-DSCH, but due to the large amount of users, the downlink code resource is exhausted by the many associated SRB:s. In the simulations, half the code tree was assigned to the HS-DSCH, but there is of course nothing that prevents this ratio from being decreased. In the case of PoC, it is probably benecial to use a smaller ratio of the code tree for the HS-DSCH, to free code resources to the SRB:s. This would decrease the capacity in terms of bitrate, but impact the PoC performance in a positive way since the full HS-DSCH capacity is not utilized anyway. When using the 64-kbps uplink, performance is still limited by the downlink code shortage, but at approximately the same load point uplink interference starts growing dangerously high. Thus, assigning fewer codes to the HS-DSCH will have no eect here, as the uplink then will limit instead. The 16-kbps uplink, on the other hand, does not suer from interference problems at such low loads, but can be used up to at least 100 users/cell. The conclusion must be that the 16-kbps uplink is the most suitable choice for PoC, and that there are no technical arguments for using the 64-kbps alternative. As long as the only trac present is PoC, and there is no trac carried on channels other than HSDPA, the 64-kbps uplink can be used, but when other trac exists also, the uplink interference will be a problem much earlier than the downlink code usage for HSDPA. Hence, the 64-kbps uplink is not a reasonable alternative even if the results indicate otherwise in the isolated PoC case. The requirement on the uplink is, conclusively, that the bitrate should be as low as possible for PoC trac, so that interference is kept to a minimum. Bitrate is not a major limitation for PoC, so the aim should be to maximize the number of users possible to serve. Thus, the 16-kbps DCH used in this study is a suitable choice. The bitrate should however probably not be chosen any lower, as the packetized PoC trac may require bitrates higher than the average 8.88 kbps at some time instants. With too low bitrate margins, there is a risk for increased delays when many packets arrive simultaneously. Except the code limitation problem for HSDPA, the results imply a limitation in the scheduler when many users generate packets with short intervals. This is seen from the simulations with n AM R = 1, where the HS-DSCH delays reach 120 ms already at 40 users/cell. The conclusion must be that

53

HSDPA is not as suitable for serving a large number of users with short inter-packet times, as for serving a smaller number of users generating large packets with relatively long intervals. The comparison of HSDPA to a DCH downlink, showed that the capacity is approximately equal for the two cases, while delays are somewhat higher for DCH due to the WCDMA architecture. Hence, it can be considered a matter of preferences whether to use HSDPA or DCH for the PoC service. As capacity is limited by the downlink code resource also in the case of DCH, it may however be a better choice to use HSDPA for PoC if the code allocation problem could be alleviated. For the DCH case, nothing can be done about the code shortage, since every link requires a xed ratio of the code tree and there is no or little scope for a decrease of bitrate. Furthermore, it may be a waste of resources to use DCH channels for PoC, as these probably are better used for truly real-time services as conventional voice conversations. The HS-DSCH, on the other hand, will have capacity left for other services than PoC, provided the code shortage issue can be resolved. To summarize, the main conclusions are that PoC can be relatively well provided over HSDPA, but that there is a code shortage problem that needs to be addressed. The gain compared to common DCH:s is limited and consists mainly of slightly lower delays. It is, however, possibly a gain in itself to be able to provide PoC over HSDPA with at least the same quality as over DCH:s.

8.1

Further Work

A potential subject for further study is the impact on HSDPA performance when assigning less codes to the HS-DSCH, so that larger code resources are left to the associated control signaling DCH:s. The results of this study indicate that this would increase the capacity for the PoC service, as more associated DCH:s then could be set up while the HS-DSCH bitrate still would be sucient for PoC. Thus, new simulations are necessary to investigate whether this is actually the case, and what other factors may become limiting. It must also be taken into account that decreasing the number of codes assigned to the HS-DSCH and consequently the bitrate of the channel, will aect also other services carried over HSDPA. Another approach to improving the HSDPA performance, is to investigate the possibility to decrease the control signaling overhead imposed by the associated DCH:s. These links are today of spreading factor 256, but if the control signaling could be decreased somehow, it may be possible to use SF 512 instead. This would considerably improve capacity. Finally, it should be investigated what can be done to decrease the large protocol overhead that is present in PoC due to the use of IP. With ve AMR frames per packet, nearly half the transmitted bits are protocol headers, which may be a waste of resources. On the other hand, the PoC concept has the advantage of using standard internet protocols, which surely simplies the interfaces between dierent networks. One way to decrease the overhead is to make use of a header compression scheme such as Robust Header Compression (ROHC), which operates on all protocol headers down to the IP layer and transmits only the header changes between consecutive packets. It is of interest to study the eect of such a technique in the PoC case, to see what performance gain can be achieved and if any new issues arise. A more straightforward method of reducing the protocol overhead is to increase the number of AMR frames bundled in each packet. Again, it should be investigated how this aects capacity and performance in general, and in particular what the impact is on mean delay.

54

References
[1] Northstream AB, Overview http://www.northstream.se/, 2004 and comparison of Push-to-Talk solutions,

[2] R Cuny, A Lakaniemi, VoIP in 3G Networks: An End-to-End Quality of Service Analysis, The 57th IEEE Semiannual Vehicular Technology Conference, vol 2, pp 930-934, 2003 [3] A Mate, M Rinne, Performance of Voice over IP on the WCDMA Radio Interface with the Robust Header Compression scheme, Proceedings of SPIE, vol 4522, pp 148-156, 2001 [4] Q Shen, Performance of VoIP over GPRS, IEEE Proceedings of the 17th International Conference on Advanced Information Networking and Applications, 2003 [5] A Schneider, T Ley, Enhanced Voice over IP Support in GPRS and EGPRS, IEEE Wireless Communications and Networking Conference, vol 2, pp 803-808, 2000 [6] E ORegan, D Pesch, Performance Estimation of a SIP based Push-to-Talk Service for 3G Networks, Cork Institute of Technology, Ireland, Adaptive Wireless Systems Group, 2004 [7] S Parkvall, E Dahlman, P Frenger, P Beming, M Persson, The High Speed Packet Data Evolution of WCDMA, IEEE International Symposium on Personal Indoor and Mobile Radio Communications, vol 2 pp G27-31, 2001 [8] T E Kolding, K I Pedersen, J Wigard, F Fredriksen, P E Mogensen, High Speed Downlink Packet Access: WCDMA Evolution, IEEE Vehicular Technology Society News, vol 50, no 1, pp 4-10, 2003 [9] E Englund, M Persson, M Samuelsson, S Parkvall, Impacts of Higher Order Modulation on HSDSCH System Performance, The 57th IEEE Semiannual Vehicular Technology Conference, vol 4 pp 2172-2176, 2003 [10] E Dahlman, P Beming, J Knutsson, F Ovesjo, M Persson, C Roobol, WCDMA - The Radio Interface for Future Mobile Multimedia Communications , IEEE Transactions on vehicular technology, vol 47 pp 1105-1118, 1998 [11] N C Hock, Queueing Modelling Fundamentals, Wiley, ISBN 0-471-96819-6, 1996 [12] N Medman, K Svanbro, P Synnergren, Ericsson Instant Talk, Ericsson Review, no 1 pp 16-19, 2004 [13] Northstream AB, Push-to-talk Over Wireless, http://www.northstream.se/, 2004 [14] B Razavi, RF Microelectronics, Prentice Hall, ISBN 0-13-887571-5, 1998 [15] Ericsson AB, WCDMA Evolved - The First Step - HSDPA, White Paper, 2004 [16] J Rosenberg, H Schulzrinne, G Camarillo, A Johnston, J Peterson, R Sparks, M Handley, E Schooler, SIP: Session Initiation Protocol, IETF RFC 3261, 2002

55

[17] H Schulzrinne, S Casner, R Frederick, V Jacobson, RTP: A Transport Protocol for Real-Time Applications, IETF RFC 3550, 2003 [18] Comneon, Ericsson, Motorola, Nokia, Siemens, Push-to-Talk over Cellular; Architecture; PoC Release 2.0, OMA Specication, 2004 [19] Comneon, Ericsson, Motorola, Nokia, Siemens, Push-to-Talk over Cellular User Plane; Transport Protocols; PoC Release 2.0, OMA Specication, 2004 [20] Comneon, Ericsson, Motorola, Nokia, Siemens, Push-to-Talk over Cellular User Plane; Transport Protocols; PoC Release 2.0, OMA Specication, 2004 [21] 3rd Generation Partnership Project, 3GPP TS 34.108 V5.2.0, 3GPP Specication, 2004 [22] 3rd Generation Partnership Project, 3GPP TS 25.211 V6.1.0, 3GPP Specication, 2004 [23] 3rd Generation Partnership Project, 3GPP TR 21.01U, 3GPP/ETSI Specication, 1997 [24] 3rd Generation Partnership Project, 3GPP TS 25.308 V6.1.0, 3GPP Specication, 2004

56

Appendix A

Channel Congurations
Listed below are the conguration parameters used for the simulated channels.

HS-DSCH Parameter Total HSDPA codes Max. code multiplexing Use 16QAM Max. power TTI length HARQ queues Max. attempts HARQ type Scheduling Policy Value 8 4 Yes 16 W 2 ms 6 5 CC PF Comment Total number of codes (SF 16) used for HSDPA Number of code multiplexed users sharing a TTI. Whether to use the 16QAM modulation scheme. Maximum power used for HSDPA. Fixed for HS-DSCH Number of parallel hybrid ARQ queues. Hybrid ARQ retransmission attempts before sending NAK to RLC. Hybrid ARQ type used. Chase Combining (CC) or Incremental Redundancy (IR). Scheduling policy. See Section 6.1.3.

64-kbps DCH Uplink Parameter RLC payload size in transport block Transport block size BLER target TPC bits/time slot TTI length Max. transport blocks per TTI Pdata /Pcontrol Value 320 336 0.01 2 20 ms 4 5.5 dB Comment Number of bits in the RLC payload Total L1 transport block size, including header RLC and MAC header Target Block Error Rate for outer loop power control Slot format #0, see [22] Design parameter, see above Controls the bitrate, four 320-bit RLC PDU:s in 20 ms renders a bitrate of 64 kbps Power used for physical data channel divided by power used for physical control channel.

57

16-kbps DCH Uplink Parameter RLC payload size in transport block Transport block size BLER target TPC bits/time slot TTI length Max. transport blocks per TTI Pdata /Pcontrol Value 320 336 0.01 2 20 ms 1 2.7 dB Comment Number of bits in the RLC payload Total L1 transport block size, including RLC and MAC header Target Block Error Rate for outer loop power control DPCCH slot format #0, see [22] Design parameter, see above Controls the bitrate, one 320-bit RLC PDU in 20 ms renders a bitrate of 16 kbps Power used for physical data channel divided by power used for physical control channel.

16-kbps DCH Downlink Parameter RLC payload size in transport block Transport block size Spreading factor Pilot bits/time slot TPC bits/time slot TTI length BLER target Max. transport blocks per TTI DPDCH bits per TTI Value 320 336 128 4 2 20 ms 0.01 1 754 Comment Number of bits in the RLC payload Total L1 transport block size, including RLC and MAC header. Gives approximately 25% puncturing Slot format #9, see [22] Slot format #9, see [22] Design parameter, see above Target Block Error Rate for outer loop power control Controls the bitrate, one 320-bit RLC PDU in 20 ms renders a bitrate of 16 kbps Data bits transmitted per TTI. Based on slot format #9 and calculated with a RAB calculation tool developed at Ericsson Research. RM attributes 143/160 for RAB/SRB. Control bits transmitted per per TTI. Slot format #9. Initial CIR target for inner loop power control. Will be adjusted according to BLER target.

DPCCH bits per TTI Initial inner loop target

240 4.5 dB

58

Appendix B

Detailed Results
Below are the detailed simulation results. The symbols should be interpreted as follows. m mcell minst Mean delay Delay standard deviation Mean throughput per cell Mean instantaneous user throughput

B.1

HSDPA with 16-kbps Uplink

nAM R = 5 Load 10 20 30 40 50 60 63 65 67 70 75 80 90 100 120 140 160 Delay m 42 44 46 47 47 47 48 52 52 69 116 249 655 1764 6982 12197 15006 HS-DSCH [ms] Throughput [kb/s] mcell minst 7 41.4 20.6 9 81.8 19.7 9 120.6 18.9 8 155.7 18.5 9 201.2 18.5 36 237.4 18.8 82 250.9 18.9 156 260.3 19.0 129 265.3 19.0 316 277.3 18.9 649 299.8 18.5 1203 320.5 17.5 2414 361.2 15.1 4558 396.0 11.7 9763 439.4 5.5 12448 403.2 3.3 13161 347.6 2.5 Delay m 112 113 113 113 113 114 115 124 123 156 223 413 857 1804 5395 8848 10607 16-kbps DCH UL [ms] Throughput [kb/s] mcell minst 19 40.6 7.71 12 82.1 7.71 12 119.3 7.70 12 154.9 7.70 11 198.9 7.71 67 234.2 7.69 71 247.9 7.68 213 258.1 7.63 177 260.4 7.62 430 274.1 7.49 776 294.1 7.29 1442 318.3 6.90 2607 351.4 6.31 4516 390.6 5.67 9116 441.5 4.38 11900 431.1 3.69 12916 394.6 3.42 Non-sat.usr 103 0.0 1.0 0.8 0.6 0.3 9.5 19.4 52.4 66.3 155.4 292.0 513.4 743.1 -

59

Load 10 20 30 40 50 60 63 65 67 70 75 80 90 100 120 140

Downlink Code Usage mean max 0.628 0.683 0.689 0.769 0.746 0.867 0.795 0.922 0.857 0.992 0.912 1.000 0.932 1.000 0.944 1.000 0.946 1.000 0.961 1.000 0.979 1.000 0.990 1.000 0.998 1.000 0.999 1.000 0.999 1.000 1.000 1.000

Uplink Interference [dB] mean max 0.338 0.992 0.710 1.442 1.076 1.849 1.439 2.355 1.951 3.094 2.409 3.517 2.599 3.700 2.758 4.102 2.754 3.970 2.970 4.126 3.194 4.304 3.505 4.688 3.940 5.512 4.503 6.171 5.861 8.363 7.197 10.654

60

B.2

HSDPA with 64-kbps Uplink

nAM R = 5 Load 50 60 65 70 75 80 85 HS-DSCH Delay [ms] Throughput [kb/s] m mcell minst 47 8 203.0 18.5 47 51 238.5 18.8 48 68 258.8 19.0 79 396 284.5 18.8 129 729 301.6 18.4 180 934 317.2 17.9 609 2404 332.5 15.9 Downlink Code Usage mean max 0.863 1.000 0.914 1.000 0.940 1.000 0.970 1.000 0.981 1.000 0.990 1.000 0.997 1.000 Uplink Interference [dB] mean max 4.066 6.325 5.538 8.425 6.396 9.940 7.986 11.893 9.365 13.496 10.815 15.909 20.912 33.383 64-kbps DCH UL Delay [ms] Throughput [kb/s] m mcell minst 71 13 201.4 12.15 72 46 239.3 12.11 74 98 256.7 12.07 104 402 283.5 11.79 163 784 300.0 11.49 203 896 313.1 11.21 790 3010 313.3 10.13 Non-sat.usr 103 1.32 20.2 35.2 173.9 297.8 -

Load 50 60 65 70 75 80 85

nAM R = 1 Load 30 40 50 60 Delay m 51 128 966 7518 HS-DSCH [ms] Throughput [kb/s] mcell minst 71 300.0 9.8 327 390.0 8.4 2407 487.8 5.7 9804 461.6 2.0 Uplink Interference [dB] mean max 3.354 5.597 5.289 8.461 9.857 17.370 32.040 36.240 64-kbps DCH UL Delay [ms] Throughput [kb/s] m mcell minst 71 8 297.4 6.18 71 8 388.6 6.18 71 41 480.2 6.18 4606 9560 402.6 4.27 Non-sat.usr 103 57.2 300.9 585.8 -

Load 30 40 50 60

Downlink Code Usage mean max 0.748 0.863 0.801 0.914 0.866 1.000 0.982 1.000

61

B.3

DCH 16-kbps Uplink and Downlink

nAM R = 5 Load 10 20 30 40 50 60 65 70 75 76 77 78 79 80 Delay m 103 103 103 103 103 103 103 104 112 123 130 153 2481 4663 16-kbps DCH DL [ms] Throughput [kb/s] mcell minst 17 40.2 8.5 17 80.8 8.5 17 119.8 8.5 17 158.7 8.5 17 196.4 8.5 19 242.3 8.5 24 263.3 8.5 41 279.8 8.5 183 295.9 8.4 286 304.6 8.4 325 306.8 8.3 454 308.9 8.1 6875 218.1 6.1 9717 177.6 5.3 Uplink Interference [dB] mean max 0.327 0.981 0.695 1.401 1.062 1.851 1.474 2.335 1.886 2.958 2.528 3.719 2.751 4.203 3.041 4.288 3.266 4.934 3.331 4.547 3.393 4.929 3.444 4.828 4.331 8.773 5.110 11.960 Delay m 113 113 113 113 113 113 113 113 122 132 133 138 1493 2783 16-kbps DCH UL [ms] Throughput [kb/s] mcell minst 12 40.1 7.71 11 79.4 7.71 12 118.7 7.71 12 158.2 7.71 12 192.8 7.70 17 243.6 7.71 19 259.7 7.70 39 280.7 7.69 187 294.1 7.64 273 299.3 7.59 282 303.6 7.58 312 303.8 7.55 5199 264.4 6.72 7481 227.9 6.20 Non-sat.usr 103 60.3 58.8 57.8 57.8 57.8 55.8 58.2 72.0 114.1 134.8 144.8 173.8 493.8 -

Load 10 20 30 40 50 60 65 70 75 76 77 78 79 80

Downlink Code Usage mean max 0.154 0.273 0.272 0.469 0.384 0.586 0.502 0.719 0.599 0.930 0.749 1.000 0.790 1.000 0.850 1.000 0.887 1.000 0.904 1.000 0.909 1.000 0.917 1.000 0.964 1.000 0.978 1.000

62