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

Bad clock quality incoming from customer side caused slips on TDM services passing through RTN910 V100R001C02

Publication Date:  2012-07-25 Views:  170 Downloads:  0
Issue Description
In an OptiX RTN 910 V100R001C02 link customer report continuous negative slips on TDM services affecting the quantity of packages passing through it. RTN 910 nearest to the BSC had the first four E1s configured to take clock signal and the RTN 910 nearest to the BTS had configured the IFs to track clock signal.


Alarm Information
NULL

Handling Process
After followed with customer the E1 route connected to the E1-1 port of the RTN we found that it was opened some hops after. However the E1 – 1 port was receiving signal and for that reason RTN took clock signal from it.
To solve problem we change the priorities from the RTN and the second E1 port was set as the first priority. After this change slips on services stopped and after running again the commands the output showed that the clock quality was within the accepted values for RTN -2PPM to 2PPM.
 
Command PPM
Optp cmd : 0e87                                                                    
20db -0.207192
   
:optp: 2,0,90,1,0e,87,10,20  
Optp cmd : 0e87                                                                    
20c5 -0.2328
   
:optp: 2,0,90,1,0e,87,10,20  
Optp cmd : 0e87                                                                     
20d5 -0.214176
   
:optp: 2,0,90,1,0e,87,10,20  
Optp cmd : 0e87                                                                     
20d2 -0.217668
   
:optp: 2,0,90,1,0e,87,10,20  
Optp cmd : 0e87                                                                     
20dd -0.204864
   
:optp: 2,0,90,1,0e,87,10,20  
Optp cmd : 0e87                                                                     
20d5 -0.214176
   
:optp: 2,0,90,1,0e,87,10,20  
Optp cmd : 0e87                                                                    
20cf -0.22116
   
:optp: 2,0,90,1,0e,87,10,20  
Optp cmd : 0e87                                                                     
20c9 -0.228144
   
:optp: 2,0,90,1,0e,87,10,20  
Optp cmd : 0e87                                                                    
20d9 -0.20952
   
:optp: 2,0,90,1,0e,87,10,20  
Optp cmd : 0e87                                                                     
20ae -0.259572

Root Cause
After customer complains the following verifications and test were done:
  1. Verify RTNs synchronization configuration. RTN nearest to the BSC should have priority for E1s and remote RTN should have priority from Ifs. RTNs were well configured
  2. Verify that both RTNs are tracking clock signal from the configured priorities. Both were working normally. RTN nearest to the BSC was taking clock signal from the E1 -1 and RTN nearest from BTS from the 3IF (main IF).
  3. Running a BERT connecting the analyzer in a free E1 port and configuring clock as received. BER test alarmed after some minutes due to sync problems.
  4. Change the RTN nearest to the BSC clock priority to the E1 connected to the analyzer and set clock from analyzer to internal. BER test run normally and no errors were reported.
  5. With the priorities configured as test 2 the following navigator command given by R&D was run in the RTN nearest to the BSC:
:optp:2,0,90,1,0e,c5,1,1   (run once)
:optp:2,0,90,1,0e,87,10,20   (At least 10 times)
Outputs from command are then analyzed with the following formula:
Reference
Middle Frequency 8589
ppm/1 (Hz?) 0.001164
Count (DA Value(DEC)-Middle Frequency) * 0.001164
 
 
Usually, our RTN can only take a ±2 ppm comparing with middle frequency. If values are not in this range it mean that clock quality received by the RTN is not good.
In this case after running commands and replacing them in the formula results showed that clock quality was quite bad:

Command PPM
Optp cmd : 0e87                                                                    
002f -9.942888
   
:optp: 2,0,90,1,0e,87,10,20  
Optp cmd : 0e87                                                                    
003b -9.928992
   
:optp: 2,0,90,1,0e,87,10,20  
Optp cmd : 0e87                                                                     
002a -9.948708
   
   
:optp: 2,0,90,1,0e,87,10,20  
Optp cmd : 0e87                                                                    
0035 -9.935904
   
:optp: 2,0,90,1,0e,87,10,20  
Optp cmd : 0e87                                                                     
0037 -9.933576
   
:optp: 2,0,90,1,0e,87,10,20  
Optp cmd : 0e87                                                                    
0043 -9.919608
   
:optp: 2,0,90,1,0e,87,10,20  
Optp cmd : 0e87                                                                     
0039 -9.931248
   
:optp: 2,0,90,1,0e,87,10,20  
Optp cmd : 0e87                                                                     
0020c -9.94638

Suggestions
Verify always from which side comes the synchronization and confirm that RTN takes normally the clock configured in the priority list.


END