You are on page 1of 28

New AR:

View AR | AR without Proprietary


History | States | Assignment | Timetracking
AR Text Search | More | CARES Home

Assistance Request 1-5514132


Customer Ticket N/A

Short

Repeated cell instability on the site 288

Description

Current

Issue caused by TMU instability. TMU issue solved. Closure

Summary

aproval granted.

State

Closed : Solution/Service Provided

Outage

No

Severity

Priority

Service Request Remote Technical Support


Request Type

Support

Sub-Type

Diagnose

Category

Software

Internal

No

Assignment Events
Product
Product

9926 DBS-WCDMA

Version

LR13.1.W

No Change Request is linked to this AR


Product Location
Site

ETISALAT ABU DHABI

Instance

9926DBS WCDMA-Etisalat : In Service

Site Company

Emirates Telecommunications Corporation

City

Abu Dhabi

Country

United Arab Emirates

Contact
Name

Karim IBRAHIM ABD EL NABY

Company

Alcatel-Lucent : Open on behalf of Customer

Phone
20 127 109 0616
Karim.Ibrahim@alcatel-lucent.com
Request Method

Email

Email-CR

Dates
Occurred
(GMT+4)

29-Dec-2014 15:11

Time now

29-Aug-2015 13:24

Reported

29-Dec-2014 15:11

AR Created

29-Dec-2014 15:21

Service Start

29-Dec-2014 15:11
Next Customer Contact

29-Dec-2015 03:00

Responded
30-Dec-2014 11:00
SA - Calculated

Respond Target

30-Dec-2014 15:11

Restored
SA - None

07-Jan-2015 11:00

Restore Target

-- --- ----

Resolved
22-Jan-2015 12:39
SA - Calculated

Resolve Target

02-Mar-2015 19:42

Targets for Restore & Resolve were extended by 3 days 5 hours


to account for Pending time
Closed

22-Jan-2015 12:39

Last Modified

22-May-2015 16:03

Entitlement

Modified By

archive

Agreement

242895 (OXIA 627085)

Covered Service TS 24x7 (Gold, Wireless Mobile Access)


Script

This request is entitled to service.

People
Owner

TSCr-MoA-WCDMA-SK : rkosorin

Assignee

TSCr-MoA-WCDMA-SK : rkosorin

Referred 1

ExcP-WLS-WCDMA-vGlobal : rkosorin

Referred 2

TEC-MoA-WCDMA_BTS : mdiwanou

Resolve Group

TEC-MoA-WCDMA_BTS

Submitter

dmajer

Description
From: "IBRAHIM ABD EL NABY, Karim (Karim)** CTR **"
<karim.ibrahim@alcatel-lucent.com>
Sent: 2014-12-29 12:11:55
To: ALU Support <support@alcatel-lucent.com>
Subject: RE: Repeated cell instability on the site 288

Hi,

Severity 3.

Thanks,

--

BR,

Karim Ibrahim

From: SUPPORT@ALCATEL-LUCENT.COM [mailto:SUPPORT@ALCATEL-LUCENT.COM]


Sent: Monday, December 29, 2014 3:10 PM
To: IBRAHIM ABD EL NABY, Karim (Karim)** CTR **
Cc: BERIDY, AHMED (AHMED); REDA, RAMY (RAMY); ELHAKIM, Mohamed (Mohamed)**
CTR **; ABDEL-HALIM, SAYED (SAYED); NADER, Mohamed (Mohamed)** CTR **;
ZAHABI, RAMSEY (RAMSEY); OKASHA, TAHER (TAHER)
Subject: Re: Repeated cell instability on the site 288

Dear Mr. Ibrahim,

what is the severity of this problem 1 or 3?

Kind regards,

Natalia Targonska

ALCATEL-LUCENT

GLOBAL WELCOME CENTER

Visit OnLine Customer Support


<https://services.support.alcatel-lucent.com/product_support/> for Contact
details

On 29.12.14 12:03, Karim (Karim)** CTR ** IBRAHIM ABD EL NABY wrote:

Hello,

Short Description

Repeated cell instability on the site 288

causing KPIs degradation

Current Summary

: TEC support needed

Contact Surname

Contact Given Name

Contact Phone

Contact Company

Company

Contract Number

Karim

: Ibrahim

:+971 56 354 4568

: Alcatel-Lucent

Emirates Telecommunications Corporation

: OXIA 627085

Region

: EMEA

Country

: United Arab Emirates

City

: Abu Dhabi

Site

: ETISALAT ABU DHABI

Product Instance

: 9926 DBS-WCDMA

Severity

: 3

Priority

Product Version

Severity

: 3

: LR13.3W

: 1

Action taken: Change SG, Reset the TMUs, the issue solved for short time
and come back.

Logs: Attached HFB.

Outage

Internal/External:

: No

:Internal

-Best Regards,

Karim Ibrahim
LTE/WCDMA Integration Professional

META WLS Access Network (GNE EMEA)


M(UAE): +
<https://mail.eu.alcatel-lucent.com/owa/redir.aspx?
C=30449991f54743fd85063b63258fd6f2&URL=https%3a%2f%2fmail.eu.alcatellucent.com%2fowa%2fUrlBlockedError.aspx>
971-56-354-4568

M(Egy): +
<https://mail.eu.alcatel-lucent.com/owa/redir.aspx?
C=30449991f54743fd85063b63258fd6f2&URL=https%3a%2f%2fmail.eu.alcatellucent.com%2fowa%2fUrlBlockedError.aspx>
2010-668-44-810

ONNET:

2205 5534

Showing Investigation and Proprietary logs together in time order


separately

Show

Investigation Log and Proprietary Log


1. 29-Dec-2014 15:24
dmajer

Update to Current Summary: Assigned to Workgroup;

2. 29-Dec-2014 15:25
dmajer

ALCATEL-LUCENT PROPRIETARY

Outgoing E-mail to Karim (Karim)** CTR ** IBRAHIM ABD EL NABY


Workflow Status: Queued
Subject: Re: RE: Repeated cell instability on the site 288 // AR 1-5514132
Contact: Karim (Karim)** CTR ** IBRAHIM ABD EL NABY
Agent: dmajer
From: support@alcatel-lucent.com
To: "IBRAHIM ABD EL NABY, Karim (Karim)** CTR **"
<karim.ibrahim@alcatel-lucent.com>
Cc: "BERIDY, AHMED (AHMED)" <Ahmed.Beridy@alcatel-lucent.com>, "REDA, RAMY

(RAMY)" <ramy.reda@alcatel-lucent.com>, "ELHAKIM, Mohamed (Mohamed)** CTR


**"
<Mohamed.Elhakim@alcatel-lucent.com>, "ABDEL-HALIM, SAYED (SAYED)"
<Sayed.Abdel-Halim@alcatel-lucent.com>, "NADER, Mohamed (Mohamed)** CTR **"
<mohamed.nader@alcatel-lucent.com>, "ZAHABI, RAMSEY (RAMSEY)"
<ramsey.zahabi@alcatel-lucent.com>, "OKASHA, TAHER (TAHER)"
<Taher.Okasha@alcatel-lucent.com>
Bcc:
Sent on:

Dear Customer,

Thank you for contacting the Alcatel-Lucent Welcome Center.


Your request has been processed and the ticket number for your reference is
AR
-5514132. Please reference that number when contacting Alcatel-Lucent for
follow-up.
An Alcatel-Lucent representative will contact you regarding your request.

Kind Regards,

Dawid Majer

ALCATEL-LUCENT

GLOBAL WELCOME CENTER

Visit OnLine Customer Support for Contact details

3. 30-Dec-2014 11:04
rkosorin

Update to Current Summary: TPS WIP

4. 30-Dec-2014 13:16
rkosorin

Hello Karim,
We received your ticket, where you are complaining about the cell
instability on
the NodeB 288.

In order to investigate the issue, please provide:

1)

The issue in 288 is being repeated periodically?

2)

Are you observing the same kind of issue also on different NodeBs?

3)
What is the exact behavior? The cells are bouncing and then going to
disabled
state without any possibility to bring it back to the service without TMU
restart
(have you tried different WA - NodeB reset, lock/unlock of the cells)?
4)

Have you observed any transport instability when the issue starts?

5)

Are you seeing ANO_DEADLOCK alarm on the cells?

For the AP:

A)
the

Please do telnet to the RNC, where the problematic cell is mapped. Log

session.
B)

Check on which TMU instance the cells are being mapped:

My example: looking for the 40851 & 40852 cells:

d -n rncin tmu/* cellist

RncIn Tmu/11

TMU instance, where the desired cells are mapped

cellList = 20031,30671,30672,20032,20033,39622,20034,30674,30675,20035,
20036,39625,20083,20082,20086,20085,20089,20088,20037,39623,
39861,39862,22251,39863,22252,39621,39864,39865,22254,39866,
22255,39624,39626,20038,20039,20081,20084,22257,22258,20682,
30431,23471,23474,21152,20681,20683,23472,23475,21155,20685,
30432,20684,20686,20691,20692,20693,20694,20695,20696,20697,
20698,20699,20087,21151,21154,62514,62515,62516,62965,62966,
62964,30433,30434,30435,30436,21032,21031,21034,21035,40852,
40851

C)

Do TELCI to the TMU instance, which is handling the cells:

My Example: I was looking for the cell 40851. I did telci to TMU instance 11

Play commands:

telci -tmu(11) rncin


telci(tmu)> set unsafe
telci(tmu)> rrmcell info 40851
telci(tmu)> rnccom celldpref -> from report of this command please determine
iNodebCoreProcessRef and iCellRefPerNodebCP

(iNodebCoreProcessRef,iCellRefPerNodebCP,CId): 4 34 45273
(iNodebCoreProcessRef,iCellRefPerNodebCP,CId): 4 35 45052
(iNodebCoreProcessRef,iCellRefPerNodebCP,CId): 5 0 40851
(iNodebCoreProcessRef,iCellRefPerNodebCP,CId): 5 1 40852
(iNodebCoreProcessRef,iCellRefPerNodebCP,CId): 5 2 40853
(iNodebCoreProcessRef,iCellRefPerNodebCP,CId): 5 3 45421

And use these numbers for next two commands:


Syntax: nobcch rootaut < iNodebCoreProcessRef> <iCellRefPerNodebCP>

telci(tmu)> nobcch rootaut 5 0


telci(tmu)> nobcell cellaut 5 0

Play the commands for all impacted cells

Q -> for exit

D)

Run full RNCLogCollection

E)

Provide the RNCLogCollection, log from the TMU and HFB file

BR

rasto

5. 02-Jan-2015 17:47
rkosorin

Dear TEC,

ALCATEL-LUCENT PROPRIETARY

i wouldlike to ask you for help regarding issue seen in UEA network.

Issue description:
*****************************
Fddcells on the NodeB Baynoonah_T_288 are bouncing. Sometimes in the same
time all
of them are going down, sometimes only one or few of them. Issue is seen
only on
this NodeB. The cell outage is very short - the cells are just bouncing.
Issue is
relativelly frequent. it occurrs several times per day.

Issue investigation:
*****************************
Issue is happening in the load: UNB1330BC01.

NodeB is relatively new one. It has been put online 25.11.2014. The issue
started
to ocure 9.12.2014. From the config perspective the NodeB looks fine...
There are
no errors which would indicate config issue... From the IMT perspective it
is
difficult for me to say, what is going on on the NodeB. I have seen few
erreos,
which occurred around the times of the issue occurrence, but those errors
were
seen also at diffeent times and no cell bouncing was observed.
RNCLogCollection is
not helpfull at all for me...

Please check for example the date/time 31.12.2014 14:28:55. At this time all
the
cells wend down anf]d up....

There is OT cell trace available from that time and again - it is not
helpfull at
all. To sumarize - there is no clue for me what is going on... I have asked
for
CCM replacement but local team would like to have theproof there is HW issue
first...

Logs available on cuba server /traces/UAE/1-5514132:


******************************
OTcell trace, RNCLogCollection, IMT ZAP, HFB. snapshot

Please advise.

BR

Rasto

6. 02-Jan-2015 17:49
rkosorin

ALCATEL-LUCENT PROPRIETARY

Time Tracking Entry Added - IR01-TSA4

7. 02-Jan-2015 18:03
rkosorin

ALCATEL-LUCENT PROPRIETARY

Time Tracking Entry Added - IR01-TSA3

8. 12-Jan-2015 11:18
rkosorin

ALCATEL-LUCENT PROPRIETARY

Hello Manuela,
have you had the time to look at the issue? Please share the results.

BR

Rasto

9. 12-Jan-2015 20:36
mdiwanou

ALCATEL-LUCENT PROPRIETARY

Hi Rasto,

Could you provide NTL fot the BTS and the RNC, for the time issue is seen.

Issue seems to happen randomly for 3 seconds. So I need to check the NTL
logs
I can't find anything in BTS logs synchronized with HFB reports.
I can't find anything interesting on BTS Logs instead of CCP get disable
several
times, this were reported several time.

Let me check further, I may need to involve TPS RNC. I will you know.

Regards

MAnuela

10. 13-Jan-2015 14:59


rkosorin

ALCATEL-LUCENT PROPRIETARY

Hello Manuela,
please involve al neccessary support you need. Please provide feedback as
soon as
possible. The local team is pushing - i know the ticket is having s/p = 3/3,
but
this is because the guy, who opened it has no clue about the criticity
numbering i believe.

BR

rasto

11. 13-Jan-2015 15:04


rkosorin

Hello Ahmed,
The ticket was in the TEC BTS team for investigation. The investigation
results
from their side except the fact, that the cells wend down, are not showing
anything, which could point to RC.

The BTS TEC engineer asked for help the RNC team. I will update as soon as I
have
their view.

BR

Rasto

12. 13-Jan-2015 15:13


mdiwanou

ALCATEL-LUCENT PROPRIETARY

Hello,

I will have a look for this. But unless could they provide a NTL
requested... I
doubt that a well working site starts bouncing without any actions from
Customer.
Maybe this is due to any misconfiguration performed.
But for now, I can't provide the RC.

Regards,

Manuela DIWANOU

13. 16-Jan-2015 15:34


rkosorin

ALCATEL-LUCENT PROPRIETARY

Hello Manuela,
the logs from AP you asket for are uploaded to Cuba server:
/traces/UAE/1-5514132/14012015

Please have a look.

BR

rasto

14. 16-Jan-2015 17:30


rkosorin

ALCATEL-LUCENT PROPRIETARY

Just an additional info - customer just replaced CCM board for this NodeB.
Unfortunately the issue is still persisting.

Rasto

15. 16-Jan-2015 18:01


mdiwanou

ALCATEL-LUCENT PROPRIETARY

Hi Rasto,

Stability data attached are from 10/01/2015 and 11/01/2015 when OTC cell is
from
13/01/2015, can I have stability data for 13, 14 and 15 january.

Same for NTL, it stops at 13 january, but I need data for 13,14,15.

As it will help for matching logs.

Regards,

Manuela

16. 16-Jan-2015 18:43


mdiwanou

In addition,

ALCATEL-LUCENT PROPRIETARY

From the NTL, I can see following alarm:

2015/01/10 - 15:26:38
State Change
(BTSEquipment/T_AR_U_288_Baynoonah)

5483603

BTSEquipment/T_AR_U_288_Baynoonah CCP/0
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/disabled/failed//
2015/01/10 - 15:26:38
State Change
(BTSEquipment/T_AR_U_288_Baynoonah)

5483604

BTSEquipment/T_AR_U_288_Baynoonah CCP/1
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/disabled/failed//
2015/01/10 - 15:26:38
State Change
(BTSEquipment/T_AR_U_288_Baynoonah)

5483605

BTSEquipment/T_AR_U_288_Baynoonah CCP/2
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/disabled/failed//
2015/01/10 - 15:26:38
State Change
(BTSEquipment/T_AR_U_288_Baynoonah)

5483606

BTSEquipment/T_AR_U_288_Baynoonah CCP/3
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/disabled/failed//
2015/01/10 - 15:26:38
State Change
(BTSEquipment/T_AR_U_288_Baynoonah)

5483602

BTSEquipment/T_AR_U_288_Baynoonah NodeBCP/0
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/disabled/failed//
2015/01/10 - 15:26:41
State Change
(BTSEquipment/T_AR_U_288_Baynoonah)

5483610

BTSEquipment/T_AR_U_288_Baynoonah NodeBCP/0
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus

/enabled///
2015/01/10 - 15:26:50
State Change
(BTSEquipment/T_AR_U_288_Baynoonah)

5483729

BTSEquipment/T_AR_U_288_Baynoonah CCP/0
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/enabled///
2015/01/10 - 15:26:50
State Change
(BTSEquipment/T_AR_U_288_Baynoonah)

5483728

BTSEquipment/T_AR_U_288_Baynoonah CCP/1
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/enabled///
2015/01/10 - 15:26:50
State Change
(BTSEquipment/T_AR_U_288_Baynoonah)

5483730

BTSEquipment/T_AR_U_288_Baynoonah CCP/2
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/enabled///
2015/01/10 - 15:26:50
State Change
(BTSEquipment/T_AR_U_288_Baynoonah)

5483731

BTSEquipment/T_AR_U_288_Baynoonah CCP/3
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/enabled///

2015/01/10 - 11:16:15
Alarm
5460635
(BTSEquipment/T_AR_U_288_Baynoonah)
BTSEquipment/T_AR_U_288_Baynoonah IpRan/0 VirtualInterface/2
HEARTBEAT

IP RAN/0

FAILURE
Cleared faultCode : BTS_0404_00054 helpVolume :
RAN_iBTS_Fault_Analysis
NotificationID : 5460635
Alarm Specific

communicationsProtocolError

Problem:IP RAN/0 HEARTBEAT FAILURE,

Communication

AdditionalInformationFromNE:additionalInformation = { manufacturerInfoAscii
= UDP
HeartBeat Request NOT received from RNC }

Those alarms point out transport issue. Can customer check its transport
link? Did
they perform any operation regarding transport in december 10 (beginning of
this
issue).

Please provide requested data so We can check here in order to confirm that
this
issue is out of UTRAN.

Thanks in advance,

Manuela

17. 19-Jan-2015 13:44


rkosorin

ALCATEL-LUCENT PROPRIETARY

Hello Manuela,
i uploaded the hfb/stc for 14.15.1.2015. The log for 14.1.2015 is not
containing
any record about fddcells being disabled. There is only RRH dump
notification for
288 NodeB inside. The hfb/stc for 13.1.2014 are missing. They are not even
on the
server - so they do not exist. From my side i have asked local team to
provide
exact date/time when the cells wend to disabled state in order to avoid
"blind"
search.

From my side - if they can't provide exact date/time, i would ask them to
perform
the AP again and to pay attention that all the loga are available and
correlated
in time. Do you agree, or the data available now are useful for you?

BR

rasto

18. 19-Jan-2015 13:44


rkosorin

Hello Karim,
The traces were taken 13 and 14.1.2015. The hfb file was delivered for
14.1.2015
only. No hfb/stc for 13.1.2014.

From hfb 14.1.2015: there is only one record regarding 288 NodeB inside:

T_AR_U_288_Baynoonah
NW/UTRAN BTSEquipment/T_AR_U_288_Baynoonah
Board/688526591
1/12/2015 11:11
null
processing
error
warning
active
softwareProgramError
RRH/41 SOFTWARE DUMP
RRH/41 SOFTWARE DUMP Specific
Problem:RRH/41 SOFTWARE DUMP, Cabinet:10, Shelf:20, Slot-position:255,
AdditionalInformationFromNE:additionalInformation = { manufacturerInfoAscii
= FULL RESET 131 RFH Reset triggered from EH: internal event 1, App: CPRI
Messag.- RRH F/W:_BI_RE_ASB2XA_BAND01_FV_P0103HwRel:AB P EC:3JR10104AA
SN:YP1433 }
BTS_0002_00047

No record about Fddcells being unlocked disabled....

TEC had looked at the traces and from the trace content only following is
revealed:

From the NTL, I can see following alarm:

2015/01/10 - 15:26:38
State Change
5483603
(BTSEquipment/T_AR_U_288_Baynoonah)
BTSEquipment/T_AR_U_288_Baynoonah CCP/0
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/disabled/failed//
2015/01/10 - 15:26:38
State Change
5483604
(BTSEquipment/T_AR_U_288_Baynoonah)
BTSEquipment/T_AR_U_288_Baynoonah CCP/1
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/disabled/failed//
2015/01/10 - 15:26:38
State Change
5483605
(BTSEquipment/T_AR_U_288_Baynoonah)
BTSEquipment/T_AR_U_288_Baynoonah CCP/2
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/disabled/failed//
2015/01/10 - 15:26:38
State Change
5483606
(BTSEquipment/T_AR_U_288_Baynoonah)
BTSEquipment/T_AR_U_288_Baynoonah CCP/3
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/disabled/failed//
2015/01/10 - 15:26:38
State Change
5483602
(BTSEquipment/T_AR_U_288_Baynoonah)
BTSEquipment/T_AR_U_288_Baynoonah NodeBCP/0
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/disabled/failed//
2015/01/10 - 15:26:41
State Change
5483610
(BTSEquipment/T_AR_U_288_Baynoonah)
BTSEquipment/T_AR_U_288_Baynoonah NodeBCP/0
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/enabled///
2015/01/10 - 15:26:50
State Change
5483729
(BTSEquipment/T_AR_U_288_Baynoonah)
BTSEquipment/T_AR_U_288_Baynoonah CCP/0
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/enabled///
2015/01/10 - 15:26:50
State Change
5483728
(BTSEquipment/T_AR_U_288_Baynoonah)
BTSEquipment/T_AR_U_288_Baynoonah CCP/1
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/enabled///

2015/01/10 - 15:26:50
State Change
5483730
(BTSEquipment/T_AR_U_288_Baynoonah)
BTSEquipment/T_AR_U_288_Baynoonah CCP/2
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/enabled///
2015/01/10 - 15:26:50
State Change
5483731
(BTSEquipment/T_AR_U_288_Baynoonah)
BTSEquipment/T_AR_U_288_Baynoonah CCP/3
adminState/operationalState/availabilityStatus/standbyStatus/controlStatus
/enabled///

2015/01/10 - 11:16:15
Alarm
5460635
(BTSEquipment/T_AR_U_288_Baynoonah)
BTSEquipment/T_AR_U_288_Baynoonah IpRan/0 VirtualInterface/2
IP RAN/0
HEARTBEAT FAILURE
Cleared
faultCode : BTS_0404_00054
helpVolume : RAN_iBTS_Fault_Analysis NotificationID : 5460635
communicationsProtocolError Communication Alarm
Specific
Problem:IP RAN/0 HEARTBEAT FAILURE,
AdditionalInformationFromNE:additionalInformation = { manufacturerInfoAscii
= UDP HeartBeat Request NOT received from RNC }

The time of the issue (10.1.2015) is not matching with the AP time (1314.1.2015).

Please provide the information, at what time in the date 13-14.1.2015 the
fddcells
wend down without apparent reason. The log for 14.1.2015 is having only the
record
about RRH dump. 13.1.2015 is missing. What shall we look at and to what
date/time?

BR

Rasto

19. 20-Jan-2015 14:46


mdiwanou

Hi Rasto,

ALCATEL-LUCENT PROPRIETARY

I prefer to wait for the whole data as you described above. Then, I'll
confirm my
analysis or not.

Regards.

Manuela

20. 22-Jan-2015 12:37


rkosorin

TPS update:
***************************
Hello Karim,
From the HFB extract and from the raw hfb files you provided, the cells on
NodeB
288 during 13-14.1.2015 were stable.

Regarding your question about TMU be

indeed, looking at the old logs it can

seen that prior the cells wend down, the TMU was resewt:

RNC_2028_30467
EM RNCRNC231
RNC231
quality of service
NW:UTRAN RNC:RNC231 RNCEquipment:0 CNode:0
NW/UTRAN RNC/RNC231 RNCEquipment/0 CNode/0
2014-12-10T16:29:26 +0400
warning
Cleared
2014-1210T16:51:19 +0400
FALSE
> Local
value : ANO_RESTART_CONTEXT on PSFP slot 8 Processor role First PMC-TMU
Specific Problem:> Local value : ANO_RESTART_CONTEXT on PSFP slot 8
Processor role First PMC-TMU, manu:[unavailable value], plmno:Ns-FailCause,
common:[unavailable value],
AdditionalInformationFromNE:additionalInformation = { common = { information
= { postMortem = fmNormal eqp3GLocation = { hardSlotPosition = { shelfNumber
= 0 positionInShelf = 8 } hardconf = { } } } } plmno = { information =
{ plmnoRestartContext = { boardType = v-pmc-boardType cause = v-ns-FailCause
overFMTreshold = v-fmtreshold-notExceeded } } } manu = { information = "FM

PMDZ is written and valid BaseOS PMDZ is empty. " "FM nb event 0. FM
threshold has NOT occured. " } }
softwareProgramAbnormallyTerminated
> Local value : ANO_RESTART_CONTEXT on PSFP slot 8 Processor role First PMCTMU
RNC_0021_00020
EM RNCRNC231
RNC231
quality of service
NW:UTRAN RNC:RNC231
NodeB:T_AR_Baynoonah_U_288_U900 FDDCell:T_WR_BAYNOONAH_U900_F2_B
NW/UTRAN RNC/RNC231 NodeB/T_AR_Baynoonah_U_288_U900
FDDCell/T_WR_BAYNOONAH_U900_F2_B
2014-12-10T16:29:27 +0400
Critical
Cleared
2014-12-10T19:21:12 +0400
FALSE
State change to Disable Failed
Associated BTS:T_AR_Baynoonah_U_288_U900, $site.name$, Correlated
notification: 20141210162927Z, RNC Shelf number\Board Slot position\Adjunct
Processor:0\12\1, Source Indicator:RESOURCE_OPERATION
underlyingResourceUnavailable
State change to Disable Failed
Inhibit rule;
RNC_0021_00020
EM RNCRNC231
RNC231
quality of service
NW:UTRAN RNC:RNC231
NodeB:T_AR_Baynoonah_U_288_U900 FDDCell:T_WR_BAYNOONAH_U900_F2_C
NW/UTRAN RNC/RNC231 NodeB/T_AR_Baynoonah_U_288_U900
FDDCell/T_WR_BAYNOONAH_U900_F2_C
2014-12-10T16:29:27 +0400
Critical
Cleared
2014-12-10T19:21:12 +0400
FALSE
State change to Disable Failed
Associated BTS:T_AR_Baynoonah_U_288_U900, $site.name$, Correlated
notification: 20141210162927Z, RNC Shelf number\Board Slot position\Adjunct
Processor:0\12\1, Source Indicator:RESOURCE_OPERATION
underlyingResourceUnavailable
State change to Disable Failed
Inhibit rule;
RNC_0021_00020
EM RNCRNC231
RNC231
quality of service
NW:UTRAN RNC:RNC231
NodeB:T_AR_Baynoonah_U_288_U900 FDDCell:T_WR_BAYNOONAH_U900_F2_D
NW/UTRAN RNC/RNC231 NodeB/T_AR_Baynoonah_U_288_U900
FDDCell/T_WR_BAYNOONAH_U900_F2_D
2014-12-10T16:29:27 +0400
Critical
Cleared
2014-12-10T19:21:12 +0400
FALSE
State change to Disable Failed
Associated BTS:T_AR_Baynoonah_U_288_U900, $site.name$, Correlated
notification: 20141210162927Z, RNC Shelf number\Board Slot position\Adjunct
Processor:0\12\1, Source Indicator:RESOURCE_OPERATION
underlyingResourceUnavailable
State change to Disable Failed
Inhibit rule;
RNC_0021_00020
EM RNCRNC231
RNC231
quality of service
NW:UTRAN RNC:RNC231
NodeB:T_AR_Baynoonah_U_288_U900 FDDCell:T_WR_BAYNOONAH_U900_F1_D
NW/UTRAN RNC/RNC231 NodeB/T_AR_Baynoonah_U_288_U900
FDDCell/T_WR_BAYNOONAH_U900_F1_D
2014-12-10T16:29:27 +0400
Critical
Cleared
2014-12-10T19:21:12 +0400
FALSE
State change to Disable Failed
Associated BTS:T_AR_Baynoonah_U_288_U900, $site.name$, Correlated
notification: 20141210162927Z, RNC Shelf number\Board Slot position\Adjunct
Processor:0\12\1, Source Indicator:RESOURCE_OPERATION
underlyingResourceUnavailable
State change to Disable Failed
Inhibit rule;

RNC_0021_00020
EM RNCRNC231
RNC231
quality of service
NW:UTRAN RNC:RNC231
NodeB:T_AR_Baynoonah_U_288_U900 FDDCell:T_WR_BAYNOONAH_U900_F1_A
NW/UTRAN RNC/RNC231 NodeB/T_AR_Baynoonah_U_288_U900
FDDCell/T_WR_BAYNOONAH_U900_F1_A
2014-12-10T16:29:27 +0400
Critical
Cleared
2014-12-10T19:21:12 +0400
FALSE
State change to Disable Failed
Associated BTS:T_AR_Baynoonah_U_288_U900, $site.name$, Correlated
notification: 20141210162927Z, RNC Shelf number\Board Slot position\Adjunct
Processor:0\12\1, Source Indicator:RESOURCE_OPERATION
underlyingResourceUnavailable
State change to Disable Failed
Inhibit rule;
RNC_0021_00020
EM RNCRNC231
RNC231
quality of service
NW:UTRAN RNC:RNC231
NodeB:T_AR_Baynoonah_U_288_U900 FDDCell:T_WR_BAYNOONAH_U900_F1_C
NW/UTRAN RNC/RNC231 NodeB/T_AR_Baynoonah_U_288_U900
FDDCell/T_WR_BAYNOONAH_U900_F1_C
2014-12-10T16:29:27 +0400
Critical
Cleared
2014-12-10T19:21:12 +0400
FALSE
State change to Disable Failed
Associated BTS:T_AR_Baynoonah_U_288_U900, $site.name$, Correlated
notification: 20141210162927Z, RNC Shelf number\Board Slot position\Adjunct
Processor:0\12\1, Source Indicator:RESOURCE_OPERATION
underlyingResourceUnavailable
State change to Disable Failed
Inhibit rule;
RNC_0021_00020
EM RNCRNC231
RNC231
quality of service
NW:UTRAN RNC:RNC231
NodeB:T_AR_Baynoonah_U_288_U900 FDDCell:T_WR_BAYNOONAH_U900_F2_A
NW/UTRAN RNC/RNC231 NodeB/T_AR_Baynoonah_U_288_U900
FDDCell/T_WR_BAYNOONAH_U900_F2_A
2014-12-10T16:29:27 +0400
Critical
Cleared
2014-12-10T19:21:12 +0400
FALSE
State change to Disable Failed
Associated BTS:T_AR_Baynoonah_U_288_U900, $site.name$, Correlated
notification: 20141210162927Z, RNC Shelf number\Board Slot position\Adjunct
Processor:0\12\1, Source Indicator:RESOURCE_OPERATION
underlyingResourceUnavailable
State change to Disable Failed
Inhibit rule;
RNC_0021_00020
EM RNCRNC231
RNC231
quality of service
NW:UTRAN RNC:RNC231
NodeB:T_AR_Baynoonah_U_288_U900 FDDCell:T_WR_BAYNOONAH_U900_F1_B
NW/UTRAN RNC/RNC231 NodeB/T_AR_Baynoonah_U_288_U900
FDDCell/T_WR_BAYNOONAH_U900_F1_B
2014-12-10T16:29:27 +0400
Critical
Cleared
2014-12-10T19:21:12 +0400
FALSE
State change to Disable Failed
Associated BTS:T_AR_Baynoonah_U_288_U900, $site.name$, Correlated
notification: 20141210162927Z, RNC Shelf number\Board Slot position\Adjunct
Processor:0\12\1, Source Indicator:RESOURCE_OPERATION
underlyingResourceUnavailable
State change to Disable Failed
Inhibit rule;

So this might be the reason, why we do not see the cell fluctuation in the
latest

logs.

BR
Rasto

21. 22-Jan-2015 12:37


rkosorin

Hi Rasto,

Thanks for your feedback , Kindly note that the site is stable from KPIs and
also
no alarms of cell fail observed since 18.1.2015,

Thanks to close this AR.

Thanks,

-BR,
Karim

22. 22-Jan-2015 12:39


rkosorin

Update to Current Summary: Issue caused by TMU instability. TMU issue


solved.
Closure aproval granted.
Resolution
Issue caused by TMU instability. TMU issue solved. Closure aproval granted.

End of Assistance Request 1-5514132


New AR:

View AR | AR without Proprietary | OLCS


History | States | Assignment | Timetracking
AR Text Search | More | CARES Home

You might also like