Sprint Community is Read Only. Please use the My Sprint app or Sprint.com to manage your account. If you need assistance, please visit Sprint.com/chat or visit community.t-mobile.com
Sprint Community is Read Only. Please use the My Sprint app or Sprint.com to manage your account. If you need assistance, please visit Sprint.com/chat or visit community.t-mobile.com
Sprint Community
Showing results for 
Search instead for 
Did you mean: 

LTE/3G inconsistent, spontaneous roaming, can't answer calls, incorrect time


LTE/3G inconsistent, spontaneous roaming, can't answer calls, incorrect time

I see lots of individual issues posted, but I haven't seen multiple network-wish issues reported simultaneously. I'm wondering if anybody else has seen these issues.

I've had my Nexus 5 since first available. I preordered with Sprint when it was released. I haven't had any issues until the last week of February.

The issues started with the incorrect time. I was set to automatic date and time/time zone. The first morning I noticed this, the day was an hour fast. The time corrected itself during the day. 2 days later, the phone was an hour behind when I woke up. Again, it corrected during the day. The next day, the phone was an hour fast again. In addition to being annoying and not sounding my morning alarm at the correct time, the inconsistent behavior is confusing. The random incorrect time has started happening again mid March, being an hour behind.

Now in March, I'm plagued with more unpredictable behavior. Some times, I am unable to answer a phone call from a location I've been in for years. I try to slide to answer, but the call won't connect, and the roaming R appears on my signal status bar. This happens with multiple combinations of Preferred Network Type and System Select options. And I've tried all 8 possible combinations of the settings.

The inability to answer calls is often paired with the warning triangle stating that I've Entered Data Roaming. I can't make the error go away without restarting the phone. Sometimes the error status away for hours, sometimes it comes back after a few minutes.

Further, I regularly see the phone toggling between LTE and 3G while sitting still for hours on end. There is no consistency between network availability and location.

Here's the kicker: either all or all but one of these issues happen at the same time, at the same location. A location that none of my last 3 phones with Sprint had issues, and a location that the Nexus 5 didn't have issues until recently. In other places, I have no problems, and the phone works well enough (I'd still like to have data connectivity simultaneously while making a phone call, and a voicemail notification would be great).

I'm leaning toward this being a Sprint network issue because it seems to be location based. I've also used the Nexus 5 with other carriers, and I haven't seen any of these behaviors. I'd really like to be able to use my phone without having to think about it. I've been using Sprint that way for about 12 years, and I've only had to contact them about once a year until recently. Now, I'm extremely frustrated with the amount of time I have to put in just to figure out how to receive a phone call.


POTOHEAD1 -- I apologize for the inconvenience. I am seeing some problems with the tower nearest to Telegraph/Pioneer. I've pinpointed the location and sent a report to our network team so that this problem can be resolved as soon as possible. Thank you. -- Toya, Sprint Social Care

I'm going to apologize ahead of time for calling BS on what you are saying. Every person that has reported this issue gets the same answer there's a problem with the towers in your area. So I cannot believe that every person with an issue similar to the one I have with a Nexus 5 mind you that the towers happen to be down or with problems in that area. I also said that the problem that I am having at my house is the same issue that I had in a completely different city far away from my house, you are going to tell me that they're tower in that city also has issues? That doesn't make any sense, not only that, but I have family members that live in my house, 3 more people that live in my house what they use sprint, one of them has a 4G LTE HTC, the other one has an lg optimus and one an iPhone. None of them are having any issues with their phones, so how can you tell me that the towers are down or having issues and I'm the only one being affected. Again you giving us an answer just to give us an answer doesn't do anything else than frustrate us. Stop testing us like if we are idiots because we aren't.


This is the first time I've set the time manually and left it that way for an extended amount of time. The result is that when I go into an area with bad timing from the network, the time notifications on my texts and messages are now an hour off. So, if I receive a text right now, it says that it arrived an hour ago. Unless immediately checking messages as they arrive, I can't tell which have good time stamps. It throws off real life communications like "I'm at this place. Cone meet me."

Is it possible that the phone displays the correct time because it's set manually, but the messages from the network are stamped an hour behind? That would make sense because the towers were telling my phone it was an hour behind when I used network timing.



It is possible for sure. When messages come in they are time stamped by the tower you are connected to, not the device receiving them. I do understand how that can cause conversations to get out of whack when depending on the texts. As the tower work continues that will clear up.

Jon H. Sprint Social Care Team

Further updates with setting the time manually while in an area where the towers are an hour behind: While the clock display on my phone is still accurate, there are more timing issues that just time stamps on text messages and alerts.

The entire Google calendar is shifted by an hour. So, an appointment that I set with a good time actually adjusts to be an hour behind when I am near a bad tower and have to manualy set the time in my phone. So, the manual time setting actually hurts the operation of the phone. This is no longer an inconvenience about receiving text messages. This is now affecting the ability to make and keep appointments.

I tried it out based on advice from this forum, but this has turned out to not be an acceptable solution.


Do you know of other Sprint users in this area that are seeing the same issue with the incorrect time? Also, we would like to see if this has been reported. What is the zip code and some close cross streets to where you see this issue?
Sprint Social Care

I'm sorry I'm not sure if you are able to read the previous messages on this thread abs other parts of the forum. But if you notice there is a lot of peruke having this issue including me. As I write this I'm in CA currently my phone displays 11:08pm real time is 12:08am. I've had the same issues with my appointments, I almost missed a couple of work related appointments because I'd the time. At the time the time zone changes by itself to pacific standard time metlakatla. I've again we need this resolved, there are people living in my house with different brand phones in sprint who are not having this issues. So could you please give us an answer?



Both phones on my account have experienced this. 29485 at Wescott Blvd and Oak Forest Blvd, and 29406 at Aviation Ave and Core Rd, and at 95 GA Hwy 247 South in 31088. This spans across one city and extends into the middle of another state.


DOLFINGIRL, Thanks for the provided information. I have taken a look in 29485 at Wescott Blvd and Oak Forest Blvd and see tat there is a tower down and we are currently working on resolving this issue so that the tower will be performing as expected. In 29406 at Aviation Ave and Core Rd I see that all the towers are performing as expected. Lastly, in the area of 95 GA Hwy 247 South in 31088 everything is performing as expected. When did this issue begin? I would like to see if it started the same time that the tower went down. Let me know. *Jazmine Social Care


This issue is a symptoms of the upgrades taking place. These upgrades, while taking place, can cause the time zone issue. This will be resolved in those areas affected as the upgrades near completion. Manually setting the time on the device and changing it from automatic will help a great deal.

Jon H.

Sprint Social Care Team

hey, i made a thread over at xda on the nexus 5 e.csfb issue, that helped me -


from within that, i delved into the inner working of sprint half baked network vision set-up nationwide,

what i found, is that the LTE part is actually an overlay on the cdma / evdo network (with sprint), so in essence, it's two separate networks the triband phones with single radio paths have to inter-roam between (or hand-off) to & from from data to voice services, & why they can't do them both at the same time.. when we  at times saw *roaming* with full LTE service in incoming calls, it wasn't a flux, the nexus 5 was ACTUALLY inter-roaming within the network, from the LTE channel to the 1xrtt channel to serve the call..

somewhere in between, the phone app would get hung up in the processing because there was a fault on the network side -

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

that's where ehrpd comes to play, to *BRIDGE* lte & cdma / 1xrtt for seemless hand-offs, **lte doesn't have the capabilities for circiut switching within it's framework, cdma does, but, lte needs a flattened IP (internet protocol) bridge to evdo data, which then splits to 1xrtt  for voice, for seemless transparent work..

on the time thingy, cdma should provide automatic network time sync from the cell sites to your phone, since those very towers are gps sync'd.. obviously when parked in LTE, that link somehow, was broken..

Community News

Sprint Community is Read Only. Please use the My Sprint app or Sprint.com to manage your account. If you need assistance, please visit Sprint.com/chat or visit community.t-mobile.com
Please try Searching the Community, we have many questions already answered, you can also check out the Knowledge base
If you need immediate assistance after hours please visit Sprint Chat