Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
AT&T Businesses Network Verizon Wireless Networking

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

Wrong Number: Why Phone Companies Overcharge For Data

Comments Filter:
  • Link to study (Score:5, Informative)

    by ccguy ( 1116865 ) on Saturday September 15, 2012 @06:38AM (#41345051) Homepage
  • by samjam ( 256347 ) on Saturday September 15, 2012 @07:36AM (#41345223) Homepage Journal

    Keep track isn't hard. Telco's already have optimisation for tcp re-delivery from the mobile gateway so that the distant sender doesn't have to re-send the missing packet, the telco can do that.

    This service improves tcp performance over a mobile network and is important for customer retention.

    Maybe not all telco's do it but I doubt it.

    http://www.iith.ac.in/~tbr/teaching/docs/transport_protocols.pdf [iith.ac.in]
    http://www.cs.sunysb.edu/~jgao/CSE370-spring06/lecture17.pdf [sunysb.edu]

  • by broknstrngz ( 1616893 ) on Saturday September 15, 2012 @07:57AM (#41345291)

    Indeed, all sorts of TCP splitting techniques exist. However, there is only so much data such a device can temporarily queue to keep retransmission on the terrestrial side. If you run a network with 10 million subscribers, it becomes very interesting.

    The mismatch comes from the fact that operators collect CDRs on the terrestrial side of their GGSNs. So even if the mobile subscriber does not need to resend a segment, the terrestrial retransmission is still accounted, as are the duplicate ACKs sent by the Internet host.

    You simply can't expect both having the cake and eating it. High latency links come with trade-offs.

    I work for a provider with much higher RTTs (~1200ms). The 5% reported by the study is exactly what we are seeing.

  • Re:DNS not counted? (Score:5, Informative)

    by isj ( 453011 ) on Saturday September 15, 2012 @09:45AM (#41345687) Homepage

    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.

This file will self-destruct in five minutes.

Working...