多集中单元CU融合方法、相应设备及系统与流程

本发明涉及通信领域，特别是涉及一种多集中单元cu融合方法、相应设备及系统。

背景技术：

现有技术中，基站系统架构包括集中式基站系统(c-ran)和分布式基站系统(d-ran)。目前，c-ran中依然存在射频拉远覆盖的传输问题，无法满足高吞吐量的要求。

因此5g(5th-generation，第五代移动通信技术)中采用了改良的c-ran方式：针对同一个基站(gnodeb，gnb)提出cu-du分离的垂直架构，将同一个逻辑基站切分为集中单元(centralizedunit，cu)和分布单元(distributedunit，du)两部分，每个逻辑基站只有一个cu，但du可以是多个，按协议分离后的gnb-cu与gnb-du通过f1口连接。

而多个cu集中部署继承c-ran，可以进一步缓解集中单元和分布单元的传输瓶颈，但存在资源浪费、开销大、实时性差等问题。

技术实现要素：

为了克服上述缺陷，本发明要解决的技术问题是提供一种多集中单元cu融合方法、相应设备及系统，用以至少解决在cu-du分离架构下，多个cu部署存在资源浪费的问题。

为解决上述技术问题，本发明实施例中的一种多集中单元cu融合系统，包括m个cu和cu中心；

所述cu中心用于根据预设的各个业务需求，对所述m个cu设置共用的1个或多个对应级别功能模块；通过所述对应级别功能模块，向各个cu提供相应级别功能服务；所述m大于或等于1。

为解决上述技术问题，本发明实施例中的一种多集中单元cu融合方法，包括：

根据预设的各个业务需求，对预先选择的多个cu设置共用的1个或多个对应级别功能模块；

通过各级别功能模块，向各个cu提供相应级别功能服务。

为解决上述技术问题，本发明实施例中的一种多集中单元cu融合设备，包括存储器和处理器；所述存储器存储有多cu融合计算机程序，所述处理器执行所述计算机程序，以实现如上所述方法的步骤。

本发明有益效果如下：

现有技术中每个cu分别具有相应级别功能模块，从而存在资源浪费、开销大、实时性差等问题，本发明实施例将集中部署的多个cu功能整合，对多个cu设置共用的各个对应级别功能模块，打破了cu间资源的约束，有效解决了cu间资源共享的问题，有效解决了在cu-du分离架构下，多个cu部署存在资源浪费的问题。

附图说明

图1是本发明实施例中cu中心的结构示意图；

图2是本发明实施例中各级别功能模块融合过程示意图；

图3是本发明实施例中融合系统的整体架构图；

图4是本发明实施例中ue切换流程图；

图5是本发明实施例中一种多集中单元cu融合方法的流程图；

图6是本发明实施例中一种多集中单元cu融合设备的结构示意图。

具体实施方式

为了解决现有技术的问题，本发明提供了一种多集中单元cu融合方法、相应设备及系统，以下结合附图以及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不限定本发明。

在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身没有特定的意义。因此，“模块”、“部件”或“单元”可以混合地使用。

使用用于区分元件的诸如“第一”、“第二”等前缀仅为了有利于本发明的说明，其本身没有特定的意义。

为了使本发明实施例的描述简洁，首先简述本发明实施例中涉及的技术术语，如下表：

实施例一

本发明实施例提供一种多集中单元cu融合系统，所述系统包括m个cu和cu中心；

所述cu中心用于根据预设的各个业务需求，对所述m个cu设置共用的1个或多个对应级别功能模块；通过所述对应级别功能模块，向各个cu提供相应级别功能服务；所述m大于或等于1。

本发明实施例将集中部署的多个cu功能整合，打破了cu间资源的约束，有效解决了cu间资源复用的问题，有效解决了在cu-du分离架构下，多个cu部署存在资源浪费的问题。

在本发明实施例中，可选地，所述cu中心包括选择模块和所述对应级别功能模块；

所述选择模块用于从n个cu中选取m个cu，并根据预设的各个业务需求，在所述cu中心内，对所述m个cu设置共用的1个或多个对应级别功能模块；所述n大于或等于1；所述m小于或等于n；

所述对应级别功能模块用于向各个cu提供相应级别功能服务。

其中，所述对应级别功能模块包括用于提供基站级功能服务的基站级模块、用于提供小区级功能服务的小区级模块和用于提供用户级功能服务的用户级模块。

具体说，如图1所示，本发明实施例中cu中心包括一个或多个逻辑基站的cu。对外呈现独立的cu集合，接口不变。内部根据业务需求上的差异，按照基站级、小区级和用户级融合，业务模块(或称之为功能模块)应用范围不再限定(cu内)，而是全局共享。以下对各级别功能模块进行详细描述。

基站级模块：

提供cu级功能服务，如cu与外部网元接口(f1、ng)的传输链路管理。

如图2所示，融合前，各cu基站级功能模块独立，传输链路只能在对应cu内使用，ue跨cu移动需要切换不同cu内的传输链路。

如图1所示，融合后，基站级模块在cu中心内共享，负责管理的所有cu对外的传输链路，不同传输链路需要使用基站标识(gnbid)和链路标识(链路id)唯一标识。也就是说，所述基站级模块还用于通过预设的基站标识和链路标识，标识各个cu的传输链路。

本发明实施例中，在外部网元不变的情况下，跨cu不需要切换传输链路。如ue在cu间切换，与核心网间的传输链路可以保持不变(cu中心内共享，ue使用任意cu内的ng接口传输链路都可以保持与核心网业务)，不需要切换ng接口传输链路，做到核心网不感知。

小区级模块：

提供cu内小区级功能服务，包括小区空口资源接纳，小区信息查询等。

如图2所示，融合前，各cu内小区独立管理，cu间小区不可见，小区级服务只能在各自cu内完成。如ue在不同cu的小区时，对应不同的小区级模块处理。

如图1所示，融合后，小区级模块在cu中心内共享，管理小区的范围扩大到多个cu，不同小区需要使用基站标识(gnbid)和小区标识(cellid)二级标识唯一确定。也就是说，所述小区级模块还用于通过预设的基站标识和小区标识，标识各个小区。

本发明实施例中，ue在跨cu移动时，源小区和目标小区业务可以集中在该模块处理，从而有效减少站间协作。

用户级模块：

提供cu内ue级功能服务，包括ue接入、切换、释放等业务流程的控制。

如图2所示，融合前，ue级功能处理只能在各自cu内进行，ue跨cu的业务需要使用两个或多个cu内的ue级服务，并且通过协作完成。并且在移动过程中，需要在不同cu内创建、释放或迁移用户级资源。

如图1所示，融合后，用户级模块在cu中心内共享，可以跨逻辑cu提供ue级服务，统一ue在cu中心内的标识，集中处理所有ue的业务流程，资源不需要多个cu内重复创建、释放或迁移。

以上各级别功能模块在cu中心内都可以提供全局服务，其中用户级模块是ue业务流程处理的核心模块，基站级模块为ue级模块提供传输链路服务，如提供ue专用信令的转发功能，小区级模块提供小区接纳等服务，从而在融合后，cu中心内的ue业务流程得到简化。

在本发明实施例中，可选地，如图3所示，所述融合系统还可包括配置管理模块、资源平台模块、资源管理模块中的一个模块或多个模块。

其中，配置管理模块(简称配置管理)：

用于在后台对cu中心进行配置，例如：

cu中心作为单独网络功能(nf)配置，nfid标识。nf下配置一个或多个cu，以及各cu的对应参数。参数可以划分为：cu全局级参数、基站级参数、小区级参数、用户级参数。其中cu全局级参数对应的是cu中心内所有cu的共同参数。基站级参数对应各cu内所有小区共有参数，小区级参数对应各小区特有参数。用户级参数则对应于用户特有参数。后台通过管理面与cu中心各模块同步配置参数。

资源平台模块(简称资源平台)：

作为支撑cu中心的通用平台系统，为cu中心各模块提供运行环境和系统资源，支持动态资源调整。执行后台资源管理下发的控制命令和策略。

资源管理模块(简称资源管理)：

用于在后台提供资源编排功能，负责定义系统资源规格，设置资源调整策略等，通过资源平台管理cu中心各模块的系统资源。具体的，为各模块分配的初始系统资源，设置资源调整策略和粒度，策略包括基于cpu利用率等系统资源指标和基于业务模块注册的kpi指标两种方式，两种方式都要在后台配置资源扩展和回收阈值门限。一旦指标达到门限，资源平台根据预先设置的资源粒度调整各模块资源。也就是说，所述资源管理模块用于基于功能模块粒度，对所述cu中心的各级别功能模块分配相应资源；以及还用于针对每一级别功能模块，根据与该功能模块对应的业务需求变化，按照预设的资源调整策略，调整分配的相应资源。

以上各模块的关系如下：

初始创建cu中心时，后台配置管理负责配置cu中心以及内部各模块参数，同时，后台资源管理负责cu中心内各模块系统资源分配，并通知资源平台执行。然后，cu中心各模块在资源平台上加载，同步后台配置，完成cu中心的创建。cu中心内各模块运行过程中，与资源平台交互，根据资源管理设置的策略，可以动态调整模块的系统资源。

综上所述，本发明实施例中cu中心的资源由后台资源管理通过资源平台分配，资源基于业务模块粒度分配，而非cu粒度，资源分配大小按照各模块的业务需求设定。例如，基站级模块资源参考支持的最大传输链路数，小区级模块资源参考支持的最大小区数量，用户级模块资源参考支持的最大用户数，不同等级的业务需求分配不同等级的资源，对应资源平台的分配单元(资源规格，如cpu1核+1g内存)。

并且cu中心内各模块可以采用多实例负荷分担的设计，每个实例的功能相同，各模块的所提供的服务可以分配给不同实例同时处理。每个实例对应资源平台配置的资源分配单元，初始资源分配时，资源平台根据业务需求为各模块分配资源来创建一定数量的实例。在模块运行过程中，模块资源可以动态调整，具体调整方法：

资源调整通过业务模块与资源平台交互完成，触发动态调整的方式包括资源平台监控和业务模块反馈，其中，平台监控系统资源利用率，如cpu，内存达到配置门限会触发资源调整。业务模块向平台注册并反馈kpi指标，如吞吐量，激活用户数等达到门限会触发资源调整。

资源调整粒度细化到各功能模块的实例，当系统资源受限(或kpi恶化)则增加实例数扩充资源，反之，当业务资源空闲较多(或kpi提升)则减少实例数回收资源。各模块业务功能独立，资源调整互不影响，不受逻辑cu基站的约束。

因此，本发明实施例中融合系统，将集中部署的多个cu功能整合，打破了cu间资源的约束，解决了cu间资源复用的问题，解决了在cu-du分离架构下，多个cu部署存在资源浪费的问题；例如，在极端情况下行，单个逻辑cu内各类业务的处理能力(或容量)等于整个cu中心内所有cu的处理能力(或容量)之和，扩大了资源共享范围。

本发明实施例中在cu中心内，资源的分配和调整从cu级减小到功能模块级，细化了调整粒度；而且，资源类型也可以根据模块的具体业务需求分类，弹性伸缩更灵活更精确，提高资源利用率。

本发明实施例中cu中心内业务融合后，不仅减少用户站间移动的业务流程开销，而且减少不必要的资源迁移和切换；并且，站间协作的业务功能得到简化，更容易实现，而且有利于性能提升。

以下描述本发明实施例中融合系统的具体实现实例。

实例1

本实例描述cu中心根据选取的多个cu创建cu基站池的创建过程。

初始创建cu中心包括gnb1-cu和gnb2-cu，分别对应gnb1-du和gnb2-du，每个du对应一个小区。具体步骤如下：

步骤10：在后台配置管理中(图3)，先配置cu中心，作为网络功能(nf)一级的根节点，设置cu中心的nfid，并配置全局级参数，例如gnb1和gnb2相同的功能开关等。cu基站池下面添加gnb1-cu和gnb2-cu，分别配置对应gnbid，并配置基站级参数，包括gnb1和gnb2与外部网元间的传输链路信息，各自cu基站下所有小区共同的参数。然后，在gnb1-cu和gnb2-cu下分别添加各自的小区，配置对应的cellid和小区级参数，其中，gnb1配置一个小区cell1，gnb2配置一个小区cell1。在参数配置过程中，ue级配置根据使用场景配置，分布在全局级、基站级、或小区级配置。通过上述配置可以确定cu中心、cu基站、小区间对应关系和各级参数。

步骤11：在后台资源管理中编排平台资源(图3)，通过资源平台为各模块分配资源时，将cu中心作为整体考虑，不区分逻辑cu，由于gnb1-cu和gnb2-cu业务模块共享，极端情况下单个gnb-cu的业务容量等于cu中心内所有cu容量(gnb1-cu和gnb2-cu)之和，具体的，基站级模块需要支持gnb1-cu和gnb2-cu下所有传输链路数(通常为2条链路)，小区级模块需要支持gnb1-cu和gnb2-cu小区数之和(2个小区)，用户级模块需要支持所有cu对应的覆盖区域内的最大用户数(根据业务模型估计)。初始资源根据各模块单实例支持的最大容量确定分配的实例资源，如覆盖区域按照最多1万用户估计，假设用户级模块单实例支持6000用户，那么初始资源需要分配2个实例。同时，在资源管理中配置资源调整策略，见后续实施例说明。资源管理完成资源编排后，下发到资源平台，为cu中心内各模块分配资源。

步骤12：cu中心内各模块使用资源平台分配的资源加载运行，同时从后台配置管理获取配置参数，各级模块保存对应的标识和参数。多实例模块，如用户级模块，初始会加载两个实例，采用负荷分担的策略处理ue流程。各模块加载成功运行，并且成功获取后台配置参数后，cu中心创建完成。

本实例的一个应用场景如下：

商业区用户和住宅区用户分别由不同基站覆盖(如gnb1-cu和gnb2-cu)，白天商业区用户多，夜晚住宅区用户多，相应的gnb1-cu和gnb2-cu在不同时段业务量不同，在总体资源有限的情况下，传统集中部署方式下cu资源独立，需要动态调整两个覆盖区域的cu资源。本实施例创建的cu中心，可以将gnb1-cu和gnb2-cu融合，资源完全共享，不需要动态调整。

实例2

本实例用于说明cu中心内ue跨cu切换的业务流程，以便详细阐述cu间业务协作的简化方法。

本实例中所述配置管理模块用于在用户终端接入所述cu中心的任意cu时，对所述用户终端分配ue全局标识；

所述基站级模块还用于当所述ue在所述cu中心内进行cu间切换时，通过所述ue全局标识，使所述ue与核心网间的传输链路保持不变。

ue级标识说明：

ue全局标识，是ue接入时动态分配的，cu中心内唯一。

ue级接口标识，ue在逻辑cu各个接口上有内外标识对，其中，内部标识是接收ue消息时使用，由cu中心分配，外部标识是发送ue消息时使用，由外部网元分配。ue标识间存在映射关系，cu中心内ue全局标识唯一。接口对内标识在不同cu内唯一，cu中心内可能存在多个(移动性场景)。

参考图1，连接态的ue从gnb1-du移动到gnb2-du的过程中，会触发切换流程。ue业务流程处理以用户级模块为中心，其他模块提供协作服务。如小区管理模块负责资源接纳，基站级模块负责控制面信令的收发。具体说：

步骤20：用户级模块作为cu中心内用户控制流程处理的集中点，不同逻辑cu对应的外部网元(接口)发送的ue级信令，都会通过基站级模块汇聚到该用户级模块处理。ue通过测量报告触发切换时，用户级模块根据ue接口内部标识找到对应的全局标识(参考ue标识说明)，识别ue为cu中心内用户。

步骤21：切换过程中，ue所在的源小区和目标小区都在cu中心内，用户级模块向小区级模块进行目标小区的资源接纳，然后通过基站级模块与目标侧的du交互完成目标侧资源配置。该过程中，源侧du和目标du使用的是不同的传输链路(f1接口)，但都在基站级模块中管理。

步骤22：ue切换到目标小区后，在目标侧du发送切换完成消息，使用目标侧f1接口内部标识，该消息通过基站级模块转发到用户级模块。用户级模块识别ue切换成功后，通知小区级模块释放源小区空口资源，更新du侧的传输链路信息(从源侧切换到目标侧，包括uef1接口标识)，ng接口传输和标识保持不变，核心网不感知，切换流程结束。

上述步骤中，用户级模块负责集中处理ue在不同cu内的切换信令，维护ue在cu中心内和cu接口上的用户标识；小区级模块负责处理目标侧空口资源接纳和源侧空口资源删除；基站级模块负责切换ue在f1接口上的传输链路，保持ng接口链路不变。整个切换流程涉及的模块在cu中心内共享，不需要不同cu间协作，并且核心网不感知，简化了切换流程。

为了进一步说切换流程的简化方法，结合切换流程，对比如下：

在cu-du分离架构普通切换流程中，源侧和目标侧gnb-cu业务功能独立，需要通过xn口协作完成整个切换流程，包括切换请求和响应，以及目标侧的切换准备阶段的资源创建和源侧切换完成后的资源释放，而且在切换后需要与核心网交互，完成ng接口传输链路的切换。

在融合后的架构下的切换流程中，如图4所示，源侧和目标侧的gnb-cu资源都整合在cu中心内，业务流程处理都集中在用户级模块处理，源侧和目标侧业务资源共享，不需要在创建新的用户资源，也没有站间xn口的消息交互。切换过程中，共享原ng接口传输链路，不需要链路切换流程。

类似的，连接态ue在cu基站池内多个gnb-cu间连续切换，不需要xn口协作，不切换ng接口传输链路，可以做到核心网不感知。

实例3

本实例用于说明cu中心内根据业务需求调整资源的方法。

cu中心内(图3)，每个模块采用多实例负荷分担设计，各模块资源可独立扩展，当某个功能模块业务需求增加时，针对该模块资源进行弹性扩展，增加实例数。反之，当该模块业务需求减少时，可缩减对应的资源，减少实例数。具体的应用场景：

应用1：在后台资源管理中,设置用户级模块的资源调整策略基于kpi，如在线用户数，并设定调整门限，包括扩展门限和回收门限(如分别为10000和100)。

当cu中心内在线用户数增加到一定门限时(如超过10000)，用户级模块的向资源平台反馈，(平台)根据预设的资源调整策略对用户级模块进行弹性扩展，增加新的实例进行分担负荷，新接入的ue可以由新的实例处理，其他模块资源不变。当在线用户数减少到一定门限时(如低于100)，资源平台也会根据反馈，重新整合用户级模块资源，减少实例数，回收空闲资源。

应用2：在后台资源管理中，设置用户数据级模块的资源调整策略基于系统资源利用率，如cpu利用率，并设定调整门限，包括扩展门限和回收门限(如分别为80％和10％)。

当cu中心内并发用户数增加，cpu利用率达到一定门限时(如超过80％)，资源平台会主动监控并触发资源动态调整，根据预设的策略对用户级模块进行弹性扩展，增加新的实例分担负荷，其他模块不变。当并发用户数减少，cpu利用率降低到一定门限时(如低于10％)，资源平台重新整合用户级模块资源，减少实例数，回收空闲资源。

实施例二

本发明实施例提供一种多集中单元cu融合方法，所述方法包括：

s201，根据预设的各个业务需求，对预先选择的多个cu设置共用的1个或多个对应级别功能模块；

s202，通过各级别功能模块，向各个cu提供相应级别功能服务。

在本发明实施例中，可选地，所述根据预设的各个业务需求，对预先选择的多个cu设置共用的1个或多个对应级别功能模块，包括：

根据预先选择的多个cu创建cu中心；

根据预设的各个业务需求，在所述cu中心内，对所述多个cu设置共用的1个或多个对应级别功能模块。

在本发明实施例中，可选地，所述通过各级别功能模块，向各个cu提供相应级别功能服务之后，包括：

当用户终端接入所述cu中心的任意cu时，对所述用户终端分配ue全局标识；

当所述ue在所述cu中心内进行cu间切换时，通过所述ue全局标识，使所述ue与核心网间的传输链路保持不变。

在本发明实施例中，可选地，所述当用户终端接入所述cu中心的任意cu时，对所述用户终端分配ue全局标识之后，还包括：

通过预设的基站标识和链路标识，标识各个cu的传输链路；

通过预设的基站标识和小区标识，标识各个小区。

在本发明实施例中，可选地，所述方法还包括：

基于功能模块粒度，对所述cu中心的各级别功能模块分配相应资源。

其中，所述基于功能模块粒度，对所述cu中心的各级别功能模块分配相应资源之后，包括：

针对每一级别功能模块：根据与该功能模块对应的业务需求变化，按照预设的资源调整策略，调整分配的相应资源。

其中，所述对应级别功能模块包括用于提供基站级功能服务的基站级模块、用于提供小区级功能服务的小区级模块和用于提供用户级功能服务的用户级模块。

本发明实施例中方法，将集中部署的多个cu功能整合，打破了cu间资源的约束，解决了cu间资源复用的问题，解决了在cu-du分离架构下，多个cu部署存在资源浪费的问题；例如，在极端情况下行，单个逻辑cu内各类业务的处理能力(或容量)等于整个cu中心内所有cu的处理能力(或容量)之和，扩大了资源共享范围。

本发明实施例中在cu中心内，资源的分配和调整从cu级减小到功能模块级，细化了调整粒度；而且，资源类型也可以根据模块的具体业务需求分类，弹性伸缩更灵活更精确，提高资源利用率。

本发明实施例中cu中心内业务融合后，不仅减少用户站间移动的业务流程开销，而且减少不必要的资源迁移和切换；并且，站间协作的业务功能得到简化，更容易实现，而且有利于性能提升。

本发明实施例在具体实现时，还可以参阅实施例一。

实施例三

如图5所示，本发明实施例提供一种多集中单元cu融合设备，所述设备包括存储器40和处理器42；所述存储器40存储有多cu融合计算机程序，所述处理器42执行所述计算机程序，以实现如实施例二中任意一项所述方法的步骤。

实施例四

本发明实施例提供一种计算机可读存储介质，所述介质存储有多cu融合计算机程序，所述计算机程序被至少一个处理器42执行时，以实现如实施例二中任意一项所述方法的步骤。

本发明实施例中计算机可读存储介质可以是ram存储器、闪存、rom存储器、eprom存储器、eeprom存储器、寄存器、硬盘、移动硬盘、cd-rom或者本领域已知的任何其他形式的存储介质。可以将一种存储介质藕接至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息；或者该存储介质可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路中。

实施例三和实施例四在具体实现时，可以参阅实施例一和实施例二。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。