时钟不同步引起的指针调整处理方法

h68810115

经过多年的网络维护，从网络故障、性能劣化等问题的处理中，本人总结出处理网上问题的一些经验。总的来说，网络故障中的告警分析应该是比较直观的，相信所有熟悉网络维护的同行都会有自己的体会，在这里我想说说时钟不同步引起的指针调整故障的定位方法。

    分析指针调整，首先要清楚SDH网的时钟跟踪方向，同时还要清楚产生指针调整的通道业务走向，再排除时钟跟踪的配置错误（例如，形成时钟互跟）和其它可能的问题，最后定位网同步的故障所在。

    一、AU指针调整出现的情形

    AU指针调整在线路（SL1、SL2、SL4、ASP）侧完成，产生原因有两种：

    1、上一网元产生指针调整，本端直接检测到AU指针调整；

    2、业务上游网元产生指针调整，经过VC4业务穿通，将指针调整信息带到本站，如图1所示。



图1  形成AU指针调整的原因分析

    在图1所示的业务走向中，若NET1、NET2不同步，而NET2、NET3和NET4保持同步，则将在NET3、NET4的线路侧上报检测到AU指针调整的信息，此时NET3检测到的AU指针调整是由NET2产生的，而NET4检测到的AU指针调整是由NET2产生后经过NET3穿通过来的。当然，NET3的FIFO可以吸收一部分由NET2产生的AU指针调整，从而也有可能NET4的线路侧检测不到AU指针调整。

    在一般情况下，若时钟链的传递方向是从NET1至NET4，即NET4跟踪NET3，NET3跟踪NET2，NET2跟踪NET1，则基本可以判断为NET1或者NET2时钟存在问题。

    二、TU指针调整出现的情形

    TU指针调整的上报有下列三种情况：

    1、上游站点报AU指针调整，本站转化为TU指针调整。

    以图1为例，NET1、NET2存在不同步，而NET2、NET3和NET4保持同步，NET4将上报TU指针调整，产生原因是在解复用过程中，AU指针调整转化为TU指针调整所致。

    2、本站和相邻上游站，由于系统时钟与接收信号时钟不一致，解复用过程中产生TU指针调整。



图2  系统时钟与接收时钟不一致产生的TU指针调整

    在图2中，NET1、NET2不同步，但NET1是业务的复用端发送者，并没有产生指针调整，因此NET2不会检测到AU指针调整，但在NET2的解复用过程中，由于系统时钟和接收的信号时钟不一致，将会产生TU指针调整。

    3、业务的上游网元产生指针调整，穿通到本站后在解复用过程中产生TU指针调整。



【注】括号中的数字表示相应的业务通道

图3  业务上游网元产生的指针调整穿通到本站解复用后产生TU指针调整

    在图3中，63个2M业务从NET1上传到传输设备，其中一部分，通道1-32的业务下传到NET2，而另外一部分，通道33-63的业务则以VC12的方式从NET2穿通到NET3，再下到支路。若NET1、NET2不同步，按照前面分析可知，NET2会产生TU指针调整，而另一部分通道业务（通道33-63），则带着TU指针调整的信息穿通到NET3，此时，NET3将会上报TU指针调整，不会检测到AU指针调整，不管NET2、NET3之间是否存在同步关系。



图4  业务配置为VC12的全穿通方式

    需要注意的是，当业务配置为VC12全穿通时，如图4所示，若NET1、NET2不同步，则由于业务不在NET2上，因而NET2既不会上报AU指针调整，也不会上报TU指针调整，只有当业务到达终点站NET3时才会上报TU指针调整。问题是，单从NET3上报TU指针调整无法确定是NET2还是NET3的时钟不同步，解决办法一是分析其它通道业务，二是配置一个VC12业务下到NET2的支路再进行分析。

    总体来说，时钟不同步是产生指针调整的根源，抓住“上游产生，本端检测”的原则，分析指针调整的问题与分析告警信息一样，先高级后低级，也就是先AU指针后TU指针，综合业务流向和时钟跟踪方向，找到不同步的环节。