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..
Related
I have quite a few questions some hidden settings I found while using ANYcut app.
My phone is the Epic 4G and on Gingerbread leak EH17 if that matters.
1) MSL code. I did some google searches and found that is an algorithm to determine the ESP and other things. What is the algorithm? If a phone had a bad ESP could you change the MSL to make Sprint think there is a clean ESP?
2) Cell broadcast SMS. What is this? And what is it for? some of the settings are Emergency broadcast, administrative, maintenance, local weather, area traffic reports
general news:
local
regional
national
international
And those same options for other types of news also
3) Data Create. I think this one is self explanatory. But is this for the maximum number of each I can store on the phone before it deletes them. So if i set the maximum number of texts in my inbox to 500, that is the maximum I can store?
4) Dial up networking. I thought this was going to be the 3G but I was wrong. What is it? I turn it on and click on the connection settings but nothing happens why?
5) Dock settings. Its obvious. But I herd that you can connect your phone to the a computer via USB and have it act as a dock and play songs or videos through the speakers on your computer. Is this true?
6) DUN. It has a picture of a computer with 2 green arrows. And 2 progress like bars, labeled, RX and TX. Any ideas? I was thinking it might have to do with USB activity.
7) EVDO settings??? I am on the Sprint network. Why would they not opt this options out of there SDKs? Isnt EVDO T-Mobile network? But I am on a leaked build so maybe they haven't removed it yet?
8) Preconfig? I really not sure what this is. It says sales code and then an input field. And at the bottom a button that says install and one for cancel. What would this be for?
9) License settings. most of the options are obvious but there is one for expiry reminder. whats that? reminds you when your DRM content is going to expire?
10) MMS Provision Settings. some settings are transaction logs, optional field attendance, UA string, UAP url, and test modes. Anyone know what this is for?
11) Now one that is just called advanced. Some options are home orig. vocoder. homepage vocoder, roam orig. vocoder. whats this for?
12) USB Logging(DM) One section is Function, with the options of, enable and disable. And other section called Type. the options are CP only, AP only, CP+AP. No idea about this one
13) WiMAX CT. there is a button at the top that says open device. then options of max num of used FA, FA Index, BW, FA index. Are these settings for WiMAX networking?
14) WiMAX Mode Change. The options are, SDIO, WTM, DM, USB, Auth modes. What are these different modes and what do they do?
15) WiMAX LineTest. Optioins are, write eeprom, power on, power off, write mac with and input field, and read mac. any ideas??
16) Work mode. it says Work Mode :2 and then a button that says set work mode. and i can set it to 1, 2 or 3. what are these different modes for?
Bump - Anybody want to jump in and help the op?
Wow, with all the brilliant minds on here no takers? Or is the question too big for anyone to take a stab at?
First off, as someone who somehow burnt out my 4G chip, I would suggest that anyone reading this be very careful, search here and google before fiddling with settings. lol
Since I am doing research to see if I can get my Wimax to work better I will answer a couple of questions a day, however anyone feel free to jump in.
1) MSL code. I did some google searches and found that is an algorithm to determine the ESP and other things. What is the algorithm? If a phone had a bad ESP could you change the MSL to make Sprint think there is a clean ESP?
The MSL code or (Master Subsidy Lock) is how a phone carrier keeps the phone from going to another network, however some phones including the E4GT can be found through using Android Debug Bridge (adb) a command line tool that lets you communicate with an emulator instance or connected Android-powered device - or even easier just go to the market and download, for free, Get My MSL which will display your Master Subsidy Lock code.
2) Cell broadcast SMS. What is this? And what is it for? some of the settings are Emergency broadcast, administrative, maintenance, local weather, area traffic reports general news:localregionalnationalinternationalAnd those same options for other types of news also
According to Wikipedia:
Quote:
Cell Broadcast is not as affected by traffic load; therefore, it may be usable during a disaster when load spikes tend to crash networks, as the 7 July 2005 London bombings showed. Another example was during the Tsunami catastrophe in Asia. Dialog GSM, an operator in Sri Lanka was able to provide ongoing emergency information to its subscribers, to warn of incoming waves, to give news updates, to direct people to supply and distribution centres, and even to arrange donation collections using Celltick's Cell Broadcast Center, based on Cell Broadcast Technology.
All for today. Peace
Hey guys I did a search and found nothing. Any time I'm connected to Wi-Fi, I can't receive calls or texts. I'm on Sprint. Anyone else have this issue?
nein7three said:
Hey guys I did a search and found nothing. Any time I'm connected to Wi-Fi, I can't receive calls or texts. I'm on Sprint. Anyone else have this issue?
Click to expand...
Click to collapse
Yes, have done tons of research and am having a similar issue. It's believed to be software related. If LTE or Global are set as the "Preferred Network Type" under Mobile Network AND wifi is turned on, then the mobile signal cuts out when it goes to sleep. With 3G set, the phone works fine with wifi turned on. I've tried wiping the phone and also loaded the factory 4.4.2 image via fastboot this morning and still have the problem. Some people have RMA-ed their phones and still report the issue, so it must be a certain combination of settings. It's also being reported from Sprint and T-Mobile user, so it's not restricted to just one network. As for me, I'm on Sprint in NYC, have an AC router and using an Airave. My Galaxy S4 didn't have any problems.
Here are a few threads that I've found:
XDA - Signal Problem
XDA - Signal issues with new baseband solved by flashing older baseband
On Google's forums:
Nexus 5 sometimes doesn't ring when people are calling
Thanks man, I had read the Google thread but hadn't find the XDA ones. I'll try forcing 3g while on Wi-Fi.
No problem! If you're on Sprint, there is also this:
Circuit Switched Fallback Issues on Sprint
I'm in an area that is reported as not having the issue, so it's not that for me. Plus, I'm on 3G with the Airave. I remember having the HTC Mogul on Sprint and for a while it would just die if the signal was roaming. An update fixed it, but it wasn't fun. At least in this case the phone still works, not as advertised, but it works. Here's to hoping that it's fixed soon!
I'm the Tmobile user in the Google discussion. It's an annoying problem and hope it's fixed with 4.4.3. However the issue just happened to me in the last week before I got the 4.4.2 update. So I'm not sure what could have happened from a month ago when I got the phone until a week ago. Haven't installed any new apps since then.
This does seem to be working now that I am forcing 3g
Weird, right?
4.4.1 and 4.4.2 both have the same baseband and kernel. That's about the timeframe when the updates both came out, so I assume that maybe 4.4.1 is when the majority of users started seeing issues pop up?
From what I've read, this phone handles cell signals much differently because of the newer LTE TDD. It could be any number of things really, but I don't have the expertise to examine the code to see what was changed between the 4.4 and 4.4.1/4.4.2 baseband. I do believe that all of the Wifi and cell signal issue posts that are popping up now are related though.
I'm also noticing my wifi speeds bouncing all over the place (from ~180Mbps -- ~500Mbps) and I'm only a few feet away from my router. I have a Netgear r6300v2 AC router.
12/14/13 Update: I just got off of the phone with Sprint. They show that there is an internal memo on the issue and LG is aware of it. They will be pushing an update as soon as it's ready. Sprint will also be pushing an update for the Airave to help with the issue, starting on 12/19/13.
The support rep told me that it is an issue where the wifi and LTE radios aren't playing nicely together and it's causing this conflict. That's why everything seems to work fine when 3G is set as a preferred network.
PynkFloydd said:
Weird, right?
4.4.1 and 4.4.2 both have the same baseband and kernel. That's about the timeframe when the updates both came out, so I assume that maybe 4.4.1 is when the majority of users started seeing issues pop up?
From what I've read, this phone handles cell signals much differently because of the newer LTE TDD. It could be any number of things really, but I don't have the expertise to examine the code to see what was changed between the 4.4 and 4.4.1/4.4.2 baseband. I do believe that all of the Wifi and cell signal issue posts that are popping up now are related though.
I'm also noticing my wifi speeds bouncing all over the place (from ~180Mbps -- ~500Mbps) and I'm only a few feet away from my router. I have a Netgear r6300v2 AC router.
12/14/13 Update: I just got off of the phone with Sprint. They show that there is an internal memo on the issue and LG is aware of it. They will be pushing an update as soon as it's ready. Sprint will also be pushing an update for the Airave to help with the issue, starting on 12/19/13.
The support rep told me that it is an issue where the wifi and LTE radios aren't playing nicely together and it's causing this conflict. That's why everything seems to work fine when 3G is set as a preferred network.
Click to expand...
Click to collapse
thanks man!
do we have any update on the situation?
Yeah I wish there was an update soon because this problem is starting to become very annoying. Twice this week I had to check my Google Voice because my Text didn't go through on my phone
Anyone have a fix for this yet?
Does anyone know if any custom roms fix this?
I've read Google is aware of the issue and speculation says they will fix it with the 4.4.3 release.
questions:
(the 1st is stupid, but i'll ask anyways) - when this issue occurs, is the phone set to **wifi only** with 3g / lte in airplane mode?
or does it occur when just setting up wifi in ADDITION to 3g / lte?
&, when you typed Receiving no calls out texts while on WiFi , is your application for texting, hangouts?
if it's hangouts, then google neutered it to only allow text thru the cellular network,
but if you're simply joining a wifi hotspot at work or home, with your cellular network enabled, it SHOULD go thru, ive never had an issue like that with wifi toggled.. even with 4.4.1
---------- Post added at 03:54 PM ---------- Previous post was at 03:48 PM ----------
j'vai said:
questions:
(the 1st is stupid, but i'll ask anyways) - when this issue occurs, is the phone set to **wifi only** with 3g / lte in airplane mode?
or does it occur when just setting up wifi in ADDITION to 3g / lte?
&, when you typed Receiving no calls out texts while on WiFi , is your application for texting, hangouts?
if it's hangouts, then google neutered it to only allow text thru the cellular network,
but if you're simply joining a wifi hotspot at work or home, with your cellular network enabled, it SHOULD go thru, ive never had an issue like that with wifi toggled.. even with 4.4.1
Click to expand...
Click to collapse
~hint~
maybe it's simpler than one would expect (shot in the dark)
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~
for those with this issue, what are your setting like, in relation?
---------- Post added at 04:11 PM ---------- Previous post was at 03:54 PM ----------
j'vai said:
questions:
(the 1st is stupid, but i'll ask anyways) - when this issue occurs, is the phone set to **wifi only** with 3g / lte in airplane mode?
or does it occur when just setting up wifi in ADDITION to 3g / lte?
&, when you typed Receiving no calls out texts while on WiFi , is your application for texting, hangouts?
if it's hangouts, then google neutered it to only allow text thru the cellular network,
but if you're simply joining a wifi hotspot at work or home, with your cellular network enabled, it SHOULD go thru, ive never had an issue like that with wifi toggled.. even with 4.4.1
---------- Post added at 03:54 PM ---------- Previous post was at 03:48 PM ----------
~hint~
maybe it's simpler than one would expect (shot in the dark)
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~
for those with this issue, what are your setting like, in relation?
Click to expand...
Click to collapse
just a note -
if you look at slide 7 on the qualcomm snapdragon 800's chipset (you all already know this)
http://www.slideshare.net/jjwu6266/qualcomm-snapdragon-800-mobile-device
there's only ONE chip to handle wifi, 4g, 3g, bt, etc..
with lesser BoM (bill of materials) just maybe, top level s/w userspace toggles, handle more than what meets the eye, the point i was making in another thread..
which not only effects our nexus 5s, but even other phones in various ways depending on the implementation of sw/hd, of the same chipset family..
& sprint has mentioned for the forseeable future, of providing phones, with these types of chips from qualcomm..
~go figure~
nein7three said:
Hey guys I did a search and found nothing. Any time I'm connected to Wi-Fi, I can't receive calls or texts. I'm on Sprint. Anyone else have this issue?
Click to expand...
Click to collapse
the ONLY reason i pointed to the network settings *home vs automatic* in this situation, is because,
the qualcomm sd 800 is an asymmetric multiprocessor, (as will future chipsets be) & you're losing other core networking functions, while gaining another, when you SHOULD have available ALL facilities -
**ASMP vs SMP**
&
Symmetric Multiprocessing Vs. Asymmetric Processing
It actually occurs when the phone is connected to LTE and WiFi together. If my settings were to connect to 3G along with WiFi, SMS works fine.
I have to manually change my Mobile Network settings when I get to home or work, where I will be connecting to WiFi (note cellular service is always ,on, I didn't mean to make it sound as if I am trying to send SMS over WiFi). So when home I turn on WiFi along with 3G connectivity and when I leave I turn off Wifi and switch to LTE.
This issue has been happened while unrooted and running stock ROM and it still happens while rooted running Cataclysm.
Also note, the SMS we miss never will come through, it's not as if later on the message comes through...It's gone forever. It also prevents calls from coming through, it's not just limited to SMS.
nein7three said:
It actually occurs when the phone is connected to LTE and WiFi together. If my settings were to connect to 3G along with WiFi, SMS works fine.
I have to manually change my Mobile Network settings when I get to home or work, where I will be connecting to WiFi (note cellular service is always ,on, I didn't mean to make it sound as if I am trying to send SMS over WiFi). So when home I turn on WiFi along with 3G connectivity and when I leave I turn off Wifi and switch to LTE.
This issue has been happened while unrooted and running stock ROM and it still happens while rooted running Cataclysm.
Also note, the SMS we miss never will come through, it's not as if later on the message comes through...It's gone forever. It also prevents calls from coming through, it's not just limited to SMS.
Click to expand...
Click to collapse
try my suggestion; it won't hurt..
let us know if it rectified anything..
What worked for me was forcing 2G instead of 3G, hope it helps!
13I find myself with a few phones handed down to me, and I am often in areas where there in no mobile phone network available,
I am curious as to weather or not these Android phones (on which I have gained root access) could be perhaps booted to a system that allows communication directly between the phones instead of via the non available mobile network.
If I remember correctly, an article I read some years ago described an open source project designed to offer telecommunications using the transceiver in each phone to create a network for areas that had no other available network.
If anyone could point me to some information on the above described network, or just using these as "walkie talkies" I would very much appreciate it.
I was not able to find much in the way of relevant information, but Wikipedia says,
Developments
Some cellular telephone networks offer a push-to-talk handset that allows walkie-talkie-like operation over the cellular network, without dialing a call each time. However, the cellphone provider must be accessible.
Motorola has IDEN cellphones (e.g., i867) that can have 15 conversations over each of 10 900Mhz channels (see Moto Talk) between compatible cellphones without using the cellphone network or a base station. This is very useful outside the range of a cellphone provider as well as reducing network charges.
Click to expand...
Click to collapse
Smartphone apps
A variety of mobile apps exist that mimic a walkie-talkie style interaction. They are marketed as low-latency, asynchronous communication. The advantages touted over two-way voice calls include: the asynchronous nature not requiring full user interaction (like SMS) and it is voice over IP (VOIP) so it does not use minutes on a cellular plan. Applications on the market that offer this walkie-talkie style interaction for audio include Voxer, Zello, and HeyTell, among others.[7] An application that offers this style of interaction for video is Glide.[8]
Click to expand...
Click to collapse
Nothing in this seems to be what I am looking for.
have you tried restarting your phone? my phone sometimes crashes and restarting works perfectly, try it seriously
There may be apps that provide Walkie Talkie like functionality over Wifi, but I think you need to distinguish what you are doing over wifi, bluetooth, and cellular. I'd go with one of these. You might even be able to setup some kind of mesh-based network using wifi - depending on the area you are trying to cover.
iDen and other carrier based PTT solutions are based on connectivity to cellular networks, and won't help you here. Additionally, most GSM networks are not outfitted with native PTT functionality. You are best working with Local Area Networks (LANs, like WiFi) or Personal Area Networks (PAN, like bluetooth)
WiFi and Bluetooth operate on spectrum which is unlicensed and available for public use - with some restrictions, such as power output and the like. Anything you could coax out of WiFi or Bluetooth should be fine.
Cellular, on the other hand, is an entirely different breed. Cell networks are generally regulated and licensed by relevant government authorities. Trying to setup your own cell towers is likely illegal in most countries without licensing or regulatory approval - with a few exceptions, like carrier sponsored micro cells. That would include tampering with the cellular radios in most devices.
3234
Yes,,, the legal issue is something I had not yet considered and you make some important points.
It is likely that even if I find the information on the project I mention above I will not be able to do anything other than learn a little from it, that's OK.
You mention IDEN as being carrier based, as far as I can tell IDEN is one of the few that is not.
From my previous quote
Motorola has iDEN cellphones (e.g., i867) that can have 15 conversations over each of 10 900Mhz channels (see Moto Talk) between compatible cellphones without using the cellphone network or a base station. This is very useful outside the range of a cellphone provider as well as reducing network charges.
Click to expand...
Click to collapse
There is more info on this at this site .wikipedia.org/wiki/MOTO_Talk ( need to make more posts before I can give a link ).
I do however note that some carriers do not allow this feature to be used, or limit its use.
MOTO Talk also works only on some specific Motorola phones, reading between the lines there seems to be some hardware as well as software that is unique to these models.
I'm most interested in the open source project ( I think it was open source ) that I read about some years ago, perhaps it is on SourceForge?
I have trouble finding a useful search string for Google, any suggestions?
I'm building a test mobile network on some laptops and with a software defined radio based on Open AirInterface (is googleable, but I can't post the link cos I'm a newb) code, and I have this up and running. Additionally, I've bought some programmable SIMs to work with it on a bunch of phones. The information on these I've added into my HSS implementation. The Country Code/Network code deployed on the SIMs is 901/70 - so it doesn't interfere with commercial networks.
I'm testing with a bunch of phones in an isolation chamber, and my end goal is to shift the network into something I have a license for and "go public", but this network will have a low channel bandwidth (3MHz or 1.4MHz in Band 3 LTE). Not many phones have supported this, so I started with a 5MHz channel, which most do support - and I've successfully connected an S4 and a Nexus to my little network. However, when I tried the S6 with a SIM that worked in another phone, it cannot even see the network. I've seen hints of Samsung doing operator whitelisting, but would like to know if this is the case and, if possible, how to add my operator codes into the whitelist.
So far, I've tried the following:
a) "*#0011#" puts you into ServiceMode where you used to be able to enable/disable frequency bands and other such settings with the "Q0000" menu entry - but it looks like Samsung have squished this, also I know the phone has Band 3 operational as I can put a commercial SIM in it that runs on that band. I've not found any way of actually modifying any settings within this mode.
b) I found the file "/system/etc/apns-conf.xml" which contains a list of operator APN addresses - I updated mine to contain my settings, but no joy, and if I "reset to default" my APN settings, my settings are not picked up and I have to manually add my APN (but at least that stays selected)
c) I found some databases in "/data/data/com.android.providers.telephony/databases/", in particular "nwk_info.db" and added my network details to it. The phone then changed from basically saying I was only able to make emergency calls to "Selected mobile network (901/70) unavailable", which kind of at least hints I've moved it in the right direction
The S6 is running a rooted factory reset, and allows SIMS from two different commercial operators on it so it should be completely unlocked. It's never been out of the country, so should have "defeated" the region locks that Sammy put on the phones nowadays (although it begs the question whether rooting the phone resets this and perhaps it's still awaiting 5 mins of calls via a local SIM?).
Does anyone know of a whitelist of MNC/MCC numbers I can add my settings to? Or any other possible solution to this?
The long winded solution is to change the MNC/MCC info on each of my SIMs, but that's a PITA and I'm not even sure it'll work yet (I will attempt to try one soon, but changing the configs on my mobile network is also non-trivial!)
Hi everyone,
Has anyone here had any success capturing VoLTE network traffic on a smartphone?
Some context:
I have tested a rooted Redmi Note 9S so far. When registered on an LTE network with a VoLTE-enabled SIM, two network interfaces are added in Android, one of which is used for data connection and the other for IMS/VoLTE (I have examined the output of "logcat -b radio" on the phone to confirm this). The two interfaces are usually named rmnet_data1 and rmnet_data2, and rmnet_data1 is usually used for data. By using tcpdump, the data traffic can be captured without any problems. But when I run tcpdump on the VoLTE interface, almost no traffic is captured even when making a VoLTE call.
By examining the outputs of other Android tools and even built-in linux network statistics, and then reading a bit about it, I am now almost certain that VoLTE traffic is completely handled by the baseband, and it doesn't reach the regular OS (Android) at all. This old post from 2013 provides some info on this development in smartphones.
There are vendor-specific tools like QXDM (from Qualcomm) for troubleshooting baseband communications. But I haven't used them, and I wonder if they provide a way to "capture" the VoLTE traffic, e.g. in a pcap file.
I would be thankful if someone can provide me with an answer or a direction to explore.