Documentos de Académico
Documentos de Profesional
Documentos de Cultura
TEMS log shows that signal is going down. RSCP and Ec/No is weak, RSSI is high Mobile is changing to idle mode. TEMS log and scanner information showing different SC. After Cell Reselection Ec/No situation is ok. See next pages for typical screen shot.
Page 2
2 transition to Idle
Mode 3 weak RSCP 4 strong RSSI 5 discrepancy betw. Scan & Ue 6 low SIR 7 high BLER 8 strong Ec/No after Cell Reselection
The call drops because the Ec/No is too weak, but after Cell Reselection, the Ec/No of a different Pilot is very good drop like in GSM !
Page 3
TEMS log shows that RF situation is good. No Pilot Pollution Low Ue Tx Power Call is dropped because RNC request Iu release with command IU release request Utran generated reason RNC sendet an UE RRConnction release-unspecified K1297 Iub traces shows in Common Measurement a high value (>70) for RTWP.
Reason & Solution
The high RTWP values represents a very high cell load for the nodeB, thus the admission and congestion control are not accepting call setup or call is very likely to be dropped after HO. Correction of Duamco Settings to right attenuation is solves problem.
Page 4
1 good Ec/No
2 good RSCP 3 no Pilot Pollution 4 low Ue TxPower 5 good SIR 6 low BLER 7 dl RRC Connection
Release
with Cause unspecified
Note: there is a difference in time between TEMS Scanner and TEMS Ue
The Call drops because the RNC requests an Iu-Release due to UTRAN generated reasons
Page 5
id-DirectTransfer id-ErrorIndication
RELCMP
rrcConnectionRelease rrcConnectionReleaseComplete initiatingMessage initiatingMessage initiatingMessage succesfulOutcome REL RLC RL DT1 RL RLSD RL RLC
cause = unspecified
id-Iu-Release
DUAMCO-setting:
TEMS log shows that RF situation is good. No Pilot Pollution Low Ue Tx Power Call is Rejected with reason Congestion. K1297 Iub traces show in Common Measurement a high value (>70 > -105dBm) for RTWP.
The high RTWP values represent a very high cell load for the nodeB, thus the admission and congestion control are not accepting HO or call setup. Even worse, the existing call(s) will be terminated if set so in the RNC database Correction of Duamco Settings to right attenuation.
Page 7
After the drop, a new call attempt is rejected byPage RNC 8 with Cause Congestion
id-DirectTransfer id-ErrorIndication
RELCMP
rrcConnectionRelease rrcConnectionReleaseComplete initiatingMessage initiatingMessage initiatingMessage succesfulOutcome REL RLC RL DT1 RL RLSD RL RLC
cause = unspecified
id-Iu-Release
New call is rejected by the RNC with cause Congestion. This irrational behavior of the RNC can be explained by the Congestion Control Algorithm which kicks in when RTWP is high and that is the case if the TMAgain is not compensated by the FeederLoss and Duamco.
Page 9
TEMS log shows that RF situation is good. No Pilot Pollution Low Ue Tx Power No RRC Release command received from UTRAN See next pages for typical screen shot Mobile is changing to idle mode without any motivation.
Must be a problem from mobile. (Qualcomm) Since Motorola Mobiles are available for TEMS, those Qualcomm problems shall not be considered any longer. (VDF Topphofen)
Page 10
conditions
2 good SIR 3 low BLER 4 no Pilot Pollution 5 no dl RRC Connection Release 6 transition to Idle Mode
The call drops although the RF-conditions are perferct a second Ue in parallel does not drop!
Page 11
TEMS log shows that RF situation is good. No Pilot Pollution Ue Tx Power increased No RRC Connection Release command received. See next pages for typical screen shot Mobile is changing to idle mode without any motivation.
Possible reasons Downlink Layer 2 RLC errors or synchronisation problems on Layer 1 Other UTRAN error (e.g. ALCAP Problem between MSC & RNC). K1297 traces from Iub and Iu Interface necessary.
Page 12
4 Good SIR
Before Failure: 5 High TxPower Normal Call Setup 7 low SIR 6 increased BLER
Transition to
Idle Mode
During Call Setup the Ue requests ActiveSet Update and goes into Soft-HO
Page 13
ActiveSet
Update during call Transition to Idle Mode After ActiveSet Update Complete no Measurement Control can be received from the UTRAN no Radio Bearer Setup setup
Page 14
es sa ge
i re ct io
ot oc ol
-E rro
tra SI R
Ti m
AS
SI R
AS
Pr
16:00:39 16:00:39 16:00:39 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40 16:00:40
R R S S R S R S R S R R S R R S R S R S R R R S S R R S S
RRC DCCH RRC DCCH RANAP RNSAP RANAP RRC DCCH RNSAP ALCAP ALCAP RNSAP RNSAP RNSAP RNSAP RNSAP RRC DCCH RANAP RRC DCCH RANAP RANAP RRC DCCH RNSAP RANAP RANAP RRC DCCH RRC DCCH RRC DCCH RRC DCCH RRC DCCH ALCAP
MeasurementReport SecurityModeComplete SecurityModeComplete RadioLinkSetupRequestFDD DirectTransfer DownlinkDirectTransfer RadioLinkSetupResponseFDD ERQ - Establish Request ECF - Establish Confirm DedicatedMeasurementInitiationRequest RadioLinkRestoreIndication DedicatedMeasurementInitiationResponse DedicatedMeasurementInitiationRequest DedicatedMeasurementInitiationResponse UplinkDirectTransfer DirectTransfer UplinkDirectTransfer DirectTransfer DirectTransfer DownlinkDirectTransfer DedicatedMeasurementReport DirectTransfer RAB-AssignmentRequest DownlinkDirectTransfer ActiveSetUpdate MeasurementReport ActiveSetUpdateComplete MeasurementControl ERQ - Establish Request
[Setup] [Setup] [Identity Response] [Identity Response] [Call Proceeding] [Call Proceeding] [55] [Facility] [Facility]
Page 15
Ti m e
AS
SI R
16:00:41 16:00:41 16:00:41 16:00:41 16:00:41 16:00:41 16:00:41 16:00:41 16:00:41 16:00:41 16:00:41 16:00:41 16:00:42 16:00:42 16:00:43 16:00:43 16:00:43 16:00:45 16:00:49 16:00:49 16:00:49 16:00:53 16:00:53 16:00:53 16:00:53 16:00:55 16:00:55 16:00:55 16:00:55 16:00:59 16:00:59 16:00:59 16:01:08 16:01:08
R S R S R S R S R S S S R R R R R R R R R R S S R R R S S R R R R S
ALCAP NBAP NBAP RNSAP RNSAP ALCAP ALCAP ALCAP ALCAP RNSAP NBAP RRC DCCH NBAP RNSAP RNSAP NBAP NBAP RNSAP NBAP NBAP NBAP NBAP RANAP RRC DCCH RANAP ALCAP ALCAP ALCAP ALCAP NBAP NBAP NBAP RANAP RANAP
ECF - Establish Confirm RadioLinkReconfigurationPrepareFDD RadioLinkReconfigurationReady RadioLinkReconfigurationPrepareFDD RadioLinkReconfigurationReadyFDD ERQ - Establish Request ECF - Establish Confirm ERQ - Establish Request ECF - Establish Confirm RadioLinkReconfigurationCommit RadioLinkReconfigurationCommit RadioBearerSetup DedicatedMeasurementReport DedicatedMeasurementReport DedicatedMeasurementReport DedicatedMeasurementReport DedicatedMeasurementReport RadioLinkFailureIndication DedicatedMeasurementReport DedicatedMeasurementReport DedicatedMeasurementReport RadioLinkFailureIndication RAB-AssignmentResponse RRCConnectionRelease Iu-ReleaseCommand REL - Release Request REL - Release Request RLC - Release Confirm RLC - Release Confirm DedicatedMeasurementReport DedicatedMeasurementReport DedicatedMeasurementReport Iu-ReleaseCommand ErrorIndication
Radio Bearer Setup is sent from RNC to NodeB but cannot be received by Ue
SI R
Pr o
AS
di o
Page 16
[release-due-to-utran-generated-reason[15]]
[0] [96]
[norm
Page 17
[synchronisation-failure[11]]
[synchronisation-failure[10]] [radio-connection-with-UE-Lost[46]]
[message-not-compatible-with-receiver-state[99]]
[synchronisation-failure[10]]
[message-not-compatible-with-receiver-state[99]]
[synchronisation-failure[10]] [message-not-compatible-with-receiver-state[99]]
Control towards NodeB. This indicates already downlink sychronisation problem. Then Ue
awaits Radio Bearer Setup from RNC. The NodeB/Cell detects an Radio Link problem with the Ue during Call Setup. The Ue was at that time in Inter RNC softhandover. The first Radio Link Failure Indication was ignored by
the RNC as it came from the DRNC via RNSAP. Once the second cell, connected to the
SRNC, also reported an Radio Link Failure Indication, the RNC aborted the Radio Bearer Setup and sent RAB Assignment Response Radio Connection lost with Ue towards MSC. In parallel the RNC sends RRC Connection Release to the Ue The MSC answers with IuRelease Command message which seems to be wrong from the RNC protocol state as RNC
responses with Error Indication message not comaptible with receiver state.
The biggest issue is that the RNC is not able to clear the RRC Resources, so the NodeB/Cell continues to report Radio Link Failure Indication synchronisation failure. The MSC sends in regular intervals Iu-Release Command and the RNC rejects always with Error Indication. Note: Protocol Error continues for about 1 minute, during that time possible Call Setups will be rejected with Requested Service Option not supported
Page 19
TEMS log shows several strong server, but no dominant server situation. Frequent link additions and deletions. See next page for typical screen shot.
Changes in RF situation required to establish dominant server. Change of downtilts. Increase tilts of far sites Change of azimuth.
Page 20
3 Ec/Io is of
average quality
-10dB
Areas with more than 3 strong Pilots occur quite Frequently, because same Azimuths are used in neighbor sites
cells having the same azimuth cell-id Scr_Code MXU7774C 130 Hoehe_ 525m Hoehe 31.5m Azimuth 310
Page 22
Elek.Downtilt 3
7) Call Rejection due to loss of RRC Release Complete message Delayed Iu Release
Symptoms
After an RRC Connection Release (e.g. due to drop) it sometimes happens, that the RRC Connection Release Complete message is lost from the Ue.
In such cases the RNC is waiting a defined time period before it entirely
This issue causes that the UMSC rejects a new call containing CM_SERV_REQ with cause Service Option not supportd
It is not possible to establish two CS calls at the same time. Resources need to be released before new connection can be established.
Decrease time the RNC waits until the resources are released. Ue may perform Cell Update after drop according to 3GPP 25.331
Page 23
abnormally
2 Ue changes to Idle mode 3 New Call Setup
4 Good Ec/Io
5 Good RSCP
The previous Call dropped due to bad coverage and Ue changes to Idle Mode
Page 24
7) Call Rejection due to loss of RRC Release Complete message (Iu-trace K1297)
Iu-trace extract 1st call drops, 2nd call gets rejected right after CMSREQ
Long Time 14:39:03,642,122 14:39:03,652,085 14:39:04,041,923 14:39:04,102,237 14:39:04,401,936 14:39:04,522,265 14:39:04,542,627 14:39:04,543,694 14:39:04,561,923 14:39:06,791,932 14:39:07,527,879 14:39:07,557,739 14:39:07,921,920 14:39:25,661,855 14:39:25,776,495 14:39:32,826,903 14:39:32,872,642 14:39:32,886,910 14:39:32,586,963 14:39:32,708,121 From UMSC UMSC RNC UMSC RNC UMSC UMSC UMSC RNC RNC UMSC UMSC RNC RNC UMSC RNC UMSC RNC RNC UMSC 2. MSG SD SD SD SD SD SD SD SD SD SD SD SD SD SD SD SD SD SD SD SD 3. MSG RL RL RL RL RL RL RL RL RL RL RL RL RL RL RL RL RL RL RL RL 4. MSG CC DT1 DT1 DT1 DT1 DT1 DT1 DT1 DT1 DT1 DT1 DT1 DT1 DT1 DT1 DT1 RLSD RLC CR CREF Procedure Code id-CommonID id-SecurityModeContr id-SecurityModeContr id-DirectTransfer id-DirectTransfer id-DirectTransfer id-DirectTransfer id-RAB-Assignment id-DirectTransfer id-RAB-Assignment id-DirectTransfer id-DirectTransfer id-DirectTransfer id-Iu-ReleaseRequest id-Iu-Release id-Iu-Release 5. MSG initiating.. initiating.. successful.. initiating.. initiating.. initiating.. initiating.. initiating.. initiating.. outcome initiating.. initiating.. initiating.. initiating.. initiating.. successful.. 6. MSG radioNetwork cause
IDREQ SETUP CPROC FACIL IDRES PROGRES CONNECT CONACK release-due-to-utran-generated-reason release-due-to-utran-generated-reason
id-InitialUE-Message id-DirectTransfer
initiating.. initiating..
The first call drops with release due to utran generated reason, but the Iu-Release is completed 7sec afterwards. In the meantime, the Ue tries to setup a new call which gets
rejected by MSC with cause Service Option not supportd assumption: 2 outgoing
CS calls are not supported for one Ue at the same time.
Page 25
7) Call Rejection due to loss of RRC Release Complete message (Iu + Iub trace K1297)
The Iu-resource gets released after about 7sec after the drop has been declared by RNC. It seems that a Radio Link timer runs in NodeB to monitor the Ues DCH. After the NodeB (cell) has reported an Radio Link Failure towards RNC, the Iu resource is released (IuRelease successful Outcome). Note: The Ue has not reported RRC Connection Complete
Long Time 14:39:25,661,855 14:39:25,776,495 14:39:26,435,778 14:39:26,435,778 14:39:30,608,053 14:39:30,618,806 14:39:31,068,692 14:39:32,826,903 14:39:32,872,642 14:39:32,886,910
From 2. MSG 3. MSG 4. MSG RNC SD RL DT1 UMSC SD RL DT1 Node-B #3 (DCH FP DATA #1 DL) DCH Node-B #3 (DCH UM DATA #1 DL) DCH rrcConnectionRelease NBAP UL SD initiatingMessage NBAP UL SD initiatingMessage NBAP UL SD initiatingMessage RNC SD RL DT1 UMSC SD RL RLSD RNC SD RL RLC
Iu Released
Page 26
Often, but not always, together with pilot polution. Tems log shows frequent active setupdates. Many 1a, 1b, 1c events This causes signaling load in network. Risk of link addition failure and drop is increased. Mobile is always in SHO and ocupies more resources than necessary.
Establish clear best server. Improve strong server and reduce not requested far server by changing azimuth and downtilts.
Page 27
Page 28
Page 29
Page 30
It can be seen that the HCOM is sent to the Ue, but after 15sec the UMSC sends a Iu-Release
because the InterRAT HO to GSM is not successful. If the InterRAT HO were successful a IuRelease with cause successful Relocation would be sent by UMSC. We know from the Ue that the call dropped in our trace. It is also obvious that the RNC waits more than 15sec and does not realize any problem during the handover. Here it is vital to check what is the setting for the timer T_RELOC_COMPLETE in RNC - if exist - as no handover failure with e.g.
Page 33
Page 34
Page 35
Page 36
Page 37
Page 38
Page 39
Problem with Allocating the Spreading Factor in NodeB NodeB Reset fixes the problem temporarily
Page 40
Page 41
Page 42
The RRC Connection Release has as a cause normal Event so a problem in UTRAN is not
visible for the Drive-test personnel when looking at TEMS
Page 43
It can be seen that the failure dl-resources not available can also be the reason for
Page 44
Good RF condition EcNo and RSCP are good Ue (TEMS) shows sending of RRC Connection Request on RACH TrCH up to the max. number or retransmissions
Not any response from UTRAN e.g. RRC Connection Setup is missing
K1297 shows RACH decoding error or CRC checksum error SHOs into the affected cell and out of that cell work fine
Page 45
12) Faulty RACH prevents Call Setup but SHO OK K1297 trace
Long Time 16:53:26,974,189 16:53:26,981,439 16:53:27,810,070 16:53:27,820,814 16:53:29,404,938 16:53:29,415,688 16:53:34,787,349 16:53:36,973,115 16:53:36,983,998 16:53:37,812,246 16:53:37,819,627 16:53:37,883,994 16:53:39,404,112 16:53:39,414,616 16:53:40,977,379 16:53:46,972,043 16:53:46,982,680 16:53:47,811,556 16:53:47,822,054 16:53:49,406,412 From NBAP UL NBAP UL NBAP UL NBAP UL NBAP UL NBAP UL C2 RACH UL NBAP UL NBAP UL NBAP UL NBAP UL C2 RACH UL NBAP UL NBAP UL C2 RACH UL NBAP UL NBAP UL NBAP UL NBAP UL NBAP UL 2. MSG SD SD SD SD SD SD FP DATA .. SD SD SD SD FP DATA .. SD SD FP DATA .. SD SD SD SD SD 3. MSG initiatingMessage initiatingMessage initiatingMessage initiatingMessage initiatingMessage initiatingMessage initiatingMessage initiatingMessage initiatingMessage initiatingMessage initiatingMessage initiatingMessage initiatingMessage initiatingMessage initiatingMessage initiatingMessage initiatingMessage Procedure Code id-commonMeasurement id-commonMeasurement id-commonMeasurement id-commonMeasurement id-commonMeasurement id-commonMeasurement id-commonMeasurement id-commonMeasurement id-commonMeasurement id-commonMeasurement id-commonMeasurement id-commonMeasurement id-commonMeasurement id-commonMeasurement id-commonMeasurement id-commonMeasurement id-commonMeasurement received total wide band power 70 70 18 70 18 70 18 70 18 70 18 70 18 70 18 70 transmitted carrier power 18
The C2 indicates the 3rd sector (C0 = 1st sector and C1=2nd sector) After the RACH has been relayed to the RNC there is no response from the RNC. Reason for that are decoding errors or wrong CRC-checksum inside the RACH.
Page 46
12) Iub shows RACH decoding errors or CRC checksum error K1297 trace
Page 47
12 Iub shows RACH decoding errors or CRC checksum error K1297 trace
Page 48
Page 49
12) Drive-test log - RRC Connection Request w/o response from UTRAN
Symptoms 1 Good Ec/No 2 Good RSCP 3 Ue sends max.
number of RRC
Connection Requests without any Ack or Nack from
UTRAN
4 Ue back in Idle Mode 5 SHO into
faulty are ok
Page 50
shows that
SHO into and out of the faulty cell are fine no
problem
visible
Page 51
12) Summary
The faulty cell(s) behave normal Pilot Channel can be decoded and soft-handover in and out of the faulty cell(s) are possible. Call-Setups in those faulty cells are prevented by decoding or CRC checksum error on the RACH-transport channel. As the K1297 trace monitors the Iub-interface, it cannot be determined if the error was introduced on the Air-interface or inside the NodeB. From the drive-test it looks similar like a sleeping cell, however soft-handover are working which prove that the RF-path and channels are okay. The cell is active on Uu but even after several RACHs still no response from UTRAN.
This error points to some hardware problem on the CCCH, as DCH channels work fine.
Page 52
Good RF condition EcNo and RSCP are good Ue (TEMS) does not send any RRC Connection Request on RACH-TrCH Not any response from UTRAN e.g. RRC Connection Setup is missing
SHOs into the affected cell and out of that cell work fine
RNC database shows that neither Cell Barred nor Operator Barring is used, but SYSINFO Type 3 indicates Operator Barring (TEMS)
Cell Barred for Access Flag is set Cell Barred for Operator Use is set Perform an Audit on that NodeB to align RNC and NodeB database
Page 53
1 Good Ec/No
2 Good RSCP 3 No RRC Connection
Request from
Ue
Page 55
Good RF condition EcNo and RSCP are good Faulty Ue drops suddenly during or after Call-Setup for no obvious reason Other Ue(s) in parallel also drop for no obvious reason
Trace on Iub with K1297 and test all Ues for unusual high RTWP Throw away Ues causing high RTWP Issue seen so far on Siemens/Motorola Ue (U10 or U830)
Page 56
DT1 DT1
DT1
124 70 70 70 70
CMSREQ SETUP id-commonMeasurement 314 release-due-to-Utran generated reason unspecified id-commonMeasurement 249
id-commonMeasurement
124
It can be seen that as soon as the faulty Ue makes a phone call (SETUP message), the RTWP rises by more than 20dB. This leads to a drop and also other mobiles will drop in that Cell as well. The RRC release cause is unspecified Reason for high RTWP is the high output power of the Ue. Such an Ue will not power down as ordered by NodeB, therefore the high RTWP.
Page 58
Initial Measurement Control is sent ( for MOC: right after CM SERV REQ) Measurement Control contains Neighbor cells SC as specified in the Neighbor list After Connect Ack the Ue stops sending any measurement report towards RNC In most of the cases call drops if not aborted or Disconnected earlier
TEMS bug not yet confirmed by TEMS Support After Disconnect and new call Setup problem disappears Issue seen so far on Qualcom Ue in conjunction with TEMS only
Page 59
RNC
2 Ue measures neighbors but no measurement reports are sent to RNC 3 Ec/Io of Serving Cell drops, Neighbor Ec/Io are very good 4 Once a new call is set up, problem disappears
Page 60
The Ue cannot camp on such cell(s) - only via SHO a call can be made on that cell(s) The SysInfo Type 11 obtained in Idle Mode contains one or more repeated SCs
Page 61
with cell(s)
having an erronomeous Neighbor list same SC is defined twice as neighbor. The Meas Control Failure
is ignored by
RNC.
Page 62
Textdokument
On the left there is an extract of a faulty neighbor-list. Two neighbors are defined twice with the same Scrambling
Code.
The complete Measurement Control Message can be found in the attached Textdokument.
Page 63
SysInfo 11
find another
PLMN). This is shown on the next slide.
Page 64
goes into
limited service state
Page 65
Page 66
Page 67
the
connection with RRC Connection Release unspecified
Page 68