CN100461923C - A system and method for rebalancing a load - Google Patents

Abstract

The invention relates to the field of wireless communication, in particular to a load reconfiguration system and method. The system includes: a load reconfiguration request module, a load reconfiguration module, a load monitoring module and a load adjustment module. The method includes: S1. The load reconfiguration module receives a load reconfiguration request, and the load reconfiguration request includes the target value of the load index; S2. The load reconfiguration module selects a load adjustment action and adjusts the user and records the selection result; S3 The load readjustment module requests the load monitoring module to predict the result of the selected load adjustment action; S4. The load monitoring module predicts the load adjustment action result and returns the predicted result to the load readjustment module; the load monitoring module judges whether the result satisfies the described If the target value is yes, continue to step S5; if no, return to step S2; S5. The load readjustment module executes a load adjustment action or issues an execution command. By applying the invention, the load level can be flexibly adjusted to meet the system requirements.

Description

A system and method for rebalancing a load

technical field

The invention relates to the field of mobile communication, in particular to a load reconfiguration system and method.

Background technique

In the existing cellular mobile communication system, the coverage of a large geographic area is usually divided into several cells, and a low-power transmitter (base station) is used to cover each cell to establish communication with users. The coverage radius of the cell is small, but many A single cell can cover an entire large geographic area. At the same time, using the same frequency in different cells can greatly improve the utilization of spectrum resources; adding cells using different frequencies in areas with dense users can increase the system capacity in this area. For each cell, its physical resources (such as transmission power, bandwidth, channel code resources, etc.) are limited. As the number of users it serves increases, the load of the cell will gradually become saturated, which will inevitably cause new users to be unable to access, A series of consequences such as the decline in service quality of original users.

Traditional technology uses LCC (Load Congestion Control, load congestion control) to deal with this problem. After the cell load reaches the warning line, LCC restores the load level to an acceptable level by selecting some users to disconnect and other methods. However, because the LCC operation has a great impact on user satisfaction, it cannot be started frequently, so it can only be started when the load reaches the edge of collapse, and the load adjustment target after startup is basically fixed.

The existing technology uses the LCC module to adjust the load level of the cell, and randomly selects some users to disconnect to reduce the load of the cell to an acceptable level. In actual use, there are the following disadvantages:

1. The operation selected by the LCC module is too simple and rough, which has a great impact on user satisfaction.

2. Due to reason 1, the LCC module cannot be started frequently, so the start threshold is set very high, which is close to the edge of system crash, and the risk is very high.

3. The load adjustment target of the LCC module is basically fixed at a preset threshold, which cannot be flexibly changed according to system requirements.

4. When the load is relatively high but the threshold for triggering the LCC has not been reached, the admission module has begun to reject the access of new users, so low-priority users may be able to maintain connections due to early access, and high-priority users may be able to maintain connections due to access The phenomenon of not being able to enjoy the service because of bad entry timing is contrary to the user priority setting strategy.

Contents of the invention

The present invention solves the problems that the adjustment method in the prior art is too simple, the calling relationship between the modules is not clear, and cannot meet the user's requirements, and provides a load reconfiguration system and method that can flexibly adjust the load level to meet the system requirements.

The present invention introduces the LDR (Load Reshuffling, load reshuffling) module, which is independent of traditional LCC (Load Congestion Control, load congestion control), AC (Admission Control, admission control) and other modules, and integrates a variety of operations Flexible adjustment of load levels can be called by these modules. At the same time, an LDM (Load Monitoring, load monitoring) module is introduced to monitor and evaluate the load adjustment results relatively accurately, so as to achieve the purpose of flexibly adjusting the load level to meet the system requirements. The present invention is realized through the following technical solutions.

A load reconfiguration system, comprising: a load reconfiguration request module, a load reconfiguration module, a load monitoring module and a load adjustment module;

The load reconfiguration request module sends a load reconfiguration request to the load reconfiguration module when the current load index does not meet the target value;

The load readjustment module receives the load readjustment request; selects the load adjustment action and the adjusted user and records the selection result; requests the load monitoring module to predict the result of the load adjustment action; executes the load adjustment action or sends an execution load adjustment action command to the load adjustment module ;

The load monitoring module predicts the result of the load adjustment action and returns the result to the load reconfiguration module; monitors the load index, and sends a load reconfiguration request to the load reconfiguration module when the current load index does not meet the target value.

A method for resetting a load, comprising the steps of:

S1. The load reconfiguration module receives a load reconfiguration request, and the load reconfiguration request includes a target value of a load indicator;

S2. The load readjustment module selects the load adjustment action and adjusts the user and records the selection result;

S3. The load readjustment module requests the load monitoring module to predict the result of the selected load adjustment action;

S4. The load monitoring module predicts the result of the load adjustment action and returns the predicted result to the load readjustment module; the load monitoring module judges whether the result meets the target value, if yes, proceed to step S5; if not, return to step S2;

S5. The load readjustment module executes a load adjustment action or issues an execution command.

Compared with the prior art, the application of the load reforming system and method of the present invention can obtain the following beneficial technical effects:

1. A variety of actions are introduced to dynamically adjust the cell load level.

2. The LDR module is independent of the original LCC, AC and other modules, but can be called by these modules. The LDR module mainly completes the adjustment function of the cell load, and the adjustment timing and adjustment target are determined by other modules, thus clarifying the calling relationship between modules.

3. The LDM module can monitor and predict the cell load relatively accurately, so each module can dynamically determine the cell load adjustment target according to their own needs, and the LDM module monitors and predicts the adjustment results.

4. Due to the independence of the LDR module, when the load is too high and new users are rejected, it can be determined whether to perform load reconfiguration according to their priority. After reconfiguration, high-priority users will be connected to reflect their high-priority privileges . The LDM and LCC modules can also call the LDR to dynamically adjust the cell load according to the operator's preset strategy during the real-time monitoring of the load.

Description of drawings

The present invention will be described in detail below with specific embodiments and in conjunction with the accompanying drawings.

Fig. 1 is a schematic structural diagram of the load adjustment system of the present invention.

Detailed ways

As shown in Figure 1, the load reconfiguration system described in this embodiment includes: a load reconfiguration request module, an LDR module, an LDM module, and a load adjustment module; the LDR module includes a decision-making submodule and an execution submodule; the load reconfiguration request module includes LCC module, AC module; load adjustment module includes HO module (HandOver, switching), DCCC module (Dynamic Channel Configuration Control, dynamic channel configuration control), CHS module (Channel Switch, channel type switching).

The functions of each module are described below:

The LDR module receives the load readjustment request; selects the load adjustment action and the adjusted user and records the selection result; requests the LDM module to predict the load adjustment action result; executes the load adjustment action or sends an execution command to the external load adjustment module;

The LDM module predicts the result of its load adjustment action and returns the predicted result to the LDR module; monitors the load index, and sends a load reconfiguration request to the LDR module when the load index is not satisfied.

The LDR module can be divided into a decision-making part and an execution part. The decision-making part selects a series of actions required to achieve the load target of the external request, and LDM provides the prediction of the action results during the selection process (predicts the possible impact of each action on the overall system load). Once the action sequence is selected, it will be handed over to the execution part, and then the execution part will call the external DCCC, CHS, HO and other modules to actually complete the required operations.

The LCC module, the AC module, and the LDM module send a load reconfiguration request to the LDR module when the load index is not satisfied.

Modules such as DCCC, CHS, and HO perform actual load adjustment operations for the LDR module, and truly achieve the purpose of adjusting load levels and flexibly allocating resources by dynamically adjusting channel bandwidth, switching channel types, and performing load switching. Specifically, the role of DCCC is to dynamically adjust the rate of the wireless transmission channel; the role of CHS is to select different transmission channel types (dedicated channels or common channels, etc.) for users; the role of HO is to switch users between different cells , to ensure that the user can enjoy uninterrupted service even while moving.

In summary, under the trigger of external conditions (such as LCC, AC, LDM), dynamically adjust the system load, reduce or restore the load level, and dynamically adjust the resource allocation tendency to achieve the purpose of increasing system capacity and maintaining system stability. Note that the work of LDR is not only to reduce the load, but also to make full use of resources when the load is light, so as to avoid the situation that the user quality will only continue to decline and will not recover. The location of the LDR module in the present invention is only for reconfiguration of the load, and does not involve the judgment of the limited resource state. In layman's terms, other modules determine when to do it and to what extent, and LDR is only responsible for how to do it. The advantage of canceling the internal trigger is to make the call relationship of the function module clearer and clearer, and when to do it The LDM, LCC and AC modules all have more say in the degree of judgment.

Taking the above system as the application environment, the load rebalancing method includes the following steps:

S1. The LDR module receives a load reconfiguration request, and the external reconfiguration request message includes the current value and target value of the load index;

S2. The LDR module selects the load adjustment action and adjusts the user and records the selection result;

S3. The LDR module requests the load monitoring module to predict the result of the selected load adjustment action;

S4. The LDM module predicts the load adjustment action result and returns the predicted result to the LDR module; the LDM module judges whether the result meets the target value of the load index, if yes, proceed to step S5; if not, return to step S2;

S5. The LDR module executes the load adjustment action or issues an execution command.

The LDR module is divided into a decision-making part and an execution part. The decision-making part selects a series of actions required to achieve the load target of the external request, and LDM provides the prediction of the action results during the selection process (predicts the possible impact of each action on the overall system load). Once the action sequence is selected, it will be handed over to the execution part, and then the execution part will call the external DCCC, CHS, HO and other modules to actually complete the required operations. The function of the execution part is relatively simple, that is, it can be executed sequentially according to the action list obtained by the decision part.

The external load reconfiguration requests that trigger the LDR module come from the LCC, AC, and LDM modules respectively. The necessary information that needs to be provided when sending a load reconfiguration request to the LDR is:

1. Load indicator. Currently, five indicators are used, uplink load factor, downlink load factor, downlink code resource, NodeB (base station) Credits, ground transmission bandwidth (including Iub interface, Uu interface, Iub interface, etc.), the load indicator includes current value and target Value two index values.

(1) The current value of the load index: the external module needs to give the current value, so the LDR can reduce the one-step operation of querying the LDM. That is: there are two ways for the LDR module to obtain the current index: one is to directly notify the LDR module when triggered by the LCC, AC, and LDM modules; the other is to query the LDM after the LDR module is triggered. The preferred method is the former, the LDR can be obtained directly from the reorganization request; the latter needs to be queried from the LDM module, which requires an additional operation, and if the query volume is large, it may cause a message storm or interface congestion.

(2) Target value of load index: the external module needs to provide a target value for load readjustment, which is set according to the current needs of each module. For example, the AC module receives a service request. If the request is to be accessed, the downlink load will increase by 7%, but the current load is 65%, and the access threshold is 70%. The target value of load reconfiguration is to reduce the downlink load. to 63%, so that the user can be allowed to connect.

2. The source of the request: the external module needs to sign to indicate the source of the reorganization request. In the decision-making part of the LDR, it can be defined that different action permissions are assigned to the reorganization requests from different sources.

3. RAB priority threshold (optional): This part of information is mainly used by the AC. The new RAB applying for admission has its own RAB priority attribute. This can be set as the RAB priority threshold, and the AC instructs the LDR to only adjust the priority. Users whose level is lower than the threshold.

4. Whether to allow preemption (optional): Since the impact of RAB preemption is relatively large, it is necessary for the external module to confirm whether preemption is allowed when sending the request. Only when the external module has the authority to perform preemption in the LDR and at the same time set this cell to "allow preemption", the LDR will actually implement the preemption action when necessary.

In order to adjust the system load to the required level, LDR has many actions (Actions) to choose from. These actions are described as follows according to their comprehensive impact on user service quality from low to high:

1. Load switching: switch the user to a low-load different-frequency/different-system same-coverage adjacent cell or an adjacent different-frequency/different-system macro cell (coverage area includes the current cell coverage area). Select a part of users in this cell to switch to the adjacent cell with different frequency/different system and same coverage or the adjacent macro cell with different frequency/different system (the coverage area includes the coverage area of the current cell) with relatively low load. This action can effectively and quickly reduce the load level, and the user's service quality will not be degraded. Applicable to both uplink and downlink, mainly used to reduce load level.

2. Real-time service rate adjustment: adjust the real-time service rate. For real-time services, there are request rates and guaranteed rates in the RAB parameters. Therefore, if the data transmission rate obtained by real-time services is greater than its guaranteed rate, the actual rate of the service can be reduced to the guaranteed rate to obtain load decrease. When the load is low, the actual rate of real-time services can be increased to the requested rate. This kind of action selection range is small, and the load level that can be reduced is also limited, and has little impact on the service quality of real-time users. Both up and down, can be used to raise or lower load levels.

3. BE service rate adjustment: adjust the BE (Best Effort, non-real-time service) service rate. For BE services (such as FTP, Email, and web browsing), changes in the real-time rate will not have a great impact. Because the large data volume business in BE business has a great impact on the system load, this action can also effectively adjust the load level, at the cost of changing the service quality of BE users. Both up and down, can be used to raise or lower load levels.

4. BE service channel type switching: transfer DCH (Dedicated Channel, dedicated channel) channel users to CCH channel for data transmission. For DCH users, code resources and cell downlink transmission power will be occupied even if the user does not transmit data. CCH (Common Channel, public channel) is shared by multiple users. Users only occupy code resources and cells when they need to transmit data. Downlink transmission power; therefore, it may be considered to transfer some users from DCH to CCH for data transmission to improve resource utilization. The load level that this action can reduce is limited, but it has little impact on the service quality of BE users. Note that this action is generally performed after the BE service rate is reduced, because the CCH data rate is small, and it may not be possible to switch to CCH if the BE service rate is not reduced. If the system implements DSCH, the priority of this action can be set It is higher than BE service rate adjustment. Applicable both up and down, only for reduced load levels.

5. Common channel power adjustment: reduce the power reserved for common channels. The RNC will reserve some resources for the public channel. If the system implements DSCH, the reserved power of DSCH will occupy a large proportion. By reducing the reserved power of the public channel, the system can also reduce the downlink load, but it has no effect on the uplink load, and this action will affect all public channel users. In the case of heavy load, the negative impact of this action Not to be underestimated. Applicable only for downlink, can be used to reduce or increase the load level.

6. RAB preemption: According to the RAB (Radio Access Bearer, the priority attribute of wireless service bearer) priority, release the users who are allowed to be preempted. This is the last choice for load reduction requests. When the above actions fail to achieve the expected effect, only those users who are allowed to be preempted can be released directly. This action has the greatest impact on the user's service quality, but the effect of reducing the load level is immediate. Applicable to uplink and downlink, only used to reduce load level.

The decision-making part of the LDR module can define different action permissions for reorganization requests from different sources. There is no certain restriction on the configuration of this permission, and different restrictions can be made according to different configurations. For example, as shown in Table 1, all 6 kinds of actions can be performed for the LCC request, but there is no right to perform RAB preemption for the LDM request.

Table 1 LDR action authority

After the LDR module determines the load adjustment action according to the action authority, it needs to call the modules: LDM,

DCCC, CHS, and HO are implemented in detail. Its main calling relationship is:

(1) Load switching: call the HO module to execute.

(2) Real-time service rate adjustment: execute by calling the DCCC module.

(3) BE service rate adjustment: execute by calling the DCCC module.

(4) BE service channel type switching: call the CHS module to execute.

(5) Common channel power adjustment: it can be implemented internally, or it can be completed by calling the DSCH scheduling module.

(6), RAB preemption: internal implementation.

The order in which LDM, DCCC, CHS, and HO perform load adjustment actions can be set according to different configurations. Preferably, the LDR module issues execution commands according to the following execution order for different load reconfiguration requests:

1. Request to reduce the load:

(1) Downlink: load switching→real-time service rate adjustment→BE service rate adjustment→BE service channel type switching→common channel power adjustment→RAB preemption.

(2) Uplink: load switching→real-time service rate adjustment→BE service rate adjustment→BE service channel type switching→RAB preemption.

2. Request to increase the load:

(1) Downlink: common channel power adjustment → BE service rate adjustment → real-time service rate adjustment → BE service channel type switching.

(2) Uplink: BE service rate adjustment → real-time service rate adjustment → BE service channel type switching.

When the LDR module chooses to adjust the user, if the load reconfiguration request requires to reduce the load, the LDR module searches according to the RAB priority from low to high; otherwise, the LDR module searches according to the RAB priority from high to low. When executing each action, it is sorted according to the RAB priority of each service user. When the load is reduced, the actions of users with low RAB priority are given priority, and when the load is increased, the actions of users with high RAB priority are given priority.

According to the description in Section 5.2.4 of the protocol TS25.410, the priority of the RAB is determined by the CN (CoreNetwork, core network) based on user information and QoS (Quality of Service, quality of service requirements) information. CN must specify the priority level, stealing capability and queuing characteristics of the RAB in the RAB establishment or modification request, but the specific execution of queuing and resource stealing is done by UTRAN (UMTS Terrestrial Radio Access Network UMTS Terrestrial Wireless Communication Network).

As shown in Table 2, according to the description of the RAB ASSIGNMENT REQUEST signaling sent by the CN to the RNC (Radio Network Controller, radio network controller) according to Section 9.2.1.3 of the protocol TS25.413, the Allocation/Retention Priority will be carried in the signaling cell. If the RNC does not receive these cells, it means that the RAB cannot preempt other users, but is allowed to be preempted by other users.

Cell/packet name Ranges meaning Allocation/Retention Priority A group name in signaling ->Priority Level 0-reserved, 1-highest...14-lowest, 15-no priority Indicates the priority level of the RAB request, 1~14 is the effective level -> Pre-emption Capability Cannot trigger preemption, can trigger preemption Indicates whether the RAB can preempt existing users -> Preemptive Pre-emption Vulnerability Cannot be preempted, can be preempted Indicates whether the RAB can be preempted by other users ->Queuing Allowed Can't line up, can line up Identifies whether the RAB can be queued and delayed processing

Table 2 RAB priority cell

It can be seen from the above table that a RAB will not only be given a 14-level priority definition, but also be specified whether it can preempt other users and whether it can be preempted by other users.

In the system, the judgment of queuing and preemption can be implemented in AC, while the actual execution of preemption can be completed in LDR. Specifically, the AC checks the RAB priority information after receiving the RAB request. If it finds that the current resource is limited and the new RAB can preempt other users, the AC sends a load reconfiguration request to the LDR. Indicates that preemptive operations are allowed. If the LDR finds that other ways cannot reduce the load, it will release the RAB that can be preempted by other users to realize the execution of preemption. In other actions of the LDR (such as BE service rate adjustment, channel type switching, etc.), they are sequenced completely according to the 14-level priority definition of the RAB.

When the load reconfiguration request is sent by the AC module, the request includes the RAB priority threshold, and the LDR module selects low-priority users for adjustment according to the request. The RAB priority threshold is the priority attribute of the new RAB applying for admission.

The following is an example of how the LDR module selects the load reconfiguration action and the user. When the decision-making part receives the load reconfiguration request from other modules, it will make a decision on the action to be executed by the LDR according to the content of the specific request and select user. As shown in Table 3, after each evaluation in steps 4 to 9, it will be compared with the target value of load readjustment. If the target is reached, the evaluation will be terminated in advance, and step 10 will be directly entered. In order to reflect the differences between RAB priorities in the evaluation in step 6, segments can be made for different priorities, and a minimum rate level that can be reduced to is determined for each segment. In this example, the lowest rate is 32kbps when the RAB priority is 1~6, the lowest rate is 16kbps when the RAB priority is 7~11, and the lowest rate is 8kbps when the RAB priority is 12~15.

step illustrate example 1 Read load reshaping request The AC sends a load reduction request, reducing the downlink load factor from 0.78 to 0.65, allowing RAB preemption, and the RAB priority threshold is 10 2 Determine Action Permissions Based on Source The request issued by the AC has the authority to perform all actions 3 Determine the order of action execution based on the request content Downlink reduction request, the action execution sequence is: load switching→real-time service rate adjustment→BE service rate adjustment→BE service channel type switching→common channel power adjustment→RAB preemption 4 Perform load switching action evaluation According to the load balancing module, although there are cells with different frequency and same coverage in the current cell, the difference between the load of the different frequency and same coverage cell and the load of the current cell is less than the absolute threshold for starting load switching, and load switching cannot be performed. 5 Perform real-time service rate adjustment evaluation It is found that the current rate of the user whose ID is 134 is 128kbps, the guaranteed rate is 64kbps, the uplink and downlink are symmetrical, and the RAB priority is 11, which is lower than the priority threshold of 10. Query the load forecast result from LDM: This action can reduce the downlink load factor by 0.04. Record action: 1, ID=134, 128k→64k, 0.78→0.74 6 Perform BE service rate adjustment evaluation It is found that the current rate of the user whose ID is 627 is 64 kbps, and the RAB priority is 14; the current rate of the user whose ID is 23 is found to be 32 kbps, and the RAB priority is 11. Query the load prediction result from LDM: if ID=627, reducing the rate to 8kbps can reduce the downlink load factor by 0.03; if ID=23, reducing the rate to 16kbps can reduce the downlink load factor by 0.01. Record action: ID=134, 128k→64k, 0.78→0.74ID=627, 64k→8k, 0.74→0.71ID=23, 32k→16k, 0.71→0.70 7 Perform BE service channel type switching evaluation It is found that the current rate of users with IDs 627 and 91 is 8kbps, and the RAB priority is 14. Query the load prediction result from LDM: Switching two users to the FACH channel can reduce the downlink load factor by 0.01 each. Record action: ID=134, 128k→64k, 0.78→0.74ID=627, 64kDCH→8kFACH, 0.74→0.70 (this is a merge action) ID=23, 32k→16k, 0.70→0.69ID=91, DCH→FACH , 0.69 → 0.68 8 Conduct Common Channel Power Adjustment Evaluation DSCH is not implemented, and common channel power adjustment is not performed 9 RAB preemption assessment It is found that the current rate of the user with ID 1754 is 32kbps, the RAB priority is 13, and can be preempted. Query the load prediction result from LDM: preempting this user can reduce the downlink load factor by 0.04. Record action: ID=134, 128k→64k, 0.78→0.74ID=627, 64kDCH→8kFACH, 0.74→0.70 (this is a merge action) ID=23, 32k→16k, 0.70→0.69ID=91, DCH→FACH , 0.69→0.68ID=1754, call drop, 0.68→0.64 10 Evaluation results, transferred to the implementation section According to the recorded action list, the downlink load factor can reach the target after execution. Go to the execution part.

Table 3 Functions of the decision-making part

Table 3 only shows the process when the load reconfiguration request is downlink load reduction. If the load reconfiguration request is different, steps 4 to 9 are different. In each step of evaluation, if load reduction is required, the RAB priority is searched from low to high. If it is required that the load increases, search according to the RAB priority from high to low. If it is a request to increase the load, when performing BE service rate adjustment evaluation, for each RAB, only increase one level according to its RAB priority from high to low, for example, 8kbps→16kbps, and cannot be adjusted to 32kbps at once. In this way, most users can be taken into account. If common channel power is adjusted, only one level is adjusted each time.

The above is just an implementation example, and the selection process is different according to different configurations in actual applications.

Claims (14)

1. a load reconditioning system is characterized in that: comprising: Load Reshuffling request module, Load Reshuffling module, load monitoring module and load adjusting module;

When described Load Reshuffling request module is discontented with the foot-eye value in the present load index, send the Load Reshuffling request to the Load Reshuffling module;

Described Load Reshuffling module receives the Load Reshuffling request; Select load adjustment action and the user who adjusts and write down selection result; The result of the action is adjusted in request load monitoring module prediction load; Carry out load adjustment action or send execution load adjustment action command to the load adjusting module;

Described load monitoring module is predicted described load adjustment the result of the action and the result is returned the Load Reshuffling module; The monitoring load index is sent the Load Reshuffling request to the Load Reshuffling module when the present load index is discontented with the foot-eye value.

2. the system as claimed in claim 1, it is characterized in that: described Load Reshuffling module comprises decision-making submodule and implementation sub-module, described decision-making submodule receives the Load Reshuffling request, according to the content choice load adjustment action of Load Reshuffling request and the user who adjusts, every selection is once all to load monitoring module request prediction the result of the action, until the desired value that satisfies the Load Reshuffling request, write down all selection results simultaneously; Described implementation sub-module is carried out load adjustment action or is sent fill order to the load adjusting module.

3. the system as claimed in claim 1, it is characterized in that: described Load Reshuffling request module comprises: LCC module and/or AC module.

4. the system as claimed in claim 1, it is characterized in that: described load adjusting module comprises HO module and/or DCCC module and/or CHS module.

5. a Load Reshuffling method is applied in the cell mobile communication systems, and described cell mobile communication systems comprises Load Reshuffling module and load monitoring module; Described Load Reshuffling module receives the Load Reshuffling request; Select load adjustment action and the user who adjusts and write down selection result; Carry out load adjustment action or send fill order; Described load monitoring module monitors loading index sends the Load Reshuffling request when the present load index is discontented with the foot-eye value, and the result of the action is adjusted in the prediction load;

It is characterized in that: described method comprises the following steps:

S1. the Load Reshuffling module receives the Load Reshuffling request, comprises the desired value of loading index in the described Load Reshuffling request;

S2. the Load Reshuffling module is selected load adjustment action and is adjusted the user and write down selection result;

S3. Load Reshuffling module request load monitoring module is predicted selected load adjustment the result of the action;

S4. load monitoring module prediction load is adjusted the result of the action and will be predicted the outcome and returns the Load Reshuffling module; The load monitoring module judges whether this result satisfies described desired value, if continue step S5; If not, return step S2;

S5. the Load Reshuffling module is carried out load adjustment action or is sent fill order.

6. method as claimed in claim 5 is characterized in that: comprise also among the described step S2 that a Load Reshuffling module sets up load and adjust action lists, with the step of record selection result.

7. method as claimed in claim 5 is characterized in that: the load adjustment action described in the step S2 comprises one of them at least: load switching, the adjustment of real time business speed, the adjustment of non-real-time service BE service rate, the switching of BE traffic channel types, public channel power adjustment, RAB seize.

8. method as claimed in claim 5 is characterized in that: when the module of Load Reshuffling described in the step S2 was selected to adjust the user, if the Load Reshuffling request requires to reduce load, the Load Reshuffling module was searched for from low to high according to RAB priority; Otherwise the Load Reshuffling module is searched for from high to low according to RAB priority.

9. method as claimed in claim 5 is characterized in that: described step S5 is specially:

When load adjustment action was switched for load, order HO module was carried out;

When load adjustment action was adjusted for real time business speed, order DCCC module was carried out;

When load adjustment action was adjusted for the BE service rate, order DCCC module was carried out;

When load adjustment action was switched for the BE traffic channel types, order CIIS module was carried out;

When load adjustment action was adjusted for public channel power, the Load Reshuffling module was directly adjusted or is ordered the DSCH module to be carried out;

When load adjustment action was seized for RAB, the Load Reshuffling module was directly adjusted.

10. method as claimed in claim 9 is characterized in that: described step S5 sends fill order according to one of following order:

When the Load Reshuffling request reduces load for request:

Descending: load switching → real time business speed adjustment → BE service rate adjustment → BE traffic channel types switching → public channel power adjustment → RAB seizes;

Up: load switching → real time business speed adjustment → BE service rate adjustment → BE traffic channel types switching → RAB seizes;

When the Load Reshuffling request is request rising load:

Descending: public channel power adjustment → BE service rate adjustment → real time business speed adjustment → BE traffic channel types is switched;

Up: BE service rate adjustment → real time business speed adjustment → BE traffic channel types is switched.

11. method as claimed in claim 5, it is characterized in that: when the Load Reshuffling request among the step S1 is sent by the AC module, this request comprises the RAB priority threshold, the Load Reshuffling module selects low priority user to regulate according to it, and described RAB priority threshold is the priority attribute of the new RAB of application access.

12. method as claimed in claim 5 is characterized in that: when the Load Reshuffling request among the step S1 was sent by AC module and/or LCC module and/or load monitoring module, this request comprised the signature that it shows the source.

13. method as claimed in claim 12 is characterized in that: also comprise the step that a Load Reshuffling module moves for the load adjustment of the Load Reshuffling request setting permission of separate sources, be specially:

When Load Reshuffling request during from the load monitoring module, restriction is carried out RAB and is seized action;

When Load Reshuffling request during, can carry out all load adjustment actions from AC module, LCC module.

14. method as claimed in claim 13 is characterized in that: also comprise the step of a Load Reshuffling module according to the definite load adjustment action that allows in the source of Load Reshuffling request.

Images