CN109892004B - 通信控制方法、无线控制单元、用户终端及核心网控制器 - Google Patents

Abstract

本申请公开了一种通信控制方法、无线控制单元、用户终端及核心网控制器，其中，通信控制方法应用于RCU，该方法包括：确定用户终端离开第一协议层状态时的第二协议层状态；发送所述第二协议层状态的第一指示信息给所述用户终端，所述第一指示信息用于指示所述用户终端处于所述第二协议层状态时进行相应操作,使得所述用户终端在处于所述第二协议层状态时基于所述第一指示信息进行相应操作。由此，本申请为了避免用户终端直接进入RRC空闲态所引起的信令开销和减少用户终端重新接入连接态的时延，通过在用户终端引入新的协议层状态，并指示用户终端在新的协议层状态下进行相应的操作，进而能够实时恢复到连接态，达到永久在线的体验。

Description

通信控制方法、无线控制单元、用户终端及核心网控制器

本申请要求于2016年11月25日提交中国专利局、申请号为201611054566.8、发明名称为“一种用户终端永久在线的方法”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本申请涉及通信领域，尤其涉及一种通信控制方法、无线控制单元、用户终端及核心网控制器。

背景技术

下一代无线网络需要支持的场景和业务种类较多，不同场景和业务的需求不同，比如，有些业务要求更高的数据速率，有些业务要求更高的数据速率，有些业务要求大量的连接，其他可能要求低时延和高可靠性，但都要求有很好的用户体验，比如永久在线。永久在线可以保证用户设备(User Equipment，UE)的业务可获得时延尽量低，甚至“零等待”。

目前，UE在空口有两种无线资源控制(Radio Resource Control，RRC)状态：RRCidle状态(RRC空闲态)和RRC connected状态(RRC连接态)。当UE需要进行通信业务时，则首先需要建立与网络的连接，即从RRC空闲态转到RRC连接态，然后进行业务数据的传输。

而现有的永久在线技术虽然可以提升用户体验，常用是将UE尽量处于RRC连接态，但导致UE能耗比较大，造成资源浪费。

发明内容

有鉴于此，本申请提供了一种通信控制方法、无线控制单元、用户终端及核心网控制器，目的在于解决UE永久在线导致能耗较大和造成资源浪费的技术问题。

本申请的第一方面提供了一种通信控制方法，适用于RCU，其中包括以下步骤：确定用户终端离开第一协议层状态时的第二协议层状态，发送第二协议层状态的第一指示信息给用户终端，以使得用户终端在处于第二协议层状态时基于第一指示信息进行相应操作。可见，本申请为了避免用户终端直接进入RRC空闲态所引起的信令开销和减少用户终端重新接入连接态的时延，通过在用户终端引入新的协议层状态，并指示用户终端在新的协议层状态下进行相应的操作，进而能够实时恢复到连接态，达到永久在线的体验。

本申请的第二方面提供了一种通信控制方法，适用于用户终端，其中包括以下步骤：接收RCU发送的由RCU在确定用户终端离开第一协议层状态时的第二协议层状态时生成的第一指示信息，从而进入第二协议层状态，在处于第二协议层状态时，基于第一指示信息执行相应的操作。可见，本申请中为了避免用户终端直接进入RRC空闲态所引起的信令开销和减少用户终端重新接入连接态的时延，通过在用户终端引入新的协议层状态，并指示用户终端在新的协议层状态下进行相应的操作，进而能够快速恢复到连接态，达到永久在线的体验。

本申请的第三方面提供了一种通信控制方法，适用于核心网控制器，其中包括以下步骤：接收RCU发送的由所述RCU在确定所述用户终端离开第一协议层状态时的在线空闲态时生成的第二指示信息；基于所述第二指示信息执行相应的操作。可见，本申请中为了避免用户终端直接进入RRC空闲态所引起的信令开销和减少用户终端重新接入连接态的时延，通过在用户终端引入新的协议层状态，并指示用户终端在新的协议层状态下进行相应的操作，进而能够快速恢复到连接态，达到永久在线的体验。

本申请的第四方面提供了一种通信控制单元，可以包括以下结构：用于存储应用程序及应用程序运行所产生的数据的存储器及处理器，处理器通过执行所述应用程序，以实现功能：确定用户终端离开第一协议层状态时的第二协议层状态；发送所述第二协议层状态的第一指示信息给所述用户终端，以指示所述用户终端在处于所述第二协议层状态时基于第一指示信息进行相应操作。可见，本申请为了避免用户终端直接进入RRC空闲态所引起的信令开销和减少用户终端重新接入连接态的时延，通过在用户终端引入新的协议层状态，并指示用户终端在新的协议层状态下进行相应的操作，进而能够实时恢复到连接态，达到永久在线的体验。

本申请的第五方面提供了一种用户终端，可以包括以下结构：存储应用程序及应用程序运行所产生的数据的存储器及处理器，处理器通过执行所述应用程序，以实现功能：接收RCU发送的第一指示信息，所述第一指示信息由所述RCU在确定所述用户终端离开第一协议层状态时的第二协议层状态时生成；进入所述第二协议层状态；在处于所述第二协议层状态时，基于所述第一指示信息执行相应的操作。可见，本申请中为了避免用户终端直接进入RRC空闲态所引起的信令开销和减少用户终端重新接入连接态的时延，通过在用户终端引入新的协议层状态，并指示用户终端在新的协议层状态下进行相应的操作，进而能够快速恢复到连接态，达到永久在线的体验。

本申请的第六方面提供了一种核心网控制器，可以包括以下结构：用于存储应用程序及应用程序运行所产生的数据的存储器及处理器，处理器通过用于执行所述应用程序，以实现功能：接收RCU发送的第二指示信息，所述第二指示信息由所述RCU在确定所述用户终端离开第一协议层状态时的第二协议层状态时生成，所述第二协议层状态为在线空闲态；基于所述第二指示信息执行相应的操作。可见，本申请中为了避免用户终端直接进入RRC空闲态所引起的信令开销和减少用户终端重新接入连接态的时延，通过在用户终端引入新的协议层状态，并指示用户终端在新的协议层状态下进行相应的操作，进而能够快速恢复到连接态，达到永久在线的体验。

在一个实现方式中，第二协议层状态为在线激活态或在线空闲态。由此，本申请中用户终端不直接进入RRC空闲态，而是进入在线激活态或在线空闲态，分别对应RRC连接态及RRC空闲态，由此，用户终端与核心网控制器都会按照RRC连接态或者空闲态进行操作，保持了RRC操作的一致性。

在一个实现方式中，第二协议层状态为在线激活态时，第一指示信息包括：用户终端用于发送上行信标的配置信息，以及指示用户终端保留其处于第一协议层状态的上下文信息。由此，用户终端在处于在线激活态时不通知核心网控制器，而是用户终端基于第一指示信息向RCU发送上行信标且会保留第一协议层状态的上下文，从而在进行收发数据时，可以利用发送上行信标所建立的数据链路及保留的第一协议层状态的上下文信息实时恢复到RRC连接态，进行数据传输，不仅提升了用户终端永久在线的体验，还保持了RRC操作的一致性。

在一个实现方式中，所述配置参数包括：所述用户终端发送上行信标的发送方式和用于发送上行信标的资源。由此，用户终端在处于第二协议层状态时不通知核心网，而是用户终端基于第一指示信息向RCU发送上行信标且会保留第一协议层状态的上下文，从而在进行收发数据时，可以利用发送上行信标所建立的数据链路及保留的第一协议层状态的上下文实时恢复到RRC连接态，进行数据传输，不仅提升了用户终端永久在线的体验，还保持了RRC操作的一致性。

在一个实现方式中，第二协议层状态为在线空闲态时，第一指示信息包括：用户终端用于恢复第一协议层状态的恢复标识及指示用户终端保留其处于第一协议层状态时的上下文信息，相应的，RCU还会发送第二协议层状态的第二指示信息给核心网控制器，第二指示信息包括：通知核心网控制器用户终端进入第二协议层状态的信息及指示核心网控制器保留用户终端处于第一协议层状态时的上下文的信息。由此，用户终端处于在线空闲态时通知核心网控制器，且用户终端与核心网控制器基于各自接收到的指示信息进行相应操作，从而在进行收发数据时，能够利用恢复标识及第一协议层状态的上下文快速进入RRC连接态，进行数据传输，不仅提升了用户终端永久在线的体验，还保持了RRC操作的一致性。

在一个实现方式中，在用户终端处于在线空闲态时，RCU向用户终端发出包括上行调度授权信息的寻呼信息并指示核心网控制器停止寻呼，或者，通知核心网控制器向用户终端发出寻呼信息，使得用户终端能够对寻呼信息进行响应。由此，用户终端在处于在线空闲态时，能够基于接收到的寻呼信息进行相应，快速恢复到RRC连接态，进行数据传输，不仅提升了用户终端永久在线的体验，还保持了RRC操作的一致性。

在一个实现方式中，在确定用户终端离开第一协议层状态时的第二协议层状态时，RCU可以通过获取用户终端离开第一协议层状态时的终端类型及业务需求参数，并基于这些终端类型及业务需求参数，确定用户终端离开第一协议层状态时的第二协议层状态。由此，更好的提升用户终端永久在线的体验，并保持RRC操作的一致性。

在一个实现方式中，第一协议层状态的上下文包括L3上下文和L2上下文，而L3上下文至少包括：RCU ID(identification)、RRC配置信息、承载配置信息、安全上下文信息；L2上下文至少包括：RDU ID、UE的ID、认证令牌。由此，用户终端可以利用第一协议层状态的上下文信息快速进入第一协议层连接态，进行数据传输，不仅提升了用户终端永久在线的体验，还保持了RRC操作的一致性。

在一个实现方式中，确定用户终端离开第一协议层状态时的第二协议层状态时，RCU可以通过获取用户终端离开第一协议层状态时的终端类型及业务需求参数，进而基于终端类型及业务需求参数，来确定用户终端离开第一协议层状态时的第二协议层状态。由此，能够更好的提升用户终端永久在线的体验，并保持RRC操作的一致性。

在一个实现方式中，在确定用户终端离开第一协议层状态时的第二协议层状态之前，RCU还可以通过监测用户终端的数据收发参数，进而基于数据收发参数，生成状态变化指令，并以此来触发用户终端离开第一协议层状态。由此，能够更好的提升用户终端永久在线的体验，并保持RRC操作的一致性。

在一个实现方式中，发送第二协议层状态的第一指示信息给用户终端时，RCU可以首先确定用户终端用于发送上行信标的配置信息或者通知用户终端对应的RDU或TRP，由TDU或TRP确定用户终端用于发送上行信标的配置信息，从而生成指示用户终端保留其处于第一协议层状态的上下文信息的信息，进而将用户终端用于发送上行信标的配置信息及指示用户终端保留其处于第一协议层状态的上下文的信息发送给用户终端。由此，能够更好的提升用户终端永久在线的体验，并保持RRC操作的一致性。

在一个实现方式中，用户终端在处于在线激活态时，基于所述用户终端发送上行信标的发送方式和用于发送上行信标的资源，向RCU发送上行信标，以更新数据链路，并保留处于所述第一协议层状态的上下文。由此，用户终端在处于在线激活态时不通知核心网控制器，而是用户终端基于第一指示信息向RCU发送上行信标且会保留第一协议层状态的上下文，从而在进行收发数据时，可以利用发送上行信标所建立的数据链路及保留的第一协议层状态的上下文信息实时恢复到RRC连接态，进行数据传输，不仅提升了用户终端永久在线的体验，还保持了RRC操作的一致性。

在一个实现方式中，在用户终端需要发送上行数据时，用户终端还利用用于发送上行信标的资源向所述RCU发送所述上行数据或调度请求，由所述RCU分配上行调度授权；接收所述RCU返回的上行调度授权；基于所述上行调度授权，进入连接态；发送所述上行数据。可见，用户终端在处于在线激活态时且进行数据发送时，可以利用发送上行信标所建立的数据链路及保留的第一协议层状态的上下文实时恢复到RRC连接态，发送上行数据，不仅提升了用户终端永久在线的体验，还保持了RRC操作的一致性。

在一个实现方式中，在用户终端需要接收下行数据时，利用所述第一协议层状态的上下文，进入连接态；接收所述下行数据。可见，用户终端在处于在线激活态时且进行收发数据时，可以利用保留的第一协议层状态的上下文实时恢复到RRC连接态，接收下行数据，不仅提升了用户终端永久在线的体验，还保持了RRC操作的一致性。

在一个实现方式中，在用户终端处于在线空闲态时，基于所述第一指示信息，保留处于所述第一协议层状态的L3上下文。可见，用户终端处于在线空闲态时基于接收到的指示信息进行相应操作，从而在进行收发数据时，能够利用恢复标识及第一协议层状态的上下文快速进入RRC连接态，进行数据传输，不仅提升了用户终端永久在线的体验，还保持了RRC操作的一致性。

在一个实现方式中，用户终端处于在线空闲态且需要发送上行数据时，利用所述第一协议层状态的L3上下文，进入连接态；发送所述上行数据。可见，用户终端在处于在线空闲态时且进行数据发送时，可以利用第一协议层状态的上下文实时恢复到RRC连接态，发送上行数据，不仅提升了用户终端永久在线的体验，还保持了RRC操作的一致性。

在一个实现方式中，用户终端处于在线空闲态且需要接收下行数据时，利用接收到的寻呼信息中的上行调度授权信息，对所述寻呼信息进行响应，以进入连接态；接收所述下行数据。可见，用户终端处于在线空闲态时基于接收到的指示信息进行相应操作，从而在进行数据接收时，能够利用用户终端处于在线空闲态所接收到的寻呼信息来快速进入RRC连接态，进行数据传输，不仅提升了用户终端永久在线的体验，还保持了RRC操作的一致性。

在一个实现方式中，核心网控制器在用户终端进入在线空闲态时基于所述第二指示信息保留与所述用户终端处于第一协议层状态时的L3上下文，根据第二指示信息判断是否需要发送寻呼信息，如果需要，则发送向用户终端发出寻呼信息。由此，用户终端与核心网控制器均基于接收到的指示信息进行相应操作，从而核心网控制器在需要传输下行数据时，能够基于其保留的L3上下文与进入RRC连接态的用户终端之间进行数据传输，不仅提升了用户终端永久在线的体验，还保持了RRC操作的一致性。

本申请的第七方面提供了一种用户终端永久在线的方法，可以包括以下步骤：(控制器)确定用户终端离开第一协议层连接态时的第二协议层状态，之后(控制器)发送第二协议层状态指示消息给用户终端。可见，本申请为了避免用户终端直接进入第一协议层空闲态所引起的信令开销和减少用户终端重新接入连接态的时延，通过在用户终端引入新的协议层状态，并指示用户终端在新的协议层状态下进行相应的操作，进而能够实时恢复到连接态，达到永久在线的体验。

本申请的第八方面提供了一种用户终端永久在线的方法，可以包括以下步骤：用户终端接收网络发送的离开第一协议层连接态时的第二协议层状态指示消息，之后用户终端收发数据时根据第二协议层状态指示消息，进入第二协议层状态。可见，本申请中为了避免用户终端直接进入第一协议层空闲态所引起的信令开销和减少用户终端重新接入连接态的时延，通过在用户终端引入新的协议层状态，并指示用户终端在新的协议层状态下进行相应的操作，进而能够快速恢复到连接态，达到永久在线的体验。

在一个实现方式中，第二协议层状态指示消息包括有：用户终端的第二协议层状态、用户终端用于发送UL Beacon的配置信息(发送方式和资源)以及保留第一协议层上下文的指示信息和保留第二协议层上下文的指示信息。

在一个实现方式中，第二协议层状态指示消息包括有：用户终端的第二协议层状态及用户终端用于恢复第一协议层连接态的标识。

在一个实现方式中，用户终端的第二协议层状态包括：(永久在线)激活态和(永久在线)空闲态。

在一个实现方式中，如果用户终端的第二协议层状态是永久在线激活态，则用户终端保留第一协议层上下文和第二协议层上下文。

在一个实现方式中，如果用户终端的第二协议层状态是永久在线空闲态，则用户终端保留第一协议层上下文。

在一个实现方式中，如果用户终端的第二协议层状态是永久在线激活态，则用户终端按第二协议层状态指示消息中的预设上行资源发送UL Beacon信号，如果用户终端的第二协议层状态时永久在线激活态，有上行数据时，则按预设上行资源发送数据或调度请求SR。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为用户终端进行无线数据传输中建立连接的信令流程图；

图2为无线网络中控制面与数据面分离的网络架构示意图；

图3为现有技术中用户终端引入新的RRC状态后各个状态之间的切换示意图；

图4为本申请中用户终端引入永久在线的空闲态和激活态后各个状态之间的转换示意图；

图5为本申请中UE从RRC连接态进入AOA状态再恢复RRC连接态的信令流程示意图；

图6为本申请中UE从RRC连接态进入AOA状态再恢复RRC连接态的另一信令流程示意图；

图7为本申请中UE从RRC连接态进入AOI状态再恢复到RRC连接态的信令流程示意图；

图8为本申请中UE从RRC连接态进入AOI状态再恢复到RRC连接态的另一信令流程示意图；

图9为本申请中RCU确定UE的第二协议层状态的流程图；

图10为本申请中UE的结构示意图。

具体实施方式

图1所示为用户终端进行无线数据传输中建立连接的信令流程，以下就图1中的信令流程进行说明：

首先，处于RRC连接态的用户终端UE如果长时间没有数据传输，那么处于eNB(evolved Node B，基站)中的不活动定时器(inactivity timer)超时，则基站给UE发送RRC连接释放的消息，此时UE处于RRC连接态时的上下文被释放，而UE的上下文包括有控制面的上下文及数据面的上下文，如有RRC配置信息、承载配置信息、安全上下文信息等，从而UE进入RRC空闲态；

其次，处于RRC空闲态的UE会在一个小区进行驻留，由于UE的移动性，会进行小区重选来变更驻留的小区；

最后，处于RRC空闲态的UE会在自己的寻呼时机去接收可能的paging消息，当有下行数据到达(即网络侧要发送下行数据给UE)时，S-GW(Serving GateWay，服务网关)通知MME(Mobility Management Entity，网络节点)，MME触发paging消息给eNB(paging消息中携带UE的UE Identity Index value、Paging DRX和UE Paging Identity，前两者用于确定UE的寻呼时机，后者用于确定UE)，eNB在该UE的寻呼时机在空口发送paging消息(携带UEPaging Identity)，UE收到自己的paging消息后，会在当前驻留的小区上发起新的RRC连接建立过程，以进入连接态；或者UE有上行数据要发送时，在当前驻留的小区上发起新的RRC连接建立过程，以进入RRC连接态。

而为了提升用户体验，常采用永久在线的方案，即使UE尽量处于连接态，但这种技术手段会导致UE能耗比较大，造成资源浪费。

为了避免过多的信令开销和减少用户终端接入的时延，提升用户体验，可以对RRC空闲态到RRC连接态的转换进行增强，比如在进入RRC空闲态时，CN(Core Network，核心网)控制器和用户终端保留用户终端的上下文，当用户终端从RRC空闲态进入RRC连接态时，可以快速恢复RRC连接态。

另外，为了避免用户直接进入RRC空闲态，也可以引入新的过渡状态，在过渡状态下，用户终端可以使用共享资源进行上下行传输，比如支持DL Scheduling-free(下行免调度)传输和支持UL grant-free(Uplink grant-free，上行免授权)传输。

图2所示为无线网络中控制面与数据面分离的网络架构示意图：

无线网络的控制面的功能特别是RRC在无线控制单元RCU中实现，数据面的功能在无线分布单元RDU中实现。每个RDU可以带多个TRP(transmission and reception point，发送接收点)，因此，UE从RRC空闲态到RRC连接态的过程中，时延会增加，因此，需要研究能够针对控制面和数据面分离下的用户终端永久在线的技术方案。

现有技术中有一种解决用户永久在线的技术方案，如下：

在当前的5G NR(New Radio)讨论中，引入一种新的RRC状态：RRC connectedinactive态，如图3，在该状态下：

首先，UE和基站保留UE的上下文；

其次，为了更进一步减少S1接口(基站到核心网的接口)的信令，在UE进入或离开RRC connected inactive态时，不通知核心网控制器，即UE处于RRC connected inactive态对核心网控制器是透明的，核心网控制器并不知道UE是处于RRC连接态还是RRCconnected inactive态；

最后，当下行数据到达时，基站自身发起(而不是MME发送来的paging触发基站发起)paging触发UE进入连接态。

以上方案中，RRC connected inactive态对UE是“idle”态，对CN则是“connected”态，导致UE和CN的RRC状态不一致。UE从RRC连接态到RRC connected inactive态后不通知CN，则CN认为UE仍然处于RRC连接态，不会paging UE，当UE移动到新的小区时，如果进行位置更新，则更新后UE的RRC状态与CN登记的UE RRC状态不一致；如果不进行位置更新，则触发切换流程，导致信令开销更大。

为了能够达到用户终端能够尽量保持永久在线的目的，并且避免上述问题，本申请重新定义用户终端的状态，并提出两个新的状态，即：在用户终端引入永久在线的AOA(Always-on active，在线激活态)状态，可以实时进入到RRC连接态，减少时延，提升了接入时延的性能，同时减少了RRC信令和S1-AP(S1 application protocol，S1应用协议)信令开销；在用户终端引入永久在线的AOI(Always-on idle，在线空闲态)状态，可以快速进入RRC连接态，同时降低了能耗。另外，本申请中可以基于控制面的上下文及数据面的上下文进行快速状态转换，可以提升用户终端接入性能，达到永久在线的体验。

也就是说，本申请中定义UE在状态变化前处于第一协议层状态，如RRC连接态或RRC空闲态，定义UE在状态变化后处于第二协议层状态，如AOA状态或AOI状态等。由于本申请的目的在于实现用户终端永久在线，因此，本申请中主要介绍UE在RRC连接态或RRC空闲态与AOA状态或AOA状态之间的状态变化过程。

以下对本申请中的方案进行描述：

RCU通过实时监测用户终端的数据收发参数，基于数据收发参数，生成状态变化指令，并将这个状态变化指令传输给用户终端，用以触发用户终端离开第一协议层状态。例如，RCU监测处于RRC连接态的用户终端是否在一定时间内没有收发数据，如RRCinactivation timer超时等，如果是，则RCU触发UE离开RRC连接态；或者，RCU监测处于AOA状态的用户终端是否在一定时间内没有数据发送，也没有接收到下行数据，如AOA状态下的AOA inactivation time超时，则RCU触发用户终端离开AOA状态。

另外，RCU还可以监测处于RRC空闲态的用户终端是否需要发送上行数据或者接收下行数据，如果是，则RCU触发UE离开RRC空闲态；或者RCU还可以监测处于AOI状态的用户终端是否需要发送上行数据或者接收下行数据，如果是，则RCU触发UE离开AOI状态。

而RCU生成的状态变化指令同样可以用来指示用户终端所进入的第二协议层状态，例如，用户终端是进入AOA状态还是AOI状态。本申请中可以通过获取用户终端离开第一协议层状态时的终端类型及业务需求参数来确定用户终端离开第一协议层状态时的第二协议层状态。例如，RCU通过对用户终端是否为relay(中继的)终端且relay需求存在、用户终端的业务接入时延需求与预设门限的大小关系及用户终端是否为高频接入等进行判断，进而判断出用户终端的第二协议层状态是AOA状态还是AOI状态。

RCU在确定用户终端离开第一协议层状态时的第二协议层状态之后，向用户终端发送第二协议层状态的第一指示信息，第一指示信息用于指示用户终端处于第二协议层状态时进行相应操作。首先，RCU确定用户终端用于发送上行信标即UL Beacon的配置参数，或者，RCU通知RDU或TRP，再由RDU或TRP确定用户终端用于发送UL Beacon的配置参数，这里的配置参数包括有UL Beacon的发送方式和用于发送UL Beacon的资源，同时RCU生成指示用户终端保留其处于第一协议层状态时的上下文的信息，包括第3层(Layer3，L3)上下文及第2层(Layer2，L2)上下文，最后，RCU将用户终端用于发送UL Beacon的配置参数及指示用户终端保留L3上下文及L2上下文的信息作为第一指示信息发给用户终端。

其中，如果RCU确定用户终端进入AOA状态，则第一指示信息中包括：用户终端用于发送UL Beacon的配置参数及指示所述用户终端保留其处于所述第一协议层状态的L3上下文及L2上下文的信息。进入AOA状态的用户终端在接收到第一指示信息之后，基于第一指示信息，向RCU发送UL Beacon，以更新数据链路，包括新建数据链路或者重建数据链路，并保留处于第一协议层状态时的L3上下文及L2上下文。由此，用户终端在需要发送上行数据时，利用用户终端用于发送UL Beacon的资源向RCU发送所述上行数据或者SR(SchedulingRequest，调度请求)，由RCU分配上行调度授权即UL grant，用户终端在接收到RCU返回的ULgrant后，基于UL grant，进入RRC连接态，进而建立与核心网控制器之间的数据连接，利用数据连接发送上行数据；而用户终端有下行数据需要接收时，可以利用基于UL Beacon更新的数据链路及保留的L3上下文进入RRC连接态，进而建立与核心网控制器之间的数据连接，接收下行数据。而用户终端在移动导致服务的基站发生变化时，新的基站通知用户终端用于发送UL Beacon的新的配置参数；而用户终端在移动导致服务的基站及RDU发生变化时，新的基站需要为用户终端与新的RDU更新数据链路，新的RDU同样需要为UE更新与RCU的数据链路，RCU、新的RDU或新的基站通知用户终端用于发送UL Beacon的新的配置信息。

需要说明的是，在用户终端进入RRC连接态之后，停止发送上行信标UL Beacon。

如果RCU确定用户终端进入AOI状态，则第一指示信息中包括：用户终端用于恢复第一协议层状态的恢复标识，如Resume ID，及指示用户终端保留其处于第一协议层状态时的L3上下文的信息。除此之外，RCU还会给核心网控制器发送第二指示信息，第二指示信息中包括：通知核心网控制器用户终端进入第二协议层状态的信息以及指示核心网控制器保留用户终端处于第一协议层状态时的L3上下文的信息。之后，进入AOI状态的用户终端在接收到第一指示信息之后，基于第一指示信息，保留其处于第一协议层状态的L3上下文。同时，核心网控制器接收RCU发送的第二指示信息，基于第二指示信息执行相应的操作，如保留L3上下文。之后，RCU确定是否自己寻呼用户终端，如果是，指示核心网控制器禁止寻呼，或者由核心网控制器寻呼用户终端，由RCU向用户终端转发寻呼信息，使得用户终端能够对寻呼信息进行相应，此时的寻呼信息包括UL grant。由此，用户终端在需要发送上行数据时，利用L3上下文进入RRC连接态，进而建立与核心网之间的数据连接，发送上行数据；用户终端在需要接收下行数据，利用寻呼信息中的UL grant，对寻呼信息进行相应，进入RRC连接态，由此建立与核心网之间的数据连接，接收下行数据。

如图4所示，为本申请中用户终端在RRC连接态、RRC空闲态、AOA状态及AOI状态之间的转换示意图，以下基于图4对本申请的技术构思进行说明：

本申请在UE一端引入两种新状态，包括：AOA状态和AOI状态，这两种状态的操作分别对应UE的RRC连接态和RRC空闲态的操作，由此在CN控制器一端，UE仍然为原来的RRC连接态及RRC空闲态两种状态。

其中，在UE进入AOA状态时，RCU通知UE用于发送UL Beacon的配置参数并保留L3上下文和L2上下文，但不通知CN控制器。UE保留的L3上下文包括：RCU ID、RRC配置信息、承载配置信息、安全上下文信息等；UE保留的L2上下文包括：RDU ID、UE的ID(如C-RNTI)，authentication token等。AOA状态对应RRC连接态，UE和CN均按照UE处于RRC连接态的规则进行通信操作，如CN直接发送下行数据或UE快速进入发送上行数据；

而在UE进入AOI状态时，RCU通知UE保留UE的L3上下文及用于恢复RRC连接态的恢复标识Resume ID，并通知CN控制器UE处于RRC空闲态并保留L3上下文。该AOI状态对应RRC空闲态，对于下行数据，UE和CN均按UE处于RRC空闲态的规则进行通信操作，如UE监听CN或RCU的paging信号等；对于上行数据，UE使用Resume ID快速恢复RRC连接态，与CN之间按照UE处于RRC连接态的规则进行通信操作。

需要说明的是，在AOA状态，UE向网络侧的RCU发送上行Beacon信号(UL Beacon)，网络侧的RCU据此进行与UE的数据链路的更新，避免切换。由于UL Beacon信号对UE功耗有影响，因此，在AOA状态下，如果UE长时间没有数据发送，也没有接收到下行数据，则UE通知RCU，RCU响应并向UE通知resume ID，同时通知CN控制器，UE进入AOI状态，停止发送ULBeacon。

而UE离开RRC-connected状态时，根据UE的能力和业务需求情况，确定UE是进入AOA状态还是AOI状态。

基于上述本申请的技术构思，本申请可以应用于无线通信***中，包括但不限于LTE/LTE-A/NR、WIMAX以及后续的无线通信***。基于图2所示的通信架构，以下以具体的示例对本申请的技术构思进行说明：

本实施例中涉及的网元如图2中所示，包括：控制器如RCU和RDU、基站如TRP和用户终端UE。

实施例一

图5为UE从RRC连接态进入AOA状态再恢复RRC连接态的信令流程示意图：

其中，在UE处于RRC连接态时，如果在一定时间内没有收发数据，如RRCinactivation timer超时，则RCU触发UE离开RRC连接态，如果确定UE进入AOA状态，则具有以下步骤：

Step1：RCU确定UE进入AOA状态并命令UE进入AOA状态，并通知UE用于发送ULBeacon的配置参数和保留L3上下文和L2上下文，即控制面上下文及数据面上下文。

其中，RCU可以自己确定UE用于发送UL Beacon的配置参数，包括UE发送UL Beacon的发送方式及UE用于发送UL Beacon的资源，如UE周期性发送UL Beacon的发送方式；或者，RCU仅仅通知服务的RDU或TRP，由RDU或TRP确定UE发送UL Beacon的方式和用于发送ULBeacon的资源，之后，由RCU将RDU或TRP所确定的UE发送UL Beacon的方式和用于发送ULBeacon的资源以及指示UE保留L3上下文和L2的上下文的信息都通知给UE。

Step2：UE在收到进入AOA状态的指示即UE用于发送UL Beacon的配置参数和保留L3和L2的上下文的指示后，进入AOA状态，并根据接收到的UL Beacon的资源，向网络侧的基站如TRP1或TRP2发送UL Beacon；

Step3：当UE移动，导致服务的TRP发生变化时，如由TRP1变为TRP2时，新的TRP即TRP2通知UE用于发送UL Beacon的新的配置参数，此时，UE向TRP2发送UL Beacon。

Step4：当UE有上行数据，则使用发送UL Beacon的资源发送数据或调度请求SR，网络侧如TRP2再给UE分配专用的UL Grant，UE获得专用的UL Grant后便进入RRC连接态，继续发送上行数据；

Step5：当UE有下行数据，则UE与CN控制器之间通过UE保留的L3上下文，以及基于UL beacon更新的数据链路(重新建立断开的已有数据链路或新建的数据链路)进行数据传输。

需要说明的是，UE在发送上行数据或收到下行数据，进入RRC连接态后，停止发送UL beacon。

由此，本实施例一中引入的AOA状态，不管是否作为新的RRC状态，但UE都会按照RRC连接态的操作进行数据传输操作，保持了UE和CN的RRC操作的一致性，并且可以实时进行业务数据传输并避免了TRP切换信令，减少信令开销。

实施例二

图6为UE从RRC连接态进入AOA状态再恢复RRC连接态的另一信令流程示意图：

其中，在UE处于RRC连接态时，如果在一定时间内没有收发数据，如RRCinactivation timer超时，则RCU触发UE离开RRC connected状态，如果确定UE进入AOA状态，则具有以下步骤：

Step1：RCU确定UE进入AOA状态并命令UE进入AOA状态，并通知UE用于发送ULBeacon的资源和保留L3上下文和L2上下文；

其中，RCU可以自己确定UE用于发送UL Beacon的配置参数，包括UE发送UL Beacon的发送方式和UE用于发送UL Beacon的资源，如UE周期发送UL Beacon的发送方式；或者，RCU仅仅通知服务的RDU或TRP，由RDU或TRP确定UE发送UL Beacon的方式和用于发送ULBeacon的资源，之后，由RCU将RDU或TRP所确定的UE发送UL Beacon的方式和用于发送ULBeacon的资源以及指示UE保留L3上下文和L2的上下文的信息都通知给UE。

Step2：UE收到进入AOA状态的指示后，进入AOA状态，并根据UL Beacon的配置参数，向网络侧的基站发送UL Beacon；

Step3：当UE移动，导致服务的TRP和RDU发生变化时，如由TRP1变为TRP2，由RDU1变为RDU2，新的TRP即TRP2需要为UE与新的RDU即RDU2建立L2连接即数据面的连接，RDU2同样需要为UE建立与RCU的L2连接，网络侧如RCU、RDU2或TRP2确定通知UE用于发送UL Beacon的新的配置参数；

Step4：RCU更新UE的L2上下文；

Step5：当UE有上行数据，则使用发送UL Beacon的资源发送数据或调度请求SR，网络侧如图TRP2再给UE分配专用的UL Grant，UE获得专用的UL Grant后便进入RRC连接态，继续发送上行数据；

Step6，当UE有下行数据，则UE和CN控制器根据UE保留的L3上下文，以及基于ULbeacon更新的数据链路(重新建立的断开的已有数据链路或新建的数据链路)进行数据传输。

需要说明的是，UE发送上行数据或收到下行数据后，进入RRC连接态状态，停止发送UL beacon。

需要说明的是，本实施例二中，UE在AOA状态下，通过发送UL Beacon维护数据面的上下文，即文中的L2上下文，避免了TRP切换指令和RDU切换指令所引起的指令开销；另外，本实施例中利用发送UL Beacon的资源发送业务请求，在有业务如上下行数据传输时，实时进入RRC连接态，提升了用户终端永久在线的体验。而UE在AOA状态，UE和CN都会按照RRC连接态进行操作，保持了RRC操作的一致性。

实施例三

图7为UE从RRC连接态进入AOI状态再恢复到RRC连接态的信令流程示意图：

其中，UE在RRC连接态时，在一定时间内没有收发数据时，如RRC inactivationtimer超时，则RCU触发UE离开RRC连接态，如果确定UE应当进入AOI状态，则具体步骤如下：

Step1：RCU确定UE进入AOI状态并命令UE进入AOI状态，并通知UE保留L3上下文以及用于恢复RRC连接态的Resume ID，通知CN控制器UE进入RRC空闲态但保留L3上下文；

Step2：RCU确定自己是否需要自行寻呼UE，如果RCU自己寻呼UE，则向UE进行发出寻呼信息，即paging，并指示CN控制器paging prohibit，即禁止寻呼；

Step3：当UE有下行数据，CN控制器如果收到UE的paging prohibit指示，则不寻呼UE，直接使用保留的L3上下文进行数据传输；如果CN控制器没有收到paging prohibit指示，则CN控制器自己寻呼UE，类似于RRC idle状态的操作；

Step4：RCU基于CN控制器的寻呼或自行寻呼UE，并携带UL grant资源；

Step5：UE使用UL grant资源响应寻呼，即paging response，从而接收下行数据(通过已有数据链路或新的数据链路)。

由此，UE在AOI状态下，在有业务时，利用Resume ID，可以快速进入RRC connected状态，提升了用户永久在线的体验；而UE在AOI状态下，UE和CN均可按RRC idle状态操作，保持了RRC操作的一致性。

实施例四

UE在AOA状态，如果UE长时间没有数据发送，也没有接收到下行数据，如AOA状态下的AOA inactivation time超时，则UE通知RCU，UE自己直接进入AOI状态，停止发送ULBeacon；或者，UE从AOA态到AOI态的转化时，也可以由RCU触发，如图8中所示。

需要说明的是，在UE从AOA状态到AOI状态后，UE及RCU等之间的信令流程可以参考图7、图8及上述实施例三中内容所示，此处不再详述。

由此，本实施例中在UE进入AOI状态之后，避免了UE发送UL Beacon，从而节省了UE的能耗。

实施例五

当UE离开RRC连接态时，RCU需要确定UE是进入AOA状态还是AOI状态，具体的，本实施例中基于用户终端的类型、能力和业务情况进行确定，如图9中所示：

首先判断UE是否为relay UE，例如可以充当穿戴设备的中继的UE，并且relay需求存在，则确定UE进入AOA状态；

否则，再判断UE的业务接入延时需求如业务接入的最大允许时延是否低于预设的门限1，如果是则确定UE进入AOA状态；或者如果UE的业务接入的最大允许时延低于预设的门限2，且UE为高频接入，则确定UE进入AOA状态；

否则，UE进入AOI状态。

由此，本实施例中基于用户终端的类型、能力及业务情况确定UE离开RRC连接态时，合理进入AOA状态或进入AOI状态，保证了业务的体验并且避免了UE不必要的能耗。

图2中的RCU能够实现上述图5～图9中相应的功能，具体用于确定用户终端离开第一协议层状态时的第二协议层状态，并发送所述第二协议层状态的第一指示信息给所述用户终端，所述第一指示信息用于指示所述用户终端处于所述第二协议层状态时进行相应操作。

图2中的UE的结构可以如图10中所示，用户终端可以包括以下结构：

存储器1001及处理器1002，其中：

存储器1001，用于存储应用程序及应用程序运行所产生的数据；

处理器1002，用于执行所述应用程序，以实现功能：接收RCU发送的第一指示信息，所述第一指示信息由所述RCU在确定所述用户终端离开第一协议层状态时的第二协议层状态时生成；进入所述第二协议层状态；在处于所述第二协议层状态时，基于所述第一指示信息执行相应的操作。

图2中的CN的CN控制器能够实现上述图5～图9中相应的功能，具体用于：接收RCU发送的第二指示信息，所述第二指示信息由所述RCU在确定所述用户终端离开第一协议层状态时的第二协议层状态时生成，所述第二协议层状态为在线空闲态；基于所述第二指示信息执行相应的操作。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。

Claims (22)

1.一种通信控制方法，其特征在于，应用于RCU(Radio Control Unit，无线控制单元)，所述方法包括：

确定用户终端离开第一协议层状态时的第二协议层状态，所述第二协议层状态包括在线激活态或在线空闲态，所述在线激活态下所述用户终端保留所述第一协议层状态的恢复标识，所述在线空闲态下所述用户终端向所述RCU发送上行Beacon信号；

发送所述第二协议层状态的第一指示信息给所述用户终端，所述第一指示信息用于指示所述用户终端处于所述第二协议层状态时进行相应操作,使得所述用户终端在处于所述第二协议层状态时基于所述第一指示信息进行相应操作。

2.根据权利要求1所述的方法，其特征在于，所述第二协议层状态为在线激活态时，所述第一指示信息包括：所述用户终端用于发送上行信标的配置参数及指示所述用户终端保留其处于所述第一协议层状态的上下文。

3.根据权利要求2所述的方法，其特征在于，所述配置参数包括：所述用户终端发送上行信标的发送方式和用于发送上行信标的资源。

4.根据权利要求1所述的方法，其特征在于，所述第二协议层状态为在线空闲态时，所述第一指示信息包括：所述用户终端用于恢复所述第一协议层状态的恢复标识及指示所述用户终端保留其处于所述第一协议层状态时的上下文的信息；

其中，所述方法还包括：

发送所述第二协议层状态的第二指示信息给核心网控制器，所述第二指示信息包括：通知所述核心网控制器所述用户终端进入第二协议层状态的信息及指示所述核心网控制器保留所述用户终端处于所述第一协议层状态时的上下文的信息。

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

在所述用户终端处于所述在线空闲态时，向所述用户终端发出寻呼信息，并指示所述核心网控制器停止寻呼，或者，通知所述核心网控制器向用户终端发出寻呼信息，使得用户终端能够对所述寻呼信息进行响应，所述寻呼信息包括上行调度授权信息。

6.根据权利要求2或4所述的方法，其特征在于，所述第一协议层状态的上下文包括L3上下文和L2上下文；

其中，L3上下文至少包括：RCU ID(identification)、RRC配置信息、承载配置信息、安全上下文信息；

L2上下文至少包括：RDU ID、UE的ID、认证令牌(authentication token)。

7.根据权利要求1所述的方法，其特征在于，确定用户终端离开第一协议层状态时的第二协议层状态，包括：

获取所述用户终端离开所述第一协议层状态时的终端类型及业务需求参数；

基于所述终端类型及业务需求参数，确定所述用户终端离开所述第一协议层状态时的第二协议层状态。

8.根据权利要求1所述的方法，其特征在于，在确定用户终端离开第一协议层状态时的第二协议层状态之前，所述方法还包括：

监测用户终端的数据收发参数；

基于所述数据收发参数，生成状态变化指令，所述状态变化指令用于触发所述用户终端离开所述第一协议层状态。

9.根据权利要求2所述的方法，其特征在于，发送所述第二协议层状态的第一指示信息给所述用户终端，包括：

确定所述用户终端用于发送上行信标的配置参数，或者通知所述用户终端对应的RDU(Radio Distributed Unit，无线分布单元)或TRP(Transmission and Reception Point，发送接收点)，由所述RDU或所述TRP确定所述用户终端用于发送上行信标的配置参数；

生成指示所述用户终端保留其处于所述第一协议层状态的上下文的信息；

将所述用户终端用于发送上行信标的配置参数及所述指示所述用户终端保留其处于所述第一协议层状态的上下文的信息发送给所述用户终端。

10.一种通信控制方法，其特征在于，应用于用户终端，所述方法包括：

接收RCU发送的第一指示信息，所述第一指示信息由所述RCU在确定所述用户终端离开第一协议层状态时的第二协议层状态时生成，所述第二协议层状态包括在线激活态或在线空闲态，所述在线激活态下所述用户终端保留所述第一协议层状态的恢复标识，所述在线空闲态下所述用户终端向所述RCU发送上行Beacon信号；

进入所述第二协议层状态；

在处于所述第二协议层状态时，基于所述第一指示信息执行相应的操作。

11.根据权利要求10所述的方法，其特征在于，所述第一指示信息包括：所述用户终端用于发送上行信标的配置参数及指示所述用户终端保留其处于所述第一协议层状态的上下文；

所述配置参数包括：所述用户终端发送上行信标的发送方式和用于发送上行信标的资源。

12.根据权利要求11所述的方法，其特征在于，所述在处于所述第二协议层状态时，基于所述第一指示信息执行相应的操作，包括：

在处于在线激活态时，基于所述用户终端发送上行信标的发送方式和用于发送上行信标的资源，向RCU发送上行信标，以更新数据链路，并保留处于所述第一协议层状态的上下文。

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

在需要发送上行数据时，利用用于发送上行信标的资源向所述RCU发送所述上行数据或调度请求，由所述RCU分配上行调度授权；

接收所述RCU返回的上行调度授权；

基于所述上行调度授权，进入连接态，发送所述上行数据。

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

在需要接收下行数据时，利用所述第一协议层状态的上下文，进入连接态；

接收所述下行数据。

15.根据权利要求11所述的方法，其特征在于，所述在处于所述第二协议层状态时，基于所述第一指示信息执行相应的操作，包括：

在处于在线空闲态时，基于所述第一指示信息，保留处于所述第一协议层状态的L3上下文。

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

在需要发送上行数据时，利用所述第一协议层状态的L3上下文，进入连接态；

发送所述上行数据。

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

在需要接收下行数据时，利用接收到的寻呼信息中的上行调度授权信息，对所述寻呼信息进行响应，以进入连接态；其中，所述寻呼信息由所述RCU在所述用户终端处于所述在线空闲态时向所述用户终端发出，同时RCU指示核心网控制器停止寻呼，或者，所述寻呼信息由所述RCU通知所述核心网控制器向用户终端发出；

接收所述下行数据。

18.一种通信控制方法，其特征在于，包括：

接收RCU发送的第二指示信息，所述第二指示信息由所述RCU在确定用户终端离开第一协议层状态时的第二协议层状态时生成，所述第二协议层状态为在线空闲态，所述在线空闲态下所述用户终端向所述RCU发送上行Beacon信号；

基于所述第二指示信息执行相应的操作。

19.根据权利要求18所述的方法，其特征在于，基于所述第二指示信息执行相应的操作，包括：

保留与所述用户终端处于第一协议层状态时的L3上下文；

根据第二指示信息判断是否需要发送寻呼信息，如果需要,则发送向用户终端发出寻呼信息。

20.一种通信控制单元(RCU)，其特征在于，包括：

存储器，用于存储应用程序及应用程序运行所产生的数据；

处理器，用于执行所述应用程序，以实现功能：确定用户终端离开第一协议层状态时的第二协议层状态；发送所述第二协议层状态的第一指示信息给所述用户终端，所述第一指示信息用于指示所述用户终端处于所述第二协议层状态时进行相应操作，使得所述用户终端在处于所述第二协议层状态时基于所述第一指示信息进行相应操作，所述第二协议层状态包括在线激活态或在线空闲态，所述在线激活态下所述用户终端保留所述第一协议层状态的恢复标识，所述在线空闲态下所述用户终端向所述RCU发送上行Beacon信号。

21.一种用户终端，其特征在于，包括：

存储器，用于存储应用程序及应用程序运行所产生的数据；

处理器，用于执行所述应用程序，以实现功能：接收RCU发送的第一指示信息，所述第一指示信息由所述RCU在确定所述用户终端离开第一协议层状态时的第二协议层状态时生成；进入所述第二协议层状态；在处于所述第二协议层状态时，基于所述第一指示信息执行相应的操作，所述第二协议层状态包括在线激活态或在线空闲态，所述在线激活态下所述用户终端保留所述第一协议层状态的恢复标识，所述在线空闲态下所述用户终端向所述RCU发送上行Beacon信号。

22.一种核心网控制器，其特征在于，包括：

存储器，用于存储应用程序及应用程序运行所产生的数据；

处理器，用于执行所述应用程序，以实现功能：接收RCU发送的第二指示信息，所述第二指示信息由所述RCU在确定用户终端离开第一协议层状态时的第二协议层状态时生成，所述第二协议层状态为在线空闲态；基于所述第二指示信息执行相应的操作，所述第二协议层状态包括在线激活态或在线空闲态，所述在线激活态下所述用户终端保留所述第一协议层状态的恢复标识，所述在线空闲态下所述用户终端向所述RCU发送上行Beacon信号。

Images