You are on page 1of 67

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

1 (67)

TypeDateHere

3G Radio Optimisation Parameter Testing Guide

No. of Pages: 55

Checked by: 3G Radio Cop

Author: Pekka Ranta

Approved by:

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

2 (67)

TypeDateHere

Table of Contents
1. Call setup performance ................................................................................................................4 1.1 Idle Mode Performance..........................................................................................................4 1.1.1 Parameters .....................................................................................................................5 1.1.2 Testing Scenarios ...........................................................................................................6 1.1.3 Tools & Test Procedure ..................................................................................................7 1.1.4 Example Results.............................................................................................................7 1.1.5 Conclusions for this network ......................................................................................... 10 1.2 RRC Connection Establishment Performance...................................................................... 12 1.2.1 Parameters ................................................................................................................... 13 1.2.2 Testing Scenarios ......................................................................................................... 15 1.2.3 Tools & Test Procedure ............................................................................................... 16 1.2.4 Example Results........................................................................................................... 16 1.3 RAB Establishment Performance......................................................................................... 20 1.3.1 Parameters ................................................................................................................... 20 1.3.2 Testing Scenarios ......................................................................................................... 22 1.3.3 Tools & Test Procedure ................................................................................................ 22 1.3.4 Example results ............................................................................................................ 22 1.4 Call Setup Success Rate (CSSR) & Time ............................................................................ 23 1.4.1 Parameters ................................................................................................................... 23 1.4.2 Testing Scenarios ......................................................................................................... 24 1.4.3 Tools & Test Procedure ................................................................................................ 25 1.4.4 Example Results........................................................................................................... 25 2. SHO Performance...................................................................................................................... 30 2.1 Parameters .......................................................................................................................... 31 2.2 Tools & Test Procedures...................................................................................................... 33 2.3 Testing Scenarios/Example Results..................................................................................... 35 SHO Tuning: CPICH Ec/No Filter Coefficient ............................................................................. 35 SHO Tuning: Addition and Drop Time ........................................................................................ 36 SHO Tuning: Addition and Drop Windod .................................................................................... 36 SHO Tuning: Maximum Active Window Set Size........................................................................ 38 3. ps data performance .................................................................................................................. 40 3.1 Cell Throughput ................................................................................................................... 40 3.1.1 Parameters ................................................................................................................... 40 3.1.2 Testing Scenarios ......................................................................................................... 42 3.1.3 Tools & Test Procedure ................................................................................................ 43 3.1.4 Example Results........................................................................................................... 43 3.2 Dynamic Link Optimisation................................................................................................... 45 3.2.1 Parameters ................................................................................................................... 47 3.2.2 Testing Scenarios ......................................................................................................... 48 3.2.3 Tools & Test Procedure ................................................................................................ 48 3.2.4 Example Results........................................................................................................... 49 4. Inter-system handover................................................................................................................ 55 4.1 3G to GSM Handover .......................................................................................................... 55 4.1.1 Parameters ................................................................................................................... 55 4.1.2 Testing Scenarios ......................................................................................................... 56

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

3 (67)

TypeDateHere

4.1.3 Example results ............................................................................................................ 58 4.2 GSM to 3G handover ........................................................................................................... 59 4.2.1 Parameters ................................................................................................................... 60 4.2.2 Testing Scenarios ......................................................................................................... 61 4.3 3G to GSM cell Reselection ................................................................................................. 61 4.3.1 Parameters ................................................................................................................... 61 4.3.2 Testing Scenarios ......................................................................................................... 61 4.4 GSM to 3G Cell Reselection ................................................................................................ 63 4.4.1 Parameters ................................................................................................................... 63 4.4.2 Testing Scenarios ......................................................................................................... 65 4.5 Tools & Test Procedure ....................................................................................................... 67 5. References................................................................................................................................. 67

Scope
The scope of this document is to describe the parameters that could be tested in different 3G projects, how to do the tests and to analyse the results and what kind of values the tested parameters could have. There maybe parameters which dont need to be tested in every project due to the complexity or because the results of the parameter adjustment is not very high. This document gives explanations of new issues in RAN that are affecting to the end user performance. However, the scope of this document is not to give test cases for parameter testing and not to give new parameter values that can be followed in every project.

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

4 (67)

TypeDateHere

1. CALL SETUP PERFORMANCE


1.1 Idle Mode Performance
Both Intial cell selection to good enough cell and Cell reselection to better cell should happen to increase the call setup success rate (CSSR) and speed up the call setup time. This should be tested in different environment. Poor cell reselection can lead to poor call setup time distribution (as UE needs to send several RRC Connection Requests). The graphs below shows the difference in call set up performance due to poor cell reselection and corrected cell reselection. The graph is drawn of the CDF of percentage of calls vs. the call set up time for poor cell reselection case and improved cell reselection case. When the results are compared it could be seen that in for the first case percentage of calls with less call set up time is less than in the second case. Poor Cell Reselection: performance

Call Setup Delay (PDF & CDF)


100 90 80 70 60 50 40 30 20 10 0 0 0 to 3000 3000 to 5000 5000 to 8000 8000 to 10000 > 10000

PDF CDF

Setup Time [ms]

Corrected Reselection: performance


C all Setup Delay CDF

100.0% 80.0% 60.0% 40.0% 20.0%


3.5s - 3.7s 3.7s - 3.9s 3.9s - 4.1s 4.1s-4.3s 4.3s-4.5s 4.5s-4.7s 4.7s-4.9s 4.9s-5.1s 5.1s-5.3s 5.3s-5.5s

0.0%
<3.5s

Setup Time (seconds)

>5.5s

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

5 (67)

TypeDateHere

There can be cell reselection during RRC Connection Setup procedure. In case of cell reselection the call setup time from the end user side is increased by minimum of T300 (as the UE can only transmit new RRC Connection Request when the T300 has expired) 1. First RRC Connection request. 2. BTS of Cell A does not hear the request or UE does not hear the RRC Connection Setup message from BTS. 3. UE notices that Cell B is having better Ec/No and reselects to Cell B. 4. 2nd RRC Connection Request sent after T300 has expired in UE (T300 started in UE when 1st RRC Connection Request has been sent by the UE). The scenario above can also happen in such a way that there are several RRC Connection requests sent in phase 1 and in phase 4 due to poor coverage & poor cell reselection performance.

1.1.1 Parameters
There are parameters related to initial cell selection and cell reselection. They are explained briefly: Minimum required quality level in the cell (EcNo) (QqualMin) Minimum required RX level in the cell (RSCP) (QrxlevMin) Cell reselection triggering time (Treselection) With Treslection parameter of 0 s the cell reselection could take place immediately when the UE notices that there is difference between the cells Ec/No values. Cell reselection hysteresis 2 (Qhyst2) This will add some hysteresis to the neighboring cell evaluation (target for the cell reselection). Note that Qhyst1 is used only in case the cell selection and re-selection quality measure is set to CPICH RSCP (default is CPICH Ec/No so Qhyst 1 is not used in intra-FDD reselection). Cell Re-selection Quality Offset 2 (AdjsQoffset2) 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) This parameter is used by the UE to calculate the threshold (CPICH Ec/No) to start intra frequency (SHO) measurements (Sintrasearch above QqualMin value).

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

6 (67)

TypeDateHere

Default values for some of the parameters are below. Parameters Treselection Qhyst 2 AdjsQoffset2 Sintrasearch Qqualmin Qrxlevmin Default value 0s 4 dB 0 dB 4 dB -20 dB -115 dBm

The Qqualmin and Qrxlevmin parameters should be tuned carefully as the result could be that with certain values no calls can be made. In case the cell does not fulfill the suitable cell criteria i.e. S-criteria the UE cannot access the cell and therefore the UE is out of the coverage.

1.1.2 Testing Scenarios


Every single test should include minimum 50 call attempts. Test should be performed for different UE types and network type should be taken into account as well. In case there is underlying GSM 900/1800 network from the same operator (and ISHO is working) it might be beneficial to have other settings (and to have forced cell reselection to GSM) than those mentioned in this example (which is done in the single mode WCDMA network). Start the measurements at Ec/No ~ -8dB with Qqualmin = -20 dB, Sintrasearch = 12dB. Below is one example of different set of parameters to be tested: Parameter Sintrasearch Qhyst2 Treselection Default (param dictionary/optimal) 4dB/10dB 4dB/2dB 0s/2s Set1 14dB 0 1 Set2 12dB 2 0 Set3 14dB 2 0

This set should be tested in dirrerent areas like: Urban, rural, high speed train, highway area and possible with and without the border of two RNCs (including registration due to Location update) Slow moving conditions (walking speed) Average speed conditions (<50km/h) Fast speed conditions (~100km/h)

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

7 (67)

TypeDateHere

High speed trains if exist (~200km/h) Inter RNC and Intra RNC cases where applicable

1.1.3 Tools & Test Procedure


The tools for these tests are 1. Kenny with Nemo for AMR test 2. Scanner The procedure could be the following: 1. Start Scanner, Kenny (other Ues) with NEMO (other tools) 2. Make AMR short calls in given routes having 15s idle period and record and check result. 3. Record with Idle mode

1.1.4 Example Results


The following analysis has to be done for idle mode cell reselection: 1. Scanner Data analysis 2. Call setup success rate with the failure reason (e.g. reselection problem = UE hanging in wrong cell) 3. Call setup time Note! In all following test cases Sanyo 801 (qualcom chipset) UE (and in some cases Nokia 6650 UE) is used. It is suggested that different types of UEs are used. Parameter values are different from network to network due to NW plan and therefore all these parameters should be tuned in every network!

1.1.4.1 Scanner data analysis

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

8 (67)

TypeDateHere

Chart from scanner data shows best servers Ec/No value vs. percentage of samples where second best server is x dB lower than best server.

With common channel setting in this network: Base Ec/No (own cell) is around -4 dB so there only 1 cell at Ec/No > -4 dB. From the scanner data chart it is found that in the case where the cell reselection happens at about Ec/No 8dB, there is 95% possibility that second best server will have EcNo value more than 2dB lower than the best server. In other words, at EcNo 8 dB the neighboring cell having EcNo less than 2 dB from the serving cell is only 5 % and 95 % will have difference of EcNo from the serving cell more than 2 dB. This means that the cell reselection has 80% probability not to lead to ping-pong. If the reselection is done at about 16dB there is only 30% possibility that the second best server is more than 2dB lower than best server (this does not leave enough room for deviation between best and second best server).

1.1.4.2 Call setup Analysis


There are some example results related to call setup success rate vs. CPICH EcNo and CPICH RSCP values to find a suitable value for Qqualmin and Qrxlevmin. So we do the following analysis: 1. CSSR vs. CPICH EcNo and CPICH RSCP 2. BLER vs. CPICH EcNo and CPICH RSCP to see the quality of the call

In the following tests only Sanyo 801 UE is used and AMR calls are generated.

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

9 (67)

TypeDateHere

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

10 (67)

TypeDateHere

1.1.5 Conclusions for this network


Call setup is still success even RSCP<-112 dBm and/or Ec/No<-18 dB at about 70 % probability. The CPICH RSCP < 112dBm condition can happen especially in indoor situations and CPICH Ec/No < -18dB can happen in indoors or in occasionally in pilot pollution areas (especially when traffic increases) BLER is not so good in above situation but there is a possibility for handover to the other cells and to balance the BLER. As there is relationship between S criteria and Qqualmin, Qqualmin value setting and Sintrasearch in combined are affecting the cell reselection monitor point. For this network it is recommended to leave the Qqualmin and Qrxlevmin as 15dB and 115dBm respectively especially in WCDMA single mode networks. Minimum Required CPICH RSCP and Ec/No (From Sanyo UE drive test statistics) CSSR = 90% EcNo = -16 dB RSCP = -112 dBm

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

11 (67)

TypeDateHere

BLER < 1% Prob = 90% BLER <3% Prob= 90%

EcNo = -6 ~-7 dB EcNo = -14 dB

RSCP = -80 RSCP = -112 dBm

For Urban area (Urban 1 and 2) where the UE is slow moving with speed less than 50km/h, the cell reselection should be slower in case of inter RNC reselection -> for LA/RA borders it is recommended to have slower reselection (in this test case Qhyst2 = 2dB, Treselection = 3s). For intra RNC reselection case all the tested parameter sets work more or less the same but set 1 is recommended. For Rural area where the UE speed is somewhere between 50km/h and 100km/h the call setup performance is more or less the same for all the cases but in terms of CPICH distribution and number of cell reselections point of view the set 1 is recommended (set 1 clearly reduces the ping ponging in poor dominance environments) For high speed train from call setup performance point of view the set 1 performs clearly the best. Also from number of cell reselections and CPICH Ec/No distribution point of view set 1 is recommended. For high way case the set 1 performs the best from call setup success rate point of view and from number of reselections and CPICH Ec/No distribution point of view the set 1 is recommended. Set 1 is recommended for all types of area except at LAC boundary, slower cell reselection (default) should be used.

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

12 (67)

TypeDateHere

1.2 RRC Connection Establishment Performance


In RRC Connection Establishment Success rate, the emphasis should be on: RRC Setup performance and RRC Connection Access Success: in both cases the testing is concentrated on RRC Setup success rate, and number of sent RRC Connection Requests. The impact of minimal UE tx power (preample power) to the cell capacity Different UE performance (in the following test examples Nokia 6650 and Sanyo 801 UEs are used). Call setup delay

In open loop power control the Initial PRACH pre-amble power is defined by the UE according to

Ptx = C PIC Htransm issionPow er-RSC P(C PIC H) +RSSI(BS) + PRAC HRequiredReceivedC I
In case the BTS doesnt hear the preamble the UE resends the preamble with PowerRampStepPRACHpreamble higher power. In one PRACH cycle the power can be incremented PRACH_preamble_retrans times. If the PRACH cycle fails it will be repeated up-to RACH_tx_Max times. Potential CPICH RSCP measurement inaccuracies in the UEs are causing the pre-ample cycle(s) to fail with certain probability which is dependant on the radio conditions and the parameter settings in the network. It has been assumed that the measurement inaccuracies are more severe right after the UE wakes up from sleep in idle mode. In case PRACH procedure was initiated in order to set-up a RRC connection, the PRACH procedure, in case of failure, will be retried N300 times with an interval of T300. With N300 (3) and T300 (3s) parameters one may define how many times the UE is allowed to try to establish an RRC connection and whats the interval between the attempts. Too low values may cause RRC connection setup difficulties Too high values may bias the RRC statistics to look too bad. N300 * T300 should be reasonable (for example <=6s). Note: meaningful only in cases where RNC has received the RRC connection setup request message) Core network paging parameters may be considered as well so that its guaranteed that RRC connection setup attempt always ends before the last page is sent from CN (9 s).

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

13 (67)

TypeDateHere

1.2.1 Parameters
RRC Connection Setup performance can be improved by tuning mainly the open loop power control (OLPC) parameters. The parameters are listed below: N300, RRC CONNECTION REQUEST retransmission counter (MS counter). This parameter is part of System Information Block 1. T300, RRC CONNECTION REQUEST retransmission timer (MS timer). This parameter is part of System Information Block 1. PRACH Preamble Retrans Max (PRACH_preamble_retrans) The maximum number of preambles allowed in one preamble ramping cycle. PRACH Preamble Retrans Max is part of "PRACH power offset". RACH maximum number of preamble cycles (RACH_tx_Max) Maximum number of RACH preamble cycles defines how many times the PRACH pre-amble ramping procedure can be repeated before UE MAC reports a failure on RACH transmission to higher layers.
Power offset last preamble and PRACH message (PowerOffsetLastPreamblePRACHmessage )

The power offset between the last transmitted preamble and the control part of the PRACH message (added to the preamble power to receive the power of the message control part). Power ramp step on PRACH preamble (PowerRampStepPRACHpreamble) The power ramp step on PRACH preamble when no acquisition indicator (AI) is detected by the UE. Required received C/I on PRACH (PRACHRequiredReceivedCI) This UL required received C/I value is used by the UE to calculate the initial output power on PRACH according to the Open loop power control procedure. If this value is too low then the PRACH preamble ramping up takes too long time. If it is too high then it may cause blocking or high noise rise at BS since the UE measurement on RSCP has a poor accuracy. Maximum UE transmission power on PRACH (UETxPowerMaxPRACH) This parameter defines the maximum transmission power level a UE can use on PRACH. The value of the parameter also affects the cell selection and reselection procedures.

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

14 (67)

TypeDateHere

Parameters PRACH_preamble_retrans RACH_tx_Max PowerOffsetLastPreamblePRACHmessage PowerRampStepPRACHpreamble PRACHRequiredReceivedCI UETxPowerMaxPRACH

Default Value 8 8 2dB 2dB -25 dB 21

The RRC Connection Access success is highly depending on the used UEs so all the used UEs should be tested carefully before making any changes. The access phase can be affected by tuning the timer T312 and counter N312 (both in UE) as explained below: Longer the 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 synchronisation, the longer is call setup time. T312 The timer for supervising successful establishment of a physical channel (MS timer used in idle and connected mode). N312 This parameter defines the maximum number of "in sync" indications received from L1 during the establishment of a physical channel (UE counter used in idle and connected mode).

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

15 (67)

TypeDateHere

The recommended value for T312 is 6s minimum with which the RRC Connection Access success is highest and the call setup delay is minimised. N312 is recommended to be tested with the values of 4 and 2 at least to see the impact of call setup success and time (also certain UEs can work better with N312 = 2) All the above mentioned parameters can be tuned to improve the RRC Connection Setup performance. However, it should be noted that some of the UEs (especially the ones with qualcom chipset) have fixed values for some of those parameters (an example from Sanyo is given): PRACH_preamble_retrans & RACH_tx_Max = 8 & 8 PowerOffsetLastPreamblePRACHmessage = not fixed PowerRampStepPRACHpreamble = 3dB PRACHRequiredReceivedCI = not fixed

1.2.2 Testing Scenarios


Result evaluation should be based on drive test log analysis as well as counter analysis related to RRC setup success rate/CSSR. It should be noted that even though the emphasis is on the CSSR and call setup delay, the UE tx power should not be forgotten and it should be tested as well so that we use minimal UE tx power. The different set of parameters could be Parameter PRACHRequiredReceived CI Default -25 dB Set 1 -20 dB

The effect of parameter changes to UE tx power levels can be analysed based on drive testing logging e.g. the CPICH RSCP vs. Last (detected) preamble Tx power. Also CPICH Ec/No could be analysed but the UE does NOT use the CPICH Ec/No in the preamble power calculations and therefore it is not analysed. Different sets should be tested with several Ues, below scenarios for Sanyo 801 UE.

PRACHRequiredReceivedCI PowerOffsetLastPreamblePRACHmessage

Default Set -13 2

Set10 -21 5

Set11 -21 2

Set12 -18 2

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

16 (67)

TypeDateHere

1.2.3 Tools & Test Procedure


The tools for these tests are 1. Logging tool for voice, UDI and PS (1 service at one time), also Kenny with Nemo for voice test as reference 2. Scanner 3. RNC online monitoring to check the load (PrxTotal and PtxTotal) of the cells The test procedure could be the following: 1. Start Scanner, UE (Nokia, Sanyo etc) for Short voice and Kenny Short AMR @ moderate/good coverage 2. Make 50 AMR short call, record and check result. 3. Make 50 AMR short call, record and check result. 4. Make 50 UDI (TV) short call, record and check result. 5. Make 50 PS short call with 10 ping test each, record and check result. 6. Initiate 1 PS call (repeatedly with 3MB file and no PDP drop), Start UDI call one by one until call blocked. Check the reason (cell load) for the last failed call, change to AMR and continue until call block. Check the reason (cell load) 7. Move to cell edge, re test item 1-6 again 8. Chang parameters as to following set. Repeat step 1-6 again 9. Change parameter back to orignal value

1.2.4 Example Results

RRC _ Setup _ Comp _ Rate

RRC _ CONN _ STP _ CMP *100% RRC _ CONN _ STP _ ATT

RRC _ CONN _ ACC _ CMP *100% RRC _ CONN _ STP _ ATT If counters are used for RRC connection success they are (service level table) RRC _ Estab _ Comp _ Rate

Also there is counter calculating how many repeates there has been related to the same connection

RRC Conn Setup Att Repeats:

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

17 (67)

TypeDateHere

UE RRC Connection Request RRC Connection Setup RRC Connection Setup Complete

RNC

AVE _ RRC _ SETUP _ TM / 100s DENOM _ RRC _ SETUP _ TM


X Triggering Point

Also it is possible to look at cell reselection time

From the graphs below it is clear that there is improvement in number of RRC Connection Request messages needed per call. For 20dB case, 100% of established calls are setup with only 1 RRC Connection Request message while for 25 dB case 88% of established calls are setup with only 1 RRC Connection Request message.

PRACH req. C/I = -20dB 100% 80%


%

PRACH req. C/I = -25dB

100% 88%

60% 40% 20% 0% 1 2 3 4 # RRC Connection Request Messages per call setup 0% 2% 0% 5% 0% 6%

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

18 (67)

TypeDateHere

PRACH req. C/I = -25dB 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 1 2 3 4

PRACH req. C/I = -20dB

It is clear there is improvement in the number of sent preambles per RRC Connection Request for 20dB case. Here 50% of the calls needed less than or equal to 4 preambles where as for 25dB case the preambles requires are approximately 6.5.

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

19 (67)

TypeDateHere

PRACHRequiredReceivedCI: Call setup delay


100.0%

100% 99% 98% 97% 96% 95% 94% -25dB Call Setup Success Rate 96.2%

PRACH req. C/I = -25

PRACH req. C/I = -20

120.0% 100.0% 80.0% 60.0% 40.0%


-20dB

20.0% 0.0%
3.5s - 3.7s 3.7s - 3.9s 3.9s - 4.1s 4.1s-4.3s 4.3s-4.5s 4.5s-4.7s 4.7s-4.9s 4.9s-5.1s 5.1s-5.3s 5.3s-5.5s <3.5s >5.5s

Call Setup Delay (seconds) RRC Conn. Req. to Alerting

From the graph above it is seen that there is improvement in call setup delay for 20dB case. Nearly 65% of the established calls are through with only 3.5 3.7s delay and the more than 5.5s delay tail disappears (in this case).

Effect on used powers

CPICH RSCP vs Last preamble power


30 20 Default Set10 10 0 -10 -20 -30 -40 -50 -110 Set11 Set12 (Default) (Set10) (Set11) (Set12)

Last Preamble Power[dBm]

-100

-90

-80

-70 CPICH RSCP [dBm]

-60

-50

-40

-30

As it can be seen from the chart the power difference between set10, set11 and set12 is not so significant but clearly the current default set is having on average 5dB higher Tx power.

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

20 (67)

TypeDateHere

Recommendation is to use set 11 or set 12. Effect on different N312 During the test it was noted that setting N312 to 2 or 4 does not have any significant effect on the call set up success rate. But the effect on the call set up time is significant and therefore N312 value of 2 was selected to be used.

1.3 RAB Establishment Performance


During RAB establishment procedure Admission Control will calculate the maximum power what is possible to be used for that radiolink. It could help in some cases to increase the maximum DL DCH power in poor RSCP or EcNo conditions. This could help also certain UE types to have better RAB success.

1.3.1 Parameters
Related to RAB access there are some parameters which could be tested: Offset of the P-CPICH and reference service powers (CPICHtoRefRABOffset)

The parameter defines the offset of the primary CPICH transmission power, and the maximum DL transmission power of the reference service channel in DL power allocation. The maximum transmission power of the reference service is calculated (in dBm) by subtracting the value of the parameter from the transmission power of the primary CPICH.
Eb/No parameter set identifier (EbNoSetIdentifier)

This parameter defines the identifier of a particular parameter set of the planned Eb/No's. Parameter Default Value

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

21 (67)

TypeDateHere

CPICHtoRefRABOffset EbNoSetIdentifier

2 dB 1

CPICHtoRefRABOffset: has an impact to the max and min possible DL power levels:

DL tx pw r per C onnection [dBm] / BLER [%]

DL t x pw r per C onnect ion [ dBm] / BLER [%]

Max pow er Max pow er Min pow er Min pow er


t ime time

The max DL power is determined by AC as

Ptx ,max MIN ( RI max, eff Ptx , ref , N dpch Ptx _ DPCH _ max )

RI max,eff

RI max ref RI ref

Ptx ,ref

Ptx ,CPICH C pichTo Re fRabOffset

However it should be noted that the minimum power is increased as well (as the minimum power is Max power DL PC Range) which might lead to the situation where too high powers are allocated even in the good coverage conditions -> too much power is wasted. The power requirement per service is highly UE type dependent! EbNoSetIdentifier

Another parameter that could have some impact is the EbNoSetIdentifier. It indicates the used EbNo set (2-way diversity => 1, no diversity => 2 and 4-way diversity => 3). However it should be noted that DL Eb/Nos are the same for each case, therefore the EbNoSetIdentifier parameter has impact only on UL performance. In UL the set one has 3dB lower Eb/No than set 2 and set 3 has 1dB lower Eb/No that set 1. Therefore with Set 2 the UL initial power should be the highest .

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

22 (67)

TypeDateHere

In case there are a lot of UL AC rejections all the following parameters can have impact but only in case the interference is in spiky in nature.

1.3.2 Testing Scenarios


Different set of parameters having an impact to the RAB establishment could be as follows:

EbNoSetIdentifier CPICHRefRABoffset

Default 1 0

Set1 2 0

Set2 3 0

Set3 2 -3

Set4 2 3

These parameters should always be tested carefully against the different UE types (test results below are for Sanyo 801 UE and for AMR calls)

1.3.3 Tools & Test Procedure


The tools for these tests could be UE logging tool (Kenny with Nemo) for AMR test. The procedure could be: make 50 short voice calls with different sets in moderate/good coverage and check and count the failures Also PS calls could be tested.

1.3.4 Example results


The network counters to look at RAB success are results could be related to RAB setup fails, RAB access fails and RAB active fails. CPICHtoRefRABOffset and EbNoSetIdentifier It can be seen that the best result can be achieved with the lowest CPICHtoRefRABOffset value (which is expected result) however there seem to be hardly no (at least positive) impact on changing the EbNoSetIdentifier value.
default A B C D E F G H I J Call Setup Failure during RRC Connection Setup Phase (2.1) Call Setup Failure during Access Phase due to RACH/FACH (2.2) Call Setup Failure due to RRC Connection Reject (2.3) Call Setup Failure due to NO RRC Connection Setup Complete (2.9) Call SetUp Failure due to No Initial Direct Transter (2.8) Call Setup Failure during Security Procedure (2.5) Call Setup Failure during RAB Setup procedure(Without Complete) (2.6) Call Setup Failure during RAB Setup procedure(With Complete) (2.7) Call Setup Success Call Setup Failure due to Registration (2.4) Total Atempt Call Setup Success Call Setup Success Ratio 0 0 0 0 0 3 0 0 27 0 30 27 90.00% set1 0 0 1 0 0 5 2 0 22 0 30 22 73.33% set2 0 0 0 0 0 2 1 0 22 0 25 22 88.00% set3 0 0 0 0 0 1 0 0 29 0 30 29 96.67% set4 0 0 0 0 0 5 0 0 25 0 30 25 83.33%

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

23 (67)

TypeDateHere

1.4 Call Setup Success Rate (CSSR) & Time


CSSR depends on how well UE respond to the RB Reconfiguration or RB Setup. If UE does not have enough time to setup the lower layers for the new RB configuration then call setup will fail. This could be improved by increasing the Activation Time Offset parameter. Call setup time could be improved also with the change of SRB bit rate from 3.4kbps to 13.6kbps but it would decrease the available Iub capacity for the calls also. This is due to the reason that the SRB is not changed when reconfiguring to DCCH from CCCH. So both call setup delay and access performance should be considered and balanced.

1.4.1 Parameters
Call Setup time can be improved by changing parameter ActivationTimeOffset and/or changing the Signaling Radio Bearer (SRB) bit rate. Activation time offset in Nokia RAN is related to radio link setup (for CS data) and radio link reconfiguration (for PS call). ActivationTimeOffset part represent the processing delay of RNC and BTS. The SignalingDelayOffset is RNC internal parameter that implies a required offset based on e.g. the SRB bit rate, the actual procedure and the lenght of a RRC message. Connection Frame Number (CFN) is used in NBAP and RRC messages, when a radio link is reconfigured. It is used to indicate the activation time of the reconfiguration, and it is set by the PS. The CFN, which is set to the "activation time" field in L3 messages, is (the CFN provided by FP + (ActivationTimeOffset + SignalingDelayOffset)/10) mod 256. Difference between CFN of Activation Time and FP_CFN is increase depend on the increasing value of Activation Time offset. SignalingDelayOffset is a hard-coded table of values as function of SRB bit rate, procedure type and RAB type it was introduced in RAN1.5.2ED2 to optimise call setup delay. The delay is mapped as shown in next picture.

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

24 (67)

TypeDateHere

RB Procedures Service AMR CS PS 2*PS 3*PS AMR + 1*PS AMR + 2*PS AMR + 3*PS CS + 1*PS CS + 2*PS CS + 3*PS SRB 3,4 SRB 13,6 280 70 280 70 200 50 320 80 440 110 400 100 520 130 640 160 400 100 520 130 640 160 Transport channel procedures SRB 3,4 SRB 13,6 240 60 240 60 160 40 280 70 400 100 360 90 480 120 600 150 360 90 480 120 600 150

Service AMR CS PS 2*PS 3*PS AMR + 1*PS AMR + 2*PS AMR + 3*PS CS + 1*PS CS + 2*PS CS + 3*PS

Physical channel and measurement procedures Service SRB 3,4 SRB 13,6 All services 80 20

Note: In RAN04 the activation time offset is calculated in different way.

1.4.2 Testing Scenarios


Different Activation time offset parameters should be tested, also SRB bitrate will affect which value to use. Parameter ActivationTimeOffset Default Value 300 ms Set1 700 ms Set2 Set3

1000ms 1300ms

It should be noted however that ActivationTimeOffset change requires also that all the UEs can support the shorter times of sending the response to e.g. : Radio Bearer Setup Radio Bearer Reconfiguration

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

25 (67)

TypeDateHere

Physical Channel Reconfiguration, etc.

ActivationTimeOffset tests has to be done for several different UEs in on field conditions to see that all the UEs can respond within specified timers. Also the impact of cell reselection during the radio bearer setup should be verified. In case certain UEs are having problems in responding to RB Setup (CS) or RB Reconfiguration (PS) with complete, this can be seen as increase in PMI ticket : radio_connection_lost_c, timer_expired_c and counters: RAB_ACC_FAIL MS (RB Setup) and RRC_CONN_ACT_FAIL_RNC (RB setup).

1.4.3 Tools & Test Procedure


The tools for these tests are 1. Kenny (other Ues) with Nemo (other logging tools) for PS data test The procedure could be the following: 1. Make continious FTP download 2. 15 s Idle period 3. FTP transfer with 1 Mbyte file 4. Make steps 1-3 in SHO area also

1.4.4 Example Results


The results what to look here is related to call setup success rate and call setup time. Call setup success rate CSSR depend on the EcNo level. The figure below shows that with Ec/No <-12 the CSSR is less than 95%

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

26 (67)

TypeDateHere

Call SetUp Success Call SetUp Failure during access phase due to RACH/FACH Call SetUp Failure during security procedure Call SetUp Failure during RAB setup procedure(With Complete) Call SetUp Failure due to No RRC Connection SetUp Complete

Call SetUp Failure during RRC connection request phase Call SetUp Failure due to RRC connection reject Call SetUp Failure during RAB setup procedure(Without Complete) Call SetUp Failure due to No CM service erquest w ith RRC Connection SetUp Complete

100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%
-10>=x>-12 -12>=x>-14 -14>=x>-16 -16>=x>-18 -8>=x>-10 -4>=x>-6 -6>=x>-8 -18>=x x>-4

In example pictureas below 5UEs for SANYO701 and 5UEs for SANYO801 are used. Each UE has10 calls so a total of 50calls for each AMR 701 and 801. The difference of the call setup time between ActivationTimeOffset of 1500ms and 200ms is 1300ms, and between ActivationTimeOffset of 1500ms and 500ms is 1000ms

Call Setup Failure & Time: AMR

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

27 (67)

TypeDateHere

Call Setup Failure & Time: UDI

1 2 3 4 5 6 7 8 9 10 11 12

RRCConnectionRequest RRCConnectionSetup RRCConnectionSetupComplete MM CM Service Request MM Authentication Request MM Authentication Response SecurityModeCommand SecurityModeComplete CC SetUp CC Call Proceeding RadioBearerSetup RadioBearerSetupComplete

<=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=> <=>

RRCConnectionSetup RRCConnectionSetupComplete MM CM Service Request MM Authentication Request MM Authentication Response SecurityModeCommand SecurityModeComplete CC SetUp CC Call Proceeding RadioBearerSetup RadioBearerSetupComplete CC Alerting

Call setup delay with different SRBs

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

28 (67)

TypeDateHere

Change of SRB Bitrate


U E S R B(kbps) O ffset(m sec) 117(C O N N EC TAC KN O W LED G E) D ifference N E C v3.25 3.4k 200 3.766 -1.279 1500 5.045 -0.000 13.6k 200 1500 3.671 4.734 -1.374 -0.311 3.4k 200 3.434 -1.653 1500 5.087 -0.000 K en ny1389 13.6k 200 2.873 -2.214 1500 4.115 -0.972 200 3.780 -1.310 3.4k 1500 5.090 -0.000 S H A R P 13.6k 200 1500 2.959 4.220 -2.131 -0.870

100

TypeUnitOrDepartmentHere TypeYourNameHere

94 RRC Setup SuccessRate

95

96

97

98

99

Also the RRC Connection Access phase Success Rate should be evaluated when changing the SRB bit rate. For some UEs there might be improvement with higher SRB bit rate (in this case Sanyo / Sharp UEs are mainly use).

SRB 3.4kbps
RRC Access SuccessRate RRC Setup & Access SuccessRate

TypeDateHere

DOCUMENTTYPE

SRB 13.6kbps

15 /0 7 16 /20 /0 04 17 7/2 /0 004 18 7/20 /0 04 19 7/20 /0 04 7 20 /20 /0 04 21 7/2 /0 004 22 7/20 /0 04 23 7/20 /0 04 7 24 /20 /0 04 25 7/2 /0 004 26 7/20 /0 04 27 7/20 /0 04 28 7/20 /0 04 29 7/2 /0 004 30 7/20 /0 04 31 7/20 /0 04 01 7/20 /0 04 8 02 /20 /0 04 03 8/2 /0 004 04 8/20 /0 04 05 8/20 /0 04 8 06 /20 /0 04 07 8/2 /0 004 08 8/20 /0 04 09 8/20 /0 04 8 10 /20 /0 04 11 8/2 /0 004 12 8/20 /0 04 13 8/20 /0 04 14 8/20 /0 04 15 8/2 /0 004 16 8/20 /0 04 17 8/20 /0 04 8/ 20 04

29 (67)

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

30 (67)

TypeDateHere

2. SHO PERFORMANCE
The focus for soft handover tests mainly related to optimize SHO overhead, SHO success rate and average Active set size (and active set update period). Also call drop rate should be checked with different sets. It is not possible to optimize only SHO Over Head but also dropped call rates and SHO success rate (how many measurement reports are responded successfully) must be considered. Also change of SHO will have impact into Throughput Rate of bit rate modifications (how many upgrades and downgrades)

The SHO failures are mainly related to Initial Synchronization Failure of the new added RL Active Synchronization Failure of the existing RL(s)

Some typical SHO OverHeads are:


600 500 400 300 200 100 0

Soft handover overhead distribution on cell basis shown below Median value 49% on cell basis (no weighting with traffic) Average value 47% (with traffic weighting)

50

100

150

200

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

31 (67)

TypeDateHere

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 known restriction (parallel procedure not allowed) is not taken into account by the counters i.e. all the Measurement Report repetition counters for SHO are updated as failures.

2.1 Parameters
The parameters related to SHO performance are listed below. CPICH EcNo Filter Coefficient (EcNoFilterCoefficient) In the CELL_DCH state the UE physical layer measurement period for intra frequency CPICH Ec/No measurements is 200 ms. The Filter Coefficient parameter controls the higher layer filtering of physical layer CPICH Ec/No measurements before the event evaluation and measurement reporting is performed by the UE. Addition Window (AdditionWindow) Addition Window determines the relative threshold (A_Win) used by the UE to calculate the reporting range of event 1A. Addition Time (AdditionTime) When a monitored cell enters the reporting range (addition window), the cell must continuously stay within the reporting range for a given period of time before the UE can send a Measurement Report to the RNC in order to add the cell into the active set (event 1A). Drop Window (Drop Window) Drop Window determines the relative threshold (D_Win) which is used by the UE to calculate the reporting range of event 1B. Drop Time (DropTime) When an active set cell leaves the reporting range (drop window), the cell must continuously stay outside the reporting range for a given period of time before the UE can send a Measurement Report to the RNC in order to remove the cell from the active set (event 1B). Replacement Window (ReplacementWindow) When the number of cells in the active set has reached the maximum specified by the parameter MaxActiveSetSize and a monitored cell becomes better than an active set cell, the UE transmits a Measurement Report to the RNC in order to replace the active cell with the monitored cell (event 1C). Replacement Time (ReplacementTime)

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

32 (67)

TypeDateHere

When the number of cells in the active set has reached the maximum, and a monitored cell enters the reporting range (replacement window), the monitored cell must continuously stay within the reporting range for a given period of time before the UE can send a Measurement Report to the RNC in order to replace an active set cell with the monitored cell (event 1C). Maximum Active Set Size (MaxActiveSetSize) This parameter determines the maximum number of cells which can participate in a soft/softer handover. Active Set Weighting Coeeficient (ActiveSetWeightingCoefficient) Active Set Weighting Coefficient (W) 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 (cell addition) and 1B (dropping of cell).

Parameters CPICH Ec/No Filter Coefficient Addition Window Addition Time Drop Window Drop Time Replacement Window Replacement Time Maximum Active Set Size Active Set Weighting Coefficient

Default value 600 ms 2.5 dB 100ms


Comentario [SGy1]: 4 db

4 dB 640 2 dB 100 ms 3 0

The following parameters are not necessary to be tested: CPICH Ec/No Filtering Co-efficient Addition Time & Drop time Replacement time

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

33 (67)

TypeDateHere

2.2 Tools & Test Procedures


The tools for these tests are 1. Logging tool for voice, UDI and PS (1 service at one time), also Nokia UEs with Nemo tool 2. Scanner The test procedure could be the following (close to cell edge): 1. Start Scanner and logging UE (Nokia, Sanyo etc) for continious call in a given route 2. Make continious AMR call in a given route (60min), record and check result. 3. Make continious UDI call in a given route (60 min), record and check result. 4. Make continious PS call (60 min, 1 MB file size), record and check result. 5. Chang parameters as following set. Repeat steps 1-4 again 6. Change parameter back to orignal value

Different soft handover parameters will help syncronisation problems between radio links. When new radio link is added to the Active set the L1 synchronisation between the UE and the added BTS must be achieved. The UL/DL synchronisation procedures are needed to establish reliable new connection between BTS and UE. Some of the initial synchronisation failures are due to the fact that there can be difference in the UL noise rise levels of the adjacent cells. In case, a lot of initial synchronisation failures for SHO links are seen then one possibility is to try to reduce those by delaying the additions.

Norm al cell = UL & DL coverage are balanced

C ell having increased UL interference level = DL (C PIC H) coverage bigger than UL coverage

C ell A

C ell B

Based on the picture above the Cell B might not hear the UE at all when the SHO is initiated (based on DL Ec/No). This should be clarified from the PrxTotal measurements and counters.

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

34 (67)

TypeDateHere

Active synchronisation failures can be caused by all the restrictions there is to execute the SHO algorithm (i.e. to add new cell or do replacement) and therefore the SHO is delayed and the UE is hanging in poor cell. -Parallel processes (e.g. RB Reconfiguration on going) -Previous SHO procedure not completed (e.g. ASU complete message not received) Or then just the AS modification is initiated too late and the signal from the existing connection degrades very rapidly causing RL failure before AS modification can be initiated. In case there are a lot of Active Synchronisation Failures detected, one action could be to advance the SHO activity e.g. using cell individual offsets or in general use different FMCS (usually these conditions are improved when addition is done earlier e.g. add 4dB and drop 6dB).

There are some cases that drops happened because H/O timing was delayed(Actually it is difficult to judge as there are many cases that drops happened with no respond of Measurement Report regardless of the level). It is possible that such case happens at some places like shadow of building, tunnel, and gate way of elevated road where dominant can be changed suddenly.

When UE sends Report, it does not have enough level to receive ActiveSet Update Msg. T herefore, there are possibilities that call drop happened because of H/O failure.

It can be avoided by setting earlier timing (timing for sending out Measurement report )of H/O between targeted cells.
Use FMC parameter Use ADJSE cNooffset

Impact all of FMC targeted areas

Impact only between 2 targeted cells

For the above case, it is desirable to change the timing by applying ADJSEc/Nooffset

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

35 (67)

TypeDateHere

2.3 Testing Scenarios/Example Results


Below is one example sets related to CPICH EcNo filter co-efficient and replacement time to be tested in the field. Based on this example the suggestion for the optium set is below (based on call drop rate)

FMCS HOPS Parameter CPICH Ec/No filter co-efficient Addition Window Addition Time Drop Window Drop Time Replacement Window Replacement Time

Area1 RNC X & Y Apr, JP Default Proposal1 Proposal2 Default *1 NewSet 1 &9 Additional 2 2 2 3 3 0 (400msec) (400msec) (400msec) (600msec) (600ms) 2 2.5 3 2 2 2 320 160msec 320 320 320 320 6 dB 4 dB 6 dB 6 6 6 640 640ms 640ms 640 640 640 2 dB 2 dB 2 dB 2 2 2 320 160ms 320ms 320 100 160

Cluster New Set 3 (600ms) 2 320 6 640 2 100

Suggestion New Set 3 (600ms) 2 320 6 640 2 320

SHO Tuning: CPICH Ec/No Filter Coefficient


Parameters Additi on Window (dB) Additi on Time (ms) Drop Window (dB) Drop Time (ms) Replacement Window (dB) Replace T ime (ms) Maximum Act ive S et S ize CP ICH E c/No f ilter Coeff icient Active S et Weighting Coef ficient Value 2.5 100 4 640 2 100 3 0, 1, 2, 3, 4, 5, 6 0

3 (600ms), default 4 (800ms) 5 (1100ms) 6 (1600ms)

By comparing the results of different parameter sets, the default value 3 should be the optimal one--highest SHO gain, good KPIs and proper SHO overhead.

0 (200ms) 2 (400ms) 3 (600ms), default

By comparing the results of different parameter sets, the default value 3 should be the optimal one--highest SHO gain, good KPIs and proper SHO overhead.

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

36 (67)

TypeDateHere

SHO Tuning: Addition and Drop Time

SHO Tuning: Addition and Drop Windod

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

37 (67)

TypeDateHere

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

38 (67)

TypeDateHere

SHO Tuning: Maximum Active Window Set Size

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

39 (67)

TypeDateHere

SHO Tuning: Active set Weighting coefficient The active set weighting coefficient has been noted to improve the DCR as well as the DL BLER for certain UEs This is most likely due to that some UEs have problems in proessing power and in case of 3 Radio Links in Active Set the processing power runs out and the UE performance in terms of BLER and DCR can be degraded

Active Set Weight Coefficient

Default Set 0
Sanyo
Kenny
1 206 170 21 0.5 180 176 17 0 168 147 74 ALL 1a 1b 1c

Set1 1

Set2 0.5

Num of Measurement report msg for each event


AMR
ALL 1a 1b 1c 1 250 219 18 0.5 204 186 43 0 152 144 29

UDI
ALL 1a 1b 1c

1 260 237 26

0.5 195 186 52

0 168 147 74

Average value (Dominant Ec/No, Combined Ec/No, BLER, ActiveSet Num cell)
AMR
ALL Dominant E c/Io (dB) Combined E c/Io (dB) BLER Active Set Num Cell 1 -7.68 -5.79 0.38 1.25 0.5 -7.68 -5.71 0.61 1.31 0 - 7.63 - 5.81 0.65 1.36

UDI
ALL Dominant Ec/Io (dB) Combined Ec/Io (dB) BLE R Active Set Num Cell 1 -7.06 -6.68 0.81 1.19 0.5 - 6.72 - 6.18 0.64 1.28 0 - 7.07 - 6.54 1.73 1.30

Num of Drop
AMR
ALL Drop 1 2 0.5 2 0 3

UDI
ALL 1 1 0.5 3 0 7

Kenny
ALL 1 0 0.5 0 0 0

Ec/No [dB]
Add threshold W=0.5 : -3.4dB Add threshold W=0 : -4dB [ActiveSet: SC 1 and SC 3] W=0: SHO w indow : Add Drop = 4dB W=0.5: SHO w indow : Add Drop = 3.15dB

SHO activity (Add Remove) should increase (i.e. measurement reports(Add Remove))

Average Active Set Size should decrease SHO overhead should decrease Active Set Size=3 should decrease Replacement amount should decrease

drop threshold W=0.5 : -6.55dB

drop threshold W=0 : -8dB [ActiveSet: SC 1, SC 2 and SC 3]

SC1:- 2dB, SC2:- 4dB, SC3:- 7dB)

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

40 (67)

TypeDateHere

3. PS DATA PERFORMANCE
The focus for PS data tests is to optimize PS call drop rate and maximize the throughtput. The performance depends on the usage of certain bitrate and different RRC states of the connection. The performance/throughtput could be optimized with diffrent traffic activity/inactivity and traffic volume parameters. The optimum set of parameters depends on the used application (FTP, MSS, email) and amount of data. Thus different sets could be used for different application. Below are described different RRC states & parameters.

Available in RAN04 the future

UTRA RRC Connected Mode


URA_PCH CELL_PCH
DRX
cellUpdate, UL Tx UL_DL_activation_timer

# cellUpdat es UL Tx

DRX

CELL_DCH
Tx/Rx
inactivityTimer

CELL_FACH
Tx/Rx FACH/RACH
t rafficVolum e

Release RRC Connection

Release RRC Connection Establish RRC Connection (UE camps on UTRAN cell)

Idle Mode
3.1 Cell Throughput
3.1.1 Parameters
Parameters related to the usage of the different RRC states are described below Downlink Traffic Volume measurement high threshold (TrafVolThresholdDLHigh) This parameter defines the threshold of data in the RLC buffer of RB in bytes which triggers downlink traffic volume measurement report (capacity request) on MAC, when UE is in a Cell_DCH state and the initial bit rate DCH is allocated for the radio bearer
Uplink Traffic Volume measurement low threshold (TrafVolThresholdULLow)

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

41 (67)

TypeDateHere

This parameter defines, in bytes, the threshold of data in the RLC buffers of SRB0, SRB1, SRB2, SRB3, SRB4 and all NRT RBs that triggers the uplink traffic volume measurement report, when the UE is in Cell_FACH state. Uplink traffic volume measurement time to trigger (TrafVolTimeToTriggerUL) This parameter defines, in ms, the period of time between the timing of event detection and the timing of sending a traffic volume measurement report. Uplink traffic volume measurement pending time after trigger (TrafVolPendingTimeUL) This parameter indicates the period of time, in seconds, during which it is forbidden to send any new traffic volume measurement reports with the same measurement ID, even if the triggering condition is fulfilled again. UL/DL Activation Timer This timer is used on MAC -c to detect idle periods on data transmission (NRT RBs and SRBs) for the UE, which is in Cell_FACH state. Based on this timer the MAC -c shall give the No_Data indication to the RRC, which further can change the state of the RRC from Cell_FACH state to the Cell_PCH state (or URA_PCH state). InactivityTimerDownlinkDCHxxx (xxx= 8, 16,32,64,128,256,384 kbits/s) The time indicating how long the radio and transmission resources are reserved after silence detection on downlink DCH before release procedures. The Cell_PCH to Idle mode state transitions can be controlled by two parameters: MSActivitySupervision timer And periodical cell update timer T305

Parameters TrafVolThresholdULLow TrafVolThresholdDLhigh TrafVolTimeToTriggerUL TrafVolPendingTimeUL UL/DL Activity timer InactivityTimerDownlinkDCH

Default Value 128 bytes 1024 bytes 0 ms 2000ms 20s 2s-5s

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

42 (67)

TypeDateHere

It is recommended to test UL/DL activation timer: This timer is set when the MS is transferred to CELL_FACH state due to inactivity, or MS inactivity is detected in CELL_FACH state. Default value: 20s

Also it is recommended to test different InactivityTimerDownlinkDCH values. If there is lot of PS traffic then smaller (2s-3s) timer for this parameter will save DCH capacity. MSActivitySupervision timer is used in RRC states CELL_PCH (and URA_PCH) for supervising the inactivity of NRT RAB(s). Timer is started when a state transition to either of these states is executed. MSActivitySupervision timer is stopped when any activity of NRT RAB(s) is detected and the UE is moved to CELL_FACH or CELL_DCH state. Timer is restarted (from the initial value) when the inactivity of NRT RAB(s) detected again and the UE is moved back to the CELL_PCH or URA_PCH again. In expiry of the MSActivitySupervision timer when the first "inactive state indication" (i.e. Cell/URA Update, which does not cause the (re)initiation of the signaling or data flow) is received from the MS, the RNC asks SGSN to release the Iu connection. Note: If the parameter value is set to zero: state transition to Cell_PCH/URA_PCH is not allowed when inactivity is detected in Cell_FACH state, the UE will be switched to the Idle Mode when the DCH specific inactivity timers (InactivityTimerUplinkDCH and InactivityTimerDownlinkDCH) is/are set to value DCH inactivity supervision not used, the UE will be switched to the Idle Mode within 5 minutes (an internal fixedvalue timer in RRC entity) when inactivity is detected in Cell_DCH state

3.1.2 Testing Scenarios


As already said above the different inactivity timers (InactivityTimerDownlinkDCH, range 25s) could be tested to see how much they affect to RRC/RAB failure due to increased/decreased DCH holding time. These KPIs could be taken from network statistics. One interesting test is related to Downlink Traffic Volume measurement high threshold parameter. From the FTP Download result of test, it is said that big volume data downloading such as FTP can complete faster when upgraded to 384kbps(in case of15000- 20000 byte and higher). This kind of necessary upgrade to 384kbps still works even after the parameter change to 3072 byte.
Parameter TrafVolThresholdDLHigh Default 1024 bytes Set1 2048 bytes Set2 3072 bytes Set3 4096 bytes

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

43 (67)

TypeDateHere

3.1.3 Tools & Test Procedure


The tools needed in these tests are: 1. Ue logging tool (Kenny with Nemo) 2. Nethawk/ISCU logging tool The test procedure could be like (Use different routes with/without SHO and in weak coverage area) 1. Make PS call for different data volumes(5 kB, 10kB, 100kB, 500 kB, 1MB) downloading from FTP server. Test could be also done for MMS with smaller data volumes (1 kB, 2kB, 3kB, 10 kB) 2. At the same, take the Nethawk/ISCU log 3. Stop the logging if UE go to CelL-FACH or Idle or leave the cell (SHO) 4. Change back parameter after testing

3.1.4 Example Results


Below are some results from different DL traffic volume threshold parameter (TrafVolThresholdDLhigh). From the results can be seen the total time spend in downloading the data and the how much there have been readio beared reconfigurations. Page tests (small data up to 10 kB):

Num of us ed bearer status for each parameter set

Bearer Status: the transition of the Bearer and state to show the page form the Idle state to completion

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

44 (67)

TypeDateHere

Average download time with certain inactivity timers for all pages:

Average of the B- Time and W- Time for each beare status (unit: second)

B- Time: From the first radio bearer reconfiguration(initial 64k) to download activation completion
[Time of radio bearer reconfiguration(for cell- FACH) after download completion] - [Time of First radio bearer reconfiguration(for initial)] - InactivityTimerDownlinkDCH(384k- >2s, 128k- >2s, 64k- >3s)

W- Time: From the starting to show the page(push the button) in the Idle state to completion to show the page(Progress bar completion)

MMS and FTP results (bigger amount of data:


Bearer status and Download time (Long Mail)

B- Time: From the first radio bearer reconfiguration(initial 64k) to download activation completion
[Time of DEACTIVATE PDP CONTEXT REQUEST] - [Time of First radio bearer reconfiguration(for initial)]

W- Time: From the starting to show the page(push the button) in the Idle state to completion to s how the page(Progres s bar completion)
Bearer status and Download time (FTP)

In MMS tes t, all cases completed downloading faster with 64k (without upgrading to 384k) as far as the Mail Volume(Max.12kB) we have tested this time is concerned. In FTP test, File Downloading for 10kB or bigger file upgraded to 384k in all cas es.

OSS statistics : Radio bearer holding time and the total sum of Bitrate usage (64,128 and 384 kbits/s)

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

45 (67)

TypeDateHere

120000000

TrafVolDLThreHigh =

1024kB

3072kB

100.00% 90.00%

TrafVolDLThreHigh =

1024kB

3072kB

100000000

80.00% 70.00%

80000000

60.00%
60000000

50.00% 40.00%

40000000

30.00% 20.00%

20000000

10.00%
0
04/12/1 04/12/2 04/12/3 04/12/4 04/12/5 04/12/6 04/12/7 04/12/8 04/12/9 04/12/10 04/12/11 04/12/12 04/12/13 04/12/14 04/12/15 04/12/16 04/12/17 04/12/18 04/12/19 04/12/20 04/12/21 04/12/22 04/12/23 04/12/24 04/12/25 04/12/26 04/12/27 04/12/28 04/12/29 04/12/30 04/12/31 05/1/1 05/1/2 05/1/3 05/1/4 05/1/5 05/1/6 05/1/7 05/1/8 05/1/9 05/1/10 05/1/11 05/1/12 05/1/13 05/1/14 05/1/15 05/1/16 05/1/17 05/1/18 05/1/19 05/1/20 05/1/21 05/1/22 05/1/23 05/1/24 05/1/25 05/1/26 05/1/27 05/1/28 05/1/29 05/1/30 05/1/31

0.00%
04/12/1 04/12/2 04/12/3 04/12/4 04/12/5 04/12/6 04/12/7 04/12/8 04/12/9 04/12/10 04/12/11 04/12/12 04/12/13 04/12/14 04/12/15 04/12/16 04/12/17 04/12/18 04/12/19 04/12/20 04/12/21 04/12/22 04/12/23 04/12/24 04/12/25 04/12/26 04/12/27 04/12/28 04/12/29 04/12/30 04/12/31 05/1/1 05/1/2 05/1/3 05/1/4 05/1/5 05/1/6 05/1/7 05/1/8 05/1/9 05/1/10 05/1/11 05/1/12 05/1/13 05/1/14 05/1/15 05/1/16 05/1/17 05/1/18 05/1/19 05/1/20 05/1/21 05/1/22 05/1/23 05/1/24 05/1/25 05/1/26 05/1/27 05/1/28 05/1/29 05/1/30 05/1/31

DUR_PS_BACKG_64_DL_IN_SRNC DUR_PS_BACKG_384_DL_IN_SRNC
140000000

DUR_PS_BACKG_128_DL_IN_SRNC

Ratio_DUR_PS_BACKG_64_DL_IN_SRNC Ratio_DUR_PS_BACKG_384_DL_IN_SRNC

Ratio_DUR_PS_BACKG_128_DL_IN_SRNC

TrafVolDLThreHigh =
Sum of DUR_PS_BACKG

1024kB

3072kB

120000000

100000000

80000000

Each Duration(Bearer holding time)[left top graph ] and the total sum (64k 128k 384k)[left bottom graph] had almost tripled from End of Dec, 2004 until the mid- Jan. of 2005. The ratio of each Bearer from total sum [right top graph] remains almost in the same level as below: 64k about 69% 128k about 2% 384k 29% Due to TrafVolThresholdDLHigh change done on Jan 21, the ratio changed to: 64k about 84% 128k about 0.6% 384k 15% 384k ratio reduced almost by half. Since Users for small volume data such as Vodafone Live! & MMS completed downloading without upgrading to 384kbps, the ratio seems to be reduced. This means unnecessary upgrading to 384kbps is eliminated and efficient use of capacity achieved.

60000000

40000000

20000000

0
04/12/1 04/12/2 04/12/3 04/12/4 04/12/5 04/12/6 04/12/7 04/12/8 04/12/9 04/12/10 04/12/11 04/12/12 04/12/13 04/12/14 04/12/15 04/12/16 04/12/17 04/12/18 04/12/19 04/12/20 04/12/21 04/12/22 04/12/23 04/12/24 04/12/25 04/12/26 04/12/27 04/12/28 04/12/29 04/12/30 04/12/31 05/1/1 05/1/2 05/1/3 05/1/4 05/1/5 05/1/6 05/1/7 05/1/8 05/1/9 05/1/10 05/1/11 05/1/12 05/1/13 05/1/14 05/1/15 05/1/16 05/1/17 05/1/18 05/1/19 05/1/20 05/1/21 05/1/22 05/1/23 05/1/24 05/1/25 05/1/26 05/1/27 05/1/28 05/1/29 05/1/30 05/1/31

3.2 Dynamic Link Optimisation


With Dynamic Link Optimisation feature the bitrate performance could be optimized by comparing throughput, the usage of DL PtxDPCH power and CPICH EcNo values with each other. Coverage expectation could be verified with link budget calculations. Thus the required Ec/No and Path loss may be needed for each area. (Characteristic is decided by speed, bitrate, and load) -> Cell Range Below are some examples of cell ranges

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

46 (67)

TypeDateHere

The cell range is the result of Link budget calculation tables below with the worst services (e.g. CS64). This same link budget table is used in estimating trigger point for downgrade.

As shown in link budget, the services coverage is controlled by various parameters. Those parameters in RAN parameter are Total WPA power (20 W or 8W) Max Power per connection is selected by the minimum of these criteria PtxDPCHMax (WBTS) = -3dB(meaning WPA 3 dB= 40 dBm or 36 dBm) CPICHRefRABOffset PtxDLAbsMAX (NRT only)

Pmax: UE power = 21dBm, 24 dBm

With the mentioned parameter, one could use to allow pathloss to consider the possible threshold to be used. For example, Metro 8W WPA: Total WPA power = 8W Max Power per connection is selected by one of these criteria PtxDPCHMax (WBTS) = -3 dB (meaning 36 dBm)

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

47 (67)

TypeDateHere

From CPICHRefRABOffset calculation, Max Ptx = 40.18 dBm PtxDLAbsMAX (NRT only) = to be tested

Therefore, the max power per connection is min(36dBm,PtxDLAbsMax) and this will be the bottleneck for PS384 coverage as UE power is not limitation. (referred to below result) As a result, the parameter test set for PtxDLAbsMax will be 36 dBm or lower.

3.2.1 Parameters
The parameters having impact on the PS data performance are described below. Planned maximum downlink transmission power of a radio link (PtxDLabsMax) The planned maximum downlink transmission power of radio link. This parameter is used in the downlink power allocation when CCTrCH includes one or more DCH's of interactive or background traffic class RAB's. Initial and Minimum Allowed Bit RateDL (MinAllowedBitRateDL) This parameter defines the minimum allowed bit rate in downlink that can be allocated by the PS.
Maximum downlink bit rate for PS domain NRT data (MaxBitRateDLPSNRT)

This parameter defines the maximum downlink user bit rate allowed in a cell for an NRT PS domain RAB.

Parameters PtxDlabsmax
MinAllowedBitRateDL MaxBitRateDLPSNRT

Default Value 50 dBm 64 kbps 384 kbps

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

48 (67)

TypeDateHere

3.2.2 Testing Scenarios


Target for tests are to take sample to make statistic for CPICH value, BitRate, Throughput and PtxDPCH and specially verify the relationship of those to link power PtxDPCH. Also BitRate performace (throughput per bitrate) could be verified Below are some testing scenarios to be tested.

Ref PS_01 PS_02 PS_03 PS_04

Name FIX RATE TEST FOR URBAN AREA (CELL EDGE) FIX RATE TEST FOR RURAL AREA (COVERAGE EDGE) FIX RATE TEST with Load (LOAD CONDITION) MOVING TEST FOR URBAN AREA MOVING TEST FOR RURAL AREA

Priority P1 P1 P1 P1

Parameter MaxBitRateDLPSNRT MinAllowedBitRateDL MaxBitRateDLPSNRT MinAllowedBitRateDL MaxBitRateDLPSNRT MinAllowedBitRateDL PtxDLabsMax Ptx_DPCH_max Max/Min =

Values

Test* M M M A

Time 1day 1day 1day

384/384, 128/128, 64/64 Max/Min = 384/384, 128/128, 64/64 Max/Min = 384/384, 128/128, 64/64 Parameter set is decided according to the result of P1-3 Parameter set is decided according to the result of P1-3 TOTAL (days) 3days

PS_05

P1

PtxDLabsMax Ptx_DPCH_max

3days 9

The load case could be generated with second UE having UDI call. Other set could be as following:

Ptx DLabsMax Initia lAndMinimumAllow edBitrateDL Ma xBitRateDLPSNRT


3.2.3 Tools & Test Procedure
The tools needed in these tests are: 3. Ue logging tool (Kenny with Nemo) 4. Scanner 5. Nethawk/ISCU logging tool

Default 43 384kbps 384kbps

Set1 43 64kbps 384kbps

Set2 38 or 36 64kbps 384kbps

There will be different test procedures for fixed bitrate / moving test. For fixed bitrate the procedure could be like 5. Make PS call for 2M downloading from FTP server.

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

49 (67)

TypeDateHere

6. Call is not released after comlpeted the 2M downloading and download again 7. At the same, take the Nethawk/ISCU log. 8. Stop the logging if UE go to CelL-FACH or Idle or leave the cell (SHO) 9. Performed the test for different BTS type (Supreme, Metrosite) 10. Change back parameter after testing For bitrate change (different max and min bitrate in the cell) the procedure could be 1. Make PS call for 1M downloading from FTP server. 2. Call is released after completed the 1M downloading and setup again 3. At the same, take the Nethawk/ICSU log. 4. Change back parameter after testing

3.2.4 Example Results


The results will be related to the PtxDCH vs CPICH RSCP (for each BitRate) PtxDCH vs CPICH Ec/No (for each BitRate) Time vs PtxDCH, RSCP, Ec/No, BitRate CPICH Ec/No vs Ratio of each RAB(Bit Rate) CPICH RSCP vs Ratio of each RAB(Bit Rate) CPICH EbNo/RSCP vs. BLER Path loss vs Ratio of each RAB(Bit Rate) CPICH Ec/No vs Path Loss Failure Analysis (in case) [OSS, ICSU(if necessary)] Time spend on the certain bitrate Upgrade/Downgrade times

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

50 (67)

TypeDateHere

CPICH Ec/No vs Ratio of each RAB(Bit Rate), CPICH RSCP vs Ratio of each RAB(Bit Rate) How many % assigned the each BitRate for the each step of the Ec/No or RSCP To make the statistics by the moving test data

RB Status Statistics(vs EcNo)

100% 90% 80%

0.00% 10.67% 11.73% 13.26% 25.81% 32.37% 50.94%

70% 60% 50% 40% 30% 20% 10% 0% > -4 100.00%

38.30% 47.55% 56.40% 76.04% 88.37% 57.16% 56.09% 37.74% 51.03% 40.72% 30.34% 17.03% 11.54% -12 to -14 11.32% -14 to -16 18.75% 4.65% 5.21% -16 to -18 6.98% < -18 sf 32 sf 16 sf 8

-4 to -6

-6 to -8

-8 to -10

-10 to -12 Ec/No [dB]

RB status for each EbNo


RB Status Statistics(vs EcNo) 120.00%

384

128

64

100.00%

80.00%

60.00%

sf 8 sf 16 sf 32

40.00%

20.00%

0.00% > -4

-4 to -6

-7-8
-6 to -8

-8 to -10

-10 to -12 Ec/No [dB]

-12 to -14

-14-14 to -16

-16 to -18

< -18

CPICH RSCP vs BLER, CPICH Ec/No vs BLER (for Each BitRate) How many % of the each step of the BLER for the each step of the Ec/No or RSCP To make the statistics by the moving test data

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

51 (67)

TypeDateHere

Ec/No vs BLER

100% 90% 80% 70%


10<
Ratio of BLER

60% 50% 40% 30% 20% 10% 0% -2 -4 -6 -8 -10 -12


Ec/No

10 5 3 1 0

-14

-16

-18

-20

-22

Distribution graph between Ec/No and Path Loss (RNCP) To make the statistics by the moving test data

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

52 (67)

TypeDateHere

Time vs PtxDCH, RSCP, Ec/No, BitRate Time base graph for PtxDCH, RSCP, Ec/No, BitRate and Throughput To make the graph by 1 cell base data.
448000 384000 320000
BitRate[bps]

40 35 30 25
PtxDCH [dBm]
Ec/No [dB]

256000 20 192000 15 128000 64000 0


55:46.3 56:01.8 56:17.5 56:33.1 56:48.8 57:04.5 57:20.1 57:35.8 57:51.5 58:07.2 58:22.8 58:38.5 58:54.2 59:09.9 59:25.6 59:41.3 59:56.9 00:12.6 00:28.3 00:44.0 00:59.6 01:15.3 01:30.9 01:46.6 02:02.3 02:18.0 02:33.7 02:49.4 03:05.0 03:20.7 03:36.4 03:52.1 04:07.7 04:23.4 04:39.1 04:54.7

10 5 0 DL Bitrate current2 Ptx_ave_dBm


05:10.4
0 -5 -10 -15 -20 -25

-60 -70 -80


RSCP [dBm]

-90 -100 -110 -120 -130

CPICH Dominant RSCP (dBm)

CPICH Dominant Ec/No (dB)

+ Throughput

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

53 (67)

TypeDateHere

PtxDCH vs CPICH RSCP, PtxDCH vs CPICH Ec/No (for each BitRate) How many % of the each step of the DCh Power for the each step of the Ec/No or RSCP To make the graph by 1 cell base data.

PtxDCH vs CPICH RSCP ~38 ~36 ~34 90% ~32 80% ~30 70% ~28 60%
[%]

100%

50% 40% 30% 20% 10% 0% -4 -6 -8 -10 -12 -14 -16 -18 -20

Ec/No or RSCP
Ec/No

Times on different bearers spreading factors


sf8 sf16 sf32 FACH Idle Default Se t1 Set2 36:45.873 24:27.095 16:37.340 00:00.000 12:30.764 24:27.813 02:07.373 08:43.990 08:46.952 14:37.097 09:26.672 10:19.881 00:37.344 00:21.919 00:10.115

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

54 (67)

TypeDateHere

Upgrade, Downgrade times


Default
=>sf8 sf8 sf16 sf32 FACH =>sf16 =>sf32 =>FACH =>Idle 129 3 122 5 5

Set1
=>sf8 sf8 sf16 sf32 FACH =>sf16 8 68 34 1 =>sf32 =>FACH =>Idle 59 4 36 11 101

Set2
=>sf8 sf8 sf16 sf32 FACH =>sf16 17 67 39 6 =>sf32 =>FACH =>Idle 46 1 51 11 98

400000 350000 300000 250000 200000 150000 100000 50000 0


15 :42 :0 4, 15 0 :42 68 :4 15 3,65 :43 2 :1 7 ,0 15 :43 64 :5 15 0,56 :44 9 :2 3 ,8 15 26 :4 4: 57 ,0 15 66 :4 5: 30 ,5 15 66 :4 6: 03 ,9 15 90 :4 6: 38 ,0 63

45 40 35 30 25 20 15 10 5 0 Throughput bps/W BTS Tx Power

DLO_conclusions.ppt

Dylo conclusions:

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

55 (67)

TypeDateHere

4. INTER-SYSTEM HANDOVER
4.1 3G to GSM Handover
Here optimization parameters are mainly related to ISHO thresholds, filtering time (how long time certain level (RSCP, or EcNo) is averaged before UE is seding the report to the RNC) and decision making. Triggers for RT and NRT services could be set differently. Each triggering procedure makes use of filters, hysteresis and thresholds which are used to control the inter-system handover behaviour. The purpose of the hysteresis and filters is to improve the accuracy of the measurements. The purpose of the thresholds is to control 3G boundary of the different services. Below is picture about these parameters.
1. Handover Triggering
CPIC H RSCP (Event 1F) Thresholds: HHoRscpThreshold HHoRscpC ancel L3 filter: HHoRscpFilterC oefficient Timers: HHoRscpTim eHysteresis HHoRscpC ancelTim e UE Tx Pow er (Event 6A) Threshold: GsmUETxPw rThrXX L3 filter: GsmUETxPw rFilterC oeff Hysteresis margin: GsmUETxPw rTim eHyst Data rate threshold HHOMAxAllow edBitrateUL (XX=AMR,C S,NrtPS,RtPS) DL DPCH pow er Threshold: G smDLTxPw rThrXX Data rate threshold HHOMAxAllow edBitrateDL CPIC H Ec/Io (Event 1F) Thresholds: HHoEcNoThreshold HHoEcNoC ancel L3 filter: EcNofilterC oefficient Timers: HHoEcNoTimeHysteresis HHoEcNoC ancelTim e UL Quality Timer: ULQualDetRepThreshold Data rate threshold HHOMAxAllow edBitrateUL

2. GSM measurement reporting


Gsm MeasRepInterval GsmNcellSearchPeriod GsmMinMeasInterval GsmMaxMeasPeriod

3. Decision Algorithm

1. Triggering 2. GSM m easuring 3. Decision

AdjgTxPw rMaxTC H AdjgRxLevMinHO (n) GsmMeasAveWindow

Handover Execution

2G-to-3G back prevention


GsmMinHoInterval

4.1.1 Parameters
1. Triggering process: Parameters that belong to this process defines the starting of the GSM measurements: filters, hysteresis, timers and thresholds 2. GSM Measurement reporting process Following parameters control the reporting of the GSM measurements GsmMinMeasInterval: Establish minimum time between successive GSM measurements GsmMaxMeasPeriod: Maximum duration of the GSM measurements in compressed mode

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

56 (67)

TypeDateHere

GsmMeasRepInterval: Reporting period of the GSM measurements during compressed mode 3. Decision process: Parameters that participate in the selection of the best target cell: AdjgRxLevMinHO(n): Minimum RX level of the GSM cell to do handover (default=-95 dBm) 4. ISHO cancellation parameters: Cancellation parameters are built for CPICH EcNO and CPICH RSCP triggering functionality only

4.1.2 Testing Scenarios


Proper ISHO testing is possible with UE logging in routes with different speeds. Below are some set of tests + results for EcNo, RSCP and UeTxPwr thresholds with AMR.
Route s EcNo (IS-HO Success) % IS-HO Threshold /(Atte mpts) succe ss rate

Route 2

Route 4

Route 6

Total

-11 -12 -14 -11 -12 -14 -11 -12 -14 -11 -12 -14
UE Tx Pwr Threshold

12/12 12/12 3/9 7/9 8/9 7/9 13/16 13/16 9/20 32/37 33/37 19/38
(IS-HO Success) /(Attempts)

100% 100% 33.3% 77.7% 88.8% 77.7% 81.25% 81.25% 45% 86.50% 89.20% 50%
% IS-HO Success rate

Route s

RSC P (I S-HO Succe ss) Thre shold /(Atte mpts)

% IS-HO succe ss ra te

Route 2 Route 3

Route s

Route 4

Route 2

Route 3 Route 4

Route 6

Total

-1 -3 -5 -1 -3 -5 -1 -3 -5 -1 -3 -5 -1 -3 -5

6/6 6/6 6/6 10/10 9/9 9/10 6/6 6/6 6/6 22/30 27/30 22/25 44/52 48/51 43/47

100% 100% 100% 100% 100% 90% 100% 100% 100% 73.30% 90.00% 88% 84.60% 94.00% 91.50%

Route 6

T otal

-105 -106 -107 -105 -106 -107 -105 -106 -107 -105 -106 -107 -105 -106 -107

9/9 9/9 8/9 10/10 14/15 11/15 8/9 8/9 6/9 21/25 16/20 -48/53 47/53 25/33

100% 100% 88% 100% 93.3% 73.3% 88% 88% 66% 84% 80% -90.5% 88.7% 75.8%

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

57 (67)

TypeDateHere

Below are some different testing scenarios for filtering and timehysteresis for AMR.

RSCP
HHoRscpThreshold HHoRscpFilterCoefficient HHoRscpTimeHysteresis CPICH EcNo HHoEcNoThreshold HHoEcNoTimeHysteresis EcNoFilterCoefficient UE Tx Powe r GsmUETxPw rThrAMR GsmUETxPw rFilterCoeff GsmUETxPw rTimeHyst

Set 1
-105 dBm 200 ms 640 ms

Set 2
-105 dBm 400 ms 100 ms

Set 3
-105 dBm 200 ms 100 ms

Set 1
-12 dB 60 ms 600ms

Set 2
-12 dB 80 ms 600 ms

Set 3
-12 dB 100 ms 600 ms

Set4
-12 dB 200 ms 600 ms

Set 1
-5 dB 10 ms 1280 ms

Set 2
-5 dB 480ms 100ms

Set 3
-5 dB 10 ms 100ms

Set 4
-5 dB 10 ms 320ms

For PS data there some parameters could be set differently to trigger compressed mode. ISHO for PS data is done with Cell Change Order from Utran (CCO). The parameters for PS data triggers are
GsmUETxPwrThrNrtPS -1, -3 dB
10ms

UL Tx Pow er

-1 dB 10 ms 1280 ms -1 dB

GsmUETxPwrFilterCoeff GsmUETxPwrTimeHyst
DL DCH

320ms
-1, -3 dB

GsmDLTxPwrThrNrtPS

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

58 (67)

TypeDateHere

4.1.3 Example results


Below are some more results for the EcNo filtering and timehysteresis parameters.
CPICH EcNo

Set 1
-12 dB 60 ms 600ms

Set 2
-12 dB 80 ms 600 ms

Set 3
-12 dB 100 ms 600 ms

Set4
-12 dB 200 ms 600 ms

Route 1
800 600 400 200 0 Av e. distance(m) std(m) %Suc cess IS-HO 13.4 8.5 11.4 100 100 100 677 663 669 Set1 Set2 Set3

HHoEcNoThreshold HHoEcNoTimeHyster es is EcNoFilterCoef ficient

Parameter EcNoFilterCoefficient has been optimized for SHO (optimized value=600 ms)

Route 2
800 600 400 200 0 Ave. distance(m) std( m) %Suc cess IS-HO 44 63 22 90 88 88 562 575 555 Set1 Set2 Set3

Set 3 has the low est standard deviation and acceptable IS-HO success rate

Route 2
400 300 200 100 0 Av e. distance(m) s td(m) %Succ ess IS-HO 677 361 375 Set1 Set3 107 11.4 40 Set4 83 89 80

The use of higher hysteresis, e.g., HoEcNoTimeHysteresis=200 ms (set4) produce the w orst IS-HO success rate.

Below are some more results for the RSCP filtering and timehysteresis parameters.

Route 2
1000 800 600 400 200 0 Ave. distance(m) std(m) %Success IS-HO 42 11 17 100 88 100 795 766 743

RSCP
HHoRscpThres hold HHoRscpFilterCoef fic ient

Set 1
-105 dBm 200 ms 640 ms

Set 2
-105 dBm 400 ms 100 ms

Set 3
-105 dBm 200 ms 100 ms

Set1 Set2 Set3

HHoRscpTimeHy ster esis

Route 4
800 600 400 200 0 Ave. distance(m) std(m) %Success IS-HO 15 28 8 100 88 100 685 677 644 Set1 Set2 Set3

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

59 (67)

TypeDateHere

Below are some more results for the UE tx Pwr filtering and timehysteresis parameters.
Route 2 1000 800
meters

Route 4 800 700 600 500 400 300 200 100 0 682 716654 671 Setting 1 Setting2 Setting 3 29 28 21 22 Distance (m) Std (m) 88 88 88 90 %Success IS-HO Setting 4

859 750 726739 Setting 1 Setting 2 Setting 3 46 53 23 23 Distance (m) Std (m) 100 50 88 100 Setting 4

600 400 200 0 %Success IS-HO

Route 5 700 600 500 400 300 200 100 0 Distance (m) 548

603 519 Setting 1 Setting2 56 19 100 9 25 Setting 3 100

Set 4 provides the best balance betw een IS-HO success rate, distance (3G coverage extension) and standard deviation (accuracy)
UE Tx Powe r GsmUETx Pw rThrAMR

m eters

Std (m)

%Success IS-HO

Set 1
-5 dB 10 ms 1280 ms

Set 2
-5 dB 480ms 100ms

Set 3
-5 dB 10 ms 100ms

Set 4
-5 dB 10 ms 320ms

Set 4 w as not tested in this route due to the change of the radio conditions caused by the modification of the antenna direction of the serving cell.

GsmUETx Pw rFilterCoeff GsmUETx Pw rTimeHyst

4.2 GSM to 3G handover


Handover process to 3G is presented below.
Handover riggering set HandoverT T riggeringthresholds thresholds setin inBSC BSC Inter-RAT measurements starts in Inter-RAT measurements starts incase case the RXLEV of serving above or the RXLEV ofthe the servingcell cellis is above or below the given threshold Qsearch_C, below the given threshold Qsearch_C, (threshold MS) (thresholdfor forMulti-RAT Multi-RAT MS) Handover done in of Handoverdecision decisionis is done incase case of load of the serving cell > load_Threshold load of the serving cell > load_Threshold and Ec/No T ) )> andCPICH CPICH Ec/No(ME (MET > Min MinEc/No Ec/No threshold threshold MS selects the target RAN MS selects the targetUT UT RANcell cellbased based on onmeasurement measurementresults results Handover send Handovercommand commandis is sendto toMSC MSC

The BSC initiates an inter-system handover attempt to the WCDMA RAN if:

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

60 (67)

TypeDateHere

A neighbour WCDMA RAN cell is available (coverage). The cell-specific penalty timer does not exist in the BSC for the WCDMA RAN cell. Ec/No measured by the mobile has to exceed the handover threshold minimum CPICH Ec/Io level (MET). Traffic load of the serving GSM cell exceeds the threshold (load). The operator defines the load threshold by the parameters minimum traffic load for a speech call (LTSC). The procedure of the traffic load checking is similar compared to the BSC initiated Traffic Reason Handover. The BSC initiates only as many inter-system handovers as the number of ongoing calls in the serving GSM cell is over the traffic load threshold. That is, the serving GSM cell is not emptied into the WCDMA RAN.

4.2.1 Parameters
The main parameters to optimize GSM handover to 3G are MET (Min. EcNo threshold) MET tuning implies a compromise between blocked calls (GSM) and dropped calls(3G). MET should be higher than CPICH EcNo threshold for IS-HO 3G->GSM (default= 12 dB), in order to avoid ping-pongs and dropped calls. At least 3dB difference between MET and CPICH EcNo threshold is suggested. Proposed MET value is 9 dB.

Qsearch_C Qsearch_C implies a compromise between the lifetime battery and the availability of the terminal to handover to 3G. it would be good to know the 3G coverage levels so that IS-HO can happen quickly. In the other side, UE may unnecessarily measure 3G cells when there is no conditions for ISHO. In later BSS release, 3G measurements will start according to the load conditions. Despite the lifetime battery, it would be good not to add obstacles to the terminal to move to 3G. Thus, proposed value in BSS 10.5 is always (if 3G coverage exists).

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

61 (67)

TypeDateHere

4.2.2 Testing Scenarios


GSM ISHO scenarios could be related to the occupancy of GSM speech load e.q. when to handover from GSM to 3G. If the value (LTSC) of this parameter is set as 0, then AMR ISHO to 3G should happen. However this will depend on the operators strategy how to make AMR ISHO. Operator could also decide not to make AMR ISHO to GSM, but only PS data could make cell reselection to 3G. Also the neighbour definition could be defined in one direction only: 3G->GSM.

4.3 3G to GSM cell Reselection


Cell reselection does not happen only during Idle mode, also ISHO for PS data is done as cell reselection. The reselection process from 3G to GSM is presented below.
C PIC H EcNo

UE starts GSM m easurements if C PI C H Ec/ No < qQualMin + sSearchRAT First ranking of all the cells based on C PI C H RSC P (WC DMA) and RSSI (GSM) Rs = C PI C H RSC P + Qhyst1 Rn= Rxlev(n) - Qoffset1 Serving WC DMA cell calculation, w ith hysteresis parameter

SintraSearch

SinterSearch SsearchRAT qQualMin


No

Neighbour WC DMA or GSM cell calculation w ith offset param eter


Yes

Rn (GSM) > Rs (WC DMA) And Rxlev (GSM) > QrxlevMin Second ranking only for WC DMA cells based on C PI C H Ec/ No Rs = C PI C H Ec/ No + Qhyst2 Rn=C PI C H_Ec/ No(n)-Qoffset2 C ell re-selection to WC DMA cell of highest R value C ell re-selection to GSM

4.3.1 Parameters
The most important parameters are mentioned already above: Qhyst1 (hysteresis between GSM RSSI and 3G RSCP) AdjgOffset1 (offset to be extracted from GSM RSSI) qQualMin +sSearchRAT (start of Inter-System measurements)

4.3.2 Testing Scenarios


When to trigger the cell reselection to 2G depends greatly on: how much the 3G network is requested to be utilised target is to maximise the utilisation of WCDMA network but

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

62 (67)

TypeDateHere

what is the desired CSSR at the same time maximise the quality minimise the possibility of ping pong

Due to very different fading conditions, there should be couple of different parameter sets for 3G -> 2G reselection Outdoor, typical outdoor to dedicated indoor (in case of missing 3G indoor) 3G border Special indoor cases without dedicated 3G where the UE speed is high (e.g. tunnels)

Some extra protection against ping-pong reselections between the bands maybe needed -> therefore Qhyst1 parameter could be set to 2dB or 4dB, default 0 dB. Also in some special cases where WCDMA -> GSM reselection is needed to specific GSM cell the AdjgQoffset1 parameter could be set to such that it will promote certain GSM neighbour (e.g. value 20dB to use for high-speed train or highway tunnels without 3G coverage) So different Scenarios could be like in following:

General outdoor & Outdoor to indoor 3G -> 2G EcNo<-14dB Rxlev> -95 dBm Rxlev>RSCP + 2dB

Special Indoor cases

Outdoor border

EcNo<-6 dB Rxlev> -105dBm Rxlev+20dB>RSCP+2dB

EcNo<-10dB Rxlev> -95 dBm Rxlev>RSCP+2dB

First ranking of all the cells based on C PIC H RSC P (WC DMA) and RSSI (GSM) Rs = C PIC H RSC P + Qhyst1 Rn= Rxlev(n) - Qoffset1

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

63 (67)

TypeDateHere

4.4 GSM to 3G Cell Reselection


The reselection process from GSM to 3G is presented below
Check levels every 5s from serving GSM cell and best 6 GSM neighbour cells

UE UEstarts startsWCDMA WCDMAmeasurements measurementsififRxlev Rxlev running runningaverage average(RLA_C) (RLA_C)is isbelow belowor orabove above certain threshold: certain threshold: RLA_C Qsearch_I and Qsearch_P (GPRS) RLA_C Qsearch_I and Qsearch_P (GPRS)

Check quality of neighbour WCDMA cells, no priorities between WCDMA neighbours

UE UEwill willre-select re-selectWCDMA WCDMAcell cellin incase caseit's it's quality qualityis isacceptable: acceptable: CPICH CPICHEc/No Ec/NoMinimum_FDD_Threshold Minimum_FDD_Threshold

4.4.1 Parameters
The idle state parameters are sent to the GPRS capable mobile in the Packet System Information PSI 3quater (if PBCCH is allocated), or SI 2quater (if PBCCH is not allocated) messages on the PBCCH or BCCH GPRS threshold to search WCDMA RAN cells (QSRP) GPRS minimum fdd threshold (GFDM) GPRS fdd cell reselect offset (GFDD)

The set below is repeated for every neighbour WCDMA RAN cell: WCDMA downlink carrier frequency (FREQ) downlink transmission diversity (DIV) scrambling code (SCC)

In GSM the UE is usually set to measure the 3G neighbours all the time I.e. Qsearch_I and Qsearch_P are both set to 7

05.08:This may take up to 30s

Compare levels of all GSM cells to WCDMA neighbour

UE UEcan canselect selectWCDMA WCDMAcell cellifif the thelevel levelof ofthe the serving servingGSM GSMand andnon-serving non-servingGSM GSMcells cellshas hasbeen been exceeded by certain offset for a period of 5 exceeded by certain offset for a period of 5s: s: CPICH RSCP > RLA_C + CPICH RSCP > RLA_C + FDD_Cell_Reselect_Offset FDD_Cell_Reselect_Offset

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

64 (67)

TypeDateHere

In case the reselection is wanted to happen immediately when the 3G is good enough just based on CPICH Ec/No value (RSCP threshold is not used i.e. reselection is done RSCP > Rxlev infinity)

FDD_Qoffset (FDD_Cell_Reselect_Offset ) 0 1 2 14 15

Mapped to: -28dB -24dB 24dB 28dB

C om ment:
Always select irrespective of RSC P value Reselect in case WC DAM RSC P > GSM RXLev (RLA_C ) 28dB

Reselect in case WC DAM RSC P > GSM RXLev (RLA_C ) +28dB

The rule to set the FDD_Qmin value has not been possible to be fulfilled until the specification change (05.08 v8.18.0, 2003-8) has been implemented to the UEs as below

Fdd_Q m in m apping Aif param eter Fdd_Q m in (old) [dB] Fdd_Q m in (new) [ dB ]

0 1 2 3 4 5 6 7 -20 -19 -18 -17 -16 -15 -14 -13 -20 -6 -18 -8 -16 -10 -14 -12

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

65 (67)

TypeDateHere

4.4.2 Testing Scenarios


As a general rule the value for to search 3G cell (FDD_Qmin parameter) can be set to 23 dB higher than threshold to search GSM cell (QqualMin +Ssearch_RAT = -14dB). This is to avoid ping pong.

C PIC H Ec/ No

FDD_Qmin >= QqualMin + Ssearch_RAT

FDD_ Qm in >=-12

QqualMin + Ssearch_RAT = -14dB

QqualMin = -18dB

t
C am ping in 3G C amping in 2G C amping in 3G

For the the camping in indoor environment the set-up could be : Indoor GSM / Outdoor GSM (serving indoor)-> Indoor WCDMA / Outdoor WCDMA (serving indoor) Mobile station measuring WCDMA neighbor only when it is well inside the building using parameter Threshold to search WCDMA RAN Cells

The defined set-up can be also used in outdoor environment to push the UEs to 3G as soon as possible from the 2G cell to the border 3G cell Reselection from 2G to 3G coverage border cell (3G coverage border or coverage hole)

GSM WC DMA
WC DMA measurements not allow ed WC DMA measurements Allow ed; re-selection enabled

A subscriber entering back to the 3G coverage should not be handed over directly to 3G until 3G network coverage is good enough to avoid ping pong between GSM and WCDMA layers This can be achieved by setting the parameters so that there is certain probability when the UE reselects back to the WCDMA layer

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

66 (67)

TypeDateHere

WC DMA measurements Allow ed; reselection enabled

WC DMA measurements not allow ed

A subscriber in indoors may be served by a 3G outdoor macro cell or by 2G in-building cell When a subscriber enters the building the UE may reselect or the call can be handed over to the 2G in-building cell if the current 3G signal gets too weak To avoid any unnecessary HOs from 2G to 3G the voice call will then be ended in the 2G cell Idle state mobiles and active PS domain service users are guided back to 3G with cell reselection process when the 2G and 3G signals are/become strong enough This set-up keeps the user served by a 3G cell as long as possible and guides user served by 2G cell back to 3G service when a 3G cell is available with certain probability

General outdoor & Outdoor to indoor 3G -> 2G EcNo<-14dB Rxlev> -95 dBm Rxlev>RSCP + 2dB

Special Indoor cases

Outdoor border

EcNo<-6 dB Rxlev> -105dBm Rxlev+20dB>RSCP+2dB

EcNo<-10dB Rxlev> -95 dBm Rxlev>RSCP+2dB

First ranking of all the cells based on CPIC H RSCP (WCDMA) and RSSI (GSM) Rs = CPI C H RSC P + Qhyst1 Rn= Rxlev(n) - Qoffset1

DOCUMENTTYPE TypeUnitOrDepartmentHere TypeYourNameHere

67 (67)

TypeDateHere

4.5 Tools & Test Procedure


The tools for ISHO tests are 1. UE logging tool with AMR and PS data (Nemo with Kenny) 2. Netwhawk/ICSU log Test Procedure could be: 1. Define several different routes (different UE speed) in the area where acceptable minimum coverage for both WCDMA and GSM coverage could be seen. 2. Make 50 AMR short calls until ISHO happened, one direction only, record and check result. 3. Make 50 PS short calls with FTP downloading (1Mbyte file) until ISHO happened, one direction only, record and check result. 4. Make ISHO steps 1-3 with other direction (GSM to 3G) 5. Take nethawk logs/ICSU logs for measuring the ISHO delays

5. REFERENCES
Nokia Japan : Parameter Testing Reports for Vodafone KK Nokia Singapore : Parameter Testing Reports for M1 & StarHub Nokia Taiwan : Parameter Testing for CHT Hagedorn Thorsten: Tmobile Parameter Testing ISHO verification and Optimisation in NTN