CN102098728B - 一种移动负载均衡方法 - Google Patents

Abstract

本发明公开了一种移动负载均衡MLB方法，应用于无线蜂窝移动通信系统中，以包含多个小区的小区簇为基本单位，在同一小区簇的相邻小区间实现负载均衡。具体地，小区簇中的各个小区根据自身的负载状态和相邻小区的负载状态，向相邻小区发起MLB操作，并与相邻小区进行负载转移。小区发起的MLB操作包括由轻载小区发起的主动型MLB和由严重过载小区发起的被动型MLB。小区簇中的小区可以周期性地发起多次MLB操作，在相邻小区之间渐进、平稳地实现负载均衡，解决了MLB后的小区过载问题，避免了乒乓效应的出现，提高了负载均衡收敛速度；相邻小区之间交互负载状态信息，能够节省网络信令开销，降低网络交互的负荷，提高无线资源的利用率，进而保证网络的稳定性。

Description

一种移动负载均衡方法

技术领域

本发明涉及通信技术领域，特别是涉及一种移动负载均衡方法。

背景技术

IMT-Advanced（International Mobile Telecommunications-Advanced，先进的国际移动通信）系统为超过IMT-2000能力的下一代宽带蜂窝移动通信系统，能够提供由移动网络和固定网络支持的基于包传输的移动业务。无论在技术、网络结构，还是在业务支撑和服务环境上，IMT-Advanced系统都和传统蜂窝网络有很大的不同，具体表现在：IMT-Advanced系统采用MIMO（Multiple InputMultiple Output，多输入多输出）、无线中继、小区间干扰协调和载波聚合等先进技术；为了减少传输时延，采用扁平化网络结构，如图1所示，取代了传统的集中控制模式，基站间采用协商方式进行相应的无线资源分配和切换；为了满足室内高速和绿色通信要求，采用家庭基站技术增强室内覆盖；改变网络结构和增强基站功能，提高IMT-Advanced系统的应急通信能力，实现便捷灵活的高效组网。

上述IMT-Advanced系统的新特征和技术需求使得传统无线网络规划、网络优化和网络管理方法和流程不再高效，需要使用具有学习能力的智能化网络规划优化及管理方法，例如，将SON（自组织网络，Self-Organizing Network）引入IMT-Advanced系统，以提高网络的自组织能力，简化无线网络设计和网络运维，实现网络的自配臵、自优化和自治愈，以适合下一代宽带移动通信系统的技术需求和业务需求。

在包括IMT-Advanced系统在内的无线蜂窝网络中，各小区的业务量随用户的到达呈时间和地理位置上的随机变化，导致小区负载不均匀，资源利用率低下。为解决上述问题，通常在2G/3G（2nd Generation/3rd Generation）以及 LTE（Long Term Evolution，长期演进）网络中使用MLB（Mobility Load Balancing，移动负载均衡）技术，即，两个网络或者两个系统中负载较重的一方将部分负载转移到另一方中去，达到一种负载均匀分布的状态，以提高整体网络无线资源的利用率，扩大系统容量，为用户提供多样化的服务及更好的服务质量。

在实现本发明的过程中，发明人发现现有技术至少存在如下问题：

现有的MLB技术通常只考虑选择负载最轻的小区进行负载转移，而不考虑选择其他负载水平较轻或负载水平在未来有可能变轻的小区进行MLB，浪费了小区资源，并且加重了承受负载的小区的负担，提高了其成为过载小区的可能性；而被选择进行MLB的负载最轻的小区不考虑自己的负载能力，“冒进”地接受相邻小区的负载请求，会造成本小区在MLB后出现过载现象，需要再次发生本小区的MLB过程，导致MLB的乒乓效应，浪费了系统资源。

发明内容

本发明的目的在于提供一种移动负载均衡方法，以平稳地实现MLB，为此，本发明采用如下技术方案：

一种移动负载均衡MLB方法，其特征在于，应用于包括多个小区的小区簇中，设定由所述小区簇中当前负载量最小的小区发起MLB操作并承担相邻小区转移的负载，或者由所述小区簇中当前负载量最大的小区发起MLB操作并向相邻小区转移负载，所述方法包括以下步骤：

小区簇中的各个小区测量自身的负载状态，将自身的负载状态信息发送给相邻小区，接收相邻小区的负载状态信息，将所述相邻小区的负载状态信息存储到自身的邻小区列表中；

所述小区簇中的小区检测到自身的负载状态和相邻小区的负载状态满足MLB的触发条件时，向所述相邻小区发起MLB操作，并与所述相邻小区进行负载转移；

其中，所述小区的负载状态包括轻载、中载、轻微过载和严重过载；

所述小区簇中的小区检测到自身的负载状态和相邻小区的负载状态满足MLB的触发条件，包括：

所述小区检测到自身的负载状态为轻载，且相邻小区的负载状态为轻微过载或严重过载；

或者，所述小区检测到自身的负载状态为严重过载，且相邻小区的负载状态为轻载或中载。

本发明的实施例包括以下优点，因为根据小区簇中的各个小区的负载状态发起MLB操作，并在相邻小区间进行负载转移，能够平稳地实现MLB，提高负载均衡收敛速度，并避免乒乓效应的出现，节省了网络信令开销，降低了网络交互的负荷，提高了无线资源的利用率，进行保证整个网络的稳定性。当然，实施本发明的实施例的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

图1为现有技术中的IMT-Advanced系统的架构示意图；

图2为本发明实施例中的MLB方法流程图；

图3为本发明实施例中的主动MLB操作流程图；

图4为本发明实施例中的主动MLB操作的场景示意图；

图5为本发明实施例中的被动MLB操作流程图；

图6为本发明实施例中的被动MLB操作的场景示意图。

具体实施方式

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

本发明实施例中的上层网管可以根据所管辖网络内部的人口密度、业务水平和各小区通信类型等因素，将辖区内的小区划分入不同的小区簇，并将划分结果通知给各个小区。本发明实施例中的MLB方法以包括多个小区的小区簇为基本单位，不同小区簇中的小区可以同时进行MLB操作，各个小区簇可以按照预设的MLB周期进行MLB操作，MLB周期为从开始测量小区负载到MLB结束的时间段，可以包括多个负载测量时长和一个MLB时长，其中，一个MLB周期包含的负载测量时长的个数与小区簇包含的小区的个数相同。

如图2所示，为本发明实施例中的MLB方法流程图，包括以下步骤：

步骤201，小区簇中的各个小区测量自身的负载状态，将自身的负载状态信息发送给相邻小区，接收相邻小区的负载状态信息，将相邻小区的负载状态信息存储到自身的邻小区列表中。

具体地，同一小区簇中的各个小区可以按照各自的负载测量时长轮流测量自身的负载状态，将自身的负载状态信息发送给同一小区簇中的相邻小区。各个小区可以在其他小区的负载测量时长内接收同一小区簇中的相邻小区的负载状态信息，将该相邻小区的负载状态信息存储到自身的邻小区列表中。其中，同一小区簇中的各个小区的负载测量时长可以互不重叠。

例如，一个小区簇的MLB周期为T_i（i=1，2，…），T_i可以包括N个负载测量时长T_ij（j=1，2，…，N）和一个MLB时长T_MLB,i，并满足以下关系：

$T_i=\underset{j=1}{\overset{N}{\mathrm{\Σ}}}{T}_{\mathrm{ij}}+T_{\mathrm{MLB},i}...\left[1\right]$

其中，T_i、T_ij和T_MLB,i的长度均可由上层设定。在T_ij内，小区簇中的第j个小区测量自身的负载状态，并通过X2接口发送自身负载状态信息到各个相邻小区；小区簇中的其他小区接收各自的相邻小区的负载状态信息，并储存到自身的邻小区列表中。在最后一个负载测量时长T_iN结束后，小区簇中的所有小区均完成对自身负载状态的测量和对邻小区列表中的负载状态信息的更新。小区簇中的小区的负载状态包括轻载、中载、轻微过载和严重过载，每种状态对应 的负载状态信息可以通过2比特数据表示。

步骤202，小区簇中的小区检测自身的负载状态和相邻小区的负载状态是否满足MLB的触发条件，如果满足，则执行步骤203；否则，结束当前MLB周期的操作，等待下一MLB周期的负载测量时刻。

具体地，小区簇中的小区根据自身的负载状态和存储在邻小区列表中的相邻小区的负载状态信息，判断是否满足MLB的触发条件。其中，MLB的触发条件可以为：同一小区簇中的相邻小区间同时出现轻载小区和轻微过载小区、轻载小区和严重过载小区，或者中载小区和严重过载小区。如果相邻小区间的状态不满足上述条件，说明当前网络不需要发起MLB（例如，轻载小区和中载小区同时出现），或者即使发起MLB，网络的负载状况也无法得到改善（例如，轻微过载小区和严重过载小区同时出现），因此，当前网络不允许发起MLB操作。

步骤203，满足MLB的触发条件的小区向相邻小区发起MLB操作，并与相邻小区进行负载转移。

具体地，小区簇中的小区检测自身的负载状态和相邻小区的负载状态满足MLB的触发条件时，与相邻小区进行MLB操作。其中，上述发起MLB操作的小区可以为小区簇中负载最小或最大的小区，上述小区为轻载小区时，该轻载小区可以与过载量最大的相邻小区进行负载转移，该相邻小区为轻微过载小区或严重过载小区；上述小区为严重过载小区时，该严重过载小区可以与相邻的未过载小区进行负载转移，该未过载小区为轻载小区和/或中载小区。

步骤204，发起上一次MLB操作的小区确定转移负载后自身的负载状态，接收相邻小区在转移负载后的负载状态信息。

步骤205，发起上一次MLB操作的小区检测自身的负载状态和相邻小区的负载状态是否满足MLB的触发条件，如果满足，则执行步骤206；否则，结束当前MLB周期的操作，等待下一MLB周期的负载测量时刻。

步骤206，发起上一次MLB操作的小区判断MLB操作时间是否超过预设 时长，如果没有超过，则执行步骤203；否则，结束当前MLB周期的操作，等待下一MLB周期的负载测量时刻。

其中，MLB操作时间为从发起MLB的小区第一次检测是否满足MLB的触发条件开始，到当前时刻的时间段；预设时长可以为预设的MLB时长，即，由上层设定的T_MLB,i。

本发明的实施例包括以下优点，因为根据小区簇中的各个小区的负载状态发起MLB操作，并在相邻小区间进行负载转移，能够平稳地实现MLB，提高负载均衡收敛速度，并避免乒乓效应的出现，节省了网络信令开销，降低了网络交互的负荷，提高了无线资源的利用率，进行保证整个网络的稳定性。当然，实施本发明的实施例的任一产品并不一定需要同时达到以上所述的所有优点。

本发明实施例中发起MLB操作的小区可以为轻载小区，该轻载小区可以发起主动MLB操作，承担相邻的过载小区的负载，具体流程如图3所示，包括以下步骤：

步骤301，轻载小区根据自身的负载状态和相邻小区的负载状态信息，确定满足MLB的触发条件。

具体地，轻载小区检测到自身处于轻载状态时，搜索自身的邻小区列表，检测到本小区簇中的相邻小区的负载状态为轻微过载或严重过载，确定满足MLB的触发条件。

假设系统过载门限为50%，轻载小区的可承担负载量L_trans为20%，各负载状态对应的负载量的取值范围是：轻载状态（0～30%），中载状态（30%～50%），轻微过载状态（50%～70%），严重过载状态（70%～100%）。如图4所示，为本发明实施例中的主动MLB操作的场景示意图，小区1～7包含在同一个小区簇，负载量的取值分别为：小区1（8%），小区2（85%），小区3（75%），小区4（15%），小区5（72%），小区6（80%），小区7（35%）。小区1和小区4的邻小区列表分别如表1和表2所示：

表1小区1的邻小区列表

小区2	严重过载
		小区3	严重过载
小区4	轻载

表2小区4的邻小区列表

小区1	轻载
		小区2	严重过载
小区5	严重过载

上述小区1和小区4均检测到自身处于轻载状态，以及本小区簇中的相邻小区的负载状态为严重过载，确定满足MLB的触发条件。

步骤302，轻载小区向网管设备发送MLB请求消息。 

步骤303，网管设备向轻载小区返回负载状况请求消息。

步骤304，轻载小区向网管设备上报自身的当前负载量。

步骤305，网管设备根据接收到各个轻载小区的当前负载量，选择当前负载量最小的轻载小区。

具体地，由于网管设备可以接收到同一小区簇中的多个轻载小区发送的MLB请求消息，而每个小区簇只允许一个小区发起MLB操作，因此，网管设备可以向多个轻载小区返回负载状况请求消息，接收多个轻载小区上报的当前负载量，并选择当前负载量最小的轻载小区作为发起MLB操作的小区。

步骤306，网管设备向选择出的轻载小区发送MLB同意消息。 

具体地，网管设备向选择出的轻载小区发送MLB同意消息，触发该轻载小区发起MLB操作。此外，网管设备还可以向未选择的轻载小区发送MLB拒绝消息，接收到MLB拒绝消息的轻载小区结束当前MLB周期的操作，等待下一MLB周期的负载测量时刻。

例如，图4中的小区1和小区4均向网管设备发送MLB请求消息，并在 接收到网管设备返回的负载状况请求消息后，向网管设备上报各自的当前负载量，即，8%和15%。网管设备可以选择当前负载量为8%的小区1作为发起MLB操作的小区，向小区1发送MLB同意消息，向小区4发送MLB拒绝消息。小区4结束当前MLB周期的操作，等待下一MLB周期的负载测量时刻。

步骤307，轻载小区向相邻过载小区发送负载状况请求消息。

具体地，若轻载小区的相邻小区中同时存在轻微过载小区和严重过载小区，则轻载小区可以向所有相邻的严重过载小区发送负载状况请求消息，并忽略相邻的轻微过载小区。

步骤308，相邻过载小区向轻载小区发送自身的当前负载量。

步骤309，轻载小区根据接收到各个相邻过载小区的当前负载量，选择当前负载量最大的相邻过载小区。

步骤310，轻载小区向当前负载量最大的相邻过载小区发送负载承担请求。

例如，图4中的小区1可以向小区2和小区3发送负载状况请求消息，获取小区2和小区3的当前负载量，即，85%和75%。小区1可以选择当前负载量为85%的小区2，向小区2发送负载承担请求，负载承担请求中包含可承担负载量L_trans，L_trans可由上层进行设定。

步骤311，相邻过载小区根据接收到的可承担负载量向轻载小区转移负载。

步骤312，相邻过载小区向轻载小区反馈转移负载后的负载状态信息。

步骤313，轻载小区根据转移负载后自身的负载状态和相邻小区的负载状态信息，判断是否满足MLB的触发条件，如果满足，则执行步骤314；否则，结束当前MLB周期的操作，等待下一MLB周期的负载测量时刻。

步骤314，轻载小区判断MLB操作时间是否超过预设的MLB时长，如果没有超过，则执行步骤307；否则，结束当前MLB周期的操作，等待下一MLB周期的负载测量时刻。

以图4的场景为例，小区2按照可承担负载量L_trans向小区1转移负载，L_trans为20%时，第一次转移负载后的小区1的负载量为28%，仍为轻载小区； 第一次转移负载后的小区2的负载量为65%，为轻微过载小区。

小区1可以根据第一次转移负载后自身的负载状态和相邻小区的负载状态信息，确定满足MLB的触发条件，如果MLB操作时间没有超过预设的MLB时长，小区1可以继续发起MLB操作，直接向负载状态为严重过载的小区3发送负载承担请求，小区3按照L_trans向小区1转移负载。第二次转移负载后小区3的负载量为55%，为轻微过载小区；第二次转移负载后小区3的负载量为48%，为中载小区。小区1可以根据第二次转移负载后自身的负载状态和相邻小区的负载状态信息，确定不满足MLB的触发条件，结束MLB操作。

本发明的实施例包括以下优点，因为根据小区簇中的各个小区的负载状态发起MLB操作，并在相邻小区间进行负载转移，能够平稳地实现MLB，提高负载均衡收敛速度，并避免乒乓效应的出现，节省了网络信令开销，降低了网络交互的负荷，提高了无线资源的利用率，进行保证整个网络的稳定性。当然，实施本发明的实施例的任一产品并不一定需要同时达到以上所述的所有优点。

本发明实施例中发起MLB操作的小区还可以为严重过载小区，该严重过载小区可以发起被动MLB操作，请求转移自身的负载至相邻的未过载小区，具体流程如图5所示，包括以下步骤：

步骤501，严重过载小区根据自身的负载状态和相邻小区的负载状态信息，确定满足MLB的触发条件。

具体地，严重过载小区检测到自身处于严重过载状态时，搜索自身的邻小区列表，检测到本小区簇中的相邻小区的负载状态为轻载或中载，确定满足MLB的触发条件。

假设系统过载门限为50%，轻载小区的可承担负载量L_trans为20%，各负载状态对应的负载量的取值范围是：轻载状态（0～30%），中载状态（30%～50%），轻微过载状态（50%～70%），严重过载状态（70%～100%）。如图6所示，为本发明实施例中的主动MLB操作的场景示意图，小区1～7包含在同一个小区簇，负载量的取值分别为：小区1（8%），小区2（85%），小区3（75%），小区4 （40%），小区5（72%），小区6（32%），小区7（80%）。小区2、3、5和7的邻小区列表分别如表3～6所示：

表3小区2的邻小区列表

小区1	轻载
		小区3	严重过载
小区4	中载
		小区5	严重过载
小区6	中载
		小区7	严重过载

表4小区3的邻小区列表

小区丁	轻载
		小区2	严重过载
小区5	严重过载

表5小区5的邻小区列表

小区2	严重过载
		小区3	严重过载
小区6	中载

表6小区7的邻小区列表

小区2	严重过载
		小区4	中载
小区6	中载

上述小区2、3、5和7均检测到自身处于严重过载状态，以及本小区簇中 的相邻小区的负载状态为轻载或中载，确定满足MLB的触发条件。

步骤502，严重过载小区向网管设备发送MLB请求消息。

步骤503，网管设备向严重过载小区返回负载状况请求消息。

步骤504，严重过载小区向网管设备上报自身的当前负载量。

步骤505，网管设备根据接收到各个严重过载小区的当前负载量，选择当前负载量最大的严重过载小区。

具体地，由于网管设备可以接收到同一小区簇中的多个严重过载小区发送的MLB请求消息，而每个小区簇只允许一个小区发起MLB操作，因此，网管设备可以向多个严重过载小区返回负载状况请求消息，接收多个严重过载小区上报的当前负载量，并选择当前负载量最大的严重过载小区作为发起MLB操作的小区。

步骤506，网管设备向选择出的严重过载小区发送MLB同意消息。

具体地，网管设备向选择出的严重过载小区发送MLB同意消息，触发该严重过载小区发起MLB操作。此外，网管设备还可以向未选择的严重过载小区发送MLB拒绝消息，接收到MLB拒绝消息的严重过载小区结束当前MLB周期的操作，等待下一MLB周期的负载测量时刻。

例如，图6中的小区2、3、5和7均向网管设备发送MLB请求消息，并在接收到网管设备返回的负载状况请求消息后，向网管设备上报各自的当前负载量，即，85%、75%、72%和80%。网管设备可以选择当前负载量为85%的小区2作为发起MLB操作的小区，向小区2发送MLB同意消息，向小区3、5和7发送MLB拒绝消息。小区3、5和7结束当前MLB周期的操作，等待下一MLB周期的负载测量时刻。

步骤507，严重过载小区向相邻的未过载小区发送负载均衡请求。

其中，相邻的未过载小区可以为一个或多个轻载小区和/或中载小区。

步骤508，相邻的未过载小区向严重过载小区发送可承担负载量。

具体地，未过载小区接收到多个严重过载小区发送的负载均衡请求时，可 以统计该严重过载小区的数量，根据自身的可承担负载总量和统计得到的严重过载小区的数量确定向各个严重过载小区返回的可承担负载量，该可承担负载量为未过载小区的可承担负载总量与严重过载小区的数量之商，该未过载小区的可承担负载总量可以为系统过载门限与该未过载小区的当前负载量之差，该系统过载门限可由上层设定。

例如，图6中的小区2向小区1、小区4和小区6发送负载均衡请求，小区1的可承担负载总量为50%－8%＝42%，如果接收到2个严重过载小区发送的负载均衡请求，则小区1向2个严重过载小区分别发送的可承担负载量为42%／2=21%；同理，如果小区4和小区6分别接收到2个和3个严重过载小区发送的负载均衡请求，则小区4和小区6发送的可承担负载量分别为5%和6%。

步骤509，严重过载小区根据接收到的可承担负载量向相邻的未过载小区转移负载。

具体地，当相邻的未过载小区为多个小区时，严重过载小区可以统计接收到的未过载小区的可承担负载量之和，判断自身的绝对过载量与统计得到的可承担负载量之和之间的大小关系，其中，严重过载小区的绝对过载量为该严重过载小区的当前过载量与过载门限之差。

当可承担负载量之和小于或等于严重过载小区的绝对过载量时，严重过载小区按照可承担负载量向所有相邻的未过载小区转移负载。当可承担负载量之和大于严重过载小区的绝对过载量时，严重过载小区按照可承担负载量从大到小的顺序依次向未过载小区转移负载，直到在转移负载后自身的负载状态为轻载或中载，在上述过程中，严重过载小区有可能仅向部分相邻的未过载小区转移负载。

步骤510，相邻的未过载小区向严重过载小区反馈转移负载后的负载状态信息。

步骤511，严重过载小区根据转移负载后自身的负载状态和相邻的未过载 小区的负载状态信息，判断是否满足MLB的触发条件，如果满足，则执行步骤512；否则，结束当前MLB周期的操作，等待下一MLB周期的负载测量时刻。

以图6的场景为例，小区2可以统计小区1、小区4和小区6的可承担负载量之和，即，21%+5%+6%=32%，由于小区2的绝对过载量为85%－50%=35%，因此，上述可承担负载量之和小于小区2的绝对过载量，小区2按照各个小区的可承担负载量各个小区转移负载。转移负载后，小区2的负载量为53%，小区1、小区4和小区6的负载量为29%、45%和38%，不再满足MLB的触发条件。

步骤512，轻载小区判断MLB操作时间是否超过预设的MLB时长，如果没有超过，则执行步骤507；否则，结束当前MLB周期的操作，等待下一MLB周期的负载测量时刻。

需要说明的是，本发明实施例中的MLB方法不仅可应用于3GPP（3rd Generation Partnership Project，第三代合作伙伴计划）IMT-Advanced系统，也可应用于其他无线蜂窝移动通信系统中。

本发明的实施例包括以下优点，因为根据小区簇中的各个小区的负载状态发起MLB操作，并在相邻小区间进行负载转移，能够平稳地实现MLB，提高负载均衡收敛速度，并避免乒乓效应的出现，节省了网络信令开销，降低了网络交互的负荷，提高了无线资源的利用率，进行保证整个网络的稳定性。当然，实施本发明的实施例的任一产品并不一定需要同时达到以上所述的所有优点。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台终端设备（可以是手机，个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述 的方法。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视本发明的保护范围。

Claims (4)

1.一种移动负载均衡MLB方法，其特征在于，应用于包括多个小区的小区簇中，设定由所述小区簇中当前负载量最小的小区发起MLB操作并承担相邻小区转移的负载，或者由所述小区簇中当前负载量最大的小区发起MLB操作并向相邻小区转移负载，所述方法包括以下步骤：

小区簇中的各个小区测量自身的负载状态，将自身的负载状态信息发送给相邻小区，接收相邻小区的负载状态信息，将所述相邻小区的负载状态信息存储到自身的邻小区列表中；

所述小区簇中的小区检测到自身的负载状态和相邻小区的负载状态满足MLB的触发条件时，向所述相邻小区发起MLB操作，并与所述相邻小区进行负载转移；

其中，所述小区的负载状态包括轻载、中载、轻微过载和严重过载；

所述小区簇中的小区检测到自身的负载状态和相邻小区的负载状态满足MLB的触发条件，包括：

所述小区检测到自身的负载状态为轻载，且相邻小区的负载状态为轻微过载或严重过载；

或者，所述小区检测到自身的负载状态为严重过载，且相邻小区的负载状态为轻载或中载；

所述小区簇中的小区检测到自身的负载状态和相邻小区的负载状态满足MLB的触发条件时，向所述相邻小区发起MLB操作，并与所述相邻小区进行负载转移，包括：

所述小区检测到自身的负载状态为轻载且所述相邻小区的负载状态为轻微过载或严重过载时，向网管设备发送MLB请求消息；当所述小区为所述小区簇中当前负载量最小的小区时，所述小区接收所述网管设备返回的MLB同意消息，并向过载量最大的相邻小区发送负载承担请求，所述负载承担请求中包含可承担负载量；所述小区按照所述可承担负载量从所述过载量最大的相邻小区接收负载；

或，所述小区检测到自身的负载状态为严重过载且所述相邻小区的负载状态为轻载或中载时，向网管设备发送MLB请求消息；当所述小区为所述小区簇中当前负载量最大的小区时，所述小区接收所述网管设备返回的MLB同意消息，并向相邻的未过载小区发送负载均衡请求；所述小区接收所述未过载小区返回的可承担负载量，根据所述可承担负载量向所述未过载小区转移负载。

2.如权利要求1所述的方法，其特征在于，所述小区接收所述未过载小区返回的可承担负载量，根据所述可承担负载量向所述未过载小区转移负载，具体包括：

所述未过载小区为多个小区时，所述小区确定所述未过载小区的可承担负载量之和；

当所述可承担负载量之和大于所述小区的绝对过载量时，所述小区按照可承担负载量从大到小的顺序依次向所述未过载小区转移负载，直到在转移负载后自身的负载状态为轻载或中载，所述小区的绝对过载量为所述小区的当前过载量与过载门限之差。

3.如权利要求1所述的方法，其特征在于，所述未过载小区接收到多个严重过载小区发送的负载均衡请求时，所述未过载小区向各个严重过载小区返回的可承担负载量为所述未过载小区的可承担负载总量与所述严重过载小区的数量之商，所述未过载小区的可承担负载总量为系统过载门限与所述未过载小区的当前负载量之差。

4.如权利要求1所述的方法，其特征在于，所述小区簇中的小区检测到自身的负载状态和相邻小区的负载状态满足MLB的触发条件时，向所述相邻小区发起MLB操作，并与所述相邻小区进行负载转移之后，还包括：

发起MLB操作的小区确定转移负载后自身的负载状态，接收所述相邻小区在转移负载后的负载状态信息；

所述小区检测到转移负载后自身的负载状态和相邻小区的负载状态满足MLB的触发条件时，继续向所述相邻小区发起MLB操作，并与所述相邻小区进行负载转移，直到自身的负载状态和相邻小区的负载状态不满足MLB的触发条件，或者MLB操作时间超过预设时长。