CN106658520A - 构建任务处理路径的方法及*** - Google Patents

Abstract

本发明提供一种用于从多个处理资源池中构建任务处理路径的方法。该方法包括：基于任务需求确定任务处理路径，其中，所述任务处理路径包含从所述多个资源池中选择的处理单元；基于所述任务处理路径查找所述处理单元的对应的目的地址；向所述处理单元发送通知消息，其中所述通知消息中包含所述处理单元的数据流将要发送的目的地址。通过本发明的方法，能够按需、高效的构建任务处理路径，以完成传输数据流的交换路径的配置。

Description

构建任务处理路径的方法及***

技术领域

本发明涉及通信技术领域，尤其涉及一种构建任务处理路径的方法和***。

背景技术

传统的蜂窝网络采用垂直式的网络架构模型，小区的资源采用垂直独立的资源分配方式，如图1a所示，在GSM、TDSCDMA、LTE的基站中，分别将协议处理、基带处理、射频处理组成小区，并通常以小区的峰值负载需求作为小区的容量指标来分配资源。在这种架构下，不同基站之间不能共享处理资源，并且各小区的实时负载在时间上和空间上具有巨大的不均匀性。空闲的网络资源往往不能为其他基站所用，造成网络资源利用率低，只能通过增加基站数目，密集部署基站来应对日益增长的移动数据量的需求。

为了提高资源利用率，节约移动网络运营成本，人们开始研究水平共享式网络架构，如图1b所示，在该架构下，采取资源水平池化的概念，将各种类型的基站资源构成处理资源池，接受统一的资源管控，进行灵活的调配。例如，可以采用多模基站的通用架构将GSM、TDSCDMA、LTE中的资源作为统一的资源池，如形成射频处理资源池(射频处理1、射频处理2和射频处理3)、基带处理资源池和协议处理资源池，以通过动态组合射频处理资源、基带处理资源和协议处理资源形成小区，完成对目标区域的覆盖。通过这种方式，可以提高网络资源的利用率，并且只需要对相应的处理单元进行配置加载或升级定制，就可以重用现有的基础设施，从而满足网络升级和发展的需求。

然而，在目前的水平共享式的网络架构中，资源池中各处理单元之间一般采用较为成熟的互连网络设计，如图2所示，基带处理资源池中的DSP处理单元之间、不同机箱之间通过串行RapidIO(sRIO)实现互联，射频处理资源池与基带处理资源池之间通过CPRI(通用公共无线电接口)协议实现互联，基带处理资源池与协议处理资源池之间通过光纤或者以太网进行互联。在此示例中，如果任务处理的路径(或称数据流的传输路径)是从射频处理单元2(简称RRU2)到基带处理单元1(简称BBU1)，再到协议处理单元1(简称PPU1)，则中间需要经过CPRI交换机、sRIO交换机和以太网交换机。为了完成数据流的传输，需要配置处理单元之间的数据交换路径。例如，在现有技术中，通常是通过RRU2的配置接口，手动为RRU2配置BBU1的地址；通过BBU1的配置接口，为BBU1配置PPU1的地址，然后，RRU2在数据包生成后填充BBU1的地址为目的地址，BBU1在数据报生成后填充PPU1的地址为目的地址。

因此，现有技术中的这种方法是针对各个互联网络分别配置连接关系，任务处理路径中各处理单元的地址需要分别获取。其存在的主要问题是：一是地址的获取时间可能不同步，从而可导致任务处理路径初期的建立错误；二是由于各个交换机的互联和交换机制不同，如图2所示，RRU2与BBU1之间的交换机制为CPRI交换，BBU1与PPU1之间的交换机制为RapidIO交换，其采用不同的地址定义，使得配置操作复杂，实现困难；三是当任务处理路径改变时，需要重新手动进行配置。

发明内容

本发明的目的在于克服上述现有技术的缺陷，提供一种能够灵活动态地构建任务处理路径的方法。

根据本发明的第一方面，提供了一种用于从多个资源池中构建任务处理路径的方法。该方法包括：

步骤1：基于任务需求确定任务处理路径，其中，所述任务处理路径包含从所述多个资源池中选择的处理单元；

步骤2：基于所述任务处理路径查找所述处理单元的对应的目的地址；

步骤3：向所述处理单元发送通知消息，其中所述通知消息中包含所述处理单元的数据流将要发送的目的地址。

在一个实施例中，该方法还包括从所述处理单元接收反馈消息。

在一个实施例中，所述反馈消息包括下列项中的至少一项：目的地址是否配置成功的标志、处理单元的状态、处理单元的资源利用率、处理单元的地址变化。

在一个实施例中，该方法还包括基于下列项中的至少一项来改变所述任务处理路径：处理单元的资源利用率；处理单元的状态；网络负载；任务需求的变化。

在一个实施例中，所述处理单元的类型包括处理板、DSP、CPU、内存、硬盘、虚拟内存。

在一个实施例中，所述任务需求包括任务优先级、带宽、时延、吞吐量、载波数量中一项或多项。

在一个实施例中，在步骤2中，通过预先配置的各个处理单元的地址表来查找所述处理单元的对应的目的地址。

根据本发明的第二方面，提供了一种用于从多个处理资源池中构建任务处理路径的***。该***包括：用于基于任务需求确定任务处理路径的装置，其中，所述任务处理路径包含从所述多个处理资源池中选择的处理单元；用于基于所述任务处理路径查找所述处理单元的对应的目的地址的装置；用于向所述处理单元发送通知消息的装置，其中所述通知消息中包含所述处理单元的数据流将要发送的目的地址。

在一个实施例中，该***还包括用于配置或生成所述任务需求的装置。

在一个实施例中，该***还包括管理代理装置，用于向所述处理单元统一发送通知消息和/或为所述处理单元的数据流填充目的地址。

与现有技术相比，本发明的优点在于：通过统一配置各处理单元的目的地址，能够按需、高效地构建任务处理路径；通过动态的组合资源池中的处理单元，能够完成特定功能的处理，并灵活的扩展新功能。

附图说明

通过阅读参照以下附图所作的对非限制性实施例的详细描述，本申请的其它特征、目的和优点将会变得更明显。

图1a示出了传统的垂直式网络架构的示意图

图1b示出了水平共享式网络架构的示意图。

图2示出了基站中资源池的示意图。

图3示出了根据本发明一个实施例的构建任务处理路径的方法的流程图。

图4示出了根据本发明一个实施例的构建任务处理路径的***的示意图。

图5示出了根据本发明的另一实施例的构建任务处理路径的***的示意图。

图6示出了适合于采用本发明的方法和***的资源池的结构图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅用于解释相关发明，而非对该发明的限定。另外，还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

根据本发明一个实施例，提供一种构建任务处理路径的方法。图3示出了该方法的实施步骤。

1)步骤S310，选取任务处理路径。

选取任务处理路径是指从资源池中选择处理能力满足任务需求的处理单元。

在本文中，所述处理单元是指包含硬件且具有一定处理能力的功能单元。例如，资源池中的处理单元可以是包含大级别的硬件单元，例如，基带处理板等，也可以包括相对小级别的处理单元，例如，DSP等。处理单元可以包括诸如CPU、DSP、内存、磁盘等的物理资源，也可以包括诸如虚拟内存等的虚拟资源。

所述任务需求可以由用户配置或者根据任务要求的带宽、时延、吞吐量、载波数量等确定。例如，任务需求可以确定为是一个载波或者是最大传输速率50Mbps，或者是两者的结合。本发明对任务需求的类型不作限制。

所述任务处理路径是指资源池中的处理单元的组合，用于完成数据流的传输。任务处理路径中处理单元的数量可以是两个或两个以上。

任务处理路径的选择方法有多种。例如，可以简单地从资源池中分别选择处理能力满足任务需要的处理单元，参见图2所示，如果当前的任务需求是一个LTE载波(20M，2*2MIMO)，而在射频处理资源池、基带处理资源池和射频处理资源池中，还存在的剩余资源分别是RRU2(射频处理单元2)、基带处理单元1(BBU1)和协议处理单元1(PPU1)，并且通过计算可知RRU2、BBU1和PPU1可以承担该LTE载波的处理任务。因此，选择的任务处理路径为：RRU2→BBU1→PPU1。具体而言，如果基带处理资源池中的BBU1为一个型号为TI TCI6618的DSP，能够支持双通道20MHz、300Mbps的下行链接和150Mbps上行链接的2x2多输入多输出(MIMO)解决方案，则选择BBU1即可处理当前任务的基带部分。RRU和PPU的选择可以采用类似的方法来分析。。

在任务处理路径确定之后，也可以根据网络的监测数据或资源池中处理单元的实际状态而动态地改变该任务处理路径。例如，如果上述LTE载波的负载增加，PPU1处理能力不能满足，则可以从协议资源池中再选择合适的处理单元(如PPU2)增加到该任务处理路径中。同理，如果该LTE载波的负载减小，则可以回收某些处理单元，以用于其他的虚拟基站。通过这种方式，可以有效的提高处理单元的利用率。

由上述可知，任务处理路径中的各处理单元之间的关系可以是一对一、一对多或者多对多的情况。例如，BBU1可以对应两个处理单元PPU1和PPU2。

2)步骤S320，查找任务处理路径中处理单元的数据流的目的地址。

此步骤的目的在于，根据任务处理路径中处理单元之间的连接关系，获得各个处理单元其处理完的数据流需转发的下一个处理单元。

为了实现上述目的，可以预先存储反映各个处理单元的连接关系的信息表，以获知整个资源池的处理单元的组成情况，例如，对于每个处理单元，可以保存该处理单元的类型、标志、所属硬件板卡、所属机箱、连接情况等(如所连接的交换机及交换机的地址)。每个处理单元可能存在多个连接关系，例如，图2中的基带处理资源池，既通过CPRI交换网络与射频处理单元连接，又通过sRIO交换网络与协议处理单元连接。

表1以BBU为例，示意了信息表的所包含的内容。通过该信息表即可以获取每个处理单元的连接关系以及其地址。

表1 BBU的信息表

因此，在此步骤中，根据任务处理路径的组成，通过查找处理单元的信息表，即可获得相关处理单元数据流转发的目的地址。

3)步骤S330，将目的地址通知相应的处理单元。

在此步骤中，向处理单元发送通知消息，以执行通知目的地址的行为，例如，如果RRU2的数据流需要转发给BBU1，则BBU1的地址就是RRU2上数据流的目的地址，为完成数据流的传输，需要将BBU1对应的地址通知RRU2。

例如，上述通知消息可以包括但不限于以下项：

信息类型：用于表明该信息是通知目的地址的信息。

信息编号：是该信息的唯一标识，可以由***统一生成。

处理单元标识：是需要通知的处理单元的唯一标识，例如，DSP 1、CPU 1等。

目的地址：用于标识数据流需要发送到的地址。根据处理单元的类型不同，目的地址也可以包括多种类型，例如IP地址、MAC地址等，DSP编号、内存编号等。根据处理单元的对应关系不同，在一条通知消息中可以包括多个目的地址。进一步地，还需要在通知消息中指明地址类型，以便处理单元能够正确解析。

4)步骤S340，判断是否获得所有处理单元的反馈。

为了知悉各个处理单元是否已接收到目的地址并已经成功地完成相关的配置，在启动任务处理之前，可以进一步从所有的处理单元接收针对目的地址通知行为的反馈消息。如果指示目的地址配置成功，则执行步骤S350，否则可以选择继续等待一段时间、重传或者考虑更新任务处理路径。通过这种方式，能够保证在各处理单元均成功配置之后，再同步地进行数据流的传输，从而避免因处理单元异常而造成的传输数据错误的情况。

在一个实施例中，从处理单元接收的反馈信息包括但不限于下列项：

信息类型：用于表明该信息为通知目的地址的反馈信息。

信息编号：信息编号为通知目的地址信息的编号，以表明该反馈信息所对应的是哪一条通知目的地址的信息。

是否成功标志：用于向反馈该目的地址是否配置成功。

反馈消息还可以进一步包括处理单元是否正常工作、资源利用率、地址的变化等。

在实际的应用中，上述所列的项可以包含在一条消息中，或者分别存在于多条消息中。例如，采用状态报告消息(status report)单独指示处理单元异常。

反馈信息的上报可以是事件触发式上报或者周期性的上报。例如，在目的地址配置成功、目的地址配置失败、处理单元异常、或处理单元的负载超过阈值时、处理单元的本身地址发生变化时立即上报，从而可以基于该反馈消息，决定是否更新任务处理路径。而对于资源利用率的报告可以采用周期性上报的方式。

在另一实施例中，为了减小信息的交互，也可以在发送通知信息之后，等待预定的时间阈值之后，直接执行步骤S350。

5)步骤S350，启动任务。

启动任务即开始实际的数据流传输，例如，如图2所示，对于任务处理路径RRU2至BBU1再至PPU1，其数据传输的基本过程是：需要处理的数据首先进入RRU2进行处理，处理完的数据根据CPRI协议封装，在目的地址中填入BBU1的地址，发送到CPRI交换机上；CPRI交换机根据数据包的目的地址，将其转发给BBU1；BBU1收到后，进行基带处理，处理完毕后将数据根据RapidIO协议封装，在目的地址中填入PPU1的地址，发送到sRIO交换机上；sRIO交换机根据数据包的目的地址，将其转发给PPU1；PPU1收到后，就可以继续进行协议处理，从而完成该任务。

由上可知，本发明的构建任务处理路径的方法能够向相关的处理单元集中通知其完成数据流之后转发的目的地址。这种方式可以灵活有效地实现任务处理路径的建立和更新。

根据本发明的一个实施例，还提供了一种适合于执行本发明的构建任务处理路径的方法的***。如图4所示，该***包括配置层、控制层和物理资源层(即资源池)。配置层通过配置接口与控制层进行信息交互，控制层通过控制接口与资源池进行信息交互。配置层和控制层只是逻辑功能模块，可以实现在图4所示的管控中心中，也可以独立于管控中心。

在此实施例中，配置层的作用是为控制层传递任务需求。例如，配置层的任务需求可以由用户来定义。配置层也可以提供接口来接收来自与其他外部模块的任务处理需求。

控制层的作用包括但不限于：为某些处理单元分配地址；保存整个资源池的处理单元的组成；根据配置层传递的任务需求、物理资源层的实际情况和/或管控中心的资源管理策略，形成任务处理路径；与处理单元进行信息交互，以配置底层的物理资源，生成与任务处理路径匹配的交换路径；获取处理单元的状态信息等。

控制层与处理单元之间的信息交互，包括向处理单元发送告知其目的地址的通知消息以及从处理单元接收反馈信息。

控制层还可以负责资源池中某些处理单元的目的地址的分配，例如，对于以太网交换机来说，所连接设备的MAC地址都是设备自带的，不需要额外分配。而对于如SRIO交换机来说，所连接设备的地址是需要分配的。在控制层为某些处理单元分配地址之后，通知给相应的交换机和处理单元，以使交换机完成处理单元地址与端口的对应。只要进行信息交互的双方可以根据目的地址唯一地识别目标处理单元，所分配的目的地址可以是多种形式，例如，对于DSP地址而言，可以通过简单的统一编号来标识，或者采用DSP所属的机架号+单板号+本地的DSP标号来唯一确定。

控制层和处理单元之间的控制接口是逻辑接口，该控制接口也可以存在于控制层和交换网络之间。控制层和处理单元之间的信息交互可以由控制层分别与各个处理单元直接通信，也可以是控制层先通知管理代理，由管理代理再进一步通知处理单元，图5示意了管理代理的一个示例。

在另一个实施例中，管理代理也可以存在于每个资源池内部，或者每个交换网络内部。例如，CPRI交换网络中存在一个管理代理，控制层将BBU1的地址通知到CPRI交换网络中的管理代理，管理代理进行保存。RRU2处理完的数据进入到CPRI交换网络中，其内部的管理代理将RRU2的数据流的目的地址中填入BBU1的地址；交换网络中的交换实体根据目的地址，将其转发给BBU1。通过这种由管理代理集中进行数据流的目的地址填充的方式，可以避免控制层和资源池中每个处理单元进行信息交互，便于集中管理处理单元。

由上述可知，在根据本发明的***中，配置层和控制层的功能相对单一、独立，从而能够降低模块之间的耦合度和实现的复杂性。通过控制层向处理单元告知其数据流转发的目的地址的方式，可以灵活动态地构建或改变任务处理路径，并避免处理单元获取目的地址的时间不同步的问题。此外，控制层通过从处理单元接收反馈信息可以及时获取各处理单元的状态(正常、异常、资源利用率等)，以便集中地管理资源池。

为了清楚起见，在本申请中，主要以基站处理资源为例，介绍了本发明的方法和***，本领域的技术人员应当理解，上述的任务处理路径的构建方法和***也可以应用其它技术领域，例如，对于图6所示的资源池的示例，其包括第一处理资源池、第二处理资源池和第三处理资源池，而各处理资源池之间采用交换矩阵或交换网络连接，在这种情况下，可以应用根据本发明的方法和***来构建任务处理路径，同样可以避免传统地采用交换协议构建数据流传输路径时导致的时间不同步等问题。

虽然已经通过例子对本发明的一些特定实施例进行了详细说明，但是本领域的技术人员应该理解，以上例子仅是为了进行说明，而不是为了限制本发明的范围。本领域的技术人员应该理解，可在不脱离本发明的范围和精神的情况下，对以上实施例进行修改。本发明的范围由所附权利要求来限定。

Claims (10)

1.一种用于从多个处理资源池中构建任务处理路径的方法，包括：

步骤1：基于任务需求确定任务处理路径，其中，所述任务处理路径包含从所述多个处理资源池中选择的处理单元；

步骤2：基于所述任务处理路径查找所述处理单元的对应的目的地址；

步骤3：向所述处理单元发送通知消息，其中所述通知消息中包含所述处理单元的数据流将要发送的目的地址。

2.根据权利要求1所述的方法，其中，还包括：从所述处理单元接收反馈消息。

3.根据权利要求2所述的方法，其中，所述反馈消息包括下列项中的至少一项：目的地址是否配置成功的标志、处理单元的状态、处理单元的资源利用率、处理单元的地址变化。

4.根据权利要求1所述的方法，还包括基于下列项中的至少一项来改变所述任务处理路径：处理单元的资源利用率；处理单元的状态；网络负载；任务需求的变化。

5.根据权利要求1所述的方法，其中，所述处理单元的类型包括处理板、DSP、CPU、内存、硬盘、虚拟内存。

6.根据权利要求1所述的方法，其中，所述任务需求包括任务优先级、带宽、时延、吞吐量、载波数量中一项或多项。

7.根据权利要求1所述的方法，其中，在步骤2中，通过预先配置的各个处理单元的地址表来查找所述处理单元的对应的目的地址。

8.一种用于从多个处理资源池中构建任务处理路径的***，包括：

用于基于任务需求确定任务处理路径的装置，其中，所述任务处理路径包含从所述多个处理资源池中选择的处理单元；用于基于所述任务处理路径查找所述处理单元的对应的目的地址的装置；

用于向所述处理单元发送通知消息的装置，其中所述通知消息中包含所述处理单元的数据流将要发送的目的地址。

9.根据权利要求8所述的***，还包括用于配置或生成所述任务需求的装置。

10.根据权利要求8或9所述的***，还包括管理代理装置，用于向所述处理单元统一发送通知消息和/或为所述处理单元的数据流填充目的地址。