Release 9 incorporates SON load balancing functionality, the objective of which is to coun- teract local traffic load imbalance between neighbouring cells with the aim of improving the overall system capacity and reducing congestion. The feature functions by first detecting any traffic imbalance and then applying solutions such as adjusting the cell reselection/handover parameters (such as handover thresholds). These parameters can be autonomously changed
Figure 25.3: Illustration of PCI allocation. Reproduced by permission of©3GPP.
and directly communicated between neighbouring cells by means of the X2 Parameter Negotiation procedure as explained in Section 25.5.2.
25.5.1 Intra-LTE Load Exchange
In order to detect an imbalance, it is first necessary to exchange load information between neighbouring eNodeBs over X2 for comparison. A client-server mechanism is used for this purpose: a requesting eNodeB (client) sends a ‘RESOURCE STATUS REQUEST’ message to request a load report from some of its neighbours. The ‘RESOURCE STATUS REQUEST’
message can simultaneously request multiple types of load report and may also be directed at multiple cells of the receiving eNodeB (server). The neighbours that receive the request report the requested load information over the X2 interface via the ‘RESOURCE STATUS RESPONSE/UPDATE’ message. The reporting of the load is periodic with period indicated in the ‘RESOURCE STATUS REQUEST’ message.
The reported information can indicate any of four different types of cell load information:
• Current usage of Physical Resource Blocks (PRBs), possibly partitioned into real-time and non-real-time traffic;
• Current hardware load;
• Current S1 transport load;
• Available composite load.
The first three measurements represent a global view of the current load situation in the node that reports them. The ‘available composite load’ indicator represents the amount of overall resources that the reporting node is ready to accept. ‘Composite’ means that the reporting node takes into account multiple internal resource criteria via a proprietary evaluation to build up its report. The ‘available’ characteristic is interesting as an estimate
eNB B
eNB A
eNB C (new) Cell_B1
Ph_ID1
Cell_B2 Ph_ID 2
Cell_A1 Ph_ID 3
Cell_A2 Ph_ID 4
Cell_C1 t_Ph ID a
Cell_C2 t_Ph ID b UE_a
UE_b
of the amount of non-GBR10traffic that can be handed over into the cells controlled by the eNodeB. For example, in a case when one UE was using all PRBs, the ‘current usage of PRBs’ would typically indicate that all PRBs were fully utilized whereas those PRBs would in fact still be available to be shared by the traffic of a second UE. Two formats may be used by the operator for the ‘available composite load’ indicator:
• A simple percentage of the total E-UTRAN resources available (i.e. of the total cell uplink or downlink bandwidth known from the X2 Setup procedure);
• A percentage weighted according to a cell capacity class value.11
25.5.2 Intra-LTE Handover Parameter Optimization
As a result of the exchange of load information and detection of local load imbalance, eNodeBs may take immediate action such as deciding to handover some UEs to cells which are less loaded. However, longer-term actions can also be taken to combat the imbalance more efficiently. For example when an imbalance is detected between two specific cells it may be desirable to shift the handover trigger threshold by, for example, 0.5 dB. By so doing, UEs served by an overloaded cell may find that a less-loaded neighbour cell becomes a relatively attractive handover target, thus allowing some UEs from the overloaded cell to be served reliably by the less-loaded cell. In order to avoid a ping-pong effect, it is often desirable that the lightly loaded cell shift its corresponding threshold by a similar amount as the overloaded cell but in the opposite direction. For this to happen, the lightly loaded cell must be made aware of the change applied by the overloaded cell, or alternatively the overloaded cell could first request the less-loaded cell to change its handover threshold and wait for a positive response before initiating the change.
This is the object of the ‘Handover Parameter Negotiation’ procedure. If the two cells in question belong to the same eNodeB, this negotiation happens within the eNodeB node itself via a proprietary algorithm; otherwise, the negotiation procedure is conducted over X2 interface via the ‘Mobility Settings Change’ procedure. This procedure enables one eNodeB to send a ‘MOBILITY CHANGE REQUEST’ message to another, to indicate the handover trigger parameter shift that the first eNodeB sees as necessary for one of the cells controlled by the receiving eNodeB. The same message can optionally indicate if the first eNodeB has already performed any configuration change of this parameter for one of its own cells. If the second eNodeB accepts the proposed handover trigger parameter modification and is able to complete it, then it replies with a ‘MOBILITY CHANGE ACKNOWLEDGE’ message;
otherwise it responds with a ‘MOBILITY CHANGE FAILURE’ message which can include an ‘allowed parameter modification range’ if the reason for the failure was that the change proposed by the first eNodeB was outside the possible range.
10Guaranteed Bit-Rate – see Section 2.4.
11The cell capacity class value is a parameter between 0 and 100 configured by the operator to classify one particular cell capacity with respect to the other cells available in its network. The use of this parameter is mandatory when the ‘available composite load’ indicator is exchanged inter-RAT, e.g. towards UMTS.
25.5.3 Inter-RAT Load Exchange
In order to perform load information exchange with neighbour cells of a RAT other than LTE, an eNodeB can trigger a ‘Cell Load Reporting Request/Response’ procedure towards a neighbouring Radio Network Controller (RNC) (for WCDMA), Base Station Controller (BSC) (for GSM) or evolved High Speed Packet Access (HSPA) NodeB (for HSPA).
This new inter-RAT procedure was purposely designed to be independent of the handover procedure in order that it can be triggered at any time by a requesting eNodeB even in the absence of any mobility event. The procedure is implemented as a generic ‘SON Transfer’
container carried on top of the RAN Information Management (RIM) protocol.12 The new inter-RAT cell load reporting procedure allows an eNodeB to evaluate the load situation of GSM or UMTS/HSPA neighbour cells before triggering any load-related action such as handing traffic over to those neighbours or switching offa carrier. The new procedure may be used in all directions, i.e. from any LTE/UMTS/GSM source node to any LTE/UMTS/GSM target node of another RAT.
25.5.4 Enhanced Inter-RAT Load Exchange
One limitation of the Release 9 inter-RAT load exchange procedure described in Section 25.5.3 is that the RIM messaging which carries it passes through the core network nodes, which may become overloaded if load exchange occurs too frequently. On the other hand, variations in the radio conditions mean that it is important for the RAN nodes to have up-to-date load values from their peers in order to assess the load situation across different RATs. In order to solve these two opposing requirements, the inter-RAT load exchange procedure was enhanced in Release 10 by the introduction of two new types of reporting:
Event-triggered reporting enables a source RAN node to request a target RAN node to report only when a pre-defined cell load-level threshold is crossed in the target node.
The source node signals the granularity with which it wishes to receive indications of load variation: for example, if it requests a granularity of five levels, the target RAN node will divide the cell-load scale by five, evenly distributed on a linear scale below the overload threshold and will report the target cell load each time the load changes from one reporting level to another or enters or exits the overload state. Other parameters (such as hysteresis and averaging factors) can be configured by O&M at the target nodes.
Multiple-cell reporting enables a source RAN node to request the a target RAN node to report the load of multiple cells within a single report. For example, in the case of UMTS, an eNodeB will only need to send one request to the RNC instead of individual requests for all the cells controlled by the RNC.
12RIM is a well known protocol dedicated to information exchange between two RAN nodes of different RATs.
An example is given in Section 25.6.7.