call performance

1 © NOKIA Call Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential

Call Performance

WRST 4

Jussi Reunanen

&

Benoist Guillard

&

Supranee Sarinkarnpoonperm

WRST 4 Düsseldorf

WRST 4Module Three


Contents

• Call Setup Performance• Idle Mode Performance• Paging• RRC Connection Establishment Performance• RAB Establishment Performance• Call Setup Failure & Time• UL Interference

• Dropped Call Performance• SHO Performance (round-the-corner)• DL Power Allocation Parameters• UL Power Allocation Parameters

• PS Call Performance


Call Setup Performance-Idle Mode Cell Reselection-

• Several UEs cannot perform cell reselection during RRC Connection Setup phase (Kenny can sw >12.8x)

Cell A Cell B

UE moving from Cell A towards Cell B

CPICH Ec/NoCPICH RSCP


-15dB

UE Sends First RRC

Connection Request Message

RF Conditions OK and CPICH

Ec/No is –10dB

UE Sends First RRC

Connection Request Message

RF Conditions OK and CPICH

Ec/No is –10dB

RNC responds with RRC Connection Setup message

which is not heard by the UE due to CPICH Ec/No falls

below –15dB

RNC responds with RRC Connection Setup message

which is not heard by the UE due to CPICH Ec/No falls

below –15dB

The UE sends all the rest of the RRC Connection Request –messages to the old cell, Cell A without changing the serving

cell to Cell B (Kenny can perform this reselection and send next RRC Connection Request –message to Cell B) and the call setup

fails

The UE sends all the rest of the RRC Connection Request –messages to the old cell, Cell A without changing the serving

cell to Cell B (Kenny can perform this reselection and send next RRC Connection Request –message to Cell B) and the call setup

fails

-100dB

Time

UE does not start the cell reselection procedure if

default parameter

settings are used

UE does not start the cell reselection procedure if

default parameter

settings are used

-10dB



• Default parameter settings• Cell reselection triggering time (Treselection = 0s)

• Reselection takes place immediately when the UE notices that there is difference between the cells’ Ec/No values (in worst case scenario there can be up to 3dB + Qhyst difference based on the measurement accuracy requirement)

• Cell reselection hysteresis 2 (Qhyst2 = 4dB)• This will add 4dB hysteresis to the neighboring cell evaluation

(target for the cell reselection)• Note that Qhyst1 is used only in case the cell selection and re-

selection quality measure is set to CPICH RSCP (default is CPICH Ec/No so Qhyst 1 is not used in intra-FDD reselection)

• Cell Re-selection Quality Offset 2 (AdjsQoffset2 = 0dB)• This parameter is used in the cell re-selection and ranking

between WCDMA cells. The value of this parameter is subtracted from the measured CPICH Ec/No of the neighbor cell before the UE compares the quality measure with the cell re-selection/ ranking criteria

• S intrasearch (Sintrasearch = 4dB)• This parameter is used by the UE to calculate the threshold

(CPICH Ec/No) to start intra frequency (SHO) measurements (Sintrasearch above QqualMin value)

• Minimum required quality level in the cell (QqualMin = -20dB)


UE starts the neighboring cell

measurements here and it takes some time

to perform the reselection


measurements here and it takes some time

to perform the reselection


• Default parameter settings

Cell A Cell B



QqualMin = -20dB

UE “hangs” in CELL A until

QqualMin+Sintrasearch = -16dB threshold is

reached.However at this level the RRC Connection Setup is

probably not heard by the UE any more or the BTS does not hear the RRC Connection Request

UE “hangs” in CELL A until

QqualMin+Sintrasearch = -16dB threshold is

reached.However at this level the RRC Connection Setup is

probably not heard by the UE any more or the BTS does not hear the RRC Connection Request

Time

QqualMin+Sintrasearch=-20dB + 4dB = -16dB

Qhyst2= -16dB + 4dB = -12dB

Cell Reselection

• The time when the source cell CPICH Ec/No is too low as well as the gap between new and old cell is too large i.e. the UEs that cannot make (all except Kenny) make cell reselection during RRC Connection Setup phase will have failed call attempts



• With default parameter settings:• There is big chance that the UEs with limited capability to

perform proper cell reselection will have failed call attempts seen as consecutive RRC Connection Request messages sent by the UE (seen from the UE log) but no response from RNC or RRC Connection Setup received but then no actions after RRC Connection Setup Complete message (i.e. RRC Connection Setup Complete message is not heard by the BTS)


TimeQqualMin = -20dB


QqualMin+Sintrasearch+Qhyst2= -16dB + 4dB = -12dBCalls setups failures

Calls setups difficult

Calls setups ok

Calls setups very successful

Recommended area



• In order to optimise the call setup performance following changes are suggested (to be in the recommended area all the time)

• S intrasearch (Sintrasearch = 12dB)• The UE starts measuring the neighboring intra frequency

cells when the serving cell CPICH Ec/No reaches –20dB + 12 dB = -8dB

• This setting should leave enough time for the UE to perform reselection as well as enough room (~7dB depending on the UE sensitivity) for the RRC Connection Setup to be successful

• Note: remember to tick on the tick box in front of the Sintrasearch parameter (in PlanEditor: “SIB3compmask2”) otherwise the system does not send this parameter and according to spec the UE measures intra frequency cells all the time -> battery consumption is high



• New set Case 2: Sintrasearch = 12 dB, Treselection = 0 sec and Qhyst2 =4 dB

Cell A Cell B



QqualMin = -20dB

Time


Qhyst2 = -8dB + 4dB = -4dB

• 2 second hysteresis give UE especially at LA, RA border to be more stable than ping pong cell reselection. This also reduces signaling and call failure at LA/RA border due to LA/RA update

• Qqualmin shall not be changed as it will greatly affect cell coverage especailly when traffic is higher because CPICH Ec/No will lower and creating a coverage hole

More time to select and monitor a better

cell

More time to select and monitor a better

cell

Cell reselection happens here where cell B is about –8 dB

and Cell A is about –12 dB

Cell reselection happens here where cell B is about –8 dB

and Cell A is about –12 dB

Worst case scenario


measurements near earlier than at cell

edge


measurements near earlier than at cell

edge



• With optimised parameter settings:


Time

QqualMin = -20dB


Calls setups failures

Calls setups difficult

Calls setups ok

Calls setups very successful

Recommended area

Qhyst2 = 4dB

• It should be noted that the so called optimized settings for cell reselection are causing the UE to start the intra freq. neighbor measurements earlier than the defaults and therefore UE battery consumption is compromised

• It is therefore recommended to find optimized value specific for each environment separately and not to take the values presented here as some defaults


Call Setup Performance-Idle Mode Cell Reselection : Effect-

• There is significant improvement in performance after due to changing of the idle mode cell reselection parameters

• Call Setup Success rate (MTC and MOC especially MTC)

• MTC improvement is due to the fact that in case there are problems in RRC Connection Setup the paging timer in MSC could be expired and therefore causing failed call attempts

AMR performance

BL

ER

, C

all

dro

p r

ate,

MO

C C

SS

R,

MT

C C

SS

R

BLER rate Call drop rate

MOC setup failure rate MTC setup failure rate

Time in Days

Sintrasearch = 10dBTreselection = 0s

Idle mode param. set as defaults

New CD


-18

-16

-14

-12

-10

-8

-6

-4

-2

CP

ICH

Ec/

No

[d

B]


• From the charts on the left it can be seen that from all the RRC Connection Request messages only a few are done in the worse than CPICH Ec/No = -15dB situation

• CPICH Ec/No = -15dB can be considered as some sort of UE performance limit

• In this case the Sintraseacrh setting seems to be ok (10dB)

-24

-22

-20

-18

-16

-14

-12

-10

-8

-6

-4

-2

CP

ICH

Ec/

No

[d

B]

-24

-22

-20

-18

-16

-14

-12

-10

-8

-6

-4

-2

CP

ICH

Ec/

No

[d

B]

Call Setup Failures

All Call Attempts Test 1

All Call Attempts Test 2



Parameter Default Case4 Case5Sintrasearch 12dB 12dB 12dB

Qhyst2 4dB 4dB 0dBTreselect 0sec 2sec 0sec

• Nokia tested Common CH power sets and cell reselection parameter set in site-basis to choose candidate parameter set, which is applied to one area.

• The parameter set for Cell reselection test:

• Tests were done with Sanyo UE (3.23)



Idle mode (Stationary test)Low Coverage Med. CoverageCPICH RSCP CPICH Ec/No CPICH RSCP CPICH Ec/No

Default -81.2 -9.04 -75.06 -5.16Case4 -78.83 -7.51 -76.42 -6.5Case5 -77.47 -7.39 -74.21 -4.03

Idle mode (Drive test)Parameter set CPICH RSCP CPICH Ec/NoDefault -75.41 -5.45Case4 -76.11 -5.89Case5 -75.98 -6.03

AMR MOC (Stationary test)Low Coverage Med. Coverage

# of call attempts Setup success CPICH RSCP CPICH Ec/No # of call attempts Setup successDefault 100 82 -91.63 -6.74 100 93Case4 100 83 -92.18 -6.18 100 97Case5 100 92 -91.45 -6.16 100 89

AMR MOC (Drive test)Parameter set # of call attempts Setup success

Default 78 76 (97%)Case4 100 92%Case5 100 94%

Parameter set

Parameter set

Idle mode (Stationary test)Low Coverage Med. CoverageCPICH RSCP CPICH Ec/No CPICH RSCP CPICH Ec/No

Default -81.2 -9.04 -75.06 -5.16Case4 -78.83 -7.51 -76.42 -6.5Case5 -77.47 -7.39 -74.21 -4.03

Idle mode (Drive test)Parameter set CPICH RSCP CPICH Ec/NoDefault -75.41 -5.45Case4 -76.11 -5.89Case5 -75.98 -6.03

AMR MOC (Stationary test)Low Coverage Med. Coverage

# of call attempts Setup success CPICH RSCP CPICH Ec/No # of call attempts Setup successDefault 100 82 -91.63 -6.74 100 93Case4 100 83 -92.18 -6.18 100 97Case5 100 92 -91.45 -6.16 100 89

AMR MOC (Drive test)Parameter set # of call attempts Setup success

Default 78 76 (97%)Case4 100 92%Case5 100 94%

Parameter set

Parameter set



• Call Setup Success Statistics (drive test in one area)• Call setup success rate has improved after parameter change

by 5~7%.• It seems that UE could find better serving cell after parameter

changeAMR MOC Parameter set # of call attempts Setup success Setup success rate

Default 572 473 82.7%CR Case5 854 765 89.6%

AMR MTCParameter set # of call attempts Setup success Setup success rate

Default 484 412 85.1%CR Case5 333 286 85.9%

UDI MOC Parameter set # of call attempts Setup success Setup success rate

Default 320 262 81.9%CR Case5 647 557 86.1%

AMR MOC Parameter set # of call attempts Setup success Setup success rate

Default 572 473 82.7%CR Case5 854 765 89.6%


Default 484 412 85.1%CR Case5 333 286 85.9%


Default 320 262 81.9%CR Case5 647 557 86.1%

Call Setup Success Rate

0.0%5.0%

10.0%15.0%20.0%25.0%30.0%35.0%40.0%45.0%50.0%55.0%60.0%65.0%70.0%75.0%80.0%85.0%90.0%95.0%

100.0%

Services

Su

cces

s ra

te

Default

Case5


Call Setup Performance-Idle Mode Cell Reselection : Questions-

• Why it is not very good idea to tune Qqualmin –parameter too much and what would be appropriate value?

• What is the difference between Qhyst2 and Qhyst1?

• What is the accuracy requirement of UE CPICH Ec/No and CPICH RSCP measurements?


Contents





Call Setup Performance-Paging : PIs-

• Some UEs do not support all DRX Cycle Length Coefficients, resulting in lost paging

• For instance, NEC VTX does not support DRX Cycle Length <1280ms

• If DRX Cycle Length=640ms, every second paging message is lost

• The MTC can still work thanks to CN Paging repetition (depends on MSC/operator settings)

• This phenomenon can be observed with MSC counters and KPIs• Nokia MSC:

• Clear Code 0012 (No Paging Response)• ! Clear Code 0012 is in the ‘Normal Clearing’ Clear Code

Group ! (other groups are ‘Internal’, ‘External’ and ‘Subscriber’)

• Paging Channel (PCH) is transmitted in the SCCPCH together with FACH and power tuning of SCCPCH can help the performance of paging (see chapter -RRC Connection Establishment: Power Offset for SCCPCH Pilot & TFCI bits-)



UE BS RNC

UE has no RRC connection

RRC connection establishment

PICH(FP/AAL2/PCCH/PCH/S-CCPCH) : PAGING TYPE 1

CN

RANAP: PAGING

Paging response

CN (RANAP: PAGING Message received from CN = UE in idle mode) originated paging amount: When RNC sends Paging Type 1 M1006C25 PAGING TYPE 1 ATT CN ORIG

• Paging for UEs in IDLE state

A number of RNC originated paging type 1 attempts (UE in PCH/URA substate): When RNC sends Paging Type 1M1006C26 PAGING TYPE 1 ATT RNC ORIG

UE RNC

2. Paging Request (P-TMSI)

MM Cell Update

RRC: PAGING TYPE 1 with PICH BTS -> UE

SGSN

1.PDP PDU

The MAC-d (RLC) in RNC indicates that there is downlink user data in RLC buffers then the RRC signaling entity initiates the paging procedure

The MAC-d (RLC) in RNC indicates that there is downlink user data in RLC buffers then the RRC signaling entity initiates the paging procedure

MM IdleUE BS RNC CN 1

RANAP:PAGING

UE has signalling connection to CN1

UE is in URA_PCH or CELL_PCH state

CN 2MM Connected

(FP/AAL2/PCCH/PCH/S-CCPCH) : PAGING TYPE 1

PICH

Paging response to CN 2

• Paging for UEs in CELL_PCH or URA_PCH states

A number of paging messages received from the CNM1003C36 REC PAG MSG

11

22 33



• Paging for UEs in CELL_FACH or CELL_DCH statesUE BS RNC

RRC:PAGING TYPE 2

CN 1

RANAP:PAGING

UE has signalling connection to CN1

UE is in CELL_FACH or CELL_DCH state

Paging response to CN 2

CN 2

CN (RANAP: PAGING Message received from CN = UE in CELL_FACH or CELL_DCH states) originated paging amount: When RNC sends Paging Type 2 M1006C27 PAGING TYPE 2 ATT

A number of paging messages received from the CNM1003C36 REC PAG MSG

44MM Connected MM Idle



Paging Success Rate

• The counters M1001C32, M1001C34, M1001C36 and M1001C38 are updated according to the IE: Establishment cause in RRC Connection Request message – therefore this PI might not be very accurate

• This formula’s denominator M1003C36 REC PAG MSG does NOT include the case where the paging originates from RNC (case 3) -> therefore the formula might give too optimistic results as the M1006C37 CELL UPDATE ATT DUE TO PAGING RESP counter includes also case 3

Messages Paging Received 1003C36

Resp Paing toDueAtt UpdateCell 1006C37Att Backg MTC 1001C38AttInter MTC 1001C36Att Stream MTC 1001C34Att Conv MTC1001C32


Call Setup Performance-Paging : Questions-

• What is the paging procedure for the UE ?• Is in CELL_PCH state and has made GPRS Attach and PDP

Context is active • There are some PDUs are sent to that UE from the SGSN

• What is the response to the paging message?

• What is DRX and how does it relate to paging?


Contents





Call Setup Performance-RRC Connection Establishment-

• The power level for sending of the RRC Connection Request –message is set/calculated by the UE

• Uplink open loop PC take place at the random access procedure:

• UE measures the received power of the CPICH which reported back in "measured results on RACH" IE in: initial direct transfer (UTRAN must extract this IE from the NAS message), cell update / ura update, measurement report (UL traffic volume measurement report), RRC connection request, uplink direct transfer (UTRAN must extract this IE from the NAS message)

[RACH] RRC:RRC Connection Request

NBAP: RL Setup Request

NBAP: RL Setup Response

ALCAP:ERQ

ALCAP:ECF

[FACH] RRC: RRC Connection Setup

UEUE Node BNode B RNCRNC

• Transmission power of CPICH (SIB5&6), total received uplink power at BS (SIB7) and a parameter value PRACHRequiredReceivedCI are sent from BS in system information broadcast messages (SIB5&6)

• Based on this information UE calculates the transmission power of the first pre-amble of PRACH ptx

• ptx = CPICHtransmissionPower-RSCP(CPICH)+RSSI(BS)+"constant value“

where the "constant value" is the value of the RNC parameter PRACHRequiredReceivedCI

[DCH] RRC: RRC Connection Setup Complete

NBAP: Synchronisation Indication

L1 Synchronisation



• If no acquisition indicator is received UE raises the transmission power by PowerRampStepPRACHpreamble which is a broadcast parameter

• This procedure is repeated until acquisition indicator is received, after which UE sends the RACH message at power which offset by PowerOffsetLastPreamblePRACHmessage from the last preamble




ALCAP:ERQ

ALCAP:ECF



DownlinkBS

P1

L1 ACK / AICH

UplinkMS Preamble

1

Not detected

Message partPreamble2

P2

• PRACH_preamble_retrans parameter determines how many times PRACH preamble can be sent (without AICH response) within one preamble ramping cycle (SIB5&6)

• RACH_tx_Max defines how many times the PRACH pre-amble ramping cycle procedure can be repeated before UE MAC reports a failure on RACH transmission to higher layers (SIB 5&6)



• Some of the UEs (other than Kenny) are not capable of performing Open Loop PC correctly i.e. they have problems in RRC Connection Establishment

• The UE cannot detect the SIB7 UL interference level correctly

• This can be seen from the UE logs as consecutive failed RRC Connection Requests => This could be seen in calls without any RRC connection request by analyzing sent PRACH preambles

• The situation can be corrected by increasing the parameter value PRACH_preamble_retrans or RACH_tx_Max

• Increasing the parameter values should be made with extra care as increasing the maximum UE TX power on RACH increases the UL load is as well

• In case of problematic site which does not answer to PRACH at all due to BTS problems; increasing the power on RACH increases the UL interference on the surrounding sites


Call Setup Performance-RRC Connection Establishment – Logging CPICH Ec/No-

• For Filtering purposes it is good to have Ec/No recorded when the RRC Connection Setup is sent

• Whether the reading is done from the Finger data or from the RRC Connection Setup –message needs to decided

-18

-16

-14

-12

-10

-8

-6

-4

-2

0

-20 -18 -16 -14 -12 -10 -8 -6 -4 -2 0

CPICH Ec/No as in RRC Connection Setup Request

CP

ICH

Ec/

No

as

rep

ort

ed b

y fi

ng

ers

• As it can be seen from the picture, the difference between RRC Connection Setup –message reported CPICH Ec/No and finger data CPICH Ec/No increases when the level of CPICH Ec/No is decreasing

• Recommendation is to use the finger data as it is updated basically on at least every 200ms intervals (specified by the 3GPP spec 25.302)

Results missing


Call Setup Performance-RRC Connection Establishment –CPICH Ec/No / RSCP vs. UE

Tx Power-• For failed calls the UE Tx vs. CPICH

Ec/No and CPICH RSCP should be investigated in order to see possible DL coverage or open loop PC problems

•In case CPICH RSCP is low but UE Tx Power is low

•There is possibility that UE open loop PC is not working correctly•Or the CPICH Tx power is pretty low and there is DL coverage problem•Or the SCCPCH power offset to CPICH power is set wrongly – too big offset

•In case CPICH Ec/No is low but the UE Tx power is low then there could be some problem in DL quality - provided that the CPICH RSCP is ok

•Some high DL loading in the cell•Pilot pollution on that area

-120

-110

-100

-90

-80

-70

-60

-50

-40

-40 -35 -30 -25 -20 -15 -10 -5 0 5 10 15 20 25

UE Tx Power [dBm]

RS

CP

[d

Bm

]

-40

-30

-20

-10

0

10

20

30

-30 -25 -20 -15 -10 -5 0

CPICH Ec/No [dBm]

UE

Tx

Po

we

r [d

Bm

]

[dB]



Tx Power-• From CPICH Ec/No vs. CPICH RSCP it

can be seen that only a few call failures are having relatively good CPICH RSCP but still pretty poor CPICH Ec/No:

•indicating possibility of Pilot Pollution•Indicating possibility of relatively high DL load

• Those cells in case they constantly do have this kind of phenomena should be investigated more

-120

-110

-100

-90

-80

-70

-60

-50

-40

-30 -25 -20 -15 -10 -5 0CPICH Ec/No [dB]

CP

ICH

RS

CP

[d

Bm

]• For possible pilot pollution investigation the

amount of SCs and their strength can be plotted from the drive test data and possible the cells causing the pilot pollution can be identified and dominance optimisation can be done

Plot of RSCP and Ec/No vs Data No. in problem Area

-140

-120

-100

-80

-60

-40

-20

0

Data No.

RS

CP

and

RS

SI (

dBm

)

-50

-45

-40

-35

-30

-25

-20

-15

-10

-5

0

ANT1_RSSI SC97 RSCP SC106 RSCP SC103 RSCP SC69 RSCPSC174 RSCP SC180 RSCP SC97 Ec/No SC106 Ec/No SC103 Ec/NoSC69 Ec/No SC174 Ec/No SC180 Ec/No

Ec/

No

(dB

)

Pilot pollution area/poordominance area



Tx Power-• By investigating the Call Setup

Success Probability distribution among all the call setup related messages it can be seen:

•RRC Connection Setup Complete plays a significant role as a starting point of what can be achieved in terms of CSSR

• Therefore it is utmost important to understand how the RRC Connection Establishment procedure works

This kind of Call Setup Performance analysis can also help for the whole call set-up troubleshooting and possible trouble spot finding and tuning






ALCAP:ERQ

ALCAP:ECF



UE does not hear RRC Connection Setup from RNCUE does not hear RRC Connection Setup from RNC




ALCAP:ERQ

ALCAP:ECF






ALCAP:ERQ

ALCAP:ECF


There is no retransmission of RRC Connection Setup -message.This is why the UE just sends another RRC Connection Request – message.

The more RRC Connection Request retransmission the more (in case RNC hears the message) RLs are setup and more Iub Capacity used.The RNC internal timer (T_RRC_Resp_CCH) will release the unused RLs on Iub after 6seconds (from the establishment)


Before 1.5.2 CD15



• Current default values of the parameters are: T300=3000ms and N300=3

• UE will send the RRC Connection Request message four times in the interval of three seconds if there is no RRC Connection Setup message received from the RNC

• The RRC Connection Setup message is sent only once (UM RLC SAP is used for this RRC procedure)

• RRC Connection Setup is quite a long message that must be sent in several successive transmission blocks (TB) via the FACH transport channel

• Only one erroneous TB is sufficient to cause the MS to reject the whole Setup message




ALCAP:ERQ

ALCAP:ECF



RRC Connection Setup –message is transmitted in several

successive transport blocks



• Additionally there is a possibility for loss of the RRC Connection Request message since this message is using TM RLC SAP

• But since this message can be fit into only one RACH message, the probability of loss can be considered much smaller than in DL direction


T300

Before 1.5.2 CD15



Repetition procedures defined in RAN1.5 for RRC messages using the UM-RLC SAP

Repetition counters presented in the following table are defined for unacknowledged mode RRC messages in RAN1.5. Repetition Counter Default Usage

L3Rep_UnAckRLC 2 times Repeat counter for RRC messages when using UM RLC. Used for the following DL RRC messages: 1. DCH to FACH state transition command (interval 400ms) 2. Cell Update Confirm (interval 300ms) 3. URA Update Confirm (interval 300ms)

L3Rep_RRC_Conn_Rel 2 times (interval 300ms)

Repeat counter for RRC Connection Release message sent on: DCCH mapped to DCH and DCCH/CCCH mapped to FACH.

Note. Repetitions shall not be used when the message is sent over Iur (possible repetitions must be executed by the DRNC).

Before 1.5.2 CD15



• Based on the experiments made in the network with a sufficiently low load one can get improvement in call setup delay when reducing the value of T300

• By reducing the value of T300• the UE will repeat the request sooner

and the delay in RRC connection establishment caused by lost Request/Setup messages can be minimized

• However This is wrong way to correct the "problem“




ALCAP:ERQ

ALCAP:ECF








• When load of the network increases, too short repetition interval of RRC Connection Request message will contaminate the normal operation of the pre-emption procedure in RAN and generate even more load to already congested cells

• Each RRC Connection Request message might trigger a packet call release = pre-emption in order to release capacity for in AAL2 or in BTS or in radio interface

Before 1.5.2 CD15



• If the repeated RRC Connection Request messages are received before the RNC has been able to complete the ongoing RRC Connection Setup procedures (i.e. release the established RLs for the unsuccessful RRC Connection Setup attempts) this will cause new RRC connection establishment procedures to be triggered (requiring maybe more calls to be pre-empted in vain)

• Initiation of the pre-emption procedure may need Radio Link Setup Request to be rejected by the BTS or AAL2-setup failure to happen

• Then the DCH-allocation of packet data call (to be pre-empted) must be released (state transition CELL_DCH -> CELL FACH is triggered)




ALCAP:ERQ

ALCAP:ECF






ALCAP:ERQ

ALCAP:ECF



Before 1.5.2 CD15



• State transition from Cell_DCH to Cell_FACH is in the optimum case fast

• In case there is a cell reselection procedure executed before the MS acknowledges the state transition command, then the RL(s) cannot be released until the Cell Update is received via the RACH transport channel or Radio Link Failure indication(s) is/are received from the BTS(s)

• There may also be radio link(s) over Iur due to inter-RNC SHO




ALCAP:ERQ

ALCAP:ECF






ALCAP:ERQ

ALCAP:ECF



• Additional RRC Connection Requests will cause additional resource reservations and due to that might cause some pre-emption procedures to be triggered

• More complex situation is more time pre-emption procedure takes -> more new RRC Connection Requests are sent by the UE -> more pre-emption

Before 1.5.2 CD15



• Resources reserved for these unnecessary "double reservation" cannot be released immediately; radio links must be kept allocated for a certain time

• If there is no RRC Connection Setup Complete message received from the UE, the RL is released after Layer3 time supervision for the MS acknowledge has expired




ALCAP:ERQ

ALCAP:ECF






ALCAP:ERQ

ALCAP:ECF



Before 1.5.2 CD15



• Additionally mobility i.e. cell reselections of the UE during the RRC connection establishment procedure will cause certain amount of these "double resource reservations“

• These mobiles repeat the RRC Connection Request via the new cell if the cell reselection occurs before the MS has succeeded to receive the RRC Connection Setup message via the previous serving cell

Cell A Cell B



-15dB

First RRC Connection

Request sent by the UE –

RNC Answers with RRC

Connection Setup – UE

does not hear it

First RRC Connection

Request sent by the UE –

RNC Answers with RRC

Connection Setup – UE

does not hear it

UE sends new RRC Connection Request to Cell B which is successful and call is

setup successfully

UE sends new RRC Connection Request to Cell B which is successful and call is

setup successfully

-100dB

Time

-10dB

UE waits T300 seconds until it sends next RRC Connection Request. During the T300 time the UE

makes cell reselection to Cell B

UE waits T300 seconds until it sends next RRC Connection Request. During the T300 time the UE

makes cell reselection to Cell B

Before 1.5.2 CD15



• Resource allocations (time between RRC Connection Request and RRC Connection Setup) within "fragment of a second" can be assumed only for networks operating in low load and in good radio conditions (no RRC messages lost on RACH/FACH)

• RRC connection establishment procedure requiring a pre-emption in the congested cell may take several seconds to be completed

• Too short repetition interval for RRC Connection Request message will cause double resource reservations and unnecessary pre-emption of the ongoing calls (in our current implementation)

Before 1.5.2 CD15



• There is possibility for collecting "success-rate" statistics only RRC Connection Setup/Complete phase, so there is no "RNC level" statistical distribution available for actual cause for RRC connection establishment delay (amount of lost RRC Connection Requests is not known)

• Values less than 3000ms cannot be recommended for T300, and thus there is no possibility to speed up the RRC connection establishment in the cases where the RRC Connection Request message is lost

• Cell reselections during the RRC connection setup phase will cause "double resource reservations” where a new RRC connection establishment is started in the new cell. Ongoing RRC connection establishment in the old cell cannot be interrupted and the reserved resources cannot be released until the Layer3 time supervision (default=6 seconds) expires

Before 1.5.2 CD15



UE sends RRC Connection Request -message


Timer T300 is started




ALCAP:ERQ

ALCAP:ECF


NBAP:RL Setup Request


• The UL synchronization is based on the 1024 chips timing offset between the uplink and downlink DPCHs, the channelization code and the scrambling code of the uplink DPCH specified in the radio link setup parameters

• When the UE has established the frame synchronization to the downlink DPCH, it starts the transmission of the uplink DPCH

• The DPDCH is transmitted only when there are Transport Blocks received from the UE L2



L1 Synchronisation

2

1

3

BTS Starts sending DPCCH: Pilot and TPC &

Starts UL synchronization

procedure



procedure

Start TX/RXStart TX/RX


UE start sending DPCCH for UL sync purposes (pilot) after DL frame sync is established


RNC sends RRC Connection Setup -message


RNC starts timer T_RRC_Resp_CCH

RNC starts timer T_RRC_Resp_CCH



BTS sends: NBAP RADIO LINK

SETUP RESPONSE -message



SS

Before 1.5.2 CD15



• Before the synchronization of an uplink DPCH is established, the radio link is in initial synchronization state

• The synchronization state of a radio link is determined based on the physical channel BER of the DPCCH

• The physical channel BER is the relation of the incorrectly detected pilot bits to the total number of pilot bits in a radio frame

• L1 estimates the synchronization status (In-sync or Out-of-sync) of each radio frame

• The criteria for estimating the synchronisation status are defined in two different phases

E



• The first phase • starts when the searching of the synchronization is started and

lasts 160 ms after the first frame with In-synch status has been found

• During this time the Out-of-sync status shall not exist• During the first phase the radio frame has the In-sync status if the

following criterion is fulfilled:• The physical channel BER of the DPCCH over the previous 40

ms period has been better than a threshold Qin (def. 20% BER)• This criterion shall be assumed not to be fulfilled before 40 ms

of DPCCH BER measurements have been collected

– Qin (A radio frame has an In-sync status, if, in addition to other criteria, the physical channel BER of a DPCCH over the last 160 ms has been better than the threshold Q_IN. The mapping of the Q_IN values to the actual physical channel BER is given in 3GPP TS 25.133

E

Reported value Measured quantity valuePhCh_BER_LOG_000 Physical channel BER = 0PhCh_BER_LOG_001 - < Log10(Physical channel BER) < -2.06375 PhCh_BER_LOG_002 -2.06375 Log10(Physical channel BER) < -2.055625 PhCh_BER_LOG_003 -2.055625 Log10(Physical channel BER) < -2.0475

PhCh_BER_LOG_253 -0.024375 Log10(Physical channel BER) < -0.01625 PhCh_BER_LOG_254 -0.01625 Log10(Physical channel BER) < -0.008125 PhCh_BER_LOG_255 -0.008125 Log10(Physical channel BER) 0



• The second phase • starts 160 ms after the first frame with In-sync status has been found• During this phase the criteria for the Out-of-sync and In-sync status are

as follows• A radio frame has an Out-of-sync status if the following criterion is

fulfilled– The physical channel BER of the DPCCH over the previous 160

ms period has been worse than the threshold Qout (def. 15% BER)

– Qout A radio frame has an Out-of-sync status, if the physical channel BER of a DPCCH over the last 160 ms has been worse than the threshold Q_OUT. The mapping of the Q_OUT values to the actual physical channel BER is given in 3GPP TS 25.133.

• A radio frame has an In-sync status if the following criterion is fulfilled– the physical channel BER of the DPCCH over the previous 160

ms period has been better than a threshold Qin

• NOTE: It is possible that a radio frame has neither In-sync status nor Out-of-sync status

• These frames are ignored in determining the sync state of a radio link

E



• When the BTS L1 has detected N_INSYNC_IND consecutive indications with In-sync status, the radio link is moved from the initial state to an In-sync state

• L1 informs BTS L3 about the established synchronization and BTS L3 sends the NBAP:SYNCHRONIZATION INDICATION message to the RNC

• The parameters Qin and Qout and N_INSYNC_IND are given by the RNC to the BTS in the NBAP: CONFIGURATION DATA message

• The BTS L1 searches the synchronization in the initial state as long as the synchronization has been established or the radio link is released by the RNC with the NBAP:RADIO LINK DELETION message

• After the BTS has established the frame synchronization to the uplink DPCH, the transmission power of the downlink DPCH is controlled based on the TPC bits transmitted by the UE

• Also, the TPC bits transmitted in the downlink dedicated physical channel are based on the SIR measurements from the uplink DPCH

E



• When a physical dedicated channel establishment is initiated by the UE, the UE starts a timer T312 and wait for layer 1 to indicate N312 "in sync" indications

• On receiving N312 "in sync" indications, the physical channel is considered established and the timer T312 is stopped and reset

• On the BTS side after receiving N_INSYNC_IND synchronisation indicators the BTS sends NBAP: SYNCHRONIZATION INDICATION –message to RNC after which the closed loop and outer loop PC start to control the powers

RNC receives RRC Connection Setup Complete –message ->RNC stops timer T_RRC_Resp_CCH

RNC receives RRC Connection Setup Complete –message ->RNC stops timer T_RRC_Resp_CCH

RRC Connection Setup Complete –message SENT



L1 Synchronization established

BTS sends NBAP: SYNCHRONIZATION

IDICATION -message



IDICATION -message


1



ALCAP:ERQ

ALCAP:ECF






UE initiates physical dedicated channel establishment before sending e.g. RRC Connection Setup Complete –message on DPDCH


Timer T312 startedTimer T312 started

“in sync” indicators on L1


Timer T312 stopped

Timer T312 stopped

N312 L1 “in sync” indicators


L1 Synchronizati

on established

L1 Synchronizati

on established

N_INSYNC_IND indicators on

L1


L1

Other cases HHO, FACH=>DCH-state transitions

L1 Synchronisation

Before 1.5.2 CD15



• In case UE is not able to establish synchronization within timer T312 it stops TX on the DCH

• In case BTS is not able to establish synchronization it does not send NBAP:Synchronization Indication –message to RNC

• The BTS tries to establish synchronization until T_RRC_Resp_CCH timer in RNC expires and RNC sends NBAP:Radio Link Deletion -message

L1 Synchronization not established BTS does NOT

send NBAP: SYNCHRONIZATION IDICATION -message



Timer T312 expired => L1 Synchronization not established


Physical channel establishment failed => UE stops TX/RX


RRC Connection establishment procedure failed -> wait until T300 expires and if number of sent RRC Connection Requests < N300


2



ALCAP:ERQ

ALCAP:ECF








Timer T312 started

Timer T312 started



Less thanN312 L1 “in sync” indicators

Less thanN312 L1 “in sync” indicators

Less than N_INSYNC_IND indicators on

L1

Less than N_INSYNC_IND indicators on

L1


L1 Synchronisation

RNC does not receive RRC Connection Setup Complete –message within T_RRC_Resp_CCH timer

RNC does not receive RRC Connection Setup Complete –message within T_RRC_Resp_CCH timer Counter

1001C9 is incremented

Counter 1001C9 is incrementedRNC sends

NBAP:RADIO LINK DELETION –

message

RNC sends NBAP:RADIO LINK

DELETION –message

SS

Before 1.5.2 CD15



L1 Synchronization establishedBTS sends NBAP: SYNCHRONIZATION

IDICATION -message


IDICATION -message




ALCAP:ERQ

ALCAP:ECF






3






Less than N312 L1 “in sync” indicatorsLess than N312 L1 “in sync” indicators


L1


L1

L1 Synchronisation

N_OUTSYNC_IND indicators on

L1


L1

Timer T_RLFAILURE expires


Timer T_RLFAILURE started


Counter 1001C10 is incremented


timer T_RRC_Resp_CCH expired


RNC sends NBAP:RADIO

LINK DELETION –

message


LINK DELETION –

messageRNC receives NBAP:RADIO LINK

FAILURE –message form BTS with a cause value

"Synchronization Failure"

RNC receives NBAP:RADIO LINK



NBAP: Radio Link Failure

Timer T312 expired

Timer T312 expired





SS

• In case BTS is able to establish synchronization it sends NBAP:Synchronization Indication –message to RNC


• As the UE TX is off the BTS looses the L1 synchronization and sends NPAB: Radio Link Failure –message to RNC (and continues to send the message in 5 sec. intervals until RNC sends NBAP: Radio Link Deletion –message back)

• After T_RRC_Resp_CCH expires in RNC the RNC sends NPAB: Radio Link Deletion to BTS which then stops searching for the synchronization

Before 1.5.2 CD15



• In case the BTS does not send NBAP: RL Failure –message to RNC but the RNC does not receive RRC Connection Setup Complete –message from UE within timer T_RRC_Resp_CCH, the RNC initiates RRC Connection Release procedure





RNC sends RRC:RRC CONNECTION RELEASE –message on DCH to UE

RNC sends RRC:RRC CONNECTION RELEASE –message on DCH to UE

No RRC: RRC CONNECTION RELEASE COMPLETE –message from UE within within the message repetition timer (100ms)

No RRC: RRC CONNECTION RELEASE COMPLETE –message from UE within within the message repetition timer (100ms)

the RNC retransmits the message L3Rep_RRC_Conn_Rel times with interval of 100 ms


No RRC: RRC CONNECTION RELEASE COMPLETE message is not received => RRC entity of the UE is deleted at the same time with the radio link deletion procedure

No RRC: RRC CONNECTION RELEASE COMPLETE message is not received => RRC entity of the UE is deleted at the same time with the radio link deletion procedure


DELETION –message


DELETION –message


IDICATION -message


IDICATION -message




ALCAP:ERQ

ALCAP:ECF











Less than N312 L1 “in sync” indicatorsLess than N312 L1 “in sync” indicators

3


L1


L1

L1 Synchronisation

Timer T312 expired

Timer T312 expired





SS

Before 1.5.2 CD15




ALCAP:ERQ

ALCAP:ECF

• The UL synchronization is based on the 1024 chips timing offset between the uplink and downlink DPCHs, the channelization code and the scrambling code of the uplink DPCH specified in the radio link setup parameters

• When the UE has established the frame synchronization to the downlink DPCH, it starts the transmission of the uplink DPCH

• The DPDCH is transmitted only when there are Transport Blocks received from the UE L2

• RRCconnRepTimer1 and RRCconnRepTimer2 are having static values of 400ms and 1400ms respectively



L1 Synchronisation

2

1

3



procedure



procedure







RNC starts timers T_RRC_Resp_CCH, RRCconnRepTimer1 and RRCconnRepTimer2

RNC starts timers T_RRC_Resp_CCH, RRCconnRepTimer1 and RRCconnRepTimer2












SS




RNC receives RRC Connection Request and starts buffering timer N300*T300

RNC receives RRC Connection Request and starts buffering timer N300*T300

After 1.5.2 CD15



• When a physical dedicated channel establishment is initiated by the UE, the UE starts a timer T312 and wait for layer 1 to indicate N312 "in sync" indications

• On receiving N312 "in sync" indications, the physical channel is considered established and the timer T312 is stopped and reset

• On the BTS side after receiving N_INSYNC_IND synchronisation indicators the BTS sends NBAP: SYNCHRONIZATION INDICATION –message to RNC after which the closed loop and outer loop PC start to control the powers

RNC receives RRC Connection Setup Complete –message ->RNC stops timers T_RRC_Resp_CCH, RRCconnRepTimer1 and RRCconnRepTimer2

RNC receives RRC Connection Setup Complete –message ->RNC stops timers T_RRC_Resp_CCH, RRCconnRepTimer1 and RRCconnRepTimer2






IDICATION -message



IDICATION -message


1



ALCAP:ERQ

ALCAP:ECF











Timer T312 stopped

Timer T312 stopped



L1 Synchronizati

on established

L1 Synchronizati

on established


L1


L1


L1 Synchronisation

After 1.5.2 CD15




• In case BTS is not able to establish synchronization it does not send NBAP:Synchronization Indication –message to RNC

• The BTS tries to establish synchronization until T_RRC_Resp_CCH timer in RNC expires and RNC sends NBAP:Radio Link Deletion -message









2



ALCAP:ERQ

ALCAP:ECF








Timer T312 started

Timer T312 started

Less thanN312 L1 “in sync” indicatorsLess thanN312 L1 “in sync” indicators

Less than N_INSYNC_IND indicators on L1



L1 Synchronisation



Counter 1001C9 is incremented -no Synchronisation indication received within supervision time -no rrc connection setup complete reeived within supervision time

Counter 1001C9 is incremented -no Synchronisation indication received within supervision time -no rrc connection setup complete reeived within supervision time


DELETION –message


DELETION –message

RRC Connection Setup Complete not received RRCconnRepTimer1 expires -> RRC Connection Setup is resent to the UE


RRC Connection Setup Complete not received RRCconnRepTimer2 expires -> RRC Connection Setup is resent to the UE and RRCconnRepTimer2 reset RRCconnRepTimer1 stopped


After 1.5.2 CD17


Call Setup Performance-RRC Connection Establishment-[RACH] RRC:RRC Connection Request


ALCAP:ERQ

ALCAP:ECF






L1 Synchronisation

Counter 1001C10 is incremented-Synchronisation indication received within supervision time -no rrc connection setup complete reeived within supervision time

Counter 1001C10 is incremented-Synchronisation indication received within supervision time -no rrc connection setup complete reeived within supervision timetimer

T_RRC_Resp_CCH expired



LINK DELETION –

message


LINK DELETION –

message







NBAP: Radio Link Failure

• In case BTS is able to establish synchronization it sends NBAP:Synchronization Indication –message to RNC


• As the UE TX is off the BTS looses the L1 synchronization and sends NPAB: Radio Link Failure –message to RNC

• After T_RRC_Resp_CCH expires in RNC the RNC sends NPAB: Radio Link Deletion to BTS which then stops searching for the synchronization

3



Timer T312 started

Timer T312 started


N_INSYNC_IND indicators on L1N_INSYNC_IND indicators on L1







L1 Synchronization established BTS sends NBAP: SYNCHRONIZATION

IDICATION -message

L1 Synchronization established BTS sends NBAP: SYNCHRONIZATION

IDICATION -message




L1


L1







After 1.5.2 CD17



• In case the BTS does not send NBAP: RL Failure –message to RNC but the RNC does not receive RRC Connection Setup Complete –message from UE within timer T_RRC_Resp_CCH, the RNC initiates RRC Connection Release procedure



ALCAP:ERQ

ALCAP:ECF






3

L1 Synchronisation



Timer T312 started

Timer T312 started


N_INSYNC_IND indicators on L1N_INSYNC_IND indicators on L1






NBAP: Synchronisation Indication L1 Synchronization established BTS sends

NBAP: SYNCHRONIZATION IDICATION -message

L1 Synchronization established BTS sends

NBAP: SYNCHRONIZATION IDICATION -message



RNC sends RRC:RRC CONNECTION RELEASE –message on DCH to UE, timer T_RRC_Resp_CCH restarted

RNC sends RRC:RRC CONNECTION RELEASE –message on DCH to UE, timer T_RRC_Resp_CCH restarted

No RRC CONNECTION RELEASE COMPLETE –message from UE within within the message repetition timer (100ms)

No RRC CONNECTION RELEASE COMPLETE –message from UE within within the message repetition timer (100ms)



RRC entity of the UE is deleted at the same time with the radio link deletion procedure

RRC entity of the UE is deleted at the same time with the radio link deletion procedure


LINK DELETION –message



After 1.5.2 CD17





• Longer time (T312 high and high N312) (T312 high and high N312) the UE has to establish the L1 synchronization the higher probability successful physical channel establishment is and better call set up success rate

• However longer the time for L1 synch the longer is call setup time

AMR performance

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

14/0

1/03

16/0

1/03

18/0

1/03

20/0

1/03

22/0

1/03

24/0

1/03

25/0

1/03

28/0

1/03

01/0

2/03

05/0

2/03

10/0

2/03

12/0

2/03

15/0

2/03

01/0

3/03

06/0

3/03

07/0

3/03

17/0

3/03MO

C /

MT

C c

all s

etu

p d

elay

5 s

ec P

erce

nti

le

Percentile MOC call setup delay @5 sec

Percentile MTC call setup delay @5 sec

N31N312=42=4

N31N312=12=1

N31N312=22=2

• During the test it was noted that setting N312 to 2 or 4 (between 1 and 2 there is notable difference) does not have any significant effect on the call set up success rate

• But the effect on the call set up time is significant and therefore N312 value of 2 was selected to be used


• Secondary CCPCH support multiple transport format combinations using TFCI. • For slot formats using TFCI, the TFCI value in each radio frame corresponds to a

certain transport format combination of the FACHs and/or PCHs currently in use. This correspondence is (re-)negotiated at each FACH/PCH addition/removal.

• For example (currently used, should be noted that pilot bits are not used according to 3GPP R99 release -> thereofre 0 bits for pilot):

• slot format 8 (SF64) has 0 pilot bits and 8 TFCI bits (for FACH or combined FACH/PCH)

• slot format 0 (SF256) has 0 pilot bits and 0 TFCI bits (for PCH)• Change of offset allowing better detection on SCCPCH which carries FACH/PCH

(MOC/MTC CSSR (call setup success rate) affected)

Slot #0 Slot #1 Slot #i Slot #14

Tslot = 2560 chips, 20*2k bits (k=0..6)

Pilot Npilot bits

Data Ndata1 bits

1 radio frame: Tf = 10 ms

TFCI NTFCI bits

Call Setup Performance-RRC Connection Establishment: Power Offset for SCCPCH Pilot &

TFCI bits -


Failure due to FACH/RACH is lower from

xxx test in AprSame result shown in

MTC & UDI

power offset TFCI = 0 dB for 60 ksps SCCPCH

power offset TFCI = 4 dB for

60 ksps SCCPCH

Call Setup Performance-RRC Connection Establishment: Power Offset for SCCPCH Pilot &

TFCI bits -



• RRC Connection establishment success rate and delay cannot be improved by changing timer T300 or counter N300 to more aggressive

• Way to improve RRC Connection success rate• Improve the UE idle mode behavior by making the intra-

frequency measurements earlier and cell reselection more aggressive (see previous slide on idle mode performance)

• Typically RRC Connection Setup Success rate (= (RRC_CONN_ACC_COMP/ RRC_CONN_STP_ATT) *100) is in the region of 80% - 90%

• Adjust the T312 and N312 values (current defaults N312=4 and T312=10s should be ok but alternatives to try in case of call setup delay is an issue N312=2 or even N312=1)

• Use Nokia defaults for SCCPCH offsets

• RRC Connection Success rate can be low due to:• UE changing cell during RRC Connection Setup phase (cell A ->

cell B) – usually counter 1001C9 is updated in the cell A• RRC Connection Setup –message is not heard by the UE (no

retransmission) -> usually counter 1001C9 is updated in the cell



• It should be noted while making the idle mode performance more aggressive that the when the UE is making measurements it is also using more battery so therefore the UE should not make measurement all the time (can be done by not setting any value for Sintrasearch)

• Also common channel power settings need to be optimised in order to really optimise the idle mode and RRC Connection Setup performance

• Common channel power optimisation is to happen during 2H2003


Call Setup Performance-Common Channel Power Tuning-

• Call Setup Success Statistics• Call setup success rate has improved after parameter change

by 4~5%.


Default 572 473 82.7%Case4 771 678 87.9%


Default 484 412 85.1%Case4 625 556 89.0%


Default 320 262 81.9%Case4 527 451 85.6%


Default 572 473 82.7%Case4 771 678 87.9%


Default 484 412 85.1%Case4 625 556 89.0%


Default 320 262 81.9%Case4 527 451 85.6%

Call Setup Success Rate

0.0%5.0%

10.0%15.0%20.0%25.0%30.0%35.0%40.0%45.0%50.0%55.0%60.0%65.0%70.0%75.0%80.0%85.0%90.0%95.0%

100.0%

Services

Su

cces

s r

ate

DefaultCase4

Channels Default case4CPICH Ptx 27 27

PCCPCH Ptx 24 25PSCH 25 27SSCH 25 27PICH 20 24

SCCPCH 29 27AICH 21 27


Call Setup Performance-Common Channel Power Tuning-

• Classified the call failures according to the phases where call setup has failed

• Step A, B are related to paging, AICH, and RACH/FACH phases. – affected by PICH, AICH, and SCCPCH (PCH and FACH) increase

• In Step A & B, the performance after parameter change has improved

Index of Call Results BreakdownA Call Setup Failure during RRC Connection Setup Phase (2.1)B Call Setup Failure during Access Phase due to RACH/FACH (2.2)C Call Setup Failure due to RRC Connection Reject (2.3)D Call Setup Failure due to NO RRC Connection Setup Complete (2.9)E Call SetUp Failure due to No CM service request (2.8)F Call Setup Failure during Security Procedure (2.5)G Call Setup Failure during RAB Setup procedure(Without Complete) (2.6)H Call Setup Failure during RAB Setup procedure(With Complete) (2.7)I Call Setup SuccessJ Call Setup Failure due to Registration (2.4)

Index of Call Results BreakdownA Call Setup Failure during RRC Connection Setup Phase (2.1)B Call Setup Failure during Access Phase due to RACH/FACH (2.2)C Call Setup Failure due to RRC Connection Reject (2.3)D Call Setup Failure due to NO RRC Connection Setup Complete (2.9)E Call SetUp Failure due to No CM service request (2.8)F Call Setup Failure during Security Procedure (2.5)G Call Setup Failure during RAB Setup procedure(Without Complete) (2.6)H Call Setup Failure during RAB Setup procedure(With Complete) (2.7)I Call Setup SuccessJ Call Setup Failure due to Registration (2.4)

AMR MOC

Category Default Case4 Default (%) Case4 (%)A 8 0 1.40% 0.00%B 19 26 3.32% 3.37%C 0 0 0.00% 0.00%D 36 32 6.29% 4.15%E 7 4 1.22% 0.52%F 11 4 1.92% 0.52%G 5 8 0.87% 1.04%H 13 17 2.27% 2.20%I 473 678 82.69% 87.94%J 0 2 0.00% 0.26%

AMR MTC


UDI MOC



Call Setup Performance-RRC Connection Establishment: Counters-

UE RNC

RRC: Connection RequestCorrectly Received messageRRC Connection Setup StartsTriggers: 1001C0 RRC Connection Attempt

BTS

RRC Connection Setup phaseResource Reservation in RNC, BTS, Transmission

RRC: RRC Connection Request SetupRRC Connection setup completedTriggers: 1001C1 RRC Con Setup Compl

Failure Case:RRC Connection Setup failsDue to Triggers: 1001C2 Handover control1001C3 Admission control1001C4 BTS1001C5 Transmission network1001C6 RNC internal reason1001C7 Frozen BTS

RRC Connection Access phase RNC waits reply from UE

Failure Case:RRC Connection Access failsDue to Triggers: 1001C9 L1 synchronization in BTS1001C10 UU interface1001C11 RNC internal reason

RRC: RRC Connection Completed

RRC: Initial Direct Transfer

CN

RANAP: Initial UE Message

RRC Connection Access completedTriggers: 1001C8 RRC Con Acc Comp

RRC Connection Active phaseUE-CN Signaling

Failure Case:RRC Connection Active failsDue to Triggers: 1001C15 Iu interface 1001C16 Radio interface1001C17 BTS1001C18 Iur interface1001C19 Ciphering failure1001C20 Integrity check1001C21 RNC internal reason

RANAP: Iu Release Command

RRC Connection Active completedTriggers: 1001C12 RRC Con Active Comp

Special Reason: RRC Connection Active Release Due to Triggers: 1001C13 SRNC Relocation 1001C14 Pre-emption


UE RNC

RRC: Connection Request

Correctly Received messageTriggers: 1001C0 RRC Connection Attempt

BTS




RRC: RRC Connection Completed


CN


RRC Connection Access completedTriggers: 1001C8 RRC Con Acc Comp




RRC Connection Setup due to Cause

Triggers: 1001C22 MOC conv call att1001C24 MOC stream call att1001C26 MOC interac call att1001C28 MOC backgr call att1001C30 MOC subscribed call att1001C32 MTC conv call att1001C34 MTC stream call att1001C36 MTC interac call att1001C38 MTC backgr call att1001C40 Emergency call att1001C42 Inter RAT cell reselection1001C44 Inter RAT cell chng ord1001C46 Registration attempt1001C48 Detach attempt1001C50 MOC high prior signaling1001C52 MTC high prior signaling1001C54 MOC low prior signaling1001C56 MTC high prior signaling1001C58 Call re establishment att1001C60 Terminating cause

unknownFailures by RRC Connection Setup Causes

Triggers: 1001C23 MOC conv call failure1001C25 MOC stream call failure1001C27 MOC interac call failure1001C29 MOC backgr call failure1001C31 MOC subscribed call fail1001C33 MTC conv call failure1001C35 MTC stream call failure1001C37 MTC interac call failure1001C39 MTC backgr call failure1001C41 Emergency call failure1001C43 Inter RAT cell reselec fail1001C45 Inter RAT cell chng ord

fail1001C47 Registration attempt fai1001C49 Detach attempt failure1001C51 MOC high prior sig failure1001C53 MTC high prior sig failure1001C55 MOC low prior sig failure1001C57 MTC high prior sig failure1001C59 Call re establishment fail1001C61 Terminating cause

unknown failure

Call Setup Performance-RRC Connection Establishment: Counters-


UE RNCBTS CN

RRC Setup and Access Complete Ratio [%]100*[Sum(1001C8)/Sum(1001C0)]






Special Reason: RRC Connection Active Release Due to Triggers: 1001C13 SRNC Relocation 1001C14 Pre-emption

RRC Drop Ratio [%]100-100*[Sum(1001C12+1001C13 +1001C14)/Sum(1001C8)]

RRC: Connection RequestCorrectly Received messageRRC Connection Setup StartsTriggers: 1001C0 RRC Connection Attempt




RRC: RRC Connection CompletedRRC Connection Access completedTriggers: 1001C8 RRC Con Acc Comp

RRC Setup Complete Ratio [%]100*[Sum(1001C1)/Sum(1001C0)]

Call Setup Performance-RRC Connection Establishment: PIs-



• RRC Setup and Access Complete Ratio [%]• It should be noted that this PI is not call setup success rate

(counted from the user perspective) as:• the RAB setup and access phases not included• the user’s UE can send several RRC Connection Request –

messages until the connection is successfully established• Also it should be noted that different UEs are using the RRC

Connection establishment cause values differently (counters 1001C22 – 1001C61)

• E.g. Sanyo UE classifies UDI video call as MOC/MTC Conversational call where as NEC VTX classifies the same UDI video call as MOC/MTC High Priority Signaling

• RRC Access Failure counters• The difference between counters 1001C9 and 1001C10 is:

• 1001C9 is incremented in case Synchronization Indication IS received from BTS but no RRC Connection Setup Complete message is received from the UE

• 1001C10 is incremented in case Synchronization Indication is NOT received from BTS and no RRC Connection Setup Complete message is received from the UE



• The RRC Connection Setup and Access Complete Ratio is showing very poor results

• This however does not give correct picture from end user point of view as the UE can send several RRC Connection Requests and currently we do not know how many RRC Connection Requests the UE sends before success

• Therefore maybe better would be to calculate the RRC Connection Setup and Access Complete Success Rate by:

•In case the ratio 1001C0/1001C8 < (N300+1) then we could claim that on average there are no call setup failures due to RRC Connection•In case the ratio 1001C0/1001C8 > (N300+1) then the RRC Connection Setup and Access Complete success rate could be calculated as (N300+1)/(1001C0/1001C8)


Call Setup Performance-RRC Connection Establishment: Questions-

• Why there is a problem with RRC Connection establishment?

• What is the difference between counters 1001C9 and 1001C10 and which one most probably is having higher value at the moment?

• What are the actions with which the RRC Connection Setup and Access Complete ration can be improved?


Contents





Call Setup Performance-RAB Establishment Performance-

• The RAB establishment procedure starts right after the RRC Connection establishment, signalling connection establishment, authentication & security procedures and call setup signaling

UEUE Node BNode B RNCRNC CNCN

RRC:Initial Direct Transfer(MM:CM Service Request)

SCCP:CC

RANAP:Direct Transfer(MM:Authentication Request)

RRC:DL Direct Transfer(MM:Authentication Request)

RANAP:Direct Transfer(MM:Authentication Response)

RANAP:Common ID

RANAP:Security Mode Command

RRC:Security Mode Command

RRC:Security Mode Complete

RANAP:Security Mode Complete

RRC:UL Direct Transfer(CC:Setup)

RANAP:Initial UE Message(MM:CM Service Request)

RANAP:Direct Transfer(CC:Setup)

RRC:UL Direct Transfer(MM:Authentication Response)


RANAP:RAB Assignment Request

NBAP:Radio Link Reconfiguration Prepare

NBAP:Radio Link Reconfiguration ready

ALCAP:ERQ

ALCAP:ECFALCAP:ERQ

ALCAP:ECF

NBAP:Radio Link Reconfiguration Commit

RRC:Radio Bearer Setup

RRC:Radio Bearer Setup Complete

RANAP:RAB Assignment Response

RANAP:Direct Transfer(CC:Alerting)RRC:DL Direct Transfer(CC:Alerting)

RANAP:Direct Transfer(CC:Connect)

RRC:DL Direct Transfer(CC:Connect)

RRC:UL Direct Transfer(CC:Connect Acknowledge)

RANAP:Direct Transfer(CC:Call Proceeding)

RRC:DL Direct Transfer(CC:Call Proceeding)

RANAP:Direct Transfer(CC:Connect Acknowledge)


Call Setup Performance-RAB Establishment Performance: Counters; RAB Setup &

Access-

UE RNCBTS CN


RANAP: RAB Assignment Request

RRC: Radio Bearer Setup

RAB Setup phaseResource Reservation in RNC, BTS, Transmission

RAB Setup startsDepending on RAB TypeTriggers: 1001C66 RAB setup att for CS Voice1001C67 RAB setup att for CS Data conv class1001C68 RAB setup att for CS Data stream class1001C69 RAB setup att for PS Data conv class1001C70 RAB setup att for PS Data stream class1001C71 RAB setup att for PS Data intera class1001C72 RAB setup att for PS Data backgr class

Failure Case:CS RAB Setup for Voice fails Due to Triggers: 1001C80 Admission control1001C81 BTS1001C82 Transmission network1001C83 RNC internal reason1001C84 Frozen BTSNote: Each RAB typehas identical failure counters

RRC: Radio Bearer Setup Completed

RANAP: RAB Assignment Response

RAB Connection Access phase RNC waits reply from UE

RAB Access CompletedTriggers: 1001C115 RAB setup acc comp for CS Voice1001C116 RAB setup acc comp for CS Data conv class1001C117 RAB setup acc comp for CS Data stream class1001C118 RAB setup acc comp for PS Data conv class1001C119 RAB setup acc comp for PS Data stream class1001C120 RAB setup acc comp for PS Data intera class1001C121 RAB setup acc comp for PS Data backgr class

Failure Case:CS RAB Access for Voice fails Due to Triggers: 1001C122 UE1001C123 RNC internalNote: Each RAB typehas identical failure counters

RAB Active phaseUser Plane Data Transfer

RAB Setup CompletedDepending on RAB TypeTriggers: 1001C73 RAB setup comp for CS Voice1001C74 RAB setup comp for CS Data conv class1001C75 RAB setup comp for CS Data stream class1001C76 RAB setup comp for PS Data conv class1001C77 RAB setup comp for PS Data stream class1001C78 RAB setup comp for PS Data intera class1001C79 RAB setup comp for PS Data backgr class


Call Setup Performance-RAB Establishment Performance: Counters RAB Active Phase-

UE RNCBTS CN

RANAP: RAB Assignment Request, with IE: RAB reconfiguration

RRC: Radio Bearer Reconfiguration

RAB ReconfigurationResource Reconfigured in RNC, BTS, Transmission

RRC: Radio Bearer Reconfiguration Complete


RAB Active phaseUser Plane Data Transfer Special Reason:

RAB Active Release Due to Triggers: 1001C143 SRNC Relocation for CS Voice1001C144 Pre-emption for CS VoiceFor all types of RABs

RAB Reconfiguration Attempt Triggers: 1001C197 RAB reconf AttFor all types of RABs

RAB Reconfiguration FailureTriggers: 1001C198 RAB reconf FailFor all types of RABs

RANAP: RAB Assignment Request, with IE: RAB Release

RRC: Radio Bearer Release



RAB ReleaseResource Released in RNC, BTS, Transmission

RAB Active CompletedDepending on RAB TypeTriggers: 1001C136 RAB Act Comp for CS Voice1001C137 RAB Act Comp for CS Data conv class1001C138 RAB Act Comp for CS Data stream class1001C139 RAB Act Comp for PS Data conv class1001C140 RAB Act Comp for PS Data stream class1001C141 RAB Act Comp for PS Data intera class1001C142 RAB Act Comp for PS Data backgr class


Call Setup Performance-RAB Establishment Performance: PIs-

UE RNCBTS CN

RANAP: RAB Assignment Request

RRC: Radio Bearer Setup

RAB Setup phaseResource Reservation in RNC, BTS, Transmission

RRC: Radio Bearer Setup Completed


RAB Connection Access phase RNC waits reply from UE

RAB Setup Complete Ratio [%]100*[Sum(1001C73…79)/Sum(1001C66…72)]

RAB Setup and Access Complete Ratio [%]100*[Sum(1001C115..121)/Sum(1001C66…72)]

RANAP: RAB Assignment Request, with IE: RAB Release

RRC: Radio Bearer Release



RAB Drop Ratio [%]100-100*[Sum(1001C136…142+1001C143+1001C144+1001C151…154+1001C167…172)/Sum(1001C115…121)]


Call Setup Performance-RAB Establishment Performance: PIs-

• RAB Setup and Access Complete Ratio [%]• This PI gives success rate for the RAB establishment – this

however is not Call Setup Success Rate as it does not include RRC phase

• It is calculated as the ratio between received RANAP: Assignment Request –messages and sent RANAP: Assignment Response (showing successful case) -messages

• RAB Drop Ratio [%] • This PI can be used as dropped call rate • And it is calculated as sent RANAP: RAB Assignment Response

(showing successfully released RAB) –messages summed with RAB releases due to SRNC relocation (separate counters for each traffic class) and RAB releases due to pre-emption (separate counters for each traffic class) divided by amount of RANAP: RAB Assignment Response (separate counters for each traffic class)



• It should be noted that during RAB Assignment procedure (i.e. between RAB Assignment Request and RAB Assignment Response) the SHO activation is not possible -> measurement reports are rejected (e1a and e1c) or buffered (e1b)

• From UE logs point of view between CALL PROCEEDING and ALERTING

• This phenomena (parallel procedure not allowed) is not taken into account by the counters i.e. all the failure counters for SHO are updated if measurement reports are received during this period





ALCAP:ERQ

ALCAP:ECFALCAP:ERQ

ALCAP:ECF





RANAP:Direct Transfer(CC:Alerting)RRC:DL Direct Transfer(CC:Alerting)









• As it can be seen the RAB Setup Complete ratio and RAB Setup and Access Complete ratio are extremely good showing basically 100% success rate for RAB establishment

• Therefore in case the whole call setup success rate is evaluated as RRC Setup and Access Success rate * RAB Setup and Access Success rate the results are not so good due to RRC Connection Setup and Access complete

102 © NOKIA Call Performance.PPT / 16-09-2003 /Reunanen JussiCompany Confidential

Call Setup Performance-RAB Establishment Performance : Questions-

• What needs to be remembered concerning SHO during call setup?

• What is RAB?

• What is given in RAB attributes?


Contents





Call Setup Performance-Failure due to AC-

• If the reason for failure is Admission Control, it can be due to • Uplink: PrxTarget is reached for PrxTotal or

PrxTarget+PrxOffset is reached for average PrxTotal• Traffic, • External Interference, • Cabling, • MHA settings, • UE Power Control.

• Downlink: PtxTarget is reached for PtxTotal or PtxTarget+PtxOffset is reached for average PtxTotal

• Traffic• Cabling• Size of cell and UE locations (all at cell edge ?)• DL Power allocation

• The reason can be identified in the traffic table counters• Signalling link: DCH_REQ_LINK_REJ_UL_SRNC &

DCH_REQ_LINK_REJ_DL_SRNC• Conversational: REQ_CS_CONV_REJ_UL_SRNC &

REQ_CS_CONV_REJ_DL_SRNC

•See next slides for details

•See next slides for details

Failure Case:CS RAB Setup for Voice fails Due to Triggers: 1001C80 Admission control1001C81 BTS1001C82 Transmission network1001C83 RNC internal reason1001C84 Frozen BTSNote: Each RAB type has identical failure counters



Call Setup Performance-Investigating Call Setup Failure-

MTC/MOC ?

ServLev:RRC Setup failures ?

Traffic:UL/DL ?

Investigate transmission

or BTS

Cause: Trans, BTS

MTC

Investigate paging : See

chapter Paging

Cause: AC

ServLev:RAB Setup failures ?

Cause: Trans, BTS

Investigate interference : See chapter

UL Interferenc

e

Investigate Tx Power :

See chapter Tx Power

PIs

DLUL

Cause: AC

ServLev:RRC/RAB Access

failures ?

Investigate radio conditions,

synchronisation : See chapter RRC Connection

Establishment

Due to MS



Call Setup Performance-Call Setup Success Rate : CSSR-

• CSSR Formula is built from two part, RRC setup and RAB Setup phases.

• RRC separation is done by selecting only RRC setups with reason MOC or MTC call and corresponding failures.

• RRC setup reason is set by mobile and there has been noticed some inconsistencies between mobile vendors => this formula might ignore or take into notice also other RRC activities than which are aimed


Call Setup Performance-Call Setup Success Rate : CSSR-

• As it can be seen the poor CSSR is almost all due to poor RRC Connection Setup and Access complete success rate


Call Setup Performance-Call Setup Time-

• Call Setup Time for AMR – mobile 3G UE to PSTN

Time Direction Message58:30.7 UL CCCH rrcConnectionRequest58:31.2 DL CCCH rrcConnectionSetup58:31.4 UL DCCH rrcConnectionSetupComplete58:31.7 UL DCCH initialDirectTransfer58:32.0 DL DCCH downlinkDirectTransfer58:32.4 UL DCCH uplinkDirectTransfer58:32.6 DL DCCH securityModeCommand58:32.6 UL DCCH securityModeComplete58:33.0 UL DCCH uplinkDirectTransfer58:33.2 DL DCCH downlinkDirectTransfer58:33.9 DL DCCH radioBearerSetup58:34.8 UL DCCH measurementReport58:35.1 UL DCCH radioBearerSetupComplete58:35.3 UL DCCH measurementReport58:35.3 DL DCCH downlinkDirectTransfer (CC: Alerting)

Average call setup time ~4.6seconds

Call Setup Delay (PDF CDF)

0

10

20

30

40

50

60

70

80

90

100

0 0 to 3000 3000 to 5000 5000 to 8000 8000 to 10000 > 10000Setup Time [ms]

PDFCDF



• Call Setup Time for UDI

• UDI calls are performed between 2 3G UE

• The test results below show that M-M case time is longer especially in CN due to B party waiting time.

ApplicationApplication Time Time in UE in UE (sec)(sec)

Time in Time in CN (sec)CN (sec)

Total Total time time (sec)(sec)

MOC UDI MOC UDI serverserver

2.92.9 0.20.2 5.215.21

MOC TV callMOC TV call 2.92.9 5.175.17 10.010.0

MTC TV callMTC TV call 2.92.9 0.10.1 5.05.0

CN delay UE delay

UE Node B RNC CN

RRC:RRC Connection Request


NBAP:RL Setup Response

ALCAP:ERQ

ALCAP:ECF

RRC:RRC Connection Setup

RRC:RRC Connection Setup Complete

RRC:Initial Direct Transfer(MM:CM Service Request)

RANAP:Initial UE Message(MM:CM Service Request)

SCCP:CC

RANAP:Direct Transfer(MM:Authentication Request)

RRC:DL Direct Transfer(MM:Authentication Request)

RRC:UL Direct Transfer(MM:Authentication Response)

RANAP:Direct Transfer(MM:Authentication Response)

RANAP:Common ID

RANAP:Security Mode Command

RRC:Security Mode Command

RRC:Security Mode Complete

RANAP:Security Mode Complete



NBAP:RL Restore Indication

RANAP:Direct Transfer(CC:Setup)

RRC:UL Direct Transfer(CC:Setup)



• Call Setup Time for UDI

• UDI calls are performed between 2 3G UE

• The test results below show that M-M case time is longer especially in CN due to B party waiting time.

ApplicationApplication Time Time in UE in UE (sec)(sec)

Time in Time in CN (sec)CN (sec)

Total Total time time (sec)(sec)

MOC UDI MOC UDI serverserver

2.92.9 0.20.2 5.215.21

MOC TV callMOC TV call 2.92.9 5.175.17 10.010.0

MTC TV callMTC TV call 2.92.9 0.10.1 5.05.0

CN delay UE delay

UE Node B RNC CN




ALCAP:ERQ

ALCAP:ECF

ALCAP:ERQ

ALCAP:ECF





RANAP:Direct Transfer(CC:Alerting)

RRC:DL Direct Transfer(CC:Alerting)







• Call Setup Time for UDI – mobile 3G UE to stationary 3G UE

Call Setup Delay (PDF CDF)

0102030405060708090

100

0 0 to 3000 3000 to5000

5000 to6000

6000 to7000

7000 to8000

8000 to10000

> 10000

Setup Time [ms]

PDFCDF

16:29.0 rrcConnectionRequest16:29.0 rrcConnectionSetup16:30.0 rrcConnectionSetupComplete16:30.0 initialDirectTransfer16:31.0 downlinkDirectTransfer16:31.0 uplinkDirectTransfer16:31.0 securityModeCommand16:31.0 securityModeComplete16:31.0 uplinkDirectTransfer16:31.0 downlinkDirectTransfer16:32.0 radioBearerSetup16:33.0 radioBearerSetupComplete16:34.0 measurementControl16:39.0 downlinkDirectTransfer



• Call Setup Time can be decreased by adjusting the MSC parameters for the Authentication i.e. each call is not authenticated

• The calls that are not authenticated there is ~600ms reduction in call setup time

• For example following MSC/VLR parameter set for authentication means that only every 10th Mobile Originated call is authenticated

• AUTHENTICATION LOC UP NEW VIS: 1

• when a new visitor makes LU authentication is always used

• LOC UP: 1

• when LU is made authentication is always used

• PER UP: 0• For periodical location updates

authentication is not used

• IMSI ATTACH: 1

• when IMSI Attach procedure is made authentication is always used

• MO CALL: 10

• only every 10th MO call is authenticated

• MO SMS: 10

• only every 10th MO SMS procedure is authenticated

• MT CALL: 0 • For MT calls authentication is not used at all

• MT SMS: 0 • For MT SMS procedures authentication is not

used

• MT LOC REQ: 0 • Authentication not used for Mobile Terminated

location request procedures

• MT USSD: 0 • Authentication not used for Mobile Terminated

USSD

• SS OPER: 0• Authentication not used for Supplementary

Services operations



• Call Setup Delay can be improved currently by• Using 13.6kbps SRB bitrate but then Iub capacity is

decreased as the bitrate for DCCH (SRB) is fixed to be 13.6kbps irrespective of the state of the call (call setup phase or active phase)

• The call setup time improvement is in the region of 0.75 seconds compared to 3.4 kbps SRB bit rate allocation



• Improvements in 1.5.2 ED + CDs (available April – September)• SRB BLER optimisation

• The BLER target of SRB change from 1% to 0.1% decreases the RLC PDU retransmissions

• Each RLC PDU retransmission increases set up delay by 100-200ms

• Decrease the number of long set up delays caused by PDU retransmissions (minimum delay not decreased)

• Call Set up Time Optimisation• Dynamic setting of “ActivationTimeOffset” enables 200 to

500ms reduction for set up delay

• Improvements in RAN’04 available 2004 (1Q)• Dynamic 13.6 kbps SRB at RRC connection establishment

• SRB 13.6 kbps usage possible without loosing the Iub capacity



• With SRB 13.6kbps it can be seen that average call set up time of <4s (3G – PSTN) can be achieved

• Results are from laboratory testing showing 83 percentile share of better than 4seconds call set up time

• In case higher percentile for call set-up delay for e.g. 5 seconds is needed then it is utmost important that there is only one RRC Connection Request made as shown in the picture on the left

• Call Setup Delay vs. #RRC Connection Request


Call Setup Performance-Call Setup Time : PIs-

• RRC Setup time: time between RRC: RRC CONNECTION REQUEST and RRC: RRC CONNECTION SETUP COMPLETE

• AVE SETUP TIME FOR RRC (M1001C221)• Average setup time for RRC

– This counter, divided by the denominator, gives the Average Setup Time for RRCs on a measurement period

• UPDATED when RRC connection is successfully set up– UNIT: 10 ms

• DENOMINATOR FOR AVE SETUP TIME FOR RRC (M1001C222)• Denominator for Average setup time for RRC

– UPDATED: When RRC connection is successfully set up this counter is incremented by 1

• UNIT: 10 ms



• RAB setup time: the time between RANAP: RAB ASSIGNMENT REQUEST and RANAP: RAB ASSIGNMENT RESPONSE

• AVE SETUP TIME FOR CS VOICE RAB (M1001C223)• Average setup time for a CS Voice RAB

– This counter, divided by the denominator, gives the Average Setup Time for CS VOICE RABs on a measurement period

• UPDATED: When a RAB is successfully set up.• DENOMINATOR FOR AVE SETUP TIME FOR CS VOICE RAB (M1001C224)

• Denominator for average setup time for a CS Voice RAB• UPDATED when a RAB is successfully set up, this counter is incremented by 1

• AVE SETUP TIME FOR CS DATA CONV RAB (M1001C225)• Average setup time for CS DATA Conversational RAB

– This counter, divided by the denominator, gives the Average Setup Time for CS DATA CONV RABs on a measurement period

• UNIT: 10 ms• DENOMINATOR FOR AVE SETUP TIME FOR CS DATA CONV RAB (M1001C226)

• Average setup time for CS DATA Conversational RAB• UPDATED when a RAB is successfully set up, this counter is incremented by 1• UNIT: 10 ms

• AVE SETUP TIME FOR CS DATA STREAM RAB (M1001C227)• Average setup time for CS DATA Streaming RAB

– This counter, divided by the denominator, gives the Average Setup Time for CS DATA STREAM RABs on a measurement period

• UNIT: 10 ms




• DENOMINATOR FOR AVE SETUP TIME FOR CS DATA STREAM RAB (M1001C228)

• Average setup time for CS DATA Streaming RAB• UPDATED: When a RAB is successfully set up, this counter is

incremented by 1.• UNIT: 10 ms

• AVE SETUP TIME FOR PS DATA CONV RAB (M1001C229)• Average setup time for PS DATA Conversational RAB

– This counter, divided by the denominator, gives the Average Setup Time for PS DATA CONV RABs on a measurement period

• UPDATED: When a RAB is successfully set up• DENOMINATOR FOR AVE SETUP TIME FOR PS DATA CONV RAB

(M1001C230)• Average setup time for PS DATA Conversational RAB• UPDATED:When a RAB is successfully set up, this counter is

incremented by 1.• AVE SETUP TIME FOR PS DATA STREAM RAB (M1001C231)

• Average setup time for PS DATA Streaming RAB– This counter, divided by the denominator, gives Average Setup

Time for PS DATA STREAM RABs on a measurement period• UPDATED: When a RAB is successfully set up




• DENOMINATOR FOR AVE SETUP TIME FOR PS DATA STREAM RAB (M1001C232)

• Average setup time for PS DATA Streaming RAB• UPDATED: When a RAB is successfully set up, this counter

is incremented by 1• AVE SETUP TIME FOR PS DATA INTERACTIVE RAB (M1001C233)

• Average setup time for PS DATA Interactive RAB– This counter, divided by the denominator, gives the

Average Setup Time for PS DATA INTERA RABs on a measurement period

• UPDATED: When a RAB is successfully set up• UNIT: 10 ms

• DENOMINATOR FOR AVE SETUP TIME FOR PS DATA INTERACTIVE RAB (M1001C234)

• Average setup time for PS DATA Interactive RAB• UPDATED: When a RAB is successfully set up, this counter

is incremented by 1• UNIT: 10 ms




• AVE SETUP TIME FOR PS DATA BACKGROUND RAB (M1001C235)

• Average setup time for PS DATA Background RAB– This counter, divided by the denominator, gives the

Average Setup Time for PS DATA BACKGROUND RAB on a measurement period

• UPDATED: When a RAB is successfully set up• UNIT: 10 ms

• DENOMINATOR FOR AVE SETUP TIME FOR PS DATA BACKGROUND RAB (M1001C236)

• Average setup time for PS DATA Background RAB• UPDATED: When a RAB is successfully set up, this counter

is incremented by 1• UNIT: 10 ms



• Call Setup Time:• For Voice = Average RRC Connection Setup time + Average

RAB Setup time for Voice Setup time

)(M1001C224 RAB VOICE CS FOR TIME SETUP AVE FOR RDENOMINATO

)(M1001C223 RAB VOICE CS FOR TIME SETUP AVE

)(M1001C222 RRC FOR TIME SETUP AVE FOR RDENOMINATO

)(M1001C221 RRC FOR TIME SETUP AVE

• For CS Data Conversational Class = Average RRC Connection Setup time + Average RAB Setup time for CS data Conversational

)(M1001C226 RAB CONVDATA CS FOR TIME SETUP AVE FOR RDENOMINATO

)(M1001C225 RAB CONVDATA CS FOR TIME SETUP AVE



• For CS Data Streaming Class = Average RRC Connection Setup time + Average RAB Setup time for CS data Streaming

)(M1001C228 RAB STREAMDATA CS FOR TIME SETUP AVE FOR RDENOMINATO

)(M1001C227 RAB STREAMDATA CS FOR TIME SETUP AVE



• For PS Data Conversational Class = Average RRC Connection Setup time + Average RAB Setup time for PS data Conversational

)(M1001C230 RAB CONVDATA PS FOR TIME SETUP AVE FOR RDENOMINATO

)(M1001C229 RAB CONVDATA PS FOR TIME SETUP AVE





• Call Setup Time:• For PS Data Streaming Class = Average RRC Connection Setup

time + Average RAB Setup time for PS data Streaming

)(M1001C232 RAB STREAMDATA PS FOR TIME SETUP AVE FOR RDENOMINATO

)(M1001C231 RAB STREAMDATA PS FOR TIME SETUP AVE



• For PS Data Interactive Class = Average RRC Connection Setup time + Average RAB Setup time for PS data Interactive

)(M1001C234 RAB EINTERACTIVDATA PS FOR TIME SETUP AVE FOR RDENOMINATO

)(M1001C233 RAB EINTERACTIVDATA PS FOR TIME SETUP AVE



• For PS Data Background Class = Average RRC Connection Setup time + Average RAB Setup time for PS data Background

)(M1001C236 RAB BACKGROUNDDATA PS FOR TIME SETUP AVE FOR RDENOMINATO

)(M1001C235 RAB BACKGROUNDDATA PS FOR TIME SETUP AVE




Call Setup Performance-Call Setup Time : Questions-

• How to improve the Call Setup Time?

• What needs to be noted from the Call Setup Time PI?

• What are the current 3G – PSTN, PSTN – 3G and 3G – 3G call setup times?


Contents





Call Setup Performance-UL Interference-

• By looking the service level measurements counters from the system UL interference problems can be identified (or candidates sites for UL interference problems)

• From following statistics example problem sites can be identified

TIME RNC_NAME WBTS_NAME WCEL_ID AVE_PRXTOT_CLASS_0 PRXTOT_DENOM_0 AVE_PRX_NOISE PRX_NOISE_DENOM_1MAX_PRX_NOISE_VALUE MIN_PRX_NOISE_VALUE

xx/yy/2003 RNC0A S1 11 -101.5303476 417890 -102.2032753 417890 -96.20651315 -104.0488615

S2 21 -100.6359575 120433 -8.450980398 256097 -8.450980395 -8.450980399

S3 31 -100.1797349 418038 -101.5176085 418038 -98.38141601 -102.7430289

S4 41 -99.88490547 417646 -100.1795506 418082 -97.88041662 -102.6695255

S5 51 -99.13808872 418011 -103.0792801 418011 -96.89290798 -106.3280456

S6 62 -96.42019831 236918 -7.993405493 238251 -7.993405485 -7.993405494

S7 72 -95.55816508 417988 -100.6589406 417988 -94.13858107 -105.7031607

S8 81 -92.74359104 417909 -99.20143665 417996 -90.97058471 -105.9885019

S9 82 -92.12983064 418028 -99.37448848 418028 -90.98810486 -106.1318252

S10 101 -88.67772468 417997 -96.24871571 417997 -87.77917773 -104.9551382

S11 111 -73.0103741 417889 -88.20890215 417912 -82.83331727 -101.3714613

xx/yy/2003 RNC0A

xx/yy/2003 RNC0A

xx/yy/2003 RNC0A

xx/yy/2003 RNC0A

xx/yy/2003 RNC0A

xx/yy/2003 RNC0A

xx/yy/2003 RNC0A

xx/yy/2003 RNC0A

xx/yy/2003 RNC0A

xx/yy/2003 RNC0A



• Network statistics was found to show increased daily Prx_Noise levels for sector S62

• Call Setup problems and dropped calls under this cell

• In on-line monitoring sector 2 shows abnormal behavior where Prx_tot is jumping up periodically

• Slight trace of the same behavior also seen sector 1 even though the level is much lower

WBTS6 S6 WCEL62 UPLINK 10:10:10.0


• Admission control will block all the call setup attempts and even RRC Connection Request during the time the UL noise rise is above the set threshold value i.e. PrxTotal > PrxTarget + PrxOffset and even RRC Connection Requests are blocked when the UL noise rise is above the PrxTarget + PrxOffset• By setting:

• the PrxTarget to maximum = 30dB• PrxOffset to maximum = 6dB• PrxNoise to autotuning with 20dB tuning window

• The AC operation can be disabled however the calls cannot be setup because of the coverage



• The site was visited and investigated and the following finding was made:

• When the antenna line is disconnected the phenomena disappears.

• When the antenna is reconnected the same same behavior reappears.

• This would suggest that the cause for this behavior is rather external interference than in the BTS.

• However, the antenna installation of this site more than suggests that this site cannot perform normally.





• Under the cell suffering from excessive >>5dB noise rise due to interference, it is extremely difficult to initiate a call

• RACH procedure might fail due to not enough margin for power ramp up (especially in case the UE is having problems with Open Loop PC)

• Initial TX power for first PRACH preamble

Normal cell = UL & DL coverage are balanced

Cell suffering from UL interference = DL (CPICH) coverage much bigger than UL coverage

Cell A Cell B

ptx = CPICHtransmissionPower-RSCP(CPICH)+RSSI(BS)+"constant value“

• In case the cell having PrxNoise very high (and interference conditions cannot be solved – external source) and at the same time no RRC Connection Requests received by the RNC (Counter 1001C0 is showing very low or 0 value) -> PRACH_preamble_retrans and RACH_tx_Max could be tuned


• In Nokia RAN there are two sets of parameters related to antenna line components to be set in order to guarantee proper operation. Both sets of settings have to reflect the actual used BTS configuration. 1. Feeder loss and MHA gain parameters (set in BTS

during commissioning) BTS reports received wideband power back to the RNC. Feeder

loss and MHA gain parameters are used in calculating the value of the received wideband power

MHA parameter is set according to the actual used MHA gain (MHA gain is fixed)

MHA gain value can be checked from the MHA manufacturer's data sheet

• Feeder loss parameter includes feeder loss, diplexer loss and other connector losses

• If a value of 3dB for feeder loss for a cell is measured, then this value must be entered in the BTS commissioning file

• These parameter do not exist in the parameter dictionary because they are not directly visible to RNC



• In Nokia RAN there are two sets of parameters related to antenna line components to be set in order to guarantee proper operation. Both sets of settings have to reflect the actual used BTS configuration. N2. MHA parameter and Cable loss parameter (WBTS

parameters in RNC)• These parameters are directly related• If MHA parameter set to OFF, Cable loss parameter is not used• If MHA parameter set to ON, Cable loss parameter is used• Cable loss parameter defines the difference in DL link loss in

relation to the UL link loss• Factors that contribute to UL/DL unbalance: MHA• Cable loss = Real MHA gain = Feeder loss parameter

• The above mentioned parameters have to be set correctly in the BTS and RNC. Otherwise there is a possibility that the cell will end up with high noise



• RNC uses MHA parameters and cable loss parameter to adjust the open loop PC for PRACH and initial UL DPCCH power

• If parameter MHA used is set to yes, adjustment is done based on the Cable Loss parameter value

• If cable loss parameter is not correctly set, the initial PRACH and UL DPCCH powers are not properly set:

• If cable loss is set to less than the actual difference between DL and UL link losses, the initial powers in PRACH and UL DPCCH are too high

• If cable loss is set to higher than the actual difference between DL and UL link losses, the initial powers in PRACH and UL DPCCH are too low

• When considering the impact of this, one should bear in mind:• the relative inaccuracy of the open loop PC, and the fact

that the PRACH power is gradually ramped up, if no acquisition indicator is received in AICH

• UL DPCCH power (in case of first RL) is gradually commanded (by TPCs) to be increased if no UL syncronisation is obtained



• The impact of setting cable loss wrongly in RNC is probably not fatal, definitely non optimum performance could be caused

• In case we MHA is set ‘yes’ in RNC then:• and for PRACH the cable loss is subtracted from

PtxPrimaryCPICH and result is transmitted in SIB 5/6 to the UE for the open loop PC purposes

• cable loss is used to adjust the TxCPICH in the following formula for initial UL DPCCH:

• where TxCPICH is then PtxPrimaryCPICH - Cable Loss

)log(10r_offsetDPCCH_Powe DPCCHDPCCHRSSICPICH SFSIRRxTx



• When MHA and Cable data is wrong in commissioning file,…• RRC connection reject due to congestion can be observed.• Re-commissioning with correct data is needed

PrxTotal ~ -73dBmPrxTotal ~ -105dBm

After original commissioning -> no calls through

After re-commissioning => call can be made



Call Setup Performance -UL Interference PIs : PrxTotal measurements-

• Sample 1 : Unloaded

• Sample 2 : Feasible load area 1


• Sample 4 : Marginal load area

• Sample 5 : Overload area

X = collected sample of PrxTotal measurement

• PrxTotal values are presented according to:

• BTS reports total UL interference (RSSI) with a resolution of 0.1 dB with the range [-112, ...,-50] dBm

• RSSI_LEV _000: RSSI < -112.0 dBm• RSSI_LEV _001: -112.0 dBm <= RSSI < -

111.9 dBm• RSSI_LEV _002: -111.9 dBm <= RSSI < -

111.8 dBm• RSSI_LEV _619: -50.2 dBm <= RSSI < -50.1

dBm• RSSI_LEV _620: -50.1 dBm <= RSSI < -50.0

dBm• RSSI_LEV _621: -50.0 dBm <= RSSI

• The correct value in dBm can be obtained by formula:

-112.0dBm + (RSSI_LEV)/10


• The PrxTotal measurements are divided into classes according to following criteria:

CLASS AREA INCREMENTED IF

CLASS 0

Unloaded (Lrt=<UnloadedRT) AND (Lnrt=<UnloadedNRT)

CLASS 1

Feasible_Load_Area_1

(PrxTarget -PrxOffset >= PrxTotal ) AND ((Lrt>UnloadedRT) OR (Lnrt>UnloadedNRT))

CLASS 2


(PrxTarget > PrxTotal > PrxTarget -PrxOffset) AND ((Lrt>=UnloadedRT) OR (Lnrt>= UnloadedNRT))

CLASS 3

Marginal_Load_Area

(PrxTarget + PrxOffset > PrxTotal >=PrxTarget) AND ((Lrt>UnloadedRT) OR(Lnrt> UnloadedNRT))

CLASS 4

Overload_Area (PrxTotal >= PrxTarget + PrxOffset) AND ((Lrt>UnloadedRT) OR (Lnrt>UnloadedNRT))

• Based on the INCREMENT IF criteria the CLASS is selected and the measurement result is assigned to the corresponding class and the amount of samples in the class is put into the PRXTOT_DENOM_0



• As en example for CLASS 0:

WCELL Name Start Time AVE_PRXTOT CLASS 0

PRXTOT_DENOM_0

PLMN-PLMN/RNC-2/WBTS-1627/WCEL-16271

2003031123 84 17972


2003031122 86 17984


2003031121 88 17977

WCELL Name Start Time AVE_PRXTOT CLASS 0

[dBm]

PRXTOT_DENOM_0


2003031123 -112.0 + 84/10 = -103.6

17972


2003031122 -112.0 + 86/10 = -103.4

17984


2003031121 -112.0 + 88/10 = -103.2

17977

This is number of samples during measurement period i.e. as the period is one hour and RRI period is 200ms -> 3600s/0.2s = 18 000, some samples are not there but in general ~18 000 per one hour

This is number of samples during measurement period i.e. as the period is one hour and RRI period is 200ms -> 3600s/0.2s = 18 000, some samples are not there but in general ~18 000 per one hour

Measurement start time is: 2003 March 11th at 11pm and as next was same date but 10pm the measurement/reporting period is 60min

Measurement start time is: 2003 March 11th at 11pm and as next was same date but 10pm the measurement/reporting period is 60min

This is already average valueThis is already average value



• MAX_PRX_NOISE_VALUE (M1000C12)

• This counter is updated if the value of the counter PrxTotal is smaller than the current value of PrxNoise threshold but Lrt<UnloadedRT and Lnrt<UnloadedNRT

• The dBm value is obtained by dividing with -100


• MIN_PRX_NOISE_VALUE (M1000C13)• This counter is updated if the value of the counter PrxTotal is

bigger than the current value of PrxNoise threshold but Lrt<UnloadedRT and Lnrt<UnloadedNRT

• The dBm value is obtained by dividing with -100

Call Setup Performance -UL Interference PIs : PrxNoise measurements-


• AVE_PRX_NOISE (M1000C10)• In case the PrxTotal result is

in the unloaded area i.e. Lrt<UnloadedRT and Lnrt<UnloadedNRT, the received PrxTotal value is used to update the PrxNoise counter


• This counter is a sum over a measurement period divided by a denominator (averaged value)

• UPDATED: In every radio resource indication period• dBm value value can be derived by multiplying with –100

Call Setup Performance -UL Interference PIs : PrxNoise measurements-


X = collected sample of PtxTotal measurement

• PtxTotal means the total transmitted power in a cell

• The counter value is already average dBm value and it is multiplied by 100

• PtxTotal values are presented as follows:


CLASS 0

Unloaded PtxTotal = PtxCPICH + PtxPCCPCH

CLASS 1


PtxTarget -PtxOffset > PtxTotal > (PtxCPICH + PtxPCCPCH)

CLASS 2


PtxTarget > PtxTotal >= PtxTarget - PtxOffset

CLASS 3

Marginal_Load_Area

PtxTarget + PtxOffset > PtxTotal >= PtxTarget

CLASS 4

Overload_Area PtxTotal >= PtxTarget + PtxOffset

Call Setup Performance -UL Interference PIs : PtxTotal measurements-


• There are specific counters for Lrt and Lnrt for each CLASS (0 … 4) defined same way as for PrxTotal measurements.

• Sample 1 : Unloaded



• Sample 4 : Marginal load area

• Sample 5 : Overload area


• Counter values are already averaged and real % value is obtained when the counter value is divided by 100

• When the PrxTotal value is inside the specific CLASS range,this counter is updated with the estimated LRT value

• At the same time as AVE PRXTOT CLASS X counter is updated i.e. when Radio Resource Indication message arrives

Call Setup Performance -UL Interference PIs : Lrt & Lnrt measurements-


• Lrt means RT traffic load in a cell. The value is between [0...1[

• Lnrt means NRT traffic load in a cell. The value is between [0...1[

• By load we mean calculated fractional load in a cell (own and other cell user interference)

totalrxrx PWR

RP _

factorloadLL

WR

R

P

P

totalrx

rx

_

• the uplink interference a user will cause in the cell can be solved

• the load factor of all the users in the cell ownL

userscellOwn

own LL__

owntotalrx

ownrx LP

P

_

_

ownLi)1(



• From obtained fractional load :

rx_total

ULactivenrtN

i

ii

rx_nrt P

RW

P

___

1 1

1

totalrx

nrtrxnrt P

PL

_

_

ULactivenrtN

i

ii

nrt

RW

L___

1 1

1

Lnrt Lrt

rx_total

ULactivertN

i

ii

rx_rt P

RW

P

___

1 1

1

totalrx

rtrxrt P

PL

_

_

ULactivertN

i

ii

rt

RW

L___

1 1

1

• Own cell real time user/ non-real time user load can be obtained by multiplying Lrt/Lnrt by PrxTotal

Lrt + Lnrt = Lown userscellOwn

own LL__



Call Setup Performance -Tx Power : PtxTotal PIs-


• PtxTotal means the total transmitted power in a cell

• If raw counter value is investigated (not through EOSflex), the counter value is already average dBm value and it is multiplied by 100

• PtxTotal values are presented as follows:


CLASS 0

Unloaded PtxTotal = PtxCPICH + PtxPCCPCH

CLASS 1


PtxTarget -PtxOffset > PtxTotal > (PtxCPICH + PtxPCCPCH)

CLASS 2


PtxTarget > PtxTotal >= PtxTarget - PtxOffset

CLASS 3

Marginal_Load_Area

PtxTarget + PtxOffset > PtxTotal >= PtxTarget

CLASS 4

Overload_Area PtxTotal >= PtxTarget + PtxOffset


Call Setup Performance -Tx Power : Ptx_RT & Ptx_NRT PIs-

• Ptx_RT means in downlink transmitted power for RT services in a cell• The value is achieved by calculating the RT traffic contribution

(traffic class conversational or streaming) to the average transmitted code powers

• The code powers are measured by the BTS and reported to the RNC for each radio link of a cell

• The value is produced in every NBAP Radio Resource Indication period and expressed in dBm

• Ptx_NRT means in downlink transmitted power for NRT services in a cell

• The value is achieved by calculating the NRT traffic contribution (traffic class interactive or background) to the average transmitted code powers

• The code powers are measured by the BTS and reported to the RNC for each radio link of a cell

• The value is produced in every NBAP Radio Resource Indication period and expressed in dBm




• Estimated average transmitted power for downlink RT or NRT users on the cell for CLASS X (0 … 4)

• This counter is a sum over a measurement period divided by a denominator and it is average value

• The counter for specific CLASS is updated at the same time as AVE PTXTOT CLASS X counter i.e. when Radio Resource Indication message arrives

• For Example: When the PtxTotal value is inside CLASS 0 range, the AVE PTX RT CLASS 0 counter is updated with the estimated PTX RT value

• Real dBm value is obtained when divided by 100!

• CLASS 0 counters does not include situations when the BTS is not active



• The Ptx_average values are obtained from the Radio Link Measurements –report sent by the BTS

• RNC (AC/PS) is able to identify which of the Ptx_average values belongs to which services (RT or NRT)

ULactivenrtN

iitxPP

___

1,nrttx,

tx_averageitx, PP

ULactivertN

iitxPP

___

1,rttx,

wheretx_average

itx, PP where

reported-RL-Information-RL-Meas-Rep - length (in bits): 00000 Reported-RL-InformationItem-RL-Meas-Rep - extension flag: 0 - preamble: 00 - rL-ID: 1 - contents (in bits): 00001 measurement-1-Avail-Ind - extension flag: 0 - choice index: 0 measurement-Available - extension flag: 0 - average-DL-TransmittedPower: 80 - contents (in bits): 1010000 - trailing bits: 0

reported-RL-Information-RL-Meas-Rep - length (in bits): 00000 Reported-RL-InformationItem-RL-Meas-Rep - extension flag: 0 - preamble: 00 - rL-ID: 1 - contents (in bits): 00001 measurement-1-Avail-Ind - extension flag: 0 - choice index: 0 measurement-Available - extension flag: 0 - average-DL-TransmittedPower: 80 - contents (in bits): 1010000 - trailing bits: 0

• Based on the Radio Link ID information

Reported value Measured quantity value Unit UTRAN_CODE_POWER _010 -10.0 Transmitted code power < -9.5 dBm UTRAN_CODE_POWER _011 -9.5 Transmitted code power < -9.0 dBm UTRAN_CODE_POWER _012 -9.0 Transmitted code power < -8.5 dBm … … … UTRAN_CODE_POWER _120 45.0 Transmitted code power < 45.5 dBm UTRAN_CODE_POWER _121 45.5 Transmitted code power < 46.0 dBm UTRAN_CODE_POWER _122 46.0 Transmitted code power < 46.5 dBm

From 25.133


Contents

• Call Setup Performance• Idle Mode Performance• Paging• RRC Connection Establishment Performance• RAB Establishment Performance• Call Setup Time• UL Interference

• Dropped Call Performance• Loss of Synchronization DL/UL• SHO Performance • DL Power Allocation Parameters• UL Power Allocation Parameters



• During the In-sync state, the BTS L1 monitors the synchronization status of each radio frame

• If N_OUTSYNC_IND (def. 20) consecutive Out-of-sync indications are received, L1 starts the timer T_RLFAILURE (def. 2seconds)

• The timer is stopped and reset if N_INSYNC_IND (def. 4) consecutive In-sync indications are received

• If the timer T_RLFAILURE expires, the radio link is moved to an Out-of-sync state

• When a radio link has been moved to the Out-of-sync state, L1 informs BTS L3 about the synchronization failure

• BTS L3 sends the NBAP:RADIO LINK FAILURE message to the RNC• BTS L3 repeats the NBAP:RADIO LINK FAILURE message periodically at

intervals defined by timer T_arlf (T_arlf = 5s) until L1 has re-established the synchronization or the radio link is released by the RNC with the NBAP:RADIO LINK DELETION message

• If N_INSYNC_IND In-sync frames are received during the Out-of-sync state, L1 changes the radio link back to the In-sync state and inform BTS L3 about the re-established synchronization

• BTS L3 sends the NBAP:SYNCHRONIZATION INDICATION message to the RNC

• During the Out-of-sync state, L1 keeps on searching the synchronization as long as the synchronization has been re-established or the radio link is released by the RNC with the NBAP:RADIO LINK DELETION message

Dropped Call Performance-Loss of Synchronization UL-


• The loss of UL synchronization can be noticed on L3Iub table counters:

• FAIL_SHO_SRNC_INI_SYN_FAIL for the initial synchronization• FAIL_SHO_SRNC_ACT_SYN_FAIL for active links

• UL In-Sync/Out-of-Sync is based on the measured UL BER:• Out-of-Sync is entered if the BER goes below Q_OUT for 160ms• In-Sync is entered if the BER goes above Q_IN for 160ms

• Hidden parameters:• Q_IN=20% BER (before R1.5.2 CD12 it was 12%)• Q_OUT=15%BER

Dropped Call Performance-Loss of Synchronization UL-


• Radio link failure detection in DL is based on counter N313 (counting “out of sync” indicator) and timer T313 in UE

• In CELL_DCH State, after receiving N313 consecutive "out of sync" indications from layer 1 for the established DPCCH physical channel in FDD the UE

• start timer T313• upon receiving N315 successive "in sync" indications from layer 1

and upon change of UE state:– stop and reset timer T313

“out of sync” indicators“out of sync” indicators

Timer T313 started

Timer T313 started



N315 L1 “in sync” indicatorsN315 L1 “in sync” indicators

N313 amount of “out of sync” indicatorsN313 amount of “out of sync” indicators

Timer T313 stopped and reset

Timer T313 stopped and reset



N_OUTSYNC_IND “out of sync” indicators


N_INSYNC_IND“in sync” indicatorsN_INSYNC_IND“in sync” indicators

Timer T_RLFAILURE stopped and reset

Timer T_RLFAILURE stopped and reset

Dropped Call Performance-Loss of Synchronization DL/UL-

151 © NOKIA Call Performance.PPT / 16-09-2003 /Reunanen JussiCompany ConfidentialNot implemented in Nokia RAN currently

• if T313 expires:– consider it as a "Radio link failure"

“out of sync” indicators“out of sync” indicators

Timer T313 started

Timer T313 started

N313 amount of “out of sync” indicators

N313 amount of “out of sync” indicators

Timer T313 expires

Timer T313 expires

Radio Link FailureRadio Link Failure

Timer T315 started

Timer T314 started

When the criteria for radio link failure are fulfilled.The timer is started only if radio bearer(s) that are associated with T315 exist. Currently all the radio links are associated with T315

When the criteria for radio link failure are fulfilled.The timer is started if radio bearer(s) that are associated with T314 exist of if only RRC connection exists.

Enter Idle mode in case timer T302 or T314 are not running. T302 is the timer for Cell/URA Update retransmissions.

Enter Idle mode in case timer T302 or T314 are not running. T302 is the timer for Cell/URA Update retransmissions.

Timer T315 expires

Timer T315 expires

No re-establishment for RT services in current release -> T314 is for Tr and UM bearers

Re-establishment timer for NRT services (AM bearers)







RNC receives NBAP:RADIO LINK FAILURE –message

form BTS with a cause value


RNC receives NBAP:RADIO LINK FAILURE –message

form BTS with a cause value






T_L1_Sync_ReEstab_Wait –timer started in

RNC

T_L1_Sync_ReEstab_Wait –timer started in

RNC

T_L1_Sync_ReEstab_Wait –timer expiredT_L1_Sync_ReEstab_Wait –timer expired



• Periods in time where neither "in sync" nor "out of sync" is reported by layer 1 do not affect the evaluation of the number of consecutive (resp. successive) "in sync" or "out of sync" indications

• Longer T313 timer values allow more time for the UE to recover from possible L1 synchronisation problems

• However the longer the timer value is the longer time the resources are left “hanging”

• Values 10 and 20 are tested and value 20 provides better dropped call performance



Contents





Dropped Call Performance-SHO Performance-

• The SHO performance optimisation was done in Nokia test network, Espoo, Finland in the area where there were no coverage problems

• Optimal values derived for the SHO parameters in unloaded (no traffic) network

• In the following slides the results are presented leading to the optimal values in the table below

Parameters Default value Optimal ValueAddition Window (dB) 2 1.5Addition Time (ms) 100 100Drop Window (dB) 4 2.5Drop Time (ms) 640 640Replacement Window (dB) 2 2Replace Time (ms) 100 100Maximum Active Set Size 3 3CPICH Ec/No filter Coefficient 3 3Active Set Weighting Coefficient 0 0

CPICH Ec/No [dB]



• CPICH Ec/No Filter Coefficient:Parameters ValueAddition Window (dB) 2.5Addition Time (ms) 100Drop Window (dB) 4Drop Time (ms) 640Replacement Window (dB) 2Replace Time (ms) 100Maximum Active Set Size 3CPICH Ec/No filter Coefficient 0, 1, 2, 3, 4, 5, 6Active Set Weighting Coefficient 0

-20

-10

0

10

20

30

40

50

60

70

80

90

100

SHO overhead (%) Number of dropped calls Average active set size(RT)

Average time betweenAS updates (s)

UE Power (dBm)

0 (200ms)

2 (400ms)

3 (600ms), default

By comparing the results of different

parameter sets, the default value 3

should be the optimal one---highest SHO

gain, good KPIs and proper SHO overhead.

-20

-10

0

10

20

30

40

50

60

70

80

90

100



UE Power (dBm)

3 (600ms), default

4 (800ms)

5 (1100ms)

6 (1600ms)

By comparing the results of

different parameter sets, the default value 3 should be the optimal one---highest SHO

gain, good KPIs and proper SHO

overhead.

158 © NOKIA Call Performance.PPT / 16-09-2003 /Reunanen JussiCompany Confidential-20

-10

0

10

20

30

40

50

60

70

80

90

100



UE Power (dBm)

240ms

320ms

640ms, default

1280ms

Only the value 640ms can provide an

acceptable KPIs by looking at the

number of dropped calls.

-20

-10

0

10

20

30

40

50

60

70

80

90

100



UE Power (dBm)

60ms

80ms

100ms, default

120ms

160ms

By looking at the No. of dropped calls, only

80ms and 100ms could be acceptable. The SHO overhead

with AddTime= 80ms is too high, so 100ms was selected as the

best one.


Parameters ValueAddition Window (dB) 2.5Addition Time (ms) 60, 80, 100, 120, 160Drop Window (dB) 4Drop Time (ms) 640Replacement Window (dB) 2Replace Time (ms) 100Maximum Active Set Size 3CPICH Ec/No filter Coefficient 3Active Set Weighting Coefficient 0

Parameters ValueAddition Window (dB) 2.5Addition Time (ms) 60Drop Window (dB) 4Drop Time (ms) 120, 240, 320, 640, 1280Replacement Window (dB) 2Replace Time (ms) 100Maximum Active Set Size 3CPICH Ec/No filter Coefficient 3Active Set Weighting Coefficient 0



Parameters ValueAddition Window (dB) 0.5, 1.5, 2.5, 3.5Addition Time (ms) 100Drop Window (dB) 2, 3, 4, 5Drop Time (ms) 640Replacement Window (dB) 2Replace Time (ms) 100Maximum Active Set Size 3CPICH Ec/No filter Coefficient 3Active Set Weighting Coefficient 0

-20

-10

0

10

20

30

40

50

60

70

80

90

100

SHO overhead (%) Number of droppedcalls

Average active set size(RT)


UE Power (dBm)

0.5 / 2 (dB)

1.5 / 3 (dB)

2.5 / 4 (dB), default

3.5 / 5 (dB)

By considering the SHO

overhead, Number of

dropped calls and UE Tx power at the same time,

the parameter set 1.5 /3 is seen as

the best one.

-20

-10

0

10

20

30

40

50

60

70

80

90

100



UE Power (dBm)

1.5 / 2.5 (dB)

1.5 / 3 (dB)

1.5 / 3.5 (dB)

1.5 / 4.5 (dB)

1.5 / 7.5 (dB)

By comparing the SHO

overhead, number of

drop calls and UE Tx power,

the parameter set 1.5/ 2.5 is the best one.

Parameters ValueAddition Window (dB) 1.5Addition Time (ms) 100Drop Window (dB) 2.5, 3, 3.5, 4.5, 7.5Drop Time (ms) 640Replacement Window (dB) 2Replace Time (ms) 100Maximum Active Set Size 3CPICH Ec/No filter Coefficient 3Active Set Weighting Coefficient 0



Parameters ValueAddition Window (dB) 2.5Addition Time (ms) 100Drop Window (dB) 3.5, 4, 4.5, 5.5Drop Time (ms) 640Replacement Window (dB) 2Replace Time (ms) 100Maximum Active Set Size 3CPICH Ec/No filter Coefficient 3Active Set Weighting Coefficient 0

-20

-10

0

10

20

30

40

50

60

70

80

90

100




UE Power (dBm)

2.5 / 3.5 (dB)

2.5 / 4 (dB), default

2.5 / 4.5 (dB)

2.5 / 5.5 (dB)

The tested sets did not show better performance as the set

1.5/ 2.5.

Parameters ValueAddition Window (dB) 1.5Addition Time (ms) 100Drop Window (dB) 3Drop Time (ms) 640Replacement Window (dB) 1, 2Replace Time (ms) 100Maximum Active Set Size 2CPICH Ec/No filter Coefficient 3Active Set Weighting Coefficient 0

-20

-10

0

10

20

30

40

50

60

70

80

90

100


Average time between ASupdates (s)

UE Power (dBm)

1dB

2dB

The value 1 can gives more SHO

gain (lower UE Tx power) and better performance (less number of dropped calls), but the effect is not so significant.



Parameters ValueAddition Window (dB) 1.5Addition Time (ms) 100Drop Window (dB) 3Drop Time (ms) 640Replacement Window (dB) 2Replace Time (ms) 100Maximum Active Set Size 2, 3CPICH Ec/No filter Coefficient 3Active Set Weighting Coefficient 0

-20

-10

0

10

20

30

40

50

60

70

80

90

100




UE Power (dBm)

Max AS size= 2

Max AS size= 3

Max AS size= 2 gives lower SHO

overhead, but the value 3 provides

more SHO gain. No big difference for

the other KPIs. Max AS size= 3 was still

the better one.

Parameters ValueAddition Window (dB) 1.5Addition Time (ms) 100Drop Window (dB) 3Drop Time (ms) 640Replacement Window (dB) 1Replace Time (ms) 100, 640Maximum Active Set Size 2CPICH Ec/No filter Coefficient 3Active Set Weighting Coefficient 0

-20

-10

0

10

20

30

40

50

60

70

80

90

100


Average time between ASupdates (s)

UE Power (dBm)

100ms

640ms

Better performance with 100ms by looking at the

number of dropped calls. But both the parameter have no

big affect to the SHO gain and SHO

overhead



Parameters ValueAddition Window (dB) 1.5Addition Time (ms) 100Drop Window (dB) 3Drop Time (ms) 640Replacement Window (dB) 2Replace Time (ms) 100Maximum Active Set Size 3CPICH Ec/No filter Coefficient 3Active Set Weighting Coefficient 0, 1

Active Set Weighting Coefficient is used to weight either the measurement result of the best active set cell (M_best) or the sum of measurement results of all active set cells (M_sum) when the UE calculates the reporting range for the events 1A and 1B.

The value 1 can give us lower SHO overhead and more gain (lower UE Tx power) at the

same time. But this parameter still need fullly

test.

-20

-10

0

10

20

30

40

50

60

70

80

90

100




UE Power (dBm)

ASWeightingCoeff= 0

ASWeightingCoeff= 1



• Difference in ASU period (measured as time between ASU Complete messages) from two different environments: Case A; HongKong and Case B; Osaka

Time between "ASU complete" messages

0

50

100

150

200

0 -

1

1 -

2

2 -

3

3 -

4

4 -

5

5 -

6

6 -

7

7 -

8

8 -

9

9 -

10

10

- 1

1

11 -

15

15

- 2

0

20

- 2

5

seconds

# o

f e

ve

nts

Measurement 3

Measurement 2

Measurement 1

ASU time

05

1015202530354045

0-1

2 -

3

5 -

10

15

- 2

0

25

- 3

0

35

- 4

0

45

- 5

0

55

- 6

0

65

- 7

0

75

- 8

0

85

- 9

0

95

- 1

00

10

5 -

11

0

11

5 -

12

0

seconds from call setup

# o

f A

SU

s

ASU time

• Case A:• Average time between

Active Set Update is 2-3 seconds which is very small compared to the Case B

• Case B:• Average time between

active set updates is 5-10 seconds

• It can be seen that the smaller cells (a lot of micro cells in Case A and only macros in Case B) shorter the time between ASUs



• ASU period is measured as the time between Active Set Update commands (including both soft and softer HOs)

• For Case A the SHO optimisation must take the ASU period into account as well i.e. necessarily “most” optimised network is not the one with the lowest SHO overhead but combination of ASU period and SHO overhead

• For Case B the SHO optimisation can concentrate on SHO overhead optimisation with the cost of decreased ASU period

• When optimising SHO check also ASU period as the shorter the ASU period is the higher is the signaling load in RNC

• The limit for ASU period is under study!



• ASU period can be measured based on the counters as:

)(M1007C32) TrafficNRTForSHOOnUpdatesSetActiveSuccessful

(M1007C15) TrafficRTForOnSHOUpdatesSetActivesfulsum(succes

)(M1007C19) NRTfor set active in the cell One

(M1001C0) RTfor set active in the cell (One-tmeasuremenoftimeTotal

UpdateASbetweenTimeAvg

• It should be noted that the total time of measurement also includes the times when there are no calls – so this PI value should only be calculated for busy hour when there are a lot of calls

AS size=1

AS update

AS size=2 AS size=3 AS size=2 AS size=1

AS update AS update

AS update

Total Time of Measurement

AS size=1

AS update

AS size=2 AS size=3 AS size=2 AS size=1

AS update AS update

AS update

No calls No calls



• Some of the UEs are suffering from the delayed measurement report sending, which appears to be such that the higher the bit rate is the more late the measurement report is sent by the UE

• Measurement report is not sent even the reporting threshold for e1a or e1c is reached

Ec/No

time

Addition window /Replacement window

Ideal timing for measurement report sending after e.g. Addition time

measurement report sent : AMR

measurement report sent : PS 64 or UDI (CS T64)

measurement report sent : PS 384

• This kind of UE behavior cannot be completely fixed but results can be improved by adjusting:

• Addition window • Addition time• Replacement window• Replacement time


Plotted Data [ Line(6501 to 7000); Time(11:34:34 to 11:35:38) ]

-120

-100

-80

-60

-40

-20

0

20

40

60

80

100

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

21

[A]

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

21

[A]

N/A

21

[A]

N/A

N/A

N/A

21

[A]

N/A

N/A

N/A

0[A

]

N/A

N/A

N/A

N/A

N/A

N/A

-30

-25

-20

-15

-10

-5

0

5

10

EcN

o/A

SS

CpichRscp Sir TargetSir UeTxPower HOIndication DpchRscp DlTransportChannelBler_1 CpichEcNO ActiveSetSize


There is no response to measurement report e1c –messages by the network as the first measurement report is sent “too late” by the UE and the call drops

Time Message Monitored Set SC / Ec/No [dB]

Active Set SC / Ec/No [dB]

11:35:20 Measurement Control

11:35:20 188 / -8.5 35 / -13.5

309 / -9.5 97 / -18.5

11:35:21 188 / -3.5 35 / -8.5

309 / -11.5 97 / -23.5

11:35:22 188 / -5.5 35 / -10.5

309 / -12.5 97 / -23.5

Measurement Report e1c: SC188, SC35, SC309, SC97

SC188 = -5.5 SC35 = -10.5

SC309 = -12.5 SC97 = -23.5

11:35:22 188 / -5.5 35 / -11.5

309 / -19.5 97 / <-24

11:35:23 188 / -5.5 35 / -14.5

309 / -21.5 97 / <-24

Measurement Report e1c: SC188, SC35, SC309, SC97

UE seem to have parallel processes ongoing I.e. measurement control and therefore there is 2sec. delay in sending the measurement report

UE seem to have parallel processes ongoing I.e. measurement control and therefore there is 2sec. delay in sending the measurement report



• Some of the UEs are suffering from the low PS performance (in terms of throughput)

• While the bearer bit rate increases the throughput performance during SHO performance -> the only way to fix this is to reduce the max. active set size for PS data to e.g. 2

Low variance of SIR, ASS=2, stable BLER and throughput

High BLER, high variance with DL SIR and a lot of SHO activity

Poor performance due to coverage


Dropped Call Performance-SHO Performance: UL Interference-

• Cell B is having higher PrxNoise level than Cell A which is causing the UL and DL coverage to be very much different.




Cell A Cell B

• It should be noted that even tough the AC is disabled by high enough PrxTarget and PrxOffset parameters or PrxNoise autotuning feature and calls can be set up under this cell, successful SHOs become practically impossible between this kind of cell and “normally” operating cell

• This is due to that the UE Tx power is controlled by the original cell (Cell A) and therefore there is not enough power from UE to overcome the UL Noise rise in Cell A





Ec/No

distance


UE -> RNC : Measurement report : e1a / e1c

Active Set Update: 1a, 1c to add cell B

Active Set Update complete

Addition/ Replacement time

UL

UL & DL

Cell A Cell B

RNCBTS

RRC: Active Set Update

Decision to set up new RL

RRC: Measurement Report (e1a / e1c)

NBAP: Radio Link Setup Request

NBAP: Radio Link Setup Response

Start TX/RX

ALCAP:ERQ

ALCAP:ECF

RRC: Active Set Update Complete

UE

UL Synchronisation Procedure starts

UE Synchronisation Procedure starts: According to Synchronisation Procedure B

DL

NB

AP: S

ynch

roniza

tion

Ind

icatio

n• As the UE Tx power is not enough for

Cell B synchronisation, the SHO can fail







Measurement report e1A: CellB

Measurement report e1A: CellB



RNC does not receive synchronization indication -> timer T_RRC_RRC_Resp_DCH

RNC does not receive synchronization indication -> timer T_RRC_RRC_Resp_DCH


DELETION –message


DELETION –message

SHO Decision algorithm Cell B -> Setup RL -> NBAP: Radio Link Setup Request (Chip Offset)

SHO Decision algorithm Cell B -> Setup RL -> NBAP: Radio Link Setup Request (Chip Offset)

Successful resource allocation in Cell B BTS -> BTS Starts Tx (DPCH) -> BTS Starts UL

Synchronization procedure and sends NBAP: Radio Link Setup Response

Successful resource allocation in Cell B BTS -> BTS Starts Tx (DPCH) -> BTS Starts UL

Synchronization procedure and sends NBAP: Radio Link Setup Response

RNC sends RRC: Active Set Update - message to UE -> Starts timer

T_RRC_Resp_DCH

RNC sends RRC: Active Set Update - message to UE -> Starts timer

T_RRC_Resp_DCH

BTS UL Synchronization procedure continues until L1 Synchronization is achieved

or NBAP: RL Deletion –message is received

BTS UL Synchronization procedure continues until L1 Synchronization is achieved

or NBAP: RL Deletion –message is received

BTS stops UL Synchronization

procedure and Tx

BTS stops UL Synchronization

procedure and Tx



Cell A Cell B

After receiving ASU UE Starts DL Synchronization procedure -> and sends ASU Complete

After receiving ASU UE Starts DL Synchronization procedure -> and sends ASU Complete

UE starts T313 for Cell B after receiving N313 out-of-sync for Cell B

UE starts T313 for Cell B after receiving N313 out-of-sync for Cell B

T313 expires -> UE considers Radio Link Failure for Cell B -> UE drops the Cell B from AS

T313 expires -> UE considers Radio Link Failure for Cell B -> UE drops the Cell B from AS

Counter: RL DEL ON SRNC DUE TO

INI SYN FAIL (M1005C67) -

updated



• The ways to fix this case are:• Use CPICH Tx power in the BTS to balance the

UL and DL coverage i.e. decrease the CPICH Tx power by the UL noise rise

+ Can be done cell by cell basis+ Relatively easy to implement algorithm for

autotuning- Coverage is reduced also in the cases

when there is no UL interference- Requires autotuning feature otherwise cell

coverage is reduced in DL all the time• Use cell individual offset to lower the CPICH

Ec/No by the noise rise value+ Can be done cell by cell basis+ Does not affect to the coverage - Needs some algorithm to tune the cell

individual offset according to existing noise rise

- The UEs might have problem with too big difference between actual CPICH powers also DL power drifting might cause problems



Ec/No

distance





L1 synchronization not achieved between new cell and UE, monitored by the BTS


ULDL

DLUL & DL

Cell A Cell B

RNC sends Active Set Update : e1b to remove the cell A

Drop window



• The ways to fix this cases are:• Increase the Drop window setting so that UL

synchronization is achieved to the target cell- New drop window is used for each neighbor

cell definition- Needs some algorithm to tune the drop

window according to existing noise rise and cell by cell basis somehow

+ Easy to test to see if situation can be improved


• Change the drop timer to be long enough so that UL synchronization is achieved to the target cell

- New drop time is used for each neighbor cell definition

- Needs some algorithm to tune the drop time according to existing noise rise and cell by cell basis somehow

- Easy to test to see if situation can be improved




Ec/No

distance





L1 synchronization not achieved between new cell and UE, monitored by the BTS


ULDL

DLUL & DL

Cell A Cell B

RNC sends Active Set Update : e1b to remove the cell A

Drop window


• In case there is so called round the corner effect between two cells it might be tempting to use cell individual offsets to make the SHO to happen earlier and therefore have the connection on without dropped calls

Ec/No

routeAddition window /Replacement window


UL & DL

Cell A


Cell B

Dropped Call Performance-SHO Performance : Cell Individual Offsets-

Cell B

Cell A

UL & DL

The call drops due to too rapid CPICH coverage degradation for Cell A, and therefore there is not enough time for SHO

Without cell individual offsets


• By using cell individual offset this problem might be overcome

• However now we have different problem i.e. better DL coverage than UL coverage

• Better is to try to tune time to trigger (i.e. Addition / Replacement time need to be shortened)

Ec/No

routeAddition window /Replacement window


UL & DL

Cell A


Cell B

Dropped Call Performance-SHO Performance : Cell Individual Offsets-

Cell B

Cell A

ULWith cell individual offsets DL



• See next case

Cell individual offset


• In case there is a cell with lower CPICH power than the surrounding cells’ are having then this cell is having “too good” UL performance as this cells’ UL cannot be used efficiently due to SHO is decided upon DL (CPICH Ec/No)

• To improve this and include the cell into AS earlier than CPICH Eke/No would allow, it is possible to use cell individual offsets for this purpose


Cell having lower DL coverage = DL (CPICH) power is lower than adjacent cells

Ec/No

distanceAddition window /Replacement window




DL

ULUL & DL

Cell A


Cell B starts to suffer from UL interference due to UE getting closer to Cell B wo SHO

Cell B

Dropped Call Performance-DL Coverage < UL Coverage-


• If Cell B is having cell individual offset set according to the difference of CPICH powers between Cell A and Cell B, the SHO can happen “correct” time and Cell B can be utilized fully

• However currently the added cell’s initial Tx power is set according to the existing cell i.e.

• In case the best cell Ec/No is known




Ec/No





DL

ULUL & DL

Cell A


Cell B

),,( tx_totalcinittx, PILW

RMAX

P pTFCTF

TFCSTFC

tx_total.CPICHtx,c

tx_totalc1

),( PPPILP


• However currently the added cell’s initial Tx power is set according to the existing cell i.e.

• In case the best cell Ec/No is not known

• It should be noted that neither of the formulas include information about the cell individual offset and due to that the SHO to cell, which is having cell individual offset (“high” value), might have problems

• Synchronization in DL direction difficult




Ec/No





DL

ULUL & DL

Cell A


Cell B

highestCPICHtxnewCPICHtxhighestavetxnewinitialtx PPPP ,,,,,,,,

Cell individual offset

Tx power for the Cell B DPCH is not enough -> DL synch not achieved -> SHO failure


RNCRNCBTSBTS


Decision toset up new RL



NBAP: Radio Link Setup Request – for Soft Handover



ALCAP:ERQ

ALCAP:ECF


UEUE

Dropped Call Performance-SHO Performance : PIs-

Received message RRC: Measurement Report (e1A). Triggers for RT: M1007C10 CELL ADDITION REQUEST ON SHO FOR RT TRAFFICReceived message RRC: Measurement Report (e1B). Triggers for RT: M1007C11 CELL DELETION REQUEST ON SHO FOR RT TRAFFICReceived message RRC: Measurement Report (e1C). Triggers for RT: M1007C12 CELL REPLACEMENT REQUEST ON SHO FOR RT TRAFFICReceived message RRC: Measurement Report (e1A). Triggers for NRT: M1007C27 CELL ADDITION REQUEST ON SHO FOR NRT TRAFFICReceived message RRC: Measurement Report (e1B). Triggers for NRT: M1007C28 CELL DELETION REQUEST ON SHO FOR NRT TRAFFICReceived message RRC: Measurement Report (e1C). Triggers for NRT: M1007C29 CELL REPLACEMENT REQUEST ON SHO FOR NRT TRAFFIC

For each cell already in AS the above counters are updated i.e. in this case 2 cells

A

B

At first (UE in point A) AS includes 2 cells Then UE moves to point B and reports e1A to add “blue” cell

NBAP: Radio Link Setup Request – for Soft Handover

NBAP: Radio Link Addition Request – for Softer Handover

NBAP: Radio Link Addition Response


Dropped Call Performance-SHO Performance: PIs-

RNCRNCBTSBTS


Decision to set up new RLDecision to set up new RL





ALCAP:ERQ

ALCAP:ECF


UEUE


UE Synchronisation Procedure starts: According to Synchronization Procedure B

NB

AP: S

ynch

roniza

tion

Indica

tion

Number of DCH requests for Diversity HO (SHO) for voice calls in SRNCM1002C16 RT DCH DHO REQ FOR CS VOICE CALL IN SRNCNumber of DCH requests for a CS Voice Call rejected by the SRNC for reasons caused by radio resources in the target cell of diversity handoverM1002C17 RT DCH DHO REQ FOR CS VOICE CALL REJECT IN SRNCNumber of DCH requests for a transparent CS Data Call with conversational class due to diversity handover in the SRNCM1002C58 RT DCH DHO REQ FOR CS DATA CALL CONV CLASS IN SRNCNumber of DCH requests for a transparent CS Data Call (on SRNC side) rejected for reasons caused by radio resources in the target cell of diversity handoverM1002C59 RT DCH DHO REQ FOR CS DATA CALL CONV CLASS REJECT IN SRNCSRNC A total number of DCH requests for a nontransparent CS Data Call with streaming class due to diversity handover in the SRNCM1002C60 RT DCH DHO REQ FOR CS DATA CALL STREAM CLASS INNumber of DCH requests for a nontransparent CS Data Call with streaming class (SRNC side) rejected for reasons caused by radio resources in the target cell of diversity handoverM1002C61RT DCH DHO REQ FOR CS DATA CALL STREAM CLASS REJECT IN SRNCSAME FOR DRNC!In case of RNC sends to BTS NBAP: RL Setup

Request/RL Addition RequestM1005C1: RL SETUP ATT FOR SHO ON SRNCM1005C3:RL SETUP ATT FOR SHO ON DRNCM1005C42: RL BRANCH ADD ATT FOR SHO ON SRNCM1005C43: RL BRANCH ADD ATT FOR SHO ON DRNC

In case BTS responses back to RNC by NBAP: RL Setup Response/RL Addition ResponseM1005C6: RL SETUP SUCC FOR SHO ON SRNCM1005C8:RL SETUP SUCC FOR SHO ON DRNCM1005C44: RL BRANCH ADD SUCC FOR SHO ON SRNCM1005C45: RL BRANCH ADD SUCC FOR SHO ON SRNC


RNCRNCBTSBTS








ALCAP:ERQ

ALCAP:ECF


UEUE


Received message RRC: Active Set Update Complete. Triggers: M1007C15 SUCCESSFUL ACTIVE SET UPDATES ON SHO FOR RT TRAFFICReceived message RRC: Active Set Update Complete. Triggers: M1007C32 SUCCESSFUL ACTIVE SET UPDATES ON SHO FOR NRT TRAFFIC

For each cell in the AS the above counter(s) are updated (including the cell to be deleted from AS in case of e1B)

RRC: Active Set Update Failure

Received message RRC: Active Set Update Failure. Triggers: M1007C16 UNSUCCESSFUL ACTIVE SET UPDATES ON SHO FOR RT TRAFFICReceived message RRC: Active Set Update Failure. Triggers: M1007C33 UNSUCCESSFUL ACTIVE SET UPDATES ON SHO FOR NRT TRAFFIC



1

2

A

UE is in Spot A i.e. not in soft handover -> AS size = 1

UE in Spot B sends Measurement report indicating e1A to add cell 2 -> M1007C10 CELL ADDITION REQUEST ON SHO FOR RT TRAFFIC is updated in cell 1

RNCRNCBTSBTS

RRC: Measurement Report (e1a / e1c)UEUE

1

2B


RNC sends NBAP: RL Setup Request to BTS – updates M1005C1: RL SETUP ATT FOR SHO ON SRNC counter in cell 2

RNC Makes AC/RM for the SHO – updates M1002C16 RT DCH DHO REQ FOR CS VOICE CALL IN SRNC counter in cell 2

Decision to set up new RLDecision to set up new RL


ALCAP:ERQ

ALCAP:ECF


BTS receives the NBAP; RL Setup Request, if RL Setup Is successful, starts TX/RX and UL Synchronization procedure and sends NBAP: RL Setup Response to RNC





RNC Sends RRC: Active Set Update –message to the UE

1

2B

When receiving RRC: Active Set Update Complete, the RNC updates M1007C15 SUCCESSFUL ACTIVE SET UPDATES ON SHO FOR RT TRAFFIC or M1007C32 SUCCESSFUL ACTIVE SET UPDATES ON SHO FOR NRT TRAFFIC counter. Counter updated for cell 1.

RNCRNCBTSBTS


NBAP: Radio Link Setup RequestDecision to set up new RLDecision to set up new RL


ALCAP:ERQ

ALCAP:ECF

UL Synchronisation Procedure startsStart TX/RXStart TX/RX


After receiving RRC: Active Set Update from RNC the UE checks the Update message and if ok UE starts Synchronization Procedure B and and sends RRC: Active Set Update Complete message without waiting for the completion of the Physical Layer synchronization procedure B (according to 25.214/25.331)




• The Active Set Update success rate can be calculated as:

%

))161007(

)151007((

))151007((*100)(

CMTrafficRTForSHOOnUpdatesSetActiveulUnsuccessf

CMTrafficRTForSHOOnUpdatesSetActiveSuccessfulsum

CMTrafficRTForSHOOnUpdatesSetActiveSuccessfulsumRTRatioSuccessUpdateSetActive

• Formula does not take into account the cases where measurement report is sent several times until RNC responds with RRC: Active Set Update -> Counters1007C16 and 1007C33 are updated only in case UE responds to Active Set Update –message with Active Set Update Failure –message.

%

))331007(

)321007((

))321007((*100)(

CMTrafficNRTForSHOOnUpdatesSetActiveulUnsuccessf

CMTrafficNRTForSHOOnUpdatesSetActiveSuccessfulsum

CMTrafficNRTForSHOOnUpdatesSetActiveSuccessfulsumNRTRatioSuccessUpdateSetActive


RNCRNCBTSBTS




ALCAP:ERQ

ALCAP:ECF




11



• Therefore also the amount of periodical measurement reports must be checked i.e. :

• CELL ADDITION FAILURE ON SHO FOR RT TRAFFIC M1007C13

• CELL REPLACEMENT FAILURE ON SHO FOR RT TRAFFIC M1007C14

• CELL ADDITION FAILURE ON SHO FOR NRT TRAFFIC M1007C30

• CELL REPLACEMENT FAILURE ON SHO FOR NRT TRAFFIC M1007C31

• It should be noted that the counters M1007C13, M1007C14, M1007C30 and M1007C31 are all updated for each cell in the AS




RNCRNCBTSBTS




ALCAP:ERQ

ALCAP:ECF




• In case also RL Setup Procedure and AC decision are needed to be included then the SHO Success Rate could be counted as:

• (M1007C15)/(M1007C10 + M1007C11 + M1007C12) – for RT traffic• (M1007C32)/(M1007C27 + M1007C28 + M1007C29) – for NRT traffic

• SUCCESSFUL ACTIVE SET UPDATES ON SHO FOR RT TRAFFIC (M1007C15) divided by ADDITION/DELETION/REPLACEMENT REQUEST ON SHO FOR RT TRAFFIC (M1007C10 + M1007C11 + M1007C12)

22

%M1005C8M1005C6M1005C45M1005C44

M1005C3M1005C1 M1005C43 M1005C42*100

)(/

SHOSuccessAdditionUpSetLinkRadio

• And separate failure reasons can be identified based on M1005C16 – M1005C21, M1005C28 – M1005C33, M1005C46 – M1005C57 and M1005C58 – M1005C65

• Then in case the SHO Success Rate formula 1 and 2 are giving different results the problem spot can be identified by analysing:

• Iub Radio Link Set up & Addition success rate (either combined as below or separately)




RNCRNCBTSBTS




ALCAP:ERQ

ALCAP:ECF




%100M1002C108M1002C106M1002C104M1002C102M1002C60M1002C58M1002C16

10910021071002105100210310026110025910021710021

)(

CMCMCMCMCMCMCM

SHOSuccessAllocationDCH

• Then in case the SHO Success Rate formula 1 and 2 are giving different results the problem spot can be identified by analysing:

• DCH allocation successrate for SHO purposes

• Where nominator is stating the number of DCH allocation requests in the target cell for Diversity Handover (SHO) for RT traffic classes (Speech+Conversational CS data + Streaming CS Data) and NRT traffic classes (Conversational PS data + Streaming PS data + Interactive PS data + Background PS data)

• Where denominator is the allocation rejections due to lack of radio resources in target cell


Dropped Call Performance-SHO Performance and AC-

• When an event 1A or 1C is received, the radio load conditions in the candidate cell are evaluated by Admission Control

• Failure to add or replace a link can occur for the same reasons as for an initial RRC Connection or RAB Setup (except that the UL interference is not to checked as the UE transmission is already included in UL noise rise)

• DL Transmit Power• Transmission


Dropped Call Performance-SHO Performance : Questions-

• In case ASU period needs to be taken into account as well then what would be the optimal set?

• What are the difficulties in the SHO failure KPIs? And what is your recommendation for SHO failure PI?

• What would be your suggestion to handle the indoor <-> outdoor SHO assuming that the indoor solution is:

• AIR with 13dBm TX power• DAS with 43dBm TX power


Contents





Dropped Call Performance-Power per Connection-

Ec EcIo Sir TargetSir ActiveSetSize DlTrChBler

-120

-100

-80

-60

-40

-20

0

20

40

15:4

5:08

.00

15:4

5:08

.00

15:4

5:09

.00

15:4

5:10

.00

15:4

5:10

.00

15:4

5:11

.00

15:4

5:12

.00

15:4

5:13

.00

15:4

5:14

.00

15:4

5:15

.00

15:4

5:15

.00

15:4

5:16

.00

15:4

5:16

.00

0

10

20

30

40

50

60

70

80

90

100

DLTrchBLER increase rapidly

Call drop

e1b, 1 active set cell dropped (become 1-way active)

• Observations from the case on the right:

• 1. SIR cannot be maintained at the correct level

• 2. Ec/No is ok• 3. BLER Increases to 100%• 4. Target SIR increases at the same

time as BLER increases to 100%

1.

2.

3.

4.

• As the SIR getting lower and lower until the call drops this suggests that the DL power has reached its maximum

• This case can be improved by allowing more power window in DL for the PC to operate



• DL power per connection can be increased by changing the parameter CPICHtoRefRabOffset

• the max DL TX power is determined by AC as:

DL tx pwr perConnection [dBm]/ BLER [%]

time

),( max__,max,max, DPCHtxdpchreftxefftx PNPRIMINP refref

eff RI

RIRI

max

max,fRabOffsetpichTo

CPICHtxreftx C

PP

Re

,,

Call drop

Maxpower

Minpower

DL tx pwr perConnection [dBm]/ BLER [%]

time

Maxpower

Minpower



• When increasing the max power per connection (putting CPICHtoRefRabOffset parameter lower) it should be noted that the AC limit might be reached quite fast:

• CPICHtoRefRabOffset = 0dB• 128kbps service with Eb/No = 4.5dB• Reference service AMR 12.2kbps with Eb/No = 8dB• PtxCPICH = 33dBm• Ptx_DPCH_max = -3dB (=40dBm = 10W)

• => Ptx,ref = 33dBm – (0dB) = 33dBm• => Rimax,eff = (4.5dB*128kbps)/(8dB*12.2kbps) = 4.6865• => Ptx_Max = 9.35W

• In case the PtxTarget is set to 40dBm then in case there is even one more connection up and running the possibility that the PtxTarget value is exceeded during the new 128kbps connection admission control procedure and therefore it is denied

• Therefore CPICHtoRefRABOffset should be tuned with PtxCPICH and PtxTarget



• Another point to take into account is that the when the maximum power per connection is increased also the minimum power limit is increased (as the min power is max power – PCrangeDL (15dB))

• In case the max power increment is a lot (~3dB) then the minimum power is increased by 3dB as well which can lead to the minimum power problems (BTS sending too much power to the UEs close to the BTS and therefore causing problems to the UE and even dropped call)

• Therefore the PCrangeDL parameter should be tuned according to the CPICHtoRefRabOffset parameter tuning (from the default)


Contents





PS Call Performance• Test case was performed with RAN 1.5.2 software level

• DL Power Control was enabled in the mobile terminal

• Kenny SW version P 1.2-12.55

• 64 UL/64 DL kbps bearer services were used as per the following profiles

QOS PROFILE INDEX & BLER target 123; 0.63% 123;1% 123; 5% 123; 20%

QOS PROFILE NAME BLER 0.63 BLER 1 BLER 5 BLER 20

TRAFFIC CLASS B B B B

DELIVERY ORDER N N N N

DELIVERY OF ERRONEOUS SDU ND N ND ND

MAXIMUM SDU SIZE 1500 1500 1500 1500

MAXIMUM BIT RATE FOR DOWNLINK 64kbps 64 64 64

MAXIMUM BIT RATE FOR UPLINK 64kbps 64 64 64

RESIDUAL BER 9* 7* 7* 1*

SDU ERROR RATIO 7** 4** 4** 1**

TRANSFER DELAY

GUARANTEED BIT RATE FOR UPLINK

GUARANTEED BIT RATE FOR DOWNLINK

TRAFFIC HANDLING PRIORITY


PS Call PerformanceBLER versus avg. RTT for different ping sizes using 64 kbps

bearer

0

100

200

300

400

500

600

700

800

900

0 5 10 15 20 25

BLER %

RT

T i

n m

illi

se

con

ds

32 bytes

512 bytes

1472 bytes


PS Call Performance

Avg. Round Trip Times for different ping sizes at various BLER using 64kbps bearer

0

100

200

300

400

500

600

700

800

900

0 200 400 600 800 1000 1200 1400 1600

Ping Size in bytes

De

lay

in m

illi s

ec

on

ds

0.63% BLER

1% BLER

5% BLER

20% BLER


BLER versus Average FTP Upload Throughputs for various file sizes using 64kbps bearer

0

10

20

30

40

50

60

0 5 10 15 20 25

BLER %

Thro

ughp

ut in

Kbi

t/s

16KB

64KB

500KB

1024KB

PS Call Performance


FTP Upload Throughputs at different BLER & file sizes using 64kbps bearer

0

10

20

30

40

50

60

0 200 400 600 800 1000 1200

File sizes in kilo bytes

Th

rou

gh

pu

t in

kb

it/s

0.63% BLER

1% BLER

5% BLER

20% BLER

PS Call Performance


Ping Size 32 bytes 512 bytes 1472 bytes

0.63% 11ms 22ms 37ms

1% 25ms 36ms 42ms

5% 86ms 98ms 114ms

20% 172ms 214ms 144ms

BLER %

• Standard deviations in the Round Trip Times (milliseconds) for each ping size at a certain BLER level

PS Call Performance


0.63 % BLER 1 % BLER

1MB 1 % BLER

UL # Total bytes Re-xmt bytes Re-xmt %1 1048404 0 0,0 %2 1048404 0 0,0 %3 1048404 0 0,0 %

DL # Total bytes Re-xmt bytes Re-xmt %1 1048404 0 0,0 %2 1048404 0 0,0 %3 1048404 0 0,0 %

1MB 0.63 % BLER



5 % BLER

1MB 5 % BLER



20 % BLER

1MB 20 % BLER



PS Call Performance


PS Call Performance-Conclusions-

• A low BLER provides a much better PS performance• Lower RTT• Higher throughput

• On the other hand, a low BLER can reduce the PS capacity• Higher transmit power• Higher interference

• In the short term, low BLER is an acceptable solution

• In the middle-long term, BLER could be tuned to balance QoS and capacity


References

• Jphone project experiences – NWP Team in Japan

• H3G project experiences – NWP Team in HK & UK

• Measurements in Nokia WCDMA Test Network, RAN1.5.2 SW, February-March 2003: Soft Handover Optimised Performance - Huibin Lin, Marja-Leena Lahti

• 3G Packet Data Performance Measurements Analysis: BLER test cases - Anand Shah, Karl Tigerstedt, Octavio Garcia, Baris Sarer

• SERVICE LEVEL MEASUREMENT in WCDMA RAN 1.5 and REPORTS in OSS Reporter – Juho Pirskanen & Tapio Toppari

• RNC Performance Counters - DN99581291 Issue 2-4 en

• All SFSs

call performance

Documents