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.

Subscriber Tracing in lte network

Subscriber Tracing in lte

 

 

Subscriber Tracing provides detailed information at the call level for the UE(user).

This is done in the lte network elements(MME,SGW,PGW) to measure the performance of network elements as well as the quality of services given to the user while using lte network.

Subscriber is also traced on demand of the user itself if it is not getting the good or appropriate quality of services from the lte network.

Operator can also trace some of the random users to check the quality of network.

Purpose of Subscriber Tracing in lte network:

-         Optimize the lte network performance.

-         Upon user demand if it is not getting the good quality of services from the network.

Operator applies the tracing on lte network elements for the specific users based on any one of the information provided by user i.e. IMSI or IMEI or MSISDN.

 

How Subscriber Tracing Works:

 

Two types of Subscriber Tracing can be done in network.

1.      Management based.

2.      Signaling based.

In management based tracing operator configure User id type (imsi(0) or imei(1) or msisdn(2)) and User id value (imsi value) on the lte node(pgw,sgw,mme) from which operator wants the traces for user.

Example: UE type – IMSI, UE value – 1234566778899, Node – PGW.

Now when the UE tries to attach with the lte network all the traces sent to TCE(external entity) by PGW.

Traces contains all the details related to the user like apn, plmn, imsi, rat type, qos parameters, user location etc.

 

In Signalling based tracing operator modify the configuration data in HSS with subscriber tracing enabled for the particular UE. Whenever UE attaches with the network, HSS sends Subscriber tracing enabled in the Subscription data in message Update Location answer and then MME forwards subscriber tracing parameter in Create Session request to SGW and then to PGW. Upon receving this parameter all the nodes starts tracing of that user and send all the trace records to TCE (Trace Collection entity).

 

Configuration for Signaling based Subscriber Tracing.

In HSS –

1.      Trace depth – Low, medium, high. (At what detailed level traces required).

2.      Nodes – SGW, MME, PGW. (On which of the node tracing is required).

3.      Interfaces – S5,S8,S11,Gx,Gn etc. (On which interface tracing is required).

4.      TCE Address – Ip address of TCE.  (Which ip address node should send traces).

 

Configuration for Management based Subscriber Tracing.

In SGW,PGW,MME –

1.      Trace Depth – Low, medium, high.

2.      Type of Traces – XML , Syslog.

3.      TCE Address – Ip address of TCE.

 

Note: In operator based tracing two types of tracing is possible XML, Syslog.

but in Signaling based only xml tracing is possible.

LTE call flow beyond PGW

                       Basic LTE Call Flow beyond PGW.

Here are the call flow from PGW to PCRF on Gx interface.

During Initial Attach procedure, PGW check for the APN/Charging Characterstics received in Create session request for whether dynamic Policy(configured in PCRF) or Static policy(configured on PGW) should be applied. Depending upon the configuration, PGW forwards the request to PCRF for providing PCC Rule for the UE attach request.

PCC rules consist of:

• Rule name - This is to be used to reference a PCC rule in communication between PCEF and the PCRF . 
• Service data flow filters - shall be used to select the type of traffic that passes through the bearer on which the rule applies.
• precedence : Determines the precedence of the bearer on which the rule is applied when data is received uplink or downlink for a particular type UDP/TCP etc.  
• QoS parameters - Includes QoS Class Identifier (QCI), also the Allocation and Retention Priority (ARP) and GBR,MBR for uplink and downlik.
• Charging type - Defines whether online,offline or both or none charging is applied.

  PGW sends CCR(Init) to PCRF to get the PCC Rule from PCRF.
  PCRF has primarily two entities. PDT (Policy Derivation table) and PCT (Policy and
  Configuration table).
  In PCT, PCRF has number of PCC Rules configured.
  In PDT, PCRF has the selection criteria based upon which PCRF sends the selected PCC Rules in 
  CCA.
  Selection criteria- Can be IMSI,APN name, QCI, MBR/GBR etc. means if CCR request contains 
  the given value of IMSI or QCI and so then particular PDT is applied. 
  For Example: In CCR (Init), PCRF receive IMSI 122334455667001. Based upon this IMSI, PCRF
  has PDT configured in which PCRF applies two PCC Rules let suppose PCC1 and PCC2.
 
  Upon getting successfull PDT matched PCRF sends successfull CCA (Init) to PGW.
  Now, upon getting of successfull CCA (Init) PGW sends CCR (Update) to confirm the PCRF that  
  the Rule is applied  successfully on the particular bearer (in this case default bearer) and also
  inform the ip address of the UE.Then PCRF acknowlege with CCA(Update) success.

  Now PGW has already applied the Rule(Qos,filters,MBR,GBR etc) received from PCRF to
  the requested bearer, it sends Create Session Response to SGW and then the Default session created
  successfully.
 
Similar Procedure follows for dedicated bearer also.
  In dedicated bearer creation/updation/deletion, PGW sends CCR Update to PCRF.PCRF 
  acknowledge the request with CCA Update.
 

Note: CCR (Init) send by PGW only once for a UE session i.e on default bearer creation. 

Closed Subscriber Group in lte (CSG)

         LTE - Closed Subscriber Group (CSG)

 

Closed Subscriber Group identifies a group of subscribers who are permitted to access one or more CSG cells of the PLMN.

 

To make a CSG call UE should send CSG Id to which it belongs and its access type in Attach request.

 

MME then performs UE authentication with the HSS and then exchanges Update Location Request and Answer. In Update Location Answer HSS sends CSG Information(CSG Id, Subscription timer) in Subscription data.

MME then verifies the CSG Id with the CSG received in Attach request if it matches then UE proceed the CSG call and sends Create session request with CSG Information IE to SGW. Upon receiving of successful response from SGW, MME sends Attach Accept message with Member status as ‘member’. After expiry of the Subscription timer for which UE is subscribed to attach with CSG cell, MME initiate PDN connection deletion.

 

What if CSG Id receive in Attach Request is not same as received in Subscription Data from HSS?

MME still make a successful call but for the specific time(300 sec) and send Attach Accept message to UE with Member status as ‘non-member’.

After expiry of non-member timer MME initiates PDN Connection deletion.




 

lte Emergency Call Secrets

                                      LTE - Emergency Call Secrets:

          Dial Emergency numbers like 112,999,111 etc.
          Known Emergency numbers are already stored in the USIM/UE.
       
          MME can also provide the Emergency number List in Attach accept or TAU accept.
       
          If Emergency number list is provided by the MME, it is stored in the USIM and when the user initiate a call            to one of the number provided in the list then UE treat it as a Emergency number and initiate Attach procedure with Type Emergency_attach.

1. Default Emergency APN should be configured in MME in case where UE does not send APN in attach request and also HSS does not provide it in Subscription data for Emergency attached UE or Authentication is optional. In that case MME provides its default APN and Qos and procced the emergency call.

2. MME rejects the emergency call when APN received from UE is not configured in MME      Emergency APN list.

3. MME rejects the emergency call only when HSS sends Authentication failure with cause ‘IMSI unknown’ in case of MME is configured to contact the HSS. For all other authentication failure cause MME proceed with the call successfully.

4. When a UE attached normally(non-emergency) with the Lte network it can also calls for emergency services by sending PDN connectivity request with request type emergency.

5. UE can not create two emergency default bearers. It can be one default and other is dedicated.

6. UE can create any no. of dedicated bearer with emergency default bearer but the ARP(Qos) value should be same for all the bearers and the IMSI authentication is mandatory.

7. Bearer modification is not possible for emergency bearers.

8. If any one of the attach type or the request type in Attach Request is non-emergency then call is considered as normal call(non-emergency call).

9. Once the call is completed UE need not to detach. As soon as UE goes into idle mode, MME automatically release the call.

To know about MME configuration for Emegency Click  MME EmergencyConfiguration Data

IMS Emergency Call in LTE Network

                                   

    LTE : IMS Emergency Call in LTE Network

 

Emergency service is provided to the Lte enabled UE in the following situations:

1. User calls an emergency number.
2. UE is in the state where network is not available to serve the UE.
3. User can make IMS emergency call even if does not have a SIM card.
4. UE is in limited service state i.e limited service state where UE is not allowed to call or roam.

-         To make an IMS Emergency call, UE sends Attach type as Emergency attach and request type as Emergency in Attach Request.

-         MME(Lte Network) should be configured with the Emergency support enabled otherwise MME rejects the emergency call.

-         Following are the various configurations in MME according to which MME proceeds the Emergency call.

 

Emergency Type      

             · IMSI Authentication mandatory: Emergency call is successful only when

               IMSI comes in Attach Request and Authentication from HSS

               should be successfully done for this IMSI.

             · IMSI Mandatory Authentication optional: Emergency call is successful

                only when IMSI comes in Attach Request and Authentication from HSS

                needs not to be successfully done.In case authentication fails, network keeps
                tracking of that IMSI's that are unauthenticated.

             · IMSI Optional IMEI mandatory: In this case UE is identified in the network

               by its IMEI only.UE may or may not send IMSI in Attach Request. If UE sends IMSI
               it is not neccassary be authenticated. 

             · Emergency not supported.

Emergency APN

         That is needed to identify the PGW for emergency call.

Emergency QoS

               That is required by the MME only when the UE authentication is optional.

               Otherwise HSS sends it in Subscription Data.

 

 

For Emergency call secrets Click on  Emergency_Secrets

 

     

 

 

 

 

Tear Down indication in Gtpv1 (Teardown Ind)

Tear Down indication in Gtpv1 (Teardown Ind)

As you have seen a parameter named teardown Ind in Delete PDPContext GTP message from SGSN to GGSN. This parameter has a great significance in Deleting already existed PDP Contexts.

Teardown Indication IE has only two possible values 0 and 1.

For deleting existing PDP Context , there are 4 different scenarios where tear down indicator IE plays its role :

1.       If 1, then all the PDP Context that share same PDP address ( UE is allocated an IP/PDP address, say 70.70.70.1 for primary PDP context  and secondary PDP context linked with this primary PDP context has same IP/PDP address) is deleted.

Example:  If secondary PDP context is deleted with tear down set to 1 then with secondary PDP context as well as primary PDP context  gets deleted and vice versa.

2.       If 0, then only PDP context identified by NSAPI (bearer-ID) in Delete PDP Context gets deleted not all PDP context linked with the same UE/PDP address.

Note: If primary context is deleted with tear down indication to zero then primary PDP context  gets deleted and secondary context linked if any, with this primary PDP context  gets the primary PDP context role.

3.       If not mentioned any value for tear down indication then PDP context identified by NSAPI (bearer-ID) in Delete PDP Context gets deleted not all PDP context linked with the same UE/PDP address.

4.       If 0 or no value, and only primary PDP Context is activated/available, then GGSN ignore the Delete PDP Context message and discard.