Professional Documents
Culture Documents
Docshare - Tips Optim PDF
Docshare - Tips Optim PDF
D-2.1
Requirements Analysis and Functional Specifications
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.
DOCUMENT HISTORY
TABLE OF CONTENTS
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.
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.
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
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.
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.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.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.
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.
300
266.59
256.43 260.52
254.67 254.73
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
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
%
2:00
4:00
6:00
8:00
10:00
12:00
14:00
16:00
18:00
20:00
22:00
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
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
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.
25000
20000
15000
Erlang
10000
5000
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
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
100
97,5
95
92,5
90
%
87,5
85
82,5
80
100
90
80
70
60
50
%
40
30
20
10
100
90
80
70
60
50
%
40
30
20
10
100
90
80
70
60
50
%
40
30
20
10
100
90
80
70
60
50
%
40
30
20
10
100
90
80
70
60
50
%
40
30
20
10
100
90
80
70
60
50
%
40
30
20
10
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.
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.
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.
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.
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).
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:
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.
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
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.
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.
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.
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.
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.
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%.
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).
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.
In addition, the TCH call blocking was measured above 30% during the BH (Figure 31).
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.
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.
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!
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.
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.
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.
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.
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.
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.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.
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.
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.
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.
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.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.
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.
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 )
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.
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.
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.
Therefore more observation went on in the first BTS from the above table and the following figures show the
corresponding results.
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.
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:
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:
In comparison with a simple dial-up connection using the PSTN network with ISP_1 the followed results are
shown:
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.
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).
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.
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.
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.
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.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.4.1 Predictability
4.1.5.1 Predictability
4.1.6.1 Predictability
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.
4.1.7.1 Predictability
4.1.8.1 Predictability
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.
4.1.9.1 Predictability
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.
4.1.10.1 Predictability
4.1.11.1 Predictability
4.1.12.1 Predictability
4.1.13.1 Predictability
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.
4.1.14.1 Predictability
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.
4.1.15.1 Predictability
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.
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.
Data communications
bit rate Single slot Double slot Multiple slot
Application 9.6 kbit/s 19.2 kbit/s 76.8 kbit/s
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.
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.
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.
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.
on the factors that affect the identified traffic patterns, to pinpoint those behaviors that can be observed during
overload situations.
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).
Circuit
Circuit call
call Circuit call
Session
Session Session Session
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
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.
The different views of the Web browsing process shown in Figure 61 can be mapped into the session model
shown in Figure 62.
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.
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
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.
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.
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
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.
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.
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 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
Transmission requests
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
Transmission requests
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
3%
GPRS Reserved Channels = 0
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]
When the bottleneck is not found in the random access channel, other logical signaling channels may become
overloaded.
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.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.
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.
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:
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
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.
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.
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
• 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.
• 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.
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
• 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.
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.
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:
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
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
UA (SDCCH)
UA (SDCCH)
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.
SABM <identity>
(SDCCH)
UA <identity>
(SDCCH)
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.
UA <identity> (SDCCH)
DISC (SDCCH)
BSSMAP Clear Complete
UA (SDCCH)
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:
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:
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
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
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>
RIL3-CC Connect
Ack
Conversation
starts
MAP/B Call
Complete
RIL3-CC Call Proceeding
RIl3-CC
Assignment Cmd
RIl3-CC Assignment
Complete SDCCH (Up. Lk.)
RIl3-CC Assignment
Complete
• 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:
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.
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
TUP/ISUP Answer
Conversation starts
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.
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.
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.
• 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.
IDLE IDLE
Implicit Detach
or Cancel location READY READY
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.
GGSN
SGSN SGSN
MS MS MS
Intra SGSN Inter SGSN
RA Update RA 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.
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.
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
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.
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.
call in progress
begin
session n_pkt_calls pkts transmission
RR ALOHA
RR
usage usage
wait
grant
TCH
assignment
TCH
granted
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
RR ALOHA
RR
usage usage
wait
grant
TCH
assignment
TCH
granted
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
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)
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.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.
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:
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.
Broadcast TRX
Downlink
Uplink
FN TS0 TS1 FN TS2 TS3 TS4 TS5 TS6 TS7
0 SDCCH3 SACH1 0 TCH TCH TCH TCH TCH TCH
1 SDCCH3 SACH1 1 TCH TCH TCH TCH TCH TCH
2 SDCCH3 SACH1 2 TCH TCH TCH TCH TCH TCH
3 SDCCH3 SACH1 3 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
7 SACH2 SACH2 7 TCH TCH TCH TCH TCH TCH
8 SACH2 SACH3 8 TCH TCH TCH TCH TCH TCH
9 SACH2 SACH3 9 TCH TCH TCH TCH TCH TCH
10 SACH3 SACH3 10 TCH TCH TCH TCH TCH TCH
11 SACH3 SACH3 11 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
16 RACH SDCCH0 16 TCH TCH TCH TCH TCH TCH
17 RACH SDCCH0 17 TCH TCH TCH TCH TCH TCH
18 RACH SDCCH0 18 TCH TCH TCH TCH TCH TCH
19 RACH SDCCH1 19 TCH TCH TCH TCH TCH TCH
20 RACH SDCCH1 20 TCH TCH TCH TCH TCH TCH
21 RACH SDCCH1 21 TCH TCH TCH TCH TCH TCH
22 RACH SDCCH1 22 TCH TCH TCH TCH TCH TCH
23 RACH SDCCH2 23 TCH TCH TCH TCH TCH TCH
24 RACH SDCCH2 24 TCH TCH TCH TCH TCH TCH
25 RACH SDCCH2 25
26 RACH SDCCH2 0 TCH TCH TCH TCH TCH TCH
27 RACH SDCCH3 1 TCH TCH TCH TCH TCH TCH
28 RACH SDCCH3 2 TCH TCH TCH TCH TCH TCH
29 RACH SDCCH3 3 TCH TCH TCH TCH TCH TCH
30 RACH SDCCH3 4 TCH TCH TCH TCH TCH TCH
31 RACH SDCCH4 5 TCH TCH TCH TCH TCH TCH
32 RACH SDCCH4 6 TCH TCH TCH TCH TCH TCH
33 RACH SDCCH4 7 TCH TCH TCH TCH TCH TCH
34 RACH SDCCH4 8 TCH TCH TCH TCH TCH TCH
35 RACH SDCCH5 9 TCH TCH TCH TCH TCH TCH
36 RACH SDCCH5 10 TCH TCH TCH TCH TCH TCH
37 SDCCH0 SDCCH5 11 TCH TCH TCH TCH TCH TCH
38 SDCCH0 SDCCH5 12 SACCH SACCH SACCH SACCH SACCH SACCH
39 SDCCH0 SDCCH6 13 TCH TCH TCH TCH TCH TCH
40 SDCCH0 SDCCH6 14 TCH TCH TCH TCH TCH TCH
41 SDCCH1 SDCCH6 15 TCH TCH TCH TCH TCH TCH
42 SDCCH1 SDCCH6 16 TCH TCH TCH TCH TCH TCH
43 SDCCH1 SDCCH7 17 TCH TCH TCH TCH TCH TCH
44 SDCCH1 SDCCH7 18 TCH TCH TCH TCH TCH TCH
45 RACH SDCCH7 19 TCH TCH TCH TCH TCH TCH
46 RACH SDCCH7 20 TCH TCH TCH TCH TCH TCH
47 SACCHO 21 TCH TCH TCH TCH TCH TCH
48 SACCHO 22 TCH TCH TCH TCH TCH TCH
49 SACCHO 23 TCH TCH TCH TCH TCH TCH
50 SACCHO 24 TCH TCH TCH TCH TCH TCH
25
TRX 1
Downlink
SDCCH/8 + 7 TCHs
Uplink
FN TS0 FN TS1 TS2 TS3 TS4 TS5 TS6 TS7
0 SACH1 0 TCH TCH TCH TCH TCH TCH TCH
1 SACH1 1 TCH TCH TCH TCH TCH TCH TCH
2 SACH1 2 TCH TCH TCH TCH TCH TCH TCH
3 SACH1 3 TCH TCH TCH TCH TCH TCH TCH
4 SACH2 4 TCH TCH TCH TCH TCH TCH TCH
5 SACH2 5 TCH TCH TCH TCH TCH TCH TCH
6 SACH2 6 TCH TCH TCH TCH TCH TCH TCH
7 SACH2 7 TCH TCH TCH TCH TCH TCH TCH
8 SACH3 8 TCH TCH TCH TCH TCH TCH TCH
9 SACH3 9 TCH TCH TCH TCH TCH TCH TCH
10 SACH3 10 TCH TCH TCH TCH TCH TCH TCH
11 SACH3 11 TCH TCH TCH TCH TCH TCH TCH
12 12 SACCH SACCH SACCH SACCH SACCH SACCH SACCH
13 13 TCH TCH TCH TCH TCH TCH TCH
14 14 TCH TCH TCH TCH TCH TCH TCH
15 SDCCH0 15 TCH TCH TCH TCH TCH TCH TCH
16 SDCCH0 16 TCH TCH TCH TCH TCH TCH TCH
17 SDCCH0 17 TCH TCH TCH TCH TCH TCH TCH
18 SDCCH0 18 TCH TCH TCH TCH TCH TCH TCH
19 SDCCH1 19 TCH TCH TCH TCH TCH TCH TCH
20 SDCCH1 20 TCH TCH TCH TCH TCH TCH TCH
21 SDCCH1 21 TCH TCH TCH TCH TCH TCH TCH
22 SDCCH1 22 TCH TCH TCH TCH TCH TCH TCH
23 SDCCH2 23 TCH TCH TCH TCH TCH TCH TCH
24 SDCCH2 24 TCH TCH TCH TCH TCH TCH TCH
25 SDCCH2 25
26 SDCCH2 0 TCH TCH TCH TCH TCH TCH TCH
27 SDCCH3 1 TCH TCH TCH TCH TCH TCH TCH
28 SDCCH3 2 TCH TCH TCH TCH TCH TCH TCH
29 SDCCH3 3 TCH TCH TCH TCH TCH TCH TCH
30 SDCCH3 4 TCH TCH TCH TCH TCH TCH TCH
31 SDCCH4 5 TCH TCH TCH TCH TCH TCH TCH
32 SDCCH4 6 TCH TCH TCH TCH TCH TCH TCH
33 SDCCH4 7 TCH TCH TCH TCH TCH TCH TCH
34 SDCCH4 8 TCH TCH TCH TCH TCH TCH TCH
35 SDCCH5 9 TCH TCH TCH TCH TCH TCH TCH
36 SDCCH5 10 TCH TCH TCH TCH TCH TCH TCH
37 SDCCH5 11 TCH TCH TCH TCH TCH TCH TCH
38 SDCCH5 12 SACCH SACCH SACCH SACCH SACCH SACCH SACCH
39 SDCCH6 13 TCH TCH TCH TCH TCH TCH TCH
40 SDCCH6 14 TCH TCH TCH TCH TCH TCH TCH
41 SDCCH6 15 TCH TCH TCH TCH TCH TCH TCH
42 SDCCH6 16 TCH TCH TCH TCH TCH TCH TCH
43 SDCCH7 17 TCH TCH TCH TCH TCH TCH TCH
44 SDCCH7 18 TCH TCH TCH TCH TCH TCH TCH
45 SDCCH7 19 TCH TCH TCH TCH TCH TCH TCH
46 SDCCH7 20 TCH TCH TCH TCH TCH TCH TCH
47 SACCHO 21 TCH TCH TCH TCH TCH TCH TCH
48 SACCHO 22 TCH TCH TCH TCH TCH TCH TCH
49 SACCHO 23 TCH TCH TCH TCH TCH TCH TCH
50 SACCHO 24 TCH TCH TCH TCH TCH TCH TCH
25
TRX 2
Downlink -- Uplink
8 TCHs
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:
Uplink
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):
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):
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.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.
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.
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:
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.
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.
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.
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.
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).
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.
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.
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).
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:
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.
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.
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.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.
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.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)
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.
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:
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:
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:
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.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:
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).
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.
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.
Levels A and B shall be mapped to level 0 for priority treatment outside of the MSC area in which they are
applied.
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.
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.
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.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.
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.
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.
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.
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.
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.
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.
As a result, this has led to decrease of the total SDCCH traffic more than 10 % as shown in Figure 97.
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.
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.
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
The queue type priority and MSC informed priority could be set on or off
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.
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).
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.
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.
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.
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.
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.
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
REQUEST message, is used.
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
REQUEST message, is used.
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
REQUEST message, is used.
-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.
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.
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.
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.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.
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.
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.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.
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
REQUEST message, is used.
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).
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".
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.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.
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.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):
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.
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.
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.
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.
5.1.14.2.1 Introduction
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.
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:
• 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.1 Introduction
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.
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.
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 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.1 Introduction
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.
• 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.
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.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.
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.
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.
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.
Normal signalling
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
Channel activation
( Bi-directional / Uni-directional Bm Multislot configuration)
n times
Channel activation ack
Assignment command
( Description of multislot configuration )
Seize IW
resources
Normal signalling
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.
Normal signalling
Normal signalling
SetUp
( OMT, FNUR, UIMI(NT only) )
Call Confirmed
( OMT, FNUR, ACC, Max TCH/F, UIMI(NT only) , AIUR(NT only) )
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
Resource change
decision
Resource
allocation
R times Adjust IW
RF channel release ack resources
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.
Resource change
decision
Resource
allocation
Assignment command
( Description of multislot configuration )
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.
Figure 105: Resource upgrading and downgrading, the position of the main channel changed
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.
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.
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.
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
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.
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.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.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.
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.
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].
• 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].
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].
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].
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.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].
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.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.
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.
T
.. IWF
A
F
.
n full-rate channels
1 circuit maximum
or n time slots per TDMA frame
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.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.
GPRS core
GSM BSC network
user
SGSN
BTS GGSN
GPRS SGSN
BSC
user
BTS
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
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.
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.
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.
UTRAN CN
Node–B
MSC/ VLR GMSC PSTN
RNC
Node–B
Iur HLR
IP
SGSN GGSN
Node–B RNC X.25
Uu Iub Iu
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).
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].
• 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:
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.
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.
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.
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);
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).
• 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).
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.
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).
RLC
RLC L2
logical channels
MAC
MAC L2
transport channels
PHY
PHY L1
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.
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.
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]
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.
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]
,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.
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
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.
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.
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
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].
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:
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 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].
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.
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).
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
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.
CAUTION
system
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%
...
Concentrator
RMU
Bridge
Thereinafter the form of the clear codes, which are collected from a specific monitoring tool, is presented.
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.
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.
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
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
Is in DB?
DB
Resource
Logs, management
predictable write onto DB
execution
events etc
OMC
RMU
Figure 117: RMU high-level design
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.
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
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.
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:
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
8 UMTS SIMULATOR
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.
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.
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.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.
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.
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.
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).
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.
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
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.
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]
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]
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].
Things that require attention in the simulator related to traffic modeling are listed below
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.
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.
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).
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.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.
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
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.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).
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
3,00 0,30
2,00 0,20
1,00 0,10
0,00 0,00
1 10 100 1000 10000
Processors
Computer 1
Computer 2
Other
Computer 3 Routing parts
Computer 4 … switch of
LAN
…
Computer N
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%.
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
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.
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
control
j, proposed
Power
limit is not exceeded
P TX,TOT
j, approved
|BS| floats
P TX,TOT
j, approved
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
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.
Calculation unit N
OVSF Allow
Propagation Shadowing Power control allocation Handover
loss proposition for CU?
No No
Yes
Stop Stop? Init calls
Calculation Calculation
unit 1 unit 2
Central controller
Process
data
Calculation Calculation
unit 2 unit 1
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
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.
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
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
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
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)
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.
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.
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) ))
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.
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
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.
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
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.
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.
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.
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.
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”.
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.
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.
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.
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
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.
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.
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.
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
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
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.
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
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
MISH + MOSH
HOSRMSC − CONTROL = *100 (%)
MIO
13. BLOCKED 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.
TR: TCH_REQUEST
TCR: TCH_CALL_REQ
THS: TCH_HO_SEIZ
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”.
This can be shown in the first sheet of the excel file, “Cell Capacity”.
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.
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:
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:
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:
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:
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.
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).
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)
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.
The table above lists the traffic channels specified in GSM recommendation
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)
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.
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.
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.
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.
• 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)
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.
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.
Short bursts in counter changes between successive time slices are observed, and an alarm is triggered when the
Burst threshold has been reached.
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.
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.
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