Friday, August 18, 2017

ARP ( Allocation and Retention Priority) in LTE

ARP ( Allocation and Retention Priority) in LTE

ARP parameter in Qos profile define the the relative importance of a bearer(requested) compared to other existing bearers for the allocation or retention in the network.

ARP consists of three parameters :

Priority level(1-15): Defines the importance of a bearer in relation to other bearers.
Pre-emption Capability: Defines the capability of the requested bearer to Pre-empt (remove) the existing bearers having low priority in the network.
i.e Capability to delete the other bearers.
Pre-emption Vulnerability: Defines the capability of a bearer to get Pre-emt or deleted by other high priority bearers.
I.e Capability to get deleted by other bearers.

Use case: 

Suppose a Network is configured with a threshold to support 1000 number of bearers and a request received for the creation of one more bearer when there are already 1000 bearers exist in the network.Then network decides whether to accept the new bearer creation request or not based upon the ARP value of the requested bearer ie. Priority Level is high and Pre-emption Capability is ENABLED. 
Based upon that network initiate existing bearer deletion(one or more) that are having low Priority Level and Pre-emption Vulnerability ENABLED to give services to the requested high Priority bearer.

Note: This is product specific implementation to select the algorithm to select and delete the existing bearers based upon priority.  

Monday, March 6, 2017

                                                          MME in Pool

MME in pool is a collection of MME's that serves the common service area consisting of one or more Tracking Areas.
All the eNodeBs that are serving the Tracking Areas are connected to all the MME's in Pool via S1 interface.

Upon receiving Attach request from UE, enodeB forwards the Attach request to the one of the MME in Pool based upon the RelativeMmeCapacity parameter(proportion) provided by the MME in S1Setup procedure.

For example: MME1 is configured with RelativeMmeCapacity 50 and MME2 has RelativeMmeCapacity 100. enodeB1 and enodeB2 are connected  to both the MMEs via S1 interface in Mesh topology.
In that case, enodeB forwards number of Attach request to the MMEs in ratio 1:2 (50:100). 
Out of total 30 Attach Requests, 10 will be sent to MME1 and 20 will be sent to MME2.

MME in Pool shares the load of the subscribers in that service area. 

Subscribers latched in TrackingArea1 and Tracking Area2 served by enodeB1 will be distributed among both the MMEs in pool (MME1 & MME2) based upon the RelativeMmeCapacity of each MME in pool.

Once the UE is attached successfully to any of the MME it is assigned a unique identity known as GUTI.

GUMMEI  contains  Mobile Country Code (MCC), Mobile Network Code (MNC), MmeGroupId, and the MmeCode that identifies MME in an MME Pool.

M-TMSI: Unique identity assigned to a UE.

If the subscriber moves between the TA’s let say TA2 àTA3 in the same service area it remains connected to the same MME instead of the TrackingArea served by different enodeB (enodeB2).

MME identity will be identified by the enodeB with the help of GUMMEI as every enodeB has the S1 link establish with all the MMEs in pool.  

All the MMEs in a pool share the load from all the UE in the pool service area. As long as the UE remains in the pool service area, it is normally attached to the same MME
In case any of the MME became out of service, the eNodeB reroutes the signaling from the UE to another MME in the MME pool.

1.  Network failure Handling.
2.  Network Load balancing.
3.  Reduce the Inter-MME Tracking Area Updates.
4.  Easy to take out MME from the pool for maintenance purpose. 
     By setting RelativeMmeCapacity to 0 in MME. After that no traffic will be sent by any of the connected enodeBs to this MME.