NTT DoCoMo Asks Google To Limit Android Data Use 160
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?"
Yes, it's an esoteric Android issue. (Score:5, Informative)
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.
Re:Well that depends... (Score:5, Informative)
It's not that simple on a wireless connection where everyone shares the medium. For communications originating at the phone, the network provider can't do any throttling until the packet has already been received at their equipment, because they don't control the phone's transmitter. By that time, the bandwidth on the wireless link has already been consumed and wasn't available to other users. If the control signals originate at the server, the network provider could throttle it, but setting it up isn't trivial, and then you have problems like the servers sending retries because they aren't getting responses from the phone. The best solution requires cooperation from the OS and/or application writers.
There are limits though (Score:5, Informative)
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.
Re:Well that depends... (Score:5, Informative)
Docomo seems to claim that it's background sync/checking traffic - but Google makes a point of reducing this as much as possible. There's good reason to do this - the less often data is transferred to keep "checked in", the less often a device needs to wake up, and the better battery life is.
This is, for example, why IM apps that use Google C2DM (Such as Google Talk - but any IM app author can use C2DM) have a minimal impact on battery life, while poorly written apps that are not even remotely suited to mobile devices (like Skype) are massive battery hogs.
If Google's services are "checking in" that often on DoCoMo, it's probably because DoCoMo's NAT boxes are broken - http://conferences.sigcomm.org/sigcomm/2011/slides/s374.pdf [sigcomm.org]
Re:Both (Score:5, Informative)
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 [sigcomm.org]
Re:Well that depends... (Score:5, Informative)
It's not VoIP calls that are the cited problem, it's the periodic signals when it's not in use that tell the server, "Hey, I'm still here!"
Re:format and rhymes (Score:4, Informative)
Re:Well that depends... (Score:5, Informative)
They have a right to make money in return
No, they have the right to try to make money in return. If they can't make money without constantly changing the rules instead of their strategy they should go out of business. I'm sure others could use the spectrum.
Re:Well that depends... (Score:3, Informative)
It's not VoIP calls that are the cited problem, it's the periodic signals when it's not in use that tell the server, "Hey, I'm still here!"
Which, by the way, are usually just keep alive packets sent on sockets that are already open.
Seriously, if these tiny packets are hurting their network how cramped must their bandwidth be?
Admittedly, these SIP/Voip clients could use the more common method of opening a socket and letting it sit there till the socket times out, then re-initiate. This needs to be done once every 15 to 18 minutes, and no actual data needs to go across the link in the mean time. (In fact the radio's can go into deep sleep mode).
However, every email check, facebook check, check-in, or weather update causes way more data transfer than a few packets sent back and forth on an already open socket.
I've got a SIP connection up on my smartphone 24/7, and I've seen zero impact on my data usage, even when I get several calls per day over 3G. The software uses keep-alive packets at an interval I can set to detect early connection failure. Many SIP providers haven't yet set brought their servers up to the point where they can rely on socket timeout as a signaling method, and simply drop the registration of the sip client when this happens.