TIM, VDF-D2

ISHO handover issues in CM mode

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

Communication

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

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

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)

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 issue

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

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

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

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

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

UE requests
removing
compress mode

RNC

Terminal

NodeB
NB in compressed mode

UE in compressed mode

Measurement Report 2f (deact CM)

CM Command( CFN=x)
Measurement Control (CFN=x)
Measurement Report 2d(activ. CM)
Synch RL Reconf Prep

RNC orders NB to
go to CM mode at
CFN x-
NB shall go in CM
mode, while
removing CM mode
is still in progress

Synch RL Reconf Prep

Synch RL Reconf
Commit (CFN=x-)

The problem occurs when

the Commit message is
received before the
activation time expires

Activation time

UE requests
compress mode

CFN=x-

NB in compressed mode CFN=x-

CFN=x

Physical Channel Reconfiguration

RL Failure(synch-Failure)
RL deletion
RL Failure(unspecified)
RL deletion
Cell Update (RadioLinkFailure)

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

10

Original values used by VDF-D2: New Values proposed:

Values used by VDF-D2 (January):

Event2f:
-threshold -96 rscp
-HysteresisInterFreq 4
-TimeToTrigger 640 ms
Event2d:
-threshold -98 rscp
-HysteresisInterFreq 4
-TimeToTrigger 200 ms
Event3a:
-threshold -102 rscp
-HysteresisInterFreq 0
-TimeToTrigger 60 ms

Event2f:
-threshold -92 rscp
-HysteresisInterFreq 4
-TimeToTrigger 1280 ms
Event2d:
-threshold -98 rscp
-HysteresisInterFreq 4
-TimeToTrigger 200 ms
Event3a:
-threshold -102 rscp
-HysteresisInterFreq 0
-TimeToTrigger 60 ms

Event2f:
-threshold -95 rscp
-HysteresisInterFreq 4
-TimeToTrigger 640 ms
Event2d:
-threshold -99 rscp
-HysteresisInterFreq 4
-TimeToTrigger 640 ms
Event3a:
-threshold -102 rscp
-HysteresisInterFreq 0
-TimeToTrigger 60 ms

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 ms
Event2d:
-threshold -98 rscp
-HysteresisInterFreq 4
-TimeToTrigger 200 ms320ms
Event3a:
-threshold -102 rscp
-HysteresisInterFreq 0
-TimeToTrigger 60 ms

11

RLC PDU sent, e.g. PhyReconf for

Case4: Relation Tpoll and Activation Time Margin4deactivation
of CM. Last PDU

includes Poll bit. One TB each 40 ms.

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

NodeB

NodeB:
ToAws 30ms+
processing 40ms

Tpoll = 260 ms
NodeB:
ToAws 30ms+
processing 40ms

NodeB: Processing 9ms

Delay over the air is 3 times

TTI:3*40 ms
NodeB:
ToAws 30ms+
processing 40ms

120 ms
NodeB: Processing 9ms

If all 4 TBs are lost, 658ms are needed to complete re-transmission

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

12

RNC RLC

70 ms

RLC must re-transmit

the remaining 3 TB
which are lost.

9 ms
120 ms
70 ms

9 ms
RLC receives ack
Sum: 658 ms

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

13

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

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 mobile

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

14

Solved with UMR35.08, no solution for UMR30

Case5: Wrong TGCFN values sent to UE

RNC

Terminal

NodeB
Measurement Report 2d

Synch. RL-Reconfig.Prep.
Synch. RL-Reconfig.Prep.

Activation Time CFN = B (0-255)

TGCFN1 = B
TGCFN2 = B + 2
TGCFN3 = B + 21

Synch. RL-Reconfig. Commit

(ActCFN, TGCFN1,TGCFN2,TGCFN3)

Activation Time CFN = B

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

Physical Channel Reconfiguration

(ActCFN, TGCFN1,TGCFN2,TGCFN3)

PhysicalChannelReconfigurationComplete
MeasurementControl

UE starts loosing
synchronization

15

Cell Update (Unrecoverable Error)

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
1
Physical_Channel_Reconfiguration for compressed mode) instead of the new
one B. This is sent to the UE.
2 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

16

Case5: Default Parameter in Hidden Database

17

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

18

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

RNC

NodeB

UE

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

Call is dropped by the RNC

19

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