CN110035498B - 一种通信方法，设备及其系统 - Google Patents

Abstract

本申请实施例提供了一种通信方法，以有助于解决现有技术中基于集中式单元CU和分布式单元DU架构的无线接入网存在的寻呼机制不完善，并可能导致寻呼失败的问题，该方法包括以下过程：集中式单元向分布式单元发送寻呼消息，该寻呼消息中携带表明所涉及的寻呼是基于核心网产生的寻呼或该寻呼是基于无线接入网产生的寻呼的指示信息；分布式单元通过该指示信息可以获知涉及的寻呼是基于核心网产生的寻呼还是基于无线接入网产生的寻呼。通过该方法，有助于使得背景技术中的寻呼机制趋于合理完善，减少系统寻呼失败的情况。

Description

一种通信方法，设备及其系统

技术领域

本申请涉及通信领域，更具体的，涉及一种通信方法，设备及其系统等。

背景技术

在下一代移动通信系统中，比如第五代移动通信(the 5th generation mobilecommunication technology，5G)系统中，基站被称为gNB或ng-eNB，其中，ng-eNB是源于长期演进(long term evolution，LTE)系统基站(LTE eNB)的后续演进基站，仅为便于描述，本文采用gNB来表示基站。图1所示系统100为一种5G系统的示意性框图，其中，下一代无线接入网(next generation radio access network，NG-RAN)中的gNB和gNB之间，ng-eNB和ng-eNB之间，以及gNB和ng-eNB之间通过Xn接口互连。gNB和5G核心网(5G core，5GC)设备之间通过NG接口互连，ng-eNB和5GC设备之间通过NG接口互连。其中，5GC设备可以是接入和移动性管理功能实体(access and mobility management function，AMF)或用户面功能实体(user plane function，UPF)，AMF主要负责接入管理方面功能，UPF主要负责会话(session)管理方面功能。基站通常包括无线资源控制(radio resource control，RRC)层，业务数据适配协议(service data adaptation protocol，SDAP)层，分组数据汇聚层协议(packet data convergence protocol，PDCP)层，无线链路控制(radio link control，RLC)层，媒体接入控制(media access control，MAC)层，以及物理层(physical layer，PHY)等逻辑功能协议层。下一代基站(例如gNB)对传统基站架构进行了演进。图2为一种5G系统的示意性框图，该系统200包括5GC和NG-RAN，在NG-RAN中，基站gNB可以由集中式单元(centralized unit,CU)和分布式单元(distributed unit,DU)构成，CU和DU架构可以理解为是对传统接入网中的基站的功能进行拆分，传统基站的一部分功能部署在CU，其余功能部署在DU，多个DU可共用一个CU以节省成本并易于网络扩容，CU和DU之间通过F1接口进行信息交互。对于由CU和DU构成的gBN，对于外部其他网元而言是一个基站。

进一步的，如图3所示的一种5G系统的示意性框图中，在gNB中，集中式单元CU还可以划分为CU控制面(CU control plane,CU-CP)和CU用户面(CU user plane，CU-CP)。其中，CU-CP负责控制面功能，主要包含RRC和PDCP控制面部分(PDCP-C)，PDCP-C主要负责控制面数据的加解密，完整性保护，以及数据传输等；CU-UP负责用户面功能，主要包含SDAP和PDCP-U，其中SDAP主要负责将核心网的数据进行处理并将流(flow)映射到无线承载，PDCP-U主要负责数据面的加解密，完整性保护，头压缩，序列号维护，以及数据传输等。其中，CU-CP和CU-UP通过E1接口连接，CU-CP代表gNB通过Ng接口和核心网连接，CU-CP通过F1-C(F1控制面)接口和DU连接，CU-UP通过F1-U(F1用户面)接口和DU连接。还有一种设计是PDCP-C和PDCP-C都在CU-UP，RRC在CU-CP(图3中未示出)。

基于基站的CU-DU架构或其衍生架构，还存在如下问题中的至少一种：

当前针对UE的寻呼流程尚不完善，可能导致寻呼UE失败；

当UE进入非激活态时，CU通知DU释放该UE的UE上下文，但该机制尚存在缺陷；以及，

在UE接入网络的过程中，存在准入控制机制不完善而导致系统可能出错的问题。

发明内容

本申请提供一种通信方法，设备及其系统等，以解决基于CU-DU的基站架构或其衍生架构中存在的针对终端设备的寻呼流程尚不完善，可能导致寻呼UE失败的问题。

第一方面，本申请实施例提供了一种通信方法，该通信方法运行在通信系统中，该通信系统包括集中式单元和分布式单元，在该通信系统运行时，可执行如下示例性的操作：

集中式单元CU向分布式单元DU发送寻呼消息，该寻呼消息中携带表明该寻呼是基于核心网产生的寻呼或基于无线接入网产生的寻呼的指示信息；该分布式单元收到该寻呼消息，可寻呼消息中携带的该指示信息获知该寻呼是基于核心网产生的寻呼或该寻呼是基于无线接入网产生的寻呼。通过该方案，使得DU能够获知收到的寻呼消息是来自于核心网还是来自于RAN侧(比如CU产生的寻呼)，从而能够在空口正确的广播该寻呼。

根据第一方面的一种可选设计包括：该指示信息是源于核心网的被寻呼终端设备的标识的信息，则该指示信息被用于表明该寻呼是基于核心网产生的寻呼，并被用于使得该分布式单元获知该寻呼是基于所述核心网产生的寻呼；或者，该指示信息是无线接入网配置的被寻呼终端设备的标识的信息，则该指示信息被用于表明该寻呼是基于无线接入网产生的寻呼，并被用于使得该分布式单元获知该寻呼是基于该无线接入网产生的寻呼。通过该方案，可以通过在CU和DU之间的接口上传输的寻呼消息中携带的源于核心网的被寻呼终端设备的标识的信息来表示该寻呼是基于核心网产生的寻呼，或者，可以通过在CU和DU之间的接口上传输的寻呼消息中携带的无线接入网侧配置的被寻呼终端设备的标识的信息(或者其他能够标识该终端的信息)来表示该寻呼是基于无线接入网产生的寻呼。

根据第一方面的一种可选设计包括：该寻呼消息中还包括被寻呼终端设备的标识的信息，或者能够标识该被寻呼终端设备的信息。该寻呼消息中携带的该指示信息可用来指示或者表明所涉及的寻呼是基于核心网产生的寻呼或该寻呼是基于无线接入网产生的寻呼，该分布式单元收到该指示信息后，即可获知所涉及的寻呼是基于核心网产生的寻呼或所涉及的寻呼是基于无线接入网产生的寻呼，示例性的，如果该指示信息指示或者表明该寻呼是基于所述核心网产生的寻呼，那么该分布式单元可以根据该指示信息获知所涉及的寻呼是基于所述核心网产生的寻呼；或者，如果该指示信息指示或者表明该寻呼是基于无线接入网产生的寻呼，分布式单元收到指示信息后，即可获知该寻呼是基于无线接入网产生的寻呼。

根据第一方面的一种可选设计包括：该寻呼消息中包括被寻呼终端设备的标识的信息；该指示信息表明该寻呼是基于核心网产生的寻呼或基于无线接入网产生的寻呼，该指示信息被用于使得该分布式单元获知该寻呼是基于核心网产生的寻呼或该寻呼是基于无线接入网产生的寻呼，包括：该指示信息表明该被寻呼终端设备的标识的信息是源于核心网的，则该指示信息表明该寻呼是基于该核心网产生的寻呼，并被用于使得该分布式单元获知该寻呼是基于核心网产生的寻呼；或者，该指示信息表明该被寻呼终端设备的标识的信息是无线接入网配置的，则该指示信息表明该寻呼是基于该无线接入网产生的寻呼，并被用于使得该分布式单元获知该寻呼是基于该无线接入网产生的寻呼。通过该方案，CU和DU之间传输的寻呼消息中携带指示信息，通过该指示信息，CU可以告知DU寻呼消息中携带的UE的标识的信息是来源于核心网的还是在RAN侧配置的，从而使得DU能够获知该寻呼是源于核心网产生的寻呼，还是源于RAN侧产生的寻呼。

根据第一方面的一种可选设计包括：该指示信息中包括：源于核心网的被寻呼终端设备的标识的信息或无线接入网配置的被寻呼终端设备的标识的信息；当该指示信息中包括源于核心网的被寻呼终端设备的标识的信息时，则该指示信息表明该寻呼是基于该核心网产生的寻呼，并被用于使得该分布式单元获知该寻呼是基于该核心网产生的寻呼；或者，当该指示信息中包括无线接入网配置的被寻呼终端设备的标识的信息时，则该指示信息表明该寻呼是基于该无线接入网产生的寻呼，并被用于使得该分布式单元获知该寻呼是基于该无线接入网产生的寻呼。通过该方案，CU和DU之间的寻呼消息中可以包含两个信元，一个信元用于携带源于核心网的被寻呼终端设备的标识的信息，另一个信元用于携带无线接入网配置的被寻呼终端设备的标识的信息，在方法执行时，可择一发送这两个信元的内容。

根据第一方面的一种可选设计包括：该分布式单元具有如下中至少一种：无线链路控制层，媒体接入控制层，以及物理层；该集中式单元具有如下中至少一种：无线资源控制层，业务数据适配协议层，以及分组数据汇聚层协议层；该分布式单元和该集中式单元属于该无线接入网，是该无线接入网中的通信节点；该分布式单元和该集中式单元可以构成一个逻辑意义上的基站。

第二方面，本申请实施例提供了一种通信方法，该通信方法运行在通信系统中，以有助于解决在UE接入网络的过程中，存在准入控制机制不完善而导致系统可能出错的问题。该通信系统包括集中式单元和分布式单元，在该通信系统运行时，可执行如下示例性的操作：集中式单元拒绝终端设备的接入请求；该集中式单元向分布式单元发送指示信息；该指示信息用于表明该分布式单元需要删除该终端设备的上下文信息。

根据第二方面的一种可选设计包括：该指示信息包含：拒绝该终端设备接入的指示和/或拒绝该终端设备接入的原因的信息。

根据第二方面的一种可选设计包括：该集中式单元接收来自于该分布式单元发送的关于允许该终端设备接入的通知消息。

第三方面，本申请提供了一种通信设备，该通信设备包括：至少一个处理器和通信接口，该通信接口用于该通信设备与其他通信设备进行信息交互，当程序指令在该至少一个处理器中执行时，使得通信设备实现第一或第二方面及其各种可选的设计中在集中式单元或分布式单元的功能。

第四方面，本申请提供了一种计算机程序产品，该计算机程序产品具有程序指令，当该程序指令被直接或者间接执行时，使得如第一或第二方面及其各种可选的设计中在集中式单元或分布式单元上的功能得以实现。

第五方面，本申请提供了一种计算机程序存储介质，该计算机程序存储介质具有程序指令，当该程序指令被直接或者间接执行时，使得如第一或第二方面及其各种可选的设计中在集中式单元或分布式单元上的功能得以实现。

第六方面，本申请提供了一种芯片系统，该芯片系统包括至少一个处理器，当程序指令在该至少一个处理器中执行时，使得如第一或第二方面及其各种可选的设计中在集中式单元或分布式单元上的功能得以实现。

第八方面，本申请提供了一种通信系统，该通信系统包括如第三方面所述的通信设备。

附图说明

图1是本申请实施例提供的一种5G系统的示意性框图；

图2是本申请实施例提供的一种5G系统的示意性框图；

图3为本申请实施例提供的一种5G系统的示意性框图；

图4为本申请实施例提供的一种通信系统及方法的示意图；

图5为本申请实施例提供的一种通信系统及方法的示意图；

图6为本申请实施例提供的一种通信系统及方法的示意图；

图7为本申请实施例提供的一种通信系统及方法的示意图；

图8为本申请实施例提供的一种通信设备的示意性框图。

具体实施方式

首先对本申请各实施例出现的术语中具有共性的部分进行一般性描述。

本申请中的术语“第一”、“第二”等仅是为了区分不同的对象，“第一”、“第二”并不对其修饰的对象的实际顺序或功能进行限定。例如，“第一指示”和“第二指示”中的“第一”、“第二”，仅仅是为了区分这两者是不同的指示，“第一”和“第二”本身并不对其实际先后顺序或者功能进行限定。本申请中出现的“示例性的”，“示例”，“例如”，“可选的设计”或者“一种设计”等表述，仅用于表示举例子、例证或说明。本申请中被描述为“示例性的”，“示例”，“例如”，“可选的设计”或者“一种设计”的任何实施例或设计方案都不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用这些词旨在以具体方式呈现相关概念。本申请中出现的术语“上行”和“下行”，用于在特定场景描述数据/信息传输的方向，比如，“上行”方向一般是指数据/信息从终端设备向网络侧传输的方向，或者分布式单元向集中式单元传输的方向，“下行”方向一般是指数据/信息从网络侧向终端设备传输的方向，或者集中式单元向分布式单元传输的方向，可以理解，“上行”和“下行”仅用于描述数据/信息的传输方向，该数据/信息传输的具体起止的设备都不作限定。

本申请中出现的术语“和/或”，仅仅是一种描述对象之间的关联关系，表示对象间可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本申请中字符“/”，如无特别说明，则一般表示前后对象之间是一种“或”的关系。本申请中出现的字符“-”，一般用来表示该字符前后的对象两者之间具有对应/关联/映射/协作关系。例如，对于表述“分组数据汇聚协议处理的用户面功能(PDCP-U)”中“-”，可理解为表示PDCP功能中对应的用户面部分功能。

本申请中出现的类似于“项目包括如下中至少一种：A，B，以及C”表述的含义，如无特别说明，通常是指该项目可以为如下中任一个：A；B；C；A和B；A和C；B和C；A，B和C；A和A；A，A和A；A，A和B；A，A和C，A，B和B；A，C和C；B和B，B，B和B，B，B和C，C和C；C，C和C，以及其他A，B和C的组合。以上是以A，B和C共3个元素进行举例来说明该项目的可选用条目，当该表达为“项目包括如下中至少一种：A，B，……，以及X”时，即该表达中具有更多元素时，那么该项目可以适用的条目也可以按照前述规则获得。

在本申请中可能出现的对各种消息/信息/设备/网元/系统/装置/动作/操作/流程/概念等各类客体进行了赋名，可以理解的是，这些具体的名称并不构成对相关客体的限定，所赋名称可随着场景，语境或者使用习惯等因素而变更，对本申请中技术术语的技术含义的理解，应主要从其在技术方案中所体现/执行的功能和技术效果来确定。

在本申请中，终端设备可以包含如下形式：用户设备(User Equipment，UE)、接入终端、用户单元、用户站、移动站、移动台、远方站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置。终端设备可以是WLAN中的站点(STAION，ST)，可以是蜂窝电话、无绳电话、会话启动协议(Session Initiation Protocol，SIP)电话、无线本地环路(Wireless Local Loop，WLL)站、个人数字处理(Personal Digital Assistant，PDA)设备、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、车载设备、可穿戴设备以及下一代通信系统，例如，5G网络中的终端设备或者未来演进的公共陆地移动网络(Public Land Mobile Network，PLMN)网络中的终端设备等。终端设备还可以是可穿戴设备。可穿戴设备也可以称为穿戴式智能设备，是应用穿戴式技术对日常穿戴进行智能化设计、开发出可以穿戴的设备的总称，如眼镜、手套、手表、服饰及鞋等。可穿戴设备即直接穿在身上，或是整合到用户的衣服或配件的一种便携式设备。终端设备还可以是物联网(internet of things，IoT)系统中的终端设备，IoT是未来信息技术发展的重要组成部分，其主要技术特点是将物品通过通信技术与网络连接，从而实现人机互连，物物互连的智能化网络。在本申请实施例中，终端设备以UE为例进行实施例方案的描述，但可以理解的是，本申请实施例中终端设备并不局限于UE。

本申请实施例中CU和DU也不限于NR gNB，还可能包括LTE基站划分为CU和DU，或者CU还进一步划分为CP和UP两部分。当为LTE基站时，所述协议层不包含SDAP层。

本申请实施例描述的网络架构以及业务场景是为了便于读者清楚理解本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

在RAN侧，UE一般具有RRC连接态(RRC-connected status)和RRC空闲态(RRC-idlestatus)，还可以具有RRC非激活态(RRC-inactive status)，也可以称RRC非激活态为第三态。当UE处在非活跃状态(例如，终端没有上行和/或下行数据发送超过设定时间)时，基站可以通过RRC消息通知UE进入RRC非激活态。UE接入小区后，在基站为该UE建立相应的UE上下文，当UE的RRC状态发生改变时，基站随之相应处理该UE的UE上下文。例如，UE从RRC连接态转变为RRC空闲态，相应的，基站可以释放该UE的UE上下文；当UE从RRC连接态转换为RRC非激活态时，一种可能的处理是保持或者悬挂该UE的UE上下文，比如，在基站和/或UE保留该UE在RAN侧的UE上下文。

对于具有CU-DU架构和/或具有后续基于CU-DU衍生架构的基站而言，其中的CU一般具有RRC层，该RRC层具有管理UE的RRC状态的功能。对于处于RRC空闲态以及RRC非激活态的UE，分别具有基于核心网的寻呼(CN-based paging)以及基于无线接入网的寻呼(RAN-based paging)两种情况。特别地，还有一种可能的情况是，UE认为自己处在RRC非激活态，但实际上网络侧当时获知的情况是该UE处于RRC空闲态，则网络侧还会通过基于核心网的寻呼对该UE进行寻呼。此处所称的基于核心网的寻呼可以认为是核心网发起的寻呼，此处所称的基于无线接入网的寻呼可以认为是在无线接入网发起的寻呼，比如无线接入网中的基站，或者CU或者CP等网络节点发起的寻呼。对于基于核心网的寻呼，一般需要通过基站进行转发。此处核心网发起的寻呼和基站发起的寻呼的一个区别即在于寻呼的发起方不同。对于UE而言，需要区分收到的寻呼是基于核心网的寻呼，还是基于RAN的寻呼。对于核心网发起的寻呼，UE的最终的非连续接收周期(discontinuous reception cycle，DRX cycle)可以为：核心网发送的UE特定的DRX周期(UE specific DRX cycle)，以及小区广播的默认DRX周期(default DRX cycle)中取较小值(还可以是对应于该取得的较小值的一个值)。对于基站发起的寻呼，UE的最终的DRX cycle可以为：核心网发送的UE specific DRX cycle，UE接收到的RRC消息中携带的RAN侧UE DRX cycle以及小区广播的default DRX cycle中取较小值(还可以是对应于该取得的较小值的一个值)。一种特殊的情况是，如果其中个别DRXcycle不存在，则剩余的1个或多个DRX cycle取较小值。

CU给DU发送的寻呼消息可以携带寻呼DRX的信元，该信元可以是取如下两者中的较小者：UE specific CN DRX cycle和UE specific RAN DRX cycle。但CU给DU的发送的寻呼消息并未区分该寻呼是源于CN的寻呼还是源于RAN的寻呼，也未给出UE进入RRC非激活态时如何处理寻呼。

另外，当UE进入非激活态时，一般的，CU通知DU释放该UE的UE上下文，但该机制尚存在缺陷，比如DU是否可以干预CU关于释放UE上下文的决策，又比如，DU收到释放UE上下文的通知后，还未把CU发给UE的RRC连接释放消息转发给UE，而此时UE有上行数据到达(ULdata arrival)，如UE向基站(DU和/或CU)发送调度请求(scheduling request，SR)或缓冲区状态报告(buffer status report，BSR)，则可能导致系统出错。

还比如，基于CU-DU的RAN架构，UE请求和RAN建立RRC连接，一般的，基站中的DU或者CU可以拒绝UE的该建立RRC连接的请求。如，UE发送消息3(MSG3)以请求建立RRC连接(可以是新建、恢复或重建RRC连接中的任一种)，DU将MSG3中的RRC消息发送给CU，同时MSG3中携带为该UE分配的小区无线网络临时标识(cell radio network temporary identifier，C-RNTI)或临时小区无线网络临时标识(Temp CRNTI)，以及DU发给CU的RRC信息(DU to CURRC information)，该DU发给CU的RRC信息中包含该DU为该UE配置的信令无线承载1(signaling radio bearer，SRB1)的层1(L1)和/或层2(L2)参数，例如NR中所述RRC信息包含小区组配置CellGroupConfig。如果该CU收到该DU发送的DU to CU RRC information，则判断该DU允许该UE接入，否则认为DU不允许该UE接入。在上述UE请求建立RRC连接的过程中，可以由CU对UE的接入进行准入控制，例如，在CU拒绝UE接入RAN的情况下，CU可以向UE发送响应，该响应是针对UE向基站发送的MSG3中携带的RRC消息作出，该响应用于指示UE期望建立RRC连接的请求被拒绝。一般的，RRC消息被携带在MSG3中的RRC容器(RRC Container)中发给DU，但DU并不解析该RRC Container中的内容是接受RRC连接建立请求还是拒绝RRC连接建立请求。此时，若DU允许UE接入，并且系统默认设置中CU也允许接入的话，则DU将为UE建立用于传输SRB1的协议栈实体(例如RLC实体，MAC的逻辑信道等)，并为该UE建立上下文，该UE的上下文中包含UE的C-RNTI，F1接口ID(例如DU UE F1AP ID和/或CU UE F1SPID)；另外，DU或者CU还可以为该UE后续的RRC消息(例如MSG5)进行调度。可选地，存在第一种情况包括：DU在发送消息3之后启动定时器，当该定时器超时后，DU仍然未收到CU发送的UE上下文建立请求消息(UE context setup request)，则DU可以删除相关配置和UE上下文。或者，存在第二种情况包括：DU读取msg3中包含的RRC消息的类型，根据RRC消息类型判断CU是否拒绝或者是否将拒绝UE发起的RRC连接/重建/恢复请求，从而决定在DU是否删除所述配置和/或UE的上下文。对于第一种情况，如果定时器的设置不合理将导致系统出错。例如，若该定时器设置时长较小，则DU删除了所述配置和/或UE上下文后，DU再收到来自CU发送的UE上下文建立请求消息，这种情况下，由于DU已经删除了所述配置和/或UE上下文，将导致UE上下文建立不成功。对于第二种情况，则不符合5G RAN系统中RRC层在CU的假设前提。根据本发明实施例，如果CU拒绝UE接入，则CU需要显示的指示DU，以使得DU删除上述配置和UE上下文。

以下结合附图及实施例对本申请涉及的技术方案进行阐述。

如图4所示，本申请实施例提供了一种通信系统及其运行方法400，以解决基于CU-DU架构的寻呼机制不完善的问题，比如，寻呼处于RRC非激活态的UE时当前的寻呼机制可能导致系统出错的情况。

有鉴于此，本实施例的主要思想之一可表述为：CU向DU提供指示信息，该指示信息用于表明一个寻呼是基于核心网的寻呼和/或基于RAN的寻呼，以便DU能够获知并通知UE该寻呼是基于核心网的寻呼或基于RAN的寻呼。如图4所示，系统400包括CU，DU，以及UE，其中，CU和DU作为RAN架构中的功能节点。系统400可按照如下示例性方式运行：

操作401：CU将用于指示寻呼类型的指示信息发送给DU。

该用于指示寻呼类型的指示信息可以是CU产生的，该寻呼类型的指示信息可以携带在CU发给DU的F1应用层协议(F1application protocol，F1AP)的寻呼消息中。

根据步骤401的可选设计1，包括：该用于指示寻呼类型的指示信息是源于核心网的被寻呼UE的标识的信息，则该指示信息被用于表明涉及的寻呼是基于核心网产生的寻呼，并被用于使得该分布式单元获知该寻呼是基于核心网产生的寻呼；或，该指示信息是无线接入网配置的被寻呼UE的标识的信息，则该指示信息被用于表明该寻呼是基于该无线接入网产生的寻呼，并被用于使得该分布式单元获知该寻呼是基于无线接入网产生的寻呼。其中，可选的，该指示信息从功能上可以称之为恢复标识(resume ID)，或者是基于该恢复标识衍生的其他的标识信息，该恢复标识可被用于处在RRC非激活态的UE，该恢复标识还可被用于表示涉及的寻呼是基于RAN产生的寻呼(RAN-based paging)，该恢复标识也还可以用于获取UE的上下文。

根据可选设计1，一种示例性的实现包括：CU给DU发送的F1AP的寻呼消息中可以携带UE标识索引值(UE Identity Index value)和UE寻呼标识(UE Paging identity)这两个信元(information element，IE)。其中，UE Identity Index value可以是UE_ID，该UE_ID可通过公式：UE_ID＝IMSI mod 1024获得，UE寻呼标识可以是核心网S-TMSI或IMSI，其中，S-TMSI是源于核心网的SAE临时移动用户标识(SAE temporary mobile subscriberidentity)，IMSI是UE的国际移动用户识别码(international mobile subscriberidentity)。可以理解，NR系统中核心网的UE寻呼标识可以是其他名称，本文不做限制。上述这2个值可用于计算寻呼帧(paging frame，PF)和寻呼时机(paging occasion，PO)。当涉及寻呼是基于核心网产生的寻呼(CN based paging)时，CU向DU提供的UE的标识信息(比如UE的寻呼标识)是源于核心网的，该UE的寻呼标识信息可以是核心网S-TMSI和/或IMSI；当涉及寻呼是基于RAN侧产生的寻呼(RAN-based paging)时，CU提供的该UE的寻呼标识信息是resume ID或者是一个在RAN侧产生的用于寻呼过程的UE标识的信息。可选的，所述UE寻呼标识可以是DU主动提供给CU的，或者基于CU请求发送给CU的。DU根据预设的配置，识别其收到的是核心网产生的UE的寻呼标识的信息(比如可以是核心网TMSI或IMSI)，还是在RAN侧产生的UE的寻呼标识信息(比如可以是resume ID或者是一个在RAN侧产生的用于寻呼过程的UE标识的信息)。可选的，DU可以根据寻呼类型确定UE的非连续接收周期。可选的，当DU识别是基于核心网的寻呼时，DU确定UE的最终的非连续接收周期可以包括：核心网发送的UE特定的DRX周期，以及小区广播的默认DRX周期中取较小值(还可以是对应于该取得的较小值的一个值)。可选的，当DU识别是基于无线接入网的寻呼时，DU确定UE的最终的DRX cycle可以包括：核心网发送的UE specific DRX cycle，UE接收到的RRC消息中携带的RAN侧UEDRX cycle以及小区广播的default DRX cycle中取较小值(还可以是对应于该取得的较小值的一个值)。一种可能的情况是，如果其中个别DRX cycle不存在，则剩余的1个或多个DRXcycle取较小值。

DU收到上述F1AP的寻呼消息后，可选的，在操作402中，DU将用于指示寻呼类型的指示信息发送给UE，具体的，可以将该UE的寻呼标识的信息放入广播寻呼消息中(比如携带在信元PagingRecord中)在空口广播，和/或，在给UE的广播寻呼消息中携带指示以使得UE能够获知该寻呼是基于RAN侧产生的寻呼，还是基于CN产生的寻呼，例如，可以在PagingRecord里面给出是否为RAN based paging的指示，比如0表示CN based paging，1表示RAN based paging。可选的，UE可以基于所述指示判断是基于核心网的寻呼，还是基于无线接入网的寻呼。和DU类似地，UE可以根据寻呼类型确定最终的非连续接收周期。根据操作 401的可选设计2，包括：CU向DU发送的寻呼消息中包括被寻呼UE的标识的信息；则，当该用于指示寻呼类型的指示信息表明涉及的寻呼是基于核心网产生的寻呼或基于无线接入网产生的寻呼，该指示信息被用于使得DU获知涉及的寻呼是基于核心网产生的寻呼或该寻呼是基于无线接入网产生的寻呼的具体过程，包括：

该指示信息指示了该被寻呼UE的标识的信息是源于核心网时，则表明该寻呼是基于核心网产生的寻呼，该指示信息并被用于使得DU获知涉及的寻呼是基于核心网产生的寻呼；或者，该指示信息表明该被寻呼UE的标识的信息是无线接入网配置的，则表明寻呼是基于无线接入网产生的寻呼，该指示信息被用于使得DU获知该寻呼是基于无线接入网产生的寻呼。

可选地，CU在给DU发送的F1AP寻呼消息中除了UE寻呼标识(UE Paging identity)信元，还可以设置显示的信元用于指示，例如该指示可以是RAN based Paging指示，当该指示取值为0时表示所涉及的寻呼是基于核心网产生的寻呼，反之当该指示取值为1时则表示所涉及的寻呼是基于无线接入网产生的寻呼。或者该指示可以是CN based Paging指示，当该指示取值为0时表示该寻呼是基于无线接入网产生的寻呼，反之当该指示取值为1时表示该寻呼是基于核心网产生的寻呼。

根据操作401的可选设计3，包括：该用于指示寻呼类型的指示信息中包括：源于核心网的被寻呼终端设备的标识的信息或无线接入网配置的被寻呼终端设备的标识的信息。可选的，该指示信息中可以设置两个信元，一个信元用于携带该源于核心网的被寻呼终端设备的标识的信息，另一个信元用于携带该无线接入网配置的被寻呼终端设备的标识的信息，但发送该指示信息时，可以择一发送这两个信元所携带的信息。比如，当所述指示信息中包括源于核心网的被寻呼终端设备的标识的信息时，则所述指示信息表明所述寻呼是基于所述核心网产生的寻呼，并被用于使得所述分布式单元获知所述寻呼是基于所述核心网产生的寻呼；或者，当所述指示信息中包括无线接入网配置的被寻呼终端设备的标识的信息时，则所述指示信息表明所述寻呼是基于所述无线接入网产生的寻呼，并被用于使得所述分布式单元获知所述寻呼是基于所述无线接入网产生的寻呼。

示例性的，通过CU向DU发送的F1AP的寻呼消息中的一个信元携带CN侧配置的UE的标识信息，表明该寻呼是基于CN侧产生的寻呼，或者，通过CU向DU发送的F1AP的寻呼消息中的另一个信元携带RAN侧配置的UE的ID信息，表明该寻呼是基于RAN侧产生的寻呼。具体的，在一种可选设计中：如果是基于CN产生的寻呼(CN based paging)，则CU发给DU的F1AP的寻呼消息中包含UE寻呼标识UE Paging identity可以携带CN侧分配的UE的标识信息；如果是基于RAN侧产生的寻呼(RAN-based paging)，则CU发给DU的F1AP的寻呼消息中包含新设置的信元，例如该信元是UE无线接入网寻呼标识(UE Paging identity for RAN basedPaging)，该信元可以携带RAN侧分配的UE的标识信息。

又例如，在CU给DU发送的F1AP寻呼消息中可另行设置新的IE，通过该新的IE使CU向DU提供resume ID或者是在RAN侧产生的用于寻呼过程的UE标识的信息，以表示涉及的寻呼类型是RAN based paging，具体的，该新的IE可以是UE Paging Identity for RANbased paging。

DU收到含有该新的IE的F1AP的寻呼消息后，可选的，在操作402中，DU可以将收到的resume ID或者该RAN侧产生的用于寻呼过程的UE标识的信息(比如，UE PagingIdentity for RAN based paging)携带在空口广播的寻呼消息中发送给UE(比如在信元PagingRecord中)，或者，在给UE的广播寻呼消息中携带指示以使得UE能够获知该寻呼是基于RAN侧产生的寻呼还是基于CN产生的寻呼，例如，可以在PagingRecord里面给出是否为RAN based paging的指示，比如0表示CN based paging，1表示RAN based paging。这样，使得操作402得以执行DU将用于指示寻呼类型的指示信息发送给UE。

需要说明的是，本操作401为可选操作，也就是说，CU也可以不发送寻呼类别的指示信息给DU，具体的寻呼类型由DU自主判断。比如，对于RAN-based paging和CN basedpaging这两种情况，在CU和DU之间可以都使用源于核心网的UE的标识信息，但是DU在空口对CN based paging和RAN based paging这两种情况进行区分，可选的，在操作402中，在DU发送的广播寻呼消息中，携带是否为RAN based paging的指示，具体的，可以在信元PagingRecord里面给出是否为RAN based paging的指示比特，当该比特取值为0时，表示该寻呼是CN based paging，当该比特取值为1时，表示该寻呼是RAN based paging。可以理解，具体取值代表的含义可以有不同的方式，比如，当该比特取值为1时，表示该寻呼是CNbased paging，当该比特取值为0时，表示该寻呼是RAN based paging。

可以理解，对于系统400中的CU可以按照图3的方式进一步划分成CP和UP，对于CP和UP进一步分离的架构，那么系统400中前述CU的功能可以由CP来实现，当然，系统400中前述CU的功能也可以放在UP中实现。

可以理解，前述任一设计中所称的RAN侧配置的UE的标识的信息，也可以在RAN侧配置的其他可用于标识UE的信息，只要配置的UE的相关信息能够标识这个UE，或者有助于找到该UE的上下文，或者有助于标识针对该UE的寻呼类型。可以理解，本文所称的“RAN侧配置”，即可是RAN侧中的CU执行该配置，也可以是DU执行该配置，或者是CU和DU通过协商来完成配置，比如，针对RAN侧发起的寻呼，由CU或由DU或由CU结合DU共同来为该寻呼配置一个能够标识该UE的信息，以有助于在DU侧能够识别该寻呼的类型是核心网发起的寻呼，还是在无线接入网发起的寻呼。

如图5所示，本申请实施例还提供了一种通信系统及其运行方法500，以有助于解决当UE进入非激活态时，CU通知DU释放该UE的UE上下文的机制中尚存在的缺陷。该系统500具有CU和DU，当该系统500运行时，通过CU和DU之间交互消息，以执行如下示例性的方法500：

CU给DU发送用于释放UE上下文的消息，比如该消息可以是UE上下文释放消息UEcontext release message)，该消息中包含用于表示该UE进入RRC非激活态(UE enterinto inactive)的原因值信息；或者，CU给DU发送用于释放UE上下文的消息，比如该消息可以是UE上下文释放消息UE context release message)，在该消息中可以携带发送给UE的用于释放RRC连接的消息，例如RRC连接释放消息(RRC connection release message)；或者，CU也可以在其他F1AP消息，例如DL RRC message transfer消息中携带RRC connectionrelease，该消息中也可以包含原因值(例如UE enter into inactive)和/或RRC消息类型。那么DU后续收到CU发送的UE context release消息时，则可以获知UE进入RRC非激活态，故要释放该UE的上下文。另一种可能的情况，DU获知UE进入RRC非激活态，保留UE上下文，挂起无线信令和/或无线数据承载。

一种可选设计包括：对于出现上行数据到达(UL data arrival)的场景：DU尚未将CU发送的RRC释放消息转发给UE时，收到UE发送的SR/BSR，DU获知UL data arrival。DU通知CU拒绝释放UE上下文，可选的，通知消息中包含原因值为出现上行数据到达(UL dataarrival)。可选的，在此之前，DU发送通知消息中可携带DU判断UE进入非激活态的信息，通知消息的实现方式，可以是active/inactive指示，或者inactive timer到时的指示。若DU在发送通知消息通知CU UE进入inactive态后，尚未收到CU的回复，就发现有上行数据到达(UL data arrival)，则DU通知CU该情况(即UL data arrival)，以便CU及时作出正确的决策，例如，CU可以决策UE不能进入RRC非激活态。

一种可选设计包括：对于出现下行数据到达(DL data arrival)的场景：CU给DU发送UE context release和/或RRC释放消息后，出现下行数据到达(DL data arrival)的情况，可选的，CU判断DU可能存在尚未释放UE上下文和/或转发RRC释放消息的情况，进一步可选的，CU将发送UE context release cancel消息和/或DL RRC message transfer cancel消息给DU，该消息中包含原因值(例如DL data arrival)，可选的，该消息还可包含paging信息(例如resume ID，paging DRX，UE Identity Index value，Paging priority，以及UEpaging identity中的至少一个，或者前面操作401的三种可选设计中包含的信元。DU如果取消发送RRC释放消息和/或未释放UE上下文，则通知CU未释放UE上下文或者UE未进入RRC非激活态。如果出现DU已经转发了RRC消息且释放了UE上下文的情况，则可以基于paging信息直接发起RAN-based paging。

进一步的，对于CU具有CP-UP架构时，一种可选设计包括：CU中的CP(CU-CP)给DU和/或CU中的UP(CU-UP)发送UE context release消息，该消息中包含原因值UE enterinto inactive。或者CU-CP也可能在另一条F1AP消息，例如DL RRC message transfer消息中携带RRC connection release，该消息中也可以包含原因值UE enter into inactive或者RRC消息类型。那么后续DU收到CU发送的UE context release消息则可以推测是由于UEenter into inactive才需要释放UE上下文。另一种可能的情况，DU获知UE进入RRC非激活态，保留UE上下文，挂起无线信令和/或无线数据承载。

一种可选设计包括：对于出现上行数据到达的情况(UL data arrival)：可以参考前述CU-DU架构的描述，CU的功能可以在CP中实现。

一种可选设计包括：对于出现下行数据到达的情况(DL data arrival):假设CU-UP通知CU-CP关于UE处于非激活状态的信息，CU-UP可通过CU-CP提供的timer到时间来判定UE是否进入非激活态。若CU-UP尚未收到CU-CP发送的UE进入inactive态或UE contextrelease指示，则：

可选操作1：CU-UP发送DL data arrival指示给CU-CP，例如在E1接口消息中包含E1接口UE标识例如gNB-CU-UP UE E1APID，DL data arrival指示等。CU-CP收到CU-UP的DLdata arrival指示消息后，后续操作可参考前述CU-DU架构的描述，CU的功能在CU-CP实现。当CU-CP通知DU后，且获知UE未进入inactive态时，CU-CP通知CU-UP可以发送下行数据DLdata给DU。

可选操作2：CU-UP直接将DL data arrival指示或下行数据DL data发送给DU，DU收到DL data arrival或DL data，则取消发送RRC连接释放消息给UE，可选的，DU通知CU-CP未释放UE上下文或者UE未进入inactive态，通知消息中还可以包含DL data arrival指示。

一种可选设计包括，CU监视下行传输状态，DU监视上行传输状态并将上行传输状态为active/inactive上报给CU。其中DU决定上行传输状态时可能使用定时器，该定时器可以是DU自行设置，也可以是CU提供定时器给DU。DU上报上行传输状态时，可以按照UE粒度、PDU会话粒度、slice粒度或DRB粒度。针对UE粒度，DU可以上报例如UE标识和active/inactive指示。针对PDU会话或slice粒度或DRB粒度，DU可以上报例如UE标识，PDU会话标识/slice标识/DRB标识，以及对应PDU会话/slice/DRB的active/inactive状态。可选的，定时器也可以是PDU会话/slice/DRB粒度的，即每个PDU会话标识/slice标识/DRB标识分别对应一个定时器。

一种可选的设计包括，DU监视上行传输状态和下行传输状态，并上报上行传输状态和下行传输状态给CU。其中定时器可以即针对上行，又针对下行。或者上行定时器针对上行传输，下行定时器针对下行传输。所述定时器可以是DU自行设置，也可以是CU提供定时器给DU。特别地，DU上报上行传输状态时，可以按照UE粒度、PDU会话粒度、slice粒度或DRB粒度。DU上报下行传输状态时，也可以按照UE粒度、PDU会话粒度、slice粒度或DRB粒度。

本申请实施例还提供了一种通信方法，该通信方法运行在通信系统中，该通信系统包括集中式单元和分布式单元，在该通信系统运行时，可执行如下示例性的操作：集中式单元拒绝终端设备的接入请求；该集中式单元向分布式单元发送指示信息；该指示信息用于表明该分布式单元需要删除该终端设备的上下文信息。其中，一种可选设计包括：该指示信息包含：拒绝该终端设备接入的指示和/或拒绝该终端设备接入的原因的信息。其中，一种可选设计包括：该集中式单元接收来自于该分布式单元发送的关于允许该终端设备接入的通知消息。通过该系统及方法的运行，有助于解决现有技术中UE进行接入网络时，存在准入控制机制不完善而导致系统出错的问题。具体的，以下结合附图6和附图7对本实施例作进一步说明。

如图6所示，本申请实施例提供了一种通信系统及方法600，该系统包括CU，DU以及UE这三个网络节点，其中CU和DU构成基站系统。如图6所示，该系统和方法600运行的一个示例包括：

可选操作601：UE向基站系统发送消息3。该消息3中可以包含RRCConnectionRequest，或RRCConnectionResumeRequest(或者可以是其他类似的消息，消息名称可以不同)，或者RRCConnectionRestablishmentRequest。

可选操作602：DU向CU发送消息3。可选的，DU收到UE发送的消息3后，DU向CU发送CU-DU接口消息，例如F1AP消息，该F1AP消息中可包含UE的消息3。可选的，上述F1AP消息还可包含DU给CU的容器(container)，其中携带UE的SRB1的L1/L2配置例如小区组配置CellGroupConfig。示例性的，上述F1AP消息可以为Initial UL RRC Message。一种可能的情况是，DU判断是否允许该UE的接入，若允许，则在F1AP消息中包含上述DU给CU的容器例如DU to CU RRC information，里面包含小区组配置；反之，若DU不允许该UE的接入，则上述F1AP消息不包含DU给CU的容器。从而，CU可以获知DU是否允许该UE的接入。

CU收到UE发送的消息3后，可以回复消息4(流程如图6所示可选操作603和604)。其中，具体的，CU判断是否允许UE的接入，若拒绝UE的接入，则消息4中包含与消息3中内容对应的，表示拒绝UE接入的RRC消息，例如RRCConnectionReject,RRCConnectionReestablishmentReject。可选的，CU向DU发送F1AP消息，其中携带拒绝指示和/或拒绝原因值，用于告知DU，CU拒绝了UE的接入，从而触发DU删除该UE的上下文(如图6所示可选操作603)。示例性的，DU删除该UE的上下文的动作包括如下中的至少一项：DU释放为UE分配的C-RNTI/TempCRNTI，DU释放为UE预留的资源，DU删除该UE的L1/L2配置，以及DU释放为UE分配的DU UEF1AP ID。可选的，上述F1AP消息为DL RRC Message Transfer。可选的，CU决定拒绝UE的接入的原因可以为DU拒绝，或者CU自己拒绝。一种可能的情况是，若CU得知DU拒绝UE的接入，CU无需向DU发送拒绝指示；可选的，若CU得知DU允许UE的接入，而CU不允许UE的接入，CU需要向DU发送拒绝指示，从而通知DU删除该UE的上下文。

如图7所示，本申请实施例提供了一种通信系统及方法700，该系统包括CU，DU以及UE这三个网络节点，其中CU和DU构成基站系统。通过该系统及方法700的运行，有助于解决现有技术中UE进行接入网络时，存在准入控制机制不完善而导致系统出错的问题。如图7所示，该系统和方法700运行的一个示例包括：

可选操作701：UE向基站系统发送消息3。该消息3中可以包含RRCConnectionRequest，或RRCConnectionResumeRequest(或其他类似的消息，名称可能不一样)，或者RRCConnectionRestablishmentRequest。

可选操作702：DU向CU发送消息3。DU收到UE发送的上述消息3后，将该消息3发送给CU。可选的，DU向CU发送F1AP消息，该F1AP消息中包含UE的消息3。可选的，上述F1AP消息还包含DU给CU的容器(container)，其中携带UE的SRB1的L1/L2配置。示例性的，上述F1AP消息可以为Initial UL RRC Message。可选的，DU告知CU是否允许UE的接入。一种可能的情况是，DU判断是否允许该UE的接入，若允许，则在F1AP消息中包含上述DU给CU的容器；反之，若DU不允许该UE的接入，则上述F1AP消息不包含DU给CU的容器。从而，CU可以获知DU是否允许该UE的接入。

可选操作703：CU收到UE发送的消息3后，CU向UE回复消息4。可选的，CU判断是否允许UE的接入，若拒绝UE的接入，则该消息4中可包含与消息3中内容对应的，表示拒绝UE接入的RRC消息，例如RRCConnectionReject,RRCConnectionReestablishmentReject。可选的，CU向DU发送F1AP消息，其中携带上述消息4。示例性的，上述F1AP消息可以是DL RRCMessage Transfer。可选的，CU向DU发送拒绝指示和/或拒绝原因值，用于告知DU删除该UE的上下文。具体的，CU向DU发送F1AP消息，其中包含拒绝指示和/或拒绝原因值。示例性的，该F1AP消息为UE Context Release。具体的，DU删除该UE的上下文的动作包括如下中的至少一项：DU释放为UE分配的C-RNTI/Temp CRNTI，DU释放为UE预留的资源，DU删除该UE的L1/L2配置，以及DU释放为UE分配的DU UE F1AP ID。可选的，CU决定拒绝UE的接入的原因可以为如下至少一种：DU拒绝该UE接入，以及CU侧自身拒绝该UE接入。一种可能的情况是，若CU得知DU拒绝UE的接入，则CU无需向DU发送拒绝指示；若CU得知DU允许UE的接入，而CU不允许UE的接入，则CU需要向DU发送拒绝指示，从而通知DU删除该UE的上下文。

可以理解，前述各实施例中对操作/各种可选设计进行了顺序编号，但可理解的是，该顺序编号仅为了便于行文，并不意味着必须按照顺序编号来依次执行操作。

一种可选设计中，前述实施例中，CU-UP在物理上可以和CU-CP，DU分开部署，也可以集中部署。例如存在CU-CP，CU-UP，DU三个在物理上全部单独部署，或者CU-CP和DU在物理上集中部署，但是CU-UP单独部署，或者CU-CP和CU-UP在物理上集中部署，但是DU单独部署，或者CU-CP单独部署，CU-UP和DU集中部署等可能情况。

以上所示出的任一种设计，可以理解为针对特定场景或者特定技术问题而设计的技术方案，但并不能理解为实施本申请所记载技术内容所必须，其中的任一种设计可根据需要和其他设计相结合实施，以更有针对性的解决特定的客观技术问题。

一种可选设计中，在本申请实施例中，分布式单元DU具有RLC，MAC和PHY协议层的功能，集中式单元CU具有RRC，SDAP和/或PDCP协议层的功能，DU和CU所具有的协议层共同构成了基站所具有的RRC，SDAP，PDCP，RLC，MAC以及PHY或者RRC，PDCP，RLC，MAC以及PHY协议层架构设置。当然，在基站中对CU和DU之间的协议层划分也可以有其他的方式，举例如，DU具有MAC和PHY，则CU具有RRC，SDAP，PDCP和RLC或RRC，PDCP和RLC，此处不做限定。DU在物理上可以和射频系统为一个通信设备的两个部分从而实现两者集成在一起，所述DU和CU也可以物理上作为同属于一个通信设备的部分从而实现两者集成在一起，或者，射频系统和DU以及CU物理上也可以作为同属于一个网络节点的部分从而实现三者可以集成在一起。

可以理解的是，对于前述实施例所涉及的UE，CU，DU，CP，以及UP，可通过具有处理器和通信接口的硬件平台执行程序指令来分别实现其在本申请前述实施例中任一设计中涉及的功能，基于此，如图8所示出的，本申请实施例提供了一种通信设备800的示意性框图，所述通信设备800包括：

至少一个处理器801，可选包括通信接口802，该通信接口用于支持该通信设备800和其他设备进行通信交互；当程序指令在所述至少一个处理器801中执行时，本申请前述实施例任一设计中在如下任一设备上操作的功能得以实现：UE，CU，DU，CP以及UP。一种可选设计中，该通信设备800还可以包含存储器803，以存储实现上述设备功能所必须的程序指令或者程序执行过程中所产生的过程数据。可选的，该通信设备800还可以包含内部的互联线路，以实现该至少一个处理器801，通信接口802以及存储器803之间的通信交互。该至少一个处理器801可以考虑通过专用处理芯片、处理电路、处理器或者通用芯片实现。例如，对于实施例中涉及的DU中PHY功能的全部或者部分的处理，或者涉及的F1口或者E1口上的全部或者部分的协议通信功能，可以在该至少一个处理器中设置专用电路/芯片来实现，当然也可以通过该至少一个处理器801中设置的通用处理器执行具有PHY功能，F1口或者E1口通信功能相关的程序指令来实现；又例如，对于本申请实施例涉及设备中的MAC层，RLC层，PDCP层，SDAP层以及RRC层的相关功能的全部或者部分处理，该至少一个处理器801可以包含通信处理芯片，通过执行MAC层，RLC层，PDCP层，SDAP层以及RRC层的相关功能的程序指令来实现。可以理解的是，本申请实施例描述的各种设计涉及的的方法，流程，操作或者步骤，能够以一一对应的方式，通过计算机软件，电子硬件，或者计算机软件和电子硬件的结合来一一对应实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件，比如，考虑通用性好成本低软硬件解耦等方面，可以采纳执行程序指令的方式来实现，又比如，考虑系统性能和可靠性等方面，可以采纳使用专用电路来实现。普通技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，此处不做限定。

该通信接口802，通常具有为两个通信对端之间执行进行信息交互的功能，对于通信对端之间执行的是有线形式的信息交互的情况，通信接口可以设计成接口电路，或者包含该接口电路的硬件模块，以支持通信对端之间进行的有线形式的通信交互，比如本申请中涉及的DU和CU之间的F1口，CP和UP之间的E1口的通信功能，可以采纳这种形式的接口设计；对于通信对端之间执行的是无线形式的信息交互的情况，通信接口可以是具有射频收发功能的接口电路，或者是包含该具有射频收发功能的接口电路的硬件系统，比如在DU和UE之间进行无线通信时，那么DU和UE的通信接口可以采纳这种设计。

可选的，对于CU，DU，CP或者UP的实现，也可以通过采用通用硬件平台(具有处理资源，存储资源)直接或者间接执行实施例相关设计的实现性程序指令来完成CU，DU，CP或者UP在本申请实施例各设计中的功能。一种实际部署方式可以是，CU，CP或者UP可以和核心网设备就近，或者协同部署，物理上可以分开也可以合一；CU，CP或者UP的功能也可以作为核心网设备的一部分。

本申请实施例还提供了一种计算机程序产品，该计算机程序产品具有程序指令，当该程序指令被直接或者间接执行时，比如，在前述实施例中的通信设备800中被执行时，使得本申请实施例任一设计中在如下任一设备的功能得以实现：UE，CU，CP，UP以及DU。可以理解的是，所述程序指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述程序指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。程序指令被执行时，考虑到具体的网络设备中一般包括硬件层、运行在硬件层之上的操作系统层和/或中间层，与本申请实施例相关的程序指令被执行时，往往经过多层软件的调用和执行，因此该程序指令在硬件设备(通用处理电路或者专用处理电路)可以是一种间接的执行过程。

本申请实施例还提供了一种芯片系统，所述芯片系统包括至少一个处理器，当程序指令在所述至少一个处理器中执行时，使得如第一方面及其任一所述的设计中在如下任一设备上的功能得到实现：UE，CU，DU，CP，以及UP。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (9)

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

集中式单元根据被寻呼终端设备的寻呼是源于核心网或者是源于无线接入网，确定指示信息，其中，确定所述指示信息包括在所述寻呼是源于核心网的寻呼时，将所述指示信息设置为来自所述核心网的被寻呼终端设备的身份信息，或者，在所述寻呼是源于无线接入网的寻呼时，将所述指示信息设置为由所述无线接入网生成的被寻呼终端设备的标识信息；

所述集中式单元向分布式单元发送寻呼消息，所述寻呼消息中携带所述指示信息。

2.如权利要求1所述的通信方法，其特征在于，所述指示信息被所述分布式单元发向所述被寻呼终端设备。

3.如权利要求1或2所述的通信方法，其特征在于，所述指示信息包括：源于所述核心网的被寻呼终端设备的标识或所述无线接入网配置的被寻呼终端设备的标识。

4.如权利要求1或2所述的通信方法，其特征在于，

所述指示信息是源于所述核心网的被寻呼终端设备的标识的信息，则所述指示信息被用于表明所述寻呼是源于所述核心网的寻呼，并被用于使得所述分布式单元获知所述寻呼是源于所述核心网的寻呼；或者，

所述指示信息是所述无线接入网配置的被寻呼终端设备的标识的信息，则所述指示信息被用于表明所述寻呼是源于所述无线接入网的寻呼，并被用于使得所述分布式单元获知所述寻呼是源于所述无线接入网的寻呼。

5.如权利要求3或4所述的通信方法，其特征在于，所述源于所述核心网的被寻呼终端设备的标识为所述被寻呼终端设备的临时移动用户标识TMSI或者国际移动用户识别码IMSI。

6.一种通信设备，其特征在于，所述通信设备包括：至少一个处理器和通信接口，所述通信接口用于所述通信设备与其他通信设备进行信息交互，当程序指令在所述至少一个处理器中执行时，使得所述通信设备实现如权利要求1-5中任一所述的方法。

7.一种计算机程序存储介质，其特征在于，所述计算机程序存储介质具有程序指令，当所述程序指令被计算设备执行时，实现如权利要求1-5中任一所述的方法。

8.一种芯片系统，其特征在于，所述芯片系统包括至少一个处理器，当程序指令在所述至少一个处理器中执行时，使得所述芯片系统实现如权利要求1-5中任一所述的方法。

9.一种通信系统，其特征在于，所述通信系统包括：集中式单元和分布式单元，

所述集中式单元根据被寻呼终端设备的寻呼是源于核心网或者是源于无线接入网，确定指示信息，其中，确定所述指示信息包括在所述寻呼是源于核心网的寻呼时，将所述指示信息设置为来自所述核心网的被寻呼终端设备的身份信息，或者，在所述寻呼是源于无线接入网的寻呼时，将所述指示信息设置为由所述无线接入网生成的被寻呼终端设备的标识信息；

所述集中式单元向所述分布式单元发送寻呼消息，所述寻呼消息中携带所述指示信息；

所述分布式单元接收所述寻呼消息。

Images