Common issues about the OD system

1

Question:
For the first version of OD on NG WDM V100R007C00 (matching U2000 V100R006C02):
1. What are the differences in OPM/MCA performance reporting?
2. Why must the fiber connections be correct before the OD works?
3. How long does it take before the OSNR can be queried after the OD feature is configured for the first time or the NE is reset?
4. The OD function is forcibly enabled for a network that does not support the OD function, causing the MCA/OPM8 function to be abnormal and the original function unavailable. How to solve this problem?
5. Where can the length and type of optical fibers be configured? From the interface for creating logical fiber connections on the U2000 or other navigation paths?
Analysis:
Answer:
1. When the OSNR detection fails, the OSNR in the OPM is an invalid value. The MCA OSNR performance value is compatible with the existing MCA board and is reported as ?600.
2. When the OD feature is started for the first time, or the network changes (such as dimension adjustment or dimension expansion), the OD connection relationship needs to be synchronized to the equipment through the NMS interface (OTU-MUX/DMUX does not need to be changed.)
3. 10 minutes.
4. You can run a Navigator command to resolve the problem. :emca-check-section-id:0, 0&0
5. The navigation path is on the Board Port-Advanced Attributes tab page. Notes: 1. The line-side fiber type and length configured on the FIU, DAS1, or RAU board at the receive end must be consistent with those of actual fibers. 2. If there is no RAU board at the receive end, configure the fiber type and length information on the FIU or DAS1 board. If there is RAU board at the receive end, configure the information on this RAU board.

Other related questions:
Method to implement the OD system
The OD is a function implemented through the collaboration of products and the NMS. OD principles are provided in the product documentation. To support the OD, the NE version must be later than V100R007C00 and the NMS version must be later than V100R006C02.

NE versions required by the OD system
To support the OD, the OptiX OSN 6800/8800 version must be later than V100R007C00 and the NMS version must be later than V100R006C02.

Common causes for abnormal OSNR scanning results of the MCA board after the OD function is enabled
1. The fiber type and length of the FIU board are not set. 2. The optical performance monitoring function is not enabled for the MCA board. 3. The OMS trail is incomplete. When the OD function is enabled, ensure that the OMS trail is complete. If a logical fiber connection is deleted from the OMS trail after the OD function is enabled, the OD function will become abnormal. As a result, no OSNR is displayed for the MCA board. In this scenario, the logical fiber connection must be added again, the OMS trail must be searched out, and the OD function must be enabled. 4. The logical fiber connection of the MON port on the MCA board is falsely deleted. 5. The NE where the MCA board resides and the OTM site are not in the same ECC subnet. 6. The MCA board is in an early version. TN11MCA401 and TN11MCA801 do not support the OD function, and TN11MCA402 and TN11MCA802 also have requirements on the module firmware. If the firmware versions for the TN11MCA402 and TN11MCA802 boards are earlier than the earliest version supported, the firmware on these boards cannot be upgraded. You need to replace the TN11MCA402 and TN11MCA802 boards before using the OD function. You can run the :cfg-get-modverinfo:Bid command to query the module version.

Issues about the replacement of 51SCC and 11SCC boards by 52SCC boards
The 52SCC board can substitute for the 51SCC board in the versions later than 5.51.5.35, but they cannot mutually back up each other for a long period of time.

Common questions about extended ECC on WDM NEs
Question: How many NEs can be interconnected using automatically extended ECC at a site? Analysis: At many sites, all NEs are interconnected using automatically extended ECC. As a result, there is a large number of NEs using this function for interconnection, and NEs are frequently unreachable by the NMS. Answer: 1. If an Ethernet is used to establish an extended ECC channel for communication, at most four extended ECC channels are required. With manually extended ECC, a server can be connected to at most 7 clients, and each client can be further connected as a server. Hubs (or switches) can be cascaded, which is related to the network scale limit only. The basic principle applies to each product and is related to the platform. 2. The method of cascading metro WDM devices using ETHERNET1 and ETHERNET2 ports does not apply to a long-haul WDM system. For long-haul WDM devices, the ETHERNET2 port is not used for ECC communication. In addition, you are advised to cascade at most eight network ports in a metro WDM system.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top