03 Network Performance Optimization

(1)

Network Performance

Optimization

(2)

Summary

• PM Theory • Dx Causes • Counters, Tables • Formulas • KPIs • PM Process • Network Monitoring • Performance Monitoring

• Performance Analysis and Troubleshooting

• Trouble Ticket and Work Order (Change Requests)

• PM Tools – Optional

• Optimizing Tools

• Testing Tools

• Reporting Tools

(3)

PM Theory

Dx Causes

Counters, Tables

KPIs

(4)

Company Confidential

PM Theory

(5)

KPI's

Counters

DX-causes

Levels of information

Performance

Reports

BSS

Measurements

Observations

(6)

MSC

BSC

BTS

NetAct

DX CAUSE

GSM CAUSE

Successful

Unsuccessful = CLEAR CODES

COUNTERS

1 ←

N

1 ←

N

→

1

(7)

Where are DX causes used ?

Program

block

A

Program

block

B

Service Block controlling the Program Blocks A, B, ….

DX Cause In (Phase, Channel, Cause In)

DX Cause Out (Phase, Channel, Cause Out)

DX Cause In (Phase, Channel, Cause In)

DX Cause Out (Phase, Channel, Cause Out)

(8)

How to detect faults?

Program

block

A

DX Cause In (Phase, Channel, Cause In) DX Cause Out (Phase, Channel, Cause Out)

Cause In <> Cause Out ?

NO

_{Successful Event}

(9)

Counters triggering

Program block in BSC (e.g. ABIPRB) Different checking e.g.

Acknowledgement correct ? rej_phantom_res Ghost CCCH Res Establishment cause valid ? SDCCH act. fail ch_act_nack Phase ended successfully ?

cause code in = cause code out

DX cause code out counter

Channel request Channel activation Channel activation ackn.

(10)

Program blocks in the BSC

• ABIPRB

Abis Interface Program Block

• AIVPRB

A interface Signaling Program Block in BSC

• HASPRB

Handover Attempt Supervisor Program Block

• RC0PRB

Resource Control Program Block in BSC

• RCSPRB

Radio Connection Supervision Program Block

• RRMPRB

Radio Resource Management Program Block

(11)

Example of PRB transactions

RRMPRB

HASPRB

RCSPRB

RR M_ BTS_LOAD_INFO_S

load info of own & adj cells every 20 s

TRHO decision on cell load & evaluate target cell AV_RXLEV_NCELL(n)> TrhoTargetL evel( n) am hTrhom arginPBGT<PBGT<homarginPBGT IF suitable target cell found start BSC TRHO

HAS_A SK_H O_ S

with cause BC _T_BSC _TRHO_C

Start handover signalling

NO_RAD IO_R ESOU RCE_ AVAILABLE

Channel allocation H O

IF cause is HOPCCAUSE_T_BSC_T RHO_Cupdate 1167

checks % free TCHs in target cell

IF lower than amhMaxLoadOf TgtC ell then allocate TCH update 1168

IF greater send NO_RADIO_RESOURCE_AVAILABLE to HASPRB update 1169

1

2 3

4

(12)

DX-cause cause mapping

PHASE CAUSE VALUE COUNTER KPI SDCCH TCH CHANNEL TYPE

D

X

-C

A

U

S

E

(13)

1003

1004

1005

1013

315 - conn_fail

1-8 PHASE CAUSE VALUE NMS2000 Counter TCH SDCCH CHANNEL TYPE

Counter pegging example

1014

1015

9-11 12-14 15

Note that there are no counters that are incremented by the same DX Cause, so if you have the channel, phase and cause value you are able to know which is the counter incremented!

(14)

PM Theory

Nokia BSS counters (and tables!)

(15)

Nokia BSS counters: numbering

• Counter =

XXX

YYY

where

• XXX

= measurement table

• YYY

= counter number in measurement table

• Example: counter 001000 or c1000

• XXX

= 001 = c1 = traffic measurement

(16)

Nokia BSS counters: measurement tables

• How to activate them?

• They are activated at BSC level or can be activated at NMS level.

• If they are part of optional feature, the feature needs to be present on the PRFILE of each BSC. The parameter related to the feature needs to be activated.

• Start date and End date needs to be defined.

• Start time and End time of each day of the week needs to be defined

• Period needs to be defined

Set parameter in PR_FILE (WOC): ZWOC:10,65,FF;

Set measurement (TPM):

ZTPM:<measurement group>,<measurement type>:<measurement day>, <measurement interval>,<output interval>:;

ZTPM:MEASUR,CHAN_FIN:ALL,0–0–24–0,60:DB1=0,DB2=8; Start measurement (TPS):

(17)

Nokia BSS counters: measurement tables

• Traffic measurement

• Resource availability measurement

• Resource access measurement

• Handover measurement

• Handover adjacent cell measurement

• Power control measurement

• RxQuality statistics measurement

• RxLevel statistics measurement

• Timing advance statistics measurement

• FER measurement

• Channel Finder measurement

(18)

Nokia BSS counters: Traffic measurements

• Table name in the database : P_NBSC_TRAFFIC (001xxx)

• SDCCH related measurement part

• Attempts, success and failure counters

• TCH related measurement part

• Queuing measurement part

• GPRS measurement part

(19)

Nokia BSS counters: Resource availability

measurements

• Table name in the database : P_NBSC_RES_AVAIL (002xxx)

• Availability of TCHs and SDCCHs

• Time congestion of TCHs and SDCCHs

• Average and peak number of busy TCHs and SDCCHs

(20)

Nokia BSS counters: Interference Bands

-95 < RxLevel < -90 4 RxLevel Boundaries (dBm) Band -90 < RxLevel < -47 5 -100 < RxLevel < -95 3 -105 < RxLevel < -100 2 -110 < RxLevel < -105 1 BCCH/ CCCH SDCCH TCH free TCH traffic TCH traffic TCH traffic TCH free TCH free

Interf. Quality Quality Quality Interf. Interf.

The counters of interference are divided in 5 Bands, e.g:

Interference is measured only in UL and in "Idle Mode“. Measures can be per Time Slot (P_NBSC_RES_AVAIL) or averaged over a TRX

(21)

Nokia BSS counters: Resource access measurements

• Table name in the database : P_NBSC_RES_ACCESS (003xxx)

• Number of messages sent in Abis interface

• Paging, Immediate assignment, channel request, delete indication

• Number of seizures for MOC, MTC, LU, CR, EC, SMS

(22)

Nokia BSS counters: Handover measurements

• Table name in the database : P_NBSC_HO (004xxx)

• Number of incoming/outgoing MSC/BSC/Intracell handover attempts

• Number of successful/unsuccessful incoming/outgoing MSC/BSC/Intracell handovers

• Unsuccessfull handovers per failure causes

(23)

Nokia BSS counters: Handover adjacent cell

measurements

• Optional feature in BSC

• PRFILE parameter: 28-RXQ_HAC_USAGE_P = FF

• Table name in the database : P_NBSC_HO_ADJ (015xxx)

• Number of handover attempts on a per adjacency basis

• Number of handover success on a per adjacency basis

(24)

Nokia BSS counters: Power control measurements

• Table name in the database : P_NBSC_POWER (005xxx)

• Number of UL/DL power increase/decrease on a per cause basis (quality or level)

• Average MS/BS power

• Average UL/DL RxQual, RxLev

• Peak MS/BS distance

(25)

Nokia BSS counters: RxQuality statistics

measurements

• RxQual is split in classes going from 0 to 7 and is related to BER (%) according to:

• RxQual = 0 means BER < 0,2 %

• RxQual = 1 means 0,2 < BER < 0,4 %

• RxQual = 2 means 0,4 < BER < 0,8 %

• RxQual = 3 means 0,8 < BER < 1,6 %

• RxQual = 4 means 1,6 < BER < 3,2 %

• RxQual = 5 means 3,2 < BER < 6,4 %

• RxQual = 6 means 6,4 < BER < 12,8 %

• RxQual = 7 means 12,8 < BER

• The relation between BER and speech quality depends on the fading profile (hopping/non-hopping) and codec used.

Acceptable for EFR

Acceptable for AMR (AFS590) Useless

(26)

Nokia BSS counters: RxQuality statistics

measurements

• Table Name: P_NBSC_RX_QUAL (014xxx)

Optional Feature in BSC - PRFILE parameter: 28-RXQ_HAC_USAGE_P = FF

Counter IDCounter name

014000 BTS_ID 014001 TRX 014002 … 17 FREQ_UL/DL_QUAL0 … 7 014018 FREQ_GROUP_ID 014019 TRX_FREQUENCY 014020 TRX_TYPE 014021 … 84 AMR_FR_MODE_1 … 4_UL/DL_RXQUAL_0 … 7 014085 … 148 AMR_HR_MODE_1 … 4_UL/DL_RXQUAL_0 … 7 014149 AMR_FR/HR_CODEC_MODE_SET

Number of UL/DL radio measurement reports per RxQuality band on per TRX

and Codec type basis

Frequency of samples (calls) where UL/DL Rx Quality was 0…7

(27)

Nokia BSS counters: RxLevel statistics measurements

-47dBm level 63 Class 63 -70dBm level 40 Class 40 -80dBm level 30 Class 30 -90dBm level 20 Class 20 -95dBm level 15 Class 15 -100dBm level 10 Class 10 -110dBm level 0

QUALITY Bit Error Rate

0 Less than 0,2% 1 0,2% to 0,4% 2 0,4% to 0,8% 3 0,8% to 1,6% 4 1,6% to 3,2% 5 3,2% to 6,4% 6 6,4% to 12,8% 7 Greater than 12,8%

8 classes for Quality dimension 6 classes for Level dimension (7 levels)

(28)

Nokia BSS counters: RxLevel statistics measurements

• Table name in the database : P_NBSC_RX_STATISTICS (053xxx)

Optional Feature in BSC - PRFILE parameter: 27-RNOS_USAGE_P = FF

053000 BTS_ID 053001 TRX_ID 053002 … 6 CLASS_UPPER_RANGE 053007 … 102 FREQ_UL/DL_QUAL0 … 7 053103 FREQ_GROUP_ID 053104 TRX_FREQUENCY 053105 TRX_TYPE

Number of UL/DL radio measurement reports per RxQuality band on per TRX

and RxLevel class

• FREQ_UL_QUAL0 actually corresponds to 6 counters! 1 for each

RxLevel Class!!!

• Counters are updated every 480 ms.

(29)

Nokia BSS counters: Timing advance statistics

measurements

0 km

TA=0

GSM max distance: 35 km

_TA=63

Distance from BTS

• TA value is necessary to synchronize BTS and MS (Air interface) according to

their relative distance.

• M

ax Air IF delay ~ 550 m (TA unit). In case the MS is further away, the signal must be sent in advance in order to arrive with a maximum of ½ bit delay.

TSL0 TSL1

0.550 km

(30)

Nokia BSS counters: Timing advance statistics

measurements

• Table Name: P_NBSC_TIMING_ADVANCE (055xxx)

055000 CLASS_UPPER_RANGE

055009 … 18 FREQ_REPORTS

055019 … 28 MIN_POWER

055029 … 38 MAX_POWER

055039 … 48 AVE_POWER

Min/Max/Ave MS power per timing advance class

Number of measurement reports per timing advance class

(31)

Nokia BSS counters: Timing advance statistics

measurements

41 - 63 31 – 40 21 – 30 16 -20 11 – 15 9 – 10 7 – 8 5 – 6 3 – 4 0 – 2 TA boundaries 0 34.65 0 22.0 0 16.5 0 11.0 124 8.25 39 5.5 74 4.4 108 3.3 279 2.2 58947 1.1 Freq of reports Distance upper range (km) 055009 … 18 FREQ_REPO RTS Shows where subscribers are (distance) !!!

Timing Advance Classes

(32)

Nokia BSS counters: FER measurements

• Optional feature in BSC

• PRFILE parameter: 628-FER_USAGE = A

• PRFILE parameter: 28-RXQ_HAC_USAGE_P = FF

• Table name in the database : P_NBSC_FER (077xxx)

• UL FER from each codec of each TRX in the BTS

(33)

Nokia BSS counters: Channel Finder measurements

• Optional feature in BSC

• PRFILE parameter: 65-CHAN_FIN_USAGE_P = FF

• Table name in the database : P_NBSC_CHANNEL_FINDER (070xxx)

• Number of Samples per Class of signal strength per BSIC, BCCH:

• X = Downlink signal strength from undefined adjacent cell - Downlink signal strength from serving cell

1. X < DB_VALUE_LOW NUM_OF_SAMPLES_IN_CLASS_1

2. DB_VALUE_LOW < X < DB_VALUE_HIGH NUM_OF_SAMPLES_IN_CLASS_2

(34)

Nokia BSS counters: Link Balance measurements

• Path balance is the difference between the uplink and the downlink strength for

each cell.

• In a perfect planned network the Link Balance statistics are perfectly balanced (in

every moment the only difference between RxLevel DL and RxLevel UL should

be the correction due to the different MS and BTS sensitivity)

DL DLDL DL

UL – signal doesn’t have enough strengh to reach BTS. BTS can not “hear” the MS

(35)

Nokia BSS counters: Link Balance measurements

• Table Name: P_NBSC_LINK_BALANCE (054xxx)

Counter IDCounter name MS Power BS Power

054000 NORMAL < <

054001 MS_LIMITED = <

054002 BS_LIMITED < =

054003 MAX_POWER = =

min (MS TX PWR MAX,

(36)

(37)

PM Theory

(38)

Main BSS oriented KPIs

• PCH success: helps in dimensionning CCCH resources, may affect MS pageability

• RACH success: helps in dimensionning CCCH resources, may affect MS access to the network

• AGCH success: helps in the dimensionning CCCH resources, may affect MS access to the network

(39)

Main BSS oriented KPIs

• SDCCH traffic: helps in dimensionning signalling resources

• SDCCH availability: informs about available SDCCH resources

• SDCCH load: helps in anticipating SDCCH upgrade and shows efficiency of the use of signalling resources

• SDCCH blocking: lack of SDCCH resources, directly affects call setup failure, billing has not started, action needed urgently

• SDCCH congestion

• SDCCH access probability: 1-SDCCH blocking

• SDCCH drop rate: may affect call setup failure, action needed

(40)

Main BSS oriented KPIs

• TCH traffic: helps in dimensionning TCH resources, traffic is money

• TCH usage

• TCH holding time

• TCH availability: informs about TCH resources available

• TCH load: helps in anticipating TCH upgrade and shows efficiency of the use of traffic resources

• TCH blocking: directly affects call setup failure, billing has not started, action needed urgently

• TCH congestion

• TCH denied for call request

• TCH drop rate: directly affects dropped call rate, billing has stopped, action needed

(41)

Main BSS oriented KPIs

• RxQuality: directly linked to Bit Error Rate, may affect call quality in the case that the system does not succeed in correcting the erroneous bits

• DL/UL Cumulative Quality < 5

• Frame Erasure Rate: affect call quality, directly perceived by the end-user

• Frequency Load: together with quality indicators (FER and dropped call rate) shows the efficiency of the spectrum usage

• Ho distribution

• Ho failure per adjacency

(42)

PM Theory

Formulas

(43)

Summary of Formulas

• SDCCH Traffic (trf_11b), Availability (ava_3a) and Congestion (cngt_2)

• SDCCH access probability (csf_1a)

• SDCCH success ratio (csf_2l)

• TCH traffic (trf_24c)

• TCH Availability (ava_28a) and Usage (trf_83b)

• TCH blocking (blck_29)

• TCH call blocking (blck_8i)

• TCH drop call ratio (dcr_32a)

• TCH drop call ratio, after TCH assignment (dcr_5a)

• Ho failure, total (hfr_2a)

• Ho failure, radio blocking (hfr_55a)

• Ho drop (hfr_68a)

(44)

Graphical Summary of Formulas

TCH Blocked SDCCH Blocked TCH Dropped TCH Dropped SDCCH Successful Call SDCCH Seizure Attempts SDCCH Assigned Successful SDCCH TCH Seizure Attempts TCH Assigned SDCCH SDCCH Traffic, Availability, Congestion, Access probability TCH Traffic, Availability, Congestion, Access probability or Blocking

(45)

SDCCH Traffic, Availability and Congestion

Avg. Avail. SDCCH =

(ava_3a)

[Erlang]

sum(ave_busy_sdcch)

(

c2030

)

sum(res_av_denom15)

(

c2031

)

Counters from

p_nbsc_res avail

(

002xxx

)

[sec]

SDCCH Congestion =

(cngt_2)

sum(sdcch_cong_time/100)

=

= (

c2033

) / 100

Avg. SDCCH Traffic =

(trf_11b)

ava_46 + ava_47=

sum(decode(trx_type,0,ave_sdcch_sub)/

(46)

SDCCH access probability (csf_1a)

sum(

sdcch_busy_att

–

tch_seiz_due_sdcch_con

)

sum(

sdcch_seiz_att

)

sum (

c1001

–

c1099

)

sum (

c1000

)

csf_1a

= 100 – 100 x

csf_1a

=

100 –

blck_5a

= 100 – 100 x

sum of blocked SDCCH – sum of FACCH call setup

sum of attempts of SDCCH channel reservation

csf_1a

= 100 – 100 x

Counters from

(47)

(48)

SDCCH success ratio (csf_2l)

sum of failures on SDCCH channel - sum of failures that

happens on Abis between IMMEDIATE ASSIGNMENT

COMMAND sent by BSC and ESTABLISH INDICATION

received from the BTS

sum of successful SDCCH seized by MS for MOC (including

SMS), MTC (including SMS), LU, CR, EC + sum of successful

incoming intercell SDCCH-SDCCH HOs

csf_2l = 100 –100 x

Keeping it simple:

(49)

SDCCH success ratio (csf_2l)

sum(a.

sdcch_radio_fail

+a.

sdcch_rf_old_ho

+

a.

sdcch_user_act

+ a.

sdcch_bcsu_reset

+ a.

sdcch_netw_act

+ a.

sdcch_bts_fail

+ a.

sdcch_lapd_fail

+ a.

sdcch_a_if_fail_call

+ a.

sdcch_a_if_fail_old

+ a.

sdcch_abis_fail_old

+

(a.

sdcch_abis_fail_call

- C))

sum(b.

succ_seiz_term

+b.

succ_seiz_orig

+b.

sdcch_call_re_est

+b.

sdcch_loc_upd

+b.

imsi_detach_sdcch

+b.

sdcch_emerg_call

+sum(c.

msc_i_sdcch

+ c.

bsc_i_sdcch

)

csf_2l

= 100 –100 x

C= part of

sdcch_abis_fail_call

that happens before establishment indication =

a.

sdcch_assign

- (b.

succ_seiz_term

+b.

succ_seiz_orig

+b.

sdcch_call_re_est

+b.

sdcch_loc_upd

+b.

imsi_detach_sdcch

+b.

sdcch_emerg_call

)

Why minus C?

C” hereby contains sdcch abis failure due to “5/8 OF GHOSTS (ph.1) and other failures BEFORE ESTABL. IND”, which does not indicate real sdcch failure.

(50)

SDCCH success ratio (csf_2l)

sum(

c1003

+

c1004

+

c1037

+

c1038

+

c1039

+

c1036

+

c1035

+

c1078

+

c1079

+

c1076

+ (

c1075

- C))

sum(

c3012

+

c3013

+

c3020

+

c3019

+

c3033

+

c3021

)

+sum(

c4045

+

c4058

)

csf_2l

= 100 –100 x

C= part of

sdcch_abis_fail_call

(

c1075

) that happens before establishment

indication =

c1007

- (

c3012

+

c3013

+

c3020

+

c3019

+

c3033

+

c3021

)

Counters from

Counters from table(s

table(s

table(s):):):):

a =

p_nbsc_traffic

(

001xxx

)

b =

p_nbsc_res_access

(

003xxx

)

c =

p_nbsc_ho

(

004xxx

)

(51)

Obs: These counters can also trigger in other points not detailed in this diagram

SDCCH success ratio counters

(52)

TCH traffic (trf_24c)

sum(period_duration*

ave_busy_tch / res_av_denom14

/ 60)

trf_24c

=

Counters from

Counters from table(s

table(s

table(s):):):):

p_nbsc_res_avail

(

002xxx

)

trf_24c

= cumulative TCH traffic for a given period

sum(period_duration*

c2027

/

c2028

/ 60)

(53)

TCH Availability and Usage

Normal TCH usage ratio for CS =

(trf_83b)

trf_97

(ava_28a + ava_16b)

[%]

[TSL] sum(decode(trx_type,0, ave_avail_TCH_sum))

sum(decode(trx_type,0, decode(ave_avail_TCH_sum, 0, 0, ave_avail_TCH_den)))

Avg. CS TCH in normal TRX =

(ava_28a)

TCH Availability = Average available TCHs for CS use in normal TRXs.

TCH Usage for CS = % of the total available normal TCH capacity has been used for

(54)

TCH blocking (blck_29)

sum of requests for a TCH channel - sum of TCH

assignments for call re-establishment and new calls

minus sum of TCH rejected for a new call due to A

interface pool type mismatch or congestion

sum of requests for a TCH channel minus sum of

TCH rejected for a new call due to A interface pool

type mismatch or congestion

blck_29

= 100 x

Keeping it simple:

(55)

TCH blocking (blck_29)

sum(a.

tch_call_req

+ a.

tch_fast_req

)

-sum(c.

tch_re_est_assign

+ c.

tch_new_call_assign

)

-sum(a.

tch_rej_due_req_ch_a_if_crc

-(b.

bsc_i_unsucc_a_int_circ_type

+b.

msc_controlled_in_ho

+b.

ho_unsucc_a_int_circ_type

))

sum(a.

tch_call_req

+ a.

tch_fast_req

)

-sum(a.

tch_rej_due_req_ch_a_if_crc

-(b.

bsc_i_unsucc_a_int_circ_type

+b.

msc_controlled_in_ho

+b.

ho_unsucc_a_int_circ_type

) )

blck_29 = 100 – 100 x

(56)

TCH blocking (blck_29)

sum(

c1026

+

c1043

) – sum(

c57032

+

c57033

) –

sum(

c1122

– (

c4097

+

c4101

+

c4098

))

sum(

c1026

+

c1043

) –

sum(

c1122

– (

c4097

+

c4101

+

c4098

))

blck_29

= 100 – 100 x

Counters from

Counters from table(s

table(s

table(s):):):):

a =

p_nbsc_traffic

(

001xxx

)

b =

p_nbsc_ho

(

004xxx

)

(57)

TCH call blocking (blck_8i)

sum of (TCH channel requests for a call –

successful TCH channel seizures for a call)

sum of TCH channel requests for a call

blck_8i

= 100 x

sum(a.

tch_requests_call_attempt

– a.

succ_tch_seiz_call_attempt)

blck_8i

= 100 x

sum(a.

tch_requests_call_attempt)

sum(

c1192

–

c1193

)

sum(

c1192

)

blck_8i

= 100 x

Counters from:

(58)

(59)

TCH drop call ratio - formulas

‘001204 DROP TCH ASSCOMPL TO RFCH REL’ [S11.5 counter]

TCH DROPS AFTER SEIZURE

TCH_RADIO_FAIL /c1013 +TCH_RF_OLD_HO /c1014 +(TCH_ABIS_FAIL_CALL /c1084 -FACCH_CALL_SETUP_FAIL_PAGING)/c2072 +TCH_ABIS_FAIL_OLD /c1085 +TCH_A_IF_FAIL_CALL /c1087 +TCH_A_IF_FAIL_OLD /c1088 +TCH_TR_FAIL /c1029 +TCH_TR_FAIL_OLD /c1030 +TCH_LAPD_FAIL /c1046 +TCH_BTS_FAIL /c1047 +TCH_USER_ACT /c1048 +TCH_BCSU_RESET /c1049 +TCH_NETW_ACT /c1050 +TCH_ACT_FAIL_CALL /c1081 -tch_re_est_assign /c57032 ---CONVERSATION DROPS dropped_calls /c57007

---TCH DROPS AFTER ASSIGNMENT tch_new_call_assign /c57033 +tch_ho_assign /c57034 -tch_norm_release /c57035 -tch_ho_release /c57036 -tch_re_est_release /c57037 ---TCH ASSIGNMENTS FOR NEW CALL tch_new_call_assign /c57033 CONVERSATION STARTED conn_ack to BTS TCH ASSIGNED (alert followed) TCH SEIZED BSC allocates a TCH as a response to

TCH SEIZURES FOR NEW CALL tch_norm_seiz /c1009 +tch_seiz_due_sdcch_con /c1099 +msc_i_sdcch_tch /c4044 +bsc_i_sdcch_tch /c4057 +cell_sdcch_tch /c4074 -tch_succ_seiz_for_dir_acc /c1165 -tch_re_est_assign /c57032 S11 dcr_8h: STARTED CONVERSATIONS conver_started /c57015 - msc_i_tch_tch /c4043 CLEAR COMMAND from MSC

TCH DROPS AFTER ASSIGNMENT

spare057044 /c57044

-tch_re_est_assign /c57032

---TCH ASSIGNMENTS FOR NEW CALL

tch_new_call_assign /c57033

TCH DROPS AFTER ASSIGNMENT

drop_after_tch_assign /c1202

-tch_re_est_assign /c57032

---TCH ASSIGNMENTS FOR NEW CALL

tch_new_call_assign /c57033

TCH RELEASE Disconnect from MS (A) Disconnect. from MSC (B) S10.5 dcr_8g S12 dcr_32a S11 dcr_8h S7 dcr_8b RF CHN RELEASE Rf_channel_release_ack from BTS S4 dcr_5a

(60)

TCH drop call ratio (dcr_32a)

sum(tch_radio_fail+tch_rf_old_ho+(tch_abis_fail_call

- facch call setup fail paging)+tch_abis_fail_old

+ tch_a_if_fail_call+tch_a_if_fail_old+ tch_tr_fail

+tch_tr_fail_old+tch_lapd_fail+tch_bts_fail

+ tch_user_act+tch_bcsu_reset+tch_netw_act+tch_act_fail_call) - sum(b.tch_re_est_assign); call re-establishments

sum(a.tch_norm_seiz)

+ sum(c.msc_i_sdcch_tch+c.bsc_i_sdcch_tch

+ c.cell_sdcch_tch); DR calls

- sum(a.tch_succ_seiz_for_dir_acc) ; ref. 1

+ sum(a.tch_seiz_due_sdcch_con); FACCH call setup calls - sum(b.tch_re_est_assign); call re-establishments

dcr_32a = 100 x

sum of TCH failures sum of new calls

dcr_32a = 100 x

Ref.1. Compensation needed since in case of Direct Access to super reuse TRX the tch_norm_seizis triggered in parallel with cell_sdcch_tch.

(61)

TCH drop call ratio (dcr_32a)

sum(

c1013

+

c1014

+ (

c1084

-

c2072

) +

c1085

+

c1087

+

c1088 + c1029

+

c1030

+

c1046

+

c1047

+ c1048

+

c1049

+

c1050

+

c1081

) – sum(

b57032

)

sum(

c1009

+

c4044

+

c4057

+

c4074

+

c1099

)

–

sum(

c1165

) -

sum(

b57032

)

dcr_32a

= 100 x

Counters from:

a =

p_nbsc_traffic

(

001xxx

)

b =

p_nbsc_service

(

057xxx

)

c =

p_nbsc_ho

(

004xxx

)

(62)

tch_a_if_fail_call _{tch_a_if_fail_old} tch_a_if_fail_new

TCH drop call ratio (dcr_32a) - reasons

BSC

TC

tch_abis_fail_old tch_abis_fail_call tch_abis_fail_new tch_tr_fail _{tch_bcsu_reset} tch_user_act tch_netw_act tch_act_fail_call tch_bts_fail tch_lapd_fail tch_tr_fail_old tch_tr_fail_new tch_a_if_fail tch_abis_fail

BTS

tch_radio_fail tch_radio_fail_old tch_radio_fail_new

(63)

TCH drop call ratio (dcr_32a)

Obs1: These counters can also trigger in other points not detailed in this diagram

Obs2: Other counters that compose this formula are not detailed in the diagram

(64)

TCH drop call ratio, after TCH assignment (dcr_5a)

number of failures during a call in progress after the CONNECT_ACK message on TCH

number of the conversation phases started (CONNECT_ACK) -number of successful incoming TCH-TCH HOs (MSC controlled)

dcr_5a = 100 x sum(c57007) sum(c57015-c4043) dcr_5a = 100 x dcr_5a = 100 x sum(b.dropped_calls)

sum(b.conver_started) – sum (a.msc_i_tch_tch) Counters from: Counters from: Counters from: Counters from: a = p_nbsc_service (057xxx) b = p_nbsc_ho (004xxx)

(65)

DL CUMULATIVE QUALITY < 5 (dlq_2, dlq_2a)

sum(freq_dl_qual0 + ... + freq_dl_qual4) sum(freq_dl_qual0 + ... + freq_dl_qual7) Counters from

Counters from Counters from

Counters from table(stable(stable(s):):):):table(s

dlq_2: p_nbsc_rx_qual (014xxx) dlq_2a: p_nbsc_rx_statistics (053xxx) dlq_2 = 100 x

sum of measurement reports whose DL quality has been measured with RxQuality < 5

sum of all measurement reports dlq_2, dlq_2a = 100 x dlq_2, dlq_2a = 100 x sum(c53055 + ... + c53084) sum(c53055 + ... + c53102) dlq_2a = 100 x sum(c14010 + ... + c14014) sum(c14010 + ... + c14017)

(66)

UL CUMULATIVE QUALITY < 5 (ulq_2, ulq_2a)

sum(freq_ul_qual0 + ... + freq_ul_qual4) sum(freq_ul_qual0 + ... + freq_ul_qual7) Counters from

Counters from Counters from

Counters from table(stable(stable(s):):):):table(s

ulq_2: p_nbsc_rx_qual (014xxx) ulq_2a: p_nbsc_rx_statistics (053xxx) ulq_2 = 100 x

sum of measurement reports whose UL quality has been measured with RxQuality < 5

sum of all measurement reports ulq_2, ulq_2a = 100 x ulq_2, ulq_2a = 100 x sum(c53007 + ... + c53036) sum(c53007 + ... + c53054) ulq_2a = 100 x sum(c14002 + ... + c14006) sum(c14002 + ... + c14009)

(67)

Ho distribution

Directed Retry /c4079 (S2) cause_dir_retry UL quality /c4023 cause_up_qual UL level /c4024 cause_up_lev UL interference /c4029 cause_interf_up Pbdgt /c4032 cause_pbdgt DL quality /c4025 cause_down_qual DL level /c4026 cause_down_lev DL interference /c4030 cause_interf_down Upgrade of GPRS territory /c4130 (S9) ho_att_due_to_gprs

(68)

Total Ho failure ratio (hfr_2a)

sum(a.

msc_o_succ_ho +

a.

bsc_o_succ_ho +

a.

cell_succ_ho

)

hfr_2a

=100 x

sum(b.

msc_o_ho_cmd

+ b.

bsc_o_ho_cmd_assgn

+ b.

bts_ho_assgn

)

sum(c

4004

+ c

4014

+ c

4018

)

hfr_2a

=100 x

sum(c

1195

+ c

1196 +

c

1197

)

Counters from

Counters from table(s

table(s

table(s):):):):

p_nbsc_ho

(

04xxx

)

p_nbsc_traffic

(

01xxx

)

(ho attempts – successful ho)

hfr_2a

=100 x

ho attempts

(69)

HO failure % due to radio interface blocking (hfr_55a)

sum(a.

msc_o_fail_lack

+ a.

bsc_o_fail_lack

+ a.

cell_fail_lack

)

hfr_55a

=100 x

sum(b.

msc_o_ho_cmd

+ b.

bsc_o_ho_cmd_assgn

+ b.

bts_ho_assgn

)

sum(c

4055

+ c

4072

+ c

4019

)

hfr_55a

=100 x

sum(c

1195

+ c

1196 +

c

1197

)

Counters from

Counters from table(s

table(s

table(s):):):):

p_nbsc_ho

(

04xxx

)

p_nbsc_traffic

(

01xxx

)

handovers failing due to blocking

hfr_55a

=100 x

(70)

HO drop ratio (hfr_68a)

sum(a.bsc_o_drop_calls + a.msc_o_call_drop_ho + a.cell_drop_calls) sum(b.msc_o_ho_cmd + b.bsc_o_ho_cmd_assgn + b.bts_ho_assgn); -sum(a.msc_o_fail_lack + a.bsc_o_fail_lack + a.cell_fail_lack);

-sum(a.msc_o_not_allwd + a.bsc_o_not_allwd + a.cell_not_allwd); -sum(a.bsc_o_unsucc_a_int_circ_type + a.msc_controlled_out_ho + a.ho_unsucc_a_int_circ_type )

hfr_68a = 100 x

sum of ho failures

hfr_68a =100 x

all HO attempts

- handovers failing due to blocking - handovers failing due to not allowed - wrong Aif circuit type

Counters from: Counters from:Counters from: Counters from:

a = p_nbsc_ho (004xxx) b = p_nbsc_traffic (001xxx)

(71)

PM Process

Network Monitoring

Performance Monitoring

Performance Analysis and Troubleshooting

(72)

PM Process

Performance Analysis and Troubleshooting

Trouble Ticket and Work Order (Change Requests) Network Monitoring

Performance Monitoring

Once KPIs (E.g. Drop call rate – dcr_4e) and Targets (dcr_4e < 2%) have been agreed with customer ...

Once Network Audit has been done as well as regular consistency checks ...

... PM Process begins

(73)

PM Process

(74)

Network monitoring

• Area level monitoring

• Whole network ---> Result : Network quality trends

• Areas ---> Result : Area quality trends

• Network elements monitoring

• MSC ---> Result : MSC related problem detection

• BSC ---> Result : BSC related problem detection

• BTS ---> Result : BTS hit lists (Bad cells)

• TRX ---> Result : TRX hit list (Bad TRXs)

• Interface monitoring

• Abis and A interface ---> Result : Transmission problem detection and Heavy data flow load

Few trend rep_orts Graphical

Many detailed_reports Textual or gra_phical

(75)

Area/BSC monitoring

• Call Setup failures Daily Average: 100 – csf_1a x csf_2a x csf_3l

• Dropped call rate Daily Average: dcr_3j

• GSM quality UL: ulq_2 (% of RxQualUL samples < 5 o 6)

• GSM quality DL: ulq_2 (% of RxQualDL samples < 5 o 6)

• Voice quality UL: ulq_3 (% of FER UL samples < 9 %)

• Voice quality DL: dlq_3 (% of FEP DL samples < 9 %)

• Handover Failure

Area quality trends

(76)

Segment/Cell/Sector/BTS monitoring

• Paging deleted • Paging buffer • RACH load • SDCCH blocking rate • SDCCH failure rate • TCH blocking rate • TCH failure rate

• Handover failure rate

• Handover cause UL quality/interference

• Handover cause DL quality interference

• Drop of number of SDCCH requests

• Drop of TCH traffic

• Few incoming handovers

• Few normal calls

BTS hit lis

(77)

TRX

• Bad RxQuality UL 0

• Bad RxQuality DL 0

• Bad RxQuality UL 7

• Bad RxQuality DL 7

• Idle UL interference out of band 1

• High RxLevUL – RxLevDL

• High RxLevDL – RxLevUL

(78)

Adjacencies

• High handover failures per adjacency basis

• High handover blocking per adjacency basis

(79)

PM Process

Performance Monitoring

Statistics

Drive Test, Benchmark

Customer Complaints

(80)

Statistics

• Strong points +

• Allows centralized data collection

• A cost efficient way to monitor network quality

• Pro-Active

• Selective performance monitoring (e.g. after new feature activation)

• Permanent information flow

• Useful to monitor trends

• Locate problems on a per-cell level

• Weak points

-• Needs statistically relevant traffic volume to provide reliable results

• Limited geographical location of problems is possible

(81)

Drive Test

• Another way of measuring the target network performance

• Necessary in different steps of optimisation

• Drive Test process consists on:

1. Doing the test and collecting the logs

2. Post-processing these logs

3. Analysis of Drive Test

GPS

Outdoor antenna Indoor antenna

Drive Test Software

Pre-defined route

(82)

Drive Test - plot

• Quality monitoring from moving subscriber point of view

---> Result :

Black spots detection

(83)

Drive Test - measurements

• Continuous call:

• RxQual DL • RxLevel DL • FER DL • MOS DL, UL

• Drop Call events

• Handover events

• Many Discontinuos calls;

• Call Setup Failure Rate (CSF)

• Cal Setup Success Rate (CSSR)

• Call Setup time

• Call Completion Rate (CCR)

• Drop Call Rate (DCR)

(84)

Drive Test

• Strong points +

• Necessary if there is no traffic in cell, for network acceptance

• Helps to adjust propagation models

• Quality reporting

• Troubleshooting

• Detects problems that can be masked by statistics

• Graphical reports on maps that allow to easily identify “hot areas”

• Monitoring and validation of new functionalities or changes done in the

network

(85)

Drive Test

• Strong points (cont.) +

• Identify coverage problems, meaning both coverage holes and cells covering less or more than wanted. Used in antenna tilting optimisation.

• Finding interference (difficult to measure) and bad quality.

• Detecting adjacency problems:

• Missing neighbours

• Unnecessary or unwanted neighbours

• Incorrectly defined adjacencies. • Finding hardware problems:

• Crossed sectors.

• Mixed antenna lines.

• Faulty units (TRXs, BBUs, etc).

(86)

Drive Test

• Weak points

-•

Very resource and time consuming, making it expensive to monitor wide

areas and sometimes restricts DTs to specific areas

• QoS monitoring from moving subscriber point of view. Gives a feeling of

customer view, although slow moving MS, indoor MS, high floor MS are not

taken into consideration

• Supplies in most cases only downlink information

• Snap-shot in time

• Statistics can be influenced by the velocity of the driver in good areas and in

bad areas.

(87)

Benchmark

• QoS Measurement of many networks

• Suitable for competitor analysis

• Easy to analyse and understand

“Benchmarking is the continuous process of measuring products, services and practices against the toughest competitors or those companies

recognized as industry leaders (best in class)."

Source: The Xerox Corporation

Ne

tw

ork

1 Netwo

_{rk 2}

Network 3

(88)

Customer Complaints

• Strong points (cont.) +

• Good co-operation between network optimization and customer service

department is necessary

• Helps to find not known problems

• Helps to confirm known problems

• Might pinpoint location of problem

• Reports indoor coverage holes

• May trigger fast decision from management in case heavy users are involved

• Problems with specific mobiles

• Problems of mobile configuration

(89)

Customer Complaints

• Weak points

-•

Reacting to customer complaints is reacting too late

• Not efficient for optimizing a whole network

(90)

PM Process

Performance Analysis and Troubleshooting

(91)

Performance Analysis and Troubleshooting

• Frequency and Neighbour Optimization*

• Antenna optimisation

• Coverage optimization

• Interference optimization

• Analysis of Worst Cells through Critical Indicators

• SDCCH blocking

• SDCCH failures

• TCH blocking

• TCH drop

• Analysis of Failure Causes

• Rx Quality

• Rx Quality x Rx Level

• Interference

• Timing Advance

• Link Balance

(92)

Antenna optimisation - Interference

• Detect sectors that are covering out of their service areas using:

• Timing advance report

• Drivetest measurements

• Improve interference by:

• Changing the antenna type (smaller vertical beamwidth)

• Downtilting

• Validate the optimisation action by:

• NMS statistics monitoring (Timing advance, SDCCH, TCH performance of the sector increased, overall traffic in the area has been maintained)

Interfering cells (overshooting cells) always have poor UL quality comparing to DL. Interfered cells (interfered by overshooting cells) always have poor DL quality.

(93)

Antenna optimisation - coverage

• Detect sectors that have small coverage area by:

• Analysing traffic distribution among neighbouring sectors

• Detect cross antenna installation by:

• Analysing HO performance per pair adjacency

• Improve coverage by:

• Changing the antenna type (higher gain)

• Uptilting that sector and/or downtilting neighbouring sectors

• Validate the optimisation action by:

• Drivetest measurement

• NMS statistics monitoring (traffic of the sector increased, SDCCH, TCH performance has not been degraded)

(94)

Analysis of Worst Cells - BTS hit lists

• What is a bad cell ?

• It is a cell that creates a negative impact on the end subscriber network quality perception

• Example 1 : the subscriber cannot access the network

• Example 2 : the subscriber experiences dropped calls

• Example 3 : the subscriber experiences bad voice quality during the call

(95)

Critical indicators

get service get SDCCH establish SDCCH connection get TCH establish TCH connec tion call phase release phase

Call Completion Rate (CCR) or Dropped Call Rate (DCR) Call Setup Success Rate CSSR or

Call Setup Failure (CSF) SDCCH Blocking (system) and SDCCH call Blocking TCH Blocking (system) and TCH Call Blocking SDCCH Success Rate

Overall Call Success Rate (OCSR) or Overall Call Failure (OCF)

(96)

Critical indicators

• During Call Setup:

1. SDCCH blocking

2. SDCCH failures

3. TCH blocking

• During a Call:

(97)

SDCCH blocking

• Can be taken out from Network Doctor report 182

• Sort list of cells descending by blocking in Busy hour

• Sort descending by blocking in Daily Average – as the problem may not occur in

BH

• Formula : SDCCH access probability

• Target value : 1 % - combined SDCCH configuration

0.5 % - non-combined

(98)

(99)

SDCCH blocking

• SDCCH avalability

• Check alarms (are TRXs & TSLs in Working State? ), check availability report and

RxQuality report to verify whether there is a badly functioning TRX. Fix hardware problem.

• SDCCH capacity

• Check actual SDCCH configuration ( e.g. Combined BCCH/SDCCH, Number of SDCCH channels). If there is insuficient SDCCH capacity and enough TCH capacity, add SDCCH TSL. Other solution e.g. are to add TRX, activate Dynamic SDCCH, activate FACCH Call Setup.

• SDCCH traffic

• Verify traffic distribution (LU, SMS and MOC in %);

• Cell is covering a region greater than planned. Verify TA statistics. May need to change DMAX, or downtilt.

FM

CM

(100)

SDCCH blocking

• SDCCH traffic due to location updates

• Bad location area setting (Check MCC, MNC and LAC parameters)

• Bad Location area geographical configuration. Too small LA definition will cause many LA updates. Border of LA in a busy avenue will cause many LUs in both location areas!

• Low value for CellReselectHysteresis

• Low value of periodicTimerLU

• Verify if downtilt is needed or an increase in SDCCH capacity (air and Abis interfaces).

• SDCCH traffic due to SMS

• Increase SDCCH capacity (air and Abis interfaces).

(101)

SDCCH failure analysis example

• Can be taken out from Network Doctor report 166

• Sorted by SDCCH drop total rate

• Filtered by SDCCH bids (seizures) > 100

OR

• Sorted by SDCCH drop radio rate

• Filtered by SDCCH bids (seizures) > 100

• Formula : SDCCH success ratio, SDCCH Drop ratio

• Target value : SDCCH drop total < 10%

SDCCH drop radio < 3%

(102)

(103)

• Ghost SDCCH

• Double-Access /Multiple reservations due to co-Bsic, co-BCCH. Check and improve frequency plan.

• RACH retransmissions/Multiple reservations due to bad coverage or interference and high numberOfRachRetransmissions. Lower RACH retransmission parameter value. Check and improve frequency plan and/or downtilt.

• RACH retransmissions/Multiple reservations due to mass paging deleted. During festivals/ holidays/ concerts many subscribers are located at the same LAC, paging and rach load increases considerably. Consider LAC optimization, Abis expansion, paging group

optimization, reduce paging repeat & rach retransmission times during busy hour.

• Radio Fails

• Check alarms and RxQuality report to verify whether there is a badly functioning TRX. Fix hardware problem. Check antenna line.

SDCCH failure analysis example

CM

(104)

• Radio Fails (cont.)

• Coverage. Verify TA report and planning tool.

• Interference. Check Frequency Plan. Solution e.g. add sites, downtilt antennas, increase RxLevAccessMin.

• Extended coverage of cells in location area borders. Check LU parameters and/or downtilt

• 100% ABIS Fails

• Failure in BTS software (BCSU reset in BSC).

• 100% AIF Fails

• BTS connected to other BSC or BTS is not declared in MSC.

SDCCH failure analysis example

Change Request! PM

(105)

TCH blocking

• Can be taken out from Network Doctor report 182

• Sort descending by blocking in Busy hour

• Formula : TCH denied for call request ratio, TCH call blocking

(106)

(107)

TCH blocking

• TCH availability

• Check alarms (are TRXs & TSLs in Working State? ), check availability report and RxQuality report to verify whether there is a badly functioning TRX. Make Loop Tests on TRX. Fix

hardware problem.

• TCH capacity

• Bad TCH capacity dimensioning. Check number of TRXs. FM

(108)

TCH blocking

• TCH traffic

• Cell is covering a region greater than planned. Verify TA statistics. Change DMAX, or downtilt.

• High traffic in some cells. Solution .eg.:

Quality degradation

Add Macrocells no

Add Microcells no

Add TRXs with new freq no

Add TRXs without new freq no/yes (IUO, FH) Activate Directed Retry no/yes

Activate Queuing no

Activate HR yes

Activate AMR-HR no

Activate DADL/B no/yes

Activate AMH no/yes

Activate C2 parameter yes Modify hoMarginPBGT yes

PM

(109)

TCH drop

• Can be taken out from Network Doctor report 163

• Sorted by TCH drop total rate

• Filtered by TCH norm seizures > 100

OR

• Sorted by TCH drops absolute number

• Filtered by TCH drop rate > 3 %

• Formula : TCH drop call ratio (w/o re-est.), TCH dropped conv. (after TCH ass)

(110)

(111)

TCH drop

• Radio Fails

• Check alarms and RxQuality report to verify whether there is a badly functioning TRX. Fix hardware problem. Check antenna line.

• Coverage. Verify TA report and planning tool.

• Interference. Check Frequency Plan. Solution e.g. add sites, downtilt antennas, increase RxLevAccessMin.

• Lack of neighbours

• Bad neighbour declaration

• Transcoder Failure

• Due to synchronisation problem. Synchronisation source set in BTS clock. Change to BSC.

• AIF Failure:

• Interface failures: problem with ET cards. Solution: block the circuits connected to this card and then change ET card when available.

FM

(112)

Let’s go deeper in some failure causes . . .

• Rx Quality

• Rx Quality x Rx Level

• Interference

• Timing Advance

(113)

Rx Quality

• Can be taken out from Network Doctor report 196, 197 and 204

• Sorted reports and 197 ascending by UL/DL cumulative quality

• Formula : UL/DL cumulative quality/level ratio

(114)

Rx Quality

DL/UL CUMULATIVE QUALITY < 5 (dlq_2/ ulq_2) Network Doctor report 196 model

(115)

Rx Quality

DL/UL CUMULATIVE QUALITY < 5 (dlq_2a/ ulq_2a) Network Doctor report 197 model

(116)

Rx Quality x Rx Level

DL/UL QUALITY/LEVEL DISTRIBUTION Network Doctor report 204 model

(117)

Rx Quality x Rx Level

Coverage Problem:

Bad quality and Low Rx Level

Interference Problem:

Bad quality and High Rx Level

Good Quality

High Rv Level

HW Problem:

Bad Quality for all Rx Levels

(118)

Rx Quality

• Coverage Problem

• Bad Quality is due to weak signal. Check TA statistics. Add sites.

• Interference Problem

• Internal interference. Check if interference profile follows increases in traffic profile. Check frequency plan and TA statistics. Modify frequency to verify if problem is solved.

• External interference. Check if interference is independent of traffic profile.

• Due to synchronisation problem. Synchronisation source set in BTS clock. Change to BSC.

• HW Problem

• Bad quality in all RxLevel classes of ONE TRX. Check alarms to verify whether there is a badly functioning TRX. Fix hardware problem. Check antenna line.

• Swap frequency. If problem persists on the same TRX, fix HW problem.

• Bad quality in all RxLevel classes of TWO TRX. Verify combiner or common parts connected to both TRX.

(119)

Interference

Interference Profile 0 10 20 30 40 50 60 1 3 5 7 9 ₁1 1 3 1 5 1 7 1 9 2 1 2 3 Day Time S a m p le s o u t o f B a n d 2

In terference Pro file

0 2 4 6 8 1 3 5 7 9 1 1 1 3 1 5 1 7 1 9 2 1 2 3 D ay T ime S a m p le s o u t o f B a n d 2 Internal Interference External Interference NWD report 196 model

(120)

Timing Advance

Low share close:

BTS might be so high that area bellow it does not receive any signal They might be another dominant site

High share far:

May be causing

Interference and drop call rate as traffic is captured in certain regions far from the BTS.

High share close:

Most calls are established near the BTS BTS may have indoor coverage NWD report 232 model Decreasing share: Traffic is distributed mostly in regions with higher signal level

Don’t forget:

1. Traffic distribution depends on clutter types and planned coverage!

2. Repeters can change expected distribution.

(121)

• High share of traffic far from the BTS

• Internal Interference Problem:

High drop call rate in a certain area. Rx Quality statistics indicates an internal

interference problem. With planning tool evaluate sites with the same frequency -interfering candidates. TA statistics will show traffic distance of -interfering cells. Downtilt is needed.

• No neighbours in area:

High drop call rate. As this cell is covering na unexpected region, there will be no close neighbours declared and HO will not happen. Downtilt is needed.

(122)

Link Balance

• If high Drop Call rates are observed, check Link Balance Statistics.

• DL > UL: It will be necessary to add a MHA in BTS in order to increase BTS

sensitivity and balance the situation. Another solution can be to decrease cell size and reduce BTS power.

• UL > DL: In this case a Booster can be used to increase DL coverage or to improve indoor levels.

(123)