Commissioning Procedure (OTN)

This section describes the general commissioning procedures for the OTN system.
The commissioning procedures for the equipment can be divided into two parts: optical power commissioning and network commissioning.

• Optical power commissioning procedures individually commission the optical power values of NEs and boards based on the optical signal flow. They also remove the abnormal attenuation of lines or boards based on the requirements of optical power, and the gain and insertion losses of the boards.
• Network commissioning procedures include the commissioning protection function, commissioning feature function, testing bit errors, and other functional commissioning operations at the network level.

 NOTE:

For the ASON network, the commissioning procedures and requirements refer to Automatic Commissioning Process and Commissioning Items for ASON Network.

Figure 1 and Figure 2 provides the general commissioning procedures.

Figure 1 General commissioning procedures for OptiX OSN 8800/OSN 6800

Figure 2 General commissioning procedures for OptiX OSN 3800

You can perform the commissioning and configuration during deployment of the equipment by using either the iManager U2000 (U2000 for short) or the OptiX iManager U2000 Web LCT (Web LCT for short). All the operations that can be performed on the Web LCT can be performed on the U2000. Compared with U2000, the Web LCT has lower requirements on the computer hardware and can be started quickly.
Table 1 lists the tasks for the commissioning and configuration during deployment.

Table 1 List of tasks for the commissioning and configuration during deployment

No.	Task	Mandatory/Optional	Tool
1	Creating NEs in Batches.	Mandatory	U2000 or Web LCT
2	Creating Optical NEs.	Mandatory	U2000
3	Setting NE Power Consumption Threshold.	Mandatory	U2000
4	Uploading the NE Data.	Mandatory	U2000
5	Setting NE ID and IP.	Mandatory	U2000 or Web LCT
6	Synchronizing the NE Time with the U2000/Web LCT Server Manually.	Mandatory	U2000 or Web LCT
7	Setting Performance Monitoring Parameters of an NE.	Mandatory	U2000 or Web LCT
8	Setting Manually Extended ECC Communication. Perform this task when the network uses HWECC for communication and more than four Huawei equipment NEs use the extended ECC for communication.	Optional	U2000
	Configuring IP over DCC. Perform this task when the network uses IP over DCC for communication.	Optional	U2000
	Configuring OSI over DCC. Perform this task when the network uses OSI over DCC for communication.	Optional	U2000
10	Checking Network-Wide Software Version.	Optional	U2000
11	Configuring Boards.	Mandatory	U2000 or Web LCT
12	Creating Fiber Connections in Graphic Mode. Perform this task on the U2000.	Mandatory on the U2000	U2000
13	Creating Single-Station Optical Cross-Connection. Perform this task when ROADM stations are configured on the actual network.	Optional according to the network	U2000 or Web LCT
14	Creating OCh Trails by Trail Search. Perform this task on the U2000.	Mandatory on the U2000	U2000
15	Configuring the OSNR Detection Based on Optical Doctor. Perform this task on the U2000.	Optional	U2000
16	Commission optical power by using one of the following methods as required: Commissioning Optical Power on Site Remotely Commissioning Optical Power NOTE: This document uses a 40-channel system as an example to describe optical power commissioning. The optical power commissioning methods for an 80-channel system are similar. The main difference is that the 40-channel system and 80-channel system have different requirements on nominal single-wavelength optical power and single-wavelength incident optical power for OA boards.	Mandatory	U2000 or Web LCT
17	Configuring Services.	Mandatory	U2000
18	Configuring System Features.	Mandatory	U2000
19	Viewing Current Alarms on an NE and Removing Abnormal Alarms.	Mandatory	U2000 or Web LCT
20	Testing Protection Switching.	Mandatory	U2000
21	Testing Data Features.	Mandatory	U2000
22	Testing System Features.	Mandatory	U2000
23	Testing Ethernet Service Channels.	Mandatory	U2000
24	Configuring Orderwire of OTN System and Configuring the Orderwire Phone in an OCS System.	Optional	U2000 or Web LCT
25	Testing Orderwire Functions.	Optional	U2000 or Web LCT
26	Testing Bit Errors.	Mandatory	OTN analyzer or SDH analyzer
27	Checking the entire network against the Checklist for Commissioning During Deployment. Ensure that the network configurations are correct.	Mandatory	U2000 or Web LCT
28	Backing Up the NE Database to the SCC Board.

Related:

How to Use the Ethernet Test Frames on the OptiX OSN 6800?

TD Alarms Falsely Reported by Some Boards Using Pluggable Optical Modules in WDM Products

When the Software Version Compatibility Issue on the TNF2LQM and TNF2LDGF2 Boards in OptiX OSN 1800

The EPON LLID Management on ont llid

Function Description

This topic provides the commands related to the EPON Logical Link (Identity configuration LLID) configuration. The EPON LLID can be used to identify ONU in the system, and can be designated in ONU discovery process.

Function

The ont llid command is used to configure a DBA profile and stream control profile for the EPON ONT logical link identifier (LLID) in distributed mode. When you need to configure the upstream bandwidth, a DBA profile and stream control profile for the EPON ONT LLID in distributed mode, run this command.
The undo ont llid command is used to unbind a DBA profile and stream control profile from the EPON ONT LLID in distributed mode. When you need to unbind a DBA profile and stream control profile from the EPON ONT LLID in distributed mode, run this command.

Format

ont llid portid ontid llid-list {{ dba-profile-id profile-id | dba-profile-name profile-name } | ont-car { traffic-table-index | traffic-table-name traffic-table-name } }*
undo ont llid portid ontid llid-list { dba-profile | ont-car }*

Parameters

Parameter	Description	Value
portid	Indicates the EPON port ID.	Please see Differences Between Shelves.
ontid	Indicates the ONT number.	Numeral type. Range: varies with the board type.
llid-list	Indicates the ONT LLID list. The ONT LLID list supports "," and "-". For example, the llid-list value 0, 2-3, indicates LLIDs 0, 2, and 3. Currently, LLID only supports 0.	Character string type, a string of 1–13 characters. The LLID is in the numeral type and ranges from 0–0.
dba-profile-id profile-id	Indicates the DBA profile ID. To bind a DBA profile by specifying the profile ID, use this parameter. A DBA profile is used to configure the upstream bandwidth of the ONT.	Numeral type. Range: 1–512.
dba-profile-name profile-name	Indicates the DBA profile name. To bind a DBA profile by specifying the profile name, use this parameter. A DBA profile is used to configure the upstream bandwidth of the ONT.	Character string type, a string of 1–33 characters.
ont-car traffic-table-index	Indicates the traffic control profile ID. To set the CAR value in an ONT line profile, use this parameter. The traffic control profile is used to control downstream traffic of the ONT.	Numeral type. Range: 0–1023.
traffic-table-name traffic-table-name	Indicates the traffic control profile name. To set the CAR value in an ONT line profile, use this parameter. The traffic control profile is used to control downstream traffic of the ONT.	Character string type, a string of 1–32 characters.

Modes

EPON mode, OSN 6800

Level

Operator level

Usage Guidelines

• Run the config command to enter global config mode, and then run the interface epon command to enter EPON mode.
• This command is used to configure a DBA profile and stream profile in distributed mode. This command and the command for configuring a DBA profile and stream control profile in service profile mode are mutually exclusive. If a DBA profile and stream profile have been configured in service profile mode and you need to run this command, run the undo llid command to cancel the default values of the DBA profile and stream control profile in service profile mode first. If this command has been executed and you need to bind the LLID with a DBA profile or CAR profile in service profile mode, run the undo ont llid command in the EPON mode to unbind the DBA profile and stream control profile from the LLID first.
• When a DBA profile is not bound to the LLID in service profile mode or discrete mode, the default bandwidth is assured bandwidth and is 2 M.
• The restrictions of the upstream bandwidth of PON port the ONT related to are as follows:
  • The fixed bandwidth and assured bandwidth of all the TCONT of all the ONTs reated to the PON port must be smaller than, or equal to the allocable bandwidth of the PON port. The added ONT will use bandwdth, and the allocable bandwidth of the PON port will decrease. You can run the display port info(gpon) command to query the maxium allocable bandwidth of the PON port. The queried result is the allacable bandwith minus the ONT fixed bandwidth cost, and the fixed bandwidth and assured bandwidth that have been allocated.
  • The maximum bandwidth configured in the DBA profile the ONT bound to must be smaller than, or equal to the maximum allocable bandwidth of the PON port that the ONT is related to. You can run the display port info(gpon) command about the PON port that has not been bound by an ONT to query the maximum allocable bandwidth of the PON port.

Example

To bind DBA profile 2 and traffic control profile 2 to ONT LLID 0, do as follows:

huawei(config-if-epon-0/3)#ont llid
{ portid<U><0,7> }:0
{ ontid<U><0,63> }:0
{ llid-list<S><Length 1-13> }:0
{ dba-profile-id<K>|dba-profile-name<K>|ont-car<K> }:dba-profile-id
{ profile-id<U><1,512> }:2
{ <cr>|ont-car<K> }:ont-car
{ traffic-table-index<U><0,1023>| traffic-table-name<K> }:2

  Command:
          ont llid 0 0 0 dba-profile-id 2 ont-car 2

To unbind DBA profile 2 and traffic control profile 2 to ONT LLID, do as follows:

huawei(config-if-epon-0/3)#undo ont llid
{ portid<U><0,63> }:0
{ ontid<U><0,63> }:0
{ llid-list<S><Length 1-13> }:0
{ dba-profile<K>|ont-car<K> }:dba-profile
{ <cr>|ont-car<K> }:ont-car

  Command:
          undo ont llid 0 0 0 dba-profile ont-car

System Response

• The system does not display any message after the command is executed successfully.

More Blog:

When cannot ping the server through S5700HI VLL network.

How to add an ethernet interface on Solaris Operating Syster?

If 5700 stack member fall out caused by A large number of MAC entries delete.

Switching Fails Due to Incorrect SNCP Protection Mode on the WDM Equipment

Switching fails due to incorrect SNCP protection mode on the WDM equipment.

Product

OptiX OSN 6800

OptiX OSN 3800

Fault Type

Protection

ODU2_PM_SSF

Symptom

 At site A, the TN12NS2 board is configured with SNCP protection. At site D, SNCP protection is configured. At sites B and C, the TN12NS2 boards are configured in electrical regeneration mode. After the fiber between site B and site C is broken, however, site A does not perform any switching. As a result, services are interrupted.

Cause Analysis

The possible causes of the fault are as follows:

• The TN12NS2 board at site A is faulty.
• The SCC board at site A is faulty.
• The cross-connect board at site A is faulty.
• The protection type at site A is incorrectly configured.

Procedure

1. Query the alarms and performance events of site B on the T2000. It is found that the output optical power of the NS2 board at site B is –60 dBm after the fiber between site B and site C is broken. The NS2 board reports the R_LOS alarm.
2. Query the alarms at site A. The TN12NS2 board at site A reports the ODU2_PM_SSF alarm, but does not report any OTU-layer alarm. In addition, the ODU-layer signals at site A are detected invalid.
3. Query the protection type at site A. The SNCP protection scheme works in SNC/I mode. When the electrical regeneration function is provided, the SNCP protection scheme in SNC/I mode triggers a switching only after it detects an SM-layer alarm, instead of a PM-layer alarm. Huawei's engineers change the SNC/I mode to the SNC/N mode. Then, services can be switched successfully.

Result

The problem is resolved.

Reference Information

Conclusions and suggestions for this case are as follows:

When the SNCP protection scheme is configured for the WDM equipment with the electrical regeneration function, the protection type needs to be set to the SNC/N mode.

More blog:

ADSL2+ service(ADEE service boards not working due to Damaged protection fuses (F1))

End-to-End GE Services Cannot Be Created on the OptiX OSN 6800

Comunication failure between the GSCC and EOW Gateway NE

Incorrect Client-Side Service Type Causes Failure of Interconnection With a Router

Incorrect client-side service type causes a failure of interconnection with a router.

Product

OptiX BWS 1600G, OSN 6800, OSN 8800

Fault Type

Equipment Interconnection

Client Equipment

Symptom

On a network, an ETMX board on the OptiX BWS 1600G is used to receive a 2.5 Gbit/s service from a router on the client side. Client-side channels run properly after an expansion is performed on the network.

When the ETMX board on the OptiX BWS 1600G receives the 2.5 Gbit/s service, interconnections with ports on the router are successful but exchanges of protocols fail. After an outloop is configured on the ETMX board at the local end by using the NMS to loopback the service to the router, port interconnections and protocol exchanges are successful. After an inloop is configured on the WDM-side optical port on the ETMX board at the remote end by using a fiber patch cord to loopback the service to the router, port interconnections are successful but protocol exchanges fail. This indicates that the fault lies on the WDM-side link or interconnected ports.

Cause Analysis

The analysis of the problem is as follows:

1. An SDH analyzer is used to test the WDM-side channel after the expansion is performed. No exception is found.
2. After the outloop on the ETMX board at the local end is performed, port interconnections and protocol exchanges are successful. This indicates that the router is running properly.
3. After the inloop on the ETMX board at the remote end through a fiber patch cord is performed, protocol exchanges fail. This indicates that protocol configuration is incorrect after signals are transmitted from the router to the ETMX board.

The preceding information shows that the problem is due to incorrect configurations of the ETMX board.

Procedure

1. Check the WDM-side configurations of the board. Service Type for services received from the client side of the ETMX board can beSDH, SONET, or ODU1.. By default, Service Type is set to SDH and J0 byte in the SDH interface overhead is set to Null.
2. Check the interconnected ports and no alarm is generated. This indicates that the no error is generated in the J0 byte.
3. Confirm that on the client side of the OptiX BWS 1600G, the service type interconnected with the router is OC48, which is different from the service type of the ETMX board. This is why the problem occurs.
4. Change Service Type of the ETMX board to SONET. Then, protocol exchanges are successful and services are normal.

Result

The problem is resolved.

Reference Information

None.

MORE BLOG:

How to do when Abnormal Optical Power Reporting Caused by the Coupling Exception

How to do when the Occasional Failure to Go Online for TN11HSC1 Boards

Incorrect Configuration of the ZL80018 Chip on OptiX OSN 1800

Inconsistency of Fiber Jumper Model and Fiber Connector Type of a Board

The receive optical power of a board is lower than the specified threshold because the fiber connector mismatches the port connector on the board, the connected OAU board at the downstream station reports MUT_LOS and R_LOS alarms.

Product

OptiX BWS 1600G, OSN 6800, OSN 8800

Fault Type

Optical Power Abnormality

Fiber

MUT_LOS

R_LOS

Symptom

At an OptiX BWS 1600G station, a fiber connector on the RPC board is damaged and the fiber jumper must be replaced. After the fiber jumper is replaced, the receive optical power on the WDM side is low (-53 dBm).

The connected OAU board at the downstream station reports MUT_LOS and R_LOS alarms.

Cause Analysis

After a detailed check, it is found that:

1. The transmit optical power of the FIU board at the downstream station is within the permitted range.
2. The receive optical power of the ODF connected to the local station is within the permitted range. That is, the line attenuation is within the permitted range.
3. The receive optical power of the OAU at the local station is low.
4. The receive optical power at the IN port on the FIU board at the local station is low.
5. The fiber jumper between the IN port on the FIU board and the SYS port on the RPC board is normal.

The preceding information shows that the fault is located between the ODF and the FIU board. Possible causes of the problem are as follows:

• The fiber jumper between the ODF and the RPC board is damaged.
• The RPC board is malfunctioning.

Procedure

1. Check the fiber jumper between the ODF and the RPC board. The fiber jumper uses an FC/PC connector at one end and an LHS/UPC connector at the other end, while the LINE port connector on the RPC is LSH/APC. The end faces of the FC/PC and LSH/UPC connectors of the fiber jumper is flat while the end face of the LSH/APC connector is tilted. Therefore, air exists between the LINE port on the RPC board and the fiber jumper connector. As a result, the transmit optical power of the pump laser on the RPC board is abnormal and the receive optical power on the WDM side is low. Change connectors of the fiber jumper on the RPC board so that the fiber jumper uses an FC/PC connector at one end and an LSH/APC connector at the other end. Then, the system operates properly.

Result

The problem is resolved.

Reference Information

None.

MORE BLOG:

How to Use the Ethernet Test Frames on the OptiX OSN 6800?

TD Alarms Falsely Reported by Some Boards Using Pluggable Optical Modules in WDM Products

When the Software Version Compatibility Issue on the TNF2LQM and TNF2LDGF2 Boards in OptiX OSN 1800

The Spectrum Analyzer Cannot Scan a Wavelength of the LWC Board Due to the Drift of This Wavelength

The spectrum analyzer cannot scan a wavelength of the LWC board due to the drift of this wavelength.

Product

OptiX Metro 6100, OSN 6800,Metro 3000

Fault Type

Optical Transponder Unit

Symptom

After one LWC board that operates at 192.9 THz is added to the OptiX Metro 6100 equipment on a network for capacity expansion, the MON port on the WBA board detects neither the 192.9 THz wavelength nor one more wavelength.

Cause Analysis

The possible causes of the problem are as follows:

• The LWC board is faulty.
• The WBA board is faulty.

Procedure

1. Query the optical power at the IN optical port on the WBA board. The query result shows that the optical power at the IN optical interface after the expansion is the same as that before the expansion. This indicates that the added wavelength does not reach the WBA board.
2. Use an optical power meter to test the LWC board. The test result shows that the output frequency of the board is 193.09 Hz. The WDM-side wavelength drift of the LWC board is large. Therefore, the wavelength of the LWC board does not match that of the M40 board interconnected with the LWC board.
3. Replace the faulty LWC board and then test the output frequency at the MON interface on the new LWC board. The test result shows that the output frequency is within the normal range.

Result

After the faulty LWC board, the problem is solved.

Reference Information

Wavelength drift on the OTU board will cause low output optical power on the M40 board. Therefore, ensure that center frequency of each output wavelength on the WDM side of the OTU board is within the range of ±10 GHz from its nominal center frequency.

MORE BLOG:

When customized for North America unable to configure OSN1800.

How to Use the LDMD Board to Configure Intra-Board 1+1 Protection Fails?

When OptiX OSN 1800 Database Recovery Failures

An SCC Board Fails to Start After Multiple Board Replacement Operations

An SCC board fails to start after multiple board replacement operations.

Product

OTN, OSN 6800, OSN 8800

Fault Symptom

A site at office A in country D is configured with one master subrack and three slave subracks. The master subrack is configured with active and standby SCC boards. When the standby SCC board reports the HARD_BAD alarm, users consecutively replace the standby SCC board twice. After that, the standby SCC board malfunctions according to NMS statistics.

Network Topology

None.

Cause Analysis

There are the following possible causes:

• The new standby SCC boards that are being used have defects.
• The slot for housing a standby SCC board malfunctions, resulting a startup failure on the new standby SCC boards.
• The database of the standby SCC board is abnormal, resulting a startup failure on the new standby SCC boards.

Procedure

1. Replace the standby SCC board for two consecutive times.
   The fault persists. This indicates that the fault is not caused by the original standby SCC board.
2. Inspect the slot for housing a standby SCC board.
   No bent pin is found in the slot. This indicates that the fault is not caused by the slot.
3. Inspect the PROG indicator on a new standby SCC board.
   The PROG indicator blinks quickly, indicating that the standby SCC board is being repeatedly reset.
   Result: According to this analysis, the possible cause of that fault is that the database of the standby SCC board is abnormal, which results in start failures and repeated resets of the standby SCC board.
   When the SCC boards that are in the slave subracks start, the data modules in the slave subracks will not start. Therefore, the fault may be caused by the data module on the SCC boards that are in the master subrack.
4. Insert the original standby SCC board from the master subrack into a slave subrack.
   The board starts properly after 5 minutes. You can now determine that the repeated resets of the standby SCC board in the master subrack result from the abnormal data module.
5. Obtain the package loading logs of the SCC boards in the slave subracks using the UpgradeKit tool.
   According to the logs, downgrade operations have been performed on the SCC boards.
6. Clear the database for the SCC board by referring to the Upgrade Guide and insert the original SCC board into the master subrack.
   The board starts properly.

Conclusion and Suggestion

1. NG WDM systems support smooth upgrades but not smooth downgrades. Databases must be cleared before a downgrade. Therefore, determine the version of a spare part before replacing it on an SCC board. If you downgrade a spare part that has a version later than the version of a target SCC board before starting the board, the database of the board will fail to start.
2. Perform the following workaround if an SCC board is incorrectly downgraded and fails to start: Insert the SCC board into a slave subrack of the NE and clear the database by referring to the Upgrade Guide.

MORE BLOG:

What’s the Failure of I-Type PDU Backplane on MA5600T due to Overcurrent

How to do when Occasional MA5616 Database Clearing?

What are the meanings of the short names of UA5000 boards

The services on a network fail to be deployed

The services on a network fail to be deployed because the connectors on the live network mismatch the connectors of new devices.

Product

OSN 6800, OSN 8800

Fault Symptom

According to engineering design files, the insertion loss and distance between sites A and B on an OTN network are 40 dB and 130 km respectively. On the live network, however, the line insertion loss in the east direction and that in the west direction are 45 dB and 46 dB respectively, and the actual line distance is 160 km. Services on the network cannot be deployed.

Network Topology

The following figure shows the network topology.

Cause Analysis

The connectors on the ODF are the FC/APC type, and the connector of the E2000 jumper for connecting the new RPC board is the FC/UPC type. After these two types of connectors are interconnected, the line insertion loss significantly increases, which introduces intensive reflection after lasers on the RPC boards are enabled. As a result, services on the OTN network cannot be deployed.

Procedure

1. Check the configurations of the link insertion loss and dispersion.
   The configurations comply with the design requirements.
2. Check the optical power of the line between the OBU205 board (the board at site A is used for the purpose of this example) to the receive end on the ODF.
   The insertion loss of link A–B is 45 dB and that of the link B–A is 46 dB. The lines are in a normal state.
3. Measure the insertion loss of the link between the RPC board and the OBU101 board.
   The link insertion loss is about 2 dB.
   Measure the insertion loss of the link from the ODF to the RPC board and then to the OBU101 board.
   The link insertion loss is 2 dB (the insertion loss of the RPC board is 1.5 dB). This indicates that the RPC board and the jumper are normal.
4. Measure the ODF and the RPC board using an optical power meter after they are connected.
   No light is measured. This result conflicts with the measured results of the links between the ODF and the RPC board. This indicates that the insertion loss was introduced by the connector of the ODF.
5. Replace the connector on the ODF and jumper.
   The fault persists. The insertion loss of the connector is larger than 5 dB.
   Further analyze the connector on the ODF and the connector of the jumper.
   The connector on the ODF is the FC/APC type, and the E2000 jumper on the RPC board is the FC/UPC type. After these two types of connectors are interconnected, the line insertion loss significantly increases, which introduces intensive reflection after lasers on the RPC board are enabled. As a result, services on the OTN network cannot be deployed.
6. Replace the jumper with a new one whose connectors at the two ends are the FC/UPC and FC/APC types.
   Services on the network are available.
   
   Figure 1 Parameters for different connectors

Conclusion and Suggestion

Familiarize yourself with different types of connectors and be aware that some types of connectors cannot be directly interconnected.

There is a slight difference between the FC/APC and FC/UPC connectors: An FC/UPC connector has a plane surface, and an FC/APC connector has an inclined surface with a slope of 8 degrees.

MORE BLOG:

How to authenticate specific users on a interface

How to delete interface configuration using one command?

How to Replace the Satellite Card of the SRCU Board in the BITSV3

R_LOS Is Reported by a Line Board on a Regular Basis Because of Incorrect Wavelength Monitoring Configuration on the Electrical Regeneration NE (NG WDM Equipment)

R_LOS is reported by a line board on a regular basis because of incorrect wavelength monitoring configuration on the electrical regeneration NE.

Product

OSN 6800, OSN 8800

Fault Symptom

On network L of operator Y in country Z, the TN52ND2 board in slot 4 on NE A reported an R_LOS alarm for its optical port 1 at a specific time in every early morning (00:00–06:00). In addition, on the peer NE (NE B), the TN52ND2 board in slot 6 reported a WAVELEN_OVER alarm for its optical port 1. After a field inspection of the NE configurations, Huawei frontline engineer determined that the wavelength monitoring configuration on NE B was incorrect. After the configuration was corrected, the TN52ND2 board on NE B stopped reporting the WAVELEN_OVER alarm, but the R_LOS alarm on NE A was still reported on a regular basis.

Network Topology

Cause Analysis

As the TN52NQ2 board reported an R_LOS alarm at a specific time in every early morning (00:00–06:00), one can determine that a wavelength drift had occurred on the TN52NQ2 board of the peer NE.

If the wavelength monitoring configuration of the TN52NQ2 board on the peer NE is correct, then there are the following possible causes:

• A multi-NE wavelength locking function has been configured for the TN52NQ2 board on the peer NE and the configuration is incorrect.
• The logical and physical fiber connections between the two NEs are inconsistent.
• An electrical regeneration NE is located between NEs A and B, as shown in the following figure, and the wavelength monitoring configuration on this NE is incorrect.

Procedure

1. Checked the NE monitoring configuration of other NEs on the network. The multi-wavelength locking function was not configured for these NEs.
2. Sent test TTI bytes from optical port 1 on the TN52ND2 board in slot 6 of NE B to optical port 1 on the TN52ND2 board in slot 4 of NE A.
   1. When test TTI bytes were sent in the SM section, optical port 1 on the TN52ND2 board in slot 4 of NE A had not received any TTI bytes.
   2. When test TTI bytes were sent in the PM section, optical port 1 on the TN52ND2 board in slot 4 of NE A received the TTI bytes.
   Based on the preceding information, Huawei determined that an electrical regeneration NE was located between NEs A and B.
   The following describes how to set and check test TTI bytes:
   1. 1. Start the NE Explorer of the transmitting NE, select the board that you use to transmit TTI bytes, and choose OTN Overhead Management > SM Overhead or OTN Overhead Management > PM Overhead.
      
   2. Enter a required value in TTI to be Sent on the right of the window.
      
   3. Start the NE Explorer of the receiving NE, select the board for receiving the TTI bytes, and choose OTN Overhead Management > SM Overhead or OTN Overhead Management > PM Overhead.
   4. Check the value of TTI Received to see whether it is the same as the value of TTI to be Sent.
      
3. Confirmed that the TTI bytes from optical port 1 on the TN52ND2 board in slot 6 of NE B to optical port 1 on the TN52ND2 board in slot 4 on NE A traversed an electrical regeneration NE. Checked that the wavelength monitoring configuration on this NE was incorrect.
4. Correctly the wavelength monitoring configuration for the regeneration NE. Then the TN52ND2 board on NE A stopped reporting the R_LOS alarm.

Conclusion and Suggestion

When a line board on an NE reports an R_LOS alarm at a regular basis, if the wavelength monitoring configuration on the peer NE is correct, check whether:

• The logical and physical fiber connections between the two NEs are consistent.
• An electrical regeneration NE is located between the two NEs.

The following provides the check methods:

1. To check whether the logical and physical fiber connections are consistent, send TTI bytes in the PM section between the two NEs.
2. To check whether an electrical regeneration NE is located between the two NEs, send TTI bytes in the SM section between the two NEs

When the data communication is unavailable or interrupted intermittently, or when packet loss occurs, check the working mode of the interconnected ports. In most cases, the problem is due to the mismatch of the port working modes at the two ends.

MORE BLOG:

How to Install SLQ4 board on slot 1 to slot 4 in OSN 3500?

What’s the Ethernet features in terms of function of the OptiX OSN 1500 V1R2?

When downgrade failed on S5700-28X-PWR-LI-AC running V200R002C00SPC100

Internal Communication of an NE Is Abnormal And Many Boards Report Transiently BD_STATUS or COMMUN_FAIL Alarms Due to Conflicted Subrack IDs

The internal communication of an NE is abnormal and many boards report transiently BD_STATUS or COMMUN_FAIL alarms due to the conflicted subrack IDs.

Product

OptiX OSN 6800

OptiX OSN 8800

Fault Type

NE Offline

BD_STATUS

COMMUN_FAIL

Symptom

On network C built with the OptiX OSN 6800, many boards on an NE report a transient BD_STATUS or COMMUN_FAIL alarm. A query of the NE configuration shows that the logical board for slot 10 is sometimes displayed as TMX and sometimes displayed as XCS. Actually, the board housed in slot 10 is the TMX board.

Cause Analysis

Communication between the boards on an NE is abnormal when many boards on the NE report a transient BD_STATUS or COMMUN_FAIL alarm. The possible causes of the fault are as follows:

• The boards that report the alarms are faulty.
• The AUX board, which is the communication hub of the NE, is faulty.
• An external factor results in abnormal communication.

Procedure

1. Considering that many boards of the NE report a transient BD_STATUS or COMMUN_FAIL alarm, suspect that internal communication of the NE may be abnormal.
2. Rule out the possibility that the boards reporting the BD_STATUS or COMMUN_FAIL alarm are faulty since many boards of the NE report the same alarm.
3. The logical board in slot 10 changes frequently. Thus, suspect that conflicting subrack IDs exist.
4. Check the NE configurations at the site and find that two subracks of the NE use the same ID. Thus, determine that this problem is due to conflicting subrack IDs.

Result

The problem is resolved.

Reference Information

Conclusions and suggestions for this case are as follows:

After changing the settings of the DIP switches of a subrack in the engineering or maintenance phase, perform a power-off reset on the subrack so that the settings of the DIP switches take effect.

MORE BLOG:

Access Capacity of Slots of the OptiX OSN 1500 V1R2

How to Assemble an IMPI on the MA5620G?

Why can not login S5700 after S5700 power on when the software version was upgraded to V200R005C00SPC500?