AR100

New AR: View AR | AR without Proprietary

History | States | Assignment | Timetracking

AR Text Search | More | CARES HomeAssistance 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 3

Priority 3

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 Email [email protected]

Request Method Email-CR

Dates

Occurred 29-Dec-2014 15:11 Time now 29-Aug-2015 13:24 (GMT+4)

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 Respond Target 30-Dec-2014 15:11 SA - Calculated

Restored 07-Jan-2015 11:00 Restore Target -- --- ---- SA - None

Resolved 22-Jan-2015 12:39 Resolve Target 02-Mar-2015 19:42 SA - Calculated

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 Modified By archive

Entitlement

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 **"

<[email protected]>

Sent: 2014-12-29 12:11:55

To: ALU Support <[email protected]>

Subject: RE: Repeated cell instability on the site 288

Hi,

Severity 3.

Thanks,

--

BR,

Karim Ibrahim

From: [email protected] [mailto:[email protected]]

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

Contact Given Name : Ibrahim

Contact Phone :+971 56 354 4568

Contact Company : Alcatel-Lucent

Company : Emirates Telecommunications Corporation

Contract Number : OXIA 627085

Region : EMEA

Country : United Arab Emirates

City : Abu Dhabi

Site : ETISALAT ABU DHABI

Product Instance : 9926 DBS-WCDMA

Severity : 3

Priority : 3

Product Version : LR13.3W

Severity : 1

Action taken: Change SG, Reset the TMUs, the issue solved for short time

and come back.

Logs: Attached HFB.

Outage : No

Internal/External: :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.alcatel-lucent.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.alcatel-lucent.com%2fowa%2fUrlBlockedError.aspx>

2010-668-44-810

ONNET: 2205 5534

Showing Investigation and Proprietary logs together in time order Show separately

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 ALCATEL-LUCENT PROPRIETARY dmajer

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: [email protected]

To: "IBRAHIM ABD EL NABY, Karim (Karim)** CTR **"

<[email protected]>

Cc: "BERIDY, AHMED (AHMED)" <[email protected]>, "REDA, RAMY

(RAMY)" <[email protected]>, "ELHAKIM, Mohamed (Mohamed)** CTR **"

<[email protected]>, "ABDEL-HALIM, SAYED (SAYED)"

<[email protected]>, "NADER, Mohamed (Mohamed)** CTR **"

<[email protected]>, "ZAHABI, RAMSEY (RAMSEY)"

<[email protected]>, "OKASHA, TAHER (TAHER)"

<[email protected]>

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) Please do telnet to the RNC, where the problematic cell is mapped. Log the

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






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 ALCATEL-LUCENT PROPRIETARY rkosorin

Dear TEC,

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


Time Tracking Entry Added - IR01-TSA4


Time Tracking Entry Added - IR01-TSA3


Hello Manuela,

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

BR

Rasto

9. 12-Jan-2015 20:36 ALCATEL-LUCENT PROPRIETARY mdiwanou

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


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


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


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


Just an additional info - customer just replaced CCM board for this NodeB.

Unfortunately the issue is still persisting.

Rasto


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


In addition,

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




/disabled/failed//




/disabled/failed//




/disabled/failed//


BTSEquipment/T_AR_U_288_Baynoonah NodeBCP/0


/disabled/failed//


BTSEquipment/T_AR_U_288_Baynoonah NodeBCP/0


/enabled///




/enabled///




/enabled///




/enabled///




/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 }

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


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 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 - 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 (13-14.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


Hi Rasto,

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 - indeed, looking at the old logs it can be

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-12-10T16: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 PMC-TMU

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.

AR100

Documents

Transcript of AR100