[Nexus 5 Q&A, Help & Troubleshooting] j'vai:
what exactly is this Mobile Terminated Roaming Retry (MTRR) ?

**CSFB – MTRR**

"Circuit Switched Fall Back – aka, CSFB is the preferred choice of many operators around the world to handle voice calls in LTE environment – not forever, but at least for the start. LTE is an all IP network and voice has been traditionally carried by carriers in TDM environment and hence the need. Till the time all IP technologies evolve to handle all of the existing services offered by voice carriers, as well as brand new innovative voice based products – economically as well as ecologically fitting in the network environment, CSFB is expected to fill in the gap.

So what is CSFB? Simply stated – voice calls are handed over (fallback) to overlay 3G/2G environment instead of handling them in LTE. As could be expected, therefore, an interface needs to be extended between the “All IP” core network of LTE to “TDM world” of CS domain i.e., between MME and MSC an interface called SGs which employs use of SGs Application Part protocol to help in coordinating any Voice, SMS and CS related Supplementary Services call functions.

In a CSFB environment, 2 important concepts are employed viz., Mobile Terminating Roaming Retry, Mobile terminating roaming forward. We will discuss MTRR in this blog. In a typical operator environment, voice coverage for the entire geographical area is achieved by employing many MSC’s. These MSC’s may be a mix of Legacy MSC (where upgrading is difficult/impossible) and next generation Softswitch MSC’s. In order to support CSFB, the MSC needs to be upgraded to support SGs interface, so the issue is how do we support CSFB when the UE is in Legacy MSC coverage. This is where MTRR helps in call delivery to Legacy MSC that does not support SGs.

MTRR is employed when the call is routed via GMSC. A GMSC that supports MTRR has the additional ability to anchor the call till repeated attempts are made to successfully terminate the call. Towards this end, GMSC supports the MAP function called Resume Call Handling (RCH). Let us see how these functions help in delivering CS call to a subscriber located in an LTE coverage area and overlapping with Legacy MSC coverage.

Let us assume that GMSC receives request for incoming mobile call termination to the UE.

•GMSC learns about location of the UE through (1) MAP SRI query to HLR, including in this case, some unique call indicator parameters viz., MT Roaming Retry. HLR, on account of UE’s earlier registration (combined attach) identifies MSC 1 as the current location, to which it forwards (2) the PRN query with MTRR. The MTRR and Call Reference Number helps MSC 1 to understand that the GMSC supports RCH function.

•GMSC forwards the (3) ISUP IAM accordingly to MSC 1 for call termination.

•On receipt of this IAM, MSC 1 initiates (4) paging procedure through SGs interface indicating to MME about an incoming MT CS call.

•Paging causes UE to fallback to the umbrella CS coverage employing either “Handover” or “Redirection” procedure to acquire the overlay RAT. In our case, the UE finds itself currently located in LAI = 2 which is in the coverage region of MSC 2, where it needs to do Location Update before receiving the pending call. The UE understands this procedure is likely to delay call delivery, hence includes a special flag called CSMT in (5) LAU message to MSC 2.

Upon receipt of LAU from this UE, MSC 2 understands that there is an impending CS mobile termination call attempt. MSC 2 takes upon this cue and maintains the signalling link with UE for a longer duration, while awaiting incoming IAM.

•MSC 2 follows the regular procedure to (6) update location with HLR, the HLR being compliant to MTRR procedure (as noted earlier), would ensure (7) Cancel Location is sent to MSC 1.

•MSC 1 understands that there is a pending call delivery to this UE – triggering it to return this call back to GMSC through (8) Resume Call Handling MAP procedure. RCH procedure would convey MTRR parameter as well as the original Call Reference Number back to GMSC.

•GMSC acknowledges MSC 1 and requests HLR to (9) locate the subscriber – this time without MTRR – so as to avoid looping of the call. Also GMSC sets the SRI RR timer to a higher value than a normal value to ensure LU procedure is completed in HLR successfully.

•HLR also holds on to (10) the PRN till the time LU from MSC 2 is successfully completed. Subsequently, MSRN is returned by MSC 2 to GMSC as a result of this SRI query.

•Now the GMSC has MSRN towards MSC 2 and therefore forwards (11) IAM to new MSC. This results in regular call termination to mobile subscriber.

The MTRR procedure – as is evident – would result in increase in call setup time, but ensures the CS call is successfully delivered even though the subscriber was connected with LTE E-UTRAN and located in un-upgradeable (and sometimes cost ineffective) Legacy MSC footprint."

................

this is what current single chip phones have to deal with on sprint's un-finished network vision patchwork, bouncing from site to site;

bugs come up in real world usage away from the lab, yes, but they just don't appear out of nothing, *something* triggers them alive..

just like computers, no1's at the mercy of a network anomily, by being powerless at the hardware / software / client side..

it's simply digging deeper to understand what exactly is going on..

a simple, network toggle.. could be a migitation.