LTE carries packets and nothing else, so it has no circuit switched domain of its own. CS fallback answers that by moving the UE to GERAN or UTRAN for the length of the call. The move costs setup time. Most of this page is about what has to be in place before it can happen at all.

• Network Architecture for CS Fallback
• Triggers of CSFB - When to perform CSFB
• Example Procedure of CSFB
• Reference

Network Architecture for CS Fallback

Two core networks have to agree about one subscriber before any call can fall back. The agreement rests on a single interface. The drawing further down shows where it sits. Everything else in it is an ordinary EPS or 2G/3G element.

Basically LTE is a Packet only technology. It is well designed for data traffic. Then what about Voice call ? This has normally done via CS call in existing technology (WCDMA, GSM, C2K etc). There can be a couple of options to achieve voice call in LTE. One of the option is just to use packet based voice call (e.g, VoIP or IMS). Another option is to use multiple technology. For example, if UE wants to have packet communication, the network redirect it to the normal LTE core network and if UE wants to do voice call the network redirect the call to one of the existing technology like WCDMA, GSM or C2K. This technology that enables to redirect connection to other technology (e.g, WCDMA, GSM, C2K) is called 'CS Fallback'.

It may sound very simple and usefull... but it is not that simple as you think. First, UE should support multiple technologies and network side would be even more complicated. One of the simplest representation on network side would be as follows. As you may guess, there should be some link point between LTE network and 2G/3G network to make this CS fallback happen. In this case, the connection point is between MSC and MME and the interface connecting these two entities are called 'SGs' interface.

The picture is two complete networks with one link between them. The dashed line down the middle separates the radio side from the core side. Only one line in the drawing exists because of CS fallback.

• The UE reaches three radios : BTS for GSM, NodeB for UMTS and eNodeB for LTE, each on its own dashed link.
• The 2G and 3G radios share two core nodes : BSC and RNC both reach the MSC for circuit switched traffic. Both reach the SGSN for packet traffic.
• The LTE radio leads to two nodes as well : the MME for signalling and the SGW for user traffic. The PGW and the IP cloud sit past the SGW.
• The thick red line is the whole of CS fallback : it joins the MME to the MSC. The box sitting on it is labelled SGs.
• SGs is a reference point, not a node : 23.272 places it between the MME and the MSC server. Nothing new is deployed to make it exist.
• Nothing else in the picture is new : every other element is already there for LTE or for 2G and 3G on its own.

Now LTE and 2G/3G network is connected. Now let's look into the interplay of the two networks to make the voice call possible. I think these interplay can be explained by adding just three lines as follows.

The same architecture carries three coloured paths, and each one does a different job. Two of them run over LTE. Only the third runs over 2G or 3G.

• The legend names all three : Voice Call Traffic Path in red, Registration to CS Network Path in blue, and Paging Path in green.
• The blue path registers the UE with the MSC : it runs from the UE through the eNodeB to the MME. From there it reaches the MSC over SGs. The UE is still on LTE throughout.
• That registration is the combined EPS/IMSI attach : without it, 23.272 never lets the UE ask for CS fallback.
• The green path carries the paging : it starts at the MSC and crosses SGs to the MME. From there it reaches the UE through the eNodeB.
• The paging says which domain is calling : the MME sets a CN Domain Indicator of CS in the paging it sends to each eNodeB.
• The red path is the call itself : it runs from the UE through the NodeB and the RNC to the MSC. No part of it touches LTE.
• Only the red path needs the UE to leave LTE : the other two finish while the UE is still on E-UTRAN.

Is this everything make CS Fallback happen ? Definately not. There is some difference in terms of signaling protocol between LTE and 2G/3G. To make these two different protocol work together would not be that simple. To make this happen, LTE network should have a certain level of understanding (compatibility) with 2G/3G protocol and 2G/3G network shouldhave a certain level of understanding LTE protocol.

It is not the scope of this short section to describe the whole details of 'CS Fallback' protocol side. So just keep it mind that it would be pretty complicated process and try to google some of articles.  

Three statements about that interface matter later on, and 23.272 makes all three. SGs runs between the MME and the MSC server. Its procedures come from the Gs interface that already joined the SGSN to the MSC. It carries mobility management and paging, and it carries SMS in both directions as well. CS fallback itself works only where E-UTRAN coverage is overlapped by GERAN or UTRAN coverage.

• SMS over SGs is not CS fallback : the messages cross the same interface. Nothing falls back to 2G or 3G to deliver them.
• The two features are not a pair : SMS over SGs is mandatory for anything that does CS fallback. The reverse does not hold.
• Overlapping coverage is a hard requirement : with no GERAN or UTRAN cell under the LTE one, there is nowhere to fall back to.
• One PLMN picks one target : fallback goes either to UTRAN and GERAN or to CDMA 1xRTT. The UE may support both, and the network still picks one.

Triggers of CSFB - When to perform CSFB

A voice call on an LTE device can be carried two ways. The UE picks one of them at the start of every call. That choice is domain selection, and 23.272 hands the rules for it to 23.221. Each situation below is a case where the choice comes out as the CS domain.

Followings are the list of situation where UE initiate CSFB. These are not the full list of those situations, but can be most common situations (triggers) for CSCF.

i) UE is not capable of VoLTE and is registered (or in communication) with LTE network. User make voice call (MO Call)

ii) UE is not capable of VoLTE and is registered (or in communication) with LTE network. UE recieves a Paging message for voice call (MT Call)

iii) UE is capable of VoLTE, but ims PDN is not established (UE is not registered in CSCF). User make voice call (MO Call)

iv) UE is capable of VoLTE, but ims PDN is not established (UE is not registered in CSCF). UE recieves a Paging message for voice call (MT Call)

v) UE is capable of VoLTE, ims PDN is established and UE is registered in CSCF, but Network notifies 'VoLTE not supported' in NAS message.

vi) UE is capable of VoLTE, ims PDN is established but UE failed to register in CSCF. User make voice call (MO Call)

vii) UE is capable of VoLTE, ims PDN is established but UE failed to register in CSCF. UE recieves a Paging message for voice call (MT Call)

viii) UE is capable of VoLTE, ims PDN is established and UE is registered in CSCF but SIP INVITE for VoLTE failed to go through (e.g, getting some error or reject code right after SIP INVITE)

• The eight sort into four groups : no VoLTE capability, no IMS PDN, a network that says no, and an IMS attempt that failed.
• Items i and ii are the plain case : the UE cannot do VoLTE, so nothing else needs examining.
• Items iii and iv turn on the IMS PDN : the capability is present and the connection that would carry the call is not.
• Item v is the network's decision : the IMS voice over PS session indicator sits in the EPS network feature support IE. 24.301 has the UE pass it up for domain selection.
• Items vi to viii are failures rather than states : the call falls back after an attempt instead of before one.
• The list is split between the two call directions : four items start with the user dialling, three start with a paging message. Item v is a standing indication rather than an event.
• None of them works without a combined attach : the UE sends its fallback request only when it is attached to the CS domain.
• The network can take the option away : an Attach Accept marked SMS-only leaves SGs carrying messages and nothing else.

Example Procedure of CSFB

A worked example is easier to follow once the shape of the procedure is known. Every variant starts with the same NAS message and ends in the same place. What differs between them is only how the UE is carried across to the other radio.

If you are interested in any practical example of CsFB to the level of RRC/NAS message, refer to CSFB (LTE-->WCDMA) section of Handover page.

There are several different ways to implement CSFB (CS Fallback) and one of the most common way is to use 'Redirection' method. For the details of 'Redirection' mechanism, refer to 'Redirection' section.

23.272 splits the procedure by two questions. The first is whether the call is originating or terminating, which separates clause 6 from clause 7. The second is whether PS handover is supported, which decides how the UE crosses to the other radio. The table below lists the four ways that crossing is done.

• The eNodeB chooses the method : the MME only says that the UE should be moved. It says so with a CS Fallback Indicator in the S1AP message.
• A measurement report is optional in every variant : the eNodeB may ask for one first to settle which target cell to use.
• Redirection needs the least support : 23.272 reaches step 3b when neither PS handover nor cell change order is supported. It also applies when the network prefers not to use them.
• Only PS handover carries the packet session across : the other three release the connection first. The EPS service is resumed after the CS service ends.
• Coming back needs no new mechanism : 23.272 says the existing ones move the UE to E-UTRAN once the call is over.

The originating case starts at the UE and needs no paging at all. Its first two messages are the ones to look for in a log. They are what makes an ordinary service request a fallback request.

• Step 1a is an Extended Service Request : the UE sends it for mobile originating CS fallback, carried inside RRC and then S1AP.
• The UE sends it only when it is attached to the CS domain : the combined EPS/IMSI attach is what makes that true. That is why the blue path in the picture above comes first.
• Step 1b carries the decision to the eNodeB : the MME sends an S1AP UE Context Modification Request. It holds a CS Fallback Indicator and the LAI.
• Idle mode renames two messages and changes nothing else : the UE Context Modification pair becomes the Initial UE Context pair. The LAI travels in the request.

The terminating case starts in the CS core instead, and it reaches the UE through two separate paging steps. The green path in the picture above is the first of them.

• The MSC pages over SGs : the Paging Request carries the IMSI, the VLR TMSI and location information. The MME uses the IMSI to find the S-TMSI.
• The MME then pages the eNodeBs : it covers every tracking area it holds for the UE. The CN Domain Indicator is set to CS.
• The UE answers with the message the originating case also uses : an Extended Service Request, this time for mobile terminating CS fallback.
• That answer stops the MSC repeating itself : the MME sends an SGs Service Request, and the MSC ends its paging retransmission.
• The MSC owns the paging timers : 23.272 tells the MME not to retransmit the paging itself.

Reference

The first entry below is the author's. The two specifications after it are the ones this page was checked against, in the versions named.

[1] http://lteworld.org/blog/understanding-cs-fallback-lte

[2] 23.272 : 3GPP - Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2, v20.0.0. The source of the SGs description, the trigger preconditions and every procedure step named on this page.

[3] 24.301 : 3GPP - Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3, v20.0.0. Clause 9.9.3.12A holds the EPS network feature support IE, where the IMS voice over PS session indicator sits.