具体实施方式
为使本发明的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本发明作进一步详细的说明。
现有技术中,轻负荷小区会在RESOURCE STATUS Update中提供“可用的负荷容量”,表示该轻负荷小区还有多少资源可用,但是,对于该轻负荷小区的多个邻区来说,并不明确这些资源中的多少能够分给自己使用。
因此,本专利发明人创造性地提出了源基站在资源状态请求消息中携带自己的负荷信息,这样,目标基站就可以综合多个源基站的负荷信息,将所述“可用的负荷容量”分配给所述多个源基站,并将分配结果携带在资源状态更新信息中;因此,源基站就可以根据接收到的分配结果,确定后续的负荷均衡过程,例如,判断是否触发与相应被请求小区的负荷均衡参数协商过程等等,因而能够减少负荷均衡震荡调整。
参照图3,示出了本发明一种负荷信息的交互方法实施例1的流程图,具体可以包括:
步骤301、源基站对其下属的各个小区进行周期性的负荷信息统计;
步骤302、判断是否有小区触发负荷均衡过程,若是,则源基站向目标基站发送该小区的负荷信息;
在实际中,可以在发送至目标基站的资源状态请求(RESOURCESTATUS REQUEST)消息中,携带所述源基站中小区的负荷信息。
当然,本领域技术人员还可以根据需要,在其它消息中携带所述源基站中小区的负荷信息,本发明对所述源基站中小区的负荷信息的具体发送方式不加以限制。
步骤303、目标基站根据所接收的多个源基站中小区的负荷信息,针对该目标基站的可用负荷资源,分别为各个源基站中小区分配预留资源;
步骤304、将所述预留资源发送至源基站。
在具体实现中,可以在发送至源基站的资源状态更新(RESOURCESTATUS Update)消息中携带所述预留资源。当然,本领域技术人员还可以根据需要,在其它消息中携带所述预留资源,本发明对具体的发送方式不加以限制。
通常的负荷均衡过程一般可以包括负荷信息的交互,参数协商过程,参数的更新等环节;而对于源基站来说,在其接收到来自目标基站的针对源基站中各小区的预留资源后,由于所述预留资源表示为负荷均衡的调整而抢占目标基站的许可资源,因而,它也可作为确定后续的负荷均衡过程的依据,例如,判断是否触发与目标基站的负荷均衡参数协商过程。
因此,在本发明的一种优选实施例中,所述方法还可以包括:
依据源基站中小区的负荷信息,以及,目标基站针对该小区的预留资源,确定后续的负荷均衡过程。
在具体实现中,源基站可以依据自己的负荷信息设置一个门限TH,如果所述预留资源高于该门限TH,则触发后续的负荷均衡参数协商过程;否则放弃与相应目标基站的负荷均衡操作;因而,本发明的预留资源能够避免不恰当的负荷均衡,进而减少负荷均衡震荡调整。
为详细说明源基站小区与目标基站小区之间的负荷信息交互过程,参照图4,示出了本发明一种负荷信息的交互方法实施例2的流程图,具体可以包括:
步骤401、源基站对其下属的各个小区进行周期性的负荷信息统计;
本发明可以适用于LTE***中,或者,LTE与UMTS(通用移动通信***,Universal Mobile Telecommunications System)***中,用以减少LTE***内部,或者,LTE与UMTS***之间的负荷均衡震荡调整;以下主要以图1所示的一种LTE***内的负荷均衡过程为例对本发明进行说明。
在实际中,所述统计的负荷信息可以包括如下在TS36.423协议中定义的信息:
无线资源状态(Radio Resource Status)
TNL的负荷指示(S1TNL Load Indicator)
硬件负荷指示(Hardware Load Indicator)
复合可用的容量(Composite Available Capacity Group)
步骤402、针对源基站中的小区,判断是否触发负荷均衡过程,若是,则该小区为请求小区;
在具体实现中,小区可根据仿真参考以及运营商的需求来设置一个负荷门限值;若当前小区的剩余负荷低于该负荷门限值,表明当前的负荷过高,则触发后续的负荷均衡过程;若当前小区的剩余负荷不低于(高于或等于)该负荷门限值,则不进行负荷均衡过程。
例如,对于图1中eNB1中的小区A,其设置的负荷门限值分别为上行30、下行30;而统计的复合可用的容量中包含的上行的可用容量值(AvailableCapacity Value)为15,下行的可用容量值为5,均低于负荷门限值,故触发小区A的负荷均衡过程。
步骤403、针对源基站中的请求小区,选择与其交互的被请求小区,并确定该被请求小区所在的目标基站;
在实际中,可直接选择所有的邻区作为被请求小区;此时,小区A直接选择邻区B和D进行交互。
在本发明的一种优选实施例中,为减少交互次数,还可以根据统计的负荷信息,来选择所述被请求小区,具体可以包括如下情形:
情形一、
在此种情形下,本步骤的执行过程可以为:针对源基站中的请求小区,如果其在某邻区方向上的负荷分布高于第一负荷门限,则选择该邻区为与其交互的被请求小区。
其中,所述负荷分布主要指请求小区在邻区方向上的边缘用户数量,所述统计负荷分布的步骤主要可以包括:
步骤A1、针对源基站中的小区,获取其用户分布方向;
在实际中,可根据小区内边缘用户上报的测量报告,将信号强度最强,或者超过第三负荷门限的邻区方向,作为用户分布方向。
例如,UE(User Experience)向基站上报的测量报告中包含了本小区在多个邻区方向上的信号强度,则可以认为,UE离信号强度最强的邻区最近,也就是UE处于该邻区的方向上。
或者,可采用定位方式获取用户的位置,根据该位置计算用户到邻区的距离,并将距离最近的邻区方向,作为用户分布方向。
例如,对于某些具有GPS(全球定位***,Global Positioning System)或者OTDOA(观测到达时间差,Observed Time Difference of Arrival)等定位功能的UE,可以获得其地理位置,并且,在具有详细的地理位置的情况,可以计算UE到邻区的距离,则距离最近的邻区方向即是用户分布方向。
步骤A2、统计所述用户分布方向上的边缘用户数量。
情形二、
此时,本步骤选择被请求小区的过程可以为,针对源基站中的请求小区,如果其在某邻区方向上的用户流向高于第二负荷门限,则选择该邻区为与其交互的被请求小区;这里,所述用户流向主要指一段时间内本小区与邻区的切换次数。
在实际中,可以采用上述情形的任一种或者组合,本发明对此不加以限制。
例如,根据前一段时间内小区A用户的测量报告中发现,小区B为最强邻区的UE数量超过第三负荷门限,则选择小区B为负荷信息交互的小区。而小区D则远远低于该第三负荷门限,表明在小区D方向上用户数可能过少,那么调整与小区D相关的参数也不能有效的降低小区A的呼叫请求率以及转移相关的负荷到小区D,因此不选择小区D进行负荷信息的交互。
步骤404、源基站向目标基站发送资源状态请求消息,其中,该资源状态请求消息中可以包括该源基站中请求小区的负荷信息;
例如,在所述统计的负荷信息中包括无线资源状态、TNL的负荷指示、硬件负荷指示和复合可用的容量时,所述发送的源基站中请求小区的负荷信息是一个可选项,也即,它可以包括所述统计的负荷信息中的一项或者几项。
可以理解,除了源基站的负荷信息外,该资源状态请求消息中还可以包括TS36.423协议中定义的其它相关信息要素;例如,可以在所述资源状态请求消息中携带所述被请求小区的信息,其中所述被请求小区的信息可以是被请求小区ID的列表等等;又如,还可以所述资源状态请求消息中携带负荷信息的统计周期等,本发明对此不加以限制。
例如,eNB1向eNB2发送的资源状态请求消息中,可以包括被请求小区B,以及,小区A的负荷信息:上行的可用容量值(Available Capacity Value)为15,下行的可用容量值为5,等等。
步骤405、目标基站在接收到资源状态请求消息后,根据相应多个源基站中请求小区的负荷信息,针对该目标基站中被请求小区的可用负荷资源,分别为每个请求小区分配预留资源;
在实际中,目标基站在接收到资源状态请求消息后,如果可以为源基站提供负荷消息,则回复资源状态响应消息(Resource Status Request),并完成负荷测量,其中,得到的负荷测量结果中可以包括该目标基站中被请求小区的可用负荷资源。
本发明可以提供如下预留资源的分配方案:
方案一、
由于被请求小区的可用负荷资源可以作为共享资源,那么,OAM(操作与维护,Operation and Maintenance)***可以定义该共享资源的分配方式,具体可以包括:
1、平均分配方式;
此时,所述步骤405的执行过程可以为,将所述该目标基站中被请求小区的可用负荷资源的全部或部分,平均分配到每个请求小区。
在实际中,该目标基站中被请求小区可根据自己的负荷均衡算法,确定其用于分配的可用负荷资源的部分。
例如,eNB2得到的负荷测量结果中包括有小区B的可用负荷资源:当前的上行可用容量值为50,下行为40;
并且,eNB2根据来自eNB3的资源状态请求消息,得知小区C的负荷信息:上行的可用容量值为15,下行的可用容量值为5;eNB2的其他邻区没有向其发起过负荷信息的请求;
因此,eNB2可以综合eNB1和eNB3的信息,为请求小区A和C分配预留资源,所述分配过程可以包括:
首先,针对被请求小区B的可用负荷资源,将其中的20%用于预防其他情况发生而预留,也即用于分配的是可用负荷资源的80%;
然后,将所述80%分配给小区A和C;其中,所述分配过程可以是小区A和C平均分配,这样,小区A和C的预留资源分别为小区B可用负荷资源的40%和40%。
在实际中,如果接收到百分比形式的预留资源,源基站中请求小区可以利用以下公式计算其数值形式:目标基站中被请求小区的容量等级*可用容量值*预留资源;
例如,目标基站中被请求小区是GSM,其容量为20,上行可用容量为15%,其针对请求小区的预留资源为50%,则该请求小区计算得到实际的预留资源:20*0.15*0.5=1.5。
上面对百分比形式的预留资源进行了描述;可以理解,该预留资源还可以是一个定义0-100的数值,其定义与可用容量值IE(信息元素,InformationElement)相同,本领域技术人员可以根据需要,选用所述两种形式的一种,本发明对此不加以限制。
2、加权分配方式。
此时,所述步骤405具体可以包括:
子步骤B1、针对每个请求小区,根据其负荷信息设置加权系数;
子步骤B2、依据各自的加权系数,将所述该目标基站中被请求小区的可用负荷资源的全部或部分,分配至相应的请求小区。
例如,小区A存在两个重负荷的邻区B、C,小区B、C的负荷分别是90,80,负荷门限均为是70,则小区B、C的目标转移负荷分别可以计算为20,10,因而,可以设置小区B、C的加权系数之比为20:10=2:1,因而,小区B、C的加权系数分别为1/3,2/3;假设小区A可以预留的可用资源是15,则可以根据各自的加权系数计算得到小区B、C的预留资源:10,5。
方案二、
本方案主要依据被请求小区在每个请求小区方向上的负荷信息,来为该请求小区分配预留资源,此时,所述步骤405具体可以包括:
子步骤C1、针对该目标基站中被请求小区,统计其在每个请求小区方向上的负荷分布和/或用户流向信息;
子步骤C2、根据所述负荷分布和/或用户流向信息,为相应的请求小区分配预留资源。
这里,所述负荷分布主要指被请求小区在每个请求小区方向上的边缘用户数量,所述用户流向主要指一段时间内被请求小区与每个请求小区的切换次数。
例如,被请求小区A统计发现,在前一段时间内,与请求小区B存在着大量的用户切换;因为本来的切换就很多了,如果两个小区进行均衡,可能效果不明显,则可以不预留专门用于负荷均衡的资源,也即,设置请求小区B的预留资源为0,或者预留少数资源以限制对方发起负荷均衡。
又如,以被请求小区A为例,其负荷也超过一定的负荷,且发现其用户主要分布都在请求小区B方向上,则不能与请求小区B进行负荷均衡操作,故设置为B的预留资源0。
以上对预留资源的几种分配方案进行了详细介绍,所述几种方案能够使源基站间接地获得更多小区的信息,从而可以减少震荡调整;可以理解,本领域技术人员可以根据需要联合使用所述几种方案,或者,使用其中任一种方案,本发明对此不加以限制。
当然,除了上述几种方案,本领域技术人员还可以采用其它预留资源的分配方案,例如,随机为每个请求小区分配预留资源等,本发明对此不加以限制。
步骤406、目标基站向源基站发送资源状态更新信息,其中,所述资源状态更新信息中可以携带针对所述源基站中请求小区的预留资源。
可以理解,在实际中,所述资源状态更新信息中还可以携带有该目标基站中被请求小区的可用负荷资源等其它负荷测量结果信息,本发明对此不加以限制。
为使本领域技术人员更好地理解本发明,以下提供本发明在不同应用场景下的实施例:
实施例3、
本实施例涉及LTE***中的负荷均衡过程,参照图5示出了小区的拓扑结构,其中,深颜色的小区表示重负荷小区,浅颜色的小区表示轻负荷小区,且轻负荷小区中的数值表示下行可用容量值;
本实施例以小区1的负荷均衡过程为例进行介绍;为了简便,各个基站都是全向基站,因此每个基站中只有一个小区,小区的编号与基站编号相同。
步骤D1、基站1对小区1进行周期性的负荷信息统计;
步骤D2、判断小区1是否触发负荷均衡过程;
例如,统计得到的上行可用容量值为15,下行可用容量值为20,分别低于门限各自的门限30,则基站1触发负荷均衡过程。
步骤D3、针对小区1,选择与其交互的被请求小区,并确定该被请求小区所在的目标基站;
假设基站1根据此前一段时间内边缘用户的测量报告,发现小区2,3,4,5,6,7为最信号强度最强的UE数目分别超过门限,则选择向小区2,3,4,5,6,7交互负荷信息。
步骤D4、基站1向目标基站发送资源状态请求消息,其中,该资源状态请求消息中可以包括该小区1的负荷信息;
步骤D5、目标基站在接收到资源状态请求消息后,如果可以为基站1提供负荷消息,则回复资源状态响应消息,并完成负荷测量,其中,得到的被请求小区的负荷测量结果中可以包括该目标基站中被请求小区的可用负荷资源;
步骤D6、目标基站根据来自多个源基站中请求小区的负荷信息,以及,该目标基站中被请求小区的可用负荷资源,分别为每个请求小区分配预留资源;
以目标基站7为例,由于周围邻区大多为重负荷小区且已经获得了其他基站的负荷信息,故综合其他小区的负荷信息以及基站自己的算法,为基站1的上下行方向分别预留10%的资源。
步骤D7、目标基站向源基站发送资源状态更新信息(Resource StatusUpdate),其中,所述资源状态更新信息中可以包括针对所述源基站中请求小区的预留资源;
步骤D8、基站1在接收到目标基站的资源状态更新信息后,根据其中的预留资源,判断是否触发与目标基站中相应被请求小区的负荷均衡参数协商过程。
例如,基站1发现基站3,4的预留资源满足高于门限TH,则触发后续的MLB参数协商过程;而基站5、6、7的预留门限低于门限TH,则放弃与5,6,7的均衡操作。
实施例4、
本实施例涉及LTE与UMTS***中负荷均衡过程,参照图6,宏基站为TD-SCDMA,在其覆盖范围内分别有多个LTE的家庭基站做热点的覆盖。在某个时刻HeNB2和HeNB3处于重负荷状态,需要执行符合均衡的过程,且两个家庭基站分别为混合模式;
本实施例以家庭基站HeNB2的负荷均衡过程为例进行介绍;假设各个基站都是全向基站,家庭基站HeNB2有小区2,家庭基站HeNB3有小区3,基站NodeB1有小区1
步骤E1、家庭基站HeNB2周期性地统计小区2的负荷信息;
步骤E2、判断小区2是否触发负荷均衡过程;
例如,统计信息中的上行可用容量值为5,下行可用容量值为5,分别低于门限各自的门限10,则HeNB2触发负荷均衡过程。
步骤E3、HeNB2向其邻区NodeB1发送Source Status Request,该消息中携带小区2的负荷信息,可以包括:
无线资源状态(Radio Resource Status)
TNL的负荷指示(S1TNL Load Indicator)
硬件负荷指示(Hardware Load Indicator)
复合可用的容量(Composite Available Capacity Group)
由于HeNB3也处于重负荷状态,也执行类似的过程。
步骤E4、NodeB1在接收到Resource Status Request后,如果可以为HeNB2提供负荷消息,则回复Resource Status Response,并完成负荷测量,其中,所述负荷测量结果中可以包括该小区1的可用负荷资源;
步骤E5、NodeB1根据其接收到的多个基站的负荷信息(包括HeNB2和HeNB3),以及基站自己的算法,将所述可用负荷资源分配到每个请求小区;
例如,NodeB1根据自己的均衡算法,为LTE家庭基站的资源预留不超过20%,故最终为HeNB2和HeNB3的上下行方向分别预留10%的资源。
步骤E6、NodeB1向源基站发送资源状态更新信息,其中,所述资源状态更新信息中可以包括针对所述源基站中请求小区的预留资源;
步骤E7、家庭基站HeNB2在接收到目标基站的Resource Status Update后,根据其中的预留资源,判断是否触发与NodeB1中小区1的负荷均衡参数协商过程。
例如,HeNB2计算上行方向NodeB1为其的预留资源的计算公式为:小区容量等级*上行可用容量值*上行预留资源,通过该公式计算获得的结果高于门限TH,则触发后续的负荷均衡操作过程。
实施例5、
本实施例主要描述高速公路上的应用场景,参照图7,在地图中分别有9个基站,其编号为2-10,在四环上由于车流过高,导致小区覆盖范围内负荷的提高;
本实施例以基站4的负荷均衡过程为例进行介绍,且假设各个基站都是全向基站。
步骤F1、基站4进行周期性的负荷信息统计;
步骤F2、判断基站4是否触发负荷均衡过程;
例如,基站4统计得到的负荷信息中,上行可用容量值为15,下行可用容量值为20,分别低于门限各自的门限30,则基站4触发负荷均衡过程。
步骤F3、针对基站4,选择与其交互的目标基站;
假设基站4统计一段时间内的UE的测量报告,发现用户主要分布在基站3和8的方向上,而基站6,7方向上的用户较少,并且基站中发生的切换主要在基站3,8的边缘,则判断负荷主要在基站3,8之间进行流动,因此选择与基站3,8进行负荷信息的交互。
步骤F4、基站4向目标基站发送资源状态请求消息,其中,该资源状态请求消息中可以包括基站4自己的负荷信息;
例如,基站4向其邻基站3,8分别发送Resource Status Request消息,且该消息中携带自己的负荷信息,具体可以包括:无线资源状态、TNL的负荷指示、硬件负荷指示和复合可用的容量中的一项或几项。
步骤F5、目标基站在接收到资源状态请求消息后,如果可以为基站4提供负荷消息,则回复资源状态响应消息,并完成负荷测量,其中,得到的被请求小区的负荷测量结果中可以包括该目标基站中被请求小区的可用负荷资源;
步骤F6、根据来自多个源基站中请求小区的负荷信息,以及,该目标基站中被请求小区的可用负荷资源,分别为每个请求小区分配预留资源;
步骤F7、目标基站向源基站发送资源状态更新信息,其中,所述资源状态更新信息中可以包括针对所述源基站中请求小区的预留资源;
以目标基站8为例,由于其负荷也超过一定的负荷,且发现其用户主要分布以及主要的切换区域都在基站10和基站4方向上,且这两个基站也都处于重负荷状态,则不能进行负荷均衡操作,因而,在Resource Status Update消息中携带的用于负荷均衡的可用资源信息,设置为0,表示不与基站4进行负荷均衡操作。
步骤F8、基站4在接收到目标基站的Resource Status Update后,根据其中的预留资源,判断是否触发与目标基站中相应被请求小区的负荷均衡参数协商过程。
相应地,基站4在接收到基站8的Resource Status Update后,发现其中用于负荷均衡的可用资源信息为0,则放弃与基站8的负荷过程;同理也放弃了与基站3的负荷均衡过程。
需要说明的是,本实施例中可根据仿真参考以及运营商的需求,将上述用到的门限(如第一负荷门限,第二负荷门限,第三负荷门限,门限TH等)设置在均衡算法的内部,所述门限无须标准化或者依赖交互设置。
另外,由于本发明的交互方法不仅可以适用于SON范围的负荷均衡自动优化中,也可以适用于LTE及其后续演进网络(如LTE+)中传统意义上的负荷均衡手动优化中;因而可以作为一种简便易行的,对于LTE及其后续演进网络(如LTE+)的负荷均衡参数协调的方案来实施。
参考图8,示出了本发明一种基站实施例1的结构图,所述基站可以作为负荷信息交互的源基站,具体可以包括:
统计模块801,用于对本基站下属的各个小区进行周期性的负荷信息统计;
判断模块802,用于判断是否有小区触发负荷均衡过程;
发送模块803,用于在有小区触发负荷均衡过程时,向目标基站发送资源状态请求消息,其中,该资源状态请求消息中包括本基站中小区的负荷信息。
在实际中,所述统计的负荷信息可以包括无线资源状态、TNL的负荷指示、硬件负荷指示和复合可用的容量;而所述发送的源基站中请求小区的负荷信息通常为所述统计的负荷信息中的一项或者几项。
在具体实现中,可以在发送至目标基站的资源状态请求消息中,携带所述源基站中小区的负荷信息;此时,所述发送模块803,则可用于在有小区触发负荷均衡过程时,向目标基站发送资源状态请求消息,其中,该资源状态请求消息中可以包括该源基站中小区的负荷信息。
为详细说明源基站小区与目标基站小区之间的负荷信息交互过程,可以在所述判断模块802中设计如下子模块:
请求小区判断子模块G1,用于针对本基站中的小区,判断是否触发负荷均衡过程,若是,则该小区为请求小区;
选择子模块G2,用于针对本基站中的请求小区,选择与其交互的被请求小区,并确定该被请求小区所在的目标基站;
而此时,所述发送模块G3,则可用于在有小区触发负荷均衡过程时,向目标基站发送本基站中相应请求小区的负荷信息。
通常情况下,所述选择子模块G2可直接选择其所有的邻区作为被请求小区;但是,在某些情况下,与某一邻区交互可能起不到应有的效果,反而增加交互次数。
例如,根据前一段时间内小区A用户的测量报告中发现,小区D为最强邻区的UE数量特别少,表明在小区D方向上用户数可能过少,那么调整与小区D相关的参数也不能有效的降低小区A的呼叫请求率以及转移相关的负荷到小区D,因此不选择小区D进行负荷信息的交互。
因此,在本发明的一种优选实施例中,为减少交互次数,所述选择子模块G2还可以根据统计的负荷信息,来选择所述被请求小区:
例如,所述选择子模块G2,可用于针对本基站中的请求小区,如果其在某邻区方向上的负荷分布高于第一负荷门限,则选择该邻区为与其交互的被请求小区。
为获取所述负荷分布信息,可以在所述统计模块801中设计如下子模块:
获取子模块H1,用于针对源基站中的小区,获取其用户分布方向;
数量统计子模块H2,用于统计所述用户分布方向上的边缘用户数量。
在实际中,所述获取子模块H1,可用于根据小区内边缘用户上报的测量报告,将信号强度最强,或者超过第三负荷门限的邻区方向,作为用户分布方向;
或者,用于采用定位方式获取用户的位置,根据该位置计算用户到邻区的距离,并将距离最近的邻区方向,作为用户分布方向。
又如,所述选择子模块G2,还可用于针对源基站中的请求小区,如果其在某邻区方向上的用户流向高于第二负荷门限,则选择该邻区为与其交互的被请求小区。
在本发明的一种优选实施例中,还可以在所述基站中设置一个接收模块,用于接收来自目标基站的针对源基站中各小区的预留资源。
通常的负荷均衡过程一般可以包括负荷信息的交互,参数协商过程,参数的更新等环节;而对于源基站来说,由于所述预留资源表示为负荷均衡的调整而抢占目标基站的许可资源,因而,它也可作为确定后续的负荷均衡过程的依据,例如,判断是否触发与目标基站的负荷均衡参数协商过程。
因此,在本发明的一种优选实施例中,所述基站还可以包括:
确定模块,用于依据本基站中小区的负荷信息及目标基站针对该小区的预留资源,确定后续的负荷均衡过程。
在具体实现中,源基站可以依据自己的负荷信息设置一个门限TH,如果所述预留资源高于该门限TH,则触发后续的负荷均衡参数协商过程;否则放弃与相应目标基站的负荷均衡操作;因而,本发明的预留资源能够避免不恰当的负荷均衡,进而减少负荷均衡震荡调整。
对于基站实施例1而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
参考图9,示出了本发明一种基站实施例2的结构图,所述基站可以作为负荷信息交互的目标基站,具体可以包括:
分配模块901,用于根据所接收的多个源基站中小区的负荷信息,针对该目标基站的可用负荷资源,分别为各个源基站中小区分配预留资源;
发送模块902,用于将所述预留资源发送至源基站。
在具体实现中,还可以在基站中设置一个接收模块,可用于接收源基站中请求小区的负荷信息,以及,该目标基站中被请求小区的信息。
此时,所述分配模块901,则可用于根据相应多个源基站中请求小区的负荷信息,针对本基站中被请求小区的可用负荷资源,分别为每个请求小区分配预留资源。
本发明可以提供如下分配模块901的结构设计方案:
设计方案一、
由于被请求小区的可用负荷资源可以作为共享资源,那么,OAM***可以定义该共享资源的分配方式。
例如,对应于平均分配方式,所述分配模块901,可用于将所述该目标基站中被请求小区的可用负荷资源的全部或部分,平均分配到每个请求小区;
或者,对应于加权分配方式,所述分配模块901,则可用于针对每个请求小区,根据其负荷信息设置加权系数,并依据各自的加权系数,将所述该目标基站中被请求小区的可用负荷资源的全部或部分,分配至相应的请求小区。
在具体实现中,可以在基站中设计一个专门的模块,用于根据自己的负荷均衡算法,确定其用于分配的可用负荷资源的部分。
设计方案二、
本方案主要依据被请求小区在每个请求小区方向上的负荷信息,来为该请求小区分配预留资源,相应地,所述分配模块901可以包括:
信息统计子模块K1,针对该目标基站中被请求小区,统计其在每个请求小区方向上的负荷分布和/或用户流向信息;
预留资源分配子模块K2,用于根据所述负荷分布和/或用户流向信息,为相应的请求小区分配预留资源。
对于基站实施例2而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本发明还公开了一种既可用作负荷信息交互源基站,又可用作负荷信息交互目标基站的基站实施例3,参照图10,具体可以包括
统计模块1001,用于对本基站下属的各个小区进行周期性的负荷信息统计;
判断模块1002,用于判断是否有小区触发负荷均衡过程;
第一发送模块1003,用于在有小区触发负荷均衡过程时,向目标基站发送本基站中小区的负荷信息;
分配模块1004,用于根据所接收的多个源基站中小区的负荷信息,针对该目标基站的可用负荷资源,分别为各个源基站中小区分配预留资源;
第二发送模块1005,用于将所述预留资源发送至源基站。
在本发明的一种优选实施例中,还可以在所述基站中设置一个接收模块,用于接收来自目标基站的针对源基站中各小区的预留资源。
在本基站作为源基站时,由于所述预留资源表示为负荷均衡的调整而抢占目标基站的许可资源,因而,它也可作为确定后续的负荷均衡过程的依据,例如,判断是否触发与目标基站的负荷均衡参数协商过程等等。
因此,在本发明的一种优选实施例中,所述基站还可以包括:
确定模块,用于依据本基站中小区的负荷信息及目标基站针对该小区的预留资源,确定后续的负荷均衡过程。
在具体实现中,基站可以依据自己的负荷信息设置一个门限TH,如果所述预留资源高于该门限TH,则触发后续的负荷均衡参数协商过程;否则放弃与相应目标基站的负荷均衡操作;因而,本发明的预留资源能够避免不恰当的负荷均衡,进而减少负荷均衡震荡调整。
对于基站实施例3而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本发明可以适用于LTE***中,或者,LTE与UMTS***中,用以减少LTE***内部,或者,LTE与UMTS***之间的负荷均衡震荡调整。
以上对本发明所提供的一种基站通信方法及一种基站,进行了详细介绍,本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。