Section: 4.3.7.3 Load re-balancing between MMEs
Content: The MME Load Re-balancing functionality permits UEs that are registered on an MME (within an MME Pool Area) to be moved to another MME. NOTE 1: An example use for the MME Load Re-balancing function is for the O+M related removal of one MME from an MME Pool Area. NOTE 2: Typically, this procedure should not be used when the MME becomes overloaded because the Load Balancing function should have ensured that the other MMEs in the pool area are similarly overloaded. The eNodeBs may have their Load Balancing parameters adjusted beforehand (e.g. the Weight Factor is set to zero if all subscribers are to be removed from the MME, which will route new entrants to the pool area into other MMEs). In addition the MME may off-load a cross-section of its subscribers with minimal impacts on the network and users (e.g. the MME should avoid offloading only the low activity users while retaining the high activity subscribers. Gradual rather than sudden off-loading should be performed as a sudden re-balance of large number of subscribers could overload other MMEs in the pool. With minimal impact on network and the user's experience, the subscribers should be off-loaded as soon as possible). The load re-balancing can off-load part of or all the subscribers. To off-load ECM-CONNECTED mode UEs, the MME initiates the S1 Release procedure with release cause "load balancing TAU required" (clause 5.3.5). The S1 and RRC connections are released and the UE initiates a TAU but provides neither the S-TMSI nor the GUMMEI to eNodeB in the RRC establishment. NOTE 3: Special care needs to be taken when offloading Relay Nodes. This is because there may be UEs connected to the RN and some of these UEs may be registered on other MMEs. The MME should not release all S1 connections which are selected to be released immediately when offloading is initiated. The MME may wait until the S1 Release is performed due to inactivity. When the MME is to be offloaded completely the MME can enforce an S1 Release for all remaining UEs that were not offloaded by normal TAU procedures or by S1 releases caused by inactivity. To off-load UEs which perform TA Updates or Attaches initiated in ECM-IDLE mode, the MME completes that procedure and the procedure ends with the MME releasing S1 with release cause "load balancing TAU required". The S1 and RRC connections are released and the UE initiates a TAU but provides neither the S-TMSI nor the GUMMEI to eNodeB in the RRC establishment. When the UE provides neither the S-TMSI nor the GUMMEI in the RRC establishment, the eNodeB should select an MME based on the Weight Factors of the MMEs in the pool. To off-load UEs in ECM-IDLE state without waiting for the UE to perform a TAU or perform Service request and become ECM-CONNECTED, the MME first pages UE to bring it to ECM-CONNECTED state. If paging the UE fails and ISR is activated, the MME should adjust its paging retransmission strategy (e.g. limit the number of short spaced retransmissions) to take into account the fact that the UE might be in GERAN/UTRAN coverage. Hardware and/or software failures within an MME may reduce the MME's load handling capability. Typically such failures should result in alarms which alert the operator/O+M system. Only if the operator/O+M system is sure that there is spare capacity in the rest of the pool, the operator/O+M system might use the load re-balancing procedure to move some load off this MME. However, extreme care is needed to ensure that this load re-balancing does not overload other MMEs within the pool area (or neighbouring SGSNs) as this might lead to a much wider system failure. When the Dedicated Core Network (DCN) feature is used, the DCN load re-balancing functionality permits UEs that are registered on an MME in the DCN (within a pool area) to be moved to another MME in the same DCN in a manner that achieves load balancing between the CN nodes of the DCN and pool area. The DCN load re-balancing is triggered by the source MME (within a DCN). The details are as follows: - If the UE is in ECM-IDLE state, the NAS Message Redirection procedure (see clause 5.19.1) is triggered at the next intra-MME Tracking Area Update Request enabling eNodeB to load balance between MMEs of the same DCN. To off-load UEs in ECM-IDLE state without waiting for the UE to perform a TAU or perform Service request, the MME first pages the UE to bring it to ECM-CONNECTED state and proceeds as described for the ECM-CONNECTED case below. - If the UE is in ECM-CONNECTED state, the MME performs the GUTI reallocation procedure, includes the unchanged GUTI of the UE and a non-broadcast TAI to induce the UE to perform a TAU procedure, and forces the UE to go to ECM-IDLE state. During the subsequent TAU procedure the MME uses the NAS Message Redirection procedure (see clause 5.19.1) to redirect the UE to another MME within the same DCN.