CUPS Architecture - End-To-End Call flow diagram

 

CUPS-Userplane Selection

 

In CUPS Architecture, Control Plane(SGW-C,PGW-C,SGWPGW-C) selects Userplane (SGW-U,PGW-U,SGWPGW-U) to serve the subscriber request during PDN session establishment.

 

 There are multiple ways CP selects UP for a particular request.      

    Based upon APN received in the Create Session request. (APN-level)

       Based upon the TAC received in Create Session request. (User-location)

    Based upon the Load information of a particular UP-capacity among multiple UP to be selected.

    Round-Robin. (Least-loaded)

 

Based upon the operator configuration among above mentioned options, UP selection is to be performed by CP.

APN-Level: Same UE can be served by different Userplanes when UP selection is configured based upon APN level configuration.

            Eg:    internet àUP1

    IMS àUP2

 

User-location: UE’s can be served by a particular UP based upon their location.

                               

UP-Capacity: Based upon the Load Control Information (LCI), Overload control information (OCI) received from UP to CP. CP takes the selection decision based upon these values. These values gets updated from UP to CP in SX Response messages.

Round-Robin: When no specific matched condition is configured for UP selection then by default round-robin technique is used to distribute the load among all the connected UPs.

                   

 

 

Network Initiated Dedicated bearer

Before writing about dedicated bearers, we must be aware of the types of bearers in LTE.

There are 2 type of bearers available in LTE, “Default & Dedicated bearer”.

Default Bearer is the primary bearer that is established when UE initially attaches/latches to the network. Also, there could be additional Default bearers that could be required to access PDN for some other services(like IMS-Volte,Internet-Data).

Dedicated Bearer is the secondary bearer that is associated with any of the default bearer.

For more details refer:
http://www.simpletechpost.com/2012/05/default-bearer-dedicated-bearer-what.html

Here are the few questions to answer to better understand the context:

Which network element initiate the Network initiated dedicated bearer ?

Answer: In most of the cases, it is initiated by PCRF (Policy and Charging Rules Function) and in very few cases PGW where PCRF is not deployed.  

How Network initiated dedicated bearer gets triggered ?

Answer: PCRF initiates the dedicated bearer creation by sending diameter RAR(Re-Auth-Request) to PGW in which AVP ‘Charging Rule Install’ is present that specify the QoS parameter(QCI/ARP/GBR etc.) of the dedicated bearer to be created. PGW upon receiving RAR, sends Create Bearer Request with the received QCI/ARP to SGW. Upon receiving Create Bearer Response from SGW dedicated bearer gets created.

Refer: http://www.lte-5g-secrets.com/2012/05/lte-call-flow-beyond-pgw.html  

How PCRF decides to sends RAR with ‘Charging Rule Install’ ?

Answer: PCRF is configured with Policies in which it is specified that for certain events new bearer creation is to be triggered.

One good example is Volte(Voice over LTE) event.

Refer Volte Call flow:

https://www.rfwireless-world.com/Terminology/VoLTE-Originating-Call-Flow-Procedure.html

During VoLTE call setup procedure, P-CSCF informs PCRF through Rx interface about the Volte call that is being setup. PCRF has been configured with Policy (lets say ‘IMS-Volte-Policy’) with the information that Dedicated bearer of QCI-1(Voice call) is to be triggered towards PGW. Upon receiving Request from P-CSCF, PCRF sends RAR with Charging Rule Install named ‘Voice_Rule’ with QCI-1 along with other necessary parameters to PGW for dedicated bearer creation for Voice Call in which Voice data to be sent from source UE to destination UE.

For more details:
http://www.lte-5g-secrets.com/2012/05/lte-call-flow-beyond-pgw.html

APN-OI Replacement

                       APN-OI Replacement

Helps MME select the corresponding PGW based upon the APN-OI replacement value received from HSS in Update Location Answer.

PGW is selected using DNS NAPTR query using APN-FQDN.

FQDN consists of APN-NI + APN-OI

Scenario:

Traffic can be diverted to the specific PGW when there are multiple PGWs with same MCC-MNC in the home network or if the UE is roaming in visiting network and to home-route the traffic to its home PGW.

In the normal scenario, PGW-FQDN constructed by MME based upon the APN value(NI) received from UE and MCC/MNC(OI) based upon the IMSI.

FQDN= <APN-NI>.apn.epc.<APN-OI>.3gppnetwork.org

If it is required not to select the default PGW by MME, APN-OI replacement field is required and to be provided by HSS to force MME to select the specific PGW of its choice instead of default PGW.

Case:

1. When UE is roaming and traffic needs to divert to home PGW then home HSS needs to send Visiting-PLMN allowed flag as false and APN-OI replacement value as home MCC-MNC (mncxxx.mccxxx.gprs) along with OI tag if need to route to the specific PGW host.

  tag.mnc<MNC>.mcc<MCC>.gprs

  Pgw1.mncxxx.mccxxx.gprs

Then MME creates APN-FQDN using above information and sends DNS NAPTR query to get the home PGW IP to forward the Create Session Request.

Note: if APN-OI replacement value is set by HSS in UE’s subscription Profile, then this is applicable for all the APN’s UE is subscribed to.  

LTE End To End Call flow

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.  

                                                          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.

GUTI = GUMMEI  +  M-TMSI

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.

Benefits:
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.