WRST 4 Module Three: WRST 4 Jussi Reunanen & Benoist Guillard & Supranee Sarinkarnpoonperm

WRST 4
Module Three
Call Performance
WRST 4
Jussi Reunanen
&
Benoist Guillard
&
Supranee Sarinkarnpoonperm
1 © NOKIA Call Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential

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)
UE Sends First RNC responds with RRC
RRC Connection Setup message which
CPICH Ec/No Connection is not heard by the UE due to CPICH Ec/No
CPICH RSCP Request CPICH Ec/No falls below –15dB CPICH RSCP
Message
UE does not start RF Conditions
the cell reselection OK and CPICH
procedure if default Ec/No is –10dB
parameter settings
are used
-10dB
-100dB -15dB
Time
Cell A Cell B
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
UE moving from Cell A towards Cell B

• 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)

• Default parameter settings
UE starts the neighboring

CPICH Ec/No cell measurements here CPICH Ec/No
and it takes some time to
CPICH RSCP perform the reselection
CPICH RSCP
UE “hangs” in CELL A until

QqualMin+Sintrasearch = -
16dB threshold is reached.
However at this level the
RRC Connection Setup is Cell Reselection Qhyst2= -16dB + 4dB = -12dB
probably not heard by the UE
any more or the BTS does QqualMin+Sintrasearch
not hear the RRC Connection =-20dB + 4dB = -16dB
Request QqualMin = -20dB
Time
Cell A Cell B
• 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)
CPICH RSCP CPICH Ec/No

Recommended area
Calls setups very successful
Calls setups ok
QqualMin+Sintrasearch+
Calls setups difficult Qhyst2= -16dB + 4dB
= -12dB
Calls setups failures
QqualMin+Sintrasearch
QqualMin = -20dB =-20dB + 4dB = -16dB
Time
• 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
More time to select and
Cell reselection happens
monitor a better cell
here where cell B is about
–8 dB and Cell A is about –
CPICH Ec/No 12 dB
CPICH Ec/No
CPICH RSCP CPICH RSCP
Qhyst2 = -8dB + 4dB =
-4dB
UE starts the neighboring
cell measurements near
earlier than at cell edge Worst case scenario
QqualMin+Sintrasearch
=-20dB + 12dB = -8dB
QqualMin = -20dB
Time
Cell A Cell B
• 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
• With optimised parameter settings:
CPICH RSCP CPICH Ec/No
Recommended area
Calls setups very successful

Qhyst2 = 4dB QqualMin+Sintrasearch
Calls setups ok =-20dB + 12dB = -8dB
Calls setups difficult
Calls setups failures

QqualMin = -20dB
Time
• 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
-Idle Mode Cell Reselection : Effect-
• There is significant improvement

Idle mode param.
AMR performance
Sintrasearch = 10dB in performance after due to
set as defaults Treselection = 0s changing of the idle mode cell
reselection parameters
BLER, Call drop rate, MOC CSSR, MTC CSSR
New CD
• 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
Time in Days
Setup the paging timer in
BLER rate Call drop rate
MSC could be expired and
MOC setup failure rate MTC setup failure rate therefore causing failed call
attempts

All Call Attempts Test 1 • From the charts on the left it can be seen that
-2 from all the RRC Connection Request messages
-4 only a few are done in the worse than CPICH
-6
Ec/No = -15dB situation
CPICH Ec/No [dB]
• CPICH Ec/No = -15dB can be considered as

-8 some sort of UE performance limit
-10
-12
• In this case the Sintraseacrh setting seems to be
-14 ok (10dB)
-16
-18
-2
All Call Attempts Test 2 -2
-4 -4
-6 -6
CPICH Ec/No [dB]
CPICH Ec/No [dB]

-8 -8
-10 -10
-12 -12
-14 -14
-16 -16
-18 -18
-20 -20
-22 -22
-24 -24
11 © NOKIA Call Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential Call Setup Failures
• 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:
Parameter Default Case4 Case5

Sintrasearch 12dB 12dB 12dB
Qhyst2 4dB 4dB 0dB
Treselect 0sec 2sec 0sec
• Tests were done with Sanyo UE (3.23)

Idle mode (Stationary test)

Low Coverage Med. Coverage
Parameter set
CPICH RSCP CPICH Ec/No CPICH RSCP CPICH Ec/No
Default -81.2 -9.04 -75.06 -5.16
Case4 -78.83 -7.51 -76.42 -6.5
Case5 -77.47 -7.39 -74.21 -4.03
Idle mode (Drive test)

Parameter set CPICH RSCP CPICH Ec/No
Default -75.41 -5.45
Case4 -76.11 -5.89
Case5 -75.98 -6.03
AMR MOC (Stationary test)

Low Coverage Med. Coverage
Parameter set
# of call attempts Setup success CPICH RSCP CPICH Ec/No # of call attempts Setup success
Default 100 82 -91.63 -6.74 100 93
Case4 100 83 -92.18 -6.18 100 97
Case5 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%

• 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 change
Call Setup Success Rate

AMR MOC
Parameter set # of call attempts Setup success Setup success rate
Default 572 473 82.7% 100.0%
CR Case5 854 765 89.6% 95.0%
90.0%
85.0%
AMR MTC 80.0%
75.0%
Parameter set # of call attempts Setup success Setup success rate 70.0%
Success rate
Default 484 412 85.1% 65.0%
60.0% Default
CR Case5 333 286 85.9% 55.0%
50.0% Case5
45.0%
UDI MOC 40.0%
35.0%
Default 320 262 81.9% 25.0%
20.0%
CR Case5 647 557 86.1% 15.0%
10.0%
5.0%
0.0%
Services

-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
• Paging
• UL Interference


-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-)

-Paging : PIs-
• Paging for UEs in IDLE state
UE BS RNC CN
UE has no RRC connection CN (RANAP: PAGING Message received
RANAP: PAGING from CN = UE in idle mode) originated
1 PICH
paging amount: When RNC sends Paging
Type 1
(FP/AAL2/PCCH/PCH/S-CCPCH) : PAGING TYPE 1 M1006C25 PAGING TYPE 1 ATT CN ORIG
A number of RNC originated paging type 1
RRC connection establishment
attempts (UE in PCH/URA substate): When
Paging response RNC sends Paging Type 1
M1006C26 PAGING TYPE 1 ATT RNC
ORIG
• Paging for UEs in CELL_PCH or URA_PCH UE RNC SGSN
The MAC-d (RLC) in

states
2 MM MM Idle 3 RNC indicates that
1.PDP PDU
there is downlink user
UE BS RNC Connected
CN 1 CN 2 data in RLC buffers
then the RRC signaling
UE has signalling connection to CN1 entity initiates the
paging procedure
2. Paging Request (P-TMSI)
UE is in URA_PCH or CELL_PCH state
RANAP:PAGING RRC: PAGING TYPE 1 with PICH BTS -> UE
PICH
MM Cell
(FP/AAL2/PCCH/PCH/S-CCPCH) : PAGING TYPE 1
Update
Paging response to CN 2
A number of paging messages received
from the CN
M1003C36 REC PAG MSG

-Paging : PIs-
• Paging for UEs in CELL_FACH or CELL_DCH

states MM Connected MM Idle
A number of paging messages received
UE 4 BS RNC CN 1 CN 2 from the CN
M1003C36 REC PAG MSG
UE has signalling connection to CN1
UE is in CELL_FACH or CELL_DCH state RANAP:PAGING

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

-Paging : PIs-
Paging Success Rate
1001C32MT CConv Att  1001C34MT CStream Att  1001C36MT CInterAtt  1001C38MT CBackg Att  1006C37Cell UpdateAtt Due to PaingResp

1003C36ReceivedPaging Messages
• 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

-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
• Paging
• UL Interference


-RRC Connection Establishment-
UE Node B RNC • The power level for sending of the RRC Connection
[RACH] RRC:RRC Connection Request
Request –message is set/calculated by the UE
NBAP: RL Setup Request • Uplink open loop PC take place at the random access
NBAP: RL Setup Response
procedure:
ALCAP:ERQ
• UE measures the received power of the CPICH
which reported back in "measured results on
ALCAP:ECF
RACH" IE in: initial direct transfer (UTRAN must
[FACH] RRC: RRC Connection Setup
extract this IE from the NAS message), cell update
L1 Synchronisation / ura update, measurement report (UL traffic
NBAP: Synchronisation Indication
volume measurement report), RRC connection
[DCH] RRC: RRC Connection Setup Complete request, uplink direct transfer (UTRAN must
extract this IE from the NAS message)
• 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
• If no acquisition indicator is received UE raises the
UE Node B RNC
transmission power by
[RACH] RRC:RRC Connection Request PowerRampStepPRACHpreamble which is a
NBAP: RL Setup Request broadcast parameter
• This procedure is repeated until acquisition
ALCAP:ERQ
indicator is received, after which UE sends the
RACH message at power which offset by
ALCAP:ECF
PowerOffsetLastPreamblePRACHmessage
[FACH] RRC: RRC Connection Setup from the last preamble
L1 ACK / AICH
• PRACH_preamble_retrans parameter
determines how many times PRACH Not detected
preamble can be sent (without AICH Downlink
response) within one preamble ramping BS
cycle (SIB5&6)
• RACH_tx_Max defines how many times P2
the PRACH pre-amble ramping cycle Uplink P1
procedure can be repeated before UE MS Preamble Preamble Message part
MAC reports a failure on RACH 1 2
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

-RRC Connection Establishment – Logging CPICH Ec/No-
CPICH Ec/No as in RRC Connection Setup Request Results missing
-20 -18 -16 -14 -12 -10 -8 -6 -4 -2 0
• For Filtering purposes it is
0
CPICH Ec/No as reported by fingers

good to have Ec/No
-2 recorded when the RRC
-4 Connection Setup is sent
-6 • Whether the reading is
-8 done from the Finger data
or from the RRC
-10 Connection Setup –
-12 message needs to decided
-14
-16
-18
• 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)

-RRC Connection Establishment –CPICH Ec/No / RSCP vs. UE Tx
UE Tx Power [dBm]
Power-
-40 -35 -30 -25 -20 -15 -10 -5 0 5 10 15 20 25 • For failed calls the UE Tx vs. CPICH
-40 Ec/No and CPICH RSCP should be
-50 investigated in order to see possible DL
-60 coverage or open loop PC problems
RSCP [dBm]
-70 •In case CPICH RSCP is low but UE Tx
-80 Power is low
-90 •There is possibility that UE open
-100 loop PC is not working correctly
-110 •Or the CPICH Tx power is pretty
-120 low and there is DL coverage
problem
30
•Or the SCCPCH power offset to
20 CPICH power is set wrongly – too
UE Tx Power [dBm]
big offset
10
•In case CPICH Ec/No is low but the UE
0 Tx power is low then there could be
-30 -25 -20 -15 -10 -5 0
-10
some problem in DL quality - provided
that the CPICH RSCP is ok
-20 •Some high DL loading in the cell
-30 •Pilot pollution on that area
-40
29 © NOKIA
[dB]
CPICH Ec/No [dBm]
Call Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential
Power-
CPICH Ec/No [dB] • From CPICH Ec/No vs. CPICH RSCP it can
-30 -25 -20 -15 -10 -5 0 be seen that only a few call failures are
-40 having relatively good CPICH RSCP but still
-50 pretty poor CPICH Ec/No:
CPICH RSCP [dBm]

-60 •indicating possibility of Pilot Pollution
-70 •Indicating possibility of relatively high DL
-80 load
-90 • Those cells in case they constantly do have
-100 this kind of phenomena should be
-110 investigated more
-120
Plot of RSCP and Ec/No vs Data No. in problem Area • For possible pilot pollution investigation the amount of
0 0
Pilot pollution area/poor SCs and their strength can be plotted from the drive
dominance area -5
test data and possible the cells causing the pilot
RSCP and RSSI (dBm)
-20
-10
-40 -15
Ec/No (dB) pollution can be identified and dominance
-60
-20 optimisation can be done
-25
-80
-30
-100 -35
-40
-120
-45
-140 -50
Data No.
ANT1_RSSI SC97 RSCP SC106 RSCP SC103 RSCP SC69 RSCP
SC174 RSCP SC180 RSCP SC97 Ec/No SC106 Ec/No SC103 Ec/No
SC69 Ec/No SC174 Ec/No SC180 Ec/No
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

Before 1.5.2 CD15 Call Setup Performance
UE Node B RNC UE Node B RNC
[RACH] RRC:RRC Connection Request [RACH] RRC:RRC Connection Request
NBAP: RL Setup Request

There is no retransmission NBAP: RL Setup Request
of RRC Connection Setup
NBAP: RL Setup Response -message. NBAP: RL Setup Response
ALCAP:ERQ This is why the UE just ALCAP:ERQ
ALCAP:ECF
sends another RRC ALCAP:ECF
Connection Request –
[FACH] RRC: RRC Connection Setup message. [FACH] RRC: RRC Connection Setup
UE does not hear RRC Connection Setup from RNC UE does not hear RRC Connection Setup from RNC

The more RRC Connection NBAP: RL Setup Request
Request retransmission
the more (in case RNC NBAP: RL Setup Response
hears the message) RLs ALCAP:ERQ
are setup and more Iub ALCAP:ECF
Capacity used.
The RNC internal timer [FACH] RRC: RRC Connection Setup
(T_RRC_Resp_CCH) will
release the unused RLs on
Iub after 6seconds (from
the establishment)
UE Node B • Current default values of the parameters are:
RNC
[RACH] RRC:RRC Connection Request T300=3000ms and N300=3
• UE will send the RRC Connection Request
message four times in the interval of three
NBAP: RL Setup Response seconds if there is no RRC Connection
ALCAP:ERQ Setup message received from the RNC
ALCAP:ECF • The RRC Connection Setup message is sent
T300
only once (UM RLC SAP is used for this RRC
procedure)
RRC Connection Setup –message is • RRC Connection Setup is quite a long
transmitted in several successive
transport blocks 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
• 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

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 Repeat counter for RRC Connection Release message sent on:
(interval DCCH mapped to DCH and DCCH/CCCH mapped to FACH.
300ms) Note. Repetitions shall not be used when the message is sent
over Iur (possible repetitions must be executed by the DRNC).

UE Node B RNC
• Based on the experiments made in the
network with a sufficiently low load one can
get improvement in call setup delay when
NBAP: RL Setup Response reducing the value of T300
ALCAP:ERQ
• By reducing the value of T300
ALCAP:ECF
• the UE will repeat the request sooner and
[FACH] RRC: RRC Connection Setup the delay in RRC connection establishment
RRC Connection Setup –message is
transmitted in several successive
caused by lost Request/Setup messages
transport blocks can be minimized
• However This is wrong way to correct
the "problem“
UE does not hear RRC Connection Setup from RNC
• 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
UE Node B RNC
• If the repeated RRC Connection Request
messages are received before the RNC has
been able to complete the ongoing RRC
ALCAP:ERQ
Connection Setup procedures (i.e. release
the established RLs for the unsuccessful
ALCAP:ECF
RRC Connection Setup attempts) this will
[FACH] RRC: RRC Connection Setup cause new RRC connection establishment
procedures to be triggered (requiring maybe
more calls to be pre-empted in vain)
NBAP: RL Setup Request • Initiation of the pre-emption procedure may
need Radio Link Setup Request to be
ALCAP:ERQ rejected by the BTS or AAL2-setup failure to
ALCAP:ECF
happen
[FACH] RRC: RRC Connection Setup • Then the DCH-allocation of packet data call
(to be pre-empted) must be released (state
transition CELL_DCH -> CELL FACH is
triggered)

UE Node B RNC
• State transition from Cell_DCH to Cell_FACH is
in the optimum case fast
NBAP: RL Setup Request • In case there is a cell reselection procedure
executed before the MS acknowledges the state
ALCAP:ERQ
transition command, then the RL(s) cannot be
released until the Cell Update is received via the
ALCAP:ECF 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
UE does not hear RRC Connection Setup from RNC inter-RNC SHO
ALCAP:ERQ
ALCAP:ECF
• Additional RRC Connection Requests will cause
additional resource reservations and due to that
[FACH] RRC: RRC Connection Setup 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

UE Node B RNC
ALCAP:ERQ
ALCAP:ECF • Resources reserved for these unnecessary

[FACH] RRC: RRC Connection Setup "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
ALCAP:ERQ
RL is released after Layer3 time supervision
for the MS acknowledge has expired
ALCAP:ECF

UE sends new RRC Connection
Request to Cell B which is
CPICH Ec/No successful and call is setup CPICH Ec/No
CPICH RSCP successfully CPICH RSCP
First RRC
Connection
Request sent
by the UE –
RNC Answers
with RRC
Connection -10dB
Setup – UE
does not hear it
-100dB -15dB
UE waits T300 seconds until it sends next RRC Connection Time

Request. During the T300 time the UE makes cell reselection
Cell A to Cell B Cell B
• 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
• 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)

• 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

UE Node B RNC RNC starts timer
[RACH] RRC:RRC Connection Request T_RRC_Resp_CC 3
H
Timer NBAP:R
Start
TX/RX
T300 is L Setup RNC sends RRC
started Request Connection Setup -
message
ALCAP:ERQ
S 2
ALCAP:ECF

UE sends BTS Starts sending BTS sends: NBAP UE start
RRC DPCCH: Pilot and RADIO LINK sending
Start Connection DPCCH for
TPC & Starts UL SETUP
TX/RX
Request - synchronization RESPONSE - UL sync
L1 Synchronisation
message procedure message purposes
(pilot) after DL
1
NBAP: Synchronisation Indication frame sync is
established
[DCH] RRC: RRC Connection Setup Complete
• 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
E Call Setup Performance
• 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

• 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 Reported value Measured quantity value
PhCh_BER_LOG_ 000 Physical channel BER = 0
PhCh_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_ 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

• 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

UE Node B RNC • When a physical dedicated channel establishment is
[RACH] RRC:RRC Connection Request initiated by the UE, the UE starts a timer T312 and wait
NBAP: RL Setup Request for layer 1 to indicate N312 "in sync" indications
Start
TX/RX • On receiving N312 "in sync" indications, the physical
NBAP: RL Setup Response channel is considered established and the timer T312 is
ALCAP:ERQ stopped and reset
ALCAP:ECF

• On the BTS side after receiving N_INSYNC_IND
synchronisation indicators the BTS sends NBAP:
Start
TX/RX
SYNCHRONIZATION INDICATION –message to RNC
after which the closed loop and outer loop PC start to
L1 Synchronisation control the powers L1 Synchronization
established RNC receives RRC
[DCH] RRC: RRC Connection Setup Complete BTS sends NBAP: Connection Setup
N_INSYNC_IND SYNCHRONIZATION Complete –message ->
indicators on L1 IDICATION -message RNC stops timer
Timer T312 started T_RRC_Resp_CCH
1
Timer T312
“in sync” stopped
UE initiates physical dedicated
channel establishment before indicators on L1 RRC Connection Setup
sending e.g. RRC Connection L1 Complete –message
Setup Complete –message on Synchronization SENT
DPDCH established
N312 L1 “in sync”
indicators
Other cases HHO,
47 © NOKIA CallFACH=>DCH-state transitions
Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential
UE Node B
Before 1.5.2 CD15
RNC Call Setup Performance
Start • In case UE is not able to establish synchronization
TX/RX
NBAP: RL Setup Response within timer T312 it stops TX on the DCH
• In case BTS is not able to establish synchronization it
ALCAP:ERQ
ALCAP:ECF
[FACH] RRC: RRC Connection Setup does not send NBAP:Synchronization Indication –
Start message to RNC
TX/RX
L1 Synchronisation
• 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 RNC does not receive
Less than
Timer established BTS does NOT send RRC Connection Setup
N_INSYNC_IND Complete –message
T312 NBAP: SYNCHRONIZATION
started indicators on L1 within
IDICATION -message
T_RRC_Resp_CCH
timer
2 Counter 1001C9
is incremented
Timer T312 expired RNC sends
UE initiates physical dedicated “in sync” => L1 NBAP:RADIO LINK
channel establishment before indicators on L1 Synchronization DELETION –message
sending e.g. RRC Connection not established
Setup Complete –message on RRC Connection
DPDCH establishment procedure
Less thanN312 failed -> wait until T300
L1 “in sync” expires and if number of
Physical channel
Other cases HHO, indicators sent RRC Connection
establishment failed
FACH=>DCH-state transitions
48 © NOKIA Call Performance.PPT / 16-09-2003 /Reunanen Jussi
=> UE stops TX/RX
Company Confidential
Requests < N300 S
UE Node B RNC Call Setup Performance
Before 1.5.2 CD15
• In case BTS is able to establish synchronization it sends
Start TX/RX NBAP:Synchronization Indication –message to RNC
ALCAP:ERQ
• In case UE is not able to establish synchronization within timer T312 it
ALCAP:ECF
stops TX on the DCH
[FACH] RRC: RRC Connection Setup • 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
Start TX/RX message in 5 sec. intervals until RNC sends NBAP: Radio Link Deletion
L1 Synchronisation –message back)
NBAP: Synchronisation Indication • After T_RRC_Resp_CCH expires in RNC the RNC sends NPAB: Radio
Link Deletion to BTS which then stops searching for the synchronization
NBAP: Radio Link Failure
Counter 1001C10
is incremented
L1 Synchronization established
BTS sends NBAP: SYNCHRONIZATION Timer
IDICATION -message T_RLFAILURE
expires
Timer T312 started N_INSYNC_IND N_OUTSYNC_IND
indicators on L1 Timer T312 timer
indicators on L1 T_RRC_Resp_C
expired
CH expired
3
“in sync” Timer
Physical channel RNC sends
indicators on L1 T_RLFAILUR
establishment failed NBAP:RADIO
UE initiates physical E started
=> UE stops TX/RX LINK DELETION
dedicated channel
–message
establishment before RNC receives NBAP:RADIO
sending e.g. RRC Less than N312 L1 “in LINK FAILURE –message
Connection Setup sync” indicators form BTS with a cause value
Complete –message on "Synchronization Failure"
DPDCH RRC Connection establishment procedure failed
-> wait until T300 expires and if number of sent
49 © NOKIA RRC
Call Performance.PPT Connection
/ 16-09-2003 /ReunanenRequests
Jussi <Company
N300 Confidential S
UE
Before 1.5.2
[RACH]
Node B
CD15
RRC:RRC Connection Request
RNC
NBAP: RL Setup Request -RRC Connection Establishment-
Start TX/RX
NBAP: RL Setup Response • In case the BTS does not send NBAP: RL Failure –
ALCAP:ERQ
message to RNC but the RNC does not receive RRC
Connection Setup Complete –message from UE
ALCAP:ECF
Start TX/RX
within timer T_RRC_Resp_CCH, the RNC initiates
L1 Synchronisation
RRC Connection Release procedure
Counter 1001C10 RNC sends

is incremented NBAP:RADIO LINK
L1 Synchronization established DELETION –message
BTS sends NBAP: SYNCHRONIZATION
IDICATION -message No RRC: RRC CONNECTION
RELEASE COMPLETE message
Timer T312 started N_INSYNC_IND timer is not received => RRC entity of
indicators on L1 Timer T312 T_RRC_Resp_C the UE is deleted at the same time
expired CH expired with the radio link deletion
procedure
3
“in sync” Physical channel RNC sends No RRC: RRC CONNECTION
indicators on L1 establishment failed RRC:RRC RELEASE COMPLETE –message
UE initiates physical => UE stops TX/RX CONNECTI from UE within within the message
dedicated channel ON repetition timer (100ms)
establishment before RELEASE –
sending e.g. RRC Less than N312 L1 “in
sync” indicators message on
Connection Setup DCH to UE the RNC retransmits the
Complete –message on message
RRC Connection establishment procedure failed L3Rep_RRC_Conn_Rel times
DPDCH
-> wait until T300 expires and if number of sent with interval of 100 ms
50 © NOKIA RRC
Call Performance.PPT Connection
/ 16-09-2003 /ReunanenRequests
Jussi <Company
N300 Confidential S
After 1.5.2 CD15 Call Setup Performance
RNC starts timers
T_RRC_Resp_CCH,
UE Node B RNC RNC receives RRC
RRCconnRepTimer1 and
Connection Request and
starts buffering timer
RRCconnRepTimer2 3
NBAP: RL Setup Request N300*T300
Timer NBAP:R
Start
TX/RX
T300 is L Setup RNC sends RRC
started Request Connection Setup -
message
ALCAP:ERQ
S 2
ALCAP:ECF

UE sends BTS Starts sending BTS sends: NBAP UE start
RRC DPCCH: Pilot and RADIO LINK sending
Start Connection DPCCH for
TPC & Starts UL SETUP
TX/RX
Request - synchronization RESPONSE - UL sync
L1 Synchronisation
message procedure message purposes
(pilot) after DL
1
NBAP: Synchronisation Indication frame sync is
established
[DCH] RRC: RRC Connection Setup Complete
• 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
Call Setup Performance After 1.5.2 CD15
UE Node B RNC • When a physical dedicated channel establishment is
[RACH] RRC:RRC Connection Request initiated by the UE, the UE starts a timer T312 and wait
NBAP: RL Setup Request for layer 1 to indicate N312 "in sync" indications
Start
TX/RX • On receiving N312 "in sync" indications, the physical
NBAP: RL Setup Response channel is considered established and the timer T312 is
ALCAP:ERQ stopped and reset
ALCAP:ECF

• On the BTS side after receiving N_INSYNC_IND
synchronisation indicators the BTS sends NBAP:
Start
TX/RX
SYNCHRONIZATION INDICATION –message to RNC
after which the closed loop and outer loop PC start to
L1 Synchronisation control the powers L1 Synchronization RNC receives RRC
NBAP: Synchronisation Indication Connection Setup
established
Complete –message ->
[DCH] RRC: RRC Connection Setup Complete BTS sends NBAP: RNC stops timers
N_INSYNC_IND SYNCHRONIZATION
indicators on L1 T_RRC_Resp_CCH,
IDICATION -message RRCconnRepTimer1 and
Timer T312 started
RRCconnRepTimer2
1
Timer T312
“in sync” stopped
UE initiates physical dedicated
channel establishment before indicators on L1 RRC Connection Setup
sending e.g. RRC Connection L1 Complete –message
Setup Complete –message on Synchronization SENT
DPDCH established
N312 L1 “in sync”
indicators
Other cases HHO,
52 © NOKIA CallFACH=>DCH-state transitions
Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential
UE Node B RNC

After 1.5.2 CD17
Start
TX/RX • In case UE is not able to establish synchronization within
ALCAP:ERQ
timer T312 it stops TX on the DCH
ALCAP:ECF • In case BTS is not able to establish synchronization it does
not send NBAP:Synchronization Indication –message to
Start RNC
TX/RX
L1 Synchronisation
• The BTS tries to establish synchronization until
T_RRC_Resp_CCH timer in RNC expires and RNC sends
NBAP:Radio Link Deletion -message
Less than N_INSYNC_IND indicators on L1
L1 Synchronization not RNC does not receive

RRC Connection Setup Complete RRC Connection Setup
Timer established BTS does NOT send
not received RRCconnRepTimer1 Complete –message
T312 NBAP: SYNCHRONIZATION
expires -> RRC Connection within
started IDICATION -message
Setup is resent to the UE T_RRC_Resp_CCH
timer
2
RNC sends
RRC Connection Setup Complete Timer T312 expired NBAP:RADIO LINK
not received RRCconnRepTimer2 => L1 DELETION –message
UE initiates physical dedicated expires -> RRC Connection Setup Synchronization
channel establishment before is resent to the UE and not established Counter 1001C9 is
sending e.g. RRC Connection RRCconnRepTimer2 reset incremented
Setup Complete –message on RRCconnRepTimer1 stopped -no Synchronisation
DPDCH indication received within
Physical channel supervision time
Other cases HHO, Less thanN312 L1 “in sync” indicators establishment failed -no rrc connection setup
FACH=>DCH-state transitions => UE stops TX/RX complete reeived within
53 © NOKIA Call Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential supervision time
UE Node B RNC Call Setup Performance
After 1.5.2 CD17
• In case BTS is able to establish synchronization it sends
Start TX/RX NBAP:Synchronization Indication –message to RNC
ALCAP:ERQ • In case UE is not able to establish synchronization within timer
ALCAP:ECF T312 it stops TX on the DCH
[FACH] RRC: RRC Connection Setup • As the UE TX is off the BTS looses the L1 synchronization and
Start TX/RX
sends NPAB: Radio Link Failure –message to RNC
L1 Synchronisation • After T_RRC_Resp_CCH expires in RNC the RNC sends NPAB:
Radio Link Deletion to BTS which then stops searching for the
NBAP: Synchronisation Indication synchronization
NBAP: Radio Link Failure Counter 1001C10 is incremented
L1 Synchronization established BTS sends
NBAP: SYNCHRONIZATION IDICATION - -Synchronisation indication
message received within supervision time
N_INSYNC_IND indicators on L1 Timer -no rrc connection setup complete
T_RLFAILUR reeived within supervision time
RRC Connection Setup Complete E started
Timer
not received RRCconnRepTimer1 N_OUTSYNC_IND Timer
T312 timer
expires -> RRC Connection indicators on L1 T_RLFAILU
started T_RRC_Resp_C
Setup is resent to the UE RE expires
CH expired
3
RRC Connection Setup Complete Timer T312 expired RNC sends
not received RRCconnRepTimer2 => L1 NBAP:RADIO
UE initiates physical dedicated expires -> RRC Connection Setup Synchronization LINK DELETION
channel establishment before is resent to the UE and not established –message
sending e.g. RRC Connection RRCconnRepTimer2 reset
Setup Complete –message on RRCconnRepTimer1 stopped
DPDCH RNC receives NBAP:RADIO
Physical channel LINK FAILURE –message
Other cases HHO, Less thanN312 L1 “in sync” indicators establishment failed form BTS with a cause value
FACH=>DCH-state
54 © NOKIA transitions / 16-09-2003 /Reunanen Jussi
Call Performance.PPT Company Confidential => UE stops TX/RX "Synchronization Failure"
UE Node B
RNC
After 1.5.2 CD17
NBAP: RL Setup Request -RRC Connection Establishment-
Start TX/RX
NBAP: RL Setup Response • In case the BTS does not send NBAP: RL Failure –
ALCAP:ERQ
message to RNC but the RNC does not receive RRC
Connection Setup Complete –message from UE
ALCAP:ECF
Start TX/RX
within timer T_RRC_Resp_CCH, the RNC initiates
L1 Synchronisation
RRC Connection Release procedure
NBAP: Synchronisation Indication L1 Synchronization Counter 1001C10 is
incremented
established BTS sends
-Synchronisation
NBAP: SYNCHRONIZATION indication received within
IDICATION -message supervision time
-no rrc connection setup RNC sends
N_INSYNC_IND indicators on L1 complete reeived within NBAP:RADIO LINK
supervision time DELETION –
RRC Connection Setup Complete message
Timer
not received RRCconnRepTimer1
T312 RRC entity of the UE is deleted
expires -> RRC Connection timer
started at the same time with the radio
Setup is resent to the UE T_RRC_Resp_CCH
expired link deletion procedure
3
RNC sends RRC:RRC CONNECTION RELEASE –
RRC Connection Setup Complete message on DCH to UE, timer T_RRC_Resp_CCH
not received RRCconnRepTimer2 restarted
UE initiates physical dedicated expires -> RRC Connection Setup No RRC CONNECTION
channel establishment before is resent to the UE and RELEASE COMPLETE –
sending e.g. RRC Connection RRCconnRepTimer2 reset message from UE within within
Setup Complete –message on RRCconnRepTimer1 stopped the message repetition timer
DPDCH (100ms)
the RNC retransmits the
Other cases HHO, Less thanN312 L1 “in sync” indicators message
FACH=>DCH-state
55 © NOKIA transitions
Call Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential L3Rep_RRC_Conn_Rel times
• Longer time (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
• During the test it was noted

AMR performance
that setting N312 to 2 or 4
MOC / MTC call setup delay 5 sec Percentile
100%
90% (between 1 and 2 there is
80%
70% notable difference) does not
60%
50%
have any significant effect on
40% the call set up success rate
30%
20%
10%
• But the effect on the call set up
0% time is significant and therefore
14/01/03
16/01/03
18/01/03
20/01/03
22/01/03
24/01/03
25/01/03
28/01/03
01/02/03
05/02/03
10/02/03
12/02/03
15/02/03
01/03/03
06/03/03
07/03/03
17/03/03
N312 value of 2 was selected
Percentile MOC call setup delay @5 sec
to be used
Percentile MTC call setup delay @5 sec
N312 N312 N312

=1 =4 =2
-RRC Connection Establishment: Power Offset for SCCPCH Pilot & TFCI bits
-
• 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)
TFCI Data Pilot

NTFCI bits Ndata1 bits Npilot bits
Tslot = 2560 chips, 20*2k bits (k=0..6)
Slot #0 Slot #1 Slot #i Slot #14
1 radio frame: Tf = 10 ms

-RRC Connection Establishment: Power Offset for SCCPCH Pilot & TFCI bits
-
power offset power offset TFCI =

TFCI = 4 dB 0 dB for 60 ksps
for 60 ksps SCCPCH
SCCPCH
Failure due to FACH/RACH

is lower from xxx test in Apr
Same result shown in MTC
• 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

-Common Channel Power Tuning-
• Call Setup Success Statistics
• Call setup success rate has improved after parameter change by 4~5%.
Channels Default case4

CPICH Ptx 27 27
PCCPCH Ptx 24 25
PSCH 25 27
SSCH 25 27
PICH 20 24
SCCPCH 29 27
AICH 21 27
Call Setup Success Rate
AMR MOC 100.0%
90.0%
Default 572 473 82.7% 85.0%
Case4 771 678 87.9% 80.0%
75.0%
Success rate
70.0%
AMR MTC 65.0%
60.0%
Default 484 412 85.1% 50.0%
45.0% Default
Case4 625 556 89.0% 40.0%
35.0% Case4
30.0%
UDI MOC 25.0%
20.0%
Default 320 262 81.9% 10.0%
5.0%
Case4 527 451 85.6% 0.0%
61 © NOKIA Call Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential Services
-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
Index of Call Results Breakdown

A 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 Success
• In Step A & B, the performance after parameter change has improved
J Call Setup Failure due to Registration (2.4)
AMR MOC AMR MTC UDI MOC

Category Default Case4 Default (%) Case4 (%) Category Default Case4 Default (%) Case4 (%) Category Default Case4 Default (%) Case4 (%)
A 8 0 1.40% 0.00% A 3 0 0.62% 0.00% A 0 0 0.00% 0.00%
B 19 26 3.32% 3.37% B 5 15 1.03% 2.40% B 18 26 5.63% 4.93%
C 0 0 0.00% 0.00% C 0 1 0.00% 0.16% C 0 0 0.00% 0.00%
D 36 32 6.29% 4.15% D 21 20 4.34% 3.20% D 18 25 5.63% 4.74%
E 7 4 1.22% 0.52% E 2 7 0.41% 1.12% E 7 3 2.19% 0.57%
F 11 4 1.92% 0.52% F 28 10 5.79% 1.60% F 6 5 1.88% 0.95%
G 5 8 0.87% 1.04% G 6 4 1.24% 0.64% G 3 6 0.94% 1.14%
H 13 17 2.27% 2.20% H 7 12 1.45% 1.92% H 6 11 1.88% 2.09%
I 473 678 82.69% 87.94% I 412 556 85.12% 88.96% I 262 451 81.88% 85.58%
J 62 © NOKIA 0 2 0.00% 0.26% J
Call Performance.PPT / 16-09-2003 /Reunanen Jussi 0 0 0.00%
Company Confidential 0.00% J 0 0 0.00% 0.00%
-RRC Connection Establishment: Counters-
Failure Case:
RRC Connection Setup fails
UE RNC CN
BTS Due to
Triggers:
RRC: Connection Request 1001C2 Handover control
Correctly Received message 1001C3 Admission control
RRC Connection Setup Starts 1001C4 BTS
Triggers: 1001C5 Transmission network
1001C0 RRC Connection Attempt 1001C6 RNC internal reason
1001C7 Frozen BTS
RRC Connection Setup phase
Resource Reservation in RNC, BTS, Transmission
Failure Case:
RRC: RRC Connection Request Setup RRC Connection Access fails
RRC Connection setup completed Due to
Triggers: Triggers:
1001C1 RRC Con Setup Compl 1001C9 L1 synchronization in BTS
1001C10 UU interface
RRC Connection Access phase 1001C11 RNC internal reason
RNC waits reply from UE
RRC: RRC Connection Completed Failure Case:
RRC Connection Access completed RRC Connection Active fails
Triggers: Due to
1001C8 RRC Con Acc Comp Triggers:
RRC: Initial Direct Transfer 1001C15 Iu interface
1001C16 Radio interface
RANAP: Initial UE Message 1001C17 BTS
1001C18 Iur interface
RRC Connection Active phase 1001C19 Ciphering failure
UE-CN Signaling 1001C20 Integrity check
1001C21 RNC internal rea
RANAP: Iu Release Command
Special Reason:
RRC Connection Active completed RRC Connection Active
Triggers: Release Due to
1001C12 RRC Con Active Comp Triggers:
1001C13 SRNC Relocat
1001C14 Pre-emption

RRC Connection Setup due to Cause
Call Setup Performance Triggers:

1001C22 MOC conv call att
1001C24 MOC stream call att
-RRC Connection Establishment: Counters- 1001C26 MOC interac call att
1001C28 MOC backgr call att
1001C30 MOC subscribed call att
1001C32 MTC conv call att
UE RNC CN 1001C34 MTC stream call att
BTS 1001C36 MTC interac call att
1001C38 MTC backgr call att
RRC: Connection Request 1001C40 Emergency call att
Correctly Received message 1001C42 Inter RAT cell reselection
Triggers: 1001C44 Inter RAT cell chng ord
1001C0 RRC Connection Attempt 1001C46 Registration attempt
1001C48 Detach attempt
RRC Connection Setup phase 1001C50 MOC high prior signaling
Resource Reservation in RNC, BTS, Transmission 1001C52 MTC high prior signaling
1001C54 MOC low prior signaling
RRC: RRC Connection Request Setup 1001C56 MTC high prior signaling
RRC Connection setup completed 1001C58 Call re establishment att
Triggers: 1001C60 Terminating cause unknown
1001C1 RRC Con Setup Compl
Failures by RRC Connection Setup
RRC Connection Access phase Causes
RNC waits reply from UE Triggers:
RRC: RRC Connection Completed 1001C23 MOC conv call failure
1001C25 MOC stream call failure
RRC Connection Access completed 1001C27 MOC interac call failure
Triggers: 1001C29 MOC backgr call failure
1001C8 RRC Con Acc Comp 1001C31 MOC subscribed call fail
RRC: Initial Direct Transfer 1001C33 MTC conv call failure
1001C35 MTC stream call failure
RANAP: Initial UE Message
1001C37 MTC interac call failure
1001C39 MTC backgr call failure
RRC Connection Active phase 1001C41 Emergency call failure
UE-CN Signaling 1001C43 Inter RAT cell reselec fail
1001C45 Inter RAT cell chng ord fail
RANAP: Iu Release Command 1001C47 Registration attempt fai
1001C49 Detach attempt failure
RRC Connection Active completed 1001C51 MOC high prior sig failure
Triggers: 1001C53 MTC high prior sig failure
1001C12 RRC Con Active Comp 1001C55 MOC low prior sig failure
1001C57 MTC high prior sig failure
1001C59 Call re establishment fail
1001C61 Terminating cause unknown
failure
-RRC Connection Establishment: PIs-
UE RNC CN
BTS
RRC: Connection Request
Correctly Received message
RRC Connection Setup Starts
Triggers:
1001C0 RRC Connection Attempt RRC Setup Complete Ratio [%]
100*[Sum(1001C1)/Sum(1001C0)]
RRC Connection Setup phase
Resource Reservation in RNC, BTS, Transmission
RRC: RRC Connection Request Setup RRC Setup and
RRC Connection setup completed
Triggers: Access Complete Ratio [%]
1001C1 RRC Con Setup Compl 100*[Sum(1001C8)/Sum(1001C0)]
RRC Connection Access phase

RNC waits reply from UE Special Reason:
RRC Connection Active
RRC: RRC Connection Completed Release Due to
RRC Connection Access completed Triggers:
Triggers: 1001C13 SRNC Relocation
1001C8 RRC Con Acc Comp 1001C14 Pre-emption
RRC: Initial Direct Transfer
RANAP: Initial UE Message
RRC Drop Ratio [%]

RRC Connection Active phase 100-100*[Sum(1001C12+1001C1
UE-CN Signaling +1001C14)/Sum(1001C8)]
RANAP: Iu Release Command
RRC Connection Active completed

Triggers:
1001C12 RRC Con Active Comp

• 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)
-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
• Paging
• UL Interference


-RAB Establishment Performance-
• The RAB establishment procedure starts right after the RRC Connection
establishment, signalling connection establishment, authentication &
security procedures and call setup signaling
UE Node B RNC CN UE Node B RNC CN
RRC:Initial Direct Transfer(MM:CM Service Request) RANAP:Direct Transfer(CC:Call Proceeding)

RRC:DL Direct Transfer(CC:Call Proceeding)
RANAP:Initial UE Message(MM:CM Service Request)
RANAP:RAB Assignment Request
SCCP:CC
NBAP:Radio Link Reconfiguration Prepare
RANAP:Direct Transfer(MM:Authentication Request)
NBAP:Radio Link Reconfiguration ready
RRC:DL Direct Transfer(MM:Authentication Request) ALCAP:ERQ
RRC:UL Direct Transfer(MM:Authentication Response) ALCAP:ECF
ALCAP:ERQ
RANAP:Direct Transfer(MM:Authentication Response) ALCAP:ECF
RANAP:Common ID NBAP:Radio Link Reconfiguration Commit
RRC:Radio Bearer Setup

RANAP:Security Mode Command
RRC:Radio Bearer Setup Complete
RRC:Security Mode Command
RANAP:RAB Assignment Response
RRC:Security Mode Complete RANAP:Direct
RRC:DL Direct Transfer(CC:Alerting) Transfer(CC:Alerting)
RANAP:Security Mode Complete
RANAP:Direct Transfer(CC:Connect)
RRC:UL Direct Transfer(CC:Setup)
RRC:DL Direct Transfer(CC:Connect)
RANAP:Direct Transfer(CC:Setup)
RRC:UL Direct Transfer(CC:Connect Acknowledge)
RANAP:Direct Transfer(CC:Connect Acknowledge)

-RAB Establishment Performance: Counters; RAB Setup & Access-
RAB Setup starts
Depending on RAB Type
BTS RNC Triggers:
UE CN 1001C66 RAB setup att for CS Voice
1001C67 RAB setup att for CS Data conv class
RRC Connection Active phase 1001C68 RAB setup att for CS Data stream cla
UE-CN Signaling 1001C69 RAB setup att for PS Data conv class
1001C70 RAB setup att for PS Data stream cla
RANAP: RAB Assignment Request 1001C71 RAB setup att for PS Data intera clas
1001C72 RAB setup att for PS Data backgr cla
RAB Setup phase Failure Case:

Resource Reservation in RNC, BTS, Transmission CS RAB Setup for Voice fails Due to
Triggers:
RRC: Radio Bearer Setup 1001C80 Admission control
1001C81 BTS
RAB Connection Access phase 1001C82 Transmission network
RNC waits reply from UE 1001C83 RNC internal reason
1001C84 Frozen BTS
RRC: Radio Bearer Setup Completed Note: Each RAB type
has identical failure counters
RANAP: RAB Assignment Response
RAB Setup Completed
Triggers:
RAB Active phase 1001C73 RAB setup comp for CS Voice
User Plane Data Transfer 1001C74 RAB setup comp for CS Data conv clas
1001C75 RAB setup comp for CS Data stream c
RAB Access Completed 1001C76 RAB setup comp for PS Data conv clas
Triggers: 1001C77 RAB setup comp for PS Data stream cl
1001C115 RAB setup acc comp for CS Voice 1001C78 RAB setup comp for PS Data intera cla
1001C116 RAB setup acc comp for CS Data conv 1001C79 RAB setup comp for PS Data backgr cl
class
1001C117 RAB setup acc comp for CS Data stream Failure Case:
class CS RAB Access for Voice fails Due
1001C118 RAB setup acc comp for PS Data conv to
class Triggers:
1001C119 RAB setup acc comp for PS Data stream 1001C122 UE
class 1001C123 RNC internal
1001C120 RAB setup acc comp for PS Data intera Note: Each RAB type
class
-RAB Establishment Performance: Counters RAB Active Phase-
UE BTS RNC CN
RAB Active phase
User Plane Data Transfer Special Reason:
RAB Active Release Due to
RANAP: RAB Assignment Request, with IE: RAB reconfiguration Triggers:
1001C143 SRNC Relocation for CS Voice
1001C144 Pre-emption for CS Voice
For all types of RABs
RAB Reconfiguration
Resource Reconfigured in RNC, BTS, Transmission
RAB Reconfiguration Attempt
RRC: Radio Bearer Reconfiguration Triggers:
1001C197 RAB reconf Att
RRC: Radio Bearer Reconfiguration Complete
RAB Reconfiguration Failure
Triggers:
1001C198 RAB reconf Fail
RANAP: RAB Assignment Request, with IE: RAB Release
RRC: Radio Bearer Release

RAB Active Completed
RRC: Radio Bearer Reconfiguration Complete
RANAP: RAB Assignment Response Triggers:
1001C136 RAB Act Comp for CS Voice
RAB Release 1001C137 RAB Act Comp for CS Data conv clas
Resource Released in RNC, BTS, Transmission 1001C138 RAB Act Comp for CS Data stream c
1001C139 RAB Act Comp for PS Data conv clas
1001C140 RAB Act Comp for PS Data stream c
1001C141 RAB Act Comp for PS Data intera cla
1001C142 RAB Act Comp for PS Data backgr c

-RAB Establishment Performance: PIs-
UE BTS RNC CN
RANAP: RAB Assignment Request
RAB Setup phase RAB Setup Complete Ratio [%]

Resource Reservation in RNC, BTS, Transmission 100*[Sum(1001C73…79)/Sum(1001C66…72
RRC: Radio Bearer Setup
RAB Setup and
RAB Connection Access phase Access Complete Ratio [%]
RNC waits reply from UE 100*[Sum(1001C115..121)/Sum(1001C66…72
RRC: Radio Bearer Setup Completed

RANAP: RAB Assignment Request, with IE: RAB Release

RAB Drop Ratio [%]
RRC: Radio Bearer Release 100-100*[Sum(1001C136…142+1001C143
1001C144+1001C151…154+1001C167…1
RRC: Radio Bearer Reconfiguration Complete /Sum(1001C115…121)]

-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)

UE Node B RNC CN
RANAP:Direct Transfer(CC:Call Proceeding) • It should be noted that during RAB

RRC:DL Direct Transfer(CC:Call Proceeding) Assignment procedure (i.e. between
RANAP:RAB Assignment Request RAB Assignment Request and RAB
NBAP:Radio Link Reconfiguration Prepare Assignment Response) the SHO
activation is not possible ->
ALCAP:ERQ measurement reports are rejected
ALCAP:ECF (e1a and e1c) or buffered (e1b)
ALCAP:ERQ
• From UE logs point of view
ALCAP:ECF
between CALL PROCEEDING
NBAP:Radio Link Reconfiguration Commit
and ALERTING
RRC:Radio Bearer Setup

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

• 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

-RAB Establishment Performance : Questions-
• What needs to be remembered concerning SHO during call setup?
• What is RAB?
• What is given in RAB attributes?

Contents
• Paging
• UL Interference


Failure Case:
CS RAB Setup for Voice fails Due to
Triggers:
1001C80 Admission control
Call Setup Performance Failure Case:
CS RAB Access for Voice fails Due
to
1001C81 BTS
1001C82 Transmission network -Failure due to AC- Triggers:
1001C122 UE
1001C83 RNC internal reason 1001C123 RNC internal
1001C84 Frozen BTS Note: Each RAB type
Note: Each RAB type has identical has identical failure counters
failure counters
• 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, •See next slides for details
• 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 •See next slides for details
• The reason can be identified in the traffic table counters
• Signalling link: DCH_REQ_LINK_REJ_UL_SRNC &
DCH_REQ_LINK_REJ_DL_SRNC
104 • Conversational:
© NOKIA REQ_CS_CONV_REJ_UL_SRNC
Call Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential &
-Investigating Call Setup Failure-
MT Investigate paging
MTC/MOC ? C : See chapter
Paging
Cause:
Trans, BTS ServLev: Cause: AC
RRC Setup failures ?
Investigate
transmission or
BTS
Cause:
Trans, BTS ServLev: Cause: AC
RAB Setup failures ? UL Traffic: DL
UL/DL ?
Failure Case:
CS RAB Access for Voice fails Due Investigate Investigate Tx
to interference : Power : See
Triggers: ServLev: See chapter UL chapter Tx
1001C122 UE RRC/RAB Access
1001C123 RNC internal Interference Power PIs
Note: Each RAB type failures ?
Due to MS
Investigate radio conditions,
synchronisation : See chapter
RRC Connection
Establishment
-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 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 Time-
• Call Setup Time for AMR – mobile 3G UE to PSTN
Time Direction Message Call Setup Delay (PDF CDF)
58:30.7 UL CCCH rrcConnectionRequest 100
58:31.2 DL CCCH rrcConnectionSetup 90 PDF
80 CDF
58:31.4 UL DCCH rrcConnectionSetupComplete 70
58:31.7 UL DCCH initialDirectTransfer 60
58:32.0 DL DCCH downlinkDirectTransfer 50
40
58:32.4 UL DCCH uplinkDirectTransfer 30
58:32.6 DL DCCH securityModeCommand 20
58:32.6 UL DCCH securityModeComplete 10
0
58:33.0 UL DCCH uplinkDirectTransfer 0 0 to 3000 3000 to 5000 5000 to 8000 8000 to 10000 > 10000
58:33.2 DL DCCH downlinkDirectTransfer Setup Time [ms]
58:33.9 DL DCCH radioBearerSetup

58:34.8 UL DCCH measurementReport
58:35.1 UL DCCH radioBearerSetupComplete
58:35.3 UL DCCH measurementReport
58:35.3 DL DCCH downlinkDirectTransfer (CC: Alerting)
Average call setup

time ~4.6seconds

UE Node B RNC CN
RRC:RRC Connection Request
NBAP:RL Setup Request
NBAP:RL Setup Response
-Call Setup Time-
ALCAP:ERQ
ALCAP:ECF
• Call Setup Time for UDI
RRC:RRC Connection Setup
NBAP:RL Restore Indication

• UDI calls are performed between 2 3G
RRC:RRC Connection Setup Complete UE
RRC:Initial Direct Transfer(MM:CM Service Request) • The test results below show that M-
RANAP:Initial UE Message(MM:CM Service Request) M case time is longer especially in
SCCP:CC CN due to B party waiting time.
RANAP:Direct Transfer(MM:Authentication Request)
RRC:DL Direct Transfer(MM:Authentication Request) Application Time in Time in CN Total time
RRC:UL Direct Transf
er(MM:Authentication Response)
UE (sec) (sec) (sec)
RANAP:Direct Transfer(MM:Authentication Response)
MOC UDI 2.9 0.2 5.21
RANAP:Common ID server
RANAP:Security Mode Command
RRC:Security Mode Command

MOC TV call 2.9 5.17 10.0
RRC:Security Mode Complete
RANAP:Security Mode Complete

MTC TV call 2.9 0.1 5.0
RRC:UL Direct Transfer(CC:Setup)
RANAP:Direct Transfer(C
C:Setup)
RANAP:Direct Transfer(CC:Call Proceeding)

CN delay UE delay
RRC:DL Direct Transfer(CC:Call Proceeding)
UE Node B RNC CN
-Call Setup Time-
RANAP:RAB Assignment Request
NBAP:Radio Link Reconfiguration Prepare

• Call Setup Time for UDI
ALCAP:ERQ
• UDI calls are performed between 2 3G
ALCAP:ECF UE
ALCAP:ERQ • The test results below show that M-
ALCAP:ECF
M case time is longer especially in
CN due to B party waiting time.
NBAP:Radio Link Reconfiguration Commit
RRC:Radio Bearer Setup Application Time in Time in CN Total time

UE (sec) (sec) (sec)
MOC UDI 2.9 0.2 5.21
RANAP:Direct Transfer(CC:Alerting) server
RRC:DL Direct Transfer(CC:Alerting)
MOC TV call 2.9 5.17 10.0

MTC TV call 2.9 0.1 5.0
CN delay UE delay

-Call Setup Time-
• Call Setup Time for UDI – mobile 3G UE to stationary 3G UE
16:29.0 rrcConnectionRequest Call Setup Delay (PDF CDF)

16:29.0 rrcConnectionSetup 100
PDF
16:30.0 rrcConnectionSetupComplete 90
CDF
80
16:30.0 initialDirectTransfer 70
60
16:31.0 downlinkDirectTransfer 50
16:31.0 uplinkDirectTransfer 40
30
16:31.0 securityModeCommand 20
10
16:31.0 securityModeComplete 0
16:31.0 uplinkDirectTransfer 0 0 to 3000 3000 to 5000 to 6000 to 7000 to 8000 to > 10000
5000 6000 7000 8000 10000
16:31.0 downlinkDirectTransfer Setup Time [ms]
16:32.0 radioBearerSetup
16:33.0 radioBearerSetupComplete
16:34.0 measurementControl
16:39.0 downlinkDirectTransfer

-Call Setup Time-
• 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 • MO SMS: 10
• when a new visitor makes LU authentication is • only every 10th MO SMS procedure is authenticated
always used
• MT CALL: 0
• LOC UP: 1
• For MT calls authentication is not used at all
• when LU is made authentication is always used
• MT SMS: 0
• PER UP: 0 • For MT SMS procedures authentication is not used
• For periodical location updates authentication is not
used • MT LOC REQ: 0
• IMSI ATTACH: 1 • Authentication not used for Mobile Terminated location
request procedures
• when IMSI Attach procedure is made authentication• MT USSD: 0
is always used
• Authentication not used for Mobile Terminated USSD
• MO CALL: 10
• SS OPER: 0
• only every 10th MO call is authenticated
• Authentication not used for Supplementary Services
112 © NOKIA Call Performance.PPT / 16-09-2003 /Reunanen Jussi operations
-Call Setup Time-
• 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

-Call Setup Time-
• 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

-Call Setup Time-
• 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 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
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
for CS DATA STREAM RABs on a measurement period
• UNIT: 10 ms
• RAB setup time: the time between RANAP: RAB ASSIGNMENT REQUEST and
RANAP: RAB ASSIGNMENT RESPONSE
• 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
• RAB setup time: the time between RANAP: RAB ASSIGNMENT REQUEST
and RANAP: RAB ASSIGNMENT RESPONSE
• 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
Setup Time for PS DATA INTERA RABs on a measurement
period
• UNIT: 10 ms
• DENOMINATOR FOR AVE SETUP TIME FOR PS DATA
INTERACTIVE RAB (M1001C234)
• Average setup time for PS DATA Interactive RAB
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 PS DATA BACKGROUND RAB (M1001C235)
• Average setup time for PS DATA Background RAB
Setup Time for PS DATA BACKGROUND RAB on a
measurement period
• UNIT: 10 ms
• DENOMINATOR FOR AVE SETUP TIME FOR PS DATA
BACKGROUND RAB (M1001C236)
• Average setup time for PS DATA Background RAB
incremented by 1
• UNIT: 10 ms

• Call Setup Time:
• For Voice = Average RRC Connection Setup time + Average RAB Setup
time for Voice Setup time
AVE SET UP T IMEFOR RRC (M1001C221) AVE SET UP T IMEFOR CS VOICE RAB (M1001C223)

DENOMINAT OR FOR AVE SET UP T IMEFOR RRC (M1001C222) DENOMINAT OR FOR AVE SET UP T IMEFOR CS VOICE RAB (M1001C224)
• For CS Data Conversational Class = Average RRC Connection Setup

time + Average RAB Setup time for CS data Conversational
AVE SET UP T IMEFOR RRC (M1001C221) AVE SET UP T IMEFOR CS DAT ACONV RAB (M1001C225)

DENOMINAT OR FOR AVE SET UP T IMEFOR RRC (M1001C222) DENOMINAT OR FOR AVE SET UP T IMEFOR CS DAT ACONV RAB (M1001C226)
• For CS Data Streaming Class = Average RRC Connection Setup time +

Average RAB Setup time for CS data Streaming
AVE SET UP T IMEFOR RRC (M1001C221) AVE SET UP T IMEFOR CS DAT AST REAM RAB (M1001C227)

DENOMINAT OR FOR AVE SET UP T IMEFOR RRC (M1001C222) DENOMINAT OR FOR AVE SET UP T IMEFOR CS DAT AST REAM RAB (M1001C228)
• For PS Data Conversational Class = Average RRC Connection Setup

time + Average RAB Setup time for PS data Conversational
AVE SET UP T IMEFOR RRC (M1001C221) AVE SET UP T IMEFOR PS DAT ACONV RAB (M1001C229)

DENOMINAT O
R FOR AVE SET UP T IMEFOR RRC (M1001C222) DENOMINAT O
R FOR AVE SET UP T IMEFOR PS DAT ACONV RAB (M1001C230)

• Call Setup Time:
• For PS Data Streaming Class = Average RRC Connection Setup time +
Average RAB Setup time for PS data Streaming
AVE SET UP T IMEFOR RRC (M1001C221) AVE SET UP T IMEFOR PS DAT AST REAM RAB (M1001C231)

DENOMINAT OR FOR AVE SET UP T IMEFOR RRC (M1001C222) DENOMINAT OR FOR AVE SET UP T IMEFOR PS DAT AST REAM RAB (M1001C232)
• For PS Data Interactive Class = Average RRC Connection Setup time +

Average RAB Setup time for PS data Interactive
AVE SET UP T IMEFOR RRC (M1001C221) AVE SET UP T IMEFOR PS DAT AINT ERACT IVE RAB (M1001C233)

DENOMINAT OR FOR AVE SET UP T IMEFOR RRC (M1001C222) DENOMINAT OR FOR AVE SET UP T IMEFOR PS DAT AINT ERACT IVE RAB (M1001C234)
• For PS Data Background Class = Average RRC Connection Setup time

+ Average RAB Setup time for PS data Background
AVE SET UP T IMEFOR RRC (M1001C221) AVE SET UP T IMEFOR PS DAT ABACKGROUND RAB (M1001C235)

DENOMINAT OR FOR AVE SET UP T IMEFOR RRC (M1001C222) DENOMINAT OR FOR AVE SET UP T IMEFOR PS DAT ABACKGROUND RAB (M1001C236)

-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
• Paging
• UL Interference


-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_1 MAX_PRX_NOISE_VALUE MIN_PRX_NOISE_VALUE
xx/yy/2003 RNC0A S1 11 -101.5303476 417890 -102.2032753 417890 -96.20651315 -104.0488615
xx/yy/2003 RNC0A S2 21 -100.6359575 120433 -8.450980398 256097 -8.450980395 -8.450980399
xx/yy/2003 RNC0A S3 31 -100.1797349 418038 -101.5176085 418038 -98.38141601 -102.7430289
xx/yy/2003 RNC0A S4 41 -99.88490547 417646 -100.1795506 418082 -97.88041662 -102.6695255
xx/yy/2003 RNC0A S5 51 -99.13808872 418011 -103.0792801 418011 -96.89290798 -106.3280456
xx/yy/2003 RNC0A S6 62 -96.42019831 236918 -7.993405493 238251 -7.993405485 -7.993405494
xx/yy/2003 RNC0A S7 72 -95.55816508 417988 -100.6589406 417988 -94.13858107 -105.7031607
xx/yy/2003 RNC0A S8 81 -92.74359104 417909 -99.20143665 417996 -90.97058471 -105.9885019
xx/yy/2003 RNC0A S9 82 -92.12983064 418028 -99.37448848 418028 -90.98810486 -106.1318252
xx/yy/2003 RNC0A S10 101 -88.67772468 417997 -96.24871571 417997 -87.77917773 -104.9551382
xx/yy/2003 RNC0A S11 111 -73.0103741 417889 -88.20890215 417912 -82.83331727 -101.3714613

-UL Interference-
WBTS6 S6 WCEL62 UPLINK 10:10:10.0
• 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
• 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

-UL Interference-
• 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.

-UL Interference-
Cell suffering from UL

• Under the cell suffering from
interference = DL (CPICH) excessive >>5dB noise rise due to
coverage much bigger interference, it is extremely difficult to
Normal cell = UL & DL than UL coverage
coverage are balanced initiate a call
• RACH procedure might fail due to
not enough margin for power
ramp up (especially in case the
Cell A Cell B
UE is having problems with Open
Loop PC)
• Initial TX power for first PRACH
preamble
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

-UL Interference-
• 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

-UL Interference-
• 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. N
2. 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

-UL Interference-
• 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

-UL Interference-
• 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:
DPCCH_Powe r_offset  TxCPICH  Rx RSSI  SIRDPCCH  10  log( SFDPCCH )
• where TxCPICH is then PtxPrimaryCPICH - Cable Loss

-UL Interference-
• 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
After original commissioning -> no calls through After re-commissioning => call can be made
PrxTotal ~ -73dBm
PrxTotal ~ -105dBm
-UL Interference PIs : PrxTotal measurements-
• 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
X = collected sample of PrxTotal measurement • RSSI_LEV _619: -50.2 dBm <= RSSI < -50.1 dBm
• RSSI_LEV _620: -50.1 dBm <= RSSI < -50.0 dBm
• Sample 1 : Unloaded • RSSI_LEV _621: -50.0 dBm <= RSSI
• Sample 2 : Feasible load area 1 • The correct value in dBm can be

• Sample 3 : Feasible load area 2 obtained by formula:
• Sample 4 : Marginal load area -112.0dBm + (RSSI_LEV)/10
• Sample 5 : Overload area

• The PrxTotal measurements are divided into classes according to following
criteria:
CLASS AREA INCREMENTED IF

CLASS Unloaded (Lrt=<UnloadedRT) AND (Lnrt=<UnloadedNRT)
0
CLASS Feasible_Load_Area_ (PrxTarget -PrxOffset >= PrxTotal ) AND ((Lrt>UnloadedRT)
1 1 OR (Lnrt>UnloadedNRT))
CLASS Feasible_Load_Area_ (PrxTarget > PrxTotal > PrxTarget -PrxOffset) AND
2 2 ((Lrt>=UnloadedRT) OR (Lnrt>= UnloadedNRT))
CLASS Marginal_Load_Area (PrxTarget + PrxOffset > PrxTotal >=PrxTarget) AND
3 ((Lrt>UnloadedRT) OR(Lnrt> UnloadedNRT))
CLASS Overload_Area (PrxTotal >= PrxTarget + PrxOffset) AND ((Lrt>UnloadedRT)
4 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:
Measurement start time is: 2003 March 11th at 11pm and as This is number of
next was same date but 10pm the measurement/reporting samples during
period is 60min measurement period i.e.
as the period is one hour
WCELL Name Start Time AVE_PRXTOT PRXTOT_DENO and RRI period is 200ms
CLASS 0 M_0 -> 3600s/0.2s = 18 000,
PLMN-PLMN/RNC-2/WBTS- 2003031123 84 17972 some samples are not
1627/WCEL-16271 there but in general ~18
PLMN-PLMN/RNC-2/WBTS- 2003031122 86 17984 000 per one hour
1627/WCEL-16271
PLMN-PLMN/RNC-2/WBTS- 2003031121 88 17977
1627/WCEL-16271
This is already average value
WCELL Name Start Time AVE_PRXTOT PRXTOT_DENO

CLASS 0 M_0
[dBm]
PLMN-PLMN/RNC-2/WBTS- 2003031123 -112.0 + 84/10 = -103.6 17972
1627/WCEL-16271
1627/WCEL-16271
136 1627/WCEL-16271
© NOKIA Call Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential
-UL Interference PIs : PrxNoise measurements-
• 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
X = collected sample of PrxTotal measurement
• 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

-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
X = collected sample of PrxTotal measurement
• 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

-UL Interference PIs : PtxTotal measurements-
• 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:
X = collected sample of PtxTotal measurement

CLASS Unloaded PtxTotal = PtxCPICH + PtxPCCPCH
0
CLASS Feasible_Load_Area_ PtxTarget -PtxOffset > PtxTotal > (PtxCPICH + PtxPCCPCH)
1 1
CLASS Feasible_Load_Area_ PtxTarget > PtxTotal >= PtxTarget - PtxOffset
2 2
CLASS Marginal_Load_Area PtxTarget + PtxOffset > PtxTotal >= PtxTarget
139 3 © NOKIA Call Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential
-UL Interference PIs : Lrt & Lnrt measurements-
• There are specific counters for Lrt and Lnrt for each CLASS (0 … 4) defined
same way as for PrxTotal measurements.
• 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
X = collected sample of PrxTotal measurement message arrives
• Sample 1 : Unloaded
• Sample 2 : Feasible load area 1
• Sample 3 : Feasible load area 2
• Sample 4 : Marginal load area
• Sample 5 : Overload area
• 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   (1  i) Lown in a cell (own and
other cell user interference)
• the uplink interference a user will cause in the cell can be solved
R Prx R
Prx  Prx _ total  L L  load factor
R  W Prx _ total R  W
• the load factor of all the users in the cell Lown
Lown  L Prx _ own

 Lown
Own _ cell _ users Prx _ total

• From obtained fractional load :

Lnrt Lrt
N _ nrt _ active _ UL N _ rt _ active _ UL

1 1
Lnrt   W
Lrt   W
i 1
1 i 1
1
i Ri i Ri
Prx _ nrt N _ nrt _ active_ UL
1 Prx _ rt N _ rt _ active _ UL
1
Lnrt  Prx_nrt   W
 Prx_total Lrt  Prx_rt   W
 Prx_total
Prx _ total i 1
1 Prx _ total i 1
1
i Ri i Ri
Lrt + Lnrt = Lown Lown  L

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

-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 Unloaded PtxTotal = PtxCPICH + PtxPCCPCH
0
CLASS Feasible_Load_Area_ PtxTarget -PtxOffset > PtxTotal > (PtxCPICH + PtxPCCPCH)
1 1
CLASS Feasible_Load_Area_ PtxTarget > PtxTotal >= PtxTarget - PtxOffset
2 2
143
CLASS
© NOKIA
Marginal_Load_Area PtxTarget
Call Performance.PPT / 16-09-2003 /Reunanen Jussi
+ PtxOffset > PtxTotal >= PtxTarget
-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)
• Based on the Radio Link ID information
reported-RL-Information-RL-Meas-Rep
N _ nrt _ active_ UL N _ rt _ active_ UL - length (in bits): 00000
Ptx, nrt  P
i 1
tx,i Ptx, rt  P
i 1
tx,i
Reported-RL-InformationItem-RL-Meas-Rep
- extension flag: 0
- preamble: 00
- rL-ID: 1
where Ptx, i  Ptx _ av erag e where Ptx, i  Ptx _ av erag e - contents (in bits): 00001
measurement-1-Avail-Ind
- extension flag: 0
- choice index: 0
measurement-Available
From 25.133 - extension flag: 0
Reported value Measured quantity value Unit
UTRAN_CODE_POWER _010 -10.0  Transmitted code power < -9.5 dBm
- average-DL-TransmittedPower: 80
UTRAN_CODE_POWER _011 -9.5  Transmitted code power < -9.0 dBm - contents (in bits): 1010000
UTRAN_CODE_POWER _012 -9.0  Transmitted code power < -8.5 dBm - trailing bits: 0
… … …
UTRAN_CODE_POWER _120 45.0  Transmitted code power < 45.5 dBm

Contents
• Paging
• Call Setup Time
• UL Interference

• Loss of Synchronization DL/UL
• SHO Performance
Dropped Call Performance
-Loss of Synchronization UL-
• 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
-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

-Loss of Synchronization DL/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
Timer
N_OUTSYNC_IND T_RLFAILUR N_INSYNC_IND“in
Timer T313 “out of sync” E started sync” indicators
started indicators
Timer T313
stopped and reset
“out of sync” indicators Timer “in sync”

T_RLFAILUR indicators on L1
E stopped
and reset
N313 amount of “out of N315 L1 “in sync”
sync” indicators indicators

• if T313 expires:
T_L1_Sync_ReEstab_Wait
– consider it as a "Radio link failure" –timer started in RNC
Timer Timer T_L1_Sync_ReEstab_W

N_OUTSYNC_IND T_RLFAILURE
T_RLFAILUR ait –timer expired
“out of sync” E started expires
indicators
Timer T313 Timer T315
expires expires
RNC receives
Timer T313 NBAP:RADIO LINK RNC sends
“out of sync” indicators started Radio Link Failure NBAP:RADIO LINK
FAILURE –message form
BTS with a cause value DELETION –
"Synchronization Failure" message
N313 amount of “out

Enter Idle mode in case
of sync” indicators
Timer T315 Timer T314 timer T302 or T314 are
started started not running. T302 is the
timer for Cell/URA
When the criteria for When the criteria for Update retransmissions.
radio link failure are radio link failure are
Re-establishment fulfilled. fulfilled. No re-
timer for NRT The timer is started only The timer is started if establishment for
services (AM if radio bearer(s) that are radio bearer(s) that are RT services in
bearers) associated with T315 associated with T314 current release ->
exist. Currently all the exist of if only RRC T314 is for Tr and
radio links are associated connection exists. UM bearers
with T315
Not implemented in
151 © NOKIA Call Performance.PPT / 16-09-2003 /Reunanen Jussi Nokia
Company RAN currently
Confidential
• 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
• Paging
• Call Setup Time
• UL Interference

• SHO 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 Value

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

-SHO Performance-
• CPICH Ec/No Filter Coefficient: Parameters Value
Addition Window (dB) 2.5
Max AS Size= 3, CPICH Filter Coefficient Changed (1)
Addition Time (ms) 100
Drop Window (dB) 4
Drop Time (ms) 640
Replacement Window (dB) 2
Replace Time (ms) 100
Maximum Active Set Size 3
CPICH Ec/No filter Coefficient 0, 1, 2, 3, 4, 5, 6
Active Set Weighting Coefficient 0
3 (600ms), default By comparing the

results of different 0 (200ms) By comparing the results
4 (800ms)
parameter sets, 2 (400ms) of different parameter
5 (1100ms)
3 (600ms), default sets, the default value 3
6 (1600ms) the default value 3 should be the optimal
should be the one---highest SHO gain,
17 optimal one--- good KPIs and proper
8
highest SHO gain, SHO overhead.
3 1.9 1.5 1.5
good KPIs and
1.1 1.5 1.5
proper SHO
Number of dropped calls Average active set size Averageoverhead.
time between UE Power (dBm)
Power (dBm) (RT) AS updates (s)
8.5 -9.9 -9.3 -10.4 -11.3 -11.6

-SHO Performance-
Parameters Value
60ms Addition Window (dB) 2.5
Max 80ms
AS Size= 3, By looking
DropTime at the No. of
Changed Addition Time (ms) 60, 80, 100, 120, 160
100ms, default dropped calls, only 80ms Drop Window (dB) 4
120ms and 100ms could be
Drop Time (ms) 640
160ms acceptable. The SHO
overhead with AddTime=
80ms is too high, so Replace Time (ms) 100
100ms was selected as Maximum Active Set Size 3
the best one. CPICH Ec/No filter Coefficient 3
ower (dBm)
-11.6
240ms
5 -14.4-14.7
320ms
Only the value
640ms, default
Parameters Value 1280ms
640ms can provide
Addition Window (dB) 2.5 an acceptable
22
Addition Time (ms) 60 KPIs by looking at
Drop Window (dB) 4 the number of
10 120, 240, 320, 640, 1280
Drop Time (ms) dropped calls.
3 Replacement1.4Window
1.5 1.5(dB)1.6 1.5 1.2 1.5 2.1 2
Maximum
r of dropped Active Sactive
calls Average et Sizeset size Average time between UE3Power (dBm)
CPICH Ec/No filter Coefficient
(RT) AS updates (s) 3 -7.6
Active Set Weighting Coefficient 0-10.9-11.6
-13.7
-SHO Performance-
Parameters Value
ged
Addition Window (dB) 0.5, 1.5, 2.5, 3.5
Drop Window (dB) 2, 3, 4, 5 By considering the
0.5 / 2 (dB)
Drop Time (ms) 640 SHO overhead,
1.5 / 3 (dB)
Replacement Window (dB) 2 2.5 / 4 (dB), default Number of dropped
Replace Time (ms) 100 3.5 / 5 (dB) calls and UE Tx
Maximum Active Set Size 3 power at the same
23 time, the parameter
CPICH Ec/No filter Coefficient 3
Active Set Weighting Coefficient 0 set 1.5 /3 is seen as
11
the best one.
5
3 2.0 1.7 1.5 1.4
1.2 1.3 1.5 1.7
umber of dropped Average active set size

By comparing
Average time between UE Power (dBm)
calls 1.5 / 2.5 (dB)
(RT) theupdates
AS SHO(s)
1.5 / 3 (dB) overhead, -11.6
1.5 / 3.5 (dB) number of drop -14.9-14.2 -15.9
Parameters Value
1.5 / 4.5 (dB) calls and UE Tx Addition Window (dB) 1.5
1.5 / 7.5 (dB) power, the Addition Time (ms) 100
parameter set Drop Window (dB) 2.5, 3, 3.5, 4.5, 7.5
1.5/ 2.5 is the Drop Time (ms) 640
best one. Replacement Window (dB) 2
159
Power (dBm)
© NOKIA Call Performance.PPT / 16-09-2003 /Reunanen Jussi Active Set Weighting Coefficient
Company Confidential 0
-SHO Performance-
Parameters Value
2.5 / 3.5 (dB)
2.5 / 4 (dB), default
Drop Window (dB) 3.5, 4, 4.5, 5.5 The tested
2.5 / 4.5 (dB)
Drop Time (ms) 640 2.5 / 5.5 (dB) sets did not
show better
Maximum Active Set Size 3 performance
7 CPICH Ec/No filter Coefficient 3 as the set 1.5/
4 Active Set Weighting Coefficient 1.4 1.5 2.4 1.7
1.4 1.5 1.5 1.6
0 2.5.
ropped Average active set size Average time between UE Power (dBm)
(RT) AS updates (s)
-11.6-13.0
-13.6
-15.3
1dB
The value 1 can gives
more SHO gain (lower
2dB Parameters Value
UE Tx power) and
better performance
(less number of Drop Window (dB) 3
dropped calls), but the Drop Time (ms) 640
effect is not so Replacement Window (dB) 1, 2
significant. Replace Time (ms) 100
m) 160 © NOKIA Call Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential
-SHO Performance-
Parameters Value
Drop Window (dB) 3
Drop Time (ms) 640 Max AS size= 2 gives
Replacement Window (dB) 2 lower SHO overhead,
Max AS size= 2
Replace Time (ms) 100 but the value 3
Max AS size= 3
Maximum Active Set Size 2, 3 provides more SHO
CPICH Ec/No filter Coefficient 3 gain. No big
difference for the
other KPIs. Max AS
5 5
size= 3 was still the
1.3 1.3 2.1 1.7 better one.
er of dropped Average active set sizeBetter
Average time between
performance UE Power (dBm)
with
calls (RT) AS updates (s)
100ms 100ms by looking at the
640ms number of dropped calls.-13.2 -14.2
But both the parameter Parameters Value
have no big affect to the Addition Window (dB) 1.5
SHO gain and SHO Addition Time (ms) 100
overhead Drop Window (dB) 3
Drop Time (ms) 640
Replace Time (ms) 100, 640
Bm)
161 © NOKIA Call Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential Active Set Weighting Coefficient 0
Set Weighting Coefficient Changed Dropped Call Performance
-SHO Performance-
Parameters Value
Drop Window (dB) 3
Drop Time (ms) 640
Active Set Weighting Coefficient 0, 1
The value 1 can
ASWeightingCoeff= 0
ASWeightingCoeff= 1
give us lower SHO
overhead and
Active Set Weighting Coefficient is more gain (lower
used to weight either the measurement UE Tx power) at
result of the best active set cell (M_best)
the same time. But
or the sum of measurement results of all
active set cells (M_sum) when the UE this parameter still
calculates the reporting range for the need fullly test.
1.3 1.3 1.7 1.3
events 1A and 1B.
verage active set size Average time between UE Power (dBm)
(RT) AS updates (s)
-14.24
-17.28
-SHO Performance-
• 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
200
• Case A:
• Average time between
# of events
150 Measurement 3
100 Measurement 2 Active Set Update is 2-3
50 Measurement 1
seconds which is very
0
small compared to the
9 - 10
10 - 11
11 - 15
15 - 20
20 - 25
0-1
1-2
2-3
3-4
4-5
5-6
6-7
7-8
8-9
Case B
seconds
ASU time
• Case B:
• Average time between
45
40
active set updates is 5-10
35 seconds
30
# of ASUs
25
20
ASU time • It can be seen that the
15 smaller cells (a lot of micro
10
5 cells in Case A and only
0 macros in Case B) shorter the
time between ASUs
seconds from call setup
-SHO Performance-
• 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!

-SHO Performance-
• ASU period can be measured based on the counters as:
T otaltimeof measurement - (One cell in theactiveset for RT (M1001C0)

One cell in theactiveset for NRT (M1007C19))
Avg Tim ebetween AS Update
sum(successful ActiveSet UpdatesOnSHO For RT T raffic(M1007C15)
Successful ActiveSet UpdatesOn SHO For NRT T raffic(M1007C32))
• 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
No calls AS update AS update No calls
AS update AS update
AS update AS update
AS update AS update
AS size=1 AS size=2 AS size=3 AS size=2 AS size=1

AS size=1 AS size=2 AS size=3 AS size=2 AS size=1
Total Time of Measurement

-SHO Performance-
• 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
measurement measurement report
report sent : AMR sent : PS 384 • This kind of UE behavior
Ec/No cannot be completely fixed
but results can be improved
by adjusting:
• Addition window
• Addition time
• Replacement window
Addition window /
Replacement window • Replacement time
time
Ideal timing for measurement measurement
report sending after e.g. report sent : PS 64
Addition time or UDI (CS T64)
-SHO Performance-
UE seem to have parallel processes
ongoing I.e. measurement control and
Plotted Data [ Line(6501 to 7000); Time(11:34:34 to 11:35:38) ]
therefore there is 2sec. delay in sending
Time Message Monitored Active Set the measurement report
100 Set SC / SC / Ec/No 10
Ec/No [dB] [dB]
80
11:35:20 Measurement Control 5
11:35:20
60 188 / -8.5 309 / -9.5 97
35 / -13.5 / -18.5
0
40
11:35:21 188 / -3.5 309 / -11.5
35 / -8.5 97 / -23.5
20 -5
11:35:22 188 / -5.5 309 / -12.5
EcNo/ASS
0 35 / -10.5 97 / -23.5
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
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
N/A
21[A]
21[A]
21[A]
21[A]
0[A]
-10
Measurement Report SC188 = -5.5 SC309 = -
-20
e1c: SC188, SC35, SC35 = -10.5 12.5 SC97 =
SC309, SC97 -23.5 There is no response -15
-40
11:35:22 188 / -5.5 309 / -19.5 to measurement
35 / -11.5 97 / <-24 report e1c –
-60
messages by the -20
11:35:23 188 / -5.5 309 / -21.5 network as the first
-80 35 / -14.5 97 / <-24
measurement report
-100
is sent “too late” by-25
Measurement Report
e1c: SC188, SC35,
the UE and the call
-120 SC309, SC97 drops -30
CpichRscp Sir TargetSir UeTxPower HOIndication DpchRscp DlTransportChannelBler_1 CpichEcNO ActiveSetSize

-SHO Performance-
• 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
Poor
performan High BLER, high
ce due to variance with DL SIR Low variance
coverage and a lot of SHO of SIR, ASS=2,
activity stable BLER
and throughput

-SHO Performance: UL Interference-
interference = DL (CPICH)
Normal cell = UL & DL coverage much bigger than
coverage are balanced UL coverage
Cell A Cell B
• Cell B is having higher PrxNoise level

than Cell A which is causing the UL and
DL coverage to be very much different.
• 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

interference = DL
UE BTS RNC Normal cell = UL & (CPICH) coverage
DL coverage are much bigger than UL
RRC: Measurement Report (e1a / e1c) balanced coverage
Decision to set up new RL
NBAP: Radio Link Setup Request
Cell A Cell B
Start TX/RX UL Synchronisation Procedure starts
NBAP: Synchronization
NBAP: Radio Link Setup Response
Active Set
ALCAP:ERQ Update: 1a, 1c
DL
Indication
to add cell B
ALCAP:ECF
RRC: Active Set Update UL & DL
UE Synchronisation Procedure starts: According to Ec/No
Synchronisation Procedure B
Addition window /
UL
RRC: Active Set Update Complete Replacement window
Addition/ distance
Replacement
time Active Set Update
• As the UE Tx power is not enough for Cell B complete
UE -> RNC :
synchronisation, the SHO can fail Measurement report :
e1a / e1c

interference = DL (CPICH)
Normal cell = UL & DL coverage much bigger than
coverage are balanced UL coverage
Cell A Cell B
T313 expires -> UE
BTS stops UL considers Radio Link
Less than N_INSYNC_IND indicators Synchronization Failure for Cell B -> UE
on L1 procedure and Tx drops the Cell B from AS
L1 Synchronization not
Measurement UE starts T313 for Cell
RNC sends RRC: Active Set established BTS does NOT B after receiving N313
report e1A:
Update - message to UE -> send NBAP: out-of-sync for Cell B
CellB
Starts timer SYNCHRONIZATION IDICATION
T_RRC_Resp_DCH -message
SHO Decision After receiving ASU BTS UL Synchronization

RNC sends Counter: RL DEL ON
algorithm Cell B - UE Starts DL procedure continues until L1
NBAP:RADIO LINK SRNC DUE TO INI SYN
> Setup RL -> Synchronization Synchronization is achieved or
DELETION –message FAIL (M1005C67) -
NBAP: Radio procedure -> and NBAP: RL Deletion –message is updated
Link Setup sends ASU received
Request (Chip Complete
Offset)
Successful resource allocation in Cell B BTS -> BTS RNC does not receive
Starts Tx (DPCH) -> BTS Starts UL Synchronization synchronization indication ->
procedure
171 and
© NOKIA sends NBAP: Radio Link Setup Response
Call Performance.PPT / 16-09-2003 /Reunanen Jussi timer T_RRC_RRC_Resp_DCH
• The ways to fix this case are:
• Use CPICH Tx power in the BTS to balance the UL interference = DL (CPICH)
coverage much bigger
and DL coverage i.e. decrease the CPICH Tx power Normal cell = UL & DL
coverage are balanced
than UL coverage
by the UL noise rise

+ Can be done cell by cell basis
+ Relatively easy to implement algorithm for
Cell A Cell B
autotuning L1 synchronization
not achieved between
- Coverage is reduced also in the cases when new cell and UE,
monitored by the BTS
there is no UL interference Active Set
- Requires autotuning feature otherwise cell

Update: 1a,
1c to add cell
DL
coverage is reduced in DL all the time UL & DL B
UL
• Use cell individual offset to lower the CPICH Ec/No Ec/No DL
by the noise rise value
RNC sends
+ Can be done cell by cell basis Addition window /
Replacement window
Drop
window Active Set
Update :
+ Does not affect to the coverage e1b to
remove the
- Needs some algorithm to tune the cell individual Addition/ distance cell A
Replacement
offset according to existing noise rise time
Active Set
- The UEs might have problem with too big Update
UE -> RNC : complete
difference between actual CPICH powers also Measurement report :
e1a / e1c
DL power drifting might cause problems

• The ways to fix this cases are: Cell suffering from UL
• Increase the Drop window setting so that UL interference = DL (CPICH)
coverage much bigger
synchronization is achieved to the target cell Normal cell = UL & DL
than UL coverage
- 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 Cell A Cell B
basis somehow L1 synchronization
not achieved between
+ Easy to test to see if situation can be improved new cell and UE,
monitored by the BTS
- The UEs might have problem with too big Active Set
difference between actual CPICH powers also

Update: 1a,
1c to add cell
DL
DL power drifting might cause problems UL & DL B
• Change the drop timer to be long enough so that UL UL
synchronization is achieved to the target cell Ec/No DL
- New drop time is used for each neighbor cell Addition window / Drop RNC sends
definition Replacement window window Active Set
Update :
- Needs some algorithm to tune the drop time e1b to
remove the
according to existing noise rise and cell by cell Addition/
Replacement
distance cell A
basis somehow time

Active Set
- Easy to test to see if situation can be improved Update
UE -> RNC : complete
- The UEs might have problem with too big Measurement report :
e1a / e1c
difference between actual CPICH powers also
DL power drifting might cause problems

-SHO Performance : Cell Individual Offsets-
• 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 Cell A Cell B
therefore have the connection on
without dropped calls Without cell individual offsets
UL & DL
UL & DL
The call drops due to
Ec/No too rapid CPICH
coverage degradation
for Cell A, and therefore
there is not enough time
for SHO
Cell A route
Addition window /
Replacement
window
Addition/
Cell B UE -> RNC : Replacement
Measurement report : time
174 © NOKIA Call Performance.PPT / 16-09-2003 /Reunanen Jussi Company e1a
Confidential
/ e1c
-SHO Performance : 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 Cell A Cell B
shortened)
DL
• See next case With cell individual offsets
Active Set
Update: 1a, 1c
UL
to add cell B
UL & DL Cell individual offset
Ec/No
Cell A route
Addition window /
Replacement Active Set Update
window complete
UE -> RNC : Addition/

Cell B Measurement report :
e1a / e1c
Replacement
time
-DL Coverage < UL Coverage-
Cell having lower DL
• In case there is a cell with lower coverage = DL (CPICH)
CPICH power than the Normal cell = UL & DL
power is lower than adjacent
cells
surrounding cells’ are having
then this cell is having “too
good” UL performance as this Cell A Cell B
cells’ UL cannot be used Active Set
efficiently due to SHO is decided Update: 1a, 1c
to add cell B
upon DL (CPICH Ec/No)
Cell B starts to UL
• To improve this and include the UL & DL suffer from UL
interference due to
cell into AS earlier than CPICH UE getting closer
Eke/No would allow, it is Ec/No to Cell B wo SHO DL
possible to use cell individual
offsets for this purpose
distance
Addition window /
Replacement
window Active Set Update
complete
Addition/
UE -> RNC : Replacement
Confidential
/ e1c
• If Cell B is having cell individual coverage = DL (CPICH)
offset set according to the Normal cell = UL & DL
cells
difference of CPICH powers
between Cell A and Cell B, the
SHO can happen “correct” time Cell A Cell B
and Cell B can be utilized fully
• However currently the added Active Set
cell’s initial Tx power is set Update: 1a, 1c
to add cell B UL
according to the existing cell i.e. UL & DL
• In case the best cell Ec/No is
known Ec/No DL
 
MAX   R 
Ptx, init 
TFCTFCS
 TF TFC   IL ( c, Ptx_total),
p
W
distance
Addition window /
1 Replacement
ILP ( c, Ptx_total)   Ptx, CPICH    Ptx_total. window Active Set Update
c complete
Addition/
Confidential
/ e1c
• However currently the added coverage = DL (CPICH)
cell’s initial Tx power is set Normal cell = UL & DL
cells
according to the existing cell i.e.
• In case the best cell Ec/No is
not known Cell A Cell B
Ptx,initial,new  Ptx,ave,highest  Ptx,CPICH ,new  Ptx,CPICH ,highest
Active Set
• It should be noted that neither of Update: 1a, 1c
to add cell B UL
the formulas include information UL & DL Cell individual offset
about the cell individual offset
and due to that the SHO to cell, Ec/No DL
Tx power for the Cell
which is having cell individual B DPCH is not
enough -> DL synch
offset (“high” value), might have not achieved -> SHO
failure
problems
• Synchronization in DL Addition window /
distance
direction difficult Replacement
Active Set Update
window
complete
Addition/
Confidential
/ e1c
Dropped Call Performance Received message RRC: Measurement Report (e1A).
Triggers for RT:
M1007C10 CELL ADDITION REQUEST ON SHO FOR RT
-SHO Performance : PIs-
TRAFFIC
Received message RRC: Measurement Report (e1B).
BTS RNC Triggers for RT:
UE M1007C11 CELL DELETION REQUEST ON SHO FOR RT
RRC: Measurement Report (e1a / e1c) TRAFFIC
Received message RRC: Measurement Report (e1C).
Triggers for RT:
Decision to M1007C12 CELL REPLACEMENT REQUEST ON SHO FOR
set up new RL RT TRAFFIC
Received message RRC: Measurement Report (e1A).
NBAP: Radio Link Setup Request – for Soft Handover Triggers for NRT:
NBAP: Radio Link Addition Request – for Softer HandoverM1007C27 CELL ADDITION REQUEST ON SHO FOR NRT
TRAFFIC
Start TX/RX Received message RRC: Measurement Report (e1B).
Triggers for NRT:
NBAP: Radio Link Setup Response M1007C28 CELL DELETION REQUEST ON SHO FOR NRT
TRAFFIC
NBAP: Radio Link Addition Response Received message RRC: Measurement Report (e1C).
ALCAP:ERQ Triggers for NRT:
For each
M1007C29 CELL REPLACEMENT cell already
REQUEST ON SHO in FOR
AS the
ALCAP:ECF NRT TRAFFIC above counters are updated
RRC: Active Set Update i.e. in this case 2 cells
RRC: Active Set Update Complete B

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

Dropped Call Performance Number of DCH requests for Diversity HO (SHO) for voice calls
-SHO Performance: PIs- in SRNC
M1002C16 RT DCH DHO REQ FOR CS VOICE CALL IN
SRNC
UE BTS RNC Number of DCH requests for a CS Voice Call rejected by the
SRNC for reasons caused by radio resources in the target cell
RRC: Measurement Report (e1a / e1c) of diversity handover
M1002C17 RT DCH DHO REQ FOR CS VOICE CALL
Decision to set up new RL REJECT IN SRNC
Number of DCH requests for a transparent CS Data Call with
NBAP: Radio Link Setup Request conversational class due to diversity handover in the SRNC
M1002C58 RT DCH DHO REQ FOR CS DATA CALL CONV
UL Synchronisation Procedure starts
Start TX/RX CLASS IN SRNC
NBAP: Synchronization Indication

Number of DCH requests for a transparent CS Data Call (on
NBAP: Radio Link Setup Response SRNC side) rejected for reasons caused by radio resources in
the target cell of diversity handover
ALCAP:ERQ M1002C59 RT DCH DHO REQ FOR CS DATA CALL CONV
CLASS REJECT IN SRNC
ALCAP:ECF SRNC A total number of DCH requests for a nontransparent CS
RRC: Active Set Update Data Call with streaming class due to diversity handover in the
SRNC
UE Synchronisation Procedure starts: M1002C60 RT DCH DHO REQ FOR CS DATA CALL STREAM
According to Synchronization Procedure B CLASS IN
RRC: Active Set Update Complete Number 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 handover
M1002C61RT DCH DHO REQ FOR CS DATA CALL STREAM
CLASS REJECT IN SRNC
In case BTS responses back to RNC by NBAP: RL
Setup Response/RL Addition Response SAME FOR DRNC!
M1005C6: RL SETUP SUCC FOR SHO ON In case of RNC sends to BTS NBAP: RL Setup Request/RL
SRNC Addition Request
M1005C8:RL SETUP SUCC FOR SHO ON DRNC M1005C1: RL SETUP ATT FOR SHO ON SRNC
M1005C44: RL BRANCH ADD SUCC FOR SHO M1005C3:RL SETUP ATT FOR SHO ON DRNC
ON SRNC M1005C42: RL BRANCH ADD ATT FOR SHO ON SRNC
M1005C45: RL BRANCH ADD SUCC FOR SHO M1005C43: RL BRANCH ADD ATT FOR SHO ON DRNC
ON SRNC
UE BTS RNC Received message RRC: Active Set Update Complete.
Triggers:
RRC: Measurement Report (e1a / e1c) M1007C15 SUCCESSFUL ACTIVE SET UPDATES ON SHO
FOR RT TRAFFIC
Decision to Received message RRC: Active Set Update Complete.
set up new RL Triggers:
M1007C32 SUCCESSFUL ACTIVE SET UPDATES ON SHO
NBAP: Radio Link Setup Request FOR NRT TRAFFIC
Received message RRC: Active Set Update Failure. Triggers:

Start TX/RX M1007C16 UNSUCCESSFUL ACTIVE SET UPDATES ON
NBAP: Radio Link Setup Response SHO FOR RT TRAFFIC
Received message RRC: Active Set Update Failure. Triggers:
ALCAP:ERQ M1007C33 UNSUCCESSFUL ACTIVE SET UPDATES ON
SHO FOR NRT TRAFFIC
ALCAP:ECF
RRC: Active Set Update
RRC: Active Set Update Complete For each cell in the AS the above counter(s)
RRC: Active Set Update Failure are updated (including the cell to be deleted
from AS in case of e1B)

UE is in Spot A i.e. not UE BTS RNC
in soft handover -> AS UE in Spot B sends RRC: Measurement Report (e1a / e1c)
size = 1 Measurement report
indicating e1A to add Decision to set up new RL
cell 2 -> M1007C10 NBAP: Radio Link Setup Request
CELL ADDITION UL Synchronisation
Start TX/RX
REQUEST ON SHO Procedure starts
FOR RT TRAFFIC is NBAP: Radio Link Setup Response
2 updated in cell 1 ALCAP:ERQ

B ALCAP:ECF
1
A
RNC Makes AC/RM for the SHO – updates

M1002C16 RT DCH DHO REQ FOR CS VOICE
CALL IN SRNC counter in cell 2
RNC sends NBAP: RL Setup Request to BTS – BTS receives the NBAP; RL Setup
updates M1005C1: RL SETUP ATT FOR SHO ON Request, if RL Setup Is successful, starts
SRNC counter in cell 2 TX/RX and UL Synchronization procedure
and sends NBAP: RL Setup Response to
RNC

UE BTS RNC
RNC Sends RRC: Active Set Update – RRC: Measurement Report (e1a / e1c)
message to the UE Decision to set up new RL
NBAP: Radio Link Setup Request
UL Synchronisation
Start TX/RX
Procedure starts
2 NBAP: Radio Link Setup Response
B ALCAP:ERQ
1
ALCAP:ECF
After receiving RRC: Active Set Update from RNC UE Synchronisation Procedure starts:
According to Synchronization Procedure B
the UE checks the Update message and if ok UE
RRC: Active Set Update Complete
starts Synchronization Procedure B and and
sends RRC: Active Set Update Complete
message without waiting for the completion of the
When receiving RRC: Active Set Update
Physical Layer synchronization procedure B Complete, the RNC updates M1007C15
(according to 25.214/25.331) SUCCESSFUL ACTIVE SET UPDATES ON
SHO FOR RT TRAFFIC or M1007C32
SUCCESSFUL ACTIVE SET UPDATES ON
SHO FOR NRT TRAFFIC counter. Counter
183 © NOKIA Call Performance.PPT / 16-09-2003 /Reunanen Jussi updated for cell 1.
• The Active Set Update success rate can be calculated as:
sum( SuccessfulActive SetUpdatesOn SHO For RT Traffic( M 1007C15))

Active SetUpdateSuccessRatio( RT )  100* %
sum( SuccessfulActive SetUpdatesOn SHO For RT Traffic( M 1007C15) 
Unsuccessful Active SetUpdatesOn SHO For RT Traffic( M 1007C16))
sum( SuccessfulActive SetUpdatesOn SHO For NRT Traffic( M 1007C 32))

Active SetUpdateSuccessRatio( NRT )  100* %
sum( SuccessfulActive SetUpdatesOn SHO For NRT Traffic( M 1007C 32) 
Unsuccessful Active SetUpdatesOn SHO For NRT Traffic( M 1007C 33))
UE BTS RNC
RRC: Measurement Report (e1a / e1c)
• Formula does not take into account the Decision to set up new RL
cases where measurement report is sent NBAP: Radio Link Setup Request
several times until RNC responds with UL Synchronisation
Start TX/RX
RRC: Active Set Update -> Procedure starts
Counters1007C16 and 1007C33 are ALCAP:ERQ
updated only in case UE responds to 1 ALCAP:ECF
Active Set Update –message with Active RRC: Active Set Update
Set Update Failure –message. UE Synchronisation Procedure starts:
• 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
• 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)
• 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)
Radio Link Set Up / AdditionSuccess ( SHO) 
BTS RNC
M1005C42 M1005C43 M1005C1 M1005C3 UE
100* % RRC: Measurement Report (e1a / e1c)
M1005C44 M1005C45 M1005C6 M1005C8
Decision to set up new RL
• And separate failure reasons can be NBAP: Radio Link Setup Request
identified based on M1005C16 – M1005C21, Start TX/RX
UL Synchronisation
M1005C28 – M1005C33, M1005C46 – Procedure starts
M1005C57 and M1005C58 – M1005C65 NBAP: Radio Link Setup Response
ALCAP:ERQ
ALCAP:ECF
UE Synchronisation Procedure starts:
2 RRC: Active Set Update Complete
• 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
DCH AllocationSuccess( SHO) 
 M 1002C17  M 1002C 59  M 1002C 61 M 1002C103 M 1002C105 M 1002C107  M 1002C109 
1   100%
 M1002C16 M1002C58 M1002C60 M1002C102 M1002C104 M1002C106 M1002C108
• Where nominator is stating the number of

DCH allocation requests in the target cell UE BTS RNC
for Diversity Handover (SHO) for RT traffic RRC: Measurement Report (e1a / e1c)
classes (Speech+Conversational CS data + Decision to set up new RL
Streaming CS Data) and NRT traffic NBAP: Radio Link Setup Request
classes (Conversational PS data + UL Synchronisation
Start TX/RX
Streaming PS data + Interactive PS data + Procedure starts
Background PS data)
ALCAP:ERQ
• Where denominator is the allocation ALCAP:ECF
rejections due to lack of radio resources in RRC: Active Set Update
target cell UE Synchronisation Procedure starts:

-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

-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
• Paging
• Call Setup Time
• UL Interference

• SHO Performance
-Power per Connection-
• Observations from the case on the right: 40 100
• 1. SIR cannot be maintained at the

Call drop 90
correct level 20
• 2. Ec/No is ok 1. 80
• 3. BLER Increases to 100%
0
• 4. Target SIR increases at the same
15:45:08.00
15:45:08.00
15:45:09.00
15:45:10.00
15:45:10.00
15:45:12.00
15:45:13.00
15:45:14.00
15:45:15.00
15:45:15.00
15:45:16.00
15:45:16.00
15:45:11.00
70
time as BLER increases to 100% 2.
-20
60
-40 50
• As the SIR getting lower and lower until e1b, 1 active set cell DLTrchBLER
the call drops this suggests that the DL dropped (become 1-way increase rapidly
3.
40
active)
power has reached its maximum -60
30
-80
4. 20
• This case can be improved by allowing -100
more power window in DL for the PC to 10
operate
-120 0
Ec EcIo Sir TargetSir ActiveSetSize DlTrChBler

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

CPICHtoRefRabOffset
• the max DL TX power is determined by AC as:
Ptx,max  MIN ( RI max, eff  Ptx,ref , N dpch  Ptx _ DPCH _ max )   RI max Ptx,CPICH
RI max, eff  Ptx,ref 
 ref  RI ref C pichTo Re fRabOffset
DL tx pwr per DL tx pwr per

Connection [dBm] Connection [dBm]
/ BLER [%] / BLER [%]
Max
power
Max
power
Min
power
Min
power
time time
Call drop
• 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
• Paging
• Call Setup Time
• UL Interference

• SHO Performance
Contents
• Paging
• Call Setup Time
• UL Interference

• SHO Performance
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 Performance
BLER versus avg. RTT for different ping sizes using 64 kbps
bearer
900
800
700
RTT in milli seconds
600
32 bytes
500
512 bytes
400
1472 bytes
300
200
100
0
0 5 10 15 20 25
BLER %

PS Call Performance
Avg. Round Trip Times for different ping sizes at various BLER using
64kbps bearer
900
800
700
Delay in milli seconds
600
0.63% BLER
500
1% BLER
400 5% BLER
20% BLER
300
200
100
0
0 200 400 600 800 1000 1200 1400 1600
Ping Size in bytes

PS Call Performance
BLER versus Average FTP Upload Throughputs for various file sizes
using 64kbps bearer
60
50
Throughput in Kbit/s
40 16KB
64KB
30
500KB
20 1024KB
10
0
0 5 10 15 20 25
BLER %

PS Call Performance
FTP Upload Throughputs at different BLER & file sizes using
64kbps bearer
60
50
Throughput in kbit/s
40
0.63% BLER
1% BLER
30
5% BLER
20% BLER
20
10
0
0 200 400 600 800 1000 1200
File sizes in kilo bytes

PS Call Performance
• Standard deviations in the Round Trip Times
(milliseconds) for each ping size at a certain BLER level
Ping Size 32 bytes 512 bytes 1472 bytes
BLER
%
0.63% 11ms 22ms 37ms
1% 25ms 36ms 42ms
5% 86ms 98ms 114ms
20% 172ms 214ms 144ms

PS Call Performance
0.63 % BLER 1 % BLER
1MB 0.63 % BLER 1MB 1 % BLER
UL # Total bytes Re-xmt bytes Re-xmt % UL # Total bytes Re-xmt bytes Re-xmt %
1 1048404 0 0,0 % 1 1048404 0 0,0 %
2 1048404 0 0,0 % 2 1048404 0 0,0 %
3 1048404 0 0,0 % 3 1048404 0 0,0 %
DL5 #% BLER
Total bytes Re-xmt bytes Re-xmt % 20#% BLER
DL Total bytes Re-xmt bytes Re-xmt %
1 1048404 0 0,0 % 1 1048404 0 0,0 %
1MB 2 5 %1048404
BLER 0 0,0 % 1MB 2 20 % BLER
1048404 0 0,0 %
3 1048404 0 0,0 % 3 1048404 0 0,0 %
UL # Total bytes Re-xmt bytes Re-xmt % UL # Total bytes Re-xmt bytes Re-xmt %
1 1048404 0 0,0 % 1 1048404 67160 6,4 %
2 1048404 0 0,0 % 2 1048404 67238 6,4 %
3 1048404 0 0,0 % 3 1048404 52560 5,0 %
DL # Total bytes Re-xmt bytes Re-xmt % DL # Total bytes Re-xmt bytes Re-xmt %
1 1048404 0 0,0 % 1 1048404 0 0,0 %
2 1048404 0 0,0 % 2 1048404 0 0,0 %
3 1048404 0 0,0 % 3 1048404 0 0,0 %

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

WRST 4 Module Three: WRST 4 Jussi Reunanen & Benoist Guillard & Supranee Sarinkarnpoonperm

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WRST 4 Module Three: WRST 4 Jussi Reunanen & Benoist Guillard & Supranee Sarinkarnpoonperm

Uploaded by

Copyright:

Available Formats

WRST 4

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

• Dropped Call Performance

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

UE moving from Cell A towards Cell B

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

UE starts the neighboring

UE “hangs” in CELL A until

CPICH RSCP CPICH Ec/No

Calls setups very successful

• In order to optimise the call setup performance following changes are

• Note: remember to tick on the tick box in front of the Sintrasearch

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

Calls setups very successful

Calls setups difficult

Calls setups failures

• There is significant improvement

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

• CPICH Ec/No = -15dB can be considered as

CPICH Ec/No [dB]

Parameter Default Case4 Case5

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

Idle mode (Stationary test)

Idle mode (Drive test)

AMR MOC (Stationary test)

AMR MOC (Drive test)

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

Call Setup Success Rate

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

• What is the difference between Qhyst2 and Qhyst1?

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

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

• Dropped Call Performance

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

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

• Paging for UEs in CELL_PCH or URA_PCH UE RNC SGSN

The MAC-d (RLC) in

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

• Paging for UEs in CELL_FACH or CELL_DCH

UE is in CELL_FACH or CELL_DCH state RANAP:PAGING

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

• The counters M1001C32, M1001C34, M1001C36 and M1001C38 are

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

• What is the response to the paging message?

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

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

• Dropped Call Performance

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

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

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

CPICH Ec/No as reported by fingers

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

CPICH RSCP [dBm]

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

NBAP: RL Setup Request

[RACH] RRC:RRC Connection Request

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

Repetition Counter Default Usage

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

• When load of the network increases, too short repetition interval of

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

NBAP: RL Setup Request

NBAP: RL Setup Response