寻呼方法、装置及可读存储介质与流程

本发明涉及通信领域，特别是涉及一种寻呼方法、装置及可读存储介质。

背景技术：

在lte/lte-a中，核心网可以通知处于无线资源控制空闲态(rrc_idle)下的用户设备(userequipment，ue)所驻留的跟踪区(trackingarea，ta)中的基站寻呼该ue以通知该ue与当前驻留的小区的基站建立连接。处于rrc_idle的ue在寻呼帧(pagingframe，pf)中的寻呼时刻(pagingoccasion，po)监听物理下行控制信道(physicaldownlinkcontrolchannel，pdcch)。如果ue在po检测到pdcch传输的由寻呼无线网络临时标识(paging-radionetworktemporyidentity，p-rnti)加扰的下行控制信息(downlinkcontrolinformation，dci)，则读取所述dci指示的物理下行共享信道(physicaldownlinksharedchannel，pdsch)传输的寻呼记录，以检查自身的标识(identity，id)是否包括在寻呼记录中，如果包括则启动随机接入以与当前驻留的小区的基站建立连接。处于rrc_idle的ue可以使用非连续接收(discontinuousreception，drx)技术以节省功耗，一个drx周期内只监听一个po。

在新空口(newradio，nr)中，由于系统被设想在高达100ghz的频率范围上运行，面临着脆弱的无线链路和高穿透损耗的挑战。为了解决这些问题，波束赋形被采用作为基本技术，并提出波束扫描以改善小区覆盖。波束扫描是指同一信号/信道至少由两个波束承载，且在一个周期内的至少两个时间单元(例如子帧、时隙、符号等)中发送。

在nr中，寻呼消息可以以波束扫描的方式发送。由于核心网/锚基站并不知道处于rrc_idle或无线资源控制待用态(rrc_inactive)下ue的具体位置以及最佳的发送/接收波束，可能需要控制ta/通知区(notificationarea)中的所有基站以波束扫描方式发送寻呼消息(包括p-rnti加扰的dci及寻呼记录)。

nr中可用频谱资源的范围很大，不同的小区的寻呼配置(例如drx周期等)和波束配置(例如波束数量等)可能区别很大，因此不同小区中的寻呼时机(包括pf和/或po)可能无法对齐，有可能出现被寻呼的ue已经响应了但是某些小区仍未/仍在发送寻呼消息，造成无线资源的浪费。

技术实现要素：

本发明主要解决的技术问题是提供一种寻呼方法、装置及可读存储介质，能够解决现有技术中不同小区的寻呼时机无法对齐导致的无线资源浪费的问题。

为了解决上述技术问题，本发明第一方面提供了一种寻呼方法，该方法包括：向被寻呼的用户设备所驻留的跟踪区中的基站发送寻呼通知，寻呼通知用于通知基站发送寻呼消息以寻呼用户设备；确认用户设备被找到；至少向跟踪区中除找到用户设备基站之外的其他基站发送寻呼终止消息，寻呼终止消息用于通知其他基站停止发送寻呼消息。

为了解决上述技术问题，本发明第二方面提供了一种寻呼方法，该方法包括：发送寻呼消息以寻呼用户设备并向用户设备所驻留的通知区中的基站发送寻呼通知，寻呼通知用于通知基站发送寻呼消息以寻呼用户设备；确认用户设备被找到；至少向通知区中除找到用户设备基站之外的其他基站发送寻呼终止消息，寻呼终止消息用于通知其他基站停止发送寻呼消息。

为了解决上述技术问题，本发明第三方面提供了一种寻呼方法，该方法包括：接收来自于核心网或锚基站的寻呼通知；响应寻呼通知发送寻呼消息以寻呼用户设备；未找到用户设备时接收到来自于核心网或锚基站的寻呼终止消息；响应寻呼终止消息停止发送寻呼消息。

为了解决上述技术问题，本发明第四方面提供了一种寻呼装置，该装置包括处理器和通信电路，处理器连接通信电路，处理器用于执行指令以实现本发明第一至第三方面中任一个提供的方法。

为了解决上述技术问题，本发明第五方面提供了一种可读存储介质，该可读存储介质存储有指令，指令被执行时实现本发明第一至第三方面中任一个提供的方法。

本发明的有益效果是：核心网/锚基站在确认用户设备被找到后至少向跟踪区/通知区中除找到该用户设备的基站之外的其他基站发送寻呼终止消息以通知其停止发送寻呼消息，其他基站不会继续发送不必要的寻呼消息，从而减少无线资源的浪费。

附图说明

图1是本发明寻呼方法第一实施例的流程示意图；

图2是本发明寻呼方法第二实施例的流程示意图；

图3是本发明寻呼方法第三实施例的流程示意图；

图4是本发明寻呼方法第四实施例的流程示意图；

图5是本发明寻呼方法第五实施例的流程示意图；

图6是本发明寻呼方法第六实施例的流程示意图；

图7是本发明寻呼方法第七实施例的流程示意图；

图8是本发明寻呼方法第八实施例的流程示意图；

图9是本发明寻呼方法第九实施例的流程示意图；

图10是本发明寻呼方法第十实施例的流程示意图；

图11是本发明寻呼装置第一实施例的结构示意图；

图12是本发明寻呼装置第二实施例的结构示意图；

图13是本发明可读存储介质第一实施例的结构示意图；

图14是本发明可读存储介质第二实施例的结构示意图。

具体实施方式

下面结合附图和实施例对本发明进行详细说明。以下各实施例中不冲突的可以相互结合。

本发明寻呼方法第一实施例的执行主体为核心网。如图1所示，本实施例包括：

s11：向被寻呼的用户设备所驻留的跟踪区中的基站发送寻呼通知。

本实施例中，被寻呼的用户设备(以下简称用户设备)处于rrc_idle，寻呼由核心网启动。核心网知道该用户设备当前所驻留的跟踪区(以下简称跟踪区)，但是并不知道该用户设备当前驻留在哪个基站。寻呼通知的发送对象可以为该跟踪区中的所有基站。寻呼通知用于通知基站发送寻呼消息以寻呼用户设备。收到寻呼通知的基站可以将传统的寻呼直接应用到波束扫描来发送寻呼消息，也可以以新的方式(例如响应驱动)发送寻呼消息，在此不做限制。

s12：确认用户设备被找到。

核心网可以在接收到来自于找到用户设备的基站的寻呼响应消息时确认用户设备被找到。其中找到用户设备的基站为被找到时用户设备驻留(rrc_idle)/连接(rrc_connected)的基站。寻呼响应消息可以包括第一寻呼响应消息和/或第二寻呼响应消息。第一寻呼响应消息早于第二寻呼响应消息。两者相比，前者能够更早的触发寻呼终止消息的发送，从而进一步减少无线资源的浪费。

第二寻呼响应消息的发送时机可以与现有技术相同，第一寻呼响应消息的发送时机在第二寻呼响应消息之前，因此也可以被称为早期寻呼响应消息。

例如，第一寻呼响应消息是找到用户设备的基站在接收到来自于用户设备的消息3(msg3)后发送的。消息3是用户设备发起随机接入以转换到rrc_connected过程中的第三条消息，由于其中包括了发送方的id，收到它的基站可以确认用户设备成功的被找到。基站收到消息3时用户设备仍未从rrc_idle转换到rrc_connected，因此找到该用户设备的基站为其驻留的基站。本实施例中用户设备原本为rrc_idle，消息3可以为rrc连接请求消息。

第二寻呼响应消息是找到用户设备的基站在与用户设备建立连接之后发送的。基站与用户设备建立连接意味着用户设备转换到rrc_connected。

s13：至少向跟踪区中除找到用户设备的基站之外的其他基站发送寻呼终止消息。

寻呼终止消息用于通知其他基站停止发送寻呼消息。对于找到用户设备的基站，核心网可以向其发送寻呼终止消息，也可以不发送。

通过本实施例的实施，核心网在确认用户设备被找到后至少向跟踪区中除找到该用户设备的基站之外的其他基站发送寻呼终止消息以通知其停止发送寻呼消息，其他基站不会继续发送不必要的寻呼消息，从而减少无线资源的浪费。

如果基站是以响应驱动的方式进行寻呼，由于寻呼消息中可以包括寻呼指示，每个寻呼指示对应一组用户设备，每组用户设备的数量大于或者等于一，有可能出现误报(即收到对应的寻呼指示但未被寻呼的用户设备仍会响应基站)，如果基站能够停止发送寻呼指示，则减少浪费的无线资源中除了基站发送寻呼消息的下行资源之外，还包括用户设备误报所消耗的上行资源。

如图2所示，本发明寻呼方法第二实施例，是在本发明寻呼方法第一实施例的基础上，至少部分寻呼通知中包括寻呼延迟信元。本实施例是对本发明寻呼方法第一实施例的进一步扩展，因此与本发明寻呼方法第一实施例相同的内容在此不再赘述。本实施例包括：

s100：至少根据用户设备的信息评估用户设备驻留在跟踪区中的小区的概率。

核心网可以至少根据用户设备的信息估算若干个用户设备当前可能的位置以及用户设备处于每个可能的位置的概率，结合跟踪区的小区部署信息，可以评估出用户设备驻留在跟踪区中每个小区的概率。

用户设备的信息可以包括用户设备的运动速度、历史轨迹、近期活动中的至少一种。近期活动可以包括通知区更新、跟踪区更新、rrc连接释放、rrc连接恢复、rrc连接拒绝(用于响应驱动的寻呼机制中误报解决)、系统信息请求中的至少一种。这些信息对于核心网是已知的，因此不需要引入额外的信令开销。

除了用户设备的信息之外，核心网在评估概率时还可以考虑小区的选择/重选优先级。举例说明，用户设备的某个当前可能的位置处于小区a和b的重叠范围内，也就是说用户设备既有可能驻留在小区a，也有可能驻留在小区b，核心网可以结合小区a和b的选择/重选优先级来估算最终的概率，对于该当前可能的位置而言，用户设备驻留在选择/重选优先级更高的小区的概率更高。

s101：至少向低概率基站发送包括寻呼延迟信元的寻呼通知。

低概率基站包括至少部分跟踪区中的基站，用户设备驻留在低概率基站的小区的概率低于第一阈值。在选择低概率基站时，除了驻留概率之外，核心网还可以考虑小区中扫描波束的数量。例如只有同时满足驻留概率第一阈值且扫描波束数量大于第二阈值的小区的基站才会被选为低概率基站。

寻呼延迟信元用于指示基站推迟指定时长发送寻呼消息，寻呼延迟信元可以显性或者隐性地指示指定时长的长短。指定时长可以用实际的时长来表示，也可以用时长单位(可省略)和倍数的乘积来表示。时长单位可以为一个寻呼周期、drx周期、波束扫描周期等。

如果低概率基站不止一个，则不同的寻呼延迟信元指示的指定时长可以相同，也可以不同。如果不同，指定时长可以与对应的评估概率负相关，即用户设备驻留在某个低概率基站的小区的概率越低，核心网发给该低概率基站的寻呼通知中的寻呼延迟信元指示的指定时长越长。

对于向跟踪区中除低概率基站之外的其他基站发送的寻呼消息，其中可以不包括寻呼延迟信元，也可以包括寻呼延迟信元(指示的指定时长可以为0以表示正常发送寻呼消息)。

s102：确认用户设备被找到。

s103：至少向跟踪区中除找到用户设备的基站之外的其他基站发送寻呼终止消息。

通过本实施例的实施，核心网在至少部分寻呼通知中引入寻呼延迟信元，使得用户设备驻留概率低的基站推迟发送寻呼消息。低概率基站在寻呼过程中找到用户设备的概率较低，相应的收到寻呼终止消息的概率较高，推迟发送寻呼消息可以使得低概率基站收到寻呼终止消息尚未开始发送寻呼消息的可能性提高，即使低概率基站在收到寻呼终止消息时已经开始发送寻呼消息，寻呼消息的发送时间也会缩短。在对用户设备的寻呼时间不造成明显影响的同时，进一步减少了无线资源的浪费。

在其他实施例中，核心网也可以不配置寻呼延迟信元，此时所有的寻呼通知中可以均不包括寻呼延迟信元。例如被寻呼的用户设备对系统延迟要求较高时，为避免寻呼延迟信元可能对寻呼时间造成的影响，核心网可以选择直接发送所有的寻呼通知而不配置寻呼延迟信元。

本发明寻呼方法第三实施例的执行主体为基站，本实施例中作为锚基站。基站连接核心网并与用户设备进行无线通信，为相应的地理区域提供通信覆盖。基站可以为宏基站、微(micro)基站、微微(pico)基站或家庭基站(femtocell)。在一些实施例中，基站也可以被称为无线基站、接入点、b节点，演进型b节点(enodeb,enb)，gnb或其他合适的术语。如图3所示，本实施例包括：

s21：发送寻呼消息以寻呼用户设备并向用户设备所驻留的通知区中的基站发送寻呼通知。

本实施例中，用户设备处于rrc_inactive，寻呼可以由锚基站(anchorgnb)启动。锚基站知道ue所处的通知区(notificationarea，na)。锚基站保存有ue接入上下文(accesscontext，以下简称上下文)，以及与核心网(corenetwork，cn)的连接关系。用户设备当前驻留的基站不一定为锚基站。锚基站可以在收到核心网的数据传输请求后启动寻呼，并向通知区中其他基站发送寻呼通知。

寻呼通知的发送对象可以为通知区中除锚基站自身之外的其他所有基站。寻呼通知用于通知基站发送寻呼消息以寻呼用户设备。锚基站和收到寻呼通知的基站可以将传统的寻呼直接应用到波束扫描来发送寻呼消息，也可以以新的方式(例如响应驱动)发送寻呼消息，在此不做限制。

s22：确认用户设备被找到。

如果用户设备驻留在锚基站，则会启动随机接入以恢复与锚基站的连接，锚基站自身就是找到用户设备的基站。此时锚基站可以基于接收到来自用户设备的消息3来确认找到用户设备。消息3是用户设备发起随机接入以转换到rrc_connected过程中的第三条消息，由于其中包括了发送方的id，收到它的基站可以确认用户设备成功的被找到。本实施例中用户设备原本为rrc_inactive，消息3可以为rrc连接恢复请求。

如果用户设备没有驻留在锚基站，则会启动随机接入以恢复与其驻留的基站的连接。驻留的基站不是锚基站，可能没有保存用户设备的上下文，在收到消息3后需要向锚基站发送取回用户设备上下文请求来获取上下文。取回用户设备上下文请求隐性的指示了用户设备已经被找到。

如果驻留的基站保存了用户设备的上下文，则可以选择在收到消息3和/或恢复与用户设备的连接之后向锚基站发送寻呼响应消息以显性地指示用户设备被找到。

s23：至少向通知区中除找到用户设备的基站之外的其他基站发送寻呼终止消息。

寻呼终止消息用于通知其他基站停止发送寻呼消息。锚基站自身也会停止发送寻呼消息。如果找到用户设备的基站不是锚基站自身，锚基站可以向其发送寻呼终止消息，也可以不发送。

通过本实施例的实施，锚基站在确认用户设备被找到后至少向跟踪区中除找到该用户设备的基站之外的其他基站发送寻呼终止消息以通知其停止发送寻呼消息，其他基站不会继续发送不必要的寻呼消息，从而减少无线资源的浪费。

如果基站是以响应驱动的方式进行寻呼，由于寻呼消息中可以包括寻呼指示，每个寻呼指示对应一组用户设备，每组用户设备的数量大于或者等于一，有可能出现误报(即收到pi但未被寻呼的用户设备仍会响应基站)，如果基站能够停止发送寻呼指示，则减少浪费的无线资源中除了基站发送寻呼消息的下行资源之外，还包括用户设备误报所消耗的上行资源。

如图4所示，本发明寻呼方法第四实施例，是在本发明寻呼方法第三实施例的基础上，至少部分寻呼通知中包括寻呼延迟信元。本实施例是对本发明寻呼方法第三实施例的进一步扩展，因此与本发明寻呼方法第三实施例相同的内容在此不再赘述。本实施例包括：

s200：至少根据用户设备的信息评估用户设备驻留在通知区中的小区的概率。

s201：发送寻呼消息并至少向低概率基站发送包括寻呼延迟信元的寻呼通知。

驻留概率、低概率基站和寻呼延迟信元的具体描述可参考本发明寻呼方法第二实施例中的相关内容，在此不再重复。

s202：确认用户设备被找到。

s203：至少向通知区中除找到用户设备的基站之外的其他基站发送寻呼终止消息。

在其他实施例中，锚基站也可以不配置寻呼延迟信元，此时所有的寻呼通知中可以均不包括寻呼延迟信元。例如被寻呼的用户设备对系统延迟要求较高时，为避免寻呼延迟信元可能对寻呼时间造成的影响，锚基站可以选择直接发送所有的寻呼通知而不配置寻呼延迟信元。

本发明寻呼方法第五实施例的执行主体为基站，且不是用户设备所在的通知区的锚基站。如图5所示，本实施例包括：

s31：接收来自于核心网或锚基站的寻呼通知。

寻呼通知用于通知基站发送寻呼消息以寻呼用户设备。寻呼通知中可以包括寻呼延迟信元，也可以不包括。

s32：响应寻呼通知发送寻呼消息以寻呼用户设备。

基站可以将传统的寻呼直接应用到波束扫描来发送寻呼消息，也可以以新的方式(例如响应驱动)发送寻呼消息，在此不做限制。

如果寻呼通知中包括了寻呼延迟信元，则基站需要推迟由寻呼延迟信元指示的指定时长发送寻呼消息。

s33：未找到用户设备时接收到来自于核心网或锚基站的寻呼终止消息。

意味着用户设备没有驻留在本基站的小区且已经被找到，继续发送寻呼消息也不可能找到用户设备，寻呼消息已经失效。

s34：响应寻呼终止消息停止发送寻呼消息。

具体内容可参考前述实施例的描述。

通过本实施例的实施，核心网/锚基站在确认用户设备被找到后至少向跟踪区/通知区中除找到该用户设备的基站之外的其他基站发送寻呼终止消息以通知其停止发送寻呼消息，其他基站不会继续发送不必要的寻呼消息，从而减少无线资源的浪费。

如图6所示，本发明寻呼方法第六实施例，是在本发明寻呼方法第五实施例的基础上，s32之后进一步包括：

s35：找到用户设备后向核心网发送寻呼响应消息或向锚基站发送取回用户设备上下文请求。

找到用户设备后可以包括接收来自于用户设备的消息3和/或与用户设备建立连接。消息3可以为rrc连接请求消息或rrc连接恢复请求。具体内容可参考前述实施例的描述。

下面结合附图举例说明具体的信令交互过程，与前述实施例相同的部分不再重复。

如图7所示，本发明寻呼方法第七实施例中，寻呼由核心网启动，发给基站3的寻呼通知中包括寻呼延迟信元，且核心网在收到来自于找到用户设备的基站(基站1)的第二寻呼响应消息之后发送寻呼终止消息。为了便于示意，图中只画出了1、2、3共三个基站，实际基站数量可以更多或更少；同时没有找到用户设备的基站(基站2和3)可能的寻呼消息的发送过程也未画出。本实施例包括：

s111：核心网向基站1、2和3发送寻呼通知。

寻呼通知的发送顺序仅为示意。发给基站3的寻呼通知中包括寻呼延迟信元。

s112：基站1以波束扫描方式发送寻呼消息。

可以是将传统的寻呼直接应用到波束扫描，也可以采用新的方式，具体发送过程省略。

s113：用户设备向基站1发送消息1.物理随机接入信道(physicalrandomaccesschannel，prach)前导(preamble)。

启动随机接入。

s114：基站1向用户设备发送消息2.随机接入响应(randomaccessresponse，rar)。

s115：用户设备向基站1发送消息3.rrc连接请求。

s116：基站1向用户设备发送消息4.rrc连接建立。

之后用户设备从rrc_idle转换为rrc_connected。

s117：用户设备向基站1发送消息5.rrc连接建立完成。

s118：基站1向核心网发送第二寻呼响应消息。

s119：核心网向基站2和3发送寻呼终止消息。

寻呼终止消息的发送顺序仅为示意。

如图8所示，本发明寻呼方法第八实施例中，寻呼由核心网启动，发给基站3的寻呼通知中包括寻呼延迟信元，且核心网在收到来自于找到用户设备的基站(基站1)的第一寻呼响应消息之后发送寻呼终止消息。本实施例与图7对应的实施例的区别为基站1发送第一寻呼响应消息而不是第二寻呼响应消息，相同的部分不再重复。本实施例包括：

s121：核心网向基站1、2和3发送寻呼通知。

s122：基站1以波束扫描方式发送寻呼消息。

s123：用户设备向基站1发送消息1.物理随机接入信道(physicalrandomaccesschannel，prach)前导(preamble)。

s124：基站1向用户设备发送消息2.随机接入响应(randomaccessresponse，rar)。

s125：用户设备向基站1发送消息3.rrc连接请求。

s126：基站1向核心网发送第一寻呼响应消息。

s127：核心网向基站2和3发送寻呼终止消息。

s128：基站1向用户设备发送消息4.rrc连接建立。

s129：用户设备向基站1发送消息5.rrc连接建立完成。

s127在s126之后执行，s129在s128之后执行，s126/s127与s128/s129之间的执行顺序并无限制。

如图9所示，本发明寻呼方法第九实施例中，寻呼由接入网启动，锚基站(基站1)发给基站3的寻呼通知中包括寻呼延迟信元，且用户设备驻留在锚基站。为了便于示意，图中只画出了1、2、3共三个基站，实际基站数量可以更多或更少；同时没有找到用户设备的基站(基站2和3)可能的寻呼消息的发送过程也未画出。本实施例包括：

s131：基站1向基站2和3发送寻呼通知。

寻呼通知的发送顺序仅为示意。发给基站3的寻呼通知中包括寻呼延迟信元。

s132：基站1以波束扫描方式发送寻呼消息。

s131和s132的先后顺序仅为示意。

可以是将传统的寻呼直接应用到波束扫描，也可以采用新的方式，具体发送过程省略。

s133：用户设备向基站1发送消息1.物理随机接入信道(physicalrandomaccesschannel，prach)前导(preamble)。

启动随机接入。

s134：基站1向用户设备发送消息2.随机接入响应(randomaccessresponse，rar)。

s135：用户设备向基站1发送消息3.rrc连接恢复请求。

s136：基站1向基站2和3发送寻呼终止消息。

寻呼终止消息的发送顺序仅为示意。本步骤与s137/s138之间的执行顺序仅为示意。

s137：基站1向用户设备发送消息4.rrc连接恢复。

之后用户设备从rrc_inactive转换为rrc_connected。

s138：用户设备向基站1发送消息5.rrc连接恢复完成。

如图10所示，本发明寻呼方法第十实施例中，寻呼由接入网启动，锚基站(基站1)发给基站3的寻呼通知中包括寻呼延迟信元，且用户设备驻留在非锚基站(基站2)。本实施例与图9对应的实施例的区别为用户设备驻留的基站不同，相同的部分不再重复。本实施例包括：

s141：基站1向基站2和3发送寻呼通知。

s142：基站2以波束扫描方式发送寻呼消息。

可以是将传统的寻呼直接应用到波束扫描，也可以采用新的方式，具体发送过程省略。

s143：用户设备向基站2发送消息1.物理随机接入信道(physicalrandomaccesschannel，prach)前导(preamble)。

启动随机接入。

s144：基站2向用户设备发送消息2.随机接入响应(randomaccessresponse，rar)。

s145：用户设备向基站2发送消息3.rrc连接恢复请求。

s146：基站2向基站1发送取回用户设备上下文请求。

基站2没有保存用户设备的上下文。

s147：基站1向基站2发送取回用户设备上下文响应。

其中包括用户设备的上下文。

s148：基站1向基站3发送寻呼终止消息。

寻呼终止消息的发送顺序仅为示意。本步骤与s147/s149之间的执行顺序仅为示意。

s149：基站2向用户设备发送消息4.rrc连接恢复。

之后用户设备从rrc_inactive转换为rrc_connected。

s150：用户设备向基站2发送消息5.rrc连接恢复完成。

如图11所示，本发明寻呼装置第一实施例包括：处理器110和通信电路120，处理器110连接通信电路120。

通信电路120用于发送和接收用户数据，是寻呼装置与其他通信设备进行通信的接口。

处理器110控制寻呼装置的操作，处理器110还可以称为cpu(centralprocessingunit，中央处理单元)。处理器110可能是一种集成电路芯片，具有信号的处理能力。处理器110还可以是通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现成可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

处理器110用于执行指令以实现本发明寻呼方法第一或第二实施例所提供的方法。

本实施例中的寻呼装置可以是核心网。

如图12所示，本发明寻呼装置第二实施例包括：处理器210和通信电路220，处理器210连接通信电路220。

通信电路220用于发送和接收用户数据，是寻呼装置与其他通信设备进行通信的接口。

处理器210控制寻呼装置的操作，处理器210还可以称为cpu(centralprocessingunit，中央处理单元)。处理器210可能是一种集成电路芯片，具有信号的处理能力。处理器210还可以是通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现成可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

处理器210用于执行指令以实现本发明寻呼方法第三至第六实施例中任一个以及任意不冲突的组合所提供的方法。

本实施例中的寻呼装置可以是基站，也可以是可集成于基站中的独立部件，例如基带板。

如图13所示，本发明可读存储介质第一实施例包括存储器310，存储器310存储有指令，该指令被执行时实现本发明寻呼方法第一或第二施例所提供的方法。

存储器310可以包括只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、闪存(flashmemory)、硬盘、光盘等。

本实施例中的可读存储介质可以是独立部件，也可以集成于核心网。

如图14所示，本发明可读存储介质第二实施例包括存储器410，存储器410存储有指令，该指令被执行时实现本发明寻呼方法第三至第六实施例中任一个以及任意不冲突的组合所提供的方法。

存储器410可以包括只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、闪存(flashmemory)、硬盘、光盘等。

本实施例中的可读存储介质可以是独立部件，也可以集成于基站，或者基站中的部件，例如基带板。

在本发明所提供的几个实施例中，应该理解到，所揭露的方法和装置，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施方式所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本发明的实施方式，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。