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..
Device Settings Guide, Tips & Discussions
Part 1 - Connections
If you're new to this series or want to see the index, please read Post #2 first.
Wi-Fi
Click on Gear icon besides any network:
View supported Network speed and security
Auto reconnect: If on, automatically connects to this network when Wi-Fi is ON. Switch it off for backup Wi-Fi i.e. you can keep it ON for 5 GHz network and OFF for 2.4 GHz so that it always connects to 5 GHz automatically.
Manage Router: Opens up the router admin page by going to your Gateway IP Address.
IP Settings: Choose from DHCP or Static. If you want to use custom DNS, you have to use Static IP. If you want to know the Network info like IP, Gateway or Subnet Mask, choose Static once and note the displayed info.
Proxy: Set manual or auto-config proxy here.
Click advanced to show:
View device's MAC address and allocated IPv6/IPv4. Learn about MAC and IPs here.
Metered Network: If you set a connection as metered, you or device can restrict background processes, big downloads and save data.
Randomized MAC: Devices are supposed to have a permanent MAC but this could be used to track you. From Android 10, you get an option to use randomized MAC each time your device connects to Wi-Fi. You can disable this if you use MAC Filtering on your router.
QR Scan (icon on top-right): Connect to Wi-Fi without entering password. Use a device that is already connected to the network and scan the QR code displayed by the former.
Menu > Wi-Fi Direct: Turn on Wi-Fi Direct on a nearby device as well to transfer files wirelessly and fastly. Works best with Samsung Devices and it does NOT require connection to a Wi-Fi network. You get speeds maxed out at the supported wireless speed of your devices! It is a better and more secure alternative than ShareIT or JioSwitch.
Menu > Advanced:
Sync with Samsung Cloud: Backup your Wi-Fi usernames and passwords and use the same on synced devices.
Switch to mobile data: If your Wi-Fi network quality drops, use mobile internet directly even if Wi-Fi is still connected (needs Mobile Data to be ON). You can add (Wi-Fi) Network Exceptions to prevent switching. Get notified to Allow individual apps to switch to mobile data i.e. if WhatsApp is blocked on your college Wi-Fi, you can allow WhatsApp to use Mobile data while keep using the Wi-Fi!
Turn on Wi-Fi Automatically: Your device will automatically enable Wi-Fi where you use it frequently. For example, you or your device can turn off your Wi-Fi when you go out and you won't need to enable it again when you get back home (you can configure the frequent networks after they appear here). Tasker used to handle this job for me (try IFTTT for simpler setup) but now the OEM solution is more optimized.
Wi-Fi power saving mode: For example, if you get WhatsApp messages every 30 minutes on average, the device learns about this traffic pattern and can toggle Wi-Fi accordingly to fetch notifications every 30 minutes. I keep this disabled as my usage pattern is dynamic like most of you. Better use App Sleep or Hibernation Apps like Greenify to save battery. Learn more about this mode here.
Wi-Fi control history: View apps that have toggled Wi-Fi recently. You can figure out if there's any culprit app that is toggling your Wi-Fi frequently when you have explicitly turned it off/on.
Hotspot 2.0: Automatically connects to APs that support Hotspot 2.0 or 802.11u. Network providers are themselves upgrading existing Wi-Fi in public areas like airports and encryption is a must for Hotspot 2.0 so you can trust and rely on it while you don't have to manually guess the right network. Learn more about Hotspot 2.0 here.
WPS push button; WPS PIN Entry: (Pie doesn't support WPS but Google says it's coming back, Read here) Connect the device to WiFi by pushing WPS button on the router or entering WPS PIN in case these are enabled on the router. Learn about WPS here.
Install network certificates: Normally not needed. Some organizations would need you to install certificates to access their domains. Same as what you do on a PC to install certificates.
Wi-Fi Calling
(Formerly VoLTE calling) Uses Wi-Fi to transmit voice instead of the mobile network but they still appear to be done via your SIM or number. This saves your mobile plan and also beneficial when you have low mobile network inside your home but good Wi-Fi! You'll see the SIMs in case the carrier supports VoLTE calling. #JioWaale
Bluetooth
When the Bluetooth is ON, you can STOP/SCAN for nearby devices manually. Keep BT on for playing with the following settings.
Menu > Advanced:
Sync with Samsung Cloud: Note that this only sync Samsung devices like Galaxy Home Speakers and Galaxy Buds.
Music Share: Enables your friends (or else) to connect with a speaker connected to your phone without requiring you to unpair and them to pair with the speaker. Useful in cases like you want your car to be always connected to your device. However, on a trip, your friend wants to play music from his phone while you drive. Get more explanation here.
Ringtone sync: Sync the ringtone you set on your phone to the connected speaker. I did not know they played different tones!
Bluetooth control history: Similar to 'WiFi control history' above.
Block pairing requests: Block spammers to request pairing.
Bluetooth scan history: Shows apps that scanned for BT devices. Review this once in a while as Apps can scan even when the BT is off!
[Discontinued] Dual Audio: Enables your device to connect to 2 different audio devices and play the same audio on both of them. Samsung explains this here.
[Discontinued] Media volume sync: In case the connected audio device supports this, you can change the player's volume by your device's volume rockers by enabling this i.e. you don't have to manually raise the volume to the fullest on both your device and the connected player to get the highest volume possible for your house party.
[Discontinued] Phone visibility: (Moved to Separate section after Bluetooth in Pie, please tell if it works for BT as well) Allow devices (with Samsung Connect) to find your device for connection. You can disable it unless you live in a Smart Home or transfer files from other devices more often. Learn more about this mode here.
NFC and contactless payments
It's turned ON by default on a new phone so do turn it OFF first. Samsung Pay will turn that ON if needed. Samsung Pay uses only NFC now starting from S21. MST is discontinued though no other brand could use this for payments. In case you don't know about MST (patented by LoopPay), must-read here. More information on the discontinuation in the FAQ.
[Discontinued] Android Beam: Allows you to share stuff when you tap your phone with some other-phone-with-already-enabled-NFC.
Contactless payments (Formerly Tap and pay): Select the default app for Payments and Others. Your default app will open up when you, for instance, tap your phone on an NFC-enabled POS (of course you need NFC to remain ON beforehand).
Pay with currently open app: By enabling, if currently opened app supports payment, it will used instead of the default app above. I have kept it enabled because I don't want Samsung Pay to open up when I know I am going to use GPay!
[Discontinued] Default NFC Method: By default and normally needed, 'Auto select'. In case you are the curious breed, learn about the different options here.
Flight Mode
Disables your operator's network. Since enabling this will also disable Wi-Fi and Bluetooth altogether, you can turn back these two on without toggling flight mode.
Mobile networks
Data roaming: Enable it if your carrier doesn't charge you for roaming or you're rich enough.
Network mode: By default, 'auto connect'. You can play with the options in case you're facing network mode changing issues or want to save battery (put to 2G only). If your region does not have 5G yet, you can go back to 4G/LTE to save battery!
Access Point Names: I recommend you to request or configure your operator's settings for the first time even if it had been automatically fetched. Nerdy guide here.
Network operators: Suggest usage?
Data usage
Data saver: Formerly known as 'Restrict background data'. Your background apps will stop using network data i.e. you'll receive WhatsApp notifications only when you open the app again. You can also whitelist apps in 'Allowed to use data while Data saver on'. This feature can help a lot in saving battery or making you check the phone less when you're hanging out with your girl. Me no girl so no enable!
Mobile data usage; Billing cycle and data warning: Do check this in a while to review the apps that use most of your mobile data (maybe you don't need those apps that much on mobile data); Change your operator billing cycle, set data warning and enable data limit in case your operator doesn't give you free GBs. The app options you change here will be reflected in the Data saver section above.
Mobile data only apps: You can choose apps that you only want to use mobile data. Useful in case your organization's Wi-Fi blocks some apps like WhatsApp. This is related to 'Allow individual apps to switch' in the Wi-Fi section.
Wi-Fi data usage; Restrict networks: Like mobile data, you can also review your Wi-Fi usage! Do review it once in a while to identify data-hungry apps that can affect battery and CPU as well. The apps you disable here for background usage will be blocked while Mobile Data is on OR the Wi-Fi is metered. Please confirm?
SIM card manager
Select Icon, Name and Network mode (described above) for the corresponding 'SIM slot' (not the SIM). Select preferred slot for calls, messaging and data. Learn about Smart Dual SIM here.
Mobile Hotspot and Tethering
Mobile Hotspot > Advanced:
Wi-Fi sharing: In addition to mobile data, you can also share your Wi-Fi. This can be helpful in case you don't want to reveal your network or its credentials or don't know about them. Also, your device can become a repeater for devices that are too far away from the Wi-Fi (keep your phone on charging).
Security: Use 'WPA2/WPA3-Personal' (Learn about wireless encryption here).
Timeout: Keep timeout low so that hotspot turns itself OFF earlier in case there's no client or change to 'Never Timeout' if you are going to need it for some time.
Hidden network: Enable 'Hide my device' to stop exposing your SSID.
Power saving mode: Similar to PMS in Wi-Fi Advanced. Keep Protected Management Frames (PMF) on by default and change in case the client doesn't support.
[Discontinued] Menu > Allowed Devices: Enter MAC addresses of clients you want only to connect to your hotspot. Same as MAC filtering in routers.
Mobile Hotspot > Auto Hotspot: You might get this ON by default. Turn it off! This enables your or family devices to share your internet connection via Hotspot. You know when you need it!
Bluetooth tethering; USB tethering; Ethernet tethering: Learn about BT/USB tethering here.
More connection settings
Advanced Calling & Messaging: Some iMessage kinda thing? Anyone?
Nearby device scanning: Although it uses Bluetooth Low Energy, I have it disabled. If you enable it, you get notifications for nearby devices like TVs that support connections through your device (will annoy you at airports).
Printing: Do download Google Cloud Print and any other printing plugin required by your or your organization's printer.
[Discontinued] MirrorLink: Learn more here.
[Discontinued] Download Booster: Uses both WiFi and LTE at the same time to download apps over 30MB from Play Store and Galaxy Apps. In case you want that app as soon as possible.
VPN: Configure your VPNs here in case you have. I use Psiphon. You can also manually configure profiles as you do on PC.
Ethernet: Yes, you can use a wired connection on your device too. Discussions here.
Private DNS: Supports DNS over HTTP/TCP and I recommend reading about this here. I use 1dot1dot1dot1.cloudflare-dns.com.
Series - Full Menu Guide Explained
Series - Device Settings Menu Guide
Hey XDA! I just got free from the initial setup of my Galaxy S22 Ultra. I don't know how many of you do this but I'm one of a kind that gives a considerable amount of time to explore every setting, feature and every single option whenever I get a new device or even when I factory reset the existing one. It's been years since I have started with this curiosity and I have never found an 'all-in-one' menu guide to explain each and every option in the device. Yes, you could also simply google the option you want to know about but how about compiling all of them in one guide? I don't know if this experiment would work or not but here's I am starting with this. I have spent the past three weeks taking out time whenever I could to compile this guide.
There are a couple of reasons I had decided upon to start with this series. Firstly, I want to help newbies (or even experienced) out there to explore and know about every feature or option your device could offer. I have seen many duplicate threads that are created every day to query fellow users even about an individual but unfamiliar option in the settings. I intend to do my bit to clear this clutter and help potential askers to get answers beforehand. Secondly, this guide could serve as a manual in case you want to find or get briefed about an option. You could then simply 'Find in a page' over the threads or simply use XDA's 'search in the thread' option to save your time. Thirdly, since I've broken the settings into different threads, this could help users engage and discuss over a particular device's super-menu and spread their knowledge, come up with new ideas and explore more of their devices. Fourthly, this series is not constrained to Note9 only. The settings on every Android device out there is similar and you would be able to find any common to your device settings here as well. Fifthly, since I have provided links and sources to some options, this can serve as directory map as well. Sixthly, this guide consists of tips for many options that you won't probably find normally.
This guide is intended and recommended to be read by anyone at least once. If you're reading a thread for the first, I recommend you to open up the corresponding settings in your phone and read the settings description in case there is. All the threads are arranged in the same order as the settings would come up. You could then simply read out my description of the same, my selected configuration and hyperlinks to some articles or videos in case you're the curious breed. This guide is strongly recommended after a fresh start. I want you all to give some time to explore each and every option your device can offer.
Hope this experiment lives up to the marks. Both criticism and appreciation are greatly needed and appreciated. Please comment.
I've tried to explain each option you could find by going deep into any setting. No matter whatever links I have provided, I will feel grateful if you want me to explain any feature more than I have done already. Please ask questions related to any settings. Do provide me suggestions and your take on my configuration. Please provide me with more guides and articles for a particular feature. I want to have the precious contribution of XDA members in this guide. Discussion over any feature, setting, your configuration, did-you-knows and anything else is greatly appreciated. This is a newbie-friendly place so don't hesitate to ask questions - besides the fellow XDA members, I'm always here for you.
Regards,
Paras Lehana
Index
Part 1 - Connections
Part 2 - Sounds and vibration, Notifications, Wallpaper and themes
Part 3 - Display, Lock screen, Biometrics and security
Part 4 - Advanced features, Device maintenance, Apps
Part 5 - Cloud and accounts, Google, Accessibility, General management, Software update, User manual, About phone, Developer options
FAQs
Why did Samsung discontinue MST for Samsung Pay? (Contributed by @sansart)
Ans: With big card companies like Mastercard ditching Magnetic Stripes due to security concerns, Samsung could be taking a step in this direction. Starting with Galaxy S21, Samsung discontinued MST and, in a statement, it added: "Due to the rapid adoption of near field communication (NFC) technology by consumers and businesses, beginning with devices launched in 2021, Samsung Pay will focus its support on NFC transactions, across the Galaxy portfolio. While future devices will no longer include magnetic stripe technology (MST), customers with previous, compatible Galaxy devices will be able to continue using Samsung Pay, including MST." (Source: The Verge)
Mastercard nicely explains about ditching Magnetic Stripes here: Swiping left on magnetic stripes
Good read, thanks! I think your NFC section needs updating though, Samsung no longer uses MST.
Updated. FAQ too. Thank you for contributing!
Since S22U is my upgrade after spending over 3 years with Note 9, I was doubting about the MST thing after the payment failed once. Now I have read about it. Thanks again!
sansart said:
Good read, thanks! I think your NFC section needs updating though, Samsung no longer uses MST.
Click to expand...
Click to collapse