CN116600385B - 用于在无线网络中寻呼和发射ue身份的方法、设备和系统 - Google Patents

Abstract

本公开提供了一种用于在无线网络中寻呼和发射UE身份的方法、设备和系统。该方法包括：由无线通信网络的第一网络元件向无线通信网络的第二网络元件发送第一寻呼消息，该第一寻呼消息以UE为目标并且包括第一组寻呼参数；由第一网络元件标识与第一寻呼消息相关联的寻呼失败条件；以及由第一网络元件在标识出寻呼失败条件时向第二网络元件发送第二寻呼消息，该第二寻呼消息以UE为目标并且包括不同于第一组寻呼参数的第二组寻呼参数。

Description

用于在无线网络中寻呼和发射UE身份的方法、设备和系统

本申请是申请号为202080102891.5、申请日为2020年8月7日、发明名称为“用于在无线网络中寻呼和发射UE身份的方法、设备和系统”的中国专利申请的分案申请。

技术领域

本公开总体上涉及无线通信，并且具体地涉及用于寻呼移动设备并且发送移动设备的身份信息的方法、系统和设备。

背景技术

寻呼移动设备的成功率是无线通信系统中的一个重要的性能指标。在降低功耗的同时提高寻呼成功率一直是无线通信网络中的各种网络设备的设计的一个重要目标。对于窄带物联网(NB-IoT)和机器类型通信(MTC)设备尤其如此。在寻呼过程中，无线通信网络与移动设备之间的稳健和高效的信令可以显著地有助于省电。

发明内容

本公开涉及用于在无线通信网络中寻呼移动设备的方法、系统和设备。

在一些实现中，公开了一种由无线网络中的网络元件和/或用户设备(UE)执行的方法。该方法可以包括由无线通信网络的第一网络元件向无线通信网络的第二网络元件发送第一寻呼消息，第一寻呼消息以UE为目标并且包括第一组寻呼参数；由第一网络元件标识与第一寻呼消息相关联的寻呼失败条件；以及由第一网络元件在标识出寻呼失败条件时向第二网络元件发送第二寻呼消息，第二寻呼消息以UE为目标并且包括不同于第一组寻呼参数的第二组寻呼参数。

进一步公开了一种网络元件和/或UE。该网络元件和/或UE包括处理器和存储器，其中处理器被配置为从存储器读取计算机代码以实现上述方法。进一步公开了一种计算机可读介质。该计算机可读介质包括指令或计算机程序，该指令或计算机程序在由无线终端执行时引起无线终端执行上述方法。

上述实施例及其实现的其他方面和替代方案在以下附图、说明书和权利要求中更详细地描述。

附图说明

图1示出了示例性无线通信网络。

图2示出了示例性寻呼周期。

图3示出了详细的示例性寻呼消息流。

图4示出了用于处理最后小区信息的示例性消息流。

图5示出了用于确保UE状态一致性的示例性消息流。

图6示出了用于确保UE状态一致性的另一示例性消息流。

图7示出了用于在核心网与基站之间同步UE上下文操作的握手机制。

图8示出了用于发送寻呼辅助信息的示例性消息流。

具体实施方式

以下描述和附图详细阐述了本公开的某些说明性实现，这些实现指示可以实施本公开的各种原理的若干示例方式。然而，图示的示例并非穷尽本公开的很多可能的实施例。本公开的其他目的、优点和新颖特征将结合附图在下面的详细描述中阐述。

介绍

图1示出了示例性无线通信网络100，包括核心网110和无线电接入网(RAN)120。核心网110还包括至少一个移动性管理实体(MME)112和/或至少一个接入和移动性管理功能(AMF)。可以被包括在核心网110中的其他功能在图1中未示出。RAN 120还包括多个基站，例如基站122和124。基站可以包括用于4G LTE的至少一个演进型NodeB(eNB)、或者用于5G新无线电(NR)的下一代NodeB(gNB)、或者任何其他类型的信号发射/接收设备，诸如UMTSNodeB。eNB 122经由S1接口与MME 112通信。eNB 122和gNB 124都可以经由Ng接口连接到AMF 114。每个基站管理和支持至少一个小区。例如，基站gNB 124可以被配置为管理和支持小区1、小区2和小区3。

gNB 124可以包括中央单元(CU)和至少一个分布式单元(DU)。CU和DU可以并置(co-located)在同一位置，或者它们可以被拆分在不同位置。CU和DU可以经由F1接口连接。替代地，对于能够连接到5G网络的eNB，其也可以被类似地划分为CU和至少一个DU，分别称为ng-eNB-CU和ng-eNB-DU。ng-eNB-CU和ng-eNB-DU可以经由W1接口连接。

无线通信网络100可以包括一个或多个跟踪区域。跟踪区域可以包括由至少一个基站管理的一组小区。例如，标记为140的跟踪区域1包括小区1、小区2和小区3，并且还可以包括可以由其他基站管理的更多小区，且在图1中未示出。无线通信网络100还可以包括至少一个UE 160。UE可以在基站支持的多个小区中选择小区，以通过空中(OTA)无线电通信接口和资源与基站进行通信，并且当UE 160在无线通信网络100中移动时，它可以重新选择用于通信的小区。例如，UE 160最初可以选择小区1来与基站124通信，然后它可以在稍后的某个时间点重新选择小区2。可以基于各种小区中的无线信号强度/质量以及和其他因素，由UE 160进行小区选择或重新选择。

无线通信网络100可以被实现为例如2G、3G、4G/LTE或5G蜂窝通信网络。相应地，基站122和124可以被实现为2G基站、3G NodeB、LTE eNB或5G NR gNB。UE 160可以被实现为能够接入无线通信网络100的移动或固定通信设备。UE 160可以包括但不限于移动电话、膝上型计算机、平板电脑、个人数字助理、可穿戴设备、IoT设备、MTC/eMTC设备、分布式遥感设备、路边辅助设备和台式计算机。

在无线通信网络100中，UE可以由核心网110使用寻呼机制来定位。寻呼失败可能由多种原因引起。例如，各种失败模式包括：由于唤醒信号(WUS)检测不一致性而导致的寻呼失败；由UE和各种网络元件跟踪的UE状态的不一致性而导致的寻呼失败。下面公开的各种实施例是用于处理和解决这种不一致性的定向方法、设备和系统。

虽然下面的描述集中在如图1所示的蜂窝无线通信系统上，但是基本原理适用于用于寻呼无线设备的其他类型的无线通信系统。这些其他的无线系统可以包括但不限于Wi-Fi、Bluetooth、ZigBee和WiMax网络。

WUS检测相关的寻呼失败

唤醒信号被引入作为对现有寻呼技术的增强，以通过减少在监测寻呼信息时的硬件资源使用来进一步降低功耗并且延长移动设备的电池寿命。寻呼监测中的唤醒机制对于诸如NB-IoT(物联网)和eMTC(增强型机器类型通信)设备等低功耗设备尤其有益。参考图1，当UE 160与基站之间没有活动的通信会话时，那么UE 160保持在空闲状态。UE 160继续监测寻呼信号，同时在空闲状态期间限制其对无线电资源的使用以降低功耗。例如，UE 160可以通过使用包括但不限于不连续接收(DRX)或扩展不连续接收(eDRX)在内的技术来监测寻呼信号。

在DRX中，资源监测和通信活动是按周期被管理的，称为DRX周期。特别地，在诸如LTE和5G等无线通信系统中，无线电信号在无线电帧中被发射。在系统等级，无线电帧按顺序被标识，并且每个无线电帧都用系统帧号(SFN)被编号，该SFN例如从0到1023进行循环。在DRX模式下，UE可以进入睡眠模式以减少电池消耗。UE周期性地监测寻呼时机(PO)。PO包括一组物理下行链路控制信道(PDCCH)监测时机，并且可以包括在其中可以发送寻呼DCI的多个时隙(例如，子帧或OFDM符号)。对PO进行周期性监测的目的是检查是否有针对UE的寻呼消息、以及获取系统信息更新，使得UE可以能够与网络同步。如果没有针对特定UE的寻呼消息，则UE可以返回睡眠，并且唤醒以在下一周期监测PO。该周期称为寻呼周期或DRX周期。寻呼周期的长度由每个周期中的无线电帧的数目给出。

在eDRX中，UE能够设置和调节其在唤醒以监测任何无线信号之前保持在低功耗睡眠模式的时间。eDRX机制使得UE，尤其是NB-IoT或eMTC设备，能够进一步降低电池消耗。除了DRX和eDRX，唤醒信号(WUS)可以进一步降低UE的功耗，如下所述。

具有WUS的寻呼

图2示出了具有WUS信号的寻呼周期。在寻呼周期210期间，UE经历3种状态(或模式)：睡眠状态，其中UE处于睡眠模式并且消耗最少功率；WUS检测状态212；以及PO监测状态214，其中UE消耗最多功率。在PO监测状态214下，UE解码PDCCH并且可能还需要通过激活和使用完整接收器硬件来解码物理下行链路共享信道(PDSCH)数据。在PO监测状态之前增加唤醒信号(WUS)检测状态212，以帮助UE确定是否需要进一步解码PO PDCCH数据。与用于解码PO PDCCH的完整接收器硬件不同，WUS检测是在物理层上使用较低功耗的硬件电路系统来进行的，该硬件电路系统可以与完整接收器硬件分离。UE只需要在WUS检测结果指示存在PO PDCCH数据供UE解码时，才激活完整接收器。否则，UE将立即返回睡眠，并且在下一寻呼周期期间唤醒。由于WUS检测硬件的简单性和高效性，UE可以进一步降低功耗。

在一般的寻呼机制中，一组UE形成寻呼组，并且在无线信令消息中共享同一PO和在PO之前的同一服务WUS。因此，即使寻呼组中只有一个UE是寻呼消息的目标，WUS也会存在并且会被同一寻呼组中的每个UE检测到和采取行动。结果，在具有高业务量的跟踪区域(TA)中，寻呼消息存在于作为组的UE的PO中的概率变高。在极端情况下，每个PO中可能存在针对UE组内的至少一个UE的寻呼消息，因此每个PO之前都有WUS。在这种情况下，UE组中的每个UE除了在每个寻呼周期监测和解码PO PDCCH之外，还会检测WUS，从而与在没有WUS机制的情况下直接监测PDCCH相比，导致了与频繁的WUS检测相关联的功耗更高。进一步，在这种情况下，由于跟踪区域包括多个小区，在整个跟踪区域中广播的一个寻呼消息可以传播到跟踪区域下的所有小区。因此，上述问题可能会影响整个跟踪区域中的UE。

为了避免这种情况下的高功耗，WUS的发射和检测可能会受到限制。例如，在寻呼UE时，核心网和基站可以仅在UE的最后小区(last cell)中发射用于寻呼的PDCCH之前的WUS。最后小区是UE最近访问或连接到的小区。核心网和基站还被配置为在同一跟踪区域内的其他小区中，只发射用于寻呼的PDCCH而不发射WUS，从而减少了UE组中需要监测WUS和用于寻呼的PDCCH的UE的数目。同时，UE可以被配置为仅在最后小区中监测WUS和PDCCH。当UE不在最后小区中时(例如，当UE执行小区重新选择，但还没有连接到小区时)，UE可以被配置为跳过WUS检测并且直接继续监测用于寻呼的PDCCH。以图1为例，UE 160可以在一个时间点连接到小区1并且小区1是UE 160的最后小区。随后，UE 160移动到小区2并且进行小区重新选择以选择小区2。然而，UE 160尚未与小区2下的核心网交互。因此，即使UE 160现在在小区2中，UE 160的最后小区仍然是小区1。当在小区2中监测用于寻呼的PDCCH时，由于小区2不是UE 160的最后小区，所以UE 160跳过WUS检测并且直接继续监测PDCCH。随后，UE 160与小区2中的核心网进行交互。小区2现在成为UE 160的最后小区，并且UE 160将在继续进行PO PDCCH解码之前，开始检测WUS。通过使用该解决方案，大大降低了WUS的发射和监测的频率，从而节省了更多能源。

如上所述，最后小区对于该解决方案的完美运行起着关键作用，因为它用于在解码用于寻呼的PDCCH之前确定是否需要WUS检测。在UE和核心网上一致地记录UE的最后小区是至关重要的。最后小区记录的不一致性可能导致寻呼失败。在诸如信令链路失败或网络过载等某些异常网络条件下，最后小区记录可能会变得不一致。例如，假定UE的最后小区是小区1。在一个时间点，UE可以移动到小区2并且尝试发起与核心网的交互。但是，在核心网侧，交互可能会失败。在这种情况下，UE可以将自己的最后小区记录更新为小区2，而诸如MME或AMF等核心网为UE保留陈旧的最后小区记录(小区1)。在这种情况下，当MME或AMF需要向UE发送寻呼消息时，由于MME或AMF并不认为小区2是UE的最后小区，因此最终在小区2中发射的寻呼消息只包括用于寻呼的PDCCH，而不包括WUS。但是在UE侧，UE认为小区2是最后小区，所以UE在继续进行以解码用于寻呼的PDCCH之前，尝试检测WUS信号，但是寻呼消息中没有携带WUS信号，所以寻呼最终失败。

UE状态不一致

UE在操作期间可能处于各种状态。这些状态包括但不限于空闲状态、非活动状态和连接状态。在一种场景下，UE状态可能变得不一致，如跨UE、基站和核心网所跟踪的。例如，当基站发起涉及核心网和UE的UE相关过程时，核心网和UE可能依赖于其参与的动作的结果将UE标记为不一致状态。例如，UE侧的操作可能是成功的，而在核心网侧的操作失败了。在这种情况下，有可能UE将自己标记为一种状态，而核心网将UE标记为另一种状态，导致UE状态的不一致性。作为涉及UE和核心网两者的UE上下文释放过程中的具体示例，该过程中发生在核心网中的错误条件可能导致核心网认为UE正处于连接状态，而不知道错误条件的UE可能认为自己处于空闲状态。这种UE状态不一致性可能造成后续的寻呼失败，因为核心网可能认为UE未处于接收寻呼消息的正确状态。更多细节将在本公开的后面的实施例中给出。

实施例的简要描述

在本公开中，描述了用于解决由不一致的最后小区记录引起的WUS相关的寻呼问题的各种实施例。进一步描述了用于解决UE状态不一致性问题的各种其他实施例。此外，描述了附加实施例以增强寻呼消息传递。其他实施例涉及在各种小区覆盖模式下UE身份信息的传输。

实施例1

示例性寻呼过程参见图3。在该寻呼过程中，核心网302(MME/AMF)可能需要寻呼UE306。以UE 306为目标的寻呼消息310可以从核心网302被发起，并且经由诸如S1或Ng接口等接口被发送给基站304。核心网包括至少一个MME和/或至少一个AMF。基站可以是任一种信号发射和接收站点，包括gNB、eNB或NodeB。寻呼消息310可以携带包括推荐小区列表的一组寻呼参数，并且推荐小区列表还包含正被寻呼的UE的最后小区信息。最后小区信息可以包括小区标识符，诸如小区ID。如前所述，最后小区是UE最近访问的或最近连接到的小区。当基站接收到包括最后小区信息的寻呼消息时，基站向由基站管理的、并且与该UE属于同一跟踪区域的所有小区发射寻呼消息。基站通过在寻呼消息312中在PO PDCCH之前发射WUS，来区别对待最后小区。对于最后小区以外的其他小区，基站通过仅发射PO PDCCH，而不发射在前的WUS(图5中未示出)来寻呼UE。

下面针对多个场景描述UE的行为。在第一场景中，假定UE在最后小区中。UE首先监测WUS，并且如前所述，由于存在由基站发射的WUS，因此检测到WUS指示在对应PO中可能存在用于UE的寻呼消息。然后UE进一步监测和执行PDCCH以进行寻呼解码，并且成功接收到寻呼消息。应当理解，基于PO PDCCH解码结果，可能还需要执行物理下行链路共享信道(PDSCH)解码。在第二场景中，UE可以重新选择新小区而不是最后小区，并且还没有连接到新小区。UE监测新小区中的寻呼消息。在这种情况下，由于新小区与最后小区不同，UE将跳过WUS检测，并且可以根据由基站发射的寻呼消息的格式直接监测PO PDCCH。UE也可能能够正确接收寻呼消息。在上述任一场景中，一旦UE接收到寻呼消息，UE就会经由诸如非接入层信令等信令，对寻呼消息进行响应。

在如上所解释的成功寻呼过程中，当核心网发起具有最后小区参数的寻呼消息时，UE与核心网具有一致的最后小区记录，并且UE能够做出关于要在接收寻呼消息时，在解码PO PDCCH之前是否检测WUS的正确决定。

然而，在另一场景中，由核心网和UE记录的最后小区可能会变得不一致。例如，在某个时刻，UE访问并且连接到小区(诸如小区)，以及随后UE重新选择另一小区(诸如小区2)，以及然后发起用于连接的请求。连接请求可以包括但不限于以下任一项：

·RRC(无线电资源控制)连接请求；

·RRC连接恢复请求；

·RRC早期数据请求；或者

·RRC连接重建立请求。

在基站接收到请求之后，它尝试在MME/AMF与UE之间建立S1或Ng连接。但是，连接设置可能会失败。例如，核心网中的MME或AMF可能会由于过载情况而拒绝该请求。因此，MME或AMF仍可能将UE访问的先前小区视为最后小区，例如小区1。相反，UE可能将最后小区视为UE在其中发起RRC连接的小区，例如小区2。这会导致由核心网和UE记录的对最后小区的不一致性。仍然参考图3，如果存在以UE为目标的寻呼消息，则核心网经由S1或Ng接口向基站发送寻呼消息310，该寻呼消息310包括最后小区(小区1，根据由核心网记录的最后小区)信息。然后基站通过在小区2中发射寻呼消息312来寻呼UE，而不在PO PDCCH之前包括WUS，因为小区2不是从核心网发起的每个寻呼消息的最后小区。因为UE当前在小区2中并且认为小区2是其最后小区，所以UE在继续进行PO PDCCH解码之前尝试检测WUS。由于小区2中的寻呼信号不包含任何WUS，UE确定没有PO PDCCH可供其进一步监测，并且因此未能接收到寻呼消息。

在该实施例中，为了保证UE接收到寻呼消息，提供了一种解决方案。参考图3，在如上所述的UE在小区2中未能接收到寻呼消息312之后，由于UE没有响应，核心网在314通过例如检测超时条件来确定寻呼失败。然后核心网向基站重新发送寻呼消息316。在这个第二尝试中，核心网可以从寻呼消息去除最后小区信息。

在一些实现中，推荐小区列表可以被携带在寻呼消息中的推荐小区的辅助数据(Assistance Data for Recommended Cells)信息元素中。最后小区可以被列为推荐小区的辅助数据中的第一个条目。如果核心网决定从寻呼消息中去除最后小区信息，则寻呼消息可以不携带推荐小区的辅助数据。在基站侧，如果基站在寻呼消息中没有获取推荐小区的辅助数据，则节点认为没有最后小区。在这种情况下，无论小区是否是最后小区，基站都会向在UE所属的跟踪区域内的所有小区发送在PO PDCCH之前带有WUS的寻呼消息。如图3所示，寻呼消息318被发送给包括小区2在内的所有小区。寻呼消息318还包括UE期望在小区2内检测到的WUS。因此，即使核心网和UE具有不同的记录的UE的最后小区信息，在寻呼UE的第二尝试之后，UE接收寻呼消息。

如上所述，核心网在初始寻呼努力失败之后，在第二寻呼尝试中修改寻呼信号(或一般地，寻呼信号中包含的一个或多个寻呼参数)。这样的修改使得UE能够正确地检测和解码寻呼消息。

实施例2

在实施例2中，提供了用来维持核心网与UE之间的最后小区记录的一致性的解决方案。

例如，在一个时刻，UE可能在小区1中并且将小区1视为其最后小区。UE然后重新选择小区2并且尝试与基站建立连接。参考图4，UE可以向基站发送RRC消息410。RRC消息可以包括但不限于以下任一项：

·RRC连接请求；

·RRC连接恢复请求；

·RRC早期数据请求；或者

·RRC连接重建立请求。

在基站接收到RRC消息之后，基站可以尝试在UE与核心网之间建立S1或Ng连接，该连接可以是逻辑链路。如果S1或Ng连接建立失败，则基站可以发送响应消息412以拒绝RRC连接。响应消息可以包括但不限于以下任一项：

·RRC连接拒绝消息；

·RRC连接释放消息；或者

·RRC连接重建立拒绝消息。

即使在这种情况下UE未能在小区2中建立S1或Ng连接，UE仍然可以在连接建立请求之后将小区2视为最后小区，并且更新其最后小区记录。UE进一步确定需要监测该小区中的WUS，因为它是其记录的最后小区。然而，核心网将UE访问或连接到的先前小区视为最后小区，例如小区1，并且向基站发送以UE为目标的、携带最后小区信息(小区1)的寻呼消息。基站通过仅在小区1中在PO PDCCH之前发射WUS来寻呼UE，而在小区1以外的其他小区中不发射WUS。因此，由于UE期望WUS触发PO PDCCH解码，但未检测到任何WUS，因此UE错过寻呼消息。UE的寻呼因此失败了。

为了确保UE接收到寻呼消息，该实施例提供了一种解决方案来强制UE与核心网之间的最后小区记录的一致性。具体地，当基站确定S1或Ng连接建立失败时，基站发送携带指示符的RRC响应消息412。在一些实现中，指示符可以包括指示最后小区信息或UE应当如何监测寻呼信号的单个比特。例如，如果该比特被设置为1(真)，则它可以指示以下至少一项：

·核心网中存储的最后小区不会被UE发起的RRC消息改变。

·S1或Ng连接建立失败。

·UE应当保留其最后小区记录(在该示例中，小区1应当被保留作为最后小区，以匹配核心网中的最后小区记录。

·UE应当在当前小区(在该示例中为小区2)中直接监测用于寻呼的PO PDCCH，并且跳过WUS检测。

当UE接收到RRC响应消息412时，它可以检查RRC响应消息中携带的指示符，以确定核心网中的最后小区记录是否已经更新。基于该信息，UE可以保留其最后小区记录(小区1)以匹配核心网记录，而不将其最后小区记录更新为小区2。替代地，UE仍可以将其最后小区记录更新到小区1并且附加地为该不一致条件创建内部标志。当内部标志被设置时，UE将直接监测PO PDCCH并且跳过WUS检测。

实施例3

实施例3提供了用于解决如前所述的小区状态不一致性问题的解决方案。该解决方案可以从基站侧发起。

在无线通信网络中，UE上下文暂停过程被用于在RAN和核心网中暂停UE上下文、UE相关联的逻辑S1或Ng连接、以及相关的承载上下文。基站可能由于过载条件或按照用户平面(UP)解决方案所指示的，来触发UE上下文暂停过程。为了降低功耗，基站可以在从核心网接收例如UE上下文暂停响应消息的形式的暂停确认之前，经由具有暂停指示的RRC释放消息来暂停UE。在接收到具有暂停指示的RRC释放时，UE暂停UE上下文并且转换到空闲模式，即使暂停操作尚未被核心网确认(或批准)。

如果核心网拒绝UE上下文暂停，MME或AMF将使用UE上下文暂停失败或错误(ERROR)指示消息来响应于基站，并且核心网将仍认为UE处于连接模式，而UE已经进入空闲模式。这样，产生了在核心网与UE之间对UE状态的不一致性。

该实施例提供了解决这种UE状态不一致性的解决方案。该解决方案是通过提供强制暂停的选项来确保核心网可以成功暂停UE上下文。在一些实现中，可以使用UP解决方案。参考图5，基站可以发送携带指示符的UE上下文暂停请求消息510，并且该指示符例如可以包括在该消息中的单个比特。当指示符比特被设置为1(真)时，它可以指示以下至少一项：

·基站在没有来自核心网的确认或批准的情况下暂停UE。

·基站在接收来自核心网的成功响应之前暂停UE。

·在基站向核心网发送暂停请求之后，基站立即暂停UE。

·在执行UE上下文暂停时，无论是否有错误情况，核心网都被强制无条件地暂停UE。

例如，紧接在基站向核心网发送UE上下文暂停请求消息510之后，基站继续进行以向UE发送RRC释放消息512，而无需等待来自核心网的响应。在核心网侧，即使在执行UE上下文暂停时出现错误条件，核心网也会抑制错误或失败响应消息516被发送回基站。核心网进一步更新UE状态，以指示UE上下文操作成功。替代地，核心网可以选择将UE上下文暂停成功消息514发送回基站。

在该实施例中，通过引入强制UE上下文暂停操作，由UE上下文暂停操作引起的UE状态不一致性问题可以得到解决。本文中讨论的原理适用于可能导致UE和核心网感知的UE状态不一致性的其他UE上下文操作。

实施例4

实施例4提供了用来解决如前所述的小区状态不一致性问题的另一解决方案。该解决方案可以从基站侧发起。

在无线通信网络中，UE上下文释放过程被用于使得基站能够请求核心网释放UE相关联的逻辑S1或Ng连接。基站可能由于过载条件或按照控制平面(CP)解决方案所指示的，来触发UE上下文释放过程。为了降低功耗，基站可以在从核心网接收确认或批准之前，经由RRC释放消息来释放UE。在UE侧，如果UE接收到RRC释放消息，则UE释放UE上下文并且转换到空闲模式。

如果核心网拒绝UE上下文释放，核心网将仍认为UE处于连接模式。这样，产生了在核心网与UE之间对UE状态的不一致性。

该实施例提供了用于解决这种UE状态不一致性的解决方案。该解决方案是通过提供强制释放的选项来确保核心网可以成功释放UE上下文。在一些实现中，可以使用CP解决方案。例如，在空闲模式下，UE的上下文被释放。参考图6，基站可以发送携带指示符的UE上下文释放请求消息610，并且该指示符例如可以包括在该消息中的单个比特。当指示符比特被设置为1(真)时，它可以指示以下至少一项：

·基站在没有来自核心网的确认或批准的情况下释放UE上下文。

·基站在接收来自核心网的成功响应之前释放UE上下文。

·在基站向核心网发送UE上下文释放请求之后，基站立即释放UE上下文。

·在执行UE上下文释放时，无论是否有错误条件，核心网都被强制无条件地释放UE上下文。

例如，紧接在基站向核心网发送UE上下文释放请求消息610之后，基站继续进行以向UE发送RRC释放消息612，而无需等待来自核心网的批准或确认。在核心网侧，即使在执行UE上下文释放时出现错误条件，核心网也会抑制错误指示消息614被发送回基站。核心网进一步更新UE状态，以指示UE上下文操作成功。

在该实施例中，通过引入强制UE上下文释放操作，由UE上下文释放操作引起的UE状态不一致性问题可以得到解决。本文中讨论的原理适用于可能导致UE和核心网感知的UE状态不一致性的其他UE上下文操作。

实施例5

实施例5提供了用来解决小区状态不一致性问题的另一解决方案。本解决方案从核心网侧发起。

在一些实践中，在UE上下文释放过程和UE上下文暂停过程中，为了降低功耗，基站可以在与核心网确认成功的释放或暂停操作之前，释放或暂停UE上下文。但是，在某些失败情况下，核心网可能无法成功释放或暂停UE。在这种情况下，基站和核心网需要在UE上下文操作方面进行协作或同步。

在该实施例中，在后续UE上下文释放或暂停过程之前，执行核心网与基站之间的握手，使得核心网与基站之间可以就如何处理这些过程达成一致。该握手可以从核心网侧发起。通过握手，可以就是否允许基站继续进行UE上下文释放或暂停过程达成一致，而无需首先从核心网接收确认或批准。参考图7，携带用于该同步握手目的的指示符的消息710可以从核心网发送给基站。在一些实现中，该消息可以是S1或Ng消息。特别地，该S1或Ng消息可以包括以下至少一项：

·初始上下文建立请求；

·连接建立指示；

·AMF CP重定位指示；

·切换请求；

·切换命令；

·路径切换请求确认；

·切换成功；或者

·UE上下文恢复响应消息。

该指示符可以包括在上述消息中的单个比特，以指示是否允许基站在没有与MME或AMF确认操作成功的情况下、或在接收成功响应之前、或紧接在基站向MME或AMF发送请求之后，释放或暂停UE。例如，如果该指示符被设置为1(真)，则表示允许基站在来自MME或AMF的对成功响应的确认之前，释放或暂停UE上下文。在这种情况下，核心网和基站可以具有关于UE上下文操作被强制为成功的约定，并且核心网需要更新小区状态以指示UE上下文操作成功。另一方面，如果该指示符被设置为0(假)，则表示在来自MME或AMF的对成功响应的确认之前，不允许基站释放或暂停UE上下文。也就是说，基站必须等到接收到来自核心网的确认或批准之后，才能继续进行以向UE发送UE上下文释放消息。如果在核心网侧的UE上下文操作失败，则基站接收错误指示或失败消息，并且基站将不会基于约定继续释放UE上下文。

此外，基于实际需要，该约定可以随时更新。

实施例6

该实施例提供了用来从CU向DU发射寻呼配置信息的若干解决方案。

如前所述，在RRC空闲或非活动模式下，诸如新无线电(NR)UE、LTE UE或eMTC/NB-IoT设备等UE可以使用DRX以便降低功耗。寻呼消息在寻呼时机(PO)中被发射。UE在每个寻呼周期中监测PO。

基站和核心网都可以向UE发送DRX配置信息。对于对延迟不敏感的某些UE，诸如eMTC、NB-IoT或NR UE，核心网和UE可以经由非接入层(NAS)消息来协调UE专用(special)DRX周期。当核心网寻呼UE并且向基站发送寻呼消息时，寻呼消息可以携带UE专用DRX周期配置，包括DRX周期的值。对于需要低功耗的一些UE，诸如eMTC、NB-IoT或NR UE，核心网和UE可以经由NAS消息来协调eDRX周期和寻呼时间窗口(PTW)。PTW是为UE而配置的时段(period)，在该时段期间，UE监测DRX周期之后的寻呼时机。当核心网寻呼UE并且向基站发送寻呼消息时，寻呼消息可以携带eDRX配置，eDRX配置包括eDRX周期和PTW。基站可以广播默认寻呼DRX周期(包括DRX周期的值)、以及系统信息块(SIB)中的最小UE特定(specific)DRX周期。如果UE特定DRX周期由核心网分配，则CN(核心网)UE寻呼DRX周期可以被确定为默认DRX周期和UE特定DRX周期的最小值。替代地，CN UE寻呼DRX周期可以被视为默认DRX周期和寻呼周期的最小值，其中寻呼周期是UE特定DRX值和最小UE特定DRX值中的最大值。如果UE特定DRX没有被高层配置或者如果最小UE特定DRX值没有在系统信息中广播，则可以应用默认DRX值并且CN UE寻呼DRX周期被设置为默认DRX值。

具体地，UE应当在非活动模式下使用DRX来监测从基站触发的RAN寻呼消息。包括DRX周期的值的RAN寻呼周期配置经由RRC消息被配置，该RRC消息触发UE进入非活动模式。

如果UE被配置有eDRX，则基站可以知道UE的确切DRX周期。为了避免UE错过寻呼消息，DRX周期可以由核心网配置的DRX周期和基站在SIB或RRC消息中指示的DRX周期中的最短者确定。因此，如果UE被配置有eDRX，则DRX周期可以由RAN寻呼周期、UE特定寻呼周期(如果由核心网分配)、和PTW期间的默认寻呼周期中的最短者确定，并且DRX周期可以由PTW之外的RAN寻呼周期确定。

替代地，如果UE被配置有eDRX，则如果UE特定DRX由核心网配置或者如果最小UE特定DRX值在PTW期间被广播，则DRX周期可以被确定为默认DRX周期的最小值和寻呼周期中的最短者，该寻呼周期是UE特定DRX值和最小UE特定DRX值中的最大值，并且DRX周期可以被确定为PTW之外的RAN寻呼周期。

替代地，如果UE被配置有eDRX，则如果UE特定DRX没有由核心网配置或者如果最小UE特定DRX值在PTW期间没有被广播，则DRX周期可以由默认DRX值确定，并且DRX周期可以由PTW之外的RAN寻呼周期确定。

在CU-DU拆分架构中，CU是连接到至少一个DU的中央单元，DU是分布式单元。CU与DU之间的接口包括F1接口或W1接口。

在寻呼场景中，CU首先接收寻呼消息，并且使用F1消息或W1消息(诸如寻呼消息)将其发送给DU。DU负责寻呼信号到UE的调度和传输。DU应当能够知道寻呼信号的传输时机。因此，DU应当获取有关UE的DRX周期的信息。此外，如果UE被配置有eDRX，则PTW期间和之外的DRX周期是不同的。所以DU应当能够区分PTW期间和之外的DRX周期。

在该实施例中，提供了若干解决方案，使得DU能够获取上述信息。

解决方案1

解决方案1是CU经由F1接口(用于5G)或W1接口(用于4G)向DU递送寻呼消息。如果UE被配置有eDRX，则寻呼消息包括RAN寻呼值、CN UE寻呼DRX周期、和eDRX配置，eDRX配置包括eDRX周期和寻呼时间窗口(PTW)。

解决方案2

解决方案2是CU经由F1接口(用于5G)或W1接口(用于4G)向DU递送寻呼消息。如果UE被配置有eDRX，则寻呼消息包括寻呼值、RAN寻呼周期、和eDRX配置，eDRX配置包括eDRX周期的值和寻呼时间窗口(PTW)。寻呼周期是RAN寻呼周期和CN UE寻呼DRX周期中的最小值。

解决方案3

解决方案3是CU经由F1接口(用于5G)或W1接口(用于4G)向DU递送寻呼消息。如果UE被配置有eDRX，则寻呼消息包括UE专用DRX周期(如果由核心网分配)、默认寻呼DRX周期、RAN寻呼周期、和eDRX配置，eDRX配置包括eDRX周期的值和寻呼时间窗口(PTW)。

解决方案4

解决方案4是CU经由F1接口(用于5G)或W1接口(用于4G)向DU递送寻呼消息。如果UE被配置有eDRX，则寻呼消息包括UE专用DRX周期(如果由核心网分配)、默认寻呼DRX周期、最小UE特定DRX值(如果广播)、RAN寻呼周期、以及eDRX周期和寻呼时间窗口(PTW)。

实施例7

该实施例提供了在CU-DU拆分架构中的寻呼增强。

对于CU-DU拆分架构，CU(诸如ng-eNB-CU、gNB-CU)从核心网接收寻呼，并且然后将其递送给DU。DU(诸如ng-eNB-DU、gNB-DU)负责寻呼信号调度和传输。

在来自核心网的寻呼消息中，可以提供一些寻呼辅助信息来帮助基站发射寻呼消息。该信息对DU也是有益的。

参考图8，在该实施例中，CU被配置为经由F1或W1接口将寻呼辅助信息递送给DU。寻呼辅助信息可以携带在从CU发送给DU的寻呼消息810中。

寻呼消息可以包括但不限于以下至少一项：

·用于寻呼的辅助数据；

·eDRX参数；

·RAN寻呼DRX；

·CN(核心网)寻呼DRX；或者

·WUS辅助信息。

特别地，用于寻呼的辅助数据可以包括：

·用于推荐小区的辅助数据；

·用于支持CE(覆盖增强)的UE的辅助数据；

·寻呼尝试信息。

WUS辅助信息可以包括寻呼概率信息。

实施例8

该实施例提供了在CU-DU拆分架构中的另一寻呼增强。

如前所述，在空闲或非活动模式下，UE需要监测寻呼消息。为了节省功率，UE可以监测WUS，并且如果检测到WUS指示PO中存在寻呼，则然后监测PDCCH。如果同一寻呼组中的一个UE被寻呼，则该寻呼组中的所有UE都需要监测PDCCH。因此，引入了组唤醒信号(groupwake up signal，GWUS)。在GWUS方案下，UE可以监测GWUS，并且如果检测到GWUS指示存在WUS，则UE然后监测WUS，并且如果检测到WUS指示在PO中存在寻呼，则UE然后监测PDCCH。

在CU-DU架构中，当寻呼消息从核心网被发送时，包括要由基站使用以确定UE的WUS组的寻呼概率信息的WUS辅助信息被发送给CU。但是，负责GWUS的调度和传输的是DU。因此，该实施例中提供了一种解决方案，使得DU可以从CU获取上述GWUS相关信息。

在该实现中，CU被配置为经由F1或W1接口通过寻呼消息将WUS辅助信息或寻呼概率信息递送给DU。

实施例9

该实施例提供了另一寻呼增强。

当UE处于非活动模式时，可以在基于RAN的通知区域内发送寻呼消息。当将UE变为非活动模式的源小区需要寻呼UE时，寻呼消息可以被发送给目标小区。对于目标小区，可能需要在以UE为目标的后续寻呼消息中发射GWUS。因此，用于确定WUS组的参数和UE的传输时机信息可以被发送给目标小区，以增强寻呼性能。

在该实施例中，源小区被配置为使用经由X2或Xn接口从源小区发送给目标小区的RAN寻呼消息，向目标小区递送辅助信息，诸如WUS辅助信息、寻呼概率信息、或eDRX配置，eDRX配置包括eDRX周期的值和寻呼时间窗口(PTW)。

实施例10

该实施例提供了另一寻呼增强。

当UE处于非活动模式时，小区可以触发对UE的寻呼。如果小区被配置为在寻呼消息中发射GWUS，那么用于确定UE的WUS组的参数也是必要的。但是，该参数存储在核心网中，并且只有在寻呼从核心网被发起时该参数才会被发送给基站。因此，在Ng或S1中的UE特定连接建立中，需要解决方案来将该参数从核心网发送给基站。

在该实施例中，核心网被配置为在Ng或S1中的UE特定连接建立中，将WUS辅助信息或寻呼概率信息递送给基站。WUS辅助信息或寻呼概率信息可以被携带在消息中，该消息包括但不限于：

·初始上下文建立请求；

·UE上下文修改请求；

·切换请求；或者

·路径切换请求确认。

特别地，WUS辅助信息或寻呼概率信息可以被携带在用于RRC非活动的核心网辅助信息(Core Network Assistance Information fro RRC INACTIVE)信息元素(IE)中。

实施例11

该实施例提供了用于UE发送身份信息的增强。

对于某个UE，诸如LTE、eMTC、NB-IoT或NR UE，它可以具有连接到5G通信系统中的核心网的能力。为了标识UE，UE需要将其在5G系统中的UE身份发送给核心网。例如，UE向基站发送包括UE的5G S-TMSI的RRC消息，并且然后基站将5G S-TMSI递送给核心网。

但是，5G S-TMSI占用48位。如果UE在RRC消息(诸如RRC连接请求消息)中包括5GS-TMSI，则它可能会太长。因此，可以使用截断的5G-S-TMSI。例如，截断的5G-S-TMSI可以是从5G-S-TMSI构建的40位UE标识符。截断的5G-S-TMSI可以由AMF集ID的n个LSB(最低有效位)、AMF指针的m个LSB、和5G-TMSI的(40-n-m)个LSB组成，其中m和n为正整数，并且(m+n)<40。核心网和UE使用相同的规则来产生相同的5G-S-TMSI。

此外，UE的信号质量对服务质量有影响。如果UE处于覆盖增强模式，例如，如果UE的参考信号接收功率(RSRP)低于阈值，则UE可以转换到覆盖增强模式，例如，按照基站所指示的。在覆盖增强模式下，UE具有有限的无线能力，诸如有限的传输比特率。另一方面，如果UE处于正常覆盖模式，则UE具有更好的信道质量并且被提供有更好的服务，例如更快的传输比特率。

当UE触发连接并且向基站发送RRC消息或UL数据时，如果该消息太大且UE具有有限的无线能力，则该消息可能会失败。RRC消息可以包括但不限于：

·RRC连接请求；

·RRC连接重建立请求；

·RRC连接恢复请求；

·RRC早期数据请求。

UL数据可以是UL MAC PDU(上行链路媒体访问控制协议数据单元)等。

为了解决这个问题，在该实施例中，如果UE处于正常覆盖模式，则UE可以在RRC消息或UL数据中包括5G-S-TMSI，而如果UE处于覆盖增强模式，则可以包括截断的5G-S-TMSI。

特别地，由AS(接入层)选择5G-S-TMSI或截断的5G-S-TMSI，并且NAS可能不知道该选择。NAS可以将包括5G-S-TMSI和截断的5G-S-TMSI的UE身份发送给AS。对于截断的5G-S-TMSI，用于产生截断的5G-S-TMSI的m、n的值也应当被发送给AS。如果AS选择截断的5G-S-TMSI，则m和n的值可以被包括在RRC消息或UL数据中。

总之，以上公开描述了一种用于可靠地递送和接收寻呼消息并且降低功耗的方法和系统。在寻呼失败的情况下，不具有最后小区信息的第二寻呼消息被发送，使得即使核心网与UE之间对最后小区记录存在不一致，UE仍然能够解码PO PDCCH并且接收寻呼消息。此外，基站与UE之间的RRC消息被扩展，以携带用于指示核心网是否没有为UE更新其最后小区记录的指示符，以便UE可以保留其最后小区记录。UE上下文暂停和UE上下文释放消息也被扩展，以携带用于发信号通知强制核心网UE上下文操作的指示符，使得即使在UE上下文操作失败时，核心网也能够更新指示UE上下文操作成功的UE状态。还引入了在核心网与基站之间的握手机制，使得这两个网络实体就是否允许基站在从核心网接收到确认或批准之前向UE发送RRC释放消息达成一致。本公开中描述的方案有助于提高无线通信系统中的寻呼成功率。

本公开还描述了用于增强寻呼性能的各种实施例。在一些实施例中，在CU-DU拆分架构中，CU可以向DU发送寻呼相关信息，以促进DU提高寻呼性能。寻呼相关信息包括eDRX配置参数、寻呼辅助信息、和WUS辅助信息。一些其他实施例描述了在诸如核心网、基站、源小区、和目标小区等各种网络元件之间发送WUS相关信息。

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

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

一般而言，术语可以至少部分从上下文中的使用来理解。例如，本文中使用的诸如“和”、“或”或“和/或”等术语可以包括多种含义，这些含义可以至少部分取决于使用这样的术语的上下文。通常，“或”如果用于关联列表，诸如A、B或C，则旨在表示A、B和C，这里用于包括性意义，以及A、B或C，这里用于排他性意义。此外，本文中使用的术语“一个或多个”可以至少部分取决于上下文而用于以单一意义描述任何特征、结构或特性，或者可以用于以复数意义描述特征、结构或特性的组合。类似地，至少部分取决于上下文，诸如“一个(a)”、“一个(an)”或“该(the)”等术语可以被理解为传达单数用法或传达复数用法。此外，术语“基于”可以被理解为不一定旨在传达一组排他性因素，而是可以允许存在不一定明确描述的附加因素，这再次至少部分取决于上下文。

在整个说明书中对特征、优点或类似语言的引用并不表示可以用本解决方案来实现的所有特征和优点都应当被包括在其任何单个实现中。相反，提及特征和优点的语言被理解为表示结合实施例描述的特定特征、优点或特性被包括在本解决方案的至少一个实施例中。因此，在整个说明书中对特征和优点以及类似语言的讨论可以但不一定指代相同的实施例。

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

Claims (21)

1.一种用于无线通信的方法，包括：

由无线通信网络的第一网络元件经由通信接口向所述无线通信网络的第二网络元件发送寻呼消息，所述寻呼消息包括一组寻呼参数，其中所述一组寻呼参数包括寻呼时间窗口(PTW)、扩展不连续接收(eDRX)周期、以及无线电接入网(RAN)寻呼周期，所述一组寻呼参数被所述第二网络元件用于发送寻呼信号，以及其中所述第一网络元件包括基站的中央单元(CU)，并且所述第二网络元件包括所述基站的分布式单元(DU)。

2.根据权利要求1所述的方法，其中所述基站包括下一代NodeB(gNB)、或能够连接到5G网络的LTE演进型nodeB(ng-eNB)中的一项。

3.根据权利要求1所述的方法，其中所述通信接口包括F1接口或W1接口中的至少一项。

4.根据权利要求1所述的方法，其中所述一组寻呼参数还包括核心网(CN)UE寻呼不连续接收(DRX)周期。

5.根据权利要求1所述的方法，其中所述第一网络元件包括源小区，并且所述第二网络元件包括目标小区。

6.一种用于无线通信的方法，包括：

由无线通信网络的第一网络元件经由通信接口接收来自所述无线通信网络的第二网络元件的寻呼消息，所述寻呼消息包括一组寻呼参数，其中所述一组寻呼参数包括寻呼时间窗口(PTW)、扩展不连续接收(eDRX)周期、以及无线电接入网(RAN)寻呼周期，以及其中所述第一网络元件包括基站的分布式单元(DU)，并且所述第二网络元件包括所述基站的中央单元(CU)；

基于所述一组寻呼参数发送寻呼信号。

7.根据权利要求6所述的方法，其中所述基站包括gNB、或能够连接到5G网络的LTE演进型nodeB(ng-eNB)中的一项。

8.根据权利要求6所述的方法，其中所述一组寻呼参数还包括核心网(CN)UE寻呼DRX周期。

9.根据权利要求6所述的方法，其中所述通信接口包括F1接口或W1接口中的至少一项。

10.根据权利要求6所述的方法，其中所述第一网络元件包括目标小区，并且所述第二网络元件包括源小区。

11.一种第一网络元件，包括用于存储计算机指令的存储器以及与所述存储器通信的处理器，其中当所述处理器执行所述计算机指令时，所述处理器被配置为使得所述第一网络元件：

经由通信接口向第二网络元件发送寻呼消息，所述寻呼消息包括一组寻呼参数，其中所述一组寻呼参数包括寻呼时间窗口(PTW)、扩展不连续接收(eDRX)周期、以及无线电接入网(RAN)寻呼周期，并且其中所述一组寻呼参数被所述第二网络元件用于发送寻呼信号，以及其中所述第一网络元件包括基站的中央单元(CU)，并且所述第二网络元件包括所述基站的分布式单元(DU)。

12.根据权利要求11所述的第一网络元件，其中所述基站包括下一代NodeB(gNB)、或能够连接到5G网络的LTE演进型nodeB(ng-eNB)中的一项。

13.根据权利要求11所述的第一网络元件，其中所述一组寻呼参数还包括核心网(CN)UE寻呼不连续接收(DRX)周期。

14.根据权利要求11所述的第一网络元件，其中所述通信接口包括F1接口或W1接口中的至少一项。

15.根据权利要求11所述的第一网络元件，其中所述第一网络元件包括源小区，并且所述第二网络元件包括目标小区。

16.一种第一网络元件，包括用于存储计算机指令的存储器以及与所述存储器通信的处理器，其中当所述处理器执行所述计算机指令时，所述处理器被配置为使得所述第一网络元件：

经由通信接口接收来自第二网络元件的寻呼消息，所述寻呼消息包括一组寻呼参数，其中所述一组寻呼参数包括寻呼时间窗口(PTW)、扩展不连续接收(eDRX)周期、以及无线电接入网(RAN)寻呼周期，以及其中所述第一网络元件包括基站的分布式单元(DU)，并且所述第二网络元件包括所述基站的中央单元(CU)；

基于所述一组寻呼参数发送寻呼信号。

17.根据权利要求16所述的第一网络元件，其中所述基站包括gNB、或能够连接到5G网络的LTE演进型nodeB(ng-eNB)中的一项。

18.根据权利要求16所述的第一网络元件，其中所述一组寻呼参数还包括核心网(CN)UE寻呼DRX周期。

19.根据权利要求16所述的第一网络元件，其中所述通信接口包括F1接口或W1接口中的至少一项。

20.根据权利要求16所述的第一网络元件，其中所述第一网络元件包括目标小区，并且所述第二网络元件包括源小区。

21.一种非暂态计算机可读存储介质，其上存储有计算机代码，所述计算机代码在由处理器执行时，使得实现根据权利要求1至10中任一项所述的方法。