GSM Solutions For Optimisation and Densification

GSM
GSMsolutions
solutionsfor
foroptimisation
optimisationand
and
densification
densification
Agenda
>
GSM optimisation/densification methods
>
Product means for densification
>
GSM optimisation after network planning

Possible process/methods for basic GSM optimisation
GSM optimisation/densification during network lifetime
Basic means
Half Rate
Concentric cell
Microcell
Multiband solutions
Product means for optimisation
In release B7
In release B8
All rights reserved 2005, Alcatel
GSM solutions for optimisation and densification,
GSM optimisation/densification methods
First step of network planning on a large city
Second step of network planning on a large city
Why network optimisation is needed

afterwards ?
River
Road
BTS site
Coverage
re-appearance
Too large overlap
Too wide coverage
Uncontinuous coverage
KPI
Possible process/methods for basic GSM

optimisation
TRAFFIC_TCH
50000
40000
30000
>
20000
Dashboard of the Quality of Service in the network

10000
0
W41
W42
W43
W44
W45
W46
W47
W48
Erlang_ TOT
KPI
Status
Call Setup Success
Rate
60000
50000
PAT Target
FAT Target
99.00
Call Setup Success Rate
98.43%
>= 96 %
>= 98 %
Call Drop Rate
1.63%
<= 3 %
<= 2 %
95.59%
>= 94%
>= 95%
40000
30000
20000
98.00
HandOver Success Rate

0
W41
W42
W43
W44
SD_ Blocks
Rate of Cells
with TCH CongestionSD_ Drop
>
97.50
97.00
10000
45000
40000
35000
30000
25000
20000
15000
10000
5000
0
98.50
Rate of Cells with SDCCH Congestion
W45
13.48%
W46
W47
<= 3 %
<= 3 CSSR
%
<= 3 %
<= 3 %
TCH_ AssFail
Call Drop Rate
5.67%
96.50
W48
2.50
2.00
1.50
1.00
with a background
W41
W42
W43
TCH_ Drop_ Radio
0.50
0.00
W44
W45
TCH_ Drop_ HO
W46
W47
W48
TCH_ Drop_ BSS
CDR
HandOver Success Rate
1200000
95.90
95.80
95.70
95.60
95.50
95.40
95.30
95.20
95.10
95.00
94.90
1000000
800000
600000
400000
200000
0
W41
W42
W43
HO_ Success
W44
W45
W46
W47
HOSR
W48
Possible process/methods for basic GSM

optimisation
Ranking of cells according to QoS indicators

Worst Cell List CDR
5 first cells: Highest number of Dropped call

Cell Name
NKS0070_3
Failures
972
Problem description
Start
Date
Action
First neighbors not on air (NKS76, NKS79)
W36
Waiting for NKS76, NKS79
961
Radio drop, border cell
W32
TT number
Problem
type
1a : Pure pb of coverage - a neigh
2.77%
TRG0001_2
5 last cells: Highest rate for Dropped call
Investigations on Cartographic 1bdata

: Pure pb of coverage - no neig
2.64%
NKS0044_1
872
Peak on Nov.26 (304 drops)
7.10%
KBI0006_1
807
694 drop BSS RTC during 3 days
694
W48
8 - Other
4b - Drop BSS TC problem
Solved Nov.28
First neighbor not on air (NKS29)
Investigations on different
timeWaiting
scales
W31
for NKS29
W48
Solved Nov.28
High rate of UL level handover, suspected TMA problem
W47
Check TMA
W48
W48
Coverage hole betw een TRG13_2 and KBI14_1

First neighbor KBI14 declared as RESELECTION ONLY until
Nov.28
W46
20.90%
NKS0060_2
Investigations
on several
W48
Solved Nov.27
QoS indicators
1a : Pure pb of coverage - a neigh
2.52%
233
KBI0006_3
24.66%
112
NKS0065_1
22.76%
6 - Radio and HO Drop artificially g
807
KBI0006_1
20.90%
570
KBI0006_2
12.18%
132
TRG0013_2
11.92%
Investigations
on several
Solved Nov.28
QoS indicators
Solved Nov.28
Investigations on parameter
tuning
TT02123131322
1b : Pure pb of coverage - no neig
7 - Bad definition of the parameter
Optimisation Process - Weekly RNO activities

(1/2)
>
Weekly RNO activities
Worst cell list investigation based on daily Main Indicators

Congestion analysis
Drive tests analysis
Trigger appropriate actions to solve problems
frequency modifications
parameters modifications
design tuning ( azimuth, tilt, lower antenna height..)
neighbourhood modifications
Hardware restoring (reset / restart / boards replacement...)
Follow-up the launched actions
update the PRC list

check if modifications have been performed
boost the modifications
Optimisation Process - Weekly RNO activities

(2/2)
>
Outputs:
Capacity Management Plan (TRX activation and Channel

configuration modifications)
Parameters check results
Network Performance Report
Worst cells list analysis
Parameter/frequency tuning requests
rework requests
Trouble shooting Drive Test Requests
RNO Process (1/3) - Weekly Dashboard analysis

Dashboard
RNO Maneger
Computation
RNO Eng.
Congestion List Analysis
List of TRX
upgrades/downgrades
+ Channel config.
changes
RNO Manager
RNO Eng.
Worst cells List

Analysis
RNO Eng., cc RNO Manager
Network Performance
RNO Manager + QoS Engineer
REPORT
RNO Process 2/3 - Global RNO process

Worst Cells
List
RNO DRIVE TEST TEAM
Deep investigation:
Drive tests
Abis - A trace
RNO ENGINEER
O&M
INSTALL / REWORK
Pb
identified ?
PROJECT MANAGEMENT
NO
YES
YES
Interferenc
e
TAC
Pb
identified ?
Parameter
Tuning
TRX
activation/Channel
Config. modification
Link
Problem
HW
Problem
HW
Reset/Rest
art
PRC
TT to O&M
Team
TT to O&M
Team
TT to O&M
Team
TT to O&M
Team
NO
Antenna
System Pb
YES
External ?
NO
Drive Test
(Spectrum
Analyser)
Request
Frequency
change to FP
Team
External
interference
REPORT
Issue TT to
O&M Team
TT to
Installation/Rewor
k Teams
update TT tracking list

Send Request for Action
update TT tracking list

Send Request for Action
Maintenance FOR ACTION
Install / Rework FOR ACTION
Alert Project
Management
for ACTION
Validation (Drive
Test or QoS)
Correction implemented
YES
Close Trouble Ticket
Pb Solved?
NO
RNO Process (3/3) - Parameter Check

Global Parameter Check
using A956 RNO
RNO Engineer
Split per area

distributed to concerned
RNO Manager
RNO Eng.
Validation by RNO Eng.
RNO Engineer
Copy of Param. Pbs

to RNO Mngr
Operator/Alcatel
Create PRC
Application of PRC by
Maintenance
Maintenance
Weekly Reporting
>
Network Performance Report
Main Indicators Status

Worst cells Lists per Main Indicators
Corrective actions taken
Red Flags
>
Drive Test Campaign Results
>
Capacity Management
>
Weekly Meeting with the Client
RNO, Site Installation, Rework, O&M

Capacity management
Pending issues
Planned actions for next week
Evolution of network complexity

>
More subscribers to handle
>
Extension of the coverage (indoor, )
>
More radio resources to deploy : new sites (or microsites), new frequency band, Half rate, .
>
Different hardware configuration in the network
>
Traffic management : which resources to be used ?
>
Voice Quality concerns : HO optimisation, new CODECs

introduction (through AMR)
>
Data transmission : GPRS, EDGE
Evolution of cell complexity

MS differentiation in terms of :
Frequency bands (900, 1800, G1)
GPRS capable -> GPRS MS classes
AMR capable (in FR or HR))
EDGE capable -> EDGE MS classes
MAFA capable (used in RMS)
TRX differentiation in terms of :

Frequency bands (900, 1800, G1)
Frequency planning
GPRS traffic / speech traffic
1800
Full rate / Half
rate
TRX class (for GPRS CS3/CS4 & EDGE
Initial Frequency planning

Tight frequency
planning
1800
900
Product means for densification
Basic means for densification

>
Increase the number of TRXs in the cells

+
>
Better trunking efficiency

More difficult frequency planning
Reduced transmit power (due to combining stage)
Increase the number of sites in one area : cell splitting

A
AB
B
AC
D
BC
C
After insertion
of three sites
Initial status
Half rate (1/2)

>
Using half a radio-timeslot for a call brings high

capacity improvement :
Traffic-capacity increase
120
%
110
100
90
80
70
Linear increase in HR call share
60
50
40
SDCCHs added
30
20
Traffic-capacity increase
10
0
10
20
30
40
50
60
70
80
Percentage of HR calls
90 % 100
Half rate (2/2)

>
There are some prices to pay for it in terms of :
>
Solutions have been proposed for these issues :
>
BSC connectivity : reduction of the number of TRX per TCU

Voice Quality : HR CODEC is more sensitive to surrounding
noise
BSC connectivity : half-rate flexibility
Voice Quality : AMR HR
But still some issues are under investigations :
Slight increase of call drop rate when HR is activated

Modification of the handover rate due to UL Quality
Possible misbehaviour of Nokia mobiles with HR + DL PC +
BBH
.
Concentric cell (1/4)

>
Realize two concentric zones within one cell.
MS1 can use F1 or F2

MS2 can use F2.
F2
F1
MS1
MS2
BS1
>
The zone applying F1 is in the inner zone
>
The zone applying F2 is in the outer zone


>
Two ways of using concentric cells :
capacity oriented : by using it on an interfered cell

and guaranteeing a high received level in the inner
zone. This allows an additional TRX in the inner zone
with a reduced reuse cluster size.
F2
F2
F1
I1
F1
I2
C1
C2
MS1
MS2
BS1
C1 > C2 I1 > I2 acceptable F1 can be reused in the inner zone
2out+1in
1out+1in
1out+2in
2out+2in
3out+1in
3out+2in
Erlangs
(2% blocking)
Carried Traffic
normal cells
Carried Traffic
Concentric cells
30
5 TRX
25
4 TRX
20
15
3 TRX
10
2 TRX
5
1 TRX
0
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1.0
(Rin/R)^2
QoS oriented :
by using it on an interfering cell to bring down the level
of interference by powering down the inner zone
carriers.
if a frequency is interfered, it is possible to convert it in
an inner zone frequency.
F1
Interference
F1
F1
MS1
BS1
MS2
BS2
Reduced power interference F1 less interfered
Microcell (1/4)
>
Hierarchical network with two layers :

Umbrella cells
macro macro handover
macro micro
handover
micro macro
handover
micro micro handover
Micro cells (cluster 1)
Micro cells (cluster 2)
continuous
coverage of a
large area
coverage of high
trafic area, hot
spot
+
Indoor coverage
Microcell (2/4)
Microcell (3/4)
>
HO strategy : objectives and criteria
Maximising the use of microcells compared to

macrocells :
facilitate the mobiles access to the micro-layer
keep mobiles on the micro-layer as long as possible
... while assuring good quality communications and

avoiding call drops :
Fast moving mobiles are handled by the macrocell layer
In case of emergency (bad radiolink quality) in the micro
layer, calls are handed over to the macro layer
the
tuning of the parameters will result in trade-offs

which limit the load of the macrolayer while
ensuring a very good quality of service in the
microcellular area
Microcell (4/4)
Multiband (1/7)
Multiband BSC
900 and 1800 MHz cells connected to the same BSC
Single band
Dual band
Dual band
BTS 1800 MHz cell and BCCHBT

S
900 MHz cell and BCCH
BSC
Multiband (2/7)
Multiband BSC
>
Few parameters are necessary to operate a dual band

network :
neighbouring cells list and monitoring

idle mode
call set-up
handover
classmark handling
>
It is possible to reuse 900 and 1800 MHz default radio

parameters
>
Traffic balance mechanisms between frequency bands

are interesting to use.
Multiband (3/7)
Multiband cell
900 and 1800 MHz TRXs belonging to the same cell
Dual band
Single band
Dual band
BTS
BSC
1800 MHz TCH
900 MHz BCCH, SDCCH and TCH
Multiband (4/7)
Multiband cell
>
Less cells to operate
>
Only one BCCH frequency plan
>
Dual band MS have less cells to monitor : more

efficient neighbour cell monitoring.
>
Reduced number of inter-cell HO
>
Higher traffic efficiency of the second frequency

band not limited by a BCCH frequency plan
>
Traffic balance mechanisms between frequency

bands are less needed : there is normally no
drawback to saturate 1800 TRX.
Multiband (5/7)
>
In Hierarchical network :
GSM 900 macrocell
GSM 1800 macrocell
GSM 900 microcell
Multiband (6/7)
Higher priority to macro 1800 cells
Macro 900
Traffic
based
handover
1
Macro 1800
Directed retry
Emergency
Handover
1
Initial access
Micro 900
2
Higher priority to 1800

cells
GSM 900 macrocell as a pool of traffic resources
when the preferred cell is congested
Multiband (7/7)
Higher priority to micro 900 cells
Macro 900
Traffic
based
handover
2
Macro 1800
Directed retry
Emergency handover
2
Micro 900
1
Initial access
Higher priority to micro 900 cells

GSM 900 and 1800 macrocell as a pool of traffic
resources when the preferred cell is congested
Overview on features for capacity management

>
Features compensating variation of traffic load
Handover zone adaptation according to traffic load in

PBGT handover (HO cause 12) and in traffic handover (HO
cause 23)
Traffic discrimination in preferred band HO (HO cause 21)
Traffic discrimination in general capture HO (HO cause 24)
Speed discrimination according to the traffic load in the
umbrella cell
AMR channel adaptation according to the traffic load in the
cell
AMR HR=> FR HO (HO cause 26)

AMR FR=> HR HO (HO cause 27)
Traffic balancing between outer zone-inner zone in

multiband cell (HO cause 13)
Fast traffic HO (HO cause 28)
Indoor layer
Product means for optimisation in B7

release
Agenda
>
B7 GSM Features
Fast Traffic Handover

Anti ping pong mechanism for capture HO
Multiband cell (B6 feature)
Multiband cell/concentric cell improvements
Preservation of on-going calls
Indoor Layer
RMS / MAFA
Cell split over 2 BTS
GSM 850 / E-GSM
TCH Pre-emption
AGCH preempt PCH
AMR / TFO
Fast Traffic Handover - Description

Fast Traffic Handover goal:
The Fast Traffic Handover feature provides additional
capacity by improving the system behaviour in case of
sudden traffic peaks leading to full cell congestion
It allows pushing out of a cell an on-going call (inter-cell
handover) to allow a queued request to be served. It can
thus bring benefit even if the queued request takes place in
a part of a cell
not
overlapping another one
new call
attempt
handover
congested cell
Fast Traffic Handover - Description
Fast Traffic Handover can be seen as a complement to the forced

directed retry
in order to give all the opportunities to a call establishment request

leaves the serving cell without congestion
The forced directed retry proposes to push out a queued request in

a neighbour cell if the radio conditions allow it.
The fast traffic handover searches in the whole cell a mobile which
can perform a handover in a non loaded neighbour cell if the
received signal on BCCH is good enough
For Fast Traffic Handover activation, just a flag for enable/disable

this feature (EN_FAST_TRAFFIC_HO) besides the forced directed
retry parameters
Fast Traffic Handover (Cause 28) only applies to inter-cell HO from

TCH to TCH
belongs to the better condition HO causes family and has the lowest
priority among all HO causes
Fast Traffic Handover Pre-Requisites

>Fast
Traffic Handover pre-requisites:
Fast Traffic Handover is really efficient in a multi-layer

environment (dual band or micro-macro)
PM type 6 activation, in order to follow Fast Traffic Handover

through QoS follow-up
The counter related to the number of fast traffic handover is

counter C449 that is not in type 110 but in type 6.
The number of observed cells is limited to 40 cells per BSS

for type 6
In B8 release the counter C449 has been duplicated into type

110: MC449 = C449 NB_TCH_HO_ATPT_28_FastTraffic.
Fast Traffic Handover Trial Feedbacks

>
Fast Traffic Handover field trials feedback:
This feature has been tried in a lot of networks/countries

without reported main problems:
Orange France
TA Orange
Orascom Tunisie
Mcell Mozambique
Emirates
MTN - Sri Lanka
Russia
....

>TA
Orange:
The Assignment blocking decrease significantly and no drop calls

detected in neighboring cells where the calls are handed over
Incoming Handover blocking increase instead because the calls
are attempting to handover back to originated cell.
No mechanism in BSC to prevent this incoming HO attempt.

This might generate KPI issue for the network which concerns Incoming
HO Blocking.
>Orange
France:
Unitary tests validated the behaviour for intra-BSC handovers

Statistical tests on 19 cells in multiband BSC environment :
Congestion reduced on the most congested cell : from 16% to 3%

Queuing failure on timeout also reduced
Forced DR still activated -> Impact with Fast Traffic HO ?
OF feedback : it seems quite interesting


>Sri
Lanka:
Congestion for TCH Normal assignment had decreased by around

50%
Incoming external HO failure due congestion had also decreased
by around 35%
Call drop (due to radio or HO problems) remains stable on the trial
zone and surrounding sites
CSSR had increased from 95.5% to 97%
When FTHO and DR are activated both, more requests where
handed over to the neighbour cells and hence better efficiency for
the queuing system
>Tunisia:
That cell had ~ 300 Fast Traffic HO /day (during the period of Type
6 activation). These 300 HO would have been 300 blocked calls if
the Fast Traffic HO was not activated
Fast Traffic Handover Deployment

>
In South-Africa :
Seen on one BSC :

Split of standard handover causes
% Distance
100%
5
4,5
4
3,5
3
2,5
2
1,5
1
0,5
0
80%
60%
40%
20%
0%
% Pref Band
% Concentric
% Interference
% Gen Capt
% Quality
% Level
% PBGT
% Fast Traf HO
% Traffic
Anti Ping-Pong - Description

Anti Ping Pong mechanism for capture handover:
An anti ping-pong mechanism is created in order to avoid the
triggering of a capture HO after the triggering of an
emergency HO
Complementary mechanism to the already existing one for
intra-layer handovers on cause 12 (power budget)
This anti ping-pong mechanism uses a new parameter
(T_INHIBIT_CPT).
The timer T_INHIBIT_CPT controls the time during which the
capture handover Causes are inhibited:
cause 14 lower and indoor layers capture
cause 21 preferred band capture
cause 24 general capture

T_INHIBIT_CPT is started when an emergency HO on quality
has been performed towards the serving cell, and the
preceding cell does not belong to the same layer or to the
same frequency band as the serving cell.
T_INHIBIT_CPT is started if the serving cell is in the upper or
lower layer, but not if the serving cell is in the single layer.
The B7 implementation does not cover the case where the
serving cell is in a single layer and the previous serving cell
belongs to a different frequency band
Single 900
Cause 21
Emergency quality HO
Single 1800

>
Two very similar cases depending on the layer of the

serving cell (upper or lower) :
remark : CELL_BAND_TYPE(n-1) and CELL_LAYER_TYPE(n1) are also known by the BSC in case of inter-BSC HO
if CELL_LAYER_TYPE(0) = upper:
CELL_LAYER_TYPE(n-1) = lower or indoor
or
CELL_BAND_TYPE (n-1) CELL_BAND_TYPE(0)
an incoming intra-BSC HO on cause 2, 4 or 7 has just been
performed
or
an incoming inter-BSC HO with the A interface cause DL
quality or UL quality has just been performed
if the conditions C1 and C2 are met, the timer
T_INHIBIT_CPT is started and inhibits causes 21, 14 and 24
in serving upper layer cell
C1
C2

>
Two very similar cases depending on the layer of the

serving cell (upper or lower) :
if CELL_LAYER_TYPE (0) = lower:

CELL_LAYER_TYPE(n-1) = indoor
or
CELL_BAND_TYPE (n-1) CELL_BAND_TYPE(0)
an incoming intra-BSC HO on cause 2, 4 or 7 has just been
performed
or
an incoming inter-BSC HO with the A interface cause DL
quality or UL quality has just been performed
if the conditions C3 and C4 are met, the timer
T_INHIBIT_CPT is started and inhibits causes 21, 14 and 24
in the serving lower layer cell
C3
C4

>In
An improvement of the timer T_INHIBIT_CPT extends the capture

handover inhibition mechanism to the case
B8 release:
the serving cell is in a single layer and the previous serving cell belongs
to a different frequency band
Additional condition of T_INHIBIT_CPT :

Case the serving cell (n) is in the upper or single layer
The immediately preceding cell (n-1) is in the indoor or lower layer or the
frequency band of the immediately preceding cell (n-1) is different from
the frequency band of the serving cell (n)
The call has previously performed an emergency internal handover on
quality (Cause 2, 4, and 7) towards the serving cell, or an external
handover with the A interface GSM cause uplink quality or downlink
quality, and there is a bi-directional adjacency link between the
preceding external cell (n-1) and the serving cell (n).
Anti Ping-Pong Pre-Requisites

>
Anti Ping-Pong pre-requisites:

Serving cell is in different layer from neighboring cell
Serving cell = upper layer (Umbrella or macro cell)

Neighboring cell = lower layer (micro cell, indoor cell)
They are suspected to have ping-pong handover each

other.
high number of emergency handovers (cause 2, 4 and

7) from lower layer cell to upper layer cell
also high number of capture handovers (cause 14, 21
and 24) from upper layer cell to lower layer cell
Anti Ping-Pong Trial Feedbacks

>Anti
ping-pong mechanism for capture handover

feedback:
Anti ping-pong activation brought problems related with TCU reset.

This problem was solved since B7 MR6. No many operators tried it:
>TA
Orange France
TA Orange
TMN
Etisalat....
Orange:
From the results of drive test and walk test in tested cell areas,
there is no ping-pong handovers detected. In fact, it is difficult to
locate the ping-pong situation due to the matter of coverage size
There was no major KPIs impacted, a lower number of cause14 HO
(MC_HO) could be found on a particular couples of cell
Anti Ping - Pong Trial Feedbacks

>Orange
France:
Successful unitary tests, no statistical tests yet

OF feedback : only interesting in multilayer/multiband zone border
(to be confirmed in the field)
>TMN:
The trial did not present any significant QoS modification.

Anti Ping-Pong Mechanism activation had no impact on the QoS
indicators, in Micro cells as well as in Umbrella cells.
One reason for this could be the fact that in TMN network there
are no cases of significant ping-pong handovers between Micro
cells and Umbrella.
As this mechanism does not work between a single 900 cell and a
single 1800, this feature is not so useful for TMN network
Multiband cells
>
Multiband cell principle:
Mix of frequency bands within a cell

The BCCH frequency always belongs to the same band
Use of an adapted version of the concentric cells
algorithms
Possible profiles : single, umbrella, mini, micro and indoor
FREQUENCY_RANGE = GSM-DCS
CELL_PARTITION_TYPE = concentric
Single band
Dual band
Dual band
BS
1800 MHz TCH
900 MHz BCCH, SDCCH and TCH
Multiband cells
>Multiband
cell advantages:
Less cells to operate
Dual band MS have less cells to monitor -> more reliable

measurements
Reduced number of inter-cell HO -> improved voice quality
Only one BCCH frequency plan
TRXs management
BCCH and SDCCH recovery management
FHS on separate set of TRXs
Interzone handover algorithms
Multiband cells
>Multiband
cell disadvantages:
The level in the second frequency band is estimated according to

the level in the BCCH frequency band -> lower accuracy of the HO
detection process
Roaming is not possible for single band MS working in the new

frequency band
Introduction of new frequency band TRX has a limiting impact on

the capacity of the old frequency band : it is necessary to add
SDCCH channels in the old frequency band and GPRS can be
supported only in this band
Provide similar coverage of GSM and DCS bands to maximize the

capacity
Multiband/Concentric cells improvements Load

Estimation
>Principle:
Freefactor/Loadfactor, load and traffic evaluations may be

calculated either with the outer zone or the whole cell (TCH TS)
>This
improvement is useful for multiband cells when the

population of monoband mobiles is higher than
multiband ones
when the outer zone of a multiband cell tends to be congested

and the whole cell is not yet congested.
>Cell
parameter used for this choice :
EN_LOAD_OUTER = 1 : only TCH TS of the outer zone are taken

into account in Freefactor/Loadfactor, load and traffic evaluations
EN_LOAD_OUTER = 0 : TCH TS of both zones are taken into
account

Balance
>Principle:
balance of the load between the inner and the outer zones
>Way:
the load of the inner and the outer zones is taken into account for
the triggering of cause 13 (outer zone to inner zone HO)
>Impact:
better zone HO inhibited when the inner zone is more loaded than
the outer zone
>New
cell parameter created in order to enable/disable

the load balance algorithm : EN_LOAD_BALANCE

Balance
>The
loads of the inner and outer zones are

estimated separately every TCH_INFO_PERIOD
seconds :
LOAD_SAMPLE_INNER = 100 * (1 - Nb free inner TCH / Nb tot inner

TCH)
LOAD_SAMPLE_OUTER = 100 * (1 - Nb free outer TCH / Nb tot

outer TCH)
in the above formulas, TCH and PDCH TS are counted
if EN_LOAD_EGSM is set to 1, TCH TS working in the G1-GSM band

are taken into account. If EN_LOAD_EGSM is set to 0, only 1800
and P-GSM TCH TS are taken
intoaccount
All rights reserved
2005, Alcatel
Multiband cells
>
Multiband cells pre-requisites:
Only available with Evolium BTS
The coverage should be aligned between both bands: all the

repeaters must be dual-band
The coverage of the 1800 inner zone should be made

continuous in order to allow mobiles to stay safely in this
band. This can be checked through some radio coverage
plots
The number of TRX in the inner zone and the outer zone
must be determined according to the ratio of coverage
between the two bands
Multiband cells Trial Feedbacks

>Multiband
cells have been tested since B6 release and

deployed in several major networks in Asia, Middle East,
Europe and South of America
>Wind:
With Multiband cell + Cell-Split they had problems with TREs

restarted continuously (TFO commands without TFO activation).
The workaround was to disable intra-cell HO (FR 45/144003). Since
B7 MR9 its corrected
>Orange
France:
Load balance between inner and outer zone of multiband cell not
flexible enough. Need of a specific load limit in inner zone
Orange France complains that during this field trial, RTCH
assignment failure rate went from 0.4% to 1.3%
Multiband cells Trial Feedbacks

>Mobilink
- Pakistan:
GSM TRXs with congestion, but low traffic in DCS TRXs
>TMN:
The results are good and Multiband cell test was consider a
success
No degradation observed in the Drive Tests performed
Stable QoS indicators
Duration of the call decreased due to activation of
EN_MULTIBAND_HO.
HO/Call decreased
>GlobaCom:
RTCH Assign Failure Rate increase from 2% to 4%, due to the

allocation in Multiband Cells (normally in the inner zone)
After new DCS frequency plan and new inner to outer zone
threshold, RTCH Ass Fail reduce to 2.5%
rights reserved 2005, Alcatel
No
congestion
in Allouter
zone were seen
GSM solutions
formore
optimisation
and densification,
Multiband cells Deployment

>
Deployment of multiband cells :
CMCC in china
Etisalat in Emirats
Mobiltel in Bulgaria
Multiband cells : Nanjin city in China (1/4)

>
28 multiband cells have been introduced in Nanjin

network.
Multiband cells are represented in red

on the graph besides.
They are configured with in average :
- 6 TRXs in the outer zone (900)
- 3 TRXs in the inner zone (1800)
Most of them are planned with BBH.
The available bandwidth in 900/1800
is 19MHz/15MHz so the ARCS are :
- In 900 : around 16
- In 1800 : 25

>
The parameter values in the multiband cells are as

follows :
Parameter
Value
BS_TXPWR_INNER
0dB
MS_TXPWR_INNER
30dBm
EN_MULTIBAND_PBGT_HO
FALSE
RXLEV_DL_ZONE
-84dBm
RXLEV_UL_ZONE
-88dBm
ZONE_HO_HYST_DL
14dB
ZONE_HO_HYST_UL
14dB
HO_MARGIN_INNER_OFFSET
10dB

>
The traffic distribution in the multiband cells is as

follows :
Mean traffic of channel
number of TRX
Traffic (Erlang) (Erlang)
900 TRX
162
178.7
0.165
1800 TRX
95
119.0
0.157
The traffic is well distributed between 900 and 1800
However, the mean traffic of channels is lower in

of every
multiband cells than onmean
the traffic
other
cellschannel
of the network :
Multi-band cell group
0.16
Network
0.25

>
The main QoS figures in the multiband cells are as

follows :
SDCCH Drop Rate TCH Drop Rate Handover success Rate
0.30%
0.57%
97.93%
Network
0.49%
0.43%
97.57%
The SDCCH drop rate and the handover success rate are
better in multiband cells but the TCH drop is little bit
higher.
The higher values of TCH drop has been explained by

some antenna installation that lead to inconsistent
coverage between 900 and 1800.
Multiband cells : Abu Dhabi in Emirats (1/4)

>
43 Multiband cells and 68 E-GSM multiband cells in the

Abu Dhabi network : it represents 5% of the cells in the
network.
The Multiband cells are configured with in average :
The E-GSM multiband cells are configured with in

average :
4.5 TRXs in the outer zone (P-GSM 900)

3 TRXs in the inner zone (1800)
7 TRXs in the outer zone among which :

4 in average are P-GSM 900
3 in average are G1 900 (extended band)
3 TRXs in the inner zone (1800)
Most of these multiband cells are planned with BBH

Out of the 43 multiband cells, 23 are microcells.

>
The traffic distribution in the multiband cells is as

follows :
number of
Traffic
Mean traffic of
TRX
(Erlang)
channel (Erlang)
900 TRX
187
534.6
0.408
1800 TRX
122
325.4
0.333
The traffic is more located on 900 than on 1800
The mean traffic of channels is higher in multiband cells

mean
traffic
of
every
than on the other cells of
the network
:
channel

Network
0.348
0.284

>
The main QoS figures in the multiband cells are as

follows :
SDCCH Drop Rate TCH Drop Rate HO success rate
0,20%
0,26%
98,94%
E Multi band cell group
0,24%
0,25%
99,06%
Network
0,24%
0,25%
99,01%
All these indicators show roughly the same values in

multiband cells or e-multiband cells, compared to the
whole network.

>
The TCH assignment failure rate shows the following

difference between multiband cells and the network :
TCH assignment failure rate
1,01%
Network
0,36%
>
This difference can be explained by radio failures

during access to the inner zone. However, such failures
does not degrade too much the Call Setup Success rate
(it stays around 98.8 %)
Preservation of on-going calls - Description

>
Reservation of some P-GSM/DCS TCH TS for incoming emergency,

power budget (cause 12) and FR to HR AMR (cause 27)
handovers
>
If nb of free TCH TS is lower or equal than NUM_TCH_EGNCY_HO:
a normal assignment allocation request cannot be directly satisfied:

the demand is queued or rejected
a TCH allocation request for an intracell or an internal intercell HO is
rejected, except in case of emergency, causes 12 or 27 handovers
a TCH allocation request for an external HO cannot be directly
satisfied except in case of external emergency cause: the demand is
queued or rejected
>
PDCH allocation request from the MFS :
the number of PDCH allocated by the BSC must allow the number of
free remaining TCH TS on P-GSM/DCS TRX being equal to or above
the parameter NUM_TCH_EGNCY_HO
If ALLOC_ANYWAY(cell) =
1, then the queued request can be
allocated on free resources regardless of the threshold
>
Preservation of on-going calls Trial Feedbacks

>Preservation
of on-going calls field trials feedback:
Many questions about this feature, but not so many

feedbacks if it was tried or not and if it worked
Orange France feedback:
Unitary tests validated the behaviour for intra-BSC handovers

Statistical tests on 2 congested cells
On more than 2500 intra-BSC incoming HO requests,
congestion rate was reduced from around 6% to 3%
OF feedback : not applicable in OF because Tqho = 0s
Preservation of on-going calls Trial Feedbacks
UMC (Ukraine) Feedback :
Implementation
Date
Parameter
26-fvr
NUM_TCH_EGNCY_HO ( )
2-mars
NUM_TCH_EGNCY_HO ( )
9-mars
ALLOC_ANYWAY
Current UMC value
1TRX: 1,
2TRX: 3,
DISABLE
Test value for DCS1800 Test value for GSM900
1TRX: 1,
2TRX: 3,
3TRX: 5 1TRX: 1,
2TRX: 3,
3TRX: 5 1TRX: 0,
2TRX: 2,
3TRX: 3 1TRX: 0,
2TRX: 2,
ENABLE
ENABLE
Comment
The new values have improved

the Incoming Inter-BSC HO
performance. But some cells
3TRX: 5
started to suffer from
congestion especially the one
with 1 TRX
The values have been
decreased in order to solve the
3TRX: 3 Congestion problem appeared
just after setting the new values
for the 2 parameters
Enabling this feature had a
significant positive impact on
the Queuing success rate
Indoor Layer - Description
>
An indoor micro cell profile is created
>
It corresponds to the following combination :
CELL_DIMENSION_TYPE = micro
CELL_LAYER_TYPE = indoor
CELL_PARTITION_TYPE = normal
CELL_RANGE = normal
>
It is possible to have a multiband indoor micro cell
>
This feature is mainly useful to operate the indoor cells:
apply default parameters values, distinguish the indoor

cells within RNO, ...
Indoor Layer Trial Feedbacks

TA Orange:
To apply the new layer type (indoor) at IBCs in order to
differentiate the parameters template between micros and
indoors
Related parameters and tested value
CELL_TYPE = indoor at IBCs.
PRIORITY(0,n) = 0 (optional)
Results
The number of unnecessary HOs decreased significantly at the IBCs since
the PBGT HO was prohibited towards micro cells. But this could lead to the
lower HOSR on case by case
Problems
The parameter CELL_TYPE can not be changed from micro to indoor via
PRC. The cell need to be deleted and recreated with indoor type
Indoor Layer Trial Feedbacks

>Orange
France:
Tested in the coming month in the indoor cells of high towers in

Paris suburbs.
Applied to perform capture handover with speed discrimination
(cause 14) between outdoor microcells and indoor cells.
>Etisalat:
Tested successfully but Etisalat didn't like it because it increases

the Quality HO
>MTN
Sri Lanka:
Average transmitted power had been reduced on all indoor cells

by around 3dBm
UL quality HO on network wide had slightly been decreased (from
6.3% to 6.2%)
Changing the cell layer type of the target cells to indoor, better
cell handovers is prohibited from micro to indoor and only capture
handover is allowed
The Call drop rate remains stable on all the impacted cells after
changing their layer type to indoor.
RMS - Description
The feature Radio Measurements Statistics (RMS) is designed to
make far easier the work for planning and optimisation of the
network by providing the operator with useful statistics on reported
radio measurements.
These statistics give directly the real cell characteristics by taking
into account the MS distribution.
RMS are performed by mobiles and BTSs on TCH channels,
computed by the BTSs and made available at the OMC-R through
the PM application.
During the observation period, the BTS stores all the requested
statistics results reported by the mobiles or measured by the BTS on
TCH.
At the end of the observation period, the BTS builds a report (binary
files) and sends it to the
OMC-R.
RMS - Description
RMS allows to:
Detect interfered frequencies and interferes
Assess quality of the cell coverage
Assess radio link quality
Evaluate the voice quality
assess the traffic distribution in the cell from statistics on
reported neighbour cells
Etc.
Those statistics help in debugging the network:

optimize the neighbourhood and frequency plan
detect the origin of a bad QoS in order to optimize
consequently the network parameters
Etc.
RMS/MAFA - Description
>
>
Why MAFA ?
Detect an interferer which is not a neighbor cell
Look for clean frequencies
Improve the frequency plan
MAFA activation
BSC sends and Extended Measurement Order (EMO) to

the MS
MS performs measurement on user defined frequencies

(once at the beginning of the call)
MS measurements reported via Extended Measurement

Report (EMR)
Measurements reported in RMS results

RMS Outputs
>
Main Statistics related to cells TRXs or to the cell
Samples, average Timing Advance, average Power per

RxLev and RxQual
Samples per C/I on neighbor cells or on MAFA frequencies
Samples per Consecutive Frame Erasure (CFE) and RxLev
(UpLink only)
Samples per Radio Link Counter (UpLink only)
Samples per Path Balance
Voice Quality counters (RMS is not an end to end VQ
measurement and hence does not substitute totally VQ
measurements)
Timing advance counters
Number of channel seizures, measurements, ...
RMS Trial Feedbacks

>Radio
Measurements Statistics have been tested and

deployed in several major networks around the world:
TMN - Portugal
Orange France
SFR France
TA Orange - Thailand
ClobaCom - Nigeria
Vietnam
Telering Austria
China
MTN Sri Lanka
Brazil - Claro
Vodacom South Africa
Vimpelcom - Russia
....
RMS Trial Feedbacks

>Vodacom
and Alcatel South-Africa:
Vodacom has tested RMS in the field thanks to some

specific on-air cells linked to their B7 platform :
one indoor cell in the Vodacom premises
one outdoor macro cell in rural environment
Vodacom has tested MAFA on Cape Town area.
A penetration of 10% of MAFA mobiles has been observed.
Alcatel RSA developed on Customer request a tool

(RADAR), which creates an interference matrix based on
field measurements obtained through RMS and the
definition of dummy neighbour cells.
A previous version created for B6 was based on T180 HO stats
(SONAR).
PCS is currently specifying a combination of RADAR and SONAR
functionality with A955 interference predictions, to get the most
accurate basis for Frequency Planning via the A955 AFP.
The result shall be a tool, fully integrated into the Alcatel
Standard tool chain (A955V6 Plug in).
RMS Trial Feedbacks

>Parameter
optimization of concentric cells - MTN:
From RMS data, they find that most of the DL RxLev samples
measured by the mobiles in the outer zone are between 66 dBm
to 79 dBm
However Parameter was set in order to enter the inner zone at

level higher than 64 dbm
Thanks RMS data they will be able to optimize the threshold to

enter the inner zone and hence to capture more traffic in the inner
zone better radio condition - without impacting the overall QoS
After changing the threshold for entering the inner zone from - 64
dBm to 73 dBm, the inner zone coverage area had increased
since the percentage of the RxLev measured samples between 72
dBm and 79 dBm had significantly increased
This leads to more traffic handled on the inner zone at better radio
condition than before
RMS Trial Feedbacks

>Warning
reporting with RMS - MTN:
RMS data can be also used in the warning reporting, in order to

detect cells suffering from interference or hardware problems.
A warning report was created on RNO and provides on daily basis

the list of problematic cells. These problematic cells are
categorized as follows:
Cells
Cells
Cells
Cells
Cells
Cells
Cells
suffering from bad Downlink received level

suffering from bad UL RxLev
suffering from bad DL RxQual
suffering from bad UL RxQual
suffering from unbalanced Path Loss
serving with High Timing Advance
suffering from high UL FER
Cell split over 2 BTS - Description

>Principle
Map sector / cells onto TRX belonging to 2 different BTS
>Benefits
Same number of TRX in fewer racks
No need to touch/modify the configuration of existing BTS

(cabling)
Take full benefit of 12 TRX per cabinet
Support 3x8 TRXs configurations in 2 racks (instead of 3)
To provide EDGE service in BTS G2 sites, by adding an EvoliumTM

BTS
>Applications
Multi-band cells
Configuration extension of sites by adding TRX
Large configurations
Cell split over 2 BTS - Description

>Condition:
only available on A9100 BTS which must be

synchronized
>Antenna
engineering on both BTS must be identical
panel type, height, azimuth, tilt, diversity technique, diversity

separations
Same feeder, jumper
TMAs (if any) on both BTSs
>Same
EIRP required for both paths
>FH:
No restriction on RFH
Restriction on BBH: FHS may not extend over 2 BTSs

Cell split over 2 BTS Trial Feedbacks
This feature has been tried in a lot of networks/countries without

reported main problems:
Orange France
TMN
Germany
WIND
China
....
Cell split over 2 BTS Trial Feedbacks

>
Wind Italy:
>
With Multiband cell + Cell-Split they had problems with

TREs restarted continuously (TFO commands without TFO
activation). The workaround was to disable intra-cell HO
(FR 45/144003). Since B7 MR9 its corrected
Orange France:
Successful unitary tests (handover and assignment

procedures) on 3 multiband cells with 900 and 1800 TRXs
on different BTSs.
Application on mono-band single cells difficult: no
possibility to define SDCCH channels on secondary BTS ?
GSM 850 and E-GSM - Description

>
Reminder:
>
E-GSM = P-GSM band (890-915 MHz - 935-960 MHz) + G1GSM band (880-890 MHz - 925-935 MHz)
GSM850 = 824-849 MHz - 869-894 MHz
Following configurations are now supported:
monoband cells : PGSM, DCS1800, DCS1900, EGSM,

GSM850
multiband cells : PGSM-DCS1800, EGSM-DCS1800
network configurations in GSM850 : mix of GSM 850 and
DCS 1800 cells, mix of GSM 850 and DCS 1900 cells
GSM 850 and E-GSM - Description

>
Details:
multiband cells: it is not possible to mix G1-GSM TRX and

1800 TRX within the same zone
concentric cells: it is possible to have G1 TRX in both
zones
BCCH and SDCCH channels are carried by P-GSM
frequencies
it is not possible to mix G1 frequencies and P-GSM
frequencies within a frequency hopping sequence
GPRS is not supported by G1 TRX
the BSC tries first to allocate a G1 TCH to an E-GSM MS. If
no suitable G1 resource can be allocated to the MS, then
the BSC tries to allocate a TCH in the P-GSM or DCS bands
GSM 850 and E-GSM Trial Feedbacks

>No
many feedbacks concerning E-GSM feature
>Etisalat:
EGSM activation cause radio call drop and TCH assignment failure
This problems was observed sporadically on a few cells where E-GSM had
been activated
Etisalat has agreed to continue deployment of E-GSM and keep this
problem under monitoring for recurrence in new sites
Still open?
CMCC:
CMCC enabled E-GSM and additional 5MHz band in DCS1800 (origin

19MHz/10MHz)
TCH Pre-emption - Description

>
eMLPP = enhanced Multi-Level Precedence and Preemption
>
Aim of the eMLPP feature : supplementary service

which allows a subscriber in the fixed or mobile network
to initiate calls that have priority and pre-emption
attributes known to all the network elements
>
Aim of the Pre-emption feature : allow the operator to

allocate radio resources (TCH) with a higher priority to
preferred subscribers in case of congestion

>
Principle :
only TCH pre-emption is considered

the pre-emption feature is initiated in case of congestion
the feature allows TCH radio resources in a cell to be
allocated to those calls which are deemed to be the most
important
the pre-emption feature uses three bits given by the MSC
to the BSC:
pci (pre-emption capability indication, set by the MSC) : the

connection may pre-empt another connection
pvi (pre-emption vulnerability indication, set by the MSC) : the
connection may be pre-empted
prec (pre-emption recommendation, set by the source BSC) :
indicates in case of incoming inter-BSC HO if the pre-emption
of another connection is recommended or not by the source
BSC

>
Principle :
when a request (ASSIGNMENT REQUEST or HANDOVER

REQUEST) is queued (no TCH is available in the current
cell) and has the pci bit set, the BSC looks for a TCH
(associated to another connection) in the cell which has :
the pvi bit set
the lowest lower priority level (i.e. lower priority level than
the queued request)
>
and, when found, the BSC releases it

remark : the directed retry and fast traffic HO procedures
are not triggered for the queued request in parallel
Parameters :
EN_TCH_PREEMPT : flag to enable/disable on a per BSC

basis the pre-emption feature
TCH Pre-emption Trial Feedbacks
>
It seems that this feature was not very used. This may
come from the fact that this feature must also be
available inside the NSS (and it seems that it was not
available in the Alcatel core network...)
>
DST Brunei:
>
Not possible to activate pre-emption because Alcatel MSC

does not support eMLPP
China:
The operator was interested in implement this feature

(last year)

>T-Mobile:
After TCH_pre-emption was enabled, DTC restart/takeover

was observed on TCHRM DTC of both BSCs
TCH_pre-emption was disabled and the problem disappeared
consequently
Pre-emption feature doesnt work after a while observed in
T-Mobile due to pre-emption queue saturated
This was in B7
>TMN:
After Preemption activation, all DTC Telecom of rack1,2,3

continuously restarted forcing DTC takeover. (B7 MR5 ed.3)
This problem was solved on B7 MR6-ed6
At this moment we have B8 MR6 ed2 and the feature is
enabled; we have Siemens MSCs.

WIND:
All test provided was completed with a positive result
AGCH preempt PCH - Description

Pre-emption of AGCH channels over PCH channels:
The pre-emption mechanism of AGCH channels over PCH
channels existed in B6 release but only when
BS_AG_BLKS_RES = 0 (no CCCH timeslot reserved for AGCH).
In B7 release, it is possible to activate this mechanism even
when BS_AG_BLKS_RES > 0 thanks to the flag
AG_PREMPT_PCH
The purpose of the flag AG_PREMPT_PCH is to be able to use
the pre-emption mechanism when the BCCH Extended is
configured or when the CBCH is supported in a noncombined CCCH configuration (the value BS_AG_BLKS_RES =
0 is not allowed in these cases).
AG_PREMPT_PCH = enable is allowed only with
BS_AG_BLKS_RES = 1, in order to minimise the disturbance
offorthe
paging
sub-channels.
GSM solutions
optimisation
and densification,
AGCH preempt PCH Trial Feedbacks

>
No feedback concerning this feature!
Adaptive Multi-Rate ( AMR )
Goal:
New set of codecs in order to improve voice quality over mobile

network
Main Benefits:
For AMR-FR, good speech quality is maintained at bad radio

conditions.
For AMR-HR, better speech quality is offered at good radio conditions.
Limitations
Depends on mobile penetration

Useful figures
>
AMR penetration had recently reached 20% and

increasing on monthly basis
Austria 19.53%
Pakistan 20.22%
Srilanka 20.55%
Tanzania 19.2%
Tunis 15%

Platform Results
AMR-FR
4
3.5
3
Pace
EFR
2.5
AMR-FR
Opt.
2
1.5
1
20
16
12
6
C/I
Adaptive Multi-Rate (AMR)

Platform Results
AMR-HR
4
3.5
EFR
Pace
HR
2.5
2
AMR-HR
opt.
1.5
1
20
16
12
C/I
Tandem Free Operation (TFO)
Goal:
Avoid double transcoding for Mobile to Mobile calls.
Main Benefits:
Enhance the speech quality for all Mobile to Mobile calls.
Voice Quality for MS to MS is as good as MS to ISDN.
HR to HR calls is now possible, since good speech quality is offered.
Limitations
Compliancy of IPE and NSS release should be granted.

Useful figures
>
Number of TFO calls strongly depends on % of MS to

MS calls in mobile network
Tele.ring (Austria) 4.5%
OTT (Tunis) 5.2%
P.S The values presented above are very low due to the fact
that TFO was enabled on only 1 trial BSC.
Vimpelcom (Russia) ?? %

Platform Results
Voice Quality Results Comparison
4.0
Ms to Fix line
Ms to MS without TFO
3.5
MOS
3.0
2.5
Ms to MS with TFO
3.8
3.8
3.4
3.1
2.7
3.1
Platform Radio Conditions:
2.0
- RxLev=-60dBm
- RxQual=0
1.5
- No MS and BS power
control
1.0
EFR
HR
With TFO, speech quality for MS to MS call is as good as MS to ISDN

call.
HR to HR call is now possible
Product means for optimisation in B8

release
Agenda
Algorithms/Parameters
>QoS
Call Establishment
Normal Assignment Procedure
New counters
System Failures Preparation
Phase
System Failures Execution
Phase
Specific case
Status
Duplication of some counters in
type 110
New counters in type 110
New Counter Type
Additionnal information on QoS
counters
New
feature : Dynamical SDCCH
TCH allocation
New Use of
TRX_PREF_MARK
parameter
Consistency between CS &
PS allocations
TRX Ranking Function
Principles
Traffic Handovers
in multiband mono-layer
networks
Inhibition of Capture HO
for cells belonging to the
single layer
>QoS
Call Establishment
New counters
Phase
System Failures Execution Phase
Specific case
Status
type 110
New Counter Type
counters
New feature : Dynamical SDCCH
TCH allocation
New Use of
TRX_PREF_MARK
parameter
PS allocations
Principles
Traffic Handovers
networks
single layer
Call Establishment
Normal Assignment Procedure (1/6)

Resource not available
in the BSC
ASSIGNMENT
REQUEST MC140a
CONGESTION
Resource available
in the BSC
PREPARATION
PHASE
CHANNEL
ACTIVATION
ALLOCATION
Channel Activation
Failure
System failures
NEW
Channel Activation
Success
ASSIGNMENT
COMMAND
EXECUTION
PHASE
MC140b
Assignment Failure
MS has seized
the channel
ASSIGNMENT
COMPLETE
SUCCESS
Radio failures
System failures
MODIFIED
Call Establishment
New counters (2/6)
Assignment Request
In B7 release : No counter dedicated to the number of

assignment request.
=> It was evaluated adding the TCH allocations & Congestion
=> Approximation : other failures than congestion during the
preparation phase should normally be taken into account in the
assessment of the requests.
In B8 release : A new counter MC140a is introduced for the number of
assignment requests
=> The existing RTCH_assign_request indicator is modified in B8
release
Assignment Command
In B7 release : No counter dedicated to the number of

assignment command.
In B8 release : A new counter MC140b is introduced for the number of
assignment command
=> New indicator in the RNO tool in B8 release:
GSM solutions forRTCH_assign_command
optimisation and densification,
Call Establishment
System Failures Preparation Phase (3/6)
In B8 release : It is possible to evaluate the system failures

occurred during the preparation phase of the normal
assignment procedure.
Formula : Request Command Congestion
New indicator in the RNO tool in B8 release:
RTCH_assign_prep_fail_BSS
RTCH_assign_prep_fail_BSS always equal to 0 using the RNO V4 with
B7 release.
If after the migration from B7 to B8, RTCH_assign_prep_fail_BSS <>
0:
=> we can not speak of a degradation introduced by the B8 release
=> it is quite likely that those failures already existed in B7 with the
same values but it was not possible to evaluate them.
=> impact on the call_setup_success_rate : possible decrease in B8
release as new cause of failure is taking into account.
Call Establishment
System Failures Execution Phase (4/6)
Evaluation of the system failures occurred during the

execution phase of the normal assignment procedure
modified between B7 and B8 releases.
In B7 release: the MC14b counter was used to evaluate this kind of

failures.
=> MC14b indicated sometimes results not 100% reliable; unreal
BSS problems were taken into account
=> MC14b has been removed in B8 release.
In B8 release, thanks to MC140b introduction:
=> it is possible to compute more accurately those failures
=> Formula: Command Success Radio Failures
Call Establishment
Specific case : congested cells with DR activated (5/6)
ASSIGNMENT REQUEST
BSC
Request served
in the neighbour cell
using DR
NEIGHBOUR
CELL
CELL
CONGESTED
NEIGHBOUR
CELL
Case of a congested cell with the

directed retry activated:
=> Not all the ASSIGNMENT
REQUEST received from the MSC
concern this cell.
=> Part of those requests will be rerouted and served in the neighbour
cells through the directed retry
procedure.
=> The MC140a counter overevaluates the number of requests
received on the cell, as it counts also
the requests forwarded and served in
the neighbours via the directed retry.
Call Establishment
Status (6/6)
Main indicators dedicated for call establishment

evaluation have been changed between B7 and B8
releases
RTCH_assign_request = MC140a instead of (MC703 + MC812)
New indicators thanks to new B8 counters MC140a &

MC140b in order to improve the evaluation of call
establishment phase
The formulas of those indicators are not valid in the

specific case of a congested cell with the directed retry
activated.
In order to have the real number of requests : remove the number of

outgoing directed retry successes (MC142e + MC142f) from MC140a.
Workaround: Use the new B8 module on RNO tool that allows
to create indicators and re-create indicators taking into
account this recommendation.
From B8 MR6: the formulas

of2005,
those
indicators have been
All rights reserved
Alcatel
Duplication of some counters in type 110

(1/2)
>AMR
QoS Follow up
MC448a = C447(type6): NB_TCH_HO_ATPT_26_BadQualHR

MC448b = C448(type6): NB_TCH_HO_ATPT_27_GoodQualFR
MC701a = C701a (type1) : NB_TCH_FR_REQ
MC701b = C701b (type1) : NB_TCH_DR_REQ
MC701c = C701c (type1) : NB_TCH_DR_EFR_REQ
MC701d = C701d (type1) : NB_TCH_AMR_REQ
MC701e = C701e (type1) : NB_TCH_DATA_REQ
MC702a = C702a (type1) : NB_TCH_NOR_FR_ALLOC
MC702b = C702b (type1) : NB_TCH_NOR_HR_ALLOC
MC702c = C702c (type1) : NB_TCH_NOR_EFR_ALLOC
MC704a = C704a (type1) : NB_TCH_NOR_AMR_FR_ALLOC
MC704b = C704b (type1) : NB_TCH_NOR_AMR_HR_ALLOC
MC705 = C705 (type1) : NB_TCH_NOR_DATA_ALLOC
=> Note that MC447 and MC704 have been removed from type 110.
MC447 = MC448a + M448b ( CHO_AMR in RNO)

MC704 = MC704a + MC704B ( RTCH_assign_AMR_allocated in RNO)
Duplication of some counters in type 110

(2/2)
>
Fast Traffic HO
MC449 = C449(type6): NB_TCH_HO_ATPT_28_FastTraffic
=> In RNO: CHO_all & CHO_better_condition take into account
MC449 in B8
>
Preservation of on-going calls

MC460 = C460(type1): N_TCH_EMERGENCY_HO_PRESERVATION
=> In RNO, two new indicators introduced :
- RTCH_HO_preservation_allocated = MC460
- RTCH_HO_preservation_allocated_ratio = MC460a /
(MC15a+MC15b)

>
Four new TRX counters in Type 110

MC380c (TIME_TRX_GSM_FR_BUSY) =>
RTCH_GSM_full_occy_total
MC380d (TIME_TRX_GSM_HR_BUSY) =>
RTCH_GSM_half_occy_total
MC380e (TIME_TRX_DCS_FR_BUSY) => RTCH_DCS_full_occy_total
MC380f (TIME_TRX_DCS_HR_BUSY) =>
RTCH_DCS_half_occy_total
=> RTCH_GSM/DCS_occy_total & RTCH_GSM/DCS_Erlang_total
New Counter Type
Implementation of counters for dual-band HO (1/2)
>New
counter type : Type 32
C403a (NB_INC_EXT_TCH_HO_NEW_BAND_ATPT) = HO_Inc_MSC_multiband_allocated

C403b (NB_INC_EXT_TCH_HO_NEW_BAND_SUCC) = HO_Inc_MSC_multiband_success
C404a (NB_OUT_EXT_TCH_HO_NEW_BAND_ATPT) = HO_Out_MSC_multiband_request
C404b (NB_OUT_EXT_TCH_HO_NEW_BAND_SUCC)=HO_Out_MSC_multiband_success
C420a (NB_INC_INT_TCH_HO_NEW_BAND_ATPT) = HO_Inc_BSC_multiband_allocated
C420b (NB_INC_INT_TCH_HO_NEW_BAND_SUCC) = HO_Inc_BSC_multiband_success
C421a (NB_OUT_INT_TCH_HO_NEW_BAND_ATPT) = HO_Out_BSC_multiband_request
C421b NB_OUT_INT_TCH_HO_NEW_BAND_SUCC = HO_Out_BSC_multiband_success
=> HO_Inc_MSC/BSC_multiband_allocated_ratio,
HO_Out_MSC/BSC_multiband_request_ratio
=> HO_Inc/Out_MSC/BSC_multiband_efficiency_rate,
HO_Inc/Out_MSC/BSC_multiband_success_ratio
=>HO_Inc_multiband_XXX & HO_Out_multiband_XXX
Additionnal information on QoS counters

>Type
26 : TCH outgoing handover per adjacency

measurements
The scope of type 26 is extended from 1 to 40 cells.
>Type
29 : Directed retry measurements
The OMC allows the activation of type 29 as a standard type

=> RNO indicators have been created on those counters
- split : outgoing external/internal _ forced/normal
- failures have been introduced : ROC, radio, BSS.
>Type
18 & Type 19 available in RNO from B8 MR4
Type 18 : A interface measurements => A_XXX indicators in the

RNO tool
Type 19 : SMS PP measurements => SMS_XXX indicators in the
RNO tool
>QoS
Call Establishment
New counters
Phase
Specific case
Status
type 110
New Counter Type
counters
TCH allocation
New Use of
TRX_PREF_MARK
parameter
PS allocations
Principles
Traffic Handovers
networks
single layer
TCH Allocation
New Use of TRX_PREF_MARK parameter (1/2)
In B8 release, the definition of the TRX_PREF_MARK parameter is

modified:
The radio resources

TRX_PREF_MARK :
Still indicates the TRX preference used to serve a CS call

Replaces the B7.2 GPRS_PREF_MARK parameter - removed in B8 - in order
to indicate the capacity of the TRX to carry PS traffic.
management
process
only
uses
the
TRX_PREF_MARK > 0: TRX reserved for the CS traffic.

As in previous releases, the highest the TRX_PREF_MARK parameter is,
the highest the priority for the CS traffic is
TRX_PREF_MARK = 0: TRX used for CS & PS traffics
TRX has the lowest priority for CS traffic
Migration Rule
If GPRS_PREF_MARK(B7.2) <> 0 => TRX_PREF_MARK(B8) = 0

If GPRS_PREF_MARK(B7.2) = 0
=> if TRX_PREF_MARK(B7.2) = 0 Then : TRX_PREF_MARK(B8) = 1
=> if TRX_PREF_MARK(B7.2) > 0 Then : TRX_PREF_MARK(B8) = B7 value
TCH Allocation
Consistency between CS & PS allocations (2/2)
In B8 release, a TRX rank is assigned to each PS capable

TRX, i.e with TRX_PREF_MARK=0.
In order to have consistent CS and PS allocations, the

ordering of the PS capable TRX used for the CS allocations
is reverse to the ordering used for PS allocations.
the TRX having the highest TRX rank is preferentially

selected for TCH allocations, whereas the TRX having the
lowest TRX rank is preferentially selected for SPDCH
allocations.
This rule only applies on PS capable TRX
TCH Allocation
TRX Ranking Function - Principles
Step 1 : Separation of non-PS and PS capable TRX

Step 2 : Ranking of the PS capable TRX
HW TRE capability
(G4HP, G4MP or G3)
TRE
Characteristics
DR TRE capability
(FR or HR)
TRX Ranking
function
TRX_PREF_MARK
PS_PREF_BCCH_TRX
TRX or cell
Characteristics
Radio Cell Configuration

(nb of SPDCH per TRX)
TRX ID
TRX Ranking Table
Traffic Handovers
In multiband mono-layer networks (1/2)
Before B8: In a multiband monolayer network, the capture

handovers between cells of different bands are inefficient to
regulate the CS traffic load in the serving cell neighbourhood.
In B8 release: the intra-layer traffic HO (Cause 23) based on a

power budget evaluation between cells of different bands is
allowed
The existing flag EN_MULTIBAND_PBGT_HO will be used to

enable/disable the Handover Cause 23 towards a neighbour cell
belonging to a different frequency band (i.e. BCCH frequency band)
than the serving cell.
To enable only the HO Cause 12 towards a neighbour cell belonging

to a different frequency band than the serving cell
=> disable Cause 23 towards those cells as the flag
EN_TRAFFIC_HO(0,n) enabling/disabling the HO Cause 23 is
defined per cell adjacency link.
Traffic Handovers
In multiband mono-layer networks (2/2)

In B7 release: Cause 23 is checked over all the neighbour cells
belonging to the same layer (CELL_LAYER_TYPE).
In B8 release: In addition to the condition on the cell layer type,
the cell frequency band condition for checking Cause 23 is as
follows
Case the MS is not in the inner zone of a multiband cell
- EN_MULTIBAND_PBGT_HO = disable : Cause 23 must not be
checked between cells which use different frequency band
(CELL_BAND_TYPE).
- EN_MULTIBAND_PBGT_HO = enable : Cause 23 will be
checked over all the neighbour cells without any cell
frequency band restriction.
Case the MS is in the inner zone of a multiband cell
- EN_MULTIBAND_PBGT_HO = disable : Cause 23 is checked
over all the neighbour multiband cells (FREQUENCY_RANGE=
PGSM-DCS1800 or EGSMDCS1800) which belong to the same
BSC as the serving cell.
- EN_MULTIBAND_PBGT_HO = enable : Cause 23 will be
GSM solutions for optimisation
and densification,
checked
over all the neighbour cells without any cell
for cells belonging to the single layer (1/2)

>
In B7 release:
an anti ping-pong mechanism avoids the triggering of a capture
HO after the triggering of an emergency HO on quality.
The timer T_INHIBIT_CPT controls the time during which the
capture handover Causes 14, 21, and 24 are inhibited.
It is started when an emergency HO on quality has been
performed towards the serving cell, and the preceding cell does
not belong to the same layer or to the same frequency band as
the serving cell.
T_INHIBIT_CPT is started if the serving cell is in the upper or
lower layer, but not if the serving cell is in the single layer.
=> The current B7 implementation does not cover the case
where the serving cell is in a single layer and the previous
serving cell belongs to a different frequency band
Single 900
Cause 21
Emergency quality HO
Single 1800
for cells belonging to the single layer (2/2)

>
In B8 release:
An improvement of the timer T_INHIBIT_CPT extends the capture
handover inhibition mechanism to the case : the serving cell is
in a single layer and the previous serving cell belongs to a
different frequency band
Additional condition of T_INHIBIT_CPT :
Case the serving cell (n) is in the upper or single layer
- The immediately preceding cell (n-1) is in the indoor or lower
layer or the frequency band of the immediately preceding
cell (n-1) is different from the frequency band of the serving
cell (n)
- The call has previously performed an emergency internal
handover on quality (Cause 2, 4, and 7) towards the serving
cell, or an external handover with the A interface GSM cause
uplink quality or downlink quality, and there is a bidirectional adjacency link between the preceding external
cell (n-1) and the serving cell (n).
>QoS
Call Establishment
New counters
Phase
Specific case
Status
type 110
New Counter Type
counters
TCH allocation
New Use of
TRX_PREF_MARK
parameter
PS allocations
Principles
Traffic Handovers
networks
single layer
Dynamic SDCCH
Introduction
Dynamic SDCCH configuration rules
Main principles
SDCCH allocation algorithm
TCH/SDCCH timeslot de-allocation
Impacts on existing processes
O&M Aspects
QoS
Field Feeback
Dynamic SDCCH
Introduction
The "Dynamic SDCCH allocation" feature allows to

configure
Following types of TS:
a set of static SDCCH/x timeslots to handle normal SDCCH

traffic
a set of dynamic SDCCH/8 timeslots (TCH/SDCCH
timeslots), which can be used for TCH traffic (no PS
traffic), or for SDCCH traffic depending on the need.
pure SDCCH (static SDCCH)

pure TCH (static TCH)
TCH/SDCCH (dynamical SDCCH/8 TS)
TCH/SPDCH
Major Telecom and O&M impacts

Dynamic SDCCH
Dynamic SDCCH configuration rules

>1.
CBCH shall be configured on a static SDCCH/8 or SDCCH/4

timeslot.
>2. Combined SDCCHs (SDCCH/4 + BCCH) are always static.
>3. To avoid incoherent allocation strategy between SDCCH
and PDCH, a dynamic SDCCH/8 timeslot can not have the
characteristic of being a PDCH (it can not carry GPRS traffic).
>4. The operator must configure at least one static SDCCH/8 or
SDCCH/4 timeslot on the BCCH TRX in a cell.
>5. In cells with E-GSM, only the TRX, which do not belong to
the G1 band, can support dynamic and static SDCCH.
>6. In multiband and concentric cells, only the TRX, which
belong to the outer zone, can support dynamic and static
SDCCH.
>7. Up to 24 static/dynamic SDCCH sub-channels can be
configured per TRX
Dynamic SDCCH
Main principles (1/2)
Principle 1: Preference is given to pure SDCCH timeslots
SDCCH requests are preferably served on the static SDCCH

TS
If several static SDCCH TS contain free SDCCH sub-channels,

the SDCCH sub-channel on the static SDCCH TS that has the
highest number of free SDCCH sub-channels is chosen
The BSC will systematically select the same dynamic SDCCH

TS as long as there are still free SDCCH sub-channels on it
=> to let other dynamic SDCCH TS free to serve the possible
TCH requests
=> the least loaded TCH/SDCCH TS allocated as SDCCH have
more chance of being deallocated sooner, and to become
then available to serve a further TCH request.
Dynamic SDCCH
Main principles (2/2)
Principle 2: Balance TCU processor load between different

TCUs
As a SDCCH allocation is very consuming in terms of CPU on
the TCU, the TCU overload state when selecting a pure
SDCCH or TCH/SDCCH TS is taken into account.
If the TCU Overload state of a given TCU enters the Very
High Overload state, it is forbidden to allocate any SDCCH
sub-channels on that TCU, and thus new TCH/SDCCH
timeslots on the TRX mapped on this TCU.
Principle 3: FR TRX preference
As a TCH/SDCCH TS mapped on a DR TRX can carry two CS

calls in HR, the TCH/SDCCH TS are preferentially selected in
the set of FR TRX so as to preserve the CS capacity of the
cell.
Dynamic SDCCH
SDCCH allocation algorithm

Removal
Removal of
of all
all the
the SDCCH
SDCCH TS
TS mapped
mapped on
on
a
a TCU
TCU in
in Very
Very High
High Overload
Overload state
state
YES
Are
Are there
there any
any free
free static
static SDCCH
SDCCH sub-channel
sub-channel
among
among static
static SDCCH/x
SDCCH/x TS
TS ??
NO
Are
Are there
there any
any free
free dynamic
dynamic SDCCH
SDCCH sub-channel
sub-channel
among
among the
the candidate
candidate dynamic
dynamic SDCCH/8
SDCCH/8 TS
TS
allocated
allocated for
for SDCCH
SDCCH usage
usage ??
YES
NO
Are
Are there
there any
any dynamic
dynamic SDCCH/8
SDCCH/8 TS
TS
available
and
free
in
available and free in the
the cell?
cell?
YES
NO
Send
Send Select
Select channel
channel reject
reject
to
to originating
originating protocol
protocol entity
entity
Select
Select one
one static
static SDCCH
SDCCH sub-channel
sub-channel
1:
Among
TCU
having
1: Among TCU having the
the free
free static
static SDCCH/x
SDCCH/x TS,
TS,
TCU
having
the
most
favourable
overload
TCU having the most favourable overload state
state
2:
2: static
static SDCCH/x
SDCCH/x TS
TS having
having the
the max
max nb
nb of
of free
free SDCC
SDCC
subchannels
subchannels
3:
3: static
static SDCCH/x
SDCCH/x TS
TS with
with the
the lowest
lowest index
index in
in the
the TRX
TRX
with
the
lowest
TRX-id
with the lowest TRX-id
Select
Select one
SDCCH sub-channel
sub-channel
one dynamic
dynamic SDCCH
1:
1: dynamic
dynamic SDCCH/8
SDCCH/8 TS
TS on
on aa FR
FR TRX
TRX
2:
2: dynamic
dynamic SDCCH/8
the lowest
lowest index
index in
in the
the T
T
SDCCH/8 TS
TS with
with the
with
with the
the lowest
lowest TRX-id
TRX-id
Allocate
Allocate one
one dynamic
dynamic SDCCH/8
SDCCH/8 TS
TS
1:
1: Among
Among TCU
TCU having
having the
the free
free dynamic
dynamic SDCCH/8
SDCCH/8 TS,
TS,
TCU
TCU having
having the
the most
most favourable
favourable overload
overload state
state
2:
2: dynamic
dynamic SDCCH/8
SDCCH/8 TS
TS on
on aa FR
FR TRX
TRX
3:
3: dynamic
dynamic SDCCH/8
the lowest
lowest index
index in
in the
the T
T
SDCCH/8 TS
TS with
with the
with
with the
the lowest
lowest TRX-id
TRX-id
Select
Select one
one dynamic
dynamic SDCCH
SDCCH sub-channel
sub-channel
Dynamic SDCCH
TCH/SDCCH timeslot de-allocation
The de-allocation algorithm makes sure that:
dynamic SDCCH/8 timeslots are not allocated too fast to TCH

after de-allocating them;
dynamic SDCCH/8 timeslots are not re-allocated immediately

to SDCCH after deallocating them (Ping-Pong phenomenon)
T_DYN_SDCCH_HOLD :
Timer to define the delay before a dynamic SDCCH/8

timeslot will be de-allocated once all of its SDCCH subchannels are in the free state
Instance : BSC
No changeable at the OMC-R => DLS
Dynamic SDCCH
TCH/SDCCH timeslot de-allocation (2/2)
While T_DYN_SDCCH_HOLD is running:
the dynamic SDCCH/8 TS marked as HOLD is still considered as

allocated to SDCCH and can not be allocated to TCH;
If a subsequent dynamic SDCCH/8 TS used as SDCCH and in the

same cell becomes free:
- If this dynamic SDCCH/8 TS has a higher priority
=> T_DYN_SDCCH_HOLD is re-started and the precedent dynamic SDCCH/8 TS in
HOLD state is de-allocated immediately;
- If this dynamic SDCCH/8 timeslot has a lower priority
=> T_DYN_SDCCH_HOLD is re-started and the just freed dynamic SDCCH/8 TS is deallocated immediately.
T_DYN_SDCCH_HOLD is stopped once one of the sub-channels of the

dynamic SDCCH/8 timeslot marked as HOLD is assigned.
At T_DYN_SDCCH_HOLD expiry:
the dynamic SDCCH/8 TS marked as HOLD is de-allocated => it can
be used for a TCH call or, if needed, for a subsequent dynamic
SDCCH/8 TS allocation.
Dynamic SDCCH
Impacts on existing processes (1/5)
Interference band updating

the interference band table is not updated with interference
measurements corresponding to TCH/SDCCH TS allocated as
SDCCH
when a TCH/SDCCH timeslot used as SDCCH becomes free,
the TS is classified with the previous interference band, if
available, else, with the worst interference band.
Load & Traffic evaluation

a TCH/SDCCH TS allocated as SDCCH is seen as a TS in the
"busy" occupancy state.
a TCH/SDCCH TS allocated as TCH and used to carry CS
traffic (in HR or FR usage) is seen as "busy". It is seen as
"free" only when the TS is allocated to TCH and it does not
carry any CS traffic.
Dynamic SDCCH
Timeslots reservation for high priority requests

The O&M parameter NUM_TCH_EGNCY_HO allows the
operator to reserve a number of TS on DR or FR GSM/DCS
TRXs for high priority TCH requests (emergency HO).
The reserved timeslots may be located on pure TCH
timeslots, on TCH/SDCCH timeslots, or on TCH/SPDCH
timeslots.
Radio Pools of TCH sub-channels

a new pool type is introduced: GSM/DCS TCH/SDCCH radio
pool. It contains all the free TCH sub-channels (FR or HR)
available on the TCH/SDCCH TS of the GSM/DCS TRXs.
As for the other ones, it is divided in three sub-pools: FR
radio sub-pool, DR radio sub-pool, HR radio sub-pool
Dynamic SDCCH
Preservation of the generic resources
The TCH requests for E-GSM MS are preferentially

allocated
in the G1 band
on TCHs of the GSM/DCS bands
>
1: on pure TCH timeslots

2: on TCH/SPDCH timeslots
>
3: TCH requests are served on TCH/SDCCH timeslots.
>
The TCH requests are preferentially not served on

TCH/SDCCH TS
A fully free dynamic SDCCH/8 TS which is not in the HOLD
state will only be allocated to a TCH channel select request if
there are no other free TCHs.
Dynamic SDCCH
FR/DR TRX preference

In case the cell enters a high load state, the Radio TCH Allocation
function tends to allocate an HR TCH sub-channel to the TCH
requests (if possible and allowed by the operator).
On pure TCH timeslots:

a FR TCH request is preferentially served with
- 1: a FR TCH sub-channel available on a FR TRX
- 2: a FR TCH sub-channel available on a DR TRX.
an HR TCH request is preferentially served with an HR TCH subchannel whose mate is already busy.
On TCH/SDCCH timeslots:
a FR TCH request is preferentially served with
1: a FR TCH sub-channel available on a DR TRX
2: a FR TCH sub-channel on a FR TRX
an HR TCH request is preferentially served with an HR TCH subchannel whose mate is already busy.
Dynamic SDCCH
Radio TCH Selection based on the interference bands
The O&M parameter N_TCH_HO indicates the number of

timeslots reserved in a cell for handover in the best
interference bands. This function allows allocating to a
handover the least interfered TCH subchannel.
As pure TCH or TCH/SPDCH TS should be more widely used

than TCH/SDCCH TS
=> TCH/SDCCH timeslots are excluded from the FR TCH
subchannels reserved by the parameter N_TCH_HO
Dynamic SDCCH
O&M Aspects (1/2)
The configuration rules/constraints used in B7 release to

dimension the SDCCHs at the OMC-R by selecting the
exact positions of the TS have been kept.
-
Selection by simple mouse clicks a set of SDCCH TS.
Using the same HMI, selection of additional TS which are

marked as "dynamic SDCCH/8 TS".
In addition to the SDCCH assisted configuration of B7

release, configuration templates easy to apply to a large
number of cells are proposed.
Dynamic SDCCH
O&M Aspects (2/2)
In B8 release
Principle:
a new mechanism is offered to modify SDCCH configuration

or to introduce dynamic SDCCH configuration on a large
group of existing cells.
This mechanism consists of a Java Script applying Template
on a group of selected cells.
The Java script does not intend to help to create cells, but
only to modify the existing ones.
The OMC manages 10 SDCCH Templates defining SDCCH
configurations - static or/and dynamic - to be applied by the
Java script to a group of cells.
The operator is able to customise the SDCCH templates.
The Java script is launched in a PRC with one of the templates
defined
Activation of the feature
The feature can be activated cell per cell or on a large group

of cells with the configuration
templates
using the Java script.
All rights reserved 2005,
Alcatel
Dynamic SDCCH
QoS
Dynamic_TS_nb_avg = CELL_NB_DYN
Dynamic_TS_available_nb_avg = MC800
Number of configured dynamic SDCCH/8 timeslots

Average number of available dynamic SDCCH/8 timeslots
"Available" = The timeslot is available if it is not "blocked" or "out of service
(the operational state of a timeslot).
RTCH_dynamic_allocated_nb_avg = MC801a
Average number of busy dynamic SDCCH/8 timeslots allocated as TCH
RTCH_dynamic_allocated_nb_avg_max = MC801b
SDCCH_dynamic_allocated_nb_avg = MC802a
Average number of busy dynamic SDCCH/8 timeslots allocated as SDCCH
SDCCH_dynamic_allocated_nb_max = MC802b
Existing indicators for capacity evaluation and status but also for
traffic offered have been updated taking into account dynamic SDCCH
TS
Dynamic SDCCH
Field Feeback
> Orange
France
Unitary Tests: the behaviour observed on field is in line

with the theoretical behaviour expected ; the new
counters have been incremented during those tests and
values were consistent with the tests realised.
Statistical Tests: several cases have been analysed
Case1 : No SDCCH congestion & RTCH congestion

Case 2 : SDCCH & RTCH congestion
Case 3 : SDCCH congestion & no RTCH congestion
with add of dynamic SDCCH / replacement of static

resources by dynamic ones
=> No QoS degradations observed ; some improvements
on congestion but not enough cells to generalize
conclusions
Dynamic SDCCH
Field Feeback
>
MOBILY-KSA (Kenya)
4th of August: SDCCH

Dynamic
Implementation
>
Dhiraagu (Maldives)
Problem of SDCCH assignment failure rate when Dynamic

SDDCH has been tested (?)
Dynamic SDCCH
Field Feeback
>
TA Orange (Thailand)
Introduction of Dynamic SDDCH + reconfiguration of static
SDCCH :
Dynamic SDCCH
Field Feeback
SDDCH QoS evolution on that cell :

Dynamic SDCCH implementation
www.alcatel.com

GSM Solutions For Optimisation and Densification

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

GSM Solutions For Optimisation and Densification

Загружено:

Авторское право:

Доступные форматы

GSM

GSM optimisation/densification methods

Product means for densification

GSM optimisation after network planning

Product means for optimisation

GSM solutions for optimisation and densification,

GSM optimisation/densification methods

First step of network planning on a large city

All rights reserved 2005, Alcatel

GSM solutions for optimisation and densification,

Second step of network planning on a large city

All rights reserved 2005, Alcatel

GSM solutions for optimisation and densification,

Why network optimisation is needed

All rights reserved 2005, Alcatel

GSM solutions for optimisation and densification,

Possible process/methods for basic GSM

Dashboard of the Quality of Service in the network

Call Setup Success Rate

Call Drop Rate

HandOver Success Rate

Rate of Cells with SDCCH Congestion

Call Drop Rate

TCH_ Drop_ Radio

TCH_ Drop_ BSS

HandOver Success Rate

All rights reserved 2005, Alcatel

GSM solutions for optimisation and densification,

Possible process/methods for basic GSM

Ranking of cells according to QoS indicators

5 first cells: Highest number of Dropped call

First neighbors not on air (NKS76, NKS79)

Waiting for NKS76, NKS79

Radio drop, border cell

1a : Pure pb of coverage - a neigh

5 last cells: Highest rate for Dropped call

Investigations on Cartographic 1bdata

Peak on Nov.26 (304 drops)

694 drop BSS RTC during 3 days

4b - Drop BSS TC problem

First neighbor not on air (NKS29)

170 drop BSS RTC during 2 days

High rate of UL level handover, suspected TMA problem

694 drop BSS RTC during 3 days

242 drop BSS RTC during 3 days

Coverage hole betw een TRG13_2 and KBI14_1

1a : Pure pb of coverage - a neigh

4b - Drop BSS TC problem

6 - Radio and HO Drop artificially g

4b - Drop BSS TC problem

4b - Drop BSS TC problem

All rights reserved 2005, Alcatel

GSM solutions for optimisation and densification,

1b : Pure pb of coverage - no neig

7 - Bad definition of the parameter

Optimisation Process - Weekly RNO activities

Weekly RNO activities

Worst cell list investigation based on daily Main Indicators

Follow-up the launched actions

update the PRC list

All rights reserved 2005, Alcatel

GSM solutions for optimisation and densification,

Optimisation Process - Weekly RNO activities