CN104123185A - 一种资源调度方法、装置及*** - Google Patents

Abstract

本发明公开了一种资源调度方法，该方法包括：设置业务调度单元及环境调度单元；将要执行的业务划分为一个以上子业务，在执行所述业务的各子业务过程中，当需要使用相应资源时，所述业务调度单元通知所述环境调度单元分配所需资源。本发明同时公开了一种资源调度装置及***，采用本发明的方法、装置及***，在处理实时信号时，能有效地实现资源的动态调度。

Description

一种资源调度方法、装置及***

技术领域

本发明涉及使用通用处理器(GPP，General Purpose Processors)处理实时信号技术，尤其涉及一种基于GPP的资源调度方法、装置及***。

背景技术

随着近几年能源和电力价格的上涨，全球的移动通信网络运营商面临日渐严重的成本压力，同时运营商获取站址和机房的难度也在不断加大。由于全球大多数主流运营商通常会同时拥有2-3个不同通信制式的网络，为保证网络的服务质量，就需要部署大量的基站以解决网络覆盖的问题。站址和机房资源的相对稀缺与不断增长的基站数量的矛盾在一定时期内无法协调，目前已成为运营商无法回避的难题。如今，电信市场的激烈竞争使得单用户平均收入(ARPU)增长缓慢甚至下降，严重消弱了移动运营商的盈利能力。而运营商收入的下降必将会导致建网和设备采购投资的压缩，进而影响到全行业的整体发展。面对这种局面，出于行业持续盈利和长期发展考虑，移动通信产业界提出了新型的绿色演进的无线网络(C-RAN)***架构，以引导未来集中式基带处理网络架构技术的发展。

C-RAN***主要由远端的无线射频单元(RRU)与天线组成的分布式无线网络、具有高带宽、低延迟特性的光传输网络、以及集中式基带处理池三大部分组成。其中，集中式基带处理池由集中在一个物理站点的多个基带单元(BBU)构成，所有BBU和RRU通过具有高带宽、低延迟特性的光传输网络连接起来；并且，集中式基带处理池中多个BBU之间交叉连接。实现集中式基带处理池的功能需要应用基站虚拟化技术，具体地，需要支持集中式基带处理池的物理资源和计算能力的虚拟分配和组合。

集中式基带处理池中多个BBU之间互联互通，构成高容量、低延迟的互联架构，而远端的RRU通过互联架构即光传输网络可以与集中式基带处理池中任意一个BBU进行交互，这种方式可以认为是对现有BBU进行集中化集成处理，如此，有效地实现了载波负载均衡、容灾备份，同时还能实现提高设备利用率、减少基站机房数量、以及降低能耗的目的。

现有实现集中式基带处理池的功能的技术方案中，多采用传统的数字信号处理器(DSP，Digital Signal Processing)+现场可编程门阵列(FPGA，FieldProgrammable Gate Array)的架构处理基带信号，并采用额外的附加交换设备实现多个BBU之间的同相/正交相位(I/Q，In-phase/Quadrature-phase)路数据的交换。但是，以DSP为基带处理核心的硬件架构必然会有着对应的软件架构特点，具体地，由于DSP的操作***相对简单，当DSP内部多个核之间协作处理信号时，操作***很难自动化分配处理资源，因此，DSP的软件架构设计往往基于固定的时序图。如此，当***配置发生变化，比如：当从时分同步码分多址接入(TD-SCDMA，Time Division-Synchronous Code Division MultipleAccess)软升级为时分双工-长期演进(TDD-LTE，Time Division Duplexing-LongTerm Evolution)时，往往需要重启离线更改DSP的软件配置。并且，当DSP的软件配置组合复杂时，固定时序设计会给软件设计带来极高的复杂度，如此，DSP软件的升级和维护会大大增大成本。

另外，当多个DSP间相互协作完成信号处理时，各DSP间的信号交互与DSP内多核间的信号交互会采用不同的方式。由于协作处理时额外需要考虑信号发送时延、以及对方DSP工作的正常性，因此，在这种情况下，底层信息交互的维护会相对复杂。

为解决DSP+FPGA架构带来的缺陷，提出了一种基于GPP、通过软件无线电技术实现多标准的统一开放的实现集中式基带处理池功能的技术方案，采用GPP的优点是：首先，GPP具有后向兼容好的优点，因此有利于网络***的平滑演进；其次，在GPP中，多核间的通信有成熟的方式和方法，操作***也较适合自动化地任务分配，对编程模型的要求比较简单。

但是，目前，在实现集中式基带处理池功能时，即：在处理实时的数字信号时，传统的基于操作***自动分配核资源的处理方式影响了处理效率。

发明内容

有鉴于此，本发明的主要目的在于提供一种资源调度方法、装置及***，在处理实时信号时，能有效地实现资源的动态调度。

为达到上述目的，本发明的技术方案是这样实现的：

本发明提供了一种资源调度方法，设置业务调度单元及环境调度单元；该方法还包括：

将要执行的业务划分为一个以上子业务，在执行所述业务的各子业务过程中，当需要使用相应资源时，所述业务调度单元通知所述环境调度单元分配所需资源。

上述方案中，所述将要执行的业务划分为一个以上子业务，包括：

将所述业务划分为一个以上能独立运行的子业务；

确定各子业务所需的参数信息；

确定各子业务之间的关联关系。

上述方案中，所述将所述业务划分为一个以上能独立运行的子业务，为：

依据划分出的子业务之间的耦合相关性小的策略，将所述业务划分为一个以上能独立运行的子业务。

上述方案中，在执行所述业务的各子业务之前，该方法还包括：

根据各子业务的启动条件及处理时延，确定环境调度单元的触发机制；

相应的，所述业务调度单元根据确定的环境调度单元的触发机制通知所述环境调度单元分配所述所需资源。

上述方案中，该方法还包括：

在执行所述业务的各子业务过程中，所述业务调度单元与模块资源的算法模块进行接口适配，完成各子业务处理。

上述方案中，在分配所述所需资源时，该方法进一步包括：

所述环境调度单元根据资源的使用情况及所述所需资源的使用时间片，分配所述所需资源。

本发明又提供了一种资源调度装置，该装置包括：业务调度单元、以及环境调度单元；其中，

业务调度单元，用于在执行划分为一个以上子业务的业务的各子业务过程中，当需要使用相应资源时，通知环境调度单元；

环境调度单元，用于收到业务调度单元的通知后，分配所需资源。

上述方案中，所述环境调度单元，具体用于：在分配所述所需资源时，根据资源的使用情况及所述所需资源的使用时间片，分配所述所需资源。

本发明还提供了一种资源调度***，该***包括：应用子***、平台资源、硬件资源、底层资源、以及模块资源；所述应用子***进一步包括资源调度装置，所述资源调度装置包括：业务调度单元、以及环境调度单元；其中，

业务调度单元，用于在执行划分为一个以上子业务的业务的各子业务过程中，当需要使用相应资源时，通知环境调度单元；

环境调度单元，用于收到业务调度单元的通知后，分配所需资源。

上述方案中，所述平台资源、所述硬件资源、以及所述底层资源组成资源调度***的资源，用于被所述环境调度单元控制。

上述方案中，所述环境调度单元，具体用于：在分配所述所需资源时，根据资源的使用情况及所述所需资源的使用时间片，分配所述所需资源。

上述方案中，所述模块资源进一步包括算法模块；所述业务调度单元，还用于在执行所述业务的各子业务过程中，所述业务调度单元与所述算法模块进行接口适配，完成各子业务处理。

本发明提供的资源调度方法、装置及***，设置业务调度单元及环境调度单元；将要执行的业务划分为一个以上子业务，在执行所述业务的各子业务过程中，当需要使用相应资源时，所述业务调度单元通知所述环境调度单元分配所需资源，业务调度和资源调度进行了分离，由环境调度单元统一分配资源，如此，在处理实时信号时，能有效地实现资源的动态调度。并且，由于业务调度和资源调度进行了分离，资源能最大化的共享。

另外，依据划分出的子业务之间的耦合相关性小的策略，将所述业务划分为一个以上能独立运行的子业务，如此，能使环境调度单元更加灵活地调度资源。

本发明中，在执行所述业务的各子业务过程中，所述业务调度单元与模块资源的算法模块进行接口适配，完成各子业务处理，业务调度单元不关心通信机制，也不关心各处理资源之间的相互处理时序关系，仅调用算法模块，即仅完成某一空口制式的算法接口的适配和信号处理的优化，如此，提高了代码的可重用性，使得软件升级简单化，从而有利于***的平滑演进。

本发明中，在执行所述业务的各子业务过程中，所述环境调度单元根据确定的维护机制，实时维护各处理资源的任务队列，如此，最大化地保证了***异常的可恢复性，从而具有更高的可靠性。

本发明中，在执行所述业务的各子业务过程中，所述环境调度单元释放未使用的处理资源，如此，能有效地节约能源。

本发明中，所述环境调度单元根据资源的使用情况及所述所需资源的使用时间片，分配所述所需资源，减少了GPP平台的操作***任务调度的额外开销，如此，有效地提高了处理效率。

附图说明

图1为基于GPP的实现集中式基带处理池功能的***架构示意图；

图2为本发明资源调度方法流程示意图；

图3为本发明实施例二PUSCH划分出的子业务示意图；

图4为本发明实施例二各处理核间动态共享处理资源示意图；

图5为本发明资源调度装置结构示意图；

图6为本发明资源调度***结构示意图。

具体实施方式

下面结合附图及具体实施例对本发明再作进一步详细的说明。

图1为基于GPP的实现集中式基带处理池功能的***架构示意图，如图1所示，一个完整的基于GPP的实现集中式基带处理池功能的***包括：应用子***、平台资源、硬件资源、底层资源、以及模块资源；其中，平台资源为GPP平台，平台资源和硬件资源共同组成整个***赖以构建的软硬件开发平台，这部分的资源随着***使用的GPP平台的不同而改变，比如：不同的CPU等；包含操作***的底层资源封装了软硬件开发平台的全部硬件资源和大部分软件资源；应用子***和模块资源是整个***的主要组成部分，应用子***可根据不同的平台资源、***需求而改变，且可混合多种不同的空口标准，模块资源可以在不同的平台资源间平滑移植。在图1中，同一资源层次中，位置在上的资源单元对位置在下的资源单元具有依赖关系，具体地讲，应用子***对模块资源具有依赖关系，应用子***还对底层资源具有依赖关系，模块资源对底层资源具有依赖关系，底层资源对硬件资源具有依赖关系。由于GPP在处理实时信号时需要更高的处理效率，传统的基于操作***自动分配核资源的处理方式影响了处理效率，基于此，本发明资源调度方法，如图2所示，包括以下步骤：

步骤200：设置业务调度单元及环境调度单元；

这里，在实际应用时，本步骤的具体实现是指将整体实时信号处理软件中实现调度的调度逻辑分成业务调度逻辑和环境调度逻辑。

步骤201：将要执行的业务划分为一个以上子业务，在执行所述业务的各子业务过程中，当需要使用相应资源时，所述业务调度单元通知所述环境调度单元分配所需资源。

这里，所述将要执行的业务划分为一个以上子业务，具体包括：

将所述业务划分为一个以上能独立运行的子业务；

确定各子业务所需的参数信息；

确定各子业务之间的关联关系。

其中，所述将所述业务划分为一个以上能独立运行的子业务，具体为：

依据划分出的子业务之间的耦合相关性小的策略，将所述业务划分为一个以上能独立运行的子业务。进一步地，在划分时，依据的策略还可以包括：功能单一且处理复杂度适度。

所述参数信息包括：配置信息和输入输出的接口信息。

在执行所述业务的各子业务之前，该方法还可以进一步包括：

根据各子业务的启动条件及处理时延，确定环境调度单元的触发机制；

相应的，所述业务调度单元根据确定的环境调度单元的触发机制通知所述环境调度单元分配所述所需资源。

该方法还可以进一步包括：

在执行所述业务的各子业务过程中，所述业务调度单元与模块资源的算法模块进行接口适配，完成各子业务处理。

这里，所述业务调度单元与模块资源的算法模块进行接口适配是指：所述业务调度单元完成某一空口制式的算法接口的适配。

在分配所述所需资源时，该方法还可以进一步包括：

所述环境调度单元根据资源的使用情况及所述所需资源的使用时间片，分配所述所需资源。

该方法还可以进一步包括：

在执行所述业务的各子业务过程中，所述环境调度单元根据确定的维护机制，实时维护各处理资源的任务队列。

其中，所述处理资源是指已被各子业务使用的资源。

所述环境调度单元实时维护各处理资源的任务队列，包括：

当各处理资源出现执行各子业务的时间超时或通信故障的异常时，所述环境调度单元进行处理；这里，所述环境调度单元如何处理各处理资源出现的执行时间超时或通信故障的具体实现为本领域技术人员惯用技术手段，不再赘述。

该方法还可以进一步包括：

在执行所述业务的各子业务过程中，所述环境调度单元释放未使用的处理资源。比如：将未使用的处理核进行降频节能处理等；这里，释放未使用的处理资源的具体实现本领域技术人员惯用技术手段，不再赘述。

下面结合实施例对本发明再作进一步详细的描述。

实施例一

本实施例以长期演进(LTE，Long Term Evolution)***为例，描述实现本发明资源调度方法的准备工作，准备工作主要包括以下步骤：

步骤a：将业务划分为一个以上能独立运行的子业务；

在本实施例中，是将基带处理物理层信号的处理流程划分为一个以上能独立运行的子业务；

这里，在划分时，以划分出的子业务之间耦合相关性小、功能单一、处理复杂度适当为准则。

步骤b：确定各子业务所需的参数信息，并将划分的各子业务分别封装成能独立运行的业务调度实例；

这里，所述参数信息包括：配置信息和输入输出的接口信息。

步骤c：确定各业务调度实例之间的关联关系；

具体地，画出数据在各业务调度实例间的处理流图、以及各业务调度实例之间的相互协作关系。

步骤d：根据各业务调度实例触发启动的条件和各业务调度实例的处理时延，确定环境调度单元的触发机制；

这里，举个例子来说，根据各业务调度实例触发启动的条件和各业务调度实例的处理时延，确定环境调度单元的触发机制为：当某个业务调度实例触发启动的条件满足后，触发环境调度单元。

步骤e：确定环境调度单元的环境调度实现及维护机制；

这里，确定的环境调度单元的环境调度实现机制为：环境调度单元根据当前各处理核正在执行的业务调度实例和各处理核待执行的业务调度实例，判断当前处理的子业务下发的目标核，将当前处理的子业务分配给可以及时完成相关处理的核执行。

确定的维护机制为：实时维护各处理核的任务队列，处理下发的各业务调度实例执行时间片超时或通信故障等异常处理，从而保证环境调度单元的健壮性。

步骤f：确定环境调度单元的节能机制；

具体地，将部分未使用的处理核进行降频节能处理。

实施例二

为了更好地说明实施例一中实现本发明资源调度方法的准备工作，本实施例以LTE的上行处理流程为例进行描述；其中，LTE的上行处理流程是演进型节点B(eNB，EvolvedNode B)物理层处理的主要部分。

首先，描述子业务的划分、以及各子业务调度触发机制的确定。

LTE的上行处理流程可包括：前端处理、物理随机接入信道(PRACH，Physical Random Access Channel)处理、SRS处理、信道估计、符号(Symbol)处理、以及比特(Bit)处理。其中，前端处理及PRACH处理可认为与用户设备(UE，User Equipment)配置无关，而SRS处理、信道估计、Symbol处理、以及Bit处理均与UE配置直接相关，UE调度的数量决定了这些处理模块的处理负载。因此，在划分子业务时，可以以处理的信道对象为粒度进行划分，每类不同的信道还可进一步划分子业务。下面以物理上行共享信道(PUSCH，Physical Uplink Shared Channel)为例，详细描述信道划分子业务的方式。图3为PUSCH划分出的子业务示意图；如图3所示，划分出的子业务包括：前端抽样级处理子业务、Symbol级处理子业务、以及Bit级处理子业务。其中，前端抽样级处理子业务的处理包括降采样和傅立叶变换(FFT，Fourier Transform)等操作，这部分操作与当前子帧的UE配置无关，因此可按照天线进行均分，单任务处理降采样、每个FFT模块处理2个天线。前端抽样级处理子业务的待处理数据为天线口数据，处理后的数据为FFT操作后的结果，调度触发机制为：单正交频分复用(OFDM，Orthogonal Frequency Division Multiplexing)符号完整接收。对于PUSCH，Symbol级处理子业务的处理主要包括：信道估计、解调、离散傅里叶反变换(IDFT，Inverse Discrete Fourier Transform)、频域均衡等操作，处理目标是多组UE配置资源块(RB，Resource Block)组；Symbol级处理子业务的处理复杂度与处理的RB块大小和块数量近似线性相关。因此可按照RB组为粒度进行划分；Symbol级处理子业务的待处理数据为某单个UE分配的RB资源块，处理后的数据为单UE数据的解调后的结果。调度触发机制为：单子帧的多个OFDM符号已被处理完毕，且具备各UE在当前子帧的调度配置信息。Bit级操作子业务的处理包括：解扰码、解速率匹配、信道译码等操作，处理复杂度与编码块的大小及码块数量直接相关。由于按照UE承载的传输块大小、以及当前信道的信噪比(SNR，Signal Noise Ratio)可动态预测出每个UE的处理延时，因此以编码块(CB，Code Block)为处理单位粒度设计子业务。Bit级处理子业务的待处理数据为单UE的单个编码块的解调后信息，处理后的数据为译码后的结果。

估算各子业务的处理时延，其中，各子业务的处理时延如下：

表1前端抽样级处理子业务的处理时延

PUSCH(us)	2天线	4天线
			前端抽样级处理	94	191

表2Symbol级处理子业务的处理时延

Symbol级处理(us)	20RB	40RB	80RB	100RB
					信道估计	18	34.8	58	71
频域均衡处理	10.5	18	34	42
					IDFT	6.7	12.1	21.4	26.7
解调	4.1	9	16	19
					总计	39.3	73.9	129.4	158.8

表3Bit级处理子业务的处理时延

Bit级处理(us)

5504bits

6144bits

Turbo码译码	132(8Iter)	150(8Iter)
			HARQ合并	11.4	12
Total	143.4	162

其次，描述环境调度单元的设置及功能，具体包括：时序关系排布、接口数据传输等。

在实际应用时，设置的环境调度单元对应的环境调度逻辑可以绑定在主核上，负责环境调度中查询业务处理状态和分配处理任务的功能，其他核主要处理业务的各子业务。在设置时，环境调度单元能根据每个子业务的关键信息如：处理天线数、目标频域数据RB大小、CB块大小、以及SNR等可以估算出每个子业务的处理时延，因此可合理地分配给处理子业务的核处理。

使用环境调度和业务调度分离的方法可以在各处理核间动态共享处理资源，如图4所示，假设环境调度逻辑承载在主核上，称为调度核，即为环境调度单元，具有环境调度中查询子业务处理状态和分配处理子业务的功能，其它两个核负责处理所述业务的各子业务，称为业务核1和业务核2。在子帧开始后，在执行前端抽样级处理子业务的过程中，环境调度单元即承载在主核上的环境调度逻辑收到业务调度单元的指示后，分配业务核1处理天线0(Ant0)和天线1(Ant1)的前端抽样级处理子业务，分配业务核2处理天线2(Ant2)和天线4(Ant4)的前端抽样级处理子业务，处理时延为94us，业务核1和业务核2处理完成后，向环境调度单元返回前端抽样级处理子业务完成的指示；在执行Symbol级处理子业务的过程中，环境调度单元收到业务调度单元的指示后，分配业务核1处理UE1的20RB及UE3的20RB，分配业务核2处理UE2的40RB，处理时延为72us，业务核1和业务核2处理完成后，向环境调度单元返回Symbol级处理子业务完成的指示。在执行Bit级处理子业务的过程中，环境调度单元收到业务调度单元的指示后，分配业务核1处理UE1的相关CB，分配业务核2处理UE3的相关CB，同时分配业务核1核和业务核2分别处理UE2的部分相关CB，换句话说，由业务核1和业务核2共同处理UE2的相关CB，处理时延为800us，业务核1和业务核2处理完成后，向环境调度单元返回Bit级处理子业务完成的指示，从而实现各子业务的处理。其中，在图4中，表示与UE1相关的处理，表示与UE2相关的处理，表示与UE3相关的处理。

从上面的描述可以得出，基于本发明的方法，在图1所示的基于GPP的实现集中式基带处理池功能的***中，调度模块包含了业务调度单元及环境调度单元；调度模块的功能主要包括：资源分配以及接口适配；其中，从分配资源和数字处理的角度来看，业务调度单元的处理只与具体的空口制式相关，而不涉及分配各处理核的处理任务，而环境调度单元负责分配各处理核的处理任务，以满足空口协议规定的实时性要求。这样划分后，使得业务调度单元更加专注于某种空口制式的算法接口适配和处理流程，从而脱离了具体的服务器，而环境调度单元则需要考虑各子业务调度处理流程的处理时间和分配原则等，环境调度单元在处理时，需要考虑平台资源的主频、处理器内核、以及所选操作***等。其中，所述服务器是指业务调度单元所在的服务器，也就是说，所述服务器为承载业务调度单元对应的业务调度逻辑的硬件设备。

具体地讲，业务调度单元与模块资源接口，它完成的主要功能包括：算法模块接口的适配、以及向环境调度单元申请资源分配给算法模块使用。业务调度单元不允许直接使用硬件资源，也不允许使用栈以外的任何存储器空间。在业务调度单元需要使用硬件资源和/或存储器空间时，需要通过环境调度单元进行分配并通过环境调度单元才能使用。

因此，在实际应用时，业务调度单元对应的业务调度逻辑可以在任意GPP平台和操作***上使用，它仅和所实现的上层应用绑定。不同的空口协议比如全球移动通讯***(GSM，Global System of Mobile communication)、TD-SCDMA、TDD-LTE等，可以有不同的业务调度逻辑，这些业务调度逻辑可以在同一个业务环境中混合执行，当新的处理器或操作***出现时，这些业务调度逻辑可以以lib库的形式移植到新的GPP平台上而不作修改。

具体而言，业务调度单元可能完成的功能包括：事件管理、配置管理、业务数据统计、以及数据异常保护。其中，所述事件管理包括：算法实例的创建和释放、事件比如测量事件的启动和终止、算法实例的调用等；所述配置管理包括：在不同的信令或后台配置下的各算法实例配置消息的分发、和所执行业务的配置管理；所述业务数据统计包括：需上报的业务数据统计比如流量等、以及，某些需要做二次统计的业务数据的二次统计等；所述数据异常保护包括各类数据异常的异常处理，例如数据不配套等。

环境调度单元与完成业务所需的所有资源接口，它完成的主要功能包括：平台资源、底层资源和硬件资源的接口适配、以及对资源包括时间片的分配和管理。环境调度单元不关心上层业务的具体应用，仅关心资源的使用情况。由于这种特性，环境调度单元需要控制所有的资源，因此需要提供特殊的应用程序编程接口(API，Application Programming Interface)供上层应用即业务调度单元和算法模块使用，以便业务调度单元和/或算法模块可以在需要的时候申请包括外部加速器和时间片在内的资源，同时由环境调度单元分配这些资源。

从原理上来说，环境调度单元的功能相当于手动实现操作***在业务管理方面的部分功能，这主要是基于无线协议物理层对算法处理的特殊实时性要求的考虑，比如：尽量减少任务切换、以及单核单线程绑定等特殊需求。

具体而言，环境调度单元可能完成的功能包括：消息管理、时序管理、任务管理、通信管理、时序和通信异常保护、以及运行状态统计。其中，所述消息管理包括管理消息队列，以驱动子业务的执行；所述时序管理包括：对各种资源的使用时序以及业务调度单元申请分配的时间片；所述任务管理包括：对各子业务、中断、信号量、以及邮箱等与操作***相关的配置和管理；所述通信管理包括：CPU内部各核、CPU之间、以及跨服务器的各类通信的配置和管理；所述时序和通信异常保护包括：各类时序和通信的异常保护，比如子业务的执行时间片超出、数据传输丢失等；所述运行状态统计包括：对CPU运行的各类数据进行统计，具体包括消息触发次数、成功次数、以及失败次数等，以便调试需要。

综上所述，本发明提供的资源调度方法，业务调度和资源调度进行了分离，由环境调度单元统一分配资源，如此，在处理实时信号时，能有效地实现资源的动态调度。并且，由于业务调度和资源调度进行了分离，因此，环境调度逻辑可以不局限于同一个空口协议，举个例子来说，LTE和TD-SCDMA的业务可以在同一个业务环境中混合执行，换句话说，在LTE和TD-SCDMA的业务处理过程中，当LTE或TD-SCDMA承载的用户量不足时，环境调度逻辑可以将资源调度给用户量大的业务来使用。

另外，在划分子业务时，依据划分出的子业务之间的耦合相关性小的策略，将所述业务划分为一个以能独立运行的上子业务，如此，能使环境调度单元更加灵活地调度资源。

除此以外，在执行所述业务的各子业务过程中，所述环境调度单元根据确定的维护机制，实时维护各处理资源的任务队列，而业务调度单元不关心通信机制，也不关心各处理核之间的相互处理时序关系，仅调用算法模块，即仅完成某一空口制式的算法接口的适配和信号处理的优化，如此，提高了代码的可重用性，使得软件升级简单化，从而有利于***的平滑演进。

环境调度单元实时维护各处理资源的任务队列，如此，最大化地保证了***异常的可恢复性，从而具有更高的可靠性。

由环境调度单元分配资源，减少了GPP平台的操作***任务调度的额外开销，如此，有效地提高了处理效率。

为实现上述方法，本发明还提供了一种资源调度装置，如图5所示，该装置包括业务调度单元51、以及环境调度单元52；其中，

业务调度单元51，用于在执行划分为一个以上子业务的业务的各子业务过程中，当需要使用相应资源时，通知环境调度单元52；

环境调度单元52，用于收到业务调度单元51的通知后，分配所需资源。

其中，所述环境调度单元52，具体用于：在分配所述所需资源时，根据资源的使用情况及所述所需资源的使用时间片，分配所述所需资源。

所述环境调度单元52，还用于在执行所述业务的各子业务过程中，根据确定的维护机制，实时维护各处理资源的任务队列。

所述环境调度单元52，还用于在执行所述业务的各子业务过程中，释放未使用的处理资源。

基于上述资源调度装置，本发明还提供了一种资源调度***，如图6所示，该***包括：应用子***61、平台资源62、硬件资源63、底层资源64、以及模块资源65；其中，应用方案61包括调度资源装置661，所述资源调度装置包括：业务调度单元6611、以及环境调度单元6612；其中，

业务调度单元6611，用于在执行划分成一个以上子业务的业务的各子业务过程中，当需要使用相应资源时，通知环境调度单元6612；

环境调度单元6612，用于收到业务调度单元的通知后，分配所需资源。

其中，平台资源62、硬件资源63、底层资源64、以及模块资源65的功能与图1中相应的各模块的功能相同，这里不再赘述。这里，所述平台资源62为GPP平台。

所述环境调度单元6612，具体用于：在分配所述所需资源时，根据资源的使用情况及所述所需资源的使用时间片，分配所述所需资源。

所述环境调度单元6612，还用于在执行所述业务的各子业务过程中，根据确定的维护机制，实时维护各处理资源的任务队列。

所述环境调度单元6612，还用于在执行所述业务的各子业务过程中，释放未使用的处理资源。

所述模块资源65进一步包括算法模块651，所述业务调度单元6611，还用于在执行所述业务的各子业务过程中，所述业务调度单元与算法模块651进行接口适配，完成各子业务处理。

所述平台资源62、所述硬件资源63、以及所述底层资源64组成资源调度***的资源，用于被所述环境调度单元6612控制。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (12)

1.一种资源调度方法，其特征在于，设置业务调度单元及环境调度单元；该方法还包括：

将要执行的业务划分为一个以上子业务，在执行所述业务的各子业务过程中，当需要使用相应资源时，所述业务调度单元通知所述环境调度单元分配所需资源。

2.根据权利要求1所述的方法，其特征在于，所述将要执行的业务划分为一个以上子业务，包括：

将所述业务划分为一个以上能独立运行的子业务；

确定各子业务所需的参数信息；

确定各子业务之间的关联关系。

3.根据权利要求2所述的方法，其特征在于，所述将所述业务划分为一个以上能独立运行的子业务，为：

依据划分出的子业务之间的耦合相关性小的策略，将所述业务划分为一个以上能独立运行的子业务。

4.根据权利要求1、2或3所述的方法，其特征在于，在执行所述业务的各子业务之前，该方法还包括：

根据各子业务的启动条件及处理时延，确定环境调度单元的触发机制；

相应的，所述业务调度单元根据确定的环境调度单元的触发机制通知所述环境调度单元分配所述所需资源。

5.根据权利要求1、2或3所述的方法，其特征在于，该方法还包括：

在执行所述业务的各子业务过程中，所述业务调度单元与模块资源的算法模块进行接口适配，完成各子业务处理。

6.根据权利要求1、2或3所述的方法，其特征在于，在分配所述所需资源时，该方法进一步包括：

所述环境调度单元根据资源的使用情况及所述所需资源的使用时间片，分配所述所需资源。

7.一种资源调度装置，其特征在于，该装置包括：业务调度单元、以及环境调度单元；其中，

业务调度单元，用于在执行划分为一个以上子业务的业务的各子业务过程中，当需要使用相应资源时，通知环境调度单元；

环境调度单元，用于收到业务调度单元的通知后，分配所需资源。

8.根据权利要求7所述的装置，其特征在于，所述环境调度单元，具体用于：在分配所述所需资源时，根据资源的使用情况及所述所需资源的使用时间片，分配所述所需资源。

9.一种资源调度***，该***包括：应用子***、平台资源、硬件资源、底层资源、以及模块资源；其特征在于，所述应用子***进一步包括资源调度装置，所述资源调度装置包括：业务调度单元、以及环境调度单元；其中，

业务调度单元，用于在执行划分为一个以上子业务的业务的各子业务过程中，当需要使用相应资源时，通知环境调度单元；

环境调度单元，用于收到业务调度单元的通知后，分配所需资源。

10.根据权利要求9所述的***，其特征在于，所述平台资源、所述硬件资源、以及所述底层资源组成资源调度***的资源，用于被所述环境调度单元控制。

11.根据权利要求9或10所述的***，其特征在于，所述环境调度单元，具体用于：在分配所述所需资源时，根据资源的使用情况及所述所需资源的使用时间片，分配所述所需资源。

12.根据利要求9或10所述的***，其特征在于，所述模块资源进一步包括算法模块；所述业务调度单元，还用于在执行所述业务的各子业务过程中，所述业务调度单元与所述算法模块进行接口适配，完成各子业务处理。