Analysis and Handling process of Two Optical Fiber Links

Source: Internet
Author: User

A friend of the author works in China Telecom and is mainly responsible for the fiber optic business of China tietong. At a recent meeting, he told me about several failures encountered during Optical Fiber maintenance. The author selects two of the most representative introductions for readers, I hope you will learn from the article and reflect on the whole process of solving the problem.

Fault 1: multiplexing segment codes caused by SDH and their handling

Symptom description:

The provincial-level trunk optical transmission network, from Chengdu to ya'an, is a 2G Single-Chain optical fiber. The composition of the transmission network is from Chengdu to Pujiang and then to ya'an, a total span of more than 200 kilometers. On the chain are ZTE ZXSM-10G equipment, the main control version V3.14.012.040220; Pujiang for ZTE ZXSM-150/600/2500 ADM & Reg equipment, as REG signal regeneration and amplification, the main control version is v1.0020.21; ya'an is a ZTE ZXSM-150/600/2500 device, the main control version is v1.0020.21. One day, it was found on the Chengdu network element, and more than 7-slot OL16 VC4 channels reported Remote Defect indication alarms.

Alarm information:

After checking on the network management, the 7-slot OL16 of Chengdu network element has 3 VC4 instances reporting remote code indication alerts. These VC4 correspond to the businesses from Chengdu to ya'an. At the same time, the OI16 optical board of ya'an Network Element reports the Remote Defect indication alarm of the multiplexing segment. Check performance events. ya'an Network Element OI16 reports a large number of remote background Block Error events for reuse segments, and Chengdu Network Element reports a large number of background Block Codes for higher-level channels corresponding to VC4 channels. The received optical power of the OI16 board of ya'an network element is-32dbm, and historical performance events show that the received optical power of the OI16 board has changed significantly recently, ranging from-32-18.7dbm. However, the Chengdu network element corresponds to the OL16 light board with a light receiving light of-18.5dbm, and the value does not change significantly in historical performance.

Cause analysis:

The Remote Defect indication of the reuse segment reported by ya'an network element indicates that there are too many optical path multiplexing segments in Chengdu, so Chengdu sent the alarm back to ya'an. At the same time, the higher-order VC4 channel discovery error code after the Chengdu site is dereused, so relevant performance events are reported. It can be judged that the alarm is caused by the optical path code between Chengdu and ya'an. Possible causes include:

(1) poor quality of optical fiber lines between Chengdu and ya'an;
(2) faults of pigtails, optical fiber connectors, or Optical attenuation connectors;
(3) A source optical board fault occurred between Chengdu and ya'an.

Processing Process:

Combined with the optical power values of each segment found on the network management, the fault segment is determined in the Pujiang-ya'an room. Because the receiving sensitivity of the OI16 optical board of ya'an network is about-32dbm, and its current light receiving is-32dbm, the optical power is obviously a little low. In addition, in terms of historical performance, the optical power of the OI16 optical board of ya'an has greatly changed. It is determined that the optical power of ya'an is abnormal, leading to optical path error codes. The optical power values of other segments do not fluctuate greatly and are within the normal range. However, we still cannot confirm the Fault Cause of the Pujiang-ya'an section, whether the fiber core is poor or the device board is faulty or other causes. As a result, the standby board, Optical attenuation device, and other devices were urgently transported to ya'an city and Pujiang relay station. Then, when combined with local maintenance personnel for inspection, they were measured at the ODF frame of ya'an station, the attenuation value of optical power is-19.4dbm, and the light sent from Pujiang to ya'an is-1dbm on the network management. Pujiang-ya'an is about 80 km. The optical cable series are newly created. The average attenuation per kilometer is calculated as dBm. When Pujiang sends the light to ya'an station, the following occurs:-1-80 x0.2 =-17dbm, it is basically consistent with the value measured at the ODF frame of ya'an station. It indicates that the core has no quality problems. According to the detection, the optical power of ya'an is too low, which may be caused by poor pigtails in the ya'an data center. The alarm is cleared after the fiber receiving from the ODF frame to the light board is replaced. Alarms for Chengdu network element are also cleared. However, after 20 minutes of observation on the network management system, we found that, In the OI16 optical board performance event of the ya'an station, we reported the background Block Codes of the reused segments again, and the error codes increased cumulatively. This light board is likely to have problems. After the same type of OL16 optical board is replaced at the ya'an station, no error code is found on the network management for a long time and the optical power receiving is-19dbm. According to these situations, pigtails are also eliminated.

Summary:

This fault occurs because the optical power is too low, resulting in an error code exceeding the limit. The specific fault point is compound: Pigtails are of poor quality and optical board faults. When dealing with similar problems, keep your mind calm and analyze them carefully to identify possible causes of faults.

Fault 2: SDH cross-Network Audio Service Fault Handling Method

Symptom description:

There are two audio services between two ONU points of the iron Tong private network. These two ONU points are not under the same network management and are connected through two semi-permanent connections. I tested the two channels with the level meter recently. When I found that the other side sent 0 dB, we received + 8 dB. When we sent 0 dB, the other side received + 8 dB, which was significantly too high.

Cause analysis:

1. Because only two audio ports on the AUDB Board are not good, it is suspected that the audio board is a problem. After both ends change the audio board, the phenomenon remains the same, and hardware reasons are excluded;

2. Check this board. First, check that these two audio interfaces belong to subnode 19 on the digital console of this Board. The audio interface numbers are 1-11-1 and 1-1-11-2, for the 4-line audio, use the 1393 command to view the sending and receiving gains of the two ports are + 4 and-14dB, respectively, and then remotely log on to the network administrator of the ONU on the peer end, it is found that the audio port numbers corresponding to the peer network management are 1-1-6-0 and 1-1-6-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1-1, it is determined that the data at both ends is incorrect.

Processing Process:

The gain of this board is reduced separately. After testing, the effect is not obvious. Then, the receiving and sending gains of the audio ports at both ends are changed to + 4 and-14dB. After testing, the level is within the normal range, yes.

Suggestions and summary:

The gains of the audio interfaces at both ends of the audio leased line should be set to the same; otherwise, crosstalk may occur in the article.

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.