Slashdot Mirror
NTT DoCoMo Asks Google To Limit Android Data Use
An anonymous reader writes "NTT DoCoMo has had enough of Android's effects on its mobile network in Japan. Following a service disruption due to Google's Android VoIP app, the company is now asking Google to look at reducing Android's data use. In particular, the amount of time allowed between control signals being sent either by official apps or 3rd party ones. Typically these occur as often as every 3 minutes, but scale that up to thousands of apps on millions of handsets and you can see the issue DoCoMo has. So, does DoCoMo need to invest more in its infrastructure, or is Android a data hog that needs reining in?"
If all they are asking is for Google to optimize its network usage, as the article seems to imply, go all out.
If its telling Google to try and control the amount of bandwidth the users decide to use, well, I think they are going to have a little trouble getting that done.
Having been to Japan, and several locations around the world, I can say with fair certainty that NTT DoCoMo has the best network service I have *ever* seen. It allowed me to measure what is due to the iPhone's failings, and what is due to the network operator's failings. By contrast, in New York, AT&T makes getting signal a game of hide and seek. France stands somewhere in between the depths of AT&T and glory of NTT DoCoMo.
All this to say that if NTT DoCoMo feels Android is unoptimized... than I pretty much take their word for it.
Both Apple and Google need to be aware of their bandwidth usage, but it is not just those two, but the app developers as well. Better to spend a few more CPU cycles and compact the data a little more than to bring down the network. XML is fine, but hardly the most efficient way to transmit data, especially not without compression.
On the other hand, the providers must realize that the trend are for increasing data usage, as we take our daily communications with us, rather than sitting at home with our fixed line broadband connections.
It's some "control-traffic" issue that you, the customer, really shouldn't have to think about. It's nothing to do with an application that routes voice traffic over a data connection, thereby disrupting the carrier's finely-crafted billing practices.
Uh... Control signals have nothing to do with overall data consumption quantities. When you send a text message, you send the 160 or so bytes of data through control signals. The issue here is that Android doesn't control the way its apps try to contact the towers, basically hammering them if they don't respond properly. This issue is one of the reasons Android has massive standby battery drain problems, as detailed in this 300 page xda thread: http://forum.xda-developers.com/showthread.php?t=1179809
The galaxy nexus has its own 100+ page thread dedicated to battery drain on standby.
I agree. But I would add one more thing...
Perhaps Google could come up with a standard for pushing all these control signals and keep alives through a single gateway. That way apps could piggyback on each other to reduce traffic.
I must have at least 5 different ways to asynchronously receive messages on my phone. I would love a way to combine the traffic for all of these down to something small. Especially if (and I realize I'm an extremely rare case for wanting this) I could redirect it through a web app or something running on my server at home.
It's like how almost every social website grows some form of instant messaging that's relayed through the website's servers. Why can't they all just use Jabber and be done with it?
Need a Python, C++, Unix, Linux develop
Yes. But everyone (users and network providers alike) would rather that users' data usage focus on data the user actually wants, and less on "checking in" with various servers. I would think users would be just as annoyed to find out that Android handsets are really using 10x the bandwidth on idle tasks as other handsets (assuming it is true, that is).
So I've got one of them gen-u-ine android phones. Which apps are supposedly hammering the network?
My guess is the GOOG latitude GPS plotting thingy must be updating fairly often. So in the big list of blacklisted apps, I've got one "i donno maybe guess".
This is important to me because my batteries life is very short... Enabling latitude position tracking thingy meant my battery died in about 10 hours (which is an issue for a guy who works 10 hour shift bracketed by a modest commute), so I shut it off, gaining me at least 6 more hours, making it very easy not go thru a working day without charging. I wonder if I disable "something else" if I'll magically gain yet another 6 hours... or more...
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Oh yes, the providers (at least in the US) are well aware of this trend. It's reflected in the current data usage pricing scheme and the "unlimited" plan max caps.
Google already has a standard for pushing those control signals over a dedicated persistent TCP/IP connection (when your signal indicator goes from white to green it's connected). Many apps choose not to use it for one reason or another, Facebook Chat for example posts a huge XML request every minute or so to poll for new messages.
Also, Jabber sucks mostly due to its use of XML.
Just because you disagree doesn't mean it's not true.
The problem is that pesky Shannonâ"Hartley theorem. Basically it says that your data throughput is equal to your channel bandwidth and SNR. With a wired connection, there's a lot you can do there. With wireless, there's serious limits. SNR is fixed by environmental conditions, unless you are willing to up the S part a lot which requires lots of power and thus isn't suitable for mobile.
Bandwidth is limited since you have to share the airwaves with lots of stuff and certain frequencies are good for certain things. So going with 60GHz might sound great because a 1GHz channel would be no problem, but you find that it has trouble with attenuation due to water in the air, never mind walls. 700MHz cuts through walls pretty nice, but your channel will be much smaller.
Then of course there's the real sticking point: You share with everyone else in the same area. If your throughput is, say, 100mbps total you are sharing that 100mbps between anyone on the same segment as you. So have 100 users, all trying to go full blast and you'll each get 1mbps or so.
The only solution is to build out the segments smaller. However there's limits to how much of that you can do. You can't realistically segment the network down to an arbitrarily small level.
The "JUST UPGRADE THE NETWORK!" thing that geeks like to scream is very unrealistic in the case of wireless. Yes, with fibre we can have shit tons of bandwidth, when you are talking carriers in the hundreds of Terahertz, you can have some bigass channels, you can have lots of channels, SNR is quite good in fibre and you can always just lay more of it. However wireless has some real physical limits you butt up against.
We have to accept that when you are using wireless, especially longer range wireless, that there are limits to deal with.
So what? The world is heading to MORE digital data usage, not less, that's a fact. And the prices for use are going to drop, that's also a fact. Maybe NTT DoCoMo needs to up their capacity, not worry about throttling it so much. Words all providers need to take to heart.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
Considering that Google has a SERIOUS interest in making control signal intervals as long as possible for battery life purposes - if they are too often, the carriers only have themselves to blame. Too many carriers have aggressive NAT firewalls with short TCP connection timeouts, and it's much better for the handset AND the carrier to send a keepalive within that timeout period than to have to detect a dead connection and set up a new one.
Google "netpiculet" or look at my last post earlier on this article for an eye-opener of how network providers shoot themselves in the foot.
If Google is sending control signals too often - DoCoMo should take it up with the carriers that deployed broke-ass NAT boxes that forced Google to do this.
retrorocket.o not found, launch anyway?
They already do - it's called Cloud to Device Messaging (C2DM).
If C2DM is sending syncs/keepalives every 3-5 minutes, it's because broken carrier NAT boxes are forcing them to.
http://conferences.sigcomm.org/sigcomm/2011/slides/s374.pdf
retrorocket.o not found, launch anyway?
A quick look on wikipedia tells me that DoCoMo is short for "do communications over the mobile network", while the Japanese word "dokomo" translates to "everywhere".
If God forks the Universe every time you roll a die, he'd better have a damned good memory.
That's because AT&T is suffering from the same problem NTT DoCoMo is suffering from - control channel congestion. You're getting 5 bars alright, but the big problem is stuff like dialing and establishing data connections consume control channel bandwidth. Dropped calls happen because your phone's trying to switch towers and can't because it can't get a word in edgewise on the control channel.
Slow data ditto - the phone on 3G needs to establish multiple PDP data sessions to get 3G speeds, and if it can't talk to the tower because the control channel is busy, well, it suffers.
Control channel congestion (caused by all this plus texting) is why AT&T service can be horrible, despite having plenty of free channels available for data and voice. It's what took T-mobile down once (a bad IM app overloaded the control channel).
Think of it as the old-timey POTS phone days where you lifted the handset and told the operator who you wanted to talk to. And now have lots of people do the same and the operator's now overloaded trying to establish and tear down connections, leading to phone calls not going through, the operator not responding to you, etc.
If you're a developer and you've discounted a valid option purely because other people misuse that option then please, put a barrel in your mouth and pull the trigger.
Exactly. And increasing control channel capacity is not free, as it reduces resources available for users data. Plus the control channel need robust encoding so are comparatively more expensive than data on average. Plus the standards have some flexibility on dimensioning control channels, but it's not fully flexible either. There's some assumption built in.
So operators may increase the amount of resources allocated to signaling, but this is only possible up to a point and would reduce data capacity (so increase cost per user level data).
So the way to get out of this with everyone wining is to make sure mobile phone applications use the network efficiently, and don't waste signaling capacity just out of ignorance. It seems both Google and Apple provide centralized polling / notification services already, so blaming them may be unfair. But I'm pretty sure there's a lot of developer education still to do. And maybe adding tools in the platform to see what are the wasteful applications would help. Knowledgeable users could spot the offenders, and make some noise so they improve their behavior.