Push-to-Talk over Cellular over High Speed

Downlink Packet Access — A Performance

Evaluation

ERIK AKERFELDT

Master of Science ThesisStockholm, Sweden 2005-01-31

IR-SB-EX-0503

Push-to-Talk over Cellular over High Speed Downlink Packet

Access - A Performance Evaluation

Erik Akerfeldt

January 27, 2005

Abstract

In this master thesis, the performance of the Push-to-Talk over Cellular (PoC) service will be in-vestigated, when provided over the High Speed Downlink Packet Access (HSDPA) of the WCDMAradio interface.

A statistical traffic model for PoC traffic is derived, and the performance evaluation is carried outusing an HSDPA capable WCDMA simulator. The measures used for evaluating performance aredelay and throughput, and user satisfaction as a function of delay. Also, the capacity in terms ofcode usage and interference is studied.

To put the HSDPA results into perspective, a comparison is made to a dedicated channel downlink.Also, two different uplink configurations are evaluated for use with HSDPA, one of 16-kbps and oneof 64-kbps bitrate.

The results show that PoC can be relatively well provided over HSDPA, with capacity approximatelyequal to that of the dedicated channel case, but with slightly lower delay. The main HSDPA issue isthe downlink code limitation, which occurs due to the vast number of signaling channels that needto be set up. In the case of the dedicated channel downlink, the limiting factor is rather the uplinkinterference, especially in the 64-kbps case. It is concluded also that the relatively large protocoloverhead of the PoC service is limiting performance.

Contents

1 Introduction 5

1.1 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Universal Mobile Telecommunications System 8

2.1 UMTS Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 WCDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 WCDMA Network Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.2 Layer structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.1 HSDPA Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.2 Code Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Push-to-Talk over Cellular 15

3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.1 IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.2 Group And List Management Function . . . . . . . . . . . . . . . . . . . . . . 16

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

3.2 Session Control Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 Floor Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1

3.4 Voice Data Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4.1 Bits Transmitted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Traffic Model 20

4.1 Session Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Traffic Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2.1 Bit Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3 Model Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 Performance Measures 24

5.1 Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1.1 Delay Measure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.1.2 End-To-End Delay Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.1.3 Relevance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 Cell Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2.1 Satisfied User Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.2.2 Interference And Code Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2.3 Cell Capacity Measure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2.4 Relevance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3 System Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.3.1 Relevance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6 Simulation 31

6.1 Simulator Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.1 Cell Layout and User Movement . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1.2 Radio Link Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.1.3 WCDMA Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6.1.4 Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.2 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.2.1 Simulations Made . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.2.2 RAB Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7 Results 37

2

7.1 HSDPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.1.1 16-kbps Uplink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7.1.2 64-kbps Uplink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.1.3 Varying Number of AMR Frames . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.2 DCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

8 Conclusions 53

8.1 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

A Channel Configurations 57

B Detailed Results 59

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

3

Abbreviations

16QAM 16 Quadrature Amplitude Modulation3GPP Third Generation Partnership ProjectAMR Adaptive Multi-RateARQ Automatic Repeat RequestBER Bit Error RateBLER Block Error RateCIR Carrier-to-Interference RatioCPiCH Common Pilot ChannelDCH Dedicated ChannelDL DownlinkEGPRS Enhanced General Packet Radio ServicesGLMS Group and List Management ServerGPRS General Packet Radio ServicesGSM Global System for Mobile communicationsHS-DSCH High Speed Downlink Shared ChannelHSDPA High Speed Downlink Packet AccessIMS IP Multimedia SubsystemIP Internet ProtocolITU International Telecommunication UnionMAC Medium Access ControlMCS Modulation Code SchemeNodeB Radio base station in UTRANOTAP Over The Air ProvisioningPDU Protocol Data UnitPTT Push-to-TalkPoC Push-to-Talk over CellularQPSK Quadrature Phase Shift KeyingQoS Quality of ServiceRAB Radio Access BearerRAN Radio Access NetworkRFC Request For CommentsRLC Radio Link ControlRNC Radio Network ControllerROHC Robust Header CompressionRRC Radio Resource ControlRTCP RTP Control ProtocolRTP Realtime Transport ProtocolSF Spreading FactorSIP Session Initiation ProtocolSRB Signaling Radio BearerTTI Transmission Time IntervalTrCH Transport ChannelUDP User Datagram ProtocolUE User EquipmentUL UplinkUMTS Universal Mobile Telecommunications SystemUTRAN UMTS Terrestrial Radio Access NetworkWCDMA Wideband Code Division Multiple Access

4

Chapter 1

Introduction

The third generation of cellular radio networks has enabled several packet switched services in awireless environment. One such service is Voice over IP (VoIP) and the Push-to-Talk application inparticular. Push-to-Talk is a “walkie-talkie” like service, which allows for using the mobile phonefor quick half-duplex communication with just a push of a button. This may be useful for privatecommunication between friends, but also for businesses like delivery firms 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 vendor-specific solutions dedicated for the Push-to-Talk service and hence cannot be implemented in theexisting infrastructure for mobile communications in Europe. However, the American systems, withthe 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), whichis a specification of Push-to-Talk in packet switched cellular networks. This specification has beendeveloped by an industry consortium supported by Ericsson and others, and submitted to the OpenMobile Alliance (OMA) as a proposed standard. PoC is based on the Internet Protocol (IP) andis not biased to a particular radio network architecture. Thus, it can be implemented on bothEuropean WCDMA networks and American CDMA2000 networks. Currently some pre-standardimplementations 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 preciselyover a high-speed channel called HSDPA. HSDPA is a concept that allows for higher data rates thanprevious WCDMA versions, but only in the downlink. The aim is to examine how well and efficientPoC can be provided over HSDPA and how large (if any) the improvement is compared to other,slower channels.

1.1 Problem Definition

The problem addressed in this thesis may be formulated as a question: how well can the servicePush-to-Talk over Cellular be provided over HSDPA, and what, if any, are the gains compared tostandard dedicated channels?

HSDPA improves only the downlink, while PoC is a bidirectional service, and thus the limitations ofthe uplink must be considered and requirements specified. It will also be investigated whether it isthe 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 definition needs to be defined, which is done in Chapter 5. Themeasures used for determining how well PoC is provided are latency (packet delay), cell capacity andthroughput, 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 traffic,based on the OMA specification, in order to learn how packets are generated and transmitted. It willbe examined how much data each user need to transmit and receive, how often and for how long.

The PoC traffic situation will then be modeled in a Matlab-based simulator developed at EricssonResearch. The simulator is capable of simulating WCDMA networks including the HSDPA function-ality, but has no specific handling of the PoC service. Hence, a simulator function modeling PoCtraffic must be added.

1.3 Goal

The goal is to arrive at concrete results (from simulations) showing the characteristics of HSDPAwhen carrying PoC traffic, in terms of the selected performance measures. Also, it is intended thatthe differences between HSDPA and a dedicated channel downlink should be made clear. An absoluteanswer to what channel is better will however not be given, as this to some extent is a matter ofpreferences. 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 PoCtraffic, 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 isreflected in the fact that the number of published studies of PoC performance seems to be verylimited. Also, providing PoC over HSDPA is somewhat unconventional, as HSDPA originally wasdesigned for high-bitrate best-effort downlink applications rather than a relatively narrow-band semi-realtime 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 differences,mainly that PoC is only a half-duplex service, which will be discussed further in Chapter 3, butnevertheless the numerous studies of VoIP in WCDMA networks may hint about what performancecan be expected for PoC.

In [2], simulations of VoIP carried by the dedicated channels of WCDMA are made, and it is concludedthat it is possible to provide the VoIP service with reasonable quality over such channels. It is assumedthat 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 configuration of the channels used,which will be discussed later in this thesis, and that there may be a trade-off between delay and usercapacity. 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 resultsshow 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 partlyhas developed, and this is probably of more relevance for this thesis. It is concluded that transmissiondelays are approximately 30% lower for the shared channel compared to the dedicated channels, andthat the reason is mainly the shorter transmission time intervals of the DSCH. HSDPA, as will laterbe described, has even shorter transmission time intervals and several other enhancements, and canthus be expected to decrease delays further.

Other studies of VoIP in radio access networks can be found in [4] and [5], both considering (E)GPRSrather than WCDMA.

A partially relevant study is done in [6], which investigates the performance of PoC in WCDMAnetworks. The study is however limited to the setup and termination times of PoC sessions, not theactual voice transmission delays. The setup times are beyond the scope of this thesis, but it maynevertheless be noted that the study concludes that session setup times are on the order of 1500 ms,which is considered sufficiently low.

Finally, there are a large number of studies looking at the HSDPA concept in general, i.e. whenused not specifically for PoC. Simulations done in [7] show that HSDPA is capable of providingbitrates up to 8-10 Mb/s under favorable conditions, while the study in [8] point at bitrates up to 4Mb/s on average. A third study can be found in [9], which is focused primarily on to what extentthe higher order modulation supported by HSDPA (see Section 2.4) contributes to the performanceimprovement.

1.5 Thesis Outline

The thesis is outlined as follows.

A description of the UMTS/WCDMA system will first be given, including the HSDPA concept. Next,the PoC service as specified by OMA will described, with focus on the traffic pattern and amount ofbits generated. This is followed by a detailed explanation of the traffic model.

The thesis is continued with a description of the performance measures used for evaluating PoCperformance, and a review of the simulator. The simulation setup and channel configurations arealso covered.

Finally, the results are presented and analyzed, followed by conclusions and a discussion of possibleimprovements and further work.

7

Chapter 2

Universal Mobile

Telecommunications System

The increasing number of wireless users and applications has placed new demands on capacity inthe radio networks. The network is required not only to offer services as voice and SMS, but alsointernet access and streaming video. Applications of this kind call for bitrates significantly higherthan those of second generation systems.

To meet these demands, new spectra have been allocated, and a new third generation technologydeveloped. Systems of this kind are by the International Telecommunications Union (ITU) referredto as IMT-2000, and by the European Telecommunications Standards Institute (ETSI) as UMTS.UMTS, the Universal Mobile Telecommunications System, specifies what services the third generationsystems will be capable of providing, and what network architecture should be used.

2.1 UMTS Functionality

UMTS offers both tele-services as speech and SMS, and general bearer services that can transfer anyinformation between two points. These services can be either connection-oriented or connectionless,and can be configured for different quality of service parameters and bitrates. The ITU has specifiedthat 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 defined for UMTS, specified 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 surfing etc, moderate delay but no data ordering.

• Background bearer class. Used for e.g. file transfer, no delay requirements or ordering.

8

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

2.2 Network Architecture

The UMTS network is subdivided into three conceptual subsystems: the Core Network (CN), theUMTS Terrestrial Radio Access Network (UTRAN) and the User Equipment (UE). The responsibil-ities 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 AsynchronousTransfer Mode (ATM) for data transfer. Also, home and visitor location registration, authenticationand billing are handled by the core network.

The UTRAN handles the connection between the user equipment and the core network. Its mainpurpose is to isolate the core network from all issues involving radio when communicating with theUE. The interface between the UTRAN and the core network is called Iu, and the interface betweenUTRAN 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 anumber 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 specified by the 3rd Generation Partnership Project (3GPP) and operates in the 2-GHzfrequency band. The outspoken goal is to make WCDMA a global standard for the 3G radio accesstechnology, and it is not unlikely that this will be achieved [10]. WCDMA networks are currentlyimplemented in numerous European countries, as well as in North America, Japan and Asia. Inaddition to higher bitrates, there are many other improvements in WCDMA compared to secondgeneration systems. Among these are improved coverage and capacity, support for inter-frequencyhand-overs, adaptive antennas and multiuser detection, and a fast and efficient packet-access protocol.Also, as WCDMA developed further, the high-rate concept of HSDPA was added. The HSDPAfunctionality 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 orthogonalcodes are used for separating logical channels. This is an alternative to frequency or time divisionmultiple access and is more spectral efficient. The principle of CDMA is, somewhat simplified, tomultiply each data bit with a code of n bits that is orthogonal to all other codes used, so that the bitsequence to be transmitted becomes n times longer than the original sequence. A broader frequencyband is then needed for the transmission, but it can be shared with other channels due to the codeorthogonality. At the receiver, the sequence is correlated with the same code, in order to extract theoriginal data [14].

The length n of the code is called the spreading factor, SF, and defines the maximum number oflogical channels possible to transmit in parallel. Channels of different spreading factors can be presentsimultaneously, as long as the code resource is not exhausted.

Algorithms

A number of algorithms are implemented in the WCDMA network, to ensure secure and efficientoperation.

Power control is used to regulate the transmission power of the UE:s, so that the received power atthe Node B is (approximately) equal for all UE:s. This is to ensure that UE:s close to the Node B donot shout down UE:s more distant by transmitting at excessive power. The power control is carriedout at two different 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 onecell to another. This process is called hand-over (or sometimes hand-off). In WCDMA, it is possiblefor a UE to be simultaneously connected to more than one Node B. In this case, the UE adjustsits output power to the minimum required by the available Node B:s, and may as a consequenceswitch between cells very quickly. This feature is referred to as soft hand-over, and does not onlysave power, but also reduces the risk for dropped calls.

The admission control function controls how users are admitted into the system, and is needed toavoid overload. In WCDMA, as opposed to e.g. GSM, the aim is to always maintain the QoS of theadmitted users, and thus it must be ascertained that there is sufficient resources left before a newuser can be admitted.

Admission control is divided into two parts, the session admission control and the link admissioncontrol. Session admission control decides whether there are sufficient resources to admit a new userof a certain service, based on knowledge of how many sessions the system can handle without loss ofQoS. Link admission control works on a shorter time scale, and checks whether or not it is possibleto set up a new link (e.g. a dedicated channel, DCH) for a specific session. Setting up new linksmay be required during a session if the user is in soft hand-over, or transmits so much data that anup-switch to a broader channel is necessary.

In the downlink, the link admission control performs both a code usage check and a load check. Thecode usage check ensures that there is always sufficient code space for all admitted links, i.e. that

10

c =∑

i

1

SFi

< 1

where c is the code usage, and SFi the spreading factor of link i. Link admission control admits newlinks 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 isdone by calculating the total power used by the current links, and estimating the power increasethat will be caused by the new link. If the total power after admission of the new link exceeds aprescribed limit, admission will be denied.

In the uplink, link admission control performs a load check to ensure that the uplink interferencedoes not compromise the coverage. Similar to the downlink, a parameter controls the uplink loadlimit in terms of power.

2.3.2 Layer structure

The various functions needed to efficiently and securely carry data over the WCDMA radio accessnetwork, are organized in a layered structure, similar to most other types of networks. The threelayers 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. Abovethese is the packet data convergence protocol (PDCP) layer, offering services to the core networkand 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 overradio. It handles many complex issues as coding, multiplexing, interleaving, rate-matching etc, andhides all this to the above layers. The result is a number of transport channels (TrCH) that areoffered 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 offers the service of data transfer to the layers above. It handles the selection ofan appropriate bitrate, service multiplexing onto single physical layer TrCH:s and priority handlingbetween multiple user data flows. Also, the MAC layer caters for access control, address control andcontention 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 inthree different modes, depending on the characteristics of the service carried. These modes are theTransparent Mode (TM), the Unacknowledged Mode (UM) and the Acknowledged Mode (AM). InTM no header is added at the RLC layer which means that the ordering and error correction of datamust be catered for elsewhere, in UM some header information is added but data received in erroris 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 errorsare not acceptable, e.g. e-mail.

The RRC includes system information broadcasting, radio resource handling, QoS control and UEmeasurement reporting. The RRC exists at the same level as RLC, but is used for control ratherthan data transfer.

2.4 HSDPA

As new packet-data services are introduced, and the user terminals become more advanced, higherdata rates are required in the wireless networks. The answer to this demand in WCDMA is a conceptcalled High Speed Downlink Packet Access, HSDPA. As the name implies, the HSDPA concept offershigher 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 amaximum of 2 Mbps for certain “hot spot” areas like offices and airports. This may be enough formany 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 14Mbps in the downlink, but also for two to three times higher system capacity and a significantlyreduced delay for some services [15]. However, HSDPA only improves the downlink, and its archi-tecture makes it suitable mainly for non real-time applications. The improvements seen by the userwill be most obvious when downloading large files, while the main benefit for operators may be theincreased capacity.

HSDPA is designed to fit as easily as possible into the existing WCDMA system, but some changeshave been done mainly at the physical layer and the MAC layer. For the latter, a new protocolnamed 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 Chan-nel). The main benefit of a shared channel, is that resources can be more efficiently utilized, asavailable codes and power can be shared by many users. The sharing is primarily done in time, butthere is also a possibility to use codes. The shared code resource available to the HS-DSCH consistsof a total of 15 codes (SF 16 with 1/16 of the code resource reserved for control), but it is the decisionof 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 forfast closed loop power control. This mechanism is replaced by fast link adaptation and channel-dependent scheduling, as described below.

Higher-Order Modulation

The modulation scheme for release 99 WCDMA is QPSK, which can carry two bits per symbol. TheQPSK principle is to divide the RF carrier into in-phase and quadrature-phase components, whichare orthogonal to each other. This is done in practice by observing that the sine and cosine functionsare 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, andcan 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 lesscompared to QPSK. When channel conditions are good, it is therefore favorable to use 16QAM,while QPSK is better under more difficult channel conditions. HSDPA utilizes this by altering themodulation 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 sentin each interval, but on the other hand the time until the next transmission window will also belong. The TTI for the dedicated channels of WCDMA range from 10 ms and up, but for HSDPAthis is reduced to 2 ms. This significantly reduces the round-trip time, which is important whenseveral retransmissions are needed before data can be decoded. Also, the short TTI helps keepingend-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. Thisis exploited in HSDPA by adjusting the data rate and/or changing modulation scheme according tothe instantaneous channel conditions. If the channel conditions are good, the 16QAM modulationcan be used, together with a high code-rate, while with poor channel conditions, QPSK may be usedinstead and the code-rate is decreased. In this way, the channel is always utilized as efficiently aspossible.

In order to perform the link adaptation, the Node B must have a means of estimating the instanta-neous channel quality, or more specifically the current Carrier-to-Interference Ratio (CIR). One wayto obtain such information is to send a pilot signal to the UE in question on the CPiCH (CommonPilot Channel) and measure the power needed. The CIR of the CPiCH is then used as an estimatefor the CIR of the HS-DSCH which will later be used for data transmission, and thus constitutes ameasure of the current channel conditions. This method is used for HSDPA.

Channel-Dependent Scheduling

The task of the scheduler is to decide which user’s data should be transmitted in a given TTI. InHSDPA, this decision may depend on the channel conditions, but also on the QoS class of differentusers 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. Thescheduler thus works in close cooperation with the link adaptation function, as channel characteristicsare needed for the scheduling decision. However, to only use the channel conditions as a base for thescheduling may lead to unfairness, as users with continuous bad channel conditions will experiencea very low QoS. For that reason, one may combine the purely channel-dependent approach withsome degree of long-term fairness. One possibility is the proportional fair scheduling principle, butthe HSDPA specification allows for any other solution, as there has been no standardization of thescheduling algorithm.

Hybrid ARQ

Hybrid Automatic Repeat Request (HARQ) is another important feature of HSDPA which enablesfast and efficient retransmission of erroneous data blocks. The principle of ARQ schemes is thatthe receiver sends a positive or negative acknowledgment for each data block, and in the case of anegative acknowledgment a retransmission is made. HSDPA uses a Stop-And-Wait (SAW) type ofARQ, meaning that the transmitter awaits an acknowledgment for the previous data block beforesending the next.

The hybrid ARQ mechanism extends the ARQ concept by combining data from the original transmis-sion and every retransmission in order to enable successful decoding. This way, data can be correctlyreceived even if neither the original block nor the retransmission could be decoded individually. Theconcept 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 assigningeach user a time slot of 2 ms in which she can transmit. This works well as long as every user hasenough data queued to make use of the entire TTI (the actual amount of bits that can be transmittedduring the TTI depends on the channel conditions), but if a user only can utilize part of the TTIcapacity, 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 eachbe assigned a subset of the codes available for HSDPA, so that the full potential of the channelcan be exploited. Some precaution must be taken, however, as code multiplexing will increase thecontrol signaling overhead. Nevertheless, code multiplexing can be expected to increase the capacityof 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 walkie-talkie. The principle is that the user, with just a push of a button, gets instantly connected to one ormore 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 beforespeaking, and may speak only after an acoustic or visual signal is given by the PoC terminal. PoCsessions may be either one-to-one or one-to-many, where in the latter case several users are connectedin a fashion similar to conference calls. The terminals hold a so called “buddy list”, in which theusers 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 devicescommunicate 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 offered by the cellular systems,thus enabling PoC communication with users all over the world. Also, the PoC service will beintegrated in ordinary mobile phones, which millions of people already carry with them every day.

PoC may be used for dispatching in delivery firms etc., and in other cases where traditional walkie-talkies are used today. The service can also be assumed to have a widespread private use, as it maybe seen as an alternative to SMS and the various text-based instant messaging services.

A Push-to-Talk service was first made available in USA by the operator Nextel. Together withMotorola, Nextel built a completely proprietary network designed only for Push-to-Talk traffic. TheNextel service is fast and reliable and has many American subscribers, but the system offers verylimited interoperability with other systems [1]. In Europe, the approach to Push-to-Talk has insteadbeen to provide the service over general radio access networks as GSM and UMTS, to benefit fromthe existing infrastructure.

PoC can be seen as an implementation of Push-to-Talk based on IP in GPRS and WCDMA net-works. An industry consortium consisting of Ericsson, Motorola, Nokia, Siemens and Comneon iscurrently working on a specification which has been submitted to the Open Mobile Alliance (OMA)for standardization. The specification is now publicly available1 and is expected to be frozen in 2004.In the following sections, PoC as defined in these specifications will be described [18, 19, 20].

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

15

3.1 Architecture

PoC is based on IP and relies on the IP Multimedia Subsystem (IMS) specified by 3GPP. It ismandatory 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 Pro-tocol (RTP) and RTP Control Protocol (RTCP), which all are standardized by IETF and describedin [16] and [17]. The SIP protocol is used for finding PoC users and setting up sessions, while RTPand RTCP are used for the voice data transfer and the so called floor control.

3.1.1 IMS

The IMS (IP Multimedia Subsystem) is a subsystem of the UMTS core network, which handlesIP-based multimedia services. PoC is one such service.

The functionality for finding, registering and authenticating PoC users is handled in the IMS usingSIP. 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, andmaintains 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 andaccess lists. These lists are stored by the GLMF and used by the PoC user to establish sessions anddetermine access. The contact list (“buddy list”) contains the addresses of all other PoC users a usermay want to establish a session with, and predefined groups of users who all may take part in the samePoC session. The access lists control who are allowed to establish a PoC session with a particularuser, and who is allowed to view the user’s presence information. The presence information indicateswhether 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 listfor 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 defined for PoC servers, which arethe Controlling PoC Server role and the Participating PoC Server role. The controlling PoC serverhas the overall control of a PoC session, but UE:s are not directly connected to this server, but ratherto a participating PoC server handling a specific UE. Each UE is connected to a participating PoCserver, and there may be several participating PoC servers for every session. The participating PoCservers 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 different networks. The controlling and participating PoCservers are, as the GLMF, only functional entities, and may in implementations be grouped togetheron 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. thewell-known HTTP and SMTP protocols.

SIP signaling is needed in three phases of the PoC session, at setup, at termination and at sessionchanges. The latter applies only to group sessions, where PoC users may join and leave the groupthroughout the duration of the session. The study of this thesis will for simplicity be limited toone-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 participantis allowed to talk. As PoC is designed to be a half-duplex service, only one participant may talk ata time. The process of controlling this is referred to as floor control and the signaling is carried inRTCP packets. Seven types of floor control messages are defined, but in a typical one-to-one PoCsession, only a subset of these messages will be sent. Typically, when a talk-burst finishes and theuser releases the push-to-talk button, a Floor Release message is sent in the uplink from the UE tothe PoC server. The PoC server responds by sending a Floor Idle message in the downlink, and theother UE of the session may then send an uplink Floor Request message. The PoC server finallyresponds 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 thelength of each message including RTCP headers. As packets are wrapped in UDP and transmittedover IP, additional bits are added.

Type Subtype bit-pattern Total bits Direction

Floor Release 00100 128 UplinkFloor Idle 00101 96 UplinkFloor Request 00000 96 UplinkFloor Grant 00001 96 DownlinkFloor Taken 00010 32(3 + nD) Downlink

Table 3.1: Floor control messages.

The Floor Taken message, used to inform UE:s that the floor has been taken and who has taken it,will vary in length. When assuming 8-bit ASCII character encoding an approximate mean value maybe calculated.

From [19] it is seen that the Floor Taken message should include the canonical and common namesof the user granted the floor, and the average lengths of these are assumed to be lCNAME = 8 ·16 bitsand lNAME = 8 · 24 respectively. Including header bits, the mean number of 32-bit data sections inthe Floor Taken RTCP packet is nD = 1

32(16 + lCNAME + 16 + lNAME), 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 andtransmitted over IP. The voice codec used is the so called Adaptive Multi-Rate (AMR) codec, whichis also used in the GSM and WCDMA systems for traditional voice calls.

As the name implies, AMR supports a number of different bitrates, with varying voice quality. Theparameters controlling the AMR mode are negotiated with SIP signaling during session setup, sothat 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 andmandatory for PoC. This mode have an output bitrate of 5.15 kbps.

The AMR codec output is organized in AMR frames, with a fixed length of 20 ms. The frames arein turn subdivided into three parts, denoted A, B and C, with decreasing sensitivity to transmissionerrors. In the PoC case, however, all three parts are transmitted over the same channel, and thisdivision is of no importance. The number of AMR frames placed in each RTP packet is a designparameter, ranging from one up to a maximum of 20 AMR frames per packet. With few frames perpacket, delay will be low as packets are arriving frequently and little buffering space is required. Onthe other hand, the protocol header overhead will be large. By just increasing the number of AMRframes per packet slightly, the overhead factor will decrease considerably.

The AMR codec used for PoC is also required to support discontinuous transmission (DTX). DTXis used to reduce bandwidth usage when the user is temporarily quiet. The codec detects thesilent periods, and sends short control messages every 160 ms, instead of continuously transmittingnormal AMR frames with encoded silence. However, DTX will probably have limited impact on PoCperformance, as PoC is a half-duplex service. It is likely that the user currently speaking will notbe silent for long periods without releasing the push-to-talk button, and the silence of the listeningPoC 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 anAMR frame length of 20 ms the 5.15 kbps mode renders frames of length lAMR = 20·10−3 ·5.15·103 =103 bits. Furthermore, the number of AMR frames per RTP packet is denoted nAMR.

The PoC specification [19] states that the AMR frames should be placed in an RTP packet wherethe CSRC (contributing source) field is not used in the header, and the payload is in so called octetaligned mode. The CSRC field is unnecessary because there is always only one source, namely thePoC UE currently granted the floor. From [17] it can be seen that the RTP header then becomes3 · 32 = 96 bits long. The RTP payload consists of an eight-bit payload header, and eight bits TOCinformation for each AMR frame. As the octet aligned mode is used, each AMR frame of lengthlAMR is padded with zeros so that the length becomes an integer multiple of 8 bits. The effectivelength of each AMR frame, when placed in the RTP payload, thus becomes lAMR,eff = dlAMR/8e ·8bits where d•e denotes the closest higher integer or the ceiling function. Putting everything together,the total length of the RTP packet is lRTP = 3 · 32 + 8 + (8 + lAMR,eff)nAMR bits, which in the 5.15kbps mode evaluates to lRTP = 104 + 112nAMR bits.

The RTP packets are placed in UDP packets with 64 bits of header, and the UDP packets are inturn put into 160-bit header IPv4 packets (the optional IPv6 has a longer header). The nAMR AMRframes bundled together then render a total of lIP = 160 + 64 + 104 + 112nAMR = 328 + 112nAMR

bits out from the IP layer. To illustrate the effect of varying the number of AMR frames per RTPpacket, an “overhead factor” may be calculated for different values of nAMR. With nAMR = 2 theratio of total bits to AMR frame bits is fOH = (328 + 112 · 2)/(103 · 2) = 2.7, while with nAMR = 8the overhead factor decreases to fOH = (328 + 112 · 8)/(103 · 8) = 1.5. Apparently, the overheadfactor can be multiplied with the AMR codec output bitrate, to retrieve the effective average bitrateout of the IP layer. Figure 3.1 illustrates the IP bitrate dependence on nAMR.

It is suggested above that there is a trade-off between bandwidth and delay when setting the numberof AMR frames per packet, nAMR. With few frames per packet, the header overhead becomessignificant but on the other hand the delays are kept low, while with a large nAMR the bandwidthefficiency increases at the cost of larger delays. However, there is a third factor requiring attentionwhen deciding a suitable value for nAMR in the case of PoC, namely the TTI length of the RAB:sused. As will be seen in Chapter 6, the parameter set of the channels (RAB:s) used for radiotransmission controls how many bits can be transmitted per TTI, and in order to limit delays it is

18

1 2 3 4 5 6 7 8 9 10 11 120

2

4

6

8

10

12

14

16

18

20

nAMR

Bit−

rate

[kbi

t/s]

Figure 3.1: Average bitrate from IP layer as a function of number of AMR frames per packet nAMR.

desirable to utilize the “capacity” of each TTI as much as possible. For this reason, some values ofnAMR are more suitable than others for a given channel configuration, and this will be discussedfurther in Chapter 6.

19

Chapter 4

Traffic Model

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

4.1 Session Generation

The PoC traffic is generated by a number of sessions, each corresponding to one PoC user. A one-to-one PoC call is thus in the traffic model made up of two individual sessions. Furthermore, thereis no direct connection between the two users of a PoC call, but a session is at every time instanteither uplink or downlink and only implicitly paired with some other arbitrary session. The othersession may be one in the same cell, but also in another cell or in a completely different network,geographically distant (in which case the session is not modeled).

Sessions are generated randomly and last for an exponentially distributed amount of time Ts. Inorder to keep the number of active sessions constant on the average, a value for the session arrivalintensity λ is required. This is calculated according to Little’s law [11], which states that, undergeneral conditions,

N = λT

where N is the average number of users in the system (offered load), λ is the arrival intensity andT = 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 sessionis set. The session duration time is then calculated as Ts =

∑ntb

i=1ti, where ti is the duration of

talk-burst i. The mean session duration time T of (4.1) will then be

20

T = E[Ts] = E

[ ntb∑

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 ntb

always is even. The talk-burst times ti are independent and drawn from an exponential distributionwith mean E[ti] = mt, and the number of downlink talk-bursts 1

2ntb are drawn from a geometric

distribution with mean 1

2E[ntb] = 1

2mn. It can be shown that the total session duration time Ts then

also is exponentially distributed with mean mtmn.

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 flag in the simulator indicating that the userno longer requires any service. However, a session may linger for some time after the user stoppedtransmitting, due to a WCDMA function used to save channel setup time if the user should starttransmitting again after a short idle period. These down-switch timers are implemented in thesimulator which results in a situation where the average number of total users in the system is higherthan the desired offered load. But, as terminated sessions do not transmit, the average number ofactive users should correspond to the offered load N used in (4.1).

When the simulation starts there are no users in the system, and a considerable amount of timewill elapse before the system reaches the desired load. It is however not feasible to wait for thesystem to stabilize, due to the heavy computations needed, but the simulator offers another solutionwhich will be used. For the first tstart seconds of the simulation, sessions are generated uniformlyover the interval [0, tstart] so that the offered load at time tstart is the desired value N . After this,sessions are generated according to the normal arrival process. An empirical study indicate thatsetting tstart = T/2 gives the most rapid load stabilization.

4.2 Traffic Generation

As PoC is a packet-switched service, traffic is generated as packets which in this case are transmittedwith fixed intervals. The model handles four types of packets: ordinary voice data packets, floorcontrol packets, SIP session setup packets and SIP session termination packets. The floor controlpackets 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 sessionis initialized and terminated. The SIP model is very simplified, and present mainly for the followingreasons. First, there is a fixed 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 traffic sent during this initial period will be SIP signaling, and voice data transmission will not beaffected. By initially generating SIP type packets, this situation is catered for by the traffic model.Second, the SIP signaling contributes to the total load offered to the system, which can be modeledby generating an approximate amount of data bits that not necessarily need to follow the exact SIPtraffic pattern; the average load will still be correct. In addition, the SIP type packets indicate thebeginning and end of each session, which is useful for confirming the implementation of the trafficmodel in the simulator.

For voice packets, the inter-packet time is fixed and deterministic and decided by the number of AMRframes per packet. The inter-packet time would with nAMR AMR frames per packet be 20nAMR

ms, as one AMR frame is generated every 20 ms. An exception is made for new users, where thetime until the first packet is sent is chosen randomly from a uniform distribution over the interval[0, 20nAMR] ms. The reason for randomizing the first inter-packet time is that all new users otherwisewould transmit simultaneously throughout the duration of the session, which is not realistic. Thedirection of the first 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, floor control packets arealso sent according to the direction of the switch. The floor control packets are sent as describedin Section 3.3, and only one packet per type. This means that floor control packets are sent at thesame time as the first voice data packets in the new direction, which is not very realistic. On theother hand, the floor control packets contribute mainly to the “background” load of the system, andhave 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 directionhave been delivered or not, since there is no direct coupling between the traffic model and thelinks that are used to transmit the generated bits. This simplification of the model facilitates theimplementation, but also leads to somewhat unexpected effects when evaluating the results. As willbe stated in Chapter 5, session admission control is disabled in the simulations, while the downlinkcode check still is active. If a situation occurs where the downlink code resource is exhausted, sothat users are denied links, the traffic model will still generate bits which are buffered until a linkcan be set up. Thus, when the link finally is set up, transmission takes place continuously (i.e. notwith 20nAMR ms intervals) until the buffer is empty. This means that the traffic model ceases tomodel PoC traffic under such circumstances. This is not a major problem, since real systems withsession admission control activated never experience this, but the phenomenon is important to keepin mind when evaluating the simulation results.

All packets sent are time stamped and placed in a log. When bits are delivered for a session, theremaining number of undelivered bits of the oldest packet for that session is decreased. This processcontinues until all delivered bits have been assigned to an undelivered packet, and when a packethas been delivered completely, it is stamped with the time of delivery. This allows for following eachpacket through the system, and perform any type of post-processing after the simulation is finished.However, the method for determining when a packet is delivered assumes that all packets are deliveredin-sequence, i.e. in exactly the same order as they were sent. This assumption is probably valid asthe RLC if necessary will cater for the re-ordering, even if it is theoretically possible that packets fallout 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 nAMR 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 floor 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 onthese occasions, two cases must be considered: when a PoC user first was talking and then switchedto listening and when a PoC user first was listening and switched to talking.

In the case of an uplink (talking) PoC user switching to downlink (listening), the Floor Releasemessage will be sent in the uplink, and the Floor Idle and Floor Taken messages will be receivedin the downlink. This renders a total of 128 uplink bits and 544 downlink bits. In the case of adownlink (listening) PoC user switching to uplink (talking), the Floor Request message will be sentin the uplink, and the Floor Idle and Floor Grant messages will be received in the downlink. Thisrenders a total of 96 uplink bits and 192 downlink bits. The RTCP floor control packets are wrappedin UDP and transmitted over IP. From the IETF RFC specifications of these protocols, it can beseen 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 final value for thetransmitted uplink and downlink bits for the two cases.

It should be noted that, according to the PoC specification, the Floor Idle, Floor Release and FloorRequest 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 approx-imately exponentially. For simplicity this is not taken into account in the traffic model, which maybe acceptable if the initial floor control inter-sending times are larger than the round-trip times. Inthis case, the participating UE:s will receive the Floor Grant or Floor Taken messages before sendingany repeated floor control messages.

SIP Bits

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

4.3 Model Parameters

The behavior of the traffic model is mainly influenced by the following parameters.

• Mean number of talk-bursts mn.

• Mean talk-burst duration time mt.

• Offered load N .

• The number of AMR frames per packet nAMR.

The parameters mn and mt will decide how long a PoC session lasts, but the session length has littleimpact on the delay of each voice packet of the session. Regardless of how long a session is, voicepackets will be sent with certain fixed intervals and are required to arrive within a specified periodof time. Nevertheless, a short session duration time will require a longer simulation, as there mustbe time to smooth out short term variations. In this thesis, it is assumed that mn = 4 and mt = 7s, which gives an average session length of T = mnmt = 28 s. From experience, a simulation time ofapproximately 200 seconds is then required.

The offered load N will be varied in the simulations to find the point of maximum system capacity.Also, nAMR 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 defined and what relevance they have to the overall performance ofPoC over a specific channel. In this chapter, the performance measures used are described, as wellas 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 fromits origin to the destination. This time may include not only the actual transmission delay, but alsoprocessing delays at different points, e.g. in the UE and in the PoC servers. Furthermore, whendefining delay, it must be made clear what is meant by origin and destination. When the networktransmits 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 shouldbe measured from the time a packet leaves the sending UE until the time it arrives at the receivingUE. This combined uplink and downlink delay will in this thesis be referred to as the end-to-enddelay.

Packets are in the PoC case generated with fixed intervals and are required to arrive with approx-imately 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 variationsin processing time at different points, but the main reason is that data sometimes needs to be re-transmitted due to transmission errors. Depending on the number of retransmissions, and how thescheduler handles them, this may result in significantly increased delays for some packets. To handlethis, the UE:s implement a play-out buffer in which packets can be held for a short time before theyare unpacked, decoded and played out to the PoC user. The size of the play-out buffer depends onthe delay distribution of the system, and in particular the delay variance. With a certain lengthof the play-out buffer, there is a maximum variation in packet delay that can be tolerated before apacket is outdated, i.e. it is considered not useful at arrival. Late packets must be discarded, andthe 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 departureand arrival time, thus making it easy to calculate the delay. However, the delay is only measuredin 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 downlinkseparately.

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 arecalculated for each session individually to illustrate differences due to e.g. the scheduling, but alsofor the system in general to show the overall system performance in terms of delay. To obtain adistribution for the end-to-end delay, it would in principle be necessary to measure the end-to-enddelay of every packet, but as the simulation is not set up this way, this is not possible. Instead, themethod 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 allpackets sent in one direction of the same session will be included in the same distribution. Thismeans that for a session of e.g. two uplink and two downlink talk-bursts, packets belonging totwo different talk-bursts will be included in the same delay distribution. This way, it can easily bedecided whether or not the delay was sufficiently low for the particular session, which is useful fordetermining if the user was satisfied (see Section 5.2).

The delay PDF:s will of course be presented together with their mean and variance values, where thevariance (or rather standard deviation) can be viewed as a measure of the delay jitter. However, thestandard deviation value must be interpreted with care, as it at least when the system is moderatelyloaded may be somewhat misleading. It is for non-overloaded systems possible that the vast majorityof packets arrive with the shortest possible delay, but that a few packets have significantly higherdelays. The reason for the large delay of a small amount of packets may be many retransmissions forusers with poor instantaneous channel conditions. Thus, even with a large delay standard deviation,say 95% of the users may be perfectly satisfied. Even if five percent non-satisfied users is not at allnegligible, 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, notprocessing 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 fixed, andthus it is possible to calculate an additional delay term which must be added to the transmissiondelay 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 andpacketize the AMR frames into RTP packets and so forth. With five AMR frames per packet,this delay is 105 ms including 5 ms of processing. Also, a 10-ms general processing delay willbe 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 beapproximately 25 ms.

• General network processing, e.g. in the core network and IMS Core. This delay is assumed tobe approximately 25 ms.

• Processing in the receiving UE. The UE unpacks and decodes data, causing a processing delaywhich is assumed to be approximately 15 ms. To handle the delay jitter, the play-out bufferholds the voice frames for a certain time before playing them. This offset is assumed to be 100ms, 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 actualtransmission delay. In the PoC specification [20], it is recommended that the total end-to-end delaydoes not exceed 650 ms for “a vast majority of the users”, which means a delay tolerance of maximum370 ms for the radio transmission. However, the 650-ms recommendation includes the possibility ofproviding PoC over GPRS, which can be expected to be slower than WCDMA. For this reason, the

1The 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 valueshould be seen as the accepted average delay, longer delays can be handled due to the play-out bufferin 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 delaydistributions for uplink and downlink. This is because for two independent random variables X andY 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 randomvariables. The above relation will be used to estimate the end-to-end delay distributions, but itmust first be decided what PDF:s are to be convolved. To simply convolve the total (all sessionscombined) uplink and downlink distributions, would not be sufficient to decide what sessions weresatisfied according to Section 5.2, nor is it possible to convolve the uplink and downlink distributionsof every specific PoC call, as there is no coupling between the sessions. The solution will instead beto look at all possible pairs of uplink and downlink sessions, and convolve the delay distributions ofall these. For every pair, it may then be decided whether or not the two involved users would havebeen satisfied if they had actually talked to each other. The algorithm is shown below.

For every session iEstimate uplink PDF f i

UL(x) of session iFor all sessions j 6= i

Estimate downlink PDF f jDL(x) of session j

Calculate end-to-end PDF estimation as f ijE−E(x) = f i

UL(x) ∗ f jDL(x)

Decide whether this combination is satisfiedaccording to Section 5.2

EndEnd

This approximation of the user satisfaction level is valid only if the delays of the two paired sessionsare independent. If the sessions exist in different cell (far enough to not interfere), there will be nodependency, but for sessions in the same cell the situation is different. Such sessions will, if theyexist simultaneously, interfere with each other, and thus there is no guarantee that the delays areindependent. However, the vast majority of the pairs will have sessions in different cells, making theapproximation acceptable.

One may object that it would have been more beneficial to actually model the coupling betweensessions, 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 withinthe same cell or even the same network, but this is what would have been modeled with coupledsessions. Second, the estimation of the end-to-end delay characteristics will be based on much moredata when using all possible combinations of sessions, rather than just looking at two specific sessions.This way, reliable information can be obtained even if the modeled system is relatively small, andthe 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 differenttimes will be convolved. This will model sessions existing at the same time in different cells,as there will be no interference between the sessions.

26

• The approach used will also model sessions existing in different networks. When convolvingdistributions for sessions in different cells distant enough to not interfere, the result can beexpected to be the same as if the sessions existed in different networks. This is of course validonly 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 beN(N − 1) as a session is not combined with itself. There is no need to convolve the downlinkdistribution of session i with the uplink distribution of session j, as this case will already becovered 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 delaysare kept as low as possible. Nevertheless, the delay figures of the system must be interpreted in ameaningful way to be used as a performance measure, which may for example be to investigate theratio of satisfied users. This will be done in this thesis, and is described in Section 5.2. Thus, thedelay characteristics can be seen partly as an auxiliary measure for calculating the satisfied usersratio.

One aim of this thesis is to determine whether it is the uplink or downlink that will be the limitationwhen providing PoC over HSDPA. The uplink and downlink delay characteristics are relevant forinvestigating this, as these will show in what direction the delays first start to increase. If, after anincrease in offered load, the mean delay of, say, the uplink also increases while the downlink meandelay 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 offered load per cell the system can handle before it isoverloaded. The offered load is in this case defined as the number of users in the system, N , seeSection 4.1. To be able to find the cell capacity in terms of users per cell, a criterion for the systemload limit must be defined. As PoC is a (semi) real-time service where in-time delivery of packets isimportant, the criterion will be based primarily on delay, and thus will cell capacity be a function ofdelay. However, the interference levels and code usage of the system will also be taken into account.

5.2.1 Satisfied User Criterion

The criterion for the load limit of the system, i.e. the point at which the system is so loaded thatadditional users will cause overload, is formulated in terms of a satisfied user ratio. Therefore, thenotion of a satisfied user must first be defined.

The voice-carrying packets are, as already described, transmitted regularly with a certain intervaldecided by the number of AMR frames per packet. Also, they must be made available at thereceiving 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 buffer in the receiver, which holds incoming packetsa short time before playing out the contents. It is the offset time, i.e. the time from when thefirst packet was expected to arrive until it is actually played out, that decides exactly how muchdelay variation can be tolerated before the voice quality is decreased. The situation is depicted inFigure 5.1.

If the first voice packet is transmitted at time t0, and the offset of the receiving play-out buffer 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 first three packets arrive in time, while packet4 is not available in the play-out buffer at the time it should be played out.

allowed average end-to-end transmission delay. Consecutive packets are sent with fixed intervals, andthus must also arrive no later than d0 + τpo after they were sent. This indicates that the maximumextra delay allowed, i.e. the maximum jitter, is equal to τpo.

Satisfied users will be those whose probability plate of a late packet is at the most p0, where a packetis late if its delay is more than τpo larger than the allowed average delay d0. The probability of alate packet is hence calculated according to

pilate = Pr[di > d0 + τpo] ≈

nip,late

N ip

where di is the packet delay, nip,late the number of late packets, and N i

p is the total number of packetsfor session i.

Finally, the load limit criterion is defined as follows. The system reaches is maximum load when theratio of satisfied users Qs drops below a certain value q0. Formalized mathematically, the load limitis reached when the inequality

Qs =Ns

N≤ q0

holds. Here Ns is the number of users with pilate ≤ p0, and N is the total number of users.

A minor complication is, that end-to-end distributions are available only for every possible pair ofsessions, as described in Section 5.1.1, and the number of satisfied users Ns can not be calculateddirectly. Instead, it will for every combination of uplink and downlink sessions be decided whetherthe satisfaction criterion is met or not, and the number of “satisfied combinations” will be dividedby the total number of combinations. The load limit criterion then transforms into

Qs ≈ Q′

s =N ′

s

N ′≤ q0

where N ′

s and N ′ denote the number of satisfied combinations and the total number of combinations,respectively.

28

5.2.2 Interference And Code Usage

The delay-based satisfied user criterion is convenient, as it enables comparison of different meansof providing the PoC service, in this case HSDPA versus conventional DCH:s. However, there areproblems 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 limitas long as the system is stable. But if the instantaneous load increases slightly, the interferencelevels may become too high resulting in a situation where power control tries to increase powerto infinity and the system will collapse. Consequently, commercial systems are moderated (usingadmission control) so that the interference levels never become this dangerously high, and this factshould be taken into account when determining the cell capacity in a meaningful way. However, whatinterference levels are acceptable depends on the preferences of the system operator, and no absolutelimit will be assumed here. Instead, the interference levels will simply be measured for every 10-msradio frame (the average value over each frame), and presented together with the satisfied user ratiofor the specific load.

Interference will be monitored only in the uplink, as it can be shown that the downlink is limitedrather by the available codes. The code usage in the downlink will also be monitored, so that it canbe determined whether the cell capacity is code-limited.

Interference is not a clearly defined quantity, but herein it is calculated as the total power received ateach base station, taking into account the path-loss from the UE to the base station. Values for allbase stations are then averaged to a single value for the entire system. The code usage is calculatedas the sum of the inverses of the spreading factors of all channels in a cell (see Section 2.3.1), alsoaveraged over all cells in the system. When the code usage approaches one, the system becomescode-limited.

5.2.3 Cell Capacity Measure

The cell capacity will be measured as the number of users per cell possible to offer to the systembefore Qs drops below the minimum allowed value q0. The same measure will be used regardless ofchannel choice (HS-DSCH/DCH), and to make the comparison fair, the session admission controlfunction will be turned off in the simulations. If session admission control would be active, no newusers would be admitted at a certain load point, in principle regardless of whether they would havebeen satisfied or not. With session admission control disabled, on the other hand, new users willalways be admitted, and at some point Qs will drop too low. This point can be used for setting thesession admission threshold for a real system. The same argument can be applied to link admissioncontrol, and hence this will also be turned off, except for the downlink code usage check. This checkmust 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 thecapacity 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 needsto be set. From Section 5.1.1 it follows that a maximum of 200 ms is assumed to be allowed for theend-to-end radio transmission, and that the offset of the play-out buffer 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 satisfied user ratio, the interference and code usage levels are also presented. Theformer will show whether it is realistic to run the system at the load allowed by the satisfied user ratiocriterion, while the latter will show whether the the system load limit was reached due to downlinkcode shortage. Note also the following. The delay limit d0 + τpo = 300 ms is set with HSDPAin 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 satisfied users sooner than HSDPA with the 300-mstolerance. Thus, it may be interesting to increase the maximum allowed delay when providing PoCover this channel, if in turn the capacity in terms of interference and/or code usage is higher. Thiswill 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 ofhandling. 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 onuser perception, increases its relevance. By using this approach, the cell capacity value hints abouthow 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. Inthis study, the throughput will be measured at the IP layer, i.e. the amount of IP bits per secondtransmitted.

Very straightforwardly, the system throughput is defined as

R =nbits

Tobs

where R is the throughput in bits/s, nbits is the total number of delivered bits, and Tobs is theobserved time period is seconds. Thus, the throughput value will be an average over the duration ofthe whole simulation. Mean throughput is not dependent on packet delay, but is rather a measureof the amount of bits that passed through the system. In addition to total system throughput, theinstantaneous user throughput for every packet will be calculated. In both cases, the uplink anddownlink are kept separate, as there is no meaningful way of combining the throughput informationfor the two cases.

The instantaneous user throughput is calculated for each packet, by dividing the packet length in bitsby 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 userthroughput is different from the instantaneous throughput in the way that it indicates the throughputactually experienced by the user. Not only the link transmission time is included, but also any extradelay 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 othertwo presented performance measures, it is still relevant. As the throughput is measured at the IPlayer, the value reveals how well the channel is utilized. As an example, HSDPA is designed to allowa 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 broaderchannel would decrease delays.

30

Chapter 6

Simulation

The simulations made in this study were carried out using an HSDPA capable WCDMA simulatordeveloped at Ericsson Research. The simulator is written in Matlab and covers all UTRAN func-tionality from radio link characteristics (e.g. shadow and multi-path fading) to the RLC and TCPprotocols.

An entire WCDMA system, consisting of a number of cells, is simulated and thus modeling ofboth inter-cell interference and soft/softer hand-over is included. Simulated is also the movement ofindividual 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 channelquality estimation and power control, to RLC and TCP. Also, some models for traffic generation areincluded, among which are standard DTX speech traffic and best-effort TCP/IP traffic produced byinternet users. Any modeling of PoC traffic is not present by default.

The main simulation loop lasts for one radio frame (10 ms), and in turn contains an HSDPA TTI (2ms) loop. Finally, the HSDPA TTI loop contains a slot-level loop, so that there are 15 slots for eachradio frame. The slot level is the maximum time resolution of the simulator.

6.1 Simulator Model

6.1.1 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 Bper cell and thus one cell per site. In the case of three-sector antennas, one Node B controls threecells which together constitute a site. Figure 6.1 illustrates the difference. In the simulations, thethree-sector site alternative will be used, as this is the most commonly used configuration.

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 experiencean interference situation different from cells inside the cell pattern. To alleviate these problems atthe boundaries, a wrapping technique is used where the cell pattern is wrapped around in a certainmanner so that there are no borders. This way, cells at, say, the south border of the system willexperience interference from the cells at the north border, as if were they neighbors, and a fairlylarge 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 Rayleighdistributed 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 thevelocity and position are calculated according to Newton’s laws of motion. This is a common meansof 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 moreconventional 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 trans-mitter 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 factoris drawn from a log-normal distribution, so that it is normally distributed when measured indecibels.

• Multi-path Fading. The radio signal may be reflected by buildings and other objects, so thatmultiple copies of the signal with varying delay reaches the receiver. The multi-path fadingfactor is taken from a precomputed map, which is indexed by the cumulative moved distance ofthe user. Different maps exist for different channel models, and supported are the ITU modelsIndoor A, Vehicular A and Pedestrian A, as well as the 3GPP models Typical Urban and RuralArea.

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 specified by 3GPP and describedin 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 theCIR target set by the outer loop power control is maintained. All downlink power remainingafter 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 powerusage for HSDPA is configurable, but this limitation will not be used in the simulations.

• Admission Control. For the reasons described in Chapter 5, admission control will only considerthe downlink code usage. Nevertheless, interference will be logged to be able to interpret theresults at high loads.

• HSDPA scheduling. This is an important part of the simulations, since the performance andsuitability of the scheduler have significant impact on delay. The scheduling policy used willbe 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 timet. Hence, users with long periods of poor channel conditions (low data rate) will eventually beprioritized.

• Retransmission. The concept of parallel ARQ instances is included, and a default setting of sixparallel instances is used. The hybrid ARQ protocol retransmits data a configurable numberof times, and if the receiver still was incapable of decoding the data retransmission at the RLClayer is flagged. For non-HSDPA channels, retransmission is handled only by the RLC.

• Channel Quality Estimation. Channel quality is estimated from the CIR of the CPiCH, andused for the scheduling decision and Modulation Code Scheme (MCS) choice. A measurementerror 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 peruser, the actual bit patterns are not considered. In this section, it will be described how bits travelthrough the simulated system, and where the delays occur.

At every 10-ms radio frame, the traffic models used (may be several) generate an amount of bitsfor every user of the specific service. In the case of PoC, bits are generated every 20nAMR ms withnAMR AMR frames per RTP packet, but as users start transmitting at different times, it is likelythat some users transmit in every radio frame. The bits from the traffic model are stored in uplinkand downlink transmission buffers, and moved to the respective reception buffers as soon as theyare correctly received. The traffic model function can then, every time it is invoked, investigate theamount of bits delivered for each user and calculate the delay.

Fixed Delays

Regardless of channel type (DCH or HS-DSCH) there is always a fixed configurable channel setuptime. In the simulations, this setup time is assumed to be 400 ms, but since only initial SIP signalingis sent during this time, the delay of voice data will not be affected.

The minimum delay experienced by a packet is primarily decided by the TTI length, which definesthe 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 increasesto 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 fixed delay is always added to every packet to model the RLC processingdelay. This delay is chosen according to knowledge and observations of RLC operation, and is not

33

Channel Uplink Downlink

dTTI1 RLC Total dTTI RLC Total

16/HS-DSCH 60 ms 50 ms 110 ms 10 ms 30 ms 40 ms64/HS-DSCH 20 ms 50 ms 70 ms 10 ms 30 ms 40 ms16/16 60 ms 50 ms 110 ms 60 ms 40 ms 100 ms

Table 6.1: Fixed delays modeled for the different channels.

symmetric for up- and downlink. For the HS-DSCH, the fixed RLC delay is set to 3 radio frames (30ms), while the corresponding value for the 16-kbps DCH downlink is 4 radio frames (40 ms). Theuplink 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 fixed delays experienced by a data packet for three cases: HSDPA with16-kbps uplink, HSDPA with 64-kbps uplink and the 16-kbps dedicated channel in both downlinkand uplink. The delays consider the case nAMR = 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 = 70ms for the two cases respectively, when including the RLC delay. Note however that the averagebitrate for the 16-kbps channel is sufficient for PoC.

Variable Delays

The first source of potential extra delay is the scheduler. Bits are queued until scheduled for trans-mission, and if a user has poor channel conditions and/or the system is heavily loaded, this delaymay be significant. However, there is no fixed processing delay modeled for the scheduler, and atmoderate load data is scheduled for transmission immediately.

The next possible contribution to extra delay occurs in the hybrid ARQ function, when packets withnegative 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 traffic generating function (in which arriving data packets are time stampedand logged) is one 10-ms radio frame, which means that hybrid ARQ retransmission on the borderbetween two radio frames may be interpreted as a delay of 10 ms, while retransmission completelyinside a radio frame gives the impression of zero extra delay. This is due to the architecture ofthe simulator, not the real WCDMA system, but when calculating the average delay, the effect issmoothed out.

The above two delays are valid only for HSDPA, while the extra delay due to RLC retransmission iscommon to all channel types. The RLC protocol assures retransmission of negatively acknowledgedpackets, which may be a time consuming process for channels with relatively long TTI. Note thatRLC 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 inthis thesis, AM is used and a maximum of five hybrid ARQ retransmissions are allowed before RLCretransmission is done.

1Delay caused by the TTI length.

34

6.2 Simulation Setup

6.2.1 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 thedifferences and potential advantages. As PoC is a relatively narrow-band service (8.88 kbps with5.15 kbps codec rate and nAMR = 5), the bitrate for the DCH is chosen to be 16 kbps. The reasonfor not choosing an even lower bitrate is that the PoC traffic is packetized, and it is desirable notto use too many TTI:s for every packet in order to keep transmission delays low. With nAMR = 5each IP packet becomes 888 bits long, and can be transmitted in three TTI:s with one 320-bit RLCpayload per TTI. The 320-bit RLC payload size is a configuration parameter, see Section 6.2.2. Witha lower bitrate (or larger nAMR), additional TTI:s would have been necessary, each increasing thedelay with 20 ms in each direction, according to Table 6.1. The 16-kbps DCH is also used for theHSDPA uplink, to make the comparison fair.

The first 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 bottleneck as a relatively limited number of 64-kbps channels may be set up per cell. Nevertheless, the64-kbps uplink is the only available choice if implementing PoC over HSDPA today, and for thisreason simulations are made also for this case. Furthermore, the transmission delay is lower with the64-kbps alternative, as only one TTI is needed to transmit each voice packet. This is because four320-bit RLC payloads (1280 bits) are transmitted in each TTI.

For both the HSDPA and the pure DCH cases, repeated simulations are made for different offeredloads (users/cell) in order to find the system load limit and values for the performance measuresdefined in Chapter 5. For the load sweep, the number of AMR frames per packet is set to nAMR = 5and the number of code-multiplexed users for HSDPA is set to four. In order to investigate the impacton the results of these parameters, simulations are also made using other values. These simulationsare made only at selected load points and for the following cases.

• HSDPA with four users code-multiplexed and nAMR = 1. In this case the 64-kbps uplink isused, as the average bitrate is 21.5 kbps, i.e. greater than 16 kbps (see Section 3.4).

• HSDPA with four users code-multiplexed, nAMR = 5 and the 64-kbps uplink. This is to isolatethe effect of varying nAMR.

Note finally, that the only traffic present in the simulations is PoC traffic, i.e. there is no mixturewith other types of traffic. In real networks this will obviously not be the case, but evaluating andcomparing the PoC performance is greatly simplified using this approach. This is because it is, in amixed traffic situation, difficult to determine whether e.g. delays occur as a result of the PoC trafficpattern, or because other traffic is limiting the system capacity. Also, simulating only one service ata time, enables fair comparison of different services.

6.2.2 RAB Configuration

The general characteristics of the RAB:s used in the simulations are given below, while the configu-ration 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 includedin the 3GPP specification of tested RAB:s [21] but with a TTI of 40 ms, and hence the specificationparameters are adjusted to compensate for the shorter TTI. The reason for changing the TTI is thesemi-realtime characteristics of PoC; a 40 ms TTI would give relatively large delays in general andfor retransmissions in particular. The interleaving gains are on the other hand larger, but low delayis considered more important for PoC.

Non-compressed mode is used for both uplink and downlink, which means that all 15 slots aretransmitted in every radio frame. Also, the acknowledged mode (AM) is used for RLC, which meansthat blocks transmitted in error will be retransmitted. Consequently, there will be no packet lossdue to transmission errors (assuming block errors can always be detected).

HSDPA

The 16-kbps uplink DCH used with HSDPA shares configuration with the above described DCH.The 64-kbps uplink alternative has a similar configuration, with the RLC in acknowledged mode,but obviously adjusted to provide the desired bitrate. The HSDPA downlink, the HS-DSCH, useseight 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 aDCH used for carrying control information.The SRB:s are modeled in the sense that they contributeto power consumption and interference, but no data transmission is modeled. The SRB:s have astandard configuration with 40-ms TTI.

36

Chapter 7

Results

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

7.1 HSDPA

7.1.1 16-kbps Uplink

As indicated, HSDPA simulations were carried out for a number of cases, but a full load sweep wasdone only for the case

• 16-kbps uplink,

• 4 users code multiplexed and

• nAMR = 5,

with offered 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. Themean is taken over all finished packets. As expected, the mean delays for light loads are close to 40ms and 110 ms for the HS-DSCH and uplink DCH respectively, but in the region of 65 users/celldelays start growing. As can be seen, loads above 80 users/cell give average end-to-end delays ofmore 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 difference being a multiplicative factor. One may haveexpected the delays to be uncorrelated, but the effect can be explained in the following way. Whena 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 traffic may be only controlsignaling. Hence, it is not possible to assign only a downlink or uplink to a user, and completelyexclude 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 issetup 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 iscaused by the fact that sessions that were denied links are included in the mean. Such sessions will,due to the architecture of the traffic model and the absence of session admission control, generatepackets regardless of whether a link is present or not, and experience very large delays if a long timeelapses before a link is granted.

10 20 30 40 50 60 70 80 900

50

100

150

200

250

300

350

400

450

500

Load [users/cell]

Mea

n de

lay

[ms]

End−to−endHS−DSCHUplink DCH

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 ata load of 65 users/cell. Packets belonging to all sessions are included. As can be seen, a vast majorityof the packets experience a delay lower than the 300 ms limit, but there is also a considerable amountexperiencing larger delays. This is due to the code shortage, and contributes to the non-satisfieduser ratio of 5.2% which is seen in Figure 7.3.

0 50 100 150 200 250 300 350 400 450 5000

0.5

1

Uplink (16−kbps DCH)

ms

Rat

io

0 50 100 150 200 250 300 350 400 450 5000

0.5

1

Downlink (HS−DSCH)

ms

Rat

io

0 50 100 150 200 250 300 350 400 450 5000

0.5

1

End−to−end

ms

Rat

io

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 definition in Chapter 5, is shown in Figure 7.3. Theratio of satisfied users is very close to one for moderate loads, and starts dropping approximately atthe same point where the delays start growing. This is what can be expected, since the satisfied usercriterion is based on delay. Depending on what minimum level of satisfied users can be accepted, itis seen that the capacity falls in the region of 60 to 68 users/cell.

At a load of 90 users/cell, the satisfied user ratio has dropped almost to zero. This is because themean end-to-end delay at this point by far exceeds 300 ms, which is the point at which packets areconsidered too late. The 90-users/cell load case is not included in the graph for clarity reasons.

10 20 30 40 50 60 70 80 900.7

0.75

0.8

0.85

0.9

0.95

1

1.05

Load [users/cell]

Sat

isfie

d U

ser

Rat

io

Figure 7.3: Satisfied user ratio for HSDPA with 16-kbps uplink.

To illustrate the difference between satisfied and non-satisfied users, delay distributions for the twocases are plotted in Figure 7.4. The difference is rather limited, but the delay spread is clearly largerfor the non-satisfied 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-satisfied users there exists packets with far higher delays.

0 100 200 300 400 5000

0.2

0.4

0.6

0.8

1

ms

Rat

io

Non−satisfied users (end−to−end)

0 100 200 300 400 5000

0.2

0.4

0.6

0.8

1

ms

Rat

io

Satisfied users (end−to−end)

Figure 7.4: Delay distributions for all non-satisfied and all satisfied users at 65 users/cell. Dottedlines 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 anduplink interference have been logged and are shown in Figure 7.5. The mean and maximum valuesthat are shown are calculated over all 36 simulated cells, meaning than when the mean code usagereaches one, the code resource is practically exhausted in all cells. Apparently, this happens atapproximately 80 users/cell, which explains the increase in delay at this load point. When no morecodes are available, new links cannot be set up, and it may be argued that delays should increase toinfinity1. This is the case for sessions that were denied a link, but as it is the average delays that areplotted in Figure 7.1, i.e. including both sessions granted links and sessions denied links, the curveis smooth.

The reason for the shortage of codes is the SRB:s carried over associated DCH:s of spreading factor256 that are set up in the downlink for every HSDPA user. The HS-DSCH is assigned half the codetree (8/16), five SF 128 channels are reserved for common control channels, and four SF 128 channelsneed to be set up to control the HS-DSCH code multiplexing. Thus,

cSRB = 1 −( 8

16+

5 + 4

128

)

= 0.430

is the ratio of the code tree made available to the associated DCH:s. When assuming 35% of theusers in soft hand-over, this is sufficient for

nSRB = 256 · cSRB/1.35 ≈ 82

channels and hence approximately 82 users/cell, a result which apparently is confirmed by the sim-ulations.

The uplink interference imposes a somewhat softer limitation than the code usage, but on the otherhand delays for all sessions will start growing as interference increases. There is however no sharpedge, 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 interpretationmust 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 behaviormay be that the curve should stabilize because no more links are set up. The effect can be explainedby the traffic model limitation highlighted in Chapter 4, i.e. that bits are generated even if thesession was not granted a link, and buffered until a link actually could be set up. Thus, transmissionwill be made continuously for these sessions until the stored buffer if empty, utilizing the full bitratecapacity of the link instead of the average 8.88 kbps used by sessions that did not have to wait. Athigh enough loads, nearly all sessions will have to wait for a link to become free and nearly all linkswill be utilized fully, which explains an increase in uplink interference even if the number of activelinks is constant. Note that this effect is a consequence of the traffic model and the deactivatedsession admission control; the interference figures above the code shortage point have no relevanceto real systems.

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

40

0 20 40 60 80 100 120 1400.6

0.7

0.8

0.9

1

1.1Downlink code usage for HSDPA

Load [users/cell]

Cod

e us

age

MeanMax

0 20 40 60 80 100 120 1400

2

4

6

8

10

12Uplink interference for HSDPA (16−kbps uplink)

Load [users/cell]

Inte

rfer

ence

[dB

]

MeanMax

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 considerablyhigher than the uplink DCH, but the situation changes drastically after the downlink code limit hasbeen reached. Instantaneous user throughput is calculated only for delivered packets and so onemay think that it would remain unchanged even when the code resource is exhausted. However, thesession admission control was disabled in the simulations, and thus sessions will be admitted evenif no link can be set up. This means that some sessions have to wait for an active session to endbefore transmission can begin, and the packets generated prior to link setup will experience very largedelays. In real systems such situations are prohibited by the use of session admission thresholds, butit 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 growup to a load of 120 users/cell. Even if the HS-DSCH is limited by code, the capacity in bits persecond for links that could be setup is not reached. Rather, it is the uplink that limits in the caseof mean throughput, which can be seen in the interference plot of Figure 7.5. At 140 users/cell theuplink interference has peaks above 10 dB, certainly causing excessive RLC retransmissions.

41

0 20 40 60 80 100 120 1400

100

200

300

400

500

Load [users/cell]M

ean

Thr

ough

put [

kbps

/cel

l]

DownlinkUplink

0 20 40 60 80 100 120 1400

5

10

15

20

25

Load [users/cell]

Mea

n In

st U

ser

Thr

ough

put [

kbps

]

DownlinkUplink

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 aresufficient to isolate the differences compared to the 16-kbps uplink. All parameters except the uplinkconfiguration were unchanged, i.e.

• 64-kbps uplink,

• 4 users code multiplexed and

• nAMR = 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 meanuplink delays are approximately 70 ms rather than 110 ms, as expected. This suggests that the changeof uplink impacts performance only by decreasing delays, while the capacity remains unchanged.

42

50 55 60 65 70 75 80 850

50

100

150

200

250

300

350

400

450

500

Load [users/cell]

Mea

n de

lay

[ms]

End−to−endHS−DSCHUplink DCH

Figure 7.7: Mean delay for HSDPA with 64-kbps uplink.

The satisfied user ratio is shown in Figure 7.8, indicating a capacity of approximately 65 users/cellwith 95% satisfied users. This is practically identical to the 16-kbps uplink result.

50 55 60 65 70 75 80 850.7

0.75

0.8

0.85

0.9

0.95

1

1.05

Load [users/cell]

Sat

isfie

d U

ser

Rat

io

Figure 7.8: Satisfied 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 uplinkcase, which illustrates the main difference when using the 64-kbps uplink. The interference reachesup to 8 dB already at 60 users/cell, which should be compared to approximately 3 dB for the 16-kbpscase. At 85 users/cell the interference levels are unreasonably high and it would not be realistic torun a system under these conditions.

43

The reason that the high uplink interference does not noticeably impact the delay curves, is likely tobe that the capacity already is limited by the downlink code shortage. Even if links that are setupexperience extra delay due to the interference, this is shadowed by the large delays occurring becauseof the limited code resource. However, if the downlink code usage could be decreased, the uplinkinterference would become significant and thus there is reason to pay attention even if the impact inthis specific case is limited.

60 65 70 75 80 850.9

0.92

0.94

0.96

0.98

1

1.02Downlink code usage for HSDPA

Load [users/cell]

Cod

e us

age

MeanMax

60 65 70 75 80 855

10

15

20

25

30

35Uplink interference for HSDPA (64−kbps uplink)

Load [users/cell]

Inte

rfer

ence

[dB

]

MeanMax

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 issaturated already at 85 users/cell compared to 140 users/cell in the 16-kbps uplink case. The reasonis 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 the16-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 thedownlink code limitation and the uplink interference can be seen as a decrease in instantaneous userthroughput.

44

50 55 60 65 70 75 80 85200

250

300

350

Load [users/cell]M

ean

Thr

ough

put [

kbps

/cel

l]

DownlinkUplink

50 55 60 65 70 75 80 8510

12

14

16

18

20

Load [users/cell]

Mea

n In

st U

ser

Thr

ough

put [

kbps

]

DownlinkUplink

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

7.1.3 Varying Number of AMR Frames

The effect of using only one AMR frame per packet instead of the usual five, was studied for theloads 30 to 70 users/cell. To handle the higher bitrate, the 64-kbps uplink was used, resulting in thefollowing set of main parameters.

• 64-kbps uplink,

• 4 users code multiplexed and

• nAMR = 1.

Delay and User Satisfaction

Mean delays for uplink and downlink, and mean end-to-end delays are shown in Figure 7.11. Ap-parently, the higher bitrate rendered for the case nAMR = 1 causes problems already at a load of30 to 40 users/cell. Furthermore, the delay at moderate load is higher than for the comparablecase nAMR = 5 and 64-kbps uplink shown in Figure 7.7. Consequently, the expected gain of usingnAMR = 1 — to decrease the delays — is absent.

The uplink and downlink delay curves are not correlated, which is reasonable since there is nocode limitation triggering the link admission control. While the uplink delay characteristics can beexplained from the interference plot in Figure 7.13, the cause of the HS-DSCH delay increase isless obvious. The probable reason is the relatively high bitrate from many simultaneous users, whoeach generate 440 bits every 20 ms. With four users code multiplexed and 30 users/cell, on average30/4 = 7.5 HS-DSCH TTI:s are necessary for the transmission, rendering a maximum queuing timeof 7.5 · 2 = 15 ms. Taking into account also the random variations in session starting time, it is notunreasonable 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 thefurther delay increase that is seen at this load.

30 35 40 45 50 55 60 65 700

50

100

150

200

250

300

350

400

450

500

Load [users/cell]

Mea

n de

lay

[ms]

End−to−endHS−DSCHUplink DCH

Figure 7.11: Mean delay for HSDPA with 64-kbps uplink and namr = 1.

The large delays impact also the satisfied user ratio plot, which is shown in Figure 7.12. As can beseen, no more than approximately 30 users/cell can be handled before the satisfied user ratio dropstoo low. Even at this relatively light load, only 94% of the users are satisfied.

30 35 40 45 50 55 60 65 700.7

0.75

0.8

0.85

0.9

0.95

1

1.05

Load [users/cell]

Sat

isfie

d U

ser

Rat

io

Figure 7.12: Satisfied 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 anduplink interference levels. Close to a load of 50 users/cell, the uplink interference grows unreasonablylarge, 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 limitationless important.

30 35 40 45 50 55 60 65 700.7

0.8

0.9

1

1.1Downlink code usage for HSDPA

Load [users/cell]

Cod

e us

age

MeanMax

30 35 40 45 50 55 60 65 700

10

20

30

40Uplink interference for HSDPA (64−kbps uplink)

Load [users/cell]

Inte

rfer

ence

[dB

]

MeanMax

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

Throughput

The throughput plots shown in Figure 7.14 further confirm that the uplink capacity is reached at 50users/cell. It is seen that the mean throughput per cell peaks at this load point, and that also themean instantaneous user throughput starts decreasing here.

30 35 40 45 50 55 60 65 70250

300

350

400

450

500

Load [users/cell]

Mea

n T

hrou

ghpu

t [kb

ps/c

ell]

DownlinkUplink

30 35 40 45 50 55 60 65 700

2

4

6

8

10

Load [users/cell]

Mea

n In

st U

ser

Thr

ough

put [

kbps

]

DownlinkUplink

Figure 7.14: Mean throughput per cell and mean instantaneous user throughput for HSDPA with64-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 DCHlink in both uplink and downlink. A load sweep ranging from 10 to 80 users/cell was made, withmain parameters as below.

• 16-kbps DCH uplink,

• 16-kbps DCH downlink and

• nAMR = 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. Thisindicates a somewhat higher capacity than in the HSDPA case, where delays started increasing inthe region of 65 users/cell. On the other hand, the delays at moderate loads are higher than forHSDPA, due to the architecture of the WCDMA dedicated channels. Note also that delays are trulyconstant before approaching the overload point, while the HSDPA delay curve in Figure 7.1 havea slight positive slope. This illustrates the WCDMA functionality to maintain QoS for admitteddedicated channels, meaning that if a link actually is set up, the quality is equally good regardless ofnumber of other links present. In the HS-DSCH case, on the other hand, delays will slowly increasewith higher loads, due to the scheduler.

10 20 30 40 50 60 70 800

50

100

150

200

250

300

350

400

450

500

Load [users/cell]

Mea

n de

lay

[ms]

End−to−endDownlinkUplink

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 beseen, the delay spread is limited, with only a small ratio of packets experiencing delays other thanthe minimum of 110/100 ms for uplink/downlink. The cause for the delays for some packets is likelyto be RLC retransmissions, which may increase delays by several hundreds of milliseconds in somecases. Also, when a negative acknowledgment is to be transmitted after a decoding failure, user datamay need to be queued at the RLC layer in order to quickly serve the retransmission request.

48

0 50 100 150 200 250 300 350 400 450 5000

0.5

1

Uplink (16−kbps DCH)

ms

Rat

io

0 50 100 150 200 250 300 350 400 450 5000

0.5

1

Downlink (16−kbps DCH)

ms

Rat

io

0 50 100 150 200 250 300 350 400 450 5000

0.5

1

End−to−end

ms

Rat

io

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 satisfied user ratio, and as can be seen approximately 94% of the usersare satisfied with the delay limit set to 300 ms, i.e. the same as was used in the HSDPA casedepicted in Figure 7.3. A further comparison of the two cases shows that the ratio of satisfied usersstarts dropping around 60 users/cell for both HSDPA and pure DCH, which may be a bit surprisingregarding that delays increase at a higher load in the DCH case. However, the DCH delays are fromthe beginning closer to the 300-ms limit, and thus only a small increase is necessary for users tobecome non-satisfied.

Neither 99% nor 95% satisfied users can be reached with a delay limit of 300 ms, while the capacitywhen accepting only 90% satisfied users is approximately 73 users/cell. This is 7% more than in theHSDPA case, but on the other hand 90% satisfied users is probably too low. However, as stated below,increasing the delay limit to 350 ms dramatically changes the situation, indicating that capacity interms of satisfied users possibly is higher for DCH than for HSDPA if the delay requirements can beslightly relaxed.

49

10 20 30 40 50 60 70 800.7

0.75

0.8

0.85

0.9

0.95

1

1.05

Load [users/cell]

Sat

isfie

d U

ser

Rat

io

Figure 7.17: Satisfied 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 Sec-tion 6.1.4), makes the comparison of capacity in terms of user satisfaction somewhat unfair. If slightlylarger delays can be tolerated, the satisfied user ratio can be expected to reach the same levels as forHSDPA at light loads, i.e. close to 100%. Renewed calculations show that relaxing the delay limitto 350 ms is sufficient 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 in99.7% satisfied users. For reasons already given, the result can be expected to be the same for otherloads prior to the overload point.

Code Usage and Interference

Figure 7.18 shows the downlink code usage and uplink interference, and apparently the code resourceis exhausted at approximately 80 users/cell. The delay plot of Figure 7.15 indicates a situation ofcomplete overload at the same point, and the delay increase is quicker than in the HS-DSCH case.One explanation for the difference may be that every new user in the DCH case requires a SF128 downlink, while only a SF 256 SRB downlink is required in the HS-DSCH case. Hence theprobability of being able to set up a new link when the code resource is almost exhausted, is largerin 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 plottedin 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 notfully utilized at 80 users/cell (which it is in the HSDPA case), still allowing for new uplinks to beset up at this load. This, in conjunction with the fact that some cells probably already suffer fromcode shortage, may explain the increase also in mean uplink interference. The cells in which thecode resource is exhausted will contribute to the interference increase for the same reason as in theHSDPA case, i.e. that sessions denied links will buffer bits and transmit using full capacity when alink is granted.

50

10 20 30 40 50 60 70 800

0.2

0.4

0.6

0.8

1

Downlink code usage

Load [users/cell]

Cod

e us

age

MeanMax

10 20 30 40 50 60 70 800

2

4

6

8

10

12Uplink interference

Load [users/cell]

Inte

rfer

ence

[dB

]

MeanMax

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 tothe overload point at 80 users/cell, and then rapidly drops. The instantaneous user throughput issomewhat lower for the uplink than for the downlink, and the probable reason is that retransmissionsare more common in the uplink due to higher interference levels. This can be seen also from thedelay 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 highuplink interference at this point. The curves are aligned for the reason already described, i.e. theneed to set up both uplink and downlink.

51

10 20 30 40 50 60 70 800

100

200

300

400

Load [users/cell]

Mea

n T

hrou

ghpu

t [kb

ps/c

ell]

DownlinkUplink

10 20 30 40 50 60 70 805

6

7

8

9

Load [users/cell]

Mea

n In

st U

ser

Thr

ough

put [

kbps

]

DownlinkUplink

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

Capacity

To enable comparison with the HSDPA case, the cell capacity in terms of satisfied users is shown inFigure 7.20. It is seen that neither 99% nor 95% satisfied users can be reached with a delay limit of300 ms, and that the capacity when accepting only 90% satisfied users is approximately 73 users/cell.This is 7% more than in the HSDPA case, but on the other hand 90% satisfied users is probably toolow. However, it was stated above that increasing the delay limit to 350 ms dramatically changesthe situation, indicating that capacity in terms of satisfied users possibly is higher for DCH than forHSDPA provided that the delay requirements can be slightly relaxed.

This standpoint is supported also when looking at the 94% percent satisfied user ratio. At this level,65 users/cell can be handled, which is equally many as for HSDPA with 95% of the users satisfied.

10 20 30 40 50 60 70 800.7

0.75

0.8

0.85

0.9

0.95

1

1.05

Load [users/cell]

Sat

isfie

d U

ser

Rat

io

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

52

Chapter 8

Conclusions

The main issue addressed in this study is how well the PoC service can be provided over HSDPA, andit can be concluded that with the performance measures used, approximately 65 users/cell can beserved with acceptable quality. The mean delay is in the region of 40 ms for the HS-DSCH downlinkand 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 limitingfactor rather than the high-bitrate HS-DSCH, but due to the large amount of users, the downlinkcode resource is exhausted by the many associated SRB:s. In the simulations, half the code treewas assigned to the HS-DSCH, but there is of course nothing that prevents this ratio from beingdecreased. In the case of PoC, it is probably beneficial to use a smaller ratio of the code tree for theHS-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 utilizedanyway.

When using the 64-kbps uplink, performance is still limited by the downlink code shortage, butat approximately the same load point uplink interference starts growing dangerously high. Thus,assigning fewer codes to the HS-DSCH will have no effect here, as the uplink then will limit instead.The 16-kbps uplink, on the other hand, does not suffer 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 isthe most suitable choice for PoC, and that there are no technical arguments for using the 64-kbpsalternative.

As long as the only traffic present is PoC, and there is no traffic carried on channels other thanHSDPA, the 64-kbps uplink can be used, but when other traffic exists also, the uplink interferencewill be a problem much earlier than the downlink code usage for HSDPA. Hence, the 64-kbps uplinkis 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 PoCtraffic, so that interference is kept to a minimum. Bitrate is not a major limitation for PoC, so theaim should be to maximize the number of users possible to serve. Thus, the 16-kbps DCH usedin this study is a suitable choice. The bitrate should however probably not be chosen any lower,as the packetized PoC traffic may require bitrates higher than the average 8.88 kbps at some timeinstants. With too low bitrate margins, there is a risk for increased delays when many packets arrivesimultaneously.

Except the code limitation problem for HSDPA, the results imply a limitation in the scheduler whenmany users generate packets with short intervals. This is seen from the simulations with nAMR = 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 forserving 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 forthe 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 bea better choice to use HSDPA for PoC if the code allocation problem could be alleviated. For theDCH case, nothing can be done about the code shortage, since every link requires a fixed ratio of thecode tree and there is no or little scope for a decrease of bitrate. Furthermore, it may be a waste ofresources to use DCH channels for PoC, as these probably are better used for truly real-time servicesas conventional voice conversations. The HS-DSCH, on the other hand, will have capacity left forother 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, butthat there is a code shortage problem that needs to be addressed. The gain compared to commonDCH:s is limited and consists mainly of slightly lower delays. It is, however, possibly a gain in itselfto 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 codesto 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 moreassociated DCH:s then could be set up while the HS-DSCH bitrate still would be sufficient for PoC.Thus, new simulations are necessary to investigate whether this is actually the case, and what otherfactors may become limiting. It must also be taken into account that decreasing the number of codesassigned to the HS-DSCH and consequently the bitrate of the channel, will affect also other servicescarried over HSDPA.

Another approach to improving the HSDPA performance, is to investigate the possibility to decreasethe control signaling overhead imposed by the associated DCH:s. These links are today of spreadingfactor 256, but if the control signaling could be decreased somehow, it may be possible to use SF 512instead. This would considerably improve capacity.

Finally, it should be investigated what can be done to decrease the large protocol overhead that ispresent in PoC due to the use of IP. With five AMR frames per packet, nearly half the transmittedbits are protocol headers, which may be a waste of resources. On the other hand, the PoC concepthas the advantage of using standard internet protocols, which surely simplifies the interfaces betweendifferent networks.

One way to decrease the overhead is to make use of a header compression scheme such as RobustHeader Compression (ROHC), which operates on all protocol headers down to the IP layer andtransmits only the header changes between consecutive packets. It is of interest to study the effectof such a technique in the PoC case, to see what performance gain can be achieved and if any newissues arise. A more straightforward method of reducing the protocol overhead is to increase thenumber of AMR frames bundled in each packet. Again, it should be investigated how this affectscapacity and performance in general, and in particular what the impact is on mean delay.

54

References

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

[2] R Cuny, A Lakaniemi, VoIP in 3G Networks: An End-to-End Quality of Service Analysis, The57th 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 theRobust 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 Confer-ence on Advanced Information Networking and Applications, 2003

[5] A Schneider, T Ley, Enhanced Voice over IP Support in GPRS and EGPRS, IEEE WirelessCommunications and Networking Conference, vol 2, pp 803-808, 2000

[6] E O’Regan, D Pesch, Performance Estimation of a SIP based Push-to-Talk Service for 3GNetworks, 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 Evolutionof WCDMA, IEEE International Symposium on Personal Indoor and Mobile Radio Communi-cations, vol 2 pp G27-31, 2001

[8] T E Kolding, K I Pedersen, J Wigard, F Fredriksen, P E Mogensen, High Speed Downlink PacketAccess: 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 HS-DSCH System Performance, The 57th IEEE Semiannual Vehicular Technology Conference, vol4 pp 2172-2176, 2003

[10] E Dahlman, P Beming, J Knutsson, F Ovesjo, M Persson, C Roobol, WCDMA - The Ra-dio Interface for Future Mobile Multimedia Communications , IEEE Transactions on vehiculartechnology, 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, ESchooler, SIP: Session Initiation Protocol, IETF RFC 3261, 2002

55

[17] H Schulzrinne, S Casner, R Frederick, V Jacobson, RTP: A Transport Protocol for Real-TimeApplications, IETF RFC 3550, 2003

[18] Comneon, Ericsson, Motorola, Nokia, Siemens, Push-to-Talk over Cellular; Architecture; PoCRelease 2.0, OMA Specification, 2004

[19] Comneon, Ericsson, Motorola, Nokia, Siemens, Push-to-Talk over Cellular User Plane; Trans-port Protocols; PoC Release 2.0, OMA Specification, 2004

[20] Comneon, Ericsson, Motorola, Nokia, Siemens, Push-to-Talk over Cellular User Plane; Trans-port Protocols; PoC Release 2.0, OMA Specification, 2004

[21] 3rd Generation Partnership Project, 3GPP TS 34.108 V5.2.0, 3GPP Specification, 2004

[22] 3rd Generation Partnership Project, 3GPP TS 25.211 V6.1.0, 3GPP Specification, 2004

[23] 3rd Generation Partnership Project, 3GPP TR 21.01U, 3GPP/ETSI Specification, 1997

[24] 3rd Generation Partnership Project, 3GPP TS 25.308 V6.1.0, 3GPP Specification, 2004

56

Appendix A

Channel Configurations

Listed below are the configuration parameters used for the simulated channels.

HS-DSCH

Parameter Value Comment

Total HSDPA codes 8 Total number of codes (SF 16) used for HSDPAMax. code multiplexing 4 Number of code multiplexed users sharing a TTI.Use 16QAM Yes Whether to use the 16QAM modulation scheme.Max. power 16 W Maximum power used for HSDPA.TTI length 2 ms Fixed for HS-DSCHHARQ queues 6 Number of parallel hybrid ARQ queues.Max. attempts 5 Hybrid ARQ retransmission attempts before sending

NAK to RLC.HARQ type CC Hybrid ARQ type used. Chase Combining (CC) or

Incremental Redundancy (IR).Scheduling Policy PF Scheduling policy. See Section 6.1.3.

64-kbps DCH Uplink

Parameter Value Comment

RLC payload size 320 Number of bits in the RLC payloadin transport blockTransport block size 336 Total L1 transport block size, including header

RLC and MAC headerBLER target 0.01 Target Block Error Rate for outer loop power controlTPC bits/time slot 2 Slot format #0, see [22]TTI length 20 ms Design parameter, see aboveMax. transport blocks 4 Controls the bitrate, four 320-bit RLCper TTI PDU:s in 20 ms renders a bitrate of 64 kbpsPdata/Pcontrol 5.5 dB Power used for physical data channel divided by

power used for physical control channel.

57

16-kbps DCH Uplink

Parameter Value Comment

RLC payload size 320 Number of bits in the RLC payloadin transport blockTransport block size Total L1 transport block size, including RLC

336 and MAC headerBLER target 0.01 Target Block Error Rate for outer loop power controlTPC bits/time slot 2 DPCCH slot format #0, see [22]TTI length 20 ms Design parameter, see aboveMax. transport blocks 1 Controls the bitrate, one 320-bit RLCper TTI PDU in 20 ms renders a bitrate of 16 kbpsPdata/Pcontrol 2.7 dB Power used for physical data channel divided by

power used for physical control channel.

16-kbps DCH Downlink

Parameter Value Comment

RLC payload size 320 Number of bits in the RLC payloadin transport blockTransport block size 336 Total L1 transport block size, including

RLC and MAC header.Spreading factor 128 Gives approximately 25% puncturingPilot bits/time slot 4 Slot format #9, see [22]TPC bits/time slot 2 Slot format #9, see [22]TTI length 20 ms Design parameter, see aboveBLER target 0.01 Target Block Error Rate for outer loop power controlMax. transport blocks 1 Controls the bitrate, one 320-bit RLCper TTI PDU in 20 ms renders a bitrate of 16 kbpsDPDCH bits per TTI 754 Data bits transmitted per TTI. Based on slot format

#9 and calculated with a RAB calculation tooldeveloped at Ericsson Research. RM attributes143/160 for RAB/SRB.

DPCCH bits per TTI 240 Control bits transmitted per per TTI. Slot format #9.Initial inner loop 4.5 dB Initial CIR target for inner loop power control. Willtarget be adjusted according to BLER target.

58

Appendix B

Detailed Results

Below are the detailed simulation results. The symbols should be interpreted as follows.

m Mean delayσ Delay standard deviation

mcell Mean throughput per cellminst Mean instantaneous user throughput

B.1 HSDPA with 16-kbps Uplink

nAMR = 5

HS-DSCH 16-kbps DCH UL

Load Delay [ms] Throughput [kb/s] Delay [ms] Throughput [kb/s] Non-sat.usrm σ mcell minst m σ mcell minst ·10−3

10 42 7 41.4 20.6 112 19 40.6 7.71 0.020 44 9 81.8 19.7 113 12 82.1 7.71 1.030 46 9 120.6 18.9 113 12 119.3 7.70 0.840 47 8 155.7 18.5 113 12 154.9 7.70 0.650 47 9 201.2 18.5 113 11 198.9 7.71 0.360 47 36 237.4 18.8 114 67 234.2 7.69 9.563 48 82 250.9 18.9 115 71 247.9 7.68 19.465 52 156 260.3 19.0 124 213 258.1 7.63 52.467 52 129 265.3 19.0 123 177 260.4 7.62 66.370 69 316 277.3 18.9 156 430 274.1 7.49 155.475 116 649 299.8 18.5 223 776 294.1 7.29 292.080 249 1203 320.5 17.5 413 1442 318.3 6.90 513.490 655 2414 361.2 15.1 857 2607 351.4 6.31 743.1100 1764 4558 396.0 11.7 1804 4516 390.6 5.67 -120 6982 9763 439.4 5.5 5395 9116 441.5 4.38 -140 12197 12448 403.2 3.3 8848 11900 431.1 3.69 -160 15006 13161 347.6 2.5 10607 12916 394.6 3.42 -

59

Downlink Uplink

Load Code Usage Interference [dB]mean max mean max

10 0.628 0.683 0.338 0.99220 0.689 0.769 0.710 1.44230 0.746 0.867 1.076 1.84940 0.795 0.922 1.439 2.35550 0.857 0.992 1.951 3.09460 0.912 1.000 2.409 3.51763 0.932 1.000 2.599 3.70065 0.944 1.000 2.758 4.10267 0.946 1.000 2.754 3.97070 0.961 1.000 2.970 4.12675 0.979 1.000 3.194 4.30480 0.990 1.000 3.505 4.68890 0.998 1.000 3.940 5.512100 0.999 1.000 4.503 6.171120 0.999 1.000 5.861 8.363140 1.000 1.000 7.197 10.654

60

B.2 HSDPA with 64-kbps Uplink

nAMR = 5

HS-DSCH 64-kbps DCH UL

Load Delay [ms] Throughput [kb/s] Delay [ms] Throughput [kb/s] Non-sat.usrm σ mcell minst m σ mcell minst ·10−3

50 47 8 203.0 18.5 71 13 201.4 12.15 1.3260 47 51 238.5 18.8 72 46 239.3 12.11 20.265 48 68 258.8 19.0 74 98 256.7 12.07 35.270 79 396 284.5 18.8 104 402 283.5 11.79 173.975 129 729 301.6 18.4 163 784 300.0 11.49 297.880 180 934 317.2 17.9 203 896 313.1 11.21 -85 609 2404 332.5 15.9 790 3010 313.3 10.13 -

Downlink Uplink

Load Code Usage Interference [dB]mean max mean max

50 0.863 1.000 4.066 6.32560 0.914 1.000 5.538 8.42565 0.940 1.000 6.396 9.94070 0.970 1.000 7.986 11.89375 0.981 1.000 9.365 13.49680 0.990 1.000 10.815 15.90985 0.997 1.000 20.912 33.383

nAMR = 1

HS-DSCH 64-kbps DCH UL

Load Delay [ms] Throughput [kb/s] Delay [ms] Throughput [kb/s] Non-sat.usrm σ mcell minst m σ mcell minst ·10−3

30 51 71 300.0 9.8 71 8 297.4 6.18 57.240 128 327 390.0 8.4 71 8 388.6 6.18 300.950 966 2407 487.8 5.7 71 41 480.2 6.18 585.860 7518 9804 461.6 2.0 4606 9560 402.6 4.27 -

Downlink Uplink

Load Code Usage Interference [dB]mean max mean max

30 0.748 0.863 3.354 5.59740 0.801 0.914 5.289 8.46150 0.866 1.000 9.857 17.37060 0.982 1.000 32.040 36.240

61

B.3 DCH 16-kbps Uplink and Downlink

nAMR = 5

16-kbps DCH DL 16-kbps DCH UL

Load Delay [ms] Throughput [kb/s] Delay [ms] Throughput [kb/s] Non-sat.usrm σ mcell minst m σ mcell minst ·10−3

10 103 17 40.2 8.5 113 12 40.1 7.71 60.320 103 17 80.8 8.5 113 11 79.4 7.71 58.830 103 17 119.8 8.5 113 12 118.7 7.71 57.840 103 17 158.7 8.5 113 12 158.2 7.71 57.850 103 17 196.4 8.5 113 12 192.8 7.70 57.860 103 19 242.3 8.5 113 17 243.6 7.71 55.865 103 24 263.3 8.5 113 19 259.7 7.70 58.270 104 41 279.8 8.5 113 39 280.7 7.69 72.075 112 183 295.9 8.4 122 187 294.1 7.64 114.176 123 286 304.6 8.4 132 273 299.3 7.59 134.877 130 325 306.8 8.3 133 282 303.6 7.58 144.878 153 454 308.9 8.1 138 312 303.8 7.55 173.879 2481 6875 218.1 6.1 1493 5199 264.4 6.72 493.880 4663 9717 177.6 5.3 2783 7481 227.9 6.20 -

Downlink Uplink

Load Code Usage Interference [dB]mean max mean max

10 0.154 0.273 0.327 0.98120 0.272 0.469 0.695 1.40130 0.384 0.586 1.062 1.85140 0.502 0.719 1.474 2.33550 0.599 0.930 1.886 2.95860 0.749 1.000 2.528 3.71965 0.790 1.000 2.751 4.20370 0.850 1.000 3.041 4.28875 0.887 1.000 3.266 4.93476 0.904 1.000 3.331 4.54777 0.909 1.000 3.393 4.92978 0.917 1.000 3.444 4.82879 0.964 1.000 4.331 8.77380 0.978 1.000 5.110 11.960

62