LTE CSFB performance in a live network

A lot has been written about LTE and the issues with supporting voice services. Now that the dust has settled it is clear that initially CSFB (Circuit Switched Fall Back) will be used and once some maturity has been reached in networks and devices, VoLTE (Voice over LTE) will be introduced. My personal opinion is that this will be sometime towards the end of 2012 (the soonest) but most probably in 2013.

CSFB has been the victim of a lot of bad press and one of the main drawbacks of the solution is the additional voice setup delay is causes while the UE has to "fallback" to UMTS/GSM (or even CDMA2000 1x) to establish the CS call.

I recently obtained some logs from a network that supports CSFB and I therefore thought it would be interesting to quantify exactly what sort of delays we are taking about.

First of all though, a very quick overview of CSFB. From a network perspective, a new interface is introduced between the MME and the MSC Server/VLR. This is is called SGs and is very similar to the "old" Gs interface that was defined in the specs quite a few years back to enable an SGSN to communicate with an MSC.

When a UE that supports CSFB performs a registration on the LTE network it will do so with a combined Tracking Area Update/Location Area Update. The MME will process the Tracking Area Update itself and forward the Location Area Update to the MSC Server/VLR via the SGs interface. The VLR will process this Location Area Update as normal by updating the HLR.

Now when a MT call arrives for the UE in question, the MSC Server will send the paging message via the SGs to the MME which will forward it to the UE. The UE responds with an Extended Service Request that triggers the MME to instruct the UE to perform a CSFB (which essentially is a blind re-direction) to UMTS/other. Once there the UE has to read the system information messages and initiate the call as normal.

With that quick introduction, let's have a look at a log extract and especially the timestamps associated with each part of the procedure.

- at 01:27:40.218 the UE receives a paging message which indicates that it originates from the CS core network (IE  cn-Domain : cs)

- this triggers the EMM layer to send an Extended Service Request (IE Service Type Value : (1) mobile terminating CS fallback or 1xCS fallback) to the RRC layer which initiates the RRC connection establishment procedure

- once the RRC connection is established the mandatory security procedures are performed followed by a UE capability enquiry and a RRC Connection Reconfiguration that configures the measurement events and establishes the DRB

- once the above are completed the message that triggers the CSFB is sent which is just a RRC Connection Release with re-direction information instructing the UE to go UMTS (IE RedirectedCarrierInfo : utra-FDD). Time elapsed up to this point is 01:27:40.421 - 01:27:40.218 = 203ms


- the UE then takes a further 01:27:40:671 - 01:27:40.421 = 250ms to detect and synchronise with the UMTS cell

- the UE then reads the system information messages on the UMTS cell which takes 01:27:40:984 - 01:27:40:671 = 313ms


- from here on the UE responds to the paging message as it would have if it was on UMTS in the first place. This means an RRC connection is established, followed by a paging response and the typical CS call set-up signalling flow.

The Alerting message is then received, 01:27:43:625 - 01:27:40:218 = 3s and 407ms after the paging message was sent on LTE.

For those people familiar with measuring call setup delays, 3s 407ms is a pretty good time and quite a few networks would be hard to achieve this natively in UMTS.

Even though this is just one example of a CSFB MT call, it clearly shows that call set-up delay is not impacted that much by CSFB. The delay purely associated with CSFB is only (203ms + 250ms) 453ms.


It is also worth noting that in the rel9 version of the specs, the UE can be sent the System Information associated with the target cell in the redirection message which will speed up the process even more.

A final point to make is  that SMS is supported over the SGs interface so there is no need for CSFB to send or receive text messages.