Document Name DT Analysis Guidelines Date Created November 27, 2014

Version V 001 Approved By ISAT NPS Manager

Document Number INDOSAT OPTI – 00x Owner NPO
Prepared By Joseph Lennart Olaivar Designed For NPO
Reviewed By Alan Castaneda Project Indosat Optimization 2014

1. VERSION HISTORY

Version Modified By Date Modified Description of Changes

001 Joseph Lennart Olaivar November 27, 2014 Draft of DT analysis for Cluster Optimization, VIP
drives and City drives

2. OBJECTIVE

The purpose of this document is to give general guidelines on the process and strategy in
analyzing cluster DT for the purpose of optimizing the radio network of Indosat and fulfilling the
reporting requirements of the project. This document is particularly for the consumption of regional
team engineers who are doing the actual analysis and reporting. It lays out the process that the
regional teams should follow and strategies on how they will analyze the problems and the
expectations on their output. The target is for the regional engineers to produce a good quality
report and reliable analysis & recommendations.

This guideline is supplementary to the original “03 dt methodology guidelines v005” and “02
coverage optimization guidelines v001”. This guideline is particularly focused on analysis for the
cluster DT, VIP route and City route reporting required by Indosat. After reading this document
analysis engineer is still required to read the 2 mentioned original guidelines to get full details of the
requirement for this project.

3. PROCESS

Step 1: Level 1 and Level 2 engineers are doing cluster DT analysis and reporting.

Step 2: Once report is done it is submitted to senior engineers for layer 1 checking before it goes to
DT Lead (Samsul). If the one who made the report is the senior engineer the layer 1 check is the
regional TL.

Step 3: Once report is reviewed and confirmed by the senior engineer it will be submitted to regional
team lead for final review. During the strategic and central DT team visit to the regions the layer 2
check was done by the strategic engineers. Reports are being presented in a conference room with
projector so all the engineers can scrutinize the analysis and report and at the same time give
valuable inputs. If the senior engineer is the one making the report the layer 2 check is the DT Lead.
Step 4: After confirmation by Layer 2 check the report is submitted to DT Lead for submission to ISAT.
The DT Lead makes final sanity check before submission to ISAT to ensure correct format is followed
and major parts of the analysis and recommendations are good and reliable. Once DT Lead confirms
the readiness of the report it is then submitted to ISAT for checking.

Step 5: Once report is submitted to ISAT and confirmed by ISAT changes are implemented through
NCR and PCR.

Step 6: Once all PCRs and NCRs are implemented a next drive will be triggered. This drive is a
verification drive to confirm if all the changes have improved the cluster or DT route.

Step 7: After DT2 or Verification DT is finished the analysis engineer checks the improvement,
degradation and persistent bad spots of the clusters. If all KPIs are passed or all the bad spots are
improved (if not improved it should be justified) a second report will be submitted to ISAT for the
closure of the cluster. If KPIs are not passed or the bad spots were not improved the process goes
back to Step 1.

Step 8: This Final step is for the submission of the final report for the closure of the subject cluster.
Since deadlines are tight at this time and priority is to finish optimization of all the clusters Final
report is waived at the moment and instead an improvement report is submitted. The improvement
report will be the substitute for the Final report for now just to confirm the following:
• Bad spots were improved
• Identify which spots improved, degraded or persisting
• The degraded spots will be rectified and a revision to the improvement report will be
done
• The persisting bad spots will also be rectified

4. Identification of UE state (Idle or Dedicated Mode)

-below are the ways to determine if the UE is in Connected mode or in Idle mode on both 3G and 2G:

3G in Connected Mode indications

• If WCDMA Serving/Active Set window shows AS, MN and DN that means UE is connected
mode
• If WCDMA Radio Parameters window shows RRC state “Connected Cell-DCH” it means UE is
in connected mode
• If layer 3 messages shows the following messages it means UE is in dedicated mode
• Measurement report
• Active Set Update
• Measurement Control
• If HSDPA window show HS Session “HSPA Active” that means UE is in connected mode
 having HSPA service

3G in Idle Mode indications

• If WCDMA Serving/Active Set window shows SC, MN that means UE is Idle mode
• If WCDMA Radio Parameters window shows RRC state “Idle Mode” it means UE is in idle
mode
• If layer 3 messages shows the following messages it means UE is in Idle mode:
• System Information (SIB messages)
• Cell Reselection messages
• If HSDPA Analysis window show HS Session “blank” that means UE is not having HSPA service

2G in Connected Mode indications

• If GSM Current Channel window shows Mode “Dedicated” that means UE is in connected
mode
• If GSM Radio Parameters window shows RxQual has value that means UE is in connected
mode
• If Event Windows shows the “Handover” Messages that means UE is in connected mode
• If GSM Serving + Neighbor window shows C1 & C2 blank/no value that means UE is in
connected mode

2G in Idle Mode indications

• If GSM Current Channel window shows Mode “Idle” that means UE is in idle mode
• If GSM Radio Parameters window shows RxQual blank that means UE is in idle mode
• If Event Windows shows the “Cell Reselection” Messages that means UE is in idle mode
• If GSM Serving + Neighbor window shows C1 & C2 has value that means UE is in idle mode

5. COVERAGE ANALYSIS

5.a 3G Low level criteria for analysis

Below are the 3G levels for coverage that are considered poor and subject for analysis. Areas
with these levels are considered bad spots and should be analyzed in detail:

Table 1: 3G Poor Coverage Criteria

5.b. 2G Low level criteria for analysis

Below are the 2G levels for coverage that are considered poor and subject for analysis. Areas
with these levels are considered bad spots and should be analyzed in detail:

Table 2: 2G Poor Coverage Criteria

5.c. Identification of Bad Spots

All the areas with signal levels that falls into Poor Coverage Criteria in Table 1 and Table 2
should be identified by circle or rectangle or triangle which ever suites the report best. These areas
will be called bad spots. Each of these bad spots should be analyzed in detail on the succeeding pages
of the report.

5.d. Coverage Bad Spot Analysis

Poor Coverage Bad Spot analysis is composed of 2 parts – Problem/Root Cause identification
and Solution
5.d.1. Problem/Root Cause
- Root cause of the problem should be identified
- Need to check why nearest cell has poor signal level
- Need to check if other neighbour cells are serving
- Need to check the terrain/contour
- Need to check the site-to-site distance
- Need to check blocking – buildings, houses, etc.
- If there is no blocking and terrain is ok engineer should check the serving cell for
alarms and availability issues.
 Blocking
If a site/cell is blocked the engineer should show proof of blocking. Example is shown below:

Bad Spot-to-Site Distance

If Bad Spot to site distance is identified as the main cause of poor coverage the engineer
needs to indicate in the report and show a picture to justify this claim:

Terrain/Contour Problem
If terrain/contour is the cause of the problem the engineer needs to show the google
terrain/contour snapshot of the serving site/cell to bad spot:

Swapped Sectors
Analysis engineer should ensure that his cluster or DT route result has no swapped sectors
by checking best server plot. If there is swapped sector rectification should be done immediately and
drive test should be conducted to verify swapped sector has been fixed.

Overshooting
All cells in the cluster should be checked for overshooting by doing “per cell” coverage
plotting and analysis. As much as possible all overshooting cells should be downtilted but at the same
time ensuring that affected areas will still have signal level from the right serving cell.

5.d.2. Solution
- the engineer needs to provide solution to the identified problem in the first part.
- if the problem cannot be solved in a few days, say it needs a new site, a temporary
solution should be proposed like physical changes to neighboring sites while new site is not yet
implemented.
- if a new site is recommended it should be included in “Feedback to Planning” with
good justification. The engineer needs to make sure that poor coverage problem cannot be solved by
physical or logical optimization. A no-brainer is a bad spot where existing/neighboring sites are far
away – around more than 3Kms. Another case would be a bad spot where existing site is near (below
1Km) but is blocked by a building or challenged by Terrain/Contour.

If a physical optimization is required the engineer needs to show the following justifications:

1-TA/TP Analysis

If a 2G cell will be uptilted or downtilted the Engineer should show the TA of the cell to
confirm if its overshooting, undershooting or at optimal coverage:

If a 3G cell will be uptilted or downtilted the Engineer should show the TP of the cell to
confirm if its overshooting, undershooting or at optimal coverage:

2-Terrain/Contour Analysis
If a sector will be uptilted or downtilted the engineer should show the terrain plot from
google earth to confirm if uptilt or downtilt is justified:

3- Tilt Analysis (Kathrein)

If a sector is proposed to be downtilted or uptilted a Kathrein tool tilt analysis should be done to have
a quick idea if the sector can still serve its intended coverage after the physical change and to ensure
that the coverage will not be degraded worst than expected.

Serving Cell Assurance

When a sector is proposed to be downtilted to eliminate/reduce its overshooting or limit its coverage
to specific area the engineer needs to ensure that the area affected will still have good signal level
from another potential best server. The engineer needs to check and ensure that the next nearest
neighbour will serve the area well.

6. DROPPED CALL ANALYSIS

6.a Identification of all Dropped Calls or Retainability bad spots

All the areas/spots with dropped calls should be identified by circle or rectangle or triangle
which ever suites the report best. These areas will be called retainability/dropped call bad spots.
Each of these bad spots should be analyzed in detail. If there are multiple dropped calls in one area
this can be grouped into one especially if the cause is the same to simplify the report at the same
time identify the real problem.

6.b Dropped Call Analysis

Dropped calls analysis has 2 parts. 1st part is the identification of the problem or root cause and the
2nd part is the narration of solution. The Engineer needs to identify first the root cause of the problem
and has to support it with proof or justification by TEMS snapshot, Actix Snapshot, Spider graphs,
Statistics, M2000/LMT snapshot and other pictures or graphs that will support the claim for the root
cause. This problem will then be correlated with the proposed solution. Once problem is identified a
solution should be proposed. The solution will also be supported with proof to assure ISAT that
solution will cause improvement and resolve the problem identified.

Below are the items that need to be checked:

Coverage check
First item to be checked is the signal level of the serving cell. It is also necessary to check also the
distance from dropped call/bad spot to the serving cell and the neighboring cells. If distance from
bad spot to serving and neighboring cells is far (more than 1Km or 2Kms) then a new site can be
recommended if optimization cannot solve the poor coverage problem. New site will be the
permanent solution but engineer can still do optimization as temporary solution. If the distance from
bad spot to serving and neighboring cells is near (less than 1Km) then definitely optimization is the
best solution. There will be some cases where optimization will still not work even if bad spot-to-site
distance is near because of terrain/contour problems and blocking problems. In these cases a new
site will also be the permanent solution but engineer can still recommend a temporary solution.

3G RSCP check

2G RxLev check

Quality Check
Next item to check is the quality – Ec/Io for 3G and Rxqual for 2G.

In 3G poor Ec/Io is normally caused by poor dominance and pilot pollution. In order to improve the
Ec/Io of the area the engineer should ensure that there are less than 4 strong pilots in the area that
are within the 5dB range. This will not only improve the Ec/Io but also the SHO overhead.

In 2G poor RxQual is usually caused by frequency clash (co-BCCH and adjacent-BCCH channel) in
which re-tune is necessary. TCH frequency clash is not applicable in our network since we are using
RF hopping. In some cases faulty TRXs causes poor RxQual this is why it is important to check the
health of the hardware. One way to quickly check is the Scan TRX report. Engineer should check Scan
TRX for any clues on hardware problem especially the Imbalance Level. Then the engineer needs to
check the statistics also to get clues on the hardware problem and check in LMT for any alarms. If Trx
problem is not solved by reset or rectification then Trx replacement should be recommended.
External interference is another cause of poor RxQual.

3G Ec/Io

2G RxQual

Missing Neighbors
Next item to check is the neighbour relations of the cell. Missing neighbour and handover problem is
a common cause of dropped call. In 3G this can easily be spotted by looking at the active set window
of TEMS. If a neighbour is in DN (Detected Set) it is possibly a missing neighbour but not all the time.
In some cases cells are in DN due to UE limitation of measuring only 31 neighbors and leaving other
neighbours out. This is why it is still necessary to check the configuration manually through CFGMML
or M2000/LMT.

Other Radio Parameter level check

There are also other parameters in the WCDMA/GSM Radio parameters window of TEMS that are
worth checking and analyzing:

UE Tx power - if value goes higher than 0 it is an indication of high uplink load or high RTWP
or poor uplink coverage
SIR – usually problem occurs when SIR goes to zero or gives a negative value. When SIR goes
to zero or negative it is an indication that the UE is not anymore synchronized with the Node B.
BLER – when radio conditions are good and BLER is high it is an indication that there is
transmission or hardware problem.

SIB 7 (Layer 3 Message) – UL RSSI – this is RTWP measured through DT. Values more than
-95dBm is an indication of high RTWP

Alarms, Transmission Problem, Hardware Problems

Site or RNC/BSC alarms can also cause dropped calls especially if they are related to hardware
problems or transmission problems. Transmission problems can also be confirmed through counters
by IPPM or Packet Drops. Other problems like synchronization issues can also cause call drops.
Synchronization issues are usually seen in alarm monitoring.

UE Problem or DT tool problem

In some special cases dropped calls are caused by temporary UE problems. This usually happens
when all radio conditions are good and statistics shows good performance of the serving cell. In this
case a re-drive can be done to confirm if dropped call is really valid and if it is caused only by UE
problem.

Congestion
Congestion can also be the reason for a dropped call. This can be indicated by a layer 3 RRC
connection release message with cause “congestion”. This can be verified through statistics by
checking the congestion of the serving cell.

Core Network Problem

In some cases core network problems or congestion can also cause a call drop. This can be verified
through a layer 3 or NAS message that the release is coming from the core network.

7. BLOCKED CALL ANALYSIS

Just like Coverage and Dropped calls analysis, blocked call analysis has 2 parts. 1 st part is the
identification of the problem or root cause and the 2 nd part is the narration of solution. The Engineer
needs to identify first the root cause of the problem and has to support it with proof or justification
by TEMS snapshot, Actix Snapshot, Spider graphs, Statistics, M2000/LMT snapshot and other pictures
or graphs that will support the claim for the root cause. This problem will then be correlated with the
proposed solution. Once problem is identified a solution should be proposed. The solution will also
be supported with proof to assure ISAT that solution will cause improvement and resolve the
problem identified.

If cause of the problem is overshooting or undershooting it must be supported by proof through TA

or TP like the examples below.

Sample TA of an undershooting cell

Sample TP of an undershooting cell

Sample TA of an overshooting cell

Sample TP of an overshooting cell

If a Terrain/Contour problem or challenge has been identified it must be supported with proof like
Google elevation profile snapshot shown below:

Coverage check
Just like dropped call, blocked call first check is also coverage. Poor RSCP or Rxlev can also cause
blocked call because RNC or BSC is unable to receive messages from the UE.

Congestion check
Congestion is one of the main reasons for blocked call. One way to check is to see the layer message
details for blocked call. Normally RNC indicates the blocked call reason and “Congestion” or “resource
unavailable” is indicated. If it is not visible in the DT logs check the statistics of the serving cell at that
particular time. An hourly statistics is suggested. If the particular cell has congestion, high traffic and
high utilization at that moment then it is likely the reason for the blocked call.

Alarms, Transmission Problem, Hardware Problems

Just like dropped calls, blocked calls can also be due to Site or RNC/BSC alarms especially if they are
related to hardware problems or transmission problems.

Core Network Problem

In some cases core network problems or congestion can also cause a blocked call or rejection. This
can be checked through layer 3 or NAS message that indicates that rejection is from Core Network.

External Interference
External interference can also cause a blocked call. This can be checked through SIB 7 message in DT
and RTWP measurement in statistics. Good RTWP ranges from -105dBm up to -95dBm. When RTWP
is higher than -95dBm then deeper analysis is required to see if it is caused by traffic or external
interference.

UL External interference in 2G can be checked in IF band counters.

8. THROUGHPUT ANALYSIS

8.a 3G Throughput Analysis

Shown below are the criteria to consider if a spot or area has poor 3G throughput. All the areas with
these colors or ranges should be identified as bad spot and should be analyzed in detail.
 Table 3: 3G Poor Throughput Criteria

Items to check for 3G low throughput areas/spots

• If CQI values are good
-If CQI values are good then radio condition is good. That means low throughput
is not related to radio condition. Good CQI is 20 and above and marginal CQI is
16 to 20.
- If CQI values are bad then radio conditions are bad and RSCP and Ec/Io analysis
should be conducted. Pilot pollution analysis will also be beneficial.
• If Traffic is High
• If traffic is high or when user numbers are high then it is possible cause of low
throughput
• To validate this a re-DT or stationary test during non busy hour should be
conducted and OSS statistics should be checked.
• If serving cell has alarm or transmission problem
• If site/cell has alarms or transmission problems then it is one possible cause for
low throughput
• If there is indication of FTP server problem
• If there is a layer 3 message that says there is FTP server problem then it could
be a possible cause of the low throughput
• If UE is problematic
• If there is any indication or proof that the UE is problematic during the drive
then it could be possible reason for low throughput. In this case a re-DT should
be done to validate the real cause of low throughput
• If there is Dominance Problem
• If there are multiple cell changes and if best server plot is bad then it is a
possible reason for the low throughput problem
• Stationary Test
• To eliminate doubts of site or handover problem causing the low throughput a
stationary test should be done in order to validate if the site or cell itself has
problems. If stationary test gives low throughput then problem is site/cell
specific. If stationary test shows good throughput then low throughput might be
related to mobility problems such as pingpong handover or frequent cell
changes.

8.b 2G Throughput Analysis

Shown below is the criteria to consider if a spot or area has poor 2G throughput. All the areas with
these colors or ranges should be identified and analyzed in detail.

Table 4: 2G Poor Throughput Criteria

Items to check for 2G low throughput areas/spots

• Poor C/I and RxQual.

-Good Rxlevel but bad C/I and RxQual contributes to low throughput. Verify if
there’s any frequency clash on the BCCH frequencies. If there is clash then
frequency retune should be recommended
-check also if the serving cell is overshooting.
 -Verify also hardware issue (e.g. faulty TRX)

• Pingpong/Frequent Cell Reselection

• Frequent or too many cell relesection in 2G PS call also causes poor throughput
because of too many packet mode to idle mode state transitions. Check if
dominance is good and if there is no pingpong reselection.

• Hardware alarms/issues
• Check the serving cell for any alarms or hardware issues. Hardware issues also
contributes to low throughput problem

• PDCH Utilization
-for good RF condition but low PS throughput Engineer should check the PDCH
utilization (AR9311:Average Number of Occupied PDCHs / AR9303:Average Number
of Available PDCHs)
High PDCH utilization causes poor throughput. If PDCH utilization reaches 80% the
engineer should recommend to add static PDCH (considering no congestion in
SDCCH/TCH) or adjust MAXPDCHRATE (dynamic PDCH) to a higher value.

• Coding scheme available on the cell

• If there’s high coding scheme available on the cell, suggest to use this coding
scheme instead of the default one. (e.g. MCS for EDGE)
• Check if EDGE feature is activated.

• Other issues such as server problem and terminal issue also contributes to low
throughput.

9. PARAMETERS FOR OPTIMIZATION

9.a. 3G Parameters for Optimization
9.a.1 Soft Handover Parameters

Soft Handover Events

SHO Event Description
1A Addition of Radio Link
1B Deletion of Radio Link

1C Change of worst cell in Active Set

1D Change of Best Cell in Active Set

Soft Handover Parameters

Shown below are the SHO parameters that can be tuned based on the results of the DT to improve
DCR and SHO performance of the site/cluster. As much as possible avoid changing parameters when
it is not necessary. Cluster DT analysis and recommendations must be focused more on physical
changes.

Be careful in adjusting the SHO parameters below as they affect SHO to all neighbors. If an engineer
wants to advance or delay SHO with a particular cell/neighbor then a neighbor related parameter
should be adjusted such as CIO and CIO offset.
CIO Offset is the most recommended parameter to adjust if an engineer wants to advance or delay a
SHO since it is neighbour relation specific parameter and SHO to other neighbours are not affected.

9.a.2 3G Reselection Parameters

Cell Selection/Reselection Parameters

Below are the idle and connected mode cell reselection parameters that can be tuned to improve cell
reselection performance in order to achieve best coverage during idle or PS connected mode. Again,
it is advised not to change logical parameters as much as possible. Physical change is first priority for
DT related problems. Logical parameter change is only advised when physical change is already done
and problem is still not resolved.

9.b 2G Parameters for Optimization

9.b.1 2G Idle and Reselection Parameters

Idle and Reselection Parameters Effects

Parameter Recommended Optimization Range Remarks Increase Decrease
GSM900: 8
RXMIN Non Optim Idle Mode - -
DCS1800: 10
Hard Reselection Fast Reselection
CRH 12dB 12 to 15 dB Cell Reselection
(on different LAC) (on different LAC)
GSM 900: 0 GSM 900: Non Optim Cell will be more Cell will be less
CRO Cell Reselection
DCS1800: 12 DCS1800: 8 to 15 attractive attractive
PT 0 Non Optim Cell Reselection - -
Among the 2G idle parameters above 2 of them cannot be changed anymore –
RxMin and PT- because they were already standardized by 2G strategic team. Almost the
same is true with CRH, it is already standardized by 2G strategic team that’s why it should
not be changed as much possible, only when really needed. It is advised that CRO be the
only idle parameter that will be tuned/changed if really necessary. If DT bad spot or problem
can be solved by physical adjustment make it a priority recommendation and action. Tune
the parameters only when physical changes are already exhausted.

9.b.2 2G Handover Parameters (Set on Cell to Cell Relation)

Cell to Cell Handover Parameters Effects

Parameter Recommended Optimization Range Remarks Increase Decrease
INTERCELLHYST 68 64 to 72 All Layers Hard Handover Fast Handover
Same Layer (GSM to
PBGTMARGIN 68 64 to 72 Hard Handover Fast Handover
GSM, DCS to DCS)
From Lower Layer to
INTELEVHOHYST 67 64 to 70 Higher Layer (GSM to Hard Handover Fast Handover
DCS)
 MINOFFSET 0 0 to 10 All Layers Hard Handover Fast Handover
BQMARGIN 69 66 to 72 All Layers Fast Handover Hard Handover

For Handover parameters it is advised to change only PBGTMARGIN for same layer
handover optimization and INTELEVHOHYST for Inter Layer Handover optimization. Other
parameters are advised not to be changed as much as possible.

9.b.3 Inter Layer (Set on Cell level)

8. IMPROVEMENT REQUIRED

After the DT2 or cluster verification drive the normal process is to make the DT2 or Verification DT
report to confirm if all the KPIs are already passed and if the cluster has improved. Due to time
limitation DT2 complete report is substituted by Improvement Report which shows all improvements,
degradations and persistently bad spot in few slides. This is to ensure that the changes caused
improvement. If the changes caused degradation then a rollback can be done. If the changes did not
improve the bad spot further rectification will be done.

Below is the Legend:

BLUE CIRCLE – Bad spot improved after optimization
YELLOW CIRCLE – Bad spot persists even after optimization. This requires further analysis and
optimization.
RED CIRCLE – Good spot has degraded. This also requires deep analysis to determine the cause of
degradation.

Coverage Improvement

Accessibility Improvement (Blocked call in this example)

Retainability Improvement (Dropped call in this example)

Integrity Improvement (DL throughput in this example)

Integrity Improvement (UL throughput in this example)

• COMPLEMENTARY ANALYSIS

3G UE Category analysis based on L3 Message

3G APN, MBR,GBR Analysis based on L3 Message