the reason why i ask is because i wanted to put a solution that worked for me to the test:
before, i noticed the phone app would freeze on incoming calls while parked on lte, the only way of it of the freeze, was a reboot..
selecting 3g, no issue but no lte..
back on lte, more freezing..
under settings in MOBILE NETWORKS then SYSTEM SELECT then toggling to AUTOMATIC
seemed to clear the issue, (for me)
but i wondered why?
i know of the e.csfb issue on sprint network with single chip phones that don't support svtle, having one voice / data path, & how ehrpd plays in bridging cdma hand-offs to & from lte parking semmlessly;
but why did switching to AUTOMATIC in system select, seemed towork for me between sites that are mixed between upgraded non upgrade network vision?
my suspicions is that when ehrpd is utilized, it invokes a roaming type hand-off in-channel, yes it's explain for evdo to lte, but evdo is technically, cdma also, is why it worked..
here's some of the reading i did to wrap my heading around the issue -
http://www.slideshare.net/abpreen/cdma-ho-design
&
Multi-RAT Heterogeneous
Networks (PDF)
also - EHRPD Integrates EV-DO & LTE Networks (PDF)
reaching out to an inquisitive community to seek an answer..
does this toggling *migitate* the negative effect of the e.csfb issue on sprint with newer single chip qualcomm phones?
i need help y'all
what i'm asking, is that if anyone is having issues like the phone app freezing on imcoming calls while parked in lte, while on certain sites, to try this, see it they can get underneath what's actually happening..
i test called myself umpteen times after this setting, & suffered nary phone app freezing, switched back to lte it would sporatically freeze on imcoming calls, in which i couldn't answer the call, the phone app would stay in the ringing state long after the calling party hung up,
a reboot was the only way out of it..
j'vai said:
what i'm asking, is that if anyone is having issues like the phone app freezing on imcoming calls while parked in lte, while on certain sites, to try this, see it they can get underneath what's actually happening..
i test called myself umpteen times after this setting, & suffered nary phone app freezing, switched back to lte it would sporatically freeze on imcoming calls, in which i couldn't answer the call, the phone app would stay in the ringing state long after the calling party hung up,
a reboot was the only way out of it..
Click to expand...
Click to collapse
~correction~
test called myself umpteen times after this setting, & suffered nary phone app freezing, switched back to **AUTOMATIC** from home only in **system select** (change cdma roaming mode), it would sporatically freeze on incoming calls, in which i couldn't answer the call, the phone app would stay in the ringing state long after the calling party hung up,
hate to burst your bubble but a freeze on the phone apk doesnt really have to do with the e/csfb issue . sounds more like a software issue with your phone.
here is a good read for you
http://s4gru.com/index.php?/blog/1/...-due-to-circuit-switched-fallback-technology/
jcwxguy said:
hate to burst your bubble but a freeze on the phone apk doesnt really have to do with the e/csfb issue . sounds more like a software issue with your phone.
here is a good read for you
Click to expand...
Click to collapse
no bubbles burst..
points:
you typed: "..sounds more like a software issue with your phone..."
when i sought people who may have actually had the issue to apply it & try, not just, throw what they FELT it was out there w/o practical application, (that's why i came here in xda)
here - "..but a freeze on the phone apk doesnt really have to do with the e/csfb issue . sounds more like a software issue with your phone. "
is what i want to nail down, i can't post links (new member) but narrowing down a google search on nexus 5 google dialer freeze for the nexus 5 leads to a google trouble shooting thread which stalemates unresolved, up to the date jan 9...
you know what they all had in common? they mostly were using cdma networks;
shucks, i even found from that search, a thread from here -
Tried a factory reset and was still having problems with the dialer. Then I went into the mobile data settings and set it to auto roam, I have sprint so I did not select sprint home only. I also set it to accept roaming and kept the network mode to global. I had changed that to LTE before and also have the roaming network set to Sprint only. Now that I changed these settings I can receive calls and sail out without any problems even with my music player on. Hope this helps.
Sent from my Nexus 5 using XDA Premium 4 mobile app - cjrivera04 18th November 2013, 11:52 PM from Nexus 5 phone dialer buggy?
pretty much the same practical application!
i have a global international truphone sim card & tested it to envoke the freeze, there are no similiar setting to toggle, the truphone sim, uses tmobile's network here in the states, & the google dialer freeze never happens on the gsm side ..
so what proof is there that a freeze on the phone apk doesnt really have to do with the e/csfb issue ..?
i wish i had several nexus 5s in my possession to test in unison, but i don't i only had mine, i wish i could walk up to some1 who had a sprint nexus 5 & drum up a freindly chat, to talk of the issues to help troubleshoot, but i haven't seem anyone in dc with one..
i don't know why you posted the s4gur blog, ( i already stated i knew of the e.csfb issue) it was because i read that blog 1st,
which THEN, led me to delve deeper into the setting when having the dialer freeze issues, which in turn, wanted me to join that site, to post my results & be a part of that.. *community*..
i expounded on that moreso on that site, & was looking for it to mature into something of the nature of:
someone saying; "ok, well let's see, where where you having those issues let's narrow it down to what cell sites you were connected to & whether they were non nv, nv, or both to find some corrolation"
or / and; "there are others who have experienced this, let's narrow down to see if it's a combination of how this handset interacts with the network while processing incoming calls over other markets in the same settings, etc"
this was in febuary, my very 1st post ( in that blog talking of my steps in detail is now erased, or hidden i'm told because it had nothing to do with the blog)..
~shrugs shoulders~
i set the standard high at face value going into any place, & let them paint the finishing picture..
there, i was told, that there was NOTHING one could do to migitate the e.csfb issue from the handset side, "it is was it is"
& not saying they are related (don't go one deminsional on me)
here, i see nexus 5s accessing band 41 & 26 prior to an official patch to unleash a feature the phone was capable of the the start..
freimal have
1 △ ▽
•
<Reply
•
⥅Share ›
−
⚑
Avatar
kamiller42 • 2 months ago
Using Sprint here in an LTE environment, so it's using CFSB. When a call comes in, I can see the Nexus receiving the signal, LTE goes off, but the Nexus does not respond.
I am so glad a major Android news source is publicizing this. Thanks AP! It is a very annoying bug. I'm missing calls from clients. I am not pleased.
that's from one source (but where i stand corrected, is that cal symtoms are sporatic regardless of carrier network, they are mostly sprint, tmobile) from - bug-watch-nexus-5-can-randomly-stop-receiving-calls-and-text-messages-for-some
remember when i typed -
"under settings in MOBILE NETWORKS then SYSTEM SELECT then toggling to AUTOMATIC
seemed to clear the issue, (for me)
but i wondered why?
i know of the e.csfb issue on sprint network with single chip phones that don't support svtle, having one voice / data path, & how ehrpd plays in bridging cdma hand-offs to & from lte parking semmlessly;
but why did switching to AUTOMATIC in system select, seemed towork for me between sites that are mixed between upgraded non upgrade network vision?
my suspicions is that when ehrpd is utilized, it invokes a roaming type hand-off in-channel, yes it's explain for evdo to lte, but evdo is technically, cdma also, is why it worked.."
i found an excellent read from a qualcomm paper -
file:///tmp/circuit-switched-fallback-the-first-phase-of-voice-evolution-for-mobile-lte-devices.pdf
Conclusions
CSFB is the first step in enabling mainstream LTE
handsets with the cost, size and battery life advantages
of single-radio solutions to LTE data in combination with
2G/3G voice (and data fallback, in non-LTE areas).
The single-radio solution is also the pathway to later
phases of LTE voice evolution that add additional operator
network capacity gains and user experience enhancements.
CSFB network upgrades provide a first step towards
VoLTE with SRVCC, the next phase of LTE voice evolution.
Even as VoLTE is initially launched, VoLTE handsets will
continue to require CSFB for roaming.
While several options are available to address the call setup
time and reliability issues introduced by the single-radio
solution, the evidence gathered to date suggests the fol-
lowing as solutions for handsets and supporting network
infrastructure in the current phase of LTE evolution:
• Redirection-based CSFB using Release 9 SI Tunneling,
for both 3G and 2G. The measured sub-second call setup
penalties should fall within the range of legacy user
experience, and can be improved (for incoming calls) with
DRX paging cycle optimization. The slight call setup time
advantage of handover-based CSFB for 3G does not appear
to justify its deficiencies relative to call setup reliability
under changing IRAT conditions.
• MSC Pool architecture, in combination with MT
Roaming Forwarding, to deliver satisfactory call setup
times and success rates across the broadest range of
network conditions.
i suspect when the google dialer froze on incoming calls, it came from the worse case scenario here ( it didn't happen all the tyme, but sporatically) -
Call setup reliability
Another key issue for the voice call user experience is call
setup reliability—the ability to successfully establish an
incoming or outgoing call on the first attempt, or within
a time frame that doesn’t indicate call setup failure. The
target is to at least match legacy performance, which is
in the 98% range.
With CSFB switching between LTE and 3G networks, there
are two primary challenges to call setup success: changes
in IRAT conditions between measurement and acquisition
(for handover-based CSFB), and mismatches between
LTE and 3G geographic signal coverage areas that require
server-side updates.
Changing IRAT conditions for handover-based CSFB
With handover-based CSFB, IRAT measurements can
change between the time the measurement is taken using
LTE and the time 3G voice network acquisition is attempted.
In that time, the cell identified and prepared for handover
may become unavailable, resulting in connection failure,
as visualized in Figure 10.
In handover-based CSFB, the measurement is performed
before—on average of 0.3 seconds before, as shown in
Figures 7 and 8 above—the IRAT transition. If the IRAT
conditions change negatively, there is a higher probability
of handover failure, especially in high mobility situations.
Historical experience has already shown somewhat
higher failure rates with inter-frequency handover or
IRAT handover (e.g. 3G to 2G), suggesting that delays
between IRAT measurement and network acquisition
can increase setup failures.
In contrast, redirection-based CSFB can be expected to
deliver higher call setup reliability than handover-based
CSFB, simply because redirection-based CSFB takes the
IRAT measurement immediately before attempting access
on the identified cell. Since the Release 9 SI Tunneling
and Release 8 Skip SIBs redirection-based CSFB methods
have only slightly higher call setup times, their higher call
setup reliability has guided the general industry trend to
rely on redirection-based CSFB approaches.
The reliability of redirection-based CSFB call setup has
been tested using device traces in field testing on live 3G
networks, and no call setup failures were observed out
of more than 160 calls, covering both good and bad RF
conditions for redirection-based CSFB to UMTS. These
results point to call setup reliability on par with legacy call
setup reliability. Similar traces collected on the network
side showed redirection-based CSFB reliability in the 99%
range, on par with UMTS legacy performance. Test data
for handover-based CSFB reliability has not yet become
available, due to its limited use to date.
....
the dialer app froze on totally different parts of town in my home in the suburbs, & inner city at work, i know not the particulars of the kind of sprint sites i was connected to ( was hoping to get that help from s4gur), allowing automatic in system select migitated the dialer freeze on incoming calls, to nil..
Mobile Terminated Roaming Forwarding for LTE CSFB
"As described in a previous post one of the issues with LTE CSFB is what happens when the UE falls back to the target RAT but the the LA is not same as the one the UE is registered in during the combined attach procedure. This typically occurs on the borders of Location Areas (LA) and Tracking Areas (TA) or when the target layer is 3G and the UE can only acquire 2G (e.g. indoors).
In order to avoid MT call setup failures, operators must implement either MTRR (Mobile Terminating Roaming Retry) described here or MTRF (Mobile Terminating Roaming Forwarding) which will be described in this post.
The signalling flow for MTRF is shown above (click to enlarge) and essentially consists of 3 phases.
Phase 1 and phase 2 are identical to the MTRR signalling flow, with the exception that the network elements involved must support MTRF and signal as such with the applicable IE (MTRF Supported) defined in the specs.
In phase 3 however rather than cancelling the call setup procedure and re-initiating it towards the "new" MSC like MTRR, with MTRF the old MSC is used as a relay and the call setup procedure continues with an additional PRN & IAM procedure.
So essentially MTRF manages to cut down the signalling flow and the whole MT procedure completes in 3 phases as opposed to 4. This results in a reduced call setup delay and as such better customer experience.
In the final post on the subject I will describe the IWF solution which overcomes the problem of misaligned LA & TA (and a number of other issues) with the inclusion of an additional core network element. "
"One of the many issues with LTE Circuit Switched Fall Back (CSFB) is what happens when the UE falls back on the target RAT (can be 3G or 2G, operator defined) and the LAC is not the same as the one the UE is registered on through the Combined Attach procedure in LTE. This typically occurs on the borders of Location Areas (LA) and Tracking Areas (TA) or when the target layer is 3G and the UE can only acquire 2G (e.g. indoors).
In these cases, a Mobile Originated CS call would experience a delay as the UE would first have to perform a LAU procedure on the target RAT followed by the subsequent call setup procedure.
A Mobile Terminated CS call on the other hand would fail as the call has already been routed to the "old" MSC (i.e. the one the UE registered on though the Combined Attach procedure) but the UE finds itself in the LAC of a different, "new", MSC.
To prevent this happening two 3GPP defined procedures can be re-used. The first one is called Mobile Terminated Roaming Retry (defined in rel.07) and the second one is called Mobile Terminated Roaming Forwarding (defined in rel.10). Both of these require an upgrade to the CN elements involved in the call setup procedure.
It is interesting to note, that both of these procedures were defined originally to handle the (rare) occasion of a UE being paged in one LA but at the same time moving through a LA border and thus performing a LAU procedure on a different MSC than the one being paged on.
For this post we will have a closer look at the Mobile Terminated Roaming Retry (MTRR) procedure.
The signalling flow is shown above (click to enlarge) and can be broken down into 4 distinct phases.
During phase 1, a MT call comes through the GMSC which initiates the MAP procedures to inform the MSC the UE is registered on (through the Combined Attach procedure). The MSC contacts the MME through the SGs interface which pages the UE. The paging action initiates the CSFB procedure and the UE is directed towards the target RAT.
Under normal circumstances the UE would fall back on the LA it registered on and would send a Paging Response. In this case however the UE falls back on a different LA and thus has to perform a LAU procedure. This is shown in phase 2, as is the subsequent procedure to transfer the UE subscription from the "old" MSC to the "new" one.
This is also where the call setup procedure would fail as the "old" MSC would not have the ability to inform the GSMC that the UE has changed MSCs.
With MTRR however the "old" MSC informs the GMSC through the Resume Call Handling procedure that the call setup procedure should be repeated by contacting the HLR once more. This is shown in phase 3 of the signalling flow.
Finally, phase 4 is a repeat of phase 1, but this time the GMSC contacts the correct "new" MSC and the call setup procedure is successful.
It is also important to note that during the LAU procedure in phase 2, the UE populated an IE indicating that a CS MT call was in progress. This ensures the new "MSC" keeps the signalling link towards the HLR for the subsequent signalling exchange in phase 4.
Obviously this whole procedure would also add a couple of seconds more on the overall call setup time, which due to the general CSFB procedure is already longer that a "native" CS call setup in 2G/3G.
In the next few posts I will look at the second option, MTRF, and also at a completely different approach that uses an inter working function between the MME and MSC in order to avoid any upgrades in the legacy CS network."
any hackers .. following me here on the breakdown? lol
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.
now, i guess it just a matter of narrowing it down to;
what a normal if conditions are perfect csfb set up is -
< Extended service request >
NAS_LTE:EMM,Extended service request
Extended service request ::= DIVISION
+-Security header type ::= V
| +-Security header type ::= CHOICE [Plain NAS message, not security protected]
+-EPS mobility management protocol discriminator ::= V
| +-Protocol discriminator ::= PD [7]
+-Extended service request message identity ::= V
| +-Message type ::= MSG [4C]
+-NAS key set identifier ::= V
| +-TSC ::= CHOICE [native security context (for KSI ASME)]
| +-NAS key set identifier ::= CHOICE [possible values for the NAS key set identifier 0]
+-Service type ::= V
| +-Service type value ::= CHOICE [mobile originating CS fallback or 1xCS fallback]
+-M-TMSI ::= LV
| +-Octet1 ::= DIVISION
| | +-Length of mobile identity contents ::= LEN (0..255) [0]
| +-Octet2 ::= DIVISION
| | +-Identity digit 1 ::= INT (0..15) [0]
| | +-Odd/even indication ::= CHOICE [even number of identity digits and also when the TMSI/P-TMSI is used]
| | +-Type of identity ::= CHOICE [No Identity]
| +-Octet3-Octet6 ::= DIVISION
| +-Identity digit p ::= OCTETARRAY SIZE(0..4)
+-CSFB response ::= TV OPTIONAL:Exist
+-Octet1 ::= DIVISION
+-CSFB response IEI ::= IEI [B-]
+-spare ::= FIX [0]
+-CSFB response value ::= CHOICE [CS fallback accepted by the UE]
< RRC Connection Release >
RRC_LTEL-DCCH-Message
DL-DCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [rrcConnectionRelease]
+-rrcConnectionRelease ::= SEQUENCE
+-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
+-criticalExtensions ::= CHOICE [c1]
+-c1 ::= CHOICE [rrcConnectionRelease-r8]
+-rrcConnectionRelease-r8 ::= SEQUENCE [100]
+-releaseCause ::= ENUMERATED [other]
+-redirectedCarrierInfo ::= CHOICE [cdma2000-1xRTT] OPTIONAL:Exist
| +-cdma2000-1xRTT ::= SEQUENCE
| +-bandClass ::= ENUMERATED [bc2]
| +-arfcn ::= INTEGER (0..2047) [0]
+-idleModeMobilityControlInfo ::= SEQUENCE OPTIONALmit
+-nonCriticalExtension ::= SEQUENCE OPTIONALmit
to network logcats of a nexus 5, set to *home only* vs *automatic* in system select (change the cdma roaming mode), where ever those logcats may be..
CS Fallback Function for Combined LTE and 3G Circuit Switched Services (PDF)
https://www.nttdocomo.co.jp/english/binary/pdf/corporate/technology/rd/technical_journal/bn/vol11_3/vol11_3_013en.pdf
&
http://lteuniversity.com/get_trained/expert_opinion1/b/ramesh2/archive/2013/06/21/csfb-mtrr.aspx
I just tried again, to set the phone to *HOME ONLY* in system select (change the cdma roaming mode), called myself consecutively, after the second successful anser i was like "ooh maybe the issue has been cleared" but the third time, and fourth, the freeze came back, while in this setting..
Mobile Terminating Roaming Retry Call
While doing some background reading I stumbled over the following optional Mobile Terminated Call procedure for a race condition:
The scenario: Just when the mobile network receives an incoming call for a user, the user's mobile changes to a cell which is controlled by a different mobile switching center. This results in a race condition, i.e. the previous MSC receives the call while the mobile is already performing a location update via the new MSC. If this is not treated, the mobile will not see the paging in the old cell and the call establishment fails.
This is where the "Mobile Terminating Roaming Retry Call" feature comes into play: If implemented, the previous MSC which has sent out the paging message to contact the mobile is informed of the location update by a "Cancel Location" message from the HLR. This is standard practice so far. However, instead of failing the paging procedure, e.g. after a timeout, the Cancel Location message is used as a trigger to signal to the Gateway MSC that the subscriber is no longer with this MSC. The Gateway MSC then releases the speech path to the previous MSC, runs another subscriber location search with the Home Location Register and then forwards the call to the new MSC. All quite elegant.
For details see 3GPP TS 23.018, chapter 5.2.1
I wonder, if this feature is widely implemented and used today? If you know, please let me know.
I'm writing an email to a RF Engineer at Sprint Nextel locally here in wash dc, (well actually she's in university of maryland college park) to look at this thread to see if it holds water, we could meet demostrate in person what happens over lunch / dinner whatever...
i wondered if i was conversating over alot of peple's heads in making my case about this;
on another site, it was even asked why did i bring up ehrpd when taking about ecsfb, in relation to sprint's network..
i have to assume, that those who'd ask that, didn't understand the underlying working of sprint's current network, (all it takes is research, one doesn't have to be a rf engineer to understand english, TO connect dots) -
from here A critical examination of CSFB as a solution for providing Voice-on-LTE (PDF)
1st & foremost -
Background to voice-on-LTE
Despite the recent growth of 3G mobile broadband and smartphone appstores, the bulk of cellular industry revenues still come from ordinary telephony. Irrespective of the rapidly-rising volumes of data traffic and the need for more capacity and speed, it is clearly important for operators to retain the ability to deliver a good voice experience, on any new radio network deployment intended for a broad audience.
But unlike previous generations of mobile standards like GSM, LTE does not have dedicated channels for circuit-switched (CS) telephony, instead relying on an end-to-end IP connection from the handset to the core network. Consequently, any form of voice service used on an LTE bearer, by definition, must be some form of VoIP. As far back as 2006 it became obvious that implementing voice telephony was the “elephant in the room” for LTE, but progress on solid and suitable definitions has been glacially-slow. Following a rather panicked flurry of activity, there are now two 3GPP-approved solutions to this problem – VoIMS and CS Fallback - as well as several other non-standardised alternatives.
ok, in a cdma network, this is where ehrpd would come into play, to bridge that, for BOTH voice (1x) & IP (cdma 2000) -
http://http://www.mobilitytechzone.com/topics/4g-wirelessevolution/articles/37366-evolution-options-from-cdma-lte-benefits-ehrpd.htm
This combination aims to enhance the user’s interaction with the network and further drive demand for mobile multimedia services. Furthermore, the LTE evolution calls for a transition to a ‘flat,’ all-IP core network with a simplified architecture and open interfaces. This requirement is defined by the System Architecture Evolution (SAE) — also known as Evolved Packet Core (EPC) — the 3GPP specification for changes to the packet core network architecture.
While GSM/UMTS-based operators have a natural evolution to LTE, many CDMA-based mobile operators also have decided to evolve to the LTE specification. Changes in mobile communications have traditionally been evolutionary, and the deployment of LTE will be the same. The transition for CDMA operators from High Rate Packet Data (HRPD) to LTE will be over a period of several years, as is the case still with the transition from 1xRTT to HRPD. As a result, mobile operators must look for a migration path that will enhance their existing HRPD networks, while addressing LTE deployment requirements and will not require a ‘forklift’ upgrade.
The choice of migration path depends on many factors including radio access strategy, network resource strategy, services enabled, timing and cost. A key goal of LTE is to enhance service provisioning while simplifying interworking with non-3GPP mobile networks. This is essential for CDMA operators that have chosen to migrate to LTE. The following are three basic migration paths to LTE currently available for CDMA operators.
Overlay — In this approach, a complete LTE network is deployed as a second network to the existing HRPD network. However, this will be very expensive, and with an overlay, a subscriber roaming from the HRPD network to the LTE network will experience a loss of continuity for the IP session.
& from the 1st link -
Problems with CSFB
There are numerous drawbacks with the CSFB approach to interim voice and messaging, which Disruptive Analysis believes should prompt operators and standards authorities to look afresh at alternative interim mechanisms. Part of the problem has been that past assessments of the standards have focused mostly on the technical aspects, rather than addressing issues around user experience and behaviour, or impacts on broader application usage and indirect impacts on business models.
The following issues are examined in more details in the next sections of the document:
Additional call set-up latency Requirements on network coverage Side-effects of dropping the data connection during voice calls Impact on data applications, especially on multi-tasking devices Issues relating to SMS support Implementation cost and practicalities Negative impacts on current or potential new LTE business models, eg MVNOs Poor fit with new types of voice application Problematic integration with femtocells
i've read issues, where the newer single chip qualcomm phone (nexus 5 & lg g2 on sprint) would have ither, a strong steady lte signal, but no switch over on voice calls, missing the paging channel altogether, resulting in a voicemail, w/o the phone even ringing..
or vice versa, the phones would park on 3g & stay parked in definately, one would suspect they were in a lte coverage area, & would toggle airplane mode, or reboot, (effectively ripping down the established connection, to rebuild a new one) & getting a strong lte signal!
the older phone with two paths rarely suffered this, regardless of the settings , on home only or automatic, in system select..
j'vai said:
i wondered if i was conversating over alot of peple's heads in making my case about this;
on another site, it was even asked why did i bring up ehrpd when taking about ecsfb, in relation to sprint's network..
i have to assume, that those who'd ask that, didn't understand the underlying working of sprint's current network, (all it takes is research, one doesn't have to be a rf engineer to understand english, TO connect dots) -
from here A critical examination of CSFB as a solution for providing Voice-on-LTE (PDF)
1st & foremost -
Background to voice-on-LTE
Despite the recent growth of 3G mobile broadband and smartphone appstores, the bulk of cellular industry revenues still come from ordinary telephony. Irrespective of the rapidly-rising volumes of data traffic and the need for more capacity and speed, it is clearly important for operators to retain the ability to deliver a good voice experience, on any new radio network deployment intended for a broad audience.
But unlike previous generations of mobile standards like GSM, LTE does not have dedicated channels for circuit-switched (CS) telephony, instead relying on an end-to-end IP connection from the handset to the core network. Consequently, any form of voice service used on an LTE bearer, by definition, must be some form of VoIP. As far back as 2006 it became obvious that implementing voice telephony was the “elephant in the room” for LTE, but progress on solid and suitable definitions has been glacially-slow. Following a rather panicked flurry of activity, there are now two 3GPP-approved solutions to this problem – VoIMS and CS Fallback - as well as several other non-standardised alternatives.
ok, in a cdma network, this is where ehrpd would come into play, to bridge that, for BOTH voice (1x) & IP (cdma 2000) -
http://http://www.mobilitytechzone.com/topics/4g-wirelessevolution/articles/37366-evolution-options-from-cdma-lte-benefits-ehrpd.htm
This combination aims to enhance the user’s interaction with the network and further drive demand for mobile multimedia services. Furthermore, the LTE evolution calls for a transition to a ‘flat,’ all-IP core network with a simplified architecture and open interfaces. This requirement is defined by the System Architecture Evolution (SAE) — also known as Evolved Packet Core (EPC) — the 3GPP specification for changes to the packet core network architecture.
While GSM/UMTS-based operators have a natural evolution to LTE, many CDMA-based mobile operators also have decided to evolve to the LTE specification. Changes in mobile communications have traditionally been evolutionary, and the deployment of LTE will be the same. The transition for CDMA operators from High Rate Packet Data (HRPD) to LTE will be over a period of several years, as is the case still with the transition from 1xRTT to HRPD. As a result, mobile operators must look for a migration path that will enhance their existing HRPD networks, while addressing LTE deployment requirements and will not require a ‘forklift’ upgrade.
The choice of migration path depends on many factors including radio access strategy, network resource strategy, services enabled, timing and cost. A key goal of LTE is to enhance service provisioning while simplifying interworking with non-3GPP mobile networks. This is essential for CDMA operators that have chosen to migrate to LTE. The following are three basic migration paths to LTE currently available for CDMA operators.
Overlay — In this approach, a complete LTE network is deployed as a second network to the existing HRPD network. However, this will be very expensive, and with an overlay, a subscriber roaming from the HRPD network to the LTE network will experience a loss of continuity for the IP session.
& from the 1st link -
Problems with CSFB
There are numerous drawbacks with the CSFB approach to interim voice and messaging, which Disruptive Analysis believes should prompt operators and standards authorities to look afresh at alternative interim mechanisms. Part of the problem has been that past assessments of the standards have focused mostly on the technical aspects, rather than addressing issues around user experience and behaviour, or impacts on broader application usage and indirect impacts on business models.
The following issues are examined in more details in the next sections of the document:
Additional call set-up latency Requirements on network coverage Side-effects of dropping the data connection during voice calls Impact on data applications, especially on multi-tasking devices Issues relating to SMS support Implementation cost and practicalities Negative impacts on current or potential new LTE business models, eg MVNOs Poor fit with new types of voice application Problematic integration with femtocells
i've read issues, where the newer single chip qualcomm phone (nexus 5 & lg g2 on sprint) would have ither, a strong steady lte signal, but no switch over on voice calls, missing the paging channel altogether, resulting in a voicemail, w/o the phone even ringing..
or vice versa, the phones would park on 3g & stay parked in definately, one would suspect they were in a lte coverage area, & would toggle airplane mode, or reboot, (effectively ripping down the established connection, to rebuild a new one) & getting a strong lte signal!
the older phone with two paths rarely suffered this, regardless of the settings , on home only or automatic, in system select..
Click to expand...
Click to collapse
to sum it up;
on our new triband spark capable phones, does *automatic vs home only* in (change the cdma roaming mode) mean what we THINK it means in relation to it's single chip, single path architect??
back when, in dual pathed phones it MEANT roaming in another provider, when ecsfb, carrier aggregation, spark wasn't a thought..
but these newer triband phone are different beasts, & the effect of the patched worked, fit n finished network of cell sites of upgraded , non upgraded network vision, does toggling automate for smoother performance between these sites on these triband devices, with single paths....?
something as simple as a network toggle, to aid service (on the mobile client side) in this -
"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"
from being parked on an lte channel, being called & successfully *inter-roaming* to 1xtt voice, evdo data (if used), then back to lte parking & usage when applicable..
~shrugz shoulderz~
j'vai said:
the reason why i ask is because i wanted to put a solution that worked for me to the test:
before, i noticed the phone app would freeze on incoming calls while parked on lte, the only way of it of the freeze, was a reboot..
selecting 3g, no issue but no lte..
back on lte, more freezing..
under settings in MOBILE NETWORKS then SYSTEM SELECT then toggling to AUTOMATIC
seemed to clear the issue, (for me)
but i wondered why?
i know of the e.csfb issue on sprint network with single chip phones that don't support svtle, having one voice / data path, & how ehrpd plays in bridging cdma hand-offs to & from lte parking semmlessly;
but why did switching to AUTOMATIC in system select, seemed towork for me between sites that are mixed between upgraded non upgrade network vision?
my suspicions is that when ehrpd is utilized, it invokes a roaming type hand-off in-channel, yes it's explain for evdo to lte, but evdo is technically, cdma also, is why it worked..
here's some of the reading i did to wrap my heading around the issue -
http://www.slideshare.net/abpreen/cdma-ho-design
&
Multi-RAT Heterogeneous
Networks (PDF)
also - EHRPD Integrates EV-DO & LTE Networks (PDF)
reaching out to an inquisitive community to seek an answer..
does this toggling *migitate* the negative effect of the e.csfb issue on sprint with newer single chip qualcomm phones?
i need help y'all
Click to expand...
Click to collapse
what i'm seeking is true collaboration, of people of truely work to put it to the test -
these are the setting on my nexus 5 -
as anyone can see, i have mobile data roaming set to OFF, & automatic ON in system select, this allows me acces to verizon's 1xtt voice while underground in the subway, but that's it;
what would be similiar settings as this for
an lg g2?
a galaxy s4g triband?
an iphone 5s?
if you successfully are able to park in lte, & answer/ recieve calls, & switch back to lte afterwards, & utilise that lte data, like myself, in your vicinity on the sprint network non nv & nv, what are your settings set to?
this is the collaboration i seek..
j'vai said:
https://www.nttdocomo.co.jp/english/binary/pdf/corporate/technology/rd/technical_journal/bn/vol11_3/vol11_3_013en.pdf
&
http://lteuniversity.com/get_trained/expert_opinion1/b/ramesh2/archive/2013/06/21/csfb-mtrr.aspx
I just tried again, to set the phone to *HOME ONLY* in system select (change the cdma roaming mode), called myself consecutively, after the second successful anser i was like "ooh maybe the issue has been cleared" but the third time, and fourth, the freeze came back, while in this setting..
Mobile Terminating Roaming Retry Call
While doing some background reading I stumbled over the following optional Mobile Terminated Call procedure for a race condition:
The scenario: Just when the mobile network receives an incoming call for a user, the user's mobile changes to a cell which is controlled by a different mobile switching center. This results in a race condition, i.e. the previous MSC receives the call while the mobile is already performing a location update via the new MSC. If this is not treated, the mobile will not see the paging in the old cell and the call establishment fails.
This is where the "Mobile Terminating Roaming Retry Call" feature comes into play: If implemented, the previous MSC which has sent out the paging message to contact the mobile is informed of the location update by a "Cancel Location" message from the HLR. This is standard practice so far. However, instead of failing the paging procedure, e.g. after a timeout, the Cancel Location message is used as a trigger to signal to the Gateway MSC that the subscriber is no longer with this MSC. The Gateway MSC then releases the speech path to the previous MSC, runs another subscriber location search with the Home Location Register and then forwards the call to the new MSC. All quite elegant.
For details see 3GPP TS 23.018, chapter 5.2.1
I wonder, if this feature is widely implemented and used today? If you know, please let me know.
I'm writing an email to a RF Engineer at Sprint Nextel locally here in wash dc, (well actually she's in university of maryland college park) to look at this thread to see if it holds water, we could meet demostrate in person what happens over lunch / dinner whatever...
Click to expand...
Click to collapse
daam, thank you cisco! -
Universal Roaming
By operating 2G/3G and 4G functions on the same core platform for 3GPP and non-3GPP (for example, CDMA) access systems, operators can more easily achieve inter-technology handover and universal roaming/interworking between access networks with reduced signaling overhead over the air and in the network. With LTE/SAE specifications detailing a common, converged core, universal roaming will be critical.
Since LTE/SAE is becoming the network evolution choice of many CDMA operators, 3GPP and 3GPP2 are defining interworking specifications for optimized handover management between 3GPP2 radio access technologies and LTE, using EPC as the converged core. Key to this interworking will be seamless mobility and handover between the two technologies - one of the goals of a migration to eHRPD.
The Cisco Difference
Cisco brings a history of innovative solutions that already meet many of the requirements of LTE and SAE, such as integrated intelligence, simplified network architecture, high-bandwidth performance capabilities, and enhanced mobility.
Additionally, mobile operators will benefit from solutions that can provide 2G/3G functionality now and evolve to 4G functionality later. Cisco's solutions are capable of supporting 2G/3G today, and through software upgrades these solutions are designed to support 4G functionality when LTE networks are deployed. Furthermore, they are capable of supporting multiple functions in a single node. This allows a single platform to concurrently act as a 2G/3G and 4G node, providing a true evolution path.
The flexibility of Cisco's multimedia core platform provides multiple migration options from 3G/HRPD to 4G/LTE. Options include the phased approach to LTE through eHRPD and the cutover approach with coexisting but pure overlay HRPD and LTE networks.
Evolving to LTE: Cisco’s Seamless Migration for CDMA Operators
What authentication method is used between the UE and the network in LTE
question:
What authentication method is used between the UE and the network? From reading a few different text books, it seems that the authentication with the USIM in the UE is the same it was with GSM/UMTS-to-LTE networks. Is is assumed that CDMA2000-to-LTE networks will authenticate and register the UE the same way it would in its legacy CDMA network? I can't seem to find the answer to this.
answer:
EAP-AKA is the protocol that is used in UMTS/LTE (3GPP) networks between the UE and the network.
The technology is known as eHRPD which acts as an evolution path between HRPD(CDMA2000) towards LTE. The UEs have dual mode radios,i.e LTE and eHRPD, so whenever the UEs are moving from LTE to eHRPD n/w they start the eHRPD procedures to acquire the eHRPD radio resources and viceversa switch to EUTRAN access procedures while moving into EUTRAN access.
The eHRPD access network connects to the EPC via a g/w called HSGW which acts as a 3GPP ePDG.
There are two levels of authentication that happen in HRPD n/w, which also apply to eHRPD UEs.
1. UE device authentication: with Access n/w via 3GPP2 A12 interface, which uses CHAP protocol(with the hardware addr either ESN/MEID as the key). Here the authentication is only between the UE device and the eHRPD access-AAA server(known as AN-AAA)
2. UE subscriber authentication with the core LTE n/w: Here the subscriber authentication and authorization occurs with the LTE core network. For this, the UE, during the establishment of the session(during PPP auth phase), performs EAP-AKA' authentication. The HSGW sends PPP-EAPIdentityRequest, UE responds with EAP response(with its NAI). The HSGW forwards the EAP response (encapsulated over Diameter based Pi interface) to the 3GPP2 AAA proxy server, which in turn relays the EAP response to the 3GPP AAA server in the EPC (over Diameter based STa interface), the 3GPP AAA server now in-turn retrieves the authentication vectors from the HSS(over Diameter based SWx). The 3GPP AAA server now sends a EAP-REQ(with AKA' Challenge) which transcends to the UE via 3gpp2AAA->HSGW->UE. UE responds with EAP-RESP(with AKA' Challenge response) which travels upto the 3gppAAA, which sends EAP-SUCCESS(after comparison of SRES and XRES).
**Point to Note: In '1)UE device authentication' could also follow EAP-AKA procedures similar to as described for 2 (instead of CHAP) if it is a scenario of an LTE UE <-(UE=user equipment) roaming into eHRPD network.**
Hope this answers your doubt! Refer to 3GPP2 X.S0057-0 for more clarity.
j'vai said:
what i'm seeking is true collaboration, of people of truely work to put it to the test -
these are the setting on my nexus 5 -
as anyone can see, i have mobile data roaming set to OFF, & automatic ON in system select, this allows me acces to verizon's 1xtt voice while underground in the subway, but that's it;
what would be similiar settings as this for
an lg g2?
a galaxy s4g triband?
an iphone 5s?
if you successfully are able to park in lte, & answer/ recieve calls, & switch back to lte afterwards, & utilise that lte data, like myself, in your vicinity on the sprint network non nv & nv, what are your settings set to?
this is the collaboration i seek..
Click to expand...
Click to collapse
...
jcwxguy said:
hate to burst your bubble but a freeze on the phone apk doesnt really have to do with the e/csfb issue . sounds more like a software issue with your phone.
here is a good read for you
http://s4gru.com/index.php?/blog/1/...-due-to-circuit-switched-fallback-technology/
Click to expand...
Click to collapse
that you've **plugged that blog** let me ask you;
everyone that has read it, is now aware of WHAT'S going on,
**but why stop there?**
why?
it would be very self defeative in mindset, to believe there's nothing more to understand than WHAT'S happened, no further than that..
what usually follows that school of thought, is, *there's nothing i can do about* in-line with the blog..
to follow that line of thinking, would have one believe lg placed faulty handsets (that DON'T operate as they were designed) out on the market on a perfect sprint network (that operates as it SHOULD) - but we know that's not the case;
on that site, i have it opened in another tab - it states;
S4GRU MISSION STATEMENT:
"To provide a forum for discussion and education about wireless spectrum, networks, and Sprint Network Vision, in particular, in an online community that is mature, intelligent, and free from uncritical negativity."
The mission statement is very important to us, because it is the foundation for which all rules and guidelines stem from. S4GRU endeavors to maintain the mission statement as our core philosophy and only consider rules and actions in context within the mission statement.
~if that's true & is the case~
(this thread will NEVER see the light of day over at s4gru if their mission statement's a front, i have my suspicions why)
why stalemate to WHAT'S happening , & not delve further & push the envelope, into WHY the handsets & network inter-act like so?
**WHY is sprint's ecsfb creating issues with the newer qualcomm based single chipped, single pathed phones??**
(which is the point of this thread's birth)
for solution sake..