Wrong Number: Why Phone Companies Overcharge For Data 105
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."
Re:DNS not counted? (Score:3, Insightful)
The trouble is. . . (Score:5, Insightful)
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.
Word Play (Score:2, Insightful)
Carriers are businesses (Score:4, Insightful)
Re:The trouble is. . . (Score:2, Insightful)
and if the phones allowed ad-blocking, your data use will drop significantly.
I'm fine with ad's in a unlimited ecosystem. but in a bandwidth limited, receiver pays, system? Screw all ad's. It's why I jailbroke my iphone and installed an ad blocker, and my android phone also had ad blocking added to it.
Re:DNS not counted? (Score:2, Insightful)
A strong bias and a poor conclusion. Rather, a poor methodology. Since you also appear to work in the industry - I'm wondering if you notice what I notice? The two methodologies they used for detecting traffic at the mobile... They used an android application that does not require root access (e.g. isn't taking pure IP level statistics) and the Traffic Status API.
Two pretty big problems. 1) They don't measure TCP Retransmissions... This is uhh a big "duhh" - but more disturbing they don't measure IP packet overhead. E.g. the application they used uses the same API their homebrew application uses - both of which look at actual TCP and UDP payloads (reassembled in the case of TCP). IP Packet Overhead, SYN's, SYNACK, FIN, RESET. Are those measured? Nope.
Basically, the methodology is flawed and the title is sensationalist. If this is the quality of research coming out of American Universities then we're fucked. Anyone who has a minor clue can read the paper and come to some astonishing conclusions:
1) They don't measure IP Packet Overhead
2) They don't measure TCP Overhead
3) They don't measure TCP Retransmissions
I'd wager most of the "over charged data" they're claiming is coming from #1 and #2, just setting aside #3. And with regards to #3 - it's clear that it's to the consumer's benefit to measure traffic at based on the number of IP Packets, as opposed to measuring traffic on the RAN. If the consumer had to pay for RAN - it would create a billing nightmare. Those who require a lot of RAN retrans would be screwed.
Finally, the idea of measuring actual payload received on the device, and then reporting that back to the network is simply laughable. It's stupid at best, retarded at worst. The overhead in this reporting would drive the cost of data usage up and would only hurt to consumers. Considering the possible signalling load, let alone the security implications...
Overly educated morons talking about shit they don't understand. It's no wonder CS grads in this country can't find jobs. They should demand their education $$$ back - because they clearly didn't learn enough to actually be effective in the workplace....