Call Performance

WRST 4
Module Three
W
RS
T
Call Performance
WRST 4
Jussi Reunanen
&
Benoist Guillard
&
Supranee Sarinkarnpoonperm
1
NOKIA
Call Performance.PPT / 16-09-2003 /Reunanen Jussi
Company Confidential
D
ss
el
d
or
f
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
2
NOKIA

-Idle Mode Cell Reselection-
Several UEs cannot perform cell reselection during RRC

Connection Setup phase (Kenny can sw >12.8x)
CPICH Ec/No
CPICH RSCP
-100dB
UE does not
start the cell
reselection
procedure if
default
parameter
settings are
used
UE Sends
First RRC
Connection
Request
Message
RF Conditions
OK and CPICH
Ec/No is
10dB
RNC responds with RRC

Connection Setup message
which is not heard by the UE
due to CPICH Ec/No falls
below 15dB
CPICH Ec/No
CPICH RSCP
-10dB
-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
NOKIA
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 reselection 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)
4
NOKIA

Default parameter settings

CPICH Ec/No
CPICH RSCP
UE starts the
neighboring cell
measurements here
and it takes some time
to perform the
reselection
UE hangs in CELL A
until
QqualMin+Sintrasearch =
-16dB threshold is
reached.
However at this level the
RRC Connection Setup is
probably not heard by the
UE any more or the BTS
does not hear the RRC
Connection Request
CPICH Ec/No
CPICH RSCP
Cell Reselection
Qhyst2= -16dB + 4dB =

-12dB
QqualMin+Sintrasearch
=-20dB + 4dB = -16dB
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
5
NOKIA

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
Calls setups difficult
Calls setups failures
QqualMin = -20dB
+
Qhyst2= -16dB + 4dB
=
-12dB
=-20dB + 4dB = -16dB
Time
6
NOKIA

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
NOKIA
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
CPICH Ec/No
CPICH RSCP
More time to select

and monitor a better
cell
Cell reselection
happens here where
cell B is about 8 dB
and Cell A is about 12
dB
CPICH Ec/No
CPICH RSCP
Qhyst2 = -8dB + 4dB

-4dB
UE starts the
neighboring cell
measurements near
earlier than at cell
edge
Worst case scenario
=-20dB + 12dB = -8dB
QqualMin = -20dB
Cell A
Time
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
8
Qqualmin shall not be changed as it will greatly affect cell coverage especailly
NOKIA
Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential
when Call
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

Calls setups ok
Qhyst2 =
4dB
=-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
9
NOKIA
BLER, Call drop rate, MOC CSSR, MTC CSSR
-Idle Mode Cell Reselection : Effect-
10
Idle mode
param. set as
defaults
Sintrasearch = 10dB
Treselection = 0s
AMR performance
New CD
Time in Days
NOKIA
BLER rate
Call drop rate
MOC setup failure rate
MTC setup failure rate
There is significant
improvement in performance
after due to changing of the
idle mode cell reselection
parameters
Call Setup Success rate
(MTC and MOC especially
MTC)
MTC improvement is due
to the fact that in case
there are problems in RRC
Connection Setup the
paging timer in MSC could
be expired and therefore
causing failed call
attempts

-2
All Call Attempts Test 1
CPICH Ec/No [dB]
-4
-6
-8
-10
From the charts on the left it can be seen

that from all the RRC Connection Request
messages only a few are done in the worse
than CPICH Ec/No = -15dB situation
CPICH Ec/No = -15dB can be
considered as some sort of UE
performance limit
-12
-14
In this case the Sintraseacrh setting seems

to be ok (10dB)
-16
-18
11
All Call Attempts Test 2
-6
-8
-10
-12
-14
-16
-18
-20
-22
-24
NOKIA
-2
-4
CPICH Ec/No [dB]
CPICH Ec/No [dB]
-2
-4
-6
-8
-10
-12
-14
-16
-18
-20
-22
-24
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
Sintrasearch
Qhyst2
Treselect
Default
12dB
4dB
0sec
Case4
12dB
4dB
2sec
Case5
12dB
0dB
0sec
Tests were done with Sanyo UE (3.23)
12
NOKIA

Idle mode (Stationary test)

Parameter set
Default
Case4
Case5
Idle mode (Drive test)
Parameter set
Default
Case4
Case5
Low Coverage
CPICH RSCP
-81.2
-78.83
-77.47
CPICH Ec/No
-9.04
-7.51
-7.39
CPICH RSCP
-75.41
-76.11
-75.98
Med. Coverage
CPICH RSCP
-75.06
-76.42
-74.21
CPICH Ec/No
-5.16
-6.5
-4.03
CPICH Ec/No
-5.45
-5.89
-6.03
AMR MOC (Stationary test)

Parameter set
Default
Case4
Case5
AMR MOC (Drive
rivetest)
Parameter set
Default
Case4
Case5
13
NOKIA
Low Coverage
#of call attempts
100
100
100
Setup success
82
83
92
#of call attempts

78
100
100
Setup success
76 (97%)
92%
94%
CPICH RSCP
-91.63
-92.18
-91.45
CPICH Ec/No
-6.74
-6.18
-6.16
Med. Coverage
#of call attempts Setup success
100
93
100
97
100
89

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 MTC
Parameter set # of call attempts Setup success Setup success rate
Default
484
412
85.1%
CR Case5
333
286
85.9%
UDI MOC
Default
320
262
81.9%
CR Case5
647
557
86.1%
Success rate
AMR MOC
Default
572
473
82.7%
CR Case5
854
765
89.6%
100.0%
95.0%
90.0%
85.0%
80.0%
75.0%
70.0%
65.0%
60.0%
55.0%
50.0%
45.0%
40.0%
35.0%
30.0%
25.0%
20.0%
15.0%
10.0%
5.0%
0.0%
Default
Case5
Services
14
NOKIA
-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?
15
NOKIA
Contents
Paging
UL Interference
PS Call Performance
16
NOKIA

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

-Paging : PIs-
Paging for UEs in IDLE state

UE
BS
RNC
UE has no RRC connection
CN
RANAP: PAGING
PICH
(FP/AAL2/PCCH/PCH/S-CCPCH) : PAGING TYPE 1
RRC connection establishment
Paging response
CN (RANAP: PAGING Message received

from CN = UE in idle mode) originated
paging amount: When RNC sends
Paging Type 1
M1006C25 PAGING TYPE 1 ATT CN
ORIG
A number of RNC originated paging
type 1 attempts (UE in PCH/URA
substate): When RNC sends Paging
Type 1
M1006C26 PAGING TYPE 1 ATT RNC
ORIG
Paging for UEs in CELL_PCH or URA_PCH

states
MM
2
MM Idle
UE
BS
RNC
Connected
CN 1
CN 2
UE has signalling connection to CN1

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

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

MM Connected
MM Idle
states
UE
BS
RNC
CN 1
CN 2
A number of paging messages

received from the CN
M1003C36 REC PAG MSG
UE has signalling connection to CN1

UE is in CELL_FACH or CELL_DCH state
RANAP:PAGING
RRC:PAGING TYPE 2
Paging response to CN 2
19
NOKIA
CN (RANAP: PAGING Message received

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

-Paging : PIs-
Paging Success Rate
1001C32 MTC Conv Att 1001C34 MTC Stream Att 1001C36 MTC Inter Att 1001C38 MTC Backg Att 1006C37 Cell Update Att Due to Paing Resp
1003C36 Received Paging 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 formulas 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
22
NOKIA

-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?
23
NOKIA
Contents
Paging
UL Interference
PS Call Performance
24
NOKIA

-RRC Connection Establishment-
UE
RNC
Node B
[RACH] RRC:RRC Connection Request
NBAP: RL Setup Request
NBAP: RL Setup Response
ALCAP:ERQ
ALCAP:ECF
[FACH] RRC: RRC Connection Setup
L1 Synchronisation
NBAP: Synchronisation Indication

[DCH] RRC: RRC Connection Setup Complete
The power level for sending of the RRC Connection

Request message is set/calculated by the UE
Uplink open loop PC take place at the random
access procedure:
UE measures the received power of the CPICH
which reported back in "measured results on
RACH" IE in: initial direct transfer (UTRAN must
extract this IE from the NAS message), cell
update / ura update, measurement report (UL
traffic volume measurement report), RRC
connection request, uplink direct transfer
(UTRAN must extract this IE from the NAS
message)
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
25
NOKIA
Call Performance.PPT
/ 16-09-2003 value"
/Reunanen Jussi
Company
where
the "constant
is the
valueConfidential
of the RNC parameter PRACHRequiredReceivedCI

UE
RNC
Node B
ALCAP:ERQ
ALCAP:ECF
If no acquisition indicator is received UE

raises the transmission power by
PowerRampStepPRACHpreamble which is a
broadcast parameter
This procedure is repeated until
acquisition indicator is received, after
which UE sends the RACH message at
power which offset by
PowerOffsetLastPreamblePRACHmessage
from the last preamble
L1 ACK / AICH
PRACH_preamble_retrans parameter
determines how many times PRACH
preamble can be sent (without AICH
response) within one preamble
ramping cycle (SIB5&6)
Not detected
Downlink
BS
RACH_tx_Max defines how many

P2
P1
Uplink
times the PRACH pre-amble ramping
MS PreamblePreamble
cycle procedure can be repeated
1
2
before UE MAC reports a failure on
RACH transmission to higher layers
26
NOKIA
Call Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential
(SIB
5&6)
Message part

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
27
NOKIA
-RRC Connection Establishment Logging CPICH Ec/NoCPICH Ec/No as in RRC Connection Setup Request
-20 -18 -16 -14 -12 -10
-8
-6
-4
-2
Results missing
-2
-4
-6
-8
-10
-12
-14
-16
-18
CPICH Ec/No as reported by fingers
For Filtering purposes it is

good to have Ec/No
recorded when the RRC
Connection Setup is sent
Whether the reading is
done from the Finger data
or from the RRC
Connection Setup
message needs to
decided
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)
28
NOKIA
-RRC Connection Establishment CPICH Ec/No / RSCP vs. UE Tx

PowerUE Tx Power [dBm]
-40 -35 -30 -25 -20 -15 -10 -5
10 15 20 25
-40
-60
-70
-80
-90
RSCP [dBm]
-50
-100
-110
-120
30
10
0
-30
-25
-20
-15
-10
-5
-10
-20
-30
UE Tx Power [dBm]
20
For failed calls the UE Tx vs. CPICH

Ec/No and CPICH RSCP should be
investigated in order to see possible
DL coverage or open loop PC problems
In case CPICH RSCP is low but UE Tx
Power is low
There is possibility that UE open
loop PC is not working correctly
Or the CPICH Tx power is pretty
low and there is DL coverage
problem
Or the SCCPCH power offset to
CPICH power is set wrongly too
big offset
In case CPICH Ec/No is low but the
UE Tx power is low then there could
be some problem in DL quality provided that the CPICH RSCP is ok
Some high DL loading in the
cell
Pilot pollution on that area
-40
29
NOKIA
CPICH Ec/No [dBm]

[dB]

Power-30
CPICH Ec/No [dB]

-20
-15
-10
-25
-5
From CPICH Ec/No vs. CPICH RSCP it

can be seen that only a few call failures
are having relatively good CPICH RSCP
but still pretty poor CPICH Ec/No:
indicating possibility of Pilot Pollution
Indicating possibility of relatively
high DL load
Those cells in case they constantly do
have this kind of phenomena should be
investigated more
0
-50
-60
-70
-80
-90
-100
CPICH RSCP [dBm]
-40
-110
-120
Plot of RSCP and Ec/No vs Data No. in problem Area
Pilot pollution area/poor
dominance area
-20
For possible pilot pollution investigation the

amount of SCs and their strength can be
-5
plotted from the drive test data and possible
-10
the cells causing the pilot pollution can be
-15
identified and dominance optimisation can be
-20
-25
done
0
Ec/No (dB)
RSCP and RSSI (dBm)
-40
-60
-80
-30
-35
-100
-40
-120
-45
-140
ANT1_RSSI
SC174 RSCP
SC69 Ec/No
30
-50
Data No.
NOKIA
SC97 RSCP
SC180 RSCP
SC174 Ec/No
SC106 RSCP
SC97 Ec/No
SC180 Ec/No
SC103 RSCP
SC106 Ec/No
SC69 RSCP
SC103 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
31
NOKIA
Before 1.5.2 CD15
UE
RNC
Node B

ALCAP:ERQ
ALCAP:ECF
UE
RNC
Node B
There is no
retransmission of RRC
Connection Setup
-message.
This is why the UE just
sends another RRC
Connection Request
message.
UE
UE does
does not
not hear RRC Connection Setup from RNC

ALCAP:ERQ
ALCAP:ECF
UE
UE does
does not
not hear
hear RRC
RRC Connection
Connection Setup
Setup from
from RNC
RNC
32
NOKIA
The more RRC

Connection Request
retransmission the
more (in case RNC
hears the message) RLs
are setup and more Iub
Capacity used.
The RNC internal timer
(T_RRC_Resp_CCH) will
release the unused RLs
on Iub after 6seconds
(from
the Confidential
Call Performance.PPT / 16-09-2003 /Reunanen
Jussi Company

ALCAP:ERQ
ALCAP:ECF
Before 1.5.2 CD15

UE
RNC
Node B

ALCAP:ERQ
T300
ALCAP:ECF
RRC
RRC Connection
Connection Setup
Setup message
message
is
is transmitted
transmitted in
in several
several
successive
successive transport
transport blocks
Current default values of the parameters are:

T300=3000ms and N300=3
UE will send the RRC Connection Request
message four times in the interval of three
seconds if there is no RRC Connection
Setup message received from the RNC
The RRC Connection Setup message is sent
only once (UM RLC SAP is used for this RRC
procedure)
RRC Connection Setup is quite a long
message that must be sent in several
successive transmission blocks (TB) via
the FACH transport channel
Only one erroneous TB is sufficient to
cause the MS to reject the whole
Setup message
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
33
NOKIA
Before 1.5.2 CD15

Repetition procedures defined in RAN1.5 for RRC messages using the UM-RLC SAP
Repetition counters presented in the following table are defined for unacknowledged
mode RRC messages in RAN1.5.
34
NOKIA
Repetition Counter
Default
Usage
L3Rep_UnAckRLC
2 times
Repeat counter for RRC messages when using UM RLC. Used

for the following DL RRC messages:
1. DCH to FACH state transition command (interval 400ms)
2. Cell Update Confirm (interval 300ms)
3. URA Update Confirm (interval 300ms)
L3Rep_RRC_Conn_Rel
2 times
(interval
300ms)
Repeat counter for RRC Connection Release message sent on:

DCCH mapped to DCH and DCCH/CCCH mapped to FACH.
Note. Repetitions shall not be used when the message is sent

over Iur (possible repetitions must be executed by the DRNC).
Before 1.5.2 CD15

UE
RNC
Node B

Based on the experiments made in the

network with a sufficiently low load one
can get improvement in call setup delay
when reducing the value of T300
ALCAP:ERQ
By reducing the value of T300

the UE will repeat the request sooner
and the delay in RRC connection
RRC
RRC Connection
Connection Setup message
establishment
caused
by
lost
is
is transmitted
transmitted in
in several
several
successive
successive transport
transport blocks
blocks
Request/Setup messages can be
minimized
UE
UE does
does not
not hear RRC Connection Setup from RNC
However This is wrong way to
correct
the "problem
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
ALCAP:ECF
35
NOKIA
Before 1.5.2 CD15
UE
RNC
Node B
ALCAP:ERQ
ALCAP:ECF
UE
UE does
does not
not hear
hear RRC
RRC Connection
Connection Setup
Setup from
from RNC
RNC
ALCAP:ERQ
ALCAP:ECF
If the repeated RRC Connection Request

messages are received before the RNC
has been able to complete the ongoing
RRC Connection Setup procedures (i.e.
release the established RLs for the
unsuccessful RRC Connection Setup
attempts) this will cause new RRC
connection establishment procedures to
be triggered (requiring maybe more calls
to be pre-empted in vain)
Initiation of the pre-emption procedure
may need Radio Link Setup Request to
be rejected by the BTS or AAL2-setup
failure to happen
Then the DCH-allocation of packet data
call (to be pre-empted) must be released
(state transition CELL_DCH -> CELL FACH
is triggered)
36
NOKIA
Before 1.5.2 CD15
UE
RNC
Node B
State transition from Cell_DCH to Cell_FACH

is in the optimum case fast

ALCAP:ERQ
ALCAP:ECF
UE
UE does
does not
not hear
hear RRC
RRC Connection
Connection Setup
Setup from
from RNC
RNC
In case there is a cell reselection procedure

executed before the MS acknowledges the
state transition command, then the RL(s)
cannot be released until the Cell Update is
received via the RACH transport channel or
Radio Link Failure indication(s) is/are received
from the BTS(s)
There may also be radio link(s) over Iur due to
inter-RNC SHO

ALCAP:ERQ
ALCAP:ECF
Additional RRC Connection Requests will cause

additional resource reservations and due to
that
might
cause
some
pre-emption
procedures to be triggered
More complex situation is more time pre-emption procedure takes -> more
new RRC Connection Requests are sent by the UE -> more pre-emption
37
NOKIA
Before 1.5.2 CD15
UE
RNC
Node B
ALCAP:ERQ
ALCAP:ECF
UE
UE does
does not
not hear
hear RRC
RRC Connection
Connection Setup
Setup from
from RNC
RNC
ALCAP:ERQ
ALCAP:ECF
Resources reserved for these unnecessary

"double reservation" cannot be released
immediately; radio links must be kept
allocated for a certain time
If there is no RRC Connection Setup
Complete message received from the UE,
the RL is released after Layer3 time
supervision for the MS acknowledge has
expired
38
NOKIA
Before 1.5.2 CD15
CPICH Ec/No
CPICH RSCP
-100dB
First RRC
Connection
Request sent
by the UE
RNC Answers
with RRC
Connection
Setup UE
does not hear
it
Cell A
UE sends new RRC

Connection Request to Cell B
which is successful and call is
setup successfully
CPICH Ec/No
CPICH RSCP
-10dB
-15dB
UE waits T300 seconds until it sends next RRC

Connection Request. During the T300 time the UE
makes cell reselection to Cell B
Time
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
39
NOKIA
Before 1.5.2 CD15

Resource allocations (time between RRC Connection Request

and RRC Connection Setup) within "fragment of a second" can
be assumed only for networks operating in low load and in
good radio conditions (no RRC messages lost on RACH/FACH)
RRC connection establishment procedure requiring a preemption 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)
40
NOKIA
Before 1.5.2 CD15

There is possibility for collecting "success-rate" statistics only

RRC Connection Setup/Complete phase, so there is no "RNC
level" statistical distribution available for actual cause for RRC
connection establishment delay (amount of lost RRC
Connection Requests is not known)
Values less than 3000ms cannot be recommended for T300,
and thus there is no possibility to speed up the RRC
connection establishment in the cases where the RRC
Connection Request message is lost
Cell reselections during the RRC connection setup phase will
cause "double resource reservations where a new RRC
connection establishment is started in the new cell. Ongoing
RRC connection establishment in the old cell cannot be
interrupted and the reserved resources cannot be released
until the Layer3 time supervision (default=6 seconds) expires
41
NOKIA
Before 1.5.2 CD15

UE
Node B
RNC

Start
Start
TX/RX
TX/RX
ALCAP:ERQ
ALCAP:ECF
Start
Start
TX/RX
L1 Synchronisation
Timer
T300
is
starte
d
UE sends
RRC
Connectio
n Request
-message
NBAP:R
L Setup
Reques
t
RNC starts
timer
T_RRC_Resp_C
CH
RNC sends RRC
Connection Setup
-message
BTS Starts
sending DPCCH:
Pilot and TPC &
Starts UL
synchronization
procedure
BTS sends: NBAP

RADIO LINK
SETUP RESPONSE
-message
2
UE start
sending
DPCCH for
UL sync
purposes
(pilot) after
DL frame
sync is
established
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
42
NOKIA

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
43
NOKIA

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.
Reported valueof the Q_IN
Measured
quantityto
valuethe actual physical
The mapping
values
PhCh_ BER_LOG_ 000
Physical channel BER = 0
- < Log10(Physical
channel
BER)25.133
< -2.06375
PhCh_ BER_LOG_
001 given
channel
BER
is
in
3GPP
TS
-2.06375 Log10(Physical channel BER) < -2.055625

PhCh_ BER_LOG_ 002
44
NOKIA
PhCh_ BER_LOG_ 003
PhCh_ BER_LOG_ 253

PhCh_ BER_LOG_ 254
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 Q out (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 Q in
NOTE: It is possible that a radio frame has neither In-sync status nor Out-ofsync status
These frames are ignored in determining the sync state of a radio link
45
NOKIA

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
46
NOKIA
Before 1.5.2 CD15

UE
Node B
RNC When a physical dedicated channel establishment is initiated by

Start
Start
TX/RX
TX/RX
ALCAP:ERQ
ALCAP:ECF
the UE, the UE starts a timer T312 and wait for layer 1 to
indicate N312 "in sync" indications
On receiving N312 "in sync" indications, the physical channel is
considered established and the timer T312 is stopped and reset
On the BTS side after receiving N_INSYNC_IND synchronisation
indicators the BTS sends NBAP: SYNCHRONIZATION INDICATION
message to RNC after which the closed loop and outer loop PC
start to control the powers
Start
Start
TX/RX
L1 Synchronisation
Timer T312
started
UE initiates physical
dedicated channel
establishment before
sending e.g. RRC
Connection Setup Complete
message on DPDCH
47
NOKIA
N_INSYNC_IND
indicators on
L1
in sync
indicators on
L1
N312 L1 in
sync
indicators
L1 Synchronization
established
BTS sends NBAP:
SYNCHRONIZATION
IDICATION
-message
Timer
T312
stopped
L1
Synchronizati
on
established
Other cases HHO,

FACH=>DCH-state
Call
RNC receives RRC

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

Complete message
SENT
UE
Node B
Before 1.5.2 CD15
RNC

Start
Start
TX/RX
TX/RX
ALCAP:ERQ
ALCAP:ECF
Start
Start
TX/RX
L1 Synchronisation
Timer
T312
starte
d
In case UE is not able to establish synchronization

within timer T312 it stops TX on the DCH
In case BTS is not able to establish synchronization
it does not send NBAP:Synchronization Indication
message to RNC
The BTS tries to establish synchronization until
T_RRC_Resp_CCH timer in RNC expires and RNC
sends NBAP:Radio Link Deletion -message
Less than
N_INSYNC_IND
indicators on
L1
2
dedicated channel
sending e.g. RRC
message on DPDCH
in sync
indicators on
L1
Less
thanN312 L1
in sync
indicators
RNC does not

receive RRC
Connection Setup
Complete message
within
T_RRC_Resp_CCH
timer
Counter
1001C9 is
RNC sends
incremented
NBAP:RADIO LINK
DELETION
message
RRC Connection
establishment
procedure failed -> wait
until T300 expires and if
number of sent RRC
Connection Requests <
N300
L1 Synchronization not
established BTS does NOT
send NBAP:
SYNCHRONIZATION
IDICATION -message
Timer T312
expired => L1
Synchronization
not established
Physical channel
Other cases HHO,
establishment
FACH=>DCH-state
failed => UE stops
48
NOKIA
transitions
TX/RX
UE
Node B
Before[RACH]
1.5.2
CD15
RRC:RRC
Connection Request
RNC
Start
Start TX/RX
TX/RX
ALCAP:ERQ
ALCAP:ECF
In case BTS is able to establish synchronization it sends

NBAP:Synchronization Indication message to RNC
In case UE is not able to establish synchronization within timer

T312 it stops TX on the DCH
As the UE TX is off the BTS looses the L1 synchronization and
sends NPAB: Radio Link Failure message to RNC (and
continues to send the message in 5 sec. intervals until RNC
sends NBAP: Radio Link Deletion message back)
Start
Start TX/RX
TX/RX
L1 Synchronisation
NBAP: Radio Link Failure
After T_RRC_Resp_CCH expires in RNC the RNC sends NPAB:

Radio Link Deletion to BTS which then stops searching for the
synchronization
Counter
1001C10 is
incremented
L1 Synchronization established
BTS sends NBAP: SYNCHRONIZATION
IDICATION -message
Timer T312
started
N_INSYNC_IND
indicators on
L1
3
dedicated channel
sending e.g. RRC
Connection Setup
Complete message
on DPDCH
49
NOKIA
in sync
indicators on
L1
Less than N312 L1
in sync indicators
Timer
T312
expired
Timer
T_RLFAILURE
expires
N_OUTSYNC_IN
timer
D indicators on
T_RRC_Resp_
L1
CCH expired
Physical channel
establishment
failed => UE stops
TX/RX
Timer
T_RLFAILU
RE started
RRC Connection establishment procedure

failed -> wait until T300 expires and if
/ 16-09-2003
/Reunanen
Jussi Company
Confidential
number
of sent
RRC Connection
Requests
RNC receives
NBAP:RADIO LINK
FAILURE message form
BTS with a cause value
"Synchronization
Failure"
RNC sends
NBAP:RADIO
LINK
DELETION
message
UE
Node B
Before[RACH]
1.5.2
CD15
RRC:RRC
Connection Request
RNC
Start
Start TX/RX
TX/RX
ALCAP:ERQ
ALCAP:ECF
Start
Start TX/RX
TX/RX
L1 Synchronisation
In case the BTS does not send NBAP: RL Failure

message to RNC but the RNC does not
receive RRC Connection Setup Complete
message from UE within timer
T_RRC_Resp_CCH, the RNC initiates RRC
Connection Release procedure
Counter
1001C10 is
incremented
L1 Synchronization established
BTS sends NBAP: SYNCHRONIZATION
IDICATION -message
Timer T312
started
N_INSYNC_IND
indicators on
L1
3
dedicated channel
sending e.g. RRC
Connection Setup
Complete message
on DPDCH
50
NOKIA
in sync
indicators on
L1
Timer
T312
expired
timer
T_RRC_Resp_
CCH expired
Physical channel
establishment
failed => UE stops
TX/RX
Less than N312 L1

in sync indicators
RRC Connection establishment procedure

failed -> wait until T300 expires and if
/ 16-09-2003
/Reunanen
number
of sent
RRC Jussi
Connection
CompanyRequests
Confidential
RNC sends
RRC:RRC
CONNECTI
ON
RELEASE
message
on DCH to
UE
RNC sends
NBAP:RADIO LINK
DELETION
message
No RRC: RRC CONNECTION
RELEASE COMPLETE message
is not received => RRC entity
of the UE is deleted at the
same time with the radio link
deletion procedure
No RRC: RRC CONNECTION
RELEASE COMPLETE message
from UE within within the
message repetition timer
(100ms)
the RNC retransmits the
message
L3Rep_RRC_Conn_Rel times
with interval of 100 ms
After 1.5.2 CD15

UE
RNC starts timers

-RRC Connection EstablishmentT_RRC_Resp_CCH,
Node B
RNC

Start
Start
TX/RX
TX/RX
ALCAP:ERQ
ALCAP:ECF
Start
Start
TX/RX
L1 Synchronisation
RNC receives RRC

RRCconnRepTimer1
Connection Request and
and
starts buffering timer
RRCconnRepTimer2
N300*T300
Timer
NBAP:R
T300
L Setup
RNC sends RRC
is
Reques
Connection Setup
starte
t
-message
d
UE sends
RRC
Connectio
n Request
-message
BTS Starts
sending DPCCH:
Pilot and TPC &
Starts UL
synchronization
procedure
BTS sends: NBAP

RADIO LINK
SETUP RESPONSE
-message
UE start
sending
DPCCH for
UL sync
purposes
(pilot) after
DL frame
sync is
established
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
51
NOKIA
After 1.5.2 CD15
UE
Node B
RNC When a physical dedicated channel establishment is initiated by

Start
Start
TX/RX
TX/RX
ALCAP:ERQ
ALCAP:ECF
the UE, the UE starts a timer T312 and wait for layer 1 to
indicate N312 "in sync" indications
On receiving N312 "in sync" indications, the physical channel is
considered established and the timer T312 is stopped and reset
On the BTS side after receiving N_INSYNC_IND synchronisation
indicators the BTS sends NBAP: SYNCHRONIZATION INDICATION
message to RNC after which the closed loop and outer loop PC
start to control the powers
Start
Start
TX/RX
L1 Synchronisation
Timer T312
started
dedicated channel
sending e.g. RRC
message on DPDCH
52
NOKIA
N_INSYNC_IND
indicators on
L1
in sync
indicators on
L1
N312 L1 in
sync
indicators
L1 Synchronization
established
BTS sends NBAP:
SYNCHRONIZATION
IDICATION
-message
RNC receives RRC

Connection Setup
Complete message ->
RNC stops timers
T_RRC_Resp_CCH,
RRCconnRepTimer1
and
RRCconnRepTimer2
Timer
T312
stopped
L1
Synchronizati
on
established

Complete message
SENT
Other cases HHO,

FACH=>DCH-state
Call
UE
Node B
RNC

Start
Start
TX/RX
TX/RX
ALCAP:ERQ
ALCAP:ECF
Start
Start
TX/RX
L1 Synchronisation
Timer
T312
starte
d

After 1.5.2 CD17
In case UE is not able to establish synchronization

within timer T312 it stops TX on the DCH
In case BTS is not able to establish synchronization
it does not send NBAP:Synchronization Indication
message to RNC
The BTS tries to establish synchronization until
T_RRC_Resp_CCH timer in RNC expires and RNC
sends NBAP:Radio Link Deletion -message
Less than N_INSYNC_IND indicators

on L1
Complete not received
send NBAP:
RRCconnRepTimer1 expires
SYNCHRONIZATION
-> RRC Connection Setup is
IDICATION
-message
resent to the UE
resent to the UE and
RRCconnRepTimer2 reset
RRCconnRepTimer1 stopped
Timer T312
expired => L1
Synchronization
not established
dedicated channel
sending e.g. RRC
message on DPDCH
Physical channel
establishment
Less
thanN312
L1
in
sync
Other cases HHO,
failed => UE stops
indicators
FACH=>DCH-state
53
NOKIA
Call Performance.PPT / 16-09-2003 /Reunanen Jussi Company Confidential TX/RX
transitions
RNC does not

receive RRC
Connection Setup
Complete message
within
T_RRC_Resp_CCH
timer
RNC sends
NBAP:RADIO LINK
DELETION
message
Counter 1001C9 is
incremented
-no Synchronisation
indication received
within supervision time
-no rrc connection
setup complete reeived
within supervision time
UE
Node B
RNC

Start
Start TX/RX
TX/RX
ALCAP:ERQ
ALCAP:ECF

After 1.5.2 CD17
In case BTS is able to establish synchronization it sends NBAP:Synchronization Indication

message to RNC
In case UE is not able to establish synchronization within timer T312 it stops TX on the DCH
As the UE TX is off the BTS looses the L1 synchronization and sends NPAB: Radio Link
Failure message to RNC
After T_RRC_Resp_CCH expires in RNC the RNC sends NPAB: Radio Link Deletion to BTS
which then stops searching for the synchronization
Start
Start TX/RX
TX/RX
L1 Synchronisation
NBAP: Radio Link Failure
Timer
T312
starte
d
Counter 1001C10 is
L1 Synchronization established BTS
incremented
sends NBAP: SYNCHRONIZATION
-Synchronisation indication
IDICATION -message
N_INSYNC_IND indicators on L1
Timer
received within supervision
T_RLFAILU
time
RE
started
-no rrc connection setup
complete reeived within
Timer
N_OUTSYNC_IN
supervisiontimer
time
T_RLFAILU
D indicators on
T_RRC_Resp_
RE expires
L1
CCH expired
resent to the UE
Timer T312
expired => L1
Synchronization
not established
dedicated channel
sending e.g. RRC
message on DPDCH
Physical channel
establishment
Less thanN312 L1 in sync
Other cases HHO,
54
NOKIA
Call Performance.PPT / indicators
16-09-2003 /Reunanen Jussi Company Confidential failed => UE stops
FACH=>DCH-state
RNC sends
NBAP:RADIO
LINK
DELETION
message
RNC receives
NBAP:RADIO LINK
FAILURE message form
BTS with a cause value
UE
Node B
RNC

Start
Start TX/RX
TX/RX
ALCAP:ERQ
ALCAP:ECF
Start
Start TX/RX
TX/RX
L1 Synchronisation

After 1.5.2 CD17
In case the BTS does not send NBAP: RL Failure

message to RNC but the RNC does not
receive RRC Connection Setup Complete
message from UE within timer
T_RRC_Resp_CCH, the RNC initiates RRC
Connection
Release
procedure
Counter
1001C10 is
L1 Synchronization
incremented
-Synchronisation
indication received
within supervision
time
RNC sends
-no rrc connection
NBAP:RADIO
setup complete
LINK DELETION
reeived within
message
supervision time
RRC entity of the UE is
timer
deleted at the same time
T_RRC_Resp_CCH
with the radio link deletion
expired
procedure
established BTS sends

NBAP:
SYNCHRONIZATION
IDICATION -message
N_INSYNC_IND indicators on L1
Timer
T312
starte
d

resent to the UE
dedicated channel
sending e.g. RRC
message on DPDCH
Less thanN312 L1 in sync
Other cases HHO,
FACH=>DCH-state
55
NOKIA
Call Performance.PPT / indicators
16-09-2003 /Reunanen Jussi Company Confidential
RNC sends RRC:RRC CONNECTION RELEASE

message on DCH to UE, timer
T_RRC_Resp_CCH restarted
No RRC CONNECTION
RELEASE COMPLETE
message from UE within
within the message
repetition timer (100ms)
the RNC retransmits the
message
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
AMR performance
noted that setting N312 to
2 or 4 (between 1 and 2
there is notable difference)
does not have any
significant effect on the call
set up success rate
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
Percentile MOC call setup delay @5 sec

Percentile MTC call setup delay @5 sec
N31
2=1
56
NOKIA
N31
2=4
17/03/03
07/03/03
06/03/03
01/03/03
15/02/03
12/02/03
10/02/03
05/02/03
01/02/03
28/01/03
25/01/03
24/01/03
22/01/03
20/01/03
18/01/03
16/01/03
0%
14/01/03
MOC / MTC call setup delay 5 sec Percentile
But the effect on the call

set up time is significant
and therefore N312 value
of 2 was selected to be
used
N31
2=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
NTFCI bits
Data
Ndata1 bits
Pilot
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
57
NOKIA
-RRC Connection Establishment: Power Offset for SCCPCH Pilot &

TFCI bits -
power offset TFCI

= 0 dB for 60
ksps SCCPCH
power
offset TFCI
= 4 dB for
60 ksps
SCCPCH
58
NOKIA
Failure due to
FACH/RACH is lower from
xxx test in Apr

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 intrafrequency 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:
59
NOKIA
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
60
NOKIA

-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
PCCPCH Ptx
PSCH
SSCH
PICH
SCCPCH
AICH
27
24
25
25
20
29
21
27
25
27
27
24
27
27
Call Setup Success Rate
AMR MTC
Default
484
412
85.1%
Case4
625
556
89.0%
UDI MOC
Default
320
262
81.9%
Case4
527
451
85.6%
61
NOKIA
100.0%
95.0%
90.0%
85.0%
80.0%
75.0%
70.0%
65.0%
60.0%
55.0%
50.0%
45.0%
40.0%
35.0%
30.0%
25.0%
20.0%
15.0%
10.0%
5.0%
0.0%
Success rate
AMR MOC
Default
572
473
82.7%
Case4
771
678
87.9%
Default
Case4
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
J
Call Setup Failure due to Registration (2.4)
In Step A & B, the performance after parameter change has

AMR MOC
AMR MTC
UDI MOC
improved
Category Default Case4
Default (%) Case4 (%) Category Default Case4
Default (%) Case4 (%)
A
8
0
1.40%
0.00% A
3
0
0.62%
0.00%
B
19
26
3.32%
3.37% B
5
15
1.03%
2.40%
C
0
0
0.00%
0.00% C
0
1
0.00%
0.16%
D
36
32
6.29%
4.15% D
21
20
4.34%
3.20%
E
7
4
1.22%
0.52% E
2
7
0.41%
1.12%
F
11
4
1.92%
0.52% F
28
10
5.79%
1.60%
G
5
8
0.87%
1.04% G
6
4
1.24%
0.64%
H
13
17
2.27%
2.20% H
7
12
1.45%
1.92%
I
473
678
82.69%
87.94% I
412
556
85.12%
88.96%
J
0
2
0.00%
0.26%
J
0
0
0.00%
0.00%
62
NOKIA
Category Default Case4

Default (%) Case4 (%)
A
0
0
0.00%
0.00%
B
18
26
5.63%
4.93%
C
0
0
0.00%
0.00%
D
18
25
5.63%
4.74%
E
7
3
2.19%
0.57%
F
6
5
1.88%
0.95%
G
3
6
0.94%
1.14%
H
6
11
1.88%
2.09%
I
262
451
81.88%
85.58%
J
0
0
0.00%
0.00%
-RRC Connection Establishment: CountersUE
RNC
BTS
Failure Case:
RRC Connection Setup fa
Due to
Triggers:
1001C2 Handover control
1001C3 Admission control
1001C4 BTS
1001C5 Transmission netwo
1001C6 RNC internal reason
1001C7 Frozen BTS
CN
RRC: Connection Request

Correctly Received message
RRC Connection Setup Starts
Triggers:
1001C0 RRC Connection Attempt
RRC Connection Setup phase
Resource Reservation in RNC, BTS, Transmission

RRC: RRC Connection Request Setup
RRC Connection setup completed
Triggers:
1001C1 RRC Con Setup Compl
RRC Connection Access phase

RNC waits reply from UE
RRC: RRC Connection Completed
Failure Case:
RRC Connection Access fails
Due to
Triggers:
1001C9
L1 synchronization
1001C10 UU interface
Failure Case:
RRC Connection Active f
Due to
Triggers:
1001C15 Iu interface
1001C16 Radio interface
RANAP: Initial UE Message 1001C17 BTS
1001C18 Iur interface
1001C19 Ciphering failur
1001C20 Integrity check
1001C21 RNC internal re
RRC Connection Access completed

Triggers:
1001C8 RRC Con Acc Comp
RRC: Initial Direct Transfer
RRC Connection Active phase

UE-CN Signaling
RANAP: Iu Release Command

RRC Connection Active completed
Triggers:
1001C12 RRC Con Active Comp
63
NOKIA
Special Reason:
RRC Connection Active
Release Due to
Triggers:
1001C13 SRNC Relocat
1001C14 Pre-emption
RRC Connection Setup due to

Cause
Triggers:
1001C22 MOC conv call att
1001C24 MOC stream call att
1001C26 MOC interac call att
1001C28 MOC backgr call att
1001C30 MOC subscribed call att
1001C32 MTC conv call att
CN 1001C34 MTC stream call att
RNC
UE
BTS
1001C36 MTC interac call att
1001C38 MTC backgr call att
1001C40 Emergency call att
1001C42 Inter RAT cell reselection
1001C44 Inter RAT cell chng ord
Triggers:
1001C46 Registration attempt
1001C0 RRC Connection Attempt
1001C48 Detach attempt
1001C50 MOC high prior signaling
1001C52 MTC high prior signaling
1001C54 MOC low prior signaling
1001C56 MTC high prior signaling
1001C58 Call re establishment att
Triggers:
1001C60 Terminating cause
unknown
Failures by RRC Connection
Setup Causes
Triggers:
1001C23 MOC conv call failure
1001C25 MOC stream call failure
1001C27 MOC interac call failure
Triggers:
1001C29 MOC backgr call failure
1001C31 MOC subscribed call fail
1001C33 MTC conv call failure
RANAP: Initial UE Message1001C35 MTC stream call failure
1001C37 MTC interac call failure
1001C39 MTC backgr call failure
1001C41 Emergency call failure
UE-CN Signaling
1001C43 Inter RAT cell reselec fail
1001C45 Inter RAT cell chng ord fail
RANAP: Iu Release Command1001C47 Registration attempt fai
1001C49 Detach attempt failure
1001C51 MOC high prior sig failure
1001C53 MTC high prior sig failure
Triggers:
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: Counters-
64
NOKIA
-RRC Connection Establishment: PIsUE
RNC
BTS
CN

RRC Connection Setup Starts
Triggers:
1001C0 RRC Connection AttemptRRC Setup Complete Ratio
100*[Sum(1001C1)/Sum(1001C0)]

Triggers:
RRC Setup and

Access Complete Ratio [%
100*[Sum(1001C8)/Sum(1001C0
Special Reason:
Release Due to
Triggers:
1001C13 SRNC Relocatio
1001C14 Pre-emption

Triggers:
RANAP: Initial UE Message
RRC Drop Ratio [%]
100-100*[Sum(1001C12+100
+1001C14)/Sum(1001C8)]
UE-CN Signaling
RANAP: Iu Release Command

Triggers:
65
NOKIA
-RRC Connection Establishment: PIs RRC Setup and Access Complete Ratio [%]
It should be noted that this PI is not call setup success rate (counted
from the user perspective) as:
the RAB setup and access phases not included
the users 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
66
NOKIA
-RRC Connection Establishment: PIs-
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)
67
NOKIA
-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?
83
NOKIA
Contents
Paging
UL Interference
PS Call Performance
84
NOKIA

-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
UE
RNC
RNC
Node
Node B
B
CN
CN
UE
UE
RNC
RNC
Node
Node B
B
RRC:Initial Direct Transfer(MM:CM Service Request)
CN
CN
RANAP:Direct Transfer(CC:Call Proceeding)
RANAP:Initial UE Message(MM:CM Service

Request)
SCCP:CC
RRC:DL Direct Transfer(CC:Call Proceeding)

RANAP:RAB Assignment Request
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
ALCAP:ECF
RRC:UL Direct Transfer(MM:Authentication

Response)
RANAP:Direct Transfer(MM:Authentication
Response)
RANAP:Common ID
RANAP:Security Mode Command
ALCAP:ERQ
ALCAP:ECF
NBAP:Radio Link Reconfiguration Commit
RRC:Radio Bearer Setup
RRC:Radio Bearer Setup Complete
RRC:Security Mode Command
RANAP:RAB Assignment Response
RRC:Security Mode Complete

RANAP:Security Mode Complete
RRC:DL Direct Transfer(CC:Alerting)
RRC:UL Direct Transfer(CC:Setup)

RANAP:Direct Transfer(CC:Setup)
RRC:DL Direct Transfer(CC:Connect)
RANAP:Direct
Transfer(CC:Alerting)
RANAP:Direct
Transfer(CC:Connect)
RRC:UL Direct Transfer(CC:Connect Acknowledge)

RANAP:Direct Transfer(CC:Connect Acknowledge)
85
NOKIA
-RAB Establishment Performance: Counters; RAB Setup &

AccessRAB Setup starts
BTS
UE

UE-CN Signaling
Depending on RAB Type

Triggers:
RNC
CN
1001C66 RAB setup att for CS Voice
1001C67 RAB setup att for CS Data conv
1001C68 RAB setup att for CS Data strea
phase
1001C69 RAB setup att for PS Data conv
1001C70 RAB setup att for PS Data strea
RANAP: RAB Assignment Request 1001C71 RAB setup att for PS Data intera
1001C72 RAB setup att for PS Data backg
RAB Setup phase

RRC: Radio Bearer Setup
RAB Connection Access phase

RRC: Radio Bearer Setup Completed

RANAP: RAB Assignment Response
RAB Active phase
User Plane Data Transfer
86
NOKIA
RAB Access Completed

Triggers:
1001C115 RAB setup acc comp
conv class
stream class
conv class
stream class
intera class
for CS Voice
for CS Data
for CS Data
for PS Data
for PS Data
for PS Data
Failure Case:
CS RAB Setup for Voice fails D
Triggers:
1001C81 BTS
1001C82 Transmission network
1001C84 Frozen BTS
Note: Each RAB type
has identical failure counters
RAB Setup Completed

Triggers:
1001C73 RAB setup comp for
CS Voice
CS Data conv
CS Data strea
PS Data conv
PS Data strea
PS Data inter
PS Data back
Failure Case:
CS RAB Access for Voice fails
Due to
Triggers:
1001C122 UE
1001C123 RNC internal
Note: Each RAB type
-RAB Establishment Performance: Counters RAB Active PhaseUE
RNC
BTS
CN
RAB Active phase
Special Reason:
RAB Active Release Due to
Triggers:
RANAP: RAB Assignment Request, with IE: RAB reconfiguration
1001C143 SRNC Relocation for CS Vo
1001C144 Pre-emption for CS Voice
For all types of RABs
User Plane Data Transfer
RAB Reconfiguration
Resource Reconfigured in RNC, BTS, Transmission

RRC: Radio Bearer Reconfiguration
RRC: Radio Bearer Reconfiguration Complete
RAB Reconfiguration Attemp

Triggers:
1001C197 RAB reconf Att
RAB Reconfiguration Failure

Triggers:
1001C198 RAB reconf Fail
RANAP: RAB Assignment Request, with IE: RAB Release
RRC: Radio Bearer Release
RAB Active Completed
RANAP: RAB Assignment Response Triggers:
1001C136 RAB Act Comp for
RAB Release
Resource Released in RNC, BTS, Transmission
87
NOKIA
CS Voice
CS Data conv
CS Data strea
PS Data conv
PS Data strea
PS Data inter
PS Data back
-RAB Establishment Performance: PIsBTS
UE
RNC
CN
RANAP: RAB Assignment Request
RAB Setup phase
RAB Setup Complete Ratio [%
100*[Sum(1001C7379)/Sum(1001C66
RRC: Radio Bearer Setup
RAB Setup and

Access Complete Ratio [%]
RAB Connection Access phase
100*[Sum(1001C115..121)/Sum(1001C66
RRC: Radio Bearer Setup Completed

RANAP: RAB Assignment Request, with IE: RAB Release

RRC: Radio Bearer Release
88
NOKIA
RAB Drop Ratio [%]
100-100*[Sum(1001C136142+1001
1001C144+1001C151154+1001C16
/Sum(1001C115121)]
-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)
89
NOKIA

UE
UE
RNC
RNC
Node B
CN
CN

ALCAP:ERQ
ALCAP:ECF
ALCAP:ERQ
ALCAP:ECF
RANAP:Direct
Transfer(CC:Alerting)
RANAP:Direct
Transfer(CC:Connect)

It should be noted that during

RAB Assignment procedure (i.e.
between RAB Assignment
Request and RAB Assignment
Response) the SHO activation is
not possible -> measurement
reports are rejected (e1a and
e1c) or buffered (e1b)
From UE logs point of view
between CALL PROCEEDING
and ALERTING
This phenomena (parallel
procedure not allowed) is not
taken into account by the
counters i.e. all the failure
counters for SHO are updated if
measurement reports are
received during this period

90
NOKIA

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
91
NOKIA
-RAB Establishment Performance : Questions What needs to be remembered concerning SHO during call setup?
What is RAB?
What is given in RAB attributes?
102
NOKIA
Call Performance.PPT / 16-09-2003 /Reunanen JussiCompany
Confidential
Contents
Paging
UL Interference
PS Call Performance
103
NOKIA
Confidential
Failure Case:
CS RAB Setup for Voice fails Due
to Triggers:
1001C81 BTS
1001C82 Transmission network
1001C84 Frozen BTS
Note: Each RAB type has identical
failure counters

-Failure due to AC-
Failure Case:
Due to
Triggers:
1001C122 UE
Note: Each RAB type
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
Cabling,
details
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
The reason can be identified in the traffic table

details
counters
Signalling link: DCH_REQ_LINK_REJ_UL_SRNC & DCH_REQ_LINK_REJ_DL_SRNC
Conversational: REQ_CS_CONV_REJ_UL_SRNC & REQ_CS_CONV_REJ_DL_SRNC
104
NOKIA
Confidential

-Investigating Call Setup FailureMT
C
MTC/MOC ?
Cause:
Trans, BTS
Investigate
paging : See
chapter Paging
Cause: AC
ServLev:
RRC Setup failures ?
Investigate
transmission
or BTS
Cause:
Trans, BTS
Failure Case:
Due to
Triggers:
1001C122 UE
Note: Each RAB type
105
NOKIA
ServLev:
RAB Setup failures ?
Cause: AC
ServLev:
RRC/RAB Access
failures ?
to MS
InvestigateDue
radio
conditions,
synchronisation : See
chapter RRC Connection
Establishment
UL
Investigate
interference :
See chapter
UL
Interferenc
e
Traffic:
UL/DL ?
DL
Investigate
Tx Power :
See chapter
Tx Power
PIs

-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
106
NOKIA
Confidential

-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
107
NOKIA
Confidential

-Call Setup Time-
Call Setup Time for AMR mobile 3G UE to PSTN

Time
58:30.7
58:31.2
58:31.4
58:31.7
58:32.0
58:32.4
58:32.6
58:32.6
58:33.0
58:33.2
58:33.9
58:34.8
58:35.1
58:35.3
58:35.3
Direction
UL CCCH
DL CCCH
UL DCCH
UL DCCH
DL DCCH
UL DCCH
DL DCCH
UL DCCH
UL DCCH
DL DCCH
DL DCCH
UL DCCH
UL DCCH
UL DCCH
DL DCCH
Message
rrcConnectionRequest
rrcConnectionSetup
rrcConnectionSetupComplete
initialDirectTransfer
downlinkDirectTransfer
uplinkDirectTransfer
securityModeCommand
securityModeComplete
radioBearerSetup
measurementReport
radioBearerSetupComplete
measurementReport
downlinkDirectTransfer (CC: Alerting)
Call Setup Delay (PDF CDF)

100
PDF
CDF
90
80
70
60
50
40
30
20
10
0
0
Average call
setup time
~4.6seconds
108
NOKIA
Confidential
0 to 3000
3000 to 5000
5000 to 8000 8000 to 10000
Setup Time [ms]
> 10000
UE
RNC
Node B
CN
RRC:RRC Connection Request

NBAP:RL Setup Request
NBAP:RL Setup Response
Call Setup
Performance
-Call Setup Time-
ALCAP:ERQ
ALCAP:ECF
Call Setup Time for UDI
RRC:RRC Connection Setup

NBAP:RL Restore Indication
RRC:RRC Connection Setup Complete
RRC:Initial Direct Transfer(MM:CM Service Request)
RANAP:Initial UE Message(MM:CM Service Request)
SCCP:CC
RANAP:Direct Transfer(MM:Authentication Request)
RRC:DL Direct Transfer(MM:Authentication Request)
UDI calls are performed between 2

3G UE
The test results below show that
M-M case time is longer
especially in CN due to B party
waiting time.
Application
Time
in UE
(sec)
Time in
CN (sec)
Total
time
(sec)
MOC UDI
server
2.9
0.2
5.21
MOC TV call 2.9
5.17
10.0
MTC TV call
0.1
5.0
RRC:UL Direct Transfer(MM:Authentication Response)

RANAP:Direct Transfer(MM:Authentication Response)
RANAP:Common ID
RANAP:Security Mode Command
RRC:Security Mode Command
RRC:Security Mode Complete
RANAP:Security Mode Complete
2.9
RRC:UL Direct Transfer(CC:Setup)

RANAP:Direct Transfer(CC:Setup)
CN delay

109
NOKIA
Confidential
UE delay
UE
RNC
Node B
CN

ALCAP:ERQ
ALCAP:ECF
ALCAP:ERQ
ALCAP:ECF
Call Setup
Performance
-Call Setup Time-
Call Setup Time for UDI

UDI calls are performed between 2
3G UE
The test results below show that
M-M case time is longer
especially in CN due to B party
waiting time.
Application
Time
in UE
(sec)
Time in
CN (sec)
Total
time
(sec)
MOC UDI
server
2.9
0.2
5.21
MOC TV call 2.9
5.17
10.0
MTC TV call
0.1
5.0

RANAP:Direct Transfer(CC:Alerting)
RANAP:Direct Transfer(CC:Connect)
2.9
CN delay
110
NOKIA
Confidential
UE delay

-Call Setup Time-
Call Setup Time for UDI mobile 3G UE to stationary 3G

UE
16:29.0
16:29.0
16:30.0
16:30.0
16:31.0
16:31.0
16:31.0
16:31.0
16:31.0
16:31.0
16:32.0
16:33.0
16:34.0
16:39.0
111
NOKIA
rrcConnectionRequest
rrcConnectionSetup
rrcConnectionSetupComplete
initialDirectTransfer
securityModeCommand
securityModeComplete
radioBearerSetup
radioBearerSetupComplete
measurementControl
Call Setup Delay (PDF CDF)

100
90
80
70
60
50
40
30
20
10
0
PDF
CDF
0 to 3000
3000 to
5000
5000 to
6000
6000 to
7000
Setup Time [ms]
Confidential
7000 to
8000
8000 to
10000
> 10000

-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
when a new visitor makes LU authentication

is always used
LOC UP: 1
when LU is made authentication is always

used
For periodical location updates
authentication is not used
when IMSI Attach procedure is made
authentication is always used
MO CALL: 10
112
only every 10th MO call is authenticated

NOKIA
only every 10th MO SMS procedure is

authenticated
For MT calls authentication is not used at all
MT SMS: 0
IMSI ATTACH: 1
MT CALL: 0
PER UP: 0
MO SMS: 10
For MT SMS procedures authentication is not

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

location request procedures
MT USSD: 0
Authentication not used for Mobile Terminated

USSD
Confidential
SS OPER: 0

-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
113
NOKIA
Confidential

-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 RAN04 available 2004 (1Q)
Dynamic 13.6 kbps SRB at RRC connection establishment
SRB 13.6 kbps usage possible without loosing the Iub
capacity
114
NOKIA
Confidential

-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
115
NOKIA
Confidential

-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
116
NOKIA
Confidential

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
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
CS DATA STREAM RABs on a measurement period
UNIT: 10 ms
117
NOKIA
Confidential

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
118
NOKIA
Confidential

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
incremented by 1
AVE SETUP TIME FOR PS DATA INTERACTIVE RAB (M1001C233)
Average setup time for PS DATA Interactive RAB
Average 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
119
NOKIA
Confidential

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
Average 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
UPDATED: When a RAB is successfully set up, this counter
is incremented by 1
UNIT: 10 ms
120
NOKIA
Confidential

Call Setup Time:

For Voice = Average RRC Connection Setup time + Average RAB
Setup time for Voice Setup time
AVE SETUP TIME FOR CS VOICE RAB (M1001C223)
DENOMINATO R FOR AVE SETUP TIME FOR RRC (M1001C222) DENOMINATO R FOR AVE SETUP TIME FOR CS VOICE RAB (M1001C224)
For CS Data Conversational Class = Average RRC Connection

Setup time + Average RAB Setup time for CS data
AVE
SETUP TIME FOR RRC (M1001C221)
AVE SETUP TIME FOR CS DATA CONV RAB (M1001C225)
Conversational
DENOMINATO R FOR AVE SETUP TIME FOR RRC (M1001C222)
DENOMINATO R FOR AVE SETUP TIME FOR CS DATA CONV RAB (M1001C226)
For CS Data Streaming Class = Average RRC Connection Setup

time + Average RAB Setup time for CS data Streaming

AVE SETUP TIME FOR CS DATA STREAM RAB (M1001C227)
DENOMINATO R FOR AVE SETUP TIME FOR RRC (M1001C222) DENOMINATO R FOR AVE SETUP TIME FOR CS DATA STREAM RAB (M1001C228)
For PS Data Conversational Class = Average RRC Connection

Setup time + Average RAB Setup time for PS data
AVE
SETUP TIME FOR RRC (M1001C221)
AVE SETUP TIME FOR PS DATA CONV RAB (M1001C229)
Conversational
DENOMINATO R FOR AVE SETUP TIME FOR RRC (M1001C222)
121
NOKIA
DENOMINATO R FOR AVE SETUP TIME FOR PS DATA CONV RAB (M1001C230)
Confidential

Call Setup Time:

For PS Data Streaming Class = Average RRC Connection Setup
time + Average RAB Setup time for PS data Streaming
AVE SETUP TIME FOR PS DATA STREAM RAB (M1001C231)
DENOMINATO R FOR AVE SETUP TIME FOR RRC (M1001C222) DENOMINATO R FOR AVE SETUP TIME FOR PS DATA STREAM RAB (M1001C232)
For PS Data Interactive Class = Average RRC Connection Setup

time + Average RAB Setup time for PS data Interactive

AVE SETUP TIME FOR PS DATA INTERACTIVE RAB (M1001C233)
DENOMINATO R FOR AVE SETUP TIME FOR RRC (M1001C222) DENOMINATO R FOR AVE SETUP TIME FOR PS DATA INTERACTIVE RAB (M1001C234)
For PS Data Background Class = Average RRC Connection

Setup time + Average RAB Setup time for PS data Background

AVE SETUP TIME FOR PS DATA BACKGROUND RAB (M1001C235)
DENOMINATO R FOR AVE SETUP TIME FOR RRC (M1001C222) DENOMINATO R FOR AVE SETUP TIME FOR PS DATA BACKGROUND RAB (M1001C236)
122
NOKIA
Confidential

-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?
123
NOKIA
Confidential
Contents
Paging
UL Interference
PS Call Performance
124
NOKIA
Confidential

-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
125
NOKIA
Confidential

-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 WBTS6
behavior
also
seen
S6 WCEL61 UPLINK
10:10:10.0
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
PrxTarget + PrxOffset
the
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
126
NOKIA
Confidential

-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.
127
NOKIA
However, the antenna installation of

this site more than suggests that this
site cannot perform normally.
Confidential

-UL Interference-
Normal cell = UL & DL

coverage are balanced
Cell A
Cell suffering from UL

interference = DL
(CPICH) coverage
much bigger than UL
coverage
Cell B
Under the cell suffering from

excessive >>5dB noise rise due
to interference, it is extremely
difficult to initiate a call
RACH procedure might fail
due to not enough margin for
power ramp up (especially in
case the UE is having
problems with Open Loop PC)
Initial TX power for first PRACH
preamble
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
128
NOKIA
Confidential

-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)
129
NOKIA
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
Confidential

-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
130
NOKIA
Confidential

-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
131
NOKIA
Confidential

-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_Power_offset TxCPICH RxRSSI SIRDPCCH 10 log( SFDPCCH )
132
NOKIA
where TxCPICH is then PtxPrimaryCPICH - Cable Loss
Confidential

-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
133
NOKIA
Confidential
-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
Sample 1 : Unloaded
RSSI_LEV _619: -50.2 dBm <= RSSI < -50.1

dBm
Sample 2 : Feasible load area 1
RSSI_LEV _620: -50.1 dBm <= RSSI < -50.0

dBm
RSSI_LEV _621: -50.0 dBm <= RSSI
X = collected sample of PrxTotal measurement

Sample 4 : Marginal load area
Sample 5 : Overload area
134
NOKIA
The correct value in dBm can be

obtained by formula:
-112.0dBm + (RSSI_LEV)/10
Confidential
-UL Interference PIs : PrxTotal measurements The PrxTotal measurements are divided into classes according to
following criteria:
CLASS
AREA
INCREMENTED IF
CLASS
0
Unloaded
(Lrt=<UnloadedRT) AND (Lnrt=<UnloadedNRT)
CLASS
1
Feasible_Load_Area
_1
(PrxTarget -PrxOffset >= PrxTotal ) AND

((Lrt>UnloadedRT) OR (Lnrt>UnloadedNRT))
CLASS
2
Feasible_Load_Area
_2
(PrxTarget > PrxTotal > PrxTarget -PrxOffset) AND

((Lrt>=UnloadedRT) OR (Lnrt>= UnloadedNRT))
CLASS
3
Marginal_Load_Are
a
(PrxTarget + PrxOffset > PrxTotal >=PrxTarget) AND

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

((Lrt>UnloadedRT) OR (Lnrt>UnloadedNRT))
Based on the INCREMENT IF criteria the CLASS is selected and the

measurement result is assigned to the corresponding class and
the amount of samples in the class is put into the
PRXTOT_DENOM_0
135
NOKIA
Confidential
-UL Interference PIs : PrxTotal measurements As en example for CLASS 0:

th at 11pm
Measurement start time is: 2003 March 11th
and as next was same date but 10pm the
measurement/reporting period is 60min
WCELL Name
Start Time
AVE_PRXTOT
CLASS 0
PRXTOT_DENO
M_0
PLMN-PLMN/RNC2/WBTS-1627/WCEL16271
2003031123
84
17972
2003031122
86
17984
2003031121
88
WCELL Name
Start Time
AVE_PRXTOT
CLASS 0
17977
This is already average

value
PRXTOT_DENO
M_0
[dBm]
2003031123
-112.0 + 84/10 =
-103.6
PLMN-PLMN/RNC2003031122
-112.0 + 86/10 =
2/WBTS-1627/WCEL-103.4
16271Call Performance.PPT / 16-09-2003 /Reunanen Jussi
136
NOKIA
17972
17984
This is number of
samples during
measurement period
i.e. as the period is
one hour and RRI
period is 200ms ->
3600s/0.2s = 18 000,
some samples are not
there but in general
~18 000 per one hour
-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
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
137
NOKIA
Confidential
-UL Interference PIs : PrxNoise measurements AVE_PRX_NOISE (M1000C10)

In case the PrxTotal result is
in the unloaded area i.e.
Lrt<UnloadedRT and
Lnrt<UnloadedNRT, the
received PrxTotal value is
used to update the PrxNoise
counter
This counter is a sum over a measurement period divided by a

denominator (averaged value)
UPDATED: In every radio resource indication period
dBm value value can be derived by multiplying with 100
138
NOKIA
Confidential
-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
AREA
INCREMENTED IF
CLASS
0
Unloaded
PtxTotal = PtxCPICH + PtxPCCPCH
CLASS
1
Feasible_Load_Area
_1
PtxTarget -PtxOffset > PtxTotal > (PtxCPICH +

PtxPCCPCH)
CLASS
2
Feasible_Load_Area
_2
PtxTarget > PtxTotal >= PtxTarget - PtxOffset
CLASS
3 NOKIA
Marginal_Load_Are PtxTarget + PtxOffset > PtxTotal >= PtxTarget

Call Performance.PPT / 16-09-2003 /Reunanen JussiCompany Confidential
a
139
-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
Sample 1 : Unloaded
Resource Indication message
arrives

Sample 4 : Marginal load area
Sample 5 : Overload area
140
NOKIA
Confidential
-UL Interference PIs : Lrt & Lnrt measurements Lrt means RT traffic load in a cell. The value is between [0...1[
Lnrt means NRT traffic load in a cell. The value is between [0...1[
(1 i) Lown
By load we mean calculated fractional load
in a cell
(own and other cell user interference)
the uplink interference a user will cause in the cell can be
solved
P
R
R
Prx
R W
Prx _ total
rx
Prx _ total
R W
the load factor of all the users in the L

cell
own
Lown
Own _ cell _ users
141
NOKIA
Prx _ own
Prx _ total
Lown
Confidential
L load factor
-UL Interference PIs : Lrt & Lnrt measurements From obtained fractional load :
Lnrt
Lnrt
Lnrt
Lrt
N _ nrt _ active _ UL
i 1
Prx _ nrt
Prx _ total
Prx_nrt
1
W
1
i Ri
i 1
Lrt
1
Prx_total
W
1
i Ri
Lrt + Lnrt = Lown Lown
Lrt
N _ rt _ active _ UL
Prx _ rt
Prx _ total
i 1
Prx_rt
1
W
1
i Ri
i 1
1
Prx_total
W
1
i Ri
Own _ cell _ users
Own cell real time user/ non-real time user load can be obtained by
multiplying Lrt/Lnrt by PrxTotal
142
NOKIA
Confidential

-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
AREA
INCREMENTED IF
CLASS
0
Unloaded
PtxTotal = PtxCPICH + PtxPCCPCH
CLASS
1
Feasible_Load_Area
_1
PtxTarget -PtxOffset > PtxTotal > (PtxCPICH +

PtxPCCPCH)
CLASS
2
Feasible_Load_Area
_2
PtxTarget > PtxTotal >= PtxTarget - PtxOffset
NOKIA
CLASS
Call Performance.PPT / 16-09-2003 /Reunanen

JussiCompany
Marginal_Load_Are
PtxTarget
+Confidential
PtxOffset > PtxTotal >= PtxTarget
143

-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
144
NOKIA
Confidential

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
145
NOKIA

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
Ptx, nrt
P
i 1
where
tx ,i
Ptx, i Ptx_average
Ptx, rt
P
i 1
where
tx ,i
Ptx, i Ptx_average
From 25.133
Reported value
UTRAN_CODE_POWER _010
146
NOKIA
Measured quantity value

-10.0 Transmitted code power < -9.5
45.0 Transmitted code power < 45.5

Unit
dBm
dBm
dBm
dBm
dBm
dBm
Confidential
reported-RL-Information-RL-Meas-Rep
- length (in bits): 00000
Reported-RL-InformationItem-RL-Meas-Rep
- extension flag: 0
- preamble: 00
- rL-ID: 1
- contents (in bits): 00001
measurement-1-Avail-Ind
- extension flag: 0
- choice index: 0
measurement-Available
- extension flag: 0
- average-DL-TransmittedPower: 80
- contents (in bits): 1010000
- trailing bits: 0
Contents
Paging
Call Setup Time
UL Interference
Loss of Synchronization DL/UL
SHO Performance
PS Call Performance
147
NOKIA
Confidential

-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 reestablished 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
148
NOKIA
Confidential

-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
149
NOKIA
Confidential

-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
T313
started
N_OUTSYNC_IND
out of sync
indicators
out of sync
indicators
Timer
T_RLFAILUR
E started
Timer T313
stopped and
reset
Timer
T_RLFAILUR
E stopped
and reset
N313 amount of out

of sync indicators
150
NOKIA
N_INSYNC_INDin
sync indicators
in sync
indicators on
L1
N315 L1 in
sync indicators
Confidential

if T313 expires:
consider it as a "Radio link failure"
N_OUTSYNC_IND
out of sync
indicators
N313 amount of
out of sync
indicators
151
NOKIA
Timer
T313
expires
Timer
T315
expires
RNC receives
RNC sends
NBAP:RADIO LINK
NBAP:RADIO
Radio Link Failure
FAILURE message
LINK
DELETION
form BTS with a cause
message
value
"Synchronization
Failure" Enter Idle mode in
case timer T302 or
Timer
Timer
T314 are not running.
T315
T314
T302 is the timer for
started
started
Cell/URA Update
When the criteria for
When the criteria for
retransmissions.
radio link failure are
radio link failure are
No refulfilled.
fulfilled.
establishment for
The timer is started
The timer is started if
RT services in
only if radio bearer(s)
radio bearer(s) that are
current release ->
that are associated
associated with T314
T314 is for Tr and
with T315 exist.
exist of if only RRC
UM bearers
Currently all the radio
connection exists.
links are associated
with T315
Not implemented in
Timer
T313
started
out of sync
indicators
Re-establishment
timer for NRT
services (AM
bearers)
Timer
T_RLFAILUR
E started
T_L1_Sync_ReEstab_W
ait timer started in
RNC
Timer
T_L1_Sync_ReEstab_
T_RLFAILURE
Wait timer expired
expires
NokiaConfidential
RAN currently

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
152
NOKIA
Confidential
Contents
Paging
Call Setup Time
UL Interference
SHO Performance
PS Call Performance
155
NOKIA
Confidential

-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
1.5
Addition Window (dB)
2
Addition Time (ms)
100
100
Drop Window (dB)
4
2.5
Drop Time (ms)
640
640
Replacement Window (dB)
2
2
Replace Time (ms)
100
100
MaximumActive Set Size
3
3
CPICH Ec/No filter Coefficient
3
3
Active Set Weighting Coefficient
0
0
156
NOKIA
Confidential
CPICH Ec/No [dB]

-SHO Performance-
CPICH Ec/No Filter Coefficient:Parameters
Value

Addition Time (ms)
Drop Window (dB)
Drop Time (ms)
Replace Time (ms)
Maximum Active Set Size
3 (600ms), default
4 (800ms)
5 (1100ms)
6 (1600ms)
Number of dropped calls Average active set size

(RT)
Power (dBm)
157
NOKIA
By comparing
the results of
different
parameter sets,
the default value
3 should be the
optimal one--highest SHO
gain, good KPIs
and time
proper
Average
between SHO
UE Power (dBm)
ASoverhead.
updates (s)
Confidential
0 (200ms)
2 (400ms)
3 (600ms), default
2.5
100
4
640
2
100
3
0, 1, 2, 3, 4, 5, 6
0
By comparing the
results of different
parameter sets, the
default value 3
should be the optimal
one---highest SHO
gain, good KPIs and
proper SHO
overhead.

-SHO Performance-
60ms
80ms
100ms, default
120ms
160ms
Parameters
Addition Time (ms)
Drop Window (dB)
Drop Time (ms)
Replace Time (ms)
By looking at the No.

of dropped calls, only
80ms and 100ms
could be acceptable.
The SHO overhead
with AddTime= 80ms
is too high, so 100ms
was selected as the
best one.
Value
2.5
60, 80, 100, 120, 160
4
640
2
100
3
3
0
ower (dBm)
Parameters
Value
2.5
Addition Time (ms)
60
Drop Window (dB)
4
Drop Time (ms)
120, 240, 320, 640, 1280
2
Replace Time (ms)
100
Maxim
Active Set
Sizeset size Average time between
r of dropped
callsumAverage
active
UE3Power (dBm)
(RT)
AS updates (s)
3
0
158
NOKIA
240ms
320ms
640ms, default
1280ms
Confidential
Only the value

640ms can
provide an
acceptable KPIs
by looking at the
number of
dropped calls.

-SHO Performance-
Parameters
Addition Time (ms)
Drop Window (dB)
Drop Time (ms)
Replace Time (ms)
Maximum Active Set Size
umber of dropped
calls
Average active set size

1.5 / 2.5
(dB)
(RT)
1.5 / 3 (dB)
1.5 / 3.5 (dB)
1.5 / 4.5 (dB)
1.5 / 7.5 (dB)
159
NOKIA
Power
(dBm)
Value
0.5, 1.5, 2.5, 3.5
100
2, 3, 4, 5
640
2
100
3
3
0
By
comparing
Average
time between
the
SHO(s)
AS
updates
overhead,
number of
drop calls and
UE Tx power,
the parameter
set 1.5/ 2.5 is
the best one.
0.5 / 2 (dB)
1.5 / 3 (dB)
2.5 / 4 (dB), default
3.5 / 5 (dB)
By considering
the SHO
overhead,
Number of
dropped calls and
UE Tx power at
the same time,
the parameter set
1.5 /3 is seen as
the best one.
UE Power (dBm)
Parameters
Addition Time (ms)
Drop Window (dB)
Drop Time (ms)
Replace Time (ms)
Value
1.5
100
2.5, 3, 3.5, 4.5, 7.5
640
2
100
3
3
0

-SHO Performance-
Parameters
Addition Time (ms)
Drop Window (dB)
Drop Time (ms)
Replace Time (ms)
ropped
m)
2.5
100
3.5, 4, 4.5, 5.5
640
2
100
3
3
0
Average active set size Average time between

(RT)
AS updates (s)
1dB
2dB
160
Value
NOKIA
2.5
2.5
2.5
2.5
/
/
/
/
3.5 (dB)
4 (dB), default
4.5 (dB)
5.5 (dB)
The tested
sets did not
show better
performanc
e as the set
1.5/ 2.5.
UE Power (dBm)
The value 1 can

gives more SHO
gain (lower UE Tx
power) and better
performance (less
number of dropped
calls), but the effect
is not so significant.
Parameters
Addition Time (ms)
Drop Window (dB)
Drop Time (ms)
Replace Time (ms)
Value
1.5
100
3
640
1, 2
100
2
3
0

-SHO Performance-
Parameters
Addition Time (ms)
Drop Window (dB)
Drop Time (ms)
Replace Time (ms)
er of dropped
calls
1.5
100
3
640
2
100
2, 3
3
0
Max AS size= 2
Max AS size= 3
Max AS size= 2
gives lower SHO
overhead, but the
value 3 provides
more SHO gain. No
big difference for
the other KPIs. Max
AS size= 3 was still
the better one.
Average active set size Better

Average time
between
UE Power (dBm)
performance
(RT)
AS updates (s)
100ms
640ms
Bm)
161
Value
NOKIA
with 100ms by
looking at the
number of dropped
calls. But both the
parameter have no
big affect to the SHO
gain and SHO
overhead
Parameters
Addition Time (ms)
Drop Window (dB)
Drop Time (ms)
Replace Time (ms)
Call Performance.PPT / 16-09-2003 /Reunanen JussiCompany ConfidentialActive Set Weighting Coefficient
Value
1.5
100
3
640
1
100, 640
2
3
0

-SHO Performance-
Parameters
Addition Time (ms)
Drop Window (dB)
Drop Time (ms)
Replace Time (ms)
Value
1.5
100
3
640
2
100
3
3
0, 1
ASWeightingCoeff= 0
ASWeightingCoeff= 1
Active Set Weighting

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

(RT)
AS updates (s)
162
NOKIA
UE Power (dBm)
Confidential
The value 1 can

give us lower
SHO overhead
and more gain
(lower UE Tx
power) at the
same time. But
this parameter
still need fullly
test.

-SHO Performance-
20 - 25
15 - 20
11 - 15
10 - 11
9 - 10
8-9
7-8
6-7
5-6
4-5
3-4
2-3
1-2
0-1
# of events
Difference in ASU period (measured as time between ASU Complete

messages) from two different environments: Case A; HongKong and
Case B;Time
Osaka
between "ASU complete" messages
Case A:
200
Average time between
150
Measurement 3
100
Measurement 2
Active Set Update is 2Measurement 1
50
3 seconds which is
0
very small compared
to the Case B
seconds
Case B:
Average time between
active set updates is 510 seconds
45
40
35
30
25
20
15
10
5
0
163
NOKIA
seconds from call setup
115 - 120
105 - 110
95 - 100
85 - 90
75 - 80
65 - 70
55 - 60
45 - 50
35 - 40
25 - 30
15 - 20
5 - 10
2-3
ASU time
0-1
# of ASUs
ASU time
Confidential
It can be seen that the

smaller cells (a lot of
micro cells in Case A and
only macros in Case B)
shorter the time between
ASUs

-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!
164
NOKIA
Confidential

-SHO Performance-
ASU period can be measured based on the counters as:

Total time of measurement - (One cell in the active set for RT (M1001C0)
One cell in the active set for NRT (M1007C19))
Avg Time between AS Update
sum(successful Active Set Updates OnSHO For RT Traffic (M1007C15)
Successful Active Set Updates On SHO For NRT Traffic (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
AS update AS update
No calls
AS update
AS size=1
165
NOKIA
AS update
AS size=2 AS size=3 AS size=2
AS update
AS size=1
AS size=1
No calls
AS update AS update
Confidential
AS update
AS size=2 AS size=3 AS size=2

Total Time of Measurement
AS size=1

-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
Ec/No
measurement
report sent :
AMR
measurement
report sent : PS
384
Addition window /
Replacement window
time
166
NOKIA
Ideal timing for

measurement
measurement report
report sent : PS
sending after e.g. Addition
64 or UDI (CS
time
T64)
This kind of UE behavior

cannot be completely
fixed but results can be
improved by adjusting:
Addition window
Addition time
Replacement window
Replacement time
UE seem to have parallel processes

-SHO Performanceongoing I.e. measurement control
Time
ongoing
I.e. measurement
control
Plotted Data [ Line(6501 to 7000); Time(11:34:34
to 11:35:38)
]
and therefore there is 2sec. delay in
sending the measurement report
Monitored
Active Set
Set SC /
SC / Ec/No
Ec/No [dB]
[dB]
Message
100
80
11:35:20
Measurement
Control
60
11:35:20
40
11:35:21
20
188 / -8.5
35 / -13.5
309 / -9.5
97 / -18.5
188 / -3.5
35 / -8.5
309 / -11.5
97 / -23.5
-40
11:35:22
188 / -5.5
35 / -11.5
309 / -19.5
97 / <-24
188 / -5.5
35 / -14.5
309 / -21.5
97 / <-24
-60
11:35:23
-80
Measurement
Report e1c: SC188,
SC35, SC309, SC97
-120
CpichRscp
167
NOKIA
Sir
TargetSir
UeTxPower
HOIndication
DpchRscp
Confidential
DlTransportChannelBler_1
N/A
N/A
N/A
N/A
N/A
N/A
0[A]
N/A
N/A
N/A
N/A
21[A]
N/A
N/A
21[A]
N/A
N/A
21[A]
N/A
N/A
N/A
N/A
SC309 =
-12.5 SC97
= -23.5
N/A
N/A
N/A
N/A
N/A
N/A
N/A
SC188 = -5.5
SC35 = -10.5
309 / -12.5
97 / -23.5
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
21[A]
N/A
N/A
N/A
N/A
N/A
N/A
N/A
Measurement
Report e1c: SC188,
SC35, SC309, SC97
188 / -5.5
35 / -10.5
-10
EcNo/ASS
-20
N/A
N/A
N/A
N/A
-5
11:35:22
-100
10
There is no
-15
response to
measurement
report e1c
-20
messages by the
network as the first
measurement -25
report is sent too
late by the UE and
-30
the call drops
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
performa
nce due
to
coverage
168
NOKIA
High BLER, high

variance with DL SIR
and a lot of SHO
activity
Confidential
Low variance
of SIR,
ASS=2,
stable BLER
and
throughput

-SHO Performance: UL Interference-

Cell A

interference = DL
(CPICH) coverage much
bigger than UL coverage
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
169
NOKIA
Confidential

BTS
UE
RNC
Normal cell = UL
& DL coverage
are balanced
RRC: Measurement Report (e1a / e1c)
Cell suffering from

UL interference = DL
(CPICH) coverage
much bigger than UL
coverage
Decision to set up new RL
NBAP: Radio Link Setup Request
NBAP: Synchronization
Indication
Start TX/RX
UL Synchronisation Procedure starts
Cell A
NBAP: Radio Link Setup Response

ALCAP:ERQ
ALCAP:ECF
RRC: Active Set Update
UE Synchronisation Procedure starts: According to
Synchronisation Procedure B
RRC: Active Set Update Complete
Active Set
Update: 1a,
1c to add cell
B
NOKIA
DL
UL & DL
Ec/No
UL
Addition window /
Replacement window
As the UE Tx power is not enough for

Cell B synchronisation, the SHO can
fail
170
Cell B
Addition/
Replacement
time
Confidential
UE -> RNC :
Measurement report :
e1a / e1c
distance
Active Set
Update
complete

Normal cell = UL &

DL coverage are
balanced

interference = DL
bigger than UL coverage
Cell A
Cell B
Less than N_INSYNC_IND
indicators on L1
Measureme
nt report
e1A: CellB
RNC sends RRC: Active

Set Update - message
to UE -> Starts timer
T_RRC_Resp_DCH
T313 expires -> UE

considers Radio Link
Failure for Cell B ->
UE drops the Cell B
from AS
UE starts T313 for
Cell B after
receiving N313
out-of-sync for Cell
B
BTS stops UL
Synchronization
procedure and Tx
send NBAP:
SYNCHRONIZATION
IDICATION -message
BTS UL Synchronization
SHO Decision
After receiving
RNC sends
procedure continues until L1
algorithm Cell
ASU UE Starts DL
NBAP:RADIO
LINK
B -> Setup RL
Synchronization is achieved
Synchronization
DELETION
-> NBAP: Radio

or NBAP: RL Deletion
procedure -> and
message
Link Setup
sends ASU
message is received
Request (Chip
Complete
Offset)
Successful resource allocation in Cell B BTS ->
RNC does not receive
BTS Starts Tx (DPCH) -> BTS Starts UL
synchronization indication
-> timer
Synchronization
procedure
sends
NBAP:
171
NOKIA
Call
Performance.PPTand
/ 16-09-2003
/Reunanen
JussiCompany Confidential
Counter: RL DEL
ON SRNC DUE TO
INI SYN FAIL
(M1005C67) updated

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

UL and DL coverage i.e. decrease the CPICH Tx
power by the UL noise rise
+ Can be done cell by cell basis
+ Relatively easy to implement algorithm for
Cell A
autotuning
- Coverage is reduced also in the cases
when there is no UL interference
Active Set
Update: 1a,
- Requires autotuning feature otherwise cell
1c to add
UL & DLcell B
coverage is reduced in DL all the time
Use cell individual offset to lower the CPICH
Ec/No
Ec/No by the noise rise value
Addition window /
+ Can be done cell by cell basis
Replacement window
+ Does not affect to the coverage
- Needs some algorithm to tune the cell
Addition/
individual offset according to existing noise Replacemen
t time
rise
UE -> RNC :
- The UEs might have problem with too big
Measurement
report : e1a / e1c
difference between actual CPICH powers
also DL power drifting might cause
problems
NOKIA
Confidential

interference = DL
bigger than UL
coverage
Cell B
L1 synchronization
not achieved
between new cell
and UE, monitored
by the BTS
DL
UL
DL
Drop
window
distance
Active Set
Update
complete
RNC
sends
Active Set
Update :
e1b to
remove
the cell A

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

synchronization is achieved to the target cell
- New drop window is used for each neighbor
cell definition
- Needs some algorithm to tune the drop
window according to existing noise rise and Cell A
cell by cell basis somehow
+ Easy to test to see if situation can be
improved
Active Set
Update: 1a,
1c to add
UL & DLcell B
also DL power drifting might cause problems
Change the drop timer to be long enough so that
Ec/No
UL synchronization is achieved to the target cell
Addition window /
- New drop time is used for each neighbor cell
Replacement window
definition
- Needs some algorithm to tune the drop time
Addition/
according to existing noise rise and cell by
Replacemen
t time
cell basis somehow
- Easy to test to see if situation can be
UE -> RNC :
Measurement
improved
report : e1a / e1c
also DL power drifting might cause problems
NOKIA
Confidential

interference = DL
bigger than UL
coverage
Cell B
L1 synchronization
not achieved
between new cell
and UE, monitored
by the BTS
DL
UL
DL
Drop
window
distance
Active Set
Update
complete
RNC
sends
Active Set
Update :
e1b to
remove
the cell A
-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 therefore have the
connection on without dropped
calls
Cell A
Cell B
Without cell individual offsets
UL & DL
UL & DL
Ec/No
Cell A
NOKIA
route
Addition window /
Replacement
window
Cell B
174
The call drops due to

too rapid CPICH
coverage
degradation for Cell
A, and therefore
there is not enough
time for SHO
UE -> RNC :
e1a / e1c
Addition/
Replacement
time
-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 shortened)
Cell A
Cell B
With cell individual offsets
See next case
Active Set
Update: 1a,
1c to add cell
B
UL & DL
Ec/No
UL
Cell individual
offset
Cell A
Addition window /
Replacement
window
175
NOKIA
UE -> RNC :
e1a / e1c
Cell B
DL
route
Active Set
Update
complete
Addition/
Replacement
time

-DL Coverage < UL Coverage-
In case there is a cell with

lower CPICH power than the
surrounding cells are having
then this cell is having too
good UL performance as
this cells UL cannot be used
efficiently due to SHO is
decided upon DL (CPICH
Ec/No)
To improve this and include
the cell into AS earlier than
CPICH Eke/No would allow, it
is possible to use cell
individual offsets for this
purpose
176
NOKIA

Cell having lower DL

coverage = DL (CPICH)
power is lower than
adjacent cells
Cell A
UL & DL
Ec/No
Cell B
Active Set
Update: 1a,
1c to add cell
B
Cell B starts to
suffer from UL
interference due
to UE getting
closer to Cell B
wo SHO
Addition window /
Replacement
window
UE -> RNC :
e1a / e1c
UL
DL
distance
Active Set
Update
complete
Addition/
Replacement
time

If Cell B is having cell

individual offset set
according to the difference
of CPICH powers between
Cell A and Cell B, the SHO
can happen correct time
and Cell B can be utilized
fully
However currently the
added cells initial Tx power
is set according to the
i.e.
existing cell
MAX R
TFCTFCS
In case
TFTFC
ILcell
the
best
Ptx, init
p ( c, Ptx_total ),
W
Ec/No is known
ILP ( c, Ptx_total)
177
NOKIA
1
Ptx, CPICH Ptx_total.
c


power is lower than
adjacent cells
Cell A
Cell B
Active Set
Update: 1a,
1c to add cell
B
UL
UL & DL
DL
Ec/No
Addition window /
Replacement
window
UE -> RNC :
e1a / e1c
distance
Active Set
Update
complete
Addition/
Replacement
time

However currently the

added cells initial Tx power
is set according to the
existing cell i.e.
In case the best cell
Ec/No
not known
Ptx ,initial ,new
Ptx ,ave,is
highest Ptx ,CPICH , new Ptx ,CPICH , highest
It should be noted that
neither of the formulas
include information about
the cell individual offset and
due to that the SHO to cell,
which is having cell
individual offset (high
value), might have problems
Synchronization in DL
direction difficult
178
NOKIA


power is lower than
adjacent cells
Cell A
Cell B
Active Set
Update: 1a,
1c to add cell
B
UL & DL
Ec/No
Addition window /
Replacement
window
UE -> RNC :
e1a / e1c
UL
Cell individual
offset
Tx power for the
Cell B DPCH is not
enough -> DL
synch not
achieved -> SHO
failure
distance
Active Set
Update
complete
Addition/
Replacement
time
DL
Received message RRC: Measurement Report (e1A).

Triggers for RT:
M1007C10 CELL ADDITION REQUEST ON SHO FOR RT
TRAFFIC
Received message RRC: Measurement Report (e1B).
Triggers for RT:
BTS
RNC
UE
M1007C11 CELL DELETION REQUEST ON SHO FOR RT
TRAFFIC
Received message RRC: Measurement Report (e1C).
Triggers for RT:
Decision to
M1007C12 CELL REPLACEMENT REQUEST ON SHO
set up new RL
FOR RT TRAFFIC
Received message RRC: Measurement Report (e1A).
NBAP: Radio Link Setup Request for Soft Handover
Triggers for NRT:
M1007C27 CELL ADDITION REQUEST ON SHO FOR NRT
NBAP: Radio Link Addition Request for Softer Handover
TRAFFIC
Received message RRC: Measurement Report (e1B).
Start TX/RX
Triggers for NRT:
M1007C28 CELL DELETION REQUEST ON SHO FOR
NRT TRAFFIC
NBAP: Radio Link Addition Response
Received message RRC: Measurement Report (e1C).
Triggers for NRT:
ALCAP:ERQ
For each
cell already
M1007C29 CELL REPLACEMENT
REQUEST
ON SHO in AS
ALCAP:ECF
FOR NRT TRAFFIC
the above counters are
-SHO Performance : PIs-

B

A
179
NOKIA
Confidential
updated i.e. in this case 2

cells
At first (UE in point A) AS

includes 2 cells
Then UE moves to point B
and reports e1A to add
blue cell
Number of DCH requests for Diversity HO (SHO) for

voice calls in SRNC
M1002C16 RT DCH DHO REQ FOR CS VOICE CALL IN
SRNC
Number of DCH requests for a CS Voice Call rejected by
BTS
RNC
the SRNC for reasons caused by radio resources in the
UE
target cell of diversity handover
M1002C17 RT DCH DHO REQ FOR CS VOICE CALL
REJECT IN SRNC
Decision to set up new RL Number of DCH requests for a transparent CS Data Call
with conversational class due to diversity handover in
the SRNC
M1002C58 RT DCH DHO REQ FOR CS DATA CALL CONV
UL Synchronisation Procedure starts CLASS IN SRNC
Start TX/RX
Number of DCH requests for a transparent CS Data Call
(on SRNC side) rejected for reasons caused by radio
resources in the target cell of diversity 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 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
ccording to Synchronization Procedure B
STREAM CLASS IN
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
In case BTS responses back to RNC by
M1002C61RT DCH DHO REQ FOR CS DATA CALL
NBAP: RL Setup Response/RL Addition
STREAM CLASS REJECT IN SRNC
Response
In case
RNC sends to BTS NBAP: RL Setup
SAME
FORof
DRNC!
M1005C6: RL SETUP SUCC FOR SHO ON
Request/RL Addition Request
SRNC
M1005C1: RL SETUP ATT FOR SHO ON SRNC
M1005C8:RL SETUP SUCC FOR SHO ON
M1005C3:RL SETUP ATT FOR SHO ON DRNC
DRNC
M1005C42: RL BRANCH ADD ATT FOR SHO ON SRNC
M1005C44: RL BRANCH ADD SUCC FOR SHO
M1005C43: RL BRANCH ADD ATT FOR SHO ON DRNC
ON SRNC
-SHO Performance: PIs-
NBAP: Synchronization Indication
M1005C45: RL BRANCH ADD SUCC FOR SHO

ON
180SRNC
NOKIA

BTS
UE
RNC

Decision to
set up new RL
Start TX/RX
ALCAP:ERQ
ALCAP:ECF
RRC: Active Set Update Failure
181
NOKIA
Received message RRC: Active Set Update Complete.

Triggers:
M1007C15 SUCCESSFUL ACTIVE SET UPDATES ON SHO
FOR RT TRAFFIC
Received message RRC: Active Set Update Complete.
Triggers:
M1007C32 SUCCESSFUL ACTIVE SET UPDATES ON SHO
FOR NRT TRAFFIC
Received message RRC: Active Set Update Failure.
Triggers:
M1007C16 UNSUCCESSFUL ACTIVE SET UPDATES ON
SHO FOR RT TRAFFIC
Received message RRC: Active Set Update Failure.
Triggers:
M1007C33 UNSUCCESSFUL ACTIVE SET UPDATES ON
SHO FOR NRT TRAFFIC
For each cell in the AS the above

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

UE is in Spot A i.e.
not in soft handover
-> AS size = 1
2
1
UE in Spot B sends
Measurement
report indicating
e1A to add cell 2
-> M1007C10 CELL
ADDITION
REQUEST ON SHO
FOR RT TRAFFIC is
updated in cell 1
UE
BTS
RNC
Decision to set up new R

UL Synchronisation
Start TX/RX
Procedure starts
NBAP: Radio Link Setup Respons
ALCAP:ERQ
ALCAP:ECF
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 SHORequest, if RL Setup Is successful,
starts TX/RX and UL Synchronization
ON SRNC counter in cell 2
procedure and sends NBAP: RL Setup
Response to RNC
182
NOKIA
Confidential

-SHO Performance : PIsUE
RNC Sends RRC: Active Set Update

message to the UE
BTS
RNC
Decision to set up new R

UL Synchronisation
Start TX/RX
Procedure starts
NBAP: Radio Link Setup Respons
ALCAP:ERQ
ALCAP:ECF

After receiving RRC: Active Set Update from According
to Synchronization Procedure B
RNC the UE checks the Update message and
if ok UE starts Synchronization Procedure B
and and sends RRC: Active Set Update
Complete message without waiting for theWhen receiving RRC: Active Set Update
completion of the Physical Layer
Complete, the RNC updates M1007C15
synchronization procedure B (according toSUCCESSFUL ACTIVE SET UPDATES ON
25.214/25.331)
SHO FOR RT TRAFFIC or M1007C32
183
NOKIA
SUCCESSFUL ACTIVE SET UPDATES ON

SHO FOR NRT TRAFFIC counter. Counter
updated for cell 1.

The Active Set Update success rate can be calculated as:

Active Set Update Success Ratio ( RT ) 100 *
Active Set Update Success Ratio( NRT ) 100 *
sum( Successful Active Set Updates On SHO For RT Traffic ( M 1007C15))

%
sum( Successful Active Set Updates On SHO For RT Traffic ( M 1007C15)
Unsuccessful Active Set Updates On SHO For RT Traffic ( M 1007C16))
sum( Successful Active Set Updates On SHO For NRT Traffic ( M 1007C 32))
%
sum( Successful Active Set Updates On SHO For NRT Traffic ( M 1007C 32)
Unsuccessful Active Set Updates On SHO For NRT Traffic ( M 1007C 33))
UE
Formula does not take into account

the cases where measurement
report is sent several times until
RNC responds with RRC: Active Set
Update -> Counters1007C16 and
1007C33 are updated only in case
UE responds to Active Set Update
message with Active Set Update
Failure message.
184
NOKIA
BTS
RNC

UL Synchronisation
Start TX/RX
Procedure starts
ALCAP:ERQ
ALCAP:ECF

According to Synchronization Procedure B
Confidential

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
185
NOKIA
Confidential

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 / Addition Success ( SHO)

M1005C42 M1005C43 M1005C1 M1005C3
100 *
%
M1005C44 M1005C45 M1005C6 M1005C8
186
UE
RNC

And separate failure reasons can be

identified based on M1005C16
M1005C21, M1005C28 M1005C33,
M1005C46 M1005C57 and M1005C58
M1005C65
NOKIA
BTS
UL Synchronisation
Start TX/RX
Procedure starts
ALCAP:ERQ
ALCAP:ECF
Confidential

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 Allocation Success ( SHO)
M 1002C17 M 1002C 59 M 1002C 61 M 1002C103 M 1002C105 M 1002C107 M 1002C109

100%
M1002C16 M1002C58 M1002C60 M1002C102 M1002C104 M1002C106 M1002C108
Where nominator is stating the

number of DCH allocation requests in
the target cell for Diversity
Handover (SHO) for RT traffic classes
(Speech+Conversational CS data +
Streaming CS Data) and NRT traffic
classes (Conversational PS data +
Streaming PS data + Interactive PS
data + Background PS data)
Where denominator is the allocation
rejections due to lack of radio
resources in target cell
187
NOKIA
UE
BTS
RNC

UL Synchronisation
Start TX/RX
Procedure starts
ALCAP:ERQ
ALCAP:ECF
Confidential

-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
214
NOKIA
Confidential

-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
215
NOKIA
Confidential
Contents
Paging
Call Setup Time
UL Interference
SHO Performance
PS Call Performance
216
NOKIA
Confidential

-Power per Connection40
20
-40
Ec
217
NOKIA
EcIo
Sir
90
1.
80
-60
15:45:16.00
15:45:16.00
15:45:15.00
15:45:15.00
15:45:14.00
15:45:13.00
15:45:12.00
15:45:11.00
15:45:10.00
15:45:10.00
15:45:09.00
15:45:08.00
e1b, 1 active set cell

dropped (become 1-way
active)
2.
70
60
50
DLTrchBLER
increase rapidly
3.
40
30
-80
This case can be improved by

allowing more power window in DL
for the PC to operate
Call drop
-20
As the SIR getting lower and lower

until the call drops this suggests
that the DL power has reached its
maximum
100
15:45:08.00
Observations from the case on the right:

1. SIR cannot be maintained at the
correct level
2. Ec/No is ok
3. BLER Increases to 100%
4. Target SIR increases at the same
time as BLER increases to 100%
4.
20
-100
10
-120
TargetSir
Confidential
ActiveSetSize
DlTrChBler

-Power per Connection-
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 )
DL tx pwr per
Connection [dBm]
/ BLER [%]
RI max,eff
Ptx ,CPICH
C pichTo Re fRabOffset
Max
power
Min
power
Min
power
time
time
Call drop
NOKIA
Ptx , ref
DL tx pwr per
Connection [dBm]
/ BLER [%]
Max
power
218
RI max
ref RI ref
Confidential

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
219
NOKIA
Confidential

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)
220
NOKIA
Confidential
Contents
Paging
Call Setup Time
UL Interference
SHO Performance
PS Call Performance
221
NOKIA
Confidential
Contents
Paging
Call Setup Time
UL Interference
SHO Performance
PS Call Performance
222
NOKIA
Confidential
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
DELIVERY ORDER
DELIVERY OF ERRONEOUS SDU
ND
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
223
NOKIA
Confidential
PS Call Performance
BLER versus avg. RTT for different ping sizes using 64 kbps
bearer
900
RTT in milli seconds
800
700
600
32 bytes
500
512 bytes
400
1472 bytes
300
200
100
0
0
10
15
BLER %
224
NOKIA
Confidential
20
25
PS Call Performance
Avg. Round Trip Times for different ping sizes at various BLER using
64kbps bearer
900
800
Delay in milli seconds
700
600
0.63% BLER
500
1% BLER
5% BLER
400
20% BLER
300
200
100
0
0
200
400
600
800
1000
1200
Ping Size in bytes

225
NOKIA
Confidential
1400
1600
PS Call Performance
BLER versus Average FTP Upload Throughputs for various file sizes
using 64kbps bearer
60
Throughput in Kbit/s
50
40
16KB
64KB
30
500KB
1024KB
20
10
0
0
10
15
BLER %
226
NOKIA
Confidential
20
25
PS Call Performance
FTP Upload Throughputs at different BLER & file sizes using
64kbps bearer
60
Throughput in kbit/s
50
40
0.63% BLER
1% BLER
30
5% BLER
20% BLER
20
10
0
0
200
400
600
800
File sizes in kilo bytes
227
NOKIA
Confidential
1000
1200
PS Call Performance
Standard deviations in the Round Trip Times
(milliseconds) for each ping size at a certain BLER
levelPing Size
32 bytes
512 bytes
1472 bytes
BLER
%
228
NOKIA
0.63%
11ms
22ms
37ms
1%
25ms
36ms
42ms
5%
86ms
98ms
114ms
20%
172ms
214ms
144ms
Confidential
PS Call Performance
0.63 % BLER
1MB
UL #
1
2
3
229
1 % BLER
0.63 % BLER
1MB
Total bytes Re-xmt bytes Re-xmt %

1048404
0
0,0 %
1048404
0
0,0 %
1048404
0
0,0 %
UL #
1 % BLER
1
2
3

1048404
0
0,0 %
1048404
0
0,0 %
1048404
0
0,0 %
DL5#% BLER
1
1048404
0
0,0 %
1MB
5
%
BLER
2
1048404
0
0,0 %
3
1048404
0
0,0 %
UL #
1
1048404
0
0,0 %
2
1048404
0
0,0 %
3
1048404
0
0,0 %
20# % BLER
DL
1
1048404
0
0,0 %
1MB
20
%
BLER
2
1048404
0
0,0 %
3
1048404
0
0,0 %
UL #
1
1048404
67160
6,4 %
2
1048404
67238
6,4 %
3
1048404
52560
5,0 %
DL #
DL #
NOKIA

1
1048404
0
0,0 %
2
1048404
0
0,0 %
3
1048404
0
0,0 %
Confidential

1
1048404
0
0,0 %
2
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
230
NOKIA
Confidential
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
231
NOKIA
Confidential

Call Performance

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Call Performance

Загружено:

Авторское право:

Доступные форматы

WRST 4

Call Performance.PPT / 16-09-2003 /Reunanen Jussi

Idle Mode Performance

RRC Connection Establishment Performance

RAB Establishment Performance

Call Setup Failure & Time

Dropped Call Performance

SHO Performance (round-the-corner)

DL Power Allocation Parameters

UL Power Allocation Parameters

Call Performance.PPT / 16-09-2003 /Reunanen Jussi

Call Setup Performance

Several UEs cannot perform cell reselection during RRC

RNC responds with RRC

The UE sends all the rest of the RRC Connection Request

UE moving from Cell A towards Cell B

Call Performance.PPT / 16-09-2003 /Reunanen Jussi

Call Setup Performance

Default parameter settings

Call Performance.PPT / 16-09-2003 /Reunanen Jussi

Call Setup Performance

Default parameter settings

Qhyst2= -16dB + 4dB =

Call Performance.PPT / 16-09-2003 /Reunanen Jussi

Call Setup Performance

With default parameter settings:

Calls setups very successful

Call Performance.PPT / 16-09-2003 /Reunanen Jussi

Call Setup Performance

In order to optimise the call setup performance following changes

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

Call Performance.PPT / 16-09-2003 /Reunanen Jussi

Call Setup Performance

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

More time to select

Qhyst2 = -8dB + 4dB

Worst case scenario

Call Setup Performance

With optimised parameter settings:

Calls setups very successful

Calls setups difficult

It should be noted that the so called optimized settings for cell

Call Performance.PPT / 16-09-2003 /Reunanen Jussi

Call Setup Performance

BLER, Call drop rate, MOC CSSR, MTC CSSR

-Idle Mode Cell Reselection : Effect-

Call drop rate

MOC setup failure rate

MTC setup failure rate

Call Performance.PPT / 16-09-2003 /Reunanen Jussi

Call Setup Performance

All Call Attempts Test 1

CPICH Ec/No [dB]

From the charts on the left it can be seen

In this case the Sintraseacrh setting seems

All Call Attempts Test 2

CPICH Ec/No [dB]

Call Performance.PPT / 16-09-2003 /Reunanen Jussi

Call Setup Failures

Call Setup Performance

Nokia tested Common CH power sets and cell reselection

Tests were done with Sanyo UE (3.23)