CN103068044A - 一种寻呼方法和*** - Google Patents

Abstract

本发明实施例提供了一种寻呼方法和***，以解决由于MME向TA list中的所有基站发送寻呼请求，而占用较多的寻呼资源，降低网络的性能的问题。其中，方法包括：接收下行业务信令，通过所述下行业务信令解析出目标用户设备的标识；从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区，并向所述N个跟踪区内的基站发送寻呼请求，其中，N为正整数；判断在预设的第一时间内是否接收到所述目标用户设备的寻呼响应；如果接收到所述寻呼响应，则确定本次寻呼成功；如果没有接收到所述寻呼响应，则分别向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求。本发明实施例能够有效节约寻呼资源，减少寻呼请求的数量，降低对网络性能的影响。

Description

一种寻呼方法和***

技术领域

本发明实施例涉及通信技术领域，特别是涉及一种寻呼方法和***。

背景技术

在3G***中，由于不再有电路区和分组区的区分，所以在用户的位置管理上也不采取位置区(LA)和路由区(RA)的登记方法，而是统一采用跟踪区(Track Area，TA)，通过给用户分配相应的标识进行位置管理，一个跟踪区通常由多个基站或小区组成。

移动性管理实体(Mobility Management Entity，MME)是第三代合作伙伴计划(3GPP)协议长期演进(Long Term Evolution，LTE)接入网络的关键控制节点，它负责空闲模式的用户设备(User Equipment，UE)的定位、传呼过程，包括中继。

MME保存UE经过的跟踪区，组成跟踪区列表(TA list)，当MME接收到下行数据传输或网络侧触发的信令时，MME会向所有处于TA list中的基站发送寻呼请求，从而对UE进行寻呼。

但是，上述方法中MME需要向TA list中的所有基站发送寻呼请求，如果TA list较大，或者TA list中的基站数目较多，则下行业务会频繁触发寻呼请求，此时会占用较多的寻呼资源，降低网络的性能。

发明内容

本发明实施例所要解决的技术问题是提供一种寻呼方法和***，以解决由于MME向TA list中的所有基站发送寻呼请求，而占用较多的寻呼资源，降低网络的性能的问题。

为了解决上述问题，本发明公开了一种寻呼方法，包括：

接收下行业务信令，通过所述下行业务信令解析出目标用户设备的标识；

从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区，并向所述N个跟踪区内的基站发送寻呼请求，其中，N为正整数；

判断在预设的第一时间内是否接收到所述目标用户设备的寻呼响应；

如果接收到所述寻呼响应，则确定本次寻呼成功；

如果没有接收到所述寻呼响应，则分别向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求。

可选地，在分别向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求之后，还包括：

判断在所述预设的第一时间内是否接收到所述目标用户设备的寻呼响应；

如果接收到所述寻呼响应，则确定本次寻呼成功；

如果没有接收到所述寻呼响应，则确定本次寻呼失败。

可选地，在从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区之前，还包括：

判断当前的寻呼状态，所述寻呼状态包括正在寻呼和寻呼结束；

当所述寻呼状态为寻呼结束时，执行所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的步骤。

可选地，在所述向所述N个跟踪区内的基站发送寻呼请求之后，还包括：

将当前的寻呼状态更新为正在寻呼；

在所述确定本次寻呼成功，以及所述确定本次寻呼失败之后，还包括：

将当前的寻呼状态更新为寻呼结束。

可选地，所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区，包括：

获取所述跟踪区列表中各个跟踪区的更新时间；

将所述跟踪区列表中的跟踪区按照所述更新时间的早晚顺序进行倒序排序；

从排序后的跟踪区列表中选取前N个跟踪区。

可选地，在从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区之前，还包括：

获取所述跟踪区列表中跟踪区的最晚更新时间，并判断本次寻呼的寻呼时间与所述最晚更新时间的间隔是否小于预设的第二时间；

若是，则执行所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的步骤；

若否，则向所述跟踪区列表中的所有跟踪区内的基站发送寻呼请求。

可选地，在从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区之前，还包括：

比较所述跟踪区列表中的跟踪区的个数与N的大小；

当所述跟踪区的个数大于N时，执行所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的步骤；

当所述跟踪区的个数小于或等于N时，向所述跟踪区列表中的所有跟踪区内的基站发送寻呼请求。

另一方面，本发明还公开了一种寻呼***，包括：

解析模块，用于接收下行业务信令，通过所述下行业务信令解析出目标用户设备的标识；

第一发送模块，用于从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区，并向所述N个跟踪区内的基站发送寻呼请求，其中，N为正整数；

第一判断模块，用于判断在预设的第一时间内是否接收到所述目标用户设备的寻呼响应；

确定模块，用于当所述第一判断模块的判断结果为是时，确定本次寻呼成功；

第二发送模块，用于当所述第一判断模块的判断结果为否时，分别向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求。

可选地，所述***还包括：

第二判断模块，用于在第二发送模块分别向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求之后，判断在所述预设的第一时间内是否接收到所述目标用户设备的寻呼响应；

所述确定模块还用于当所述第二模块的判断结果为是时，确定本次寻呼成功，当所述第二模块的判断结果为否时，确定本次寻呼失败。

可选地，所述***还包括：

状态判断模块，用于在第一发送模块从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区之前，判断当前的寻呼状态，所述寻呼状态包括正在寻呼和寻呼结束；

所述第一发送模块当所述寻呼状态为寻呼结束时，执行所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的操作。

可选地，所述***还包括：

第一更新模块，用于在所述第一发送模块向所述N个跟踪区内的基站发送寻呼请求之后，将当前的寻呼状态更新为正在寻呼；

第二更新模块，用于在所述确定模块确定本次寻呼成功，以及确定本次寻呼失败之后，将当前的寻呼状态更新为寻呼结束。

可选地，所述第一发送模块包括：

时间获取子模块，用于获取所述跟踪区列表中各个跟踪区的更新时间；

排序子模块，用于将所述跟踪区列表中的跟踪区按照所述更新时间的早晚顺序进行倒序排序；

选取子模块，用于从排序后的跟踪区列表中选取前N个跟踪区。

可选地，所述***还包括：

时间判断模块，用于在第一发送模块从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区之前，获取所述跟踪区列表中跟踪区的最晚更新时间，并判断本次寻呼的寻呼时间与所述最晚更新时间的间隔是否小于预设的第二时间；

所述第一发送模块当所述时间判断模块的判断结果为是时，执行所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的操作；

第三发送模块，用于当所述时间判断模块的判断结果为否时，向所述跟踪区列表中的所有跟踪区内的基站发送寻呼请求。

可选地，所述***还包括：

比较模块，用于在第一发送模块从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区之前，比较所述跟踪区列表中的跟踪区的个数与N的大小；

所述第一发送模块当比较模块的比较结果为所述跟踪区的个数大于N时，执行所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的操作；

第四发送模块，用于当比较模块的比较结果为所述跟踪区的个数小于或等于N时，向所述跟踪区列表中的所有跟踪区内的基站发送寻呼请求。

与现有技术相比，本发明实施例包括以下优点：

本发明实施例中MME在接收下行业务信令后，首先通过所述下行业务信令解析出目标用户设备的标识，然后从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区，并向所述N个跟踪区内的基站发送寻呼请求，发送寻呼请求之后判断在预设的第一时间内是否接收到所述目标用户设备的寻呼响应，如果接收到所述寻呼响应，则确定本次寻呼成功；如果没有接收到所述寻呼响应，则分别向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求。本发明实施例中MME并不是直接向跟踪区列表中的所有跟踪区内的基站发送寻呼请求，而是选取其中的N个跟踪区，向其中的基站发送寻呼请求，如果没有收到寻呼响应，才会向其余的跟踪区内的基站发送寻呼请求，从而能够有效节约寻呼资源，减少寻呼请求的数量，降低对网络性能的影响。

其次，本发明实施例在选选跟踪区进行寻呼之前，可以先判断当前的寻呼状态，如果当前的寻呼状态为正在寻呼，则不执行本次的寻呼过程，在当前的寻呼状态为寻呼结束时，才执行本次的寻呼过程。通过对当前寻呼状态的判断，可以控制只在上一次寻呼完成之后才进行下一次寻呼，因此，当有大量的下行业务信令到达时，可以避免同时寻呼导致的相互影响，减少无效寻呼。

附图说明

图1是本发明实施例一所述的一种寻呼方法的流程图；

图2是本发明实施例二所述的一种寻呼方法的流程图；

图3是本发明一个具体实施例所述的一种寻呼方法的流程图；

图4是本发明实施例三所述的一种寻呼***的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

本发明实施例MME在向基站发送寻呼请求时，并不是直接向跟踪区列表中的所有跟踪区内的基站发送寻呼请求，而是选取其中满足条件的N个跟踪区，向所述N个跟踪区内的基站发送寻呼请求，在没有接收到寻呼响应时，才会向剩余的跟踪区发送寻呼请求，从而能够有效节约寻呼资源，减少寻呼请求的数量。

实施例一：

当网络中有下行数据传输或者网络侧触发的信令流程时，网络会下发下行业务信令至MME，要求MME与UE进行连接，此时，MME将向对应的基站发送寻呼请求，再由基站将所述寻呼请求转发给对应的UE，从而建立与UE之间的链接。

在MME中保存有UE经过的跟踪区，这些跟踪区可以组成跟踪区列表(TA list)，每个UE都对应一个跟踪区列表，当MME接收到下行业务信令时，MME会直接向所有处于TA list中的基站发送寻呼请求，由基站将所述寻呼请求转发给UE，如果在预设的时间内接收到UE的寻呼响应，则说明寻呼成功。

但是，上述方法中MME会向所有处于TA list中的基站发送寻呼请求，这样会导致寻呼过程中下行业务频繁触发寻呼请求，从而占用较大的寻呼资源，降低网络的性能。

针对上述问题，本发明实施例提出了一种寻呼方法，该方法中MME并不是直接向UE对应的跟踪区列表中所有跟踪区内的基站发送寻呼请求，而是选取其中的部分跟踪区内的基站发送寻呼请求。

参照图1，示出了本发明实施例一种寻呼方法的流程图，具体的，该方法可以包括：

步骤100，接收下行业务信令，通过所述下行业务信令解析出目标用户设备的标识。

当网络中有下行数据传输或者网络侧触发的信令流程时，网络会下发下行业务信令至MME，该下行业务信令中会携带一些目标用户设备的信息，MME通过对所述下行业务信令进行分析，即可以解析出目标用户设备的标识，进而与该目标UE建立连接。

步骤102，从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区，并向所述N个跟踪区内的基站发送寻呼请求，其中，N为正整数。

MME可以保存UE经过跟踪区，然后将这些跟踪区组成跟踪区列表，其中UE与所述跟踪区列表是一一对应的关系，可以通过UE的标识与所述跟踪区列表进行对应。

在解析出目标UE的标识之后，可以根据一定的条件从该目标UE的标识对应的跟踪区列表中选取N个跟踪区，然后只向所述N个跟踪区内的基站发送寻呼请求。

步骤104，判断在预设的第一时间内是否接收到所述目标用户设备的寻呼响应。

步骤106，如果接收到所述寻呼响应，则确定本次寻呼成功。

每次寻呼过程都是有寻呼时间的限定的，如果在规定的时间内接收到UE的寻呼响应，则说明本次寻呼成功，可以停止寻呼流程，进入业务接入流程；如果在规定的时间内没有接收到UE的寻呼响应，则说明本次寻呼失败，因此不能执行业务接入流程。

因此，本发明实施例中预设了一个第一时间，该时间即用于限定寻呼的时间。对于所述第一时间的具体数值，本领域技术人员根据实际经验进行相关设定即可，本发明实施例对此并不加以限制。

步骤108，如果没有接收到所述寻呼响应，则分别向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求。

如果在步骤104中判断出在预设的第一时间内没有接收到所述目标UE的寻呼响应，则说明所述目标UE均没有在之前选取的N个跟踪区内的基站覆盖范围内，而目标UE可能在剩余的跟踪区内的基站覆盖范围内，因此，本发明实施例可以进一步向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求。

对于上述寻呼方法的各个步骤本发明实施例描述的比较简单，其具体过程将在下面的实施例中详细介绍。

本发明实施例中MME在接收下行业务信令后，首先通过所述下行业务信令解析出目标用户设备的标识，然后从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区，并向所述N个跟踪区内的基站发送寻呼请求，发送寻呼请求之后判断在预设的第一时间内是否接收到所述目标用户设备的寻呼响应，如果接收到所述寻呼响应，则确定本次寻呼成功；如果没有接收到所述寻呼响应，则分别向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求。本发明实施例中MME并不是直接向跟踪区列表中的所有跟踪区内的基站发送寻呼请求，而是选取其中的N个跟踪区，向其中的基站发送寻呼请求，如果没有收到寻呼响应，才会向其余的跟踪区内的基站发送寻呼请求，从而能够有效节约寻呼资源，减少寻呼请求的数量，降低对网络性能的影响。

实施例二：

下面，对本发明实施例提出的寻呼方法进行详细介绍。

参照图2，示出了本发明实施例所述的一种寻呼方法的流程图，所述方法具体可以包括：

步骤200，接收下行业务信令，通过所述下行业务信令解析出目标用户设备的标识。

当网络中有下行数据传输或者网络侧触发的信令流程时，网络会下发下行业务信令至MME，MME可以通过该下行业务信令中的具体的信息解析出目标UE的标识。

其中，目标UE主要是指该下行业务信令是针对哪个UE的，例如下行业务数据要传输至哪个UE，等等。

例如，所述下行业务信令中可以包括该下行业务信令与目标UE的标识(每个UE都可以有一个标识，用于将该UE去其他UE区别开)的映射关系，通过对该映射关系进行解析，即可获取到对应的目标UE的标识。对于具体的解析所述映射关系过程，本发明实施例在此不再详细论述。

当然，所述下行业务信令中还可以包括一些其他的关于所述目标UE的信息，通过这些信息也可以解析出目标UE的标识，本发明实施例对此并不加以限制。

步骤202，判断当前的寻呼状态，所述寻呼状态包括正在寻呼和寻呼结束。

在寻呼过程中，如果多个寻呼同时进行，则各个寻呼流程之间可能会相互影响，因此很有可能使某些寻呼流程失败，从而出现无效寻呼。

为了解决上述问题，本发明实施例中，在针对本次接收到的下行业务信令进行寻呼之前，可以先判断当前的寻呼状态，所述寻呼状态可以包括正在寻呼和寻呼结束两种，其中“正在寻呼”状态可以表示当前正处于上一次的寻呼流程中(即上次的寻呼流程还未结束)，“寻呼结束”状态可以表示当前没有在执行寻呼流程(即之前的寻呼流程均已经结束)。

如果当前的寻呼状态为正在寻呼，为了避免同时寻呼导致的相互影响，则本发明实施例针对本次接收到的下行业务信令可以暂时不进行寻呼，本次寻呼过程结束，当再接收到下行业务信令时，再进行判断。

如果当前的寻呼状态为寻呼结束，则说明当前没有在执行寻呼流程，可以执行本次的寻呼流程。此时，可以执行以下步骤208所述的从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的过程。

但是，本发明实施例中进一步提出了以下步骤204中描述的对跟踪区列表中的跟踪区的个数进行判断的方式，针对跟踪区的个数的不同情况执行不同的操作。因此，本发明实施例中，在该步骤202中判断出当前的寻呼状态为寻呼结束时，可以执行以下步骤204的比较过程。

步骤204，当所述寻呼状态为寻呼结束时，比较所述目标UE的标识对应的预先设置的跟踪区列表中的跟踪区的个数与N的大小。

本发明实施例中，MME中保存有UE经过跟踪区，并将这些跟踪区组成跟踪区列表，其中每个UE都可以对应一个跟踪区列表，可以通过UE的标识与所述跟踪区列表进行对应。

本发明实施例在步骤202中判断出当前的寻呼状态为寻呼结束，进行寻呼之前，可以先判断该跟踪区列表的大小(即跟踪区列表中的跟踪区的个数的多少)。如果所述跟踪区列表比较大，则可以只从其中选取部分跟踪区内的基站进行寻呼；如果所述跟踪区列表比较小，则可以直接向所有的跟踪区内的基站进行寻呼。

具体的，可以根据实际情况预先设置一个正整数N，然后将所述目标UE的标识对应的预先设置的跟踪区列表中的跟踪区的个数与N进行比较，如果所述跟踪区的个数大于N，则可以认为该跟踪区列表比较大，如果所述跟踪区的个数小于或等于N，则可以认为该跟踪区列表比较小。

因此，本发明实施例中，当判断出所述跟踪区的个数大于N时，可以从所述跟踪区列表中选取部分跟踪区内的基站进行寻呼，此时，可以执行步骤208所述的从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的过程。

但是，本发明实施例中还进一步提出了以下步骤206中描述的判断本次寻呼的寻呼时间与跟踪区列表的最近更新时间的时间间隔的方式，根据该时间间隔的不同情况执行不同的操作。因此，本发明实施例中，在该步骤204中判断出所述跟踪区的个数大于N时，可以执行以下步骤206的判断过程。

当所述跟踪区的个数小于或等于N时，可以向所述跟踪区列表中的所有跟踪区内的基站发送寻呼请求，并执行步骤214。

对于上述N的具体数值，本领域技术人员根据实际经验进行相应设置即可。例如，可以将N的范围设置为[2，7]，例如可以设置N为3，并根据组网情况进行动态调整，若网络内部跟踪区覆盖的基站数目较多，则可以将该常数设置为较小值；若该网络预定用户的移动速度较小，也可以将该常数设置为较小值，本发明实施例并不加以限制。

步骤206，当所述跟踪区的个数大于N时，获取所述跟踪区列表中跟踪区的最晚更新时间，并判断本次寻呼的寻呼时间与所述最晚更新时间的间隔是否小于预设的第二时间。

当UE的位置有更新时，会触发跟踪区更新(Tracking Area Update，TAU)流程，通知MME更新跟踪区，并且MME可以记录该更新时间。在本发明实施例中，可以首先获取所述跟踪区列表中各个跟踪区的更新时间，然后获取其中的最晚更新时间。

本发明实施例中，可以预先设置一个第二时间(该第二时间用于控制本次寻呼与上次TAU的时间间隔是否太长)，并判断本次寻呼的寻呼时间与上述获取的所述最晚更新时间的间隔是否小于预设的第二时间。

如果判断结果为否，则可以说明该UE在网络中已经很长时间没有活动，该UE对应的跟踪区列表中的跟踪区可能是过期的，因此不能确定该UE处于哪个跟踪区内。此时，可以执行步骤214，向所述跟踪区列表中的所有跟踪区内的基站发送寻呼请求。

如果判断结果为是，则可以执行步骤208所述的从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的过程。

需要说明的是，对于上述预设的第二时间的具体数值，本发明实施例并不加以限制。

步骤208，从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区，并向所述N个跟踪区内的基站发送寻呼请求。

本发明实施例中，可以从所述跟踪区列表中选取最近更新过的N个跟踪区，向这些跟踪区内的基站发送寻呼请求，具体的，该步骤208可以包括：

1、获取所述跟踪区列表中各个跟踪区的更新时间。

2、将所述跟踪区列表中的跟踪区按照所述更新时间的早晚顺序进行倒序排序。

所述进行倒序排序即将更新时间晚的跟踪区排在序列的前面。

3、从排序后的跟踪区列表中选取前N个跟踪区。

本发明实施例中在并向所述N个跟踪区内的基站发送寻呼请求之后，还会将当前的寻呼状态更新为正在寻呼，以避免其他的寻呼流程对本寻呼流程的影响。

步骤210，判断在预设的第一时间内是否接收到所述目标用户设备的寻呼响应。

MME向所述N个跟踪区内的基站发送寻呼请求之后，通过基站将所述寻呼请求转发给UE。每次寻呼过程都是有寻呼时间的限定的，如果在规定的时间内接收到UE的寻呼响应，则说明本次寻呼成功；如果在规定的时间内没有接收到UE的寻呼响应，则说明本次寻呼失败。

因此，在该步骤210中可以判断在预设的第一时间内是否接收到所述目标用户设备的寻呼响应。

如果接收到所述寻呼响应，则说明所述目标UE在所选取的N个跟踪区内的基站覆盖范围内，因此可以执行步骤216，确定本次寻呼成功，并将当前的寻呼状态更新为寻呼结束。

如果没有接收到所述寻呼响应，则说明所述目标UE均没有在之前选取的N个跟踪区内的基站覆盖范围内，而目标UE可能在剩余的跟踪区内的基站覆盖范围内，因此，本发明实施例可以进一步执行步骤212，分别向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求。

步骤212，如果没有接收到所述寻呼响应，则分别向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求。

步骤214，判断在所述预设的第一时间内是否接收到所述目标用户设备的寻呼响应。

在向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求之后，也可以判断在所述预设的第一时间内是否接收到所述目标用户设备的寻呼响应。

如果接收到所述寻呼响应，则说明所述目标UE在剩余的跟踪区内的基站覆盖范围内，因此可以执行步骤216确定本次寻呼成功，并将当前的寻呼状态更新为寻呼结束。

如果没有接收到所述寻呼响应，则说明目标UE均没有在所述跟踪区列表中的跟踪区内的基站覆盖范围内，因此可以执行步骤218确定本次寻呼失败，并将当前的寻呼状态更新为寻呼结束。

需要说明的是，在上述步骤204中判断出所述跟踪区的个数小于或等于N以及上述步骤206的判断结果为否时，向所述跟踪区列表中的所有跟踪区内的基站发送寻呼请求之后，也会执行该步骤214。如果接收到所述寻呼响应，则说明本次寻呼成功，并将当前的寻呼状态更新为寻呼结束；如果没有接收到所述寻呼响应，则说明本次寻呼失败，并将当前的寻呼状态更新为寻呼结束。

步骤216，当接收到所述寻呼响应时，确定本次寻呼成功，并将当前的寻呼状态更新为寻呼结束。

在上述步骤210或者步骤214中判断出在预设的第一时间内接收到所述目标用户设备的寻呼响应之后，即可确定本次寻呼成功，此时本次寻呼过程结束，因此可以将当前的寻呼状态更新为寻呼结束。

步骤218，当没有接收到所述寻呼响应时，确定本次寻呼失败，并将当前的寻呼状态更新为寻呼结束。

如果在上述步骤214中判断出在预设的第一时间内没有接收到所述目标用户设备的寻呼响应，则说明目标UE均没有在所述跟踪区列表中的所有跟踪区中的基站覆盖范围内，因此可以确定本次寻呼失败，此时本次寻呼过程结束，可以将当前的寻呼状态更新为寻呼结束。

下面，通过一个具体的实施例说明本发明实施例提出的一种寻呼方法的具体过程。

在该具体的实施例中，可以通过定时器控制各个时间的判断过程，例如，可以分别设置Timer1、Timer2和Timer3这3个定时器。

Timer1：该定时器可以用于控制一次寻呼过程中的重复寻呼。当网络第一次触发寻呼时启动，寻呼结束时关闭。该定时器的阈值大于2倍的Timer3的阈值(根据上述相关描述可以得知，在一次寻呼过程中，可能会发送两次寻呼请求，因此，Timer1的阈值要大于2倍的Timer3的阈值)。

另外，本发明实施例还可以设置一个开关变量，可以通过该变量表示当前的寻呼状态，例如，如果开关变量为0，则可以表示当前的寻呼状态为寻呼结束，如果开关变量为1，则可以表示当前的寻呼状态为正在寻呼。

当然，还可以将所述开关变量设置为其他值，本发明实施例对此并不加以限制。

Timer2：该Timer2可以与上述的第二时间相对应，用于控制本次寻呼与上次TAU的时间间隔。当该Timer值大于阈值时，认为该用户在网络中太久没有活动，TA list中的TA可能是过期的。该定时器通过网络自动控制，当网络认为用户处于空闲态(IDLE态)时启动，当网络认为该用户处于连接态(CONNECTED态)时重置为初始值。

Timer3：该Timer3可以与上述的第一时间相对应，用于控制寻呼过程。当发出寻呼请求时启动，收到寻呼响应或者超时后自动关闭。

参照图3，示出了该具体实施例所述的一种寻呼方法的流程图，具体可以包括：

a1，接收到下行业务信令，解析出目标UE的标识。

a2，判断开关变量是否为0。

若是，则执行步骤a3；否则，针对本次接收的下行业务信令不进行寻呼。

a3，启动Timer1，将开关变量置1。

a4，判断TA list中TA区的个数是否小于N。

若是，则认为跟踪区列表较小，执行步骤a；否则，认为跟踪区列表较大，执行步骤a5。

a5，判断Timer2是否超时。

若是，则认为用户很久未与网络联系，不确定用户在哪个TA区内，执行步骤a7；否则执行步骤a6，进行全面寻呼。

a6，对目标UE的标识对应的TA list中的跟踪区内的所有基站进行寻呼，并执行步骤a10。

a7，从目标UE的标识对应的TA list中选取最近更新的N个TA区内的基站进行寻呼，并启动Timer3。

a8，判断Timer3超时之前是否收到寻呼响应。

若是，则执行步骤a11；否则，执行步骤a9。

a9，在TA list中剩余的TA区内的基站进行寻呼，并启动Timer3。

a10，判断Timer3超时之前是否收到寻呼响应。

若是，则认为用户处于无效状态，执行步骤a12；否则，执行步骤a11。

a11，确定本次寻呼成功，关闭Timer1和Timer3，并将开关变量置0。

a12，确定本次寻呼失败，关闭Timer1。

本发明实施例中，MME在向基站发送寻呼请求时，并不是直接向跟踪区列表中的所有跟踪区内的基站发送寻呼请求，而是选取其中满足条件的N个跟踪区，向所述N个跟踪区内的基站发送寻呼请求，在没有接收到寻呼响应时，才会向剩余的跟踪区发送寻呼请求，从而能够有效节约寻呼资源，减少寻呼请求的数量。

其次，本发明实施例在选选跟踪区进行寻呼之前，可以先判断当前的寻呼状态，如果当前的寻呼状态为正在寻呼，则不执行本次的寻呼过程，在当前的寻呼状态为寻呼结束时，才执行本次的寻呼过程。通过对当前寻呼状态的判断，可以控制只在上一次寻呼完成之后才进行下一次寻呼，因此，当有大量的下行业务信令到达时，可以避免同时寻呼导致的相互影响，减少无效寻呼。

实施例三：

参照图4，示出了本发明实施例三所述的一种寻呼***的结构框图，所述***可以包括：解析模块400、第一发送模块402、第一判断模块404、确定模块406、第二发送模块408、第二判断模块410、状态判断模块412、第一更新模块414、第二更新模块416、时间判断模块418、第三发送模块420、比较模块422和第四发送模块424。

其中，

解析模块400，用于接收下行业务信令，通过所述下行业务信令解析出目标用户设备的标识；

第一发送模块402，用于从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区，并向所述N个跟踪区内的基站发送寻呼请求，其中，N为正整数；

所述第一发送模块402包括：

时间获取子模块，用于获取所述跟踪区列表中各个跟踪区的更新时间；

排序子模块，用于将所述跟踪区列表中的跟踪区按照所述更新时间的早晚顺序进行倒序排序；

选取子模块，用于从排序后的跟踪区列表中选取前N个跟踪区。

第一判断模块404，用于判断在预设的第一时间内是否接收到所述目标用户设备的寻呼响应；

确定模块406，用于当所述第一判断模块的判断结果为是时，确定本次寻呼成功；

第二发送模块408，用于当所述第一判断模块的判断结果为否时，分别向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求；

第二判断模块410，用于在第二发送模块分别向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求之后，判断在所述预设的第一时间内是否接收到所述目标用户设备的寻呼响应；

所述确定模块还用于当所述第二模块的判断结果为是时，确定本次寻呼成功，当所述第二模块的判断结果为否时，确定本次寻呼失败；

状态判断模块412，用于在第一发送模块从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区之前，判断当前的寻呼状态，所述寻呼状态包括正在寻呼和寻呼结束；

所述第一发送模块当所述寻呼状态为寻呼结束时，执行所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的操作；

第一更新模块414，用于在所述第一发送模块向所述N个跟踪区内的基站发送寻呼请求之后，将当前的寻呼状态更新为正在寻呼；

第二更新模块416，用于在所述确定模块确定本次寻呼成功，以及确定本次寻呼失败之后，将当前的寻呼状态更新为寻呼结束；

时间判断模块418，用于在第一发送模块从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区之前，获取所述跟踪区列表中跟踪区的最晚更新时间，并判断本次寻呼的寻呼时间与所述最晚更新时间的间隔是否小于预设的第二时间；

所述第一发送模块当所述时间判断模块的判断结果为是时，执行所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的操作；

第三发送模块420，用于当所述时间判断模块的判断结果为否时，向所述跟踪区列表中的所有跟踪区内的基站发送寻呼请求；

比较模块422，用于在第一发送模块从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区之前，比较所述跟踪区列表中的跟踪区的个数与N的大小；

所述第一发送模块当比较模块的比较结果为所述跟踪区的个数大于N时，执行所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的操作；

第四发送模块424，用于当比较模块的比较结果为所述跟踪区的个数小于或等于N时，向所述跟踪区列表中的所有跟踪区内的基站发送寻呼请求。

需要说明的是，在本发明实施例中，所述寻呼过程可以通过MME进行控制，因此上述各个模块可以为MME中的模块，当然，本发明实施例对此并不加以限制。

本发明实施例中MME在向基站发送寻呼请求时，并不是直接向跟踪区列表中的所有跟踪区内的基站发送寻呼请求，而是选取其中满足条件的N个跟踪区，向所述N个跟踪区内的基站发送寻呼请求，在没有接收到寻呼响应时，才会向剩余的跟踪区发送寻呼请求，从而能够有效节约寻呼资源，减少寻呼请求的数量。其次，在选选跟踪区进行寻呼之前，可以先判断当前的寻呼状态，在当前的寻呼状态为寻呼结束时，才执行本次的寻呼过程，通过对当前寻呼状态的判断，可以控制只在上一次寻呼完成之后才进行下一次寻呼，因此，当有大量的下行业务信令到达时，可以避免同时寻呼导致的相互影响，减少无效寻呼。

对于***实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本发明实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个......”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上对本发明所提供的一种寻呼方法和***，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (14)

1.一种寻呼方法，其特征在于，包括：

接收下行业务信令，通过所述下行业务信令解析出目标用户设备的标识；

从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区，并向所述N个跟踪区内的基站发送寻呼请求，其中，N为正整数；

判断在预设的第一时间内是否接收到所述目标用户设备的寻呼响应；

如果接收到所述寻呼响应，则确定本次寻呼成功；

如果没有接收到所述寻呼响应，则分别向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求。

2.根据权利要求1所述的方法，其特征在于，在分别向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求之后，还包括：

判断在所述预设的第一时间内是否接收到所述目标用户设备的寻呼响应；

如果接收到所述寻呼响应，则确定本次寻呼成功；

如果没有接收到所述寻呼响应，则确定本次寻呼失败。

3.根据权利要求2所述的方法，其特征在于，在从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区之前，还包括：

判断当前的寻呼状态，所述寻呼状态包括正在寻呼和寻呼结束；

当所述寻呼状态为寻呼结束时，执行所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的步骤。

4.根据权利要求3所述的方法，其特征在于，

在所述向所述N个跟踪区内的基站发送寻呼请求之后，还包括：

将当前的寻呼状态更新为正在寻呼；

在所述确定本次寻呼成功，以及所述确定本次寻呼失败之后，还包括：

将当前的寻呼状态更新为寻呼结束。

5.根据权利要求1所述的方法，其特征在于，所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区，包括：

获取所述跟踪区列表中各个跟踪区的更新时间；

将所述跟踪区列表中的跟踪区按照所述更新时间的早晚顺序进行倒序排序；

从排序后的跟踪区列表中选取前N个跟踪区。

6.根据权利要求1所述的方法，其特征在于，在从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区之前，还包括：

获取所述跟踪区列表中跟踪区的最晚更新时间，并判断本次寻呼的寻呼时间与所述最晚更新时间的间隔是否小于预设的第二时间；

若是，则执行所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的步骤；

若否，则向所述跟踪区列表中的所有跟踪区内的基站发送寻呼请求。

7.根据权利要求1所述的方法，其特征在于，在从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区之前，还包括：

比较所述跟踪区列表中的跟踪区的个数与N的大小；

当所述跟踪区的个数大于N时，执行所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的步骤；

当所述跟踪区的个数小于或等于N时，向所述跟踪区列表中的所有跟踪区内的基站发送寻呼请求。

8.一种寻呼***，其特征在于，包括：

解析模块，用于接收下行业务信令，通过所述下行业务信令解析出目标用户设备的标识；

第一发送模块，用于从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区，并向所述N个跟踪区内的基站发送寻呼请求，其中，N为正整数；

第一判断模块，用于判断在预设的第一时间内是否接收到所述目标用户设备的寻呼响应；

确定模块，用于当所述第一判断模块的判断结果为是时，确定本次寻呼成功；

第二发送模块，用于当所述第一判断模块的判断结果为否时，分别向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求。

9.根据权利要求8所述的***，其特征在于，还包括：

第二判断模块，用于在第二发送模块分别向所述跟踪区列表中剩余的跟踪区内的基站发送寻呼请求之后，判断在所述预设的第一时间内是否接收到所述目标用户设备的寻呼响应；

所述确定模块还用于当所述第二模块的判断结果为是时，确定本次寻呼成功，当所述第二模块的判断结果为否时，确定本次寻呼失败。

10.根据权利要求9所述的***，其特征在于，还包括：

状态判断模块，用于在第一发送模块从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区之前，判断当前的寻呼状态，所述寻呼状态包括正在寻呼和寻呼结束；

所述第一发送模块当所述寻呼状态为寻呼结束时，执行所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的操作。

11.根据权利要求10所述的***，其特征在于，还包括：

第一更新模块，用于在所述第一发送模块向所述N个跟踪区内的基站发送寻呼请求之后，将当前的寻呼状态更新为正在寻呼；

第二更新模块，用于在所述确定模块确定本次寻呼成功，以及确定本次寻呼失败之后，将当前的寻呼状态更新为寻呼结束。

12.根据权利要求8所述的***，其特征在于，所述第一发送模块包括：

时间获取子模块，用于获取所述跟踪区列表中各个跟踪区的更新时间；

排序子模块，用于将所述跟踪区列表中的跟踪区按照所述更新时间的早晚顺序进行倒序排序；

选取子模块，用于从排序后的跟踪区列表中选取前N个跟踪区。

13.根据权利要求12所述的***，其特征在于，还包括：

时间判断模块，用于在第一发送模块从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区之前，获取所述跟踪区列表中跟踪区的最晚更新时间，并判断本次寻呼的寻呼时间与所述最晚更新时间的间隔是否小于预设的第二时间；

所述第一发送模块当所述时间判断模块的判断结果为是时，执行所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的操作；

第三发送模块，用于当所述时间判断模块的判断结果为否时，向所述跟踪区列表中的所有跟踪区内的基站发送寻呼请求。

14.根据权利要求8所述的***，其特征在于，还包括：

比较模块，用于在第一发送模块从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区之前，比较所述跟踪区列表中的跟踪区的个数与N的大小；

所述第一发送模块当比较模块的比较结果为所述跟踪区的个数大于N时，执行所述从所述标识对应的预先设置的跟踪区列表中选取N个跟踪区的操作；

第四发送模块，用于当比较模块的比较结果为所述跟踪区的个数小于或等于N时，向所述跟踪区列表中的所有跟踪区内的基站发送寻呼请求。

Images