2g & 2.5g optimization nokia india

NOKIA BSS PARAMETERTRAIL TEST & ANALYSIS

1 (136)

NETWORKS, AND SERVICE OPTIMIZATIONSTENIN. N. P 2nd Dec 2007.


2 (136)


The information in this document is subject to change without notice and describes only the product defined in the introduction ofthis documentation. This document is intended for the use of Nokia Siemens Networks' customers only for the purposes of theagreement under which the document is submitted, and no part of it may be reproduced or transmitted iin any form or meanswithout the prior written permission of Nokia Siemens Networks. The document has been prepared to be used byprofessional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia SiemensNetworks welcomes customer comments as part of the process of continuous development and improvement of thedocumentation.The information or statements given in this document concerning the suitability, capacity, or performance of the mentionedhardware or software products cannot be considered binding but shall be defined in the agreement made between NokiaSiemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that theinstructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, ifnecessary, explain issues which may not be covered by the document.Nokia Siemens Networks' liability for any errors in the document is limited to the documentary correction of errors. NokiaSiemens Networks WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENT OR FORANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARY LOSSES), that might arise from the useof this document or the information in it.This document and the product it describes are considered protected by copyright according to the applicable laws.NOKIA SIEMENS logo is a registered trademark of Nokia Siemens Corporation.Other product names mentioned in this document may be trademarks of their respective companies, and they arementioned for identification purposes only.Copyright © Nokia Siemens Networks 2007. All rights reserved


3 (136)


ACKNOWLEDGEMENTS:-

It was indeed quite difficult to acknowledge the entire crowd who had a major influence onthe conception and fruition of this document.To the best of my ability I shall attempt to do so.I would liketo thank Pradeep Chattikal, Prashanth k, Vikrant Arun Dolas, Muthu Krushnan and Rajiv Mohan Gandhifrom Nokia Siemens Network. (India) for their technical support and providing valuable sujections duringthe course of work.I would also like to thank Avnish Kumar from NSN, contributing for IBS solutions forIdea Delhi Network.

My gratitude also to grand me and my team an opportunity of testing several queries andfeatures on Idea cellular Delhi Network and also on some of the Hutch Networks in India.

Date: December 02 2007.

Stenin.N.PNetworks, and Service Optimization.Nokia Siemens Network, India.


4 (136)


Table of contents:-i. EXECUTIVE SUMMARY .........................................................................................4ii. INTRODUCTION ......................................................Error! Bookmark not defined.iii. OBJECTIVE.............................................................................................................71 Voice Audit……….…………………………………………………………………………..8

1.1 Radio Network Capacity and Traffic……………………………………………………81.2 Cell wise Capacity Utilization…………………………………………………………..101.3 Spectrum Loading …………………………………………………………………….. .111.4 BSC and A-Interface Capacity and Utilization………………………………………..11

BCSU Utilization and sujections ……………………………………………….121.5 SDCCH Utilization and Failure Observations………………………………………...121.6 LAC Subscribers and Paging analysis ……………………………………………….13

LAC Distribution ……………………………………………………………...…131.7 Handover Cause Distribution ………………………………………………………….171.8 Frequency Utilization …………………………………………………………… …….181.9 Network Discrepancies ………………………………………………………… …… 18

SDCCH Redimensioning Requirement ………………………………………18Basic Parameter Discrepancy ………………………………………………. .19AMR Parameter Discrepancy …………………………………………………20Neighbor Discrepancies ………………………………………………… …..20Path Imbalance …………………………………………………………….....21Ghost SDCCH Analysis ……………………………………………………….21

2. Data Audit………………………………………………………………………………...232.1 Executive summary …………………………………………………………………..232.2 EDGE / GPRS Configuration Settings ……………………………………………..232.3 GPRS / EDGE Parameter Discrepancies …………………………………………242.4 NSCI Plan Review …………………………………………………………………...292.5 RAC Plan Review ……………………………………………………………………302.6 Paging success rate verses LAC Plan ………………………………………….....312.7 Territory Upgrade ………………………………………………………...................322.8 Multi slot allocation …………………………………………………………………..332.9 Sleeping Cells ……………………………………………………….……………….362.10 EDAP Congestion …………………………………………………….……………..372.11 Gb Utilization ………………………………………………………….……………..392.12 Recommendations …………………………………………………………………..40

3 Parameter Audit. …………………………………………………………..….………..413.1 Transcoder Optimization …………………………………………...….…………41

Ignored Transcoder Failure_ITCF …………………………………….………….42Explanation ………………………………………………………..……..…………42Parameter Discreption …………………………………………….……..………..42MML Command …………………………………………………..………..………43Performance Plot ……………………………………………….…………..……..44

3.2 Rx_Level_Min_Cell [SL] ………………………………………….….……….…..46Parameter Discreption ………………………………………….…………….......46Expected Improvement ……………………………………………………….......47Handover Improvement Plot ……………………………………………………...48Drop due to HO Improvement Plot …………………………..……………….....50

3.3 LAPD Timer T200 Optimization …………………………………………………51Software Requirement …………………………………………………………….51Parameter Discreption …………………………………………………………….52


5 (136)


Performance Plot ………………………………………………………………..533.4 Handover Detection Analysis ……………………………………..…..……….54

3.4.1 ND 204 Analysis ……………………………………………….………..553.4.2 Level HO in the Down Link …………………………………………………56

Explanation …………………………………………….……………….56Parameter Descreption …………………………….………………….56

3.4.3 Level HO in the Up Link ……………………………….………………..58Explanation ……………………………………..………………………58Parameter Descreption ……………………..…………………………59

3.4.4 Quality HO in the Down Link ………………….…………………………60Explanation ……………………………….……………………………..61Parameter Discreption ……………….…………………………………61

3.4.5 Quality HO in the Up Link ………………..………………………………..62Explanation ………………………………………………………………63Parameter Descreption …………………………………………………63

3.5 IBS Optimization ……………………………………………… …………………643.5.1 Umbrella Cell Concept …………………………………………………….…643.5.2 Explanation ……………………………………………………………………653.5.3 Parameter Discreption ……………………………………………………….653.5.4 Performance Enhancement Plot ……………………………………………67

3.6 IBS Design Verification and Analysis. ……………………………………683.6.1 Explanation ………….……………………………………………….… ..683.6.2 Cell site Information form ………………………………………………..693.6.3 Trunking Diagran Verification……………………………………………70

3.7 RLT & ARLT Analysis Report……………………………… …………………763.7.1 Parameter Descreption …………...…………………………………….763.7.2 RLT Performance Improvement Plot ………………………………….783.7.3 Explanation ……………………………………………………………….793.7.4 ARLT Improvement Plot …………………………………...……………80

3.8 Congestion Relief using TRHO …………………………………………..………813.8.1 Advantages ……………………………………………………………….813.8.2 Parameter Descreption ………………………………………………….823.8.3 Setting in the switch ………………………………………...…………..823.8.4 Performance Plot …………………………………………………………85

4 Optimizer Cycle…………………………………………………………………………...864.1 Optimizer 2.0 Explanation ……………………………………………………….86

TCH / BCCH Plan Generation ………………………….…………………..87BSIC Plan Generation ………………………………………………………87

4.2 Optimizer Result, Before and After Iterations …………………………………874.3 BCCH and TCH Usage Plot ……………………………………………………..874.4 TRx Interference Distribution ……………………………………………………884.5 Performance Plot …………………………………………………………………89

5 EOSFLEX OPERATIONS ………………………………………………………………...915.1 General Information …………………………………………………………...925.2 Temporary Table ……………………………………………………………….925.3 EOSFLEX Release 5.2 Operations …………………………………………935.4 XML Scripts and bat file ……………………………………………………….945.5 EOS Scheduler …………….........................................................................975.6 Scheduler Script ………………………………………………………………...985.7 Statistics Generated ………………………………………………………….101

6 Alarm Cause study……………………………………………………..………………..1026.1 Alarm Number 7745 ………………………………………….……………………….104


6 (136)


6.1.1 Descreption …………………………………………...………………………1046.1.2 Statistical Analysis ………………………………...………………………….1056.1.3 Field Test Trial ………………………………………………………………..1066.1.4 Script……………..…………………………………………………………….1065.1.5 Performance Plot ………………………..……………………………………106

6.2 Alarm Number 7601 …………………………………………………….……………….1076.2.1 Description ………………………………………………….………………..1086.2.2 Fault Reasons with solutions ……………………….……………………...1086.2.3 Description of supplementry Information ………………………………….109

6.3. Alarm Number 7738 …………………………………….………………………………...1096.3.1 Description ………………………………...………………………………….1096.3.2 Description of supplementry Information ………………………………….1106.3.3 Field Trial ……………………………………………………………………..110

6.4 Alarm Number 7604 ……………………………………………………………………….1146.4.1 Alarm Description ……………………………….…………………………...1146.4.2 Fault Reasons and Solutions ……………….………………………………1146.4.3 Supplementary Information..…………………………………………………115

6.5 Alarm Number 7744 …………………………………………………….…………………1166.5.1 Alarm Description ……………………………………………………………1166.5.2 Supplementary Information..…………………………………………………115

6.6 Alarm Number 7606 ………………………………………….…………………………...1176.6.1 Alarm Description ………………………………..………………………….1176.6.2 Fault Reasons and Solutions …………….……………………………….117

7 Drive test Analysis………………………………………………………………………….1187.1 Check List for Cell site………………………………………………………….1187.2 Basic Information…………………………………………………….………….1187.3 Idle Mode Information…………………………………………………………..1187.4 Dedicated Information…………………………………………………………..1197.5 Handover Information…………………………………………………………...1197.6 Data Drive Information GPRS………………………………………………….1197.7 Radio Efficacy Check……………………………………………………………1207.8 Benchmarking Drive using Swis Qual 7.5…………………….……………….121

7.8.1 Drive Test Session ……………………………………………………...1227.8.2 Data Service Drive test Measurement ………………………………..1227.8.3 Executive summary Voice ……………………………………………..1237.8.4 Executive summary Data ………………………………………………1237.8.5 Mobile service Quality in Nutshell …………………………………….113

Voice Service Quality Lpot. ……………………………………..124Data Service Performance Plot …………………………………125Summerised KPI Comparision ………………………………….126

8 Nokia Macros …………………..………………………………………………………………...1288.1 Nokai Macro Dictionary for ND…… …………………………………………..………1288.2 Nokia Macro Dictionary for MML ……………………………………………………...1298.3 Details of Nokia Macros ……………………………………………………..…………129

9 Summary of Idea Delhi Optimization………………………………………………………....130Network Performance Plots …………………………………………………………….131

10 APPENDIX………………………………………………………………………….…………….137


7 (136)


i. INTRODUCTION:-

The heigh marketing demand for better efficacy in the field of Optimization with less ofinvestement on the cellular Network has lead to conduct several Test Trials, which are summerised intoone single document. The test was done on technologies like GSM, GPRS and EDGE for both Voiceand Data. The document also covers some of the critical Alarms and the way forward to handle theseAlarms. Some of the methods that were adopted to achieve good Key performance Indicater were alsocovered for performance enhancement of Cellular Network.


8 (136)


1. Voice AuditNetwork Audit for GSM Network carried out with analysis of different Nokia ND Reports and OSS

Extracted statistics .The Voice Audit gives an understanding of the GSM Network and the discrepanciesin the Network, which can be corrected on time to time basis for better Efficacy of Network Operation.

1.1 Radio Network Capacity and Traffic.

This gives details of the Network taken for Voice Audit as listed below as for Idea CellularDelhi (India).

Observations Idea_Cellular-Delhi:Total Cells in the Network 3563

Total Sites:Metro= 128Total Sites: Ultra= 1234Total Sites in the Network 1362Total TRX in the Network 10569

BTS Software Version: S 11.5 CD 6.0BSC Software Version: S 11.5 CD 6.0OSS Software Version: OSS 4 CD 3.0Switch Software Version: M12 CD 3.0

Traffic Split is as follows :(For 13th June 2007 from Dashdoard).


9 (136)



10 (136)


1.2 Cell wise Capacity Utilization

Cell wise capacity utilization Idea Cellular Delhi:

Number of cells which are utilized more than 90% in Idea cellular Delhi Network tend towards a percentage of 44.And there are also 6% of cells that are Under Utilized.Utilization of cells can be planned appropriately for Idea Cellular Delhi Network.

Total Operational Cells in the Network 2993 for Idea Cellular DELHI Circle


11 (136)


1.3 Spectrum Loading.

1.4 BSC and A-Interface Capacity and Utilization

Observations:

Total number of BSCs :22 BSC versions used :5 BSC ( BSC 2i ) & 17 BSC ( BSC 3i) BSS software load :S11.5 CD 6.0


12 (136)


BCSU CAPACITY UTILIZATION Idea Cellular Network.

NOTE: BSC which have High Utilization can affect theperformance of the BSC.Thus cells can be reprantedappropriately.

NILNIL8.0 Mgh40

1.5 SDCCH Utilization and Failure Observation.

SDCCH availability ........................../ava_63a 95.26 %Dynamic SDCCH allocation (TCH reconfigured to SDCCH )Attempts………/c1154 .


13 (136)


T3101 expired (S7) .........................../c57020 4658584 7.56%SDCCH drop ratio without T3101 expiry....../sdr_4 1.78 1.78%

NOTE: There seems a lot of SDCCH Utilized for Location Updates, for which The LAC Re-Dimension will be carried out appropriately.

NOTE: The major share of the drop at the SDCCH is seen due to T3101 Expiry and also atthe Abis.

1.6 LAC Subscribers and Paging analysis.

There are 26 LAC Created under 3 MSC. Cells planned under different LAC are as shownbelow.


14 (136)


Comment:The cells distributed under Different LAC are seen uneven.As some of the LAC has largenumber of cells defined under them where as some other have few cells definedThe distribution can be done according to study made with respect to Paging Load and Locationupdate.Possibility of site rehoming, etc.LAC Distributed for Idea Cellular DELHI is as shownbelow.


15 (136)


Cells of the same Site are given different LAC.LAC distribution is seen uneven in some of the geographical area for Idea Cellular Delhi,whichcan cause High signaling load due to high usage of SDCCH.


16 (136)


LAD redimensioning requirement for the following cells for Idea Cellular Delhi:The cell listed in the attachment requires LAC Changes appropriately, to reduce signalling Load in theNetwork.


17 (136)


FOR HANDOVER Idea Cear DELHI:1.7 Handover Cause Distribution1.7USES FOR HANDOVER Idea Cellular DELHI:CAUSES FOR HANDOVER Idea Cellular DELHI:

Recommendation:From the cause for Handover Network wide.The power budget Handover can be further

improved from a value of 29.31%.Interfering frequency requires correction appropriately to reduce the Handover due to

interference as shown there is 14.66 % Ho, due to DL Interference.

NOTE: The most critical is the DL Interference of 14.66 demanding correction immediately.


18 (136)


1.8 Frequency Utilization:Frequency Distribution Idea Cellular Delhi.

NOTE;The BCCH Plan for Idea Cellular Delhi shows the difference between the most commonly used BCCHFrequency and the Least BCCH Frequency used in the Network.

1.9 Network Database Discrepancies :

With appropriate Nokia ND reports the following Discrepancies were found when Network Audit forVoice was conducted for Idea Cellular Delhi Netwrork.

SDCCH Redimensioning Requirement.

NOTE- SDCCH RE-Dimensioning Requiremnt for Cells having High SDCCH Blocking (Considering that the cells do nothave time slots Blocked carrying SDCCH denoted by Alarm 7745) .Taking Optimization of SDCCH further, we can haveDynamic SDCCH also switch on for better efficacy of SDCCH.


19 (136)


Basic Parameter Discrepancy:-

Some of the Discrepancies in the parameters were audited for better operation ofCells in the Network.The data taken for audit was from OSS Statistics, ND Reports and BSS Dump.

The above discrepancy includes Prioritising of Cells for their Voice calls, Cells whichare barred from Operations, Call Re establishment requirements, Hysterisis papameter, TemporaryOffsets, Penality time requirements, Power controm Parameter enabled, and Handover papameters.

The above parameter describes the Band Requirement, Transmit power requirement, Accessgrand requirement , Periodic MS location update, Discontinious Transmission, and power budjetparameters.

The above table shows the RTSL which are not in use requiring Checks for those TRX.


20 (136)


AMR Parameter Discrepancy:-

The Discrepancies in the AMR Parameters are listed in the table for Idea Cellular Network.

Neighbor Discrepancies:-The Neighbor Discrepancies for Idea Cellular Network, showing cells which are not

synchronised.

Cells which required Neighbours to be added and as well as to be deleted are done appropriatelywith the analysis of Neighbor Stats taking help of the percentage of Handover attempts for theseperticular cells .


21 (136)


Path Imbalance:-Path imbalance in the cells of the network can be analysed with the help of Nokia ND report 183.This

report can be used to find the Transmitted power inbalance, the sensitivity of both MS and Basae station,High VSWR in these cells.

Note:-For Voltage Standing Wave Ratio (VSWR) the alarm threshold should be set to appropriate valuein advance to a value of about 1.2. So as to indicate if the value shoots more than the set value of 1.2.

The positive value indicates the Imbalance is in the Transmitted Path, and the Negative valueindicates the Imbalance in the Reception path with respect to the Base Transcive Station.

NOTE-Cells having Path Imbalance requires checks like Cable, Transmit Power , Connectors , VSWRetc checked for these cells appropriately

Ghost SDCCH Analysis:-

The Phantom or Ghost SDCCH is due to reasons like Interference Both External and internalInterference in the Network. Parameter Changes requirement for Ghost SDCCH Establishment- IdeaCellular Delhi. By fine tuning changing the training Sequence the Ghost SDCCH can be reduced to anextend in the cell site.


22 (136)


The Training sequence changes required for Non BCCH TRX Only as Listed in the table aboveNote: There should not be any changes made in the Training Sequence for BCCH Trx as, it would bedifficult for a call to macheure, if the Training sequence differes from the BCC on the BCCH TRX of aSector, then there would be difficulty in the calls getting mechured.


23 (136)


2. Data Audit

Network Audit for Data (GPRS / EDGE) Network carried out with analysis of different Nokia NDReports and OSS Extracted statistics .The Data Audit gives an understanding of the Cellular Networkand the discrepancies in the Network related to Data, which can be corrected on time to time basis forbetter Efficacy of Network Operation for smooth and agreed Data Throughput and efficacy.

2.1 Executive Summary on the Network.

MSC: 5 BSC: 22 Sites: 1393 Cells: 4038 TRX: 8517 Spectrum: 6.2 MHz (GSM 900) Radio Network Capacity (Erlang): 36008.65 Radio Network Capacity (Erlang) - Data: 2512.35 VLR Subscribers (Attached): 945594 Registered GPRS Subscribers: 16450 Total BBH Traffic (Erlang): 36358 Total NBH Traffic (Erlang): 33623

2.2 EDGE / GPRS Configuration Settings:

The configuration settings helps to explain the total cells with GPRS and EGPRSEnabled cells in the Network, and of the enabled cells with details of the Dedicated and Default(Switchable) timeslots availability.

GPRS Enabled Yes - 3285 No - 789 (to be verified with MML commands)

EGPRS Enabled Yes - 750 No - 3324

GPRS TRX 1 TRX - 3875 2 TRX - 174 3 TRX - 22 4 TRX - 4


24 (136)


CDED (%) 0 Ts: 1418 cells 1 Ts: 2610 cells 2 Ts: 33 cells 3 Ts: 13 cells

CDEF (%) 0 Ts: 901 cells 1 Ts: 2041 cells 2 Ts: 165 cells 3 Ts: 35 cells 4 Ts: 919 cells 6 Ts: 9 cells 9 Ts: 4 cells

2.3 GPRS / EDGE Parameter Discrepancies

Priority BCCH: 3096 cells Non-BCCH: 978 cells

It is recommended to have at least 2 GTRXs in cells prioritised with BCCH This Priority helps in allocation of Data calls on the enabled priority first,

and then move on to remaining TRx’s.

AlphaBinary Representation ALPHA (ALPHA)

GSM Reference: ETS 300 940 (GSM 04.08)Q3 name: AlphaModification: Online

Range: 0...10 according to the following principle:

0: α=0.0

1: α=0.1

2: α=0.2

...

10: α=1.0

MML default:

MML default: 7 (GSM 800 and GSM 900)

8 (GSM 1800 and GSM 1900)

Description: With this parameter you describe the binary representation of theparameter α.


25 (136)


Related command(s): EUC, EUM, EUO

Note: OPTIONAL (GPRS)

This particular Network has the following Settings as listed below:

Value Total cells:

0.7: 4072 cells 0: 2 cells

Recommended Value: 1

Gamma

GSM reference: ETS 300 940 (GSM 04.08)

Q3 name: Gamma

Modification: Online

Range: 0...62 (dB) with a step size of 2

MML default: 34 (GSM 800 and GSM 900)

36 (GSM 1800 and GSM 1900)

Description: With this parameter you describe the binary representation of the parameter τ chfor MS output power control.

Relatedcommand(s):

EUC, EUM, EUO


This Network has the following settings as listed below.Value Total Cells.

18: 3812 cells 26: 6 cells 34: 256 cells



26 (136)


AGCH

Access Grant Channel requirement for the Network depends on the kind of Mode.That is Combined and Non Combined Mode.If combined mode ie (BCCH + SDCCH) then the requirement for AGCH is 1, and is NonCombined mode ie separate BCCH and Separate SDCCH, then AGCH requirement is 2.


1: 2 cells 2: 4072 cells

Recommended Value: 2 The Recommended value is taken as 2, since most of the cells in the GSM

network are found to be with Combined Mode.

BFG / TRP:Prefer BCCH frequency GPRS (BFG)

GSMreference:

No ref.

Q3 name: preferBCCHfreqGPRS2

Modification: You can modify the BFG parameter online when the value of the GENAparameter is N. If the value of the GENA parameter is Y, you must lock theBTS before modifying the BFG parameter.

Range: 0…2

MML default: 0

Description: With this parameter you define whether the BCCH TRX or other TRXs arepreferred in GPRS channel allocation.

Relatedcommand(s):

EQV, EQO

TRX priority in TCH allocation (TRP)

GSM reference: No ref.


27 (136)


Q3 name: trxPriorityInTCHAlloc


Range: 0…3

MML default: 0

Description: With this parameter you define whether the BCCH TRX or other TRXsare preferred in traffic channel allocation.

Relatedcommand(s):

EQM, EQO


BFG = No; TRP = 1: 300 cells BFG = No; TRP = 2: 3096 cells BFG = Yes; TRP = 2: 678 cells

It is recommended to have at least 2 GTRXs in cells prioritised with BCCH

IFPIdle mode signal strength filter period (IFP)


Q3 name: TAvgW


Range: 0...25

MML default: 9

Description: With this parameter you control the signal strength filter period for power controlin the packet idle mode.

Relatedcommand(s):

EUC, EUM, EUO



28 (136)



9: 4065 cells 0: 9 cells


TFPTransfer mode signal strength filter period (TFP)


Q3 name: TAvgT


Range: 0...25

MML default: 13

Description: With this parameter you control the signal strength filter period for powercontrol in the packet transfer mode.

Relatedcommand(s):

EUC, EUM, EUO



0: 4065 cells 1: 2 cells 0: 7 cells


NOTE: It is recommended to have at least 2 GTRXs in all cells prioritised as BCCH NOTE: Many cells need additional GTRXs / Value of CDED / CDEF to be increased

A sample list (top 50 such cells) is attached herewith NOTE: Also many cells are defined with additional GTRXs than required. This would lead

to PCU congestion in future and is hence recommended to be reduced The cells which do not require additional channel seizures (ach_3 = 0) can be re-

Dimensioned to 2 GTRXs after analysing the CDED / CDEF %. A sample list (cells with more than 3 GTRXs) is attached herewith


29 (136)


2.4 NSEI Plan Review.Network Service Control Information Elements (IEs)

NSEI plan to be re-worked NSEI should be planned on a geographical basis

The Cell sites which are closely located geographically, are expected to have the same NSEI tobe used, else may have a possibility of Inter PCU reselection which can constitute to increasedsignaling and in turn reduction in the overall throughput


30 (136)


NSEI – Current Plan Review:

Few NSEIs have exceeded the capacity (64 cells) as highlighted in the circled regions Many NSEIs have exceeded the recommended threshold (48 cells) as highlighted in the circled regions,

while some have very few cells associated to them. PCU re-dimensioning to be done on priority to improve performance and also ensure better

utilisation of PCU resources.

2.5 RAC Plan Review.Routing area code (RAC)

GSMreference:

GSM 04.60

Q3 name: Rac



31 (136)


Range: 0.. 255

MML default: 255

Description: With this parameter you define the routing area code in the adjacent cell. In theadjacent cell creation if this parameter is not given and the SEG and the adjacentcell are in the same BSS, the value of this parameter is copied from the SEG.

Relatedcommand(s):

EAC, EAM, EAO


2.6 Paging success rate verses LAC Plan

Few sites have different LACs even amongst their cells as highlighted in the circled regions. This needs to be rectified on priority.


32 (136)


2.7 Territory Upgrade.

Territory Upgrade Success Rate is 96.338 % 3.662 % of the Territory Upgrade requests are blocked (totally denied) 2.721 % of the Territory Upgrade requests are blocked due to high CS Traffic load 0.940 % of the Territory Upgrade requests are blocked due to lack of PCU Resources (high PCU

congestion) 30.529 % of the successful Territory Upgrades are served with lesser radio time slots than

requested

PCU Congestion.

CS Traffic.


33 (136)


2.8 Multi slot allocation

2911

65 10 7 2

0

500

1000

1500

2000

2500

3000

# Cells

Blocking % DL Multislot Blocking %

DL Multislot Blocking % 2911 65 10 7 2

< 1% >= 1% < 5% >= 5% < 10% >= 10% < 20% >= 20%


34 (136)


DL Multislot Blocking rate is 0.096 % 49 (out of 2992 cells reported) cells have DL Multislot blocking > 1% on a network level

This is primarily due to lack of radio resources (insufficient time slots). This can be rectified by TRX addition, & removing faulty / bad time slots from the

network (Alarm 7745 may be used for this purpose).

DL Multislot BlockingLow Allocated Success Rate.


35 (136)


High Blocking:

DL Multislot Allocation Success:

DL Multislot Allocation Success rate is 81.245 % 990 (out of 2992 cells reported) cells have DL Multislot Allocation success > 90 % on a network

level Majority of the requests are not entirely denied, but served with lesser Tsl. This can be improved if equipped with more than 1 GTRX / cell

870

120

395

869

590

148

0

100

200

300

400

500

600

700

800

900

# Cells

Blocking %

DL Mult islot Allocation Success %

DL Multislot AllocationSuccess %

DL Mult islot Al locat ion Success % 870 120 395 869 590 148

>= 99% >= 90% < 99% >= 80% < 90% >= 70% < 80% >= 60% < 70% < 60%


36 (136)


2.9 Sleeping Cells Two main categories

Sleeping GPRS (filter N0) – ava_71 No data activity (filter N1) – ava_72 Sleeping GPRS (ava_71) further divided into the following sub-categories

Zero TSL (N10) Bouncing GPRS (N20) High UL TBF Establishment Fail (N30) UL no DL (N40) High DL TBF Fail (N50)


37 (136)


The above analysis is done using Nokia ND Report 239.

2.10 EDAP Congestion

High no. of rejections are observed due to inadequate / no EDAP resource. Multislot allocation and throughput get affected due to this Capacity enhancement would be required for these cells Recommended to have adequate Abis pool devices for EGPRS

High rejections also observed due to lack of PCU resources PCU re-dimensioning to be done on priority

153

66

518

222

118

1225

390

915

0

200

400

600

800

1000

1200

1400

# Cells

BSC

TBFs without EDAP DL

TBFs without EDAP DL

TBFs without EDAP DL 153 66 518 222 118 1225 390 915

5 49 6 34 1 2 5 10

41350

22574

13658

88265

13421 13946 1277517472

28013 27838

1284410453

36097

27739

20573

119929

27971

11994

61714

0

20000

40000

60000

80000

100000

120000

# Cel ls

BSC

TBFs w ith inadeq. EDAP DL

TBFs w ith inadeq. EDAP DL

T B F s with inadeq. ED A P D L 41350 22574 13658 88265 13421 13946 12775 17472 28013 27838 12844 10453 36097 27739 20573 119929 27971 11994 61714

15 18 8 4 2 44 79 10 3 18 72 46 11 5 6 6 1 5 10


38 (136)


TBF without EDAP DL

TBF with inadequate EDAP DL


39 (136)


Limited by PCU

2.11 Gb Utilization

Most of the Gb links are with CIR of either 64k or 128k Certain links have crossed their threshold levels or are nearing them as

highlighted in the circular regions Recommended to increase the capacity on these links


40 (136)


2.12 Recommendations:

It is recommended to configure GPRS on BCCH TRX, provided there is no limitationon the PCU

Since the power on the BCCH TRX is maintained to be constant, the signalinghappens in a good RF environment, as compared to Non-BCCH TRX

The BCCH carrier, is also maintained to be cleaner than the hopping TCH layer,thereby reducing the interference on the BCCH layer

It is recommended to have at least 2 GTRXs in all cells prioritised as BCCH Since the TSLs available on the BCCH TRX is limited, it is recommended to have

at least 2 GTRXs, to assist in territory upgrades Geographical allocation of RAC and NSEI

This will aid in better utilisation of the PCU resources, thereby enhancing theperformance of the network

PCU re-dimensioning to be done on priority This will aid in better utilisation of the PCU resources, thereby enhancing the

performance of the network


41 (136)


3. Parameter Audit.Different Nokia Parameters are audited for their better Performnace with the Help of statistics

analysis and Field Test Trials.

3.1 Transcoder Optimization.

1 © Nokia Siemens Networks Presentation / Author / DateFor internal use

XCDR Optimization(ITCF). Performance ReportIdea Cellular Delhi23rd-July-2007

Stenin.N.PNetworks, and Service Optimipation.Nokia.India.


42 (136)



Transcoder Optimization was carried out on several BSC’s of IdeaCellular Delhi which was Dropping calls on the basic of TranscoderFailure:-

Parameter Fine tuning was carried out on the BSC Level with the help of Parameter ITCF(Number of Ignored Transcoder Fail) .

This Parameter is used to check how many Transcoder Failure the system will receive before it Releases aparticular calls.

Explanation:After a speech path connection has been established between the BTS and the TC, they try to align

with each other to enable speech coding both in uplink and downlink directions. If the alignment procedurefails, speech decoding also fails and speech is no longer audible. In this case, the BTS sendsCONNECTION_FAILURE_INDICATION message to the BSC. The BSC requests for a clearing and thenreleases the resources connected to the call. The cause field in this failure indication message is "REMOTETRANSCODER FAIL”

When more aggressive HR is introduced, due to the interference in the air interface and signalingmessages can be lost. Re-sending the messages one or more times can lengthen the call establishmentdramatically and this might lead to trigger of REMOTE TRANSCODE FAIL counters.

Description:-ITCF:-Number of ignored transcoder Failures.

This parameter defines ,how many successive remote transcoder failure the BSC may receive beforereleasing the particular Call.

Range: 0 to 5Default: 0. Nokia Tested (2)


43 (136)


1 © N ok ia S iem en s N e tw o rks P res en ta tion / A u th o r / D a teF or in tern a l us e

IT C F P a ra m e te r fro m M M L :-W ith th e h e lp o f m m l c o m m a n d “Z E E O :A L L ” , th e s ta tu s o f IT C F ca n b e fo u n d o n th e B S C L e ve l.

4 © N o k ia S ie m e n s N e tw o rks P res e n ta tio n / A u th o r / D a teF or in tern a l u s e

P e rfo rm a n c e P lo t B D 0 1 7 :


44 (136)




6 © N o k ia S ie m e n s N e tw o r k s P r es e n ta tio n / A u th o r / D a teF or in te r n a l u s e



45 (136)


7 © N o k i a S i e m e n s N e t w o r k s P r e s e n t a t i o n / A u t h o r / D a t eF o r i n t e r n a l u s e

P e r f o r m a n c e P l o t B D 0 2 0 :


TCH Drop Network Level Idea Cellular Delhi:

TCH Drop callImprovement

Thus there was improvement on TCH Drop which was due to Transcoder failure, and there by enhancingTCH Drop Call Performance on the Network Level.


46 (136)


3.2 Rx Level Min Cell (SL).


ParameterOptimization Performance Reprot.Rx_Lev_Min_cell (SL)Idea Cellular Delhi31st-July-2007

Stenin N.P………………Nokia Siemens Network.


47 (136)



Rx_Level_Min_Cell (SL) ,Optimization Performance :-

Rx_Level_Min_Cell (SL) Parameters was fine tuned for Four BSC’s (BSC02 ,BSC05,BSC15,BSC12) for Idea Cellular Delhi Network.

Description :-Rx_Lev_Min_Cell (SL):-

This Parameter defines the minimum signal level of an adjacent cell when an handover is allowedto the Neighboring cell.

Range: -110 to -47 dBm.Default: -100 dBm. Nokia Tested (-92dBm)

Note : The Value for SL can be Fine tuned to a value of -96dBm for Border Cells in the network for betterPerformance Enhancement.

Expected Improvement:- With this Parameter fine tuning there should be improvement in“ Handover success Rate” and also Enhancement in “drop Call” which were dropping due tohandover.


48 (136)


3 © N o k ia S ie m e n s N e t w o r k s P r e s e n t a t i o n / A u t h o r / D a t eF o r in t e r n a l u s e

H a n d o v e r Im p r o v e m e n t ( B S C 0 5 ) : -

B S C - 0 5 - H O S R I M P R O V E M E N T

1

1 0

1 0 0

1 0 0 0

1 0 0 0 0

2007-0

7-1

6

2007-0

7-1

7

2007-0

7-1

5

2007-0

7-1

8

2007-0

7-1

9

2007-0

7-2

0

2007-0

7-2

1

2007-0

7-2

2

2007-0

7-2

3

2007-0

7-2

4

2007-0

7-2

5

2007-0

7-2

6

2007-0

7-2

7

2007-0

7-2

8

2007-0

7-2

9

2007-0

7-3

0

ER

L

0

1

2

3

4

5

6

T C H T r a f f ic ( E lr ) T C H d r o p S d c c h D r o p H O F A IL P o ly . (H O F A IL )

d a te o f im p l im e n ta t io n


D ro p c a ll d u e to H a n d o v e r : Im p ro v e m e n t (B S C 0 5 ).


49 (136)


5 © N o k ia S ie m e n s N e t w o r k s P r e s e n t a t io n / A u t h o r / D a t eF o r in t e r n a l u s e

1

1 0

1 0 0

1 0 0 0

1 0 0 0 0

20

07

-07

-16

20

07

-07

-17

20

07

-07

-15

20

07

-07

-18

20

07

-07

-19

20

07

-07

-20

20

07

-07

-21

20

07

-07

-22

20

07

-07

-23

20

07

-07

-24

20

07

-07

-25

20

07

-07

-26

20

07

-07

-27

20

07

-07

-28

20

07

-07

-29

20

07

-07

-30

0

1

2

3

4

5

6

7

T C H T ra f f i c (E l r) T C H d ro p Sd c ch D ro p H O F A I L P o l y . (H O F A I L )

E rl %

d a te o fim p lim e n ta tio n

B S C -0 2 H O S R Im p r o v e m e n t

D e g r a d a t io n is d u et o R e -H o m in g .

R e s o lv e d o n 3 0 th

6 © N ok ia S iem en s N etw orks P res en ta tion / A uth or / D ateF or in tern a l us e

D rop ca ll due to H ando ver: Im provem ent (B S C 02 ).


50 (136)


7 © N o k ia S ie m e n s N e t w o r k s P r e s e n t a t io n / A u t h o r / D a t eF o r in t e r n a l u s e

H a n d o v e r Im p r o v e m e n t ( B S C 1 5 ) : -

B S C - 0 1 5 - H O S R IM P R O V E M E N T

1

1 0

1 0 0

1 0 0 0

1 0 0 0 0

20 0

7 - 07 - 1

6

20 0

7 - 07 - 1

7

20 0

7 - 07 - 1

5

20 0

7 - 07 - 1

8

20 0

7 - 07 - 1

9

20 0

7 - 07 - 2

0

20 0

7 - 07 - 2

1

20 0

7 - 07 - 2

2

20 0

7 - 07 - 2

3

20 0

7 - 07 - 2

4

20 0

7 - 07 - 2

5

20 0

7 - 07 - 2

6

20 0

7 - 07 - 2

7

20 0

7 - 07 - 2

8

20 0

7 - 07 - 3

0

ER

L

0

1

2

3

4

5

6

7

T C H T ra f f i c ( E l r) S d c c h D ro p T C H d ro p H O F A I L P o l y . (H O F A I L )

d a te o f im p l im e n ta t io n

9 © N o k ia S ie m e n s N e tw o r ks P r es e n ta tio n / A u th o r / D a teF or in ter n a l u s e

H a n d o v e r Im p ro v e m e n t (B S C 1 2 ): -

B S C -0 1 2 H O S R I m p ro v e m e n t

1

1 0

1 0 0

1 0 0 0

1 0 0 0 0

200 7 -07 -1

6

2 0 0 7 -07 -1

7

2 0 0 7 -07 -1

5

2 0 0 7 -07 -1

8

2 0 0 7 -07 -1

9

2 0 0 7 -07 -2

0

2 0 0 7 -07 -2

1

2 0 0 7 -07 -2

2

2 0 0 7 -07 -2

3

2 0 0 7 -07 -2

4

2 0 0 7 -07 -2

5

2 0 0 7 -07 -2

6

2 0 0 7 -07 -2

7

2 0 0 7 -07 -2

8

2 0 0 7 -07 -2

9

2 0 0 7 -07 -3

00

1

2

3

4

5

6

7

T C H T ra ff ic (E lr) T C H d ro p S d cch D ro p H O FA IL Po ly . (H O FA IL )

d a te o fim p lim e n ta tio n

Thus this Parameter can be implemented, Network Wide of Idea Cellular Delhi for Better “HandoverPerformance” Enhancement and “Drop Call” Due to Handover.


51 (136)


3.3 LAPD T200 Timer Optimization.


LAPD-T200 TimerOptimization Performance ReportIdea Cellular Delhi20th-July-2007

Stenin.NP.Nokia Siemens Networks.

Optimization of LAPD-T200 Timer, LAPD-N200 along with LAPD-k Value:-

Fine tuning of Timer LAPD-T200 to enhance SDCCH Drop call rate on BSC18 IdeaCellular Delhi Network.

Minimum Software requirement:NOTE: - To have the Timer LAPD-T200 Modified or to view, the minimum software

Requirements are.BSC Software: S11.5 CD 4.2BTS Software: CX 4.1 CD 2.0

Discription:-LAPD-T200 Timer:-

The Timer T200 Can be optimized to achieve a Maximum time the LAPD (Layer-2)transmitter (at the BSC) will wait for an acknowledgment before making a retransmission.


52 (136)


Range: 220ms to 1000 msecDefault: 220ms. Nokia Tested (780ms)

T200 FACCH = 780msT200 SDCCH = 780ms

LAPD-N200 Counter:-The counter N200 is used to achieve a maximum number of

Retransmission a transmitter will make.

LAPD-K Value:-The K Value decides the maximum number of unacknowledgement frames a

transmitter will allow before holding up the transmission.

The K value is has dependency on the SAPI (Service access Point Identifier)


SDCCH Enhancement after timer T200 was finetuned appropriately from 0ms to780ms (for both FACCH and SDCCH


53 (136)


5 © N o k ia S ie m e n s N e t w o r k s P r e s e n t a t i o n / A u t h o r / D a t eF o r in t e r n a l u s e

T 2 0 0 P e r f o r m a n c e e n h a n c e m e n t :W it h n o D e g r a d a t i o n in T C H D r o p f o r t h is P a r t ic u la r B S C 1 8 .

Thus this Timer T-200 can be finetuned, Network Wide of Idea Cellular Delhifor Better SDCCH Performance Enhancement

3.4 Level and Quality Handover Decission Analysis.


54 (136)


HANDOVER DETECTION ANALYSIS USINGWINDOW, WEIGHTING, THRESHOLD, & NX / PX - OPTIMIZATIONPERFORMANCEFOR LEVEL AND QUALITY HANDOVER CRITERIA.IDEA CELLULAR DELHI.24th Aug 2007 .

Stenin.N.PNetworks, and Service Optimipation.

Nokia.India.

2 © N o k i a S i e m e n s N e t w o r k s P r e s e n t a t i o n / A u t h o r / D a t eF o r i n t e r n a l u s e

H A N D O V E R O P T I M I Z A T I O N P E R F O R M A N C E ,F O R D I F F E R E N T H A N D O V E R C R I T E R I A :I D E A C E L L U L A R D E L H I .2 4 t h A u g 2 0 0 7 .

The Window and Weighting have dependency on the raw measurement done on the SACCH (480msec)for different Handover Criteria’s.


55 (136)


Power Budget UL Power Budget DL Quality Handover UL Quality Handover DL Level Handover UL Level Handover DL Interference Handover UL Interference Handover DL Distance Handover UL Distance Handover DL.

Each of these Handover Criteria have parameters which can be fine tunedsuch as Window size ,Weighting , Threshold and NX and PX Value appropriately for better Performancein Handover of a cellular Network. The analysis done is for Level and Quality based handover.

Statistics from ND 204,with cause values for Handover, Idea Cellular Delhi:-

[ CASE I ]

LEVEL HANDOVER IN THE DOWN LINK:


56 (136)


Parameters associated with Level Handover in the Down Link:

LDWS: Level Down link Window Size.LDW:-Weighting.LDR:-Threshold Level Downlink Rx Level.LDP (Px):-Number of samples to be satisfied out of the Nx.LDN (Nx):-Total Number of Averages.

LDWS: Level Down link Window Size:-Description:-

Parameter calculates average value from signal strength in the DownlinkMeasurement. Window size represents the average window size in SACCH Period.Range:

1 SACCH to 32 SACCH.MML Default:

6 SACCH.Example:-

If LDWS is set to a value of 6,means that for the consecutive 6 SACCH’s in the downlink, it willtake in the level and average it to get one value.The next average will happen between 2nd to 7thSACCH period (For next 6 consecutive SACCH’s). So in this scenario there will be 6 SACCH’s taken intoaccount to make an average as set by LDWS=6 as shown in the diagram below.

LDWS: Level Down link Window Size:-

LDW:-WeightingLDW:-Level Down Link Weighting.Description:-


57 (136)


This Parameter has a dependency on the DTX ( Discontinuous Transmission)If Discontinuous Transmission in the Down link is switched off then the LDW Value should be set to 1,stating all SACCH’s taken into consideration.And in cause if Discontinuous Transmission in the Down link is switched on, then the LDW Value shouldbe set to 2 / 3 appropriately, stating blank speech in between, not a continuous Transmission.Range:

1 to 3.MML Default:

Value of 1.

LDR:-Threshold Level Downlink Rx Level:-Description:-

This Parameter compares the average values of signal strength in the Down link direction fortriggering the handover process. In other words with this parameter one can set the threshold for RxLevel in the downlink. The averages has to overcome the value set by this particular parameter LDR.

Range:-110 to -47dBm.

MML Default:-95 dBm.

LDN(Nx):-Total Number of Averages.Description:-

This Parameter, states number of Averages that have to be taken into account when making aLevel based Downlink handover decision.Range:

1 to 32.MML Default:

Value of 1.Example:- If the value set is 4, then total of 4 averages are used for decision making.

NOTE:-If the decision have to be speeded up or slowed down, this parameter can be reduced orIncremented appropriately.

LDP(Px):-Number of samples to be satisfied out of the Nx .Description:-

This Parameter, states the number of averages that should satisfy the threshold (LDR), out ofthe Total averages (LDN-NX).Range:


Value of 1.Example:- If the value set is 3, then there should be a minimum of 3 averages that should satisfy thethreshold of the total of 4 averages (NX) for a decision making for Level based downlink handover.3(PX) out of 4(NX).

NOTE:-NX should always be greater than PX.

Diagram showing, how decision is made for Level based Downlink Handover:


58 (136)


[ CASE II ]

LEVEL HANDOVER IN THE UP LINK:Parameters associated with Level Handover in the UP Link:

LUWS: Level UP link Window Size.LUW:-Weighting.LUR:-Threshold Level UP link Rx Level.LUP (Px):-Number of samples to be satisfied out of the Nx.LUN(Nx):-Total Number of Averages.

LUWS: Level UP link Window Size:-Description:-

Parameter calculates average value from signal strength in the UPlinkmeasurement. Window size represents the average window size in SACCH Period.Range:


6 ( SACCH Period ).Example:-


59 (136)


If LUWS is set to a value of 6,means that for the consecutive 6 SACCH’s in the UP link, it willtake in the level and average it to get one value.The next average will happen between 2nd to 7thSACCH period (For next 6 consecutive SACCH’s). So in this scenario there will be 6 SACCH’s taken intoaccount to make an average as set by LUWS=6 .

LUW:-Weighting.LUW:-Level UP Link Weighting.Description:-

This Parameter has a dependency on the DTX ( Discontinuous Transmission)If Discontinuous Transmission in the UP link is switched off then the LUW Value should be set to1,stating all SACCH’s taken into consideration.And in cause if Discontinuous Transmission in the UP link is switched On, then the LUW Value shouldbe set to 2 / 3 appropriately, stating blank speech in between, not a continuous Transmission.Range:

1 to 3.MML Default:

Value of 1.

LUR:-Threshold Level UP link Rx Level:-Description:-

This Parameter compares the average values of signal strength in the UP link direction fortriggering the handover process. In other words with this parameter one can set the threshold for RxLevel in the UP link. The averages has to overcome the value set by this particular parameter LUR.

Range:-110 to -47dBm.

MML Default:-95 dBm.

LUN (Nx):-Total Number of Averages.Description:-

This Parameter, states number of Averages that have to be taken into account when making aLevel based UP link handover decision.Range:


Value of 1.Example:- If the value set is 4, then total of 4 averages are used for decision making.

NOTE:-If the decision have to be speeded up or slowed down, this parameter can be reduced orIncremented appropriately.

LUP(Px):-Number of samples to be satisfied out of the Nx .Description:-

This Parameter, states the number of averages that should satisfy the threshold (LUR), out ofthe Total averages (LUN-NX).Range:


Value of 1.Example: - If the value set is 3, then there should be a minimum of 3 averages that should satisfy thethreshold of the total of 4 averages (NX) for a decision making for Level based UP link handover.3(PX) out of 4(NX).


60 (136)


NOTE:-NX should always be greater than PX.

[ CASE III ]

QUALITY HANDOVER IN THE DOWN LINK:Parameters associated with Quality Handover in the Down Link:

QDWS: Quality Down link Window Size.QDW:-Weighting.QDR:-Threshold Quality Downlink Rx Qual.QDP(Px):-Number of samples to be satisfied out of the Nx .QDN(Nx):-Total Number of Averages.

QDWS: Quality Down link Window Size:-Description:-

Parameter calculates average value from quality in the Downlinkmeasurement. Window size represents the average window size in SACCH Period.Range:


1 ( SACCH Period ).Example:-

If QDWS is set to a value of 1,means that for every SACCH (480msec) in the downlink, it willtake in the quality.NOTE:-As in cause of Level varies at a very fast rate compared to Rx Quality. Thus for Quality QDWSthe default is taken as 1,ie decision taken for every SACCH period.QDW:-Quality Down Link Weighting.Description:-

This Parameter has a dependency on the DTX ( Discontinuous Transmission)If Discontinuous Transmission in the Down link is switched off then the QDW Value should be set to1,stating all SACCH’s taken into consideration.And in cause if Discontinuous Transmission in the Down link is switched On, then the QDW Valueshould be set to 2 / 3 appropriately, stating blank speech in between, not a continuous Transmission.Range:

1 to 3.MML Default:

Value of 1.

QDR:-Threshold Quality Downlink Rx Qual:-Description:-

This Parameter compares the values of signal quality in the Down link direction for triggering thehandover process. In other words with this parameter one can set the threshold for Rx Quality in thedownlink. This value has to overcome the value set by this particular parameter QDR.

Range:0 to 7.

MML Default:4 (1.6% to 3.2%).

QDN (Nx):-Total Number of Averages.


61 (136)


Description:-This Parameter, states number of Averages that have to be taken into account when making a

Quality based Downlink handover decision.Range:


Value of 6.Example: - If the value set is 6, then total of 6 averages are used for decision making.

NOTE:-If the decision have to be speeded up or slowed down, this parameter can be reduced orIncremented appropriately.QDP (PX):-Number of samples to be satisfied out of the Nx.Description:-

This Parameter, states the number of averages that should satisfy the threshold (QDR), out ofthe Total averages (QDN-NX).Range:


Value of 4.Example: - If the value set is 4, then there should be a minimum of 4 averages that should satisfy thethreshold of the total of 6 averages (NX) for a decision making for Quality based downlink handover.4(PX) out of 6(NX).

NOTE:-NX should always be greater than PX.NOTE:-In cause of Level, there are two trailing SACCH considered for decision making .But where as forQuality, the sliding average is done only once as QDWS is by default set to one.

Diagram showing, how decision is made for Quality based Downlink Handover:


62 (136)


[CASE IV]QUALITY HANDOVER IN THE UP LINK:

Parameters associated with Quality Handover in the UP Link:

QUWS: Quality UP link Window Size.QUW:-Weighting.QUR:-Threshold Quality UP link Rx Qual.QUP (PX):-Number of samples to be satisfied out of the Nx.QUN (Nx):-Total Number of Averages.

QUWS: Quality UP link Window Size:-Description:-

Parameter calculates average value from quality in the UP linkMeasurement. Window size represents the average window size in SACCH Period.Range:


1 (SACCH Period).Example:-

If QUWS is set to a value of 1, means that for every SACCH (480msec) in the UP link, it willtake in the quality.NOTE:-As in cause of Level varies at a very fast rate compared to Rx Quality. Thus for Quality QUWSthe default is taken as 1, ie decision taken for every SACCH period.

QUW:-Weighting.QUW:-Quality UP Link Weighting.Description:-

This Parameter has a dependency on the DTX (Discontinuous Transmission)If Discontinuous Transmission in the UP link is switched off then the QUW Value should be set to 1,stating all SACCH’s taken into consideration.And in cause if Discontinuous Transmission in the UP link is switched on, then the QUW Value shouldbe set to 2 / 3 appropriately, stating blank speech in between, not a continuous Transmission.Range:

1 to 3.MML Default:

Value of 1.

QUR:-Threshold Quality UP link Rx Qual:-Description:-

This Parameter compares the values of signal quality in the UP link direction for triggering thehandover process. In other words with this parameter one can set the threshold for Rx Quality in the UPlink. This value has to overcome the value set by this particular parameter QUR.

Range:0 to 7.

MML Default:4 (1.6% to 3.2%).


63 (136)


QUN (Nx):-Total Number of Averages.Description:-

This Parameter, states number of Averages that have to be taken into account when making aQuality based UP link handover decision.Range:


Value of 6.Example: - If the value set is 6, then total of 6 averages are used for decision making.

NOTE:-If the decision have to be speeded up or slowed down, this parameter can be reduced orIncremented appropriately.QUP (PX):-Number of samples to be satisfied out of the Nx.Description:-

This Parameter, states the number of averages that should satisfy the threshold (QUR), out ofthe Total averages (QUN-NX).Range:


Value of 4.Example: - If the value set is 4, then there should be a minimum of 4 averages that should satisfy thethreshold of the total of 6 averages (NX) for a decision making for Quality based UP link handover.4(PX) out of 6(NX).

NOTE:-NX should always be greater than PX.NOTE:-In cause of Level, there are two trailing SACCH considered for decision making .But where as forQuality, the sliding average is done only once as QUWS is by default set to one.

2 4 © N ok ia S iem en s N e tw o rks P res en ta tion / A u th o r / D a teF or in tern a l us e

H A N D O V E R D IS T R IB U T IO N B E F O R E A N D A F T E R O P T IM IZ A T IO N(N e tw o rk L e ve l) :-


64 (136)


Thus these parameters can be fine tuned appropriately for Level and Quality for better Handoverperformance. Further fine tuning requirement for improvement Power budget Handover and Handoverdue to Interference for Both UP Link and Down Link on the Network Level after appropriate.

3.5 IBS Parameter Optimization.

IBS OPTIMIZATION PERFORMANCE ,USINGUMBRELLA HANDOVER CONCEPT:IDEA CELLULAR DELHI.4th July 2007 .

UMBRELLA HANDOVER CONCEPT:

Umbrella handovers are used in scenarios, in which the handover is toHappen from external server to in building system.

In the umbrella handover concept, the in building system will have to beset as lower layer (Micro) as seen by external server (Macro).

The umbrella handover concept was applied for IBS site “HYATREG 2”of


65 (136)


Idea Cellular Delhi Network, where there was performance enhancement seen in Handover and TCHDrop Call.

Parameter used for fine tuning:

The above param eters are explained in the previous session, on their operations.

Performance Enhancement Plot:


66 (136)


6 © N ok ia S iem en s N etw orks P res en ta tion / A uth or / D ateF or in tern a l us e

P erfo rm an ce E n h an cem en t P lo t:


67 (136)



Performance Enhancement Plot:

Thus there was improvement in Handover and TCH Drop Call for Site “HYATREG” of IdeaCellular Delhi, with no degradation in performance of the neighboring sites.


68 (136)


3.5 IBS Design Verification and Analysis

The basis IBS Design verification was carried out for one of the IBS Cell at Ideacellular Delhi Network for performance enhancement.

SUMMARY

In- Building survey was conducted for the Park Royal Hotel, Delhi. Summery of thissurvey is as follows:

• Idea is having own IBS implemented in this Bldg.

• Due to uneven EIRP & improper IBS design there are some poor coverage areas insidethe Bldg. & on the window of rooms.

• To improve the coverage & performance of this IBS site we had re-designed the ParkRoyal IBS. This design gives sufficient & even EIRP to all planned antennas inside thebldg.

• As at present we are not having access to put antennas inside the Hotel rooms so wemay not have sufficient indoor coverage at the window of rooms to avoid Idea customerto camp or latch on outdoor signal. On these windows at present we are facing Ping-Pong condition.

• After implementation of new design if we face same problem on the window of Hotel,then we propose the dedicated outdoor site to give the proper indoor coverage inside therooms.

• For the implementation of proposed new IBS design at Hotel Park Royal Hotel, werequire IDEA Delhi team help to get access inside the building & floor plan of all floors ofthis Hotel. Also we require some extra IBS material.

• As per new design antennas are having EIRP between 14 to 19 dBm. In old design EIRPwas 0 dBm to 10 dBm.


69 (136)


BTS CONFIGURATION DETAIL FORM.


70 (136)


The Trunking diagram was modified appropriately with a new Design for better efficacy, byhaving the Metro cell replaced by ultra cell adding in more capacity.And also by splitting the sector tohave a constatnt and high EIRP appropriately.

P A R K R O Y A L H O T E L D E L H I

11

T R U N K IN G D IA G R A M

U L T R A M IN IB T S

S E C T O R 1

1 5 m

L E V E L 4 T O L E V E L 1 1 - G U E S T F L O O R S -S H A F T 1

3 0 m

A

B

C

D

S H A F T 1

S H A F T 2

S H A F T 3

S H A F T 4

A 5 m

5 m

5 m

1 0 m

A 1 -L 4 1 9 .8 5 d B m

A 1 -L 5 1 9 .3 d B m

5 m

1 0 m

A 1 -L 6 1 9 .8 5 d B m

A 1 -L 7 1 9 .3 d B m

5 m

5 m

5 m

1 0 m

A 1 -L 8 1 9 .8 5 d B m

A 1 -L 9 1 9 .3 d B m

5 m

1 0 m

A 1 -L 1 0 1 9 .8 5 d B m

A 1 -L 1 1 1 9 .3 d B m

1 5 m

1 5 m

L E V E L 3


71 (136)


PARK ROYAL HOTEL D ELHI

TRUNK ING DIAGRAM

LEVEL 4 TO LEVEL 11- GUEST FLOORS-SHAFT 3

30m

C 5m

5m

5m

10m

A3-L4 19.85dBm

A3-L5 19.3 dB m

5m

10m

A3-L6 19.85 dBm

A3-L7 19.3 dB m

5m

5m

5m

10m

A3-L8 19.85 dBm

A3-L9 19.3 dB m

5m

10m

A3-L10 19.85 dBm

A3-L11 19.3 dB m

15 m

15m

10m

5m

10m

10

5m

10m

20m

5m

10m

5m

10m

B

10m

30m

A2-L4 17.75dBm

A2-L5 18.3 dB m

A2-L6 17.75 dBm

A2-L7 19.4 dB m

A2-L8 19.95 dBm

A2-L9 19.4 dB m

A2-L10 18.85 dBm

A2-L11 19.4 dB m

A2-L12 18.85 dBm

LEVEL 4 TO LEVEL 12- GUEST FLOORS-SHAFT 2


72 (136)


PARK RO YAL H O TEL D ELH I

TRUNK ING DIAGRAM

LEVEL 4 TO LEVEL 11- G UEST FLO O RS-SH AFT 4

30m

D 5m

5m

5m

10m

A4 -L4 19.85 dBm

A4 -L5 19.3 dB m

5m

10m

A4 -L6 19.85 dBm

A4 -L7 19.3 dB m

5m

5m

5m

10m

A4 -L8 19.85 dBm

A4 -L9 19.3 dB m

5m

10m

A4 -L10 19.85 dBm

A4 -L11 19.3 dB m

15 m

15m


73 (136)


PA R K R O YA L H O TEL D ELH I

TRUNK ING DIAG RAM

ULTRA M INIB TS

SECTO R 2

30m

10m

LEVEL 1- B ANQ UET FLOO R

10m

5m

10m

A1 -L0 15.35 dBm

A2 -L0 14.8 dB m

40m A3 -L0 14.6 dB m

15m

20m

10m

15m

A4 -L0 14..9 dB m

A5 -L0 14.4 dB m

45m

40m

A6 -L0 15.5 dB m

A7 -L0 14.1 dB m

10m

40m

LEVEL 3

LEVEL - 0

15m

40m

5m

15m

A1 -L1 18.2 dB m

A2 -L1 17.2 dB m

30m

30m

A3 -L1 16.2 dB m

A4 -L1 16.2 dB m

30m

5m

25m

A6 -L1 17.9 dB m

A7 -L1 17.2 dB m

5mA5 -L1 18.7 dB m

15m

30m

5m

10m

TO LEVEL S1

7dB

10dB


74 (136)


PA R K R O YA L H O TEL D ELH I

TR U N K IN G D IA G R AM

5m

10m

LEVEL - S2- H EALTH CLUB

LEVEL – S1 20m

30m

20m

20m

20m

15m

30m

15m

A1 -L S1 16.6 dB m

A2 -L S1 15. 5dB m

A3 -L S1 16.6dB m

A4 -L S1 17.1 dB m

A5 -L S1 17.7 dB m

A6 -L S1 16.0 dB m

20m

25m

35m

A4 -L S2 14.65 dB m

A5 -L S2 14.1 dB m

A6 -L S2 18 dB m

A3 -L S2 16.3 dB m5m

10m

15m

A1 -L S2 18.9 dB m

A2 -L S2 18.35 dBm

10m

10m

A7 -L S2-H C 15.8 dB m

A8 -L S2-H C 15.8 dB m

15m

30m

45m

5m

40m

5mA9 -L S2-H C 15.8 dB m

TO LEVEL B2

FRO M LEVEL1

7dB


75 (136)


P A R K R O Y A L H O T E L D E L H I

T R U N K I N G D I A G R A M

5 m

1 5 m

L E V E L – B 2 1 0 m

1 5 m

2 0 m

2 5 m

2 0 m

A 1 - L 7 1 6 .5 d B m

A 1 - L 8 1 5 .9 d B m

A 1 - L 9 1 5 .4 d B m

1 0 m

2 5 m

A 1 - L 1 1 6 .0 d B m

A 2 - L 1 1 4 .3 d B m

4 0 m

1 5 m

3 0 m

A 1 - L 1 1 8 .5 d B m

A 2 - L 1 1 6 .9 d B m

L E V E L – B 1

F R O M L E V E L S 2

7 d B

The EIRP before plan was unevenly distributed with some nodes having very low EIRP when comparedto some nodes with quite high EIRP, which was finetuned in the new design appropriately with the helpof 2 ways to 3 ways couplers.Sectorisation helped in power increment and Capacity enhancement aswell.


76 (136)


3.7 RLT & ARLT Analysis Report.

RLT(RADIO LINK TIMEOUT)ANDARLT (AMR RADIO LINK TIMEOUT)TEST REPORT AND ANALYSIS.IDEA CELLULAR DELHI.29th Aug 2007 .


Nokia.India.

Parameter Description:

RLT:-Radio Link Timeout:-Parameter (RLT) Radio Link Timeout can be fine tuned appropriately to

have performance enhancement on the Drop Call for cells tending to Drop High on TCH.Description:-

This Parameter defines the maximum value of radio link counter expressed in SACCH frame.Range:

0 to 64 SACCH.With a step size of 4 SACCH.

MML Default:Value of 4.Nokia Tested 20 SACCH


77 (136)


ARLT: AMR Radio Link Timeout:-Similarly (ARLT) AMR Radio Link Timeout can be fine tuned appropriately to have

performance enhancement on the Drop Call for cells tending to Drop High on TCH with AMRImplemented.Description:-

This Parameter defines the maximum value of radio link counter expressed in SACCH frame forAMR Calls.Range:

4 to 64 SACCH.With a step size of 4 SACCH.

MML Default:Value of 20.Nokia Tested 36 SACCH

MML COMMANDE @ BSC FOR RLT & ARLT:


78 (136)


Performance Improvement with RLT Fine tuning.

The below performance plot shows how cells had performance enhancement “TCH_COMPLETION_RATE ” after fine tuning RLT from value of 20 to 24 SACCH

Cells improvement in the “TCH_Completion_Ratio” after RLT Fine tuned.


79 (136)


The above Diagram shows how RLT is incremented (Steps of 2) on successful decoding of a SACCH,and also Decrement (Steps of 1) on unsuccessful decoding of Consecutive SACCH.

Similarly ARLT was fine tuned from a value of 20 SACCH to 36 SACCH on the Network Level forIdea Cellular Delhi Network with enhancement in “TCH_COMPLETION_RATIO” as shown in thePerformance plot below.


80 (136)



Performance Improvement with ARLT Fine tuning.TCH Completion Ratio.

50.00

53.00

56.00

59.00

62.00

65.00

68.00

71.00

74.00

77.00

80.00

83.00

86.00

89.00

92.00

23/04/

07

26/04/

07

29/04/

07

02/05/

07

05/05/

07

08/05/

07

11/05/

07

14/05/

07

17/05/

07

20/05/

07

23/05/

07

26/05/

07

29/05/

07

01/06/

07

04/06/

07

07/06/

07

10/06/

07

13/06/

07

16/06/

07

19/06/

07

22/06/

07

25/06/

07

28/06/

07

01/07/

07

04/07/

07

07/07/

07

10/07/

07

TCH Completion Ratio.

ARLT Finetunned to a value of36, dated 7th Aug 2007.

Thus optimizing RLT and ARLT parameters can bring in enhancement in performanceon TCH_COMPLETION_RATIO (TCH Drop Call) appropriately

3.8 CONGESTION RELIEF USING TRHO.


81 (136)


CONGECTION RELIEF USING (TRHO)TRAFFIC REASON HANDOVER,TEST REPORT AND ANALYSIS.IDEA CELLULAR DELHI.30th Aug 2007 .


Nokia.India.

Advantage of TRHO:-

Distributes traffic between cells in close proximity.Increases coverage area of under utilized target cell.Reduces congested coverage area of a particular cell.

Parameter setting for Congested Cell:


82 (136)


1) AMH Upper Load Threshold => AUT.2) AMH Max Load of Target Cell => AML.3) AMH TRHO Guard Time => TGT.4) THRO Target Level {n} => TRHO.5) Rx Level Min Cell {n} => SL.6) AMH TRHO Pbdgt Margin {n} =>ATPM.7) Ho Margin Pbdgt {n} => PMRG.

Parameter setting for Under Utilized Cell:1) Ho Margin Pbdgt {n} => PMRG.

Parameter Setting at the Switch:-MML Commands.To View: ZEPO;

To Modify:1) ZEPI; BTS=“Source & Target cell id” RI=ON; RIM=PER.2) ZEPH; BTS=“Source cell id” TRHO=ON; OUCT=98.3) ZEPH; BTS=“Target cell id” TRHI=ON.

Parameter Description:

TRHO: AMH TRHO TARGET LEVEL:-This Parameter defines the minimum signal level when a traffic reason handover is allowed to

an adjacent cell.This parameter is set in the Neighbor defined in the Source Cell.Range:

-109 to -47(dBm).N (Not used)

MML Default:N (Not in use)Tested value -85dBm.

AMH Advance Multilayer Handling:-AMH Consists of three different features, related to network Load.

a) BSC Initiated TRHO.b) IUO Load Control (Intelligent Underlay Overlay)c) Multilayer Load Control (Dual band network operation)

AMH provided both Capacity and Coverage by distributing traffic evenly over the network.Used especially in 1) Multi band (GSM 900/ GSM 800)

2) Micro cellular or Multilayer (IUO) Network.AMH is used to relief load of a congested cell. AMH Dynamically distributes traffic to appropriate cell /Layer / Frequency band according to load in the Network.To avoid additional handover, back to heavy loaded cell, the AMH has a particular penalty system. Thusmobiles cannot be directed back to original heavy loaded cell before the penalty timer expires.

TRHO: AMH TRHO TARGET LEVEL:-This Parameter defines the minimum signal level when a traffic reason handover is allowed to

an adjacent cell.This parameter is set in the Neighbor defined in the Source Cell.


83 (136)


Range: -109 to -47(dBm).N (Not used)

MML Default:N (Not in use)Tested value -85 dBm.

AUT: AMH Upper Load Threshold:-This Parameter defines the upper threshold for load of the Base station .This parameter

triggers, BSC Controlled traffic reason handover. In other words, the Traffic reason handover will gettriggered in the Congested (Source) cell, when the load of this source cell goes above set value in theAUT (say source cell loaded more than 80%, triggrs TRHO).Range: 0 to 100 or

N (Not used)MML Default: N (Not in use)

Tested value 80.AML: AMH Max Load Of Target Cell:-

This Parameter defines maximum traffic load in the adjacent cell that is allowed to be the targetcell for Traffic reason handover. In other words, when the Traffic reason handover get triggered in theCongested (Source) cell with AUT 80, the target cell where the traffic should be distributed should not beloaded more than 60.

Range: 0 to 100 orN (Not used)

MML Default:N (Not in use)

Tested value 60.TGT: TRHO Guard Time:-

This Parameter defines the guard time after a BSC-controlled or an MSC-controlled TRHO,during which a handover back to the original cell is not allowed. In other words the MS will not bedirected back to the original heavy loadad cell until the time set by TGT is attained.If TGT set to 20 sec,then the handover from target back to source will happen after 20 sec only.Range:

0 to 120 Sec.MML Default:

30Tested value 20.

SL: Rx level min cell:-This Parameter defines the minimum signal level of an adjacent cell when a handover is allowed to the

Neighboring cellRange:

-110 to -47 dBm.MML Default: -100

Tested value -92 dBm.ATPM:AMH TRHO Pbdgt Margin:-

This Parameter defines the guard time after a BSC-controlled or an MSC-controlled TRHO,during which a handover back to the original cell is not allowed. In other words the MS will not bedirected back to the original heavy loadad cell until the time set by TGT is attained.If TGT set to 20 sec,then the handover from target back to source will happen after 20 sec only.Range:

-24 to 24 dBm. Or N.MML Default:

N (Not active)


84 (136)


Tested value -6dBm.

MML COMMAND @ SWITCH, “ZEPO”.

RI: Resource Indication Function:-


85 (136)


Range:On/Off

MML Default:Off

RIM: Resource Indication Method:-

Range:No Indication.Per=Periodic Indication

MML Default: No Indication

TRHO: Traffic Reason Ho function from Cell:-

Range:On / Off

MML Default:Off

TRHI: Traffic Reason Ho function to Cell:-

Range:On / Off

MML Default:Off

OUTC: Out Criterion:-

Range:

MML Default:10%

Nokia Tested 98%

TRHO handover statistics ND 155Check report ND 222

Thus Congestion forms Healy loaded cell can be relived using TRHO appropriately for evenly distributionof traffic in the Cellular Network.

4. Optimizer Cycle


86 (136)


OPTIMIZER CYCLE 2

Date:15th Oct 2007Stenin.Nokia Siemens Networks.

General Information:

Optimizer 2.0 was run for Idea Cellular Delhi Network, with measurements enabled for consecutive threedays having the Network Freeze for this duration.

Optimizer had plans generated for: TCH & BCCH Frequency Plan BSIC Plan.

There were also Prediction's made for Cell sites that were planned for the month of Oct 2007, yet to berolled out.


87 (136)


There were several iterations run for better efficacy of Plan and some of the results from the Plan isjotted down along with the Improvement in performance from Statistics extracted form Nokia OSS.

Optimizer Results: Idea Cellular Delhi

BCCH & TCH Usage in the New Plan:


88 (136)


TRX’s Interfered, Distribution

The total number of TRX’s which were interfered have Come Down in the New Plan. Initiallythere were about 700 TRX’s 100% Interfered which have reduced to about 250 TRX’s in this scenario ofNew Plan.

Performance Enhancement with statistical Report.


89 (136)


U L & D L Q U A L I T Y I d e a C e l l u l a r D e l h i .

1 .2 0

1 .3 0

1 .4 0

1 .5 0

1 .6 0

1 .7 0

1 .8 0

1 .9 0

2 .0 0

2 .1 0

2 .2 0

2 .3 0

2 .4 0

2 .5 0

2 .6 0

20

07

-06

-18

20

07

-06

- 22

20

07

- 06

- 26

20

07

- 06

- 30

20

07

- 07

- 04

20

07

- 07

- 08

20

07

- 07

- 12

20

07

- 07

- 16

20

07

- 07

- 20

20

07

- 07

- 24

20

07

-07

-28

20

07

-08

-01

20

07

-08

-05

20

07

-08

-09

20

07

-08

-13

20

07

-08

-17

20

07

-08

-21

20

07

-08

-25

20

07

-08

-29

20

07

-09

-02

20

07

-09

-06

20

07

-09

-10

20

07

-09

-14

20

07

-09

-18

20

07

-09

-22

20

07

-09

-26

20

07

-09

-30

20

07

-10

-04

20

07

-10

-08

20

07

-10

-12

D a t e .

UL

Qu

ali

ty .

1 .2 0

1 .4 0

1 .6 0

1 .8 0

2 .0 0

2 .2 0

2 .4 0

DL

Qu

ali

t y .

U L Q u a lity D L Q u a lity Po ly . ( D L Q u a lity ) Po ly . ( U L Q u a lity )

O ptim izerC yc le

H O P e r fo rm a n c e I d e a C e l l u l a r D e l h i :

2 0 0 0 0

2 2 0 0 0

2 4 0 0 0

2 6 0 0 0

2 8 0 0 0

3 0 0 0 0

3 2 0 0 0

3 4 0 0 0

3 6 0 0 0

3 8 0 0 0

4 0 0 0 0

20

07

-06

-18

20

07

-06

- 22

20

07

- 06

- 26

20

07

- 06

- 30

20

07

- 07

- 04

20

07

- 07

- 08

20

07

- 07

- 12

20

07

- 07

- 16

20

07

- 07

- 20

20

07

- 07

- 24

20

07

-07

-28

20

07

-08

-01

20

07

-08

-05

20

07

-08

-09

20

07

-08

-13

20

07

-08

-17

20

07

-08

-21

20

07

-08

-25

20

07

-08

-29

20

07

-09

-02

20

07

-09

-06

20

07

-09

-10

20

07

-09

-14

20

07

-09

-18

20

07

-09

-22

20

07

-09

-26

20

07

-09

-30

20

07

-10

-04

20

07

-10

-08

20

07

-10

-12

D a t e . . .

Tra

ffic

(E

lr)

.

2 .0 02 .2 02 .4 02 .6 02 .8 03 .0 03 .2 03 .4 03 .6 03 .8 04 .0 04 .2 04 .4 04 .6 04 .8 05 .0 05 .2 05 .4 05 .6 05 .8 06 .0 06 .2 06 .4 06 .6 06 .8 07 .0 07 .2 07 .4 07 .6 07 .8 0

Ha

nd

ov

er_

Fa

ilu

re .

TC H T r a f f ic ( Elr ) H O Fa il Po ly . ( H O Fa il)

O ptim izerC yc le


90 (136)


TCH & SDCCH DROP:Idea Cellular Delhi.

25000

27500

30000

32500

35000

37500

40000

2007

-06-1

8

2007

-06-2

3

2007

-06-2

8

2007

-07-0

3

2007

-07-0

8

2007

-07-1

3

2007

-07-1

8

2007

-07-2

3

2007

-07-2

8

2007

-08-0

2

2007

-08-0

7

2007

-08-1

2

2007

-08-1

7

2007

-08-2

2

2007

-08-2

7

2007

-09-0

1

2007

-09-0

6

2007

-09-1

1

2007

-09-1

6

2007

-09-2

1

2007

-09-2

6

2007

-10-0

1

2007

-10-0

6

2007

-10-1

1

Date ...

Traf

fic (E

lr) .

0.000.100.200.300.400.500.600.700.800.901.001.101.201.301.401.501.601.701.801.902.002.102.202.302.402.502.602.702.802.903.00

TCH

_Dro

p , S

DC

CH

_Dro

p .

TCH Traf f ic (Elr) TCH Drop SD Drop Poly. (TCH Drop) Poly. (SD Drop)

OptimizerCycle

Thus there was improvement in performance of Uplink Quality, Down Link Quality, Handover,and also on TCH Drop and SDCCH Drop Call on the Network Level.


91 (136)


5. EOSFLE (Release 5.52) OPERATION.

1 ©Nokia Siemens Networks Presentation / Author / DateFor internal use

EOSFLEX OPERATIONS.Idea Cellular Delhi11th-May-2007

Stenin.N.PNetworks, and Service Optimipation.Nokia.India.

EOSFLEX Release 5.52:-Extended Operations Flexible Reporting.


92 (136)


This Nokia Propriety tools EOSFLEX Release 5.52, helps in extracting statistical Datafrom a 2G, 2.5G and WCDMA Networks, by querying the Data base server at the Nokia OSS.Different “.xml” scripts are written for extraction of the required Data from the OSS.

The data extraction can be scheduled, with the help of a scheduler for atomizing thestats extraction task, wherein reducing the time requirement for Data extraction.

Once a query is made for a particular day for a particular data from the OSS, and thetask is carried out for the second time for stats of the same day, the tool reduces the time it willtake after the first attempt to query the Data base server, which is time consuming.Note: The output can be extracted as “.csv “(Excel output).

EOS Scheduler operates with two separate entities.1) Scheduler Engine.2) The scheduled content definition.

Note: The engine handles all scheduled jobes.It process scheduled jobs defined in the XMLfile.

The engine contains of Perl script, supporting modules for Excel, Zip, and mailinginterface

The engine starts via WIN2K Task scheduler.The reports Excel file offers.

1) Frozen panes (Column header and date / object identifiers are always available)2) Web Link3) support for markup coloring4) support for number formatting5) Vertical column header (Space saving)

Eos scheduler supports file and directory cleanup.

SCRIPT: There are different tables from which the raw counters are to be extracted.Some of the commonly used tables are listed:-

<temp_table create="yes" name="traffic"><temp_table create="yes" name="ho"><temp_table create="yes" name="res_avail"><temp_table create="yes" name="service"><temp_table create="yes" name="res_access"><temp_table create="yes" name="pcu"><temp_table create="yes" name="qual"><temp_table create="yes" name="rxqual"><temp_table create="yes" meas_level="" name="mcs">

Way forward with EOSFLES Release 5.52.Log in using:- http://localhost


93 (136)


Main Report Selection Window:-

http://localhost

94 (136)


XML (Script for Voice)Example shown Script for TCH Drop Call.

<conf_file><column_order><trf_6></trf_6><sdcch_comp_ratio></sdcch_comp_ratio><tch_comp_ratio></tch_comp_ratio></column_order>

<! -- ========================= Tables ================================= --><temp_table create="yes" name="traffic">

<Counters>


95 (136)


<counter alias="sdcch_busy_att">sum (sdcch_busy_att) </counter><counter alias="tch_seiz_due_sdcch_con">sum (tch_seiz_due_sdcch_con) </counter><counter alias="sdcch_seiz_att">sum(sdcch_seiz_att)</counter><counter alias="sdcch_radio_fail">sum (sdcch_radio_fail) </counter>

<counter alias="que_all_ass_req_att">sum (que_all_ass_req_att) </counter><counter alias="drop_after_tch_assign">sum (drop_after_tch_assign) </counter></counters>

<table_name>p_nbsc_traffic </table_name><alias_name>traffic</alias_name>

</temp_table><! -- ================= Table ================================== -->

<temp_table create="yes" name="ho"><Counters>

<counter alias="msc_i_tch_tch">sum (msc_i_tch_tch) </counter><counter alias="msc_i_sdcch_tch">sum (msc_i_sdcch_tch) </counter><counter alias="msc_i_tch_tch_at">sum (msc_i_tch_tch_at) </counter><counter alias="msc_i_sdcch_tch_at">sum (msc_i_sdcch_tch_at) </counter><counter alias="msc_i_sdcch_at">sum (msc_i_sdcch_at) </counter><counter alias="msc_o_tch_tch">sum (msc_o_tch_tch) </counter><counter alias="msc_o_sdcch_tch">sum (msc_o_sdcch_tch) </counter>

<counter alias="cell_call_clr">sum (cell_call_clr) </counter></counters><table_name>p_nbsc_ho </table_name><alias_name>ho</alias_name>

</temp_table><! -- ==================================== Table========================== -->

<kpi name="tch_comp_ratio"><Formula>

Nvl (decode (((traffic.tch_norm_seiz+ho.msc_i_sdcch_tch+ho.bsc_i_sdcch_tch+ho.cell_sdcch_tch-traffic.tch_succ_seiz_for_dir_acc+traffic.tch_seiz_due_sdcch_con

)), 0, 0+null,100-100*

(Traffic.tch_radio_fail+Traffic.tch_rf_old_ho+traffic.tch_abis_fail_call+traffic.tch_abis_fail_old+traffic.tch_a_if_fail_call+traffic.tch_a_if_fail_old+traffic.tch_tr_fail+traffic.tch_tr_fail_old+traffic.tch_lapd_fail+Traffic.tch_bts_fail+traffic.tch_user_act+traffic.tch_bcsu_reset+traffic.tch_netw_act+traffic.tch_act_fail_call)

96 (136)


/( traffic.tch_norm_seiz+ho.msc_i_sdcch_tch+ho.bsc_i_sdcch_tch+ho.cell_sdcch_tch-traffic.tch_succ_seiz_for_dir_acc+traffic.tch_seiz_due_sdcch_con)), null)

</formula><kpi_alias> Tch Comp ratio</kpi_alias><kpi_format>format %3.2f</kpi_format><kpi_mark></kpi_mark><area_level>all</area_level><kpi_info>

<title>Drop Call Ratio (dcr_3i)</title><use></use><use_experience></use_experience><known_problems></known_problems><open_questions></open_questions><formula></formula><pm_class></pm_class><unit>(%)</unit><tables> p_nbsc_traffic</tables>

</kpi_info></kpi>

<info><release number="5"/><maxrows>100</maxrows><header>Idea_kpi </header><help_file> about_eosflx.htm</help_file><csv_title> gos_new </csv_title><bts_number>20< /bts_number><csv_rule>reuse</ csv_rule><wrap_header>on< /wrap_header><dst>RC</dst><nokia_counter_id_help_file></nokia_counter_id_help_file><nokia_counter_db_help_file></nokia_counter_db_help_file><nokia_kpi_help_file></nokia_kpi_help_file><external_kpi_help_file></external_kpi_help_file><report_version></report_version><min_obj_agg>BTS</min_obj_agg><nw_tp>2g</nw_tp><obj_number>20</obj_number><bts_number>20</bts_number><implementation>2g_ran</implementation><addon_sorting></addon_sorting><help_text></help_text>

</info> <! -- ============================ end =============================== --></conf_file>

97 (136)


Note: The above script is saves @ D:\raproot\conf\nrbasic\eosflx\2g_ran\reports

The “ui_conf.xml” file<Conf><release number ="5.5"/><dsn><name dst="RC_2G" raw_data="yes" agg_data="yes">idea_nw_rc</name></dsn><xml_file>

<report dst="" name="Idea GPRS KPI"> idea_gprs.xml</report><report dst="" name="Idea GOS Report"> idea_gos.xml</report><report dst="" name="Idea EDGE"> idea_edge.xml</report><report dst="" name="Idea_Cellular KPI2"> idea_KPI2.xml</report><report dst="" name="Idea_Cellular KPI3"> idea_KPI3.xml</report><report dst="" name="Idea_edge"> idea_KPI3.xml</report>

</xml_file><date_format name ="europe"/></conf>

Note: The above script is used for display in the “Main report selection window”.After script is run to fetch report is stored @ D:\raproot\apps\scheduler\log\01.05.2007

Thus the output is calculated with the formula in the script and displayed in the above link after zippingthe output file appropriately.

After continuous execution of report using EOSFLEX, the old files can be cleared from overloading the system from D:\raproot\data\incs\odrcache.To add script for a new BSC Integrated D:\raproot\apps\scheduler\ IDEA_BSC_CS_BH.xml

SCHEDULER (. bat file)The scheduler script for different BSC.cd /raproot /apps/schedulerperl eos_scheduler.pl XML=IDEA_BSC_CS_BH.xml SCHED_REPORT=RepSuite_IDEA_KPI3.xmlSCHED_INSTANCE=BSC1_CS_BH

perl eos_scheduler.pl XML=IDEA_BSC_CS_BH.xml SCHED_REPORT=RepSuite_IDEA_KPI3.xmlSCHED_INSTANCE=BSC10_CS_BH

98 (136)











Note:This script is stored @ D:\raproot \apps\schedulerThe script for scheduler is stored as “ .bat ” file.

Scheduler script.<sched><info id="info"> 

<host_ip></host_ip> <date_format>europe</date_format><dsn>idea_nw_rc</dsn>

<xls_dir>/dlbrowser/{today}/</xls_dir></info>

99 (136)


<report id="RepSuite_IDEA_KPI3.xml">

<instance id="BSC10_CS_BH" go="yes"><weekdays>All </weekdays>

<dsn>

idea_nw_rc</dsn> <sched_exe>



%cgi-bin%nrbasic/eosflx/eosflx.pl B=Generate IMPL=2g_ran UI_CONF= idea_ui_conf.xmlDROP_XML=idea_KPI3.xml DROP_DSN={dsn} DSN_ATT=RC_2G PARENTLIST=190657

OBJECT=SEG_ID OBJECT_LEVEL=3Agg =CS_BH Time=Relative Fdate = Tdate = RLength =1 RTselection= Day(s) RCAselection=AbsoluteRdate ={yesterday}DROP_SORT= desc Sortby =None Threshold=None Max= Min= SCHEDULE=1 REPORTYPE= KPI=

UI=1 MY_SCRIPT_CONF_LINK= script_conf.xml</sched_exe><xls go="yes">

<type>

PM </type> <dst>

RC_2GPM </type> <dst>

RC_2G</dst>

<freq>

</freq><xlsfile> 

BSC10_CS_BH.xls</xlsfile><xlssheet> 

BSC10_CS_BH</xlssheet>

<title> idea_report (1 day(s) end {yesterday}) Time Agg: CS_BH Object Type: BSC,

Object(s): '190657' Object Aggregation:</title>

<replink go="yes"> 

<exclude_params>

SCHEDULE=1 UI=1</exclude_params>

</replink><freezepane> <!-- Freeze a number of rows and columns in the XLS sheet - e.g. used to keep the

100 (136)


column headers and object info in window while scrolling results in Excel.-->5,5

</freezepane><sumxls> 

</sumxls><markup>



</markup><datasetformat> 

undef,undef,undef,undef,undef, %8u, %.2f, %.2f, %.0f, %.2f, %3i, %.2f, %3.2f, %.2f, %3.2f,%.2f, %.0f, %.1f, %.1f, %8u, %8u, %3.2f, %.2f, %3.2f, %.0f, %.0f, %.0f, %.0f, %.0f, %.0f, %.0f, %.0f,

%.0f, %.0f, %.0f, %.0f, %.0f, %.0f, %.0f, %.0f, %8u, %8u, %0u, %.0f, %.0f, %.0f, %3.2f, %.0f, %.0f,%.0f

, %.0f , %.0f , %.0f , %.0f , %.0f , %.0f , %.0f , %.0f , %.0f , %.1f , %.0f , %.0f , %.0f , %3.2f, %3.2f,%.0f, %.0f, %3.2f, %.0f, %3.2f, %.0f, %.0f, %3.2f, %3.2f, %.0f, %.0f, %3.2f, %3.2f, %.0f, %.0f

</datasetformat></xls>

<sched_csv>



/odrcache//eosflx_idea_KPI3.xmlidea_nw_rc_CS_BH??.??.????_??.??.????_3_190657__._desc___SEG_ID_.csv

</sched_csv><sched_csv_age></sched_csv_age><zip go="yes">

<zipfile>BSC_CS_BH_IDEA.zip

</zipfile><sourcefiles>

{xlsfile}, {sumxls}, {sched_csv}</sourcefiles>

</zip><mail go="no">

<mailfile>RS_mail.csv

</mailfile><sourcefiles>

{xlsfile}, {sumxls}, {zipdest}


101 (136)


</sourcefiles><mailaddress>

[email protected]</mailaddress>

</mail></instance></report></sched>

Statistical Report GeneratedThe statistical report generated .csv file.

The above stat was generated for a particular BSC Using EOSFLEX.

6. Alarm Cause study.

mailto:[email protected]


102 (136)


NOKIA ALARM DESCREPTION AND ANALYSIS ONPERFORMANCE DEGRADATION.

- a detailed analysis and field test for some of the Common Alarms and its Causes -

NOKIA India Pvt.LtdIdea cellular Delhi.

Date:1st August 2007

List Of Important Alarms :

Some of the Important Alarma:-


103 (136)


Alarm Number Description

7745 CHANNEL FAILURE RATE ALARM

2992 bts and tc unsynchronization clear calls on a interface

2993 bts and tc unsynchronization clear calls on abis interface

7508 RADIO TIMESLOT FAILURE IN TRX

7600 BCF FAULTY

7601 BCF OPERATION DEGRADED

7603 BTS FAULTY

7604 BTS Operation Degraded

7606 TRX FAULTY

7617 SEVERAL CALLS DROPPED DUE TO PROBLEM WITH TRANSCODER

7704 PCM FAILURE

7705 LAPD FAILURE

7715 CONTINUOUS RESTARTS OF BCF-TRX

7725 TRAFFIC CHANNEL ACTIVATION FAILURE

7738 BTS WITH NO TRANSACTIONS

7743 MEAN HOLDING TIME BELOW DEFINED THRESHOLD

2955 TRANSCODER CHANNEL FAILURE

7746 CH CONGESTION IN CELL ABOVE DEFINED THRESHOLD

7767 BCCH MISSING

7939 FORWARD POWER TOO LOW AT TX ANTENNA

8112 FREQUENCY ERROR


104 (136)


ALARM NUMBER 7745:- CHANNEL FAILURE RATE ABOVE DEFINEDTHRESHOLD:

This alarm helps in finding out the timeslots which are blocked and causing High SDCCH or TCHBlocking.And in some scenarios calls get established on these timeslots and then drops with an cause of “Time out”.Alarm 7745 is explained as described below with an example.

Alarm number 7745 gives information on the Timeslot degraded.

This displays degradation of both SDCCH Timeslot and TCH Time slots that have gone faulty.At theforemost instent a soft reset (Locking that particular Time slot and then unlockimg )can help in overcommng theproblem.If it is found to have all the Timeslots degraded ,then that particular TRX can be given a reset on a temporarybasis.

If the Problem still exists then change the TRX.

Causes: 1) If Alarm noticed on BCCH Carrier, then swap BCCH /TCH Carrier appropriately.

2a) 7745 on One TRx Only:If there is alarm noticed on one single TRx, then check for SMA Cable(Cable that connects the Radio) at

TX Connector to WCxA(Wide band combiner) of the TRx is properly tightned.

2b) 7745 on Two TRx of a cell.If alarm noticed on two TRx’s, then check if there exist, cross feeder in these two TRx’s


105 (136)


2c) Noticed on all TRx.Check for Cross feeder, Bad connectors, Connection to DVxA (Duplexer).

Solution:a) Temporary => Inservicing appropriate Time slots.b) Permanent => Replace Hardware (Radio).

STATISTICS ANALYSIS:7745.

The statistics showing no calls been handled by a particular Timeslot found to be having this alarm 7745.

Time slot number “2” showing Alarm 7745 for “TRX -002” of Site “AMITYSCHL1” of “BSC015”

Statistics showing no calls been handled by this particular Timeslot number “2” of “TRx-002” of site“AMITYSCHL1” of “BSC15”.

FIELD TEST TRIAL, FOR ALARM 7745:


106 (136)


The alarm 7745 shows for this particular cell “SARAIJLNA1” that Timeslot (TS0 & TS1) to beworking fine and Timeslots(TS2, TS3,TS4,TS5,TS6, & TS7) not carrying calls(blocked).

Field test was conducted with TEMS for this particular cells at non busy hour and could find that theMobile could latch on to Time slot TS0 & TS1 only and and the remaining Time slots ( TS2, TS3, TS4, TS5,TS6, & TS7 ) could not get calls going on tending the timeslot Faulty.


107 (136)


ALARM NUMBER 7601:- BCF OPERATION DEGRADED:

This alarm 7601 is generated at the BTS.

BD018 BCF-0030 EQUIPM 2007-07-24 04:20:45.42** ALARM

(14652) 7601 BCF OPERATION DEGRADEDDifference between PCM and base station frequency reference.02 01 07 96 00 00

I. Fault reason: Cabinet I2C bus is jammed.

Solution:

1. Switch the site power Off and On.2. Check the fan unit, the power supply unit and the TRXs.

If necessary, replace the faulty units(s).3. If the fault reappears, replace the cabinet. The units

Inside the cabinet can be reused in the new cabinet

II. Fault reason: Incompatible unit presence has been detected in the BTS.


108 (136)


Solution:

1. Replace the high power or EDGE TRX(s) with normal type TRX(s)and reset the BCF.

2. Or, replace the normal type FAN and power supply with high poweror EDGE units. Now EDGE and high power TRXs are supported.

III. Fault reason: Difference between the PCM and BTS frequency reference.

Solution:

1. Check the synchronisation settings of the transmission interface.( DAC Value)DACvalue Range from 1800 t0 2200.

2. If the settings are OK, check the transmission chain.3. If the alarm stays active or reappears after the recovery actions

above, reset the BCF.4. If the alarm reappears after the BCF reset, replace the BTS.

Note: If this Supplementary alarm appears there is Drift in clock value(DAC). Thatleads to HO failures

IV. Fault reason: Oven oscillator control is close to its margins. The ovenmight be outdated.

Solution:

1. Check the synchronisation settings of the transmission interface.2. If the settings are OK, check the transmission chain.3. If the alarm stays active or reappears after the recovery actions

Above, reset the BCF.4. If the alarm reappears after the BCF reset, replace the BTS

Note: If this Supplementary alarm appears there is Drift in clock value (DAC). Thatleads to HO failures

V. Fault reason: Flash operation failed in BOI or TRX.

Solution:

1. Replace the BOI.2. BOI=Base station operation Interface unit3. If it is TRX change the TRX


109 (136)


Descrpition of Supplementary information:

1-6 XX XX XX XX XX XX1 2 3 4 5 6

1. Rack (cabinet) number

2. shelf number

3. slot

4. Type of unit

5. unit number

6. subunit number

ALARM NUMBER 7738:- BTS WITH NO TRANSCATIONS

This alarm helps in finding out that BTS has had no successfully terminated calls, SDCCH orTranscations GPRS TBF releases during the supervision period.

This alarm is used for supervising the BTS traffic capacity and to indicate sudden lossof service on BTS level

This is a BTS Specific alarm. BF=Temporary Block Flows


No SDCCHTransaction


110 (136)


01= No successful SDCCH seizures

02 = No successful TCH seizures

03 = No successful SDCCH nor TCH seizures

10 = No successful GPRS transactions

11 = No successful SDCCH seizures and No succesful GPRS transactions

12 = No successful TCH seizures and No succesful GPRS transactions

13 = No successful SDCCH nor TCH seizures nor GPRS transactions

NO SDCCH TRANSACTION


111 (136)


NO GPRS TRANSACTION

2.

NO GPRSTransaction


112 (136)



113 (136)



114 (136)


Temporary solution: Reset the Sector (BTS)

Permanent solution: Replace the Hardware

ALARM NUMBER 7604:- BTS OPERATION DEGRADED

Description: Major fault (or faults) has occurred in a unit (or units) thatBelong to the sector indicated in the alarm.This alarm belong to particularsector.

Following are the Fault Reasons for BTS Operation Degraded.

I. Fault Reason: Remote tune combiner temperature isdangerously high.

Solution:

1. Ensure that the ambient temperature of the base station is withinSpecified limits.

2. Check the cabinet fans.3. Replace the remote tune combiner.

II. Fault reason: Remote tune combiner temperature is low.

Solution:

1. Ensure that the ambient temperature of the base station is withinSpecified limits.

2. Check the cabinet heater if it is installed.3. Replace the remote tune combiner.

III. Fault reason: Rx levels differ too much between main anddiversity antennas.

Solution:

1. Check the RSSI measurements by BTS Manager.2. Locate the cause of the alarm (unit, cable, antennas).Check unit , cable and

antennas,3. RSSI: Received Signal Strength indicator.4. Imp alarm where call gets blocked.


115 (136)



1-6 XX XX XX XX XX XX1 2 3 4 5 6

7. Rack (cabinet) number

8. shelf number

9. slot

10. Type of unit

11. unit number

12. subunit number

This supplementary information is valid for 1 to 3 fault reasons.

IV: Fault Reason: Fault in the chain between power unit and high gain MNxx with.

Supplementary information: By pass

ALARM NUMBER 7744:- EXCESSIVE TCH INTERFERNCE

Descrpition: During the supervision period, the TCH time slot has sufferedExcessive interference in idle mode that is equal to or higher than

the operator-defined alarm threshold percentage.

That is the ,Interference in the time slot has lasted longer than is acceptable.

The interference level classified as excessive is defined by theOperator. The alarm is used to supervise the BTS traffic capacity

Supplementary information fields

1-8 the percentage (per each TRX time slot) that the channel hasSpent in excessive interference during the supervision period.The number is a hexadecimal, 0 - 64 %.


116 (136)


If the time slot is not a TCH time slot, the value is 0

9 the threshold level of excessive interference. The values are0, 1, 2, 3 and 4

10 the TCH channel's alarm threshold percentage of the time spentIn excessive interference, 1 - 100 %. The alarm is generated ifat least one TRX time slot reaches the threshold

These alarms basically indicate the uplink interfencence, check MAIO, HSN. MAIOSTEP Check any Repeaters installed near the site, fine tune the repeaters

. ALARM NUMBER 7606:- TRX FAULTY

.Descrpition:

Critical fault has occurred in a TRX. This alarm blocks the TRX.

Call drops will be severely with the faulty TRX.

Following are the Fault Reasons for TRX Faulty.

I. .Fault reason: Failure detected during TRX configuring.

Solution:

Either the TRX is faulty or its frequency band is differentfrom the one that was configured into BSC. Replace the TRX

with a functional TRX or with another TRX with correct frequency band.

II. Fault reason: Antenna connection faulty.


117 (136)


Solution:

Check the antenna and cabling. If the antenna and cablingare faulty, correct the problem and run TRX test to cancelthe alarm.

If the antenna and cabling are OK, TRX is faulty.Replace the faulty TRX.

7. Drive Test Analysis.

Check List for Cell site.For better understanding for enhancement in performance, requiring field analysis, which was carried

out for problematic cells in Idea Cellular Delhi Networks.There were Drive carried out for data collectionin the following scenarios:

Basic Information.Idle ModeDedicated modeHandover Checks Made.Data Drive (GPRS / EDGE )

The following were the checks made during the Drive test for each of the scenarios.

Basic Information from Drive Test.

Site IDSite NameSite Connected to BSCTRX Configuration.


118 (136)


Idle Mode Information from Drive test.

Frequencies (Sys info type1)BSIC correctly defined

Cell_Reselect_Offset,Temp_OffsetPenalty_Time are as planned (sys info3)

The Site Radio parameters in Layer3 messagesSys. Info type 3, as planned.

The LAC is correctly definedLocation Update procedure is checked (If applicable)MO-SMSMT-SMS

Dedicated Mode Information from Drive test.

DL_QUALs for all TRX's is zero below the antennaDL_LEVELs for all TRX's comparable and steadyUplink power control is min below the antennaAll TCHs and corresponding TS's are OKSite configuration (Micro / Macro / Umbrella …etc) is correctMobile Terminating callsMobile Originating calls are tested OKRescue and Concentric cells handovers, checked wherever applicableFrequency Hopping is activated.

Handover Data From Drive Test.

Neighbors definition from layer3 type 5 messages is OKSubsequent Handovers from and back to each cell checked OKHandovers to main umbrella(s) and neighbor(s) work fineIntra BSC Outgoing handovers checked OKIntra BSC Incoming handovers checked OKInter BSC Outgoing handovers with all surrounding BSC's checked OKInter BSC Incoming handovers with all surrounding BSC's checked OKInter MSC Outgoing Handovers with all surrounding MSC's (if applicable) checkedOK


119 (136)


Inter MSC Incoming Handovers with all surrounding MSC's (if applicable) checkedOK

Data Drive for GPRS.

GPRS AttachGPRS PDP Context ActivationGPRS PDP Context DeactivationGPRS Routing Area Update (If applicable)GPRS Detach

General Information from Drive Test.

Installed antenna is of the planned typeOverall performance and coverage area as expected by a brief drive test

Radio Efficacy Check Per Cell.

Site ID: SiteName:

Sector 1TRX # 1 2 3 4 5 6 7 8 9 10 11 12Freq.RxLev




120 (136)


Sector 4TRX # 1 2 3 4 5 6 7 8 9 10 11 12Freq. 801 805 808RxLev -51 -49 -57

Remarks

In the above example the efficacy of the Radio per sector can be checked in the field for betterperformance.Say for Example, in sector 4 as shown above, having 3 TRX, and when tested of theirRXLev should not have a difference in the RXLev of not more than 5dbm between the TRX of the samesector.

And as this test is to be conducted in a close proximity to the cell site, should not have an RXLevnot less than -55dbm proximately in each of the TRX.

Along with RXQual and Level Plot from the Drive, Problems like Hardware Faulty, Sector Swap,Cable Swap, Etc can be further analysed with Field Drive testing.

Benchmarking Drive using Swis Qual 7.5

The Benchmarking of 2G networks for Idea, Airtel, Dolphin, Hutch (all GSM),Reliance (CDMA) was conducted with Measurement period from Sept 16, 2007 – Oct 26, 2007

Test done at static locations were SMS, MMS & FTP test.Measurement systems used:

– SwissQual 7.5 for Voice and Data drive tests– SwissQual QualiPoc for SMS & MMS static tests– N6680 for GSM, LG RD6000 for CDMA

Per operator approximately:– 2100 two-minute voice calls (mobile to fixed) evaluated– 300 FTP up- and downloads, 300 Emails send and received, 300 HTTP requests,

200 SMS, 60 MMS tests performed– 2600 km of routes driven

The Benchmarking Tool Swis Qual version 7.5 was used to analyse competator network at DelhiRegion for both Voice and Data.The following are the summerised comparision found as describedbelow.

Drive Test session:


121 (136)


Simultanious Drive done for Voice and Data, during test.

Data Services Drive Test Measurement

The data test comprised of sequence of Attach, then PDP Activation, followed by FTP Download,HTTP Brouser, FTP Upload, Email Sending and then Email Reception.

Executive Summary - Voice• Idea shows an average overall voice service performance in Delhi.• Call Setup Time of Idea is exceptionally good, also in international comparison they show

one of the best statistics here.

FTP DownloadHTTP

BrowsingEmailSend

EmailReceive

Data Session

Attach & PDP ContextActivation

Detach & PDP ContextDeactivation

FTP Upload


122 (136)


• Overall Idea has good Call Setup success rates, most of the failed calls are due tocoverage issues.

• Idea slightly under performs with regards to the call completion rate and should beworked upon.

• Idea’s speech quality is found good and speech samples for both the Uplink as well asDownlink are well balanced .

• With respect to call Accessibility and Retainability Dolphin is clearly underperforming.• In International comparison Airtel appears to have a fairly high cell density and is also the

highest compared to local competitors.

Executive Summary – Data• The overall data performance for Idea in Delhi can be rated as poor.• All data services except SMS have poor performance levels in Delhi. For some of

the data services Idea is amongst the poor 20% networks globally.• Hutch shows up with a better data performance in Delhi as compared to Idea.

Reliance being a CDMA service provider is also good when it comes to datastatistics in Delhi.

• Having used EDGE for almost all the sessions the average throughput of Idea isfound to be very low. This is the major reason for having low success rates aswell.

• The MMS performance of Idea needs improvement. Long delivery times and onlya 60% success rate puts Idea’s performance amongst one of the most poorperformers measured globally.

2 2 © N ok ia S iem en s N etw orks B enc hm ark S ervic e R ep ort / P M & R H / 2 0 .1 1.2 0 07

M obile S ervices Q uality in a N utshellD elh i, O cto ber 2007

t o p 2 0 % p e rfo r m e r sin t e rn a t io n a lly

lo w 2 0 % p e r fo rm e rsin t e rn a t io n a lly

in t e rn a t io n a l a v e ra g e

1 I D E A2 A i r te l3 D o l p h i n4 H u tc h5 R e l i a n c e

D C Q I

1

2

4 5

V C Q I

1

2

3

4

5


123 (136)


2 4 © N ok ia S iem en s N etw orks B enc hm ark S ervic e R ep ort / P M & R H / 2 0 .1 1.2 0 07

V oice S ervice Q uality = Cal l Set u p Tim e= Cal l Set u p Su ccess Rat e= Cal l Co m p le t i o n Rat e= Mean Op in io n Sco re

CSTCSSRCCRMOS

C S T

9 .4

4 .5

3 .7

3 .3

2 .61

2 3

4

C S S R

9 9 .3 %

9 8 .2 %

9 6 .1 %

7 4 .6 %

1 0 0 %

12

3

4 5

M O S

3 .9 4

3 .6 9

3 .6 0

3 .3 8

2 .9 5

12

34

5

1 I D E A2 A i r te l3 D o l p h i n4 H u tc h5 R e l i a n c e

* ) CST sco re fo r Re lia n ce se t t o m e d ia n va lu e

* ) C C R

9 9.4%

9 8.6%

9 7.0%

8 9.2%

1 00 %

1

2

3

45

V C Q I

1

2

3

4

5


124 (136)


35 ©Nokia Siemens Networks Benchmark Service Report / PM & RH / 20.11.2007

Data Service Performance

*) MMSscoreforRelianceset to medianvalue

DCQI

1

2

45

HTTP

12

4

5

FTP DL

1

2

4

5

FTP UL

1

2

4

5

SMS

1

24

5

MMS

1

2

4

5

Email

1

2

4

5

GPRS Attach

1

2

4

5

PDP Context

1

2

4

5

1 IDEA 2 Airtel 3 Dolphin4 Hutch 5Reliance

The above plot shows Performance for Voice and Data when compared to other competatorOperators at Delhi area.


125 (136)



126 (136)


The table above gives an overview about the most important performance figures collected duringthis 2G Benchmarking campaign.


127 (136)


8. Nokia Macros:-

Table shows the availability of Macros for differend Nokia ND Reports.


128 (136)



129 (136)


The Detailed List of availability of Macros for ND and MML is listed above.


130 (136)


9. Summary of Idea Delhi Optimization:

After consecutive effersts put in to optimize Idea Cellular Delhi Network,with Parameter Optimization, Basic Design reviw, Field Optimization, AMR Finetuning, DataOptimization for 2G and 2.5G, Hardware Fault Verification, Timer Optimization, Alarms Handlingand threshold Verification, had the performance enhancement listed below on the NetworkLevel.

TCH Drop.

Drop on the TCH could be brought down to a value of 1.01 from an initial value of 2.6, withtaking the new sites getting integrated in the Network.


131 (136)


TCH BLOCKING:

Traffic Distribution:


132 (136)


SDCCH Drop:

SDCCH Blocking:


133 (136)


Handover Failure:

RACH Failure:


134 (136)


UL & DL Quality:


135 (136)


To cover in the Next Review.

DAC Performance AnalysisThreshold verification for DAC

Path Imbalance AnalysisRepeater Optimization AnalysisAMR Parameter Optimization

TMA / TMB Performance AnalysisMicro / Macro Cellular Model AnalysisPhysical AuditOther Methods of KPI EnhancementDiscontinious Transmission [DTX] / Reception [DRX].

Transmission related Alarms 2000 series.


136 (136)


10. Appendices.

End.NETWORKS, AND SERVICE OPTIMIZATIONNOKIA SIEMENS NETWORKS. 2nd Dec 2007.

2g & 2.5g optimization nokia india

Documents