Download - Parameter Testing Reference Quide

DOCUMENTTYPE 1 (63)

TypeUnitOrDepartmentHereTypeYourNameHere TypeDateHere

3G Radio Optimisation

Parameter Testing Guide

No. of Pages:

55

Checked by:

3G Radio Cop

Author:

Pekka Ranta

Approved by:

DOCUMENTTYPE 2 (63)


Table of Contents

1. Call setup performance...................................................................................................................41.1 Idle Mode Performance............................................................................................................4

1.1.1 Parameters........................................................................................................................51.1.2 Testing Scenarios..............................................................................................................61.1.3 Tools & Test Procedure.....................................................................................................71.1.4 Example Results...............................................................................................................71.1.5 Conclusions for this network...........................................................................................10

1.2 RRC Connection Establishment Performance.......................................................................121.2.1 Parameters......................................................................................................................131.2.2 Testing Scenarios............................................................................................................151.2.3 Tools & Test Procedure..................................................................................................161.2.4 Example Results.............................................................................................................16

1.3 RAB Establishment Performance...........................................................................................201.3.1 Parameters......................................................................................................................201.3.2 Testing Scenarios............................................................................................................221.3.3 Tools & Test Procedure...................................................................................................221.3.4 Example results...............................................................................................................22

1.4 Call Setup Success Rate (CSSR) & Time..............................................................................231.4.1 Parameters......................................................................................................................231.4.2 Testing Scenarios............................................................................................................241.4.3 Tools & Test Procedure...................................................................................................251.4.4 Example Results.............................................................................................................25

2. SHO Performance.........................................................................................................................302.1 Parameters.............................................................................................................................312.2 Tools & Test Procedures........................................................................................................332.3 Testing Scenarios/Example Results.......................................................................................35

SHO Tuning: CPICH Ec/No Filter Coefficient...............................................................................35SHO Tuning: Addition and Drop Time..........................................................................................36SHO Tuning: Addition and Drop Windod......................................................................................36SHO Tuning: Maximum Active Window Set Size..........................................................................38

3. ps data performance.....................................................................................................................403.1 Cell Throughput......................................................................................................................40

3.1.1 Parameters......................................................................................................................403.1.2 Testing Scenarios............................................................................................................423.1.3 Tools & Test Procedure...................................................................................................433.1.4 Example Results.............................................................................................................43

3.2 Dynamic Link Optimisation.....................................................................................................453.2.1 Parameters......................................................................................................................473.2.2 Testing Scenarios............................................................................................................483.2.3 Tools & Test Procedure...................................................................................................483.2.4 Example Results.............................................................................................................49

4. Inter-system handover..................................................................................................................554.1 3G to GSM Handover.............................................................................................................55

4.1.1 Parameters......................................................................................................................554.1.2 Testing Scenarios............................................................................................................56

DOCUMENTTYPE 3 (63)


4.1.3 Example results...............................................................................................................584.2 GSM to 3G handover..............................................................................................................59

4.2.1 Parameters......................................................................................................................604.2.2 Testing Scenarios............................................................................................................61

4.3 3G to GSM cell Reselection...................................................................................................614.3.1 Parameters......................................................................................................................614.3.2 Testing Scenarios............................................................................................................61

4.4 GSM to 3G Cell Reselection...................................................................................................634.4.1 Parameters......................................................................................................................634.4.2 Testing Scenarios............................................................................................................65

4.5 Tools & Test Procedure..........................................................................................................675. 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 don’t 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 4 (63)


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

Corrected Reselection: performance

Call Setup Delay (PDF & CDF)

0

10

20

30

40

50

60

70

80

90

100

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

PDFCDF

Call Setup Delay (PDF & CDF)

0

10

20

30

40

50

60

70

80

90

100

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

PDFCDF

0.0%

20.0%

40.0%

60.0%

80.0%

100.0%

<3.5

s

3.5

s -3.7

s

3.7

s -3.9

s

3.9

s -4.1

s

4.1

s-4.3

s

4.3

s-4.5

s

4.5

s-4.7

s

4.7

s-4.9

s

4.9

s-5.1

s

5.1

s-5.3

s

5.3

s-5.5

s

>5.5

s

Setup Time (seconds)

Call Setup Delay CDF

0.0%

20.0%

40.0%

60.0%

80.0%

100.0%

<3.5

s

3.5

s -3.7

s

3.7

s -3.9

s

3.9

s -4.1

s

4.1

s-4.3

s

4.3

s-4.5

s

4.5

s-4.7

s

4.7

s-4.9

s

4.9

s-5.1

s

5.1

s-5.3

s

5.3

s-5.5

s

>5.5

s

Setup Time (seconds)

Call Setup Delay CDF

DOCUMENTTYPE 5 (63)


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 6 (63)


Default values for some of the parameters are below.

Parameters Default value

Treselection 0 s

Qhyst 2 4 dB

AdjsQoffset2 0 dB

Sintrasearch 4 dB

Qqualmin -20 dB

Qrxlevmin -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:

ParameterDefault (param

dictionary/optimal)Set1 Set2 Set3

Sintrasearch 4dB/10dB 14dB 12dB 14dBQhyst2 4dB/2dB 0 2 2Treselection 0s/2s 1 0 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 7 (63)


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 8 (63)


Chart from scanner data shows best server’s 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 9 (63)


DOCUMENTTYPE 10 (63)


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

BLER < 1% Prob = 90% EcNo = -6 ~-7 dB RSCP = -80



BLER <3% Prob= 90% EcNo = -14 dB 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.



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

In case the BTS doesn’t 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 what’s 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 it’s guaranteed that RRC connection setup attempt always ends before the last page is sent from CN (9 s).

Ptx =CPICHtransmissionPower-RSCP(CPICH) +RSSI(BS) +PRACHRequiredReceivedCI



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.

Parameters Default Value



PRACH_preamble_retrans 8

RACH_tx_Max 8

PowerOffsetLastPreamblePRACHmessage 2dB

PowerRampStepPRACHpreamble 2dB

PRACHRequiredReceivedCI -25 dB

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

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


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 Default Set 1

PRACHRequiredReceived CI -25 dB -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.



1. Logging tool for voice, UDI and PS (1 service at one time), also Kenny with Nemo for voice test as reference

Default Set Set10 Set11 Set12PRACHRequiredReceivedCI -13 -21 -21 -18PowerOffsetLastPreamblePRACHmessage 2 5 2 2

Default Set Set10 Set11 Set12PRACHRequiredReceivedCI -13 -21 -21 -18PowerOffsetLastPreamblePRACHmessage 2 5 2 2



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


If counters are used for RRC connection success they are (service level table)

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

RRC Conn Setup Att Repeats:

Also it is possible to look at cell reselection time

RRC Connection Request

RRC Connection Setup Complete

UE RNC

RRC Connection Setup

RRC Connection Request

RRC Connection Setup Complete

UE RNC

RRC Connection Setup

sTMSETUPRRCDENOM

TMSETUPRRCAVE100/

___

___

XTriggering Point

%100*___

______

ATTSTPCONNRRC

CMPSTPCONNRRCRateCompSetupRRC

%100*___

______

ATTSTPCONNRRC

CMPACCCONNRRCRateCompEstabRRC



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.

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.

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

1 2 3 4 5 6 7 8

PRACH req. C/I = -25dB PRACH req. C/I = -20dB

100%

0% 0% 0%

88%

2% 5% 6%

0%

20%

40%

60%

80%

100%

1 2 3 4

# RRC Connection Request Messages per call setup

%

PRACH req. C/I = -20dB PRACH req. C/I = -25dB



PRACHRequiredReceivedCI: Call setup delay

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

96.2%

100.0%

94%

95%

96%

97%

98%

99%

100%

-25dB -20dB

Call Setup Success Rate0.0%

20.0%

40.0%

60.0%

80.0%

100.0%

120.0%

<3

.5s

3.5

s -

3.7

s

3.7

s -

3.9

s

3.9

s -

4.1

s

4.1

s-4

.3s

4.3

s-4

.5s

4.5

s-4

.7s

4.7

s-4

.9s

4.9

s-5

.1s

5.1

s-5

.3s

5.3

s-5

.5s

>5

.5s

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

PRACH req. C/I = -25 PRACH req. C/I = -20



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.

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.

CPICH RSCP vs Last preamble power

-50

-40

-30

-20

-10

0

10

20

30

-110 -100 -90 -80 -70 -60 -50 -40 -30

CPICH RSCP [dBm]

Last

Pre

ambl

e P

ower

[dB

m]

Default

Set10

Set11

Set12

線形 (Default)

線形 (Set10)

線形 (Set11)

線形 (Set12)



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

CPICHtoRefRABOffset 2 dB

EbNoSetIdentifier 1

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

The max DL power is determined by AC as

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

time

Maxpower

Minpower


time

Maxpower

Minpower


time

Maxpower

Minpower


time

Maxpower

Minpower

time

Maxpower

Minpower

),( max__,max,max, DPCHtxdpchreftxefftx PNPRIMINP



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 .

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.


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

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


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.

refrefeff RI

RIRI

max

max,fRabOffsetpichTo

CPICHtxreftx C

PP

Re

,,

refrefeff RI

RIRI

max

max,fRabOffsetpichTo

CPICHtxreftx C

PP

Re

,,

Default Set1 Set2 Set3 Set4EbNoSetIdentifier 1 2 3 2 2CPICHRefRABoffset 0 0 0 -3 3



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.

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.

default set1 set2 set3 set4A Call Setup Failure during RRC Connection Setup Phase (2.1) 0 0 0 0 0B Call Setup Failure during Access Phase due to RACH/FACH (2.2) 0 0 0 0 0C Call Setup Failure due to RRC Connection Reject (2.3) 0 1 0 0 0D Call Setup Failure due to NO RRC Connection Setup Complete (2.9) 0 0 0 0 0E Call SetUp Failure due to No Initial Direct Transter (2.8) 0 0 0 0 0F Call Setup Failure during Security Procedure (2.5) 3 5 2 1 5G Call Setup Failure during RAB Setup procedure(Without Complete) (2.6) 0 2 1 0 0H Call Setup Failure during RAB Setup procedure(With Complete) (2.7) 0 0 0 0 0I Call Setup Success 27 22 22 29 25J Call Setup Failure due to Registration (2.4) 0 0 0 0 0

Total Atempt 30 30 25 30 30Call Setup Success 27 22 22 29 25Call Setup Success Ratio 90.00% 73.33% 88.00% 96.67% 83.33%



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.

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


Different Activation time offset parameters should be tested, also SRB bitrate will affect which value to use.

Parameter Default Value

Set1 Set2 Set3

ActivationTimeOffset 300 ms 700 ms 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. :

Service SRB 3,4 SRB 13,6AMR 280 70CS 280 70PS 200 502*PS 320 803*PS 440 110AMR + 1*PS 400 100AMR + 2*PS 520 130AMR + 3*PS 640 160CS + 1*PS 400 100CS + 2*PS 520 130CS + 3*PS 640 160

Service SRB 3,4 SRB 13,6AMR 240 60CS 240 60PS 160 402*PS 280 703*PS 400 100AMR + 1*PS 360 90AMR + 2*PS 480 120AMR + 3*PS 600 150CS + 1*PS 360 90CS + 2*PS 480 120CS + 3*PS 600 150

Service SRB 3,4 SRB 13,6All services 80 20

RB Procedures

Transport channel procedures

Physical channel and measurement procedures



Radio Bearer Setup

Radio Bearer Reconfiguration

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


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%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

x>-4

-4>=

x>-6

-6>=

x>-8

-8>=

x>-1

0

-10>

=x>-

12

-12>

=x>-

14

-14>

=x>-

16

-16>

=x>-

18

-18>

=x

Call SetUp Success Call SetUp Failure during RRC connection request phaseCall SetUp Failure during access phase due to RACH/FACH Call SetUp Failure due to RRC connection rejectCall SetUp Failure during security procedure Call SetUp Failure during RAB setup procedure(Without Complete)Call SetUp Failure during RAB setup procedure(With Complete) Call SetUp Failure due to No CM service erquest w ith RRC Connection SetUp CompleteCall SetUp Failure due to No RRC Connection SetUp Complete



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

Call Setup Failure & Time: UDI

Call setup delay with different SRBs

1 RRCConnectionRequest <=> RRCConnectionSetup2 RRCConnectionSetup <=> RRCConnectionSetupComplete3 RRCConnectionSetupComplete <=> MM CM Service Request4 MM CM Service Request <=> MM Authentication Request5 MM Authentication Request <=> MM Authentication Response6 MM Authentication Response <=> SecurityModeCommand7 SecurityModeCommand <=> SecurityModeComplete8 SecurityModeComplete <=> CC SetUp9 CC SetUp <=> CC Call Proceeding

10 CC Call Proceeding <=> RadioBearerSetup11 RadioBearerSetup <=> RadioBearerSetupComplete12 RadioBearerSetupComplete <=> CC Alerting



Change of SRB Bitrate

UESRB (kbps)Offset (msec) 200 1500 200 1500 200 1500 200 1500 200 1500 200 1500

117 (CONNECT ACKNOWLEDGE) 3.766 5.045 3.671 4.734 3.434 5.087 2.873 4.115 3.780 5.090 2.959 4.220Difference -1.279 -0.000 -1.374 -0.311 -1.653 -0.000 -2.214 -0.972 -1.310 -0.000 -2.131 -0.870

NECv3.25 Kenny1389 SHARP3.4k 13.6k 3.4k 13.6k 3.4k 13.6k



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

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:

Soft handover overhead distribution on cell basis shown below

Median value 49% on cell basis (no weighting with traffic)

94

95

96

97

98

99

100

RRC Setup SuccessRate RRC Access SuccessRate RRC Setup & Access SuccessRate

SRB 13.6kbpsSRB 3.4kbps



Average value 47% (with traffic weighting)

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

0 50 100 150 2000

100

200

300

400

500

600

S oft handover overhead [%]



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)

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 Default value

CPICH Ec/No Filter Coefficient 600 ms

Addition Window 2.5 dB

Addition Time 100ms

Drop Window 4 dB

Seema Gyanwali, 01/03/-1,

4 db



Drop Time 640

Replacement Window 2 dB

Replacement Time 100 ms

Maximum Active Set Size 3

Active Set Weighting Coefficient 0

The following parameters are not necessary to be tested:

CPICH Ec/No Filtering Co-efficient

Addition Time & Drop time

Replacement time

2.2 Tools & Test Procedures


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.

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.

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

Normal cell = UL & DL coverage are balanced

Cell having increased UL interference level = DL (CPICH) coverage bigger than UL coverage

Cell A Cell B

Normal cell = UL & DL coverage are balanced

Cell having increased UL interference level = DL (CPICH) coverage bigger than UL coverage

Cell A Cell B



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

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)

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 happensat 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 ActiveSetUpdate Msg. Therefore, 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 ADJSEcNooffset

Impact all of FMC targeted areas

Impact only between 2 targeted cells

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 happensat 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 ActiveSetUpdate Msg. Therefore, 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 ADJSEcNooffset

Impact all of FMC targeted areas

Impact only between 2 targeted cells

Cluster Suggestion

Apr, JP Default Proposal1 Proposal2 Default *1 NewSet 1 &9 Additional New Set New Set

CPICH Ec/No filter co-efficient 02

(400msec)2

(400msec)2

(400msec)3

(600msec)3

(600ms)3

(600ms)3

(600ms)Addition Window 2 2.5 3 2 2 2 2 2Addition Time 320 160msec 320 320 320 320 320 320Drop Window 6 dB 4 dB 6 dB 6 6 6 6 6Drop Time 640 640ms 640ms 640 640 640 640 640Replacement Window 2 dB 2 dB 2 dB 2 2 2 2 2Replacement Time 320 160ms 320ms 320 100 160 100 320

FMCS HOPS ParameterArea1 RNC X & Y Cluster Suggestion

Apr, JP Default Proposal1 Proposal2 Default *1 NewSet 1 &9 Additional New Set New Set

CPICH Ec/No filter co-efficient 02

(400msec)2

(400msec)2

(400msec)3

(600msec)3

(600ms)3

(600ms)3

(600ms)Addition Window 2 2.5 3 2 2 2 2 2Addition Time 320 160msec 320 320 320 320 320 320Drop Window 6 dB 4 dB 6 dB 6 6 6 6 6Drop Time 640 640ms 640ms 640 640 640 640 640Replacement Window 2 dB 2 dB 2 dB 2 2 2 2 2Replacement Time 320 160ms 320ms 320 100 160 100 320

FMCS HOPS ParameterArea1 RNC X & Y



SHO Tuning: CPICH Ec/No Filter Coefficient

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

Max AS Size= 3, CPICH Filter Coefficient Changed (1)

87

17

1.9 1.1

-10.4

53

8

1.5 1.5

-11.3

49

3 1.5 1.5

-11.6-20

-10

0

10

20

30

40

50

60

70

80

90

100

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

Average time betweenAS updates (s)

UE Power (dBm)

0 (200ms)

2 (400ms)

3 (600ms), default

By comparing the results of different parameter sets, the default value3should be the optimal one---

highest SHO gain, good KPIs and proper SHO overhead.

-9.9-9.3

-20

-10

0

10

20

30

40

50

60

70

80

90

100



UE Power (dBm)

3 (600ms), default

4 (800ms)

5 (1100ms)

6 (1600ms)

By comparing the results of different parameter sets, the

default value3should be the optimal one---highest SHO gain,

good KPIs and proper SHO overhead.

Max AS Size= 3, CPICH Filter Coefficient Changed (1)

87

17

1.9 1.1

-10.4

53

8

1.5 1.5

-11.3

49

3 1.5 1.5

-11.6-20

-10

0

10

20

30

40

50

60

70

80

90

100



UE Power (dBm)

0 (200ms)

2 (400ms)

3 (600ms), default

By comparing the results of different parameter sets, the default value3should be the optimal one---

highest SHO gain, good KPIs and proper SHO overhead.

-9.9-9.3

-20

-10

0

10

20

30

40

50

60

70

80

90

100



UE Power (dBm)

3 (600ms), default

4 (800ms)

5 (1100ms)

6 (1600ms)

By comparing the results of different parameter sets, the

default value3should be the optimal one---highest SHO gain,

good KPIs and proper SHO overhead.



SHO Tuning: Addition and Drop Time

SHO Tuning: Addition and Drop Windod



SHO Tuning: Maximum Active Window Set Size



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

Default Set Set1 Set2Active Set Weight Coefficient 0 1 0.5

A L L 1 0 . 5 0D o m i n a n t E c / I o ( d B ) - 7 . 6 8 - 7 . 6 8 - 7 . 6 3C o m b i n e d E c / I o ( d B ) - 5 . 7 9 - 5 . 7 1 - 5 . 8 1B L E R 0 . 3 8 0 . 6 1 0 . 6 5A c t i v e S e t N u m C e l l 1 . 2 5 1 . 3 1 1 . 3 6

A L L 1 0 . 5 0D o m i n a n t E c / I o ( d B ) - 7 . 0 6 - 6 . 7 2 - 7 . 0 7C o m b i n e d E c / I o ( d B ) - 6 . 6 8 - 6 . 1 8 - 6 . 5 4B L E R 0 . 8 1 0 . 6 4 1 . 7 3A c t i v e S e t N u m C e l l 1 . 1 9 1 . 2 8 1 . 3 0

N u m o f M e a s u r e m e n t r e p o r t m s g f o r e a c h e v e n tA M R U D I K e n n y

A v e r a g e v a l u e ( D o m i n a n t E c / N o , C o m b i n e d E c / N o , B L E R , A c t i v e S e t N u m c e l l )A M R U D I

A L L 1 0 . 5 01 a 2 5 0 2 0 4 1 5 21 b 2 1 9 1 8 6 1 4 41 c 1 8 4 3 2 9

A L L 1 0 . 5 01 a 2 0 6 1 8 0 1 6 81 b 1 7 0 1 7 6 1 4 71 c 2 1 1 7 7 4

A L L 1 0 . 5 01 a 2 6 0 1 9 5 1 6 81 b 2 3 7 1 8 6 1 4 71 c 2 6 5 2 7 4

A L L 1 0 . 5 0D r o p 2 2 3

A L L 1 0 . 5 01 3 7

A L L 1 0 . 5 00 0 0

N u m o f D r o pA M R U D I K e n n y

S a n y o



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.

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

Release RRCConnection


URA_PCH

CELL_DCH CELL_FACH

CELL_PCH

Establish RRCConnection

UTRA RRC Connected Mode

Idle Mode

(UE camps on UTRAN cell)

Available in RAN’04

cellUpdate, UL Tx

UL_DL_activation_timer

#cellUpdates

UL Tx

DRX DRX

Tx/Rx

inactivityTimer

Tx/Rx FACH/RACH

trafficVolume



URA_PCH

CELL_DCH CELL_FACH

CELL_PCH



Idle Mode


Available in the future

cellUpdate, UL Tx


#cellUpdates

UL Tx

DRX DRX

Tx/Rx

inactivityTimer

Tx/Rx FACH/RACH

trafficVolume



URA_PCH

CELL_DCH CELL_FACH

CELL_PCH



Idle Mode


Available in RAN’04

cellUpdate, UL Tx


#cellUpdates

UL Tx

DRX DRX

Tx/Rx

inactivityTimer

Tx/Rx FACH/RACH

trafficVolume



URA_PCH

CELL_DCH CELL_FACH

CELL_PCH



Idle Mode


Available in the future

cellUpdate, UL Tx


#cellUpdates

UL Tx

DRX DRX

Tx/Rx

inactivityTimer

Tx/Rx FACH/RACH

trafficVolume

Ec/No [dB]

Add threshold W=0 : -4dB

Add threshold W=0.5 : -3.4dB

drop threshold W=0 : -8dB

drop threshold W=0.5 : -6.55dB

W=0: SHO window : Add – Drop = 4dB

W=0.5: SHO window : Add – Drop = 3.15dB

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

[ActiveSet: SC1 and SC3]

[ActiveSet: SC1, SC2 and SC3]

• 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



Uplink Traffic Volume measurement low threshold (TrafVolThresholdULLow)

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


TrafVolThresholdULLow 128 bytes

TrafVolThresholdDLhigh 1024 bytes

TrafVolTimeToTriggerUL 0 ms

TrafVolPendingTimeUL 2000ms

UL/DL Activity timer 20s

InactivityTimerDownlinkDCH 2s-5s



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 fixed-value timer in RRC entity) when inactivity is detected in Cell_DCH state


As already said above the different inactivity timers (InactivityTimerDownlinkDCH, range 2-5s) 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 Default Set1 Set2 Set3TrafVolThresholdDLHigh 1024 bytes 2048 bytes 3072 bytes 4096 bytes




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


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



Average download time with certain inactivity timers for all pages:

MMS and FTP results (bigger amount of data:

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

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

B-Time: Fromthe first radio bearer reconfiguration(initial 64k) todownload 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: Fromthe starting to show the page(push the button) in the Idle statetocompletion to show the page(Progress bar completion)

Bearer status and Download time (Long Mail)

Bearer status and Download time (FTP)

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

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

In MMS test, 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 cases.



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

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.

0.00%

10.00%

20.00%

30.00%

40.00%

50.00%

60.00%

70.00%

80.00%

90.00%

100.00%

04/1

2/1

04/1

2/2

04/1

2/3

04/1

2/4

04/1

2/5

04/1

2/6

04/1

2/7

04/1

2/8

04/1

2/9

04/1

2/10

04/1

2/11

04/1

2/12

04/1

2/13

04/1

2/14

04/1

2/15

04/1

2/16

04/1

2/17

04/1

2/18

04/1

2/19

04/1

2/20

04/1

2/21

04/1

2/22

04/1

2/23

04/1

2/24

04/1

2/25

04/1

2/26

04/1

2/27

04/1

2/28

04/1

2/29

04/1

2/30

04/1

2/31

05/1

/105

/1/2

05/1

/305

/1/4

05/1

/505

/1/6

05/1

/705

/1/8

05/1

/905

/1/1

005

/1/1

105

/1/1

205

/1/1

305

/1/1

405

/1/1

505

/1/1

605

/1/1

705

/1/1

805

/1/1

905

/1/2

005

/1/2

105

/1/2

205

/1/2

305

/1/2

405

/1/2

505

/1/2

605

/1/2

705

/1/2

805

/1/2

905

/1/3

005

/1/3

1

Ratio_DUR_PS_BACKG_64_DL_IN_SRNC Ratio_DUR_PS_BACKG_128_DL_IN_SRNCRatio_DUR_PS_BACKG_384_DL_IN_SRNC

0

20000000

40000000

60000000

80000000

100000000

120000000

04/1

2/1

04/1

2/2

04/1

2/3

04/1

2/4

04/1

2/5

04/1

2/6

04/1

2/7

04/1

2/8

04/1

2/9

04/1

2/10

04/1

2/11

04/1

2/12

04/1

2/13

04/1

2/14

04/1

2/15

04/1

2/16

04/1

2/17

04/1

2/18

04/1

2/19

04/1

2/20

04/1

2/21

04/1

2/22

04/1

2/23

04/1

2/24

04/1

2/25

04/1

2/26

04/1

2/27

04/1

2/28

04/1

2/29

04/1

2/30

04/1

2/31

05/1

/105

/1/2

05/1

/305

/1/4

05/1

/505

/1/6

05/1

/705

/1/8

05/1

/905

/1/1

005

/1/1

105

/1/1

205

/1/1

305

/1/1

405

/1/1

505

/1/1

605

/1/1

705

/1/1

805

/1/1

905

/1/2

005

/1/2

105

/1/2

205

/1/2

305

/1/2

405

/1/2

505

/1/2

605

/1/2

705

/1/2

805

/1/2

905

/1/3

005

/1/3

1

DUR_PS_BACKG_64_DL_IN_SRNC DUR_PS_BACKG_128_DL_IN_SRNCDUR_PS_BACKG_384_DL_IN_SRNC

0

20000000

40000000

60000000

80000000

100000000

120000000

140000000

04

/12

/10

4/1

2/2

04

/12

/30

4/1

2/4

04

/12

/50

4/1

2/6

04

/12

/70

4/1

2/8

04

/12

/90

4/1

2/1

00

4/1

2/1

10

4/1

2/1

20

4/1

2/1

30

4/1

2/1

40

4/1

2/1

50

4/1

2/1

60

4/1

2/1

70

4/1

2/1

80

4/1

2/1

90

4/1

2/2

00

4/1

2/2

10

4/1

2/2

20

4/1

2/2

30

4/1

2/2

40

4/1

2/2

50

4/1

2/2

60

4/1

2/2

70

4/1

2/2

80

4/1

2/2

90

4/1

2/3

00

4/1

2/3

10

5/1

/10

5/1

/20

5/1

/30

5/1

/40

5/1

/50

5/1

/60

5/1

/70

5/1

/80

5/1

/90

5/1

/10

05

/1/1

10

5/1

/12

05

/1/1

30

5/1

/14

05

/1/1

50

5/1

/16

05

/1/1

70

5/1

/18

05

/1/1

90

5/1

/20

05

/1/2

10

5/1

/22

05

/1/2

30

5/1

/24

05

/1/2

50

5/1

/26

05

/1/2

70

5/1

/28

05

/1/2

90

5/1

/30

05

/1/3

1

Sum of DUR_PS_BACKG

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.

1024kB 3072kBTrafVolDLThreHigh = 1024kB 3072kBTrafVolDLThreHigh =

1024kB 3072kBTrafVolDLThreHigh =



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)

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.


PtxDlabsmax 50 dBm

MinAllowedBitRateDL 64 kbps

MaxBitRateDLPSNRT 384 kbps


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.



The load case could be generated with second UE having UDI call.

Other set could be as following:


The tools needed in these tests are:

3. Ue logging tool (Kenny with Nemo)

4. Scanner

5. Nethawk/ISCU logging tool

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.

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)


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.

Default Set1 Set2PtxDLabsMax 43 43 38 or 36InitialAndMinimumAllowedBitrateDL 384kbps 64kbps 64kbps MaxBitRateDLPSNRT 384kbps 384kbps 384kbps

Ref Name Priority Parameter Values Test* Time

PS_01 FIX RATE TEST FOR URBAN AREA (CELL EDGE)

P1 MaxBitRateDLPSNRT

MinAllowedBitRateDL

Max/Min =

384/384, 128/128, 64/64

M 1day

PS_02 FIX RATE TEST FOR RURAL AREA (COVERAGE EDGE)


MinAllowedBitRateDL

Max/Min =

384/384, 128/128, 64/64

M 1day

PS_03 FIX RATE TEST with Load (LOAD CONDITION)


MinAllowedBitRateDL

Max/Min =

384/384, 128/128, 64/64

M 1day

PS_04 MOVING TEST FOR URBAN AREA

P1 PtxDLabsMax

Ptx_DPCH_max

Parameter set is decided according to the result of P1-3

A 3days

PS_05 MOVING TEST FOR RURAL AREA

P1 PtxDLabsMax

Ptx_DPCH_max

Parameter set is decided according to the result of P1-3

A 3days

TOTAL (days) 9



2. Call is released after completed the 1M downloading and setup again

3. At the same, take the Nethawk/ICSU log.



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

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

R B S t a t u s S t a t i s t i c s ( v s E c N o )

0 . 0 0 %

2 0 . 0 0 %

4 0 . 0 0 %

6 0 . 0 0 %

8 0 . 0 0 %

1 0 0 . 0 0 %

1 2 0 . 0 0 %

> - 4 - 4 t o - 6 - 6 t o - 8 - 8 t o - 1 0 - 1 0 t o - 1 2 - 1 2 t o - 1 4 - 1 4 t o - 1 6 - 1 6 t o - 1 8 < - 1 8

E c / N o [ d B ]

s f 8

s f 1 6

s f 3 2

1 0 0 . 0 0 %

0 . 0 0 %0 . 0 0 %

5 1 . 0 3 %

3 8 . 3 0 %

1 0 . 6 7 %

4 0 . 7 2 %

4 7 . 5 5 %

1 1 . 7 3 %

3 0 . 3 4 %

5 6 . 4 0 %

1 3 . 2 6 %

1 7 . 0 3 %

5 7 . 1 6 %

2 5 . 8 1 %

1 1 . 5 4 %

5 6 . 0 9 %

3 2 . 3 7 %

1 1 . 3 2 %

3 7 . 7 4 %

5 0 . 9 4 %

5 . 2 1 %

1 8 . 7 5 %

7 6 . 0 4 %

6 . 9 8 %

4 . 6 5 %

8 8 . 3 7 %

0 %

1 0 %

2 0 %

3 0 %

4 0 %

5 0 %

6 0 %

7 0 %

8 0 %

9 0 %

1 0 0 %

> - 4 - 4 t o - 6 - 6 t o - 8 - 8 t o - 1 0 - 1 0 t o - 1 2 - 1 2 t o - 1 4 - 1 4 t o - 1 6 - 1 6 t o - 1 8 < - 1 8

E c / N o [ d B ]

R B S t a t u s S t a t i s t i c s ( v s E c N o )

s f 3 2

s f 1 6

s f 8

3 8 4 1 2 8 6 4



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


RB status for each EbNo

Ec/No vs BLER

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

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

Ec/No

Rat

io o

f BLE

R

10<

10

5

3

1

0

For each BitRate

≒-7～-8 ≒-14～-15



Distribution graph between Ec/No and Path Loss (RNCP)


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.

0

64000

128000

192000

256000

320000

384000

448000

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

05

:10

.4

BitR

ate

[bp

s]

0

5

10

15

20

25

30

35

40

Ptx

DC

H [

dB

m]

DL Bitrate current2 Ptx_ave_dBm

-130

-120

-110

-100

-90

-80

-70

-60

RS

CP

[d

Bm

]

-25

-20

-15

-10

-5

0

Ec/

No

[d

B]

CPICH Dominant RSCP (dBm) CPICH Dominant Ec/No (dB)



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.

+ Throughput

PtxDCH vs CPICH RSCP

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

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

Ec/No

[%]

~38

~36

~34

~32

~30

~28



Upgrade, Downgrade times

= > s f 8 = > s f 1 6 = > s f 3 2 = > F A C H = > I d l es f 8 8 5 9s f 1 6 4 3 6s f 3 2 6 8 3 4 1 1F A C H 1 1 0 1 3

= > s f 8 = > s f 1 6 = > s f 3 2 = > F A C H = > I d l es f 8 1 2 9s f 1 6s f 3 2 3F A C H 1 2 2 5 5

= > s f 8 = > s f 1 6 = > s f 3 2 = > F A C H = > I d l es f 8 1 7 4 6s f 1 6 1 5 1s f 3 2 6 7 3 9 1 1F A C H 6 9 8 3

D e f a u l t

S e t 1

S e t 2

= > s f 8 = > s f 1 6 = > s f 3 2 = > F A C H = > I d l es f 8 8 5 9s f 1 6 4 3 6s f 3 2 6 8 3 4 1 1F A C H 1 1 0 1 3

= > s f 8 = > s f 1 6 = > s f 3 2 = > F A C H = > I d l es f 8 1 2 9s f 1 6s f 3 2 3F A C H 1 2 2 5 5

= > s f 8 = > s f 1 6 = > s f 3 2 = > F A C H = > I d l es f 8 1 7 4 6s f 1 6 1 5 1s f 3 2 6 7 3 9 1 1F A C H 6 9 8 3

D e f a u l t

S e t 1

S e t 2

Times on different bearers’ spreading factors

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

Times on different bearers’ spreading factors

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

Ec/No or RSCP

0

50000

100000

150000

200000

250000

300000

350000

400000

0

5

10

15

20

25

30

35

40

45

Throughput

bps/W

BTS Tx Power



Dylo conclusions:

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.

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

3. Decision Algorithm

UE Tx Power (Event 6A)•Threshold:GsmUETxPwrThrXX •L3 filter:GsmUETxPwrFilterCoeff•Hysteresismargin:GsmUETxPwrTimeHyst•Data rate thresholdHHOMAxAllowedBitrateUL

UL Quality•Timer:ULQualDetRepThreshold•Data rate thresholdHHOMAxAllowedBitrateUL

DL DPCH power•Threshold:GsmDLTxPwrThrXX

•Data rate thresholdHHOMAxAllowedBitrateDL

(XX=AMR,CS,NrtPS,RtPS)

CPICH RSCP (Event 1F)•Thresholds:HHoRscpThreshold HHoRscpCancelL3 filter:HHoRscpFilterCoefficient•Timers:HHoRscpTimeHysteresisHHoRscpCancelTime

CPICH Ec/Io (Event 1F)•Thresholds:HHoEcNoThresholdHHoEcNoCancel•L3 filter:EcNofilterCoefficient•Timers:HHoEcNoTimeHysteresisHHoEcNoCancelTime

AdjgTxPwrMaxTCHAdjgRxLevMinHO(n)GsmMeasAveWindow

GsmMeasRepIntervalGsmNcellSearchPeriodGsmMinMeasIntervalGsmMaxMeasPeriod

1. Handover Triggering

Handover Execution2G-to-3G back prevention

GsmMinHoInterval

2. GSM measurement reporting

1. Triggering

2. GSM measuring

3. Decision

3. Decision Algorithm

UE Tx Power (Event 6A)•Threshold:GsmUETxPwrThrXX •L3 filter:GsmUETxPwrFilterCoeff•Hysteresismargin:GsmUETxPwrTimeHyst•Data rate thresholdHHOMAxAllowedBitrateUL

UL Quality•Timer:ULQualDetRepThreshold•Data rate thresholdHHOMAxAllowedBitrateUL

DL DPCH power•Threshold:GsmDLTxPwrThrXX

•Data rate thresholdHHOMAxAllowedBitrateDL

(XX=AMR,CS,NrtPS,RtPS)

CPICH RSCP (Event 1F)•Thresholds:HHoRscpThreshold HHoRscpCancelL3 filter:HHoRscpFilterCoefficient•Timers:HHoRscpTimeHysteresisHHoRscpCancelTime

CPICH Ec/Io (Event 1F)•Thresholds:HHoEcNoThresholdHHoEcNoCancel•L3 filter:EcNofilterCoefficient•Timers:HHoEcNoTimeHysteresisHHoEcNoCancelTime

AdjgTxPwrMaxTCHAdjgRxLevMinHO(n)GsmMeasAveWindow

GsmMeasRepIntervalGsmNcellSearchPeriodGsmMinMeasIntervalGsmMaxMeasPeriod

1. Handover Triggering

Handover Execution2G-to-3G back prevention

GsmMinHoInterval

2. GSM measurement reporting

1. Triggering

2. GSM measuring

3. Decision



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

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


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 /(Attempts) success rate

Route 2 -11 12/12 100%-12 12/12 100%-14 3/9 33.3%

Route 4 -11 7/9 77.7%-12 8/9 88.8%-14 7/9 77.7%

Route 6 -11 13/16 81.25%-12 13/16 81.25%-14 9/20 45%-11 32/37 86.50%

Total -12 33/37 89.20%-14 19/38 50%

Route s RSCP (IS-HO Success) % IS-HO

Thre shold /(Attempts) success rate

-105 9/9 100%Route 2 -106 9/9 100%

-107 8/9 88%Route 3 -105 10/10 100%

-106 14/15 93.3%-107 11/15 73.3%-105 8/9 88%

Route 4 -106 8/9 88%-107 6/9 66%-105 21/25 84%

Route 6 -106 16/20 80%-107 -- ---105 48/53 90.5%

Total -106 47/53 88.7%-107 25/33 75.8%

Route s UE Tx Pwr (IS-HO Success) % IS-HO

Threshold /(Attempts) Success rate

-1 6/6 100%Route 2 -3 6/6 100%

-5 6/6 100%-1 10/10 100%

Route 3 -3 9/9 100%-5 9/10 90%

Route 4 -1 6/6 100%-3 6/6 100%-5 6/6 100%-1 22/30 73.30%

Route 6 -3 27/30 90.00%-5 22/25 88%-1 44/52 84.60%

Total -3 48/51 94.00%-5 43/47 91.50%



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

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

RSCP Set 1 Set 2 Set 3

HHoRscpThreshold -105 dBm -105 dBm -105 dBm

HHoRscpFilterCoef f ic ient 200 ms 400 ms 200 ms

HHoRscpTimeHysteres is 640 ms 100 ms 100 ms

CPICH EcNo Set 1 Set 2 Set 3 Set4

HHoEcNoThreshold -12 dB -12 dB -12 dB -12 dB

HHoEcNoTimeHysteres is 60 ms 80 ms 100 ms 200 ms

EcNoFilterCoef f icient 600ms 600 ms 600 ms 600 ms

UE Tx Pow er Set 1 Set 2 Set 3 Set 4

GsmUETxPw rThrAMR -5 dB -5 dB -5 dB -5 dB

GsmUETxPw rFilterCoef f 10 ms 480ms 10 ms 10 ms

GsmUETxPw rTimeHyst 1280 ms 100ms 100ms 320ms

UL Tx Power GsmUETxPwrThrNrtPS -1 dB -1, -3 dB

GsmUETxPwrFilterCoeff 10 ms 10ms

GsmUETxPwrTimeHyst 1280 ms 320ms

DL DCH GsmDLTxPwrThrNrtPS -1 dB -1, -3 dB



4.1.3 Example results

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

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

R o u t e 1

1 3 . 41 0 0 1 0 0 1 0 0

6 7 7

8 . 5

6 6 3

1 1 . 4

6 6 9

0

2 0 0

4 0 0

6 0 0

8 0 0

A v e . d i s t a n c e ( m ) s t d ( m ) % S u c c e s s I S - H O

S e t 1

S e t 2

S e t 3

R o u t e 2

5 6 2

4 4

5 7 5

6 3

5 5 5

2 2 9 0 8 8 8 8

0

2 0 0

4 0 0

6 0 0

8 0 0


S e t 1

S e t 2

S e t 3

R o u t e 2

1 0 7 8 3 8 9 8 0

6 7 73 6 1

1 1 . 4

3 7 5

4 0

0

1 0 0

2 0 0

3 0 0

4 0 0


S e t 1

S e t 3

S e t 4

C P I C H E c N o S e t 1 S e t 2 S e t 3 S e t 4

H H o E c N o T h r e s h o l d - 1 2 d B - 1 2 d B - 1 2 d B - 1 2 d B

H H o E c N o T i m e H y s t e r e s i s 6 0 m s 8 0 m s 1 0 0 m s 2 0 0 m s

E c N o F i l t e r C o e f f i c i e n t 6 0 0 m s 6 0 0 m s 6 0 0 m s 6 0 0 m s

S e t 3 h a s t h e l o w e s t s t a n d a r d d e v i a t i o n a n d a c c e p t a b l e I S - H O s u c c e s s r a t e

T h e u s e o f h i g h e r h y s t e r e s i s , e . g . , H o E c N o T i m e H y s t e r e s i s = 2 0 0 m s ( s e t 4 ) p r o d u c e t h e w o r s t I S - H O s u c c e s s r a t e .

P a r a m e t e r E c N o F i l t e r C o e ffi c i e n t h a s

b e e n o p t i m i z e d f o r S H O ( o p t i m i z e d v a l u e = 6 0 0 m s )

RS CP S et 1 S e t 2 S e t 3

HHo Rsc pTh res ho ld -1 05 dB m -10 5 d B m -10 5 d Bm

HHo Rsc pF ilterCo ef f ic ie nt 2 0 0 ms 4 00 ms 20 0 ms

HHo Rsc pT imeHy s ter es is 6 4 0 ms 1 00 ms 10 0 ms

R o u te 2

7 95

42 10 0

76 6

1 18 8

74 3

1 710 0

0

2 00

4 00

6 00

8 00

1 0 00

A v e . d is tan c e(m) s td(m) % S uc c e s s IS -HO

S et1

S et2

S et3

R o u te 4

685

15100

677

2888

644

8100

0

200

400

600

800

A ve. d is tance(m ) std(m ) % S uc c es s IS -H O

S et 1

S et 2

S et 3



Below are some more results for the UE tx Pwr filtering and timehysteresis parameters.

4.2 GSM to 3G handover

Handover process to 3G is presented below.

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

R o u t e 2

7 5 0

4 61 0 0

8 5 9

5 3 5 0

7 2 6

2 3

7 3 9

2 31 0 0

8 8

0

2 0 0

4 0 0

6 0 0

8 0 0

1 0 0 0

D i s t a n c e ( m ) S t d ( m ) % S u c c e s s I S - H O

met

ers

S e t t i n g 1

S e t t i n g 2

S e t t i n g 3

S e t t i n g 4

R o u t e 4

6 8 2

2 98 8

7 1 6

2 88 8

6 5 4

2 1

6 7 1

2 29 08 8

01 0 02 0 03 0 04 0 05 0 06 0 07 0 08 0 0


S e t t i n g 1

S e t t i n g 2

S e t t i n g 3

S e t t i n g 4

R o u t e 5

5 4 8

5 61 0 0

6 0 3

1 9 2 5

5 1 9

1 0 09

0

1 0 0

2 0 0

3 0 0

4 0 0

5 0 0

6 0 0

7 0 0


me

ters

S e t t i n g 1

S e t t i n g 2

S e t t i n g 3

U E T x P o w e r S e t 1 S e t 2 S e t 3 S e t 4

G s m U E T x P w r T h r A M R - 5 d B - 5 d B - 5 d B - 5 d B

G s m U E T x P w r F i l t e r C o e f f 1 0 m s 4 8 0 m s 1 0 m s 1 0 m s

G s m U E T x P w r T i m e H y s t 1 2 8 0 m s 1 0 0 m s 1 0 0 m s 3 2 0 m s

S e t 4 w a s n o t t e s t e d i n t h i s r o u t e d u e t o t h e c h a n g e o f t h e r a d i o c o n d i t i o n s c a u s e d b y t h e

m o d i fi c a t i o n o f t h e a n t e n n a d i r e c t i o n o f t h e s e r v i n g c e l l .

S e t 4 p r o v i d e s t h e b e s t b a l a n c e b e t w e e n I S - H O s u c c e s s r a t e , d i s t a n c e ( 3 G c o v e r a g e e x t e n s i o n ) a n d s t a n d a r d d e v i a t i o n ( a c c u r a c y )

Handover Triggering thresholds set in BSCHandover Triggering thresholds set in BSC

Inter-RAT measurements starts in case the RXLEVof the serving cell is above or below the given threshold Qsearch_C,

(threshold for Multi-RAT MS)

Inter-RAT measurements starts in case the RXLEVof the serving cell is above or below the given threshold Qsearch_C,

(threshold for Multi-RAT MS)

Handover decision is done in case ofload of the serving cell > load_Thresholdand CPICHEc/No (MET) > MinEc/No

threshold

Handover decision is done in case ofload of the serving cell > load_Thresholdand CPICHEc/No (MET) > MinEc/No

threshold

MS selects the target UTRAN cell based on measurement results

MS selects the target UTRAN cell based on measurement results

Handover command is send to MSCHandover command is send to MSC



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




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.

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)


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…

First rankingof all the cells based on CPICH RSCP (WCDMA) and RSSI (GSM)

Rs= CPICH RSCP + Qhyst1Rn= Rxlev(n) - Qoffset1

Rn (GSM) > Rs(WCDMA)And

Rxlev (GSM) >QrxlevMin

YesNo

Cell re-selection to GSM

Neighbour WCDMA or GSM cell calculation with offset

parameter

Serving WCDMA cell calculation, with

hysteresisparameter

UE starts GSM measurements if CPICH Ec/No < qQualMin + sSearchRAT

SintraSearch

SinterSearch

SsearchRAT

CPICH EcNo

qQualMin

Second ranking only for WCDMA cells based on CPICH Ec/No

Rs = CPICH Ec/No + Qhyst2Rn=CPICH_Ec/No(n)-Qoffset2 Cell re-selection to

WCDMA cell of highest R value



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

General outdoor&

Outdoor to indoor

General outdoor&

Outdoor to indoor

Special Indoor casesSpecial Indoor casesSpecial Indoor cases Outdoor borderOutdoor borderOutdoor border

3G -> 2G3G -> 2G EcNo<-14dBRxlev> -95 dBmRxlev>RSCP + 2dB

EcNo<-14dBRxlev> -95 dBmRxlev>RSCP + 2dB

EcNo<-6 dBRxlev> -105dBmRxlev+20dB>RSCP+2dB


EcNo<-10dBRxlev> -95 dBmRxlev>RSCP+2dB


First rankingof all the cells based on CPICH RSCP (WCDMA) and RSSI (GSM)




4.4 GSM to 3G Cell Reselection

The reselection process from GSM to 3G is presented below

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

Check levels every 5s from serving GSM cell

and best 6 GSM neighbour cells

UE starts WCDMA measurements if Rxlev running average (RLA_C) is below or above

certain threshold:RLA_C Qsearch_I and Qsearch_P (GPRS)



UE can select WCDMA cell if the level of the serving GSM and non-serving GSM cells has been

exceeded by certain offset for a period of 5 s:CPICH RSCP > RLA_C + FDD_Cell_Reselect_Offset



UE will re-select WCDMA cell in case it's quality is acceptable:

CPICH Ec/No Minimum_FDD_Threshold



Compare levels of all GSM cells

to WCDMAneighbour

Check quality of neighbour

WCDMA cells, no priorities between

WCDMA neighbours 05

.08:

Thi

s m

ay t

ake

up t

o 30

s













Compare levels of all GSM cells

to WCDMAneighbour

Check quality of neighbour

WCDMA cells, no priorities between

WCDMA neighbours 05

.08:

Thi

s m

ay t

ake

up t

o 30

s



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)

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


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

Reselect in case WCDAM RSCP > GSMRXLev(RLA_C) +28dB

28dB15

24dB14

……

-24dB2

Reselect in case WCDAM RSCP > GSMRXLev(RLA_C) –28dB

-28dB1

Always select irrespective of RSCP value 0

Comment:Mapped to:

FDD_Qoffset (FDD_Cell_Reselect_Offset )

Reselect in case WCDAM RSCP > GSMRXLev(RLA_C) +28dB

28dB15

24dB14

……

-24dB2

Reselect in case WCDAM RSCP > GSMRXLev(RLA_C) –28dB

-28dB1

Always select irrespective of RSCP value 0

Comment:Mapped to:

FDD_Qoffset (FDD_Cell_Reselect_Offset )

Fdd_Qmin mapping

Aif parameter 0 1 2 3 4 5 6 7Fdd_Qmin (old) [dB] -20 -19 -18 -17 -16 -15 -14 -13Fdd_Qmin (new) [dB ] -20 -6 -18 -8 -16 -10 -14 -12



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)

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

A subscriber in indoors may be served by a 3G outdoor macro cell or by 2G in-building cell

QqualMin = -18dB

QqualMin + Ssearch_RAT= -14dB

FDD_Qmin >=-12

Camping in 3G Camping in 2G Camping in 3G

CPICH Ec/No

t

FDD_Qmin >= QqualMin + Ssearch_RAT

QqualMin = -18dB

QqualMin + Ssearch_RAT= -14dB

FDD_Qmin >=-12

Camping in 3G Camping in 2G Camping in 3G

CPICH Ec/No

t

FDD_Qmin >= QqualMin + Ssearch_RAT

WCDMA measurementsnot allowed

WCDMA measurementsAllowed; re-selection enabled

WCDMA

GSM

WCDMA measurements Allowed; re-selection enabled

WCDMA measurements not allowed



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

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.

General outdoor&

Outdoor to indoor

General outdoor&

Outdoor to indoor

General outdoor&

Outdoor to indoor

Special Indoor casesSpecial Indoor casesSpecial Indoor cases Outdoor borderOutdoor borderOutdoor border

3G -> 2G3G -> 2G EcNo<-14dBRxlev> -95 dBmRxlev>RSCP + 2dB

EcNo<-14dBRxlev> -95 dBmRxlev>RSCP + 2dB





First ranking of all the cells based on CPICH RSCP (WCDMA) and RSSI (GSM)




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

Download - Parameter Testing Reference Quide

Top Related