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>Search


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

Knowledge Base

Clock configuration RTN 910 V1R1 connecting PTN 3900

Publication Date:  2012-07-25  |   Views:  563  |   Downloads:  0  |   Author:  Jesus Gabriel Ly Ponce  |   Document ID:  EKB0000505938


Issue Description

In country C, a backhaul network is deployed to support 3G UMTS services over it, integrating OptiX PTN 3900 and microwave equipment RTN 910. The PTN 3900 running software version V100R002C00SPC300 ( using ETFC 
board (TN81ETFC) is connected through this board to RTN 910 running software version V100R001C02SPC200 ( ETFC board on PTN 3900 does not support Ethernet synchronization neither SSM protocol. In the other hand 
RTN 910 with this software version does not support SSM protocol on IFE2 boards. We need to synchronize RTN microwave chain to PTN 3900 and assure the clock quality on the network.
--------------                 -------------
|PTN3900| -----------|RTN 910|
--------------                 -------------

Alarm Information

Some FERF and AIS events are reported on end equipment which is a Tellabs ADM.

Handling Process

On the above scenario, the clock configuration and testing is as follows:
1) Connect external clock cable between PTN 3900 input/output clock port located on XCS board and CLK1/TOD1 located on RTN 910 CXPB board.
The cable is a common UTP cable with RJ-45 connectors, and corresponding pin-out is as follows:
Tx end:             Rx end:
pin 4-------------pin 1
pin 5-------------pin 2
2) Enable SSM protocol on the RTN 910 where the external clock cable is connected.
3) Disable SSM protocol on the rest RTNs involved on the microwave chain (Notice if the SSM protocol is enabled on the remote RTN, this equipment will run in hold-over state since the IFE2 board does not send S1 byte containing clock quality information, which does not imply the RTN is not working with G.811, for this reason the RTN turn into hold-over state therefore it uses the internal clock source when should not use).
4) Make sure the equipment is working in the normal state checking the Clock Synchronization Status, which should be 'Normal mode' and the clock source should be the corresponding interface according to the topology.
5) To make sure the RTNs are correctly synchronized and using the corresponding clock quality, create a test CES service and run a BER test with analyzer during 24 hours or more (the analyzer should be connected to BITS or external 
clock source on PTN 3900 or OSN 3500). The test should be OK (no AIS) if all the equipments through which the signal is passing are using the same clock signal quality and reference, namely the BITS.

Root Cause

When CES services are created over this scenario some AIS events are reported on end equipments, which does not affect the services but may impact on customers KPIs.


- If CES services need to be deployed assure the clock quality on all the RTNs involved.
- The RTN is able to be connected to another RTN in cascade (from TOD1 to TOD2), with the limitation of 20 cascade connections as a maximum because of the clock signal degradation