CN115552997A - 无线网络中寻呼信令的方法、设备及系统 - Google Patents

Abstract

本公开描述了用于UE监测寻呼DCI的方法和系统。寻呼DCI包括若干种不同的类型。UE被划分成多个组。每个UE组可以监测若干种类型的任意组合的寻呼DCI。寻呼DCI的类型由预定义特征来确定。与用于特定UE的每种类型的寻呼DCI相关联的寻呼帧和寻呼时机可以基于UE标识符来确定。本公开所描述的方案有助于降低寻呼监测中的虚警率，从而降低UE的UE功耗，尤其是处于RRC空闲状态或RRC非激活状态的UE。

Description

无线网络中寻呼信令的方法、设备及系统

技术领域

本公开总体涉及无线通信，特别是涉及用于各种类型的寻呼信令的方法、设备和系统。

背景技术

在设计无线通信网络和移动设备时，降低移动设备的功耗和增加电池寿命一直是重要的目标。无线通信网络和移动设备之间的有效信令可以大大有助于这样的省电。

发明内容

本公开涉及用于无线通信中各种类型的寻呼信令的方法、设备和系统。

在一些实施方式中，公开了一种由无线网络中的无线终端执行的方法。该方法可以包括：在预定持续时间内确定一个或多个寻呼时机(paging occasion，PO)，每个寻呼时机针对一种或多种类型的寻呼DCI中的一种，其中，该一种或多种类型的寻呼DCI中的至少一种的寻呼时机至少基于无线终端的截断的(truncated)标识符和无线终端的组标识符；以及在预定持续时间内监测一个或多个PO处的物理下行链路控制信道(PDCCH)。一种或多种类型的寻呼DCI包括第一类型、第二类型或第三类型的寻呼DCI中的至少一种。

还公开了一种无线终端。该无线终端包括处理器和存储器，其中处理器被配置为从存储器读取计算机代码以实施上述方法。还公开了一种计算机可读介质。该计算机可读介质包括指令或计算机程序，该指令或计算机程序在由无线终端执行时致使无线终端执行上述方法。

在下文的附图、描述和权利要求中更为详细地描述了上述实施例及其实施方式的其他方面和替代方案。

附图说明

图1示出了具有基站和UE之间的示例性空中(Over the Air，OTA)接口的无线通信网络。

图2示出了具有寻呼帧的示例性寻呼周期。

图3示出了寻呼帧和寻呼时机的详细结构。

图4示出了具有SSB(同步信号/PBCH块)和用于第一类型的寻呼下行链路控制信息(Downlink Control Information，DCI)的寻呼时机的示例性寻呼周期。

图5示出了使用第二类型的寻呼DCI的寻呼机制。

图6示出了使用第三类型的寻呼DCI的寻呼机制。

图7示出了使用第一和第二类型的寻呼DCI的寻呼机制。

图8示出了使用第二和第三类型的寻呼DCI的寻呼机制。

图9示出了使用第二类型的寻呼DCI的另一种寻呼机制。

图10示出了使用第二和第三类型的寻呼DCI的另一种寻呼机制。

图11示出了使用第一和第二类型的寻呼DCI的另一种寻呼机制。

图12示出了使用第一、第二和第三类型的寻呼DCI的另一种寻呼机制。

具体实施方式

介绍

图1示出了无线通信网络100，其包括核心网110和无线接入网(radio accessnetwork，RAN)120。RAN 120还包括多个基站122和124。基站122与用户设备(UE)130经由空中(OTA)无线通信资源140彼此通信。例如，无线通信网络100可以被实现为2G、3G、4G/LTE或5G蜂窝通信网络。相应地，基站122和124可以被实现为2G基站、3G nodeB、LTE eNB或5G新空口(New Radio，NR)gNB。UE 130可以被实现为安装有SIM/USIM模块进行接入无线通信网络100的移动或固定通信设备。UE 130可以包括但不限于移动电话、膝上型计算机、平板电脑、个人数字助理、可穿戴设备、分布式远程传感器设备、路边助理设备和台式计算机。可替选地，RAN 120可以被实现为其他类型的无线接入网，诸如Wi-Fi、蓝牙、ZigBee和WiMax网络。

在图1的无线通信系统100中，UE 130可以经由OTA接口140与基站122连接。如果有激活的通信会话与UE 130和基站122相关联，则UE和基站122之间的连接状态是激活的，并且UE处于激活模式(active mode)。另一方面，如果在UE 130和基站122之间没有激活的通信会话，则UE 130移动到RRC空闲(RRC idle)状态或RRC非激活(RRC inactive)状态。UE130在RRC空闲状态或RRC非激活状态期间限制其对无线资源的使用，并且可以通过使用包括但不限于不连续接收(Discontinuous Reception，DRX)的技术来降低功耗，如下文更详细描述的。

在DRX中，资源监测和通信活动以周期方式管理，这被称为DRX周期。图2示出了包括多个无线帧的DRX周期的示例性实施方式。特别地，在诸如LTE和5G的无线通信系统中，无线信号以无线帧进行发送。在系统级上，无线帧依次识别，并且每个无线帧用系统帧号(SFN)编号，该系统帧号例如从0至1023再循环。

在DRX模式中，UE可以进入睡眠模式以减少电池消耗。UE周期性地监测寻呼时机(Paging Occasion，PO)。PO是PDCCH监测时机的集合，并且可以包括寻呼DCI可以被发送的多个时隙(例如，子帧或OFDM符号)。一个寻呼帧(Paging Frame，PF)包括一个无线帧，并且可以包含一个或多个PO或PO的起始点。图2和图3给出了更详细的说明。在PO上周期性地监测的目的是要检查是否存在用于UE的寻呼消息以及获得系统信息更新，使得UE能够与网络同步。如果没有用于特定UE的寻呼消息，则UE可以返回到睡眠并在下一个周期中唤醒以监测PO。这种周期被称为寻呼周期或DRX周期。寻呼周期的长度由每个周期中无线帧的数量给出，表示为T。

图3示出了示例寻呼帧结构300。寻呼帧310是承载寻呼相关信息的特殊无线帧。寻呼帧310可以包含从0至9编索引的多个(例如，10个)子帧320。在寻呼帧310内，可以有至少一个PO 322或PO的起始点。PO 322对应于一个或多个PDCCH监测时机，并且每个PDCCH监测时机可以包括寻呼DCI可以被发送的一个或多个时隙。在示例无线通信系统中，在DRX周期中可以有至少一个寻呼帧，并且在寻呼帧中可以有至少一个PO或PO的起始点。多个UE可以被分配以监测相同PO，而每个UE在DRX周期中监测一个PO。特定UE的PF和PO可以使用预配置的或由高层信令配置的各种系统和UE参数来确定。

例如，PF的SFN号可以通过求解下式来确定：

(SFN+PF_offset)mod T＝(T div N)*(UE_ID mod N)

此外，用于指示PO在PF中的位置的索引(由i_s表示)可以由例如下式来确定：

i_s＝floor(UE_ID/N)mod Ns

这些公式中使用的参数描述如下：

·T：UE的DRX周期。T由一个或多个UE特定的DRX值(如果UE特定的DRX值由RRC和/或上层配置的话)和系统信息中广播的默认DRX值中的最短值来确定。在RRC_IDLE状态下，如果UE特定的DRX不由上层配置，则应用默认值。

·N：T中寻呼帧的总数。N表示DRX周期中寻呼帧的密度。

·Ns：PF的寻呼时机的数量。Ns表示PF中PO的密度。

·PF_offset：用于PF确定的偏移。

·UE_ID：5G-S-TMSI mod 1024。这是通过将ID空间中的最低有效比特保持在0至1023之间的截断的UE ID。

对PO的监测

在上文所述的PO检测过程中，在DRX周期中有至少一个PO，并且每个PO由多个UE共享。特别地，根据上述示例性公式，网络中的UE被分配给不同的UE池，并且每个UE池被映射到PO。例如，假设在特定系统中，在DRX周期中有2个PO。这两个PO可能在相同PF中也可能不在相同PF中。进一步假设有200个UE被映射到这两个PO。这200个UE可以落入两个池，即池1和池2，每个池包括例如100个UE。例如，在池1中分配的100个UE被调度以监测两个PO中的一个。在每个DRX周期中，池1中的这100个UE中的每个监测相应PO以获取寻呼DCI的寻呼消息指示，并且根据该寻呼消息指示而确定是否存在需要进一步处理的寻呼消息。

在一些实施方式中，寻呼消息指示可以调度承载寻呼消息的物理下行链路共享信道(Physical Downlink Shared Channel，PDSCH)。这样的指示可以不是UE特定的，并且寻呼消息可以以一个或多个UE为目标。这样，当寻呼DCI指示寻呼消息的下行链路调度时，即使不是所有的UE被寻呼，池中的每个UE也需要根据下行链路调度进一步解码寻呼消息，因为在成功解码寻呼消息之前，UE将不会获知其是否被寻呼。寻呼消息可以只以该UE池中的少许UE为目标。这样，其他非目标UE仍然必须仅解码寻呼消息，以便发现寻呼消息指向其他UE。这对于寻呼消息中的非目标UE被称为虚警(false alarm)。因此，这种虚警致使非目标UE浪费能量来执行解码。在极端情况下，如果寻呼消息仅针对组中的1个UE，则剩余99个未寻呼的UE仍将解码寻呼消息，这导致了高虚警率。一般而言，分配给PO的UE越多，虚警率就越高。

在这种情况下，总功率浪费可能是显著的。具体地，对于能够在一些情况下成功解码寻呼消息的UE，UE可能必须首先检测多个SSB(同步信号/PBCH块)以调整其AGC(Automatic Gain Control，自动增益控制)和/或时间/频率同步，用于正确解码寻呼DCI和寻呼消息。在本公开中，这种解码被称为深度解码(deep decoding)。深度解码可以是更加功率密集型的。这种虚警致使的深度解码在功率消耗方面非常浪费。图4示出了上述PO检测和深度解码过程。如图4所示，UE池在每个寻呼周期410中监测PO 416。为了使UE正确解码寻呼DCI和寻呼消息416，UE需要在深度解码以正确解码寻呼DCI和寻呼消息416之前首先检测一个或多个SSB 412和414。然而，最后，PO可能承载用于特定UE的寻呼信息或可能不承载用于特定UE的寻呼信息。

除了寻呼消息的调度信息以外，寻呼DCI还可以承载系统信息更新相关信息。如果UE仅需要获得系统信息更新并且不需要解码寻呼消息，则它可以这样做而不需要检测多个SSB。这个过程被称为轻解码(light decoding)，其比深度解码是较不功率密集型的。

下述各种实施方式被设计为减少由处于RRC空闲状态或RRC非激活状态的UE引起的深度解码的虚警量。同时，可以保持用于UE跟上系统信息更新的机会。

寻呼组和寻呼DCI的类型

为了减少由UE虚警引起的深度解码量，可以实施基于UE分组和多种类型的不同寻呼DCI的寻呼机制。特别地，可以设计不同类型的寻呼DCI。相同池中的UE还可以被划分成与相应的组ID相关联的不同组。PO的位置可以基于UE ID、组ID和/或寻呼DCI的类型中的至少一个来确定。一般而言，寻呼DCI类型的设计和UE池内UE的分组被实施为降低虚警率和/或减少UE进行深度解码的次数。每个UE组可以被配置为检测一种或多种类型的寻呼DCI。

当只有UE池中的UE组而不是整个UE池与一个PO相关联时，UE的分组降低了虚警率。例如，当上文所述的100个UE的UE池被划分成四个UE组，每个UE组25个UE时，特定UE的虚警率将会降低4倍。

在一些实施例中，每个UE可以与组ID相关联。具有相同组ID的UE被分组以监测包含一种或多种类型的寻呼DCI的一个或多个PO。组ID可以通过高层信令或系统信息来确定，或者可以通过解析UE-ID或通过解析UE的唯一5G-S-TMSI来确定。如上所述，UE-ID以例如5G-S-TMSI mod 1024的形式表示截断的移动标识符。

如以下各种实施方式中所示，可以设计各种类型的DCI，其中每种类型的DCI与以各种方式分布在多个DRX周期中的PO相关联，并且与UE池内的不同UE组相关联。虽然下文示出了三种不同类型的DCI，但是本领域普通技术人员可以基于所公开的实施方式来导出其他类型的DCI，而无需创造性的努力。

第一类型的寻呼DCI以一个或多个组中的UE为目标。在一些实施例中，第一类型的寻呼DCI可以与每个DRX周期中的PO相关联。不同组中的UE可以在每个DRX周期监测与第一类型的寻呼DCI相关联的相同PO。在一些实施例中，UE可能仅需要检测由第一类型的寻呼DCI承载的系统信息更新。UE可能不需要解码由第一类型的寻呼DCI调度的寻呼消息。特别地，通过执行轻解码而不是深度解码，UE在检测第一类型的寻呼DCI之前不检测多个SSB。

第二类型的寻呼DCI以一个UE组中的UE为目标。在一些实施例中，UE可能需要针对寻呼消息和系统信息更新而监测第二类型的寻呼DCI。在一些实施例中，第二类型的DCI与每个DRX周期中的PO相关联。每个UE组每G个DRX周期监测一个PO，其中G是正整数。在一些实施例中，G是UE组的数量。例如，如果100个UE被划分成4组，并且G可以被设置为4。特定组的每个UE每4个DRX周期监测第二类型的寻呼DCI。图5示出了使用第二类型的寻呼DCI的这种寻呼机制。例如，UE可以被划分成4个组，即组#0到组#3。在寻呼周期520期间，组#0中的UE监测用于第二类型的寻呼DCI的PO 510。图中未示出，在接下来的两个寻呼周期期间，组#1和组#2中的UE监测用于第二类型的寻呼DCI的PO。组号在每个寻呼周期中轮换。在寻呼周期522期间，组#3中的UE监测用于第二类型的寻呼DCI的PO 512。然后，在寻呼周期524中，组#0中的UE再次监测用于第二类型的寻呼DCI的PO 514。通过使用第二类型的寻呼DCI，每个UE可以仅需要每G个周期检测用于寻呼消息的调度的寻呼DCI。每个UE可以仅需要每G个DRX周期而不是每个DRX周期执行一次深度解码。

对于第三类型的寻呼DCI，寻呼DCI以一个或多个UE组为目标。在一些实施例中，UE可能需要针对寻呼消息和/或系统信息更新而监测第三类型的寻呼DCI。与第三类型的DCI相关的PO在多个DRX周期中出现频率较低。一个或多个目标组中的UE可以每G个DRX周期监测第三类型的寻呼DCI，其中G是正整数。在一些实施例中，G是UE组的数量。例如，如果100个UE被划分成4组，并且G可以被设置为4。这4个组中的每个UE每4个DRX周期监测第三类型的DCI。图6示出了使用第三类型的寻呼DCI的这种寻呼机制。例如，第三类型的寻呼DCI可以以4个UE组为目标。如图6所示，在寻呼周期620期间，所有4个组中的UE监测由第三类型的寻呼DCI作为目标的相同PO 610，然后等待直到寻呼周期622，以再次监测用于第三类型的寻呼DCI的PO 612。

UE监测某种类型的寻呼DCI的DRX周期的数量被称为该特定类型的寻呼DCI的周期。例如，如果UE每个DRX周期或每G1个DRX周期监测第一类型的寻呼DCI，则第一类型的寻呼DCI的周期分别是1个或G1个DRX周期。如果UE每G2个DRX周期监测第二类型的寻呼DCI，则第二类型的寻呼DCI的周期是G2个DRX周期。使用图5作为示例，第二类型的寻呼DCI每4个DRX周期以4个UE组中的每一组为目标，因此用于第二类型的寻呼DCI的周期530是4个DRX周期。同样，如果UE每G3个DRX周期监测第三类型的寻呼DCI，则第三类型的寻呼DCI的周期是G3个DRX周期。上述G1、G2和G3都是正整数。在一些实施例中，G1、G2或G3可以是UE组的数量。在一些其他实施例中，G1、G2或G3可以是2的幂。在一些其他实施例中，G1、G2和G3可以相同。如下所示，用于各种类型的寻呼DCI的周期可以扩展到M＝(G+g)，其中M是正整数，G是UE组的数量，且g是零或正整数，其表示DCI监测周期在多个组上的伸展(stretch)量。例如，对于特定类型的DCI，用于特定UE的DCI可以每M个DRX周期与PO相关联。

UE的特定组可以被配置为监测不同类型的DCI的组合。下文给出了示例组合。下文还描述了确定对应于每个UE组和用于每种类型的寻呼DCI的PO的示例方式。

实施例1

在该实施例中，UE被配置有第二类型的寻呼DCI。图5示出了用于UE仅检测第二类型的寻呼DCI的示例。对于在组#0中分配的UE，它监测寻呼周期520期间的PO 510。然后，它在下一个监测周期中监测寻呼周期524期间的PO514。在这种情况下，UE组的数量是4，并且相应地，DCI监测周期是4个DRX周期。每个UE组可以在4个DRX周期的监测周期内的相应DRX周期处接收寻呼DCI和寻呼消息(执行深度解码)，并且在监测周期内的其他DRX周期期间不监测任何寻呼DCI。由于减少了寻呼DCI和寻呼消息检测的数量，可以降低UE功耗。如上所述，监测周期可以伸展到超过4个周期。例如，监测周期可以伸展到5个周期。在这样的实施方式中，每个监测周期中的5个DRX周期中的一个可以对于四个UE组中的任何UE对应于无PO。

实施例2

在该实施例中，UE被配置有第一和第二类型的寻呼DCI。UE可以每个DRX周期检测用于系统信息更新的第一类型的寻呼DCI，但是不需要进一步接收调度的PDSCH。在这种情况下，UE不需要在与第一类型的寻呼DCI相关联的每个PO之前检测多个SSB，因此使用了轻解码并且降低了功耗。同时，对于寻呼DCI和寻呼消息，UE可以每G个DRX周期检测与第二类型的寻呼DCI相关联的PO(深度解码)。以这种方式，UE能够使用轻解码及时跟上每个DRX周期中的系统信息更新，同时使用深度解码检测每个G DRX周期中的寻呼消息的寻呼DCI。

图7示出了使用第一类型和第二类型的寻呼DCI的组合的示例。再次，假设对于第二类型的DCI，有四个UE组和4个DRX周期的监测周期。在寻呼周期740期间，组#0中的UE监测第二类型的寻呼DCI 712。公共PO 722表示与第一类型DCI相关联的PO，并且对于多于一组的UE是公共的，并且多于一组中的UE监测该公共PO 722。在下一个寻呼周期742期间，组#1中的UE监测第二类型的寻呼DCI 714，并且多于一个组中的UE监测与第一类型的寻呼DCI相关联的公共PO 724。同样，在下一个DRX周期744中，组#2中的UE监测第二类型的寻呼DCI716，并且多于一个组中的UE监测与第一类型的寻呼DCI相关联的公共PO 726。此外，在下一个DRX周期746中，组#3中的UE监测第二类型的寻呼DCI 718，并且多于一个组中的UE监测与第一类型的寻呼DCI相关联的公共PO 728。如图7的720和730所示，监测过程在下一个周期748中重复。同样，如上所述，监测周期可以伸展到超过4个周期。例如，监测周期可以伸展到5个周期。在这样的实施方式中，每个监测周期中的5个DRX周期中的一个可以仅对应于公共PO(对应于第一类型的寻呼DCI)。

实施例3

在该实施例中，UE被配置有第二和第三类型的寻呼DCI。UE可以每G个DRX周期检测第二和第三类型的寻呼DCI。图8示出了用于这种实施方式的示例。在寻呼周期840期间，组#0中的UE监测第二类型的寻呼DCI 812。公共PO 822表示与第三类型的寻呼DCI相关联的PO，并且第三类型的寻呼DCI以一个或多个UE组为目标，因此一个或多个组中的UE监测该公共PO 822。在下一个寻呼周期842期间，组#1中的UE监测第二类型的寻呼DCI 814，并且没有对应于第三类型的DCI的公共PO。在下一个寻呼周期844期间，组#2中的UE监测第二类型的寻呼DCI 816，并且没有对应于第三类型的寻呼DCI的公共PO。同样，在下一个寻呼周期846期间，组#3中的UE监测第二类型的寻呼DCI818，并且没有对应于第三类型的寻呼DCI的公共PO。重复上述过程，并且在寻呼周期848调度与第三类型的寻呼DCI相关联的下一个公共PO824。

在图8的示例实施例中，在4个DRX周期的监测周期期间，每个组执行两次深度解码。组#0UE在寻呼周期840中执行两种深度解码。组#1UE在DRX周期840和842中执行深度解码。组#2UE在DRX周期840和844中执行深度解码。组#3UE在DRX周期840和846中执行深度解码。再次，如上所述，监测周期可以伸展到超过4个周期。例如，监测周期可以伸展到5个周期。在这种实施方式中，监测周期中的5个DRX周期中的一个可以仅对应于与第三类型的DCI相对应的公共PO。

实施例4

在该实施例中，UE被配置有第一和第二类型的寻呼DCI。UE可以每G个DRX周期检测第一和第二类型的寻呼DCI，其中G可以被设置为具有或不具有伸展的UE组的数量。第一类型的寻呼DCI可能每G个DRX周期才出现一次。

实施例5

在该实施例中，UE被配置有第一、第二和第三类型的寻呼DCI。UE可以每G个DRX周期检测第二和第三类型的寻呼DCI，其中G是正整数。当UE检测到第二和第三类型的寻呼DCI时，它执行类似于上述第三实施例的深度解码。除此之外，UE还可以在每个DRX周期检测用于系统信息更新的第一类型的寻呼DCI。当UE检测到第一类型的寻呼DCI时，它可以在不接收调度的PDSCH的情况下执行轻度解码，并且在第一类型的寻呼DCI之前检测多个SSB。

实施例6

在该实施例中，如图6中的600所示，UE被配置有第三类型的寻呼DCI。UE可以每G个DRX周期检测第三类型的寻呼DCI。由于UE在多个DRX周期中醒来一次，因此可以降低功耗。图6示出了使用第三类型的寻呼DCI的示例。在寻呼周期620期间，一个或多个组中的UE监测PO 610。在接下来的三个DRX周期期间，一个或多个组中没有UE被调度以监测任何寻呼DCI。然后，再次在寻呼周期622期间，所有一个或多个组中的UE监测PO 612。

UE行为、要求和能力

UE可以被配置为支持三种类型的寻呼DCI的各种组合。根据一方面，UE可以被配置为检测多种寻呼DCI类型中的一种或多种类型的寻呼DCI。此外，UE可以确定寻呼帧和PO的定时，该PO承载以UE为目标的这些寻呼DCI。UE还需要频域相关信息来定位和解码寻呼DCI。

在一些实施例中，UE可以支持三个寻呼DCI的全部或组合，或者甚至某个寻呼DCI类型的部分特征。用于支持处理各种类型的寻呼DCI的UE能力可以包括但不限于：

·寻呼DCI的类型可以与UE能力或UE类别相关联。例如，UE类别可以包括具有降低的能力的UE或者新的无线UE。

·在一些实施例中，UE报告其是否支持第一或第二或第三类型的寻呼DCI。

·在一些实施例中，具有降低的能力的UE支持第一或第二或第三类型的寻呼DCI。

·在一些实施例中，UE经由UE辅助信息报告优选类型的寻呼DCI。

·在一些实施例中，寻呼DCI的优选配置或参数可以由UE辅助信息来传送。

UE可以通过使用诸如UE能力消息或UE辅助信息消息之类的机制向网络报告这种UE能力相关参数。例如，UE可以报告其是否支持第一或第二或第三类型的寻呼DCI，或者UE可以报告其是否降低了支持第二或第三类型的寻呼DCI的能力，或者UE可以向网络报告其优选类型的寻呼DCI。这种能力或优选信息可以包括在UE能力信令或UE辅助信息中。

在一些实施例中，支持第二类型或第三类型的寻呼DCI的UE能力通过频率范围来区分。在一些实施例中，第二类型或第三类型的寻呼DCI的UE辅助信息通过频率范围来区分。频率范围包括频率范围1(FR1)和频率范围2(FR2)。例如，表1给出了频率范围的定义。

表1：频率范围的定义

频率范围名称	相应频率范围
		FR1	410MHz-7125MHz
FR2	24250MHz-52600MHz

在一些实施例中，支持第二类型或第三类型的寻呼DCI的UE能力通过时分双工(Time-division Duplex，TDD)或频分双工(Frequency-division Duplex，FDD)来区分。

在一些具体实施方式中，UE确定PO，检测PO处的PDCCH，其中三种类型的寻呼DCI中的至少一种由PDCCH传送：第一类型的寻呼DCI、第二类型的寻呼DCI或第三类型的寻呼DCI。每种类型的寻呼DCI与一个或多个预定义特征相关联或者由一个或多个预定义特征来确定。

各种类型的寻呼DCI的预定义特征

每种类型的寻呼DCI与一个或多个预定义特征相关联，或者由其确定。这些预定特征可以包括但不限于以下至少一项：

·寻呼DCI的时域资源分配。

·寻呼DCI的频域资源分配。

·信息字段(有些信息字段可被用于承载寻呼DCI类型和/或UE组信息)。

·无线网络临时标识符。

·搜索空间集。

·CORESET(control resource set，控制资源集)。

·UE能力。

·UE类别。

·UE辅助信息。

·高层信令。

·与参考信号的关系。

这些预定义特征将在下文更为详细地描述。

PO的时域确定

在一些实施例中，预定义特征包括时域中的资源分配。时域中的资源分配包括寻呼帧、寻呼时机或寻呼时机的第一PDCCH监测时机中的至少一个。例如，对于不同类型的寻呼DCI，寻呼帧、寻呼时机或寻呼时机的第一PDCCH监测时机中的至少一个可能会不同。

例如，UE可以确定PF和PO的时域资源。下文描述了针对各种类型的DCI和不同UE组的PO的时域规范的示例。

对于网络和UE确定与每种类型的寻呼DCI相关联的特定PO的位置以及对于特定UE而言，网络以及UE需要能够根据通用规范在时域中确定PF和PO位置。下列小节更为详细地描述了如何确定这些位置。

寻呼帧(PF)

对于第一类型的寻呼DCI，寻呼帧至少与每个UE的UE-ID相关联。寻呼可能与UE组ID不相关，因为一个或多个组中的UE监测第一类型的寻呼DCI。

例如，用于PF的SFN号通过求解下式来确定：

(SFN+PF_offset_1)mod T_1＝(T_1/N)*(UE_ID mod N)，

其中，SFN是系统帧号，PF_offset_1是寻呼帧偏移值，T_1是第一类型的寻呼DCI的周期，并且N是周期内寻呼帧的数量。在一些实施例中，T_1表示DRX周期。UE_ID是截断的UE标识符。

在一些实施例中，第二或第三类型的寻呼DCI的寻呼帧由相对于第一类型的寻呼DCI的寻呼帧的偏移来确定。在一些实施例中，第二或第三类型的寻呼DCI的寻呼帧的偏移是不同的。在一些实施例中，第二或第三类型的寻呼DCI的寻呼帧的偏移范围或候选是不同的。在一些实施例中，偏移与子载波间隔或频率范围中的至少一个相关联。

在一些实施例中，对于第二类型的寻呼DCI，寻呼帧由UE-ID、组ID或组数量中的至少一个来确定。例如，第二类型的寻呼帧至少由UE-ID和组ID来确定。例如，第二类型的寻呼帧至少由UE-ID、组ID和组的数量来确定。

例如，PF的SFN号可以通过求解下式来确定：

(SFN+PF_offset_2)mod T_2＝(T_2/N/(G+g))*(UE_ID mod N)+(T_2/G)*(GRP_ID+i)；

或者，

(SFN+PF_offset_2)mod T_2＝(T_2/N/(G+g))*(UE_ID mod N)+(T_2/G/N)*(GRP_ID+i)，

其中，SFN是系统帧号，PF_offset_2是寻呼帧偏移值，T_2是第二类型的寻呼DCI的周期，N是周期内寻呼帧的数量，GRP_ID是组ID，i是整数，并且其中M＝G+g，且M是整数。特别地，数字g表示在组号G上伸展的周期。UE_ID是截断的UE标识符。在一些实施例中，T_2是DRX周期的(G+g)倍。

用于针对第二类型的寻呼DCI确定上述寻呼帧偏移的第二公式与第一公式的不同之处在于，用于第二类型的寻呼DCI的PF被压缩到一个或多个DRX周期中，而不是在监测周期T_2期间的每个DRX周期上扩展，如图9中的900所示。特别地，图9示出了用于第二类型的寻呼DCI的寻呼机制，其周期等于4个DRX周期。由上述第一公式确定的用于第二类型的寻呼DCI的所有四个DRX周期中扩展的示例寻呼帧根据第二公式被压缩到一个DRX周期910中，如寻呼帧PF 920、PF 922、PF 924和PF 926所示。这4个UE组中的UE在相同DRX周期910中的寻呼帧PF 920、PF 922、PF 924和PF 926中的一个中监测相应的PO。替代图9所示的配置，通过调整第二公式中的参数，诸如N和G，用于四个UE组的这4个PF可以被分布到两个或三个DRX周期中。

对于第三类型的寻呼DCI，寻呼帧由UE-ID、组ID或组的数量中的至少一个来确定。例如，第三类寻呼帧至少由UE-ID和组的数量来确定。例如，第三类寻呼帧至少由UE-ID、组ID和组的数量来确定。

例如，PF的SFN号可以通过求解下式来确定：

(SFN+PF_offset_3)mod T_3＝(T_3/N/(G+g))*(UE_ID mod N)+(T_3/G)*(GRP_ID_one+j)；

或者，

(SFN+PF_offset_3)mod T_3＝(T_3/N/(G+g))*(UE_ID mod N)+(T_3/G)*(GRP_ID_one+j)，

其中SFN是系统帧号，PF_offset_3是寻呼帧偏移值，T_3是第三类型的寻呼DCI的周期，N是周期内寻呼帧的数量，其中g和j是整数，并且其中GRP_ID_one是整数。在一些实施例中，GRP_ID_one由高层信令配置。UE_ID是截断的UE标识符。在一些实施例中，GRP_ID_one是组ID中的一个。在一些实施例中，T3是DRX周期的(G+g)倍。

在所有用户组的第二类型的寻呼DCI被压缩到例如一个或多个DRX周期的情况下，包括第二类型的寻呼DCI的上述各种实施例将会具有不同于对应于图6至图7的实施例4(第一类型的和第二类型的寻呼DCI的组合)和实施例3(第二类型的和第三类型的寻呼DCI的组合)以及实施例5(第一类型的、第二类型的和第三类型的寻呼DCI的组合)的时域配置。图10至图12示出了第二类型的寻呼DCI的相应配置。例如，如图10所示，在一个DRX周期1010期间，UE组0-3在1028处监测用于第三类型的寻呼DCI的PO，并且每个组中的UE另外分别在1020、1022、1024和1026处监测用于第二类型的寻呼DCI的PO。又例如，如图11所示，在一个DRX周期1110期间，组0-3中的UE在1128处监测第一类型的寻呼DCI的PO，并且每个组中的UE另外分别在1120、1122、1124和1126处监测用于第二类型的寻呼DCI的PO。还例如，如图12所示，在一个DRX周期1210期间，组0-3中的UE在1230处监测用于第一类型的寻呼DCI的PO，并且每个组中的UE另外分别在1220、1122、1124和1126处监测用于第二类型的寻呼DCI的PO。在DRX周期1210中，每个组中的UE还在1228处监测用于第三类型的寻呼DCI的PO。

寻呼时机确定

PF内的第一或第二或第三类型的寻呼DCI的寻呼时机至少与UE-ID相关联。

用于指示PO在PF内的位置的索引(由i_s_1表示)，由下式确定：

i_s_1＝floor(UE_ID/N)mod Ns，

其中Ns是PF内由第一或第二或第三类型的寻呼DCI作为目标的PO的数量，N是周期内寻呼帧的数量。UE_ID是截断的UE标识符。

在一些实施例中，第二或第三类型的寻呼DCI的寻呼时机由相对于第一类型的寻呼DCI的寻呼时机的偏移来确定。在一些实施例中，第二或第三类型的寻呼DCI的寻呼时机的偏移是不同的。在一些实施例中，第二或第三类型的寻呼DCI的寻呼时机的偏移的范围或候选是不同的。在一些实施例中，偏移与子载波间隔或频率范围中的至少一个相关联。

例如，用于指示PO在第二和第三类型的寻呼DCI的PF内的位置的索引(由(i_s_2)和(i_s_3)表示)可以分别由下式确定：

i_s_2＝floor(UE_ID/N)mod Ns+offset_2，以及

i_s_3＝floor(UE_ID/N)mod Ns+offset_3

第二类型的寻呼DCI的寻呼时机至少由UE-ID和/或组ID来确定。例如，偏移值由UE-ID和/或组ID来确定。

PO的第一PDCCH监测时机

在一些实施例中，第一或第二或第三类型的寻呼DCI的PO的第一PDCCH监测时机可以由高层信令确定。

在一些实施例中，第二或第三类型的寻呼DCI的PO的第一PDCCH监测时机由相对于第一类型的寻呼DCI的PO的第一PDCCH监测时机的偏移确定。在一些实施例中，第二或第三类型的寻呼DCI的PO的第一PDCCH监测时机的偏移是不同的。在一些实施例中，第二或第三类型的寻呼DCI的PO的第一PDCCH监测时机的偏移的范围或候选是不同的。在一些实施例中，偏移与子载波间隔或频率范围中的至少一个相关联。

在一些实施例中，第二或第三类型的寻呼DCI的PO的第一PDCCH监测时机至少由UE-ID和/或组ID来确定。

时域资源分配

从时域资源分配的角度来看，本公开公开了用于第一、第二或第三类型的寻呼DCI的若干种不同的组合，列举如下：

·第三类型的寻呼DCI的资源可以与第一类型的寻呼DCI的资源共享。

·第二或第三类型的寻呼DCI的时域中的资源分配可以由相对于第一类型的寻呼DCI的时域中的资源分配的偏移来确定。在一些实施例中，第二或第三类型的寻呼DCI的时域中的资源分配的偏移是不同的。在一些实施例中，第二或第三类型的寻呼DCI的时域中的资源分配的偏移的范围或候选是不同的。在一些实施例中，偏移与子载波间隔或频率范围中的至少一个相关联。

·在一些实施例中，具有不同组ID的第二类型的寻呼DCI被时分复用(TDM)。·在一些实施例中，第一类型的寻呼DCI和第二类型的寻呼DCI被时分复用(TDM)。

·在一些实施例中，第二类型的寻呼DCI和第三类型的寻呼DCI被时分复用(TDM)。

·在一些实施例中，第一类型的寻呼DCI和第三类型的寻呼DCI被时分复用(TDM)。

在一些实施例中，每种类型的寻呼DCI与周期、寻呼帧、寻呼时机或PO的第一PDCCH监测时机中的至少一个相关联。上文已经详细描述了不同类型的寻呼DCI的周期实施方式以及寻呼帧和寻呼帧内的PO的确定。上文也已经详细描述了PO的第一个PDCCH监测时机的确定。

用于各种类型的寻呼DCI(诸如第二或第三类型的寻呼DCI)的时域资源分配可以取决于UE的组ID。上文已经描述了实施组ID的各种选项。

频域资源分配

从频域资源分配的角度，本公开公开了第一、第二或第三类型的寻呼DCI的若干种不同的组合，列举如下：

·第三类型的寻呼DCI的资源可以与第一类型的寻呼DCI的资源共享。

·第一类型的寻呼DCI的频域中的资源分配可以由高层信令来确定。

·第二或第三类型的寻呼DCI的频域中的资源分配可以由相对于第一类型的寻呼DCI的频域中的资源分配的偏移来确定。在一些实施例中，第二或第三类型的寻呼DCI的频域中资源分配的偏移是不同的。在一些实施例中，第二或第三类型的寻呼DCI的频域中资源分配的偏移的范围或候选是不同的。在一些实施例中，偏移与子载波间隔或频率范围中的至少一个相关联。

·在一些实施例中，第一类型的寻呼DCI和第二类型的寻呼DCI被频分复用(FDM)。

·在一些实施例中，第二类型的寻呼DCI和第三类型的寻呼DCI被频分复用(FDM)。

·在一些实施例中，第一类型的寻呼DCI和第三类型的寻呼DCI被频分复用(FDM)。

在一些实施例中，寻呼DCI的类型由时域和频域中的资源分配来确定，或者与其相关联。

DCI信息域

上述各种类型的寻呼DCI承载各种信息字段。在一些实施例中，第一类型的寻呼DCI包括以下信息字段：

·短消息指示符。

·短消息。

·频域资源分配。

·时域资源分配。

·VRB到PRB的映射。

·调制和编码方案。

·TB缩放。

·保留比特。

在一些实施例中，第二类型的寻呼DCI调度用于UE组的寻呼消息。第二类型的寻呼DCI包括以下信息字段：

·短消息指示符。

·短消息。

·频域资源分配。

·时域资源分配。

·VRB到PRB的映射。

·调制和编码方案。

·TB缩放。

·附加信息比特。

在一些实施例中，第三类型的寻呼DCI是多个UE组共享的公共寻呼DCI。第三类型的寻呼DCI调度用于多于一组的UE的寻呼消息。第三类型的寻呼DCI包括以下信息字段：

·短消息指示符。

·短消息。

·频域资源分配。

·时域资源分配。

·VRB到PRB的映射。

·调制和编码方案。

·TB缩放。

·附加信息比特。

在一些实施例中，第三类型的寻呼DCI包括第一类型的寻呼DCI，或者第一类型的寻呼DCI包括第三类型的寻呼DCI。

在一些实施例中，第一或第二或第三类型的寻呼DCI包括指示参考信号配置的更新的信息字段，其中参考信号包括信道状态信息参考信号(CSI-RS)或跟踪参考信号(TRS)中的至少一个。TRS可以被CSI-RS跟踪。

在一些实施例中，寻呼DCI的类型与多个信息字段的解释或值或代码点相关联，或者由其确定。多个信息字段包括短消息或预定义信息字段中的至少一个。

用于承载寻呼DCI类型指示和/或组ID的信息字段：短消息

寻呼DCI承载指示其在三种类型的寻呼DCI中的类型的信息。以特定的一个或多个UE组为目标的寻呼DCI承载一个或多个UE组的组ID信息。这种信息可以由如上所述的寻呼DCI的各种信息字段以下文详述的方式承载。

在一个实施例中，寻呼DCI类型指示符可被承载在短消息中。短消息信息字段包括M个比特，其中M是正整数。在一种实施方式中，M＝8。寻呼DCI的类型由短消息中的多个比特来确定。例如，多个比特包括短消息的第3至第8个比特中的至少一个。

例如，当多个比特被设置为值V1时，它指示第一类型的寻呼DCI。在一些实施方式中，V1可以全是0或全是1。又例如，当多个比特被设置为值V2时，它指示第二类型的寻呼DCI。又例如，当多个比特被设置为值V2时，它指示第二类型的寻呼DCI。在一些实施方式中，对于第二类型的寻呼DCI，组ID被传送。比特图可被用于指示某些组或子组是否被寻呼。又例如，当多个比特被设置为值V3时，它指示第三类型的寻呼DCI。在一些实施方式中，组ID由第三类型的寻呼DCI传送。比特图可被用于指示某些组是否被寻呼。

在另一个实施例中，寻呼DCI类型指示符可被承载在短消息的代码点中。例如，当短消息的代码点被设置为值C1时，它指示第一类型的寻呼DCI。在一些实施方式中，C1可以全是0或全是1。再比如，当短消息的码位设置为值C2时，它指示第二类型的寻呼DCI。在一些实施方式中，组ID或子组ID由第二类型的寻呼DCI指示。该指示可以是比特图。再比如，当短消息的码位设置为值C3时，它指示第三类型的寻呼DCI。在一些实施方式中，组ID由第三类型的寻呼DCI指示。该指示可以是比特图。

在另一个实施例中，短消息的多个比特的解释与寻呼DCI的类型相关联。例如，多个比特可以是用于第一类型的寻呼DCI的保留比特。又例如，多个比特被用作比特图，以指示对于第二类型的寻呼DCI，组或子组是否被寻呼。还例如，多个比特用于指示对于第三类型的寻呼DCI，这些组是否被寻呼。该指示还可以是比特图。

用于承载寻呼DCI类型指示和/或组ID的信息字段：预定义信息字段

在另一个实施例中，DCI还承载预定义信息字段。预定义信息字段包括TB缩放信息字段之后的信息字段。预定义信息字段可以包括保留比特或附加信息比特。在一些实施例中，预定义信息是第一类型的寻呼DCI中的保留比特。在一些实施例中，预定义信息字段是第二或第三类型的寻呼DCI中的附加信息比特。在一种实施方式中，当预定义信息字段被设置为R1时，它指示第一类型的寻呼DCI。在另一种实施方式中，R1可以全是0或全是1。在另一种实施方式中，当预定义信息字段被设置为R2时，它指示第二类型的寻呼DCI。在一些实施方式中，组ID或子组ID由第二类型的寻呼DCI传送。例如，预定义信息字段中的多个比特被用作比特图，以指示对于第二类型的寻呼DCI，组或子组是否被寻呼。在另一种实施方式中，当预定义信息字段被设置为R3时，它指示第三类型的寻呼DCI。在一些实施方式中，组ID由第三类型的寻呼DCI传送。该指示符还可以是比特图。

在一些情况下，预定义信息字段的多个比特的解释与寻呼DCI的类型相关联。在一些实施方式中，多个比特是用于第一类型的寻呼DCI的保留比特。在一些实施方式中，多个比特用于指示对于第二类型的寻呼DCI是否寻呼了组或子组。该指示符还可以是比特图。在一些实施方式中，多个比特用于指示对于第三类型的寻呼DCI，是否寻呼了这些组。该指示符还可以是比特图。

在一些实施例中，寻呼DCI的类型由时域中的资源分配以及信息字段的解释或值来确定，或者与其相关联。在一些实施例中，寻呼DCI的类型由频域中的资源分配以及信息字段的解释或值来确定，或者与其相关联。在一些实施例中，寻呼DCI的类型由时域和频域中的资源分配以及信息字段的解释或值来确定，或者与其相关联。

用于各种类型的寻呼DCI的RNTI

在一些实施例中，第一类型的寻呼DCI的循环冗余校验(Cyclic RedundancyCheck，CRC)比特被P-RNTI(Paging-Radio Network Temporary Identifier，寻呼无线网络临时标识符)加扰。在一些实施例中，第二或第三类型的寻呼DCI的CRC比特由RNTI而不是P-RNTI加扰。

在一些实施例中，被用于加扰第一类型的寻呼DCI的CRC比特的RNTI值是FFFE(十六进制数)。在一些实施例中，被用于加扰第二或第三类型的寻呼DCI的CRC比特的RNTI的值是不同于FFFE(十六进制数)的值。例如，它可能在FFF0–FFFD(十六进制数)的范围内。

在一些实施例中，寻呼DCI的类型由时域/频域中的资源分配和被用于加扰寻呼DCI的CRC比特的RNTI来确定，或者与其相关联。在一些实施例中，寻呼DCI的类型由被用于加扰寻呼DCI的CRC比特的信息字段和RNTI的解释/值来确定，或者与其相关联。

高层信令或系统信息；搜索空间集；CORESET；子载波间隔

在一些实施例中，寻呼DCI的类型由高层信令或系统信息来确定，或者与其相关联。

在一些实施例中，寻呼DCI的类型由时域/频域中的资源分配和高层信令来确定，或者与其相关联。在一些实施例中，寻呼DCI的类型由RNTI和高层信令来确定，或者与其相关联。

在一些实施例中，寻呼DCI的类型与SCS(子载波间隔)相关联。在示例实施方式中，寻呼DCI的类型取决于子载波间隔。

在一些实施例中，寻呼DCI的类型与搜索空间集或搜索空间集ID相关联。例如，第一或第二或第三寻呼DCI中的至少一个具有专用搜索空间集或搜索空间集ID。又例如，具有不同组ID的第二类型的寻呼DCI由搜索空间集或搜索空间集ID区分。

在一些实施例中，寻呼DCI的类型与CORESET(Control Resource Set，控制资源集)或CORESET ID相关联。例如，第一或第二或第三类型的寻呼DCI中的至少一个具有专用CORESET或CORESET ID。又例如，具有不同组ID的第二类型的寻呼DCI由CORESET或CORESETID区分。

UE能力

上文已经更为详细地描述了与处理各种类型的寻呼DCI相关联的UE能力或类别或辅助信息。

DCI格式

在一些实施例中，寻呼DCI的类型可以与DCI格式相关联。在一些实施例中，第一类型的寻呼DCI可以是DCI格式0-1。在一些实施例中，第二或第三类型的寻呼DCI可以是不同于DCI格式0-1的DCI格式。

在一些实施例中，寻呼DCI的类型由时域/频域中的资源分配和DCI格式来确定，或者与其相关联。

在一些实施例中，寻呼DCI的类型由RNTI和DCI格式来确定，或者与其相关联。

在一些实施例中，寻呼DCI的类型由RNTI和搜索空间集来确定，或者与其相关联。

在一些实施例中，寻呼DCI的类型由RNTI和CORESET来确定，或者与其相关联。

与参考信号的关系

在一些实施例中，寻呼DCI的类型与相对于参考信号的偏移相关联。在一些实施例中，第一或第二或第三类型的寻呼DCI的偏移是不同的。在一些实施例中，第一或第二或第三类型的寻呼DCI的偏移的范围或候选是不同的。在一些实施例中，偏移与子载波间隔或频率范围中的至少一个相关联。

在一些实施例中，寻呼DCI的类型与相对于参考信号的周期相关联。例如，第一类型的寻呼DCI的周期可以是参考信号的周期的倍数，诸如N1倍。例如，第二类型的寻呼DCI的周期可以是参考信号周期的倍数，诸如N2倍。例如，第三类型的寻呼DCI的周期可以是参考信号周期的倍数，诸如N3倍。其中N1、N2和N3是正整数。在一些实施例中，参考信号是SSB、CSI-RS(信道状态信息参考信号)、TRS(跟踪参考信号)中的至少一个。

实施例1的详细描述

详细描述了基于第二类型的寻呼DCI的寻呼调度和控制机制的示例性实施例。

UE被配置为至少支持第二类型的寻呼DCI。参照图5作为示例。有4个UE组并且特定UE被分配到组#0。UE被配置为每4个寻呼周期(寻呼周期也被称为DRX周期)检测第二类型的寻呼DCI。在该特定实施方式中，第二类型的寻呼DCI的周期是4个DRX周期，其示出为周期530。在寻呼周期520期间，UE唤醒并检测PO，并进一步解码来自PO的PDCCH信道的寻呼DCI。基于DCI中承载的信息，UE可以采取进一步行动，诸如定位和解码来自PDSCH信道的寻呼消息。

第二类型的寻呼DCI调度用于UE组的寻呼消息。例如，在寻呼周期520处调度用于组#0UE的寻呼消息，而在寻呼周期522处调度组#3UE的寻呼消息。

第二类型的寻呼DCI包括以下信息字段：

·短消息指示符。

·短消息。

·频域资源分配。

·时域资源分配。

·VRB到PRB的映射。

·调制和编码方案。

·TB缩放。

在一些情况下，寻呼DCI的类型由多个比特的短消息来确定。其中，多个比特包括短消息的第3至第8比特中的至少一个。

在一些情况下，寻呼DCI的类型由短消息的代码点来确定。

在一些情况下，寻呼DCI的类型由预定义信息字段来确定。在一些情况下，第二类型的寻呼DCI传送被寻呼的组ID。

在一些情况下，具有不同组ID的第二类型的寻呼DCI被时分复用(TDM)

在一些情况下，UE每G2个DRX周期检测第二类型的寻呼DCI，或者第二类型的寻呼DCI的寻呼时机的周期为G2个DRX周期。在一些情况下，G2可以是组的数量。例如，如图5所示，有四个寻呼组，并且周期是4个DRX周期。在一些情况下，G2可以是2的幂。

在一些情况下，第二类型的寻呼DCI的寻呼帧至少由UE-ID、组ID和组的数量来确定。

例如，用于寻呼帧(由PF_offset_2表示)的SFN号通过求解下式来确定：(SFN+PF_offset_2)mod T_2＝(T_2/N/G)*(UE_ID mod N)+(T_2/G)*GRP_ID；

或者，

(SFN+PF_offset_2)mod T_2＝(T_2/N/G)*(UE_ID mod N)+(T_2/G/N)*GRP_ID；其中，SFN是系统帧号，PF_offset_2是偏移值，T_2是第二类型的寻呼DCI的周期，N是周期内寻呼帧的数量，G是组的数量，并且GRP_ID是组ID。

在一些情况下，组ID由高层信令或系统信息来确定。在一些情况下，组ID由UE-ID或5G-S-TMSI来确定。

在一些情况下，T2是DRX周期的G倍。

用于指示PO在PF内的位置的索引(由(i_s_2)表示)由下式确定：

i_s_2＝floor(UE_ID/N)mod Ns+offset_2

其中，Ns是PF内第一类型的寻呼DCI的PO的数量，其中offset_2是偏移值，offset_2是整数。

在一些情况下，第二类型的DCI的资源与第一类型的DCI的资源共享。

在一些情况下，第二类型的DCI的资源分配被与第一类型的DCI的资源分配频分复用(FDM)或时分复用(FDM)。

在一些情况下，第二或第三类型的寻呼DCI由RNTI而不是P-RNTI加扰。

在一些情况下，被用于加扰第二类型的寻呼DCI的RNTI值不是FFFE(十六进制数)。例如，该值在FFF0–FFFD(十六进制数)的范围内。

在一些情况下，UE报告其是否支持第二类型的寻呼DCI。

在一些情况下，UE被配置有降低的能力以支持第二类型的寻呼DCI。

在一些情况下，第二类型的寻呼DCI的优选配置或参数可以由UE辅助信息来传送。

其他实施例(诸如实施例2-6)的细节可以以类似于上述第一实施例的方式推导。

总而言之，上面的公开内容描述了用于UE监测寻呼DCI的方法和系统。寻呼DCI包括若干种不同的类型。UE被划分成多个组。每个UE组可以监测若干种类型的任意组合的寻呼DCI。寻呼DCI的类型由预定义特征来确定。与用于特定UE的每种类型的寻呼DCI相关联的寻呼帧和寻呼时机可以基于UE标识符来确定。本公开所描述的方案有助于降低寻呼监测中的虚警率，从而降低UE的UE功耗，尤其是处于RRC空闲状态或RRC非激活状态的UE。

下面的各种实施方式被设计为减少处于空闲状态的UE深度解码引起的虚警量，同时为UE保持充足的机会以跟上系统更新信息。

上文的描述和附图提供了具体示例实施例和实施方式。然而，所描述的主题可以用各种不同的形式体现，并因此，所覆盖的或所要求保护的主题旨在被解释为不限于本文所阐述的任何示例实施例。旨在针对所要求保护的或所覆盖的主题的合理宽泛的范围。除了其他方面，例如，主题可以体现为用于存储计算机代码的方法、设备、组件、系统或非暂时性计算机可读介质。因此，实施例可以例如采取硬件、软件、固件、存储介质或其任何组合的形式。例如，上文描述的方法实施例可以由包括存储器和处理器的组件、设备或系统通过执行存储在存储器中的计算机代码来实施。

在整篇说明书和权利要求书中，除了明确陈述的含义之外，术语可以具有在上下文中提议或暗示的微妙含义。同样地，如本文所使用的短语“在一个实施例/实施方式中”不一定指的是相同的实施例，并且如本文所用的短语“在另一个实施例/实施方式中”不一定指的是不同的实施例。例如，旨在所要求保护的主题包括示例实施例的全部或部分组合。

一般而言，术语可以至少部分地从上下文中的用法来理解。例如，如本文所使用的术语，诸如“和”、“或”、“和/或”，可以包括各种含义，这些含义可以至少部分地取决于在其中使用这些术语的上下文。典型地，如果“或”用于关联诸如A、B或C的列表，则旨在意味着这里在包含性的意义上使用的A、B和C，以及这里在排他性的意义上使用的A、B或C。另外，如本文所使用的术语“一个或多个”，至少部分地取决于上下文，可以用于在单数意义上描述任何特征、结构或特性，或者可以用于在复数意义上描述特征、结构或特性的组合。类似地，诸如“一”、“一个”或“该”的术语可以被理解为至少部分地取决于上下文而传送单数的用法或传送复数的用法。另外，术语“基于”可以被理解为不一定旨在传送排他的因素集合，而是可以同样至少部分地取决于上下文而允许不一定明确描述的额外因素的存在。

在整篇说明书中，对特征、优点或类似语言的参照并非暗示可以利用本解决方案实现的所有特征和优点应当或包括在其任何单个实施方式中。相反，涉及特征和优点的语言被理解为意味着结合实施例所描述的具体特征、优点或特性被包括在本解决方案的至少一个实施例中。因此，在整篇说明书中，对特征和优点的讨论以及类似的语言可以但未必是指相同的实施例。

此外，本解决方案的所描述的特征、优点和特性可以在一个或多个实施例中以任何合适的方式组合。相关领域的普通技术人员将认识到，依据本文中的描述，本解决方案可以在没有特定实施例的一个或多个具体的特征或优点的情况下来实践。在其他情况下，额外的特征和优点可以在可能不存在于本解决方案的所有实施例的某些实施例中认识到。

Claims (37)

1.一种由无线网络节点中的无线终端执行的方法，包括：

在预定持续时间内确定一个或多个寻呼时机PO，每个寻呼时机针对一种或多种类型的寻呼DCI中的一种类型的寻呼DCI，其中，所述一种或多种类型的寻呼DCI中的至少一种类型的寻呼DCI的寻呼时机至少基于所述无线终端的截断的标识符和所述无线终端的组标识符；以及

在预定持续时间内监测所述一个或多个PO处的物理下行链路控制信道PDCCH，

其中，所述一种或多种类型的寻呼DCI包括第一类型的寻呼DCI、第二类型的寻呼DCI或第三类型的寻呼DCI中的至少一种。

2.根据权利要求1所述的方法，其中，所述第一类型的寻呼DCI、所述第二类型的寻呼DCI或所述第三类型的寻呼DCI中的每一种类型都与预定义特征相关联，或者由其确定。

3.根据权利要求2所述的方法，其中，所述第一类型的寻呼DCI、所述第二类型的寻呼DCI或所述第三类型的寻呼DCI包括选自以下中的至少一个信息字段：

短消息指示符；

一条或多条短消息；

频域资源分配；

时域资源分配；

虚拟资源块与物理资源块之间的映射；

调制和编码方案；

传输块缩放；或者

附加信息比特。

4.根据权利要求1所述的方法，其中，所述第一类型的寻呼DCI或所述第三类型的寻呼DCI包括一个或多个无线终端组的信息。

5.根据权利要求4所述的方法，其中，所述一个或多个无线终端组由组标识符的集合标识。

6.根据权利要求1所述的方法，其中，所述第二类型的寻呼DCI包括一个无线终端组的信息。

7.根据权利要求6所述的方法，其中，所述一个无线终端组由所述组标识符标识。

8.根据权利要求3所述的方法，其中，所述预定义特征包括以下中的至少一个：

所述至少一个信息字段中的一个或多个信息字段；

频域中的资源分配；

时域中的资源分配；

无线网络临时标识符RNTI

搜索空间集；

控制资源集；

无线终端能力或无线终端类别；

无线终端辅助信息；

高层信令；或者

与参考信号的关系。

9.根据权利要求8所述的方法，其中，所述预定义特征包括所述至少一个信息字段中的一个或多个信息字段。

10.根据权利要求9所述的方法，其中，寻呼DCI的所述至少一个信息字段中的一个或多个信息字段包括类型指示符，其指示所述第一类型、所述第二类型或所述第三类型中的至少一种中的寻呼DCI的类型。

11.根据权利要求9所述的方法，其中，寻呼DCI的所述至少一个信息字段中的一个或多个信息字段包括用于指示至少一个无线终端组的至少一个组指示符，或者用于指示至少一个无线终端子组的至少一个子组指示符。

12.根据权利要求8所述的方法，其中，所述至少一个信息字段中的一个或多个信息字段包括所述一条或多条短消息的一个或多个比特或者所述附加信息比特。

13.根据权利要求8所述的方法，其中，所述预定义特征包括所述时域中的资源分配。

14.根据权利要求13所述的方法，其中，所述时域中的资源分配与寻呼DCI的预定持续时间相关联。

15.根据权利要求13所述的方法，其中：

所述预定持续时间包括M个不连续接收DRX周期；并且

M是第一预定正整数。

16.根据权利要求15所述的方法，还包括：在所述预定持续时间内的每个DRX周期中监测所述第一类型的寻呼DCI。

17.根据权利要求15所述的方法，还包括：每M个DRX周期监测所述第二类型的寻呼DCI或所述第三类型的寻呼DCI，其中M不小于无线终端组的数量。

18.根据权利要求15所述的方法，所述时域中的资源分配包括所述一个或多个PO的时间位置。

19.根据权利要求18所述的方法，其中，确定所述一个或多个PO包括：

确定对应于所述一个或多个PO的寻呼帧；和

确定所述寻呼帧中的所述一个或多个PO的索引。

20.根据权利要求19所述的方法，其中，确定用于所述第二类型的寻呼DCI或所述第三类型的寻呼DCI的寻呼帧基于所述无线终端的截断的标识符、所述无线终端的组标识符或M中的至少一个。

21.根据权利要求20所述的方法，其中，确定用于所述第二类型的寻呼DCI的寻呼帧基于以下公式中的至少一个：

(SFN+PF_offset2)mod T2＝(T2/N/M)*(UE_ID mod N)+(T2/M)*(GRP_ID+i)；或者

(SFN+PF_offset2)mod T2＝(T2/N/M)*(UE_ID mod N)+(T2/M/N)*(GRP_ID+i)，

其中，SFN是系统帧号，PF_offset2是寻呼帧的偏移值，T2是所述第二类型的寻呼DCI的预定持续时间，N是T2内寻呼帧的数量，并且GRP_ID是无线终端的组标识符，且i是非负整数。

22.根据权利要求20所述的方法，其中，确定用于所述第三类型的寻呼DCI的寻呼帧基于以下公式中的至少一个：

(SFN+PF_offset3)mod T3＝(T3/N/M)*(UE_ID mod N)+(T3/M)*(GRP_one+i)；或者，

(SFN+PF_offset)mod T3＝(T3/N/M)*(UE_ID mod N)+(T3/M/N)*(GRP_one+i)，

其中，SFN是系统帧号，PF_offset3是寻呼帧的偏移值，T3是所述第三类型的寻呼DCI的预定持续时间，N是T3内寻呼帧的数量，并且GRP_one、i是非负整数。

23.根据权利要求19所述的方法，其中，确定用于所述第一类型的寻呼DCI或所述第二类型的寻呼DCI或所述第三类型的寻呼DCI的寻呼帧内的一个或多个PO中的一个PO的索引是基于：

index＝floor(UE_ID/N)mod Ns+offset，

其中，Ns是寻呼帧内的所述第一类型的寻呼DCI或所述第二类型的寻呼DCI或所述第三类型的寻呼DCI的PO的数量，并且其中offset是整数偏移值。

24.根据权利要求19所述的方法，其中，确定用于所述第二类型的寻呼DCI或所述第三类型的寻呼DCI的寻呼帧内的一个或多个PO中的一个PO的索引是基于：相对于用于所述第一类型的寻呼DCI的寻呼帧内的PO的索引的偏移。

25.根据权利要求20所述的方法，其中，所述无线终端的组标识符由高层信令、系统信息或者由所述无线终端的移动标识符的比特集合来提供。

26.根据权利要求8所述的方法，其中，所述第二类型的寻呼DCI或所述第三类型的寻呼DCI的资源分配在频域或时域中与所述第一类型的寻呼DCI的资源分配复用。

27.根据权利要求8所述的方法，其中，所述第三类型的寻呼DCI的资源分配在频域或时域中与所述第一类型的寻呼DCI的资源分配共享。

28.根据权利要求8所述的方法，其中，所述预定义特征包括所述无线网络临时标识符RNTI。

29.根据权利要求28所述的方法，其中，所述第一类型的寻呼DCI的循环冗余校验CRC比特由P-RNTI加扰，并且所述第二类型的寻呼DCI或所述第三类型的寻呼DCI的CRC比特由不同于P-RNTI的RNTI加扰。

30.根据权利要求28所述的方法，其中，被用于加扰所述第一类型的寻呼DCI消息的CRC比特的RNTI的值是十六进制数FFFE。

31.根据权利要求28所述的方法，其中，被用于加扰所述第二类型的寻呼DCI或所述第三类型的寻呼DCI的CRC比特的RNTI的值不是十六进制数FFFE。

32.根据权利要求8所述的方法，还包括：由所述无线终端报告所述无线终端支持所述第二类型的寻呼DCI或所述第三类型的寻呼DCI。

33.根据权利要求8所述的方法，其中，所述第一类型的寻呼DCI、所述第二类型的寻呼DCI或所述第三类型的寻呼DCI的配置或参数在所述无线终端的辅助信息中被传送。

34.根据权利要求8所述的方法，其中，所述与参考信号的关系包括相对于参考信号的偏移。

35.根据权利要求34所述的方法，其中，所述参考信号是同步信号/PBCH块SSB或信道状态信息参考信号CSI-RS中的至少一个。

36.根据权利要求1至35中任一项所述的无线终端，包括处理器和存储器，其中，所述处理器被配置为从所述存储器读取计算机代码，以实施根据权利要求1至35中任一项所述的方法。

37.一种计算机程序产品，包括其上存储有计算机代码的非暂时性计算机可读程序介质，所述计算机代码在由处理器执行时，致使所述处理器实施根据权利要求1至35中任一项所述的方法。

Images