Wednesday, February 23, 2011

MME Pool – Load Balancing and Re-balancing

Reference - 3GPP TS 23.401 Section 4.3.7

As LTE is planned for larger deployment it is time to look at the load balancing and redundancy among the various core network nodes. I would like to present how a MME load balancing and redundancy can be achieved in this post. I will follow up this post with SGW and PGW pooling.
A MME in the network is identified by MME code and Group id.  Each MME will have a weight factor configured that is conveyed to eNB during initial S1 setup.  An eNB can talk to multiple MMEs in a pool. Based the weight factor eNB will decide which MME can be loaded with calls to what level. Assume that an eNB is communicating with 2 MMEs in a pool. MME-1 has weight of 100 and MME-2 has weight of 50. This means eNB, out of 3 UE attaches, will forward 2 attaches to MME-1 and 1 attach to MME-2.  If in case MME-1 is down, then all calls will be routed to MME-2. This is one way of achieving load balancing and redundancy. 

There is another way to achieve load rebalancing. This is the case when a MME feels overloaded, it can simply move the calls to other MME in a given pool. Assume above example. MME-1 has been overloaded and cannot handle any more calls. If MME-1 wants to free up some resources, than it release the S1 connections of UE towards eNB asking UE to perform a “load balancing TAU”. This is conveyed to UE by eNB in a RRC message. Once UE gets this message it shall send a Tracking area update message which is routed to MME-2 by eNB. This way MME-1 can gracefully move calls to other MME-2.  It is assumed that MME-2 and MME-1 are connected over S10 interface as MME-2 should pull the UE context from MME-1. 
If the MME is feeling overloaded, then it may also send Overload Start message to eNB asking it not to forward any calls to it. If necessary resources are available then MME may send Overload Stop indicating that it is ready to accept new calls.
Another way of achieving load balancing is using DNS at eNB. If UE is NOT connecting for the first time then it will populate GUMMEI to eNB in one of the RRC messages. Based on the GUMMEI eNB can perform a DNS query to obtain MME information and forward the UE messages to that particular MME.  If the selected MME is not responding then eNB may forward the call to next available MME in the pool.
I believe this should help operators to plan their network.

29 comments:

Husni said...

Very nice.........




http://www.wirelessrouterproxy.blogspot.com

dhruv said...

@Santosh: When you say that weights are assigned to the MME, do you actually mean the weights for the link between eNB and MME or is the weight for MME hard-coded. Coz if thats the case, there's always a need for Load Balancing from MME-1 to MME-2. What I think is that the link connecting eNB to MME should have a path metric, which would indicate MME selection priority for eNB's. I hope I am making sense here. Correct me if I am wrong.

Santosh said...

Hi

Weights are assigned to MME. Infact they are configured based on their strengths in a given pool. Using these weights eNB will decide how much to load a MME.

Santosh

Anonymous said...

Hey Santosh,

I am working on how exactly the PDN-GW keeps track of data UL/DL for updating the HSS for billing and charging purposes. Is there any doc that I can refer for the network/call flows?

Thanks
Pratap

Santosh said...

Hi...i believe thats up to PGW implementation. Specs doent speak of that.

Santosh said...

Oops...wrong comment. I am not sure of the PGW talking HSS spec. I know the spec which gives call flows for online and offline billing.

Gabriel Brown said...

Hi Santosh -- any views on what the influence of MME Pool might be on the decision about whether or not to integrate SGSN and MME equipment?

Santosh said...

Gabriel Brown on my blog! Cool!

Well I wouldn't be too worried when integration is considered.

If 3G network is well laid then we can simply fit the LTE network into the same topology, i.e from mobile core point. Also operators are very much interested in combining both SGSN and MME onto a single node making the interRat handovers a bit easy. If existing network is designed for redundancy then fitting in LTE shouldn't be much of problem.

Rauf said...

Hi Santosh,

I am new to this blog. I have a naive question!

I just went through Overload related procedure of TS 36.413 which describes

"The purpose of the Overload Start
procedure is to inform an eNB to reduce the signalling load towards the concerned MME."

What should be the criteria of measuring signalling load or Weight Factor? Number of UE connections?

Santosh said...

Hi Rauf

Its upto the MME to decide when it is overload. Number of Subscribers is 1, other could cpu overload or anything. Its basically a implementation factor. Different vendors have different overload conditions.

Rauf said...

Another naive question!!

I was wondering if the MME fails in the middle of ongoing data call (data passing through S-GW between PDN and UE, bearer activation is already done for that UE) what will be the behavior of the ongoing data call. Will it be failed on instant due to MME failure?

Santosh said...

If MME fails, S1 will be released. So eNB will release the RRC connections and UE may go to idle mode. UE can do service request which can be directed to a different MME.

Anonymous said...

Hello Santosh,

First of all, thanks for this nice article. I have problem understanding the third method. Why DNS query is required in last method? EnodeB is configured for that particular MME, Right? It seems to me this method has more overhead than first one - weight factor, as it waits for MME response.

Santosh said...

Hello

No! eNB is not configured for one MME. There can be a many to many relation between eNB and MME. Hence eNB may do a dns query to find an MME based on GUTI.

Bhanu Magadi said...

Santosh, which S1-AP or EMM message carry the MME weight factor?

Is weight factor a static configuration for MMEs in pool? If so, which attribute carries the current load factor of MME?

Santosh said...

S1 setup response and MME configuration update.

Yes, it should be a static configuration.

oc-ed said...

Thank you for the informative article Santosh.

Is anyone looking at ways to measure the overall signalling load as well as signalling load on a per sNodeB and/or ue basis?

I have seen some discussion of the potential problems with signalling in LTE and am interested in how to track that as a set of performance KPIs.

Rauf said...

Hi Santosh,

At the case of MME load re-balancing when it moves the call to other MME, source MME releases the S1 resources and UE performs "load balncing TAU" directed by eNB through RRC message.

I cannot understand why radio (rrc) connection re-establishment from UE side is necessary. Moreover, if all UEs rrc connection re-establish at the same time, as surely happen in this case, it will bring signaling congestion in network side.

Is there any problem in this approach where eNB just establish new S1-connection with target MME and redirect UE's packet UL/DL side without affecting radio connections?

Santosh said...

I havent heard of signalling issues on LTE. Every node in core network is designed to handle load. Not sure how it is done on eNB.

Anyone?

Santosh said...

Hi Rauf

I am not an expert at Radio. But UE connection may be dropped or RRC may be modified. But if you have insights on RRC spec do let us know how the load balancing tau works on radio side.

Cheers,
Santosh

oc-ed said...

Here is a link to an article on LTE signaling woes ...

http://www.lightreading.com/document.asp?doc_id=209574

Anonymous said...

Hey, Can we do Load balancing and ICIC b/w two eNodeB's when there is no X2 b/w them.

Elena said...

Hi! Thanks for the article. Can you recommend any source where I could learn more details about using DNS at eNB for achieving load balancing? I cannot find anything about this method neither in 3GPP documentation nor in the Internet. Thank you! /Elena

Harish said...

Hi Santosh,

I just want to know if e-NodeB support MME active & standby sort of.
e-NodeB is connecting to MME A when MME A has no problem. But if MME A has a problem, e-NodeB tries to connect to MME B.

Cheers,
Harish

Santosh said...

Yes

Muthukumaran said...

Hi Santhosh,

When a MME is offloading, is it not necessary to update eNBs with reduced-capacity (via "Relative MME Capacity" of MME_CONFIGURATION_UPDATE message) so that eNBs do not divert newer traffic to the MME which is in offloading-mode ?

Is it also mandatory to prevent new S1-Setups in this case ?

Without these, offloading may be only partial and non-deterministic.

Could not find anything specifically in R9 docs in this regard

Regards
Muthu

Santosh said...

Well.. while offloading it can release the Iu connection with TAU required. This will make eNB redirect the further messages to another MME.

Overload start and stop can be used too.

Relative Capacity is also another way.


Refer to 36.413 and 23.401

raghav said...

I'm new to this blog. Interesting discussion. My be a dumb question. I'm curious on why the UE need to know which MME it is connected.Can't the eNode-B hide the details. eNodeB could connect to alternate MME if the current active becomes overloaded. thanks for your response.

Santosh Kumar Dornal said...

Yes, UE doesn't care about which MME it is connected to, how ever the GUTI assigned to UE will have MME group I'd an code, which can be used to identify a MME.

Yes, eNB can feel free to connect to or route calls to different MME if serving MME is over loaded