数据链路层故障处理方法 【技术领域】
本发明涉及通信技术领域，尤其涉及一种数据链路层故障处理方法。
背景技术
在窄带通信技术领域，网络设备之间常常采用QSIG(Q信令)进行对接。在对接过程中，由于传输线路故障、协议类型更改等原因，可能导致提供信令承载机制的数据链路层发生故障。所发生的故障可能瞬间解除，也可能持续较长时间。对于可以瞬间解除的故障，为了防止数据链路层故障导致呼叫被立即清除，而影响用户正常的通信，现有技术普遍采用QSIG协议簇中的ECMA-143(ECMA，欧洲计算机制造商协会)协议在链路层事件处理流程中规定的断链保护方法，即采用名称为T309的定时器对呼叫进行延时保护：当数据链路层发生故障时，对正在通话的呼叫不会立即进行清除，而是保持在当前状态；如果在T309定时器超时之前数据链路层恢复正常，则继续现有的通话过程，而不需要重新建立呼叫；如果在T309定时器超时后数据链路层仍然没有恢复正常，则中止通话过程，清除呼叫，释放通道。具体过程如下：
当QSIG处理模块收到链路层故障的消息后，查询PRI(Primary RateInterface，基群速率接口)上所有呼叫的状态，清除不在“运行”状态下的呼叫。而对于处于“运行”状态下的呼叫，则启动T309定时器进行延时保护(时长为90秒)，同时向数据链路层发送建链请求，要求重新建立数据链路层的连接。
在T309定时器超时之前，如果QSIG处理模块收到了数据链路层恢复连接的消息，就遍历接口上所有的呼叫，停止所有的T309定时器，同时保持本地呼叫地当前状态，并向对端网络设备发送“STATUS ENQUIRY(状态查询)”消息，启动针对对端呼叫状态的状态查询程序，确定本地与对端的呼叫状态是否兼容。如果双方的呼叫状态能够兼容，则保持当前呼叫；否则，启动呼叫清除程序，清除当前呼叫。
如果T309定时器超时，数据链路层仍没有恢复连接，则清除接口上所有的呼叫。
以上过程是ECMA-143协议规定的对链路层事件的处理流程。其中，对“数据链路层连接恢复消息”的处理，请参见图1。
可以看出，断链保护程序可以有效提高呼叫连接的可靠性和抗干扰能力，避免数据链路层的临时故障对通话造成影响。但是，如果对数据链路层故障的原因不加以区别，在任何情况下都启动断链保护程序的话，就可能妨碍一些用户操作的实现。
实际应用中，在路由器设备上运行ECMA-143协议时，除了由于客观因素引起的链路层故障外，用户的主观操作也可能引起链路层故障。比如，用户可以通过执行SHUT DOWN命令中断接口上的数据传输，释放通信资源；然后，再执行NO SHUTDWON命令，实现对接口的重新初始化。在这个过程中，执行SHUTDOWN操作时就会使链路层因为传输中断而出现故障。此时，如果根据ECMA-143协议的规定启动断链保护程序，那么在T309定时器超时之前，正在通话的呼叫所占用的通信资源就会处于被保护的状态，而不会象用户期望的那样被释放掉，从而无法中断接口上的数据传输；同样，如果在T309定时器超时之前执行NO SHUTDOWN操作，链路层就会因为重新建立连接而解除故障，T309定时器就会被停止，处于被保护状态的通信资源也会被继续占用下去，导致接口没有被重新初始化。
【发明内容】
本发明的目的是提供一种数据链路层故障处理方法，当用户主观操作引起链路层故障时，释放通信资源，以实现用户的操作目的。
本发明的目的是这样实现的：
所述的一种数据链路层故障处理方法，包括：
当数据链路层发生故障，判断所述故障是否由用户执行清除呼叫操作引起的，如是则立即作清除呼叫的处理，否则进行延时保护处理。
所述判断故障是否由用户执行清除呼叫操作引起的进一步指：
在网络设备中设置用于记录用户是否执行了清除呼叫操作的标志位；
当用户执行清除呼叫操作时，利用所述的标志位进行记录；
收到数据链路层故障的消息时，根据该标志位确定是由用户执行了清除呼叫操作所引起的数据链路层故障。
在路由器中，所述的用户执行了清除呼叫操作包括：用户执行中止接口上数据传输的命令、用户执行恢复数据传输的命令或用户执行对接口上数据进行初始化的命令。
所述延时保护处理为：
根据ECMA-143协议启动T309定时器，即断链保护定时器对接口上的呼叫进行延时保护处理。
所述的启动T309定时器对接口中的呼叫进行延时保护处理进一步包括：
当数据链路层发生故障时，将正在通话的呼叫保持在当前状态，并启动T309定时器，并作如下处理：
T309定时器超时之前数据链路层恢复正常，则继续所保持的呼叫的通话过程；
T309定时器超时后数据链路层仍然没有恢复正常，则中止所保持的呼叫的通话过程，清除呼叫，释放通道。
所述的数据链路层故障处理方法还包括当数据链路层发生故障后，数据链路层又恢复连接时的处理过程：
当收到数据链路层恢复连接的消息时，如果本地接口不存在呼叫，则向该连接的对端发送“RESTART(重新启动)”消息重新启动整个接口，确保对端也清除该接口上所有的呼叫。
所述的接口为：PRI(Primary Rate Interface，基群速率接口)。
由上述技术方案可以看出，本发明中，对于由用户执行SHUT DOWN进行通话清除操作引起的数据链路层故障，不对通话进行延时处理，而直接清除所有呼叫；当数据链路层恢复连接时，如果接口上没有呼叫，则向对端设备发送重新启动整个接口的消息，以防止对端设备启动了断链保护程序，确保对端设备也将所有呼叫全部清除。本发明根据路由器等网络设备的特点，对QSIG数据链路层故障的产生原因进行了划分，将用户主动执行相应操作引起的链路层故障区别于因客观情况导致的链路层故障进行不同的处理。因此，本发明既可以对由客观情况引起的链路层临时故障进行延时处理，又能够在用户下达旨在中断接口上的数据传输的操作指令时清除PRI上的呼叫(即通话)，释放通信资源，实现用户的实际操作目的。
【附图说明】
图1为现有技术中数据链路层连接恢复时的处理过程示意图；
图2为本发明的具体实施方式流程图；
图3为数据链路层故障解除时对非“零”和非“运行”状态下呼叫的处理过程示意图；
图4为本发明中数据链路层连接恢复时的处理过程示意图。
【具体实施方式】
本发明是根据目前应用的路由器等网络通信设备的特点，设计的一种对数据链路层故障的处理方法。该方法将由用户执行相应操作引起的数据链路层故障和因网络中客观情况引起的数据链路层故障进行了区别，并采用了不同的处理过程，在不降低网络通信性能的前提下，保证了用户执行的清除呼叫操作的可靠性。
在网络通信的通话过程中，当数据链路层发生故障而无法进行正常的数据传输时，数据链路层需要上报“数据链路释放指示”事件，以释放呼叫所占用的通信资源。下面结合附图，对通信过程中处于各种状态下的呼叫，在通信系统中的用于处理QSIG的QSIG处理模块收到数据链路层上报的“数据链路释放指示”事件后的处理过程作进一步的说明：
如图2所示，对处于“运行”状态下的呼叫，当QSIG处理模块收到数据链路层上报的“数据链路释放指示”事件后的处理过程包括：
步骤21：QSIG处理模块收到数据链路层上报的“数据链路释放指示”事件；
步骤22：判断呼叫所在的接口(即PRI)是否已经被人为执行“SHUTDOWN”操作，即用户是否执行了清除呼叫的操作，如果当前接口已经被人为执行“SHUT DOWN”操作，则执行步骤23，否则，执行步骤25；
具体实现方法是：在路由器程序中增加一个标志位，用于记录用户执行“SHUT DOWN”操作；当QSIG处理模块收到链路层故障的消息后，根据该标志位判断是否由用户执行“SHUT DOWN”操作引起的数据链路层故障，如果是由用户执行SHUT DOWN操作引起的，则执行步骤23；否则就按照ECMA-143协议的规定进行处理，即步骤25、26、27描述的过程；
步骤23：向CC(呼叫控制)层发送“数据链路释放指示”消息，不必启动T309定时器，并停止所有正在运行的T309定时器，执行步骤24；
步骤24：立即清除本地所有呼叫，即释放呼叫所占用的通信资源，并进入到“零”状态，处理过程结束。
步骤25：如果当前接口没有被SHUT DOWN，则判断T309定时器是否处于运行状态，如果T309定时器没有处于运行状态，执行步骤26，否则，如果T309定时器正在运行，就不必再次启动T309定时器，直接执行步骤27；
步骤26：启动T309定时器，对当前处于“运行”状态的通话进行保护，执行步骤27；
步骤27：向数据链路层发送“建链请求”，并将呼叫保持在“运行”状态不变，处理过程结束。
步骤21至步骤27的处理过程是本发明的核心，即本发明所述的技术方案主要是针对收到数据链路层上报的“数据链路释放指示”事件后，对处于“运行”状态下的呼叫的处理过程的改进。
本发明所述的T309定时器为断链保护定时器，对处于任何状态下的呼叫，如果T309定时器超时，则停止所有呼叫定时器，并向CC(呼叫控制)层发送“数据链路释放指示”，然后释放呼叫所占用的通信资源，并进入到“零”状态。
前面步骤21至步骤27描述了对处于“运行”状态下的呼叫，当QSIG处理模块收到数据链路层上报的“数据链路释放指示”事件后的处理过程。通信系统中除了处于“运行”状态下的呼叫外，通常还存在一种处于非“零”状态且非“运行”状态下的呼叫，下面将结合图3，对处于非“零”状态且非“运行”状态下的呼叫，当收到数据链路层上报的“数据链路释放指示”事件的处理过程进行描述：
对处于非“零”状态且非“运行”状态下的呼叫，当收到数据链路层上报的“数据链路释放指示”事件时，则向CC(呼叫控制)层发送“数据链路释放指示”，停止所有正在运行的T309定时器，释放呼叫所占用的通信资源，并进入到“零”状态。所述的“零”状态表示呼叫并不存在，相当于电话没有被使用的状态；所述的“运行”表示呼叫已经建立，双方正在通话。该处理过程为现有技术中的处理过程，本发明在实施过程中仍采用上述处理过程。
通信系统中除了处于“运行”状态下的呼叫，以及处于非“零”状态且非“运行”状态下的呼叫外，接口上的呼叫均处于“零”状态。当接口上没有任何呼叫时，即所有呼叫都已经恢复到初始状态“零”状态，如果收到数据链路层上报的“数据链路释放指示”后，则无需采取任何动作，仍然保持“零”状态。
通过上述的描述可以看出，本发明实现了当数据链路层发生故障时，对由用户操作引起数据链路层故障和因客观情况引起的数据链路层故障进行了区别处理。
数据链路层发生故障后，无论由用户执行相应操作引起的数据链路层故障，还是因网络中客观情况引起的数据链路层故障，这种故障通常将在一定的时间内解除，因此，本发明除提供了当数据链路层发生故障时，针对处于各种状态下呼叫的处理过程外，还提供了当所述的数据链路层故障被解除时的处理过程。下面还需要结合图4，对所述的数据链路层故障的解除，即数据链路层连接恢复时的处理过程作进一步说明：
步骤41：确定数据链路连接恢复，即QSIG处理模块收到数据链路层恢复连接的消息；
步骤42：判断本地接口上是否还存在着呼叫，如果存在，则执行步骤43，否则，执行步骤44；
步骤43：如果接口上存在着呼叫，则按照ECMA-143协议规定的流程处理链路层恢复消息，具体处理过程为：停止所有的T309定时器，同时保持本地呼叫的当前状态，并向对端网络设备发送“STATUS ENQUIRY(状态查询)”消息，启动针对对端呼叫状态的状态查询程序，确定本地与对端的呼叫状态是否兼容，如果双方的呼叫状态能够兼容，则保持当前呼叫，否则，启动呼叫清除程序，清除当前接口上存在的呼叫；
步骤44：如果接口上不存在任何呼叫，则向对端设备发送“RESTART(重新启动)”消息请求重新启动整个接口，确保对端设备也清除掉接口上所有的呼叫；
即当所有呼叫都已经恢复到初始状态“零”状态时，收到数据链路层上报的“建链指示”后，就向对端发送“RESTART”消息请求重新启动整个接口。