TN55TQX card in general supports various service types including STM-64, OC192, 10GE, FC800, FC1200 or OTU2. However there are dedicated XFP modules (BOMs) for different services. Unfortunately U2000 does not alert or notify when user creates service with wrong XFP type. Moreover many XFPs will actually work although wrong service type is created. For example customer ordered several TQX cards equipped with: 10GE/STM64 dedicated XFPs (BOM 34060313), and FC800 dedicated XFPs (BOM 34060658). However XFPs arrived distributed randomly and customer didn’t pay attention to verify XFP type while creating services. Unexpectedly most services ware working although wrong XFP BOMs were used. Eventually one of the FC800 services failed and after investigation XFPs mismatch across the network has been discovered on OSN 8800.

Software version OSN 8800 V100R007C02SPC200

iManager U2000 V100R008C00SPC300

The following XFP types have been delivered to the customer:

BOM 34060313 (dedicated for STM64/10GE):

- FTLX1412M3BCL(also working when FC800 configured)

- FTLX1413M3BCL-HW (also working when FC800 configured)

- SXP3104NV-H1

- TRF5013FN-GA420

- TRF5015FN-GA420

BOM 34060658 (dedicated for FC800 services):

- PT745F-81-1D (also working when 10GE or STM64 configured)

The problem with XFP mismatch has been discovered when FC800 service was created with XFP SXP3104NV-H1 type. U2000 didn’t rapport any problems although the far end equipment reported link down. The issue has been resolved by relocating XFPs across the network to get dedicated XFPs for all relevant services.Wrong XFP types were used when crating FC800 serviceXFP modules relocation

Although some XFP types can work even when incorrect service type is created, this configuration is not recommended or supported by Huawei transport network. There is no guarantee this configuration is stable, and under certain conditions errors might occur.

I've searched around, don't know whether OSN 1500 OR OSN 500 is fit for small area network use.

The networking is as follows:
Station A and station B are configured with the LWX2 and the DMD2S. Each SCC is configured with one 1551-nm optical module to implement the OSC communication. The configuration of the two stations is the same. The NE version is 5.67.1.22. After Huawei optical power commissioning is complete, the ECC between station A and station B fails. 1. The optical power is incorrect.
2. The optical module is faulty.Huawei OSN 1800
3. The SCC software is defective The SCC software has a bug. When the PHY chip used by the OSC optical port on the SCC works in BASE-EFX mode, special requirements are raised for the optical module. That is, the chip can be linked only when the amplitude of the electrical input signals of the optical module is higher than 800 mV. The amplitude of the electrical input signals of the currently used optical module is about 800 mV. Therefore, the OSC communication may fail.

The LWX2 does not support the ESC. Station A and station B use the optical module on the SCC to implement the OSC communication. Check the receive optical power of the RM1/TM1 optical port on the SCC. The check result shows that the receive optical power is normal. There is no abnormal alarm. Run :cm-get-eccroute. The remote NE cannot be queried. Run :cm-get-bdinfo to query the DCC state. The query result shows that the DCC state is rx-f. Reset the SCC. The fault persists.
Install OptiX OSN 1800 A and OptiX OSN 1800 B in the same equipment room. Interconnect the RM1s/TM1s of the two OptiX OSN 1800s with the added fixed optical attenuators through fibers. Run :cm-get-eccroute. The remote NE still cannot be queried. The DCC state is still rx-f.
The confirmation result by the related experts shows that the SCC software has a bug. When the PHY chip used by the OSC optical port on the SCC works in BASE-EFX mode, special requirements are raised for the optical module. That is, the chip can be linked only when the amplitude of the electrical input signals of the optical module is higher than 800 mV. The amplitude of the electrical input signals of the currently used optical module is about 800 mV. Therefore, the OSC communication may fail.
Software mitigation is performed in the latest version (5.67.01.24). The problem is solved. After the NE software is upgraded to this version, the OSC communication is normal on Huawei WDM OSN 1800( http://www.thunder-link.com/HUAWEI-OPTIX-OSN1800_p191.html ).

A new Huawei OSN 3500( http://www.thunder-link.com/HUAWEI-OPTIX-OSN3500_p187.html ) equipment just created, generated after the upload operation the NE error: Invalid parameters error code: 38722; and some boards didn’t appear or turned grey (picture).
The troubleshooting developed was:
1. Run in Navigator the commands (:ver, :hbu-get-backup-info, :cfg-get-nestate, :alm-get –curdata)
2. Try to create the NE with only one SCC board.
3. Downgrade the NE to a pure SDH version.
There was two troubles, first the NE had two SCC boards that didn’t synchronize because each one had a different ID, and the second issue was a mistake made by the person that upgrade the element on site; he put on the equipment the version V2R11C00SPH303 which is a version for Huawei MSTP equipments, and the customer network only managed SDH elements.
The solution was remove one SCC board, and after that the configured the ID belong to the board that was outside of the equipment in the board that kept inside. The next step was insert again the SCC board and wait until those boards turned synchronized. Once the Navigator command :hbu-get-backup-info, showed the result: “Backup-Info : 0x00000003”; I proceed to ask the partner on site to downgrade the NE from the firmware V2R11C00SPH303 to V100R010C03SPH211.
Finally when the NE get the target version V100R010C03SPH211, all the boards belong to the equipment appeared in the layout, and began to work properly.
The key to create on the NM a new NE without problems is; to demand a good commissioning on site with a complete report when buy Huawei OSN 3500.

A [URL="http://www.thunder-link.com"]Huawei WDM[/URL] network consisted of five rings. An M40v board and a D40 board were used on each NE as the multiplexer and demultiplexer. LDX boards were used to forward 10GE LAN services. Dual-ended intra-board 1+1 protection was configured by using DCP boards. After the PAT, switchovers occurred frequently on the channels between NE 12 and NE2 and on those between NE 13 and NE 2. Related DCP boards reported INTRA_OTU_STA_INDI and INTRA_OTU_PS alarms. The INTRA_OTU_STA_INDI cleared after a while but the INTRA_OTU_PS alarm failed to clear. Services were switched to the protection channel. The switchovers occurred twice. The related information is as follows:

First switchover: When the customer was maintaining the line, the line attenuation between NE 13 and NE 2 transiently increased by 6.5 dB and then restored (queried in the 15-minute performance data). Wavelength 1 between NE 13 and NE2 and Wavelength 2 and Wavelength 3 between NE 12 and NE 2 were switched. Services were transmitted to NE 2 through NE 1.
Second switchover: When the customer was maintaining the line, the line attenuation between NE 13 and NE 2 transiently increased by 1.8 dB and then restored (queried in the 15-minute performance data of the OBU board). Wavelength 1 between NE 13 and NE2 and Wavelength 2 between NE 12 and NE 2 were switched. Services were transmitted to NE 2 through NE 1. Wavelength 3 was normal.
The networking typology is as follows.
OSN 8800 T32/P16 version: V100R008C00T
U2000 version: V100R009C00
The conditions for an OLP switchover include R_LOS and POWER_DIFF_OVER. The switchovers in this case were triggered by the POWER_DIFF_OVER alarm caused by optical cable deterioration. On the U200, the default threshold for the difference between optical power on the working and protection channel on the DCP boards is 5 dB. This threshold can be modified by choosing
Configuration > WDM Interface > Variance Threshold Between Primary and Secondary Input Power on the NE Explorer. The default value was used on the network in this case.
First switchover:
On NE 13, Port 1 (TI1/RO1) of the DCP board was used. The optical power at the working port (RI11) and protection port (RI12) was as follows:
RI11: –4.9 dBm
RI12: –5.3 dBm
When the optical power on the working channel decreased from –4.9 dBm to –11.4 dBm (queried in the 15-minute performance data of the OBU board), the difference between the optical power on the working and protection channels was –5.3 – (–11.4) = 6.1 dB, which exceeded threshold. Therefore, a POWER_DIFF_OVER alarm was generated. This alarm was not reported to the U2000 by default. Huawei queried the historical alarms by choosing More Alarm Operations > History Alarm on NE from the switched NE 13 on the U2000 and found that the DCP board reported a POWER_DIFF_OVER alarm.
Therefore, the switchover was normal. The switchovers on Wavelength 2 and Wavelength 3 between NE 12 and NE 2 were triggered by the same condition.
Second switchover:
On NE 13, Port 1 (TI1/RO1) of the DCP board was used. The optical power at the working port (RI11) and protection port (RI12) was as follows:
RI11: –4.9 dBm
RI12: –5.3 dBm
When the optical power on the working channel decreased from –4.9 dBm to –6.7 dBm (queried in the 15-minute performance data of the OBU board), the difference between the optical power on the working and protection channels was –5.3 – (–6.7) = 1.4 dB, which was less than the threshold. Therefore, no switchover should occur. However, Huawei queried the history alarms by choosing More Alarm Operations > History Alarm on NE from the switched NE 13 on the U2000 and found that the DCP board reported a POWER_DIFF_OVER alarm. The same situation occurred in the switchover of Wavelength 2 between NE 12 and NE 2.
The cause is as follows:
An OBU board collects and reports optical power to the NE software per second. If the optical power during the deterioration is collected, an accurate value is reported to the NE. However, if the duration of the deterioration is short and the board fails to collect the optical power during the deterioration, the reported value is inaccurate and the actual input optical power of the OBU board is lower than the value in the historical performance. Therefore, the difference may exceed the threshold and trigger a POWER_DIFF_OVER alarm, as shown in the following figure.
The optical attenuation increased transiently due to optical cable deterioration.No special handling operations are required because the switchover is triggered by optical cable deterioration. Manually switch services back to the working channel after it is stable.
The optical cables used by the customer are of poor quality and are frequently maintained. Therefore, this problem occurs frequently. The following suggestions are given to the customer:
1. The switching mechanism is used to secure services when an exception occurs on the line. A switchover is completed in 50 ms and services are not affected during the switchover. Therefore, no special operations are required to handle this problem.
2. The alarm threshold parameter on the U2000 of [URL="http://www.thunder-link.com/HUAWEI-OPTIX-OSN8800_p193.html"]OSN 8800[/URL] is Variance Threshold Between Primary and Secondary Input Power. The parameter value ranges from 3 dB to 8 dB and the default value is 5 dB. The value can also be set to 0 dB. The customer can use a high threshold value to work around this problem. However, if the threshold is not met when the optical power on the working channel deteriorates, the switchover cannot be triggered. Therefore, exercise caution when using this method.

The process is very complicated from Huawei MSTP equipment( http://www.thunder-link.com ) OSN 3500 configuration to management. You'll in confront of all kind of technical problems. Here we have three STM64 channels, one of our services is STM4*4 (2,5 Gbit/s). At first we wanted to redund the whole channel STM64 via SCNMP - one STM64 is working and other two are the protection channels - but it is not optimal solution. The question is the following: can we protect with SCNMP only these four STM4? so that in each channel we had free 7,5 Gbit/s for traffic?

Summary:
When a warm reset is performed on a TN52XCH, TN52XCM, TNK2XCT, or TNK2SXM board that has not booted, the board becomes logically abnormal and cannot be restored to normal.
[Problem Description]
Trigger conditions:
For a TN52XCH, TN52XCM, TNK2XCT, or TNK2SXM board, when the physical board is installed but no logical board is configured or mapped, an upgrade in package loading or matching mode is performed and the board experiences a warm reset during the upgrade. The common application scenarios on the live network are as follows:
1. During a subrack expansion, a cross-connect board is added to the subrack and undergoes package loading or matching before the required logical board is configured.
2. During board replacement, a cross-connect board is added to the subrack and undergoes package loading or matching before the required logical board is configured or mapped.
Symptom:
When no BUS_ERR alarm is reported on the entire NE and no HARD_BAD alarm is reported for the cross-connect boards, the active/standby switching on the cross-connect boards fails.
Identification method:
During normal NE operation, run the SmartKit Inspector to check the following item:
Checking why the working status of the synchronous cross-connect board is set to abnormal and cannot be restored

This issue is a known issue of a synchronous cross-connect board. To be specific, if the software of a synchronous cross-connect board is (warm) reset before the board software starts to work, the working status of the board software will be set to abnormal after the board software gets started.

[Impact and Risk]
Active/standby switching cannot be performed on the cross-connect boards. As a result, services may be affected.
[Measures and Solutions]
Recovery measures:
When the system is properly operating, run the SmartKit Inspector. If any abnormality is found, rectify the abnormality according to the following handling suggestions:
Perform the following steps in the permitted maintenance windows:
1. If both the active and standby cross-connect boards in a subrack are malfunctioning, perform a cold reset on the standby cross-connect board. About 5 minutes later after the board software starts to work, active/standby switching will be automatically performed. After the active/standby switching is completed, perform a cold reset on the new standby cross-connect board.
2. If only one cross-connect board is malfunctioning in a subrack, perform the following operations:
If the standby cross-connect board is malfunctioning, perform a cold reset on it.
If the active cross-connect board is malfunctioning, check whether a fault occurs on the standby cross-connect board and rectify the fault if it is found. After the fault on the standby cross-connect board is rectified, active/standby switching will be automatically performed. After the active/standby switching is completed, perform a cold reset on the new standby optical transmission[http://www.thunder-link.com/] cross-connect board.

3. Check whether the cross-connect boards are normal.
Workarounds:
When no logical boards are loaded for cross-connect boards, do not upgrade the cross-connect boards in package loading or matching mode or perform a warm reset on the boards.
Preventive measures:
Upgrade the board software version to OptiX OSN 8800[http://www.thunder-link.com/HUAWEI-OPTIX-OSN8800_p193.html] V100R006C01SPC200 or later.

Inter-brand released the 15th annual Best Global Brands on Oct. 9, and a Chinese company broke into the list for the first time throughout history.

Huawei, a Chinese telecommunications and transmission network http://www.thunder-link.com equipment manufacturer and the world's third largest smartphone provider was listed No. 94 and is one of five new entrants on the Best Global Brands ranking this year. Maybe Huawei is more of a household name in Asia than in Western markets, but it has got its popularity and reputation globally with its rapid growth and long-term investments and earned its place in this year' Best Global Brands ranking.

Focused on innovation and aggressive globalization, Huawei strategically utilizes its resources in accordance with market demand. Huawei is quickly becoming one of the world’s largest telecommunications equipment manufacturers with 65% of its revenue coming from outside of China.

Proved its strategy is prosperous, this transnational http://www.thunder-link.com optical networking and telecommunications company is rapidly becoming the market leader in Latin America and Central Asia, and a major player in Canada. With the new marketing approach--getting closer to more customers which is to support its ambitions, the brand has recently launched a more consumer-friendly face. Its work that cooperated with telecom operators around the world is being leveraged as a way to show how much impact Huawei has on the world they live in. with these customers in mind, Huawei plans to eliminate 80% of the low-cost Mobile device this year. The goal is to develop products to meet consumer demand, instead of meet the minimum costs and operational specifications. Huawei's star product line—Ascend is clearly shows that the company is trying to change their image in the mobile phone market, transform low-cost alternatives into a more advanced one. With smart phone sales volume go up since the first quarter of 2014, and the current 20% global market share is in the best brands place, Huawei is at its full speed and making its mark to the world.

In Huawei optical transmission boards, SSN4 is equal to SSND00, and generally speaking, the same boards that display different product name have the same feature code, like SSN4SL6402 and SSND00SL6402. But When it comes to Huawei service board SSN4EGS411 and SSND00EGS412, some customers are misguided and some customers are asking that whether we delivered the wrong model of board to them, because In huawei BOQ, it is show as SSND00EGS412, here version code is ND00, feature code is 412; But in board front panel, it show as SSN4EGS411, here verison code is N4, but feature code is 411. Actually they are the same board.
To avoid this confuse, we suggest when ordering a EGS4 board, it better to comment with a optical specification behind.

For example, when you are about to order a SSN4EGS411[http://www.thunder-link.com/SSN4EGS411_p215.html] board, you must select maybe you will choose configuration(slots and transmission range etc.).

After you selected the configuration of this board, it will appear message box.

The product name shows as SSND00EGS412[http://www.thunder-link.com/SSND00EGS412_p216.html. But the product name that shows on the board is SSN4EGS411.

So when you buy this model of board later, you won’t be confused again.

For more information about Huawei optical transmission boards or buy Huawei transmission network equipments, please visit our site or contact with: info@thunder-link.com.

SSR1PCXLL401 is a SDH service board which serve in Huawei OSN 1500B[http://www.thunder-link.com/HUAWEI-OPTIX-OSN1500B_p201.html] equipment. You could discover several names of this board, these are SSR1PCXLL4, SSR1PCXLL401, SSRD0PCXL411. In fact they describe the same item and you can use any name of it to search on the internet. Many professional HUAWEI transmission product suppliers buy this board such as thunder-link international. Reports various alarms and performance events, which facilitates the management and maintenance of the equipment.

Four parts compose of SSR1PCXLL401, namely, SDH Processing Unit whose function is transmits and receives 1xSTM-1/STM-4/STM-16 optical signals; SCC Unit works on Configures and monitors services, monitors the service performance,and collects the information about the performance events and alarms; Cross-Connect Unit includes Higher order cross-connect capacity: 60(Gbit/s); Lower order cross-connect capacity: 20(Gbit/s), which matters a lot to the customers; the forth one Clock Unit provides the standard system synchronization clock.

The SSR1PCXLL401 is available in one functional version, that is R1. It is used in the OSN 1500B Transmits and receives 1xSTM-1/STM-4/STM-16 optical signals. It converts the received optical signals into electrical signals and sends the electrical signals to the cross-connect side. In addition, it also converts the electrical signals sent from the cross-connect side into optical signals and transmits the optical signals.

The SSR1PCXLL401[http://www.thunder-link.com/SSR1PCXLL4S41LC_p390.html] could be installed in slots 4 and 5 in the subrack. By default, slot 4 is the slot for the working board, and slot 5 is the slot for the protection board.
The feature code 401 of the SSR1PCXLL401 indicates the type of optical interface is S-4.1. Some parameters that differ from the series board of SSR1PCXLL401 can be referred as follows: (S-4.1) , its transmission distance is 2 ~ 15 km; (L-4.1 ), 20~40km; (L-4.2), 50~80km and (Ve-4.2 ), 50~100km.

The SSR2PD1A is a PDH processing board which adds tributary signals to line signals and drops tributary signals to line signals. This board has another name, SSR2PD1A01[http://www.thunder-link.com/SSR2PD1A_p385.html], so that you can use different names to search at Thunder-link.com which sells various transmission boards including SSR2PD1A. Thus you will enjoy your shopping tour at that site.
Huawei SSR2PD1A board

The SSR2PD1A can be used on the OptiX OSN1500B equipment to transmit/receive process 32xE1 signals. The series of PD1 is available in two functional versions, namely, R1 and R2. The difference between the two versions is with regard to their function: R2PD1supports the PRBS test in the tributary direction and in the cross-connect direction in the normal mode or MUX mode and does not support the PRBS test in the Server mode; The R1PD1 supports the PRBS test in the tributary direction and in the cross-connect direction and does not support the CRC function, but the R2PD1 supports the CRC function. The R1PD1A can be replaced with the R2PD1A when the required conditions are met. So you should pay attention to the difference.

In the case of SSR2PD1A of OptiX OSN 1500B equipment[http://www.thunder-link.com/HUAWEI-OPTIX-OSN1500B_p201.html], it must be used with the D75S, D12S, or D12B. In the OptiX OSN 1500B sub-rack, the slots valid for the SSR2PD1A01 vary with the cross-connect capacity of the sub-rack. When the cross-connect capacity is 20 Gbit/s, the PD1 can be installed in divided slots 1–3, 6–8, and 11–13.The valid slots of SSR2PD1A are slot 1, 2 3, 6, 11, 12, 13, 15, 16, 17.

The feature code of the SSR2PD1A indicates the type of interface impedance. The relationship between the feature code of the PD1 and the type of interface impedance is: the feature code of SSR2PD1A and SSR1PD1 is A01; Type of Interface Impedance is 75-ohm.

Huawei transmission boards [http://www.thunder-link.com/]own a good word-of-mouth and a large scale market in the overseas. With the rapid development of the society and economy, the prospect of this field will be better and better. What’s more, SSR2PD1A will play a duteous board, service the people and society.

Summary: This document is about Un pairing connection for [www.thunder-link.com]Huawei SDH equipment E1 X connect because different time slot naming label for TUG-3 between frame type Lucent Mode equipment to frame type Huawei Mode. The product family is NG-SDH and the product is optiX OSN 3500.
When we create a connection between [www.thunder-link.com]Huawei Optical transmission equipment with difference frame type (Lucent mode in one side and Huawei Mode in the other end) we find some difficulty,match x connect. If we configure 63 E1 x connection straightly using VC12 level or straightly using VC4 level between this 2 equipment as below topology,we find only 21 E1 Time slot alignment are matched and 42 E1. And no alarm.

Cause Analysis:

First we found only 21 E1 is match (alignment Time slot properly).
Time slot in MGW A (Huawei frame type) is match with time slot in MGW B (Lucent frame type) for time slot 1,4,7,10,13,16,19,23,26,29,32,35,41,45,48,51,54,57,60 and 63.
The time slot is un-match / not properly alignment.

This un- match time slot alignment due to Time slot state for TUG3 for Interleave/Lucent are different with ITU/Huawei.

If Huawei frame type state Time Slot 1, the TUG3 state are 1.1.1 and in Lucent state time slot 1, the TUG3 state are the same as 1.1.1 that why for time slot 1 is match.
If Huawei state time slot 2, the TUG3 state are 2.1.1, but in Lucent state time slot 2 is for TUG3 1.1.2. The time slot are unmatched.
If Huawei state time slot 3, the TUG3 state are 3.1.1, but in Lucent state time slot 3 is for TUG3 1.1.3. The time slot are unmatched.

To avoid this mismatch we need to create x connect using VC12 level refer to original TUG3 for each connection.
If Huawei claim for time slot “2″ (2.1.1) to be connect to with Lucent time slot “2″ (1.1.2), we need TUG3 we need to make x connect VC12 time slot.
scheme by order (ITU-T) time slot 2 connect to time slot 22 or make x connect VC12 time slot scheme by Interleave time slot 22 connect to time slot 2. And so on.

As the result, to make sure correct alignment distributed time slot for each equipment
1. We need to create x connect base on original time slot for each equipment base on their original TUG3 scheme.
2. Or we can ask every equipment admin to change the frame type to be match.

Summary:
Creep occurs on SD585 soldered balls of some cross-connect boards on Huawei transmission OptiX OSN 3500 equipment so these boards repeatedly reset, fail to work, and report BD_STATUS alarms.
[Problem Description]
Trigger conditions:
There is a possibility that this problem occurs as a result of long-term exposure of the boards involved to high temperature.
Symptom:
1. Boards are reset repeatedly and fail to work.
2. NEs may report BD_STATUS alarms or COMMUN_FAIL alarms on cross-connect boards.System control boards may report BIOS_STATUS alarms on cross-connect boards.
Identification method:
The problem can be identified if the following two conditions are met:
1. The boards are manufactured in Feb 2010, Apr 2010, May 2010, Jul 2010, Aug 2010, or Mar 2011.
2. The cross-connect boards are repeatedly reset and fail to work. The board BOMs are found in the attached Board Delivery Information.
[Root Cause]
The SD585 chip radiator uses the thick spring, which applies high levels of stress to the chip. The soldered ball of the SD585 chip may deform and short-circuit as a result of long-term exposure to high temperature. Therefore, the board repeatedly reset and fail to work.
[Impact and Risk]
1. Services are not influenced because of the 1+1 protection scheme is configured on the cross-connect boards. When a cross-connect board is faulty, services are switched over to the other cross-connect board.
2. In extra situations, both cross-connect boards configured in the 1+1 protection scheme become faulty in a short time. As a result, the NE fails to work and services are interrupted.
[Measures and Solutions]
Recovery measures:
Replace the faulty cross-connect board.
Reference and buy new similar boards in www.Thunder-link.com network product distributors
Preventive measures:
None
Solution:
Replace the faulty boards.
Material handling after replacement:
Return the spare parts for repair.
[Rectification Instructions]
Replace the faulty boards.
SSN1SXCSA02 (03030KBM) boards are out of production, so replace SSN1SXCSA02 boards with SSN1SXCSA01 (03030DKF) when filling in an electric process application for board rectification in batches. The two kinds of boards can be mixedly inserted or completely replace each other. Active and standby boards of the same type are recommended.

Summary: The clock chips used on some TN55N02 and TN55TOX boards of Huawei OSN product OptiX OSN 8800 NEs have design defects. As a result, the failure rate of the chips is 5% after they are in service for 2 years. In the case of a clock chip failure, services on these boards will be interrupted and cannot be restored even after you remove and reinsert or perform a cold reset on the boards.
[Problem Description]
Trigger conditions:
The chip failure rate is 5% within 2 years. The chip failure rate is proportional to the service period but is irrelevant to application scenarios.
Symptom:
On the transmission faulty board, a Hard_Bad alarm is reported and cannot be cleared and services are interrupted.
Identification method:
1. Check the barcodes of the boards against the attachment. If the barcodes are included in the attachment which provided by the official website, you can determine that the boards are at risk of a clock chip failure.
2. If the previously described symptom occurs on a TN55TOX01 or TN55NO201 board, you can determine that the board is at risk of a clock chip failure.
[Root Cause]
The clock chip has design defects. As a result, the TN55NO2 and TN55TOX boards have 5% failure rate within 2 years.
[Impact and Risk]
OptiX OSN 8800: On a board with a defective clock chip, a Hard_Bad alarm is reported and services are interrupted. The services cannot be restored even after you remove and reinsert or perform a cold reset on the board. The chip failure rate is 5% within 2 years and is proportional to the service period.
[Measures and Solutions]
Recovery measures
Replace the boards with a defective clock chip.
Solutions:
Replace the boards with a defective clock chip.

[Problem Description]
Trigger condition:
The problem described in the pre-warning is triggered when the following four conditions are all met:
1.TPS is triggered or restored by the TPS protection group consisting of [Huawei network product distributor ]transmission boards in slot 12 and 13.
2. The NE type is [Huawei transmission product supplier]OptiX OSN 1500B and its version is included in the “Versions Involved” part.
3. The NE is configured with a TPS protection group consisting of processing boards in slots 12 and 13.
4. The NE is configured with a service processing board that needs work with an interface board in slot 7 or 8, such as SSR1PD1 and SSR2PD1. In addition, services are configured on the board.
Symptoms:
The fault scenarios are as follows:
Scenario 1: Boards in slots 12 and 13 form a TPS protection group, and a board in slot 7 or 8 is not configured with TPS protection.
When TPS is triggered by the TPS protection group consisting of boards in slots 12 and 13, services on the board in slot 7 or 8 are interrupted and the T_ALOS alarm is reported. After the TPS is restored, the T_ALOS alarm is cleared and the services on the board are recovered.
Scenario 2: Boards in slots 12 and 13 form a TPS protection group, and a board in slot 7 or 8 is configured with the TPS protection group.
1. TPS is not triggered on the boards in slots 7 and 8:
When the TPS protection group consisting of boards in slots 12 and 13 triggers TPS, services on the boards in slot 7 and 8 are interrupted, and the boards in slots 7 and 8 report the T_ALOS alarm. When the TPS protection group consisting of boards in slots 12 and 13 is restored to the idle state, the T_ALOS alarm is cleared and the services on the boards in slots 7 and 8 are recovered.
2. If TPS is triggered on the board in slot 7 or 8:
When TPS protection group consisting of boards in slots 12 and 13 is restored to the idle state, services on the board in slot 7 or 8 are interrupted and the T_ALOS alarm is reported. When TPS on the board in slot 7 and 8 is restored, the services on the board are recovered and the T_ALOS alarm is cleared.
Identification methods:
The problem described in the pre-warning is triggered when the following three conditions are all met:
1. The NE type is OptiX OSN 1500B and its version is included in the “Versions Involved” part.
2. The NE is configured with TPS protection groups consisting of the service processing boards in slots 12 and 13. In addition, the NE is configured with a service processing board in slot 7 or 8 that needs to work with an interface board (such as SSR1PD1 and SSR2PD1).
3. Services on the boards in slots 7 and 8 are interrupted and the T_ALOS alarm is reported, which is triggered by TPS or TPS restoration in the TPS protection group consisting of boards in slots 12 and 13.
[Root Cause]
The software version has defects. Boards in slot 12 and 13 form a TPS protection group. When TPS is triggered or restored, relays on boards in slots 16 and 17 are switched no matter whether two interface boards are required to be configured on the service processing board in slot 13.
If two interface boards are required by the board in slot 13, the valid slots are slots 16 and 17.
If one interface board is required by the board in slot 13, the valid slot is slot 16.
When a service processing board with an interface board is required by the board in slot 7 or 8 (the interface board is in slot 15 or 17), services on the boards in slots 7 and 8 are affected due to TPS or TPS restoration in the TPS protection group consisting of the boards in slots 12 and 13.
[Impact and Risks]
TPS and TPS restoration will interrupt the services on boards in slots 7 and 8 which are configured with a TPS protection group consisting of boards in slots 12 and 13.
Measures and Solutions
Recovery measures:
It is recommended that you restore TPS for scenario 1 and trigger TPS to ensure that two TPS protection groups are in the idle state for scenario 2.
Workarounds:
Currently, there are two methods available for working around the problem.
1. Do not configure TPS protection groups for boards in slots 12 and 13.
2. Configure TPS protection groups for boards in slots 12 and 13 on an OptiX OSN 1500B subrack but do not configure service processing boards or configure service processing boards that do not work with interface boards in slots 7 and 8.

[Problem Description]
Trigger conditions:
The problem occurs when some TNH1EGT1 boards of OSN500 have been working for 72 hours or less.
Note
This problem does not necessarily occur on each TNH1EGT1 board. Those that have been properly working for 72 hours will not have this problem.
Fault symptoms:
1. Services carried by the the above transmission board are interrupted.
2. The TNH1EGT1 board continuously reports the ALM_GFP_DLFD alarm, LOP or AIS alarms.
3. Re-installing the board, or powering off and powering on the NE may recover services; however, the problem will recur later.
Note
Cold resets cannot solve the problem nor trigger the problem.
Identification method:
1. Check whether the service is configured correctly on the board.
2. Ensure that service configuration is correct and check whether alarms persist. If the GFP alarms (ALM_GFP_DLFD), LOP alarms (AU_LOP, TU_LOP_VC3, TU_LOP_VC12), or AIS alarms (AU_AIS, TU_AIS_VC3, TU_AIS_VC12) persist, this problem may occur.
3. Check whether the board is produced before October 26, 2011.For the bar code of the board, see the appendix Delivery List of Risky TNH1EGT1 Boards.xls.
4. Re-insert the TNH1EGT1 board. The problem is solved but recurs after a while.
[Root Cause]
No bias circuit was configured at the receive end of the upstream and downstream LVDS receivers on the TNH1EGT1 board. As a result, the bias voltage approached the range specified in chip files. In addition, due to individual differences of LVDS receivers, there was a possibility that the output of the LVDS receivers was abnormal, which triggers service interruption and alarms report such as the ALM_GFP_DLFD alarm, LOP and AIS alarms.
The TNH1EGT1 board produced after October 26, 2011 will not trigger this problem.
[Impacts and Risks]
Services are interrupted.
[Measures and Solutions]
Recovery measures:
Re-insert the TNH1EGT1 board.
Note
Re-installing the TNH1EGT1 board cannot completely solve the problem. The problem may recur within 72 hours after the operation.
Solution
1. To solve the problem that the bias voltage approached the specified range in the AC coupling, change the AC coupling to DC coupling on the LVDS service bus in the TNH1EGT1 board.
By using this solution, the TNH1EGT1 board produced after October 26, 2011 has no such problem.
2. The TNH2EGT1 board does not have this problem; therefore, it can replace the TNH1EGT1 board.

Abstract
Few SSN1GSCC02 and SSN3GSCC02 boards have degraded clock signals due to the critical-state quality of clock signals on the orderwire chip SPI and individual variances among boards (for example, in PCB layout and build-out resistor precision). There is a low possibility that these boards experience warm resets. If this occurred on an active SSN1GSCC02 or SSN3GSCC02, the NE housing the SSN1GSCC02 or SSN3GSCC02 board may become transiently unreachable by the NMS.
[Problem Description]
Trigger condition:
There is a low possibility that the SSN1GSCC02 and SSN3GSCC02 boards manufactured earlier than August 9th, 2013 confronts this problem.
Symptom:
The SCC board occasionally reports the HARD_BAD (0xff 0xff 0xff 0×00 0×01) alarm that cannot be cleared after a warm reset due to an abnormal orderwire interruption. If the active SCC board is warm reset but does not report the HARD_BAD alarm, the NE is transiently unreachable for the NMS; if the active SCC board reports the HARD_BAD alarm, the active/standby switching is triggered. If the standby SCC board is warm reset, the standby SCC board reports the COMMUN _ FAIL (0×01 0×00 0×03 0xff 0xff) alarm, and the COMMUN-FAIL alarm clears after the standby SCC board starts working.
Identification method:
When the following two conditions are met, it can be determined that the problem is triggered:
1. The SSN1GSCC02 or SSN3GSCC02 board manufactured earlier than August 9th, 2013 serves as the system control board. Query the type and production date (obtained from the bar code) of a system control board using either of the following methods:
Method 1:
On the Navigator, run the :cfg-get-bdinfo:sccbdid command, as shown below:
cfg-get-bdinfo:24
BOARD-ALL-INFO
VERSION-INFO
[ArchivesInfo Version]
ArchivesInfoVersion=2.0
$[Log]
$Log1=14336,03020DCM0,2009-12-03
[Board Properties]
BoardType=SSN3GSCC02
BarCode=020DCM109B000016
BOM=BOM03020DCM00
Manufactured=2009-12-03
ManufactureCode=1
The type and production date of the system control board can be obtained from BoardType and BarCode respectively.
Method 2:
On the NMS (for example, U2000), choose Inventory > Project Document > Board Manufacture Information from the menu bar.
The type and production date of the system control board can be obtained from BoardType and BarCode respectively.
As shown in the above figure, the type and bar code of the system control board are SSN3GSCC02 and 020DCM109B000016 respectively. The 9th hexadecimal digit of a bar code indicates the year and the 10th indicates the month. The hexadecimal digit B equals the decimal digit 11. Therefore, the system control board queried above is manufactured in November, 2009.
2. An SSN1GSCC02 or SSN3GSCC02 board is reset three times or more within 24 hours due to abnormal orderwire interruptions. On the Navigator, run the :mon-get-errlog:sccbdid command to query the reset record of an SSN1GSCC02 or SSN3GSCC02 board, as shown below:
mon-get-errlog:24
No.1035: 2013-08-14 08:16:49 BOARD=024 TYPE=0xf0000040 SOFTTYPE=002
No.1036: 2013-08-14 08:31:46 BOARD=024 TYPE=0xf0000040 SOFTTYPE=002
No.1037: 2013-08-14 15:47:49 BOARD=024 TYPE=0xf0000010 SOFTTYPE=002
No.1038: 2013-08-14 16:56:39 BOARD=024 TYPE=0xf0000010 SOFTTYPE=002
084# 2013-08-14 08:14:45 fatal task errorcode=0xffffffff, Line 00000 in reboot:interrup
085# 2013-08-14 08:29:43 fatal task errorcode=0xffffffff, Line 00000 in reboot:interrup
086# 2013-08-14 15:45:26 ExcptErr: pc=0×00000000, SR=0×81030, FaultAddr=0×00000700, DataBuff=0x019894c4, taskname=interrupt
087# 2013-08-14 16:54:16 ExcptErr: pc=0×00000000, SR=0×81030, FaultAddr=0×00000700, DataBuff=0x019894c4, taskname=interrupt
In query results, if the reset type (TYPE) is 0xf0000040 or 0xf0000010, and the field interrup appears in the corresponding reset cause, the SSN1GSCC02 or SSN3GSCC02 board experiences a reset due to an abnormal orderwire interruption.
[Root Cause]
Few SSN1GSCC02 and SSN3GSCC02 boards have degraded clock signals due to the critical-state quality of clock signals on the orderwire chip SPI and individual variances among boards (for example, in PCB layout and build-out resistor precision). Therefore, the register is incorrectly read or written, an abnormal orderwire interruption occurs, and then an SSN1GSCC02 and SSN3GSCC02 board is reset. In addition, orderwire interruption and nest occurs, as well as stack overflow. As a result, the register values of power switching control are mistakenly modified, and the HARD-BAD alarm is reported.
This problem is addressed in SSN1GSCC02 and SSN3GSCC02 boards manufactured later than August 9th, 2013.
[Impact and Risk]
1. A traditional NE experiences a warm reset and no active/standby switching is triggered on a traditional NE housing two system control boards. If the active system control board or the single system control board of a traditional NE experiences a warm reset, the NE will become transiently unreachable by the NMS. If the standby system control board of the NE experiences a reset, there is no impact or risk.
2. During the active/standby switching, if data is being backed up in batches, data loss may occur.
3. If the active system control board of an ASON NE experiences a warm reset, the NE will lose the rerouting capability temporally so the services may interrupt.
Preventive measures:
Replace the problematic system control board with an SSN1GSCC02 or SSN3GSCC02 board manufactured in September 2013 or later, or with an SSN4GSCC board. For ASON NEs, replace the faulty SCC board with the SSN4GSCC board.

Abstract
After the network connectivity element[www.Thunder-link.com] (NE) is powered off, the tag of the VCTRUNK port on the ET1 board is lost. As a result, data services are interrupted.
Trigger conditions
The tag of the VCTRUNK port on the ET1 board is modified, and then the NE is powered off.
Fault symptoms
After the NE is powered off and then reset, the tags of some VCTRUNK ports on the ET1 board of the Metro1000v3 [http://www.thunder-link.com/HUAWEI-OPTIX-METRO1000_p182.html]are lost (the tag state changes from tag to access). As a result, the data services on the ports are interrupted.
You can confirm that the NE has entered the BIOS state if either of the following conditions is met:
1. The NE is configured with the ET1 board. The NE version is included in the involved versions.
2. Run the :dbms-query:”BdPara16.dbf”,fdb0 and :dbms-query:”BdPara16.dbf”,fdb1 commands to check whether any records similar to the red fields (04c5) shown in the following example exist in the BdPara16 tables in fdb0 and fdb1. If the similar records exist, it indicates that the tag has been modified. Check the blue characters at the end of the records: 0 indicates VCTRUNK 1, 2 indicates VCTRUNK 2, and the rest may be deduced by analogy.
3. Run the :ethn-cfg-get-tag:4,vctrunkX command to check the tag of the corresponding VCTRUNK port (X). If the displayed tag state is tag, there is a probability that the tag is lost (that is, the tag state changes from tag to access) after the NE is powered off.
[Root Cause]
For VCTRUNK ports on the ET1 board, the default tag state stored in the memory is tag, whereas that stored in the database on the flash memory is access. The tag field is stored in the database on the flash memory only after the tag state is modified from tag to access. In addition, the modification record is kept in the database on the flash memory (modification from access back to tag included).
For the VCTRUNK attribute of the ET1 board, the variable stored in the memory consists of 64 bytes. In the codes for database storage, the number of bytes is set to 16. As a result, the last 48 bytes (VCTRUNK tag included) are not stored in the database. Therefore, the VCTRUNK tag state stored in the database remains access.
Impact and Risks
Generally, the default VCTRUNK tag state (tag) is used. This field is not stored in the database on the flash memory if the tag state is not modified. In this case, the proble
does not occur. If the tag state is stored in the database on the flash memory, this problem occurs after the NE is reset. As a result, the data services on the corresponding VCTRUNK ports are interrupted.
Recovery measures
Set the tag state of the relevant VCTRUNK ports to tag.
Solution
Upgrade to V300R005 C01SPC180 (5.37.05.12P05) or later version.
Note: For the NE using SS46SCB, replace SS46SCB with SS49SCB and upgrade to V300R005 C01SPC180 (5.37.05.12P05) or later version.

Summary:
0.03% to 0.1% of certain models of data boards and central switching boards with the basic BIOS version of 1.21 or earlier on OSN 550/500 NEs fail to start up after the NEs are upgraded, which results in the rollback of the NE version. The issue is solved after the boards are replaced.

Huawei OSN 550Trigger conditions:
This problem may occur if the following conditions are met at the same time:
An NE is upgraded.
The NE uses one of the following boards: TNH1EM6T/F, TNM1EF8F, TNH1CSHDA/B, TNM1PCXLG, TNM1PCXX, TNM1PCXLX, TNM1PCXGB, or TNM1PCXGA.
The basic BIOS version of the board is 1.21 or earlier.
Symptom:
The faulty board stays in the BIOS state after an upgrade and does not start up. The fault is cleared after the NE version is rolled back.
Identification method:
1. Query the version
2. After an upgrade, the STAT indicator on the board is red and the other indicators are off, which indicates that the board stays in the BIOS state and fails to start up. The board starts up after the NE version is rolled back.
The following interfaces are displayed in the case of an automatic rollback after an upgrade failure on the U2000.When both of the preceding conditions are met, the fault can almost be identified.
[Root Cause]
On the basic BIOS of version 1.21 or earlier, the time sequence of the CPU adder is not the optimal configuration. As a result, there is a low possibility that the board fails to start up after an upgrade.
[Impact and Risk]
The board does not start up after an upgrade, which results in service interruptions. The fault is cleared after the NE version is rolled back.
[Measures and Solutions]
The fault is automatically cleared after the NE version is rolled back.
Solution:
The basic BIOS of boards on OSN 500/550 cannot be upgraded online. If the fault occurs on an NE during an upgrade, replace the board with a new board with the basic BIOS version of 1.22 or later.
Material handling after replacement:
Return the replaced board to Huawei, if the board supplied by thunder-link.com, then please contact your sales representative.

Summary:
The TN52FCD fan tray assembly on the OptiX OSN 8800 T32/T64 subrack occasionally has its fans stopped, leading to a FAN_FAIL or FAN_FAULT alarm on the subrack.
[Problem Description]
Trigger condition:
This problem occurs when the following conditions are met:
The TN52FCD fan tray assembly on the OptiX OSN 8800 T32/T64 subrack works in auto speed mode and the fans rotate at the lowest speed.
The optical coupler that is used to convert the PWM signal inside the fan tray assembly is provided by Renesas Electronics in lot 146.
NOTE
Altogether 492 fan tray assemblies (BOM code: 02120495) are equipped with Renesas optical couplers of this delivery lot. The table below shows the distribution of these optical couplers.
Symptom:
Symptom 1: A FAN_FAIL or FAN_FAULT alarm is present on the U2000 and the STAT indicator on the fan tray assembly is steady red or orange. Physically, the STAT indicator is steady red when the FAN_FAIL alarm is present and is steady orange when FAN_FAULT is present. In addition, the noise generated by the fans is sometimes large but sometimes small, alternating at intervals of 3 to 5 seconds. In general, the noise is less than 85 dB.
Symptom 2: A FAN_FAIL or FAN_FAULT alarm is present on the U2000 and the fans inside the fan tray assembly have stopped working. Physically, the STAT indicator is steady orange when the FAN_FAULT alarm is present and is steady red when FAN_FAIL is present.
Identification method:
To determine whether the problem corresponds to this warning notice, perform the following steps:
1. On the U2000, check that a FAN_FAIL or FAN_FAULT alarm is reported for the fan tray assembly.
2. Check that the STAT indicator (in the red circle in the figure below) on the fan tray assembly is steady red or orange. (Skip this step if you are not in the [http://www.thunder-link.com]equipment[/http://www.thunder-link.com] room.)
3. Change Fan Speed Mode to Adjustable Speed Mode and set the fan rotation speed to the Medium Speed or Medium-High Speed. Then check whether the alarm has cleared. If the alarm has cleared, the problem corresponds to this warning notice. If the alarm persists, the problem does not correspond to this warning notice, but is related to other fan faults.
[Root Cause]
The PWM signal, which is used to adjust the fan rotation speed, generated by the logic of the fan tray assembly is converted by the optical coupler of the fan tray assembly before it is sent to the fans. A small number of OptiX OSN 8800 T32/T64 subrack fan tray assemblies are equipped with Renesas optical couplers delivered in lot 146, while these optical couplers have a defect to introduce a large attenuation. As a result, the duty cycle of the PWM signal is large and the PWM signal is attenuated greatly. When the system automatically adjusts the fan rotation speed to the lowest speed based on the received PWM signal, the fans are likely to stop working. When the fans stop, a FAN_FAIL or FAN_FAULT alarm is generated.
[Impact and Risk]
This problem does not affect the normal operation of the OptiX OSN 8800 T32/T64 subrack.
1. A FAN_FAIL or FAN_FAULT alarm is reported only when the system instructs the fans to rotate at the lowest speed.
2. If the system temperature increases after the fans stop working, the system will instruct the fans to rotate at a higher speed. When receiving the instruction, the fans will start rotating and correctly adjust their fan speed to ensure efficient heat dissipation.
This problem affects user experience. The FAN_FAIL or FAN_FAULT alarm and the lit STAT indicator will induce the customer to believe that a fan failure or fault has occurred.
[Measures and Solutions]
Recovery measures:
On the U2000, change the Fan Speed Mode to Adjustable Speed Mode and set the fan rotation speed to Medium Speed or Medium-High Speed.
Workarounds:
None.
Preventive measures:
On the U2000, change the Fan Speed Mode to Adjustable Speed Mode and set the fan rotation speed to Medium Speed or Medium-High Speed.If the cumstors do not accept the measure,replace the defective fan tray assembly.
Material handling after replacement:
The replaced fan tray assembly is scrapped.
[Attachment]
List of Delivered Optical Couplers (02120495) with Renesas Optical Couplers Delivered in Lot 146.