CN102907167B

CN102907167B - 通信***及其管理方法

Info

Publication number: CN102907167B
Application number: CN201180000751.8A
Authority: CN
Inventors: 刘晟; 程宏
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2011-05-17
Filing date: 2011-05-17
Publication date: 2016-01-20
Anticipated expiration: 2031-05-17
Also published as: WO2011127855A2; US20130017852A1; CN102907167A; RU2013155899A; WO2011127855A3; WO2011127855A8; US8467818B2; EP2525623A4; BR112013029651B1; EP2525623A2; EP2525623B1; RU2556081C1; BR112013029651A2

Abstract

本发明实施例提供通信***及其管理方法。该通信***包括：无线收发层，包括无线收发节点组合，至少包括宏小区RRU、微小区RRU、微小区BRU中的一种；本地计算层，包括本地计算节点，与一个或相邻的多个无线收发节点组合中的无线收发节点相连，用于执行该本地计算节点所对应小区的全部通信处理或第一部分通信处理；集中计算层，包括集中计算节点，与所述本地计算层中的本地计算节点相连接，用于执行第二部分通信处理，其中全部通信处理包括第一和第二部分通信处理。本发明实施例的本地计算层负责一定范围内的全部或部分通信处理，而不必将全部处理都交给较远的计算中心处理，节省了网络带宽，提高了***资源的利用效率。

Description

通信***及其管理方法

技术领域

本发明实施例涉及无线通信领域，并且更具体地，涉及通信***及其管理方法。

背景技术

蜂窝通信***中包括用户设备(UserEquipment，UE)，接入网(RadioAccessNetwork，RAN)和核心网(CoreNetwork)三个部分。其中UE是网络用户进行通信的工具，RAN负责空口资源的管理和一部分移动性管理，CN负责用户认证、计费、移动性管理、承载建立维护和数据路由。

LTE(LongTermEvolution，长期演进)以前的RAN包括基站和基站控制器两个部分。对于GSM(GlobalSystemofMobilecommunication，全球移动通讯***)/GPRS(GeneralPacketRadioService，通用分组无线服务技术***)，RAN由BS(BaseStation，基站)和BSC(BaseStationController，基站控制器)组成；对于UMTS(UniversalMobileTelecommunicationsSystem，通用移动通信***)***，RAN由NodeB和RNC(RadioNetworkController，无线网络控制器)组成。基站通过空口与UE进行通信，基站控制器对多个基站进行统一管理和调度。LTE采用了扁平化的网络架构，RAN只有eNodeB一个网元，它包括了以前NodeB的功能，基站控制器的功能也被分布到各个eNodeB节点。

从3G(3^rdGeneration，第三代)开始，分布式基站开始被广泛应用。分布式基站将传统基站分为基带处理单元(BasebandUnit，BBU)和射频拉远单元(RadioRemoteUnit，RRU)。RRU完成射频信号收发、降峰均比、数字预失真、上变频、DAC(Digital-to-AnalogConversion，数模转换)/ADC(Analog-to-DigitalConversion，模数转换)、功放等操作，它与BBU通过通用公共无线接口(CommonPublicRadioInterface，CPRI)等协议进行基带信息交互。现阶段BBU和RRU之间的物理连接多采用光纤。BBU+RRU的方式给站址布设带来了极大的灵活性，RRU的体积较小，容易布设在电线杆等位置，占用空间较小。通常大型建筑物内部的层间有楼板，房间有墙壁，室内与室内用户之间有空间分割，BBU+RRU多通道方案就是利用这一特性，对每个分割的空间部署一个RRU。对于超过10万平方米的大型体育场馆，可将看台划分为几个小区，每个小区设置几个通道，每个通道对应一面板状天线的RRU。BBU的体积较大，可以单独找机房放置。

移动通信网络通常采用蜂窝结构，即在不同地点架设不同的基站，每个基站形成一个小区，负责该区域内的移动用户的通信，为了保证移动用户能够获得无缝的连续的通信，相邻小区有一定的重叠区域，从而使得移动用户能够从一个小区切换到另外一个小区。在这种传统的单层小区***中，为了提高***的容量，需要提高每个小区的容量，通常这需要采用复杂的、成本高的技术来实现。但是，在一个较大区域内，并不是所有地方都需要很高的容量，多数情况下只有局部热点地区才需要，业务量需求比较小的其它区域，即使提供了容量，也没有用户使用，是一种***资源的浪费。也就是说，通过提高整个小区的容量的方式，是一种较低效率的方式。为此，一种较好的方式是采用多层小区结构(在3GPP的LTE标准中称为HeterogeneousNetwork，简称HetNet)，即首先用宏小区(Macro-cell)实现该区域的无缝连续覆盖，然后在热点采用小蜂窝(Pico或Femto等)重叠覆盖，小蜂窝针对热点地区内较大的业务量需求，提供很高的容量，从而实现***容量的“按需分配”。从***角度来看，这种方式是一种更加精确的、有的放矢的容量投放方式，避免了***资源的浪费。目前，HetNet已被认为是LTE中提高***容量的一个重要技术手段。

由于工作时间大部分的用户分布在工业区，而其它时间大部分用户分布在住宅区，这种用户的潮汐效应使得基站的计算资源不能得到充分利用。之前提出Cloud-RAN(C-RAN，云接入网)的接入网架构，目的是为了更加有效的利用基站的计算资源。

C-RAN将一个区域内的分布式基站BBU集中到一起形成一个BBU资源池，区域内的RRU对应的基带信号都在同一的BBU池进行处理，这样用户在该区域的流动性不会对计算资源的利用率产生影响。

BBU的集中可以通过光纤与较大区域内的RRU相连，如果BBU之间的交互带宽和时延允许，也可以通过将区域内的BBU互连形成BBU资源池。

由于BBU资源池集中处理多个小区的信号，所以C-RAN带来的另一个好处是为多小区之间的联合传输提供了方便。

但是在传统云接入网架构中，一个区域和小区只对应一个BBU资源池，所有的RRU都需要通过光纤连到BBU资源池。由于物理距离远还有所有的基带信号都必须送到BBU资源池进行处理，这样对光纤传输能力的要求很高。

对于HetNet场景，如果所有的微小区都需要通过光纤与远端的BBU池进行连接，那么大量的Pico会使得光纤铺设的成本和BBU池所需要的处理的数据量都成倍的提高。

本发明和传统C-RAN架构的主要优势在于极大的节省基站连接到云计算节点的带宽。在未来的通信网中小蜂窝数量增多，为现有宏蜂窝的数倍；频带成倍的提升；天线数量会急剧增加，由现在的最多4天线增加到几十甚至上百天线。如果还是使用传统云接入网架构，让所有基带数据都直接连接到几公里之外的云计算中心，对光纤传输将是极大的挑战。

发明内容

本发明实施例提供一种通信***及其管理方法，能够节省基站间数据的传输带宽，提高资源利用率。

一方面，提供了一种通信***，包括：无线收发层，包括一个或多个无线收发节点组合，其中每个无线收发节点组合中的无线收发节点至少包括宏小区射频单元、微小区射频拉远单元、微小区射频与基带拉远单元中的一种；本地计算层，包括一个或多个本地计算节点，其中每个本地计算节点与一个或相邻的多个无线收发节点组合中的无线收发节点相连，用于执行该本地计算节点所连接的无线收发节点组合所对应的小区的全部通信处理或第一部分通信处理；集中计算层，包括一个或多个集中计算节点，其中每个集中计算节点与所述本地计算层中的一个或多个本地计算节点相连接，用于在所述本地计算节点执行所述第一部分通信处理的情况下，执行所述一个或多个本地计算节点所连接的无线收发节点组合所对应的小区的第二部分通信处理，其中所述全部通信处理包括所述第一部分通信处理和第二部分通信处理。

另一方面，提供了一种通信***的管理方法，所述通信***包括无线收发层、本地计算层和集中计算层，所述无线收发层包括一个或多个无线收发节点组合，其中每个无线收发节点组合中的无线收发节点至少包括宏小区射频单元、微小区射频拉远单元、微小区射频与基带拉远单元中的一种；所述本地计算层包括一个或多个本地计算节点，其中每个本地计算节点与一个或相邻的多个无线收发节点组合中的无线收发节点相连，所述集中计算层包括一个或多个集中计算节点，其中每个集中计算节点与所述本地计算层中的一个或多个本地计算节点相连接，所述方法包括：所述本地计算节点执行该本地计算节点所连接的无线收发节点组合中的无线收发节点所对应的小区的全部通信处理或第一部分通信处理；所述集中计算节点在所述本地计算节点执行所述第一部分通信处理的情况下，执行所述一个或多个本地计算节点所连接的无线收发节点组合中的无线收发节点所对应的小区的第二部分通信处理，其中所述全部通信处理包括所述第一部分通信处理和第二部分通信处理。

本发明实施例在集中计算层和无线收发层之间增加了本地计算层，负责一定范围内的相邻小区的全部或部分通信处理，而不必将全部处理都交给较远的计算中心处理，节省了网络带宽，提高了***资源的利用效率。

附图说明

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

图1是根据本发明实施例的通信***的网络架构的示意图。

图2根据本发明另一实施例的通信***的网络架构的示意图。

图3A-3B是根据本发明的一个实施例的数据处理的过程的示意图。

图4是根据本发明实施例的HetNet网络架构的典型例子的示意图。

图5是根据本发明实施例的通信***的管理方法的示意流程图。

图6是根据本发明另一实施例的通信***的管理方法的示意流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例将BBU的计算资源进行分层，使本地化、小范围的BBU集中与全局化、大范围的BBU集中结合起来。对于一个无线收发单元，例如，宏小区射频单元、微小区RRU或微小区BRU(BasebandandRadioUnit，射频与基带拉远单元)，该无线收发单元既与本地计算节点连接，又通过本地计算节点与更上层大范围的计算节点连接。微小区BRU可以具有RRU的射频处理功能和一定的通信处理功能(例如基带数据压缩、基带及上层通信协议处理)。由此，本发明实施例的通信***支持根据用户分布、数据量和干扰情况，对计算资源、联合处理在本地计算节点和集中计算节点之间进行自适应的调度。

应注意，在本发明实施例中，当两个网元直接“连接”或“相连”时，表示这两个网元仅仅通过一种连接介质(例如，空口、光纤、数字用户线路、微波或电力线连接等)相连或者不经任何连接介质直接相连。当两个网元“连接”或“相连”时，表示这两个网元可以直接相连，也可以经由一个或多个其他中间网元间接相连。这些连接方式均落入本发明实施例的范围内。

图1是根据本发明实施例的通信***的网络架构的示意图。在图1中，为了简洁地显示出本发明实施例的***架构，每种网元均只描绘了一个，但是本发明实施例不限于此。各种网元的数目可以根据需要增加、减少或删除，这些修改均落入本发明实施例的范围内。

如图1所示，无线收发层110位于接入网架构的最底层，与用户设备之间通过空口进行无线信号传输。无线收发层110包括一个或多个无线收发节点组合115。无线收发节点组合115中的无线收发节点至少包括宏小区射频单元116、微小区射频拉远单元RRU117、微小区射频与基带拉远单元BRU118中的一种。无线收发节点116-118至少完成基站的射频处理功能，例如对于LTE来说，包括基带数据成帧/解帧(如CPRI成帧/解帧)、降峰均比、数字预失真、上/下变频、ADC/DAC(模数/数模转换)、功放、双工器等。

图1中仅仅描绘了一个无线收发节点组合115，但本发明实施例的无线收发层可以包括多个无线收发节点组合115。图1中无线收发节点组合115被描绘为包括三个无线收发单元116-118，但是本发明实施例的每个无线收发节点组合115可以包括这三种无线收发单元116-118中的一种或两种或全部，并且每个无线收发节点组合115中任一种无线收发单元116-118的数目可以是多个。为了简洁，下文中的术语“无线收发单元116-118”用于指代任一无线收发节点组合115中包含的无线收发单元，它可以表示包括无线收发单元116-118中的一种或多种，每种无线收发单元的数目可以是一个或多个。

本地计算层120位于无线收发层110的上层，包括一个或多个本地计算节点125。本地计算层120是直接与无线收发单元116-118相连的计算层，每个本地计算节点125与一个或相邻的多个无线收发节点组合115中的无线收发节点116-118相连，用于执行该本地计算节点120所连接的无线收发节点组合115所对应的小区的全部通信处理或第一部分通信处理。无线收发节点组合115所对应的小区是指该无线收发节点组合115中的无线收发单元116-118所服务的小区。本地计算层120与无线收发层110之间的距离一般在较短的范围内，例如在一个宏小区内。在采用微小区连续覆盖而没有宏小区覆盖的情况下，本地计算节点125可以连接到在较短范围内连续覆盖的多个微小区BRU/RRU。

图1中虽然仅仅显示了一个本地计算节点125与一个无线收发节点组合115中的无线收发节点116-118相连的情形，但是本发明实施例的本地计算节点125可以与一个或相邻的多个无线收发节点组合115中的无线收发节点116-118相连。可以根据网络配置，确定与本地计算节点连接的无线收发节点组合中无线收发节点，以及相连接的无线收发节点组合的数量。

集中计算层140位于***架构的顶层，包括一个或多个集中计算节点145。集中计算节点145与较大范围内的本地计算节点125相连，例如与多个宏小区对应的本地计算节点125相连。集中计算层140与本地计算层120之间的距离一般比较远。集中计算节点145与本地计算层中120的一个或多个本地计算节点125相连接，用于在本地计算节点125执行第一部分通信处理的情况下，执行所述一个或多个本地计算节点125所连接的无线收发节点组合115所对应的小区的第二部分通信处理，其中上述全部通信处理包括上述第一部分通信处理和第二部分通信处理。

在一个实施例中，第一部分通信处理和第二部分通信处理可以同时进行，在另一个实施例中，第一部分通信处理和第二部分通信处理也可以不同时进行，本发明实施例并不做特别的限定。

图1中虽然仅仅显示了一个集中计算节点145，但本发明实施例的集中计算层140可包括多个集中计算节点145。集中计算节点145可以相互连接。

本发明实施例在集中计算层和无线收发层之间增加了本地计算层，负责一定范围内的相邻小区的全部或部分通信处理，而不必将全部处理都交给较远的集中计算节点处理，节省了网络带宽，提高了***资源的利用效率。

为了进一步节省带宽，可以在集中计算层和本地计算层之间增加一个或多个中间计算层。图2是根据本发明另一实施例的通信***的网络架构的示意图。在图2中，与图1相同的部分采用相同的附图标记表示。

如图2所示，在本地计算层120和集中计算层140之间，可增加中间计算层130。图2中虽然仅仅显示了一个中间计算层130，但是本发明实施例可包括多个中间计算层。中间计算层130由中间计算节点135组成，每个中间计算节点135用于执行该中间计算节点135连接到的本地计算节点(例如图2中的125-2)所连接的无线收发节点组合(例如图2中的115-2)中的无线收发节点(例如图2中的115-2中包括的无线收发节点116-118)所对应的小区的全部通信处理或第三部分通信处理。除了上述第一部分通信处理(本地计算节点125执行)和第二部分通信处理(集中计算节点145执行)之外，所述全部通信处理还包括上述第三部分通信处理。

在一个实施例中，第三部分通信处理、第一部分通信处理和第二部分通信处理可以同时进行，在另一个实施例中，第三部分通信处理、第一部分通信处理和第二部分通信处理也可以不同时进行，本发明实施例并不做特别的限定。

如图2所示，集中计算节点145可通过各种方式与无线收发单元组合115中的无线收发单元116-118相连。例如，集中计算节点145-1直接与本地计算节点125-1相连，本地计算节点125-1直接与无线收发单元组合115-1中的无线收发单元116-118相连。

或者，集中计算节点145-1经由一层或多层的中间计算节点135与本地计算节点125-2相连，本地计算节点125-2直接与无线收发单元组合115-2中的无线收发单元116-118相连。

虽然本发明实施例的网络架构中无线收发单元116-118先接到本地计算节点125，然后通过本地计算节点125连到集中计算节点145，但是本发明实施例也可进一步采用与传统C-RAN类似的集中计算节点145直接连接无线收发单元116-118的方式。如图2所示，集中计算节点145-2直接连接到无线收发单元组合115-3中的无线收发单元116-118。例如，如果微小区RRU/BRU位于两个宏小区的交界处，从资源调度和干扰管理的角度出发，微小区的用户通常需要与多个宏基站联合处理。那么此微小区RRU/BRU可以直接连到集中计算节点。

特别地，对于BRU118，微基站侧具有部分基带处理功能，相当于微基站RRU与一个共站址的微计算节点相连。BRU118可执行BRU所对应小区的第四部分通信处理。另外，如图2所示，集中计算节点145之间可以相互连接，此时集中计算节点145可经任务调度将第五部分通信处理转移至其他集中计算节点执行。所述全部通信处理还包括上述第四部分通信处理和/或第五部分通信处理。

在一个实施例中，第五部分通信处理、第四部分通信处理、第三部分通信处理、第一部分通信处理和第二部分通信处理可以同时进行，在另一个实施例中，第五部分通信处理、第四部分通信处理、第三部分通信处理、第一部分通信处理和第二部分通信处理也可以不同时进行，本发明实施例并不做特别的限定。

下面描述本发明实施例各个网元之间的接口。如图2所示，宏小区射频单元116和本地计算节点125-1/125-2之间、微小区RRU117和本地计算节点125-1/125-2之间、宏小区射频单元116和集中计算节点145-2之间、微小区RRU117和集中计算节点145-2之间，通过第一类接口C1连接。第一类接口C1用于传输基带数据和控制状态消息，例如提供同步和相应的控制管理功能。第一类接口C1可以使用现有分布式基站BBU和RRU之间的CPRI等协议实现。

微小区BRU118和本地计算节点125-1/125-2之间、本地计算节点125-1和集中计算节点145-1之间、本地计算节点125-2和中间计算节点135之间、上下层的中间计算节点135之间、中间计算节点135和集中计算节点145-1之间、集中计算节点145-1和145-2之间，微小区BRU118和集中计算节点145-2之间，通过第二类接口C2连接。第二类接口C2用于传输基带数据、数据包和控制状态消息，例如为上下层之间的计算节点交互计算任务和控制信息。第二类接口C2可以考虑通过现有接口协议CPRI与X2，Iur，Iub的功能组合来实现。

集中计算节点145-1/145-2和核心网200之间通过第三类接口C3连接。第三类接口C3用于传输数据包和控制状态消息。第三类接口C3可以考虑通过现有的S1、Iu接口的功能来实现。

图2的实施例中，可通过中间计算层130进一步减少集中计算层140需要执行的通信处理，减少带宽需求，提高***资源的利用率。

本发明实施例的通信处理是指与无线网络通信有关的处理，包括但不限于数据处理、联合干扰管理处理、联合资源调度处理、联合计算任务调度处理、多制式基带信号和上层协议联合处理或联合传输、工作模式或开闭状态的联合控制等。

下面的描述中，主要参照不包含中间计算层的三层网络架构(图2中的145-1至125-1至115-1)或者包含一个中间计算层的四层网络架构(图2中的145-1至135至125-2至115-2)描述各个网元的操作。但是本发明实施例可类似地应用于包含更多个中间计算层的情景，其中每个中间计算层处理与之相连(间接相连)的无线收发单元服务的小区的部分或全部通信处理。

图3A-3B是根据本发明的一个实施例的数据处理的过程的示意图。其中图3A是上行数据处理的一个例子的示意图，图3B是下行数据处理的一个例子的示意图。在所述通信处理包括数据处理的情况下，各个计算节点对于所接收的数据进行分流处理，以区分出本计算节点需要处理的数据和非本计算节点需要处理的数据。所述非本计算节点需要处理的数据可包括前一层计算节点已经处理完的数据和/或需要后一层计算节点处理的数据。对于网络架构顶层的计算节点(集中计算节点145)和底层的计算节点(本地计算节点125)，需要对完成通信处理的数据进行聚合。

具体而言，如图3A所示，上行时，本地计算节点125对来自无线收发单元的数据D进行分流。在图3A的实施例中，假设不存在BRU，即数据D为未经处理的基带数据和控制信息。本地计算节点125将数据D分为在本地计算节点125进行处理的部分D1、在中间计算层130进行处理的部分D2(假设有中间计算层)、以及在集中计算层140处理的部分D3(D＝D1+D2+D3)。然后完成需要在本地计算节点125处理的数据D1的基带和/或L2处理，将处理D1后产生的数据包P1以及需要由中间计算层130和顶层计算层140处理的数据D2+D3传输至中间计算层130中与该本地计算节点125相连的中间计算节点125(如果没有中间计算层，则直接传输至集中计算层140中与该本地计算节点125相连的集中计算节点145)。本地计算层是本发明实施例降低传输带宽最主要的功能节点。另一方面，如果存在BRU，则此时本地计算节点125的操作可类似于下面所述的中间计算节点135的操作。

中间计算层130中的中间计算节点135在上行时对来自下层节点(可以是本地计算节点125或者下层的中间计算节点)的数据进行分流，区分出需要在本层进行处理的数据D2和不需要在本层进行处理的数据P1和D3。中间计算节点135对数据D2进行基带和/或L2处理，将本层的处理结果P2(数据包)，以及需要上层计算层进行处理的数据D3和已经由计算节点125处理产生的数据P1传输至上层中间计算节点(如果有上层中间计算节点)或集中计算节点145(如果没有上层中间计算节点)。

集中计算层140是直接与核心网相连的计算层。上行时，集中计算层140的集中计算节点145进行计算数据的分流，区分出需要集中计算节点145处理的数据D3和不需要集中计算节点145处理的数据(例如已经由下层计算节点完成数据处理后产生的数据包P1和P2)。然后集中计算节点145完成下层未完成的基带数据D3的联合处理以及L2处理，并将处理结果P3(数据包)和下层已完成处理后产生的数据包P1和P2聚合为数据包P，并将数据包P传输至核心网。

类似地，下行时集中计算节点145对来自核心网数据包P进行分流，分为在需要本地计算层进行处理的部分P3、在中间计算层进行处理的部分P2(如有中间计算层的话)，以及需要在本集中计算节点145处理的部分P1(P＝P1+P2+P3)。对需要进行处理的数据包P1进行L2和基带处理，将处理的结果D1(基带信号和控制消息)以及需要由中间计算层和本地计算层处理的数据包P2和P3传输给中间计算层(如有)或本地计算层(如没有中间计算层)。

中间计算节点135对来自上层节点(可以是集中计算节点145或者上层的中间计算节点)的数据进行分流，区分出需要在本层进行处理的数据P2以及不需要本层进行处理的数据D1和P3。中间计算节点135对数据P2进行L2和基带处理，将处理的结果D2(基带信号和控制消息)以及需要下层计算节点进行处理的数据P3和已经由集中计算节点145处理产生的数据D1传输至下层中间计算节点(如果有下层中间计算节点)或本地计算节点125(如果没有下层中间计算节点)。

本地计算节点125对来自上层计算节点的数据进行分流，区分出本地计算节点125需要处理的部分数据包P3，以及不需要本地计算节点125处理的数据(例如上层计算节点已经完成处理后产生的基带信号和控制消息D1和D2)。然后本地计算节点125完成上层未完成的数据包P3的处理，将处理结果D3(基带信号和控制消息)以及来自上层的基带信号和控制消息D1和D2聚合为基带信号和控制消息D，然后将D传输至无线收发单元。

计算节点进行数据分流时，可基于计算节点的计算能力、节点间带宽、数据处理需求(处理速度需求、延迟需求、处理量需求等)等因素，综合确定数据分流的比例。图3A的实施例中，本地计算节点125可以直接分流出需要本层处理的数据D1、需要在中间计算节点135处理的数据D2和需要在集中计算节点145处理的数据D3，但本发明实施例不限于此。本地计算节点125可以不区分开D2和D3，而仅仅分流出需要本层处理的数据D1和不需要本层处理的数据D2+D3，然后由中间计算节点135根据需求区分开D2和D3。图3B的实施例中也是类似的，集中计算节点145可以不区分开P2和P3。

图3A和图3B的实施例中，除了最后一层计算节点外，其他层的计算节点不对数据进行聚合，而是分开传输各种数据，例如本层处理后产生的数据、前一层已经处理的数据和需要后一层处理的数据。但本发明实施例不限于此。在向上层或下层的计算节点传输数据时，可以对要传输的数据进行聚合后再传输。

本发明实施例的分层网络架构能够执行的通信处理还可以包括联合干扰管理处理。例如，对于小区交界处的用户设备，如果可以在相邻的小区间进行联合处理的话，将有效提高用户设备的吞吐量。本发明实施例在联合干扰管理处理上采用分层自适应的方式。联合干扰管理处理的基本原则是由干扰双方共同的上层计算节点优先处理该干扰。

结合图2的***架构描述本发明实施例的联合干扰管理处理。本地计算节点125优先执行与该本地计算节点125连接的无线收发节点组合115中的无线收发节点116-118所对应的小区内的无明显干扰的用户设备的通信处理或仅受到来自该本地计算节点125所连接的无线收发节点组合115中的其他无线收发节点116-118所对应小区的干扰(例如，受到所述其他无线收发节点116-118的干扰或者受到所述其他无线收发节点116-118服务的UE的干扰)的用户设备的干扰处理。例如，本地计算节点125-1优先执行无线收发节点组合115-1所对应的小区中无明显干扰的用户设备的通信处理或者仅仅受到无线收发节点组合115-1中的无线收发节点116-118所对应小区的干扰的用户设备的干扰处理。

中间计算节点135优先执行与该中间计算节点135连接的下层中间计算节点或本地计算节点相关联的无线收发节点组合中的无线收发节点所对应小区内的用户设备的干扰处理，其中该用户设备受到来自与该中间计算节点连接的其他下层中间计算节点或本地计算节点相关联的无线收发节点组合中的无线收发节点所对应小区的干扰。以一个中间计算节点135连接多个本地计算节点的情形为例，该中间计算节点135优先处理该多个本地计算节点之间的干扰。

集中计算节点145优先执行与该集中计算节点145连接的下层中间计算节点或本地计算节点相关联的无线收发节点组合中的无线收发节点所对应小区内的用户设备的干扰处理，其中该用户设备受到来自与该集中计算节点连接的其他下层中间计算节点或本地计算节点相关联的无线收发节点组合中的无线收发节点所对应小区的干扰。以图2的架构为例，如果本地计算节点125-1连接的无线收发单元116服务的用户设备A受到本地计算节点125-2连接的无线收发单元118的干扰，则由它们共同的上层计算节点(即集中计算节点145-1)执行该干扰的处理。

在本地计算节点、中间计算节点和集中计算节点进行的干扰处理可包括联合干扰删除、联合时频资源协调、联合功控、以及多个基站之间的多点协作(CoordinatedMulti-Point，CoMP)。

这样，大部分用户的信号可以在本地计算节点进行联合处理，大大降低了传输到上层计算节点的数据量，从而节省了光纤资源和上层计算节点的负荷。

图4是根据本发明实施例的HetNet网络架构的典型例子的示意图。如图4所示，该HetNet网络架构包括一个集中计算节点245、两个本地计算节点225a和225b。HetNet网络架构中本地计算节点典型地设置在宏基站处，例如与宏小区RRU共站址；本地计算节点也可以设置在多个相邻宏基站组成的区域内，例如连接到多个宏小区RRU。本地计算节点的通信处理包括：1)可以按用户、上行/下行、macro/Pico等灵活划分为不同负荷的“计算任务包”，便于***按需在集中计算节点与本地计算节点之间自适应分配处理负荷；2)完成适合在本地计算节点完成的基带信号处理任务：本地Macro/Pico的、与其它Macro/Pico没有干扰的用户信号的全部基带处理；3)负责本地Macro/Pico基带信号的预处理(如FFT、Mapping/De-mapping、Precoding等)或信号压缩处理；4)通过软件无线电(SoftwareDefinedRadio，SDR)实现多制式统一处理和联合传输。

具体而言，在图4的例子中，本地计算节点225a与由宏小区RRU215a、微小区RRU215b、微小区BRU215c组成的无线收发单元组合相关联，其中本地计算节点225a与宏小区RRU215a共站址，微小区RRU215b和微小区BRU215c在宏小区RRU215a的覆盖范围MC1内。

本地计算节点225b与由宏小区RRU215d、微小区RRU215e和微小区BRU215f组成的无线收发单元组合相关联，其中本地计算节点225b与宏小区RRU215d共站址，微小区RRU215e和微小区BRU215f在宏小区RRU215d的覆盖范围MC2内。

在多个宏小区组成的较大区域内，每个宏小区的本地计算节点225a/225b连至一个集中化的集中计算节点245。这样就在较大的区域内构成了一个上层的云计算架构。

图4中仅仅显示了两个宏小区MC1和MC2，本发明实施例不限于此。一个集中计算节点可以连接到更多个本地计算节点，每个本地计算节点也可以连接到更多个宏小区RRU，每个宏小区内可以没有微小区RRU或微小区BRU，微小区RRU/BRU的数目也可以根据需要增删，这些修改均落入本发明实施例的范围内。

在下文中，在无需相互区分的情况下，将本地计算节点225a和225b统称为本地计算节点225，将宏小区RRU215a、微小区RRU215b、微小区BRU215c、宏小区RRU215d、微小区RRU215e和微小区BRU215f统称为无线收发单元215。

如图4所示，每一个无线收发单元首先连到本地计算节点225，然后通过本地计算节点225连接到上层的集中计算节点245，但是本地计算节点225之间没有接口，无线收发单元之间也不连接。由于X2接口标准化时没有考虑到多点协作CoMP，所以X2接口的带宽和延迟都无法满足多点协作和联合处理的要求。本发明实施例中基站之间没有逻辑接口，多点协作和联合处理由上层计算节点完成。此外，本发明实施例中取消了RNC，UMTS***中RNC完成的数据处理和联合调度都在上层计算节点完成。

另外，作为统一的接入网，所有计算节点上的处理都通过软件实现，可以使用不同的虚拟机或者统一操作***平台上的不同进程完成不同无线制式的处理，同时实现G/U/L/WiFi，并支持多种制式的联合传输。

应注意，图4的HetNet架构只是示例性的，本发明实施例不限于此，可以按照需要对计算节点的数目、位置、层数进行修改，也可以增加一层或多层中间计算节点。另外，图4的HetNet架构可以与微小区连续覆盖架构结合使用，即部分本地计算节点225可以与较小范围内连续覆盖的多个微小区BRU/RRU相连。这些修改均落入本发明实施例的范围内。

在图4的HetNet场景下，用户设备受到的干扰可分为以下几种类型：

1)无明显干扰的用户设备UE：

宏小区MC1/MC2中无明显干扰的UE：典型地该类UE位于本地宏小区的中心区域。由于远离相邻的宏小区，所以该类UE受到来自相邻宏小区内的干扰很小；并且这些UE远离本宏小区内使用相同频段的热点区域，所以受到来自微小区的干扰也很小。

微小区中无明显干扰的UE：典型地该类UE位于一个孤立的热点区域的中心位置。由于是孤立的热点区域，所以它受到来自本宏小区中其它微小区的干扰很小；由于该类UE位于微小区的中心位置，所以它受到来自本宏小区的干扰也相对较小。

对于无明显干扰的UE来说，在不考虑潮汐效应的情况下，它们的数据优先在与之关联的本地计算节点上进行处理。因为即使进行联合处理，带来的增益也不明显，反而会明显增加基带信号传输的负荷。对应本发明实施例的云接入网架构而言，这类用户数据的通信处理优先在本地计算节点执行。

对于有明显干扰的用户设备，可以根据其干扰来源分为在本地计算节点225进行处理和在集中计算节点245进行处理两种情况。

2)优先在本地计算节点225进行处理的干扰用户

对于优先在本地计算节点进行处理的干扰情况：

Type1：仅受到所在宏小区干扰的微小区的UE，这类UE位于微小区的边沿，而该类UE周围没有其他的微小区，其信号只受本地宏小区信号的干扰。干扰联合处理的情况下只需要在微小区和所在宏小区之间进行。例如，如果微小区RRU215b服务的UE仅受到所在宏小区MC1的干扰，则该UE的干扰处理由本地计算节点225a执行。

Type2：位于微小区边沿的宏小区UE，它的干扰来源于邻近的微小区。干扰联合处理的情况下只需要在宏小区和与该UE产生较大干扰的微小区之间进行。例如，如果宏小区RRU215a服务的UE受到微小区RRU215b的干扰，则该UE的干扰处理由本地计算节点225a执行。

Type3：如果两个微小区相隔很近，那么在它们交界处的用户不论隶属于宏小区或者两者微小区之一，都会受到来自另两个小区的干扰。有这样三种示例情况：宏小区MC1服务的UE同时受到来自两个相邻微小区的干扰(即，受到微小区RRU215b和微小区BRU215c的干扰)；微小区RRU215b服务的UE同时受到来自宏小区RRU215a和微小区BRU215c的干扰；微小区BRU215c服务的UE同时受到来自宏小区RRU215a和微小区RRU215b的干扰。干扰联合处理的情况下需要在宏小区和所述的两个相邻微小区之间进行。例如，上面的三种示例情况下，由本地计算节点225a执行干扰处理。

对于优先在本地计算节点进行联合干扰处理的用户来说，在不考虑潮汐效应的情况下，它们的数据优先在与之关联的云接入网架构下的本地计算节点进行处理。因为它们的干扰来源都是本地计算节点下的小区之间，所以联合处理在本地计算节点上进行即可。在此情况下，即使在集中计算节点进行联合干扰处理也不会带来进一步的性能增益，反而会明显增加基带信号传输的负荷。

3)优先在集中计算节点245进行处理的干扰用户

对于优先在集中计算节点245进行处理的干扰情况：

Type4：位于几个宏小区(例如MC1和MC2)边沿的宏小区(例如MC1和MC2之一)服务的UE，在周围没有微小区时，其干扰主要来源于周围的邻近宏基站(MC2或MC1)，位于宏小区非热点地区用户，信号主要受相邻宏小区的干扰。由于本地计算节点位于本地宏小区，所以本地计算节点无法对周围几个宏小区的用户进行联合干扰处理。所以此类UE将其数据发给集中计算节点245，由于集中计算节点245负责较大区域内的宏小区和微小区，所以它可以将几个不同宏小区用户的信号进行联合干扰处理。例如，如果MC1服务的UE受到MC2的宏基站干扰，则由集中计算节点245处理该干扰。

Type5：如果一个热点区域位于几个宏小区的交界处，那么在微小区边沿的用户，不论是隶属于微小区还是其中一个宏小区，都会受到来自其他小区的干扰。例如，微小区RRU215e服务的UE受到相邻宏小区MC1和MC2的宏基站的干扰；宏小区MC1服务的UE受到微小区BRU215c和宏小区MC2的宏基站的干扰；宏小区MC2的用户受到微小区RRU215e和宏小区MC1的宏基站的干扰。对于底层计算节点位于本地宏小区，所以本地云接入网架构无法对周围几个宏小区的用户进行联合干扰处理。所以与Type4一样，此类UE将其数据发给上层的集中计算节点245。由于上层云接入网架构负责较大区域内的宏小区和微小区，所以它可以将几个不同宏小区和微小区用户的信号进行联合干扰处理。

对于优先在集中计算节点245进行联合干扰处理的用户来说，它们的数据优先在云接入网架构中的上层计算节点进行处理。因为它们的干扰来源是几个本地云接入网架构下的宏小区和微小区之间，所以为了提高***性能，希望联合处理在集中计算节点245进行。由于处于几个底层云接入网架构交界处的用户数量不会太多，所以上传到上层云接入网架构进行联合处理的数据有限，不会对基带信号传输网造成太大的负荷。

在判断是否需要进行上层联合处理的情况下，网络侧可以让UE周期性地测量周围RRU/BRU的参考信号强度和接收延迟。如果发现多个RRU/BRU强度和延迟都相近，则将用户数据上移至这些RRU/BRU共同的上层计算节点。相反地，如果发现一个上层计算节点处理的UE测量相邻RRU/BRU参考信号强度相差较大，例如只有一个或少数几个强度较大时，将UE的信号处理下移到这些RRU/BRU对应的下层计算节点。

以LTE为例，在上行时，最下层的计算节点(微计算节点或本地计算节点)在收到射频单元输出的数据时，进行FFT，分出对应微计算节点(如果有BRU的话)、本地计算节点以及集中计算节点处理的资源块(RB，ResourceBlock)。每一层的计算节点处理对应的基带数据，将上层处理的基带数据透传到上层计算节点。

在下行时，集中计算节点将来自核心网的数据包分为集中计算节点、本地计算节点以及微计算节点(如果有BRU的话)进行处理的部分。每一层完成处理以后的基带数据和控制信息在最底层的计算节点(本地计算节点或微计算节点)完成组合，以供射频单元处理成发射信号。

对于CDMA(CodeDivisionMultipleAccess，码分多址)接入方式，不同用户的数据是加载在相互正交的码序列上的，其分层处理方式可以类比到以时频资源块区分用户的方式，此处不再赘述。

本发明实施例的通信***执行的通信处理可包括联合资源调度处理，通过相邻小区之间的资源调度，在减少小区间干扰的同时，提高资源利用率和***性能。在本发明实施例的多层云接入网架构下，根据不同的用户位置，在不同层的网络上进行资源管理，各层计算节点分别负责不同情况下的资源调度。联合资源调度处理的原则是由能够服务用户设备的无线收发单元均关联的本地计算节点、中间计算节点或集中计算节点进行该用户设备的资源调度。

参照图2，本地计算节点125执行与该本地计算节点125连接(直接连接)的无线收发节点组合115中的无线收发节点116-118所对应的小区之间的资源调度。中间计算节点135执行与该中间计算节点135连接(间接连接)的无线收发节点组合115中的无线收发节点116-118所对应的小区之间的资源调度。集中计算节点145执行与该集中计算节点145连接(直接或间接连接)的无线收发节点组合115中的无线收发节点116-118所对应的小区之间的资源调度。

对于图4所示的异构网络HetNet场景，本地计算节点225主要完成本地Macro-Pico联合资源调度。对宏小区中心用户，以及位于宏小区内部区域的微小区内的用户，与其它宏小区的干扰很小，基本上可以做到资源的完全本地化调度与控制，只需进行本地Macro-Pico联合资源调度。由于可以采用Macro-Pico联合调度，因此微小区的业务信道资源可以和宏小区复用；对于距离较远的不同微小区，它们之间干扰很小，控制和业务信道资源可以独立调度。例如，本地计算节点225a可以完成MC1覆盖范围内的Macro-Pico联合资源调度，本地计算节点225b可以完成MC2覆盖范围内Macro-Pico联合资源调度。

集中计算节点245主要完成全局Macro-Pico联合资源调度。对宏小区边缘UE以及位于宏小区边缘的微小区内的UE，与其它宏小区存在一定的相互干扰，因此对这类UE需要进行全局资源调度。例如，如图4所示，假设微小区RRU215e位于宏小区MC1和MC2的覆盖范围交界处，此时，微小区RRU215e内的资源分配可以由集中计算节点245进行调度，以降低小区间干扰。

以通过频域资源的联合调度来降低小区间干扰为例进行说明。在底层云架构下，本地计算节点完成宏小区内部的微小区与宏小区在交界处的资源分配，在两个相邻的微小区的交界处，频域资源被分为f1、f2、f3三个部分，分别供交界处的两个微小区和宏小区的边沿UE使用。各频域资源的具体比例由各小区边沿的用户数量和业务数据量决定。

在上层云架构下，集中计算节点245完成多个底层云架构之间的资源分配。比如在图4的HetNet云计算架构中，集中计算节点245负责两个宏小区MC1和MC2交界处和宏小区交界附近的微小区(例如，微小区RRU215e覆盖的小区)的边沿UE的频域资源的分配。比如将频域资源分为f1、f2、f3三个部分，分别供两个宏小区和微小区的边沿UE使用。各频域资源的具体比例由各小区边沿的用户数量和业务数据量决定。

假设对于异构网，宏小区和微小区使用相同的频域资源，那么就对同一时频资源会有上下两层的计算节点对其进行调度。为了避免调度冲突，有如下两种解决方法：

1)本地计算节点、中间计算节点和集中计算节点进行调度的资源被配置为彼此不同。这是基于频分/时分/空分的多层调度，无需改动现有标准数据处理流程。

具体地，上层计算节点根据下层覆盖中需要进行联合处理的UE在一定时/频/空域资源上进行联合调度。下层计算节点的其他有关和在上层剩余的时/频/空域资源上进行调度。为了保证本地UE的吞吐量，上层供上层联合调度的资源必须限定在一定范围内，并根据实际UE分布和数据量进行动态调整。

2)优先由位于上层的计算节点执行资源调度。这种调度由上层统一执行，可以优化全网吞吐量。

所有用户设备的信道信息，例如上行测量信号SRS(SoundingReferenceSignal)，信道条件指示CQI(ChannelQualityIndicator，信道质量指示)/PMI(PrecodingMatrixIndicator，预编码矩阵指示)/RI(RankIndicator，秩指示)等，都传输到位于上层的计算节点。因为用户数据都要经过上层的计算节点，所以上层的计算节点统一调度时有当前和过去用户数据率的信息，以便保证调度的公平性。如果上层的计算节点的计算能力很强，所以统一上层用户调度的计算负荷也是可以接受的。

在传统的C-RAN架构下，由于BBU到RRU的距离很远，所以都需要高速光纤相连，基带传输成本很高。

在本发明实施例的架构下，本地计算节点到本地宏小区RRU和微小区RRU/BRU的距离很近。以现在站间距为500米的宏小区为例，本地计算节点到远端微小区RRU的距离在200米左右。这样很多其他的短距离连接介质和技术都可以用来作为本发明实施例中不同节点之间的连接。例如，无线收发节点组合中的无线收发节点和本地计算节点之间、本地计算节点和中间计算节点之间、或者上下层的中间计算节点之间，均可以根据具体情况，通过光纤、数字用户线路DSL(DigitalSubscriberLine)、微波或电力线连接。所以分层结构大大简化了基带信号传输网络的拓扑结构，有效降低了传输成本。可以基于节点计算能力、节点间距离、节点间传输带宽需求和/或节点间传输延迟需求等因素，确定节点之间的连接介质。

例如，数字用户线路DSL(双绞线、铜线等)、微波、电力线通信等技术可以在200米的范围内实现接近Gbps的传输速率，可用来替换光纤用作本地短距离信号的传输。

对于本地计算节点和集中计算节点之间的连接，因为相对数目较少，距离较远，可以仍然使用光纤相连。

可以根据实际场景，根据传输距离和成本考虑，对每一层的云接入网使用不同物理媒质用于基带信号传输网。

在传输带宽方面，本发明实施例中提出的网络架构可以根据基带信号的传输网的带宽自适应的分配计算负荷。当可用传输带宽较大时，处理负荷可上移到上层计算节点，简化本地计算节点的配置；当可用传输带宽较小时，处理负荷较多地分配到本地计算节点。

本发明实施例的通信***执行的通信处理还可以包括联合计算任务调度处理。本发明实施例的网络结构具有在较大区域内平衡计算负载、有效利用计算资源的能力。

本地计算节点和连接到该本地计算节点的中间计算节点之间，上下层连接的中间计算节点之间，中间计算节点和连接到该中间计算节点的集中计算节点之间，相互连接的集中计算节点之间，根据计算负荷、计算能力、传输带宽和传输时延等相互转移计算任务。

本地宏小区内RRU对应的基带数据优先在本地计算节点进行处理，如果由于本地计算节点处理能力有限，或者由于用户设备的潮汐效应导致本地计算节点的计算负荷过大，本地计算节点可以将一部分信号交给上层的计算节点进行处理，例如中间计算节点或集中计算节点。上层的计算节点负责平衡较大范围内本地计算节点的计算负荷，当其自身的计算负荷过大时，它可以将部分的计算工作下放到本地计算节点进行处理。

一般对于多层云架构的接入网，由于其计算任务分布在两层以上不同的计算节点上，对计算任务的调度可以放在上层计算节点进行集中式调度，或者放在各层计算节点进行分布式调度。

如果是集中式调度，由位于上层的计算节点调度计算任务的转移。例如，在图4的HetNet场景下，各个本地计算节点225可以定期向上层的集中计算节点245报告当前的计算负荷。集中计算节点245在收集各本地计算节点225的信息后，决定是否要将某些本地计算节点的部分计算任务上移至集中计算节点进行。然后集中计算节点245向各本地计算节点225返回调度指令，指示是否要将部分计算任务上移，以及需要上移的计算任务量。

如果是分布式调度，由计算节点基于其他计算节点的请求来调度计算任务的转移。此时本地计算节点225与集中计算节点245是平权的。本地计算节点225的计算资源紧张时，会向集中计算节点245发送计算任务上移请求消息，请求消息中包括希望上移的计算任务量。集中计算节点245收到各本地计算节点225上报的请求消息后，根据自身的计算资源空闲情况，并统筹各下属本地计算节点225的申请需求，对各本地计算节点225发出的计算资源上移请求消息进行反馈。反馈消息包括是否同意其计算任务上移，以及可以上移的计算任务量。另一方面，集中计算节点245的资源紧张时，也可以通过轮询或随机选择的方式向下层本地计算节点225发送计算任务下移请求消息，或者向其他集中计算节点发送计算任务转移请求消息(例如，关于上述第五部分通信处理的转移请求)，这两个请求消息包括希望转移的计算任务量。收到请求消息的本地计算节点225或集中计算节点245根据自身的计算资源空闲情况，对发出请求的集中计算节点245返回调度指令，指示是否要将部分计算任务转移，以及需要转移的计算任务量。

如果通信***支持多种制式，则无线收发节点组合可包括多种制式的无线收发节点。此时本发明实施例的各个计算节点执行的通信处理可包括多种制式的通信处理和/或多种制式之间的联合通信处理。

传统模拟无线电***的射频部分、上/下变频、滤波及基带处理全部采用模拟方式，某频段和某种调制方式的通信***都对应专门的硬件结构；而数字无线电***的低频部分采用数字电路，但其射频部分和中频部分仍然离不开模拟电路。与传统无线电***相比，软件无线电的A/D、D/A变换移到了中频，并尽可能靠近射频端，对整个***进行采样，这是软件无线电的一个突出特点。数字无线电采用专用数字电路，实现单一通信功能，无编程性可言。而软件无线电以可编程力强的DSP(数字信号处理，DigitalSignalProcessing)器件代替专用数字电路，使***硬件结构与功能相对独立。这样就可基于一个相对通用的硬件平台，通过软件实现不同的通信功能，并对工作频率、***带宽、调制方式、信源编码等进行编程控制，***灵活性大为增强。

本发明实施例中由于各计算节点都是高性能的CPU或CPU阵列以及DSP构成，所以同一计算节点可以支持多种不同制式的RRU的基带信号和上层协议处理。这样会带来一系列的好处：不同制式对于同一处理单元，简化网络架构，降低建网成本；便于***或基站升级，只需要通过更新计算节点的软件即可完成，这使得对已有频谱资源的重整(refarming)变得容易操作。

如果用户设备支持多制式同时传输，本地计算节点根据不同制式上的实际情况(无线链路条件，网络负荷等)将数据分流到不同制式上进行传输。上行传输时，本地计算节点，或中间计算节点，或集中计算节点对不同制式上的数据进行聚合。如果用户设备支持多模传输，那么这种基于SDR并且集中处理的方式当然支持多种制式的联合传输。这些多制式可以是G/U/L/WiFi，不同协议层上都可以进行多制式的联合传输，如PHY(物理层)，MAC(MediaAccessControl，媒体接入控制)，RLC(RadioLinkControl，无线链路控制)等等。并且计算节点可以对多制式的联合传输进行统一调度。

在图4的HetNet分层接入网架构中，本地微基站和宏基站的基带信号处理都被集中到本地计算节点225。这种场景下，微基站和宏基站之间可以自适应的进行网络配置，与传统HetNet相比具有更加灵活的接入网架构。

本发明实施例的通信处理可以包括无线收发节点组合中的微小区RRU和/或微小区BRU的工作模式或开闭状态的联合控制。例如，可以将Pico微小区灵活、自适应地配置为以下三种形态：1)配置为独立的微小区，有自己的CellID(小区标识)和所有的控制/数据信道；2)配置为宏基站的RelayStation(RN，中继站点)，对于常用的带内传输方式，RN通过宿主eNodeB以无线方式连接到接入网，所使用的频段与RN和终端之间的链路共享同一频段；3)配置为宏基站的分布式天线，通过SFN(SingleFrequencyNetwork，单频网)方式或者其他空间编码方式(如SFBC(Space-FrequencyBlockCodes，空频块码))发送/接收宏基站的部分或全部无线信号。

微小区RRU或BRU的数量/模式可以根据不同的场景进行自适应的配置。例如微小区RRU或BRU可以根据需要自适应配置为上述3种不同的工作模式。

例如，当某热点的流量呈现随时间变化很大时，例如白天用户密集，晚间用户稀少，可以在用户数较大时打开微小区RRU或BRU，而在用户数较小时关闭微小区RRU或BRU。也可以根据传输资源的可用带宽或负荷等因素，自适应开闭微小区RRU或BRU。

当本地计算节点225与集中计算节点245之间的可用传输带宽较小时，可以增加微小区RRU或BRU站点，这样，更多的用户进入微小区RRU或BRU，由于发射功率减少，和直接与宏基站传输相比，受到其它宏基站的干扰以及对其它宏基站的干扰都大幅减小，因此不再需要在集中计算节点进行联合处理，从而有效降低了本地计算节点225与集中计算节点245之间的传输带宽需求。

本发明实施例的通信***将BBU的计算资源进行分层和本地化，使得小范围的无线收发单元集中在本地计算节点管理，大范围的无线收发单元集中结合起来由上层计算节点管理。对于一个无线收发单元，它既与本地计算节点直接连接，又通过本地计算节点与更上层大范围的计算节点间接连接，而且也不排除部分无线收发单元直接与上层计算节点连接的情况。本发明实施例支持根据用户分布、数据量和干扰情况，对计算资源、联合处理在本地计算节点和集中计算节点之间进行自适应的调度。

对于HetNet异构***，本地计算层可放置在局部相对较小的区域内，例如宏小区内，以通过部分本地计算处理降低对传输网的带宽要求，并且使多种短距离传输技术可以在本地应用，此时可根据实际连接介质的带宽选择不同的上移云数据的比例。上层的集中计算层要负责管理较大区域内的无线收发单元和计算节点，使得通过计算资源的调度达到解决用户潮汐效应等问题。根据实际组网，确定是否需要中间计算层作为本地计算层到集中计算层的过渡。

本发明实施例与传统C-RAN架构相比，主要优势在于极大地节省基站连接到云计算节点的带宽。在未来的通信网中小蜂窝数量增多，为现有宏蜂窝的数倍；频带成倍的提升；天线数量也积聚增加，由现在的最多4天线增加到几十甚至上百天线。如果还是使用传统云接入网架构，让所有基带数据都直接连接到几公里之外的云计算中心，对光纤传输将是极大的挑战。

以下行为例，假设在LTE***中，每个宏基站对应三扇区，每个扇区8天线；每个宏小区范围内有10个微蜂窝基站，单天线，对应一个微蜂窝小区；每个基站对应20MHz的频谱，采样频率30.74MHz，每个采样点22bit量化。那么这个宏基站下行数据连接到云的数据率为：(3×8+10)×30.74MHz×22bit＝23Gbps。

但是，如果从联合信号处理增益的角度出发，可以发现，没有必要将所有UE都直接连接到统一的云计算节点，只有处在小区边沿的UE才有明显的联合处理增益。如果按照本发明实施例，在本地完成绝大部分基带甚至L2的数据处理，将极大减少需要与云计算中心相连的数据率：信道解码后数据率下降1/3；如果是64QAM，解调后数据率下降5/22；出去循环前缀(CP，CyclicPrefix)也会使得数据率下降一些；如果本地可以完成L2的数据处理，那么帧头，CRC校验，控制字段都可以节省下来，假设完成L2处理可以节省10％，那么如果只有20％的用户数据需要联合处理，LTE下行的数据率为23Gbps×20％+23Gbps×80％×90％×1/3×5/22＝5.8Gbps。上行时基带数据通过本地处理所节省的传输带宽比例与下行时相近。由此可见，本发明实施例中加入底层本地计算层的通信***带来较大的带宽节省优势。

即便考虑到云接入网架构带来的平衡计算资源和解决潮汐效应等问题，本发明实施例的多层计算架构中，计算任务也可以在上下层计算节点中进行调度，不失传统C-RAN架构的优势。

第二个优势在于传统C-RAN需要每个宏基站都通过光纤连到计算中心，但在微基站密布的将来，如果所有微基站都通过光纤连到统一计算中心，将会极大提高光纤铺设成本。本发明实施例可以使得基站数据在本地一定范围内先集中然后再传输到上层计算中心。由于是本地集中，所以可以考虑多种短距离通信技术，比如微波、DSL、电力线等，降低基带传输成本。对于传统C-RAN架构，如果基带传输数据率不能满足所有基带数据上云的需求，那么就无法使用云计算架构。本发明实施例中，我们可以根据基带数据传输带宽，选择最需要上层统一处理的用户数据上云，而其它数据在本地处理，从而在任何情况下都可以使用云架构。

图5是根据本发明实施例的通信***的管理方法的示意流程图。图5的方法由图1或图2所示的通信***执行。所述通信***包括无线收发层、本地计算层和集中计算层，所述无线收发层包括一个或多个无线收发节点组合，其中每个无线收发节点组合中的无线收发节点至少包括宏小区射频单元、微小区射频拉远单元、微小区射频与基带拉远单元中的一种；所述本地计算层包括一个或多个本地计算节点，其中每个本地计算节点与一个或相邻的多个无线收发节点组合中的无线收发节点相连，所述集中计算层包括一个或多个集中计算节点，其中每个集中计算节点与所述本地计算层中的一个或多个本地计算节点相连接。

501，本地计算节点执行该本地计算节点所连接的无线收发节点组合中的无线收发节点所对应的小区的全部通信处理或第一部分通信处理。

502，集中计算节点在所述本地计算节点执行所述第一部分通信处理的情况下，执行所述一个或多个本地计算节点所连接的无线收发节点组合中的无线收发节点所对应的小区的第二部分通信处理，其中所述全部通信处理包括所述第一部分通信处理和第二部分通信处理。

应注意，图5中虽然将501显示为在502之前执行，但是本发明实施例不限于此。事实上501和502的执行可以相对独立，例如，501可以在502之后执行，501也可以与502同时执行。这些修改均落入本发明实施例的范围内。

图6是根据本发明另一实施例的通信***的管理方法的示意流程图。图6的实施例的通信***可以如图2所示，在本实施例的通信***的某些部分中，可以根据实际需求在集中计算层140和本地计算层120之间增加一个或多个中间计算层130，以进一步减少带宽需求。每个中间计算层130包括一个或多个中间计算节点135。

除了图5所示的501和502之外，图6的方法还包括：

503，中间计算节点在本地计算节点执行所述第一部分通信处理的情况下，执行该中间计算节点连接到的本地计算节点所连接的无线收发节点组合中的无线收发节点所对应的小区的第三部分通信处理，其中所述全部通信处理包括所述第三部分通信处理。

另外，在微小区BRU也分担部分处理任务的情况下，图6的方法还包括：

504，微小区射频与基带拉远单元BRU在本地计算节点执行所述第一部分通信处理的情况下，执行该微小区射频与基带拉远单元所对应小区的第四部分通信处理。

或者，在集中计算节点145-1/145-2之间可以进行计算任务调度时，图6的方法还包括：

505，集中计算节点经任务调度将第五部分通信处理转移至其他集中计算节点执行。

其中所述全部通信处理还包括上述第四部分通信处理和/或上述第五部分通信处理。

图6中各个过程可以根据需要改变执行顺序、删除、替换，这些修改均落入本发明实施例的范围内。

本发明实施例的通信处理可包括以下处理中的一个或多个：数据处理、联合干扰管理处理、联合资源调度处理、联合计算任务调度处理、多种制式的通信处理、多种制式之间的联合通信处理、微小区射频拉远单元和/或微小区射频与基带拉远单元的工作模式或开闭状态的联合控制。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的图5和图6的方法的具体过程，可以参考前述通信***的实施例中的对应过程，在此不再赘述。

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

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

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

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

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

Claims

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

无线收发层，包括一个或多个无线收发节点组合，其中每个无线收发节点组合中的无线收发节点至少包括宏小区射频单元、微小区射频拉远单元、微小区射频与基带拉远单元中的一种；

本地计算层，包括一个或多个本地计算节点，其中每个本地计算节点与一个或相邻的多个无线收发节点组合中的无线收发节点相连，用于执行该本地计算节点所连接的无线收发节点组合所对应的小区的全部通信处理或第一部分通信处理；

集中计算层，包括一个或多个集中计算节点，其中每个集中计算节点与所述本地计算层中的一个或多个本地计算节点相连接，用于在所述本地计算节点执行所述第一部分通信处理的情况下，执行所述一个或多个本地计算节点所连接的无线收发节点组合所对应的小区的第二部分通信处理，

其中所述全部通信处理包括所述第一部分通信处理和第二部分通信处理。

2.如权利要求1所述的通信***，其特征在于，所述集中计算节点与所述本地计算层中的一个或多个本地计算节点相连接包括：

所述集中计算节点直接连接到所述本地计算节点；或者，

所述集中计算节点经由一个或多个中间计算节点连接到所述本地计算节点，每个中间计算节点用于在所述本地计算节点执行所述第一部分通信处理的情况下，执行该中间计算节点连接到的本地计算节点所连接的无线收发节点组合中的无线收发节点所对应的小区的第三部分通信处理，

其中所述全部通信处理包括所述第三部分通信处理。

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

所述微小区射频与基带拉远单元用于在所述本地计算节点执行所述第一部分通信处理的情况下，执行所述微小区射频与基带拉远单元所对应小区的第四部分通信处理；或者

所述集中计算节点用于经任务调度将第五部分通信处理转移至其他集中计算节点执行，

其中所述全部通信处理还包括所述第四部分通信处理和/或所述第五部分通信处理。

4.如权利要求2所述的通信***，其特征在于，

所述宏小区射频单元和所述本地计算节点之间、所述微小区射频拉远单元和所述本地计算节点之间、所述宏小区射频单元和所述集中计算节点之间、所述微小区射频拉远单元和所述集中计算节点之间，通过第一类接口连接，所述第一类接口用于传输基带数据和控制状态消息；

所述微小区射频与基带拉远单元和所述本地计算节点之间、所述微小区射频与基带拉远单元和所述集中计算节点之间、所述本地计算节点和所述集中计算节点之间、所述本地计算节点和所述中间计算节点之间、上下层的所述中间计算节点之间、所述中间计算节点和所述集中计算节点之间、所述集中计算节点之间，通过第二类接口连接，所述第二类接口用于传输基带数据、数据包和控制状态消息；

所述集中计算节点和核心网之间通过第三类接口连接，所述第三类接口用于传输数据包和控制状态消息。

5.如权利要求2所述的通信***，其特征在于，所述通信处理包括数据处理，

所述本地计算节点进行数据的分流处理以区分出该本地计算节点需要处理的数据和非该本地计算节点需要处理的数据，和/或对完成通信处理的数据进行聚合；

所述中间计算节点进行数据的分流处理以区分出该中间计算节点需要处理的数据和非该中间计算节点需要处理的数据；

所述集中计算节点进行数据的分流处理以区分出该集中计算节点需要处理的数据和非该集中计算节点需要处理的数据，和/或对完成通信处理的数据进行聚合。

6.如权利要求2所述的通信***，其特征在于，所述通信处理包括联合干扰管理处理，

所述本地计算节点优先执行与该本地计算节点连接的无线收发节点组合中的无线收发节点所对应的小区内的无明显干扰的用户设备的通信处理或仅受到来自所述本地计算节点所连接的无线收发节点组合中的其他无线收发节点干扰的用户设备的干扰处理，

所述中间计算节点优先执行与该中间计算节点连接的下层中间计算节点或本地计算节点相关联的无线收发节点组合中的无线收发节点所对应小区内的用户设备的干扰处理，其中该用户设备受到来自与该中间计算节点连接的其他下层中间计算节点或本地计算节点相关联的无线收发节点组合中的无线收发节点所对应小区的干扰，

所述集中计算节点优先执行与该集中计算节点连接的下层中间计算节点或本地计算节点相关联的无线收发节点组合中的无线收发节点所对应小区内的用户设备的干扰处理，其中该用户设备受到来自与该集中计算节点连接的其他下层中间计算节点或本地计算节点相关联的无线收发节点组合中的无线收发节点所对应小区的干扰。

7.如权利要求2所述的通信***，其特征在于，所述通信处理包括联合资源调度处理，

所述本地计算节点执行与该本地计算节点连接的无线收发节点组合中的无线收发节点所对应的小区之间的资源调度，

所述中间计算节点执行与该中间计算节点连接的无线收发节点组合中的无线收发节点所对应的小区之间的资源调度，

所述集中计算节点执行与该集中计算节点连接的无线收发节点组合中的无线收发节点所对应的小区之间的资源调度。

8.如权利要求7所述的通信***，其特在于，

本地计算节点、中间计算节点和集中计算节点进行调度的资源被配置为彼此不同，或者

优先由位于上层的计算节点执行资源调度。

9.如权利要求2所述的通信***，其特征在于，所述无线收发节点组合中的无线收发节点和本地计算节点之间、所述本地计算节点和中间计算节点之间、或者上下层的所述中间计算节点之间通过光纤、数字用户线路、微波或电力线连接。

10.如权利要求9所述的通信***，其特征在于，基于节点计算能力、节点间距离、节点间传输带宽需求和/或节点间传输延迟需求，确定节点之间的连接介质。

11.如权利要求2所述的通信***，其特征在于，所述通信处理包括联合计算任务调度处理，

本地计算节点和连接到该本地计算节点的中间计算节点之间，上下层连接的中间计算节点之间，中间计算节点和连接到该中间计算节点的集中计算节点之间，相互连接的集中计算节点之间，根据计算负荷、计算能力、传输带宽和传输时延相互转移计算任务。

12.如权利要求11所述的通信***，其特征在于，

由计算节点基于其他计算节点的请求来调度所述计算任务的转移；或者，

由位于上层的计算节点调度所述计算任务的转移。

13.如权利要求2所述的通信***，其特征在于，所述无线收发节点组合包括多种制式的无线收发节点，所述通信处理包括多种制式的通信处理和/或多种制式之间的联合通信处理。

14.如权利要求1-2、4-13任一项所述的通信***，其特征在于，每个本地计算节点与一个或相邻的多个无线收发节点组合相连包括：

根据网络配置确定与所述本地计算节点连接的无线收发节点组合中无线收发节点，以及相连接的无线收发节点组合的数量。

15.如权利要求1所述的通信***，其特征在于，所述本地计算节点与一个无线收发节点组合中的无线收发节点相连接，所述无线收发节点组合包括与所述本地计算节点共站址的宏小区射频单元，宏小区射频单元覆盖范围内的微小区射频拉远单元和/或微小区射频与基带拉远单元。

16.如权利要求1所述的通信***，其特征在于，所述本地计算节点与一个无线收发节点组合中的无线收发节点相连接，所述无线收发节点组合包括规定范围内的微小区射频拉远单元和/或微小区射频与基带拉远单元，所述规定范围根据网络配置确定。

17.如权利要求16所述的通信***，其特征在于，所述通信处理包括所述无线收发节点组合中的微小区射频拉远单元和/或微小区射频与基带拉远单元的工作模式或开闭状态的联合控制。

18.一种通信***的管理方法，其特征在于，所述通信***包括无线收发层、本地计算层和集中计算层，所述无线收发层包括一个或多个无线收发节点组合，其中每个无线收发节点组合中的无线收发节点至少包括宏小区射频单元、微小区射频拉远单元、微小区射频与基带拉远单元中的一种；所述本地计算层包括一个或多个本地计算节点，其中每个本地计算节点与一个或相邻的多个无线收发节点组合中的无线收发节点相连，所述集中计算层包括一个或多个集中计算节点，其中每个集中计算节点与所述本地计算层中的一个或多个本地计算节点相连接，

所述方法包括：

所述本地计算节点执行该本地计算节点所连接的无线收发节点组合中的无线收发节点所对应的小区的全部通信处理或第一部分通信处理；

所述集中计算节点在所述本地计算节点执行所述第一部分通信处理的情况下，执行所述一个或多个本地计算节点所连接的无线收发节点组合中的无线收发节点所对应的小区的第二部分通信处理，

19.如权利要求18所述的方法，其特征在于，所述集中计算节点经由一个或多个中间计算节点连接到所述本地计算节点，

所述方法还包括：

所述中间计算节点在所述本地计算节点执行所述第一部分通信处理的情况下，执行该中间计算节点连接到的本地计算节点所连接的无线收发节点组合中的无线收发节点所对应的小区的第三部分通信处理，

其中所述全部通信处理包括所述第三部分通信处理。

20.如权利要求18或19所述的方法，其特征在于，还包括：

所述微小区射频与基带拉远单元在所述本地计算节点执行所述第一部分通信处理的情况下，执行所述微小区射频与基带拉远单元所对应小区的第四部分通信处理；或者

所述集中计算节点经任务调度将第五部分通信处理转移至其他集中计算节点执行，

21.如权利要求18或19所述的方法，其特征在于，所述通信处理包括以下处理中的一个或多个：数据处理、联合干扰管理处理、联合资源调度处理、联合计算任务调度处理、多种制式的通信处理、多种制式之间的联合通信处理、微小区射频拉远单元和/或微小区射频与基带拉远单元的工作模式或开闭状态的联合控制。