Vendor Escalation Trouble Report (TR) Form

Originated by: E-mail: Engineer reference Number:

Robi Syaaban robi.syaaban@huawei.com HWA_BSC-0356
Hidayat
Email:
TR Issued by: Region:

Jabodetabek ( ) West (X ) Central ( ) East ()

Telephone Number: Extension: Notification Date: Notification Time:
087884279303 6145-59502 Nov 8, 2015 16:00
Network Element: Site ID/No.: Product/Service Name:
BJMB3 BSC6900 GSM

Dispatch to Vendor: Dispatched Date: Dispatched Time: XL Reference Number (SAP M3#):
HTI Nov 11,2015 15:51 5022331

Trouble Informations at PT. XL Axiata

Type of Service
On site Intervention ( ) Technical Query Service ( ) Consultation ( )

Trouble Priority:
Emergency ( ) Critical ( ) Major (X) Minor ( )
Time for Emergency: ( Only Emergency Priority)

Trouble Heading:
Board Hardware Fault

Need your help to find root cause & solving Board Hardware Fault, we have done :

- Swap Board OIUa (Subrack 7 Slot 18 & Slot 20)

- Replace Board OIUa (Subrack 7 Slot 18 & Slot 20)
- Reset Board OIUa (Subrack 7 Slot 18 & Slot 20)

Alarm clear but next day, alarm rise again

Regards,
WidyaM

Please Response to: Noc_tr@xl.co.id Page 1 of 7

Cc: NCTT@xl.co.id
Version# 1.0
 Vendor Escalation Trouble Report (TR) Form

Vendor Responses
Response by: Response Date: Response Time: Vendor Ticket Number:
th
Zhaowenwen 11 November 2015 16:55 PM SR 5376585

Cleared Date: Response Time: Hardware Replacement :

th
18 November 2015 14:34 PM (X) Yes () No

Please get below analysis:

Analysis:
Base on the alarm, we can see currently 6-20 and 7-18 persisted report board hardware fault alarm with Forwarding
component..

Base on the FAD log, we can see both board already replaced, but alarm persist.
6-20 may replaced at 23rd, Oct.
7-18 may replaced at 4th, Nov.

Operation as below, we can see many times of board reset.

Checking the DEBUG log:

Please Response to: Noc_tr@xl.co.id Page 2 of 7
Cc: NCTT@xl.co.id
Version# 1.0
 Vendor Escalation Trouble Report (TR) Form

For 6-20, when alarm report at 2015/11/7 22:20, we can see report 0x351(849) and parameter is 0x53(83),0x44(68), which
means board detect PRBS fault.

For 7-18, base on the FAD log at 2015/11/5 14:17, board also report 849 and paramter as 0x53 and 0x44.(which same as 6-
20).

As further checked, when signaling link fault will trigger detection, at the same time, also have TDM detection.
These two type detection confilct and cause detection failure (as DEBUG log shows), then report this alarm.

From alarm log, we also can see there are many MTP3LNK alarm which related to MTP3LNK 1 and 2.

Please Response to: Noc_tr@xl.co.id Page 3 of 7

Cc: NCTT@xl.co.id
Version# 1.0
 Vendor Escalation Trouble Report (TR) Form

MTP3LNK configuraiton as below:

MTP3LNK 1 and 2 related to A interface board 6-20 and 7-18 which report alarm.

Also we can see many transmission alarm related to the ater path of the two MTP3LNK:

Please Response to: Noc_tr@xl.co.id Page 4 of 7

Cc: NCTT@xl.co.id
Version# 1.0
 Vendor Escalation Trouble Report (TR) Form

Related to ater port 8:

Please Response to: Noc_tr@xl.co.id Page 5 of 7

Cc: NCTT@xl.co.id
Version# 1.0
 Vendor Escalation Trouble Report (TR) Form

Related to ater port 0:

Solution:
Solution 1: since we see many alarm related to Ater path which cause MTP3LNK frequently get fault, please improve the
ater transmission, especially ater path/port which used for MTP3LNK (SRN=1, SN=16, PN=0 and SRN=0, SN=16, PN=8)
When MTP3LNK not frequently get fault, will not report this alarm.
0-16---6-14
1-16---6-16
3-16---7-14
4-16---7-16

Solution 2: if the ater transmission difficult to solve, can restore the Board Hardware Fault alarm first
as below:
Run MML:SET TNSOFTPARA: MTP2ResumeSwitch=OFF; to disable the link fault detection, and then reset board (6-20/7-
18).

Please Response to: Noc_tr@xl.co.id Page 6 of 7

Cc: NCTT@xl.co.id
Version# 1.0
 Vendor Escalation Trouble Report (TR) Form

Conclusion:
After implement solution 2 and alarm cleared; until 20th, Nov, no more alarm happened again.

Please Response to: Noc_tr@xl.co.id Page 7 of 7

Cc: NCTT@xl.co.id
Version# 1.0