CN114902755B

CN114902755B - 寻呼消息的处理方法及装置、通信设备和存储介质

Info

Publication number: CN114902755B
Application number: CN202080002107.3A
Authority: CN
Inventors: 洪伟
Original assignee: Beijing Xiaomi Mobile Software Co Ltd
Current assignee: Beijing Xiaomi Mobile Software Co Ltd
Priority date: 2020-08-26
Filing date: 2020-08-26
Publication date: 2023-10-03
Anticipated expiration: 2040-08-26
Also published as: CN114902755A; US20230269701A1; WO2022041016A1

Abstract

本公开实施例提供了一种寻呼消息的处理方法及装置、通信设备和存储介质。本公开实施例所提供的应用于基站的寻呼消息的处理方法包括：发送携带有寻呼原因的寻呼消息，其中，所述寻呼原因，用于供用户设备UE确定响应或忽略所述寻呼消息。

Description

寻呼消息的处理方法及装置、通信设备和存储介质

技术领域

本公开实施例涉及无线通信领域但不限于无线通信领域，尤其涉及一种寻呼消息的处理方法及装置、通信设备和存储介质。

背景技术

随着无线通信技术的发展，双卡甚至多卡手机被广泛应用，针对多卡手机的处理方式，包括双卡单待、双卡双待单通以及双卡双待双通等多种模式。在实际应用中，终端用于网络数据交互的用户识别卡为其中一张，即终端硬件及软件系统在一张卡对应的系统进行通信，另一张卡可处于监听的状态，即需要每一段时间监听另一张卡的寻呼消息、系统消息等，以实现双卡的业务使用。然而，监听另一张卡时会降低当前网络数据交互的用户识别卡的性能；而如果不监听，则无法使用另一张用户识别卡，因此在整体上降低了用户体验。

发明内容

本公开提供一种寻呼消息的处理方法及装置、通信设备和存储介质。

根据本公开实施例的第一方面，提供一种寻呼消息的处理方法，所述方法应用于基站，包括：

发送携带有寻呼原因的寻呼消息，其中，所述寻呼原因，用于供UE(UserEquipment，用户设备)确定响应或忽略所述寻呼消息。

在一些实施例中，所述寻呼原因携带在所述寻呼消息的寻呼原因IE(InformationElement，信息单元)或所述寻呼消息的辅助数据IE中。

在一些实施例中，所述方法还包括：

从核心网接收所述寻呼原因。

在一些实施例中，所述寻呼消息为基于所述核心网的寻呼信令下发的；

所述从核心网接收所述寻呼原因，包括：

从核心网接收携带有所述寻呼原因的寻呼信令。

在一些实施例中，所述寻呼消息为：RAN(Radio Access Network，无线接入网)寻呼消息。

在一些实施例中，所述方法还包括：

接收核心网发送的待下发给UE的待传输数据及与所述待传输数据关联的指示信息；

根据所述指示信息，确定寻呼UE的寻呼原因。

在一些实施例中，所述指示信息包括：所述待传输数据的业务标识。

根据本公开实施例的第二方面，提供一种寻呼消息的处理方法，所述方法应用于用户设备UE，包括：

接收寻呼消息；

根据所述寻呼消息携带的寻呼原因，响应或忽略所述寻呼消息。

在一些实施例中，所述根据所述寻呼消息携带的寻呼原因，响应或忽略所述寻呼消息，包括：

根据所述寻呼原因及响应准则，响应或忽略所述寻呼消息。

在一些实施例中，所述根据所述寻呼原因及响应准则，响应或忽略所述寻呼消息，包括：

根据所述寻呼原因及所述响应准则，响应于触发寻呼所述UE的待传输数据的业务优先级为预设优先级，响应或忽略所述寻呼消息。

在一些实施例中，所述预设优先级为：基于用户输入配置的优先级；

或者

网络设备配置的优先级。

输出所述寻呼原因触发寻呼所述UE的待传输数据的业务优先级；

根据针对所述业务优先级的用户反馈，响应或忽略所述寻呼消息。

在一些实施例中，所述寻呼原因携带在所述寻呼消息的寻呼原因IE或辅助数据IE中。

根据本公开实施例的第三方面，提供一种寻呼消息的处理方法，所述方法应用于核心网，包括：

下发用于确定寻呼UE的寻呼原因的预定信息，其中，所述寻呼原因被携带在寻呼消息中，用于供所述UE确定响应或忽略所述寻呼消息。

在一些实施例中，所述寻呼原因携带在所述寻呼消息的寻呼原因IE或所述寻呼消息的辅助数据IE中。

在一些实施例中，所述预定信息包括：携带所述寻呼原因的寻呼信令。

在一些实施例中，所述预定信息包括：与待下发到UE的待传输数据关联的指示信息，其中，所述指示信息，用于供接入网确认寻呼UE的所述寻呼原因。

根据本公开实施例的第四方面，提供一种寻呼消息的处理装置，所述装置应用于基站，包括：

第一发送模块，配置为发送携带有寻呼原因的寻呼消息，其中，所述寻呼原因，用于供UE确定响应或忽略所述寻呼消息。

在一些实施例中，所述装置还包括：

第一接收模块，配置为从核心网接收所述寻呼原因。

所述第一接收模块，包括：

第一接收子模块，配置为从核心网接收携带有所述寻呼原因的寻呼信令。

在一些实施例中，所述寻呼消息为：RAN寻呼消息。

在一些实施例中，所述装置还包括：

第二接收模块，配置为接收核心网发送的待下发给UE的待传输数据及与所述待传输数据关联的指示信息；

确定模块，配置为根据所述指示信息，确定寻呼非激活态的UE的寻呼原因。

根据本公开实施例的第五方面，提供一种寻呼消息的处理装置，所述装置应用于用户设备UE，包括：

第三接收模块，配置为接收寻呼消息；

响应模块，配置为根据所述寻呼消息携带的寻呼原因，响应或忽略所述寻呼消息。

在一些实施例中，所述响应模块，包括：

响应子模块，配置为根据所述寻呼原因及响应准则，响应或忽略所述寻呼消息。

在一些实施例中，所述响应子模块，包括：

第一响应单元，配置为根据所述寻呼原因及所述响应准则，响应于触发寻呼所述UE的待传输数据的业务优先级为预设优先级，响应或忽略所述寻呼消息。

或者

网络设备配置的优先级。

在一些实施例中，所述响应子模块，包括：

输出单元，配置为输出所述寻呼原因触发寻呼所述UE的待传输数据的业务优先级；

第二响应单元，配置为根据针对所述业务优先级的用户反馈，响应或忽略所述寻呼消息。

根据本公开实施例的第六方面，提供一种寻呼消息的处理装置，所述装置应用于核心网，包括：

下发模块，配置为下发用于确定寻呼UE的寻呼原因的预定信息，其中，所述寻呼原因被携带在寻呼消息中，用于供所述UE确定响应或忽略所述寻呼消息。

根据本公开实施例的第七方面，提供一种通信设备，所述通信设备至少包括：处理器和用于存储能够在所述处理器上运行的可执行指令的存储器，其中：

处理器用于运行所述可执行指令时，所述可执行指令执行上述任一项寻呼消息的处理方法中的步骤。

根据本公开实施例的第八方面，提供一种非临时性计算机可读存储介质，所述计算机可读存储介质中存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现上述任一项的寻呼消息的处理方法中的步骤。

本公开实施例在基站向终端下发寻呼消息时，向终端告知寻呼消息的寻呼原因，终端则可根据寻呼原因来判断是否需要响应该寻呼消息。这样，基站在下发寻呼消息时告知寻呼原因，可以便于终端在监听寻呼消息的同时，根据寻呼原因来有针对性地对寻呼消息进行响应，减少非激活态以及空闲态等的用户识别卡不必要的响应占用的系统资源，从而为提升终端整体的使用性能提供数据的参考。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明实施例，并与说明书一起用于解释本发明实施例的原理。

图1是根据一示例性实施例示出的一种无线通信系统的结构示意图；

图2是根据一示例性实施例示出的一种寻呼消息的处理方法的流程示意图一；

图3是根据一示例性实施例示出的一种寻呼消息的处理方法的流程示意图二；

图4是根据一示例性实施例示出的一种寻呼消息的处理方法的流程示意图三；

图5是根据一示例性实施例示出的一种寻呼消息的处理方法的流程示意图四；

图6是根据一示例性实施例示出的一种寻呼消息的处理装置的结构示意图一；

图7是根据一示例性实施例示出的一种寻呼消息的处理装置的结构示意图二；

图8是根据一示例性实施例示出的一种寻呼消息的处理装置的结构示意图三；

图9是根据一示例性实施例示出的通信设备的结构示意图一；

图10是根据一示例性实施例示出的通信设备的结构示意图二。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开实施例的一些方面相一致的装置和方法的例子。

在本公开实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开实施例。在本公开实施例和所附权利要求书中所使用的单数形式的“一种”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”及“若”可以被解释成为“在……时”或“当……时”或“响应于确定”。

请参考图1，其示出了本公开实施例提供的一种无线通信系统的结构示意图。如图1所示，无线通信系统是基于蜂窝移动通信技术的通信系统，该无线通信系统可以包括：若干个终端11以及若干个基站12。

其中，终端11可以是指向用户提供语音和/或数据连通性的设备。终端11可以经无线接入网(Radio Access Network，RAN)与一个或多个核心网进行通信，终端11可以是物联网终端，如传感器设备、移动电话(或称为“蜂窝”电话)和具有物联网终端的计算机，例如，可以是固定式、便携式、袖珍式、手持式、计算机内置的或者车载的装置。例如，站(Station，STA)、订户单元(subscriber unit)、订户站(subscriber station)，移动站(mobilestation)、移动台(mobile)、远程站(remote station)、接入点、远程终端(remoteterminal)、接入终端(access terminal)、用户装置(user terminal)、用户代理(useragent)、用户设备(user device)、或用户终端(user equipment，终端)。或者，终端11也可以是无人飞行器的设备。或者，终端11也可以是车载设备，比如，可以是具有无线通信功能的行车电脑，或者是外接行车电脑的无线终端。或者，终端11也可以是路边设备，比如，可以是具有无线通信功能的路灯、信号灯或者其它路边设备等。

基站12可以是无线通信系统中的网络侧设备。其中，该无线通信系统可以是第四代移动通信技术(the 4th generation mobile communication，4G)系统，又称长期演进(Long Term Evolution，LTE)系统；或者，该无线通信系统也可以是5G系统，又称新空口(new radio，NR)系统或5G NR系统。或者，该无线通信系统也可以是5G系统的再下一代系统。其中，5G系统中的接入网可以称为NG-RAN(New Generation-Radio Access Network，新一代无线接入网)。

其中，基站12可以是4G系统中采用的演进型基站(eNB)。或者，基站12也可以是5G系统中采用集中分布式架构的基站(gNB)。当基站12采用集中分布式架构时，通常包括集中单元(central unit，CU)和至少两个分布单元(distributed unit，DU)。集中单元中设置有分组数据汇聚协议(Packet Data Convergence Protocol，PDCP)层、无线链路层控制协议(Radio Link Control，RLC)层、媒体访问控制(Media Access Control，MAC)层的协议栈；分布单元中设置有物理(Physical，PHY)层协议栈，本公开实施例对基站12的具体实现方式不加以限定。

基站12和终端11之间可以通过无线空口建立无线连接。在不同的实施方式中，该无线空口是基于第四代移动通信网络技术(4G)标准的无线空口；或者，该无线空口是基于第五代移动通信网络技术(5G)标准的无线空口，比如该无线空口是新空口；或者，该无线空口也可以是基于5G的更下一代移动通信网络技术标准的无线空口。

在一些实施例中，终端11之间还可以建立E2E(End to End，端到端)连接。比如车联网通信(vehicle to everything，V2X)中的V2V(vehicle to vehicle，车对车)通信、V2I(vehicle to Infrastructure，车对路边设备)通信和V2P(vehicle to pedestrian，车对人)通信等场景。

在一些实施例中，上述无线通信系统还可以包含网络管理设备13。

若干个基站12分别与网络管理设备13相连。其中，网络管理设备13可以是无线通信系统中的核心网设备，比如，该网络管理设备13可以是演进的数据分组核心网(EvolvedPacket Core，EPC)中的移动性管理实体(Mobility Management Entity，MME)。或者，该网络管理设备也可以是其它的核心网设备，比如服务网关(Serving GateWay，SGW)、公用数据网网关(Public Data Network GateWay，PGW)、策略与计费规则功能单元(Policy andCharging Rules Function，PCRF)或者归属签约用户服务器(Home Subscriber Server，HSS)等。对于网络管理设备13的实现形态，本公开实施例不做限定。

如图2所示，本公开实施例提供一种寻呼消息的处理方法，该方法应用于基站，包括：

步骤S101、发送携带有寻呼原因的寻呼消息，其中，所述寻呼原因，用于供UE确定响应或忽略所述寻呼消息。

在本公开实施例中，基站在向UE下发寻呼消息时，可基于寻呼消息对应的业务类型，确定寻呼原因，并将寻呼原因携带在寻呼消息中告知UE。这里，携带有寻呼原因的寻呼消息中，可通过携带预定的寻呼原因的标识、信元或者直接将寻呼原因的内容携带在寻呼消息的指定位置中。也可通过隐式的方式，通过寻呼消息中的指定位置的内容来指示UE该寻呼消息的寻呼类型。

这样，当UE接收到寻呼消息后，可根据寻呼原因来确定是否响应该寻呼消息。

在本公开实施例中，寻呼原因可与寻呼消息对应的业务类型相关。例如，通话业务对应的寻呼消息，其寻呼原因为电话呼入；短信息业务对应的寻呼消息，其寻呼原因为请求接收短信息；系统消息以及紧急通知类业务消息等，其寻呼原因可以为紧急通知等。

此处的寻呼消息的接收用户设备，可为任意状态的用户设备，例如，

RRC连接态的UE；

RRC非激活态的UE；

RRC空闲态的UE。

核心网下发携带有系统消息变更或者地震海啸通知等寻呼消息，该寻呼消息，可以面向RRC连接态的UE、RRC非激活态的UE及RRC空闲态的UE中任意状态的UE。

例如，因为业务传输需求，核心网下发的触发UE从RRC空闲态退出切换到RRC连接态以进行数据传输的寻呼消息，即基于业务的寻呼消息。

再例如，UE处于RRC非激活态，接入网在RAN通知区内下发的寻呼消息。

终端具有多用户识别卡的情况，被寻呼的用户识别卡接收到带有寻呼原因的寻呼消息时，可根据寻呼原因来判断是否需要响应该寻呼消息，如果不需要响应，则无需将该用户识别卡切换为RRC连接态，使得终端可维持各用户识别卡对应的状态，而不需要进行切换。从而减少了非激活态用户识别卡切换至RRC连接态时对于当前处于RRC连接态的用户识别卡的干扰，提升了网络交互的性能。

如果根据寻呼原因判断需要响应该寻呼消息，则可将处于非激活态的用户识别卡切换为RRC连接态，以快速恢复数据传输，保证该用户识别卡的业务应用的正常数据交互。

这样，基站在下发寻呼消息时告知寻呼原因，一方面可以使得终端仍然保持对于各用户识别卡的寻呼消息的监听，不会因为用户识别卡处于非激活态以及空闲态等情况时未监听而遗漏必要的业务消息；另一方面可以便于终端根据寻呼原因来有针对性地对寻呼消息进行响应，减少非激活态以及空闲态等的用户识别卡不必要的响应占用的系统资源，从而为提升终端整体的使用性能提供数据的参考。

在本公开实施例中，寻呼消息中可携带有各种IE来表明寻呼消息中的各类参数，在本公开实施例中，可将寻呼原因作为单独的IE携带在寻呼消息的IE列表中，即在原来的寻呼消息中新增一个IE专门用于携带寻呼原因。

此外，寻呼消息的IE列表中还可能包含有辅助数据IE。将寻呼原因携带在辅助数据IE，在维持寻呼消息原有的信息格式的情况下，使用辅助数据IE的保留比特等进行携带，与相关技术的兼容性更强，无需更改寻呼消息的信息格式。

在一实施例中，可通过预定协议规定IE列表中各IE对应的参数含义，从而定义各种不同的寻呼原因。

在一些实施例中，所述方法还包括：

从核心网接收所述寻呼原因。

寻呼原因可以是核心网的接入和移动管理功能(AMF，Access and MobilityManagement Function)下发的。

在一个实施例中，AMF通过寻呼消息下发寻呼原因。例如，AMF下发面向所有状态携带系统消息变更通知或者地震海啸等灾难通知的寻呼消息时，可以顺带携带上该寻呼原因。再例如，AMF下发面向RRC空闲态(IDLE)或非激活态(INACTIVE)的UE的寻呼消息时，可以通过该寻呼消息下发寻呼原因。

在一些实施例中，寻呼原因不一定携带在寻呼消息中，也可以由AMF等核心网的网元通过专门下发寻呼原因的核心网消息等有别于寻呼消息的其他消息下发。

具体地，寻呼原因可以通过核心网直接获取，即核心网可直接下发寻呼原因至基站，这样基站将该寻呼原因添加至寻呼消息的IE列表中即可；也可通过核心网提供的传输数据对应的业务类型来获知寻呼原因，例如，核心网向基站提供某业务应用场景的传输数据，基站根据传输数据的数据类型或者数据内容等，确定该业务场景对应的寻呼原因。

例如：核心网提供的传输数据为通话业务请求数据，基站基于该传输数据确定寻呼原因为通话请求，则将该寻呼原因携带在寻呼消息中下发至UE。

如图3所示，所述从核心网接收所述寻呼原因，包括：

步骤S201、从核心网接收携带有所述寻呼原因的寻呼信令。

在本公开实施例中，核心网可直接向寻呼原因携带在寻呼信令中，由核心网的AMF(Access and Mobility Management Function，接入和移动管理功能)向基站(如，gNB)下发对应的寻呼信令(Paging)：

该寻呼信令由AMF发送，用于在一个或几个跟踪区域中寻呼UE。消息内容可由如下表一的IE列表来表示：

表一

本公开实施例中，寻呼原因包括在基站接收寻呼消息中所携带的寻呼原因IE中。本领域的技术人员应当知晓，上表中所述的寻呼原因IE形式仅是示例性的，不构成对本公开保护范围的限制。

此外，表一中示出的内容并不构成寻呼信令形式的限制，在实际应用中，寻呼信令可包含如下表中的部分或全部IE，也可包含表一中未示出的IE。

在本公开的一些实施例中，寻呼原因IE的信元格式、或寻呼原因IE的信元位置等可根据协议规定灵活调整，本领域技术人员应当知晓任何携带寻呼原因的寻呼消息均属于本公开要求保护的范围。

在一些实施例中，所述寻呼消息为：RAN寻呼消息。

在本公开实施例中，上述寻呼消息可以为RAN寻呼消息，由NG-RAN节点之间相互传输，例如，从NG-RAN node1向NG-RAN node2传输，以寻呼UE。

消息内容可由如下表二所示的IE列表来表示：

表二

需要说明的是，表二中的寻呼原因IE形式也仅为示例性的，不构成对本公开保护范围的限制。在本公开的一些实施例中，寻呼原因IE的信元格式、或寻呼原因IE的信元位置等可根据协议规定灵活调整，本领域技术人员应当知晓任何携带寻呼原因的寻呼消息均属于本公开要求保护的范围。

此外，表二中示出的内容并不构成RAN寻呼消息形式的限制，在实际应用中，RAN寻呼消息可包含如下表中的部分或全部IE，也可包含下表二中未示出的IE。

在一些实施例中，所述方法还包括：

根据所述指示信息，确定寻呼UE的寻呼原因。

在本公开实施例中，基站除了接收核心网发送的寻呼信令以外，也可通过接收核心网的UPF(User Plane Function，用户面功能)下发的待传输数据来直接确定寻呼原因。例如，针对RRC非激活态或者空闲态等除连接态以外的其他状态的UE，接入网接收到核心网需下发给RRC非激活态的UE的待传输数据之后，先根据待传输数据，确定出寻呼原因，下发携带有该寻呼原因的RAN寻呼消息，并发送寻呼消息，并在UE响应寻呼消息切换到RRC连接态之后，将UPF下发的待传输数据，通过与UE建立的RRC连接下发给UE。

其中待传输数据关联有指示信息，用于指示寻呼UE的寻呼原因。基站则可根据该指示信息，确定寻呼非激活态的UE的寻呼原因，并将该寻呼原因添加至发送到UE的寻呼消息中告知UE。

例如，所述指示信息可包括：QoS标识，一般QoS标识与待传输数据的传输延时和/或传输正确率相关，若QoS标识对应的传输可容忍延时较小，说明这个业务可能是特定业务，需要尽快下发到UE的使得UE尽快响应寻呼的概率越高，因此可以QoS标识确定寻呼原因。

再例如，指示信息可以是与待传输数据的业务类型相关联的标识，基站根据指示信息可以确定待传输数据的业务类型，进而确定对应的寻呼原因。该指示信息也可以是基于预定协议确定的指示与寻呼原因相对应的标识，直接指示基站待传输数据所对应的寻呼原因，便于基站将寻呼原因添加至寻呼消息中。

需要说明的是，本公开任一实施例中所涉及的寻呼消息的处理方法适用于UE处于非激活态、空闲态或其他激活状态以外的任意状态。

这里，上述指示信息包括待传输数据的业务标识，也就是不同的业务或者业务类型的待传输数据，对应有不同的指示信息。因此，基站可根据指示信息确定待传输数据对应的业务或者业务类型，并根据指示信息将对应的寻呼原因添加到寻呼消息中进行UE的寻呼。这样，即使基站接收到的待传输数据中没有携带寻呼原因，也可以识别业务标识对应的寻呼原因并告知UE。便于UE在接收数据之前，根据寻呼消息中携带的寻呼原因来判断是否需要响应寻呼消息，或者接收上述待传输数据。

如图4所示，本公开实施例提供一种寻呼消息的处理方法，该方法应用于用户设备UE，包括：

步骤S301、接收寻呼消息；

步骤S302、根据所述寻呼消息携带的寻呼原因，响应或忽略所述寻呼消息。

在本公开实施例中，UE在基站的寻呼范围内接收带有自身用户标识的寻呼消息，由于寻呼消息中携带有寻呼原因，因此可以先从寻呼消息中读取寻呼原因，根据寻呼原因来响应或忽略寻呼消息。这里，UE可以是手机、笔记本电脑等终端设备。

若UE根据寻呼原因确定需要响应寻呼消息，则基于寻呼消息与基站建立对应的数据连接，此时，如果UE处于非激活态，则可切换为RRC连接态，获取基站下发的数据，或者向基站发送寻呼消息请求的数据；若UE确定不需要响应寻呼消息，则忽略寻呼消息，不与基站建立对应的连接关系，同时，如果UE处于非激活态，则可仍维持在非激活态，不进行状态的切换。

根据所述寻呼原因及响应准则，响应或忽略所述寻呼消息。

这里，UE可根据寻呼原因与预先设定的响应准则中与之对应的处理方式响应或忽略寻呼消息。对于不同的寻呼原因，用户或者运营商或者终端可针对各用户识别卡设定不同的响应准则。这样，UE在接收到寻呼消息时，根据寻呼原因找到对应的响应准则进行处理。

在实际应用中，用户可根据自身的需求随时更改响应准则，例如，用户可设定双卡手机中，主卡卡槽内的用户识别卡用于网络数据传输时，副卡卡槽内的用户识别卡处于非激活态，当副卡监听到寻呼消息时，如果寻呼原因为通话请求，则响应该寻呼消息，将终端硬件如射频模块等切换至副卡建立通信连接，并接入通话请求。而如果寻呼原因为运营商的通知消息，则忽略该寻呼消息。

这样，终端可根据用户的设定灵活处理寻呼消息，减少了不必要的寻呼响应以及终端的系统切换，进而提升了整体的用户使用感受。

在本公开实施例中，上述响应准则可为寻呼消息对应的业务的业务优先级。UE可设定将业务优先级划分为响应寻呼消息对应的优先级和忽略寻呼消息对应的优先级。这样，UE根据待传输数据的业务优先级是否属于响应寻呼消息的预设优先级或者是否属于忽略寻呼消息对应的预设优先级，来判断是否响应该寻呼消息。

或者

网络设备配置的优先级。

在本公开实施例中，上述预设优先级可以由根据用户输入确定，用户还可根据实际需求随时更改预设优先级的设定。预设优先级也可通过网络设备的配置确定，通过网络设备下发的配置信息告知UE，其中，网络设备可以为基站也可以为核心网设备。

对于待传输数据的业务优先级则可通过核心网或基站等网络设备根据待传输数据的业务类型，标识出对应的业务优先级，也可由UE自身通过寻呼原因确定对应的业务优先级。

在本公开实施例中，可针对寻呼原因在终端输出用于供用户设定的选项等，输出的方式可包括在终端显示界面上显示的图像、文字等也可通过语音输出等方式，提供业务优先级的设定选项，在用户选择寻呼原因对应的业务优先级后，终端判断该业务优先级是否满足预设优先级，进而响应或忽略寻呼消息。

还可输出由待传输数据对应的业务优先级，该业务优先级可由网络设备确定并告知UE。用户则可根据该业务优先级，直接选择响应或忽略该寻呼消息。

在本公开实施例中，可将寻呼原因作为单独的IE携带在寻呼消息的IE列表中。此外，寻呼消息的IE列表中还可能包含有辅助数据IE。辅助数据IE具有对应的子列表作为辅助数据IE的IE列表。因此，也可将寻呼原因IE作为辅助数据IE的子列表中的IE携带在IE列表中。

如图5所示，本公开实施例提供一种寻呼消息的处理方法，该方法应用于核心网，包括：

步骤S401、下发用于确定寻呼UE的寻呼原因的预定信息，其中，所述寻呼原因被携带在寻呼消息中，用于供所述UE确定响应或忽略所述寻呼消息。

这里，核心网可以利用AMF或UPF等向基站下发上述预定信息。该预定消息经过基站处理后可将确定的寻呼原因携带在寻呼消息中，并在寻呼UE的过程中将寻呼原因告知UE，以便UE根据寻呼原因响应或忽略寻呼消息。

这里，上述IE列表可以由核心网直接提供给基站，再由基站将该IE列表携带在寻呼消息中提供给UE。此外，核心网也可不携带寻呼原因，直接将待传输数据发送至基站，再由基站将待传输数据对应的寻呼原因携带在寻呼消息的寻呼原因IE或所述寻呼消息的辅助数据IE中，并发送至UE。

在本公开实施例中，核心网可直接向基站下发携带有寻呼原因的寻呼信令，该寻呼信令可由核心网的AMF发送，用于在一个或几个跟踪区域中寻呼UE。

在发送寻呼信令时，核心网可直接将寻呼原因携带在IE列表中，这样，基站在接收到寻呼信令后，可直接将IE列表中的寻呼原因IE添加至用于寻呼UE的寻呼消息中并发送至UE。

在本公开实施例中，上述待传输数据可通过核心网的UPF发送至基站，由基站根据待传输数据向UE下发寻呼消息。核心网在发送待传输数据的同时，可将用于指示寻呼原因的预定信息同时传输给基站，使得基站根据指示信息将寻呼原因添加至寻呼消息中。

例如，针对RRC非激活态的UE，接入网从核心网接收到需下发给RRC非激活态的UE的待传输数据之后，先根据待传输数据，确定出寻呼原因，在接入网各节点发送携带有该寻呼原因的RAN寻呼消息，并向UE下发寻呼消息。在UE响应寻呼消息切换到RRC连接态之后，将UPF下发的待传输数据，通过与UE建立的RRC连接下发给UE。

这样，在接入网中，基站需要对非激活态或者空闲态等状态的UE进行寻呼时，可以将指示信息确定的寻呼原因告知UE，便于非激活态或者空闲态等的UE进行判断是否需要响应该寻呼消息。

在本公开实施例中，上述指示信息可包含用于确定待传输数据的业务或业务类型的标识，即上述业务标识。接入网在进行寻呼时，无需从核心网获取寻呼原因，而是可以根据业务标识确定出待传输数据的对应业务的寻呼原因，进而添加到寻呼消息中告知UE。

本公开实施例还提供如下示例：

在5G NR中引入了RRC非激活态(RRC_INACTIVE)，当终端处于该状态时，NAS层仍然保持在连接态(即终端与核心网仍然保持连接)，但终端的空口连接是断开的。基站侧则保留UE的上下文信息，以及终端与核心网的NG接口连接。终端可以在基站配置的一个区域范围内移动而无需通知网络，以节省信令开销。终端进入非激活态时，最后一个服务基站存储着该终端的上下文以及与服务核心网的NG连接，终端的AS层也保存相应的上下文信息，包括承载、非激活态的标识、归属区域等。通过该方式，基站能在所配置的区域范围内通过无线接入网寻呼机制寻呼到处于非激活态的终端，终端可以基于终端侧和基站侧所存储的上下文信息，快速恢复数据传输，实现低时延传输。

对于多卡终端在和第一系统(终端的一张用户识别卡对应的通信系统)通信时，需要定期检测第二系统(终端中另一用户识别卡对应的通信系统)，比例监听寻呼、进行测量、读取系统消息等。而这可能会对第一系统的性能造成影响，降低当前用户识别卡的网络使用体验。如果不去第二系统进行这些操作，例如不去监听寻呼，则可能造成第二系统的业务一直不能建立起来。

因此，在本公开实施例中，当多卡终端在第二系统上收到寻呼消息时，还需要决定是否需要对该寻呼进行回应，而这是基于用户配置的规则进行的。

在本公开实施例中，核心网向非激活态的UE对应的锚点基站发送寻呼消息或者传输数据时，需要同时在寻呼信令中或者数据中告知寻呼的原因。该寻呼原因可以通过直接在寻呼消息中添加用于标识寻呼原因的IE来实现，如下表三所示。也可以通过在寻呼消息中的寻呼辅助数据IE中添加用于标识寻呼原因的IE来实现。

该寻呼消息由AMF发送至基站(gNB)，用于在一个或多个跟踪区域中寻呼UE。

表三

上述锚点基站收到核心网发送的上述带有寻呼原因的寻呼消息时，或者收到核心网发送的待传输数据时，可在无线寻呼信令中添加寻呼原因。在本公开实施例中，该寻呼原因可通过直接在RAN寻呼消息中添加用于标识寻呼原因的IE来实现，如下表四所示：

该RAN寻呼消息由NG-RAN节点之间进行传输，以寻呼UE。

表四

当非激活态或者空闲态的UE在收到带有寻呼原因的寻呼信令后，根据预定的响应准则确定是否响应该寻呼消息。例如：

UE可综合寻呼原因以及对应业务的业务优先级，来确定是否响应寻呼消息。此外业务优先级可由用户配置也可由网络设备(包括基站或者核心网设备等)进行预配置并告知UE。

UE还可将寻呼原因所对应的业务或者业务类型通过终端的UI呈现给用户，并由用户来选择是否响应该寻呼。

如图6所示，本公开实施例还提供一种寻呼消息的处理装置600，应用于基站，包括：

第一发送模块601，配置为发送携带有寻呼原因的寻呼消息，其中，所述寻呼原因，用于供UE确定响应或忽略所述寻呼消息。

在一些实施例中，所述装置还包括：

第一接收模块，配置为从核心网接收所述寻呼原因。

所述第一接收模块，包括：

在一些实施例中，所述寻呼消息为：RAN寻呼消息。

在一些实施例中，所述装置还包括：

确定模块，配置为根据所述指示信息，确定寻呼UE的寻呼原因。

如图7所示，本公开实施例还提供一种寻呼消息的处理装置700，所述装置应用于用户设备UE，包括：

第三接收模块701，配置为接收寻呼消息；

在一些实施例中，所述响应模块，包括：

在一些实施例中，所述响应子模块，包括：

或者

网络设备配置的优先级。

在一些实施例中，所述响应子模块，包括：

如图8所示，本公开实施例还提供一种寻呼消息的处理装置800，所述装置应用于核心网，包括：

下发模块801，配置为下发用于确定寻呼UE的寻呼原因的预定信息，其中，所述寻呼原因被携带在寻呼消息中，用于供所述UE确定响应或忽略所述寻呼消息。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图9是本公开实施例提供的一种通信设备的结构框图。该通信设备可以是终端。例如，通信设备900可以是移动电话，计算机，数字广播用户设备，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

参照图9，通信设备900可以包括以下至少一个组件：处理组件902，存储器904，电源组件906，多媒体组件908，音频组件910，输入/输出(I/O)的接口912，传感器组件914，以及通信组件916。

处理组件902通常控制通信设备900的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件902可以包括至少一个处理器920来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件902可以包括至少一个模块，便于处理组件902和其他组件之间的交互。例如，处理组件902可以包括多媒体模块，以方便多媒体组件908和处理组件902之间的交互。

存储器904被配置为存储各种类型的数据以支持在通信设备900的操作。这些数据的示例包括用于在通信设备900上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器904可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件906为通信设备900的各种组件提供电力。电源组件906可以包括电源管理系统，至少一个电源，及其他与为通信设备900生成、管理和分配电力相关联的组件。

多媒体组件908包括在所述通信设备900和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括至少一个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的唤醒时间和压力。在一些实施例中，多媒体组件908包括一个前置摄像头和/或后置摄像头。当通信设备900处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件910被配置为输出和/或输入音频信号。例如，音频组件910包括一个麦克风(MIC)，当通信设备900处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器904或经由通信组件916发送。在一些实施例中，音频组件910还包括一个扬声器，用于输出音频信号。

I/O接口912为处理组件902和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件914包括至少一个传感器，用于为通信设备900提供各个方面的状态评估。例如，传感器组件914可以检测到设备900的打开/关闭状态，组件的相对定位，例如所述组件为通信设备900的显示器和小键盘，传感器组件914还可以检测通信设备900或通信设备900一个组件的位置改变，用户与通信设备900接触的存在或不存在，通信设备900方位或加速/减速和通信设备900的温度变化。传感器组件914可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件914还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件914还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件916被配置为便于通信设备900和其他设备之间有线或无线方式的通信。通信设备900可以接入基于通信标准的无线网络，如WiFi，2G或3G，或它们的组合。在一个示例性实施例中，通信组件916经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件916还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，通信设备900可以被至少一个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器904，上述指令可由通信设备900的处理器920执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

如图10所示，本公开一实施例示出另一种通信设备的结构。该通信设备可为本公开实施例所涉及的基站。例如，通信设备1000可以被提供为一网络设备。参照图10，通信设备1000包括处理组件1022，其进一步包括至少一个处理器，以及由存储器1032所代表的存储器资源，用于存储可由处理组件1022的执行的指令，例如应用程序。存储器1032中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件1022被配置为执行指令，以执行上述方法前述应用在所述通信设备的任意方法。

通信设备1000还可以包括一个电源组件1026被配置为执行通信设备1000的电源管理，一个有线或无线网络接口1050被配置为将通信设备1000连接到网络，和一个输入输出(I/O)接口1058。通信设备1000可以操作基于存储在存储器1032的操作系统，例如Windows Server TM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本公开旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。

Claims

1.一种寻呼消息的处理方法，其中，所述方法应用于基站，包括：

发送携带有寻呼原因的寻呼消息，其中，所述寻呼原因用于供用户设备UE确定响应或忽略所述寻呼消息；其中，所述UE为无线资源控制RRC连接态的UE、RRC非激活态的UE以及RRC空闲态的UE中之一；所述寻呼消息为RAN寻呼，所述寻呼原因携带在所述寻呼消息的寻呼原因信息单元IE或所述寻呼消息的辅助数据IE中。

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

从核心网接收所述寻呼原因。

3.根据权利要求2所述的方法，其中，所述寻呼消息为基于所述核心网的寻呼信令下发的；

所述从核心网接收所述寻呼原因，包括：

从核心网接收携带有所述寻呼原因的寻呼信令。

4.根据权利要求1至3任一项所述的方法，其中，所述方法还包括：

根据所述指示信息，确定寻呼UE的寻呼原因。

5.根据权利要求4所述的方法，其中，所述指示信息包括：所述待传输数据的业务标识。

6.一种寻呼消息的处理方法，其中，所述方法应用于用户设备UE，包括：

接收寻呼消息，所述寻呼消息为RAN寻呼，所述UE为无线资源控制RRC连接态的UE、RRC非激活态的UE以及RRC空闲态的UE中之一；

根据所述寻呼消息携带的寻呼原因，响应或忽略所述寻呼消息；

其中，所述寻呼原因携带在所述寻呼消息的寻呼原因IE或辅助数据IE中。

7.根据权利要求6所述的方法，其中，所述根据所述寻呼消息携带的寻呼原因，响应或忽略所述寻呼消息，包括：

根据所述寻呼原因及响应准则，响应或忽略所述寻呼消息。

8.根据权利要求7所述的方法，其中，所述根据所述寻呼原因及响应准则，响应或忽略所述寻呼消息，包括：

9. 根据权利要求8所述的方法，其中，所述预设优先级为：基于用户输入配置的优先级；

或者

网络设备配置的优先级。

10.根据权利要求7所述的方法，其中，所述根据所述寻呼原因及响应准则，响应或忽略所述寻呼消息，包括：

11.一种寻呼消息的处理方法，其中，所述方法应用于核心网，包括：

下发携带寻呼原因的寻呼信令，其中，所述寻呼原因用于供用户设备UE确定响应或忽略寻呼消息；所述UE为无线资源控制RRC连接态的UE、RRC非激活态的UE以及RRC空闲态的UE中之一；所述寻呼原因携带在所述寻呼信令的寻呼原因IE或辅助数据IE中。

12.一种寻呼消息的处理装置，其中，所述装置应用于基站，包括：

第一发送模块，配置为发送携带有寻呼原因的寻呼消息，其中，所述寻呼原因，用于供UE确定响应或忽略所述寻呼消息；其中，所述UE为无线资源控制RRC连接态的UE、RRC非激活态的UE以及RRC空闲态的UE中之一；所述寻呼消息为RAN寻呼，所述寻呼原因携带在所述寻呼消息的寻呼原因信息单元IE或所述寻呼消息的辅助数据IE中。

13.根据权利要求12所述的装置，其中，所述装置还包括：

第一接收模块，配置为从核心网接收所述寻呼原因。

14.根据权利要求13所述的装置，其中，所述寻呼消息为基于所述核心网的寻呼信令下发的；

所述第一接收模块，包括：

15.根据权利要求12至14任一项所述的装置，其中，所述装置还包括：

16.根据权利要求15所述的装置，其中，所述指示信息包括：所述待传输数据的业务标识。

17.一种寻呼消息的处理装置，其中，所述装置应用于用户设备UE，包括：

第三接收模块，配置为接收寻呼消息，所述寻呼消息为RAN寻呼，所述UE为无线资源控制RRC连接态的UE、RRC非激活态的UE以及RRC空闲态的UE中之一；

响应模块，配置为根据所述寻呼消息携带的寻呼原因，响应或忽略所述寻呼消息；

18.根据权利要求17所述的装置，其中，所述响应模块，包括：

19.根据权利要求18所述的装置，其中，所述响应子模块，包括：

20. 根据权利要求19所述的装置，其中，所述预设优先级为：基于用户输入配置的优先级；

或者

网络设备配置的优先级。

21.根据权利要求18所述的装置，其中，所述响应子模块，包括：

22.一种寻呼消息的处理装置，其中，所述装置应用于核心网，包括：

下发模块，配置为下发携带寻呼原因的寻呼信令，其中，所述寻呼原因用于供用户设备UE确定响应或忽略寻呼消息；所述UE为无线资源控制RRC连接态的UE、RRC非激活态的UE以及RRC空闲态的UE中之一；所述寻呼原因携带在所述寻呼信令的寻呼原因IE或辅助数据IE中。

23.一种通信设备，其中，所述通信设备至少包括：处理器和用于存储能够在所述处理器上运行的可执行指令的存储器，其中：

处理器用于运行所述可执行指令时，所述可执行指令执行上述权利要求1至5或6至10或11任一项提供的寻呼消息的处理方法中的步骤。

24.一种非临时性计算机可读存储介质，其中，所述计算机可读存储介质中存储有计算机可执行指令，该计算机可执行指令被处理器执行时实现上述权利要求1至5或6至10或11任一项提供的寻呼消息的处理方法中的步骤。