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.