Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Android Software Japan Networking Wireless Networking

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?"
This discussion has been archived. No new comments can be posted.

NTT DoCoMo Asks Google To Limit Android Data Use

Comments Filter:
  • by Ragun ( 1885816 ) on Monday January 30, 2012 @04:30PM (#38869617)
    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.
    • by kelemvor4 ( 1980226 ) on Monday January 30, 2012 @04:44PM (#38869753)

      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.

      • by kbielefe ( 606566 ) <karl...bielefeldt@@@gmail...com> on Monday January 30, 2012 @05:19PM (#38870183)

        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!"

        • 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?

        • You mean the ones that are no different in load to the one the phone makes regularly to the base station for the same purpose. Those are a single packet or 2 usually.
          • by icebike ( 68054 ) *

            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.

            • Please see my reply to ewanm89 just above. It's very small at the TCP/IP level, but it's actually MUCH BIGGER and MUCH MORE FREQUENT ;) than the keep-alive done by the telecom network. It's not even very useful, adds inefficient signalling (particularly in 3G vs. 4G) and drains your phone battery for nothing.
          • That's actually incorrect and quite way off. A normal telephone does NOT report its presence every 3 minutes as the quoted VoIP applications (value coming from TFA). A location update is done only every few hours, or when changing location areas. So it is much less frequent, and will also be much more efficient as the phone returns to low-power / silent mode after the minimum exchange of packets. Whereas the VoIP keep-alive, being data, will lead to a wake-up and the phone will go back to idle after a timeo
        • by ackthpt ( 218170 )

          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)

          by icebike ( 68054 ) *

          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

          • You forget, this is happening in Japan, the land where everything is done via cellphone (I do kid... kinda). I'd bet typical data usage there is different than typical data usage here in the States (or even Europe).
          • by AmiMoJo ( 196126 )

            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.

    • by Suki I ( 1546431 )

      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.

      • by kbielefe ( 606566 ) <karl...bielefeldt@@@gmail...com> on Monday January 30, 2012 @05:02PM (#38869965)

        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.

      • by icebike ( 68054 ) *

        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.

    • 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

      • 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)

        • How old is your Sig? I'm trying to figure out if it is new and and you're suggesting we replace the current crop of politicians with monkeys, or if in fact this is an old sig and explains our current predicament?
    • by Andy Dodd ( 701 ) <atd7@ c o r n e l l .edu> on Monday January 30, 2012 @05:08PM (#38870031) Homepage

      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]

      • by wrook ( 134116 )

        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

        • by Suhas ( 232056 )
          I live and work in downtown Tokyo and DoCoMo performance has gone down the drain *significantly* in the last few weeks. 3 times in January alone the service completely stopped for 3-4 hours, as in, no data signal, only voice. This is true for all DoCoMo users. I would guess that a few thousand users per cell tower out in the sticks is not a good indication of network reliability for say Shibuya-ku or Minato-ku where you can have a million customers crammed in a few square kilometers.
          • by vix86 ( 592763 )
            I can concur with this. Anytime I hit the heavy crowded areas, Shinjuku, Akihabara, I basically lose my connection a lot. As soon as I'm headed back up north toward Saitama and Ibaraki, signal/connection comes right back no problem. I use a Galaxy S2.
      • Yes, this centralization of keep-alive / sync / update if very key to operate efficiently on a mobile wireless network. And even though both Google and Apple have some support, I guess not all applications are using it. An application designed for a fixed platform where the network is truly always on and dirt cheap will just do its own polling, and a fast polling it will be compared to what is suitable for a mobile network. This same application on a mobile wireless network will create a lot of signaling an
  • by Anonymous Coward on Monday January 30, 2012 @04:37PM (#38869665)

    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.

    • 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.

      • by tlhIngan ( 30335 ) <slashdot&worf,net> on Monday January 30, 2012 @05:41PM (#38870503)

        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.

        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.

        • 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 i
          • 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.

    • by interval1066 ( 668936 ) on Monday January 30, 2012 @05:12PM (#38870063) Journal
      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.
      • by Pieroxy ( 222434 )

        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.

      • by treeves ( 963993 )

        I'd guess they've already upped their capacity, and they probably think you should up yours.

    • 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.

      • by ace123 ( 758107 )

        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

        • by Andy Dodd ( 701 )

          At that point you're probably better off writing your own reliability protocol layered over UDP...

    • by ace123 ( 758107 )

      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

      • by Andy Dodd ( 701 )

        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)

    by JavaBear ( 9872 ) on Monday January 30, 2012 @04:39PM (#38869691)

    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)

      by Omnifarious ( 11933 ) * <eric-slash@omnifari3.14ous.org minus pi> on Monday January 30, 2012 @04:46PM (#38869783) Homepage Journal

      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?

      • by JavaBear ( 9872 )

        "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.

        • It doesn't need to add latency: if you replace polling with push notification you will both use the mobile network more efficiently AND reduce latency. So as far as latency goes optimizing for mobile can really be win-win.

          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
      • by poptix ( 78287 )

        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.

        • by Suhas ( 232056 )
          >Also, Jabber sucks mostly due to its use of XML. Well, the solution is simple enough. XML is like violence, If it doesn't work the first time, use more!
      • 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).

      • 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

        • The primary reason mobile IM programs like eBuddy for iOS use bouncing servers isn't a technical necessity. There are plenty of IM programs that go straight to the source, in fact; even IRC, FTP, and SMB clients exist. One reason that eBuddy in particular connects through its own server is to provide an answering service, like an IRC reverse proxy. Simply put, it caches messages when you're out of signal range; if you have something like an iPod touch with no ubiquitous cell tower coverage, this is quite us
          • 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

            • OS News discussed this in an Android review [osnews.com]:

              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:Both (Score:5, Informative)

        by Andy Dodd ( 701 ) <atd7@ c o r n e l l .edu> on Monday January 30, 2012 @05:13PM (#38870105) Homepage

        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]

        • Interesting, and it goes on to show that even inside the telcos the IP network guys do not necessarily know what to do to best use the radio access network (which is the scarce resource to optimize for). So blaming developers or Google as DoCoMo does is not very fair. There's some learning to do all around I'd say.
      • by dargaud ( 518470 )
        Yeah, that and a way to tell some apps to only use wifi when available and never 3G.
      • by Andy Dodd ( 701 )

        "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).

    • 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).

    • 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.
    • by Sycraft-fu ( 314770 ) on Monday January 30, 2012 @05:04PM (#38869991)

      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.

    • by Kagato ( 116051 )

      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.

    • Maybe there should be a rating system for apps (and the phones themselves) similar to the Energy Star Rating, but for data instead.

      • by treeves ( 963993 )

        Similar to Energy Star rating, but actually useful, would be a better criterion I should think.

  • by jeffb (2.718) ( 1189693 ) on Monday January 30, 2012 @04:39PM (#38869695)

    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.

    • by b0bby ( 201198 )

      Yeah, the control traffic every three minutes is *just* as important to them as stopping the VOIP apps...

    • by kwark ( 512736 )

      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.

      • 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.

  • "Andloid's not done until VOIP won't run."

  • by sonicmerlin ( 1505111 ) on Monday January 30, 2012 @04:46PM (#38869779)

    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.

    • 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.

    • If DoCoMo (sounds like a Beach Boys song) thinks this is an issue, let them dedicate some of THEIR resources to provide an open source solution, whether it be kernel changes or an ECMA API spec that would that would allow tuning the communications flow that they find so disruptive. Make a positive contribution instead of having your suits whinging about how bad it is. I have no doubt that mutiple apps are sending keep alives and other such stuff which could be consolidated. I am sure DoCOMo will have no ob
    • by robmv ( 855035 )

      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

    • by Miamicanes ( 730264 ) on Monday January 30, 2012 @05:33PM (#38870385)

      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.

    • 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)

    by vlm ( 69642 ) on Monday January 30, 2012 @04:49PM (#38869823)

    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...

  • 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?

    • Perhaps DoCoMo are the first to have these issues as they have over 57 million customers, half the entire Japan market which is made up of high (the highest revenue per customer in the world) value customers (read: lots of data usage).
    • It's cellular level signaling. To save battery the mobile device should spend most of its time in idle mode. In this mode the device mostly sleeps, and wake-up only for a short duration every paging cycle (from 640 ms to 2.56 s typically) to listen for a possible paging from the network telling it to wake-up because there's data to receive. In this idle mode, the device does not transmit, and only receive a few milliseconds every paging cycle. The UE will perform a sort of keep-alive (location tracking real
  • So, does DoCoMo need to invest more in its infrastructure, or is Android a data hog that needs reigning in?

    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.

  • 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]

  • ...does DoCoMo need to invest more in its infrastructure, or is Android a data hog that needs reigning in?

    640k ought to be enough for anybody.

  • 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

  • So after Google tells them to go screw themselves, what are they going to do? Ban the operating system?

    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?
  • 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

Those who do things in a noble spirit of self-sacrifice are to be avoided at all costs. -- N. Alexander.

Working...