Daniel's been doing some phone archaeology again. He switched to a cheaper virtual operator about a month ago, because he's got this long-term plan to go voice over IP first, with telephony through Zapier and an eSIM doing nothing but data. So he freed up budget for the data plan. Same handset, same apartment, same city. He checked the frequency bands. He made sure the data allowance would carry him. And the result is night and day in the wrong direction. The phone says 5G, but whole chunks of Jerusalem just drop out, and sometimes a simple text message hangs. His question is whether there's a way to read handset diagnostics, without being a network engineer, that would tell him which provider actually has the most reliable coverage in his area. Not the fastest. The most stable. And he's wondering whether the phone is latching onto a spotty higher-generation frequency and then dropping it, over and over, because that's what it feels like.
The latching hypothesis is real. It has a name. Ping-pong handover. The phone grabs a cell, holds it for a few seconds, the network or the phone decides a different cell looks marginally better, it hands over, the radio stack resets, throughput dives, and then it happens again. There's a diagnostic signature for it. Time of stay on the target cell below five seconds in more than five percent of cases. Which maps almost exactly onto what Daniel's describing.
So the phone is doing the network equivalent of changing lanes every four seconds in traffic and wondering why it never gets anywhere.
That's the image. And the thing is, each handover resets the RLC stack, the radio link control layer. Every reset means the data that was in flight gets retransmitted. So signal strength looks fine. RSRP looks fine. But throughput is garbage because the connection keeps getting torn down and rebuilt.
Before we get to the diagnostic side, I want to sit with the thing Daniel said he wasn't expecting. Same location, same handset, frequency compatibility checked. And the performance is dramatically worse. Most people would assume that means the cheap provider has worse coverage. But that's not what's happening here, is it.
No. And this is the part that most coverage of this topic gets exactly backwards. The radio link is a red herring. When researchers actually measured this properly, they found no statistically significant difference in signal strength, cell IDs, or link-layer technology between a host network and the virtual operators running on it. Same towers, same frequencies, same signal. The degradation was in round trip time, TCP retransmissions, and radio dormancy. Network-side problems, not radio-side problems.
So the bars on the phone are telling the truth. The signal is fine. The problem is what happens after the signal arrives.
The scheduler. The base station has a policy decision to make when a cell gets congested. Whose packets go first. And the host network's own subscribers are at the front of the queue. The virtual operator's subscribers get whatever capacity is left over. It's not a hardware limit. It's a firmware policy. The direct SIM gets faster service not because the signal is different, but because the scheduling logic assigns it higher priority.
Which means Daniel could stand in the exact same spot with two SIMs, watch both phones show full 5G, and one of them is still going to crawl.
There's a structural reason on top of that. The virtual operator buys wholesale bandwidth at what's called a point of interface. A logical junction with the host network. It's a fixed pipe. When that pipe fills up, all of the virtual operator's subscribers share whatever's left. Host network traffic never passes through that pipe at all. It stays in the host's own capacity pools. So you've got two mechanisms. Priority tiering and a wholesale capacity cap. Either one will do it. Together they explain the night and day.
Daniel's instinct was to check frequency compatibility. And that checked out. Because that was never the problem. It's like checking that your car has the right tires when the issue is that you're only allowed on the road between two and four in the morning.
The measurement study that nailed this down is from twenty fourteen. Zarinni and a group at Stony Brook and Carnegie Mellon. Thirteen thousand measurements, eleven locations, three months, four identical phones. One on the base carrier, three on virtual operators. The base carrier often performed significantly better. Some virtual operators failed to load ten percent or more of YouTube requests. One had a median video startup delay of twenty three seconds. And when they checked the signal data, there was no meaningful difference. The problem was never the radio.
Twenty three seconds to start a video. That's not a coverage problem. That's a queueing problem.
They found something else that's worth naming. In the long page loads for the worst virtual operator, eighty percent of the time was TCP idle or dormant periods. The radio wasn't doing anything. The connection was just sitting there. They attributed it to radio resource control misconfiguration. The network wasn't even trying.
So Daniel's phone isn't necessarily being throttled in the way people imagine. It's being ignored in bursts.
And here's the thing that complicates the story. This isn't universal. A UK white paper from PolicyTracker compared British virtual operators with their parent networks and found the differences were relatively small. In some comparisons, the virtual operator scored better than the parent. Lebara on Vodafone. So the night and day experience is real for Daniel, but it's not a law of nature. It depends on the host network, the wholesale deal, and how aggressively the host manages congestion.
Which brings us to the practical question. How does Daniel figure out what's actually happening on his handset, and whether another provider would be more stable.
The first thing to say is that his instinct about passive measurement is sound. Android exposes low-level radio data through the CellInfo and TelephonyManager APIs. Reference signal received power, reference signal received quality, signal to interference plus noise ratio, band, cell ID. Apps can read all of that without root. That's exactly what CellMapper and SigBench and Network Survey consume. The phone can passively observe signal quality from any network the radio can see.
But there's a limit. The phone can see signal quality. It cannot see another provider's priority tier. That's network-side policy. Invisible without an active SIM on that network.
Correct. And that's the gap. Crowdsourced tools measure reception. They don't measure congestion behaviour. So Daniel can stand in his apartment and see that provider A has a stronger RSRP on band twenty eight than provider B. What he can't see is whether provider A's scheduler will serve him first or last at five thirty in the afternoon.
So the question becomes, what's the diagnostic that actually distinguishes his two hypotheses. One, the phone is ping-ponging between frequencies and a setting change would fix it. Two, the provider is deprioritizing him and no setting will fix it.
The boring answer is the best one. Run the same speed test at the same location during peak hours and off-peak hours. Peak is roughly seven thirty to nine thirty in the morning and five to nine in the evening. Off-peak is ten at night to six in the morning. If it's fast off-peak and slow during rush hour, in the same spot, that's the signature of congestion-driven deprioritization. It rules out coverage issues, APN misconfiguration, and device problems in one shot.
Because a coverage problem doesn't care what time it is. A bad frequency doesn't care what time it is. Congestion does.
And Daniel's priority is stability. So the metric he should care about is not RSRP. That's strength. It's RSRQ and SINR. Quality. Reference signal received quality tells you how clean the signal is. Signal to interference plus noise ratio tells you how much garbage is competing with it. A strong signal with terrible quality is a crowded room. You can hear someone shouting, but you can't make out the words.
The Starlink direct to cell measurements made that distinction nicely. Their median RSRP was twenty four decibels lower than terrestrial. But the RSRQ was three decibels higher. Weaker signal, cleaner channel. For stability, Daniel wants clean, not loud.
And the ping-pong detection is about handover frequency and time on cell. CellMapper-style logs will show that over time. If the phone is spending four seconds on a cell and then jumping, the log will show a string of short dwell times. That's the smoking gun for the latching hypothesis.
Let's talk about the setting change Daniel mentioned. Prefer 4G. What does that actually do.
The hidden radio info menu, the star hash star hash four six three six hash star hash star code, exposes a preferred network type dropdown. On a lot of Android phones you can set it to LTE only, or LTE and UMTS. The idea is to stop the phone from reaching for a 5G non-standalone anchor that's flaky and falling back constantly. In 5G non-standalone, the phone is always anchored on LTE anyway. The 5G leg gets added and removed dynamically. There's no real handover between non-standalone and LTE. So if the 5G leg is the thing flapping, pinning to LTE removes the flap.
But there's a cost.
A real one. George Georgovassilis wrote this up in twenty twenty and he's blunt about it. If you pin a higher mode and the signal gets bad, the phone won't fall back to 2G. Phone calls will not be possible. Not even emergency calls. VoLTE maturity is spotty. You can be standing on a strong 4G signal and still not be able to place a call because the fallback path is gone. He once took his phone offline entirely and needed a restart.
For a voice over IP first user, that's a sharper warning than for most. Daniel's calls are going to ride the data path anyway. If the data path is deprioritized, pinning to 4G doesn't fix the congestion. It just removes one failure mode and adds another.
And on Samsung phones the four six three six code often doesn't work at all. You need a shortcut maker app to launch the hidden radio info activity, or one of the force LTE apps from the forums. It's doable, but it's fiddly.
So the decision tree for Daniel is something like this. First, run the peak versus off-peak test. If the difference is dramatic, it's deprioritization, and no setting change will save him. He needs a different provider or a higher tier.
Second, if the difference is small, then look at the logs. Check time on cell. If he sees short dwell times and frequent handovers, the ping-pong hypothesis is right, and pinning to 4G or changing the preferred network type might actually help. Third, check the APN. Misconfigured APN is a separate cause of slow virtual operator speeds. It can prevent full speed or stop data entirely. It's the cheapest thing to rule out.
And fourth, the boring stuff. Toggle airplane mode. Reset the network settings. Rule out a stale radio stack before concluding the provider is cursed.
There's a survivorship bias in the crowdsourced data too. CellMapper depends on people running the app. If nobody's mapped a given street, the absence of coverage on the map doesn't mean there's no coverage there. It means nobody's walked down that street with the app open. A provider that looks bad on CellMapper might just have fewer contributors.
Which is the same problem as the carrier maps, inverted. Carrier maps show predicted coverage. Crowdsourced maps show measured reception. But the measurement is only as good as the number of people doing the measuring.
CoverageMap's pitch is exactly that distinction. Carrier coverage maps show what a network is predicted to do. Signal mapping shows what your phone actually receives. The catch is the word actually. Actually receives, in the places where someone was actually running the app.
For Daniel's specific situation, living in Jerusalem, the crowdsourced data is probably decent. Dense city, lots of phones, lots of contributors. The problem is that crowdsourced data won't tell him about priority tier. It'll tell him which provider has the strongest signal on his street. It won't tell him which provider will serve him first at rush hour.
And his stated priority is reliability. So the research question changes. Most people ask which provider is fastest. Daniel's asking which provider is most stable. That's a different query. For stability, the relevant metrics are RSRQ, SINR, and handover frequency. Not RSRP and not a speed test number.
A speed test is a snapshot. Stability is a time series. One tells you the peak. The other tells you whether the peak is there when you need it.
And there's a knock-on effect with his voice over IP plan. Wi-Fi calling bypasses cellular congestion entirely for calls and texts. But it doesn't help with mobile data performance. So a voice over IP first user on a deprioritized virtual operator is exposed precisely on the data path their calls depend on. If the data pipe is congested, the call drops, regardless of what the signal bars say.
That's the part I'd want Daniel to sit with. He's optimizing for budget to fund a data plan. But the data plan he's funding is the thing that's failing. If the whole point of the virtual operator is to be a dumb pipe for data, then the pipe being dumb in the wrong way undermines the entire architecture.
The fix might be as simple as moving up one tier on the same host network. Or choosing a virtual operator that rides a different host. The PolicyTracker data suggests the gap isn't always huge. Some virtual operators are fine. The question is which host network in Jerusalem has the least congested wholesale pipe at the times Daniel actually uses his phone.
And that's a question the handset can't answer directly. The handset can tell him the signal quality of every network it can see. It cannot tell him the queueing policy of any of them.
Which is why the peak versus off-peak test is the single most decisive diagnostic. It's boring, it's free, and it distinguishes the two hypotheses in one afternoon. If Daniel runs that test and sees a huge swing, he has his answer. The provider is deprioritizing him. No amount of log analysis will change that.
If the swing is small, then the problem is local. The handset, the APN, the ping-pong. And those are fixable without changing provider.
Let me add one more layer on the ping-pong. The HiCellTek guide lists the signature as time of stay below five seconds on the target cell in more than five percent of cases. But it also lists a symptom that maps exactly onto what Daniel described. Unstable user throughput while RSRP looks fine. Each handover resets the RLC stack and throughput dives. So the signal bars stay full, but the connection stutters. That's the latching hypothesis in technical language.
And the battery overheating. Permanent signaling, active scheduling, continuous measurements. The phone is working hard to accomplish nothing. Daniel said it hangs trying to send a simple text. That's the phone burning battery on signaling while the data path is stalled.
So the log analysis he's asking about is useful, but only after the peak versus off-peak test points him in the right direction. If it's congestion, the logs will show fine signal and terrible throughput during peak hours. If it's ping-pong, the logs will show short dwell times and frequent handovers. Both are readable without being a network engineer. You just need to know which column to look at.
The column for stability is not the speed column. It's the time on cell column. How long does the phone stay on a given cell before jumping. Long dwell times with low throughput means congestion. Short dwell times with low throughput means ping-pong. Same symptom, different disease.
The treatment is different too. Congestion means change provider or change tier. Ping-pong means change the preferred network type or pin to LTE. If Daniel treats congestion with a 4G pin, he'll still be deprioritized, just on 4G. If he treats ping-pong with a provider switch, he might switch to a provider with the same flap problem on a different host.
The diagnostic comes first. The intervention second. Daniel's instinct to analyze rather than fly blind is right. He just needs the right test to run first.
The test is almost embarrassingly simple. Same spot, same phone, same test. Once at ten in the morning, once at ten at night. If the numbers are wildly different, it's not the radio. It's the queue.
The queue that Daniel can't see and the provider won't advertise. Most virtual operators don't prominently disclose their priority tier. It's usually buried in the fair use policy. Traffic may be managed during periods of congestion. That's the euphemism for you go last.
Which is why the honest answer to Daniel's question about researching from the stability vantage point is that the research has to be empirical. You can't read a spec sheet and learn the queueing policy. You have to measure it. The crowdsourced tools give you signal. The peak versus off-peak test gives you congestion. The logs give you ping-pong. Put the three together and you can make a stability decision with actual data.
If the data says the current provider is deprioritizing him, the next research question is which virtual operator rides a different host network with a less congested wholesale pipe. That's not a handset question. That's a market question.
The market question has a twist. The same host network can sell wholesale to multiple virtual operators at different priority levels. So two virtual operators on the same host might perform differently. Because of the deal.
The deal. That's the part none of the coverage maps show. The bars, the bands, the frequencies. All visible. The contract, the queue, the priority. Invisible. And that's where Daniel's night and day actually lives.
Hilbert: I had four of these SIMs in the glovebox of a van I drove for a courier outfit in ninety two. Different networks, same phone. The dispatcher would call and say the east side's gone quiet, switch to the other card. You'd pull over, pop the back off the phone, swap the SIM, and the same streets would come back. Same signal. Same phone. Different card. The boss called it the quiet tax.
The quiet tax.
Hilbert: The cheap card went quiet when everyone else was talking. The expensive card didn't. It wasn't the coverage. It was who got to talk first. We had a route sheet with which card to use in which neighborhood at which hour. It was the only thing that kept the deliveries on time.
That's the priority tiering, decades before the term was common. The host network's own subscribers got the capacity, and the resold cards got the remainder.
Hilbert: The remainder was sometimes nothing. You'd sit at a light with full signal and the radio would just sit there. Just not talking. Then the light would change and it'd all come through at once.
The bursts Daniel's describing. The hang and then the flood.
Hilbert: I kept one of the cards. It's in a tin with some old fuses. No idea if it still works. The network doesn't exist anymore. But the principle does.
The principle being that signal bars are a measure of proximity, not permission.
Hilbert: The permission is the part they don't print on the packaging. You find out when you're trying to send a text and the phone just sits there.
The diagnostic hasn't changed in thirty years. Run the test at peak and off-peak. The difference is the permission.
Hilbert: The difference is the queue. And the queue doesn't show up on any map.
Daniel's in a better position than the courier van. He has the handset APIs, the logs, the crowdsourced data. The van had a route sheet and a pile of SIMs.
Hilbert: The route sheet worked.
The route sheet was the empirical data. Which card worked where and when. That's what Daniel's trying to reconstruct. Just with more decimal places.
Hilbert: The decimal places don't change the answer. If it's slow at rush hour and fine at midnight, it's the queue. If it's slow all the time, it's something else. The van taught me that in a week.
The queue is the thing the provider won't tell you. The fair use policy says traffic may be managed. It doesn't say your traffic will be managed first.
Hilbert: The cheap card's fair use policy was a line on the back of the packet. I think it said service may vary. That was the whole policy.
Service may vary. The entire industry in four words.
Hilbert: It varied. That's what I'm saying.
The cutting room floor detail I keep coming back to is that eighty percent figure from the measurement study. In the worst virtual operator's long page loads, eighty percent of the time was TCP idle or dormant periods. The radio wasn't struggling. It was waiting. The network wasn't congested in the way we imagine. It was just not serving.
That's the thing to remember. Congestion isn't always a wall of traffic. Sometimes it's a scheduler that's decided you're not the priority. The bytes aren't blocked. They're just not being sent.
Daniel's next step is the peak versus off-peak test. If the swing is dramatic, he has his answer and it's time to shop for a different host network. If the swing is small, he starts looking at time on cell and handover frequency. Either way, he stops flying blind.
The voice over IP plan means the stakes are higher than a slow web page. The data path is the call path. Stability isn't a preference. It's the whole architecture.
Thanks to Hilbert Flumingtop for producing. This has been My Weird Prompts, the human AI collaboration podcast. If you want to send us a prompt like Daniel does, email us at show at my weird prompts dot com.
We'll be back soon.
