MXBSC B10 Improvements - Field Feedback: Technology Introduction & Support Network Engineering

Technology Introduction & Support
Network Engineering
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Domain BSS Release First Off

Product GSM/GPRS/EDGE
Division Methods
Rubric First - Off
Type MX BSC
Keywords B10, MXBSC, TRX, traffic, migration, QoS follow up, Stability, Dimensioning
Release Date 17 – June - 2009
CRISTIAN IOAN INTA, EUGEN MARZA, JOÃO FRADE
MXBSC B10
Improvements - Field
Feedback
Abstract
This document presents the methods, results, and problems detected during the
deployment of MXBSC in B10 in Alcatel-Lucent projects.
Predistribution
Department Name Department Name

NE Florent Colin GSM Romania Oliviu Burlacu
NE Romania Eugen Marza NE Romania Cristian Udriste
NE Portugal João Frade NE France Milena Palumbo
NE France Thierry Plantier
Approval Authorities
Department Name Date Signature
NE Manager Florent Colin 17.06.2009
GSM Romania Manager Oliviu Burlacu 17.06.2009
MX-BSC B10 Improvements – Field Feedback Edition 02 RELEASED 3DF 01907 8010 VAZZA
1/84
Table of Contents
TABLE OF CONTENTS......................................................................................................................................... 2

1 REFERENCED DOCUMENTS .............................................................................................................................. 3
2 MX BSC IMPROVEMENTS IN B10....................................................................................................................... 4

2.1 1000 TRX MX BSC capacity .......................................................................................................................... 4
2.1.1 B9 situation ............................................................................................................................................. 4
2.1.2 B10 evolution .......................................................................................................................................... 4
2.1.2.1 Connection of a SMLC to a BSS ................................................................................................... 4
2.1.2.2 Requirements to connect a MFS to a MX BSC .............................................................................. 4
2.1.2.3 Summary of the requirements for this feature in B10 ................................................................ 4
2.2 SS7 on High Speed Links (HSL) .................................................................................................................... 5
2.2.1 B9 situation .............................................................................................................................................. 5
2.2.2 B10 evolution........................................................................................................................................... 5
2.2.2.1 Requirements for supporting ITU variant of HSL in the MX BSC on E1 links................................. 5
2.2.2.2 TDM synchronization with E1 links supporting HSL ..................................................................... 6
2.3 Removal of HR impact on BSC connectivity................................................................................................. 8
2.3.1 B9 situation ............................................................................................................................................. 8
2.3.2 B10 evolution .......................................................................................................................................... 8
2.4 Up to 500 cells per MX BSC ......................................................................................................................... 9
2.4.1 B9 situation ............................................................................................................................................. 9
2.4.2 B10 evolution .......................................................................................................................................... 9
3 MXBSC PILOT DESCRIPTIONS......................................................................................................................... 10

3.1 Pilot Overall Description ........................................................................................................................... 10
3.2 CMCC China, B10MR1 ................................................................................................................................ 10
3.2.1 Test Plan................................................................................................................................................ 10
3.2.2 Followed Schedule................................................................................................................................. 11
3.2.3 Architecture and Dimensioning aspects ................................................................................................. 12
3.2.4 QoS Follow-up ....................................................................................................................................... 17
3.2.4.1 Phase1 QoS Follow-up .............................................................................................................. 18
3.2.5 Stability Follow-up ................................................................................................................................ 30
3.2.6 End User Impact .................................................................................................................................... 31
3.2.6.1 Voice Quality............................................................................................................................ 31
3.2.6.2 Data Performance Test ............................................................................................................. 33
3.3 T-Mobile, B10MR2...................................................................................................................................... 37
3.3.1 Test Plan................................................................................................................................................ 37
3.3.4 QoS Follow-up ....................................................................................................................................... 38
3.4 Orange France, B10MR2 ............................................................................................................................ 40
3.4.1 Test Plan................................................................................................................................................ 40
3.4.4 QoS Follow-up ....................................................................................................................................... 43
2/84 MX-BSC B10 Improvements – Field Feedback Edition 02 RELEASED 3DF 01907 8010 VAZZA
3.5 Wind Italy, B10 MR2 Ed3 QD8 .................................................................................................................... 46
3.5.1 Test Plan................................................................................................................................................ 46
3.5.4 QoS Follow-up ....................................................................................................................................... 49
1 REFERENCED DOCUMENTS
[1] System Feature Descriptions Reference List Release B10 – 3BK 10251 0003 DPZZA
[2] MX capacity improvements - 3BK 10204 0031 DTZZA
3/84
2 MX BSC IMPROVEMENTS IN B10
This chapter contains extract from the SFD document for MX BSC capacity
improvements [2]. Where more details about each feature can be found.

2.1 1000 TRX MX BSC capacity
2.1.1 B9 situation
In B9 the MX BSC supports up to 600 TRXs with 3 CCP boards in one ATCA shelf;
each CCP board supports up to 200 TRX. The TP GSM board supports the traffic
of these 600 TRXs.
BSS B9 only supports JBXTP (TPGSM V1).
A GPU board of a MFS supports up to 448 TRX. A minimum of two GPU boards is
needed for connection to a MX BSC.
A GP board of a MX MFS supports up to 600 TRX. A minimum of one GP board is
needed for connection to a MX BSC.
2.1.2 B10 evolution
In B10 the capacity of a CCP board is kept unchanged (i.e. it supports up to 200
TRX); the capacity of the MX BSC is extended to 1000 TRX by adding 2 CCP
boards in the ATCA shelf. The TP GSM board supports the traffic of 1000 TRXs.
BSS B10 – from B10MR2 onwards – supports both JBXTP and JBXTP3 (TPGSM V3).
The targeted capacity on the A interface is 4500 Erlangs (4.5 Erlang / TRX) with
the Alcatel traffic model. HSL links support this capacity.
The increase to 4500 Erlangs is supported on both TPGSM V1 and TPGSM V3 in
B10 MR2. In B10 MR1 the limit is 4000 Erlangs with TPGSM V1.
Note: JBXTP3 is ready for STM-1 and IPoE1, but these functions will only be
supported in a later release. For IPoE1 a daughterboard (JAXIP) is needed which
can only be added by upgrade in factory. Nevertheless, note that the Mx BSC
supports only 512 HDLC with TP V1 (441 available for Abis LAPD) and 1024 HDLC
with TP V3 (984 HDLC available for Abis LAPD). HDLC limit is checked at
configuration time.
2.1.2.1 Connection of a SMLC to a BSS
In the current architecture of the BSS, the SMLC is part in the MFS and the
standardized Lb interface between the SMLC and the BSS is not needed.
To support the Lb interface, the MX BSC needs to have a link set with two 64
Kbit/s channels.
In case the HSL is supported for the SS7 connection between the MX BSC and the
MSC, it is not requested to support at the same time LSL for SS7 connection
between a MX BSC and a SMLC.
2.1.2.2 Requirements to connect a MFS to a MX BSC
It is possible to connect a MFS with GPU AB, GPU AC and GP (MX MFS) to a MX
BSC configured with 1000 TRXs.
2.1.2.3 Summary of the requirements for this feature in B10
MX BSC telecom performances requirements:

• The MX BSC support up to 1000 TRX with up to 5 CCP boards
• The MX BSC boards (TP GSM V3 and 5 CCPs) support a traffic of up to
4500 Erlangs (4500 Erlangs for the TP GSM V3 board and 900 Erlangs per
CCP board). The TP GSM V1 supports also up to 4500 Erlangs.
Requirements for a MFS connected to a MX BSC:
• It is possible to connect a GPU AB, a GPU AC and a GP board to a MX BSC

configured with 1000 TRXs.

• A GP board is able to support 4000 cells
2.2 SS7 on High Speed Links (HSL)
2.2.1 B9 situation
The signaling messages exchanged between a MSC and a BSC on the A interface
are transferred with the Signaling System No. 7 (SS7). The Level 2 of SS7 (MTP) is
defined in ITU-T Q.703 and ITU-T Q.704. The subset of MTP functions used by the
BSS is defined in 3GPP TS 48.006.
The MX BSC uses up to sixteen SS7 signaling channels at 64kbit/s on the A
interface. These signaling channels are part of one link set. According to the
ITU-T Q.704 standard, a signaling channel of a link set is addressed with the
Signaling Link Selection (SLS) field, which is a 4 bits field. Therefore in B9 the
maximum number of SS7 signaling channels at 64kbit/s that can be connected to
a BSC with one link set is 16.
The committed capacity on the A interface is 2600 Erlangs.
The load of the SS7 links on the A interface with the B9 traffic model is 55 %
(above the 50 % maximum load allowed by the standard; it is not a problem as
the link set has 16 channels at 64 Kbit/s and if one channel fails, the load
increases of 7%, which is still acceptable).
2.2.2 B10 evolution

SS7 on HSL links can reach 4500 Erlangs on MxBSC with improved capacity.
2.2.2.1 Requirements for supporting ITU variant of HSL in the MX BSC on E1 links
Only E1 links are supported by the Alcatel BSS (T1 links are not supported).
With the B9 configuration of the SS7 signaling channels (i.e. 16 * 64 Kbit/s time
slots) and a traffic of 4500 Erlangs the SS7 load on the A interface will be
unacceptable (close to 100%) and therefore it becomes mandatory to extend the
SS7 signaling capacity on the A interface to overcome this bandwidth limitation.
The capacity can be extended either by using high speed links (HSL) as described
in ITU-T Q.703 Annex A or by using two links set. The choice is to use HSL links
(the HSL links must use E1 framed mode -G.704- aggregating time slots 1 to 31,
allowing a bandwidth of 1.984 Mbit/s). The use of HSL links requires that the
transmission network between the BSC and the MSC ensures the frame integrity
for time slots 1 to 31.
For redundancy purpose, two HSL links will be used and therefore the link set
will be done with these two 1.984 Mbit/s links. The load will be shared between
these two HSL links. When one of the HSL link is out of service, the second HSL
link is able to support all traffic without performances degradations.
In this case the load of the HSL link should not exceed 60%. With traffic of 4500
Erlangs and the B9 traffic model the SS7 load on the A interface should be in this
case about 45%.
5/84
The use of HSL is optional and may be used if this option is supported by the
MSC. It is the choice of the operator to decide whether the HSL links are used.
The HSL can be used on any MX BSC configuration type (whatever the number of
Erlangs supported by the MX BSC). During installation of the network, the
configuration of HSL is done with POLO. When the network is operational, the

switching between the LSL and HSL mode or vice versa is done by an operator

command at the BSC Terminal.
In case HSL is not used, the capacity of the MX BSC is limited to approximately
3000 Erlangs via the overload mechanisms on the A interface. This maximum
number of Erlangs depends in fact of the maximum load on A interface we want
to accept. 3000 Erlangs corresponds to a load of approximately 63 % on the A
interface.
The migration from SS7 link with 16 * 64 Kbit/s time slots to SS7 link with 1.984
Mbit/s links will be done with interruption of service (i.e. the on-going traffic is
lost when the migration is started).
The subset of MTP Level 2 and Level 3 requirements supported by the BSS is
compliant with 3GPP TS 48.006 (Rel-6)
The implementation of MTP Level 2 is compliant with ITU-T Q.703 (white book -
07/96).
The implementation of MTP Level 2 for supporting HSL links is compliant with
ITU-T Q.703 Annex A (white book - 07/96).
The implementation of MTP Level 3 is compliant with ITU-T Q.704 (white book -
07/96).
2.2.2.2 TDM synchronization with E1 links supporting HSL
The E1 links carrying the HSL can be used as any other link for TDM
synchronization.
When enabled, the E1 link(s) carrying the HSL will be assigned the lowest clock
priority among all the enabled Atermux links.
When disabled, the E1 link(s) carrying the HSL will be assigned a clock priority
lower than any other enabled Atermux E1 links.
MX BSC general SS7 configurations requirements:

• The MX BSC support two modes of operation for SS7: HSL and LSL
• The selection of the mode of operation is exclusive (mixed mode are not
allowed)
• When HSL is supported, it is not required to support at the same time
additional LSL links for the Lb interface
• The selection of the mode of operation is done by the operator
• Changing the mode of operation can be done with outage
• The SS7 implementation is compliant with ITU-T Q.703, ITU-T Q.703
Annex A and ITU-T Q.704 (white book - 07/96) and 3GPP TS 48.006 (Rel-
6)
MX BSC HSL configurations requirements:
• The HSL can be used on any MX BSC configuration type (whatever the
number of Erlangs supported by the MX BSC).
• Introduction of HSL (High Speed Signaling Link):
o The HSL links are physically connected on two LIU ports,
corresponding to Atermux CS;
o The Atermux for HSL are directly cabled to MSC;
o These two links will work on load sharing mode, not
active/standby mode.
o Mixed mode (LSL+HSL) is not allowed;

o There is no Qmux configured on the Atermux for HSL
o Any Atermux defined in the BSC configuration could be used to
support HSL.
• The BSC checks that these two Atermux:
o Do not carry Qmux (Atermux 1 and 2, Atermux 7 and 8, …)
o Are configured for CS traffic only,
o Are on two different LIU boards, and each LIU boards must be
available in BSC.
o HSL is always defined on the first Atrunk of the selected
Atermux.
• Feature activation prerequisite conditions
o Parameter in OMC-R - EN_HSL - to activate/deactivate HSL.
o LSL to HSL mode change is possible only if the operator has
cabled direct PCM links between the MSC and the BSC LIU.
o From BSC Terminal
o Step1: Install the high speed links
o Step2: Execute the command “HSL_Activate” giving as input the
Atermux number for HSL
• If HSL is actived, N7 can have 2 different frame formats:
• Normal frame format (MSU contains 6 bytes as fix part + SIF&SIO as
variable part).
• Extended frame format (MSU contains 9 bytes as fix part + SIF&SIO as
variable part).
• Parameter: MTP_Sequence_Number_Format (may be checked in ACIE
AlcatelManagedElementComplex.csv, in field
“MtpSequenceNumberFormat”) Range / default value: (0=Normal,
1=Extended) / 0 .
• The MxBSC is supporting both formats. Extended format may not be used
if HSL is not activated.
• To be checked which format is supported by MSC.
• Note: The CIC numbering scheme defined in ITUT Q.763 is coded on 12-
bits field, permitting to address a maximum of 4096 circuits between
MSC and BSC elements. The BSC Evolution supports CIC-numbers coded
on 16 bits from release B10 onwards. It must be connected to an MSC
also supporting coding on 16 bits, such as the A5060 Spatial Atrium Call
Server (NGN solution from Alcatel-Lucent) in order to address more than
4096 CICs.
MX BSC SS7 configurations requirements for the Chinese market:
7/84
• The HW of the TP GSM V3 is ready to support the Chinese variant of SS7
(MTP2 and MTP3)
MX BSC SS7 configurations requirements for TDM modes:
• The MX BSC support LSL and HSL terminations in the TP GSM in TDM

mode

• The MX BSC support two 1.984 Mbit/s channels for HSL termination
• The MX BSC support sixteen 64 kbit/s channels for LSL termination
Transcoder SS7 configurations requirements for IP modes:
• The transcoder support LSL and HSL SS7 terminations
• The two 1.984 Mbit/s links used for the HSL channels of a MX BSC are
terminated in two different boards
• The sixteen 64 kbit/s links used for the LSL channels of a MX BSC are
terminated at least in two different boards
2.3 Removal of HR impact on BSC connectivity
The requirements for this feature are described in the SFR document [1].
2.3.1 B9 situation
The number of TREs that can be mapped to a CCP board of the MX BSC depends
on the type of TRE (FR or DR).
50 VTCUs are allocated per CCP and per VTCU it is possible to map:
• four FR TREs or
• two DR TREs or
• one DR TREs and two FR TREs
With these rules up to 200 FR TREs can be mapped on a CCP with VTCU handling
FR TREs while only up to 100 DR TREs can be mapped to a CCP with VTCU
handling DR TREs and with mixed FR/DR VTCUs configurations the number of
TREs that can be mapped on a CCP is in between these two values.
Therefore the number of TREs a CCP can handle (i.e. the connectivity of the
CCP) decreases when the number of VTCUs mapped with DR TREs increases.
Furthermore when a CCP board is added on a MX BSC or when a BTS is removed
from a MX BSC, the load is not reshuffled between the boards and therefore it
may happens that some boards are highly loaded while some others are not
loaded.
2.3.2 B10 evolution
The maximum number of TREs mapped to a CCP is independent on whether the

TREs are FR or DR. It is always possible to map up to four TREs (FR and/or DR)
per VTCU, i.e. up to 200 TREs per CCP.
The load on a CCP board is kept at the same level as in B9. For that reason the
maximum number of TCH a CCP can handle is limited to MAX_TCH_PER_CCP. The
PDCHs channels used for PS traffic are not taken into account in the evaluation
of the load. To avoid having unbalanced load between the CCP boards when a
CCP board is added on a MX BSC or when a BTS is removed from a MX BSC, it is
requested to have a “remap-bts-on-ccp” command at the OMC-R to spread the
load between the CCPs boards.
This feature is optional.
This feature is supported by TP GSM V1 and TP GSM V3.
Note: MAX_TCH_PER_CCP is currently set to 1100 but if the load tests of the MX
BSC show that the average load of a CCP is too high with 1100 TCHs sub-channels
active simultaneously, this value could be decreased.
• The “removal of HR impact on BSC connectivity” feature is optional

• For mapping the TREs on a TCU, two mapping rules must always be
supported: The B9 rules and a new B10 rule.
• For an operator who has bought the feature, it is possible to
activate/deactivate the feature from the OMC-R (i.e. it can choose the
mapping rule it wants)
• The maximum number of TREs mapped to a CCP is independent on
whether the TREs are FR or DR. This maximum number is 200.
• It is possible to map up to four TREs on a VTCU independently whether
they are FR or DR.
• The command “remap-bts-on-ccp” is not optional and is supported at
the OMC-R
• It is possible to trigger the command “remap-bts-on-ccp” at any time,
e.g. when a BTS is removed or when a CCP is added. The call can be lost
during BTS remapping.
2.4 Up to 500 cells per MX BSC
2.4.1 B9 situation
A MX BSC supports a maximum of 264 cells.

The number of 2G cells adjacencies supported per MX BSC is 5400.
The number of 2G target cells supported per MX BSC is 3500.
The maximum number of 3G external cells supported per MX BSC is 450.
The maximum number of 3G cells adjacencies supported per MX BSC is 980.
2.4.2 B10 evolution
The capacity is extended to 500 cells for the MX BSC.

The ratio between the number of 2G adjacencies and the number of 2G cells
remains the same as in B9 (i.e. approximately 20 2G adjacencies per 2G cell in
average). Therefore the number of 2G adjacencies to be supported per MX BSC
in B10 is 10300.
The maximum number of 2G target cells supported per MX BSC is 6630.
The maximum number of 3G external cells supported per MX BSC is 850.
This feature is not optional.
This feature is supported by TP GSM V1 and TP GSM V3.
9/84
3 MXBSC PILOT DESCRIPTIONS
3.1 Pilot Overall Description

MXBSC in B10 has been tested in several pilots, and this chapter presents the

results obtained for each feature. The pilots were:
• B10MR1
o CMCC China – 1000TRX with HSL
• B10MR2
o T-Mobile Germany – Removal HR connectivity
o Orange France – Removal HR connectivity
3.2 CMCC China, B10MR1
3.2.1 Test Plan
The test plan for the MXBSC in B10 has been scheduled to reach a higher
configuration in several steps.
One OMCR in B10MR1 has been reserved for this pilot. All BSCs involved in the
pilot are migrated to B10 and cutover to the reserved B10OMCR (FOA OMCR). The
BSCs involved in the project were:
• BSC62_C, 397 TRXs
• BSC62_D, 248 TRXs
• BSC62_A, 191 TRXs
• BSC62_1, 262 TRXs
• BSC62_B – target BSC
The schedule to be used in pilot is presented below:
Move all 45 cells from old BSC62_B to BSC62_1 (this old BSC62_B will be not used
Step 1
anymore)
Step 2 Move MFS530+BSC62_0/C/D/E/F from MXOMCR to B10 FOA OMCR(B10 MR1 Ed02)
Step 3 MFS/BSC/CELL parameters were checked and modified as old value
Step 4 B10FOA OMCR/MFS530 will be migrated from B10 MR1 Ed02 to B10 MR1 Ed03.
BSC62_0/E/F will be migrated from B10 MR1 Ed02 to B10 MR1 Ed03. BSC62_C/D is still as
Step 5
B10 MR1 Ed02.
The new MXBSC62_B with 5CCP/HSL will be linked to MFS530 on B10 FOA OMCR and tested
Step 6
with cases.
Step 7 Move all 72 cells (395TRX) from MXBSC62_C to new MXBSC62_B.
Step 8 1~2 weeks for observation for this new MXBSC62_B with HSL.
Move all 51 cells (243TRX) from MXBSC62_D to new MXBSC62_B, then new MAXBSC62_B
Step 9
will have around 637 TRX.
Step 10 1 week for observation for this new BSC62_B with HSL.
Move 29cells from BSC62_A, and move 6cells from BSC62_1 to newMXBSC62_B, then new
Step 11
MAXBSC62_B will have around 854 TRX.
Step 12 Observation for 1000TRX MXBSC62_B (under MFS530)
During all steps of the pilot the following issues have been continuously
monitored:
• Architecture, in order to be compliant with architecture rules and to be

sure that no issues occurred

• Traffic, to check that the interfaces are correctly planned, to cover the
highest peak traffic
• QoS follow-up, to ensure the impact of this BSC on the final QoS KPIs,
and detect fast any degradation for a quick mitigation of issues
• Stability follow-up, the check how BSC is behavior in such higher
configuration
• End user performances
o Voice Quality – MX BSC impact on CS
o Data Performance Tests – MX BSC impact on PS
3.2.2 Followed Schedule
The below picture presents the actual phases that occurred in the pilot, and
their implementation dates.
TRX Nr. BSC62_C BSC62_D BSC62_A BSC62_1 BSC62_B
Reference 397 248 191 262 0
Phase1 - 248 191 262 391
Phase2 - - 191 262 639
Phase3 - - - 236 898
11/84
As seen in the picture and table, the B10 behavior only started after Phase 2
cutover, after it the number of TRX has exceeded the B9 limitation.

3.2.3 Architecture and Dimensioning aspects

The Architecture and Dimensioning assessment started after 2nd cutover, when
the new MxBSC BSC62_B equipped with 5+1 CCP boards and 2 HSL links was ready
to be used in B10 and the cells of BSC62_C were moved to it.
Based on configuration and traffic of the 4 BSCs involved in the project, a first
estimation of final traffic and configuration of target BSC62_B was done. This
estimation was performed considering that all cells and TRXs of BSC62_1,
BSC62_A and BSC62_D will be moved on target BSC in order to identify the
potential risks. The results are shown in table below.
Network Element Final Number BSC 1000TRX Occupancy

Type Estimated capacity Estimated
BTS 162 255 63.53%
Cell 164 500 32.80%
TRX eq 898 (838FR+30HR) 1000 89.80%
TCH Traffic 1991.39 Erlang 4000 Erlang 49.78%
SCCP Traffic 2404.84 Erlang 4000 Erlang 60.12%
Abis links 165 up to 176 93.75%
ExtraAbisTS 940 up to 2000 41.30%
AterCS links 19 (30 now) up to 46 80.43%
AterPS links 23 (only 18 now) up to 28 82.14%
GP boards 2 (4 now) up to 6 33.33%
From the results of this first estimation the conclusion was that no risk may be
foreseen during the cutover process. The closest to the BSC limits are the final
number of TRXs and the final number of Abis links.
During the cutover steps, the traffic evolution and configuration requirements
were under continuous observation. The configuration evolution may be seen in
the next table.
After first After second After third 2 weeks after

BSC62_B
cutover cutover cutover third cutover
Total nb TRX 405 624 898 818
FR TRX 395 604 838 797
HR TRX 10 20 30 21
Eq TRX 415 644 855 839
ExtraAbisTS 396 687 848 824
Cells 76 129 160 153
BTSs 75 128 159 152
Abis links 75 126 161 154
AterMuxCS 30 (13*) 30 (20*) 30 (28*) 30 (28*)
AterMuxPS 10 18 18 18
GP 2 4 4 4
* (28) Unlocked links (2 AterCs links are used for HSL)

It may be seen that the number of AterMux CS and PS links has been extended
accordingly to the traffic increase. Also the number of GP boards has been
extended to 4.
The traffic evolution during the FO may be followed in the next tables.
BSC62_B
3.06-10.06 10.06-17.06 21.06-29.06 03.07-10.07 08.07-15.07
traffic (BH)
Max Traffic
TCH 568.69 498.22 857.97 1239.56 1206.95
[Erlang]
Max Nb TCH
715 631 1059 1509 1470
needed
Needed Nb
7 6 10 14 13
AterMux CS
Max Traffic
SCCP 699.94 611.33 1030.83 1469.69 1418.77
[Erlang]
Needed Nb
8 7 11 18 17
N7 TS
13/84
It can be seen the need for HSL after last cutover (more than 16 N7 TS needed).

BSC62_B
3.06-10.06 10.06-17.06 21.06-29.06 03.07-10.07 08.07-15.07

traffic (BH)
Max PS
Traffic 694.43 665.47 1070.72 1472.10 1475.17
[Erlang]
Max Nb GCH 849 815 1346 1832 1836
Needed Nb
8 8 13 17 17
AterMux PS
The final status of BSC62_B is shown in table below.
Network Element Needed or existing BSC 1000TRX

Occupancy
Type number or value capacity
BTS 156 255 61.18%
Cell 157 500 31.40%
TRX eq 898 (838FR+30HR) 1000 89.80%
TCH Traffic 1239.56 Erlang 4000 Erlang 30.98%
SCCP Traffic 1469.69 Erlang 4000 Erlang 36.74%
Abis links 158 up to 176 89.77%
ExtraAbisTS 848 up to 2000 42.40%
AterCS links 14 (30 now) up to 46 30.43%
AterPS links 17 (18 now) up to 28 60.71%
GP boards 2 (4 now) up to 6 33.33%
From the last table it may be seen that the final results in terms of load and
connectivity are close to the initial estimation. The highest values (close to the
BSC limits) are the number of the Abis links and the number of FR TRX equipped.
Conclusions regarding dimensioning after last cutover:
• From Traffic point of view the BSC62_B is far from its limits: CS traffic is
1239.56 Erlang and BSC CS capacity is 4000 Erlang
• From connectivity point of view, BSC is more close to the limits: TRX
load is 89.80% (898/1000) and Abis load is 89.77% (158/176)
An important check was related to the number of HDLC used by MCB over Abis
links. The TP GSM board used was V1, and it has max 441 HDLC available.
The method used for HDLC occupancy was to check for each BTS the Mux rule,
the signaling load and the number of FR and HR TRX, to calculate the number of
HDLC used per BTS.
Apply rule
AlcatelBtsSiteManager Total # Total # Total # Total # Total #

UserLabel MuxRate MuxRule
InstanceIdentifier LAPD TRE TRX DR TRX FR HDLC
{ amecID 1, moiRdn 1} G62B011 {signallingLoadBts high} statisticMux64 7 6 6 0 6

{ amecID 1, moiRdn 10} G62B083 {signallingLoadBts high} statisticMux64 4 3 0 3 2
{ amecID 1, moiRdn 100} G62B271 {signallingLoadBts dummy} statisticMux64 5 4 0 4 1
{ amecID 1, moiRdn 134} G62B122 {signallingLoadBts normal} statisticMux64 12 11 0 11 3
{ amecID 1, moiRdn 11} G62B091 {signallingLoadBts dummy} noMux 6 5 0 5 6
{ amecID 1, moiRdn 17} G62A12_3 {signallingLoadBts dummy} staticMux 10 9 0 9 10
from AlcatelBtsSiteManager.csv from AlcatelBts_Sector.csv
The results are shown in table below.
Before 3rd After 3rd

BSC62_B Comment
cutover cutover
Nb of LAPD used from a total of 1750
(for RSL+OML) 751 1028
LAPD available
Nb of HDLC used from a total of 441 HDLC
(for RSL+OML) 351 350
available
Nb of HDLC used from a total of 24 HDLC
(for GSL) 18 18
available
The decrease of HDLC number used after last cutover is due to MUX rule change
to StatisticalMUX64 for all BTSs before cutover.
An additional check was done to evaluate the load distribution between CCP
boards. First step was to identify from ACIE AlcatelLapdLink.csv file the RSL and
OML mapping per VTCU and CCP.
15/84
LAPD type VTCU Id (4325887)
AlcatelLapdLinkInstance
LapdLinkUsage RelatedFunctionList
Identifier
{ amecID 1, moiRdn 250} om {{{ managedElComplexId , 1},{ equipId , 1},{ aFunctionCoordinatorId , 1},{ functionId , 4325887}}}


{ amecID 1, moiRdn 2001} rsl {{{ managedElComplexId , 1},{ equipId , 1},{ aFunctionCoordinatorId , 1},{ functionId , 4325887}}}
LAPD type CCP board (1.4.5)

AlcatelLapdLink
LapdLinkUsage RelatedGSMEquipment
InstanceIdentifier
{ amecID 1, moiRdn 101} rsl {{ equipmentHolderID { ameID { amecID 1, moiRdn 1}, rackRdn 1,shelfRdn 4}, moiRdn 5}}
{ amecID 1, moiRdn 125} om {{ equipmentHolderID { ameID { amecID 1, moiRdn 1}, rackRdn 1,shelfRdn 4}, moiRdn 5}
{ amecID 1, moiRdn 31} gsl {}
Then, cumulating results, the LAPD load was calculated as shown below.
RSL Nb of OML load Nb of LAPD load

CCP board Id Nb of RSL
load[%] OML [%] LAPD [%]
Board 1.4.3 177 88.50% 34 22.67% 211 60.29%
Board 1.4.4 177 88.50% 30 20.00% 207 59.14%
Board 1.4.5 169 84.50% 31 20.67% 200 57.14%
Board 1.4.11 182 91.00% 34 22.67% 216 61.71%
Board 1.4.12 164 82.00% 30 20.00% 194 55.43%
Total 869 86.90% 159 21.20% 1028 58.74%
Next step was to identify in ACIE files the cell mapping per each CCP board, as
shown in picture below.
Cell
RelatedGSMEquipment (CCP) RelatedBtsSector CellGlobalIdentity UserLabel
rackRdn 1,shelfRdn 4, moiRdn 3 {{ bsmID { amecID 1, moiRdn 100}, moiRdn 1}} { lai { mcc 'f460'H, mnc '00'H, lac 6288}, ci 45681} maoqiao_1
rackRdn 1,shelfRdn 4, moiRdn 3 {{ bsmID { amecID 1, moiRdn 105}, moiRdn 1}} { lai { mcc 'f460'H, mnc '00'H, lac 6288}, ci 45715} jiangjingcun_3
rackRdn 1,shelfRdn 4, moiRdn 3 {{ bsmID { amecID 1, moiRdn 111}, moiRdn 1}} { lai { mcc 'f460'H, mnc '00'H, lac 6288}, ci 45907} hanwu_3
from AlcatelLapdLink.csv from AlcatelBts_Sector.csv
Then, cumulating results, the cell mapping per each CCP board was calculated
as shown below.
CCP board Id Nb of Cells
Board 1.4.3 35
Board 1.4.4 30
Board 1.4.5 31
Board 1.4.11 34
Board 1.4.12 30
Total per BSC 160
Then, a cell zone was created for each CCP board. Using the cell zones in NPO,
the related indicators were exported and the traffic per cell zone was
evaluated.
The traffic load per CCP board during busy hour was calculated. The final results
are presented in table below.
CCP board CS Traffic CS Traffic SCCP Traffic SCCP Traffic

TCH Nb TCH load
Id (position) [Erlang] load [Erlang] load
Board 1.4.3 217.1347 24.13% 291 26.45% 275.2770 30.58%
Board 1.4.4 301.4202 33.49% 394 35.82% 348.5094 42.72%
Board 1.4.5 253.0780 28.12% 335 30.45% 302.1752 33.57%
Board 1.4.11 225.0305 25.00% 301 27.36% 270.9613 30.10%
Board 1.4.12 310.9955 34.56% 405 36.82% 360.6743 40.07%
Total per BSC 1307.6589 32.69% 1726 31.38% 1557.5972 38.93%
It may be seen that even there is not exactly the same load on each CCP board,
the load is quite well balanced.
3.2.4 QoS Follow-up
The QoS Follow-up has been done using AnaQoS.NET software, as NPO was not
available in China.
As there were several phases to be followed, different cell zones have been
created and monitored:
Phase1
17/84
The 1st cutover, involved the move of all cells of BSC62_C to BSC62_B. The QoS
has been followed looking on BSC62_C before cutover and BSC62_B after
cutover. (Still B9 behavior)
Phase2

The 2nd cutover, involved the move of all cells of BSC62_D to BSC62_B. The QoS

has been followed looking on BSC62_B and BSC62_D before cutover and BSC62_B
after cutover. (B10 behavior)
Phase3
The 3rd cutover involved the move of all cells of BSC62_A, and some cells of
BSC62_1 to BSC62_B. The QoS has been followed looking on BSC62_B, BSC62_A
and some cells of BSC62_1 before cutover and BSC62_B after cutover. (B10
behavior)
3.2.4.1 Phase1 QoS Follow-up
The 1st phase consists in moving of some cells from one BSC to another, without
any impact to the new MXBSC features. The QoS have been followed in this step,
only to ensure the good behavior of MXBSC, but without any impact about MXBSC
improvements.. The following chart presents the main QoS indicators evolution.
CS QoS
ALC_SDCCH_ASSIGN_CONGESTION
1st cutover ALC_SDCCH_DROP
1800000 10.0%
1st cutover
BSC62_C BSC62_B 10000 0.8%
BSC62_C BSC62_B
9.0%
1600000
9000
0.7%
8.0%
1400000
8000
0.6%
7.0%
1200000 7000
6.0% 0.5%
6000
1000000
Indicator values
Indicator values
5.0%
5000 0.4%
800000
4.0%
4000
0.3%
600000
3.0%
3000
0.2%
400000
2.0%
2000
200000 0.1%
1.0%
1000
0 0.0% 0 0.0%
22/05/2008 24/05/2008 25/05/2008 26/05/2008 27/05/2008 28/05/2008 01/06/2008 02/06/2008 03/06/2008 04/06/2008 05/06/2008 06/06/2008 07/06/2008 22/05/2008 24/05/2008 25/05/2008 26/05/2008 27/05/2008 28/05/2008 01/06/2008 02/06/2008 03/06/2008 04/06/2008 05/06/2008 06/06/2008 07/06/2008
Time Time
Request Congestion Series3 % Congestion Drop - Radio Drop - HO Drop - BSS Series4 % Drop
The SDCCH traffic indicators are not impacted by the cutover.

ALC_CALL_ESTABLISHMENT
ALC_CALL_DROP
1800000
1st cutover 120.0%
1600 1st cutover 0.7%

BSC62_C BSC62_B
1600000 BSC62_C BSC62_B
100.0%
1400
0.6%
1400000
80.0% 1200
0.5%
1200000
1000
60.0%
1000000
Indicator values
0.4%
Indicator values
800
800000
40.0%
0.3%
600
600000
20.0%
0.2%
400
400000
0.0%
0.1%
200000 200
0 -20.0% 0 0.0%
22/05/2008 24/05/2008 25/05/2008 26/05/2008 27/05/2008 28/05/2008 01/06/2008 02/06/2008 03/06/2008 04/06/2008 05/06/2008 06/06/2008 07/06/2008 22/05/2008 24/05/2008 25/05/2008 26/05/2008 27/05/2008 28/05/2008 01/06/2008 02/06/2008 03/06/2008 04/06/2008 05/06/2008 06/06/2008 07/06/2008
Time Time
RTCH Ass Req SDCCH Ass Suc Series3 % Call Setup Suc Drop - Radio Drop - HO Drop BSS Intern Drop - BSS RTC
% RTCH Ass Cong % RTCH fail BSS % RTCH fail Rad %SDCCH drop Rad Preemption Series6 % Call Drop % RTCH drop
The Call setup success rate and call drop rate are stable and not influnced after
the 1st cutover. There was one day before cutover, with higher call drop rate,
but it was not due to the MXBSC (before the pilot BSC have been populated with
cells).
ALC_HO_INC_INTRA_BSC ALC_HO_OUT_INTRA_BSC
350000 1st cutover 14.0% 350000 1st cutover 14.0%
BSC62_C BSC62_B BSC62_C BSC62_B

300000 300000
12.0% 12.0%
250000 250000
10.0% 10.0%
200000 200000
8.0% 8.0%
Indicator values
Indicator values
150000 150000
6.0% 6.0%
100000 100000
4.0% 4.0%
50000 50000
2.0% 2.0%
0 0
22/05/2008 24/05/2008 25/05/2008 26/05/2008 27/05/2008 28/05/2008 01/06/2008 02/06/2008 03/06/2008 04/06/2008 05/06/2008 06/06/2008 07/06/2008 22/05/2008 24/05/2008 25/05/2008 26/05/2008 27/05/2008 28/05/2008 01/06/2008 02/06/2008 03/06/2008 04/06/2008 05/06/2008 06/06/2008 07/06/2008
-50000 0.0% -50000 0.0%

Time Time
Congestion Prep Fail Success Fail - BSS Fail - Radio Series6 % Cong % Fail Prep Fail Success ROC Drop - BSS Drop - Radio Series6 % ROC % Drop
Regarding the intra BSC HO (outgoing and incoming) it was detected a fail
increase just before cutover (the same as for call drop seen before). Apart of
this indicator evolution) not linked with MXBSC behavior, the indicators are
stable (slight improvement detected).
ALC_HO_INC_INTER_BSC ALC_HO_OUT_INTER_BSC
35000
1st cutover 7.0% 90000 1st cutover 6.0%

80000
30000 6.0%
5.0%
70000
25000 5.0%
60000
4.0%
20000 4.0% 50000

Indicator values
Indicator values
40000 3.0%
15000 3.0%
30000
10000 2.0% 2.0%
20000
5000 1.0% 10000
1.0%
0
22/05/2008 24/05/2008 25/05/2008 26/05/2008 27/05/2008 28/05/2008 01/06/2008 02/06/2008 03/06/2008 04/06/2008 05/06/2008 06/06/2008 07/06/2008
0 0.0%
22/05/2008 24/05/2008 25/05/2008 26/05/2008 27/05/2008 28/05/2008 01/06/2008 02/06/2008 03/06/2008 04/06/2008 05/06/2008 06/06/2008 07/06/2008
Time
-10000 0.0%
Time
Congestion Prep Fail No CIC alloc Success Fail - BSS Fail - Radio
Series7 % Cong % Fail Prep Fail Success ROC Drop - BSS Drop - Radio Series6 % ROC % Drop
The interBSC HO (incoming and outgoing) indicators are not impacted by the
cutover.
PS QoS
ALC_UL_TBF_ESTABLISHMENT
ALC_DL_TBF_ESTABLISHMENT 1st cutover
4000000 100.0%
1st cutover BSC62_C BSC62_B
1200000 120.0%
BSC62_C BSC62_B 90.0%

3500000
1000000 100.0% 80.0%
3000000
70.0%
800000 80.0%
2500000
60.0%
Indicator values
Indicator values
2000000 50.0%
600000 60.0%
40.0%
1500000
400000 40.0%
30.0%
1000000
20.0%
200000 20.0%
500000
10.0%
0 0.0% 0 0.0%
22/05/2008 23/05/2008 24/05/2008 25/05/2008 26/05/2008 27/05/2008 28/05/2008 01/06/2008 02/06/2008 03/06/2008 04/06/2008 05/06/2008 06/06/2008 07/06/2008 22/05/2008 23/05/2008 24/05/2008 25/05/2008 26/05/2008 27/05/2008 28/05/2008 01/06/2008 02/06/2008 03/06/2008 04/06/2008 05/06/2008 06/06/2008 07/06/2008
Time Time
DL TBF Request Series2 % TBF Fail Gb % TBF Fail BSS UL TBF Request Series2 % TBF Fail Gb % TBF Fail BSS
% TBF Fail Radio % DL TBF Success % TBF Fail Cong % TBF Fail Radio % UL TBF Success % TBF Fail Cong
The PS traffic is increasing day by day to the last day of QoS monitoring, while
the DL and UL TBF success rate is not impacted.
19/84
ALC_GPRS_DL_RESOURCE_REALLOC ALC_GPRS_UL_RESOURCE_REALLOC
900000
1st cutover 60.0% 900000
1st cutover 80.0%

800000 800000
70.0%
50.0%
700000 700000
60.0%

600000 40.0% 600000
50.0%
500000 500000
Indicator values
Indicator values
30.0% 40.0%
400000 400000
30.0%
300000 20.0% 300000
20.0%
200000 200000
10.0%
10.0%
100000 100000
0 0.0% 0 0.0%
22/05/2008 23/05/2008 24/05/2008 25/05/2008 26/05/2008 27/05/2008 28/05/2008 01/06/2008 02/06/2008 03/06/2008 04/06/2008 05/06/2008 06/06/2008 07/06/2008 22/05/2008 23/05/2008 24/05/2008 25/05/2008 26/05/2008 27/05/2008 28/05/2008 01/06/2008 02/06/2008 03/06/2008 04/06/2008 05/06/2008 06/06/2008 07/06/2008
Time Time
T1 Request T2 Request T3 Request T4 Request Series5 %Success T1 Request T2 Request T3 Request T4 Request Series5 % Success
The traffic increase is more evident for the re-allocation phase. The success
rates are a bit reduced, due to higher re-allocation requests, not due to MXBSC
behavior.
ALC_GPRS_DL_RLC_TRAFFIC_ACK ALC_GPRS_UL_RLC_TRAFFIC_ACK
2500000000 1st cutover 25.0% 600000000 1st cutover 4.5%

4.0%
500000000
2000000000 20.0%
3.5%
400000000 3.0%
1500000000 15.0%
2.5%
Indicator values
Indicator values
300000000
2.0%
1000000000 10.0%
200000000 1.5%
1.0%
500000000 5.0%
100000000
0.5%
0 0.0% 0 0.0%
22/05/2008 23/05/2008 24/05/2008 25/05/2008 26/05/2008 27/05/2008 28/05/2008 01/06/2008 02/06/2008 03/06/2008 04/06/2008 05/06/2008 06/06/2008 07/06/2008 22/05/2008 23/05/2008 24/05/2008 25/05/2008 26/05/2008 27/05/2008 28/05/2008 01/06/2008 02/06/2008 03/06/2008 04/06/2008 05/06/2008 06/06/2008 07/06/2008
Time Time
CSx usef byt MCSx usef byt CSx retr byt MCSx retr byt Series5 CSx retr rate MCSx retr rate CSx usef byt MCSx usef byt CSx retr byt MCSx retr byt Series5 CSx retr rate MCSx retr rate
The retransmission rates in GPRS and EDGE are kept in the same range after the
1st cutover.
Summary QoS
This subchapter presents a summary of the QoS indicators monitored before and
after the 1st cutover.
The values are averaged on the following durations:
• Before 1st cutover: 22.05.2008 – 28.05.2008
• After 1st cutover: 01.06.2008 – 07.06.2008
CS Summary Before 1st cutover After 1st cutover Delta (P1-P0)
% SDCCH Assign Congestion 5.28% 2.88% -2.40%
% SDCCH Assign Fail 5.91% 4.65% -1.26%
% SDCCH Drop 0.64% 0.63% -0.01%
SDCCH Traffic Erl Total 1564 1606 41
RTCH Traffic Erl Total 4914 5669 755
% RTCH Assign Congestion 0.01% 0.05% 0.04%
% RTCH Assign Success 99.08% 99.24% 0.16%
CS Summary Before 1st cutover After 1st cutover Delta (P1-P0)
%Call Setup Suc 98.45% 98.61% 0.17%
% RTCH fail Radio 0.91% 0.69% -0.22%

% Call Drop 0.37% 0.31% -0.06%

% RTCH Drop 0.18% 0.15% -0.03%
% HO Inc Intra Fail 4.70% 2.44% -2.27%
% HO Inc Intra Cong 0.13% 0.40% 0.27%
% HO Inc Intra Success 94.62% 96.83% 2.22%
% HO Out Intra ROC 4.56% 2.27% -2.29%
% HO Out Intra Drop 0.17% 0.18% 0.01%
% HO Out Intra Success 94.62% 96.83% 2.22%
% HO Inc Inter Fail 5.81% 4.54% -1.28%
% HO Inc Inter Cong 0.46% 0.57% 0.11%
% HO Inc Inter Success 93.72% 94.89% 1.18%
% HO Out Inter ROC 3.60% 4.00% 0.40%
% HO Out Inter Drop 0.07% 0.06% -0.01%
% HO Out Inter Success 46.21% 60.92% 14.71%
%HO Better Cell 74.17% 75.43% 1.26%
PS Summary Before 1st cutover After 1st cutover delta

%DL TBF Success 94.52% 96.67% 2.15%
%DL TBF Fail Radio 5.07% 2.92% -2.15%
%UL TBF Success 86.65% 88.51% 1.86%
%UL TBF Fail Radio 12.51% 10.92% -1.58%
%GPRS DL Resource Reallocation Success 53.90% 44.24% -9.66%
%GPRS UL Resource Reallocation Success 69.67% 61.63% -8.03%
% DL TBF Drop 5.47% 3.60% -1.87%
% DL TBF Acc Release 0.63% 0.64% 0.01%
% DL TBF Norm Release 93.90% 95.76% 1.86%
% UL TBF Drop 3.14% 2.05% -1.08%
% UL TBF Acc Release 0.03% 0.03% 0.00%
% UL TBF Norm Release 96.83% 97.92% 1.09%
DL CSx retr rate 3.89% 2.88% -1.00%
DL MCSx retr ratio 17.97% 14.69% -3.29%
UL CSx retr rate 0.75% 0.76% 0.00%
UL MCSx retr rate 3.19% 3.49% 0.30%
st
There is no impact on QoS indicators, brought by the 1 cutover. The MXBSC
behavior after the 1st cutover is still the B9 behavior (as the number of cells and
TRXs are still in B9 limits.
21/84
The 2nd phase was a bit more interesting since it monitors the QoS after the
MXBSC has exceeded the B9 limitations in terms of number of TRX. The following
chart presents the main QoS indicators evolution.

CS QoS

A L C _S D C C H _D R O P
ALC_SDCCH_ASSIGN_CONGESTION 2n d
20000 1.0%
2nd B S C 62_D + B S C 62_B B S C 62_B only

2500000 4.0% 18000 0.9%
BSC62_D + BSC62_B BSC62_B only
3.5% 16000 0.8%
2000000
14000 0.7%
3.0%
Congestion 12000 0.6%

2.5% D rop - B S S
Indicator values
1500000
Request 10000 0.5% D rop - H O
Indicator values
2.0% D rop - R adio

% Congestion 8000 0.4%
1000000
% D rop
1.5%
6000 0.3%
1.0%
4000 0.2%
500000
0.5% 2000 0.1%
0 0.0% 0 0.0%
8
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
8
8
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
7 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
7 /2
6 /2
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
01
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
01
27
Time Tim e
On SDCCH traffic there was no issue detected after the 2nd cutover. It has been noticed a reduction of SDCCH
drop, but after deep analysis it was not find a direct connection with the MXBSC improvements.
ALC_CALL_ESTABLISHMENT ALC_CALL_DROP
2nd 2nd
3000000 120.0% 1800 0.4%
BSC62_D + BSC62_B BSC62_B only BSC62_D + BSC62_B BSC62_B only
1600 0.35%
100.0%
2500000
1400
0.3%
80.0%
2000000 SDCCH Ass Suc 1200 Preemption
0.25%
RTCH Ass Req Drop - BSS RTC
60.0% 1000 Drop BSS Intern
Indicator values
Indicator values
%SDCCH drop Rad

1500000 0.2%
% RTCH fail Rad Drop - HO
800
40.0% Drop - Radio
% RTCH fail BSS
0.15%
% RTCH drop
1000000 % RTCH Ass Cong 600
20.0% % Call Drop
% Call Setup Suc 0.1%
400
500000
0.0%
200 0.05%
0 -20.0% 0 0.0%
8
8
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
7 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
7 /2
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
01
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
01
Time Time
Call setup success rate has been kept a very high level after the 2nd cutover. There were two days with high
call drop rate, but this was due to one cell with Abis problems. The issue has been solved and the call drop
rate recovered.
ALC_HO_INC_INTRA_BSC ALC_HO_OUT_INTRA_BSC
2nd 2nd
450000 3.0% 450000 3.0%
400000 400000
2.5% 2.5%
350000 350000
300000 300000
2.0% Fail - Radio 2.0% Drop - Radio
250000 Fail - BSS 250000 Drop - BSS
Success ROC
Indicator values
Indicator values
200000 1.5% 200000 1.5%

Prep Fail Success
150000
Congestion 150000
Prep Fail
% Fail % Drop
1.0% 1.0%
100000 % Cong 100000 % ROC
50000 50000
0.5% 0.5%
0 0
8
8
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
7 /2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
7/2
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
01
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
01
-50000 0.0% -50000 0.0%

Time Time
Outgoing and incoming interBSC HO success has been kept stable. A slight increase of fail is detected, but the
trend begun before the 2nd cutover.
A L C _H O _IN C _IN T E R _B S C
2n d ALC_HO_OUT_INTER_BSC
1 00000 7.0%
B S C 62_D + B S C 62_B B S C 62_B only 140000
2nd
4.5%
90000 BSC62_D + BSC62_B BSC62_B only

6.0%
4.0%
80000 120000
70000 5.0% F ail- R adio 3.5%

100000
F ail- B S S
60000 Drop - Radio
4.0% S uccess 3.0%
80000
Indicator values
N o C IC alloc Drop - BSS

50000
2.5% ROC
Indicator values
3.0%
P rep F ail
60000
40000
C ongestion Success
2.0%
Prep Fail
30000 % F ail
2.0% 40000 % Drop
% C ong 1.5%
20000 % ROC
1.0% 20000
1.0%
10000
0
0 0.0% 0.5%
8
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
7/2
8
8
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
7 /2
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
01
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
01
Tim e -20000 0.0%
Time
The number of interBSC HO has been reduced after cutover, as it was expected. However in the first three
days the number of interBSC HO has been seriously decreased. The reason is that the cell LAC/CI’s have been
changed during cutover, but the HO relations have not been updated with new values. The issue has been
corrected in the 4th day, and the values recovered to the expected number of requests.
PS QoS
ALC_DL_TBF_ESTABLISHMENT ALC_UL_TBF_ESTABLISHMENT
2nd 2nd
1800000 120.0% 8000000 100.0%

1600000 90.0%
7000000
100.0%
80.0%
1400000
6000000
80.0% 70.0%
1200000
UL TBF Request
DL TBF Request
5000000
60.0%
% TBF Fail Cong
60.0%
% TBF Fail Cong
1000000 % UL TBF Success
Indicator values
Indicator values
% DL TBF Success
4000000 50.0% % TBF Fail Radio
800000
% TBF Fail Radio
40.0%
% TBF Fail BSS 40.0%
% TBF Fail BSS
3000000
600000 % TBF Fail Gb % TBF Fail Gb
20.0% 30.0%
2000000
400000
20.0%
0.0%
200000 1000000
10.0%
0 -20.0% 0 0.0%
8
8
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
7 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
7 /2
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
01
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
01
Time Time
DL and UL TBF Success rate has been kept stable. There was a slight decrease for UL TBF success, generated by
three cells with issue (not linked to MXBSC) After the cells have been corrected, UL TBF success is recovered.
ALC_GPRS_DL_RESOURCE_REALLOC ALC_GPRS_UL_RESOURCE_REALLOC
2nd 2nd
1200000 80.0% 1200000 90.0%

80.0%
70.0%
1000000 1000000
70.0%
60.0%
800000 800000 60.0%

50.0% T4 Request T4 Request
T3 Request 50.0% T3 Request
Indicator values
Indicator values
600000 40.0% T2 Request 600000 T2 Request

40.0%
T1 Request T1 Request
30.0% % Success
%Success
400000 400000 30.0%
20.0%
20.0%
200000 200000
10.0% 10.0%
0 0.0% 0 0.0%
8
8
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
6/2
7/2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
7 /2
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
01
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
01
Time Time
DL and UL reallocation success are slight improved after the 2nd cutover.
23/84
ALC_GPRS_DL_RLC_TRAFFIC_ACK ALC_GPRS_UL_RLC_TRAFFIC_ACK
2nd 2nd
4500000000 20.0% 1200000000 6.0%

4000000000 18.0%
1000000000 5.0%
16.0%
3500000000

14.0%
3000000000 800000000 4.0%
MCSx retr byt MCSx retr byt

12.0% CSx retr byt CSx retr byt
2500000000
Indicator values
Indicator values
10.0%
MCSx usef byt 600000000 3.0%
MCSx usef byt
2000000000 CSx usef byt CSx usef byt
8.0% MCSx retr rate MCSx retr rate
1500000000 CSx retr rate 400000000 2.0% CSx retr rate
6.0%
1000000000
4.0%
200000000 1.0%
500000000 2.0%
0 0.0% 0 0.0%
8
8
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
7 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
7 /2
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
01
12
13
14
15
16
17
18
19
21
22
23
24
25
26
27
28
29
30
01
Time Time
DL and UL retransmission rate in GPRS and in EDGE have been kept at the same
values after cutover.
Summary QoS
after the 2nd cutover.
• Before 2nd cutover: 12.06.2008 – 19.06.2008
• After 2nd cutover: 21.06.2008 – 01.07.2008
Before 2nd After 2nd Delta (P2-
Summary CS
cutover cutover P1)
% SDCCH Assign Congestion 2.37% 2.79% 0.43%
% SDCCH Assign Fail 4.86% 4.66% -0.20%
% SDCCH Drop 0.83% 0.71% -0.12%

SDCCH Traffic [Erl
2583 2517 -66
Total/day]
RTCH Traffic [Erl
10066 10067 1
Total/day]
% RTCH Assign Congestion 0.006% 0.005% 0.00%
% RTCH Assign Success 98.84% 99.58% 0.74%
%Call Setup Suc 98.01% 98.87% 0.86%
% RTCH fail Radio 0.41% 0.41% 0.00%
% Call Drop 0.275% 0.297% 0.02%
% RTCH Drop 0.13% 0.15% 0.02%
% HO Inc Intra Fail 2.12% 2.59% 0.47%
% HO Inc Intra Cong 0.21% 0.19% -0.01%
% HO Inc Intra Success 97.39% 97.00% -0.40%
% HO Out Intra ROC 2.01% 2.47% 0.47%
% HO Out Intra Drop 0.13% 0.13% 0.01%
% HO Out Intra Success 97.39% 97.00% -0.40%
% HO Inc Inter Fail 4.93% 5.80% 0.87%
% HO Inc Inter Cong 0.15% 0.13% -0.02%
% HO Inc Inter Success 94.46% 94.06% -0.41%
Before 2nd After 2nd Delta (P2-
Summary CS
cutover cutover P1)
% HO Out Inter ROC 2.80% 3.34% 0.54%
% HO Out Inter Drop 0.04% 0.06% 0.02%

% HO Out Inter Success 79.31% 70.07% -9.23%
%HO Better Cell 65.25% 64.36% -0.89%
No impact is detected on CS part.

Before 2nd After 2nd
Summary PS delta
cutover cutover
%DL TBF Success 97.14% 97.28% 0.14%
-
%DL TBF Fail Radio 2.74% 2.31%
0.43%
-
%UL TBF Success 87.28% 85.10%
2.19%
%UL TBF Fail Radio 12.18% 14.28% 2.10%
%GPRS DL Resource Reallocation Success 56.07% 61.42% 5.35%
%GPRS UL Resource Reallocation Success 74.31% 77.43% 3.12%
-
% DL TBF Drop 3.47% 3.47%
0.01%
% DL TBF Acc Release 0.53% 0.57% 0.04%
-
% DL TBF Norm Release 96.00% 95.97%
0.03%
-
% UL TBF Drop 1.98% 1.93%
0.05%
-
DL CSx retr rate 3.23% 2.67%
0.56%
-
DL MCSx retr ratio 14.92% 14.67%
0.24%
-
UL CSx retr rate 0.77% 0.73%
0.04%
UL MCSx retr rate 2.92% 3.57% 0.65%
No impact is detected on PS part.
The most interesting and important part were to monitor the QoS after the
MXBSC has reached a significant number of TRX and a significant amount of
traffic. The following chart presents the main QoS indicators evolution.
25/84
CS QoS
A L C _S D C C H _A S S IG N _C O N G E S T IO N A L C _S D C C H _D R O P
3rd cu to ver
3rd cu to ver 80000 3.0%
3500000 5.0% B S C 62_B ,1,A B S C 62_B
B S C 62_B ,1,A B S C 62_B
4.5% 70000
3000000 2.5%

4.0%
60000

2500000 3.5% 2.0%
C ongestion
50000
3.0%
2000000 R equest
Indicator values
D rop - B S S
Indicator values
40000 1.5%
2.5% D rop - H O
% C ongestion
1500000 D rop - R adio
2.0% 30000
1.0% % D rop
1000000 1.5%
20000
1.0%
0.5%
500000 10000
0.5%
0 0.0% 0 0.0%
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
8
08
22 2 0 0
23 2 0 0
24 2 0 0
25 2 0 0
26 2 0 0
27 2 0 0
28 2 0 0
29 2 0 0
30 2 0 0
05 2 0 0
07 2 0 0
09 2 0 0
10 2 0 0
11 2 0 0
12 2 0 0
13 2 0 0
14 2 0 0
15 2 0 0
16 2 0 0
17 2 0 0
0
01 2 0
04 2 0
06 2 0
20
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
2
2
6/
6/
6/
6/
6/
6/
6/
6/
6/
6/
7/
7/
7/
7/
7/
7/
7/
7/
7/
7/
7/
7/
7/
7/
7/
7/
7
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
21
22
23
24
25
26
27
28
29
30
01
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
21
03
08
Tim e Tim e
There is no impact on SDCCH traffic due to MXBSC B10 improvements. There was
a high increase of SDCCH congestion and drop in the 8th of July, due to two cells
(Songyang2 and Songyang3), cells with O&M issues. After the cells have been re-
created in the OMCR, the values have been recovered.
A L C _C A L L _E S T A B L IS H M E N T A L C _C A L L _D R O P
3rd cu to ver 3rd cu to ver
4000000 120.0% 4 50 0 0.8 %
B S C 62_B ,1,A B S C 62_B B S C 62_B ,1,A B S C 62_B
3500000 4 00 0 0.7 %
100.0%
3 50 0
3000000 0.6 %
80.0%
3 00 0
S D C C H A ss S uc P reem ption
2500000 0.5 %
60.0% R T C H A ss R eq D rop - B S S R TC
2 50 0
Indicator values
Indicator values
% S D C C H drop R ad 0.4 % D rop B S S Intern

2000000
2 00 0 D rop - H O
40.0% % R T C H failR ad
1500000 0.3 % D rop - R adio
% R T C H failB S S
1 50 0 % R TC H drop
20.0% % R T C H A ss C ong
1000000 0.2 % % C allD rop
% C allS etup S uc 1 00 0
0.0%
500000 50 0 0.1 %
0 -20.0% 0 0.0 %
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
/0 0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
08
0
2 3 /2 0
2 4 /2 0
25 2 0
2 6 /2 0
2 7 /2 0
2 8 /2 0
2 9 /2 0
3 0 /2 0
0 1 /2 0
0 3 /2 0
0 4 /2 0
0 5 /2 0
0 6 /2 0
07 2 0
0 8 /2 0
0 9 /2 0
1 0 /2 0
1 1 /2 0
1 2 /2 0
1 3 /2 0
1 4 /2 0
1 5 /2 0
1 6 /2 0
1 7 /2 0
20
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
6/
7/
7/
7
6
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
21
22
23
24
25
26
27
28
29
30
01
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
21
22
Tim e Tim e
Call Setup Success and Call drop rate has been kept stable, with 1 day
exceptions (7th of July). In the 7th of July 2 cells (Wushe1 and Wushe2) have had
O&M issues. After the issues have been solved the values have recovered. There
is no impact due to MXBSC B10 improvements.
A L C _H O _IN C _IN T R A _B S C A L C _H O _O U T _IN T R A _B S C
700000 18.0% 7000 00 1 8.0%
16.0% 1 6.0%
600000 6000 00
14.0% 1 4.0%
500000 5000 00
F ail- R adio 1 2.0%

D rop - R adio
12.0%
400000 F ail- B S S 4000 00 D rop - B S S
10.0% S uccess 1 0.0% ROC
Indicator values
Indicator values
300000 P rep F ail 3000 00 S uccess

8.0% C ongestion 8 .0% P rep F ail
200000 % F ail 2000 00 % D rop
6.0% 6 .0%
% C ong % ROC
100000 1000 00
4.0% 4 .0%
0 0
2.0% 2 .0%
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
0
0
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
7
6
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
21
22
23
24
25
26
27
28
29
30
01
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
21
22
23
24
25
26
27
28
29
30
01
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
-100000 0.0% -1000 00 0 .0%

Tim e Tim e
The HO Intra BSC requests have been increased after cutover, as more cells are
belonging now to the same BSC. Despite the request increase the QoS indicators
shows no impact due to cutover. Up to the 7th of July there were some O&M
issues with 2 cells (Wushe1 and Wushe2), but after the correction the values had
recovered.
A L C _H O _IN C _IN T E R _B S C A L C _H O _O U T _IN T E R _B S C
14 000 0 4 5.0% 200 000 5.0%
4 0.0% 4.5%
12 000 0
3 5.0% 150 000 4.0%
10 000 0 F ail- R adio

3 0.0% 3.5%
F ail- B S S D rop - R adio
8 000 0
S uccess D rop - B S S
2 5.0% 100 000 3.0%
Indicator values
N o C IC alloc ROC
Indicator values
2 0.0% P rep F ail 2.5% S uccess
6 000 0
C ongestion P rep F ail
50 000 2.0%
1 5.0% % F ail % D rop
4 000 0
% C ong 1.5% % ROC
1 0.0%
2 000 0 0 1.0%
5 .0%
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
6 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
7 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
8
27 /2 00
05 /2 00
00
22 /2 0
23 /2 0
24 /2 0
25 /2 0
26 /2 0
28 /2 0
29 /2 0
30 /2 0
01 /2 0
03 /2 0
04 /2 0
06 /2 0
07 /2 0
08 /2 0
09 /2 0
10 /2 0
12 /2 0
15 /2 0
17 /2 0
7 /2
7 /2
7 /2
7 /2
7 /2
6
7
/0
/0
/0
21
11
13
14
16
0.5%
0 0 .0%
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
08
0
0
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
-50 000 0.0%
6
7
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
21
22
23
24
25
26
27
28
29
30
01
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
Tim e Tim e
The inter BSC HO request (incoming and outgoing) are reduced, as expected,
due to lower interBSC HO and higher intraBSC HO. In the 7th of July there was an
increase of HO fail, but it was recovered (the same 2 cells: Wushe1 and
Wushe2). After the issue has been corrected, the QoS indicators have been
recovered to the value before
PS QoS
A L C _D L _T B F _E S T A B L IS H M E N T A L C _U L _T B F _E S T A B L IS H M E N T
3rd cu to ver 10000000
3rd cu to ver 100.0%
2500000 120.0%
B S C 62_B 1A B S C 62_B 9000000

B S C 62_B 1A B S C 62_B 90.0%
100.0%
2000000 8000000 80.0%
U L TB F R equest
80.0% D L T B F R equest 7000000 70.0%
% TB F F ailC ong
1500000 % T B F F ailC ong
6000000 60.0% % U L TB F S uccess
Indicator values
% D L T B F S uccess
Indicator values
60.0% % TB F F ailR adio

% T B F F ailR adio 5000000 50.0%
% TB F F ailB S S
1000000 % T B F F ailB S S
4000000 40.0% % TB F F ailG b
40.0% % T B F F ailG b
3000000 30.0%
500000
20.0%
2000000 20.0%
1000000 10.0%
0 0.0%
08
08
08
08
08
08
08
08
08
08
08
08
08
0 0.0%
0
0
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
/2
6 /2 8
6 /2 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
/0 0 8
8
00
00
00
00
6
0 1 /2 0
0 4 /2 0
0 5 /2 0
0 6 /2 0
0 7 /2 0
0 8 /2 0
1 2 /2 0
1 5 /2 0
1 6 /2 0
1 7 /2 0
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
7 /2
7 /2
7 /2
7 /2
7 /2
7 /2
7 /2
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
7
/0
/0
/0
/0
21
23
25
27
29
01
04
06
08
10
12
14
16
21
22
23
24
25
26
27
28
29
30
03
09
10
11
13
14
Tim e
Tim e
There was a traffic increase with the 1st of July (1 day before cutover). The PS
traffic increase could not be explained by the operator, as no end user
promotion has been done at the beginning of July. The QoS indicators have been
kept in the same ranges as before cutover.
27/84
A L C _G P R S _U L _R E S O U R C E _R E A L L O C ALC_GPRS_DL_RESOURCE_REALLOC
3rd
1600000 90.0%
1800000 3rd cutover 70.0%
B S C 62_B 1A B S C 62_B
80.0% 1600000
BSC62_B1A BSC62_B
1400000
60.0%
70.0% 1400000
1200000

50.0%

60.0% 1200000
T4 R equest T4 Request
1000000
Indicator values
40.0% T3 Request
50.0% T3 R equest 1000000
Indicator values
800000 T2 R equest T2 Request

800000
40.0% T1 R equest 30.0% T1 Request
600000 % S uccess 600000

%Success
30.0%
20.0%
400000 400000
20.0%
10.0%
200000
200000 10.0%
0 0.0%
21/06/2008
23/06/2008
25/06/2008
27/06/2008
29/06/2008
01/07/2008
04/07/2008
06/07/2008
08/07/2008
10/07/2008
12/07/2008
14/07/2008
16/07/2008
0 0.0%
8
8
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
00
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
6 /2
7 /2
7 /2
7 /2
7 /2
7 /2
7 /2
7 /2
7 /2
7 /2
7 /2
7 /2
7 /2
7 /2
7 /2
7 /2
7 /2
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
21
22
23
24
25
26
27
28
29
30
01
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
Tim e T im e
The re-allocations are not impacted by MXBSC B10 improvements. Due to PS

traffic increase, the number of re-allocations is increased (noticed also one day
before 3rd cutover). Due to higher request the success is slightly reduced.
A L C _G P R S _D L _R L C _T R A F F IC _A C K A L C _G P R S _U L _R L C _T R A F F IC _A C K
3rd 3rd
6000000000 20.0% 1400000000 6.0%
B S C 62_B 1A B S C 62_B B S C 62_B 1A B S C 62_B

18.0%
1200000000
5000000000 5.0%
16.0%
1000000000
14.0%
4000000000 M C S x retr byt 4.0% M C S x retr byt
12.0% C S x retr byt C S x retr byt

800000000
Ind icator values
Indicator values
M C S x usef byt M C S x usef byt

3000000000 10.0% 3.0%
C S x usef byt C S x usef byt
600000000
8.0% M C S x retr rate M C S x retr rate
2000000000 C S x retr rate 2.0% C S x retr rate

6.0% 400000000
4.0%
1000000000 1.0%
200000000
2.0%
0 0.0% 0 0.0%
/0 08
/0 0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
8
00
/0 0 08
08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
/0 08
08
0
2 5 /2 0
2 6 /2 0
2 7 /2 0
2 8 /2 0
2 9 /2 0
3 0 /2 0
0
0 3 /2 0
0 4 /2 0
0 5 /2 0
0 6 /2 0
0 7 /2 0
0 8 /2 0
0 9 /2 0
1 0 /2 0
1 1 /2 0
1 2 /2 0
1 3 /2 0
1 4 /2 0
1 5 /2 0
0
1 7 /2 0
6 /2
6 /2
6 /2
6 /2
7 /2
7 /2
20
2 4 /2 0
25 20
2 6 /2 0
2 7 /2 0
2 8 /2 0
2 9 /2 0
3 0 /2 0
0 1 /2 0
0 3 /2 0
04 20
0 5 /2 0
0 6 /2 0
0 7 /2 0
0 8 /2 0
0 9 /2 0
1 0 /2 0
1 1 /2 0
1 2 /2 0
1 3 /2 0
1 4 /2 0
1 5 /2 0
1 6 /2 0
1 7 /2 0
20
/2
7
6/
6/
7/
7/
/0
6
7
7
7
7
7
7
7
/0
/0
21
22
23
24
01
16
21
22
23
Tim e
Tim e
The retransmission rate in GPRS and EDGE has been kept at the same level.
Summary QoS
There are no QoS impacts detected due to the higher configuration of MXBSC in
B10MR1.
after the 3rd cutover.
• Before 3rd cutover: 21.06.2008 – 02.07.2008
• After 3rd cutover: 03.07.2008 – 17.07.2008
CS Summary Before 3rd cutover After 3rd cutover Delta (P3-P2)
% SDCCH Assign Congestion 2.14% 2.34% 0.20%
% SDCCH Assign Fail 4.92% 5.57% 0.65%
% SDCCH Drop 0.72% 0.91% 0.19%
SDCCH Traffic Erl Total 3372 3575 204
RTCH Traffic Erl Total 13852 14112 259
% RTCH Assign Congestion 0.02% 0.01% -0.02%
% RTCH Assign Success 99.51% 99.31% -0.20%
CS Summary Before 3rd cutover After 3rd cutover Delta (P3-P2)
%Call Setup Suc 98.79% 98.41% -0.38%
% RTCH fail Radio 0.46% 0.67% 0.20%

% Call Drop 0.34% 0.38% 0.04%
% RTCH Drop 0.17% 0.19% 0.02%
% HO Inc Intra Fail 2.51% 4.86% 2.35%
% HO Inc Intra Cong 0.30% 0.17% -0.13%
% HO Inc Intra Success 96.99% 94.83% -2.16%
% HO Out Intra ROC 2.34% 4.72% 2.38%
% HO Out Intra Drop 0.16% 0.20% 0.04%
% HO Out Intra Success 97.00% 94.79% -2.21%
% HO Inc Inter Fail 5.51% 11.84% 6.33%
% HO Inc Inter Cong 0.22% 0.30% 0.07%
% HO Inc Inter Success 94.25% 87.85% -6.40%
% HO Out Inter ROC 3.53% 3.56% 0.02%
% HO Out Inter Drop 0.06% 0.07% 0.01%
% HO Out Inter Success 70.88% 57.85% -13.03%
%HO Better Cell 56.92% 55.38% -1.53%
No impact is detected on CS part.
PS Summary Before 2nd cutover After 2nd cutover delta

%DL TBF Success 95.88% 97.25% 1.37%
%DL TBF Fail Radio 3.70% 2.32% -1.37%
%UL TBF Success 84.27% 86.27% 2.00%
%UL TBF Fail Radio 15.11% 13.12% -1.98%
%GPRS DL Resource Reallocation Success 58.27% 54.75% -3.51%
%GPRS UL Resource Reallocation Success 75.84% 73.73% -2.11%
% DL TBF Drop 4.12% 3.36% -0.76%
% DL TBF Acc Release 0.61% 0.59% -0.02%
% DL TBF Norm Release 95.27% 96.05% 0.78%
% UL TBF Drop 2.73% 1.99% -0.74%
DL CSx retr rate 3.88% 3.25% -0.63%
DL MCSx retr ratio 15.98% 16.20% 0.22%
UL CSx retr rate 0.78% 0.82% 0.04%
UL MCSx retr rate 3.54% 3.41% -0.13%
No impact is detected on PS part.
29/84
3.2.5 Stability Follow-up
The stability follow-up has been made during all phases of the projects to:
• Detect the possible instability issues due to MXBSC in high configurations
(B10 behavior)

• Assess the instability issues due to O&M interventions or other issues that
MXBSC, on the QoS follow-up of the pilot.
The pilot network was not kept frozen during all phases of the QoS and stability
monitoring. The un-frozen situation has been detected quite easily as the planned
cell unavailability was quite high.
This chapter presents the main stability issues detected during the MXBSC pilot in all
their phases.
As NPO was not installed in CMCC, the LASER in NPO tool was not available.
Therefore the stability issues in this pilot have been analyzed using LASER legacy
tool, by post-processing the alarms file transferred from the OMCR.
Unfortunately the LASER file for the period before the 1st cutover could not be
retrieved in time, and they are not included in this analysis.
The main stability indicators followed for the BSC62_B are presented in the next
table:
After 1st After2nd After3rd After3rd
BSC62_B cutover cutover Cutover Cutover
13.06-19.06 21.06-27.06 03.07-06.07 07-07-13.07
Cell Unavailability 0.22% 0.10% 0.76% 1.60%
GPRS planned unavailability 50.00% 49.05% 50.17% 44.39%
GPRS unplanned unavailability 0.00% 0.00% 0.00% 0.44%
Total number of alarms / day /
TRX 7.68 4.3 3.84 3.08
The above table is to be seen only as stability of the impacted BSC involved in pilot
(BSC62_B), but in each phase there are more TRX than previous phase.
The stability evolution before and after the 2nd and the 3rd cutover, are analyzed next
(the same amount of TRX before and after cutover)
2nd Cutover
The below table is showing the stability results for BSC 62_B and BSC62_D before
the 2nd cutover, and the stability results for BSC62_B (after BSC62_D cells have
been moved to pilot BSC).
BSC62_B and BSC62_D BSC62_B
2nd cutover
Cell Availability 99.78% 100.00%

GPRS availability 50.00% 50.95%
Alarms/day 7.68 4.30
BSC-TRANS [101] RAI [5]: for 1 Abis RX-TX [10] ANTENNA-VSWR-WARNING [11]
BSC-TRANS [101] LIS [0]: 1 day for 1 Abis RX-TX [10] ANTENNA-VSWR-WARNING [11]
Main Alarms TRUNK [36] AIS [4] BSC-TRANS [101] RAI [5]
There are no stability issues found due to MXBSC in B10.

3rd Cutover
The below table is showing the stability indicators for BSC 62_B, BSC62_1 and
BSC62_A, before the 3rd cutover, and the stability results for BSC62_B (after all cells
of BSC62_A and 6 cells from BSC62_1 have been moved to pilot BSC).
BSC62_B BSC62_B
Cell Availability 100.00% 99.24%
GPRS availability 50.95% 49.93%
Alarms/day 4.30 3.84
GPU board has lost Ethernet link component 1 (a GPU not

RX-TX [10] ANTENNA-VSWR-WARNING [11]
linked to BSC62_B)
Main Alarms RX-TX [10] ANTENNA-VSWR-WARNING [11]
RX-TX [10] ANTENNA-VSWR-WARNING [11]
BSC-TRANS [101] RAI [5]
BSC-TRANS [101] LFA [2]
BSC62_A
Cell Availability 99.87%
3rd cutover
GPRS availability 100.00%
Alarms/day 0.77
TSC-TRUNK [66] BER-10E-6 [102]
BSS BVCSig of this GPU is broken
Main Alarms component 0
BSS BVCSig of this GPU is broken - Not
secured - component 0
BSC62_1
Cell Availability 98.11%
GPRS availability 55.48%
Alarms/day 0.50
TSC-TRUNK [66] BER-10E-6 [102]

Main Alarms RX-TX [10] ANTENNA-VSWR-WARNING [11]
CELL [43] LOSS-OF-SDCCH [1]
There are no stability issues found due to MXBSC in B10.

The main outcome of stability audit is that there were no stability issues added by
the MXBSC in high configurations.
3.2.6 End User Impact
The behavior of MXBSC in high configuration (B10 case) was checked from the
end-user point of view. In order to assess these performances both voice quality
measurements and data performance tests have been performed in different
phases of the pilot.
3.2.6.1 Voice Quality
The Voice Quality has been assessed only after the 3rd cutover, after the BSC had a
significant number of TRXs.
31/84
The measurements have been done in the same area before and after the 3rd
cutover, as shown in the below picture:
BSC62_B
(MXBSC)
BSC62_A

BTS
VQ measurement Area
Before 3rd Cutover
BSC62_B
(MXBSC)
BTS
VQ measurement Area
After 3rd Cutover
The Voice quality measurements performed were done for all speech codecs
available within CMCC network: EFR, FR and HR. AMR was not activated in the pilot
area.
The codecs have been measured both in static and mobility conditions.
In the following table the different ranges of the PESQ/MOS and corresponding
classification are presented.
PACE_TA
Speech Quality Speech
From To Sample
Excellent 5 3.5
Excellent
Sample.wav
Good 3.5 2.7

Good Sample.wav
Fair 2.7 2.1

Fair Sample.wav
Poor 2.1 1.5

Poor Sample.wav
Bad 1.5 1
Bad Sample.wav
The below plots, shows the VQ results obtained before and after the 3rd cutover for
both UL and DL paths.
MXBSC Pilot Voice Quality DL

4.00
3.50
3.00
2.50
2.00
Before
1.50 After
1.00
0.50
0.00
EFR FR HR EFR FR
Static Mobility
MXBSC Pilot Voice Quality UL
4.00
3.50
3.00
2.50
2.00
Before
1.50
After
1.00
0.50
0.00
EFR FR HR EFR FR
Static Mobility
It can be clearly seen that there is no impact, on Voice Quality, brought by the
MXBSC in B10 software release.
3.2.6.2 Data Performance Test
The Data Performance Tests were done to check the impact brought by the MXBSC
in high configurations to the PS traffic.
The tests consist in measuring for one cell, in each phase of the pilot, several
transfers at application level:
• PING tests (to test the network reactivity)
• FTP UL and DL
The same cell has been measured, and for an easy reference the period have been
named:
• Reference – for the period before the 1st cutover (while the cell was
belonging to another BSC
• Phase 1 – the phase between the 1st cutover and the 2nd cutover
• Phase 2 – the phase between the 2nd cutover and the 3rd cutover
33/84
• Phase 3 – the phase after the 3rd cutover
Reference Phase 1 Phase 2 Phase 3

BSC62_B BSC62_B BSC62_B
(MXBSC) (MXBSC) (MXBSC)
BSC62_A
CI=47185 CI=47185 CI=47185 CI=47185
PS measurement PS measurement PS measurement PS measurement

Area Area Area Area
1st cutover 2nd cutover 3rd cutover
The tests have been done using 3 different configuration settings: EDGE, CS3/CS4
and CS1/CS2.
A brief explanation of the test plans followed is presented below:
CS1/CS2 Test Plan
CMCC
CS1/CS2 Test Plan Size Iterations MS Tools
FTP DL 200 kB 20
DEUTRIP 3.2.8.3
FTP UL 100 kB 20
32B 0sec 101 OT290
PING (small)
32B 5sec 101
1460B 0sec 101
PING (big)
1460B 5sec 101
Parameters
MAX_GPRS_CS CS2
MAX_EGPRS_MCS MCS9
EN_EGPRS disable
INI_CS CS2
INI_MCS MCS3
EN_FAST_INITIAL_GPRS_ACCESS enable
CS3/CS4 Test Plan

CMCC
Radio
CS3/CS4 Size Iterations Conditions MS Tools
FTP DL 500 kB 20 Good OT290
DEUTRIP
3.2.8.3
FTP UL 200 kB 20
32B 0sec 101

PING (small) 32B 5sec 101
1460B 0sec 101
PING (big) 1460B 5sec 101
Parameters
MAX_GPRS_CS CS4
MAX_EGPRS_MCS MCS9
EN_EGPRS enable
INI_CS CS3
INI_MCS MCS3
EDGE Test Plan

CMCC
Radio
EDGE Size Iterations conditions MS Tools
DEUTRIP 3.2.8.3
FTP DL 2 MB 20
FTP UL 1 MB 20
32B 0sec 101 Good N73
PING (small) 32B 5sec 101
1460B 0sec 101
PING (big) 1460B 5sec 101
Parameters
MAX_GPRS_CS CS4
MAX_EGPRS_MCS MCS9
EN_EGPRS enable
INI_CS CS3
INI_MCS MCS6
The results obtained in al the phases are presented in the next table:
Pause between
Transfer type transfers [s] Reference Phase1 Phase2 Phase3 Unit
CS1/CS2
Ping32 0 565.98 576.86 587.84 579.5 ms
Ping32 5 837.07 827.56 865.55 844.54 ms
Ping1460 0 2262.39 2243.78 2284.23 2274.2 ms
Ping1460 5 2601.91 2618.96 2720.32 2540.7 ms
FTP UL - 10.48 10.4 10.24 10.64 kbps
FTP DL - 30.24 29.92 30.32 29.84 kbps

CS3/CS4
Ping32 0 542.04 569.61 590.82 566.17 ms
Ping32 5 789.86 796.45 828.6 798.45 ms
Ping1460 0 2018.71 2000.56 2035.75 2015.1 ms
Ping1460 5 2389.13 2358.9 2461.15 2312.7 ms
FTP UL - 16.72 16.8 16.8 17.04 kbps
35/84
Pause between
Transfer type transfers [s] Reference Phase1 Phase2 Phase3 Unit
FTP DL - 51.44 51.28 50.72 50.8 kbps
EDGE

Ping32 0 214.44 204.05 213.58 201.33 ms
Ping32 5 648.25 636.09 685.64 662.02 ms
Ping1460 0 567.37 524.22 565.76 498.81 ms
Ping1460 5 1321.3 1289.06 1328.98 1278.1 ms
FTP UL - 93.36 96.32 92.32 96.16 kbps
FTP DL - 207.12 207.84 205.84 202.64 kbps
From the above table it can be seen that the MXBSC brings no impact on the PS
performances in the pilot area. There are some fluctuations form one phase to
another, but these fluctuations are rather small and they are specific to the GSM
network behavior.
3.3 T-Mobile, B10MR2
As 1000TRX feature was not tested on T-Mobile B10 First-off, only the Optimized
HR Connectivity was tested.
3.3.1 Test Plan
The test plan for Optimized HR Connectivity (OHRC) in T-Mobile was planned to
reach 4 DR TRX in one VTCU. Without this feature, one VTCU can handle up to 2
DR TRX at maximum.
The data to follow-up should this one:
• BSC Reports from AMT.NET
• CCP Resource Usage Report from OMC-R
• TCH_block_BSC_cong indicator from NPO
• EN_4_DR_TRE_PER_TCU parameter from NPO
This data should be collected at a daily basis two weeks before (reference
period) and 2 weeks after (observation period) the feature activation.
This was the test plan for T-Mobile FO regarding the OHRC feature:
Operation Description Date Status
Step 1 Enable one DR TRX per cell W820, 13/May, 0am-5am Done
Step 2 Enable the feature W820, 15/May, 0am-5am Done
Step 3 Enable DR TRX for all the cells W821, 19/May, 0am-5am Done
Step 4 Decrease HR threshold trigger W821, 21/May, 0am-5am Done
Deactivate the feature, HR and

Step 5 W821, 28/May, 0am-5am Done
AMR
The involved MX-BSC was Stuttgart163_K which had 126 FR TRXs.
There is no limitation to enable this feature, the requirement is to have a MX-BSC.

The gain on the architecture after activate the feature is to have the same TRXeq
even if we declare more DR TRX on the BSC. The CCP Occupancy will also
decrease after the feature activation.
37/84
The TRXeq on Stuttgart163_K before feature activation was 31.5%. At the time,
there were 126 TRXs and all were declared as Full Rate (FR).

After the feature activation and declaration of DR TRXs, the TRXeq kept the same
thanks to the feature.
Without the feature, the TRXeq Load become 50,75% ((49+2*77) / 400). If there
was only one CCP (max of 200 TRX) without OHRC, this configuration leads to 203
TRXeq which can not be supported by only one CCP, then we save one CCP with this
feature. The TREeq is normalized to FR TRX.
In T-Mobile FO, the CCP Resource Usage report was not checked.
3.3.4 QoS Follow-up
The main GSM and GPRS KPIs kept stable after the feature activation. No
congestion at CCP level was observed after feature activation.
The impact of these steps was observed mainly on speech version allocations. You
can see the evolution of the related indicators in the next pictures.
The lower penetration of HR calls was due to low traffic load on BTSs. Only after the
step 4, we notice a considerable HR penetration, anyway, 4 DR RSLs were never
allocated in only one VTCU. To have this behavior, more load was needed on the
BSC. 4 RSLs on one VTCU was detected on Orange first-off and more details can
be found on the next chapter.
39/84
3.4 Orange France, B10MR2
As 1000TRX feature was not tested on Orange B10 First-off, only the Optimized

HR Connectivity was tested.

3.4.1 Test Plan
The test plan for Optimized HR Connectivity (OHRC) in Orange was planned to
reach 4 DR TRX in one VTCU. This configuration can be found at ACIE files.
This was the test plan for Orange FO regarding the OHRC feature:
The concerned MX-BSC was Neudorf10 which had 343 TRXs (268 FR and 75 DR).
Neudorf10 had at the time 3 CCPs which brings a capacity of 600 DR TRXs if
OHRC is activated.
In the next picture it is presented the configuration of this BSC at step 0.
At step 2, 214 TRX were declared as Dual Rate and the configuration become the
following one:
As you can see, the TRXeq Load decreased thanks to feature activation, it was
reduced from 69.67% (268 + 2* 75 / 600) to 57.16% (55+288 / 600). There is no
more impact on HR at BSC level if OHRC is enable.
The essential check of this feature was detected on ACIE file AlcatelLapdLink.csv
where it was reported 4 DR TRXs in one single VTCU, more details are shown in the
next table.
This configuration can not be possible without this feature.
41/84
The CCP Occupancy decreased as well after the feature activation. After feature
activation, the CCP Occupancy goes from 71.66% down to 59% (delta of 12.66).
The CCP configuration can be seen in the next tables.

CCP Occupancy before Feature Activation

CCP Occupancy after Feature Activation
At step 3, cells from Neudorf8 were moved to Neudorf10 carrying 157 TRXs. As
expected, the CCP Occupancy increased and this time went up to 85.16% as you
can see in the next table.
CCP Occupancy after Step 3 (Neuforf8-Neudorf10 move)
Without the feature, the TRXeq will be 817 TRXeq (205 + 306*2), which is not
possible with only 3 CCPs. Each CCP can handle up to 200 TRXs / 1100 TCH.
With the feature enable, the TRXeq is 511 and we save 2 CCP boards.
The feature was completely tested and validated successfully on Orange B10 First-
off.
3.4.4 QoS Follow-up
The main GSM and GPRS KPIs kept stable after the feature activation.
No TCH failures due to CCP Congestion were observed and the maximum
measured RTCH Traffic was 754.9 Erl.

In the next pages it is presented the evolution about some main indicators with
comments.
GSM Traffic kept stable after the feature activation and the declaration of 214 DR
TREs.
Call Success rate kept stable after feature activation.
43/84
On GPRS part, there was a DL TBF success rate degradation due to few cells
impacted by radio failures but this is a specific issue and it is not related with this
feature.
The UL TBF success rate kept stable after the feature activation.
(E)GPRS DL Traffic kept stable after the feature activation and the declaration of 214
DR TREs.
45/84
3.5 Wind Italy, B10 MR2 Ed3 QD8

WIND Italy was a First-off customer to test the new board named TPGSM v3 also

known as TPv3. The preparation and results will be presented along this chapter.
The pilot area was near the city of Bari and the pilot MX-BSC was BA12.
3.5.1 Test Plan
The goal of this First-off was to check that the introduction of TPv3 doesn’t
provoke any regression regarding the Quality of Service of the network. The data
checked was the main KPIs of GSM, (E)GPRS, Stability and Unavailability. Some
TPv3 customer reports were also created to follow-up the indicators strictly
related with TPv3.
The NPO Reports used to follow-up the QoS were:
• Alc Mono Call
• Alc Mono GPRS Telecom
• Alc Mono HO
• OPERATIONAL
• AVAILABILITY
• TPv3 Optim BSC Connectivity
• TPv3 Busy Hours
• TPv3 N7
• TPv3 A Ater
• TPv3 CS
• TPv3 PS
A dimensioning assessment and follow-up was made in order to check if the

resources satisfy the correct performance and capacity of the TPv3 board.
To make the dimensioning assessment, the tools AMT.NET and Excel Dimensioning
Template were used.
Finally, the last objective was to reach more capacity than the older TP board
(441 HDLCs). To reach this target, cells from 3 G2 BSCs (BA2, BA3 and BA5) were
moved to BA12 (pilot MX-BSC for the TPv3 FO) and some tuning operations were
done to increase the number of busy HDLCs.
More details regarding this part can be seen on chapter “3.5.3 Architecture and
Dimensioning aspects”.
These were the actions taken by Wind and ALU to reach the objectives of this
FO. The FO campaign period was from mid-December 2008 till the end of March
2009.
Date Action Status
30 Oct (W844) BA03 migration to B10 MR2 ED3 QD6 Done

9 Dec (W850) Install Patch B10 MR2 ED3 QD8 (0068) Done
12 Dec (W850) Replace TP on BA12 (MX-BSC) Done

12 Jan (W903) Install Patch B10 MR2 ED3 QD8 (006F) Done
19 Jan (W903) Add 2 CCP Done
22 Jan (W904) Move BA02BSC step 1 Done

9 Feb (W907) Activate “HR Removal from BSC” on BA12 Done
3 Mar (W910) Move BA03BSC step 2 Done

26 Mar (W914) Increase HDLC used to 460 Done
The main actions were the replacement of TP board on 12/Dec and the increase
of busy HDLCs to 460 on 21/Mar.
To increase the capacity of the MX-BSC, 2 more CCPs were added on 19/Jan in
order to get 5 CCPs (1000TRX) and the feature “HR Removal from BSC” was
activated on 9/Feb to unblock the HR limitation on BSC side, otherwise it is
impossible to reach 460 HDLCs.
All the BTS moves from G2 BSC to the MX-BSC were divided into 2 steps,
normally half number of the cells were moved on each step.
In the following tables we can see the initial and final configuration of BA12.
47/84
INITIAL CONFIGURATION
BSC NAME BA12BSC

BSC CONFIGURATION 3 CCP

NBR BTS 24
NBR CELL 74
NBR TRX 139
NBR TRX DR 79
NBR HDLC Used 87
MFS NAME BA02MFS
MFS TYPE A9130 MFS MX (1 GP)
FINAL CONFIGURATION
BSC NAME BA12BSC
BSC CONFIGURATION 5 CCP
NBR BTS 107
NBR CELL 359
NBR TRX 803
NBR TRX DR 396
NBR HDLC Used 460
MFS NAME BA02MFS
MFS TYPE A9130 MFS MX (2 GP)
At the end of the moves, BA12 grow to 803 TRXs and 359 cells with 460 HDLCs
which are more than 441 and consequently, the target number was reached.
There was also an increase of one GP connected to this MX-BSC in order to
handle the (E)GPRS Traffic because a big increase was expected with the
introduction of 335 new cells.
CCP Occupation Evolution
MX-BSC BA12 Initial * + BA02 + BA03 step 1 HR removal Final

CCP Occupancy 36.33% 57.29% 88.80% 60.90% 80.30%
FR RSL 60 209 314 314 407
DR RSL 79 182 287 287 396
Used RSL 218 573 888 601 803
Free RSL 382 427 112 399 197
* - On the initial configuration it was present only 3 CCPs, in the next step
there were 5 CCPs available.
Once “Removal of HR impact on BSC connectivity“ was enabled, the numbers of
Used RSL and the CCP Occupancy were reduced because Full Rate and Dual Rate
TRXs were handled in the same way in the BSC.
HDLC Evolution
MX-BSC BA12 Initial * + BA02 + BA03 + BA05 Tuning

Used HDLCs 87 187 295 398 460
Free HDLCs 897 797 689 586 524
At the final move of BA05, the total number of used HDLCs was not enough to
cover 441, then some tuning operations were done and the target was
accomplished.
The operations were to change some Abis signalling sub-multiplexing schemes
from Statistical Signalling Multiplexing 64k to Static Signalling Multiplexing
and to declare some FR TRXs as DR TRXs. The static signalling multiplexing does
not support DR TRXs, therefore it should be applied on Abis/BTSs with FR TRXs
only.
After these tuning operations, we get 460 busy HDLCs and the FO reaches his
end. There was no issue when the busy HDLCs were greater than 441. Regarding
the QoS evolution you can see the following chapter.
3.5.4 QoS Follow-up
On this chapter we will see the QoS and Stability evolution after the TPv3
Introduction and the TPv3 High Load state.
Looking to these charts we can see if there were degradations on QoS or
Stability and if there was a significant variation it will be explained using text
boxes.
For both operations, the reference and observation period was 1 week.
TPv3 Introduction phase
Reference Period: 5-Dec / 10-Dec 2008 (1 Week)

Observation Period: 13-Dec / 18-Dec 2008 (1 Week)
TPv3 Introduction: 12-Dec
GSM Main KPIs
The following graphs show stable values of the related GSM QoS Indicators after
the TPv3 Introduction (TP Replacement). When there is a variation, it is
explained using text boxes and comments to describe the impacted cells and
issues.
49/84
SDCCH Assign Congestion - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To
2008/12/18 (Working Zone: Global - Medium)
800000 TP 3,0%
BA180G1-G2- BA234G1
Replacement

700000
2,5%
600000
2,0%
500000
Congestion
nb
%
400000 1,5% Request
% Congestion
300000
1,0%
200000
0,5%
100000
0 0,0%
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
There was some SDCCH congestion observed after the TP replacement but it was
only on 3 cells: BA180G1, BA180G2 and BA234G1. This issue was not related with
the new TP board introduction.
SDCCH assignment failure - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To

TP Zone: Global - Medium)
2008/12/18 (Working
BA189D1/D2/D3 Replacement
700000 8,% BA196G1/G2/G3

600000 7,% BA237G1/G2
500000 6,%
400000 5,% Fail - BSS

Fail - Radio
nb
300000 4,%
Success
200000 3,% % Fail
100000 2,%
0 1,%
-100000 ,%
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
Some radio SDCCH drops were noticed in some few cells but not related with
TPv3.
SDCCH Drop - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To 2008/12/18 (Working
Zone: Global - Medium)
TP
5000 Replacement 0,9%
4500 0,8%
4000
0,7%
3500
0,6%
3000 Drop - BSS
0,5%
Drop - HO
nb
%
2500
0,4% Drop - Radio
2000 % Drop
0,3%
1500
0,2%
1000
500 0,1%
0 0,%
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
No abnormal variation was noticed on SDCCH Drop causes except the radio as
explained before.
SDCCH Traffic - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To 2008/12/18 (Working

TP
Replacement
680 3,82
3,8
660
3,78
640
3,76
620 3,74 SDCCH Erlang

nb
3,72 SDCCH Avg Duration

600
3,7
580
3,68
560
3,66
540 3,64
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
The SDCCH Traffic kept stable after the TPv3 Introduction.
51/84
RTCH assign execution - BSC: BA12BSC
TP ( BA12BSC ) - 2008/12/05 To 2008/12/18
(WorkingReplacement
250000 0,8%

0,7%
200000
0,6%
150000
0,5% Exe Fail BSS
Fail Radio
nb
%
100000 0,4% Success
% Exe Fail BSS
0,3% % Fail Radio
50000
0,2%
0
0,1%
-50000 0,%
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
RTCH Assignment execution KPIs kept stable after the TPv3 Introduction.
RTCH Assign Congestion - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To

TP
250000 Replacement BA196D2 0,7%
0,6%
200000
0,5%
150000
0,4% Congestion
nb
Request
0,3% % Congestion
100000
0,2%
50000
0,1%
0 0,0%
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
There was a little occurrence of RTCH Congestion but was verified only on cell
BA196D2. This issue was not linked with TPv3.
Call success - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To 2008/12/18 (Working
Zone:TPGlobal - Medium)
Replacement
BA196D2 BA234G1
12000 100,%
98,%
10000
96,%
Assign Unsucc
94,%
8000 Call drop
92,%
SDCCH drop
nb
%
6000 90,%
% End to End Call setup
88,%
4000 % Call success
86,%
% Call setup
84,%
2000
82,%
0 80,%
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
2 cells: BA196D2 and BA234G1 had an increase of RTCH assignment failures but
this issue was solved after a lock/unlock RSL and it was not related with TPv3.
Call drop - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To 2008/12/18 (Working Zone:

Global - Medium)
TP
1,2%
2500
1,% Drop - BSS RTC

2000
Drop BSS Intern
,8% Preemption
nb
1500 Drop - HO
,6% Drop - Radio
% RTCH Drop
1000
,4% % Call Drop
500
,2%
0 ,%
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
The KPIs regarding Call Drop kept stable after TPv3 Introduction.
53/84
RTCH Traffic - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To 2008/12/18 (Working
TP
Replacement
5000 32,5

4500 32
4000
31,5
3500
31
3000
30,5
RTCH Erlang
nb
%
2500
30 RTCH Avg Duration
2000
29,5
1500
29
1000
500 28,5
0 28
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
The RTCH Traffic kept stable after the TPv3 Introduction.
Handover KPIs
Incoming Inter BSC handovers - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To

TP
30000 14,0%
12,0% Prep Fail

25000
Fail - BSS
10,0% Fail - Radio
20000
Congestion
nb
8,0%
No CIC alloc
15000
6,0% Success
% Fail
10000
4,0% % Cong
5000 2,0%
0 0,0%
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
The incoming inter BSC HOs KPIs kept stable after TPv3 Introduction.
Incoming Intra BSC handovers - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To
TP
Replacement
BA196D2
300000 6,%
250000
5,%
200000 Prep Fail

4,%
Fail - BSS
150000 Fail - Radio
nb
%
3,% Congestion
100000 Success
% Fail
2,%
50000 % Cong
1,%
0
-50000 ,%
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
The Congestion observed on BA196D2 had an impact also on HOs but after 5
days, the problem was solved. Issue not related with TPv3.
Outgoing Inter BSC handovers TP

- BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To
Replacement
30000 12,%
25000
10,%
20000 Prep Fail

8,%
Drop - BSS
15000 Drop - Radio
nb
6,% ROC
10000 Success
% Drop
4,%
5000 % ROC
2,%
0
-5000 ,%
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
The outgoing inter BSC HOs KPIs kept stable after TPv3 Introduction.
55/84
Outgoing Intra BSC handovers - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To
TP
Replacement BA196 BA153 BA152
300000 2,5%

250000
2,%
200000 Prep Fail
Drop - BSS
1,5%
150000 Drop - Radio
nb
%
ROC
100000 Success
1,%
% Drop
50000 % ROC
,5%
0
-50000 ,%
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
Failures on outgoing intra HO were detected on cells from 3 BTSs: BA196, BA153
and BA152. This issue was solved after 5 days and was not linked with TPv3.
Handover Causes - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To 2008/12/18

(WorkingTP
Replacement
100% 50000
90% 45000
% Interference
80% 40000 % DL Quality
70% 35000 % HO Distance
% UL Quality
60% 30000
% UL Level
nb
%
50% 25000 % DL Level

% Better Cell
40% 20000
Traffic
30% 15000 DR Forced
20% 10000 Microcell

Pref Band
10% 5000
0% 0
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
The HO causes kept stable after TPv3 introduction.
(E)GPRS Main KPIs
No significant variations were observed after the TPv3 Introduction regarding the
GPRS and EGDE main KPIs.
Downlink Data Transfer - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To 2008/12/18

(Working Zone: Global - Medium)
TP
Replacement
350000 120,%
340000 100,% Realloc drop

Radio drop
330000 80,% Blocking drop
Stagnat drop
nb
%
320000 60,% BSS drop
Gb drop
310000 40,% Estab Success
% Acc Release
300000 20,% % Norm Release
290000 ,%
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
Uplink Data Transfer - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To 2008/12/18

TP
Replacement
900000 120,%
800000
100,% Realloc drop
700000
Radio drop
600000 80,% Blocking drop
500000 Stagnat drop

nb
60,% BSS drop

400000 Gb drop
300000 40,% Estab Success
% Norm Release
200000
20,% % Acc Release
100000
0 0,%
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
57/84
DL TBF Acceptable Release causes - BSC: BA12BSC ( BA12BSC ) - 2008/12/01 To 2008/12/18 (Working
TP
Replacement
3500 1,%

0,9%

3000
0,8%
2500 0,7%
NC0 Resel
0,6%
2000 NC2 Resel
nb
%
0,5% Suspend
1500 Radio Preempt
0,4%
% Acceptable Rel
1000 0,3%
0,2%
500
0,1%
0 0,%
05
06
07
08
09
10
12
13
14
15
16
17
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
UL TBF Acceptable Release causes - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To
TP
Replacement
1000 0,16%
900
0,14%
800
0,12%
700
NC0 Resel
0,1%
600 NC2 Resel
nb
500 0,08% Suspend

400 Radio Preempt
0,06%
% Acceptable Rel
300
0,04%
200
0,02%
100
0 0,%
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
DL RLC traffic in Acknowledged mode - BSC: BA12BSC ( BA12BSC ) - 2008/12/05
To 2008/12/18 (Working Zone: Global - Medium)
TP
3500000000 Replacement 25,%
3000000000
20,%
2500000000 MCSx retr byt
15,% CSx retr byt
2000000000
MCSx usef byt
nb
%
CSx usef byt
1500000000
10,% % MCSx retr ratio
1000000000 % CSx retr rate
5,%
500000000
0 ,%
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
UL RLC traffic in Acknowledged mode - BSC: BA12BSC ( BA12BSC ) - 2008/12/05
TP
Replacement
1800000000 5,%
1600000000 4,5%
1400000000 4,%
3,5% MCSx retr byt

1200000000
3,% CSx retr byt
1000000000 MCSx usef byt
nb
%
2,5%
800000000 CSx usef byt
2,% % MCSx retr
600000000
1,5% % CSx retr
400000000 1,%
200000000 ,5%
0 ,%
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
Stability KPIs and Alarms
The following graphs show stable values of the related Stability indicators and
Alarms. When there is a variation it is explained using text boxes and comments
to describe the impacted cells.
59/84
Availability for BSC - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To 2008/12/18
TP
90 Replacement 1,2
80

1
70
60 0,8 Total_BSC_GPRS_BU(BSC_GPRS_T
BU)
50 Total_BSC_GSM_BU(BSC_GSM_TBU)
%
0,6
s
Average_BSC_GSM_unavailable_time(
40 AVG_BSC_GSM_IBU)
Average_BSC_GSM_Availability(AVG_
30 0,4 BSC_GSM_TBA)
20
0,2
10
0 0
5
06
09
13
16
18
20 2/0
20 2/0
20 2/0
/1
20 2/1
20 2/1
20 2/1
2/
2/
2/
2/
2/
2
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
No BSC unavailability was noticed after TPv3 Introduction.
Availability for CELL2G - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To 2008/12/18

TP
6000 Replacement 100,02% BA188G1
BA196D2
100,00%
5000
Total_CELL2G_GPRS_BU(CELL2G_G
99,98% PRS_TBU)
4000 Total_CELL2G_GSM_BU(CELL2G_GS
M_TBU)
99,96% Average_CELL2G_GPRS_unavailable_t
ime(AVG_CELL2G_GPRS_IBU)
%
s
3000
Average_CELL2G_GSM_unavailable_ti
99,94% me(AVG_CELL2G_GSM_IBU)
Average_CELL2G_GPRS_Availability(A
2000 VG_CELL2G_GPRS_TBA)
99,92% Average_CELL2G_GSM_Availability(A
VG_CELL2G_GSM_TBA)
1000
99,90%
0 99,88%
5
18
20 2/0
20 2/0
20 2/0
20 2/0
20 2/0
20 2/1
20 2/1
20 2/1
20 2/1
20 2/1
20 2/1
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
There was some unavailability in cells BA196D2 and BA188G1 but it was not
related with TPv3 introduction.
Availability for SS7SL - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To 2008/12/18
TP
60000 95,31%
50000 95,3%
Total_SS7SL_GSM_BU(SS7SL_GSM_
40000 95,29% TBU)
Average_SS7SL_unavailable_time(AVG
%
s
_SS7SL_IBU)
30000 95,28% Average_SS7SL_Availability(AVG_SS7
SL_TBA)
20000 95,27%
10000 95,26%
0 95,25%
5
18
20 2/0
20 2/0
20 2/0
20 2/0
20 2/0
20 2/1
20 2/1
20 2/1
20 2/1
20 2/1
20 2/1
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
The SS7 availability kept stable after the TP Replacement.
Availability for TRX - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To 2008/12/18

TP
BA196D2 TRX 2
100,00%
5000
99,99%
4000
BA058D1 TRX 4 Total_TRX_GSM_BU(TRX_GSM_TBU)
99,98%
Average_TRX_unavailable_time(AVG_T
%
3000
s
RX_IBU)
99,97% Average_TRX_Availability(AVG_TRX_T
BA)
2000
99,96%
1000
99,95%
BA188G1 TRX 2
0 99,94%
08 05
08 06
08 07
08 08
08 09
08 10
08 13
08 14
08 15
08 16
08 17
18
20 12/
20 12/
20 12/
20 12/
20 12/
20 12/
20 12/
20 12/
20 12/
20 12/
20 12/
2/
/1
/
/
08
20
Two TRXs have some unavailability after the TP Replacement but it was not
linked with TPv3 introduction.
61/84
Alarms_Split_per_EventType - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To
TP
300 Replacement
BA180

250
200 QoS_Alarms(QOS_ALARMS)
Processing_Error_Alarms(PE_ALARMS)
nb
150 Equipment_Alarms(EQU_ALARMS)
Environment_Alarms(ENV_ALARMS)
100 Communication_Alarms(COM_ALARMS)
50
0
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
There was a small increase of QoS Alarms on BA180 BTS after the TP
Replacement but this kind of events are normal when operations are taken in the
field.
Alarms Split per Severity - BSC: BA12BSC ( BA12BSC ) - 2008/12/05 To 2008/12/18

TP BA180
200 Replacement
180
160
140 Indeterminate_Alarms(IND_ALARMS)
120 Warning_Alarms(WAR_ALARMS)
nb
100 Minor_Alarms(MIN_ALARMS)
80 Major_Alarms(MAJ_ALARMS)
60 Critical_Alarms(CRIT_ALARMS)
40
20
0
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
The alarms observed on BA180 BTS were major but in the next day the issue was
solved. The type of Alarms can be seen in the next pictures. The alarms started
before the TPv3 introduction then it is not related with TP replacement.
OPERATIONAL TOP N OCCURENCE ON SP - Equipment (Top 10): Alarm-Specific
Loss of EDGE Service
Problem- BSC ( BA12BSC ) - 2008/12/05 To 2008/12/18 (Working Zone: Global -
Medium) (Number
TP of Occurences)(24 Hours)
CELL [43] LOSS-OF-ALL-CHAN [3]
Replacement
160 BA180 RX-TX [10] HW-DEGRADED [237]

140
Loss of Packet Service
120
100 CELL [43] LOSS-OF-TCH [2]
80
BTS-EXTERNAL [9] Allarme NON Urgente
60 SE SAFT 12 [92]
40 CELL [43] LOSS-OF-BCCH [0]
20 BTS-EXTERNAL [9] Ponte Radio Urgente

0 13 [93]
BSC-TRANS [101] BER-10E-6 [7]
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
CELL [43] LOSS-OF-SDCCH [1]
20
20
20
20
20
20
20
20
20
20
20
20
Split per BSC Alarms Split per EventType - BSC: BA12BSC ( BA12BSC ) -
2008/12/05 To 2008/12/18 (Working Zone: Global - Medium)
TP
30 Replacement
BA180
BSC_Communication_Alarms(BSC_COM_
25
ALARMS)
BSC_Environment_Alarms(BSC_ENV_AL
20
ARMS)
BSC_Equipment_Alarms(BSC_EQU_ALA
nb
15
RMS)
BSC_Processing_Error_Alarms(BSC_PE_
10
ALARMS)
BSC_QoS_Alarms(BSC_QOS_ALARMS)
5
0
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
63/84
Split per BTS Alarms Split per EventType - BSC: BA12BSC ( BA12BSC ) -
TP
60 Replacement

BA180 BTS_Communication_Alarms_Count(BTS_
50
Type1_A_C)
BTS_Environment_Alarms_Count(BTS_Ty
40
pe2_A_C)
BTS_Equipment_Alarms_Count(BTS_Type
nb
30
3_A_C)
BTS_Processing_Error_Alarms_Count(BT
20
S_Type4_A_C)
BTS_QoS_Alarms_Count(BTS_Type5_A_
10
C)
0
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
The alarms that occurred after TP replacement on BA180 BTS were Environment
type. The alarms were clean in the next day.
Split per CELL2G Alarms Split per EventType - BSC: BA12BSC ( BA12BSC ) -
TP
250 Replacement
BA180 CELL2G_Communication_Alarms_Count(
200 CELL2G_Type1_A_C)
CELL2G_Environment_Alarms_Count(CEL
150 L2G_Type2_A_C)
CELL2G_Equipment_Alarms_Count(CELL
nb
2G_Type3_A_C)
100
CELL2G_Processing_Error_Alarms_Count
(CELL2G_Type4_A_C)
50 CELL2G_QoS_Alarms_Count(CELL2G_Ty
pe5_A_C)
0
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
On this chart we can see the increase of QoS Alarms on Cells.
Split per CELL2G Alarms Split per Severity - BSC: BA12BSC ( BA12BSC ) -
TP
Replacement
180 BA180
160 CELL2G_Critical_Alarms_Count(CELL2G_
140 Severity5_A_C)
CELL2G_Indeterminated_Alarms_Count(C
120
ELL2G_Severity1_A_C)
100 CELL2G_Major_Alarms_Count(CELL2G_S
nb
80 everity4_A_C)
CELL2G_Minor_Alarms_Count(CELL2G_S
60
everity3_A_C)
40 CELL2G_Warning_Alarms_Count(CELL2G
20 _Severity2_A_C)
0
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
The alarms after the TP Replacement were mainly minor and major. Since 14 of
December, major alarms occurrence return to typical values.
SPLIT_PER_TRANSCODER_ALARMS_SPLIT_EVENTTYPE - BSC: BA12BSC (

BA12BSC ) - 2008/12/05 To 2008/12/18 (Working Zone: Global - Medium)
TP
2,5 Replacement
TRANSCODER_Communication_Alarms(T
2 C_COM_ALARMS)
TRANSCODER_Environment_Alarms(TC_
1,5 ENV_ALARMS)
TRANSCODER_Equipment_Alarms(TC_E
nb
QU_ALARMS)
1
TRANSCODER_Processing_Error_Alarms
(TC_PE_ALARMS)
0,5 TRANSCODER_QoS_Alarms(TC_QOS_A
LARMS)
0
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
The Transcoder alarms kept stable after the TPv3 introduction.
65/84
SPLIT_PER_TRANSCODER_ALARMS_SPLIT_SEVERITY - BSC: BA12BSC (
TP
Replacement
2,5

TRANSCODER_Critical_Alarms_Count(TC
2 _Severity5_A_C)
TRANSCODER_Indeterminated_Alarms_C
1,5 ount(TC_Severity1_A_C)
TRANSCODER_Major_Alarms_Count(TC_
nb
Severity4_A_C)
1
TRANSCODER_Minor_Alarms_Count(TC_
Severity3_A_C)
0,5 TRANSCODER_Warning_Alarms_Count(T
C_Severity2_A_C)
0
05
06
07
08
09
10
13
14
15
16
17
18
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
2/
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
/1
08
08
08
08
08
08
08
08
08
08
08
08
20
20
20
20
20
20
20
20
20
20
20
20
TPv3 High Load phase
The TPv3 High Load state was when there was more than 441 busy HDLCs handle
by the TPv3 board. In this case, the number of busy HDLCs was 460.
Reference Period: 18-Mar / 23-Mar 2009 (1 Week)

Observation Period: 27-Mar / 1-Apr 2009 (1 Week)
Start of TPv3 High Load phase: 26-Mar
GSM Main KPIs

The following graphs show stable values of the related GSM QoS Indicators after
the TPv3 in High Load state. When there is a variation, it is explained using text
boxes and comments to describe the impacted cells and issues.
SDCCH Assign Congestion - OZ_CELL2G: CZ_BA12_BA02_BA3_BA05 -
TP
BA150G3, BA180G2 HIGH LOAD
3200000 1,6%
BA193D2
1,4%
3100000 BA072D2 BA078D1
1,2%
3000000 BA180G1
1,0%
2900000 Congestion
nb
%
0,8% Request
2800000 % Congestion
0,6%
2700000
0,4%
2600000 0,2%
2500000 0,0%
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
There was an increase of SDCCH Congestion on 30th of March in 3 cells: BA072D2,
BA078D1 and BA180G1. This congestion was not caused by TPv3.
SDCCH assignment failure - OZ_CELL2G:

TP CZ_BA12_BA02_BA03_BA05 -
2009/03/18 To 2009/04/01 (Working
HIGH LOADZone: Global - Medium)
3500000 4,5%
3000000 4,%
3,5%
2500000
3,%
2000000 Fail - BSS
2,5%
Fail - Radio
nb
1500000 %
2,% Success
1000000 % Fail
1,5%
500000
1,%
0 ,5%
-500000 ,%
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
The SDCCH failures kept stable after the high load on TPv3.
67/84
SDCCH Drop - OZ_CELL2G: CZ_BA12_BA02_BA03_BA05 2009/03/18 To
Move BTS
TP
Last Step
HIGH LOAD
25000 BA057G2
0,9%

0,8%
20000
0,7%
0,6%
15000 Drop - BSS
0,5%
Drop - HO
nb
%
0,4% Drop - Radio
10000 % Drop
0,3%
0,2%
5000
0,1%
0 0,%
8
19
20
21
22
23
27
28
29
30
31
01
/1
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
03
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
9/
09
09
09
09
09
09
09
09
09
09
09
0
20
20
20
20
20
20
20
20
20
20
20
20
There was a small increase of SDCCH Radio Drop on BA057G2 but was not related
with TPv3.
SDCCH Traffic - OZ_CELL2G: CZ_BA12_BA02_BA03_BA05 - 2009/03/18 To

TP
HIGH LOAD
3200 3,82
3150 3,8
3100
3,78
3050
3,76
3000
3,74 SDCCH Erlang
nb
2950
3,72 SDCCH Avg Duration
2900
3,7
2850
3,68
2800
2750 3,66
2700 3,64
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
The SDCCH Traffic kept stable after the TPv3 high load state.
RTCH assign execution - OZ_CELL2G: CZ_BA12_BA02_BA03_BA05 - 2009/03/18
TP
HIGH LOAD
900000 0,9%
800000 0,8%
700000 0,7%
600000 0,6%
Exe Fail BSS
500000 0,5%
Fail Radio
nb
%
400000 0,4% Success
% Exe Fail BSS
300000 0,3%
% Fail Radio
200000 0,2%
100000 0,1%
0 0,%
-100000 -0,1%
8
20
21
22
23
27
28
29
30
31
01
/1
/1
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
03
03
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
9/
9/
09
09
09
09
09
09
09
09
09
09
0
0
20
20
20
20
20
20
20
20
20
20
20
20
The RTCH Assignment execution KPIs kept stable after TPv3 high load state.
RTCH Assign Congestion - OZ_CELL2G: CZ_BA12_BA02_BA03_BA05 - 2009/03/18

TP
BA078D1
900000 HIGH LOAD 0,18%
BA147G5
800000 0,16%
BA320G1
700000 0,14%
600000 0,12%
500000 0,1% Congestion

nb
Request
400000 0,08% % Congestion
300000 0,06%
200000 0,04%
100000 0,02%
0 0,%
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
A small increase of RTCH Congestion was noticed on 3 cells: BA078D1, BA147G5

and BA320G1 but it was not related with TPv3 high load.
69/84
MOVE BTS Call success - OZ_CELL2G: CZ_BA12_BA02_BA03_BA05 - 2009/03/18 To
2009/04/01 (Working
TP Zone: Global - Medium)
LAST STEP
High Load
60000 100,%

98,%
50000
96,%
Assign Unsucc
40000 94,% Call drop
92,% SDCCH drop
nb
%
30000
90,% % End to End Call setup
20000 88,% % Call success

% Call setup
86,%
10000
84,%
0 82,%
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
The Call Success KPIs kept stable after the TPv3 in high load state.
Call drop - OZ_CELL2G: CZ_BA12_BA02_BA03_BA05 - 2009/03/18 To 2009/04/01

TP
BTS BA053
HIGH LOAD
14000 1,6%
BTS BA314
12000 1,4%
1,2%
10000 Drop - BSS RTC
1,% Drop BSS Intern
8000 Preemption
nb
,8% Drop - HO
6000 Drop - Radio
,6% % RTCH Drop
4000 % Call Drop
,4%
2000 ,2%
0 ,%
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
There was an increase of Remote Transcoder Drops on all the cells from 2 BTSs:
BA053 and BA314. This issue was not related with TPv3 and it was solved after a
lock/unlock RSL.
RTCH Traffic - OZ_CELL2G: CZ_BA12_BA02_BA03_BA05 - 2009/03/18 To
TP
25000 HIGH LOAD 30,4
30,2
20000
30
29,8
15000
29,6
RTCH Erlang
nb
%
29,4 RTCH Avg Duration
10000
29,2
29
5000
28,8
0 28,6
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
The RTCH Traffic kept stable after the TPv3 high load state.
Handover KPIs
Incoming Inter BSC handovers - OZ_CELL2G: CZ_BA12_BA02_BA03_BA05 -

TP
HIGH LOAD
100000 8,0%
90000
7,0%
80000
6,0% Prep Fail
70000
Fail - BSS
5,0% Fail - Radio
60000
Congestion
nb
50000 4,0%
No CIC alloc
40000 Success
3,0%
% Fail
30000
2,0% % Cong
20000
1,0%
10000
0 0,0%
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
The decrease of incoming inter BSC HOs was noticed since 25 of March as shown
in the next picture, then the issue is not related with TPv3.
71/84
Incoming Inter BSC handovers - OZ_CELL2G: CZ_BA12_BA3_BA2_BA5 -
100000 9.0%

90000 8.0%
80000 7.0% Prep Fail
70000 Fail - BSS
6.0%
Fail - Radio
60000
5.0% Congestion
nb
%
50000
4.0% No CIC alloc
40000
Success
3.0%
30000 % Fail
20000 2.0% % Cong
10000 1.0%
0 0.0%
03-18-2009
03-19-2009
03-20-2009
03-21-2009
03-22-2009
03-23-2009
03-24-2009
03-25-2009
03-26-2009
03-27-2009
03-28-2009
03-29-2009
03-30-2009
03-31-2009
04-01-2009
Outgoing Inter BSC handovers - OZ_CELL2G: CZ_BA12_BA02_BA03_BA05 -
TP
2009/03/18 To 2009/04/01HIGH
(Working
LOAD Zone: Global - Medium)
80000 12,%
70000
10,%
60000
Prep Fail
50000 8,%
Drop - BSS
40000 Drop - Radio
nb
%
6,% ROC
30000 Success
% Drop
20000 4,%
% ROC
10000
2,%
0
-10000 ,%
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
The decrease of HOs was not caused by TPv3 board state.
Incoming Intra BSC handovers - OZ_CELL2G: CZ_BA12_BA02_BA03_BA05 -
TP
HIGH LOAD
1600000 6,%
1400000
5,%
1200000
Prep Fail
1000000 4,%
Fail - BSS
800000 Fail - Radio
nb
%
3,% Congestion
600000 Success
% Fail
400000 2,%
% Cong
200000
1,%
0
-200000 ,%
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
Incoming intra BSC HOs kept stable after TPv3 in high load state. It was noticed an
improvement of Failure rate.
Handover Causes - OZ_CELL2G: CZ_BA12_BA02_BA03_BA05 - 2009/03/18 To

2009/04/01 (WorkingTPZone: Global - Medium)
HIGH LOAD
100% 300000
90%
250000 % Interference
80% % DL Quality
70% % HO Distance
200000
% UL Quality
60%
% UL Level
nb
%
50% 150000 % DL Level

% Better Cell
40%
Traffic
100000
30% DR Forced
20% Microcell
50000 Pref Band
10%
0% 0
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
The HO causes distribution kept stable after the TPv3 in high load mode.
(E)GPRS Main KPIs
73/84
No significant variations were observed after the TPv3 High Load phase regarding
the GPRS and EGDE main KPIs.

Downlink Data Transfer - OZ_CELL2G: CZ_BA12_BA02_BA03_BA05 - 2009/03/18

TP
HIGH LOAD
1750000 120,%
1700000
100,% Realloc drop
Radio drop
1650000
80,% Blocking drop
1600000 Stagnat drop
nb
%
60,% BSS drop
1550000 Gb drop
40,% Estab Success
1500000
% Acc Release
20,% % Norm Release
1450000
1400000 ,%
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
Uplink Data Transfer - OZ_CELL2G: CZ_BA12_BA02_BA03_BA05 - 2009/03/18 To

TP
HIGH LOAD
3600000 120,%
3500000
100,% Realloc drop
3400000 Radio drop
80,% Blocking drop
3300000
Stagnat drop
nb
3200000 60,% BSS drop

Gb drop
3100000
40,% Estab Success
3000000 % Norm Release
20,% % Acc Release
2900000
2800000 0,%
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
DL TBF Acceptable Release causes - OZ_CELL2G: CZ_BA12_BA02_BA03_BA05 -
2009/03/18 To 2009/04/01TP
HIGH LOAD
16000 0,92%
14000 0,9%
0,88%
12000
0,86% NC0 Resel
10000
0,84% NC2 Resel
nb
%
8000 Suspend
0,82% Radio Preempt
6000
0,8% % Acceptable Rel
4000
0,78%
2000 0,76%
0 0,74%
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
UL TBF Acceptable Release causes - OZ_CELL2G: CZ_BA12_BA02_BA03_BA05 -
TP
HIGH LOAD
6000 0,18%
0,17%
5000
0,17%
4000 NC0 Resel
0,16% NC2 Resel
nb
3000 % Suspend
0,16% Radio Preempt
2000 % Acceptable Rel
0,15%
1000
0,15%
0 0,14%
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
75/84
DL RLC traffic in Acknowledged mode - OZ_CELL2G:
CZ_BA12_BA02_BA03_BA05 - 2009/03/18 To 2009/04/01 (Working Zone: Global -
TP
Medium)
HIGH LOAD

18000000000 14,%
16000000000
12,%
14000000000
10,% MCSx retr byt
12000000000
CSx retr byt
10000000000 8,%
MCSx usef byt
nb
%
8000000000 CSx usef byt
6,%
% MCSx retr ratio
6000000000
4,% % CSx retr rate
4000000000
2,%
2000000000
0 ,%
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
UL RLC traffic in Acknowledged mode - OZ_CELL2G:
CZ_BA12_BA02_BA03_BA05 - 2009/03/18 To 2009/04/01 (Working Zone: Global -
Medium)
TP
HIGH LOAD
5000000000 3,0%
4500000000
2,5%
4000000000
3500000000 MCSx retr byt
2,0%
CSx retr byt
3000000000
MCSx usef byt
nb
%
2500000000 1,5%
CSx usef byt
2000000000
% MCSx retr
1,0%
1500000000 % CSx retr
1000000000
,5%
500000000
0 ,0%
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
Stability KPIs and Alarms
The following graphs show stable values of the related Stability indicators and
Alarms. When there is a variation it is explained using text boxes to describe the
impacted cells and issues.
Availability for BSC - BSC: BA12BSC ( BA12BSC ) - 2009/03/18 To 2009/04/01
TP
HIGH LOAD
1,2 1,2
1 1
0,8 0,8 Total_BSC_GPRS_BU(BSC_GPRS_T

BU)
Total_BSC_GSM_BU(BSC_GSM_TBU)
%
0,6 0,6
s
Average_BSC_GSM_unavailable_time(
AVG_BSC_GSM_IBU)
Average_BSC_GSM_Availability(AVG_
0,4 0,4 BSC_GSM_TBA)
0,2 0,2
0 0
8
01
20 3/1
20 3/1
20 3/2
20 3/2
20 3/2
20 3/2
20 3/2
20 3/2
20 3/2
20 3/3
20 3/3
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
Availability for CELL2G - BSC: BA12BSC ( BA12BSC ) - 2009/03/18 To 2009/04/01

TP
HIGH LOAD
BA056 BA314
9000 99,98%
issue
8000 99,98%
7000 99,98% Total_CELL2G_GPRS_BU(CELL2G_G

PRS_TBU)
6000 99,98% Total_CELL2G_GSM_BU(CELL2G_GS
M_TBU)
5000 99,97% Average_CELL2G_GPRS_unavailable_t

ime(AVG_CELL2G_GPRS_IBU)
%
s
Average_CELL2G_GSM_unavailable_ti
4000 99,97% me(AVG_CELL2G_GSM_IBU)
Average_CELL2G_GPRS_Availability(A
3000 99,97% VG_CELL2G_GPRS_TBA)
Average_CELL2G_GSM_Availability(A
2000 99,97% VG_CELL2G_GSM_TBA)
1000 99,97%
0 99,96%
8
01
20 3/1
20 3/1
20 3/2
20 3/2
20 3/2
20 3/2
20 3/2
20 3/2
20 3/2
20 3/3
20 3/3
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
77/84
Availability for SS7SL - BSC: BA12BSC ( BA12BSC ) - 2009/03/18 To 2009/04/01
TP
HIGH LOAD
50000 99,%
One more N7

45000 Link, then less

98,5% Unavailability
40000
35000
98,%
Total_SS7SL_GSM_BU(SS7SL_GSM_
30000
TBU)
Average_SS7SL_unavailable_time(AVG
%
s
25000 97,5%
_SS7SL_IBU)
Average_SS7SL_Availability(AVG_SS7
20000
SL_TBA)
97,%
15000
10000
96,5%
5000
0 96,%
8
09 21
1
01
20 3/1
20 3/1
20 3/2
20 3/2
2
20 3/2
20 3/2
20 3/2
20 3/3
3
20 03/
20 03/
20 03/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/
/
09
09
09
09
09
09
09
09
09
09
09
20
Availability for TRX - BSC: BA12BSC ( BA12BSC ) - 2009/03/18 To 2009/04/01

TP
HIGH LOAD
9000 100,00% BA056 BA314
issue
8000 100,00%
7000 100,00%
6000 100,00%
Total_TRX_GSM_BU(TRX_GSM_TBU)
5000 99,99%
Average_TRX_unavailable_time(AVG_T
%
s
RX_IBU)
4000 99,99%
Average_TRX_Availability(AVG_TRX_T
BA)
3000 99,99%
2000 99,99%
1000 99,99%
0 99,98%
09 18
09 20
09 21
09 23
09 27
09 29
09 30
09 31
01
20 03/1
20 03/2
20 3/2
20 03/
20 03/
20 03/
20 03/
20 03/
20 03/
20 03/
20 3/
4/
/0
/0
/0
/
/
09
09
09
09
20
Alarms_Split_per_EventType - BSC: BA12BSC ( BA12BSC ) - 2009/03/18 To
TP
HIGH LOAD
Microwave
700
Issue
600
500 QoS_Alarms(QOS_ALARMS)
400 Processing_Error_Alarms(PE_ALARMS)
nb
Equipment_Alarms(EQU_ALARMS)
300 Environment_Alarms(ENV_ALARMS)
200 Communication_Alarms(COM_ALARMS)
100
0
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
Alarms Split per Severity - BSC: BA12BSC ( BA12BSC ) - 2009/03/18 To 2009/04/01
TP
Microwave
900 HIGH LOAD Issue
800
700
600 Indeterminate_Alarms(IND_ALARMS)
Warning_Alarms(WAR_ALARMS)
500
nb
Minor_Alarms(MIN_ALARMS)
400
Major_Alarms(MAJ_ALARMS)
300 Critical_Alarms(CRIT_ALARMS)
200
100
0
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
79/84
OPERATIONAL TOP N OCCURENCE ON SP - Equipment (Top 10): Alarm-Specific
RX-TX [10] HW-DEGRADED [237]
Problem- BSC ( BA12BSC ) - 2009/03/18 To 2009/04/01 (Working Zone: Global -
Medium) (Number
TP of Occurences)(24 Hours)
RX-TX [10] ANTENNA-VSWR-WARNING
HIGH LOAD [11]

400 BTS-EXTERNAL [9] Ponte Radio Urgente

13 [93]
350
Loss of EDGE Service
300
250 CELL [43] LOSS-OF-ALL-CHAN [3]
200
BTS-EXTERNAL [9] Ponte Radio NON
150 Urgente 14 [94]
100 Loss of Packet Service
50 CLK [1] HW-DEGRADED [237]

0
BSC-TRANS [101] LFA [2]
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
CELL [43] LOSS-OF-TCH [2]
20
20
20
20
20
20
20
20
20
20
20
20
Split per BSC Alarms Split per EventType - BSC: BA12BSC ( BA12BSC ) -
TP
HIGH LOAD
30
BSC_Communication_Alarms(BSC_COM_
25
ALARMS)
BSC_Environment_Alarms(BSC_ENV_AL
20
ARMS)
BSC_Equipment_Alarms(BSC_EQU_ALA
nb
15
RMS)
BSC_Processing_Error_Alarms(BSC_PE_
10
ALARMS)
BSC_QoS_Alarms(BSC_QOS_ALARMS)
5
0
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
Split per BSC Alarms Split per Severity - BSC: BA12BSC ( BA12BSC ) - 2009/03/18
TP
HIGH LOAD
30
BSC_Critical_Alarms_Count(BSC_Severity
25
5_A_C)
BSC_Indeterminated_Alarms_Count(BSC_
20
Severity1_A_C)
BSC_Warning_Alarms_Count(BSC_Severi
nb
15
ty2_A_C)
BSC_Major_Alarms_Count(BSC_Severity4
10
_A_C)
BSC_Minor_Alarms_Count(BSC_Severity3
5
_A_C)
0
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
Split per BTS Alarms Split per EventType - BSC: BA12BSC ( BA12BSC ) - Microwave
2009/03/18 To 2009/04/01 (Working Zone: Global - Medium) Issue
TP
HIGH LOAD
700
600 BTS_Communication_Alarms_Count(BTS_
Type1_A_C)
500 BTS_Environment_Alarms_Count(BTS_Ty
pe2_A_C)
400
BTS_Equipment_Alarms_Count(BTS_Type
nb
3_A_C)
300
BTS_Processing_Error_Alarms_Count(BT
200 S_Type4_A_C)
BTS_QoS_Alarms_Count(BTS_Type5_A_
100 C)
0
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
81/84
Split per BTS Alarms Split per Severity - BSC: BA12BSC ( BA12BSC ) - 2009/03/18
TP
HIGH LOAD
900

800 BTS_Critical_Alarms_Count(BTS_Severity
700 5_A_C)
BTS_Major_Alarms_Count(BTS_Severity4
600
_A_C)
500 BTS_Minor_Alarms_Count(BTS_Severity3
nb
400 _A_C)
BTS_Indeterminated_Alarms_Count(BTS_
300
Severity1_A_C)
200 BTS_Warning_Alarms_Count(BTS_Severit
100 y2_A_C)
0
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
Split per CELL2G Alarms Split per EventType - BSC: BA12BSC ( BA12BSC ) -
TP
HIGH LOAD
300
CELL2G_Communication_Alarms_Count(
250
CELL2G_Type1_A_C)
CELL2G_Environment_Alarms_Count(CEL
200
L2G_Type2_A_C)
CELL2G_Equipment_Alarms_Count(CELL
nb
150
2G_Type3_A_C)
CELL2G_Processing_Error_Alarms_Count
100
(CELL2G_Type4_A_C)
CELL2G_QoS_Alarms_Count(CELL2G_Ty
50
pe5_A_C)
0
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
Split per CELL2G Alarms Split per Severity - BSC: BA12BSC ( BA12BSC ) -
TP
HIGH LOAD
140
120 CELL2G_Critical_Alarms_Count(CELL2G_
Severity5_A_C)
100 CELL2G_Indeterminated_Alarms_Count(C
ELL2G_Severity1_A_C)
80
CELL2G_Major_Alarms_Count(CELL2G_S
nb
everity4_A_C)
60
CELL2G_Minor_Alarms_Count(CELL2G_S
40 everity3_A_C)
CELL2G_Warning_Alarms_Count(CELL2G
20 _Severity2_A_C)
0
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
SPLIT_PER_TRANSCODER_ALARMS_SPLIT_EVENTTYPE - BSC: BA12BSC (
TP
HIGH LOAD
4,5
4 TRANSCODER_Communication_Alarms(T
3,5 C_COM_ALARMS)
TRANSCODER_Environment_Alarms(TC_
3
ENV_ALARMS)
2,5 TRANSCODER_Equipment_Alarms(TC_E
nb
2 QU_ALARMS)
TRANSCODER_Processing_Error_Alarms
1,5
(TC_PE_ALARMS)
1 TRANSCODER_QoS_Alarms(TC_QOS_A
0,5 LARMS)
0
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
83/84
SPLIT_PER_TRANSCODER_ALARMS_SPLIT_SEVERITY - BSC: BA12BSC (
TP
HIGH LOAD
6

TRANSCODER_Critical_Alarms_Count(TC
5
_Severity5_A_C)
TRANSCODER_Indeterminated_Alarms_C
4
ount(TC_Severity1_A_C)
TRANSCODER_Major_Alarms_Count(TC_
nb
3
Severity4_A_C)
TRANSCODER_Minor_Alarms_Count(TC_
2
Severity3_A_C)
TRANSCODER_Warning_Alarms_Count(T
1
C_Severity2_A_C)
0
18
19
20
21
22
23
27
28
29
30
31
01
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
3/
4/
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
/0
09
09
09
09
09
09
09
09
09
09
09
09
20
20
20
20
20
20
20
20
20
20
20
20
End of document

MXBSC B10 Improvements - Field Feedback: Technology Introduction & Support Network Engineering

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

MXBSC B10 Improvements - Field Feedback: Technology Introduction & Support Network Engineering

Încărcat de

Drepturi de autor:

Formate disponibile

Technology Introduction & Support

Domain BSS Release First Off

CRISTIAN IOAN INTA, EUGEN MARZA, JOÃO FRADE

Department Name Department Name

NE Romania Eugen Marza NE Romania Cristian Udriste

NE Portugal João Frade NE France Milena Palumbo

NE France Thierry Plantier

GSM Romania Manager Oliviu Burlacu 17.06.2009

not permitted without written authorization from Alcatel.

2 MX BSC IMPROVEMENTS IN B10....................................................................................................................... 4

3 MXBSC PILOT DESCRIPTIONS......................................................................................................................... 10

not permitted without written authorization from Alcatel.

2.1.2 B10 evolution

2.1.2.1 Connection of a SMLC to a BSS

2.1.2.2 Requirements to connect a MFS to a MX BSC

2.1.2.3 Summary of the requirements for this feature in B10

MX BSC telecom performances requirements:

• It is possible to connect a GPU AB, a GPU AC and a GP board to a MX BSC

configured with 1000 TRXs.

2.2 SS7 on High Speed Links (HSL)

2.2.2 B10 evolution

not permitted without written authorization from Alcatel.

All rights reserved. Passing on and copying of this

2.2.2.2 TDM synchronization with E1 links supporting HSL

2.2.2.3 Summary of the requirements for this feature in B10

MX BSC general SS7 configurations requirements:

o Mixed mode (LSL+HSL) is not allowed;

not permitted without written authorization from Alcatel.

All rights reserved. Passing on and copying of this

2.3 Removal of HR impact on BSC connectivity

2.3.2 B10 evolution

The maximum number of TREs mapped to a CCP is independent on whether the

2.3.2.1 Summary of the requirements for this feature in B10

• The “removal of HR impact on BSC connectivity” feature is optional

2.4 Up to 500 cells per MX BSC

A MX BSC supports a maximum of 264 cells.

2.4.2 B10 evolution

The capacity is extended to 500 cells for the MX BSC.

3.1 Pilot Overall Description

not permitted without written authorization from Alcatel.

All rights reserved. Passing on and copying of this

3.2 CMCC China, B10MR1

3.2.1 Test Plan

Step 3 MFS/BSC/CELL parameters were checked and modified as old value

• Architecture, in order to be compliant with architecture rules and to be

sure that no issues occurred

3.2.2 Followed Schedule

TRX Nr. BSC62_C BSC62_D BSC62_A BSC62_1 BSC62_B

Reference 397 248 191 262 0

Phase1 - 248 191 262 391

Phase2 - - 191 262 639

Phase3 - - - 236 898

not permitted without written authorization from Alcatel.

All rights reserved. Passing on and copying of this

Network Element Final Number BSC 1000TRX Occupancy

BTS 162 255 63.53%

Cell 164 500 32.80%

TRX eq 898 (838FR+30HR) 1000 89.80%

TCH Traffic 1991.39 Erlang 4000 Erlang 49.78%

SCCP Traffic 2404.84 Erlang 4000 Erlang 60.12%

Abis links 165 up to 176 93.75%

ExtraAbisTS 940 up to 2000 41.30%

AterMuxCS 30 (13) 30 (20) 30 (28) 30 (28)