CN117898001A - 管理用户设备的寻呼 - Google Patents

Abstract

一种无线电接入网络RAN的分布式基站的分布式单元DU，该分布式基站包括DU和集中式单元CU，该分布式基站可以实现一种用于当分布式基站与用户设备UE之间的无线电连接非活动时寻呼UE的方法。该方法包括：从CU接收(1502)用于增强型寻呼的配置；以及使用该配置来寻呼(1504)UE。

Description

管理用户设备的寻呼

技术领域

本公开一般涉及无线通信，并且更具体地，涉及当UE在与用于控制无线电资源的协议相关联的非活动或空闲状态中操作时寻呼用户设备(UE)。

背景技术

出于总体上呈现本公开的背景的目的而提供该背景描述。在该背景技术部分中描述的程度上，目前署名的发明人的工作以及在提交时可能没有资格作为现有技术的描述的各方面，既不明确地也不隐含地被承认为是本公开的现有技术。

在电信***中，无线电协议栈的分组数据汇聚协议(PDCP)子层提供诸如用户乒面数据的传送、加密、完整性保护等服务。例如，针对演进通用陆地无线电接入(EUTRA)无线电接口(参见3GPP规范TS 36.323)和新无线电(NR)(参见3GPP规范TS 38.323)定义的PDCP层提供上行链路方向(从用户设备，也称为用户设备(UE)到基站)以及下行链路方向(从基站到UE)上的协议数据单元(PDU)的排序。此外，PDCP子层提供用于向无线资源控制(RRC)子层信令发送无线承载(SRB)的服务。PDCP子层还向服务数据适配协议(SDAP)子层或协议层(诸如互联网协议(IP)层、以太网协议层和互联网控制消息协议(ICMP)层)提供用于数据无线电承载(DRB)的服务。一般而言，UE和基站可以使用SRB来交换RRC消息以及非接入层(NAS)消息，并且可以使用DRB来在用户平面上传输数据。

RRC子层指定RRC_IDLE状态，其中，UE不具有与基站的活动无线电连接；RRC_CONNECTED状态，其中，UE具有与基站的活动无线电连接；以及RRC_INACTIVE状态，以允许UE由于无线电接入网络(RAN)级基站协调和RAN寻呼过程而更快速地转换回RRC_CONNECTED状态。

在一些场景中，UE可以在与RAN的无线电资源控制连接非活动的状态(例如，RRC_IDLE或RRC_INACTIVE状态)下操作，并且随后转换到连接状态。一般而言，在非活动状态下，UE与无线电接入网络(RAN)之间的无线电连接被暂停。稍后，当UE被触发以发送数据(例如，传出电话呼叫、浏览器启动)或从基站接收到寻呼消息时，UE随后可以转换至连接状态。为了执行转换，UE可以请求基站建立无线电连接(例如，通过向基站发送RRC建立请求消息)或恢复暂停的无线电连接(例如，通过向基站发送RRC恢复请求消息)，使得基站可以将UE配置为在连接状态下操作。

在一些情况下，处于RRC_IDLE或RRC_INACTIVE状态的UE仅具有一个或一些相对较小的分组要发送，或者基站仅具有一个或一些相对较小的分组要发送到在RRC_IDLE或RRC_INACTIVE状态下操作的UE。在这些情况下，处于RRC_IDLE或RRC_INACTIVE状态的UE可以执行早期数据通信而不转换到RRC_CONNECTED状态，例如，通过使用3GPP规范36.300v16.4.0中的第7.3a-7.3d节中指定的技术。

最近，3GPP已经讨论了用于UE功率节省的各种寻呼增强。例如，基站可以在寻呼时机之前发送寻呼早期指示(PEI)。如果支持检测PEI的UE接收到PEI，则UE尝试在后续寻呼时机接收寻呼下行链路控制信息(DCI)。如果UE没有接收到PEI，则UE可以通过不监测后续寻呼时机来节省功率。作为另一示例，核心网络可以为UE配置寻呼子组。支持寻呼子组的UE可以基于寻呼DCI是否指示UE的寻呼子组来确定是否根据寻呼DCI接收寻呼消息。

然而，实现用于UE功率节省的寻呼增强提出了若干挑战。例如，关于寻呼子组，虽然核心网络可以用寻呼子组配置UE，但是不清楚负责寻呼UE的无线电接入网络(RAN)的节点如何获得寻呼子组配置。如果RAN不知道寻呼子组配置，则RAN不能向UE发送寻呼子组指示，并且UE不能利用寻呼子组寻呼增强来节省功率。

关于PEI寻呼增强，因为RAN不保留用于在RRC_IDLE中操作的UE的UE能力，所以RAN不知道在RRC_IDLE状态中操作的UE是否支持PEI。因此，在一些情况下，RAN将避免向UE发送PEI。如果RAN向支持检测PEI的UE发送寻呼DCI，则当UE未检测到PEI(由于RAN不知道UE支持PEI而不发送PEI)时，UE将不尝试接收寻呼DCI。在其它情况下，RAN仍然可以向UE发送PEI，即使RAN不知道UE是否支持PEI。在此类情形中，RAN可能不必要地使用无线电资源来向不支持PEI的UE发送PEI。

发明内容

无线电接入网络(RAN)的网络节点可以使用本公开的技术来管理寻呼。分布式基站的集中式单元(CU)可以从核心网络(CN)或从RAN的另一节点接收用于增强型寻呼的配置。该配置指示UE是否支持增强型寻呼功能，诸如检测寻呼早期指示(PEI)或利用寻呼子组。如果CU确定寻呼UE，则CU向分布式基站的至少一个分布式单元(DU)发送该配置，以指示DU使用该配置来寻呼UE。

基于该配置，DU确定如何寻呼UE。如果DU确定UE支持检测通知UE尝试接收寻呼下行链路控制信息(DCI)(例如，PEI)的信号，则DU通过在发送寻呼DCI之前发送信号来寻呼UE。然后，DU根据DCI向UE发送寻呼消息。

此外，如果DU基于配置确定UE支持寻呼子组，则DU可以在寻呼UE时向UE发送寻呼子组的指示。例如，DU可以在寻呼DCI中包括寻呼子组的标识符(例如，寻呼子组标识(ID)或子组特定的寻呼无线电网络临时标识符(P-RNTI))，或者可以使用该标识符对寻呼DCI的循环冗余校验(CRC)值进行加扰。如果UE支持检测信号和寻呼子组两者，则DU可以组合上述技术，或者可以在信号内发送寻呼子组的指示。

这些技术的一个示例实施例是一种在RAN的DU中实现的方法，该分布式基站包括DU和CU，用于在分布式基站与UE之间的无线电连接非活动时寻呼UE。该方法可以由处理硬件执行，并且包括：从CU接收用于增强型寻呼的配置；以及使用该配置来寻呼UE。

这些技术的另一示例实施例是一种在RAN的分布式基站的CU中实现的方法，该分布式基站包括CU和DU，用于在分布式基站与UE之间的无线电连接非活动时寻呼UE。该方法可以由处理硬件执行，并且包括：接收用于增强型寻呼的配置；确定寻呼UE；以及响应于该确定，向DU发送该配置以指示DU使用该配置来寻呼UE。

这些技术中的又一示例实施例是一种在基站中实现的用于寻呼UE的方法，该基站操作一个或多个小区。该方法可以由处理硬件实现，并且包括：接收UE支持的第一频带列表；生成第二频带列表，第二频带列表包括第一频带列表中的由一个或多个小区支持的频带；以及在一个或多个小区中的支持第二频带列表中的频带的小区上寻呼UE。

这些技术中的另一示例实施例是一种在分布式基站的CU中实现的用于寻呼UE的方法，分布式基站包括CU和DU。该方法可以由处理硬件实现，并且包括：确定寻呼UE；确定UE是处于与用于控制无线电资源的协议相关联的空闲状态还是与协议相关联的非活动状态；基于UE是处于空闲状态还是非活动状态来选择寻呼配置；以及向DU发送寻呼配置。

这些技术的另一示例实施例是RAN的节点，其包括处理硬件并且被配置为实现上述方法中的任何一个。

附图说明

图1A是示例无线通信***的框图，在该***中本公开内容的用户设备和基站可以实现本公开内容的用于管理增强型寻呼的技术；

图1B是包括可以在图1A的***中操作的集中式单元(CU)和分布式单元(DU)的示例基站的框图；

图2A是图1A的UE与基站通信所依据的示例协议栈的框图；

图2B是图1A的UE与CU和DU通信所依据的示例协议栈的框图；

图3A是示例消息序列，其中，CU向DU发送用于增强型寻呼的配置并且当UE在空闲状态下操作时DU使用该配置来寻呼UE；

图3B是示例消息序列，其中，核心网络(CN)向第一基站和第二基站两者发送用于增强型寻呼的配置；

图3C是类似于图3A的消息序列的示例消息序列，但是其中，CU还向第二DU发送用于增强型寻呼的配置；

图4A是类似于图3A的消息序列的示例消息序列，但是其中，当UE在非活动状态下操作时DU寻呼UE；

图4B是类似于图4A的消息序列的示例消息序列，但是其中，DU寻呼UE以执行与UE的早期数据通信；

图4C是CU向DU和第二基站发送用于增强型寻呼的配置的示例消息序列，其中，当UE在非活动状态下操作时第二基站寻呼UE；

图4D是类似于图4A的消息序列的示例消息序列，但是其中，CU还向第二DU发送用于增强型寻呼的配置；

图5是可以由DU实现的用于确定是使用增强型寻呼还是使用传统寻呼来寻呼UE的示例方法的流程图；

图6A-图6B是可以由CU实现的用于分发增强型寻呼的配置的示例方法的流程图；

图7A-图7B是用于向DU发送CU到DU消息以指示DU寻呼UE的示例方法的流程图，其可以分别由CU和CU控制平面节点(CU-CP)实现；

图8-图11是用于确定在其上寻呼UE的子集小区的示例方法的流程图，其可以分别由DU、CU、基站和CN实现；

图12A-图12B是可以由CU实现的用于分发UE寻呼能力的示例方法的流程图；

图13是可以由DU实现的用于确定用于寻呼UE的配置的示例方法的流程图；

图14是可以由CU实现的用于基于UE的无线电资源控制(RRC)状态来选择寻呼配置的流程图；

图15是可以由DU实现的用于寻呼UE的示例方法的流程图；

图16是可以由CU实现的用于寻呼UE的示例方法的流程图；

图17是可以由CU或DU实现的用于选择在其上寻呼UE的小区的示例方法的流程图；以及

图18是可以由CU实现的用于选择用于寻呼UE的寻呼配置的示例方法的流程图。

具体实施方式

首先参考图1A，示例无线通信***100包括UE 102、基站(BS)104、基站106和核心网络(CN)110。基站104和106可以在连接到核心网络(CN)110的无线电接入网络(RAN)105中操作。例如，CN 110可以被实现为演进分组核心(EPC)111或第五代(5G)核心(5GC)160。在另一示例中，CN 110还可以被实现为第六代(6G)核心。

基站104支持小区124，并且基站106支持小区126。小区124和126可以部分重叠，使得UE 102可以从小区124或126中的一个选择、重选或切换到另一个。如果基站104是gNB，则小区124是新无线电(NR)小区。如果基站104是ng-eNB，则小区124是演进通用陆地无线电接入(E-UTRA)小区。类似地，如果基站106是gNB，则小区126是NR小区，并且如果基站106是ng-eNB，则小区126是E-UTRA小区。小区124和126可以在相同的无线电接入网络通知区域(RNA)或不同的RNA中。通常，RAN 105可以包括任何数量的基站，并且每个基站可以覆盖一个、两个、三个或任何其他合适数量的小区。UE 102可以支持至少5G NR(或简称为“NR”)或E-UTRA空中接口以与基站104和106进行通信。基站104、106中的每一个可以经由接口(例如，S1或NG接口)连接到CN 110。基站104和106还可以经由用于互连NG RAN节点的接口(例如，X2或Xn接口)互连。基站104和基站106可以通过X2或Xn接口直接交换消息或信息。通常，CN 110可以连接到支持NR小区和/或EUTRA小区的任何合适数量的基站。

在其他组件中，EPC 111可以包括服务网关(SGW)112、移动性管理实体(MME)114和分组数据网络网关(PGW)116。SGW 112通常被配置为传送与音频呼叫、视频呼叫、互联网业务等相关的用户平面分组，并且MME 114被配置为管理认证、注册、寻呼和其它相关功能。PGW 116提供从UE到一个或多个外部分组数据网络(例如，互联网网络和/或互联网协议(IP)多媒体子***(IMS)网络)的连接。5GC 160包括用户平面功能(UPF)162以及接入和移动性管理(AMF)164和/或会话管理功能(SMF)166。一般而言，UPF 162被配置为传送与音频呼叫、视频呼叫、互联网业务等相关的用户平面分组，AMF 164被配置为管理认证、注册、寻呼和其他相关功能，并且SMF 166被配置为管理PDU会话。

如果当UE与RAN 105之间的无线电连接非活动时(例如，当UE在与用于控制无线电资源的协议相关联的空闲或非活动状态下操作时，诸如RRC_IDLE或RRC_INACTIVE)，CN接收到用于UE 102的下行链路(DL)数据，则CN 110可以确定寻呼UE 102。

在UE在空闲状态(例如，RRC_IDLE或CM-IDLE)下操作的情况下，CN 110确定寻呼UE102以便向UE 102发送DL数据。响应于该确定，CN 110能够与RAN 105执行寻呼操作以寻呼在空闲状态下操作的UE 102。更具体地，CN 110可以向RAN 105发送CN到BS寻呼消息(例如，3GPP规范38.413中定义的NG应用协议(NGAP)寻呼消息或3GPP规范36.413中定义的S1应用协议(S1AP)寻呼消息)以触发RAN 105向UE 102发送UE寻呼消息。CN 110在NGAP寻呼消息中包括UE 102的CN ID。例如，CN ID可以是S-TMSI或NG-5G-S-TMSI。响应于CN到BS寻呼消息，RAN 105的基站104生成包括CN ID的UE寻呼消息(例如，3GPP规范38.331中定义的RRC寻呼消息)，并且经由小区124发送UE寻呼消息以寻呼UE 102。在基站104具有附加小区的情况下，基站104还可以经由附加小区发送UE寻呼消息以寻呼UE 102。响应于或在例如经由小区124从基站104接收到UE寻呼消息之后，处于空闲状态的UE 102可以执行与基站104的RRC连接建立过程以建立与基站104的RRC连接(即，SRB1和/或SRB2)，并且经由基站104和RRC连接(即，SRB1或SRB2)向CN 110发送服务请求消息。在接收到服务请求消息之后，CN 110可以向基站104发送CN到BS消息(例如，PDU会话资源建立请求消息或初始上下文建立请求消息)以请求基站104为UE 102分配资源以接收DL数据。CN 110可以在CN到BS消息中包括UE 102的PDU会话ID和/或服务质量(QoS)流ID，以请求基站104分别为由PDU会话ID和/或QoS流ID标识的PDU会话和/或QoS流分配资源。响应于接收到CN到BS消息或在接收到CN到BS消息之后，基站104激活对UE 102的安全保护，并为PDU会话和/或QoS流建立DRB。基站104可以向UE102发送安全模式命令消息以激活安全保护，并且作为响应，UE 102可以向基站104发送安全模式完成消息。基站104可以向UE 102发送配置用于PDU会话和/或QoS流的DRB的RRC重新配置消息，并且作为响应，UE 102可以向基站104发送RRC重新配置完成消息。

在UE 102在非活动状态(例如，RRC_INACTIVE状态)下操作的情况下，CN 110例如经由NG-U连接或接口向RAN 105发送DL数据，而不向基站104发送用于UE 102的CN到BS寻呼消息(例如，3GPP规范38.413中定义的NGAP寻呼消息或3GPP规范36.413中定义的S1AP寻呼消息)。在接收到DL数据之后或响应于接收到DL数据，基站104生成包括UE 102的RAN ID的UE寻呼消息(例如，3GPP规范38.331中定义的RRC寻呼消息)，并经由小区124发送UE寻呼消息以寻呼UE 102。在基站104具有附加小区的情况下，基站104还可以经由附加小区发送UE寻呼消息以寻呼UE 102。例如，RAN ID可以是非活动无线电网络临时标识符(I-RNTI)或恢复ID。在一些场景和实施方式中，基站104可以向基站106发送包括RAN ID的BS到BS寻呼消息(例如，3GPP规范38.423中定义的Xn寻呼消息或3GPP规范36.423中定义的X2寻呼消息)以触发基站106寻呼UE 102。响应于或根据BS到BS寻呼消息，基站106生成包括RAN ID的UE寻呼消息，并经由小区126发送UE寻呼消息。在基站106具有附加小区的情况下，基站106还可以经由附加小区发送UE寻呼消息以寻呼UE 102。响应于或在从基站104接收到UE寻呼之后，UE 102可以与基站104执行RRC连接恢复过程，以从非活动状态转换到连接状态(例如，RRC_CONNECTED状态)。如果RAN 105使得UE 102能够进行早期数据通信(或称为小数据传输)并且UE寻呼消息指示UE 102将执行早期数据通信(例如，移动终止早期数据传输(EDT))，则处于非活动状态的UE 102在没有状态转换的情况下执行与基站104的早期数据通信。在早期数据通信期间，UE 102可以响应于UE寻呼消息向基站104发送包括完整性消息认证码(MAC-I)的UL RRC消息(例如，RRC恢复请求消息)。在UL RRC消息中，UE 102可以包括指示UE正在执行早期数据通信的指示或原因值，以便防止基站104将UE 102转换到连接状态。在接收到UL RRC消息之后，基站104可以向在非活动状态下操作的UE 102发送DL数据。

基站104配备具有处理硬件130，处理硬件130可以包括一个或多个通用处理器(例如，CPU)和存储一个或多个通用处理器执行的指令的非暂时性计算机可读存储器。附加地或可替代地，处理硬件130可以包括专用处理单元。在示例实施方式中，处理硬件130包括介质访问控制(MAC)控制器132，其被配置为执行与一个或多个用户设备的随机接入过程，接收到一个或多个用户设备的上行链路MAC协议数据单元(PDU)，以及向一个或多个用户设备发送下行链路MAC PDU。处理硬件130还可以包括分组数据汇聚协议(PDCP)控制器134，其被配置为在一些场景中发送PDCP PDU，基站104可以根据PDCP PDU在下行链路方向上发送数据，并且在其他场景中接收PDCP PDU，基站104可以根据PDCP PDU在上行链路方向上接收数据。处理硬件还可以包括RRC控制器136，以在协议通信栈的RRC子层处实现过程和消息传送。示例实施方式中的处理硬件130包括寻呼控制器138，其被配置为管理与在RRC_INACTIVE或RRC_IDLE状态下操作的一个或多个UE的寻呼操作。基站106可以包括处理硬件140，处理硬件140包括通常类似于处理硬件130的组件的组件。特别地，组件140、142、144、146和148可以分别类似于组件130、132、134、136和138。

UE 102配备具有处理硬件150，处理硬件150可以包括一个或多个通用处理器(诸如CPU)和存储可在一个或多个通用处理器和/或专用处理单元上执行的机器可读指令的非暂时性计算机可读存储器。示例实施方式中的处理硬件150包括寻呼控制器158，该寻呼控制器158被配置为当UE 102在RRC_IDLE或RRC_INACTIVE状态下操作时管理寻呼操作。示例实施方式中的处理硬件150包括介质访问控制(MAC)控制器132，其被配置为利用基站执行随机接入过程，向基站发送上行链路MAC协议数据单元(PDU)，以及从基站接收下行链路MACPDU。处理硬件150还可以包括PDCP控制器154，其被配置为在一些场景中发送PDCP PDU，UE102可以根据该PDCP PDU在上行链路方向上发送数据，并且在其他场景中接收PDCP PDU，UE102可以根据该PDCP PDU在下行链路方向上接收数据。处理硬件还可以包括RRC控制器156以在协议通信栈的RRC子层处实现过程和消息传送。

图1B描绘了基站104、106中的任何一个或多个基站的示例分布式或分解式实施方式。在该实施方式中，基站104或106包括集中式单元(CU)172和一个或多个分布式单元(DU)174。CU 172包括处理硬件，诸如一个或多个通用处理器(例如，CPU)和存储可在通用处理器和/或专用处理单元上执行的机器可读指令的计算机可读存储器。例如，CU 172可以包括PDCP控制器、RRC控制器和/或寻呼控制器，诸如PDCP控制器134、144、RRC控制器136、146和/或寻呼控制器138、148。在一些实施方式中，CU 172可以包括无线链路控制(RLC)控制器，其被配置为管理或控制一个或多个RLC操作或过程。在其他实施方式中，CU 172不包括RLC控制器。

DU 174中的每一个还包括处理硬件，该处理硬件可包括一个或多个通用处理器(例如，CPU)和存储可在该一个或多个通用处理器上执行的机器可读指令的计算机可读存储器和/或专用处理单元。例如，处理硬件可以包括被配置为管理或控制一个或多个MAC操作或过程(例如，随机接入过程)的MAC控制器(例如，MAC控制器132、142)，和/或被配置为管理或控制一个或多个RLC操作或过程的RLC控制器。处理硬件还可以包括被配置为管理或控制一个或多个物理层操作或过程的物理层控制器。

在一些实施方式中，CU 172可以包括托管(host)CU 172的PDCP协议的控制平面部分的逻辑节点CU-CP 172A。CU 172还可以包括托管CU 172的PDCP协议和/或服务数据适配协议(SDAP)协议的用户平面部分的逻辑节点CU-UP 172B。CU-CP 172A可以发送控制信息(例如，RRC消息、F1应用协议消息)，并且CU-UP 172B可以发送数据分组(例如，SDAP PDU或互联网协议分组)。

CU-CP 172A可以通过E1接口连接到多个CU-UP 172B。CU-CP 172A为UE 102的所请求服务选择适当的CU-UP 172B。在一些实施方式中，单个CU-UP 172B可以通过E1接口连接到多个CU-CP 172A。如果CU-CP和DU属于gNB，则CU-CP 172A可以通过F1-C接口和/或F1-U接口连接到一个或多个DU 174。如果CU-CP和DU属于ng-eNB，则CU-CP 172A可以通过W1-C接口和/或W1-U接口连接到一个或多个DU 174。在一些实施方式中，一个DU 174可以在同一CU-CP 172A的控制下连接到多个CU-UP 172B。在这样的实施方式中，CU-UP 172B和DU 174之间的连接是由CU-CP 172A使用承载上下文管理功能来建立的。

图2A以简化的方式示出了示例协议栈200，根据该协议栈，UE 102可以与eNB/ng-eNB或gNB(例如，基站104、106中的一个或多个)进行通信。

在示例栈200中，EUTRA的物理层(PHY)202A向EUTRA MAC子层204A提供传输信道，EUTRA MAC子层204A进而向EUTRA RLC子层206A提供逻辑信道。EUTRA RLC子层206A进而向EUTRA PDCP子层208提供RLC信道，并且在一些情况下，向NR PDCP子层210提供RLC信道。类似地，NR PHY 202B向NR MAC子层204B提供传输信道，NR MAC子层204B进而向NR RLC子层206B提供逻辑信道。NR RLC子层206B进而向NR PDCP子层210提供数据传送服务。NR PDCP子层210进而可以向服务数据适配协议(SDAP)212或无线电资源控制(RRC)子层(图2A中未示出)提供数据传送服务。在一些实施方式中，UE 102支持如图2A所示的EUTRA和NR栈两者，以支持EUTRA和NR基站之间的切换和/或支持EUTRA和NR接口上的DC。此外，如图2A所示，UE102可以支持NR PDCP 210在EUTRA RLC 206A上的分层，以及SDAP子层212在NR PDCP子层210上的分层。

EUTRA PDCP子层208和NR PDCP子层210接收可以被称为服务数据单元的分组(例如，从在PDCP层208或210上直接或间接分层的互联网协议(IP)层)，并且输出可以被称为协议数据单元的分组(例如，向RLC层206A或206B)。除了SDU和PDU之间的差异相关的情况之外，为了简单起见，本公开将SDU和PDU都称为“分组”。

在控制平面上，EUTRA PDCP子层208和NR PDCP子层210可以提供信令无线承载或RRC子层(图2A中未示出)以交换例如RRC消息或非接入层(NAS)消息。在用户平面上，EUTRAPDCP子层208和NR PDCP子层210可以提供数据无线承载(DRB)以支持数据交换。在NR PDCP子层210上交换的数据可以是SDAP PDU、互联网协议(IP)分组或以太网分组。

因此，可以在功能上拆分无线电协议栈，如图2B中的无线电协议栈250所示。基站104或106中的任何基站处的CU 172可以保持所有控制和上层功能(例如，RRC 214、SDAP212、NR PDCP 210)，而下层操作(例如，NR RLC 206B、NR MAC 204B和NR PHY 202B)被委托给DU 174。为了支持到5GC的连接，NR PDCP 210向RRC 214提供SRB，并且NR PDCP 210向SDAP 212提供DRB并向RRC 214提供SRB。

图3A-图4D是示例场景的消息序列，其中，CU向DU发送寻呼增强配置以使得DU能够使用寻呼增强配置来寻呼UE。一般而言，图3A至图3C和图4A至图4D中类似的事件用类似的附图标记来标记(例如，图3A中的事件394类似于图3B至图3C中的事件394和图4A至图4D中的事件494)，其中在适当的情况下在下面讨论差异。除了附图中所示和下面讨论的差异之外，关于特定事件(例如，用于消息传递和处理)讨论的任何替代实施方式可以应用于在其他附图中用类似附图标记标记的事件。

首先参考图3A，在场景300A中，UE 102最初在与包括CU 172和DU 174的基站104的连接状态(例如，RRC_CONNECTED)下操作302。当UE 102在连接状态下操作时，UE 102向DU174发送304包括能力和/或辅助信息的上行链路(UL)NAS消息。继而，DU 174向CU 172发送306包括UL NAS消息的DU到CU消息。接着，CU 172将包含UL NAS消息的BS到CN消息发送308到CN 110(例如，AMF 164或MME 114)。在一些实施方式中，UE 102可以在能力和/或辅助信息中指示对寻呼增强配置的支持。在CN 110在UL NAS消息中接收到能力和/或辅助信息之后，CN 110可以响应于或根据能力和/或辅助信息中的寻呼增强配置的支持指示来确定生成寻呼增强配置。如果UE 102不指示对寻呼增强的任何支持，则CN 110不为UE 102创建寻呼增强配置。寻呼增强配置(在本公开中也称为用于增强型寻呼的配置)使得UE 102能够使用对应的寻呼增强功能来管理寻呼接收。响应于该确定，CN 110生成包括寻呼增强配置的DL NAS消息，并且向CU 172发送310包括DL NAS消息的第一CN到BS消息。反过来，CU 172向DU 174发送312包括DL NAS消息的第一CU到DU消息。然后，DU 174向UE 102发送314DL NAS消息。

在如图所示的一些实施方式中，CN 110可以根据或响应于能力和/或辅助信息来生成、确定或选择寻呼增强配置。在未示出的其它实施方式中，CN 110可以从CU 172获得寻呼增强配置。例如，在接收到能力和/或辅助信息之后，CN 110可以向CU 172发送附加的CN到BS消息以请求CU 172提供寻呼增强配置，并且作为响应，CU 172向CN 110发送包括寻呼增强配置的附加的BS到CN消息。

在UE 102的数据非活动的特定时段之后，CU 172可以确定CU 172和UE 102在该特定时段期间都没有分别在下行链路方向或上行链路方向上发送任何数据。在一些实施方式中，DU 174可以向CU 172发送(未示出)指示UE 102的数据非活动的DU到CU消息，以辅助确定。响应于该确定，CU 172向DU 174发送316包括RRC释放消息的第二CU到DU消息，DU 174进而向UE 102发送318RRC释放消息。UE 102响应于接收到RRC释放消息而转换320到空闲状态(例如，RRC_IDLE状态)，并且在空闲状态下操作。

在一些实施方式中，UL NAS消息和DL NAS消息可以是5G移动性管理(MM)消息或5G会话管理(SM)消息(例如，如3GPP规范24.501中所描述的)。例如，UL NAS消息可以是注册请求消息或注册完成消息。在另一示例中，DL NAS消息可以是注册接受消息或配置更新命令消息。在一些实施方式中，DU到CU消息、第一CU到DU消息和第二CU到DU消息是F1应用协议(F1AP)或W1应用协议(W1AP)消息(例如，如3GPP规范38.473或37.473中所描述的)。例如，DU到CU消息、第一CU到DU消息和第二CU到DU消息可以分别是UL RRC消息传送消息、DL RRC消息传送消息和UE上下文释放命令消息。在一些实施方式中，BS到CN消息和第一CN到BS消息是NG应用协议(NGAP)消息。例如，BS到CN消息是初始UE消息消息或上行链路NAS传输消息。在另一示例中，第一CN到BS消息是初始上下文建立请求消息或下行链路NAS传输消息。

事件304、306、308、310、312、314、316、318和320在图3A中统称为NAS寻呼增强启用过程392。

在稍后的时间，CN 110确定寻呼UE 102(例如，用于移动终止呼叫)或者向UE 102发送DL数据。响应于该确定，CN 110向CU 172发送322包括寻呼增强配置的第二CN到BS消息。在第二CN到BS消息中，在一些实施方式中，CN 110可以包括UE 102的NAS ID、UE 102用于寻呼的一个或多个能力和/或用于UE 102的寻呼辅助信息。在一些实施方式中，NAS ID可以是S-TMSI或5G-S-TMSI。在一个实施方式中，CN 110在DL NAS消息310中包括NAS ID。在另一实施方式中，在发送第二CN到BS消息之前，CN 110经由CU 172和DU 174向UE 102发送包括NAS ID的第二DL NAS消息，类似于事件310、312和314。

在一些实施方式中，用于寻呼的一个或多个能力被包括在UE寻呼能力IE(例如，UERadioPagingInformation IE)中，并且CN 110将UE寻呼能力IE包括在第二CN到BS消息中。在一些实施方式中，一个或多个能力被包括在UE 102的UE完全能力IE(例如，UE-NR-Capability IE)中。除了UE寻呼能力IE中的一个或多个能力之外，UE完全能力IE还包括其他能力。在一些实施方式中，CN 110可以从RAN 105(例如，CU 172或另一CU或基站)接收UE寻呼能力IE和/或UE完全能力IE。在其他实施方式中，CN 110可以预存储UE完全能力IE。在这样的实施方式中，CN 110可以预存储UE寻呼能力IE或者从UE完全能力IE动态地生成UE寻呼能力IE。在一些实施方式中，CN 110可以将能力ID与UE完全能力IE和/或UE寻呼能力相关联。

在一些实施方式中，一个或多个能力包括用于寻呼的频带列表(例如，supportedBandListNRForPaging字段)，其包括UE 102支持的频带。在一些实施方式中，UE完全能力IE包括全频带列表(例如，supportedBandListNR字段)，其包括UE 102支持的全频带。RAN 105或CN 110可以从全频带列表生成用于寻呼的频带列表。在一些实施方式中，RAN105或CN 110可以在频带列表中包括用于寻呼的全频带的子集。例如，RAN 105或CN 110可以从全频带中选择RAN 105支持的频带。在其他实施方式中，RAN 105或CN 110可以将全频带包括在频带列表中以用于寻呼。

在其他实施方式中，一个或多个能力包括一个或多个下行链路调度时隙偏移能力(例如，dl-SchedulingOffset-PDSCH-TypeA-FDD-FR1-r15、dl-SchedulingOffset-PDSCH-TypeA-TDD-FR1-r15、dl-SchedulingOffset-PDSCH-TypeB-FDD-FR1-r15和/或dl-SchedulingOffset-PDSCH-TypeB-FDD-FR1-r15)以指示UE 102支持跨时隙调度。在其他实施方式中，一个或多个能力包括单个能力字段/IE以指示当UE 102在空闲状态(例如，RRC_IDLE)和/或非活动状态(例如，RRC_INACTIVE)中操作时对PEI信号的支持。可替代地，一个或多个能力包括第一能力字段/IE和第二能力字段/IE，以分别指示当UE 102在空闲状态下操作时对PEI信号的支持和当UE 102在非活动状态下操作时对PEI信号的支持。

在一些实施方式中，寻呼辅助信息包括寻呼不连续接收(DRX)配置、寻呼优先级、寻呼起点和/或用于寻呼的跟踪区域标识(TAI)列表。寻呼DRX信息可以包括寻呼DRX周期值。在一些实施方式中，寻呼DRX周期值可以是32、64、128或256个无线电帧。在其它实施方式中，寻呼DRX周期值可以是512或1024个无线电帧。寻呼DRX配置可以是寻呼不连续接收(DRX)信息(例如，寻呼DRX IE)或寻呼扩展DRX(eDRX)信息(例如，寻呼eDRX信息IE)。寻呼eDRX信息可以包括寻呼eDRX周期值(例如，0.5、1、2、4、6、8、10、12、14、16、32、64、128、256个超高帧)和/或寻呼时间窗口值。

在一些实施方式中，第二CN到BS消息可以是3GPP规范38.413中描述的NGAP寻呼消息。在一些实施方式中，CN 110在DL NAS消息310或第二DL NAS消息中包括寻呼DRX信息或寻呼eDRX信息。

响应于接收到第二CN到BS消息或在接收到第二CN到BS消息之后，CU 172从第二CN到BS消息中检索寻呼增强配置，并且向DU 174发送324包括寻呼增强配置的第三CU到DU消息。在一些实施方式中，CU 172可以从第二CN到BS消息中取回NAS ID，并且将NAS ID包括在第三CU到DU消息中。在一些实施方式中，CU 172可以从第二CN到BS消息中取回寻呼起点，并且将寻呼起点包括在第三CU到DU消息中。

在一些实施方式中，CU 172可以将检索到的寻呼增强配置直接包括在第三CU到DU消息中，而不将检索到的寻呼增强配置解码为某种类型的数据，然后将数据编码为寻呼增强配置作为第三CU到DU消息的IE。这样的实施方式的优点在于，CU 172不需要处理或理解寻呼增强配置，即，CU 172对于寻呼增强配置是透明的。在一些实施方式中，寻呼增强配置可以是RRC信息元素(IE)。在一些实施方式中，第三CU到DU消息可以是3GPP规范38.473中描述的F1AP寻呼消息。在其它实施方式中，第三CU到DU消息可以是在37.473中描述的W1AP寻呼消息。

在其它实施方式中，CU 172将检索到的寻呼增强配置(即，第二CN到BS消息的IE)解码为某种类型的数据，然后将数据编码为寻呼增强配置作为第三CU到DU消息的IE。这样的实施方式的优点在于，CU 172可以基于DU 174和/或CU 172的条件或实施方式来确定是增强还是调整检索到的寻呼增强配置的配置参数。例如，由于DU 174可能不支持检索到的寻呼增强配置中的特定配置参数，因此CU 172可以确定从第三CU到DU消息的寻呼增强配置中排除该特定配置参数。在另一个示例中，由于DU 174可能不支持检索到的寻呼增强配置中的配置参数的特定值，因此CU 172可以将该特定值改变为DU 174支持的另一个值。在一些实施方式中，检索到的寻呼增强配置是NGAP IE，并且第三CU到DU消息的寻呼增强配置是F1AP IE或W1AP IE。

在一些实施方式中，如果第二CN到BS消息包括用于寻呼的一个或多个能力，则CU172可以在第三CU到DU寻呼消息中包括用于寻呼的一个或多个能力。例如，第二CN到BS消息可以包括UE寻呼能力IE，并且CU 172可以在第三CU到DU消息中包括UE寻呼能力IE。在其他实施方式中，第二CN到BS消息可以在第二CN到BS消息的IE中包括用于UE 102的寻呼辅助信息。例如，如果第二CN到BS消息是NGAP消息，则IE可以是NGAP IE。在这样的实施方式中，CU172从第二CN到BS消息的IE中检索寻呼辅助信息，并且将寻呼辅助信息(的一部分)包括在第三CU到DU消息的IE中。在一些实施方式中，CU 172可以修改寻呼辅助信息(的一部分)，并且将修改的寻呼辅助信息(的一部分)包括在第三CU到DU消息中。在一些场景和实施方式中，第二CN到BS消息中的寻呼辅助信息包括寻呼DRX信息，该寻呼DRX信息包括寻呼DRX周期值：512或1024个无线电帧。当CU 172和DU 174中的一个不支持512或1024个无线电帧时，CU172可以将第三CU到DU消息中的寻呼DRX周期值设置为32、64、128或256个无线电帧，而不是512或1024个无线电帧。在一些实施方式中，CU 172或DU 174不支持512或1024个无线电帧，因为第三CU到DU消息的寻呼辅助信息IE不支持具有512或1024个无线电帧的寻呼DRX周期值。在其它实施方式中，扩展寻呼DRX周期值(即，512和1024个无线电帧)可以被包括在第三CU到DU消息的寻呼辅助信息IE的新格式中。如果CU 172和DU 174支持新格式(即，支持具有512或1024个无线电帧的寻呼DRX周期)，则CU 172可以在第三CU到DU消息中将寻呼DRX周期设置为512或1024个无线电帧。如果CU 172支持新格式但DU 174不支持新格式，则CU 172可以将第三CU到DU消息中的寻呼DRX周期值设置为32、64、128或256个无线电帧，而不是512或1024个无线电帧。

响应于接收到第三CU到DU消息或在接收到第三CU到DU消息之后，DU 174生成用于寻呼UE 102的寻呼消息(例如，3GPP规范38.331中定义的RRC寻呼消息)，并且根据或考虑第三CU到DU消息中的寻呼增强配置、用于寻呼的一个或多个能力和寻呼辅助信息来配置326寻呼UE 102。配置寻呼UE 102包括鉴于寻呼增强配置来确定如何寻呼UE 102(例如，确定是否在发送调度寻呼消息的寻呼DCI之前发送PEI，确定是否在寻呼UE 102时向UE 102发送寻呼子组的指示，生成寻呼DCI等)。

为了配置寻呼UE 102，DU 174生成寻呼DCI，该寻呼DCI调度和分配用于在DU 174的小区(例如，小区124)上传输寻呼消息的无线电资源。如果CU 172在第三CU到DU消息324中包括寻呼小区列表，则DU 174调度和分配用于在寻呼小区列表中的小区上传输寻呼消息的无线电资源。根据事件326处的确定，DU 174通过小区发送327寻呼DCI和328寻呼消息以寻呼UE 102。在一些实施方式中，事件326处的DU 174可以例如根据3GPP规范38.304在寻呼时机上配置寻呼DCI的传输。在一些实施方式中，DU 174根据寻呼DRX信息或寻呼eDRX信息来确定寻呼DRX周期的开启持续时间中的寻呼时机。UE 102尝试在寻呼时机接收寻呼DCI，例如，根据3GPP规范38.304。在一些实施方式中，UE 102根据寻呼DRX信息或寻呼eDRX信息来确定寻呼(e)DRX周期的开启持续时间中的寻呼时机。在一些实施方式中，DU 174在事件326处可以确定在相同或不同的无线电资源上多次发送寻呼消息。在这样的实施方式中，DU174针对寻呼消息的每个传输来发送寻呼DCI。用于每个传输的寻呼DCI可以相同或不同。

在一些实施方式中，UE 102可以在UE能力和/或辅助信息中指示对寻呼子组的支持。作为一个示例，UE 102可以使用UE能力和/或辅助信息中的子组特定寻呼无线电网络临时标识符(P-RNTI)来指示对寻呼子组的支持。如果UE 102支持寻呼子组，则事件314、324处的寻呼增强配置包括由CN 110分配给UE 102的寻呼子组的指示。例如，寻呼增强配置可以包括将UE 102配置为寻呼子组的寻呼子组配置(例如，寻呼增强配置可以包括寻呼子组标识(ID)，或者可以包括或指示子组特定P-RNTI)。

如果寻呼增强配置指示UE 102支持寻呼子组，则DU 174可以在事件326处确定在寻呼UE 102时向UE 102发送寻呼子组的指示。例如，DU 174可以在寻呼DCI中指示寻呼子组。在一些实施方式中，DU 174在寻呼DCI中包括寻呼子组ID。在其它实施方式中，DU 174将字段设置为对应于寻呼子组的值。如果寻呼DCI指示寻呼子组，则UE 102尝试根据寻呼DCI接收寻呼消息。如果寻呼DCI不指示寻呼子组，则UE 102丢弃或忽略寻呼DCI，或者避免尝试根据寻呼DCI接收寻呼消息。

在其他实施方式中，DU 174可以通过利用子组特定P-RNTI对寻呼DCI的CRC进行加扰来指示寻呼子组，并且在PDCCH上发送寻呼DCI和加扰的CRC，例如，在事件327处。如果UE102在PDCCH上接收到寻呼DCI和加扰的CRC并且基于加扰的CRC和子组特定P-RNTI将寻呼DCI识别为旨在用于UE 102，则UE 102尝试接收寻呼消息。如果UE 102在PDCCH上接收到寻呼DCI和加扰的CRC，并且基于加扰的CRC和子组特定P-RNTI将寻呼DCI识别为不旨在用于UE102，则UE 102丢弃或忽略寻呼DCI或避免根据寻呼DCI接收寻呼消息。UE 102可以从寻呼增强配置获得或导出子组特定P-RNTI。

在一些实施方式中，UE 102可以指示UE 102是否支持在UE能力和/或辅助信息中检测寻呼早期指示(PEI)信号。如果UE 102支持检测PEI信号，则寻呼增强配置包括PEI配置，该PEI配置将UE 102配置为在接收到寻呼DCI和/或寻呼消息之前接收或检测PEI信号。如果UE 102接收或检测到PEI信号，则UE 102尝试接收寻呼DCI。在一些实施方式中，PEI信号可以是用于寻呼的唤醒信号(WUS)。因此，如果UE 102支持检测PEI，则DU 174在事件326处确定在发送327寻呼DCI之前发送PEI信号。

在一些实施方式中，寻呼增强配置指示UE 102支持寻呼子组和检测PEI信号两者。例如，UE 102可以指示UE 102支持寻呼子组以及检测UE能力和/或辅助信息中的PEI信号。附加地或可替代地，UE 102可以具体地指示支持使用UE能力和/或辅助信息中的PEI信号来识别寻呼子组。如果UE 102支持寻呼子组和检测PEI信号两者，则DU 174可以在事件326处确定在PEI信号中指示寻呼子组。例如，DU 174可以生成包括特定序列的PEI信号以指示寻呼子组。如果UE 102接收或检测到PEI信号，则UE 102尝试接收寻呼DCI。如果UE 102接收到或检测到包括另一序列的PEI信号，或者没有接收到或检测到包括用于寻呼子组的特定序列的PEI信号，则UE 102不尝试在UE 102的寻呼时机接收寻呼DCI。

在CU 172除了DU 174之外还操作其它DU的情况下，CU 172可以向其它DU中的每一个发送类似于第三CU到DU消息的CU到DU消息。参见图3C。类似地，CU 172可以在每个CU到DU寻呼消息中包括特定的寻呼小区列表。响应于CU到DU消息，特定的DU生成用于寻呼UE 102的寻呼DCI和寻呼消息(例如，3GPP规范38.331中定义的RRC寻呼消息)，并且类似于事件326配置寻呼DCI和寻呼消息的传输。在一些实施方式中，CU 172可以从寻呼辅助信息或第二CN到BS消息的IE中检索用于寻呼的TAI列表或RNA，并且确定请求DU 174和/或其他DU根据TAI列表或RNA来寻呼UE 102。也就是说，DU 174和/或其它DU属于由TAI列表或RNA标识的一个或多个寻呼区域。此外，DU 174可以控制多于一个小区。在这样的情况下，DU 174可以在多个小区上寻呼UE。

事件324、326和328在图3A中统称为增强型寻呼过程394。

当UE 102经由小区124接收328寻呼消息时，UE 102识别(例如，证实或验证)NASID寻址UE 102。响应于该识别，UE 102可以发起寻呼响应过程(例如，服务请求过程)以响应寻呼消息。响应于该发起，UE 102经由DU 174和小区124执行330与CU 172的RRC连接建立过程。为了执行RRC连接建立过程，UE 102可以经由DU 174向CU 172发送RRC请求消息(例如，RRCConnectionRequest或RRCSetupRequest消息)。作为响应，CU 172可以经由DU 174向UE102发送RRC响应消息(例如，RRCConnectionSetup或RRCSetup消息)。UE 102可以经由DU174向CU 172发送RRC完成消息(例如，RRCConnectionSetupComplete或RRCSetupComplete消息)。UE 102响应于RRC响应消息而转换372到连接状态(例如，RRC_CONNECTED状态)。UE102可以响应于寻呼消息经由DU 174和CU 172向CN 110发送服务请求消息。在UE 102转换到连接状态之后，CU 172可以经由DU 174与UE 102执行332安全模式过程，以激活用于UE102和CU 172之间的数据通信的安全性(例如，完整性保护和/或加密)。在激活安全性之后，CU 172可以经由DU 174与UE 102执行334至少一个RRC重配置过程，以配置信令无线电承载(SRB)和/或数据无线电承载(DRB)。然后，UE 102经由CU 172和DU 174与CN 110通信(例如，发送和/或接收)336数据。数据可以包括用户平面数据分组(例如，IP分组)和/或控制平面消息(例如，NAS消息)。在一些实施方式中，UE 102可以经由DU 174在DRB上与CU 172通信336用户平面数据分组，其中，CU 172与CN 110通信用户平面数据分组。在其它实施方式中，UE 102可以经由DU 174在SRB上与CU 172通信336控制平面消息，其中，CU 172与CN 110通信控制平面消息。

接下来转到图3B，场景300B通常类似于场景300A，除了CN 110还向基站106发送寻呼增强配置以进一步扩展增强型寻呼过程的范围。在CN 110经由基站106的CU 172A和DU174A与UE 102执行392NAS寻呼增强启用过程之后，CN 110确定寻呼在空闲状态下操作的UE102。CN 110向CU 172A发送338包括寻呼增强配置的CN到BS消息，类似于事件322。然后，CU172A在CU到DU消息中向DU 174A发送340寻呼增强配置，类似于事件324。DU 174A使用寻呼增强配置来确定342如何寻呼UE 102，类似于事件326。

与图3A中所示的成功的增强型寻呼过程394相反，当DU 174A发送343寻呼DCI和/或发送344寻呼消息时，寻呼DCI和/或寻呼消息不会到达UE 102。例如，在转换到空闲状态之后，UE 102可能已经从由基站106服务的小区126移动到由基站104服务的小区124。结果，基站106没有成功地寻呼UE 102。然而，CN 110可以向其它基站发送包括用于UE 102的寻呼增强配置的CN到BS消息。例如，CN 110可以向UE 102的寻呼区域内的基站发送这种CN到BS消息，其中，寻呼区域可以基于用于UE 102的RNA或TAI列表。因此，CN 110还向基站104的CU172B发送322CN到BS消息，以在附加的分布式基站处发起增强型寻呼过程394。CU 172B经由基站104的DU 174B与UE 102执行394增强型寻呼过程，以成功地寻呼UE 102。在一些实施方式中，代替从CN 110接收322增强型寻呼配置，CU 172B可以从CU 172A接收增强型寻呼配置(例如，经由BS到BS消息)。CU 172A可以基于UE 102的寻呼区域来确定向CU 172B发送增强型寻呼配置。

转到图3C，场景300C最初类似于场景300B。然而，基站104包括CU 172和两个DU，DU174A和DU 174B。最初，CN 110通过向CU 172发送338包括寻呼增强配置的CN到BS消息来发起寻呼UE 102。CU 172尝试经由DU 174B来寻呼UE 102，类似于图3B，其中，基站106的CU172A尝试经由基站106的DU 174A来寻呼UE 102。DU 174B发送344的寻呼消息没有到达UE102。然而，经由增强型寻呼过程394，CU 172还在CU到DU消息中向DU 174A发送寻呼增强配置，并且DU 174A成功地寻呼UE 102。CU 172可以基于UE 102的寻呼区域来向多个DU发送寻呼增强配置。

图3A-图3C示出了当UE在空闲状态下操作时基站寻呼UE的场景。相反，图4A-图4D示出了当UE在非活动状态下操作时基站寻呼UE的场景。

首先转到图4A，在场景400A中，UE 102最初在与包括CU 172和DU 174的基站104的连接状态(例如，RRC_CONNECTED)下操作402。当UE 102在连接状态下操作时，UE 102经由CU172和DU 174与CN 110通信403数据。当与CN 110通信403时，UE 102可以向CN 110发送能力和/或辅助信息(例如，经由CU 172和DU 174，类似于NAS寻呼增强启用过程392期间的事件304、306和308)。基于能力和/或辅助信息，CN 110可以生成寻呼增强配置。CN 110可以向UE102发送寻呼增强配置(例如，经由CU 172和DU 174，类似于NAS寻呼增强启用过程392期间的事件310、312和314)。此外，在生成寻呼增强配置之后，CN 110可以向CU 172发送415包括寻呼增强配置的CN到BS消息。在一些实施方式中，CN到BS消息可以是初始上下文建立请求消息、切换请求消息、路径切换请求确认消息或UE上下文修改请求消息。

在UE 102的数据非活动的特定时段之后，CU 172可以确定CU 172和UE 102在该特定时段期间都没有分别在下行链路方向或上行链路方向上发送任何数据。响应于该确定，CU 172向DU 174发送416包括RRC释放消息的CU到DU消息，DU 174进而向UE 102发送418RRC释放消息。响应于RRC释放消息，UE 102转换421到非活动状态(例如，RRC_INACTIVE)并在非活动状态下操作。

稍后，CN 110检测用于UE 102的DL数据。作为响应，CN 110向CU 172发送423DL数据。响应于接收到423DL数据，CU 172在CU到DU消息中向DU 174发送寻呼增强配置，以使得DU 174寻呼UE 102。类似于事件326，DU 174基于寻呼增强配置来配置426寻呼UE 102。为了配置426寻呼UE 102，DU 174基于寻呼增强配置来确定如何寻呼UE 102。然后，DU 174根据事件426处的确定来寻呼UE 102。更具体地，DU 174向调度寻呼消息的UE 102发送427寻呼DCI，并且向UE 102发送428寻呼消息。例如，基于事件426处的确定，DU 174可以确定是否在发送427寻呼DCI之前发送PEI和/或是否在寻呼UE 102时向UE 102指示寻呼子组。事件424、426、427和428在本公开中统称为增强型寻呼过程494。

响应于寻呼消息，UE 102发起RRC恢复过程，以便转换到连接状态(例如，RRC_CONNECTED)并接收DL数据。UE 102向DU 174发送446RRC恢复请求消息(例如，RRCResumeRequest消息)，DU 174又向CU 172发送448包括RRC恢复请求消息的DU到CU消息。作为响应，CU 172向DU 174发送450包括RRC恢复消息(例如，RRCResume消息)的CU到DU，DU174进而向UE 102发送452RRC恢复消息。响应于RRC恢复消息，UE 102转换430到连接状态并且在连接状态下操作。在转换到连接状态之后，UE 102向DU 174发送454RRC恢复完成消息(例如，RRCResumeComplete消息)，DU 174又向CU 172发送456包括RRC恢复完成消息的DU到CU消息。然后，UE 102可以经由CU 172和DU 174与CN 110通信458数据。具体地，CU 172可以向UE 102发送DL数据。事件446、448、450、452、430、454、456和458在本公开中统称为数据通信过程496。

转到图4B，场景400B一般类似于场景400A，不同之处在于基站104执行与UE 102的早期数据通信以使得UE 102在不转换到连接状态的情况下接收DL数据。UE 102转换421到非活动状态，类似于图4A。在接收423用于UE 102的DL数据之后，CU 172使用增强型寻呼过程494经由DU 174来寻呼UE 102。CU 172可以在CU 172在增强型寻呼过程494期间向DU 174发送的CU到DU消息中包括关于UE 102将执行早期数据通信的指示。因此，DU 174可以在DU174向UE 102发送的寻呼消息中包括关于UE 102将执行早期数据通信的指示(例如，DU 174可以包括DU 174从CU 172接收的指示，或者可以是由DU 174生成的指示)。

在接收到寻呼消息之后，UE 102向DU 174发送446RRC恢复请求消息，DU 174又在DU到CU消息中将RRC恢复请求消息发送到CU 172。RRC恢复请求消息可以包括UE 102正在发起早期数据通信的指示。与数据通信过程496相反，CU 172然后可以向UE 102发送DL数据，而不使UE 102转换到连接状态。CU 172向DU 174发送451DL数据，DU 174又向UE 102发送453DL数据。在一些实施方式中，在发起早期数据通信之后，UE 102还可以向DU 174发送455UL数据，DU 174进而向CU 172发送457UL数据。然后，CU 172可以将UL数据转发459到CN110。在发送451DL数据(并且在一些实施方式中接收UL数据)之后，CU 172向DU 174发送460包括RRC释放消息的CU到DU消息，DU 174进而向UE 102发送462RRC释放消息462，以便结束早期数据通信。事件446、448、451、453、455、457、459、460和462在本公开中统称为数据通信过程497。

接下来转到图4C，场景400C通常类似于场景400A或400B，除了基站104从另一个基站106接收寻呼增强配置。UE 102最初经由基站106与CN 110通信403，并且稍后转换421到非活动状态。然后，CN 110检测用于UE 102的DL数据，并向基站106的CU 172A发送439DL数据，其中，基站106在UE 102转换到非活动状态之前最后服务于UE 102。然后，CU 172尝试经由DU 174A寻呼UE 102。然而，当DU 174A发送443寻呼DCI和/或发送444寻呼消息时，寻呼DCI和/或寻呼消息不到达UE 102，类似于图3B中的事件343和344。因此，DU 174A没有成功地寻呼UE 102。

CU 172A还在BS到BS消息中向基站104的CU 172B发送470寻呼增强配置。CU 172A可以确定向另一基站发送470寻呼增强配置，因为基站104处于UE 102的寻呼区域中(例如，基于UE 102的TAI列表或RNA)。然后，CU 172B可以使用增强型寻呼过程494经由DU 174B寻呼UE 102。在寻呼UE 102之后，UE 102使用数据通信过程496或497(即，通过转换到连接状态或通过执行早期数据通信)从DU 174B接收DL数据。CU 172B可以从CU 172A接收DL数据。

转到图4D，场景400D最初类似于场景400C。然而，基站104包括CU 172和两个DU，DU174A和DU 174B，类似于图3C中的基站104。最初，CN 110通过向CU 172发送421DL数据来发起对UE 102的寻呼。CU 172尝试经由DU 174B寻呼UE 102，但是DU 174B发送444的寻呼消息没有到达UE 102。然而，CU 172还在CU到DU消息中向DU 174A发送寻呼增强配置，并且DU174A经由增强型寻呼过程494成功地寻呼UE 102。CU 172可以基于UE 102的寻呼区域来向多个DU发送寻呼配置。

图5-图18是描绘RAN(例如，RAN 105)的节点可以执行以管理寻呼UE(例如，UE102)的示例方法的流程图。

图5是用于确定是使用增强型寻呼还是传统寻呼来寻呼UE的方法500的流程图，该方法500可以由DU(例如，DU 174)来实现。在框502处，DU从CU(例如，CU 172)接收指示DU寻呼UE(例如，UE 102)的CU到DU消息(例如，事件324、340、424、440，或者过程394、494内的类似事件)。响应于CU到DU消息，在框504处，DU生成包括UE的标识(例如，NAS ID)的寻呼消息。在框506处，DU还确定DU是否具有用于UE的寻呼增强配置。DU可以在DU在框502处接收到的CU到DU消息中接收寻呼增强配置，或者它可能先前已经接收到用于UE的寻呼增强配置。

如果DU具有寻呼增强配置，则流程进行到框508。在框508处，DU使用寻呼增强配置来经由一个或多个小区向UE发送寻呼消息，以便寻呼UE(例如，事件326、327、328)。例如，基于寻呼增强配置指示UE支持检测PEI，DU可以确定在发送调度寻呼消息的寻呼DCI之前向UE发送PEI。作为另一示例，DU可以基于在寻呼增强配置中标识的寻呼子组，在DCI中或与DCI一起包括对UE的寻呼子组的指示，如上面参考图3A所描述的。

如果DU不具有寻呼增强配置，则流程进行到框510，其中，DU使用预定的寻呼配置来经由一个或多个小区向UE发送寻呼消息，以便寻呼UE。使用预定寻呼配置来寻呼UE对应于寻呼UE的传统方法，如3GPP TS 38.304V16.4.0版本16第7.1节中所描述的。

图6A-图6B分别是可以由CU(例如，CU 172)实现的用于分发用于增强型寻呼的配置的方法600A和600B的流程图。从图6A开始，在框602处，CU从CN(例如，CN 110)接收包括用于寻呼UE(例如，UE 102)的寻呼增强配置的CN到BS消息(例如，事件322、338、415、465)。响应于接收到CN到BS消息或在接收到CN到BS消息之后，在框604处，CU向一个或多个DU发送包括寻呼增强配置的CU到DU消息以寻呼UE(例如，事件324、340、424、440，或过程394、494内的类似事件)。如先前所讨论的，CU可以向UE的寻呼区域内的多个DU发送寻呼增强配置。在一些实施方式中，在框606处，CU向一个或多个基站发送包括寻呼增强配置的BS到BS消息(例如，事件470)。CU可以向UE的寻呼区域内的多个基站发送寻呼增强配置。

参考图6B，方法600B大体上类似于方法600A。然而，在框603处，CU从RAN节点而不是从CN接收寻呼增强配置，如框602中那样。CU从RAN节点(例如，第二基站、或者第二基站的CU或DU)接收包括用于寻呼UE的寻呼增强配置的第一BS到BS消息(例如，事件470)。响应于接收到第一BS到BS消息或在接收到第一BS到BS消息之后，CU向一个或多个DU发送包括寻呼增强配置的CU到DU消息以寻呼UE，类似于框604。在一些实施方式中，在框607处，CU向一个或多个基站发送包括寻呼增强配置的第二BS到BS消息，类似于框606。

在一些实施方式中，框606、603或607处的BS到BS消息是用于寻呼UE的RAN寻呼消息。在其他实施方式中，框606、603或607处的BS到BS消息是切换请求(Handover Request)消息。例如，在框603处，CU(即，目标CU)可以在用于在连接状态下操作的UE的切换准备过程中，从RAN节点(例如，源CU或源基站)接收切换请求消息。在该示例中，CU可以响应于切换请求消息向RAN节点发送切换请求确认消息。在其他实施方式中，框606、603或607处的BS到BS消息是检索UE上下文响应(Context Response)消息。例如，作为框603内的子例程(未示出)，CU(即，新CU)向RAN节点(例如，旧CU或旧基站)发送用于在非活动状态或空闲状态下操作的UE的检索UE上下文请求(Context Request)消息。在该示例中，CU可以响应于检索UE上下文请求消息而从RAN节点接收检索UE上下文响应消息。

图7A-图7B是用于向DU发送CU到DU消息以指示DU寻呼UE的方法700A和700B的流程图，其可以分别由CU(例如，CU 172)和CU-CP实现。首先参考图7A，在框702处，CU确定向DU(例如，DU 174)发送CU到DU消息，以便寻呼UE。在框704处，CU确定CU是否具有用于UE的寻呼增强配置。如果是，则流程进行到框706，其中，CU在CU到DU消息中包括寻呼增强配置。在框708处，CU向一个或多个DU发送CU到DU消息(例如，事件324、340、424、440，或者过程394、494中的类似事件)。如果CU不具有用于UE的寻呼配置，则流程直接从框704进行到框708，并且CU向一个或多个DU发送不包括寻呼增强配置的CU到DU消息。

参考图7B，方法700B大体上类似于方法700A。然而，方法700B由CU-CP执行。在框701处，CU-CP从CU-UP接收针对UE的DL数据通知。在框703处，响应于接收到DL数据通知，CU-CP确定向DU发送CU到DU消息，以便寻呼UE。在框704，CU-CP确定CU是否具有用于UE的寻呼增强配置。如果是，则在框708处，在向一个或多个DU发送CU到DU消息之前，CU-CP将寻呼增强配置包括在CU到DU消息中。

图8-图11是用于确定在其上寻呼UE(例如，UE 102)的小区子集的方法800、900、1000和1100的流程图，其可以分别由DU(例如，DU 174)、CU(例如，CU 172)、基站(例如，基站104或106)和CN(例如，CN 110)实现。在使用方法800-1100中的任何方法确定小区子集之后，RAN可以使用本公开中讨论的增强型寻呼机制或使用传统寻呼机制(例如，3GPP TS38.304V16.4.0版本16第7.1节讨论的传统寻呼机制)在小区子集上寻呼UE。

首先参考图8，在框802处的DU操作一个或多个蜂窝小区，每个蜂窝小区支持频带。由DU操作的每个小区可以支持不同的频带，或者一个或多个小区中的一些小区可以支持相同的频带。在框804处，DU从CU接收包括由UE所支持的频带的频带列表。如关于图3所描述的，在NAS寻呼增强启用过程392期间，一个或多个频带列表可以被包括在来自UE的能力IE中。在框806处，DU从CU接收指示DU寻呼UE的CU到DU消息。在寻呼UE之前，DU在框808处基于频带列表和由DU操作的频带来确定在由UE和DU两者支持的频带内操作的小区。例如，在框808处，DU生成第二频带列表，第二频带列表包括频带列表中的也由DU操作的一个或多个小区支持的频带。因此，第二频带列表是频带列表(即，UE支持的频带)和由DU支持的频带的交集。然后，DU可以确定由DU操作的一个或多个小区中的支持第二频带列表中的频带的那些小区。在框810处，DU在那些小区(即，在框808处确定的小区)上向UE发送寻呼消息。因此，DU在支持由DU和UE两者支持的频带的小区上寻呼UE。

接下来参考图9，方法900类似于方法900，除了CU而不是DU确定DU应该在其上寻呼UE的小区。在框902处，CU从CN、基站或UE接收包括由UE所支持的频带的频带列表。在框904处，CU基于频带列表和由DU操作的频带来确定UE和DU两者支持的频带(支持的小区)。因此，类似于框808处的DU，CU确定第二频带列表，第二频带列表包含频带列表中也由DU操作的一个或多个小区支持的频带。然后，CU可以确定由DU操作的一个或多个小区中的支持第二频带列表中的频带的那些小区。在框906处，为了寻呼UE，CU向DU发送包括小区列表和/或对应于那些小区的频带列表(即，第二频带列表)的CU到DU消息。

转到图10，方法1000由CU或基站实现。为简洁起见，图10的讨论涉及执行方法1000的基站。在框1002处，基站从CN或UE接收包括由UE所支持的频带的频带列表。在框1004处，基站基于频带列表和由RAN操作的频带来确定用于寻呼的频带。因此，类似于图8-图9，基站确定由UE支持的频带与RAN支持的频带的交集。在框1006处，基站向CN发送包括在框1006处确定的频带列表的BS到CN消息。

转到图11，方法1100由CN实现。在框1102，CN经由RAN向UE执行注册过程。在框1204处，CN基于指示由UE支持的频带和由RAN操作的频带的频带列表来确定用于寻呼的频带。因此，CN确定由UE支持的频带与由RAN支持的频带的交集。在框1206处，CN向RAN发送包括在框1204处确定的频带列表的CN到BS消息，其中，RAN利用频带列表来寻呼UE。

图12A-图12B分别是可以由CU(例如，CU 172)实现的用于分发UE寻呼能力的方法1200A和1200B的流程图。首先参考图12A，在框1202处，CU从CN接收包括UE的用于寻呼的一个或多个能力的CN到BS消息。在接收到CN到BS消息之后或响应于接收到CN到BS消息，在框1204处，CU向一个或多个DU发送包括一个或多个能力的CU到DU消息，以便寻呼UE。在一些实施方式中，在框1206处，CU还向一个或多个基站发送包括一个或多个能力的BS到BS消息，以便寻呼UE。CU可以基于UE的寻呼区域，向一个或多个DU发送一个或多个能力，并且在一些实施方式中，向一个或多个基站发送一个或多个能力。

转到图12B，方法1200B大体上类似于方法1200A。然而，在框1203处，CU从BS而不是CN接收UE的用于寻呼的一个或多个能力。CU在第一BS到BS消息中接收能力。响应于接收到第一BS到BS消息或在接收到第一BS到BS消息之后，在框1205处，CU向一个或多个DU发送包括一个或多个能力的CU到DU消息以寻呼UE。在一些实施方式中，CU还在框1207向一个或多个基站发送包括一个或多个能力的第二BS到BS消息。CU可以基于UE的寻呼区域，向一个或多个DU发送一个或多个能力，并且在一些实施方式中，向一个或多个基站发送一个或多个能力。

在一些实施方式中，框1206、1203或1207处的BS到BS消息是用于寻呼UE的RAN寻呼消息。在其他实施方式中，框1206、1203或1207处的BS到BS消息是切换请求消息。例如，在框1203处，CU(即，目标CU)可以在用于在连接状态下操作的UE的切换准备过程中，从RAN节点(例如，源CU或源基站)接收切换请求消息。在该示例中，CU可以响应于切换请求消息向RAN节点发送切换请求确认消息。在其他实施方式中，框1206、1203或1207处的BS到BS消息是检索UE上下文响应消息。例如，CU(即，新CU)向RAN节点(例如，旧CU或旧基站)发送用于在非活动状态或空闲状态下操作的UE的检索UE上下文请求消息。在该示例中，CU可以响应于检索UE上下文请求消息而从RAN节点接收检索UE上下文响应消息。

图13是用于确定要用于寻呼UE的配置的方法1300的流程图，其可以由DU(例如，DU174)实现。在框1302处，DU从CU接收CU到DU消息以寻呼UE。在框1304处，响应于CU到DU消息，DU生成包括UE的标识的寻呼消息。在框1306处，DU确定DU是否具有UE的寻呼能力。如果是，则流程进行到框1308。在框1308处，DU使用寻呼能力来确定用于UE的第一寻呼配置。例如，如果寻呼能力指示UE支持增强型寻呼功能(诸如检测PEI或寻呼子组)，则DU可以确定应用针对UE的增强型寻呼配置。DU可能先前已经接收到增强型寻呼配置(例如，在CU到DU消息中从CU)，或者在框1302处在CU到DU消息中接收到增强型寻呼配置。

如果DU不具有UE的寻呼能力，则流程从框1306进行到框1312，其中，DU使用第二寻呼配置经由一个或多个小区发送寻呼消息以寻呼UE。第二寻呼配置是不包括增强型寻呼功能的寻呼配置，因为DU不知道UE是否支持增强型寻呼功能。例如，第二寻呼配置可以是预定寻呼配置，如3GPP TS 38.304V16.4.0版本16第7.1节中所描述的。

图14是可以由CU(例如，CU 172)实现的用于基于UE的无线电资源控制(RRC)状态来选择寻呼配置的方法1400的流程图。在框1402，CU确定寻呼UE。在框1404处，CU确定UE是在空闲状态(例如，RRC_IDLE)还是在非活动状态(例如，RRC_INACTIVE)下操作。基于UE是处于空闲状态还是非活动状态，CU选择用于寻呼UE的寻呼配置。如果UE处于空闲状态，则在框1406处，CU向一个或多个DU发送包括第一寻呼DRX配置的第一CU到DU消息以寻呼UE。如果UE处于非活动状态，则在框1408处，CU向一个或多个DU发送包括第二寻呼DRX配置的第二CU到DU消息以寻呼UE。

第一寻呼DRX配置和第二寻呼DRX配置中的每一个可以是寻呼DRX IE或寻呼eDRX信息IE。第一寻呼DRX配置和第二寻呼DRX配置可以是不同的。例如，与第一DRX寻呼配置相比，第二DRX寻呼配置可以具有更短的寻呼(e)DRX周期或寻呼时间窗口。此外，第一寻呼DRX配置和第二寻呼DRX配置可以源自不同的源。在一些实施方式中，CU从CN接收第一寻呼DRX配置。在一些实施方式中，CU自己确定第二寻呼DRX配置。

图15是可以由分布式基站(例如，基站104或106)的DU(例如，DU 174)实现的方法1500的流程图，分布式基站包括DU和CU(例如，CU 172)。当分布式基站和UE(例如，UE 102)之间的无线电连接非活动时(例如，当UE在空闲或非活动状态下操作时)，DU可以实现方法1500来寻呼UE。

在框1502处，DU从CU接收用于增强型寻呼的配置(即，寻呼增强配置)(例如，事件324、340、424、440)。在框1504处，DU使用该配置来寻呼UE(例如，事件326、327、328、426、427、428)。

在一些实施方式中，基于该配置，DU确定UE支持检测通知UE在寻呼时机尝试接收寻呼DCI的信号(例如，PEI信号)。在这样的实施方式中，寻呼UE包括发送信号，并且在发送信号之后，在寻呼时机发送寻呼DCI。然后，DU可以根据寻呼DCI发送寻呼消息。如果DU基于配置确定UE不支持这样的信号，则DU可以避免在发送寻呼DCI之前发送信号。

在一些实施方式中，基于该配置，DU确定UE支持寻呼子组。例如，DU可以基于该配置来确定UE的寻呼子组。然后，寻呼UE可以包括基于确定寻呼子组，向UE发送寻呼子组的指示。DU可以通过在寻呼DCI中包括寻呼子组的标识符(例如，寻呼子组ID或子组特定P-RNTI)并将DCI发送到UE来发送指示。可替代地，DU可以通过使用寻呼子组的标识符对寻呼DCI的CRC值进行加扰并将加扰的CRC值与寻呼DCI一起发送到UE来发送指示。如果DU确定UE不支持寻呼子组或者确定UE不属于寻呼子组，则DU可以发送省略寻呼子组的指示的寻呼DCI。

此外，在一些实施方式中，DU基于该配置来确定：(i)UE支持检测通知UE尝试在寻呼时机接收寻呼DCI的信号(例如，PEI信号)，以及(ii)UE的寻呼子组。然后，DU可以通过在信号中包括寻呼子组的指示来寻呼UE，并且在发送寻呼DCI之前将信号发送到UE。

当UE在与用于控制无线电资源的协议(例如，RRC_IDLE或RRC_INACTIVE)相关联的空闲状态或非活动状态下操作时，DU可以寻呼UE。当UE在非活动状态下操作时，DU可以通过发送寻呼消息来寻呼UE，该寻呼消息包括关于UE将发起用于接收数据的过程而不转换到连接状态的指示(例如，对执行早期数据通信的指示)。取决于实施方式，DU可以接收配置作为由符合CU和DU之间的信令的协议(例如，W1AP或F1AP)定义的IE，或者作为由用于控制无线电资源的协议(例如，RRC协议)定义的IE。

图16是可以由分布式基站(例如，基站104或106)的CU(例如，CU 172)实现的方法1600的流程图，分布式基站包括CU和DU(例如，DU 174)。CU可以实现方法1600以在分布式基站和UE(例如，UE 102)之间的无线电连接非活动时(例如，当UE在空闲或非活动状态下操作时)寻呼UE。

在框1602处，CU接收用于增强型寻呼的配置(例如，事件322、338、415、465)。在框1604处，CU确定寻呼UE。响应于确定寻呼UE，在框1606处，CU向DU发送配置以指示DU使用该配置来寻呼UE(例如，事件324、340、424、440)。

在一些实施方式中，CU接收该配置作为由CN和CU之间的信令所符合的协议(例如，NGAP)定义的第一IE。CU可以从第一IE解码配置，将配置编码为由CU和DU之间的信令所符合的协议(例如，F1AP或W1AP)定义的第二IE，并将配置作为第二IE发送给DU。在一些实施方式中，在解码配置之后，CU确定DU不支持包括在配置中的参数。CU可以通过改变参数或从配置中排除参数来修改配置，并将修改后的配置编码为第二IE。

在一些实施方式中，CU向RAN的第二节点(诸如分布式基站的第二DU)或向第二基站发送配置。CU可以接收关于UE的寻呼区域(例如，跟踪区域或RNA)的指示，并且基于寻呼区域向第二节点发送配置。例如，CU可以向UE的寻呼区域内的节点发送配置。

例如，CU可以响应于从CN接收到指示CU寻呼UE的消息或者响应于从CN接收到寻址到UE的数据来确定寻呼UE。取决于实施方式，CU可以从核心网络、第二基站(或第二基站的CU或DU)或DU接收配置。

图17是用于选择在其上寻呼UE(例如，UE 102)的小区的方法1700的流程图，其可以由操作一个或多个小区的基站(例如，基站104或106)来实现。更具体地，方法1700可以由基站的CU(例如，CU 172)或DU(例如，DU 174)实现。在框1702处，基站接收由UE所支持的第一频带列表。在框1704处，基站生成包括第一频带列表中的由一个或多个小区支持的频带的第二频带列表。在框1706处，基站在一个或多个小区中的支持第二频带列表中的频带的小区上寻呼UE。如果方法1700由DU实现，则寻呼UE包括在一个或多个小区中的小区上发送寻呼消息。如果方法1800由CU实现，则寻呼UE可以包括：向基站的DU发送第二频带列表或一个或多个小区中的小区列表，以使DU在一个或多个小区中的小区上寻呼UE。

图18是用于寻呼UE(例如，UE 102)的方法1800的流程图，其可以由分布式基站的CU(例如，CU 172)实现，分布式基站包括CU和DU(例如，DU 174)。在框1802处，CU确定寻呼UE。在框1804处，CU确定UE是处于与用于控制无线电资源的协议相关联的空闲状态还是与该协议相关联的非活动状态。在框1806处，CU基于UE是处于空闲状态还是非活动状态来选择寻呼配置。在框1808处，CU向DU发送所选择的寻呼配置。

以下描述可以应用于以上描述。

在一些实施方式中，“消息”被使用并且可以由“信息元素(IE)”代替。在一些实施方式中，“IE”被使用并且可以由“字段(field)”代替。在一些实施方式中，“配置(configuration)”可以由“配置(configuration)”或配置参数代替。在一些实施方式中，“早期数据通信”可以由“小数据通信”代替，并且“早期数据传输”可以由“小数据传输”代替。

如果小区以时分双工(TDD)模式或在TDD载波频率上操作，则小区的DL BWP和ULBWP(即，与DL BWP相关联)可以是相同的BWP。如果小区以频分双工(FDD)模式或在一对FDD载波频率(即，UL载波频率和DL载波频率)上操作，则小区的DL BWP和UL BWP(即，与DL BWP相关联)是不同的BWP。在这种情况下，DL BWP是DL载波频率的BWP，并且UL BWP是UL载波频率的BWP。在一些实施方式中，小区的UL BWP中的一个UL BWP可以与另一个UL BWP部分重叠或者与另一个UL BWP不重叠。在其他实施方式中，UL BWP中的一个UL BWP可以完全在另一个UL BWP内。在一些实施方式中，小区的DL BWP中的一个DL BWP可以与另一个DL BWP部分重叠或者与另一个DL BWP不重叠。在其他实施方式中，DL BWP中的一个DL BWP可以完全在另一个DL BWP内。

可以实现本公开的技术的用户设备(例如，UE 102)可以是能够进行无线通信的任何合适的设备，诸如智能电话、平板计算机、膝上型计算机、移动游戏控制台、销售点(POS)终端、健康监测设备、无人机、相机、媒体流加密狗或另一个人媒体设备、可穿戴设备(诸如智能手表、无线热点、毫微微小区或宽带路由器)。此外，在一些情况下，用户设备可以嵌入在电子***中，诸如车辆的头部单元或高级驾驶员辅助***(ADAS)。此外，用户设备可以作为物联网(IoT)设备或移动互联网设备(MID)操作。取决于类型，用户设备可以包括一个或多个通用处理器、计算机可读存储器、用户接口、一个或多个网络接口、一个或多个传感器等。

某些实施例在本公开中被描述为包括逻辑或多个组件或模块。模块可以是软件模块(例如，代码或存储在非暂时性机器可读介质上的机器可读指令)或硬件模块。硬件模块是能够执行某些操作的有形单元，并且可以以某种方式配置或布置。硬件模块可以包括永久配置为执行某些操作的专用电路或逻辑(例如，作为专用处理器，诸如现场可编程门阵列(FPGA)或专用集成电路(ASIC)、数字信号处理器(DSP)等)。硬件模块还可以包括由软件临时配置以执行某些操作的可编程逻辑或电路(例如，包含在通用处理器或其他可编程处理器内)。在专用和永久配置的电路中或在临时配置的电路(例如，由软件配置)中实现硬件模块的决定可以由成本和时间考虑来驱动。

当在软件中实现时，这些技术可以作为操作***的一部分、由多个应用使用的库、特定软件应用等来提供。软件可以由一个或多个通用处理器或一个或多个专用处理器执行。

以下示例列表反映了本公开明确考虑的各种实施例：

示例1。一种在无线电接入网络(RAN)的分布式基站的分布式单元(DU)中用于当分布式基站与用户设备(UE)之间的无线电连接非活动时寻呼UE的方法，分布式基站包括DU和集中式单元(CU)，该方法包括：由DU的处理硬件从CU接收用于增强型寻呼的配置；以及由处理硬件使用配置来寻呼UE。

示例2。根据示例1所述的方法，还包括：由处理硬件基于配置来确定UE支持检测通知UE在寻呼时机尝试接收寻呼下行链路控制信息(DCI)的信号，其中，寻呼UE包括：基于该确定，发送信号；以及在发送信号之后，在寻呼时机发送寻呼DCI。

示例3。根据示例1所述的方法，还包括：由处理硬件基于该配置来确定UE不支持检测到通知UE在寻呼时机尝试接收寻呼下行链路控制信息(DCI)的信号，其中，寻呼UE包括：基于该确定，避免发送信号。

示例4。根据示例1-3中任一项所述的方法，还包括：由处理硬件基于该配置来确定UE的寻呼子组，其中，寻呼UE包括：基于该确定，向UE发送寻呼子组的指示。

示例5。根据示例4所述的方法，其中，DU通过以下方式发送指示：将寻呼子组的标识符包括在寻呼下行链路控制信息(DCI)中；以及向UE发送寻呼DCI。

示例6。根据示例4所述的方法，其中，DU通过以下操作来发送指示：使用寻呼子组的标识符对寻呼下行链路控制信息(DCI)的循环冗余校验(CRC)值进行加扰；以及将加扰的CRC值与寻呼DCI一起发送给UE。

示例7。根据示例1-3中任一项所述的方法，还包括：基于该配置确定UE不属于寻呼子组，其中，寻呼UE包括：基于该确定，生成省略对寻呼子组的指示的寻呼下行链路控制信息(DCI)；以及向UE发送寻呼DCI。

示例8。根据示例1所述的方法，还包括：由处理硬件基于该配置来确定：(i)UE支持检测通知UE在寻呼时机尝试接收寻呼下行链路控制信息(DCI)的信号，以及(ii)UE的寻呼子组；其中，寻呼UE包括：响应于确定，在信号中包括寻呼子组的指示；向UE发送信号；以及在发送信号之后，在寻呼时机发送寻呼DCI。

示例9。根据前述示例中任一项所述的方法，其中，寻呼UE包括：当UE在与用于控制无线电资源的协议相关联的空闲状态下操作时，寻呼UE。

示例10。根据示例1-8中任一项所述的方法，其中，寻呼UE包括：当UE在与用于控制无线电资源的协议相关联的非活动状态下操作时，寻呼UE。

示例11。根据示例10所述的方法，其中，寻呼UE包括：发送寻呼消息，寻呼消息包括关于UE将发起用于在不转换到连接状态的情况下接收数据的过程的指示。

示例12。根据前述示例中任一项所述的方法，其中，DU接收配置作为由符合CU和DU之间的信令的协议定义的信息元素(IE)。

示例13。根据示例1-11中任一项所述的方法，其中，DU接收配置作为由用于控制无线电资源的协议定义的信息元素(IE)。

示例14。一种在无线电接入网络(RAN)的分布式基站的集中式单元(CU)中用于当分布式基站与用户设备(UE)之间的无线电连接非活动时寻呼UE的方法，分布式基站包括CU和分布式单元(DU)，该方法包括：由CU的处理硬件接收用于增强型寻呼的配置；由处理硬件确定寻呼UE；以及响应于该确定，由处理硬件向DU发送该配置，以指示DU使用该配置来寻呼UE。

示例15。根据示例14所述的方法，其中：CU接收配置作为由核心网络和CU之间的信令所符合的协议定义的第一信息元素(IE)；该方法还包括：由处理硬件从第一IE解码配置；以及由处理硬件将该配置编码为由CU和DU之间的信令所符合的协议定义的第二IE；以及CU将该配置作为第二IE发送给DU。

示例16。根据示例15所述的方法，还包括：在解码该配置之后，由处理硬件确定DU不支持包括在该配置中的参数；以及由处理硬件通过改变该参数或从配置中排除该参数来修改配置，其中，CU将修改后的配置编码为第二IE。

示例17。根据示例14-16中任一项所述的方法，还包括：响应于该确定，由处理硬件向RAN的第二节点发送该配置。

示例18。根据示例17所述的方法，其中：DU是分布式基站的第一DU；并且第二节点是分布式基站的第二DU。

示例19。根据示例17所述的方法，其中：分布式基站是第一基站；并且第二节点是第二基站。

示例20。根据示例17-19中任一项所述的方法，还包括：由处理硬件接收对UE的寻呼区域的指示，其中，向第二节点发送配置包括：基于寻呼区域向第二节点发送配置。

示例21。根据示例14-20中任一项所述的方法，其中：CU在来自核心网络的指示CU寻呼UE的消息中接收用于UE的配置；以及CU响应于接收到该消息而确定寻呼UE。

示例22。根据示例14-20中任一项所述的方法，还包括：从核心网络接收寻址到UE的数据，其中，CU响应于接收到该数据而确定寻呼UE。

示例23。根据示例14-20中任一项所述的方法，其中，CU从核心网络接收配置。

示例24。根据实例14到20中任一项的方法，其中，CU从第二基站接收配置。

示例25。根据示例24所述的方法，其中，CU从第二基站的DU接收配置。

示例26。根据示例14-20中任一项所述的方法，其中，CU从DU接收配置。

示例27。一种基站中用于寻呼用户设备(UE)的方法，基站操作一个或多个小区，该方法包括：由基站的处理硬件接收由UE支持的第一频带列表；由处理硬件生成第二频带列表，第二频带列表包括第一频带列表中的由一个或多个小区支持的频带；以及由处理硬件在一个或多个小区中支持第二频带列表中的频带的小区上寻呼UE。

示例28。根据示例27所述的方法，其中，该方法由基站的分布式单元(DU)实现。

示例29。根据示例28所述的方法，其中，寻呼UE包括：在一个或多个小区中的小区上发送寻呼消息。

示例30。根据示例27所述的方法，其中，该方法由基站的集中式单元(CU)实现。

示例31。根据示例30所述的方法，其中，寻呼UE包括：向基站的DU发送第二频带列表，以使得DU在一个或多个小区中的小区上寻呼UE。

示例32。根据示例30所述的方法，其中，寻呼UE包括：生成一个或多个小区中的小区列表；以及向基站的DU发送小区列表，以使得DU在小区上寻呼UE。

示例33。一种分布式基站的集中式单元(CU)中的用于寻呼用户设备(UE)的方法，分布式基站包括CU和分布式单元(DU)，该方法包括：由CU的处理硬件确定寻呼UE；由处理硬件确定UE是处于与用于控制无线电资源的协议相关联的空闲状态还是与该协议相关联的非活动状态；由处理硬件基于UE是处于空闲状态还是非活动状态来选择寻呼配置；以及由处理硬件向DU发送该寻呼配置。

示例34。一种无线电接入网络(RAN)的节点，包括处理硬件并且被配置为实现根据上述示例中任一项所述的方法。

Claims (15)

1.一种在无线电接入网络(RAN)的分布式基站的分布式单元(DU)中用于当分布式基站与用户设备(UE)之间的无线电连接非活动时寻呼UE的方法，所述分布式基站包括DU和集中式单元(CU)，所述方法包括：

由DU的处理硬件从CU接收指示UE是否支持寻呼子组的寻呼消息；以及

由所述处理硬件根据UE是否支持寻呼子组来寻呼UE。

2.根据权利要求1所述的方法，其中，接收所述寻呼消息包括：

接收包括UE的寻呼子组标识的所述寻呼消息。

3.根据权利要求1或2所述的方法，其中，接收所述寻呼消息包括：

接收由符合CU和DU之间的信令的协议定义的所述寻呼消息。

4.根据权利要求1-3中任一项所述的方法，其中，接收所述寻呼消息包括接收包括在所述寻呼消息中的UE能力信息元素(IE)。

5.根据权利要求4所述的方法，其中，所述UE能力IE指示UE是否支持寻呼子组。

6.根据权利要求4或5所述的方法，其中，所述UE能力IE指示UE是否支持检测寻呼早期指示(PEI)。

7.根据权利要求1至5中任一项所述的方法，其中，所述寻呼消息还指示UE是否支持检测寻呼早期指示(PEI)。

8.一种在无线电接入网络(RAN)的分布式基站的集中式单元(CU)中用于当分布式基站与用户设备(UE)之间的无线电连接非活动时寻呼UE的方法，所述分布式基站包括CU和分布式单元(DU)，所述方法包括：

由CU的处理硬件确定寻呼UE；以及

响应于所述确定，由所述处理硬件向DU发送寻呼消息以指示DU寻呼UE，所述寻呼消息指示UE是否支持寻呼子组。

9.根据权利要求8所述的方法，其中，发送所述寻呼消息包括：

发送包括UE的寻呼子组标识的所述寻呼消息。

10.根据权利要求8或9所述的方法，其中，发送所述寻呼消息包括：

发送由符合CU和DU之间的信令的协议定义的所述寻呼消息。

11.根据权利要求8至10中任一项所述的方法，其中，发送所述寻呼消息包括发送包括在所述寻呼消息中的UE能力信息元素(IE)，所述UE能力IE指示UE是否支持寻呼子组。

12.根据权利要求8-11中任一项所述的方法，其中，所述寻呼消息还指示UE是否支持检测寻呼早期指示。

13.根据权利要求8-12中任一项所述的方法，其中，所述寻呼消息是第一寻呼消息，所述方法还包括：

响应于所述确定，由所述处理硬件向RAN的第二节点发送第二寻呼消息，所述第二寻呼消息指示UE是否支持寻呼子组。

14.根据权利要求8-13中任一项所述的方法，还包括：

在确定寻呼UE之前，由所述处理硬件从核心网络接收指示CU寻呼UE的消息，所述消息指示UE是否支持寻呼子组；其中

所述CU响应于接收到所述消息而确定寻呼UE。

15.一种无线电接入网络(RAN)的节点，包括处理硬件并且被配置为实现根据上述权利要求中任一项所述的方法。