yashsingh1/xdaforums huggingface dataset:
[Nexus 5 Q&A, Help & Troubleshooting] j'vai:
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.
[Nexus 5 Q&A, Help & Troubleshooting] j'vai:
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..
[Nexus 5 Q&A, Help & Troubleshooting] j'vai:
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. "
[Nexus 5 Q&A, Help & Troubleshooting] j'vai:
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_LTE:DL-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 OPTIONAL:eek:mit

+-nonCriticalExtension ::= SEQUENCE OPTIONAL:eek:mit

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..
[Nexus 5 Q&A, Help & Troubleshooting] j'vai:
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...
[Nexus 5 Q&A, Help & Troubleshooting] j'vai:
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~
[Nexus 5 Q&A, Help & Troubleshooting] j'vai:
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..
[Nexus 5 Q&A, Help & Troubleshooting] j'vai:
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
[Nexus 5 Q&A, Help & Troubleshooting] j'vai:
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.
[Nexus 5 Q&A, Help & Troubleshooting] j'vai:
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..
[Nexus 5 Q&A, Help & Troubleshooting] j'vai:
"Okay idk if this had been covered but just kinda curious, would even prevent you from roaming and have lte? Just curious because sometimes ill roam and still have lte ( no idea how) lol.. but im guessing by the end of it lte 800 shouldnt have the same coverage as 1x 800. But sometimes even tho all my towers are 1x 800 accepted I have areas where I will roam but have lte.. faint but useable... which just confuses me.

And thats with band 25 1900 lte"

"That will continue to be true of SVLTE devices. But considering that we are in the e/CSFB thread, it is important to note that single RF path devices will never encounter that odd situation of Sprint native LTE plus roaming CDMA1X."

"I've been in a situation where I'm on Sprint LTE with my N5. Then when the call comes in it connects to 1x roaming.

Sent from my Nexus 5"

"My understanding from the SignalCheck developer is that the Nexus 5 sometimes incorrectly displays roaming when connected to a voice call over 1x 800. It is not likely to my knowledge that your device would be able to get tunneled roaming packets through the Sprint LTE connection to know when a call is incoming."

"You might see the roaming indicator, but it's a glitch.. you are not actually roaming. I have seen it myself. I think it might have something to do with the fallback from LTE to 1xRTT happening a split second before the incoming call hits. The N5 might not be "realizing" what network it is on yet, for lack of a better word. As I mentioned before, the CDMA routines in the base Android code aren't entirely perfect for single-path devices like the N5. It appears that there are telephony functions where a constant 1X connection was expected (which was a fairly safe assumption until last fall)."

"This is spot on. My N5 indicates roaming any time I fall back from LTE to cdma1x 800 to receive the call, but it is not actually logged as roaming. I was in a sprint store today asking about this. It was kind of funny watching the guy fumble around trying to figure it out. First he tried telling me it's because the phone was set to global, then my prl was out of date, then needing an updated profile. Ultimately he caved in and admitted he didn't know why it was doing it and handed me the phone back."

~sigh~

good night group..
[Nexus 5 Q&A, Help & Troubleshooting] j'vai:
What is EUTRAN?

The E-UTRAN (Evolved UTRAN) consists of eNBs, providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the UE. The eNBs are interconnected with each other by means of the X2 interface. The eNBs are also connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by means of the S1-MME and to the Serving Gateway (S-GW) by means of the S1-U.

How does Intra E-UTRAN Handover is performed?

Intra E-UTRAN Handover is used to hand over a UE from a source eNodeB to a target eNodeB using X2 when the MME is unchanged. In the scenario described here Serving GW is also unchanged. The presence of IP connectivity between the Serving GW and the source eNodeB, as well as between the Serving GW and the target eNodeB is assumed.

The intra E-UTRAN HO in RRC_CONNECTED state is UE assisted NW controlled HO, with HO preparation signalling in E-UTRAN.

when e.csfb is linked to sprint spark's 3g / lte upgrade, the lte part to sprint's ecsfb *isn't even in the equation as of yet* UNTIL the IP link can be **flattened** via ehrpd, at the E-UTRAN, TO be circuit switched, to fall back to voice & evdo data..
[Nexus 5 Q&A, Help & Troubleshooting] j'vai:
over 1,000 views, ...

and NO ONE wants to put it to the test, & collaborate?
[Nexus 5 Q&A, Help & Troubleshooting] j'vai:
Nexus 5 cannot answer incoming call

**This question is Not Answered.**

~watching~

http://https://community.sprint.com/baw/thread/140006?start=0&tstart=0