CN114143914A - 寻呼方法及装置 - Google Patents

Abstract

本发明公开了一种寻呼方法，该方法包括：用户设备在待用态下收到来自于目标基站的寻呼消息，寻呼消息包括用户设备的核心网标识；用户设备判断目标基站是否属于用户设备驻留的通知区；若目标基站属于通知区，用户设备在待用态下恢复与目标基站的连接以从待用态变为连接态，若目标基站不属于通知区，用户设备进入空闲态后与目标基站建立连接以从空闲态变为连接态。本发明还公开了一种寻呼装置。通过上述方式，本发明能够减少信令开销和处理开销。

Description

寻呼方法及装置

技术领域

本发明涉及通信领域，特别是涉及一种寻呼方法及装置。

背景技术

在新无线(New Radio，NR)中，用户设备(User Equipment，UE)有三种状态，无线资源控制(Radio Resource Control，RRC)连接(RRC_CONNECTED)态、RRC待用(RRC_INACTIVE)态和RRC空闲(RRC_IDLE)态。

处于RRC_INACTIVE状态的UE仍然有核心网(Core Network，CN)-无线接入网(Radio Access Network，RAN)连接关系，保持有UE的CN-RAN连接关系且存储UE上下文(context)的基站被称为锚基站，锚基站负责为UE配置通知区。同时，核心网把处于RRC_INACTIVE状态的UE当做演进分组系统(Evolved Packet System，EPS)连接管理(EPSConnection Management，ECM)连接态，意味着核心网认为UE连接到锚基站。因此，如果存在下行数据，则核心网会向锚基站发送该下行数据，然后锚基站会执行RAN发起的寻呼(以下简称无线接入网寻呼或RAN寻呼)并通知通知区内的基站执行无线接入网寻呼以在通知区内寻呼UE。

无线接入网寻呼成功的流程图如图1所示，UE在RRC_INACTIVE状态下接收到来自目标基站，即UE当前驻留的基站，的RAN寻呼消息；然后UE向目标基站发送消息1：随机接入前导(preamble)；目标基站向UE发送消息2：随机接入响应；UE向目标基站发送消息3：RRC连接恢复请求，消息3中包括UE的接入网标识(RAN UE ID)，且其中的原因值(causeValue)被设置为寻呼响应(mt-Access)；由于图中的目标基站不是锚基站，因此需要从锚基站取回UEcontext，如果目标基站是锚基站，则取回UE context的过程可以省去；目标基站向UE发送消息4：RRC连接恢复；然后UE从RRC_INACTIVE变为RRC_CONNECTED。图1中锚基站的寻呼过程未画出。

现有技术中，如果通知区中的所有基站的无线接入网寻呼均失败，锚基站会通知核心网UE无法在通知区中被找到并指示核心网释放UE context，然后核心网会释放UEcontext，将UE当做ECM空闲态并通知跟踪区(tracking area，TA)内的所有基站执行核心网发起的寻呼(以下简称核心网寻呼)，TA大于通知区。如果收到核心网寻呼消息，无论是否位于通知区内，UE都会自动进入RRC_IDLE态以避免状态不匹配，然后响应核心网发起的寻呼消息与寻呼它的基站建立连接,从RRC_IDLE变为RRC_CONNECTED。在建立连接的过程中，核心网需要重建UE context，为UE修改承载等，具体过程如图2所示。

可以看出，无线接入网寻呼失败后通过核心网寻呼而找到的UE需要从RRC_INACTIVE进入RRC_IDLE再变为RRC_CONNECTED，与通过无线接入网寻呼而找到的UE直接从RRC_INACTIVE变为RRC_CONNECTED相比，信令开销和处理开销明显增大。

发明内容

本发明主要解决的技术问题是提供一种寻呼方法及装置，能够解决现有技术中无线接入网寻呼失败后核心网寻呼信令开销和处理开销的明显增大的问题。

为了解决上述技术问题，本发明提供了一种寻呼方法，该方法包括：用户设备在待用态下收到来自于目标基站的寻呼消息，寻呼消息包括用户设备的核心网标识；用户设备判断目标基站是否属于用户设备驻留的通知区；若目标基站属于通知区，用户设备在待用态下恢复与目标基站的连接以从待用态变为连接态，若目标基站不属于通知区，用户设备进入空闲态后与目标基站建立连接以从空闲态变为连接态。

为了解决上述技术问题，本发明提供了一种寻呼方法，该方法包括：锚基站执行无线接入网寻呼以寻呼用户设备并通知所在的通知区中的基站执行无线接入网寻呼以寻呼用户设备，无线接入网寻呼包括多次发送无线接入网寻呼消息，无线接入网寻呼消息包括用户设备的接入网标识；无线接入网寻呼失败后，锚基站向核心网发送无线接入网寻呼失败消息，无线接入网寻呼失败消息用于指示核心网保留用户设备的上下文且通知跟踪区中所有基站执行核心网寻呼以寻呼用户设备；锚基站执行核心网寻呼以寻呼用户设备，核心网寻呼包括多次发送核心网寻呼消息，核心网寻呼消息包括用户设备的核心网标识；锚基站接收来自于用户设备的连接恢复请求然后向用户设备发送连接恢复信令以将用户设备从待用态变为连接态，或锚基站协助目标基站将用户设备从待用态变为连接态。

为了解决上述技术问题，本发明提供了一种寻呼方法，该方法包括：目标基站执行无线接入网寻呼以寻呼用户设备，无线接入网寻呼包括多次发送无线接入网寻呼消息，无线接入网寻呼消息包括用户设备的接入网标识；无线接入网寻呼失败后，目标基站执行核心网寻呼以寻呼用户设备，核心网寻呼包括多次发送核心网寻呼消息，核心网寻呼消息包括用户设备的核心网标识；目标基站接收来自于用户设备的连接恢复请求；目标基站向用户设备发送连接恢复信令以将用户设备从待用态变为连接态。

为了解决上述技术问题，本发明提供了一种寻呼方法，该方法包括：锚基站执行无线接入网寻呼以寻呼用户设备并通知所在的通知区中的基站执行无线接入网寻呼以寻呼用户设备；锚基站在未收到用户设备寻呼响应的情况下接收来自于用户设备的原因值为基于接入网的位置区域更新的连接恢复请求然后向用户设备发送连接恢复信令以将用户设备从待用态变为连接态，或锚基站在未收到所述用户设备的寻呼响应的情况下接收来自于目标基站的取回用户设备上下文的请求然后向目标基站发送取回用户设备上下文响应消息以协助目标基站将用户设备从待用态变为连接态，取回用户设备上下文的请求是目标基站响应来自于用户设备的原因值为基于接入网的位置区域更新的连接恢复请求而发送的。

为了解决上述技术问题，本发明提供了一种寻呼方法，该方法包括：目标基站接收来自于待用态下的用户设备的原因值为基于接入网的位置区域更新的连接恢复请求；目标基站响应原因值为基于接入网的位置区域更新的连接恢复请求向锚基站发送取回用户设备上下文的请求；目标基站接收来自于锚基站的取回用户设备上下文响应消息；目标基站向用户设备发送连接恢复信令以将用户设备从待用态变为连接态。

为了解决上述技术问题，本发明提供了一种寻呼方法，该方法包括：处于待用态的用户设备在未收到无线接入网寻呼消息的情况下向目标基站发送原因值为基于接入网的位置区域更新的连接恢复请求；用户设备接收来自于目标基站的连接恢复信令；用户设备响应连接恢复信令从待用态进入连接态。

为了解决上述技术问题，本发明提供了一种寻呼装置，该装置包括处理器和通信电路，处理器连接通信电路，处理器用于执行指令以实现前述的任意一种方法。

为了解决上述技术问题，本发明提供了一种寻呼装置，该寻呼装置存储有指令，指令被执行时实现前述的任意一种方法。

本发明的有益效果是：在无线接入网寻呼失败但用户设备仍处于通知区内的情况下，通知区内的基站进行核心网寻呼但用户设备直接恢复与目标基站的连接/通知区内的基站可以继续进行无线接入网寻呼而不是核心网寻呼，使得驻留在通知区内的用户设备可以直接从RRC_INACTIVE变为RRC_CONNECTED而不用进入RRC_IDLE状态，从而减少信令开销和处理开销；在无线接入网寻呼过程中，若用户设备未收到无线接入网寻呼消息时发起了基于接入网的位置区域更新(RAN-based Location Area Update，RLAU)，锚基站/目标基站收到原因值为基于接入网的位置区域更新的连接恢复请求后不是向用户设备发送连接暂停以完成RLAU而是发送连接恢复信令以将用户设备从RRC_INACTIVE变为RRC_CONNECTED，如果用户设备驻留在的基站属于通知区，则省去了保持RRC_INACTIVE的过程，并降低了无线接入网寻呼失败的概率，从而减少信令开销和处理开销，如果目标基站不属于通知区，现有技术中无线接入网寻呼会失败需要启动核心网寻呼，而本申请能够在无线接入网寻呼过程中成功找到用户设备而无需启动核心网寻呼，降低了无线接入网寻呼失败的概率，减少信令开销和处理开销。

附图说明

图1是现有技术中无线接入网寻呼成功的流程示意图；

图2是现有技术中无线接入网寻呼失败后核心网寻呼成功的流程示意图；

图3是本发明寻呼方法第一实施例的流程示意图；

图4是本发明寻呼方法第二实施例的流程示意图；

图5是本发明寻呼方法第三实施例的流程示意图；

图6是本发明寻呼方法第四实施例的流程示意图；

图7是由目标基站自身对用户设备的CN UE ID和RAN UE ID进行匹配的情况下图6中S29的流程示意图；

图8是由锚基站对用户设备的CN UE ID和RAN UE ID进行匹配的情况下图6中S29的流程示意图；

图9是本发明寻呼方法第五实施例的流程示意图；

图10是本发明寻呼方法第六实施例的流程示意图；

图11是本发明寻呼方法第七实施例的流程示意图；

图12是本发明寻呼方法第八实施例的流程示意图；

图13是本发明寻呼方法第九实施例的流程示意图；

图14是本发明寻呼方法第十实施例的流程示意图；

图15是本发明寻呼方法第十一实施例的流程示意图；

图16是本发明寻呼方法第十二实施例的流程示意图；

图17是本发明寻呼方法第十三实施例的流程示意图；

图18是本发明寻呼方法第十四实施例的流程示意图；

图19是本发明寻呼方法第十五实施例的流程示意图；

图20是本发明寻呼方法第十六实施例的流程示意图；

图21是本发明寻呼方法第十七实施例的流程示意图；

图22是本发明寻呼方法第十八实施例的流程示意图；

图23是本发明寻呼方法第十九实施例的流程示意图；

图24是本发明寻呼方法第二十实施例的流程示意图；

图25是本发明寻呼方法第二十一实施例的流程示意图；

图26是本发明寻呼方法第二十二实施例的流程示意图；

图27是本发明寻呼方法第二十三实施例的流程示意图；

图28是本发明寻呼方法第二十四实施例的流程示意图；

图29是本发明寻呼方法第二十五实施例的流程示意图；

图30是本发明寻呼装置第一实施例的结构示意图；

图31是本发明寻呼装置第二实施例的结构示意图；

图32是本发明寻呼装置第三实施例的结构示意图；

图33是本发明寻呼装置第四实施例的结构示意图；

图34是本发明寻呼装置第五实施例的结构示意图；

图35是本发明寻呼装置第六实施例的结构示意图。

具体实施方式

下面结合附图和实施例对本发明进行详细说明。以下各实施例中不冲突的可以相互结合。

本发明寻呼方法第一实施例的执行主体为用户设备(User Equipment，UE)，UE可以是固定的也可以是移动的，可以为蜂窝电话、个人数字助理(PDA)、无线调制解调器、平板电脑、笔记本电脑、无绳电话等。如图3所示，本实施例包括：

S11：UE在待用态下收到来自于目标基站的核心网寻呼消息。

核心网寻呼消息包括UE的核心网标识。

UE处于待用态(RRC_INACTIVE)下时，已为UE配置的通知区(以下可简称通知区)中的基站会先进行无线接入网(Radio Access Network，RAN)寻呼，RAN寻呼失败之后再由核心网通知跟踪区中的所有基站进行核心网寻呼。UE没有收到RAN寻呼消息而收到了核心网寻呼消息说明RAN寻呼已经失败。本实施例中目标基站是指成功寻呼到UE的基站，也就是UE在收到寻呼消息时驻留的基站。

目标基站可以属于已配置给UE的通知区，例如RAN寻呼过程中UE处于较差的无线环境(例如进入隧道、周围有强干扰等)中，RAN寻呼失败核心网寻呼开始后UE所处的无线环境才改善到可以接收核心网寻呼消息。目标基站可以不属于已配置给UE的通知区，例如RAN寻呼过程中UE还未收到RAN寻呼消息就已经离开通知区。

S12：UE判断目标基站是否属于已配置给UE的通知区。

若目标基站属于已配置给UE的通知区，则意味着UE仍然位于通知区内，跳转到S13；若目标基站不属于已配置给UE的通知区，则意味着UE已经离开通知区，跳转到S14。

S13：UE在待用态下恢复与目标基站的连接以从待用态变为连接态。

由于UE仍然位于通知区内，且在本实施例中核心网和锚基站仍然保留着UE的CN-RAN连接关系和UE context，虽然收到的是核心网寻呼消息，UE可以按照收到RAN寻呼消息的方式进行响应，即直接恢复与目标基站的连接而直接从RRC_INACTIVE状态变为连接态(RRC_CONNECTED)无需进入空闲态(RRC_IDLE)。目标基站可以是通知区内的任意一个基站。

S14：UE进入空闲态后与目标基站建立连接以从空闲态变为连接态。

目标基站不属于通知区，意味着无法保证目标基站与锚基站之间存在接口，虽然锚基站仍旧保留了UE context，目标基站不一定能从锚基站获取UE context，因此可以按照现有技术中RRC_INACTIVE状态下的UE收到核心网寻呼消息的方式进行处理。具体的，UE进入RRC_IDLE状态，然后与目标基站建立连接以从RRC_IDLE状态变为RRC_CONNECTED状态，其信令开销与现有技术相似。

通过本实施例的实施，在RAN寻呼失败但UE仍处于通知区内的情况下，已配置的通知区内的基站进行核心网寻呼，但UE收到核心网寻呼消息直接恢复与目标基站的连接，可以直接从RRC_INACTIVE变为RRC_CONNECTED而不用进入RRC_IDLE，从而减少信令开销和处理开销。

如图4所示，本发明寻呼方法第二实施例，是在本发明寻呼方法第一实施例的基础上，S13包括：

S131：UE向目标基站发送连接恢复请求。

连接恢复请求为包括UE的接入网标识(RAN UE ID)且其中的原因值(causeValue)为寻呼响应(mt-Access)的RRCConnectionResumeRequest，即RRC连接恢复请求，与现有技术中RAN寻呼成功流程中UE发送的消息3类似。

由于已经开始核心网寻呼，UE收到的寻呼消息中包括的是其核心网标识(CN UEID)，而上报的连接恢复请求中包括的是其RAN UE ID，目标基站可以自行或者通过锚基站将UE的CN UE ID和RAN UE ID进行匹配以确认UE被找到。

S132：UE接收来自于目标基站的连接恢复信令。

S133：UE响应连接恢复信令以从待用态变为连接态。

本发明寻呼方法第三实施例的执行主体为基站，本实施例中作为锚基站。基站连接核心网并与UE进行无线通信，为相应的地理区域提供通信覆盖。基站可以为宏基站、微(micro)基站、微微(pico)基站或家庭基站(femtocell)。在一些实施例中，基站也可以被称为无线基站、接入点、B节点，演进型B节点(eNodeB,eNB)，gNB或其他合适的术语。如图5所示，本实施例包括：

S21：锚基站执行RAN寻呼以寻呼UE并通知所在的通知区中的基站执行RAN寻呼以寻呼UE。

UE处于RRC_INACTIVE。锚基站保持有UE的CN-RAN连接关系并存储UE context，但并不知道UE当前驻留在哪个基站，因此在收到来自核心网的下行数据后需要进行RAN寻呼来寻找UE。RAN寻呼可以包括多次发送RAN寻呼消息，RAN寻呼消息中可以包括UE的RAN UEID。

RAN寻呼消息一般是周期性发送的，发送周期和发送次数可以由锚基站指定，从而确定RAN寻呼的总时长T。RAN寻呼过程中，锚基站能够确认UE是否被找到。如果UE被找到时驻留在锚基站，则锚基站能够直接收到UE的连接恢复请求；如果UE被找到时驻留在通知区内除锚基站之外的其他基站，则该基站会向锚基站请求取回UE context。

S22：RAN寻呼失败后，锚基站向核心网发送RAN寻呼失败消息。

RAN寻呼失败消息可以用于指示核心网保留UE的CN-RAN连接关系和UE上下文(context)，并且通知跟踪区中所有基站执行核心网寻呼以寻呼UE。

RAN寻呼的总时长T过去后，即所有的RAN寻呼消息都已经发送完成后，如果锚基站始终未收到被寻呼UE的连接恢复请求或取回UE context的请求，则意味着RAN寻呼失败。锚基站需要通知核心网RAN寻呼失败。此外，为了保证UE仍位于通知区内的情况下能够不进入RRC_IDLE状态而直接恢复连接，锚基站和核心网应保留UE的CN-RAN连接关系和UEcontext。

S23：锚基站执行核心网寻呼以寻呼UE。

在此之前锚基站可以接收来自于核心网的执行核心网寻呼的通知。核心网寻呼可以包括多次发送核心网寻呼消息，核心网寻呼消息可以包括UE的CN UE ID。

S24：锚基站接收来自于UE的连接恢复请求；

本实施例中，UE在收到寻呼消息时驻留在锚基站，且锚基站属于已配置的通知区。连接恢复请求可以为包括UE的RAN UE ID且causeValue为mt-Acces的RRCConnectionResumeRequest，即RRC连接恢复请求。由于连接恢复请求包括的是UE的RANUE ID，锚基站需要对UE的CN UE ID和RAN UE ID进行匹配以确认UE被找到。

S25：锚基站向UE发送连接恢复信令以将UE从待用态变为连接态。

通过本实施例的实施，在RAN寻呼失败但UE仍处于通知区内的情况下，已配置的通知区内的基站进行核心网寻呼，但UE收到核心网寻呼消息直接恢复与目标基站的连接，可以直接从RRC_INACTIVE变为RRC_CONNECTED而不用进入RRC_IDLE，从而减少信令开销和处理开销。

如图6所示，本发明寻呼方法第四实施例的执行主体为基站，本实施例中作为锚基站。本实施例与本发明寻呼方法第三实施例的主要区别在于UE在收到寻呼消息时驻留的目标基站与锚基站不同，与本发明寻呼方法第三实施例相同的部分在此不再重复。本实施例包括：

S26：锚基站执行RAN寻呼以寻呼UE并通知所在的通知区中的基站执行RAN寻呼以寻呼UE。

S27：RAN寻呼失败后，锚基站向核心网发送RAN寻呼失败消息。

S28：锚基站执行核心网寻呼以寻呼UE。

S29：锚基站协助目标基站将UE从待用态变为连接态。

由于目标基站不是锚基站，可能没有存储UE context。锚基站可以将UE context发给目标基站以协助目标基站与UE恢复连接。

具体的，如图7所示，如果由目标基站自身对UE的CN UE ID和RAN UE ID进行匹配，则本步骤可以包括：

S291：锚基站接收来自于目标基站的取回UE context的请求。

S292：锚基站向目标基站发送取回UE context响应消息。

取回UE context响应消息可以包括UE context。

具体的，如图8所示，如果由锚基站对UE的CN UE ID和RAN UE ID进行匹配，则本步骤可以包括：

S296：锚基站接收来自于目标基站的取回UE context的请求。

取回UE context请求中可以包括UE的RAN UE ID。

S297：锚基站将UE的CN UE ID和RAN UE ID进行匹配。

若匹配成功，则跳转到S298。

S298：锚基站向目标基站发送取回UE context响应消息。

通过本实施例的实施，在RAN寻呼失败但UE仍处于通知区内的情况下，已配置的通知区内的基站进行核心网寻呼，但UE收到核心网寻呼消息直接恢复与目标基站的连接，可以直接从RRC_INACTIVE变为RRC_CONNECTED而不用进入RRC_IDLE，从而减少信令开销和处理开销。

如图9所示，本发明寻呼方法第五实施例的执行主体为基站，本实施例中作为目标基站。本实施例包括：

S31：目标基站执行RAN寻呼以寻呼UE。

UE处于RRC_INACTIVE。RAN寻呼包括多次发送RAN寻呼消息，RAN寻呼消息包括UE的RAN UE ID。RAN寻呼消息一般是周期性发送的，发送周期和发送次数可以由锚基站指定，从而确定RAN寻呼的总时长T。

在执行RAN寻呼之前，目标基站可以接收来自于锚基站的执行RAN寻呼的通知以及转发的下行数据。

S32：RAN寻呼失败后，目标基站执行核心网寻呼以寻呼UE。

RAN寻呼失败后，锚基站和核心网应保留UE的CN-RAN连接关系和UE context。

核心网寻呼包括多次发送核心网寻呼消息，核心网寻呼消息包括UE的CN UE ID。在执行核心网寻呼之前，目标基站可以接收来自于核心网的执行核心网寻呼的通知。

S33：目标基站接收来自于UE的连接恢复请求。

本实施例中，UE在收到寻呼消息时驻留在目标基站，目标基站属于已配置的通知区，且目标基站与锚基站不同。连接恢复请求可以为包括UE的RAN UE ID且causeValue为mt-Acces的RRCConnectionResumeRequest，即RRC连接恢复请求。

S34：目标基站向UE发送连接恢复信令以将UE从待用态变为连接态。

通过本实施例的实施，在RAN寻呼失败但UE仍处于通知区内的情况下，已配置的通知区内的基站进行核心网寻呼，但UE收到核心网寻呼消息直接恢复与目标基站的连接，可以直接从RRC_INACTIVE变为RRC_CONNECTED而不用进入RRC_IDLE，从而减少信令开销和处理开销。

如图10所示，本发明寻呼方法第六实施例，是在本发明寻呼方法第五实施例的基础上，S33之后，S34之前进一步包括：

S35：目标基站将RAN UE ID与CN UE ID进行匹配。

若匹配成功，则执行后续步骤，即向UE发送连接恢复信令。

本实施例中由目标基站对UE的RAN UE ID和CN UE ID进行匹配，在其他实施例中，也可以由锚基站进行匹配。

如图11所示，本发明寻呼方法第七实施例，是在本发明寻呼方法第五实施例的基础上，S33之后，S34之前进一步包括：

S36：目标基站向锚基站发送取回UE context的请求。

S37：目标基站接收来自于锚基站的取回UE context响应消息。

取回UE context响应消息可以包括UE context。

如果目标基站没有存储UE context，则在恢复与UE的连接之前需要执行上述步骤。

本实施例可以与本发明寻呼方法第六实施例相结合，此时S36和S37可以在S35和S34之间执行。

下面结合附图12-14举例说明UE驻留在不同基站的情况下收到RAN寻呼消息后自行决定如何响应的具体信令交互过程，其中与前述实施例相同的部分在此不再重复。

如图12所示，在本发明寻呼方法第八实施例中，RAN寻呼失败且UE收到核心网寻呼消息时驻留在锚基站。为了便于示意，图中未画出通知区/跟踪区中除锚基站之外的其他基站，实际基站数量可以更多。本实施例包括：

S101：核心网向锚基站发送下行数据。

S102：锚基站进行RAN寻呼但失败了。

S103：锚基站向核心网发送寻呼失败消息。

S104：核心网向锚基站发送核心网寻呼通知。

核心网保留了UE的CN-RAN连接关系和UE context。核心网寻呼通知用于指示锚基站执行核心网寻呼。

S105：锚基站向UE发送核心网寻呼消息。

S106：UE确认锚基站属于通知区。

S107：UE向锚基站发送消息1：随机接入前导(preamble)。

启动随机接入。

S108：锚基站向UE发送消息2：随机接入响应。

S109：UE向锚基站发送消息3：RRCConnectionResumeRequest。

RRCConnectionResumeRequest可以包括UE的RAN UE ID，且其中的causeValue可以为mt-Acces。

由于锚基站存储了UE context，因此无需从其他基站取回UE context。

S110：锚基站对UE的RAN UE ID和CN UE ID进行匹配。

匹配成功后执行后续步骤。

S111：锚基站向UE发送消息4：RRCConnectionResume。

之后UE从RRC_INACTIVE转换为RRC_CONNECTED。

S112：UE向锚基站发送消息5：RRCConnectionResumeComplete。

如图13所示，在本发明寻呼方法第九实施例中，RAN寻呼失败且UE收到核心网寻呼消息时驻留的目标基站属于通知区但与锚基站不同。为了便于示意，图中未画出通知区/跟踪区中除目标基站和锚基站之外的其他基站，实际基站数量可以更多。本实施例包括：

S201：核心网向锚基站发送下行数据。

S202：锚基站向目标基站发送RAN寻呼通知。

RAN寻呼通知用于指示目标基站执行RAN寻呼。

S203：锚基站进行RAN寻呼但失败了。

S204：目标基站进行RAN寻呼但失败了。

S203和S204之间的执行顺序仅为示意。

S205：锚基站向核心网发送寻呼失败消息。

S206：核心网向锚基站和目标基站发送核心网寻呼通知。

核心网保留了UE的CN-RAN连接关系和UE context。核心网寻呼通知用于指示执行核心网寻呼。

S207：锚基站发送核心网寻呼消息但UE未收到。

S208：UE收到目标基站发送的核心网寻呼消息。

S207和S208-S214之间的执行顺序仅为示意。

S209：UE确认目标基站属于通知区。

S210：UE向目标基站发送消息1：随机接入preamble。

启动随机接入。

S211：目标基站向UE发送消息2：随机接入响应。

S212：UE向目标基站发送消息3：RRCConnectionResumeRequest。

RRCConnectionResumeRequest可以包括UE的RAN UE ID，且其中的causeValue可以为mt-Acces。

S213：目标基站对UE的RAN UE ID和CN UE ID进行匹配。

本实施例中由目标基站进行ID匹配，在其他实施例中，也可以由锚基站在收到取回UE context请求对UE的RAN UE ID和CN UE ID进行匹配。

匹配成功后执行后续步骤。

S214：目标基站向锚基站发送取回UE context请求。

由于目标基站未存储UE context，因此需要从锚基站取回UE context。

S215：锚基站向目标基站发送取回UE context响应消息。

S216：目标基站向UE发送消息4：RRCConnectionResume。

之后UE从RRC_INACTIVE转换为RRC_CONNECTED。

S217：UE向目标基站发送消息5：RRCConnectionResumeComplete。

S218：目标基站进行路径切换。

如图14所示，在本发明寻呼方法第十实施例中，RAN寻呼失败且UE收到核心网寻呼消息时驻留的目标基站不属于通知区。为了便于示意，图中未画出通知区/跟踪区中除目标基站和锚基站之外的其他基站，实际基站数量可以更多。本实施例包括：

S301：核心网向锚基站发送下行数据。

S302：锚基站进行RAN寻呼但失败了。

S303：锚基站向核心网发送寻呼失败消息。

S304：核心网向锚基站和目标基站发送核心网寻呼通知。

核心网保留了UE的CN-RAN连接关系和UE context。核心网寻呼通知用于指示执行核心网寻呼。

S305：锚基站发送核心网寻呼消息但UE未收到。

S306：UE收到目标基站发送的核心网寻呼消息。

S305和S306-S315之间的执行顺序仅为示意。

S307：UE确认目标基站不属于通知区。

之后UE进入RRC_IDLE状态。

S308：UE向目标基站发送消息1：随机接入preamble。

启动随机接入。

S309：目标基站向UE发送消息2：随机接入响应。

S310：UE向目标基站发送消息3：RRCConnectionRequest。

RRCConnectionRequest中的causeValue可以为mt-Acces。

S311：目标基站向UE发送消息4：RRCConnectionSetup。

之后UE从RRC_IDLE转换为RRC_CONNECTED。

S312：UE向锚基站发送消息5：RRCConnectionSetupComplete。

S313：目标基站向核心网发送初始UE消息。

S314：核心网释放旧的UE context和CN-RAN连接关系。

S315：核心网通知锚基站释放旧的UE context和CN-RAN连接关系。

S316：核心网向目标基站发送上下文建立请求。

S317：目标基站向UE发送消息6：RRCConnectionReconfiguration。

S318：UE向目标基站发送消息7：RRCConnectionReconfigurationComplete。

S319：目标基站向核心网发送上下文建立响应消息。

S320：核心网修改承载。

如图15所示，本发明寻呼方法第十一实施例的执行主体为基站，且基站属于已经为UE配置的通知区，本实施例包括：

S41：基站执行RAN寻呼以寻呼UE。

UE处于RRC_INACTIVE状态。锚基站保持有UE的CN-RAN连接关系并存储UEcontext，但并不知道UE当前驻留在哪个基站，因此在收到来自核心网的下行数据后需要进行RAN寻呼来寻找UE。基站可以是锚基站，也可以不是。

为了便于区分，我们将由锚基站发起的通知区范围内的寻呼称为第一轮寻呼；由核心网发起的跟踪区范围内的寻呼称为第二轮寻呼。本步骤中的RAN寻呼属于第一轮。

RAN寻呼可以包括多次发送RAN寻呼消息，RAN寻呼消息包括UE的RAN UE ID。RAN寻呼消息一般是周期性发送的，发送周期和发送次数可以由锚基站指定，从而确定第一轮RAN寻呼的总时长T。

S42：RAN寻呼失败后，基站继续进行RAN寻呼而不是核心网寻呼以寻呼UE。

在第二轮寻呼过程中，锚基站和核心网仍然保留UE的CN-RAN连接关系和UEcontext，通知区内的基站继续进行RAN寻呼，而通知区外跟踪区内的基站进行核心网寻呼。核心网寻呼包括多次发送核心网寻呼消息，核心网寻呼消息包括UE的CN UE ID。

假设UE仍然位于通知区内，且在第二轮寻呼过程中才接收到寻呼消息，这种情况下UE收到的仍然是包括其RAN UE ID的RAN寻呼消息，UE和找到它的目标基站可以按照标准的RAN寻呼成功的流程进行交互而恢复与目标基站的连接，从而直接从RRC_INACTIVE变为RRC_CONNECTED。

假设UE位于通知区外，且在第二轮寻呼过程中才接收到寻呼消息，这种情况下UE收到的是核心网寻呼消息，可以按照现有技术中RRC_INACTIVE状态下的UE收到核心网寻呼消息的方式进行处理。具体的，UE进入RRC_IDLE状态，然后与目标基站建立连接以从RRC_IDLE状态变为RRC_CONNECTED状态，其信令开销与现有技术相似。

通过本实施例的实施，在RAN寻呼失败但UE仍处于通知区内的情况下，通知区内的基站可以继续进行RAN寻呼而不是核心网寻呼，使得UE和找到它的目标基站可以按照标准的RAN寻呼成功的流程进行交互，UE可以直接从RRC_INACTIVE变为RRC_CONNECTED而不用进入RRC_IDLE状态，从而减少信令开销和处理开销。

如图16所示，本发明寻呼方法第十二实施例，是在本发明寻呼方法第十一实施例的基础上，基站不是通知区的锚基站。本实施例是对本发明寻呼方法第十一实施例的进一步扩展，与其相同的部分在此不再重复。本实施例包括：

S411：基站接收来自于锚基站的执行RAN寻呼的通知。

除了通知之外，基站还可以接收锚基站转发的下行数据。

S412：基站执行RAN寻呼以寻呼UE。

S413：RAN寻呼失败后，基站接收来自于锚基站的继续进行RAN寻呼的通知。

S414：基站继续进行RAN寻呼而不是核心网寻呼以寻呼UE。

如图17所示，本发明寻呼方法第十三实施例，是在本发明寻呼方法第十一实施例的基础上，基站是通知区的锚基站。本实施例是对本发明寻呼方法第十一实施例的进一步扩展，与其相同的部分在此不再重复。本实施例包括：

S421：基站执行RAN寻呼以寻呼UE并向通知区中的基站发送执行RAN寻呼的通知。

S422：RAN寻呼失败后，基站向核心网发送RAN寻呼失败消息。

第一轮RAN寻呼的总时长T过去后，即所有的RAN寻呼消息都已经发送完成后，如果锚基站始终未收到被寻呼UE的连接恢复请求或取回UE context的请求，则意味着RAN寻呼失败。

RAN寻呼失败消息用于指示核心网保留UE的上下文，通知跟踪区中除通知区中的基站之外的其他基站执行核心网寻呼以寻呼UE且不通知通知区中的基站进行核心网寻呼。

S423：基站继续进行RAN寻呼而不是核心网寻呼以寻呼UE，并向通知区中的基站发送继续进行RAN寻呼的通知。

如图18所示，本发明寻呼方法第十四实施例的执行主体为核心网，本实施例包括：

S51：核心网接收来自于锚基站的RAN寻呼失败消息。

RAN寻呼失败消息用于指示核心网保留UE的上下文且通知跟踪区中除通知区中的基站之外的其他基站执行核心网寻呼以寻呼UE。

S52：核心网响应RAN寻呼失败消息保留被寻呼的UE的上下文，通知跟踪区中除锚基站所在的通知区中的基站之外的其他基站执行核心网寻呼，并且不通知锚基站所在的通知区中的基站执行核心网寻呼。

核心网寻呼包括多次发送核心网寻呼消息，核心网寻呼消息包括UE的CN UE ID，RAN寻呼包括多次发送RAN寻呼消息，RAN寻呼消息包括UE的RAN UE ID。

具体的，核心网可以不通知锚基站所在的通知区中的基站执行核心网寻呼，而由锚基站通知该通知区中的基站继续进行RAN寻呼。

通过本实施例的实施，在RAN寻呼失败但UE仍处于通知区内的情况下，通知区内的基站可以继续进行RAN寻呼而不是核心网寻呼，使得UE和找到它的目标基站可以按照标准的RAN寻呼成功的流程进行交互，UE可以直接从RRC_INACTIVE变为RRC_CONNECTED而不用进入RRC_IDLE状态，从而减少信令开销和处理开销。

下面结合附图19-21举例说明UE驻留在不同基站的情况下第一轮RAN寻呼失败后通知区内的基站继续进行RAN寻呼而跟踪区内通知区外的基站进行核心网寻呼的具体信令交互过程，其中与前述实施例相同的部分在此不再重复。为了便于示意，图19-21中只画出了两个基站：基站1和基站2，其中基站1位于通知区内，基站2位于跟踪区内通知区外，实际基站数量可以更多。

如图19所示，在本发明寻呼方法第十五实施例中，第二轮寻呼中UE被通知区内的基站1找到，且基站1是锚基站。本实施例包括：

S431：核心网向基站1发送下行数据。

S432：基站1向通知区内的其他基站发送RAN寻呼通知。

RAN寻呼通知用于指示执行RAN寻呼。

S433：基站1进行RAN寻呼但失败了。

S434：基站1向核心网发送寻呼失败消息。

S435：基站1向通知区内的其他基站发送继续进行RAN寻呼的通知。

核心网保留了UE的CN-RAN连接关系和UE context。

S436：核心网向基站2发送核心网寻呼通知。

核心网寻呼通知用于指示执行核心网寻呼。

S437：基站2发送核心网寻呼消息但UE未收到。

S438：UE收到基站1发送的RAN寻呼消息。

S435/S438和S436-S437之间的执行顺序并无限制。

S439：UE向基站1发送消息1：随机接入preamble。

启动随机接入。

S440：基站1向UE发送消息2：随机接入响应。

S441：UE向基站1发送消息3：RRCConnectionResumeRequest。

RRCConnectionResumeRequest可以包括UE的RAN UE ID，且其中的causeValue可以为mt-Acces。

由于基站1作为锚基站存储了UE context，因此无需从其他基站取回UE context。

S442：基站1向UE发送消息4：RRCConnectionResume。

之后UE从RRC_INACTIVE转换为RRC_CONNECTED。

S443：UE向基站1发送消息5：RRCConnectionResumeComplete。

如图20所示，在本发明寻呼方法第十六实施例中，第二轮寻呼中UE被通知区内的基站1找到，且基站1不是锚基站。本实施例包括：

S451：基站1接收来自于锚基站的核心网寻呼通知。

S452：基站1进行RAN寻呼但失败了。

S453：基站1接收来自于锚基站的继续进行RAN寻呼的通知。

核心网保留了UE的CN-RAN连接关系和UE context。

S454：核心网向基站2发送核心网寻呼通知。

核心网寻呼通知用于指示执行核心网寻呼。

S455：基站2发送核心网寻呼消息但UE未收到。

S456：UE收到基站1发送的RAN寻呼消息。

S453/S456和S454-S455之间的执行顺序并无限制。

S457：UE向基站1发送消息1：随机接入preamble。

启动随机接入。

S458：基站1向UE发送消息2：随机接入响应。

S459：UE向基站1发送消息3：RRCConnectionResumeRequest。

RRCConnectionResumeRequest可以包括UE的RAN UE ID，且其中的causeValue可以为mt-Acces。

S460：基站1从锚基站取回UE context。

基站1不是锚基站，未存储UE context，需要从锚基站取回UE context。

S461：基站1向UE发送消息4：RRCConnectionResume。

之后UE从RRC_INACTIVE转换为RRC_CONNECTED。

S462：UE向基站1发送消息5：RRCConnectionResumeComplete。

S463：基站1执行路径切换。

如图21所示，在本发明寻呼方法第十七实施例中，第二轮寻呼中UE被通知区外的基站2找到，且基站1是锚基站。本实施例包括：

S501：核心网向基站1发送下行数据。

S502：基站1向通知区内的其他基站发送RAN寻呼通知。

RAN寻呼通知用于指示执行RAN寻呼。

S503：基站1进行RAN寻呼但失败了。

S504：锚基站向核心网发送寻呼失败消息。

S505：基站1向通知区内的其他基站发送继续进行RAN寻呼的通知。

S505和S506/S508之间的执行顺序并无限制。

S506：核心网向基站2发送核心网寻呼通知。

核心网保留了UE的CN-RAN连接关系和UE context。

核心网寻呼通知用于指示执行核心网寻呼。

S507：基站1发送RAN寻呼消息但UE未收到。

S507和S506/S508-S514之间的执行顺序并无限制。

S508：UE收到基站2发送的核心网寻呼消息。

之后UE进入RRC_IDLE状态。

S509：UE向基站2发送消息1：随机接入preamble。

启动随机接入。

S510：基站2向UE发送消息2：随机接入响应。

S511：UE向基站2发送消息3：RRCConnectionRequest。

RRCConnectionRequest中的causeValue可以为mt-Acces。

S512：基站2向UE发送消息4：RRCConnectionSetup。

之后UE从RRC_IDLE转换为RRC_CONNECTED。

S513：UE向锚基站发送消息5：RRCConnectionSetupComplete。

S514：基站2向核心网发送初始UE消息。

S515：核心网释放旧的UE context和CN-RAN连接关系。

S516：核心网通知基站1释放旧的UE context和CN-RAN连接关系。

S517：核心网向基站2发送上下文建立请求。

S518：基站2向UE发送消息6：RRCConnectionReconfiguration。

S519：UE向基站2发送消息7：RRCConnectionReconfigurationComplete。

S520：基站2向核心网发送上下文建立响应消息。

S521：核心网修改承载。

如图22所示，本发明寻呼方法第十八实施例的执行主体为基站，且在本实施例中作为锚基站。本实施例包括：

S61：锚基站执行RAN寻呼以寻呼UE并通知所在的通知区中的基站执行RAN寻呼以寻呼UE。

UE处于RRC_INACTIVE。锚基站保持有UE的CN-RAN连接关系并存储UE context，但并不知道UE当前驻留在哪个基站，因此在收到来自核心网的下行数据后需要进行RAN寻呼来寻找UE。RAN寻呼可以包括多次发送RAN寻呼消息，RAN寻呼消息中可以包括UE的RAN UEID。RAN寻呼消息一般是周期性发送的，发送周期和发送次数可以由锚基站指定，从而确定RAN寻呼的总时长T。

除了通知之外，锚基站还可以向通知区中的基站转发收到的下行数据。

S62：RAN寻呼过程中，锚基站在未收到UE的寻呼响应情况下接收来自于UE的原因值为基于接入网的位置区域更新(RAN-based Location Area Update，RLAU)的连接恢复请求。

UE的寻呼响应可以包括来自于UE的原因值为mt-Access的连接恢复请求(UE驻留的目标基站是锚基站时)，或者来自于UE驻留的目标基站响应来自于UE的原因值为mt-Access的连接恢复请求而发送的取回UE context请求(UE驻留的目标基站不是锚基站时)。

原因值为RLAU的连接恢复请求，简称RLAU请求，可以为包括UE的RAN UE ID且causeValue为接入网区域更新(ranAreaUpdate)的RRCConnectionResumeRequest，即RRC连接恢复请求，与现有技术中RAN寻呼成功流程中UE发送的消息3不同。

在RAN寻呼过程中，即在总时长T内，可能出现UE原本处于较差的无线环境(例如进入隧道、周围有强干扰等)中，无法接收到RAN寻呼消息，当UE的无线环境改善时，还没有接收到RAN寻呼消息就开始了RLAU过程。本实施例中的UE驻留的基站为锚基站，RLAU可以为周期性的。

S63：锚基站向UE发送连接恢复信令以将UE从待用态变为连接态。

连接恢复信令可以为RRCConnectionResume，即RRC连接恢复。

现有技术中，锚基站会响应RLAU请求向UE发送RRCConnectionSuspend，以将UE保持在RRC_INACTIVE状态。如果保持在RRC_INACTIVE状态的UE随后收到了RAN寻呼消息，则可以按照标准的RAN寻呼成功流程从RRC_INACTIVE状态转变为RRC_CONNECTED状态，这中间存在一段保持RRC_INACTIVE状态的时间，会带来额外的寻呼延迟，并造成额外的信令开销。反之如果保持在RRC_INACTIVE状态的UE随后无法接收RAN寻呼消息，例如RLAU请求是在RAN寻呼消息发送之后，T结束之前发起的，则RAN寻呼会失败而需要执行核心网寻呼，带来额外的信令开销和处理开销。

通过本实施例的实施，在RAN寻呼过程中，若UE未收到RAN寻呼消息时开始了RLAU过程，锚基站收到RLAU请求后不是向UE发送连接暂停以完成RLAU而是发送连接恢复信令以将UE从RRC_INACTIVE变为RRC_CONNECTED，省去了保持RRC_INACTIVE的过程，并降低了RAN寻呼失败的概率，从而减少信令开销和处理开销。

如图23所示，本发明寻呼方法第十九实施例的执行主体为基站，且在本实施例中作为锚基站。本实施例与本发明寻呼方法第十八实施例的主要区别在于目标基站与锚基站不同，与本发明寻呼方法第十八实施例相同的部分在此不再重复。本实施例包括：

S66：锚基站执行RAN寻呼以寻呼UE并通知所在的通知区中的基站执行RAN寻呼以寻呼UE。

S67：RAN寻呼过程中，锚基站在未收到UE的寻呼响应的情况下接收来自于目标基站的取回UE context的请求。

取回UE context的请求是目标基站响应来自于UE的RLAU请求而发送的。RLAU请求的具体描述可参考前一实施例中的相关内容。

UE的寻呼响应可以包括来自于UE的原因值为mt-Access的连接恢复请求(UE驻留的目标基站是锚基站时)，或者来自于UE驻留的目标基站响应来自于UE的原因值为mt-Access的连接恢复请求而发送的取回UE context请求(UE驻留的目标基站不是锚基站时)。

本实施例中的目标基站是指UE发起RLAU过程时驻留的基站。目标基站可以与锚基站属于同一通知区，这种情况下的RLAU为周期性的。目标基站可以与锚基站可以属于不同通知区，这种情况下RLAU为移动性触发的。

取回UE context的请求包括接入网区域更新标记，接入网区域更新标记用于指示UE正在请求基于接入网的位置区域更新。不同类型的RLAU对应的取回UE context的请求中的配置值可以是不同的。

S68：锚基站向目标基站发送取回UE context响应消息以协助目标基站将UE从待用态变为连接态。

取回UE context响应消息包括寻呼标记及UE context，寻呼标记用于指示UE正在被锚基站所在的通知区进行RAN寻呼，以通知目标基站向UE发送连接恢复信令而不是RRCConnectionSuspend。

可选的，如果目标基站与锚基站属于不同通知区，本步骤之后锚基站可以向目标基站转发来自于核心网的下行数据。

通过本实施例的实施，在RAN寻呼过程中，若UE未收到RAN寻呼消息时开始了RLAU过程，目标基站收到RLAU请求后不是向UE发送连接暂停以完成RLAU而是发送连接恢复信令以将UE从RRC_INACTIVE变为RRC_CONNECTED，如果UE驻留在的基站属于通知区，则省去了保持RRC_INACTIVE的过程，减少信令开销，如果目标基站不属于通知区，现有技术中RAN寻呼会失败需要执行核心网寻呼，而本实施例能够在RAN寻呼过程中成功找到UE而无需执行核心网寻呼，降低了RAN寻呼失败的概率，减少信令开销和处理开销。

如图24所示，本发明寻呼方法第二十实施例的执行主体为基站，且在本实施例中作为目标基站。本实施例包括：

S71：目标基站接收来自于待用态下的UE的RLAU请求。

目标基站可以与锚基站属于同一通知区，这种情况下的RLAU为周期性的，且目标基站可能正处于RAN寻呼该UE的过程中。目标基站可以与锚基站可以属于不同通知区，这种情况下RLAU为移动性触发的，且目标基站并未寻呼该UE。

RLAU请求可以为包括UE的RAN UE ID且causeValue为ranAreaUpdate的RRCConnectionResumeRequest，即RRC连接恢复请求，与现有技术中RAN寻呼成功流程中UE发送的消息3不同。

S72：目标基站响应RLAU请求向锚基站发送取回UE context的请求。

目标基站未存储UE context，需要从锚基站取回UE context以完成后续过程。取回UE context的请求可以包括接入网区域更新标记，接入网区域更新标记用于指示UE正在请求基于接入网的位置区域更新。不同类型的RLAU对应的取回UE context的请求中的配置值可以是不同的。

S73：目标基站接收来自于锚基站的取回UE context响应消息。

取回UE context响应消息可以包括寻呼标记及UE context，，寻呼标记用于指示UE正在被锚基站所在的通知区进行RAN寻呼。

如果目标基站和锚基站不属于同一通知区，本步骤后目标基站可以接收锚基站转发的由核心网发给锚基站的下行数据。

S74：目标基站向UE发送连接恢复信令以将UE从待用态变为连接态。

连接恢复信令为RRCConnectionResume，即RRC连接恢复。

具体内容可参考本发明寻呼方法第十九和二十实施例的描述。

通过本实施例的实施，在RAN寻呼过程中，若UE未收到RAN寻呼消息时开始了RLAU过程，目标基站收到RLAU请求后不是向UE发送连接暂停以完成RLAU而是发送连接恢复信令以将UE从RRC_INACTIVE变为RRC_CONNECTED，如果UE驻留在的基站属于通知区，则省去了保持RRC_INACTIVE的过程，并降低了RAN寻呼失败的概率，从而减少信令开销和处理开销，如果目标基站不属于通知区，现有技术中RAN寻呼会失败需要执行核心网寻呼，而本实施例能够在RAN寻呼过程中成功找到UE而无需执行核心网寻呼，降低了RAN寻呼失败的概率，减少信令开销和处理开销。

如图25所示，本发明寻呼方法第二十一实施例，是在本发明寻呼方法第二十实施例的基础上，S71之前进一步包括：

S75：目标基站接收来自于锚基站的执行RAN寻呼的通知。

本实施例中目标基站与锚基站属于同一通知区。除了通知之外，目标基站还可以接收锚基站转发的由核心网发给锚基站的下行数据。

S76：目标基站响应通知执行RAN寻呼以寻呼UE。

如图26所示，本发明寻呼方法第二十二实施例的执行主体为UE。本实施例包括：

S81：处于待用态的UE在未收到RAN寻呼消息的情况下向目标基站发送RLAU请求。

在RAN寻呼过程中，即在总时长T内，可能出现UE原本处于较差的无线环境(例如进入隧道、周围有强干扰等)中，无法接收到RAN寻呼消息，当UE的无线环境改善时，还没有接收到RAN寻呼消息就开始了RLAU过程。

本实施例中的目标基站是指UE发起RLAU过程时驻留的基站。目标基站可以属于通知区，这种情况下的RLAU为周期性的，且目标基站可以是锚基站，也可以不是；或者目标基站可以不属于通知区，这种情况下RLAU为移动性触发的。

RLAU请求可以为包括UE的RAN UE ID且causeValue为ranAreaUpdate的RRCConnectionResumeRequest，即RRC连接恢复请求，与现有技术中RAN寻呼成功流程中UE发送的消息3不同。

S82：UE接收来自于目标基站的连接恢复信令。

连接恢复信令可以为RRCConnectionResume，即RRC连接恢复。

S83：UE响应连接恢复信令从待用态进入连接态。

具体内容可参考本发明寻呼方法第十九和二十实施例的描述。

通过本实施例的实施，在RAN寻呼过程中，若UE未收到RAN寻呼消息时开始了RLAU过程，目标基站收到RLAU请求后不是向UE发送连接暂停以完成RLAU而是发送连接恢复信令以将UE从RRC_INACTIVE变为RRC_CONNECTED，如果UE驻留在的基站属于通知区，则省去了保持RRC_INACTIVE的过程，并降低了RAN寻呼失败的概率，从而减少信令开销和处理开销，如果目标基站不属于通知区，现有技术中RAN寻呼会失败需要执行核心网寻呼，而本实施例能够在RAN寻呼过程中成功找到UE而无需执行核心网寻呼，降低了RAN寻呼失败的概率，减少信令开销和处理开销。

下面结合附图27-29举例说明UE未收到RAN寻呼消息时执行RLAU且驻留在不同基站的情况下具体信令交互过程，其中与前述实施例相同的部分在此不再重复。

如图27所示，在本发明寻呼方法第二十三实施例中，UE未收到RAN寻呼消息时执行RLAU且驻留在锚基站。为了便于示意，图中未画出通知区/跟踪区中除锚基站之外的其他基站，实际基站数量可以更多。本实施例包括：

S601：核心网向锚基站发送下行数据。

S602：锚基站广播RAN寻呼消息但UE未收到。

S603：UE向锚基站发送消息1：随机接入preamble。

启动随机接入。

S604：锚基站向UE发送消息2：随机接入响应。

S605：UE向锚基站发送消息3：RRCConnectionResumeRequest。

RRCConnectionResumeRequest作为RLAU请求，包括UE的RAN UE ID且causeValue为ranAreaUpdate。本步骤在RAN寻呼的总时长T内完成。

S606：锚基站向UE发送消息4：RRCConnectionResume。

之后UE从RRC_INACTIVE转换为RRC_CONNECTED。

S607：UE向锚基站发送消息5：RRCConnectionResumeComplete。

如图28所示，在本发明寻呼方法第二十四实施例中，UE未收到RAN寻呼消息时执行RLAU且驻留的目标基站属于通知区但与锚基站不同。为了便于示意，图中未画出通知区/跟踪区中除目标基站和锚基站之外的其他基站，实际基站数量可以更多。本实施例包括：

S701：核心网向锚基站发送下行数据。

S702：锚基站向目标基站发送RAN寻呼通知。

RAN寻呼通知用于指示目标基站执行RAN寻呼。此外锚基站还可以向目标基站转发下行数据。

S703：锚基站进行RAN寻呼。

S704：UE接收到来自于目标基站的RAN寻呼消息。

S703和S704之间的执行顺序仅为示意。

S705：UE向目标基站发送消息1：随机接入preamble。

启动随机接入。

S706：目标基站向UE发送消息2：随机接入响应。

S707：UE向目标基站发送消息3：RRCConnectionResumeRequest。

RRCConnectionResumeRequest作为RLAU请求，包括UE的RAN UE ID且causeValue为ranAreaUpdate。本步骤在RAN寻呼的总时长T内完成。

S708：目标基站对UE进行验证。

验证成功后执行后续步骤。

S709：目标基站向锚基站发送取回UE context请求。

取回UE context请求包括接入网区域更新标记。由于目标基站未存储UEcontext，因此需要从锚基站取回UE context。

S710：锚基站向目标基站发送取回UE context响应消息。

取回UE context响应消息包括寻呼标记。

S711：目标基站进行路径切换。

S712：目标基站通知锚基站释放旧的UE context。

S713：目标基站向UE发送消息4：RRCConnectionResume。

之后UE从RRC_INACTIVE转换为RRC_CONNECTED。

S714：UE向目标基站发送消息5：RRCConnectionResumeComplete。

如图29所示，在本发明寻呼方法第二十五实施例中，UE未收到RAN寻呼消息时执行RLAU且驻留的目标基站不属于通知区。为了便于示意，图中未画出通知区/跟踪区中除目标基站和锚基站之外的其他基站，实际基站数量可以更多。本实施例包括：

S801：核心网向锚基站发送下行数据。

S802：锚基站进行RAN寻呼。

S803：UE向目标基站发送消息1：随机接入preamble。

启动随机接入。

S804：目标基站向UE发送消息2：随机接入响应。

S805：UE向目标基站发送消息3：RRCConnectionResumeRequest。

RRCConnectionResumeRequest作为RLAU请求，包括UE的RAN UE ID且causeValue为ranAreaUpdate。本步骤在RAN寻呼的总时长T内完成。

S806：目标基站对UE进行验证。

验证成功后执行后续步骤。

S807：目标基站向锚基站发送取回UE context请求。

取回UE context请求包括接入网区域更新标记。由于目标基站未存储UEcontext，因此需要从锚基站取回UE context。

S808：锚基站向目标基站发送取回UE context响应消息。

取回UE context响应消息包括寻呼标记。

S809：锚基站向目标基站转发下行数据。

本步骤中的下行数据可以是S801中锚基站从核心网接收的下行数据。

S810：目标基站进行路径切换。

S811：目标基站通知锚基站释放旧的UE context。

S812：目标基站向UE发送消息4：RRCConnectionResume。

之后UE从RRC_INACTIVE转换为RRC_CONNECTED。

S813：UE向目标基站发送消息5：RRCConnectionResumeComplete。

如图30所示，本发明寻呼装置第一实施例包括：处理器110和通信电路120，处理器110连接通信电路120。

通信电路120用于发送和接收用户数据，是寻呼装置与其他通信设备进行通信的接口。

处理器110控制寻呼装置的操作，处理器110还可以称为CPU(Central ProcessingUnit，中央处理单元)。处理器110可能是一种集成电路芯片，具有信号的处理能力。处理器110还可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

处理器110用于执行指令以实现本发明寻呼方法第一、第二以及第二十二实施例中任一个所提供的方法。

本实施例中的寻呼装置可以是UE，也可以是可集成于UE中的独立部件，例如基带芯片。

如图31所示，本发明寻呼装置第二实施例包括：处理器210和通信电路220，处理器210连接通信电路220。

通信电路220用于发送和接收用户数据，是寻呼装置与其他通信设备进行通信的接口。

处理器210控制寻呼装置的操作，处理器110还可以称为CPU(Central ProcessingUnit，中央处理单元)。处理器110可能是一种集成电路芯片，具有信号的处理能力。处理器110还可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

处理器210用于执行指令以实现本发明寻呼方法第三至第七、第十一至第十三、第十八至第二十一实施例中任一个以及任意不冲突的组合所提供的方法。

本实施例中的寻呼装置可以是基站，也可以是可集成于基站中的独立部件，例如基带板。

如图32所示，本发明寻呼装置第三实施例包括：处理器310和通信电路320，处理器310连接通信电路320。

通信电路320用于发送和接收用户数据，是寻呼装置与其他通信设备进行通信的接口。

处理器310控制寻呼装置的操作，处理器110还可以称为CPU(Central ProcessingUnit，中央处理单元)。处理器110可能是一种集成电路芯片，具有信号的处理能力。处理器110还可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

处理器310用于执行指令以实现本发明寻呼方法第十四实施例所提供的方法。

本实施例中的寻呼装置可以是核心网。

如图33所示，本发明寻呼装置第四实施例包括存储器410，存储器410存储有指令，该指令被执行时实现本发明寻呼方法第一、第二以及第二十二实施例中任一个所提供的方法。

存储器410可以包括只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、闪存(Flash Memory)、硬盘、光盘等。

本实施例中的寻呼装置可以是UE，也可以是可集成于UE中的独立部件，例如基带芯片。

如图34所示，本发明寻呼装置第五实施例包括存储器510，存储器510存储有指令，该指令被执行时实现本发明寻呼方法第三至第七、第十一至第十三、第十八至第二十一实施例中任一个以及任意不冲突的组合所提供的方法。

存储器510可以包括只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、闪存(Flash Memory)、硬盘、光盘等。

本实施例中的寻呼装置可以是基站，也可以是可集成于基站中的独立部件，例如基带板。

如图35所示，本发明寻呼装置第6实施例包括存储器610，存储器610存储有指令，该指令被执行时实现本发明寻呼方法第十四实施例中任一个所提供的方法。

存储器610可以包括只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、闪存(Flash Memory)、硬盘、光盘等。

本实施例中的寻呼装置可以是核心网中的一个或更多个网元，也可以是可集成于核心网/网元中的独立部件。

在本发明所提供的几个实施例中，应该理解到，所揭露的方法和装置，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施方式所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本发明的实施方式，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (27)

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

用户设备在待用态下收到来自于目标基站的核心网寻呼消息，所述核心网寻呼消息包括所述用户设备的核心网标识；

所述用户设备判断所述目标基站是否属于已配置给所述用户设备的通知区；

若所述目标基站属于所述通知区，所述用户设备在所述待用态下恢复与所述目标基站的连接以从所述待用态变为连接态，若所述目标基站不属于所述通知区，所述用户设备进入空闲态后与所述目标基站建立连接以从所述空闲态变为所述连接态。

2.根据权利要求1所述的方法，其特征在于，

所述用户设备在所述待用态下恢复与所述目标基站的连接以从所述待用态变为连接态包括：

所述用户设备向所述目标基站发送连接恢复请求；

所述用户设备接收来自于所述目标基站的连接恢复信令；

所述用户设备响应所述连接恢复信令以从所述待用态变为所述连接态。

3.根据权利要求2所述的方法，其特征在于，所述连接恢复请求为包括所述用户设备的接入网标识且原因值为寻呼响应的RRCConnectionResumeRequest，即RRC连接恢复请求。

4.一种寻呼方法，其特征在于，包括：

锚基站执行无线接入网寻呼以寻呼用户设备并通知所在的通知区中的基站执行所述无线接入网寻呼以寻呼所述用户设备，所述无线接入网寻呼包括多次发送无线接入网寻呼消息，所述无线接入网寻呼消息包括所述用户设备的接入网标识；

所述无线接入网寻呼失败后，所述锚基站向核心网发送无线接入网寻呼失败消息，所述无线接入网寻呼失败消息用于指示所述核心网保留所述用户设备的上下文且通知跟踪区中所有基站执行所述核心网寻呼以寻呼所述用户设备；

所述锚基站执行核心网寻呼以寻呼所述用户设备，所述核心网寻呼包括多次发送核心网寻呼消息，所述核心网寻呼消息包括所述用户设备的核心网标识；

所述锚基站接收来自于用户设备的连接恢复请求然后向所述用户设备发送连接恢复信令以将所述用户设备从待用态变为连接态，或所述锚基站协助目标基站将所述用户设备从所述待用态变为所述连接态。

5.根据权利要求4所述的方法，其特征在于，所述连接恢复请求包括所述接入网标识，所述锚基站接收来自于用户设备的连接恢复请求之后，向所述用户设备发送连接恢复信令之前进一步包括：

所述锚基站将所述接入网标识与所述核心网标识进行匹配；

若匹配成功，则所述锚基站向所述用户设备发送所述连接恢复信令。

6.根据权利要求4所述的方法，其特征在于，

所述锚基站协助所述目标基站将所述用户设备从所述待用态变为所述连接态包括：

所述锚基站接收来自于目标基站的取回所述用户设备上下文的请求；

所述锚基站向所述目标基站发送取回所述用户设备上下文响应消息。

7.根据权利要求6所述的方法，其特征在于，

所述取回所述用户设备上下文的请求包括所述接入网标识；所述锚基站向所述目标基站发送取回所述用户设备上下文响应消息之前进一步包括：

所述锚基站将所述接入网标识与所述核心网标识进行匹配；

若匹配成功，则所述锚基站向所述目标基站发送所述取回所述用户设备上下文响应消息。

8.一种寻呼方法，其特征在于，包括：

目标基站执行无线接入网寻呼以寻呼用户设备，所述无线接入网寻呼包括多次发送无线接入网寻呼消息，所述无线接入网寻呼消息包括所述用户设备的接入网标识；

所述无线接入网寻呼失败后，所述目标基站执行核心网寻呼以寻呼所述用户设备，所述核心网寻呼包括多次发送核心网寻呼消息，所述核心网寻呼消息包括所述用户设备的核心网标识；

所述目标基站接收来自于用户设备的连接恢复请求；

所述目标基站向所述用户设备发送连接恢复信令以将所述用户设备从待用态变为连接态。

9.根据权利要求8所述的方法，其特征在于，

所述目标基站向所述用户设备发送连接恢复信令之前进一步包括：

所述目标基站将所述接入网标识与所述核心网标识进行匹配；

若匹配成功，则所述目标基站向所述用户设备发送所述连接恢复信令。

10.根据权利要求8所述的方法，其特征在于，

所述目标基站向所述用户设备发送连接恢复信令之前进一步包括：

所述目标基站向所述锚基站发送取回所述用户设备上下文的请求；

所述目标基站接收来自于所述锚基站的取回所述用户设备上下文响应消息。

11.一种寻呼方法，其特征在于，包括：

锚基站执行无线接入网寻呼以寻呼用户设备并通知所在的通知区中的基站执行所述无线接入网寻呼以寻呼所述用户设备；

所述无线接入网寻呼过程中，所述锚基站在未收到所述用户设备的寻呼响应的情况下接收来自于所述用户设备的原因值为基于接入网的位置区域更新的连接恢复请求然后向所述用户设备发送连接恢复信令以将所述用户设备从待用态变为连接态，或所述锚基站在未收到所述用户设备的寻呼响应的情况下接收来自于目标基站的取回所述用户设备上下文的请求然后向所述目标基站发送取回所述用户设备上下文响应消息以协助所述目标基站将所述用户设备从所述待用态变为所述连接态，所述取回所述用户设备上下文的请求是所述目标基站响应来自于所述用户设备的所述连接恢复请求而发送的。

12.根据权利要求11所述的方法，其特征在于，

所述连接恢复请求为包括所述用户设备的接入网标识且原因值为基于接入网的位置区域更新的RRCConnectionResumeRequest，即RRC连接恢复请求。

13.根据权利要求11所述的方法，其特征在于，

所述连接恢复信令为RRCConnectionResume，即RRC连接恢复。

14.根据权利要求11所述的方法，其特征在于，

所述取回所述用户设备上下文的请求包括接入网区域更新标记，所述接入网区域更新标记用于指示所述用户设备正在请求基于接入网的位置区域更新。

15.根据权利要求11所述的方法，其特征在于，

所述取回所述用户设备上下文响应消息包括寻呼标记，所述寻呼标记用于指示所述用户设备正在被所述通知区进行无线接入网寻呼。

16.根据权利要求11-15中任一项所述的方法，其特征在于，

所述目标基站与所述锚基站属于同一通知区。

17.根据权利要求11-15中任一项所述的方法，其特征在于，

所述目标基站与所述锚基站属于不同通知区。

18.根据权利要求17所述的方法，其特征在于，

所述向所述目标基站发送取回所述用户设备上下文响应消息之后进一步包括：

所述锚基站向所述目标基站转发由核心网发给所述锚基站的下行数据。

19.一种寻呼方法，其特征在于，包括：

目标基站接收来自于待用态下的用户设备的原因值为基于接入网的位置区域更新的连接恢复请求；

所述目标基站响应所述原因值为基于接入网的位置区域更新的连接恢复请求向锚基站发送取回所述用户设备上下文的请求；

所述目标基站接收来自于所述锚基站的取回所述用户设备上下文响应消息；

所述目标基站向所述用户设备发送连接恢复信令以将所述用户设备从所述待用态变为连接态。

20.根据权利要求19所述的方法，其特征在于，

所述连接恢复请求为包括所述用户设备的接入网标识且原因值为基于接入网的位置区域更新的RRCConnectionResumeRequest，即RRC连接恢复请求；所述连接恢复信令为RRCConnectionResume，即RRC连接恢复。

21.根据权利要求19所述的方法，其特征在于，

所述取回所述用户设备上下文的请求包括接入网区域更新标记，所述接入网区域更新标记用于指示所述用户设备正在请求基于接入网的位置区域更新；

所述取回所述用户设备上下文响应消息包括寻呼标记，所述寻呼标记用于指示所述用户设备正在被所述锚基站所在的通知区进行无线接入网寻呼。

22.根据权利要求19-21中任一项所述的方法，其特征在于，所述目标基站与所述锚基站不属于同一通知区，所述目标基站接收来自于所述锚基站的取回所述用户设备上下文响应消息之后进一步包括：

接收所述锚基站转发的由核心网发给所述锚基站的下行数据。

23.根据权利要求19-21中任一项所述的方法，其特征在于，所述目标基站与所述锚基站属于同一通知区，所述目标基站接收来自于用户设备的原因值为基于接入网的位置区域更新的连接恢复请求之前进一步包括：

所述目标基站接收来自于所述锚基站的执行无线接入网寻呼的通知；

所述目标基站响应所述通知执行所述无线接入网寻呼以寻呼所述用户设备。

24.一种寻呼方法，其特征在于，包括：

处于待用态的用户设备在未收到无线接入网寻呼消息的情况下向目标基站发送原因值为基于接入网的位置区域更新的连接恢复请求；

所述用户设备接收来自于所述目标基站的连接恢复信令；

所述用户设备响应所述连接恢复信令从所述待用态进入连接态。

25.根据权利要求24所述的方法，其特征在于，

所述连接恢复请求为包括所述用户设备的接入网标识且原因值为基于接入网的位置区域更新RRCConnectionResumeRequest，即RRC连接恢复请求；所述连接恢复信令为RRCConnectionResume，即RRC连接恢复。

26.一种寻呼装置，其特征在于，包括处理器和通信电路，所述处理器连接所述通信电路；

所述处理器用于执行指令以实现如权利要求1-25中任一项所述方法。

27.一种寻呼装置，存储有指令，其特征在于，所述指令被执行时实现如权利要求1-25中任一项所述的方法。

Images