Have you ever meet the problem Single End SNCP switching failed?

Problem was reported by customer  that service interruption observed after fiber cut between NE-1565 & NE-1567. All the interrupted services were configured as SNCP and having the protection paths. SNCP services are configured on NE-1567 and NE-6. See diagrams attached. OSN 7500 and OSN 3500 equipments software Version is V1R8 are involved.



UP_E1_AIS alarms were observed on interrupted services. 

After above step, SNCP switching status was checked on both NE-1567 & NE-6. SNCP services switching was triggered on NE-1567 due to R_LOS alarm upon fiber cut, however SNCP services switching was not triggered at NE-6. 

According to the service connectivity information provided by the customer, SNCP services for the interrupted sites are configured on NE-1567 & NE-6 as shown in attached diagram1.  After problem escalation, end to end configuration for the interrupted services was checked and found that SNCP services were configured as VC4 level at NE-6 whereas services configured at NE-1567 were VC12 level as shown in diagram2 attached. 



Due to lower order services configuration at NE-1567, SNCP switching trigger conditions didn’t meet for the higher order services configured at NE-6, therefore services were interrupted. 

N/AIn order to restore interrupted services, “Force Switching to Protection” was performed at NE-6 for the particular services. After this step, sites were restored successfully  

From above detailed analysis, it is concluded that the services were interrupted due to wrong SNCP configuration. Higher order (VC4 level) services were configured at NE-6 whereas lower order (VC12 level) services were configured at NE-1567. Upon fiber cut between NE-1567 & NE-1565, SNCP services switching triggered at NE-1567 due to R_LOS alarm upon fiber cut, however no higher order alarm was reported at NE-6 not meeting the SNCP switching trigger condition resulting no SNCP services switching trigger at NE-6. Therefore service interruption was observed for the services having wrong configuration.  When fiber cut restored we restore SNCP force protection. Later implemented proper SNCP configuration at same level that is vc12 level at both end nodes and issue resolved. 

Whenever it is required to configure SNCP services, it is recommended to use same service level either lower order or higher order on both add/drop points. Moreover in above scenario, services switch to the protection path upon “Force Switch to Protection” command, however SNCP services switching will not be triggered upon fiber cut if trigger conditions don’t meet.   

 When changed the SNCP services configuration on the same level on both add/drop points SNCP switching tested and found normal. 

Thunder-link.com now have Huawei OSN series, MERO series, PTN/TRN series equipment, GPON products, datacom products and various board on promotion, more than 86% off list price, please come to visit www.thunder-link.com; or just email for inquire: sales@thunder-link.com

Categories:

Comments are closed