One train of thought I followed with my easy smartphone Wi-Fi tracing setup I wrote about recently is how often a typical smartphone contacts the network per hour even if it is not used and just lies on the table and what impact that has on the cellular network in a larger context. Even though I monitored the devices behavior over Wi-Fi the result can be applied to cellular as well as it is likely that most applications do not make a difference anymore between Wi-Fi and cellular connectivity. The result is quite interesting:
Even without user interaction my smartphone contacts the network 10 times per hour. Out of these, 4 times is for checking email. Another 4 times Android calls home to Google, mainly using a Google Talk domain, even though I've disabled the app. Less frequently a DNS query and subsequent traffic can be observed to a number of additional Google domains. I feel quite observed by such unwanted behavior but there's something that can be done about it with a rooted phone as I've described here in the past. Further connections are made for various other purposes. My calendar and address book are synchronized with my Owncloud server at home every four hours, the NTP server is queried to keep the clock in synch, crash reports are sent to crashlytics.com (have I consented to this?), the weather app requests updates, the GPS requests ephemeris data periodically, etc.
So what does this mean on a larger scale? Let's say a network operators has 15.000 3G base stations (extrapolated from here) and 10 million smartphones. If those smartphones were evenly distributed across all base stations there would be around 660 smartphones per base station or around 220 smartphones per sector. If each smartphone connected to the network 10 times an hour that's 2200 requests an hour per sector. If the connection is held for 10 seconds on average, that's 2200 requests / (60 minutes * 60 seconds / 10) = 6 concurrent connections just for the background traffic of the devices.
Some cells are obviously busier than others so some cells probably see two or three times this number, i.e. 15-20 concurrent connections just for background traffic. As the number of concurrent users in 3G cells is likely to be less than a three digit figure that's quite a sizable percentage. And the 10 connections per hour is perhaps even a conservative number as many subscribers use instant messengers that need to send frequent TCP keep-alive packets so they don't loose connectivity to the server. On the other side, many smartphones are used over Wi-Fi, especially when people are at home, which is likely to significantly reduce background traffic over cellular in residential areas. Not so in business areas, however.
So where do we go from here? One good thing is that LTE networks are mostly in place now and many new smartphones, especially those of heavy users are LTE capable by now. That significantly reduces the load on 3G networks. And from what I hear the number of simultaneous users in an LTE cell can be much higher than in a 3G cell. The right technology at the right time.
5 thoughts on “My Smartphone Contacts The Network 10 Times Per Hour When Its Idle”
As a follow-up to my previous post, Patrick Tan, with Alcatel-Lucent, covered this background issue of ad network data use, signaling, and client power consumption in blogs earlier this summer. This is very good reading about “appvertising.” My concern about background browser data use on mobile devices is probably not important when compared to apps. on smart phones.
I am somewhat of a privacy nut myself and really enjoy your articles on that topic. And also the link to the old post from 2011 that I missed about /etc/hosts.
Personally I am also constantly testing the limits of privacy and convenience. Lucky for me I am not a social network guy, so I wouldn’t have a Facebook/Twitter account even if there were no privacy concerns. I figure that would be a big issue for people who are more connected and really enjoy social networks online.
But even without that I like my smartphone. I currently use two side by side. Both are Android/CyanogenMod. One with Google installed and one without the GApps package. I have a very recent CyanogenMod for the one without GApps. One that comes with the privacy settings. But there are still so many issues. The keyboard for example. I like Swiftkey. So I had to install XPrivacy to keep it from mailing all my input home. And then there is the fact that it is a cellphone after all. Not only does the network always know where I am, there are lots of processors with proprietary firmwares (baseband, for example) on it.
It is a rather difficult thing to value privacy, have a smartphone and knowing about the smartphone as much as I do, which is probabely not half as much as you know.
Keep the articles coming!
Very interesting post Martin! Would you agree that most of these connections would actually go over Cell FACH, because they seem like quite small packets (email check, keep alives, DNS requests)? Thus although there may be around 6 concurrent users in a cell, they’d all be in Cell FACH state, and not really affecting the customer experience for those on HSDPA with a dedicated channel? Also may I ask which connections took on average 10 seconds for you? I’d have thought the keep alives would be done in about 1-2 seconds? Thanks for these excellent
in my experience, well tuned networks use Cell-DCH for such operations
because its more than just a few bytes being exchanged. Another reason
might be to optimize network behavior for non-background operations such
as web browsing responsiveness. If the network first went to Cell-FACH
(from Cell-PCH or URA-PCH) when the DNS query is made and then to DCH
when the web page data is downloaded this results in a lag time of a few
hundred milliseconds that is noticable to the user.
As a consequence the Cell-FCH state is usually skipped by the network
configuring thresholds in a way so the device sets the Traffic Volume
Indicator in the Cell Update message when returning from Cell- or
URA-PCH even if only little data is in the transmit buffer.
Comments are closed.