CN112205041B - 一种寻呼消息传输方法和相关设备 - Google Patents

Abstract

本申请实施例提供了一种寻呼消息传输方法及相关设备。其中，该方法主要包括：从核心网设备接收第一寻呼消息，所述第一寻呼消息包括终端对应的第一指示，所述第一指示用于指示所述终端支持时延敏感寻呼；确定与所述第一指示对应的第一寻呼载波组，所述第一寻呼载波组包括网络侧设备的多个寻呼载波中的部分寻呼载波；在所述第一寻呼载波组的寻呼载波上寻呼所述终端。实施本申请实施例，通过对寻呼载波进行分组，不同组的寻呼载波对应不同的寻呼配置，可以实现一个小区内不同的寻呼周期的支持，同时满足短时延和深覆盖终端的寻呼需求。本实施例提供的方法提高了网络的覆盖能力，可以应用于物联网，例如MTC、IoT、LTE‑M、M2M等。

Description

一种寻呼消息传输方法和相关设备

技术领域

本申请涉及无线通信技术领域，尤其涉及一种寻呼消息传输方法和相关设备。

背景技术

移动通信已经深刻地改变了人们的生活，但人们对更高性能移动通信的追求从未停止。为了应对未来爆炸性的移动数据流量增长、海量的设备连接、不断涌现的各类新业务和应用场景，第五代移动通信(5G)系统将应运而生。物联网作为5G的组成部分，其市场需求增长迅猛，预测显示,到2022年5G物联网的连接数将会达到180亿。

目前3GPP标准已经基于蜂窝网络，针对物联网的特点提出了解决方案，比如窄带物联网通信(Narrow Band-Internet of Things，NB-IoT)和机器类型通信(Machine-TypeCommunications，MTC)。二者均利用了窄带技术的特点，来承载IoT业务。其中，NB-IoT网络应用了独立于现有蜂窝网络(Long Term Evolution，LTE)的新空口技术，终端成本更低，支持的速率和移动性更低。MTC网络属于传统蜂窝网络的一部分，终端成本较NB-IoT略高，适用于相对较高速率和移动性的物联网业务。与传统蜂窝网络相比，物联网的业务和终端设备具有业务速率低周期长、海量连接要求、低成本要求、低功耗要求等特点。

在物联网中，每个小区当前使用的寻呼的默认非连续接收(DiscontinuousReception，DRX)周期的值只有一个。比如，在NB-IOT中，基站默认的DRX为：{rf128,rf256,rf512,rf1024},共有4个值，基站会根据当前的网络的需要接收寻呼的用户设备(UserEquipment，UE)的覆盖等级的需求，即每个UE的接收的寻呼在物理下行控制信道(PhysicalDownlink Control Channel，PDCCH)的重复次数的需求，基站会设置其中的一个值，比如rf512作为小区的默认DRX的值。因为在物联网中，会同时存在深覆盖等级的终端(这种终端对于PDCCH和物理下行共享信道(Physical Downlink Shared Channel，PDSCH)的传输上的重复次数比较高，比如需要重复1024次,最大到2048次等)和非深覆盖的终端(即PDCCH的重复次数比较少，比如1次，2次，4次等),所以基站的默认DRX的配置会满足深覆盖终端的重复次数带来的时延，比如1024次重复，但是PDCCH就占用1.024秒，再考虑到PUSCH的传输时间，基站的默认DRX的周期就需要设置到5.12秒。在物联网设计的初期，认为物联网的业务对于时延没有要求，即物联网的业务都是时延非敏感的。但是从目前的物联网业务的发展来看，物联网还需要支持时延敏感的业务，比如智能路灯的业务，端到端时延为3-5s。在智能路灯的应用场景下，开灯和关灯命令通过寻呼消息触发终端接收下行数据。由于默认DRX周期比较大的话，则终端接收到下行(Downlink，DL)数据的时延就会比较长。

此外，终端在收到寻呼消息后，还需要2-3秒与基站建立连接，并接收下行数据。现有技术中没有提供相关的技术以解决满足时延敏感业务的时延要求，而且也没有有效减小下行数据接收时延的手段。

发明内容

本申请提供了一种寻呼消息传输方法和相关设备，能够实现一个小区内不同的寻呼周期的支持，同时满足短时延和深覆盖的终端寻呼需求。

第一方面，提供了一种寻呼消息传输方法，所述方法包括：从核心网设备接收第一寻呼消息，所述第一寻呼消息包括终端对应的第一指示，所述第一指示用于指示所述终端支持时延敏感寻呼；

确定与所述第一指示对应的第一寻呼载波组，所述第一寻呼载波组包括网络侧设备的多个寻呼载波中的部分寻呼载波；

在所述第一寻呼载波组的寻呼载波上寻呼所述终端。

实施本申请实施例，通过接收核心网设备发送的第一寻呼消息，并根据该第一寻呼消息中的第一指示，确定与该第一指示对应的第一寻呼载波组，从确定后的第一寻呼载波组中选择一个寻呼载波寻呼所述终端，可以实现对支持时延敏感的终端进行寻呼，进而可以实现一个小区内不同的寻呼周期的支持，同时满足短时延和深覆盖的终端寻呼需求。

在一种可选的实现方式中，所述方法还包括：从终端接收寻呼能力信息，所述寻呼能力信息包括第二指示，所述第二指示用于指示所述终端支持时延敏感寻呼；

向核心网设备发送寻呼能力相关信息，所述寻呼能力相关信息包括第三指示，所述第三指示用于指示所述终端支持时延敏感寻呼。

实施本申请实施例，终端可以通过向网络侧设备发送寻呼能力信息，以使网络侧设备知晓该终端设备支持时延敏感寻呼，网络侧设备可以通过向核心网设备发送寻呼能力相关信息，以使核心网设备知晓该终端设备支持时延敏感寻呼，并保存该终端设备的寻呼能力。

在一种可选的实现方式中，所述方法还包括：向所述终端发送寻呼配置，所述寻呼配置用于指示所述第一寻呼载波组和所述第一寻呼载波组的第一寻呼配置参数，所述第一寻呼配置参数包括第一默认寻呼周期DRX cycle。

在一种可选的实现方式中，所述寻呼配置还用于指示第二寻呼载波组和所述第二寻呼载波组的第二寻呼配置参数，所述第二寻呼载波组包括所述网络侧设备的所述多个载波中的另一部分寻呼载波，所述第二寻呼配置参数包括第二DRX cycle。

可以理解，网络侧设备配置了多组寻呼载波组的寻呼配置，终端通过接收网络侧设备发送的寻呼配置从而获取到不同载波组对应的寻呼配置参数。

在一种可选的实现方式中，所述第一寻呼载波组对应的DRX cycle小于所述第二寻呼载波组对应的第二DRX cycle。

实施本申请实施例，时延敏感寻呼对应的DRX cycle要比非时延敏感寻呼的DRXcycle小，终端可以根据自己的业务属性或是否支持时延敏感寻呼，从接收到的寻呼配置中选择相应的寻呼配置参数，完成后续的寻呼过程。

第二方面，提供了一种寻呼消息传输方法，所述方法包括：

从网络侧设备接收寻呼配置，所述寻呼配置用于指示第一寻呼载波组和所述第一寻呼载波组的第一寻呼配置参数，所述第一寻呼载波组包括所述网络侧设备的多个寻呼载波中的部分寻呼载波，所述第一寻呼配置参数包括第一DRX cycle，所述第一寻呼载波组与时延敏感寻呼相关联；

若终端支持时延敏感寻呼，根据所述第一寻呼配置参数，在所述第一寻呼载波组的寻呼载波上接收寻呼消息。

实施本申请实施例，网络侧设备通过对寻呼载波进行分组，并对不同组的寻呼载波进行不同的寻呼配置，再将该寻呼配置发送给终端，可以实现一个小区内不同的寻呼周期的支持，同时满足短时延和深覆盖的终端寻呼需求。

在一种可选的实现方式中，所述方法还包括：

向所述网络侧设备发送寻呼能力信息，所述寻呼能力信息包括第二指示，所述第二指示用于指示支持时延敏感寻呼。

实施本申请实施例，终端上报自己的寻呼能力信息，有利于网络侧设备确定终端对应的寻呼载波的组别，并对该终端发送寻呼消息。

在一种可选的实现方式中，所述方法还包括：

所述寻呼配置还用于指示第二寻呼载波组和所述第二寻呼载波组的第二寻呼配置参数，所述第二寻呼载波组包括所述网络侧设备的所述多个寻呼载波中的另一部分寻呼载波，所述第二寻呼配置参数包括第二DRX cycle。

实施本申请实施例，网络侧设备可以对寻呼载波进行分组，并对不同组的寻呼载波进行不同的寻呼配置得到不同的寻呼配置信息，其中，支持时延敏感寻呼的第一DRXcycle比支持非时延敏感寻呼的第二DRX cycle要小。

第三方面，提供了一种寻呼消息传输方法，所述方法包括：

从网络侧设备接收寻呼能力相关信息，所述寻呼能力相关信息包括终端对应的第一指示，所述第一指示用于指示所述终端支持时延敏感寻呼；

向所述网络侧设备发送第一寻呼消息，所述第一寻呼消息包括第二指示，所述第二指示用于指示时延敏感寻呼。

实施本申请实施例，通过向网络侧设备发送第一寻呼消息，并使该网络侧设备根据该第一寻呼消息中的第二指示，确定与所述第二指示对应的寻呼载波组，该寻呼载波组支持时延敏感寻呼，可以实现一个小区内不同的寻呼周期的支持，同时满足短时延和深覆盖的终端寻呼需求。

在一种可选的实现方式中，所述方法还包括：

接收寻呼触发消息，所述寻呼触发消息用于触发对所述终端的寻呼。

实施本申请实施例，该核心网设备在被触发的情况下，才会向该网络侧设备发送第一寻呼消息。

第四方面，提供了一种下行数据传输方法，所述方法包括：

在随机接入过程中，从终端接收消息3，所述消息3包括第一信息，所述第一信息用于指示被叫数据早传；

从第一核心网设备获取所述终端的下行数据；

向所述终端发送消息4，所述消息4包括所述下行数据。

在一种可选的实现方式中，所述第一信息为所述终端的标识，所述终端的标识与被叫数据早传具有关联关系；或者

所述第一信息为所述消息3的原因值；或者

所述第一信息为所述终端的能力信息或者类别信息；或者，

所述第一信息为用于请求进行被叫数据早传的信息。

在一种可选的实现方式中，所述从第一核心网设备获取所述终端的下行数据包括：

向所述第一核心网设备发送第二信息，所述第二信息用于指示所述终端的所述被叫数据早传；

从所述第一核心网设备接收所述终端的下行数据。

在一种可选的实现方式中，所述从第一核心网设备获取所述终端的下行数据包括：

向第二核心网设备发送第二信息，所述第二信息用于指示所述终端的所述被叫数据早传；

与所述第一核心网设备建立所述终端的数据承载；

通过所述数据承载从所述第一核心网设备接收所述终端的下行数据。

在一种可选的实现方式中，还包括：

从所述第二核心网设备接收第一消息，所述第一消息用于指示恢复所述终端的上下文。

还提供了另一种下行数据传输方法，所述方法包括：

接收终端发送的第一RRC消息，所述第一RRC消息中包括所述终端的标识；

获取所述终端的被叫早传数据指示信息；

根据所述被叫早传数据指示信息，向核心网设备发送第一请求消息，所述第一请求消息携带所述终端的被叫早传数据相关信息；

接收所述核心网设备发送的下行早传数据，并将所述下行早传数据发送给所述终端。

实施本发明实施例，网络侧设备通过获取被叫早传数据指示信息，可以提前从核心网设备获取到下行早传数据，并将该下行早传数据发送给终端，不必建立RRC连接之后才向终端发送下行数据，可以实现下行数据早传。

在一种可选的实现方式中，所述接收所述终端发送的第一RRC消息，包括：接收所述终端发送的RRC连接请求消息、RRC早传数据请求消息或RRC连接恢复请求消息。

在一种可选的实现方式中，所述获取终端的被叫早传数据指示信息包括：

接收所述核心网设备发送的第一寻呼消息，所述第一寻呼消息包括被叫早传数据指示信息和寻呼的终端标识，对所述第一寻呼消息中的终端标识和所述第一RRC消息中的终端标识进行比较，如果标识一致，则获取所述第一寻呼消息中的被叫早传数据指示信息；或者

所述第一RRC消息包括被叫早传数据请求消息，获取所述第一RRC消息中的被叫早传数据指示信息。

实施本发明实施例，网络侧设备可以从核心网设备发送的第一寻呼消息中或终端发送的第一RRC消息中获取到被叫早传数据指示信息，可以提前从核心网设备获取到下行早传数据，并将该下行早传数据发送给终端，不必建立RRC连接之后才向终端发送下行数据，可以实现下行数据早传。

在一种可选的实现方式中，所述第一RRC消息包括被叫早传数据指示信息包括：

所述第一RRC消息包括被叫早传数据指示比特；或者

所述第一RRC消息包括接入原因值，所述接入原因值为被叫接入。

实施本发明实施例，网络侧设备可以通过第一RRC消息中的被叫早传数据指示比特或接入原因值获取到被叫早传数据指示信息，简单高效，实现复杂度低。

在一种可选的实现方式中，所述方法还包括：

若所述第一RRC消息为RRC连接请求消息或RRC连接恢复请求消息，所述被叫早传数据指示信息为被叫早传数据指示比特；

若所述第一RRC消息为RRC早传数据请求消息，所述被叫早传数据指示信息为被叫早传数据指示比特或者接入原因值，所述接入原因值为被叫接入。

可以理解，若所述第一RRC消息为RRC连接请求消息或RRC连接恢复请求消息，由于RRC连接请求消息或RRC连接恢复请求消息中已经包括被叫接入的原因值，网络侧设备不能通过原因值来获取到被叫早传数据指示信息，而只能通过RRC连接请求消息或RRC连接恢复请求消息中的被叫早传数据指示比特来获取被叫早传数据指示信息。若第一RRC消息为RRC早传数据请求消息，则网络侧设备可以通过RRC早传数据请求消息的接入原因值获取到被叫早传数据指示信息，该接入原因值是被叫接入，当然，网络侧设备也可以通过RRC早传数据请求消息中的被叫早传数据指示比特来获取被叫早传数据指示信息。

第五方面，提供了一种下行数据传输方法，所述方法包括：

在随机接入过程中，向网络侧设备发送消息3，所述消息3包括第一信息，所述第一信息用于指示被叫数据早传；

从所述网络侧设备接收消息4，所述消息4包括终端的下行数据。

在一种可选的实现方式中，所述第一信息为所述终端的标识，所述终端的标识与被叫数据早传具有关联关系；或者

所述第一信息为所述消息3的原因值；或者

所述第一信息为所述终端的能力信息或者类别信息；或者，

所述第一信息为用于请求进行被叫数据早传的信息。

还提供了另一种下行数据传输方法，所述方法包括：

向网络侧设备发送第一RRC消息，所述第一RRC消息包括被叫早传数据指示信息和终端标识，所述被叫早传数据指示信息用于所述网络侧设备向核心网设备发送第一请求消息并接收所述核心网设备发送的下行早传数据；

接收所述网络侧设备发送的下行早传数据。

实施本发明实施例，网络侧设备通过接收终端发送的第一RRC消息并从该RRC消息中获取被叫早传数据指示信息，可以提前从核心网设备获取到下行早传数据，并将该下行早传数据发送给终端，不必建立RRC连接之后才向终端发送下行数据，可以实现下行数据早传。

在一种可选的实现方式中，所述向网络侧设备发送第一RRC消息，包括：向所述网络侧设备发送RRC连接请求消息、RRC早传数据请求消息或RRC连接恢复请求消息。

在一种可选的实现方式中，所述第一RRC消息包括被叫早传数据指示信息包括：

所述第一RRC消息包括被叫早传数据指示比特；或者

所述第一RRC消息包括接入原因值，所述接入原因值为被叫接入。

实施本发明实施例，网络侧设备可以通过第一RRC消息中的被叫早传数据指示比特或接入原因值获取到被叫早传数据指示信息，简单高效，实现复杂度低。

在一种可选的实现方式中，所述方法还包括：

若所述第一RRC消息为RRC连接请求消息或RRC连接恢复请求消息，所述被叫早传数据指示信息为被叫早传数据指示比特；

若所述第一RRC消息为RRC早传数据请求消息，所述被叫早传数据指示信息为被叫早传数据指示比特或者接入原因值，所述接入原因值为被叫接入。

可以理解，若所述第一RRC消息为RRC连接请求消息或RRC连接恢复请求消息，由于RRC连接请求消息或RRC连接恢复请求消息中已经包括被叫接入的原因值，网络侧设备不能通过原因值来获取到被叫早传数据指示信息，而只能通过RRC连接请求消息或RRC连接恢复请求消息中的被叫早传数据指示比特来获取被叫早传数据指示信息。若第一RRC消息为RRC早传数据请求消息，则网络侧设备可以通过RRC早传数据请求消息的接入原因值获取到被叫早传数据指示信息，该接入原因值是被叫接入，当然，网络侧设备也可以通过RRC早传数据请求消息中的被叫早传数据指示比特来获取被叫早传数据指示信息。

第六方面，提供了一种下行数据传输方法，所述方法包括：

从核心网设备接收第一寻呼消息，所述第一寻呼消息包括寻呼对象的第一标识和所述寻呼对象的下行数据；

向所述寻呼对象发送第二寻呼消息，所述第二寻呼消息包括所述寻呼对象的第二标识和所述下行数据的调度信息；

基于所述调度信息向所述寻呼对象发送所述下行数据。

在一种可选的实现方式中，还包括：

使用所述寻呼对象的无线网络临时标识RNTI对所述下行数据进行加扰；

所述基于所述调度信息向所述寻呼对象发送所述下行数据包括：

基于所述调度信息向所述寻呼对象发送加扰后的所述下行数据。

在一种可选的实现方式中，还包括：

向所述寻呼对象发送调度所述第二寻呼消息的控制信息。

在一种可选的实现方式中，还包括：

使用所述寻呼对象的无线网络临时标识RNTI对所述控制信息进行加扰；

所述向所述寻呼对象发送所述控制信息包括：

向所述寻呼对象发送加扰后的所述控制信息。

在一种可选的实现方式中，还包括：

获取所述寻呼对象的所述RNTI；

向所述寻呼对象发送所述第二标识和所述RNTI的对应关系。

在一种可选的实现方式中，所述寻呼对象为终端或者终端组。

还提供了另一种下行数据传输方法，所述方法包括：

接收核心网设备发送的第一寻呼消息，所述第一寻呼消息包括终端的寻呼能力信息和寻呼标识信息以及下行数据；

向终端发送第二寻呼消息，所述第二寻呼消息包括所述下行数据的调度信息，所述调度信息用于所述终端接收所述下行数据。

实施本申请实施例，网络侧设备通过接收核心网设备发送的第一寻呼消息并从中获取到寻呼标识信息和下行数据，再向终端发送包括该下行数据的调度信息的第二寻呼消息，可以使得终端在接收到该第二寻呼消息时就可以基于该下行数据的调度信息获取到下行数据，不需要和网络侧设备建立连接再获取下行数据，有效减少了下行数据接收的时延。

在一种可选的实现方式中，所述寻呼标识信息包括组寻呼标识和/或终端寻呼标识。

实施本申请实施例，可以实现下行组数据的快速下发。

在一种可选的实现方式中，在向终端发送第二寻呼消息之前，所述方法还包括：

根据所述组寻呼标识映射出一个组无线寻呼标识，将所述组寻呼标识和/或所述组寻呼标识与所述组无线寻呼标识的映射关系通过广播消息或专用信令发送给所述终端。

实施本申请实施例，终端可以准确快速的确定寻呼的组标识是否为自己支持的组标识。

在一种可选的实现方式中，所述向终端发送第二寻呼消息包括：

使用P-RNTI对调度所述第二寻呼消息的PDCCH进行加扰，以使所述终端接收在所述PDCCH中携带的所述第二寻呼消息的调度信息，并根据所述调度信息接收物理下行共享信道PDSCH上发送的所述第二寻呼消息。

实施本申请实施例，通过使用P-RNTI对调度所述第二寻呼消息的PDCCH进行加扰，以使处于空闲态的终端使用P-RNTI监听调度所述第二寻呼消息的PDCCH，可以使得终端快速准确的接收第二寻呼消息的调度信息。

在一种可选的实现方式中，所述向终端发送第二寻呼消息包括：

使用Group-RNTI对调度所述第二寻呼消息的PDCCH进行加扰，以使所述终端接收在所述PDCCH中携带的所述第二寻呼消息的调度信息，并根据所述调度信息接收PDSCH上发送的所述第二寻呼消息。

实施本申请实施例，组标识可以通过Group-RNTI来进行区分，终端通过接收不同的Group-RNTI来判断接收对应的下行组数据。

第七方面，提供了一种下行数据传输方法，所述方法包括：

终端从网络侧设备接收第一寻呼消息，所述第一寻呼消息包括寻呼对象的标识和所述寻呼对象的下行数据的调度信息；

若所述寻呼对象的标识与所述终端的寻呼标识匹配，所述终端基于所述调度信息接收所述下行数据。

在一种可选的实现方式中，所述下行数据是使用所述寻呼对象的无线网络临时标识RNTI加扰的。

在一种可选的实现方式中，还包括：

从所述网络侧设备接收调度所述第二寻呼消息的控制信息。

在一种可选的实现方式中，所述控制信息是使用所述寻呼对象的无线网络临时标识RNTI加扰的。

在一种可选的实现方式中，还包括：

从所述网络侧设备接收所述第二标识和所述RNTI的对应关系。

在一种可选的实现方式中，所述寻呼对象为所述终端或者所述终端所属的终端组。

还提供了另一种下行数据传输方法，所述方法包括：

接收网络侧设备发送的第二寻呼消息，所述第二寻呼消息包括下行数据的调度信息；

根据所述下行数据的调度信息，获取所述第二寻呼消息中的下行数据。

实施本申请实施例，终端通过接收网络侧设备发送的第二寻呼消息并根据该第二寻呼消息中的下行数据的调度信息获取下行数据，不需要和网络侧设备建立连接后再获取下行数据，直接从网络侧设备发送的寻呼消息中获取下行数据，有效减少了下行数据接收的时延。

在一种可选的实现方式中，在接收网络侧设备发送的第二寻呼消息之前，所述方法还包括：

接收所述网络侧设备通过广播消息或专用信令发送的组寻呼标识和/或所述组寻呼标识与组无线寻呼标识的映射关系，所述映射关系包括所述网络侧设备根据所述组寻呼标识映射出一个组无线寻呼标识。

实施本申请实施例，终端可以准确快速的确定寻呼的组标识是否为自己支持的组标识。

在一种可选的实现方式中，所述接收网络侧设备发送的第二寻呼消息，包括：

使用P-RNTI监听调度所述第二寻呼消息的PDCCH，接收在所述PDCCH中携带的所述第二寻呼消息的调度信息，并根据所述调度信息接收PDSCH上发送的所述第二寻呼消息。

实施本申请实施例，通过使用P-RNTI对调度所述第二寻呼消息的PDCCH进行加扰，以使处于空闲态的终端使用P-RNTI监听调度所述第二寻呼消息的PDCCH，可以使得终端快速准确的接收第二寻呼消息的调度信息。

在一种可选的实现方式中，所述接收网络侧设备发送的第二寻呼消息，包括：

使用Group-RNTI监听调度所述第二寻呼消息的PDCCH，接收在所述PDCCH中携带的所述第二寻呼消息的调度信息，并根据所述调度信息接收PDSCH上发送的所述第二寻呼消息。

实施本申请实施例，组标识可以通过Group-RNTI来进行区分，终端通过接收不同的Group-RNTI来判断接收对应的下行组数据。

第八方面，提供了一种网络侧设备，所述网络侧设备为第一方面、第四方面或第六方面，或者第一方面、第四方面或第六方面中的任意一个可选的实现方式所描述的网络侧设备。

第九方面，提供了一种终端设备，所述终端设备为第二方面、第五方面或第七方面，或者第二方面、第五方面或第七方面中的任意一个可选的实现方式所描述的终端设备。

第十方面，提供了一种核心网设备，所述核心网设备为第三方面或者第三方面中的任意一个可选的实现方式所描述的核心网设备。

第十一方面，提供了一种网络侧设备，所述网络侧设备包括：处理器、存储器和收发器，其中：

所述处理器、所述存储器和所述收发器相互连接，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行以下步骤：

从核心网设备接收第一寻呼消息，所述第一寻呼消息包括终端对应的第一指示，所述第一指示用于指示所述终端支持时延敏感寻呼；

确定与所述第一指示对应的寻呼载波组，所述寻呼载波组包括一个或多个寻呼载波；

在所述寻呼载波组的载波上寻呼所述终端。

第十二方面，提供了一种终端设备，所述终端设备包括：处理器、存储器和收发器，其中：

所述处理器、所述存储器和所述收发器相互连接，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行以下步骤：

从网络侧设备接收寻呼配置，所述寻呼配置用于指示第一寻呼载波组和所述第一寻呼载波组的第一寻呼配置参数，所述第一寻呼载波组包括所述网络侧设备的多个寻呼载波中的部分寻呼载波，所述第一寻呼配置参数包括第一DRX cycle，所述第一寻呼载波组与时延敏感寻呼相关联；

若终端支持时延敏感寻呼，根据所述第一寻呼配置参数，在所述第一寻呼载波组的寻呼载波上接收寻呼消息。

第十三方面，提供了一种核心网设备，所述核心网设备包括：处理器、存储器和收发器，其中：

所述处理器、所述存储器和所述收发器相互连接，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行以下步骤：

从网络侧设备接收寻呼能力相关信息，所述寻呼能力相关信息包括终端对应的第一指示，所述第一指示用于指示所述终端支持时延敏感寻呼；

向所述网络侧设备发送第一寻呼消息，所述第一寻呼消息包括第二指示，所述第二指示用于指示时延敏感寻呼。

第十四方面，提供了一种网络侧设备，所述网络侧设备包括：处理器、存储器和收发器，其中：

所述处理器、所述存储器和所述收发器相互连接，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行以下步骤：

在随机接入过程中，从终端接收消息3，所述消息3包括第一信息，所述第一信息用于指示被叫数据早传；

从第一核心网设备获取所述终端的下行数据；

向所述终端发送消息4，所述消息4包括所述下行数据。

第十五方面，提供了一种终端设备，所述终端设备包括：处理器、存储器和收发器，其中：

所述处理器、所述存储器和所述收发器相互连接，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行以下步骤：

在随机接入过程中，向网络侧设备发送消息3，所述消息3包括第一信息，所述第一信息用于指示被叫数据早传；

从所述网络侧设备接收消息4，所述消息4包括终端的下行数据。

第十六方面，提供了一种网络侧设备，所述网络侧设备包括：处理器、存储器和收发器，其中：

所述处理器、所述存储器和所述收发器相互连接，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行以下步骤：

从核心网设备接收第一寻呼消息，所述第一寻呼消息包括寻呼对象的第一标识和所述寻呼对象的下行数据；

向所述寻呼对象发送第二寻呼消息，所述第二寻呼消息包括所述寻呼对象的第二标识和所述下行数据的调度信息；

基于所述调度信息向所述寻呼对象发送所述下行数据。

第十七方面，提供了一种终端设备，所述终端设备包括：处理器、存储器和收发器，其中：

所述处理器、所述存储器和所述收发器相互连接，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行以下步骤：

终端从网络侧设备接收第一寻呼消息，所述第一寻呼消息包括寻呼对象的标识和所述寻呼对象的下行数据的调度信息；

若所述寻呼对象的标识与所述终端的寻呼标识匹配，所述终端基于所述调度信息接收所述下行数据。

第十八方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被网络侧设备的处理器执行时，使所述网络侧设备的处理器执行上述第一方面或者第一方面的任意一个可选的实现方式所描述的方法；或者所述程序指令当被终端设备的处理器执行时，使所述终端设备的处理器执行上述第二方面或者第二方面的任意一个可选的实现方式所描述的方法，或者所述程序指令当被核心网设备的处理器执行时，使所述核心网设备的处理器执行上述第三方面或者第三方面的任意一个可选的实现方式所描述的方法。

第十九方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被网络侧设备的处理器执行时，使所述网络侧设备的处理器执行上述第四方面或者第四方面的任意一个可选的实现方式所描述的方法；或者所述程序指令当被终端设备的处理器执行时，使所述终端设备的处理器执行上述第五方面或者第五方面的任意一个可选的实现方式所描述的方法。

第二十方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被网络侧设备的处理器执行时，使所述网络侧设备的处理器执行上述第七方面或者第七方面的任意一个可选的实现方式所描述的方法；或者所述程序指令当被终端设备的处理器执行时，使所述终端设备的处理器执行上述第八方面或者第八方面的任意一个可选的实现方式所描述的方法。

附图说明

图1为本申请实施例提供的一种NB-IoT的网络连接示意图；

图2为本申请实施例提供的一种寻呼消息传输方法的流程示意图；

图3为本申请实施例提供的另一种寻呼消息传输方法的流程示意图；

图4为本申请实施例提供的一种寻呼载波分组示意图；

图5为本申请实施例提供的一种下行数据传输方法的流程示意图；

图6为本申请实施例提供的另一种下行数据传输方法的流程示意图；

图7为本申请实施例提供的另一种下行数据传输方法的流程示意图；

图8为本申请实施例提供的另一种下行数据传输方法的流程示意图；

图9为本申请实施例提供的一种网络侧设备的结构示意图；

图10为本申请实施例提供的另一种网络侧设备的结构示意图；

图11为本申请实施例提供的另一种网络侧设备的结构示意图；

图12为本申请实施例提供的另一种网络侧设备的结构示意图；

图13为本申请实施例提供的另一种网络侧设备的结构示意图；

图14为本申请实施例提供的另一种网络侧设备的结构示意图。

具体实施方式

下面将结合附图对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例的技术方案可以应用于各种通信系统，例如：全球移动通讯(globalsystem of mobile communication，GSM)系统、码分多址(code division multipleaccess，CDMA)系统、宽带码分多址(wideband code division multiple access，WCDMA)系统、通用分组无线业务(general packet radio service，GPRS)、长期演进(long termevolution，LTE)系统、LTE频分双工(frequency division duplex，FDD)系统、LTE时分双工(time division duplex，TDD)、通用移动通信系统(universal mobiletelecommunication system，UMTS)、全球互联微波接入(worldwide interoperabilityfor microwave access，WiMAX)通信系统、未来的第五代(5th generation，5G)系统或新无线(new radio，NR)等。

本申请实施例涉及的终端设备，可以指用户设备、接入终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置。终端设备还可以是蜂窝电话、无绳电话、会话启动协议(session initiationprotocol，SIP)电话、无线本地环路(wireless local loop，WLL)站、个人数字处理(personal digital assistant，PDA)、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备，未来5G网络中的终端设备或者未来演进的公用陆地移动通信网络(public land mobile network，PLMN)中的终端设备等，本申请实施例对此并不限定。

本申请实施例涉及的网络设备可以是用于与终端设备通信的设备。该网络设备可以是任意一种具有无线收发功能的设备或可设置于该设备的芯片，该设备包括但不限于：演进型节点B(evolved Node B，eNB)、无线网络控制器(radio network controller，RNC)、节点B(Node B，NB)、基站控制器(base station controller，BSC)、基站收发台(basetransceiver station，BTS)、家庭基站(例如，home evolved NodeB，或home Node B，HNB)、基带单元(base band Unit，BBU)，无线保真(wireless fidelity，WIFI)系统中的接入点(access point，AP)、无线中继节点、无线回传节点、传输点(transmission point，TP)或者发送接收点(transmission and reception point，TRP)等，还可以为5G，如，NR，系统中的gNB，或，传输点(TRP或TP)，5G系统中的基站的一个或一组(包括多个天线面板)天线面板，或者，还可以为构成gNB或传输点的网络节点，如基带单元(BBU)，或，分布式单元(distributed unit，DU)等。

在一些部署中，gNB可以包括集中式单元(centralized unit，CU)和DU。gNB还可以包括射频单元(radiounit，RU)。CU实现gNB的部分功能，DU实现gNB的部分功能，比如，CU实现无线资源控制(radio resource control，RRC)，分组数据汇聚层协议(packet dataconvergence protocol，PDCP)层的功能，DU实现无线链路控制(radio linkcontrol，RLC)、媒体接入控制(mediaaccess control，MAC)和物理(physical，PHY)层的功能。由于RRC层的信息最终会变成PHY层的信息，或者，由PHY层的信息转变而来，因而，在这种架构下，高层信令，如RRC层信令或PHCP层信令，也可以认为是由DU发送的，或者，由DU+RU发送的。可以理解的是，网络设备可以为CU节点、或DU节点、或包括CU节点和DU节点的设备。此外，CU可以划分为接入网RAN中的网络设备，也可以将CU划分为核心网CN中的网络设备，在此不做限制。

本申请实施例中，核心网设备可以是移动性管理实体(Mobility ManagementEntity)、蜂窝物联网服务网关节点(CIoT serving gateway node，C-SGN)、服务网关(Serving GateWay，SGW)、分组数据网关(packet data network gateway，P-GW)或归属用户服务器(Home Subscriber Server，HSS)等。需要说明的是，在本申请实施例中并不限定核心网设备的具体类型。

本申请实施例提供的一种寻呼消息传输方法及相关设备，包括但不局限适用于物理层改变之后的窄带物联网(Narrow Band-Internet of Things，NB-IoT)网络和机器类通信(Machine-Type Communication，MTC)网络。3GPP标准基于蜂窝网络，通过设计新的空口，充分利用窄带技术的特点，来承载物联网(Internet of Things，IoT)业务，这一类物联网被称为NB-IoT。如图1所示为NB-IoT的网络连接示意图，NB-IoT中包括基站和终端设备(图1除基站之外的设备为终端设备)，基站与终端设备、基站与基站、终端设备与终端设备之间互相连接。与传统蜂窝网络相比，NB-IoT的业务具有速率低、周期长的特点，NB-IoT支持连接海量的终端设备，NB-IoT要求与其连接的终端设备成本低、低功耗。在物联网中，每个小区当前使用的寻呼的默认非连续接收周期值(Discontinuous Reception cycle，DRXcycle)只有一个，而在一个小区中可能会同时存在深覆盖等级的终端和非深覆盖的终端，由于基站的默认DRX cycle的配置会满足深覆盖终端而选用的值比较大，终端接收到下行数据的时延就会比较长。

如果基站只配置一个默认的DRX cycle，就会无法满足对于时延敏感的终端或具有时延敏感业务的终端对于时延的要求。本申请实施例提供的一种寻呼消息传输方法及相关设备，将在一个小区中配置两个或多个默认DRX cycle，分别用于对时延敏感终端(非深覆盖终端)和非时延敏感终端(深覆盖终端)的寻呼。其中，方法和相关设备是基于同一方面构思的，由于方法和相关设备解决问题的原理相似，因此相关设备与方法的实施可以相互参见，重复之处不再赘述。

下面详细介绍本申请实施例提供的一种寻呼消息传输方法及相关设备。需要说明的是，本申请实施例的展示顺序仅代表实施例的先后顺序，并不代表实施例所提供的技术方案的优劣。

请参见图2，图2是本申请实施例提供的一种寻呼消息传输方法的流程示意图，该方法包括但不限于以下步骤：

S201：从核心网设备接收第一寻呼消息，所述第一寻呼消息包括终端对应的第一指示，所述第一指示用于指示所述终端支持时延敏感寻呼。

需要说明的是，终端设备可以理解为用户设备(User Equipment，UE)，核心网设备可以理解为MME，网络侧设备可以理解为基站。

具体地，第一指示可以是在UE上报的寻呼能力中增加的是否支持时延敏感寻呼的能力信息，也可以是在UE上报的寻呼能力中增加的是否为非深覆盖的信息。

需要说明的是，在NB-IoT或MTC系统中，大部分的终端的业务不是时延敏感的，比如智能水/电表或智能家居等，它们默认的DRX cycle比较大，比如10.24秒，而有一些终端的业务是时延敏感的，比如智能电灯，它们默认的DRX cycle就需要比较小，比如1.024秒，所以支持时延敏感的寻呼的DRX cycle要比非时延敏感的寻呼的DRX cycle小。

在一种可能的实现方式中，所述方法还包括：从终端接收寻呼能力信息，所述寻呼能力信息包括第二指示，所述第二指示用于指示所述终端支持时延敏感寻呼；向核心网设备发送寻呼能力相关信息，所述寻呼能力相关信息包括第三指示，所述第三指示用于指示所述终端支持时延敏感寻呼。

具体地，在接收核心网设备发送的第一寻呼消息之前，基站需要从UE获取到UE的寻呼能力信息，并将该UE的寻呼能力信息和寻呼的覆盖信息(即PDCCH重复次数相关信息)发送给MME，因此，UE需要建立无线资源控制协议(Radio Resource Control，RRC)连接并与基站进行数据通信，通信过程包括attach/TAU等非接入层(Non-Access Stratum，NAS)层信令交互过程或者数据传输过程。其中，UE可以向基站发送UE能力消息(UE capabilityinformation)到基站，其中携带UE的寻呼能力信息，该寻呼能力信息中包括UE的类别信息，以及UE的多载波寻呼支持能力等，该寻呼能力信息还包括该UE支持敏感寻呼的信息。

在UE与基站数据通信结束后，基站向MME发送UE上下文释放完成消息，由于基站在与UE数据通信的过程中获取到了UE寻呼能力信息和寻呼的覆盖信息，寻呼的覆盖信息即为UE接收寻呼的物理下行控制信道(Physical Downlink Control Channel，PDCCH)的重复次数，对于深覆盖UE来说，接收寻呼的PDCCH的重复次数多，对于非深覆盖UE则相反，接收寻呼的PDCCH的重复次数比较少。所以基站通过向MME发送上下文释放消息中提供UE寻呼的覆盖增强等级信息，MME在接收到该覆盖增强等级信息后，对该覆盖增强等级信息进行保存。基站通过向MME发送UE能力信息指示消息(UE capability info indication)提供UE的寻呼能力信息，UE的寻呼能力信息即为UE接收寻呼消息的能力，包括UE的类别和是否支持多载波寻呼，以及多载波寻呼的频带等任一信息，UE可以在UE的寻呼能力信息中携带UE的寻呼能力，该能力在标准上可以为UE的无线寻呼能力。MME在收到UE能力信息指示消息后，保存UE的寻呼能力。基站向UE发送连接释放消息，UE在收到该连接释放消息后释放RRC连接，UE由RRC连接态进入RRC空闲态。

在MME从SGW获取到发送给某个UE的下行数据到达通知后，基站接收MME发送的第一寻呼消息，该第一寻呼消息携带UE的寻呼的覆盖增强等级信息和UE的寻呼能力信息。MME可以在第一寻呼消息中的UE Radio Capability for Paging中携带UE的新增的寻呼能力信息，在Assistance Data for Paging中携带寻呼的PDCCH的重复次数的信息。需要说明的是，这里的第一寻呼消息仅仅是为了区分基站向UE发送的寻呼消息，并不对该寻呼消息做出其他限制。

S202：确定与所述第一指示对应的第一寻呼载波组，所述第一寻呼载波组包括网络侧设备的多个寻呼载波中的部分寻呼载波。

由于在现有技术中，在同一个小区中，所有的载波(锚点载波和非锚点载波)都是支持相同的唯一的DRX cycle，所以基站需要对用于寻呼的载波进行重新配置，一种较好的方式是对所有的非锚寻呼载波进行分组，不同组的载波对应不同的寻呼配置。

在一种可能的实现方式中，向所述终端发送寻呼配置，所述寻呼配置用于指示所述第一寻呼载波组和所述第一寻呼载波组的第一寻呼配置参数，所述第一寻呼配置参数包括第一默认寻呼周期DRX cycle。

具体地，基站为了支持时延敏感或非深覆盖的终端，需要将一部分寻呼载波进行重新配置。由于不同的寻呼列表中的寻呼载波其对应的DRX cycle和nB的值是不一样的，所以基站必须对其进行重配置。

进一步的，基站需要在寻呼载波的寻呼控制信道(Paging Control Channel，PCCH)配置上，配置一个新的载波列表，新的默认DRX cycle值和nB，用来支持时延敏感的寻呼。

在一种可能的实现方式中，所述第一寻呼配置参数还包括：物理下行控制信道PDCCH重复次数和寻呼载波对应的权重值weight。

由于PDCCH重复次数和寻呼载波对应的权重值weight这两个参数可以引用之前默认的配置，所以基站可以选择不对其进行配置，当然，基站也可以在配置了新的默认DRXcycle和nB的基础上，对PDCCH重复次数和寻呼载波对应的权重值weight也进行重新配置，这两个参数主要用于后续的寻呼载波的计算。

在一种可能的实现方式中，所述寻呼配置还用于指示第二寻呼载波组和所述第二寻呼载波组的第二寻呼配置参数，所述第二寻呼载波组包括所述网络侧设备的所述多个载波中的另一部分寻呼载波，所述第二寻呼配置参数包括第二DRX cycle。

具体地，基站配置了两组寻呼载波组的寻呼配置参数，并将配置好的寻呼配置参数通过系统信息的方式发送给UE或通过广播方式向UE发送该寻呼配置参数，值得说明的是，这两组寻呼配置参数可以通过一个系统消息发送给UE，也可以通过不同的系统消息发送给UE。这两组寻呼载波组中，一组是用于支持时延敏感寻呼的，所以其对应的DRX cycle相应的就比较小，而另一组是用于支持非时延敏感寻呼的，所以其对应的DRX cycle就比较大，UE在接收到基站发送的寻呼配置参数后，会根据自身的业务情况或者是否是支持时延敏感的，选择相对应的一套寻呼配置参数。

S203：在所述第一寻呼载波组的寻呼载波上寻呼所述终端。

具体地，基站在确定了UE对应的寻呼载波的组别后，从确定了的寻呼载波组中选择一个寻呼载波进行寻呼，基站通过一种具体的算法公式从确定了的寻呼载波组中计算得到用于寻呼的一个寻呼载波，对于不同的系统，具体计算方法也有差异。

需要说明的是，基站通过执行上述算法公式后，可以从确定了的寻呼载波组中选择唯一一个寻呼载波进行寻呼，UE会通过相同的计算方法得到相同的寻呼载波，并在该寻呼载波上接收基站发送的寻呼消息。一般来说，基站和UE计算得到相同的一个寻呼载波后，基站和UE会一直用该寻呼载波发送和接收寻呼消息，但是在每次寻呼过程中，基站和UE都会再通过相同的计算方法再计算一次。

实施本申请实施例，基站通过将寻呼载波进行分组，并对不同组的寻呼载波进行具体的寻呼配置，可以实现一个小区内不同的寻呼周期的支持，同时满足短时延和深覆盖的UE的寻呼需求。

请参见图3，图3是本申请实施例提供的另一种寻呼消息传输方法的流程示意图，该方法包括但不限于以下步骤：

S301：UE与基站进行数据通信。

具体地，UE是在建立了无线资源控制协议(Radio Resource Control，RRC)连接之后与基站进行数据通信，通信过程包括attach/TAU等非接入层(Non-Access Stratum，NAS)层信令交互过程或者数据传输过程，其中，UE可以向基站发送UE能力消息(UE capabilityinformation)，其中携带UE的寻呼能力信息，该寻呼能力信息中包括UE的类别信息以及UE的多载波寻呼支持能力等。

进一步的，UE在自己的寻呼能力中增加是否支持时延敏感寻呼的能力，且UE在与基站进行数据通信时，UE会根据自己的业务需求向基站上报是否支持时延敏感寻呼，即UE在上报的寻呼能力信息中会增加一个支持时延敏感的配置，具体如下：

对于支持时延敏感的寻呼的信元的名字，可以是LatencysensitivePaging-r16或者其他的EnhPaging-r16。这里是假定的R16做这种寻呼增强，所以信元的名字后面都加上R16。如果该技术在其他的版本实现，信元的后面加上其他的版本后缀，本申请对于具体采用哪种版本并不做出限制。通过上述配置，基站能够根据UE的寻呼能力信息获取到UE是否支持时延敏感寻呼。

数据通信结束后，基站向UE发送连接释放消息，UE在收到该连接释放消息后释放RRC连接，UE由RRC连接态进入空闲态。

S302：基站向MME发送UE上下文释放完成消息和UE能力信息指示消息。

具体地，在UE与基站数据通信结束后，基站向MME发送UE上下文释放完成消息，由于基站在与UE数据通信的过程中获取到了UE寻呼能力信息和寻呼的覆盖信息，寻呼的覆盖信息即为UE接收寻呼的物理下行控制信道(Physical Downlink Control Channel，PDCCH)的重复次数，对于深覆盖UE来说，接收寻呼的PDCCH的重复次数多，对于非深覆盖UE则相反，接收寻呼的PDCCH的重复次数比较少。所以基站通过向MME发送上下文释放消息中提供UE寻呼的覆盖增强等级信息，MME在接收到该覆盖增强等级信息后，对该覆盖增强等级信息进行保存。基站通过向MME发送UE能力信息指示消息(UE capability info indication)提供UE的寻呼能力信息，UE的寻呼能力信息即为UE接收寻呼消息的能力，包括UE的类别和是否支持多载波寻呼，以及多载波寻呼的频带等任一信息，UE可以在UE的寻呼能力信息中携带UE的寻呼能力，该能力在标准上可以为UE的无线寻呼能力。MME在收到UE能力信息指示消息后，保存UE的寻呼能力。

S303：MME从SGW获取到下行数据到达通知后，MME向基站发送第一寻呼消息。

具体地，当MME从SGW获取到发送给某个UE的下行数据到达通知后向基站发送第一寻呼消息，该第一寻呼消息携带UE的覆盖增强等级信息和UE的寻呼能力相关信息。MME可以在第一寻呼消息中的UE Radio Capability for Paging中携带UE的新增的寻呼能力信息，在Assistance Data for Paging中携带UE的增强覆盖等级信息(寻呼的PDCCH的重复次数的信息)。需要说明的是，这里的第一寻呼消息仅仅是为了区分基站向UE发送的寻呼消息，并不对该寻呼消息做出其他限制。

需要说明的是，步骤S302和步骤S303之间没有时间上的逻辑关系，即在步骤S302之后并不需要立即执行步骤S303,可以是经过一段时间后，MME从SGW获取到下行数据到达通知后，再执行步骤S303。

S304：基站根据UE的寻呼能力相关信息，确定UE对应的寻呼载波组。

具体地，为了扩展寻呼容量，在NB-IoT中最多支持16个载波，其中有一个为锚点载波，其它的为非锚点载波。锚点载波和非锚点载波都可以用于寻呼。

由于在现有技术中，在同一个小区中，所有的载波(锚点载波和非锚点载波)都是支持相同的唯一的DRX cycle，所以基站需要对用于寻呼的载波进行重新配置，一种较好的方式是对所有的非锚点寻呼载波进行分组，不同组的载波对应不同的寻呼配置。

具体地，如图4所示，基站为了支持时延敏感或非深覆盖的终端，需要将一部分寻呼载波进行重新配置。基站将所有的非锚点寻呼载波分为两组，上面一组(寻呼载波较少的一组)是需要重新配置的，剩下的一组和锚点载波仍用原来的配置，其对应的DRX cycle仍为之前基站默认的DRX cycle。

进一步的，基站需要在寻呼载波的寻呼控制信道(Paging Control Channel，PCCH)配置上，配置一个新的寻呼载波列表，新的默认DRX cycle值，寻呼周期的数量(nB)，PDCCH重复次数，寻呼载波对应的权重值(weight)等。对于PCCH的配置，通过对系统信息块2(System Information Block，SIB2)和SIB22上的配置修改为例，进行具体的说明。

在SIB22的PCCH配置中，增加如下的配置：

r16和r14代表不同的版本，其它版本的表达方式类似。通过上述配置，可以看出，在PCCH的R16的配置中，增加了支持时延敏感寻呼的寻呼载波列表的配置SIZE(1..maxNonAnchorCarriers-NB-r14)，表示新的载波列表中可以最多包括15个非锚点寻呼载波或者它们之间的任意组合，增加了支持时延敏感寻呼的终端对应的寻呼默认DRXcycle的配置{rf128,rf256,rf512,rf1024}，其中，rf128对应128个系统帧，rf256对应256个系统帧，以此类推，每个系统帧的时间长度是10毫秒，基站可以选择这四个值中的任意一个作为默认的DRX cycle，对于支持时延敏感寻呼的载波，基站一般会选择较小的值作为默认的DRX cycle。增加了nB的配置{fourT，twoT，halfT，one8thT，…one1024thT}，nB主要用于推导寻呼帧(Paging Frame，PF)和寻呼时机(Paging Occasion，PO)，其中，twoT对应2*T，one8thT对应1/8*T，以此类推。另外，对于支持时延(非时延敏感)的下行寻呼载波重用现有的R14的配置，其中包括寻呼载波的列表，每个寻呼载波上PDCCH的重复次数，每个寻呼载波对应的weight值等。

可以看出，通过上述的具体配置，可以将一部分寻呼载波的默认DRX cycle和nB等寻呼参数进行重新配置以满足支持时延敏感寻呼的要求。

除了上述配置方式，还可以使用另外一种配置方式。比如在现有的SIB2的R13的PCCH的配置基础上，增加一个时延敏感的DRX的配置，具体如下：

在SIB22的PCCH配置中，增加如下的配置：

这种配置方式与上述配置方式的区别在于，只是引用现有SIB2的R13的PCCH配置的基础上，增加了一个使能条件latencysensitive，在SIB22的PCCH配置中增加了支持时延敏感寻呼对应的寻呼载波列表的配置SIZE(1..maxNonAnchorCarriers-NB-r14)，如果终端是时延敏感的，就需要选用该配置。需要说明的是，该使能条件一旦确定，是不能更改的，不能动态的进行再配置。

基站经过上述配置后，会将相应的配置信息通过系统信息广播等方式发送给UE，此外，基站在接收到的MME发送的UE的寻呼能力相关信息后，就可以确定UE对应的寻呼载波组。比如，基站将所有的寻呼载波分为了两组，第一组没有进行改变，仍旧保持原先的配置参数等不变，其对应的DRX cycle较大，第二组进行了重新配置，用于支持时延敏感的寻呼，其对应的DRX cycle较小，若基站接收到MME发送的UE的寻呼能力相关信息后，发现该UE是支持时延敏感寻呼的，那么基站就会确定选用第二组寻呼载波对该UE进行寻呼。

可以理解的是，上述为UE分配不同的寻呼所在的载波都是基于时延(即是否支持时延敏感)的分配方式，当然也可以按照终端的覆盖需求为UE分配不同的寻呼所在的载波，具体的分配方式与基于时延的分配方式类似，不同之处在于，在PCCH-config-r16中，该IE的条件是NonDeepCoverage，此外，在UE的寻呼能力信息中，信元的名字可以是NonDeepCoveragePaging-r16，如果该技术在其他的版本实现，信元的后面加上其他的版本后缀，本申请对于具体采用哪种版本并不做出限制。除此之外，其它的具体配置与基于时延的配置完全相同，在此不再赘述。

需要说明的是，上述在SIB2和SIB22上的配置进行修改只是示例性的说明，当然也可以使用其它的SIB进行具体的配置，而且在实施例中，只是将寻呼载波分为了两组寻呼载波组并进行相应的配置，当然也可以将寻呼载波分为多组并进行相应的配置即可，本申请并不对此做出限制。

可以看出，基站通过对寻呼载波进行分组，并对不同组的寻呼载波进行了重新配置，可以使得基站根据UE对应的寻呼能力信息，确定UE对应的寻呼载波的组别，实现一个小区内不同的寻呼周期的支持，同时满足短时延和深覆盖的UE的寻呼需求。

S305：基站选择第一寻呼载波向UE发送第二寻呼消息。

具体地，基站在确定了UE对应的寻呼载波的组别后，从确定了的寻呼载波组中选择一个寻呼载波进行寻呼。

基站需要通过一种具体的算法从确定了的寻呼载波组中计算得到用于寻呼的载波，对于不同的系统，基站的具体计算方法也有差异。对于NB-IoT系统而言，可以通过公式(1)计算得到相应的寻呼载波，公式(1)如下所示：

其中，T表示UE的寻呼周期，即基站默认的DRX cycle，该DRX cycle是从{rf128,rf256,rf512,rf1024}中选择的一个值，在系统消息中会提供该寻呼周期的值，对于寻呼增强的情况下(假设R16做寻呼增强)，该周期值为PCCH-Config-NB-r16中提供的值。nB表示寻呼周期的数量，实际上，nB表示在每个DRX cycle内包含了多少个PO，在系统消息中会提供该nB的值，对于寻呼增强的情况下(假设R16做寻呼增强)，该nB的值为PCCH-Config-NB-r16中提供的值，nB的取值可以是4T,2T,T,T/2,T/4,T/8,T/16,T/32,T/64,T/128,T/256,对于NB-IoT系统而言，nB的取值还可以是T/512或T/1024。N表示T和nB中取较小的一个值，实际上N表示在每个DRX cycle内包含了多少个PF，Ns表示1和nB/T中取较大的一个值，实际上Ns表示在每个PF内包含了多少个PO。UE_ID＝IMSI mod 16384，IMSI表示国际移动用户识别码，mod表示模运算，即UE_ID表示IMSI除以16384的余数。MaxPagingCarriers表示基站支持寻呼的非锚点载波的个数，对于寻呼增强的情况下(假设R16做寻呼增强)，该非锚点载波的个数是r16的IE中指示的个数，比如，dl-ConfigList-r16中的载波个数。Weight(i)表示寻呼i的权重，对于寻呼增强的情况下(假设R16做寻呼增强)，该寻呼权重是r16的IE中指示的weight，比如，dl-ConfigList-r16中的配置的每个载波的权重。

对于MTC系统而言，可以通过公式(2)计算得到相应的寻呼载波，公式(2)如下所示：

PNB＝floor(UE_ID/(N*Ns))mod Nn

其中，Nn表示基站支持寻呼的非锚点载波的个数，对于寻呼增强的情况下(假设R16做寻呼增强)，该非锚点载波的个数是r16的IE中指示的个数，比如，dl-ConfigList-r16中的载波个数。其它的参数符号所代表的含义与NB-IoT系统中的完全一致，在此不再赘述。

可以理解，基站通过执行上述算法可以从确定了的寻呼载波组中选择唯一一个寻呼载波进行寻呼，这里为了区分该寻呼载波组中的其它载波，所以使用了第一寻呼载波来突出该载波是基站经过计算得到用于寻呼某个UE的载波，应当理解，本申请并不对此做出限制。

基站在选择了寻呼载波之后，向终端发送第二寻呼消息，终端从基站发送的系统消息中获取到相关寻呼配置，并从该寻呼配置中获取到相应的配置参数，根据该配置参数，并基于相同的算法计算得到相应的寻呼载波，并在该寻呼载波上接收基站发送的第二寻呼消息，可以理解，UE计算得到的寻呼载波与基站计算得到的寻呼载波应该是一致的。这里的第二寻呼消息仅仅是为了区分核心网设备向基站发送的寻呼消息，并不对该寻呼消息做出其它的限制。

值得说明的是，基站会先向UE发送广播消息，该广播消息里包括SIB22中包含的配置信息，UE在读取广播消息后，会根据其中的配置信息以及自己的DRX cycle，确定对应的PF的对应PO上醒来，去监听使用P-RNTI加扰的PDCCH。如果UE在PO上检测到使用P-RNTI加扰的PDCCH，UE会去读取PagingRecordlist中的每一个PagingRecord，PagingRecord中包含了被寻呼的UE的标识UE-Identity，如果UE发现自己的UE标识与某个UE-Identity一致，就会把UE-Identity和cn-Domain发往上层继续处理，如果UE没有找到一个与其UE标识一致的UE-Identity，UE会丢弃接收到的寻呼消息，并进入休眠以降低功耗。

进一步的，UE和核心网设备在NAS层协商确定了自己的DRX cycle后，核心网设备会保存该UE的DRX cycle，核心网设备在下发寻呼消息时会将该UE的DRX cycle和UE标识等信息携带在第一寻呼消息中下发给基站，基站根据这些信息计算UE的PF和PO，并在对应的PO上发送寻呼消息，而UE也会根据自己的DRX cycle和UE标识等信息计算PF和PO，并在对应的PO上接收基站发送的寻呼消息。需要说明的是，UE计算得到的PF和PO与基站计算得到的PF和PO是相同的，这样才能准确的完成寻呼消息的发送和接收。具体地，PF是满足基站公式(3)的系统帧，公式(3)为：

SFNmodT＝(TdivN)*(UE_IDmodN)；

使用索引(i_s)查表可以得到PO，其中，i_s满足公式(4)，公式(4)为：

i_s＝floor(UE_ID/N)modNs；

其中，SFN表示系统帧号(System Frame Number)，T表示基站默认的DRX cycle，N表示T和nB中较小的一个值，实际上表示在每个DRX cycle内包含了多少个PF，UE_ID表示IMSImod1024。可以看出，TdivN相当于把一个DRX cycle等分成N份后，每一份包含的系统帧数；UE_IDmodN相当于取N等份里的第i份，i的取值范围是0到N-1，而PF为其中的第一个系统帧。

对于某个具体的UE来说，PF就是用于发送寻呼消息的系统帧，PO就是该PF内用于发送寻呼消息的子帧。可以看出，TdivN相当于把一个DRX cycle等分成N份后，每一份包含的系统帧数；UE_IDmodN相当于取N等份里的第i份，i的取值范围是0到N-1，而PF为其中的第一个系统帧。

实施本申请实施例，基站通过将寻呼载波进行分组，并对不同组的载波进行具体的寻呼配置，可以实现一个小区内不同的寻呼周期的支持，同时满足短时延和深覆盖的UE的寻呼需求。

请参见图5，图5是本申请实施例提供的一种下行数据传输方法的流程示意图，该方法包括但不限于以下步骤：

S501：在随机接入过程中，从终端接收消息3，所述消息3包括第一信息，所述第一信息用于指示被叫数据早传。

具体地，在基站接收UE发送的第一RRC消息之前，应用服务器产生UE需要获取的下行数据，并将该下行数据发送给PDN网关(PDN GateWay，PGW)，PGW再将该下行数据发送给SGW，SGW在接收到PGW发送的下行数据后，SGW给MME发送数据到达通知。

UE接收基站发送的第二寻呼消息之后，向基站发送随机接入前导(preamble)，并接收基站发送的随机接入响应信息，然后再向基站发送消息3(第一RRC消息)。

在一种可能的实现方式中，所述第一信息为所述终端的标识，所述终端的标识与被叫数据早传具有关联关系；或者所述第一信息为所述消息3的原因值；或者所述第一信息为所述终端的能力信息或者类别信息；或者，所述第一信息为用于请求进行被叫数据早传的信息。

具体地，UE在向基站发送的RRC连接请求消息、RRC早传数据请求消息或RRC连接恢复请求消息中可以包括MT EDT指示信息和UE标识。

在一种可能的实现方式中，所述获取终端的被叫早传数据指示信息包括：接收所述核心网设备发送的第一寻呼消息，所述第一寻呼消息包括被叫早传数据指示信息和寻呼的终端标识，对所述第一寻呼消息中的终端标识和所述第一RRC消息中的终端标识进行比较，如果标识一致，则获取所述第一寻呼消息中的被叫早传数据指示信息；或者所述第一RRC消息包括被叫早传数据指示信息，获取所述第一RRC消息中的被叫早传数据指示信息。

具体地，MME在接收到SGW发送的数据到达通知后向基站发送第一寻呼消息，该第一寻呼消息包括UE的寻呼能力信息和UE标识。该寻呼能力信息是基站在之前与UE数据通信时，向MME发送UE能力信息指示消息时发送给MME的，MME保存该寻呼能力信息，并在下一次进行寻呼时，在向基站发送的第一寻呼消息中携带该寻呼能力信息。

进一步的，在MME向基站发送的寻呼能力信息中可以携带UE的被叫早传数据(Mobile Terminated Early Data Transmission，MT EDT)指示信息，该MT EDT指示信息表示UE具有支持MT EDT的能力。基站在接收到第一寻呼消息之后，还需要保存该寻呼消息中的UE标识。该UE标识一般可以是该UE的S-TMSI，若该UE的S-TMSI不可用，该UE标识也可以是IMSI，或者是GUTI，或者是IMEI，本申请不做限定。

基站在接收到该第一寻呼消息后，对该第一寻呼消息中的终端标识和从UE接收到的第一RRC消息中的终端标识进行比较，如果标识一致，则获取该第一寻呼消息中的被叫早传数据指示信息，当然也可以通过从UE发送的第一RRC消息中获取被叫早传数据指示信息。

在一种可能的实现方式中，所述第一RRC消息包括被叫早传数据指示信息包括：所述第一RRC消息包括被叫早传数据指示比特；或者所述第一RRC消息包括接入原因值，所述接入原因值为被叫接入。

在一种可能的实现方式中，若所述第一RRC消息为RRC连接请求消息或RRC连接恢复请求消息，所述被叫早传数据指示信息为被叫早传数据指示比特；若所述第一RRC消息为RRC早传数据请求消息，所述被叫早传数据指示信息为被叫早传数据指示比特或者接入原因值，所述接入原因值为被叫接入。

具体地，UE在向基站发送的RRC连接请求消息、RRC早传数据请求消息或RRC连接恢复请求消息中可以包括MT EDT指示信息和UE标识。

进一步地，该MT EDT指示信息可以是RRC连接请求消息或RRC连接恢复请求消息中携带的1比特的UE需要发起MT EDT的相关信息，该相关信息可以是MT EDT的能力指示，也可以是MT EDT的业务请求。该MT EDT指示信息也可以是RRC早传数据请求消息中的接入原因值，该接入原因值为被叫接入，比如，将RRC早传数据请求消息中的接入原因值设置为mt-Access，需要说明的是，RRC早传数据请求消息中也可以携带1比特的UE需要发起MT EDT的相关信息，在UE发送的RRC早传数据请求消息中还可以包括UE发起的服务请求的NAS PDU。

需要说明的是，若基站从MME发送的第一寻呼消息中已经获取到MT EDT指示信息，则UE可以在发送的RRC连接请求消息或RRC连接恢复请求消息中不携带该1比特的MT EDT相关能力信息。

S502：从第一核心网设备获取所述终端的下行数据。

在一种可能的实现方式中，所述从第一核心网设备获取所述终端的下行数据包括：向所述第一核心网设备发送第二信息，所述第二信息用于指示所述终端的所述被叫数据早传；从所述第一核心网设备接收所述终端的下行数据。

具体地，基站在收到UE发送的RRC连接请求消息、RRC早传数据请求消息或RRC连接恢复请求消息后，对该RRC连接请求消息、RRC早传数据请求消息或RRC连接恢复请求消息中的UE标识和从MME接收到的第一寻呼消息中的UE标识进行比较，如果UE标识一致，则表示UE已经响应了从MME发送的寻呼消息，基站向MME发送初始UE消息。可以理解，基站时刻都需要下发大量的寻呼消息，也会接收大量的RRC连接请求消息、RRC早传数据请求消息或RRC连接恢复请求消息，UE并不能及时准确的区分出哪个RRC连接请求消息、RRC早传数据请求消息或RRC连接恢复请求消息响应了该从MME发送的寻呼消息，所以基站需要通过比较接收到的RRC连接请求消息、RRC早传数据请求消息或RRC连接恢复请求消息中的UE标识和从MME接收到的第一寻呼消息中的UE标识是否一致，来判断出UE是否已经响应了从MME发送的寻呼消息。

进一步地，基站向MME发送的初始UE消息中携带该UE的MT EDT相关信息。该MT EDT相关信息可以是1比特的MT EDT指示消息，或者是原因值为mt-Access，该原因值是上述RRC早传数据请求消息中的原因值，或者是该初始UE消息包括的可选的服务NAS PDU。

在基站接收MME发送的下行早传数据之前，MME向SGW发送寻呼应答消息。

具体地，该寻呼应答消息可以是在MME接收到基站发送的初始UE消息后向SGW发送的，也可以是在MME接收到基站发送的初始UE消息之前向SGW发送的。

具体地，如果下行早传数据是控制面数据，可选的，MME可以向SGW发送承载修改消息，SGW利用修改后的承载资源下发该下行早传数据，MME收到下行早传数据后向基站发送下行消息，该下行消息中包括该下行早传数据。

具体地，MME在接收到SGW发送的下行早传数据后，判断需要下发的下行数据包的数量，若该下行数据包只有一个，则MME会向基站发送下行消息，并在该下行消息中携带该下行数据包中的下行早传数据，特别的，MME可以将该下行早传数据放到NAS PDU中发送给基站；在下行数据包不止一个的情况下，MME会向基站发送另一个下行消息，并通过该下行消息指示基站向UE发送RRC连接建立或RRC连接恢复请求消息，以使UE在建立了RRC连接之后再获取下行数据。

在一种可能的实现方式中，所述从第一核心网设备获取所述终端的下行数据包括：向第二核心网设备发送第二信息，所述第二信息用于指示所述终端的所述被叫数据早传；与所述第一核心网设备建立所述终端的数据承载；通过所述数据承载从所述第一核心网设备接收所述终端的下行数据。

具体地，如果下行早传数据是用户面数据，可选的，MME可以向SGW发送承载修改消息，SGW利用修改后的承载资源向基站下发该下行早传数据，MME向基站发送上下文恢复消息。

具体地，基站在接收到MME发送的上下文恢复消息之后，基站会设置一个非激活定时器，判断是否有下行早传数据到达，若基站在非激活定时器超期后没有接收到SGW发送的下行早传数据，则基站会发起连接释放消息，释放基站与UE之间的空口连接；若非激活定时器超期前基站接收到SGW发送的下行早传数据，则基站会将接收到的下行早传数据发送给UE，然后发起连接释放消息，释放基站与UE之间的空口连接。

在一种可能的实现方式中，网络侧设备从所述第二核心网设备接收第一消息，所述第一消息用于指示恢复所述终端的上下文。

S503：向所述终端发送消息4，所述消息4包括所述下行数据。

实施本申请实施例，在UE支持MT EDT能力时，基站可以通过从UE侧或MME侧获取到MT EDT指示信息，从而获取到UE支持MT EDT的能力，然后基站提前通过MME获取到从SGW发送的下行早传数据，或者基站直接提前从SGW获取到下行早传数据，并将该下行早传数据发送给UE，让UE不必再建立RRC连接，不用再向基站发送RRC连接建立完成消息或RRC连接恢复完成消息，节省了信令开销，减小了下行数据到达UE的时延。

请参见图6，图6是本申请实施例提供的另一种寻呼消息传输方法的流程示意图，该方法包括但不限于以下步骤：

S601：SGW向MME发送数据到达通知。

具体地，应用服务器产生UE需要获取的下行数据，并将该下行数据发送给PDN网关(PDN GateWay，PGW)，PGW再将该下行数据发送给SGW，SGW在接收到PGW发送的下行数据后，SGW给MME发送数据到达通知。

需要说明的是，SGW和PGW可以分别设置，也可以合在一起进行设置，此外，SGW与基站以及PGW之间的接口消息均要符合GPRS隧道协议(GPRS Turning Protocol，GTP)协议。

S602：MME向基站发送第一寻呼消息。

具体地，MME在接收到SGW发送的数据到达通知后向基站发送第一寻呼消息，该第一寻呼消息包括UE的寻呼能力信息和UE标识。该寻呼能力信息是基站在之前与UE数据通信时，向MME发送UE能力信息指示消息时发送给MME的，MME保存该寻呼能力信息，并在下一次进行寻呼时，在向基站发送的第一寻呼消息中携带该寻呼能力信息。需要说明的是，这里的第一寻呼消息仅仅是为了区分基站向UE发送的寻呼消息，并不对该寻呼消息做出其他限制。

进一步地，在MME向基站发送的寻呼能力信息中可以携带UE的MT EDT指示信息，该MT EDT指示信息表示UE具有支持MT EDT的能力。基站在接收到该第一寻呼消息后，可以通过该第一寻呼消息中的寻呼能力信息获取到该MT EDT指示信息。

基站在接收到第一寻呼消息之后，还需要保存该寻呼消息中的UE标识。该UE标识一般可以是该UE的S-TMSI(S-Temporary Mobile Subscriber Identity)，若该UE的S-TMSI不可用，该UE标识也可以是IMSI，或者是GUTI，或者是IMEI，本申请不做限定。

S603：基站向UE发送第二寻呼消息。

具体地，基站在向UE发送的第二寻呼消息中，包括寻呼的UE标识，该UE标识是基站从第一寻呼消息中获取到的，可以是S-TMSI，或者是IMSI，或者是GUTI，或者是IMEI。需要说明的是，这里的第二寻呼消息仅仅是为了区分MME向基站发送的寻呼消息，并不对该寻呼消息做出其他限制。

进一步地，基站可以在接收到第一寻呼消息之后，根据该第一寻呼消息中的寻呼能力信息，该寻呼能力信息可以包括是否支持时延敏感寻呼的能力，确定UE对应的寻呼载波组别，在基站确定了寻呼载波组别后，通过具体的公式从确定了的寻呼载波组中计算得到一个寻呼载波，并通过该寻呼载波向UE发送第二寻呼消息。当然，基站之前需要对用于寻呼的载波进行分组，且不同组的载波对应不同的寻呼配置，例如对SIB22的PCCH配置进行修改，增加时延敏感UE或非深覆盖UE对应的DRX cycle和nB的配置，使其能够满足短时延的需求。

基站通过DRX cycle和UE标识等信息计算UE的PF和PO，并在对应的PO上向UE发送第二寻呼消息。

S604：UE向基站发送preamble。

具体地，UE先接收基站发送的广播消息，该广播消息里包括基站对寻呼载波的配置信息，UE在读取广播消息后，会根据其中的配置信息和自己的DRX cycle，并通过与基站相同的计算公式计算得到接收寻呼消息的载波，再根据DRX cycle和UE标识等信息计算PF和PO。UE计算得到的PF和PO与基站计算得到的是相同的。UE在对应的PO上接收到基站发送的第二寻呼消息后，UE判断该寻呼消息中的UE标识是否为自身的UE标识，若该寻呼消息中的UE标识与自身的UE标识一致，则UE确定自己被寻呼时，UE选择非增强(legacy)的物理随机接入信道资源PRACH发起随机接入，向基站发送preamble。需要说明的是，legacy的PRACH不同于系统为EDT数据传输专门预留的PRACH，也与其它专用PRACH不同。

S605：基站向UE发送随机接入响应信息。

S606：UE向基站发送RRC连接请求消息、RRC早传数据请求消息或RRC连接恢复请求消息。

具体地，UE在向基站发送的RRC连接请求消息、RRC早传数据请求消息或RRC连接恢复请求消息中可以包括MT EDT指示信息和UE标识。

进一步地，该MT EDT指示信息可以是RRC连接请求消息或RRC连接恢复请求消息中携带的1比特的UE需要发起MT EDT的相关信息，该相关信息可以是MT EDT的能力指示，也可以是MT EDT的业务请求。该MT EDT指示信息也可以是RRC早传数据请求消息中的接入原因值，该接入原因值为被叫接入，比如，将RRC早传数据请求消息中的接入原因值设置为mt-Access，需要说明的是，RRC早传数据请求消息中也可以携带1比特的UE需要发起MT EDT的相关信息，在UE发送的RRC早传数据请求消息中还可以包括UE发起的服务请求的NAS PDU。

需要说明的是，若基站从MME发送的第一寻呼消息中已经获取到MT EDT指示信息，则UE可以在发送的RRC连接请求消息或RRC连接恢复请求消息中不携带该1比特的MT EDT相关能力信息。

S607：基站向MME发送初始UE消息。

具体地，基站在收到UE发送的RRC连接请求消息、RRC早传数据请求消息或RRC连接恢复请求消息后，对该RRC连接请求消息、RRC早传数据请求消息或RRC连接恢复请求消息中的UE标识和从MME接收到的第一寻呼消息中的UE标识进行比较，如果UE标识一致，则表示UE已经响应了从MME发送的寻呼消息，基站向MME发送初始UE消息。可以理解，基站时刻都需要下发大量的寻呼消息，也会接收大量的RRC连接请求消息、RRC早传数据请求消息或RRC连接恢复请求消息，UE并不能及时准确的区分出哪个RRC连接请求消息、RRC早传数据请求消息或RRC连接恢复请求消息响应了该从MME发送的寻呼消息，所以基站需要通过比较接收到的RRC连接请求消息、RRC早传数据请求消息或RRC连接恢复请求消息中的UE标识和从MME接收到的第一寻呼消息中的UE标识是否一致，来判断出UE是否已经响应了从MME发送的寻呼消息。

进一步地，基站向MME发送的初始UE消息中携带该UE的MT EDT相关信息。该MT EDT相关信息可以是1比特的MT EDT指示消息，或者是原因值为mt-Access，该原因值是上述RRC早传数据请求消息中的原因值，或者是该初始UE消息包括的可选的服务NAS PDU。

S608：MME向SGW发送寻呼应答消息。

具体地，该寻呼应答消息可以是在MME接收到基站发送的初始UE消息后向SGW发送的，也可以是在MME接收到基站发送的初始UE消息之前向SGW发送的。

可选的，若UE需要获取的下行早传数据为控制面数据，则需要执行：

S609：MME向SGW发送承载修改消息。

具体地，SGW在接收到MME发送的承载修改消息后，根据该承载修改消息对承载资源进行修改，并利用修改后的承载资源下发该下行早传数据。需要说明的是，步骤S609是可选的，当然，S609也可以不执行。

S610：SGW向MME发送下行早传数据。

具体地，SGW在接收到MME发送的初始UE消息或承载修改消息之后，SGW向MME发送下行早传数据。

S611：MME向基站发送下行消息。

具体地，MME在接收到SGW发送的下行早传数据后，判断需要下发的下行数据包的数量，若该下行数据包只有一个，则MME会向基站发送下行消息，并在该下行消息中携带该下行数据包中的下行早传数据，特别的，MME可以将该下行早传数据放到NAS PDU中发送给基站；在下行数据包不止一个的情况下，MME会向基站发送另一个下行消息，并通过该下行消息指示基站向UE发送RRC连接建立或RRC连接恢复请求消息，以使UE在建立了RRC连接之后再获取下行数据。

S612：基站向UE发送下行早传数据。

具体地，基站在接收到MME发送的下行消息之后，向UE发送RRC连接建立或RRC连接恢复请求消息。若基站从MME中已经获取到下行早传数据，则基站会在该RRC连接建立或RRC连接恢复请求消息中携带基站获取到的下行早传数据，UE通过接收该RRC连接建立或RRC连接恢复请求消息，从而获取到其中携带的下行早传数据，UE在获取到该下行早传数据之后，不必再建立RRC连接，不用再向基站发送RRC连接建立完成消息或RRC连接恢复完成消息，节省了信令开销。若基站从MME中没有获取到下行早传数据，则基站仍和以前普通RRC连接建立流程一样，向UE发送RRC连接建立或RRC连接恢复请求消息，该RRC连接建立或RRC连接恢复请求消息与之前的消息一样，UE无法从该RRC连接建立或RRC连接恢复请求消息中获取到下行早传数据，所以UE会向基站发送RRC连接建立完成消息或RRC连接恢复完成消息，与基站建立RRC连接，并通过该RRC连接再向基站请求获取下行数据。

可选的，若UE需要获取的下行早传数据为用户面数据，则需要执行：

S613：MME向SGW发送承载修改消息。

具体地，SGW在接收到MME发送的承载修改消息后，根据该承载修改消息对承载资源进行修改，并利用修改后的承载资源下发该下行早传数据。需要说明的是，步骤S613是可选的，当然，S613也可以不执行。

S614：SGW向基站发送下行早传数据。

具体地，SGW在接收到MME发送的初始UE消息或承载修改消息之后，SGW向基站发送下行早传数据。

S615：MME向基站发送上下文恢复消息。

具体地，基站在接收到MME发送的上下文恢复消息之后，基站会设置一个非激活定时器，判断是否有下行早传数据到达，若基站在非激活定时器超期后没有接收到SGW发送的下行早传数据，则基站会发起连接释放消息，释放基站与UE之间的空口连接；若非激活定时器超期前基站接收到SGW发送的下行早传数据，则基站会将接收到的下行早传数据发送给UE，然后发起连接释放消息，释放基站与UE之间的空口连接。

需要说明的是，S615和S608在执行上并不存在时间逻辑上的先后关系，即MME向SGW发送寻呼应答消息和MME向基站发送上下文恢复消息并没有严格意义上的先后关系，S615和S608是可以同时执行的。

S616：基站向UE发送下行早传数据。

具体地，基站在接收到MME发送的上下文恢复消息之后，向UE发送RRC连接建立或RRC连接恢复请求消息。若基站接收到SGW发送的下行早传数据，则基站会在该RRC连接建立或RRC连接恢复请求消息中携带基站接收到的下行早传数据，UE通过接收该RRC连接建立或RRC连接恢复请求消息，从而获取到其中携带的下行早传数据，UE在获取到该下行早传数据之后，根据基站发起的连接释放消息，释放与基站的空口连接，进入空闲态。若基站没有接收到SGW发送的下行早传数据，则UE直接根据基站发起的连接释放消息，释放与基站的空口连接，进入空闲态。

实施本申请实施例，在UE支持MT EDT能力时，基站可以通过从UE侧或MME侧获取到MT EDT指示信息，从而获取到UE支持MT EDT的能力，然后基站提前通过MME获取到从SGW发送的下行早传数据，或者基站直接提前从SGW获取到下行早传数据，并将该下行早传数据发送给UE，让UE不必再建立RRC连接，不用再向基站发送RRC连接建立完成消息或RRC连接恢复完成消息，节省了信令开销，减小了下行数据到达UE的时延。

请参见图7，图7是本申请实施例提供的另一种寻呼消息传输方法的流程示意图，该方法包括但不限于以下步骤：

S701：从核心网设备接收第一寻呼消息，所述第一寻呼消息包括寻呼对象的第一标识和所述寻呼对象的下行数据。

在基站接收MME发送的第一寻呼消息之前，应用服务器向业务能力开发功能(Service Capability Exposure Function，SCEF)网元发送下行消息。

具体地，应用服务器产生UE需要获取的下行数据，该应用服务器将该下行数据携带在发送给SCEF网元中的下行消息中，同时，该下行消息还携带有与该下行数据对应的用于寻呼的标识。

在一种可能的实现方式中，所述寻呼标识信息包括组寻呼标识和/或终端寻呼标识。

具体地，应用服务器发送给SCEF网元的下行消息可以是下行组消息，即该下行数据不是用于某一个UE的，而是用于一组(多个)UE的。则下行组消息中携带的寻呼标识是该下行数据对应的组标识(Group id)或者基于该Group id衍生的其它组标识，衍生的组标识主要是长度发生变化，可以进行调整。

当然，该下行消息中的下行数据也可以是只用于某个单独的UE，则下行消息中携带的寻呼标识是该UE对应的UE标识，该UE标识一般可以是该UE的S-TMSI，若该UE的S-TMSI不可用，该UE标识也可以是IMSI，或者是GUTI，或者是IMEI，本申请不做限定。

SCEF网元将接收到的下行消息发送给MME，该下行消息可以是下行组消息，其中携带Group id和下行数据，也可以是针对某个具体的UE的下行消息，其中携带该UE的UE标识和下行数据。

若MME接收到是SCEF网元发送的下行组消息，在MME在向基站发送的第一寻呼消息中的寻呼能力信息中携带UE的组寻呼能力信息。该组寻呼能力信息是基站在之前与UE数据通信时，向MME发送UE能力信息指示消息时发送给MME的，MME保存该组寻呼能力信息，并用于MME进行下一次寻呼。该第一寻呼消息中还包括Group id和下行数据。

若MME接收到是SCEF网元发送的针对某个具体的UE的下行消息，在MME在向基站发送的第一寻呼消息中的寻呼能力信息中携带该UE对应的寻呼能力信息。该UE对应的寻呼能力信息是基站在之前与UE数据通信时，向MME发送UE能力信息指示消息时发送给MME的，MME保存该UE对应的寻呼能力信息，并用于MME进行下一次寻呼。该第一寻呼消息中还包括该UE的UE标识和下行数据。

S702：向所述寻呼对象发送第二寻呼消息，所述第二寻呼消息包括所述寻呼对象的第二标识和所述下行数据的调度信息。

可选的，基站可以在接收到第一寻呼消息之后，根据该第一寻呼消息中的寻呼能力信息，该寻呼能力信息可以包括是否支持时延敏感寻呼的能力，确定UE对应的寻呼载波组别，在基站确定了寻呼载波组别后，通过具体的公式从确定了的寻呼载波组中计算得到一个寻呼载波，并通过该寻呼载波向UE发送第二寻呼消息。当然，基站之前需要对用于寻呼的载波进行分组，且不同组的载波对应不同的寻呼配置，例如对SIB22的PCCH配置进行修改，增加时延敏感业务对应的DRX cycle和nB的配置，使其能够满足短时延的需求。

基站通过DRX cycle和UE标识等信息计算UE的PSF和PO，在PSF和PO指示的寻呼时刻向UE发送第二寻呼消息。需要说明的是，这里的第一寻呼消息仅仅是为了区分MME向基站发送的寻呼消息，并不对该寻呼消息做出其他限制。

在一种可能的实现方式中，在向终端发送第二寻呼消息之前，所述方法还包括：根据所述组寻呼标识映射出一个组无线寻呼标识，将所述组寻呼标识和/或所述组寻呼标识与所述组无线寻呼标识的映射关系通过广播消息或专用信令发送给所述终端。

具体地，若基站接收到的MME发送的第一寻呼消息中的寻呼能力信息中是携带UE的组寻呼能力信息和Group id，基站在向UE发送的第二寻呼消息中新增该Group id或基于该Group id衍生的组标识，以及该Group id或基于该Group id衍生的组标识对应的下行组数据的调度信息。比如，在第二寻呼消息的寻呼记录表中增加该Group id或基于该Groupid衍生的组标识，以及对应的下行组数据调度信息。需要说明的是，在寻呼记录表中，可以增加多个Group id或基于该Group id衍生的组标识，以及各个Group id或基于该Group id衍生的组标识对应的下行组数据调度信息。

基站将该Group id映射为组无线标识(Group-RNTI)，并将映射关系通过广播消息或专用信令发送给UE。UE在接收到第二寻呼消息之后，检查该寻呼消息中的Group id是否为该UE支持的Group id，若该UE支持寻呼消息中的Group id，则UE读取该Group id对应的下行组数据调度信息，并从该下行组数据调度信息中获取在PDSCH信道上发送的下行组数据。

在一种可能的实现方式中，所述向终端发送第二寻呼消息包括：使用P-RNTI对调度所述第二寻呼消息的PDCCH进行加扰，以使所述终端接收在所述PDCCH中携带的所述第二寻呼消息的调度信息，并根据所述调度信息接收物理下行共享信道PDSCH上发送的所述第二寻呼消息。

具体地，基站在向UE发送第二寻呼消息时，在调度寻呼消息的PDCCH中使用P-RNTI加扰，该P-RNTI的值为0xFFFE，是小区内所有UE共用的，UE根据现有的寻呼时机监听方案，接收在PDCCH携带的第二寻呼消息的调度信息，获得第二寻呼消息在PDSCH上具体的时频资源位置，UE根据该调度信息接收PUSCH上发送的第二寻呼消息。

在一种可能的实现方式中，所述向终端发送第二寻呼消息包括：使用Group-RNTI对调度所述第二寻呼消息的PDCCH进行加扰，以使所述终端接收在所述PDCCH中携带的所述第二寻呼消息的调度信息，并根据所述调度信息接收PDSCH上发送的所述第二寻呼消息。

具体地，UE通过第二寻呼消息中的Group-RNTI来区分Group id，UE在接收到基站发送的第二寻呼消息后，根据该映射关系就能正确接收该UE支持的Group id对应的调度该第二寻呼消息的PDCCH，并接收在PDCCH中携带的第二寻呼消息的调度信息，获得第二寻呼消息在PDSCH上具体的时频资源位置，UE根据该调度信息接收PUSCH上发送的第二寻呼消息。基站在向UE发送的第二消息中新增该Group id对应的下行组数据的调度信息，比如在第二寻呼消息的寻呼记录表中增加该Group id对应的下行组数据调度信息，需要说明的是，在寻呼记录表中，只能增加一个Group id对应的下行组数据调度信息，即在一个寻呼消息中只能包括一个下行组数据包。UE在接收到第二寻呼消息后，直接读取该寻呼消息中的下行组数据调度信息，并从该下行组数据调度信息中获取在PDSCH信道上发送的下行组数据。

S703：基于所述调度信息向所述寻呼对象发送所述下行数据。

实施本申请实施例，MME在向基站发送第一寻呼消息之前就已经从SGW获取到下行数据，而且基站在向UE发送的第二寻呼消息中携带了寻呼标识信息和下行数据的调度信息，UE在接收到PDSCH上传输的寻呼消息后，即可基于其中的调度信息获取对应的下行数据，不需要再建立RRC连接，可以有效减少下行数据接收的时延。

请参见图8，图8是本申请实施例提供的一种寻呼消息传输方法的流程示意图，该方法包括但不限于以下步骤：

S801：应用服务器向业务能力开发功能(Service Capability ExposureFunction，SCEF)网元发送下行消息。

具体地，应用服务器产生UE需要获取的下行数据，该应用服务器将该下行数据携带在发送给SCEF网元中的下行消息中，同时，该下行消息还携带有与该下行数据对应的用于寻呼的标识。

需要说明的是，该下行消息可以是下行组消息，即该下行数据不是用于某一个UE的，而是用于一组(多个)UE的。则下行组消息中携带的寻呼标识是该下行数据对应的组标识(Group id)或者基于该Group id衍生的其它组标识，衍生的组标识主要是长度发生变化，可以进行调整。

当然，该下行消息中的下行数据也可以是只用于某个单独的UE，则下行消息中携带的寻呼标识是该UE对应的UE标识，该UE标识一般可以是该UE的S-TMSI，若该UE的S-TMSI不可用，该UE标识也可以是IMSI，或者是GUTI，或者是IMEI，本申请不做限定。

S802：SCEF网元向归属用户服务器(Home Subscriber Server，HSS)发送授权信息。

S803：SCEF网元向MME发送该下行消息。

具体地，SCEF网元将接收到的下行消息发送给MME，该下行消息可以是下行组消息，其中携带Group id和下行数据，也可以是针对某个具体的UE的下行消息，其中携带该UE的UE标识和下行数据。

S804：MME向基站发送第一寻呼消息。

具体地，若MME接收到是SCEF网元发送的下行组消息，在MME在向基站发送的第一寻呼消息中的寻呼能力信息中携带UE的组寻呼能力信息。该组寻呼能力信息是基站在之前与UE数据通信结束后，向MME发送连接释放完成消息时发送给MME的，MME保存该组寻呼能力信息，并用于MME进行下一次寻呼。该第一寻呼消息中还包括Group id和下行数据。

若MME接收到是SCEF网元发送的针对某个具体的UE的下行消息，在MME在向基站发送的第一寻呼消息中的寻呼能力信息中携带该UE对应的寻呼能力信息。该UE对应的寻呼能力信息是基站在之前与UE数据通信时，向MME发送UE能力信息指示消息时发送给MME的，MME保存该UE对应的寻呼能力信息，并用于MME进行下一次寻呼。该第一寻呼消息中还包括该UE的UE标识和下行数据。

需要说明的是，这里的第一寻呼消息仅仅是为了区分基站向UE发送的寻呼消息，并不对该寻呼消息做出其他限制。

S805：基站向UE发送第二寻呼消息。

具体地，基站在向UE发送第二寻呼消息时，在调度寻呼消息的PDCCH中使用P-RNTI加扰，该P-RNTI的值为0xFFFE，是小区内所有UE共用的，UE根据现有的寻呼时机监听方案，接收在PDCCH携带的第二寻呼消息的调度信息，获得第二寻呼消息在PDSCH上具体的时频资源位置，UE根据该调度信息接收PUSCH上发送的第二寻呼消息。

进一步地，基站可以在接收到第一寻呼消息之后，根据该第一寻呼消息中的寻呼能力信息，该寻呼能力信息可以包括是否支持时延敏感寻呼的能力，确定UE对应的寻呼载波组别，在基站确定了寻呼载波组别后，通过具体的公式从确定了的寻呼载波组中计算得到一个寻呼载波，并通过该寻呼载波向UE发送第二寻呼消息。当然，基站之前需要对用于寻呼的载波进行分组，且不同组的载波对应不同的寻呼配置，例如对SIB22的PCCH配置进行修改，增加时延敏感业务对应的DRX cycle和nB的配置，使其能够满足短时延的需求。

基站通过DRX cycle和UE标识等信息计算UE的PSF和PO，在PSF和PO指示的寻呼时刻向UE发送第二寻呼消息。需要说明的是，这里的第一寻呼消息仅仅是为了区分MME向基站发送的寻呼消息，并不对该寻呼消息做出其他限制。

若基站接收到的MME发送的第一寻呼消息中的寻呼能力信息中是携带UE的组寻呼能力信息和Group id，基站在向UE发送的第二寻呼消息中新增该Group id或基于该Groupid衍生的组标识，以及该Group id或基于该Group id衍生的组标识对应的下行组数据的调度信息。比如，在第二寻呼消息的寻呼记录表中增加该Group id或基于该Group id衍生的组标识，以及对应的下行组数据调度信息。需要说明的是，在寻呼记录表中，可以增加多个Group id或基于该Group id衍生的组标识，以及各个Group id或基于该Group id衍生的组标识对应的下行组数据调度信息。

若基站接收到的MME发送的第一寻呼消息中的寻呼能力信息中是携带某个具体UE的寻呼能力信息和UE标识，基站在向UE发送的第二寻呼消息中新增该UE标识对应的下行数据调度信息。比如，在第二寻呼消息的寻呼记录表中，由于寻呼记录表中已经记录了各个UE的UE标识，所以不需要再增加UE标识，而是增加针对于各个UE标识所对应的下行数据调度信息。需要说明的是，在寻呼记录表中，可以增加多个UE标识对应的下行数据调度信息。

UE在接收到第二寻呼消息之后，检查该寻呼消息中的Group id是否为该UE支持的Group id，若该UE支持寻呼消息中的Group id，则UE读取该Group id对应的下行组数据调度信息，并从该下行组数据调度信息中获取在PDSCH信道上发送的下行组数据。可选的，该下行组数据可以使用Group-RNTI进行加扰，基站需要根据从MME接收到的第一寻呼消息中的Group id映射出一个组无线寻呼标识(Group-RNTI)，基站将该Group id和Group-RNTI的映射关系通过广播消息或专用信令发送给UE，UE在接收到基站发送的第二寻呼消息后，根据该映射关系就能正确解读获取到下行组数据。

类似的，若基站发送的第二寻呼消息中的寻呼能力信息是携带某个具体UE的寻呼能力信息和UE标识，UE在接收到第二寻呼消息后，检查该寻呼消息中的UE标识是否与自身的一致，若一致，则UE读取该UE标识对应的下行数据调度信息，并从该下行数据调度信息中获取在PDSCH信道上发送的下行数据。

可选的，若基站接收到的MME发送的第一寻呼消息中的寻呼能力信息中是携带UE的组寻呼能力信息和Group id，则基站根据该Group id映射出一个Group-RNTI，基站将该Group id和Group-RNTI的映射关系通过广播消息或专用信令发送给UE，基站向UE发送第二寻呼消息，其中在调度该寻呼消息的PDCCH中使用Group-RNTI加扰，UE根据现有的寻呼时机监听方案，接收在PDCCH中携带的第二寻呼消息的调度信息，获得第二寻呼消息在PDSCH上具体的时频资源位置，UE根据该调度信息接收PUSCH上发送的第二寻呼消息。

可以看出，在此种方案中，UE是通过第二寻呼消息中的Group-RNTI来区分Groupid，UE在接收到基站发送的第二寻呼消息后，根据该映射关系就能正确接收该UE支持的Group id对应的调度该第二寻呼消息的PDCCH，并接收在PDCCH中携带的第二寻呼消息的调度信息，获得第二寻呼消息在PDSCH上具体的时频资源位置，UE根据该调度信息接收PUSCH上发送的第二寻呼消息。基站在向UE发送的第二消息中新增该Group id对应的下行组数据的调度信息，比如在第二寻呼消息的寻呼记录表中增加该Group id对应的下行组数据调度信息，需要说明的是，在寻呼记录表中，只能增加一个Group id对应的下行组数据调度信息，即在一个寻呼消息中只能包括一个下行组数据包。UE在接收到第二寻呼消息后，直接读取该寻呼消息中的下行组数据调度信息，并从该下行组数据调度信息中获取在PDSCH信道上发送的下行组数据。

S806：UE向基站发送服务请求消息。

具体地，UE在确定自己被寻呼，并且完成了下行数据的接收后，为了向服务器应答该下行数据的接收，UE向基站发起随机接入，向基站发送服务请求消息。

可选的，UE可以选择使用legacy的方式进行随机接入或者数据早传的方式进行随机接入。若UE采用legacy方式进行随机接入，则UE在向基站发送的RRC连接建立完成消息或RRC连接恢复请求消息中携带该服务请求消息；若UE采用数据早传方式进行随机接入，则UE在向基站发送的RRC连接请求或RRC连接恢复请求中携带该服务请求消息。

S807：基站向MME发送服务请求消息。

具体地，基站在接收到UE采用legacy方式发送的RRC连接建立完成消息或RRC连接恢复请求消息，或者是接收到UE采用数据早传方式发送的RRC连接请求或RRC连接恢复请求中携带该服务请求消息后，获取其中携带的服务请求消息，并将该服务请求消息发送给MME。

S808：MME向SCEF网元发送下行消息交付信息。

S809：SCEF网元向应用服务器发送下行消息交付信息。

实施本申请实施例，MME在向基站发送第一寻呼消息之前就已经从SGW获取到下行数据，而且基站在向UE发送的第二寻呼消息中携带了寻呼标识信息和下行数据的调度信息，UE在接收到PDSCH上传输的寻呼消息后，即可基于其中的调度信息获取对应的下行数据，不需要再建立RRC连接，可以有效减少下行数据接收的时延。

上述详细阐述了本申请实施例的方法，为了便于更好地实施本申请实施例的上述方案，相应地，下面还提供用于配合实施上述方案的相关装置。

参见图9，图9为本申请实施例提供的一种网络侧设备的结构示意图，该网络侧设备100至少包括：接收单元110、处理单元120和发送单元130；其中：

接收单元110，用于接收核心网设备发送的第一寻呼消息，所述第一寻呼消息包括终端对应的第一指示，所述第一指示用于指示所述终端支持时延敏感寻呼；

处理单元120，用于确定与所述第一指示对应的第一寻呼载波组，所述第一寻呼载波组包括网络侧设备的多个寻呼载波中的部分寻呼载波；

发送单元130，用于在所述第一寻呼载波组的寻呼载波上向所述终端发送第二寻呼消息。

在一个可能的实施例中，所述接收单元110，还用于接收终端发送的寻呼能力信息，所述寻呼能力信息包括第二指示，所述第二指示用于指示所述终端支持时延敏感寻呼；所述发送单元130，还用于向所述核心网设备发送寻呼能力相关信息，所述寻呼能力相关信息包括第三指示，所述第三指示用于指示所述终端支持时延敏感寻呼。

在一个可能的实施例中，所述发送单元130，还用于向所述终端发送寻呼配置，所述寻呼配置用于指示所述第一寻呼载波组和所述第一寻呼载波组的第一寻呼配置参数，所述第一寻呼配置参数包括第一默认寻呼周期DRX cycle。

在一个可能的实施例中，所述寻呼配置还用于指示第二寻呼载波组和所述第二寻呼载波组的第二寻呼配置参数，所述第二寻呼载波组包括所述网络侧设备的所述多个载波中的另一部分寻呼载波，所述第二寻呼配置参数包括第二DRX cycle。

可理解的是，本实施例的网络侧设备100的各功能模块的功能可根据上述方法实施例中的方法具体实现，此处不再赘述。

实施本申请实施例，网络侧设备通过将寻呼载波进行分组，并对不同组的载波进行具体的寻呼配置，可以实现一个小区内不同的寻呼周期的支持，同时满足短时延和深覆盖的UE的寻呼需求。

参见图10，图10为本申请实施例提供的另一种网络侧设备的结构示意图，该网络侧设备200至少包括：接收单元210、获取单元220和发送单元230；其中：

接收单元210，用于在随机接入过程中，接收终端发送的消息3，所述消息3中包括第一信息，所述第一信息用于指示被叫数据早传；

获取单元220，用于获取第一核心网设备发送的下行数据；

发送单元230，用于向所述终端发送消息4，所述消息4包括所述下行数据。

在一个可能的实施例中，所述第一信息为所述终端的标识，所述终端的标识与被叫数据早传具有关联关系；或者所述第一信息为所述消息3的原因值；或者所述第一信息为所述终端的能力信息或者类别信息；或者，所述第一信息为用于请求进行被叫数据早传的信息。

在一个可能的实施例中，所述发送单元230，还用于向所述第一核心网设备发送第二信息，所述第二信息用于指示所述终端的所述被叫数据早传；所述接收单元210还用于从所述第一核心网设备接收所述终端的下行数据。

在一个可能的实施例中，所述发送单元230，还用于向第二核心网设备发送第二信息，所述第二信息用于指示所述终端的所述被叫数据早传；所述获取单元220，还用于与所述第一核心网设备建立所述终端的数据承载；所述接收单元210还用于通过所述数据承载从所述第一核心网设备接收所述终端的下行数据。

在一个可能的实施例中，所述接收单元210，还用于从所述第二核心网设备接收第一消息，所述第一消息用于指示恢复所述终端的上下文。

可理解的是，本实施例的网络侧设备的各功能模块的功能可根据上述方法实施例中的方法具体实现，此处不再赘述。

实施本申请实施例，在UE支持MT EDT能力时，基站可以通过从UE侧或MME侧获取到MT EDT指示信息，从而获取到UE支持MT EDT的能力，然后基站提前通过MME获取到从SGW发送的下行早传数据，或者基站直接提前从SGW获取到下行早传数据，并将该下行早传数据发送给UE，让UE不必再建立RRC连接，不用再向基站发送RRC连接建立完成消息或RRC连接恢复完成消息，节省了信令开销，减小了下行数据到达UE的时延。

参见图11，图11为本申请实施例提供的另一种网络侧设备的结构示意图，该网络侧设备300至少包括：接收单元310和发送单元320；其中：

接收单元310，用于接收核心网设备发送的第一寻呼消息，所述第一寻呼消息包括寻呼对象的第一标识和所述寻呼对象的下行数据；

发送单元320，用于向所述寻呼对象发送第二寻呼消息，所述第二寻呼消息包括所述寻呼对象的第二标识和所述下行数据的调度信息；

其中，所述发送单元320，还用于基于所述调度信息向所述寻呼对象发送所述下行数据。

在一个可能的实施例中，所述网络侧设备还包括处理单元330，所述处理单元330，用于使用所述寻呼对象的无线网络临时标识RNTI对所述下行数据进行加扰；所述发送单元320，还用于基于所述调度信息向所述寻呼对象发送加扰后的所述下行数据。

在一个可能的实施例中，所述发送单元320，还用于向所述寻呼对象发送调度所述第二寻呼消息的控制信息。

在一个可能的实施例中，所述处理单元330，还用于使用所述寻呼对象的无线网络临时标识RNTI对所述控制信息进行加扰；所述发送单元320，还用于向所述寻呼对象发送加扰后的所述控制信息。

在一个可能的实施例中，所述处理单元330，还用于获取所述寻呼对象的所述RNTI；所述发送单元320，还用于向所述寻呼对象发送所述第二标识和所述RNTI的对应关系。

在一个可能的实施例中，所述寻呼对象为终端或者终端组。

可理解的是，本实施例的网络侧设备的各功能模块的功能可根据上述方法实施例中的方法具体实现，此处不再赘述。

实施本申请实施例，MME在向基站发送第一寻呼消息之前就已经从SGW获取到下行数据，而且基站在向UE发送的第二寻呼消息中携带了寻呼标识信息和下行数据的调度信息，UE在接收到PDSCH上传输的寻呼消息后，即可基于其中的调度信息获取对应的下行数据，不需要再建立RRC连接，可以有效减少下行数据接收的时延。

请参见图12，图12是本申请实施例提供的一种网络侧设备400。该网络侧设备400至少包括：处理器410、存储器420和收发器430，该处理器410、存储器420和收发器430通过总线440相互连接。

存储器420包括但不限于是随机存取存储器(Random Access Memory，RAM)、只读存储器(Read-Only Memory，ROM)或可擦除可编程只读存储器(Erasable ProgrammableRead-Only Mmory，EPROM或者快闪存储器)，该存储器420用于存储相关指令及数据。

该收发器430可以包括一个接收器和一个发送器，例如，无线射频模块，以下描述的处理器410接收或者发送某个消息，具体可以理解为该处理器410通过该收发器430来接收或者发送。

处理器410可以是一个或多个中央处理器(Central Processing Unit，CPU)，在处理器410是一个CPU的情况下，该CPU可以是单核CPU，也可以是多核CPU。

该网络侧设备400中的处理器410用于读取该存储器420中存储的程序代码，执行以下操作：

处理器410通过收发器430接收核心网设备发送的第一寻呼消息，所述第一寻呼消息包括终端对应的第一指示，所述第一指示用于指示所述终端支持时延敏感寻呼。

处理器410确定与所述第一指示对应的第一寻呼载波组，所述第一寻呼载波组包括网络侧设备的多个寻呼载波中的部分寻呼载波。

处理器410选择所述第一寻呼载波组中的一个寻呼载波，通过收发器430发送第二寻呼消息。

需要说明的是，各个操作的具体实现还可根据上述方法实施例中的方法具体实现，此处不再赘述。

实施本申请实施例，基站通过将寻呼载波进行分组，并对不同组的载波进行具体的寻呼配置，可以实现一个小区内不同的寻呼周期的支持，同时满足短时延和深覆盖的UE的寻呼需求。

请参见图13，图13是本申请实施例提供的另一种网络侧设备500。该网络侧设备500至少包括：处理器510、存储器520和收发器530，该处理器510、存储器520和收发器530通过总线540相互连接。

存储器520包括但不限于是随机存取存储器(Random Access Memory，RAM)、只读存储器(Read-Only Memory，ROM)或可擦除可编程只读存储器(Erasable ProgrammableRead-Only Mmory，EPROM或者快闪存储器)，该存储器520用于存储相关指令及数据。

该收发器530可以包括一个接收器和一个发送器，例如，无线射频模块，以下描述的处理器510接收或者发送某个消息，具体可以理解为该处理器510通过该收发器530来接收或者发送。

处理器510可以是一个或多个中央处理器(Central Processing Unit，CPU)，在处理器510是一个CPU的情况下，该CPU可以是单核CPU，也可以是多核CPU。

该网络侧设备500中的处理器510用于读取该存储器520中存储的程序代码，执行以下操作：

在随机接入过程中，处理器510通过收发器530接收终端发送的消息3，所述消息3包括第一信息，所述第一信息用于指示被叫数据早传。

处理器510通过收发器530接收第一核心网设备发送的所述终端的下行数据。

处理器510通过收发器530接收所述核心网设备发送的下行早传数据。

处理器510通过收发器530发送所述下行数据给终端。

需要说明的是，各个操作的具体实现还可根据上述方法实施例中的方法具体实现，此处不再赘述。

实施本申请实施例，在UE支持MT EDT能力时，基站可以通过从UE侧或MME侧获取到MT EDT指示信息，从而获取到UE支持MT EDT的能力，然后基站提前通过MME获取到从SGW发送的下行早传数据，或者基站直接提前从SGW获取到下行早传数据，并将该下行早传数据发送给UE，让UE不必再建立RRC连接，不用再向基站发送RRC连接建立完成消息或RRC连接恢复完成消息，节省了信令开销，减小了下行数据到达UE的时延。

请参见图14，图14是本申请实施例提供的另一种网络侧设备600。该网络侧设备600至少包括：处理器610、存储器620和收发器630，该处理器610、存储器620和收发器630通过总线640相互连接。

存储器620包括但不限于是随机存取存储器(Random Access Memory，RAM)、只读存储器(Read-Only Memory，ROM)或可擦除可编程只读存储器(Erasable ProgrammableRead-Only Mmory，EPROM或者快闪存储器)，该存储器620用于存储相关指令及数据。

该收发器630可以包括一个接收器和一个发送器，例如，无线射频模块，以下描述的处理器610接收或者发送某个消息，具体可以理解为该处理器610通过该收发器630来接收或者发送。

处理器610可以是一个或多个中央处理器(Central Processing Unit，CPU)，在处理器610是一个CPU的情况下，该CPU可以是单核CPU，也可以是多核CPU。

该网络侧设备600中的处理器610用于读取该存储器620中存储的程序代码，执行以下操作：

处理器610通过收发器630接收核心网设备发送的第一寻呼消息，所述第一寻呼消息包括寻呼对象的第一标识和所述寻呼对象的下行数据。

处理器610通过收发器630发送第二寻呼消息，所述第二寻呼消息包括所述寻呼对象的第二标识和所述下行数据的调度信息。

处理器610通过收发器630向所述寻呼对象发送所述下行数据。

需要说明的是，各个操作的具体实现还可根据上述方法实施例中的方法具体实现，此处不再赘述。

实施本申请实施例，MME在向基站发送第一寻呼消息之前就已经从SGW获取到下行数据，而且基站在向UE发送的第二寻呼消息中携带了寻呼标识信息和下行数据的调度信息，UE在接收到PDSCH上传输的寻呼消息后，即可基于其中的调度信息获取对应的下行数据，不需要再建立RRC连接，可以有效减少下行数据接收的时延。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机或处理器上运行时，使得计算机或处理器执行上述任一个数据传输方法中的一个或多个步骤。上述装置的各组成模块如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在所述计算机可读取存储介质中。

上述计算机可读存储介质可以是前述任一实施例所述的网络侧设备、终端设备或核心网设备的内部存储单元，例如网络侧设备、终端设备或核心网设备的硬盘或内存。上述计算机可读存储介质也可以是上述网络侧设备、终端设备或核心网设备的外部存储设备，例如上述网络侧设备、终端设备或核心网设备上配备的插接式硬盘，智能存储卡(SmartMedia Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，上述计算机可读存储介质还可以既包括上述网络侧设备、终端设备或核心网设备的内部存储单元也包括外部存储设备。上述计算机可读存储介质用于存储上述计算机程序以及上述网络侧设备、终端设备或核心网设备所需的其他程序和数据。上述计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的数据。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，可通过计算机程序来指令相关的硬件来完成，该的程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可存储程序代码的介质。

本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。

本申请实施例装置中的模块可以根据实际需要进行合并、划分和删减。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (33)

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

从核心网设备接收第一寻呼消息，所述第一寻呼消息包括终端对应的第一指示、寻呼对象的标识和所述寻呼对象的下行数据，所述第一指示用于指示所述终端支持时延敏感寻呼；

确定与所述第一指示对应的第一寻呼载波组，所述第一寻呼载波组包括网络侧设备的多个寻呼载波中的部分寻呼载波；

在所述第一寻呼载波组的寻呼载波上向所述寻呼对象发送第二寻呼消息，所述第二寻呼消息包括所述寻呼对象的标识和所述下行数据的调度信息；

基于所述调度信息向所述寻呼对象发送所述下行数据。

2.如权利要求1所述的方法，其特征在于，所述方法还包括：

从终端接收寻呼能力信息，所述寻呼能力信息包括第二指示，所述第二指示用于指示所述终端支持时延敏感寻呼；

向核心网设备发送寻呼能力相关信息，所述寻呼能力相关信息包括第三指示，所述第三指示用于指示所述终端支持时延敏感寻呼。

3.如权利要求1或2所述的方法，其特征在于，所述方法还包括：

向所述终端发送寻呼配置，所述寻呼配置用于指示所述第一寻呼载波组和所述第一寻呼载波组的第一寻呼配置参数，所述第一寻呼配置参数包括第一默认寻呼周期DRX cycle。

4.如权利要求3所述的方法，其特征在于，所述寻呼配置还用于指示第二寻呼载波组和所述第二寻呼载波组的第二寻呼配置参数，所述第二寻呼载波组包括所述网络侧设备的多个载波中的另一部分寻呼载波，所述第二寻呼配置参数包括第二DRX cycle。

5.如权利要求1所述的方法，其特征在于，所述方法还包括：

使用所述寻呼对象的无线网络临时标识RNTI对所述下行数据进行加扰；

所述基于所述调度信息向所述寻呼对象发送所述下行数据包括：

基于所述调度信息向所述寻呼对象发送加扰后的所述下行数据。

6.如权利要求5所述的方法，其特征在于，所述方法还包括：

向所述寻呼对象发送调度所述第二寻呼消息的控制信息。

7.如权利要求6所述的方法，其特征在于，所述方法还包括：

使用所述寻呼对象的无线网络临时标识RNTI对所述控制信息进行加扰；

所述向所述寻呼对象发送所述控制信息包括：

向所述寻呼对象发送加扰后的所述控制信息。

8.如权利要求7所述的方法，其特征在于，所述方法还包括：

获取所述寻呼对象的所述RNTI；

向所述寻呼对象发送所述寻呼对象的标识和所述RNTI的对应关系。

9.如权利要求7或8所述的方法，其特征在于，所述寻呼对象为终端或者终端组。

10.如权利要求1所述的方法，其特征在于，所述方法还包括：

在随机接入过程中，从终端接收消息3，所述消息3包括第一信息，所述第一信息用于指示被叫数据早传；

从第一核心网设备获取所述终端的下行数据；

向所述终端发送消息4，所述消息4包括所述下行数据。

11.如权利要求10所述的方法，其特征在于，

所述第一信息为所述终端的标识，所述终端的标识与被叫数据早传具有关联关系；或者，

所述第一信息为所述消息3的原因值；或者，

所述第一信息为所述终端的能力信息或者类别信息；或者，

所述第一信息为用于请求进行被叫数据早传的信息。

12.如权利要求10或11所述的方法，其特征在于，所述从第一核心网设备获取所述终端的下行数据包括：

向所述第一核心网设备发送第二信息，所述第二信息用于指示所述终端的所述被叫数据早传；

从所述第一核心网设备接收所述终端的下行数据。

13.如权利要求12所述的方法，其特征在于，所述从第一核心网设备获取所述终端的下行数据包括：

向第二核心网设备发送第二信息，所述第二信息用于指示所述终端的所述被叫数据早传；

与所述第一核心网设备建立所述终端的数据承载；

通过所述数据承载从所述第一核心网设备接收所述终端的下行数据。

14.如权利要求13所述的方法，其特征在于，所述方法还包括：

从所述第二核心网设备接收第一消息，所述第一消息用于指示恢复所述终端的上下文。

15.一种寻呼消息传输方法，其特征在于，包括：

从网络侧设备接收寻呼配置，所述寻呼配置用于指示第一寻呼载波组和所述第一寻呼载波组的第一寻呼配置参数，所述第一寻呼载波组包括所述网络侧设备的多个寻呼载波中的部分寻呼载波，所述第一寻呼配置参数包括第一DRX cycle，所述第一寻呼载波组与时延敏感寻呼相关联；

若终端支持时延敏感寻呼，根据所述第一寻呼配置参数，在所述第一寻呼载波组的寻呼载波上接收第一寻呼消息，所述第一寻呼消息包括寻呼对象的标识和所述寻呼对象的下行数据的调度信息；

若所述寻呼对象的标识与所述终端的寻呼标识匹配，所述终端基于所述调度信息接收所述下行数据。

16.如权利要求15所述的方法，其特征在于，所述方法还包括：

向所述网络侧设备发送寻呼能力信息，所述寻呼能力信息包括第二指示，所述第二指示用于指示支持时延敏感寻呼。

17.如权利要求15或16所述的方法，其特征在于，

所述寻呼配置还用于指示第二寻呼载波组和所述第二寻呼载波组的第二寻呼配置参数，所述第二寻呼载波组包括所述网络侧设备的所述多个寻呼载波中的另一部分寻呼载波，所述第二寻呼配置参数包括第二DRX cycle。

18.如权利要求15所述的方法，其特征在于，所述下行数据是使用所述寻呼对象的无线网络临时标识RNTI加扰的。

19.如权利要求18所述的方法，其特征在于，所述方法还包括：

从所述网络侧设备接收调度所述第一寻呼消息的控制信息。

20.如权利要求19所述的方法，其特征在于，所述控制信息是使用所述寻呼对象的无线网络临时标识RNTI加扰的。

21.如权利要求20所述的方法，其特征在于，所述方法还包括：

从所述网络侧设备接收所述寻呼对象的标识和所述RNTI的对应关系。

22.如权利要求15所述的方法，其特征在于，所述寻呼对象为所述终端或者所述终端所属的终端组。

23.如权利要求15所述的方法，其特征在于，所述方法还包括：

在随机接入过程中，向网络侧设备发送消息3，所述消息3包括第一信息，所述第一信息用于指示被叫数据早传；

从所述网络侧设备接收消息4，所述消息4包括终端的下行数据。

24.如权利要求23所述的方法，其特征在于，

所述第一信息为所述终端的标识，所述终端的标识与被叫数据早传具有关联关系；或者，

所述第一信息为所述消息3的原因值；或者，

所述第一信息为所述终端的能力信息或者类别信息；或者，

所述第一信息为用于请求进行被叫数据早传的信息。

25.一种寻呼消息传输方法，其特征在于，包括：

从网络侧设备接收寻呼能力相关信息，所述寻呼能力相关信息包括终端对应的第一指示，所述第一指示用于指示所述终端支持时延敏感寻呼；

向所述网络侧设备发送第一寻呼消息，所述第一寻呼消息包括终端对应的第二指示、寻呼对象的标识和所述寻呼对象的下行数据，所述第二指示用于指示所述终端支持时延敏感寻呼。

26.如权利要求25所述的方法，其特征在于，还包括：

从所述网络侧设备接收寻呼触发消息，所述寻呼触发消息用于触发对所述终端的寻呼。

27.一种网络侧设备，其特征在于，包括执行如权利要求1至14任意一项所述的方法的单元。

28.一种终端设备，其特征在于，包括执行如权利要求15至24任意一项所述的方法的单元。

29.一种核心网设备，其特征在于，包括执行如权利要求25至26任意一项所述的方法的单元。

30.一种网络侧设备，其特征在于，所述网络侧设备包括：处理器、存储器和收发器，其中：

所述处理器、所述存储器和所述收发器相互连接，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行如权利要求1至14任意一项所述的方法。

31.一种终端设备，其特征在于，所述终端设备包括：处理器、存储器和收发器，其中：

所述处理器、所述存储器和所述收发器相互连接，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行如权利要求15至24任意一项所述的方法。

32.一种核心网设备，其特征在于，所述核心网设备包括：处理器、存储器和收发器，其中：

所述处理器、所述存储器和所述收发器相互连接，所述存储器用于存储计算机程序，所述计算机程序包括程序指令，所述处理器被配置用于调用所述程序指令，执行如权利要求25至26任意一项所述的方法。

33.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时，使所述处理器执行如权利要求1至26任意一项所述的方法。

Images