一种协作资源分配的方法和装置
技术领域
本发明涉及通信技术领域,尤其涉及一种协作资源分配的方法和装置。
背景技术
协作多点(Coordinated MultiPoint,简称CoMP)传输技术可以利用多个小区为同一个用户设备进行服务,例如共同为这个用户设备发送或接收数据信号(联合发送/联合接收),也可以通过多点联合的调度或波束赋型等手段降低这个用户设备收到的干扰(协同调度/协同波束赋型),还可以通过选择最合适的一个传输点来为用户设备提供服务(动态传输点选择)。协作多点技术由于主要是通过消除邻小区干扰或将邻小区干扰转化为有用信号带来增益,因此最适用于系统中受到邻小区干扰最为严重的边缘用户。
这项技术需要在多个传输点间协调资源,例如要求多个传输点同时发送/接收信号(对应于联合传输/接收技术),或者要求一个传输点传输信号,另一些传输点不传输信号(对应于协作调度技术)。现有技术中,资源的协调有两大类方案。第一类方案为集中控制节点负责协调多个传输点间的资源分配问题。集中控制节点能控制多个传输点的资源分配,因此能够有效协调多个传输点间的资源分配,降低协作失败的概率。但这种方案需要引入一个集中控制节点来控制多个小区的资源分配过程,会在原有网络中引入一个新的节点,增加网络成本。并且这种集中控制的方式也不利于系统的可靠性。如果集中控制节点出现问题,就会导致多个被管辖的传输点不能做协作传输。考虑到集中式控制的这些问题,另一类方式是不引入集中控制节点,采用分布式的方式进行资源协调。这类方案的特点是各个传输点独立进行资源分配,然后向邻区请求进行资源协调。但传输点完成资源分配后,向邻区请求需要协调的资源有可能会与邻区已经分配的资源相冲突,导致协作失败,降低协作成功率。
发明内容
本发明的目的是提供一种协作资源分配的方法和装置,以解决现有的分布式资源协调方式可能导致协作失败,降低协作成功率的问题。
本发明的目的是通过以下技术方案实现的:
一种协作资源分配的方法,包括:
步骤1、确定本小区用于协作多点调度的资源;
步骤2、向本小区的各邻区发送协作资源请求消息,以向所述各邻区请求所述本小区用于协作多点调度的资源;
步骤3、接收所述各邻区发送的协作资源反馈消息,所述协作资源反馈消息用于指示是否接受对所述本小区用于协作多点调度的资源的请求;
如果所述各邻区均接受对所述本小区用于协作多点调度的资源的请求,执行步骤4、为终端分配协作资源,并将协作资源的分配结果通知给参与所述终端协作多点传输的邻区,所述协作资源为所述本小区用于协作多点调度的全部或部分资源。
可选的,该方法还包括:
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,返回所述步骤1。
可选的,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,返回所述步骤1,包括:
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,在预定时间间隔后返回步骤1;或者,
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,在下一个调度周期的开始时刻或下一个调度周期的开始时刻之后返回步骤1。
可选的,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,返回所述步骤1,包括:
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,且向所述各邻区请求所述本小区用于协作多点调度的资源的次数未达到预定次数,在预定时间间隔后返回步骤1;
该方法还包括:
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,且向所述各邻区请求所述本小区用于协作多点调度的资源的次数达到预定次数,为终端分配协作资源,并将协作资源的分配结果通知给参与所述终端协作多点传输的邻区,所述协作资源为所述本小区进行协作多点调度所需的全部或部分资源,所述参与所述终端协作多点传输的邻区为接受对所述本小区用于协作多点调度的资源的请求的部分或全部邻区。
可选的,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,返回所述步骤1,包括:
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,且定时器未超时,在预定时间间隔后返回步骤1,所述定时器是本调度周期开始时刻启动的,或初次确定本小区用于协作多点调度的资源时启动的;
该方法还包括:
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,且本调度周期开始时刻启动的定时器超时,为终端分配协作资源,并将协作资源的分配结果通知给参与所述终端协作多点传输的邻区,所述协作资源为所述本小区进行协作多点调度所需的全部或部分资源,所述参与所述终端协作多点传输的邻区为接受对所述本小区用于协作多点调度的资源的请求的部分或全部邻区。
可选的,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,返回所述步骤1,包括:
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,本调度周期内向所述各邻区请求所述本小区用于协作多点调度的资源的次数未达到预定次数,且本调度周期开始时刻启动的定时器未超时,在预定时间间隔后返回步骤1;
该方法还包括:
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,且满足以下至少一个条件:本调度周期内向所述各邻区请求所述本小区用于协作多点调度的资源的次数达到预定次数,本调度周期开始时刻启动的定时器超时;为终端分配协作资源,并将协作资源的分配结果通知给参与所述终端协作多点传输的邻区,所述协作资源为所述本小区进行协作多点调度所需的全部或部分资源,所述参与所述终端协作多点传输的邻区为接受对所述本小区用于协作多点调度的资源的请求的部分或全部邻区。
基于上述任意方法实施例,可选的,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,确定本小区用于协作多点调度的资源,包括:
根据所述各邻区发送的协作资源反馈消息中携带的信息,确定本小区用于协作多点调度的资源,所述协作资源反馈消息中携带发送端确定的用于协作多点调度的资源的信息和/或发送端的邻区请求且发送端接受的用于协作多点调度的资源的信息。
一种协作资源分配的方法,包括:
接收协作资源请求消息,所述协作资源请求消息的发送端通过所述协作资源请求消息向各邻区请求所述发送端的小区用于协作多点调度的资源;
判断是否接受对发送端的小区用于协作多点调度的资源的请求;
向所述发送端发送协作资源反馈消息,以指示是否接受对所述发送端小区用于协作多点调度的资源的请求。
可选的,所述协作资源反馈消息中携带本小区确定的用于协作多点调度的资源的信息和/或本小区的邻区请求且本小区接受的用于协作多点调度的资源的信息。
基于与方法同样的发明构思,本发明实施例还提供一种协作资源分配的装置,包括:
协作资源确定模块,用于确定本小区用于协作多点调度的资源;
资源协商模块,用于向本小区的各邻区发送协作资源请求消息,以向所述各邻区请求所述本小区用于协作多点调度的资源;接收所述各邻区发送的协作资源反馈消息,所述协作资源反馈消息用于指示是否接受对所述本小区用于协作多点调度的资源的请求;
协作资源分配模块,用于如果所述各邻区均接受对所述本小区用于协作多点调度的资源的请求,为终端分配协作资源,并将协作资源的分配结果通知给参与所述终端协作多点传输的邻区,所述协作资源为所述本小区用于协作多点调度的全部或部分资源。
可选的,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,所述协作资源确定模块再次确定本小区用于协作多点调度的资源。
可选的,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,所述协作资源确定模块用于在预定时间间隔后返回步骤1,再次确定本小区用于协作多点调度的资源;或者,
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,所述协作资源确定模块用于在下一个调度周期的开始时刻或下一个调度周期的开始时刻之后,再次确定本小区用于协作多点调度的资源。
可选的,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,且向所述各邻区请求所述本小区用于协作多点调度的资源的次数未达到预定次数,所述协作资源确定模块用于在预定时间间隔后,再次确定本小区用于协作多点调度的资源;
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,且向所述各邻区请求所述本小区用于协作多点调度的资源的次数达到预定次数,所述协作资源分配模块用于为终端分配协作资源,并将协作资源的分配结果通知给参与所述终端协作多点传输的邻区,所述协作资源为所述本小区用于协作多点调度的全部或部分资源,所述参与所述终端协作多点传输的邻区为接受对所述本小区用于协作多点调度的资源的请求的部分或全部邻区。
可选的,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,且定时器未超时,所述协作资源确定模块用于在预定时间间隔后,再次确定本小区用于协作多点调度的资源,所述定时器是本调度周期开始时刻启动的,或初次确定本小区用于协作多点调度的资源时启动的;
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,且本调度周期开始时刻启动的定时器超时,所述协作资源分配模块用于为终端分配协作资源,并将协作资源的分配结果通知给参与所述终端协作多点传输的邻区,所述协作资源为所述本小区用于协作多点调度的全部或部分资源,所述参与所述终端协作多点传输的邻区为接受对所述本小区用于协作多点调度的资源的请求的部分或全部邻区。
可选的,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,本调度周期内向所述各邻区请求所述本小区用于协作多点调度的资源的次数未达到预定次数,且本调度周期开始时刻启动的定时器未超时,所述协作资源确定模块用于在预定时间间隔后,再次确定本小区用于协作多点调度的资源;
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,且满足以下至少一个条件:本调度周期内向所述各邻区请求所述本小区用于协作多点调度的资源的次数达到预定次数,本调度周期开始时刻启动的定时器超时,所述协作资源分配模块用于为终端分配协作资源,并将协作资源的分配结果通知给参与所述终端协作多点传输的邻区,所述协作资源为所述本小区用于协作多点调度的全部或部分资源,所述参与所述终端协作多点传输的邻区为接受对所述本小区用于协作多点调度的资源的请求的部分或全部邻区。
基于上述任意装置实施例,可选的,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,所述协作资源确定模块用于:
根据所述各邻区发送的协作资源反馈消息中携带的信息,确定本小区用于协作多点调度的资源,所述协作资源反馈消息中携带发送端确定的用于协作多点调度的资源的信息和/或发送端的邻区请求且发送端接受的用于协作多点调度的资源的信息。
基于与方法同样的发明构思,本发明实施例还提供一种协作资源分配的装置,包括:
请求消息接收模块,用于接收协作资源请求消息,所述协作资源请求消息的发送端通过所述协作资源请求消息向各邻区请求所述发送端的小区用于协作多点调度的资源;
判断模块,用于判断是否接受对发送端的小区用于协作多点调度的资源的请求;
反馈消息发送模块,用于向所述发送端发送协作资源反馈消息,以指示是否接受对所述发送端小区用于协作多点调度的资源的请求。
可选的,所述协作资源反馈消息中携带本小区确定的用于协作多点调度的资源的信息和/或本小区的邻区请求且本小区接受的用于协作多点调度的资源的信息。
本发明实施例提供的技术方案,在协作资源调度之前,先向邻区请求本小区确定的用于进行多点协作调度的资源,即向邻区请求进行资源协调,从而可以尽量避免协作资源冲突的发生,提高协作成功率。
附图说明
图1为本发明一个实施例提供的方法流程图;
图2为本发明另一个实施例提供的方法流程图;
图3为本发明实施例提供的小区分布示意图;
图4为本发明实施例提供的协作资源协商及分配过程的信令图;
图5为本发明实施例提供的协作资源协商过程的信令图;
图6为本发明实施例提供的协作资源分配过程的信令图;
图7为本发明实施例提供的协作资源示意图;
图8为本发明一个实施例提供的装置示意图;
图9为本发明另一个实施例提供的装置示意图;
图10为本发明实施例提供的基站结构示意图。
具体实施方式
下面将结合附图,对本发明实施例提供的技术方案进行详细说明。
本发明实施例提供的协作资源分配的方法在资源请求发送端的实现方式如图1所示,具体包括如下操作:
步骤1、确定本小区用于协作多点调度的资源。
以小区A为例,确定本小区(即小区A)用于协作多点调度的资源(时频资源)。
步骤2、向本小区的各邻区发送协作资源请求消息,以向各邻区请求本小区用于协作多点调度的资源。
仍以小区A为例,向小区A的各邻区发送协作资源请求消息。
步骤3、接收各邻区发送的协作资源反馈消息,协作资源反馈消息用于指示是否接受对本小区用于协作多点调度的资源的请求。
仍以小区A为例,协作资源反馈消息用于指示该反馈消息的发送端是否接受对小区A用于协作多点调度的资源的请求。
如果各邻区均接受对本小区用于协作多点调度的资源的请求,执行步骤4、为终端分配协作资源,并将协作资源的分配结果通知给参与该终端协作多点传输的邻区,协作资源为本小区用于协作多点调度的全部或部分资源。
仍以小区A为例,假设需要为终端1和终端2分配协作资源,且小区A与小区B协作为终端1提供服务,小区A与小区C协作为终端2提供服务,则将为终端1分配协作资源的分配结果通知给小区B,将为终端2分配协作资源的分配结果通知给小区C。
本发明实施例提供的技术方案,在协作资源调度之前,先向邻区请求本小区确定的用于进行多点协作调度的资源,即向邻区请求进行资源协调,从而可以尽量避免协作资源冲突的发生,提高协作成功率。
另外,本发明实施例提供的技术方案尤其适用于分布式的资源协调场景,能够在不引入集中控制节点的情况下尽量避免协作资源冲突的发生,提高协作成功率。
另外,本发明实施例提供的技术方案,由于可以提前进行资源协商,就可以为协作终端和非协作终端在不同时刻调度,尽量充分利用时域资源。
本发明实施例提供的方案,如果有邻区不接受对本小区用于协作多点调度的资源的请求,可以返回上述步骤1,也可以暂停协作多点调度,还可以与接受本小区请求的邻区进行协作多点调度。
其中,如果有邻区不接受对本小区用于协作多点调度的资源的请求,返回上述步骤1,其具体实现方式有多种。下面例举其中几种:
返回上述步骤1的实现方式一、如果有邻区不接受对本小区用于协作多点调度的资源的请求,在预定时间间隔后返回步骤1。
本发明实施例中,预定时间间隔根据实际需要设置。
本发明实施例中,协作多点调度可以周期性进行,那么,预定时间间隔的设置需要保证返回步骤1时,本调度周期还未结束。
返回上述步骤1的实现方式二、如果有邻区不接受对本小区用于协作多点调度的资源的请求,在下一个调度周期的开始时刻或下一个调度周期的开始时刻之后返回步骤1。
本实现方式适用于周期性进行协作多点调度的场景。
返回上述步骤1的实现方式三、如果有邻区不接受对本小区用于协作多点调度的资源的请求,且向各邻区请求本小区用于协作多点调度的资源的次数未达到预定次数,在预定时间间隔后返回步骤1。
本发明实施例中,预定次数根据实际需要设置。
另外,本发明实施例提供的技术方案可以适用于周期性协作多点调度,相应的,从本调度周期的第一次确定本小区用于协作多点调度的资源开始计数。
另外,针对周期性协作多点调度,即使所有邻区均接受对本小区用户协作多点调度的资源的请求,在下一个调度周期的开始时刻或之后,也返回步骤1。
本发明实施例提供的技术方案也可以适用于非周期性协作多点调度,相应的,根据实际应用场景确定何时开始计数。例如,在小区启动后第一次确定本小区用于非周期性协作多点调度的资源开始计数。
本发明实施例中,可以在有邻区不接受对本小区用于协作多点调度的资源的请求后,判断向各邻区请求本小区用于协作多点调度的资源的次数是否达到预定次数,也可以在有邻区不接受对本小区用于协作多点调度的资源的请求之前,判断向各邻区请求本小区用于协作多点调度的资源的次数是否达到预定次数,本发明对此不作限定。
相应的,如果有邻区不接受对本小区用于协作多点调度的资源的请求,且向各邻区请求本小区用于协作多点调度的资源的次数达到预定次数,可以暂停协作多点调度(例如在本调度周期内停止协作多点调度),也可以为终端分配协作资源,并将协作资源的分配结果通知给参与该终端协作多点传输的邻区,协作资源为本小区用于协作多点调度的全部或部分资源,参与上述终端协作多点传输的邻区为接受对本小区用于协作多点调度的资源的请求的部分或全部邻区。
例如,小区A向邻区B、C、D、E和F发送协作资源请求消息,其中,小区B和小区C接受了小区A的资源请求,但小区D、E和F拒绝了小区A的资源请求,并且,本调度周期内小区A请求协作多点调度的资源的次数达到预定次数。假设有终端1和终端2需要进行协作多点传输,且终端1需要小区A和小区B协作,终端2需要小区A和小区D协作,那么,基于上述情况,小区A仅为终端1进行协作资源调度。
返回上述步骤1的实现方式四、如果有邻区不接受对本小区用于协作多点调度的资源的请求,且定时器未超时,在预定时间间隔后返回步骤1。
本发明实施例提供的技术方案可以适用于周期性协作多点调度,相应的,定时器是本调度周期开始时刻或开始时刻之后启动的。
本发明实施例提供的技术方案也可以适用于非周期性协作多点调度,相应的,定时器是初次确定本小区用于协作多点调度的资源时或之后启动的。
本发明实施例中,定时器的启动时刻根据实际需要设置,定时器的计时时长根据需要设置。
相应的,如果有邻区不接受对本小区用于协作多点调度的资源的请求,且本调度周期开始时刻启动的定时器超时,可以暂停协作多点调度(例如在本调度周期内停止协作多点调度),也可以为终端分配协作资源,并将协作资源的分配结果通知给参与该终端协作多点传输的邻区,协作资源为所述本小区用于协作多点调度的全部或部分资源,参与该终端协作多点传输的邻区为接受对本小区用于协作多点调度的资源的请求的部分或全部邻区。
返回上述步骤1的实现方式五、如果有邻区不接受对本小区用于协作多点调度的资源的请求,本调度周期内向各邻区请求本小区用于协作多点调度的资源的次数未达到预定次数,且本调度周期开始时刻启动的定时器未超时,在预定时间间隔后返回步骤1。
其具体实现方式可以参照上述实现方式三和实现方式四,此处不再赘述。
相应的,如果有邻区不接受对本小区用于协作多点调度的资源的请求,且满足以下至少一个条件,本调度周期内向各邻区请求本小区用于协作多点调度的资源的次数达到预定次数,本调度周期开始时刻启动的定时器超时;可以暂停协作多点调度(例如在本调度周期内停止协作多点调度),也可以为终端分配协作资源,并将协作资源的分配结果通知给参与该终端协作多点传输的邻区,协作资源为本小区用于协作多点调度的全部或部分资源,参与该终端协作多点传输的邻区为接受对本小区用于协作多点调度的资源的请求的部分或全部邻区。
上述提到,本发明实施例适用于周期性多点协作调度。这种场景下,优选的,各小区的调度周期相同,且调度周期的开始时刻相同。
基于上述任意方法实施例,其中,如果有邻区不接受对本小区用于协作多点调度的资源的请求,再次确定本小区用于协作多点调度的资源的实现方式可以是:根据各邻区发送的协作资源反馈消息中携带的信息,确定本小区用于协作多点调度的资源,协作资源反馈消息中携带发送端确定的用于协作多点调度的资源的信息和/或发送端的邻区请求且发送端接受的用于协作多点调度的资源的信息。
其中,同一个资源,占用它的小区越少,则发生冲突的可能性越小。
本发明实施例提供的协作资源分配的方法在资源请求接收端的实现方式如图2所示,具体包括如下操作:
步骤200、接收协作资源请求消息,该协作资源请求消息的发送端通过该协作资源请求消息向各邻区请求该发送端的小区用于协作多点调度的资源。
以小区A为例,小区B是小区A的邻区,小区B接收小区A发送的协作资源请求消息,小区A通过该消息向其各邻区请求小区A用于协作多点调度的资源。
步骤210、判断是否接受对发送端的小区用于协作多点调度的资源的请求。
步骤220、向上述发送端发送协作资源反馈消息,以指示是否接受对该发送端小区用于协作多点调度的资源的请求。
本发明实施例提供的技术方案,在协作资源调度之前,先向邻区请求本小区确定的用于进行多点协作调度的资源,即向邻区请求进行资源协调,从而可以尽量避免协作资源冲突的发生,提高协作成功率。
另外,本发明实施例提供的技术方案尤其适用于分布式的资源协调场景,能够在不引入集中控制节点的情况下尽量避免协作资源冲突的发生,提高协作成功率。
另外,本发明实施例提供的技术方案,由于可以提前进行资源协商,就可以为协作终端和非协作终端在不同时刻调度,尽量充分利用时域资源。
优选的,上述协作资源反馈消息中携带本小区确定的用于协作多点调度的资源的信息和/或本小区的邻区请求且本小区接受的用于协作多点调度的资源的信息。
其中,判断是否接受对发送端的小区用于协作多点调度的资源的请求的实现方式有多种,具体根据不同的协作方式确定。
对于联合传输(Joint Transmission,JT)或联合接收(Joint Reception,JR)调度,所有邻区请求的资源与小区自身分配的资源都不能相同。假设小区A向小区B请求资源R,如果小区B确定本小区用于协作多点调度的资源也是R,则判断不接受小区A的请求;或者小区B已经接受小区C对资源R的请求,则判断不接受小区A的请求。
对于协作调度(Coordinated Scheduling,CS)调度,所有邻区请求的资源都不能与小区自身分配的资源相同,但邻区请求的资源之间可以相同。假设小区A向小区B请求资源R,如果小区B确定本小区用于协作多点调度的资源也是R,则判断不接受小区A的请求;如果小区B确定本小区用于协作多点调度的资源不是R,但已经接受小区C对资源R的请求,则判断接受小区A的请求。
另外,如果接受请求,还可以进行记录。例如记录请求的资源的信息和发送请求的小区的信息。相应的,在接收到协作资源请求消息后,可以查找是否有该发送端请求资源的记录,如果有,则删除相应的记录。
下面将结合具体应用场景,对本发明实施例提供的技术方案进行详细描述。
以图3所示的小区分布为例,本实施例中,一个基站即为一个小区,各小区按数字进行编号,每个小区都与相邻的小区互为邻区。例如,小区1与小区2~7相邻,小区2~7是小区1的邻区,同理,小区1、3、7、8、9、10是小区2的邻区。
各小区间协作资源分配过程采用分布式架构,各个小区的地位相同,周期性独立进行协作资源分配,每个调度周期可以分为两个过程:协作资源协商过程,协作资源分配过程,如图4所示,这两个过程周期性重复进行。重复的周期根据实际需要设置,可以但不仅限于由运营、管理和维护(Operations,Administration&Maintenance,OAM)系统配置。具体的,OAM系统会为每个小区配置一个相同的协作资源协商过程开始时刻(即为调度周期的开始时刻),在协作资源协商过程结束后,小区进入协作资源分配过程。一种情况下,各小区的协作资源分配过程各自独立,并不相互协商或由OAM配置相同的开始时刻;另一种情况下,各小区的协作资源分配过程的开始时刻相同,通过相互协商确定或由OAM配置。各小区的协作资源分配过程在下一次协作资源协商过程开始前结束。
以小区1和小区2之间的协作资源协商过程为例,如图5所示,其中:
在一个调度周期的协作资源协商过程中,小区1确定本小区用于协作多点调度的资源,然后向小区2(当然还向其他邻区)发送协作资源请求消息;小区2接收到该协作资源请求消息后,判断是否接受请求,并通过协作资源反馈消息指示是否接受请求,可选的,协作资源反馈消息中携带小区2确定的用于协作多点调度的资源的信息(例如资源标识)和/或小区2的邻区请求且小区2接受的用于协作多点调度的资源的信息(例如资源标识),进一步的,协作资源反馈消息中还携带这些资源对应的小区的标识信息;如果小区2拒绝小区1的资源请求,则小区1在预定时间间隔后重新确定本小区用于协作多点调度的资源,尝试其他协作资源,并重新发送协作资源请求消息,直至所有邻区均接受其资源请求,或达到预定次数或定时器超时。
仍以小区1和小区2为例,协作资源协商过程之后,小区1进入协作资源分配过程,如图6所示,其中:
首先小区1会在第一步确定的协作资源集合内,进一步确定本次协作资源分配需要使用的具体协作资源,并将这些资源信息通过“协作资源分配结果”消息发送给小区2。小区2收到后,就知道在之前为小区1划分的协作资源区域中,有哪些资源被小区1实际分配,剩下的资源位置如果没有其他小区使用,则可用于小区2自己的非协作资源分配过程。
小区1会周期性地进行协作资源分配过程,并将结果发送给其他协作小区。同理,小区2也会周期性地进行自己的协作资源分配过程。这里还需要注意的是,小区1向不同小区发送的协作资源分配结果可能不同。例如小区1在协作资源内为用户设备(UserEquipment,简称UE)1和UE 2分配了协作资源,其中UE 1需要与小区2协作,UE 2需要与小区3协作。则小区1仅会将UE 1占用的协作资源分配结果发给小区2,将UE 2占用的协作资源分配结果发给小区3。
上面描述了本发明中CoMP资源分配的大致流程,下面将更为详细地描述这一过程,还是分为“协作资源协商过程”与“协作资源分配过程”两部分进行描述。
协作资源协商过程
这里首先需要明确什么是协作资源。一个小区的协作资源包括时域资源和频域资源两个维度,如图7所示,一个小区协作资源被划分为了9份,其中时域和频域各被划分为了3部分。需要说明的是,这里时域上的划分并不一定是指将一段连续时间划分为连续的3份,还可以是例如将无线帧按照模3的结果进行划分,或者将子帧轮流分给这三个时域资源集合。同理,上述的频域资源划分也不一定是将一段连续频域资源分为连续的3份,也可以采用其他划分方式。
每个小区对协作资源的划分方式都是相同的,这可以通过OAM系统来为各个小区配置。
明确了协作资源划分方式后,接下来还需要确定小区如何挑选协作资源。
假设OAM系统将协作资源划分为9份,分别是R1~R9,并将这一划分通知给了各个小区。当OAM配置的协作资源协商过程开始时刻到达后,各个小区就可以开始确定自己要占用的协作资源了。由于刚开始各个小区都没有其他小区确定协作资源的情况,因此此时各个小区可以采用随机确定一个协作资源。这里假设小区1通过随机确定的方法选择了协作资源R1。
之后小区1会将这一选择结果通过“协作资源请求”消息发送给所有邻区,例如图3所示的邻区2~7。这些邻区收到请求消息后,会判断能否接受这一请求。具体的判断方法要区分CoMP调度方式:
JT或JR调度
对于JT或JR调度,所有邻区请求的资源与小区自身分配的资源都互相不能相同。例如小区1向小区2请求占用协作资源R1。如果小区2自己想要占用的协作资源也是R1,则这次请求不能成功。或者小区2自己想要占用的资源不是R1,但是之前有小区2的其他邻区请求R1,并且小区2已经接受这一请求,则此次小区1的请求同样不能成功。只有当小区2自己想要占用的协作资源不是R1,并且之前小区2已经接受的邻区请求中也不包含R1,则小区2会向小区1反馈成功。小区2在向小区1反馈成功或失败的同时,还会向小区1反馈小区2已经接受的其他邻区占用的协作资源编号。例如之前小区3、8、9分别请求占用资源R2、R3、R4,其中小区2自己希望占用的资源为R2。则小区2同意小区8和小区9的请求,拒绝小区3的请求。则小区2向小区1的反馈信息中要包含小区8和小区9的小区ID,以及小区8和小区9请求的协作资源编号R3和R4。
CS调度
对于CS调度,所有邻区请求的资源都不能与小区自身分配的资源相同,但邻区请求的资源之间可以相同。还是上面的例子,假设小区1向小区2请求占用协作资源R1。如果小区2自己想要占有的协作资源也是R1,则这次请求不能成功。否则认为此次协作可以成功。最后不管协作成功与否,小区2都会向小区1反馈小区2自己想要占用的协作资源编号。
当小区1收到所有邻区的“协作资源反馈”消息后,首先检查是否所有小区都反馈成功。如果是,则小区1认为此次协作资源分配成功,可以进行第二步协作资源分配了。如果有小区反馈失败,则小区1还需要检查各个小区反馈的具体信息。
对于JT或JR调度,小区1获得的反馈信息包括邻区的协作资源占用信息,以及邻区的邻区的协作资源占用信息。由于小区1分配的协作资源要想成功,就要避免与这些小区分配相同的协作资源。因此小区1可以统计这些小区占用的各个协作资源的次数,次数越少说明这个协作资源被越少的邻区所使用,越有可能协作成功。下面还是以一个例子来说明这个情况。假设小区1收到的反馈消息内容为:
小区2反馈:成功,R1(C1),R2(C3),R3(C2),R6(C9),R7(C10),R9(C7)
小区3反馈:成功,R1(C1),R2(C3),R3(C2),R4(C4),R6(C12),R7(C10),R8(C11)
小区4反馈:失败,R1(C14),R2(C3),R3(C5),R4(C4),R5(C13),R6(C12)
小区5反馈:失败,R1(C14),R3(C5),R4(C4),R5(C16),R6(C15)
小区6反馈:失败,R1(C18),R2(C17),R3(C6),R5(C16),R9(C7)
小区7反馈:失败,R1(C18),R3(C2),R4(C19),R7(C8),R9(C7)
其中括号中的C1代表小区1。统计各个协作资源的占用次数如表1所示:
表1 JT/JR反馈信息统计结果
可以看出,其中占用R8、R9的小区最少,因此小区1下一次选择小区编号就从R8、R9种随机选择一个。
对于CS调度,小区1获得的反馈信息中包含邻区的资源分配信息。小区1要想分配成功,就要避开这些邻区分配的资源。下面还是以一个例子来说明这个过程。假设各个邻区的反馈信息如下:
小区2反馈:成功,R2(C2)
小区3反馈:失败,R1(C3)
小区4反馈:成功,R6(C4)
小区5反馈:成功,R7(C5)
小区6反馈:成功,R8(C6)
小区7反馈:成功,R5(C7)
统计各个协作资源的占用次数如表2所示:
表2 CS反馈信息统计结果
其中R3、R4、R9出现的次数为0,则小区1下一次选择小区编号就从R3、R4、R9中随机选择一个。
小区1通过上面的步骤再次确定了需要占用的资源后,就会再次向所有邻区发送“协作资源请求”消息。协作小区收到小区1发来的这一消息后,首先要做的是查找自己之前是否接受过小区1发来的协作资源请求。如果接受过,则要删除之前接受的请求,重新判断小区1新发来的协作资源请求是否能被接受。判断的方法与之前第一次发来的请求的判断方法相同,这里不再赘述。
邻区确定出能否接受小区1的请求后,会再次通过“协作资源反馈”消息把结果反馈给小区1。小区1收到后会再次按照上面描述的步骤判断是否请求的资源已经被所有邻区所接受。如果不是,小区1可能还要再重新确定协作资源。
为了防止小区1一直找不到协作资源,导致不断重复请求资源的情况,可以设定一个门限值:例如每个小区在一次协作资源协商过程中请求协作资源的次数上限。如果小区1发送协作资源请求消息的数目达到这一上限,但还不能找到所有邻区都满足条件的协作资源,则小区1停止第一步协作资源协商过程。或者还可以考虑设定一个定时器,在协作资源协商过程开始时启动。当这个定时器超时时,所有小区的协作资源协商过程都要停止,开始进行第二步协作资源分配过程。此时需要注意的是,每个小区在进行第二步协作资源分配过程时,只能与第一步中接受其协作资源的小区进行CoMP协作。
协作资源分配过程
每个小区的协作资源分配过程开始后,就会在第一步确定的协作资源集合内调度需要进行协作资源分配的UE。UE的挑选过程是现有技术,例如可以挑选位于小区边缘的UE作为协作UE。这些协作UE在协作资源内的调度也是现有技术。例如可以将这些协作UE优先在协作资源内进行调度。这里需要注意的是,每个协作UE的协作小区可能不同。例如小区1内有UE 1、UE2、UE3三个协作UE。这三个UE分别占用协作资源的一部分。假设协作资源为R1,其中UE 1占用的部分记为R1,1,UE 2占用的部分记为R1,2,UE 3占用的部分记为R1,3。这三个协作UE所需的协作小区和协作资源情况总结如表3所示:
表3小区1协作资源分配情况汇总
这样,小区1向小区2发送的“协作资源分配结果”消息中要包含UE 1的分配结果。小区1向小区3发送的“协作资源分配结果”消息中要包含UE 1和UE 2的分配结果。小区1向小区4发送的“协作资源分配结果”消息中要包含UE 3的分配结果。小区1不会向小区5、6、7发送“协作资源分配结果”消息。
小区2收到小区1发来的“协作资源分配结果”消息后,就知道要在协作资源R1,1上与小区1进行协作。
如果是JT或JR调度,每一个协作资源都是一个小区独自占用的,所以小区2可以确定R1中R1,1之外的资源是不会被其他小区占用的,因此小区2可以在R1,1之外的资源上进行本小区的调度,避免R1中未被使用的协作资源被浪费。
如果是CS调度,每一个协作资源可能被多个邻区共用。此时小区2需要确定所有共用这一资源的邻区对这部分资源的占用的并集R1,n,这个并集之外的资源同样是可以进行本小区调度的。
一般情况下,各个小区进行的协作资源调度,调度结果都有一定的生效时间,在这段生效时间内,这一调度结果都是有效的。因此各个小区都会周期性重复进行协作资源调度,也会周期性发送“协作资源分配结果”消息。
为了使各个小区进行本区调度时能得到其他邻区协作资源的分配结果,因此可以要求各个小区按照统一的周期进行协作资源分配。这样各个小区在同一时间进行协作UE的调度,并将调度结果发送给邻区。邻区在进行非协作UE的调度之前就可以获得这些协作资源的分配情况,使非协作UE能尽量充分地利用可用资源。
应当指出的是,以上仅为举例而非限定。例如,各小区的调度周期也可以不同,甚至,小区的协作资源调度也可以是非周期性的。
基于与方法同样的发明构思,本发明实施例还提供一种协作资源分配的装置,如图8所示,包括:
协作资源确定模块801,用于确定本小区用于协作多点调度的资源;
资源协商模块802,用于向本小区的各邻区发送协作资源请求消息,以向所述各邻区请求所述本小区用于协作多点调度的资源;接收所述各邻区发送的协作资源反馈消息,所述协作资源反馈消息用于指示是否接受对所述本小区用于协作多点调度的资源的请求;
协作资源分配模块803,用于如果所述各邻区均接受对所述本小区用于协作多点调度的资源的请求,为终端分配协作资源,并将协作资源的分配结果通知给参与所述终端协作多点传输的邻区,所述协作资源为所述本小区用于协作多点调度的全部或部分资源。
本发明实施例提供的技术方案,在协作资源调度之前,先向邻区请求本小区确定的用于进行多点协作调度的资源,即向邻区请求进行资源协调,从而可以尽量避免协作资源冲突的发生,提高协作成功率。
另外,本发明实施例提供的技术方案尤其适用于分布式的资源协调场景,能够在不引入集中控制节点的情况下尽量避免协作资源冲突的发生,提高协作成功率。
本发明实施例提供的装置可以但不仅限于是传输节点,具体可以包括基站、中继节点(Relay),其中的基站包括宏基站(Macro)、微基站(Micro)、微微基站(Pico)、家庭基站或称为毫微微基站(Femto)等,以及其它可能的无线接入点(AP)。
其中,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,所述协作资源确定模块再次确定本小区用于协作多点调度的资源。
其中,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,所述协作资源确定模块用于在预定时间间隔后返回步骤1,再次确定本小区用于协作多点调度的资源;或者,
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,所述协作资源确定模块用于在下一个调度周期的开始时刻或下一个调度周期的开始时刻之后,再次确定本小区用于协作多点调度的资源。
其中,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,且向所述各邻区请求所述本小区用于协作多点调度的资源的次数未达到预定次数,所述协作资源确定模块用于在预定时间间隔后,再次确定本小区用于协作多点调度的资源;
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,且向所述各邻区请求所述本小区用于协作多点调度的资源的次数达到预定次数,所述协作资源分配模块用于为终端分配协作资源,并将协作资源的分配结果通知给参与所述终端协作多点传输的邻区,所述协作资源为所述本小区用于协作多点调度的全部或部分资源,所述参与所述终端协作多点传输的邻区为接受对所述本小区用于协作多点调度的资源的请求的部分或全部邻区。
其中,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,且定时器未超时,所述协作资源确定模块用于在预定时间间隔后,再次确定本小区用于协作多点调度的资源,所述定时器是本调度周期开始时刻启动的,或初次确定本小区用于协作多点调度的资源时启动的;
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,且本调度周期开始时刻启动的定时器超时,所述协作资源分配模块用于为终端分配协作资源,并将协作资源的分配结果通知给参与所述终端协作多点传输的邻区,所述协作资源为所述本小区用于协作多点调度的全部或部分资源,所述参与所述终端协作多点传输的邻区为接受对所述本小区用于协作多点调度的资源的请求的部分或全部邻区。
其中,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,本调度周期内向所述各邻区请求所述本小区用于协作多点调度的资源的次数未达到预定次数,且本调度周期开始时刻启动的定时器未超时,所述协作资源确定模块用于在预定时间间隔后,再次确定本小区用于协作多点调度的资源;
如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,本调度周期内向所述各邻区请求所述本小区用于协作多点调度的资源的次数达到预定次数,且本调度周期开始时刻启动的定时器超时,所述协作资源分配模块用于为终端分配协作资源,并将协作资源的分配结果通知给参与所述终端协作多点传输的邻区,所述协作资源为所述本小区用于协作多点调度的全部或部分资源,所述参与所述终端协作多点传输的邻区为接受对所述本小区用于协作多点调度的资源的请求的部分或全部邻区。
基于上述任意装置实施例,其中,如果有邻区不接受对所述本小区用于协作多点调度的资源的请求,所述协作资源确定模块用于:
根据所述各邻区发送的协作资源反馈消息中携带的信息,确定本小区用于协作多点调度的资源,所述协作资源反馈消息中携带发送端确定的用于协作多点调度的资源的信息和/或发送端的邻区请求且发送端接受的用于协作多点调度的资源的信息。
基于与方法同样的发明构思,本发明实施例还提供一种协作资源分配的装置,如图9所示,包括:
请求消息接收模块901,用于接收协作资源请求消息,所述协作资源请求消息的发送端通过所述协作资源请求消息向各邻区请求所述发送端的小区用于协作多点调度的资源;
判断模块902,用于判断是否接受对发送端的小区用于协作多点调度的资源的请求;
反馈消息发送模块903,用于向所述发送端发送协作资源反馈消息,以指示是否接受对所述发送端小区用于协作多点调度的资源的请求。
本发明实施例提供的技术方案,在协作资源调度之前,先向邻区请求本小区确定的用于进行多点协作调度的资源,即向邻区请求进行资源协调,从而可以尽量避免协作资源冲突的发生,提高协作成功率。
另外,本发明实施例提供的技术方案尤其适用于分布式的资源协调场景,能够在不引入集中控制节点的情况下尽量避免协作资源冲突的发生,提高协作成功率。
其中,所述协作资源反馈消息中携带本小区确定的用于协作多点调度的资源的信息和/或本小区的邻区请求且本小区接受的用于协作多点调度的资源的信息。
基于与方法同样的发明构思,本发明实施例还提供一种基站,如图10所示,包括:
处理器1000,收发机1010,存储器1020。
其中,收发机1010用于在处理器1000的控制下接收和发送数据;
存储器1020用于保存处理器1000执行操作时所使用的数据。
一方面,处理器1000用于从存储器1020中读取程序,执行下列过程:
确定本小区用于协作多点调度的资源;
向本小区的各邻区发送协作资源请求消息,以向所述各邻区请求所述本小区用于协作多点调度的资源;接收所述各邻区发送的协作资源反馈消息,所述协作资源反馈消息用于指示是否接受对所述本小区用于协作多点调度的资源的请求;
如果所述各邻区均接受对所述本小区用于协作多点调度的资源的请求,为终端分配协作资源,并将协作资源的分配结果通知给参与所述终端协作多点传输的邻区,所述协作资源为所述本小区用于协作多点调度的全部或部分资源。
另一方面,处理器1000用于从存储器1020中读取程序,执行下列过程:
接收协作资源请求消息,所述协作资源请求消息的发送端通过所述协作资源请求消息向各邻区请求所述发送端的小区用于协作多点调度的资源;
判断是否接受对发送端的小区用于协作多点调度的资源的请求;
向所述发送端发送协作资源反馈消息,以指示是否接受对所述发送端小区用于协作多点调度的资源的请求。
其中,在图10中,总线架构可以包括任意数量的互联的总线和桥,具体由处理器1000代表的一个或多个处理器和存储器1020代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口提供接口。收发机1010可以是多个元件,即包括发送机和接收机,提供用于在传输介质上与各种其他装置通信的单元。处理器1000负责管理总线架构和通常的处理,存储器1020可以存储处理器1000在执行操作时所使用的数据。
上述本发明实施例提供的基站,其处理器的具体工作方式可以参照上述各实施例的描述,此处不再赘述。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本发明的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。