Fieldtrial.exe explanations - Touch Pro2 CDMA

Looking for a line-by-line explanation of Fieldtrial.exe.
For example, some articles I've read say Rx Power is the tower strength, while others say RX Ec/Io say that's what I should be watching.
Any guides/FAQs?
Thanks

I'll give it a go...
- Rx Power is the actual power of the signal you are receiving, measured in dBm.
- Rx Ec/Io is essentially the signal to noise ratio (signal quality) of the signal you're receiving. It's a negative number in CDMA because the pilot carrier's signal strength is just a part of the total carrier energy received, so essentially the "noise" is stronger than the signal. I won't go into the gory details of how that all works, but it's pretty cool. Ec/Io is the more important factor to look at if you're wondering how your call will sound and if it will drop...a strong signal is useless if it's dirty. Ec/Io also maps to the "bars" on the phone. -3 dB is the maximum (best) value and -12 or -13 is about as low as you can go and carry a call.
- Rx FER is the received frame error rate. Basically it's how many errors (due to poor signal quality) were detected in the received signal.
- Tx Adj is how much the phone is powering itself back when transmitting back to the tower. Higher values mean you're closer to a tower. I'm not sure of the units here, but maybe just dB.
That's all the signal related stuff. The rest is Network ID, System ID, Channel, etc. The phone also shows the Active Set, which is the PNs (codes that distinguish one sector from another) of the sites you are connected to. This will be 1 site when you're idle, but can be multiple sites when you're on a call. Candidate set is the list of sites that are being considered for promotion into the active set. They are just being measured, you aren't connected to these. Neighbor set is the set of sites that are on the active site's neighbor list. These are nearby sites that your current site might want to hand your call off to if you move towards them. These PNs tell an engineer which site you're on, but unless you have a PN list it's hard to say what site goes with what PN. If you use Google Maps though, and don't use the GPS, it locates you at the cell tower you're currently on.
I hope that helps.

Wonderful! Thank you so much...
I had pretty much given up on getting either Verizon or HTC to answer this for me. "Not supported" was all I could ever get out of them.

Related

5 Things You Never Knew Your Cell Phone Could Do

5 Things You Never Knew Your Cell Phone Could Do
For all the folks with cell phones. (This should be printed and kept in your car, purse, and wallet. Good information to have with you.)
There are a few things that can be done in times of grave
emergencies.
Your mobile phone can actually be a life saver or an emergency
tool for survival. Check out the things that you can do with it:
FIRST
Emergency
The Emergency Number worldwide for Mobile is 112. If you find
Yourself out of the coverage area of your mobile network and there is an
Emergency, dial 112 and the mobile will search any existing network to
Establish the emergency number for you, and interestingly, this number 112
can be dialed even if the keypad is locked. Try it out.
SECOND
Have you locked your keys in the car?
Does your car have remote keyless entry? This may come in handy
someday. Good reason to own a cell phone: If you lock your keys
In the car and the spare keys are at home, call someone at home on
their cell phone from your cell phone. Hold your cell phone about a foot
>From your car door and have the person at your home press the unlock
button, holding it near the mobile phone on their end. Your car will
unlock. Saves someone from having to drive your keys to you. Distance is no
object. You could be hundreds of miles away, and if you can reach someone who has
the other 'remote' for your car, you can unlock the doors (or the trunk).
Editor's Note: It works fine! We tried it out and it unlocked
Our car over a cell phone!'
THIRD
Hidden Battery Power
Imagine your cell battery is very low. To activate, press the
keys *3370#. Your cell phone will restart with this reserve and the instrument
will show a 50% increase in battery. This reserve will get charged when you
charge your cell phone next time.
FOURTH
How to disable a STOLEN mobile phone?
To check your Mobile phone's serial number, key in the following
Digits on your phone: *#06#. A 15-digit code will appear on the
screen. This number is unique to your handset. Write it down and keep it
somewhere safe.
When your phone get stolen, you can phone your service provider
and give them this code. They will then be able to block your handset
so even if the thief changes the SIM card, your phone will be totally
useless. You probably won't get your phone back, but at least you know
that whoever stole it can't use/sell it either. If everybody does this, there
would be no point in people stealing mobile phones.
And Finally....
FIFTH
Free Directory Service for Cells
Cell phone companies are charging us $1.00 to $1.75 or more for
411 information calls when they don't have to. Most of us do not
carry a telephone directory in our vehicle, which makes this situation
even more of a problem. When you need to use the 411 information
option, simply dial: (800)FREE411, or (800) 373-3411 without incurring
any charge at all. Program this into your cell phone now.
Holy God..
the second trick actually worked !
i tried third option in my imate pdal , but it doesnt restart ???
Did it? most of these are myths or misunderstandings and some were proved false long ago. Did you actually try the car unlocking thing yourself?
Here are the facts:
- FIRST: yes, that's true. That's by design, and by legal requirement in some countries.
- SECOND: false. At least, this has been considered a hoax for a long time. If it worked for you, then maybe it works in some very specific cars.
- THIRD: false. There is NO hidden battery reserve, that would be daft. What you can do is switch between EFR and HR modes of transmission. EFR (enhanced full rate) = higher sound quality, shorter battery life. HR (half rate) = lousy sound quality, better battery life. The code *3370# enables EFR, therefore actually worsening your battery life. By the way, these codes are for some GSM based phones only.
- FOURTH:true. But have in mind that remotely disabling phones based on their IMEI is an operator dependent feature. Some operators may do it, others not.
- FIFTH:no idea why they would be plugging that service here.
And check http://www.snopes.com/inboxer/household/cellphones.asp too.
I have read that the third option turns on a higher quality codec, which uses MORE battery life. Can anyone confirm this?
maniac2403 said:
Holy God..
the second trick actually worked !
Click to expand...
Click to collapse
What kind of car do you have?
Snopes.com points out that using two cell phones to unlock a car will not work as remote keyless entry devices use 300 MHz radio signals and not sound.

[App Idea] GSM/WCDMA Switcher

Hey guys,
As the radio stack is the second cause of battery draining after the display, I was thinking about a way to save battery life by reducing the impact of the 3G connection. Most of the energy saving apps on the market are only disconnecting the phone from the APN, but this isn't a great solution as each app could be set to update at different times and thus being unable to download data even if the user sets some exceptions. So I thought that an application which operates in the following way could be great to save power:
- The phone uses the 3G network while the screen is on;
- It switches to 2G when phone is in standby mode;
- It disconnects the APN data connection while the phone is using a WiFi Network;
Obviously to avoid possible issues during the switch between 2G and 3G the following rules are applied:
- If there's an incoming call or a phone call is being performed, there won't be any radio switch until the phone call is ended;
- If there's an incoming SMS/MMS, there won't be any radio switch until the text message is fully received.
Unfortunately as I'm not a Java developer I can't code anything like this. But let me know what you guys think about my idea and if it's technically feasible... Maybe some developer could be interested into further exploring my thoughts and will try to create such an app
Cheers
I'm not a developer but I think it sounds like a great idea. I go into settings and switch it to 2g when I'm in spotty areas outside of town. I have to work a bit to keep my N1 battery alive all day...
Hello I'm new here.
I don't know if your suggested profiles are the best case scenarios. You would need to calculate your data throughput, not just the radio power.
If you need to send 100 packets, your radio would be on the longest for edge > 3g > wifi. So, even though wifi uses the most power, it would be for a much shorter duration.
A profile for "place calls only" would work somewhat like airplane mode, but still keep track of towers. Your phone just wouldn't register on the network unless you wanted to place a call. You would miss your incoming calls, have no data connection, or sms. But, you could have it check at an interval for voicemail or sms. This would be most useful for "ringer off" situations like class or meeting.
Afaik Android is always connected to the APN even if the phone is not downloading anything, consuming a lot of battery power. On other platforms, i.e. Windows Mobile, the connection can be terminated by user and re-established when an app needs that.
The amount of data downloaded by widgets, Google mobile applications or apps which operates in background like eBuddy or Facebook should be quite low, so downloading the required data by using GSM or WCDMA while the phone is in standby would be pretty much the same. The only difference is that downloading stuff using GSM/EDGE should take much less energy power.
So that's why I thought about the app I described before: the phone can save a lot of energy power while in standby and be back to its full horsepower when there is any kind of user intervention. Pretty much the same thing that the system already does for CPU usage. It scales to the less consuming protocol (or, in the case of CPU, frequency and voltage) to save power
I know on the google api it isn't possible to do this, but I don't think that isn't the problem.
At the moment you have 3 options. GSM only, WCDMA only and GSM/WCDMA. Whenever you switch between the 3 of them, the phone will lose signal for 10 seconds before it can find the best network. So the switcher here is not the best as you will lose connection, and what if you are downloading something at the same time...
What you need is when the phone is on GSM/WCDMA that it knows the best network to pick from depending on the phones lifecycle. GSM/WCDMA loses battery power because it always tries to find the best network to connect to, so for example if you are on GSM it will constantly try to find a 3G network etc (as far as I understand it).
What we need is the ability for the phone to stay on GSM when the phone is idle and then when the phone is woken up to automatically start to search for a WCDMA network and then gracefully switch over like it does now. For this I have no idea if it is possible as I don't know how the scanning of the network works. If it is possible then that would be wicked. But this is what we need.
my preference would be if the phone would stay on 3g as long as any possible even if there would be a more reliable 2g connection and only switch to 2g if there really is no way to connect to 3g. turn of apn if the screen us turned of for longer then 1 or 2 minutes and only check every 15 minutes or so.
most of the time I'm on 3g only mode . since I live in a city I got good coverage almost all over the city. only problem is that when there is no 3g available also my phone is unreachable. I don't really miss data connectivity when there is no 3g since 2g is so slow that I rather have no internet at all but not being sale to be called or texted is a major disadvantage...
Sent from my Nexus One using XDA App

[Q] Signal Strength Indication Lies?

After finding out that forcing LTE Mode on the SamChg (See here) always results in a Signal Disabled "circle-slash" display for the network signal strength - even when you have a solid 4G connection - I am suspecting that the signal strength bars in the notification bar only show CDMA signal strength, and never show 4G signal strength.
If so, the signal strength indicator lies to us (at least, when the 4G icon is on the notification bar).
Is there a widget / app / notification mod that will show both the 3G and 4G signal strength? A dB indication would be fine. That way, I can identify the real 4G signal vs. the real 3G signal vs. the signal bar display.
Cheers,
Yes, the signal strength meter lies and only indicates 1xRTT signal strength, not EVDO or LTE.
OpenSignal Maps will show the LTE signal strength but it's a mapping program.
Real Signal shows separate 1x and EV bars like how Verizon feature phones display it, however it doesn't yet support LTE. I've e-mailed the developer to find out if this was planned and/or if they'd like any help in implementing that feature and I've received no response thus far.
skuzz said:
Yes, the signal strength meter lies and only indicates 1xRTT signal strength, not EVDO or LTE.
OpenSignal Maps will show the LTE signal strength but it's a mapping program.
Real Signal shows separate 1x and EV bars like how Verizon feature phones display it, however it doesn't yet support LTE. I've e-mailed the developer to find out if this was planned and/or if they'd like any help in implementing that feature and I've received no response thus far.
Click to expand...
Click to collapse
It's no longer in the market. Do you have the APK by chance ?
Field test mode access seems to elude us on the Charge, but if we could find the code, there's got to be a signal strength indicator in there.
I'm going to query Samsung to see if they'll cough it up.
ram130 said:
It's no longer in the market. Do you have the APK by chance ?
Click to expand...
Click to collapse
nvm..found it under another name. Also Samsung is not the only one with misleading bars, Motorola too. Just look at the thread I did on it here:
https://supportforums.motorola.com/message/302492
distortedloop said:
Field test mode access seems to elude us on the Charge, but if we could find the code, there's got to be a signal strength indicator in there.
I'm going to query Samsung to see if they'll cough it up.
Click to expand...
Click to collapse
Meanwhile, googling around I found some info on enabling hidden menus on the phone (basically same steps as for Fascinate), but once there, none of the known dialer codes work for me, despite others saying they do.
HOWEVER, check out the app called SGSTools in the Market. Install it, run it, select Service Mode. A black screen comes up, hit the menu button, then back and voila, you're in LTE Monitor screen. You might be able to navigate around from there and get your signal information.
Hope this helps.
distortedloop said:
Meanwhile, googling around I found some info on enabling hidden menus on the phone (basically same steps as for Fascinate), but once there, none of the known dialer codes work for me, despite others saying they do.
HOWEVER, check out the app called SGSTools in the Market. Install it, run it, select Service Mode. A black screen comes up, hit the menu button, then back and voila, you're in LTE Monitor screen. You might be able to navigate around from there and get your signal information.
Hope this helps.
Click to expand...
Click to collapse
you should take a pic...I'm curious what that mode looks like. Don't have a charge to fool around with it.
Bumping this up because I just noticed that in Anandtech's review of the LG Revolution, there's a way at least for that phone to see the 4G signal strength: http://images.anandtech.com/doci/4450/DSC_0734.jpg
Given that the Revolution and Charge have different LTE chips, I'm not sure if this can be reproduced on the Charge.
Credit: Page 10 of the LG Revolution review by Anandtech
---------- Post added 10th November 2011 at 12:36 AM ---------- Previous post was 9th November 2011 at 11:55 PM ----------
I just looked around the LTE Monitor menu as distortedloop posted above (thanks!) and it does seem there are some values that may give a better idea of the LTE signal.
One interesting thing I noticed was some sort of MPSR timer that counts down; what it seemed like it was doing was counting down to the next time it would attempt to connect to the LTE network (I was on 1X at the time). Other values that I believe pertain more to the LTE signal strength include: RSRP (Reference Signal Received Power) and CINR (Carrier-to-Interference-and-Noise Ratio). I correlated faster LTE speeds with lower RSRP values (that is, LESS negative).

3G network speed logger

Hi guys,
Is this the right Thread? Please excuse, but I couldn't find a "looking for XX App"-thread.
I do want to proof to my operator that their 3G bandwidth very often is almost 0 even though the 3G coverage / reception is very well.
So I would need an app that regularly probes the transmission speed and logs that, best with geolocation and signal strength.
Most of the Apps around only log 3G signal strength, which is _not_ what I want: in my case the signal is fine, there's just almost no throughput.
Then there are the speedtest-Apss that take a one-time-only speedtest... That's fine but I would have to trigger it everytime: impractical.
I tried "traffic monitor", but often enough the speed tester wouldn't even start because the 3G speed is too slow for it's calibration/download/upload cycle.
Also, as with my operator, there's often only _very_ small bandwidth / nearly 0 avilable the app shouldn't send too big amounts of data for it's probings or it might timeout / at least it should log that correctly.
in the end there sholud be a way to export the data so I can proof the network's disfunctionality.
Unfortunately all my market searches have been in vain yet. Has one of you guys seen an app like that before?
I would be very glad about any hints and tips.
Thanks in advance!
southy
Disclaimer:
Yes, I realise that such a behaviour will drain battery.

[Q] a nexus 5 e.csfb issue

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..

Categories

Resources