No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

TU_AIS reported when creating SDH service by trail due to the fiber misconnection

Publication Date:  2012-07-25 Views:  81 Downloads:  0
Issue Description
NMS version: U2000 V1R5C00SPC603
OSN7500 Ver: V1R8C02SPC500
Metro1000v3 Ver: 5.37.05.12P03

For network topology and rack layout please check below diagrams,



Figure:1 Network Topology


Figure2: Rack layout


Customer wants to create Ethernet ( 1VC3 bounded) and none protected service between
117-Queen Nour (Metro1000) - S1-EGS and 705-3G BeitRas- S2-EGS4
Service creation procedure as below:
1- create NP_Chain (None protected chain) on new VC4 (VC4#5)
2-create SDH service using trail (VC4 Server trail using VC4#5) then create VC3 service (117-S1-VC4:1,VC3:1) to (705-S2-VC4:1,VC3:1).
3-bound path the above VC3 to the EGS VCTRUNK:1 & EGS4 VCTRUNK1.
4- create EPLAN service and add port1 & VCTRUNK1 at both Metro-EGS & OSN-EGS4.

once they finish the service configuration the Ethernet service never work, always down.
and the SDH service trail (VC3) has alarm (TU_AIS) alarm.

Alarm Information
Ethernet Service down.
TU_AIS_VC3 reported at both OSN7500 & Metro1000

Handling Process
  • Check the optical power and SDH path alarms if some higher-level alarms, such as the R_LOS, R_LOF, HP_SLM or AU_AIS, occur in the system, but we did not find any alarm.
  • Check if a hardware fault alarm, such as the PLL_FAIL or CHIP_FAIL, occurs but also it was normal and we dont have any fault.
  • Check the cross-connect and timing board (SCB/Metro & IXCSA/OSN7500) it was ok and other services working normally.
  • We checked the cross connect on the NE at both station it was ok and service is active.
  • we suspect that the fiber connection created on U2000 is different than actual physical fiber connection on site, so we send a J0 messege at 5-SLQ16-P1 which must be received at 117-S1-P2 but actually we received the messege at P2, to double confirm customer ask us to switch OFF the laser of 5-SLQ1-P1 at OSN7500 and we receive the R_LOS alarm also at 117-S1-P2 not P1.
  • So we delete the VC3 service.
  • Then delete the fiber from NMS and re-create the fiber as per actual connection (this will delete the protection subnet & trails from NMS) and search for SDH trails again.
  • Try to create the VC3 ethernet service , the problem solved.
     
NOTE: the customer did not notice the problem before because all the old services where SNCP protected (i.e. the services are transmitted at both end "dual fed") so there was not TU_AIS alarm before.

Root Cause

The possible causes of the TU_AIS_VC3 alarm are as follows:

  • Some higher-level alarms, such as the R_LOS, R_LOF, HP_SLM or AU_AIS, occur in the system.
  • A hardware fault alarm, such as the PLL_FAIL or CHIP_FAIL, occurs at the upstream station.
  • The cross-connect and timing board is faulty.
  • The relevant path at the opposite station is faulty.

Suggestions
1. The actual fiber connection on site must match the actual data on NMS, so its better to use Fiber search rather than creating fiber manually.
2.the SDH trails & protection follow the NMS data so if any mismatch or wrong data on NMS will be reflected on the service creation and service route.
3.High engineering quality and good installation & labeling may save alot of efforts and smooth the maintinance job.

END