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.
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.
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.
No, but there's a switchable "bars"/dBm display built in to recent versions of iOS:
1. Dial #3001#12345#* and hit send to start the Field Test app.
2. Hold down the power/lock button until the "slide to power off" screen displays.
3. Hold down the Home button to force-quit the Field Test app.
4. A numeric dBm value now displays in place of "bars", and you can toggle the display by tapping it.
This behavior persists until you re-enter and gracefully quit the Field Test app.
Just a minor correction for anyone trying this out. The correct field test mode number is 3001#12345#. This must be dialed from the keypad. It won't work from the address book.
I had never had problems in Canada on my iPhone with my provider. I could in fact take an elevator ride 2 stories into the basement and continue a call. I recently moved from one suburb of Vancouver, BC to another and all that changed.
At the new neighbourhood I couldn't get service standing at my front door about a mile in line of sight of the nearest tower. After a long and ugly fight with the provider, I was able to cancel my service for half the ETF and move to another provider using an iPhone that I presume connects to the same towers and works as expected. I definitely wasn't happy with the result.
I've noticed that the 5 bar system does not work well for diagnosing actual signal strength and reliability: the display updates too slowly to be of actual use when signal is a problem -- watch people waive their phones around while they try and make them work. The bars don't represent the signal it's getting now, but some normalized value of the last little bit of signal.
At minimum, it would be nice to have an app that does a good job of diagnosing and explaining your current network situation. I'm sure it already exists, I'm just not aware of it.
Android users with a Google account added to their phone should know that the color of their signal bars will change depending on the status of their connection to Google. Android keeps a connection open to Google for various reasons (push notifications, e-mail sync, etc.). If this connection goes away for some reason (like, say, if your provider doesn't have any bandwidth left for you), the connection bars will change to grey.
It's not fool proof, but it's better than nothing.
So glad to read someone pointing this out. It's especially maddening on Caltrain, where you're trapped with a group of data-hungry, bored commuters. Even with five bars, network responsiveness is a crapshoot and the severity of the problem is completely opaque.
This kind of talk makes me want to build a box which does wifi on one end and something more reliable than cell service on the other, routing between the two. Then I'd just ride the trains all day with it in my bag and sell access to anyone who jumps on.
Think of it as the homeless hotspot thing from SxSW, only brought to the peninsula. One person per train would probably do the trick.
The hardest part is: just how do you get reliable connectivity to your box in order to resell it?
Summary: uses a bunch of different 4G cards from different carriers, large high gain antennas, and link aggregation; to make a single reliable network connection from a bunch of unreliable ones.
Downside: Fills a backpack, is really thrillingly expensive.
Nice! I bet you could make the money back, given sufficient demand (and this is not the first I've heard about sketchy service). Maybe just doing it on the baby bullets daily would get the job done.
I imagine you could probably test the waters by running an open AP with a suitable name and have a small web server behind it which lets people indicate their interest. Ride with it for a few days, wear the name of the network on your clothing, and see what happens.
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.