Optim

CAUTION IST-2000-25352
D-2.1
Requirements Analysis and Functional Specifications
Contractual Date of Delivery to the CEC: 30.6.2001

Actual Date of Delivery to the CEC: 13.7.2001
Author(s): Kostas Vlahodimitropoulos1 (editor), Axilleas Chatzikontantinou1, Filippos Kyriazidis1,
Sofoklis Kyriazakos2, Evangelos Gkroustiotis2, Charis Kechagias2, Chris Karambalis2,
B. Petropoulos2, Z. Lioupas2, M. Agapitos2, F. Evmorfopoulos2
Sami Nousianen3, Krzysztof Kordybach3, Kristian Ukkonen3,
Lennart Larsson4, Antony Marinidis4,
Ivan Mura5, Gianluca Previti5, Massimo Barbera5, Fernanda Farinaccio5, Paola Dal Zovo5,
Lucia Oneto5, Cristina Barbero5, Speros Velentzas5
Participant(s): COSMOTE1, ICCS/NTUA2, VTT3, TELIA4, MOTOROLA5
Workpackage: WP2
Est. person months: 20
Security: Pub.
Nature: R
Version: 3.1
Total number of pages: 265
Abstract:
Deliverable D-2.1 is named Requirement Analysis and Functional Specifications, and presents the work carried
out in WP2 of CAUTION project. The deliverable consists of two thematic areas. The first one, which is the
largest, is an extensive study and statistical evaluation of operational data, classification and characterization of
traffic-load scenarios, review and evaluation of congestion management techniques and finally congestion
analysis for emerging technologies. The second thematic area of this deliverable is the functional specifications
of the CAUTION architecture. This is mainly a high-level specification of the CAUTION elements. This
deliverable is the final result of WP2 and additionally the first milestone of CAUTION project. Although the
evaluation and implementation mainly refers to existing networks, conclusions and guidelines will be very useful
for next generation cellular networks. Therefore, within the scope of CAUTION project, GPRS issues are also
investigated and the development of a UMTS simulator is presented.
Keyword list: requirements, congestion study, management techniques, high-level specifications

D-2.1 Requirements Analysis and Functional Specifications Page 2
DOCUMENT HISTORY
Date Version Status Comments

27.03.2001 0.0 Int Initial version (ToC) for partners’ comments
10.04.2001 0.1 Int Final ToC
01.06.2001 1.0 Int 1st deliverable draft
06.07.2001 2.0 Int 2nd deliverable draft
11.07.2001 3.0 Int Final deliverable draft
12.07.2001 3.1 Apr Approved document
Copyright  2001 CAUTION Consortium 13/7/2001

TABLE OF CONTENTS
1 EXECUTIVE SUMMARY ........................................................................................................................ 10

2 INTRODUCTION ...................................................................................................................................... 12
3 STATISTICAL ANALYSIS OF OPERATIONAL DATA IN CONGESTION SITUTATIONS........ 14
3.1 DESCRIPTION OF EXISTING CELLULAR NETWORK REPORTING ................................................................. 14
3.2 CHARACTERISTIC CONGESTION DIAGRAMS ............................................................................................ 19
3.3 EVALUATION OF RESULTS ...................................................................................................................... 30
3.4 HSCSD / GPRS STATISTICAL EVALUATION........................................................................................... 48
4 TRAFFIC-LOAD SCENARIOS AND TRAFFIC MODELING............................................................ 58
4.1 TRAFFIC LOAD SCENARIOS ..................................................................................................................... 58
4.2 TRAFFIC MODELING ................................................................................................................................ 68
5 REVIEW AND EVALUATION OF RESOURCE MANAGEMENT TECHNIQUES IN CELLULAR
NETWORKS ..................................................................................................................................................... 105
5.1 RESOURCE MANAGEMENT TECHNIQUES IN CELLULAR NETWORKS OF 2G............................................. 105
5.2 RESOURCE MANAGEMENT TECHNIQUES IN CELLULAR NETWORKS OF 2+G .......................................... 156
5.3 RESOURCE MANAGEMENT TECHNIQUES IN CELLULAR NETWORKS OF 3G ............................................ 168
6 ANALYSIS OF EMERGING TECHNOLOGIES REQUIREMENTS ............................................... 175
6.1 WAP .................................................................................................................................................... 175
6.2 HSCSD ................................................................................................................................................ 177
6.3 GPRS ................................................................................................................................................... 178
6.4 EDGE/EGPRS..................................................................................................................................... 180
6.5 UMTS REQUIREMENTS ........................................................................................................................ 182
7 GUIDELINES FOR SYSTEM REQUIREMENTS............................................................................... 196
7.1 CAUTION HIGH LEVEL LOGICAL ARCHITECTURE................................................................................ 196
7.2 ITMU................................................................................................................................................... 197
7.3 RMU.................................................................................................................................................... 201
7.4 PRIORITY CALL SERVER ........................................................................................................................ 203
7.5 EMERGENCY CALL CENTER .................................................................................................................. 204
8 UMTS SIMULATOR ............................................................................................................................... 205
8.1 GENERAL DESCRIPTION ........................................................................................................................ 205
8.2 SIMULATOR CORE................................................................................................................................. 206
8.3 IMPLEMENTATION ASPECTS .................................................................................................................. 215
9 CONCLUSIONS ....................................................................................................................................... 234
10 APPENDIX 1: REPORTING IN GSM................................................................................................ 235
10.1 EVENT COUNTERS ............................................................................................................................ 235
10.2 CALCULATION OF SUCCESS/FAILURE RATES ..................................................................................... 246
11 APPENDIX 2: NETWORK SIMULATOR STRUCTURE ............................................................... 249
11.1 PARAMETERS ................................................................................................................................... 249
11.2 CELL CAPACITY ................................................................................................................................ 249
11.3 TRAFFIC DENSITY ............................................................................................................................. 249
11.4 PERIODIC LOCATION UPDATE ........................................................................................................... 250
11.5 SCENARIOS ....................................................................................................................................... 250
11.6 TECHNIQUES .................................................................................................................................... 251
11.7 RESULTS ........................................................................................................................................... 251
11.8 FURTHER WORK................................................................................................................................ 251
12 APPENDIX 3: LOGICAL CHANNELS IN GSM NETWORKS ..................................................... 252

12.1 MULTIPLEX STRUCTURE ................................................................................................................... 252

12.2 FREQUENCY-MULTIPLEXING STRUCTURE ......................................................................................... 252
12.3 TIME-MULTIPLEXING STRUCTURE .................................................................................................... 252
12.4 FREQUENCY HOPPING ....................................................................................................................... 253
12.5 LOGICAL CHANNELS ......................................................................................................................... 253
12.6 HIERARCHY OF FRAME STRUCTURES ................................................................................................ 255
12.7 COMBINATIONS OF LOGICAL CHANNELS ........................................................................................... 255
13 APPENDIX 4: TRAFFICA NETWORK ............................................................................................ 257
13.1 TRAFFICA NETWORK ........................................................................................................................ 257
13.2 TRAFFICA NETWORK ARCHITECTURE ............................................................................................... 259
REFERENCES .................................................................................................................................................. 263

TERMS AND ACRONYMS
2G Second Generation of wireless communication systems

3G Third Generation of wireless communication systems
3GPP Third-Generation Partnership Project (W-CDMA)
ACC Automatic Congestion Control
ACC Acceptable Channel Coding
AGCH Access Grant Channel
AICH Acquisition Indicator Channel
AIUR Wanted Air Interface User Rate
AIVPRB A Interface Signaling Program Block in BSC
AMR Advanced Muti-Rate codec
AP-AICH Access Preamble Acquisition Indicator Channel
ASYM Channel coding ASYMetry indication
AUC Authentication Center
BCCH Broadcast Control Channel
BCH Broadcast Channel
BER Bit Error Rate
BFHFIL BTS Forced Handover Data Structure
BH Busy Hour
BLER Block Error Rate
BR Blocking Rate
BSC Base Station Controller
BSS Base Station Subsystem
BSTAFI BTS State Data Structure
BTS Base Transceiver Station
C/I Carrier to interference ratio
CAC Call Admission Control
CBCH Cell Broadcast Channel
CCCH Common Control Channel
CD/CA – ICH Collision Detection Channel Assignment Indicator Channel
CDMA Code Division Multiple Access
CI Cell identifier
CN Core network
CPCH Common Packet Channel

CPICH Power control of common pilot channel

CS Circuit Switched
CSICH CPCH Status Indicator Channel
CSSR Call Setup Success Rate
CTCH Common Traffic Channel
DCCH Dedicated Control Channel
DCH Dedicated Channel
DECT Digital European Cordless Telecommunications
DL Downlink
DPCCH Dedicated physical Data Channel
DPCH Downlink Dedicated Physical Channel
DPDCH Dedicated Physical Control Channel
DR Directed Retry
DR Dual Rate
DRNC Drift RNC
DSCH Downlink Shared Channel
DTCH Dedicated Traffic Channel
DTX Discontinuous Transmission
EDGE Enhanced Data for Global Evolution
EFR Enhanced Full Rate
EFR Enhanced Full Rate
EGPRS Enhanced GPRS
EIR Equipment Identity Register
eMLPP enhanced Multi-Level Precedence and Pre-emption service
ETSI European Telecommunications Standard Institute
FACCH Fast Associated Control Channel
FACH Forward Access Channel
FDD Frequency Division Duplex
FM Fault Management
FNUR Fixed Network User Rate
FR Full Rate
FTP File Transfer Protocol
GGSN Gateway GPRS Support Node
GMSC Gateway MSC
GMSK Gaussian minimum-shift keying
GPRS General Packet Radio Service
GSM Global System for Mobile Communication

GTP GPRS Tunneling Protocol

GUI Graphic User Interface
GUPDAT BSC Configuration Updating Program Block
HASPRB Handover Attempt Supervisor Program Block
HLR Home Location Registry
HO Handover
HOSR Handover Success Rate
HR Half Rate
HSCSD High Speed Circuit Switched Data
IMSI International Mobile Station Identity
IP – M Multicast IP
ISDN Integrated Services Digital Network
ITMU Interface Traffic monitoring Unit
LA Location Area
LAN Local Area Network
LU Location Update
MAP Mobile Application Part
MCMU Cellular Management Unit
MCN Micro cellular network
MM Mobility Management
MML Man Machine Language
MOC Mobile Originating Calls
MoU Memorandum of Understanding
MS Mobile Station
MSC Mobile Switching Center
MTC Mobile Terminating Calls
NDW Network Data Warehouse
NMC Network Management Center
NMS Network Management System
NSS Network Switched Subsystem
OASCU Off Air Call Setup
OMC Operations & Maintenance Center
OMT Other Mobile Type
OVSF Orthogonal Variable Spreading
PBTHAN Base Transceiver Station parameter Handling MML
PC Power Control
PCCH Paging Control Channel

P-CCPCH Primary Common Control Physical Channel

PCH Paging Channel
PCPCH Physical Common Packet Channel
P-CPICH Primary Common Pilot Channel
PDP Packet Data Protocol
PDSCH Physical Downlink Shared Channel
PHY Physical Layer
PICH Paging Indicator Channel
PLMN Public Land-mobile Network
PM Performance Management
POTS Plain Old Telephone Service
PRACH Physical Random Access Channel
PS Packet Switched
PSK Phase shift keying
PSTN Public Switched Telephone Network
PTM Point to Multipoint
PTM – G PTM Group Call
PTM – M Multicast
P-TMSI Temporary mobile subscriber identity
PTP Point to Point
PTP – CLNS PTP Connectionless Network Service
PTP – CONS PTP Connection Oriented Network Service
QoS Quality of Service
RA Routing Area
RACH Random Access Channel
RAI Routing area identity
RCSPRB Radio Connection Supervision Program Block
RFI External Functionality Interface
RLC Radio Link Control Protocol
RMU Resource Management Unit
RNC Radio Network Controller under UMTS
RNW Radio Network
RSCP Received Signal Code Power
RSSI Received Signal Strength Indicator
RTT Round Trip Time
RTT Real Time Traffic
SACCH Slow Associated Control Channel

SCCH Signaling Control Channel

S-CCPCH Secondary Common Control Physical Channel
SCH Signaling Channel
SCH Synchronization Channel
S-CPICH Secondary Common Pilot Channel
SDCCH Slow Dedicated Control Channel
SGSN Serving GPRS Support Node
SIWFS Shared Inter Working Function Server
SM Session management
SMS Short Messaging Service
SRNC Serving RNC
SU Signaling Unit
TCH Traffic Channel
TCH/F Full Rate Traffic Channel
TCH/H Half Rate Traffic Channel
TCHSTA Traffic Channel Status Data Structure
TCP Transmission Control Protocol
TDD Time Division Duplex
TDMA Time Division Multiplex Access
TMSI Temporary Mobile Subscriber Identity
TN Timeslot Numbers
TR Trunk Reservation
UIMI User Initiated Modification Indication
UL Uplink
UMTS Universal Mobile Telecommunications System
URA UTRAN Registration Area
UTRAN UMTS Terrestrial Radio Access Network
Uu Radio Interface (UMTS)
VLR Visitor Location Registry
WAP Wireless Application Protocol
WCDMA Wideband Code Division Multiple Access

1 EXECUTIVE SUMMARY
Traffic congestion in cellular networks of 2nd and 3rd generation is a very hot issue for mobile network operators.
Unfortunately it has been proved that today's infrastructures have failed to address this issue efficiently so far, a
fact that was dramatically demonstrated during critical situations, e.g. earthquakes, New Year’s Eve, public
events, etc. Mobile network operators received strong criticism on their failure to address the communication
needs of their users.
This deliverable is the main outcome of WP2 and additionally it is the first milestone of CAUTION project.
WP2 is concerned mainly with the requirements extraction and analysis for all the aspects of the CAUTION
system and this deliverable aims to form the guideline of the forthcoming system's implementation. In this
document the following are reported in detail: statistical evaluation, traffic-load scenarios, congestion
management techniques, analysis of emerging technologies requirements and formulation of guidelines for the
system architecture corresponding to the major activities and tasks of WP2.
Since the deliverable is covering both requirements extraction and analysis of the system and high-level
functional specifications the first step was the evaluation of operational data of existing GSM networks in order
to trace potential bottlenecks and identify abnormal behaviors that affect their performance. This in-depth study
has revealed on the one hand the different traffic-patterns that appear at the system's interfaces, on the other hand
the various factors that lead to problematic situations and congestion. A general conclusion that comes up as a
result of our studies is that cellular GSM networks are not optimized and the transition from 2G to 2+ and 3G
has to be done in such a way to cope efficiently with shortcomings whenever these appear.
The document is organized as follows. Chapter 1 is the executive summary of the deliverable providing it's
purpose and its contents in a concentrated manner. Chapter 2 is the document’s introduction, which focuses on
the methodology that has been followed in order to achieve the objectives of this deliverable.
Chapter 3 is the presentation of the statistical analysis of operational data during periods of congestion. Initially
the reporting mechanisms used by cellular operators are presented and subsequently the statistical evaluations
are given, both during normal and congestion situations. The resulting diagrams and the corresponding
mathematical formulas are discussed and the identified problems are listed. HSCSD and GPRS measurements
are also included, in order to identify problems and limitations of emerging technologies.
Chapter 4 is named Traffic-load scenarios and traffic modeling. Traffic modeling is concerned with the modeling
of the various procedures and logical channels existing in a communication system, as well as with their
respective traffic patterns. In the beginning this chapter classifies the traffic load to a number of different
categories that correspond to the different available services offered by the system. In that way the various traffic
load patterns can be seen as entities that can be characterized and fine-tuned by a set of specific parameters. This
is quite important for the implementation later on, since it will be easier to understand the state, where the system
is at each time and take the appropriate decisions.
The scope of chapter 5 is to evaluate existing resource management techniques in cellular networks, to check
their possibilities for enhancements and also to identify new techniques. From the techniques presented some are
focusing on traffic channel allocation while others on control channels. There are also a number of techniques
that can be applied on both logical channels simultaneously. For the purpose of the study of congestion
management techniques, an appropriate network simulator was developed. The techniques presented are
classified in GSM, 2+ and 3G systems.
In chapter 6, an analysis of the traffic requirements of emerging technologies in cellular networks is given in
order to identify these distinct situations that will affect the network's performance in a negative way. In
particular WAP, HSCSD, GPRS and EDGE are studied and the points that may present problems and may
require the existence of a specifying "healing" functionality within the network are identified.

Based on the results of the previous chapters, chapter 7 provides a set of specific guidelines that would form the
basis for the realization of the CAUTION architecture, which is the subject of WP3.
Chapter 8 is a detailed description of the UMTS simulator that will be developed in order to evaluate and
validate the usage of the identified resource management techniques in this specific environment and to
formulate proposals for their efficient deployment.
Finally, chapter 9 is the conclusions, where emphasis is given to the major outcomes of the work within the
framework of this deliverable.

2 INTRODUCTION
Deliverable D-2.1, Requirement Analysis and Functional Specifications, is the presentation of the work done in
WP2 of the project. There are two thematic areas covered in this deliverable. The first one, which is the largest,
consists of an extensive study and statistical evaluation of operational data, classification and characterization of
traffic-load scenarios, review and evaluation of congestion management techniques and finally congestion
analysis for emerging technologies. The second thematic area of the deliverable is the functional specifications
of the CAUTION architecture. This consists mainly of a high-level specification of the CAUTION elements,
since the major part of the system specification will be handled in WP3.
Cellular systems of current and next generation that are classified in large-scale systems have to be optimized in
terms of survivability. Innovative technologies and mechanisms have to be applied to cope with vulnerabilities
of the above-mentioned unbounded systems. CAUTION main objective is to propose and implement innovative
mechanisms, promising enhanced capacity management, especially in critical situations. Research in the area of
congestion control will enable the development of techniques for implementation and integration of efficient
mechanisms in existing and next generation networks.
Since the cellular traffic congestion is a very hot issue, after the failure of the networks to serve subscribers and
authorities in the congestion situations, there are already many proposals and ideas to be applied in a generic
network architecture, that will support heavy network traffic. Priority schemes and dynamic channel
(re)allocation, as well as techniques that are based on time-limited calls are already under discussion. Knowledge
management mechanisms that evaluate the traffic of neighbor cells and take critical decisions for handover
executions will decrease the logical (signaling) channel traffic. The bandwidth will be then effectively allocated
to the users who need to be served.
The demand for data transmission in higher data-rates compared to the 9,6 kbit/s that are nowadays offered by
the GSM and the need for multimedia services over mobile networks have led to HSCSD, GPRS and EDGE.
The cellular operators in Europe have started HSCSD circuit-switched based networks during 2000 and GPRS
has recently been introduced to GSM networks around the world. On the one hand the data-networks will attract
even more subscribers, on the other hand the expected network congestion will create new problems.
The efficient capacity management allows the utilization of all traffic resources, in contrast with the existing
management that make use only of a part of the available resources, due to the lack of intelligent channel
assignment mechanisms in cases of congestion.
The CAUTION architecture is governed mainly by two concepts, namely real-time monitoring and efficient
resource allocation and control. Although the evaluation and implementation will take place in existing
networks, conclusions and guidelines will be very useful for next generation cellular networks. Therefore, within
the scope of CAUTION project, GPRS issues will be extensively investigated and UMTS simulations may prove
that there are similar ways of congestion management in cellular networks.
A number of resource management techniques for the next generation cellular networks is also reviewed and
analyzed. These techniques are then taken into account for the formulation of the guidelines for the system's
realization.
Traffic-load scenarios are set-up and congestion is classified. This has resulted in a more efficient way to solve
congestion problems, since each situation can be characterized by a set of parameters. Furthermore, several
congestion management techniques are studied and evaluated. Some of them already exist, but they are not
efficiently applied. The relevant scenarios are characterized by “overload conditions”, where overload is to be
intended with respect to the average situation. Indeed, a potential congestion scenario usually considers either
situations in which a large number of people is concentrated in a delimited location or a situation that induce
many users to call at the same time. The reasons and the consequences of a congestion situation may be of
variety of types, ranging from the periodic overload peak of a daily busy hour to the unpredictable occurrence of
a catastrophic large-scale event.

Scenarios have been first characterized on a phenomenological basis, and then have been compared against a set
of predictability criteria that will help in defining a scenario identification procedure. The identified scenarios are
classified in terms of time, traffic, and location predictability. A given scenario is considered time and location
predictable if the time and the location of the event represented by the scenario is known in advance, while the
scenario is considered as traffic predictable if the expected traffic can be estimated, based on data collected in
previous similar events. The set of overload situations identified are then described in terms of observability of
the congestion appearance and of the consequent effects. This scenario characterization will represent a relevant
piece of the information the Resource Monitoring Unit (RMU) algorithm will be built upon.
In CAUTION project the management techniques should be applied immediately in a way to encounter
unpredictable congestion situations as well. Emerging technologies, mostly all 2+ features were investigated and
analyzed, in terms of how they influence the traffic load in cellular networks.
After finishing the extensive analysis functional requirements are made for the CAUTION system. The problems
identified from the statistical evaluation and the relevant simulations lead to conclusions about the requirements
of the system that will be implemented in the following months of the project. The achievement of the first
milestone will be a smooth handover from the requirements phase of the project to the specifications one, based
on the input that has been produced in WP2.
The document is organized as follows. Chapter 1 is an executive summary of the deliverable. It is a high level
description of the contents and it mainly describes the general concept. Chapter 2 is the document’s introduction.
Chapter 3 is the presentation of the statistical analysis of operational data in congestion situations. The statistical
evaluation is based on an in-depth study performed by the CAUTION partners, evaluating reports from the data
warehouse of a cellular network. In the Appendix 1 of this document there is a detail description of the event
counters that were evaluated for this purpose. Based on this event counters, a set of formulas is given that can
fully describe the network performance, both in normal and congestion situation. Based on these formulas
diagrams and mathematical formulas are discussed in chapter 3 and identification of usual problems is listed.
Chapter 4 is named Traffic-load scenarios and traffic modeling. This chapter classifies the traffic load, so that it
can be seen as a system that can be characterized by a set of parameters. This is quite important for the further
implementation, since it will be easier to understand the state, where the system is each time. Traffic modeling is
mainly the modeling of several procedures and logical channels, as well as the traffic pattern. Chapter 5 is the list
of resource management techniques in cellular networks. This is classified in GSM, 2+ and 3G systems. In
chapter 6, analysis of emerging technologies is given, in terms of requirements and influence for congestion.
These technologies are HSCSD, GPRS, EDGE and UMTS. Chapter 7 takes into account the previous chapters
and forms the guidelines for the CAUTION architecture. These guidelines can be seen as a high level logical
architecture of the CAUTION system and its elements. Chapter 8 is a detailed description of the UMTS
simulator that will be developed for CAUTION studies. Finally, chapter 9 is the conclusions, where emphasis is
given to major issues that are analyzed in this document.
Additional to the main document there are 4 Appendixes attached, which are very useful for the understanding
and the in-depth investigation of the system. Appendix 1, as described above, is a description of the reporting
system in cellular networks. Appendix 2 is a description of the models that were implemented in a simple
simulator in order to investigate the performance of the management techniques. Appendix 3 is a description of
the logical channels in GSM and the combination of them in the real environment. This is quite important for
understanding the available channel resources in cellular systems. Finally, Appendix 4 is a description of one
existing monitoring tool for GSM systems.

3 STATISTICAL ANALYSIS OF OPERATIONAL DATA IN

CONGESTION SITUTATIONS
3.1 Description of existing cellular network reporting

The performance of cellular networks is the most important issue concerning their operators. Their main goal is
to keep satisfied the customer/subscriber with the quality of the services they provide. In order to achieve best
performance, they have to monitor and optimize their network continuously. A Network Management System
with an online database is responsible for the collection of everything that happens on the network, in a raw data
form. For greater effectiveness, operators install systems that do a lot more than collect and store (they organize
data in event counters, generate web reports etc.), are easier to use and take advantage of all the data provided by
the NMS. In the following subsections, such a system (a data warehouse) will be presented, as it provided the
data that were studied, and gives an extensive description of the most important event counters, that the data was
consisted of. In CAUTION project one of the most important tasks was the statistical evaluation of performance
data, focusing on congestion situations. For that purpose, historical data was from the data warehouse was
evaluated. In the following sections a good overview of the data warehouse and the reporting mechanism is
given. The counters that have been used for the statistical evaluation are described in detail in Appendix 1.
3.1.1 Introduction to Network Data Warehouse (NDW)

NDW was developed to optimize the performance of telecommunication networks. It collects, stores, manages
and presents data on a long-term basis. The NDW is a combined data collection and data handling system
comprised of Unix and NT servers. Therefore, part of the NDW processes run in a Unix environment and part of
the processes run in a Windows NT environment.
In the Unix environment these processes are dealt with:

• Data collection
• Data storage
• Pre-processing tasks
In the NT environment these processes are dealt with:

• Report generation
• Data analysis
• Report publishing via the intranet
After the pre-processed data is processed, the user finally sees:

• Automatically generated web-page reports
• Ad-hoc reports which can be created from scratch
• Reports, which are executed on demand according to given parameters.
This chapter provides an overview of the NDW, its utility and effectiveness, its architecture and how to work
with it. Differences between the NMS online database and NDW are also listed. This is done to highlight the
different storage capacities in the two systems. The NDW stores data for longer periods of time as opposed to
the NMS online database.
3.1.2 NDW Processes

The part of NDW located on a separate Unix database server allows storing performance measurements, alarms
and radioing network parameters for long periods of time. It can store this data for several years. Raw
performance measurement data (PM data), alarm data (FM data) and radio network parameter data (RNW data)

is extracted from the operational NMS database and stored periodically in the NDW. Data is processed into
summaries according to the type of data. Figure 1 shows the processes of collecting and processing data in
NDW.
ONLINE
DATABASE
Topology DB
PREPROCESSES
TEMPLATE
NMS PM DB
PM DATA
NMS FM DB DATA
FM DATA POSTPROCESSING
WAREHOUSE ANALYSIS TOOLS
RNW DB
RNW DATA
NETWORK
ANALYSIS
REPORT
Figure 1: Network Data Warehouse
3.1.3 Optimizing NMS with NDW

The larger the network is and the more active measurements there are in each network element, the heavier the
load on the network management system. By keeping daily online processing clearly separated from the off-line
analysis of long-term data, NDW ensures better overall performance of the NMS.
Summarizing raw PM data in NDW, allows reducing the load of the NMS, as well as to store measurement data
covering substantially longer periods of time. Stored data can be used in NDW to forecast future trends in the
network. In the NDW, Fault Management (FM), Performance Management (PM) and Radio Network (RNW)
data is reorganized and combined which makes it easier to generate trend data reports.
3.1.3.1 Data Processing and Presentation in NDW

Long-term data in NDW can be extracted and processed with NMS post-processing tools designed for PC
environments. These tools enables presenting long-term data in various reports, which show trends in the
functioning of the network, the behavior of end users as well as in relations between the performance
measurements data, alarm data and radio network parameter data.
3.1.3.2 Differences between NMS online database and NDW

There are several differences between the online NMS database and NDW. Table 1 summarizes the basic
differences.

Table 1: NMS / NDW characteristics

NMS NDW
Short time range for data Long time range for data
All details available Some details not available
Online monitoring (thresholds etc.) Off-line usage
Troubleshooting oriented Analysis and trend reporting oriented
Access limited Access to wider scope of users
Raw data Pre-processed data
Only PM history PM, FM and RNW data combined
The principal vale here is the division of tasks between the NMS and the NDW. Daily online monitoring and
troubleshooting is carried out in the NMS database. NDW carries out daily, weekly and monthly reporting,
analysis and forecasting. The NMS processes need up-to-date, detailed data, whereas NDW processes require
pre-processed filtered data.
3.1.4 NDW Architecture

NDW architecture is composed of five major areas. Each of these areas deals with one aspect of the workflow in
NDW. These processes begin with the collection of data from the NMS ad end with the distribution of reports on
the intranet. Table 2 shows the role of each area in the NDW architecture. The subsections below Table 2
describe these five areas further.
Table 2: Description of NDW areas

AREA DESCRIPTION
Data collection The area concerned with the collection of data
from the NMS and other data resources
Data storage Storing and pre-processing (summarizing) the
data in the NDW database
Data analysis Post-processing the data with NDW analysis tools
to extract information for the end-user from the
NDW database
Report distribution Generating analysis reports automatically and
distributing them in the intranet
Self management Area concerned with the supervision and
administration of the NDW itself
3.1.4.1 Data collection

The collection of data into NDW is carried out in a series of short, optimized queries. These queries are regulated
so that they take up a short period of time and exert a very low load on the NMS. This is because data collection
can be scheduled to take place outside peak periods and busy hours. The data is usually collected and inserted
into the NDW, once a day, during the night.
3.1.4.2 Data storage

Data is collected from several NMSs. NDW can store data for period of time ranging from several months to
several years. This time period is determined by the object and summary level, the size of the network and the
volume of disk capacity.

3.1.4.3 Data post-processing

The data in the NDW is not identical to the data in the online NMS database. After data collection some
automatic or ad-hoc analysis is carried out in order to use the data for long-term analysis, reporting and storage
purposes.
3.1.4.4 Report distribution

This area creates web page reports from automatically generated reports and publishes them for defined user-
groups to view. This area is therefore concerned with the processes of report generation and report distribution
on the intranet. These tasks take place on the NT server.
3.1.4.5 Self management

This area refers to the self-monitoring functions in the NDW. If some defect occurs, or some part begins to show
signs of failure, an alarm is sent. For example, if total disk capacity is about to be reached then an alarm is sent
to the supervising NMS, informing that the disk space is nearly full.
3.1.5 Types of Data in NDW

As mentioned above the NDW has FM, RNW and PM data, which it collects, combines and presents for
observation in the form of textual and graphical reports. These different types of data are listed and explained in
the following subsections.
3.1.5.1 FM data
The information in NDW on fault management contains the alarm status and acknowledgement status of the
managed objects. This information contains the class (critical, major or minor) of the most critical alarm active at
the time when the data was collected from the online database. Information on the unacknowledged alarms is
also available. Additionally, the alarm data is summarized.
3.1.5.2 RNW data

The raw cell level and the adjacent-cell level RNW parameters are also stored daily into the NDW. This makes it
possible to follow the effect parameter changes on the network in the long run. The following parameters are
fetched once a day from the NMS online database:
• BTS parameters
• Handover Control parameters
• Power Control parameters
• Adjacent-cell parameters
• Object state: Locked/Unlocked
In addition, RNW parameter history is also stored in the NDW database.
3.1.5.3 PM data
PM data forms a large part of the data in NDW. The PM data in the NDW can include summarized measurement
results from all counter levels, for example, BTS and BSC levels in the NMS. The raw PM data is summarized

according to the element hierarchy and according to time periods, for example, hourly, daily and weekly. Also
daily busy hour and weekly busy hour summaries of PM data are available. Hourly, daily and busy hour
summaries are calculated when the data is collected and inserted into the NDW, weekly summaries are
calculated once a week on Mondays.

3.2 Characteristic congestion diagrams

This section of the document deals with the graphical presentation of congestion situations. The most reliable
and representative performance indicators have been chosen throughout the analysis of operational data. In order
to be able to identify a congestion situation, the first part refers to patterns of a normal day, while the second part
refers to the exact point of a congestion problem. The performance indicators presented are Traffic, Call Setup
Success Rate (CSSR), Handover Success Rate (HOSR), SDCCH Blocking Rate (SDCCH BR) and TCH
Blocking Rate (TCH BR) and are all described in Appendix 1.
Traffic is chosen in order to see the augmentation of demand for services and channels in actual numbers, it is an
estimation of the congestion that will follow. Call Setup Success Rate and Handover Success Rate are chosen in
order to appreciate the impact of congestion in the two most important procedures during a call attempt,
regarding the quality of service offered to the subscribers. Finally, SDCCH and TCH Blocking Rates are chosen
in order to understand where exactly congestion appears (in terms of logical channels), as the respective channels
are the ones most affected in a congestion situation.
3.2.1 Normal situation diagrams

Traffic, Call Setup Success Rate, Handover Success Rate, SDCCH Blocking Rate and TCH Blocking Rate are
the indicators presented in this particular part. Their behavior on a normal day is examined by averaging the
measurements on BSC level (but for the entire network, as all BSCs participate), per hour of the day. It must be
noted that days presenting high congestion events are excluded from the averaging process, as they do not
comply with the normal day profile.
300
266.59
256.43 260.52
254.67 254.73
250 229.16 228.66

235.65
210.43
189.38 190.97
200 178.18 174.58
Erlang
142.43
150
117.74
96.91
100
57.75 62.18
50 34.58
25.86
21.78
15.0011.3712.52
0
10:00
12:00
14:00
16:00
18:00
20:00
22:00
0:00
2:00
4:00
6:00
8:00
Figure 2: Average daily traffic pattern
The particular pattern of traffic in Figure 2 presents two peaks: a lower one at 12.00 – 13.00, where it reaches
255 Erlang (BSC level) and a higher one at 19.00, where it reaches 266 Erlang. Usually, busy hour is considered
to be at noon, but our data analysis showed higher values in the afternoon peak. In addition, traffic reaches
minimum values of below 100 Erlang during the night, until the early morning hours. This pattern repeats itself

everyday with a slight variation on weekends (and especially Sundays), where the noon peak is much lower than
the usual.
100
98
96
94
91,4991,4691,19
9290,8590,7690,5190,3490,4690,1590,1190,92 90,79
90,3790,3390,3290,5290,3490,26 90,53
89,9589,6989,6589,9190,26
90
%
88
86
84
82
80
0:00
2:00
4:00
6:00
8:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
Figure 3: Daily Call Setup Success Rate (CSSR) pattern
In Figure 3 the CSSR pattern is similar to the one of the traffic, but inverted in a way. CSSR reaches minimum
points at the exact time that traffic reaches its peaks, showing that increase of traffic degradates this particular
success rate. The difference between the two charts is during the night, where CSSR also reaches minimum
values.
100
98
96
93,2392,91
94 92,4392,70
92,79
92,1092,28
91,53 91,64
92 90,60
90,12 89,8990,15 89,81
89,24
90
%
88,82 88,86 88,69

88,0688,24 88,08
87,5387,4287,68
88
86
84
82
80
0:00
2:00
4:00
6:00
8:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
Figure 4: Hand Over Success Rate (HOSR) pattern

The HOSR pattern in Figure 4 is an exact duplicate of the traffic pattern, but also inverted. It shows the lowest
values when traffic is at its highest ones and the minimum HOSR coincides with the traffic peak, thus showing a
chain effect phenomenon.
3
2,27
%
2,07 2,15
2
1,52
1,27
1,13 1,13
1,02 0,97
1 0,67 0,70 0,61 0,63
0,49 0,47
0,06 0,13 0,02

0,17 0,14 0,19
0,02 0,01 0,04
0
0:00
2:00
4:00
6:00
8:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
Figure 5: Daily SDCCH Blocking Rate pattern
The SDDCH Blocking Rate pattern in Figure 5 is also similar to the traffic, pattern presenting the same peaks at
13.00 and 19.00 and minimums at night, showing that increased traffic increases blocking too.
4
3,18 3,17 3,24
3,03 2,98
2,84 2,76
3 2,70
%
2,16
1,91 1,96
2 1,74
1,48
1,37
1,07
0,89
1
0,34 0,31
0,04 0,01 0,02 0,03 0,02 0,04
0
0:00
2:00
4:00
6:00
8:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
Figure 6: TCH Blocking Rate pattern

The TCH Blocking Rate pattern in Figure 6 is exactly the same pattern, as the traffic one. Same highs and lows,
same behavior throughout the day.
Looking carefully all the above charts, it is obvious that all indicators depend on traffic, which affects their
behavior, affects all procedures that these counters represent. This is called a chain effect phenomenon and is
more clearly perceived in the next part, where congestion charts are shown.
3.2.2 Detection of Congestion Situations

The following charts depict a high congestion situation and a low congestion (geographically limited) one. The
charts referring to traffic are not averaged, but the values show the entire network’s traffic (this time the result is
the same and the analysis is not affected by that fact).
25000
20000
15000
Erlang
10000
5000
Figure 7: Traffic on a high congestive situation
A predictable and expected event, as the New Year’s Eve situation, is depicted in Figure 7. Traffic increased
about 180% over a BH and about 500% over the same hour of a normal day. The event was perceived by the
entire network, all BSCs participated.
14000
12000
10000
8000
Erlang
6000
4000
2000
Figure 8: Traffic on a low congestive situation

In Figure 8 a congestive event is perceived by only a part of the network (geographically limited) and it is
neither predicted nor expected (local earthquake, only few BSCs participate). Traffic increases about 1000
Erlang on network level.
The following charts show the behavior of the network’s performance indicators in the two situations described
above. Congestion is easily detected and identified, depending on the situation, with the exception of SDCCH
BR in the low congestive event. If one ignores the abnormal peak that is created by outside reasons, in this
particular case, then SDCCH BR also goes along with what is discussed above.
100
90
80
70
60
50
%
40
30
20
10
Figure 9: CSSR on high congestive situation
100
97,5
95
92,5
90
%
87,5
85
82,5
80
Figure 10: CSSR on low congestive situation

100
90
80
70
60
50
%
40
30
20
10
Figure 11: HOSR on high congestive situation
100
90
80
70
60
50
%
40
30
20
10
Figure 12: HOSR on low congestive situation

100
90
80
70
60
50
%
40
30
20
10
Figure 13: SDCCH BR on high congestive situation
100
90
80
70
60
50
%
40
30
20
10
Figure 14: SDCCH BR on low congestive situation

100
90
80
70
60
50
%
40
30
20
10
Figure 15: TCH BR on high congestive situation
100
90
80
70
60
50
%
40
30
20
10
Figure 16: TCH BR on low congestive situation

3.2.3 Behavior of the network in traffic congestion

This section deals with the evaluation of results that were produced through the analysis of operational data. This
part depicts the behavior of the network’s performance and is a real example of a congestion problem, which
helps to understand the above, while it also refers to other types of blocking that can happen (other than the two
basic: TCH and SDCCH blocking). The following diagram depicts a real network in real time action. It presents
the behavior of its basic performance indicators through scaling congestion situations, thus presenting how the
network reacts in such conditions. It explains how exactly the chain effect phenomenon is triggered, where and
how each indicator is affected, as the congestion increases, and the result in a network basis. It must be noted
that indicators are relatively designed and not according to real figures (this part is the subject of the next
paragraph).
Figure 17: General network behavior in congestion situations
The diagram consists of four indicators: Traffic (light blue line), SDCCH Blocking (deep blue line), TCH
Blocking (red line) and Handover failures (green line). The first three are defined and explained above.
Handover failures are defined as HandOverSuccessRate, which is also defined above. The three vertical lines
represent the thresholds of low, medium and high congestion situations and they are very helpful in the
identification of each situation. Low congestion means that only few BSCs are affected and probably is
geographically limited, medium congestion means that a respective percent of BSCs participate in the crisis and
high congestion means that almost the entire network is affected. Of course, the above classification of situations
is also based on the results on network level.
At first, Traffic can also be considered as the throughput of the network. As seen in the diagram, it increases
beyond the threshold of the low congestion situation, but reaches a limit beyond the threshold of the medium
congestion conditions. This limit represents exactly how much traffic the network can handle (or the maximum
throughput the network can achieve). After the threshold of the high congestion, traffic is slightly degrading, as
the conditions worsen and the resources responsible for a service establishment (SDCCH mostly) dramatically
diminish.
As far as the SDCCH Blocking is concerned, it is clearly marked on the diagram that it is increasing
proportionally to the augmentation of the congestion level. This is normal, because the demand for establishment
resources increases, while resources are static and limited. In that way, blocking is increased proportionally to
the demand. The importance of the SDCCH Blocking in the whole study is that all procedures are SDCCH-
dependant, as shown in the above paragraph and will be shown in the next paragraphs also.

TCH Blocking also increases as traffic (or demand) increases, beyond the low congestion threshold, and reaches
a peak at medium congestion, accordingly to the traffic. As high congestion situations approach, TCH Blocking
clearly reduces its figures. This is also SDCCH-dependant and it happens because the network has run out of
establishment resources (SDCCH mostly), traffic is reduced and there are TCHs available. It must be noted that,
in cellular networks, TCHs outnumber SDCCHs in every single TRX.
Finally, Handover failure rate (the same applies for Call Setup failure rate, which is 1-CSSR) follows the curve
of TCH Blocking. It is also SDCCH-dependant, reaches its peak when TCH Blocking is at its highest point and
diminishes at high congestion conditions, because services cannot be established at this point. Concluding this
subchapter, it should be remarked that establishment resources (SDCCH mostly) encounter the most severe
problems, thus triggering a chain effect phenomenon that affects traffic resources and procedures, such as call
setup or handover. It should also be noted that beyond a certain point (approaching the high congestion situation
and the maximum handling of traffic takes place), services’ requests begin not to be served, but are in other
words cut off, thus decreasing TCH Blocking and Failure rates. If conditions worsen even more, even deeper
beyond the high congestion threshold, then the user cannot even reach the network (e.g. RACH Blocking, the
user cannot send a Channel Request message). The network then cannot even ‘understand’ this attempts, so the
above indicators are not affected beyond that point.
3.2.4 Handover in GSM

Handover can be caused by a lot of different reasons. Each mobile terminal attempts to use the radio channel that
will provide the best connection quality, i.e., the best C/I (carrier-to-interference ratio). Co-channel interference
is a factor that cannot be avoid because of multiple use of the same time and frequency channels due to existing
cell layouts, and consequently quality can be poor (i.e., bit-error ratio high) despite a high signal level. A usual
cause of interference to other mobile stations may be the connection of a mobile terminal to the base stations,
even if it is a high-quality one. The interference can be minimized if the interfered station changes to a different
radio channel. It is also possible for mobile users to have the same good receive quality from more than one cell.
The service quality of the network can then be optimized if mobile users are equally distributed over the
available cells.
A connection is continuously being measured and evaluated by the respective base station and MS. Handover is
based upon this evaluation. The decision algorithm mainly contributes to the spectral efficiency of the radio
network and the service quality as seen by the mobile subscriber. A mobile subscriber leaving the coverage area
of a base station must receive coverage from a neighboring base station in order to keep a connection intact.
Connection cut-off or “call drop" are not acceptable to the mobile user during conversation. The network, when
the traffic volume of a cell periodically reaches too high a level or when neighboring cells are being
underutilized, can also initiate handovers. In Figure 18 the main handover causes are presented. This is a result
of a statistical analysis of recorded data from operators, averaged over the whole network for a period of two
weeks.
Figure 18: Handover causes

According to the above graph, the main reason is the uplink/downlink level with 61%. Power budget is another
important reason for handover initiations (18%). Other reasons are: Downlink quality (13%), umbrella-cell
handover, interference, direct retry and OMC shortcomings.
Figure 19: Handover Success Rate
In Figure 19, the Handover Success Rate is indicated. With red line, the BSC controlled handovers are shown,
while with green line, the MSC controlled are shown. With blue line, the overall handover success rate is
indicated. Obviously the BSC handovers are easier to be handled; therefore, the success rate is higher. Another
conclusion is that the number of the MSC controlled handovers is significantly lower, since the MSC controlled
ones have only a minor influence to the overall graph.

3.3 Evaluation of results
This chapter deals with the evaluation of results that were produced through the analysis of operational data. It
consists of three subchapters, where the conclusions of our study are stated. The first part analyzes the chain
effect phenomenon, meaning how all procedures and the basic performance indicators are affected in a
congestion situation. The second part is a real example of a congestion problem that helps to understand the
above. Finally, the third part refers to other types of blocking that can happen (other than the two basic: TCH and
SDCCH blocking).
3.3.1 Behavior of the Network in traffic congestion

Throughout the whole procedure of the data processing and analysis, the severe chain effect phenomenon was
encountered, in every possible congestion situation. As the study was focused on the most important
performance indicators, a strong relation between them was observed in every different case examined. Focus
has been given on Call Setup Success Rate, HO Success Rate, TCH Blocking Rate and SDCCH Blocking Rate
and studied them with the help of the Traffic counter. These indicators and counters are properly defined (and
graphically presented) in the paragraphs above.
A first impression of the network’s reaction was given in section 3.3.2, where the above indicators are charted,
for the case of a large-scale (the whole network participated) event and of a low-scale (only few BSCs
participated) event. As the data was thoroughly analyzed, in both network and BSC level and in both large and
low scale events, it was remarked that the behavior of these counters was following one another, like one was
triggering the other. A grand increase of traffic caused a serious increase in TCH and SDCCH Blocking Rates,
thus triggering the dramatic degradation of Call Setup and HO Success Rates. As the study was extended to other
counters and indicators, it was observed that they followed the same behavior too. To be more specific, the
above situations are listed as follows:
3.3.1.1 Large-scale event (predictable, e.g. New Year’s Eve)

Most of or the entire network participates in such an event. Total traffic is augmented by 180% related to BH and
500% related to the same hour of a normal day, reaching the peak of 20000 Erlang. On network level, the TCH
Blocking Rate responds to the congestion situation reaching the value of 13%, while in a normal day’s BH is
3,25%. SDCCH Blocking Rate also perceives the heavy load of traffic as it climbs to 25%, while in normal
situations is about 2% (up to 5% in extremely loaded BHs). As described above, the Call Setup Success Rate is
triggered and a degradation to 70% from the usual 90% (up to 94%) is observed. At the same time, the handover
procedure is also affected, as the HO Success Rates falls to 72%, while in normal cases reaches values over 90%.
On BSC level, as all BSCs of the network contribute to the congestion situation, more or less the chain effect is
similar.
3.3.1.2 Low-scale event (local, unpredictable, e.g. earthquake)

The event takes place locally, only in a part of the network. Total traffic is increased by about 1000 Erlang, but
the event is perceived by the whole network. On network level, TCH Blocking Rate reaches 8,4%, while the day
before and the day after, at the same time, it was 2,4% and the usual rate is 3,25% in a typical BH. On BSC
level, BSCs that don’t have cells near the epicenter of the earthquake do not perceive the phenomenon, while
BSCs near the epicenter reach rates of 15% to 24%. SDCCH Blocking Rate climbs to 5% on network level,
double the usual rate, but in the limits of a normal busy hour. On BSC level, only BSCs near the epicenter are
affected, climbing to rates of 3% up to 5%. As described above, the Call Setup Success Rate is triggered and a
degradation to 87% from 92,5% of the day before and the day after. On BSC level, only BSCs near the epicenter
are affected, climbing to rates of 70% up to 85%. At the same time, the handover procedure is also affected, as
the HO Success Rates falls to 73%, while in normal cases reaches values over 90% (as it was the day before and

the day after, at the same time). Moreover, on BSC level, the results are even more persuasive for the chain
effect phenomenon: Randomly chosen BSCs with excellent behavior in one of the counters, present excellent
behavior in the other counters too. Randomly chosen BSCs with average behavior in one of the counters, present
the same results in the other counters too. The same thing happens to BSCs with bad behavior respectively.
There are of course exceptions met in that particular analysis, which have to do mostly with outside reasons.
3.3.1.3 Other counters and indicators

Apart from the basic performance indicators, the study was extended to different counters, in order to achieve a
better overview of the network’s behavior. Measurements from the Abis interface show that heavy traffic load,
though it can be handled by the air interface, present a bottleneck in the Abis point, concerning and affecting
mostly SDCCH Blocking Rate and paging procedure and less TCH Rates. Handover procedure is also affected,
as shown above. A look at handover causes counters confirms that fact, as directed retry handovers climb to 13%
in a large-scale situation, 7% in a low-scale case, while in normal cases reach only 2%. That shows how the lack
of resources affects the handover procedure in a deeper level than the HOSR. Congestion time in both TCH and
SDCCH was also investigated. Measurements show that SDCCH Congestion time was lower than 30 sec in
normal days, while it reached 1 up to 4 min to the BSCs affected by the earthquake that day and climbed to 4 up
to 7 min in the large-scale event. TCH Congestion time followed the same trend with lower rates, but in the
earthquake event did not decline from the usual rates. Therefore, only SDCCH encountered problems that day
and not traffic channels. Finally, occupation time of the SDCCH was analyzed and related to SDCCH Blocking
Rate, for all the above situations, on BSC level. The results show that the increase of the blocking rate is
followed by a respective increase of the occupation time, no matter what the channel is used for, no matter what
the situation is. The following diagrams show exactly this point, in two randomly chosen BSCs:
Figure 20: Occupation time vs. SDCCH BR (BSC_01)
Figure 21: Occupation time vs. SDCCH BR (BSC_01)

Though this chapter deals with the behavior of the network in a congestion situation, it is very interesting to see
the user’s/subscriber’s behavior in similar conditions. A new counter is created for this purpose by dividing the
counter AVE_BUSY_TCH (shows the traffic in Erlang) by the counter TCH_NORMAL_SEIZURE (shows the
number of successful calls). The results refer to network level, so there are small differences in BSC level,
depending on the area. A typical call in normal conditions is 10 up to 12 mErlang, that is 36 up to 47 sec,
depending on the hour of the day.
The day of a large-scale event (New Year’s Eve), call duration is reduced to an average of 21,6 sec, while in
almost every BSC duration varies from 20 to 30 sec. This fact could be explained by supposing that calls at this
exact event have mostly the purpose of exchanging wishes, so they are shortened anyway. One can also suppose
that users are familiar with the congestion problem, so they shorten their calls in purpose to help the network.
On the contrary, the day of the low-scale event, users tend to lengthen their calls. The measurements refer to
BSC level and especially to BSCs affected by the event (earthquake) and show call durations of 46 to 50 sec.
This could be explained by the fact that people were worried about the earthquake, so calls tended to be longer.
The result is graphically presented in Figure 22.
16
14
12
mErlang/call
10
0
1/1/2001
2/1/2001
3/1/2001
4/1/2001
5/1/2001
6/1/2001
7/1/2001
25/12/2000
26/12/2000
27/12/2000
28/12/2000
29/12/2000
30/12/2000
31/12/2000
Figure 22: Average mErl./call
Finally, after carefully processing and analyzing the operational data given and evaluating the results produced,
the most important conclusion is that the congestion problem affects a great part of the network, even if it is low-
scaled or locally placed. It cannot be limited to one network element or to one procedure, but, as shown above, it
causes problematic situations in the air and the Abis interface, in most of the logical channels used, in the call
setup and the handover procedures by a chain effect phenomenon. Though SDCCH encounters most problems,
not only in the air interface but in the Abis too, and should be carefully treated, the congestion problem should be
dynamically confronted in a way that solutions will apply to network level. The chapter that follows includes an
example that depicts the chain effect phenomenon and clarifies these conclusions.
3.3.2 Radio network performance in a congestion situation

In this document performance of the network is investigated, during a certain period of time. This period
includes a big event that affects all the Performance Key Indicators that took place in a certain BSC area and was
expected. It is a very good example of what is discussed in the above paragraphs. From the BSCs aspect is a

large-scale event, while the network considers it as low scale. The first part of the document examines the
influence of the event in the overall network level, while the second part focuses the report on the respective
BSC level. In both parts, the chain-effect phenomenon is clearly shown, while the most important event counters
are used to remark the network’s performance.
3.3.2.1 Network level

The big event that took place in the respective BSC area influenced the overall Key Performance Indicators in
network level. In particular, the SDCCH blocking value (Figure 23) increased from the usual level of 2.5% to
5.5% in network level. The main reason for this was the high traffic request in that BSC that measured SDCCH
blocking up to 25% in BH.
Figure 23: SDCCH Blocking Rate %
According to Figure 24, the overall SDCCH success ratio value presented small degradation on the day of the
event falling from the level of 94% to 93%. In particular, the increase of SDCCH drop call has been recognized
in the respective BSC. Actually, the SDCCH success rate was decreased from 94% to 67% on the above-
mentioned date in this BSC area. Analyzing the drop call causes for this signaling phase it has been found that
the dominant factor of this kind of performance degradation was the SDCCH Abis failure contributing almost
100% to the overall figuring of SDCCH success rate in the area.
Figure 24: SDCCH Success Ratio %

As it can be seen in Figure 25, two peaks of TCH call blocking have noticed during the period of time that was
look into. As far as the first date is concerned the problem was noticed in BSCs 1 and 2, other than the
aforementioned one and irrelevant to the event. Among others in BSC 1 a blocking value close to 8.5% was
measured being much higher that the normal values of less that 0.01%. Moreover, BSC 2 experienced a blocking
close to 6% also much higher that the normal values of 0.3%. In both BSCs an amount of high traffic request
was measured during that day.
Moreover, the TCH call blocking level presented a second peak "climbing" to 3.5% from the usual level of 0.4%
during the BH. The high blocking phenomenon were noticed in the respective BSC, that experienced a value
close to 24% during the BH as a result mainly of high traffic request. In addition, the appearance of high amount
of Transmission Failures in both BSCs is related to the blocking performance. Actually, this kind of TCH
failures mainly happened before the conversation started and from the user’s point of view, it was considered as
a failure during a call set up. Hence, the blocking value from the subscribers' point of view was even higher.
Figure 25: TCH Call Blocking %
In addition, the TCH drop call ratio (Figure 26) level appeared higher than the usual trend presenting a value
close to 1.75% on the critical date. The main reason for this increase was the appearance of high amount of
Transmission-Transcoder failures on this date that their share to the total number of Drops increased from 5% to
14%. The main BSC that experienced this phenomenon was again the one examined, that measured an overall
DCR value close to 3% much higher than the usual 1.5%. The reason for this degradation is the aforementioned
phenomenon of Transmission-Transcoder failures.
Figure 26: TCH Drop Call Rate %

It was observed that the overload conditions that lead to some specific TCH failures, as Abis and Transmission
failures, require deeper investigation by activating observation measurements for short periods of time during big
events in which high amount of traffic is requested. Finally, a degradation of HO performance was noticed on
that date presenting a HO failure ratio close to 20% being double than the usual value. The reason for this was
the congestion phenomenon effect of target cell during the HO process. In particular, 65% of the HO failures in
the network were due to this phenomenon on that date, while the usual value is 35%. This phenomenon appeared
to be very high in the BSC examined, arriving to 85% on the specific date. However, the overall HO
performance after this date is following the usual trend, approaching to 10%.
Figure 27: Total Handover Failure Ratio %
3.3.2.2 BSC Level

The whole analysis has been focused, only, on the cells of the respective BSC, which handled the increased
traffic volume of the event (30 cells). The high amount of traffic request in that area during the event caused
serious performance degradation of the network performance in the area. First of all the SDCCH blocking value
in the BH was more than 30% in the area (Figure 28). The reason for this high value of blocking was the high
amount of requested traffic.
Figure 28: SDCCH Blocking Chart

Moreover, the appearance of very high amount of SDCCH drop calls mainly because of the SDCCH Abis
failures has contributed to the more reservation time of the SDCCH channels affecting the overall resources
availability and increasing further the blocking. Especially, the SDCCH drop call ratio arrived to values close to
90% during the BH (Figure 29).
Figure 29: SDCCH Drop Call Ratio
The main reason for this increase of SDCCH drops came because of the amount of SDCCH Abis failures as
shown in Figure 30. The main reasons for the Abis failures appearance are first of all the heavy conditions in Air
interface concerning the UL and DL interference effect, but also some real Abis interface failures that could be
even caused by some overload phenomenon in this interface. However, the automatic retransmission feature in
SDCCH request phase improved this drop call ratio value from the subscribers’ point of view.
Figure 30: SDCCH Abis failures

In addition, the TCH call blocking was measured above 30% during the BH (Figure 31).
Figure 31: TCH Blocking – TCH call requests
Furthermore, the TCH drop call ratio value “climbed” to 5% being much higher than the usual value of less than
1%. This is shown in Figure 32, where it is mentionable that the drop call increases dramatically, after a very low
increase of the TCH seizures. This proves how the network responds after reaching a specific threshold in TCH
requests. This can be observed in all congestion situations, where the blocking probability and all other (chain-)
effects are increasing rapidly after a specific value.
Figure 32: Drop call rate according to the TCH seizures

The deeper analysis (Figure 33) has shown that the appearance of high amount of Transmission-Transcoder
failures caused this performance degradation. Actually, 70% of the total number of drop calls is coming from
this kind of failures during the BH.
Figure 33: Transmission-Transcoder failures

Finally, the HO success performance presented (Figure 34) a serious drop arriving to 40% while the regular
value is 85%. The main reason for this increase of HO failures is the congestion phenomenon to the target cell
that it can be easily explained by the overall overload of radio resources in the area.
Figure 34: Handover success performance

3.3.2.3 BTS level

In this subchapter, the study is extended to BTS level. In that way, the evaluation of operational data is
performed in a deeper level, reaching the fundamental network element: the cell. The situation analyzed consists
of an event that is considered as a high congestive one, on cell basis (though on network level is a low
congestive one or even not perceived by the network).
The event was a very popular football match (Panathinaikos – Juventus), held in a stadium of high capacity,
located inside an urban area. The area is mainly served by three cells (STADIUMA, B and C). The event
gathered about 70,000 people in the stadium. A rough estimation of the subscribers of the operator that provided
the data produces a figure of about 22,400 subscribers (it was estimated that 80% of the crowd had a mobile
phone and 40% of that 80% was subscribed to the respective operator). This figure shows exactly the extra load
that the three mentioned cells had to serve, in addition to the normal traffic served. The study is focused on the
most representative performance indicators: Call Setup Success Rate, Handover Success Rate, SDCCH Blocking
Rate, TCH Blocking Rate and Traffic, that are used in most of the situations presented in this chapter. Data is
analyzed not only for the date of the event, but for the day before and the day after, in order to perform a
comparison of the results. Table 1 includes all the data mentioned above (the Daily column refers to mean values
for the day).
Table 3: BTS statistics
SDCCH BL
CSSR (%) HOSR (%) TCH BL (%) Traffic (Erl)
Cell name Date (%)
Daily BH Daily BH Daily BH Daily BH Daily BH
STADIUM Day
92,9 100 95,8 100 0 0 0 0 0,222 1,626
A before
STADIUM Event
32,7 12,7 46,6 36,4 26,6 27,1 48,9 71,9 4,509 27,34
A day
STADIUM Day
96,1 98,2 66,8 60,7 0,29 0,31 0 0 0,172 3,417
A after
STADIUM Day
94,7 95,5 96,2 95,5 0 0 0,06 0,11 7,778 16,02
B before
STADIUM Event
91,3 68,7 84,5 66,1 0,58 0,91 3,51 18,8 9,413 25,33
B day
STADIUM Day
90,4 49,4 85,1 42,9 1,48 7,56 9,47 50,7 8,547 15,78
B after
STADIUM Day
96,1 97,4 97,1 97,4 0 0 0 0 1,668 4,244
C before
STADIUM Event
59,7 23,2 57,3 44,4 25,2 32,8 28,4 58,2 4,284 19,61
C day
STADIUM Day
88,2 61,4 75,3 43,9 6,02 12,3 12,6 32,1 1,794 10,63
C after
It should be noted that the situation started at 20.00 and lasted till 00.30 of the next day, as the coming and
leaving of the crowd is event started at 21.45, but the congestion included. That affected the definition of busy
hour of each day: the day of the event, the busy hour is defined at 20.00, while the day after, it is 00.00 (the first
hour of the day, that coincided with the leaving of the crowd). It also affected all the daily values for the next day
of the event, by significantly increasing them. The day before the event is not affected, so it sets the normal
values that the congestive ones will be compared to.
STADIUMA covers mostly the area of the stadium itself, as understood by the values of the indicators: actual
traffic is present only at event hours, CSSR degrades to 32% that day and nearly disappears (12%) at the event’s
peak (busy hour of the event day). Blocking and HOSR also present the same behavior. After the end of the
event, all indicators return to perfect values, except the HOSR, thus making it clear that the crowd is moving to
neighboring cells (actually leaving the stadium) and STADIUMA covers only the stadium itself.

STADIUMB covers mostly neighboring to the stadium areas, as increased blocking and call failures were
observed during the crowd’s leaving the stadium (measured in the day after values). The highest values of
blocking and failures appear the day after the event, thus making it obvious that STADIUMB covers areas
outside the stadium mostly. Even in that case, the situation is clearly better than the one encountered by
STADIUMA.
Finally, STADIUMC is between the two situations described above. It covers part of the stadium area and part of
the areas around it. In that way, it presents values below the average not only in the day of the event (especially
during the busy hour, values reach the lowest points), but also in the day after the event (where HOSR reaches its
lowest).
It is very interesting to estimate what is the loss for the operator, during such congestion situations, apart from
the subscribers not being satisfied. Estimating the extra traffic produced by the event in Erlang, an amount of
224 extra Erl is requested only in the busy hour of the event (22,400 extra users * 10 mErl/user at busy hour, as
estimated by the operator). Supposing that the event lasted at least four hours (but traffic was lower for the non-
busy hours), at least 600 extra Erl were requested during the event (optimistic estimation). The measurements
show that the three cells served about 200 Erl in maximum (also optimistic estimation). The result is that 400 Erl
were not served, thus were lost for the operator. Granted that 1 Erl is 60 min and 1 min costs about 0.3 Euro, it is
easily estimated that the loss for the operator reached the amount of 7.200 Euro for an event that lasted four
hours and was geographically limited in a stadium!
3.3.2.3.1 Umbrella cells

SDCCH Blocking
As it can be seen from Figure 35, on network level, the SDCCH blocking in Busy Hour arrived at the level of
5% on two certain dates. The overall trend of this performance indicator on network level is around 1.5 – 2%
during the normal period of traffic requests. However, this value can reach much higher levels close to 10%
excluding the special occasion of New Year’s Eve. Moreover, an interesting analysis result shows that more than
half of the SDCCH blocking, experienced in the NW, was coming from the umbrella cells. Especially, in
SDCCH request phase, the blocking is very critical, as there is no any directed retry feature available like it is in
TCH request phase. Hence, in areas where the dominant cell is very heavily congested, like most of the umbrella
cells, there is a possibility to be impossible any service provision to the subscribers.
Figure 35: Umbrella cell – SDCCH blocking
As it can be seen in Figure 36 (which is the sequence of the figure above), the BSCs that influence the overall
SDCCH blocking values are the BSC04 and BSC01 having umbrella cells and measuring high traffic request.
Actually, as it was seen above, the Umbrella cells present very high amount of blocking in high traffic hours.

Especially, the more detailed analysis on BSC level extracted the result that the reason for the blocking increase
is coming from the aforementioned umbrellas in these BSCs.
Figure 36: Umbrella cell – SDCCH blocking
In addition, some TRX unavailability problems could cause a dramatic increase of this kind of blocking even if
there is a usual amount of traffic request for a cell, because of the lack of the aforementioned Directed Retry
feature in this phase. Hence, due to the last phenomenon, the cells distribution that experience SDCCH blocking,
in an area, is not similar with the traffic one, in a lot of the cases. In Figure 37 the SDCCH blocking distribution,
on BSC level is presented for the analysis period. In this graph it can be seen that BSCs having Umbrella cells
presented the higher amount of blocking.
Figure 37: Blocking in BSCs with umbrella cells
Moreover, as it can be seen in Figure 38, the main reasons for an SDCCH drop call, are the Abis failure and radio
failure. Actually, from the total 6.2% of SDCCH drop call ratio the biggest amount, 4.5% is due to Abis failure
and almost the rest is radio failure, around 1.6%. However, for this phenomenon can be said, that it is not
considered as critical by the fact that the feature of retransmission in the SDCCH phase is performed
automatically, thus not being noticeable by the subscriber in most of the cases. In that way the possibility to have
an SDCCH failure after the last (forth) retransmission is very small.

Figure 38: Reasons for SDCCH call-drop
HO performance
In the next graph, the HO failure on network level, daily, is presented as well as the amount of HO failures due
to congestion to the target cell. It can be clearly seen that around 40% of the total HO failures, on network level,
are because of the lack of resources to the target cell.
Figure 39: Total HO failure – HO failure due to congestion to the target cell
Among BSCs with high amount of HO failure due to congestion of the target cell are mainly the ones having
umbrella cells. However, it should be mentioned that after a HO failure of this kind, in most of the cases there is
no drop call. Actually, wherever this kind of HO failure is appeared high, is a good indication to say that in the
specific area the network could be considered as capacity limited, supposing that no any TRX availability
problems have caused a decrease of available radio resources. On the other hand, when this failure is not high
comparing to other radio or even HW reasons could be said that the network in the area has somehow coverage
problems between the various cells, excluding again any possible HW failures that influence the overall
performance.
Finally, the calculation of the amount of HO failures because of the congestion in the target cell, very clearly
shows that the dominant factor in the HO performance is the appearance of this phenomenon, especially in
capacity limited areas.
3.3.2.3.2 Directed Retry performance

Directed retry performance was also affected by the heavy traffic conditions. During the busy hours because of
the congestion in the target cells the DR failure percentage increased even to 50% as can be seen in the graph
below.

Figure 40: Directed retry failure
One more interesting indicator for the evaluation of the area’s performance is the one that shows the percentage
of the non served requests that were not driven to a directed retry process and the percentage of non directed
retry, which are presented in the following graph. Usually a non-served request in the cell should be driven to a
DR attempt, apart if there is no neighbor cell with decent signal level. But in our case seems that this indicator is
following the traffic pattern, making the conclusion that the signaling overload causes some of the messages
concerning DR to be lost and no attempt to be made. The graph presents the data on hour basis, for the days that
lasted the event.
Figure 41: Directed retry attempts - failure

3.3.2.3.3 Paging performance

In the operator’s network there are two TMSI paging attempts, in the Location Area, being separated by 3
seconds each other. Actually, if after the first paging attempt there is no any answer from the BSS part in the
period of the 3 seconds, another paging attempt in the Location Area waiting for the same amount of time for
the BSS response, will take place. If this paging process also fails, the entire MSC area related to the VLR in
which the subscriber is present is paged. In this case, two times the MSC will try to search the MS inside the
whole area and again the time interval between the two searches has been set to 3 seconds. Finally, if no any
BSS response arrives to the MSC/VLR after the last search the counter fail_page is being triggered. If in these up
to four in total paging-search attempts a successful paging takes place, having the BSS response to the
MSC/VLR and the counter succ_page being triggered. Of course, the above-mentioned process stops after the
successful paging without continuing to up to four repagings-searches attempts.
Thus, the formula for the paging success rate is the following:
sum( succ _ page)

PagingSuccessRate = %
sum( fail _ page + succ _ page)
On the other hand, it should be mentioned that this formula does not give always the paging performance, as it is
perceived by the subscribers. In particular, sometimes after the paging failure of the search in the Location Area
the fail counter is triggered and for the same call at the end of the search of the whole MSC area again the failure
or the success counter is triggered depending on the result of the process. Hence, it seems that for one call two
updates of the counter fail_page or one update of the counter fail_page and one of the counter succ_page could
can take place. Of course in any case, the previous formula can certainly give an indication of how the paging
performance is going.
3.3.2.4 Other types of blocking

This part analyzes other types of channel blocking, especially during a congestion situation (where most
interfaces are overloaded), that influence the overall performance of the network.
3.3.2.4.1 Paging
First of all the mobile terminated calls (MTC) and the terminated SMS are considered. As the method selected
for paging the mobiles is the LA, the MSC will send to the BSC the message UDT (paging). If the LA includes
more than one BSC (not very common), the MSC will send this command to all the BSC under the same LA.
Afterwards, the BSC will distribute this paging to all of the BTS (normally the LA is the same for all of the BTS
under the same BSC) with the message Paging command. In the conditions where the traffic will be very big, the
number of paging message sent to all of the BTS will be also very big, even if the traffic is concentrated in some
of the BTSs. This is exactly what happened in the case investigated.
The operator is using the 16kbps link for the Abis interface. Based on vendor’s experience and measurements
made on the Abis link, the maximum average signaling traffic load should not exceed 8 kbps (1000 bytes/sec).
There is a risk of overflow if the load is more than 1200 bytes/sec. The 16kbps bit rate permits to handle about
100.000 pages/hr, which is sufficient for a normal BSC call model. Due to the great amount of subscriber
concentrated in the area, that model was useless to characterize the traffic conditions of the BSC examined.
Just a brief note to explain that from now on, Abis interface or Abis link, refers to the TRX-sig, because this carry
the information related with the BCCH, CCCH, measurements, etc. and it will be the principal link in suffering
the overload of the network.

Figure 42: Number of Paging Messages
It seems obvious looking the graph that the load was above that threshold between the 5pm and the 22pm. This
produced a blocking in the first part of the paging and, of course, overload in the Abis interface. As far as the air
interface is concerned, it is permitted to handle a paging capacity of 489600 pages/hr, much higher than the Abis
interface capacity. So in this case the bottleneck appeared in the Abis and not in the air interface.
3.3.2.4.2 RACH
In this point the blocking in the RACH will not be calculated, but the overload in the BSC BCSU CPU against
high RACH load. In the non-combined configuration the number of RACH defined is 51 and it should be high
enough to handle all the seizure attempts under one BTS. Hence the blocking itself won’t be in the RACH, but in
the capacity of the BSC to answer to all of the RACH retrieved by all of the BTS.
In the previous point it was mentioned that the big amount of paging command sent to the BTS, although not all
of them were served correctly. Even in these conditions of blocking in the paging, the number of paging request
the BTS will be able to send to the MS is very big (at least the nominal capacity, that, including the buffer in the
BTS, could be more than 125.000 pages/sec). Therefore, due to the traffic conditions of the area, the number of
RACH listened by the BTSs will be again quite big, because the mobile originated calls (MOC) can be added
and the originated SMS attempts to the previous MTC and terminated SMS. The channel required messages sent
to the BSC are equal to the number of this RACHs received by the BTS (there will be some lost due to radio
conditions). Apart of increasing the load in the TRX-sig, the number of channel required received by the BSC
should be proportionate to the traffic conditions of the event.
Then there is a protection in the BSC against this high RACH load, really in the BSCU CPU, which enables the
CPU to delete or omit some RACH (channel required). This can be calculated just subtracting the sum of the
number of immediate assignment, the immediate assignment rejected messages and the ghost reservation on
CCCH of the channel required messages received from the BTS. All of the channel required messages received
by the BSC should be answered with the messages that are subtracted from it, apart of the number of reservation
due to ghost. In other case the BSC would have omitted the RACHs due to overload in the BSCU CPU.

Figure 43: RACH access in different BSCs
Note that when the BSC sends the immediate assignment rejection to the MS, one of the reasons could be that
the Abis interface has no internal resources to handle the request. In this case, inside the message there will be a
message “wait indication” which defines the wait period for the MS.
3.3.2.4.3 SDCCH
If the network has been able to serve this channel required, the next step is to reserve one SDCCH. If there is no
SDCCH available (congestion), SDCCH Blocking will appear. This case has already been analyzed previously.
We have to underline that some of the SDCCH blocking is not real, because some of the SDCCH are reserved
for a MS, which will never use this channel. This can happen when the BSC reserves one SDCCH to the MS, but
some commands are missed in the Abis interface (effect emphasized in the high traffic conditions) due to
overload or due to the immediate assignment sent by the BTS is not received by the MS. This is one of the
reasons of the high value of the counter SDCCH Abis fail call (001075).
3.3.2.4.4 AGCH
Once the network has reserved one SDCCH to the MS, the BTS has to send to it the information of which
channel has reserved for it, the timing advance and if it is used or not frequency hopping. All this information is
sent in the message “immediate assignment”. It goes in the logical channel “AGCH”. Hence another possible
blocking in high traffic conditions could be the AGCH blocking.
In order to calculate the AGCH blocking, BSC measurements will be used. The BSC sends to the BTS the
immediate assignment or immediate assignment rejected commands. In the BTS it exists one AGCH buffer that
permits the BTS to store some of those commands coming from the BSC. In case the buffer is full, the BTS will
respond with a delete indication. Thus the ratio of delete indication to the sum of those commands describes the
blocking of AGCH.
If data related with these counters are uploaded from the NMS the formula is always null can be discovered. This
means the value of the delete indication message received by the BSC is null (checked), therefore the AGCH
blocking is null too.

3.3.2.4.4.1 AGCH blocking

Access Grant Channel Blocking can be calculated by using BSC measurements. The BSC sends to the BTS
immediate assignment or immediate assignment rejected commands. If the AG buffer in the BTS is full, it
responds with a delete indication. Thus the ratio of delete indications to the sum of imm.assign. and
imm.assgn.rej. describes the blocking of AGCH.
sum(del _ ind _ msg _ rec)

AGCHBlocking = %
sum(imm _ as sgn_ rej + imm _ as sgn_ sent )
To avoid an AGCH overload situation more capacity can be gained by increasing the BSC parameter AG (The
number of Blocks reserved for Access Grant). Vice versa this minimizes the paging capacity. Finally, it should
be mentioned that the blocking in AGCH is very rare and could happen only in very heavy load situations.

3.4 HSCSD / GPRS statistical evaluation

Within the scope of WP2 and the statistical analysis of the network, HSCSD and GPRS measurements and
evaluation has been performed. The results are restricted to measurements performed in an urban city and not
averaged over the whole network. On the other hand, the measurements have shown problems and limitations of
these technologies, as well as their performance. Before presenting the results, it is important to give new
definitions about congestion in packet switch data.
3.4.1 Congestion definition in packet switched data

New technologies emerging in the scene of mobile cellular networks, and especially GPRS, elevate the
transmission speeds into a higher level and seem to offer to the subscribers new potentials and services, based on
these speeds. Alongside to the advantages of GPRS also come certain constraints about the extra load on
network and resources that will be required and its behavior in congestion situations. The analysis of GSM
congestion showed that the problem is located mostly in certain channels (SDCCH and TCH) of the air
interface, and on RACH and PCH messages, but in the Abis part of the network. By introducing GPRS,
congestion in the respective protocol must be defined. Three different situations in GPRS’ procedures can be
defined as congestive. It should be noted that all situations occur after the initiation of the service, meaning that
GPRS attach and PDP context establishment have successfully taken place.
The first one refers to the availability of logical channels that GPRS introduces to the GSM air interface and it is
similar to the congestion that is described for typical GSM networks. The lack of resources on PRACH (Packet
RACH), PPCH (Packet PCH), PAGCH (Packet AGCH), PACCH (Packet Associated CCH) and, of course, on
PDTCH (Packet Data TCH) ends up to congestion and service unavailability, exactly like in normal GSM. The
difference between normal GSM and GPRS is that GPRS can also use some normal GSM channels for the
messages, in a case of GPRS’ resources unavailability. The normal RACH can be used instead of PRACH, the
normal PCH can be used instead of PPCH and the normal AGCH can be used instead of PAGCH, in order to
transmit the respective messages of each channel, in case of congestion in the GPRS channels.
It is very important to remark that Circuit Switched (CS) traffic has priority over Packet Switched (PS) traffic. If
congestion occurs for CS traffic, then only dedicated GPRS traffic channels can carry PS traffic. The default
GPRS capacity determines a number of traffic channels that are always switched to the PCU (in the BSC), when
allowed by the CS traffic load. Using these TCHs, the operator can provide fast GPRS channel reservations for
the first data packets. During peak GPRS traffic periods, additional channels are switched to GPRS use, but only
if the CS traffic load permits that to occur.
A second situation that can be defined as congestion has to do with the data speed that is provided by the
network to the subscribers. If the usual speeds of 40 – 50 kbps (that operators claim as reachable) fall to 10 kbps
or even below the normal GSM data speed, then this is congestion. The problem is mostly in the unavailability of
the number of PDTCHs that are required to reach these speeds. An interesting optional feature of GPRS, called
two phase access, can be applied in this situation for the improvement of the uplink resources’ allocation, but the
cost in the overall performance is to be discussed. The two-phase access is initiated by the MS, when it is not
satisfied with the uplink resources allocated to it. It sends a Packet Resource Request message that is used to
carry the complete description of the requested resources for the uplink transfer. The network’s response is a
Packet Resource Assignment message, indicating the resources reserved for uplink transfer. Power Control and
Timing Advance information are included in this message. Both messages are realized on a PAACH.
The third situation is related to the fact that the IP based service presents remarkable delays, from the
subscriber’s point of view. The interpretation of delay as congestion in the respective protocol is acceptable, as
GPRS concerns high-speed data transmission for applications dependable on that speed. If the delay is
perceivable by the subscriber, then it is classified as congestion. Technically, the problem is initiated either by
the transmission of the Ack./Nack. messages after a certain number of data blocks that hold up the speed of the

whole procedure, or/and by the limitations of the air interface itself that cuts the IP packets into the admissible
GSM bursts, thus delaying the procedure.
Concluding, it should be noted that only the analysis of real operator’s data of GPRS application could provide
the means of overcoming the problems described above. In that way, assumptions will become certainties,
definition of congestion more accurate and the performance of GPRS over GSM will be measured and depicted.
3.4.2 GPRS/ HSCSD Measurements

The measurements took place between the 14 and 21 June 2001, and the focus was on the Data Throughput and
the Response Time (Delay). The first one defines the applicability of the system data transfer for both
technologies, GPRS and HSCSD and the second one evaluates the time difference between the sending and
receiving.
3.4.2.1 Equipment
3.4.2.1.1 Software
Based on the system architecture, where is asymmetry in the connection, the DL (downlink) was measured and
evaluated in terms of Data Throughput. The Web service Tucows by the ISP_1 was used as an application to
download packets from Internet and the program Dial-Up Networking Monitor v2.1a for was used for
monitoring. Moreover, for the Time Delay, the program CyberKit v2.5 was used again for both technologies.
3.4.2.1.2 Hardware
For the measurements reports the following devices were used:
• Motorola Timeport 260 (GPRS - CSD)
• Nokia 6210 (HSCSD)
• Magellan 4000 XL (GPS)
• Compaq – Toshiba (Notebooks) & Desktop PCs
3.4.2.2 GPRS Data Throughput corresponding with the RX level and the
C/I ratio
There are four different of Coding Schemes that are used in GPRS service where, each one offers different data
throughput. The theoretical throughput for each CS (Coding Scheme) is shown in Table 4.
Table 4: Coding Shemes and Data Throughput
Coding Scheme Data

Throughput
CS-1 9.05 kbps
CS-2 13.4 kbps
CS-3 15.6 kbps
CS-4 21.4 kbps

Each coding scheme requires particular Carrier-to-Noise (C/N) ratio for a given Block Error Rate. In Table 5,
assuming block rate less than 10% and frequency hopping without RX diversity, for Nokia Base station (Talk
Family), required C/N, BTS sensitivity, body loss and link budget are indicated for each coding-scheme.
Table 5: Carrier-to-Noise (C/N) ratio for each coding scheme
Service Speech CS – 1 CS - 2 CS - 3 CS - 4
Required
6.0 dB 6.2 dB 9.8 dB 12.0 dB 19.3 dB
C/N
BTS
-108 dBm -107.8 dBm -104.1 dBm -102.4 dBm -94.7 dBm
Sensitivity
Body loss 3dB 0dB 0dB 0dB 0dB
Link budget
difference
related to
- +2.8 dB -0.8 dB -3.0 dB -10.3 dB
Talk family
Speech
Service
It is possible to understand that CS-1 and CS-2 have the same requirements of RX level when call service in
used. Actually, CS-1 leads when call service is used, and that is based on the body loss by 3dB. Therefore, the
coverage is enough for both CS-1 and CS-2 that the operator is using, especially in densely populated areas
where the coverage is compact.
More emphasis should be given in the above-described areas, the contribution of the C/I (Carrier to Interference)
ratio. Depending on the value of the C/I then the theoretical data throughput is changed in every CS. For
example the automatic change from CS-1 to CS-2 usage is triggered when the C/I increases from 6dB to 7dB.
Figure 44 shows the data throughput in connection with C/I ratio.
25
20
User Data Throughput (Kbit/s)
15
10
CS - 1
5
CS - 2
CS - 3
CS - 4
0
4 6 8 10 12 14 16 18 20 22 24 26 28 30
C / I ( dB )
Figure 44: User data throughput – C/I ratio

To investigate the effect of the RX level to the data throughput, certain trials were undertaken. Close to BTS01,
where the RX level was –97dBm, the observation was that the throughput over GPRS was 29.4kbps. Comparing
with the measurements in the same cell where the RX level was –63dBm and –45dBm, there is a slight drop at
the throughput 33.2 and 30.4-31.2 respectively. Generally, in all the measurements in the same cell, the
throughput was about 30 kbps thus it is obvious that CS-2 was used. Emphasis should be given that Motorola
T260 is using multislot 3+1.
Figure 45: GPRS -97dbm
Continuing, the measurements were focused at BTS05 over GPRS. Close to the cell where the RX level was –40
dBm (too close to the microcell) the data throughput was 32 kbps, hence 32kbps/ 3TSLs = 10.7kbps/TSL, and
that means that CS-2 was used. Running away from the microcell, and just before the reselection would take
place with an umbrella cell, about 20 seconds before, the coding scheme changed from CS-2 to CS-1 and the
throughput dropped at 18 kbps (see Figure 46). In addition, close to the antenna, the C/I ratio is higher
comparing to the borders of the cell, therefore is normal that the Coding Scheme changed to CS-1 in the margins
of the microcell.
Figure 46: BTS05 until reselection in umbrella cell
Concluded, after the measurements over GPRS that there are two “categories” of data throughput. The first one
is between 30-32 kbps and the second one 20-22 kbps. Consequently, this observation is function of the different
C/I ratios from area to area, resulting the triggering of the Coding Scheme 1 when the C/I ratio is not sufficient.
3.4.2.3 Data throughput

Table 6 shows the observation that took place for each BTS, geographical coordinates, the RX level (in dBm),
and of course the time of the throughput that have been accomplished with GPRS and HSCSD.

Table 6: Data throughput
RX Coordinates Date GPRS HSCSD

MSC BSC BTS Cell ID Channel
Level Time Kbps Kbps
37 57.693N 26/6/01
MSC02 BSC04 BTS01 xxxx 844 -75 20.0 22.8
23 37.315E 22:00
37 57.693N 26/6/01
MSC02 BSC04 BTS02 xxxx 798 -78 21.2
23 37.315E 22:10
37 57.505N 27/6/01
MSC02 BSC04 BTS03 xxxx 830 -50 20.0
23 36.892E 21:45
xxxx 37 56.839N 27/6/01
MSC02 BSC04 BTS04 774 -55 20.0
23 37.370E 21:25
xxxx 37 58.491N 27/6/01
MSC02 BSC01 BTS05 858 -40 32.0
23 39.336E 22:24
xxxx 37 57.510N 28/6/01
MSC03 BSC01 BTS06 808 -63 30.4
23 45.690E 1:32
xxxx 37 57.510N 28/6/01
MSC03 BSC01 BTS06 808 -63 31.2
23 45.690E 12:00
xxxx 37 57.510N 28/6/01
MSC03 BSC01 BTS06 808 -63 30.4
23 45.690E 13:10
xxxx 37 57.510N 28/6/01
MSC03 BSC01 BTS06 808 -97 29.4
23 45.690E 17:35
xxxx 37 57.712N 29/6/01
MSC03 BSC01 BTS07 792 -75 21.4 23.0
23 45.700E 21.45
xxxx 37 57.414N 29/6/01
MSC03 BSC01 BTS06 808 -45 33.2 24.0
23 45.870E 21:30
xxxx 37 57.175N 29/6/01
MSC01 BSC03 BTS08 866 -48 21.6
23 45.588E 22:30
xxxx 37 57.165N 29/6/01
MSC01 BSC03 BTS09 796 -60 32.0
23 45.578E 22:35
Therefore more observation went on in the first BTS from the above table and the following figures show the
corresponding results.
Figure 47: GPRS performance (Motorola T260)
Figure 48: HSCSD performance (Nokia 6210)

Figure 49: WEB browsing (LAP-M 28800)
Figure 50: WEB browsing (LAP-M 28800)
3.4.2.3.1 GPRS
Taking from the above graphs that the GPRS system has ups and downs in the throughput. This can be explained
as the GPRS uses packet switch connection, thus the instant throughput depends accordingly to the traffic at the
packet Switching Nodes (PSNs) of the network. Moreover, according to the blocking probability, packets can
pass through up to 3 TSL at the same time (MT Motorola) and the average throughput in the case of the first
BTS of the above table was about 20kbps.
3.4.2.3.2 HSCSD
High Speed connection seems to have constant throughput. Therefore, can be explained as HSCSD is based on
circuit switch, since the connection is established then the corresponding traffic channels are dedicated. To
eliminate as far as it is possible the Packet Switch part of the Internet connection in the trials, the file was
downloaded from a local server by an ISP. Thus the average throughput again in the case of the first BTS, with
HSCSD, was about 22.8kbps.
On the other hand, comparison was made between a normal Dial-Up connection and the HSCSD connection and
the result was that both connections had the same instant throughput. After that, another trial was made where
the goal was to download from a far away Tucows mirror site with 14 IP routers between, hence the Packet
Switch part will be dominant in the connection. The outcome was that the instant throughput was close enough
with the one of the GPRS.

Figure 51: HSCSD performance
Figure 52: HSCSD performance
Figure 53: BTS01 with numerous idle conditions
Figure 54: 2bar-97dbm
Figure 55: GPRSMIC

Figure 56: HSCSD BTS02
Figure 57: HSCSD BTS02
3.4.2.4 Response Time (Delay)

To understand the produced delay in a GPRS network and also in the HSCSD service, the trials was
implemented by sending packets of 64 bytes into different targets/places inside and outside the country and
waiting the answer (ping). The measurements are as follow, using Nokia 6210 (connected with infrared to PC):
Table 7: Response time (GPRS)

GPRS BTS01 xxxx BTS02 xxxx BTS04 xxxx BTS03 xxxx
min/avg/max 26/6/01 22:00 27/6/01 12:40 27/6/01 21:25 27/6/01 21:25
(ms)
www.otenet.gr 831/904/1351 831/913/1244 862/922/1326 814/905/1355
www.ntua.gr 793/902/1269 795/892/1269 859/928/1332 810/896/1273
www.yahoo.com 895/978/1321 911/1073/1746 885/942/996 889/979/1338
www.mit.edu 891/1073/1757 905/998/1415 903/996/1357

GPRS BTS05 xxxx BTS06 xxxx BTS06 xxxx BTS06 xxxx
min/avg/max 27/6/01 22:24 28/6/01 1:32 28/6/01 12:00 28/6/01 13:10
(ms)
www.otenet.gr 830/924/1332 810/894/1251 802/875/1051 828/967/1402
www.ntua.gr 841/992/1565 802/889/1247 833/906/1020 799/944/1339
www.yahoo.com 873/960/1296 906/1078/1709 860/983/1274 908/1037/1393
www.mit.edu 914/984/1395 902/983/1386 896/994/1380

Table 9: Response time (HSCSD)

HSCSD BTS01 xxxx BTS05 xxxx BTS06 xxxx
min/avg/max (ms) 27/6/01 20:30 27/6/01 22:30 29/6/01 21:30
www.otenet.gr 924/1199/1273 925/1214/1332 1257/1280/1383
www.ntua.gr 760/1130/1308 1246/1262/1283 1248/1318/1780
www.yahoo.com 940/1301/1778 1251/1283/1394 1431/1794/2300
www.mit.edu 1256/1271/1285 1251/1286/1512 1258/1331/1792
The results is high delay in the packets thus in GPRS as well as in HSCSD. The same trial took place by using
this time the Motorola mobile and the observations were both with infrared and serial cable connected to PC,
using GPRS and CSD (Circuit Switched Data). The results are shown in the next tables:
Table 10: Response time (CSD)

CSD BTS06 xxxx CABLE IRDA
2/7/01 21:00 min/avg/max (ms) min/avg/max (ms)
www.otenet.gr 878/901/987 1110/1425/1581
www.ntua.gr 891/909/945 1125/1454/1655
www.yahoo.com 1115/1180/1278 1133/1437/1988
www.mit.edu 1050/1139/1200 1130/1465/1801

GPRS BTS09 xxxx CABLE IRDA
www.otenet.gr 845/1037/2056 1084/1360/1653
www.ntua.gr 848/934/1033 1071/1352/1552
www.yahoo.com 902/978/1360 1061/1240/1737
www.mit.edu 896/998/1367 1053/1348/2061

GPRS BTS01 xxxx CABLE IRDA
www.otenet.gr 848/879/905 1081/1462/1715
www.ntua.gr 807/889/970 1086/1472/1631
www.yahoo.com 980/1065/1385 1055/1412/2050
www.mit.edu 922/960/1045 1068/1419/1598
The derived conclusion from the above measurements, using Nokia’s and Motorola’s mobiles, points the fact
that an extra delay is inserted of 415ms. Therefore, without the extra delay the average delays are as follow:
Table 13: Average response time GPRS/HSCSD

HSCSD HSCSD
Average Round Trip Time (ms) GPRS
(IrDA) (cable)
Inside country 916 1234 819
Outside country 1004 1294 879
In comparison with a simple dial-up connection using the PSTN network with ISP_1 the followed results are
shown:

Table 14: Analogue Connection (LAP-M)
Dialup 28800 LAP-M min/avg/max

26/6/01 22:00 (ms)
http://www.otenet.gr/ 129/156/207
http://www.ntua.gr/ 131/145/165
http://www.yahoo.com/ 305/319/366
http://www.mit.edu/ 290/306/371
Based on the fact that the above values are representative and comparing with the time delays extracted from the
cellular network, the GPRS inserts an extra delay of 700 to 750 ms corresponding to the wired PSTN network.
This is normal as an extra network (Switch Packet), is added.
In addition, HSDCH service adds an extra delay between 600 and 650 ms comparing to the PSTN network.
3.4.2.5 Handover success

Even if handover is not a procedure in GPRS the results are: The goal was to download a file and at the same
time moving into different cells. Whenever these cells were part of the same BTS, the time to regain the
download was about 8 seconds. On the other hand, whenever two cells were parts of different BTSs but also in
different BSC and MSC, the time was increased to 33 seconds. In addition, when two cells were in different BTS
but in the same BSC, the time to regain was about 5 minutes, and the only way to continue the download was to
de-attach and then attach again to the GPRS network
Nevertheless, in the case of the reselection was occuring when the GPRS Mobile was in standby condition and
bandwidth was requested after the reselection then the connection would be successful; e.g. when download a
web page, only a part is readable and by then scrolling down the other parts is requested.
As far as the Circuit Switch Data (CSD) the trials showed that the network does not support CSD even when
cells were in the same BTS (intra-BTS handover). The trials took place by using NOKIA 6210 with multislot
connection 3-1 (43.2-14.4 kbit/s) and also singleslot 1-1 (14.4-14.4 kbit/s) as well as with MOTOROLA
Timeport 260 with connection singleslot 1-1 (9.6-9.6 kbit/s).
3.4.2.6 WAP with GPRS/CSD

The WAP (Wireless Application Protocol) was used with GPRS and CSD. The conclusions are that the GRPS
supports faster access to the pages than the CSD. For the reason that GPRS uses multislot allocation with 3
RTSLs downlink comparing to the CSD that uses single slot allocation up to 14.4 kbit/s even when NOKIA
6210 was used, which supports HSCSD.
Time connection using GPRS was limited to 5 seconds comparing to the 25 seconds that were needed to restore
the circuit (CSD). Moreover, the idle time e.g. the waiting time to read wml pages, the CSD charges that time,
where in GPRS the charge corresponds to the download demanded capacity.

4 TRAFFIC-LOAD SCENARIOS AND TRAFFIC MODELING
This chapter provides a classification of congestion situations that has been observed after the statistical
evaluation, described in the previous chapter. An extensive traffic modeling is also included for cellular systems
of present and future generation. Since the chapter is also related with signaling procedures and signaling
channels, there is a description of logical channels in GSM summarized in Appendix 3. It is important to
mention that the detailed description of Traffic-load scenarios will be given in deliverable D-3.3, according to
the Technical Annex of the CAUTION project. In this chapter a classification of traffic-load scenarios, from the
view of the operators, and according to measurements will be given.
4.1 Traffic load scenarios

This section of the document describes the relevant scenarios for the CAUTION project, namely those scenarios
that can be classified as congestion situations. The relevant scenarios are characterized by “overload conditions”,
where overload is to be intended with respect to the average situation. Indeed, a potential congestion scenario
usually considers either situations in which a large number of people is concentrated in a delimited location or a
situation that induce many users to call at the same time.
The reasons and the consequences of a congestion situation may be of variety of types, ranging from the periodic
overload peak of a daily busy hour to the unpredictable occurrence of a catastrophic large-scale event. In the
following a set of overload scenarios is listed, which cover this wide range of possibilities, and that can be used
as a checklist for matching the data monitored through the ITMU with some congestion avoidance/tolerance
techniques in the RMU.
Scenarios have been first characterized on a phenomenological basis, and then have been compared against a set
of predictability criteria that will help in defining a scenario identification procedure. The identified scenarios
will be classified in terms of time, traffic, and location predictability. A given scenario will be considered time
and location predictable if the time and the location of the event represented by the scenario is known in
advance, while the scenario will be considered as traffic predictable if the expected traffic can be estimated,
based on data collected in previous similar events.
The set of overload situations identified are then described in terms of observability of the congestion
appearance and of the consequent effects. This scenario characterization will represent a relevant piece of the
information the RMU algorithm will be built upon.
4.1.1 Busy hours

In a telecommunications system what is called busy hour is the sliding 60-minute period during which the
maximum total traffic load in a given 24-hour period occurs. The busy hour is determined by fitting a horizontal
line segment equivalent to one hour under the traffic load curve about the peak load point. Busy hour can occur
more than once in a day.
One of the defining characteristics of wireless networks is that their capacity has been dimensioned in order to
satisfy the day average traffic load, and not to waste resources that wouldn’t be used for most of the time.
However, in particular moments of the day the traffic levels can be much higher than the average, thus probably
causing congestion. For example, this is a situation that occurs in business days more or less in the same way in
urban areas near business centers (more than one adjacent cell can be involved). Also during weekends, different
busy hours can be observed for reasons other than work (e.g. leisure time). In this case, the overloaded cells can
be located in the whole territory.

Since busy hours congestion is a periodical situation, appropriate traffic load curves have been estimated (the
typical behavior shows two peaks of traffic during the business day). This way the congestion due to busy hours
phenomenon can be faced exploiting previous measures.
4.1.2 Predictability
The predictability is classified in time-, traffic- and location-predictability. A short description of each of these
categories is included in the following sub-sections.
4.1.2.1 Time predictability

The time occurrence of busy hours is predictable with a good confidence degree, since it is a regularly occurring
event and many statistical data on the corresponding traffic trend are available, based on daily measurements.
4.1.2.2 Traffic predictability

The traffic overload in busy hours is predictable since it is a phenomenon observed periodically and
measurements are available for it.
4.1.2.3 Location predictability

The areas in which weekdays busy hours are observed are usually known in advance. In particular, they
correspond to urban business areas where a number of offices, banks, and shops are located (possibly more than
one adjacent cell). On the contrary, during weekend days, the busy hours are not related to specific locations
with a high concentration of people, but rather refer to preferred hours in which people tend to get in touch.
4.1.3 Observability
Observability mainly consists of the following three parameters: channels subject to congestion, duration of
congestion and types of traffic. A short description of each parameter is provided in the following sub-chapters.
4.1.3.1 Channels subject to congestion

This section will provide information related to the logical channels that are affected from a congestion situation.
Important is the identification of the logical channels that reach utilization over 80%.
4.1.3.2 Duration of congestion

What is the duration of the congestion event? Is it the consistently the same during the week?
4.1.3.3 Types of traffic

Provide a breakdown of the traffic as measured during the congestion event, by filling in the following table:
Voice SMS MM Data

Relative traffic %

4.1.4 Tourist periods

We consider tourist periods those long vacation periods in which a considerable amount of people uses to leave
for holidays resorts (sea sides, mountains, lakes, islands, et cetera). This migration can cause congestion
problems in those localities: typically the wireless network has been dimensioned in order to satisfy the average
traffic load generated by the locals, which generally are much less than holiday people. For each holiday resort,
specific high season periods can be individuated, during which an increase of the overall traffic rate can be
observed, that can cause congestion in particular busy hours. Even if the number of tourists in a given location
can vary over the years in a rather unpredictable way, the traffic overload can be estimated to a certain extent on
the basis of previous statistical data.
4.1.4.1 Predictability
4.1.4.1.1 Time predictability

The tourist periods are predictable with a nearly good precision, since the months in which people go on holiday
are more or less the same over the years. The last tourist trends indicate that holidays periods are more
distributed than before in the course of the year, but the periods of major tourist flow are always the traditional
ones (for example, July/August for summer holidays, and December/January/February during winter).
4.1.4.1.2 Traffic predictability

The number of persons reaching a holiday resort is predictable to a certain extent on the basis of previous years’
statistical data. However, the estimation’s accuracy could be not very high, because of the annual variations in
tourist flows. These variations depend on tourist trends, environmental conditions of holiday resorts (e.g. level of
sea pollution) and economical/financial factors. For example, many foreigner tourists choose to spend their
holidays in a given resort when the local currency is low.
4.1.4.1.3 Location predictability

Traffic congestion during tourist periods can be observed in holidays resorts usually known in advance. They are
typically the most famous seaside and mountains locations, and towns of cultural and artistic interest.
4.1.5 Bank holidays

We consider bank holidays those public holidays such as New Year first day, Easter and Christmas. In these
particular days of the year people use to give best wishes to relatives and friends causing a huge growth of the
traffic load in a relatively short period of time. Besides, since most of these days are vacation days, a
considerable amount of people uses to leave for holiday resorts; consequently in those places there are two
increasing load factors at the same time. The most critical situation caused by this kind of phenomenon takes
place in holiday resorts during the minutes around the midnight of the last day of the year.

The date of the bank holidays is known in advance. Moreover, particularly overloaded traffic times are
predictable with a nearly good precision from previous statistical data (e.g. the minutes around midnight in New
Year’s Eve).


The traffic overload is quite predictable, thanks to the previously collected data. In particular, a higher traffic
overload can be observed in holiday resorts. The most critical situation is observed in the minutes around
midnight in New Year’s Eve, when people calls relatives and friends to give best wishes. In this case, the traffic
is so high that the network will very unlikely be able to satisfy all the calls: however, some resource management
techniques can be adopted to satisfy as many calls as possible.

Even if holiday resorts are more critical for potential traffic congestion, the increase of traffic load during Bank
Holidays can be observed everywhere.
4.1.6 Sport events

During sport events a large/medium number of persons are concentrated in a delimited location; those cells
containing the spaces in which sport events take place (stadiums, arenas, motor racing tracks…) pass from the
average concentration of users to a much higher amount of users that can become call attempting users for a
period of about 2-3 hours, depending on the duration of the sport event. A serious congestion danger is the fact
that many of those users may try to call in the same time when something particular happens during the sport
event.

The date and time of the sport event are known in advance. For the whole duration of the event, the area in
which the sport event takes place can be considered risky for potential traffic congestion. A peak can be
observed when something particular happens (e.g. a goal in a football match).

The traffic is quite predictable: data previously collected in similar events can be used to estimate the traffic
overload. Another useful indication is the estimated number of people present (e.g. number of tickets sold).

The area where the sport event takes place is restricted and known in advance. Usually it corresponds to one cell.
4.1.7 Traveling services strikes

The traveling services strikes can cause the growth of users concentration in places like railway stations or
airports. Even if strikes should be announced days before they happen, usually a large amount of people is
unaware of them or is aware but have the necessity to leave anyway. This is a potential congestion situation
because the number of people in those places is going to increase as time goes by, until traveling services
become finally available. Typically all those people whose planned travel has been cancelled or suspended will

use the phone in order to inform persons waiting for them that they aren’t arriving on time, and to find a solution
like backup travel services.

The date and time of traveling services strikes are known in advance, because they must be broadcasted. Traffic
congestion can occur during the whole established duration of the strike.

The traffic is predictable to a certain extent if data has been collected in similar events. The variability of the
traffic load depends on the number of persons who agree with the strike, and consequently on the troubles
created.

The location of the event is restricted to specific areas (e.g. airports in case of airlines strike, railway stations in
case of railway men strike) and is known since the strike is broadcasted.
4.1.8 Religious/cultural events

Cultural events like theatre performances, movies, concerts, discos, and religious events cause a concentration of
people in specific locations. In those occasions a medium/large amount of people use mobile phones mostly to
call friends and relatives. The cells containing the spaces where the events take place (squares, stadiums,
cinemas, …) pass from the average concentration of users to a much higher amount of users that attempt to call
before and after the event.

The date and time of religious/cultural events are known in advance. People usually use the mobile before the
event, while waiting for it, and after the event, to look for other people or to talk about the event. During the
event, on the contrary, the number of performed calls is usually low.

The traffic is quite predictable: data previously collected in similar events can be used to estimate the traffic
overload. Another useful indication is the estimated number of people present (e.g. number of tickets sold for a
concert).

The location of the event is restricted to specific areas (e.g. stadiums, squares, theaters) and is known in advance.

4.1.9 Demonstrations
Demonstrations for political, social, trade union reasons are potential congestion situations. In this case, a
large/medium number of persons are moving along a planned way, typically involving one or more adjacent
cells. The traffic overload depends mostly on the concentration of users and also partially on the participants
need to communicate and exchange information about the demonstration progress.
The date and time of the demonstrations are known in advance, because they must be announced. Traffic
congestion can occur during the whole established duration of the demonstration.

The traffic is predictable to a certain extent if data has been collected in similar events. The variability of the
traffic load depends on the number of persons who participate to the demonstration.

The location of the demonstration is known in advance since authorities must approve the planned way for the
demonstration.
4.1.10 Department stores

Department stores grouping shops of different kinds attract all over the year a high concentration of people,
particularly in given busy hours or sales periods. In these situations, due to the huge number of people restricted
in a delimited area, a traffic congestion can be observed, both incoming and outgoing calls. The traffic overload
can be estimated on the basis of measurements collected by the specific cell(s) the department store is situated in.

In general, department stores have specific data on the hours of major concentration of customers. Anyway, the
data previously collected in the cell(s) the department store is located in can be used to estimate the busy hours.

The traffic overload is quite predictable, by using the daily measurements collected by the cell(s) the department
store is situated in. From these data, specific busy hours can also be individuated.

In this scenario, the traffic overload is observed in a restricted area, corresponding to the specific cell(s) the
department store is situated in, and is of course known in advance.

4.1.11 Planned outages

In case of a planned outage for repairing the network, the service in the corresponding cell(s) is either
unavailable or limited. The traffic trend is the usual one, but because of the outage a certain number of users are
redirected in the adjacent cells, causing a traffic overload in those areas. The location and duration of the outage
are known in advance. The number of users that are redirected in the adjacent cells can usually be estimated on
the basis of statistical data.

The date, time and duration of the network unit repair are known in advance.

The traffic overload in the adjacent areas is predictable, by knowing the normal traffic in the area under outage.

The location of the outage (and the adjacent areas where the traffic overload takes place) is known in advance.
4.1.12 BTS shortcoming

In case of BTS or BTS link shortcoming, users are redirected to the nearest BTSs, where the traffic overload
situation takes place consequently. The location, time and duration of the shortcoming is not known in advance.
The traffic overload can be estimated to a certain extent on the basis of the average number of users of the cell
corresponding to the damaged BTS.

The time of the event is totally unpredictable.

The traffic overload in the nearest BTSs is predictable, by knowing the normal traffic in the damaged area.

The location of the event is not known in advance.

4.1.13 BSC shortcoming

BSCs can have different dimensions and topologies (depending on the operator’s choices). In case of a BSC or a
BSC link shortcoming, some areas inside the BSC coverage could remain isolated. In a BSC having a star
topology, users located at the edges of the BSC coverage area are redirected to the nearest BSCs; otherwise their
calls are not satisfied. The location, time and duration of the shortcoming is not known in advance. The traffic
overload can be estimated to a certain extent on the basis of the average number of users at the edges of the area
related to the damaged BSC.

The time of the event is totally unpredictable.

The traffic overload is predictable, by knowing the normal traffic in the damaged area.

The location of the event is not known in advance.
4.1.14 Catastrophes
After small/medium/large catastrophes like earthquakes, floods, volcanic eruptions, ecological disasters, an
increase of the traffic load is usually observed, due to emergency calls or simply calls to inquire after the safety
and health of relatives and friends. In case of a small scale catastrophe, usually the traffic is limited to an
exchange of information about safety and health state of people. On the contrary, in catastrophes of a relevant
dimension, at first the traffic overload consists mostly in outgoing calls (particularly emergency calls), then, after
the event has been broadcasted by the mass media, it consists in both incoming and outgoing calls. In this last
case, also damages in the network could worsen the traffic status.

In general, the time of the catastrophe event is not known in advance. Sometimes experts can estimate with a
little advance the time the event happens (for example, for floods or volcanic eruptions), and some dangerous
areas are declared on the alert for many hours (if needed, people can also be evacuated).

The traffic is not predictable. Some very rough statistical estimation can be made on the basis of the data
collected in previous similar events.


In general, the location of the event is not known in advance. Sometimes (e.g. for flood) the location is known a
little time before the event happens.
4.1.15 Accidents
The accident scenario accounts for road accidents and queues, acts of terrorism and so on. When the accident
happens, involved people call not only emergency numbers, but also relatives and friends to inform about the
happening. The traffic overload consists mostly in outgoing calls. At first the event is delimited in a restricted
area, but can quickly spread out in adjacent areas – for example, a road accident can block the traffic for many
hours, causing queues and slowing down.

The time of the event is not known in advance.

The traffic is not predictable. Some very rough statistical estimation can be made on the basis of the data
collected in previous similar events.

The location of the event is not known in advance. After a large scale accident takes place, what can be predicted
is that also the adjacent cells will be affected by troubles in the traffic.
4.1.16 Any other congestion scenario

In case of a traffic congestion situation that cannot be classified with a certain degree of confidence in any of the
previously described scenarios, strategies based only on quantitative data are adopted, depending on the
observed traffic overload parameters.
4.1.17 Conclusions
In the previous sections, a classification of the traffic load scenarios was given. This is important in order to
understand the kind of congestion and additionally to take the correct decisions for capacity management
techniques. All above situations have several characteristics, such as:
• Lack of signaling channels (e.g. SDCCH)
• Lack of traffic channels (TCH)
• Congestion that results in “domino-” and “chain-effect”
• High congestion
• Medium congestion
• Low congestion
• Limited to a small-/large area

Each of the traffic-load scenarios will be characterized by a set of parameters that are very important in order to
be able to detect the kind of congestion. This will be shown in deliverable D-3.3 as scheduled at the beginning of
the project.

4.2 Traffic modeling

This section provides a qualitative and quantitative description of wireless telecommunications networks offered
workload, based on the experiences gathered in GSM traffic, and on the anticipated forecast for packet-data
traffic. Initially the applications that will be likely forging the traffic of the networks over the next 5-10 years are
discussed. These applications are grouped according to type of bearers they will be exploiting. Afterwards, a
qualitative characterization of the various types of traffic that the networks are intended to support is presented.
Finally, a quantitative description of the resource requirements that traffic sources impose on the network is
presented, in terms of signaling and traffic resources. It is quite important to highlight that most of the
information presented in this section, especially that related to 2+G and 3G systems, is based on projected data,
which is therefore subject to change as the technology will mature, and as the market will get forged by the
deployment of new systems and services.
4.2.1 Applications for mobile networks

While existing GSM systems primarily serve voice users and to some extent simple facsimile or short message
services (SMS), 2+ and 3G networks are expected to support a wide range of applications as:
Personal Communications i.e. voice, e-mail, SMS messaging, chat, etc.
Mobile Office i.e. Internet/Intranet access, web and WAP browsing, file transfer, etc.
Location based services i.e. navigation services, tourist information, locator services, etc.
Telemetry i.e. remote surveillance, burglar alarms, etc.
E-commerce i.e. on-line banking, electronic ticketing, etc.
Information services i.e. yellow pages, e-newspaper, etc.
Entertainment i.e. audio on demand, video on demand, gambling, interactive games, etc.
These different applications create different types of traffic patterns. For instance, some applications are fully
asymmetrical (i.e. data exchange oriented to downlink or uplink directions), where as others are symmetrical,
and some applications are very bursty (e.g. data applications), where as others have constant rates.
A view of the anticipated GSM service evolution towards multimedia services and higher bandwidth is depicted
in Table 15, since the GSM MoU Association places a high priority on developing the future of Third Generation
Systems based on the GSM platform evolution.
Table 15: Service evolution towards multimedia services
Data communications
bit rate Single slot Double slot Multiple slot
Application 9.6 kbit/s 19.2 kbit/s 76.8 kbit/s
Simultaneous Half rate Full rate Full rate

voice & data + 4.8 kbit/s + 9.6 kbit/s + 76.2 kbit/s
Wireline quality with

Hi/Fi music/ HiFi quality HiFi quality voice
enhanced full rate
voice voice and music
coder
Multimedia/ Stills Animations Video

video animations video conferencing

4.2.2 2G applications
Service types provided by GSM are basically speech and data:
• Speech: This is the most important service nowadays offered by GSM. The main speech service
provided by GSM is telephony. Emergency calling is a distinct service allowing a mobile user to reach
the nearby emergency service provider by dialing three digits number. Voice mailbox is another speech
service: the caller can directly access the mailbox of a mobile subscriber and deposit a voice message. It
will be stored and can be heard when the mobile user wants to retrieve it.
• Data: GSM users can send and receive data, at rates up to 9600 bps, to users on POTS (Plain Old
Telephone Service), ISDN, Packet Switched Public Data Networks, and Circuit Switched Public Data
Networks using a variety of access methods and protocols, such as X.25 or X.32. Since GSM is a digital
network, a modem is not required between the user and GSM network, although an audio modem is
required inside the GSM network to interwork with POTS.
A unique feature of GSM, not found in older analog system, is the Short Message Service (SMS), a bi-
directional service for sending short alphanumeric (up to 160 bytes) messages. SMS messages are transported in
a store-and-forward fashion. A point-to-point SMS message can be sent to another subscriber to the service, and
an acknowledgement of receipt is provided to the sender. SMS can also be used in a cell-broadcast mode, for
sending messages such as news or traffic updates. Messages can be stored in the SIM card for later retrieval.
Other data services include Group 3 facsimile, as described in ITU-T recommendation T.30, which is supported
by use of an appropriate fax adaptor. Supplementary services are provided on top of teleservices or bearer
services, such as call forwarding when the mobile subscriber is unreachable by the network), and call barring of
outgoing or incoming calls, for example when roaming in another country. Other additional supplementary
services are be provided as defined in the Phase 2 specifications, such as caller identification, call waiting, multi-
party conversations.
4.2.3 2+G and 3G applications

The 2+G and 3G wireless telecommunications systems that have been standardized by ETSI include the HSCSD,
the GPRS, and the EGPRS as 2+ generation, and UMTS for the third one, respectively. With respect to GSM,
the applications foreseen for these generations of telecommunications systems focus more on the data
transmission than on voice.
HSCSD will speed-up the data transmission by using a more dynamic circuit-switched technique with respect to
GSM, however, no significant changes are expected in the application arena. On the contrary, GPRS and EGPRS
are nowadays starting the wireless packet-switched communications, thus leading to a paradigm change that is
opening the way for a relevant shift in the classes of applications that can be realistically supported. In the
UMTS networks, mobile multimedia services such as voice, data transfer and video services must be provided.
The UMTS will evolve in several steps, moving from a GPRS like scenario in which circuit-switched and
packet-.switched will coexist and only the radio access part will be different with respect to GPRS, till the
complete IP solution in which the communication will be packet switched exclusively.
In the following sections the characteristics of packet-switched data applications, which will appear in wireless
networks with GPRS, and whose spread and accessibility will be enhanced thanks to the increased transfer rates
of EGPRS first and UMTS later are described.
A first classification of data services in wireless packet-switched networks distinguishes between two types of
services: Point to Point (PTP) services, and Point to Multipoint (PTM) services. The PTP service provides a
transmission of one or more packets between two users, initiated by a service requester and received by a
receiver.
There are two Point-to-Point services:
• PTP Connectionless Network Service (PTP-CLNS);
• PTP Connection Oriented Network Service (PTP-CONS)

The PTM service provides a transmission of packets between a service requester and a receiver group. There are
three Point-to-Multipoint services:
• PTM Multicast (PTM-M);
• PTM Group Call (PTM-G);
• IP Multicast (IP-M)
For PTM-M and PTM-G the data transmission is restricted to the members of a receiver group currently located
within a geographical area. The service requester specifies both the receiver group and the geographical area.
The geographical area addressing mechanism is not applicable to IP-M. An invocation of the service request by a
service requester is possible from the fixed and mobile access points. Table 16 presents the relationship between
service requests and the Service Requester/Receiver.
Table 16: Relationship of service request and service requester/receiver
Service requester/receiver Types of service request
AP = Access Point PTP-CONS and PTM-M PTM-G IP-M

PTP-CLNS
From fixed AP to mobile AP Supported Supported Supported Supported
From mobile AP to mobile AP Supported Supported Supported Supported
From mobile AP to fixed AP Supported Not applicable Supported Supported
Applications may also be as interactive services, involving only two end-stations, and distributed and collective
services, that involve far more end users; but even those two classes can be further divided as well.
• Interactive Services. Different kind of interactive service of communication between two entities,
which results in very different network traffic are the following:
• Conversational. Applications belonging to this class offer a bi-directional service of
communication between two entities in real time, without any need to save data for later
transmission. Most of the time, this results in exchange of voice data, which means that
this traffic has to be synchronized (to avoid packets arriving in random order) and fast (so
as to avoid lengthy delays between packets, which result in very poor sound quality for the
end users. Generally, it is considered that 20 ms is the delay above which the human ear
begins to notice the delay, and thus the poor quality of service offered). Although the
communication is bi-directional, the flow of data can be unidirectional (ex : a camera
recording images). Examples: telephony over IP.
• Messaging. This kind of applications offers a bi-directional service of communication
between two entities, not in real-time but with a store-and-forward mechanism. Typical
examples are services like mailboxes or messages editing but multimedia transfer flows
have to be considered, as well. If text transfer does not require much in terms of network
characteristics (except a reasonable degree of reliability of course), multimedia transfer
does require a lot of synchronism, not only between voice packets, but also between voice
and video packets. Also, this kind of traffic requires a lot of bandwidth, as multimedia
files are typically huge. Examples: E-mail (possibly multimedia).
• Retrieval. This kind of applications offers bi-directional, near real time, and asymmetric
sessions. That means that one of the entity (called client) takes the initiative of launching
all the sessions or terminating them. The other end entity (called a provider) only reacts to
the user’s commands. The information is sent to the user on demand only. The range of
data offered by providers covers the whole spectrum of traffic: text, binary data, still
images, video, audio, multimedia (audio + video, and possibly text mixed in as well). As
already said, the network requirements are as a consequence vastly different ranging from
reliability to synchronization mechanisms and speed of transmission. Examples: database
consultation, WWW.

• Distribution Services. Applications belonging to this class are characterized by unidirectional flow of
information from a given point in the network to other (multiple) locations. There can be two different
ways of communicating:
• Without Individual Control. In this particular case, all the providers can do is to send
data to a user that requests it. All a user can do is to request data. Example: video on
demand, radio broadcast.
• With Individual Control. In this case, a user is not restricted to an open/close-session
operating mode, but he can interact with the data he is receiving, by selecting a particular
piece of it or modifying it. Example: distributed databases.
• Collective Services. Although this situation involves more than two entities as seen in the preceding
example, the major difference is that the session is collective, and not made up from a set of dual
sessions. Example: videoconference, NFS (or similar file systems-sharing tools).
A snapshot of the mobile multimedia services, which are assumed, will be provided over wireless packet data
networks together with the expected traffic to be is shown in Figure 58.
Figure 58: Mobile Multimedia Services
These services widely range from the low-speed communication to the high-speed communication up to a
maximum of 2 Mbps (for UMTS only). A number of communication types are assumed including asymmetrical
and symmetrical transmission and Multi- point communication. The network operator are expected to provide a
network environment in which the user can freely use multimedia services without being restricted by the
network topologies and the need to re-provision user services. So it is desirable to build an integrated network in
which both circuit switched and packet switched services can be offered.
4.2.4 Qualitative traffic modeling

This subsection describes the typical patterns that characterize the traffic observed in wireless data networks. We
will first present the models of the session for the various applications listed above. These models represent the
basis for identifying the signaling and the traffic resources needs of each type of application. We then speculate

on the factors that affect the identified traffic patterns, to pinpoint those behaviors that can be observed during
overload situations.
4.2.5 Session modeling

In this section a qualitative description of the traffic sessions generated by the applications available for wireless
networks is presented. Initially the circuit-switched calls will be treated as a special case, and then the modeling
of the session for the packet-switched case will be approached.
4.2.5.1 Circuit-switched calls

The circuit-switched call is the only available communication technology in GSM networks. This same type of
communication is also available in GPRS for voice, and will be kept also in the first UMTS releases for
compatibility reasons. In a circuit-switched communication, a dedicated bi-directional channel is provided to the
mobile stations only on demand, but for whole the duration of the call.
Transmission paths are set-up on demand trough an exchange of signaling information between the network
elements. The set-up process starts trough the initial procedures of access and paging. For each mobile station
engaged in a communication, there exists a transmission path, as well as a signaling path, between itself and the
MSC. Such a path is set up when the mobile enters the dedicated mode and is released when the mobile goes
back to idle mode. This period of time is referred as RR-session.
A RR-session can be used for:
• Voice transmission;
• Data transmission;
In both the two cases, the partners involved in the communication exclusively hold the resources allocated to the
call, which remain statically allocated apart if handover is necessary. Therefore, from the viewpoint of the set-up
and maintenance processes, when a circuit-switched link is adopted, a voice-call session (Figure 59) is quite
similar to a data transmission (Figure 60).
voice silence voice voice silence voice
Circuit
Circuit call
call Circuit call
Session
Session Session Session
Figure 59: Circuit switched: voice transmission traffic model
In the case of circuit-switched connections we will not distinguish between the different types of data
applications, as they are all managed with the same session approach shown in Figure 60.
data data
Circuit call Circuit call
Figure 60: Circuit switched: data transmission traffic model

4.2.5.2 WWW Browsing

Web traffic is essentially bursty, with large volumes of data transferred in downlink direction. In practice, only
the downlink direction is significant, as in the uplink we can assume that only the traffic coming from page
requests and signaling messages is relevant. In order to understand the model of a web browsing session over a
wireless packet-switched transmission link, the basic structure of a web page and the mechanism of page
transmissions have to be considered. A web page consists of ASCII text, the HTML code. This part of the page
is referred to as the main object. In the HTML code images or other objects like Java classes may be embedded
with a reference to a separate file on the server. We will use the term inline objects or embedded files for them
henceforth. The downloading procedure of a WWW page starts when the user clicks on a link referencing this
page. Then a GetRequest is sent to the URL (Universal Resource Locator) indicated by the link. To transmit this
request a TCP connection has to be established between the user and the web server. After receiving the request
at the web server the main object is sent back to the browser. There, the HTML code is parsed for the occurrence
of inline objects that have not been yet transmitted.
At this point the latest and more efficient versions of HTTP allow the download of several inline objects in the
same TCP connection; several TCP connections can be established in parallel. Furthermore, to improve the
performance, the possibility exists to keep a TCP connection alive even after the requested web page is
completely transmitted. This is reasonable as the next requested page might reside at the same server. So for the
GetRequest no new TCP connection has to be established but the existing one is used instead.
Figure 61: Behavioral user model of Choi
The different views of the Web browsing process shown in Figure 61 can be mapped into the session model
shown in Figure 62.
HTML Embedded HTML Embedded

file + files file + files
Packet call Reading Time Packet call
Session Session
Figure 62: Web browsing traffic model

4.2.5.3 WAP browsing

The behaviour of the WAP session is similar to that of an HTTP session. The same two states behaviour
loading/viewing is found in WAP browsing, and there is the same unbalance between uplink and downlink data
transfer as in the case of Web browsing. The main difference is found in the structure and size of a viewed page.
The size of a WAP page is smaller than the size of a normal Web page due to its binary encoding. Moreover, the
number and size of included inline objects is reduced with respect to the Web browsing case, due to the limited
multimedia capability of the target mobile stations. The session model, depicted in Figure 63, takes into account
the burst nature of WAP browsing, similar to the Web browsing activities.
Active Embedded Active Embedded

WML OFF OFF
file file file Packet
Packet call Reading Time call IN
Activ
Session OFF Session
t
Figure 63: WAP browsing traffic model
4.2.5.4 E-mail
In the case of E-mail applications, a distinction between subscribers with different type of terminals should be
considered. Roughly, we can consider that a user with a laptop (or a PC) will have a heavier e-mail usage than a
mobile subscriber with a handheld device.
The differentiation is principally based on these factors:
• E-mail dimension
• Presence or absence of attachments
As far as the packet size and the statistics for the message inter-arrival are concerned, we can assume the same
values for the two kinds of GPRS devices. The message size will be different in the two cases. For both classes
of subscribers, the traffic pattern of the session is depicted in Figure 64. Notice that E-mail application can be
considered as generating a balanced uplink/downlink volume of data transfers.
E-mail message E-mail message
Packet call Packet call

Session Session
Figure 64: E-mail traffic model
4.2.5.5 FTP
The traffic model is similar to that for the Web browsing, except that here there is just one packet call for each
session (one file down/upload per session), and so the reading time is zero. Then, the number of sessions per
busy hour is calculated including in the FTP application “Software download”, “Archiving and Restoration (Data
Warehousing)” and “1/3 of Mobile Office and Corporate Intranet” service categories.

file file
Packet call Packet call
Figure 65: FTP traffic model
4.2.5.6 Telnet
The traffic pattern of telnet sessions is depicted in Figure 66. The model is similar to that one assumed for Web
browsing, except that for each packet call general packets are transmitted instead of packets belonging to files. A
session ends when the user is idle for more than 60 seconds.
General packets General packets

Delay between
Packet call packet calls Packet call
Session Session
Figure 66: Telnet traffic model
The “Job Scheduling and Dispatch”, “Telemetry meters/vending machines” and “Telemetry burglar alarms”
service categories are included in the Telnet application. All these services are characterized by symmetry in the
traffic generated in the uplink and downlink directions, as in the average Telnet sessions.
4.2.5.7 SMS (Short Message Service)

The SMS traffic model is very simple and is shown in the following figure:
message message message
Figure 67: SMS traffic model
4.2.6 Factors affecting traffic patterns

The traffic observed by a cellular network is the result of the superimposition of the traffic generated by the
various types of sources described above. Since each of the types of traffic is subject to fluctuations due to

several factors, the overall aggregated traffic is also variable. In this subsection we will describe the main causes
of such variations, to provide the ground for an understanding of the causes of the congestion scenarios that will
be dealt with within CAUTION.
Forecasts for the expected aggregated traffic are computed since the very early stages of network dimensioning.
The standard measure for estimating the traffic in cellular networks is the Erlang. One Erlang is the amount of
traffic generated by a user that fully utilizes a single traffic channel. For instance, if the typical GSM user
performed one call each two hours, and each call had an expected duration of three minutes, then in this case the
amount of traffic generated by the user would be 0.025 Erlang. The Erlang has been introduced to quantify
circuit-switched traffic, but it can be used also for packet-switched traffic. It is however important to remark that
in the case of packet-switched communication, the Erlang measure does not capture the intrinsic variability of
the transfer speed. For instance, suppose each user sends one E-mail each thirty minutes, whose average size is
15 Kbytes. If the E-mail is sent over the GSM radio channel, whose capacity is 9.6 Kbps, then the expected
traffic generated by the E-mail for that user is 0.069 Erlang. The overall traffic offered to a cell is evaluated as
the sum of the contributions from all the distinct traffic sources, and represents the reference level of the traffic
for a cell. This nominal situation is obviously different for each specific cell, and is also dependent on the type of
area (urban/rural), the size of the area covered by the cell (micro/pico). Obviously, the aggregated traffic
represents an average estimation of the traffic one cell has to support.
The time is surely the factor that most makes the actual traffic intensity to fluctuate around the average value.
Each user has specific time windows during which he/she is more active than during other periods. These micro-
variations at the user level become macro-variations at the aggregated traffic level. We will focus only on the
macro-variations, i.e. those that can be observed at the aggregated scale of the traffic. For instance, voice calls in
GSM show a typical time-dependent behaviour, as shown in Figure 68, which exhibits some traffic intensity
peaks during the so-called busy hours. Outside the busy hours time windows the traffic load intensity is much
less, as it can be observed by looking at the average value depicted in Figure 68.
This time-dependent shape of the voice call traffic is somewhat constant across the various GSM networks. It is
expected that some types of data traffic, as those due to business activities will follow the same patterns.
However, there are other kinds of behaviors that cause the data traffic to vary with time in a different way. For
instance, data traffic seems to be dependent from the actual network workload, with user exploiting the less
loaded hours for their accesses. This behaviour tends to redistribute a part of the workload.
18
16
14
12
10
8 Average value
6
4
2
0
10
12
14
16
18
20
22
24
0
Figure 68: Daily voice call traffic intensity fluctuation
A second factor that causes variations to the normal traffic patterns is the mobility of users. Whereas users tend
to follow almost regularly the same mobility patterns day after day, there are unforeseen situations that may lead
to rerouting of people movement, with dramatic variations of the traffic intensity with respect to the reference
values. An indirect cause of user mobility may also be adduced to network elements unreliability. In fact, due to
the outage of some network elements, users that were under the coverage of a given cell may start being served
by another cell, with the network experiencing the same effect as that of a user movement.
Another variation cause is introduced by the fact that the assumption postulating the independence of the traffic
sources is not actually satisfied under certain circumstances. Depending on the occurrence of particular events, a
positive correlation between the arrival processes of the calls is observed, and users tend to massively access the
system, causing sudden peaks of overload during hours that would have been of low traffic otherwise. An

example of such positive correlation can be observed during holidays, when the call request rate increases much
beyond the nominal values across the whole wireless network community of users.
4.2.7 Overload symptoms

The amount of workload that can be supported by a wireless telecommunication system is limited by the scarcest
of the available resources, i.e. the radio resource, which therefore represents the bottleneck of the whole system.
This bottleneck limits so heavily the overall system throughput that the other system resources are usually
neglected in the congestion analysis.
The nowadays radio resource scarceness is mainly due to historical reasons, with much of the useful spectrum
allocated for uses other than public communication services. Thus, a limited number of radio channels are
available, which tend to reach high level of utilization.
A few tens or radio channels are available in a medium size cell. Among this channel pool, some are used for the
purposes of signaling, whereas other ones carry the actual payload traffic, i.e. voice and data. In the following,
we will distinguish between signaling channels (SCH) and traffic channels (TCH) when discussing of channel
utilization. The reason we will adopt this differentiation is that reasoning on the levels of utilization of the
different sets of channels provides richer information than just considering the aggregated utilization level.
When looking at the overload from a resource utilization viewpoint, it appears quite intuitive to set threshold
values for identifying the appearance of congestion. When the utilization of radio channels approaches 80%, the
network may be considered approaching a congestion situation. Indeed, the amount of traffic sustained at that
level of utilization is very close to the maximum the network can afford. Even if more workload is offered, the
network cannot much increase the radio resource utilization. Depending on which radio channels get overloaded,
the congestion may lead to the following different scenarios.
4.2.7.1 Overload of signaling channels.

This situation is the common situation under typical overload situations. The overload on signaling may be of
various types, depending on the amount of workload. In spite of the high workload, there are extremely
overloaded situations during which the wide majority of calls cannot get access to the network, and at the same
time very little traffic is indeed served by the system. This is due to the slotted ALOHA random access
mechanisms that is used to send the first request to the network. Under very high traffic circumstances, the
collision of user requests on the common uplink signaling channel (RACH in GSM, PRACH in GPRS/UMTS)
may turn out in a waste of capacity, with no useful information reaching the radio resource management
subsystem.
1.6
1 TCH
1.4 2 TCH
3 TCH
4 TCH
1.2 5 TCH
6 TCH
Channel utilisation
7 TCH
1
0.8
0.6
0.4
0.2
0
20 40 60 80 100 120 140 160 180
Transmission requests
Figure 69 - PRACH limiting effect

Figure 69 reports the results of a simulation campaign aiming at evaluating the effect of various GPRS PRACH
dimensioning choices on the packet data services. The figure shows the average utilization of a pool of GPRS
TCHs as the number of user simultaneously trying to access the system increases. One single PRACH repetition
is used in the experiment. It is fairly evident the bottleneck effect of the collision over the PRACH channel.
When the frequency of PRACH repetition is increased, the utilization of TCHs reaches quite satisfactory values,
as shown in Figure 70.
3
1 PRACH
2 PRACH
Channel utilisation 2.5 4 PRACH
1.5
0.5
0
20 40 60 80 100 120 140 160 180
Figure 70 - Effect of increasing the frequency of PRACH repetitions
A similar beneficial effect can be observed on the call blocking probability, namely the probability that a call is
ejected by the BSC, as it can be observed from Figure 71.
1
1 PRACH
0.9
2 PRACH
4 PRACH
0.8
Call block probability
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
20 40 60 80 100 120 140 160 180
Figure 71 - Call block probability as a function of PRACH frequency
These figures are even more interesting to appreciate the effect of PRACH if one considers that the relative
percentage of users actually using the PRACH resource is very limited. In fact, as it can be observed from Figure
72, each GPRS users spends a very little time using the PRACH with respect to the total packet call duration
time.

GPRS user in
service
GPRS user
accessing PRACH
48% GPRS user

waiting a TCH
49%
3%
GPRS Reserved Channels = 0
Figure 72 - Percentages of GPRS users in the various call phases
The PRACH blocking phenomenon may become very dangerous under particular congestion situations of the
network. In Figure 73 we show the effect that the PRACH has on the time necessary to recover a normal network
situation after an outage, for various outage durations. Under these circumstances, the whole population of
GPRS users will reconnect (Attach) to the network. The time to recover is evaluated by observing the average
number of calls in service, till the steady-state value (horizontal reference line) is reached. As it can be observed,
the PRACH contention may in fact double the length of the service outage, as perceived by the users.
160
140
120
100
Userrs being served
80
60
40
Outage=20sec
Outage=80sec
20 Outage=160sec
Outage=230sec
Outage=300sec
0
0 50 100 150 200 250 300 350 400 450
TIME [sec]
Figure 73 - Outage lengthening effect of PRACH
When the bottleneck is not found in the random access channel, other logical signaling channels may become
overloaded.
4.2.8 Quantitative traffic modeling

This section provides the numerical estimations of the amount of traffic exchanged between mobiles and the
network during the various phases of activity. We separately consider the various generations of

telecommunication systems, and we deal both with the amount of data to be transferred and on the on the
requests for signaling resources.
4.2.9 Traffic resources requirements

This section provides the quantitative evaluation of traffic resource requirements for wireless applications is
terms of the amount of data to be transferred. These requirements can be translated into standard
telecommunication traffic measures such as Erlang. Whereas for the circuit-switched GSM and HSCSD the data
can be obtained from field observations, for the packet-switched GPRS/EGPRS and we can provide only
estimations based on traffic models. The traffic of UMTS will only be described in terms of expected
applications requirements, without characterizing the behaviour of the population of users.
4.2.9.1 GPRS
This section presents the data for the packet-switched applications that will run on the current and the next
generation of telecommunications systems. The wireless networks data traffic estimations need to take into
consideration the characterization of the typical profile of wireless subscriber. In fact some applications, such as
like e-mail with attachments, FTP, etc., will be used just by stationary subscribers with quite powerful devices
(like laptops for examples). Vice versa, WAP is likely to be used by users equipped with simpler devices such as
mobile phones or PDAs. Different classes of subscribers can hence be defined, as reported in Table 17. The table
assigns the shares of the various applications usage to the two different types of user profile.
Table 17: Application usage for different subscriber profiles
Profiles/Application Sub. Profile 1 (stationary Sub. Profile 2 (mobile user

user with laptop) with handheld device)
WAP browsing 0% 100%
Web browsing 100% 0%
E-mail without attachments 50% 50%
E-mail with attachments 98% 2%
FTP 90% 10%
Telnet 100% 0%
SMS 0% 100%
E-Commerce 50% 50%
The GPRS traffic estimations for the year 2004 for each of the considered traffic sources are summarized in
Table 18. It is assumed that the traffic generated by the Mobile Office could be mainly classified as e-mail, Web
browsing and FTP traffic, and for simplicity sake to compose it with equal parts of traffic. The total traffic
showed in Table 18 is the average traffic that can be imputed to each single subscriber, who however may be
able to access the network with both the typical handheld device as well as a more powerful device e.g. a laptop.
Table 18: Estimation for various traffic sources (per user)

Mean downlink values Mean uplink values
Tr Np/c Sa Pc/s Ps Tr Np/c Sa Pc/s Ps
E-mail 142788 72 8.01 1 248 56591 84 2.73 1 248
Web browsing 16504 25 0.34 5 391 495 25 0.34 5 11.7
WAP browsing 517 48 0.0039 10 278 145 67 0.0039 10 56
FTP 5242 525 0.028 1 338 2134 525 0.012 1 338
Telnet 81 1 0.0076 114 94 81 1 0.0076 114 94

SMS 6.1 1 0.061 1 100 0.7 1 0.007 1 100

e-Commerce 988 25 0.017 5 479 82 25 0.017 5 39.4
Total 166136 59528
The values estimated in the table above are defined as follows:

• Tr = average overall traffic per busy hour (14% of daily traffic) in bytes
• Sa = average number of session arrival in a busy hour
• Pc/s = average number of packet call in a packet session
• Ps = average packet size
• Np/c = average number of packets for each packet call
These mean values will vary depending on the existing QoS on the particular traffic load scenario. Therefore, it
is interesting to have as well a characterization of the measures variability in terms of their stochastic behaviour.
Let us introduce the following random variables:
Table 19: Random variable definition
Random Variable Average value

RVp Sa
RVc Pc/s
RVd Ps
RVr Np/c
The following table indicates some distribution for the mean values indicated in the previous sections for both
uplink and downlink direction.
Table 20: Type of distribution for the random variables in downlink and uplink
Application RVp RVc RVr RVd

WAP browsing Poisson Truncated Pareto Truncated Pareto Truncated Pareto
Web browsing Poisson Geometric Geometric Truncated Pareto
E-mail without attachments Poisson Truncated Pareto Truncated Cauchy
E-mail with attachments Poisson Truncated Pareto Truncated Cauchy
FTP Poisson Geometric Truncated Cauchy
Telnet/Chat Poisson Truncated Pareto Truncated Pareto Truncated Pareto
SMS Poisson Truncated exponential
E-Commerce Poisson Geometric Geometric Truncated Pareto

Table 21: Type of density and respective analytical expression
Type of random density Analytical expression Range

k −1
Geometric = p ⋅(1 − p ) 0 < k < ∞, 0 < p < 1
− λt k
Poisson =e ⋅ (λt ) / k! 0 < t < ∞, 0 < λ < ∞
α 1
Truncated Cauchy = ⋅ − to < t < t, 0 < α < ∞
2 2
t + α 2 arctan(t o / α )
Truncated Exponential = λ ⋅ e − λt /(1 − e − λt0 ) 0 < t < to , 0 < λ < ∞
α
α ⋅β 1 β < t < to , 0 < β < to,
Truncated Pareto = ⋅
t α +1 1 − ( β ⋅ t o ) −α 0<α<∞
4.2.9.1.1 UMTS
Since the UMTS system is not yet available, any kind of data traffic estimation could be too far from the
situation that we will meet. Being impossible to reliably foresee the future traffic load basing on actual situation,
this section presents a detailed description of the requirements for the applications that will run on UMTS
telecommunications system. First the classification of services made by UMTS Forum is presented, using a
number of performance parameters, and then performance requirements for a selection of applications are
outlined for real-time, streaming, interactive and background applications/services.
4.2.9.1.1.1 Service Classes

UMTS Forum attempted to break UMTS services into several classes using a number of performance
parameters.
Table 22: UMTS Service Classes and Characteristics
Services User net bit Coding Asymmetry Effective call Service bandwidth1 Switch
rate [kbit/s] factor factors duration [s] [kbit/s] UL/DL Mode2
High Multimedia 2000 2 0.005/1 53 20/4000 PS
(MM)
High interactive 128 2 1/1 144 256/256 CS
MM
Medium 384 2 0.026/1 14 20/768 PS
Multimedia
Switched data 14.4 3 1/1 156 432/43.2 CS
Simple 14.4 2 1/1 30 28.8/28.8 PS
messaging
Speech 16 1.75 1/1 60 28.8/28.8 CS
The service classes have different characteristics. High interactive multimedia services (e.g. video telephony)
require not only isochronous transmission but also switched data and speech services. They are therefore
calculated as circuit switched services. This means that the average call duration time corresponds to the actual
connection set-up time, the effective call duration depends on the occupancy factor e.g. for speech is 0.5, for
video telephony is 0.8, etc. For packet switched services, the call duration is calculated as the sum of time
1
The service bandwidth is the product of columns 2, 3 and 4.
2
CS is circuit switched and PS is packet switched.

intervals, where data is actually transferred via the air interface. Thus, the occupancy factor in this scenario is
equal to one.
1) Session initialized by user

2) Call set up
3) Data packet transfer
4) End of session: call clear
Session
call setup user packets call clear
t1 t2 t3 t4 t5
For spectrum calculations only effective data transfer time
is considered as "call duration time".
Call duration =Σ 1t + t2 + t3 + ... + 5t
Figure 74: Packet Transmission Over the UMTS Air Interface
4.2.9.1.1.2 Application Performance Requirements

In this section the performance requirements for a selection of applications are being outlined, divided in:
• Real-time;
• Streaming;
• Interactive;
• Background applications/services
4.2.9.1.1.2.1 Real-time services

The requirements of real-time services (see Table 23) are given by human perception, due to the conversational
nature of the services. Therefore, they raise the strongest requirements on the quality of service, putting strict
demands on transfer delay and jitter. However, these services usually have less hard requirements on packet loss
ratio.
• Voice. The requirement on transfer delay with regards to audio depends on the level of interactivity of
the users. The preferred range is 0 to 150 ms, but up to 400ms is acceptable. Since the human ear is
highly sensitive to jitter, a limit as low as 1ms is suggested as target. With respect to information loss,
the human ear is tolerant to a certain amount of distortion of the speech signal, setting the maximum
frame error rate (FER) to 3%.
• Videophone. Videophone carries both audio and video and is intended for conversational
environments. Therefore the same delay requirements as for voice applies. Once again, the human eye
is tolerant to some loss of information. It is excepted that acceptable video quality is obtained with
FERs in the region of 1%.
• Interactive Games. Requirements for interactive games are obviously dependent on the specific game,
but it is clear that demanding applications will require very short delays and a target value of 250ms is
often found.

Table 23: Requirements for Real-Time Services

Medium Application Degree of Data Performance parameters and target values
Freedom Rate
End-to-end One- Delay Information
way delay variation loss
Audio Conversational Two-way 4-25 kb/s <150msec preferred <1 msec <3% FER
Voice <400 msec limit
Video Videophone Two-way 32-384 <150msec preferred <1% FER
kb/s <400 msec limit
Data Telemetry Two-way <28.8 <250 msec N.A Zero
kb/s
Data Interactive Two-way <1 KB <250 msec N.A Zero
Games
Data Telnet Two-way <1 KB <250 msec N.A Zero
4.2.9.1.1.2.2 Streaming services

Streaming services mean looking at video or listening to audio in a one way manner. The requirements (see
Table 24) are characterized by the need to preserve the time relations between the information packets, although
it has no requirements on low transfer delay. However, due to buffering the acceptable jitter is much greater than
the jitter given by the limits of human perception. Since the data flows are unidirectional streaming services have
less stringent requirements on delay.
• Audio Streaming. Audio streaming will provide better quality than conversational telephony, thus
tightening the requirements on BER. However, since there is no conversational element the delay
requirements can be relaxed.
• One-Way Video. As with audio streaming, the main distinguishing feature of one-way video is that
there is no conversational element, meaning that the delay requirements will not be so stringent.
• Still Image. Since a single bit error can have large effects on the image quality, this category should in
general have zero information loss. However, this depends on the encoding format, some of which can
tolerate some information loss. As for delay requirements they are not very strict.
Table 24: Requirements for Streaming Services
Medium Application Degree of Data Rate Performance parameters and target values
Freedom
One way delay Delay Information
variation loss
Audio High Quality Primarily 32-128 kb/s <10 sec <1 msec <1% FER
Streaming Audio one-way
Video One-way One-way 32-384 kb/s <10 sec <1% FER
Data Bulk Data Primarily <10 sec N.A Zero
Transfer/ Retrieval one-way
Data Still Images One-way <10 sec N.A Zero
Data Telemetry - One-way <28.8 kb/s <10 sec N.A Zero
monitoring

4.2.9.1.1.2.3 Interactive services

Interactive services (see Table 25) refer to users being on line requesting data from a server. Examples of
interaction are web browsing and data base retrieval. Interactive traffic is characterized by the request response
pattern of the end-user. Round trip delay is therefore one of the key attributes in combination with low bit error
rate.
• Voice Messaging. Requirements for error rate is essentially the same as for conversational voice, but
the key difference is that there is more tolerance for delay since there is no direct conversation involved.
A delay of a few seconds appears to be reasonable for this application.
• Data. As a general rule a key requirement for data transfer is the need for essentially zero loss of
information. As for delay it depends on the type of application and is hard to define without knowledge
of the application in mind.
• Web-Browsing. The main performance factor is how fast a page appears after it has been requested. 0.5
seconds would be preferable.
Table 25: Requirements for Interactive Services
Medium Application Degree of Data Performance parameters and target values

Freedom Rate
One-way delay Delay Information
variation loss
Audio Voice messaging Primarily 4-13 kb/s <1 sec for playback <1 msec <3% FER
one-way <2 sec for record
Data Web browsing - Primarily <4 sec per page N.A Zero
HTML one-way
Data Transaction Services- Two-way <4 sec N.A Zero
(e-commerce)
Data Email (server access) Primarily <4 sec N.A Zero
one-way
4.2.9.1.1.2.4 Background services

Background applications usually refer to applications where the destination is not expecting the data within a
certain time. These applications are thus more or less insensitive to delay. However, a key requirement is usually
that the information should be delivered with a low bit error rate. Examples of applications are background
delivery of emails and SMS. For example, email can tolerate delays of several minutes or even hours, depending
on user expectations. On the other hand, it is quite clear that the information has to be delivery without errors.
4.2.10 Signaling
The signaling plays a major role in the traffic requirements of telecommunications systems. Each wireless access
to the network requires a set-up, maintenance, session and mobility management that represents a considerable
source of workload for the systems. Moreover, in all telecommunications systems a large amount of signaling is
generated for the mobility management even if the subscriber is not involved in any communications. In the
following, we describe the sources of signaling of relevant functionalities in the various telecommunications
systems, to quantify the amount of signaling messages exchanged for signaling purposes.

4.2.10.1 GSM
In this paragraph there we will describe the following features of GSM, taking into account the different
channels and number of messages involved:
• Attach-Detach procedures;
• Mobility management;
• Circuit switched communication;
• Short message service
Since most of the features listed above require first the mobile performing an access to the network, we will
describe the access procedure of GSM.
4.2.10.1.1 Access procedure

The access procedure is performed in order to obtain a dedicated signaling channel used for signaling message
exchange in Attach-Detach procedures, Mobility management procedures and call establishment for Circuit
Switched Traffic. In the beginning of the access procedure the mobile sends a RIL3-RR CHANNEL REQUEST
message on the random channel (RACH). Since the access on the RACH is not regulated this request may
collide with other ones. When multiple mobiles transmit during the same slot for sending the CHANNEL
REQUEST MESSAGE two things may happen:
• One out of the bursts is received by the BTS at a level significantly higher than the other one and it is
consequently correctly decoded;
• None of the bursts is received correctly
If the network cannot decode a request, no answer is sent to the mobile that issued it. According to the Slotted
ALOHA protocol, the mobile will retry issuing the request after a random interval. There are several ways the
network may use to control the load on the RACH, which will be detailed in Section YY, when discussing of the
resource management techniques for GSM. If the network decodes the request, and there are enough resources to
support the call, the network executes the Initial channel assignment: the mobile is answered by an RIL3-RR
IMMEDIATE ASSIGNMENT message (or RIL3-RR IMMEDIATE ASSIGNMENT EXTENDED message) on
the paging and access grant channel (PAGCH), carrying the description of the allocated dedicated channel
(SDCCH channel). After it has received that message, the mobile establishes the link layer for the transfer of
signaling on the newly allocated channel.
4.2.10.1.2 Attach-Detach
The mobile station triggers an IMSI detach when goes inactive and either a location updating procedure (if in a
new location area) or an IMSI attach procedure when it comes back (in the same location area). The IMSI detach
procedure consists of a single message from the mobile station to the visited MSC/VLR, the RIL3-MM IMSI
DETACH message. The IMSI detach procedure must use a radio connection, as any RIL3-MM procedure. This
connection is either established (see Access procedure paragraph) for the purpose of detach, or may pre-exist.
The mobile station immediately after the sending of the RIL3-MM IMSI DETACH message can abandon the
connection. The dialogue between the mobile and the network for the IMSI detach procedure (if the signaling
connection is not yet available) is made of the following amount of messages:
Table 26: Number of messages exchanged in the IMSI

detach procedure (SDCCH not available yet)
Mobile sent Network sent

RACH 1 (at least)
PAGCH 1
SDCCH 1

After the message on the SDCCH the mobile switches without waiting and ack, thus releasing the SDCCH. If
attach is indicated as supported in the cell the mobile station has chosen at switch-on (or SIM insertion), and if
the mobile station knows the subscriber is already registered in the same location area, it starts an IMSI attach
procedure, that is to say (except for a negligible detail) a location update procedure. It should be noted that the
attach procedure may happen even if there was no request for detach beforehand, because the network did not
require it at the time or simply because it was not physically possible in case of a loss of coverage before switch
off).
In order to perform the IMSI attach procedure, a signaling connection between the mobile and the network must
be established (see Access procedure paragraph). The dialogue between the mobile and the network for the IMSI
attach procedure is made of the following amount of messages:
Table 27: Number of messages exchanged in the IMSI attach procedure
Channel Mobile sent Network sent

RACH 1 (at least)
PAGCH 1
SDCCH 4 4
With the last message on the SDCCH (channel release message) the SDCCH is released. The sequence of events
in Figure 75, describes the IMSI (International Mobile Station Identity) attach procedure. Upon turning the
power on, the MS sends an “RIL3-RR (Radio Interface Layer 3 – Radio Resource Management) Channel request
Message” on Random Access Channel (RACH) to BSS. The network assigns the channel and the BSS sends an
“RIL3-RR IMM Assignment Message” to MS over the AGCH for the connection request message. This message
assigns the SDCCH to mobile. After the channel is assigned, MS sends an “RIL3-MM (Mobility Management)
IMSI Attach” message over the SDCCH to BSS, which is forwarded to MSC and then to VLR as a MAP/B
protocol message. VLR acknowledges MSC as “IMSI Attach Acknowledge” as a MAP/B protocol, which is
forwarded to BSS and then to MS. MSC also sends “Clear Command” for the channel release to BSS as
BSSMAP (BSS Management Application Part) protocol, which is then forwarded to MS. Upon receiving the
“RIL3-RR Disconnect” signal from MS, a “Clear Complete” message is sent to MSC as BSSMAP protocol.
MS BSS MSC VLR
Mobile turns on
RIL3-RR Channel Request on RACH
RIL3-RR IMM Assign on AGCH
SABM <identity of the message> (SDCCH)
UA (SDCCH)
RIL3-MM IMSI Attach (SDCCH)

<TMSI>
MAP/B Attach IMSI
<TMSI>
IMAP/B IMSI attach ack.
IMSI attach ack.
IRIL3-RR MSI attach ack. (SDCCH)
BSSMAP Clear Command
RIL3-RR Channel Release (SDCCH)
RIL3-RR DISC (SDCCH)
BSSMAP Clear Complete
UA (SDCCH)
Figure 75: Mobile attach

As shown in Figure 76, the IMSI detach procedure starts with the MS sending an “RIL3-RR Channel Request”
message on RACH to BSS. BSS assigns the SDCCH and notifies the channel assignment to the MS over AGCH.
The MS then sends an “RIL3-MM IMSI Detach Indication” message to the BSS. The message identifies the MS
(indicated here as <TMSI>) and contains an eight-bit code indicating IMSI detach. After receiving the “IMSI
Detach Indication” message from MS, the BSS forwards this message in a BSSMAP complete layer 3
information message to MSC. MSC in turn updates the state of MS in the VLR with a “MAP/B Detach IMSI”
message. VLR forwards this message to HLR as “MAP/D Deregister Mobile Subscriber”, and HLR marks MS
as unregistered. HLR forwards a “MAP/B Deregistration Accepted” message to VLR, which in turn sends a
“MAP/B Acknowledge IMSI Detachment” message to MSC. MSC sends a “BSSMAP Clear Command” to BSS
to clear the SDCCH channel assigned to MS. The BSS acknowledges via a “BSSMAP Clear Complete” message
to MSC.
MS BSS MSC VLR HLR
Mobile turns off
RIL3-RR Channel Request

(RACH)
RIL3-RR IMM Assign

(AGCH)
SABM <identity>
(SDCCH)
UA <identity>
(SDCCH)
RIL3-MM IMSI Detach

<TMSI>
BSSMAP Complete
MAP/B Detach IMSI

<TMSI> MAP/D Deregister Mobile
Subscriber
<IMSI>
MAP/D Deregistretion
Accepted
MAP/B Acknowledge
IMSI Detachment
Figure 76: Mobile detach
4.2.10.1.3 Mobility management

The mobility management consists of a set of procedures jointly performed by the network and the mobile to
allow the mobile to move within the coverage area of the network without loosing the possibility of
establishing/receiving calls. There are two types of mobility management procedure, the location updating and
the handover, which are described in the following two sections.
4.2.10.1.3.1 Location updating

The location updating procedure is triggered by a mobile to update the location data of a mobile subscriber. The
normal reason for a change is when the mobile station decides that the location area best fit to serve its
subscriber must be changed. This procedure requires a radio connection, as for any signaling dialogue between
the mobile station and the network. The establishment of such a connection is described in paragraph Access
procedure above.
Slightly modified versions of this procedure are used for different related purposes:

• Periodic Location Updating and Database Failure Recovery;

• IMSI Attach and Detach procedures: on the radio path both procedures are almost identical to a location
update (as seen in the previous paragraph).
The dialogue between the mobile and the network for the location updating procedure is made of the following
amount of messages:
Table 28: Number of messages exchanged in
the location updating procedure

RACH 1 (at least)
PAGCH 1
SDCCH 4 4
With the last message on the SDCCH (channel release message) the SDCCH is released. As shown in Figure 77,
when the MS switched on in a LA (Location Area) different from the previous one, or it moves across
boundaries of a LA in the idle state, an “RIL3-Location Updating Request” message, which is sent from MS to
BSS, is relayed to MSC. MSC in turn alerts VLR by a “MAP/B Update LA” message. The process of ciphering
can now start. After completing the ciphering process, the HLR sends “MAP/D Location Update Result” to
VLR, which in turn sends a “MAP/B Location Update Acknowledge” message to MSC. This message is
subsequently forwarded to the MS as an “RIL3-RR Location Update Accepted” message. After receiving a
location update accept message, the MSC asks the BSS to release the allocated dedicated resource by sending
“BSSMAP Clear Command” to BSS, which is then forwarded to MSC as a “BSSMAP Clear Complete”
message, which completes the location updating process.
MS BSS MSC VLR HLR

Mobile turns on or
enters new LA
Channel Request (RACH)
RIL3_RR IMM Assign (AGCH)
SABM <identity> (SDCCH)
UA <identity> (SDCCH)
RIL3-MM Location Update (SDCCH)

<LAIo, TMSI>
MAP/B Update Location Area
<LAIo, TMSI> MAP/D Update Location Area
MAP/B Set Ciphering Mode
BSSMAP Cipher Mode
<cipher key>
Command
RIL3-RR Cipher Mode
<cipher key>
Command (SDCCH)
RIL3-RR Cipher Mode

Complete (SDCCH)
BSSMAP Cipher Mode
Complete
MAP/D Location Update
Result
MAP/B Location Update
Acknowledge
RIL3-MM Location Update accepted

Channel Release (SDCCH)
DISC (SDCCH)
UA (SDCCH)
Figure 77: Location Update

4.2.10.1.3.2 Handover
The Handover execution procedure enables the network to command a mobile station in dedicated mode to go
onto another channel in another cell. The mobile station is completely unaware of the infrastructure process and
decisions until it receives the RIL3-RR HANDOVER COMMAND. This message contains all the information
characterizing transmission on the new channel; it also indicates to the mobile whether the synchronous or
asynchronous procedure should be followed.
In case of synchronous handover, the mobile station first sends the RIL3-RR HANDOVER ACCESS message,
and then starts normal transmission. Only when it sends the RIL3-RR HANDOVER COMPLETE message,
releasing the old SSCCH and TCH/F the mobile abandons all possibility of returning to the old channel. The
dialogue between the mobile and the network for the synchronous Handover procedure is made of the following
amount of messages:
Table 29: Messages exchanged in the synchronous

handover procedure
Mobile sent Network sent

SDCCH old 1 1
TCH/F old Released
SDCCH new 2
TCH/F Conversation
In case of asynchronous handover, the mobile station continues to send RIL3-RR HANDOVER ACCESS
messages until it has received the RIL3-RR PHYSICAL INFORMATION message from the new BTS. Then the
mobile starts normal transmission. Only when it sends the RIL3-RR HANDOVER COMPLETE message,
releasing the old SSCCH and TCH/F the mobile abandons all possibility of returning to the old channel. The
dialogue between the mobile and the network for the synchronous Handover procedure is made of the following
amount of messages:
Table 30: Messages exchanged in the synchronous

handover procedure

SDCCH old 1 1
TCH/F old Released
SDCCH new 2 (at least) 1
TCH/F Conversation
4.2.10.1.4 Circuit switched communication
4.2.10.1.4.1 Mobile originating call

When the mobile station wants start a call, it has to begin the access procedure described in paragraph Access
procedure. After it has received from the network the assignment message, the mobile establishes the link layer
for the transfer of signaling on the newly allocated channel. At the end of the signaling procedure on the
SDCCH, a full rate channel is assigned; two schemes are possible and are left for choice by the operator:
• Early assignment (basic call set-up scenario): the transmission path between the MSC and the MS is
fully operational before MSC is aware that the called is ready to converse. The alerting is postponed
until a suitable channel is allocated from the MSC to the destination mobile.
• Off Air Call Set-up (OACSU): allocation of traffic radio resources (TCH/F) is delayed, in attempt to
save radio resources; the transmission path is established only after the called user has accepted the call.

The dialogue between the mobile and the network for establishing a mobile originating call is made of the
following amount of messages:
Table 31: Messages exchanged in the establishment
of a mobile originating call

RACH 1 (at least)
PAGCH 1
SDCCH 4 4
FACCH 2 2
TCH/F Conversation
As shown in Figure 78, when the MS user wants to setup a call, he presses the button “send” and the mobile
sends the “Channel Request” message over the RACH, which is followed by a response over AGCH by BSS,
which identifies the SDCCH allocated to mobile. The MS initiates an immediate assignment and sends a SABM
frame containing the setup request (CM Service Request) to the network. The same message is returned as a UA-
frame over the SDCCH. When MS is connected to MSC, the MSC sends a “MAP/B Service Request” message
to VLR. At this stage, the network may initiate authentication and subsequently starts the cipher mode. TMSI, if
required, may also be assigned. After TMSI allocation the MS will initiate call establishment by sending the
“RIL3-CC (Call Control) Setup” message to the network. After that, MSC sends to VLR a “MAP/B Send Call
Setup Information” message, and the VLR responds with a “MAP/B Call Complete”. The MSC then sends the
MS an “RIL3-CC Call Proceeding” message to MS. MSC also assigns the TCH through an “RIL3-CC
Assignment Command”. After receiving the “RIL3-CC Assignment Complete” message from MS, MSC sends a
“TUP/ISUP Initial Address Mobile” message (IAM) to the PSTN/ISDN switching center. The switching center
returns a “TUP/ISUP Address Complete” Message (ACM). The MSC then sends an “RIL3-CC Alerting”
message to the MS. When the called party answers the switching center informs the MS with an “RIL3-CC
Connect” message. The MS responds with an “RIL3-CC Connect Acknowledgment” message. The conversation
now starts.
PSTN/ISD
MS BSS MSC VLR HLR/EIR/AUC N
PRESS
SEND RIL3-RR
Channel Request RACH
RIL3 - RR IMM AGCH

SABM
<identity of message> SDCCH (Up. Lk.)
UA SDCCH (Dn. Lk.)
Service Request SDCCH (Up. Lk.)

TMSI, Call Setup
Service Request
TMSI, Call Setup MAP/B Service Request
TMSI, Call Setup
MAP/B Autheticate
RIL3-MM Authentication
<RAND>
Request (SDCCH)
<RAND>
RIL3-MM Authentication
Response (SDCCH)
<SRESc> MAP/B Autheticate Results
<SRESc>
MAP/B Set Ciphering Mode

BSSMAP Cipher Mode
<cipher key>
Command
RIL3-RR Cipher Mode
<cipher key>
Command (SDCCH)

TUP/ISUP Initial Address Message

(IAM)
TUP/ISUP Address Complete Message

(ACM)
RIL3-CC
Alerting
Answer
Message
TCH/ RIL3-CC
SACCH Connect
RIL3-CC Connect
Ack
Conversation
starts
RIL3-RR Cipher Mode

Complete (SDCCH)
BSSMAP Cipher Mode
Complete
MAP/B Forward New TMSI
RIL3-MM Reallocate
<nTMSI>
New TMSI (SDCCH)
<nTMSI>
RIL3-MM TMSI
Reallocation Complete
(SDCCH)
MAP/B TMSI Acknowledgement
RIL3-CC Setup (Call Information)
MAP/B Send Call
Setup Information
MAP/B Call
Complete
RIL3-CC Call Proceeding
RIl3-CC
Assignment Cmd
RIl3-CC Assignment
Complete SDCCH (Up. Lk.)
RIl3-CC Assignment
Complete
Figure 78: Mobile originated call setup
4.2.10.1.4.2 Mobile terminating call – Paging

When a call to a subscriber reaches the MSC through which the subscriber is deemed reachable:
• The MSC/VLR requests the BSS to perform a paging in some of the cells of the BSS:
• MSC provides the identity of the mobile subscriber;
• MSC provides the list of cells in which the paging should be issued.
• For each cell in the list, the BSC sends an RSM PAGING command to the BTS device in charge of the
PAGCH of suitable TN (Timeslot Number determined by the BSC from the IMSI and the common
channel configuration). This message contains the number of the paging sub-channel3, as well as the TN
of the PAGCH;
3
Notice: the downlink common control channel can be divided into several paging sub-channels, and all the
paging messages pertaining to a given subscriber are normally sent on the same sub-channel. Mobile subscribers

• The BTS possibly packs some paging requests together and sends the resulting messages on the correct
paging sub-channel. Paging messages come in three brands (called RIL3-RR PAGING REQUEST
TYPE 1, TYPE 2 and TYPE 3) adapted to the size of the identity used for paging4.
In order to be consistent the paging indication should not be sent only once in each cell: a typical value (not
specified) would be to send it three times. Anyway, no repetition mechanism is described in the Specifications.
A mobile reached by a Paging message performs the access procedure described in paragraph Access procedure.
The dialogue between the mobile and the network for establishing a mobile terminating call is made of the
following amount of messages:
Table 32: Messages exchanged in the establishment

of a mobile terminating call

PAGCH 1 (at least)
RACH 1 (at least)
PAGCH 1
SDCCH 3 4
FACCH 2 2
TCH/F Conversation
Mobile terminating call establishment is similar to the respective originating call setup, but from the reverse part
(from switching center to MS). It is initiated by the network by sending the “Paging Request” message. Upon
receiving this message the MS initiates the immediate assignment procedure and responds to the network by
sending the “Paging Response” message. Details of this are illustrated in Figure 79.
are assigned to paging sub-channels in a pre-determined way taking into account the three last digits of their
international mobile subscriber identity (IMSI).
4
Type 1 can carry two identities of whichever sort, whereas Type 3 can carry four TMSIs, and Type 2 two
TMSIs and one identity of whichever sort.

RIL3-CC Call Setup

(Call information)
RIL3-CC Call
Confirmation
TUP/ISUP Address Complete
RIL3-CC Alerting Address Complete
Channel
Assignment Cmd
Channel
Assignment Cmd (SDCCH
Downlink)
Channel Assignment
Complete (SDCCH Uplink)
Channel Assignment
Complete
RIL3-CC Alert
TCH/SACCH (Uplink)
Alert
RIL3-RR Connect
RIL3-RR Connect Ack

TUP/ISUP Answers
TUP/ISUP Answer
Conversation starts
Figure 79: Mobile terminated call setup

4.2.10.1.5 SMS
For what concerns the channel usage, the short message service will be supported by an SDCCH or SACCH,
depending on the use of a TCH:
• When a TCH is not allocated, the short message service will use an SDCCH;
• If a TCH is allocated during a short message transaction on an SDCCH, the short message
transaction will stop and continue on the SACCH associated with the TCH;
• If a TCH is allocated for the short message service, the short message service will use the
associated SACCH;
• When an entity using a TCH finishes its transaction, the RR sub-layer may choose to continue
an ongoing short message transfer on the SACCH, or optionally transfer it to an SDCCH.
The following table summarizes the use of channels for the short message service. Arrows indicate changes of
channel.
Table 33: Channels used for short message transfer
Channel dependency Channel used
TCH not allocated SDCCH
TCH not allocated-> TCH allocated SDCCH -> SACCH
TCH allocated SACCH
TCH allocated -> TCH not allocated SACCH -> SACCH opt. SDCCH
As we can see in Figure 80, when a mobile subscriber wants to send a short message, the mobile sends the
“Channel Request” message over the RACH, which is followed by a response over AGCH by BSC, which
identifies the SDCCH allocated to mobile. After that, the authentication and the ciphering start with the SDCCH
allocation. The data of the short message transfer at the same SDCCH seizure. When all the data have
transferred, the MS releases the Channel.
Figure 80: Mobile originated SMS

The Mobile terminated SMS procedure, is the same with the mobile originated SMS procedure. The only
difference is that the procedure, for the terminated mobile, starts with the paging (Page Request). Details of this
are illustrated in Figure 81.
Figure 81: Mobile terminated SMS
4.2.10.2 HSCSD/GPRS/EGPRS
In 2+ generation systems, the traffic generated by voice calls will be exactly the same as that of GSM. Therefore,
we will be dealing only with the data communications. As the HSCSD will basically use the same resource
management and the same channels of GSM, we will focus on GPRS, to highlight the peculiarities of the packet-
switched telecommunication technology. As for the aspects of interest in this section, the EGPRS will not differ
from GPRS. The signaling traffic sources for the GPRS access network will generate signaling message
sequences according to the mobility management procedures and session management functions that are defined
for the GPRS network.
4.2.10.2.1 Mobility Management Functions

The mobility management activity in a GPRS access network is described by three different Mobility
Management (MM) states in Mobile Station (MS) and SGSN. These are:

• IDLE: The Mobile Station (MS) is not known by the network. Point to point data transfer is not
possible. If the MS wants to send or receive data it has to perform a GPRS attach procedure.
• STANDBY: MS is known on the Routing area level and the MS informs the SGSN when changing
Routing Areas. If a mobile originated data transfer is initiated the MS enter the READY state. The MS
is possible to be paged from the network and when a mobile terminated data transfer is initiated the
state is changed to READY.
• READY: MS is known on a cell level and the MS informs the SGSN when changing cells. Point to
point data transfer may occur. In this state the Mobile Station may have radio resources.
The transitions between the different states are:

• IDLE to READY: GPRS Attach procedure is performed to establish a logical link between MS and
SGSN.
• READY to STANDBY: The READY timer expires or the MS is forced to STANDBY.
• STANDBY to READY: PDU transmission is either a mobile originated data transfer or an answer to a
paging message for a mobile terminated data transfer.
• READY to IDLE: GPRS Detach procedure.
IDLE IDLE
GPRS GPRS Detach or GPRS GPRS

Attach Cancel location Attach Detach
Implicit Detach
or Cancel location READY READY
READY Timer Expiry or

PDU PDU
Force to STANDBY or
Transmission Transmission
Abnormal RLC condition READY Timer
Expiry or
Force to STANDBY
STAND-BY STAND-BY
SGSN side MS side
Figure 82: Mobility management states of mobile station
4.2.10.2.1.1 GPRS Attach

In order to access the GPRS services, an MS shall first make its presence known to the network by performing a
GPRS attach. This operation establishes a logical link between MS and SGSN. The network checks if the user is
authorized, copies the user profile from the HLR to the SGSN if the SGSN doesn’t already have that
information, and assigns a packet temporary mobile identity (P-TMSI) to the user. The GPRS attach procedure
can be:
• Normal GPRS attach, performed by the MS to IMSI attach for GPRS services only.
• Combined GPRS attach procedure, used by GPRS mobile stations in MS operation modes5 A or B, that
is MSs using both circuit-switched and packet switched services, to attach the IMSI for GPRS and non-
GPRS services; this entails updating of MSC/VLR.
With a successful GPRS attach procedure a GMM context is established. This procedure is related with the
frequency that a GPRS subscriber opens his Mobile Stations. The rate that a GPRS attach procedure is
performed, is the rate of switching-on per Mobile Station per day.
5
There are three GPRS MS classes, according to the possibility of using data and voice channel contemporary:
• MS class A, allowing full simultaneous GPRS and non-GPRS support
• MS class B, supporting simultaneous attach, simultaneous activation and simultaneous
monitoring, but only alternative data transfer
• MS class C, alternatively attached to GPRS or non-GPRS services

4.2.10.2.1.2 GPRS Detach

The GPRS detach procedure is used:
• to detach the IMSI for GPRS services only. Independent of the network operation mode, this procedure
is used by all kind of GPRS MSs;
• as a combined GPRS detach procedure to detach the IMSI for GPRS and non-GPRS services or for
non-GPRS services only
• in the case of a network failure condition to indicate to the MS that a re-attach with successive
activation of previously active PDP contexts shall be performed.
The GPRS detach procedure shall be invoked by the MS if the MS is switched off, the SIM card is removed
from the MS or if the GPRS or non-GPRS capability of the MS is disabled. The procedure may be invoked by
the network to detach the IMSI for GPRS services. The GPRS detach procedure causes the MS to be marked as
inactive in the network for GPRS services, non-GPRS services or both services. The rate that a GPRS detach
procedure is performed, is the rate of switching-off per Mobile Station per day.
4.2.10.2.1.3 Purge Procedure

The Purge function allows an SGSN to inform the HLR that it has deleted the MM and PDP contexts of a
detached MS.
4.2.10.2.1.4 Security Procedures

The Security function guards against unauthorized GPRS service usage (authentication and service request
validation), provides user identity confidentiality (temporary identification and ciphering) and provides user data
confidentiality (ciphering).
4.2.10.2.1.5 Location Management Procedure

The Location Management function provides mechanisms for cell and PLMN selection and mechanisms for the
network to know the Routing Area for MSs in STANDBY and READY states and the cell identity for MSs in
READY state. A routing area (RA) consists of one or more cells and is the area for paging. A routing area is
equal to or a subset of a Location Area. Procedures for cell and routing area update are briefly explained below.
GGSN
SGSN SGSN
BSS BSS BSS
MS MS MS
Intra SGSN Inter SGSN
RA Update RA Update
Figure 83: Intra & inter SGSN routing area update

When an MS changes cells within a RA it performs a Cell Update by sending the identity to the SGSN and the
BSS adds the Routing Area Identity. Whenever an MS moves to a new RA, it sends a "routing area update
request" to its assigned SGSN. The message contains the routing area identity (RAI) of its old RA. The base
station subsystem (BSS) adds the cell identifier (CI) of the new cell, from which the SGSN can derive the new
RAI. Two different scenarios are possible:
• Intra-SGSN routing area update: The MS has moved to an RA that is assigned to the same SGSN as the
old RA. In this case, the SGSN has already stored the necessary user profile and can assign a new
packet temporary mobile subscriber identity (P-TMSI) to the user ("routing area update accept"). Since
the routing context does not change, there is no need to inform other network elements, such as GGSN
or HLR.
• Inter-SGSN routing area update: The new RA is administered by a different SGSN than the old RA.
The new SGSN realizes that the MS has changed to its area and requests the old SGSN to send the PDP
contexts of the user. Afterward, the new SGSN informs the involved GGSNs about the user's new
routing context. In addition, the HLR and (if needed) the MSC/VLR are informed about the user's new
SGSN.
There also exist combined RA/LA updates. These occur when an MS using GPRS as well as conventional GSM
moves to a new LA. The MS sends a "routing area update request" to the SGSN. The parameter "update type" is
used to indicate that an LA update is needed. The message is then forwarded to the VLR, which performs the LA
update. To sum up, GPRS mobility management consists of two levels: Micro mobility management tracks the
current routing area or cell of the mobile station. It is performed by the SGSN. Macro mobility management
keeps track of the mobile station's current SGSN and stores it in the HLR, VLR, and GGSN. If the change of RA
takes place within a SGSN it is a Intra SGSN RA update and if the new RA is connected to a new SGSN it is an
inter SGSN RA Update.
4.2.10.2.2 Session Management Procedures

The main function of the session management (SM) is to support PDP context handling of the user terminal. The
Packet Data Protocol (PDP) context functions are network level functions, which are used to bind a MS to
various PDP addresses and after use to unbind the MS from these addresses. The PDP context can also be
modified. When a MS is attached to the network, it has to activate all the addresses it wants to use for data traffic
with the external networks, e.g., an IP address in case the PDN is an IP network. This address is called PDP
address (Packet Data Protocol address). For each session, a so-called PDP context is created, which describes the
characteristics of the session. It contains the PDP type (e.g., IPv4), the PDP address assigned to the mobile
station (e.g., 129.187.222.10), the requested QoS, and the address of a GGSN that serves as the access point to
the PDN. This context is stored in the MS, the SGSN, and the GGSN. With an active PDP context, the mobile
station is "visible" for the external PDN and is able to send and receive data packets. The mapping between the
two addresses, PDP and IMSI, enables the GGSN to transfer data packets between PDN and MS. A user may
have several simultaneous PDP contexts active at a given time. The allocation of the PDP address can be static
or dynamic. In the first case, the network operator of the user's home-PLMN permanently assigns a PDP address
to the user. In the second case, a PDP address is assigned to the user upon activation of a PDP context. After the
subscriber has finished the use of activated addresses, these have to be deactivated. Also the change of address
specific attributes has to be performed sometimes. The MS can use these functions when in STANDBY or
READY state. The GGSN can also use these functions, but the SGSN is responsible for performing these
functions. The MS can select a particular GGSN for the access to certain services and also activate a PDP
context anonymously, without using any identification.
4.2.10.2.2.1 PDP Context Activation Functions

The purpose of this procedure is to establish a PDP context between the MS and the network for a specific QoS
on a specific NSAPI. The PDP context activation may be initiated by MS or requested by the network

Anonymous context activation may be employed for pre-paid services, where the user does not want to be
identified. The rate that an Activate PDP Context procedure is performed is related with the cumulative number
of “sessions” are originated or terminated to the Mobile Station for all the services that are supported.
4.2.10.2.2.2 PDP Context Modification

The PDP context can be modified by the SGSN with a Modify PDP Context procedure. Only the parameter QoS
Negotiated can be changed. The SGSN sends the request to the MS, which either accepts the new QoS by
sending a Modify PDP Context Accept to the SGSN or does not accept it by sending a Deactivate PDP Context
Request for that context.
4.2.10.2.2.3 PDP Context Deactivation

The PDP Context deactivation may be initiated by MS, SGSN or GGSN. Every address can be deactivated
separately, but when the GPRS Detach is performed, all the PDP contexts will be automatically removed by the
network. This procedure terminates the access to a Packet Data Network. The rate that the Deactivate PDP
Context is performed is the same with the rate of the Activate PDP Context procedure.
4.2.10.2.3 Number of Messages to/from SGSN

In this subsection, the numbers of messages of the principal signaling procedures at the interfaces Gb, Gn, Gr,
Gs, Gf are counted and listed in Table 34. The number of messages given in is the maximum number for each
procedure. Some procedures/functions defined in GSM 03.60 are optional. The 'Portion' item means the portion
of a procedure in the same kind of procedures. For example, in the Attach procedures, some are Combined
GPRS/IMSI, some are GPRS Attach only. The portion of the Combined GPRS/IMSI is 80%, which means the
Combined GPRS/IMSI procedures account for 80% of all the Attach procedures. A call mix where 70% users
are Class A/B, 30% are Class C is assumed. Class C only can be either GPRS or IMSI attached and not both
together. It is assumed that half of Class C users are GPRS Attached. Therefore among all the GPRS Attach
procedures, 70%/(70%+15%)=82% are Combined GPRS/IMSI procedures. For simplicity, 80% is assumed.
Table 34: Number of Messages to/from SGSN

Signaling Procedures Num. of Messages to/from SGSN Portion
Gb Gn Gr Gs Gf Total (%)
MM Attach Combined GPRS/IMSI 5 2 4 3 14 80
Procedures6 GPRS only 5 2 4 11 20
MS-Initiated Combined 2 2 2 6 70
MS-Initiated GPRS 2 2 4 10
Detach SGSN-Initiated Combined 2 2 1 5 5
Procedures SGSN-Initiated GPRS 2 2 4 5
HLR-Initiated Combined 2 2 2 1 7 5
HLR-Initiated GPRS 2 2 2 6 5
Purge Procedure 2 2
Security Authentication 2 2 4
Procedures Identity Check 2 2 4
Routing Area Combined Intra SGSN RA/LA 3 3 6 45
Update Combined Inter SGSN RA/LA 3 6 4 3 16 45
Procedures6 Intra SGSN RA 3 3 5
6
The optional security functions (Authentication and Identity Check) are not counted in the procedures. They are
listed and calculated separately.

Inter SGSN RA 3 6 4 13 5
Subscriber Insert Subscriber Data 2 2
Management
Delete Subscriber Data 2 2
Procedures
Paging (GPRS, CS) Procedure 2 2
PDP Context MS-Initiated 2 2 4 80
Activation Network-Requested 3 4 7 10
Procedures6 Anonymous Access 2 2 4 10
PDP Context Modification Procedure 2 2 4
Initiated by MS6 2 2 4 80
SM Initiated by SGSN 2 2 4 5
PDP Context Initiated by GGSN 2 2 4 5
Deactivation MS-Initiated
2 2 5
Procedures Anonymous Access
GGSN-Initiated
4 2 6 5
Anonymous Access
4.2.11 Stochastic modeling of applications

The qualitative and quantitative information presented in the sections above can be combined to define
executable traffic models of stochastic nature. In this section, a Stochastic Petri Net (SPN) based modeling
approach that allows building traffic generator models for the various load sources of interest in CAUTION is
presented. These models are solvable by automated tools to obtain the statistic characterization of resource
requests. Moreover, due to the formal specification they provide, it is possible to unambiguously code them in a
programming language for inclusion in traffic simulators.
The SPN model shown in Figure 84 represents an abstract model that formally describes the behaviors of the
various data traffic sources presented in this document. The type of Petri Nets we will be using in the following
is a very expressive extension of Generalized Stochastic Petri Nets (GSPN), which allow for the definition of
very compact and easy-to-read models of even quite complex structures and behaviors.
4.2.11.1 The Petri Net modeling formalism

Just four types of objects are allowed in SPN models, namely, places, transitions, arcs, and tokens. These basic
types of objects are arranged to form a bipartite graph, so that arcs solely link places to transitions and transitions
to places. Tokens are entities that flow through the graph moving from one place to another without stopping
elsewhere. The number of tokens contained in a place is called the marking of the place, and the vector that
collects the markings of all the net places is the marking of the model.
Changes in the marking model are triggered by the firing of transitions. Transitions get enabled when a specific
predefined predicate on the net marking is satisfied. The enabling condition may be either expressed by a
predicate associate to the transitions, or graphically through the arcs that are in input to the transitions. If input
arcs are present, then the transition is enabled if and only if all the places connected to the input arcs have at least
as many tokens as their weight is. If the enabling condition persists long enough, the transition fires, and the
marking of the model is changed by removing same tokens from a set of places and adding tokens to other
places, according to the net specification. Notice that thanks to this mechanism of enabling rules,
synchronizations are quite naturally expressed. Also, batch movement of tokens are very easily realized.
The delay necessary for a transition to fire is called the firing time, and for SRN models is a negative
exponentially distributed random variable. Thus, starting from an initial marking, the model evolves over time,
possibly reaching some steady-state condition.

The model is completed by a set of numerical information that is attached to the various modeling objects. The
initial number of tokens is assigned to each place, marking-dependent functions are associated to arcs, and
priorities and marking-dependent firing rates are associated to transitions.
4.2.11.2 A generic SPN traffic model

We now can introduce the model in Figure 84, which represents the behaviour of a single user that accesses a
wireless network to execute some packet data application tasks.
call in progress
begin
session n_pkt_calls pkts transmission
idle off time gen_pkt_calls gen_pkts pause think next
RR ALOHA
RR
usage usage
wait
grant
TCH
assignment
TCH
granted
Figure 84 - Generic traffic model for packet data applications
Exploring the behaviour of the model over time, the possible state it may reach should be explored. At the
beginning, the model contains only one token in place idle, meaning that the user is not performing any
application session. In this state of the model, transition off_time is enabled. When the transition fires, the token
will be moved to place begin_session, meaning that a new activity session has begun. The firing of transition
off_time takes a time that is a random variable whose distribution is defined according to the information given
in previous sections. When the modeled session starts, the model generates (through the firing of transition
gen_pkt_calls) a random number of packet data calls, which are modeled by the number of tokens put in place
n_pkt_calls. Packet calls are served sequentially, one after the other. When one packet call starts being served,
transition gen_pkts generates the random number of packets the call will consist of. A number of tokens equal to
the number of generated packets are put in place pkts. Notice that the two transitions gen_pkt_calls and gen_pkts
may follow any distribution with positive integer support. The SPN at this point models the radio resource
acquisition. Indeed, when the number of tokens in place pkts is greater than zero, the ALOHA transition get
enables, modeling the slotted ALOHA mechanisms used for radio resource requests. Notice that the model will
only allow one firing of transition ALOHA per packet call. The arcs with small circles at then will inhibit any
firing of transition ALOHA when tokens are in places wait grant or TCH granted. When TCHs have been
obtained, the transition transmission gets enabled; it will fire with the time required for the data transfer. After
that, before starting the next packet call service, the model stops for the firing of transition think. Then the next
packet call service is started, or the model goes back to the initial state when all packet calls are serviced.
The model is generic in a sense it can be tailored for the various source of data traffic presented in the previous
sections. Such tailoring mainly passes through the definition of the random variables distributions specific for
the traffic source to be modeled . For instance, we show in Figure 85 the simplified version of the model for the

E-mail application. We exploited the fact that, as described in the qualitative modeling, each E-mail session
consists of a single packet call.
call in progress
begin
session pkts transmission
idle off time gen_pkts
RR ALOHA
RR
usage usage
wait
grant
TCH
assignment
TCH
granted
Figure 85 – E-mail traffic model
The models can be solved with many automated tools. Quite recently, the success of the Petri Net modeling
formalism has indeed paved the way for the introduction of many of PSPN-based modeling tools: SHARPE;
SPNP, UltraSAN, TimeNET, DSPNExpress, PANDA, SURF-2, CPN-AMI, GreatSPN, SPN2MGM,
Design/CPN, DEEM, are among the most popular ones, which have appeared several times in the recent
literature.
Solving the model in steady state would allow estimating measures such as the expected number of ALOHA
contentions per user per unit of time, the average time to complete a session, as a function of typical network
parameters, as for instance the average transmission time.
The models of single users can be composed to form populations, with mixing different types of workload
sources. By modifying the network operator parameters, it is possible to represent the occurrence of overloads.
For instance, consider the logical scheme of model shown in Figure 86, in which two different populations
coexist and compete for network resources. The network can be modeled as a SPN itself. If an overload
condition arises in the network model, then the population of users will be obviously influenced by the degraded
QoS offered. In this case, we could represent the degraded network performance by lengthening the transmission
time. This would affect all the population, resulting in longer services. If we need to mimic the consequences of
a large-scale event such as a catastrophe, we could act on the behavioral parameters of the models, such as
drastically reducing the idle time, thus causing a sudden increase in the rate of resource requests and in fact
introducing a strong degree of correlation in the behaviour of the populations.

Population A Population B
requests requests
grant/denial
grant/denial
Wireless Network
Figure 86 – Composed model of various traffic sources
4.2.11.3 SPN models as simulator building blocks

The models presented in the previous section can be quite naturally included into simulators, as representing
traffic model building blocks. Indeed, it is possible to translate the graphical SPN language into the sequential
code of a simulator. Events and event occurrence times will be generated according to the distributions of the
various transitions present in the model. Tokens representing entities of the real system are translated into the
corresponding simulation entities, whereas tokens used to keep memory of the state of the SPN, such as the
token in place idle in the model in Figure 84, are lost because embedded in the code sequential flow. As an
example of the easy translation of the SPN model into code for simulation, we give in the following a pseudo-
code version of the E-mail traffic model shown in Figure 85.
do
/* start in idle mode */
sleep_time=RANDOM(off_time); /* draw a RV with proper distribution */
WAIT(sleep_time); /* wait till E-mail sending time */
n_pkts=RANDOM(gen_pkts); /* E-mail size generation */
aloha_time = RANDOM(ALOHA); /* generate ALOHA contention time */
WAIT(aloha_time); /* this is a point resource requests are issued in
the real world */
grant_time= RANDOM(TCH assignment);
WAIT(grant_time);
tr_time=RANDOM(transmission(n_pkts));
WAIT(tr_time);
while (TRUE)

5 REVIEW AND EVALUATION OF RESOURCE MANAGEMENT

TECHNIQUES IN CELLULAR NETWORKS
5.1 Resource management techniques in cellular networks of 2G
Due to congestion situations that arise most of the times in big cities, the need of available traffic channels as
well as control channels like SDCCH and AGCH arises also. Furthermore, it has been found that the problem is
focused in the availability and wrong planning on the radio resources of the network. Therefore techniques to
overcome these problems should be found, techniques for capacity management. In this chapter the aim is to
evaluate existing techniques but also to enhance other and finally to obtain new techniques. Some of these
techniques are converge to traffic channel allocation while others to control channels as mention before, and
often sometimes both. For the purposes of the congestion management techniques, a network simulator was
developed. The simulator structure is presented in the following sections.
5.1.1 Dynamic SDCCH
5.1.1.1 General
Stand alone dedicated control channel (SDCCH). This channel is always used when a traffic channel has not
been assigned, and is allocated to a mobile station only as long as control information is being transmitted. It is
used in case of a call setup, before allocating a traffic channel. Moreover, control information transmitted on the
SDCCH includes SMS service, location area updating as well as authentication. The channel capacity available
from an SDCCH is 782 bit/s, which is much lower than that of a TCH.
Dynamic SDCCH scheme enables the configuration of SDCCH resources according to the actual SDCCH traffic
situation of a cell. When the BTS needs temporarily larger SDCCH capacity than normally, idle traffic channel
(TCH) resources are configured for SDCCH use by the BSC. When the SDCCH congestion situation is over, the
extra SDCCH resources are configured back to the TCH resources.
The operator is required to configure to the BTS the minimum static SDCCH capacity sufficient to handle the
normal SDCCH traffic. An extra SDCCH resource is allocated when the actual SDCCH congestion
situation has started after the last free SDCCH is allocated, in order to keep the maximum TCH capacity
available all the time.
The SDCCH resource, which is created dynamically, is always an SDCCH/8. SDCCH resource can be
configured dynamically when a MS is accessing the BTS and the SDCCH is allocated for immediate assignment.
The placement of a new SDCCH/8 depends on the following:

An RTSL of at least interference is selected
The SDCCH is configured to a TRX, which does not yet have any SDCCH resource or has the smallest
amount of them.
The preference order of the TRXs also influences the TCH configurations: priority is given to the TRX,
which has least working traffic channels.
When the BTS detects a fault in the telecom-signaling link, the BTS releases active channels of the TRX and
reconfigures dynamic SDCCH resources back to the TCH. The configuration information of the RTSL is
received in the next Channel Activation command from the BSC. The BTS accepts the data and configures the
idle RTSL to SDCCH or TCH, depending on what is requested. When the BSC detects a telecom signaling link
fault, it blocks the TRX. After the signaling link has recovered, the TRX is deblocked.

Principles that are followed when a radio channel is allocated from the SDCCH resources of the BTS are (for
minimizing the consumption of TCH channels):
SDCCH is always allocated from static SDCCH resource if there is a free channel.
When SDCCH is allocated from dynamic SDCCH resources, then the one with the smallest amount of idle
SDCCH subchannels left is used.
5.1.1.2 Parameters
5.1.1.2.1 Restrictions
During SDCCH handover dynamic SDCCH configuration is not allowed. However, already existing free
dynamic SDCCH resources are used in the target cell of the SDCCH handover.
5.1.1.2.2 Capacity
The maximum number of SDCCHs in the BSC depends on the number of TRXs that are connected to the BSC
Signaling Units (BSCU) and the number of BSCUs that are working in the BSC, where:
Max_SDCCH_count_per_BSCU = 12 * Max_TRX_count_per_BSCU, where

Max_SDCCH_count_per_BSCU, includes both the static and dynamic SDCCHs.
However, dynamic SDCCH resources can be shared between all TRXs of the BTS. The absolute limit is that the
max SDCCH number in a TRX must not exceed 16 channels; when this limit value is reached, at least one of the
two SDCCH/8 resources must be a dynamic one.
The max number of dynamic and static SDCCH channels together is limited to 12 subchannels (SDCCH/4 and
SDCCH/8) in those TRX, which use the 16 kbit/s link for the Telecom signaling. TRXs of higher capacity
signaling link (32 kbit/s or 64 kbit/s) can be configured up to 16 SDCCHs. The restriction of 12 SDCCHs per
TRX is sufficient when the maximum configuration of TRX consists or 18 radio channels maximum, that is, (12)
SDCCHs and 6 TCHs.
Three possible alternatives:

When the BCCH TRX has the combined CCCH/SDCCH, then no HR supporting TCH resource can be
configured to the TRX.
When the BCCH TRX does not have the combined CCCH/SDCCH, then the maximum of four HR
supporting TCH resources can be configured to the TRX.
Non-BCCH/SDCCH can be configured to maximum of three HR supporting TCH resources. (A 32kbit/s
LAPD link is highly recommended for supporting the telecom signaling which HR requires).

5.1.1.3 Examples (diagrams)

In case we have one BTS with three (3) TRXs the allocated SDCCHs channels within the BTS are 20, where,
SDCCH (SDDCH/4 + SDCCH/8 + SDCCH/8) and 6 TCHs. These can be shown in the following diagrams:
Broadcast TRX
Downlink
FN TS0 TS1 FN TS2 TS3 TS4 TS5 TS6 TS7

0 FCCH SDCCH0 0 TCH TCH TCH TCH TCH TCH
1 SCH SDCCH0 1 TCH TCH TCH TCH TCH TCH
2 BCCH1 SDCCH0 2 TCH TCH TCH TCH TCH TCH
6 AGCH/PCH SDCCH1 6 TCH TCH TCH TCH TCH TCH
12 AGCH/PCH SDCCH3 12 SACCH SACCH SACCH SACCH SACCH SACCH
22 SDCCH0 SDCCH5 22 TCH TCH TCH TCH TCH TCH
25 SDCCH0 SDCCH6 25
32 SDCCH2 SACCH0 6 TCH TCH TCH TCH TCH TCH
38 SDCCH3 SACCH1 12 SACCH SACCH SACCH SACCH SACCH SACCH
40 FCCH SACCH2 14 TCH TCH TCH TCH TCH TCH
41 SCH SACCH2 15 TCH TCH TCH TCH TCH TCH
42 SACCH0 SACCH2 16 TCH TCH TCH TCH TCH TCH
48 SACCH1 22 TCH TCH TCH TCH TCH TCH
49 SACCH1 23 TCH TCH TCH TCH TCH TCH
50 24 TCH TCH TCH TCH TCH TCH
25

Uplink
FN TS0 TS1 FN TS2 TS3 TS4 TS5 TS6 TS7
0 SDCCH3 SACH1 0 TCH TCH TCH TCH TCH TCH
4 RACH SACH2 4 TCH TCH TCH TCH TCH TCH
5 RACH SACH2 5 TCH TCH TCH TCH TCH TCH
6 SACH2 SACH2 6 TCH TCH TCH TCH TCH TCH
12 SACH3 12 SACCH SACCH SACCH SACCH SACCH SACCH
13 SACH3 13 TCH TCH TCH TCH TCH TCH
14 RACH 14 TCH TCH TCH TCH TCH TCH
15 RACH SDCCH0 15 TCH TCH TCH TCH TCH TCH
25 RACH SDCCH2 25
38 SDCCH0 SDCCH5 12 SACCH SACCH SACCH SACCH SACCH SACCH
47 SACCHO 21 TCH TCH TCH TCH TCH TCH
25

TRX 1
Downlink
SDCCH/8 + 7 TCHs
FN TS0 FN TS1 TS2 TS3 TS4 TS5 TS6 TS7

0 SDCCH0 0 TCH TCH TCH TCH TCH TCH TCH
12 SDCCH3 12 SACCH SACCH SACCH SACCH SACCH SACCH SACCH
25 SDCCH6 25
32 SACCH0 6 TCH TCH TCH TCH TCH TCH TCH
38 SACCH1 12 SACCH SACCH SACCH SACCH SACCH SACCH SACCH
48 22 TCH TCH TCH TCH TCH TCH TCH
25

Uplink
FN TS0 FN TS1 TS2 TS3 TS4 TS5 TS6 TS7
0 SACH1 0 TCH TCH TCH TCH TCH TCH TCH
12 12 SACCH SACCH SACCH SACCH SACCH SACCH SACCH
25 SDCCH2 25
38 SDCCH5 12 SACCH SACCH SACCH SACCH SACCH SACCH SACCH
47 SACCHO 21 TCH TCH TCH TCH TCH TCH TCH
25

TRX 2
Downlink -- Uplink
8 TCHs
FN TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7

0 TCH TCH TCH TCH TCH TCH TCH TCH
12 SACCH SACCH SACCH SACCH SACCH SACCH SACCH SACCH
25
12 SACCH SACCH SACCH SACCH SACCH SACCH SACCH SACCH
25

Scenarios:
Let in a moment that congestion situation arises and lacks of signaling resources, due to network overload. As
all signaling channels are occupied TCHs channels will be dynamically used for signaling purposes exactly
when the last free SDCCH channel will be occupied. The TRX that is going to be used is the one with the less
static SDCCH channels, where an SDCCH/8 will be fitted in the RTSL with the least air-interference in the
uplink. Hence, let that the RTSL 3 of the TRX 2 is the one with the smallest amount of interference, then the
transformation of the subchannels is as follows:
TRX 2 Downlink (Dynamic allocated SDCCH/8 + 7 TCHs)

FN TS0 TS1 TS2 FN TS3 F TS4 TS5 TS6 TS7
N
0 TCH TCH TCH 0 SDCCH0 0 TCH TCH TCH TCH
12 SACCH SACCH SACCH 12 SDCCH3 12 SACCH SACCH SACCH SACCH
25 25 SDCCH6 25
6 TCH TCH TCH 32 SACCH0 6 TCH TCH TCH TCH
12 SACCH SACCH SACCH 38 SACCH1 12 SACCH SACCH SACCH SACCH
22 TCH TCH TCH 48 22 TCH TCH TCH TCH
25 25

Uplink
FN TS0 TS1 TS2 FN TS3 F TS4 TS5 TS6 TS7

N
0 TCH TCH TCH 0 SACH1 0 TCH TCH TCH TCH
12 SACCH SACCH SACCH 12 12 SACCH SACCH SACCH SACCH
25 25 SDCCH2 25
12 SACCH SACCH SACCH 38 SDCCH5 12 SACCH SACCH SACCH SACCH
21 TCH TCH TCH 47 SACCHO 21 TCH TCH TCH TCH
25 25

5.1.1.4 Advantages / Disadvantages:

The feature offers special benefit in traffic cases where signaling is the only transmission mode during the
connection to the network. Short message services (SMS) traffic as well as location updatings are counted
among them. In some special locations such as airport and ports, the location updatings can produce sudden short
time SDCCH traffic peaks, which can now be handled without any need to configure extra permanent SDCCH
capacity for the safe of safety only.
When the floating TRX is an extra capacity use, the static type of SDCCH resources are not allowed to be
configured in it. Otherwise, when a faulty BCCH TRX of some sector has to be replaced with the floating TRX,
the SDCCH resources carried by the floating TRX may be lost in the sector where the TRX was configured
initially. This restriction does not apply to the dynamic SDCCH resources. The working floating TRX is treated
equally with the other TRXs when creating the dynamic SDCCHs. While the floating TRX is moved to another
sector, the lost dynamic SDCCH capacity can be configured to the remaining TRXs when needed. The ISDN
Abis TRXs are treated in dynamic SDCCH allocation equally with the TRXs, which have the fixed 2 Mbit/s
interface based connections to BTS.
The Dynamic SDCCH can be configured both to TRXs of extended and normal range area of the cell. The
definition of which TRX is used is based on which part of the cell area the MS access is received from. The
dynamic SDCCH as well as the static ones can be configured to the TRXs of the regular frequency area only.
Radio network provides information of the function and the duty of the SDCCHs and TCHs. The dynamic
SDCCH brings a new standpoint to the channel specific supervisions because the BSC can occasionally
reconfigure TCH resources for SDCCH use and back to TCHs. The reconfiguration can happen during the same
supervision period.
The supervision data of the dynamic SDCCH is maintained on only during the time and the resources themselves
survive. So at the end of each supervision period the data is available only for those SDCCHs, which have not
been reconfigured back to the TCH. The supervision data of these SDCCHs is handled and interpreted in the
same way as the data related to the static SDCCH resources.
5.1.1.5 Results
With the help of the simulator, and running a simple scenario the results shows that one cell with 23 TCH
channels and 8 SDCCH channels is congested as shown in the next two figures, where the % Blocking
Probability is calculated as well as the utilization of those resources (Before the technique):
Figure 87: TCH- / SDCCH-blocking in normal scenario

Figure 88: TCH- / SDCCH-utilization in normal scenario
Therefore by applying the Dynamic SDCCH technique, the congested cell is reformed the resources as with 22
TCHs and 16 SDCCHs, the result can be shown in the next figure, where the % Blocking Probability is
calculated as well as the as the utilization of those resources (After the applied technique):
Figure 89: TCH- / SDCCH-blocking after application of management technique

Figure 90: TCH- / SDCCH-utilization after application of management technique
As seen from the diagrams the SDCCH utilization drops from 89 % to 25 % where the TCH utilization increases
from 128 % to 140 %.
5.1.2 Half Rate and Full Rate TCH usage
5.1.2.1 General
As we know GSM or DCS are digital systems, where analogue sounds should be converted to digital for
transmission purposes. As the existing ISDN systems are using digital conversion with pulse code modulation
(PCM), the quality for the transmission of voice sound spectrum 0-4 kHz should point to transmission rate of 64
kbit/sec. On the other hand, in GSM systems using this kind of rate would create congestion and the results
would be undesirable. Therefore, instead algorithms for encoding and decoding are introduced to give the
wanted voice quality. The final choice of codecs was the Regular Pulse Excited – Linear Predictive Coder (PRE-
LPC). A mobile discussion is divided into packets of 20 ms and each one of them is 260 bits encoded
information, with a total transmission rate of 13 kbit/s, and called Full Rate speech coding. By dividing the 13
kbit/s by 2, it will give 6.5 kbit/s bit rate and that is the rate which Half Rate coding uses. A new third coding
technique called Enhanced Full Rate has been developed recently with approximately the same voice quality as
in ISDN lines, but with the same bit rate of 1 kbit/s.
5.1.2.2 Description of the technique

TCH allocation control according to cell load is possible if the BTS traffic channel configuration, the resource
situation in the cell and the parameters that the operator has possibly set, do not restrict the TCH allocation. In
order to apply cell load in TCH rate selection the A-interface circuit has to support both TCH rates. If there are
not support for both TCH rates, the A interface circuit has to be changed to one from another circuit pool before
a TCH of the selected rate can be allocated.
If the traffic channel allocation based on cell load is applied, TCH/Fs are allocated until the number of free FR
resources is reduced below a specified lower limit. After this the HR resources are allocated. When the number

of the TCH/F resourced increases above a specific upper limit, TCH/Fs are allocated again. Cell load based TCH
allocation visualizes the affect of the feature on TCH allocation.
This feature controls the TCH allocation for dual rate requests, that is, when both channel rates are acceptable.
For requests that determine a single TCH rate a channel of the respective type is allocated regardless of the
traffic channel load in the BTS.
The feature is applicable for speech and data calls, and signaling with some exceptions. In the speech call case if
HR is set to be preferred rate, the corresponding free permanent TCH resource is allocated primarily, whether the
cell-load-based TCH allocation has been activated or not. In the cases of data and signaling a TCH/H is always
allocated if it is set to be the primary requirement although the cell load does not currently require it.
If the feature is activated and the lower limit is set greater than zero, then at least the last free DR RTSL is split
into two TCH/H channels in TCH allocation. This makes it possible to determine a positive margin for the
TCH/H allocation in cells equipped with only one TRX without making the lower limit unnecessarily high. If the
value of the lower limit equals zero, then TCH/H resource can be allocated for a speech call or data call only if
the MSC strictly requires it, regardless of whether the target BTS has permanent HR resources or not.
5.1.2.3 Parameters
The feature is controlled by two parameters that determine the values of the upper and the lower limit for TCH/F
load in a cell: lower limit for free TCH/F resources and upper limit for free TCH/F resources. These two
parameters can be defined both on the BSC and the BTS level. The limit parameters are given as relative
amounts of free TCH/F resources in proportion to working TCH/F resources. If the upper limit is set smaller than
the lower limit then the affect of the parameters is not taking into account.
The BTS level parameters, if active, are followed in a particular BTS. If not individual channel rate control rules
have been specified in the BTS, the common BSC level parameters are applied. The default values of the
parameters have been set so that the cell load is not initially used.
5.1.2.3.1 Lower Limit for free TCH/F resources

The parameter gives the lower limit percent value of the relative amount of free TCH/F resources. The limit
includes permanent and dual rate types together. If a TCH/F was chosen the previous time the rate determination
dependent on cell load was applied, the relative amount of free TCH/F resources has to be above this limit in
order for a TCH/F to be allocated. If the relative amount of free TCH/F resources is below the lower limit, a
TCH/H has to be allocated. The default value of the parameter is 100%.
5.1.2.3.2 Upper Limit for free TCH/F resources

The parameter gives the upper limit percent value of the relative amount of free TCH/F resources. If a TCH/H
was chosen the previous time the rate determination dependent on cell load was applied, the relative amount of
free TCH/F resources has to be above this limit in order for a TCH/H to be allocated. The default value of the
parameter is 100%
5.1.2.3.3 Channel rate control handover

In addition to the call setup and the external handovers the two TCH allocation thresholds can be applied also in
internal handovers. This can be done, however, only if the handover request does not contain any limitations
concerning the channel rate changes, or if they are not defined on the BSS level.

The parameters that control the channel rate, TCH rate internal handover and TCH rate intra-cell handover,
because the following restrictions for applying the cell load threshold parameters:
if the channel rate changes are denied totally, then they are not allowed due to cell-load-dependent
conditions
if the call-serving type of TCH is indicated to be primarily choice by the parameters and the old channel is a
TCH/H, HR is the primarily rate type also for the new channel independent of the traffic load in the cell.
The other values of the parameters controlling channel rate make it possible to take into account the cell load
thresholds in TCH allocation for internal handovers due to the flexible limitations they determine.
5.1.2.4 Advantages/Disadvantages
1. It is possible to extract resources from the network and more precisely from the BTS itself without any
dramatically changes from point of view of the network. As well, there is more flexibility in the system to
control the choice of the rate that is going to be used and the coexistence of different rates within a TRX.
Moreover, with the use of TCH/HRs the BTS range can be maximized up to 70 km, where 35 km is the standard
range for FR utilization, as the reason is based in the synchronization of the system (Time Advanced)
On the other hand, traffic channels with half rate implemented provide a quality of sound less than the
expectable. Also some mobiles devices are not installed with the HR choice but this is software-based problem,
thus it does not expand the limitations. The implementation of this technique is not suitable for high congestion
situations as the main problem is located in the SDCCH channel.
For example the following supported channel rates for a Mobile Station are:
THR0 : TCH HR subchannel 0

THR1 : TCH HR subchannel 1
TFR : TCH FR
TEFR : TCH EFR
F144 : TCH FR data channel, speed 14.4 kbps
H480 : TCH HR data channel, speed 4.8 kbps, subch 0
FA : TCH FR signaling only (FACCH) channel
FAH0 : TCH HR signaling only (FACCH) channel, subch 0
5.1.3 Forced handover
5.1.3.1 General
The Radio Frequency (RF) power control strategy employed by the BSC defines the RF power command that is
signaled to the MS, and the RF power level that is used by the BTS. The RF power control optimizes the RF
output power of the MS and the BTS and simultaneously ensures that the signal level required at the BTS/MS is
sufficient to maintain adequate speech/data quality.
The RF power level to be employed in each case is based on the measurement results reported by the MS/BTS
and on the various parameters set for each cell.

5.1.3.2 Handover
The handover decisions made by the BSC are based on the measurement results reported by the MS/BTS and on
the various parameters set for each cell.
5.1.3.2.1 Handover causes:

A handover is normally caused by radio criteria but the handover algorithm present is also able to perform
handovers caused by six other reasons:
• The radio network recovery management initiates a forced handover (intra-cell or inter-cell) in order to
empty a cell or a TRX;
• The radio resource management initiates a forced inter-cell handover in order to make room for a high
priority call in situations of congestion, that is, Pre-emption Procedure;
• Due to congestion in the call set-up phase, a handover from a Stand Alone Dedicated Control Channel
(SDCCH) of the serving cell to a Traffic Channel (TCH) of an adjacent cell, that is, Directed Retry;
• The MSC requests the BSC to perform a specified number of handovers from one specified cell to other
specified cells, that is, Traffic Reason Handover;
• A handover from an extended range cell to an inner cell and vice versa, a handover between normal and
extended coverage areas within an extended range cell;
• BSC internal traffic control (for example, a handover from an umbrella cell to a micro cell).
• The BSC uses different handover decision algorithms for handovers caused by normal radio criteria and
handovers caused by other reasons than radio criteria.
When an MS moves from one cell coverage area to another, the radio link measurements show low signal level
(RXLEV) and/or quality (RXQUAL) on the current serving cell and a better RXLEV available from a
neighbouring cell, or the neighbouring cell allows communication with a lower RF power level. The crucial
principle for the BSC selecting the target cells for the handover caused by radio criteria is that the neighbouring
cell must be better than the current serving cell in order for the handover to be useful.
If other reasons than radio criteria cause the handover, it is not necessary for the target cell to be better than the
serving cell. It suffices that the target cell serves the call well enough; for example, a handover from an umbrella
cell to a micro cell is performed whenever the call can be maintained on the neighbouring micro cell.
5.1.3.2.2 Target cell evaluation

The evaluation on the preferred list of the target cells is based on:
Radio link measurements;

Priority levels of the neighbouring cells;
Load of the neighbouring cells, which belong to the local BSS.
First the BSC defines and selects those cells, which meet the requirements for the radio link properties. Then it
ranks the cells according to the priority levels and the load of the neighbouring cells, with the exceptions of the
forced handover procedure, the directed retry procedure and the traffic reason handover procedure when the
BSC ranks the cells only according to radio link properties.
5.1.3.2.3 Handover types

The possible types of handover are the following:
Intra-BTS handover (interference problems);
Intra-BSC handover;
Inter-BSC handover (i.e. MSC performs the handover).

The handover may take place during a call from a Traffic Channel (TCH) to a Traffic Channel. An intra-BTS
handover can take place either to a radio time slot on a new carrier or to a different time slot on the same carrier.
A handover may also take place from a Stand Alone Dedicated Control Channel (SDCCH) to a stand-alone
dedicated control channel during the initial signaling period of call set-up. The parameter EnableSdcchHO
indicates whether the handover from SDCCH to SDCCH is enabled. As far as the algorithm is concerned, the
handover from SDCCH to SDCCH does not differ from the handover from a TCH to a TCH. However, power
budget and umbrella handovers are not performed from SDCCH to SDCCH.
During the call setup phase in situations of congestion (Directed Retry Procedure) a handover can take place
from the SDCCH of the serving cell to a traffic channel of an adjacent cell (the parameter EnableSdcchHO has
no effect on the directed retry procedure).
The handover is synchronized or non-synchronized, depending on whether the cells are synchronized or not.
This information is administered on an adjacent cell-by-cell basis by means of the O & M with the parameter
Synchronized, which indicates whether the adjacent cell is synchronized with the serving cell. The value 'yes'
indicates that the cells are synchronized.
5.1.3.3 Interdependence of handover and power control

The Power Control (PC), for both the BTS and the MS, runs independently in parallel with the handover (HO).
With a proper choice of the PC and HO thresholds, the BSC maintains call quality by means of power control
and proposes handover only when the MS actually reaches the border of the serving cell. If both the HO and PC
threshold conditions are fulfilled, the handover has greater priority than the power control. If the handover
cannot be performed at that very moment, power increase may be used as first aid.
The BSC determines which RF power level the MS that has been handed over will use as the initial RF power in
the target cell. The default initial RF power level is the maximum RF power that an MS is permitted to use on a
traffic channel in the target cell. However, in the case of an intra-BSC handover, the PC/HO algorithm is also
able to optimize the initial RF power level so that the RF power level is lower if the radio link properties of the
target cell are good. Optimization of the MS power level in a handover cuts down the probability of high RF
power peaks in the uplink after HOs. This way it reduces the uplink interference in the radio network. This
property is controlled by the parameters MsPwrOptLevel (n) (inter-cell handover) and the parameter
OptimumRxLevUL (intra-cell handover).
5.1.3.4 Implementation concept

Generally speaking, the software of the BSC is divided into program blocks according to different functions. The
main functions of the handover and power control are divided into two program blocks. The Handover Attempt
Supervisor Program Block (HASPRB) is responsible for the actual performance of the handover, and the other,
the Radio Connection Supervision Program Block (RCSPRB), is responsible for processing the radio link
measurements, the threshold comparison and the decision algorithms of the handover and power control.
The required parameters are stored in the BSS Radio Network Configuration Database. All parameters
controlling the handover and power control are administered either on a cell-by-cell basis or on a transceiver-by-
transceiver basis by means of the O and M; that is, by using the local MMI in the BSC site. By changing the
values of the parameters it is possible to affect the RF power control and handover decisions at all stages of the
procedure, which is during measurement pre-processing, threshold comparison, and the decision algorithm.
5.1.3.4.1 Implementation details of forced handover
5.1.3.4.1.1 Forced handover check

When the RRMPRB receives an ASSIGNMENT or a HANDOVER REQUEST message and all traffic channels
are busy, the RRMPRB checks first in the priority information element of the seizure request if the assignment or

handover is allowed to cause a forced release. If a forced release is not allowed, the RRMPRB checks next if the
seizure request is allowed to cause a forced handover for another call in progress on the BTS. The forced
handover transaction is allowed, if the "pre-emption capability" indicator is set on, the MS priority is set to 2 - 15
in the Priority Information Element and the "queuing allowed" indicator is set on.
In a call attempt, which is allowed to cause a forced handover, the priority element received from the MSC in the
ASSIGNMENT REQUEST message is used. The MSC can prevent the use of the forced handover function for
the call in progress by setting the pre-emption vulnerability indicator off. In an internal handover, the original
Priority Information Element is used. The Priority Information Element is stored during call set-up phase in the
ABIPRB. If the MSC has prevented the forced handover in the original call attempt, the forced release is also
denied in all handover attempts during the ongoing call. In an external handover, the priority element received
from the MSC in the HANDOVER REQUEST message is used.
5.1.3.4.1.1.1 Acknowledgement of successful forced handover

In the case of a successful forced handover the following steps take place:
• A program block (HASPRB or ABIPRB) sends a pre-emptive TCH request for a new call- or handover
attempt
• This request causes the forced handover for another call in progress and the new call gets the released TCH
• RRMPRB then forwards a positive radio resource allocation acknowledgement to the requesting program
block, which initiates channel allocation signaling.
5.1.3.4.1.1.2 Acknowledgement of unsuccessful forced handover

If no channel has been released within the time limit, the RRMPRB sends a negative radio resource allocation
acknowledgement to the requesting program block.
5.1.3.4.1.1.3 Storing forced handover requests

The seizure request, which is allowed to cause a forced handover to another call in progress, is stored in the BTS
Forced Handover Data Structure (BFHFIL). The seizure request is stored in the BFHFIL, providing that there is
space left, a maximum of 8 seizure requests can be stored at the same time for one BTS. When the seizure
request is stored in the BFHFIL, the RRMPRB sends the QUEUING INDICATION message to the service
requesting program block. If the Directed Retry is in use in the BSC, the ABIPRB checks from the QUEUEING
INDICATION message in which queue or data structure the call attempt is stored. If the call attempt is waiting
for forced handover in the BFHFIL, the directed retry will not be attempted. If the seizure request cannot be
stored (i.e. the BFHFIL is full), the channel allocation is given a negative acknowledgement.
When the seizure request is stored in the BFHFIL, the RRMPRB BTS State Data Structure (BSTAFI) is updated
with the information on the number of forced handover seizure requests in that cell, and time supervision is
started. The time limit is a BSC-specific fixed parameter. The seizure requests are removed from the BFHFIL in
chronological order (first in, first out).
5.1.3.4.1.2 Selection of candidate for forced handover

After the RRMPRB has stored the information of the seizure request to the BFHFIL, the RRMPRB selects the
candidate for forced handover. The following main principles apply to the candidate selection:
The candidate has the pre-emption vulnerability indicator set on
The call in progress is not an emergency call
The lowest priority call of the calls in progress is chosen.
The TCH channel rate requirement of the resource request makes the candidate selection procedure more
complicated, especially when the BTS contains dual rate resources and a full rate TCH is requested. The
following three cases are then possible:

• The MS of lowest priority is found among the full rate mobiles

• The MS of lowest priority is found from a half occupied dual rate RTSL
• The MS of lowest priority is found from a dual rate RTSL that also has the other half occupied.
• The following rules apply in the selection of the candidate for forced handover:
• The MS of lowest possible priority is allocated only one forced handover is permitted
In some circumstances the forced handover can be performed inside the cell that is maintaining the candidate call
- a kind of call packing feature generated by the pre-emption:
A full rate call can be handed over from a dual rate RTSL to a free permanent full rate RTSL
A half rate call can be handed over from a half occupied dual rate RTSL to a free permanent half rate RTSL
A half rate call can be handed over from a half occupied dual rate RTSL to another half occupied dual rate
RTSL
If channel rate changes are allowed then full rate call can be handed over to a free half rate resource, and
consequently, a half rate call to a free permanent full rate resource. In these cases the handovers shall be
performed externally, controlled by the MSC if the actual A-interface circuit pool does not support the channel
rate changes. Note also that the FR call must have HR capabilities before it can be moved to a half rate traffic
channel.
When the RRMPRB has found the best suitable candidate for handover, a decision whether the handover is
going to be performed intra-cell or not is made, and the ABIPRB is informed. The ABIPRB starts the required
signaling procedures concerning forced handover.
Negative acknowledgement from RCSPRB

The ABIPRB sends the handover request to the Radio Connection Supervision Program Block (RCSPRB). If the
RCSPRB rejects the handover attempt, it sends a negative acknowledgement message to the RRMPRB. The
RRMPRB checks if the seizure request is still waiting for free resource in the BFHFIL. If the seizure request is
in the BFHFIL, the RRMPRB selects another candidate for a forced handover and gives the information of the
new channel to the ABIPRB. If the seizure request is not in the BFHFIL, the forced handover function is ended.
Negative acknowledgement from HASPRB

The HASPRB sends a handover request to the AIVPRB. If the AIVPRB rejects a handover attempt, the
HASPRB informs the RRMPRB by sending a negative acknowledgement message to the RRMPRB. If the
seizure request is still waiting for free resource in the BFHFIL, the RRMPRB selects another candidate for a
forced handover and gives the information of the new channel to the ABIPRB. If the seizure request is not in the
BFHFIL, the forced handover function is ended.
5.1.3.4.1.3 Successful forced handover

When a TCH releases in the actual BTS, the RRMPRB checks first the BFRFIL. If the RRMPRB does not detect
a seizure request in the BFRFIL, the RRMPRB checks the BFHFIL next. If the RRMPRB detects seizure
requests in the BFHFIL, the first seizure request is removed. The number of forced handover seizure request(s)
in the BFHFIL in that cell is updated in the BSTAFI.
The successful assignment or handover is reported to the requesting program block (ABIPRB or HASPRB),
including the data concerning the radio resource information allocated to it. After that, the program block starts
the required signaling procedures concerning the actual assignment or handover attempt.
5.1.3.4.1.4 Unsuccessful forced handover

If no TCH has been released within the time limit, the TCH service request is rejected due to lack of resources.

5.1.3.4.1.5 Time-out for forced handover

When the forced handover seizure request is stored to the BFHFIL, time supervision is started. The time limit is
a BSC-specific fixed parameter. If the time supervision expires and no TCHs have been released, the RRMPRB
receives a time-out message. The seizure request is removed from the BFHFIL. The number of TCH requests
that are allowed to cause a forced handover is updated in the BSTAFI. Unsuccessful assignments or handover
attempts are reported to the requesting program block (ABIPRB or HASPRB) as a negative acknowledgement to
the channel seizure request with the cause "no resource available".
5.1.3.4.1.6 Statistics counters for forced handover

When the RRMPRB receives a seizure request attempt, which is allowed to cause a forced handover for another
call in progress, the statistics counters are updated. Assignment request attempts and handover request attempts
have their own individual counters.
When a TCH request, which is allowed to cause a forced handover for another call in progress, is rejected due to
lack of released channels, the statistics counters are updated. Assignment request failures and handover request
failures have their own individual counters. When the seizure request, which caused a forced release for another
call in progress, gets a TCH, the statistics counter is updated. These counters are BTS-specific.
5.1.4 TRX prioritization in TCH allocation
5.1.4.1 General
Sometimes it can be useful to favor the BCCH carrier in call assigning. A reason for it is that as the BCCH TRX
is transmitting in all RTSLs all the time, the allocation of TCHs primarily from the BCCH carrier does not
increase the network interference. Another reason can be the quality of the BCCH TRX channels in those cases
when the BCCH carrier frequencies are not reused as efficiently as the other carriers. Thus the quality of the
TCH channel from a BCCH TRX is better as the C/I ratio is better.
RF hoping can reduce the average interference experienced by he MS. RF hoping cannot be applied in the
BCCH carrier, and therefore for quality reasons it is sometimes reasonable to assign a call priority to the other
TRXs than the BCCH carrier. However, RF hoping actually makes it possible to reuse the non-BCCH carrier
frequencies more frequently, so the favoring of the BCCH TRX due to uplink interference can still be
reasonable.
Priority setting between the BCCH TRX and the other carriers in TCH allocation is general GSM feature of the
BSC. The feature is not applied in super-reuse TCH allocation for underlay-overlay handovers.
5.1.4.2 Description of feature

The normal practice in traffic channel allocation for a call is that when no quality requirements are stated, then
an attempt is made to allocate the TCH of least uplink interference. The TRX from where the channel is going to
be allocated is determined then by the TCH resource situation in each TRX as well as the rotation of resources in
TCH allocation. Similarly when a TCH fulfilling specific uplink quality requirements is searched for, none of the
TRXs or TRX groups is given priority.
Allocation of traffic channels from specific preferred group of TRXs is reasonable if the TCHs of the group do
not have too much interference. Calls that are assigned to a channel under heavy interference can be dropped and
those channels can e allocated again for others calls, with the same consequences. Applying in TCH allocation
the method of the minimum acceptable uplink C/N ratio offers sufficient protection against these cases.

Priority setting between the BCCH carrier and the other TRXs can be determined in two ways. The
determination depends on how the maximum acceptable level of uplink interference for the TCH to be allocated
is evaluated.
When the measurements to determine the minimum acceptable plink C/N ratio are not performed by the BSC, or
the MSC has set its own interference level requirements, then the decision of the plink interference of the TCH
to be allocated is made by using merely the BTS-specific idle TCH resource information. Channels with least
interference are selected to be the target of the TCH allocation. A TCH is allocated primarily either from the
BCCH TRX or from the group of the other TRXs of the BTS depending on which one is set as preferred. If a
suitable channel cannot be found from the preferred group, then it must be allocated from the secondary group.
The quality of the TCH to be allocated is actually determined here before the selection between the BCCH
transceiver and the other TRXs is made. Because the actual interference tolerance of the call is unknown, the
best quality channel is allocated for it.
When the interference band requirement on the recommendation evaluated by the BSC from the principle of the
minimum acceptable C/N ratio, then the decision of the quality of the TCH to be allocated is first based on the
plink interference information of the TCH resources of the preferred TRX group. This information is compared
with the evaluated interference band recommendation. When the preferred TRX group has a channel of
acceptable interference, then the TCH which fulfils the quality requirements best is allocated from there. When
all TCHs of the preferred TRX group are over the recommended interference level, then the channel, which
keeps the conditions best, is allocated from the free TCH resources of the BTS.
The feature is applied to every resource request concerning a TCH of the regular frequency area. However, in
intra-BTS handover cases the TCH is allocated primarily from another TRX that the one which maintains the
call. When such a TRX can be found from the preferred TRX group the TCH is allocated from there.
The TRX priority setting method can be applied by adjusting a BTS-specific configuration parameter
TrxPriorityInTCHAllocation.
5.1.5 Dynamic cell resizing with the use of C values
5.1.5.1 General
The technique of cell selection is based on the idea that the mobile station should be within the cell offering the
best coverage. As previous, in dedicated mode this is handled by handovers, but in idle mode the mobiles station
has to find the best coverage cell in each area. This process is called Cell Selection and is based upon the
comparison of two values C1 or C2. This method can be seen as “cell-breathing” in GSM systems for users in
idle-mode.
5.1.5.2 Parameters
The idea is that the mobile compares field strength levels coming from different cells within an area and selects
the best one from them. The mobile uses the cellReselectHysteresis (0…14 dB) parameter to avoid the “Ping
pong” phenomenon, which means that before the Mobile changes cell in idle mode, the field strength level of the
better cell has to be set at least the value of cellReselectHysteresis better than the value of the serving cell. The
equation of the cell selection is as follows:
Cell selection in idle mode based on C1, Radio criteria (Path loss criterion – GSM Phase 1)
C1 = (RX- RxLevAm- MAX (MSTxPwr-MSMaxPwr), 0)), where:
RX is the signal level that the mobile station receives from the FCCH channel,
RxLevAm (Rx Level Access minimum): Is the minimum allowable signal level, which the mobile station may
use the cell. This value is implemented from the operator and the values depend on the type and the role of the
antenna.

MSTxPwr: Is the maximum allowable power that the BTS permit the mobile station to gain access on the RACH
channel.
MSMaxPwr: Maximum RF Power of the Mobile Station
Thus as seen above, the mobile station takes into account the minimum access level to the cell and the maximum
transmitting power allowed to the Mobile in each cell when starting a call.
Cell reselection criterion based on C2 (GSM Phase 2)
In comparison based on C2, a couple of more parameters are needed. The parameter cellReselectParamInd
(Yes/No) becomes activate, if C2 parameters are sent to the Mobile (activates C2) and the parameter
cellBarQualifty (Yes/No) controls if the cell barring can be overridden.
The rest of the C2 parameters are related to the microcellular planning. Parameter penaltyTime (20…640s)
describes the time delay before the final comparison is made between two cells. Parameter temporaryOffset
(0…70 dB) describes how much field strength could have dropped during this penalty time, and parameter
cellReselectOffset (0…126 dB) describes an offset to cell reselection. C2 cell reselection is calculated by
equation:
C2 = C1 + cellReselectOffset – temporaryOffset * H(penaltyTime – T) , penaltyTime ≠ 640

C2 = C1 - cellReselectOffset, penaltyTime = 640
Where H(x) = 1 when x < 0,

and H(x) = 0 when x ≥ 0
Cell Reselect Offset: this parameter is used often for micro cells with such an offset value so that mobile station
will lock to a certain cell, e.g. the value 24 dB aims for micro cell architecture that is covering in-house places
and general busy spots.
Temporary Offset: Can be changed dynamically by the operator to allocate the traffic load to other BTS.
If the C2 values of a neighbour cell, from the six (6) available, is bigger than the value of the serving cell for
time duration of more than 5 seconds, then the Mobile Station has to change cell. Focus has to be set as the entire
above are valid only when the Mobile Station is in Idle Mode and tracks the CCCH channel, paging channel
(PCH).
Moreover, exception is given also when the neighbour cell resides into a different location area, thus all the
above cannot happen. However, if the Mobile Station has to switch to a neighbour cell of a different LA, then the
requirement is that:
C2 > C2 + Cell_Reselect_Hysteresis
As well as, if the Mobile Station has switch to another cell in the last 15 seconds then the value C2 of the new
cell has to be 5 dB more than the value of the previous cell.
5.1.5.3 Implementation
Let that a Mobile Station is locked in an overload cell. The operator sets the parameter TemporaryOffset of the
neighbour cells (where the traffic load of these cells is normal), so that the Mobile Station could switch to these
cells, in order to serve a mobile originated or terminated call. The idea of cell reselection is based upon cell
congestion as well as cell overlapping. On the other hand, depending on the value of that parameter, possible
problem arises as extra signal load is created as Mobile Station prompt to lock into BTS in different LAC.
5.1.5.4 Example
The network consists of two cellular layers: GSM macro layer and microcellular layer. In order to prevent
unnecessary camping between layers, C2 will be introduced. The idea is: the micro cell, having good downlink

signal strength and therefore very attractive, has to belong to one of the best cells of the neighbour list at list for
the time set as penaltyTime 20 seconds, in order to allow the Mobile Station to camp on that micro cell.
The parameter temporaryOffset has been set to be 30 dB and cellReselectOffset has been set to 20 dB. Let also
that the measured value of C1 is 32 therefore two alternatives cases are possible:
During time 0 … 19 seconds, that is within the penaltyTime:
C2 = C1 + cellReselectOffset – temporaryOffset * H(penaltyTime – T)

C2 = 32 + 20 – 30*1
C2 = 22
Therefore the Mobile Station will be kept in macro layer; the target cell is not attractive.
During time 20 … ∞ seconds, that is over the penaltyTime:
C2 = C1 + cellReselectOffset – temporaryOffset * H(penaltyTime – T)

C2 = 32 + 20 – 30*0
C2 = 52
Therefore the target cell is very attractive and the idle mode Mobile Station will camp on the micro cell.
Therefore the target cell is very attractive and the idle mode Mobile Station will camp on the micro cell.
As not yet implemented in the excel simulator file this technique, cell resizing with the use of C values, using
another simulator called “WINPROP” the followed results show how powerful are these C values:
Figure 91: Cell-breathing effect in idle-mode
The green area with the square box is the congested cell. So by applying the technique at the congested cell:
Temporary offset –6 dB and Penalty time 20 sec therefore we have:

Also if those two values are changed to: Temporary offset –12 db and Penalty time 20 sec. the result is shown in
the next figure:

5.1.6 Bandwidth reservation
5.1.6.1 General
Trunk reservation (TR) is a stochastic algorithm employed in channel allocation from a cell. The initial purpose
of the feature is to allow the shared use of traffic channel resources of a BTS by GSM and MCN users. The
algorithm retains the tuning of the grade of service provided for the users of the two networks. The scheme
ensures that the overload of the TCH resource in one network will not necessarily lead to congestion in the other
network. The two networks can thus be dimensioned to offer different grades of service simultaneously.
5.1.6.2 Parameters
Trunk reservation can be applied both to mobile originating and to mobile terminating calls. Handovers can also
be treated as one traffic class, and the availability of a channel in a cell will thus be determined with the help of
the stochastic algorithm.
After the access is granted to a subscriber in a specific BTS, a traffic channel is allocated for the MS by applying
the BSC’s internal algorithms that do not depend on trunk reservation. The trunk reservation scheme is realized
within a BSC, and is thus an entirely internal procedure. The micro cellular network (MCN) service area is a
subset of the GSM service area. GSM subscribers are allowed to camp on MCN cells, so the micro cells must
therefore provide traffic channels resources for both MCN and GSM use. Each kind of access attempt to a call
made by an MS is considered to be one of the traffic types defined to the cell. The traffic types are determined by
the services provided, plus the corresponding subscribers’ characteristics. A decision threshold is defined as a
function of the number of currently free radio resources, that is, idle traffic channels and service types. When the
trunk reservation algorithm is applied, a random variable R is compared with a threshold to find out whether a
free traffic channel is available for a requester representing a specific traffic type.
The random value R is uniformly distributed between 0 and randomValueLimit and regenerated for each
request. Possible values (Xij = decisionThresholdValues) of the threshold can be presented as a table:
Table 35: Threshold values

TTRAFFIC TYPE
IDLE TCHs
1 2 …
1 10 5
2 20 10
3 30 20 Xij
… … …
Q XQ1 XQ2
Access is granded only if R < Xij, with i and j corresponding to the number of free channels and traffic type
respectively. Access can therefore be rejected even though there are idle channels left. If more than Q channels
are free (freeTchLimit), all access attempts are granded.
5.1.6.3 Example
GSM user tries to make a call (traffic type 2). We have three free TCHs in the cell. Due to the fact that only a
few TCHs are available (Q can be max 16) BSC will use the decision threshold table Xij. According to the above
table Xij = 20%. BSC will use the random value R to be compared with Xij = 20%. R value is random that is why
we could have the following two alternatives cases:
if R = 8% => R<Xij i.e. 8<20 is true => call attempt will be successful
if R = 73% => R<Xij is not true i.e. 73>20 => call attempt will be terminated.

Note that the decision threshold table can be defined on the cell basis; this will give a great opportunity to affect
traffic distribution.
There are two exclusive methods of distinguishing between different subscribers types. The distinction can be
made according to the power capability class of the Mobile Station or according to the priority level of the
service request given by the MSC. In this part the concept “priority level” means the priority level of the service
request given by the MSC and received by the BSC in the Assignment or Handover requests. The priority
subscribers’ type is available only if the latter method is used in the BSC. The user can select the method with a
BSC specific parameter.
The power capability class is indicated in the MS class mark. The possible values vary from 1(the highest power
level) to 5 (the lowest power level). The priority level cab has several values between 1 (the highest priority) and
14 (the lowest priority).
5.1.6.4 Priority subscriber type

Employing new subscriber types means that the analogy between subscriber type and network is no longer
explicit, that is, subscribers of different networks can represent the same subscriber type. The service separation
is based on the priority level.
This kind of a subscriber type, where subscribers can belong to either a GSM or a MCN network, is the priority
subscriber type. Priority subscriber type subscribers are the only subscribers who are able to access a certain
amount of reserved priority channels (nbrTVHForPrioritySubs) in the cell.
When the number of priority channels is defined to zero and the “priority” traffic types are attached to decision
threshold tables.
Trunk reservation gives the possibility to use two alternative reservation methods (reservationMethods) of
traffic channels: static and dynamic. The reservation method is of significance only if the priority subscriber
traffic type is employed in the BSC.
5.1.6.4.1 Static reservation method

In static reservation, once the priority has been allocated to priority subscribers, the remaining spare channels are
available to other subscribers. Thus, in static reservation the number of channels reserved for priority subscribers
is actually the number of simultaneous priority calls, which the BTS is able to transmit.
5.1.6.4.2 Dynamic reservation method

In dynamic reservation the number of channels for priority subscribers means the number of channels that have
to be left available to the priority subscribers only, no matter how many ongoing priority calls there are in the
BTS.
The selection between static and dynamic reservation of traffic channels is made on a per cell basis. The
reservation method can also be defined to apply only to call set-up, and in that case in an incoming handover the
priority channels are available to all subscribers.
The queuing procedure is never applied to resource requests that have been rejected by the trunk reservation
algorithm. In other words, although queuing would be allowed in a cell for a call setup or for handover, the
resource request will not be put to queue if it represents a non-trivial traffic type and the trunk reservation
algorithm has denied access to the requested resources. The access attempt is then rejected due to congestion in
the BTS (no idle traffic channels) or by the stochastic algorithm.

If the access attempt has already been accepted by the trunk reservation algorithm or by some other procedure,
but no TCH meeting the extra requirements (interference band request, etc) is available at that moment, the TCH
request can be put to queue if that is allowed.
5.1.7 eMLPP
5.1.7.1 General
The enhanced Multi-Level Precedence and Pre-emption (eMLPP) feature enables network operators to define
different priority levels for calls, on the basis of a set of analysed attributes, for call set-up and for call continuity
in case of handover. Using this priority feature, the network can release (or put in a queue) certain connections in
Air-Interface during a congestion situation, provided that this possibility has been defined in the beginning of the
connection. According to the GSM standards, priority may be used in two procedures for the traffic channel
allocation; these are the ASSIGNMENT and the HANDOVER procedure.
The eMLPP feature has obviously two parts: (a) precedence, involving assigning a priority level to a call, and (b)
pre-emption, involving the seizing of resources by a higher-level precedence call in the absence of idle
resources.
eMLPP shall be applicable also in case of roaming, if supported by the related networks. The maximum
precedence level of a subscriber is set at the subscription time by the service provider, based on the subscriber's
needs. The subscriber may select a precedence level up to the maximum level subscribed to on a per call basis
(provided that he/she has an eMLPP-compatible Mobile Terminal).
5.1.7.2 Parameters
The main features of the eMLPP are listed in the following sections.
5.1.7.2.1 The 7 eMLPP Priority levels

The two highest levels are reserved for network internal use, e.g. for emergency calls or the network-related
services, such as specific voice broadcast or voice group call services. These two levels can only be used locally,
i.e. in the domain of one MSC. The other five priority levels are offered for subscription and can be applied
globally, e.g. on inter-switch trunks, if supported by all related network elements, and also for networking with
ISDN networks providing the MLPP service. The seven priority levels are defined as follows:
• A (highest, for network internal use)

• B (for network internal use)
• 0 (for subscription)
• 4 (lowest, for subscription)
Levels A and B shall be mapped to level 0 for priority treatment outside of the MSC area in which they are
applied.

5.1.7.2.2 Priority Call Scenarios
5.1.7.2.2.1 Mobile originated calls

The priority level depends on the calling subscriber.
If the user has no eMLPP subscription, the call shall have a default priority level defined in the network.
If the user has an eMLPP subscription, the call shall have the priority level selected by the user at set-up or
the priority level predefined by the subscriber as default priority level by registration.
5.1.7.2.2.2 Mobile terminated calls
The priority level depends on the calling party. For this, interworking with the ISDN MLPP (Multi-Level
Precedence and Pre-emption) service is required.
If the call is not an ISDN MLPP call, i.e. no priority level is defined; the call shall be treated in the mobile
network with a default priority level.
If the call is an ISDN MLPP call, the call shall be treated with the priority level provided by the interfacing
network.
5.1.7.2.2.3 Mobile-to-mobile calls in case of Roaming

The priority shall be treated for the calling subscriber as for mobile originated calls and for the called
subscriber as for mobile terminated calls.
5.1.7.2.2.4 Mobile-to-mobile calls in one network

The priority shall be treated for the calling subscriber as for mobile originated calls and for the called
subscriber as for mobile terminated calls.
5.1.7.2.3 The 3 classes of set-up time performance

Examples of the call set-up times are:
Class 1 fast set-up (1-2 sec).
Class 2 normal set-up (< 5 sec).
Class 3 slow set-up (< 10 sec).
Calls with a high priority requiring a class 1 set-up may not require authentication at call set-up nor
confidentiality on the radio link.
The network shall have the possibility to pre-empt on-going calls with lower priority. This is done for
precedence calls, in ascending order of priority, in case of congestion at set-up on the radio interface or the GSM
network side, respectively, or at handover of the precedence call to a congested cell. In case of necessary pre-
emption of another on-going call at set-up, the successful call set-up may exceed the set-up time performance
defined under (C) but shall be completed as soon as possible.
A call can be pre-empted any time after the precedence level of the call has been established and before call
clearing has begun.
Pre-emption shall only be performed to provide precedence for those priority levels, which have a pre-emption
capability, allocated by the network operator. Priority levels with no pre-emption capability shall only have
queuing priority.
5.1.7.3 Set-up classes and pre-emption capabilities to priority levels.

The network operator can allocate set-up classes and resource pre-emption capabilities to each priority level.
Table 36 presents an example for the assignment of priority levels and the corresponding parameters.

Table 36: Example on eMLPP Service Composition

Priority Level Set-Up Time Pre-emption Examples
A Class 1 Yes Voice Broadcast Service/Voice Group
Call Service
B Class 2 Yes Operator Calls
0 Class 2 Yes TS12 Emergency Calls
1 Class 3 Yes Premium Rate Calls
2 Class 3 Yes Standard Rate Calls
3 Class 3 Yes Default for no eMLPP Subscription
4 Class 3 Yes Low Tariff Calls
Network operators, which provide the eMLPP service for subscription, need to consider the interrelation of the
number of subscriptions offered (possibly restricted for particular users), the technical performance and the
network planning issues in order to guarantee the service performance for the subscriber.
A subscriber shall be able to set his mobile station to automatically answer a call. This is done if the incoming
call is of or exceeds a defined priority level, respectively. In case of called mobile subscriber busy, the on-going
call shall be pre-empted (or set automatically on call hold by the mobile station in case of telephony and if the
subscriber is entitled to call hold services) to accept the incoming call with the priority defined for automatic
answering. If the on-going call is a point-to-point call, this function is only possible if the subscriber has a
subscription for Call Waiting (CW).
5.1.8 Location update
5.1.8.1 Description
Presently, the location method most widely implemented in the first- and second-generation cellular system
(NMT, GSM, IS-95, etc.) makes use of location areas (LAs). In these wide-area radio networks, location
management is done automatically.
Location areas allow the system to track the mobiles during their roaming in the networks: subscriber location is
known if the system knows the LA in which the subscriber is located. When the system must establish a
communication with the mobile, the paging only occurs in the current user LA. Thus, resource consumption is
limited to this LA; paging messages are only transmitted in the cells of this particular LA.
Implementing LA-based methods requires the use of databases. Generally, a home database and several visitor
databases are included in the network architecture. There are also several locations updating methods that can be
implemented based on LA structuring.
The LA-based location management methods are the most adapted and widely used in current cellular (GSM, IS-
54 and IS-95). Nevertheless, the traffic and processing generated may lead to congestion problems in high-
density systems. One of the main concerns of the system designers is therefore to define methods allowing the
system to reduce the overhead traffic as much as possible.
Location Update procedure is divided into periodic and non-periodic location updates. Periodic location update,
aims to keep a back up of the system in case of network failure, but on the other hand increases the congestion
on the system resources.
5.1.8.2 Periodic location updating

This method is simplest because it just requires the mobile to periodically transmit its identity to the network. Its
drawback is its resource consumption, which is user dependent and can be unnecessary if the user does not move
from a LA for several hours. The location update described by parameters is time periodic and carried out by the

Mobile Station. It is used to check that the location information in MSC/HLR is correct, because by error in the
MSC/HLR, the location information of Mobile Station can disappear. Time periodic location update is controlled
by the timer timerPeriodicUpdatesMS (0.0 … 25.5 hours). Generally, this method is combined with the next
one.
5.1.8.2.1 Location updating on LA crossing

This method first requires each BS to periodically broadcast the identity of its LA. Second, the mobile is
required to permanently listen to network broadcast information (on the broadcast channel) and to store the
current LA identity. Of the received LA number differs from the stored one, a location update (LU) procedure is
automatically triggered by the mobile.
The advantage of this method is that it only requires LUs when the mobile actually moves. A highly mobile user
will generate a lot of LUs; a low mobility user will only trigger a few.
A hybrid method, which combines the two previous ones, can also be implemented. The mobile generates its
LUs each time it detects a LA crossing. Nevertheless, if no communication (related to a LU or a call) has
occurred between the mobile (in idle mode, i.e., powered on but not communicating) and the network for a fixed
period, the mobile generates a LU. This periodic LU typically allows the system to recover user location data in
case of a database failure.
5.1.8.2.2 Location Update vs. Paging
Location management schemes are essentially based on users' mobility and incoming call rate characteristics.
The network mobility process has to face strong antagonism between its two basic procedures: location and
paging. The location procedure allows the system to keep the user's location knowledge, more or less accurately,
in order to be able to find him, in case of a coming call, for example. Location registration is also used to bring
the user's service profile near its location and allows the network provide him rapidly with his services. The
paging process achieved by the system consisting of sending paging messages in all cells where the mobile
terminal could be located. Therefore, if the location cost is high (and thus the user location knowledge is
accurate), the paging cost will be low (paging messages will be only be transmitted over a small area) and vice
versa. The IMSIAttachDetach (Yes/No) parameter is used to decrease signaling load. The Mobile Station sends
a message to MSC telling if it is switched on or off. When the MSC knows that the Mobile Station is switched
off does not try to page it, and useless paging is avoided.
5.1.8.2.3 Implementation
An HLR (Home Location Register) where all subscribers’ related information is stored (access right, user
location, etc.). Security parameters and algorithms are managed by the authentication center (AuC) which is
often considered part of the HLR. Also there are several VLRs. Each VLR stores part of the data regarding the
users located in its related LAs. The location management method defined in GSM combines the periodic LU
method and the LU on the border crossing. The VLR stores the LA identifier, and the HLR stores the VLR
identifier. This consists of three main types of LU procedures: The intra-VLR LU, the inter_VLR LU using
TMSI (temporary mobile subscriber identity), and the inter_VLR LU using IMSI (international mobile
subscriber identity). A fourth one, the IMSI attach procedure, is triggered when the mobile is powered on in the
LA where it was powered off. In the following, we present the most complete LU, which is inter_VLR using
MISI.
This procedure mainly consists of the following steps:

A signaling channel is allocated to the MS, and a LU is requested. The MS provides the network with its IMSI,
which allows the new VLR (VKR2) to load authentication data from the HLR/AuC, mainly the triplets for the
authentication and the ciphering procedures. The VLR is then able to authenticate the MS; if this step succeeds,
it updates the location at the HLR. The HLR informs the old HLR (VLR1) to remove the user's data stored in

VLR1. Ciphering may be required id available. A new TMSI is allocated to the MS, and, after acknowledgment
of its LU request (first message sent by the MS), the channel finally released
5.1.8.2.4 Example
For the Periodic location update it has been shown that the only way to change this effect and to minimize the
congestion that is produced , is from the timer, as described above, timerPeriodicUpdatesMS (0.0 … 25.5
hours). This value was set to 1 hour and has been changed to 4 hours, and had as result the decrease of the share
of the periodic location updates (LU) compared to other LUs (intra/inter VLR, home/roamer subscriber). The
results in more details are: from 99.8% to 99.5% in LU, see next figure.
Figure 94: Location update attempts – Location update Success Rate
On the other hand, the effect of the paging is presenting below. The effect shows a small increase, about 0.5 %,
which can be interpreted as a negative effect of the change.
Figure 95: Paging success rate- location update attempts

However, this change aim to decreases the congestion that arises in SDCCH control channel. It is known that
Call request and SMS request as well as Location Update are the main causes for seizing an SDCCH channel;
therefore the change would expect to have positive impact to SDCCH performance, as it is shown in Figure 96.
Figure 96: SDCCH causes share
As a result, this has led to decrease of the total SDCCH traffic more than 10 % as shown in Figure 97.
Figure 97: Location update attempts – SDCCH Traffic
5.1.9 Queuing
5.1.9.1 Description
The purpose of radio resource queuing in the BSC is to increase the number of successfully completed calls in a
temporary congestion situation in the BTS and thereby to increase radio network efficiency.

Radio resource queuing enables the setting of the radio channel request to the queue, and when a suitable radio
resource is available again, the interrupted call setup can be continued. Consequently, there is no need to cut-off
started transaction owing temporary radio channel congestion in the actual BTS.
The queued radio resource is always a TCH, never an SDCCH. The queued seizure request can be a call setup,
mobile originating call (MOC) setup or mobile terminating call (MTC) setup, or a handover attempt (all GSM-
specified handover types). The queuing contains specific priority management and statistical functions.
5.1.9.2 Parameters
Radio resource queuing in the BTC is always a BTS-specific procedure and it is non-optional feature. The BSC
has a specific queue for every BTS and for every queue type in each cell.
Three different queue types are implemented:

Call queue
Used when MOC or MTC attempts are queued for.
Handover queue for urgent handovers

Used when an urgent handover attempt is queued for; urgency is determined by the initial cause of the
handover.
Uplink/downlink interference
Uplink/downlink quality
Uplink/downlink level
Handover initiated due to rapid field drop
MS-BS distance exceeding cell boundaries
MS-BS distance causing handover from extended range cell to inner cell
MS-BS distance causing handover from inner cell to extended cell
Forced handover in order to empty cell
Handover from super-reuse to regular frequency are due to bad C/I ratio
Handover initiated in order to switch A interference circuit pool
Handover of fast-moving MS from lower layer cell to upper layer cell.
Handover queue for non-urgent handovers

Used when a non-urgent handover attempt is queued for. Handover causes treated as non-urgent are
Power budget handover
Umbrella handover
Handover of slow-moving MS from upper cell to lower layer cell
MSC controlled traffic reason traffic
BSC controlled traffic reason traffic
These three logical queues are carried out with one BTS-specific physical queue. The handover attempt can be
internal intra-cell, internal inter-cell or external handover. External handovers, however, are always treated as the
urgent ones when the actual handover cause information has not been received by the target BSC from the A
interface.
Note that the following handover attempts are not queued:

Handovers from regular to super-reuse frequency area corresponding to the cause “Good C/I ratio”
Handovers related to Directed Retry or Intelligent Directed Retry
Handovers initiated by the pre-emption procedure
It is possible to handle the queuing parameters and management via the OMC and/or local MMI. By means of
parameters it is possible to manage the queuing on a cell-by-cell basis, as well as to determine the queuing
characteristics. The following parameters are used:
Allowed queue length
Queuing time of the call queue type which is equal for MOC and MTC
Queuing time of the handover queue type which is equal for urgent and non urgent handovers
Priority management

Queue type priority: possibility to prioritize between the queue types

Call queue
Handover queue for urgent handovers
Handover queue for non-urgent handovers
MSC informed priority (MS priority): possibility to prioritize between queue elements
The queue type priority and MSC informed priority could be set on or off
5.1.9.3 List of parameters
The queue characteristics are defined with the aid of the BTS object class parameters. The parameters can be
handled by a specific queuing parameters modifying command (EQH) of the Base Transceiver Station parameter
Handling MML (PBTHAN).
Parameters can also be handled from the OMC via the Q3.
The following parameters have been defined:

Maximum queue length (maxQueueLength)
Maximum queue length in the actual BTS (in percentage format) specifies the number of call attempts and
handover attempts waiting for a TCH release in the BTS. If the value is set to zero, TCH queuing is not
possible in that BTS.
Time limit for call queuing (timeLimitCall)

The maximum queuing time for call attempts (MOC or MTC) in the actual BTS. If the value is set to zero,
call attempt queuing is not active in that BTS.
Time limit for handover queuing (timeLimitHandover)

The maximum queuing time for handover attempts (all handover types and handover reasons) in the actual
BTS. If the value is set to zero, handover attempt queuing is not active in that BTS.
Queue type priority for call attempt queuing (queuingPriorityCall)

Specified priority for the call queue type in the actual BTS. Queue type prioritisation enables different
priorities between call attempt and handover attempt queuing.
Queue type priority for urgent handover attempt queuing (queuingPriorityHandover)

Specified priority for the urgent handover queue type in the actual BTS. Queue type prioritisation enables
different priorities between call attempt and handover attempt queuing as well as between urgent and non-
urgent handovers queuing.
Queue type priority for non-urgent handover attempt queuing (queuePriorityNonUrgentHo)

Specified priority for the non-urgent handover queue type in the actual BTS. Queue type prioritisation
enables different priorities between call attempt and handover attempt queuing as well as between non-
urgent and urgent handovers queuing.
MSC informed priority (MS priority) is taken into account; YES/NO

(msPriorityUsedInQueuing)
Tells whether the priority data for the message element priority in the messages ASSIGNMENT REQUEST
and HANDOVER REQUEST is taken into account in the queue management of the BTS.
Queue type priority is taken into account; YES/NO

(queuePriorityUsed)
Tells whether the queue type priority (queuingPriorityCall, queuingPriorityHandover and
queuePriorityNonUrgentHo attributes) is taken into account in queue management in the BTS.

5.1.9.4 Implementation
Radio resource call control management in the DX 200 BSC (radio channel allocations, releases and queuing) is
totally controlled by and performed in the Radio Resource Management Program Block (RRMPRB). The radio
resource queuing algorithm and pre-emption procedures (forced release and forced handover) are realised as a
program sub-block which contains several subroutines. The program sub-block is controlled by the main
RRMPRB radio resource manager. The main RRMPRB handles the message interfaces with other program
blocks involved, as well as the data processing in the input transitions. The RRMPRB is located in the Marker
and Cellular Management Unit (MCMU).
5.1.9.5 Main program blocks

In addition to the RRMPRB, the following program blocks are mainly involved in the radio channel queuing and
pre-emption procedures:
BSC Configuration Updating Program Block (GUPDAT)
The GUPDAT handles the BTS configuration updating procedures to the RRMPRB, for instance, TRX
creating/deleting and blocking/deblocking functions, and BTS queuing parameter updating.
Abis Interface Program Block (ABIPRB)
The ABIPRB handles the Abis interface signaling. It requests radio channels from the RRMPRB, and also
releases them. The ABIPRB updates the idle radio channel interference band information received from the BTS
to the RRMPRB.
Handover Attempt Supervisor Program Block (HASPRB)
The HASPRB supervises handover attempts. It sends channel requests to the RRMPRB, and sometimes also
releases them in case of failure. If a handover attempt is interrupted during queuing, the HASPRB can send an
order to remove the queue to the RRMRPB.
A Interface Signaling Program Block in BSC (AIVPRB)
The AIVPRB is responsible for interface management between MSC and BSC.
5.1.9.6 Pre-emption and queuing functions

MCMU switchover during pre-emption and queuing
The Marker and Cellular Management Unit (MCMU) are duplicated. The state of the RRMPRB in the spare unit
can be changed to active in whichever situation without affecting the active calls. Calls at set-up phase can
break.
The pre-emption and queued transactions are set-up phase connections, and are not updated and maintained in
the spare unit. If the MCMU switchover occurs during pre-emption or queuing, there is no real time pre-emption
or queuing data available in the new working unit, and the RRMPRB cannot send an acknowledgement
concerning the pre-emption attempt or queuing. The process instances (ABIPRB or HASPRB hands), which
have requested pre-emption or queuing services, are released autonomously when the time supervision for the
acknowledgement from the RRMPRB expires. The pre-emption call attempts and queued call attempts are then
cleared. The pre-emption handover attempts and queued handover attempts are interrupted, and calls will
continue on the original radio channels.
5.1.9.7 Queuing possibility

The target BTS used for queuing can vary depending on the request type. One queuing target BTS is possible in
the following cases:
Call attempt; the actual BTS is used as the queuing target
Internal intra-cell handover: the actual BTS is used as the queuing target
External cell handover (target BSC); the BTS identified by the MSC in a HANDOVER REQUEST message is
used as the queuing target.
As far as the internal inter-cell handover is concerned, it is possible to use more cells (sixteen at the maximum)
as alternative target cells in radio resource allocation. The handover candidate BTSs for the channel search is

chosen from the candidate cell list created by the handover algorithm, and are then forwarded to the RRMPRB.
From these BTSs, the RRMPRB searches for a free radio resource in order of their superiority over each other.
In case the entire base stations in the list are congested, the queuing possibility in the candidate BTSs is checked
using the same order as in the allocation procedure.
Consequently, in this handover type choices are given to the RRMPRB in order to increase the possibility to get
the required free radio resource, either immediately or after queuing.
5.1.9.8 Queue management

Queuing is used when the BSC receives an assignment or a handover request from the MSC and all traffic
channels are busy or there are no TCHs of the requested kind available. If this seizure request is not allowed to
pre-empt an existing connection, the BSC checks the priority information element and, on the basis of the
"queuing allowed" indicator, it may initiate queuing.
5.1.9.9 Use of priority element in queuing

In queue handling, one of the most important pieces of information concerning the queued seizure request is the
priority of the queue element. This queue element priority consists of the MS priority and the queue type
priority.
The SEIZURE REQUEST messages to the RRMPRB contain the MS priority information, which is the priority
value determined by the MSC. The queue type priority is a BTS queue parameter that also affects the queuing
algorithm function considerably. In general, the handover queue type is set to have a higher priority than the call
queue type, because handovers deal with already existing call connections.
5.1.9.10 BTS queue length specification

Every created TRX builds up eight possible queue positions in the actual BTS. If the TRX contains half rate
resources, the queue length is doubled. The maximum queue length in the BTS is, however, 24. Respectively,
every deleted TRX removes eight/sixteen possible queue positions.
The actual queue length is calculated by using the number of the possible queuing positions (all created TRXs in
the BTS), and the BTS parameter maximum queue length (maxQueueLength) given in percentage format.
Recalculation is performed when you change the maximum queue length parameter or when the active TRX
count changes (TRXs are created or deleted). The calculated actual queue length in the BTS, then, specifies the
number of call and handover attempts which can queue for a TCH release in that BTS.
In the BSC every BTS has the same maximum data area (same number of queuing positions), on which the
maximum queue length can have an effect. The data area gives the maximum value to the actual queue length for
every BTS. The size of the data area can be changed, but it is fixed in a certain software package.
5.1.9.11 Queuing possibility checks
5.1.9.11.1 Queuing checks

When all traffic channels are busy or there are no TCHs of the requested kind available and the seizure request is
not allowed to cause a forced release or a forced handover for another call in progress, the RRMPRB checks if
the queuing of this assignment or handover is allowed. The queuing transaction is allowed if the following
requirements are fulfilled:
The "queuing allowed" indicator in PIE is set on
The BTS channel configuration contains channels capable of the requested channel rate and
The BTS specific queue parameters make queuing possible in the BTS.

In call attempt queuing, the priority element that has been received from the MSC, and is given in the
ASSIGNMENT REQUEST message, contains the "queuing allowed" indicator. This priority element will then
be used. If the MSC prevents the queuing, the call attempt cannot be placed in the queue.
In an internal handover, the above original Priority Information Element is used, and stored in the original call
set-up in the ABIPRB. If the MSC has prevented the original call attempt queuing, the queuing is also denied in
all handover attempts during the ongoing call.
In external handover queuing, the Priority Information Element received from the MSC in the HANDOVER
REQUEST message, contains the "queuing allowed" indicator. This priority element will then be used. If the
MSC prevents queuing, the handover attempt cannot be placed in the queue.
5.1.9.11.2 Queuing possibility in the BTS

If this transaction queuing is allowed, the RRMPRB checks that the queue is available, i.e. that the actual queue
length is not zero, and the queue type is activated in this BTS so that the time limit value of the actual queue type
is not zero. If queuing in general, or only for this kind of attempt, is not allowed in the actual BTS, the call
attempt cannot be placed to the queue.
5.1.9.11.3 Acknowledgement in successful queue set-up

In all radio channel requests, if there is no TCH of the requested kind available in the BTS, and the queue set-up
is successful, the RRMPRB sends queuing information to the requested program block. If the call attempt is
queued for, the RRMPRB gives queuing information to the ABIPRB, which then sends a queuing indication to
the AIVPRB. The AIVPRB then sends a QUEUING INDICATION message to the MSC. If the handover
attempt is queued for, the RRMPRB gives queuing information to the HASPRB. In an external handover attempt
queuing in the target BSC, the HASPRB sends a queuing indication to the AIVPRB. The AIVPRB then sends a
QUEUING INDICATION message to the MSC.
5.1.9.11.4 Acknowledgement in successful queuing

In the case of successful queuing, i.e. when the queue element gets a TCH, the normal positive radio resource
allocation acknowledgement is forwarded to the requested program block, which then starts the required
signaling procedure concerning the actual attempt.
5.1.9.11.5 Acknowledgement in unsuccessful queuing

In all radio channel request cases, if no TCH of the requested kind is available in the BTS and the queue set-up is
not successful, the RRMPRB sends a normal negative radio resource allocation acknowledgement to the
requested program block. It then starts the required clearing or interruption procedure concerning the actual
attempt.
If the queue set-up has been successful, but the queuing time-out takes place, the RRMPRB sends a normal
negative radio resource allocation acknowledgement to the requested program block.
If the queue set-up has been successful, but the actual queue element has to be removed from the queue, the
RRMPRB sends a normal negative radio resource allocation acknowledgement to the requested program block.
5.1.9.11.6 Queue element

Each queued seizure request, i.e. queue element, has queue specifications (see below), which fully identify the
queue element and the required radio resource.
Original queuing resource indication: BTS, TRX, channel number

Queue type: call attempt, urgent handover attempt, non-urgent handover attempt; (sorting of handover
attempts to urgent and non-urgent handovers is based on the actual reason of the handover and indicated
in the TCH resource request received by the RRMPRB)
Queue element priority: MS priority, queue type priority:
In call attempt queuing the MS priority definition received from the MSC, contained in the ASSIGNMENT
REQUEST message, is used.
In internal handover the original MS priority definition above is used and stored in the call set-up in the
ABIPRB.
In external handover queuing, the MS priority definition received from the MSC, contained in the HANDOVER
If the MS priority is undefined in the MSC, the MS priority value will have the lowest priority in queue
management.
-required TCH resource (channel type)
In call attempt queuing, the resource definition received from the MSC, contained in the ASSIGNMENT
In an inter-BSC handover the original resource definition above is used and stored in the call set-up in the
ABIPRB.
In external handover queuing, the resource definition received from the MSC, contained in the HANDOVER
-accepted interference levels
In call attempt queuing, the most recently received interference band definition from the MSC, contained in the
ASSIGNMENT REQUEST message, is used. If there are no interference band requirements, all available TCHs
are suitable for this queue element.
In an inter-BSC handover the original interference band definition above is used and stored in the call set-up in
the ABIPRB.
In external handover queuing, the most recently received interference band definition from the MSC, contained
in the HANDOVER REQUEST message, is used.
-Requested TRX type:
Indicates if the queued resource is requested from the extended area or the normal area. The same queues are
used by MSs of the normal area and the extended area. When a TCH is released in the normal area it is assigned
immediately to the first MS of a queue which is queuing for resources of the normal area. When a radio channel
is released in the extended area it is assigned immediately to the first MS of a queue which is queuing for
resources of the extended area.
In call attempt queuing the type of the requested TRX is always the same as the TRX type used for signaling.
In intra- and inter-cell handover the TRX type request from the HANDOVER REQUEST message is used.
In external handover queuing the queued TRX type is always E-TRX if the target cell is extended and the queued
TRX type is N-TRX if the target cell is normal.
5.1.9.12 Prioritization of requests

In queue management, one important specification of the queue element is the priority. There are two queue
priority elements:
-MS priority: possibility to prioritize between queue elements

-queue type priority: possibility to prioritise between the queue types.

Queue management with different combinations of the priority elements is presented below.
5.1.9.12.1 Queue type priority and MS priority off

In this most straightforward case of queue management, the priority elements are not taken into account at all.
The seizure request is set to queue, providing that there is space left. If the queue is full, the channel allocation is
given a negative acknowledgement.
5.1.9.12.2 MS priority on, queue type priority off

The seizure request, i.e. the queue element, is set to the queue in a position that the MS priority entitles it to.
The MS priorities of the queue elements are checked. If the new queue element has a higher priority than the
previous ones, it is set to the queue so that it is located just before the lower priority element. Other queue
elements are transferred one position towards the end. In this case the last queue element may have to be
removed from the queue, which is then informed to the actual requested instance as a negative acknowledgement
to the radio channel seizure request.
When the seizure request is set to the queue, the timer service corresponding to the queue type is attached, and
the required RRMPRB file updating is performed. After that the queuing acknowledgement is returned to the
requested instance.
5.1.9.12.3 MS priority off, queue type priority on

The new queue element is set to queue in the position that the queue type priority entitles it to.
The queue type priorities of the queue elements are checked. If the new queue element has a higher priority than
the previous ones, this new element is set to the queue just before the lower priority element. Other queue
elements are transferred one position towards the end. In this case the last queue element may have to be
removed from the queue, which is then informed to the actual requested instance as a negative acknowledgement
to the radio channel seizure request.
When the seizure request is set to the queue, the timer service corresponding the queue type is attached, and the
required RRMPRB file updating is performed. After that the queuing acknowledgement is returned to the
requested instance.
5.1.9.12.4 MS priority and queue type priority on

In this case the queue element priority consists of the MS priority and the queue type priority. The new queue
element is set to queue in the position that the queue element priority entitles it to. The MS priority operates only
inside one single queue type. A higher MS priority call attempt, for example, is placed after a lower MS priority
handover attempt, if the handover queue type priority is set to be higher than the call queue type priority.
In the queue setting analysis only the MS priorities corresponding to the same queue type as the requested one
are checked, so that the search is not performed on the whole BTS queue. If the new queue element has a higher
MS priority than the previous ones inside the same queue type, the new element is set to the queue so that it is
located just before the lower MS priority element. Other queue elements inside the same queue type are
transferred one position towards the end. In this case the last queue element may have to be removed from the
queue, which is then informed to the actual requested instance as a negative acknowledgement to the radio
channel seizure request.
When the seizure request is set to the queue, the timer service corresponding to the queue type is attached, and
the required RRMPRB file updating is performed. After that the queue setting command is acknowledged to the
main channel call control.

5.1.9.13 Stored information and statistics counters

When a seizure request is stored to the queue, all necessary information from the seizure request message is
stored in the RRMPRB BTS Queue Data Structure (BQUFIL) in a record corresponding to the BTS identifier.
The time stamp for the queuing start time is also stored.
The priority order of the queue elements in the RRMPRB BTS Queue Order Data Structure (BQUORD) is
updated according to the queue element priority. The most important part of the stored data deals with the radio
channel identifiers of the requested instance, the requested channel type, the requested TRX type, the accepted
interference level, and the sub index to the reserved BQUFIL record.
When the request is stored in the BTS queue, the RRMPRB BTS State Data Structure (BSTAFI) is updated with
the information on the number of the queue elements in that cell, i.e. the number of requests queuing for either
full rate or half rate TCHs or requests capable of both channel rates depending on the received channel type and
rate in the assignment request.
The channel state files are also updated with information on queuing. The information includes the queued BTS
identifier and a sub index to the BQUFIL. It is of great importance, because if for instance an MS releases a call,
or if the HASPRB sends information concerning the rejected handover attempt while queuing, the queue element
has to be found and removed from the queue files.
When a request is set to the queue, statistics counters are updated. All counters are BTS-specific queue counters.
Call set-ups and handovers have their own counters; the queuing statistics related to the urgent and non-urgent
handovers can also be picked off with the aid of the counters.
5.1.9.14 Transaction release during queuing
5.1.9.14.1 Queuing MS on SDCCH releases

When the queuing radio channel (source) is an SDCCH, the queuing data is stored in the RRMPRB Signaling
Channel State Data Structure (SCHSTA) record corresponding to the SDCCH in question.
If the SDCCH is released during the queuing, the queue element is removed from the queue. If the queuing
SDCCH gets a TCH, the queuing data in the SCHSTA has to be removed. Respectively, if the queuing time runs
out, or the queue element is removed from the queue, the queuing data in the SCHSTA is removed.
5.1.9.14.2 Queuing MS on TCH releases
When the queuing radio channel (source) is a TCH, the queuing data is stored in the RRMPRB Traffic Channel
Status Data Structure (TCHSTA) record corresponding to the TCH in question. If this TCH is released during
queuing, the queuing element is removed from the queue files with the help of the queuing data stored in the
TCHSTA.
The HASPRB can send a REMOVE FROM QUEUE message to the RRMPRB in interrupted sequences. The
queuing element is removed from the queue files with the help of the information acquired from the message. If
the queuing TCH gets a new TCH, the queuing data in the TCHSTA has to be removed. Respectively, if the
queuing time runs out, or this queue element is removed from the queue, the queuing data in the TCHSTA will
be removed.

5.1.9.15 Queue search
5.1.9.15.1 General
If the RRMPRB detects queued seizure requests in the actual BTS when TCH releases, the BTS queue is
scanned. The last updated interference level information to be used for the released TCH can be found in the
channel state file record.
When TCH radio resources are deblocked, and the RRMPRB detects queued seizure requests in the actual BTS,
the BTS queue is scanned. The new available TCH interference band is initialised for the worst interference band
until a real interference updating is received.
The BTS queue is also scanned when the idle TCH interference levels are changed and there are queued seizure
requests in the actual BTS. This is done because the queued elements may have just the kind of interference band
requirements that the new updated TCHs can now offer.
5.1.9.15.2 Queue search procedure

The BTS queue is scanned in the queue element priority order until a suitable queue element is found, that is,
when the requested channel type and rate, the requested TRX type and the interference level information are the
same as those of the new TCH available. The starting-point in the search is the top element of the BTS queue
order records, because the queue is always organised so that the highest priority element is the first one in the
queue.
The queuing time used is examined and after that the queue record is removed. Because of this queue removal,
the information controlling the queuing order has to be reorganised and updated in the BQUORD. The queuing
data and the possible BTS data in the queued channel state file record are removed. The number of queuing
requests in that cell is updated in the BSTAFI.
Successful queuing is reported to the requested program block (the ABIPRB or the HASPRB), including the data
concerning the radio resource information allocated to it. After that, the program block starts the required
signaling procedures concerning the actual queued attempt. Successful queuing is marked to the statistics
counters. The queuing time used is examined by using the actual time stamp and the stored time stamp to see the
queuing start time. Every queue type has its own counters.
5.1.9.15.3 Time-out for queued seizure request

When the seizure request is queued, time supervision is started. The queuing time available depends on the
queue type. If the time supervision expires, and no suitable TCHs have been released, the RRMPRB receives a
time-out message. The queue element is searched, and the queue element removed and reorganised in the same
way as in the radio channel release.
The number of BTS queue elements in the BSTAFI is updated. The queuing data in radio channel state files (the
TCHSTA and the SCHSTA) is removed. Unsuccessful queuing is reported to the requested program block (the
ABIPRB or the HASPRB) as a normal negative acknowledgement to the channel seizure request. After that the
actual signaling process starts the required clearing or interruption procedures concerning the actual queued
attempt.
Unsuccessful queuing, as well as the queuing time used, are marked to the statistics counters. Call set-ups and
handovers have their own counters; the urgent and non-urgent handovers can also be picked off with the aid of
the counters.

5.1.9.15.4 Changing BTS queue length

Maximum queue length parameter change by user. If you change the maxQueueLength parameter, the RRMPRB
receives a BTS parameter update via the BSC Configuration Updating Program Block (GUPDAT) from the
OMC or the local MMI. You may, for example, set the new maximum queue length definition to zero, so that
queuing is not possible in that BTS. The actual queue length, i.e. the maximum queue length proportioned to the
number of possible queuing positions (all created TRXs in the BTS), is recalculated after the parameter change.
If there are queuing call or handover attempts not located within the new allowed area, the RRMPRB removes
them immediately from the BTS queue, and negative acknowledgements for the queued channel seizure requests
are forwarded to the requested instances.
5.1.9.15.5 TRX creation or deletion by user

When the BTS configuration is changed, the RRMPRB receives a configuration-updating message from the
GUPDAT. Every created TRX builds up eight/sixteen (TCH/F / TCH/H) queue positions. However, the
maximum queue length in the BTS is 24. When a TRX is deleted, the same number of possible queue positions
are removed. The actual queue length is determined by means of the maxQueueLength attribute (in percentage
format) given by the user.
After the TRX deletion procedure, it is checked whether there are queuing call or handover attempts not located
within the new allowed area. If this is the case, the RRMPRB immediately removes them from the BTS queue,
and negative acknowledgements for the queued channel seizure requests are forwarded to the requested
instances.
5.1.10 Time limited calls
5.1.10.1 General
Due to high-congested situation where the radio resources are not enough to serve all the subscribers then the
procedure time limited call is enabled. The aim of this technique is based upon an ongoing call which is setup for
certain duration. Therefore the objective is the Mobile Station to occupy a traffic channel for a small period of
time. This period is defined from the operator and can be vary to different subscribers as it can also be combined
with the priority scheme. Moreover, when the time has expired the network should make free the traffic channel
again and drop the call. This procedure is implemented with forced release.
5.1.10.2 Forced release check

When the RRMPRB receives an ASSIGNMENT or a HANDOVER REQUEST message and all traffic channels
are busy, the RRMPRB checks if the assignment is allowed to cause a forced release to another call in progress
on the BTS. The forced release transaction is allowed, if the "pre-emption capability" indicator is set on, the MS
priority is set to 1 and the "queuing allowed" indicator is set on.
In a call attempt which is allowed to cause a forced release the Priority Information Element received from the
MSC in the ASSIGNMENT REQUEST message is used. The MSC can prevent the use of the forced release
function for a call in progress by setting the pre-emption vulnerability indicator off.
In an internal handover, the original priority information element is used. The priority information element is
stored in the ABIPRB during the call set-up phase. If the MSC has prevented the forced release in the original
call attempt, the forced release is also denied in all handover attempts during the ongoing call.
In an external handover, the priority information element received from the MSC, given in the HANDOVER

5.1.10.2.1 Acknowledgement in successful forced release

In the case of a successful forced release the following steps take place:
a program block (HASPRB or ABIPRB) sends a pre-emptive TCH request for a new call- or handover
attempt
this request causes the forced release for another call in progress and the new call gets the released TCH
RRMPRB then forwards a positive radio resource allocation acknowledgement to the requesting
program block, which initiates channel allocation signaling.
5.1.10.2.2 Acknowledgement in unsuccessful forced release

If no channel has been released within the time limit, the RRMPRB sends a negative radio resource allocation
acknowledgement to the requesting program block.
5.1.10.3 Storing forced release requests

The seizure request which is allowed to cause a forced release to another call in progress is stored in the BTS
Forced Release Data Structure (BFRFIL). The seizure request is stored, providing that there is space left; a
maximum of 8 seizure requests can be stored at the same time for one BTS. When the seizure request is stored in
the BFRFIL, the RRMPRB sends the QUEUING INDICATION message to the service requesting program
block. If the Directed Retry is in use in the BSC, the ABIPRB checks from the QUEING INDICATION message
in which queue or data structure the call attempt is stored. If the call attempt is waiting for forced release in the
BFRFIL, the Directed Retry will not be initiated. If the seizure request cannot be stored (the BFRFIL is full), the
channel allocation is given a negative acknowledgement.
When the seizure request is stored in the BFRFIL, the RRMPRB BTS State Data Structure (BSTAFI) is updated
with the information on the number of forced release seizure requests in that cell, and time supervision is started.
The time limit is a BSC-specific fixed parameter (i.e. it cannot be changed by the operator).
The seizure requests are removed from the BFRFIL in chronological order (first in, first out).
5.1.10.4 Selection of the candidate for forced release

After the RRMPRB has stored the information of the seizure request to the BFRFIL, the RRMPRB selects the
candidate to be released. The following main principles apply to the candidate selection:
the candidate has the pre-emption vulnerability indicator set on
the call in progress is not an emergency call
the lowest priority of the calls in progress is chosen.
The TCH channel rate requirement of the resource request makes the candidate selection procedure more
complicated especially when the BTS contains dual rate resources and a full rate TCH is requested. In that case
the following three cases are possible:
the MS of lowest priority is found among the FR mobiles
the MS of lowest priority is found from a half occupied dual rate RTSL
the MS of lowest priority is found from a dual rate RTSL, both halves of which are occupied.
The MSs of the first two cases are accepted as candidates but the third case is exceptional when the forced
release is requested.
The following rules are followed when the candidate for forced release is selected:
the MS of lowest possible priority is allocated
only one call is allowed to be released for an incoming call.
When the RRMPRB has found the best suitable candidate for release, the RRMPRB sends the information of
that channel to the ABIPRB. The ABIPRB starts the required signaling procedures concerning forced release.

5.1.10.4.1 Successful forced release

If the RRMPRB detects seizure requests in the BFRFIL when TCH releases, the first seizure request is removed.
The number of forced release seizure requests in the BFRFIL in that cell is updated in the BSTAFI.
The successful assignment or handover is reported to the requesting program block (ABIPRB or HASPRB),
including the data concerning the radio resource information allocated to it. After that, the program block starts
the required signaling procedures concerning the actual assignment or handover attempt.
5.1.10.4.2 Unsuccessful forced release

If no TCH has been released within the time limit, the TCH service request is rejected due to lack of resources.
5.1.10.4.3 Time-out for the forced release

When the forced release seizure request is stored to the BFRFIL, time supervision is started. The time limit is a
BSC-specific fixed parameter.
If the time supervision expires and no TCHs have been released, the RRMPRB receives a time-out message. The
seizure request is removed from the BFRFIL.
The number of TCH requests, which are allowed to cause a forced release, is updated in the BSTAFI. The
unsuccessful assignment or handover attempt is reported to the requesting program block (ABIPRB or
HASPRB) as a negative acknowledgement to the channel seizure request with the cause "no resource available".
5.1.10.4.4 Statistics counters for forced release

When the RRMPRB receives a seizure request attempt which is allowed to cause a forced release for another call
in progress, the statistical counters are updated. Assignment request attempts and handover request attempts have
their own individual counter.
When a TCH request which is allowed to cause forced release for another call in progress is rejected due to lack
of released channels, the statistics counters are updated. Assignment request failures and handover request
failures have their own individual counters.
When the seizure request which caused a forced release for another call in progress gets a TCH, the statistics
counter is updated.
These counters are BTS-specific.
5.1.11 FACCH call set-up due to SDCCH congestion
5.1.11.1 Description
When the feature FACCH call setup is activated, in SDCCH congestion of the BTS the Mobile Station can be
assigned from the CCCH to the TCH with the Immediated Assignment procedure. The TCH is then used for
signaling. FACCH call set up may be used in SDCCH congestion situations. If an attempt to allocate an SDCCH
fails, the RRMPRB tries immediately to allocate TCH provided that the FACCH call set up has been allowed by
an indicator in SDCCH request message.
An SDCCH request does not contain the normal allocation criteria for TCH allocation. The TCH type to be
allocated is determined based solely on the request type information of the SDCCH request. The request tells
whether a TCH/H is sufficient for the requested call or if the call requires a TCH/F. If a TCH/H is valid, an
attempt is made to first allocate a channel of this rate. If the TCH/H allocation does not succeed, then an attempt

is made to allocate a TCH/F. If the request type indicates that a TCH/F is to be allocated, then only of this rate
may be selected.
A TCH/F is always allocated for emergency calls, because the HR capabilities cannot be solved for them in the
phase the FACCH call setup is applied.
Because no information of the preferred speech codecs is available, the basic speech encoding algorithm of the
selected channel rate is always chosen for an FACCH call.
The A interface circuit type information is not available in this signaling phase. Therefore, during FACCH call
setup, the A interface circuit is assumed to support fully the TCH rate requirement given in the SDCCH request
message.
5.1.11.2 Limitations
Queuing of the FACCH call setup resource request is not allowed.
5.1.12 Directed retry

If a TCH is requested for an internal handover that has been started due to direct retry or the Intelligent Directed
Retry procedure, a TCH is allocated with the same search criteria as in normal call set up. Restrictions that have
been specified for internal handovers are not applied. All the factors affecting the determination of the channel
rate to be used are examined for each BTS while checking through the handover candidate list. As a further
difference from the other handover cases switching of the A interface circuit pool is not performed during
handover caused by the Direct Retry procedures.
Directed retry is a procedure in the cellular radio system which is triggered by the assignment procedure in the
call set-up phase. In case of congestion in the serving cell, the mobile subscriber (MS) can be assigned to a
traffic channel in a new target cell based on the radio measurement reports received from the MS.
5.1.13 Access Control by User Groups
5.1.13.1 Description
The system information messages on the BCCH broadcast the list of authorized access classes and authorized
special access classes in the system information messages, and whether emergency calls are allowed in the cell
to all mobile stations or only to the members of authorized special access classes.
If the establishment cause for the request of the MM sublayer is not "emergency call", access to the network is
allowed if and only if the mobile station is a member of at least one authorized:
• Access class; or
• Special access class.
If the establishment cause for the request of the MM sublayer is "emergency call", access to the network is
allowed if and only if:
• Emergency calls are allowed to all mobile stations in the cell; or
• The mobile station is a member of at least one authorized special access class.
Under certain circumstances, it will be desirable to prevent MS users from making access attempts (including
emergency call attempts) or responding to pages in specified areas of a GSM PLMN. Such situations may arise
during states of emergency, or where 1 of 2 or more co-located PLMNs has failed.
Broadcast messages should be available on a cell-by-cell basis indicating the class(es) of subscribers barred from
network access. The use of this facility allows the network operator to prevent overload of the access channel
under critical conditions. It is not intended that access control be used under normal operating conditions.

5.1.13.2 Allocation
All MSs are members of one out of ten randomly allocated mobile populations, defined as Access Classes 0 to 9.
The population number is stored in the SIM. In addition, mobiles may be members of one or more out of 5
special categories (Access Classes 11 to 15), also held in the SIM. These are allocated to specific high priority
users as follows. (The enumeration is not meant as a priority sequence):
Class 15 - PLMN Staff;

Class 14 - Emergency Services;
Class 13 - Public Utilities (e.g. water/gas suppliers);
Class 12 - Security Services;
Class 11 - For PLMN Use.
5.1.13.3 Operation
If the MS is a member of at least one Access Class, which corresponds to the permitted classes as signaled over
the air interface, and the Access Class is applicable in the serving network, access attempts are allowed.
Otherwise access attempts are not allowed. Access Classes are applicable as follows:
Classes 0 - 9 - Home and Visited PLMNs;
Classes 11 and 15 - Home PLMN only;
Classes 12, 13, 14 - Home PLMN and visited PLMNs of home country only.
Any number of these classes may be barred at any one time.
5.1.13.3.1 Emergency calls

An additional control bit known as "Access Class 10" is also signaled over the air interface to the MS. This
indicates whether or not network access for Emergency Calls is allowed for MSs with access classes 0 to 9 or
without an IMSI. For MSs with access classes 11 to 15, Emergency Calls are not allowed if both "Access class
10" and the relevant Access Class (11 to 15) are barred. Otherwise, Emergency Calls are allowed.
5.1.14 NSS Overload Features
5.1.14.1 Random traffic dispersion to trunks
5.1.14.1.1 Introduction
The feature Random Traffic Dispersion allows the operator to direct traffic in the desired proportion between
primary and alternate routes. This feature can be used, for example, if the operator wants to direct, due to an
agreement, 60% of the traffic via the network of operator A and 40% via the network of operator B.
5.1.14.1.2 Description of the feature

When Random Traffic Dispersion is adapted to a route, certain percentages are applied to routes according to the
wishes of the operator.

Figure 98: Destination using Random Traffic Dispersion
For each call a random number is allotted and scaled to the interval 0...100. If, for example the number is 35 it
falls to the route 2 (Figure 99). Percentages are from Figure 98.
Figure 99: Lottery of the primary route
A free circuit is then tried to find from the circuit groups of the route 2. Call control passes a call to Resource
Manager the traffic type being "direct routing". If no free circuit is found or the call control rejects the call for
some other reason a new random number is allotted, the portion of the route 2 excluded (Figure 100). The new
percentages are got by giving the proportion of the route 2 to the other routes so that the proportional share of the
rest of the routes remains the same as at the beginning. If a new random number is 56 this means that the first
alternate route is the route 3. Call control forwards this route along with the traffic type "alternate routed to" to
Resource Manager. This is the way we continue until a free circuit is found.
Figure 100: Lottery of the first alternate route
5.1.14.2 Selective circuit reservation
Selective Circuit Reservation allows the operator to have more extensive control over how circuits are reserved
and used under heavy traffic. The operator can set a limit on how many circuits can be reserved of the circuit
groups of a route, after which different criteria are followed on how calls are forwarded.
Normally circuits are reserved in the order in which new calls arrive. All outgoing calls are directed to the
primary circuit group until no free circuits are left, after which new calls are directed to the next alternative
circuit group. All calls are given equal treatment.

When no free circuits are left in any of the alternative circuit groups, calls are rejected or directed to an
alternative route, if an alternative route exists. With the Selective Circuit Reservation feature the two call types,
direct routed calls (DR) and alternative routed calls (ART), can be given different priorities: the operator can
give preference to the direct routed calls over the alternative routed calls and thus make sure that at least the
direct routed calls are forwarded also under heavy traffic.

The Selective Circuit Reservation has direct effects on circuit group level. You can set one or two threshold
values for each individual circuit group; the values determine in which cases selective circuit reservation is
applied to a circuit group. Typically, the feature is applied when the traffic intensity exceeds a certain level,
defined as the amount of available circuits in the circuit group.
For example, the less critical threshold (threshold 1) can be defined as five available circuits out of the total
amount of ten circuits, and the more critical threshold (threshold 2) as two available circuits out of the total of
ten circuits. Next, you need to define a response category for each of the circuit groups, which apply to the
selective circuit reservation. This means that you should determine what rejection percentages are used for the
two traffic types (DR, ART) in cases when the thresholds 1 and 2 are exceeded. After that, you should decide
how the calls, which are rejected according to the rejection tables after a threshold value has been exceeded, are
handled. There are two possible control actions: Skip and Cancel. When the control action of a circuit group is
Skip, the call is forwarded to the next alternative circuit group, provided that there is one. In this case the control
action of the primary circuit group overrides the control action of the alternative circuit group, so that if the
control action of the alternative circuit group would also cause the call to be rejected, the control action of the
primary circuit group determines whether the call is rejected or skipped to the next alternative circuit group.
If the call is rejected at every alternative circuit group, the control action is passed to the call control, which
determines whether the call is forwarded to an alternative route or rejected altogether. The call is always
forwarded to the alternative route if an alternative route exists.
When the control action of the primary circuit group is Cancel, no alternative circuit group is used, and the call is
rejected at this point. Only in cases where an emergency call has been passed to the call control with the control
action "cancel" does the call control ignore the action, trying to find a free circuit for the call in an alternative
route.
5.1.14.2.3 Parameters
The parameters of the Selective Circuit Reservation feature are best understood from the following figure:
Figure 101: Parameters of the selective reservation feature

5.1.14.2.4 Operator interface

When a circuit group is created, it does not contain any selective circuit reservation features; they have to be
added afterwards. This is done with the MML command RCM.
The following parameters are used when defining selective circuit reservation for a circuit group:
• Reservation threshold 1: the less critical of the two limits at which selective circuit reservation is
started. Give the value of the parameter in multiples of ten per cent (10 %, 20 % and such). The value of
threshold 1 indicates the number of available circuits in relation to the total amount of circuits in a
circuit group. With threshold 1 at 40 %, selective circuit reservation is started as soon as the number of
circuits available in the circuit group falls below 40 %, after which new calls directed to the circuit
group are rejected according to the rejection tables.
• DR1: rejection percentage of DR calls with traffic load between threshold 1 and threshold 2. The value
of DR1 indicates how big a percentage of the DR calls directed to the circuit group are rejected when
traffic intensity is higher than threshold 1 but lower than threshold 2.
• ART1: rejection percentage of ART calls with traffic load between threshold 1 and threshold 2. The
value of ART1 indicates how big a percentage of the ART calls directed to the circuit group are rejected
when traffic intensity is higher than threshold 1 but lower than threshold 2.
• Reservation threshold 2: the more critical of the two limits at which selective circuit reservation is
started. Give the value of the parameter in multiples of ten per cent (10 %, 20 % and such)
• DR2: rejection percentage of DR calls with traffic load exceeding threshold 2. The value of DR2
indicates how big a percentage of the DR calls directed to the circuit group are rejected when traffic
intensity is higher than threshold 2.
• ART2: rejection percentage of calls directed to an alternative route with traffic load exceeding threshold
2. The value of ART2 indicates how big a percentage of the ART calls directed to the circuit group is
rejected when traffic intensity is higher than threshold 2.
• Control action: the parameter tells how the rejected calls are handled. The alternatives are:
– Skip: direct the call to the next alternative
– Cancel: reject the call
– No action
5.1.14.3 Automatic congestion control
Automatic Congestion Control (ACC) is capable of receiving and handling ACC information coming from the
neighboring exchanges, and of limiting its traffic to these exchanges. Using this feature, the operator can reduce
traffic to the neighboring exchanges that are in danger of becoming overloaded in their own network or in the
PSTN, provided that they can send congestion level information. The operator can make a distinction between
different types of traffic, and prefer one type of traffic over the others.
5.1.14.3.2 Interface
The user interface of the Automatic Congestion Control includes the commands for defining the rejection
percentages for each traffic type (DR and ART) under both congestion levels (CL1 and CL2). There are also
action controls for each case, and a parameter for defining the duration of ACC information. If no new ACC
information is received from a signaling point during the time defined in the parameter, the signaling point is no

longer considered as being congested. The default value of the ACC duration is 5 seconds, and the allowed
values range from 1 to 30 seconds.
To respond to the congestion level received from the neighboring exchange, the user must define the rejection
percentage table according to which the exchange rejects the calls. When the exchange receives the congestion
level information from the network, a timer is activated and the expiration time defined (the default value is 5
seconds). The expiration time is given as a parameter (ACC duration). If no new congestion level information is
received during this time, the timer expires, and the congestion level is no longer valid. If new congestion level
information is received before the timer expires, the timer is restarted.
5.1.14.4 Overload control
5.1.14.4.1 Definition of Overload

Every part of a telecommunication network must be dimensioned according to the traffic demand. Flexible
system design facilitates proper dimensioning. Spare capacity is normally reserved for occasional traffic peaks
and future growth. In addition, load-sharing principles are often applied in order to enable robust dimensioning.
However, due to the random nature of telecommunication traffic and its dependence on human behavior, the
installed capacity is not sufficient in all circumstances.
Traffic load is defined as the total number of transaction requests arriving to a network element during a given
interval of time. A shortage of resources is caused by an excessive amount of load, or a failure that reduces the
installed capacity of a network element. The number of transaction requests coming to a network element may
exceed its engineered transaction processing capacity for a significant period of time, excluding momentary
peaks. Overload refers to the percentage of the total traffic load that exceeds the engineered transaction
processing capacity.
The number of signaling units and processor equipment that is in a centralized use (central block) are determined
during the dimensioning phase. Normally, the transaction processing capacity of a network element is restricted
by the limiting computer unit of the central block. Processor overload of a network element means a situation
where the limiting computer unit, normally in the central block, is fully loaded. In this case, it is recommended
that originating and incoming transaction requests are rejected in the signaling units. Overload control functions
are used to prevent and detect overload conditions and to protect network elements from overload, which might
deteriorate the level of service.
Many signaling systems include capabilities for congestion and overload control. CCITT No.7 includes features
for avoiding congestion by alternative routing or capacity expansion. The requirements for exchange overload
control in fixed networks are outlined in CCITT Recommendation Q.543 /1/. Recommendation Q.543 also
provides guidelines for the GSM network elements. However, the recommendations do not specify overload
control mechanisms on a detailed level. In particular, the detection of processor overload is left to depend on the
manufacturer.
5.1.14.4.2 Objectives of Processor Overload Control

Objectives for performance design are expressed by the percentage of inadequately handled transaction requests,
transaction processing delays, and some other criteria. These objectives must be fulfilled when the traffic load is
at the level of the designed traffic capacity of the MSC and VLR or HLR, AuC and EIR for the mixture of
transaction types handled and signaling types used. If the traffic load is less than the designed traffic capacity of
an installed MSC and VLR or HLR, AUC and EIR, no type of resource is exhausted and all the grade-of-service
criteria are met.
The criteria for the grade of service are met as long as the traffic load is below the engineered traffic capacity. If
the offered traffic load is higher, overload control mechanisms are used to reject the overload traffic. In the case

of central overload, all the signaling units (SUs) must apply overload control. If a single SU is overloaded, new
requests are rejected only in this unit.
The following objectives are set to the overload control functions:

• If the offered traffic exceeds the engineered transaction processing capacity of a network element,
excessive transaction requests should be rejected without significant decrease of the traffic handled.
• The traffic that is handled during overload conditions should not experience unacceptable processing
delays.
• If the limiting computer unit of the central block is overloaded, all the SUs must be able to reject new
transaction requests.
• If a single SU is overloaded, the overload control methods should not reject the transaction requests that
are not processed by the overloaded SU.
• The overload control mechanism should react quickly to sudden peaks of overload traffic.
• Rapid variations of the offered traffic should be buffered in the SUs.
• The rejection of transaction requests should be made on a per transaction basis using delay criteria.
• The overload control functions should not decrease the effective transaction processing capacity of any
computer unit.
• Signaling-specific features should be utilized in the rejection of transaction requests.
• The overload control and rejections should not cause significant oscillation in the amount of processed
traffic.
• The number of rejected transaction requests should be recorded at specified time intervals.
The onset of an overload state should be recognized by the processing logic of the network element, which in
turn invokes strategies to avoid a severe degradation in the throughput. The used internal overload control
methods depend on the implementation.
5.1.14.5 Alternative routing restriction
The feature Alternate Routing Restriction allows the operator to place certain restrictions on a route that uses
alternative routing due to heavy overloading or a fault in some part of the network. The operator can prevent
instability from spreading in the network by placing temporary restrictions on a destination or on certain
subdestinations.

The user can set restrictions to subdestinations as a part of a destination and directly to individual
subdestinations. The restrictions possible for a destination, that is, to the subdestinations within a certain
destination, are the following:
• No restrictions
• Skip this subdestination
The restrictions for the primary subdestination of a destination are the following:
• No restrictions
• Make a certain percentage of the traffic go to the first alternative subdestination.
The restrictions for individual subdestinations are:

• No restrictions
• Skip this subdestination
• No overflow from this subdestination
• This subdestination may only be used as a primary subdestination, that is, no overflow to this
subdestination is allowed. If a new call is directed to this subdestination as something else than a
DR call, the call will overflow to the next alternative.

• This subdestination may only be used as an alternate subdestination. If a call is directed to this
subdestination as something else than an ART call, the call will overflow to the next alternative
subdestination.
• This subdestination is blocked. No overflow.
5.1.15 Conclusions
Despite all the techniques that have been mentioned and detailed explained an overview of the usage of each
technique can be shown in following table. As mentioned before congestion arises due to the lack of SDCCH
and TCH resources, thus the table concluded which technique is suitable either for SDCCH congestion or TCH
congestion.
Table 37: Management techniques comparison
Congestion
Technique SDCCH TCH
Dynamic SDCCH x
Half Rate / Full Rate x
Forced Handover x
TRX prioritization x
Dynamic Cell resizing x x
Bandwidth Reservation x
eMLPP x
Location Update x
Time Limited Calls x x
FACCH call setup x
Directed Retry x
Access Control by User Groups x x
NSS Overload Features x

5.2 Resource management Techniques in cellular networks of 2+G
5.2.1 HSCSD
The HSCSD is a 2+ Generation extension of the circuit-switched 2 generation GSM communication. As such,
HSCSD inherits all the resource management techniques of GSM. Therefore, all the considerations made in
previous sections of this document are still applicable. Moreover, with respect to GSM, HSCSD makes available
the multislot mechanism, i.e. it is able to simultaneously allocate multiple traffic channels (/bearers) for the
communication. In this section, we will concentrate on the multislot related features of HSCSD, to highlight the
flexibility mechanisms in resource management that can be exploited for CAUTION overload control purposes.
5.2.1.1 Overview of operations

A multislot configuration consists of multiple circuit or packet switched traffic channels together with associated
control channels, allocated to the same MS. The multislot configuration occupies up to 8 basic physical channels,
with different timeslots numbers (TN) but with the same frequency parameters (ARFCN or MA, MAIO and
HSN) and the same training sequence (TSC).
When an MS supports the use of multiple timeslots it shall belong to a multislot class; for HSCSD, only
multislot classes 1 - 18 are recognized (3GPP TS 05.02). The Multi Slot Class determines the range of some
parameters negotiated during the call setup: the multislot class of the MS will limit the combinations and
configurations allowed when supporting multislot communication.
For all kind of connections, at call setup the user indicates a maximum number of TCH/F, acceptable channel
codings, possible other modem type, and fixed network user rate values. For non-transparent HSCSD
connections, in addition, wanted air interface user rate is indicated and the network resource needs, if the user
wishes to make use of the user initiated modification of the maximum number of TCH/F and/or wanted air
interface user rate (user initiated service level up- and downgrading described in 5.2.1.7) during the call.
In case the indicated acceptable channel coding(s) implies that enhanced modulation is possible, the user may
indicate a preference for channel coding asymmetry or channel coding symmetry. All together these parameters
describe the HSCSD characteristics and network uses them to allocate an appropriate HSCSD connection.
For both transparent (variable bit-rate) and non-transparent (fixed bit rate) HSCSD connections the call can be
established with any number of TCH/F from one up to the maximum number of TCH/F (the minimum channel
requirement is always one TCH/F). If the wanted air interface user rate requirement cannot be met using a
symmetric configuration, an asymmetric configuration can be chosen. The network shall in this case give priority
to fulfilling the air interface user rate requirement in downlink direction.
For non-transparent HSCSD connection the network can use dynamic allocation of resources (TCH/F) as long as
the configuration is not in contradiction with the limiting values defined by the MS and the mobile equipment is
capable of handling the allocated channel configuration. For transparent HSCSD connection the dynamic
resource allocation is applicable, if the air interface user rate is kept constant.
The change of channel configuration within the limits of minimum and maximum channel requirements is done
with resource upgrading and resource downgrading procedures (described in 5.2.1.5) during the call. The MS
may request a service level up- or downgrading (described in 5.2.1.7) during the call, if this option has been
negotiated in the beginning of the call. In the user initiated modification procedure, the user can modify the
channel coding asymmetry preference when enhanced modulation is indicated. This modification of channel
requirements and/or wanted air interface user rate and/or channel coding asymmetry preference is applicable to
non-transparent HSCSD connections only.

5.2.1.2 Air interface

The HSCSD configuration is a multislot configuration using the TCH/F data channel mapping described in [GPP
TS 05.02: "Digital cellular telecommunications system (Phase 2+); Multiplexing and multiple access on the
radio path"].
Three types of HSCSD configurations exist:
1) symmetric configuration: a bi-directional FACCH and co-allocated bi-directional TCH/F and SACCH
channels;
2) asymmetric configuration: a bi-directional FACCH and co-allocated uni-directional (data transferred

down-link direction only) or bi-directional TCH/F and SACCH channels;
3) pseudo-asymmetric configuration: the timeslot allocation is symmetric but the ME may use different air
interface access rates at uplink and downlink; it is applicable only to non-transparent HSCSD.
For each type of configuration:
• the channels may be allocated on either consecutive or non consecutive time slots taking into account
the restrictions defined by the classmark.
• one bi-directional channel, the main channel, carries a FACCH used for all the signaling not carried on
the SACCH(s).
The same channel coding is used for all the channels in the HSCSD configuration, though in the enhanced
modulation mode, for non-transparent services, it is possible to have one channel coding used in the downlink
and another channel coding used in the uplink. Different channel coding for up- and downlink could be applied
in three cases:
1) If the mobile station only supports enhanced modulation in the downlink direction;
2) If the mobile station supports enhanced modulation in both directions, but the user indicates preference
for uplink or downlink biased channel coding asymmetry;
3) If the mobile station supports enhanced modulation in both directions, and the user indicates preference
for channel coding symmetry, but the link conditions justifies different channel coding in uplink or
downlink.
5.2.1.3 Call establishment procedures
5.2.1.3.1 Mobile originated call establishment

At the call set-up the mobile station sends a set of parameters7 (all contained in the Bearer Capability
Information Element) describing the HSCSD characteristics to the network. These parameters and their presence
in the Setup message in transparent (T) and non-transparent (NT) calls are as follows:
Table 38: Parameters exchanged in HSCSD call establishment
Parameter Meaning Service

OMT Other Modem Type All
FNUR Fixed Network User Rate All
Max TCH/F Maximum number of traffic channels All
ACC Acceptable Channel Codings All
ASYM Channel coding ASYMmetry indication, NT only
AIUR Wanted Air Interface User Rate NT only
UIMI User Initiated Modification Indication NT only
7 The multislot mechanism is not needed in Iu mode, as one bearer can provide all needed data rates. In Iu mode, consequently the parameters required for setup of a
multislot call are not needed in a call setup, and the MSC shall ignore the parameters.

MS BTS BSC MSC
Normal signalling
Classmark change, CLM3

( MS Multislot Class )
Normal signalling
SetUp
( OMT, FNUR, ACC, Max TCH/F, UIMI(NT only), AIUR(NT only) )
Call Proceeding
( OMT, FNUR, UIMI(NT only) )
Assignment Request
( Max TCH/F allowed, Allowed radio interface data rates,
Wanted total radio interface data rate(NT) / Requested
Resource air interface user rate (T), Configuration evolution indication )
allocation
Physical context interrogation
Channel activation
( Bi-directional / Uni-directional Bm Multislot configuration)
n times
Channel activation ack
Assignment command
( Description of multislot configuration )
Signalling link establishment
Assignment complete Assignment complete

( Channel mode, n TCH/F )
Seize IW
resources
Normal signalling
n = number of time slots allocated
Figure 102: Mobile originated call establishment
In reply the network responds in Call Proceeding with the Other Modem Type, OMT, Fixed Network User Rate,
FNUR, and User Initiated Modification Indication, UIMI (NT only), parameters it is prepared to give to the
mobile station. The MSC requests the BSC to allocate the channel configuration using parameters derived from
the HSCSD related parameters agreed in the set-up phase. Based on these parameters and operator preferences
the BSC then allocates a suitable number of channels and a suitable channel coding for the connection.
The following rules for channel allocation apply:
• The BSS shall try to reach but not exceed, with one exception, the wanted AIUR. The exception is the
case when the chosen configuration can reach the wanted AIUR with lower number of TCH/F, e.g. in
case AIUR=14.4 kbit/s, max number of TCH/F=3, ACC=TCH/F4.8 and TCH/F9.6, the network shall
choose 2x9.6 over 3x4.8 if the TCH/F9.6 is available in the cell;
• Separate channel activation is applied for each of the HSCSD channels before the selected channel
configuration with information of the channel coding is forwarded to the mobile station. When the
preference for downlink or uplink biased channel coding asymmetry is indicated by the user, and an
asymmetric channel coding connection is set up based on this indication, the BSC shall always assign a
TCH/F14.4 channel on the unbiased link of the connection.
At assignment completion, the BSS informs the MSC of the chosen HSCSD configuration and the MSC may
seize the IW resources accordingly.

5.2.1.3.2 Mobile terminated call establishment

At the call setup the network sends the Other Modem Type,OMT, Fixed Network User Rate, FNUR, and User
Initiated Modification Indication,UIMI (NT only), parameters to the mobile station. In reply the mobile station
responds to the network with the set of parameters describing the HSCSD characteristics. The procedure is then
equal to the Mobile originated call case.
MS BTS BSC MSC
Normal signalling
Classmark change, CLM3

( Multislot class )
Normal signalling
SetUp
( OMT, FNUR, UIMI(NT only) )
Call Confirmed
( OMT, FNUR, ACC, Max TCH/F, UIMI(NT only) , AIUR(NT only) )
Signalling like in mobile originated case
Figure 103: Mobile terminated call establishment
5.2.1.4 Handover procedures

Even if once split the data streams are carried by the n full rate traffic channels, logically the n full rate traffic
channels at the radio interface belong to the same HSCSD configuration, and therefore they shall be controlled
as one radio link by the network for the purpose of cellular operations, e.g. handover.
5.2.1.4.1 Intra BSC handover

For a non-transparent call, the HSCSD configuration may be modified during an intra BSS handover within the
maximum number of TCH/F and channel codings acceptable for the user and allowed by the network.
5.2.1.4.2 Inter BSC, intra-MSC handover

In inter BSS handover the MSC requests the new BSS to allocate a channel configuration using parameters
derived from the HSCSD related parameters agreed earlier during the call. Based on these parameters and
operator preferences the BSC then allocates a suitable number of TCH/F and a suitable channel coding for the
connection. For a non-transparent call, the HSCSD configuration may be modified during an intra BSS handover
within the maximum number of TCH/F and channel codings acceptable for the user and allowed by the network.
The same channel allocation and activation rules as in call establishment apply.
5.2.1.4.3 Inter MSC handover

In inter MSC handover the requested channel configuration is forwarded to a BSS within the new MSC using
MAP protocol between MSCs. Procedures similar to those in inter BSS handover case can be applied in order to
establish the HSCSD connection in a new cell.

5.2.1.5 Flexible air interface resource allocation

This section describes the flexibility mechanisms that HSCSD makes available to adapt the multislot
configuration to the current needs of the network and of the mobile subscriber. These mechanisms, especially
those described in the following subsection, could be exploited for the sake of resource management under
overload conditions in CAUTION.
5.2.1.6 Network initiated service level up- and downgrading

The flexible air interface resource allocation allows the network to alter the air interface resource allocation for
the reasons of either lack of radio resource, handover, and/or to maintain service quality. This flexibility may
result in a change in a user data rate change.
5.2.1.6.1 Configuration change procedure

The configuration change procedure is used by the network to change the number of timeslots used in a multislot
configuration. The procedure can also be used to change the channel mode of one or several channels and change
their allocation. The main signaling link however, cannot be changed by the configuration change procedure. If a
change of the main signaling link is needed, the assignment or handover procedures shall be used. Trough the
configuration change procedure both resources upgrading (allocating more channels) and downgrading (channels
are released) are possible. These procedures are initiated by the network in non-transparent calls. For transparent
connection the alteration of resources is also applicable required that the AIUR for the connection remains
constant. The configuration change procedure starts when the network sends a CONFIGURATION CHANGE
COMMAND to the mobile station on the main DCCH (the network shall not initiate a new configuration change
procedure before a response to the previous CONFIGURATION CHANGE COMMAND message has been
received from the mobile station). The message indicates:
• Timeslots to use in uplink;
• Timeslots to use in downlink;
• Channel set each timeslot belongs to.
When the mobile station receives the CONFIGURATION CHANGE COMMAND it changes its configuration
in accordance with the message contents and returns a CONFIGURATION CHANGE ACKNOWLEDGE on the
same channel as the command message was received, confirming the new channel configuration. This applies
irrespective of whether the new configuration is different from the one already in use by the mobile station or if
it is the same.
If the CONFIGURATION CHANGE COMMAND message instructs the mobile station to use a Channel
Configuration or Mode(s) that it does not support, or if the channel mode to use is not defined for all channel
sets, the mobile station shall return a CONFIGURATION CHANGE REJECT message with cause 'channel
mode unacceptable', and the mobile station shall remain on the current channel(s) and use the old Channel
Configuration and Channel Mode(s).
Figure 104 depicts the procedure for a successful resource upgrading and downgrading for an ongoing HSCSD
call, in case the position of the main TCH/F remains unchanged. A separate channel activation for the new
HSCSD channels is carried out and the earlier activated HSCSD channels may be modified, before RR
Configuration change procedure is used for forwarding the new channel configuration to the mobile station.
Similarly, the Configuration change procedure can be used in both transparent and non-transparent calls for
reordering the channels in a call without changing the number of TCH/Fs allocated. At resource modification
completion, the BSC signals to the MSC the new HSCSD configuration and the MSC may adjusts the IW
resources accordingly. In case the resource modification has to take place between different networks, a
procedure involving the Shared Inter Working Function Server (SIWFS) is used [Digital cellular
telecommunications system (Phase 2+); Mobile Application Part (MAP) specification (3GPP TS 09.02 version

7.7.0 Release 1998)]. In brief, a MAP_SIWFS_Signaling_Modify is invoked either by an MSC or by the

SIWFS. It contains the changed Air Interface User Rate.
MS BTS BSC MSC
Resource change
decision
Resource
allocation
Channel activation / Mode modify

( A + M ) times
Channel activation ack / Mode modify ack
Configuration change command

Configuration change ack New Configuration

RF channel release
R times Adjust IW
RF channel release ack resources
A = number of time slots added to the connection

R = number of time slots released from the connection
M = number of time slots modified
n = number of time slots after upgrading/downgrading
Figure 104: Resource upgrading and downgrading, the position of the main channel unchanged
Figure 105 depicts the procedure for a successful resource upgrading and downgrading for an ongoing HSCSD
call in case the position of the main channel is changed. A separate channel activation for the new HSCSD
channels, is carried out and the earlier activated HSCSD channels may be reactivated, before RR Assignment
procedure is used for forwarding the new channel configuration to the mobile station. Similarly, the Assignment
procedure can be used in both transparent and non-transparent calls for reordering the channels in a call without
changing the number of TCH/Fs allocated. At resource modification completion, the BSC signals to the MSC the
new HSCSD configuration and the MSC may adjusts the IW resources accordingly.

MS BTS BSC MSC
Resource change
decision
Resource
allocation
Channel (re-)activation / Mode modify

( A + M - 1 ) times
Channel (re-)activation ack / Mode modify ack
Assignment command
Signalling link establishment
Assignment complete Handover Performed

Channel re-activation
Adjust IW
( Bi-directional / Uni-directional Bm Multislot configuration) resources
Note !
Channel re-activation ack
RF channel release
R times
RF channel release ack
NOTE: Deactivates the old signalling link by modifying the old main channel. The old main can not be modified
before a new main has been established. If the time slot for the old main is not used in the new HSCSD
configuration, RF channel release is used instead.
A = number of time slots added to the HSCSD connection
R = number of time slots released from the HSCSD connection
M = number of time slots modified or re-activated
n = number of time slots after upgrading/downgrading
Figure 105: Resource upgrading and downgrading, the position of the main channel changed
5.2.1.6.2 Assignment procedure

In dedicated mode or in group transmit mode, an intracell change of channel can be requested by upper layers for
changing the channel type, or decided by the RR sublayer, e.g. for an internal handover. This change may be
performed through the dedicated channel assignment procedure.
The purpose of the channel assignment procedure is to completely modify the physical channel configuration of
the mobile station without frequency redefinition or change in synchronization while staying in the same cell.
The channel assignment procedure happens only in dedicated mode and in group transmit mode. This procedure
cannot be used in the idle mode; in this case the immediate assignment procedure is used. The channel
assignment procedure includes:
• The suspension of normal operation except for RR management (layer 3);
• The release of the main signaling link, and of the other data links;
• Disconnection of TCHs if any;
• The deactivation of previously assigned channels (layer 1);
• The activation of the new channels and their connection if applicable;
• The triggering of the establishment of the data link connections for SAPI = 0.

The channel assignment procedure is always initiated by the network sending an ASSIGNMENT COMMAND
message to the mobile station on the main signaling link.
5.2.1.7 User initiated service level up- and downgrading

The user initiated service level up- and downgrading is applicable for non-transparent multislot data services,
only. By means of this procedure, if so indicated in the call setup, during a HSCSD call the user can request a
change of the network to change the current maximum number of traffic channels and/or air interface user rate
parameters, to be assigned by the network. This is done by using the CC User initiated service level up and
downgrading procedure. The procedure is initiated by the mobile station in the "active" state of the call. It shall:
• Send a MODIFY message including the wanted value of the "maximum number of traffic channels"
and/or the "wanted air interface user rate" parameters;
• Not change any of the other, possibly negotiated, parameters of the bearer capability information
element;
• Start timer T323;
• Enter the "mobile originating modify" state.
Any internal resources necessary to support the next service parameters shall be reserved. If a dual service was
negotiated at call setup, the mobile station shall initiate the service level up- or down-grading only during the
data phase of the dual service. Upon receipt of the MODIFY message, the network shall check if the indicated
maximum number of traffic channels can be supported and enter the "mobile originating modify" state. The
network may upon reception of the MODIFY message initiate a change of the channel configuration assigned to
the mobile station. As a response to the MODIFY message the network sends a MODIFY COMPLETE message
including the bearer capability negotiated at call setup and enters the "active" state. Upon receipt of the
MODIFY COMPLETE message the mobile station shall stop timer T323 and enter the "active" state. If network
allows the modification, the resulting new parameters are forwarded to BSC and the radio interface resources
may be adjusted accordingly. The resource upgrading or downgrading is done separately from the change in
HSCSD parameters. The cases in which the network doesn’t allow the modification are:
• If a change of bearer service is requested together with a change of the "maximum number of traffic
channels" and/or the "wanted air interface user rate"
• If the current used service is not a data service where up- and downgrading is applicable
• If the receiver chooses not to grant the request.
In these cases the network shall:

• send a MODIFY REJECT message with bearer capability negotiated at call setup and with cause #58
"bearer capability not presently available";
• enter the "active" state
Upon receipt of the MODIFY REJECT message with the bearer capability negotiated at call set-up, the mobile
station shall: stop timer T323 and enter the "active" state. Upon expiration of T323 in the mobile station the
procedures for call clearing shall be initiated with cause #102 "recovery on timer expiry".
5.2.2 GPRS
The GPSR offers both the circuit-switched and the packet-switched access technology. As for the circuit-
switched access, the same GSM technology is used. Therefore, all resource management techniques taken into
consideration for congestion management in GSM are also of interest in GPRS. In this section, we will focus on
two specific aspects of GPRS:
• Random access procedure on the PRACH channel
• QoS management
These two specific GPRS aspects offer potential targets for enhancing the resource management under overload
conditions.

5.2.2.1 PRACH access

GPRS mobile terminals use the PRACH channel in order to access to the GPRS mobile network. A PRACH
channel is used each time a GPRS mobile terminal
• Executes a GPRS attach,
• Executes a packet data call set up (PDP context activation)
• Executes a location update (only for MS in IDLE state),
• When it receives a paging message (only for MS in IDLE state).
The MS recognize what uplink PRACH shall use by examining the PCCCH RLC/MAC block headers that
indicates which next uplink block is free for use as PRACH. After detecting the free block it sends s a Packet
Channel Request and monitors the PCCCH for a “Packet uplink assignment”.
The mobile station shall make maximally M + 1 attempts to send a PACKET CHANNEL REQUEST message.
After sending each PACKET CHANNEL REQUEST message, the mobile station shall listen to the full PCCCH
corresponding to its PCCCH_GROUP. The PRACH Control Parameters contains the access persistence control
parameters and shall be broadcast on PBCCH and PCCCH. The parameters included in the PRACH Control
Parameters are:
• MAX_RETRANS, for each radio priority i (i=1,2,3,4);
• PERSISTENCE_LEVEL, which consists of the PERSISTENCE_LEVEL P(i) for each radio priority i (i
= 1, 2, 3, 4); where P(i) ∈ {0, 1, …14, 16}. If the PRACH Control Parameters does not contain the
PERSISTENCE_LEVEL parameter, this shall be interpreted as if P(i)=0 for all radio priorities;
• S;
• TX_INT.
The mobile station shall start a timer (T3186) at the beginning of the Packet Access Procedure. At expiry of the
timer, the packet access procedure shall be aborted, packet access failure shall be indicated to upper layers and
the mobile station shall return to packet idle mode. For each attempt, the mobile station shall draw a random
value R with uniform probability distribution in the set {0, 1, …, 15}. The mobile station is allowed to transmit a
PACKET CHANNEL REQUEST message if P(i), where i is the radio priority, is less or equal to R.
After each attempt, the S and T parameters are used to determine the next TDMA frame in which it may be
allowed to make a successive attempt. The number of TDMA frames belonging to the PRACH on the PDCH
defined by the PCCCH_GROUP for the mobile station between two successive attempts to send a PACKET
CHANNEL REQUEST message excluding the TDMA frames potentially containing the messages themselves is
a random value drawn for each transmission with uniform probability distribution in the set {S, S + 1, …, S + T -
1};
Here,
• M is the value of the parameter MAX_RETRANS, belonging to the Radio Priority of the access;
• T is the value of the parameter TX_INT;
• S is the value of the parameter S.
Having made M + 1 attempts to send a PACKET CHANNEL REQUEST message, the mobile station shall stop
timer T3186 and start a new timer T3170. At expiry of timer T3170, the packet access procedure shall be
aborted, a packet access failure shall be indicated to upper layer and the mobile station shall return to packet idle
mode.
If the mobile station receives a PACKET DOWNLINK ASSIGNMENT message during the packet access
procedure, it shall abort the packet access procedure and respond to the PACKET DOWNLINK ASSIGNMENT
message on the PDTCH indicated in the same PACKET DOWNLINK ASSIGNMENT. The network may send
to the mobile station a PACKET QUEUING NOTIFICATION message. The PACKET QUEUING
NOTIFICATION message shall be sent on the same PCCCH on which the network has received the PACKET
CHANNEL REQUEST. It contains a Temporary Queuing Identity, which is later used to identify the mobile
station.
On receipt of a PACKET QUEUING NOTIFICATION message corresponding to one of its 3 last PACKET
CHANNEL REQUEST messages, the mobile station shall stop timers T3170 and T3186 if running, start timer
T3162, and stop sending PRACH messages. It shall continue to listen to the full PCCCH corresponding to its

PCCCH_GROUP. On receipt of a PACKET UPLINK ASSIGNMENT message following a PACKET

QUEUING NOTIFICATION message, the mobile station shall stop timer T3162.
At expiry of timer T3162, the packet access procedure shall be aborted and a packet access failure shall be
indicated to the upper layer and the mobile station shall return to packet idle mode.
If the mobile station receives a PACKET DOWNLINK ASSIGNMENT message, it shall abort the packet access
queuing notification procedure and respond to the PACKET DOWNLINK ASSIGNMENT message.
Like the GSM the GPRS network may respond to a channel request with a PACKET ACCESS REJECT
message avoiding a high incoming load. After receiving the reject message a new timer T3172 starts. The mobile
station is not allowed to make a new attempt for packet access in the same cell until timer T3172 expires, but
may attempt packet access in other cells after successful cell reselection for radio conditions reasons.
The network broadcasts on PBCCH and PCCCH, the list of authorised access classes and authorised special
access classes in the ACC_CONTR_CLASS parameter. Access to the network is allowed if the mobile station is
a member of at least one authorised access class or special access class. The numbers of classes and procedure to
avoid unauthorized classes follow exactly what is defined for GSM mobile.
For GPRS (and for GSM as well), the maximum access rate depends on the particular frequency strategy
planned in a particular cell. More precisely, the number of access per second that can be offered varies in the
range [29, 54, 108, 162, 217] and the particular mapping preference is operator-dependent.
5.2.2.2 QoS management

The GPRS manages the packet-switched assigned resources through the basic mechanisms of QoS negotiation.
This resource management is used in a resource negotiation phase that precedes each data transfer.
The Quality of Service Profile assumes the user is at a location with acceptable GSM/GPRS coverage and refers
to and is valid for normal network operating conditions or, as in case of the service precedence parameter,
regulates how the network shall handle abnormal conditions.
QoS is considered to be a single parameter with multiple data transfer attributes, in particular in terms of the
following attributes:0
• Precedence class;
• Delay class;
• Reliability class;
• Peak throughput class;
• Mean throughput class.
There are many possible QoS Profiles defined by the combinations of the attributes: a PLMN may support only a
limited subset of the possible QoS profiles. During the QoS profile negotiation, that happens during some
Session Management procedures (e.g. PDP Context Activation), it shall be possible for the MS to request a value
for each of the QoS attributes. The network shall negotiate each attribute to a level that is in accordance with the
available GPRS resources. The network shall always attempt to provide adequate resources to support the
negotiated QoS Profiles.
5.2.2.3 Precedence Class

Under normal operating conditions, the network shall attempt to meet the service commitments of all QoS
profiles. The Precedence Class indicates the relative importance of maintaining the service commitments under
abnormal conditions, for example which packets are discarded in the event of problems such as limited resources
or network congestion. The Precedence Classes are defined in Table 39.
Table 39: Precedence Classes

Class Name Interpretation
Service commitments shall be maintained ahead of
1 High Priority
precedence classes 2 and 3
Service commitments shall be maintained ahead of
2 Normal Priority
precedence class 3
Service commitments shall be maintained after of precedence
3 Loss Priority
classes 1 and 2

5.2.2.4 Delay Class

There are four delay classes (1 to 4): the network operator should provide adequate transmission resources on the
radio and network communication channels in order to support the expected number of subscribers within each
cell at a given delay class. As a minimum, the PLMN shall support the best effort delay class (4). The Delay
Class is defined on base of the delay due to technical transmission characteristics of the system and measured
with the transmission of SDUs through specified reference points in the GPRS network.
5.2.2.5 Reliability Class

The Reliability Class is defined in terms of the residual error rates for the following cases:
• Probability of data loss;
• Probability of data delivered out of sequence;
• Probability of duplicate data delivery;
• Probability of corrupted data
The Reliability Class specifies the requirements of the various network protocol layers. The combinations of the
GTP, LLC and RLC transmission modes support the reliability class performance requirements. The Reliability
Classes are summarized in Table 40.
Table 40: Reliability Classes
Class Traffic Type
1 Non real-time traffic, error-sensitive application that cannot cope with data loss.
2 Non real-time traffic, error-sensitive application that can cope with infrequent data loss.
3 Non real-time traffic, error-sensitive application that can cope with data loss, GMM/SM, and SMS.
4 Real-time traffic, error-sensitive application that can cope with data loss, GMM/SM, and SMS.
5 Real-time traffic, error-non-sensitive application that can cope with data loss.
5.2.2.6 Throughput Classes

User data throughput is specified in terms of a set of throughput classes that characterize the expected bandwidth
required for a PDP Context. The throughput is defined by means of both peak and mean classes. It shall be
possible for the network to re-negotiate the throughput parameters at any time during a session.
5.2.2.6.1 Peak Throughput Class

The peak throughput is measured at Gi and R reference points in units of octets per second. It specifies the
maximum rate at which data is expected to be transferred across the network for an individual PDP Context.
There is no guarantee that this peak rate can be achieved or sustained for any time period, this depends upon the
MS capability and available radio resources. The network may limit the subscriber to the negotiated peak data
rate, even if additional transmission capacity is available. The peak throughput is independent of the delay class,
which determines the per-packet GPRS network transit delay. The Peak Throughput Classes are defined in Table
41.
Table 41: Peak Throughput Classes
Class Peak Throughput in octets per second

1 Up to 1000 (8 kbit/s)
2 Up to 2000 (16 kbit/s)
3 Up to 4000 (32 kbit/s)
4 Up to 8000 (64 kbit/s)
5 Up to 16000 (128 kbit/s)
6 Up to 32000 (256 kbit/s)

7 Up to 64000 (512 kbit/s)

8 Up to 128000 (1024 kbit/s)
9 Up to 256000 (2048 kbit/s)
5.2.2.6.2 Mean Throughput Class

The mean throughput is measured at the Gi interface and R reference points in units of octets per hours. It
specifies the average rate at which data is expected to be transferred across the GPRS network during the
remaining lifetime of an activated PDP context.
The network may limit the subscriber to the negotiated mean data rate, even if additional transmission capacity is
available. A “best effort” mean throughput class may be negotiated, and means that throughput shall be made
available to the MS on a per need and availability basis. The Mean Throughput Classes are defined in Table 42.
Table 42: Mean Throughput Classes
Class Mean Throughput in octets per hour

1 100 (0.22 bit/s)
2 200 (0.44 bit/s)
3 500 (1.11 bit/s)
4 1000 (2.2 bit/s)
5 2000 (4.4 bit/s)
6 5000 (11.1bit/s)
7 10000 (22 bit/s)
8 20000 (44 bit/s)
9 50000 (111 bit/s)
10 100000 (0.22 kbit/s)
11 200000 (0.44 kbit/s)
12 500000 (1.11 kbit/s)
13 1000000 (2.2 kbit/s)
14 2000000 (4.4 kbit/s)
15 5000000 (11.1 kbit/s)
16 10000000 (22 kbit/s)
17 20000000 (44 kbit/s)
18 50000000 (111 kbit/s)
31 Best Effort
5.2.3 EDGE/EGPRS
Apart from the lowest transmission layers EGPRS does not introduces modifications in the protocols with
respect to GPRS. Therefore, we will be not considering any specific resource management techniques for
EGPRS.

5.3 Resource management Techniques in cellular networks of 3G
5.3.1 General
Resources in 3G networks can be divided for radio resources and core network hardware resources. Hardware
resources are usually much less limited than radio resources so it is easy to improve the performance of that part.
However, radio resources are always strictly limited and they are usually the bottle neck for total performance of
the whole network. That is why proper radio resource management is so important in mobile networks. In UMTS
following radio resources may be managed:
• Power (interference)
• Codes
• Frequency
• Cell layers
As an indirect method of resource management, algorithms for standard procedures may be considered. The
main procedures, which can be found in all cellular networks, are following:
• Handovers
• Traffic management and scheduling
• Admission control
• Congestion control
All those resources and procedures are all very closely linked, so it is hard to design a method to manage only
one of them. Most algorithms shortly described below have an impact on all.
5.3.2 Admission control

To avoid coverage decreasing or degrading quality level of ongoing calls admission control is used. This
procedure allows determining whether user requesting an access may have it granted. Implemented algorithm
determines further network behaviour.
The simplest algorithm should just analyze available resources in the cell. When user wants to establish a
connection in the cell, downlink capacity and uplink interference at base station is analyzed. If there are enough
resources in downlink and current interference is below threshold, an access is granted [19]. To avoid
unnecessary blocking additional mechanism may be added to this algorithm: not only resources are checked, but
also a history of base station. If there are not enough resources, algorithm checks if base station has been in the
same state as the current one before. If it has and it has not caused a handover failure then new call is accepted
[18]. In the modified algorithm a general rule is presented, which is important in other methods, too: handover
requests are more important, than new calls. This is because call dropping caused by handover failure is more
annoying for a user than blocking a call.
Another modification of simple algorithm, which checks momentary available resources in the cell, is based on
overall view on part of the network. This algorithm should be placed in SRNC and analyze interference in whole
supervised area, too. This decreases probability of assigning the same resources to several users in different cells
[20].
To avoid admission mistakes caused by momentary peaks or declines of traffic load some prediction method
may be implemented (for example, instead of checking available resources, available bandwidth may be
considered). This method can be combined with described above algorithms: new user may access the network if
the level of interference is low enough and there is available bandwidth. Such a combined algorithm can provide
better performance for some popular services (like speech, e-mail and web browsing) [21].

It was also proposed to calculate system determinant whenever access is requested. The determinant is compared
to a threshold depending on QoS and multiplied by a fixed or tunable factor. The factor allows reserving some
resources for ongoing calls. It may be tuned based on estimated drop rate. Such an algorithm allows
differentiating admission policy to reflect different services [26].
There are other algorithms designed for diverted services. In one of them outage probability is derived based on
state chain model (each state represents number of active connections in a cell). This probability is compared to
new user’s QoS requirements and, if the probability is too high, the user is blocked [22]. In second algorithm
more sophisticated method was utilized: based on different mathematical models of fours services (video, voice,
Poisson data and web browsing) requirements for admission control was derived. Fulfilling them allows
maintaining QoS of ongoing calls [25]. Next step is to ascribe priorities to QoS levels. Comparing priorities it
will be possible to decide which calls are more important and, if it is necessary (for instance in case of
handover), pre-empt calls with lower priorities to free the resources. If priorities correspond to required
bandwidth, then using this method allows improving overall network performance. It is even not always
necessary to drop pre-empted calls — if HCS is implemented, pre-empted calls (with lower bandwidth) can be
forced to hand over to bigger cells [23]. To support multiple priorities, queues may be implemented. Then, even
if new or handover call does not fulfill all conditions to be admitted to the cell, it is not blocked immediately, but
put into the proper queue. If it is not executed before a timer expires, it is removed from the queue and blocked
[2].
Service priorities and call pre-emption may be compared to GSM enhanced MLPP (eMLPP) mechanism. It
proposes to divide all calls into seven classes and to ascribe a priority level to each class. Two highest classes are
available only for the system. Five lower may be provided to users (however, the highest class of these five is
recommended to be allocated for emergency calls). With different priorities, a pre-emption mechanism is
proposed [54]. Similar algorithm may be applied to UMTS calls carrying different services. However, no
precise recommendations have been released by now [55].
Centralized method of admission controlling with QoS provisioning consists in implementing a separate
controller (at least logically separate). It may be placed in RNC or MSC server. Such a call admission controller
has been proposed. The algorithm controlling it is based on fuzzy logic and recurrent neural network. This
controller is able to predict a mean interference of existing calls, possible interference caused by a new call and
decide whether accept the call or not [24].
For some services, access blocking does not mean call failure. In case of non-real-time services, it causes only
data transmission delay. On the other hand, in case of soft handover (ref. next chapter) blocking handover call
does not mean the call is immediately dropped — overloaded cell is just not added to active set of blocked
mobile station.
5.3.3 Handover
In most CDMA-based networks, including UMTS, handovers may be divided for hard and soft (softer)
handovers. Hard handovers are well known, for example in GSM: mobile station changing base station has to
change operating frequency, too, so it first closes connection to old base station and then starts communication to
new one. CDMA hard handover works in exactly the same way. However, unlike in GSM, in UMTS radio
network entities are not distinguished with its operating frequency, but with code, so it is possible to reuse the
same frequency in adjacent cells. In that case, mobile station can communicate with several base stations
simultaneously during handover procedure. This is defined as soft handover. When soft handover is performed
between sectors of the same base station, it is called softer handover.
5.3.3.1 Hard handover

First type of hard handover is intra-UMTS handover. At the beginning of UMTS operation, it will be probably
common to use only one frequency. However, soon it will be necessary to add one or more new frequencies to
cells, where traffic load is the highest. There are two main ways of adding those resources to the network [10]:

• increasing capacity of existing cells with new frequencies;

• creating new cells with new frequencies, possibly as a different layer (HCS);
The way radio network capacity is increased belongs to network planning.
Intra-UMTS hard handovers are less efficient than soft ones. In case of similar conditions, utilization of soft
handovers allows decreasing average transmission power, what has impact on interference and cell capacity [17].
As a special type of HCS layer, satellite UTRAN may be considered (although it is not expected to be available
soon). Because satellite segment will use different frequency band than terrestrial one, all inter-segment
handovers between those layers are going to be hard handovers.
Some algorithms for HCS handovers allowing efficient resource management are described in following
chapters.
Second type of hard handover is inter-system handover between UMTS and GSM. Contrary to inter-segment,
inter-system handovers will be implemented since the very beginning of UMTS to provide continuous coverage.
On the other hand, UMTS network will allow extending the capacity, where existing GSM network is
overloaded. From network point of view, such type of a handover is similar to inter-BSC/inter-RNC handover.
Hard handover occurs when mobile station switches between FDD and TDD, too.
Hard handover requires compressed mode to enable mobile station to perform measurements on other
frequencies. That mode causes radio link degradation, because some procedures either can not be applied or are
not so efficient as in normal mode (e.g. fast power control) [10]. Network informs mobile station when it should
start monitoring different frequency. However, base station controllers are aware only of “their” base stations. If
hard handover is to be used as a tool solving congestion situations (distributing calls more fairly), base station
controllers should be provided with measurements of the cells belonging to other controllers. To enable that a
mechanism allowing a RNC requesting cell measurements form another RNC should be implemented [58].
5.3.3.2 Soft and softer handover

Soft handover allows mobile station to communicate with more than one base station simultaneously. A general
mechanism of soft handover is standardized, but precise algorithms depend on implementation. Several
parameters describe soft handover algorithm. Most important are:
• Active set size: set of base stations, to which mobile station is connected.
• Add and drop thresholds: thresholds describing conditions to add a base station to active set, or to drop it
from the set. The thresholds are relative: they define difference between signal strength from the strongest
base station in active set and candidate base station (allowing it to be added to active set if the difference is
smaller than the add threshold), or the weakest base station (allowing this base station to removed from
active set, if the difference is higher than the drop threshold).
• Drop delay: to avoid dropping base stations because of fades a drop delay was proposed. Base station may
be removed from active set, if the difference between its signal and the strongest signal from active set
exceeds drop threshold for longer time than drop delay defines.
Maximum active set is usually limited by mobile station capabilities. However, simulations show that reasonable
upper limit for active set is about 4–5. Bigger active can hardly improve soft handover performance [14]. For
thresholds, it is possible to implement an algorithm, which can adjust them dynamically. It may be a function of
signal strengths of base stations from active set [15]. Other possible parameter for threshold deriving is current
traffic load [16]. Any algorithm adjusting those parameters should be considered at the stage of network
planning, because signaling traffic load depends on mean number of base stations with which mobile station
communicates (usually between 1 and 2).

In future, it may be necessary to design a mechanism separating resource allocation and radio link activation. In
case of handover of high data rate services with short delay QoS requirements, resources should be reserved in
advance. Separating mechanism would enable requesting resource allocation in new cell, but without activation
radio link — it would be done with separate request. Similarly, radio link could be deactivated, but resources
would remain allocated [58].
5.3.3.3 Handover to another cell layer

Different cell layers are usually implemented in a network to balance traffic load. The way how radio resources
and users are assigned to cell layers depends on algorithms controlling the traffic. The simplest way is to set
static thresholds for traffic parameters and based on them control resources. However, this method is very
inefficient — the thresholds have to be set for “worst case”, but then during normal operation large capacity is
wasted. On the other hand, if they are set for normal operation in case of “emergency” (e.g. unusual meetings,
New Year Eve) the network would fail (as it happens often in GSM networks) [18].
One of possible traffic controlling algorithms bases on users' velocity — mobile stations, which move faster are
assigned to bigger cells and the rest remains (or is assigned, when slows down) under control of small cells
(which have higher capacity). Thanks to this, number of handover may be decreased. That method can be
enhanced with additional algorithms, which control threshold velocity and dynamically assign channels to cell
layers. Velocity threshold algorithm is based on current loss probability estimation (in order to minimise
handover rate): if the probability is too high the threshold is increased, in the other case it is decreased. Resource
control algorithm works only together with the threshold control algorithm. Here, again, probability of the loss is
estimated. If velocity threshold controlling itself can not decrease the probability some channels are reassigned
from macro to micro cells (so the capacity of the latter is enlarged). Otherwise capacity of micro cells may be
decreased and some channels are reassigned to macro cells to decrease handover probability [11]. Velocity may
be counted as average time between handovers [57]. It is also possible to allow micro cells to control its
coverage (with power control) and with that, to improve its capacity without degrading quality of existing calls.
In some cases (unbalanced traffic load between macro and micro cells) it may decrease probability of call
blocking [12].
In case of inter-segment handovers between terrestrial and satellite parts of UTRAN, following two option are
possible:
• “backward” algorithm (from satellite to terrestrial segment and oppositely): handover requests and signaling
messages are sent via old segment. In case of handover to terrestrial part of the network, satellite radio link
is heavily loaded with signaling. In case of handover to satellite, this part decides about available resources
and accepts, or not, the handover. The decision must be send back to core network, what loads signaling. In
both cases, delays are long.
• “forward” algorithm (from satellite to terrestrial segment and oppositely): mobile station is capable of using
new link to initiate handover procedure. It requires high complexity of mobile station.
It is possible to combine those options to find optimal algorithm. Core network must have full knowledge about
available resources of both satellite and terrestrial radio network. Then, the decision if handover is possible, or
not, may be made in core network, what decreases total signaling traffic load on radio links. Beside that,
signaling traffic may be sent using “cheaper” terrestrial links, so delays are shorter. This method gives almost as
good results as “forward” algorithm, but requires less complex mobile stations [13].
5.3.4 Power control

In all CDMA systems, where power is a limited resource fast power control is implemented in uplink. In
WCDMA, power control is performed 1500 times per second in both directions: uplink and downlink.

During soft handover, UE sends fast power control commands to all Nodes-B from active set. However, because
of radio link errors it may happen that the command will not be decoded correctly in base station. This may
cause power drifting: some base stations changes the power level in opposite way than it was requested by UE.
This feature decreases radio link quality, so some algorithms have been proposed to avoid it [10]:
• Limited changes: when fast and large changes of transmitted power are forbidden, power control errors can
not degrade quality too much. It is very simple method, but decreases as well power control gain.
• RNC supervision: RNC receives power control information from base stations and records them. Based on
these records some statistics may be derived and used to supply base stations with reference levels. Each
base station changes its transmitted power toward the reference level.
More important problem than fast power control in downlink is the same procedure in uplink, because it
influences cell capacity. To avoid decoding errors in power control commands received by mobile station
physical dedicated control channel (DPCCH) may be transmitted with higher power. In case of soft handover
mobile station has to decrease its power whenever it is possible — it means the UE must adjust its transmitters
power to the lowest allowed level [10]. When active set contains more than one base station, mobile station may
choose which base station provides highest quality of the data transmission. Then, it informs network about
results of measurements and all other base stations decreases power of their downlink dedicated data channels
(DPDCH) to minimum level. When radio conditions changes primary base station is changed [57].
Beside fast power control, there is outer loop power control in UMTS, too. It allows setting a target for fast
power control and works in both directions: uplink and downlink. Too high SIR would waste resources, while
too low could decrease QoS. The general algorithm for outer loop power control is very simple: if the quality of
received signal is better than required, SIR ought to be decreased — otherwise it should be increased. The
mechanism may be more sophisticated to avoid problems with upper and lower limits of mobile station
transmitter power. To obtain received signal quality several methods may be used. Some are presented below:
• CRC check: this method is good for low quality, non-real-time services;
• Estimated BER before decoding (“Raw” BER);
• Information from Viterbi or Turbo decoders (“soft information”): this method is more useful for high quality
services;
Similar outer loop power control exists for downlink connections. However, in this case all signals come from
the same source — base station. It can easily supervise quality of all connections so it is not necessary to obey
every power control command sent from mobile stations [10].
Some improvements to standard power control algorithm were proposed. The standard algorithm forces mobile
station to follow power control commands. However, power control transmission delays cause small shift in
mobile station reactions. This means, power received at base station is below threshold when a fade appears and
excess the threshold when the fade peak passes. One method to avoid that consist in speed estimation. The
estimation should be performed in mobile station based on fades frequency. The information is used together
with power control commands from base station. Different approach is to skip fixed power change step. The step
transmitter power is changed should depend not only on the last power control command, but on the history of
changes, too. That allows to follow non-linear characteristic of fast fades [29].
The algorithm used for power management determines transmission performance. For example, in case of non-
real-time data services (like WWW or WAP browsing, so the most popular data services), a method with
constrained total power and scheduling transmission (assigned power depends on distance from base station to
mobile station) provides much better performance than simple algorithm, which aims to assign minimum power
for each mobile station [27]. Other algorithm links uplink data rates of data transmission with mobile station
power level: mobile station increases or decreases its data rate by step if its power crosses lower or upper power
threshold. It allows either improving transmission quality (lower BLER and interference, higher average data
rates) in case of big cells (radius over 1 km) or widening cell coverage with maintained quality level [28].
Similar algorithm introduces rate control mechanism. Network monitors radio conditions and decides if data rate
for some users may be increased (or should be decreased). Choosing the users network considers the services
they are using. Therefore, the algorithm is centralized, but allows to decrease cell interference [30].

5.3.5 Packet scheduling

There are three basic methods for packet scheduling [10]:
• time division scheduling

• code division scheduling
• scheduling based on transmission power
Time division scheduling splits whole transmission time for all users. Simultaneously only a few users can
transmit, but with high data rates. Because high data rates requires less power per one bit [10], so scheduling
based on time division has an advantage of lower Eb/N0. However, frequent allocating and freeing radio
resources requires some time and causes higher signaling traffic load. The second drawback is that not all mobile
stations will be able to use so high data rates, so this method is more useful on downlink. It may be especially
efficient for asymmetric, bursty transmission — like, for example, web browsing. It may be also useful in case of
protocols, where many small packets are exchanged, because here transmission delays are short. As an example
of such protocol Microsoft network protocol may be given.
Second method, code division scheduling, allows providing low data rates for many users simultaneously. An
advantage of this method is more predictable interference level and lower signaling load. On the other hand,
more energy per transmitted bit is required and transmission delays are higher, than in case of time division
scheduling. This method is more efficient when large amount of data is transmitted without frequent packet
exchanging (e.g. FTP) and when it is not possible to utilize high data rate (e.g. in some cases in uplink). Data
rate assignment may be either static or dynamic. In case of static assignment, the same data rate is used
throughout a connection. This method is easy to implement, but may be inefficient when application
requirements change often. In case of dynamic data rate assignment, the rate may vary throughout transmission.
However, it is difficult to predict required rate. One of possible ways is to use large buffers and derive required
data rate based on their status.
High data rate allows using lower transmission power per transmitted bit. Thus, to utilize available cell capacity
more efficiently users requesting high data rates should be privileged. This approach is called transmission
power-based scheduling. To implement this algorithm transmission power of a mobile station must be predicted
or estimated at the beginning of the connection. This algorithm privileges mobile stations, which are close to the
base station. Thus, it may be compared to ideal GPRS system, where coding scheme may depend on distance
from BTS.
Packet scheduling must be considered together with other algorithms used for handover and admission control.
Resources and traffic load of all cells of active set (soft/softer handover), in case of all described methods,
should be taken into account. Similarly, admission control algorithm depends on packet scheduling, because
resources available for new and handover calls depends on that. If separate queues are implemented for each
type of service (for each priority) it is possible to add service class parameter to described above algorithms.
Each class has a priority level and packets are scheduled based on those priorities. However, when scheduling of
the same class packets is required, described above algorithms may be used [2].
5.3.6 Other algorithms
5.3.6.1 CPICH power adjustment

Power control of common pilot channel (CPICH) may be one of very important tools for solving congestion
situations. Mobile station decides about handovers measuring power of primary CPICH. Thus, changing CPICH
power level is the simplest way to control traffic load in a cell. Disadvantage of this method is that it is not
possible to make only selected calls remove the cell from their active sets. Controlling of CPICH may be
compared to coverage control [10].

5.3.6.2 AMR
Speech is a very special service. It requires real time transmission, but only narrow bandwidth is necessary.
Usually it should provide high quality of a sound, but if it is unavoidable, that quality may be lowered. The data
source (user) has typical ON/OFF characteristic: whole call is divided in silent and active parts. These features
were considered during speech codecs designing in 2G systems and are going to be used in 3G.
UMTS specification proposed Adaptive Multi-Rate technique to be implemented in speech codec. It allows
changing speech service data rate during call (there are several rates proposed, corresponding to different coding
schemes in 2G networks). Important thing is, that coding rate does not depend on speech activity, but is
controlled by the network. This allows the network to adjust the rate to reflect momentary transmission channel
conditions (interference and traffic load). AMR may be combined with discontinuous transmission (DTX) — it
monitors speech activity and switches transmitter off when user is silent. Beside of lowering interference level
that mechanism allows prolonging mobile station battery life [10].
Decision about selecting or changing codec mode should be made within UTRAN (preferably in RNC), because
it is the only part of UMTS network, where radio interface status is known [57].
5.3.6.3 Resource management in case of congestion

In UMTS, it is possible that RNC controlling mobile station and RNC controlling base station to which mobile
station is connected are two different RNC. The one controlling mobile station is called serving RNC (SRNC)
and the one controlling radio resources is called drift RNC (DRNC).
At the current state of specification, DRNC is provided with very limited amount of traffic information (because
it is “invisible” for the traffic). This causes that DRNC knows only maximum allowed data rate for mobile
station, but does not know minimum guaranteed data rate. Thus, it must allocate resources for maximum data
rate, although it may not be necessary.
Possible solution is to introduce mechanism, which would provide guaranteed data rate information for DRNC to
enable better dealing with congestion situations. If it would be necessary (e.g. decreasing data parameters to the
lowest level is not enough), DRNC should be able to ask SRNC to renegotiate QoS [58].

6 ANALYSIS OF EMERGING TECHNOLOGIES REQUIREMENTS
6.1 WAP
Current trends in telecommunications has enabled new kinds of functionalities in a wireless terminal; either
through the integration of new features into the terminal or by allowing new types of devices to be connected to
the terminal. Such a supportive development will only strengthen the WAP’s position as a platform for advanced
wireless data services by providing access to new capabilities.
The Wireless Application Protocol (WAP) is a result of continuous work to define an industry-wide specification
for developing applications that operate over wireless communication networks. The wireless market is growing
very quickly, and reaching new customers and services. To enable operators and manufacturers to meet the
challenges in advanced services, differentiation and fast/flexible service creation WAP has defined a set of
protocols for the transport, security, transaction, session and application layers.
The existing environment of WAP is the place within the terminal where applications are executed, either in the
form of WML pages or in the form of scripts or both. The most convenient way to facilitate the connection
between the application and new functionality of the terminal is to specify new standard services that can be
accessed by an application that is being executed in WAP application environment.
The External Functionality Interface (EFI) specifications in WAP provide methods enabling applications to
access External Functionality in a uniform way through the EFI Application Interface (EFI AI). The EFI
specifications consists of the Framework, the Process specification and a set of Class Specifications, each one
specific to the given application area.
EFI has defined a set of general behaviors of implementation in the WAP terminals while detailed requirements
for the class are provided in individual Class Specification documents. The Process specification facilitates the
development of Class Specifications by defining steps that should be taken in order to achieve the quality Class
Specification.
6.1.1 WAP terminal Architecture

An application environment within the WAP mobile client (wireless terminal) consists of several components.
The simplified relationship of those components is depicted below.
Client Web Server

WAP Gateway
WML Sc
WML Encoder CGI W rip
WML- Scripts M -t
WSP/WTP HTTP etc. L
wit
Script WMLScript h
Compiler De
W
WTAI cks
M
Protocol Adapters Content
L
Etc.
Figure 106: The WAP programming model

WAP provides several benefits to the application developer community, including a familiar programming
model, a proven architecture, and the ability to leverage existing tools (e.g. Web servers, XML tools, etc.).
Optimizations and extensions have been made in order to match the characteristics of the wireless environment.
Wherever possible, existing standards have been adopted or have been used as the starting point for the WAP
technology.
WAP content and applications are specified in a set of well-known content formats based on the familiar WWW
content formats. Content is transported using a set of standard communication protocols based on the WWW
communication protocols. A micro browser in the wireless terminal co-ordinates the user interface and is
analogous to a standard web browser.
WAP has defined a set of standard components that enable communication between mobile terminals and
network servers, including:
• Standard naming model – WWW-standard URLs are used to identify WAP content on origin servers.
WWW-standard URIs are used to identify local resources in a device, eg call control functions.
• Content typing – All WAP content is given a specific type consistent with WWW typing. This allows WAP
user agents to correctly process the content based on its type.
• Standard content formats – WAP content formats are based on WWW technology and include display
markup, calendar information, electronic business card objects, images and scripting language.
• Standard communication protocols – WAP communication protocols enable the communication of browser
requests from the mobile terminal to the network web server.
The WAP content types and protocols have been optimized for mass market, hand-held wireless devices. WAP
utilizes proxy technology to connect between the wireless domain and the WWW. The WAP proxy typically is
comprised of the following functionality:
• Protocol Gateway – The protocol gateway translates requests from the WAP protocol stack (WSP, WTP,
WTLS, and WDP) to the WWW protocol stack (HTTP and TCP/IP).
• Content Encoders and Decoders – The content encoders translate WAP content into compact encoded
formats to reduce the size of data over the network.
This infrastructure ensures that mobile terminal users can browse a wide variety of WAP content and
applications, and that the application author is able to build content services and applications that run on a large
base of mobile terminals. The WAP proxy allows content and applications to be hosted on standard WWW
servers and to be developed using proven WWW technologies such as CGI scripting.
While the nominal use of WAP will include a web server, WAP proxy and WAP client, the WAP architecture
can quite easily support other configurations. It is possible to create an origin server that includes the WAP
proxy functionality. Such a server might be used to facilitate end-to-end security solutions, or applications that
require better access control or a guarantee of responsiveness, e.g. WTA.

6.2 HSCSD
High Speed Circuit Switched Data answers the problem with current wireless data communications: bit rate.
Current applications, such as email and remote LAN access, as well as new applications, such as wireless
imaging and video, will benefit from higher bit rates.
HSCSD provides data throughput 6 times faster than that of current GSM data with only minor additional
investment. The air interface user rate in the original GSM data transmission is limited to 9.6 kbps with the 12
kbps air interface rate8. HSCSD allows higher air interface user rates to be used for transparent and non-
transparent data services.
HSCSD is a feature that enables the co-allocation of multiple full rate traffic channels (TCH/F) into a HSCSD
configuration: the aim of HSCSD is to provide a mixture of services with different air interface user rates by a
single physical layer structure.
Further improvements in data rates are achieved through enhancement of the radio interface (modulation and
coding schemes), which allows higher bit rates per one GSM time slot.
Compared to GSM, HSCSD technology adds:
• The co-allocation of multiple full rate traffic channels (TCH/F) into a HSCSD configuration (maximum
real number n = 4): this feature allows much higher speed rates than GSM but charging will be
proportional to the number of TCH/F used;
• A new channel-coding scheme: that increases the time-slot bitrate from the 9.6 kbit/s (GSM) to 14.4
kbit/s; this means that operators will be able to provide GSM users with a variety of new bitrates,
ranging from 9.6 kbit/s to 57.6 kbit/s;
• Flexible air interface resource allocation:
• Network side: the network is able to alter the air interface resource allocation (between one TCH/F
and the maximum number of TCH/F allowed) for the reasons of either lack of radio resource,
handover, and/or to maintain service quality;
• User side: the user may request, if so indicated during the call setup, the network to change the
current maximum number of traffic channels and air interface user rate parameters and/or channel
coding asymmetry preference.
Figure 107 represents the network architecture to support GSM HSCSD based on the concept of multiple
independent channels in one HSCSD configuration. HSCSD, being mainly a software upgrade (probably done
with remote access), does not entail new network elements and so the GSM operator avoids having to redesign
the network. However, the user does require a new terminal.
MS BTS BSC MSC

Air I/F Abis I/F A I/F
T
.. IWF
A
F
.
n full-rate channels
1 circuit maximum
or n time slots per TDMA frame
Figure 107: HSCSD network architecture
8 The term "air interface user rate" corresponds to the transfer rate in radio interface for user data and "air interface rate" includes additional
data related to transmission protocols.

A new functionality is introduced at the network and MS to provide the functions of combining and splitting the
data into separate data streams which will then be transferred via n channels at the radio interface, where in
theory n = 1, 2, 3, ... 8 (actually according to MS power requirements n = 1, … 4).
Once split, the data streams shall be carried by the n full rate traffic channels, called HSCSD channels, as if they
were independent of each other, until to the point in the network where they are combined. However, logically
the n full rate traffic channels at the radio interface belong to the same HSCSD configuration, and therefore they
shall be controlled as one radio link by the network for the purpose of cellular operations, e.g. handover. This
requires a new functionality in BSS.
On the A and E interfaces, the use of resources is restricted to one 64 kbps circuit by multiplexing the data
streams into one A interface circuit (see ITU-T Recommendation I.460 [ITU-T Recommendation I.460:
"Multiplexing, rate adaptation and support of existing interfaces".]).
The coexistence of HSCSD and pure GSM features may pose some issues concerning the share of the scarce
radio resources. It is interesting observing that, during peak hours, the pure GSM traffic is enough to reach high
levels of utilization of radio resources, therefore making problematic the provision of multiple timeslots for a
single HSCSD. The handover further complicates the scenario, in that the likelihood of finding multiple
timeslots in neighbor cells under high-intensity traffic may be quite low. Care must be taken in assigning the
priorities to the two types of traffic, to avoid that one types consumes an excessive amount of traffic resources,
leading the other type of traffic to overload.
6.2.1 List of constraints

This section provides a list constraints related to HSCSD system:
• Possible co-allocation of multiple full rate traffic channels (TCH/F) into a HSCSD
configuration (maximum real number n = 4);
• According to ETSI specification the channels may be allocated on either consecutive or non
consecutive time slots; for some vendors (for example Nokia), the HSCSD timeslots have to be
consecutive;
• Time-slot bitrate: 9.6 kbit/s and 14.4 kbit/s;
• The network may alter the air interface resource allocation (Flexible air interface resource
allocation):
For non-transparent as long as the configuration is not in contradiction with the
limiting values defined by the MS and the mobile equipment is capable of handling
the allocated channel configuration;
For transparent if the air interface user rate is kept constant.
• The MS may request a service level up- or downgrading for non-transparent HSCSD
connections only;
• HSCSD is mainly a software upgrade: it doesn’t require new network elements besides GSM
ones;
• The user requires a new terminal;
• The n full rate traffic channels shall be controlled as one radio link by the network for the
purpose of cellular operations, e.g. handover.
6.3 GPRS
GPRS uses a packet mode technique to transfer high-speed and low-speed data and signaling in an efficient
manner. In GPRS from 1 to 8 radio interface timeslots can be allocated per TDMA frame and up and downlink
timeslots can be allocated separately. The radio interface resources can be shared dynamically between speech
and data services as a function of service load and operator preferences. Four radio resources coding schemes are
specified to allow bit rates from 9 kbps to more than 150 kbps per user.
Applications based on standard data protocols are supported, and inter-working is defined with IP networks and
X.25 networks. Several QoS profiles are supported. Charging should typically be based on the amount of data
transferred.

Three GPRS MS modes of operations are defined: an MS in class-A mode of operation operates GPRS and other
GSM services simultaneously. An MS in class-B mode of operation monitors control channels for GPRS and
other GSM services simultaneously, but can only operate one set of services at one time. An MS in class-C mode
of operation exclusively operates GPRS services.
Shared GSM/GPRS resources

IP network
Pure GPRS resources GSM
resources
GPRS core
GSM BSC network
user
SGSN
BTS GGSN
GPRS SGSN
BSC
user
BTS
Figure 108: GPRS architecture
6.3.1 GPRS architecture

A snapshot of the GPRS system architecture, as it is described in the standard ETSI documents is shown in 6.3.1.
GPRS uses a packet mode technique to transfer high-speed and low-speed data and signaling in an efficient
manner. Packets are transmitted over the GSM radio interface, and compete for the radio channels together with
the GSM ordinary voice calls, which keep their circuit-switched service mode. The radio frequency resources are
shared dynamically between speech and data services as a function of service load and operator preferences.
GPRS introduces two new network nodes in the GSM PLMN:
• The Serving GPRS Support Node (SGSN), which is at the same hierarchical level as the MSC, keeps
track of the individual MSs' location and performs security functions and access control. The SGSN is
connected to the BSS with Frame Relay.
• The Gateway GPRS support node (GGSN) provides inter-working with external packet-switched
networks, and is connected with SGSN via an IP-based GPRS backbone network.
This GPRS core network is a private (i.e. with access control) IP-network. Within this network, data is sent as
packets in GPRS tunneling protocol (GTP). Some GSNs, the so-called SGSNs (Servicing GPRS Support
Nodes), roughly fulfill the same functionality as a MSC and a VLR in original GSM. Other GSNs, the so-called
GGSNs (Gateway GGSN Support Nodes), provide access to the external packet data networks (e.g. the public
Internet). All messages between GSNs are sent in GTP.
In order to access the GPRS services an MS first makes its presence known to the network by performing a
GPRS attach. This operation establishes a logical link between the MS and the SGSN, and makes the MS
available for SMS via GPRS, paging via SGSN and notification of incoming GPRS data.
In order to send and receive GPRS data, the MS activates the packet data address that it wants to use. This
operation makes the MS known in the corresponding GGSN, and inter-working with external data networks can
commence. User data is transferred transparently between MS and external networks with encapsulation and
tunneling.
Due to the existing competition for the scarce radio resources, the GSM traffic strongly influences the GPRS
performances. Evaluating the impact of such competition is an important step. The timeslots on a GPRS carrier
can be reserved for packet-switched GPRS use, reserved for GSM circuit-switched use only, or allocated as
switchable. The term switchable describes a timeslot that can be dynamically allocated for GPRS data service or

for circuit-switched service. The timeslot allocation is performed such that the GPRS reserved timeslots are
allocated for GPRS use before switchable timeslots. Similarly, GSM circuit-switched timeslots are allocated to
the circuit-switched calls before switchable timeslots. The switchable timeslots are allocated only when there are
no reserved timeslots available anymore, with priority given to circuit-switched calls, which means that GPRS
calls may be dropped out of service to satisfy GSM resources requests.
In the first deployments of GPRS systems, the wireless operators will be using quite a cautious approach in terms
of resource assignment, not to jeopardize the circuit-switched traffic revenues in exchange for the uncertain
gains of the new data transfer technology. Therefore, very few resources will be allocated as reserved for GPRS
packet-switched traffic. In the future, it will be necessary to allocate some reserved timeslots and the number of
them will depend on the operators’ policies and on the GPRS traffic intensity in a specific cluster of cells.
Besides the number of reserved timeslots, the number G of users that can share a timeslot also affects the per-
user data transfer capacity across the radio interface.
Thus, a proper choice on how many traffic timeslots have to be reserved for achieving given levels of service
availability and quality is not trivial at all, and needs to be studied in order to avoid GSM to occupy an excessive
amount of radio resources, leading GPRS to congestion

This section provides a list constraints related to GPRS system:
• The maximum theoretical data transmission speed over GPRS is 171.2 kbps. To achieve this
maximum speed would require eight timeslots using a Coding Scheme 4 (CS-4) channel
coding scheme that incorporates no error protection. Clearly, it is highly unlikely that a
network operator will assign all the timeslots to GPRS usage rather than voice.
• Additionally, the initial GPRS terminals will support point-to-point, alternate GPRS or GSM,
and alternate receive or transmit operation (known as Phase 1, Type 1, Class B operation). In
fact, only a subset of Type 1 classes will be supported since it is unlikely that any terminals
will support more than two transmit timeslots. Since they will support few timeslots, initial
GPRS terminals will therefore severely limit the bandwidth available to the GPRS user.
• Voice and GPRS calls both use the same network resources in the BSS subsystem. The extent
of the impact depends upon the number of timeslots, if any, that are reserved for exclusive use
of GPRS
• Whereas the Store and Forward Engine in the Short Message Service is the heart of the SMS
Center and key feature of the SMS data service, there is no storage mechanism incorporated
into the GPRS standard, apart from the incorporation of interconnection links between SMS
and GPRS.
• In Phase 1 point-to-point GPRS (sending information to a single GPRS user) will be
supported, but not point to multipoint (sending the same information to several GPRS users at
the same time).
6.4 EDGE/EGPRS
In EDGE and EGPRS system different coding schemes are allowed in order to support higher data rate. GPRS is
based on a modulation technique known as Gaussian minimum-shift keying (GMSK). EDGE is based on a new
modulation scheme that allows a much higher bit rate across the air interface- this is called eight-phase-shift
keying (8 PSK) modulation. Since 8 PSK will also be used for 3GSM, network operators will need to
incorporate it at some stage to make the transition to third generation mobile phone systems. The GPRS and
EDGE coding schemes are represented in the following table.

Table 43: EDGE and GPRS coding schemes
S chem e M o d u la tio n M a x im u m r a te (K b /s ) p e r tim e s lo t

M C S -9 5 9 .2
M C S -8 5 4 .4
8PSK
M C S -7 4 4 .8
M C S -6 2 9 .6
M C S -5 2 2 .4
M C S -4 1 7 .6
M C S -3 G M SK 1 4 .8
M C S -2 1 1 .2
M C S -1 8 .8
In the EGPRS system up to 8 timeslot can be dedicated to a single user with the coding schemes MCS-9
reaching the maximum speed of 473.6 Kb/s.

The limitations listed for the GPRS system are also pertinent for EDGE and EGPRS system. For instance is
highly unlikely that a network operator will assign all the timeslots to EGPRS usage with jeopardizing voice
traffic requirements satisfaction.

6.5 UMTS requirements
6.5.1 General
The differences in the underlying technologies in GSM and UMTS imply many differences in the operation of
the networks. The combined time and frequency division multiple access (TDMA/FDMA) technology used in
GSM is simpler than the code division multiple access (CDMA) used in UMTS. The CDMA technology poses
new requirements for the network in the form of a lot higher transmission power control command rate (1500 Hz
in UMTS). Also, more complex handover algorithms (soft handover) and the necessity for advanced admission
and congestion control algorithms are needed. The benefit for all these awkward procedures is dynamic capacity
and more efficient usage of radio resources. The coexistence of GSM and UMTS networks is a likely scenario in
the future. In the rural areas, the demand for high data rate multimedia services is essentially lower than in
densely populated urban center. Thus, GSM could be sufficient in the rural areas whereas in the city center both
GSM and UMTS would be used.
6.5.1.1 Frequency and time division duplexing

The UMTS encompasses two different possibilities for separating the downlink and uplink transmissions. The
first one, frequency division duplexing (FDD), uses different 5 MHz spectral bands for transmissions in different
directions and the second one, time division duplexing (TDD), requires only one 5 MHz frequency band but
allocates different time slots for transmissions in different directions. The latter approach is more complicated
but it is motivated by the asymmetric traffic of WWW browsing where most of the data transmission takes place
from base stations to mobile stations. In the frequency division duplexing, superfluous radio resources are
wasted if most of the traffic is asymmetric. However, the FDD model will be the principal mode of operation and
this study is focused on that from now on. All references to UMTS should be understood to imply FDD mode
even though that is not explicitly stated.
6.5.2 UMTS network structure

6.5.2.1 Network elements and structure
Underneath picture presents general logical UMTS architecture according to Release 99 (R99) specification.
This release will be probably implemented in most networks at the first stage of UMTS operations, because it
does not require replacing existing GSM/GPRS core network (it is necessary to upgrade some elements).
Further, when UTRAN will work properly R99 core network will evolve to Release 2000 (R00 or Release 4).
However, then UTRAN will remain [61, 62].
UTRAN CN
Node–B
MSC/ VLR GMSC PSTN
RNC
Node–B
Iur HLR
IP
SGSN GGSN
Node–B RNC X.25
Uu Iub Iu
Figure 109: General UMTS network architecture (R99)

6.5.2.1.1 Blocks
UTRAN: (UMTS Terrestrial Radio Access Network) it contains all elements of UMTS network responsible for
radio network functionality. It is the new part of R99 UMTS network (on the contrary to core network).
CN: (Core Network) it contains elements providing telecommunication network functionality. In R99, it consists
of the elements existing in GSM/GPRS network. However, some of those elements are upgraded to enable
offering UMTS services (e.g. new cards in MSC and SGSN supporting Iu interface).
6.5.2.1.2 Nodes
UE (User Equipment): this is a name for UMTS terminal. It describes mobile equipment (which is capable to
communicate over radio interface) containing at least one UMTS SIM card (USIM), which identifies user.
Node–B: this is a name introduced in UTRAN specification for UMTS base station. Node–B has similar
functionality and features like BTS (GSM) — it is responsible for radio functions, like reception and
transmission from and to UE. Base station can consist of several (typically three) sectors (cells) or work as one
sector (cell).
RNC (Radio Network Controller): this is similar to BSC (GSM). RNC controls Node–Bs. Every Node–B is
controlled by only one RNC, which is the controlling RNC (CRNC) for that Node–B. CRNC manages logical
resources of its Nodes–B. CRNC with its Nodes–B is defined as radio network subsystem (RNS). From user
point of view RNS can work as serving RNS (SRNS) or drift RNS (DRNS). SRNS is RNS, which is responsible
for radio connection to the user and maintain his connection to CN. It may happen that user is communicating to
Nodes–B belonging to other RNS that the one through which he is connected to CN. In that case, that other RNS
is working as DRNS.
HLR (Home Location Registry): it stores information about all subscribers of the network. It supports other
elements of the network providing the information (e.g. information about subscribed services).
GGSN (Gateway GPRS Support Node): it provides access to external packet networks for packet services.
SGSN (Serving GPRS Support Node): it has functionality necessary for providing mobile packet services.
MSC/VLR (Mobile Switching Centre / Visitors Location Registry): it has functionality necessary for providing
circuit switched services. VLR stores data about users connecting through the MSC (downloaded from HLR).
GMSC (Gateway MSC): it provides access to external circuit switched networks.
6.5.2.1.3 Interfaces
Uu: radio interface (like Um in GSM).
Iu: interface connecting UTRAN and CN. Can appear in two versions: packed switched Iu (connecting UTRAN
with SGSN in R99 — like Gb in GSM) and circuit switched Iu (connecting UTRAN and MSC in R99 — like A
in GSM).
Iub: interface connecting RNC and its Nodes–B (like Abis in GSM).
Iur: new UMTS interface connecting RNSs. It is required for inter–RNC synchronisation, soft handover, and
radio resource handling [59].
Interfaces connecting CN elements are the same as specified in GSM/GPRS standards.

6.5.2.2 Measurement exchange

Radio interface measurements are performed in UE and in UTRAN (because CN is designed to be independent
from radio access network). UE and UTRAN are capable of performing following measurements [60]:
UE (not all are performed all the time):
• Received Signal Code Power (RSCP): the received power on one code measured on the primary CPICH and
PCCPCH (TDD).
• Received Signal Strength Indicator (RSSI): the wide-band received power within the relevant channel
bandwidth (measured for UMTS and GSM BCCH).
• CPICH Ec/N0: RSCP/RSSI ratio measured on primary CPICH.
• Transport channel BLER (based on CRC).
• Total UE transmitted power per carrier.
• Observed time differences (several types: within UMTS and comparisons to GSM).
• Time (GPS) of occurrence of specific UTRAN events (e.g. beginning of transmission of some frame).
UTRAN:
• Total received power (including receiver noise) within measured bandwidth.

• SIR and SIR error (difference between SIS and SIR target).
• Transmitted carrier power: the ratio between the total transmitted power and the maximum transmission
power.
• Transmitted code power: the transmitted power on one channelisation code on one given scrambling code
on one given carrier.
• BER (for transport and physical channels).
• Round Trip Time (RTT): difference between sending a frame and receiving an answer from UE.
• Time (GPS) of occurrence of specific UTRAN events (e.g. beginning of transmission of some frame).
• Observed time differences (within UMTS).
• PRACH and PCPCH propagation times.
• Acknowledged PRACH preambles: defined as the total number of acknowledged PRACH preambles per
access frame per PRACH.
• Detected PCPCH access preambles: defined as the total number of detected access preambles per access
frame on the PCPCHs belonging to a CPCH set.
• Acknowledged PCPCH access preambles: defined as the total number of acknowledged PCPCH access
preambles per access frame on the PCPCHs belonging to a spreading factor.
Most of those measurements are important from resource management point of view. For radio resouces
management especially important are all measurements concerning received and transmitted power level, BER,
BLER, SIR and SIR error. But other, like time differences, RTT and propagation times are useful, too.
6.5.2.3 Capacity limiting parts

Interfaces may be divided for radio and fixed connections. The latter is much larger, logically divided for fixed
UTRAN part, core network and interfaces connecting them. Fixed interfaces are built using standard
technologies, which are well known and used, easily scalable and cheap. When an interface reaches its capacity
it can be either replaced with links of higher capacity or a new, parallel link can be added (it usually requires
addition of proper interface cards in connected nodes). So interfaces capacity is limited only by capacities of the
nodes, which depend on vendors’ solutions. Some of the interfaces are only logically distinguishable, because
vendors offer equipment, which combine in one physical rack, several logical elements (e.g. Combined GSN —
CGSN — which is mixture of SGSN and GGSN). Capacity of such an invisible interface is limited only by
combined node capacity (what, again, depends on vendor’s solution).

In case of radio interface the situations is completely different. It is standardized very precisely and the standard
introduces constraints limiting interface capacity. Vendors can just try to implement mechanisms allowing better
utilization of available capacity, but the technology is new and has not been tested commercially yet. On the
other hand, most of the traffic transmitted in UMTS network (both, user data and signaling) goes through air, so
the interface is heavily loaded.
Therefore, Uu is very important interface on one hand, but on the other, its practical performance is unknown.
The only known thing is that its capacity is limited. So research concerning air interface capacity and its efficient
utilization are very important now, when it is still possible to propose new algorithms for radio resource
management.
6.5.3 Air interface
6.5.3.1 Capacity analysis

CDMA radio network capacity is often described as soft. Number of scrambling codes limits the number of
simultaneous calls in uplink, but it is rather theoretical constraint. That means that there is no strict limit for
number of users, which can be served in a cell. The only limit is service quality and system stability (since
admitting too many users can lead to coverage waving [33]). Thus, UMTS capacity means the capacity of the
cell or network, when QoS level is still acceptable. In this chapter some analysis concerning the capacity is
presented.
Capacity depends on many factors. In [31] some of them are presented. Noise, which limits uplink, does not
increases linearly with increasing number of users. After crossing a certain limit (6 dB in the simulation) it starts
to increase much faster and levels again when most mobile stations reach their maximum output power. With
rapid noise rise, fraction of good uplink connections decreases. Cell size limits the capacity, too. Increasing
average cell diameter (inter–base station distance) causes decreasing the number of good uplink connections.
The same happens to downlink, but much slower. The noise is higher and higher, when cell diameter increases,
but only until most mobile stations reach their maximum transmitter power — afterwards its characteristic is
almost flat. Propagation loss exponent also limits the capacity. It directly defines maximum reasonable cell size:
the stronger signals are reduced with the distance, the smaller cell can be. Other parameters are analyzed in [34].
Active set size (soft handover) does not influence cell capacity when traffic load is relatively low. However,
large active set helps maintain high fraction of satisfied users when traffic load increases. The only exception is
active set limited to one base station (hard handover) — even when traffic load is low the number of satisfied
users is smaller than in the case of bigger active set. The environment (indoor or outdoor) does not change
gained characteristics.
As it has already been mentioned, the capacity is defined by QoS level. One of QoS factors is SIR. Influence of
Doppler bandwidth is presented in [32]. It is shown, that the more frequent Doppler fades are, the higher
standard deviation of SIR level of users suffering the worst radio conditions is.
Different services require different bandwidths and generate different types of interference. Simulations show
that the only way to maintain service QoS in a cell is to implement constraints for capacity. Results of different
scenarios (street / office, data / speech, pedestrian / vehicular) allow predicting that data services will be the most
responsible for noise rise and therefore, for uplink capacity limits [33].
Most simulations show that the capacity of uplink connection is more limited than of downlink. However,
downlink capacity may not be skipped during capacity analysis, because the most popular data services (like web
browsing or file downloading) are very asymmetric: bandwidth demands for downlink are much higher than for
uplink.

6.5.3.2 Implications of different service types

6.5.3.2.1 General
UMTS enables the usage of different service types such as real-time video and WWW browsing in addition to
normal speech calls. A relevant difference in comparison to normal GSM is packet-switched data calls. Also, the
transmission bit rates in UMTS are considerably higher than in GSM. Some of these features will already be
available in the GSM improvements (GPRS) but UMTS will further enhance them.
These new service types require new traffic modeling methods and approaches. The experience gained from
GSM can be utilized to some extent.
Basic UMTS services can be divided to bearer services and teleservices. This distinction is general for all
telecommunication networks. Basic services can be supported with supplementary services. Supplementary
service can exist only as a basic service extension.
Bearer services provide the capability for data transfer using lower layer functions. Teleservices are offered to
users and may be used either directly, or via user applications. Different types of teleservices are based on
different bearer services, which provide the most adequate transport capabilities. Bearer services are defined
with different characteristics and required QoS. Those characteristics consist of, among others, transfer rate,
BER and delay. By now, only a few teleservices have been defined [56]:
• Speech;
• Emergency call;
• SMS service (point–to–point and broadcast);
Requirements for Internet access are defined, too.
This set will be for sure extended in future with both new standardized services and specific operator services.
UMTS standards do not constrain usage of provided bearer services (within technical limits).
6.5.3.2.2 QoS and services examples

QoS is provided based on bearer service and its characteristics. Based on presently defined teleservices and
trying to foresee new ones four general QoS classes were defined:
• Conversational class: This is designed for real–time services with close to constant transfer rate
(guaranteed). Acceptable delay is given by human perception. This QoS is applicable especially for speech
(and multimedia calls, involving video beside speech), VoIP, real–time controlling, etc.
• Streaming class: This is predestined for one–way services, which requires guaranteed data rate and
preserving time characteristic of the stream. However, delays are not so important in this case. This QoS is
designed especially for multimedia broadcast services, like TV or radio.
• Interactive class: This type of QoS is defines maximum allowed delay, but data rate may not be guaranteed
(or guaranteed on low level). This characteristic is applicable for services, where user communicates with
remote information source or controls non–real–time devices. So content preserving must be guaranteed.
For example web browsing would be satisfied with this QoS.
• Background class: This is QoS class with the lowest demands. Generally only payload preserving should be
guaranteed, other requirements (if exist) must be provided by applications using the QoS. This is designed
for communication, in which destination party is not expecting any transmission. It happens in case of
messaging services, like SMS or e–mail. Background downloading (like FTP) can use this QoS, too.
There is a set of guaranteed parameters (with both maximum and minimum values, or only one of them)
assigned to every QoS class (e.g. guaranteed and maximum bitrate, allowed error rates of different types, traffic

handling priority and transfer delay). This set is the biggest in case of conversational class and the smallest in
case of background class. Many services and applications have different requirements for uplink and downlink,
so in case of bi-directional communication it should be possible to set different values for some QoS parameters
[68].
UMTS QoS allows to support 2G services, what is necessary — probably for some time 2G and 3G will coexist
and inter–domain handovers will be quite frequent.
It will be possible to initiate several services simultaneously — for example answer video calls during web
browsing and hearing to a radio. In that case for each ongoing call (active service) separate QoS is provided.
However, it must be noted that some attributes of QoS sum up (e.g. bitrate — because of mobile station
capabilities).
6.5.3.2.3 Range of QoS parameters

Transfer delay and BER are defined differently for real–time and non–real–time services. In case of the real–
time the delay variation must be very small, when in case of the non–real–time it may vary. BER limits depends
on service demands, but those defines as well whether the service is real–time, or non–real–time.
For real–time services the delay should not be longer than 400 ms in case of satellite segment and can be
guaranteed within 20 ms through 300 ms range in all terrestrial radio environments. In both satellite and
terrestrial environments BER may be guaranteed within 10-3 through 10-7 range. For non–real–time services max.
transfer delay may be 1200 ms in case of satellite segment and 150 ms in all other environments, or longer. BER
may be guaranteed within 10-5 through 10-8 range.
Those values must be taken into account when radio resource management algorithms are designed. To enable
maintaining proper QoS level it is necessary to implement traffic control and admission control mechanisms.
Transfer bit rate guarantees depends on radio environment, in which mobile station operates. In case of satellite
and rural environment it should be possible to provide at least 144 kb/s (for satellite it may be achieved only
when mobile station operates in nomadic mode), 384 kb/s in urban and suburban areas and over 2 Mb/s indoors
(or very close to base station). Those values defines total bitrate per mobile station (sum of bitrates of all
ongoing calls) [56].
The higher data rate the lower spreading factor is. Thus, high data rate services increases interference level,
what limits cell capacity. In the worst case it may happen that some calls from the biggest distances will be
dropped when someone begins high data rate call — it looks like cell coverage is decreasing. Although those
dropped calls may be still supported by other base station (only if those mobile stations are in soft–handover
mode) it may be impossible to maintain QoS of their calls. To prevent such behaviour good (well tested in
simulations and trials) traffic control algorithms ought to be implemented.
6.5.3.2.4 Circuit and packet switching

In 2G networks all services can be divided for two groups: circuit and packet switched (CS and PS). This
approach is based on characteristics of the services (quality requirements). To support these two groups whole
core network is divided for CS (MSC, GMSC) and PS (GSNs) domains. This distinction exists in UMTS, too.
Although in R00 whole core network is going to be based on packet switching, separate domains for CS and PS
exist [62].
The fact whether a service is rather circuit switched or packet switched has an impact on resource management.
To achieve stable data rate and delay special algorithms have to be used (e.g. permanent resource allocation all
the time the service is active).
Nowadays the distinction for circuit and packet switched services is losing meaning in favor of QoS, because
more and more services, even traditionally circuit switched are implemented based on packet bearers (e.g.
speech and VoIP).

6.5.3.3 Implications of UMTS features
6.5.3.3.1 Different channels

There are logical, transport and physical channels in UMTS FDD. Their hierarchy is depicted in Figure 110. The
physical layer (PHY) offers services to the medium access control (MAC) protocol via transport channels. The
MAC layer, on the other hand, provides services on logical channels to radio link control (RLC) protocol. The
physical layer is the lowest layer (L1) and MAC and RLC belong to the second lowest layer (L2).
RLC
RLC L2
logical channels
MAC
MAC L2
transport channels
PHY
PHY L1
Figure 110. UMTS FDD low-level protocol layer structure.
The air interface problems arise from the shortage of physical channels, which are ultimately connected to the
available spectral bandwidth resources. However, the two channel layers of UMTS FDD above the physical
layer—logical and transport channels—are briefly described in [66] and [63], [65], respectively. The directions
of the channels are shown and also the mapping of logical channels to transport channels is indicated. One
logical channel can be mapped to several transport channels and, conversely, several logical channels can
correspond to one transport channel.
Table 44: Logical channels of UMTS FDD

Logical channel Acronym Dir.
Broadcast Control Channel BCCH DL
Paging Control Channel PCCH DL
Dedicated Control Channel DCCH UL/DL
Common Control Channel CCCH UL/DL
Dedicated Traffic Channel DTCH UL/DL
Common Traffic Channel CTCH DL
Table 45: Transport channels of UMTS FDD

Transport channel Acronym Dir. Logical channel(s)
mapped
Dedicated Channel DCH UL/DL DCCH, DTCH
Broadcast Channel BCH DL BCCH
Forward Access Channel FACH DL BCCH, CCCH,
DCCH, DTCH,
CTCH
Paging Channel PCH DL PCCH
Random Access Channel RACH UL CCCH, DCCH,
DTCH
Common Packet Channel CPCH UL DCCH, DTCH
Downlink Shared DSCH DL DCCH, DTCH
Channel

A physical channel consists of a carrier frequency, scrambling code, canalization code, start and stop time and
relative phase (in the uplink direction) [63]. A summary of all physical channels of UMTS FDD is shown in
Table 46 [63], [64] with technical characteristics such as transmission direction (uplink or downlink or both) and
information about spreading and scrambling code usage.
Table 46. Physical channels of UMTS FDD.

Physical Channel Acronym Dir. Description Transport
channel(s)
carried
Dedicated Physical Data DPCCH UL I/Q code multiplexed, spreading factor DCH
Channel may range from 256 to 4.
Dedicated Physical DPDCH UL I/Q code multiplexed, channelization DCH
Control Channel code always Cch,256,0..
Physical Random Access PRACH UL Transmission based on Slotted ALOHA RACH
Channel approach. Open-loop power control
used. Spreading factor 256 for the
preamble, spreading factor 256 for the
message control part and spreading
factor between 256 and 32 for the
message data part.
Physical Common Packet PCPCH UL Transmission based on DSMA-CD CPCH
Channel approach. Spreading code Cch,256,0 for the
message control part, spreading factor
between 256 and 4 for the message data
part.
Downlink Dedicated DPCH DL Spreading factor may range from 512 to DCH
Physical Channel 4. Contains time-multiplexed DPDCH
and DPCCH.
Primary Common Pilot P-CPICH DL Fixed channelization code Cch,256,0. —
Channel Primary scrambling code.
Secondary Common Pilot S-CPICH DL Arbitrary channelization code of —
Channel spreading factor 256. Either primary or
secondary scrambling code.
Primary Common Control P-CCPCH DL Fixed channelization code Cch,256,1. BCH
Physical Channel
Secondary Common S-CCPCH DL Spreading factor may range from 256 to FACH and PCH
Control Physical Channel 4. No inner-loop power control.
Synchronization Channel SCH DL —
Physical Downlink PDSCH DL Spreading factor may range from 256 to
Shared Channel 4.
Acquisition Indicator AICH DL Spreading factor always 256. —
Channel
Access Preamble AP-AICH DL Spreading factor always 256 (same or —
Acquisition Indicator different code as in AICH).
Channel
Collision Detection CD/CA- DL Spreading factor always 256. —
Channel Assignment ICH
Indicator Channel
Paging Indicator Channel PICH DL Spreading factor always 256. —
CPCH Status Indicator CSICH DL Spreading factor always 256. —
Channel

6.5.3.3.2 Dedicated channels

The dedicated channels are the most important means for data transmission in the uplink as well as downlink
direction. In the uplink, the dedicated physical data channel (DPDCH) and the dedicated physical control
channel (DPCCH) are I/Q code multiplexed and in the downlink there is one channel called downlink dedicated
physical channel (DPCH), which is in practice a time-multiplex of DPDCH and DPCCH.
In the downlink, the spreading factors of the OVSF codes can range from 512 to 4 and in the uplink from 256 to
4. In the uplink, one mobile station has the whole OVSF code tree at its disposal but in the downlink the OVSF
(or channelization) code tree is shared between all mobile stations connected to the base station [64]. Thus, in the
downlink, there is a limitation on the number of channelization codes available and this might present a problem.
However, in practice, the interference situation in the network is likely to become more severe limiting factor
before all the OVSF codes are consumed. And even if it does not, another scrambling code can be used for the
base station to obtain a new OVSF code tree, which is then, however, not orthogonal to the first one. Also, a new
carrier could be added to the base station. Especially for bursty packet data the downlink shared channel presents
a code saving option for data transmission. In the uplink, the spreading factor in the DPDCH can vary from
frame to frame but in the downlink it cannot (however, in the downlink shared channel it can).
The initial uplink power of the DPCCH is chosen in the following way [67]
DPCCH_Initial_power = DPCCH_Power_offset – CPICH_RSCP, (1)

where DPCCH_Power_offset is received as a parameter and CPICH_RSCP denotes received signal code power
for the common pilot channel. After that, the closed loop power control takes care of keeping the transmission
power at an appropriate level.
The dedicated channels are the primary means for data transmission and most of the resource management
requirements concern them. The underlying CDMA technology and the UMTS features offer the possibility to
use efficient resource management with mobile station users that are connected to base stations on dedicated
channels. The features include fast closed loop power control and soft handover. Good algorithms are required to
take advantage of these.
6.5.3.3.3 Call request and random access procedure

The random access procedure is used in UMTS to request for a dedicated traffic channel for initiating the data
transmission. The random access is based on Slotted ALOHA approach where the mobile station can start the
transmission at certain times in certain access slots. The random access transmission consists of preambles (one
or more) and message part (10 ms or 20 ms in duration). The message part is further divided into data and
control parts.
The initial transmission power of the PRACH is set by open-loop power control and has a very large uncertainty.
Fading channel conditions deteriorate the situation further. The initial power setting is done according to the
equation below [67]
Preamble_Initial_Power = Primary CPICH DL TX power –

- CPICH_RSCP + UL interference + Constant Value (2)
,where CPICH refers to the common pilot channel and CPICH_RSCP denotes received signal code power for the
common pilot channel [69]. If the access is not detected by the base station, the transmission power for the next
preamble transmission is increased. If it is detected, the base station sends positive or negative response in
AICH. The problem with random access procedure is that it has to be detected from the interference caused by
uplink traffic channels. Also, since the random access procedure is based on ALOHA approach, collisions of
random access requests can occur. Furthermore, it is possible to make a erroneous decision and interpret noise as
a random access. In addition to the initial PRACH power setting, the way in which the PRACH power is
adjusted in subsequent access attempts is important. The procedure is illustrated in Figure 111 [42].

power
increment
BS detects
initial the request
MS
power
preambles message
BS
AICH
(ack/nack)
Figure 111: Random access procedure.
In [41] the random access procedure has been studied from the point of view of different access priorities. Three
different access priority mechanisms have been evaluated by simulations. They cause some mobiles to delay
their access request or allow them to use only a subset of RACH slots and signatures thus giving rise to different
priority classes. In [40] an improved power ramping scheme is studied. It is based on using multiple thresholds
for the random access request detection and taking different actions based on results. The mean access time and
mean total spend energy in the random access procedure have been investigated in [9]. They are shown to
depend on the initial PRACH power and the power increment used in subsequent access request and optimum
values for those are obtained with simulations. Thus, if too low an initial power is chosen, the request is not
detected by the base station and multiple power increments have to be performed. If, on the other hand, the
initial power is very high, it causes unnecessary interference.
Some of the parameters related to the random access request are listed below [42]
• Initial preamble power (the power used in the first preamble transmission)
• Power-ramping factor (the power step used to increase the preamble transmission power in subsequent
requests)
• Power offset (the power difference between the last preamble and the control part of the random access
message)
• Maximum number of preamble transmissions (indicates how many times at most the preamble transmission
is attempted)
Under high load, the detection of call requests might pose a problem. Thus, the priority schemes and power
ramping methods can be important factors from the point of view of call request success. If the random access
procedure is simulated, it is very important to model the interference caused by random access requests as well
as ongoing calls accurately in order to obtain realistic performance estimates.
6.5.3.3.4 Packet transmission using common packet channel

The common packet channel (CPCH), which is carried in the physical common packet channel (PCPCH), can be
used to send packet data in the uplink direction. The possible application areas could be e-mail, ftp and WWW
applications. The efficiency of the CPCH in comparison to dedicated traffic channels is dependent on the traffic
characteristics such as packet data burstyness: the more burstiness the more advantageous it is to use CPCH. The
advantage of CPCH in comparison to RACH is better collision avoidance system and the possibility to use inner-
loop power control. Comparison of CPCH/FACH to DCH/DCH+DSCH is presented in [44].

The access procedure is in some ways reminiscent of the random access procedure but better collision detection
is required in case of CPCH because the data transmission can last longer than in RACH. The access procedure
for CPCH is illustrated in Figure 112. The access procedure starts with power ramping as in PRACH, too. After
that, either acceptance or rejection is received in AP-AICH. However, the message transmission is not yet started
after this but, instead, a collision resolution phase begins.
power
increment
BS detects
initial the request
MS
power
preambles CD preamble power control message

preamble (optional)
BS
AP-AICH CD/CA-ICH
(ack/nack)
Figure 112: Common packet channel access procedure.
Multiple mobile stations might have used the same access preamble signature and thus have entered the collision
resolution phase. In the collision resolution phase, the mobile station randomly selects a signature from the
signature set and a CD access slot sub-channel and then transmits collision detection (CD) preamble with the
same power as the last access preamble. The base station replies with CD/CA-ICH channel to the CD preamble.
The probability of colliding after reaching the CD phase is very low. Then an optional power control preamble is
sent using power that is a specified step higher than the power of the CD preamble. The power control preamble
is used to correct the errors in the open-loop power control that was used to set the initial transmission power.
After thte optional power control preamble transmission, the transmission of the message part is started
immediately. In the message part, inner-loop power control can be used [42] and a downlink control channel
(DPCCH) is associated with the uplink common packet channel (PCPCH).
Two other issues are still related to the common packet channel access: channel assignment and status
monitoring [42]. When channel assignment is used, the base station can specify in the reply in AP-AICH the free
channel in addition to sending acknowledgement (ack). In status monitoring, the base stations sends status
information about the occupancy of the common packet channels to the mobile stations in CPCH Status
Indicator Channel (CSICH). Their effect on the performance has been investigated in [43].
Some of the parameters related to the common packet channel procedure are listed below [42]
• Initial preamble power (the power used in the first preamble transmission
• Power step size (for each successive CPCH access preamble)
• Power offset (the power difference between the last preamble and the initial transmission power of the
CPCH power control preamble, if used, or the control part of the CPCH message)
• Maximum number of preamble transmissions (indicates how many times at most the preamble transmission
is attempted)
The problems associated with the common packet channel are, for example, the efficient usage of available
common packet channels especially in congestion situations. The optional channel assignment strategy can

alleviate this problem but it also brings more complexity to the implementation. Also, the status monitoring can
help but in addition to complexity, interpretation errors of the status information can deteriorate the performance.
Thus, there is the requirement to set optimal values for the parameters that can be controlled if the common
packet channel is used for data transmission.
6.5.3.3.5 Packet transmission using downlink shared channel

Transmission of very bursty packet data in the downlink direction using dedicated channels poses some
problems. The limited number of downlink channelization codes (OVSF codes) can be easily consumed even
though often there might be nothing to transmit. Thus, reserving a certain OVSF code exclusively for one packet
user is not very efficient and there exists easily a discrepancy between the allocated OVSF codes and actually
allocated resources.
The problem can be tackled by using downlink-shared channel (DSCH) carried in physical downlink shared
channel (PDSCH) to share the downlink capacity between multiple users. The DSCH capacity can be shared on
a frame-by-frame basis to different users and different bit rates. One DSCH can even be mapped to multiple
parallel PDSCHs [64]. The DSCH usage has been evaluated in [45].
The downlink-shared channel obviously requires good resource management since it cannot guarantee 100 %
service availability. If the activity percentage for some user is very low, it is suitable for using the shared
channel. Services that require the availability of the channel almost all the time should take advantage of
dedicated channels.
6.5.3.3.6 Common pilot channel, common control channels and synchronization

channel
The common pilot channel (CPICH) has two different forms in UMTS: primary common pilot channel (P-
CPICH) and secondary common pilot channel (S-CPICH). The P-CPICH always uses the primary scrambling
code and the S-CPICH can use either the primary or secondary scrambling code. Both of the channels are spread
with OVSF code of spreading factor 256 [64]. Thus, CPICH remains (at least in principle) orthogonal to other
downlink channels such as DPCH.
The primary and secondary synchronization channels are scrambled with primary scrambling code but instead of
OVSF code spreading other codes are used for them. The synchronization channels are transmitted only in the
beginning of the slots.
The primary common control physical channel (P-CCPCH) is used to carry BCH and the secondary common
control physical channel (S-CCPCH) FACH and PCH. The fixed spreading factor of 256 is used for P-CCPCH
but the spreading factor of S-CCPCH can vary from 256 to 4 depending on the data rate required. Also, P-
CCPCH is transmitted almost all the time (excluding the beginning of each slot when the synchronization
channel is transmitted) but S-CCPCH is only transmitted when there is data to transmit. The transmission times
for P-CPCCH, P-SCH, S-SCH and CPICH are illustrated in Figure 113 [64].

P-CPCCH
P-SCH
S-SCH
CPICH
Figure 113. Transmission times for some channels.
The CPICH is used in initial cell search and for handover decisions. However, since it shares the same physical
resources as the dedicated channels, it causes interference to them. The CPICH power can be used to adjust the
cell size by affecting the handover regions but the power should be carefully managed in order not to deteriorate
the performance of the traffic channels. Also, the code and time acquisition time depend on the powers allocated
to the synchronization and common pilot channels. Higher power allocations to these channels result in faster
acquisition time (cell search) but cause more interference to traffic channels. This has been studied in [46].
6.5.3.3.7 Location updates

Some signaling procedures may have an impact on radio resource allocation. Location update is one of them.
When mobile station initiates a call, it first requests access on RACH (ref. 6.5.3.3.3). The interference caused by
the random access procedure has been studied in [9]. Initial power level is calculated based on information
received from the network and performed measurements of CPICH power level. When first power control
information is received from network closed loop power control is started [67].
In UMTS location update consist of cell update or UTRAN Registration Area (URA) update. Those procedures
are performed only if mobile station is in RRC connected mode (states Cell_PCH or URA_PCH). Cell update is
performed on:
• Initialization of uplink data transmission;

• Paging reception;
• Re–entering service area before location update timer expiry;
• Occurrence of radio link or RLC error;
• Cell reselection;
• Periodical cell update (range: 5 min. through 12 hours, or no periodic update);
If one of the triggers occur mobile station sends on CCCH/RACH Cell Update message. Response is sent on
DCCH/FACH or on CCCH/FACH. The procedure may end now, but sometimes-mobile station sends
“Complete” message on DCCH/RACH (when network sends some additional information, which have to be
confirmed).
URA update is performed on:
• URA reselection (cell reselection, if new cell has different URA identifier);
• Periodical URA update (range: 5 min. through 12 hours, or no periodic update);
The message flow is similar to the one of cell update: mobile station sends on CCCH/RACH URA Update
message, which is confirmed by a network on DCCH/FACH or on CCCH/FACH. If the response contains any
data requiring confirmation it is sent on DCCH/RACH or on CCCH/FACH [67].

6.5.3.3.8 Soft handover

When base stations are distinguishable with scrambling codes instead of frequencies the same bandwidth may be
allocated for all (or most) base stations (frequency reuse close to or equal 1). In that case mobile station equipped
with only one transmit/receive hardware module can communicate to many base station. This feature is used in
CDMA–based cellular networks to improve handover performance (such a handover is called soft — as distinct
from hard handover present in TDMA/FDMA–based networks, where mobile station can communicate with
only one base station at a moment).
Using soft handover gives numerous advantages: lower uplink interference, better power control, higher quality,
lower drop probability, etc. However, it introduces some problems, too. The most important is related to resource
allocation: mobile station communicating with several base stations has allocated resources (e.g. data and
signaling links) in all of those base stations. It also causes additional traffic load on wired UTRAN interfaces,
like Iub and Iur.
The decision about starting communication to a new base station or closing one of existing links is made based
on strength of the signal from considered base station — it is compared to the strongest known base station. It
means that signal strength thresholds controlling soft handover controls as well average number of base stations
involved in communication with a mobile station and allocated resources.
6.5.4 Summary of UMTS requirements

Based on the information and analyses related to UMTS network, the issues causing congestion and calling for
resource management are, for example, the following
• Air-interface
• Data transmission using dedicated channels versus common/shared channels
• Circuit-switched and packet-switched data
• Different service types with different QoS requirements
• Random access and location updates
• Soft handover
These requirements form the starting point for studying resource management techniques in UMTS networks
and they should also be taken into account when considering what to implement in the UMTS simulator (chapter
8).

7 GUIDELINES FOR SYSTEM REQUIREMENTS

This chapter summarizes the system requirements from the previous chapter resulting in a high level functional
specification of the CAUTION logical architecture. It is important that the system specifications will be included
in the forthcoming deliverables, since this is work that will be carried out in WP3: System Architecture. This
deliverable summarizes all task that has been carried out in WP2, namely: Statistical Evaluation of Data in
Congestion Situations, Traffic-load Scenarios, Resource Management Algorithms, Emerging Technologies
Requirements and Guidelines for System Architecture.
7.1 CAUTION high level logical architecture

Figure 114 shows the logical architecture of CAUTION system. This is the refined architecture after considering
a set of parameters studied in WP2. This logical system architecture consists of the following elements:
• Concentrator (already existing)
• ITMU (Interface Traffic Monitoring Unit)
• RMU (Resource Management Unit)
• Emergency call server
• Priority call server
BSC BSC BSC
C MSC_01 MSC_02 MSC_n
Concentrator Concentrator Concentrator
A'
ITMU_01 ITMU_02 Emergency
... ITMU_n
Emergency
call server
U call server Emergency
call server
T
I
Priority RMU
call server
O' N
OMC
Figure 114: High level CAUTION architecture

The identified interfaces are named as follows:

• C : MSC - Concentrator
• A’ : Concentrator – ITMU
• U : ITMU – emergency call server
• T : Emergency call server – RMU
• I : ITMU – RMU
• O’ : RMU- priority call server
• N : RMU – OMC
The concentrator is an existing element in GSM cellular networks that is in general vendor-dependent. This
element can filter the MSC reports or even produce new ones. The traffic monitoring in the CAUTION system
will be distributed, since the reports that will be exploited are generated in each MSC and they are not forward to
the OMC, to result in a centralized system. It is feasible to make use of universal reports (even billing, CDR) for
the real-time monitoring, but within the scope of the project, more compact reports will be exploited. These
reports will be forward to each ITMU over the A’-interface (not the existing specified GSM A-Interface). Of
course there is a mapping of the specific reports with the typical reports, according to the GSM
recommendations. The ITMU will perform the monitoring and forward alarm messages to the centralized RMU,
when congestion is detected (I- Interface). RMU can respond with a request for additional information about
traffic-load in adjacent cells, in order to execute the most appropriate technique. The RMU makes the decisions
making of the system and finally over the N-interface executes a command to the OMC for congestion
management. In addition, a priority-call- and an emergency-call-server are connected to the RMU and ITMU
elements respectively. Analyzing Figure 114, it is obvious that there is “closed-loop” in the architecture, which is
explained in Figure 115. The CAUTION system is part of the feedback of the cellular network that performs the
automatic control to result in a more stable state.
initial state cellular network optimized state
CAUTION
system
Figure 115: CAUTION Control System Concept for Network Optimization
7.2 ITMU
ITMU element is one of the CAUITON elements of great importance, since it is the element that will detect the
congestion. The implemented system will be based on GSM system, but it will be scalable to support UMTS
elements (RNCs). In the following sections, an introduction of the element will be given to summarize the
requirements and the functionalities of ITMU.
7.2.1 Introduction
One of the most important topics, concerning a network consideration, is network monitoring. Generally,
monitoring helps to obtain useful information about a system, its state and its behavior. More specifically
network monitoring provides useful information about the utilization of its resources, and the interaction way
between various network units.
When a mobile radio network is considered, the main concern is its resources, the kind of channels, the number
of cells, the number of BSCs, MSCs that the network has, etc. It is also important to know, at any time, if a call
request was established successfully or not, if a call was ended successfully or not, and if network resources are

sufficient at emergency instances. If a connection was cleared unsuccessful, we want to know the reason, which
causes that problem and to propose solutions. For that reasons it is a big necessity for us to have a special tool,
which will monitor our mobile network.
7.2.2 Requirements
The first requirement of a monitoring tool is the real time monitoring. The monitor unit should be able present
results at any time. The extraction must be continuous, and the results must be near to the real time, in order that
the network to react on time at an emergency instant. Another demand from the monitor tool is to calculate the
utilization of any network resource. In fact these utilizations are the desired results. The utilization of the various
logical channels will trigger at last the respective management techniques, if it will be necessary. The ITMU
requirements can be summarized as follows:
• Real-time monitoring
• Monitoring of all logical channels and not just TCH utilization
• Adjustments and additional configurations over GUI
• Connection with MSC-concentrator (1-way communication)
• Connection with Emergency call center (2-way communication)
• Connection with centralized RMU (2 way-communication)
• Avoid delays while retrieving data
• Collection of useful data (no redundancies due to the huge amount of data)
• Storage of data in the memory of ITMU for quick response
• Alarm reporting to RMU & emergency call center
• Respond on RMUs requests on cell-(channel-) utilization
In Figure 116, the logical architecture of ITMU is shown. The concentrator listens the reports generated in the
MSC and forwards them to a computer, which constructs a matrix for all BTSs. Each cell contains information
about all logical channels. A sliding window aggregates and averages the data, estimating the real-time resource
utilization. Alarms are generated, whenever a value reaches a specified threshold. In that case this is forwarded
to RMU. Subsequently, RMU requests additional information about resource utilization of adjacent cells.
BTS1
BTS2
BTS3
BTS4
BTSn
...
SDCCH: 30%
TCH: 67%
t0 RACH: 20%
AGCH: 10%
PCH: 4%
...
RTT, CDR, etc.
Concentrator
RMU
Bridge
Figure 116: ITMU logical architecture

7.2.3 Monitoring tools

There are many real-time traffic monitoring tools, which are designed to facilitate the monitoring and analysis of
network traffic. These tools allow the visualization the network functioning from the network element level
down to individual subscriber information. Monitoring tools extracts information from an MSC and visualizes it
in real-time graphs. The data received from an MSC, in the form of Real-time Traffic (RTT) reports. An RTT
report is generated at the end of each call that is executed in an MSC. The report contains versatile information,
for example, the call start time, the call end time, the cause why the call ended, A and B subscribers' identities,
the mobile identities (IMEI), the dialed digits, incoming and outgoing CGR, BSC, PCM, TSL, LAC and the cell.
Generally, a monitoring tool, using the RTT reports, can monitor the following:
• Number of calls
• Avoid Setup failures
• Dropped calls
• Clear codes
• Average call durations
• Mobile equipment
• Roaming subscribers
• User-defined subscribers or subscriber groups
• International calls
• Paging time
• Data calls
• HSCSD (High Speed Circuit Switch Data)
• Selected information about IN (Intelligent Network) calls
• SMS (Short Message Service)
• Dual band
• Network entities (for example, LACs, BSCs and cells)
Thereinafter the form of the clear codes, which are collected from a specific monitoring tool, is presented.
7.2.4 Clear codes

Clear codes are “special” codes in hexadecimal form, from 000H to FFFH, which informs how the various calls
are finished. For that reason, clear codes, are divided into four main classes:
0H – 3FFH: normal clearing
400H – 7FFH: internal congestion
800H – BFFH: external congestion
C00H – FFFH: subscriber errors
The different clearings affect the respective number of the network resources. These resources are mainly the
logical channels (traffic and control channels), which exist in the radio interface. For example, if an RTT report
with a clear code for normal end of the call (num: 000H) is received, it is very easy to calculate how many
channels were occupied during that call. Of course each of the above clear codes is triggered from many other
subcodes.
7.2.5 High level ITMU description
The ITMU (Interface Traffic Monitoring Unit) is the monitoring tool, which will be implemented. It collects the
various RTT (Real Time Traffic) reports, and registers the number and the kind of the occupied logical channels.
This registration informs about the utilization of each logical channel at any time. This knowledge helps to
monitor the system situation at any time (problems, congestion, etc.).
The main concept of the IMTU is that this element has two inputs. The first input is a file, which contains all the
information about the clear codes. The proper completion of this file is a very important and enough difficult

task. It contains all the clear codes with their identifiers, and the indicator calling/called. It also contains the kind
of channels (TCH, PCH, RACH, AGCH, SDCCH, SACCH, FACCH), that a specific clear code seizes and the
respective durations. All the above information results from the pre-study of the operation of the clear codes.
The second input is the point of where the ITMU receives the RTT reports from the network. The RTTs will be
collected with a special tool, which will be placed between the ITMU and the network body. As explained
above, The RTT reports contain information, such as the clear code identifier, the start and the end time of the
clear code, and an indicator which shows if the specific clear code concerns the calling party or the called party.
After the proper processing of the incoming data, the ITMU results the utilization of each logical channel. Each
logical channel has a critical utilization threshold. If the calculated utilization overcomes this critical threshold,
the program activates the respective management technique. This is and the connection point between the ITMU
and the RMU (Resource Management Unit). The RMU has as input the output of the ITMU.
7.2.6 Existing monitoring tools in 2G cellular systems

Traffica from NOKIA is a traffic monitoring tool, which is designed to facilitate the monitoring and analysis of
network traffic. Traffica allows seeing the network functioning from the network element level down to
individual subscriber information. With the Traffic News and SMS News tools, it is possible to post-process the
traffic data generated from voice and data calls, and short messages.
Traffica extracts information from an MSC and visualizes it in graphs. For visualizing the network traffic, the
manufacturer provides an extensive selection of predefined graphs. The data received from an MSC is stored in
an embedded database. The database can be used for making queries and running predefined reports with the
Traffic News and SMS News tools. The information from an MSC is received in the form of Real-time Traffic
(RTT) reports. An RTT report is generated at the end of each call that is executed in an MSC. The report
contains versatile information, for example, the call start time, the call end time, the cause why the call ended, A
and B subscribers' identities, the mobile identities (IMEI), the dialed digits, incoming and outgoing CGR, BSC,
PCM, TSL, LAC and the cell. The Traffic News tool uses RTT reports when generating reports.
As to short messages, MSCs generate two kinds of SMS reports: one is for mobile originated short messages and
the other for mobile terminated short messages. The SMS News tool uses these SMS reports when generating
predefined SMS News reports. SMS News report contains information, for example, of LACs, cells and mobile
types. Traffica makes it possible to define alarms. Alarms can be forwarded to the NMS, where action can be
taken.
Traffica is intended for monitoring the network performance during short time periods, from a one-second time
slice up to 24-hour time slices. However, there are no restrictions on the length of the monitored time periods.
Still, if you want to monitor the data, for example, over one week, the memory capacity sets limits for the
accuracy of the data. In other words, it is not possible to collect data with one-second accuracy for one week.
The traffic data derived from Traffica can be stored in the Network Data Warehouse (NDW) for longer periods
of time, such as, days, months, or years. Detailed information about Traffica is listed in Appendix 4.

7.3 RMU
The RMU is the core of the CAUTION system by which resource management techniques are decided as well as
executed after a detection of network congestion. In the following sections, an introduction of the requirements
and the functionalities of RMU will be provided.
7.3.1 Introduction
Generally, a wireless network (for instance GSM) provides measurement reports for the radio resource
management. These data, comprising data such as up/downlink quality are today only used for handover and
power control decisions. In CAUTION, the data will be collected and aggregated by means of the ITMU. The
ITMU output will be used for preventing and avoiding network congestions through the Resource Management
Unit (RMU).
An efficient Resource Management element shall also detect promptly any network shortcoming occurrences.
Moreover, it shall execute the appropriate recovery action as soon as possible in order to limit the damage caused
by the network failure. Calls can be lost for different reasons; instances are network element failures or
congestion due to an excessive incoming overload on the limited radio resources.
7.3.2 Requirements
The first requirement of the Resource Management Unit is the reaction constraint. The efficiency in terms of
calls lost of the RMU strongly depends on the time elapsed from the detection of the network shortcoming and
until the right resource management techniques are carried out. The detection implies that an exact translation
between alarms generated by the ITMU and different load scenarios is performed. If the matching action cannot
be completed, the RMU may decide to request to ITMU supplementary data in order to detect the most likely
load scenario.
Furthermore, the execution of the right recovery action involves a tuning action in order to set the optimal
resource management technique parameters. This tuning procedure can necessitate data messaging exchange
between RMU and ITMU in order to gain further information about the network condition (traffic on adjacent
cells, handover success completion rate etc.). The RMU choices must be propagated to the Priority call server,
Emergency call server and to the OMC. From what stated above the RMU requirements can be summarized as
follows:
• Minimizing reaction time
• Connection with Priority call server (2-way communication)
• Connection with Emergency call server (2-way communication)
• Connection with one or more ITMUs (2 way-communication, also through an IP based network
backbone)
• RMU actions triggered at ITMU alarms (unpredictable events) or time clock (predictable events)
• Capability to ask the ITMU for obtaining more information on the network status
• Storage of log-data and predictable events onto a DB
• Connection with the OMC (2 way-communication, also through an IP based network backbone) for
executing the proper resource management techniques
7.3.3 High level RMU description
The main purpose of the RMU is to collect alarm messages from the ITMU and to react to them executing the
most suitable resource management technique. The RMU can also be triggered when a scheduled event occurs
which indicates the necessity of handling the occurrence of a predictable event (for instance a sport match

event). In this case the RMU is aware of a possible congestion situation and two different actions may be
performed:
• The RMU applies the proper RM technique
• The RMU waits for ITMU alarms and then it applies the right RM technique
Note that, the first one can be adopted for preventing possible radio interface congestions and so alarms
generated from the ITMU. After an alarm message, the RMU shall identify what kind of congestion is occurring
in the network radio interface. The RMU can require further information about traffic-load in adjacent cells. This
can happen when different scenarios match with the information delivered by the ITMU. In this case the
additional required information is needed in order to minimize the detection error likelihood.
Subsequent to scenario detection, the RMU enters in a decision-making mode (see Figure 117). The RMU shall
identify which resource management technique is most appropriate between the stored available ones for that
particular identified scenario. Also in this case further adjacent cell information can be demanded to the ITMU in
particular for two purposes:
• To increase the level of confidence in the selection of the resource management technique to be used
• A RM technique parametric tuning may be performed in order to optimize the management action
result.
The resource management execution is performed by means of data exchanged with the OMC. Note that the
RMU, after the RM execution, can monitor the congested cells in order to fine-tune the RM parameters or to
verify that the RM technique has obtained or is obtaining the correct effects. One or more DB shall be used to
store log-files that can be used by the RMU for learning or to store predictable events used to wake up the RMU
when they happen.
ITMU
Identify the traffic Resource

identified
load scenario management
selection
Is in DB?
DB
Resource
Logs, management
predictable write onto DB
execution
events etc
OMC
RMU
Figure 117: RMU high-level design

7.4 Priority call server

Priority call server will be an additional element of the CAUTION architecture that will enable the prioritized
assignment of bandwidth, according to the user’s class. ETSI and 3GPP have specified user’s prioritization
classes for priority calls, preemption and queuing. In CAUTION project, it will be important to avoid
prioritization of users according to their contract with the cellular operator, since there are several legal issues
that need to be considered. The priority call server will be an element that can be “on the fly” reconfigured in
such a way to assign priorities according to the traffic-load situations. The users will be classified to several
classes, such as:
• Ambulances
• Authorities
• Police
• Fire department
• PMR users
• etc.
In this way after the monitoring of the system, that will take place in ITMU, the priority server will provide the
RMU information related to the priority classes of the subscribers. Priority call server will be connected to the
RMU over the O’ interface, which will be specified in WP3.
The requirements of this element can be summarized as following:

• GUI in order to enable interactive assignment of priorities
• 2-way communication with RMU
• Ability to handle priority request
Obviously, the server will be based on a database and a database handler. An important issue will be which of
the subscribers will be registered in the list. The initial thought is that all users will be assigned a default priority
(normal) and on the other hand a set of priority classes will exist. The priority server will be manually accessible
over the cellular network’s VPN and priorities will be assigned dynamically. In this way specific user-IDs will
be upgraded according to the situation. Subsequently RMU will be notified for a change of user’s status and
execute the appropriate command to the NMS. After reaching a stable state of the system again, the users will
have their default priorities.
DB
DB handler
Processor
RMU
GUI
Figure 118: Priority call server - block diagram
Finally, it can be mentioned that in a further step, the priority call server can be integrated in the HLR of the
network having important information about priority classes, since the HLR can be configured from the OMC. In
that case, if priorities have to be assigned, this can be executed to the OMC, in the same way that the
RMU executes a set of commands.

7.5 Emergency call center

The emergency call center will be a CAUTION element that should guarantee a full-time availability in the
network. In GSM networks, these elements already exist but they are not operational in extreme congestion
situations. Emergency call centers will be attached to each ITMU in the CAUTION architecture. Its functionality
is to monitor the traffic load in all cells and alarm reporting from ITMU.
The emergency call centers will be distributed to each IMTU and also connected to the centralized RMU.
Whenever ITMU reports congestion alarms to the emergency call center the emergency call center will take the
decision about the required bandwidth needed. This would be adjustable and re-configurable from external
places, in a way to require on-demand bandwidth or QoS. For instance, if a catastrophe has taken place the QoS
grade will be definitely increased in such a way that all emergency calls will be served, even if they are
performed from the operator. For the optimal usage of the emergency call centers, operators should in the future
monitor the reserved resources. The connection with the RMU, might change the selected management
technique, therefore, it will be the dominant element in cases of emergency, that despites the RMU decisions,
might require the execution of a mechanism, which will enable the handling of emergency calls. The
requirements can be summarized as follows:
• GUI in order to enable interactive assignment of priorities

• 2-way communication with RMU
• 2-way communication with ITMU
• Considering user interaction, influence the RMU decisions
The emergency call center will get information from the operator and on the fly, exchanging information with
RMU and ITMU will influence the decision of RMU, even if this is not the optimal for the capacity utilization of
the whole system. Therefore, emphasis will be given to the guarantee of services, including E-112. Moreover the
operator by means of this element will be able to inform the subscribers about forthcoming shortcomings over
the BCCH channel. Finally, calls can be set-up from the operator, in case of receiving emergency SMSs from
system’s subscribers. For that purpose, bandwidth reservation will be requested from the RMU.
ITMU
RMU
Decisions Making
GUI
Figure 119: Emergency call center

8 UMTS SIMULATOR
8.1 General description

8.1.1 Network planning, link and system level simulations
Before a cellular network can be deployed in a certain region, detailed studies have to be conducted to discover
the requirements set by geographical environment and potential subscribers. The goal of the network planning is
to ensure that the demands can be met in the optimal way. The role of the network planning and the differences
between 2nd and 3rd generation cellular networks is discussed in [5].
Two cornerstones of the network planning in the detailed phase are link level simulation and system level
simulation. Even though in a real cellular network the whole process is continuous, the different computational
requirements of the two simulations and their joint computational burden call for splitting the process into these
two parts. This dichotomous approach is naturally not straightforward but instead brings about problems related
to the accomplishment of information interchange between the simulation parts. The problem of exploiting the
results obtained in link level simulations in system level simulations has been addressed in [4].
Radio transmission and reception are investigated in the link level simulations. Different methods for channel
coding, interleaving and modulation, for example, can be studied. The simulation time step in CDMA link level
simulations should be less than the duration of one chip in order for the simulations to capture the effect of
interchip interference. For example, the relationship between bit error rate (BER) and bit energy per interference
density ( Eb / I o ) for different services and bit rates can be obtained from these simulations.
The results gained from link level simulations are used as an input to the system level simulations. In the system
level simulations the operation of a cellular network with users is studied. At this stage there is no need to
explicitly model the radio transmission and reception of data since that has already been done in the link level
simulations. However, the system level simulations can be conducted with different accuracies and modeling
precisions. It is possible to resort to static simulations where, for example, user mobility, handover algorithms
and fast realistic transmission power control are not explicitly modeled [6]. In this case, only the convergence of
the powers in the network is important. This kind of simulation has the advantage of having lower computational
load than more accurate approach but the disadvantage of not enabling one to simulate admission and congestion
control mechanisms. A more accurate approach is to use incorporate user mobility in the simulations, use fast
transmission power control and model explicitly handover algorithms. This greatly increases the computational
load but also extends the possibilities for examining capacity management algorithms.
8.1.2 Purpose and objectives

This section describes the purpose and objectives of the simulations in this project rather than in general. The
general purpose and objectives were already explained in previous sections.
The purpose of the system level simulations is to investigate the capacity utilization in congestion situations.
Because the available procedures for alleviating and avoiding congestion situations in cellular networks are
performed at the call level, it is necessary to simulate individual calls in the system level simulations.
A general simulator core functionality and different resource management algorithms will be implemented. The
operation of the network will be simulated in congestion situations using the simulator and the impact of radio
resource management algorithms on the capacity utilization will be studied. Reliable information about the
efficiency of the algorithms cannot be obtained otherwise. It is expected that conclusions can be drawn about the
applicability of the studied algorithms in congestion situations based on the simulations.

8.1.3 Constraints and requirements

The possibilities for simulating at most a scenario comprising 50 base stations (counting each sector as an
individual base station) and roughly 50 ongoing calls per base station should be assessed. This results in 2500
ongoing calls (mobile stations) in the whole simulation area. This would be sufficient to guarantee versatility in
the traffic conditions in the region and it would encompass geographically a large enough region to be useful. It
would also be sufficient to enable reliable analysis of the results as suggested in [1]. In the time domain, a span
of 30 minutes using simulation time step of 1/1500 seconds would enable one to simulate enough calls to give
statistically reliable results and to suppress the effect of few exceptionally behaving calls. The time steps used in
WCDMA simulations have been longer than 1/1500 seconds; in [2] a time step of 10 ms was used. The effect of
the simulation time step on the results has been studied in [3] where simulations performed with slot resolution
were compared to those performed with frame resolution (15 slots). Under high traffic loads the discrepancy
between the results gained with different resolutions increased.
One commonplace way of diminishing the border effect (i.e. the peripheral cells are subjected to different
interference conditions than the central cells) is wrap-around technique: the cells in one side of the network are
considered to be neighbors of the cells in the other side. This has been used, for example, in [2]. However, this
technique is not suitable for a simulator that is to be used in real simulation scenarios. Thus, although the data
collected in the peripheral base stations differs from that of the central base stations, it can be easily excluded
from the result analysis and can also be very useful.
These requirements regarding the number of ongoing calls and the length of simulation should be understood to
indicate the ultimate and aspirable goals rather than easily and necessarily fulfillable goals. The huge
computational load calls for special procedures to tackle it. The approach relying on distributed computing can
reduce the execution time of the simulations. Naturally, careful C++ code optimization is needed in addition to
that.
8.2 Simulator core
8.2.1 General
The infrastructure necessary for carrying out the simulations is presented and components that have to be
implemented in order to be able to investigate sophisticated admission control, congestion control and
prioritization algorithms are outlined.
Input
Inputparameters
parameters
Propagation
Propagationlosses
losses User
Userdistribution
distribution Traffic
Trafficmodel
model Mobility
Mobilitymodel
model
Move
Moveusers
users Interference
Interference Handover
Handover Power
Powercontrol
control
calculations
calculations (admission
(admissioncontrol)
control)
Congestion
Congestioncontrol
control Terminate
Terminatecalls
calls Initiate
Initiatenew
newcalls
calls
(admission
(admissioncontrol)
control)
Figure 120: UMTS system level simulator structure.

8.2.2 Cell structures of the network

The placement of base stations in a cellular network is a relevant factor affecting the network capacity. The
offered traffic in the region and mobile station mobility characteristics may vary a lot. Thus, in addition to using
a network consisting of one cell layer with omni-directional base station antennas, it is essential to consider more
complicated network and cell structures to alleviate the problems that non-uniform user distribution, for
example, brings with it.
The starting point for a CDMA-based network is the usage of the same carrier frequency in each base station.
However, if more spectrum is available for the network operator, multiple frequency bands might be used to
provide higher capacity. Thus, one base station could operate on multiple carrier frequencies serving a hotspot
region (a region where the offered traffic is exceptionally high) better.
A cellular network may also contain multiple cell layers. If the users tend to move with high speed (motorways),
using large umbrella cells can reduce the handover rate and signaling traffic. The network layers can use
different frequency bands and
In addition to multiple cell layers, the base stations in one cell layer can be sectorized. This has an effect on the
handover procedures enabling softer handover to be performed between sectors. Softer handover, on the other
hand, encompasses the usage of more efficient signal combining schemes. The effect of base station
sectorization on the network performance has been studied in [8], for example.
a) Multiple cell layers. b) Multiple carriers. c) Sectorized cell.

Figure 121: Different cell structures.
These three features affecting the network structure are illustrated in Figure 121 and the factors that they affect
are briefly listed in Table 47. Each of these features is relevant in congestion situations.
Table 47: Features of different cell structures.

Multiple cell layers Multiple carriers Sectorized cell
• Interference calculations • Interference calculations • Softer handover possible
separately for each frequency separately for each frequency between sectors
band band
• Fast mobiles could be handed
over to an umbrella cell
8.2.3 Propagation losses

Radiowave used to transmit data between base stations and mobile stations are attenuated in the air. The
difference between the transmitted power and received power is designated as propagation loss. The propagation
loss values are provided to the simulator for each base station and for the whole region in a set of matrices. The
propagation losses can originate from three different sources and can be:
• Real measured values

• Predictions with deterministic methods
• Predictions with empirical methods

The propagation loss can be artificially decomposed into three parts that can be attributed to different factors and
modeled with variable success. The most important part of the propagation loss is dependent on the distance
between the mobile station and the base station and usually denoted large-scale propagation loss. The signal
power undergoes slow fluctuations called shadow (or slow) fading that are due to the obscuring effect of the
trees and buildings. The fast fluctuations observed in the signal are called fast fading and originate from the
multipath propagation.
If the propagation loss values are real measured values or prediction with deterministic methods, they already
contain shadow fading and fast fading components (fast fading components might be missing from the
deterministic predictions). However, propagation loss values calculated with empirical methods only give the
large-scale propagation loss. This naturally affects the accuracy of the simulation results but it does not affect the
general structure of the simulator.
It is important to note that the effect of fast fading depends on the signal bandwidth and environment (delay
spread). Taking into account the large signal bandwidth and the typical delay spread, it can be shown that fast
fading has quite a small effect on the received signal level in UMTS. On the other hand, the delay spread and
channel impulse response has a clear effect on the bit error rate. This effect will be taken into account in the
simulator by selecting the receiver threshold level according to the results obtained in link simulations.
The propagation loss values could be provided in a set of two-dimensional matrices with arbitrary precision.
BS
Figure 122: Example of signal strength predictions with VTT's ray tracing-based Microcell Tool (MCT).

8.2.4 Interference modeling

8.2.4.1 General
Because basically all the users and base stations in a CDMA network operate in the same frequency band, the
interference situation is an essential factor affecting the operation of the network. Thus, the calculations
performed in the simulator concerning the interference powers and, subsequently, signal-to-interference ratios
should be very accurate. The calculated SIRs are used as input to the power control and handover algorithms, for
example, and the errors incurred in the SIR calculations are directly reflected in other parts of the simulator as
well.
The interference can be divided into three parts: intracell interference ( I int ra ) , intercell interference ( I int er )
and background noise ( N 0 ) . This kind of classification is relevant since the different components of the
interference can be mitigated differently. In the downlink, the spreading codes used for users are, at least,
partially orthogonal and the intracell interference can thus be partially mitigated. In the uplink, multi-user
detection could be used to reduce intracell interference.
In the downlink, the signal-to-interference ratio for a user can be expressed as
P
SIR DL = (3)
(1 − α ) I int ra + I int er + N 0
where P is the received power of the user (traffic channel) and α the orthogonality factor. In the uplink, the
corresponding expression is
P
SIRUL = (4)
(1 − β ) I int ra + I int er + N 0
where β is the multiuser detection efficiency. The relevant difference between the downlink and uplink
directions is the lack of orthogonality of the interfering signals coming from different mobile stations in the
uplink.
The received intracell and intercell interference powers in the expressions are dependent on many different
factors such as
• Transmission power
• Propagation characteristics of the region (propagation loss)
• Modeled channels
• Service type characteristics (transmission activity)
When Equations (3) and (4) are written taking into account the traffic and other channel transmission powers and
propagation losses, equations

Pi TX
,j
li , j
SIRiDL
,j = (5)
∑P TX
k, j +P TX
other , j ∑PTX
k ,n
TX
+ Pother ,n
(1 − α ) +∑ + N0
li , j li , n
and
PiTX
li , j
SIRiUL
,j = (6)
∑P k
TX
∑P k
TX
(1 − β ) k
+ k
+ N0
lk , j lk , j
are obtained. Here, PiTX TX

, j is the transmission power allocated for mobile station i in base station j , Pother , j is
the transmission power of other channels (e.g. pilot channel) in base station j , PiTX the transmission power of
mobile station i , li , j the propagation loss between mobile station i and base station j.
These SIR calculations take a lot of time because they are carried out in both directions (uplink and downlink)
and for each mobile station and base station. The calculations can be optimized by performing the common parts
only once. Also, when calculating the intercell interference, base stations far from the current mobile station or
mobile stations far from the current base station are not likely to cause much interference compared to more
nearby mobile stations or base stations and could thus be ignored in the calculations. However, especially in
urban environments the distance is not the only factor that determines the propagation loss because the radio
wave propagation takes place in the street canyons. Also, the transmission powers of mobile/base stations can
differ so that it is not always easy to point out the most interference causing mobile/base stations and this task is
further made more difficult in congestion situations where the user distribution might be highly non-uniform.
8.2.4.2 Effect of different carriers

Even though it is not necessary to use different frequencies in different cells in a CDMA network, a cell might
have multiple carriers allocated to it and different cell layers might use different frequencies. Adjacent frequency
bands can interfere with each other. If this effect is neglected, the signal-to-interference ratio of the received
signal can be calculated just by taking into account the interfering signals in the same frequency band.
8.2.4.3 Effect of soft handover

In the soft (and softer) handover state, the mobile station receives signals from multiple base stations and
multiple base stations receive the signal from the mobile station. The signal-to-interference ratio of the resulting
combined signal, when all the individual signal are utilized, depends on the quality of the individual signals and
the combining scheme.
If selection diversity is used, the combining of the signals actually implies selecting the best signal based on the
SIRs of the signals. Thus, the resulting SIR in this case is [35]
SIRi = max(SIRi ,1 , SIRi , 2 ,l, SIRi , N ) (7)

where N is the number of signals to be combined.
If maximum ratio combining is used, the signals are weighed according to their individual SIR values before
combining. The resulting SIR can then be calculated as a sum of the SIRs of the individual signals [35]
SIRi = SIRi ,1 + SIRi , 2 + h + SIRi , N . (8)

The combining scheme that can be used in the handover is dependent on the direction (downlink or uplink) and
the handover type (soft or softer). The usage of maximum ratio combining exploits better the all the signals to be
combined than selection diversity.
8.2.5 User distribution and mobility

The distribution of inhabitants in a certain geographical region is not usually uniform. This implies that the call
requests are neither distributed uniformly and even if they are distributed uniformly under normal circumstances,
a hotspot traffic situation might easily occur under abnormal circumstances. Thus, it is imperative to be able to
test the performance of the network using non-uniform user distributions.
The movement of the cellular network users affects handover execution and the user distribution. Thus, in order
to be able to study the effect of different handover algorithms, the mobility of the users has to be modeled.
Usually the possible routes traced by mobile station users are constrained by buildings and geographical
environment and especially in urban environments the movement takes place along streets. Thus, there is a
requirement to limit the acceptable movement directions in each location in the simulation area.
The movement of the users in the region could be modeled as totally random or by weighing some directions.
The latter situation might occur in practice, for example, when mobile station users are mostly moving towards a
certain hotspot region (a place for public event) or along highways to countryside.
The information necessary for constraining mobile phone users' locations and movement directions could be
obtained from a raster map (Figure 123) or a vector map of the simulation region or using both of these. If a
raster map is used, preprocessing is required to transform it to a suitable form for application. One factor to take
into account in deciding which one to use is the availability of maps from different regions and the ease of using
such a map in the simulations.
Figure 123: Example of a raster map of a geographical region showing buildings and streets that affect the
user distribution and mobility.

In addition to the movement direction, the speed of the movement of mobile station users also affects the
performance of the network. It has an effect on the signal reception and also changes the handover frequency.
The situation is quite different for pedestrian users and for vehicular users, which can cross many cells during
one ongoing call and thus have multiple handovers. The movement speed is dependent on the user type
(pedestrian, vehicular) but also on the street (speed limits). Pedestrian users can be expected to move everywhere
with approximately the same speed but the variations in vehicular users' speeds can be considerable between
different streets. Real information about the speed limits of the streets could be exploited in the simulator if such
information is available in suitable format. If the information is not available, the values could be assigned
manually or automatically to a certain same value for every street.
The simulator could take as an input a matrix describing with arbitrary precision the discrete two-dimensional
probability distribution of users. This matrix could, in turn, be obtained by estimating or modeling the user
distribution on a general level in the simulation region and taking into account the buildings in the region by
constraining thereafter the user distribution using a raster map of the simulation region as shown in Figure 123.
The issues related to mobility have been investigated, for example, in [37], [36], [38] and [39].
8.2.6 Traffic modeling

Traffic modeling is an important part of the simulator and, especially, when analyzing congestion situation with
the aid of the simulator, the models used should be as realistic as possible because otherwise the validity of the
obtained results is diminished.
Things that require attention in the simulator related to traffic modeling are listed below
• Service type (and percentage of users per each service type)

• Connection type (circuit-switched or packet-switched)
• Data rate
• Asymmetry (between uplink and downlink)
• SIR requirement
• Delay requirements
• Connection arrival (or request) process
• Connection duration process
• Packet arrival model
• Activity model for speech
The service type of each user can depend on the transportation means of the user (pedestrian, vehicular); i.e.
pedestrian users might be more likely to use real-time video than vehicular users. However, if the usage of
different service types is taken to be independent of the user class, the situation is simplified a bit. The
penetration of different service types in the simulation region should then be estimated.
The distribution of users also depends on service type: people living in certain region might take advantage of
the emerging new service types like real-time video whereas in other regions the users might settle for normal
voice calls. The user distribution should therefore be given separately for each service type.
The two different connection types, circuit-switched and packet-switched, should be taken into account in the
simulator. Packet-switched connections are more complex to implement because they require, at least, some sort
of packet scheduler implementation to control and regulate the transmission of packets. The scheduler, on the
other hand, should attempt to heed the QoS requirements of the packet-switched service types and try to fulfill
the delay constraints, for example.
The effect of traffic model is reflected in the interference situation in the network which in turn has an effect on
the capacity of the network. In signal-to-noise ratio calculations in Equations (5) and (6) the powers of those
users are set to zero that do not transmit anything at a certain instant because of a silent period in speech service
(DTX) or a pause between packets in packet-switched data. At the transmission stage in the simulator, the

differences in the traffic model or connection type do not have any importance from the implementation point of
view because the same interference calculations apply.
A circuit-switched connection is illustrated in Figure 124. Before transmission a model for voice activity is used
to set the transmission power to zero during some inactive periods of time.
Call Transmission
Voice
activity
model
Figure 124: Circuit-switched connection.
A packet-switched connection is illustrated in Figure 125. A model for the packet arrival is used to generate the
packets that have to be subsequently stored because they cannot be necessarily transmitted immediately due to
the packet-scheduling algorithm applied. After the scheduling algorithm the packet process is different and the
resulting process is used in the interference calculations.
Delay
calculations
Packet arrival process Transmission
Packet
scheduling
Functionality
for storing
packets
Figure 125: Packet-switched connections.
WWW traffic models have been analyzed in [7].
8.2.7 Power control

Power control in UMTS can be divided into three different operations
• Open loop power control

• Closed loop power control
• Outer loop power control
Open loop power control is used to adjust the transmission power of RACH (random access channel) or CPCH
(common packet channel) before transmission. Outer loop power control is used to adjust the SIR target set for
fast closed loop power control. The same signal-to-interference ratio can result in different bit error rates
depending on the movement speed of the mobile station and channel conditions. Outer loop power control will
not be modeled in the simulator because it would require obtaining information about the channel conditions
indirectly or directly.

The fast closed loop power control is performed 1500 times per second in both downlink and uplink. The
transmission powers are adjusted with a fixed power control step, which can differ between downlink and
uplink. Because the power control rate is very high and consequently the required simulation time step very low,
the computational burden becomes easily huge. This could be alleviated partially by using a longer simulation
step but allowing at the same time bigger power adjustments. However, before using this method, it should be
verified that the results are not affected essentially.
The transmission powers of the mobile and base stations are limited from above. In base stations, there is a limit
for the total transmission power (including all the traffic and control channels) as well as for each traffic channel
separately. There is also a lower limit for the transmission powers stipulated by the equipment. These two limits
together define the power control dynamics and have to be taken into account in the simulator.
In the soft handover state, the power adjustment concerns all the base stations participating in the handover.
Thus, all the base stations should detect the power control command sent by the mobile station and change their
transmission powers in the same direction.
Things that have to be taken into account in the power control implementation
• Constrained power control dynamics
• Power control in soft handover state
8.2.8 Handover
There is a need to distinguish between different handover types in the simulator. Depending on the number of
simultaneous connections to different base stations or base station sectors, handovers can be classified in three
categories that require attention in the implementation
• Hard handover
• Soft handover
• Softer handover
The applicable handover type in each situation depends on the base stations, base station sectors, carriers and cell
layers that participate in the handover. In principle, a situation could occur in which the mobile station is
connected to two sectors of the same cell and, in addition to that, to another cell.
BS
RNC MS RNC BS MS
BS
a) Soft handover between sectors of different BS. b) Softer handover between sectors of the same BS.
Figure 126: Soft and softer handover.

Table 48: Different handover types.

Hard handover Soft handover Softer handover
• Used in interfrequency • Used between different base • Used between different sectors
handovers stations of the same base station
• Requires information that base • Requires information that base • Requires information that
stations use different carrier stations are different but sectors belong to the same base
frequency operating in the same station
frequency band
Another relevant issue related to handover is the notion of different cell sets. The sets should contain a list of the
cells that are currently participating in the handover (active set) and the cells that might be included in the
handover (neighbor set). For each base station, the neighbors should be defined and given as an input to the
simulator or the neighbors could be automatically determined before beginning the simulation based on some
criteria (e.g. distance measure).
8.2.9 Admission and congestion control

In the CDMA based UMTS cellular network there is no hard limit on the number of channels that can be
allocated to users which is contrary to the situation in the TDMA/FDMA based GSM. Thus, the capacity of
UMTS is soft and depends on the interference situation in the network and it is imperative to regulate the number
of users admitted to the network in order to guarantee an acceptable call quality for all calls. The procedure used
for deciding whether a new call can be accepted and initiated is denoted call admission control (CAC). The
procedures executed after the calls have already been accepted to the network are designated congestion control.
Call admission control has to distinguish between handover calls and totally new calls and it has to take into
account the different resource requirements that are dependent on the service type. In addition to the interference
dependent capacity, soft handover complicates the situation in UMTS. The usage of a call admission control
algorithm increases the number of blocked calls but at the same time decreases the number of dropped calls. This
kind of behavior is desirable since losing an ongoing connection more annoying than getting blocked.
From the point of view of the simulator and especially concerning the implementation, the relevant issues are
what kind of data has to be available in the algorithms and what calculations are required. Information about the
following things could be used in the admission and congestion control algorithms
• New call or handover call
• OVSF code allocation situation
• Transmission/reception powers
• Intracell/intercell/total interference
• Signal-to-interference ratio of connections
8.3 Implementation aspects
8.3.1 General
It should be possible to disable different features in the simulator in order to focus on studing just the effect of
chosen factors. For example, user distribution and mobility could be simulated without any other things (i.e.
power control, handover, etc.). Also, it should be possible to execute different parts of the simulations less
frequently than the base simulation time step in integer multiples of the base simulation step. For example, the
handover algorithm could be performed only once every 10 time steps but the power control once every time
step. This would increase the execution speed of the simulations without necessarily affecting the results much.

8.3.2 User interface

The user interface of the simulator should not receive too much focus. Some features could be optionally
implemented. The visualization of the mobile stations as a function of time during the simulation can be
informative for inspecting roughly the resulting traffic hotspots in the simulation region with chosen user
distribution and mobility models. This should be possible by overlaying the mobile stations on a raster map of
the simulation region.
8.3.3 Input and output functionality

The simulator takes some data as input in files, performs simulations based on that data and using specific
models and stores the output data into a file or files.
8.3.3.1 Input data

Some of the models used in the simulations will be contained in the functions of the simulator (e.g. traffic
models) whereas others (propagation models) are isolated from the simulator itself. The simulator requires some
data as an input. What exactly is required and, especially, in what format, is not described here. Rather, general
level descriptions are given below of the different kinds of data that should be provided for the simulator
• Propagation loss data

• Base station data (locations)
• Allowed service types and their characteristics (data rate, SIR threshold value)
• Allowed user groups (pedestrian, vehicular)
• User distribution
• Mobility constraints
8.3.3.2 Output data

The simulations can produce large amounts of data if all the values of all quantities are collected during the
whole simulation run. The storing of output data into a file/files during the simulation runs can easily slow down
the execution. Thus, data should first be collected to memory and then output to a file after certain period of
time. Also, it might be desirable to be able to choose what quantities are output in a certain simulation run and to
alter data sampling frequency. Examples of output data are given below
• Number of ongoing calls per service type as a function of time

• Call termination reasons (blocked, dropped) for all calls
• Transmission delays for packet-switched data
• Transmission powers
• Reception powers
• SIR values
8.3.4 Result analysis and visualization

The analysis and visualization of the data recorded during simulations can be carried out outside the simulator
and there is thus no need to implement complicated analysis functions and support for plotting in the simulator
itself. However, some features could be useful in the simulator itself such as showing the locations of the
dropped or blocked calls on the map of the region. This could also be carried out outside the simulator.

8.3.5 Simulator speed-up

A relevant problem with dynamic network simulations is the computational burden. There are many mobile
stations and base stations in the network and low simulation time step is required. The speed of the simulations
can be increased by different means [47] :
• Implementing the simulator with efficient programming language (C++)
• Optimizing the calculations carried out in the simulator
• Resorting to approximations
• Implementing the simulator using parallel and/or distributed computing
Because the execution speed of the simulations limits the possibilities for testing algorithms, there has to be a
method for estimating the feasibility of implementation of the algorithms. The potential speed gains of
implementing the simulator using distributed computing have been estimated analytically by implementing a
simple core for the simulator containing some crucial basic functionality and measuring its execution speed. The
features implemented so far are listed below
• COST-Walfisch-Ikegami propagation loss model calculated during simulation
• Fixed step closed loop power control
• Handover algorithm using active set size 1
• Random movement of mobile stations (no mobility constraints, uniform user distribution)
• Call admission based on number of available downlink OVSF codes
8.3.5.1 Optimizing calculations

The SIR calculation equations include summations that are repeated many times. A significant improvement is
gained by calculating the summations only once and storing the values to new terms that are used in the
equations instead of calculating the raw summations every time
The simulator algorithm uses the propagation loss and SIR values for the same (mobile station, base station)
pairs several times during each power control cycle. It is possible to save significant time by storing the values to
memory when they are calculated for the first time, and by using the values from memory afterwards. This is
possible and feasible because modern computers have plenty of memory available - e.g. 60 base stations with
3200 mobile stations, and 3 SIR values and one propagation loss for each (MS, BS) pair only requires
60*3200*4*4 bytes = 3072000 bytes = less than 3 megabytes.
8.3.5.2 Parallel computing
8.3.5.2.1 General
The simplified idea of parallel computing is that all tasks of a computation are composed of subtasks. The trivial
execution of the task would just run all the subtasks i sequentially, one after another, until the final subtask I is
ready. This will take a total time ttotal, which is the sum of all the runtimes of the subtasks, as shown in Equation
(9).
I
ttotal = ∑ t subtask,i (9)
i =1
In order to execute the task faster, it would be necessary to run the subtasks at the same time in parallel. This
arrangement would in an ideal case reduce the total time to the runtime of the largest subtask, as shown in
Equation (10).
ttotal = max(t subtask,i ) (10)

1≤i ≤ I
The Gantt charts in Figure 127 demonstrate the effect with four subtasks, where at the left chart the serial
execution takes a total amount equal to the sum of all the times, and at the right chart the parallel execution takes
only time t2.

Task 1 t1 Task 1 t1
Task 2 t2 Task 2 t2
Task 3 t3 Task 3 t3
Task 4 t4 Task 4 t4
Time Time
Figure 127: Gantt charts for serial and parallel execution of the same task
There are many non-ideal elements that cause the actual execution time to differ from the ideal. A job that is to
be executed in parallel usually has parts that need to be executed serially and can't be parallelized. This is
expressed by the Amdahl's law in Equation (11) for P processors.
t parallelpart
ttotalexecutiontime = + t serialpart (11)
P
The Amdahl's law parameters include the total execution time ttotalexecutiontime of the whole program, the execution
time tserialpart of the serial non-parallelizable part and the execution time tparallelpart of the parallelizable part. The
Amdahl's law implies that the serial part will always cause a limit to how much it is possible to speed up the total
execution time. For example, 10% serial part will limit the theoretical speedup to a factor of 10. [48]
The theoretical measure of how much the parallel execution helps for a particular algorithm is called speedup S
and expressed in Equation (12) as the ratio of the execution time tserialalgorithm of the fastest known serial algorithm
to the execution time tparallelalgorithm of the parallel algorithm.
t serialalgorithm
S= (12)
t parallelalgorithm
The efficiency E of the parallel execution for a particular algorithm is calculated using Equation (13) as the ratio
of speedup S and number of processors P used for parallel execution.
S
E= (13)
P
The example above for the Amdahl's law is shown in Figure 128 as the serial part is 10% of the total execution
time. The chart shows clearly how the speedup approaches asymptotically the maximum value of 10, as
predicted, and efficiency goes asymptotically towards zero, when the number of processors increases.
10,00 1,00
9,00 0,90
8,00 0,80
7,00 0,70
6,00 0,60
Efficiency
Speedup
5,00 Speedup 0,50

Efficiency
4,00 0,40
3,00 0,30
2,00 0,20
1,00 0,10
0,00 0,00
1 10 100 1000 10000
Processors
Figure 128 : Chart of speedup and efficiency example

8.3.5.3 Simulator test hardware

Network connecting the machines is a standard 10Mbps Ethernet. The computers are connected via twisted-pair
cables to Cisco systems Catalyst 1900 routing switch. The routing switch "supports up to 25 switched
(dedicated) Ethernet connections to workstations" [49] which means that compared to a hub, the other
(background) network traffic has much less of an effect on the network throughput and the delays. The network
topology is illustrated in Figure 129.
Computer 1
Computer 2
Other
Computer 3 Routing parts
Computer 4 … switch of
LAN
…
Computer N
Figure 129: Network topology
The machines, which are used in the cluster, are listed in Table 49. Sisoft Sandra [50] standard version
2001.0.7.10 was used to find out this information, including the measurement of MFLOPS, million floating
operations per second, with the Whetstone benchmark and MIPS, million instructions per second, with the
Dhrystone benchmark. The measured values of MFLOPS and MIPS are, according to the Sandra documentation,
comparable to similar values from other programs within +5-10%.
Table 49 : Cluster computer specifications
Id Operating system CPU Memory MFLOPS MIPS

1 Windows 2000 P3, 866 MHz 512 MB 1159 2292
2 Windows 2000 P3, 600 MHz 256 MB 806 1601
3 Windows 2000 P3, 600 MHz 256 MB 802 1583
4 Windows 2000 P3, 600 MHz 256 MB 802 1582
5 Windows NT 4, sp5 P2, 400 MHz 256 MB 540 1089
8.3.5.4 Simulator parallelization scheme

The general parallelization scheme for the simulator must support running both on only one computer and
several computers. Because their will always be a user-interface for the program and a central place for storing
the results, the structure can be based on a star topology. The central controller handles simulator initialization
and other non-palallelizable tasks while one or more calculation units perform the parallelizable tasks. A schema
of the parallelization scheme is shown in Figure 130.
The computer running the central controller can, as well, run one calculation unit. In a general case of a
processor farm, the farmer process (central controller) and the workers (calculation units) are not synchronized,
so there will be a problem with farmer and worker processes in the same computer disturbing each other, and

thus in practice requiring a dedicated computer for farmer after certain threshold [51]. However, in this simulator
the central processor and calculation units are synchronized, and thus they will not disturb each other - while one
is working the other is waiting. The requirement for running the system in one computer is fulfilled by allowing
the central controller and the calculation unit to run in one computer
Calculation Computer 2
unit
Calculation
unit Calculation Computer 3
unit
Computer 1
Central Calculation Computer 4
controller unit
…
Calculation Computer P
unit
Figure 130 : Simulator parallelization scheme
8.3.5.5 Simulator data flow

There is data that has to be transferred from the central controller to the calculation units and similarly from the
calculation units to the central controller. This state information is required during the simulation to keep all
calculation units up-to-date on global parameters that are calculated distributed. It is, as well, mandatory to
uphold global limits at a central place as no calculation unit knows the whole system state. Without this kind of a
control it would be possible, for example, for all calculation units to increase base station 1 total transmission
power from 5W to 20W (maximum value) independently, which would be ok if there were only one calculation
unit, but with 5 calculation units this would actually cause change from 5W to 5W+5*15W= 80W.
The amount of data flow must be minimized because it takes time to transmit the data and all this time increases
the overhead. The variables in the C++ program are integers (int) or floating-point numbers (float). These data
types are both 4 bytes long, which is equivalent to 32 bits. In order to carry out the minimization, only the
required state information or the change of state information is transmitted. For example, with the power control,
it is logical to carry out the actual power control at the calculation units and to make only the approval of all the
calculation unit changes at the central computer. Thus only the information about the change of the total
transmission power for each base station needs to transmitted (|BS| floats) instead of all the power control
requests and the changes of power for each mobile station (|BS|*|MS| bits + |BS|*|MS| floats). This kind of
optimization has a significant effect on the overhead. The actual data flows are shown in
Figure 131.

Central controller Calculation units
2 * |BS| floats
P RX,TOT
j, local
SIR calculation
P RX,TOT
j = P RX,TOT
j, local P RX,ALLTOT
j, local
P RX,ALLTOT
j = P RX,ALLTOT
j, local
P RX,TOT
j
P TX,TOT
j += P TX,TOT
j, approved
3 * |BS| floats
P RX,ALLTOT
j
P TX,TOT
j
Check that transmit power |BS| floats

P TX,TOT
control
j, proposed
Power
limit is not exceeded
P TX,TOT
j, approved
|BS| floats
P TX,TOT
j, approved
|BS| ints OVSF codes
Handovers
allocated, local
Calculate global OVSF
codes allocated |BS| ints OVSF codes
allocated
part of control
Circulate allocation command
Permission
permission between CUs
2 floats
Control
CU loads
int
Control command
Figure 131: Data flow diagram
The data flows of

Figure 131 can be divided into four sections: the SIR calculation, the power control, the handovers and the
control. Of course, in the actual implementation all the transmissions are combined so that all the data to one
direction is transmitted as one combined message. The data flow requires transmission of 3*|BS|+2 floats and
|BS| ints from the calculation units to the central controller, and 4*|BS| floats and |BS|+1 ints from the central
controller to the calculation units. As the size of both float and int are 4 bytes in the used environment, this
means (3*|BS|+2)*4 + |BS|*4 bytes from the calculation units to the central controller, and 4*|BS|*4 +
(|BS|+1)*4 bytes from the central controller to the calculation units. The total data to be transmitted during one
iteration of the simulation is thus ((3*|BS|+2)*4 + |BS|*4) + (4*|BS|*4 + (|BS|+1)*4) bytes = 36*|BS|+12 bytes.
The SIR calculation requires information on the total transmission powers and the received powers at the base
stations. The received powers are first calculated at the calculation units for all the local mobile stations, and
then these subsums are summed together at the central computer to get the global values. The update of the total
transmitted power of the base stations is based on the changes of the total transmission power from the power
control.

The power control must keep the total base station transmission power below the set total transmission power
limit. This is achieved by all the calculation units first proposing for a change of the total power. If this proposed
change does not cause the total global transmission power to exceed the limit value, the proposed value is
approved by the central controller; otherwise a smaller amount of power increase is approved. In the latter case,
the calculation unit has to redo the power control by using this new limit. This is, however, only a local operation
for the calculation unit.
The changeovers must be approved globally as well, because the number of OVSF codes per base station is
limited. Only one calculation unit at each iteration is allowed to allocate OVSF codes, and this permission is
circulated amongst the active calculation units. The number of allocated OVSF codes from the calculation unit,
which could allocate codes, is the global value for the next iteration.
The control command is used to control the calculation unit during the simulation. The command can be used to
calculate the next iteration, end the simulation, do check pointing, or indicate a permission to allocate OVSF
codes. In the actual implementation, the commands are bits of a 32bit integer. The calculation unit program load
(%) and idle load (%) are used at the central controller to monitor the background loads.
8.3.5.6 Simulator steps

A presentation of the simulator steps is shown in Figure 132 for the distributed, parallel version of the simulator.
The diagram is divided into two parts: the calculation unit N details and the central controller details. There are,
as well, some illustrations of the data flow between these parts. The arrows inside parts denote control flow
while arrows between parts denote data flow.

Calculation unit N
Initial data from SIR SIR pilot

Start
central controller calculations calculations
OVSF Allow
Propagation Shadowing Power control allocation Handover
loss proposition for CU?
No No
Yes
Stop Stop? Init calls
Power control Move MSs Congestion Terminate Admission

(as allowed) control calls control
Data from Data to

central central
controller controller
Calculation Calculation
unit 1 unit 2
Central controller
Data from Data from Data from

Start Initialize calculation calculation calculation
unit 1 unit 2 unit N
Process
data
Data to Data to Data to

calculation calculation calculation
unit N unit 2 unit 1
Calculation Calculation
unit 2 unit 1
Figure 132 : Parallel distributed simulator steps
8.3.5.7 Simulator runtime estimation
A simple model for parallel runtime was presented in previous paragraphs. However, there is also overhead
caused by, for example, communication delays of the used parallelization scheme and the hardware/software
environment. A more realistic model [52] of the execution time RP for a synchronous parallel algorithm running
I iterations using P processors is presented in Equation (14).

I
R p = ∑ t serial,i + max(t parallel,i, j ) + t par_overhead,i  (14)

i =1 
i≤ j ≤ P 
The runtime model Equation (14) parameters include

• Serial, i.e. non-parallelizable, execution time tserial,i of iteration i
• Parallel overhead execution time tpar_overhead,i of iteration i
• Parallel execution time tparallel,i,j of iteration i on processor j
8.3.5.7.1 Network communication

In order to estimate the overhead caused by network communication between distributed calculation units of the
system it is mandatory to predict the transmission times of data messages. These transmission times can be
modeled [53] for TCP socket-based communication with ethernet using Equation (15).
ttransmission = b0 + b1 * m (15)
The Equation (15) parameters include ttransmission as predicted time of transmission for a message of m bytes, b0 as
the base cost for each message in microseconds and b1 as the message size dependant factor in microseconds per
byte of data.
Because there can be a calculation unit at the same computer where the central controller is run, the local
transmission time must be measured as well. The local transmission time is several magnitudes faster because
the data doesn't have to be transported via the network, but only goes through layers of operating system.
Table 50 : Measured data for transmission of message
Message size Transmission time (ms) Time per message (ms)

(bytes) Local LAN Local LAN
2000 14761 76819 0.14761 3.84095
1000 11968 40709 0.11968 2.03545
500 11436 22623 0.11436 1.13115
250 11186 13680 0.11186 0.68400
100 11126 8662 0.11126 0.43310
50 11096 6809 0.11096 0.34045
10 11016 5067 0.11016 0.25335
1 10975 4756 0.10975 0.23780
The measurement data is shown in Table 50, and a graph of the data is shown in Figure 133. It is easily seen that
the LAN data seems to fit to a line nicely, while the local data is somewhat non-linear.

4,5 0,15
4,0 LAN transmission 0,145
Local transmission time, ms

LAN transmission time, ms
3,5 Local transmission 0,14

3,0 0,135
2,5 0,13
2,0 0,125
1,5 0,12
1,0 0,115
0,5 0,11
0,0 0,105
0 500 1000 1500 2000
Message size, bytes
Figure 133: Message transmission times vs. message size
The least-squares method was used to fit a line to the LAN measurement data, and the values of 1.80 µs/byte for
b1 and 240.3 µs for b0 were the result at R2 value of 0.9999. The inverse of b1 is throughput and the value above
gives 4.242 Mbps, which is reasonable considering the theoretical maximum of 10 Mbps for Ethernet. In
comparison, [53] reports 8.3 Mbps using 8 Kbytes messages with dedicated Silicon graphics Inc. (SGI)
workstations with IRIX 6.2 connected by Ethernet. The maximum error is 3% between measured values and
calculated values.
The least-squares method was used, as well, to fit a line to the local measurement data, and the values of 17.73
ns/byte for b1,local and 0.1083 µs for b0,local were the result at R2 value of 0.9883. The maximum error is 6%
between measured values and calculated values.
These results and Equation (15) are valid at least for m ∈ [1,2000]. This range is enough for 60 base stations
because according to the dataflow as defined above, the amount of data to be transmitted is 36*60+12 bytes =
2172 bytes, which is close enough to 2000 bytes.
The communication between the calculation units and the central controller is implemented with socket
programming within the simulator software and the communication overhead is composed of the transmissions
from all the calculation units to the central controller, and vice versa. The durations of these transmissions can be
predicted by Equation (16). The bytes of data transmitted per iteration, mdata,j, include the data transmission both
ways between the central controller and the calculation unit. Because the actual transmission of the data happens
as a separate transmission for each direction, the latency for both transmissions has to be included. A valuation
of mdata,j = 36*|BS|+12 bytes can be used based on the defined data flow.
P
t par_overhead,i = ∑ (2 * b0 + b1 * mdata, j ) = P * (2 * b0 + b1 * mdata, j ) (16)
j =1
8.3.5.7.2 Parallel part

It is possible to estimate the time tparallel,i,j by using a test program that executes iterations of the simulator code
using dummy data, thus lasting same amount of time as real simulation iterations. It is clear from the structure of
simulator algorithm that the runtime of the simulator algorithm is a function of the number of mobile stations

and base stations. For this test program, different numbers of base stations and mobile stations are used, with the
duration of the "call" from mobile station forced to start immediately and last the whole duration of the
simulation. In order to maintain full load on the simulator test code, the SIR limits and the OVSF code limits
were adjusted so that no calls would be blocked or dropped. The active set size was one.
The measurement of runtime was accomplished by measuring the start time of the first iteration of the algorithm,
and the end time of the last iteration. The start and end times were read with Win32 API function GetTickCount.
The measurements were performed with the cluster computer id 2 having no background load. Each runtime
includes 6000 iterations of the simulator algorithm.
14000
60 BS
50 BS
40 BS
12000
30 BS
25 BS
10000 20 BS
15 BS
14 BS
13 BS
Runtime (s)
8000
12 BS
11 BS
6000 10 BS
9 BS
8 BS
4000 7 BS
6 BS
5 BS
2000
4 BS
3 BS
2 BS
0
1 BS
0 500 1000 1500 2000 2500 3000
MS
Figure 134: Runtime estimation
A second-degree polynomial y = a1 x2 + a2 x + a3, where y is line coefficient and x is number of base stations, is
fit to the data of line coefficients. The fit gives polynomial coefficient values a1=1.32795*10-7, a2=3.93661*10-6,
a3=6.4*10-6. These values result in a reasonable fit to the line coefficients as seen in Figure 134 where both the
polynomial and the data points are shown.
Based on the measurements and the fitted curves, it is possible to express the runtime of one iteration of the
linear simulator with Equation (17). The constant offset c with value 8.33333*10-5 is used to make runtimes from
equation to be greater than or equal to the measured runtime, thus forcing the error limits to be nearer to the
shape "+error -0" rather than "±error". This correction term has most effect in cases of low number of MS where
the runtime is very short - in fact, the larger negative errors were always with 1 MS and an error of less than 0.5
seconds.
hom 2
tlinearsimu lator = ( a1 * BS + a2 * BS + a3 ) * MS + c (17)
The parameters of Equation (17) include

• Number of base stations |BS|
• Number of mobile stations |MS|
• Second degree polynomial coefficients a1, a2, a3
• Constant offset c
This equation is valid at least for |BS| ∈ [1,60], |MS| ∈ [1,3200]. Of course, the equation is valid only for the
computer used for measurements.

Based on Equation (17) it is possible to express the optimal parallel runtime as a function of the available
processors P.
2
(a * BS + a2 * BS + a3 ) * MS + c
t hom
parallel ,i , j = 1 (18)
P
An important point of Equation (18) is that the runtime of an iteration of the simulator algorithm is based on the
number of currently active mobile stations, |MS|. This number of currently active mobile stations can be
calculated from the starting parameters of the simulator; the mean call arrival intensity and the average call
duration. The number of base stations does not change during simulation, so |BS| is always known.
The simulator runtime for the other computers in the cluster must be known in order to estimate the runtime of
the heterogeneous cluster with non-identical computers. In order to achieve this, the test program was run on the
other computers of the cluster with 10 BS and various numbers of MS.
It can be perceived that the order of the computers based on MIPS and MFLOPS measurements, and the
runtimes, is practically the same. This can be used to approximate the runtime of the simulator on various
computers, based on the performance ratio between the computer id 2 used above and each computer of the
cluster. The performance ratio can be used to correct Equation (18) for each computer of the heterogeneous
cluster. Some performance ratios are shown in Table 51. A smaller value means that a computer is running the
test slower than the computer id 2.
Table 51 : Performance ratios for cluster computers

Ratios Computer
Computer
vs. computer 2 1 2 3 4 5 6 7
MIPS 1.44 1.00 1.00 1.00 0.67 0.67 0.50

MFLOPS 1.43 1.00 0.99 0.99 0.68 0.68 0.51
Runtimes 100MS, 10BS 1.40 1.00 1.00 0.98 0.66 0.67 0.48
Runtimes 400MS, 10BS 1.40 1.00 1.01 0.99 0.68 0.68 0.48
Runtimes 800MS, 10BS 1.38 1.00 0.99 0.97 0.68 0.68 0.48
Based on this performance ratio pk for computer k, the Equation (17) can be rewritten.
2
(a * BS + a2 * BS + a3 ) * MS k + c
tlinearsimulator ,k = 1 (19)
pk
In a heterogeneous cluster all the calculation units do not take the same time with the same number of MS for
each. This means that the estimate has to take the load balancing into consideration. An optimal load balancing
will cause the mobile stations, calls, to be divided among the calculation units based on their performance ratios.
The next equation presents such an optimal balancing for a calculation unit k.
pk
MS k = P
* MS (20)
∑p i =1
i
Based on this optimal division of the mobile stations among the calculation units, it is possible to express the
parallel runtime of any of the calculation units of the heterogeneous cluster, based on any of the calculation units
- i.e. because of optimality, all the runtimes are equal. The first calculation unit, and thus p1, was chosen.

2 p1
(a1 * BS + a2 * BS + a3 ) * P
MS + c
het
∑p k
t parallel ,i , j = k =1
(21)
p1
For an optimal solution, it is mandatory to include the calculation units with the best performance ratios, even
though more cluster calculation units would be available. This means that in case of the example cluster of this
work, computer id 1 would always be part of the solution. Thus it is necessary to define the notation so that the
numbering in the equations is always ordered by the performance ratios for the calculation units - i.e. calculation
unit k has a higher performance ratio than calculation unit k+1, where k ≥1.
8.3.5.7.3 Simulator serial part

There is no easy way to measure tserial,i without actually implementing the parallel and distributed version of the
simulator. However, based on the data flow of the simulation, the serial part consists mainly of a few sums and
comparisons with the complexity scaling to the number of base stations, thus O(|BS|). The runtime of these
operations is insignificant compared to the complexity of the simulation algorithm, and thus a simplification of
ignoring the serial part of runtime is done.
8.3.5.7.4 Heterogeneous cluster predictions

Based on the results of the previous paragraphs, for an optimal load balancing, it is possible to express runtime
for a heterogeneous cluster.
R phet = I (t het
parallel + t par_overhead )

( 2
)
 a1 * BS + a2 * BS + a3 * P 1 MS + c
p

 ∑ pk
= I k =1
+
p (22)
 1



( P − Plocal )(2 * b0 + b1 * (36 * BS + 12) ) +
Plocal (2 * b0,local + b1,local * (36 * BS + 12) ))
Parameters of Equation (22) include

• Number of iterations during simulator runtime I
• Number of calculation units P
• Number of calculation units at same computer as central controller Plocal
• Performance ratios pk
• Coefficients from previous paragraphs a1, a2, a3, b0, b1, b0,local, b1,local, c
• Number of mobile stations in simulation |BS|
• Number of on-going calls in simulation |MS|

The speedup calculations based on Equation (22) are shown in
Table 52 and visualized in Figure 135 as a 3D chart. The performance ratios are based on 800MS, 10BS
runtimes. Computer id 2 has a local calculation unit, so with P=1, Plocal=0, and with P>1, Plocal=1.
Table 52 : Speedup calculations for heterogeneous cluster
Numbers Speedup
MS BS 1 2 3 4 5 6 7
100 1 0.76 0.81 0.61 0.47 0.38 0.32 0.27
100 5 0.97 1.26 1.05 0.86 0.70 0.60 0.51
100 10 1.08 1.51 1.36 1.16 0.97 0.84 0.73
100 15 1.13 1.65 1.57 1.38 1.18 1.02 0.89
100 20 1.16 1.75 1.73 1.56 1.35 1.18 1.04
100 30 1.21 1.88 1.96 1.84 1.63 1.45 1.29
100 40 1.24 1.96 2.13 2.06 1.87 1.68 1.51
100 50 1.26 2.02 2.26 2.24 2.06 1.88 1.70
100 60 1.27 2.06 2.36 2.39 2.24 2.06 1.88
400 1 1.14 1.61 1.58 1.42 1.24 1.09 0.96
400 5 1.25 1.94 2.17 2.15 1.98 1.82 1.65
400 10 1.29 2.08 2.46 2.57 2.46 2.32 2.15
400 15 1.31 2.14 2.62 2.83 2.77 2.66 2.49
400 20 1.32 2.18 2.72 3.00 2.99 2.91 2.76
400 30 1.33 2.23 2.86 3.24 3.31 3.29 3.17
400 40 1.34 2.26 2.94 3.40 3.53 3.57 3.48
400 50 1.35 2.28 3.00 3.52 3.70 3.78 3.73
400 60 1.35 2.29 3.05 3.61 3.83 3.96 3.93
800 1 1.25 1.92 2.15 2.14 1.99 1.83 1.66
800 5 1.31 2.14 2.64 2.88 2.84 2.75 2.60
800 10 1.33 2.22 2.85 3.23 3.30 3.30 3.19
800 15 1.34 2.26 2.95 3.42 3.57 3.63 3.55
800 20 1.35 2.28 3.01 3.55 3.75 3.86 3.82
800 30 1.36 2.30 3.09 3.71 3.99 4.17 4.19
800 40 1.36 2.32 3.14 3.81 4.14 4.39 4.45
800 50 1.36 2.33 3.18 3.89 4.26 4.55 4.65
800 60 1.37 2.33 3.20 3.94 4.34 4.67 4.81
1600 1 1.31 2.12 2.62 2.87 2.85 2.77 2.62
1600 5 1.35 2.25 2.96 3.46 3.63 3.71 3.66
1600 10 1.36 2.30 3.09 3.70 3.99 4.18 4.20
1600 15 1.36 2.32 3.15 3.83 4.17 4.43 4.51
1600 20 1.36 2.33 3.18 3.90 4.29 4.60 4.72
1600 30 1.37 2.34 3.23 4.00 4.44 4.82 5.00
1600 40 1.37 2.35 3.25 4.06 4.54 4.96 5.18
1600 50 1.37 2.35 3.27 4.10 4.61 5.06 5.31
1600 60 1.37 2.36 3.28 4.13 4.66 5.13 5.41
3200 1 1.35 2.25 2.95 3.45 3.63 3.73 3.68
3200 5 1.36 2.32 3.15 3.85 4.21 4.50 4.60
3200 10 1.37 2.34 3.22 4.00 4.44 4.82 5.00
3200 15 1.37 2.35 3.25 4.07 4.56 4.99 5.22
3200 20 1.37 2.35 3.27 4.11 4.63 5.09 5.35
3200 30 1.37 2.36 3.30 4.16 4.71 5.22 5.53
3200 40 1.38 2.36 3.31 4.20 4.77 5.30 5.63
3200 50 1.38 2.37 3.32 4.22 4.80 5.36 5.71
3200 60 1.38 2.37 3.33 4.23 4.83 5.40 5.77

6,00
5,00
4,00
Speedup
3,00
7
2,00
5
1,00 3
1
0,00
3200, 60
3200, 50
3200, 40
3200, 30
3200, 20
3200, 15
3200, 10
3200, 5
3200, 1
1600, 60
1600, 50
1600, 40
1600, 30
1600, 20
1600, 15
1600, 10
1600, 5
1600, 1
800, 60
800, 50
800, 40
800, 30
800, 20
800, 15
800, 10
800, 5
800, 1
400, 60
400, 50
400, 40
400, 30
400, 20
400, 15
400, 10
400, 5
400, 1
100, 60
100, 50
100, 40
100, 30
100, 20
100, 15
100, 10
100, 5
100, 1
Processors
MS, BS
Figure 135: Heterogeneous cluster speedup
These calculated speedups are for the optimal case of the example heterogeneous cluster. When the fastest
computers are not available, the slower computers will not reach as good a speedup.
Based on the results from speedup calculations, it is obvious that it is feasible to parallelize the simulator. In a
realistic simulation with 40 base stations with 40 active calls (mobile stations) per base station, total 1600 MS, it
will take approximately half an hour real time per 4 seconds of simulation time at full 1.5kHz power control
frequency. This means that 15 minutes of simulation time would take nearly 6 days with the linear simulator, but
only 1 day with the 7 machine heterogeneous cluster described above. To put it in another way, one can run half
an hour of simulation time during a weekend with the cluster, while the same simulation would take nearly two
weeks with the linear simulator.
It is clearly necessary to take into consideration in load sharing that only an optimal number of calculation units
should be used even though more might be available, because it can be seen that too many calculation units
cause the speedup to become smaller. The Equation (22) can be used in a load sharing algorithm to make this
decision. The Equation (20) can directly be used for general load sharing - i.e. distribution of the mobile stations
to the calculation units.
8.3.5.7.5 Measured runtimes

The runtime data from the performed measurements is shown in (22). The speedup calculations based on the
measurements are shown in Table 53, Table 54 and visualized in Figure 136.
Table 53 : Distributed parallel simulator measured runtimes

Numbers Runtime (vs. number of CUs)
MS BS 1 2 3 4 5 6 7
100 1 11.166 12.838 17.165 21.091 24.215 25.015 29.062
100 10 33.028 29.763 24.375 23.350 27.920 30.797 34.029
100 20 67.577 47.769 42.381 38.886 39.819 39.922 47.121
100 40 170.425 112.482 88.878 80.369 83.280 83.328 93.485
100 60 320.090 207.026 161.623 144.517 144.428 143.109 156.655
400 1 23.073 20.470 21.171 21.364 24.438 29.250 32.316

400 10 104.541 68.859 52.826 45.552 45.128 47.750 50.342

400 20 234.196 144.477 108.226 91.481 84.019 80.109 80.660
400 40 629.586 387.247 275.586 226.508 202.513 193.969 194.990
400 60 1205.233 731.323 525.672 437.950 399.835 361.016 357.124
800 1 42.151 31.726 27.480 26.310 28.864 33.437 36.483
800 10 209.091 123.938 91.862 75.296 71.978 69.750 69.996
800 20 478.027 274.384 201.310 159.077 143.485 134.703 128.751
800 40 1252.834 754.355 529.372 425.004 374.308 344.500 326.279
800 60 2474.659 1463.725 1039.290 826.230 711.783 656.781 614.734
1600 1 95.998 53.777 40.879 38.566 39.627 41.235 43.723
1600 10 464.738 248.838 177.856 137.546 125.072 115.344 111.465
1600 20 1030.812 552.825 392.604 309.060 269.077 244.282 229.963
1600 40 2687.638 1477.924 1054.570 838.579 722.276 645.360 610.919
1600 60 5078.262 2880.082 2117.207 1613.806 1411.933 1243.812 1155.872
3200 1 208.339 123.768 80.216 64.343 58.236 58.109 63.057
3200 10 1025.355 579.673 373.267 276.170 243.821 215.906 207.504
3200 20 2240.362 1254.975 818.207 626.023 537.596 477.454 441.705
3200 40 5720.216 3254.072 2151.504 1726.438 1426.858 1273.407 1174.586
3200 60 10693.747 6088.775 4447.265 3231.917 2728.256 2472.098 2267.954
Table 54 : Distributed parallel simulator speedup based on measurements
Numbers Speedup (vs. number of CUs)

MS BS 1 2 3 4 5 6 7
100 1 0.46 0.40 0.30 0.24 0.21 0.20 0.18
100 10 0.90 0.99 1.21 1.27 1.06 0.96 0.87
100 20 1.07 1.51 1.70 1.86 1.81 1.81 1.53
100 40 1.23 1.86 2.36 2.61 2.52 2.52 2.24
100 60 1.28 1.98 2.54 2.84 2.84 2.87 2.62
400 1 0.84 0.95 0.92 0.91 0.79 0.66 0.60
400 10 1.18 1.80 2.34 2.72 2.74 2.59 2.46
400 20 1.26 2.05 2.73 3.23 3.52 3.69 3.66
400 40 1.34 2.18 3.07 3.73 4.17 4.36 4.33
400 60 1.36 2.25 3.13 3.75 4.11 4.55 4.60
800 1 0.97 1.29 1.48 1.55 1.41 1.22 1.12
800 10 1.21 2.04 2.75 3.36 3.51 3.62 3.61
800 20 1.28 2.23 3.04 3.84 4.26 4.54 4.75
800 40 1.35 2.24 3.19 3.98 4.52 4.91 5.18
800 60 1.33 2.25 3.17 3.99 4.64 5.02 5.37
1600 1 1.00 1.78 2.35 2.49 2.42 2.33 2.19
1600 10 1.18 2.20 3.08 3.99 4.39 4.76 4.92
1600 20 1.23 2.30 3.24 4.12 4.73 5.21 5.53
1600 40 1.31 2.37 3.33 4.18 4.86 5.44 5.74
1600 60 1.34 2.36 3.22 4.22 4.82 5.48 5.89
3200 1 1.01 1.70 2.63 3.28 3.62 3.63 3.34
3200 10 1.12 1.99 3.09 4.17 4.73 5.34 5.56
3200 20 1.19 2.13 3.26 4.26 4.96 5.59 6.04
3200 40 1.27 2.23 3.37 4.20 5.08 5.70 6.17
3200 60 1.31 2.30 3.14 4.33 5.12 5.66 6.16

7,00
6,00
5,00
Speedup
4,00 7
3,00 5
2,00
3
1,00
1
0,00
Processors
3200, 60
3200, 40
3200, 20
3200, 10
3200, 1
1600, 60
1600, 40
1600, 20
1600, 10
1600, 1
800, 60
800, 40
800, 20
800, 10
800, 1
400, 60
400, 40
400, 20
400, 10
400, 1
100, 60
100, 40
100, 20
100, 10
100, 1
MS, BS
Figure 136: Actual speedup based on measurements
8.3.5.7.6 Measured loads

The simulation was run with either load balancing, according to Equation (20), or with equal number of mobile
stations per calculation unit. For an example case of 1600 mobile stations and 40 base stations, the measured
runtimes were 601.768 seconds with load balancing and 1029.090 seconds with equal number of MS. The loads
of the calculation unit computers are shown in Figure 137, Figure 138, and Figure 139. The loads were recorded
once per iteration, as received to the central controller according to the data flow, but measured at each
calculation unit with an interval of one second. Similarly, with 3200 mobile stations and 60 base stations the
runtimes were 2267.954 seconds and 4132.833 seconds. The runtime of the non-load-balanced simulation run
was roughly twice the duration of the load-balanced runtime in each case. The average loads for the load
balanced runs were 95.5 % for 3200 mobile station, 60 base station run and 90.1% for 1600 mobile station, 40
base station run.
Figure 137: Measured loads for 40BS, 1600MS, non-load-balanced run

Figure 138: Measured loads for 40BS, 1600MS load-balanced run
Figure 139: Measured loads for 60BS, 3200MS load-balanced run

9 CONCLUSIONS
In this document the work that has been carried out in the second WP is presented. The scope of this WP was the
in-depth investigation of the congestion reasons and the system requirements analysis. In order to cover all
aspects it was important to consider all theoretical background of the existing and future generation systems’
architecture. Signaling mechanisms were in-depth studied and system requirements were examined. The main
result of the study can be simply stated as follows: “Existing cellular system are not optimized”. In the light of
introduction of new generation networks several issues have to be considered. Despite the operational and
technical considerations, user satisfaction and operator’s profit should be taken into account. Moreover, the
exploitation of cellular networks for PMR use is another important reason to consider upgrading of the system.
Important conclusions from the extensive statistical analysis have lead to conclusions that were not expected.
The congestion reasons are not the obvious. On the other hand there are several mechanisms for resource
management both for 2G and 3G. Some of the presented techniques are more theoretical but other can be really
applied in exiting networks. Moreover the whole concept of dynamic reconfiguration ensures the optimal usage
of the network. The cell breathing in GSM, even for idle-mode connections, is of great innovation and can lead
to optimal use of network in limited congestions.
Emphasis was also given in emerging technologies. GSM networks will continue to exist, especially after the
introduction of GPRS and the promised bandwidth utilization. On the other hand, this work should not be limited
got 2G. The main idea should remain the same, as well as the general system architecture. The CAUTION
elements will follow the same concept of processing, but additional techniques will be implemented. For that
scope a powerful 3G simulator will be developed.

10 APPENDIX 1: REPORTING IN GSM
10.1 Event counters

This subsection deals with all the event counters studied. They are divided into two basic categories: the ones
that refer to measurements that are affected mainly in a congestion situation and the ones that refer to handover
measurements and statistics. Each category is also divided into more specified ones, according to different
criteria.
10.1.1 SDCCH basic counters

The following counters refer to the SDCCH channel in terms of traffic and congestion study. They count total
attempts of seizing the channel, their success or not and different activities that an SDCCH channel is requested
for and reserved for. This is very useful in monitoring the traffic load on the SDCCH, calculating the success rate
of its reservation/activation and estimating the load of each activity to the total traffic load of the channel.
1. SDCCH_SEIZ_ATT : This counter refers to the attempts made for an SDCCH seizure. It consists of all the
possible reasons that an SDCCH is required (call, HO, Location Update, SMS etc.). It is updated when the
Radio Resource Manager receives an SDCCH seizure request directly after receiving a channel request from
an MS in a call or HO attempt. To be more specific, the counter is triggered when a Channel Required
message is received by the BSC. The procedure is generated by the MS, which sends a Channel Request
message on the RACH to the BTS. Then the BTS forwards it to the BSC.
2. SDCCH_BUSY_ATT : This counter refers to the SDCCH seizure attempts that are unsuccessful because
all SDCCHs are busy. It is updated when no SDCCH is available upon request from the Radio Resource
Manager in either a call or handover attempt. The triggering takes place after the Channel Required message
is received by the BSC and no channel is available. It is a very important counter as it pinpoints exactly the
problem of SDCCH congestion, which leads to network unavailability.
3. SDCCH_ASSIGN : This counter refers to the successful SDCCH seizures for immediate assignment. It is
updated when the Radio Resource Manager allocates an SDCCH for immediate assignment (call setup). It is
triggered when the Assignment Command message is generated by the BSC and sent to the BTS, as soon as
the Channel Activation Ack. message is received. It includes seizures for all the services (calls, SMS,
Location Update, emergency, re-establishment) other than handover, which is counted by a different object
(SDCCH_HO_SEIZ).
4. SDCCH_HO_SEIZ : This counter refers to the successful SDCCH seizures for a handover. It is updated
when the Radio Resource Manager allocates an SDCCH as a response to an SDCCH request during a
handover attempt. It is triggered when the HO Command message is generated by the BSC and sent to the
BTS, as soon as the Channel Activation Ack. message is received. The triggering point is similar to
SDCCH_ASSIGN’s point, speaking in terms of procedure (similarity concerning Immediate Assign
Command to HO Command).
5. SUCC_SEIZ_TERM : This counter refers to the successful SDCCH seizures for a mobile terminated call.
It is increased by one every time that an Establishment Indication containing a paging response is received
on SDCCH from the BTS. The exact procedure is generated by the MS, which sends the SABM
(CM_SERVICE_REQUEST), containing a paging response, to the BTS. Then the BTS forwards this
message as an Establish Indication to the BSC. Finally, a SABM (Paging Response message) is forwarded
to the MSC. This counter is very useful in estimating the traffic load of different services served by SDCCH
and, in particular, the load of mobile terminated calls.

6. SUCC_SEIZ_ORIG : This counter refers to the successful SDCCH seizures for a mobile originated call. It
is increased by one every time that an Establishment Indication containing a CM Service Request is received
on SDCCH from the BTS. The exact procedure is generated by the MS, which sends the SABM
(CM_SERVICE_REQUEST), containing a service request for a mobile originated call, to the BTS. Then the
BTS forwards this message as an Establish Indication to the BSC. Finally, a SABM
(CM_SERVICE_REQUEST message) is forwarded to the MSC. This counter is very useful in estimating
the traffic load of different services served by SDCCH and, in particular, the load of mobile originated calls.
7. SDCCH_LOC_UPD : This counter refers to the successful SDCCH seizures for location updating. It is
increased by one every time that an Establishment Indication containing a Location Update Request is
received on SDCCH from the BTS. The exact procedure is generated by the MS, which sends the SABM
(CM_SERVICE_REQUEST), containing a location update request, to the BTS. Then the BTS forwards this
message as an Establish Indication to the BSC. Finally, a SABM (CM_SERVICE_REQUEST message) is
forwarded to the MSC. This counter is very useful in estimating the traffic load of different services served
by SDCCH and, in particular, the load of location updating.
8. SDCCH_EMERG_CALL : This counter refers to the successful SDCCH seizures for an emergency call. It
is increased by one every time that an Establishment Indication containing an emergency call request is
received on SDCCH from the BTS. The exact procedure is generated by the MS, which sends the SABM
(CM_SERVICE_REQUEST), containing an emergency call request, to the BTS. Then the BTS forwards
this message as an Establish Indication to the BSC. Finally, a SABM (CM_SERVICE_REQUEST message)
is forwarded to the MSC. This counter is very useful in estimating the traffic load of different services
served by SDCCH and, in particular, the load of emergency calls.
9. SDCCH_CALL_RE_EST : This counter refers to the successful SDCCH seizures for a call re-
establishment. It is increased by one every time that an Establishment Indication containing a call re-
establishment request is received on SDCCH from the BTS. The exact procedure is generated by the MS,
which sends the SABM (CM_SERVICE_REQUEST), containing a call re-establishment request, to the
BTS. Then the BTS forwards this message as an Establish Indication to the BSC. Finally, a SABM
(CM_SERVICE_REQUEST message) is forwarded to the MSC. This counter is very useful in estimating
the traffic load of different services served by SDCCH and, in particular, the load of call re-establishment.
10. SUCC_SDCCH_SMS_EST : This counter refers to the number of successful SMS establishments on the
SDCCH. It is augmented by one every time that an Establish Indication (mobile originated SMS) or
Establish Confirm (mobile terminated SMS) is received on the SDCCH from the BTS. The procedure differs
a little from the ones mentioned above, because the Establish Indication and Confirm messages are
generated after the Ua message (SAPI=3), so the counter is triggered later than the above counters. In a
mobile terminated SMS, the MSC starts the procedure by sending a Cp data message (instead of a Setup
message as in normal MTC), which is forwarded to the MS as a SABM (SAPI=3). The MS responds with a
Ua (SAPI=3) and then an Establish Confirm is sent to the BSC, thus triggering the counter. In a mobile
originated SMS, the MS starts the procedure by sending SABM (SAPI=3) (instead of a Setup message as in
normal MOC). The BTS responds with a Ua (SAPI=3) and generates an Establish indication message that is
sent to the BSC, thus triggering the counter.
11. UNSUCC_SDCCH_SMS_EST : This counter refers to the number of unsuccessful SMS establishments on
the SDCCH. It is augmented by one every time that an SMS establishment has failed on the SDCCH. The
procedure is the same as described above and the counter is triggered after the Establish Indication or
Confirm messages have failed. This counter and the preceding one indicate the load of SMS on the total
traffic load of the SDCCH.
12. SDCCH_MOC_SEIZ_ATT : This counter refers to the number of SDCCH seizure attempts for a MOC. It
is triggered after the Channel Required message, containing a user’s request for a mobile originated call, is
received by the BSC.
13. SDCCH_MTC_SEIZ_ATT : This counter refers to the number of SDCCH seizure attempts for a MTC. It
is triggered after the Channel Required message, containing an answer for paging (mobile terminated call),
is received by the BSC.

14. IMM_ASSGN_SENT : This counter refers to the number of immediate assignment messages sent to the
BTS. It is increased by one every time that an Immediate Assign Command containing an immediate
assignment is sent to the BTS.
15. IMM_ASSGN_REJ : This counter refers to the number of immediate assignment reject messages sent to
the BTS. It is increased by one every time that the BSC sends the Immediate Assignment Reject message to
the MS, if the SDCCH channel reservation or activation has failed.
10.1.2 SDCCH transaction failures

The following counters refer to the transaction failures that take place during the SDCCH establishment part.
They point out the cause of the failure and the respective point of the procedure, so they help in retrieving
problems that occur while the SDCCH establishment is attempted.
1. SDCCH_RADIO_FAIL : This counter refers to the number of SDCCH transaction failures due to radio
failure. It is updated when an SDCCH transaction fails and the SDCCH is released in the Radio Resource
Manager due to radio failure. To be more specific, the cause is connection failure during SDCCH
assignment and the counter is triggered after the RF Channel Release Ack. message is received by the BSC.
2. SDCCH_LAPD_FAIL : This counter refers to the number of SDCCH transaction failures due to LAPD
failure. It is updated when an SDCCH transaction fails and the SDCCH is released in the Radio Resource
Manager due to a TRX blocked caused by a LAPD failure. To be more specific, the TRX blocked is in one
of the following substates : signaling link fault or PCM fault. The counter is triggered after the RF Channel
Release Ack. message is received by the BSC and the impact to the procedure is Call clear.
3. SDCCH_BTS_FAIL : This counter refers to the number of SDCCH transaction failures due to BTS failure.
It is updated when an SDCCH transaction fails and the SDCCH is released in the Radio Resource Manager
due to a TRX blocked caused by a BTS failure. To be more specific, the TRX blocked is in one of the
following substates : FU fault, CU fault, BTS reset, BCF reset, both FU and CU fault, BCF fault. The
counter is triggered after the RF Channel Release Ack. message is received by the BSC and the impact to
the procedure is Call clear.
4. SDCCH_USER_ACT : This counter refers to the number of SDCCH transaction failures due to user
actions. It is updated when a busy SDCCH is disconnected by blocking the TSL/TRX with a MML
command. The transaction fails and the SDCCH is released in the Radio Resource Manager. To be more
specific, the TRX/TSL blocked is in the substate : blocked by user. The counter is triggered after the RF
Channel Release Ack. message is received by the BSC and the impact to the procedure is HO Failure/Call
clear.
5. SDCCH_NETW_ACT : This counter refers to the number of SDCCH transaction failures due to radio
network reconfiguration actions. It is updated when an SDCCH transaction fails and the SDCCH is released
in the Radio Resource Manager due to a TRX blocked caused by a failure which leads to TRX
reconfiguration. The failure may occur both during call and handover attempts. The TRX blocked is in the
substate : blocked by system. The counter is triggered after the RF Channel Release Ack. message is
received by the BSC and the impact to the procedure is HO Failure/Call clear.
6. SDCCH_RF_OLD_HO : This counter refers to the number of SDCCH transaction failures due to radio
failure on the former channel during an SDCCH>SDCCH or SDCCH>TCH handover. It is updated when an
SDCCH transaction fails and the SDCCH is released in the Radio Resource Manager due to radio failure
(handover failure) of the former channel during a handover attempt. It is similar to the
SDCCH_RADIO_FAIL counter, as in terms of procedure. The cause is connection failure during SDCCH
assignment and the counter is triggered after the RF Channel Release Ack. message is received by the BSC.
It must be noted that the counter is updated on source cell side. If the target cell is in the same BSC, the
following counter (SDCCH_RF_NEW_HO) is updated in the target.

7. SDCCH_RF_NEW_HO : This counter refers to the number of SDCCH transaction failures due to radio
failure on the new channel during an SDCCH>SDCCH or SDCCH>TCH handover. It is updated when an
SDCCH transaction fails and the SDCCH is released in the Radio Resource Manager due to radio failure
(handover failure) of the new channel during a handover attempt. Radio failure in this case is caused by
incomplete access of the MS to the new channel. The reason may be missing establish indication, missing
HO detection, missing handover completed or corruption of handover related messages. The impact in the
procedure is HOFailure/Possible Call clear.
10.1.3 Paging and RACH access/availability

The following counters refer to the procedure that precedes the SDCCH signaling and establishment part and
concerns the paging and the first response of the MS for a channel request on the RACH.
1. PAGING_MSG_SENT : This counter refers to the number of paging commands sent to the BTS. It is
increased by one every time a Paging Command is sent to the BTS. The procedure is generated by the MSC,
which sends a UDT (Paging) message to the BSC. The BSC then forwards it to the BTS as a Paging
Command message. Finally, the message is sent to the MS on the PCH as a Paging Request message. It can
be very useful in monitoring the increase of the paging load, in case of reduction of the location updates.
2. GHOST_CCCH_RES : This counter refers to the number of ghost reservations on the CCCH. It is
augmented by one every time that a ghost reservation is rejected on the CCCH. To be more specific, the
counter is triggered whenever a Channel Required message containing an invalid establishment cause is
detected by the BSC.
3. AVE_RACH_BUSY : This counter refers to the average RACH busy count on the CCCH. It is updated
whenever a CCCH Load Indication (included in a Channel Required message) is received from the BTS.
Then the RACH busy count value is added to the old RACH busy count value and the number of events is
increased by one.
4. AVE_RACH_ACCESS : This counter refers to the average RACH access count on the CCCH. It is
updated whenever a CCCH Load Indication (included in a Channel Required message) is received from the
BTS. Then the RACH access count value is added to the old RACH access count value and the number of
events is increased by one.
10.1.4 TCH Basic Counters

The following counters refer to the TCH channel in terms of traffic and congestion study. They count total
attempts of seizing the channel, their success or not and different activities (normal call, handover) that a TCH
channel is requested for and reserved for. This is very useful in monitoring the traffic load on the TCH,
calculating the success rate of its reservation/activation and estimating the load of each activity to the total traffic
load of the channel.
1. TCH_REQUEST : This counter refers to the number of TCH requests, both successful and unsuccessful. It
is updated when the Radio Resource Manager receives a TCH request in a call or handover attempt. The
actual triggering of the counter takes place when the Physical Context Confirm message is received by the
BSC. Then the BSC searches for the relevant TCH using channel reservation procedure described on the
SDCCH. This counter is very important as it shows the number of successful passes through the signaling
procedure (SDCCH).
2. TCH_REQ_REJ_LACK : This counter refers to the number of rejected TCH requests due to lack of radio
resources, whether or not queuing has occurred. It is updated when no TCHs are available when requested
from the Radio Resource Manager in either a call or handover attempt. The counter may be updated

immediately after the TCH request in case of queuing, after the queuing timer expires. The actual triggering
of the counter takes place when the Physical Context Confirm message is received by the BSC. Then the
BSC returns an Assignment Failure message with the cause “no radio resource available”.
3. TCH_CALL_REQ : This counter refers to the number of TCH requests for normal assignment, both
successful and unsuccessful. It is updated when the Radio Resource Manager receives a TCH request in a
call attempt. The actual triggering of the counter takes place when the Physical Context Confirm message is
received by the BSC, during a call attempt. Then the BSC searches for the relevant TCH using channel
reservation procedure described on the SDCCH.
4. TCH_NORM_SEIZ : This counter refers to the number of successful TCH requests for a normal
assignment. It is updated when the Radio Resource Manager allocates a TCH as a response to a TCH
request in a call attempt. The actual triggering of the counter takes place after the Physical Context Confirm
message is received by the BSC, during a call attempt. Then the BSC searches for the relevant TCH using
channel reservation procedure described on the SDCCH, reserves and activates the TCH and sends a
Channel Activation message to the BTS.
5. TCH_HO_SEIZ : This counter refers to the number of successful TCH requests for handover purposes. It
is updated when the Radio Resource Manager allocates a TCH as a response to a TCH request in a handover
attempt. The actual triggering of the counter takes place after the Physical Context Confirm message is
received by the BSC, during a handover attempt. Then the BSC searches for the relevant TCH using channel
reservation procedure described on the SDCCH, reserves and activates the TCH and sends a Channel
Activation message to the BTS.
6. TCH_SEIZ_FAILS_DUE_CONG : This counter refers to the number of TCH seizure failures due to
congestion, during call setup. It is updated when no TCHs are available when requested from the Radio
Resource Manager in a call attempt and queuing or directed retry are not allowed. The actual triggering of
the counter takes place when the Physical Context Confirm message is received by the BSC. Then the BSC
returns an Assignment Failure message with the cause “no radio resource available”.
7. TCH_SEIZ_ATT_DUE_SDCCH_CON : This counter refers to the number of seizure attempts of TCH in

a FACCH call setup due to SDCCH congestion. It is updated when the Radio Resource Manager tries to
allocate a TCH as a response to an SDCCH seizure request in SDCCH congestion situation. An attempt is
made to allocate a TCH if the SDCCH load is above the defined threshold and the TCH allocation is
allowed in the Channel Required message (triggering of the FACCH call setup procedure).
8. TCH_SEIZ_DUE_SDCCH_CON : This counter refers to the number of successful seizures of TCH in a

FACCH call setup due to SDCCH congestion. It is updated when the Radio Resource Manager allocates a
TCH in response to an SDCCH seizure request in SDCCH congestion situation. A TCH is allocated if the
SDCCH load is above the defined threshold and the TCH allocation is allowed in the Channel Required
message (triggering of the FACCH call setup procedure).
10.1.5 TCH transaction failures
The following counters refer to the transaction failures that take place during the TCH reservation/activation
part. They point out the cause of the failure and the respective point of the procedure, so they help in retrieving
problems that occur while the TCH activation is attempted.
1. TCH_RADIO_FAIL : This counter refers to the number of TCH transaction failures due to radio failure. It
is updated when a TCH transaction fails and the TCH is released in the Radio Resource Manager due to
radio failure. To be more specific, the cause is connection failure during TCH assignment and the counter is
triggered after the TCH RF Channel Release Ack. message is received by the BSC.

2. TCH_RF_OLD_HO : This counter refers to the number of TCH transaction failures due to radio failure on
the former channel, during a TCH handover. It is updated when a TCH transaction fails and the TCH is
released in the Radio Resource Manager due to radio failure (handover failure) of the former channel during
a handover attempt. It is similar to the TCH_RADIO_FAIL counter, as in terms of procedure. The cause is
connection failure during TCH assignment and the counter is triggered after the TCH RF Channel Release
Ack. message is received by the BSC. It must be noted that the counter is updated on source cell side. If the
target cell is in the same BSC, the following counter (TCH_RF_NEW_HO) is updated in the target.
3. TCH_RF_NEW_HO : This counter refers to the number of TCH transaction failures due to radio failure on
the new channel, during a TCH handover. It is updated when a TCH transaction fails and the TCH is
released in the Radio Resource Manager due to radio failure (handover failure) of the new channel during a
handover attempt. Radio failure in this case is caused by incomplete access of the MS to the new channel.
The reason may be missing establish indication, missing HO detection, missing handover completed or
corruption of handover related messages. The impact in the procedure is HO Failure.
4. TCH_TR_FAIL : This counter refers to the number of TCH transaction failures due to transcoder failure. It
is updated when a TCH transaction fails and the TCH is released due to transcoder failure, during a call
attempt. The counter is triggered after the TCH RF Channel Release Ack. message is received by the BSC.
The impact in the procedure is Call clear.
5. TCH_TR_FAIL_OLD : This counter refers to the number of TCH transactions ended due to transcoder
failure on the old channel, during a HO on a TCH. It is updated when a TCH transaction fails and the TCH
is released due to transcoder failure on the old channel, during a handover attempt. The counter is triggered
after the TCH RF Channel Release Ack. message is received by the BSC, that is before the
Handover/Assignment Complete message is received from the MS. The impact in the procedure is HO
Failure/Possible Call clear.
6. TCH_TR_FAIL_NEW : This counter refers to the number of TCH transactions ended due to transcoder
failure on the new channel, during a HO on a TCH. It is updated when a TCH transaction fails and the TCH
is released due to transcoder failure on the new channel, during a handover attempt. The counter is triggered
after the TCH RF Channel Release Ack. message is received by the BSC, that is before the
Handover/Assignment Complete message is received from the MS. The impact in the procedure is HO
Failure/Possible Call clear.
10.1.6 SDCCH /TCH availability

The following counters refer to the network resources’ availability. They contain information on the availability
of SDCCHs and TCHs, time congestion of SDCCH and TCH, average number of busy SDCCHs and TCHs. It
must be noted that in all averaged statistical items, the sampling interval for defined counters is 20 seconds. This
means that the statistical item is checked every 20 seconds. The average column contains the total number of the
item (from each 20 sec check) and the corresponding denominator column contains the number of samples (the
measurement period is 1 hour, so the denominator’s value is 180). The actual average is estimated when the total
is divided by the denominator.
1. AVE_SDCCH_SUB : This counter refers to the average number of available SDCCH subchannels. The
sampled counter is updated when the :
• TRX is unblocked
• TRX is blocked
• SDCCH TSL is unblocked
• SDCCH TSL is blocked
2. AVE_BUSY_TCH : This counter refers to the average number of busy TCHs. The sampled counter is
updated when a TCH is seized or released.

3. AVE_BUSY_SDCCH : This counter refers to the average number of busy SDCCH subchannels. The
sampled counter is updated when an SDCCH is seized or released.
4. AVE_NON_AVAIL_SDCCH : This counter refers to the actual average number of non available
SDCCHs, as it is the division of the average number of non available SDCCHs by the corresponding
denominator.
5. AVE_NON_AVAIL_TCH : This counter refers to the actual average number of non available TCHs, as it
is the division of the average number of non available TCHs by the corresponding denominator.
6. AVE_TCH_AVAIL_HALF : This counter refers to the actual average number of available half rate TCHs,
as it is the division of the average number of available half rate TCHs by the corresponding denominator.
The sampled counter is updated when the :
• TRX is unblocked
• TRX is blocked
• TCH TSL is unblocked
• TCH TSL is blocked
7. AVE_TCH_BUSY_FULL : This counter refers to the actual average number of busy full rate TCHs, as it is
the division of the average number of busy full rate TCHs by the corresponding denominator.. The sampled
counter is updated when a full rate TCH is seized or released.
8. AVE_TCH_BUSY_HALF : This counter refers to the actual average number of busy half rate TCHs, as it
is the division of the average number of busy half rate TCHs by the corresponding denominator.. The
sampled counter is updated when a half rate TCH is seized or released.
9. TCH_CONG_TIME : This counter refers to the total TCH busy time. The value gives information about
the total congestion time in a measurement period. The time measurement is started when all TCHs are
occupied (last free is just seized) and stopped when the first TCH is released and marked as free. The unit of
the value is 10 ms.
10. SDCCH_CONG_TIME : This counter refers to the total SDCCH busy time. The value gives information
about the total congestion time in a measurement period. The time measurement is started when all
SDCCHs are occupied (last free is just seized) and stopped when the first TCH is released and marked as
free. The unit of the value is 10 ms.
11. AVE_SDCCH_HOLD_TIM : This counter refers to the average SDCCH holding time. The unit of the
value is 10 ms.
12. AVE_TCH_HOLD_TIM : This counter refers to the average TCH holding time. The unit of the value is 10
ms.
10.1.7 Handover causes
The following counters refer to the cause that triggers the handover algorithm to start the handover procedure,
after receiving the measurement data and checking the appropriate thresholds and HO margins of the source and
candidate target cells. In this document appear the most typical of the 40 possible handover causes. The counters
do not provide information about the success of the procedure; they just count the attempts. They are also very
useful in pinpointing problems of radio coverage (signal strength and quality), interference and inadequately
defined neighbors, especially in a BSC’s “borderline”.
As far as the procedure is concerned, each counter is triggered when a Handover Required message, containing
the respective cause, is routed from the BSC to the MSC (inter-BSC handover). When the handover is internal

(intra-cell or inter-cell, intra-BSC handover), the procedure (decision and execution, respective cause counted) is
undertaken by the responsible BSC and the MSC is informed by a Handover Performed message.
1. CAUSE_UP_QUAL : The number of HO attempts due to uplink quality
2. CAUSE_UP_LEVEL : The number of HO attempts due to uplink level
3. CAUSE_DOWN_QUAL : The number of HO attempts due to downlink quality
4. CAUSE_DOWN_LEV : The number of HO attempts due to downlink level
5. CAUSE_DISTANCE : The number of HO attempts due to distance
6. CAUSE_UP_QUAL : The number of HO attempts due to response to MSC invocation
7. CAUSE_INTFER_UP: The number of HO attempts due to high interference on uplink
8. CAUSE_INTFER_DWN : The number of HO attempts due to high interference on downlink
9. CAUSE_UMBR : The number of umbrella HO attempts
10. CAUSE_PBDGT : The number of power budget HO attempts
11. CAUSE_OMC : The number of HO attempts started by O&M
12. CAUSE_CH_ADM : The number of HO attempts started by channel administrator (outgoing)
13. CAUSE_DIR_RETRY : The number of directed retry HO attempts
14. CAUSE_PRE_EMPTION : The number of HO attempts due to pre-emption
15. CAUSE_FIELD_DROP : The number of HO attempts due to rapid field drop
16. CAUSE_LOW_DISTANCE : The number of HO attempts due to low distance
17. CAUSE_BAD_CI : The number of HO attempts due to bad C/I ratio on super-reuse frequency
18. CAUSE_GOOD_CI : The number of HO attempts due to good C/I ratio on super-reuse frequency
10.1.8 Basic handover counters
The following counters provide information that can be used in statistically analyzing handovers from different
points of view. To be more specific, it is possible to measure attempts and successful HOs, which leads to
success rate. Moreover, the nature of the handover can be retrieved, meaning whether the HO is MSC-controlled,
BSC-controlled or intra-cell handover. Last, but not least, an in-depth analysis is possible on channel transaction
(SDCCH>SDCCH, SDCCH>TCH, TCH>TCH) that takes place during the procedure. The most intriguing
aspect of these counters is the fact that they combine part of or all the above characteristics; in that way,
monitoring of the usage of different network entities in HO procedure is possible.
The procedure depends on whether the handover is internal (intra-cell or inter-cell, BSC-controlled) or external
(MSC-controlled). This decision is made by checking the Handover Type Determination field in the
Measurement Result message sent to the BSC. It contains certain parameters that define the type of the HO
started. Then a candidate cell list is generated by the BSC, depending on the type of the handover.
If the handover is controlled by the MSC, then the Handover Required message informs about the cause of the
handover and the candidate target cells; the Handover Request message informs about the channel type and

transaction and, finally, the Channel Activation message confirms the channel transaction type, thus triggering
the respective counter.
If the HO is BSC-controlled, then the procedure is undertaken all the way by the BSC (the counters are triggered
in this procedure) and the MSC is informed by a Handover Performed message.
1. MSC_I_SUCC_HO : The number of successful MSC-controlled incoming handovers. This counter is

augmented when the HO (SDCCH>SDCCH, SDCCH>TCH or TCH>TCH) is completed. The counter is
triggered when the Handover Complete message is received by the MSC.
2. MSC_O_SUCC_HO : The number of successful MSC-controlled outgoing handovers. This counter is

triggered when the Handover Complete message is received by the MSC.
3. BSC_I_SUCC_HO : The number of successful BSC-controlled incoming handovers. This counter is

triggered when the Handover Complete message is received by the BSC. Then a Handover Performed
message is sent to the MSC.
4. BSC_O_SUCC_HO : The number of successful BSC-controlled outgoing handovers. This counter is

triggered when the Handover Complete message is received by the BSC. Then a Handover Performed
5. CELL_SUCC_HO : The number of successful BSC-controlled, intra-cell handovers. This counter is

augmented when the assignment (SDCCH>SDCCH, SDCCH>TCH or TCH>TCH) is completed. The
counter is triggered when the Assignment Complete message is received by the BTS, which forwards the
message to the BSC, as a Handover Complete message. Then a Handover Performed message is sent to the
MSC.
6. MSC_I(or O)_TCH_TCH : The number of successful TCH>TCH handovers (MSC-controlled incoming

(or outgoing) handovers). This counter is augmented when the TCH>TCH HO is completed. The counter is
triggered when the Handover Complete message is received by the MSC, after the channel transaction
(TCH>TCH) is confirmed.
7. MSC_I(or O)_SDCCH_TCH : The number of successful SDCCH>TCH handovers (MSC-controlled

incoming (or outgoing) handovers). This counter is augmented when the directed retry procedure is
completed. The counter is triggered when the Handover Complete message is received by the MSC, after the
channel transaction (SDCCH>TCH) is confirmed.
8. MSC_I(or O)_SDCCH : The number of successful SDCCH>SDCCH handovers (MSC-controlled

incoming (or outgoing) handovers). This counter is augmented when the SDCCH>SDCCH HO is
completed. The counter is triggered when the Handover Complete message is received by the MSC, after the
channel transaction (TCH>TCH) is confirmed.
9. MSC_I(or O)_TCH_TCH_AT : The number of TCH>TCH handover attempts (MSC-controlled incoming

(or outgoing) handovers). This counter is augmented when the TCH>TCH HO is started. The counter is
triggered after the Handover Required message is received by the MSC, when the channel transaction
(TCH>TCH) is confirmed.
10. MSC_I(or O)_SDCCH_TCH_AT : The number of SDCCH>TCH handover attempts (MSC-controlled

incoming (or outgoing) handovers). This counter is augmented when the directed retry procedure is started.
The counter is triggered after the Handover Required message is received by the MSC, when the channel
transaction (SDCCH>TCH) is confirmed.
11. MSC_I(or O)_SDCCH_AT : The number of SDCCH>SDCCH handover attempts (MSC-controlled

incoming (or outgoing) handovers). This counter is augmented when the SDCCH>SDCCH HO is started.

The counter is triggered after the Handover Required message is received by the MSC, when the channel
transaction (SDCCH>SDCCH) is confirmed.
12. BSC_I(or O)_TCH_TCH : The number of successful TCH>TCH handovers (BSC-controlled incoming (or
outgoing) handovers). This counter is augmented when the TCH>TCH HO is completed. The counter is
triggered when the Handover Complete message is received by the BSC, after the channel transaction
(TCH>TCH) is confirmed. Then a Handover Performed message is sent to the MSC.
13. BSC_I(or O)_SDCCH_TCH : The number of successful SDCCH>TCH handovers (BSC-controlled

incoming (or outgoing) handovers). This counter is augmented when the directed retry procedure is
completed. The counter is triggered when the Handover Complete message is received by the BSC, after the
channel transaction (SDCCH>TCH) is confirmed. Then a Handover Performed message is sent to the MSC.
14. BSC_I(or O)_SDCCH : The number of successful SDCCH>SDCCH handovers (BSC-controlled incoming
(or outgoing) handovers). This counter is augmented when the SDCCH>SDCCH HO is completed. The
counter is triggered when the Handover Complete message is received by the BSC, after the channel
transaction (SDCCH>SDCCH) is confirmed. Then a Handover Performed message is sent to the MSC.
15. BSC_I(or O)_TCH_TCH_AT : The number of TCH>TCH handover attempts (BSC-controlled incoming
(or outgoing) handovers). This counter is augmented when the TCH>TCH HO is started. The counter is
triggered when the Handover Decision is made by the BSC, after the channel transaction (TCH>TCH) is
confirmed.
16. BSC_I(or O)_SDCCH_TCH_AT : The number of SDCCH>TCH handover attempts (BSC-controlled

incoming (or outgoing) handovers). This counter is augmented when the directed retry procedure is started.
The counter is triggered when the Handover Decision is made by the BSC, after the channel transaction
(SDCCH>TCH) is confirmed.
17. BSC_I(or O)_SDCCH_AT : The number of SDCCH>SDCCH handover attempts (BSC-controlled

incoming (or outgoing) handovers). This counter is augmented when the SDCCH>SDCCH HO is started.
The counter is triggered when the Handover Decision is made by the BSC, after the channel transaction
(SDCCH>SDCCH) is confirmed.
18. CELL_TCH_TCH : The number of successful TCH>TCH handovers (BSC-controlled, intra-cell

handovers). This counter is augmented when the TCH>TCH HO is completed. The counter is triggered
when the Handover Complete message is received by the BSC, after the channel transaction (TCH>TCH) is
confirmed. The definition of the intra-cell nature is made by the Assignment Complete message sent to the
BTS, which then forwards it to the BSC as a Handover Complete message. Finally, a Handover Performed
19. CELL_SDCCH_TCH : The number of successful SDCCH>TCH handovers (BSC-controlled, intra-cell

handovers). This counter is augmented when the directed retry procedure is completed. The counter is
(SDCCH>TCH) is confirmed. The definition of the intra-cell nature is made by the Assignment Complete
message sent to the BTS, which then forwards it to the BSC as a Handover Complete message. Finally, a
Handover Performed message is sent to the MSC.
20. CELL_SDCCH : The number of successful SDCCH>SDCCH handovers (BSC-controlled, intra-cell

handovers). This counter is augmented when the SDCCH>SDCCH HO is completed. The counter is
(SDCCH>SDCCH) is confirmed. The definition of the intra-cell nature is made by the Assignment
Complete message sent to the BTS, which then forwards it to the BSC as a Handover Complete message.
Finally, a Handover Performed message is sent to the MSC.
21. CELL_TCH_TCH_AT : The number of TCH>TCH handover attempts (BSC-controlled, intra-cell

handovers). This counter is augmented when the TCH>TCH HO is started. The counter is triggered when
the Handover Decision is made by the BSC, after the channel transaction (TCH>TCH) is confirmed.

22. CELL_SDCCH_TCH_AT : The number of SDCCH>TCH handover attempts (BSC-controlled, intra-cell

handovers). This counter is augmented when the directed retry procedure is started. The counter is triggered
when the Handover Decision is made by the BSC, after the channel transaction (SDCCH>TCH) is
confirmed.
23. CELL_SDCCH_AT : The number of SDCCH>SDCCH handover attempts (BSC-controlled, intra-cell

handovers). This counter is augmented when the SDCCH>SDCCH HO is started. The counter is triggered
when the Handover Decision is made by the BSC, after the channel transaction (SDCCH>SDCCH) is
confirmed.

10.2 Calculation of success/failure rates

Given their description and critical information about them, the above counters can be used in certain forms that
estimate very important statistical items, based on BSC measurements. These items, such as blocked rate,
success rate, congestion, traffic etc., can be used to get a first impression for the network’s performance and
trigger a procedure for its optimization.
1. BLOCKED SDCCH RATE
SBA
SBL = * 100 (%)
SSA
SBL: SDCCH BLOCKING
SBA: SDCCH_BUSY_ATT
SSA: SDCCH_SEIZ_ATT
2. SDCCH CONGESTION
SCT
SCONG = (sec)
100
SCONG: SDCCH CONGESTION
SCT: SDCCH_CONG_TIME
3. AVERAGE NUMBER OF BUSY SDCCH
ABS = ABSD (number of channels)

ABS: AVERAGE BUSY SDCCH CHANNELS
ABSD: AVE_BUSY_SDCCH
4. AVERAGE NUMBER OF AVAILABLE SDCCH
AAS = ASS (number of channels)

AAS: AVERAGE AVAILABLE SDCCH CHANNELS
ASS: AVE_SDCCH_SUB
5. TCH BLOCKING
TRRL
TBL = * 100 (%)
TR
TBL: TCH BLOCKING
TRRL: TCH_REQ_REJ_LACK
TR: TCH_REQUEST
6. TCH CONGESTION
TCT
TCONG = (sec)
100
TCONG: TCH CONGESTION

TCT: TCH_CONG_TIME
7. TRAFFIC
TRAF = ABT (Erlang)

TRAF: TRAFFIC
ABT: AVE_BUSY_TCH
8. AVERAGE TCH HOLDING TIME
ATHT
AHT = (sec), BTS level
100
AHT: AVERAGE HOLDING TIME
ATHT: AVE_TCH_HOLD_TIM
The same form applies to the SDCCH if the counter AVE_TCH_HOLD_TIM is replaced by the
AVE_SDCCH_HOLD_TIM.
9. CALL SETUP SUCCESS RATE
TNS
CSSR = * 100 (%)
SST + SSO + SCRE − SSSE − USSE
CSSR: CALL SETUP SUCCESS RATE (Ghost accesses are not taken into account)
TNS: TCH_NORM_SEIZ
SST: SUCC_SEIZ_TERM
SSO: SUCC_SEIZ_ORIG
SCRE: SDCCH_CALL_RE_EST
SSSE: SUCC_SDCCH_SMS_EST
USSE: UNSUCC_SDCCH_SMS_EST
10. OVERALL HANDOVER SUCCESS RATE
SUCC _ HO
HOSR = * 100 (%), BTS level
MIO + BIO + CA
HOSR: HANDOVER SUCCESS RATE
MIO: MITTA+MISTA+MISA+MOTTA+MOSTA+MOSA
BIO: BITTA+BISTA+BISA+BOTTA+BOSTA+BOSA
CA: CTTA+CSTA+CSA
SUCC_HO: MISH+MOSH+BISH+BOSH+CSH
MISH: MSC_I_SUCC_HO
MOSH: MSC_O_SUCC_HO
BISH: BSC_I_SUCC_HO
BOSH: BSC_O_SUCC_HO
CSH: CELL_SUCC_HO
MITTA: MSC_I_TCH_TCH_AT
MISTA: MSC_I_SDCCH_TCH_AT
MISA: MSC_I_SDCCH_AT
MOTTA: MSC_O_TCH_TCH_AT

MOSTA: MSC_O_SDCCH_TCH_AT
MOSA: MSC_O_SDCCH_AT
BOTTA: BSC_O_TCH_TCH_AT
BOSTA: BSC_O_SDCCH_TCH_AT
BOSA: BSC_O_SDCCH_AT
BITTA: BSC_I_TCH_TCH_AT
BISTA: BSC_I_SDCCH_TCH_AT
BISA: BSC_I_SDCCH_AT
CTTA: CELL_TCH_TCH_AT
CSTA: CELL_SDCCH_TCH_AT
CSA: CELL_SDCCH_AT
11. HANDOVER SUCCESS RATE FOR BSC-CONTROLLED HANDOVERS
BISH + BOSH + CSH

HOSRBSC − CONTROL = *100 (%)
BIO + CA
12. HANDOVER SUCCESS RATE FOR MSC-CONTROLLED HANDOVERS
MISH + MOSH
HOSRMSC − CONTROL = *100 (%)
MIO
13. BLOCKED CALLS
BLOCKED _ CALLS = TCR − TNS − MOST − BOST (number of calls)
TCR: TCH_CALL_REQ
TNS: TCH_NORM_SEIZ
MOST: MSC_O_SDCCH_TCH
BOST: BSC_O_SDCCH_TCH
Successful outgoing handovers (directed retry procedure only) are taken into account for this form as they are
included in the call setup procedure, thus influencing the number of blocked calls.
14. BLOCKED HANDOVERS
BLOCKED _ HO = TR − TCR − THS (number of handovers)
TR: TCH_REQUEST
TCR: TCH_CALL_REQ
THS: TCH_HO_SEIZ

11 APPENDIX 2: NETWORK SIMULATOR STRUCTURE

The use of a simulator aims to provide a better understanding in the evaluation of the management techniques.
Further than the current research of these techniques, examples have to be implemented so that the comparison
of the techniques should take place, with results that show before and after the applied technique.
11.1 Parameters
The simulator is based on Microsoft Excel with the use of Visual Basic. The main reason for this selection was
the need of a very simple simulator, where the reprogramming of the models is easy, without considering the
speed. The program has been divided into 5 sheets. The first one is the “Cell Capacity”, where all the existing
different cell configuration are shown with tables of calculation that take place (described is ‘traffic density’), the
second one is the “Traffic Density” where most of the formulas are implemented in this section and the results
are calculated. The third one is the “Scenarios”, which characterizes the mobility of the users of the network.
Next one is the “techniques” where some parameters from the “traffic density” scheme are changed according to
the applied management technique. Last one is the “Results”, as the outcome from the calculation of the “traffic
density”.
11.2 Cell capacity

Three different cell capacity configurations have been implemented to serve the purposes of the simulator.
Generally, even if each BTS is configured with three cells, the simulator calculates only up to cell stage. The
three cell capacity configurations are:
• Low capacity configuration, with 7 TCHs and 4 SDCCHs in each cell,

• Medium capacity configuration, with 15 TCHs and 4 SDCCHs in each cell,
• High capacity configuration, with 23 TCHs and 16 SDCCHs in each cell.
This can be shown in the first sheet of the excel file, “Cell Capacity”.
11.3 Traffic density

Starting with the numbers of users in the network, are defined from the inverse normal distribution equation. By
setting the mean value and the standard deviation and also having a random number generated for the probability
the total number of users accessing the network is calculated. The users of the network are divided into Mobile
Originating Calls (MOCs) users, Mobile Terminating Calls (MTCs) users, SMS users and location Update users.
In the same way – with mean values, standard deviation and random number for the probability – the number of
minutes per call per subscriber is defined as well as the calls per hour per user.
Moreover, by dividing the number of minutes per call per user over 60 the result is the produced Erlangs per
subscriber per call. In addition, multiplying the result with the total number of calls per hour per user then the
result is the traffic density produced by each subscriber in Erlangs. The total for all the users MOCs, is calculated
by multiplying the found traffic density by the total number of users (Traffic Channel usage).
It has been found that the ration of MOCs over MTCs is 6/4 therefore the produced Erlangs can easily be found
also for the MTCs.
If the produced Erlangs from the MOCs:

Are less than 5 then duration for call assignment and for SMS is 4 seconds and 2 for location update,
Are more than 5 and less than 10 then call assignment and for SMS is 5 seconds and 2.5 for location update,
Are more than 10 then call assignment and for SMS is 6 seconds and 3 for location update.

The purpose is to calculate the SDCCH usage in Erlangs that is produced from the users. Therefore the equation
for the total number of Erlangs for SDCCH usage for MOCs is:
SDCCH_MOCs (Erlang) = Call duration * number of users * number of calls per hour per user / 3600,
For SMS:
SDCCH_SMS (Erlang) = SMS duration * number of users * number of SMS per hour per user / 3600,
For MTCs:
SDCCH_MTCs (Erlang) = (4/6) * SDCCH_MOCs
11.4 Periodic location update

The number of users that actually have done periodic location update within the defined period for the periodic
location update should not have at least one MTC or MOC or even one SMS otherwise the counter for the
Periodic Location update would have the reset. Therefore the given SDCCH is defined as:
SDCCH_LU (Erlang) = (1 - #calls_MOC)(1- #calls_MTC)(1-#SMS) * #users * LU_duration / 3600 *

Periodic_LU
Note, that LU_duration is in seconds and Periodic_LU is in every how many minutes a periodic location takes
place. In order to keep the balance between MTC, MOC, SMS and Periodic LU, if SDCCH_LU is less than zero,
then no periodic location updates takes place.
Consequently, the total TCH usage is found by adding the MOCs and MTCs TCH usage and the blocking
probability is calculated from the formula and the Erlang – B table from “Cell Capacity” sheet:
GOS_TCH = (TCH_usage)^(Available_TCH channels_in_Cell)/(Available_TCH channels_in_cell!)/

∑(TCH_usage)^(Available_TCH channels_in_Cell)/(Available_TCH channels_in_cell!)
Also by defining the network blocking and having number of TCH channels it is able to find the correspondence
TCH usage for the specific network blocking probability. Hence the Utilization is calculated from the equation:
Utilization_TCH = (1- GOS_TCH)*(TCH_Usage)/(TCH_Usage of % network blocking).
In the same way for the SDCCH usage:
GOS_SDCCH = (SDCCH_usage)^(Available_SDCCH channels_in_Cell)/(Available_SDCCH

channels_in_cell!)/ ∑(SDCCH_usage)^(Available_SDCCH channels_in_Cell)/(Available_SDCCH
channels_in_cell!)
Utilization_SDCCH = (1- GOS_SDCCH)*(SDCCH_Usage)/(SDCCH_Usage of % network blocking).
11.5 Scenarios
The simulation is over one day and the process has been divided into 24 hours. Within each hour there are 50
sub-processes, which are averaged to produce the results for that hour. Each sub-process takes the input for one
hour, that is:
Mean value and standard deviation of number of users

Mean value and standard deviation of number of minutes

Mean value and standard deviation of number of calls

Number of SMS, where the sum should not be more that 5.
Periodic Location Update (the same for the whole day)
Network Blocking Probability (Same for whole day), values are: 0.5-1-2-5
Number of SDCCH channels (For Cell configuration)
The last one has been added for easy implementation of the techniques within the simulator. More details will be
seen in the “Techniques” sheet.
Now each sub process takes these inputs for an hour and places them into the correspondence boxes in the
“Traffic Density” sheet. Generating 50 random numbers and each time the results for Calculated Blocking
Probability and Utilization are derived. As mentioned before these results are averaged and produce the desired
result for an hour of the calculated blocking probability and the utilization. Therefore total number of processes
is 24*50 = 1200.
11.6 Techniques
All the techniques are implemented in this section. Extra parameters are added to show the difference before and
after the implementation of each technique. For example with the Dynamic SDCCH technique the extra
SDCCH/8 channels are allocated which are added into the “Scenarios” sheet as a part of the new cell
configuration. At the same time one traffic channel is subtracted. With the same idea and goal, all the rest of the
techniques will be implemented.
11.7 Results
Finally the “Result” sheet where the calculated blocking probability and the Utilization for TCH and SDCCH are
saved in this section. The results are shown in a graphical presentation in the same sheet.
11.8 Further work

As stated before, all the techniques will be implemented in the “techniques” sheet with all the necessary extra
parameters. Except the SDCCH and the TCH usage within the network there are also others parameters that
result to network congestion, like the PCH channel for paging purposes and the AGCH. The goal is at least to
add the PCH usage is the “Traffic Density” sheet for a better approach to the network utilization.

12 APPENDIX 3: LOGICAL CHANNELS IN GSM NETWORKS
The radio interface (Um) is located between the mobile station (MS) and the rest of the GSM network. Physically
the information flow takes place between the mobile station and the base transceiver station (BTS). But, viewed
logically, the mobile stations are communicating with the base station controller (BSC) and the mobile switching
center (MSC).
12.1 Multiplex structure

Along with voice coding and modulation, multiplexing is also very important. In the GSM recommendations a
combination of frequency-division multiplexing (FDM) and time-division multiplexing (TDM) has been
standardized, providing multiple access by mobile stations to these systems (FDMA, TDMA).
12.2 Frequency-multiplexing structure

One of the most important in designing a radio interface was efficient utilization of the available frequency band.
In Europe two 25 MHz wide frequency bands in the 900 MHz band were reserved for GSM. Transmission from
the mobile unit to the base station (uplink) takes place in the 890 MHz to 915 MHz range. In the reverse
direction (downlink) the 935-960 MHz band is used in a frequency-division duplex (FDD) mode of operation.
The frequency bands are divided into 200 kHz bandwidth channels, therefore providing a total of 124 FDM
channels each for transmitting and receiving operations.
The respective 200 kHz bandwidth is kept as a guard band for the neighboring systems in the frequency band. If
the carrier frequencies on the uplink are denoted by Fu and those on the downlink as Fd then the GSM band can
be defined as:
Fu(n) = 890.2 MHz + 0.2(n-1) MHz (1 ≤ n ≤ 124)
Fd(n) = 935.2 MHz +0.2(n-1) MHz (1 ≤ n ≤ 124)
12.3 Time-multiplexing structure

With the TDM method a carrier frequency is divided into eight physical TDM channels in which the time axis is
divided into eight periodic time slots of 0.577 ms duration. Eight time slots are combined into a TDM frame of
4.615 ms duration. Because these time channels are used in multiple access, the frame is referred to as TDMA
frame in the GSM recommendations.
A physical channel is characterized by its carrier frequency and the time slot available to it, which recurs every
4.615 ms. Each time slot has a length corresponding to the duration of 156.25 bits or 0.577 ms (15/26 ms). A slot
is used by a burst with a length of 148 bits, which, corresponding to the guard time, is 8.25 bits shorter in
duration than the slots to avoid overlapping with other bursts. Data is transmitted in bursts. If messages are
longer than a burst, they are split up among several bursts and then transmitted.
Overall there are five types of bursts, which differ from one another in function and content.
• Normal burst: For transmitting messages in traffic and control channels.
• Access burst: Used for call setup. This burst is shorter than the others because it does not require the
MS to be fully synchronous with the BTS.
• Synchronization burst : Sent by the base station and used for synchronization.
• Frequency correction burst : Sent by the base station and used for frequency correction at the mobile
station to prevent possible interference from neighboring frequencies.
• Dummy burst : Placed in an empty slot if no data is being sent.

The TDMA frames from the uplink are transmitted with a delay of 3 time slots, in order to avoid the collision
with the respective TDMA frames from the downlink.
12.4 Frequency hopping

Since multipath reception and co-channel interference can affect the quality of certain FDM channels, an
optional method called frequency hopping is applied. With this method the frequency is changed after each
transmitted frame of a channel. The advance of this procedure is that all mobile subscribers are guaranteed
transmission channels with nearly the same quality.
12.5 Logical channels

Logical channels occur through the allocations of time slots by physical channels. Consequently the data of a
logical channel is transmitted in the corresponding time slots of the physical channel. Thus, logical channels can
occupy a part or even the entire of the physical channel.
The GSM recommendations define several logical channels, dividing them into two main groups: traffic
channels and control channels.
12.5.1 Traffic channels

Traffic channels (TCH) are logical channels over which user information are exchanged between mobile users
during a connection. Speech and data are digitally transmitted on these channels using different coding methods.
Different transmission capacities are required depending on the type of service used (e.g. voice transmission,
short-message service, data transfer, facsimile). A distinction is therefore made between the following traffic
channels:
• Bm-channel : Transmission over a Bm-channel (full-rate TCH), is carried out at a gross data rate of
22.8 kbps. However, only 13 kbps required for voice information. The remaining is used for error
correction. It is possible to transmit data at 12,6 or 3.6 kbps over a Bm-channel.
• Lm-channel : This channel (half-rate TCH) transmits at a gross rate of 11.4 kbps. The number of
channels in GSM can be doubled in a given frequency band because of the speech codes available
for half-rate channels. A Lm-channel allows data transmission at 6 or 3.6 kbps.
Traffic channel Abbreviation

Full-rate TCH for speech TCH/FS
Half-rate TCH for speech TCH/HS
9.6 kbps full-rate TCH for data TCH/F9.6
4.8 kbps full-rate TCH for data TCH/F4.8
4.8 kbps half-rate TCH for data TCH/H4.8
≤ 2.4 kbps full-rate TCH for data TCH/F2.4
≤ 2.4 kbps half-rate TCH for data TCH/H2.4
Cell broadcast channel CBCH
The table above lists the traffic channels specified in GSM recommendation
12.5.2 Control channels

Control information is used for signaling and for system control and is not passed down to the subscribers.
Typical signaling tasks include the signaling for establishing, maintaining and releasing traffic channels, for
mobility management and access control to radio channels.

Control information is transmitted over so-called control channels (CCH). This channels offer the mobile
stations a packet-oriented continuous signaling service enabling them within the PLMN to receive messages
from the base stations and to send messages to the base stations at any time.
Three groups of control channels were defined in GSM, because the control and management of a
mobile radio network is very complex:
• Broadcast control channel (BCCH)
• Common control channel (CCCH)
• Dedicated control channel (DCCH)
Table 55: Control channels in GSM
Direction Group Channel Channel identification

MS ← BS BCCH Broadcast Control Channel
MS ← BS BCCH FCCH Frequency Correction Channel
MS ← BS SCH Synchronization Channel
MS ← BS PCH Paging Channel
MS → BS CCCH RACH Random Access Channel
MS ← BS AGCH Access Grant Channel
MS ↔ BS SDCCH Stand-Alone Dedicated Control Channel
MS ↔ BS DCCH SACCH Slow Associated Control Channel
MS ↔ BS FACCH Fast Associated Control Channel
Broadcast Control Channel (BCCH) : This channel is used to transmit information about the PLMN from the
base station to the mobile stations in the radio cell through a point to multipoint connection. The kind of
information conveyed over a BCCH includes identification of the network, availability of certain options such as
frequency hopping and activity detection and identification of the frequencies being used by the base station and
neighboring base stations.
One of the subchannels of the BCCH is the frequency correction channel (FCCH), used for transmitting a
frequency correction burst to the mobile station for possible correction of the transmitting frequency.
Next subchannel is the synchronization channel (SCH) and used for transmitting synchronization bursts to a
mobile station to allow it to time-synchronize.
All messages over the BCCH group are transmitted exclusively in simplex mode by the base station to the
terminal equipment.
Common Control Channel (CCCH) : This term includes the control channels that handle the communication
between the network and the mobile phone. These channels are:
• Paging channel (PCH) : This channel exists only on the downlink, and is activated for the selective
addressing of a called mobile terminal during a connect request from the network (incoming call).
• Random access channel (RACH) : This access channel only occurs on the uplink, and allows the
mobile station, using an S-ALOHA access protocol, to request channel capacity from the base station to
establish a connection.
• Access grant channel (AGCH) : This logical channel is used from the base station to respond to a
message received over the RACH from the mobile station and exists only on the downlink.
Dedicated control channel (DCCH) : This designation is an umbrella term for three bi-directional point to
point control channels that are used to transmit signaling messages for call control at different bit rates. The three
DCCH channels are:
• Stand-alone dedicated control channel (SDCCH) : This channel is always used when a traffic
channel has not been assigned, and is allocated to a mobile station only as long as control information is
being transmitted. The SDCCH capacity is 782 bps. Control information transmitted on the SDCCH
includes registration, authentication, location area updating and data for call setup.
• Slow associated dedicated control channel (SACCH) : This channel is always allocated parallel to a
TCH or an SDCCH. It is used to transmit at a data rate of 383 bps system information from the network

to the mobile station and measurement data on signal strength and receive quality from the MS to the
network.
• Fast associated dedicated control channel (FACCH) : This channel is set up in the short term only
when a traffic channel exists and then it uses its time slots. For example, an FACCH is set up for an
impending handover and the necessary control data is transmitted over the FACCH. It can handle bit
rates of 4600 bps or 9200 bps.
12.6 Hierarchy of frame structures

In GSM the TDMA frames, which contain eight time slots for transmitting bursts, are combined into
multiframes. There are two multiframes with different lengths:
• 26-frame multiframes
• 51-frame multiframe
The bursts of the traffic channels (TCH) and the SACCHs and FACCHs assigned to them are transmitted in 26-
frame multiframes. Each traffic channel is allocated 1 of 8 (with half-rate transmission, 16) time slots of a
TDMA frame. The associated 8 SACCHs are transmitted in the 12th TDMA frame. The last TDMA frame (25)
of the 26-frame multiframes is only used if another 8 SACCHs are required for half-rate transmission. Time
slots are stolen from the TCHs for the transmission of the FACCHs.
The data of the FCCH, SCH, BCCH, RACH, AGCH, PCH, SDCCH, SACCH/C and CBCH channels is sent in
51-frame multiframes. It was generally specified that speech and data would be transmitted in 26-frame
multiframes and signaling data (except for SACCH/T and FACCH) in 51-frame multiframes.
51 of the 26-frame multiframes and 26 of the 51-frame multiframes are combined into a superframe, and 2048
superframes produce a hyperframe.
12.7 Combinations of logical channels

Logical channels are mapped onto a physical channel through a process of cyclically recurring multiframe
patterns. The correct positioning time wise of the cycles is achieved through synchronization of BTS and MS.
The BSS provides a reference counter in each cell that is used to number the time slots and serves as the
mapping scheme for the multiframes. In GSM each time slot is clearly identified of a special number. Because of
a frame structure encompassing several levels, the counter for the TDMA frame numbers can go as high as
2715648.
12.7.1 Approved channel combinations

Logical channels follow a particular pattern in distribution. The following is a set of approved channel
combinations (CC), represented by their multiframes:
CC1: TCH/F + FACCH/F + SACCH/TF

CC2: TCH/H(0,1) + FACCH/H(0,1) + SACCH/TH(0,1)
CC3: TCH/H(0) + FACCH/H(0) + SACCH/TH(0) + TCH/H(1)
CC4: FCCH + SCH + BCCH + CCCH
CC5: FCCH + SCH + BCCH + CCCH + SDCCH/4(0,1,2,3) +
SACCH/C4(0,1,2,3)
CC6: BCCH + CCCH
CC7: SDCCH/8 + SACCH/8

A physical channel contains only one of these combinations. The numbers in brackets after the logical channels
give the numbers of the logical subchannels. This means that in the case of SDCCH/4 there are 4 SDCCHs on a
physical channel, each of which is used by one mobile station.
Although the mapping of combinations of logical channels onto a physical channel may mean that several
logical channels can appear on one physical channel, they occur sequentially at intervals of at least one TDMA
frame length. The described channel combinations are not allowed to occupy just any random time slots or
frequencies.
12.7.2 Channel combinations of a cell Depending on anticipated cell utilization

The BSS provides a cell with a set of logical channels occupying several physical channels. On the basis of the
anticipated traffic load of a cell, the network operator establishes a channel configuration that must adhere to the
rules mentioned in the last section. Each individual transceiver (TRX) can offer eight channel combinations in
each time slot. The time slot is identified through a time slot number (TN). Three common combinations are
briefly presented here:
• Low-capacity cell with one TRX:
- TN 0: FCCH + SCH + BCCH + CCCH + SDCCH/4(0,1,2,3)
+ SACCH/C4(0,1,2,3)
- TN 1 to 7: TCH/F + FACCH/F + SACCH/TF
• Medium-capacity cell with four TRXs:

- Once on TN 0: FCCH + SCH + BCCH + CCCH
- Twice (on TN 2 and TN 4): SDCCH/8 + SACCH/8
- 29 times: TCH/F + FACCH/F + SACCH/TF
• High-capacity cell with 12 TRXs:

- Once on TN 0: FCCH + SCH + BCCH + CCCH
- Once on TN 2: BCCH + CCCH
- 5 times: SDCCH/8 + SACCH/8
- 87 times: TCH/F + FACCH/F + SACCH/TF
After successful synchronization, the mobile station is informed through the system information of the BCCH
which channel combinations on which physical channels are being offered to it by the BSS. Depending on its
current operating state (idle state or dedicated state), it uses a particular subset from this offering of channels.
The BCCH always appears together with SCH and FCCH and that it can always be found in time slot 0. This
condition helps to facilitate synchronization when an MS makes its first contact with a BTS. Additional
combinations 6 are added when traffic is expected to be heavy.

13 APPENDIX 4: TRAFFICA NETWORK
13.1 Traffica network

The whole GSM network can be covered with interconnected Trafficas. There is one Traffica server connected
to each MSC. These are called Lower Level Trafficas (LLT). In addition to these, there can be Upper Level
Trafficas (ULT), which are connected to Lower Level Trafficas. From Upper Level Trafficas, it is possible, for
example, to view graphs located in the lower level. This allows the operator to have an overview of the traffic in
the whole network from one single Traffica. Also, in the upper level it is possible to see the alarms generated by
the LLTs, to access the databases in the LLTs and to remotely configure the LLTs. The eight elements connected
with Traffica are:
1. Traffica database. There is a separate database for each Lower Level Traffica. You can collect parts of the
data in the Lower Level Traffica databases and combine them in an Upper Level Traffica database. By
default, the structure of the database is identical for each Traffica.
2. Traffic News. It is a database browser you can use for creating comprehensive Traffic News reports of the
collected traffic data, and for making queries in the database. Traffic News is designed for voice and data
calls.
3. SMS News. It is a similar database browser and reporting tool for short messages as Traffic News is for voice
and data calls.
4. Traffic Reporter. It forwards measurements to Network Data Warehouse (NDW).
5. NDW
6. Traffic Simulator. It enables you to simulate actual traffic, for example, for educational or alarm planning
purposes.
7. Ntalfo. It forwards alarms to the NMS.
8. NMS
The technical personnel at the operator's site can use Traffica for the following tasks:
• To observe the network performance in freely user-definable time resolutions.
• To observe the effects of the software change notes or parameter changes in real-time.
• To verify that recently installed elements deliver traffic as expected.
• To create alarms to indicate problems in traffic.
Customer Care and Service and Business Management can use the data collected by Traffica to analyze the
following:
• Subscriber behaviour. The average call duration, the destinations of calls.
• Competitors. The number and duration of the calls going to the competitor's network through your
MSCs.
• Roaming. The operators whose roamers are making calls in your network. The success rate and duration
of the calls.
• Manufacturer. The mobile equipment used in the network. The performance of the various
manufacturers' BSSs.
• Subscriber-specific call information.
Traffica monitors, for example, the following:

• Number of calls
• Setup failures
• Dropped calls
• Clear codes
• Average call durations
• Mobile equipment
• Roaming subscribers
• User-defined subscribers or subscriber groups
• International calls

• Paging time
• Data calls
• HSCSD (High Speed Circuit Switch Data)
• Selected information about IN (Intelligent Network) calls
• SMS (Short Message Service)
• Dual band
• Network entities (for example, LACs, BSCs and cells)
The basic Traffica functions are described in the following sections.
13.1.1 Data collecting and storing

Traffica collects RTT reports from the MSCs, extracts the defined data and updates the CCMA, and stores the
data in the Traffica database. Traffica updates the user-defined real-time graphs and alarms on the basis of the
received data contents.
If the Traffica-MSC connection is down, all the traffic data, which the MSC generates during the time the
connection is down, is lost.
When an RTT report is generated, Traffica converts the data in the RTT report and stores it in the IDS. From the
IDS, the Database function forwards the data into the Traffica database. The CCMA function uses the data in the
IDS to update the CCMA.
13.1.2 Graphs
The real-time graphs visualize the data collected in the CCMA. You can define the actual information shown in
the real-time graphs, and the data for the graphs is fetched from the CCMA. You can define the graph properties
in detail, from the more essential data and visual properties to minor details, such as, background coloring, line
width, and font size.
13.1.3 Alarms
It is possible for the users to define their own alarms. In addition to the user-definable alarms, there are a number
of Traffica internal alarms. Only a Traffica user with administrator rights can enable or disable internal alarms. If
the alarm severity is Info, the alarm is not forwarded to the NMS. If you want to forward an alarm to the NMS,
the alarm number must be within the range 19000-19099. The number range 19800-19899 is reserved for
internal alarms. You can define three types of alarms: Limit alarms, Delta threshold alarms, and Burst alarms.
13.1.4 Limit alarms
An alarm is triggered when a predefined Limit threshold has been reached.
13.1.5 Delta threshold alarms
The counter values between two successive time slices is compared, and when the difference between two time
slices reaches the Delta threshold value, an alarm is triggered. Notice that you can create alarms only for positive
growth.

13.1.6 Burst alarms
Short bursts in counter changes between successive time slices are observed, and an alarm is triggered when the
Burst threshold has been reached.
13.1.7 Redirecting RTT reports to an upper level Traffica

It is possible to redirect RTT reports from one or several Lower Level Trafficas to an Upper Level Traffica. You
can define the reports to be redirected and use this procedure for various purposes, for example, to collect all
data call reports to one Upper Level Traffica.
When redirecting RTT reports to an Upper Level Traffica, the UDP/IP protocol is used. However, the UDP/IP
protocol is not completely reliable and it is possible that redirected reports are lost. When you define the
redirecting rules keep in mind that the redirecting process creates LAN load.
13.1.8 Links between real-time graphs

You can set links between the real-time graphs presenting the measurement data. For example, one graph can
show the number of calls in each cell. When you click a bar that presents a cell, the linked graph shows in the
form of clear codes how the traffic is succeeding or failing. When you select another cell, the linked graph is
updated and shows the clear codes for the selected cell Links between real-time graphs.
You can set links between the real-time graphs presenting the measurement data. For example, one graph can
show the number of calls in each cell. When you click a bar that presents a cell, the linked graph shows in the
form of clear codes how the traffic is succeeding or failing. When you select another cell, the linked graph is
updated and shows the clear codes for the selected cell.
13.1.9 Remote management functions
You can remotely manage Lower Level Trafficas from an Upper Level Traffica. The remote management
function enables you to deliver Traffica workspace files, or selected parts of them. You can also remotely start,
stop, or change the priorities of the Traffica functions, define the Lower Level Trafficas to send reports to the
upper level, and remotely perform Traffica software upgrades.
13.2 Traffica network architecture

The Traffica hierarchy consists of Lower Level Trafficas and Upper Level Trafficas. The lowest level in the
hierarchy is the Traffica server that is connected to an MSC with a dedicated LAN. These Lower Level Trafficas
collect traffic data. Lower Level Trafficas can be unmanned and they can be remotely observed from an Upper
Level Traffica. Lower Level Trafficas communicate with, and forward data to, an Upper Level Traffica through
the operator's LAN/WAN. An Upper Level Traffica is logically at the same level as the NMS. One of the Lower
Level Trafficas can be converted into an Upper Level Traffica for another Lower Level Traffica. The Lower
Level Trafficas are connected to three elements: the MSC, an ULT and NMS/2000. Traffica network can be
organized in a variety of ways. Because Traffica hierarchy is dynamic, it can be built to meet the needs at the
operator's site. For this reason, the actual number and placement of Trafficas in the network remains an operator-
specific issue. You can perform nearly all functions in all Traffica levels. You can create, for example, counters,
alarms, graphs, and redirection rules in any Traffica level. In practice, it is useful to monitor, for example, alarms
centrally in the upper level. It is also practical to create the counters, alarms, graphs, and redirection rules in an
Upper Level Traffica and send them to the Lower Level Trafficas.

13.2.1 Traffic News

Traffic News is a database browser and a reporting tool. Traffic News uses the database written by Traffica.
You can use Traffic News to carry out the following:
• Browse the RTT reports in the database
• Make queries in the database
• After you have made a query in the database, you can select the fields which you want to have in a
specified file
• Generate a comprehensive Traffic News report from the collected traffic data.
13.2.2 SMS News

SMS (Short Message Service) News is a similar database browser and reporting tool for short messages as
Traffic News is for voice and data calls.
13.2.3 Traffic Reporter

Traffic Reporter generates daily certain measurements from the Traffica database and forwards them to
NDW.
13.2.4 Clear Code Matrix

The CCMA (Clear Code Matrix) is a user-definable counter tree and functions as the Traffica data storage.
Currently, you can define the structure and contents of the CCMA but if you want to see the actual counter
values you should create real-time graphs, which show the values.
The Clear Code Matrix is the basis for creating real-time graphs and alarms. You can control the data collected
to the CCMA with user-defined formulas and you can define freely the time resolutions over the data. As an
example, the time resolutions can be one second, one minute, or one day. Certain data can be presented with one-
minute bars or the data can be collected from the beginning of the day and at the end of the day you can observe,
for example, how many calls there were in a certain MSC during that day. After defining the time resolutions
you can select the data to be collected under each time resolution.
There are three member types in the CCMA tree view. The hierarchy is as follows:
• Time Class is the root item in the CCMA tree. Time Class icons are displayed in yellow.
• There are four node member types: Expression, Group, Presence, and Vector. The node member icons
are displayed in blue.
• There are three leaf member types: Addition, Counter, and Move. The leaf members are the actual data
storage in the CCMA and their icons are displayed in red.
Every time a new RTT report arrives the CCMA is updated. The Time Classes and the nodes and leaves under
them are updated one by one. Each node member contains a reference to one or several IDS fields which are
mapped with the corresponding fields in an RTT report. Each node member, except for a Vector, also includes a
condition which can be evaluated true or false. If the node condition is evaluated true, the updating of the subtree
under the node is continued. However, if the condition is evaluated false, the updating of the node is discarded
and the following node which has not yet been updated is inspected to find out whether the condition for that
node is evaluated true or false.
13.2.5 Time Class

When you create a new tree view in the CCMA, Time Class is the root item in the tree view. In the Time Class
you define the time properties for the data to be collected in the tree view. The CCMA consists of either one or

several Time Classes and a Time Class consists of one or several time resolutions. For the Time Class you define
the time resolution by giving the duration of one time slice interval. You also define the number of time slices
which are stored in the memory as historical data.
13.2.6 Expression
Expression is a node member in the CCMA tree view. The Expression type of a node is intended for general use.
The Group and Presence types are special cases of the Expression type. For Expressions you can use C
programming language style expressions. In the Expression, you can use IDS field names, operators, and digits.
The condition for Expression is evaluated true if the value for Expression equals to or is bigger than (=>) 1, and
the condition is evaluated false if the value equals to (==) 0.
13.2.7 Group
Group is a node member in the CCMA tree view. The Group member is useful when you want to monitor, for
example, one or several subscribers, mobile equipment types, roaming subscribers, cells, or BSCs. Monitoring
calls to a certain area code or country code are also possible.
Group is associated with only one IDS field. The condition for Group consists of a list of single values, a list of
value ranges, or of a list which is a combination of both of these. The condition is evaluated true if the field in
the RTT report, to which Group refers to, contains the value listed in the Group member. The condition is
evaluated false if the field does not contain a listed value.
13.2.8 Presence
Presence is a node member in the CCMA tree view. Use the Presence type when you want to see whether a
specified field has a value in the RTT report or whether the value is an empty value. Usually, Presence is
associated with one IDS field but it can also be associated with several IDS fields. If Presence is associated with
one IDS field, the Presence condition is evaluated true when the value for that IDS field exists in the RTT report.
If Presence is associated with several IDS fields, the Presence condition is evaluated true when there are values
in the RTT report for all the IDS fields defined in Presence. If this is not the case, the condition is evaluated
false.
13.2.9 Vector
Vector is a node member in the CCMA tree view. Usually, a Vector is associated with one IDS field but it can
also be associated with several IDS fields.
Vector is a versatile node type. Use Vector when you want to see in one graph all the values in a certain field in
an RTT report. Use Vector also when you want to create one alarm which applies to all, for example, MSCs,
cells, or clear codes, and you want to see, in the Alarms window, the item which triggered the alarm. Also, when
you want to create links between graphs, use a Vector which has another Vector under it in the subtree structure.
13.2.10 Addition
Addition is a leaf member in the CCMA tree view. Addition can be placed only under an Expression node.
The starting value in Addition is 0. When a new RTT report comes, a value is calculated for the Expression, and
this value is added to the value in Addition.

You can use Addition, for example, when you want to know the average call duration. You have a Counter
which shows the number of all calls and, on the same level in the CCMA, an Expression which calculates the
call durations as seconds. The Addition leaf under Expression cumulates the call durations as seconds. When you
create a relative graph or an alarm, for the Data you insert the Addition and for the Relative Data you insert the
Counter, which means that the duration of all calls is divided by the number of all calls.
13.2.11 Counter
Counter is a leaf member in the CCMA tree view. A Counter can be added anywhere under a Time Class in the
CCMA. When a new RTT report comes and the CCMA is updated, the value in a Counter is increased by one.
The nodes control which Counter values are increased. When Traffica is started or the CCMA is reset, the
Counters are initialized.
13.2.12 Move
Move is a leaf member in the CCMA tree view. A Move member can be added anywhere under a Time Class in
the CCMA. You define an IDS field for the Move. An array type of an IDS field cannot be used.
The IDS field which is defined in the Move is searched from an RTT report and moved as such to be the value of
the Move member.

REFERENCES
[1] Thomas Neubauer, Thomas Baumgartner, Ernst Bonek. Required Network Size for System Simulation
in UMTS FDD Uplink. Sixth International Symposium on Spread Spectrum Techniques and
Applications, volume 2, pages 481–485, 2000.
[2] Muhammad Kazmi, Philippe Godlewski, Christophe Cordier. Admission Control Strategy and
Scheduling Algorithms for Downlink Packet Transmission in WCDMA. IEEE VTC Fall 2000,
volume 2, pages 674–680, 2000.
[3] Raymond Kwan, Mika Rinne. A Comparison of WCDMA Network Performance Results with Frame vs
Slot Resolution Simulations. The 5th CDMA International Conference & Exhibition (CIC 2000), pages
478–482, 2000.
[4] Thomas Klingenbrunn, Preben Mogensen. Modeling Radio Link Performance in UMTS W-CDMA
Network Simulations. IEEE VTC Spring 2000, volume 2, pages 1011–1015, 2000.
[5] Ahmad R. S. Bahai, Hamid Aghvami. Network Planning and Optimization in the Third Generation
Wireless Networks. First International Conference on 3G Mobile Communication Technologies, pages
441–445, 2000.
[6] David Lister, Shirin Dehghan, Ray Owen, Phil Jones. UMTS Capacity and Planning Issues. First
International Conference on 3G Mobile Communication Technologies, pages 218–223, 2000.
[7] M. Poza, M. Iracheta. On the Quest of a Better World Wide Web Traffic Model for UMTS. First
International Conference on 3G Mobile Communication Technologies, pages 456–460. 2000.
[8] Achim Wacker, Jaana Laiho-Steffens, Kari Sipilä, Kari Heiska. The Impact of the Base Station
Sectorisation on WCDMA Radio Network Performance. IEEE VTC Fall 1999, pages 2611–2615. 1999.
[9] H. Boujemaa, M. Siala. Optimisation of Interference Cost Generated by Random Access Channel of
UMTS FDD System. Electronics Letters, volume 37, number 1, January 2001.
[10] H. Holma, A. Toskala. WCDMA For UMTS; Radio Access For Third Generation Mobile
Communications. John Willey & Sons, Ltd. 2001.
[11] Christian Hartmann, Oliver Schlegelmilch. Hierarchical Cell Structures with Adaptive Radio Resource
Management. IEEE VTC Fall 2000, volume 4, pages 1764–1771, 2000.
[12] Jongin Kim, Youngnam Han, Jihwan Ahn. An Adaptive Traffic Control Scheme for Hierarchically
Structured CDMA Cellular Systems. IEEE VTC Fall 2000, volume 5, pages 2192–2196, 2000.
[13] M. Leo, M. Luglio. Performance Evaluation of Intersegment Handover Procedures in UMTS Scenario.
IEEE VTC Fall 2000, volume 4, pages 1930–1934, 2000.
[14] U. Bernhard, H. Pampel, J. Mueckenheim, P. Gunreben. Evaluation of W-CDMA Network
Performance and Impact of Soft Handover Using Dynamic Network Simulations. First International
Conference on 3G Mobile Communication Technologies, 2000.
[15] Xinjie Yang, Shahram Ghaheri-Niri, Rahim Tafazolli. Evaluation of Soft Handover Algorithms for
UMTS. 11th PIMRC 2000, volume 2, pages 772–776, 2000.
[16] Xinjie Yang, Shahram Ghaheri-Niri, Rahim Tafazolli. Enhanced Soft Handover Algorithms for UMTS
System. IEEE VTC Fall 2000, volume 4, pages 1539–1543, 2000.
[17] Nicola Binucci, Kimmo Hiltunen, Maurizio Caselli. Soft Handover Gain in WCDMA. IEEE VTC Fall
2000, volume 3, pages 1467–1472, 2000.
[18] M. Bozinovski, P. Popovski, L. Gavrilovska. Novel Strategy for Call Admission Control in Mobile
Cellular Network. IEEE VTC Fall 2000, volume 4, pages 1597–1602, 2000.
[19] K. Kim, Y. Han, C. Yim, K. Jeong. A Call Admission Algorithm with Optimal Power Allocation for
Multiple Class Traffic in CDMA Systems. IEEE VTC Fall 2000, volume 3, pages 1086–1093, 2000.
[20] N. Wiberg, A. Gioia. Uplink Packet Access Control in WCDMA. IEEE VTC Fall 2000, volume 3,
pages 2203–2206, 2000.
[21] Bjorn Hjelm. Admission Control in Future Multi-Service Wideband Direct-Sequence CDMA Systems.
IEEE VTC Fall 2000, volume 3, pages 1086–1093, 2000.
[22] Yeong M. Jang, Jeehwan Ahn. A Connection Admission Control Using Transient Outage Probability in
CDMA Systems. IEEE VTC Fall 2000, volume 3, pages 1412–1416, 2000.

[23] F. Santucci, W. Huang, P. Tranquilli, V. K. Bhargava. Admission Control in Wireless Systems with
Heterogeneous Traffic and Overlaid Cell Structure. IEEE VTC Fall 2000, volume 3, pages 1106–1113,
2000.
[24] Chung-Ju Chang, Scott Shen, Jiun-Hsiung Lin, Fang-Ching Ren. Intelligent Call Admission Control for
Differentiated QoS Provisioning in Wideband CDMA Cellular Systems. IEEE VTC Fall 2000,
volume 3, pages 1057–1063, 2000.
[25] Cristina Comaniciu, Narayan B. Mandayam, David Famolari, Prathima Agrawal. QoS Guarantees for
Third Generation (3G) CDMA Systems via Admission and Flow Control. IEEE VTC Fall 2000,
volume 1, pages 249–256, 2000.
[26] Nikos Dimitriou, Georgios Sfikas, Rahim Tafazolli. Call Admission Policies for UMTS. IEEE VTC
Spring 2000, volume 2, pages 1420–1424, 2000.
[27] C. Mihailescu, X. Lagrange, Pf. Godlewski. Radio Resource Management for Packet Transmission in
UMTS WCDMA System. IEEE VTC 1999. 1999.
[28] Andrea Fiorini. Uplink User Bitrate Adaptation for Packet Data Transmissions in WCDMA. The 11th
International Symposium on Personal, Indoor and Mobile Radio Communication, volume 2, pages
1510–1514. 2000.
[29] S. Nourizadeh, P. Taaghol, R. Tafazolli. A Novel Closed Loop Power Control for UMTS. First
International Conference on 3G Mobile Communication Technologies, Conference Publication No. 471,
pages 56–59. 2000.
[30] Gyung-Ho Hwang, Dong-Ho Cho. Dynamic Rate Control Based on Interference and Transmission
Power in 3GPP WCDMA System. IEEE VTC Fall 2000, volume 6, pages 2926–2931, 2000.
[31] Phil Jones, Ray Owen. Sensivity of UMTS FDD System Capacity and Coverage to Model Parameters.
First International Conference on 3G Mobile Communication Technologies, Conference Publication
No. 471, pages 224–229. 2000.
[32] A.Giovanardi, G.Mazzini, V.Tralli, M.Zorzi. On the Effect of Doppler Bandwidth, Network Load and
Power Control Threshold on the UMTS/FDD Radio Interface Performance. The 11th International
Symposium on Personal, Indoor and Mobile Radio Communication, volume 2, pages 1480–1484. 2000.
[33] H. Bento Pinto, J. Gaspar da Silva, A. Rodrigues. Uplink Capacity of the WCDMA FDD Mode in
UMTS Networks for Mixed Services. IEEE VTC Fall 2000, 52nd Vehicular Technology Conference,
volume 6, pages 2617–2624, 2000.
[34] Alessandro Pace, Luca Valentini. System Level Performance Evaluation of UTRA–FDD. The 11th
International Symposium on Personal, Indoor and Mobile Radio Communication, volume 1, pages 343–
347. 2000.
[35] Theodore S. Rappaport. Wireless Communications. 1996.
[36] Enrico Jugl, Holger Boche. Dwell Time Models for Wireless Communication Systems. IEEE VTC Fall
1999, vol. 5, pp. 2984–2988, 1999.
[37] Eun-Seon Cho, Go-Whan Jin, Cheol-Hye Cho. Comparisons of Mobility Models in Cellular Systems.
IEEE VTC Fall 1999, pp. 564–568, 1999.
[38] Takehiko Kobayashi, Noriteru Shinagawa, Yoneo Watanabe. Vehicle Mobility Characterization Based
on Measurements and Its Application to Cellular Communication Systems. IEICE Trans. Commun.,
vol. E82-B, no. 12, December 1999.
[39] J.G.Markoulidakis, G.L.Lyberopoulos, D.F.Tsirkas, E.D.Sykas. Mobility Modeling in Third Generation
Mobile Telecommunication Systems. EEEE Personal Communications, pp. 41--56, August 1997.
[40] Qinqing Zhang, Mooi-Choo Chuah, On-Ching Yue. Enhanced power ramping scheme for UMTS
random access channel. IEEE Vehicular Technology Conference Fall 1999, vol. 5, pp. 2631–2635,
1999.
[41] M. Chuah, Q. Zhang, O. Yue. Access Priority Schemes in UMTS MAC. Wireless Communications and
Networking Conference, vol. 2, pp. 781–786, 1999.
[42] 3rd Generation Partnership Project. 3G TS 25.214 V4.0.0: Physical layer procedures (FDD). 2001.
[43] Beom-Sik Bae, Dong-Ho Cho. Performance Analysis of Various CPCH Mechanisms in 3GPP System.
IEICE Trans. Commun., vol. E84-B, no. 3, pp. 464–473, March 2001.
[44] Kourosh Parsa. An Overview of Common Packet Channel (CPCH), an Optimum Wireless Internet
Mechanism in 3GPP W-CDMA System and Comparison of Various UMTS Non Real Time Data
Deployment Options. The 11th IEEE International Symposium on Personal, Indoor and Mobile Radio
Communications, vol. 1, pp. 388–395, 2000.
[45] Amitava Ghosh, Mark Cudak, Ken Felix. Shared Channels for Packet Data Transmission in W-CDMA.
IEEE VTC 1999 Fall, vol. 2, pp. 943–947, 1999.

[46] Yi-Pin Eric Wang, Tony Ottosson. Cell Search in W-CDMA. IEEE Journal on Selected Areas in
Communications, vol. 18, no. 8, August 2000.
[47] Kristian Ukkonen. Master's Thesis. Helsinki university of technology, 2001.
[48] G. Amdahl. Validity of the single-processor approach to achieving large-scale computer capabilities.
Proceedings of the AFIPS Conference, volume 30, pages 483-485, 1967.
[49] Catalyst 1900 series installation and configuration guide. Cisco Systems, Inc. 1998.
[50] Sisoft Sandra homepage. http://www.sisoftware.demon.co.uk/sandra/
[51] K. Zieliński, M. Gajęcki, G. Czajkowski. Parallel programming systems for LAN distributed
computing. IEEE Proceedings of the 14th international conference on distributed computing systems,
pages 600-607, 1997
[52] Gregory D. Peterson, Roger D. Chamberlain. Parallel application performance in a shared resource
environment. Distributed Systems Engineering, volume 3, pages 9-19, 1996
[53] R.A.Fatoohi. Performance evaluation of communication software systems for distributed computing.
Distributed Systems Engineering, volume 4, pages 169-175, 1997
[54] 3rd Generation Partnership Project. 3G TS 22.067 V3.2.0: enhanced Multi-Level Precedence and Pre-
emption service (eMLPP). 2000.
[55] 3rd Generation Partnership Project. 3G TS 24.067 V4.0.0: enhanced Multi-Level Precedence and Pre-
emption service (eMLPP). 2001.
[56] 3rd Generation Partnership Project. 3G TS 22.105 V4.1.0: Services and Service Capabilities. 2001.
[57] 3rd Generation Partnership Project. 3G TR 25.922 V4.0.0: Radio resource management strategies.
2001.
[58] 3rd Generation Partnership Project. 3G TR 25.935 V4.0.0: Radio resource management; Optimisations
for Iur and Iub. 2001.
[59] 3rd Generation Partnership Project. 3G TS 25.420 V4.0.0: UTRAN Iur Interface General Aspects and
Principles. 2001.
[60] 3rd Generation Partnership Project. 3G TS 25.215 V4.0.0: Physical layer — Measurements (FDD).
2001.
[61] 3rd Generation Partnership Project. 3G TS 23.002 V3.2.0: Universal Mobile Telecommunications
System (UMTS); Network architecture. 2000.
[62] 3rd Generation Partnership Project. 3G TS 23.002 V4.2.0: Universal Mobile Telecommunications
System (UMTS); Network architecture. 2001.
[63] 3rd Generation Partnership Project. 3G TS 25.211 V4.0.0: Physical channels and mapping of transport
channels onto physical channels (FDD). 2001.
[64] 3rd Generation Partnership Project. 3G TS 25.213 V4.0.0: Spreading and modulation (FDD). 2001
[65] 3rd Generation Partnership Project. 3G TS 25.302 V4.0.0: Services provided by the physical layer.
2001.
[66] 3rd Generation Partnership Project. 3G TS 25.301 V4.0.0: Radio Interface Protocol Architecture. 2001
[67] 3rd Generation Partnership Project. 3G TS 25.331 V4.0.0: RRC Protocol Specification. 2001
[68] 3rd Generation Partnership Project. 3G TS 23.107 V3.6.0: QoS Concept and Architecture. 2000
[69] 3rd Generation Partnership Project. 3G TS 25.214 V4.0.0: Physical layer procedures (FDD). 2001

Optim

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Optim

Hochgeladen von

Copyright:

Verfügbare Formate

CAUTION IST-2000-25352

Contractual Date of Delivery to the CEC: 30.6.2001

Keyword list: requirements, congestion study, management techniques, high-level specifications

Date Version Status Comments

Copyright  2001 CAUTION Consortium 13/7/2001

1 EXECUTIVE SUMMARY ........................................................................................................................ 10

Copyright  2001 CAUTION Consortium 13/7/2001

12.1 MULTIPLEX STRUCTURE ................................................................................................................... 252

Copyright  2001 CAUTION Consortium 13/7/2001

TERMS AND ACRONYMS

2G Second Generation of wireless communication systems

Copyright  2001 CAUTION Consortium 13/7/2001

CPICH Power control of common pilot channel

Copyright  2001 CAUTION Consortium 13/7/2001

GTP GPRS Tunneling Protocol

Copyright  2001 CAUTION Consortium 13/7/2001

P-CCPCH Primary Common Control Physical Channel

Copyright  2001 CAUTION Consortium 13/7/2001

SCCH Signaling Control Channel

Copyright  2001 CAUTION Consortium 13/7/2001

Copyright  2001 CAUTION Consortium 13/7/2001

Copyright  2001 CAUTION Consortium 13/7/2001

Copyright  2001 CAUTION Consortium 13/7/2001

Copyright  2001 CAUTION Consortium 13/7/2001

3 STATISTICAL ANALYSIS OF OPERATIONAL DATA IN

3.1 Description of existing cellular network reporting

3.1.1 Introduction to Network Data Warehouse (NDW)

In the Unix environment these processes are dealt with:

In the NT environment these processes are dealt with:

After the pre-processed data is processed, the user finally sees:

3.1.2 NDW Processes

Copyright  2001 CAUTION Consortium 13/7/2001

Figure 1: Network Data Warehouse

3.1.3 Optimizing NMS with NDW

3.1.3.1 Data Processing and Presentation in NDW

3.1.3.2 Differences between NMS online database and NDW

Copyright  2001 CAUTION Consortium 13/7/2001

Table 1: NMS / NDW characteristics

3.1.4 NDW Architecture

Table 2: Description of NDW areas

3.1.4.1 Data collection

3.1.4.2 Data storage

Copyright  2001 CAUTION Consortium 13/7/2001

3.1.4.3 Data post-processing

3.1.4.4 Report distribution

3.1.4.5 Self management

3.1.5 Types of Data in NDW

3.1.5.2 RNW data

Copyright  2001 CAUTION Consortium 13/7/2001

Copyright  2001 CAUTION Consortium 13/7/2001

3.2 Characteristic congestion diagrams

3.2.1 Normal situation diagrams

250 229.16 228.66

Figure 2: Average daily traffic pattern

Copyright  2001 CAUTION Consortium 13/7/2001

88,82 88,86 88,69

Figure 4: Hand Over Success Rate (HOSR) pattern

Copyright  2001 CAUTION Consortium 13/7/2001

0,06 0,13 0,02

Figure 6: TCH Blocking Rate pattern

Copyright  2001 CAUTION Consortium 13/7/2001

3.2.2 Detection of Congestion Situations