Slashdot Mirror
Wrong Number: Why Phone Companies Overcharge For Data
MrSeb writes "A recent study (PDF) conducted by UCLA professor Chunyi Peng shows that carriers generally count data usage correctly, but those customers who commonly use their device in areas with weak signal strength or to stream audio or video are often overcharged. Peng and three other researchers used data gleaned from an app installed on Android smartphones on two different carriers. The issue appears to be in how the system is set up to count data usage. Under the current scenario, data is charged as it is sent from the carrier's network to the end user. What does not exist is a system to confirm whether the packets are received, and thus preventing charges for unreceived data. Peng demonstrated this in two extreme circumstances. In one case, 450 megabytes of data was charged to an account where not a single bit of it had been received. On the flipside, Peng's group was able to construct an app which disguised data transfers as DNS requests, which are not counted by the carriers as data usage. Here they were able to transfer 200 megabytes of data without being charged. Overall, the average overcharge is about 5-7% for most users. While that does not seem like much, with unlimited plans gone and data caps in style that could pose potential problems for some heavy data users. Could you be going over your data allotment based on data you never received? It's quite possible."
* Android Droidstats usage logger: 369 MB (2012-07-31 22:16h)
* Android "My Data Manager": 337 MB (2012-07-31 22:16h)
* Vodafone online usage monitor: 307 MB (up to 2012-07-30 17:46h)
* Phone bill for July: 343 MB (since a couple of months they actually mention the total; before I needed to use a perl script to parse the PDF invoice and add the data usage of some 200 separate data sessions)
When I asked about the differences a few months ago, the Vodafone customer service told me: "The information on your Vodafone account online is the real usage. Numbers from data usage apps are not reliable." But I highly doubt that I used 36 MB over the last day of the month, so it seems that within Vodafone they have different systems.
My train commute (where I use most of my data) passes through an area with bad coverage, so I would have expected a bigger difference based on the theory that packet loss accounts for most of the difference.
Avantslash: low-bandwidth mobile slashdot.
Also, most people have no idea of the optimization techniques operators use.
Navigate to any content heavy website. If your mobile browser allows you to, try to see the source of the page.
Chances are you will see all whitespace trimmed, all CSS and JS inlined. All pictures are compressed in a lossy
fashion to reduce their size.
There is also HTTP request coalescing. If you request "/", the whole page will be retrieved, then processed as
above and delivered to the mobile browser in a single reply. How many GET requests do you save? A lot.
If there were no such techniques, one's mobile bill would be almost twice as high and the browsing experience
would be 4 times as slow.
I also work for a supplier of GSN nodes (with charging in particular, hence posting as anonymous coward). I know we can't work at the same company, because where I work, a major bug like that would halt any delivery until it's fixed. There's no way you'll have more bytes in a PGW/GGSN CDR than what you see on Gn. A bug report would be written immediately. Any internal packet drop in our system will not be counted in CDR:s. Packet drops on Gn? Not going to happen. So you're either making that up, or your Wireshark setup is miss configured, or you work for.. Nokia? :)
HTTP request coalescing is a mixed bag, since the all the stuff you inline will be resent when you request the next page. If you have carefully reduced the size of your html pages and set your CSS and JS to be basically cacheable forever, you may want to add Cache-Control: No-Transform to your headers to request that no such thing is done. The same header should theoretically prevent your images from being re-compressed with an absurdly bad JPEG quality setting.