Jump to content

Network initiated change


mhammett

Recommended Posts

I see this on my Sprint EVO LTE and my Verizon GS3, so it spans networks and manufacturers. Why can't the network tell the handset to rescan when it sees the handset using a band that's less than optimal? Both phones sit on 3G when LTE is available. The VZ phone will sit on 1x for a while. I understand scan intervals and whatnot on the handset, but the network knows what the handset is using, what the network is capable of in that area and what the handset is capable of.

 

Sent from my EVO using Tapatalk 2

 

 

Link to comment
Share on other sites

I see this on my Sprint EVO LTE and my Verizon GS3, so it spans networks and manufacturers. Why can't the network tell the handset to rescan when it sees the handset using a band that's less than optimal? Both phones sit on 3G when LTE is available. The VZ phone will sit on 1x for a while. I understand scan intervals and whatnot on the handset, but the network knows what the handset is using, what the network is capable of in that area and what the handset is capable of.

 

Sent from my EVO using Tapatalk 2Ver

Very good question.  I have had that same question for about a year now.  The network should be smart enough to control each handset and direct it to the best network.  This should be done on the voice side and the data aside.  The network should not allow the handset to make a call on 1900 if the levels are getting weak.  If the network determines the signal from the handset if about -100, it should just move the handset to the 800 network.  Alternatively, if the level from the handset is extremely good, move the handset from the 800 network to the 1900 network. On the voice side, this might only be done when the phone is idle.  But on the data side, it could be done while active on data. 

Link to comment
Share on other sites

I am formulating an article on this topic for my engineering series on The Wall.  But I do not know when the article will be ready to publish.  So, I will answer some of the questions posed and reveal a few pieces of info later this morning.

 

AJ

  • Like 7
Link to comment
Share on other sites

I would like to note that I'm not looking to have the network force the handset to a certain technology or band. Just have the network tell the handset, "Ya know what, I think you could be doing something better. Rescan when you get the chance." It's in the best interest of the network to have the handsets on the best technology assuming sufficient modulation to not be a drag.

  • Like 1
Link to comment
Share on other sites

I've thought that, too, with my EVO LTE.  There are some places where I KNOW there is LTE, yet it stays on 3G.  In the same places, sometimes it will connect on its own, other times I have to reset the connection with Signal Check Pro.  I was assuming it was just related to the "poor reception" that everyone claims plagues the EVO LTE.

Link to comment
Share on other sites

I would like to note that I'm not looking to have the network force the handset to a certain technology or band. Just have the network tell the handset, "Ya know what, I think you could be doing something better. Rescan when you get the chance." It's in the best interest of the network to have the handsets on the best technology assuming sufficient modulation to not be a drag.

Exactly.   I do not care if I am on 1900, 800, or 2600.   Just have the system be smart enough to place my phone on the network that is going to work best for me. With today's technology and software, this should be possible. It should already be accomplished. ALSO, while this is surely more difficult, figure out how to allow a voice call to transfer between 1900, 800, 2600 and avoid a dropped call. Surely there has to be some way to make this happen. Sure, this is not easy to fix, but do it somehow. Pin down the

various manufacturers and software guys and get it done.

Link to comment
Share on other sites

I've thought that, too, with my EVO LTE. There are some places where I KNOW there is LTE, yet it stays on 3G. In the same places, sometimes it will connect on its own, other times I have to reset the connection with Signal Check Pro. I was assuming it was just related to the "poor reception" that everyone claims plagues the EVO LTE.

Well, if you've spent time in an area without LTE, then enter LTE, it mat take up to 45 minutes to reacquire LTE. As I understand it, it'll check often for twenty minutes, then go to every 45 minutes. Annoying, but not what I originally thought about. If I temporarily lose LTE or even 3G, it'll park on the next lower technology seemingly forever. Its worse when data is being used.

 

Sent from my EVO using Tapatalk 2

 

 

Link to comment
Share on other sites

Well, if you've spent time in an area without LTE, then enter LTE, it mat take up to 45 minutes to reacquire LTE. As I understand it, it'll check often for twenty minutes, then go to every 45 minutes. Annoying, but not what I originally thought about. If I temporarily lose LTE or even 3G, it'll park on the next lower technology seemingly forever. Its worse when data is being used.

 

Sent from my EVO using Tapatalk 2

 

Hm, interesting.  That explains some things!  Is the only way to change the scan time to root it?

Link to comment
Share on other sites

Rather than write one or two lengthy posts that take too long to complete, I will address some questions/concerns individually in short posts.

 

I see this on my Sprint EVO LTE and my Verizon GS3, so it spans networks and manufacturers. Why can't the network tell the handset to rescan when it sees the handset using a band that's less than optimal?

 

The CDMA2000 protocol is roughly 15 years old, not to mention, 3GPP2.  To my knowledge, it does not contain any sync or paging channel message for the network to redirect a mobile to a 3GPP or IEEE airlink.  Even W-CDMA, to my knowledge, cannot redirect a mobile to LTE -- and both W-CDMA and LTE are 3GPP airlinks.  In all cases, the mobile is responsible for detecting and acquiring LTE or WiMAX based upon a scan timer.

 

Like it or not, when old technology is standardized, it does not anticipate interfacing with all the iterations of new technology.

 

Even if such a rescan flag were possible in the CDMA2000 protocol, the other issue is it could cause a mobile within a hybrid CDMA2000/LTE cell to get stuck in an LTE rescan loop.  The mobile could be near the cell edge and have decent CDMA1X/EV-DO signal but only fringe or unusable LTE signal, as we know that LTE is a much less robust airlink.  The constant rescanning in such a situation would drain the battery in short order.

 

AJ

  • Like 1
Link to comment
Share on other sites

The network should not allow the handset to make a call on 1900 if the levels are getting weak.  If the network determines the signal from the handset if about -100, it should just move the handset to the 800 network.

Due to loading or signal strength, the network can set up a traffic channel on another carrier channel, even in another band class. That has happened for years on VZW's CDMA1X 850/1900 network.  It is no big deal.

 

On the voice side, this might only be done when the phone is idle.

No, redirecting an idle mobile to another carrier channel, while possible, is rare.  That form of redirection tends to be used only in certain circumstances and locations.  The more likely form of redirection is active state, as I have described above.

 

AJ

  • Like 1
Link to comment
Share on other sites

That's what I assumed with my Evo 3D. I know if I sit on the 4g screen and keep hitting scan it just destroys my battery. What would be nice is if the phone detects a better signal and can measure the strength and possibly have a routine to watch it over a period of a user defined time (like pick from 30 secs, 1 minute, 2 minutes, 5 minutes) and it stays stable, it should automatically switch to that band. Of course, it's easy to say it would be a good feature but how possible would it be to implement?

Link to comment
Share on other sites

The network could also send out the scan request to only handsets over a certain dB. This would prevent phones outside of coverage of a better band continually scanning.

 

The network wouldn't be forcing changes. Just hint to the handset that it should look for something better.

 

Sent from my EVO using Tapatalk 2

 

 

Link to comment
Share on other sites

So, to mildly hijack this thread...

 

I know we're just now seeing multiple bands in use with Sprint; have we seen the ability for the network to initiate a handoff from one band to another? In other words, can the network say "Hey, quit connecting to 1900, there's 2500 around you, scan for that already!" or something similar? Will multi-band devices do this on their own?

 

Basically, I would be worried about devices "sticking" on 800 LTE, simply because it's the strongest (and most readily available) signal, and never handing off to 1900 or 2500, even when available, leading to speeds on 800 quickly degrading. After all, there only ever will be one 5x5 FD-LTE carrier on ESMR 800. With PCS 1900, I know Sprint can add a second LTE carrier in many locations, and with BRS 2500, well, we've got spectrum to spare for the moment.

Link to comment
Share on other sites

So, to mildly hijack this thread...

 

I know we're just now seeing multiple bands in use with Sprint; have we seen the ability for the network to initiate a handoff from one band to another? In other words, can the network say "Hey, quit connecting to 1900, there's 2500 around you, scan for that already!" or something similar? Will multi-band devices do this on their own?

 

Basically, I would be worried about devices "sticking" on 800 LTE, simply because it's the strongest (and most readily available) signal, and never handing off to 1900 or 2500, even when available, leading to speeds on 800 quickly degrading. After all, there only ever will be one 5x5 FD-LTE carrier on ESMR 800. With PCS 1900, I know Sprint can add a second LTE carrier in many locations, and with BRS 2500, well, we've got spectrum to spare for the moment.

Like AJ said it's up to the device to select which band it gets, however you have to take into account that band 41 will likely be the first priority so when it scans it should attach to it until the signal starts to deteriorate.  

Link to comment
Share on other sites

Like AJ said it's up to the device to select which band it gets...  

 

That is largely true for CDMA2000 but not necessarily so for LTE.

 

AJ

Link to comment
Share on other sites

You can't prioritize bands in LTE?

 

You will have to elaborate what you mean by that.

 

AJ

Link to comment
Share on other sites

I saw a document today where Sprint plans to have the network determine your LTE band in certain instances, like heavy traffic, traffic balancing, carrier problem, etc. Your device will pick first, but it may be overridden by the network if it deems it necessary.

 

Robert via Samsung Galaxy Note 8.0 using Tapatalk

 

 

  • Like 6
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • large.unreadcontent.png.6ef00db54e758d06

  • gallery_1_23_9202.png

  • Posts

    • Uploaded data without issues on Friday. Now with the latest update I am getting "Cluster #1 skipped: invalid file format detected. File exported for inspection." Doing same with all other clusters. Did this on 4 phones in a row.  Seems to work on s24 ultra just fine. On s21 ultra it says "web data upload failed. No data to send" although 8800 records were displayed. Now gives same error as above. I have not sent the data from 3 other phones.  All should have latest update.
    • After several months of testing, an update to SignalCheck Pro is rolling out on Google Play. It may take up to 48 hours to become available for download. Notable changes include: Added option to display site notes for NSA 5G-NR cells. Enabling this new option (Preferences > Display Settings > Show NSA 5G-NR Site Notes) will cause the app to make an "educated guess" as to what the most appropriate site note is linked to the connected NSA 5G cell, using the PCI and the device location. If it finds an existing entry that is likely to be relevant, it will display the note along with the distance from where the strongest signal from that cell was logged. While connected to NSA 5G, these notes cannot be edited; a valid NCI is required to add/edit notes and that information is not available on NSA connections.   Added option to log cells with missing/invalid PLMN (such as NSA 5G-NR cells). Users asked for the ability to log data for NSA 5G, so a new option (Preferences > Logger Settings > Log Cells with Missing PLMN) will permit this.   Added option to display LTE info above 5G-NR info. Enabling this new option (Preferences > Display Settings > Show LTE Cells Above 5G-NR Cells) shows the same information that is currently displayed, but moves the LTE information above the 5G-NR information. Other changes: Code optimizations and enhancements. Improved Android 15 compatibility. Overhauled Purchases module. Resolved force closes impacting some GSM/LTE connections. Resolved issue with improper 5G-NR PLMN display when NR/LTE PLMNs did not match. Resolved issue with improper PLMN display with single-digit MNCs. Resolved issue with incorrect 5G-NR bands displayed on some devices due to Android bug. Resolved issue with incorrect number of neighbor cells displayed when some cells were unknown. Resolved issue with missing 5G-NR data when sector display is enabled. Resolved issue with saving 5G-NR site notes when NR/LTE PLMNs did not match. Resolved issue with settings to log missing GCI/NCI/TAC/PLMN being ignored. Resolved issues with web data export function. Updated internal libraries. Updated provider database. Updated target API to Android 15. I appreciate all of your support, and a big thank you to the members of the Beta Crew that help with testing and feedback!
    • Oct security update is out.
    • Stopped by again today and the antennas are up but it isn't live just yet. If other Sprint conversions are anything to go by it'll likely take about a month for the site to go live.
    • It is an Android bug that was reportedly fixed in August 2023 but definitely has not been. I have implemented numerous workarounds in SCP to correct the NR bands the app displays. The OS ignores the possibility that many NR-ARFCNs are valid across multiple bands.. it reports the lowest NR band that is valid for the current ARFCN. In your example, channel 432530 can be n1, n65, or n66.. so the OS just (lazily) reports n1.   Awesome, thanks! I will add an n65 override also.
  • Recently Browsing

    • No registered users viewing this page.
×
×
  • Create New...