etisalat 2g bss audit

Alcatel – Lucent 1/57 All rights reserved. Passing on and copying of this document, use and communication of its contents, not permitted without written authorization

2G BSS RAN ANALYSIS

Abstract

This document reports the analysis result of the 2G BSS Audit done in Etisalat network between October and November 2012.

This analysis encompasses results related to topics such as:

BSS Parameters Audit QoS Audit (Counters) QoS Audit (Drive Tests) Frequency Plan Audit Stability Audit Architecture Audit.

Alcatel – Lucent 2/57

All rights reserved. Passing on and copying this document, use and communication of its contents, not permitted without written authorization

TABLE OF CONTENTS

AUDIT CONTEXT .............................................................................................................................................................2

AREA UNDER STUDY ........................................................................................................................................................2 1. INTRODUCTION.......................................................................................................................................................3

TOPOLOGY OF ETISALAT’S NETWORK................................................................................................................................3 2. BSS PARAMETERS AUDIT.....................................................................................................................................4

1.1. CELL AND RADIO RESOURCE SELECTION..............................................................................................................4 1.2. POWER CONTROL................................................................................................................................................6 1.3. HANDOVER..........................................................................................................................................................8 1.4. DUAL LAYER AND DUAL BAND HANDOVER ..........................................................................................................10 1.5. MULTIBAND AND CONCENTRIC CELL SPECIFIC HANDOVER PARAMETERS .............................................................11 1.6. DIRECTED RETRY AND QUEUING ........................................................................................................................12 1.7. (E)GPRS CONFIGURATION................................................................................................................................13 1.8. BSC SPECIFIC CONFIGURATION.........................................................................................................................14 1.9. DESIGN PARAMETERS........................................................................................................................................14

3. QOS AUDIT (COUNTERS).....................................................................................................................................17 3.1. CS PERFORMANCE............................................................................................................................................17

3.1.1. Call Establishment...................................................................................................................................17 3.1.2. Call Drop .................................................................................................................................................20 3.1.3. Handover.................................................................................................................................................23 3.1.4. Traffic ......................................................................................................................................................25

3.2. PS PERFORMANCE............................................................................................................................................26 QOS AUDIT (DRIVE-TESTS) .........................................................................................................................................29

4. FREQUENCY PLAN AUDIT...................................................................................................................................32

5. STABILITY AUDIT..................................................................................................................................................35 5.1. AVAILABILITY .....................................................................................................................................................35

5.1.1. BSC availability .......................................................................................................................................37 5.1.2. Cell availability.........................................................................................................................................38 5.1.3. TRX availability........................................................................................................................................39

5.2. STABILITY..........................................................................................................................................................40 6. ARCHITECTURE AUDIT........................................................................................................................................43

6.1. BSC CONFIGURATION .......................................................................................................................................43 6.2. MFS CONFIGURATION .......................................................................................................................................47 6.3. TRAFFIC LOAD...................................................................................................................................................50 6.4. BSC MX_WEST7 DETAILS ................................................................................................................................54

7. CONCLUSION ........................................................................................................................................................56

Audit context

Area under study Regions BSC MFS Cells TRXs BSS Release

Bateen Area MX_West7 station_MX_mfs_7 135 600 B11MR3ed1.1

1. Introduction Following a complaint from Etisalat regarding some performance issues on the 2G network, a complete BSS Audit was performed in one of the main Abu Dhabi’s BSCs ( MX_West7 ), known to cover the VIP area of the city, Bateen. The aim of this document is to present the result of the audit which evaluated the behavior of the Radio/BSS elements of the network and presents a set of recommendation to improve network in terms of performance and dimensioning. Main topics of the audit consider:

• BSS Parameters Audit • QoS Audit (based in Counters) • QoS Audit (based in Drive Tests) • Frequency Plan Audit • Stability Audit • Architecture Audit

Topology of Etisalat’s network Total number of BSS elements in the network, BSC configuration and target BSC for the audit:

Figure 1 – Nb of BSS Elements

Figure 2 – BSC Configuration

Figure 3 – Audited BSC MX_West7 Details

Alcatel - Lucent 3/57




2. BSS Parameters Audit Audit of BSS Parameters of BSC MX_West7 considered the review of general and main feature configuration. Good optimization practices were also considered in order to better define an optimization strategy and allow a better network tuning in the future. Below, the 4 main important outputs of the audit highlighted:

• Need of better HO tuning – HO margins need to be better defined for PBGT and Emergency HOs. There are several important violations of good practices in parameters configurations (ex: negative HO_MARGINs). Calls not handled by best server in the area what might be causing QoS degradation; Design and coverage issues can he hided by such aggressive configuration; Ping-pong and unnecessary HOs occurring.

• Multiband and Concentric cells Traffic Management – Important to respect rules for traffic management between bands. Thresholds must be well defined to avoid unnecessary HOs and Ping-pong between layers. Aggressive forcing of traffic can affect cell’s performance and Voice Quality.

• DWELL Time Configuration – BSC tuning for DWELL time algorithm is compromising feature’s efficiency. Traffic management between umbrella and micro cells being affected.

• BCCH/BSIC Review – Several cases of BCCH/BSIC duplication inside same BSC. HO efficiency affected and Phantom RACH created.

• Network pattern – Create a network pattern for all parameter families/features. This will improve the network performance, and create conditions for a better RNE optimization.

1.1. Cell and Radio Resource Selection Parameter: CELL_RESELECT_HYSTERESIS

Default Alcatel CRH = 6 dB ETISALAT Network 4 dB in 1 cell

6 dB in 20 cells 8 dB in 97 cells 12 dB in 1 cell 14 dB in 16 cells

Recommendation: Use 6 dB for all cells. This parameter is the level hysteresis for cell reselection applied when the new cell is in a different location area. Such different parameters may cause excess of LU (cases of 0dB), or abnormal cell camping causing SDCCH assignment failures, SDCCH drop, and reduced voice quality (HOs may occur right after calls are initiated).



Parameter: CELL_RESELECT_OFFSET

Default Alcatel CRO = 0 dB ETISALAT Network

CRO (dB) Umbrella Micro

0 50 22 4 3

6 10 5 8 1 10 18 12 15 14 10

10 1

Recommendation: This parameter depends on the strategy followed for network access. Anyway, except for some specific tuned cases, usage of a pattern for all cells is recommended.

Parameter: PENALTY_TIME

Default Alcatel PENALTY_TIME = 20s ETISALAT Network 0 seg in 38 cells

1 seg in 12 cells 2 seg in 43 cells 3 seg in 1 cell 30 seg in 1 cell 31 seg in 40 cells

Recommendation: In the cases where 31s are used, CRO is computed with a negative value, preventing cell to capture most of the traffic. Degradation is expected in neighbor’s KPIs.

Parameter: RACH_TA_FILTER

Default Alcatel RACH_TA_FILTER = 64 ETISALAT Network 89 cells bellow 10 Recommendation: This setting forbids some MSs to access the network.

It is always recommended to limit cell coverage by site re-engineering and avoid logical limitation.



1.2. Power Control Parameter: EN_BS_PC

Default Alcatel ETISALAT Network Disabled Recommendation: In dense urban environments it is recommended the

usage of Power Control in order to reduce interference and improve main KPIs.

Parameter: MS_P_CON_ACK MS_P_CON_INT

Default Alcatel MS_P_CON_ACK = 3 x (2 SACCH) MS_P_CON_INT = 1 x (2 SACCH)

ETISALAT Network MS_P_CON_ACK = 2, in 73 cells MS_P_CON_INT = 0, in 105 cells

Recommendation: To achieve maximum performance, default values should be used in all cells.

Parameter: Power-Control Thresholds

Default Alcatel L_RXLEV_UL_P = -95 dBm (Evolium) or –90 dBm (G2) L_RXQUAL_UL_P = 3.0 U_RXLEV_UL_P = -85 dBm (Evolium) or –80 dBm (G2) U_RXQUAL_UL_P = 1.0

ETISALAT Network Wide range of values can be observed in the network. Recommendation: Used thresholds present in some cases very aggressive

values, turning PC algorithm ineffective. Rule: difference of 10dB between U and L level thresholds In case of Power Control activation, use recommended values to improve efficiency of algorithm.

Parameter: MAX_POW_RED

Default Alcatel 8 dB ETISALAT Network 2 dB in 3 cells

4 dB in 33 cells 6 dB in 8 cells 8 dB in 91 cells

Recommendation: 8 dB should be used in all cells



Parameter: MAX_POW_INC

Default Alcatel 8 dB (recommended) ETISALAT Network 8 dB in 39 cells

12 dB in 19 cells 16 dB in 77 cells

Recommendation: A value equal or higher than 8dB is recommended to allow a faster power level recovery in case of too low quality.

Parameter: MS_TXPWR_MIN

Default Alcatel 13 dBm (coded 15) for GSM900 cells 4 dBm (coded 13) for DCS1800 cells

ETISALAT Network Several different configurations can be found Recommendation: Usage of default values

Parameter: OFFSET_HOPPING_PC

Default Alcatel 1 ETISALAT Network 0 in 17 cells Recommendation: Usage of default value for all cells.

Parameter: POW_INC_FACTOR

POW_INC_STEP_SIZE POW_RED_FACTOR POW_RED_STEP_SIZE

Default Alcatel POW_INC_FACTOR = 0.8

POW_INC_STEP_SIZE = 6 dB POW_RED_FACTOR = 0.5 POW_RED_STEP_SIZE = 2 dB

ETISALAT Network POW_INC_FACTOR = 0.8 (in 99.9% of cells) POW_INC_STEP_SIZE = 6 dB (in 99.99% of cells) POW_RED_FACTOR = 0.5 (in 97% of cells) and 1 (in 3 cells) POW_RED_STEP_SIZE = 1 dB in all cells

Recommendation: Usage of default values for all cells.



1.3. Handover Parameter: A_PBGT_HO

Default Alcatel 8 for urban ETISALAT Network 4 in 1 cell

6 in 74 cells 8 in 2 cells 10 in 58 cells

Recommendation: Use of the default values. Parameter: HO_MARGIN_DIST (0,n)

Default Alcatel 2 dB ETISALAT Network 4dB in 5 cells

5dB in 515 cells 6dB in 6 cells

Recommendation: Should be greater than 0 and less than HO_MARGIN: < 0: Ping-Pong > HO_MARGIN: no Dist Emergency HOs

Parameter: HO_MARGIN_LEV (0,n)

Default Alcatel 2 dB ETISALAT Network < 0dB, in 90 HO relations

>= HO_MARGIN, in 602 HO relations Recommendation: Should be greater than 0 and less than HO_MARGIN:

< 0: Ping-Pong > HO_MARGIN: no Lev Emergency HOs

Parameter: HO_MARGIN_QUAL (0,n)

Default Alcatel 1 dB ETISALAT Network < 0dB, in 160 HO relations

>= HO_MARGIN, in 510 HO relations Recommendation: Should be greater than 0 and less than HO_MARGIN:

< 0: Ping-Pong > HO_MARGIN: no Qual Emergency HOs



Parameter: HO_MARGIN (0,n)

Default Alcatel 5 dB ETISALAT Network HO_MARGIN < 0 dB in 3 HO relations

0 <= HO_MARGIN < 4 in 25 HO relations 4 <= HO_MARGIN <= 6 in 3125 HO relations HO_MARGIN > 6 in 126 HO relations

Recommendation: Usage of too high or too lower values should be avoided, once calls will not be handled by the best server cells in the area. QoS is expected to be degraded and uncontrolled ping-pong HO can occur. In addition, HO_MARGIN(a,b) + HO_MARGIN(b,a) must never be less than 0 as it causes ping-pong problems.

Parameter: L_RXLEV_DL_H

L_RXLEV_UL_H L_RXQUAL_DL_H L_RXQUAL_UL_H

Default Alcatel L_RXLEV_DL_H = -93 dBm in urban

L_RXLEV_UL_H = -100 dBm in urban L_RXQUAL_DL_H = 4 L_RXQUAL_UL_H = 4

ETISALAT Network L_RXLEV_DL_H: wide range of cells between -80dBm and -92dBm L_RXLEV_UL_H: wide range of cells between -88dBm and -97dBm L_RXQUAL_DL_H = 29/30 in all cells L_RXQUAL_UL_H = 29/30 in all cells

Recommendation: High emergency level thresholds must be avoided, once it artificially reduces the coverage area with emergency HOs, and can create Ping-Pong (HO out by emergency and come in by PBGT HO).

Parameter: T_HCP

Default Alcatel T_HCP = 0s ETISALAT Network T_HCP =20s in 11 cells Recommendation: High values should be avoided for T_HCP without

specific optimization.



1.4. Dual Layer and Dual Band Handover Parameter: EN_PREFERRED_BAND_HO MULTIBAND_TRAFFIC_CONDITION

Default Alcatel EN_PREFERRED_BAND_HO = enable for GSM900 and GSM-DCS cells EN_PREFERRED_BAND_HO = enable for DCS cells (if DCS is the preferred band) MULTIBAND_TRAFFIC_CONDITION = Any load

ETISALAT Network EN_PREFERRED_BAND_HO enable for 7 DCS and 22 GSM cells

Recommendation: Both parameters must be defined according a general traffic management strategy. Due to the different configuration found at this level, no strategy seems to be followed.

Parameter: L_RXLEV_CPT_HO(0,n)

Default Alcatel -85 dBm ETISALAT Network Wide range of configurations found considering values

between -85dBm and -47dBm Recommendation: This parameter is the minimum received downlink level

from classical band cell to preferred band cell and is used on traffic balancing between bands. Recommended values should be set around –85dBm and depending on traffic management strategy.

Parameter: T_INHIBIT_CPT

Default Alcatel 0 s ETISALAT Network 4 cells have this timer greater than 0s. Recommendation: Must be set according to default value



1.5. Multiband and Concentric Cell Specific Handover Parameters Parameter: NEIGHBOUR_RXLEV(0,n)

Default Alcatel -47 dBm ETISALAT Network 0 in 2 cells Recommendation: This parameter is the threshold of maximum received

level from the neighbor cells for cause 13. If set on –47 dBm, the level of the neighboring cell is not taken into account for the triggering of cause 13. In case of non specific optimization cases, it must be used –47dBm in all HO relations.

Parameter: OFFSET_HO_MARGIN_INNER

Default Alcatel 10 dB for multiband 0 dB for concentric

ETISALAT Network 0 dB in one cell 4 dB in 21 cells 6dB in one cell 10bB in 5 cells

Recommendation: In case of Concentric Cells, value should be 0 dB. Parameter: RXLEV_DL_ZONE,

RXLEV_UL_ZONE

Default Alcatel RXLEV_DL_ZONE ≈ -80 dBm RXLEV_UL_ZONE ≈ -88 dBm

ETISALAT Network RXLEV_DL_ZONE: - 78dBm in one cell - 80dBm in one cell - 90dBm in one cell - 85dBm in 25 cells RXLEV_UL_ZONE - 95dBm in 20 cells - 92dBm in 2 cells - 90dBm in one cell - 88dBm in one cell - 85dBm in one cell

Recommendation: Depends on the traffic intended for each layer. Extreme values should be avoided. Recommended rules: RXLEV_DL_ZONE >= L_RXLEV_DL_H RXLEV_UL_ZONE >= L_RXLEV_UL_H



Parameter: ZONE_HO_HYST_DL ZONE_HO_HYST_UL

Default Alcatel 6dB ETISALAT Network ZONE_HO_HYST_DL and ZONE_HO_HYST_UL

6dB, in 8 cells >6dB, in 20 cells

Recommendation: Parameters are the hysteresis applied to RXLEV_XX_ZONE for outer to inner zone handover, or the DL/UL offset used for triggering cause 13 HOs. For a better traffic balance between zones, RXLEV_XX_ZONE must be changed and the hysteresis parameters maintained constant. This will allow better analysis of QoS and better tuning in case of need. Parameters are recommended to be set with 6 dB for Concentric Cells.

1.6. Directed Retry and Queuing Parameter: Freelevel_DR(n)

Default Alcatel 2 for cells with 2 TRX 4 for all others

ETISALAT Network 255 TS in 20 cells 0 TS in one cell

Recommendation: Setting FREElevel_DR(n) to 255 for an external cell will inhibit outgoing external directed retry towards this cell. Setting FREElevel_DR(n) to any other value will allow outgoing external directed retry towards this cell.

Parameter: L_RXLEV_NCELL_DR(n)

Default Alcatel -85 dBm ETISALAT Network Wide range of values is defined,

between -110dBm (1 cell) and -47dBm (20 cells) Recommendation: In case threshold is too low, cause 20 HOs will be

triggered in a more easy way, but creating a problem of quality in the target cell. For giving a higher priority to a given layer, it is preferable to make a better tuning of the parameter PRIORITY(0,n).



1.7. (E)GPRS Configuration Generally, for data configuration, no issues were found and just some recommendation is mentioned to improve PS performance. Parameter: EN_EGPRS

Default Alcatel Enabled (depends on customer strategy for PS) ETISALAT Network Disabled: 44 cells

- 35 Micro cells - 9 Macro cells

Enabled: 91 cells - 40 Micro cells - 51 Macro cells

Recommendation: EGPRS is recommended to be enabled for better PS performance. Due to some HW limitation in some cases is disabled.

Parameter: EN_EXTENDED_UL_TBF

Default Alcatel Disabled (depends on customer strategy for PS) ETISALAT Network Disabled Recommendation: Extended TBF mode feature is recommended for better

performance on the UL in (E)GPRS. Parameter: PS_PREF_BCCH_TRX

Default Alcatel 0: No preference. The TRX ranking algorithm handles the BCCH TRX as a non-BCCH TRX (depends on customer strategy for PS)

ETISALAT Network 1: PS requests preferentially served on BCCH TRX; the TRX ranking algorithm ensures that the BCCH TRX has the highest preference to carry PS traffic (provided that the BCCH TRX can carry PS traffic

Recommendation: Configuration at TRX level for PS depends on customer strategy and needs always to consider which TRXs (BCCH/nonBCCH) will have higher or lower interference and where CS or PS will have preference.



Parameter: TBF_DL_INIT_CS TBF_DL_INIT_MCS TBF_UL_INIT_CS TBF_UL_INIT_MCS

Default Alcatel TBF_DL_INIT_CS: CS2

TBF_DL_INIT_MCS: MCS3 TBF_UL_INIT_CS: CS2 TBF_UL_INIT_MC: MCS3

ETISALAT Network Default values respected Recommendation: Better performance can be achieved by adjusting the

initial coding schemes for GPRS and EDGE according to the network design/coverage and level of noise

1.8. BSC Specific Configuration At BSC level only a few parameters concerning the traffic management in the umbrella cells need special attention. Parameter: H_MIN_DWELL_TIME L_MIN_DWELL_TIME

DWELL_TIME_STEP

Default Alcatel H_MIN_DWELL_TIME: 20s L_MIN_DWELL_TIME: 8s DWELL_TIME_STEP: 2s

ETISALAT Network H_MIN_DWELL_TIME: 5s L_MIN_DWELL_TIME: 5s DWELL_TIME_STEP: 0s

Recommendation: In umbrella cells, speed estimation is based on the dwell time in the neighbor micro-cells. In case this value is changed, algorithm will be compromised. It is highly recommended to maintain this value as per indicated in the default.

1.9. Design Parameters Basic design configuration issues are normally a good indication of some problems in the network, such as unidirectional HO relations, relations with co-channel and adjacent BCCH and duplication of the same BCCH/BSIC in the same area. On the MX_West7 BSC were identified 3 unidirectional HO relations. This can be creating some HO efficiency problems on the opposite cell.

Figure 4 - Unidirectional HO Relation

For the detection of interference, some good inputs can be obtained from the analysis of the HO relations. Declared HO relations between cells with same BCCH indicate that most probably some strong interference is occurring, by having 2 neighbor cells with same BCCH. In MX_West7 BSC no cases were identified. However, some relations exist between BCCH adjacent cells which need a deeper analysis. In some of these cases where cell overlap is larger, some quality issues can also be created.

Figure 5 - Neighbours with Adjacent BCCH

BCCH/BSIC duplication in the same area (checked inside same BSC) may cause some HO efficiency problems which results in degradation at HO level and poor Voice Quality and can even sometimes end with a Call Drop. In MX_West7 BSC no cases were identified, but others are visible in the remaining network:



Figure 6 - BCCH/BSIC Duplication Same BSC

These situations must be avoided not to create HO efficiency problems and in some cases Phantom RACH.





3. QoS Audit (Counters) A QoS analysis was performed to BSC MX_West7 and all the main KPI for CS and PS reviewed. Important to highlight that on the 10th October a new site entered on air (Site 4915x) highly degraded due to HW issues and with high impact in global KPIs. For the analysis, and once the cause is known, this site/fact was ignored. Analysis was focused in the following QoS domains:

• CS Performance o Call Establishment o Call Drop o Handover o Traffic

• PS Performance o Global PS Performance

It is assumed that PS performance is directly linked to radio and CS performance and also configuration. Due to this, highest priority and detail was put in CS. Main outputs consider:

• General good KPI No issues found at general level with all the main KPI inside good thresholds

• Punctual issues in the different domains in some cells For each domain some cells were identified with some problems which need a better cell by cell analysis

• High HO per call in a significant number of cells affecting QoS and Voice Quality Several cells having a huge HO_per_Call which can be affecting cell’s performance and has great influence at Voice Quality level, due to the big number of unnecessary HOs. Influence also on Call Drop HO.

3.1. CS Performance General CS Performance is good and apart from the problem created by site 4915x QoS is presenting very good values. Some issues were however found and some improvement can be obtained after some optimization activities.

3.1.1. Call Establishment At Call Establishment level, no main issues were found with global behavior of the BSC in a good state. No significant congestion is observed at SDCCH level and apart from site 4915x, congestion is only observed in a few cells and below 0,1%.

Figure 7 – MX_West7 SDCCH Assignment Congestion

Failures at SDCCH assignment level only significant in a small number of cells and with no impact at global level.

Figure 8 - MX_West7 SDCCH Assignment Failure

Main impacted cells are reduced to a group of 10 cells where failures are related to radio issues:

Figure 9 - Cells with higer SDCCH Ass Fail Rate

One of the cells, VI_W_VIP_W18_Sh_Sultn_Bn_Hamdn_P (22011/52900) has global bad performance, including high Call Drop and HO Failures and should be investigated in detail. Others have a general good performance and issue might be related to some HW malfunction. At SDCCH Drop level, behavior is good and all cells performing well. Exception goes again to cell VI_W_VIP_W18_Sh_Sultn_Bn_Hamdn_P (22011/52900) which reaches more than 2% drop. Alcatel – Lucent 18/57


Figure 10 - MX_West7 SDCCH Drop

RTCH Assignment phase with very good behaviour and no issues found. No congestion verified in any of the cells with exception only for W_W11_Khalidiah_park_A (22011/49151) with just 0.01% congestion rate in one week.

Figure 11 – MX_West7 RTCH Assignment Congestion

Also very good performance at Call Setup Success Rate level with almost 100% Call Success. The only cell having values outside targets is again VI_W_VIP_W18_Sh_Sultn_Bn_Hamdn_P (22011/52900).

Figure 12 - MX_West7 CSSR



3.1.2. Call Drop Performance observed at RTCH Call Drop is generally good in the BSC, with values normally under 0.3%. On the 19th October significant degradation is observed but related only to a single site which entered On-Air with some HW issues ( Site 4915x mentioned before ). Some BSS Drops also being observed.

Site 4915x On-Air

Figure 13 – MX_West7 CDR

By removing problematic Site 4915x it is visible that BSC remains stable and with good performance:

Figure 14 - MX_West7 CDR excluding Site 4915x

However some strange behavior is observed by having a significant number of Drops during HO. This is also observed with the difference between Call Drop Rate and RTCH Drop Rate. Individually, it is possible to observe that a significant number of cells is presenting more than 50% of Drops during HO among they’re total number of Drops. All the cases refer to Micro and Concentric Cells where some special HO configuration is sometimes needed.



Figure 15 - Cells with high Drop HO (1 week data)

In most of the times, this type of behavior is linked with Ping-Pong effect in HO and is caused by mismatch configuration at HO level. In the table it is visible that in most of the cases HO per Call is very high. A relation is visible in a general way between these two indicators:

Figure 16 – Drop HO vs HO per Call

As indicated in the parameters audit, some issues were found in the Concentric Cell configuration that can lead to this type of performance. Also all the micro cells need special attention in terms of optimization to avoid Ping-Pong between capture HOs and normal PBGT HOs. Configuration is highly dependant on the type of environment and coverage of the cell. Indicator is also presenting a very high value in some cells which need urgent attention: Alcatel - Lucent 21/57


Figure 17 - Worst Cell HO per Call

Apart from the issues around the Concentric Cells, and performing a deeper analysis to CDR and the Cell Type, it is visible that the main contributors for global CDR are the Umbrella/Macro cells:

Figure 18 - CDR and HO per Call per Cell Type

Number of RTCH Assignments is equivalent between both types of macro cells, Concentric and Single and just a bit lower for the Micro cells. On the Radio side, some cells have been identified as having a high rate of failures. All the 3 sectors of the new site are visible (4915x) and issue known. For the remaining ones, a deeper analysis is recommended.

Figure 19 - Worst Cell CDR ( 1 week data )

Degradation in cell W_W9_C16 (22011/16760) only observed in the last week of analysis and might be related to punctual issues.



3.1.3. Handover

Handover Performance is having a very good performance in both Intra and Inter BSC scenarios. Rate of failures is low and no issues are visible. Again, some degradation is visible after the 19th October due to the new site 4915x.

Site 4915x On-Air

Figure 20 - BSC MX_West7 Out Intra BSC HSR

Site 4915x On-Air

Figure 21 – BSC MX_West7 Out Inter BSC HSR

Analysis to HO Causes showing good behaviour in the overall BSC:

• Mainly Better Cell HOs occurring • Low number of Quality HOs, both in DL and UL • Balanced number of HOs between DL and UL for Level and Quality causes.



Figure 22 - BSC MX_West7 HO Causes

In a per cell analysis, even if global behaviour is good, some issues can be found indicating poor performance in some cases and added need for analysis and improvement. Some outputs from the detailed cell analysis:

• 12 cells with no Better Cell HOs • Cell W_View_Refreshments_A (22011/16831) with 55.7% DL Quality HOs

Cell W_W9_C16 (22011/16760) with 31.85% DL Quality HOs • Cell VI_W_VIP_W18_Sh_Sultn_Bn_Hamdn_P (22011/52900) with 27% UL Quality HOs • 28 cells with high DL Level HOs

Cell W_W19_01_P26 (22011/64400) with almost 80% DL Level HOs • 8 cells with high UL Level HOs

Cells VI_W_VIP_W18_Sh_Sultn_Bn_Hamdn_P (22011/52900) and W_Hamad_Alsuwaidi_Villa_W35 (22011/43840) with more than 60% UL Level HOs

• Cell V_W_W30_C (22011/14263) with 42% Distance HOs Cell W_W19_01_North_A (22011/45401) with 10% Distance HOs

Issues can indicate bad configuration, unbalanced power between UL and DL, interference and HW issues. Also, coverage must be limited by reviewing cell design and not by logical configuration. A cell with 42% Distance HOs indicates large coverage where it is not needed, and even if service of the cell is limited, interference is kept for the remaining cells. In case of 3G to 2G HOs, BSC is also performing well with no visible problems. Anyway, even if rate of failures is low, a deeper analysis can be performed around existing BSS failures.



Figure 23 - BSC MX_West7 3G->2G HO Performance

BSS Failures are observed generally in all the cells of the BSC.

3.1.4. Traffic Traffic pattern normal and good values observed for RTCH and SDCCH Duration Average. On the SDCCH part, duration average is 3s, seen as very good performance.

Figure 24 - BSC MX_West7 Traffic

In a small number of cases, SDCCH Duration Average observed is low, which can be an indication of problems on the SDCCH phase. Alcatel - Lucent 25/57


Figure 25 – BSC MX_West7 Lowest SDCCH Dur Avg

3.2. PS Performance Performance for Data Services, GPRS and EDGE, is directly linked to normal radio conditions and network stability and can be evaluated by the main CS KPIs. Network is presenting good performance on the CS side and it can be assumed that Data Services will also perform well. Anyway, analysis was performed to main (E)GPRS indicators, around TBF establishment and behavior, Data Transfer modes and PDCH usage. Considering the Establishment phase, performance is very good with almost no failures and a high rate of success, both for DL and UL.

Figure 26 – BSC MX_West7 DL TBF Establishment

In the whole BSC were identified 2 cells with bad behavior at TBF Establishment in DL, with Radio and BSS problems:

Alcatel – Lucent Figure 27 - Worst Cells GPRS TBF Establishment Performance

26/57


Degradation observed around the 21st September is related to a Shelf Reduction which had some issues. Later, a new degradation is observed related to some actions around the correction of previous problem.

Figure 28 - BSC MX_West7 UL TBF Establishment

In the UL path and in a per cell analysis, a new cell was found apart from W_HILTONIA_MIC_1 (22011/55590) seen before, cell W_W11_Khalidiah_park_A (22011/49151), with only 42% success rate. During Dada Transfer, BSC is also performing well with a small rate of Drops. No radio issues are visible, blocking or any other equipment problems.

Figure 29 - BSC MX_West7 DL Data Transfer



Figure 30 - BSC MX_West7 UL Data Transfer

Some cells present higher rate of DL TBF Drops, but most of them with no significant PS Traffic and not generating reliable statistics. No blocking and/or BSS issues visible.

Figure 31 - BSC MX_West7 Cell PS Performance

The UL performance is similar and no major issues found. At PDCH Usage level, also no issues are found.

Figure 32 - BSC MX_West7 PDCH Traffic



QoS Audit (Drive-Tests) One of the best ways to evaluate real End-User experience and QoS is via the analysis of Drive-Tests, where the real performance of the MSs in the field can be evaluated. Tests were performed with TEMS tool in the main roads of Abu Dhabi with multiple passes in both ways. Toolchain: TEMS MS: Sony Ericsson W600 (2G Mode only) Roads measured and RxLev are according:

Figure 33 - DT Route and RxLev

Tests were performed in Dedicated Mode, 2G only and continuous call. No major issues detected but one call drop occurred. Main KPIs of the Drive-Tests are presented in the next table:

Figure 34 - Drive-Test KPI


Regarding RxLev distribution, most of the samples are located on the [-60dBm; -70dBm[ interval, a good indication of good coverage in the main roads. Also, only a very small number of samples


is having more than -80dBm.

Figure 35 - RxLev Distribution

For RxQual, more than 80% of the samples have value 0 and almost none above 5. Measured quality of signal is showing very good performance.

Figure 36 - Rate of Samples per RxQual

HO Issues and Call Drop were observed in Corniche Rd between 32nd Str and 18th Str. In all the remaining areas no Handover Failures and Dropped Calls were registered. During tests in Corniche Str, a normal HO occurred from cell W_W8_F to W_W11_Khalidiah_park_A. Then, as soon as the MS started to move away from the serving cell, RxLev dropped to values worst than -100dBm and also with very poor RxQual. However, at the time, some good neighbors were reported:

• First, W_W10_C54_A (RxLev around -65dBm) • Later W_Central_Furniture (RxLev around -70dBm)

No HO relation is declared between W_W11_Khalidiah_park_A and W_W10_C54_A or W_Central_Furniture. Due to the very poor radio conditions, call dropped. Next call was initiated in W_Kaser_Macro_A, also not a declared neighbor cell of W_W11_Khalidiah_park_A.



Figure 37 - RxQual and Events

3 HO Failures occurred after in cell W_W45_F, on the attempt to D_W_COW3_Yasalam_2012_A. Message received is related to:

Handover Failure Skip Indicator : 0 Protocol Discriminator : (6) Radio resources management messages Message Type : 40 Value : (111) Protocol error, unspecified

Issue is linked to: RR Timer Timeout : T3124 T3124: This timer is used in the seizure procedure during a hand-over, when the two cells are not synchronized. Its purpose is to detect the lack of answer from the network to the special signal. Its value is set to 675 ms if the channel type of the channel allocated in the HANDOVER COMMAND is an SDCCH (+ SACCH); otherwise its value is set to 320 ms. No radio issues were found and main KPI of the cell is good. Once this is a new site to cover a special event, issue must have occurred in an integration phase. In addition, from the remaining DT some other missing neighbors were detected:

• V_W_W8_Corniche_C <-> W_W10_C54_B • E_Corniche_E1_PH <-> E_Corniche_E5_D • E_E11_C125_A <-> E_East2_A



4. Frequency Plan Audit Frequency Plan analysis was performed in a global way, due to the wider impact of the frequencies, not confined to the BSC. Also, this type of analysis gives a better overview on the Frequency Plan’s issues. In summary we can observe 3 main problems:

• No strategy defined for Hopping System – Different types of hopping and also non-hopping co-exist in the same area. It is recommended the usage of the same Hopping Type in the entire network.

• No split between BCCH and TCH channels – All channels are used for both BCCH and TCH. As a good practice, a division is always preferable between the 2 types of frequencies so that optimization can be performed in an easier way and the introduction of new cells/TRXs could be better performed.

• Frequencies not used in a homogeneous way – Re-use of certain frequencies is much higher than others, meaning that frequency re-use is not being performed in a very efficient way. A complete frequency plan must be computed for a more reliable usage.

Number of cells per frequency band and Hopping Type usage can be seen below:

Figure 38 – Nb of Cells per Frequency Band and Hopping Type

No pattern could be observed in the type of hopping to be used in the network. Baseband hopping is the most common, but SFH and No-Hopping co-exist in the same areas. With current configuration some trouble is expected when performing network optimization and also it could be very hard to introduce new cells and TRXs. Any new frequency that might be needed in the network will be hard to calculate. Same type of hopping is recommended to be used in the whole network or at least in areas well defined containing the same type. No clear division is also observed between BCCH and TCH channels, meaning that the same channel is used in certain cells in BCCH and in other’s is included in the Hopping Lists or simply attributed to a TCH channel in Non-Hopping mode. Apart from this, also the distribution of BCCH channels is not made in a homogeneous way, a clear indication that frequency re-use mechanism in the network is not well optimized. As per the graphs below, showing the number of frequency usage in each band, it is easy to



observe that some channels are much more used for BCCH than other’s, and also that most of the frequencies are used in BCCH.

Figure 39 – GSM Channel Usage in BCCH

Figure 40 – DCS Channel Usage in BCCH

The lack of strategy verified in the global frequency plan might not be showing very bad results at the present time, due to a huge effort made in network optimization and frequency tuning. By the graph below, it is possible to observe that RxQual average levels are acceptable and also all the main KPI don’t indicate big issues.



Figure 41 – Average RxQual in BSC MX_West7

However, increased difficulties are found when adding a new cell or new TRXs in the network and the cell by cell analysis and optimization can be much more difficult. Detection of interference cases and the identification of the interferers will be very hard or almost impossible in certain circumstances.



5. Stability Audit This BSS availability and stability assessment is covering 1 BSC MX_West7 from 1st of October till 17th of October 2012. BSS stability assessment helps to get an idea of the network health and so to evaluate the network quality from a system point of view providing measures the BSS system capability to run without problems which is represented by telecom resources availability and by BSS equipment stability. Results Summary for BSC MX_West7

• BSC/N7 availability for MX_West7 is excellent • GPRS average availability is below good range; however this is mainly due to an outage

from 2 days • Some unavailability is noticed for cells GSM but due to planned availability for some sites;

for others, unavailability is in good range • Some transmission alarms observed which could have some impact on availability

5.1. Availability The table below shows the main Availability KPIs on network level just for reference. The analysis for the audit would concern BSC MX_West7



Network AverageMain availability KPI

97.22%Average_TRX_Availability(AVG_TRX_TBA)(%)

100.%Average_SS7SL_Availability(AVG_SS7SL_TBA)(%)

Figure 42 - Availability KPIs for the whole network

Main Availability KPIs on MX_West7 BSC level:

Figure 43 - Availability KPIs for MX_West7

BSC AverageMain availability KPI



96.5%Average_CELL2G_GSM_Availability(AVG_CELL2G_GSM_TBA)(%)

100.%Average_BSC_GSM_Availability(AVG_BSC_GSM_TBA)(%)

93.75%Average_CELL2G_GPRS_Availability(AVG_CELL2G_GPRS_TBA)(%)

BSC AverageMain availability KPI



96.5%Average_CELL2G_GSM_Availability(AVG_CELL2G_GSM_TBA)(%)


Average_CELL2G_GPRS_Availability(AVG_CELL2G_GPRS_TBA)(%) 93.75%

94.57%

94.41%

Average_CELL2G_GSM_Availability(AVG_CELL2G_GSM_TBA)(%)


Average_CELL2G_GPRS_Availability(AVG_CELL2G_GPRS_TBA)(%)

Network AverageMain availability KPI



Average_CELL2G_GSM_Availability(AVG_CELL2G_GSM_TBA)(%)


Average_CELL2G_GPRS_Availability(AVG_CELL2G_GPRS_TBA)(%)

94.57%

94.41%

Observations regarding KPIs:

• Excellent availability of BSC & N7 • Cell GPRS availability below good threshold due to impact of 3 causes

o 2 peaks of unavailability on BSC level on 8/10 & 11/10 o Some cells with planned unavailability for both Cs & Ps

• Cell GSM availability is in acceptable range and mainly impacted by the following: o 2 Cells are having planned unavailability during the whole observation period (due to

possible operator action) o 1 site (4 cells) was having as well planned unavailability on 16/10 & 17/10 o 1 site (3 cells) with unplanned unavailability on 11/10 (but with less outage compared

to planned ones) • TRX availability is in good range

Availability analysis for BSC MX_West7 Table below shows the evolution of main availability KPIs over the observation period:

Average_Availability - BSC: MX_West7 ( MX_West7 ) - 10/01/2012 To 10/17/2012 (Asia/Dubai) (Working Zone: Global - Medium)

00.00%

20.00%

40.00%

60.00%

80.00%

100.00%

10/0

1/20

12

10/0

2/20

12

10/0

3/20

12

10/0

4/20

12

10/0

5/20

12

10/0

6/20

12

10/0

7/20

12

10/0

8/20

12

10/0

9/20

12

10/1

0/20

12

10/1

1/20

12

10/1

2/20

12

10/1

3/20

12

10/1

4/20

12

10/1

5/20

12

10/1

6/20

12

10/1

7/20

12

%

Average_CELL2G_GPRS_Availability(AVG_CELL2G_GPRS_TBA)Average_BSC_GSM_Availability(AVG_BSC_GSM_TBA)Average_CELL2G_GSM_Availability(AVG_CELL2G_GSM_TBA)Average_SS7SL_Availability(AVG_SS7SL_TBA)Average_TRX_Availability(AVG_TRX_TBA)

Figure 44 – Main Availability KPIs

Next section will break-down the availability analysis element by element and highlight the availability observations Alcatel – Lucent 36/57


5.1.1. BSC availability

Table below shows the evolution of BSC availability KPIs over the observation period:

Availability for BSC - BSC: MX_West7 ( MX_West7 ) - 10/01/2012 To 10/17/2012 (Asia/Dubai) (Working Zone: Global - Medium)

0

5000

10000

15000

20000

10/0

1/20

1210

/02/

2012

10/0

3/20

1210

/04/

2012

10/0

5/20

1210

/06/

2012

10/0

7/20

1210

/08/

2012

10/0

9/20

1210

/10/

2012

10/1

1/20

1210

/12/

2012

10/1

3/20

1210

/14/

2012

10/1

5/20

1210

/16/

2012

10/1

7/20

12

s

00.00%

20.00%

40.00%

60.00%

80.00%

100.00%

120.00%

%

Total_BSC_GPRS_BU(BSC_GPRS_TBU)Total_BSC_GSM_BU(BSC_GSM_TBU)

Average_BSC_GSM_unavailable_time(AVG_BSC_GSM_IBU)Average_BSC_GSM_Availability(AVG_BSC_GSM_TBA)

Figure 45 - BSC Availability

BSC GSM availability is 100% during the observation period. However, it can be noted that there is GPRS unavailability on BSC level on 7/10 & 11/10. This could be due to unavailability issues on GPU during those 2 days Alcatel - Lucent 37/57


5.1.2. Cell availability

Availability for CELL2G - BSC: MX_West7 ( MX_West7 ) - 10/01/2012 To 10/17/2012 (Asia/Dubai) (Working Zone: Global - Medium)

0

500000

1000000

1500000

2000000

2500000

3000000

3500000

10/01

/2012

10/03

/2012

10/05

/2012

10/07

/2012

10/09

/2012

10/11

/2012

10/13

/2012

10/15

/2012

10/17

/2012

s

68.25%

73.25%

78.25%

83.25%

88.25%

93.25%

98.25%

%

Total_CELL2G_GPRS_BU(CELL2G_GPRS_TBU)Total_CELL2G_GSM_BU(CELL2G_GSM_TBU)Average_CELL2G_GPRS_unavailable_time(AVG_CELL2G_GPRS_IBU)Average_CELL2G_GSM_unavailable_time(AVG_CELL2G_GSM_IBU)Average_CELL2G_GPRS_Availability(AVG_CELL2G_GPRS_TBA)Average_CELL2G_GSM_Availability(AVG_CELL2G_GSM_TBA)

Figure 46 - Cell Availability

Cell GSM availability is mainly impacted by planned unavailability from the following cells:

• 2 cells were having 0% availability during the overall observation period o D_BLK_W_W18_02_P104_INV_FIN_BROK (22011/41080) o D_W_Crown_Prince_Gen_Serv_Office (22011/3340)

• 4 cells belonging to 1 site were having planned unavailability on 16th & 17th October

o W_W28_A (22011/11241) o W_W28_B (22011/11242) o W_W28_C (22011/11243) o W_W28_D (22011/11244)

There are as well some other unplanned unavailability for some cells (not visible on the graph due to the above mentioned sites high values). The main cells with unplanned unavailability are:

• W_W11_Khalidiah_park_A/B C on 11/10 • V_W_VIP_Qarqashan_Island_B on 10/10

However, by removing the planned availability from the total indicator, graph below can be obtained showing the unplanned availability value which is quite good:



90.00%91.00%92.00%93.00%94.00%95.00%96.00%97.00%98.00%99.00%

100.00%101.00%

10/1/

2012

10/2/

2012

10/3/

2012

10/4/

2012

10/5/

2012

10/6/

2012

10/7/

2012

10/8/

2012

10/9/

2012

10/10

/2012

10/11

/2012

10/12

/2012

10/13

/2012

10/14

/2012

10/15

/2012

10/16

/2012

10/17

/2012

Total cell availability Average unplanned cell availability

Figure 47 - Cell Availability (Total vs Unplanned)

5.1.3. TRX availability

Availability for TRX - BSC: MX_West7 ( MX_West7 ) - 10/01/2012 To 10/17/2012 (Asia/Dubai) (Working Zone: Global - Medium)

0

200000

400000

600000

800000

1000000

1200000

1400000

1600000

1800000

10/01

/2012

10/03

/2012

10/05

/2012

10/07

/2012

10/09

/2012

10/11

/2012

10/13

/2012

10/15

/2012

10/17

/2012

s

96.26%

96.76%

97.26%

97.76%

98.26%

98.76%

99.26%

99.76%

%

Total_TRX_GSM_BU(TRX_GSM_TBU)

Average_TRX_unavailable_time(AVG_TRX_IBU)Average_TRX_Availability(AVG_TRX_TBA)

Figure 48 - TRX Availability



TRX availability is in excellent range (above 99%) except for last 2 days which were impacted by the following elements:

• TRXs of 1 site (4 cells) have planned unavailability on both 16/10 & 17/10 o W_W28_A (22011/11241) o W_W28_B (22011/11242) o W_W28_C (22011/11243) o W_W28_D (22011/11244)

• Cell W_W28_D having some unplanned unavailability for 15 & 16/10

This is the same site appeared as well in cell planned unavailability; so it looks that it had cell/TRE lock action during those 2 days

On the other hand, a few cells were also found having some TRX unplanned unavailability. Those Cells should be checked for possible operational issues on its own TRXs:

• Cell W_W8_B (22011/11782)is having low TRX availability for the duration from 13/10 to 17/10

• W_W11_Khalidiah_park_B (22011/49152)& W_W11_Khalidiah_park_C (22011/49153)on different days but specially on 11,14&16/10

• W_W9_C49_B (22011/12222)on different days but specially on 15/10

5.2. Stability Graph below showing the evolution of alarms per event type. As can be observed, OoS & communication alarms are with the highest occurrences:

Alarms_Split_per_EventType - BSC: MX_West7 ( MX_West7 ) - 10/01/2012 To 10/17/2012 (Asia/Dubai) (Working Zone: Global - Medium)

0

50

100

150

200

250

300

350

400

450

10/0

1/20

12

10/0

2/20

12

10/0

3/20

12

10/0

4/20

12

10/0

5/20

12

10/0

6/20

12

10/0

7/20

12

10/0

8/20

12

10/0

9/20

12

10/1

0/20

12

10/1

1/20

12

10/1

2/20

12

10/1

3/20

12

10/1

4/20

12

10/1

5/20

12

10/1

6/20

12

10/1

7/20

12

nb

QoS_Alarms(QOS_ALARMS)Processing_Error_Alarms(PE_ALARMS)Equipment_Alarms(EQU_ALARMS)Environment_Alarms(ENV_ALARMS)Communication_Alarms(COM_ALARMS)

Figure 49 - Alarm Split per Event Type



Graph below showing the evolution of alarms per severity:

Alarms Split per Severity - BSC: MX_West7 ( MX_West7 ) - 10/01/2012 To 10/17/2012 (Asia/Dubai) (Working Zone: Global - Medium)

0

50

100

150

200

250

300

350

400

10/01

/2012

10/02

/2012

10/03

/2012

10/04

/2012

10/05

/2012

10/06

/2012

10/07

/2012

10/08

/2012

10/09

/2012

10/10

/2012

10/11

/2012

10/12

/2012

10/13

/2012

10/14

/2012

10/15

/2012

10/16

/2012

10/17

/2012

nb

Indeterminate_Alarms(IND_ALARMS)Warning_Alarms(WAR_ALARMS)Minor_Alarms(MIN_ALARMS)Major_Alarms(MAJ_ALARMS)Critical_Alarms(CRIT_ALARMS)

Figure 50 - Alarm Split per Severity

Below graph showing the highest transmission alarms occurrence for BSC MX_West7:

Global Trans. Occurence

0

100

200

300

400

500

600

BS

C-T

RA

NS

[101

] AIS

[1]

BS

C-T

RA

NS

[101

] RA

I [5]

TRU

NK

[36]

AIS

[4]

BTS

-TR

AN

S [1

1] A

IS-2

-MB

[66]

BTS

-TR

AN

S [1

1] B

ER

-10E

-6

[102

]

BTS

-TR

AN

S [1

1] F

AR

-E

ND

-ALA

RM

[176

]

BS

C-T

RA

NS

[101

] LFA

[2]

BS

C-T

RA

NS

[101

] BE

R-

10E

-6 [7

]

BTS

-TR

AN

S [1

1] B

ER

-10E

-4

[100

]

BS

C-T

RA

NS

[101

] BE

R-

10E

-3 [4

]

BS

C-T

RA

NS

[101

] LIS

[0]

BTS

-TR

AN

S [1

1] F

RA

ME

-A

LIG

NM

EN

T [8

1]

BTS

-TR

AN

S [1

1] C

RC

-M

FRA

ME

-ALG

N [8

6]

Count

Figure 51 – Highest Transmission Alarms



Below graph showing the highest alarm occurrence per network object and per specific problem:

Top N Alarm occurrence count among network object per specific problem

0

100

200

300

400

500

600

MX

_Wes

t7 -

BS

C-T

RA

NS

[101

]A

IS [1

]

V_W

_VIP

_Qar

qash

an_I

slan

d_B

(220

11/6

1302

) - G

PR

SD

OW

NLI

NK

TB

F P

RO

BLE

M

VI_

W_S

h_H

amda

n_fa

mily

_hea

lth_c

lu (2

2011

/439

90) -

GP

RS

UP

LIN

K T

BF

PR

OB

LEM

MX

_Wes

t7 -

BS

C-T

RA

NS

[101

]FR

AM

E-S

LIP

[8]

B39

_AU

H_W

ES

T_C

_XX

- R

X-

TX [1

0] H

W-D

EG

RA

DE

D [2

37]

V_W

_VIP

_Qar

qash

an_I

slan

d_B

(220

11/6

1302

) - G

PR

S U

PLI

NK

TBF

PR

OB

LEM

MX

_Wes

t7 -

BS

C-T

RA

NS

[101

]R

AI [

5]

MX

_Wes

t7 -

TRU

NK

[36]

AIS

[4]

W_W

11_K

halid

iah_

park

_A(2

2011

/491

51) -

GP

RS

UP

LIN

KTB

F P

RO

BLE

M

W_A

UH

_WE

ST_

B (2

2011

/124

2)- G

PR

S U

PLI

NK

TB

F P

RO

BLE

M

Count

Figure 52 - Highest Alarm Coccurence per Network Object and per Specific Problem



6. Architecture Audit Analysis to BSS Architecture was made considering the whole network but with focus in BSC MX-West7 and related MFS, MFS607. Current network status is:

• SW release: B11 MR3 Ed.1.1 QD4 • Network Architecture

o 72 BSCs (52 G2 BSC and 20 Mx BSC) 52 G2 BSC, all in config.6 (448 TRX) 20 Mx BSC, all in config.15 (1000 TRX) and with HSL (1 link per BSC)

o 29624 TRX (27968 TRX operational o 6717 Cells o 4719 BTS o 6 MFSs (all Mx MFS)

97 GP boards each G2 BSC has one GP board (between 2 and 4 AterPS links per board) 17 Mx BSC have 2 GP boards each (between 4 and 8 AterPS links per board) 1 Mx BSC has 3 GP boards (with 8 AterPS links per board) 2 Mx BSC have 4 GP boards (between 4 and 8 AterPS links per board)

6.1. BSC Configuration BSC configuration for CS can be found below, divided by MFS:



Figure 53 – CS BSC Configuration

For PS configuration is as following:



Figure 54 - PS BSC Configuration



6.2. MFS Configuration

All the 6 MFS have the following configuration:

Figure 55 - MFS Configuration

With the following GPs:



Figure 56 - MFS GP Configuration

From the data presented, we can observe that the number of TRE configured is exceeding the recommended limit of 80% in case of G2 BSCs and 95% in case of Mx BSCs. As example we have:

• G2 BSC Mafraq13 has 440 TRE configured (Max nb is 448) • Mx BSC MX_Reem1 has 1016 TRE configured (Max nb is 1000)

Also, all Mx BSCs are using HSL for N7 and they have a single E1 link configured. Recommended implementation considers 2 HSL links per BSC (even if there is no end-user impact except in case of link failure). All Gb links are well configured (each GP board has 2 Gb links).



6.3. Traffic Load

Considering CS Traffic Load, no issues were detected with following scenario in the BSCs:



Figure 57 – CS Traffic Load

Regarding PS Traffic Load, some problems were already found:



Figure 58 - PS Traffic Load

According to Traffic Load and Dimensioning analysis it is possible to conclude that for CS scenario dimensioning is correct. All BSC have enough AterMuxCS links configured and even, the number of links for CS is over-dimensioned.



This reality is different on the PS Traffic Load side, where several problems were found, especially for G2 BSCs. It is visible that the number of GP boards per BSC is correctly defined, with no GP overload. On the other hand, the number of ExtraAbisTS configured is very small, what can limit the PS traffic at Abis level. Traffic limitation at BSC level is coming from the number of AterPS links:

• 41 G2 BSC from a total of 52 have not enough AterPS links and are presenting Ater congestion. The number of AterPS needs to be increased with at least 1 link per GP board.

• The BSC South3 has very low traffic, and BSC Mafraq15 has no traffic at all. • In case of Mx BSCs the status is better and only 1 BSC needs more AterPS links.

6.4. BSC MX_West7 Details Going to BSC MX_West7, configuration is:

Figure 59 – MX_West7 Configuration

CS Traffic is presenting a normal variation, showing no constraints.

Figure 60 – BSC MX_West7 CS Traffic



In PS, performance was affected by problems during a Shelf Reduction operation, were one of the GP boards became inactive for some days. After the reactivation of this second GP board, traffic variation started again to performing well:

Second GP board

reactivated

Figure 61 - BSC MX_West7 PS Traffic

In terms of GP boards, and after second board became active, the traffic started to be distributed between the two boards and no longer causing Ater congestion.

Figure 62 - GP Traffic





7. Conclusion After the audit performed in one of the most important BSCs for Etisalat, MX_West7, some important outputs were obtained from the different topics. Generally it is visible that network is having a good performance but some issues still need some attention. Also, important to highlight that it is always important to maintain a strategy for network configuration and follow the good network tuning practices. This allows all the activities to be more reliable and efficient, procedures easier to implement and network problems easier to detect. For the BSS Parameter Audit, some issues were highlighted the following aspects:

• HO configuration, where better tuning is needed for better mobility performance • Multiband and concentric cell handovers, to better manage traffic between bands/zones

and avoid traffic in poor conditions • Dwell algorithm configuration, to ensure correct handling of traffic by macro and micro cells • Design parameter revision at BCCH/BSIC for better HO efficiency • Need of a network parameter pattern for better performance and to more efficient and

correct optimization QoS Counter Based Audit with important outputs:

• General good KPI in the network • Punctual issues in the different domains in some cells which need individual analysis, such

as establishment failures, high Call Drop, Low MHT • High HO per call in a significant number of cells affecting QoS and Voice Quality and

indicating issues in configuration As per the Drive-Tests performed and the QoS Audit based on them, it is visible:

• Good results in a end-to-end scenario • Good level of coverage and quality • Some missing HO relations, which lead to 1 Call Drop during the tests

During Frequency Plan Audit some issues related to lack of strategy were identified and also some according to frequency re-use. In summary:

• No strategy was found for Hopping System and where the different hopping types are used in the same area

• No split exists between frequencies for the BCCH and TCH bands, with increased difficulties for new frequency planning and interference detection

• Frequency channels not used in an homogeneous way, showing higher re-use of certain frequencies

Stability Audit considering both Availability and Alarm Stability provided good results:

• BSC/N7 availability for MX_West7 is excellent • GPRS average availability is below good range. However this is mainly due to an outage

from 2 days • Some unavailability is noticed for cells GSM but due to planned activities in some sites. For

the remaining ones, unavailability is in good range • Some transmission alarms observed which could have some impact on availability



Finally the Architecture Audit provided some good outputs regarding network dimensioning: • Good dimensioning in the number of AterCS • Some MFSs with not enough number of AterPS for a big number of BSCs and having Ater

congestion • Number of ExtraAbisTS configured is very small, what can limit the PS traffic at Abis level

etisalat 2g bss audit

Documents