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?"
Well that depends... (Score:5, Insightful)
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.
Re:Well that depends... (Score:4, Insightful)
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.
TFA specifically states they are trying to control VOIP data usage. Not unlike the (failed) domestic attempts to limit voip on a smartphone in order to preserve traditional airtime revenues. Do you remember all the hubub when apple/at&t tried to ban Skype? It's a thinly veiled attempt to screw customers, and I'm sure Google has no particular interest in limiting their users traffic based on the content being transmitted.
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: (Score:2)
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!"
Does sound like a typical Geek problem, doesn't it?
Re: (Score:2)
Re: (Score:3)
Its a tcp/ip connection, that's all.
Because the networks are so unreliable many sip clients send a packet back and forth, using CRLF-CRLF ping answered by a single CRLF pong, according to RFC5626 [ietf.org].
So the load is WAY different than connection to the base station: Its WAY SMALLER, and WAY LESS FREQUENT.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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!"
If that's indeed the case, it is understandable - it's like some idiot calling you up and then telling you to stay on the line while they get around to you. I've had telemarketers do this (yeah, I know about the Do Not Call List, and so do they -- they're choosing to flaunt it) because they dial a bunch of numbers at once, then respond to the first one that picked up.
Probably a good engineering way around it - could also be NTT DoCoMo doesn't want to put any money into upgrading their network.
Re: (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
Re: (Score:2)
Re: (Score:2)
You are only looking at the TCP/IP stuff, but there is a radio layer in there too. It isn't like wifi either, there is much more overhead, and connections have to be tracked between base stations too.
Re:Well that depends... (Score:4, Insightful)
Perhaps they shouldn't sell a product if they can't provide it, rather than stripping and restricting what people thought they were buying later?
Should we just pray they don't alter the deal further?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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.
I do not necessarily advocate this, but can't they detect individual users and throttle(?) or filter those control signals? If that takes more resources than just letting Androids bog down the system, I withdraw my question.
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.
Re: (Score:2)
That doesn't quite add up. The number of smartphones out there is on the same order as the number of high-speed connections in homes. The connection of cell phone towers to the backbone is extremely direct compared to high-speed connections in homes. And, finally, the total monthly bandwidth used by the typical phone is a lot less than the total monthly bandwidth of a home connection. So how is the backbone usage the issue when it's the same backbone as the home connections?
Re: (Score:3)
Throttle?
The Keep-Alive per RFC5626, consists of 2 CLRF pairs sent from the hanset (4 characters plus TCP wrapper) answered by a single CLRF pair (plus wrapper). Minimal wrapper, IIRC is about 16 bytes, so every 3 minutes twenty bytes out, followed by 18 bytes back in.
Pretty hard to throttle that down to anything less if you ask me.
They need to fix their network.
Re: (Score:3)
First it was bit torrent traffic, then video streaming traffic, then VOIP traffic...
They're just setting the stage for discriminating traffic so they can charge more to certain users to get back the money they lose from those customers not supporting their other services. The U.S. telecoms have been falling all over themselves trying to find a way to nullify Netflix to keep us from dropping their archaic tiered cable tv service.
Why would a Japanese company be any different? The Skype folks are going to en
Re: (Score:2)
Makes me wonder if the telcos spent just a fraction of the money they do on advertising and fighting all types of competitors, and used that to improve their product, what would happen? (Yeah, I know pipe dreams and all that)
Re: (Score:3)
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: (Score:3)
I think there may be something to what you are saying. To be honest, I was very surprised by this article (I would really like to see the original Nikkei report in Japanese... too bad they don't link it).
I'm on DoCoMo at the moment and I have had nothing but terrific service. I live out in the sticks, but no mater where I am I get good signal, good data availability, *very* good bandwidth and decent ping times. I've even tunnelled X through ssh on it and it was (barely) useable. That's considerably bett
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
NTT DoCoMo is the standard gold of mobile networks (Score:5, Interesting)
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.
Re: (Score:2)
I live in NYC and rarely have any problems getting a signal on AT&T. Actually getting any data or calls to my phone over that signal, however, is a distinct challenge. ;-)
I often experience dropped calls and slow data rates while my phone happily shows "5 bars" of signal.
Re:NTT DoCoMo is the standard gold of mobile netwo (Score:5, Interesting)
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.
Re: (Score:3)
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 i
Re: (Score:2)
The article claims Google's notification system is particularly egregious.
Also, Apple's system should be differentiated at least to some degree. Android gives developers more opportunity to utilize the network in the background. Apple's APIs give developers much less leeway in that regard.
Re:NTT DoCoMo is the standard gold of mobile netwo (Score:4, Interesting)
Re: (Score:2)
I pretty much agree. Plus, upping their capacity will make them reduce power emissions from their antennas which will calm down the GSM-is-microwave freaks.
Re: (Score:2)
I'd guess they've already upped their capacity, and they probably think you should up yours.
Re:NTT DoCoMo is the standard gold of mobile netwo (Score:5, Insightful)
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.
Re: (Score:2)
Yes, if I had mod points, I'd mod you up.
I'm an app developer, and I've had to deal with countless network problems (usually NAT's dropping connections without RST) that ended up being resolved by stupid strategies like "f it, lower the keepalive interval to 5 minutes", and killing a connection if it was not ack'ed in X seconds (you can be more agressive with killing TCP connections by adding protocol-level acks on client&server).
But despite this, I've managed to reduce bandwidth greatly by making my pr
Re: (Score:2)
At that point you're probably better off writing your own reliability protocol layered over UDP...
Re: (Score:2)
It's funny that you say that, because based on (admittedly half year old) data that an app developer collected about reconnect rates [urbanairship.com], Japan was by an order of magnitude the worst country with regards to number of reconnects that this app had to perform (DoCoMo was the second-to-worst carrier around the world).
Reconnects happen because the cell carrier closes a connection or times out--a good cell carrier won't change your IP address or RST your connections when you switch towers, but a bad one might decide
Re: (Score:2)
That's one thing I wish wireless providers would "get" - rather than marketing insanely high transfer rates with ridiculously low caps, they should sell tiered rates...
The T-Mobile and AT&T "unlimited" policy of full speed up to a ridiculously restrictive throttle wall is ridiculous - it makes FAR more sense to reduce the initial speed, and make the throttle a little gentler. If throttling of high users weren't so severe (a "soft cap" that degraded as your usage got higher, instead of a "hard threshold
Both (Score:5, Insightful)
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.
Re:Both (Score:4, Interesting)
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?
Re: (Score:2)
"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."
That is actually a very good idea, but it will add latency. Then again, a little latency on a line updated perhaps once every 2 minutes would hardly be the end of the world.
Re: (Score:2)
The only fundamental con is that you need to optimize the application for mobile. To use a centralized optimized push notification service instead of each application doing its own polling for example. But I don't think there's a way around that: a wireless network is fundamentally diffe
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Isn't there SSH for Android? You could tunnel specific traffic through it like a VPN. If it works for you then set up VPN and forward everything through it. Also, last time I looked ejabberd had extensions for most all of the IM services. They might have modules that can work, or be modified to work, for your social media site(s).
Re: (Score:2)
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.
The catch is that you then need to migrate the existing protocols to use that service. End result, we end up with a bunch platform-specific protocols (push for iOS, push for Android, push for WP etc).
A big attraction of Android for myself is that it's the only mainstream mobile platform that lets you use existing protocols, because apps can just open a socket and do what they need to it, even in background. Meaning you can write a Jabber or ICQ client that connects directly to existing servers, without goin
Re: (Score:2)
Re: (Score:2)
I understand that iOS apps can open sockets pretty much willy nilly. The question is, can they keep them open while they're in the background, and accept and respond to packets that come during that time? It would be a pretty useless IM client if it could only receive messages when it's opened.
From what I've seen in the App Store with respect to XMPP clients, my understanding that the only way to receive any kinds of network notifications in background is to use Apple's push service, so existing protocols d
Re: (Score:2)
In iOS, application programmers can only perform the following seven tasks in the background:
Background audio - application continues to run in the background as long as it is playing audio or video content
Voice over IP - application is suspended when a phone call is not in progress
Background location - application is notified of location changes
Push notifications
Local notifications - application schedules local notifications to be delivered at a predetermined time
Task completion - application asks the system for extra time to complete a given task
Fast app switching - application does not execute any code and may be removed from memory at any time
So basically, no; the program is suspended if it isn't using one of these facilities. The OS obviously supports true multitasking, and there is a Cydia program called Activator which lets you control how individual programs behave, but it no longer works on iOS 5, and Apple tries to sandbox app developers as much as possible to control this component of the UI experience. Their reasoning, whether you agree with it or not (and I don't think many geeks do) is that s
Re: (Score:2)
Does iOS lets an app in the background keep a socket open to a random port for an indefinite time period?
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
"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."
They already have it - it's called Cloud to Device Messaging (C2DM).
Re: (Score:3)
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).
Re: (Score:3)
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:There are limits though (Score:5, Funny)
The problem is that pesky Shannonâ"Hartley theorem
Well, since it's just a theory, it probably isn't true. Like evolution and such.
So, just ignore it.
Re: (Score:2)
Re:There are limits though (Score:5, Insightful)
CDMA techniques do not get you a free pass around Shannon-Hartley's channel capacity theorem.
Re: (Score:2)
I tend to agree. I would say that Phones in Japan have been much smarter and data heavy than the US equivalents for some time. So it's not like the Android phones are replacing a bunch of Nokia Feature phones. For that reason I also think NTT DoCoMo knows what it's talking about as far as optimization.
Re: (Score:2)
Maybe there should be a rating system for apps (and the phones themselves) similar to the Energy Star Rating, but for data instead.
Re: (Score:2)
Similar to Energy Star rating, but actually useful, would be a better criterion I should think.
Re: (Score:3)
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: (Score:2)
Yeah, the control traffic every three minutes is *just* as important to them as stopping the VOIP apps...
Re: (Score:2)
My guess is that the control traffic related to voip might be SIP over UDP. That kind of traffic is soley controlled by the application and the server, if the client is NAT-ed an abundance of SIP control packets might be necessary for keeping the portmapping alive. But these persons who though that a control protocol should be done over UDP, should be the first againt the wall in my book.
Re: (Score:3)
But these persons who though that a control protocol should be done over UDP, should be the first againt the wall in my book.
Its actually a protocol that can run over UDP, TCP or SCTP. Someone who thought a control protocol should be able to run over many different underlying protocols should be the last against the wall.
subtext translation: (Score:2, Offtopic)
"Andloid's not done until VOIP won't run."
Control signals- NOT Data (Score:5, Interesting)
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 [xda-developers.com]
The galaxy nexus has its own 100+ page thread dedicated to battery drain on standby.
Re: (Score:2)
Yup, and if there are this many misguided comments conflating control signals with data usage on Slashdot, imagine how easily the issue can be spun by carriers to intentionally misrepresent the issue to an ignorant consumer base.
Re: (Score:2)
Re: (Score:2)
Android problem or applications problems? What is the difference of Android vs a Laptop with 3G? If some Windows applications is using a lot of network, could the telco ask Microsoft to change Windows so that doesn't happen? The same way, If a Window application is on an infinite loop, consuming all the batery, is Windows the culprit here?
Stop blaming a multitasking OS for the failures of the applications. Android 4.0 is adding data usage limits per application so user can identify those buggy applications
Re:Control signals- NOT Data (Score:5, Insightful)
What Android desperately needs is a nice, API-level convenience method that lets you create a http(s) request, complete with args, then hand it to the OS and say, "You don't have to do this *right this millisecond*, but at some point within the next ___ seconds/minutes, please wake up the phone (if necessary), establish network connectivity, make the request, then fire {this-intent} with the server's response (or failure info)" (and optionally, if the request fails, try making a test request to something like 8.8.8.8 and/or 8.8.4.4 to make sure the phone's internet access is REALLY working before assuming failure, so the program only has to deal with the failure of its own web service, instead of having to deal with the failure of the phone itself to sustain a robust network connection).
Believe it or not, right now, there's NO good, reliable, graceful way to do the equivalent of having a cron job fire off a http request when the phone is asleep. There are ways to kludge it, but they're all either unreliable (the phone will go back to sleep before it even has a chance to MAKE the http request, the network might be down because it hasn't finished reconnecting yet, etc) or dangerous (holding partial wakelocks in static variables, with no way to guarantee their release if something crashes).
Android gives developers lots of power, but it also imposes enormous amounts of responsibility that maybe 1% are really equipped to handle. In the real world, the network failure strategy of most Android applications can be summed up as "relentlessly keep beating away at the URL in the hope it might eventually work". Oh, most semi-new Android devs don't SET OUT to be irresponsible... the problem is, anybody who tries to make a single network call and fail politely and exit if it doesn't work quickly discovers that an average Sprint user will have the app die within 10 minutes (thanks to the stupid way Sprint phones thrash between 3G and 4G in quite a few real-world indoor usage scenarios). So they adopt "keep trying over and over again" as a strategy, because it makes their app work on Sprint phones, but kills the battery of anybody who's somewhere like a subway tunnel when the phone decides to make its next http request. If Google gave developers a nice, bulletproof way to politely make asynchronous http requests that can be gracefully scheduled and batched, instead of trying to hack together buggy solutions that almost work, we'd all be better off.
Re: (Score:3)
Alarm Manager is part of the PROBLEM.
Yes, you can schedule your task through AlarmManager. You can even be polite and use InexactRepeat to batch requests. There are two specific problems:
1. You aren't allowed to do anything time-consuming (like make a http request) in the BroadcastReceiver that runs when AlarmManager fires off the Intent. You have to start a background service to do it. Unfortunately, Android makes no guarantees that it will even execute the BackgroundService onCreate() method before exitin
Re: (Score:2)
Sorry, but Android networking is nowhere close to being that straightforward once you throw deep sleep behavior and powered-down network interfaces into the equation. Just to give one blatant example, my Motorola Photon routinely gets itself into situations where it powers down all the network interfaces, and takes an ETERNITY to re-establish the network unless I launch the stock browser long enough to manually wake it back up. I've had it showing "Zzz" for the wireless network, and observed HUNDREDS of fai
Re: (Score:2)
Argh. Accidentally wiped out a major edit, too.
Relying on a long-lived background service doesn't work anymore. As of Gingerbread, Android will kill background services it thinks have been running for "too long", even if they're spending 99.999% of their time waiting politely and allowing the phone to sleep as necessary. Officially, you're now damned if you do, and damned if you don't.
Re: (Score:2)
Which begs the question of this is an Android problem or a wireless issue. I really don't know where one begins and the other ends.
To what extent can network operators control the wireless devices?
Like is there a 3G/LTE command that DocoMo can send a device to tell it to limit its traffic to X kpbs, or pause sending for y seconds...
A little less vague? (Score:4, Interesting)
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...
I don't see it (Score:2)
TFA:
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
I still don't see the issue they have... what is the issue? What are these "control signals"... is it TCP traffic or cellular network control signals? What resources are they consuming? Have other carriers had the same kind of problem or is it specific to DoCoMo? What update frequency do they recommend if 3 minutes is too often? 4 minutes? 6 minutes? 60 minutes?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
One more option (Score:2)
Given that this is a shortage, and that a shortage is when demand exceeds supply, DoCoMo can either add supply by investing in its network, or they can reduce demand by raising the cost of bandwidth, at least during peak periods. This gives DoCoMo two options to eliminate congestion on its network.
Raising the cost of bandwidth could be done pretty easily by setting caps on peak hour data usage.
Which app? (Score:2)
Was this a third-party app or an official Google app? If it's third-party, Google has no control. One packet every 3 minutes is, honestly, pretty damn good for some apps. Skype can cause a device to wake up once every few seconds (which is the main reason it's an epic battery hog).
Google's own apps are about as efficient as they can be in order to minimize periodic data, because keepalives and checkins wake the device, draining battery. The problem is that some major carriers have broken NAT boxes ( htt [sigcomm.org]
Precedents (Score:2)
640k ought to be enough for anybody.
sigh, false dichotomy (Score:2)
I know it makes articles sound more dramatic and controversial, but sometimes the answer is obvious:
"So, does DoCoMo need to invest more in its infrastructure, or is Android a data hog that needs reigning in?"
The answer is clearly "both". Apps and android should optimize their data usage, doing so increases battery life and gives a better user experience all around. If DoCoMo is identifying particularly troublesome apps, then that is helpful to decide where to start hacking. _Also_, DoCoMo should be upgradi
lol (Score:2)
The solutions to these problems are simple. If you have 100 customers, and you have 100MB/s of bandwidth on your network, don't sell them all 5MB/s plans. ITS SIMPLE MATH. To blame this on Google is like an all-you-can-eat buffet complaining to a local taxi service that they're dropping off too many fat people. Who do you expect to pay for all-you-can-eat? Twiggy?
Let me see here... (Score:2)
Should Android be more efficient, and every app it runs. OF COARSE. There is not such thing as efficient enough, but Google has to decide if it is worth
their money right now.
Should the network provide stop wining because their network is running up against the physics of
allowing too users on it and just fix the problem. Probably.
Sorry, but don't take on more subscribers then you can service. And if their are devices that you don't like their affect feel free to ban them.
If that doesn't make you money , t
Re: (Score:2)
Re: (Score:2)
I saw a Docomo poster in Tokyo that read "DOing COmmunications the MObile way". If that's the basis of their name, not sure how the Japanese "alphabet" enters into it.
Re:format and rhymes (Score:4, Informative)
Re: (Score:2)
Re: (Score:2)
I dunno, but if you look at the automotive world, the south Koreans have certainly stolen the Japanese's thunder there.
Re: (Score:2)
"reign" a kingdom. "rein" a horse. Please.
The anonymous writer was actually the shy King Richard III of England.