CN114451002A - 用户设备和用于处理用户设备的通信异常的方法 - Google Patents

Abstract

提供了一种用于处理用户设备(UE)的通信异常的方法和UE。该方法包括：UE的监测机制检测通信异常事件；将通信异常事件以及通信异常事件的属性信息一起报告给处理机制；处理机制处理通信异常事件；当满足预设条件时，处理机制将属性信息报告给预防机制，以预防通信异常事件再次发生。

Description

用户设备和用于处理用户设备的通信异常的方法

技术领域

本申请涉及电子设备领域，尤其涉及用于处理用户设备(user equipment，UE)的通信异常的方法和UE。

背景技术

诸如手机之类的用户设备(user equipment，UE)在我们的日常生活中越来越重要。人们使用UE通过语音通话、视频通话、SMS等方式与他人进行通信。人们还可以通过UE观看视频或浏览互联网。

在与网络或其他外部设备进行通信期间，可能存在可能影响通信的各种问题。目前，当出现问题时，用户需要手动重试通信，耗时、复杂，且一般无法彻底并成功地解决问题。

发明内容

根据本公开第一方面，提供了一种用于处理用户设备(user equipment，UE)的通信异常的方法。该方法包括：UE的监测机制检测通信异常事件；将通信异常事件与该通信异常事件的属性信息一起报告给处理机制；处理机制处理通信异常事件；当满足预设条件时，处理机制将属性信息报告给预防机制，以预防再次发生通信异常事件。

根据结合本公开第一方面的实施例，上述方法还包括：根据通信异常事件和事件ID之间的对应关系，确定与通信异常事件对应的事件ID，其中，每个通信异常事件具有唯一的事件ID。

根据结合本公开第一方面的实施例，将通信异常事件报告给处理机制包括：将事件ID报告给处理机制。

根据结合本公开第一方面的实施例，处理机制处理通信异常事件包括：根据事件ID和动作之间的对应关系，确定与上述事件ID对应的动作；触发该动作以处理通信异常事件。

根据结合本公开第一方面的实施例，预设条件为：处理机制未能处理通信异常事件，并且该通信异常事件在预设时段内发生了预设次数。

根据结合本公开第一方面的实施例，预设条件为：在预设时段内，处理机制未能处理通信异常事件。

根据结合本公开第一方面的实施例，预设条件为：在预设次数的尝试后，处理机制未能处理通信异常事件。

根据结合本公开第一方面的实施例，预设条件为：在预设时段内尝试预设次数后，处理机制未能处理通信异常事件。

根据结合本公开第一方面的实施例，属性信息包括小区相关信息。

根据结合本公开第一方面的实施例，小区相关信息包括以下至少之一：小区ID、当前使用的无线接入技术(radio access technology，RAT)、当前通信的公共陆地移动网(public land mobile network，PLMN)。

根据结合本公开第一方面的实施例，在预防机制中，以下动作中的至少一个被触发：将小区ID添加到低优先级小区列表或黑名单、暂时禁用当前使用的RAT、以及暂时禁用当前通信的PLMN。

根据结合本公开第一方面的实施例，在预防机制中，当定时器到期或当与小区相关信息有关的位置改变时，解除上述动作。

根据结合本公开第一方面的实施例，属性信息还包括通信异常事件的时间信息和位置信息中的至少一个。

根据结合本公开第一方面的实施例，将通信异常事件报告给处理机制包括：在通信异常事件持续了预设时间段的情况下，将通信异常事件报告给处理机制。

根据结合本公开第一方面的实施例，将通信异常事件报告给处理机制包括：在通信异常事件发生的次数超过预设次数的情况下，将通信异常事件报告给处理机制。

根据结合本公开第一方面的实施例，通信异常事件是服务失败事件。

根据结合本公开第一方面的实施例，处理机制是重试机制，其中，与服务失败事件对应的重试动作被触发以使UE成功具有通信服务。

根据结合本公开第一方面的实施例，通信异常事件是不良服务质量(quality ofservice，QoS)事件。

根据结合本公开第一方面的实施例，处理机制是恢复机制，其中，与低QoS事件对应的恢复动作被触发以使UE返回正常QoS状态。

根据第二方面，提供了一种UE。该UE包括检测器、异常处理器、以及预防控制器。检测器用于检测通信异常事件并将通信异常事件与该通信异常事件的属性信息一起报告给异常处理器；异常处理器用于处理通信异常事件，并在满足预设条件时将属性信息报告给预防控制器；预防控制器用于触发预防动作以预防再次发生通信异常事件。

根据结合本公开第二方面的实施例，检测器还用于：根据通信异常事件和事件ID之间的对应关系，确定与上述通信异常事件对应的事件ID，其中，每个通信异常事件具有唯一的事件ID。用于将通信异常事件报告给异常处理器的检测器用于：将事件ID报告给异常处理器。

根据结合本公开第二方面的实施例，用于处理通信异常事件的异常处理器用于：根据事件ID和动作之间的对应关系，确定与上述事件ID对应的动作；触发该动作以处理通信异常事件。

根据结合本公开第二方面的实施例，预设条件为：异常处理器未能处理通信异常事件，并且该通信异常事件在预设时段内发生了超过预设次数。

根据结合本公开第二方面的实施例，预设条件为：在预设时段内，异常处理器未能处理通信异常事件。

根据结合本公开第二方面的实施例，预设条件为：在预设次数的尝试后，异常处理器未能处理通信异常事件。

根据结合本公开第二方面的实施例，预设条件为：在预设时段内尝试预设次数后，异常处理器未能处理通信异常事件。

根据结合本公开第二方面的实施例，属性信息包括小区相关信息。

根据结合本公开第二方面的实施例，小区相关信息包括以下至少之一：小区ID、当前使用的无线接入技术(RAT)、当前通信的公共陆地移动网(PLMN)。

根据结合本公开第二方面的实施例，预防控制器用于触发以下预防动作中的至少一个：将小区ID添加到低优先级小区列表或黑名单、暂时禁用当前使用的RAT、以及暂时禁用当前通信的PLMN。

根据结合本公开第二方面的实施例，当定时器到期或当与小区相关信息有关的位置改变时，解除上述动作。

根据结合本公开第二方面的实施例，属性信息还包括通信异常事件的时间信息和位置信息中的至少一个。

根据结合本公开第二方面的实施例，用于将通信异常事件报告给异常处理器的检测器用于：在通信异常事件持续了预设时间段的情况下，将通信异常事件报告给异常处理器。

根据结合本公开第二方面的实施例，用于将通信异常事件报告给异常处理器的检测器用于：在通信异常事件发生的次数超过预设次数的情况下，将通信异常事件报告给异常处理器。

根据结合本公开第二方面的实施例，通信异常事件是服务失败事件。

根据结合本公开第二方面的实施例，异常处理器用于采用重试机制来处理服务失败事件，在重试机制中，与服务失败事件对应的重试动作被触发以使UE成功具有通信服务。

根据结合本公开第二方面的实施例，通信异常事件是不良服务质量(QoS)事件。

根据结合本公开第二方面的实施例，异常处理器用于采用恢复机制来处理低QoS事件，在恢复机制中，与低QoS事件对应的恢复动作被触发以使UE返回正常QoS状态。

根据结合本公开第二方面的实施例，检测器、异常处理器、以及预防控制器集成在UE的调制解调器中。

根据结合本公开第二方面的实施例，检测器、异常处理器、以及预防控制器集成在UE的应用处理器(application processor，AP)中。

根据结合本公开第二方面的实施例，检测器设置在UE的调制解调器中，异常处理器和预防控制器集成在UE的AP中。

根据本公开的第三方面，提供了一种UE。该UE包括至少一个处理器以及存储器，该存储器用于存储计算机可读程序，当由至少一个处理器执行时，该计算机可读程序可操作使处理器执行第一方面的方法。

根据本公开的第四方面，提供了一种计算机可读存储介质。该计算机可读存储介质存储有计算机程序，当由处理器执行时，该计算机程序使处理器执行第一方面的方法。

附图说明

为了更清楚地说明本公开或相关技术的实施例，简要介绍将在实施例中描述的以下附图。显然，附图仅是本公开的一些实施例，本领域普通技术人员可以在不付出任何前提下，根据这些附图获得其他附图。

图1为用户设备(UE)的结构示意图。

图2为根据实施例的异常检测和恢复框架。

图3为根据实施例的UE的结构示意图。

图4为根据实施例的用于处理UE的通信异常的方法的流程示意图。

具体实施方式

下面结合附图对本公开实施例的技术内容、结构特征、达到的目的和效果进行详细说明。具体地，本公开实施例中的术语仅用于说明一些实施例的目的，并不用于限制本发明。

在与网络或外部设备通信时，UE会遇到各种问题，这些问题影响了通信功能。上述问题的示例包括但不限于：(i)UE处于空闲模式：无服务(out of service，OOS)、有限服务(limited service)、频繁的服务丢失等。(ii)互联网相关：互联网访问不可用、低吞吐量等。(iii)呼叫相关：无法呼叫、无法接收呼叫、或无法发送SMS等。

通常，发现异常情况的用户几乎没有可以摆脱或从此类异常情况中恢复的选择。用户可以(i)重新进行服务尝试，看异常情况是否可以恢复：很多情况下不会成功；(ii)等待一段时间后重试：很多情况下不会成功；(iii)尝试进行一些恢复，比如先开启飞行模式再关闭飞行模式：这个操作对用户来说不是很熟悉，并且在某些情况下可能不起作用；(iv)重置设备：重置过程中，终端设备不可用，可能会影响用户的使用。

可见，上面给出的选项不能有效和彻底地解决问题。所有的选项都需要用户参与，成功率低，耗时长。综上所述，需要提供一种新的UE通信异常处理方案，其无需用户参与并且能够有效处理UE侧的通信异常。

根据本公开实施例，提供了一种用于处理UE的通信异常的方案。具体地，提供了一种用于处理UE的通信异常的方法以及用于执行该方法的UE。使用本文提供的技术方案，可以自动检测和处理异常情况，并且还可以避免再次发生类似问题。

如本文所使用的，术语“UE”指的是具有与网络通信的能力的电子设备。术语“通信”指的是数据、信息、或消息的发送、接收、或交换。电子设备可以包括各种手持设备、车载设备、可穿戴设备、计算设备或其他具有无线通信功能的设备、连接到无线调制解调器的其他处理设备，以及移动台(mobile station，MS)、手机、个人数字助理(personal digitalassistant，PDA)、终端设备和其他手持通信设备。

图1是示例性UE的结构示意图。如图1所示，UE 10包括用户处理器(applicationprocessor，AP)12、调制解调器14、以及至少一个用户接口(user interface，UI)16。AP 12支持所有与UI相关的工作和运行在UE上的操作系统18。操作系统18可以是高级操作系统(high level operating system，HLOS)，例如Android/IOS。调制解调器14是与网络通信的后端，即UE通过调制解调器与网络通信。

UE还包括用于存储数据或指令的存储器11。如下详述，数据可以是对应关系、事件相关数据、动作相关数据、存储在数据库中的其他数据等。AP 12可以调用存储在存储器中的指令来实现某些功能，例如异常检测和恢复。

UE还可以包括发射器13和接收器15。发射器13用于向网络发送数据。接收器15用于从网络接收数据。发射器13和接收器15可以集成到收发器。如本文所用，术语“数据”可以是文本、语音、视频、图像、代码、信号、信令等。

AP 12、调制解调器14、UI 16、存储器11、发射器13和接收器15可以通过总线相互耦合和通信。

图2是根据实施例的异常检测和恢复框架。

用于处理UE的通信异常的整个方案(框架)包括监测机制、处理机制、以及预防机制。如图2所示，监测机制用于检测通信异常事件，包括：(i)服务失败事件的异常监控(检测错误或异常情况)；(ii)低QoS事件的QoS监测(检测低QoS)。处理机制用于处理通信异常事件，包括：(1)重试机制(使得服务能够成功)；(2)恢复机制(回到正常状态)。预防机制被触发以避免该情况再次发生。

通过本文提供的框架，在某些场景下，可以在用户注意到之前自动检测异常情况，并实现智能重试和分级恢复，使UE能够以最低成本静默恢复。此外，对于某些与网络相关的问题(如故障小区)，所提框架将允许UE通过例如降低这些小区的优先级或将来不驻留在这些小区来避免类似问题再次发生。由此，上述机制将共同实现异常检测、重试/恢复到正常状态、以及异常预防。

如图2所示，本文提供的技术方案处理的服务类别至少涉及：(i)紧急呼叫(emergency call，E-Call)和正常呼叫(normal call，N-Call)等呼叫/短消息服务(shortmessage service，SMS)/补充服务(supplemental service，Sup)如呼叫转移/呼叫等待等；(ii)数据、游戏、视频等互联网服务；(iii)驻留/注册(registration，Reg)，例如OOS和其他服务。下面将参考图2详细说明每个服务类别的异常检测和恢复。

呼叫/SMS/Sup

如图2所示，关于呼叫/SMS/Sup，服务失败事件包括但不限于：呼叫建立失败/丢失、SMS失败、以及Sup失败。检测到的低QoS事件例如涉及语音质量差。

互联网

如图2所示，关于互联网，服务失败事件包括数据包切换(packet switch，PS)呼叫建立失败/丢失。检测到的低QoS事件可以是低速、高延时/丢失等。

驻留/Reg

如图2所示，关于驻留/Reg，当不存在正常服务时，可以确定存在服务失败事件，当存在频繁的服务丢失或拒绝时，可以确定发生了低QoS事件。

为了处理检测到的服务失败事件，将触发重试机制。类似地，为了处理检测到的低QoS事件，将触发恢复机制。在实施例中，如从图2底部可见，处理机制还可以根据处理结果触发预防机制。

监测机制、处理机制和预防机制中的每一个都可以通过软件、硬件或者软硬件组合来实现。在一个实施例中，监测机制、处理机制和预防机制可以在调制解调器14处实现。在另一实施例中，监测机制、处理机制和预防机制可以在AP 12处实现。在又一实施例中，监测机制可以在调制解调器14处实现，而处理机制和预防机制可以在AP 12处实现。

作为一个示例，监测机制被集成到图1所示的AP 12中，在这种情况下，通信异常监测或检测由AP完成。然而，当由AP 12执行监测时，从发生通信异常事件到AP 12实际检测到通信异常事件之间可能存在延迟。另一方面，由于手机中使用来自不同制造商的芯片，考虑到不同芯片的兼容性和适配性，相比在调制解调器14进行监测，在AP 12执行监测更有利于UE及其系统的维护。

为解决上述延迟问题，可将监测机制集成至调制解调器14，以使调制解调器14检测通讯异常。与AP 12相比，调制解调器14可以更快速地响应通信异常事件，并且可以获取更多的事件相关数据，但是调制解调器14与AP 12相比功能简单，存储空间有限，因此调制解调器14难以存储大量信息。

对于诸如重试机制的处理机制，可以将其集成到调制解调器14中。由于调制解调器14本身具有重试机制，因此将重试机制集成到调制解调器14中可以节省成本并且设计简单。另一方面，如果在AP 12处实施重试机制，则可以提高重试的自由度和灵活性。例如，在语音呼叫建立失败(如表3所示的0x00003)的情况下，当UE中安装了多个SIM卡时，如果重试机制由AP 12触发，则AP 12可以向调制解调器14发送重试请求以及用来进行重拨的SIM卡的ID。用于重拨的SIM卡可以与先前失败的语音呼叫所使用的SIM卡相同或不同。但是，仍然以上述情况为例，如果重试机制由调制解调器14触发，则调制解调器14将使用与先前失败的语音呼叫完全相同的SIM卡重新拨号，这可能导致重拨的成功率低。

综上所述，可以根据所要达到的效果来确定监测机制、处理机制和预防机制是在AP 12还是在调制解调器14处实现，在此不做限定。显然，监测机制、处理机制和预防机制的部分或全部也可以在UE的其他合适的硬件组件上实现。

基于图2的框架，提供了一种UE。图3示出了该UE的示意框图。如图3所示，UE 30包括检测器31、异常处理器33、以及预防控制器35。检测器31与异常处理器33耦合，用于检测通信异常事件并将通信异常事件与通信异常事件的属性信息一起上报给异常处理器33。异常处理器33与预防控制器35耦合，用于处理通信异常事件，并在满足预设条件时，将属性信息上报给预防控制器35。这里所说的“预设条件”是：异常处理器33未能处理通信异常事件，并且通信异常事件在预设时段内发生的次数超过预设次数。预防控制器35用于触发预防动作以预防通信异常事件再次发生。

检测器31是图2的监测机制的硬件实现，可以集成到图1的AP 12或调制解调器14中。异常处理器33是图2的处理机制的硬件实现，可以集成到图1的AP 12或调制解调器14中。类似地，预防控制器35是预防机制的硬件实现，可以集成到图1的AP 12或调制解调器14中。或者，检测器31、异常处理器33和预防控制器35可以分开设置，并且通过例如总线相互连接。例如，检测器31集成到图1的调制解调器14中，异常处理器和预防控制器集成到图1的AP 12中。

检测器31还用于：根据通信异常事件与事件ID之间的对应关系，确定通信异常事件对应的事件ID，其中，每个通信异常事件具有唯一的事件ID。当确定通信异常事件的事件ID时，检测器31可以将事件ID报告给异常处理器。相应地，当异常处理器33接收到事件ID时，异常处理器33根据事件ID与动作之间的对应关系确定事件ID对应的动作，并触发所确定的动作以处理通信异常事件。

这里所说的“属性信息”包括小区相关信息。“小区相关信息”又包括以下至少一项：小区ID、当前使用的无线接入技术(radio access technology，RAT)、当前通信的公共陆地移动网络(public land mobile network，PLMN)等。

预防控制器35用于触发以下预防动作中的至少一种：将小区ID加入低优先级小区列表或黑名单、暂时禁用当前使用的RAT、暂时禁用当前通信的PLMN。当与预防动作对应的定时器到期或与小区相关信息有关的位置改变时，解除该预防动作。

在一个实施例中，属性信息还可以包括通信异常事件的时间信息和位置信息中的至少一个。

检测器31用于在通信异常事件持续了预设时间段的情况下，将通信异常事件上报给异常处理器33。替代地或附加地，检测器31用于在通信异常事件发生的次数超过预设次数的情况下，将通信异常事件上报给异常处理器33。

通信异常事件包括服务失败事件和低QoS事件。当检测器31报告的通信异常事件为服务失败事件时，异常处理器33用于采用重试机制处理服务失败事件，在重试机制中，与服务失败事件对应的重试动作被触发，以使UE成功进行通信服务。当检测器31报告的通信异常事件为低QoS事件时，异常处理器33用于采用恢复机制处理低QoS事件，在恢复机制中，与低QoS事件对应的恢复动作被触发，以使UE回到正常的QoS状态。

检测器31、异常处理器33、和预防控制器35可以共用一个存储器，也可以分别具有用于存储数据的存储器，数据例如是事件与事件ID之间的对应关系，事件、事件ID、重试/恢复动作之间的对应关系或事件ID与重试/恢复动作之间的对应关系，以及其他预防动作相关的数据。

基于图2的框架，提供了一种用于处理UE的通信异常的方法。该方法可以由图3所述的UE执行。作为另一选择，该方法可以在图1所示的UE中实现。图4是示出用于处理通信异常的方法的流程图。

如图4所述，该方法包括以下操作。

在401，UE的监测机制检测通信异常事件。监测机制可以实现为图3的检测器31。

在403，监测机制将通信异常事件以及通信异常事件的属性信息一起报告给处理机制。例如，监测机制可以向处理机制发送请求或指令，响应于接收到的请求或指令，处理机制可以确定并触发对应动作，以处理通信异常事件。属性信息包括小区相关信息。小区相关信息包括以下至少之一：小区ID、当前使用的无线接入技术(RAT)、当前通信的公共陆地移动网(PLMN)。

在405，处理机制处理通信异常事件。处理机制可以实现为图3的异常处理器33。

在407，当满足预设条件时，处理机制将属性信息报告给预防机制，以预防通信异常事件再次发生。在预防机制下，特定预防动作被触发，以预防同一事件再次发生。预防机制可以实现为图3的预防控制器35。

在一个实施例中，属性信息还可以包括通信异常事件的时间信息和位置信息中的至少一个。借助通信异常事件的时间信息和/或位置信息，预防机制可以确定UE的时间或位置变化，进而确定是否要解除已触发的预防动作。

监测机制包括异常监测(也称为服务失败监测)以及QoS监测(也称为低QoS监测)。通信异常事件至少包括服务失败事件和低QoS事件。

异常监测用于检测每个服务类别的异常情况。QoS监测用于检测每个服务类别中的QoS降级。异常监测将为重试机制提供指示，QoS监测将为恢复机制提供指示。

在实施例中，预先维护事件与事件ID之间的对应关系，其中每个事件具有唯一的ID。上述方法还包括：根据通信异常事件与事件ID之间的对应关系，确定通信异常事件对应的事件ID，每个通信异常事件具有唯一的事件ID。这里引入了事件ID，在403向处理机制报告通信异常事件时，可以报告事件ID。

关于在403的报告，该报告可以按预设规则进行。预设规则可以与时间、计数器、或阈值相关。例如，可以在通信异常事件持续了预设时间段的情况下将通信异常事件报告给处理机制。又例如，可以在通信异常事件发生的次数超过预设次数的情况下将通信异常事件报告给处理机制。

基于以上，下面将分别针对服务失败事件和低QoS事件详细描述涉及通信异常事件监测和报告的在401和403的操作。

针对服务失败事件的异常监测

如下表1，通过一些示例定义了与UE异常服务相关的关键事件表。

	事件ID	异常事件(服务失败事件)名称
			1	0x00001	小区服务丢失(无信号)
2	0x00002	无法获得正常服务(网络注册失败/被拒绝)
			3	0x00003	语音呼叫建立失败
4	0x00004	数据呼叫建立失败
			5	0x00005	语音呼叫丢弃
6	0x00006	数据呼叫丢弃
			7	0x00007	SMS(文本)发送失败
8	0x00008	补充服务失败

表1

UE(具体地，设置在图1的AP 12或调制解调器14的监测机制)应能够检测上述定义的事件，并将事件转换为事件ID以报告给处理机制进行处理。在一个实施例中，UE将检测到的事件转换为事件ID以及属性信息，例如时间/位置/网络/RAT(GSM/WCDMA/LTE等)。时间/位置/网络/RAT(GSM/WCDMA/LTE等)是事件的属性信息。

例如，如果UE调制解调器在14:25:30检测到有限服务的事件，UE可以将其转换为事件ID 0x0002与驻留PLMN/Cell ID。类似地，如果调制解调器报告语音呼叫建立失败事件，UE可以将其转换为事件ID 0x0003。

服务失败事件报告的规则(时间/计数器/阈值)

可选地，如上所述，可以为事件定义有关如何/何时将事件报告给重试机制的某些规则。规则可以基于时间或计数器。所有定义的事件可以遵循相同的规则，或者每个事件可以具有特定的规则。例如，数据呼叫服务可能具有与语音呼叫服务不同的规则。

时间：超过指定时间后，如果服务失败事件相关异常情况仍然存在，则报告；否则，如果没有定义其他条件，立即报告。

计数器/阈值：每次检测到服务失败事件，增加事件的计数器，如果计数器的值等于或大于事件对应的阈值，则报告服务失败事件。否则，如果没有定义其他条件，则每次检测到事件时报告服务失败事件。

例如，阈值可以设置为5、10或任何其他合适的值。每次检测到服务失败事件时，该事件的计数器加1，其中，计数器初始值为0。如果阈值为5，则仅当服务失败事件发生5次时才报告，即当计数器的值达到5时进行报告。

时间和计数器/阈值：每次检测到服务失败事件，增加该事件的计数器，如果计数器的值在预设时间段内达到事件对应的阈值，则上报服务失败事件。否则，如果没有定义其他条件，则每次检测到服务失败事件时报告该事件。

因此，报告考虑了事件的随机性。例如，由于UE的移动性，当UE移出小区覆盖范围时，可能会发生业务失败事件。但是，在UE移回小区覆盖范围后，服务失败事件会立即消失。在这种情况下，不需要在第一次发生服务失败事件时上报，可以忽略这种瞬时服务失败事件。但是，如果服务失败事件持续时间较长或多次发生，则表明该服务失败事件并非偶然事件，需要上报处理。

针对低QoS事件的QoS监测

与UE QoS相关的关键事件表可以通过一些示例如下定义。

	事件ID	低(不良)QoS事件名称
			1	0x10001	CS语音呼叫质量差
2	0x10002	PS语音呼叫质量差
			3	0x10003	数据呼叫吞吐量低
4	0x10004	数据呼叫时延长
			5	0x10005	数据呼叫抖动大
6	0x10006	频繁服务丢失
			7	0x10007	频繁网络扫描

表2

UE可以为每个主要服务定义一个QoS规则列表，并使用该列表来触发低QoS事件。这里所指的主要服务包括但不限于CS语音呼叫、PS语音呼叫、数据呼叫吞吐量/延迟/抖动、服务丢失频率、网络扫描频率等。

例如，一条规则规定，如果数据呼叫吞吐量小于x Kb/s，UE可以判定低QoS事件。“x”可以是固定值，也可以是基于UE所使用的无线接入技术(RAT)的值(如对于2G，“x”可能较小，对于LTE，“x”将是较大的值)。如果UE检测到数据吞吐量低于x KB/s，根据表2，UE可以触发事件ID 0x10003对应的QoS事件。

低QoS事件报告的规则(时间/计数器/阈值)

类似于服务失败事件报告，可以基于时间和/或计数器/阈值，为低QoS事件定义关于如何/何时将事件报告给恢复机制的某些规则。

时间：在超过指定时间后，如果仍然存在低QoS事件，则报告该事件，否则如果没有定义其他条件，则立即报告该事件。

计数器/阈值：每次触发低QoS事件时，增加其计数器。如果计数器的值等于或大于低QoS事件对应的阈值，则报告低QoS事件。否则，如果没有定义其他条件，则在每次检测到低QoS事件时报告该事件。

时间和计数器/阈值：每次检测到低QoS事件时，增加该事件的计数器，如果计数器的值在预设时间段内达到事件对应的阈值，则报告服务失败事件。否则，如果没有定义其他条件，则每次检测到服务失败事件时报告该事件。

在405，调用处理机制以处理通信异常事件。对应于通信异常事件包括服务失败事件和低QoS事件，处理机制包括用于处理服务失败事件的重试机制和用于处理低QoS事件的恢复机制。

如上所述，服务失败事件的异常监测机制向重试机制提供指示，低QoS事件的QoS监测机制向恢复机制提供指示。在处理机制接收到这样的指示后，重试机制会提供动作以重试与服务失败事件相关的服务，例如呼叫请求；恢复机制会恢复正在进行的服务，例如从不良质量恢复到正常或良好质量。具体地，在重试机制下，触发服务失败事件对应的重试动作，以使UE成功具有通信服务。在恢复机制下，触发低QoS事件对应的恢复动作，以使UE回到正常QoS状态。

动作的触发可以如下实现。可以预先设置事件ID和动作之间的对应关系。然后根据从监测机制接收到的事件ID，根据事件ID与动作之间的对应关系，可以确定该事件ID对应的动作，然后触发这样确定的动作来处理通信异常事件。

在407，当满足预设条件时，处理机制将向预防机制报告通信异常事件的属性信息。例如，预设条件可以定义为处理机制未能处理通信异常事件，并且通信异常事件在预设时间段内发生的次数超过预设次数。具体地，当重试机制未能处理服务失败事件，或恢复机制未能处理低QoS事件，并且服务失败事件或低QoS事件在一段时间内发生超过阈值次数时，失败的结果将被提供给预防机制。响应于从处理机制收到的失败结果，预防机制将在需要时采取动作以防止问题再次发生。

下面分别详细介绍重试机制、恢复机制和预防机制。

重试机制

UE可以具有针对每一个服务失败异常事件(具体来说，针对每一个服务失败事件)的重试动作表，定义如下表3为例：

表3

根据从异常监测机制接收到的服务失败事件的事件ID，UE会发起相应的动作进行重试。

例如，如果接收到事件0x00003(对应于语音呼叫建立失败)，UE会触发重拨，看能否成功。因此，UE不会立即向用户报告语音呼叫建立失败，相反，UE会先重试。

如果重试结果仍然是失败并且满足一定的规则，UE可以将诸如小区相关信息(小区ID/RAT/PLMN等)的事件属性信息发送给预防机制进行进一步处理。特定规则是基于定时器和计数器的，例如，特定规则是在一个时间段内重试失败超过阈值次数。或者，特定规则是基于计数器的，特定规则可以是重试失败超过阈值次数。特定规则还可以是基于定时器的，该特定规则可以是重试持续了预设时间段但仍然没有成功。从另一个角度来说，如果每次发生服务失败事件都上报，那么特定规则可以是重试失败并且服务失败事件已经发生超过预设次数。

恢复机制

UE可以具有针对每个QoS事件的恢复动作表，定义如下表4为例：

表4

基于从QoS监测机制接收到的低QoS事件的事件ID，UE会发起相应的动作进行恢复。

例如，如果接收到事件0x10001(对应于CS语音呼叫质量差)，基于呼叫类型(紧急呼叫或正常呼叫)，UE会触发相关动作，看是否可以恢复呼叫。

如果恢复结果为“失败”并且满足一定的规则，UE可以将诸如小区相关信息(小区ID/RAT/PLMN等)的事件属性信息发送给预防机制进行进一步处理。特定规则是基于定时器和计数器的，例如，特定规则是在一个时间段内恢复失败超过阈值次数。或者，特定规则是基于计数器的，该特定规则可以是恢复失败超过阈值次数。特定规则还可以是基于定时器的，该特定规则可以是恢复持续预设时间段但仍未成功。如果每次发生低QoS事件都上报，则特定规则可以是恢复失败并且低QoS事件已经发生超过预设次数。

预防机制

预防机制可以被设计用于防止发生重复性失败或服务降级。

在服务失败事件或低QoS事件由监测机制检测到并由处理机制处理后，如前所述，根据特定逻辑，UE可以决定触发预防机制。该特定逻辑可以是，如果接收到的关于小区/RAT的事件量比较大，例如大于预设数量，则可以将小区/RAT降级或者加入黑名单；如果与IMS服务相关的问题频繁出现，则可以暂时关闭IMS服务。

在预防机制下，至少触发以下动作之一：将小区ID加入低优先级小区列表或黑名单，例如低优先级小区/黑名单小区数据库；暂时禁用相关的RAT，例如当前使用的RAT；暂时禁用相关功能(feature)，例如当前通信的PLMN。

预防动作的管理可以基于定时器/位置。一旦满足基于计时器/位置的特定条件，就可以解除预防动作。例如，当一个预防动作被触发时，将启动该预防动作对应的定时器，并在该定时器到期时解除该预防动作。或者，预防动作可以是基于位置的。在这种情况下，如果UE不在问题区域内，则将重置预防动作。例如，通过接收到的通信异常事件的属性信息(如UE的位置、小区ID等)，预防机制可以知道UE的位置。当UE的位置发生变化时，即与小区相关信息相关的位置发生变化时，近期内可能不会再次发生通信异常事件，因此可以解除预防动作。

预防动作管理可以通过数据库来实现。例如，UE可以有几个新的数据库来存储预防动作相关的数据，见下例：

表5

在以上给出的表5中，提供了四个数据库，每个数据库对应不同的预防策略。在名为“低优先级小区”的数据库中，PLMN/小区ID/RAT的优先级会被降低，因此，UE重新选择与PLMN/小区ID/RAT相关的小区的几率会降低；因此，可以防止异常事件再次发生。

UE将在小区选择/重选和功能/RAT启用期间检查上述数据，以查看是否应该继续或删除限制。

根据实施例，提供了一种UE。该UE包括至少一个处理器和存储器，存储器用于存储计算机可读程序，当由至少一个处理器执行时，该计算机可读程序可操作以使处理器执行图4的用于处理通信异常的方法。至少一个处理器可以是图1的应用处理器(AP)12，存储器可以是图1的存储器11。存储器用于加载和存储例如用于机制的数据和/或指令。存储器可以包括合适的易失性存储器(例如动态随机存取存储器(dynamic random access memory，DRAM))和/或非易失性存储器(例如闪存)的任何组合。

根据实施例，提供了一种计算机可读存储介质。计算机可读存储介质存储有计算机程序，当该计算机程序被处理器执行时，使处理器执行图4的用于处理通信异常的方法。

本领域普通技术人员可以理解，本发明实施例中描述和公开的各个机制、算法和步骤都是通过电子硬件或者计算机软件与电子硬件的组合来实现的。功能是在硬件中运行还是在软件中运行取决于应用条件和技术方案的设计要求。

本领域普通技术人员可以使用不同的方式来实现针对每个具体应用的功能，但这样的实现不应超出本公开的范围。本领域普通技术人员可以理解，对于本发明的完整理解，可以参考上述实施例中的UE、机制、部件的工作过程。为了便于描述和简化，这些工作过程将不再重复。

可以理解的是，本发明实施例所公开的机制、装置和方法可以通过其他方式实现。上述实施例仅是示例性的。检测器、异常处理器、预防控制器等部件的划分只是基于逻辑功能，其他的划分存在于实现中。可以将多个组件组合或集成在另一个系统中。也可以省略或跳过某些特征。另一方面，显示或讨论的相互耦合、直接耦合或通信耦合通过一些端口、设备或单元间接地或通过电气、机械或其他种类的形式实现。

Claims (41)

1.一种用于处理用户设备(UE)的通信异常的方法，包括：

所述UE的监测机制检测通信异常事件；

将所述通信异常事件与所述通信异常事件的属性信息一起报告给处理机制；

所述处理机制处理所述通信异常事件；以及

当满足预设条件时，所述处理机制将所述属性信息报告给预防机制，以预防再次发生所述通信异常事件。

2.根据权利要求1所述的方法，还包括：

根据通信异常事件和事件ID之间的对应关系，确定与所述通信异常事件对应的事件ID，其中，每个通信异常事件具有唯一的事件ID；

其中，将所述通信异常事件报告给所述处理机制包括：

将所述事件ID报告给所述处理机制。

3.根据权利要求1所述的方法，其中，所述处理机制处理所述通信异常事件包括：

根据事件ID和动作之间的对应关系，确定与所述事件ID对应的动作；以及

触发所述动作以处理所述通信异常事件。

4.根据权利要求1所述的方法，其中，所述预设条件为：

所述处理机制未能处理所述通信异常事件，并且所述通信异常事件在预设时段内发生的次数超过预设次数。

5.根据权利要求1所述的方法，其中，所述预设条件为：

在预设时段内，所述处理机制未能处理所述通信异常事件。

6.根据权利要求1所述的方法，其中，所述预设条件为：

在预设次数的尝试后，所述处理机制未能处理所述通信异常事件。

7.根据权利要求1所述的方法，其中，所述预设条件为：

在预设时段内尝试预设次数后，所述处理机制未能处理所述通信异常事件。

8.根据权利要求1所述的方法，其中，所述属性信息包括小区相关信息。

9.根据权利要求8所述的方法，其中，所述小区相关信息包括以下至少之一：小区ID、当前使用的无线接入技术(RAT)、当前通信的公共陆地移动网(PLMN)。

10.根据权利要求9所述的方法，其中，在所述预防机制中，以下动作中的至少一个被触发：

将所述小区ID添加到低优先级小区列表或黑名单、暂时禁用所述当前使用的RAT、以及暂时禁用所述当前通信的PLMN。

11.根据权利要求10所述的方法，其中，在所述预防机制中，当定时器到期或当与所述小区相关信息有关的位置改变时，解除所述动作。

12.根据权利要求8所述的方法，其中，所述属性信息还包括所述通信异常事件的时间信息和位置信息中的至少一个。

13.根据权利要求1至12中任一项所述的方法，其中，将所述通信异常事件报告给所述处理机制包括：

在所述通信异常事件持续了预设时间段的情况下，将所述通信异常事件报告给所述处理机制。

14.根据权利要求1至12中任一项所述的方法，其中，将所述通信异常事件报告给所述处理机制包括：

在所述通信异常事件发生的次数超过预设次数的情况下，将所述通信异常事件报告给所述处理机制。

15.根据权利要求1至12中任一项所述的方法，其中，所述通信异常事件是服务失败事件。

16.根据权利要求15所述的方法，其中，所述处理机制是重试机制，其中，与所述服务失败事件对应的重试动作被触发以使所述UE成功具有通信服务。

17.根据权利要求1至12中任一项所述的方法，其中，所述通信异常事件是不良服务质量(QoS)事件。

18.根据权利要求17所述的方法，其中，所述处理机制是恢复机制，其中，与所述低QoS事件对应的恢复动作被触发以使所述UE返回正常QoS状态。

19.一种用户设备(UE)，包括检测器、异常处理器、以及预防控制器，其中

所述检测器用于检测通信异常事件并将所述通信异常事件与所述通信异常事件的属性信息一起报告给所述异常处理器；

所述异常处理器用于处理所述通信异常事件，并在满足预设条件时将所述属性信息报告给所述预防控制器；以及

所述预防控制器用于触发预防动作以预防再次发生所述通信异常事件。

20.根据权利要求19所述的UE，其中，所述检测器还用于：

根据通信异常事件和事件ID之间的对应关系，确定与所述通信异常事件对应的事件ID，其中，每个通信异常事件具有唯一的事件ID；

其中，用于将所述通信异常事件报告给所述异常处理器的所述检测器用于：

将所述事件ID报告给所述异常处理器。

21.根据权利要求19所述的UE，其中，用于处理所述通信异常事件的所述异常处理器用于：

根据事件ID和动作之间的对应关系，确定与所述事件ID对应的动作；以及

触发所述动作以处理所述通信异常事件。

22.根据权利要求19所述的UE，其中，所述预设条件为：

所述异常处理器未能处理所述通信异常事件，并且所述通信异常事件在预设时段内发生的次数超过预设次数。

23.根据权利要求19所述的UE，其中，所述预设条件为：

在预设时段内，所述异常处理器未能处理所述通信异常事件。

24.根据权利要求19所述的UE，其中，所述预设条件为：

在预设次数的尝试后，所述异常处理器未能处理所述通信异常事件。

25.根据权利要求19所述的UE，其中，所述预设条件为：

在预设时段内尝试预设次数，所述异常处理器未能处理所述通信异常事件。

26.根据权利要求19所述的UE，其中，所述属性信息包括小区相关信息。

27.根据权利要求26所述的UE，其中，所述小区相关信息包括以下至少之一：小区ID、当前使用的无线接入技术(RAT)、当前通信的公共陆地移动网(PLMN)。

28.根据权利要求27所述的UE，其中，所述预防控制器用于触发以下预防动作中的至少一个：

将所述小区ID添加到低优先级小区列表或黑名单、暂时禁用所述当前使用的RAT、以及暂时禁用所述当前通信的PLMN。

29.根据权利要求28所述的UE，其中，当定时器到期或当与所述小区相关信息有关的位置改变时，解除所述动作。

30.根据权利要求26所述的UE，其中，所述属性信息还包括所述通信异常事件的时间信息和位置信息中的至少一个。

31.根据权利要求19至30中任一项所述的UE，其中，用于将所述通信异常事件报告给所述异常处理器的所述检测器用于：

在所述通信异常事件持续了预设时间段的情况下，将所述通信异常事件报告给所述异常处理器。

32.根据权利要求19至30中任一项所述的UE，其中，用于将所述通信异常事件报告给所述异常处理器的所述检测器用于：

在所述通信异常事件发生的次数超过预设次数的情况下，将所述通信异常事件报告给所述异常处理器。

33.根据权利要求19至30中任一项所述的UE，其中，所述通信异常事件是服务失败事件。

34.根据权利要求33所述的UE，其中，所述异常处理器用于采用重试机制来处理所述服务失败事件，在所述重试机制中，与所述服务失败事件对应的重试动作被触发以使所述UE成功具有通信服务。

35.根据权利要求19至30中任一项所述的UE，其中，所述通信异常事件是不良服务质量(QoS)事件。

36.根据权利要求35所述的UE，其中，所述异常处理器用于采用恢复机制来处理所述低QoS事件，在所述恢复机制中，与所述低QoS事件对应的恢复动作被触发以使所述UE返回正常QoS状态。

37.根据权利要求19至36中任一项所述的UE，其中，所述检测器、所述异常处理器、以及所述预防控制器集成在所述UE的调制解调器中。

38.根据权利要求19至36中任一项所述的UE，其中，所述检测器、所述异常处理器、以及所述预防控制器集成在所述UE的应用处理器(AP)中。

39.根据权利要求19至36中任一项所述的UE，其中，所述检测器设置在所述UE的调制解调器中，所述异常处理器和所述预防控制器集成在所述UE的AP中。

40.一种用户设备(UE)，包括：

至少一个处理器；以及

存储器，用于存储计算机可读程序，当由所述至少一个处理器执行时，所述计算机可读程序可操作使所述至少一个处理器执行根据权利要求1至18中任一项所述的方法。

41.一种计算机可读存储介质，存储有计算器程序，当由处理器执行时，所述计算机程序使所述处理器执行根据权利要求1至18中任一项所述的方法。

Images