Communications

TIM, VDF-D2 ISHO handover issues in CM mode

H.Fischer/L.Florean/A.Richel050602 (1) ISHO handover issues in CM mode INTERNAL V2.5.ppt

2

Compressed Mode Issues: Overview

Overview: Case1: Wrong Activation timer (UMR2.0) solved UMR30.04 Case2: HO failures with video calls in CM mode(UMR30.04 ff) CR738,

solved in UMR30.10 Case3: NodeB CM mode deactivation failure (UMR30.07) solved in

UMR30.10A with NBL9_54_3 Case4: RL failure during rapid CM activation/deactivation “Motorola

problem” Fekat DA4576 (failure still there, but lower activation time for CM mode makes it much less frequent). 18.2.05 introduced in Berlin BXN002

Case5: 18.2.05: RNC sends wrong TGCFN numbers to UE FEKAT DB8291 solved UMR35.08 patch 644

Case6: 18.5.05: Combined trigger Ec/No and RSCP not working with many UEs

3

Case1: 3G to 2G HO Activation timer (1)

Short description (Known problem): Case1: in UMR 2.0 RNC sends activation time values which randomly are not

multiple of 4. Therefore the transmission gaps are not synchronized on network and handset side, resulting in a high block error rate. The amount of block error rate depends on how much the "unwanted" overlap is and of the prevailing general radio conditions. This block error rates occur on all physical channels, e.g. signaling channels and user plane. The error correction built in terminal and network receivers can correct some errors. In consequence, a wrong activation timer does not necessarily provoke a call drop. All these statistical effects are overlapping depending also from terminal’s capabilities

Impact on network– The HO fails (drop) or is successful (not predictable)– A Radio Link failure occurs (drop)– A RLC reset occurs (drop)– High user plane block-error rate: terminal dependent call release perceived as

drop by end-user– Drive testing in Berlin 15.1.03 showed only 43% of success mainly due to

activation timer problem

4

Case1: 3G to 2G HO Activation timer (2)

Progress/applied actions: 28.1.04: Potential work around for UMR20 to bridge the time until rollout of

UMR3.0 by a set of new parameters verified Factory default parameters adapted to change the gaps in compressed mode,

during which the Ue is measuring GSM cells Default gap length has been constructed such

– to allow handover for mobiles moving with high speed in areas with short cell overlapping between GSM and UMTS

New parameter set improves success rate despite activation timer fault to 80..90% (depending on terminal type), because probability of high block error rate is drastically reduced

Remaining failures are most likely direct consequence of the remaining collisions and the Ues capability to decode them anyhow

Workaround is suitable for UMR2.0 , UEs Samsung and Nokia and shall be removed for UMR 3.0

Solution plan: solved and verified in field for VDF-D2 (15.11.04)

5

Case2: UMR3.0 CM HO problems with video calls

Progress/applied actions: 14.4.04: Mail received from Ericsson with following content (UMR 3.0)

– It takes normally 4 seconds from the time that we report 3A until HandoverFromUTRANCommand is received due to the fact that two MSCs are involved. This means that from the moment the UE has a signal strength of RSCP = -103 it will take an extra second before 3A is sent (time to trigger = 200 ms + fc2 = about 800 ms). So in total it will take 5 seconds from the UE measures a strength of -103 until the call is moved to GSM. Comment: This will cause a lot of U2G HO failures. Behavior is not seen in the infrastructure provided by Ericsson in Dusseldorf. Please compare!

– Known error SHO during compressed mode (Fekat CV3117) should be solved with UMR30/03

– Above LME problem seems to be a timing issueShort description Case2: 14.4.04: Nokia indicated during drive testing in Vodafone network HO

failures in compressed mode: 3G ->2G ISHO - 88% success rate. 2/17 tests failed. 1 dropped call and 1 error in connection.

6

Case2: UDI call drops during CM mode

Solution plan: 16.4.04: VDF executed HO during CM and video calls. Intersystem-HO to 2G is

refused (ok, UDI calls not possible in 2G) and UE (Samsung Z105) performs many HOs. Finally call drops– Analysis 30.4.04: RNC reaction unclear, if UE sends many events e1c in less

than 1s (Tortelli NEC)– UE trace and RNC IMSI-traces don’t match. Messages sent and visible in IMSI

trace are missing in mobile trace or have different sequence numbers. This may be a problem of the mobile not being able to trace simultaneously

18.4.04: Issue escalated. Traces of 14.5.04 from live network Berlin contain many UE attempts to go to 2G, despite radio conditions are claimed to be good. New item #24 opened. – 3G-2G handover scenario is not designed for overlay network. To be clarified

with VDF 19.11.04: CR738 not sending any more video calls in compressed mode is

released in UMR30.10. Has been verified in TMD labs

7

Case3: NodeB compressed mode deactivation failure

Short description:In TIM (Palermo), randomly during 2G3G ISHO, the RNC sends correctly the

command to leave compressed mode to the UE and the NodeB, however the NodeB remains in CM mode and the call drops. This issue was found also in TMD labs after a few days of operation. When the NodeB entered this state, the NodeB did not leave any more the CM mode. SW in TIM UMR30.07

Progress/Applied actions: 5.11.04: The NodeB was traced with channel card trace in field and the issue

reproduce. FEKAT DA3643 19.12.04: During AMR calls compressed mode for GSM measures is activated

correctly due to radio conditions. Speech quality in UL/DL is good. Event 2f is triggered by UE and then RNC sends to de-activate CM mode:– Compressed mode command to NodeB– Measurement control to UE

NodeB does not deactivate compressed mode, i.e. downlink frames are sent with compressed mode still active. The CRCs are mainly not correct and this causes UL SIR target increasing (OLPC) and consequently UE gets to its max power. The speech quality in UL path decreases and sometimes the call is released.

Solution in UMR30.10A with NBL9_54_3

8

Case4: RL failure during rapid CM activation/de-activation

Short description:15.12.04: VDF-D2 KPI testing in Berlin with Motorola UE and UMR30.10. The UE

asks frequently to de-activate and activate the compressed mode respecting the parameters set by the system, e.g. time to trigger. Very often this results in a call drop. FEKAT DA4576

Analysis: The current NodeB implementation does not allow to activate the radio link

reconfiguration procedure (RAB assignment handling or Activation of compressed mode) during the deactivation of the compress mode

When the Commit message is received by the NodeB before the activation time expires, a double radio link failure is triggered.

Consequently the RNC deletes the Radio links and the UE has to send a Cell Update (Cause: RL-Failure) to re-establish the call. This causes around 8 seconds of missing voice

The RNC should not ask NB to activate CM mode again, during a pending procedure of de-activation.

A partial solution for UMR3.5 could be to use different Δ-values for activation time for activating and de-activating CM mode (currenty 128 frames)

128 frames is quite long and takes into account long processing time of NodeB

9

NB in compressed mode CFN=x-Δ

NB in compressed mode UE in compressed mode

Case4: RL failure during rapid CM activation/de-activation

TerminalRNC

CM Command( CFN=x)

Synch RL Reconf Prep The problem occurs when the Commit message is received before the activation time expires

Measurement Report 2f (deact CM)

Measurement Control (CFN=x)

Physical Channel Reconfiguration

Measurement Report 2d(activ. CM)

RL Failure(synch-Failure)

Cell Update (RadioLinkFailure)

UE requests removing compress mode

UE requests compress mode

RL deletion

RL Failure(unspecified)

RL deletion

Synch RL Reconf PrepRNC orders NB to go to CM mode at CFN x-Δ Synch RL Reconf

Commit (CFN=x-Δ)

Act

ivat

ion

time

NodeB

NB shall go in CM mode, while removing CM mode is still in progress CFN=x

CFN=x-Δ

10

Case4: Work Around (proposed 23.12.04)

The purpose of these changes is to delay a new request from the UE to go in compress mode– Increasing the time to trigger for event 2d from 200ms to 640 ms (was not accepted by

VDF)– Increasing the distance between the thresholds for 2f and 2d from 2dB to 4dB. VDF has

chosen a difference of 6 dB, which is ok

Original values used by VDF-D2:Event2f:-threshold -96 rscp-HysteresisInterFreq 4-TimeToTrigger 640 msEvent2d:-threshold -98 rscp-HysteresisInterFreq 4-TimeToTrigger 200 msEvent3a:-threshold -102 rscp-HysteresisInterFreq 0-TimeToTrigger 60 ms

New Values proposed:Event2f:-threshold -95 rscp-HysteresisInterFreq 4-TimeToTrigger 640 msEvent2d:-threshold -99 rscp-HysteresisInterFreq 4-TimeToTrigger 640 msEvent3a:-threshold -102 rscp-HysteresisInterFreq 0-TimeToTrigger 60 ms

Values used by VDF-D2 (January):Event2f:-threshold -92 rscp-HysteresisInterFreq 4-TimeToTrigger 1280 msEvent2d:-threshold -98 rscp-HysteresisInterFreq 4-TimeToTrigger 200 msEvent3a:-threshold -102 rscp-HysteresisInterFreq 0-TimeToTrigger 60 ms

11

Case4: Workaround for “Motorola problem” (10.2.05)

10.2.04: submitted to VDF-D2 as solution, but the error persists. Reduction of the activation time margin for the compressed mode from

1280700 ms– Has been tested in Siemens labs for UMR3.0 and UMR3.5– Speeds up the time to de-activate and activate the compressed mode, time ∆t3– is a parameter in the minDB

Increase of time to trigger for e2d from 200ms320 ms– Siemens suggests this setting in addition, because it further reduces the problem, however

it would be acceptable to test the impact in field only for the activation time margin Changes are suggested to be implemented in BXN002 during the week (14.2.-

18.2.05)Values suggested by SAG (February):Event2f:-threshold -92 rscp-HysteresisInterFreq 4-TimeToTrigger 1280 msEvent2d:-threshold -98 rscp-HysteresisInterFreq 4-TimeToTrigger 200 ms320msEvent3a:-threshold -102 rscp-HysteresisInterFreq 0-TimeToTrigger 60 ms

12

NodeB: ToAws 30ms+ processing 40ms

NodeB: ToAws 30ms+ processing 40ms

UE RLC

NodeB: Processing 9ms

NodeB: Processing 9ms

NodeB RNC RLC

Delay over the air is 3 times TTI:3*40 ms

RLC receives ack

Tpoll = 260 ms

4 RLC PDU sent, e.g. PhyReconf for deactivation of CM. Last PDU includes Poll bit. One TB each 40 ms.

NodeB: ToAws 30ms+ processing 40ms

Last TB including the Poll bit may be corrupted as the previous TBs. Delay over the air 40 ms one TTI per direction.The UE does usually respond the ACK without any extra delay.

RLC must re-transmit the remaining 3 TB

which are lost.70 ms

9 ms

120 ms

70 ms120 ms

9 ms

If all 4 TBs are lost, 658ms are needed to complete re-transmissionExample: 4 TBs per RRC message (RAB setup is longer)Activation time must be >658ms to allow complete re-transmission of 4 TBs with Tpoll =260 ms

Sum: 658 ms

Case4: Relation Tpoll and Activation Time Margin

13

Case4: Customer explanation of activation time (UMR3.0)

Activation time margin for compressed mode– Acttc : marg_cprs , Siemens default 128 CFN– New proposal 70 CFN– Specifies the Compressed Mode Margin– Value range 0...255

Activation calculation time margin– Acttc : marg_acttc , Siemens default 128 CFN– Optimized value 96 CFN (already applied)– Specifies the Activation Time Calculation Margin to change DCH to DCH– Value range 0...255– Is used for RAB setup and is different from the one used for compressed mode

14

Case5: Wrong Transmission Gap CFN sent to UE

18.2.05– Rapid change of de-activation / activation of compressed mode in VDF-D2

(Berlin) leads occasionally to call drops– Traced in presence of Motorola– SW UMR30.11A

28.2.05– Motorola sends analysis to VDF, that the RNC randomly sends the wrong

transmission gap CFN (TGCFN) numbers to the mobileAnalysis:

– Normally needs about 50 tentatives of CM de-act/act. To trigger the problem, in that case, the RNC sends the previous activation time A (instead the new one B)

– Traces exist, where this happens also during the 1st activation of CM mode. Here it is unclear, from where the value a is derived

Status:17.5.05

– Solved with UMR35.08, no solution for UMR30

15

Case5: Wrong TGCFN values sent to UE

NodeB TerminalRNC

Synch. RL-Reconfig.Prep.

Physical Channel Reconfiguration (ActCFN, TGCFN1,TGCFN2,TGCFN3)

Measurement Report 2d

Cell Update (Unrecoverable Error)

Activation Time CFN = B TGCFN1 = A (should be B!)TGCFN2 = A (should be B!) + 2TGCFN3 = A (should be B!) + 21

PhysicalChannelReconfigurationComplete

MeasurementControl

Synch. RL-Reconfig. Commit(ActCFN, TGCFN1,TGCFN2,TGCFN3)

Synch. RL-Reconfig.Prep.

UE starts loosing synchronization

1

2

Activation Time CFN = B (0-255)TGCFN1 = BTGCFN2 = B + 2TGCFN3 = B + 21

16

Case5: Wrong TGCFN values sent to UE

The compress mode procedure fails because the RNC sends wrong values for the TGCFN:

The activation time margin is correct but the TGCFN are wrongly calculated using the old value A of activation time margin (the one used in the previous Physical_Channel_Reconfiguration for compressed mode) instead of the new one B. This is sent to the UE.

The NodeB receives the correct transmission gap CFN-values

These wrong values lead to a compress mode runtime error in the UE if the following condition is not fulfilled:

– (Activation Time >= First TGCFN) AND (Activation Time <= First TGCFN+21)– UE reacts with a CellUpdate (unrecoverable error)

The UE condition explains, why it depends on the actual values of A and B, if the call drops

– We have traces, where the RNC sends the wrong TGCFNs, but the UE handles it

1

2

17

Case5: Default Parameter in Hidden Database

gap in the last 7 slots

gap in the f irst 7 slots 0 1 2 3

Default parameters in minDB 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

ro_strfrm tsgn tgl1 tgl2 tgd tgpl1 tgpl2 tgprc rpp itp

grssi_mesr 0 0 7 7 53 8 8 inf mode0 mode0

gsm_init 2 8 7 7 38 12 12 inf mode0 mode0

gsm_rcfm 21 8 14 14 undef 24 24 inf mode0 mode0

dl_ftyp dl_dsir1 dl_dsir1a dl_dsir2 dl_dsir2a ul_dsir1 ul_dsir1a ul_dsir2 ul_dsir2a niatb trabt

grssi_mesr a 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0

gsm_init a 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 24,0

gsm_rcfm a 0,0 0,0 0,0 0,0 0,0 0,0 0,0 0,0 5,0

formula correct wrong activation time CFN B B B

TG CFN1GSM Carrier RSSI Measurement

B+grssi_mesr B A

TG CFN2GSM initial BSIC Identification

B+gsm_init B+2 A+2

TG CFN3GSM BSIC Reconfirmation B+gsm_rcfm B+21 A+21

12

18

Case6: Combined Ec/No and RSCP not working with UEs

Short description: 23.3.04:

– VF-D2 issues RFI405 for the feature and proves (via Nokia implementation) a 1..2% less drop rate. Siemens issues CR754 released in UMR35.08 patch 648

– Many UEs as Qualcomm chipset based 6200, 6250 (Z107, option fusion card) do not support the implementation

Impact on network: 18.5.05:

– If the feature is activated, the calls will drop with the (majority) of UEs not supporting it

– Motorola, Ericsson, Nokia UEs support our implementation???Analysis: 18.5.05:

– RNC configures 2 measurement control commands e3a (one for Ec/No, one for RSCP), not including the GSM neighbor list in the second one

– This implementation is 3GPP 25.331 compliant (2nd list is optional)– Qualcomm chipset based UEs require the second neighbor list– CR1093 issued to overcome UE limitation, however not yet approved

19

Case6: Combined Ec/No and RSCP not working with UEs

Measurement Report e2d

Physical Channel Reconfiguration

Physical Channel Reconf. Complete

Measurement Contr. e3a: criteria 1 and list of 2G cell

Measurement Contr. e3a: criteria 2 without list of 2G cell

Measurement Contr. fail:” Incomplete Configuration”

RNC NodeB UE

Call is dropped by the RNC

Compressed mode activation

1st measurement control to configure e.g.Ec/No criteria containing GSM neighbors

2nd measurement control to configure e.g.RSCP criteria not

repeating GSM neighbors

Qualcomm based UEs reject the 2nd control and the call drops. They

require to include in both e3a controls the neighbor list