Serkan Kangal

WCDMA Mobility Troubleshooting Studies

and Enhancements



















Masters Thesis
Espoo, September 30, 2011
Supervisor: Prof. Jyri Hmlinen
Instructor: Jukka Valtanen, M.Sc. (Eng)

AALTO UNIVERSITY
School of Electrical Engineering
Department of Communications and Networking
ii
AALTO UNIVERSITY ABSTRACT OF MASTERS THESIS
School of Electrical Engineering
Department of Communications and Networking
Author
Serkan Kangal
Date
30.09.2011
Pages
88
Title of thesis
WCDMA Mobility Troubleshooting Studies and Enhancements
Degree programme
Communications Engineering
Department
Department of Communications and
Engineering
Supervisor
Prof. Jyri Hmlinen
Instructor
Jukka Valtanen, M.Sc. (Eng)
Abstract
Mobility is the key success area in WCDMA technology. To maintain seamless
mobility, Radio Resource Management algorithms are essential in network
management. Together with Admission Control, Load Control, Packet Scheduler,
Resource Manager and Power Control algorithms, Handover Control algorithms are
responsible for high quality seamless communication. These algorithms take place in
the Radio Network Controller software.

In software life-cycle there can be challenges related with different software
program blocks. Other than software problems there can also be radio network
planning problems, hardware problems and user-equipment related problems. Those
issues have to be analyzed by experienced R&D engineers. Usually it is not
straightforward to investigate what is the root cause. Because of this reason
troubleshooting tools play a vital role in software development. This thesis analyzes
the existing troubleshooting solutions in NSN-WCDMA-Control Plane-Handover
Algorithm team and proposes enhanced solutions for those needs.

As a result of this thesis, some of the enhanced solutions are implemented and
analyses for the other solutions are provided. Development of troubleshooting tools
and methodology will continue in the software development team after the
completion of this thesis.
Keywords
WCDMA, radio network controller, handover, troubleshooting
iii
AALTO-YLIOPISTO DIPLOMITYN TIIVISTELM
Shktekniikan korkeakoulu
Tietoliikenne- ja tietoverkkotekniikan laitos
Tekij
Serkan Kangal
Pivys
30.09.2011
Sivumr
88
Tyn nimi
WCDMA Mobility Troubleshooting Studies and Enhancements
Tutkinto-ohjelma
Tietoliikennetekniikka
Laitos
Tietoliikenne- ja
tietoverkkotekniikan laitos
Tyn valvoja
Prof. Jyri Hmlinen
Tyn ohjaaja
Jukka Valtanen, M.Sc. (Eng)
Tiivistelm
Mobiliteetti on yksi WCDMA-teknologian menestyksen avaintekijist.
Saumattoman liikkuvuuden yllpitmiseksi radioresurssien hallinnan algoritmit ovat
trkess roolissa verkon hallinnassa. Yhdess psyvalvonnan, kuormavalvonnan,
pakettiskedulerin, resurssimanagerin ja tehovalvonnan kanssa
kanavanvaihtoalgoritmit vastaavat laadukkaan, katkeamattoman yhteyden
yllpidosta. Nm algoritmit on toteutettu radioverkko-ohjaimen (RNC)
ohjelmistossa.

Ohjelmiston elinkaaren aikana ohjelmiston eri osissa kohdataan erilaisia haasteita.
Ohjelmiston lisksi ongelmia voi lyty mys radioverkon suunnittelusta,
verkkolaitteistosta tai ptelaitteista. Kaikkien niden ongelmien analysointiin
vaaditaan kokeneita R&D-insinrej, eik ongelmien varsinaisen aiheuttajan
lytminen usein ole yksinkertaista. Tmn takia erilaiset vianetsinttykalut ovat
ohjelmistokehityksess ensisijaisen trkeit. Tm diplomity analysoi jo kytss
olevia vianetsintmenetelmi NSN-WCDMA-Control Plane-Handover Algorithm -
ryhmss sek esitt erilaisia paranneltuja ratkaisuja nihin menetelmiin.

Tmn diplomityn tuloksena muutamia paranneltuja ratkaisuja toteutettiin ja
muutamia muita ratkaisumalleja analysoitiin. Vianetsinttykalujen sek -
menetelmien kehitys jatkuu tarkastellussa ohjelmistokehitysryhmss mys tmn
diplomityn valmistumisen jlkeen.
Avainsanat
WCDMA, radio network controller, handover
iv
AALTO NVERSTES YKSEK LSANS TEZ ZET
Elektrik Mhendislii Fakltesi
Haberleme ve A letiimi Blm
Yazar
Serkan Kangal
Tarih
30.09.2011
Sayfa
88
Tez Bal
Geni Bant Kod Blmeli oklu Eriim (WCDMA) Mobilite Sorun Giderme
almalar ve yiletirmeleri
Derecesi
Haberleme Mhendislii Yksek
Lisans Program
Blm
Haberleme ve A letiimi Blm
Deneti
Prof. Jyri Hmlinen
Okutman
Jukka Valtanen, M.Sc. (Eng)
zet
Hareketlilik, geni bant kod blmeli oklu eriim (WCDMA) teknolojisindeki en nemli
baar alandr. Kesintisiz hareketlilii korumak iin, Radyo Kaynaklar Ynetim
algoritmalar a ynetiminde ok nemlidir. Eriim Kontrol, Yk Kontrol, Paket
Zamanlaycs, Kaynak Yneticisi ve G Kontrol algoritmalar ile birlikte, Hcreler
Aras Gei Kontrol algoritmalar, yksek kaliteli kesintisiz bir iletiimdem sorumludur.
Bu algoritmalar Radyo ebeke Kontrolr yazlmnda yer alr.

Yazlm gelitirme srecinde, farkl yazlm program bloklari arasnda skntlar olabilir.
Yazlmsal sorunlar dnda, radyo ebeke planlama sorunlar, donanm sorunlar ve
kullanc ekipmanyla ilgili sorunlar olabilir. Bu sorunlarn deneyimli Ar-Ge
mhendisleri tarafndan analiz edilmesi gerekir. Genellikle kk nedenin ne olduunu
aratrip ortaya karmak kolay deildir. Bu nedenle sorun takip ve giderme aralar,
yazlm gelitirmede hayati bir rol oynar. Bu tez, Nokia Siemens Networks irketi
WCDMA Yazlm - Kontrol Platformu - Hcreler Aras Gei Kontrol Algoritmalar
takmndaki mevcut sorun takip ve giderme zmlerini analiz etmekte ve bu ihtiyalar
iin gelitirilmi zmler nermektedir.

Bu tezin bir sonucu olarak, baz gelimi zmler uygulanmakta ve dier zmler iin
analizler salanmaktadr. Sorun giderme aralar ve metodolojisinin gelitirilmesi, bu
tezin tamamlanmasndan sonra, yazlm gelitirme ekibinde devam edecektir.

Anahtar Kelimeler
WCDMA, Radyo ebeke Kontrolr, Hcreler Aras Gei
v
Preface

This Masters thesis presents the work that was carried out under supervision of
Professor Jyri Hmlinen from Aalto University School of Electrical Engineering and
under instruction of M.Sc. Jukka Valtanen from Nokia Siemens Networks. This thesis
work was performed at Nokia Siemens Networks premises in Espoo from January 2011
to September 2011.
Acknowledgements

I would like to thank to my employer for giving me the opportunity and necessary
support for writing this thesis. It would have been impossible to prepare this thesis
without the guidance and support of my colleagues. I would like thank to Kari, Oskari,
Tony, Maria, Jari and my instructor Jukka.
I would also like to thank my supervisor professor Jyri Hmlinen, from Aalto
University School of Electrical Engineering, for his guidance during the thesis process.
After the clarification of the thesis topic by Nokia Siemens Networks he helped me in
getting the process started and also thereafter gave me valuable comments on this thesis.
Most of all, I would like to thank to my family, my mother, my father and my beloved
Elis for all their support and encouragement that they have given me throughout my
studies.



In Espoo, 30.09.2011


vi
Table of Contents
Preface .......................................................................................................................... v
Acknowledgements ....................................................................................................... v
Table of Contents ......................................................................................................... vi
List of Acronyms ........................................................................................................ vii
List of Figures ............................................................................................................ xiii
List of Tables ............................................................................................................. xiv
Key Concepts.............................................................................................................. xv
1 Introduction........................................................................................................... 1
1.1 Problem Statement and The Objectives ........................................................... 1
1.2 Structure of the Thesis .................................................................................... 2
2 WCDMA and HSPA Basics .................................................................................. 3
2.1 Evolution to 3G .............................................................................................. 3
2.2 UMTS Radio Access Network Architecture .................................................. 10
2.3 WCDMA ...................................................................................................... 14
2.4 HSPA ........................................................................................................... 16
3 Mobility in UMTS .............................................................................................. 20
3.1 Introduction to Radio Resource Management ................................................ 20
3.2 Handover Control ......................................................................................... 21
3.3 Handover Measurements ............................................................................... 29
4 Radio Network Controller (RNC) ........................................................................ 40
4.1 UTRAN network elements: Standard concept ............................................... 40
4.2 Nokia Siemens Networks RNC Solutions ..................................................... 41
4.3 RNC SW Architecture .................................................................................. 45
4.4 Radio Resource Management of WCDMA RAN Service Block .................... 48
4.5 Handover Control Process Family ................................................................. 54
5 Troubleshooting Experiences .............................................................................. 57
5.1 Troubleshooting Approach for Mobile Networks .......................................... 57
5.2 EMIL ............................................................................................................ 59
5.3 Challenges to be studied related with Handover Control Algorithm .............. 60
6 Conclusion .......................................................................................................... 80
7 References .......................................................................................................... 83
8 Appendixes ......................................................................................................... 85
8.1 Data types ..................................................................................................... 85


vii
List of Acronyms
2G 2nd Generation
3GPP 3rd Generation Partner Project
8PSK Eight-Phase Shift Keying
A-GPS Network-Assisted Global Positioning System
AC Admission Control
ACK Acknowledgement
ADJD Adjacent Detected Cell
ADJG Adjacent GSM Cell
ADJI Adjacent Inter-Frequency cell
ADJS Adjacent Intra-Frequency cell
ALCAP Access Link Control Application Part
AMPS Advanced Mobile Phone Service
AS Active Set
ASU Active Set Update
AT&T American Telephone and Telegraph
ATDMA Advanced TDMA Mobile Access
BCC Base Station Colour Code
BCCH Broadcast Control Channel
BER Bit Error Rate
BLER Block Error Rate
BoD Bandwidth on Demand
BSC Base Station Controller
BSIC Base Station Identity Code
BSS Base Station Subsystem
BTS Base Transceiver Station
C-NETZ Radio Telephone Network C
CDMA Code Division Multiple Access
CFCP Centralized Functions and services in Control Plane
CGI Cell Global Identification
CI Cell Identifier
CIO Cell Individual Offset
CM Compressed Mode
viii
CN Core Network
CODIT Code Division Testbed
CPICH Common Pilot Channel
CRNC Controlling Radio Network Controller
CSCP Cell Specific functions and services in Control Plane
CSUP Cell Specific functions and services in User Plane
DCCH Dedicated Control Channels
DCH Dedicated Channel
DL Downlink
DMCU Data and Macro diversity Combining Unit
DMPG Data and Macro Diversity Processor Group
DPCCH Dedicated Physical Control Channel
DPCH Dedicated Physical Channel
DPDCH Dedicated Physical Data Channel
DRNC Drifting Radio Network Controller
DS-CDMA Direct-Sequence Code Division Multiple Access
DSCR Detected Set Cell Reporting
E-DCH Enhanced Dedicated Channel
EDGE Enhanced Data Rates for Global Evolution
EHU External Hardware Alarm Unit
EITP External Interface functions in Transport Plane
ETACS Extended Total Access Communications System
ETSI European Telecommunications Standards Institute
FCC Federal Communications Commission
FDD Frequency Division Duplex
FDMA Frequency Division Multiple Access
FM Frequency Modulation
FRAMES Future Radio Wideband Multiple Access System
GERAN GSM EDGE Radio Access Network
GGSN Gateway GPRS Support Node
GMSC Gateway Mobile Services Switching Center
GMSK Gaussian Minimum Shift Keying
GPRS General Packet Radio Services
GSM Global System for Mobile Communications
ix
HC Handover Controller
HHO Hard Handover
HLR Home Location Register
HO Handover
HSCSD High-Speed Circuit-Switched Data
HSDPA High Speed Downlink Packet Access
HSUPA High Speed Uplink Packet Access
HSPA High Speed Packet Access
ICSU Interface Control and Signalling Unit
I-HSPA Internet High Speed Packet Access
I&V Integration and Verification
IFHO Inter Frequency Handover
IMS IP Multimedia Subsystem
IMSI International Mobile Subscriber Identity
IS-95 Interim Standard 95 for CDMA
IS-136 Interim Standard 136 for Digital AMPS
ISHO Inter System Handover
LAC Location Area Code
LC Load Control
LCS Location Services
LTE 3GPP Long Term Evolution
MAC Medium Access Control
MBMS Multimedia Broadcast Multicast Service
MCC Mobile Country Code
ME Mobile Equipment
MEHO Mobile Evaluated Handover
MIMO Multiple-Input and Multiple-Output
MNC Mobile Network Code
MRC Maximal Ratio Combining
MSC Mobile Services Switching Centre
MT Module Test
MXU Multiplexer Unit
NACK Negative Acknowledgement
NBAP Node B Application Part
x
NCC Network Colour Code
NEHO Network Evaluated Handover
NFC Near Field Communications
NMT Nordic Mobile Telephony
NodeB Base Transceiver Station in UMTS Architecture
NPGE Network Processor Interface Units Gigabit Ethernet
NPS1 Network Processor Interface Unit STM-1
NRT Non Real Time
NTT Nippon Telegraph and Telephone
O&M Operation & Maintenance
ODMA Opportunity Driven Multiple Access
OFDMA Orthogonal Frequency Division Multiple Access
OMS Operation and Maintenance Server
OMU Operation and Maintenance Unit
QoS Quality of Service
P-CPICH Primary Common Pilot Channel
PC Power Control
PDC Personal Digital Cellular
PLMN Public Land Mobile Network
PRB Program Block
PS Packet Scheduler
R&D Research and Development
RAB Radio Access Bearer
RAC Routing Area Code
RACE Research of Advanced Communication Technologies in
Europe
RAN Radio Access Network
RANAP Radio Access Network Application Part
RAT Radio Access Technology
RLC Radio Link Control
RNC Radio Network Controller
RNS Radio Network Subsystem
RNSAP Radio Network Subsystem Application Part
RNW Radio Network
xi
RRC Radio Resource Control
RRM Radio Resource Management
RSCP Received Signal Code Power
RSMU Resource and Switch Management Unit
RT Real Time
RX-TX Receive Transmit
SAB Service Area Broadcast
SAP Service Access Point
SAS Stand Alone Serving Mobile location Centre
SC-FDMA Single Carrier Frequency Division Multiple Access
SEB Service Block
SFU Switching Fabric Unit
SGSN Serving GPRS Support Node
SHO Soft Handover
SIR Signal to Interference Ratio
SITP Signalling Transport Plane
SRNC Serving Radio Network Controller
SRNS Serving Radio Network Subsystem
SWU Switching Unit (Ethernet)
SYB System Block
TACS Total Access Communications System
TBU Timing and Hardware Management Bus Unit
TDD Time Division Duplex
TDMA Time Division Multiple Access
UARFCN UTRA Absolute Radio Frequency Channel Number
UE User Equipment
UER UE Specific Radio Resources
UL Uplink
UMTS Universal Mobile Telecommunications System
USCP UE Specific functions and services in Control Plane
USUP UE Specific functions and services in User Plane
USIM UMTS Subscriber Identity Module
UTRAN UTMS Terrestrial Radio Access Network
VAS Value Added Services
xii
VLR Visitor Location Register
VOIP Voice over IP
WCDMA Wideband Code Division Multiple Access
WDU Winchester Drive Unit for OMU
WTDMA Wideband Time Division Multiple Access
xiii
List of Figures
Figure 1: Mobile Evolution [1, pp 4] ............................................................................. 3
Figure 2 : European research programmes towards 3G systems and the ETSI decision
[ 4, pp 65] ..................................................................................................................... 7
Figure 3 : 3GPP organizational partners [ 4, pp 67] ....................................................... 8
Figure 4 : 3GPP RAN TSG Working Groups [ 4, pp 68] ............................................... 9
Figure 5 : UMTS high-level system architecture [4, pp 76] ......................................... 10
Figure 6 : UTRAN architecture [ 4, pp 78] .................................................................. 11
Figure 7 : UTRAN architecture extended [ 4, pp 76] ................................................... 12
Figure 8 : FDMA, TDMA, Hybrid FDMA/TDMA and CDMA [ 3, pp 26 - 27] ........... 14
Figure 9 : Allocation of bandwidth in WCDMA in the timefrequencycode space
[ 4, pp 48] ................................................................................................................... 14
Figure 10 : WCDMA radio-access network architecture [ 6, pp 132] ........................... 15
Figure 11 : Network Diagram for HSPA traffic (user plane) [ 6 , pp 28] ...................... 16
Figure 12 : HSPA Standardization and Deployment Schedule [ 8,pp 7] ....................... 17
Figure 13 : HSPA Evolution [ 7, pp 4] ........................................................................ 17
Figure 14 : HSPA deployment with (f2) new carrier deployed with HSPA and (f1)
carrier shared between WCDMA and HSPA. [ 7, pp 5] ............................................... 18
Figure 15 : Soft Handover [ 3, pp 38] .......................................................................... 23
Figure 16 : Softer Handover [ 3, pp 270] ..................................................................... 23
Figure 17 : Inter-system handovers between GSM and WCDMA [ 4, pp 255] ............. 24
Figure 18 : Inter-system handover procedure [ 4, pp 256] ............................................ 25
Figure 19 : Compressed Mode pattern [ 9, pp 224] ...................................................... 27
Figure 20 : Effect of compressed mode on the coverage [ 4, pp 257] ........................... 27
Figure 21 : Intra-frequency Measurements [ 9, pp 219] ............................................... 34
Figure 22 : Time-to-trigger Mechanism for Event 1A [ 9, pp 219] ............................... 36
Figure 23 : UTRAN Network Elements ...................................................................... 40
Figure 24 : Functional architecture of the cRNC [ 12, pp 31]....................................... 42
Figure 25 : cRNC SW architecture [ 12, pp 38] ........................................................... 45
Figure 26 : mcRNC SW architecture [ 12, pp 39] ........................................................ 45
Figure 27 : Service model architecture [ 12, pp 40] ..................................................... 47
Figure 28 : Radio Resource Management of WCDMA RAN Service Block Diagram
[ 12, pp 48] ................................................................................................................. 49
xiv
Figure 29 : Handover Algorithms Program Block Diagram ......................................... 52
Figure 30 : EMIL Screenshot ...................................................................................... 59
Figure 31 : Handover Control Algorithm Program Block interactions ......................... 61
Figure 32 : Database Consistency Check ..................................................................... 63
Figure 33 : Actions when inconsistency is identified ................................................... 65
Figure 34 : Transition from log file to network topology table..................................... 69
Figure 35 : Example for missing Neighbour Cell Definitions and Handover fail .......... 70


List of Tables
Table 1 : First Generation Networks [ 3, pp 2]............................................................... 4
Table 2 : 3GPP Release History in a nutshell [ 5] ........................................................ 10
Table 3 : Formatted printout of the RNW network topology ........................................ 68


xv
Key Concepts
GSM: 2
nd
Generation Radio Access Network technology which is standardized by
European Telecommunications Standards Institute. It uses FDMA and TDMA as radio
access method and at the backbone it uses digital circuit switching.
BSC: Base Station Controller manages radio resources for Base Stations in GSM
architecture.
RNC: RNC stands for Radio Network Controller which is defined with UTRA-3G
specifications. The key functions of the Radio Network Controller (RNC) are
management of terrestrial channels, management of radio channel configurations in the
Radio Access Network (RAN), radio resource management, telecom functionality,
transmission & transport features and maintenance & operation.
Handover: Handover is the process to maintain seamless communication while users
are mobile between different cells/sectors inside the network.
EMIL: An internal tool that is designed to investigate call traces and other logs for
verification purposes.
Troubleshooting: Troubleshooting is the chain of processes which aims to identify a
particular challenge inside the software and try to propose solutions or workarounds.



1

1 Introduction
Wireless Communications has become step by step indispensable in peoples life as it is
utilized more and more. For service providers, it also becomes vital to use their wireless
resources efficiently. Radio Resource Management (RRM) is the solution to maintain
seamless mobility and resource efficiency. In WCDMA Radio Access Network (RAN)
architecture Radio Network Controller (RNC) is responsible from RRM duties. Radio
Resource management functions are split into 6 different groups of algorithms:
Admission Control
Load Control
Packet Scheduler
Resource Manager
Power Control
Handover Control

The software development for Nokia DX type of digital switches was started in early
70s and with the ease of its modular design; DX architecture followed the technology
evolution and was used for GSM mobile technology as well. As an ancestor, software
for Radio Network Controller continued from the existing DX200 software and it
became more complex with the specifications of 3GPP for WCDMA networks. Those
changes in the software also created new fields to be debugged and investigated.
Eventually troubleshooting has become more important and complex for the new
systems.

This work examines the troubleshooting experiences for Handover related issues under
Radio Resource Management software block in Radio Network Controller.

1.1 Problem Statement and The Objectives
There are different types of challenges in WCDMA Mobility part of the RNC software.
From developers and testers point of view, it would be easier for them to investigate
those issues by using a specially designed troubleshooting tool or with improvements to
the existing tools.

2
Most of the existing troubleshooting approaches are based on practical analysis which
takes time and usually it is hard to figure out the problem. This thesis will analyze the
existing challenges and propose better solutions to be implemented by modifying the
existing solution or providing a new troubleshooting tool.
1.2 Structure of the Thesis
This thesis consists of 8 chapters.
Chapter 1 includes the introduction of the thesis. Chapter 2 includes the basic
information about WCDMA and HSPA. Chapter 3 includes detailed information about
mobility concept in terms of UMTS specifications. Chapter 4 explains the Radio
Network Controller concept and different solution approaches and detailed information
about the Handover Control Algorithm Program Block in Radio Network Controller
Software. Chapter 5 includes the troubleshooting experiences and introduces an existing
troubleshooting tool called EMIL. Then it depicts and analyzes existing challenges in
Handover Control Algorithm Block. Chapter 6 has conclusion statements about the
thesis. Chapter 7 includes the list of references and Chapter 8 includes the message
details for a particular issue which will be analyzed in 5.3.2.
The scope of this thesis work was decided with the NSN - Control Plane - Handover
Algorithms team. My prior knowledge about WCDMA was not deep enough to analyze
the handover algorithm based problems, so I started studying the Radio Resource
Management fundamentals focusing on handover types. In the second chapter I try to
inform the reader about the short history of WCDMA and in the further chapters I try to
focus the attention on Handover Algorithm analysis.
With the Handover Algorithms team we started with initial thesis meetings to define the
scope of the work. Then, from different proficiencies, analysis requests were gathered
and problem specific small working groups were assigned. After that, thesis progress
continued with weekly updates.
3

2 WCDMA and HSPA Basics
In this chapter, a short history about 3G evolution and basics of WCDMA and HSPA
will be presented.
2.1 Evolution to 3G
2.1.1 1
st
Generation







Figure 1: Mobile Evolution [1, pp 4]
The first mobile telephony network was deployed in 1920 for the use of several police
departments in the U.S. as an experiment. Then, with the development of frequency
modulation (FM), mobile communications became more reliable during World War II.
The development continued after the war, and it started to be used in big cities of U.S.
But those systems had limited capacity and inefficient transmission methods [2, pp 3].

After multiple trials, technology evolved to a level that it could be used as a commercial
product. In 1978, American Telephone & Telegraph (AT&T) implemented a Federal
Communications Commission (FCC) authorized trial system in Chicago. After
analyzing the results of the trial system for a couple of years, AT&T got the licence for
Advanced Mobile Phone Service (AMPS). A commercial mobile network was first
deployed in Chicago and the other big cities followed. AMPS was operating in 800-
1st Generation (analogue)
2nd Generation (digital)
3rd Generation
GSM + EDGE
GSM + GPRS
GSM + VAS
4th Generation
FUTURE
4
MHz band [2, pp 3]. At the same time in Japan, Nippon Telegraph and Telephone
(NTT) started operating their AMPS network in Tokyo [3, pp 1].

In 1980s, Nordic countries launched their Nordic Mobile Telephony (NMT450)
network which was using 450 MHz band in the following years it was developed to use
900MHz band. After AMPS and NMT, the British launched a new technology in 1985
which was Total Access Communications System (TACS) [2, pp 3]. There were also
other technologies developed, but widely used technologies were AMPS, NMT and
TACS.

System Countries
NMT-450 Andorra, Austria, Belarus, Belgium, Bulgaria, Cambodia, Croatia,
Czech Republic, Denmark, Estonia, Faroe Islands, Finland, France,
Germany, Hungary, Iceland, Indonesia, Italy, Latvia, Lithuania,
Malaysia, Moldova, Netherlands, Norway, Poland, Romania, Russia,
Slovakia, Slovenia, Spain, Sweden, Thailand, Turkey, and Ukraine
NMT-900 Cambodia, Cyprus, Denmark, Faroe Islands, Finland, France,
Greenland, Netherlands, Norway, Serbia, Sweden, Switzerland, and
Thailand
TACS/ETACS Austria, Azerbaijan, Bahrain, China, Hong Kong, Ireland, Italy,
Japan, Kuwait, Macao, Malaysia, Malta, Philippines, Singapore,
Spain, Sri Lanka, United Arab Emirates and United Kingdom

AMPS

Argentina, Australia, Bangladesh, Brazil, Brunei, Burma, Cambodia,
Canada, China, Georgia, Guam, Hong Kong, Indonesia, Kazakhstan,
Kyrgyzstan, Malaysia, Mexico, Mongolia, Nauru, New Zealand,
Pakistan, Papua New Guinea, Philippines, Russia, Singapore, South
Korea, Sri Lanka, Tajikistan, Taiwan, Thailand, Turkmenistan,
United States, Vietnam, and Western Samoa

C-NETZ Germany, Portugal, and South Africa
Radiocom 2000 France
Table 1 : First Generation Networks [ 3, pp 2]
5
2.1.2 2
nd
Generation
At the beginning, the capacity was enough for the limited amount of subscribers, but
when the number of subscribers increased, operators and vendors started to think on
better technologies for mobile communications. With this motivation, different 2G
technologies were developed in different countries.

The main enhancement with 2G was digital communication. The use of digital
transmission brought a number of benefits [ 2, pp 52]:
Increased capacity over analogue
Reduced capital infrastructure costs
Reduced the capital per subscriber cost
Reduced cellular fraud
Improved features (such as encryption)

The benefits listed above, mainly helped operators to serve more efficiently (higher
capacity with less cost) to their subscribers. The most successful 2G technologies were
Interim Standard 136 (IS-136) TDMA, IS-95 CDMA, and the Global System for
Mobile communications (GSM).

IS 136 (digital-AMPS) was developed over analogue AMPS system. In the first phase
time-division-multiplexing (TDM) was added only for the voice channels. Then in the
second phase control channels were also digitalized [3, pp 3].

GSM was developed with the standardization movements of European Countries. Even
though the standardization was done by European initiatives, it was aimed to be a global
standard. As a continuation of NMT900; at first, it was standardized to work in 900
MHz, but later GSM1800 launched in U.K. and GSM1900 launched in U.S. [ 2, pp 6].

CDMA or IS-95 was developed by Qualcomm and standardized in U.S. Besides from
other multiple access methods, CDMA uses different codes in the same frequency to
share the transmission medium. (In the next chapters there are detailed explanations
about CDMA and wide-band CDMA.) It was used in the United States, South Korea,
Hong Kong, Japan, Singapore, and many other East Asian countries. In South Korea
6
especially this standard was widely used. IS-95 networks are also known by the brand
name cdmaOne [3, pp 4].

2.1.3 Generation 2,5
From technological perspective, 2G developments were made to overcome the 1G
deficiencies but could not add any additional value to the network. After solving the
first generation problems, operators would like to increase their network values by
connecting their networks to the big ocean, Internet. For that purpose, different
standardization committees discussed different technology enhancements to increase the
user bandwidth.
First technology that was used was High-speed Circuit-switched Data (HSCSD), it was
circuit connection based and could not get much support from the handset
manufacturers. HSCSD was a good solution for real-time services but when there is no
traffic, reserved resources will be idle which is a waste of money [3, pp 5]. Then the
General Packet Radio Services (GPRS) came to the market. GPRS was suitable for non-
real-time applications. Throughput was increased by packet switched transmission.
Implementation of GPRS was not as easy as HSCSD, additional hardware was needed
for the radio network [3, pp 6].
Another approach to increase the user bandwidth was to change the modulation method.
Enhanced Data rates for Global Evolution (EDGE) was developed by using eight-phase
shift keying (8PSK) modulation method. Because it had the coexistence with Gaussian
minimum shift keying (GMSK), EDGE upgraded network and also supported old
handsets. Some operators also used EDGE with their existing GPRS infrastructure and
reached to great data rates such as 384 kbps [3, pp 6].
In U.S. there were technologies that can be named as 2.5G. One of them was IS-95B,
which used multiple code channels per user to increase the user data rate. The other one
was CDMA2000, which was evolved from CDMA (IS-95).
In Japan, NTT DoCoMo introduced its own concept, i-mode, over Personal Digital
Cellular (PDC). Including the internet services, i-mode concept showed great success
and became a business model for new concepts and technologies [ 3, pp 8].
7
2.1.4 3
rd
Generation
In 1988 the RACE I (Research of Advanced Communication Technologies in Europe)
programme started, researching for the basics of third generation communications
networks. Between 1992 and 1995 research continued on CDMA-based Code Division
Testbed (CODIT) and TDMA-based Advanced TDMA Mobile Access (ATDMA) in
the RACE II project. In 1995, Future Radio Wideband Multiple Access System
(FRAMES) project was set up by Advanced Communication Technologies and Services
(ACTS) research group [ 4, pp 61].











Figure 2 : European research programmes towards 3G systems and the ETSI
decision [4, pp 65]
The main objective of the project was to study on a proposal for Universal Mobile
Telecommunications System radio access system. FRAMES project was supported by
several European Universities, Nokia, Siemens, Ericsson, France Tlcom and CSEM /
Pro Telecom. After some discussions, two modes were proposed to the European
Telecommunications Standards Institute (ETSI) as candidates for UMTS air interface
[ 4, pp 62]:
FMA1: Wideband TDMA
FMA2: Wideband CDMA

In 1997 after the proposal submissions, ETSI formed 5 working groups [ 4, pp 62]:
Wideband CDMA (WCDMA)
Wideband TDMA (WTDMA)
TDMA / CDMA
Orthogonal Frequency Division Multiple Access (OFDMA)
Opportunity Driven Multiple Access (ODMA)
RACE I
- basic
studies
RACE II
-ATDMA
-CODIT
ACTS/FRAMES
-FMA1: WTDMA
-FMA2: WCDMA
ETSI
Concept
groups
ETSI Decision:
-WCDMA for
FDD operation
1988 1992 1995 1997 1998
8

After getting the full solution proposals from work-groups and evaluating the results,
WCDMA was chosen as the standard for the UMTS Terrestrial Radio Access (UTRA)
air interface on the paired frequency bands and WTDMA/CDMA was chosen for the
unpaired frequency bands. In 1999, technical work for the UTRA transferred to 3
rd

Generation Partnership Project (3GPP) [ 4, pp 65].

Standardization studies were taking place in different countries under different
committees [ 4, pp 67]:
Japan: The Association for Radio Industries and Businesses (ARIB) and the
Telecommunication Technology Committee (TTC)
Korea: The Telecommunications Technology Association (TTA)
U.S. : A Technical Subcommittee of Standards Committee T1
Telecommunications (T1P1)
China: The China Wireless Telecommunication Standard Group (CWTS)






Figure 3 : 3GPP organizational partners [ 4, pp 67]
In 3GPP, four different technical specification groups (TSG) were set up:
Radio Access Network TSG
Core Network TSG
Service and System Aspects TSG
Terminals TSG

UTRA air interface specification was produced by the Radio Access Network TSG.
Release99 UMTS specifications from ETSI were identical to the Release99
specifications produced by 3GPP. During 2000, further work on GSM evolution was
moved from ETSI and other forums to 3GPP, including work on GPRS and EDGE. A
new technical specification group, TSG GERAN was set up for this purpose [ 4, pp 68].

3GPP
ETSI ARIB TTA T1P1 TTC CWTS
ETSI Members ARIB Members TTA Members T1P1 Members TTC Members CWTS Members
9

Within these groups the one most relevant to the WCDMA technology is the Radio
Access Network TSG (RAN TSG), which has been divided into four different working
groups.










Figure 4 : 3GPP RAN TSG Working Groups [ 4, pp 68]
As mentioned earlier, the studies of various participating organisations were merged
into a single standard, and then the detailed parameters for the first full release (Release
99) of UTRA from 3GPP finalised in 1999. In 3GPP the next version of the
specifications was originally considered as Release 2000, but in the meantime the
release naming was adjusted, so that the next release in March 2001 was called Release
4 and the numbering continued. 3GPP release history can be seen in Table 2.












Radio Access Network Technical Specification Group
WG1 WG2 WG3 WG4 ITU AdHoc
Radio
Layer 1
Radio
Layer 2/3
Architecture
and
Interfaces
Radio
Performance
and RF
Parameters
ITU Activity
Co-ordination
10
Version Date Release Info
Release 99 2000 Q1 Specification of first UMTS 3G networks.
Release 4 2001 Q2 All-IP Core Network features added.
Release 5 2002 Q1 IP Multimedia Subsystem (IMS) and High-Speed Downlink
Packet Access (HSDPA) introduced.
Release 6 2004 Q4 Integration with Wireless-LAN added, High-Speed Uplink
Packet Access (HSUPA) and Multimedia Broadcast Multicast
Service (MBMS) introduced, enhancements to IMS added
Release 7 2007 Q4 Improvements to QoS and support for real-time applications
added. Enhanced Data Rates for GSM Evolution (EDGE
Evolution), High-Speed Packet Access Evolution (HSPA+)
and Near Field Communications (NFC) introduced,
Release 8 2008 Q4 Specification of first LTE networks. All-IP Network approach
introduced. Orthogonal Frequency-Division multiple access
(OFDM), Single Carrier Frequency Division Multiple Access
(SC-FDMA or FDE) and Multiple-Input and Multiple-Output
(MIMO) added. Dual-Cell HSDPA introduced.
Release 9 2009 Q4 All-IP Network enhancements added. WIMAX and
LTE/UMTS interoperability added. Dual-Cell HSDPA with
MIMO introduced. Dual-Cell HSUPA introduced
Release 10 2011 Q1 LTE Advanced introduced, Multi-cell HSDPA(4 carriers)
introduced
Table 2 : 3GPP Release History in a nutshell [ 5]

2.2 UMTS Radio Access Network Architecture





Figure 5 : UMTS high-level system architecture [4, pp 76]
UE UTRAN CN
Uu Iu
11
In the standardization phase, network elements were grouped based on their similar
functionality and defined at the logical level. The UMTS system consists of a number of
logical network elements that each has a defined functionality. The User Equipment
(UE) that interfaces with the user and the radio interface is defined, the Radio Access
Network (UTRAN) handles all radio-related functionality and the Core Network is
responsible for switching and routing calls and data connections to external networks.












Figure 6 : UTRAN architecture [4, pp 78]
UTRAN consists of one or more Radio Network Sub-systems (RNS). An RNS is a sub-
network within UTRAN and consists of one Radio Network Controller (RNC) and one
or more Node Bs. RNCs may be connected to each other via an Iur interface. RNCs
and Node Bs are connected with an Iub interface.

The main characteristic of UTRAN can be summarised in the following points
[4, pp79]:
Support of UTRA and all the related functionality. In particular, the major
impact on the design of UTRAN has been the requirement to support soft
handover (one terminal connected to the network via two or more active cells)
and the WCDMA-specific Radio Resource Management algorithms.


USIM
ME
Cu
NodeB
NodeB
NodeB
NodeB
RNC
RNC UE
UTRAN
RNS
RNS
MSC/
VLR
CN
SGSN
Iub Iur
Uu
Iu CS
Iu PS
12
Maximization of the commonalities in the handling of packet-switched and
circuit switched data, with a unique air interface protocol stack and with the use
of the same interface for the connection from UTRAN to both the PS and CS
domains of the core network.
Maximization of the commonalities with GSM, when possible.
Use of the ATM transport as the main transport mechanism in UTRAN.
Use of the IP-based transport as the alternative transport mechanism in UTRAN
from Release 5 onwards.
2.2.1 UTRAN Elements








Figure 7 : UTRAN architecture extended [4, pp 76]
The UE consists of two parts:
The Mobile Equipment (ME) is the radio terminal used for radio communication
over the Uu interface.
The UMTS Subscriber Identity Module (USIM) is a smartcard that holds the
subscriber identity, performs authentication algorithms, and stores authentication
and encryption keys and some subscription information that is needed at the
terminal.



USIM
ME
Cu
NodeB
NodeB
NodeB
NodeB
RNC
RNC UE
UTRAN
MSC/
VLR
CN
SGSN
Iub
Iur
Iu
GGSN
GMSC
HLR
Uu
Internet
External Networks
PLMN, PSTN,
ISDN, etc...
13
UTRAN also consists of two distinct elements:
The Node B converts the data flow between the Iub and Uu interfaces. It also
participates in radio resource management.
The Radio Network Controller (RNC) owns and controls the radio resources in
its domain (the Node Bs connected to it). RNC is the service access point for all
services UTRAN provides to the Core Network, for example, management of
connections to the UE.

The main elements of the Core Network are as follows:
HLR (Home Location Register) is a database located in the users home system
that stores the master copy of the users service profile.
MSC/VLR (Mobile Services Switching Centre / Visitor Location Register) is the
switch (MSC) and database (VLR) that serves the UE in its current location for
Circuit Switched (CS) services.
GMSC (Gateway MSC) is the switch at the point where UMTS PLMN is
connected to external Circuit Switched networks.
SGSN (Serving GPRS (General Packet Radio Service) Support Node)
functionality is similar to that of MSC / VLR but is typically used for Packet
Switched (PS) services.
GGSN (Gateway GPRS Support Node) functionality is close to that of GMSC
but is in relation to PS services.
14
2.3 WCDMA

Figure 8 : FDMA, TDMA, Hybrid FDMA/TDMA and CDMA [3, pp 26 - 27]

WCDMA is a wideband Direct-Sequence Code Division Multiple Access (DS-CDMA)
system, i.e. user information bits are spread over a wide bandwidth by multiplying the
user data with quasi-random bits (called chips) derived from CDMA spreading codes. In
order to support very high bit rates (up to 2 Mbps), the use of a variable spreading factor
and multi-code connections is supported.


Figure 9 : Allocation of bandwidth in WCDMA in the timefrequencycode
space [4, pp 48]
15
WCDMA is designed to be deployed in conjunction with GSM. Therefore, handovers
between GSM and WCDMA are supported in order to be able to leverage the GSM
coverage for the introduction of WCDMA. WCDMA supports two basic modes of
operation: Frequency Division Duplex (FDD) and Time Division Duplex (TDD). In the
FDD mode, separate 5 MHz carrier frequencies are used for the uplink and downlink
respectively, whereas in TDD only one 5 MHz is timeshared between the uplink and
downlink. Uplink is the connection from the mobile to the base station, and downlink is
that from the base station to the mobile. The TDD mode is based heavily on FDD mode
concepts and was added in order to leverage the basic WCDMA system also for the
unpaired spectrum allocations of the ITU for the IMT-2000 systems [4, pp 48].

The WCDMA air interface has been crafted in such a way that advanced CDMA
receiver concepts, such as multiuser detection and smart adaptive antennas, can be
deployed by the network operator as a system option to increase capacity and/or
coverage [4, pp 49].


Figure 10 : WCDMA radio-access network architecture [6, pp 132]

16
The chip rate of 3.84 Mcps leads to a carrier bandwidth of approximately 5 MHz.
DS-CDMA systems with a bandwidth of about 1 MHz, such as IS-95, are commonly
referred to as narrowband CDMA systems. The inherently wide carrier bandwidth of
WCDMA supports high user data rates and also has certain performance benefits, such
as increased multipath diversity. Subject to its operating licence, the network operator
can deploy multiple 5 MHz carriers to increase capacity, possibly in the form of
hierarchical cell layers. The actual carrier spacing can be selected on a 200 kHz grid
between approximately 4.4 MHz and 5 MHz, depending on interference between the
carriers [4, pp 47].

WCDMA supports highly variable user data rates, in other words the concept of
obtaining Bandwidth on Demand (BoD) is well supported. The user data rate is kept
constant during each 10 ms frame. However, the data capacity among the users can
change from frame to frame. This fast radio capacity allocation will typically be
controlled by the network to achieve optimum throughput for packet data services
[4, pp 48].

Furthermore, WCDMA supports the operation of asynchronous base stations, so that,
unlike in the synchronous IS-95 system, there is no need for a global time reference
such as a GPS. Deployment of indoor and micro base stations is easier when no GPS
signal needs to be received. WCDMA employs coherent detection on uplink and
downlink based on the use of pilot symbols or common pilot. While already used on the
downlink in IS-95, the use of coherent detection on the uplink is new for public CDMA
systems and will result in an overall increase of coverage and capacity on the uplink
[4, pp 48].

2.4 HSPA

Figure 11 : Network Diagram for HSPA traffic (user plane) [ 7 , pp 28]
17
High-Speed Downlink Packet Access (HSDPA) was standardized as a part of 3GPP
Release 5 with the first specification version in March 2002. High-speed uplink packet
access (HSUPA) was a part of 3GPP Release 6 with the first specification version in
December 2004. HSDPA and HSUPA together are called High-Speed Packet Access
(HSPA). The first commercial HSDPA networks were available at the end of 2005 and
the commercial HSUPA networks were available by 2007 [ 8, pp 4]. HSPA
development history (including LTE) is illustrated in Figure 12 and HSPA Evolution is
illustrated in Figure 13.

Figure 12 : HSPA Standardization and Deployment Schedule [ 9, pp 7]

Figure 13 : HSPA Evolution [ 8, pp 4]
HSPA is deployed on top of the WCDMA network either on the same carrier or for a
high-capacity and high bit rate solution using another carrier (demonstration can be
seen in Figure 14). In both cases, HSPA and WCDMA can share all the network
elements in the core network and in the radio network including base stations, Radio
18
Network Controller (RNC), Serving GPRS Support Node (SGSN) and Gateway GPRS
Support Node (GGSN). WCDMA and HSPA are also sharing the base station sites,
antennas and antenna lines.

Figure 14 : HSPA deployment with (f2) new carrier deployed with HSPA
and (f1) carrier shared between WCDMA and HSPA. [ 8, pp 5]
The performance of the radio system defines how smoothly applications can be used
over the radio network. The key parameters defining application performance include
data rate and network latency. There are applications that are happy with low bit rates of
a few tens of kbps but require very low delay, like voice-over-IP (VoIP) and real time
action games. On the other hand, the download time of a large file is only defined by the
maximum data rate, and latency does not play any role. GPRS Release 99 typically
provides 3040 kbps with latency of 600 ms. EGPRS Release 4 pushes the bit rates 34
times higher and also reduces latency below 300 ms. The EGPRS data rate and latency
allow smooth application performance for several mobile-based applications including
Wireless Application Protocol (WAP) browsing and push-to-talk [ 8, pp 6].
WCDMA enables peak data rates of 384 kbps with latency of 100200 ms, which
makes Internet access close to low-end digital subscriber line (DSL) connections and
provides good performance for most low-delay Internet Protocol (IP) applications as
well. HSPA pushes the data rates up to 12 Mbps in practice and even beyond 3Mbps in
good conditions. Since HSPA also reduces network latency to below 100 ms, the end
user experienced performance is similar to the fixed line DSL connections. No or only
little effort is required to adapt Internet applications to the mobile environment.
Essentially, HSPA is a broadband access with seamless mobility and extensive
coverage. Radio capability evolution from GPRS to HSPA is illustrated in Figure 1.9.
HSPA was initially designed to support high bit rate non-real time services. The
19
simulation results show, however, that HSPA can provide attractive capacity also for
low bit rate low-latency applications like VoIP. 3GPP Releases 6 and 7 further improve
the efficiency of HSPA for VoIP and other similar applications [ 8, pp 6].
Higher cell capacity and higher spectral efficiency are required to provide higher data
rates and new services with the current base station sites. Basic HSPA includes a one-
antenna Rake receiver in the terminals and two-branch antenna diversity in the base
stations. Enhanced HSPA includes two-antenna equalizer mobiles and interference
cancellation in the base station. The simulation results show that HSPA can provide
substantial capacity benefit. Basic HSDPA offers up to three times WCDMA downlink
capacity, and enhanced HSDPA up to six times WCDMA. The spectral efficiency of
enhanced HSDPA is close to 1 bit/s/Hz/cell. The uplink capacity improvement with
HSUPA is estimated between %30 and %70. HSPA capacity is naturally suited for
supporting not only symmetric services but also asymmetric services with higher data
rates and volumes in downlink [ 8, pp 7].
20

3 Mobility in UMTS
3.1 Introduction to Radio Resource Management
The task of Radio Resource Management (RRM) is to optimize the use of the available
resources, such as transmitter power and spreading codes, in order to provide users with
the largest possible capacity for a specified coverage and quality-of-service (QoS). This
is achieved through the concerted effort of a number of closely inter-related radio
resource management algorithms. The algorithms can be divided into cell-based and
connection-based algorithms on the basis of their different purposes.
Cell Based Algorithms:
Admission Control: When a radio resource related request is received in the
RNC, the admission control algorithm estimates the minimum radio resources
required to provide the required quality of service, determines whether these radio
resources are available, and, if they are, allocates them. Failing this, the request
for radio resources is denied [4, pp 264].
Load Control: The main task of the load control algorithm is to measure the cell
load and prevent the system from becoming overloaded. Should this happen, the
load control algorithm returns the system both quickly and controllably to the
normal load state defined during the radio network planning phase [4, pp 267].

Packet Scheduler: The packet scheduler takes care of scheduling radio resources
for the best-effort traffic in both the uplink and the downlink directions
[4, pp 278].

Resource Manager: The main function of the resource manager is to allocate
downlink spreading codes when the admission control entity or the packet
scheduler requests this function. The resource manager also optimizes the usage
of the code tree in a cell [10, pp 244].



21
Connection Based Algorithms:
Handover Control: Handover control serves in two purposes. Firstly, it ensures
that the user equipment is connected to the strongest cell at all times. This helps to
control the interference level in the network by minimizing the transmission
power. Secondly, handover control supports user mobility by ensuring that the
radio connection is uninterrupted while the user equipment moves in the network
[10, pp 211].
Power Control: Since the capacity of any CDMA system is limited by
interference, it is crucial that all base stations and terminals in the radio access
network use the least possible transmission power. The purpose of power control
is to use as little transmit power as possible in both uplink and downlink while
maintaining the quality of the connection [4 , pp 55].

From this thesis point of view, the Handover Control algorithms will be examined in
detail in the following sections.
3.2 Handover Control
Mobile phones can maintain their connections in cellular networks when they move
from one cell area to another. The procedure, which switches a connection from one
base station to another, is called a handover (HO) or a handoff. It is possible that an HO
does not involve a change of the base station but only a change of radio resources
[3, pp 37-38].
The primary function of the handover control algorithm is to monitor the quality of a
dedicated radio connection, and to perform a soft or a hard handover if the quality is
insufficient. Briefly, maintaining seamless communication for mobile users is the main
duty of handover control algorithms.



22
There are various reasons that could cause a handover for an UE. The reasons can be
[ 11, pp 15]:
Uplink quality (e.g. bit error rate (BER))
Uplink signal measurements (e.g. received signal code power (RSCP) for TDD)
Downlink quality (e.g. Transport channel BLER)
Downlink signal measurements (e.g. CPICH RCSP, CPICH

, Pathloss)
Distance
Change of service
Operation & Maintenance intervention
Directed retry
Traffic load
Pre-emption

From Radio Network Controller point of view there are 4 different types of handovers:
Intra-System Intra-Frequency Handover: Soft Handover (SHO)
Inter-System Handover (GSMWCDMA)
Intra-System Intra-Frequency Hard Handover
Intra-System Inter-Frequency Handover
3.2.1 Intra-System Intra-Frequency Handover: Soft Handover(SHO)
Soft Handover (SHO) is a general feature in wireless systems, such as WCDMA, in
which neighbouring cells are operated on the same frequency. When in Connected
Mode, the user equipment (UE) continuously measures serving and neighbouring cells
(cells indicated by the RNC) on the current carrier frequency. Periodically, the UE
compares the measurement results with HO thresholds provided by the RNC. When the
reporting criteria is fulfilled and UE sends a measurement report back to the RNC
indicating the SHO presence. The decision algorithm of SHO is located in the RNC.
Because of this measurement reporting SHO is a Mobile Evaluated Handover (MEHO)
[10, pp 212].
23

Figure 15 : Soft Handover [3, pp 38]
Softer Handover: A softer HO is an HO between two sectors of a cell. From a UEs
point of view, it is just another SHO. The difference is only meaningful to the network,
as a softer HO is an internal procedure for a Node B, which saves the transmission
capacity between Node Bs and the RNC [3, pp 39]. In the uplink, the signal from the
mobile station MS is received at different sectors, which are combined in softer
handover by using Maximal Ratio Combining (MRC) and in soft handover by using
selection combining [10, pp 179]. In softer handover with MRC of the signals from
different sectors, the gain is slightly bigger than in soft handover with selection
combining [10, pp 88].

Figure 16 : Softer Handover [3, pp 270]
24
The main objectives of soft / softer HO are the following [10, pp 212]:
Optimum fast closed-loop Power Control (PC), as the UE is always linked with
the strongest cells.
Seamless HO without any disconnection of the Radio Access Bearer (RAB).
To enable a sufficient reception level for maintaining communications by
combining the received signals (macro-diversity) at symbol level from multiple
cells in cases when the UE moves to cell boundary areas, and cannot obtain a
sufficient reception level from a single cell.
Furthermore, the macro-diversity gain achieved by combining the received
signal in the Node B (softer HO) or in the RNC (SHO) improves the uplink
signal quality and thus decreases the required transmission power of the UE
3.2.2 Inter-System Handover
At the start of WCDMA deployment, handovers to GSM were needed to provide
continuous coverage, and handovers from GSM to WCDMA can be used to lower the
(congestion) loading in GSM cells [4, pp 254]. When the coverage areas of WCDMA
and the neighbouring system overlap each other, an Inter-System Handover (ISHO) can
be used to control the load between the systems [10, pp 214]. When the traffic in
WCDMA networks increases, it is important to have load reason handovers in both
directions. The inter-system handovers are triggered in the source RNC / BSC, and from
the receiving system point of view, the intersystem handover is similar to inter-RNC or
inter-BSC handover. The handover algorithms and triggers are not standardised
[4, pp 254].


Figure 17 : Inter-system handovers between GSM and WCDMA [4, pp 255]
25
In a practical example, speech connections can be handed over to a neighbouring
second-generation (2G) system and data connections handled within the WCDMA
system. Inter-System Handover (ISHO) is a Hard Handover (HHO) and it causes
temporary disconnection of the Real Time (RT) Radio Access Bearer (RAB). When an
RT RAB is handed over from one system to another, the Core Network (CN) is
responsible for adapting the Quality of Service (QoS) parameters included in the RAB
attributes according to the new system [10, pp 214].

Figure 18 : Inter-system handover procedure [4, pp 256]
The inter-system measurements are not active all the time but are triggered when there
is a need to make intersystem handover. The measurement trigger is a Radio Network
Controller (RNC) vendor-specific algorithm and could be based, for example, on the
quality (block error rate, BER) or on the required transmission power. When the
measurements are triggered, the User Equipment (UE) measures first the signal powers
of the GSM frequencies on the neighbour-list. Once those measurements are received
by RNC, it commands the UE to decode the BSIC (base station identity code) of the
best GSM candidate. When the BSIC is received by RNC, a handover command can be
sent to the UE. The measurements can be completed in approximately 2 seconds
[4, pp 255].

26
The RNC recognises the possibility of Inter System Handover (ISHO) based on the
configuration of the radio network (neighbour cell definitions and relevant control
parameters). In case the second system is a GSM system, the decision algorithm of the
ISHO from GSM to WCDMA is located in the GSM Base Station Controller (BSC).
From the viewpoint of the RNC, an ISHO from GSM to WCDMA does not differ from
the inter-RNC HHO. Correspondingly, an ISHO from WCDMA to GSM does not differ
from the inter-BSC HO from the viewpoint of the GSM BSS. As with inter-frequency
measurements, the User Equipment (UE) must be either equipped with a second
receiver or support Compressed Mode (CM) to execute inter-system measurements
[10, pp 214].

3.2.2.1 Compressed Mode
Intra-frequency neighbours can be measured simultaneously with normal transmission
by the UE using a RAKE receiver. Inter-frequency and inter-system measurements,
however, require the UE to measure on a different frequency. This can be done by
incorporating multiple receivers in the UE. A second possibility that avoids receiver
multiplicity is stopping the normal transmission and reception for a certain time period,
enabling the UE to measure on the other frequency [10, pp 223].

WCDMA uses continuous transmission and reception and cannot make inter-system
measurements with a single receiver if there are no gaps generated in the WCDMA
signals. Therefore, compressed mode is needed both for inter-frequency and for inter-
system measurements [4, pp 255]. Inter-system handovers from GSM to WCDMA are
initiated in GSM BSC. No compressed mode is needed for making WCDMA
measurements from GSM because GSM uses discontinuous transmission and reception
[4, pp 258].
27

Figure 19 : Compressed Mode pattern [ 10, pp 224]
During the gaps of the compressed mode, the fast power control cannot be applied and
part of the interleaving gain is lost [4, pp 256]. The RNC algorithms for activating the
compressed mode are important to guarantee reliable handovers while maintaining low
compressed mode usage [4, pp 257].
The RNC determines which frames are compressed, and sends the information both to
the Node B and to the UE. There are three methods to generate the gaps to use CM
[10, pp 223]:
Reducing the data rate used in the upper layers (higher layer scheduling);
Reducing the symbol rate used in the physical layer (rate matching and/or
puncturing).
Spreading factor splitting (halving the spreading factor doubles the available
symbol rate).
Compressed mode also affects the uplink coverage area of the real time services where
the bit rate cannot be lowered during the compressed mode. Therefore, the coverage
reason inter-system handover procedure has to be initiated early enough at the cell edge
to avoid any quality degradation during the compressed mode [4, pp 257].

Figure 20 : Effect of compressed mode on the coverage [4, pp 257]
28
3.2.3 Intra-System Intra-Frequency Hard Handover
Hard-handover (HHO) is a category of handover (HO) procedures in which all the old
radio links of a user-equipment (UE) are released before the new radio links are
established. For real-time (RT) bearers it means a short disconnection of the bearer, for
non-real-time (NRT) bearers HHO is lossless [10, pp 211].
Intra-frequency HHO is needed when cells participating in the HO are controlled by
different RNCs in situations when the inter-RNC HO cannot be executed as a soft-
handover (SHO) or if SHO is not allowed (Intra-frequency HHO causes temporary
disconnection of the RT RAB but is lossless for NRT bearers). Its decisions are made
by the RNC based on the intra-frequency measurement results the UE is sending
periodically after it has reported an intra-frequency triggering event and the active set
could not be updated, and relevant control parameters. The reports are usually applied to
the SHO procedure, so intra-frequency HHO is a mobile station evaluated handover
(MEHO) [10, pp 213].

By performing an HHO when SHO is not possible, excessive interference can be
avoided. During the HHO procedure all links in the active set are replaced
simultaneously by one new link [10, pp 213].
3.2.4 Intra-System Inter-Frequency Handover
Inter-frequency Handover (IFHO) is a hard-handover (HHO) between different
WCDMA carriers required to ensure a handover (HO) path from one cell to another cell
in situations when different carriers have been allocated to the cells in question. Also,
HHO here means that IFHO causes temporary disconnection of the real-time radio
access bearers (RT RAB) and is lossless for non-real-time (NRT) bearers. IFHO also
enables handovers between separate layers of a multi-layered cellular network e.g., a
network consisting of macro- and micro-cells where the cell layers are using different
carriers. The radio access network handover controller (RAN HC) should support the
following types of IFHO [10, pp 213]:
intra-Base Station (BS) HHO (to control the load between carriers)
intra-RNC HHO
inter-RNC HHO
29
IF-HO is a Network Evaluated Handover (NEHO) since its evaluation algorithm is
located in the RNC. The RNC recognises the possibility of an IFHO based on the
configuration of the radio network (frequency / carrier allocation, neighbour cell
definitions, cell layers etc.). When a UE is located where an IFHO is possible and
needed, the RNC commands the UE to start inter-frequency measurements and to report
the results periodically. HO decisions are then made by the RNC based on those
measurement results (inter and intra-frequency) and relevant control parameters
[10, pp 213 - 214].
3.3 Handover Measurements
Handover Measurements are important for the decisions that are derived by handover
algorithms. HO measurement reporting can be divided into the following stages:
1. Neighbour cell definitions
2. Measurement reporting criteria
3. Reporting of measurement results
3.3.1 Neighbour Cell Definitions
For each cell in the UTRAN an own set of neighbouring cells must be defined in the
radio network configuration database, typically located in the RNC. Since a
neighbouring cell may be located in the same network on the same frequency, on a
different frequency or in any neighbouring Public Land Mobile Network (PLMN), the
following neighbour lists need to be defined for each cell in case the corresponding HO
needs to be supported [10, pp 215]:
Intra-frequency neighbour cell list: The UE must be able to monitor at least 32
cells on the same WCDMA carrier frequency as the serving cell.
Inter-frequency neighbour cell list: The UE must be able to monitor at least 32
cells on a maximum of two WCDMA carrier frequencies in addition to the
serving cells frequency.
Inter-system neighbour cell lists: For each neighbouring PLMN, an own list is
needed. In total a maximum of 32 inter-frequency neighbours must be supported
by the UE.

30
The RAN broadcasts the initial neighbour cell list(s) of a cell in the system information
messages on the BCCH (Broadcast CCH). In case a required ASU has been performed,
a new neighbour list is combined in the RNC based on the neighbour lists of the cells in
the new active set and then is sent to the UE on the DCCH.

To identify a WCDMA neighbour cell, this list includes the following information
[10, pp 215]:
UTRAN Cell Identifier:
o Global RNC identifier (PLMN identifier MCC and MNC);
o Cell Identifier (CI).
Location Area Code (LAC).
Routing Area Code (RAC).
UTRA Absolute Radio Frequency Channel Number (UARFCN).
Scrambling code of the P-CPICH.

For a GSM neighbouring cell, the following information is sent:
Cell Global Identification (CGI), Mobile Country Code (MCC), Mobile
Network Code (MNC),
CGI = MCC + MNC + LAC + CI
BCCH frequency
Base Station Identity Code (BSIC), Base Station Colour Code (BCC), Network
Colour Code (NCC)
BSIC = BCC + NCC

Neighbour Cell Search on Current Carrier Frequency
In idle mode as well as in connected mode the UE continuously searches for new cells
on the current carrier frequency. If the UE detects a candidate cell that has not been
defined as a neighbouring cell, it has to decode the cells BCCH to identify the cell
before it can report the measured

of the detected neighbouring cell to the RNC. In

this case, the following Information Elements (IEs) are used to identify the undefined
neighbouring cells: the downlink scrambling code, LAC and CI. When reporting the
measurement result, the UE may or may not include this information in the
measurement report [ 10, pp 215].
31
3.3.2 Measurement Reporting Criteria
Depending on the handover (HO) type (mobile evaluated handover (MEHO) or network
evaluated handover (NEHO)), different measurement reporting criteria can be used. The
RNC may request the UE to execute and report the following different types of basic
HO measurements:
intra-frequency measurements (MEHO)
inter-frequency measurements (NEHO)
inter-system measurements (NEHO)
UE internal measurements

All HO measurement types are controlled independently of each other and are defined
on a cell-by-cell basis, with the exception of UE internal measurements, which are
partly controlled by parameters common to all cells under the same RNC. Two or more
HO measurement types can be active simultaneously e.g., intra- and inter-frequency
measurements. Typically, in a RAN separate measurement parameter sets for RT and
NRT bearers and for users applying HSDPA can be defined. Control of the HO
measurements is explained in detail in the following sections in connection with the
relevant HO types [ 10, pp 216].
3.3.2.1 Intra-Frequency Handover Measurements
The RAN broadcasts the measurement reporting criteria (measurement parameters) for
intra-frequency measurements on the BCCH. When the criteria are fulfilled, the UE
reports the results of its measurements to the RNC. The RNC in turn makes the HO
decision. If the ASU could not be executed, the UE continues to measure the
neighbouring cells but changes to periodic reporting of the results. For this type of
measurements the UE uses separate measurement reporting criteria transmitted to the
UE [ 10, pp 216].
3.3.2.2 Inter-Frequency and Inter-System Handover Measurements
Inter-frequency and inter-system measurements are both made only when ordered by
the RNC. They use separate measurement reporting criteria transmitted to the UE.
When they are initiated, the UE periodically reports the results to the RNC. The
32
measurements are controlled by two parameters: reporting duration and the reporting
interval [ 10, pp 216].
3.3.2.3 User Equipment Internal Measurements
UE internal measurement reporting criteria are controlled partly on a cell-by-cell basis
and partly by parameters common to all cells in the whole RNC. The measurement
information for UE internal measurements is not included in the system information on
the BCCH but transmitted to the UE on a Dedicated CCH (DCCH). When the
measurement-reporting criteria are fulfilled, the UE reports the results of its
measurements to the RNC [ 10, pp 216].
3.3.3 Reporting of Measurement Results
When the UE reports the measurement results from the intra- or inter-frequency
measurements of the neighbouring cells back to the UTRAN, the following IEs are
included to identify the neighbours [ 10, pp 217]:
P-CPICH information (downlink scrambling code) identifies active and
monitored cells when the UE reports intra-frequency or UE internal
measurement results to the RNC.
P-CPICH information and UTRA RF (Radio Frequency) channel number
identifies neighbouring cells when the UE reports IF measurement results to the
RNC.
BCCH frequency identifies neighbouring GSM cells when the UE reports IS
(GSM) measurement results to the RNC. The BSIC can be used additionally to
verify identification if two or more neighbouring GSM cells have the same
BCCH frequency. The RNC always applies the BSIC verification for the target
cell before the execution of IS-HO so that the UE can synchronise with the GSM
cell before HO execution. The UE reports the BSIC information only if it is
requested by the RNC.




33
The UE generates at least the following event-triggered and periodic measurement
reports [ 10, pp 217]:
event-triggered intra-frequency measurement report
periodic intra-frequency measurement report
inter-frequency measurement report
inter-system measurement report
measurement reports on common channels
traffic volume measurement report
UE internal measurement report
quality deterioration report

3.3.3.1 Reporting of Intra-frequency Measurements
Intra-frequency measurement reporting can be either event-triggered or periodic. During
connected mode, the UE constantly monitors the P-CPICH

of the cells defined by

the intra-frequency neighbour cell list and evaluates the reporting criteria. If one of the
reporting events is fulfilled, the UE sends an event-triggered measurement report.
Before the P-CPICH

of a cell is used by the HO algorithm in the UE, an arithmetic

mean of a certain number of the latest measured values is taken. The number of the
values taken into account is a UE performance specification parameter. The average is
taken over the linear values of

, not the dB values [ 10, pp 217].

34

Figure 21 : Intra-frequency Measurements [10, pp 219]
For intra-frequency measurement criteria, the following reporting events are defined
[ 10, pp 218]:
Event 1A: A P-CPICH enters the reporting range. A report is triggered when the
equation below is fulfilled:

where

is the measurement result of the cell entering the reporting range;

is the cell-individual offset of the cell entering the reporting range;

is a measurement
result of a cell in the active set not forbidden to affect the reporting range;

is the
number of cells in the current active set not forbidden to affect the reporting range;

is the measurement result of the strongest cell in the active set; is a weighting
parameter sent from the RNC to the UE;

is the reporting range constant for Event

1A sent from the RNC to the UE; and

is the hysteresis parameter for Event 1A. The

hysteresis parameter together with the reporting range constant is usually called the
addition window.
35
Event 1B: A P-CPICH leaves the reporting range. A report is triggered when the
equation below is fulfilled:

where

is the reporting range constant for event 1B sent from the RNC;

is the
measurement result of the cell leaving the reporting range;

is the cell individual

offset of the cell leaving the reporting range; and

is the hysteresis parameter for

Event 1B. The hysteresis parameter together with the reporting range constant is usually
called the drop window.

Event 1C: A non-active P-CPICH becomes better than an active one. A report is
triggered when the equation below is fulfilled i.e., when a P-CPICH that is not in the
active set gets better than the worst P-CPICH from the active set when the active set is
full. Used to replace the cell with the worst P-CPICH:

where

is the measurement result of the cell in the active set with the lowest
measurement result;

is the cell-individual offset for the cell in the active set that
is becoming worse than the new cell; and

is the hysteresis parameter for Event 1C.

The hysteresis parameter is usually called the replacement window.

Event 1D: Change of best cell. A report is triggered when any P-CPICH in the
reporting range becomes better than the current best plus an optional hysteresis value.

Event 1E: A P-CPICH becomes better than an absolute threshold. A report is triggered
when a new cell plus its cell-individual offset becomes better than an absolute threshold
plus an optional hysteresis value.

36
Event 1F: A P-CPICH becomes worse than an absolute threshold. A report is triggered
when a new cell plus its cell-individual offset becomes worse than an absolute threshold
minus an optional hysteresis value.
3.3.3.2 Time-to-trigger Mechanism
The abundance of possible neighbouring cells together with the variety of triggering
events could result in quite frequent reporting. To protect the network from an excessive
signalling load, each of the reporting events can be connected with a timer. Only if the
measurement criteria have been fulfilled during the whole period until the timer expires
is the event reported to the network. Figure 22 shows an example of the time-to-trigger
mechanism in case of Event 1A. On the first two occasions when the event occurs, no
report is triggered, since P-CPICH 3 does not stay within the reporting range for a long
enough time. Only the third occurrence triggers the reporting of Event 1A [ 10, pp 219].

Figure 22 : Time-to-trigger Mechanism for Event 1A [10, pp 219]
3.3.3.3 Event-triggered Periodic Reporting
Reporting one of the above-mentioned events typically results in an active set update.
However, if the active set update cannot take place, owing to lack of capacity or
hardware resources, for example, the UE changes to periodic reporting. In this case it
sends a measurement report every reporting interval until the active set update has taken
place, the measurement criteria are no longer fulfilled or the maximum number of
measurement reports has been sent [ 10, pp 220].
37
3.3.3.4 Mechanism for Forbidding a Neighbouring Cell to Affect the Reporting
Range
In case of Events 1A and 1B when the weighting coefficient, W, is non-zero, all cells in
the active set are used to evaluate whether or not the measurement criteria are fulfilled.
In a RAN, however, it could be beneficial to exclude a specific neighbouring cell i.e.,
its P-CPICH from this active set weighting: for example, when the P-CPICH of that
cell is very unstable within the reporting range. For this case, a neighbouring cell
parameter can be specified for each cell, indicating whether or not this cell is allowed to
affect the reporting range calculation when it is in the active set [ 10, pp 220].
3.3.3.5 Cell-individual Offsets
To have an efficient means of reporting a monitored cell individually, a P-CPICH offset
can be assigned to each neighbouring cell. The offset can be either positive or negative.
The UE then adds this offset to the measurement quantity (

, path loss or RSCP)

before it evaluates whether a reporting event has occurred [ 10, pp 220].
3.3.3.6 Reporting of Inter-frequency and Inter-system Measurements
Inter-frequency and inter-system measurement reports are always periodic. The events
triggering them are not part of the standards. The RNC may initiate inter-frequency
and/or inter-system measurements in various circumstances, for example [10, pp 221]:
Average downlink transmission power of a radio link as it approaches its
maximum power level
Uplink transmission power reaches a threshold or its maximum (events 6A/6D,
see below)
Quality deterioration report from uplink outer-loop PC from the RNC
Quality deterioration report from the UE
Unsuccessful SHO (branch addition) procedure
Unsuccessful RAB setup
UE located within cell where SHO capability is restricted
UE located within cell where admitted user bit rate is lower than requested
Frequent SHOs (cell size and UE speed do not match)
Radio network recovery management initiates forced HO procedure
38
UE located within an area where cell structure is hierarchical (inter-frequency)
UE located within an area where hierarchical network structure is composed of
WCDMA and GSM systems (inter-system only)
IMSI-based HO is needed
UE located within a cell with restricted intra-system HO capability (inter-system
only)

3.3.3.7 UE Internal Measurements
UE internal measurements can be divided into two groups. The first group is used to
indicate to the network the status of the UE transmit power. The reports may be used by
the RNC to trigger off inter-frequency or inter-system measurements. The second group
is the UE RxTx (ReceiverTransmitter) time difference measurement. It is used to
adjust the downlink DPCH air interface timing when the difference in time between the
UE uplink DPCCH/DPDCH frame transmission and the first significant path of the
downlink DPCH frame from a measured active set cell (UE RxTx time difference)
becomes too large[10, pp 221].
The following events are specified in 3GPP specifications [ 12]:
Event 6A: UE transmit power becomes larger than an absolute threshold.
Event 6B: UE transmit power becomes less than an absolute threshold.
Event 6C: UE transmit power reaches its minimum value.
Event 6D: UE transmit power reaches its maximum value.
Event 6E: UE RSSI (Received Signal Strength Indicator) reaches the UE
receiver dynamic range.
Event 6F: UE RxTx time difference for a radio link included in the active set
becomes larger than an absolute threshold.
Event 6G: UE RxTx time difference for a radio link included in the active set
becomes less than an absolute threshold.


39
3.3.3.8 Node B Measurements
The Node B measurement report can be used to trigger off inter-frequency or
intersystem (GSM) measurements, and to balance the PC (uplink and downlink) of the
diversity branches during SHO. The Node B sends the measurement report to the RNC
on a radio link by radio link basis at regular (e.g., 5001000 ms) intervals. The
measurement report from the Node B includes the following radio link measurement
results [10, pp 222]:
Average downlink transmission power of the DPCH
Average measured uplink SIR of the DPCH
Uplink SIR target currently used on the DPCH


40

4 Radio Network Controller (RNC)

4.1 UTRAN network elements: Standard concept







Figure 23 : UTRAN Network Elements
The key functions of the Radio Network Controller (RNC) are management of
terrestrial channels, management of radio channel configurations in the Radio Access
Network (RAN), radio resource management, telecom functionality, transmission &
transport features and maintenance & operation. They are briefly explained in the
following sub chapters and more in detail throughout this document.

Defined RNC roles [ 13, pp 29]:
1. Serving RNC: Role an RNC can take with respect to a Radio Resource Control
(RRC) connection between an UE and RAN. There is one Serving RNC for each
UE that has a connection to RAN. The Serving RNC is in charge of the radio
connection between a UE and the RAN. The Serving RNC terminates the Iu
interface for this UE.
2. Drift RNC: A role an RNC can take with respect to a specific connection
between an UE and RAN. An RNC that supports the Serving RNC with radio
resources when the connection between the RAN and the UE need to use cell(s)
controlled by this RNC is referred to as Drift RNC
Node B

UTRAN
Core Network
Iub
Iur
RNC
Node B
Iub
Node B

Iub
RNC
Node B
Iub
RNS RNS
Iu Iu
41
3. Controlling RNC: A role an RNC can take with respect to a specific set of
BTS's. There is only one Controlling RNC for any BTS. The Controlling RNC
has overall control of the logical resources of its BTS's. Both serving and
drifting RNCs serve as controlling RNC for the cells they control.
4.2 Nokia Siemens Networks RNC Solutions
4.2.1 IPA2800 Platform
Nokia Siemens Networks continues the work that its predecessor, Nokia Networks, did
earlier as a developer of network elements. A network element is a complex network of
inter-connected computer units. The system consists of various computers with different
tasks of their own, communicating with each other via message connections.

As Jyri Ilama mentioned in his masters thesis: In early 70s, the research and
development process of DX200 started at Nokia Networks and the first customer
deliveries took place in the year 1980, in the form of a Fixed Network Switching Centre
(FNC). Later, multiple DX200 based products have been developed, such as MSC, HLR
and BSC. Anyhow, the capacity and performance of the old DX200 started to become
obsolete before the turn of millennium, and it was discovered that this system wont be
able to handle the requirements of telecommunication systems of the third generation.
This was the need that started the developing of IPA2800 a DX200 based system,
which is much more efficient and clearer of its architecture than its predecessor was.
But, IPA2800 is not a substitute for DX200: it works in parallel with these old systems,
hand in hand, offering new resources and possibilities that are needed by the third
generation systems. IPA2800 was designed to be much simpler than DX200 from the
architectural point of view [ 14, pp 15].





42
4.2.2 cRNC
cRNC is the classic RNC solution of Nokia Networks and Nokia Siemens networks that
has been developed since 90s. The general functional architecture of the RNC is shown
in Figure 24. The RNC consists of four parts: network interface functions, switching
and multiplexing functions, user plane functions and control functions.


Figure 24 : Functional architecture of the cRNC [ 13, pp 31]
DMCU Data and Macro diversity Combining Unit
EHU External Hardware Alarm Unit
HDD Hard Disk Drive for OMS
ICSU Interface Control and Signalling Unit
MXU Multiplexer Unit
NPGE Network Processor Interface Units Gigabit Ethernet
NPS1 Network Processor Interface Unit STM-1
MXU
MXU
SFU
I CSU
DMCU
RSMU
OMU
WDU
NI P (NI P!)
NPS1(P)
DMCU DMCU
TBU
EHU EHU
MXU
NI P (NI P!)
NPGE(P)
Ethernet
HDD
OMS
SWU
Ethernet
Ethernet
I CSU I CSU
43
OMS Operation and Maintenance Server
OMU Operation and Maintenance Unit
RSMU Resource and Switch Management Unit
SFU Switching Fabric Unit
SWU Switching Unit (Ethernet)
TBU Timing and Hardware Management Bus Unit
WDU Winchester Drive Unit for OMU

In the scope of this thesis, only Handover/Mobility related functional units of cRNC
will be analyzed and explained.
The Operation and Management Unit (OMU) performs the basic system
maintenance functions such as hardware configuration, alarm system and
centralized recovery functions. It also contains cellular related functions such as
performance management, radio network management, radio network recovery,
databases and state management.

The Interface Control and Signalling Unit (ICSU) provides the signalling
protocols for Iu, Iub, Iur and Uu interfaces (NBAP, RNSAP, RANAP, RRC,
AAL2). It is also responsible for termination of the SAAL signalling links,
monitoring and recovery of the signalling links, admission control, handover
control, load control, radio resource scheduling and management and cell based
locationing for LCS.


Distributed Signal Processing Unit (DMCU) that provides support for macro
diversity handovers and packet data processing as well as other L2 functions
related to radio interface.


44
4.2.3 mcRNC
mcRNC is the new generation of the RNC solution in Nokia Siemens Networks which
has a completely new hardware architecture and changes platform and the software side
because of the increased capacity and performance requirements. As the mcRNC has
only one type of processing hardware, it allows in theory a large degree of freedom in
design of functional software architecture. In reality, the reuse of existing software as
well as logical structure of RNC limits the option space.

Similar as cRNC; mcRNC can also expressed with 4 planes Control Plane, User
Plane, Transport Plane and Management Plane.

In mcRNC architecture, the services of the Control Plane and User Plane are
functionally divided based on whether they are provided for a specific UE, common
entities like BTS and cells or centralized in the Network Element for architectural
reasons. The resulting functional units are:
CSCP Cell Specific functions and services in Control Plane
USCP UE Specific functions and services in Control Plane
CFCP Centralized Functions and services in Control Plane
CSUP Cell Specific functions and services in User Plane
USUP UE Specific functions and services in User Plane. This includes the
dedicated and shared channel services since they are relevant for a UE.

The Transport plane is divided based on whether it provides services for the internal
network (also referred to as backplane) or external network (external interfaces).
SITP Signalling Transport Plane
EITP External Interface functions in Transport Plane.
Backplane - The internal backplane is realized using the Ethernet switch (internal side),
a program block from the application domain resembling a Service Access Point (SAP)
and services provided by IPA Light including the kernel module for transferring DMX
messages.

45
4.3 RNC SW Architecture
4.3.1 Structural View
cRNC: The general structure of RNC SW architecture that consists of IPA2800 ATM
platform and RNC application parts is depicted in Figure 25. RNC Network Element
includes SW on top of three different Operating Systems; DMX, Chorus and OSE.










Figure 25 : cRNC SW architecture [ 13, pp 38]
mcRNC: As it is seen on Figure 26, the general structure of the SW architecture
remains similar to that of cRNC but the notable differences are in the removal of OMS
as a unit of RNC and the change of platforms and middleware that support the new
hardware and Linux OS.









Figure 26 : mcRNC SW architecture [ 13, pp 39]
Switching
Platform
Software
Signal
Processing
Platform
Software
RNC Application Software
Fault Tolerant
Computing
Platform
Software
Modular and Scalable Hardware

Platform



Adjunct
Platform
(OMS)
API API API API
Applications
Switching
Platform
Software
Signal
Processing
Platform
Software
(UMW)
RNC Application Software
Fault Tolerant
Computing
Platform
Software
Modular and Scalable Hardware

Platform
API API API
Applications
Flexi PF + IPA Lite
46
4.3.2 SW Architecture
The essentials of the software architecture solutions of the RNC have been the
following attributes:
modular system
communication
redundancy
variations

The software of the RNC consists of various independent software components such as
process families, libraries and files. The software is very modular and hence easier to
modify and develop than a large monolithic entity [ 15].

The software components are loosely coupled together. Each component implements a
functional entity, which functions very independently. On the other hand, each
component needs each other to form a system. The RNC contains a message bus which
provides a connection for different components in different physical locations [ 15].

A real-time system needs the work contribution of every component all the time. Each
computer unit is duplicated into two, a working unit and a spare unit. The working unit
is the one which provides the services. The spare unit is taken into use if the working
unit malfunctions. The functionality is called the switchover. The switchover is a
procedure which provides fast recovery from a malfunction of a computer unit. The
switchover requires that the spare unit is available to take over the functionalities of the
working unit without delays. In a switchover procedure, all content of all critical
variables, files, time supervisions, buffers and utility libraries need to be copied into the
spare unit. Critical information is information which needs to be precisely identical in
the working and in the spare unit in order for a process to function correctly. The
copying process is called a warming process [ 15].




47
Different customers need different services. Usually, there are different variations of the
software package available. Because of the modularity, a version update of a software
component or an addition of a software component is relatively easy. This requires
efficient version control on a component level as well as on a software package level
[ 15].
4.3.3 Service model architecture
The service model means that when executing a task, a process may delegate parts of
the task to other processes. What needs to be done defines the services that the other
process needs to provide. The whole system can be seen as a network of responsibilities
and services. The services become an interface to the process and the outside world sees
only the service interfaces [ 13, pp 40].

The service model SW is divided into three levels: system blocks, service blocks and
program blocks [ 13, pp 40]:
System block (SYB) is hierarchically the highest block and it offers a defined
number of related services and implements a defined number of functions.
Service block (SEB) is a part of the implementation of a system block offering
certain system block services to others and a number of services used within the
system block.
Program blocks (PRB) is the actual implementation of the service blocks.
Program blocks implement the services of service blocks.









Figure 27 : Service model architecture [ 13, pp 40]
System Block (SYB)
Service Block A (SEB)
Program Block X
(PRB)
Program Block Y
(PRB)
Service Block B (SEB)
Program Block I
(PRB)
Program Block J
(PRB)
Service Block C (SEB)
Program Block U
(PRB)
Program Block V
(PRB)
Service Block D (SEB)
Program Block M
(PRB)
Program Block N
(PRB)
48
In the block model illustrated by Figure 27, the services can be hidden, so that program
blocks belonging to different service blocks do not see each others service definitions
[ 13, pp 40].
4.3.4 Process Family
A software block is usually implemented as a process family. A process family is a
group of independent, dynamically allocated state machines. One of the state machines
is on the controlling position towards others. The controlling state machine exists
always after the activation of the program [ 15].

A process family consists of a master process and various number of hand processes. A
process family can also be implemented without the hand processes. The master
functions as the controlling state machine. In a process family, the master process is a
service point where service requests are handled. The master process may handle the
request and offer the services or it may create a hand process to do the work [ 15].

4.4 Radio Resource Management of WCDMA RAN Service
Block
Radio Resource Management of WCDMA RAN Service Block is responsible for air
interface resource allocation in RAN. Its main task is to optimize the use of the
available radio resources, such as transmitter power and the usage of spreading codes in
order to provide users with the largest possible capacity for given coverage and quality-
of-service requirements [ 13, pp 46]. Radio Resource Management of WCDMA RAN
Service Block provides Load Control, Admission Control, Packet Scheduler, Code
Management and Handover Control functionalities to the RNC application.







49












Figure 28 : Radio Resource Management of WCDMA RAN Service Block
Diagram [ 13, pp 48]
Task division inside service block:
Handover Control Algorithm Program Block is responsible for handover
control of UEs.
Base station Resource Manager Program Block is responsible for load
control, admission control, code management and packet scheduling of base
stations.
User Equipment Radio Resources Program Block manages UE specific radio
resources.
RNW management can be divided into three functionalities from Radio Resource
Management of WCDMA RAN Service Block point of view [ 13, pp 48]:
a) RNW parameter management contains the management and access routines for
the radio network configuration database. Radio Resource Management of WCDMA
RAN Service Block both reads and receives via message interface radio network
parameters from the RNW database in OMU unit. However, base transceiver station
(BTS) and cell related radio network parameters are delivered inside ICSU/CSCP via
message interface to Base station Resource Manager Program Block first when
BTS/cell is setup and thereafter whenever those parameters change.
MS Connection
Control
NBAP
protocol
L2 Services
MAC
Transport
Resource
Management
Location
Services
RNW
Management
PM
Services
Handover Control
Algortihm Program
Block
User Equipment
Radio Resources
Program Block
Radio Resource
Management of WCDMA
RAN Service Block
Base station
Resource Manager
Program Block
50

b) BTS and cell configuration management in ICSU/CSCP is responsible for BTS
and cell setup and cell state handling inside ICSU/CSCP. Base station Resource
Manager Program Block receives information about cell states through this interface.
Base station Resource Manager Program Block provides common channel DL
spreading codes for CCH setup purposes.

c) BTS and cell recovery management in OMU is responsible BTS and cell
recovery procedures. This interface is also used for triggering cell recovery
procedures.

PM Service collects statistical counter data from applications. PM Service interface is
used to deliver statistical counter data for traffic and cell resource measurements.
Counter data collection is performed through Distributed Statistics Mediator library,
which is linked to each provider application. This interface is also used for online
monitoring.

User Equipment (UE) connection management controls the UE mobility and
connections between UE, RNC, and core network (CN) and performs related signalling
at L3 level (also handover (HO) signalling). UE connection management uses UE
resource management services for RAB related operations.
NBAP protocol: Node B Application Part (NBAP) protocol sends periodically cell
specific load information and radio link specific load information from BTS. Dedicated
BTS measurements are controlled and reported through NBAP.
Layer 2 services offer radio lank control (RLC) and medium access control (MAC)
protocols. MAC protocol is informed whether common channels can be used for data
transfer in downlink direction (depends on load conditions in radio interface). Also it is
used for reserving Data and Macro Diversity Processor Group (DMPG) resources for
HSDPA channels.
Transport resource management offers a service through which HS-DSCH transport
resource allocation can be performed.
51
Location services (LCS) request Handover Control Algorithm Program Block to
perform assisted GPS measurement. Handover Control Algorithm Program Block
delivers LCS related measurement results (assisted GPS measurement, Rx-Tx
measurement) to location services.
4.4.1 The Interface Control and Signalling Unit
The Interface Control and Signalling Unit (ICSU) performs all the signalling
transactions towards the other network elements and UE. The unit is responsible for the
following tasks:
Signalling protocols to Iu, Iub, Iur and Iu-BC interfaces for
o NBAP, RNSAP, RANAP, SABP signalling
o ALCAP (Q.2630.1) signalling
o RRC signalling
Monitoring and recovery of the signalling links
Service Area Broadcast (SAB)
Radio resource management functions
o Admission control (AC)
o Handover control (HC)
o Load control (LC)
o Packet scheduling (PS)
Location service control functions
Through the focus of this thesis, handover related transactions take place in ICSU. In
other words ICSU has a key role in the success of handover functions.
4.4.2 Handover Control Algorithm Program Block
The functionality of handover control is implemented in Handover Control Algorithm
Program Block. Handover Control Algorithm Program Block has one master process
and several hand processes. A Handover Control Algorithm hand is created in serving
RNC together with the radio resource control (RRC) connection establishment for the
UE and it exists until the RRC connection is released. In drift RNC, Handover Control
Algorithm hand is created when the first radio link is established for diversity handover
and it exists until last radio link of the diversity handover is released. The software
52
architecture of Handover Control Algorithm Program Block and the interfaces to other
program blocks are illustrated in Figure 29.
Interfaces:
1 & 2) Handover Control Algorithm master uses the RNC RNW Database Library to
read the relevant operator defined RNC RNW parameters. RNC RNW Database Library
in turn uses RNW Database Manager to perform the actual (hand-) fast-reads from the
RNW Database. Handover Control Algorithm HC-master reads the relevant parameters
at process start up and stores them to its internal data structures. UE dedicated Handover
Control Algorithm HC-hand processes (HC-hand) have access to these parameters via
internal function interface. If the operator changes these parameters in the RNC RNW
database the Radio Network Manager sends a message including the modified
parameters to Handover Control Algorithm HC-master process.














Figure 29 : Handover Algorithms Program Block Diagram
ICSU
Handover Control
Algorithm Program Block
Handover
Control
Algorithm
Master


Handover
Control
Algorithm Hand
(UE specific)

Iur
Interface
Problem
Block
UE Radio
Resources
Program
Block
Location
Based Services
Program Block
NBAP
Protocol
Program Block
Base station
Resource Manager
Program Block

RRC
Protocol
Program
Block
OMU
RNC RNW
Database
Library and
Manager
Radio Network
Manager
Periodical
RNW
Measurement
Interface
Program Block
Statistic Report
Handler
Program Block
Monitoring
Tool Mediator
Distributed
Statistics
Mediator
1
2
3
4
5
6
7
Peer to Peer Program Block
Outer Loop
Power Control
8
9
11
10
53
3) This interface is for UE handover measurement. Dedicated RRC process provides
RRC protocol for dedicated radio connections. HC-hand receives UE handover
measurement reports and also sends and receives UE handover measurement control
messages via this interface.

4) There are two interfaces towards UER (UE Specific Radio Resources):
Start of Handover Control algorithm: UER requests HC-master to start handover
control algorithm (HC-hand) for UE connection. HC-hand is always started in
the same ICSU as the UER resides.
Handover algorithm main interface: This is an interface between UE specific
Radio Resources (UER) and handover control algorithm in HC-hand. All UE
specific control functions related to soft / softer / hard handovers / serving cell
change / compressed mode activation and deactivation are handled through this
interface.
Handover Control Algorithm Program Block triggers DCH to HS-DSCH
channel switching and vice versa (for not DCH 0/0).

5) This interface is for serving RNC (SRNC) BTS measurement reporting. HC-hand
receives dedicated BTS measurement reports in SRNC (NBAP) via this interface.
Control of dedicated BTS measurements is also performed through this interface.

6) This interface is for drifting RNC (DRNC) BTS measurement reporting. HA3-m
initiates common BTS measurements and receives measurement reports from DRNC
(RNSAP) via IUR control process. HC-hand initiates dedicated BTS measurements and
receives dedicated BTS measurement reports from DRNC (RNSAP) via dedicated Iur
process.

7) Base station Resource Manager Program Block provides cell load information to
HA3-m as well as it indicates need for load, service or HSPA Capability based
handover to HC-hand via this interface. This interface exists only if service and load or
HSPA capability based handover functionality is enabled.

54
8) This interface is for uplink DCH quality reporting. In serving RNC the outer loop
power control informs HC-hand about uplink DCH quality deterioration via this
interface.

9) Location Based Services Program Block sends request for assisted GPS measurement
to Handover Control Algorithm Program Block, which then later delivers the results of
assisted GPS measurement back to Location Based Services Program Block.

10) This interface is for Distributed Statistics Mediator. Distributed Statistics Mediator
is a statistical library module linked into Handover Control Algorithm Program Block.
Distributed Statistics Mediator provides functions related to statistical counter updates.
Periodical RNW Measurement Interface Program Block uses Distributed Statistics
Mediator interface to start and stop periodical measurements and to collect
measurement data from a data provider such as Handover Control Algorithm Program
Block. Data of active measurements is sent to Statistic Report Handler Program Block
based on Periodical RNW Measurement Interface Program Block commands. Periodical
RNW Measurement Interface Program Block interface is also used for trace and online
monitoring. Distributed Statistics Mediator library implements both Periodical RNW
Measurement Interface Program Block and Statistic Report Handler Program Block
interfaces.

11) This is an interface for monitoring tools. Monitoring Tool Mediator activates and
deactivates trace data collection to HC-master. HC-hand sends the actual trace data to
Monitoring Tool Mediator.
4.5 Handover Control Process Family
4.5.1 Handover Control Master Process [ 16]
As explained in the previous chapters, the Handover Control (HC) implements the
handover decision algorithm of the RNC. The Handover Control has two processes, a
master process and a hand process. The master process is active as long as the RNC is
up and running. The hand processes are call-specific and they are created and removed
when needed.

55
The Handover Control Master Process is responsible for maintaining an on-line copy of
the Radio Network (RNW) database parameters and providing an interface for every
handover control hand process to read these parameters. Only the Handover Control
specific RNW parameters are provided to the HC-master. The HC master is also
responsible for creating and supervising an HC-hand, providing a statistical interface
and managing process warming and switchover. The memory consumption of the HC-
master process is dependable on the network configuration. That can be controlled by
configuration parameters, and hence the memory usage of the HC master is not an issue
in different hardware environments.

In addition to normal hand creation and supervision functions HC master maintains a
local copy of RNW parameter database in its own memory and provides an interface for
hand processes to read these parameters. Only HC specific RNW parameters are stored
in HC-masters memory. Process warming and switchover control functions are
implemented in the HC-master as well.
4.5.2 Handover Control Hand Process [ 16]
An HC-hand is created in the SRNC (serving RNC) when the RRC connection on the
Cell_DCH state is set up and it exists until the UE leaves the Cell_DCH state. The UE
is in the Cell_DCH state if at least one dedicated transport channel is set up. In the
DRNC (drifting RNC), an HC-hand is created when the first soft-handover (SHO)
branch over Iur is set up and it exists until the last soft handover (SHO) branch over Iur
is removed.

The HC-hand provides all UE-dedicated handover functionalities in the Cell_DCH
state. This is why most of the implementation is done in the HC-hand code area.
Because there can be thousands of HC-hand processes in a computer unit at the same
time, every new bit of memory needed by the HC-hand is multiplied by the number of
the active HC-hand processes.

56
4.5.3 Module Structure of HC Hand Process [ 16]
The HC-hand was abstracted according to developed services. The intention was to
have one module for one service. The abstraction was implemented by abstract data
types, which have their internal data structures and service interface. The service
interface consists of many independent service offering operations. This implementation
method supports object-oriented programming suggestive of implementation solution,
which supports thinking and designing of data structures and combinations of different
operations rather than just thinking and designing of the functionality. Parameter and
return values of functions are the communication tools of the operations. This section
concentrates on the current usage of abstract data types from the point of view of
memory consumption.

The HC-hand functionality in the Drifting-RNC (DRNC) and in the Serving-RNC
(SRNC) side differs from each other. The DRNC functionality is very limited and
contains only the active set update and providing of the neighbour cell lists of the active
set cells to the SRNC. The DRNC functionality does not contain any sophisticated
handover decision algorithms. The SRNC HC-hand is responsible for all handover
decision algorithms. Because the DRNC HC-hand can take a role of the SRNC HC-
hand at any time, the DRNC HC-hand uses the same data structure as the SRNC HC-
hand.

The challenges and the troubleshooting experiences that are analyzed in the next chapter
are mostly related with HC-hand processes and their transactions with different RNC
software elements.
57

5 Troubleshooting Experiences
Serving to all 3GPP requirements, radio network controller software includes millions
of lines of code. During the internal testing phase of the software, there can be several
bugs or missing features. Bugs can also appear inside the verified versions of the
software. Vendors design tailor made software solutions for different operators and this
differentiation also hardens the testing and troubleshooting process.

5.1 Troubleshooting Approach for Mobile Networks
In mobile networks, problem solving for software or hardware problems has to be done
by experienced (senior) engineers. Each mobile network element is designed to inform
its operators for errors or problems. But operators are not always proficient to
investigate complex situations. Those situations need to be handled by vendors own
engineers.

In general, troubleshooting is done in 4 steps:
Fault Identification
Symptom Collection
Symptom Analysis
Fault Repair

In Fault Identification, engineers have to identify clearly what the problem is. For this
purpose, vendors have developed some tools. Common features of these tools:
User Interface
Cell Status Reporting
Link Status Reporting (Radio, Transport, Signalling)
Key Performance Indicators (KPI) Threshold Monitoring
Alarm Monitoring
Alarm History Tracking
Problem prioritization
Process assessment
Counter analysis
58

In Symptom Collection, engineers have to collect data for the problem investigation.
Data collection can take place in interface level or directly from a database. Symptom
Collection tools often provide filtering options (by using different query scripts) to the
user for better experience. Subscriber tracing is another important option that is
provided by symptom collection tools. In addition to IMSI based filtering,
complementary data from the different parts of the network for particular subscriber has
a big value for troubleshooting.

In Symptom Analysis, knowledge for network architecture and signalling protocols
become vital for analysis. The tools have to provide network analyzing and subscriber
tracing features for advanced troubleshooting. At this level, providing signalling flow
charts can easily reveal the causes of the problem. Vendors usually have different tools
for data collection and the compatibility of those tools is vital for troubleshooting
experiences.

In Fault Repair phase; according to the internal fault repair policies, engineers can
either report their results by proposing a software change or configuration change to the
software development team. They can also do the fix by themselves.

In R&D team, a tool called EMIL is used for the first two phases. Details about EMIL
are introduced in the next chapter.

59
5.2 EMIL

Figure 30 : EMIL Screenshot
EMIL is an internal troubleshooting tool for Nokia Siemens Networks, which can be
used for investigating different kinds of message monitoring outputs and other log files.
It supports different software versions (different data types) and products. EMIL
provides profiles for different products and Software Program Blocks, depending on the
needs, for effective fault analysis. A profile consists of several files, which describe how
the information in a log file is processed and visualized to the end user.

The main benefit of the profiles is that they can be modified by users for better
visualization of the log files. EMIL provides an opportunity to create very powerful
automated scripts inside the profiles. With the help of those scripts, thousands of lines
(messages) can easily be filtered to tens or hundreds of lines, which can further be
highlighted to identify and visualise the problematic issues better. With this flexibility,
EMIL platform is open for new scripting implementations and it can easily be
customized for different needs around the R&D organization.
60

5.3 Challenges to be studied related with Handover Control
Algorithm
As it is mentioned in the prior chapters, RNC software is a very complex product which
came to its final phase through proved success in different technologies. To keep the
same success level continuous in different versions of the software, R&D activities are
vital. In R&D, mostly Integration & Verification engineers have the responsibility to
keep the software parts compatible with each other and working all the time.

R&D support continues after the product is deployed to the live networks. From
engineers point of view, a harder phase starts with the deployment. Problems from
different operators come to the R&D engineers to be solved. At this level most
important phase is troubleshooting. The approach that is mentioned in the prior
chapters (Troubleshooting Experiences) is commonly used for RNC related challenges.
Troubleshooting phase is usually a cumbersome process that requires analyzing big
number of data. Any improvement that is done during this phase would increase the
efficiency of software lifecycle.

In NSN; the team that is cooperated for this thesis, is mostly interested about the
Handover Algorithm related challenges that occur in any R&D processes which
includes the existing software versions and the upcoming versions. As a team it was
decided to prepare a thesis work to enhance the troubleshooting experiences.

During the topic and scope decision phase, there were many meetings done to identify
the needs of the team from different perspectives and to keep the scope under timing
and workload targets. As a result, several use cases were defined and the consultancy
for the thesis has mostly continued individually with the responsible senior engineers.

In the following chapters, different use cases will be presented with their problem
statements, existing solutions, live network needs, internal integration and verification
needs, implementation possibilities, enhancement proposals and testing scenarios for
new functionalities.

61
5.3.1 Radio Network Database parameter consistency checking






Figure 31 : Handover Control Algorithm Program Block interactions
Problem statement: Parameter values in Handover Control HC-master memory should
be the same as in radio network (RNW) database. Communication between the RNW
database and HC-master has two interfaces; library interface and messaging interface.
When the unit starts up and Handover Control family is started, each HC-master uses
RNC RNW Database Library procedures to read the needed RNW parameters from the
database. If parameters are created / deleted / modified in the database after the unit
start-up (i.e. during normal operation), Radio Network Manager sends notification
message to each HC-master process about the new / removed / changed parameters.
This messaging interface is hidden from the clients with a library.

If everything works as it should, there should not be any inconsistencies. But in
practice; in distributed systems, where database users are in different network units than
the actual database, it is always possible that due to some reason data in different
network units is not the same. Investigation of this kind of problems is very challenging.
More specifically, there might be different parameter values in different ICSU's HC-
master memory. There can be several problematic scenarios:
Radio Network Manager sends wrong data.
Radio Network Manager sends correct data to a wrong ICSU.
Radio Network Manager sends correct data to ICSUs but, not to all of them.
RNW
Database
Manager
RNW
Manager
RNW
Database
Library

Handover Control
Master Process
Handover
Control
Hand Process
ICSU
62
Radio Network Manager sends correct data but, HC-master is unable to receive
or process the data correctly.
Radio Network Manager does not notify the parameter changes to ICSUs.
Existing solution for the problem: Currently, parameter consistency check can be
done by requesting Handover Control Algorithm parameter printout from different
ICSUs by:
1- Starting message monitoring in ICSU
2- Sending parameter query to HC-master process
3- Collecting monitoring logs (size of log files are around 10 MB per ICSU)
After parameters have been collected from each ICSU, they are manually checked by
comparing with the operators own RNW plan. No special tool is available for that
purpose. Message monitoring is done manually by using EMIL tool.

Live network needs: The tool has to create alarms/warnings for parameter
inconsistencies and clearly show the relevant database parameter inconsistencies in
terms of related ICSU and parameters. The only way to catch the data corruption that
occurs at RNC RNW Database Library interface is to have Handover Control Algorithm
message monitoring running already when RNC or ICSUs are starting up or RNW
database is being read. This procedure is next to impossible to arrange at customer
premises. To make it happen; it is needed to have an experienced scripting or debugging
person at the site, but usually they are not available until the problem has already been
escalated. As a result, a new monitoring interface is needed to detect / locate / diagnose
a problem once it has occurred.

Internal Testing (I&V, MT) needs: The tool has to create alarms or warnings for
parameter inconsistencies. The tool also has to provide debugging features for the
problems in terms of queries, messages and responsible functional units.

Implementation: Additional functions/features to indicate that there is a parameter
inconsistency might be needed. New interface for parameter update traffic might be
needed (reason for a new interface explained above). New data types might be needed.
Example for data types and functions:
63
Tool Handover Control Algorithm: inquire counter data, reset counter data, and
launch consistency checks. (If something implemented directly to Handover Control
Algorithm)
Tool Radio Network Manager: launch Radio Network data, reload to Handover
Control Algorithm Program Block (If reloading not implemented to Handover Control
Algorithm)
Tool RNC RNW Database Library: inquiries (If the interfaces already used by
Handover Control Algorithm are not sufficient)

Testing new features: New features have to be tested by forcing the system to have
inconsistent parameters. When testing with real RNC, it could be possible that after the
RNW data is read from Operation and Maintenance Unit (OMU) during start-up, test
program would send modified messages to Handover Control Algorithm in one ICSU to
change the parameter values that have been read from database. For simulating the
corruption, a test program (maybe a version compiled with special flags) can also be
part of the tool itself.

Proposals: The tool can check the parameters from different ICSUs and compare them
with the ones that are read from RNW Manager or RNW Database Manager or RNW
Database Library.













Figure 32 : Database Consistency Check
RNW
Database
Manager
RNW
Manager
RNW
Database
Library

Handover Control
Master Process
Handover
Control
Hand Process
ICSU
Troubleshooting
Tool
Report
1
2 3
4
64
In a regular consistency check approach (see Figure 32):
1 - Correct parameters have to be read from the RNW Database Library.
2 - A parameter query has to be sent (broadcast) to every ICSU.
3 - Received parameters (from ICSU) have to be compared with the ones in the
database.
4 - The differences need to be reported.

This procedure should be enough to catch the missing or corrupted parameters, but it
does not detect possible excess objects, which are still in Handover Control Algorithm
but removed from RNW database. To solve this problem, there can be simple object
counters. Handover Control Algorithm can count the number of objects in each object
class and report back to the tool by using the counters. Also the number of received
updates can be stored as counters which can help to investigate the problems in Radio
Network Manager update mechanism. (E.g. how many add / modify / delete attempts
have been done). As an additional feature; date and time of the last Radio Network
Manager update can be stored in Handover Control Algorithm and printed out by the
tool when requested.

If this procedure is followed, full parameter check can create additional traffic in the
live network and take a long time. To make this procedure efficient:
Consistency check can be limited to specific ICSUs.
Consistency check can be limited to specific object class.
Consistency check can be limited to specific object.
Consistency check can be done in a specific time (and once in a day) that will
not affect the network (e.g. midnight).

Another approach can be comparing the parameters between two or more ICSUs
without sending any query to RNC RNW Database Library. But result may not be
satisfying because the comparison will not be done with the raw data.
65














Figure 33 : Actions when inconsistency is identified
According to these approaches; when the parameter inconsistency is identified, the tool
can do the following (see Figure 33):
1 - Create alarms / warnings
The tool can provide a report about inconsistencies, including the related ICSU
information. In addition to different query options, there can also be different
reporting options to provide needed information in a meaningful way. The tool can
provide options about how to visualize that information to the screen. On the other
hand, filtering the results may also create process load. In addition to ICSU, object
class, object based results there can also be condensed results such as a list of
corrupted ICSUs or a list of corrupted parameters. For end-users (e.g. operators) the
tool may also create DMX alarms (DMX alarms are used the report important
situations directly to the operators). Implementation of DMX alarms can be analyzed
upon request.

For detailed troubleshooting, the tool can also provide a dump file or the printout of
the corrupted data to determine the root of the cause or mechanism behind the fault.
There can also be EMIL compatibility for detailed investigation.

- Create Alarms/Warnings
- Give Diagnostic Info
- Force Parameter Update
RNW
Database
Manager
RNW
Manager
RNW
Database
Library

Handover Control
Master Process
Handover
Control
Hand Process
ICSU
Troubleshooting
Tool
1
2
3
66
For data storage; using a computer log is probably not feasible due to its limited size
and possibility of overwriting other important information in the log. Storage
memory is a problem. Writing all the needed data to a new file can be a suitable
solution.

2 - Force RNW Manager for parameter update to the corresponding ICSUs
In addition to pointing that there is a problem, the tool can offer a solution to the
problem. It can be user oriented or automated.

After identifying the parameter inconsistency, the tool can force ICSUs to ask for a
new set of parameters. This procedure will also create additional network load so the
options can be: re-reading all the parameters, a specific class of parameters or a
specific parameter (automated or inter-active with users choice).

Reading Source is another decision point: It can either be from RNW database or
from another ICSUs. RNW manager initiated reading has to be analyzed in terms of
feasibility by R&D engineers.

3 - Give diagnostic information:
Load time: Handover Control Algorithm Program Block can remember the start and
end time of RNW database loading (in unit or system start-up) and report back to
tool when asked.
Average DB op time: The program block can calculate the average time that it takes
to perform one RNW database library call and report back to tool when asked.
Load source: The program block can remember the number of reads which it
performed from RNW database library or different ICSUs, report back to tool when
asked.
Number of failures: The program block could calculate the number of
failures/retries it had to do when loading the database (corrupted data from RNW
database library, error status from RNW database library), report back to tool when
asked.

67
During the studies for this issue; R&D engineers implemented the Database
Consistency add-on to the Handover Control Algorithm Program Block. It is not
intended for live usage, because consistency check takes a long time and consumes a lot
of bandwidth between ICSU units. It basically calculates the checksums locally and
then only compare them between ICSUs, which would dramatically reduce the
execution time. There is no need to transfer the large amount of data between units,
because the checksum calculation is efficient and does not take long time to calculate.

Consistency check procedure:
Consistency check can be started with a new service terminal extension.
Service terminal extension sends start message to Handover Control Algorithm
Master process in given ICSU unit. HC-master in this ICSU unit reads through
all other ICSU units and compares all data of all ICSU units against its own
memory.
If there are any errors, HC-master writes to ICSU computer log.
Finally, HC-master acknowledges to Service terminal extension with the status
only.
5.3.2 Formatted printout of the RNW network topology
Problem Definition: In module testing, it is very hard and slow to get an
understandable view of the network topology which is present in some old regression
test set (or even in Functional Testing). Because it is needed to open hundreds of
network modification messages in module testing environment, memorize the object
ids, and try to build a mental image of the relations between them. The best way is to
draw it on a piece of paper. In practice, this makes re-using or updating RNW
configurations in existing module test projects very hard. It is practically impossible to
know what you can modify without breaking an existing test case.

Existing solution for the problem: No present solution at all. It would be very
beneficial to have this feature.

Live network needs & Internal testing needs: A topology figure/table has to be drawn
by the tool according to collected modification messages.
68
Implementation: No need to have new functions or data types in Handover Control
Algorithm Program Block, the data will be stored and processed by an external tool.

Proposal: Handover Control Algorithm Program Block messages have to be collected
and then processed according to relations between cells. After data collection, required
radio network topology can be drawn.
A quick sketch can be seen below (displaying object identifiers with some of the key
parameters):
BTS id: Defines the identification number for the Base Transceiver Station
WCEL id: Identifies a WCEL unambiguously within a RNC.
ADJS id: Defines the identification of intra- frequency adjacent cell
ADJI id: Defines the identification of inter-frequency adjacent cell
ADJG id: Defines the identification of GSM adjacent cell
BTS id
WCEL id
ADJS id
ADJI id
ADJG id
WCEL id
ADJS id
ADJI id
WCEL id
ADJS id
ADJI id
WCEL id
ADJS id
ADJI id
BTS id
WCEL id
ADJS id
ADJI id
WCEL id
ADJS id
ADJI id
ADJG id
WCEL id
ADJS id
ADJI id
Table 3 : Formatted printout of the RNW network topology
One of the implementation possibilities is creating an EMIL script that could draw this
type of table or chart. The main concern about EMIL implementation is; how easy or
how hard will it be to create a global data structure where the data from filtered query
messages can be stored. Processing the information and producing the printout should
not be an issue.
69











Figure 34 : Transition from log file to network topology table
Another option is to provide this functionality inside a new troubleshooting tool. In both
cases, required information has to be collected, stored and processed to create the
network topology.

In the log messages, required information is located under certain data types.
ha3_rnw_parameter_query_s message includes the desired information to build the
network topology table. The same signals are also used when database sends
new/updated parameters to Handover Control Algorithm. Detailed information about
the signals can be found in Appendix 8.1.1. Required messages to build the network
topology in a nutshell are given below:
BTS id can be provided from rak_create_ha3_wcel_s signals
ha3_wbts_param_t data type, wbts_id object.
WCELL id can be provided from rak_create_ha3_wcel_s signals
ha3_wcel_param_t data type, wcell_id object.
ADJS id can be provided from rak_create_ha3_adjs_cell_s signals
ha3_adjs_t data type, adjs_id object.
ADJI id can be provided from rak_create_ha3_adji_cell_s signals ha3_adji_t
data type, adji_id object.
ADJG id can be provided from rak_create_ha3_adjg_cell_s signals
ha3_adjg_t data type, adjg_id object.

000034 15.04 12:50:17.723 [192.168.255.208] 98 FSP-2491 <15.04
11:50:23.140683> 02 DBG/TUP_UP HsdpaFcInd BufferOccupancy 0

000035 15.04 12:50:17.723 [192.168.255.208] 99 FSP-2491 <15.04
11:50:23.140736> 02 DBG/TUP_UP CQueue32910M0P0: m_TpEstim:2070500 ;
Buff:0 ; temp:727 ; m_DataReceivedDuringIteration:0 ; FC_CRtp:727 ;
FC_lastCRtp:770 ; SFN:368

000036 15.04 12:50:17.723 [192.168.255.208] 9a FSP-2491 <15.04
11:50:23.140779> 02 DBG/TUP_UP CQueue32910M0P0: m_DataPrev_period: 0,
m_DataST: 6560

000037 15.04 12:50:17.723 [192.168.255.208] 9b FSP-2491 <15.04
11:50:23.140830> 02 DBG/TUP_UP CQueue32910M0P0: CRtp 727, CRcc 12, CRst
117, RxData 0, AllocPrev 66400 bps, NewAlloc 66400 bps

000038 15.04 12:50:17.723 [192.168.255.208] 9c FSP-2491 <15.04
11:50:23.140871> 02 DBG/TUP_UP Received HsdpaFcInd message for UserId
32911 PrioQId 7

000039 15.04 12:50:17.723 [192.168.255.208] 9d FSP-2491 <15.04
11:50:23.140909> 02 DBG/TUP_UP Received HsdpaFcInd message for UserId
32910 PrioQId 7

000040 15.04 12:50:17.723 [192.168.255.208] 9e FSP-2491 <15.04
11:50:23.146825> 02 DBG/TUP_UP CCRncGroup0: TotalData: 5000000, TotalGBR:
0, TotalNBR: 0, Rem: 5000000, WSPI_SumAct: 1, RxData: 24, CCEnabledQ: 3

000041 15.04 12:50:17.738 [192.168.255.208] 9f FSP-2491 <15.04
11:50:23.150112> 02 DBG/TUP_UP Received HsdpaFcInd message for UserId
32911 PrioQId 0

000042 15.04 12:50:17.738 [192.168.255.208] a0 FSP-2491 <15.04
11:50:23.150148> 02 DBG/TUP_UP HsdpaFcInd AirIfThroughput 2271500

000043 15.04 12:50:17.738 [192.168.255.208] a1 FSP-2491 <15.04
11:50:23.150180> 02 DBG/TUP_UP HsdpaFcInd BufferOccupancy 0
000363 15.04 12:50:17.847 [192.168.255.41] aa FSP-240D<15.04
11:50:23.250960> 2005EINF/RM/Sel: EncodeHsdpaRlReconfigCommitResp():
Encode OldParams situation: CellId = 191, MimoStatus= 0,

000364 15.04 12:50:17.847 [192.168.255.41] ab FSP-240D<15.04
11:50:23.251089> 1005DDBG/LGC/P, RLH_RM_HSResReconfigCommit, crnccId:
8480, nbccId: 143

000365 15.04 12:50:17.847 [192.168.255.41] ac FSP-240D<15.04
11:50:23.251195> 1005D INF/LGC/B, RLHSR_RLC_RlReconfigCommit, nbccId:
143

000366 15.04 12:50:17.847 [192.168.255.41] ad FSP-240D<15.04
11:50:23.251396> 1005D INF/LGC/B, RLH_CTRL_HSRlReconfigCommitResp,
nbccId: 143, dchAddr: 0x22

000367 15.04 12:50:17.847 [192.168.255.41] ae FSP-240D<15.04
11:50:23.251433> 1005DDBG/LGC/P, RLH_CTRL_HSRlReconfigCommitResp,
crnccId: 8480, nbccId: 143, initialRlh: 0x22

002572 15.04 12:53:46.248 [192.168.255.208] 4d FSP-2491 <15.04
11:53:51.671564> 02 DBG/TUP_UP CQueue32932M0P0: m_TpEstim:12192000 ;
Buff:0 ; temp:3966 ; m_DataReceivedDuringIteration:0 ; FC_CRtp:3966 ;
FC_lastCRtp:3966 ; SFN:74

002573 15.04 12:53:46.248 [192.168.255.208] 4e FSP-2491 <15.04
11:53:51.671594> 02 DBG/1

002574 15.04 12:53:46.248 [192.168.255.208] 4f FSP-2491 <15.04
11:53:51.671633> 02 DBG/TUP_UP CQueue32932M0P0: m_DataPrev_period: 0,
m_DataST: 6560

002575 15.04 12:53:46.248 [192.168.255.208] 50 FSP-2491 <15.04
11:53:51.671685> 02 DBG/TUP_UP CQueue32932M0P0: CRtp 3966, CRcc 89541,
CRst 117, RxData 0, AllocPrev 657600 bps, NewAlloc 652800 bps

002576 15.04 12:53:46.248 [192.168.255.208] 51 FSP-2491 <15.04
11:53:51.671725> 02 DBG/TUP_UP Received HsdpaFcInd message for UserId
32932 PrioQId 7

002577 15.04 12:53:46.264 [192.168.255.208] 52 FSP-2491 <15.04
11:53:51.681078> 02 DBG/TUP_UP Received HsdpaFcInd message for UserId
32931 PrioQId 0

002578 15.04 12:53:46.264 [192.168.255.208] 53 FSP-2491 <15.04
11:53:51.681113> 02 DBG/TUP_UP HsdpaFcInd AirIfThroughput 6341000

002579 15.04 12:53:46.264 [192.168.255.208] 54 FSP-2491 <15.04
11:53:51.681146> 02 DBG/TUP_UP HsdpaFcInd BufferOccupancy 0
TOOL
asdwasdwasdw
70
5.3.3 Missing neighbour cell definitions (ADJs)
Problem Statement: In the radio resource planning phase, some cells neighbours are
defined wrongly or with missing information. UEs detected cells measurements are
sent to RNC and the troubleshooting tool can be used to inform operator about the
unlisted but detected adjacent cells.


Figure 35 : Example for missing Neighbour Cell Definitions and Handover fail
There is an example radio network topology in Figure 35. At the beginning, there are
only BTS1, BTS2 and BTS3. Then a new BTS (BTS4) is added by operator due to
congestion, but updating the neighbour cell definitions is forgotten. If a call is started by
a mobile user within the coverage area of BTS1, following a path through
BTS1BTS2BTS4BTS3, first handover occurs between BTS1 and BTS2 to
maintain the call state. When the user moves to the edge of BTS2 coverage area and
gets the radio signals of BTS4, BTS4 is added to the active set. As it enters to the
coverage area of BTS4, there has to be a handover and the call has to be forwarded to
BTS4. But the call is dropped because the neighbour cell definitions are missing at the
responsible RNC.

Existing solution for the problem:
If missing neighbour cell definitions are known to be the cause of the problem, then the
collected data is analyzed with some effort and the determination is done which
neighbouring cell definitions are missing.

After the data has been collected, it can be (with some effort) analyzed and determined
if / which neighbouring definitions are missing. Another method is to analyze the "call
71
drop" counters and try to solve why and where the call drops are happened. In most of
the cases, it is found out that, there is neighbour information missing from a cell located
at the call drop area.

The problem about this approach is that: the results are not obtained as quickly as they
are needed; required data has to be provided correctly from customers network. Also,
analyzing that data can be a time consuming task.

Live network needs: The tool has to create alarms or warnings for missing neighbour
cell definitions. The tool has to have ability to check Cell based, IMSI based, RNC
based neighbour cell lists and compare the results within Detected Cells list.

Internal Testing (I&V, MT) needs: The tool has to create alarms or warnings for
missing neighbour cell definitions. The tool also has to provide debugging features for
missing neighbour cell definitions and measurements. The tool has to have ability to
check Cell based, IMSI based, RNC based neighbour cell lists (UEs Detected Cell list
as well).

Implementation: Additional functions or features to indicate that there is a problem in
neighbour cell definitions might be needed. Comparison between ADJD (Detected
adjacent cells) and neighbour cell list might be needed.

Testing new features: New features have to be tested by forcing system to have
missing neighbour cell definitions.

Proposals: Majority of the comparison and analyzing code for this tool can be located
inside Handover Control Algorithm and only results passed to / presented by / post-
processed by the tool. In this case, newly implemented software part requires access to
the network related information that is known by Handover Control Algorithm, for
example, the neighbour cell configurations and data counters. After that, the tool has to
check the measurement reports that are done by UE as detected cells. And according
to decision algorithm, it can inform operator about missing or wrongly configured
neighbour cell definitions. For this enhancement, it is important to have detected cell
reporting feature in working mode.
72
5.3.4 Handover Related Troubleshooting
Mobile Operators are monitoring their networks in terms of KPIs and customer
complaints. According to their business types, they focus on certain KPIs and most of
the time they calculate their own KPIs by using the default counters. Furthermore
vendors are also monitoring their customers in terms of certain KPIs.
The KPIs listed below are important to recognize the problems related with mobility.
Number of Call Drops
Handover success rate
Number of Handover attempts
Change of average active set size (increase / decrease)
Average Ec/No
Number of IFHO
Number of ISHO
Number of SHO
Depending on those indications, the root cause of a problem can be:
Configuration problems
o Missing neighbour cell definitions
o Wrong measurement control parameters
o Wrong Iur / Iu parameterization
Problems caused by other network elements
o UE specific problems
o Problems between RNCs (Iur interface problems)
o Problems with BTS (Iub interface problems)
o Problems with Core Network (Iu interface problems)
Software related issues
o New features
o New set of configuration parameters
o Software bugs

Investigation of handover related problems is quite often very time-consuming.
Because handover is the basic state of the call thus handover problems can cause many
kind of other problems and it has to be investigated in detail.

73
There are many enhancement opportunities for the troubleshooting process that is
related with handover problems. For this thesis work, some major ones were studied and
analyzed in the following sub-chapters.
5.3.4.1 Investigation of large ICSU-files
Problem Definition:
Amount of information that is needed to analyze handover problems can be very huge
(ICSU log files, parameter data and counter data). Thus it would be good to have some
tool which can be configured to search certain patterns which indicate some certain
problems. For example: statistical data of Handover Control Algorithm initiated channel
type switch requests and serving cell changes. Furthermore the tool can provide
summarized statistics by using cell based filtering.

Useful information related to channel type switch requests and serving cell changes
would be:
Number of requests
Trigger cause for the request
Intra frequency measurement reports from UE
Handling Events 1A and 1C
Target cell
Number of ACKs for the request
Number of NACKs for the request
Failure cause of the request

That information can be collected from investigated ICSU-logs by searching following
messages:
Handover failure related messages (ICSU messages sent/received by Handover
Control Algorithm Program Block)
Handling of Event 1A Cell Addition
Handling of Event 1C Cell Replacement
Call release reasons (for possible call drops)

74
Existing Solution for the problem: The ICSU-files are analyzed with EMIL manually
which takes a lot of time. Desired information is visible also from statistics but that data
is sometimes difficult to get from customer and also difficult to analyze. By getting the
information directly out from the ICSU-data would be a good advantage. For a better
solution, provided by this tool, detailed information can be collected from ICSU-logs
and processed or demonstrated in desired way.

Live network needs & Internal testing needs: Condensed information could be useful
in numerical format and also in some graphical format. For example:
Frequency of requests
Number of requests per trigger cause
Number of ACKs and Number of NACKs (with specific failure cause)
The success and failure ratio on cell level
How many requests from a certain cell and how many NACKs / ACKs from a
certain cell and BTS (The information would be useful to get on cell level and
on BTS level)

Implementation: No need to have new functions or data types in Handover Control
Algorithm Program Block, the values will be stored and processed by the tool.

Proposals: ICSU-logs have to be collected and then processed in terms of important
values to report. After doing required calculations, condensed values can be reported in
table or graphic format. Those calculations can be done by using EMIL scripts and
those scripts can be saved as an EMIL profile that can be used later as well.
5.3.4.2 SHO KPI Problems
Problem Definition: As it is mentioned earlier, KPIs have importance on indicating
problems about the network. But time to time, there can also be problems about the
KPIs itself. Besides the default KPI values, operators can have their own specific KPIs
to monitor their network. With a new software release to the network elements, there
can be a change in the KPIs by %1 ~ %2 due to many reasons such as new feature
activations (required changes to RRM parameter adjustments). After software baseline
upgrades, there can be KPI problems which also affect handover processes.
75
Existing Solution for the problem: Currently, the problem is investigated by analyzing
the logs manually to check which parameter is calculated wrongly or configured
wrongly.

Live network needs & internal testing needs: Internally, correct values of the KPIs
have to be calculated and compared to identify the problem. This feature can also be
provided to the field engineers or operators upon request.

Implementation: A new EMIL profile can be created with embedded KPI calculations.
Message monitoring has to be triggered by Handover Control Algorithm.

Proposals: KPIs are calculated from counters, the raw data has to be read from counters
and exact KPI values can be calculated from them. An EMIL profile can be designed for
this purpose. But to achieve this, Distributed Statistics Mediators debug feature has to
be turned on.

Furthermore, Radio Resource Control Program Block is doing message monitoring for
failure situations and dropped calls. For a better investigation, Handover Control
Algorithm Program Block can trigger message monitoring via Radio Resource Control
Master process and get the required logs. The logs include the message monitoring
between:
UE Radio Resources Program Block Handover Control Algorithm
Program Block
Radio Resources Control Program Block (dedicated RRC protocol hand)
Handover Control Algorithm Program Block
Message traffic and counter changes are vital to identify the source of the problem about
KPIs.



76
5.3.5 HSPA related items to be improved
5.3.5.1 Investigation of large ICSU-files
Problem Definition: Because there is a huge traffic in the operators live network, it is
difficult to find the root cause of certain HSDPA or HSPA accessibility problem
without proper tool which would easily show the required information. Typically the
problems that have to be investigated are HSDPA or HSPA accessibility issues which
would mean that Handover Control Algorithm Program Block does not grant HSDPA
or HSPA for the user during user plane creation or that Handover Control Algorithm
Program Block triggers user-plane to DCH/DCH allocation from HS(D)PA allocation
which means again lower bit rates.
Another typical issue is, Handover Control Algorithm Program Block serving cell
algorithm does not work correctly and it is not able to keep the best active set cell as
HS-DSCH serving cell or it triggers CTS to DCH/DCH instead of serving cell change.
Also serving cell change KPI is one which operators are keen and if there happens even
%0.01 worsening in this KPI, the operators start to complain. And for this kind of KPI
worsening it is very hard to find root cause without good statistical information.
Some kind of tool which could be used to collect statistical data of Handover Control
Algorithm initiated channel type switch requests and serving cell changes would be
useful when investigating large ICSU-files from customer live networks.
Monitoring should be done cell based, responsible cell and the target cell. Useful
information related to channel type switch requests and serving cell changes would be:
Number of requests
Trigger cause for the request
Number of ACKs for the request
Number of NACKs for the request
Failure cause of the request




77
Existing Solution for the problem: The ICSU-files are analyzed with EMIL which
takes a lot of time. Desired information is visible also from statistics but that data is
sometimes difficult to get from customer and it is sometimes also difficult to analyze.
By getting the information directly out from the ICSU-data would be good advantage.

For a better solution, provided by this tool, detailed information can be collected from
ICSU-logs and processed or demonstrated in desired way.

Live network needs & Internal testing needs: Condensed information could be useful
in numerical format and also in some graphical format. For example:
Frequency of requests
Number of requests per trigger cause
Number of ACKs and Number of NACKs (with specific failure cause)
The success and failure ratio on cell level
How many requests from certain cell and how many NACKs or ACKs from
certain cell and BTS (The information would be useful to get on cell level and
on BTS level)

Implementation: No need to have new functions/data types in Handover Control
Algorithm Program Block, the values will be stored and processed by the tool.

Proposals: ICSU-logs have to be collected and then processed in terms of important
values to report. After doing required calculations condensed values can be reported in
table or graphic format.
5.3.5.2 HSPA Accessibility Problems (Parameter Inconsistency):
Problem Definition: E_DCH operational state is used by BTS to report to HSUPA
operational state of the cell. In order to use HSUPA in a cell the BTS must have
reported HSUPA Operational state to be enabled in that cell. Otherwise HSPA cannot
be used in that cell (meaning no accessibility for high uplink (UL) bit rates from end
user point of view).

78
HS-DSCH operational state is used by BTS to report to HSDPA operational state of the
cell. In order to use HSDPA in a cell the BTS must have reported HSDPA Operational
state to be enabled in that cell. Otherwise HSDPA cannot be used in that cell meaning
no accessibility for high downlink (DL) bit rates.

HSDPAOperationalState and HSUPAOperationalState indications are the most error
prone and also the most difficult one to catch from live network. Handover Control
Algorithm gets this information from Radio Network Initiator on WBTS (cell) level
basis and there has been some problems that Radio Network Initiator has not always
sent this information correctly to Handover Control Algorithm or sometimes it has not
sent it at all. That will cause huge problems for HS(D)PA accessibility. From end user
point of view; problem can be seen with lower bit rates than expected because HSDPA
or HSUPA cannot be allocated for the user.

Existing Solution for the problem: Currently the R&D just need to try to get
Operation and Maintenance Unit logs from customer and try to search from there (by
using EMIL) any Radio Network Initiator notifications that have been sent to Handover
Control Algorithm.

Live network expectations from the desired tool: The tool has to create alarms or
warnings for parameter inconsistency and clearly show the relevant database parameter
inconsistencies in terms of ICSU and parameters.

Internal testing expectations from the desired tool: The tool has to create alarms or
warnings for parameter inconsistency. The tool also has to provide debugging features
for the problem in terms of queries, messages and responsible functional units.

Implementation: Additional functions or features to get the information from Radio
Network Initiator and ICSUs might be needed. After getting the
HSDPAOperationalState and HSUPAOperationalState parameters the tool can compare
them.

79
Proposals: The tool has to get the correct values of the parameters from Radio Network
Initiator and then compare with the ones in Handover Control Algorithm and then it
can:
Create alarms or warnings
Force Radio Network Initiator for parameter update
Force Handover Control Algorithm to ask for new set of parameters.
Debug messages can be used between Base Station Resource Manager Program
Block Handover Control Algorithm Program Block
5.3.5.3 Calculation of certain Parameters related with HSPA
Problem Definition: UL SIRerror and periodical CPICH Ec/No values are used in
handover control algorithm decisions. While investigating issues/problems in handover
control algorithm related to HS(D)PA functionality, those values has to be analyzed in
order to see if the algorithm works correctly and utilizes correctly those inputs that are
coming from UE and BTS. Currently the R&D team needs to calculate averaged UL
SIRerror and periodical CPICH Ec/No measurement results of a certain cell based on
ICSU-log by hand which is not a very efficient way.

Existing Solution for the problem: Periodical CPICH Ec/No reports come from UE
and UL SIRerror reports come from BTS. Those values are captured in logs by
automated macros and then calculated by hand.

Live network needs & Internal testing needs: Averaged UL SIRerror and periodical
CPICH Ec/No measurement results of a certain cell (which is defined by the user) are
needed.

Implementation: No need to have new functions or data types in Handover Control
Algorithm Program Block, the values will be stored and processed by the tool. Another
option is using EMIL scripts for calculation.

Proposals: The tool has to get the UL SIRerror and CPICH Ec/No values from the
ICSU-log. Then it will calculate the averaged UL SIRerror and periodical CPICH Ec/No
measurement results for certain cell which is defined by the user.
80
6 Conclusion
During the topic decision phase of this thesis, the main problem statement was how to
enhance the troubleshooting experiences of the R&D engineers. At the beginning I was
guided to increase my knowledge more on Radio Resource Management and then
particularly about Handover Algorithms. Later on, team meetings were organized to
reveal the existing troubleshooting experiences and difficulties. At that point, I started
to be informed about the software architecture of RNC and Handover Control
Algorithm.

Needs of R&D engineers were discussed and a list for enhancement opportunities was
decided during the meetings. Then, efficiency evaluation was done case by case basis to
prioritize the cases for the thesis work duration. Some enhancement cases were
eliminated due to their complex analysis and implementation techniques. After the
study cases were determined, individual meetings with the senior engineers took place
on a weekly schedule. Enhancement cases were studied with their problem statements,
existing solutions, live network needs, internal integration and verification needs,
implementation possibilities, enhancement proposals and testing scenarios for new
functionalities.

In Radio Network Database Parameter Consistency checking case; different solutions
are proposed for implementation (see 5.3.1 for detailed analysis). As a consequence of
analysis, reliable and efficient implementation was done for internal usage. With the
pace of the radio network technology evolution, future networks are designed to be
flexible in terms of network resources. To maintain same configuration information,
databases in the network elements must be same in terms of common parameters. For
future studies this database consistency check feature can be added to the RNC software
itself as an automated self-check tool.





81
In Formatted Printout of the RNW topology case; implementation proposal has been
made (see 5.3.2 for detailed analysis). Required message types were identified to build
the topology. For future studies, new type of visualization objects can be added such as
downlink RF channel number, downlink scrambling code of the WCEL and Absolute
radio frequency number. And it is important to update the implementation according to
the software baseline (data type) changes.

In Missing Neighbour Cell Definitions, implementation proposal has been made (see
5.3.3 for detailed analysis). For this issue, detected cell reporting feature has to be
turned on. Throughout the evolution of Cellular Radio systems, cell sizes are decreasing
and number of cells is increasing thus number of handover attempts are also increasing.
Neighbour cell definitions are very important for handover algorithms. For future
studies, there can be an automated self-check in the RNC software for neighbour cell
definitions which is based on the reports that are received from UEs.

In Handover Related Troubleshooting, KPI calculation comparisons and log file
filtering is very important. Implementation possibilities were proposed (see 5.3.4 for
detailed analysis). A KPI calculation comparison is a complex process that cannot be
used for all handover related problems. Only if there is a suspicion about KPI values
comparison can be done for the KPI values. On the other hand, log file analysis is a n
every day activity for troubleshooting experiences. For future studies, there can be new
parameters required to be in the filtered report.

In HSPA related issues, similar problems were analyzed from HSPA perspective and
implementation proposals have been made (see 5.3.5 for detailed analysis). Calculation
of certain parameters related with HSPA is an everyday need for troubleshooting
experiences. Required parameters can be updated upon request in the future. The
enhancement for HSPA Accessibility problems is important because it is hard to
investigate the problem from log files. In the future parameter set can be updated if
there is a new software baseline. Similar to previous analyses, using large log files is
always time-consuming thus it is also important to provide this feature.


82
To sum up, the scope of this thesis was to analyze the existing troubleshooting
experiences in NSN-WCDMA-Control Plane-Handover Algorithms team and study the
enhancements opportunities to increase the efficiency of R&D engineers. Study cases
were chosen after long discussions to increase the R&D engineers benefit from this
work. The benefit of this study will show itself in the long run. In the future, it would be
good to continue this type of efficiency related studies for different troubleshooting
cases and for different software platforms.





83
7 References
1. Mishra, A. R. Fundamentals of Cellular Network Planning and Optimisation : 2G /
2.5G / 3G - Evolution To 4G; John Wiley & Sons, 2004.
2. Collins, D.; Smith, C. 3G Wireless Networks, 1st ed.; McGraw - Hill Professional
Publishing, 2001.
3. Korhonen, J. Introduction to 3G Mobile Communications, 2nd ed.; Artech House:
Massachussets USA, 2003.
4. Holma, H.; Toskala, A. WCDMA for UMTS Radio Access for Third Generation
Mobile Communications, 3rd ed.; John Wiley & Sons, 2004.
5. 3GPP. 3GPP - Releases. http://www.3gpp.org/releases (accessed July 6, 2011).
6. Dalman, E.; Parkvall, S.; Skld, J.; Beming, P. 3G Evolution: HSPA and LTE for
Mobile Broadband, 1st ed.; Academic Press, 2007.
7. Tapia, P.; Liu, J.; Feuerstein, M. J. HSPA Performance and Evolution : A Practical
Perspective; Wiley, 2009.
8. Holma, H.; Toskala, A. HSDPA/HSUPA for UMTS: High Speed Radio Access for
Mobile Communications; John Wiley & Sons, 2006.
9. Holma, H.; Toskala, A. LTE for UMTS Evolution to LTE-Advanced, 2nd ed.; Wiley
& Sons, 2011.
10. Laiho, J.; Wacker, A.; Novosad, T. Radio Network Planning and Optimisation for
UMTS; John Wiley & Sons, 2006.
11. 3GPP TSG RAN. 3GPP Specification: 25.922 - Radio Resource Management
Strategies. http://www.3gpp.org/ftp/Specs/html-info/25922.htm (accessed July 6,
2011).
12. 3GPP. 3GPP Specification: 25.331 Radio Resource Control (RRC) Protocol
Specification. http://pda.etsi.org/exchangefolder/ts_125331v051100p.pdf (accessed
July 6, 2011).
13. Nokia Siemens Networks Internal Document. Radio Network Controller Software
Architecture Specification; NSN, 2010.




84
14. Ilama, J. Masters Thesis: Functional Regression Testing and Test Automation in a
3G Network Element Platform Environment; Helsinki University of Technology:
Espoo, 2010.
15. Silander, S. DX-Aapinen; Edita Oy, 1999.
16. Hrknen, P. Master's Thesis: Static Memory Optimization of Handover Control;
Helsinki Metropolia University of Applied Sciences: Espoo, 2010.



85

8 Appendixes
8.1 Data types
8.1.1 ha3_rnw_parameter_query_s message
rak_create_ha3_adjd_cell_s: RNW Manager hand process sends this message to
Handover Control Algorithm HC-master process to notify, that one new
additional intra-frequency adjacent cell to specified WCDMA cell has been
created into the RNW RNC database.
RNW Manager hand process HC-master process
WCEL_ID: WCDMA cell identifier of cell under which the new intra-frequency
adjacent cell is created. (Identifies a WCEL unambiguously within a RNC)
HA3_ADJD_PARAM: Additional adjacent cell parameters needed by Handover
Control Algorithm Program Block. (In ha3_adjd_t data type; adjd_id defines the
identification of ADJD (Additional Intra-Frequency ADJ), utran_cell_id defines
the UTRAN cell identifier identifies neighbouring cell uniquely within UTRAN.
This one is used internally in RNC. )

rak_create_ha3_adjg_cell_s: RNW Manager hand process sends this message to
HC-master process to notify, that one new GSM adjacent cell to specified
WCDMA cell has been created into the RNW RNC database.
RNW hand process HC-master process
WCEL_ID: WCDMA cell identifier of the modified WCDMA cell. (Identifies a
WCEL unambiguously within a RNC)
HA3_ADJG_PARAM: GSM neighbour cell parameters needed by Handover
Control Algorithm Program Block. (In ha3_adjg_t data type; adjg_id defines the
Identification of ADJG, cell_id identifies a WCEL unambiguously within a RNC)




86
rak_create_ha3_adji_cell_s: RNW Manager hand process sends this message to HC-
master process to notify, that one new inter-frequency adjacent cell to specified
WCDMA cell has been created into the RNW RNC database.
RNW hand process HC-master process
WCEL_ID: Cell id of the modified WCDMA cell.
HA3_ADJI_PARAM: Inter-frequency neighbour cell parameters needed by
Handover Control Algorithm Program Block. (In ha3_adji_t data type; adji_id
defines the identification of the ADJI, and utran_cell_id defines the UTRAN cell
identifier identifies neighbouring cell uniquely within UTRAN. This one is used
internally in RNC. )

rak_create_ha3_adjs_cell_s: RNW Manager hand process sends this message to HC-
master process to notify, that one new intra- frequency adjacent cell to specified
WCDMA cell has been created into the RNW RNC database.
RNW hand process HC-master process
WCEL_ID: WCDMA cell identifier of cell under which the new intra-frequency
adjacent cell is created. (Identifies a WCEL unambiguously within a RNC)
HA3_ADJS_PARAM: Adjacent cell parameters needed by Handover Control
Algorithm Program Block. (In ha3_adjs_t data type; adjs_id defines the
identification of ADJS (Intra-Frequency ADJ), utran_cell_id defines the UTRAN
cell identifier identifies neighbouring cell uniquely within UTRAN. This one is
used internally in RNC. )

rak_create_ha3_fmcg_s: RNW Manager hand process sends this message to HC-
master process to notify, that one new set of GSM measurement control
parameters has been created into the RNW RNC database.

rak_create_ha3_fmci_s: RNW Manager hand process sends this message to HC-
master process to notify, that one new set of inter-frequency measurement control
parameters has been created into the RNW RNC database.

rak_create_ha3_fmcs_s: RNW Manager hand process sends this message to HC-
master process to notify, that one new set of intra-frequency measurement control
parameters has been created into the RNW RNC database.
87

rak_create_ha3_hopg_s: RNW Manager hand process sends this message to HC-
master process to notify, that one new set of GSM handover path parameters has
been created into the RNW RNC database.

rak_create_ha3_hopi_s: RNW Manager hand process sends this message to HC-
master process to notify, that one new set of inter-frequency handover path
parameters has been created into the RNW RNC database.

rak_create_ha3_hops_s: RNW Manager hand process sends this message to HC-
master process to notify, that one new set of intra-frequency handover path
parameters has been created into the RNW RNC database.

rak_create_ha3_wane_s: RNW Manager hand process sends this message to HC-
master process to notify that one new set of WCDMA authorized network
parameters has been created into the RNC RNW database.

rak_create_ha3_wcel_s: RNW Manager hand process sends this message to HC-
master process to notify, that one new WCDMA cell has been created into the
RNW RNC database.
RNW hand process Handover Control Algorithm master process
WBTS_PARAM: Handover Control Algorithm Program Block related WCDMA
base transceiver station parameters of the WCDMA cell, which is created.(In
ha3_wbts_param_t data type wbts_id defines the identification of the WBTS)
WCEL_PARAM: WCDMA cell parameters, which concern only the Handover
Control Algorithm processes. (In ha3_wcel_param_t data type wcel_id identifies a
WCEL unambiguously within a RNC)

rak_create_ha3_wsg_s: RNW Manager hand process sends this message to HC-master
process to notify, that one new WCDMA subscriber group has been created to
RNC RNW database.

rak_modify_ha3_rnc_param_s: RNW Manager hand process sends this message to
HC-master process to notify, that RNC parameters has been modified.
88

rak_modify_ha3_vbts_param_s: RNW Manager hand process sends this message to
HC-master process to notify that VBTS parameters have been modified.

rak_modify_ha3_vcel_param_s: RNW Manager hand process sends this message to
HC-master process to notify that VCEL parameters have been modified.