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."
Well I sent a check for my monthly bill... not my fault you didn't receive it.
Here's the paper: http://www.cs.ucla.edu/~chunyip/publications/mobicom12-peng-accounting.pdf
I guess that means the operators will shortly release an update for the phone OS's to also charge for the data the phone sent but wasn't received by the operator.
1. write an app that disguises streaming porn as a DNS request
2. ???
3. Profit!
http://code.kryo.se/iodine/
It is true, I work for a supplier of GSN nodes and most operators configure GGSN/PGW to classify DNS and TCP SYNs as free. However, this freebie is overset but charging retransmission in the telco IP network. Personal experience in comparing sent bytes vs received bytes on remote and charged bytes in CDRs. Wiresharking on Gn interfaces pointed out the origin of extra bytes in CDR. So there never is a free lunch
Thank you for your suggestion. at&t(R) is committed(tm) to rebuilding the nation's largest 4G network this year with your input. To pay for the buildout* you will notice a 10% 2012 Nation's Largest 4G Network Improvements Fee along with a 200% SMS price increase. Thank you again for choosing at&t(R), with the nation's largest 4G network.
*Buildout subject to cancellation without notice. Just kidding about that last part, we cancelled it while you were reading that sentence. The fee stands to pay for the costs of typing the prior two and commissioning a forthcoming Gartner study to validate their market impact.
You can hold down the "B" button for continuous firing.
Resending a packet due to a missed ACK takes up air time, just like it did sending it the first time, and the carriers have no control on where the user will be. If they make their systems robust enough to move their present average packet reception rate from an already-good 93-95% to, say, 99%, this will only enable their users to move down another floor in their sub-basements, or another few city blocks, or another cubicle row deeper into the building, before the average goes back down again -- after all, wireless systems have limited range. The cost of the new infrastructure would be roughly twice that of the previous one ("increasing coverage is increasingly expensive"), and you're going to pay for the cost of the infrastructure either way in your air-time charges.
Look at it this way: Even if the company only charged for packets successfully received, it would just increase their rates by (1/0.95) - 1 = 5.3% to (1/0.93) - 1 = 7.5% to maintain the same cash flow. Plus it would have to start keeping track of the success or failure of each packet transmitted, and put that into its billing scheme. That's a database PITA I don't want, thank you very much.
* 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.
Do you really think what carriers charge is how much it actually costs to send a text message?
The operators that my employer delivers charging solutions to rarely use the byte counters from the GGSN because they charge he traffic types differently, e.g. "free facebook" while other traffic is charged based on byte counters from the DPI box. It is true that some of the newer GGSNs/ASN-GWs have adequate DPI capabilities so they can classify the traffic with enough granularity and the byte from them can be used.
There is one slightly fishy thing in the study (yes, I read the fine paper). Their test with logging on, go idle, move to radio-inaccessible room, then have server start steaming UDP to the phone (which will be dropped due to inaccessibility). In my experience the SGSN/GGSN quickly signals that the user has gone offline (PDP session termination), and the stream of UDP from the server is blocked at the DPI or the GGSN. Sounds like the operator that the study used has a major bug in its charging setup where PDP session termination doesn't also stop the IPuser association.