Nm Mb Mobile

Nonstandard MaintenanceControl

NM:MB

A30828-Y1187-N510-2-7620

2 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805807edb1c

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2007. All rights reserved

f Important Notice on Product Safety Elevated voltages are inevitably present at specific points in this electrical equipment. Some of the parts may also have elevated operating temperatures.

Non-observance of these conditions and the safety instructions can result in personal injury or in property damage.

Therefore, only trained and qualified personnel may install and maintain the system.

The system complies with the standard EN 60950 / IEC 60950. All equipment connected has to comply with the applicable safety standards.

The same text in German:

Wichtiger Hinweis zur Produktsicherheit

In elektrischen Anlagen stehen zwangsläufig bestimmte Teile der Geräte unter Span-nung. Einige Teile können auch eine hohe Betriebstemperatur aufweisen.

Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Körperverlet-zungen und Sachschäden führen.

Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die Anlagen installiert und wartet.

Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene Geräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.

A30828-Y1187-N510-2-7620

3

NM:MB

Id:0900d805807edb1c

Table of ContentsThis document has 156 pages.

Change History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1 Introduction to NM:MB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1 Target Group of this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Reference to additional documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Interpretation of the diagnosis results for MBD . . . . . . . . . . . . . . . . . . . 102.1 Brief Description of the MBD Diagnosis. . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Preparation for diagnosis of an MBD side or a unit . . . . . . . . . . . . . . . . 102.3 Internal hardware test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 XLINK Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 MB SN interface test for SNA, SNB or SND in B-Mode. . . . . . . . . . . . . 142.6 MB SN interface test for SND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.7 Timers used for MBD diagnosis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.8 MBD Diagnosis Output mask. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.9 Diagnosis of an MB unit/MB side is not executed . . . . . . . . . . . . . . . . . 17

3 Interpretation of the MBB Diagnosis Results . . . . . . . . . . . . . . . . . . . . . 183.1 Brief Description of the MBB Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 MBU:LTG - Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 MBU:LTG - Test Phase 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4 MBU:LTG - Test Phase 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.5 MBU:LTG Output Masks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.6 MBU:LTG Interpretation of TEST BLOCK NO . . . . . . . . . . . . . . . . . . . . 233.7 MBUL - Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.8 MBU:SGC - Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.9 MBU:SGC - Test Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.10 MBU:SGC - Test Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.11 MBU:SGC - Test Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.12 MBU:SGC - Output Masks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.13 MBU:SGC - Interpretation of the TEST BLOCK NO . . . . . . . . . . . . . . . 453.14 MBUS - Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.15 Diagnosis of an MBU (of an MB) is not executed . . . . . . . . . . . . . . . . . 51

4 Interpretation of MBD alarm messages . . . . . . . . . . . . . . . . . . . . . . . . . 534.1 MBD - IO processor numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.2 MMN:MB210-2001 - MBIA or MBIH MODULE FAILURE . . . . . . . . . . . 554.3 MMN:MB210-2002 - MBIA or MBIH IBUS FAILURE. . . . . . . . . . . . . . . 624.4 MMN:MB210-2003 - MBIA or MBIH XLINK FAULT. . . . . . . . . . . . . . . . 644.5 MMN:MB210-2004 - MBIA or MBIH TOO MANY RESETS. . . . . . . . . . 664.6 MMN:MB210-2005 - MBIA or MBIH OLD FW LOADED . . . . . . . . . . . . 674.7 MMN:MB210-2007 - MBIH: NO CONNECTION TO SN POSSIBLE . . . 684.8 MMN:MB212-2001 - ATMB FAILURE . . . . . . . . . . . . . . . . . . . . . . . . . . 724.9 MMN:MB214-2001 - MBIA STATISTIC FAULT . . . . . . . . . . . . . . . . . . . 744.10 MMN:MB215-2001 - MBIC MODULE FAILURE . . . . . . . . . . . . . . . . . . 774.11 MMN:MB215-2002 - MBIC IBUS FAILURE. . . . . . . . . . . . . . . . . . . . . . 79

4 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805807edb1c

4.12 MMN:MB215-2004 - MBIC TOO MANY RESETS . . . . . . . . . . . . . . . . . 804.13 MMN:MB215-2005 - MBIC OLD FW LOADED. . . . . . . . . . . . . . . . . . . . 814.14 MMN:MB215-2006 - MBIC NO LOOP RESPONSE . . . . . . . . . . . . . . . . 824.15 MMN:MB215-2007 - MUTILATED LOOP RESPONSE . . . . . . . . . . . . . 844.16 MMN:MB215-2008 - NO IO PORT ACCESSIBLE . . . . . . . . . . . . . . . . . 864.17 MMN:MB215-2009 - IOPORT FAULTY . . . . . . . . . . . . . . . . . . . . . . . . . 884.18 MMN:MB PR:MB - EQUIPMENT ALARM. . . . . . . . . . . . . . . . . . . . . . . . 904.19 MMN:MB225-2001: MBICG PARTIAL FAULT: MODULE FAILURE . . . 914.20 MMN:MB225-2002:

MBICG XLINK FAULT: MASTER/SLAVE SYNCH FAILURE . . . . . . . . . 944.21 MMN:MB225-2003: MBICG TOTAL FAULT: MODULE FAILURE . . . . . 954.22 MMN:MB235-2001: MBICG: CLOCK REFERENCE FAILURE . . . . . . . 974.23 Interpretation of alarm mask for MBICG failures. . . . . . . . . . . . . . . . . . . 984.24 MMN:MB240-2001 - MBIE MODULE FAILURE . . . . . . . . . . . . . . . . . . 1004.25 MMN:MB240-2002 - MBIE IBUS FAILURE . . . . . . . . . . . . . . . . . . . . . 1024.26 MMN:MB240-2003 - MBIE XLINK FAULT . . . . . . . . . . . . . . . . . . . . . . 1044.27 MMN:MB240-2004 - MBIE TOO MANY RESETS . . . . . . . . . . . . . . . . 1064.28 MMN:MB240-2005 - MBIE OLD FW LOADED . . . . . . . . . . . . . . . . . . . 1074.29 MMN:MB240-2006 - FPGA ERROR. . . . . . . . . . . . . . . . . . . . . . . . . . . 1084.30 MMN:MB240-2007 - ETHERNET ERROR . . . . . . . . . . . . . . . . . . . . . . 1094.31 MMN:MB241-2001 - MBIE IP DATA ERROR. . . . . . . . . . . . . . . . . . . . 1104.32 MMN:MB243-2000 - COM PROT ERROR . . . . . . . . . . . . . . . . . . . . . . 1134.33 MMN:MB244-2000 - MBIE LOSS OF SIGNAL . . . . . . . . . . . . . . . . . . . 1174.34 MMN:MB245-2000 - MBIECH TOTAL FAULT . . . . . . . . . . . . . . . . . . . 1214.35 MMN:MB246-2000 - MBIECH PARTIAL FAULT . . . . . . . . . . . . . . . . . 1244.36 MMN:MB247-2001 COMMUNICATION TO MG FAILED (MGC INTER-

NAL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1254.37 MMN:MB247-2002

COMMUNICATION TO MG FAILED (MGC EXTERNAL). . . . . . . . . . . 1264.38 MMN:MB247-2003 - MGCP VERSION MISMATCH . . . . . . . . . . . . . . 1264.39 MMN:MB247-2004 - MGC INTERNAL SOFTWARE ERROR . . . . . . . 1274.40 MMN:MB230-2000 - ERROR MESSAGE. . . . . . . . . . . . . . . . . . . . . . . 127

5 Interpretation of the MBB Fault Messages . . . . . . . . . . . . . . . . . . . . . . 1315.1 MBB - IO Processor Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1315.2 MMN:MB110-1002 - NO LOOP RESPONSE . . . . . . . . . . . . . . . . . . . . 1315.3 MMN:MB110-1003 - MUTILATED LOOP RESPONSE . . . . . . . . . . . . 1335.4 MMN:MB110-1004 - MBU ERROR. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1355.5 MMN:MB110-1005 - MESSAGE BUFFER ALARM . . . . . . . . . . . . . . . 1375.6 MMN:MB110-1006 - EXCESSIVE MBU RESETS . . . . . . . . . . . . . . . . 1375.7 MMN:MB110-1007 - RESYNCHRONIZATION FAILURE. . . . . . . . . . . 1395.8 MMN:MB PR:MB - EQUIPMENT ALARM. . . . . . . . . . . . . . . . . . . . . . . 1405.9 MBB FAILURE WITHOUT CONFIGURATION . . . . . . . . . . . . . . . . . . . 1405.10 MMN:MB130 - ERROR MESSAGE DURING CONF.. . . . . . . . . . . . . . 1475.11 MMN:MB130 - ERROR MESSAGE FROM MBU.... . . . . . . . . . . . . . . . 148

6 Replacement Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1546.1 Replacing MBD modules MBDA, MBDH, MBDE . . . . . . . . . . . . . . . . . 1546.2 Replacing MBD modules MBDC, MBDCG . . . . . . . . . . . . . . . . . . . . . . 154

A30828-Y1187-N510-2-7620

5

NM:MB

Id:0900d805807edb1c

6.3 Replacing MBB modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1546.4 Replacing Current Converter and Associated Fuse. . . . . . . . . . . . . . . 1556.5 Replacing F:MBD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1556.6 Replacing F:MB/CCG(B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

6 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805807edb1c

List of FiguresFigure 1 HDLC interface MBIH <--> SND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Figure 2 HDLC interface MBIH <--> SND in B-Mode for DE52. . . . . . . . . . . . . . . 59Figure 3 HDLC interface MBIH <--> SNA/SNB. . . . . . . . . . . . . . . . . . . . . . . . . . . 60Figure 4 Optical interface MBD <--> SCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Figure 5 Optical interface MBD <--> SCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Figure 6 Fault handling for IBUS faults between two modules . . . . . . . . . . . . . . . 63Figure 7 HDLC interface MBIH <--> SND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Figure 8 HDLC interface MBIH <--> SNA/SNB. . . . . . . . . . . . . . . . . . . . . . . . . . . 72Figure 9 HDLC interface MBIH <--> SND in B-Mode for DE52. . . . . . . . . . . . . . . 72Figure 10 Optical interface MBD <--> SCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Figure 11 Optical interface MBD <--> SCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Figure 12 Fault handling for IBUS faults between two modules . . . . . . . . . . . . . . 103Figure 13 Example SURPASS hiG1600 database at hIE9200 . . . . . . . . . . . . . . . 112Figure 14 Physical interconnection MBD/LAN - COPL . . . . . . . . . . . . . . . . . . . . . 123

A30828-Y1187-N510-2-7620

7

NM:MB

Id:0900d805807edb1c

List of TablesTable 1 Fault information for the MBDH, MBDE and the MBDA . . . . . . . . . . . . 11Table 2 Fault information (test block number) for MBDC . . . . . . . . . . . . . . . . . . 12Table 3 Diagnosis timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Table 4 Test steps of phase 1 MBU:LTG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Table 5 SG.OPER: Interpretation MBLOOP for MBU:LTG . . . . . . . . . . . . . . . . 21Table 6 Interpretation Table: TEST BLOCK NO for MBU:LTG . . . . . . . . . . . . . 23Table 7 Test steps of phase 1: MBU:SGC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Table 8 SG.OPER: Interpretation MBLOOP for MBU:SGC . . . . . . . . . . . . . . . . 43Table 9 Interpretation table: TEST BLOCK NO for MBU:SGC . . . . . . . . . . . . . 45Table 10 MB processors for MBD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Table 11 Assignment of MCH to ASIC on M:MBDH . . . . . . . . . . . . . . . . . . . . . . 58Table 12 Assignment of SGC IF interfaces to ASIC on M:MBDH . . . . . . . . . . . . 59Table 13 Allocation of the MCHs to the ASICs on M:MBDH . . . . . . . . . . . . . . . . 60Table 14 Assignment of SGC IF interfaces to ASIC on M:MBDH . . . . . . . . . . . . 71Table 15 Allocation of the SGC IF interfaces to the ASIC on M:MBDH . . . . . . . . 72Table 16 Assignment of SGC IF interfaces to ASIC on M:MBDH . . . . . . . . . . . . 72Table 17 Interpretation of SUPPLEMENTARY INFORMATION . . . . . . . . . . . . . 99Table 18 MB channel numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Table 19 Correlation between MBIE number, MBU number and LTGSET . . . . 116Table 20 LTG allocation GPPxx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Table 21 MB channel numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Table 22 LTG allocation GPPxx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Table 23 Correlation between MBIE number, MBU number and LTGSET . . . . 121Table 24 MBDE IP addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Table 25 MB processor numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

8 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806e8bb4

Change History

Change HistoryIssue 1 (01/2010)Editorial changes.

A30828-Y1187-N510-2-7620

9

NM:MB Introduction to NM:MB

Id:0900d805800bec0a

1 Introduction to NM:MB

1.1 Target Group of this ManualThis NM:MB contains notes which are designed to support special maintenance for MB faults.

An MB hardware fault can usually be cleared by using procedures which are included in Maintenance Manual MMN:MB. This documentation for special MB maintenance is not required in all these cases.

The fault must be cleared by a system specialist only if the specified procedures are unsuccessful. As further support for specialists, additional information is given in the NM:MB for each type of fault.

The documentation specified in the next section is also important for special mainte-nance.

1.2 Reference to additional documentation • Of particular importance for Nonstandard Maintenance is the manual Construction;

Section Racks offers an overview of the equipment containing MB frames and the fuse assignments. Sections Frames F:MB/CCG and Frames F:IOPMBD provides the layout of MB frames and cabling according to cable list. The interpretation of the LEDs on the module faceplates is given in section Modules MB.

• The documentation overview gives detailed information about all the general aspects and about fault clearance

• On inserting and removing modules and cables the applicable ESD specifications (EN60950/IEC60950) have to be taken into account.

10 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec08

Interpretation of the diagnosis results for MBD

2 Interpretation of the diagnosis results for MBDThis documentation describes the procedures involved in MB diagnosis in detail:

The sequence and the functions of the individual test phases are explained. This provides an overview of the sequence of the diagnosis of the MB and allows an operator to specify a discovered malfunction and also pinpoint it more exactly.

All necessary input commands, possible system responses, reaction times to be taken account of and the significance of the various elements of the diagnosis output masks.

2.1 Brief Description of the MBD DiagnosisThe MBD diagnosis is a complete function test (overall test) of an MB unit or of an entire MB.

Parallel running of the MB diagnosis with call processing is not possible as they both interfere with each other. For example, faults are deliberately produced in an MB unit during diagnosis and their reactions are checked or, as a test condition, certain synthetic message sequences must be generated.

The MB diagnosis can therefore only run in off-line operation, i.e. before the start of the diagnosis the appropriate MB unit or MB must be MBL.

The MB diagnosis is not automatically initiated by the system, but rather by the user by means of MML commands.

The MB consists of several units in each side of the system. If diagnosis of a complete MB is called up here, all the relevant units are tested individually and consecutively by the system. Because of the modular design of the MB, no additional test stages are required. For the diagnosis of the MBIC (interface to the CP) or the clock module MBDCG, the diagnosis of an entire MB side must be called up.

The diagnosis of an MB unit includes a hardware test and the test of the direct connec-tion to the redundant unit (XLINK test). In the case of an MBIH, the SN interface is also tested (SNFIMS). If an SND is connected the SN interface is only tested in a diagnosis of a complete MB side. The hardware test corresponds to the sequence of the BOST (BoardOnSelfTest).

2.2 Preparation for diagnosis of an MBD side or a unita) For an MBIC and an MBICG

The diagnosis for an MBIC or an MBICG cannot be started individually. The units to be tested of the MBD side must be in MBL. After the diagnosis has been called up by the operator (MML command), the MBIC, MBIH and MBIA units are configured by the diagnosis software in the CP to SEZ. A prerequisite for SEZ is a successfully completed RESTART in the MB units concerned. RESTART is a special interface signal sent by the IOP:MB. In the MB unit, RESTART resets the hardware and rein-itializes the firmware. In a complete diagnosis, subsequently all connected SN units are configured to SEZ provided that they were in NAC.

b) For an MBIH, MBIE and MBIAThe MBIH, MBIE or the MBIA to be tested must be in MBL. The CP carries out a plausibility test and the number of the specified unit is tested. After the diagnosis has been called up by the operator (MML command), the MBIH, MBIE or MBIA unit is

A30828-Y1187-N510-2-7620

11

NM:MB Interpretation of the diagnosis results for MBD

Id:0900d805800bec08

configured by the diagnosis software in the CP to SEZ. A prerequisite for SEZ is a successfully completed RESTART in the MB units concerned. In the MB unit, RESTART resets the hardware and reinitializes the firmware. Should an MBIH be diagnosed, the appropriate SN units are also configured to SEZ: For an MBIH con-figuration, a maximum of 2 SSGs and 4 TSGs in SNA/SNB, or 2 SNMUX in SND - for total diagnosis (complete MB side) all connected SNMUX and the MATC, provided that they were in NAC.

2.3 Internal hardware testTest scopeAll the test stages which can be executed without the involving the CP will be carried out in an appropriate sequence by the MBD firmware.

Test sequenceThis test phase is started by the CP by sending the MBDDIAG command to module MBDC. The further test procedure is controlled internally by the hardware and the firmware of the modules and, therefore, the CP does not have any additional influence. Modules MBDC, MBDH and MBDA: The ASIC including the BIST (ASIC self-test), FEPROM (master ASIC), SRAM, DRAM and start-up are tested. Module MBDE FEPROM (master processor), SRAM, DRAM start-up and ethernet Phy-modules are tested. A diagnosis of the complete MB side also includes resetting the control (MBDC). 8 and 50 MHz clock faults are also detected.

For complete diagnosis of a module or an MB side, the MBD_MTC (on MBDC) collects the MBDREADY/MBDERR messages of the individual ASICs/processors. Before the result can be reported to the CP, another IBUS test of the side is carried out. The diag-nosis result is reported to the CP with MBDDIAGR.

A diagnosis PROGRESS MESSAGE with the reason HARDWARE FAULT and an FLN number are displayed on the user terminal.

The test phases are time-controlled. Should the CP not receive an answer within 50 seconds, HARDWARE FAULT is displayed without any additional information.

This completes the diagnosis for MBIC and MBICG, whereas further tests are carried out for MBIH, MBIE and MBIA.

Return values of the MBDDIAGR messageThese values do not appear on the user terminal, but can be read from the SG.OPER. The values correspond with the fault information of the MBDERROR message. Routine tests and the diagnosis use identical test procedures.

Byte 07 contains the error information for MBDC, bytes 08 up to 15 contain the error information for MBDH0 up to MBDH7 or bytes 15 down to 08 for MBDE and Bytes 16 up to 20 for MBDA0 up to MBDA4

Value Remark

00 The diagnosis of the module was carried out fully and no fault was detected.

Table 1 Fault information for the MBDH, MBDE and the MBDA

12 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec08


03 ASIC/processor does not send READY. The ASIC MBDIF on module MBDC sends a RESET request to the MBIH or MBIA to be tested. Acknowledgments of a RESET request are sent via the IBUS to the MBDC. The MBDREADY acknowledgment failed to appear within a specified time limit.

04 Fault in the FEPROM checksum test. A fault was detected on testing the FEPROM, i.e. the incre-mented horizontal sum of the stored bytes did not correspond with the stored checksum.

05 Parity error. The data bus between the ASIC/processor and the SDRAM is tested. For write access to the SDRAM, a parity bit is calculated for each byte. The parity bit is supplemented for even parity. The parity is stored with the data in the SDRAM. For read access of the SDRAM, the parity of the read data is recalculated and compared with the stored parity.

06 SDRAM fault. A fault was detected on testing the SDRAM, i.e. either the writability or the readabil-ity of the memory is not guaranteed.

07 Memory protection violation (access of ASIC/processor to SDRAM is checked).

08 Memory shortage

09 ASIC ATM230 on module MBDA does not send a READY to RESET request

0A IBUS fault bus test: The internal bus system on the MBDH, MBDE or MBDA is tested. For this, a test loop runs from the IBUS output to the corresponding IBUS input via the rear panel of the module frame. The IBUS switch is tested via this connection. Faults are detected if the test pattern did not arrive after a timer has expired or if a test pattern was mutilated.

0B BIST (built-in self-test) detected faults. The entire logic of the ASIC including the RAM of MBDH and MBDA are tested.

14 Job code 2 fault

15 Length fault: Incorrect command length. The length of the message does not correspond to the value specified in the header

Value Remark

00 Full diagnosis of the module was performed and no fault was found.

02 RESBUS fault (faulty reset bus) An interrupt which is acknowledged with RESBUS_RDY is initi-ated in all the ASICs in the READY mode (incl. both MBDIFs) via the RESBUS. If an acknowl-edgment fails to appear, the interrupt is repeated after 10 s. If RESBUS_RDY fails to appear twice on the MBDIF master, the RESBUS is found to be faulty.

04 Fault in the FEPROM checksum test. A fault was detected when testing the FEPROM, i.e. the incremented horizontal sum of the stored bytes did not correspond to the stored checksum.

05 Parity error. The data bus between the ASIC and the SDRAM is tested. For write access to the SDRAM, a parity bit is calculated for each byte. The parity bit is supplemented for even parity. The parity is stored with the data in the SDRAM. For read access of the SDRAM, the parity of the read data is recalculated and compared with the stored parity.

06 SDRAM fault. A fault was detected on testing the SDRAM, i.e. either the writeability or the read-ability of the memory is not guaranteed.

07 Memory protection violation (access of ASIC to SDRAM is checked).

08 Memory shortage

0A IBUS fault bus test: The internal bus system on the MBDC is tested. For this, a test loop runs from the IBUS output to the corresponding IBUS input via the rear panel of the module frame. The IBUS switch is tested via this connection. Faults are detected if the test pattern did not arrive after a timer has expired or if a test pattern was mutilated.

0B BIST detects faults (built-in self-test). The entire logic of the ASIC including the RAM are tested.

Table 2 Fault information (test block number) for MBDC

Value Remark

Table 1 Fault information for the MBDH, MBDE and the MBDA (Cont.)

A30828-Y1187-N510-2-7620

13


Id:0900d805800bec08

Hardware test of module MBDCGThe test of the group clock generator MBDCG in the course of MB diagnosis basically corresponds to periodic routine test initiated by the STAGCG command. The output values of the fault information of the MBDDIAGR message correspond to the fault infor-mation of the MB_MEGCG message, see 4.23 Interpretation of alarm mask for MBICG failures

In the first stage a test is performed to establish whether or not an alarm has been set. Because the alarm registers are reset automatically at the end of an alarm, a set alarm means continuous malfunctioning on module MBDCG. Therefore, the diagnosis is ter-minated with the result FAULTS DETECTED

If there is no alarm, the test is continued with the fault detection circuits. The clock super-vision is then tested by PLL supervision.

To test the clock supervision, the clock input is blocked by the diagnosis program. The supervisory circuit must react and report the clock failure with an alarm. The clock input is then released again. If the supervisory circuit works correctly, the clock alarm is reset again.

In conclusion, if the clock supervision is evaluated as "fault-free", the PLL supervisory circuit is also tested. The PLL supervisory circuit always compares the phase position of the input clock with the phase position of the output clock of the group clock generator. For the test, one of the signals is inverted (phase shift by half a period). PLL supervision must react and report a PLL alarm. The conversion is then canceled again. If the PLL supervisory circuit works correctly, the clock alarm is reset again.

If no malfunction was identified during these test stages, the group clock generator is evaluated as fault-free.

2.4 XLINK Test Test scopeIn order to be able to execute the cross link connection test, a test is performed to check that the redundant unit is in ACT. The direct connection between the unit specified when diagnosis is called and the appropriate redundant unit is tested.

Test sequenceThe CP sends two consecutive MBDXLINK commands to the specified unit and the redundant unit provided that the specific command was acknowledged with MBDX-LINKR.

14 Job code 2 fault. An incorrect JOB code 2 was detected for an MBU command. (MBU command = a command which should be executed by the MBU. In contrast to this, there are the more frequent messages which the MBU only has to forward

15 Length fault: Incorrect command length. The length of the message does not correspond to the value specified in the header

17 Incorrect MBU number. Message with invalid MBU number

18 Incorrect channel numberAn incorrect channel number was specified as the destination MCH for a message with the TRASIN format or for an MBU command.

Value Remark

Table 2 Fault information (test block number) for MBDC (Cont.)

14 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec08


The diagnosis result is reported to the CP with MBDXLINKR. A timer is set for both the specified unit and the redundant unit. If the specific MBDXLINKR acknowledgment is not sent after 10 sec, MB XLINK ERROR is output to the operator without further informa-tion.

If the acknowledgment is sent and contains an indication of a crosslink error, a corre-sponding diagnosis PROGRESS MESSAGE with the warning MB XLINK ERROR and an FLN number is output at the operator terminal.

If the CP does not detect any malfunction, it ends diagnosis of MBIA or MBIE with the result NO FAULT DETECTED

This completes the diagnosis for MBIA and MBIE, whereas a further test, of the SN inter-face, is carried out for the MBIH. If an SND is connected the SN interface is only tested in a complete MB diagnosis.

2.5 MB SN interface test for SNA, SNB or SND in B-ModeTest scopeThe interface (SDC:SGC) between the MBU:SGC on the MBDH modules and the con-nected switch group control (SGC) is tested. Module MBDH contains 2 virtual MBU:SGCs. Each virtual MBU:SGC has a physical connection to an SSG and one to each of two TSGs. Channel 1 and 2 for TSG and channel 3 for SSG are used for syn-chronization. The number of connected switch groups depends on the expansion stage.

In SND in B-Mode, TSG and SSG exist as logical units on SNMUX. One SNMUX com-prises 2 TSG and 1 SSG. The TSG and SSG firmware is simulated on module MUXC with the restrictions that cross connection between TSG and SSG of different system sides is not provided.

Test sequence:The CP software starts this test phase by displaying CHON commands (= channel on) to the MBU:SGC. Because each connected SGC is connected to the MBU:SGC with one message channel (MCH), a maximum of 3 MCHs are affected by these commands. If the MBU:SGC contains the CHON commands it tries to synchronize the connected MCHs. In the case of successful synchronization, the connected SGC generates the FIMS functional parameter information. If the SNFIMS acknowledgments fail to appear, diagnosis is terminated after 1 second with the result = fault detected and a diagnosis PROGRESS MESSAGE is displayed with MB SN INTERFACE ERROR. If both connec-tions to the SN are faulty, two messages are displayed. The relevant MCHs are also specified in the information byte.

If the CP does not detect any malfunction, it ends diagnosis of the MBIH with the result NO FAULT DETECTED

2.6 MB SN interface test for SNDTest scopeA test of all connected SND links (S1 and S3) is performed by invoking a synchronization of the involved channels to the SND units. The SND link test procedure for diagnosis of a complete MB and diagnosis of an MBIH is slightly different. For total diagnosis the MBD has to be informed about the connected SN type. After reset of the controller the MBD loses the information about the connected SN type and sets the default value SNB.

A30828-Y1187-N510-2-7620

15


Id:0900d805800bec08

By means of command MBD_SNTYP the CP informs the controller which type is con-nected. Reply of the command is supervised by a 10 seconds timer. If message SNTYPR is not received within this interval or indicates a fault, HARDWARE FAULT is output in the additional information the value H’FF is set for each of the diagnosed units.

Test sequenceMBDSCHON commands (= channel on) are sent to each MBDH to be diagnosed in order to synchronize all channels to the equipped SND units. Since it is possible that one ore two SNMUX are connected, it depends on the actual connected equipment whether two or four S1 channels are synchronized. However, it is fixed that always both S1 channels to an equipped SNMUX and both S3 channels to MATC are tried to be syn-chronized. In the case of successful synchronization, the respective units respond by message SNFIRMES with processor numbers of SNMUX or MATC indicating the sending unit. If the acknowledgments fail to appear after 1 second, the synchronization attempt with MBDCHON is repeated five times till the diagnosis is terminated a with the result = fault detected and a diagnosis PROGRESS MESSAGE is displayed with MB SN INTERFACE ERROR. for each tested MBDH with faulty links. The relevant MCHs are also specified in the additional information bytes.

If the CP does not detect any malfunction, it ends diagnosis of the MBIH with the result NO FAULT DETECTED

In an SN DE6.0 configuration without MATC a special handling is necessary.

Since no MATC is equipped, the switching functionality is supported by an SNMUX (as addition to its multiplexing functionality). Consequently, the S3 interfaces are connected to this unit which always has to be SNMUX0. For a switching SNMUX S1 as well S3 channels are synchronized, i.e. four SNDFIRMES are expected.

2.7 Timers used for MBD diagnosis

Timer Value Remark

TCB 0.1s Timer for canceling the memory contents

TD3 50s HARDWARE TEST

Waiting time between sending the MBDDIAG command and the arrival of MBDDIAGR with the test result

A current test phase is aborted if TD3 expires and the diagnosis ends with the result

HARDWARE FAULT

FAULTS DETECTED

TD4 10s XLINK TEST

Waiting time between sending the MBDXLINK command and the arrival of MBDX-LINKR with the test result


MB XLINK ERROR

FAULTS DETECTED

Table 3 Diagnosis timer

16 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec08


2.8 MBD Diagnosis Output mask As soon as the diagnosis has found a fault, the input command is repeated with the addi-tional information PART. EXEC'D (partially executed) and a PROGRESS MESSAGE is then displayed with all the diagnosis information. PROGRESS MESSAGE MMN:MB250-2000 TEST RESULT= @### TESTED UNIT= @########## FLN:@######### ERROR INFORMATION: @##################################### ADDITIONAL INFORMATION: @############################################################

After diagnosis is completed, the command is repeated once more, this time with the additional information EXEC'D. The diagnosis result then follows with the message that a fault was detected. (FAULTS DETECTED)

The suspect modules can be determined via the fault lists FL:MBD, FL:SNA2, FL:SNB2, FL:SND1 and FL:SND2 in MMN:MB.

If an MB SN INTERFACE ERROR was detected, SN modules are also suspect. The first bytes of the Additional Information mark the defective S1 and S3 channels. Depending on the SN type the suspect modules can be identified using FL:SNA2, FL:SNB2 and FL:SND in MMN:MB.

TD5 10s XLINK TEST

Waiting time between sending the MBDXLINK command and the arrival of MBDX-LINKR from the partner module with the test result


MB XLINK ERROR

FAULTS DETECTED

TD6 10s MBD_SNTYP

Waiting time between sending the SNTYP information from CP which SN is connected (only used for SND total diagnosis) and the arrival of acknowledgement SNTYPR from the MBD


HARDWARE FAULT

FAULTS DETECTED

TS1 1s (1s) MB SN INTERFACE TEST (only for MBIH diagnosis, or in case of SND: MB diag-nosis)

Waiting time between sending the MBCHON/MBDCHON and the MBUS commands and the arrival of SNFIMS from the switch control group with the test result

A current test phase is aborted if TS1 expires and the diagnosis ends with the result

MB SN INTERFACE ERROR

FAULTS DETECTED

Timer Value Remark

Table 3 Diagnosis timer (Cont.)

with ERROR INFORMATION HARDWARE FAULT

MB XLINK ERROR

MB SN INTERFACE ERROR

A30828-Y1187-N510-2-7620

17


Id:0900d805800bec08

2.9 Diagnosis of an MB unit/MB side is not executedThe entered diagnosis command is repeated at the O&M terminal with the additional information NOT EXEC'D. In an additional line the reason why the diagnosis was not executed is given with a keyword. The only thing of any great significance here is the keyword HARDWARE FAULT.

For all the other keywords cf. MMN:MB, Introduction. Usually this is an operator fault which can be quickly corrected by simple interpretation of the largely self-explanatory keyword. Software malfunctions are an extremely rare occurrence during MB diagnosis. If they do occur, individual measures are required up to CP recovery (NSTART 1 - 3) in relatively low traffic periods during the day.

Possible causes for the keyword HARDWARE FAULT: For MB diagnosis, the CP (via the IOP:MB) and the MB unit concerned work in close collaboration. Therefore, a minimum function of the relevant unit is required (RESTART successful, unit reports with MBDREADY). If these basic conditions cannot be met, diagnosis cannot be executed and is rejected with the keyword HARDWARE FAULT .

Before final rejection of the diagnosis however, another ERROR MESSAGE with the MMN number MB230-2000 and another keyword are displayed on the O&M terminal. Possible keywords are as follows:

NO REACTION TO RESTART OF MBIC

NO REACTION TO RESTART OF MBIH

NO REACTION TO RESTART OF MBIA

NO REACTION FROM MBIC

MB FAULT

NO LOOP RESPONSE

XLINK FAULT

MEGCG FAULT

FW FALLBACK

RESET BUS FAULT

NO RESET RESPONSE

FEPROM FAULT

PARITY FAULT

ACCESS FAULT

NO REACTION TO RESTART OF ATM230

IBUS TEST NOT SUCCESSFUL

BUILD IN SELF TEST NOT SUCCESSFUL

SDRAM FAULT

The test phases are time-controlled. Should the CP not receive an answer within the specified time a PROGRESS MESSAGE is output instead of an ERROR MESSAGE. HARDWARE FAULT, MB XLINK ERROR or MB SN INTERFACE ERROR is displayed without any additional information.

18 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07

Interpretation of the MBB Diagnosis Results

3 Interpretation of the MBB Diagnosis Results(Diagnosis PROGRESS MESSAGE with the MMN number MB150-1000)

The use of the MB diagnosis is explained in great detail in this document:

All necessary input commands, possible system responses, reaction times to be taken account of and the significance of the various elements of the diagnosis output masks, the operation and the functions of each test block (test steps9. In this way an overview of the operation of the MB diagnosis is provided which aims to allow the user to precisely determine detected fault behavior and to exactly locate the fault.

3.1 Brief Description of the MBB DiagnosisThe MB diagnosis (in this case for an MB of type MBB) is a complete function test (overall test) of an MBU or of an entire MB.

Parallel running of the MB diagnosis with call processing is not possible as they both interfere with each other. For example, faults are deliberately produced in an MBU during diagnosis and their reactions are checked or, as a test condition, certain synthetic message sequences must be generated.The MB diagnosis can therefore only run in off-line operation, i.e. before the start of the diagnosis the appropriate MBU or MB must be MBL.

The MB diagnosis is not automatically initiated by the system, but rather by the user by means of MML commands.

The MB in each system side is composed of several MBUs. If the diagnosis of an entire MB is invoked, all affected MBUs are singly tested one after another by the system. No additional test steps are required due to the modular structure of the MB. For the follow-ing, it is therefore sufficient to only consider the diagnosis actions for the individual MBUs. The diagnosis of an entire MB can only be used in exceptional cases since addi-tional complications must be expected when several MBUs are taken out of service at the same time (see also section 3.7 MBUL - Notes, point 15.).

The diagnosis of an MBU is divided into 2 (for an MBU:LTG) or 3 (for an MBU:SGC) test phases. Each test phase in turn consists of a sequence of test steps which must be pro-cessed consecutively. Every test step contains the complete test of an MB subfunction. The test step is an enclosed, independent unit, but requires that the previous test steps were carried out without faults being detected.

If a test step detects a fault, then the diagnosis is aborted and a diagnosis PROGRESS MESSAGE is output with a TEST BLOCK NO. The first detected fault is always out-put.The output TEST BLOCK NO uniquely identifies the fault-detecting test step or (as a so-called pseudo test block number) it signifies a certain error behavior detected by the diagnosis software in the CP during running of the diagnosis.

3.2 MBU:LTG - PreparationThe MBU:LTG to be tested must be MBL. After the diagnosis is called by the user (with an MML command) the MBU:LTG is configured to SEZ by the diagnosis software in the CP. A prerequisite for SEZ is a successfully completed RESTART in the MBU:LTG con-cerned.

A30828-Y1187-N510-2-7620

19

NM:MB Interpretation of the MBB Diagnosis Results

Id:0900d805800bec07

RESTART is a special interface signal sent by the IOP:MB via the B:MBG to the MBU:LTG. This special command effects a reset of the hardware for the MBU:LTG and new initialization of the firmware.

If RESTART is not carried out, the MBU:LTG cannot be tested with the diagnosis.

The MBU:LTG reports a successful RESTART to the CP with MBUR (= MBU ready).

Then the MB type is determined and the identity code set in the data base. The CP trans-mits the MBFWID command to the MBU:LTG. An MBU:LTG of type MBB replies with the acknowledgement MBFWSTA. For an MBU:LTG the parameter MB type of MBFWSTA can contain the values H’0F for MBB, H’01 for MBUL(C) and H’02 for an MBUL(C) with the functions mirroring and packeting*).

An MBU:LTG of type MBA ignores this command and does not issue an acknowledge-ment.

In order to decide whether the MBU:LTG is defect and unable to acknowledge, or whether it is of type MBA, MBLOOP is sent as accompanying command immediately fol-lowing transmission of the MBFWID. If the CP does not receive a RELOOP message or if the test pattern is mutilated, information about the MB type is irrelevant. The identity code cannot be set and the MBU:LTG is not tested with the diagnosis.

If the request is positive, in other words the MBU:LTG sends RELOOP with exactly the output test pattern, the identity code is set and the MBU:LTG waits in IDLE for instruc-tions from the diagnosis software.

*) Mirroring: The MBUL(C) can forward via a “shortcut“ reports between LTGs which have their active MCHs at the same MBU:LTG. These reports don‘t have to be routed via the CP any more. Packeting: With the MBUL(C) Messages can be sent between MB and LTG in packeted form (several messages in blocks up to max. 128 bytes)

3.3 MBU:LTG - Test Phase 1Phase 1 is also called the MB interface test. Here the CP access procedures to the MBU:LTG are tested in the dialog between the MBU:LTG and CP software.

Test StrategyThe test steps of test phase 1 are created according to a uniform basic pattern:

The CP firstly sends a command of message type MBTEST to the MBU:LTG. The command MBTEST always contains a characterizing test block number. Every test block number causes the MBU:LTG to prepare a concrete test situation, for example, the introduction of a message loop or the setting of a fault simulation. With the exception of type D test steps (see also 3.4 MBU:LTG - Test Phase 2), the CP then sends a command of message type LOOP with a defined test pattern to the MBU:LTG for the actual execution of the test.

The reactions of the MBU:LTG are analyzed by the diagnosis program according to the test situation of the specified test block number. If a fault was simulated for the test step, a contrary test is carried out after the fault simulation is removed by outputting another test pattern. The MBU:LTG stops the fault simulation alone after a timer has expired which the MBU:LTG had set at the same time as the fault simulation was started.

The CP software supervises and analyzes all reactions of the MBU:LTG. When a test step is completed according to specification, i.e. no fault is detected, the next test step or test phase 2 of the diagnosis is initiated with a new command MBTEST.

20 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07


If a test step detects a fault, the diagnosis is aborted. The detected fault is assigned a pseudo test block number with which the diagnosis software exactly describes the type of error behavior detected (see 3.6 MBU:LTG Interpretation of TEST BLOCK NO; Pseudo test block numbers of phase 1 are the numbers E0...FD.). The (pseudo) test block number and an assigned fault list number are output in the diagnosis PROGRESS MESSAGE.

TestingThe test steps of test phase 1 initiated with the test block number of the command MBTEST can be differentiated in the following five testing types A, B, C, D and E:

a) Testing type A:The task of the MBU:LTG is the identical looping of the test pattern transferred with the following LOOP command, i.e. the normal function for a command with message format LOOP.

b) Testing type B:The task of the MBU:LTG is to create a fault simulation which disturbs the dialog between IOP:MB and MBU:LTG.

After the fault simulation is ended, the identical looping of another LOOP must function without restriction in an opposite test (operation and analysis is as for testing type A).

c) Testing type C:The input capability of the MBU:LTG is blocked by a fault simulation. The MBU:LTG cannot reply with RELOOP to the following command, LOOP.

After the fault simulation is ended, the identical looping of another LOOP must function without restriction in a contrary test (operation and analysis is as for testing type A). The RELOOP message buffered during the fault simulation must be previ-ously deleted.

d) Testing type D:The task of the MBU:LTG is the generation and sending of an error message with message format MBRETEST.

e) Testing type E:The output capability of the MBU:LTG is blocked by a fault simulation. The following command LOOP cannot be given by the IOP:MB.

Successful: The CP receives a message RELOOP with exactly the output test pattern.

Unsuccessful: e.g. input/output fault (IOFAULT) on the IOP:MB or the test pattern was mutilated.

Successful: No reaction of the MBU:LTG to LOOP; the IOP:MB reports an input/output fault (IOFAULT)

Unsuccessful: e.g. no IOFAULT from IOP:MB or a RELOOP from the MBU:LTG.

Successful: No inputs at all from the MBU:LTG

Unsuccessful: e.g. message RELOOP

Successful: The CP receives the message MBRETEST with the same test block number as the previously output command MBTEST.

Unsuccessful: e.g. the CP does not receive the message MBRETEST

A30828-Y1187-N510-2-7620

21


Id:0900d805800bec07

Once the fault simulation has been ended, the IOP:MB must be able to give the command LOOP, which is still stored. The CP awaits an appropriate RELOOP message from the MBU:LTG. (Operation and analysis is as for testing type A.)

The individual test steps of phase 1 are listed in the following table (the first command MBTEST has the test block number 17, the last command the number 1E):

In SG.OPER the bytes of the command MBLOOPH'aabbccdd ddeeffgg gggggggg ggggggggH'gggggggg gggggggg gggggggg ggggzzzz

are interpreted according to the following table:

Successful: The LOOP remains in the output list of the IOP:MBNo RELOOP from the MBU:LTG

Unsuccessful: e.g. RELOOP from the MBU:LTG

Test block no. in command

MBTEST

Testing-type

1st LOOP with test pattern

Is an IOFAULT

expected?

2nd LOOP with test pattern

Comments

17 A LM1 N --- Test of normal fault-free operation

18 B LM2 Y LM1 Test of the plausibility supervision and the associated continuation func-tions at the IOP:MB interface

19 B LM2 Y LM1 Suppression of the interface signal ACK1 for an output

1A B LM1 Y LM1 Suppression of the interface signal ACK1 for an input

1B E LM2 N --- Suppression of the output capability

1C C LM1 N LM1 Suppression of the input capability

1D D --- --- --- Error path on the output side

1E D --- --- --- Error path on the input side

Table 4 Test steps of phase 1 MBU:LTG

Byte Contents Explanation

aa

bb

cc

dddd

ee

ff

0F

00

1B

02

04

Origin of the message (sender) SGMES (safeguarding monitor)

SG_OUT

Length (number of the following bytes)

Processor number of the affected unit see MBB - IO Processor Numbers

Job code 1

Job code 2

g..g

LM1

LM2

Testpattern00 F 01 02 04 08 10 20 40

80 FE FD F9 F7 EF DF 9F 7F 33 55 AA 0F FC00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00

zz The bytes designated by z..z are not occupied in this case. Entries not equal to 00 are also irrel-evant and cannot be interpreted.

Table 5 SG.OPER: Interpretation MBLOOP for MBU:LTG

22 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07


3.4 MBU:LTG - Test Phase 2Test AreaPhase 2 is also described as an internal MBU overall test. All test steps which can run without the aid of the CP are carried out in a meaningful order in the MBU:LTG.

TestingTest phase 2 is started by the CP by sending the command MBTEST with the test block number 00. The rest of the testing operation is internally controlled by the hardware and firmware of the MBU:LTG. The CP has no further influence. The central diagnosis control and internal pre-analysis is carried out by the MDI processor on the module MDM. The processor principally controls the testing of the T/RC modules of this MBU:LTG also via the MDM interface.

If no fault behavior is detected in the MBU:LTG in test phase 2, then the MBU:LTG gen-erates a message MBRETEST with the test block number 00. The CP then ends the diagnosis with the RESULT = NO FAULT DETECTED.

In the event of a fault, the number of the test step (in the jargon in this document: test step = test block) which detected the fault is inserted in the message MBRETEST as test block number. As the MB diagnosis is principally aborted after the first detected fault, only an MBRETEST message is output and therefore only a test block number y (with 20 ≤ y ≤ 85 or y = 0F) occurs.

The test block number and an assigned fault list number are output in the diagnosis PROGRESS MESSAGE. The contents and the function of the individual test steps/test blocks are given in chapter 3.6 MBU:LTG Interpretation of TEST BLOCK NO. The test blocks of test phase 2 are processed in the following order:

20 --> 21 --> 22 --> ... --> 84 --> 85 --> 0F

3.5 MBU:LTG Output Masks As soon as the diagnosis has detected a fault in an MBU:LTG, the input command with the addendum PART. EXEC'D (partially executed) is repeated and subsequently a PROGRESS MESSAGE is output with the entire diagnosis information:PROGRESS MESSAGE MMN:@######### TEST RESULT= @### TESTED UNIT= @####### FLN:@######### ERROR INFORMATION: TEST BLOCK NO= @### ADDITIONAL INFORMATION: @####################################### @#######################################

Once the diagnosis has been completed, the command is repeated once more but this time with the additional EXEC'D. (The abortion procedure for the diagnosis is started immediately after the first fault is detected.) Then follows the result of the diagnosis with the message that a fault was detected (FAULTS DETECTED).

with: mb = 0 (for MB-0) or 1 (for MB-1)

mbul = 0 ... 7 = number of the MBU:LTG

A30828-Y1187-N510-2-7620

23


Id:0900d805800bec07

The significance of the TEST BLOCK NO= H'xx and therefore the cause of the PROGRESS MESSAGE is given in the following pages:

Each suspect module can be determined via the fault lists FL:MB and FL:SN or FL:SNB (for an SN of type SNB) in the register TAB of MMN:MB. The associated fault list number FLN:MBUL-y is found in the table, to the right of the test block number.

(As explained in the previous sections, each test block number signifies either a specific test step for which fault behavior was found, or - as pseudo test block number - a fault behavior which the CP detected in the diagnosis phase 1 in dialog with the MBU:LTG.)

3.6 MBU:LTG Interpretation of TEST BLOCK NO

TEST BLOCK

NO

Asso-

ciated

FLN:

MBUL

Comments For further information

refer to 3.7 MBUL -

Notes

00 The diagnosis of the MBU:LTG was completely executed and no fault was detected. (This test block number does not appear as in this case no diagnosis PROGRESS MESSAGE is output. The number can however be read out of SG.OPER for example).

0F 65 Interface test to the SN; clock test for RX part: A test pattern is sent on test channel 0 from the output side (TX part) of the MBU:LTG via the SN to the input side (RX part).

15.

17 66 Test of the fault-free operation 3.

18 66 Test of the plausibility supervision and the associated continuation func-tions at the IOP:MB interface.

3.

19 66 Suppression of the interface signal ACK1 for an output to the MBU:LTG. 3.

1A 66 Suppression of the interface signal ACK1 for an input from the MBU:LTG. 3.

1B 66 Suppression of the output capability of the MBU:LTG. 3.

1C 66 Suppression of the input capability of the MBU:LTG. 3.

1D 51 Testing of the error path on the input side (RX part) of the MBU:LTG. 3.

1E 51 Testing of the error path on the output side (TX part) of the MBU:LTG. 3.

20 51 ROM test (EPROM) on the module MDM on the input side (RX part) of the MBU:LTG. The sum of the entire contents is created.

1.

21 51 ROM test (EPROM) on the module MDM on the output side (TX part) of the MBU:LTG. The sum of the entire contents is created.

1.

22 51 RAM test (EPROM) on the module MDM on the input side (RX part) of the MBU:LTG. The read and write abilities of the memory are tested.

2.

23 51 RAM test (EPROM) on the module MDM on the output side (TX part) of the MBU:LTG. The read and write abilities of the memory are tested.

2.

24 68 Bus test: the internal MBU:LTG bus system between the module MDM and the connected four modules T/RC-0 to T/RC-3 is tested

16.

25 52 FIFO test: T/RC 00 (RX, TX)

On the module T/RC-0, the input and output FIFO are tested for the first of the two "function units for controlling the message channels".

17.

Table 6 Interpretation Table: TEST BLOCK NO for MBU:LTG

24 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07



On the module T/RC-0, the input and output FIFO are tested for the second of the two "function units for controlling the message channels".

17.

27 56 EPROM test: T/RC 00

On the module T/RC-0, the EPROM is tested for the first of the two "func-tion units for controlling the message channels".

1.


On the module T/RC-0, the EPROM is tested for the second of the two "function units for controlling the message channels".

1.

29 56 RAM test: T/RC 00

On the module T/RC-0, the RAM is tested for the first of the two "function units for controlling the message channels".

2.

2A 56 RAM test: T/RC 01

On the module T/RC-0, the RAM is tested for the second of the two "func-tion units for controlling the message channels".

2.

2B 56 Timer 1 - test T/RC 00 (WD, 4 ms)

On the module T/RC-0, the hardware timer (watchdog) is tested for the first of the two "function units for controlling the message channels".

18.

2C 56 Timer 1 - test T/RC 01 (WD, 4 ms)

On the module T/RC-0, the hardware timer (watchdog) is tested for the second of the two "function units for controlling the message channels".

18.

2D 53 FIFO test: T/RC 10 (RX, TX)

On the module T/RC-1, the input and output FIFO are tested for the first of the two "function units for controlling the message channels".

17.

2E 53 FIFO test: T/RC 11 (RX, TX)

On the module T/RC-1, the input and output FIFO are tested for the second of the two "function units for controlling the message channels".

17.

2F 57 EPROM test: T/RC 10


1.



1.



2.



2.

33 57 Timer 1 - test T/RC 10 (WD, 4 ms)


18.

TEST BLOCK

NO

Asso-

ciated

FLN:

MBUL


refer to 3.7 MBUL -

Notes

Table 6 Interpretation Table: TEST BLOCK NO for MBU:LTG (Cont.)

A30828-Y1187-N510-2-7620

25


Id:0900d805800bec07



18.


On the module T/RC-2, the input and output FIFO is tested for the first of the two "function units for controlling the message channels".

17.


On the module T/RC-2, the input and output FIFO is tested for the second of the two "function units for controlling the message channels".

17.



1.



1.



2.

3A 58 RAM test: T/RC 21


2.

3B 58 Timer 1 - test - Test T/RC 20 (WD, 4 ms)


18.

3C 58 Timer 1 - test T/RC 21 (WD, 4 ms)


18.

3D 55 FIFO test: T/RC 30 (RX, TX)

On the module T/RC-3, the input and output FIFO is tested for the first of the two "function units for controlling the message channels".

17.

3E 55 FIFO test: T/RC 31 (RX, TX)

On the module T/RC-3, the input and output FIFO is tested for the second of the two "function units for controlling the message channels".

17.

3F 59 EPROM test: T/RC 30


1.



1.



2.

TEST BLOCK

NO

Asso-

ciated

FLN:

MBUL


refer to 3.7 MBUL -

Notes


26 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07




2.



18.



18.

45 56 TEST HSCC channel 0-1

(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On the module T/RC-0, on the first of the two "function units for controlling the message chan-nels", the first of the four HSCC chips is tested (assigned: test channel 0 and MCH to the 1st LTG of this MBU:LTG).

19.


(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On the module T/RC-0, on the first of the two "function units for controlling the message chan-nels", the second of the four HSCC chips is tested (assigned: the MCH to the 2nd and 3rd LTG of this MBU:LTG).

19.


(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-0, on the first of the two "function units for controlling the message chan-nels", the third of the four HSCC chips is tested (assigned: the MCH to the 4th and 5th LTG of this MBU:LTG).

19.


(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-0, on the first of the two "function units for controlling the message chan-nels", the fourth of the four HSCC chips is tested (assigned: the MCH to the 6th and 7th LTG of this MBU:LTG).

19.


(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-0, on the second of the two "function units for controlling the message chan-nels", the first of the four HSCC chips is tested (assigned: the MCH to the 8th and 9th LTG of this MBU:LTG).

19.

4A 56 TEST HSCC channel 10-11

(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-0, on the second of the two "function units for controlling the message chan-nels", the second of the four HSCC chips is tested (assigned: the MCH to the 10th and 11th LTG of this MBU:LTG).

19.

4B 56 TEST HSCC channel 12-13

(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-0, on the second of the two "function units for controlling the message chan-nels", the third of the four HSCC chips is tested (assigned: the MCH to the 12th and 13th LTG of this MBU:LTG).

19.

TEST BLOCK

NO

Asso-

ciated

FLN:

MBUL


refer to 3.7 MBUL -

Notes


A30828-Y1187-N510-2-7620

27


Id:0900d805800bec07

4C 56 TEST HSCC channel 14-15

(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-0, on the second of the two "function units for controlling the message chan-nels", the fourth of the four HSCC chips is tested (assigned: the MCH to the 14th and 15th LTG of this MBU:LTG).

19.

4D 57 TEST HSCC channel 16-17

(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-1, on the first of the two "function units for controlling the message chan-nels", the first of the four HSCC chips is tested (assigned: the MCH to the 16th and 17th LTG of this MBU:LTG).

19.

4E 57 TEST HSCC channel 18-19

(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-1, on the first of the two "function units for controlling the message chan-nels", the second of the four HSCC chips is tested (assigned: the MCH to the 18th and 19th LTG of this MBU:LTG).

19.

4F 57 TEST HSCC channel 20-21

(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-1, on the first of the two "function units for controlling the message chan-nels", the third of the four HSCC chips is tested (assigned: the MCH to the 20th and 21st LTG of this MBU:LTG).

19.


(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-1, on the first of the two "function units for controlling the message chan-nels", the fourth of the four HSCC chips is tested (assigned: the MCH to the 22nd and 23rd LTG of this MBU:LTG).

19.



19.



19.



19.


(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-1, on the second of the two "function units for controlling the message chan-nels", the fourth of the four HSCC chips is tested (assigned: the MCH to the 30th and 31st LTG of this MBU:LTG).

19.

TEST BLOCK

NO

Asso-

ciated

FLN:

MBUL


refer to 3.7 MBUL -

Notes


28 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07



(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-2, on the first of the two "function units for controlling the message chan-nels", the first of the four HSCC chips is tested (assigned: the MCH to the 32nd and 33rd LTG of this MBU:LTG).

19.


(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-2, on the first of the two "function units for controlling the message chan-nels", the second of the four HSCC chips is tested (assigned: the MCH to the 34th and 35th LTG of this MBU:LTG).

19.


(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-2, on the first of the two "function units for controlling the message chan-nels", the third of the four HSCC chips is tested (assigned: the MCH to the 36th and 37th LTG of this MBU:LTG).

19.



19.


(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-2, on the second of the two "function units for controlling the message chan-nels", the first of the four HSCC chips is tested (assigned: the MCH to the 40th and 41st LTG of this MBU:LTG).

19.

5A 58 TEST HSCC channel 42-43

(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-2, on the second of the two "function units for controlling the message chan-nels", the second of the four HSCC chips is tested (assigned: the MCH to the 42nd and 43th LTG of this MBU:LTG).

19.

5B 58 TEST HSCC channel 44-45


19.

5C 58 TEST HSCC channel 46-47

(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-2, on the second of the two "function units for controlling the message chan-nels", the fourth of the four HSCC chips is tested (assigned: the MCH to the 46th and 47th LTG of this MBU:LTG).

19.

5D 59 TEST HSCC channel 48-49

(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-3, on the first of the two "function units for controlling the message chan-nels", the first of the four HSCC chips is tested (assigned: the MCH to the 48th and 49th LTG of this MBU:LTG).

19.

TEST BLOCK

NO

Asso-

ciated

FLN:

MBUL


refer to 3.7 MBUL -

Notes


A30828-Y1187-N510-2-7620

29


Id:0900d805800bec07

5E 59 TEST HSCC channel 50-51

(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-3, on the first of the two "function units for controlling the message chan-nels", the second of the four HSCC chips is tested (assigned: the MCH to the 50th and 51st LTG of this MBU:LTG).

19.

5F 59 TEST HSCC channel 52-53

(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-3, on the first of the two "function units for controlling the message chan-nels", the second of the four HSCC chips is tested (assigned: the MCH to the 50th and 51st LTG of this MBU:LTG).

19.



19.



19.



19.


(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-3, on the second of the two "function units for controlling the message chan-nels", the third of the four HSCC chips is tested (assigned: the MCH to the 60th and 61st LTG of this MBU:LTG).

19.


(LOOP via T/RC multiplexer, timer 2 - test = 70 ms) On module T/RC-3, on the second of the two "function units for controlling the message chan-nels", the fourth of the four HSCC chips is tested (assigned: the MCH to the 62nd and 63rd LTG of this MBU:LTG).

19.

65 60 TEST channel 0-1 (LOOP via CG/MUX multiplexer)

On module T/RC-0, on the first of the two "function units for controlling the message channels", the first of the four HSCC chips is tested (assigned: test channel 0 and MCH to the 1st LTG of this MBU:LTG).

20.


On module T/RC-0, on the first of the two "function units for controlling the message channels", the second of the four HSCC chips is tested (assigned: the MCH to the 2nd and 3rd LTG of this MBU:LTG).

20.


On module T/RC-0, on the first of the two "function units for controlling the message channels", the third of the four HSCC chips is tested (assigned: the MCH to the 4th and 5th LTG of this MBU:LTG).

20.

TEST BLOCK

NO

Asso-

ciated

FLN:

MBUL


refer to 3.7 MBUL -

Notes


30 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07



On module T/RC-0, on the first of the two "function units for controlling the message channels", the fourth of the four HSCC chips is tested (assigned: the MCH to the 6th and 7th LTG of this MBU:LTG).

20.


On module T/RC-0, on the second of the two "function units for controlling the message channels", the first of the four HSCC chips is tested (assigned: the MCH to the 8th and 9th LTG of this MBU:LTG).

20.

6A 60 TEST channel 10-11 (LOOP via CG/MUX multiplexer)

On module T/RC-0, on the second of the two "function units for controlling the message channels", the second of the four HSCC chips is tested (assigned: the MCH to the 10th and 11th LTG of this MBU:LTG).

20.

6B 60 TEST channel 12-13 (LOOP via CG/MUX multiplexer)

On module T/RC-0, on the second of the two "function units for controlling the message channels", the third of the four HSCC chips is tested (assigned: the MCH to the 12th and 13th LTG of this MBU:LTG).

20.

6C 60 TEST channel 14-15 (LOOP via CG/MUX multiplexer)

On module T/RC-0, on the second of the two "function units for controlling the message channels", the fourth of the four HSCC chips is tested (assigned: the MCH to the 14th and 15th LTG of this MBU:LTG).

20.

6D 61 TEST channel 16-17 (LOOP via CG/MUX multiplexer)

On module T/RC-1, on the first of the two "function units for controlling the message channels", the first of the four HSCC chips is tested (assigned: the MCH to the 16th and 17th LTG of this MBU:LTG).

20.

6E 61 TEST channel 18-19 (LOOP via CG/MUX multiplexer)

On module T/RC-1, on the first of the two "function units for controlling the message channels", the second of the four HSCC chips is tested (assigned: the MCH to the 18th and 19th LTG of this MBU:LTG).

20.

6F 61 TEST channel 20-21 (LOOP via CG/MUX multiplexer)

On module T/RC-1, on the first of the two "function units for controlling the message channels", the third of the four HSCC chips is tested (assigned: the MCH to the 20th and 21st LTG of this MBU:LTG).

20.


On module T/RC-1, on the first of the two "function units for controlling the message channels", the fourth of the four HSCC chips is tested (assigned: the MCH to the 22nd and 23rd LTG of this MBU:LTG).

20.



20.



20.

TEST BLOCK

NO

Asso-

ciated

FLN:

MBUL


refer to 3.7 MBUL -

Notes


A30828-Y1187-N510-2-7620

31


Id:0900d805800bec07



20.


On module T/RC-1, on the second of the two "function units for controlling the message channels", the fourth of the four HSCC chips is tested (assigned: the MCH to the 30th and 31st LTG of this MBU:LTG).

20.


On module T/RC-2, on the first of the two "function units for controlling the message channels", the first of the four HSCC chips is tested (assigned: the MCH to the 32nd and 33rd LTG of this MBU:LTG).

20.


On module T/RC-2, on the first of the two "function units for controlling the message channels", the second of the four HSCC chips is tested (assigned: the MCH to the 34th and 35th LTG of this MBU:LTG).

20.


On module T/RC-2, on the first of the two "function units for controlling the message channels", the third of the four HSCC chips is tested (assigned: the MCH to the 36th and 37th LTG of this MBU:LTG).

20.



20.


On module T/RC-2, on the second of the two "function units for controlling the message channels", the first of the four HSCC chips is tested (assigned: the MCH to the 40th and 41st LTG of this MBU:LTG).

20.

7A 62 TEST channel 42-43 (LOOP via CG/MUX multiplexer)

On module T/RC-2, on the second of the two "function units for controlling the message channels", the second of the four HSCC chips is tested (assigned: the MCH to the 42nd and 43rd LTG of this MBU:LTG).

20.

7B 62 TEST channel 44-45 (LOOP via CG/MUX multiplexer)


20.

7C 62 TEST channel 46-47 (LOOP via CG/MUX multiplexer)

On module T/RC-2, on the second of the two "function units for controlling the message channels", the fourth of the four HSCC chips is tested (assigned: the MCH to the 46th and 47th LTG of this MBU:LTG).

20.

7D 63 TEST channel 48-49 (LOOP via CG/MUX multiplexer)

On module T/RC-3, on the first of the two "function units for controlling the message channels", the first of the four HSCC chips is tested (assigned: the MCH to the 48th and 49th LTG of this MBU:LTG).

20.

TEST BLOCK

NO

Asso-

ciated

FLN:

MBUL


refer to 3.7 MBUL -

Notes


32 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07


7E 63 TEST channel 50-51 (LOOP via CG/MUX multiplexer)

On module T/RC-3, on the first of the two "function units for controlling the message channels", the second of the four HSCC chips is tested (assigned: the MCH to the 50th and 51st LTG of this MBU:LTG).

20.

7F 63 TEST channel 52-53 (LOOP via CG/MUX multiplexer)

On module T/RC-3, on the first of the two "function units for controlling the message channels", the third of the four HSCC chips is tested (assigned: the MCH to the 52nd and 53rd LTG of this MBU:LTG).

20.



20.



20.



20.


On module T/RC-3, on the second of the two "function units for controlling the message channels", the third of the four HSCC chips is tested (assigned: the MCH to the 60th and 61st LTG of this MBU:LTG).

20.


On module T/RC-3, on the second of the two "function units for controlling the message channels", the fourth of the four HSCC chips is tested (assigned: the MCH to the 62nd and 63rd LTG of this MBU:LTG).

20.

85 64 PLL test, clock test of the MB group clock generator on the module CG/MUX.

21.

E0 66 During a type A test step, an incorrect IORESP message was received after an IOKONF command with MBU-RESTART.

4., 5., 6., 7.

E1 66 During a type A test step, an IOFAULT message was issued after an IOKONF command with MBU-RESTART.

4., 5., 6., 8.

E2 66 During a type A test step, an unexpected message was received from the MBU:LTG after an IOKONF command with MBU-RESTART.

4., 5., 6.

E3 66 During a type A test step, an IOFAULT message was issued in place of an expected RELOOP message from the MBU:LTG.

4., 8., 9.

E4 66 During a type A test step, instead of an expected RELOOP message another unexpected message from the MBU:LTG was received.

4., 9.

E5 66 During a type B test step, an incorrect IORESP message was received after an IOKONF command.

4.,5., 7.

E6 66 During a type B test step, an unexpected IOFAULT message was issued after an IOKONF command.

4., 5., 8.

TEST BLOCK

NO

Asso-

ciated

FLN:

MBUL


refer to 3.7 MBUL -

Notes


A30828-Y1187-N510-2-7620

33


Id:0900d805800bec07

3.7 MBUL - NotesAdditional Explanations for the interpretation table of the test block numbers output in a diagnosis PROGRESS MESSAGE for an MBU:LTG:1. Procedure for ROM test (EPROM test)

E7 66 During a type B test step, an unexpected message from the MBU:LTG was received after an IOKONF command.

4., 5.

E8 66 During a type B test step, a message from the MBU:LTG was received although the delay timer TD2 had not yet expired.

4., 10.

E9 66 During a type B test step, an incorrect IORESP message was received after an IORSOUT command.

4., 7., 11.

EA 66 During a type B test step, the delay timer TD2 expired before the deletion of the output list was acknowledged by an IORESP message.

4., 7., 10.

EB 66 During a type C or E test step, a message was received from the MBU:LTG although the delay timer TD2 had not yet expired.

4., 10.

EC 66 During a type B test step, an IOFAULT message with incorrect parame-ters was issued after a LOOP command.

4., 8., 10.

ED 66 During a type B test step, a message from the MBU:LTG was received after a LOOP command instead of an interface error message.

4., 12.

EE 66 During a type B test step, the delay timer TD2 expired before an interface error message was received.

4., 10.

EF 66 During a type D test step, a message MBUR (MB ready) with an incorrect processor number was received after an IOKONF command with MBU-RESTART.

4., 5., 6.

F0 66 After output of a command MBTEST an IOFAULT message was issued. 4.,8., 13.

F1 66 Before the command LOOP with the test pattern is sent to the MBU:LTG, an unexpected message is received from the MBU:LTG.

4., 12.

F2 66 During a type D test step, a message MBRETEST with the wrong test block number was issued by the MBU:LTG.

4., 14.

F3 66 After output of the command MBTEST for initiating the internal MBU:LTG diagnosis (= test phase 2), an IOFAULT message was issued.

8., 14.

F4 66 The supervisory timer (TS2) for test phase 2 of this MBU:LTG has expired. However, no MBRETEST message was received.

10., 14.

F7 66 During a type A test step, a LOOP command was replied to by a RELOOP message with an incorrect processor number.

4., 9., 12.

F8 66 After output of the command MBTEST for initiating the internal MBU:LTG diagnosis (= test phase 2), a message MBRETEST with an incorrect pro-cessor number was received.

13., 14.

F9 66 During a type C or E test step, an IOFAULT message was issued after a LOOP command.

4., 8., 12.

FD 66 The supervisory timer for test phase 1 (TS1) has expired without test phase 1 (TS1) being able to be concluded.

10.

TEST BLOCK

NO

Asso-

ciated

FLN:

MBUL


refer to 3.7 MBUL -

Notes


34 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07


The ROM contents are added together byte for byte from ROMSTART up to and including the fourth-last byte (ROMEND-3). The result is a three-byte sum. The last three bytes of the ROM similarly form a three-byte checksum. ROMEND thereby contains the most significant byte of this checksum. The two three-byte numbers (sum and checksum) are compared. If successful, i.e. if no fault is detected, the two numbers are identical. Every divergence of the sum from the checksum is seen by the test as a ROM fault. The test of this ROM is then concluded.

2. Procedure for RAM test:The RAM is sectioned into areas 8 byte large for the test. During the on-line routine test only one area is tested in a test cycle for dynamic reasons, whereas the diag-nosis tests all areas, one immediately after the other. The test program is also newly called for each area in this procedure.The individual area test is the same for all areas: A byte is written with the test pattern CCH. Subsequently, the test pattern is read out again. The values written in and read out are compared. If a discrepancy exists, a RAM fault is detected and the test is terminated. If both values correspond, the pro-cedure is repeated with the test pattern 33H. The selection of this combination of test patterns ensures that altogether, every bit memory position is written and read once with 0 and once with 1. If the algorithms does not detect a fault for a byte, it continues the test immediately with the next byte of the area until the entire area is tested. As part of the diagnosis, the same test is invoked immediately afterwards for the next area.The RAM test is concluded with the result "fault-free" when all areas have been tested in this way and no fault was detected.

3. This test block number is only called as part of the diagnosis test phase 1. It is output in the diagnosis PROGRESS MESSAGE, if a fault is detected by the test started after the fault simulation ends.

4. This test block number is a pseudo test block number of the MBU:LTG diagnosis test phase 1.The fault behavior shown must be seen in connection with the procedure for the indi-vidual testing types described in section 3.3 MBU:LTG - Test Phase 1.

5. IOKONF is a CP software command to the IOP:MB.In this case, the command's contents signify that the affected MBU:LTG must be included in or blocked out of the scan cycle. The command for inclusion in the scan cycle can contain a directive for transfer of a RESTART command to the MBU:LTG at the same time. The inclusion can however be carried out without RESTART.Messages can only be exchanged between the CP and MBU:LTG when the MBU:LTG is included in the scan cycle.

6. MBU-RESTART is a special interface signal which the IOP:MB applies to an MBU via the B:MBG.The signal practically causes a newstart of the affected MBU: the hardware/proces-sors are reset and the firmware is newly initialized. All stored messages/flags/regis-ter contents are deleted. The MBU then switches to IDLE and awaits further instructions from the CP, e.g. diagnosis commands or return to normal operation by setting up the message channels etc.

With: ROMSTART = first byte of the ROM

ROMEND = last byte of the ROM

A30828-Y1187-N510-2-7620

35


Id:0900d805800bec07

7. IORESP is an acknowledgment from the IOP:MB to the CP software for a received IOKONF or IORSOUT command. If the associated command could not be, or only incompletely, carried out, additional parameters are transferred with IORESP. At the same time the MBU is removed from the scan cycle.

8. IOFAULT is a message from the IOP:MB to the CP software.IOFAULT reports an interface fault between the IOP:MB and MBU:LTG if the fault occurs twice in succession. The affected MBU:LTG is removed from the scan cycle as reliable message exchange is no longer possible with it. In normal operation IOFAULT usually signifies total failure of the MBU:LTG (even a diagnosis is not pos-sible), for example, as a result of power failure. During an MB diagnosis, IOFAULT is partly deliberately initiated using fault simulation.

9. RELOOP is an MBU:LTG message to the CP.A test pattern is transferred from the CP to the MBU:LTG with the command LOOP (see12). The MBU:LTG loops the test pattern (= transfer of the pattern from the output side to the input side and conversion to a message format) and transfers it as message RELOOP back to the CP. Once this test pattern has been received again, it is compared in the CP with the pattern previously output. In normal operation, devi-ation causes an error message. During diagnosis, deliberate differences are partly provoked by fault simulation.

10. The following timers are used for the diagnosis of an MBU:LTG:In the MBU:LTG firmware:

Delay timers in the CP software:

Supervisory timers in the CP software

TM1 (min. 200 ms, max. 800 ms)

Waiting time between the creation of a fault simulation and the stopping of the simulation for testing types B and C.

TM2 (min. 1400 ms, max. 1700 ms)

Waiting time between the creation of a fault simulation and the stopping of the simulation for testing type E.

TD1 (min. 50 ms, max. 150 ms)

Waiting time between the sending of a command MBTEST for diagnosis phase 1 and the following command LOOP with the corresponding test pattern.

TD2 (min. 900 ms, max. 1100 ms)

Waiting time between the output of the command LOOP for a test step of diagnosis phase 1 and the start of the test step analysis.


Protection time before expiry of a test block of the diagnosis phase 1 (before the next test block is started).

TCB (min. 50 ms, max. 150 ms)

Waiting time for messages still arriving from the MBU:LTG.

36 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07


11. IORSOUT is a CP software command to the input/output call processing periphery (EAVT or IOCP) for resetting the output list.(New linkage: set the W/R CHAR of the list positions to "writable" and set the read and write pointers to the same state as after initialization.)

12. LOOP is a CP command to the MBU:LTG.A test pattern is transferred from the CP to the MBU:LTG with the command LOOP. Depending on the fault simulation used, an interface error message IOFAULT (see 8) or a (possibly falsified) message RELOOP (see also 9: RELOOP) for example is expected during the diagnosis.

13. MBTEST is a CP command to the MBU:LTG.A test function is called in the MBU:LTG with this command: for example, an internal overall test of the diagnosis test phase 2 or creation of a fault simulation (see sections 3.3 MBU:LTG - Test Phase 1 and 3.4 MBU:LTG - Test Phase 2).

14. MBRETEST is an MBU:LTG message to the CP.This message is a reply to the command MBTEST. The execution or the result of a test job is reported (see sections 3.3 MBU:LTG - Test Phase 1 and 3.4 MBU:LTG - Test Phase 2).

15. The test block H'0F is the last test block of test phase 2 for the MBU:LTG diagnosis. In this test step, a test pattern is output from the transmission side of the MBU:LTG to the SN and returned to the receive side of the MBU:LTG via the test channel 0 of the interface SDC:TSG. The pattern must arrive within a fixed time limit and may not be falsified.In the case of faults, all SN modules along which the test channel 0 runs are also suspect. For information concerning the suspect modules: see MMN:MB, register TAB, the fault lists FL:MB and FL:SN or FL:SNB (for an SN of type SNB) under FLN:MBUL-65 respectively.A problem with the test block H'0F is that the test channel 0 must be appropriately prepared/switched (= apply test channel loop) for its correct execution in the SN. The necessary creation commands are transferred to the SN via the associated MBU:SGC.If the preparation of the test block H'0F does not occur according to specification, a so-called "phantom fault" must be considered. Although the MBU:LTG is in order the loop over the test channel 0 cannot be closed and the diagnosis program therefore comes to the result = FAULTS DETECTED. A PROGRESS MESSAGE is output with the test block number H'0F.In order to avoid unnecessary pursuance of these "phantom faults", the following boundary conditions must be fulfilled for fault clearance for test block number H'0F:– In the system side with the faulty MBU:LTG, no MBU:SGC may be UNA or MBL.

TS1 (2 minutes)

Supervisory timer of diagnosis test phase 1

The expiry of TS2 causes the abortion of an active test phase 2 and therefore the conclusion of the diagnosis with the result = FAULTS DETECTED

TS2 (1 minute)

Supervisory timer of diagnosis test phase 2.

The expiry of TS2 causes the abortion of an active test phase 2 and therefore the conclusion of the diagnosis with the result = FAULTS DETECTED

A30828-Y1187-N510-2-7620

37


Id:0900d805800bec07

– In the system side with the faulty MBU:LTG, the SN (type A and B only) must not be UNA or MBL, or no SSG or TSG may be UNA or MBL.

If these conditions cannot be fulfilled due to circumstances, the affected MBU:LTG should be temporarily assumed to be fault-free for test block number H'0F - until the necessary conditions for another diagnosis become available. Another problem with test block H'0F exists in net nodes with SN (126LTG), SN (252LTG), SN (504LTG) for the diagnosis of an entire MB: As the diagnosis of an entire MB solely consists of the linking of the individual diag-noses of the associated MBU, the test block H'0F is also used in the affected MBU:LTGs. During diagnosis of the entire MB the corresponding MBU:SGCs are necessarily in state MBL which is in conflict with the above named boundary condi-tions for the MBU:LTG diagnosis. The test block H'0F can therefore occur under certain circumstances as a "phantom fault", even during diagnosis of an entire MB. (What is meant by "under certain circumstances" is when before or during configu-ration of the MBU to MBL, the switch groups were not properly switched, i.e. if the switch groups in this system side were not all uniformly ACT or STB.)The diagnosis of an entire MB must therefore be interpreted as follows:– The result = NO FAULT DETECTED can be unconditionally accepted. – The result = FAULTS DETECTED along with another test block number than

H'0F signifies with certainty a fault in the MBU, which is named in the PROGRESS MESSAGE.

– The result = FAULTS DETECTED with the test block number H'0F must be ver-ified, i.e. it must be confirmed with the boundary conditions listed with the single diagnosis of the affected MBU:LTG. To accomplish this, the associated MBU:SGCs must firstly be tested with the diagnosis and (as long as no fault has been detected) then configured to ACT.

The MMN:MB procedures are so structured that they automatically create the boundary conditions for an MBU:LTG diagnosis and carry out verification for the occurrence of the test block H'0F. In this way, a "phantom fault" is ruled out and a fault H'0F is cleared in both the MB and SN. Since fault clearance in this case is very complex, it cannot always be completed by conventional system maintenance personnel. For clearance of this type of fault it is recommended for the system specialists to reproduce this procedure once more before individual measures are taken.This procedure can be found, for example, in the MMN:MB, procedure PR:MB If a verified fault with the fault characteristic H'0F cannot be cleared by replacing modules, the module frames (backplane, connector strip) in MB and SN containing the suspect modules are likewise suspect. The connecting cables between the affected MB and SN module frames are also suspect.

16. The bus system test comprises 3 test steps:– All input and output FIFOs on all T/RC modules are interrogated to see if they

are empty. The FIFOs must be empty after the RESTART before the start of the diagnosis. If exactly one FIFO reports itself as being not empty, it is assumed defective and a test block number is output, which refers to the T/RC module with this FIFO (25H for T/RC-0, 2DH for T/RC-1, 35H for T/RC-2, 3DH for T/RC-3). If several FIFOs report themselves as not empty a bus error is deduced and 24H is output as test block number. Should all FIFOs be reported as empty, the second test step is started.

38 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07


– An internal LOOP is output from the MDI processor (on the M:MDM) to all FIFOs of the "function units for controlling the message channels" on all four modules T/RC (BROADCASTING mode). A fault is detected if not all test loops were closed after expiry of a timer or if a test pattern was falsified during the operation. In the same way as for the first test step, for a single fault a corresponding test block number indicates the associated T/RC module, or for several faults, a bus error is assumed. If no fault behavior was detected, the third test step is started.

– The last test step consists of internal test loops which are output to the same FIFOs as for test step 2. The loops are not output here in BROADCASTING mode, rather the FIFOs are individually addressed. The test of the various addressing types is therefore also included in the test step. The fault analysis and evaluation is identical to that in test step 2.

17. One output (TX) and one input (RX) FIFO are tested together each time. For the test, the output of the TX FIFO is short-circuited. All messages written into the TX FIFO (on M:T/RC) by the MDI processor via the MDM interface bus are returned to the MDI processor via the corresponding RX FIFO.For the test, 119 bytes are written into the TX FIFO. The bytes returned by the RX FIFO are compared with the original pattern. A FIFO fault is detected if not all bytes have been returned or if the bytes were fal-sified. A typical test pattern here is the 119 bytes: 79H, 78H, ..., 04H, 03H.

18. There are two "function units for controlling the message channels" on every T/RC. The watchdog of a function unit is tested by the MDI processor sending the command "processor stop" to the processor of this function unit. The watchdog is then no longer triggered and expires. After the WD has expired, it resets the function unit processor (= processor start).The processor reports to the MDI processor after the recovery phase that it is prepared for operation with "ready". If the "ready" signal does not arrive within a set time limit after the "stop" command, the watchdog is found to be defective.

19. This test runs practically internally in the HSCC chip - only the test initiation is given by the MDI processor (module MDM). For the test, the output of the transmission side (TX) of the HSCC chip is short-circuited to the input of the receive side. First of all, the timer test is carried out: The receive side of the HSCC is blocked (disabled) and the transmission side is commanded to carry out the SYN procedure (for normal operation: = synchroniza-tion of a connected MCH to the LTG). The disabled receive side does not react to the SYN signals until finally the timer is activated and the SYN procedure is aborted. The abortion of the SYN procedure within the defined time frame thus signifies that the timer functions properly.For the second test step, the receiver is released (enabled). As the receive and transmission sides of the HSCC chip are short-circuited, both can carry out the SYN procedure with each other. If the SYN procedure runs without faults, the previously tested timer must not be activated.Should the timer not be activated within the defined time limit for the second test step, the HSCC chip is assumed to be faultfree.

20. See also 19: In accordance with the test therein described, the HSCC chip assigned to the message channel to be tested here was already tested and evaluated as "fault-free" in an earlier test step.For testing the assigned channel (= MCH to the LTG as long as it runs within the MB), the output side of the MCH is short-circuited with the input side (= message

A30828-Y1187-N510-2-7620

39


Id:0900d805800bec07

looping) on module CG/MUX, directly at the interface SDC:TSG to the SN. The position of the message loop therefore guarantees the widest test area internally possible in the MB. The HSCC chip associated with the message channel is now connected with itself via the message loop - the output side sends directly to the input side. The HSCC chip is now commanded to carry out the SYN procedure (for normal operation: synchronization of a connected MCH to the LTG). As the receive and transmission side of the HSCC chip of the HSCC chip are short-circuited, they can carry out the SYN procedure together. If the HSCC chip reports successful running of the SYN procedure, the channel is deemed to be "fault-free".

21. The test of the group clock generator on the module CG/MUX as part of the MB diag-nosis corresponds mainly to the periodic routine test by means of the command STAGCG. In the first step a check is carried out to see if an alarm is set. Since the alarm register is automatically reset at the end of an alarm, an active alarm indicates a per-manent fault on module CG/MUX. As a result, the diagnosis is then aborted with result = FAULTS DETECTED. If no alarm is active, the test is continued with testing of the fault detection circuits. The clock supervision is tested by the PLL supervision. For testing the clock supervision, the clock input is disabled by the diagnosis program. The supervisory circuit (a monostable flip-flop triggered by the input clock) must be activated and must report the clock failure with an alarm. The clock input is then enabled once more. When the supervisory circuit functions, the clock alarm is deactivated.If the clock supervision is analyzed as being "fault-free", the PLL supervisory circuit is tested in conclusion. The PLL supervisory circuit constantly compares the phase position of the input clock with the phase position of the output clock of the group clock generator. For the test, one of the signals is inverted (phase shifting by a half period). The PLL supervision must become active and report a PLL alarm. The inversion is then removed. When the PLL supervisory circuit functions, the PLL alarm is deactivated. If no fault behavior was detected for these test steps, the group clock generator is deemed to be fault-free.

3.8 MBU:SGC - PreparationThe MBU:SGC to be tested must be MBL. After the diagnosis is called by the user (with an MML command) the MBU:SGC is configured to SEZ by the diagnosis software in the CP. A prerequisite for SEZ is a successfully completed RESTART in the MBU:SGC con-cerned.

RESTART is a special interface signal sent by the IOP:MB via the B:MBG to the MBU:SGC. This special command effects a reset of the hardware for the MBU:SGC and new initialization of the firmware.

If RESTART is not carried out, the MBU:SGC cannot be tested with the diagnosis (see section 3.15 Diagnosis of an MBU (of an MB) is not executed). The MBU:SGC reports a successful RESTART to the CP with MBUR (= MBU ready).

Then the MB type is determined and the identity code set in the data base. The CP trans-mits the MBFWID command to the MBU:SGC. An MBU:SGC of type MBB replies with the acknowledgement MBFWSTA. An MBU:SGC of type MBA ignores this command and does not issue an acknowledgement.

40 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07


In order to decide whether the MBU:SGC is defect and unable to acknowledge, or whether it is of type MBA, MBLOOP is sent as accompanying command immediately fol-lowing transmission of the MBFWID. If the CP does not receive a RELOOP message or if the test pattern is mutilated, information about the MB type is irrelevant. The identity code cannot be set and the MBU:SGC is not tested with the diagnosis (see section: 3.15 Diagnosis of an MBU (of an MB) is not executed). If the request is positive, in other words the MBU:SGC sends RELOOP with exactly the output test pattern, the identity code is set and the MBU:SGC waits in IDLE for instructions from the diagnosis software.

3.9 MBU:SGC - Test Phase 1Test AreaPhase 1 is also called the MB interface test. Here the access procedures of the CP to the MBU:SGC are tested in the dialog between the MBU:SGC and CP software.

Test StrategyThe test steps of test phase 1 are created according to a uniform basic pattern:

The CP firstly sends a command of message type MBTEST to the MBU:SGC. The command MBTEST always contains a characterizing test block number. Every test block number causes the MBU:SGC to prepare a concrete test situation, for example, the introduction of a message loop or the setting of a fault simulation. With the exception of the test steps of type D (see section 3.9 MBU:SGC - Test Phase 1) the CP then sends a command of message type LOOP with a defined test pattern to the MBU:SGC for the actual execution of the test.

The reactions of the MBU:SGC are analyzed by the diagnosis program according to the test situation of the specified test block number. If a fault was simulated for the test step, a contrary test is carried out after the fault simulation is removed by outputting another test pattern. The MBU:SGC stops the fault simulation alone after a timer has expired which the MBU:SGC had set at the same time as the fault simulation was started.

The CP software supervises and analyzes all reactions of the MBU:SGC. When a test step is completed according to specification, i.e. no fault is detected, the next test step or test phase 2 of the diagnosis is initiated with a new command MBTEST.

If a test step detects a fault, the diagnosis is aborted. The detected fault is assigned a pseudo test block number with which the diagnosis software exactly describes the type of fault behavior detected (see also section 3.13 MBU:SGC - Interpretation of the TEST BLOCK NO; Pseudo test block numbers of phase 1 are the numbers E0...FD). The (pseudo) test block number and an assigned fault list number are output in the diagnosis PROGRESS MESSAGE.

TestingThe test steps of test phase 1 initiated with the test block number of the command MBTEST can be differentiated in the following five testing types A, B, C, D and E:

a) Testing type A:The task of the MBU:SGC is the identical looping of the test pattern transferred with the following command LOOP, i.e. the normal function for a command with message format LOOP.

Successful: The CP receives a message RELOOP with exactly the output test pattern.

A30828-Y1187-N510-2-7620

41


Id:0900d805800bec07

b) Testing type B:The task of the MBU:SGC is to create a fault simulation which disturbs the dialog between IOP:MB and MBU:SGC.

After the fault simulation is ended, the identical looping of another LOOP must function without restriction in a contrary test (operation and analysis is as for testing type A).

c) Testing type C:The input capability of the MBU:SGC is blocked by a fault simulation. The MBU:SGC cannot reply with RELOOP to the following command LOOP.

After the fault simulation is ended, the identical looping of another LOOP must function without restriction in a contrary test (operation and analysis is as for testing type A). The RELOOP message buffered during the fault simulation must be previ-ously deleted.

d) Testing type D:The task of the MBU:SGC is the generation and sending of an error message with message format MBRETEST.

e) Testing type E:The output capability of the MBU:SGC is blocked by a fault simulation. The following command LOOP cannot be given by the IOP:MB.

Once the fault simulation has been ended, the IOP:MB must be able to give the command LOOP, which is still stored. The CP awaits an appropriate RELOOP message from the MBU:SGC. (Operation and analysis is as for testing type A).

The individual test steps of phase 1 are listed in the following table (the first command MBTEST has the test block number 10, the last command the number 1B):

Unsuccessful: e.g. input/output fault (IOFAULT) on the IOP:MB or the test pattern was mutilated.

Successful: No reaction of the MBU:SGC to LOOP; the IOP:MB reports an input/output fault (IOFAULT).

Unsuccessful: e.g. no IOFAULT from IOP:MB or a RELOOP from the MBU:SGC.

Successful: No inputs at all from the MBU:SGC.

Unsuccessful: e.g. message RELOOP

Successful: The CP receives the message MBRETEST with the same test block number as the previously output command MBTEST.

Unsuccessful: e.g. the CP does not receive the message MBRETEST

Successful: The LOOP remains in the output list of the IOP:MB.No RELOOP from the MBU:SGC.

Unsuccessful: e.g. RELOOP from the MBU:SGC.


MBTEST

Testing type


Is an IOFAULT

expected?


Comments

10 A SM1 N --- Test of fault-free normal operation

Table 7 Test steps of phase 1: MBU:SGC

42 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07


In SG.OPER the bytes of the command MBLOOPH'aabbccdd ddeeffgg gggggggg ggggggggH'gggggggg gggggggg gggggggg ggggzzzz

are interpreted according to the following table:

11 A SM6 N --- The input FIFO is deleted, followed by testing of normal fault-free operation

12 B SM2 Y SM6 Fault simulation: Parity falsification for the output FIFO with simultaneous deletion of the input FIFO. An artificial plausibility alarm is created, i.e. when the command LOOP arrives, a parity alarm is generated and the output FIFO must be deleted once more.

13 B SM3 Y Sm6 As in test block 12 only another test pattern is transferred with the command LOOP.

14 B SM4 Y SM6 As in test block 12 only another test pattern is transferred with the command LOOP.

15 B SM5 Y SM6 As in test block 12 only another test pattern is transferred with the command LOOP.

16 B SM7 Y SM6 Fault simulation:

The interface signal ACK1 is disabled. When the command LOOP arrives, no ACK1 is detected and thus no ACK2 is returned.(After each faulty entry of a command LOOP, the output LOOP must be deleted.)

17 C SM8 N SM6 Fault simulation:

Deletion of the output FIFO, i.e. after reception of command LOOP, the FIFO is deleted so that no message RELOOP is sent.

18 A SM7 --- --- Test of the normal fault-free operation

19 E SM8 --- --- Suppression of the output capability by setting CMDREQ.

1A E SM7 --- --- As in test block 19, only another test pattern is transferred with the command LOOP.

1B D --- --- --- Artificial error message sent by the MBU:SGC.


MBTEST

Testing type


Is an IOFAULT

expected?


Comments

Table 7 Test steps of phase 1: MBU:SGC (Cont.)

A30828-Y1187-N510-2-7620

43


Id:0900d805800bec07

3.10 MBU:SGC - Test Phase 2Test AreaPhase 2 is also described as an internal MBU overall test. All test steps which can run without the aid of the CP are carried out in a meaningful order in the MBU:SGC.

TestingTest phase 2 is started by the CP by sending the command MBTEST with the test block number 00. The rest of the testing operation is internally controlled by the hardware and firmware of the MBU:LTG.

The CP has no further influence. If no fault behavior is detected in the MBU:SGC in test phase 2, then the MBU:SGC generates a message MBRETEST with the test block number 00. The CP then ends the diagnosis test phase 2 and initiates phase 3.

In the event of a fault, the number of the test step (in the jargon in this document: test step = test block) which detected the fault is inserted in the message MBRETEST as test block number. As the MB diagnosis is principally aborted after the first detected fault, only an MBRETEST message is output and therefore only a test block number y (with 0A ≤ y ≤ 0D) occurs.

The test block number and an assigned fault list number are output in the diagnosis PROGRESS MESSAGE. The contents and the function of the individual test steps/test blocks are given in section 3.13 MBU:SGC - Interpretation of the TEST BLOCK NO.

The test blocks of test phase 2 are processed in the following order:

Byte Contents Explanation

aa

bb

cc

dddd

ee

ff

0F

00

1B

02

04

Origin of the message (sender). SGMES (safeguarding Monitor)

SG_OUTLength (number of the following bytes)

Processor number of the affected unit see MBB - IO Processor Numbers

Job code 1

Job code 2

g..g SM1

SM2

SM3

SM4

SM5

SM6

SM7

SM8

Testpattern93 1D 21 D6 31 CB EE 68 00

DF 3A E5 49 96 AC 73 00 00 00 00 00 00 0000 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 000D 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00FF 82 71 0D 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 005A C3 A5 3C 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 0081 42 24 18 7E BD DB E7 33

55 AA CC E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB

zz The bytes designated by z ... z are not occupied in this case. Entries not equal to 00 are also irrel-evant and cannot be interpreted.

Table 8 SG.OPER: Interpretation MBLOOP for MBU:SGC

44 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07


0A --> 0B --> 0C --> 0D

3.11 MBU:SGC - Test Phase 3Test AreaIn phase 3, the interface (SDC:SGC) between the MBU:SGC and the connected switch group controls (SGC) is tested. One, two or three SGCs are connected on an MBU:SGC.

TestingThe CP software starts the test phase 3 by outputting CHON commands (= channel on) to the MBU:SGC. As each connected SGC is connected with the MBU:SGC by a message channel (MCH), a maximum of 3 MCHs are affected by these commands. (For each connected MCH a corresponding CHON command is output). When the MBU:SGC receives the CHON commands, it attempts to synchronize the connected MCHs. For successful synchronization, each connected SGC generates the identity message FIMS, which is transferred to the CP from the MBU:SGC and analyzed there.

If the CP detects fault behavior, it reacts in the same manner as in test phase 1:

The diagnosis is aborted with result = FAULTS DETECTED and a diagnosis PROGRESS MESSAGE is output with a pseudo test block number and an assigned fault list number. The pseudo test block number (F5 or F6) represents the type of the detected fault. The contents of these pseudo test block numbers is described in section 3.13 MBU:SGC - Interpretation of the TEST BLOCK NO in the appropriate position (F5 or F6).

If the CP does not detect any fault here, it ends the MBU:SGC diagnosis with RESULT = NO FAULT DETECTED

3.12 MBU:SGC - Output MasksAs soon as the diagnosis has detected a fault in an MBU:SGC, the input command with the addendum PART. EXEC'D (partially executed) is repeated and subsequently a PROGRESS MESSAGE is output with the entire diagnosis information:PROGRESS MESSAGE MMN:@######### TEST RESULT= @### TESTED UNIT= @####### FLN:@######### ERROR INFORMATION: TEST BLOCK NO= @### ADDITIONAL INFORMATION: @####################################### @#######################################

Once the diagnosis has been completed, the command is repeated once more but this time with the additional EXEC'D. (The abortion procedure for the diagnosis is started immediately after the first fault is detected.) Then follows the result of the diagnosis with the message that a fault was detected, as here:RESULT = FAULTS DETECTED @

with: mb = 0 (for MB-0) or 1 (for MB-1)

mbus = 0 ... 3 = number of the MBU:SGC

A30828-Y1187-N510-2-7620

45


Id:0900d805800bec07

The significance of the output TEST BLOCK NO= H'xx and therefore the cause of the PROGRESS MESSAGE is given in the following pages.

Each suspect module can be determined via the fault lists FL:MB and FL:SN or FL:SNB (for an SN of type SNB) in register TAB of MMN:MB. The associated fault list number FLN:MBUS-y is found in the table, to the right of the test block number.

As explained in the previous sections, each test block number signifies either a specific test step for which fault behavior was found, or - as pseudo test block number - a fault behavior which the CP detected in the diagnosis phase 1 or 3 in dialog with the MBU:SGC.

3.13 MBU:SGC - Interpretation of the TEST BLOCK NO

TEST BLOCK

NO

Asso-ciated FLN:MBU

S


refer to 3.14 MBUS -

Notes)

00 The MBU:SGC diagnosis test phase 2 was completely executed and no fault was detected. (This test block number does not appear as in this case no diagnosis PROGRESS MESSAGE is output. The number can however be read from SG.OPER for example.)

0A 51 ROM (EPROM) test in the MBU:SGC (module IOPC). A sum is formed by adding all the contents together.

1.

0B 51 RAM test in the MBU:SGC (module IOPC). A sum is formed by adding all the contents together.

2.

0C 51 Using an internal test loop, the HSCC channel 2 (= the channel to the first of the maximum of three connected switch group controls SGC) is tested. In addition, timer 2 (50 ms) is tested.

17.

0D 51 Using internal test loops, the HSCC channels 4 and 6 (= the channels to the second and third of the maximum of three connected switch group controls) are tested. In addition, timer 2 (50 ms) is tested.

17.

10 52 Test of normal fault-free operation 3.

11 52 The input FIFO is deleted, followed by testing of normal fault-free opera-tion.

3.

12 52 The following fault simulation is activated in the MBU:SGC: parity falsifi-cation for the output FIFO and deletion of the input FIFO at the same time. In this way an artificial alarm is created, i.e. when the command LOOP arrives, a parity alarm results and the output FIFO must be deleted again.

3.

13 52 As in test block 12 only another test pattern is transferred here with the command LOOP.

3.


3.


3.

Table 9 Interpretation table: TEST BLOCK NO for MBU:SGC

46 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07


16 52 The following fault simulation is activated in the MBU:SGC:

The interface signal ACK1 is disabled. When the IOP:MB finally wants to transfer the command LOOP with the test pattern, the MBU:SGC no longer detects the ACK1 signal and also does not acknowledge the command and with ACK2. The IOP:MB then assumes an input/output fault. (After every faulty input of a command LOOP, the output FIFO must be deleted.)

3.

17 52 The following fault simulation is activated in the MBU:SGC:

After the next output the output FIFO is immediately deleted again. On receiving the command LOOP, the FIFO is deleted again and no message RELOOP is issued.

3.

18 52 Test of normal fault-free operation. 3.

19 52 By fixed setting of the REQ signal (CMDREQ) the output capability of the MBU:SGC is suppressed. The IOP:MB can no longer send the following LOOP command to the MBU:SGC.

3.

1A 52 As for test block 19 only another test pattern is used here for the command LOOP.

3.

1B 52 Sending of an artificial error message via the MBU:SGC. 3.

E0 54 During a type A test step, an incorrect IORESP message was received after an IOKONF command with MBU-RESTART.

4., 5., 6., 7.

E1 54 During a type A test step, an IOFAULT message was output after an IOKONF command with MBU-RESTART.

4., 5., 6., 8.

E2 54 During a type A test step, an unexpected message was received from the MBU:SGC after an IOKONF command with MBU-RESTART.

4., 5., 6.

E3 54 During a type A test step, an IOFAULT message was issued instead of an expected RELOOP message from the MBU:SGC.

4., 8., 9.

E4 54 During a type A test step, in place of an expected RELOOP message another unexpected MBU:SGC message was received.

4., 9.

E5 54 During a type B test step, an incorrect IORESP message was received after an IOKONF command.

4., 5., 7.

E6 54 During a type B test step, an unexpected IOFAULT message was issued after an IOKONF command.

4., 5., 8.

E7 54 During a type B test step, an unexpected command was received from the MBU:SGC after an IOKONF command.

4., 5.

E8 54 During a type B test step, a message arrived from the MBU:SGC although the delay timer TD2 had not yet expired.

4., 10.

E9 54 During a type B test step, an incorrect IORESP message was received after an IORSOUT command.

4., 7., 11.

EA 54 During a type B test step, the delay timer TD2 expired before the deletion of the output list was acknowledge by an IORESP message.

4., 7., 10.

EB 54 During a type C or E test step, a message was received from the MBU:SGC although the delay timer TD2 had not yet expired.

4., 10.

EC 54 During a type B test step, an IOFAULT message with incorrect parame-ters was issued after a LOOP command.

4., 8., 12.

TEST BLOCK

NO

Asso-ciated FLN:MBU

S



Notes)

Table 9 Interpretation table: TEST BLOCK NO for MBU:SGC (Cont.)

A30828-Y1187-N510-2-7620

47


Id:0900d805800bec07

3.14 MBUS - NotesAdditional explanations for the interpretation table of the test block numbers output in a diagnosis PROGRESS MESSAGE for an MBU:SGC:1. Procedure for ROM test (EPROM test)

ED 54 During a type B test step, a message from the MBU:SGC was received in place of an interface error message after a LOOP command.

4., 12.

EE 54 During a type B test step, the delay timer TD2 expired before an interface error message was received.

4., 10.

EF 54 During a type D test step, a message MBUR (MBU ready) is received with a false processor number after an IOKONF command with MBU-RESTART.

4., 5., 6.

F0 54 An IOFAULT message was issued after a command MBTEST was output.

4., 8., 13.

F1 54 Before the command LOOP is sent to the MBU:SGC with the test pattern, an unexpected message is received from the MBU:SGC.

4., 12.

F2 54 During a type D test step, a message MBRETEST was issued with a false test block number from the MBU:SGC.

4., 14.

F3 54 After outputting the command MBTEST for initiating the internal MBU:SGC diagnosis (= test phase 2), an IOFAULT message was issued.

8., 13.

F4 54 The supervisory timer for the test phase 2 (TS2) of the MBU:SGC has expired. However no MBRETEST message was received.

10., 14.

F5 54 The supervisory timer TS3 for the diagnosis test phase 3 has expired. No FIMS message has arrived from even one of the connected SGCs.

15.

F6 54 After output of the command CHON in the diagnosis test phase 3, a FIMS message arrives with a false processor number.

16.

F7 54 During a type A test step, a LOOP command was answered by a RELOOP message with a false processor number.

4., 9., 12.

F8 54 After output of the command MBTEST for initiating the internal MBU:SGC diagnosis (= test phase 2), a message MBRETEST arrived with a false processor number.

13., 14.

F9 54 During a type C or E test step, an IOFAULT message was issued after a LOOP command.

4., 8., 12.

FD 54 The supervisory timer for the test phase 1 (TS1) has expired without phase 1 being able to be concluded.

10.

TEST BLOCK

NO

Asso-ciated FLN:MBU

S



Notes)

Table 9 Interpretation table: TEST BLOCK NO for MBU:SGC (Cont.)

48 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07


The ROM contents are added together byte for byte from ROMSTART up to and including the fourth-last byte (ROMEND-3). The result is a three-byte sum. The last three bytes of the ROM similarly form a three-byte checksum. ROMEND thereby contains the most significant byte of this checksum. The two three-byte numbers (sum and checksum) are compared. If successful, i.e. if no fault is detected, the two numbers are identical. Every divergence of the sum from the checksum is seen by the test as a ROM fault. The test of this ROM is then concluded.

2. Procedure for RAM test:The RAM is sectioned into areas 8 byte large for the test. During the on-line routine test only one area is tested in a test cycle for dynamic reasons, whereas the diag-nosis tests all areas, one immediately after the other. The test program is also newly called for each area in this procedure.The individual area test is the same for all areas: A byte is written with the test pattern CCH. Subsequently, the test pattern is read out again. The values written in and read out are compared. If a discrepancy exists, a RAM fault is detected and the test is terminated. If both values correspond, the pro-cedure is repeated with the test pattern 33H. The selection of this combination of test patterns ensures that altogether every bit memory position is written and read once with 0 and once with 1. If the algorithms does not detect a fault for a byte, it continues the test immediately with the next byte of the area until the entire area is tested. As part of the diagnosis, the same test is invoked immediately afterwards for the next area.The RAM test is concluded with the result "fault-free" when all areas have been tested in this way and no fault was detected.

3. This test block number is only called as part of the diagnosis test phase 1. It is output in the diagnosis PROGRESS MESSAGE, if a fault is detected by the test started after the fault simulation ends.

4. This test block number is a pseudo test block number of the MBU:SGC diagnosis test phase 1.The fault behavior shown must be seen in connection with the procedure for the indi-vidual testing types described in section 3.9 MBU:SGC - Test Phase 1.

5. IOKONF is a CP software command to the IOP:MB.In this case, the command's contents signify that the affected MBU:SGC must be included in or blocked out of the scan cycle. The command for inclusion in the scan cycle can contain a directive for transfer of a RESTART command to the MBU:SGC at the same time. The inclusion can however be carried out without RESTART.Messages can only be exchanged between the CP and MBU:SGC when the MBU:SGC is included in the scan cycle.

6. MBU-RESTART is a special interface signal which the IOP:MB applies to an MBU via the B:MBG.The signal practically causes a newstart of the affected MBU: the hardware/proces-sors are reset and the firmware is newly initialized. All stored messages/flags/regis-ter contents are deleted. The MBU then switches to IDLE and awaits further instructions from the CP, e.g. diagnosis commands or return to normal operation by setting up the message channels etc.

With: ROMSTART = first byte of the ROM

ROMEND = last byte of the ROM

A30828-Y1187-N510-2-7620

49


Id:0900d805800bec07

7. IORESP is an acknowledgment from the IOP:MB to the CP software for a received IOKONF or IORSOUT command. If the associated command could not, or only incompletely, carried out, additional parameters are transferred with IORESP. At the same time the MBU is removed from the scan cycle.

8. IOFAULT is a message from the IOP:MB to the CP software.IOFAULT reports an interface fault between the IOP:MB and MBU:SGC if the fault occurs twice in succession. The affected MBU:SGC is removed from the scan cycle as reliable message exchange is no longer possible with it. In normal operation, IOFAULT usually signifies total failure of the MBU:SGC (even a diagnosis is not pos-sible), for example, as a result of power failure. During an MB diagnosis, IOFAULT is partly deliberately initiated using fault simulation.

9. RELOOP is an MBU:SGC message to the CP.A test pattern is transferred from the CP to the MBU:SGC with the command LOOP (see 12). The MBU:SGC loops the test pattern (= transfer of the pattern from the output side to the input side and conversion to a message format) and transfers it as message RELOOP back to the CP. Once this test pattern has been received again, it is compared in the CP with the pattern previously output. In normal operation, devi-ation causes an error message. During diagnosis, deliberate differences are partly provoked by fault simulation.

10. The following timers are used for the diagnosis of an MBU:SGC:In the MBU:SGC firmware:

Delay timers in the CP software:

Supervisory timers in the CP software

TM1 (min. 200 ms, max. 800 ms)

Waiting time between the creation of a fault simulation and the stopping of the simulation for testing types B and C.

TM2 (min. 1400 ms, max. 1700 ms)

Waiting time between the creation of a fault simulation and the stopping of the simulation for testing type E.


Waiting time between the sending of a command MBTEST for diagnosis phase 1 and the following command LOOP with the corresponding test pattern.

TD2 (min. 900 ms, max. 1100 ms)

Waiting time between the output of the command LOOP for a test step of diagnosis phase 1 and the start of the test step analysis.


Protection time before expiry of a test block of the diagnosis phase 1 (before the next test block is started).

TCB (min. 50 ms, max. 150 ms)

Waiting time for messages still arriving from the MBU:SGC.

TS1 (2 minutes) supervisory timer of diagnosis test phase 1. The expiry of TS1 causes the abortion of an active test phase 1 and therefore the conclusion of the diagnosis with the result = FAULTS DETECTED.

50 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07


11. IORSOUT is a CP software command to the input/output call processing periphery (EAVT or IOCP) for resetting the output list.(New linkage: set the W/R CHAR of the list positions to "writable" and set the read and write pointers to the same state as after initialization.)

12. LOOP is a CP command to the MBU:SGC.A test pattern is transferred from the CP to the MBU:SGC with the command LOOP. Depending on the fault simulation used, an interface error message IOFAULT (see 8) or a (possibly falsified) message RELOOP (see also 9: RELOOP) for example is expected during the diagnosis.

13. MBTEST is a CP command to the MBU:SGC.A test function is called in the MBU:SGC with this command. For example, an internal overall test of the diagnosis test phase 2 or creation of a fault simulation (see sections 3.9 MBU:SGC - Test Phase 1 and 3.10 MBU:SGC - Test Phase 2).

14. MBRETEST is an MBU:SGC message to the CP.This message is a reply to the command MBTEST. The execution or the result of a test job is reported.

15. See also section 3.11 MBU:SGC - Test Phase 3 for diagnosis of the MBU:SGC.With the expiry of TS3 the diagnosis was aborted with result = FAULTS DETECTED. A diagnosis PROGRESS MESSAGE (with test block number) was also output. In the first three bits in the ADDITIONAL INFORMATION of the PROGRESS MESSAGE the value C1, C2 and/or C3 is given. C1, C2 and C3 represent the maximum three message channels connected on the MBU:SGC to the switch group controls (SGC). The expected message FIMS could not be received via the message channels spec-ified in the ADDITIONAL INFORMATION. See the fault list FL:SN or FL:SNB (for SN of type SNB) in MMN:MB, register TAB to determine the associated SGC.The output of the test block number H'F5 during the diagnosis of an MBU:SGC always signifies a fault at the interface SDC:SGC between MBU:SGC and SN. For fault clearance, modules must usually be replaced in the MB and in the SN. The fault verification after every module replacement must always be carried out via the MBU:SGC diagnosis.This type of fault is detected by the MMN:MB procedures, but as the fault clearance is very complex, it cannot always be competently carried out by personnel from the conventional system maintenance. For clearance of such fault types, it is therefore recommended for the system spe-cialist to reproduce this procedure before implementing personal measures. Appropriate assistance is offered for example in MMN:MB, register FC in the proce-dure: PR:MB.If this procedure is unsuccessful, the associated SN/switch group is even more suspect because the MBU:SGC was almost entirely tested during the diagnosis test

TS2 (1 minute) supervisory timer of diagnosis test phase 2. The expiry of TS2 causes the abortion of an active test phase 2 and therefore the conclusion of the diagnosis with the result = FAULTS DETECTED.

TS3 (1 1 second) supervisory timer of diagnosis test phase 3.The expiry of TS3 causes the abortion of an active test phase 3 and therefore the con-clusion of the diagnosis with the result = FAULTS DETECTED.

A30828-Y1187-N510-2-7620

51


Id:0900d805800bec07

phases 1 and 2. Running test phase 3 implies that the first two test phases could not detect a fault. If a fault with the fault characteristic H'F5 could not be cleared by replacing modules, the module frames (backplane, connector strip) in the MB and SN which contain the suspect modules are likewise suspect. The connecting cable SDC:SGC between the MB and affected SN unit is also suspect.

16. See also section 3.11 MBU:SGC - Test Phase 3. for diagnosis of the MBU:SGC.The output of this pseudo test block number generally indicates a cabling fault between the MBU:SGC and the connected switch group controls (SGC). For this reason, a correctly sent SGC processor number from the MBU:SGC was received on the wrong message channel.

17. This test runs practically internally in the HSCC chip - only the test initiation is given by the processor.For the test, the output of the transmission side (TX) of the HSCC chip is short-circuited to the input of the receive side. First of all, the timer test is carried out: The receive side of the HSCC is blocked (disabled) and the transmission side is commanded to carry out the SYN procedure (for normal operation: = synchroniza-tion of a connected MCH to the SGC). The disabled receive side does not react to the SYN signals until finally the timer is activated and the SYN procedure is aborted. The abortion of the SYN procedure within the defined time frame thus signifies that the timer functions properly. For the second test step, the receiver is released (enabled). As the receive and transmission sides of the HSCC chip are short-circuited, both can carry out the SYN procedure with each other. If the SYN procedure runs without faults, the previously tested timer must not be activated. Should the timer not be activated within the defined time limit for the second test step, the HSCC chip is assumed to be faultfree.

3.15 Diagnosis of an MBU (of an MB) is not executedThe input diagnosis command is repeated with the addendum NOT EXEC'D . On another line, the reason the diagnosis was not carried out is given by a code word.

Only the code word HARDWARE FAULT is of any great significance here.

For all other code words, see in the MMN:MB, Introduction. Usually the fault in this case is due to a user error which can be quickly corrected by simple interpretation of the mostly self-explanatory code word. Software errors are notably rare in connection with the MB diagnosis. In this case, individual measures are necessary - up to CP recovery (NSTART 1-3) at times of relatively little traffic.

Possible causes of the code word HARDWARE FAULT:

For MB diagnosis, the CP (via the IOP:MB) and the affected MBU work closely together. It therefore requires a minimum function of the MBU concerned (RESTART successful, MBU reports with MBUR = MBU ready). If these basic conditions cannot be fulfilled by the MBU, the diagnosis cannot be run and is rejected with the code word HARDWARE FAULT.

before the diagnosis is finally rejected, an additional ERROR MESSAGE with an MMN number MB130-1000 and another code word is output. Possible code words are as follows:

NO REACTION TO RESTART OF MBUL

52 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec07


NO REACTION TO RESTART OF MBUS

NO LOOP RESPONSE

MUTILATED LOOP RESPONSE

NO RESPONSE FROM MBU

IOFAULT

IORESP

MBU ERROR

This error message can be further interpreted if necessary and can deliver more symptoms on the fault type (see section MMN:MB130-1000).

A30828-Y1187-N510-2-7620

53

NM:MB Interpretation of MBD alarm messages

Id:0900d805806b9166

4 Interpretation of MBD alarm messagesInternal on-line routine test - hardwareInternal routine test in the MB units does not have to be called up by the operator, but runs continuously without adversely affecting switching operations (endless loop). A low priority is allocated by default to the internal routine test on the ASIC of the MB modules. The CP also initiates periodic tests. The main tests are as follows: FEPROM (checksum test once daily with STAGCG), SDRAM (checksum test approximately every 500 ms), the internal bus system (IBUS test within a module and between the modules every 100 ms), the RESBUS routine test and initiation by MBD maintenance (daily). The daily routine test is performed during the low-traffic period. The units are taken out of service one after the other and then diagnosed. The interfaces are also tested one after the other. The routine test in particular also tests redundancy paths and supervisory circuits which are normally not used but will only be activated in case of faults.

If fault behavior is identified in the course of a test, the ASIC internal routine test retains this test result and repeats the complete test sequence starting with a RESET.

Two types of faults are distinguished: Faults which generate an MBDERR message but do not RESET the ASIC and faults where the ASIC is reset and no MBDERR message is generated. The CP only receives the cause of the fault after successful startup with the subsequent MBDREADY/MBDERR message. MBDREADY is generated if the IBUS test was concluded successfully with a test message to its own address.

Faults such as checksum faults, memory protection violations, SDRAM parity faults and watchdog reset are detected by the ASIC and it also initiates the RESET. Faults which are detected by another ASIC, such as IBUS and RESBUS faults, are reported to the MBDIF master on the MBDC module. This determines the suspect ASIC and initiates the RESET for this ASIC. On confirmation of this fault, an error message in MB_MBDERR format is sent to the CP via module MBDC. If the fault is not confirmed, the CP receives the message MBDREADY. Depending on the type of fault, a total or partial failure handling is initiated.

Total failure handlingThe FA:MB first of all disconnects the unit concerned. If the disconnection is successful, a critical alarm is reported and a fault printout is output. In case there is no redundancy and the disconnection of an MBIH (last MBIH) leads to a total failure of the MBD, ISTART1 is initiated. If a deactivation task for an MBIA is rejected because there is no redundancy, the unit is always configured to UNA, a fault printout output and a major alarm reported.

Partial failure handlingPartial failure cause conditional deactivation of the unit concerned i.e. the unit is only switched to UNA if redundancy is available. A critical alarm is reported and an alarm message is output.

If there is no redundancy a major alarm is reported and the fault is displayed. The FA:MB therefore foregoes deactivation of the unit. concerned in this case. The device remains in ACT.

This alarm message is admittedly only an indication of the possible failure of an MBU - however it signifies the utmost danger at the same time because of the lack of redun-dancy: Faultless exchange of messages between the CP and periphery is immediately

54 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166

Interpretation of MBD alarm messages

no longer guaranteed. Faults in the call processing traffic up to (partial) failure of the net node must be reckoned with.

Therefore, if an appropriate MB unit was taken out of service in the redundant system side or an appropriate SN unit by the operator (e.g. for diagnosis, the hardware test, module replacement etc.), it is recommended that these units be put into service again with the highest priority, i.e.

– For preventive diagnosis: After termination of the diagnosis, immediately configure the MB unit to ACT or the SN unit to STB (independent of the diagnosis result).

– For checking/cleaning the hardware: Insert all cables and all modules immediately and configure the MB unit to ACT and without further testing configure the SN unit to STB

– For fault clearance: Replace all the suspect modules or in case of doubt all the modules of the faulty unit (MBIxx, SN, TSG or SSG, SNMUX or SNMAT) at the same time and without further testing configure the MB unit to ACT and the SN unit to STB.

The last two cases are very time-critical: It is important that there is operative hardware and firmware for at least one system side for any new system start which may have already been started and thereby to be successful.

StartupAfter a reset, the ASICs on the MBD modules load their program code from the FEPROMs. If all the ASICs of a module are reset, the master ASIC has first access to the FEPROMs. The remaining ASICs then follow in the sequence of wiring. If an ASIC accesses the FEPROM, it blocks all the other ASICs from accessing it. The complete FW/SW for operating the MBD is stored in the FEPROM, i.e. no code is loaded from the CP as part of the MBD startup. The checksum and the slot are then checked.

Reset causes

– Power-on reset: Voltage supervision on the modules detects a power up (after module insertion for example) or fluctuations in the power supply on the module and initiates the reset.

– Each MBD module has a switch on the front panel via which all the ASICs can be reset manually.

– Software, watchdog and double bus error reset are equivalent and can only occur if the firmware is active.

– RESBUS reset of an individual ASIC or all the ASICs of a module: All the ASICs on a module can be reset at the same time by the MBDC via the RESBUS.

– RESBUS reset for master ASIC on MBDC – RESBUS reset of one MBD side: All the modules of an MBD side except the MBDC

can be reset at the same time by the MBDC via the RESBUS (see restart CP).

4.1 MBD - IO processor numbersThe IO processor numbers of the equipment or the unit concerned are output as a double byte in the alarm message. These numbers are used by CP to address the pro-cessor of the corresponding unit in the periphery.

A30828-Y1187-N510-2-7620

55


Id:0900d805806b9166

4.2 MMN:MB210-2001 - MBIA or MBIH MODULE FAILURE EQUIPMENT ALARM MMN:MB210-2001 ALARM PRIORITY: @####### PROBABLE CAUSE: @################################################# SPECIFIC PROBLEM: EQUIPMENT MALFUNCTION MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#

CONFIGURATION: UNIT FROM TO +------------+-----+----+ @########## @## @## SUPPLEMENTARY INFORMATION: H’zzzzzzzz aazzbbcc zzddeezz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz

IO processor number associated MB units

hexadecimal decimal

0B 88

0B 89

3000

3001

MBIC-0

MBIC-1

0B C2 (C2 0B)

0B C3 (C3 0B)

0B C4 (C4 0B)

0B C5 (C5 0B)

0B C6 (C6 0B)

0B C7 (C7 0B)

0B C8 (C8 0B)

0B C9 (C9 0B)

0B CA (CA 0B)

0B CB (CB 0B)

0B CC (CC 0B)

0B CD (CD 0B)

0B CE (CE 0B)

0B CF (CF 0B)

0B D0 (D0 0B)

0B D1 (D1 0B9

3010

3011

3012

3013

3014

3015

3016

3017

3018

3019

3020

3021

3022

3023

3024

3025

MBIH-0-0 or MBIE-0-7
















0B D6 (D6 0B)

0B D7 (D7 0B)

0B D8 (D8 0B)

0B D9 (D9 0B)

0B DA (DA 0B)

0B DB (DB 0B)

0B DC (DC 0B)

0B DD (DD 0B)

0B DE (DE 0B)

0B DF (DF 0B)

3030

3031

3032

3033

3034

3035

3036

3037

3038

3039

MBIA-0-0

MBIA-1-0

MBIA-0-1

MBIA-1-1

MBIA-0-2

MBIA-1-2

MBIA-0-3

MBIA-1-3

MBIA-0-4

MBIA-1-4

Table 10 MB processors for MBD

56 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz

Interpretation of the supplementary information bytes • aa: Origin of the message

• bb: Type of module

• cc: Module number together with the byte bb module type:

• dd: Classification of the detected fault

• ee: Detailed fault information

SPECIFIC PROBLEM MBIA TOTAL FAULT: MODULE FAILURE

MBIA PARTIAL FAULT: MODULE FAILURE

MBIH TOTAL FAULT: MODULE FAILURE

MBIH PARTIAL FAULT: MODULE FAILURE

11 SG_FA_MB

01 MBDC

02 MBDH

03 MBDA

00 ... 07 MBDH or

00 ... 04 MBDA

01 Total failure

02 Partial failure

02 RESBUS fault (faulty reset bus).

03 ASIC of the module concerned does not send READY: The RESBUS is a uni-directional bus in which case the MBDC module is the sender. RESET request acknowledgments are sent to MBDC via the IBUS. If this acknowledgment fails to appear (READY), this will be detected by the MBDC.

04 FEPROM fault: Each FW/SW version in the FEPROM is protected by a checksum which is checked when it is loaded from the FEPROM into the SDRAM and when it is checked in the routine test by each ASIC.

05 Parity error (startup after RESET unsuccessful). The data bus between ASIC and the SDRAMs is protected with 4 bit parity which is stored in the SDRAMs together with each data word. A parity error causes a reset of the correspond-ing ASICs.

Parity supervision: For write access to the SDRAM a parity bit is calculated for each byte. The parity bit is supplemented for even parity. The parity is only cal-culated for bytes which are constructionated as valid by the byte enable signal. The parity is stored with the data in the SDRAM. For read access from the SDRAM, the parity of the read data is recalculated and compared with the stored parity

06 SDRAM fault, startup after RESET unsuccessful

A30828-Y1187-N510-2-7620

57


Id:0900d805806b9166

• z...z: These bytes are not occupied. Entries not equal to 0 are also not relevant.

System reaction

– The corresponding MB unit is configured to UNA if the partner unit is ACT. If there is no redundancy, the MB unit remains ACT in the case of a partial failure. In the case of total failure the unit will be configured to UNA unconditionally. ISTART1 is initiated if the disconnection of an MBIH (last MBIH) leads to a total failure of the MBD.

– The malfunction will be displayed under object MB as a critical alarm or, if there is no redundancy, as a major alarm.

– The log will be stored in the history file and entered into the alarm file (AM.ALARM).

Fault handlingAn MB alarm message with MMN number MB210-2001 will be output if the internal on-line routine test of the ASIC of the module concerned has detected a hardware fault. Depending on whether or not one or all the ASICs of a module is/are involved, partial or total failure management is initiated by FA:MB.

Main suspect modules

Further suspect modulesThe Frames (backplane, connector strip). For M:MBDA: FOTX

Cross-referencesDiagram of the MB Racks and the associated fuses: Construction, Racks.

Diagram of frames - module side, backplane and cabling: Construction, Frames F:MB/CCG or Construction, Frames F:IOPMBD and Construction, Frames F:SN.

Display of module face plates and explanation of the LEDs: Construction, Modules MB and Construction, Modules SN.

07 Memory protection violation. The SDRAM controller supervises access to the SDRAM (e.g. access to the HDLC controller on the IBUS data areas in the SDRAM).

08 Memory shortage

09 ATM230 fault. ASIC ATM230 on MBDA does not send a READY message in response to the reset request

0B BIST fault (result message of the BIST). Fault after ASIC startup. The entire logic of the ASIC including the RAM is tested by the BIST

bb = 02 M:MBDH on both sides, cables between the two MBDH modules

bb = 03 M:MBDA on both sides, cables between the two MBDA modules

58 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


HDLC interface (connection to SND)

D DataT ClockFMB Frame Mark BitGND Ground*1 x= 0, 2, 4, 6, 8, 10, 12, 14*2 y= 1, 3, 5, 7, 9, 11, 13, 15

Figure 1 HDLC interface MBIH <--> SND

The LTG-IF0 interface is connected with the LTG on the switching network. Two ASIC always work together in pairs. Upon signal transmission to the LTG, one pair’s HDLC-Slave-ASIC sends the data to the HDLC-Master-ASIC, which connects all 64 MCH together and forwards them on to the LTG. The incoming signals from the LTG go to both ASICs.

HDLC interface (connection to SND in B-Mode)In MBD MBU:LTG and MBU:SGC exist as logical units on the module MBDH. A module MBDH usually comprises 4 MBU:LTG and 2 MBU:SGC. In SNDB TSG and SSG exist as logical units on SNMUX. One SNMUX comprises of 2 TSG and 1 SSG.

ASIC No.

on MBDH

0...7

0

HDLC-

Slave

1

HDLC-

Master

2

HDLC-

Slave

3

HDLC-

Master

4

HDLC-

Slave

5

HDLC-

Master

6

HDLC-

Slave

7

HDLC-

Master

MCH No. 0...31 32...63 0...31 32...63 0...31 32...63 0...31 32...63

connected to: LILD0 / LILE0

SNMUX0, 2...14

LILD4 / LILE0

SNMUX0, 2...14

LILD0 /LILE1

SNMUX1, 3...15

LILD4 / LILE1

SNMUX1, 3...15

Table 11 Assignment of MCH to ASIC on M:MBDH

SGC5SGC4SGC3SGC2SGC1SGC0SGC interface

LTG1...63

LTG64...126

LTG127...189

LTG190...252

LTG interfaces: LTG-IF0...LTG-IF3

SND

D, TFMB

D, TFMB

D, TFMB

D, TFMB

3 3 3 3

SNMUX-x *1 SNMUX-y *2

MUXC-x *1 MUXC-y *2

SNMUX-x *1

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TGND

D, TGND

D, TGND

D, TGND

D, TGND

D, TGND MBDCG

SNMAT

MATC-1

MBDH

SNMUX-y *2

LILE 0/LILD 0

LILE 0/LILD 4

LILE 0/LILD 4

LILE 0/LILD 0

A30828-Y1187-N510-2-7620

59


Id:0900d805806b9166

D DataT ClockFMB Frame Mark BitGND Ground

Figure 2 HDLC interface MBIH <--> SND in B-Mode for DE52

The LTG-IF0 interface is connected with the LTG on the switching network. Two ASIC always work together in pairs. Upon signal transmission to the LTG, one pair’s HDLC-Slave-ASIC sends the data to the HDLC-Master-Asic, which connects all 64 MCH and forwards them on to the LTG. The incoming signals from the LTG go to both ASICs. In DE51 only 126LTGs are supported.

ASIC No. 0 1 2 4 5 6

SGC IF No. 0 1 2 3 4 5

connected with: TSG SSG TSG TSG SSG TSG

Table 12 Assignment of SGC IF interfaces to ASIC on M:MBDH

SGC5SGC4SGC3SGC2SGC1SGC0

SGC interface

LTG1...63

LTG64...126

LTG127...189

LTG190...252

LTG interfaces LTG-IF0...LTGIF3

SNDB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

3 3 3 3

LILD0 LILD4 LILD0 LILD4

SNMUX SNMUX

MUXC-0 MUXC-y

SNMUX

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TGND

D, TGND

D, TGND

D, TGND

D, TGND

D, TGND

MBDH

SNMUX

TSG SSG TSG TSG SSG TSG

D, TFMB

TSG-0 TSG-1 TSG-2 TSG-3

LILE0 or LILE1 or

60 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


HDLC interface (connection to SNA or the SNB)


Figure 3 HDLC interface MBIH <--> SNA/SNB

Interfaces LTG-IF0 through LTG-IF3 are connected to the LTG via the switching network. Two ASICs always function together as a pair. For signal transmission to the LTG, the HDLC slave ASIC of a pair transfers the data to the HDLC master ASIC. This combines all 64 MCHs and forwards them to the LTG. The signals coming from the LTG go to both ASICs.

A LOOP message is sent via the active paths every 5 s from the CP via the MB to the LTG, which sends it back again. Only flags are sent over the stand-by paths. If another pattern is identified (e.g. IDLE pattern for physical interruption), this will be reported to the CP which then checks the corresponding HDLC path.

The HDLC log supervises the paths with different mechanisms such as CRC, frame abort or negative repeat sequences.

ASIC No. 0

HDLC-

Slave

1

HDLC

-Master

2

HDLC

-Slave

3

HDLC-

Master

4

HDLC-

Slave

5

HDLC-

Master

6

HDLC-

Slave

7

HDLC-

Master

MCH No. 0...31 32...63 0...31 32...63 0...31 32...63 0...31 32...63

Table 13 Allocation of the MCHs to the ASICs on M:MBDH

TSGSSG TSGSSGTSGTSG

SGC


SGC interface

LTG1...63

LTG64...126

LTG127...189

LTG190...252

LTG interfaces: LTG-IF0...LTGIF3

SNA, SNB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TGND

D, TGND

D, TGND

D, TGND

D, TGND

D, TGND

A30828-Y1187-N510-2-7620

61


Id:0900d805806b9166

Optical interface (connection to the AMX via FOTX)

Figure 4 Optical interface MBD <--> SCB

Figure 5 Optical interface MBD <--> SCE

FOTX 01

FOTX 00

FOTX 20

FOTX 21

MBDA0

D2

Port 0

Port1

Port 0

Port 0

C5

C3

C1ATM

Bridge2

ATMBridge3

FOTX 11

FOTX 10

FOTX 30

FOTX 31

MBDA0

D2

Port 0

Port1

Port 0

Port1

C5

C3

C1ATM

Bridge2

ATMBridge3

MBD0

MBD1

FOTX 10

FOTX 00

FOTX 20

FOTX 30

149C3

149D2

149C5

149C1

PortYB_23

PortYB_19

PortYB_21

PortYB_17

AMXE

FOTX 11

FOTX 01

FOTX 21

FOTX 31

211C3

211D2

211C5

211C1

PortYB_23

PortYB_19

PortYB_21

PortYB_17

AMXE

SCB-Shelf AMX0

AMX1

FOTX 01

FOTX 00

FOTX 20

FOTX 21

MBDAx

D2

Port 0

Port1

Port 0

Port 1

C5

C3

C1

ATMBridge4, 6, 8or 10

ATMBridge5, 7, 9 or 11

FOTX 11

FOTX 10

FOTX 30

FOTX 31

MBDAx

D2

Port 0

Port1

Port 0

Port 1

C5

C3

C1



MBD0

MBD1

FOTX 10

FOTX 00

FOTX 20

FOTX 30

221C3

221D2

221C5

221C1

PortYB_23

PortYB_19

PortYB_21

PortYB_17

AMXE

FOTX 11

FOTX 01

FOTX 21

FOTX 31

261C3

261D2

261C5

261C1

PortYB_23

PortYB_19

PortYB_21

PortYB_17

AMXE

SCE-Shelf

AMX0

AMX1

62 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


4.3 MMN:MB210-2002 - MBIA or MBIH IBUS FAILURE EQUIPMENT ALARM MMN:MB210-2002 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#

CONFIGURATION: UNIT FROM TO +------------+-----+----+ @########## @## @## SUPPLEMENTARY INFORMATION: H’zzzzzzzz aazzbbcc zzddeezz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz




• dd: Classification of the malfunction detected



System reaction


– The malfunction is indicated under object MB as a critical alarm or, if there is no redundancy, as a major alarm.

SPECIFIC PROBLEM MBIA TOTAL FAULT: IBUS FAILURE

MBIA PARTIAL FAULT: IBUS FAILURE

MBIH TOTAL FAULT: IBUS FAILURE

MBIH PARTIAL FAULT: IBUS FAILURE

11 SG_FA_MB

02 MBDH

03 MBDA

00 ... 07 MBDH or

00 ... 04 MBDA

01 Total failure

02 Partial failure

0A IBUS fault

A30828-Y1187-N510-2-7620

63


Id:0900d805806b9166

– The log is stored in the history file and entered into the alarm file (AM.ALARM).

Cause/fault explanationAn MB alarm message with the MMN number MB210-2002 is output if the IBUS test routine has detected a malfunction in the internal bus system IBUS. The IBUS test forms part of the internal on-line routine test. A loop test is carried out approximately every 100 ms within a module and between the modules. Faults are detected if a test loop cannot close after a timer has expired or a test pattern was corrupted. The IBUS test has multiple levels.

IBUS test within a module: – Each ASIC sends an IBUSLOOP message. If a fault is identified, the ASIC is reset

again.– Approximately every 100 ms, each master ASIC sends an IBUSLOOP message to

its slave ASIC. If the master receives all the IBUSLOOPR acknowledgments, the module status is fault-free (green LED). If an acknowledgment fails, an MBDERR is generated after a repeat and sent to MBD maintenance. Module status faulty (red LED).

IBUS test between the modules of one system side:– In the IBUS routine test between the individual modules, each master ASIC sends

an IBUSLOOP to the masters of the modules configured offline or online. If the acknowledgment fails to appear, MBDERR is generated after a repeat and sent to MBD maintenance on M:MBDC.

IBUSLOOP: Test loop from the IBUS output on the corresponding IBUS input on the same module via the backplane of the Frames. The IBUS switch can be tested via this connection.

All the requirements which are sent via the IBUS are time-supervised (watchdog). If an IBUS sender does not receive an acknowledgment within the timeout period, this fact will be notified to the MBIC which then identified the faulty module.

Data faults (e.g. length) are identified by the CRC (cyclic redundancy check) and reported to the MBIC. The MBIC then issues an alarm message to the CP.

Processing an IBUS fault between two modules

Figure 6 Fault handling for IBUS faults between two modules

Tx-ASIC Rx-ASIC Tx-ASIC Rx-ASIC

MBDBIF

MBDC

M:MBDx M:MBDySwitch Switch

MB

DE

RR

MB

DE

RR

Req

uest

Request

IBU

SLO

OP

IBU

SLO

OP

R

Request2.

4.5. 6.

64 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


1. During normal operation a fault is identified on the IBUS (timeout, inactive)2. To confirm the fault, the generic maintenance software sends a test report to the

receiver who cannot be reached during operation 3. If the sender receives the acknowledgment (reply message), the fault is considered

to be sporadic and the blocking flags (timeout, inactive) are reset4. If the fault is confirmed, the sender generates an MBDERR message and sends this

to MBD maintenance on module MBDC5. The MBD_MTC tries to reach the marked receiver with a test message6. If the MBD_MTC receives the reply message, an IBUS fault is sent to the CP by indi-

cating both the modules concerned with MBDERR.7. If the MBD_MTC does not receive a reply message, the receiver ASIC is reported

as being faulty to the CP with MDERR.


Further suspect modules The Frames (backplane, connector strip).

Cross references:Diagram of the MB Racks and the associated fuses: Construction, Racks.

Diagram of the Frames and wiring: Construction, Frames F:MB/CCG orConstruction, Frames F:IOPMBD.

Display of module face plates and explanation of the LEDs: Construction, Modules MB.

4.4 MMN:MB210-2003 - MBIA or MBIH XLINK FAULT EQUIPMENT ALARM MMN:MB210-2003 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#


bb = 02 M:MBDH concerned, for IBUS fault between 2 modules of a system side, the other MBDHs of this system side

bb = 03 M:MBDA concerned, for IBUS fault between 2 modules of a system side, the other MBDAs of this system side

SPECIFIC PROBLEM MBIA XLINK FAULT

MBIH XLINK FAULT

A30828-Y1187-N510-2-7620

65


Id:0900d805806b9166



• cc: Module number together with the byte cc module type:



Further suspect units are in all cases: The appropriate Frames (backplane, connec-tor strip)


System reaction




Cause/fault explanationAn MB alarm message with the MMN number MB210-2003 is output if the routine test has detected a malfunction in the internal bus system for the one partner half (called XLINK). The IBUS test forms part of the internal on-line routine test. A loop test is carried out approximately every 100 ms within a module and between the modules of a system side and between the partner modules on both system sides.

The routine test for the one partner half is carried out by the master ASIC of the modules. The ASICs in the partner side are recorded with the MBDXLINK command in the list of the ASIC to be tested. In the routine test between the partner modules, each master ASIC sends an IBUSLOOP to the master on the partner module. If the IBUSLOOPR acknowledgment fails to appear, an MBDERR is generated after a repeat and sent to MBD maintenance on M:MBDC.

Processing a cross link fault

1. During normal operation, an IBUS fault will detected during a transmission to the partner side (timeout, inactive)

2. To confirm the fault, the ASIC sender tries to reach the master ASIC of the partner module in the subsequent IBUS test

11 SG_FA_MB

02 MBDH

03 MBDA

00 ... 07 MBDH or

00 ... 04 MBDA

05 XLINK fault

01 XLINK fault

66 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


3. No fault is reported if the sender receives the reply message. This fault must have been detected on the partner side.

4. A cross link fault is reported if the fault is confirmed, i.e. the partner master ASIC cannot be reached

Further fault handlingShould there be an XLINK fault, communication between redundant modules of the two MB sides is impossible. Reports and orders are blocked which has an extremely adverse effect the switching operations.

If one or more XLINKs are marked faulty:

First of all, the system preferred side is calculated. In so far as is possible, all the MBD bridges or the MCH are activated on this system side to prevent reports and orders from blocking.

For previous XLINK faults (pairs marked as faulty) the side has already been selected and the calculation can be omitted.

No previous XLINK faults: The best possible communication is guaranteed by the side with the highest number of active modules. All the active modules including those which have been activated are counted and, in this way, the preferred side is determined.

In order to prevent the unnecessary switching over of message channels and ATM bridges, the side not affected by the configuration at the moment is specified as the pre-ferred side, provided that it was not already determined in the previous stages.

If the preferred side is specified, all the available MCHs of an MBIH pair are switched actively with the faulty XLINK on the preferred side. The distribution of message channels is recalculated for faulty XLINKs in MBIH.

If an MBIA is affected, all the information about faults and the preferred side is sent to the bridge software.


Cross referencesDiagram of the MB Racks and the associated fuses: Construction, Racks.

Diagram of the Frames and wiring: Construction, Frames F:MB/CCG or Construction, Frames F:IOPMBD.


4.5 MMN:MB210-2004 - MBIA or MBIH TOO MANY RESETS EQUIPMENT ALARM MMN:MB210-2004 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#

bb = 02 M:MBDH and partner M:MBDH, cable between the two MBDH modules

bb = 03 M:MBDA and partner M:MBDA, cable between the two MBDA modules

A30828-Y1187-N510-2-7620

67


Id:0900d805806b9166

CONFIGURATION: UNIT FROM TO +------------+-----+----+ @########## @## @## SUPPLEMENTARY INFORMATION: H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz

An evaluation of the contents of the supplementary information can be dispensed with here. An exact fault analysis is impossible.

System reaction

– The corresponding MB unit is configured to UNA if the partner side is ACT. If there is no redundancy, the MB unit remains in ACT.



Cause/fault explanationIf an MBIH or MBIA is reset spontaneously, i.e. not because of configurations, FA:MB receives an MBDREADY message from the MB. A statistics counter is run for each MBIH and MBIA: Each spontaneously arriving MBDREADY message increments the statistics counter and the statistics counter is reduced by 1 each hour. If the MBIH is reset unexpectedly, the routing information is reloaded by the CP. An MB alarm message with the MMN number MB210-2004 is output if the number of MBDREADY messages from MBIH exceed 10 or 5 from MBIA.

Main suspect modulesModule M:MBDH or MBDA allocated to the reporting unit




4.6 MMN:MB210-2005 - MBIA or MBIH OLD FW LOADED EQUIPMENT ALARM MMN:MB210-2005 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#

CONFIGURATION: UNIT FROM TO +------------+-----+----+ @########## @## @##

SPECIFIC PROBLEM MBIA PARTIAL FAULT: TOO MANY RESETS

MBIH PARTIAL FAULT: TOO MANY RESETS

68 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


SUPPLEMENTARY INFORMATION: H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz


System reaction




Cause/fault explanationAn MB alarm message with the MMN number MB210-2005 is output if the test the FEPROM detected a malfunction, i.e. the incremented checksum of the stored bytes did not correspond to the stored checksum.

The SW of units MBIH and MBIA is stored on an FEPROM of the corresponding module. Each FW/SW version in the FEPROM is protected with a checksum which is checked by each ASIC on loading the FEPROM into the SDRAM and in the routine test. If a checksum fault is detected, an older FW/SW version will be used in the FEPROM in the next startup. The routine test (internal online routine test) is started by the CP with STAGCG in low traffic periods.

Suspect hardware

The Frames (backplane, connector strip).

Check firmware version of all MB modules for compatibility




4.7 MMN:MB210-2007 - MBIH: NO CONNECTION TO SN POSSIBLE EQUIPMENT ALARM MMN:MB210-2007 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION

SPECIFIC PROBLEM MBIA PARTIAL FAULT: OLD FW LOADED

MBIH PARTIAL FAULT: OLD FW LOADED

a: M:MBDH on both sides, all M:MBDHs on the system side with the suspect MBDH

b: M:MBDA on both sides, all M:MBDAs on the system side with the suspect MBDA

A30828-Y1187-N510-2-7620

69


Id:0900d805806b9166

SPECIFIC PROBLEM: MBIH: NO CONNECTION TO SN POSSIBLE MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#

CONFIGURATION: UNIT FROM TO +------------+-----+----+ @########## @## @## SUPPLEMENTARY INFORMATION: H’aabbcccc zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz


• bb: Classification of the message

• cccc: Processor number of the unit concerned 4.1 MBD - IO processor numbers • z...z: These bytes are not occupied. Entries not equal to 0 are also not relevant.

System reaction




Cause/fault explanationIf an MBIH is reset spontaneously, i.e. not because of configurations, FA:MB receives the MBDREADY message from the MBD. If this is also an SGC channel, FA:MB requests from FA:SN that the available MCH be resynchronized for the secondary SN units. (An SN-MCH is available if the secondary SN unit is ACT or STB and FA:SN has not yet initiated a configuration for this unit.)The acknowledgment of FA:SN to FA:MB gives information about whether all, some or none of the available MCHs of a logical MBU:SGC were able to be synchronized.If no available MCHs can be synchronized, the FA:MB takes the MBIH concerned out of service conditionally and an alarm message with the MMN number MB210-2007 is output. If there is no redundancy, the configura-tion is rejected and an ISTART1 initiated. If the last ISTART ran less than 45 minutes before, unconditional deactivation is initiated to prevent the occurrence of rolling recov-eries.

Because each SGC in the SN is connected via an MCH to the MBU:SGC, there are a maximum of three MCHs per logical MBU:SGC.

The MBU unit only exists as a logical unit in the MBD. Usually, an MBDH module repre-sents 4 MBULs and 2 MBUSs. Therefore, there are a maximum of 6 MCHs for the SGCs of the SN. In DE51 only 2 MBULs and 1 MBUS are supported.

0F Call processing periphery (EAVT)

0B Last message MBU READY on spontaneous resetting of the logic unit MBU:SGC on MBIH

70 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


In SND the S1 channels are connected to the associated SNMUX and the S3 channels via module MBDCG to the MATC of SNMAT. In nodes without SNMAT the S3 channels are connected via MBDCG to SNMUX-0, which acts as switch.

In SND in B-Mode for the S1 and S3 channels are connected to the associated MUXC which contains the SGC for one SSG and two TSG. In SND in B-Mode TSG and SSG exist as logical units on SNMUX. One SNMUX comprises 2 TSG and 1 SSG. The TSG and SSG firmware is simulated on module MUXC with the restrictions that cross con-nection between TSG and SSG of different system sides is not provided.

Main suspect areasM:MBDH, cable between the MBDH and the SGC in SN

for SND with SNMAT: S3 channels, module MBDCG and cable between MBDCG and MATC,

S1 channels, module MBDH and cable between MBDH and MUXC

for SND in B-Mode, module MUXC and appropriate cable between MBDH and MUXC

Further suspect modules and cables

– If only one SN unit is connected to the SGC interface concerned on the MBDH, e.g. minimum capacity stage or SN(63LTG), modules LIM and SGC (SNA) or SGCB (SNB)) are also suspect in the connected SN unit.

– Frames (backplane, connector strip) in MB and SN with the suspect unit.


Diagram of frames - module side, backplane and cabling:Construction, Frames F:MB/CCG or Construction Frames F:IOPMBD and Construction, Frames F:SN.

Display of module face plates and explanation of the LEDs: Construction, Modules MB andConstruction, Modules SN.

HDLC interface connection to SND

D Data

SGC5SGC4SGC3SGC2SGC1SGC0SGC interface

LTG1...63

LTG64...126

LTG127...189

LTG190...252

LTG interfaces: LTG-IF0...LTG-IF3

SND

D, TFMB

D, TFMB

D, TFMB

D, TFMB

3 3 3 3

SNMUX-x *1 SNMUX-y *2

MUXC-x *1 MUXC-y *2

SNMUX-x *1

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TGND

D, TGND

D, TGND

D, TGND

D, TGND

D, TGND MBDCG

SNMAT

MATC-1

MBDH

SNMUX-y *2

LILE 0/LILD 0

LILE 0/LILD 4

LILE 0/LILD 4

LILE 0/LILD 0

A30828-Y1187-N510-2-7620

71


Id:0900d805806b9166

T ClockFMB Frame Mark BitGND Ground*1 x= 0, 2, 4, 6, 8, 10, 12, 14*2 y= 1, 3, 5, 7, 9, 11, 13, 15

Figure 7 HDLC interface MBIH <--> SND

In MBD MBU:LTG and MBU:SGC exist as logical units on the module MBDH. A module MBDH usually comprises 4 MBU:LTG and 2 MBU:SGC.

*) In a netnode without SNMAT: SNMUX-0 acts as switch

HDLC interface (connection to the SNA or the SNB)

D DataT ClockFMB Frame Mark Bit

ASIC No. 0 1 2 4 5 6

SGC IF No. 0 1 2 3 4 5

on connected to

MBDH in

MBIH0

MBIH1

MBIH2

MBIH3

MBIH4

MBIH5

MBIH6

MBIH7

MUXC in

SNMUX0

SNMUX2

SNMUX4

SNMUX6

SNMUX8

SNMUX10

SNMUX12

SNMUX14

MATC

*)

MUXC

SNMUX0

SNMUX2

SNMUX4

SNMUX6

SNMUX8

SNMUX10

SNMUX12

SNMUX14

MUXC

SNMUX1

SNMUX3

SNMUX5

SNMUX7

SNMUX9

SNMUX11

SNMUX13

SNMUX15

MATC

*)

MUXC

SNMUX1

SNMUX3

SNMUX5

SNMUX7

SNMUX9

SNMUX11

SNMUX13

SNMUX15


TSGSSG TSGSSGTSGTSG

SGC


SGC interface

LTG1...63

LTG64...126

LTG127...189

LTG190...252

LTG interfaces: LTG-IF0...LTGIF3

SNA, SNB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TGND

D, TGND

D, TGND

D, TGND

D, TGND

D, TGND

72 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


GND Ground

Figure 8 HDLC interface MBIH <--> SNA/SNB

HDLC interface (connection to SND in B-Mode)In SNDB TSG and SSG exist as logical units on SNMUX. One SNMUX comprises of 2 TSG and 1 SSG.


Figure 9 HDLC interface MBIH <--> SND in B-Mode for DE52

4.8 MMN:MB212-2001 - ATMB FAILURE EQUIPMENT ALARM MMN:MB212-2001 ALARM PRIORITY: EQUIPMENT MALFUNCTION PROBABLE CAUSE: @################################################# SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @####

ASIC No. 0 1 2 4 5 6

SGC IF No. 0 1 2 3 4 5

Connected to: TSG SSG TSG TSG SSG TSG

Table 15 Allocation of the SGC IF interfaces to the ASIC on M:MBDH

ASIC No. 0 1 2 4 5 6

SGC IF No. 0 1 2 3 4 5

connected with: TSG SSG TSG TSG SSG TSG



SGC interface

LTG1...63

LTG64...126

LTG127...189

LTG190...252

LTG interfaces LTG-IF0...LTGIF3

SNDB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

3 3 3 3

LILD0 LILD4 LILD0 LILD4

SNMUX SNMUX

MUXC-0 MUXC-y

SNMUX

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TFMB

D, TGND

D, TGND

D, TGND

D, TGND

D, TGND

D, TGND

MBDH

SNMUX

TSG SSG TSG TSG SSG TSG

D, TFMB

TSG-0 TSG-1 TSG-2 TSG-3

LILE0 or LILE1 or

A30828-Y1187-N510-2-7620

73


Id:0900d805806b9166

ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#

CONFIGURATION: UNIT FROM TO +------------+-----+----+ @########## @## @## SUPPLEMENTARY INFORMATION: H’aabbcczz ddddzzzz eezzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz

Interpretation of the supplementary information byte • aa: Origin of the message

• bb: Detected malfunction

• cc: Reporting software unit

• dddd: Processor number of the unit concerned 4.1 MBD - IO processor numbers • ee: Classification of fault detection


System reaction

– The corresponding MBIA is configured to UNA if the other system side is ACT. If there is no redundancy, ISTART1 is initiated for the MB side provided that ISTART was not run during the previous 45 minutes. If running ISTART is not allowed, the MBIA remains ACT.

– The malfunction will be displayed under object MB as a critical alarm or, if there is no redundancy, as a major alarm.

– The log will be stored in the history file and entered into the alarm file (AM.ALARM).

Fault handlingThe ATM bridge maintenance in the CP evaluates message transfer statistics collected in the MBDA to detect ATM 230 ASIC malfunctions, that are not detected by the super-vision of the MBDA module. These hardware faults are only noticeable when the ATM-Bridges are in operation. Confirmed errors are reported to the Fault Analysis MB (FA:MB) which initiates switchover to the redundant unit (if possible) and issues an HW alarm for the faulty MBD module. The MBIA is configured to UNA. An alarm message with the MMN number MB212-2001 is output.

Fault verification and fault clearanceThe diagnosis routine cannot in every case verify these hardware faults. For verification of the fault the traffic has to be routed via the affected ATM- Bridges again. A detection time of 15 minutes has to be taken into account. First the faulty (suspect) MBIA has to be configured to ACT. After activation of the MBDA its ATM-Bridges are in cold standby. In order to switch the traffic to the affected ATM-Bridges the redundant MBIA has to be configured to MBL.. Then it has to be configured immediately back to ACT. After verifi-

0F SGMES (safeguarding monitor)

39 MBDA Error

93 ATM Bridge Maintenance

08 MBDA-ATMB failure

74 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


cation of the fault the module has to be replaced. Check the ATM-Bridges of the replace-ment module with the same routine: side x = suspect MBIA, side y = redundant MBIA

CONF MBIA:MB=x,MBIA=mbia,OST=ACT;

STAT ATMB;

CONF MBIA:MB=y,MBIA=mbia,OST=MBL;

CONF MBIA:MB=y,MBIA=mbia,OST=ACT;

STAT ATMB;

Command STAT ATMB; interrogates the operating states of the ATM-Bridges.

In case the fault could not be verified, leave the suspect ATM-Bridges in operation. If sportadic faults occur again, check the interface to the SSNC, the SSNC modules and cabling (see also 4.9 MMN:MB214-2001 - MBIA STATISTIC FAULT)


Diagram of frames - module side, backplane and cabling: Construction, Frames F:MB/CCG or Construction, Frames F:IOPMBD and F:SSNC.

Display of module face plates and explanation of the LEDs: Construction, Modules MB and SSNC.

4.9 MMN:MB214-2001 - MBIA STATISTIC FAULT EQUIPMENT ALARM MMN:MB214-2001 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#

CONFIGURATION: UNIT FROM TO +------------+-----+----+ @########## @## @## SUPPLEMENTARY INFORMATION: H’aabbcczz zzzzdddd eezzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz

Interpretation of the supplementary information byte • aa: Origin of the message




SPECIFIC PROBLEM MBIA STATISTIC FAULT CAUSED BY OTHER UNIT


39 MBDA Error

93 ATM Bridge Maintenance

A30828-Y1187-N510-2-7620

75


Id:0900d805806b9166


System reaction

– An alarm message is output for the corresponding MBIA. The MBIA remains ACT since the fault is located outside of module MBDA. The error is caused by other units

– The malfunction is displayed under object MB as a critical alarm.– The log is stored in the history file and entered into the alarm file (AM.ALARM).

Cause/fault explanationCall and data loss caused by hardware failures result in list overflows in the MBDA firm-ware. These malfunctions are registered by means of a statistical counter for the acitve ATMBU on module MBDA. The ATM bridge maintenance in the CP evaluates message transfer statistics collected in the active MBDA. The faults are only noticeable when the ATM-Bridges are in operation. Confirmed errors are reported to the Fault Analysis MB (FA:MB). If the statistics showes extremely asymmetric message flow in transfer to SSNC and receive from SSNC direction, the error cause is located outside the MBDA.

The errors are caused by problems on the long way from SLT to LTG via ASN/AMX, ATMBM, or by wrong cabling between AMX and ATMB.

In case of continuous asymetric load FA:MB only alarms the MBDA with a critical alarm without deactivating the MBIA. An alarm message with the MMN number MB214-2001 for the MBIA is output.

Suspect HardwareSSNC modules and cables: Check the system for unrepaired alarmed SSNC units. These faults have to be cleared first. The way must be traced back from SLT to LTG via ASN/AMX, ATMBM. Check cabling and modules

For cabling see the exchange specific cable laying list or the manual Construction, for SSNC fault clearande refer to MMN:SSNC and NM:SSNC.

After successful SSNC fault clearance reset the MB alarm by configuration of the faulty MBIA to MBL and back to ACT..

After configuration of the faulty MBIA, the ATMBU of the redundant MBIA are active. In case the fault has not been cleared successfully, i.e. the fault still persists, an alarm message with the MMN number MB214-2001 for the redundant MBIA will be output. The detection time is about 15 minutes.


Diagram of frames - module side, backplane and cabling: Construction, Frames F:MB/CCG or Construction, Frames F:IOPMBD and F:SSNC.

Display of module face plates and explanation of the LEDs: Construction, Modules MB and SSNC.

09 ATMB failure caused by other unit

76 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


Optical interface (connection to the AMX via FOTX)

Figure 10 Optical interface MBD <--> SCB

Figure 11 Optical interface MBD <--> SCE

FOTX 01

FOTX 00

FOTX 20

FOTX 21

MBDA0

D2

Port 0

Port1

Port 0

Port 0

C5

C3

C1ATM

Bridge2

ATMBridge3

FOTX 11

FOTX 10

FOTX 30

FOTX 31

MBDA0

D2

Port 0

Port1

Port 0

Port1

C5

C3

C1ATM

Bridge2

ATMBridge3

MBD0

MBD1

FOTX 10

FOTX 00

FOTX 20

FOTX 30

149C3

149D2

149C5

149C1

PortYB_23

PortYB_19

PortYB_21

PortYB_17

AMXE

FOTX 11

FOTX 01

FOTX 21

FOTX 31

211C3

211D2

211C5

211C1

PortYB_23

PortYB_19

PortYB_21

PortYB_17

AMXE

SCB-Shelf AMX0

AMX1

FOTX 01

FOTX 00

FOTX 20

FOTX 21

MBDAx

D2

Port 0

Port1

Port 0

Port 1

C5

C3

C1



FOTX 11

FOTX 10

FOTX 30

FOTX 31

MBDAx

D2

Port 0

Port1

Port 0

Port 1

C5

C3

C1



MBD0

MBD1

FOTX 10

FOTX 00

FOTX 20

FOTX 30

221C3

221D2

221C5

221C1

PortYB_23

PortYB_19

PortYB_21

PortYB_17

AMXE

FOTX 11

FOTX 01

FOTX 21

FOTX 31

261C3

261D2

261C5

261C1

PortYB_23

PortYB_19

PortYB_21

PortYB_17

AMXE

SCE-Shelf

AMX0

AMX1

A30828-Y1187-N510-2-7620

77


Id:0900d805806b9166

4.10 MMN:MB215-2001 - MBIC MODULE FAILURE EQUIPMENT ALARM MMN:MB215-2001 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#







SPECIFIC PROBLEM MBIC TOTAL FAULT: MODULE FAILURE

MBIC PARTIAL FAULT: MODULE FAILURE

11 SG_FA_MB

01 MBDC

Not busy MBDC

00 ... 07 MBDH or

00 ... 04 MBDA

01 Total failure

02 Partial failure

02 RESBUS fault (faulty reset bus). Master BIF-ASIC has a faulty reset bus. The RESBUS routine test is initiated by command STAGCG. Via the RESBUS, an interrupt is initiated in all the ASICs in the READY mode (incl. both MBDIFs) which is acknowledged with RESBUS_RDY. If an acknowledgment fails to appear, the interrupt is repeated after 10 s. If RESBUS_RDY fails to appear twice on the MBDIF master, a RESBUS_ERR is generated immediately. A fault cannot be confirmed by resetting. The master BIF-ASIC identifies its own status as faulty.

78 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166



System reaction

– The corresponding MB side is configured to UNA if the other system side is ACT. If there is no redundancy, the MB side remains in ACT in the case of a partial fault. In the case of total failure ISTART1 is initiated for the MB side provided that ISTART was not run during the previous 45 minutes. If running ISTART is not allowed, the side is deactivated unconditionally.



Fault handlingAn MB alarm message with the MMN number MB215-2001 is output if the internal on-line routine test of the ASIC of the module concerned has independently detected a hardware malfunction. The FA:MB initiates partial or total failure handling depending on whether or not one or all the ASICs of a module are concerned.

Main suspect moduleM:MBDC

Further suspect areasThe Frames (backplane, connector strip).

03 ASIC does not send READY: The RESBUS is a unidirectional bus in which case module MBDC is the sender. Acknowledgments for a RESET request are sent to the MBDC via the IBUS. If this READY acknowledgment fails to appear, this is detected by the MBDC. Faults which are reported should be confirmed faults. At least one ASIC must be reset and after the RESET the error message must be output again. If the READY acknowledgment fails to appear after the RESET requests, the NO_RESET_RESP error message is generated.

04 FEPROM fault: Each FW/SW version in FEPROM is protected by a checksum which is checked when it is loaded from the FEPROM into the SDRAM and in the routine test of each ASIC.

05 Parity error (startup after RESET unsuccessful). The data transfer via the IOP:MB interface is protected by means of parity (even). If the MBDC detects a parity error, the ACK2 acknowledgment signal is not given. Should IOP:MB detect a parity error, this is forwarded to the CP software.

06 SDRAM fault, startup after RESET unsuccessful.

07 Memory protection violation. The SDRAM controller supervises the accesses to the SDRAM. A fault was detected on testing the SDRAM, i.e. either the writ-abilty or the readability of the memory is not guaranteed. (Parity error: Incor-rect address, messages with invalid MBU number, MCH message length incorrect, JC2 unknown)

08 Memory shortage

0B BIST fault (result message of the BIST). Fault after ASIC startup. BIST tests the entire logic of the ASIC incl. the RAM and the RISC core.

A30828-Y1187-N510-2-7620

79


Id:0900d805806b9166




4.11 MMN:MB215-2002 - MBIC IBUS FAILURE EQUIPMENT ALARM MMN:MB215-2002 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#


Interpretation of the supplementary information bytes • aa = 1: Origin of message FA:MB • bb = 0: Module type MBDC • cc = 0: Module number (together with the byte bb module type) • dd: Classification of the malfunction detected

• ee = 0A: Detailed fault information IBUS fault • z...z: These bytes are not occupied. Entries not equal to 0 are also not relevant.

System reaction

– The corresponding MB side is configured to UNA if the other system side is ACT. If there is no redundancy, the MB side remains ACT in the case of a partial fault. In the case of total failure ISTART1 is initiated for the MB side provided that ISTART was not run during the previous 45 minutes. If running ISTART is not allowed, the side is deactivated unconditionally.



Cause/fault explanationAn MB alarm message with the MMN number MB215-2002 is output if the internal on-line routine test of the module concerned has independently detected a malfunction in

SPECIFIC PROBLEM MBIC TOTAL FAULT: IBUS FAILURE

MBIC PARTIAL FAULT: IBUS FAULT

01 Total failure

02 Partial failure

80 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


the internal bus system IBUS. If an ASIC reports an IBUS fault, this fault must be con-firmed, i.e. it must be possible to find it again after a reset.

On modules MBDC, each ASIC has an IBUS interface with a TX and an RX pin as well as an IBUS switch. The IBUS connection between the OUT and IN switch of the same module is wired via the backplane.

Test of the IBUS: For this, a test loop runs from the IBUS output on the corresponding IBUS input via the backplane of the frames. The IBUS switch can be tested via this con-nection.

If an IBUS sender does not receive an acknowledgment within the timeout period (approximately 100 ms) or if the test pattern is corrupted (data fault), the MBDC sends a message to the FA:MB.

Depending on whether or not one or all the ASICs of a module are concerned, the FA:MB initiates partial or total failure management.

Main suspect module MBDC

Further suspect modulesModule MBDCG, the Frames (backplane, connector strip).




4.12 MMN:MB215-2004 - MBIC TOO MANY RESETS EQUIPMENT ALARM MMN:MB215-2004 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: MBIC PARTIAL FAULT: TOO MANY RESETS MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#



System reaction

– The corresponding MB side is configured to UNA if the partner side is ACT. If there is no redundancy, the MB side remains ACT.

A30828-Y1187-N510-2-7620

81


Id:0900d805806b9166



Cause/fault explanationIf an MBIC resets spontaneously, i.e. not because of configurations, FA:MB receives an MBDREADY message. FA:MB then reloads the MBD and the bridge software data. If reloading the data was unsuccessful, total failure management for the MB side is intro-duced. A statistics counter is run for the MBIC: Each spontaneously arriving MBDREADY message increments the statistics counter and the statistics counter is reduced by 1 each hour. An MB alarm message with the MMN number MB215-2004 is output if the number of MBDREADY messages from MBIC exceed 5.



Diagram of the Frames and wiring: Construction, Frames F:MB/CCG and Construction, Frames F:IOPMBD.


4.13 MMN:MB215-2005 - MBIC OLD FW LOADED EQUIPMENT ALARM MMN:MB215-2005 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: MBIC PARTIAL FAULT: OLD FW LOADED MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#



System reaction

– The corresponding MB unit is configured to UNA if the partner unit is ACT. If there is no redundancy, the MB unit remains in ACT.



82 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


Cause/fault explanationAn MB alarm message with the MMN number MB215-2005 is output if the internal on-line routine test of the module concerned has independently detected a malfunction in the FEPROM. In order to prevent the MBD from starting this test in heavy-traffic periods, the routine tests are started by the CP with STAGCG. A fault was identified on testing the FEPROM on the module, i.e. the incremented checksum of the stored bytes did not correspond to the stored checksum.

The SW of unit MBIC is stored on an FEPROM of M:MBDC. Each FW/SW version in the FEPROM is protected with a checksum which is checked by each ASIC on loading the FEPROM into the SDRAM and in the routine test. If a checksum fault is detected, an older FW/SW version will be used in the FEPROM in the next startup. The CP is informed that the current FW/SW version could not be loaded.





4.14 MMN:MB215-2006 - MBIC NO LOOP RESPONSE EQUIPMENT ALARM MMN:MB215-2006 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#

CONFIGURATION: UNIT FROM TO +------------+-----+----+ @########## @## @## SUPPLEMENTARY INFORMATION: H’aabbcczz zzzzdddd eeffgggg gggggggg H’gggggggg gggggggg zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz




SPECIFIC PROBLEM MBIC TOTAL FAULT: NO LOOP RESPONSE

MBIC PARTIAL FAULT: NO LOOP RESPONSE


2D SG_MBD_FAULT

A30828-Y1187-N510-2-7620

83


Id:0900d805806b9166


• ff: IOPSET Number of faulty ports • gg...gg: IOPLIST List of IOPs (IOP:MB number) which are connected to the faulty

ports • z...z: These bytes are not occupied. Entries not equal to 0 are also not relevant.

System reaction

– The corresponding MB side is configured to UNA if the other system side is ACT. If there is no redundancy, the MB side remains in the ACT in the case of a partial fault. In the case of total failure ISTART1 is initiated for the MB side provided that ISTART was not run during the previous 45 minutes. If running ISTART is not allowed, the side is deactivated unconditionally.



DescriptionThe LOOP command is output and evaluated by routine test MB. Routine test MB forms part of the safeguarding software in the CP and guarantees the correct functioning of the MB.

The routine test sends the LOOP message to all three addresses of an IOP:MBs provided that these are in operation. The command is sent once per IOP or address. This can be attributed to the variable allocation of MBU to IOP:MB. MBIC answers each LOOP with RELOOP. If the RELOOP messages fail to appear (i.e. the test pattern is not received in the time provided) it is first checked whether or not the MBU/IOP allocation has changed. It may be owing to a configuration or fault handling. If this is the case, the loop test is ended and fault handling is not initiated. Otherwise, the LOOPs are sent again. If the RELOOPs fail to appear after this repeat, the fault will be delimited. The LOOP messages are reflected in MBIC. If RELOOP fails to appear, it is concluded that there is a fault in the MBIC firmware. All faults are reported with MBDFAULT to the FA:MB.

Fault handlingFA:MB resorts to the following measures, depending on the type of fault– Total MBIC failure: If the periodic LOOP test commands were output correctly to the

MBD side concerned, but if the test patterns (with the RELOOP messages) from the MBD side (i.e. from all the addresses) were not returned within a specific period (MBIC_NON_RELOOP and IOP = 0), FA:MB takes the MB side concerned out of operation, i.e. initiates the configuration to UNA. ISTART1 is initiated should there be no redundancy regarding MB, SN or CCS7. If the last ISTART ran less than 45 minutes before, an unconditional deactivation is initiated to prevent the occurrence of rolling recoveries.

0F Safeguarding software for the routine test here MB (SG-ROUT-TEST)

03 MBIC_NON_RELOOP It was repeated that a RELOOP was not received from an MBD-mbd. Byte ff and gg..gg are 0 (total failure management)

02 MBIC_NO_RELOOP no RELOOP was received from one or several addresses of an IOP:MBs (partial failure management)

84 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


– Address-specific hardware fault: If the periodic LOOP test commands were output correctly to the MBD side concerned, but the test patterns (with the RELOOP mes-sages) were not returned within a specific period by one or more IOP addresses (MBIC_NO_RELOOP and IOP not equal to 0), FA:MB takes the MB side concerned out of operation, i.e. initiates the configuration to UNA. If there is no redundancy regarding the MB or the SN or the CCS7 traffic is interrupted, i.e. the MBD side cannot be configured, FA:MB reroutes the lists to other IOPs. ISTART1 is initiated should no IOP master be active and the last ISTART took place more than 45 minutes before. Otherwise, the FA:MB initiates an unconditional deactivation to prevent the occurrence of rolling recoveries.

Remarks/notesAfter an ISTARTx or NSTART3 recovery, the first LOOP command is output only 5 minutes after the process start (system stabilizing).

The LOOP command is output periodically every 20 seconds. If the RELOOP message fails to appear within 6 seconds, the LOOP command is repeated and there is a 3s waiting period for RELOOP. If RELOOP also fails to appear here, the MB side con-cerned is switched off.

The MBU unit only exists as a logical unit in MBD. An MBDH module usually represents 4 MBULs and 2 MBUSs. Therefore, in the CMY there are 6 output lists for peripheral units connected to an active MBDH. In the CMY, output lists are not allocated to inactive MBDHs which are therefore also not tested. Maintenance messages to an MBDH, all the messages and the MBDA and the MBDC are entered into the maintenance output list.


Further suspect modulesFrames (backplane, connector strip) with the MBD side concerned and with the appro-priate IOP:MB




4.15 MMN:MB215-2007 - MUTILATED LOOP RESPONSE EQUIPMENT ALARM MMN:MB215-2007 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#

a: M:MBDC

b: M:MBDC, cable between the MBDC and the IOP:MB concerned.

A30828-Y1187-N510-2-7620

85


Id:0900d805806b9166





• dddd: Processor number of the unit concerned 4.1 MBD - IO processor numbers • ee: Classification of the fault detection



System reaction

– The corresponding MB side is configured to UNA if the other system side is ACT. If there is no redundancy, the MB side remains in ACT in the case of a partial fault. In the case of total failure ISTART1 is initiated for the MB side provided that ISTART did not run during the previous 45 minutes. If running ISTART is not allowed, the side is deactivated unconditionally.



DescriptionThe LOOP command is output and evaluated by routine test MB. Routine test MB forms part of the safeguarding software in the CP and guarantees correct functioning of the MB.

The routine test sends the LOOP message to all three addresses of an IOP:MBs provided that these are in operation. The command is sent once per IOP or address. This can be attributed to the variable allocation of MBU to IOP:MB. MBIC answers each LOOP with RELOOP. The RELOOP pattern is compared with the originally output LOOP pattern. The LOOP command is repeated if RELOOP receives a corrupted or incomplete pattern. If routine test MB also detects a corrupted test pattern in the repeat


2D SG_MBD_FAULT


05 ALL_RELOOP DEF All RELOOPs include repeated incorrect bit patterns. Byte ff and gg..gg are 0 (total failure management)

04 RELOOP_DEF Reloops from one or several addresses of an IOP:MB contain incorrect bit patterns. Byte ff and gg...gg have been set (partial failure management)

86 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


process, it is concluded that there is a fault in the MBIC firmware. The LOOP messages are reflected in MBIC. All faults are reported with MBDFAULT to the FA:MB.

Fault handlingFA:MB resorts to the following measures depending on the type of fault– Total failure management: If all the repeated RELOOPs contain corrupted or incom-

plete bit patterns (ALL_LOOP_DEF and IOP = 0), FA:MB takes the MB side con-cerned out of operation, i.e. initiates the configuration to UNA. ISTART1 is initiated if there is no redundancy as regards the MB, the SN or the SSNC. If the last ISTART ran less than 45 minutes before, an unconditional deactivation is initiated to prevent the occurrence of rolling recoveries.

– Partial failure management: If repeated RELOOPs contain corrupted or incomplete bit patterns from one or several IOP addresses (LOOP_DEF and IOP not equal to 0), FA:MB takes the MB side concerned out of operation, i.e. initiates the configura-tion to UNA. If there is no redundancy regarding the MB or the SN, or SSNC traffic is interrupted, i.e. the MBD side cannot be configured, FA:MB reroutes the lists to other IOPs.

Remarks/notesThe LOOP command is output periodically every 20 seconds. If the RELOOP message fails to appear within 6 seconds, the LOOP command is repeated and there is a 3 second waiting period for RELOOP. If RELOOP also fails to appear here, the MBU con-cerned is switched off.

The MBU unit only exists as a logical unit in MBD. An MBDH module usually represents 4 MBULs and 2 MBUSs. Therefore, in the CMY there are 6 output lists for peripheral units connected to an active MBDH. In the CMY, output lists are not allocated to inactive MBDHs and are therefore also not tested. Maintenance messages to an MBDH, all the messages and the MBDA and the MBDC are entered into the maintenance output list.

After an ISTARTx or NSTART3 recovery, the first LOOP command is output only 5 minutes after the process start (system stabilizing).






4.16 MMN:MB215-2008 - NO IO PORT ACCESSIBLE EQUIPMENT ALARM MMN:MB215-2008

a: M:MBDC


A30828-Y1187-N510-2-7620

87


Id:0900d805806b9166

ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#






• ff: Irrelevant. MBIC can no longer be reached. Impossible to reroute the lists • gg...gg: Irrelevant. MBIC can no longer be reached. Impossible to reroute the lists • z...z: These bytes are not occupied. Entries not equal to 0 are also not relevant.

System reaction

– It is imperative that the corresponding MB side be switched off, i.e. configured to UNA.

– The malfunction is indicated under object MB as a critical alarm.– The log is stored in the history file and entered into the alarm file (AM.ALARM).

Description/fault handlingThe ASIC output lists on module MBDC are supervised in MBD. If an output list of this type that is not empty is not read in a specified period, the control deletes the contents of the list and resets the appropriate ASIC. FA either receives a ready or an error message. The MBU:LTG and MBU:SGC output lists (MBDC lists) in the CMY are super-vised by IOCP. If IOCP identifies that an output list that is not empty is not read for several seconds, the list is taken to be stuck. IOCP IOMBDEF reports to the routine test for each unit with a stuck list. The routine test tries to record the MBUS concerned with IOMBUASS into the scan cycle. Because the command includes the complete alloca-tion, IOCP, PIO and IOP can synchronize their allocation with safeguarding. Three seconds after IOMBUASS was sent, the routine test sends IOCHECK to determine whether or not the list still exists. Fault handling ends if messages were read in the meantime.


2D SG_MBD_FAULT


00 MBIC_TOT_FAIL Stuck output lists are reported for more than three IOP:MBs of a side. The IOP:MB test shows no error byte ff and gg..gg are 0

88 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


On the other hand, the corresponding IOPs are tested. If there is no redundant IOP:MB, FA receives the IOPOFF message and then reroutes the lists from this IOP:MB to the remaining IOP:MB pairs. If the IOP:MBs cannot be reached, i.e. the lists cannot be rerouted, it is imperative that the MB side be switched off and an alarm message with the number MMN:MB215-2008 output.


The LOOP command is output periodically every 20 seconds. If the RELOOP message fails to appear within 6 seconds, the LOOP command is repeated and there is a 3 second waiting period for RELOOP. If RELOOP also fails to appear here, the MBU con-cerned is switched off.







4.17 MMN:MB215-2009 - IOPORT FAULTY EQUIPMENT ALARM MMN:MB215-2009 ALARM PRIORITY: EQUIPMENT MALFUNCTION PROBABLE CAUSE: @################################################# SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#

CONFIGURATION: UNIT FROM TO +------------+-----+----+ @########## @## @## SUPPLEMENTARY INFORMATION: H’aabbcczz zzzzdddd eeffgggg gggggggg H’gggggggg gggggggg zzzzzzzz zzzzzzzz

M:MBDC

Cable between the MBDC and the IOP:MB concerned

IOP:MB concerned

A30828-Y1187-N510-2-7620

89


Id:0900d805806b9166

H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz







System reaction

– The corresponding MB side is configured to UNA if the other system side is in ACT. If there is no redundancy, the MB side remains in the ACT in the case of a partial fault. In the case of total failure ISTART1 is initiated for the MB side provided that ISTART did not run during the previous 45 minutes. If running ISTART is not allowed, the side must be deactivated unconditionally.



Description/fault handlingThe ASIC output lists on module MBDC are supervised in MBD. If such an output list that is not empty is not read in a specified period, the control deletes the contents of the list and resets the appropriate ASIC. FA either receives a ready or an error message. The MBU:LTG and MBU:SGC output lists (MBDC lists) in the CMY are supervised by IOCP. If IOCP identifies that an output list that is not empty is not read for several seconds, the list is taken to be stuck. IOCP IOMBDEF reports to the routine test for each unit with a stuck list. The routine test tries to record the MBUS concerned with IOMBUASS into the scan cycle. Because the command includes the complete alloca-tion, IOCP, PIO and IOP can synchronize their allocation with safeguarding. Three seconds after IOMBUASS was sent, the routine test sends IOCHECK to determine whether or not the list still exists. fault handling ends if messages were read in the mean-time.


2D SG_MBD_FAULT


00 MBIC_TOT_FAIL: Stuck output lists are reported for more than three IOP:MBs of a side. The IOP:MB test shows no error byte ff and gg..gg are 0

01 MBIC_PORT_FAIL: Stuck output lists are reported for an IOP:MB of a side. The IOP:MB test does not show faults. MBIC port-specific hardware faults or software errors. Byte ff and gg...gg have been set (partial failure handling)

90 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


On the other hand, the corresponding IOPs are tested. If there is no redundant IOP:MB, FA receives the IOPOFF message and then reroutes the lists from this IOP:MB to the remaining IOP:MB pairs. If there is redundancy, the lists are allocated to the redundant IOP without the assistance of safeguarding. Another test is performed if there is no self-test error or at least one of the IOP:MB pairs is available. (IOCHECK, IOMBDEF). If only this IOP reports stuck output lists, the connection is considered to be faulty (connection includes: Interface hardware on MBDC and IOP:MB and the cable connection). If there is no redundancy, the malfunction is logged and a critical alarm reported. The MB side is not configured to UNA.


The LOOP command is output periodically every 20 seconds. If the RELOOP message fails to appear within 6 seconds, the LOOP command is repeated and there is a 3 second waiting period for RELOO. If RELOOP also fails to appear here, the MBU con-cerned is switched off.



Further suspect areasFrames (backplane, connector strip) with the MBD side concerned and with the appro-priate IOP:MB




4.18 MMN:MB PR:MB - EQUIPMENT ALARM DEFAULT EQUIPMENT ALARM MMN:MB PR:MB ORIGINAL ALARM MESSAGE WAS LOST. ALARM PRIORITY: @####### PROBABLE CAUSE: PROCESSOR PROBLEM SPECIFIC PROBLEM: NOT AVAILABLE MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=yyyy#### @#######@@##### UNITNO=mb-mbix

a: M:MBDC


A30828-Y1187-N510-2-7620

91


Id:0900d805806b9166

Explanations about the output mask

This alternative message is output if an MB unit or side could not be activated during the preceding system run (or new start) because of a malfunction and the actual alarm message has been lost. Because there is no more detailed information, the malfunction of the MB must be reanalyzed. The MMN number refers to the PR:MB procedure. In this procedure, the entire MB is checked by using diagnosis. Procedure PR:MB in MMN:MBD supplies the correct reference to further fault clearance for each fault.

4.19 MMN:MB225-2001: MBICG PARTIAL FAULT: MODULE FAILUREFor display of output mask and interpretation of byte-coded information, refer to 4.23 Interpretation of alarm mask for MBICG failures

System reaction

– The fault is a conditional fault. The corresponding MB side is configured to UNA if the partner side is ACT. If there is no redundancy, the MB side remains ACT.



Fault handlingMessage MB_MEGCG is sent on the IOP channel for maintenance commands either as a spontaneous MBDCG alarm (from the MBIC) or as an answer to the STAGCG. If the message was sent spontaneously once already, the current fault state of M:MBDCG is sent via the maintenance channel to the CP by means of MB_MEGCG after each LOOP command. Depending on the contents of the MB_MEGCG message, FA:MB initiates total, cross link or partial fault handling.

An MBD alarm message with MMN:MB225-2001 is output if:a) The routine test identifies a fault in an 8-MHz PLL supervisory circuitb) 50-MHz alarm of the MBDCG master module is reported (flags

MBDCG_MBD_SyncFail or MBDCG_MBD_Fmax for the master module are in the status register (system side 0 set)

c) 50-MHz alarm (MBDCG_MBD_Fmax)d) an I2C bus fault is detected.

a) Routine testSafeguarding which is decisive for the MBDCG is implemented by the HW on the module, the MBDC software and the CP software. The test circuits on the MBDCG only become active in case of faults. Therefore routine test is necessary. The routine test starts with the CG_8M-TestSynchFail command. The module is then in the routine test

xxxxxxxx MINOR = Minor alarm

MAJOR = Major alarm

CRITICAL = Critical alarm

yyyy MB, MBIH, MBIA

mb 0 (MB-0) or 1 (MB-1)

mbix 0...7 (number of the MB unit)

92 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


PLL alarm mode which is ended after 200 ms at the latest by expiry of the watchdog timer (timeout). If there is a positive acknowledgment, the test circuit reacts and the error message is generated once only and sent to the MBDC. If the MBDC does not receive an error message, but SG_8M_Normal, the module must be replaced because the test circuit is faulty. If the MBDC receives the error message twice, this means that an HW fault occurred immediately after the test and was identified by PLL supervision.

b) Unlatch detection MBD system clock PLL (PLL alarm)A hardware fault implies that the PLL is asynchronous with the reference. Each detected fault sets the CG_50M_SyncFail flag. Should the reference signal be detected again, the flag is reset again after reading by the MBDC. If the frequency increases by more than 10%, the overfrequency detection becomes active. (see point c)

The PLL is supervised with a test circuit which can be faulty on its part. A faulty test circuit can lead to a master whose frequency deviates strongly from 49.152 MHz. This leads to faulty IBUS connections (I2C bus fault). There is a fault on the MBDCG if the module is master. If the module is in slave operation, the reference i.e. the cross signal can be distorted by the redundant MBDCG to such an extent that reference supervision does not react although the PLL no longer functions correctly.

c) Frequency alarm: Overfrequency detection MBD system clockOn the MBDCGA, a test circuit is installed which switches off the hardware outputs if the MBD clock frequencies are too high (see characteristic values MBD system clock). Too high means that the dissipated power of the ASICs increases too much on the other modules and these modules can be damaged. Fault handling is in 3 phases:

Changing from slave to slave disabled to master (provided that the PLL was in this mode). This excludes fault causes in the master module area.

If the problem could not be solved after 1 s or should the module not be in slave opera-tion, the PLL regulation is switched off and the VCO is set to minimum frequency (red and green LEDs illuminate).

Changeover to the MBD clock off occurs in the third phase and the system clock outputs are switched off (red LED illuminates, green LED does not illuminate). This mode can only be ended on site because the MBDC can no longer send commands for lack of clocks.

Flag CG_50M_Fmax is entered into the status register.

Checksum test The software which is stored in the FEPROM and reloaded at each power-on reset is safeguarded via checksums. The boot manager detects the correctness of the check-sums. The boot is disconnected for a fault and all the outputs of the FPGA remain high. This means that the module sends no output clocks. In contrast to other MBD modules, only one single version is stored in the FEPROM. Therefore, it is impossible to go back to a previous version. The red LED is on during loading (400 ms) and after a checksum error and the green LED off.

d) Routine testing of I2C busConnection of the M:BDCG to the MBDC (I2C bus) is tested by the MBDC with a test command which is answered with a status bit.

A30828-Y1187-N510-2-7620

93


Id:0900d805806b9166

Incomplete message on I2C interfaceAll I2C transmissions are controlled by the MBDC. Should the master be interrupted by a reset for example, a timeout is generated after 10 ms and the MBDCG again assumes its normal status. No LED reaction, Flags CG_50M_ I2CFail and CG_8M_I2CFail is set in the status register.

Remarks/notesModule MBDCG is controlled by the MBDC and does not have its own controller. There-fore, statistics about faults on the MBDCG are processed only on the MBDC. Faults on the interface to the SN must be detected on the MBDH. The MBDCG does not undertake any safeguarding supervision of this interface.

Communication with the CP software is used to report faults of the associated CCG or its own HW faults for fault handling and diagnosis.

RESET logicPower-up reset: Button on the front panel

Software reset via the MBDC: The effect depends on the status of the module:

If the module issues a system clock, only those circuit parts which do not directly inter-vene in the EWSD system clock-PLL are switched off (master/slave control, I2C inter-face). Clock distribution is not interrupted, but other functions are interrupted briefly, especially IBUS connections.

Should the outputs be in the blocked mode (blocked), the PLL can be reset. The software reset in this mode leads directly to a power-up reset and initial program loading of the FPGA. Besides module replacement and the reset button, this is the only possi-bility of exiting the blocked mode. Distribution of the MBD master clock and the IBUS connection are interrupted for approximately 1 s.

Main suspect moduleM:MBDCG

Further suspect areas

– The master CCG (= the CCG which is in ACT ).– The clock supply cables between the CCG and the M:MBDCG concerned are faulty

or have not been inserted– Frames (backplane, connector strip) with the reporting M:MBDCG and the Frames

with the master CCG.

Cross referencesDiagram of the MB and CCG Racks and the associated fuses: Construction, Racks.

Diagram of the MB and CCG Frames and wiring: Construction, Frames F:MB/CCG or Construction, Frames F:IOPMBD and Construction, Frames F:DEVCCG.

Display of module face plates and explanation of the LEDs: Construction, Modules MB and Construction, Modules CCG.

94 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


4.20 MMN:MB225-2002: MBICG XLINK FAULT: MASTER/SLAVE SYNCH FAILUREFor display of output mask and interpretation of byte-coded information, refer to 4.23 Interpretation of alarm mask for MBICG failures

System reaction

– The fault is a cross link fault. The MB side determined is configured to UNA if the partner side is ACT. If there is no redundancy, the MB side remains ACT.




An MBD alarm message with MMN:MB225-2002 is output if a 50 MHz alarm of the MBDCG master module is reported. Flags MBDCG_MBD_SyncFail or MBDCG_MBD_Fmax for the slave module are in the status register (system side 1 set).

Failure detection MBD system clock referenceThe 49.152 MHz clock reference input for the master/slave coupling is supervised con-tinuously on the slave and master. Each detected fault sets the CG_50M_SlaveRefFail flag. Should the reference signal be detected again, the flag is reset again after reading.

The PLL is supervised with a test circuit which can be faulty on its part. A faulty test circuit can lead to a slave whose frequency deviates strongly from 49.152 MHz. There is a fault on the MBDCG if the module is master. If the module is in slave operation, the reference i.e. the cross signal can be distorted by the redundant MBDCG to such an extent that reference supervision does not react although the PLL no longer functions correctly.

MBDCG SyncFail or MBDCG MBD FMax is reported by the slave module: The fault has already been pinpointed on the reporting (slave) module. If the partner MBDC (MBDC on side 0) is active, total failure handling is initiated for reporting side 1. If the partner MBDC (side 0) is inactive, partial failure handling is initiated for reporting side 1.

MBDCG SlaveRefFail is reported by the slave module: The fault is not pinpointed to one module. The MBD half to be switched off is determined in three phases:

Verification: STAGCG message is sent to the master side. If the expected acknowledg-ment does not occur within 2 s, the master side is identified as faulty. Should partial or total failure be reported for one of the two modules before the timer expires, this is con-sidered as faulty and total failure handling is initiated for the corresponding system side. Should a fault diagnosis on the module be impossible, XLINK fault handling will be initi-ated on its own side in the next phase. A conditional deactivation task is used to check whether or not there is redundancy for the reporting unit. If the deactivation task is suc-cessful, fault handling ends and an alarm message will be output. Otherwise, total failure handling will be initiated in the next phase for the partner module of the reporting unit.

A30828-Y1187-N510-2-7620

95


Id:0900d805806b9166

Remarks/notesModule MBDCG is controlled by the MBDC and does not have a controller of its own. Therefore, statistics about faults on the MBDCG are processed only on the MBDC.

Safeguarding which is decisive for the MBDCG is implemented by the HW on the module, the MBDC software and the CP software.


Main suspect moduleMBDCG


– The cross link cable to the partner module (XLINK).– The partner module MBDCG.




4.21 MMN:MB225-2003: MBICG TOTAL FAULT: MODULE FAILUREFor display of output mask and interpretation of byte-coded information, refer to 4.23 Interpretation of alarm mask for MBICG failures

System reaction

– The fault is an unconditional fault. The MB side determined is configured to UNA if the partner side is ACT. If there is no redundancy, ISTART1 is initiated provided that ISTART was not run during the previous 45 minutes. If running ISTART is not allowed, the side must be deactivated unconditionally.



Fault handlingMessage MB_MEGCG is sent on the IOP channel for maintenance commands either as a spontaneous MBDCG alarm (from the MBIC) or as an answer to the STAGCG. If the message has been sent spontaneously once already, the current fault state of M:MBDCG is sent via the maintenance channel to the CP by means of MB_MEGCG after each LOOP command. Depending on the contents of the MB_MEGCG message, FA:MB initiates total, cross link or partial fault handling.

An MBD alarm message with MMN:MB225-2003 is output if a 50 MHz alarm of the MBDCG master module is reported. Flags MBDCG_MBD_SyncFail or MBDCG_MBD_Fmax for the slave module are in the status register (system side 1 set).

96 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


Unlatch detection of the system clock PLL (PLL alarm)Safeguarding, which is decisive for the MBDCG is implemented by the HW on the module, the MBDC software and the CP software.

Individual hardware faults on the MBDCG can cause the module to issue clocks but no longer be synchronized to the CCG. The result is a phase deviation between the input and output of the module which can only be identified on the MBDCG itself. Because the PLLs in the SN and in the LTG units cannot detect small frequency deviations and would forward the faulty clock. The phase deviation between the clock reference and the EWSD system clock output is measured continuously on the MBDCG and the PLL alarm is detected when an alarm threshold is exceeded (see characteristic values of the MBD system clock generation). Each detected fault is entered into the status register of the EWSD system clock PLL.

In this case, flag CG_8M_SyncFail is set. Byte ff =01. This error message almost always refers to a fault in the MBDCG. However, it could also be a severely jittered output signal of the CCG.

The PLL is supervised with a test circuit which in its turn can also be faulty. For faulty test circuits the modules must be replaced to prevent an invalid clock from being distrib-uted in the exchange and in the entire network. Module MBDCG is the main suspect module. If byte ff = 01, the CCG output signals should also be tested.

The red and green LEDs illuminate on the module.

In order to prevent false alarms, the unlock detection is not evaluated in certain cases:

- If there is an incorrect clock reference

- After a reference fault up to safe latching of the PLL

Remarks/notesModule MBDCG is controlled by the MBDC and does not have a controller of its own. Therefore, statistics about faults on the MBDCG are processed only on the MBDC. Faults on the interface to the SN must be detected on the MBDH. The MBDCG does not accept safeguarding supervision of this interface.


Main suspect moduleM:MBDCG


– Clock supply cable CCG and M:MBDCG concerned are faulty or have not been inserted.

– The master CCG (= the CCG which is in ACT).– The MB Frames (backplane, connector strip) and the Frames with the master CCG.




A30828-Y1187-N510-2-7620

97


Id:0900d805806b9166

4.22 MMN:MB235-2001: MBICG: CLOCK REFERENCE FAILURE EQUIPMENT ALARM MMN:MB235-2001 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

For interpretation of byte-coded information, see 4.23 Interpretation of alarm mask for MBICG failures

System reaction

– If the SN is active on the side with the reference fault and the last request for an ACT/STB switchover ran less than 15 minutes before, an ACT /STB switchover of the switching network is carried out. The corresponding MB side is configured to UNA if the other system side is in ACT and there is CCG redundancy (a CCG is UNA or MBL). If there is no MB redundancy the corresponding side remains in ACT. The message is ignored if there is no CCG redundancy.

– The malfunction is indicated under object MB as a critical alarm or, if there is no redundancy, as a major alarm. An CCG fault can signal alarms of both sides (double fault). These MBD alarms can be reset only by an ACT or UNA - MBL - ACT config-uration if CCG has been repaired successfully.



An alarm message with MMN:MB235 is output if failure of the CCG clock reference is identified and the fault cannot be allocated to the group timing generator.

Failure detection of the CCG clock referenceSafeguarding which is decisive for the MBDCG is implemented by the HW on the module, the MBDC software and the CP software.

The module has 2 separate clock reference inputs for the connections to CCG0 and CCG1 which are supervised continuously. The complete failure of a clock signal, devi-ations in frequency and sporadic signal malfunctions are detected.

Each detected fault and both the active and the inactive clock reference input are entered into the status register of the EWSD system clock PLL. The flags Ref0 or Ref1 are set incorrectly and are reset again only after the status register is read.

If the fault occurs on an active clock reference input, the MBDC receives the CG_8M_RefSwitch, CG_8M_RefSpurious or CG_8M RefFail message.

Because it is very unlikely that the MB itself is malfunctioning here, it would not make sense to switch off an entire MB. FA:MB allocates the malfunction to the active master CCG and transfers the ADDITIONAL INFORMATION to the FA:CCG. If there is CCG

98 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


redundancy, the FA:CCG then takes the ACT CCG (master) out of operation, i.e. con-figures it to UNA. Cf. NM:CCG.

LEDs on the modules: Green LED on, red LED off.

Remarks/notesModule MBDCG is controlled by the MBDC and does not have a controller of its own. Therefore, statistics about faults on the MBDCG are processed only on the MBDC.

Communication with the CP software is used to report faults of the preconnected CCG or its own HW faults for fault handling and diagnosis.

Main suspect areasError message CG_8M_RefSwitch: CCG or only routine switchover

Error messages CG_8M_RefSpurious or CG_8M RefFail. The two clock supply cables between the CCG and the MBDCG concerned are faulty or have not been inserted (cor-responding MBD side is UNA.)


– The master CCG (= the CCG which is in ACT).– Module MBDCG.– The Frames (backplane, connector strip) with the reporting MBDCG and the Frames

with the master CCG.




4.23 Interpretation of alarm mask for MBICG failures EQUIPMENT ALARM MMN:MB225-200x ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#

CONFIGURATION: UNIT FROM TO +------------+-----+----+ @########## @## @## SUPPLEMENTARY INFORMATION: H’aabbcccc deffgghh iizzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz

A30828-Y1187-N510-2-7620

99


Id:0900d805806b9166

Byte Content Meaning

aa 06 Origin of message (sender) = EAVT (IOCP): The message comes from the call pro-cessing periphery; input via IOP:MB.

bb 09 MBIC message that a malfunction was detected in the appropriate group timing gen-erator

cccc Processor number of the reporting MBU:LTG side number (from which the clock mal-function was detected). The following are possible here

de Status byte of the group timing generator (GCG). The two half-bytes d and e must be interpreted separately:

d=0 PLL supervisory circuit is faulty (answer to STAGCG)

d=1 Clock alarm spontaneous (MBDCG_8M_SyncFail)

d=2 MBDCG alarm (spontaneous), MBDCG_8M_RefFail

d=3 PLL alarm spontaneous (MBDCG_8M_SyncFail)

d=4 PLL supervisory circuit o.k (answer to STAGCG) or spontaneously on reporting an MBDCG fault in byte ff or gg

d=6 PLL supervisory circuit o.k and clock alarm (confirmed by STAGCG), i.e. there was already a clock alarm before STAGCG

d=7 PLL supervisory circuit o.k and PLL alarm (confirmed by STAGCG), i.e. there was already an alarm with PLL alarm before STAGCG

d=8 I2C bus fault, the group timing generator cannot be reached/or is not available.

e= The four bit positions u v w x are occupied individually for half-byte e.

x = 0 Clock 0 is not available, w = 0 Clock 1 is not available

v = 0 FMB0 is not available, u = 0 FMB1 is not available

Examples:

e = A: Clock 1 and FMB1 are not available

e = E: Only clock 0 is not available

ff Status byte of the group timing generator 8MHz clock, the bit allocation is shown indi-vidually here because combinations are possible.

f0 = 1 MBDCG_8M_Fail

f1 = 1 MBDCG_8M_RefSpurious

f2 = 1 MBDCG_8M_RefSwitch

f3 = 1 MBDCG_8M_Ref0Fail

f4 = 1 MBDCG_8M_Ref1Fail

f5 = 1 MBDCG_8M_RefFail

f6 = 1 MBDCG_8M_RefNum

gg Status byte of the group timing generator 50MHz clock

01 MBDCG_MBD_SyncFail

02 MBDCG_8M_SlaveRefFail

04 MBDCG_MBD_Fmax

05 MBDCG_MBD_SyncFail and MBDCG_MBD_Fmax

Table 17 Interpretation of SUPPLEMENTARY INFORMATION

100 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


4.24 MMN:MB240-2001 - MBIE MODULE FAILURE EQUIPMENT ALARM MMN:MB240-2001 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#







hh Status byte of the group timing generator 50MHz master/slave

00 Master system side 0

01 Slave success: (System side 1)

02 Slave fail: (System side 1)

03 Slave disbledx

ii 50MHz fault diagnosis

00 Fault diagnosis impossible byte gg = 0

01 MBDCG module is concerned

02 MBDCG partner module is concerned

zz Bytes marked with z...z are unoccupied here. Also entries not equal to 00 are irrelevant and cannot be interpreted

Byte Content Meaning

Table 17 Interpretation of SUPPLEMENTARY INFORMATION (Cont.)

SPECIFIC PROBLEM MBIE TOTAL FAULT: MODULE FAILURE

MBIE PARTIAL FAULT: MODULE FAILURE

11 SG_FA_MB

04 MBDE

00 ... 07 MBDE

01 Total failure

02 Partial failure

A30828-Y1187-N510-2-7620

101


Id:0900d805806b9166


System reaction

– The corresponding MB unit is configured to UNA if the partner unit is ACT. If there is no redundancy, the MB unit remains ACT in the case of a partial failure. In the case of total failure the unit will be configured to UNA unconditionally. ISTART1 is initiated if the disconnection of an MBIE (last MBIE) leads to a total failure of the MBD.

– The malfunction is displayed under object MB as a critical alarm or, if there is no redundancy, as a major alarm.


Fault handlingAn MB alarm message with MMN number MB240-2001 is output if the internal on-line routine test of the ASIC of the module concerned has detected a hardware fault inde-pendently. Depending on whether or not one or both ASICs s of a module are involved, partial or total failure management is initiated by FA:MB.

Suspect hardwareM:MBDE on both sides, cables between the two MBDE modules

The Frame (backplane, connector strip).


02 RESBUS fault (faulty reset bus).

03 Processor (FPGA) of MBDE does not send READY: The RESBUS is a unidi-rectional bus in which case the MBDC module is the sender. RESET request acknowledgments are sent to MBDC via the IBUS. If this acknowledgment fails to appear (READY), this will be detected by the MBDC.

04 FEPROM fault: Each FW/SW version in the FEPROM is protected by a checksum which is checked when it is loaded from the FEPROM into the SDRAM and when it is checked in the routine test by each processor.

05 Parity error (startup after RESET unsuccessful). The data bus between Pow-erQuicc and the SDRAMs is protected with 4 bit parity which is stored in the SDRAMs together with each data word. A parity error causes a reset of the corresponding PowerQuicc.

Parity supervision: For write access to the SDRAM a parity bit is calculated for each byte. The parity bit is supplemented for even parity. The parity is only cal-culated for bytes which are constructionated as valid by the byte enable signal. The parity is stored with the data in the SDRAM. For read access from the SDRAM, the parity of the read data is recalculated and compared with the stored parity

06 SDRAM fault, startup after RESET unsuccessful

07 Memory protection violation. The SDRAM controller supervises access to the SDRAM (e.g. access to the HDLC controller on the IBUS data areas in the SDRAM).

08 Memory shortage

102 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


Diagram of frames - module side, backplane and cabling: Construction, Frames F:MB/CCG.


4.25 MMN:MB240-2002 - MBIE IBUS FAILURE EQUIPMENT ALARM MMN:MB240-2002 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#








System reaction

– The corresponding MB unit is configured to UNA if the partner unit is ACT. If there is no redundancy, the MB unit remains ACT in the case of a partial failure. In the case of total failure the unit will be configured to UNA unconditionally. ISTART1 is initiated if the disconnection of an MBIE (last MBIE) leads to a total failure of the MBD.


SPECIFIC PROBLEM MBIE PARTIAL FAULT: IBUS FAILURE

MBIE TOTAL FAULT: IBUS FAILURE

11 SG_FA_MB

04 MBDE

00 ... 07 MBDE

01 Total failure

02 Partial failure

0A IBUS fault

A30828-Y1187-N510-2-7620

103


Id:0900d805806b9166


Cause/fault explanationAn MB alarm message with the MMN number MB240-2002 is output if the IBUS test routine has detected a malfunction in the internal bus system IBUS. The IBUS test forms part of the internal on-line routine test. A loop test is carried out approximately every 100 ms within a module and between the modules. Faults are detected if a test loop cannot close after a timer has expired or a test pattern was corrupted. The IBUS test has multiple levels.

IBUS test within a module: – Each processor sends an IBUSLOOP message. If a fault is identified, the processor

is reset again.– Approximately every 100 ms, each master processor sends an IBUSLOOP

message to its slave. If the master receives all the IBUSLOOPR acknowledgments, the module status is fault-free (green LED). If an acknowledgment fails, an MBDERR is generated after a repeat and sent to MBD maintenance. Module status faulty (red LED).

IBUS test between the modules of one system side:– In the IBUS routine test between the individual modules, each master processor

sends an IBUSLOOP to the masters of the modules configured offline or online. If the acknowledgment fails to appear, MBDERR is generated after a repeat and sent to MBD maintenance on M:MBDC.

IBUSLOOP: Test loop from the IBUS output on the corresponding IBUS input on the same module via the backplane of the frames. The IBUS switch can be tested via this connection.

All the requirements which are sent via the IBUS are time-supervised (watchdog). If an IBUS sender does not receive an acknowledgment within the timeout period, this fact will be notified to the MBIC which then identifies the faulty module.

Data faults (e.g. length) are identified by the CRC (cyclic redundancy check) and reported to the MBIC. The MBIC then issues an alarm message to the CP.

Processing an IBUS fault between two modules

Figure 12 Fault handling for IBUS faults between two modules

Tx-ASIC Rx-ASIC Tx-ASIC Rx-ASIC

MBDBIF

MBDC

M:MBDx M:MBDySwitch Switch

MB

DE

RR

MB

DE

RR

Req

uest

Request

IBU

SLO

OP

IBU

SLO

OP

R

Request2.

4.5. 6.

104 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


1. During normal operation a fault is identified on the IBUS (timeout, inactive)2. To confirm the fault, the generic maintenance software sends a test report to the

receiver who cannot be reached during operation 3. If the sender receives the acknowledgment (reply message), the fault is considered

to be sporadic and the blocking flags (timeout, inactive) are reset4. If the fault is confirmed, the sender generates an MBDERR message and sends this

to MBD maintenance on module MBDC5. The MBD_MTC tries to reach the marked receiver with a test message6. If the MBD_MTC receives the reply message, an IBUS fault is sent to the CP by indi-

cating both the modules concerned with MBDERR.7. If the MBD_MTC does not receive a reply message, the receiver is reported as being

faulty to the CP with MDERR.

Suspect hardwareM:MBDE concerned, for IBUS fault between 2 modules of a system side, the other MBDEs of this system side


Cross references:Diagram of the MB Racks and the associated fuses: Construction, Racks.

Diagram of the Frames and wiring: Construction, Frames F:MB/CCG.


4.26 MMN:MB240-2003 - MBIE XLINK FAULT EQUIPMENT ALARM MMN:MB240-2003 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#





SPECIFIC PROBLEM MBIE XLINK FAULT

11 SG_FA_MB

04 MBDE

A30828-Y1187-N510-2-7620

105


Id:0900d805806b9166



Further suspect units are in all cases: The appropriate Frames (backplane, connec-tor strip)


System reaction

– The corresponding MB unit is configured to UNA if the partner side is ACT. In the case of total failure ISTART1 will be initiated for MBIE provided ISTART has not run during the previous 45 minutes. If executing ISTART is not allowed, the unit will be deactivated unconditionally.



Cause/fault explanationAn MB alarm message with the MMN number MB240-2003 is output if the routine test has detected a malfunction in the internal bus system for the one partner half (called XLINK). The IBUS test forms part of the internal on-line routine test. A loop test is carried out approximately every 100 ms within a module and between the modules of a system side and between the partner modules on both system sides.

The routine test for the one partner half is carried out by the master processor of the modules. The processors in the partner side are recorded with the MBDXLINK command in the list of the processors to be tested. In the routine test between the partner modules, each master processor sends an IBUSLOOP to the master on the partner module. If the IBUSLOOPR acknowledgment fails to appear, an MBDERR is generated after a repeat and sent to MBD maintenance on M:MBDC.

Processing a cross link fault

1. During normal operation, an IBUS fault will detected during a transmission to the partner side (timeout, inactive)

2. To confirm the fault, the sender tries to reach the master processor of the partner module in the subsequent IBUS test

3. No fault is reported if the sender receives the reply message. This fault must have been detected on the partner side.

4. A cross link fault is reported if the fault is confirmed, i.e. the partner master ASIC cannot be reached

Further fault handlingShould there be an XLINK fault, communication between redundant modules of the two MB sides is impossible. Reports and orders are blocked.

If one or more XLINKs are marked faulty:

00 ... 07 MBDE

05 XLINK fault

01 XLINK fault

106 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


First of all, the system preferred side is calculated. In so far as is possible, all the MBD bridges or the MCH are activated on this system side to prevent reports and orders from blocking.

For previous XLINK faults (pairs marked as faulty) the side has already been selected and the calculation can be omitted.

No previous XLINK faults: The best possible communication is guaranteed by the side with the highest number of active modules. All the active modules including those which have been activated are counted and, in this way, the preferred side is determined.

In order to prevent the unnecessary switching over of message channels, the side not affected by the configuration at the moment is specified as the preferred side, provided that it was not already determined in the previous stages.

If the preferred side is specified, all the available MCHCs of an MBIE pair are switched actively with the faulty XLINK on the preferred side. The distribution of message channels is recalculated for faulty XLINKs in MBIE.

Suspect hardwareM:MBDE and partner M:MBDE, cable between the two MBDE modules




4.27 MMN:MB240-2004 - MBIE TOO MANY RESETS EQUIPMENT ALARM MMN:MB240-2004 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: MBIE PARTIAL FAULT: TOO MANY RESETS MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#



System reaction




A30828-Y1187-N510-2-7620

107


Id:0900d805806b9166

Cause/fault explanationIf an MBIE is reset spontaneously, i.e. not because of configurations, FA:MB receives an MBDREADY message from the MB. A statistics counter is run for each MBIE: Each spontaneously arriving MBDREADY message increments the statistics counter and the statistics counter is reduced by one each hour. If the MBIE is reset unexpectedly, the routing information is reloaded by the CP. An MB alarm message with the MMN number MB240-2004 is output if the number of MBDREADY messages from MBIE exceed 10.

Main suspect moduleModule M:MBDE allocated to the reporting unit




4.28 MMN:MB240-2005 - MBIE OLD FW LOADED EQUIPMENT ALARM MMN:MB240-2005 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: MBIE PARTIAL FAULT: OLD FW LOADED MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#



System reaction




Cause/fault explanationAn MB alarm message with the MMN number MB240-2005 is output if the test of the FEPROM detected a malfunction, i.e. the incremented checksum of the stored bytes did not correspond to the stored checksum.

The SW of units MBIE is stored on an FEPROM of the corresponding module. Each FW/SW version in the FEPROM is protected with a checksum which is checked by each processor on loading the FEPROM into the SDRAM and in the routine test. If a

108 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


checksum fault is detected, an older FW/SW version will be used in the FEPROM in the next startup. The routine test (internal online routine test) is started by the CP with STAGCG in low traffic periods.

Suspect hardwareM:MBDE on both sides

All M:MBDEs on the system side with the suspect MBIE





4.29 MMN:MB240-2006 - FPGA ERROR EQUIPMENT ALARM MMN:MB240-2006 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: MBIE TOTAL FAULT: FPGA ERROR MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#








System reaction

– The corresponding MB unit is configured to UNA if the partner unit is ACT. If there is no redundancy ISTART1 will be initiated for MBIE provided ISTART has not run

11 SG_FA_MB

04 MBDE

00 ... 07 MBDE

01 Total failure

34 SDRAM fault, startup after RESET unsuccessful, FPGA failure

A30828-Y1187-N510-2-7620

109


Id:0900d805806b9166

during the previous 45 minutes. If executing ISTART is not allowed, the unit will be deactivated unconditionally.



Fault handlingAn MB alarm message with MMN number MB240-2006 will be output if the startup after RESET is unsuccessful. The processor of the suspect module does not send READY: The RESBUS is a unidirectional bus in which case module MBDC is the sender. Acknowledgments for a RESET request are sent to the MBDC via the IBUS. If this READY acknowledgment fails to appear, this is detected by the MBDC and reported to fault analysis MB.

Suspect hardwareMBDE and connection to MBDC



Diagram of frames - module side, backplane and cabling: Construction, Frames F:MB/CCG or Construction, Frames F:IOPMBD and Construction, Frames F:SN.


4.30 MMN:MB240-2007 - ETHERNET ERROR EQUIPMENT ALARM MMN:MB240-2007 ALARM PRIORITY: @####### PROBABLE CAUSE: EQUIPMENT MALFUNCTION SPECIFIC PROBLEM: MBIE PARTIAL FAULT: ETHERNET PHYTER ERROR MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#





11 SG_FA_MB

04 MBDE

110 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166





System reaction

– The corresponding MB unit is configured to UNA if the partner unit is ACT. If there is no redundancy, the MB unit remains ACT.



Fault handlingAn MB alarm message with MMN number MB240-2007 will be output, if the routine test detects a failure at the phyter module. The fault is reported to the fault analysis MB. In case there is no redundancy the MBIE remains ACT. If the connection is fault-free the green LED is lit, if the connection is disturbed the red LED is lit.

Suspect hardwareMBDE and connection to the ethernet



Diagram of frames - module side, backplane and cabling: Construction, Frames F:MB/CCG and Construction, Frames F:SN.


4.31 MMN:MB241-2001 - MBIE IP DATA ERROR EQUIPMENT ALARM MMN:MB241-2001 ALARM PRIORITY: @####### PROBABLE CAUSE: LOSS OF SIGNAL SPECIFIC PROBLEM: MBIE PARTIAL FAULT: IP DATA ERROR MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#


00 ... 07 MBDE

01 Total failure

33 Phyter error

A30828-Y1187-N510-2-7620

111


Id:0900d805806b9166

Interpretation of the supplementary information bytes • aa = 11: Origin of the message = SG_FA_MB • bb = 04: Type of module = MBDE • cc = 00 ... 07: Module number together with the byte bb module type MBDE • dd: Classification of the detected fault

• ee = 35: Detailed fault information = IP DATA ERROR • z...z: These bytes are not occupied. Entries not equal to 0 are also not relevant.

System reaction

– The corresponding MB unit is configured to UNA if the partner unit is ACT. If there is no redundancy, the MB unit remains ACT. ISTART1 is initiated if the disconnec-tion of an MBIE (last MBIE) leads to a total failure of the MBD.

– The malfunction is indicated under object MB.– The log is stored in the history file and entered into the alarm file (AM.ALARM).

ExplanationThis alarm is output for MBIE with the application LTG in connection with SURPASS hiG 1600 V2.x. The SURPASS hiG1600 V2.x is an IP-based gateway.

The FPU-E, a part of the SURPASS hiG 1600 V2.x, consists of the components voice module (VM) and and feature processor (FP). The VM is the SCTP partner platform. The FP has the LTG function. Administration and maintenance treat the FP as an LTG. VM and FP communicate via two HDLC connections. The SCTP and HDLC connections build the logical message channel (MCH).

The VM is a submodule that can be located on the packet service controller card (PSC-C, module M:FPPxxx) or on the voice module card (VMC, module M:MP480). It supports a maximum of four feature processing functions. The variant with the voice module card allows the reuse of existing LTGs. VMC and LTGs are connected via cables. For an overall description of the SURPASS hiG 1600 see also SURPASS hiG 1600 Functions and Hardware.

Administration of IP addressesAn MBIE has 4 LAN connectors, the MBIE links. For each MBIE link the IP address of the link itself, the IP address of the gateway router and the subnet mask for this link must be stored. For SURPASS hiG 1600 V2.x only two of the four MBIE links are used, links 0 and 2.

The IP addresses and subnet mask may only be altered if the MBIE is used for the con-nection of LTGs. If the MBIE is used for connection of commercial platforms, the IP address of the MBIE link is always the default address, the IP address of the gateway router is 0.0.0.0 and the subnet mask is always 255.255.255.255. The MBIE application is set to “COPL” by default and must be manually changed.

All administrative data which can be set with command MOD MBIE can be displayed with command DISP MBIE.

SPECIFIC PROBLEM MBIE PARTIAL FAULT: IP DATA ERROR

SPECIFIC PROBLEM MBIE TOTAL FAULT: IP DATA ERROR

01 Total failure

02 Partial failure

112 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


Figure 13 Example SURPASS hiG1600 database at hIE9200

Mismatch of MBIE IP addresses during MBIC resetAn MBDREADY for an M:MBDC of an MBIC causes the MBDC to be reloaded. If during MBDC reload the IP-addresses of the command MBDIPCONF differ to the ones stored in the MBDE the MBDIPCONF command will be acknowledged negatively causing the abortion of the MBDC reload. As the IP addresses are stored within the FEPROM of the MBDE, the reason for the difference of the IP-addresses is either an error in the database update or a hardware error of the M:MBDE. The MBIE is alarmed and config-ured to UNA.

Mismatch of MBIE IP addresses during MBIE resetFA:MB receives an MBDREADY message from the MB when an MBIE is reset sponta-neously. If after an MBIE-reset the IP-addresses in the M:MBDC differ from the one stored in the M:MBDE an MBDERROR message with error-info IP_DATA_ERROR and category partial fault is sent to the CP.

If after an MBIE-reset both IP-addresses in the M:MBDC differ from the ones stored in the M:MBDE an MBDERROR message with error-info IP_DATA_ERROR and category total fault is sent to the CP.

All concerned MCH are configured to UNA, because of MBCHERs (MB channel errors), error FF by FA:MCH. FPU-Es which cannot be reached by the CP are configured to NAC.

Download of IP addresses of VM The MBIE must know the IP address of the VM before a SCTP association can be setup. Therefore every time before an MBDCHON is sent from CP for an MCH to an FPU-E, the command MBDIPMAP must be sent that includes IP addresses of up to eight FPU-Es and the message MBDIPMAPR must be received.

MBIE SURPASS hiG 1600 resetWhen FA:MB receives an MBDREADY message for module MBDE of an MBIE with the application LTG the MCH of the FPU-E will be resynchronized. The IP addresses of the FPU-E will be reloaded with the command(s) MBDIPMAP. After having received the

MBIELINK 0192.20.59.11

MBIELINK 2192. 20.59.12

GW router192.20.59.1.

I

MBIE 3

P

PSC

PS-EVM192.20.59.4

FP21-17

FPU-E

CR LTG:LTG=21-17,TYPE=LTGC,LDARP=65,MODE=FP,IPADDR=”192.20.59.4”,LOCATION=”MUNICH-LAIM”;MOD MBIE:MBIE=3,MB=X,

APPLIC=LTG;

MOD MBIE:MBIE=3,MB=0,MBIE=3,MBIELINK=0,IPADDR=”192.20.59.11”,GWIPADDR=”192.20.59.1,SUBNMASK=”255.255.255.0”;MOD MBIE:MBIE=3,MB=0,MBIE=3,MBIELINK=2,IPADDR=”192.20.59.12”,GWIPADDR=”192.20.59.1,SUBNMASK=”255.255.255.0”;

A30828-Y1187-N510-2-7620

113


Id:0900d805806b9166

messages the ACT and STB MCH will be synchronized, with command MBDCHON. FPU-Es being initialized or in FW boot will be treated by CONF:LTG, message LTGDEF.

Suspect hardwareM:MBDE and connection to the ethernet


Cross-referencesFor LTG fault clearance refer to MMN:LTG and NM:LTG

For VM (MoPC), Router, PS fault clearance refer to the UMN:SURPASS hiG 1600 V2.x

Diagram of the MB Racks and the associated fuses: Construction, Racks.



4.32 MMN:MB243-2000 - COM PROT ERROR EQUIPMENT ALARM MMN:MB243-2000 ALARM PRIORITY: @####### PROBABLE CAUSE: COMMUNICATIONS PROTOCOL ERROR SPECIFIC PROBLEM: MBIE COMMUNICATION PROTOCOL ERROR MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#

CONFIGURATION: UNIT FROM TO +------------+-----+----+ @########## @## @## SUPPLEMENTARY INFORMATION: H’aabbcczz zzzzdddd zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz

Interpretation of the byte • aa = 0F: Origin of the message = SGMES (safeguarding monitor) • bb = 2D: Detected malfunction = SG_MBD_FAULT

bb = 33: Ethernet Error • cc = 14: Reporting software unit = Safeguarding software for the routine test here

MB (SG-ROUT-TEST) • dddd: Processor number of the unit concerned see MBD - IO processor numbers • ee = 07: Function = MB_CHER • z...z: These bytes are not occupied. Entries not equal to 0 are also not relevant.

System reaction

– The corresponding MBIE unit stays in ACT.The MCH are configured to UNA, an appropriate mask listing the faulty MCH is displayed.

– A communication alarm is displayed under object MB.– The log is stored in the history file and entered into the alarm file (AM.ALARM).

114 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


Cause / fault explanationThis alarm is output for MBIE with the application LTG in connection with SURPASS hiG 1600 V2.x. The SURPASS hiG 1600 V2.x is an IP-based gateway. The feature proces-sor unit type ethernet (FPU-E), a part of the hiG1600 V2, consists of the components voice module VM and feature processor FP. The VM is the SCTP partner platform. The FP has the LTG function. Administration and maintenance treat the FP as an LTG. VM and FP communicate via two HDLC connections. The SCTP and HDLC connections build the logical message channel (MCH). The VM is a submodule that can be located on the packet service controller card (PSC-C, module M:FPPxxx) or on the voice module card (VMC, module M:MP480) and supports a maximum of four feature processing functions. The variant with the voice module card allows the reuse of existing LTGs. VMC and LTG are connected via cables. For an overall description of SURPASS hiG 1600 see also SURPASS hiG 1600 Functions and Hardware.

If one or more FPU-Es lost one MCH an alarm message with MMN:MB243-2000 is output for the assigned MBIE.

If MCH of FPU-Es could not be re synchronized after an MBIE reset, FA:MCH again has the failed MCHs or FPU-Es configured to UNA.

Fault analysis for IP-based message channelsThe FA:MCH receives a CHER message from an MBIE if the latter has detected one or more faulty MCHs. After the CHER message has been received, the FA:MCH sends the collective command TECO to all active and standby MCHs of FPU-Es on both MBIE sides in order to detect other defective message channels. A timer of 0,5 sec is set to collect further MBCHER. The reaction of FA:MCH depends on the reason of outage.

If FA:MCH decides for MCH failures the assigned MBIE is alarmed. If the FPU-Es are still reachable a major alarm is set. The faulty MCH are output in the following mask. No SYOP alarm is set with this unsolicited message. MCH FAILURE WITH CONFIGURATION MMN:MCH01-0000 MCH FAILURE FAULT LOCATION: MB-mb MBIE-mb-mbie SUPPLEMENTARY INFORMATION: H’aabbcccc ddeeeeee eeeeeeee eezzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz CONFIGURATION SIDE: mb NO: FROM TO NO: FROM TO -----+----+----+------+----+---- ltgset-m yyy UNA @#### @## @##

In case the contents of the SUPPLEMENTARY INFORMATION bytes equals zero, the values can be read from the SG.OPER.

Byte interpretation • aa = 06: Message source = IOCP • bb = 07: Function = MB_CHER • cccc: IO processor number MBD - IO processor numbers • dd: Fault byte

01 SCTP was aborted by VM

A30828-Y1187-N510-2-7620

115


Id:0900d805806b9166

• e..e: Channel number, explanation see following topic. • z..z: These bytes are not occupied. Entries not equal to 0 are also not relevant.

Channel numberThe eight bytes ee contain the numbers of the affected MB channels. The bytes are to be interpreted bit by bit. If the affected bit has the value 1, the associated MB channel is defective.

The numbers in the table correspond to the channel numbers.

Supervision of MB - LTG message transmissionThe message buffer detects fault in message transmission between the MB and the FPU-E. The following faults may occur:– SCTP association failed because of timeout. After expiration of the integration timer

the command MBDCHOFF is sent to the MBD for the failed MCH to stop the repe-tition of the MBCHER messages and the failed ACT and STB MCH are configured by the CP STATTRANS message. With receiving message TRANSRESP the affected MBDE is alarmed. If just MCHs are configured to UNA and all concerned FPU-Es are still active a major alarm is issued for the affected MBIE. The faulty MCH are displayed.

– Overload was detected by MBIE in transmit direction or SCTP association failed because of VM problems. After the VM becomes operable again, re synchronization of the affected MCH is attempted. If re synchronization fails a major alarm for the affected MBIE is issued. The faulty MCH are displayed.

– TRACOL on not synchronized MCH. A CP application has sent collective commands for not synchronized MCH. If that MCH is not ACT or STB FA.MCH ignores the MCHCHER. Re synchronization of the ACT /STB MCH is attempted. If re synchronization fails a major alarm for the affected MBIE is issued. The faulty MCH are displayed.

02 MBIE detected a SCTP time out

03 SCTP was aborted by VM because of VM internal problems

20 MBIE detected overload in transmit direction

40 A collective command was sent on a not synchronized MCH

FF MBDE processor failed

Bit 7 6 5 4 3 2 1 0

Byte 0 14 12 10 8 6 4 2 0

Byte 1 30 28 26 24 22 20 18 16

Byte 2 46 44 42 40 38 36 34 32

Byte 3 62 60 58 56 54 52 50 48

Byte 4 78 76 74 72 70 68 66 64

Byte 5 94 92 90 88 86 84 82 80

Byte 6 110 108 106 104 102 100 98 96

Byte 7 126 124 122 120 118 116 114 112

Table 18 MB channel numbers

116 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


– If a processor of an M:MBDE fails the MBIC sends an MBDERROR message and MBDCHER messages for all possible FPU-E MCHs of this processor, regardless of their states. MBDCHOFF is sent to the MBD for MCH being not ACT or STB to stop the repetition of the MBCHER messages. For the other MCH re synchronization is attempted. All MCHs which cannot be synchronized, are then switched off and a major alarm for the affected MBIE is issued. The faulty MCH are displayed.

MCH Re synchronization after MBIE resetsAfter an MBIE reset FA:MCH re synchronizes the ACT /STB MCHs of the FPU-Es.– First the IP addresses of the FPU-Es are reloaded with command MBDIPMAP. This

is acknowledged by the MBD with MBDIPMAPR.– Then the ACT /STB MCH are set up with command MBDCHON. Each MBDE pro-

cessor responds with MBDCHONR for its MCHs.– The LTG react with LGCHAR.– LTGCHACN is sent for ACT MCH and LTGCHASN is received from the LTG.

All commands are time supervised (5 seconds). If one of those action fails for MCHs of FPU-Es, the affected MCH are configured to UNA and an alarm for the assigned MBIE is output.

Suspect hardwareMBDE and connection to the ethernet, switch and router in SURPASS hiG 1600, PS (power supply), LTGx and M:MP480 (=VMC) or M:FPP (=LTG and VM) central or single failure (port failure) in SURPASS hiG1600 V2.

MBIE MBU LTGSET

0 7 28...31

1 6 24...27

2 5 20...23

3 4 16...19

4 3 12...15

5 2 8...11

6 1 4...7

7 0 0...3

Table 19 Correlation between MBIE number, MBU number and LTGSET

Module GPPxx or GPSxx LTG MCH

1 1, 2, 3 1, 2, 3

2 4, 5, 6, 7 4, 5, 6, 7

3 8, 9, 10, 11 8, 9, 10, 11

4 12, 13, 14, 15 12, 13, 14, 15

5 16, 17, 18, 19 16, 17, 18, 19

6 20, 21, 22, 23 20, 21, 22, 23

7 24, 25 , 26, 27 24, 25 , 26, 27

Table 20 LTG allocation GPPxx

A30828-Y1187-N510-2-7620

117


Id:0900d805806b9166


For VM (MoPC), Router, PS fault clearance refer to the UMN:SURPASS hiG 1600 V2.x


Diagram of frames - module side, backplane and cabling: Construction, Frames MB/CCG or F:IOPMBD.


4.33 MMN:MB244-2000 - MBIE LOSS OF SIGNAL EQUIPMENT ALARM MMN:MB244-2000 ALARM PRIORITY: @####### PROBABLE CAUSE: LOSS OF SIGNAL SPECIFIC PROBLEM: MBIE LOSS OF SIGNAL MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=@##### MB=@# @########@@#

CONFIGURATION: UNIT FROM TO +------------+-----+----+ @########## @## @## SUPPLEMENTARY INFORMATION: H’aabbcczz zzzzdddd zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz

Interpretation of the byte • aa = 0F: Origin of the message = SGMES (safeguarding monitor) • bb = 2D: SG_MBD_FAULT

bb = 33: Ethernet Error • cc = 14: Reporting software unit = Safeguarding software for the routine test here

MB (SG-ROUT-TEST) • dddd: Processor number of the unit concerned see MBD - IO processor numbers • z...z: These bytes are not occupied. Entries not equal to 0 are also not relevant.

8 28, 29, 30, 31 28, 29, 30, 31

9 32, 33, 34, 35 32, 33, 34, 35

10 36, 37, 38, 39 36, 37, 38, 39

11 40, 41, 42, 43 40, 41, 42, 43

12 44, 45, 46, 47 44, 45, 46, 47

13 48, 49, 50, 51 48, 49, 50, 51

14 52, 53, 54, 55 52, 53, 54, 55

15 56, 57, 58, 59 56, 57, 58, 59

16 60, 61, 62, 63 60, 61, 62, 63


Table 20 LTG allocation GPPxx (Cont.)

118 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


System reaction

– The corresponding MBIE is alarmed. If the redundant unit is in ACT the alarm message is repeated for this unit as well. The MCH are configured to UNA, an appro-priate mask listing the faulty MCH is displayed. The related FPU-Es are configured to NAC (object LTG)

– The malfunction is displayed under object MB as a critical alarm.– The log is stored in the history file and entered into the alarm file (AM.ALARM).

Cause / fault explanationThese alarm messages are output for MBIEs with IP-based MCHs to SURPASS hiG1600 V2. The alarm message is output, if one or more FPU-Es (feature processor unit type ethernet) lost both MCH. Both sides are affected, the FPU-Es are not accessi-ble. The FPU-Es consist of the components VM (voice module and FP (feature proces-sor).

The VM is the SCTP partner platform: The FP has the LTG function and is also treated by administration and maintenance as an LTG. VM and FP communicate via two HDLC connections. The SCTP and HDLC connections build the logical message channel (MCH).

The VM is a submodule that can be located on the packet service controller card (PSC-C, module M:FPPxxx) or on the voice module card (VMC, module M:MP480) and supports a maximum of four feature processing functions. The variant with the voice module card allows the reuse of existing LTGs. VMC and LTG are connected via cables. For an overall description of hiG1600 see also SURPASS hiG1600 Functions and Hard-ware.

Fault analysis message channelThe FA:MCH receives a CHER message from an MBIE if the latter has detected one or more faulty MCHs. After the CHER message has been received, the FA:MCH sends the collective command TECO to all active and standby MCHs of FPU-Es on both MBIE sides in order to detect other defective message channels. A timer of 0,5 sec is set to collect further MBCHER. The reaction of FA:MCH depends on the reason of outage.

If FA:MCH decides for MCH failures, FA:MB is informed to alarm the assigned MBIE. If the FPU-Es are no longer reachable a critical alarm is set. The faulty MCHs are output with the following mask. No SYOP alarm is set with this unsolicited message. MCH FAILURE WITH CONFIGURATION MMN:MCH01-0000 MCH FAILURE FAULT LOCATION: MB-mb MBIE-mb-mbie SUPPLEMENTARY INFORMATION: H’aabbcccc ddeeeeee eeeeeeee eezzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz CONFIGURATION SIDE: mb NO: FROM TO NO: FROM TO -----+----+----+------+----+---- ltgset-m yyy UNA @#### @## @##

In case the contents of the SUPPLEMENTARY INFORMATION bytes equals zero, the values can be read from the SG.OPER.

A30828-Y1187-N510-2-7620

119


Id:0900d805806b9166

Byte interpretation • aa = 06: Message source = IOCP • bb = 07: Function = MB_CHER • cccc: IO processor number MBD - IO processor numbers • dd: Fault byte

• e..e: Channel number, explanation see following topic. • z..z: These bytes are not occupied. Entries not equal to 0 are also not relevant.

Channel numberThe eight bytes ee contain the numbers of the affected MB channels. The bytes are to be interpreted bit by bit. If the affected bit has the value 1, the associated MB channel is defective. The numbers in the table correspond to the channel numbers.

Supervision of MB - LTG message transmissionThe message buffer detects fault in message transmission between the MB and the FPU-E. The following faults may occur:– MBCHER 01: The VM detects HDLC loss to FPU-E and aborts the SCTP associa-

tion to the MBIE. After expiration of the integration timer the command MBDCHOFF is sent to the MBD for the failed MCH to stop the repetition of the MBCHER messages and the message LTGUNA is sent to FA:LTG for those FPU-Es that have lost their last ACT MCH with reason “STCP ABORT” in order to have the FPU-Es configured to UNA, and alarmed. In this case the MBIE is not alarmed.

– SCTP association failed: MBCHER with error 0x02 (TIMEOUT) was received. After expiration of the integration timer the command MBDCHOFF is sent to the MBD for the failed MCH to stop the repetition of the MBCHER messages. The failed ACT and STB MCH are configured by the CP. If the last MCH of an FPU-E gets configured to UNA, the FPU-E becomes NAC. On receiving message TRANSRESP the affected

01 SCTP was aborted by VM

02 MBIE detected a SCTP time out

03 SCTP was aborted by VM because of VM internal problems

20 MBIE detected overload in transmit direction

40 A collective command was sent on a not synchronized MCH

FF MBDE processor failed

Bit 7 6 5 4 3 2 1 0

Byte 0 14 12 10 8 6 4 2 0

Byte 1 30 28 26 24 22 20 18 16

Byte 2 46 44 42 40 38 36 34 32

Byte 3 62 60 58 56 54 52 50 48

Byte 4 78 76 74 72 70 68 66 64

Byte 5 94 92 90 88 86 84 82 80

Byte 6 110 108 106 104 102 100 98 96

Byte 7 126 124 122 120 118 116 114 112

Table 21 MB channel numbers

120 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


MBIE is alarmed: if any FPU-E is in NAC because of the lost MCH a critical alarm is issued for the assigned MBIE. The faulty MCHs are displayed.

– MBCHER 20 or 03: Overload was detected by MBIE in transmit direction or SCTP association failed because of VM problems. After the VM becomes operable again, re synchronization of the affected MCH is attempted. If re synchronization fails a major alarm for the affected MBIE is issued. If the last MCH of an FPU-E gets con-figured to UNA, the FPU-E becomes NAC.and a critical alarm is issued for the assigned MBIE. The faulty MCHs are displayed.

– MBCHER 40: TRACOL on not synchronized MCH. A CP application has sent col-lective commands for not synchronized MCH. If that MCH is not ACT or STB FA.MCH ignores the MCHCHER. Re synchronization of the ACT /STB MCH is attempted.If re synchronization fails a major alarm for the affected MBIE is issued. If the last MCH of an FPU-E gets configured to UNA, the FPU-E becomes NAC.and a critical alarm is issued for the assigned MBIE. The faulty MCHs are displayed.

– MBCHER FF: If a processor of an M:MBDE fails the MBIC sends an MBDERROR message and MBDCHER messages for all possible FPU-E MCHs of this processor, regardless of their states. MBDCHOFF is sent to the MBD for MCH being not ACT orSTB to stop the repetition of the MBCHER messages. For the other MCH re syn-chronization is attempted. All MCHs which cannot be synchronized, are then switched off. If the last MCH of an FPU-E gets configured to UNA, the FPU-E becomes NAC. On receiving message TRANSRESP the affected MBIE is alarmed: if any FPU-E is in NAC because of the lost MCH a critical alarm is issued. The faulty MCHs are displayed

The reactivation of FPU-E in NAC with UNA MCH and UNA MCH of FPU-E in ACT is triggered by RT:MCH, but FPU-E in UNA have to be configured by MML.

Download of IP addresses of VMThe MBIE must know the IP address of the VM before an SCTP association can be set up. Therefore every time before an MBDCHON is sent from CP for an MCH to an FPU-E, the command MBDIPMAP must be sent. That includes IP addresses of up to eight FPU-Es and the message MBDIPMAPR must be received.

Routining of UNA MCHRT:MCH sends once per minute the command MBDIPTEST for UNA MCH of FPU-E in ACT or NAC to the MBIE. MBIE tries to set up SCTP test associations. On success the test associations are aborted again by the MBIE. RT:MCH waits up to 10 seconds for the message MBDIPTESTR, containing the results. The MCH for which a test associa-tion could be established are configured to ACT /STB by sending the message STAT-TRANS for mass configuration.

Suspect hardwareAffected FPU-E: M:MP480 and LTG or M:FPPxxx with VM). Also suspect are the frames (backplane, connector strip)


1 1, 2, 3 1, 2, 3

2 4, 5, 6, 7 4, 5, 6, 7

3 8, 9, 10, 11 8, 9, 10, 11

Table 22 LTG allocation GPPxx

A30828-Y1187-N510-2-7620

121


Id:0900d805806b9166


For VM (MoPC), Router, PS fault clearance refer to the UMN:SURPASS hiG1600 V2.x


Diagram of frames - module side, backplane and cabling: Construction, Frames MB/CCG or F:IOPMBD.


4.34 MMN:MB245-2000 - MBIECH TOTAL FAULT EQUIPMENT ALARM MMN:MB245-2000 ALARM PRIORITY: @####### PROBABLE CAUSE: LOSS OF SIGNAL SPECIFIC PROBLEM: MBIECH TOTAL FAULT: PLFIF FAILURE MESSAGE NUMBER: @####

4 12, 13, 14, 15 12, 13, 14, 15

5 16, 17, 18, 19 16, 17, 18, 19

6 20, 21, 22, 23 20, 21, 22, 23

7 24, 25 , 26, 27 24, 25 , 26, 27

8 28, 29, 30, 31 28, 29, 30, 31

9 32, 33, 34, 35 32, 33, 34, 35

10 36, 37, 38, 39 36, 37, 38, 39

11 40, 41, 42, 43 40, 41, 42, 43

12 44, 45, 46, 47 44, 45, 46, 47

13 48, 49, 50, 51 48, 49, 50, 51

14 52, 53, 54, 55 52, 53, 54, 55

15 56, 57, 58, 59 56, 57, 58, 59

16 60, 61, 62, 63 60, 61, 62, 63

MBIE MBU LTGSET

0 7 28...31

1 6 24...27

2 5 20...23

3 4 16...19

4 3 12...15

5 2 8...11

6 1 4...7

7 0 0...3

Table 23 Correlation between MBIE number, MBU number and LTGSET


Table 22 LTG allocation GPPxx (Cont.)

122 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


ALARM IDENTIFICATION:

CLASS=MBIECH MBIECH=@###

SUPPLEMENTARY INFORMATION: MBIECH OST MCHC0 MCHC1 ---------------------- @### @## @## @##

System reaction

– Die MCHC and the appropriate MBIE channel (logic connection for the COPL) are configured to UNA



DescriptionFunctional units, PCU or OSP, are realized on Commercial Platforms (COPL) that are connected via LAN to the MBIE. 32 COPLs can be connected per MBIE unit. Each of the 4 Ethernet links at the MBDE serves up to 8 COPLs. Only one OSP can be con-nected to the system. The logical interconnection of a COPL to the MBDE is called MBIECH (message buffer ethernet interface channel). The term MCHC (message channel to COPL) is used for the logical interconnection of a COPL to the MBDE per system/LAN side. A COPL is reachable, if at least one MCHC of its interconnection is active (ACT).The COPL units are administered in the CP. The PCU and OSP will not be configured in the CP, but only their logical interconnections to the MBDE. The units PCU and OSP are configured and alarmed via SNMP.

Fault handlingThe SCTP protocol monitors the connection to the COPL and reports errors with MBD-COMLOS messages to the fault analysis for network connection (FA:NC). FA:NC checks, if the COPL has lost one or both channels. In order to avoid sporadic MCHC faults, an attempt is made to re synchronize the affected MCHCs. If it was not possible to re synchronize at least one of the two message channels, the associated MBIECH is configured to UNA and a fault log with the MMN number MB245-2000 is output.

The hardware structure of the COPL is of no relevance to the CP/MB. The COPL repre-sents one logical object with one logical interface (MBIECH). The logical connection consists of MCHC0 via MBD0/LAN0, MCHC1 via MBD1/LAN1. CP administration and maintenance software does not treat the LAN but only the interfaces. LAN errors are not considered. Since there is no information about the operation state of the COPL in the CP, the state of the MBIECH corresponds to the state of the COPL.

A30828-Y1187-N510-2-7620

123


Id:0900d805806b9166

Figure 14 Physical interconnection MBD/LAN - COPL

Main suspect modulesCOPL: OSP or PCU

If there are multiple MBIECH outages, the LAN is suspect.


Diagram of frames - module side, backplane and cabling: Construction, Frames F:MB/CCG and Construction, Frames F:SN.


MBDE interfacesThe IP addresses are used by the corresponding platforms to send ping-messages to supervise the LAN connection. The MBDE in active state sends ping responses back.

Board number Link number MBD0 MBD1

MBDE0 LINK 0

LINK 1

LINK 2

LINK 3

10.0.110.1

10.0.110.2

10.0.110.3

10.0.110.4

10.128.115.1

10.128.115.2

10.128.115.3

10.128.115.4

MBDE1 LINK 0

LINK 1

LINK 2

LINK 3

10.0.97.1

10.0.97.2

10.0.97.3

10.0.97.4

10.128.105.1

10.128.105.2

10.128.105.3

10.128.105.4

Table 24 MBDE IP addresses

L0

L1

L2

L3

MBDE-0-0

L0

L1

L2

L3

MBDE-1-0

0

1

PCU 1COPL

0

1

PCU 2COPL

0

1

PCU xCOPL

0

1

PCU 3COPL ...

SWITCH0

SWITCH1

124 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


4.35 MMN:MB246-2000 - MBIECH PARTIAL FAULT COMMUNICATION PROTOCOLL ERROR MMN:MB246-2000 ALARM PRIORITY: @####### PROBABLE CAUSE: COMMUNICATIONS PROTOCOL ERROR SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=MBIECH MBIECH=@###

SUPPLEMENTARY INFORMATION: MBIECH OST MCHC0 MCHC1 ---------------------- @### @## @## @##

System response

– The faulty MCHC is configured to UNA and the redundant MCHC is, on condition it was in STB, configured to ACT. The assigned MBIECH remains in ACT

MBDE2 LINK 0

LINK 1

LINK 2

LINK 3

10.0.77.1

10.0.77.2

10.0.77.3

10.0.77.4

10.128.87.1

10.128.87.2

10.128.87.3

10.128.87.4

MBDE3 LINK 0

LINK 1

LINK 2

LINK 3

10.0.64.1

10.0.64.2

10.0.64.3

10.0.64.4

10.128.69.1

10.128.69.2

10.128.69.3

10.128.69.4

MBDE4 LINK 0

LINK 1

LINK 2

LINK 3

10.0.25.1

10.0.25.2

10.0.25.3

10.0.25.4

10.128.59.1

10.128.59.2

10.128.59.3

10.128.59.4

MBDE5 LINK 0

LINK 1

LINK 2

LINK 3

10.0.14.1

10.0.14.2

10.0.14.3

10.0.14.4

10.128.42.1

10.128.42.2

10.128.42.3

10.128.42.4

MBDE6 LINK 0

LINK 1

LINK 2

LINK 3

10.0.15.1

10.0.15.2

10.0.15.3

10.0.15.4

10.128.43.1

10.128.43.2

10.128.43.3

10.128.43.4

MBDE7 LINK 0

LINK 1

LINK 2

LINK 3

10.0.5.1

10.0.5.2

10.0.5.3

10.0.5.4

10.128.33.1

10.128.33.2

10.128.33.3

10.128.33.4

Board number Link number MBD0 MBD1

Table 24 MBDE IP addresses (Cont.)

SPECIFIC PROBLEM MBIECH PARTIAL FAULT: MCHC0 FAILURE

MBIECH PARTIAL FAULT: MCHC1 FAILURE

A30828-Y1187-N510-2-7620

125


Id:0900d805806b9166

– The malfunction will be displayed under object MB as major alarm.– The log will be stored in the history file and entered into the alarm file (AM.ALARM).

Fault handlingAt the MBDE the outage of a message channel is detected by missing heartbeats (after 600 ms) or by failed retransmissions (after 350 ms). The STB MCHC are tested period-ically (ping). A failed MCHC is immediately reported by the MBDE to the CP via MBD-COMLOS messages. The CP maintenance software collects incoming MBDCOMLOS over a period of one second to detect single message channel outages, outage of both MCHCs to a COPL or outages of MCHCs in a whole LAN side. The routine test function tries to activate MCHCs in state UNA via LAN side 0 or LAN side 1 periodically. The time period for routining is approximately 60 sec for all platform types (depending on load sit-uation and process priority). An MB fault log with MMN number MB246-2000 is output in case of single MCHC outage.

The UNA MCHC are scanned periodically, provided the attached MBIECH is not in MBL. Re activation of UNA MBIECH is possible. If both MCHC of an MBIECH are in UNA the associated MBIECH is also in UNA. If both MCHCs to the related MBIECH have been in UNA and at least one of the two MCHCs can be recovered by routining (i.e. ACT), the MBIECH also becomes ACT again. FA:NC maintains a failure rate statistic (leaky bucket counters) for SCTP associations (MBDCOMLOS) and hosts (MBDCOMRES). RT:NC excludes hosts or associations which exceed a failure rate threshold of 10 failures/hour from its reactivation attempts.

The output masks for command DISP MBIECH:MBIECH=X-X shows the type of con-nected unit and the alarm state of the MBIECH.

STAT MBIECH displays the state of the MCHCs and MBIECHs.

The MBIECH cannot be diagnosed by the CP, since the hardware structure of the LAN is unknown to the CP.


Diagram of frames - module side, backplane and cabling: Construction, Frames MB/CCG.


4.36 MMN:MB247-2001 COMMUNICATION TO MG FAILED (MGC INTERNAL) COMMUNICATIONS ALARM MMN:@######### ALARM PRIORITY : CRITICAL PROBABLE CAUSE : @################################################# SPECIFIC PROBLEM: COMMUNICATION TO MG FAILED (MGC INTERNAL) MESSAGE NUMBER : @#### ALARM IDENTIFICATION:

CLASS=MGIF @###############################################

System reaction

– The corresponding MGIF is configured to DST. – The malfunction is indicated under object MB as a critical alarm.– The log is entered into the alarm file (AM.ALARM).

126 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


Description/fault handlingThe MG is connected either to two MGI units or to two PCUs. An even number of PCUs must exist in the system. PCUs with index no. odd and index no. even form a pair. Every MG is assigned to a PCU pair. The routine test by MGIF Maintenance sends cyclical AUEP (Audit Endpoint) messages to all MGs. If an MG fails several times to respond to these messages, the MGC (media gate control) assumes that the MG is no longer avail-able via this path: If the second path has also failed at this time, MGIF Maintenance detects MGIF failure. The MGIF is configured to DST.

Determine the type of MG. Check if there are alarm messages for the MG. The following types are possible hiG 1200, hiG 1100, hiR 200 or hiR 220. Continue fault clearance with the help of the appropriate documentation.

If there are no alarm messages continue with UMN:hiE 9200.

4.37 MMN:MB247-2002 COMMUNICATION TO MG FAILED (MGC EXTERNAL) COMMUNICATIONS ALARM MMN:@######### ALARM PRIORITY : CRITICAL PROBABLE CAUSE : @################################################# SPECIFIC PROBLEM: COMMUNICATION TO MG FAILED (MGC EXTERNAL) MESSAGE NUMBER : @#### ALARM IDENTIFICATION:

CLASS=MGIF @###############################################

System reaction

– The corresponding MGIF is configured to DST. – The malfunction is indicated under object MB as a critical alarm.– The log entered into the alarm file (AM.ALARM).

Description/fault handlingThe MG reports its failure by sending an RSIP (Restart in Progress) message. The message is sent for all PCM trunks involved with this MG. MGI Control informs MGIF Maintenance in the CP. If the second path has also failed at this time, MGIF Mainte-nance detects MGIF failure. The MGIF is configured to DST.

Determine the type of MG. Check if there are alarm messages for the MG. The following types are possible SURPASS hiG 1200, SURPASS hiG 1100, SURPASS hiR 200 or SURPASS hiR 220. Continue fault clearance with the help of the appropriate documen-tation.


4.38 MMN:MB247-2003 - MGCP VERSION MISMATCH COMMUNICATIONS ALARM MMN:@######### ALARM PRIORITY : CRITICAL PROBABLE CAUSE : @################################################# SPECIFIC PROBLEM: MGCP VERSION MISMATCH MESSAGE NUMBER : @#### ALARM IDENTIFICATION:

CLASS=MGIF @###############################################

A30828-Y1187-N510-2-7620

127


Id:0900d805806b9166

System reaction


Description/fault handlingThe MGCP commands contain an entry specifying the protocol version, so that the receive side can check whether the partner is operating with the same protocol version. If the protocol versions are different, error-free communication cannot be guaranteed. MGI Control informs MGIF Maintenance in the CP of the error. If the second path has also failed this time, MGIF Maintenance detects MGIF failure. The MGIF is configured to DST.

Determine the type of MG. Check if there are alarm messages for the MG. The following types are possible SURPASS hiG 1200, sURPASS hiG 1100, SURPASS hiR 200 or SURPASS hiR 220. Continue fault clearance with the help of the appropriate documen-tation.


4.39 MMN:MB247-2004 - MGC INTERNAL SOFTWARE ERROR @######################## MMN:@######### ALARM PRIORITY : @####### PROBABLE CAUSE : @################################################# SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER : @#### ALARM IDENTIFICATION:

CLASS=MGIF @###############################################

System reaction


Description/fault handlingThe MGIF did not react during initialization. A software error occurred during initializa-tion of the MGIF, or the MGIF has not been installed.

4.40 MMN:MB230-2000 - ERROR MESSAGEShould a serious fault occur in the MB during a configuration measure (this can also be a configuration measure within a called up diagnosis) it cannot be dealt with by the fault handling program for the MB (= FA:MB). In this case, the system gives an ERROR MESSAGE with references and further information about the specified fault, if required.

Two types of error messages are distinguished for the MB:

MBD ERROR MESSAGE DURING CONFIGURATIONShould a timer expire during a configuration measure in the CP and the configuration could not be carried out successfully, the configuration task is rejected and the following ERROR MESSAGE output:

128 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


ERROR MESSAGE DURING CONFIGURATION OF MBxx-mb-mbxx MB230-2000 xxxxxxxxxxxxxxxxxxxxxxxxxxx

The configuration is then rejected with a command repetition and the reason HARDWARE FAULT

The MMN number MB230 output in the ERROR MESSAGE can be used to enter fault clearance if the configuration task was given outside an MMN fault clearance procedure. This MMN number must be ignored within a fault clearing procedure!

Instead of xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx a keyword refers to the cause of the fault.

The different keywords refer to these causes of faults: • NO REACTION TO RESTART OF MBIC

For this fault pattern, the RESTART signal was sent successfully at the interface between the IOP:MB and the MBIC concerned. However, the ready message MBDREADY or the error message MBDERROR failed to appear. Therefore, CP decides, after the timer has expired, that the MBIC is not operable. Because there are no fault indications other than the messages which failed to appear, byte-coded fault information can also not be output for this fault pattern. The message MBDREADY as confirmation of a successfully running RESTART is a prerequisite both for the configuration of the MB side to ACT and the start of the diagnosis. The message cannot be sent in both cases for the fault pattern described here.The following are suspect modules here:– Module MBDC – The modules of the appropriate IOP:MB and the cables between the MBDC and

the IOP:MBCross references: Diagram of the MB Racks and the associated fuses: Construction, Racks. Diagram of the Frames and wiring: Construction, Frames F:MB/CCG.

• NO REACTION TO RESTART OF MBIH/NO REACTION TO RESTART OF MBIAFor this fault pattern, the RESTART signal was sent successfully at the interface between the MBIC and the MBIH or MBIA concerned. However, the ready message MBDREADY or the error message MBDERROR failed to appear. The CP decides therefore, after the timer has expired, that the MBIH or MBIA is not operable. Because there are no fault indications other than the messages which failed to appear, byte-coded fault information can also not be output for this fault pattern. The message MBDREADY as confirmation that RESTART is running successfully is a prerequisite both for the configuration of the MBIH or the MBIA to ACT and for the start of diagnosis. The message cannot be sent in both cases for the fault pattern described here.The following are suspect areas here:– Module MBDH or MBDA – MBDC and the cable between the MBDC and the MBDH or the MBDACross references: Diagram of the MB Racks and the associated fuses: Construction, Racks. Diagram of the Frames and wiring: Construction, Frames F:MB/CCG.

• NO REACTION FROM MBICFor this fault pattern, the RESTART signal was sent successfully at the interface between the IOP:MB and the MBIC. However, the ready message failed to appear. The CP decides therefore, after the timer has expired, that the MBDC is not operable because the memory cannot be loaded with the module states, message channel distribution and IOP allocation. Because there are no fault indications other than the message which failed to appear, byte-coded fault information can also not be output for this fault pattern. The message MBDREADY as confirmation that RESTART is

A30828-Y1187-N510-2-7620

129


Id:0900d805806b9166

running successfully is a prerequisite both for the configuration of the MB side to ACT and the start of the diagnosis. The message cannot be sent in both cases for the fault pattern described here.If this message is output during configuration of an MBIE, check the HW/FW status of module MBDC. It is possible that the FW of module MBDC is of an earlier version and does not consider the unit MBIE.The following are suspect areas here:– Module M:MBDC– The modules of the appropriate IOP:MB – Cables between the MBDC and the IOP:MBCross references: Diagram of the MB Racks and the associated fuses: Construction, Racks. Diagram of the Frames and wiring: Construction, Frames F:MB/CCG.

• MB FAULTAn unexpected MBDERROR or MBDREADY message was received by the CP. The configuration is then aborted The following are suspect areas here:– The module allocated to the corresponding unit – The modules of the appropriate IOP:MBCross references: Diagram of the MB Racks and the associated fuses: Construction, Racks. Diagram of the Frames and wiring: Construction, Frames F:MB/CCG.

• NO LOOP RESPONSEDuring the LOOP test at the end of configuration the timer expired before an MBU list which has not yet been allocated was recorded into the scan cycle.The following are suspect areas here:– The module allocated to the corresponding unit– The modules of the appropriate IOP:MB– Cable to the IOP:MBCross references: Diagram of the MB Racks and the associated fuses: Construction, Racks. Diagram of the Frames and wiring: Construction, Frames F:MB/CCG.

• XLINK FAULTActivation of the cross link for the partner module was impossible. If an MEGCG message with a reference to the PLL was sent in the partner module, the error message is output with the processor number of the MBIC partner otherwise with the processor number of the corresponding MBIH or MBIACross references: Diagram of the MB Racks and the associated fuses: Construction, Racks. Diagram of the Frames and wiring: Construction, Frames F:MB/CCG.The following are suspect modules here:– The module allocated to the corresponding unit – The partner module– Cables between the modules concerned

• MEGCG FAULTMessage MEGCG refers to an 8/50 MHz clock fault in the MB side for which the con-figuration task was given. This message is output with the pseudo-processor number of this side. For a 50 MHz PLL fault on the partner side, the error message is output both with the processor number of the partner module and an alarm.The following are suspect areas here:– MBDCG – The master CCG

130 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805806b9166


– Clock supply cable from the CCG to the MBDCGCross references: Diagram of the MB Racks and the associated fuses: Construction, Racks. Diagram of the Frames and wiring: Construction, Frames F:MB/CCG.

• FW FALLBACKMessage MBDREADY received from the CP contains a reference that the module belonging to the unit to be configured must activate the backup firmware for suc-cessful booting. The configuration is then abortedThe following module is suspect here:– The module allocated to the corresponding unitCross references: Diagram of the MB Racks and the associated fuses: Construction, Racks. Diagram of the Frames and wiring: Construction, Frames F:MB/CCG.

• OSML INCOMPATIBLE TO MBU TYPEThe configuration program tests the exchange-specific length of the message before the unit is activated. The configuration is aborted if 32 is entered for the OSML (office specific message length).An error message is output with one of these keywords if the MB type cannot be dif-ferentiated because of a defect in the MBU. The type identification of the MBU must be determined and stored in the database because an MB of the MBB type can transmit messages up to a length of 128 bytes whereas an MB of the MBA type can only transmit messages up to a length of 32 bytes. An MB of the MBD type transmits messages with a length of 128 bytes. The type identification is H’03.

• WRONG MODULE TYPE (MBIH/MBIE)MBDREADY message contains the module type MBDH or MBDE. If MBDREADY contains a different module time as stored in the data base, configuration is aborted. In this case check MOLOC and module type. Command DISP MB requests a list of the MBIE stored in the data base. Command MOD MB, parameter NUMMBIE administers the number of MBIEs created in the data base.Cross references: Diagram of the MB Racks and the associated fuses: Construction, Racks. Diagram of the Frames and wiring: Construction, Frames F:MB/CCG.

A30828-Y1187-N510-2-7620

131

NM:MB Interpretation of the MBB Fault Messages

Id:0900d805801951fe

5 Interpretation of the MBB Fault Messages

5.1 MBB - IO Processor NumbersThe IO processor number of the device or unit concerned is specified as a double byte in the SUPPLEMENTARY INFORMATION of the fault message. The CP uses the IO processor number to address the processor for the corresponding unit in the periphery.

5.2 MMN:MB110-1002 - NO LOOP RESPONSE MB FAILURE WITH CONFIGURATION MMN:MB110-1002 NO LOOP RESPONSE FAULT LOCATION: @######### @############ CONFIGURATION: @######### FROM: @## TO: @## SUPPLEMENTARY INFORMATION: H’aabbcczz 0000dddd zzeezzzz zzzzzzzz

IO processor numbers associated MB units

hexadecimal decimal

0C 1C

0C 21

0C 26

0C 2B

0C 30

0C 35

0C 3A

0C 3F

3100

3105

3110

3115

3120

3125

3130

3135

MBUS-0-0

MBUS-1-0

MBUS-0-1

MBUS-1-1

MBUS-0-2

MBUS-1-2

MBUS-0-3

MBUS-1-3

0C E4

0C E9

0C EE

0C F3

0C F8

0C FD

0D 02

0D 07

0D 0C

0D 11

0D 16

0D 1B

0D 20

0D 25

0D 2A

0D 2F

3300

3305

3310

3315

3320

3325

3330

3335

3340

3345

3350

3355

3360

3365

3370

3375

MBUL-0-0

MBUL-1-0

MBUL-0-1

MBUL-1-1

MBUL-0-2

MBUL-1-2

MBUL-0-3

MBUL-1-3

MBUL-0-4

MBUL-1-4

MBUL-0-5

MBUL-1-5

MBUL-0-6

MBUL-1-6

MBUL-0-7

MBUL-1-7

Table 25 MB processor numbers

132 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805801951fe

Interpretation of the MBB Fault Messages

H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz

Byte interpretation • aa: Origin of the message

• bb: Code for the detected fault behavior

• cc: Reporting software-unit

• dddd: Processor number of the affected unit see 5.1 MBB - IO Processor Numbers • ee: Classification of the detected fault

• z..z: These bytes are not occupied. Entries not equal to 0 are also irrelevant.

Reason/fault explanationAn MB fault message with the MMN number MB110-1002 is output,a) when the periodic test command LOOP has been correctly output to the MBU

affected but no return of the test pattern (with the message RELOOP) is made by the MBU within the specified time. The appropriate procedure of the routine test for the MB (part of the CP software) reports this to the FA:MB. The FA:MB takes the affected MBU out of service, i.e. it configures the MBU to UNA. (Byte ee = 00). The command LOOP will only be sent to MB units with redundancy concerning MB, SN and MUXM.

b) when the routine test establishes that an occupied or partly occupied output list can no longer be read by the IOP:MB or when the exchange of information via the B:MBG interface with the affected MBU is faulty or impossible. The appropriate pro-cedure of the routine test for the MB (part of the CP software) reports this to the FA:MB. The FA:MB tests whether redundancy exists for this MBU. If this is the case, it takes the affected MBU out of service, i.e. it configures the MBU to UNA. (Byte ee = 01). ISTART1 is performed if the configuration to UNA will lead to loss of a pair of TSGs or MUXMs.

Modules mainly suspect

Other suspect modulesHere all further modules M:MDM in the module frame with the affected MBU are addi-tionally suspect -- they all have access to the bus B:MBG of this message buffer group.

Also suspect are

– The power supply (voltage converter, main fuses) of the affected MBU (of the affected MB).

0F SGMES (Safe Guarding Monitor)

26 non arrival of the RELOOP (SG-NO-RELOOP)


00 no loop response within the specified time

01 stuck output/transfer list

MBU:LTG: M:IOPC and M:CG/MUX in the module frame with the affected MBU. M:MDM in the affected MBU

MBU:SGC M:IOPC (= the affected MBU:SGC) and M:CG/MUX in the module frame with the affected MBU

A30828-Y1187-N510-2-7620

133


Id:0900d805801951fe

– The cable between MB and IOP:MB as well as the modules connected in the IOP:MB (output stages).

– The module frames (back plane, connector strip) with the affected MBU and asso-ciated IOP:MB.

Cross-referencesLayout of racks with MB and associated fuses: Construction, Racks

Layout of frames - module side, backplane and cabling: Construction, Frames MB/CCG

Comments/notesAfter a recovery ISTARTx or NSTART3, the first LOOP command is given to the MBU only after 5 minutes after the process start have elapsed (system stabilization).

The command LOOP will only be sent to MB units with redundancy concerning MB, SN and MUXM. With the command LOOP, all ACT MBU:SGCs are tested. An MBU:LTG is only tested when it is in ACT and if the assigned TSG is in ACT or STB, i.e. in normal operation LOOP goes to all ACT MBU.

The command LOOP is output and evaluated by the MB routine test. The MB routine test forms part of the safeguarding software in the CP and therefore helps to guarantee the proper function of the MB.

The command LOOP is periodically output every twenty seconds to each MBU to be tested. If the message RELOOP does not arrive for an MBU within 3 seconds, the LOOP command is repeated and RELOOP is given 6 seconds to arrive. If RELOOP still does not arrive, the affected MBU is conditionally deactivated (i.e. the MBU is only configured to UNA if redundancy exists).

If, during a test cycle (= a command LOOP to each MBU to be tested) of more than one MBU, the RELOOP messages do not arrive, or if the call processing input list has more than 300 occupied places, a route problem is assumed and no fault handling is started.

5.3 MMN:MB110-1003 - MUTILATED LOOP RESPONSE MB FAILURE WITH CONFIGURATION MMN:MB110-1003 MUTILATED LOOP RESPONSE FAULT LOCATION: @######### @############ CONFIGURATION: @######### FROM: @## TO: @## SUPPLEMENTARY INFORMATION: H’aabbcczz 0000dddd zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz

Byte interpretation • aa: Origin of the message

• bb: Code for the detected fault behavior

• cc: Reporting software-unit


26 non arrival of the RELOOP (SG-NO-RELOOP)


134 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805801951fe


• dddd: Processor number of the affected unit, see 5.1 MBB - IO Processor Numbers • z..z: These bytes are not occupied. Entries not equal to 0 are also irrelevant.

Reason/fault explanationAn MB fault message with the MMN number MB110-1003 is output when the periodic test command LOOP is correctly output to the affected MBU and answered by return of the test pattern (with the message RELOOP) within the specified time. On comparison of the RELOOP pattern with the originally output LOOP pattern, pattern corruption was detected or the pattern was incompletely returned. The appropriate MB routine test pro-cedure (part of the CP software) reports this to the FA:MB. The FA:MB then removes the MBU in question from service, i.e. it configures the MBU to UNA. The command LOOP will only be sent to MB units with redundancy concerning MB, SN and MUXM.

Modules mainly suspect

Other suspect modulesM:CG/MUX in the module frame with the affected MBU.

Also suspect isThe module frame (back plane, connector strip)



Comments/notesAfter a recovery ISTARTx or NSTART3, the first LOOP command is given to the MBU only after 5 minutes after the process start have elapsed (system stabilization).

The command LOOP will only be sent to MB units with redundancy concerning MB, SN and MUXM. With the command LOOP, all ACT MBU:SGCs are tested. An MBU:LTG is only tested when it is in ACT and if the assigned TSG is in ACT or STB, i.e. in normal operation LOOP goes to all ACT MBU.

The command LOOP is output and evaluated by the MB routine test. The MB routine test forms part of the safeguarding software in the CP and therefore helps to guarantee the proper function of the MB.

The command LOOP is periodically output every 20 seconds to each MBU to be tested.

If the test pattern with the message RELOOP is returned within the defined time, it is compared with the originally output pattern by the MB routine test. If RELOOP receives a corrupted or incomplete pattern, the command LOOP is repeated to the affected MBU. If the MB routine test also detects a corrupted test pattern during the repetition, the MBU in question is deactivated.

MBU:LTG: M:IOPC and M:CG/MUX in the module frame with the affected MBU. M:MDM in the affected MBU

MBU:SGC M:IOPC (= the affected MBU:SGC) and M:CG/MUX in the module frame with the affected MBU

A30828-Y1187-N510-2-7620

135


Id:0900d805801951fe

5.4 MMN:MB110-1004 - MBU ERROR MB FAILURE WITH CONFIGURATION MMN:MB110-1004 MBU ERROR FAULT LOCATION: @######### @############ CONFIGURATION: @######### FROM: @## TO: @## SUPPLEMENTARY INFORMATION: H’aabbcccc ddeezzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz

Byte interpretation • aa: Origin of message

• bb: classification of the message

• cccc: Processor number of the affected unit see 5.1 MBB - IO Processor Numbers • dd: Classification of the detected fault

• ee: Detailed fault information - for an MBU:SGC

M:IOPC is suspect in all this cases • ee: Detailed fault information for an MBU:LTG

06 call processing periphery (EAVT)

0C a fault was detected in the MBU (MB-MBUER)

04 MB ONLINE FAULT detected by one of the active steps of the routine test

01 A fault was detected during the EPROM test on the module IOPC, i.e. the counted sum of the stored bytes did not agree with the stored check figure (routine test and diagnosis both use the same test procedure in this instance.

02 A fault was detected during the RAM test on the IOPC module, i.e. either the read or write capability of the memory is not guaranteed (routine test and diag-nosis both use the same test procedure in this instance).

03 Test loops are looped through via both HSCC chips by the processor as part of the routine test. One of the test patterns output with these loops was not returned correctly or was not returned at all within the defined time limit. The HSCC in questions therefore suspect.

136 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805801951fe


Also suspects the associated MB module frame (backplane, connector strip) • z..z: These bytes are not occupied. Entries not equal to 0 are also not relevant.



Cause/fault explanationAn MB fault message with the MMN number MB110-1004 is output when the internal on-line routine test of the MBU in question independently detects a fault/fault behavior. The affected MBU reports this to the FA:MB. The FA:MB tests whether redundancy exists for this MBU. If this is the case, it takes the MBU concerned out of operation, i.e.

01 During testing of one of the 10 EPROMs in the MBU:LTG a fault was detected, i.e. the sum of the stored bytes did not correspond to the stored bytes (routine test and diagnosis use the same test procedure). Suspect modules: M:T/RC0, M:T/RC1, M:T/RC2, M:T/RC3, M:MDM

02 During testing of one of the 10 RAMs in the MBU:LTG a fault was detected, i.e. either the read or write capability of the memory is not guaranteed (routine test and diagnosis use the same test procedure). Suspect modules: M:T/RC0, M:T/RC1, M:T/RC2, M:T/RC3, M:MDM

04 Test loops are looped over the two "function units for controlling the message channels" on the module T/RC-0 from the MDI processor during the routine test. One of the test patterns output with these loops was not correctly returned or not returned at all within the specified time limit. The HSCC chip in question is therefore suspect. Suspect modules: M:T/RC-0, M:MDM




40 The control for the module MDM is sectioned into a transmission side (TX) and a receive side (RX). The TX and RX sides have a mutual interface (2 FIFOs) which are tested using test loops as part of the routine test. One of the test patterns output with these loops was not correctly returned or was not returned at all within the specified time limit. The internal interface of module MDM is therefore suspect.

A30828-Y1187-N510-2-7620

137


Id:0900d805801951fe

it is configured to UNA. If no redundancy exists for the MBU in question: see MBB Fault Message with the Code Word: MBU ERROR

The internal routine test in the MBUs needs not be invoked by the user, but rather they run parallel (endless loop) without impairing the call processing traffic. The internal MB routine test concentrates on the central parts of the MBU. The main testing is of all RAM and ROM chips in the affected MBU, the internal MBU bus system and the internal inter-face between the input and output sides of module MDM. The actions in the RAM and ROM tests are identical to the MB diagnosis test steps (see 3 Interpretation of the MBB Diagnosis Results). The internal MB routine test is assigned a low priority as standard procedure. If, as a result of the system load, these tests are not activated within a spec-ified period of 400 ms, the highest priority is dynamically assigned to the test routines. For actions with the highest priority, only one line is tested for each test step with RAMs while only 16 lines are tested for ROMs. If a faulty behavior is detected during a test cycle, the routine test stores this test result and initiates a repetition of the complete test sequence. On confirmation of the fault, an error message of format MBUER (= MBU error) is sent to the CP.

5.5 MMN:MB110-1005 - MESSAGE BUFFER ALARM @########################## MMN:@######### STATUS OF PERIPHERAL PROCESSOR UNIT CHANGED DURING SYSTEM-RECOVERY UNIT : @############# OLD STATUS : @## NEW STATUS : @##

Cause/fault explanationAn MB fault message with the MMN number MB110-1005 is output if the CP detects that the operating state of the MBU in question changed during a previous system recovery (initial start). This fault message can therefore only occur immediately after a system start (initial start). It signifies that the affected MBU showed no fault behavior before the recovery but that it signalled no (complete) operation capability at the end of the restart. The FA:MB then removes the MBU concerned from operation, i.e. it is configured to UNA.

As either no information or only corrupted information exists, fault bytes are also not output in this case. More details on the type of fault can only be obtained using the diag-nosis (see document DIAG:MBB).

Due to the unusual situation (a newly detected fault after a system recovery), the standard FA:MB fault handling cannot be applied here.

5.6 MMN:MB110-1006 - EXCESSIVE MBU RESETS MB FAILURE WITH CONFIGURATION MMN:MB110-1006 EXCESSIVE MBU RESETS FAULT LOCATION: @######### @############ CONFIGURATION: @######### FROM: @## TO: @## SUPPLEMENTARY INFORMATION: H’aabbcccc zzzzzzzz zzzzzzzz zzzzzzzz

138 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805801951fe


H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz



• cccc: Processor number of the affected unit see 5.1 MBB - IO Processor Numbers • z..z: These bytes are not occupied. Entries not equal to 0 are also not relevant.

Cause/fault explanationAn MB fault message with the MMN number MB110-1006 is output, if an MBU:SGC is reset again during handling of a previous reset (synchronizing of SN-MCH by FA:SN) or within 10 minutes after completion of a reset handling (MBMBUER repetition). The affected unit is configured to UNA unconditionally.The configuration does not take place immediately, however, if a configuration order has already been sent for the unit, or if the synchronization via FA:SN is still active. In these cases the MBMBUR message rep-etition is stored.In the first case, the MBMBUR repetition is ignored if configuration to UNA was successful, because the unit has already been taken out of service. In the case of a conditional disconnection, however, if the configuration is rejected an uncon-ditional (second) configuration order is initiated as a result of the MBMBUR repetition.In the second case, irrespective of the result of the synchronization attempt, when the acknowledgement is received from FA:SN unconditional configuration is initiated due to the MBMBUR repetition.

Modules mainly suspectModule M:IOPC (the affected MBU:SGC) and M:CG/MUX in the module frame with the MBU:SGC concerned.

Other suspect modules

Also suspect are

– The power supply (voltage converter, fuse) of the affected MBU:SGC.– The connecting cable(s) between the SN and the affected MBU:SGC.– The module frames (backplane, connector strip) in MB and SN containing the faulty

unit.



Layout of frames - module side, backplane and cabling: Construction, Frames SN


0B MB-MBUR last message MBU READY due to spontaneous resetting of MBU:SGC

in SN: LIM, SGC in the affected SN (unit)

in SNB: SGCB in the affected SN (unit)

in SNDB: MUXC in the affected SN-side

A30828-Y1187-N510-2-7620

139


Id:0900d805801951fe

5.7 MMN:MB110-1007 - RESYNCHRONIZATION FAILURE MB FAILURE WITH CONFIGURATION MMN:MB110-1007 RESYNCHRONIZATION FAILURE FAULT LOCATION: @######### @############ CONFIGURATION: @######### FROM: @## TO: @## SUPPLEMENTARY INFORMATION: H’aabbcccc zzzzzzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz



• cccc: Processor number of the affected unit see 5.1 MBB - IO Processor Numbers • z..z: These bytes are not occupied. Entries not equal to 0 are also not relevant.

Cause/fault explanationIf an MBU is reset spontaneously (i.e. not as a result of configurations) FA:MB receives the MBMBUR message from the MB. If the MBU affected is an MBU:SGC, FA:MB requests from the FA:SN re synchronization of the available MCHs to the associated SN units. (An SN-MCH is considered available when the associated SN unit is ACT or STB and FA:SN has not yet initiated a configuration for this unit.)

Since each connected SGC is connected with the MBU:SGC by means of an MCH, a maximum of 3 MCHs are affected.

The acknowledgement from FA:SN to FA:MB indicates whether it was possible to syn-chronize all, some or none of the available MCHs. If none of the available MCHs can be synchronized, the FA:MB takes the affected MBU:SGC conditionally out of service and a fault report with the MMN number MB110-1007 is issued. If there is no redundant unit, the configuration is rejected and an ISTART1 is initiated. If the last ISTART was less than 45 minutes ago, the affected MBU:SGC is configured to UNA unconditionally in order to avoid rolling recoveries.

Modules mainly suspectM:IOPC (the affected MBU:SGC)

Other suspect modules and cablesIf only one SN unit is connected to the MBU:SGC concerned, e.g. reduced capacity or SN(31...63LTG), the LIM and SGC modules or module SGCB for SNB in the connected SN unit and the cable between MBU:SGC and the SN unit are suspect. For SND in B-Mode module MUXC containing the SN unit and the cables between MUXC and MBU:SGC are suspect.

Also suspect are

– The power supply (voltage converter, fuse) of the affected MBU:SGC.


0B MB-MBUR last message MBU READY due to spontaneous resetting of MBU:SGC

140 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805801951fe


– The module frames (backplane, connector strip) in MB and SN containing the faulty unit.



Layout of frames - module side, backplane and cabling: Construction, Frames SN

5.8 MMN:MB PR:MB - EQUIPMENT ALARM DEFAULT @####################### MMN:@######### ORIGINAL ALARM MESSAGE WAS LOST. ALARM PRIORITY: @####### PROBABLE CAUSE: @################################################# SPECIFIC PROBLEM: @################################################# MESSAGE NUMBER: @#### ALARM IDENTIFICATION:

CLASS=yyyy @#######@@##### UNITNO=mb-mbux

Explanation of the output mask:This substitute message is output if during the preceding system start (or new start), an MBU fault was detected with the result that the unit could not be activated and the actual error message was lost. Since no other information is available, the malfunction of the MBU must be analyzed again. The procedure PR:MB in MMN:MB refers to the correct fault clearance procedure for each fault.

5.9 MBB FAILURE WITHOUT CONFIGURATIONA fault message or an information without configuration is output:– When the self-supervision of the MBU detects a plausibility fault (not a severe fault).– If the redundant MBU is already UNA or MBL and the fault detected by the routine

test is not serious.– If the fault is detected in the group clock generator, since the fault is probably not in

the MBU.

Despite the fault the MBU is not removed from service; it remains in ACT.

MBB Fault Message with the Code Word: MBU ERRORMB FAILURE WITHOUT CONFIGURATION MBU ERROR FAULT LOCATION @######### @############ SUPPLEMENTARY INFORMATION: H’aabbcccc ddeezzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz


• bb: classification of the message06 call processing periphery (EAVT)

A30828-Y1187-N510-2-7620

141


Id:0900d805801951fe

• cccc: Processor number of the affected unit: see 5.1 MBB - IO Processor Numbers • dd: Classification of the detected fault


• z..z: These bytes are not occupied. Entries not equal to 0 are also not relevant.

For dd = 02 (Plausibility fault) the following applies: • Interpretation of Byte ee for an MBU:SGC

M:IOPC is suspect in all this cases. Also suspect is the associated module frame Cross-references: Layout of racks with MB and associated fuses: Construction, Racks. Layout of frames - module side, backplane and cabling: Construction, Frames MB

• Interpretation of Byte ee for an MBU:LTG

0C A fault was detected in the MB or in an MBU (MB-MBUER)

02 MB CONT FAULT detected by plausibility/MB self-supervision

04 MB ONLINE FAULT detected by one of the active steps of the routine test

The interpretation of the byte ee varies for MBU:LTG and MBU:SGC and is also dependent in each case on the contents of byte dd. For more information, see the following tables (arranged according to dd = 02 or 04 and MBU type.

01 An incorrect jobcode 2 was detected for an MBU command (which the MBU should execute. Contrary to this are the much more frequent messages which only have to be transferred by the MBU).

02 An incorrect length was detected for a message with format CHON, CHOFF, TEST or TRASIN.

CHON: command to the MBU:SGC to activate a specific message channel.

CHOFF: command to the MBU:SGC to deactivate a specific message channel.

TEST: command to the MBU:SGC to initiate a specific diagnosis test function.

TRASIN: A message to the MBU:SGC to be transferred to one of the connected switching group controls SGC.

04 For a message of format TRASIN or for an MBU command an incorrect channel number was given as the destination MCH, i.e. a channel number not equal to 2, 4, 6 or 81.

TRASIN: A message to the MBU:SGC to be transferred controls SGC.

MBU command: command which the MBU should execute. Contrary to this are the much more frequent messages which only have to be transferred by the MBU.

10 An AUDIT has detected a fault. This indicates a fault in the MBU:SGC firmware. Audits generally check the logical structure and operation of the firmware routines in the MBU.

01 An incorrect jobcode 2 was detected for an MBU command (command which the MBU should execute). Contrary to this are the much more frequent messages which only have to be transferred by the MBU).

Suspect modules: M:MDM, M:IOPC, M:CG/MUX

142 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805801951fe


Cross-references

Layout of racks with MB and associated fuses: Construction, Racks


Cause/fault explanation

This fault message is output when the self-supervision of the affected MBU indepen-dently detects a fault/fault behavior. It is not a severe fault, the MBU is not removed from service.

Using the routines in the self-supervision, the MBU interfaces and consequently the interface modules are primarily supervised. At interface B:MBG of the MBU to the IOP:MB, this is achieved by the supervisory mechanism of the handshaking procedure. MBU and IOP:MB mutually check each other during the process. Mechanisms for checking include:– Correct adherence to the transfer message with the various control signals.– Constant interrogation (scanning) with defined replies corresponding to the dialog

plan. – Each transferred byte is checked by means of a parity bit. – Each transferred message is tested by a length specification and length check

(length = number of transferred message bytes).

At the interfaces SDC:TSG or SDC:SGC to the LTGs or to the SN, the self-supervision is accomplished using the supervisory mechanisms of the HDLC procedure. The MBU and LTG/SN mutually check each other. Mechanisms for checking include:– Acknowledgment of every transferred message– A parallel transferred checksum byte– Numbering of the transferred messages– Time supervision of the message traffic

02 An incorrect length was detected for a message of format BROAD, BREND, CHON, CHOFF, TEST or TRASIN.

BROAD: command to the MBU:LTG to prepare the broadcasting operation.

BREND: command to the MBU:LTG to end the broadcasting operation.

CHON: command to the MBU:LTG to activate a specific message channel.

CHOFF: command to the MBU:LTG to deactivate a specific message channel.

TEST: command to the MBU:LTG to initiate a specific diagnosis test function

TRASIN: A message to the MBU:LTG to be transferred to one of the connected LTGs. Suspect modules: M:MDM, M:IOPC, M:CG/MUX

04 For a message of format TRASIN or for an MBU command an incorrect channel number was given as the destination MCH, i.e. a channel number 0, an uneven channel number less than 127 or one greater than 145.

TRASIN: A message to the MBU:SGC to be transferred to one of the connected LTGs. MBU command: command which the MBU should execute. Contrary to this are the much more frequent messages which only have to be transferred by the MBU. Suspect modules: M:MDM, M:IOPC, M:CG/MUX

08 The receive FIFOs (RX-FIFOs) on the T/RC modules of the affected MBU:LTG cannot be emptied (i.e. the MDI processor cannot access these FIFOs via the B:MBG). Suspect modules: M:MDM, M:T/RC0, M:T/RC1, M:T/RC2, M:T/RC3

A30828-Y1187-N510-2-7620

143


Id:0900d805801951fe

For dd = 04 the following applies • ee: Detailed fault information for an MBU:SGC

M:IOPC is suspect in all these cases. Cross-references: Layout of racks with MB and associated fuses: manual Construction, Racks. Layout of frames - module side, backplane and cabling: manual Construction, Frames MB/CCG

• ee: Detailed fault information for an MBU:LTG

01 A fault was detected during the EPROM test on the module IOPC, i.e. the counted sum of the stored bytes did not agree with the stored check figure. (routine test and diagnosis both use the same test procedure in this instance.)

02 A fault was detected during the RAM test on the IOPC module, i.e. either the read or write capability of the memory is not guaranteed (routine test and diag-nosis both use the same test procedure in this instance).

03 Test loops are looped through via both HSCC chips by the processor as part of the routine test. One of the test patterns output with these loops was not returned correctly or was not returned at all within the defined time limit. The HSCC in question is therefore suspect.

144 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805801951fe


Also suspect is the associated MB module frame (backplane, connector strip). Cross-references: Layout of racks with MB and associated fuses: manual Construc-tion, Racks. Layout of frames - module side, backplane and cabling: manual Con-struction, Frames MB/CCG


This MB fault message is output when the internal on-line routine test of the affected MBU independently detects a fault/fault behavior. The MBU in question reports this to the FA:MB. The FA:MB tests if redundancy exists for this MBU. This is not the case here! Deactivation or failure of this MBU would therefore cause partial failure of the system (total failure in net nodes with SN (31...63LTG)) because no more messages can be exchanged between the CP and the system periphery (assigned to this MBU).

The FA:MB therefore foregoes deactivation of the MBU concerned in this case. The device remains in ACT and the fault is only displayed.

Caution

01 During testing of one of the 10 EPROMs in the MBU:LTG a fault was detected, i.e. the sum of the stored bytes did not correspond to the stored checksum (routine test and diagnosis use the same test procedure). Suspect modules: M:T/RC0, M:T/RC1, M:T/RC2, M:T/RC3, M:MDM

02 During testing of one of the 10 RAMs in the MBU:LTG a fault was detected, i.e. either the read or write capability of the memory is not guaranteed (routine test and diagnosis both use the same test procedure here). Suspect modules: M:T/RC0, M:T/RC1, M:T/RC2, M:T/RC3, M:MDM

04 Test loops are looped over the two "function units for controlling the message channels" on the module T/RC-0 from the MDI processor during the routine test. One of the test patterns output with these loops was not correctly returned or not returned at all within the specified time limit. Suspect modules: M:T/RC-0, M:MDM




40 The control for the module MDM is sectioned into a transmission side (TX) and a receive side (RX). The TX and RX sides have a mutual interface (2 FIFOs) which are tested using test loops as part of the routine test. One of the test patterns output with these loops was not correctly returned or was not returned at all within the specified time limit. Suspect modules: M:MDM

A30828-Y1187-N510-2-7620

145


Id:0900d805801951fe

This fault message is admittedly only an indication of the possible failure of an MBU - however it signifies the utmost danger at the same time because of the lack of redun-dancy: Faultless exchange of messages between the CP and periphery is immediately no longer guaranteed. Faults in the call processing traffic up to (partial) failure of the net node must be reckoned with.

If, in the redundant system side, an associated MBU or an associated SN device was removed from operation by the user (e.g. for diagnosis, hardware testing, module replacement etc.), putting these devices back into operation must now be given the highest priority. This means:– For a preventive diagnosis: Immediately after completion of the diagnosis the MBU

must be configured to ACT or the SN devices to STB (irregardless of the result of the diagnosis).

– For checking/cleaning of the hardware: Plug in all cables and insert all modules immediately and configure the MBU to ACT or the SN devices to STB without further testing.

– During fault clearance: Replace all suspect modules, or in doubtful cases, all modules of the faulty device (MBU, SN, TSG or SSG) at the same time and config-ure the MBU to ACT (or the SN device to STB).

The last both cases are particularly critical with regard to time: It is important that any activated system restart has functioning hardware and firmware for at least one system side so that recovery of the system can be achieved.

Information with the Code Word: GCG:MBG ERRORMB INFORMATION GCG:MBG FAILURE REPORTING UNIT: @######### @############ SUPPLEMENTARY INFORMATION: H’aabbcccc ddeezzzz zzzzzzzz zzzzzzzz H’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz


• bb: Code for the determined fault behavior

• cccc: Processor number of the reporting unit • de: The group clock generator (GCG) status byte transferred by the MBU:LTG


09 MBU:LTG message that a fault was detected in the associated group clock generator

The two half-bytes d and e must be separately interpreted

d = 0 GCG test was negative without PLL alarm

d = 1 GCG test was negative with PLL alarm

d = 2 Alarm without PLL alarm

d = 3 Alarm with PLL alarm

d = 4 GCG test was positive without PLL alarm

146 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805801951fe


• z..z: These bytes are not occupied. Entries not equal to 0 are also not relevant.


An MB INFORMATION with the code word GCG:MBG FAILURE is output when the responsible MBU:LTG has localized a fault in the group clock generator on the interface module M:CG/MUX of this MB module frame. The MBU:LTG reports this to the FA:MB.

As no fault behavior of a certain MBU or of an MB itself exists in this case, the deactiva-tion of an MBU or of an entire MB would be senseless. The FA:MB therefore takes no operation actions, but rather only displays the reported fault behavior.

Main suspect module:

M:CG/MUX in the module frame with the reporting MBU:LTG

Other suspect module:

M:MDM of the reporting MBU:LTG

Also suspect:

The clock cables between the CCG and the affected M:CG/MUX are defective or are not plugged in. Check clock cables between CCG and all available MB units. They all have to be plugged in.

The module frame (backplane, connector strip) with the reporting MBU:LTG and (if not the same) the module frame with the master CCG.

The master CCG itself (= the CCG in operating state ACT).

Cross-references:

Layout of racks with MB and associated fuses: Construction, Racks


Comments/notes

If the fault impairs the output clock of the group clock generator too strongly, then all con-nected MBUs are deactivated consecutively so that they no longer function either by means of their internal supervisory circuits or else, at the latest, by the periodically output LOOP test command of the CP (every 20 seconds).

The output clock of the group clock generator on module CG/MUX supplies all MBUs of the corresponding module frame, i.e. all MBUs of a module frame are affected in the same way by the clock generator fault. All equipped MB module frames always have exactly one CG/MUX module.

d = 5 GCG test was positive with PLL alarm

d = 6 An alarm without PLL alarm was already active before command STAGCG

d = 7 An alarm with PLL alarm was already active before command STAGCGV

d = 8 There is no GCG associated to this MBU:LTG or the GCG is not available.

e = For the half-byte e the 4 bit positions u v w x are individually occupied.

x = 0 clock 0 is not available, w = 0 clock 1 is not available

v = 0 FMB 0 is not available, u = 0 FMB 1 is not available

Examples:

e = A: clock 1 and FMB 1 are not available

e = E: only clock 0 is not available

A30828-Y1187-N510-2-7620

147


Id:0900d805801951fe

The first MBU:LTG in an MB module frame is responsible for testing and supervising the M:CG/MUX. This MBU also reports the determined fault behavior. For this reason only certain MBU:LTGs can function as reporting MBUs (see "Interpretation of SUPPLE-MENTARY INFORMATION").

If the responsible MBU:LTG detects a clock fault but cannot however fixedly assign the fault to the group clock generator, it adds an appropriate note to the message for the FA:MB. The FA:MB then assigns the fault to the active master CCG and transfers the fault information to the FA:CCG. The FA:CCG removes the ACT CCG (master) from operation, i.e. configures it to UNA. Compare in NM:CCG, section Interpretation of CCGA Fault messages.

5.10 MMN:MB130 - ERROR MESSAGE DURING CONF.If a timer expires during a configuration action (this can also be a configuration action within a called diagnosis) in the CP without the configuration being able to be success-fully executed, the configuration job is rejected and the following ERROR MESSAGE is printed out:ERROR MESSAGE DURING CONFIGURATION OF MBxx-mb-mbxx MB130-1000 xxxxxxxxxxxxxxxxxxxxxxxxxxx

This is followed by a command repetition and the rejection of the configuration with the reason HARDWARE FAULT.

Explanation

• mb: 0 (MB-0) or 1 MB-1 • x: L (MBU:LTG) or S (MBU:SGC) • mbux: 0 ... 7 (number of the affected MBU)

The MMN number MB130 output in the ERROR MESSAGE can be used to initiate fault clearance if the configuration job was given outside an MMN fault clearance procedure. Within a fault clearance this MMN number must be ignored!

A code word indicates the cause of the fault in the line xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.

For the various code words the following causes of faults exist:

NO REACTION TO RESTART OF MBULNO REACTION TO RESTART OF MBUSFor this fault behavior the RESTART signal was able to be successfully sent to the affected MBU at interface B:MBG between the IOP:MB and the MBU concerned. However, the MBU operation capability message MBUR was not sent. The CP then decides after expiry of a timer that the MBU is not operable. As no fault symptoms other than the missing MBUR message exist, no byte encoded fault information can be output for this fault behavior. The message MBUR as confirmation of a successful RESTART is a prerequisite for the configuration of the MBU to ACT as well as for the start of the MB diagnosis. Both are not possible for the fault behavior outlined here.

The following modules are suspect in this case:– Modules M:IOPC and M:CG/MUX in the module frame with the affected MBU– Module M:MDM (only for faulty MBU:LTG)– The modules of the associated IOP:MB

148 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805801951fe


Cross-references:– Layout of racks with MB and associated fuses: Construction, Racks– Layout of frames - module side, backplane and cabling: Construction, Frames

MB/CCG

NO LOOP RESPONSEMUTILATED LOOP RESPONSENO RESPONSE FROM MBUAn error message with one of these code words is issued if it is not possible to distin-guish the MB type due to a defect in the MBU. An MB of type MBB can transmit a message with a length of up to 128 bytes, whereas an MB of type MBA can only transmit messages up to a length of 32 bytes. The type identity code of the MBU must be pro-cessed and saved in the data base. This is possible because the MBU is already entered in the scan cycle. After a successful RESTART the CP sends the MBFWID command to the affected MBU. The MBU ignores this command if an MBA is concerned and no acknowledgement is sent. An MBU of type MBB sends the acknowledgement MBFWSTA. For an MBU:LTG the parameter MB type of MBFWSTA can contain the values H’0F for MBB, H’01 for MBUL(C) and H’02 for an MBUL(C) with the functions mir-roring and packeting*). In order to be able to decide whether the MBU is defect and that is therefore why no acknowledgement is sent, or whether it is an MB of type MBA, the command MBLOOP is sent as an accompanying command immediately after transmit-ting the command MBFWID. The CP awaits from the MBU the acknowledgement MBRELOOP with the exact output test pattern.

In the cases where the request is negative the MBU is taken out of the scan cycle (con-figured to MBL) and an error message is issued with the following code words:

The following modules are suspect in this case: M:IOPC and M:CG/MUX in the module frame with the affected MBU and M:MDM.

*) Mirroring: The MBUL(C) can forward via a ’shortcut’ reports between LTGs which have their active MCHs at the same MBU:LTG. These reports don‘t have to be routed via the CP any more. Packeting: With the MBUL(C) Messages can be sent between MB and LTG in packeted form (several messages in blocks up to max. 128 bytes)

5.11 MMN:MB130 - ERROR MESSAGE FROM MBU....If a serious fault is detected in the MB during a configuration activity (this can also be a configuration action within a called diagnosis), it cannot be handled by the fault analysis program for the MB (FA:MB). In this case, the system outputs an ERROR MESSAGE with notes and further information on the fault if necessary.ERROR MESSAGE FROM MB130-1000 MMN:MB130-1000 @################# @####################################### @#######################################

MUTILATED LOOP RESPONSE MBFWSTA and incorrect MBRELOOP

NO LOOP RESPONSE MBFWSTA and no MBRELOOP

NO RESPONSE FROM MBU MBFWSTA and no MBRELOOP

A30828-Y1187-N510-2-7620

149


Id:0900d805801951fe

This is followed by a command repetition and the rejection of the configuration with the reason HARDWARE FAULT

Explanation

• mb: 0 (MB-0) or 1 MB-1 • x: L (for MBU:LTG) or S (for MBU:SGC) • mbux: 0...7 (number of the affected MBU)

The MMN number MB130 output in the ERROR MESSAGE can be used to initiate fault clearance if the configuration job was given outside an MMN fault clearance procedure. Within a fault clearance this MMN number must be ignored!

A code word indicates the cause of the fault in the line xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

For the various code words the following causes of faults exist:

MBU ERRORA fault was detected internally during the configuration in the MBU concerned. The MBU reports this to the CP with the message MBUER (MBU error). The configuration is ter-minated and an error message with the MMN number MB130-1000 is output.

For further comments/notes, listing of the suspect hardware and interpretation of the hexadecimal fault information see: 5.4 MMN:MB110-1004 - MBU ERROR or MBB Fault Message with the Code Word: MBU ERROR

All the information provided in this sections also applies here as both cases have the same fault cause. The sole difference is in the handling of the fault by the system soft-ware.

IOFAULTThis code word signifies that the message traffic between the affected MBU and the associated IOP:MB is so severely disturbed that the MBU cannot be put into operation (configured to ACT). However, the MBU has not failed to a 100% degree (as would be the case, for example, for power failure) because the signal RESTART could still be sent successfully and was confirmed.

Possible reasons for the fault are, for example, as follows– The interface cables of the B:MBG between the IOP:MB and MB are faulty or not

properly plugged in.– The following are also suspect as the fault location: All modules M:IOPC,

M:CG/MUX and M:MDM in the module frame with the affected MBU. The back-plane/connector strip of this module frame. Finally, the entire associated IOP:MB (modules, backplane of the module frame).

Interpretation of the hexadecimal fault information:H’aabbcccc ddeezzzz zzzzzzzz zzzzzzzzH’zzzzzzzz zzzzzzzz zzzzzzzz zzzzzzzz

– aa: Origin of message

– bb: IO-MESSAGECODE

06 EAVT (call processing periphery)


150 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805801951fe


– cccc: Processor number of the message sender

– dd: MBU Number of the affected MBU

– ee: Reason for the message IOFAULT (fault explanation)

– z..z: These bytes are not occupied. Entries not equal to 0 are also not relevant.

01 IOFAULT: Input/output procedure, during which or from which the fault was detected. The message traffic between the IOP:MB and the affected MBU is interrupted/faulty (interface B:MBG)

0800 EAVT

04 MBU:LTG-0-0 20 MBU:LTG-1-0

05 MBU:SGC-0-0 21 MBU:SGC-1-0



0A MBU:LTG-0-3 26 MBU:LTG-1-3

0B MBU:SGC-0-1 27 MBU:SGC-1-1

0C MBU:LTG-0-4 28 MBU:LTG-1-4

0D MBU:LTG-0-5 29 MBU:LTG-1-5

0F MBU:SGC-0-2 2B MBU:SGC-1-2

10 MBU:LTG-0-6 2C MBU:LTG-1-6

11 MBU:LTG-0-7 2D MBU:LTG-1-7

13 MBU:SGC-0-3 2F MBU:SGC-1-3

00 NOACK: no acknowledgement ACK2 was given by the affected MBU

01 NORDY: no “ready” signal RDY was given by the affected MBU or ACK2 or REQ was already active when the MBU was addressed

02 NOREQ: from the affected MBU no request signal REQ was sent as reaction to signal STROBE

03 PARERR: a parity error occurred for at least one byte transfer of the message (signal lines D0...8)

04 NADIN: the signal ADDRINH was not correctly given or acknowledged (ADDRESS INHIBIT)

05 ACKN: the command was successfully carried out for the affected MBU. No fault behavior was detected

06 NOEX: the command could not be carried out due to an unknown reason

07 LENFLT: a length fault was detected in the message traffic with the affected MBU, i. e. the message length given in the message header does not corre-spond with the actual length or the length contained in the message header is not defined, e. g. less than 4

08 INFLT: fault behavior was detected for the affected MBU in the IN signal

09 NOIOP: no IOP:MB was available for message execution/transfer (double failure IOP:MB)

A30828-Y1187-N510-2-7620

151


Id:0900d805801951fe

IORESPThis code word in this case signifies the severest fault which can affect a single MBU. The unit has totally failed and shows no reaction whatsoever to the contact attempts by the CP. The signal RESTART cannot be sent by the IOP:MB.

The following are examples of the possible fault causes:– The B:MBG interface cables between the IOP:MB and MB are faulty or are not/not

correctly plugged in.– The following are also suspect as the fault location: All modules M:IOPC,

M:CG/MUX and M:MDM in the module frame with the affected MBU. The back-plane/connector strip of this module frame. Finally, the entire associated IOP:MB (modules, backplane of the module frame).

Cross-references:– Layout of frames - module side, backplane and cabling: Construction, Frames MB– Layout of racks with MB and associated fuses: Construction, Racks

Interpretation of the hexadecimal fault information:H’aabbcccc ddeeffgg hhiihhii hhiihhiiH’hhiihhii hhiihhii hhiihhii hhiizzzz

– aa: Origin of message

– bb: IO-MESSAGECODE

– cccc: Processor number of the message sender

– dd: Reporting software unit

– ee: Job code 2 of the command, which was acknowledged by this message

– ff: Meaning of content of acknowledgement IORESP

06 EAVT (call processing periphery)

0F SGMES (Safe Guarding Monitor), the FA:MB received the command to initiate the fault message from another software unit, e. g. FA:IOP

00 IORESP: Input/output procedure, during which or from which the fault was detected. A command IOKONF or IORSOUT was output to the IOP:MB for the affected MBU. The command could not be carried out or only incom-pletely.

0800 EAVT

0D SG-CONF

02 IOKONF: Command to enable or disable the MBU in the scan cycle. The scan cycle can be enabled with or without RESTART of the affected MBU. IOKONF in IORESP is mostly output in connection with a rejected user job. Either the configuration of the affected MBU to ACT is rejected or a diagnosis of the affected MBU cannot be carried out because the configuration of the MBU to SEZ required here was rejected

04 IORSOUT: command to reset the output list

00 ACK: the command was nor carried out properly

01 NAK: the command was not (or only partially) carried out (this value often indicates a hardware fault)

152 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805801951fe


– gg: Number of MBUs for which this acknowledgement IORESP is valid. Maximum value is 0Bh = 11

– hh: MBU number of the affected MBU. (The byte position can only be evaluated if it is occupied according to the information in byte gg.)

– ii: Reason for the message IORESP (fault explanation)

02 REJECT: the command could not be carried out because the IOP:MB was reserved

03 TRUNK: the command could not be carried out because it was interrupted during execution by an IOP hardware reset

04 SWERR: the command could not be executed due to a software error

The number of bytes to be subsequently evaluated is dependent on this MBU number. For each MBU specified, a byte hh and a byte ii were written. All other bytes cannot be interpreted, even when a value not equal to 00 is entered.


05 MBU:SGC-0-0 21 MBU:SGC-1-0



0A MBU:LTG-0-3 26 MBU:LTG-1-3

0B MBU:SGC-0-1 27 MBU:SGC-1-1

0C MBU:LTG-0-4 28 MBU:LTG-1-4

0D MBU:LTG-0-5 29 MBU:LTG-1-5

0F MBU:SGC-0-2 2B MBU:SGC-1-2

10 MBU:LTG-0-6 2C MBU:LTG-1-6

11 MBU:LTG-0-7 2D MBU:LTG-1-7

13 MBU:SGC-0-3 2F MBU:SGC-1-3

00 NOACK: no acknowledgement ACK2 was given by the affected MBU

01 NORDY: no “ready” signal RDY was given by the affected MBU or ACK2 or REQ was already active when the MBU was addressed

02 NOREQ: from the affected MBU no request signal REQ was sent as reaction to signal STROBE

03 PARERR: a parity error occurred for at least one byte transfer of the message (signal lines D0...8)

04 NADIN: the signal ADDRINH was not correctly given or acknowledged (ADDRESS INHIBIT)

05 ACKN: the command was successfully carried out for the affected MBU. No fault behavior was detected

06 NOEX: the command could not be carried out due to an unknown reason

A30828-Y1187-N510-2-7620

153


Id:0900d805801951fe

– z..z: These bytes are not occupied. Entries not equal to 0 are also not relevant.

07 LENFLT: a length fault was detected in the message traffic with the affected MBU, i. e. the message length given in the message header does not corre-spond with the actual length or the length contained in the message header is not defined, e. g. less than 4

08 INFLT: fault behavior was detected for the affected MBU in the IN signal

09 NOIOP: no IOP:MB was available for message execution/transfer (double failure IOP:MB)

154 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec06

Replacement Instructions

6 Replacement InstructionsBefore a device is taken out of service, it is necessary to make sure that the redundant unit is fully operational.

When inserting and pulling modules and cables, the valid regulations relating to electro-static-sensitive components must always be observed. Further information can be found in the brochure “Safety Instructions for personal and products (EN60950/IEC60950)” .

The replacement module must be identical with the original module (same code number both for HW/FW and for functional status). The HW/FW status can also be taken from the exchange specific document of the network node. In exceptional cases the Func-tional Level List can be used to determine whether the functional status of the replace-ment module (as regards HW/FW) is compatible with that of the original module.

Manual Construction; Section Racks offers an overview of the equipment containing MB frames and the fuse assignments. Section Frames F:MB/CCG and Frames F:IOPMBD provides the layout of MB frames and cabling according to cable list and section Modules MB contains the display of MB modules and explanation of LEDs on the module faceplates.

6.1 Replacing MBD modules MBDA, MBDH, MBDE • When exchanging, note the following: The relevant MBIA, MBIH or MBIE unit must

always be in MBL . • Pull the suspect module and insert the spare module • Activate the BOST switch to initiate the module self-test • Perform a diagnostic test for the MB unit in MBL and configure it to ACT .

6.2 Replacing MBD modules MBDC, MBDCG • When exchanging, note the following: The relevant MBIC unit must always be in

MBL . The corresponding MB side must be configured to MBL. • Pull the suspect module and insert the spare module • Activate the BOST switch to initiate the module self-test • Perform a diagnosis for the MB side in MBL and configure to ACT

6.3 Replacing MBB modules • When replacing MB modules, the MBU in question must always be in MBL. • Before replacing modules of type IOPC or CG/MUX configure all MBUs in ACT with

are inserted in the same frame as the faulty MBU to MBL.. For the layout of racks and frames with MB see manual Construction chapter Racks and chapter Frames MB/CCG.

• Pull suspect module, insert spare module • Test MBUs in MBL with diagnosis and configure them to ACT, one after the other.

Start with MBU:SGC.

A30828-Y1187-N510-2-7620

155

NM:MB Replacement Instructions

Id:0900d805800bec06

6.4 Replacing Current Converter and Associated Fuse • When replacing the current converter, all MBUs in the frame with the faulty MBU

must be in state MBL. • The direct current converter DCCCS is in MOLOC A001 in each MB frame

F:MB/CCG(B). The direct current converter DCCDE is in MOLOC C259 in each MB frame F:SMSC(C). For the layout of racks and frames with MB see manual Con-struction chapter Racks and chapter Frames MB/CCG or SMSC. The DCCCS and the DCCDE are displayed in chapter Modules DCC.

• Switch off the current converter that supplies the faulty MBU. A direct current con-verter module is switched on and off by means of the switch on its faceplate;Switch up: current converter on Switch down: current converter off

• Remove associated fuse FU (10 A) • Pull the (switched off) DCCCS, insert a (switched off) spare current converter of the

same type • Insert (if necessary new) fuse • Switch the current converter on • Test MBUs in MBL with diagnosis and configure them to ACT, one after the other.

Start with MBU:SGC.

6.5 Replacing F:MBDA module frame must be replaced if the backplane is faulty. If the cable routing permits it, only the backplane should be removed, otherwise the module frame. For the layout of racks, fuse assignment and frames with MBD see manual Construction chapter Racks and chapter Frames MB/CCG. • Configure the MB units in the suspect module frame to MBL • Switch off the relevant automatic cutouts for the MB • Pull all modules in the frame • Pull all cable connectors on the wiring side • Remove the power supply cables • Remove FOTX on the wiring side of the M:MBDA with special tool • Replace backplane or the module frame • Plug in the power supply cables • Plug in all the cable connectors • Reinsert FOTX on the cable side of the M:MBDA • Reinsert the modules according to the inventory index • Switch on the relevant automatic cutouts • Wait till only the green LEDs on the module face plate are lit • Perform a diagnosis for the MB side in MBL and configure to ACT

6.6 Replacing F:MB/CCG(B)A module frame must be replaced if the backplane is faulty. If the cable routing permits it, only the backplane should be removed, otherwise the module frame. For the layout of racks and frames with MB see manual Construction chapter Racks and chapter Frames MB/CCG.

156 A30828-Y1187-N510-2-7620

NM:MB

Id:0900d805800bec06

Replacement Instructions

• Configure MBU:SGC, MBU:LTG(s) in the suspect module frame to MBL • If the module frame contains a CCG (basic rack R:MB/CCG, MUT 02 or MUT 03),

configure this CCG according to MBL • Switch off current converters • Unscrew the appropriate fuses for MB, and CCG if necessary • Pull all modules in the frame • Pull all cable connectors on the wiring side • Pull power supply cables • Replace backplane or module frame • Plug in power supply cables • Plug in all cable connectors • Insert modules again in accordance with inventory list • Insert associated fuses • Switch on current converters • Test the MBU:SGC with diagnosis before activating the MBU:SGC • Test the MBU:LTG(s) with diagnosis before activating the MBU:LTG(s) (one after

the other) • F:MB/CCG(B) with CCG: The CCG modules and current converter are displayed in

manual Construction chapter Modules CCG and in chapter Modules DCC.Switch on current converter After the power has been switched on again, a period of time must be allowed for After the power supply has been switched on again wait for the quartz to warm up and the synchronization. The LED on the face plate of the CCGXXA module indicate type of operation, refer-ence frequency and synchronization status.

The accuracy of the reference frequency must be within the CCG pull-in range and the reference frequency must not be interrupted during the synchronizing operation.If the reference frequency is distorted during synchronization, the indicator does not get beyond status A. In this instance the reference frequencies, transmission devices and if necessary the reference clock source must be investigated with the appropriate measuring equipment (TIE and rubidium normal). Synchronization of the CCG can also take place with a reference frequency which is derived from a rubidium standard.

• After at least synchronization status 1 is reached, or LEDs P and F are on configure CCG to STB

• In case CCG-1 is ACT, configure CCG-1 to STB (standard configuration)

plesiochronous mode: LEDs P and F are on (approx. 35 min.)

synchronous mode: LED 1, 2, 3 or 4 is on (approx. 2 - 3 hours)