Call Trace Troubleshooting Examples - Several Releases

Section 5
Troubleshooting CTg Based

CTg Post Processing - Internal tool demo
Index
> CTg Troubleshooting Analysis
Accessibilty
Mobility
Retainability
Quality
Traffic
Congestion/Load
> CTg Post Processing - Internal tool demo
RRC accessibility troubleshooting

CT based
Example 1 (1/4)
RRC Failure cause 3 - Unspecified
> Problem description
One operator has experienced sometimes a high number of
RRC.FailConnEstab.3 (cause: unspecified). Below you can see in
example the results coming from on RNC during one week.
These failures were localized in some FddCells, on which we have
activated a CTg on the 9th of August.
Example UA4.1
(Other operator)
5
Example 1 (2/4)
Call Flow:
The RNC does not get any answer from the

NodeB, and it rejects the RRC Connection.
The 30 seconds delay corresponds to the
NBAP dedicated guard-timer (defined in the
static MIB). During this period no other
NBAP procedure may take place, leading
potentially to dropped calls.
From DRF we have seen that one of the sites involved is:
Example UA4.1
(Other operator)
Example 1 (3/4)
Call Flow:
The site 3471 has a known

problem with the BT link,
that goes up and down.
Example UA4.1
(Other operator)
Historical Fault Browser:
Example 1 (4/4)
>Conclusions
The counter RRC.FailConnEstab.3 (cause:
unspecified) is incremented when an RRC
Connection Reject (cause: unspecified) is sent
from the RNC to the UE. This happens when the
RNC receives no answer, from the NodeB, to a
Radio Link Setup Request.
A possible root cause of this can be an
hardware issue, as a link not stable.
Example 2 (1/7)
PS RRC Burst of failures
> Problem description
Burst of PS Failures in RRC.FailConnEstab.2 counter.

Consider the following counter related to Originating Interactive Call:
RRC.FailConnEstab.2 = RRC.AttConnEstab.2 RRC.SuccConnEstab.
Usually the number of failures is very low, but sometimes happens a cell is affected by a
burst of failures. The cell is almost randomly every time, so this suggests a UE issue.
Sometimes this problem cause a lot of failures (>100 in a 15 minutes period) on the cells
X, but also is present, with less percentage, in the neighbours of cell X.
> Detection
Activate an alarm with quarter of hour granularity:

RRC.Fail.2 + RRC.Fail.14 > 100 [FddCell, Quarter of Hour]=> ALARM!
> Investigation
Once time the alarm appears on the Alarm Monitoring, the following is a needed:
Activate an OTCell Trace in the cell identified by the alarm (1 hour)
Possibility also to activate Iub trace in this cell to find the IMSI
To execute ASAP the command usgsnCollectDataBase with debug access on OS CLI. It

must be done on each USC. This will provide two files (mmContexts and pdpContexts).
These tables are deleted each purgeMinAge hours (presently this parameter is set to
168h)
Process the OTCell Trace in order to find the PTMSI of the mobile causing the problem
(assuming that its due only to one mobile)
Associate the PTMSI found with the IMSI, using the two files collected
9
Example 2 (2/7)
Alarm
> Alarm generated for the period 13:30 13:45

> Alarm raised at about 13:55
> CTg (ID 27) activated at 14:00 for one hour in the cell
3496 sec3.
Example UA4.1
(Other operator)
10
Example 2 (3/7)
CTg Analysis
Example UA4.1
(Other operator)
CTg Results:
C all_ID
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
11
O utput
Access Fail ure
Access Fail ure
Access Fail ure
Access Fail ure
Access Fail ure
Access Fail ure
Access Fail ure
Normal T raffic Release
Access Fail ure
Access Fail ure
Access Fail ure
Access Fail ure
Access Fail ure
Access Fail ure
TimeInt
Durati on
14:01:20.002
6.045
14:04:21.806
4.08
14:05:13.617
4.08
14:05:51.725
4.06
14:06:36.845
4.06
14:09:28.694
4.06
14:10:16.566
4.06
14:10:54.386
1.26
14:11:31.413
4.06
14:12:50.583
4.06
14:14:44
4.08
14:15:28.252
4.08
14:16:14.112
4.08
14:17:17.702
4.08
14:25:37.898
4.38
14:34:58.866
4.18
14:45:57.723
3.92
14:56:15.017
4.2
T_MSI
P_TMSI
18 00 6e 95
UNK
18 00 6e 95
UNK
18 00 6e 95
UNK
18 00 6e 95
UNK
18 00 6e 95
UNK
18 00 6e 95
UNK
18 00 6e 95
UNK
26 00 c7 b0
UNK
18 00 6e 95
UNK
18 00 6e 95
UNK
UNK
0b 13 39 3f
UNK
0b 13 39 3f
UNK
0b 13 39 3f
10 01 9e e2
UNK
30 00 c3 40
UNK
0e 02 48 de
UNK
56 00 6d c3
UNK
4c 00 35 2f
UNK
Issue captured by CTg
Typical Call Flow of an AF:

Time
14:05:13.617
14:05:13.617
14:05:13.637
14:05:13.657
14:05:13.677
14:05:17.677
14:05:17.697
Channel
SnapshotCNode
SnapshotCNode
Nbap
Nbap
Rrc
Nbap
Nbap
Message
SnapRrcStart
SnapRLinkStart
NbapRadLinkSetupReq
NbapRadLinkSetupResp
RrcConSetup
NbapRadLinkDelReq
NbapRadLinkDelResp
Example 2 (4/7)
Counter Analysis
Example UA4.1
(Other operator)
12
Example 2 (5/7)
First comments
Example UA4.1
(Other operator)
> The Call Flow its the normal one you have in cases of
RRC Repetitions. Note that the CTg considers each RRC
Repetition as a new call, with a different TK.
> Despite the fact we have had 112 failures during the
quarter 14:00 14:15, the CTg has been able to capture
just 10 AF.
> The agreed procedure was to purge immediately the
SGSN, in order to get the IMSI from the P-TMSI. But in
reality the UE is giving its TMSI. Indeed the spec confirms
that, also in case of PS Calls (in this case Originating
Interactive Calls), the TMSI is passed (see backup slide).
13
Example 2 (6/7)
USGSN Collected Database
> Collect the data from the SGSN
> P-TMSI: 0b13393f
> IMSI: 234159026600909
Example UA4.1
(Other operator)
14
Example 2 (7/7)
Backup Selection of initial UE identity
> The purpose of the IE "Initial UE identity" is to provide a unique UE
identification at the establishment of an RRC connection. The type of
identity shall be selected by the UE according to the following.
> Upper layers shall set the variable SELECTED_PLMN. If the variable
SELECTED_PLMN in the UE indicates "GSM-MAP", the UE shall
choose "UE id type" in the IE "Initial UE identity" with the following
priority:
1. TMSI (GSM-MAP): The TMSI (GSM-MAP) shall be chosen if available.
The IE "LAI" in the IE "Initial UE identity" shall also be present when TMSI
(GSM-MAP) is used, for making it unique.
2. P-TMSI (GSM-MAP): The P-TMSI (GSM-MAP) shall be chosen if
available and no TMSI (GSM-MAP) is available. The IE "RAI" in the IE "Initial
UE identity" shall in this case also be present when P-TMSI (GSM-MAP) is
used, for making it unique.
3. IMSI (GSM-MAP): The IMSI (GSM-MAP) shall be chosen if available and
no TMSI (GSM-MAP) or P-TMSI is available.
4. IMEI: The IMEI shall be chosen when none of the above three conditions
are fulfilled.
15
Example 3
PS RRC burst due to mobile issue
> A single user can create more than 3000 PS RRC failures in 1 hour
( number depends on the user that may switch off the data card or
force it to camp in GSM)
> Traces confirm that what was captured with PrOptima refers to a
single user. P-TMSI were tracked down, the UE turned out to be a the
same data card in both cases. IMEI TAC for this (351969) shows it is
an Option colt 3G card which are actually old products
> When an old Data card comes to UMTS ( from 2G), it will create
hundreds of RRC failures that creates a huge degradation on the
serving cell RRC PS metric and even affects the RNC RRC PS metric
during a short time (usually less than 1 hour)
> Old data cards not supporting SCCPCHclassid = 1 was the final
reason of these failures
PSStreamingFail_Ca
ll_FlowCompa...
16
Example UA4.2
(Other operator)
Retainability troubleshooting
Astelia Trace Analyzer based
Example 2 (1/4)
The Blackberry (RIM) behaviour
UE
SGSN
RNC
Service Request (Data)
Security & Authentication Function
RAB Assignment Request

RAB Assignment Response
Data transfer: about 3.5 sec
RRC: Signaling
Connection Release
Indication
RRC: Release
RRC: Release Complete
18
Iu Release Request: UE
Generated Signaling
Connection Release
Iu Release Command
Iu Release Complete
Example UA4.2
(Other operator)
Periodically, the blackberry reestablish the
connection to the Network for small data
transfer (about 3.5sec).
When the data transfer is finished, the UE
originates a RRC Release with the
message RRC: Signaling Connection
Release Indication (as explained in 3GPP
TS 25.331 8.1.14
When receiving this message, the RNC
initiates a Iu Release Request, with cause:
UE Generated Signaling Connection
Release
This is considered by Nortel as an
abnormal release and thus, the following
counters are pegged:
VS.IuAbnormRelReq (#547) at Cell level
VS.IuAbnormalReleaseRequest (#534) at
RNC level
According to previous formulas, this
behavior is considered as a drop PS !
There is a wrong information is NTP 4118111-822, Table 51: the cause is included
in abnormal release, whereas NTP says
the opposite
Example 1 (2/4)
Impact of the Blackberry behaviour on the 24th
>60% of the
drops on the 24th
are generated by
only 9 UEs.
>8 UEs have the
blackberry
behavior
Example UA4.2
(Other operator)
The cause UE Generated
Signaling Connection Release is
responsible of 57% of the
abnormal releases
19
1 is a Motorola
UE (by IMEI)
not supporting
the granted
RAB (capability
check feature
was not
activated on
this RNC)
Example 1 (3/4)
The IMSI 206105100465005 behavior
UE
SGSN
RNC
Attach Request (Follow-On pending)
Security & Authentication Function
Attach Accept
Attach Complete
Activate PDP Context Request
RAB Assignment Request

RRC: RB Setup
RRC: RB Setup Failure
RAB Assignment
Response: Failure in Radio
Interface Procedure
Iu Release Request:
Failure in Radio
Interface Procedure
After successful Attach procedure, the UE

tries to activate a PDP Context
The SGSN sends a RAB Assignment to the
RNC
The RNC sends the RB Setup message to
the UE
The default RB allocated by the RNC is
UL128 and DL384, which is not supported
by this UE.
The flag
isUeCapabilitiesinRabMatchingAllowed was
set to false on this RNC by this time: the
RNC allocates a RB that is not supported
by the UE
The same procedures fails 71 times in
a row between 01:50AM and 09:50AM
Activate PDP Context Reject

RRC: Release
RRC: Release Complete
20
Iu Release Command
Iu Release Complete
Example UA4.2
(Other operator)
Example 1 (4/4)
The Blackberry (RIM) behaviour
> In order to remove the Release99 PS Drops "invented" by Black Berry 8707 mobiles
> mbk_42_Iu008_Fcell&RNC_PS R99DL%Iu Abnormal Release Request
061024 BRL
reduced by
'VS.IuReleaseRequestPs.UeGeneratedSignallingConnectionRelease'[FddCell,Time]
because of RIM 8707
>
> mbk_42_Iu008_Fcell&RNC_PS%Iu Abnormal Release Request
061024 BRL
reduced by
'VS.IuReleaseRequestPs.UeGeneratedSignallingConnectionRelease'[FddCell,Time]
because of RIM 8707
>
MBK metrics
21
3G 2G Mobility troubleshooting
CT based
3g->2G HO failures in one RNC
Example 1. 3g->2G HO failures in one RNC (1/6)

Preparation And Execution Phases CS HHO 3G2G
CS 3G2G HHO RNC503

100.00%
The HHO success

metric is bad
because of the
preparation phase
95.00%
90.00%
85.00%
80.00%
75.00%
27/02/06 28/02/06 1/03/06
2/03/06
3/03/06
4/03/06
5/03/06
Preparation Success Rate
24
6/03/06
7/03/06
8/03/06
9/03/06 10/03/06 11/03/06 12/03/06
Execution Success Rate
Example UA4.2
(Other operator)
Example 1 (2/6)
CTG on RNC before changing MSC timer
25
time
17:47:20.096
17:47:20.570
17:47:20.930
17:47:21.410
17:47:21.930
17:47:22.410
17:47:22.930
17:47:23.410
17:47:23.930
17:47:23.931
17:47:23.932
17:47:24.414
17:47:24.414
17:47:24.682
17:47:24.683
17:47:25.856
17:47:25.857
17:47:25.919
17:47:26.611
17:47:26.611
17:47:26.612
17:47:26.663
17:47:27.135
17:47:27.614
17:47:27.615
17:47:27.666
17:47:28.089
17:47:28.611
17:47:28.612
17:47:28.669
17:47:29.130
17:47:29.614
17:47:29.620
17:47:29.620
17:47:30.135
17:47:30.377
17:47:30.615
17:47:31.091
17:47:31.570
17:47:31.570
17:47:32.091
17:47:32.091
17:47:32.569
17:47:32.570
17:47:33.090
17:47:33.091
17:47:33.092
17:47:33.573
17:47:33.574
17:47:33.780
17:47:33.781
17:47:33.781
17:47:33.781
message
NbapCompressedModeCommand
RrcMeasReport
RrcMeasReport
RrcMeasReport
RrcMeasReport
RrcMeasReport
RrcMeasReport
RrcMeasReport
RrcMeasReport
GSMMeas
RanapRelocReq
RrcMeasReport
GSMMeas
RanapRelocCmd
RrcHoFromUtranCmd
RrcHoFromUtranFail
RanapRelocCancel
RanapRelocCancelAck
RrcMeasReport
GSMMeas
RanapRelocReq
RanapRelocPrepFail
RrcMeasReport
RrcMeasReport
RanapRelocReq
RanapRelocPrepFail
RrcMeasReport
RrcMeasReport
RanapRelocReq
RanapRelocPrepFail
RrcMeasReport
RrcMeasReport
RrcMeasCont
RrcMeasReport
RrcMeasCont
RrcMeasReport
RrcMeasReport
RrcMeasReport
GSMMeas
RrcMeasReport
GSMMeas
RrcMeasReport
GSMMeas
RrcMeasReport
GSMMeas
RanapRelocReq
RrcMeasReport
GSMMeas
RanapRelocCmd
Change Value
Change State
RrcHoFromUtranCmd
comment
New pattern
The majority of preparation Failures

comes after a HHOfromUtran failure
towards GSM cellid 7C6F
Is like 2G resources were late released

several seconds after the HHO failur
cause :physical channel failure
More cases on:

1_exportHHOfail.zip

Cause of fail:Message not compatible with receiver state

After a Execution Fail,

all Relocation Attemps fails during 5 secs

New pattern
UMTS level above -100dBm
UMTS level below -100dBm

Success

Peformances on RNC after changing MSC Timer
to 1 sec
RNC503
100.00%
95.00%
90.00%
85.00%
After the change , there is a small

reduction of the preparation
failure but execution failure increases.
80.00%
75.00%
Globally on the metric 3g2g success

there is not much improvement
70.00%
65.00%
60.00%
17 Apr 06 18 Apr 06 19 Apr 06 20 Apr 06 21 Apr 06 22 Apr 06 23 Apr 06 24 Apr 06 25 Apr 06 26 Apr 06 27 Apr 06 28 Apr 06 29 Apr 06 30 Apr 06
41_HHO 3G2G CS Execution Success Ratio
26
41_HHO 3G2G CS Preparation Success Rate

CTG on RNC After changing MSC timer (1)
still 1 residual preparation failure after a RRC_HHOFail
12:27:17.557
12:27:17.558
12:27:17.622
12:27:17.837
12:27:17.837
12:27:17.837
12:27:17.838
12:27:17.918
12:27:18.314
12:27:18.315
12:27:18.315
12:27:18.834
12:27:18.834
12:27:18.834
12:27:18.835
12:27:19.314
12:27:19.314
12:27:19.314
12:27:19.621
12:27:19.622
12:27:19.622
12:27:19.622
12:27:19.834
12:27:19.834
12:27:19.834
12:27:21.370
27
RrcUL-DCCH
Ranap
Ranap
RrcUL-DCCH
Rrc
Rrc
Ranap
Ranap
RrcUL-DCCH
Rrc
Rrc
RrcUL-DCCH
Rrc
Rrc
Ranap
RrcUL-DCCH
Rrc
Rrc
Ranap
Internal
Internal
RrcDL-DCCH
RrcUL-DCCH
Rrc
Rrc
Ranap
RrcHoFromUtranFail
RanapRelocCancel
RanapRelocCancelAck
RrcMeasReport
intraFrequencyMeas
GSMMeas
RanapRelocReq
RanapRelocPrepFail
RrcMeasReport
intraFrequencyMeas
GSMMeas
RrcMeasReport
intraFrequencyMeas
GSMMeas
RanapRelocReq
RrcMeasReport
intraFrequencyMeas
GSMMeas
RanapRelocCmd
Change Value
Change State
RrcHoFromUtranCmd
RrcMeasReport
intraFrequencyMeas
GSMMeas
RanapIuRelCmd
physical channel failure
HHO failure due to radio
[503 CI: 9722] [ 72:-8 dB -110dBm 1:33791] [ 88:-10 dB -112dBm 1:33023] {IRAT 12
PRIMARY: 72, ACTIVE: 88,
MSC timer =1sec
Will succeed since
MSC timer has expired
Flag set to: TRAFFIC_CS

[ TRAFFIC CS --> 3G to 2G HHO CS ]
BCC : 3 NCC : 5 BCCH_ARFCN : 104
Successful Relocation
HHO is performed earlier

than with a MSC
timer of 5 secs

CTG on RNC503 After changing MSC timer (2)
time
12:27:03.000
12:27:02.599
12:27:02.603
12:27:02.606
12:27:03.114
12:27:03.595
12:27:04.117
12:27:04.000
12:27:04.598
12:27:04.855
12:27:04.856
12:27:06.518
12:27:06.519
12:27:06.572
12:27:06.878
12:27:07.394
12:27:07.396
12:27:07.878
12:27:08.207
12:27:08.207
12:27:08.394
12:27:09.639
message
RrcMeasCont
RrcMeasCont
RrcMeasCont
RrcMeasReport
RrcMeasReport
RrcMeasReport
RanapRelocReq
RrcMeasReport
RanapRelocCmd
RrcHoFromUtranCmd
RrcHoFromUtranFail
RanapRelocCancel
RanapRelocCancelAck
RrcWrongPdu
RrcMeasReport
RanapRelocReq
RrcMeasReport
RanapRelocCmd
RrcHoFromUtranCmd
RrcMeasReport
RrcHoFromUtranFail
Comment
[503 CI: 9722] S3[InterRAT]: compres mode activation cellid=12 is sent with bcch=101
Verified bsic=12 ( then is bcch=101) is the strongest GSM cell reported

Reloc Req to GSM cellid 54984 that has freq 101 on drfs
[503 CI: 9722] [ 72:-7 dB -108dBm 1:33792] [ 88:-9 dB -109dBm 1:33023] {IRAT 12:-87}{IRAT 9:-98}{IRA
Decoding NAS part indicated that bcch is 104 !!: GSM Core has this Cell id 54984 provisioned with freq 10
HHO to BCCH=104 ( CoreNAS data encapsulated) but this frequency is not the one measured by the UE
physical channel failure since bcch104 is not the one measured
Same Verified bsic=12 ( then is bcch=101) GSM cell is reported
HHO to BCCH=104 ( CoreNAS data encapsulated) but this frequency is not the one measured by the UE
cause physical channel failure that is logical
This and more cases on :

1_exportHHOfail_afterchangingMSCtimer.zip
28

Conclusion
> We are used that a 2G datafill problem creates a HHO
preparation failure. This is the case when for example a BSC
changes of LAC and is not updated on 3G side so that the
MSC3G can not find the target BSC and sends a preparation
failure to the RNC
> Nevetheless the last scenario of HHO shows that when LAC
and Cellid is the same in 3G&2G but bcch is different on 2G, the
RNC will send a RR HHO to a bcch not measured by the UE
creating an HHO execution failure.
> In such a scenario , the change of MSC from 5 secs to 1 sec
can only exchange some preparation failure by execution failures
29
Example UA4.0
(Other operator)
HHO Analysis and Troubleshooting

Nice presentation (very big) necessary to filter slides.
It contains Counter analysis + CTg
V1.01
Content
> HHO Metrics-General Status
> HHO Preparation Analysis and Results
> CTG Analysis and Results
Relocation Preparation Failures
Physical Synchronization GSM Channel Failures
> Action Points
31
HHO Metrics-General Status

Road Map
CS 3G2G Mobility Analysis
Network level
Counters
Preparation part

RNC level
Counters
32
Action
CS 3G2GPreparation
Analysis Cell level
Counters
Action
CS 3G2GPreparation
Analysis Selected Cells
CTG Odinium
Low rate execution part 2G side

RNC level
Counters
CTG Odinium Analysis

was done on RNC6
General Issue Found for
go to page 44

Counter&Formulas
#0109 3g to 2g ho detection from fddcell

Measurement Report
#0521 Iu relocation required

#0524 Iu relocation command
#0101 HO from UTRAN command
#0505 Iu Release Command
33

Counter&Formulas
#0101 HO from UTRAN command
#0103 HO From UTRAN Failure
34

Counter&Formulas
35

Counter&Formulas
Global HHO 3G2G CS success rate = (#0505.[1]) / (#0109.[0,2])
3G2G CS HHO preparation success rate at RNC level =
(#0101[0] + #0102[0]) / (#0109[0] + #0110[0])
3G2G CS HHO preparation success rate at Cell level =
(#0101[0] / (#0109[0] )
HHO 3G2G CS Execution Success Rate =
(#0505.[1]) / (#0101[0] + #0102[0])
HHO 3G2G CS Execution Success Rate - 3G side =
(#0505.[1]) / (#0101[0] + #0102[0] - (#0103[0] + #0104[0] ))
HHO 3G2G CS Execution Success Rate - 2G side =
1 - (#0103.[0]+#0104.[0]) / (#0101.[0]+#0102.[0])
36

Graphs-Network Level
HHO Metrics All RNCs
3gto2gHoDetectionFromFddcell
ALL
35000
100%
95%
90%
85%
80%
75%
70%
65%
60%
55%
50%
30000
25000
20000
15000
10000
5000
04/06/2005
03/06/2005
02/06/2005
01/06/2005
31/05/2005
30/05/2005
29/05/2005
28/05/2005
27/05/2005
26/05/2005
25/05/2005
24/05/2005
23/05/2005
22/05/2005
21/05/2005
20/05/2005
19/05/2005
18/05/2005
17/05/2005
16/05/2005
3G2G CS HHO preparation

success rate at RNC level ALL
HHO 3G2G CS Execution
Success Rate ALL
Success Rate - 2G side ALL
Success Rate - 3G side ALL
HHO 3G2G CS success rate ALL
All the metrics indicate a constant behavior of the 3G2G HHO events
Average HHO 3G2G Cs Success Rate is 76.86% 1.41 (too low mainly cause by low execution
success rate ).
Average HHO 3G2G Cs Preparation Success Rate is 94.35% 0.64. Can be Improved!
Average HHO 3G2G Cs Execution Success Rate is 81.82% 1.24. Network has good Execution
Success rate in 3G, averaging 96.16% 0.35, but is bad for the Execution Success Rate in 2G
85.09 1.07
37

Road Map
Network level
Counters
Preparation part

RNC level
Counters
38
Action
CS 3G2GPreparation
Analysis Cell level
Counters
Action
CS 3G2GPreparation
CTG Odinium

RNC level
Counters

was done on RNC6
go to page 44

Graphs-RNC Level
No related with any holyday

Or Special Event on the RNC
39

Graphs-RNC Level
Excellent Preparation and
Execution Rate in 3G
Possible Network event in 2G

or User event
Low Execution Rate
In 3G and 2G
40

Graphs-RNC Level
Excellent General Performance
Regular Preparation Success Rate
41

Graphs-RNC Level
Low Preparation Success Rate
Regular Preparation Success Rate
42

Summary
> Very low 3G2G Success HHO Rate on the network.

(76.86% )
> High number of failure in the 3G2G HHO during the
execution stage on 2G.
> RN6,7,8 need deeply analysis on the Preparation process
(low rate).
> Excellent performance of the RNC5 in the 3G2G HHO
> RNC3 HHO performance was drastically reduce during the
first 6 days of the evaluation.
43
HHO Preparation Analysis and Results

Road Map
Network level
Counters
Preparation part

RNC level
Counters
RNC6,7,8 Affected
44
Action
CS 3G2GPreparation
Analysis Cell level
Counters
Action
CS 3G2GPreparation
CTG Odinium

RNC level
Counters
All RNCs except No.5
was done on RNC6
go to page 44

Criteria and procedures
> Counter Evaluation based on 20 days data (weekend included).
> Analysis is done for all RNCs (All FDD Cells) in order to detect possible
problems (not only for the 3 worst RNCs).
> Analysis basically consist in Correlate the Number HHO detected with
the Preparation Success Rate and Get the Distribution by Number of
FDD Cells (CDF and PDF Graphs).
> Once Worst Cells (low Preparation Success Rate) are detected (using the
mean value of the period), Graphical evaluation is done in each cell who
present wrong performance.
> Cells with low Preparation Success Rate are only considered for
evaluation. Cells with HHO Detection over 19(avg/day) are consider
critical.
> Additionally, was evaluated the HHO relocation Commands Failure
screened by:
45
Relocation time-out
Relocation already in progress
Relocation failure in target system
Relocation unable to establish
Other Relocation failure

PDF and CDF Results RNC1
Comments:
No Screening for Relocation Command Failures, Only Other Relocation Failures
Low Avg HHO Detection 3G2G counted for All Cells: Max[22.16] and Min[0.05]
Only 1 cell over 19 of HHO Detect with Good HHO Prep Success Rate.
No Problematic cell were founded.
Notes:
PDF: Probabilistic Distribution Function
CDF: Cumulative Distribution Function)
Prep Suc Rate (Avg): 3G2G Cs HHO Preparation Success Rate Fdd Cell Level
46

Comments:
Low Avg HHO Detection 3G2G counted for All Cells: Max[23.74] and Min[0.05]
5 cells over 19 of HHO Detect with Good HHO Prep Success Rate.
1 Cell was considered for evaluation
Notes:
Prep Suc Rate (Avg): 3G2G Cs HHO Preparation Success Rate Fdd Cell Level
47

FDD Cell Graphs RNC2
Comments:
Attempts are not constant during this period but some days de rate fall down
48

Comments:
Avg HHO Detection 3G2G counted for All Cells: Max[198.4] and Min[0.05]
35 cells over 19 of HHO Detect with Good HHO Prep Success Rate
between [91-100%]
One FDD Cells was consider for further analysis (0%).
Notes:
49Prep Suc Rate (Avg): 3G2G Cs HHO Preparation Success Rate Fdd Cell Level

Comments:
No HHO relocation Commands for this cell even there were HHO Detection
50

Comments:
Avg HHO Detection 3G2G counted for All Cells: Max[47] and Min[0.05]
between [95-100%] and 1 cell with 79%
Notes:

Looks like HHO Parameters Change
52

Comments:
between [95-99%]
No Problematic cell were founded.
Notes:

Comments:
between [91-98%] and 2 cells with 83% and 90%
4 Problematic cell were founded.
Notes:

Comments:
3G2G preparation success rate is constant trend line is following the main value (83%), need further investigation
55

56

57

Comments:
between [92-98%] and 6 cells problematic cells with {61,63,73,77,78,81}
Respectively.
Notes:

59

60

Comments:
between [91-100%] and 2 cells problematic cells with {90%}
Respectively.
3 problematic cells were found
Notes:

62

63

Summary
> The Following FDD Cells have the worst 3G2G HHO
preparation Success Rate:
> CTG was schedule for further Investigation

64
CTG Analysis-Preparation Relocation Failures

Road Map
Network level
Counters
Preparation part

RNC level
Counters
RNC6,7,8 Affected
65
Action
CS 3G2GPreparation
Analysis Cell level
Counters
Action
CS 3G2GPreparation
CTG Odinium

RNC level
Counters
was done on RNC6
go to page 44

Criteria and procedures
> CTG Scheduled for 4 hour on the Selected Node Bs.
> HHO in other cells were counters for the general Statistics results
> Analysis basically consist in Correlate the incidences of an specific
pattern of failures by 3G cell , Target GSM Cell.
> Analysis of each Call flow was focus only on the HHO preparation
Failures. Failure during the execution were not considered but counted
for the general statistics results.
66

Statistics Results-by Call Events
Notes:
-.Hhoff (Multiservice): CS12V+SBR
(LAU, RAU or Both).
-.There were 26 FddCell with success
HHO not displayed but included in the
total account. Because they were not
included in the List for CTG
67

Statistics Results-HHO Call Events Failures Distribution
68
Notes:
-.DifGSM ch: Different GSM Target Channel
-.SameGSMch: Same GSM Target Channel

Statistics Results by Attempts
Notes:
-.There were 26 FddCell with success
HHO not displayed but included in the
total account. Because they were not
included in the List for CTG
69

Statistics Results 3Gcell vs 2G Target Cell
Notes:
-.Only cells with HHO prep failure were
displayed
70

Statistics Results Summary
71

Statistics Results Summary (Cont.)
> 9 GSM Cells were found with not Success HHO or too low (Possible
wrong parameter settings between GSM and UMTS).
> All HHO prep Failures attempts were mapped with Unspecified cause.
no Congestion or Timer Expiration were found.
> 42% of the HHO Call Events Failures were success with the same GSM
Cells. They are 13 cells and need further investigation (Possible Issue).
> 3 cases found were RNC didnt use the new GSM Cell reported (using
previous target cell) even there is a Relocation Cancel before.
> 4 cases found were RNC required the Relocation without any GSM cell
reported (using previous target cell), even there is a Relocation Cancel
before.
72
CTG Analysis- Physical Synchronization GSM Channel

Failures
Road Map
Network level
Counters
Preparation part

RNC level
Counters
RNC6,7,8 Affected
73
Action
CS 3G2GPreparation
Analysis Cell level
Counters
Action
CS 3G2GPreparation
CTG Odinium

RNC level
Counters
was done on RNC6
go to page 44

Failures
Analysis in one RNC during 1 hour
74

Failures
Table Causes
> All Failures (any Cause) happened during the Synchronization of the
GSM Channel: Ue return to Utran with rrcUtranCommandFailure
Cause: Physical Channel Failure
75

Failures
HHO3G2G Failure on 2G UE Detection
76

Failures
Example 1 & 2, statistics
HHOFailure
Des cription.xls (13...
77
Caus e Analys is
RNC6 HHOAnalys i...
Action Points
> Troubleshoot on 2G the Physical Channel Failure:
Evaluate drive test data on 2G during the Handover
detection process for the mobiles currently used on the
network
> Evaluate or Verified the Configuration and Parameter for
the GSM cells detected.
> Get counter o data of HHO activity from the 2G side
(Access7, Counters, other) in order to detect were is failing
the Relocation when finally success in the same GSM cell.
78
Success HHO 3G2G process
79

Call Trace Troubleshooting Examples - Several Releases

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Call Trace Troubleshooting Examples - Several Releases

Transféré par

Droits d'auteur :

Formats disponibles

Section 5

Troubleshooting CTg Based

> CTg Post Processing - Internal tool demo

RRC accessibility troubleshooting

The RNC does not get any answer from the

The site 3471 has a known

Burst of PS Failures in RRC.FailConnEstab.2 counter.

Activate an alarm with quarter of hour granularity:

To execute ASAP the command usgsnCollectDataBase with debug access on OS CLI. It

> Alarm generated for the period 13:30 13:45

Issue captured by CTg

Typical Call Flow of an AF:

RAB Assignment Request

RAB Assignment Request

After successful Attach procedure, the UE

Activate PDP Context Reject

3g->2G HO failures in one RNC

Example 1. 3g->2G HO failures in one RNC (1/6)

CS 3G2G HHO RNC503

The HHO success

Preparation Success Rate

9/03/06 10/03/06 11/03/06 12/03/06

Execution Success Rate

The majority of preparation Failures

Is like 2G resources were late released

cause :physical channel failure

More cases on:

towards GSM cellid 7C6F

towards GSM cellid 7C6F

After a Execution Fail,

towards GSM cellid 7C6F

UMTS level above -100dBm

UMTS level below -100dBm

Example 1. 3g->2G HO failures in one RNC (3/6)

After the change , there is a small

Globally on the metric 3g2g success

41_HHO 3G2G CS Preparation Success Rate

Example 1. 3g->2G HO failures in one RNC (4/6)

physical channel failure

HHO failure due to radio

MSC timer =1sec

Will succeed since

Flag set to: TRAFFIC_CS

HHO is performed earlier

Example 1. 3g->2G HO failures in one RNC (5/6)

Verified bsic=12 ( then is bcch=101) is the strongest GSM cell reported

Same Verified bsic=12 ( then is bcch=101) GSM cell is reported

This and more cases on :

Example 1. 3g->2G HO failures in one RNC (6/6)

HHO Analysis and Troubleshooting

> Action Points

HHO Metrics-General Status

CS 3G2G Mobility Analysis

Low rate execution part 2G side

CS 3G2G Mobility Analysis

CTG Odinium Analysis

HHO Metrics-General Status

#0109 3g to 2g ho detection from fddcell

#0521 Iu relocation required

#0505 Iu Release Command

HHO Metrics-General Status

#0101 HO from UTRAN command

#0103 HO From UTRAN Failure