What we need is something that indicates network quality. This would be
a third indicator (or replacing the two previous ones). It would
indicate the level of service that one could expect while on a cellular
band.
Whoops, physics!
The current signal indicator is based on the periodic heartbeat packets the phone broadcasts. This is the bare minimum for a cell phone to work at all: in order to route a call to a phone, the network has to know which cell it's in.
A "network quality" metric would require, say, a ping running to a host a couple hops away. This requires using the radio to actually transmit nontrivial amounts of data, and (depending on a whole lot of things, of course) more often than the heartbeat.
This would kill battery life. Absolutely murder it. You'd go from 200 hours of standby to 50. Maybe less.
Even worse if you wanted to get an idea of throughput. You'd have to transmit, say, a hundred megabytes of random data. Now we're down to 20 hours of "standby", and dramatically higher load on the backhaul. And, of course, li-on batteries die quicker the more heavily you use them, and the iPhone doesn't have a user-serviceable battery.
Or it could just piggyback the existing connections that are taking place. It could run metrics against every attempted outgoing or incoming transfer. This would include mail checks, notifications, or any in-app data use. Sure, it wouldn't be "real time" if I pick up my phone "cold" but even just piggybacking on mail checks would make it work pretty well.
Since we already know that the mail client doesn't kill the battery dead, we can guess it's not checking for mail very often.
Sure enough, google tells us the most frequent check possible is 15 minutes: https://discussions.apple.com/thread/1596018?start=0&tst...
You could use the entire network stack, sure, but that still isn't going to be very fast, since any app that uses the radio frequently is going to drain the battery, and users will complain, which mean such apps just don't exist.
You can settle for only getting an idea of how useful the network is once every 10 minutes, but then we're back at the problem of the "network quality" metric not actually meaning anything relevant.
This is a brilliant idea, perhaps even startup worthy. Integrating the quality monitoring into the TCP|UDP/IP stack wouldn't be that hard and shouldn't have too much battery impact.
I admit I know very little about how cell phone networks work, but why would the phone need to transmit anything to determine network congestion? Surely it could figure this out just by listening, right? Maybe with the help of the towers periodically broadcasting their utilization?
Phones already do that. It's the bar graph we already have.
There are multiple reasons why it's not terribly useful:
1.) Signal quality depends on many different variables, and fluctuates wildly from second to second. You can have a great signal at one moment, but if the guy next to you starts a call, the radio in their phone will ramp up to the full 500mW, and drowns out the tower. You can have a signal graph that realistically reflects "signal strength", and it'll jitter constantly, and the grandmas will complain.
2.) Marketing.
Good overview: http://www.dansdata.com/gz084.htm
As you may have noticed from every cell phone advertisement in the last decade, marketing is heavily invested in the notion of bars. It's in brands, logos, ad copy, everything. More bars are better.
If engineers ran the company, they'd just stick the SNR in dBm at the top of the screen and it'd be wonderfully pure and objective; and everybody else would hate it, and the company would go bankrupt. So we have "bars", and the bars lie.