CN114698100A - 寻呼原因发送及获取方法、装置、介质 - Google Patents

Abstract

一种寻呼原因发送及获取方法、装置、介质，所述方法包括：确定需要指示寻呼原因M的目标用户设备；发送寻呼消息，所述寻呼消息包含所述寻呼原因M和所述目标用户设备的标识信息。上述方案在实现指示寻呼原因及其对应类型的同时，降低所需增加寻呼消息的信息量。

Description

寻呼原因发送及获取方法、装置、介质

技术领域

本发明涉及无线通信技术领域，尤其涉及一种寻呼原因发送及获取方法、装置、介质。

背景技术

随着通信技术的发展，越来越多的用户使用多卡多待用户设备(User Equipment，UE)，来满足不同的通信需求。常见的多卡多待用户设备为双卡双待用户设备，两张USIM卡可以属于相同的电信运营商，也可以属于不同的电信运营商。

双卡双待用户设备中，两张USIM卡通常共享同一套射频和基带器件，不可避免的带来如下问题：当一张USIM卡处于通信状态时，另一张USIM卡也需要监听寻呼消息、进行小区测量等操作，甚至可能需要断开处于通信状态的USIM卡正在进行的业务，进行另一张USIM卡的寻呼消息监听。

针对于上述问题，现有技术中，当USIM卡1与网络A处于连接状态时，USIM卡2周期性监听网络B的寻呼消息，根据寻呼原因确定是否相应网络B的寻呼消息。

基站通知用户设备寻呼原因是有意义且必要的。现有技术中，是在寻呼消息中增加一个寻呼原因(paging cause)字段。然而，在LTE***中，一个寻呼消息最多携带16个寻呼记录(paging record)，如果每一个寻呼记录都携带寻呼原因的话，假如有5个寻呼原因，则需要3个bit指示寻呼原因，那么，16个寻呼记录总共需要48个bit；在NR***中，一个寻呼消息最多可以携带32个寻呼记录，那么，一个寻呼消息因为携带寻呼原因，需要增加96bits，并且，NR***中寻呼消息需要在多个波束(beam)中重复发送。

可见，现有技术中，由于增加寻呼原因，导致寻呼消息的信息量大大增加。

发明内容

本发明实施例解决的是因增加寻呼原因所带来的寻呼消息的信息量增加。

为解决上述技术问题，本发明实施例提供一种寻呼原因发送方法，包括：确定需要指示寻呼原因M的目标用户设备；其中，所述寻呼原因M是N个寻呼原因中的一个；发送寻呼消息，所述寻呼消息包含所述寻呼原因M和所述目标用户设备的标识信息。

可选的，所述确定需要指示寻呼原因M的目标用户设备，包括：确定需要指示所述寻呼原因M的目标用户设备的个数。

可选的，在发送寻呼消息之前，还包括：发送下行控制信息，所述下行控制信息用于调度所述寻呼消息，且所述下行控制信息包含所述目标用户设备的个数。

可选的，所述寻呼消息包含X个用户设备的标识信息，所述目标用户设备的个数为K；所述K个目标用户设备的标识信息位于所述X个用户设备的标识信息最前面，或位于所述X个用户设备的标识信息最后面。

可选的，所述寻呼原因发送方法还包括：指示所述寻呼消息中是否携带寻呼原因M。

可选的，所述指示所述寻呼消息中是否携带寻呼原因M，包括：配置所述寻呼消息中是否携带寻呼原因M。

可选的，所述寻呼消息还包括寻呼原因指示信息，所述寻呼原因指示信息用于指示所述寻呼消息是否包含寻呼原因M。

可选的，所述指示所述寻呼消息中是否携带寻呼原因M，包括：通过高层信令指示所述寻呼消息中是否携带寻呼原因M。

可选的，所述指示所述寻呼消息中是否携带寻呼原因M，包括：通过下行控制信息中的一个bit，指示所述寻呼消息中是否携带寻呼原因M。

可选的，所述下行控制信息中的一个bit为短消息中的一个bit。

可选的，所述寻呼原因发送方法还包括：当所述寻呼消息中携带有寻呼原因M时，指示所述寻呼原因M的具体类型。

可选的，所述指示所述寻呼原因的具体类型，包括：在所述寻呼消息中增加第二指示字段，所述第二指示字段的取值用于表征所述寻呼原因的类型。

可选的，所述指示所述寻呼原因的类型，包括：通过高层信令向用户设备指示所述寻呼原因的类型。

可选的，所述指示所述寻呼原因的类型，包括：通过所述预留比特位分成第一部分以及第二部分，且所述第一部分用于指示所述寻呼记录列表中目标用户设备的个数，所述第二部分用于指示所述寻呼原因的类型。

可选的，所述发送寻呼消息，包括：在所述寻呼消息中增加新的寻呼记录列表，且所述新的寻呼记录列表中的寻呼记录存在对应寻呼原因，已有的寻呼记录列表中的寻呼记录不存在对应寻呼原因。

可选的，所述寻呼原因发送方法还包括：配置所述寻呼消息中是否携带所述新的寻呼记录列表。

为解决上述技术问题，本发明实施例还提供了一种寻呼原因获取方法，包括：接收基站下发的寻呼消息，所述寻呼消息中包含寻呼原因M和目标用户设备的标识信息，所述目标用户设备为所述基站确定需要指示寻呼原因M的用户设备，所述寻呼原因M是N个寻呼原因中的一个。

可选的，在接收所述寻呼消息之前，还包括：接收下行控制信息，所述下行控制信息用于调度所述寻呼消息，且所述下行控制信息包含所述目标用户设备的个数。

可选的，所述寻呼消息包含X个用户设备的标识信息，所述目标用户设备的个数为K；所述K个目标用户设备的标识信息位于所述X个用户设备的标识信息最前面，或位于所述X个用户设备的标识信息最后面。

可选的，所述寻呼原因获取方法还包括：获取寻呼原因指示消息，所述寻呼原因指示消息用于指示所述寻呼消息中是否携带寻呼原因M。

可选的，所述获取寻呼原因指示消息，包括：从所述寻呼消息中获取所述寻呼原因指示信息。

可选的，所述获取寻呼原因指示消息，包括：接收所述基站下发的高层信令，所述高层信令中携带有所述寻呼原因指示信息。

可选的，所述获取寻呼原因指示消息，包括：接收所述基站下发的下行控制信息，所述下行控制信息中携带有所述寻呼原因指示信息。

可选的，所述寻呼原因指示信息为所述下行控制信息中短消息的一个bit。

可选的，所述寻呼原因获取方法还包括：获取寻呼原因的类型。

可选的，所述获取寻呼原因的类型，包括：读取所述寻呼消息中的第二指示字段，所述第二指示字段的取值用于表征所述寻呼原因的类型。

可选的，所述获取寻呼原因的类型，包括：接收所述基站下发的高层信令，所述高层信令中携带有所述寻呼原因的类型。

可选的，所述获取寻呼原因的类型，包括：获取预留比特位的取值，所述预留比特位包括第一部分以及第二部分，且所述第一部分用于指示所述寻呼记录列表中目标用户设备的个数，所述第二部分用于指示所述寻呼原因的类型。

可选的，所述接收基站下发的寻呼消息，包括：从所述寻呼消息中获取新的寻呼记录列表，且所述新的寻呼记录列表中的寻呼记录存在对应寻呼原因，已有的寻呼记录列表中的寻呼记录不存在对应寻呼原因。

可选的，所述寻呼原因获取方法还包括：接收寻呼记录列表指示信息，所述寻呼记录列表指示信息用于指示所述寻呼消息是否携带所述新的寻呼记录列表。

本发明实施例还提供了一种寻呼原因发送装置，包括：确定单元，用于确定需要指示寻呼原因M的目标用户设备；其中，所述寻呼原因M是N个寻呼原因中的一个；发送单元，用于发送寻呼消息，所述寻呼消息中包含所述寻呼原因M和所述目标用户设备的标识信息。

本发明实施例还提供了一种寻呼原因获取装置，包括：接收单元，用于接收基站下发的寻呼消息，所述寻呼消息中包含寻呼原因和目标用户设备的标识信息，所述目标用户设备为所述基站确定需要指示寻呼原因M的用户设备，所述寻呼原因M是N个寻呼原因中的一个。

本发明实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质为非易失性存储介质或非瞬态存储介质，其上存储有计算机程序，所述计算机程序被处理器运行时执行上述任一种所述的寻呼原因发送方法的步骤。

本发明实施例还提供了另一种计算机可读存储介质，所述计算机可读存储介质为非易失性存储介质或非瞬态存储介质，其上存储有计算机程序，所述计算机程序被处理器运行时执行上述任一种所述的寻呼原因获取方法的步骤。

本发明实施例还提供了另一种寻呼原因发送装置，包括存储器和处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器运行所述计算机程序时执行上述任一种所述的寻呼原因发送方法的步骤。

本发明实施例还提供了另一种寻呼原因获取装置，包括存储器和处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器运行所述计算机程序时执行上述任一种所述的寻呼原因获取方法的步骤。

与现有技术相比，本发明实施例的技术方案具有以下有益效果：

确定需要指示寻呼原因M的目标设备，向用户设备发送寻呼消息，在寻呼消息中携带有寻呼原因M以及目标用户设备的标识信息。仅增加需要指示寻呼原因M及寻呼原因M对应的目标用户设备的标识信息，而不是增加所有寻呼原因及所有寻呼原因对应的用户设备的标识信息，可以降低因增加寻呼原因所带来的寻呼消息的信息量的增加量。

进一步，在确定需要指示寻呼原因M的目标用户设备后，发送用于调度寻呼消息的下行控制信息。下行控制信息包含目标用户设备的个数，通过下行控制信息中预留比特位的取值来指示目标用户设备的个数。通过预先约定预留比特位对应的寻呼原因的类型，在实现指示寻呼原因及其对应类型的同时，无需额外增加寻呼消息的信息量。

附图说明

图1是本发明实施例中的一种寻呼原因发送方法的流程图；

图2是本发明实施例中的一种寻呼原因获取方法的流程图；

图3是本发明实施例中的一种寻呼原因发送装置的结构示意图；

图4是本发明实施例中的一种寻呼原因获取装置的结构示意图。

具体实施方式

如上所述，现有技术中，在寻呼消息中增加一个寻呼原因(paging cause)字段。在LTE***中，一个寻呼消息最多携带16个寻呼记录(paging record)，如果每一个寻呼记录都携带寻呼原因的话，假如有5个寻呼原因，则需要3个bit指示寻呼原因，那么，16个寻呼记录总共需要48个bit；在NR***中，一个寻呼消息最多可以携带32个寻呼记录，那么，一个寻呼消息因为携带寻呼原因，需要增加96bits，并且，NR***中寻呼消息需要在多个波束(beam)中重复发送。

可见，现有技术中，由于增加寻呼原因，导致寻呼消息的信息量大大增加。

在本发明实施例中，确定需要指示寻呼原因M的目标设备，向用户设备发送寻呼消息，在寻呼消息中携带有寻呼原因M以及目标用户设备的标识信息。仅增加需要指示寻呼原因M及寻呼原因M对应的目标用户设备的标识信息，而不是增加所有寻呼原因及所有寻呼原因对应的用户设备的标识信息，可以降低因增加寻呼原因所带来的寻呼消息的信息量的增加量。

为使本发明的上述目的、特征和有益效果能够更为明显易懂，下面结合附图对本发明的具体实施例做详细的说明。

本发明实施例提供了一种寻呼原因发送方法，参照图1，以下通过具体步骤进行详细说明。

在具体实施中，下述步骤S101～步骤S102所提供的寻呼原因发送方法可以由基站设备中的控制芯片执行，也可以由基站设备中包括控制芯片的芯片模组执行，或者由基站设备所执行。

步骤S101，确定需要指示寻呼原因M的目标用户设备。

在具体实施中，寻呼原因M可以是N个寻呼原因中的一个。

在具体应用中，寻呼原因指的是发起寻呼的原因，其由paging cause翻译而来，寻呼原因与寻呼消息类型(paging category)的意义大致相同。若无特殊说明，上述标识可以等同。

在现有协议中，N个寻呼原因可以包括语音服务(voice service)、信息发送服务(messaging serveice)、关键服务(critical service)、CP signaling、其他服务(otherservice)等。当然，寻呼原因也可以随着通信技术的发展而不断更新。

在具体实施中，基站可以确定哪些用户设备需要指示寻呼原因。在本发明实施例中，为便于表述，将需要指示寻呼原因的用户设备简称为目标用户设备。基站在确定了目标用户设备后，可以统计目标用户设备的个数。

在本发明实施例中，目标用户设备可以为寻呼原因相同的用户设备。换而言之，目标用户设备的个数可以为多个，且每一个目标用户设备对应的寻呼原因相同。

步骤S102，发送寻呼消息。

在具体实施中，寻呼消息中可以包括寻呼原因M以及目标用户设备的标识信息。

在本发明实施例中，在发送寻呼消息之前，还可以向用户设备发送下行控制信息，该下行控制信息用于调度上述的寻呼消息，且在下行控制信息中携带有目标用户设备的个数。

根据现有的NR协议可知，寻呼消息(paging message)由P-RNTI加扰的下行控制信息(Downlink Control Information，DCI)格式format 1_0的PDCCH承载或调度的，并且，其中由6～8bits的预留比特位，且预留比特位同样会传输。通常情况下，预留比特位设置为全0。

在本发明实施例中，基站在确定目标用户设备的个数之后，可以在用于调度寻呼消息的P-RNTI加扰的DCI中，将预留比特位用于指示目标用户设备的个数。

例如，寻呼原因M为寻呼原因1。若某次寻呼消息包含10个寻呼记录(pagingrecord)，且每个寻呼记录均对应寻呼原因1。由于十进制数10对应二进制数1010，因此，用于调度寻呼消息的P-RNTI加扰的DCI中的预留比特位中的四个比特(比如，可以是预留比特位中的高四比特，或者预留比特位中的低四比特，或者预留比特位中的中间四比特，本发明实施例不对具体的比特位置进行限定)的值可以设定为1010。

在现有的寻呼消息中，其中包括寻呼记录列表(paging record list)，寻呼记录列表中包括多个用户设备对应寻呼记录，但是并没有携带寻呼原因。例如，在NR***中，寻呼记录列表中最多可以包括32个用户设备对应的寻呼记录。

在本发明实施例中，可以规定存在对应寻呼原因(paging cause)的寻呼记录放在寻呼记录列表中的前一部分，不存在对应寻呼原因的寻呼记录放在寻呼记录列表中的后一部分；或者，规定存在对应寻呼原因的寻呼记录防止寻呼记录列表中的后一部分，不存在对应寻呼原因的寻呼记录放在寻呼记录列表中的前一部分。

也就是说，在寻呼记录列表中，存在对应寻呼原因的寻呼记录与不存在寻呼原因的寻呼记录分成两个部分，且两个部分相互独立。在具体实施中，可以预先定义存在对应寻呼原因的寻呼记录在寻呼记录列表中的位置，用户设备在接收到用于调度寻呼消息的P-RNTI加扰的下行控制信息时，即可根据其对应的寻呼记录在寻呼记录列表中的位置，确定是否存在寻呼原因，以及寻呼原因的类型。

继续以上述的10个寻呼记录均对应寻呼原因1的示例进行说明。在寻呼记录列表中，包含32个寻呼记录，其中，前10个寻呼记录存在对应的寻呼原因1，后22个寻呼记录不存在对应的寻呼原因。

在具体实施中，若用于调度寻呼消息的P-RNTI加扰的下行控制信息的预留比特位的取值为全0，则表明当前的寻呼消息中没有包含存在对应寻呼原因的寻呼记录。

现有技术中，假设某次寻呼消息包含10个寻呼记录，如果每个寻呼记录都包含寻呼原因1，则依据现有技术中，寻呼原因均需要在寻呼记录中指示，那么，在寻呼消息中需要增加30bits。

又如，假设某次寻呼消息包含32个寻呼记录，如果每个寻呼记录都包含寻呼原因1，则依据现有技术中，寻呼原因均需要在寻呼记录中指示，那么，在寻呼消息中需要增加96bits。

而在本发明实施例中，若某次寻呼消息包含10个寻呼记录，且每个寻呼记录均对应寻呼原因1，则在寻呼消息中，无需增加任何bit，只需要使用用于调度寻呼消息的P-RNTI加扰PDCCH的DCI中预留的比特即可。由于十进制数10对应二进制数1010，因此，用于调度寻呼消息的P-RNTI加扰PDCCH的DCI中的预留比特位的取值可以为1010(具体使用预留比特位中的哪些比特位，本发明不做限制)。

由此可见，采用本发明实施例中提供的寻呼原因发送方法，能够大大减小寻呼消息中用于指示寻呼记录的比特个数，降低寻呼消息的开销。

在具体实施中，基站可以指示寻呼消息中是否携带有寻呼原因M。具体而言，基站可以配置寻呼消息中是否携带寻呼原因M。

在本发明实施例中，基站可以指示寻呼消息中是否携带有寻呼原因M。基站可以在寻呼消息中增加第一指示字段，通过第一指示字段的取值来表征寻呼消息中是否携带寻呼原因M。

例如，在寻呼消息中，增加第一指示字段，第一指示字段的长度为1bit，当第一指示字段的取值为1时，表征寻呼消息中携带寻呼原因M；反之，当第一指示字段的取值为0时，表征寻呼消息中未携带寻呼原因M。

在具体实施中，基站也可以通过高层信令向用户设备指示寻呼消息中是否携带寻呼原因M。

例如，基站可以通过公共消息(如***消息)等，配置指示寻呼消息中是否携带寻呼原因M，之后，基站将所配置的公共消息广播。

又如，基站可以通过无线资源控制(Radio Resource Control，RRC)专用信令分别向用户设备发送指示信息，以指示寻呼消息中是否携带寻呼原因M。

在具体实施中，基站也可以通过用于调度寻呼消息的P-RNTI加扰的下行控制信息中的一个bit，来指示寻呼消息中是否携带寻呼原因M。

在本发明实施例中，用于调度寻呼消息的P-RNTI加扰的下行控制信息中的一个bit，可以为用于调度寻呼消息的P-RNTI加扰的下行控制信息中，短信息(short message)中的一个bit。

可以理解的是，若寻呼消息中未携带寻呼原因M，则基站可以不用进行指示，以降低基站的下行开销。

在本发明上述实施例中，默认目标用户设备对应的寻呼原因相同，且仅针对于某一种寻呼原因时，使用预留比特位来指示目标用户设备的个数。因此，无需再指示寻呼原因对应的类型。

例如，设定寻呼原因M为语音服务时，使用预留比特位来指示目标用户设备的个数。因此，当预留比特位的取值不是全0时，意味着有目标用户设备被指示寻呼原因M为语音服务。

然而，在实际应用中，针对不同的用户设备，其对应的寻呼原因的种类可以不同。例如，在一次寻呼消息中，用户设备1～用户设备4对应的寻呼原因为语音服务(voiceservice)，用户设备5～用户设备10对应的寻呼原因为信息发送服务(messagingserveice)。

在本发明实施例中，当存在Y种不同的寻呼原因时，其中的一种寻呼原因可以采用本发明上述实施例中提供的寻呼原因发送方法进行发送，另外Y-1种寻呼原因在寻呼记录中携带。

例如，使用用于调度寻呼消息的P-RNTI加扰的下行控制信息中的预留比特位指示用户设备1～用户设备4对应的寻呼原因为语音服务(voice service)，采用现有协议中规定的技术方案指示用户设备5～用户设备10对应的寻呼原因为信息发送服务(messagingserveice)。

假设总共存在5个寻呼原因，则每一个寻呼原因需要3bit指示。某次寻呼消息中包含10个寻呼记录，前面4个寻呼记录对应寻呼原因1，后面6个寻呼记录对应寻呼原因2。

若完全依据现有技术中提供的技术方案，则需要在寻呼消息中增加10×3＝30bits。

而采用本发明实施例中提供的技术方案，由于寻呼原因1由预留比特位隐含承载，因此，剩余的4个寻呼原因的指示只是需要2bit即可完成。使用预留比特位隐含指示用户设备1～用户设备4对应的寻呼原因为寻呼原因1，在寻呼消息中，只需要增加6×2＝12bit即可。相比于现有技术中需要增加30bit，本发明实施例中提供的技术方案大大降低了寻呼消息的长度。

在本发明上述实施例中，默认预留比特位对应的寻呼原因是固定的。在本发明下一实施例中，也可以定义预留比特位对应的寻呼原因是可变的。

在具体实施中，基站可以在寻呼消息中增加第二指示字段，通过第二指示字段的取值表征预留比特位对应的寻呼原因的类型。

例如，寻呼原因的类型为5种，则需要3bit进行指示。因此，在寻呼消息中，增加第二指示字段，第二指示字段的长度为3bit，当第二指示字段的取值为001时，表征寻呼消息中携带寻呼原因1；当第二指示字段的取值为010时，表征寻呼消息中携带寻呼原因2，以此类推。

在具体实施中，基站也可以通过高层信令向用户设备指示预留比特位对应的寻呼原因的类型。

例如，基站可以通过公共消息(如***消息)等，配置指示预留比特位对应的寻呼原因的类型为寻呼原因2，之后，基站将所配置的公共消息广播。

又如，基站可以通过无线资源控制(Radio Resource Control，RRC)专用信令分别向用户设备发送指示信息，以指示预留比特位对应的寻呼原因的类型为寻呼原因2。

在具体实施中，基站也可以将预留比特位分成第一部分以及第二部分，其中第一部分用于指示寻呼记录列表中目标用户设备的个数，第二部分用于指示寻呼原因的具体类型。

例如，预留比特位为6位，前4位用于指示目标用户设备的个数，后2位用于指示寻呼原因的类型。

在具体实施中，还可以在现有的寻呼消息中，新增一个寻呼记录列表，新的寻呼记录列表中携带存在寻呼原因的寻呼记录，原有的寻呼记录列表中的寻呼记录不存在寻呼原因。

在具体实施中，可以配置寻呼消息中是否携带新的寻呼记录列表。

在实际应用中可知，P-RNTI为paging RNTI，用于解析对应的寻呼控制信道(Paging Control Channel，PCCH)，RNTI为无线网络临时标识(Radio Network TemporaryIdentity)的简写。PDCCH为物理下行控制信道(Physical Downlink Control Channel)的简写。

参照图2，本发明实施例还提供了一种寻呼原因获取方法，下面通过具体步骤进行说明。

在具体实施中，下述步骤S201所提供的寻呼原因获取方法可以由用户设备中的基带芯片执行，也可以由用户设备中包括基带芯片的芯片模组执行，或者由用户设备所执行。

步骤S201，接收基站下发的寻呼消息。

在具体实施中，寻呼消息中可以包括寻呼原因M以及目标用户设备的标识信息，目标用户设备可以为基站确定的需要指示寻呼原因M的用户设备，且寻呼原因M与N个寻呼原因中的一个。

在具体实施中，用户设备在接收寻呼消息之前，还可以先接收基站下发的用于调度寻呼消息的下行控制信息，且下行控制信息中携带有目标用户设备的个数。

根据现有的NR协议可知，寻呼消息(paging message)由P-RNTI加扰的下行控制信息(Downlink Control Information，DCI)格式format 1_0的PDCCH承载或调度的，并且，其中由6～8bits的预留比特位，且预留比特位同样会传输。通常情况下，预留比特位设置为全0。

在本发明实施例中，基站在确定目标用户设备的个数之后，可以在用于调度寻呼消息的P-RNTI加扰的DCI中，将预留比特位用于指示目标用户设备的个数。

例如，寻呼原因M为寻呼原因1。若某次寻呼消息包含10个寻呼记录(pagingrecord)，且每个寻呼记录均对应寻呼原因1。由于十进制数10对应二进制数1010，因此，用于调度寻呼消息的P-RNTI加扰的DCI中的预留比特位的值可以设定为1010(具体使用预留比特位中的哪些比特位，本发明不做限定)。

在现有的寻呼消息中，其中包括寻呼记录列表(paging record list)，寻呼记录列表中包括多个用户设备对应寻呼记录，但是并没有携带寻呼原因。例如，在NR***中，寻呼记录列表中最多可以包括32个用户设备对应的寻呼记录。

在本发明实施例中，可以规定存在对应寻呼原因(paging cause)的寻呼记录放在寻呼记录列表中的前一部分，不存在对应寻呼原因的寻呼记录放在寻呼记录列表中的后一部分；或者，规定存在对应寻呼原因的寻呼记录防止寻呼记录列表中的后一部分，不存在对应寻呼原因的寻呼记录放在寻呼记录列表中的前一部分。

也就是说，在寻呼记录列表中，存在对应寻呼原因的寻呼记录与不存在寻呼原因的寻呼记录分成两个部分，且两个部分相互独立。在具体实施中，可以预先定义存在对应寻呼原因的寻呼记录在寻呼记录列表中的位置，用户设备在接收到用于调度寻呼消息的P-RNTI加扰的下行控制信息时，即可根据其对应的寻呼记录在寻呼记录列表中的位置，确定是否存在寻呼原因，以及寻呼原因的类型。

换而言之，设定寻呼消息包括X个用户设备的标识信息，目标用户设备的个数为K，K个目标用户设备的标识信息可以位于X个用户设备的标识信息最前面，或者位于X个用户设备的标识信息的最后面。

在具体实施中，基站可以指示寻呼消息中是否携带有寻呼原因M。具体而言，基站可以配置寻呼消息中是否携带寻呼原因M。

在本发明实施例中，基站可以指示寻呼消息中是否携带有寻呼原因M。基站可以在寻呼消息中增加第一指示字段，通过第一指示字段的取值来表征寻呼消息中是否携带寻呼原因M。

例如，在寻呼消息中，增加第一指示字段，第一指示字段的长度为1bit，当第一指示字段的取值为1时，表征寻呼消息中携带寻呼原因M；反之，当第一指示字段的取值为0时，表征寻呼消息中未携带寻呼原因M。

在具体实施中，基站也可以通过高层信令向用户设备指示寻呼消息中是否携带寻呼原因M。

例如，基站可以通过公共消息(如***消息)等，配置指示寻呼消息中是否携带寻呼原因M，之后，基站将所配置的公共消息广播。

又如，基站可以通过无线资源控制(Radio Resource Control，RRC)专用信令分别向用户设备发送指示信息，以指示寻呼消息中是否携带寻呼原因M。

在具体实施中，基站也可以通过用于调度寻呼消息的P-RNTI加扰的下行控制信息中的一个bit，来指示寻呼消息中是否携带寻呼原因M。

在本发明实施例中，用于调度寻呼消息的P-RNTI加扰的下行控制信息中的一个bit，可以为用于调度寻呼消息的P-RNTI加扰的下行控制信息中，短信息(short message)中的一个bit。

可以理解的是，若寻呼消息中未携带寻呼原因M，则基站可以不用进行指示，以降低基站的下行开销。

在本发明上述实施例中，默认目标用户设备对应的寻呼原因相同，且仅针对于某一种寻呼原因时，使用预留比特位来指示目标用户设备的个数。因此，无需再指示寻呼原因对应的类型。

在本发明上述实施例中，默认预留比特位对应的寻呼原因是固定的。在本发明下一实施例中，也可以定义预留比特位对应的寻呼原因是可变的。

在具体实施中，基站可以在寻呼消息中增加第二指示字段，通过第二指示字段的取值表征预留比特位对应的寻呼原因的类型。

例如，寻呼原因的类型为5种，则需要3bit进行指示。因此，在寻呼消息中，增加第二指示字段，第二指示字段的长度为3bit，当第二指示字段的取值为001时，表征寻呼消息中携带寻呼原因1；当第二指示字段的取值为010时，表征寻呼消息中携带寻呼原因2，以此类推。

在具体实施中，基站也可以通过高层信令向用户设备指示预留比特位对应的寻呼原因的类型。

例如，基站可以通过公共消息(如***消息)等，配置指示预留比特位对应的寻呼原因的类型为寻呼原因2，之后，基站将所配置的公共消息广播。

又如，基站可以通过无线资源控制(Radio Resource Control，RRC)专用信令分别向用户设备发送指示信息，以指示预留比特位对应的寻呼原因的类型为寻呼原因2。

在具体实施中，基站也可以将预留比特位分成第一部分以及第二部分，其中第一部分用于指示寻呼记录列表中目标用户设备的个数，第二部分用于指示寻呼原因的具体类型。

例如，预留比特位为6位，前4位用于指示目标用户设备的个数，后2位用于指示寻呼原因的类型。

在具体实施中，还可以在现有的寻呼消息中，新增一个寻呼记录列表，新的寻呼记录列表中携带存在寻呼原因的寻呼记录，原有的寻呼记录列表中的寻呼记录不存在寻呼原因。

在具体实施中，可以配置寻呼消息中是否携带新的寻呼记录列表。

在具体实施中，上述步骤S201实质上是由用户设备侧执行的寻呼原因获取方法，上述步骤S101～步骤S102实质上是由基站侧执行的寻呼原因获取方法，二者相互对应。

参照图3，给出了本发明实施例中的一种寻呼原因发送装置30，包括：确定单元301以及发送单元302，其中：

确定单元301，用于确定需要指示寻呼原因M的目标用户设备；其中，所述寻呼原因M是N个寻呼原因中的一个；

发送单元302，用于发送寻呼消息，所述寻呼消息中包含所述寻呼原因M和所述目标用户设备的标识信息。

在具体实施中，确定单元301以及发送单元302的具体执行流程可以对应参照上述步骤S101～步骤S102，本发明实施例此处不做赘述。

在具体实施中，上述的寻呼原因发送装置30可以对应于基站设备中具有数据处理功能的芯片；或者对应于基站设备中包括具有数据处理功能芯片的芯片模组，或者对应于基站设备。

参照图4，给出了本发明实施例中的一种寻呼原因获取装置40，包括：接收单元401：

接收单元401，用于接收基站下发的寻呼消息，所述寻呼消息中包含寻呼原因M和目标用户设备的标识信息，所述目标用户设备为所述基站确定需要指示寻呼原因M的用户设备，所述寻呼原因M是N个寻呼原因中的一个。

在具体实施中，接收单元401的具体执行流程可以对应参照上述步骤S401，本发明实施例此处不做赘述。

在具体实施中，上述的寻呼原因获取装置40可以对应于用户设备中具有数据处理功能的芯片，如基带芯片；或者对应于用户设备中包括具有数据处理功能芯片的芯片模组，或者对应于用户设备。

本发明实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质为非易失性存储介质或非瞬态存储介质，其上存储有计算机程序，所述计算机程序被处理器运行时执行上述任一实施例所提供的寻呼原因发送方法的步骤。

本发明实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质为非易失性存储介质或非瞬态存储介质，其上存储有计算机程序，所述计算机程序被处理器运行时执行上述任一实施例所提供的寻呼原因获取方法的步骤。

本发明实施例还提供了另一种寻呼原因发送装置，包括存储器和处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器运行所述计算机程序时执行上述任一实施例所提供的寻呼原因发送方法的步骤。

本发明实施例还提供了另一种寻呼原因获取装置，包括存储器和处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器运行所述计算机程序时执行上述任一实施例所提供的寻呼原因获取方法的步骤。

LTE时代***消息都是周期性广播的方式发送的，但是，在NR时，因为引入了波束(beam)，不同的beam覆盖不同的波束方向，所以，***消息需要在各个beam都发送。那么，如果***消息也以周期性广播的方式发送的话，需要在每个beam上都周期性的广播发送。这可能带来极大的***开销，资源效率较低。

所以，在NR中，引入on demand的***消息发送方式，也就是，按需的方式发送***消息：***并不周期性的广播发送***消息，如果有UE需求并向网络反馈了其需求，比如通过Msg1，Msg3，或者RRC信令等方式向***发出对于某个SI或者SIB的请求，***就启动对应SI或者SIB的周期性的广播发送，或者以单播的方式向UE发送所请求的SI或者SIB。

为了支持上述on demand的方式发送SI或者SIB，在***消息中除了包含SI与SIB的对应关系(也就是，一个SI包含哪些SIB)，还包括该SI是不是以广播的方式发送的：

上面si-BroadcastStatus字段取值broadcasting时，表明对应的SI是周期性广播的；取值notBroadcasting时，表明对应的SI是以按需的方式发送的。si-BroadcastStatus的取值根据SI的发送状态改变而改变：一个本来以按需的方式发送的SI，***修改其发送方式为以周期性广播的方式发送了，则si-BroadcastStatus取值从notBroadcasting修改为broadcasting；反之，一个本来以周期性广播的方式发送的SI，***修改其发送方式为以按需的方式发送了，则si-BroadcastStatus取值从broadcasting修改为notBroadcasting。

NR R17(Release 17)的SL(Sidelink)增强课题，一个很重要的方向是，支持UE-to-network relay，也就是，一个remote UE可以通过一个relay UE接入移动通信网络。并且根据当前的标准进展，relay UE可能需要在SL链路(remote UE与relay UE之间的直连链路，更广泛的概念，是两个UE之间的直连链路)转发relay UE从基站获得***消息。并且，relay UE在SL上发送***消息的方式，也可能是以按需的方式发送的。

那么，relay UE在SL发送某个SI的方式(周期性广播发送或者按需发送)，可以与Uu链路上对应SI的发送方式不同，比如，一个SI在Uu链路(relay UE与基站之间的链路)是以广播的方式发送的，但是，relay UE可能会选择在SL上以按需的方式发送该SI；或者，一个SI在Uu链路上以按需的方式发送的，但是，relay UE可能会选择在SL上以广播的方式发送该SI。当然，relay UE在SL发送某个SI的方式(周期性广播发送或者按需发送)，也可以与Uu链路上对应SI的发送方式保持一致。

本发明关注的问题在于，如果relay UE在SL发送某个SI的方式(周期性广播发送或者按需发送)，与Uu链路上对应SI的发送方式不同的情况。具体方案是：

对于relay UE(称为第一UE):

接收Uu链路上的第一***消息，所述第一***消息中包含第二***消息的发送状态；所述第二***消息是与第一***消息不同的***消息。

在具体实施中，所述第一***消息为***消息1(SIB1)。

在具体实施中，所述第二***消息，可以是SIB2，SIB3等非SIB1的***消息，也可以是包含SIB2，或者SIB3等SIB的***消息SI。

所述第二***消息的发送状态是指，所述第二***消息是广播的方式发送，还是以按需的方式发送。所述以广播的方式发送是指，所述***消息是以周期性广播的方式发送的；所述以按需的方式发生是指，所述***消息是基于UE的请求，以广播的方式发送，或者以单播的方式发送的。

所述Uu链路，是relay UE与基站之间的链路。所述基站可以是eNB，gNB，或者ng-eNB等，本发明不做限制。

在SL链路上发送所述第一***消息。

所述SL链路为第一UE与第二UE的直连链路。

在SL链路上发送所述第二***消息在SL上的发送状态。

在SL链路上发送所述第二***消息在SL上的发送状态，具体是指发送包含第二***消息在SL上的发送状态的消息。

所述第二***消息在SL上的发送状态是指，所述第二***消息在SL链路上是广播的方式发送，还是以按需的方式发送。所述以广播的方式发送是指，所述***消息是以周期性广播的方式发送的；所述以按需的方式发生是指，所述***消息是基于remote UE(成为第二UE)的请求，以广播的方式发送，或者以单播的方式发送的。

在具体实施中，如果第二***消息在SL链路上的发送状态，与所述第二***消息在Uu链路上的发送状态一致，relay UE不需要在SL链路上发送所述第二***消息在SL上的发送状态。即，只有第二***消息在SL链路上的发送状态，与所述第二***消息在Uu链路上的发送状态不一致时，relay UE才需要在SL链路上发送所述第二***消息在SL上的发送状态。

在SL链路上发送第二***消息。

在具体实施中，relay UE根据所述第一***消息中指示的第二***消息在Uu链路上的发送状态，以及所述第二***消息在SL上的发送状态，确定在SL链路发送第二***消息的发送方式。比如，如果在第一***消息中指示的第二***消息在Uu链路上的发送状态为，以广播的方式发送，但是，第二***消息在SL上的发送状态为按需的方式发送，则relayUE以按需的方式在SL链路上发送第二***消息。

又比如，如果在第一***消息中指示的第二***消息在Uu链路上的发送状态为，以按需的方式发送，但是，第二***消息在SL上的发送状态为以广播的方式发送，则relayUE以广播的方式在SL链路上发送第二***消息。

又比如，如果在第一***消息中指示的第二***消息在Uu链路上的发送状态为，以广播的方式发送，并且，第二***消息在SL上的发送状态也是以广播的方式发送，则relay UE以广播的方式在SL链路上发送第二***消息。

又比如，如果在第一***消息中指示的第二***消息在Uu链路上的发送状态为，以按需的方式发送，并且，第二***消息在SL上的发送状态也是以按需的方式发送，则relay UE以按需的方式在SL链路上发送第二***消息。

在具体实施中，如果relay UE没有发送所述第二***消息在SL上的发送状态，则，relay UE以第一***消息中的第二***消息在Uu链路上的发送状态为参考，确定第二***消息在SL链路上的发送状态，并根据确定的第二***消息在SL链路上的发送状态对应的发生方式，在SL链路上发送第二***消息。

对于remote UE(第二UE)：

接收relay UE转发的第一***消息，从第一***消息中获取第二***消息在Uu链路上的发送状态。

在具体实施中，所述第一***消息为***消息1(SIB1)。

在具体实施中，所述第二***消息，可以是SIB2，SIB3等非SIB1的***消息，也可以是包含SIB2，或者SIB3等SIB的***消息SI。

所述第二***消息的发送状态是指，所述第二***消息是广播的方式发送，还是以按需的方式发送。所述以广播的方式发送是指，所述***消息是以周期性广播的方式发送的；所述以按需的方式发生是指，所述***消息是基于UE的请求，以广播的方式发送，或者以单播的方式发送的。

所述Uu链路，是relay UE与基站之间的链路。所述基站可以是eNB，gNB，或者ng-eNB等，本发明不做限制。

接收relay UE发送的第二***消息在SL上的发送状态；

根据所述第一***消息中获取第二***消息在Uu链路上的发送状态，以及relayUE发送的第二***消息在SL上的发送状态，确定第二***消息在SL的发送状态。

比如，如果从第一***消息中获取的第二***消息在Uu链路上的发送状态为，以广播的方式发送，但是，第二***消息在SL上的发送状态为按需的方式发送，则relay UE以按需的方式在SL链路上发送第二***消息。

又比如，如果从第一***消息中获取的第二***消息在Uu链路上的发送状态为，以按需的方式发送，但是，第二***消息在SL上的发送状态为以广播的方式发送，则relayUE以广播的方式在SL链路上发送第二***消息。

又比如，如果从第一***消息中获取的第二***消息在Uu链路上的发送状态为，以广播的方式发送，并且，第二***消息在SL上的发送状态也是以广播的方式发送，则relay UE以广播的方式在SL链路上发送第二***消息。

又比如，如果从第一***消息中获取的第二***消息在Uu链路上的发送状态为，以按需的方式发送，并且，第二***消息在SL上的发送状态也是以按需的方式发送，则relay UE以按需的方式在SL链路上发送第二***消息。

在具体实施中，如果没有在SL链路接收到relay UE发送的第二***消息在SL上的发送状态，则以所述第一***消息中获取的第二***消息在Uu链路上的发送状态作为所述第二***消息在SL链路上的发送状态。

可以认为，对于remote UE而言，如果接收到relay UE发送的第二***消息在SL上的发送状态，则以relay UE发送的所述第二***消息在SL上的发送状态作为第二***消息在SL上的发送状态；如果没有接收到relay UE发送的第二***消息在SL链路上的发送状态，则以relay UE转发的第一***消息中包含的所述第二***消息在Uu链路上的发送状态作为第二***消息在SL上的发送状态。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指示相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：ROM、RAM、磁盘或光盘等。

虽然本发明披露如上，但本发明并非限定于此。任何本领域技术人员，在不脱离本发明的精神和范围内，均可作各种更动与修改，因此本发明的保护范围应当以权利要求所限定的范围为准。

Claims (36)

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

确定需要指示寻呼原因M的目标用户设备；其中，所述寻呼原因M是N个寻呼原因中的一个；

发送寻呼消息，所述寻呼消息包含所述寻呼原因M和所述目标用户设备的标识信息。

2.如权利要求1所述的寻呼原因发送方法，其特征在于，所述确定需要指示寻呼原因M的目标用户设备，包括：

确定需要指示所述寻呼原因M的目标用户设备的个数。

3.如权利要求2所述的寻呼原因发送方法，其特征在于，在发送寻呼消息之前，还包括：

发送下行控制信息，所述下行控制信息用于调度所述寻呼消息，且所述下行控制信息包含所述目标用户设备的个数。

4.如权利要求3所述的寻呼原因发送方法，其特征在于，所述寻呼消息包含X个用户设备的标识信息，所述目标用户设备的个数为K；K个目标用户设备的标识信息位于所述X个用户设备的标识信息最前面，或位于所述X个用户设备的标识信息最后面。

5.如权利要求1-4任一项所述的寻呼原因发送方法，其特征在于，还包括：指示所述寻呼消息中是否携带寻呼原因M。

6.如权利要求5所述的寻呼原因发送方法，其特征在于，所述指示所述寻呼消息中是否携带寻呼原因M，包括：

配置所述寻呼消息中是否携带寻呼原因M。

7.如权利要求6所述的寻呼原因发送方法，其特征在于，所述寻呼消息还包括寻呼原因指示信息，所述寻呼原因指示信息用于指示所述寻呼消息是否包含寻呼原因M。

8.如权利要求5所述的寻呼原因发送方法，其特征在于，所述指示所述寻呼消息中是否携带寻呼原因M，包括：

通过高层信令指示所述寻呼消息中是否携带寻呼原因M。

9.如权利要求5所述的寻呼原因发送方法，其特征在于，所述指示所述寻呼消息中是否携带寻呼原因M，包括：

通过下行控制信息中的一个bit，指示所述寻呼消息中是否携带寻呼原因M。

10.如权利要求9所述的寻呼原因发送方法，其特征在于，所述下行控制信息中的一个bit为短消息中的一个bit。

11.如权利要求5所述的寻呼原因发送方法，其特征在于，还包括：当所述寻呼消息中携带有寻呼原因M时，指示所述寻呼原因M的具体类型。

12.如权利要求11所述的寻呼原因发送方法，其特征在于，所述指示所述寻呼原因的具体类型，包括：

在所述寻呼消息中增加第二指示字段，所述第二指示字段的取值用于表征所述寻呼原因的类型。

13.如权利要求11所述的寻呼原因发送方法，其特征在于，所述指示所述寻呼原因的类型，包括：

通过高层信令向用户设备指示所述寻呼原因的类型。

14.如权利要求11所述的寻呼原因发送方法，其特征在于，所述指示所述寻呼原因的类型，包括：

发送下行控制信息，所述下行控制信息包括预留比特位，所述预留比特位包括第一部分以及第二部分，且所述第一部分用于指示所述寻呼记录列表中目标用户设备的个数，所述第二部分用于指示所述寻呼原因的类型。

15.如权利要求1所述的寻呼原因发送方法，其特征在于，所述发送寻呼消息，包括：在所述寻呼消息中增加新的寻呼记录列表，且所述新的寻呼记录列表中的寻呼记录存在对应寻呼原因，已有的寻呼记录列表中的寻呼记录不存在对应寻呼原因。

16.如权利要求15所述的寻呼原因发送方法，其特征在于，还包括：配置所述寻呼消息中是否携带所述新的寻呼记录列表。

17.一种寻呼原因获取方法，其特征在于，包括：

接收基站下发的寻呼消息，所述寻呼消息中包含寻呼原因M和目标用户设备的标识信息，所述目标用户设备为所述基站确定需要指示寻呼原因M的用户设备，所述寻呼原因M是N个寻呼原因中的一个。

18.如权利要求17所述的寻呼原因获取方法，其特征在于，在接收所述寻呼消息之前，还包括：

接收下行控制信息，所述下行控制信息用于调度所述寻呼消息，且所述下行控制信息包含所述目标用户设备的个数。

19.如权利要求18所述的寻呼原因获取方法，其特征在于，所述寻呼消息包含X个用户设备的标识信息，所述目标用户设备的个数为K；K个目标用户设备的标识信息位于所述X个用户设备的标识信息最前面，或位于所述X个用户设备的标识信息最后面。

20.如权利要求17-19任一项所述的寻呼原因获取方法，其特征在于，还包括：获取寻呼原因指示消息，所述寻呼原因指示消息用于指示所述寻呼消息中是否携带寻呼原因M。

21.如权利要求20所述的寻呼原因获取方法，其特征在于，所述获取寻呼原因指示消息，包括：从所述寻呼消息中获取所述寻呼原因指示信息。

22.如权利要求20所述的寻呼原因获取方法，其特征在于，所述获取寻呼原因指示消息，包括：接收所述基站下发的高层信令，所述高层信令中携带有所述寻呼原因指示信息。

23.如权利要求20所述的寻呼原因获取方法，其特征在于，所述获取寻呼原因指示消息，包括：接收所述基站下发的下行控制信息，所述下行控制信息中携带有所述寻呼原因指示信息。

24.如权利要求23所述的寻呼原因获取方法，其特征在于，所述寻呼原因指示信息为所述下行控制信息中短消息的一个bit。

25.如权利要求20所述的寻呼原因获取方法，其特征在于，还包括：获取寻呼原因的类型。

26.如权利要求25所述的寻呼原因获取方法，其特征在于，所述获取寻呼原因的类型，包括：读取所述寻呼消息中的第二指示字段，所述第二指示字段的取值用于表征所述寻呼原因的类型。

27.如权利要求25所述的寻呼原因获取方法，其特征在于，所述获取寻呼原因的类型，包括：接收所述基站下发的高层信令，所述高层信令中携带有所述寻呼原因的类型。

28.如权利要求25所述的寻呼原因获取方法，其特征在于，所述获取寻呼原因的类型，包括：获取预留比特位的取值，所述预留比特位包括第一部分以及第二部分，且所述第一部分用于指示所述寻呼记录列表中目标用户设备的个数，所述第二部分用于指示所述寻呼原因的类型。

29.如权利要求17所述的寻呼原因获取方法，其特征在于，所述接收基站下发的寻呼消息，包括：从所述寻呼消息中获取新的寻呼记录列表，且所述新的寻呼记录列表中的寻呼记录存在对应寻呼原因，已有的寻呼记录列表中的寻呼记录不存在对应寻呼原因。

30.如权利要求29所述的寻呼原因获取方法，其特征在于，还包括：接收寻呼记录列表指示信息，所述寻呼记录列表指示信息用于指示所述寻呼消息是否携带所述新的寻呼记录列表。

31.一种寻呼原因发送装置，其特征在于，包括：

确定单元，用于确定需要指示寻呼原因M的目标用户设备；其中，所述寻呼原因M是N个寻呼原因中的一个；

发送单元，用于发送寻呼消息，所述寻呼消息中包含所述寻呼原因M和所述目标用户设备的标识信息。

32.一种寻呼原因获取装置，其特征在于，包括：接收单元，用于接收基站下发的寻呼消息，所述寻呼消息中包含寻呼原因和目标用户设备的标识信息，所述目标用户设备为所述基站确定需要指示寻呼原因M的用户设备，所述寻呼原因M是N个寻呼原因中的一个。

33.一种计算机可读存储介质，所述计算机可读存储介质为非易失性存储介质或非瞬态存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器运行时执行权利要求1～16任一项所述的寻呼原因发送方法的步骤。

34.一种计算机可读存储介质，所述计算机可读存储介质为非易失性存储介质或非瞬态存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器运行时执行权利要求17～30所述的寻呼原因获取方法的步骤。

35.一种寻呼原因发送装置，包括存储器和处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，其特征在于，所述处理器运行所述计算机程序时执行权利要求1～16任一项所述的寻呼原因发送方法的步骤。

36.一种寻呼原因获取装置，包括存储器和处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，其特征在于，所述处理器运行所述计算机程序时执行权利要求17～30所述的寻呼原因获取方法的步骤。

Images