Load Balancing and Re-Balancing of MME and offloading process

[Krishna Kishore D V]

• Introduction
• How it works as Per 3GPP
• Implementation of this functionality in Cisco MME
• Related Information

Introduction

The S1 interface supports the indication by the MME of its relative capacity to the eNB, in order to achieve loadbalanced MMEs within the pool area.Load balancing is achieved by setting a weight factor for each MME so that the probability of the eNodeB selecting an MME is proportional to its weight factor

Goal

To offload subscribers from one MME to the other peer MME in the pool.

Primary purpose

There are situations where a network operator will wish to remove load from one CN node in an orderly manner (e.g. to perform scheduled maintenance, or, to perform load re-distribution to avoid overload) with minimal impact to end users and/or additional load on other entities. The re-distribution procedure does not require any new functionality in the terminal, that is, all terminals can be moved.

How it works as Per 3GPP

As per TS 23.401

Load balancing between MMEs

The MME Load Balancing functionality permits UEs that are entering into an MME Pool Area to be directed to an appropriate MME in a manner that achieves load balancing between MMEs. This is achieved by setting a Weight Factor for each MME, such that the probability of the eNodeB selecting an MME is proportional to its Weight Factor. The Weight Factor is typically set according to the capacity of an MME node relative to other MME nodes. The Weight Factor is sent from the MME to the eNodeB via S1-AP messages (see TS 36.413 [36]). If a HeNB GW is deployed, the Weight Factor is sent from the MME to the HeNB GW.

NOTE 1:    An operator may decide to change the Weight Factor after the establishment of S1-MME connectivity as a result of changes in the MME capacities. E.g., a newly installed MME may be given a very much higher Weight Factor for an initial period of time making it faster to increase its load.

NOTE 2:    It is intended that the Weight Factor is NOT changed frequently. e.g. in a mature network, changes on a monthly basis could be anticipated, e.g. due to the addition of RAN or CN nodes.

Load re-balancing between MMEs

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 eNB in the RRC establishment.

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 eNB in the RRC establishment.

When the UE provides neither the S-TMSI nor the GUMMEI in the RRC establishment, the eNB 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.

Implementation of this functionality in Cisco MME

The following sections describe the load balancing and re-balancing functionality available on the MME.

Load Balancing

Load balancing is achieved by setting a weight factor for each MME so that the probability of the eNodeB selecting an MME is proportional to its weight factor. The weight factor is set by the operator according to the capacity of an MME node relative to other MME nodes. The relative-capacity mme-service level command is used to specify this relative weighting factor.

Once set, the Relative MME Capacity IE is included in the S1AP S1 SETUP RESPONSE message from MME to relay this weight factor. If the relative MME capacity is changed after the S1 interface is already initialized, then the MME CONFIGURATION UPDATE message is used to update this information to the eNodeB.

Load Re-balancing: Call Handling and Other Messaging Considerations

The MME uses the mme offload mme-service exec level command to enable the operator to offload UEs for a particular mme-service for load rebalancing among MMEs in a MME pool area. The command enables the operator to specify a percentage of UEs to offload, and the desired time duration in which to complete the offload.

The operator can also include the keyword option disable-implicit-detach. By default, if the UE context is not transferred to another MME within 5 minutes, the UE will be implicitly detached. This option disables this implicit detach timer.

To offload ECM-CONNECTED mode UEs, the MME initiates the S1 Release procedure with release cause “load balancing TAU required”. To offload 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”.

To offload 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 the UE to bring it to ECM-CONNECTED state.

New calls are processed normally (as per the new call policy configuration). The offloading process does not reject INIT UE messages for new subscribers. To prevent new calls from entering this MME, set the relative-capacity on this mme-service to 0.
When Init UE messages are received for an existing offloaded subscriber, the ue-offloading state is set as MARKED and the offload procedure continues until the UE is offloaded.

Once a UE is offloaded, messages such as EGTP events, Create bearer, Update bearer, Idle mode exit, and Paging trigger are be rejected. HSS initiated events also will be rejected for offloaded UEs.Detach events are processed as usual.

IMPORTANT:  Emergency attached UEs in Connected or Idle mode are not considered for offloading.

Configuring Load Balancing and Rebalancing

Configuring Load Balancing:

Set the relative capacity of an mme-service to enable load balancing across a group of mme-services within an MME pool.
Use the following example to set the relative capacity of this mme-service. The higher the value, the more likely the corresponding MME is to be selected.

config
   mme-service mme_svc -noconfirm
   relative-capacity <0-255>
    exit

Notes:
·    The default relative capacity for an mme-service is 255.

Verifying Load Balancing:

show mme-service all
[local]asr5000# show mme-service all
Relative Capacity: 50

Performing Load Rebalancing (UE Offloading)

The following example command rebalances (offloads) 30 percent of all UEs from the specified mme-service (to other mme-services in the MME pool) over the course of 10 minutes.

mme offload mme-service mme_svc time-duration 10 offload-percentage 30 -noconfirm

This command can also be entered with the disable-implicit-detach option. By default, if the UE context is not transferred to another MME within 5 minutes, the UE will be implicitly detached. This option disables this implicit detach timer.

mme offload mme-service
mme_svc time-duration 10 offload-percentage 30 disable-implicit-detach -noconfirm

To stop the offloading process, issue the command with the stop keyword option.

mme offload mme-service mme_svc stop -noconfirm

Verifying Load Rebalancing (UE Offloading)

The following command shows the offload configuration as well as the status of the rebalancing.

show mme-service name svc_name offload statistics

[local]asr5000# show mme-service name mme1 offload statistics
Current Offload Status:
                               In Progress
Implicit Detach Status:
                               Enabled
Time Duration Requested:
                              600 secs
Percentage of Subscribers
Requested:                   30
Total Number of Subscribers:
                          0
Total Number of Subscribers
to be Offloaded:           0
Total Number of
Subscribers Offloaded:                 0
Total Number of
Subscribers Received Context Transfer: 0
Remaining Time: 0 secs

Where the Current Offload Status field will report one of the following:
·    None – No UEs marked for offloading and no UEs currently being offloaded.
·    Marked – MME has marked UEs for offloading, but is waiting for offload trigger on timer expiry.
·    In Progress – MME is currently offloading marked UEs.
·    Done – Offload procedure is completed or has been terminated by operator using stop keyword.
These counters are reset each time an offload procedure is initiated, or when the following command is entered:

clear mme-service statistics offload

Monitoring Load Rebalancing

The following sections describe commands available to monitor load rebalancing on the MME.

Load Rebalancing Show Command(s) and/or Outputs:

This section provides information regarding show commands and their outputs in support of load rebalancing (UE offload). The following show command displays current statistics for the Load Rebalancing feature.
 

 show mme-service name <mme_svc_name> offload statistics
 
The following command also provides information relating to load balancing:

show mme-service session full all

UE Offloading --> Displays the UE offload state. Possible values are None, Marked, In-Progress and Done.    

Related Information