CN109982364A - 链路自恢复方法、装置、终端系统和存储介质 - Google Patents

Abstract

本申请涉及一种链路自恢复方法、装置、终端系统和存储介质。终端系统分别监控内部数据交互以及外部数据交互；其中，内部数据交互包括通过控制通道与Modem模块的交互；外部数据交互包括通过RRC链路与接入网设备侧的交互，以及通过业务通道与服务器侧的交互。终端系统在基于监控的结果、确认出现链路异常时，执行相应的自恢复；链路异常包括控制通道异常、RRC链路异常以及业务通道异常中的至少一种。通过与3GPP协议的深度融合，以使链路监控与自恢复具有更高的准确性和时效性，用户感知更为良好。并且，终端系统通过多维度的裁决机制，能够更全面地覆盖各种可能出现的链路异常场景，具有更广泛的应用价值。

Description

链路自恢复方法、装置、终端系统和存储介质

技术领域

本申请涉及通信技术领域，特别是涉及一种链路自恢复方法、装置、终端系统和存储介质。

背景技术

在无线通信领域特别是LTE(Long Term Evolution，长期演进)通信领域，移动终端和基站之间的链路可靠性是保障用户业务稳定性的一个重要环节。由于LTE终端设备自身稳定性的因素或者空口交互上的一些不可避免的意外，可能导致空口链路的不稳定和异常。

在实现过程中，发明人发现传统技术中至少存在如下问题：有些异常无法及时得到检测和处理，如终端设备自身协议栈的缺陷、空口环境恶劣导致的信令丢失、终端设备的意外掉网等。传统通过用户网络侧数据面的检测手段，在实时性和准确性上，无法满足实际应用场景中用户对产品高稳定性的需求。

发明内容

基于此，有必要针对传统技术对链路故障的检测存在实时性和准确性差的问题，提供一种链路自恢复方法、装置、终端系统和存储介质。

为了实现上述目的，一方面，本申请实施例提供了一种链路自恢复方法，包括：

终端系统分别监控内部数据交互以及外部数据交互；其中，内部数据交互包括通过控制通道与Modem模块的交互；外部数据交互包括通过RRC(Radio Resource Control，无线资源控制链路)与接入网设备侧的交互，以及通过业务通道与服务器侧的交互。

终端系统在基于监控的结果、确认出现链路异常时，执行相应的自恢复；链路异常包括控制通道异常、RRC链路异常以及业务通道异常中的至少一种。

另一方面，本申请实施例还提供了一种链路自恢复装置，包括：

数据交互监控模块，用于分别监控内部数据交互以及外部数据交互；其中，内部数据交互包括通过控制通道与Modem模块的交互；外部数据交互包括通过RRC链路与接入网设备侧的交互，以及通过业务通道与服务器侧的交互。

异常自恢复模块，用于终端系统在基于监控的结果、确认出现链路异常时，执行相应的自恢复；链路异常包括控制通道异常、RRC链路异常以及业务通道异常中的至少一种。

在其中一个实施例中，提供一种终端系统，终端系统用于执行如上述的链路自恢复方法。

在其中一个实施例中，提供一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述的链路自恢复方法。

上述技术方案中的一个技术方案具有如下优点和有益效果：

终端系统分别监控内部数据交互以及外部数据交互；其中，内部数据交互包括通过控制通道与Modem模块的交互；外部数据交互包括通过RRC链路与接入网设备侧的交互，以及通过业务通道与服务器侧的交互。终端系统在基于监控的结果、确认出现链路异常时，执行相应的自恢复；链路异常包括控制通道异常、RRC链路异常以及业务通道异常中的至少一种。通过与3GPP(3rd Generation Partnership Project，第三代合作伙伴计划)协议的深度融合，以使链路监控与自恢复具有更高的准确性和时效性，用户感知更为良好。并且，终端系统通过多维度的裁决机制，能够更全面地覆盖各种可能出现的链路异常场景，具有更广泛的应用价值。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1为一个实施例的应用环境图；

图2为一个实施例中链路自恢复方法的第一示意性流程图；

图3为一个实施例中链路自恢复方法的第二示意性流程图；

图4为一个实施例中链路自恢复方法的第三示意性流程图；

图5为一个实施例中监控控制通道的流程示意图；

图6为一个实施例中链路自恢复方法的第四示意性流程图；

图7为一个实施例中控制通道自恢复的流程示意图；

图8为一个实施例中链路自恢复方法的第五示意性流程图；

图9为一个实施例中监控RRC链路的第一示意性流程图；

图10为一个实施例中链路自恢复方法的第六示意性流程图；

图11为一个实施例中监控RRC链路的第二示意性流程图；

图12为一个实施例中链路自恢复方法的第七示意性流程图；

图13为一个实施例中监控业务通道的示意性流程图；

图14为一个实施例中RRC链路自恢复或业务通道自恢复的示意性流程图；

图15为一个实施例中链路自恢复方法的第八示意性流程图；

图16为一个实施例中链路自恢复方法的第九示意性流程图；

图17为一个实施例中链路自恢复装置的结构示意图。

具体实施方式

为了便于理解本申请，下面将参照相关附图对本申请进行更全面的描述。附图中给出了本申请的首选实施例。但是，本申请可以以许多不同的形式来实现，并不限于本文所描述的实施例。相反地，提供这些实施例的目的是使对本申请的公开内容更加透彻全面。

需要说明的是，当一个元件被认为是“连接”另一个元件，它可以是直接连接到另一个元件并与之结合为一体，或者可能同时存在居中元件。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中在本申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请。本文所使用的术语“和/或”包括一个或多个相关的所列项目的任意的和所有的组合。

为提高LTE终端和基站之间的链路可靠性，提高业务稳定性，现有技术提供了一种方法，具体包括步骤：基站当和网管系统无法链路连接时，检测断链累计时长；当断链累计时长超过指定时长时，基站通过底层通讯协议向网管系统请求获取ip地址(InternetProtocol Address，互联网协议地址)，携带本基站的唯一标识；根据网管系统返回的ip地址，和网管系统建立ip链路；根据从网管系统获取的信息加载基站软件和配置数据。该方法当基站软件或配置数据不正常导致基站掉站时，能够自动进行系统恢复并连接到网管系统以避免人工下站处理，从而提高维护效率，减少人力和时间的消耗。该方案与本申请实施例所作用的网元不同，本申请实施例作用的网元是终端设备，涵盖的可自愈范围更广。

现有技术还提供另一种方法，具体包括步骤：在确定移动终端不具有分组交换业务能力时，向运营商计费系统发送余额信息查询指令并获取余额指示信息，在余额指示信息移动终端处于业务允许使用状态时，将用户识别卡的状态配置为分组交换有效，该分组交换有效用于指示移动终端具有分组交换业务能力，向服务器发送分组交换域注册请求，并接收服务器反馈的分组交换域注册响应，并恢复移动终端的移动数据业务。该技术方案在移动终端接触业务禁止使用状态后不需要用户参与操作，能够自动恢复移动数据业务，提升了用户体验。但该方法是通过识别终端设备收到去附着命令来判断终端是否不具有分组交换业务能力。而现实使用中，通常由于终端本身程序问题或者空口交互问题，会出现终端在未收到去附着命令时，实际已掉网。此时，该方案无法解决网络的恢复问题。本申请实施例所采用的监控识别手段能够更为细致和有效地解决上述场景下的掉网和自恢复问题。

本申请提供的链路自恢复方法，可以应用于如图1所示的应用环境中。其中，终端102可通过接入网设备104与服务器106进行通信。终端系统通过监控其内部的数据交互以及与外部的数据交互，检测通信链路是否正常，并在出现链路异常时执行相应的自恢复。其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，接入网设备104可以但不限于是各种类型的基站等；服务器106可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

在一个实施例中，如图2所示，提供一种链路自恢复方法，包括：

步骤S110，终端系统分别监控内部数据交互以及外部数据交互；其中，内部数据交互包括通过控制通道与Modem模块的交互；外部数据交互包括通过RRC链路与接入网设备侧的交互，以及通过业务通道与服务器侧的交互。

步骤S120，终端系统在基于监控的结果、确认出现链路异常时，执行相应的自恢复；链路异常包括控制通道异常、RRC链路异常以及业务通道异常中的至少一种。

具体而言，为及时检测终端与接入网设备之间的链路状态，终端系统分别监控终端内部的数据交互，以及终端与外部的数据交互。其中，内部数据交互主要包括终端系统与Modem模块的数据交互；外部数据交互主要包括终端与接入网设备侧的数据交互，以及终端与服务器侧的数据交互。通过监控数据交互的情况，终端系统在检测到出现链路异常时，执行相应的自恢复。具体地，链路异常包括以下异常中的任意一种或任意组合：控制通道异常、RRC链路异常以及业务通道异常；自恢复包括控制通道的自恢复、RRC链路的自恢复以及业务通道的自恢复中的至少一种。

具体地，终端系统可通过监控控制通道与Modem模块的数据交互情况，确认控制通道是否异常，若是，则确认出现控制通道异常，执行控制通道的自恢复。终端系统还可通过监控与接入网设备侧的数据交互情况，确认RRC链路是否异常，若是，则确认出现RRC链路异常，执行RRC链路的自恢复。同时，终端系统还可通过监控与服务器侧的数据交互情况，确认业务通道是否异常，若是，则确认出现业务通信异常，执行业务通道的自恢复。

需要说明的是，Modem模块可为3GPP的调制解调模块。控制通道可用于终端系统与Modem模块的信令交互，实现终端系统对3GPP协议的控制和对链路通道建立和拆除的控制。保证控制通道正常，进而才能实现数据通道的异常能够得到有效的自愈。应该注意的是，控制通道可为终端内部的链路通道。

RRC链路可用于终端系统与接入网设备侧的数据交互，实现RRC层的数据传输，能够传输广播系统信息、RRC连接控制信息，测量配置与报告信息，以及通用协议处理信息等，即，RRC链路是LTE的层3链路，用于承载业务，RRC链路如果异常，终端与接入网设备侧将无法正常通信。业务通道可用于终端系统与服务器侧的数据交互，实现业务层的数据传输，能够传输业务数据和/或业务信令等，即，业务通道是业务承载的逻辑通道，所有用户服务都在此通道上传输，如果业务通道异常，则无法为用户提供正常的用户服务。应该注意的是，RRC链路以及业务通道均为终端系统与外部交互的链路通道。

终端系统可在监控到数据交互满足异常条件时，确认出现相应的链路异常并执行相应的自恢复。其中，异常条件可由本领域技术人员根据终端系统所处的通信系统或环境进行设置，在此不做具体的限制。链路的自恢复过程可包括异常的链路通道的重建；具体地，例如复位Modem模块并重建控制通道，在接入网设备侧进行重新附着并重新建立业务承载等，在此不做具体限制。

本申请实施例通过与3GPP协议的深度融合，通过对3GPP标准的RRC层、业务层等的数据监控，感知LTE协议栈的运行是否良好，并通过控制通道技术实时进行纠错和修复，保证LTE协议栈无障碍运行，保证用户服务的正常提供和异常自恢复，以使链路监控与自恢复具有更高的准确性和时效性，用户感知更为良好。并且，终端系统采用多维度的裁决机制，通过监控内部数据交互、与接入网设备侧的数据交互以及与服务器侧的数据交互，进而及时检测链路通道的异常状态，能够更全面地覆盖各种可能出现的链路异常场景，具有更广泛的应用价值。

在一个实施例中，如图3所示，终端系统在基于监控的结果、确认出现链路异常的步骤包括：

步骤S126，终端系统若在第一监控时段内、未通过控制通道接收到Modem模块的响应信息，确认出现控制通道异常。

具体而言，终端系统在监控与Modem模块的数据交互时，可检测在第一监控时段内，是否通过控制通道与Modem模块进行交互并得到Modem模块的响应；若是，则确认控制通道正常；若否，则确认出现控制通道异常。

需要说明的是，在控制通道的使用过程中，终端系统每通过控制通道成功收发一条与Modem模块交互的控制数据时，确认控制通道正常；终端系统定时发送心跳消息给Modem模块并得到响应时，确认控制通道正常。在每次确认控制通道正常时，可开始第一监控时段的计时；若在第一监控时段内接收到Modem模块的响应消息时，则确认控制通道正常并重新进行第一监控时段的计时。其中，第一监控时段可根据终端系统实际的应用环境进行设置，在此不做具体限定。Modem模块的响应消息可包括对控制数据的响应消息，以及对心跳消息的响应消息。

本申请实施例通过检测终端系统在设定的第一监控时段内，正常控制命令或心跳是否能活动Modem模块的响应，来裁决控制通道是否异常，进而确定是否进行控制通道的自恢复，保证对控制通道的实时监控，能够及时完成异常链路的自恢复。

在一个实施例中，如图4所示，终端系统若在第一监控时段内、未通过控制通道接收到Modem模块的响应信息，确认出现控制通道异常的步骤之前，还包括步骤：

步骤S122，终端系统在建立控制通道时，启动定时器进行计时。

步骤S124，终端系统在通过控制通道获取到Modem模块的响应信息时，清零定时器，重新进行计时；响应消息包括控制数据响应消息和/或心跳数据响应消息。

终端系统若在第一监控时段内、未通过控制通道接收到Modem模块的响应信息，则确认为控制通道异常的步骤包括：

步骤S128，终端系统在定时器超时时，确认控制通道的状态量为异常状态；状态量为终端系统在建立控制通道时设置的、用于标识控制通道的当前状态的参数。

具体而言，终端系统可通过定时器进行第一监控时段的计时；具体地，在初始化阶段，终端系统建立控制通道时，启动定时器进行计时，并设置用于标识控制通道的当前状态的状态量。其中，在初始时刻，由于控制通道能够顺利建立且正常使用，因此，此时该状态量为正常状态。终端系统在通过控制通道与Modem模块完成交互时，将定时器清零，重新进行计时；若定时器超时，表明在指定的时间内，终端系统的正常控制数据和心跳均未获得Modem模块的响应，则将状态量切换为异常状态，确认出现控制通道异常，执行控制通道的自恢复。进一步地，可在控制通道重建成功时，将定时器清零并重新进行计时。

需要说明的是，定时器的启动、清零以及计时的触发方式可根据实际需要进行设置，即，第一监控时段的计时方式有多种，在此不一一列举。本申请实施例在控制通道与Modem模块完成一次交互后，监控控制通道是否接到Modem模块的响应消息，若超过第一监控时段仍未接收到Modem模块的响应，则确认出现控制通道异常，及时进行控制通道的自恢复，保证链路监控与自恢复具有更高的准确性和时效性。

在一个具体的示例中，如图5所示，控制通道自恢复方法需要先通过检测手段，判定当前控制通道是否异常，进而进入自恢复裁决。对当前控制通道的异常检测手段，可通过一个控制通道的状态量来标识。在终端系统初始化阶段，终端系统需要初次建立控制通道；在终端系统建立控制通道时，同时建立一个控制通道状态量用以标识控制通道的当前状态。在初始化时刻，终端系统同时需要设置一个定时器装置，用于控制通道的保活，并设置当定时器装置超时时，切换控制通道状态量为异常状态。在控制通道使用过程中，终端系统每当通过控制通道成功收发一条控制数据，即确认一次当前控制通道状态为正常；异或，终端系统每定时发送一条心跳并获得Modem模块的响应，即确认一次当前控制通道状态为正常。当终端系统确认控制通道状态为正常时，系统重置定时器装置，进行重新计时。

在一个实施例中，如图6所示，终端系统在基于监控的结果、确认出现控制通道异常时，执行相应的自恢复的步骤包括：

步骤S130，终端系统关闭控制通道接口，发送复位指令给Modem模块；复位指令用于指示Modem模块进行复位。

步骤S132，终端系统基于底层接口重新打开控制通道接口，完成控制通道的重建。

具体而言，终端系统基于监控的结果，确认出现控制通道异常时，关闭当前控制通道接口，并发送复位指令给Modem模块，尝试复位Modem模块。由于控制通道异常也可能是由于底层通道异常所致，所以无法保证复位Modem模块之后，控制通道仍基于原有的底层通道建立。因此，在复位Modem模块之后，终端系统需要动态识别新的控制通道接口绑定在哪个底层接口之上，并基于该底层接口重新打开控制通道接口，完成控制通道的重建立。

本申请实施例通过关闭控制通道接口、复位Modem模块后，重新打开控制通道接口的方式，完成控制通道的重建，能够有效进行控制通道的自恢复，进而可保证数据通道的传输或自恢复。

在一个实施例中，如图6所示，终端系统基于底层接口重新打开控制通道接口，完成控制通道的重建的步骤之后，还包括步骤：

步骤S134，终端系统通过重建后的控制通道，向Modem模块发送心跳数据，并判断是否获得Modem模块的响应，若是，则确认重建成功；若否，则确认为一次重建失败，并重新执行控制通道的自恢复。

步骤S136，终端系统在重建失败的次数超过重建阈值时，进行重新启动。

具体而言，在完成控制通道的重建后，需要确认重建是否成功。因此，终端系统可通过重建得到的控制通道向Modem模块发送心跳数据，判断是否得到Modem模块的及时响应；若是，则确认控制通道重建成功；若否，则确认为一次重建失败，并重新执行控制通道的自恢复，即，重复上述的控制通道重建和重建确认的过程。如果重建失败的次数超过重建阈值，表明终端系统当前可能存在其他异常，例如底层异常等，此时，需要终端系统进行重启，以完成控制通道的重建，进而保证链路传输以及自恢复的正常进行。进一步地，可在确认控制通道重建成功时，清零重建失败的计数，以便下一次的判定。

本申请实施例在进行控制通道的重建后，及时验证重建是否成功；在重建次数超过终端系统设置的阈值仍无法与Modem模块正常通信时，终端系统及时进行重新启动，避免陷入控制通道重建的无效循环中、影响后续数据通道的传输及自恢复。基于此，能够进一步提高终端系统在链路自恢复上的准确性、可靠性和实时性。

在一个具体的示例中，控制通道的自恢复流程可如图7所示，终端系统首先关闭已打开的控制通道接口，然后尝试复位Modem模块。控制通道重建立之后，终端系统通过新的控制通道发送心跳给Modem，若获得Modem的响应，则控制通道重建成功。否则，重复以上过程。若以上过程重复达到系统设定阈值仍无效，重启终端系统。

在一个实施例中，如图3所示，终端系统在基于监控的结果、确认出现链路异常的步骤包括：

步骤S140，终端系统处于RRC连接态、且在第二监控时段内未接收到接入网设备侧发送的数据时，确认出现RRC链路异常。

具体而言，终端系统处于RRC连接态时，监控外部数据交互的步骤需要监控接收接入网设备侧发送的数据的情况；若终端系统检测到在第二监控时段内未接收接入网设备侧的数据时，则表明接入网设备侧未有任何信令及业务数据发送给终端，然而终端系统又一直处于RRC连接态；此时，可裁定终端系统的RRC状态异常，该异常的原因可能是由于丢失基站去附着指令所导致，因此，需要触发终端系统的自恢复动作，执行RRC链路的自恢复。

需要说明的是，第二监控时段可根据终端系统所处的通信系统或环境进行设置。终端系统可在成功接收到接入网设备侧的数据时，监控是否成功接收到接入网设备侧的下一条数据；若超过第二监控时段仍未接收到接入网设备侧发送的数据，则确认出现RRC链路异常；若在第二监控时段内接收到接入网设备侧发送的数据，则在确认成接收时继续进行监控。其中，终端系统可通过检测是否接收到信令、业务数据或ACK帧等，进而判断是否能与接入网设备侧正常交互，例如成功接收则触发的方式、或者周期性检测收发统计值等，在此不做具体限制。

本申请实施例中，终端系统可实时监控RRC连接态下能否成功接收接入网设备侧的数据，确认RRC链路的状态是否正常；在终端系统与接入网设备侧的通信链路出现异常时，及时进行自恢复，以使链路监控与自恢复具有更高的准确性和时效性。

在一个实施例中，如图8所示，终端系统处于RRC连接态、且在第二监控时段内未接收到接入网设备侧发送的数据时，确认出现RRC链路异常的步骤包括：

步骤S142，终端系统监控MAC层(Media Access Control，媒体介入控制层)接收侧的流量统计值。

步骤S144，终端系统若监控到MAC层接收侧的流量统计值在第二监控时段内为零，则确认为RRC链路异常。

步骤S146，终端系统在退出RRC连接态时，停止监控MAC层接收侧的流量统计值。

具体而言，终端系统监控是否接收到接入网设备侧发送的数据的过程，可通过监控MAC层接收侧的流量统计值来实现。具体地，终端系统可在进入RRC连接态时，开始监控MAC层接收侧的流量统计值并启动第二监控时段的计时。若MAC层接收侧的流量统计值在第二监控时段内一直保持为零，则表明终端系统在该时段内未接收到接入网设备侧的数据，即，处于RRC连接态的终端系统在指定时段内，MAC层没有数据流入；此时，可确认出现RRC链路异常。进一步地，当终端系统退出RRC连接态时，停止监控MAC层接收侧的流量统计值，保证下一次裁决结果能够真实反映RRC连接态时链路的状态。

需要说明的是，MAC层接收侧的流量统计值可用于统计MAC层的数据流入情况；在接收到接入网设备的数据时，触发该流量统计值计数。通过监控MAC层接收侧的流量统计值，可获取MAC层数据的流入情况；其中，MAC层数据包括信令数据和业务数据。基于此，本申请实施例中提及到的MAC层监控及自愈方式可进行更低协议层的检测，具有颗粒度更细致，响应时间更快速，无需额外协议链路建立等特点。

在一个具体的示例中，RRC链路连接态下自恢复的裁决可如图9所示，该裁决在终端系统进入RRC连接态时启用，当终端系统退出RRC连接态时禁用且清除KPI(KeyPerformance Indicatio，关键性能指标)统计值(包括MAC层接收侧的流量统计值)，保证方法裁决结果真实反映RRC连接态状态。当终端系统处于RRC连接态时，通过实时收集MAC层KPI数据，获取MAC层数据流出和流入情况。终端系统对MAC层的接收侧KPI数据进行监控，当发现，MAC层的接收侧KPI数据在一段时间内一直为0，确认出现RRC链路异常，执行RRC链路的自恢复。

在一个实施例中，如图3所示，终端系统在基于监控的结果、确认出现链路异常的步骤包括：

步骤S150，终端系统处于RRC空闲态、且在第三监控时段内、向接入网设备侧发送接入请求未得到相应的反馈响应时，确认出现RRC链路异常。

具体而言，终端系统处于RRC空闲态时，监控外部数据交互的步骤需要监控终端系统的接入请求是否得到接入网设备侧的响应。终端系统若检测到在第三监控时段内、向接入网设备侧发送接入请求、且未及时接收到接入网设备侧对接入请求的反馈消息时，则表明终端系统在空闲态下，向接入网设备侧请求进入连接态并发送数据，但接入网设备一直未调度；此时，可考虑终端实际掉网，从而触发终端的自恢复动作，执行RRC链路的自恢复。

需要说明的是，第三监控时段可根据终端系统所处的通信系统或环境进行设置。具体地，终端系统处于空闲态时，可在成功发送接入请求给接入网设备侧时，监控是否接收到接入网设备侧相应的反馈消息；若超过第三监控时段仍未接收到接入网设备侧反馈的响应，则确认出现RRC链路异常。其中，终端系统可通过多种方式来检测是否接收到接入网设备侧的反馈响应，例如成功接收则触发的方式，或者周期性检测收发统计值等，在此不做具体限制。

本申请实施例中，终端系统可实时监控RRC空闲态下发送的接入请求、能否及时得到接入网设备侧的响应，进而确认RRC链路的状态是否正常；在终端系统与接入网设备侧的通信链路出现异常时，及时进行自恢复，以使链路监控与自恢复具有更高的准确性和时效性。

在一个实施例中，如图10所示，终端系统处于RRC空闲态、且在第三监控时段内、向接入网设备侧发送接入请求未得到相应的反馈响应时，确认出现RRC链路异常的步骤包括：

步骤S152，终端系统监控MAC层接收侧的流量统计值和MAC层发送侧的流量统计值。

步骤S154，终端系统若监控到MAC层接收侧的流量统计值在第三监控时段内保持不变，且MAC层发送侧的流量统计值在第三监控时段内增长，则确认为RRC链路异常。

步骤S156，终端系统在退出RRC空闲态时，清除且停止监控MAC层接收侧的流量统计值、和MAC层发送侧的流量统计值。

具体而言，终端系统在空闲态下，监控发送给接入网设备侧的接入请求是否得到反馈响应的过程，可通过监控MAC层接收侧和发送侧的流量统计值来实现。具体地，终端系统可在进入RRC空闲态时，开始监控MAC层接收侧和发送侧的流量统计值，并启动第三监控时段的计时。若识别到接收侧的流量统计值在核定监控时段内未增长且发送侧的流量统计值有增长，则表明终端系统在该时段内仅发送数据、且未接收到接入网设备侧的数据，即，在指定时段内，处于RRC空闲态的终端系统MAC层仅有数据流出而无数据流入；此时，可确认出现RRC链路异常。进一步地，当终端系统退出RRC空闲态时，禁用且清除MAC层接收侧和发送侧的流量统计值，保证下一次裁决结果能够真实反映RRC空闲态时链路的状态。

需要说明的是，MAC层发送侧的流量统计值可用于统计MAC层的数据流出情况；在向接入网设备发送数据时，触发该流量统计值计数。本申请实施例中提及到的MAC层监控及自愈方式可进行更低协议层的检测，具有颗粒度更细致，响应时间更快速，无需额外协议链路建立等特点。

在一个具体的示例中，RRC链路空闲态下自恢复的裁决可如图11所示，该裁决在终端系统进入RRC空闲态时启用，当终端系统退出RRC空闲态时禁用且清除KPI统计值(包括MAC层接收侧的流量统计值和MAC层发送侧的流量统计值)，保证裁决结果真实反映RRC空闲态状态。当终端系统处于RRC空闲态时，动态获取MAC层KPI并比较发送侧和接收侧的KPI，当识别接收侧KPI在核定时间窗内未增长且发送侧KPI有增长，确认出现RRC链路异常，执行RRC链路的自恢复。

在一个实施例中，如图3所示，终端系统在基于监控的结果、确认出现链路异常的步骤包括：

步骤S160，终端系统满足业务通道异常条件时，确认出现业务通道异常；业务通道异常条件包括以下条件中的任意一项或任意组合：在第四监控时段内仅发送业务数据，在第四监控时段内仅接收业务数据，以及向服务器侧发送心跳消息且未得到相应的反馈响应。

具体而言，终端系统通过监控业务数据的交互以及业务心跳，来检测业务通道是否正常。当IP层以上的故障发生时，可能发生长时间某种同类型业务数据(比如TCP(Transmission Control Protocol，传输控制协议)业务)只发不收或者只收不发的情况，此时，可以判断业务面可能存在异常。同时，终端系统定时向服务器发送心跳信息，可用于确认业务通道的状态；若心跳信息超时未回复，则可确认出现业务通道异常。

需要说明的是，第四监控时段可根据终端系统所处的通信系统或环境进行设置。具体地，终端系统可在成功完成一次与服务器的业务数据收发后，监控终端系统是否继续与服务器侧进行数据的双向交互；若超过第四监控时段仍未发生数据双向交互，则确认出现业务通道异常。其中，终端系统可通过多种方式来检测是否与服务器侧进行双向数据交互，例如交互成功则触发的方式，或者周期性检测收发统计值等，在此不做具体限制。

本申请实施例中，终端系统可实时监控与服务器侧进行的数据交互是否正常，进而确认业务通道的状态是否正常；在终端系统与服务器侧的通信链路出现异常时，及时进行自恢复，以使链路监控与自恢复具有更高的准确性和时效性。

在一个实施例中，如图12所示，终端系统满足业务通道异常条件时，确认出现业务通道异常的步骤包括：

步骤S162，终端系统监控业务接收侧流量统计值和业务发送侧流量统计值。

步骤S164，终端系统若监控到业务接收侧流量统计值在第四监控时段内保持不变、且业务发送侧流量统计值在第四监控时段内增长，则确认为业务通道异常。

步骤S166，终端系统若监控到业务接收侧流量统计值在第四监控时段内增长、且业务发送侧流量统计值在第四监控时段内保持不变，则确认为业务通道异常。

具体而言，终端系统监控与服务器侧的数据双向交互的过程，可通过监控业务层接收侧和发送侧的流量统计值来实现。具体地，终端系统可在开始业务数据传输时或完成一次业务数据交互时，开始监控业务层接收侧和发送侧的流量统计值，并启动第四监控时段的计时。若识别到接收侧的流量统计值在核定监控时段内未增长且发送侧的流量统计值有增长，则表明终端系统在该时段内仅发送业务数据、且未接收到服务器侧的业务数据，即，在指定时段内，终端系统的业务层仅有数据流出而无数据流入；此时，可确认出现RRC链路异常。同理，若识别到发送侧的流量统计值在核定监控时段内未增长且接收侧的流量统计值有增长，则表明终端系统在该时段内仅接收服务器侧的业务数据、且未发送业务数据给服务器侧，即，在指定时段内，终端系统的业务层仅有数据流入而无数据流出；此时，可确认出现RRC链路异常。进一步地，当终端系统退出业务传输时，可将业务层接收侧和发送侧的流量统计值清零，保证下一次裁决结果能够真实反映业务通道的状态。

需要说明的是，业务层发送侧的流量统计值可用于统计业务层的数据流出情况；在向服务器侧发送数据时，触发该流量统计值计数。业务层接收侧的流量统计值可用于统计业务层的数据流入情况；在接收服务器侧发送的数据时，触发该流量统计值计数。

在一个具体的示例中，业务自恢复的裁决可如图13所示。该裁决通过监控业务KPI(包括业务接收侧流量统计值和业务发送侧流量统计值)和业务心跳来实现判别。其中，业务KPI是指业务层的收发数据指标，当IP层以上的故障发生时，可能发生长时间某种同类型业务数据(比如TCP业务)只发不收或者只收不发的情况，从而可以判别业务面可能存在异常；业务心跳是指，通过定时向指定服务器发送心跳的方式，如向网管服务器及NTP服务器及某些公网域名等发送定时心跳的方式来确认业务链路的状态。当以上两种方式中的一种出现异常，即发生长时间只收不发或只发不收，或者心跳超时未回复，则可判定业务层可能存在异常。在采用多重手段的叠加验证后，可确认业务层存在异常，此时需要进行业务通道的自恢复。

在一个实施例中，终端系统在基于监控的结果、确认出现RRC链路异常时，执行相应的自恢复的步骤包括：

终端系统在确认出现RRC链路异常时，检测射频链路的状态是否正常：若是，则依次执行接入网设备侧的去附着与重新附着，并重新建立业务承载；若否，则重置射频链路。

具体而言，在基于监控的结果、确认出现RRC链路异常时，终端系统首先检查终端的射频链路是否正常；若射频链路正常，则终端系统发送去附着命令给接入网设备侧，以完成从接入网设备侧的去附着，再发送附着命令给接入网设备侧，重新完成附着，并重新建立业务承载；若射频链路异常，可通过重置射频链路的方式，确保射频链路恢复正常状态。

本申请实施例在进行RRC链路的自恢复时，先保证终端的射频链路正常，即，确保终端的物理层甚至更底层的正常运行，以便通过重新附着，实现RRC链路的重建，避免由于射频链路的异常而影响链路的自恢复。

在一个具体的示例中，RRC链路的自恢复可如图14所示，首先系统检查终端射频链路状态，确认射频无异常，进而系统发送去附着命令，再发送附着命令重新完成附着，并重新建立业务承载。同时，业务通道的自恢复可通过重建业务承载通道的形式完成，包括重新确认射频链路状态、重新去附着和附着以及重新建立业务承载。

在一个实施例中，如图15所示，终端系统在基于监控的结果、确认出现业务通道异常时，执行相应的自恢复的步骤包括：

步骤S170，终端系统在确认出现业务通道异常时，检测射频链路的状态是否正常：若是，则依次执行接入网设备侧的去附着与重新附着，并重新建立业务承载；若否，则重置射频链路。

具体而言，在基于监控的结果、确认出现业务通道异常时，终端系统首先检查终端的射频链路是否正常；若射频链路正常，则终端系统发送去附着命令给接入网设备侧，以完成从接入网设备侧的去附着，再发送附着命令给接入网设备侧，重新完成附着，并重新建立业务承载；若射频链路异常，可通过重置射频链路的方式，确保射频链路恢复正常状态。

本申请实施例在进行业务通道的自恢复时，先保证终端的射频链路正常，即，确保终端的物理层甚至更底层的正常运行，以便通过重新附着，实现业务通道的重建，避免由于射频链路的异常而影响链路的自恢复。

在一个实施例中，终端系统的链路检测和自恢复如图16所示。主要由4种方法构成，包括控制通道的自恢复方法、RRC链路连接态的自恢复方法、RRC链路空闲态的自恢复方法以及业务通道的自恢复方法。其中，控制通道的自恢复方法采用控制通道查询机制和动态通道检测机制，实现对控制通道的监控和自愈。RRC链路连接态的自恢复方法通过在RRC连接态下对MAC层上下行数据统计的比较和分析，实现对RRC链路连接态下、链路是否连通的状态监测；RRC链路空闲态的自恢复方法通过在RRC空闲态下，对下行链路MAC层数据统计的分析，实现对RRC链路空闲态下、是否掉网的辨别和自恢复。业务通道的自恢复方法通过对NAS层(Non-access stratum，非接入层)业务的流量监控(包括心跳数据的监控)、与MAC层业务流量的对比确认，实现对业务通道的监控和自恢复。

本申请实施例通过与3GPP协议的深度融合，通过对LTE协议(3GPP标准)的RRC层、业务层以及MAC层的数据监控，感知LTE协议栈的运行是否良好，并通过控制通道技术实时进行纠错和修复，保证LTE协议栈无障碍运行，保证用户服务的正常提供和异常自恢复。具有更高的准确性和时效性，用户感知更为良好。并且，终端系统不仅监控内部的数据交互，还监控其与外部的数据交互，通过多维度的裁决机制，监控控制通道、RRC链路以及业务通道等链路通道的状态，更全面地覆盖各种可能出现的链路异常场景，具有更广泛的应用价值。

应该理解的是，虽然图2至16的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2至16中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。在一个实施例中，提供一种链路自恢复装置，如图17所示，包括：

数据交互监控模块，用于分别监控内部数据交互以及外部数据交互；其中，内部数据交互包括通过控制通道与Modem模块的交互；外部数据交互包括通过RRC链路与接入网设备侧的交互，以及通过业务通道与服务器侧的交互。

异常自恢复模块，用于终端系统在基于监控的结果、确认出现链路异常时，执行相应的自恢复；链路异常包括控制通道异常、RRC链路异常以及业务通道异常中的至少一种。

关于链路自恢复装置的具体限定可以参见上文中对于链路自恢复方法的限定，在此不再赘述。上述链路自恢复装置包括对应链路自恢复方法中各个步骤的模块，此处不再赘述。应该注意的是，各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供一种终端系统，终端系统用于执行如上述的链路自恢复方法。关于终端系统可实现的步骤以及具体限定可以参见上文中对于链路自恢复方法的限定，在此不再赘述。

在一个实施例中，提供一种计算机存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述的链路自恢复方法。关于存储介质可实现的步骤以及具体限定可以参见上文中对于链路自恢复方法的限定，在此不再赘述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (15)

1.一种链路自恢复方法，其特征在于，包括：

终端系统分别监控内部数据交互以及外部数据交互；其中，所述内部数据交互包括通过控制通道与Modem模块的交互；所述外部数据交互包括通过RRC链路与接入网设备侧的交互，以及通过业务通道与服务器侧的交互；

所述终端系统在基于所述监控的结果、确认出现链路异常时，执行相应的自恢复；所述链路异常包括控制通道异常、RRC链路异常以及业务通道异常中的至少一种。

2.根据权利要求1所述的链路自恢复方法，其特征在于，所述终端系统在基于所述监控的结果、确认出现链路异常的步骤包括：

所述终端系统若在第一监控时段内、未通过所述控制通道接收到所述Modem模块的响应信息，确认出现所述控制通道异常。

3.根据权利要求2所述的链路自恢复方法，其特征在于，所述终端系统若在第一监控时段内、未通过所述控制通道接收到所述Modem模块的响应信息，确认出现所述控制通道异常的步骤之前，还包括步骤：

所述终端系统在建立所述控制通道时，启动定时器进行计时；

所述终端系统在通过所述控制通道获取到所述Modem模块的响应信息时，清零所述定时器，重新进行计时；所述响应消息包括控制数据响应消息和/或心跳数据响应消息；

所述终端系统若在第一监控时段内、未通过所述控制通道接收到所述Modem模块的响应信息，确认为所述控制通道异常的步骤包括：

所述终端系统在所述定时器超时时，确认所述控制通道的状态量为异常状态；所述状态量为所述终端系统在建立所述控制通道时设置的、用于标识所述控制通道的当前状态的参数。

4.根据权利要求1所述的链路自恢复方法，其特征在于，所述终端系统在基于所述监控的结果、确认出现所述控制通道异常时，执行相应的自恢复的步骤包括：

所述终端系统关闭控制通道接口，发送复位指令给所述Modem模块；所述复位指令用于指示所述Modem模块进行复位；

所述终端系统基于底层接口重新打开所述控制通道接口，完成所述控制通道的重建。

5.根据权利要求4所述的链路自恢复方法，其特征在于，所述终端系统基于底层接口重新打开所述控制通道接口，完成所述控制通道的重建的步骤之后，还包括步骤：

所述终端系统通过所述重建后的控制通道，向所述Modem模块发送心跳数据，并判断是否获得所述Modem模块的响应，若是，确认重建成功；若否，确认为一次重建失败，并重新执行所述控制通道的自恢复；

所述终端系统在所述重建失败的次数超过重建阈值时，进行重新启动。

6.根据权利要求1所述的链路自恢复方法，其特征在于，所述终端系统在基于所述监控的结果、确认出现链路异常的步骤包括：

所述终端系统处于RRC连接态、且在第二监控时段内未接收到所述接入网设备侧发送的数据时，确认出现所述RRC链路异常。

7.根据权利要求6所述的链路自恢复方法，其特征在于，所述终端系统处于RRC连接态、且在第二监控时段内未接收到所述接入网设备侧发送的数据时，确认出现所述RRC链路异常的步骤包括：

所述终端系统监控MAC层接收侧的流量统计值；

所述终端系统若监控到所述MAC层接收侧的流量统计值在所述第二监控时段内为零，确认为所述RRC链路异常；

所述终端系统在退出所述RRC连接态时，停止监控所述MAC层接收侧的流量统计值。

8.根据权利要求1所述的链路自恢复方法，其特征在于，所述终端系统在基于所述监控的结果、确认出现链路异常的步骤包括：

所述终端系统处于RRC空闲态、且在第三监控时段内、向所述接入网设备侧发送接入请求未得到相应的反馈响应时，确认出现所述RRC链路异常。

9.根据权利要求8所述的链路自恢复方法，其特征在于，所述终端系统处于RRC空闲态、且在第三监控时段内、向所述接入网设备侧发送接入请求未得到相应的反馈响应时，确认出现所述RRC链路异常的步骤包括：

所述终端系统监控MAC层接收侧的流量统计值和MAC层发送侧的流量统计值；

所述终端系统若监控到所述MAC层接收侧的流量统计值在所述第三监控时段内保持不变，且所述MAC层发送侧的流量统计值在所述第三监控时段内增长，确认为所述RRC链路异常；

所述终端系统在退出所述RRC空闲态时，清除且停止监控所述MAC层接收侧的流量统计值、和所述MAC层发送侧的流量统计值。

10.根据权利要求1所述的链路自恢复方法，其特征在于，所述终端系统在基于所述监控的结果、确认出现链路异常的步骤包括：

所述终端系统满足业务通道异常条件时，确认出现所述业务通道异常；所述业务通道异常条件包括以下条件中的任意一项或任意组合：在第四监控时段内仅发送业务数据，在所述第四监控时段内仅接收业务数据，以及向所述服务器侧发送心跳消息且未得到相应的反馈响应。

11.根据权利要求10所述的链路自恢复方法，其特征在于，所述终端系统满足业务通道异常条件时，确认出现所述业务通道异常的步骤包括：

所述终端系统监控业务接收侧流量统计值和业务发送侧流量统计值；

所述终端系统若监控到所述业务接收侧流量统计值在所述第四监控时段内保持不变、且所述业务发送侧流量统计值在所述第四监控时段内增长，确认为所述业务通道异常；

所述终端系统若监控到所述业务接收侧流量统计值在所述第四监控时段内增长、且所述业务发送侧流量统计值在所述第四监控时段内保持不变，确认为所述业务通道异常。

12.根据权利要求1至11任意一项所述的链路自恢复方法，其特征在于，所述终端系统在基于所述监控的结果、确认出现RRC链路异常时，执行相应的自恢复的步骤包括：

所述终端系统在确认出现所述RRC链路异常时，检测射频链路的状态是否正常：若是，依次执行所述接入网设备侧的去附着与重新附着，并重新建立业务承载；若否，重置所述射频链路；

所述终端系统在基于所述监控的结果、确认出现业务通道异常时，执行相应的自恢复的步骤包括：

所述终端系统在确认出现所述业务通道异常时，检测射频链路的状态是否正常：若是，依次执行所述接入网设备侧的去附着与重新附着，并重新建立业务承载；若否，重置所述射频链路。

13.一种链路自恢复装置，其特征在于，包括：

数据交互监控模块，用于分别监控内部数据交互以及外部数据交互；其中，所述内部数据交互包括通过控制通道与Modem模块的交互；所述外部数据交互包括通过RRC链路与接入网设备侧的交互，以及通过业务通道与服务器侧的交互；

异常自恢复模块，用于所述终端系统在基于所述监控的结果、确认出现链路异常时，执行相应的自恢复；所述链路异常包括控制通道异常、RRC链路异常以及业务通道异常中的至少一种。

14.一种终端系统，其特征在于，所述终端系统用于执行如权利要求1至12任意一项所述的链路自恢复方法。

15.一种计算机存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1至12任意一项所述的链路自恢复方法。