So AT&T relies on nightly checkins from the device reporting how much data it uses? They don't do the accounting in the network? That seems crazy. So on a jailbroken device you could just tell it to report 10% less and it would all be even.
I don't think that's how it works. I think what the speaker meant is that the accounting data is forwarded from the local access point to the billing system at the end of the day.
From the article, "the time stamp reflects the time that your device established a connection to the [billing system], not the time that you sent or received data." Note the "your device".
To really confirm this they would need to monitor the network driver(s) on the phone and record the exact data amounts that are passed and then compare that to what AT&T reported.
Another option would be to emulate a cell tower, connect the device to it, and monitor traffic that way.
The thing I did find interesting was that they said some carriers round up transfer sizes. That could account for some big differences when you consider that this rounding could happen per transfer or session. To me that sounds like highway robbery akin to shaving pennies off interest.
A sufficiently custom web server does have the means to estimate protocol level overhead (TCP and IP headers, retransmissions). The only reason it couldn't track would some kind of a system that splits TCP connections (e.g. a proxy) located somewhere between the billing system and the web server. But most forced proxies only run on port 80, and could easily be circumvented.
The measurement would not be totally accurate as the sender couldn't know at which point packet loss happened. A packet lost somewhere after the billing system and retransmitted should count, a packet lost before the billing system should not. But it would at least give an upper bound. If the bottleneck in the system is the RAN rather than the internet links that upper bound could actually be quite close to the real figure.
Of course some technical competence would have been required for this experiment, probably more than these clowns have. And it would likely have shown about 5-10% protocol overhead, which would not have done their case any good.
To verify that the device isn't indeed transferring any data as part of any background Apple process they should put it on WiFi and monitor traffic through the router. It should be zero.
I'm logically assuming that any background process that would transfer data over 3G would also do it when on WiFi network.
They could also get a data modem from AT&T and test it by connecting to the tower but not transferring any data. If AT&T is overestimating data transfers or has phantom data then it would be across the board and would also show up on transfers through their data modems not just their iPhone plans.
"If AT&T ... has phantom data then it would be across the board and would also show up on transfers through their data modems not just their iPhone plans."
Why?
Their modems might be programmed to operate or need to update differently.
Actually, it is doable. I met a guy that had a whole SDR plus GSM stack. I was able to pair my blackberry with it. He runs a cell network at Burning Man, apparently.
I've compared the network usage as reported on the iphone with the one AT&T measures, and it's not the same. I've paid over-usage fees at times when according to the iphone reading I had 20 MB left.
Now it all makes sense...
Where did it say you had 20MB left? Were you using ATT's evaluation? Or a third-part app? Or, the iPhone's operating system, itself.
If you're using the iPhone's operating system, ATT may be calculating space, and rounding up in a different way from Apple. (Examples of this exist in other child-comments of the OP)
Presumably because he was connected to the 3G (or other data) network. Unless he can run tcpdump on the iPhone itself or become a man in the middle between the iPhone and the data network, he couldn't capture traffic.
An interesting test would be to connect the iPhone to a regular wireless router, measure the activity, then compare that to billing activity. Although my Android Galaxy S, for example, connects to the data network to look for updates even though it is connected to a wireless network -- so this test could be moot.
Clearly this guy's test was incomplete and guaranteed to give the result they sought...
However, I have worked in capacity planning at a mobile telecom, and it's scary how confused that alleged experts are about "bytes" and "bytes per second."
Given that experience, I'm not surprised that AT&T would get "bytes transferred" wrong, but I think it's more likely due to incompetence and not malice. I wouldn't be surprised if they underbilled people also.
17 comments
[ 4.1 ms ] story [ 45.9 ms ] threadThis article suggests they can track data usage in the network and jailbroken phones cannot override this.
To really confirm this they would need to monitor the network driver(s) on the phone and record the exact data amounts that are passed and then compare that to what AT&T reported.
Another option would be to emulate a cell tower, connect the device to it, and monitor traffic that way.
The thing I did find interesting was that they said some carriers round up transfer sizes. That could account for some big differences when you consider that this rounding could happen per transfer or session. To me that sounds like highway robbery akin to shaving pennies off interest.
I agree. The article states that a custom web server was used, but the web server has no means of tracking protocol overhead.
The measurement would not be totally accurate as the sender couldn't know at which point packet loss happened. A packet lost somewhere after the billing system and retransmitted should count, a packet lost before the billing system should not. But it would at least give an upper bound. If the bottleneck in the system is the RAN rather than the internet links that upper bound could actually be quite close to the real figure.
Of course some technical competence would have been required for this experiment, probably more than these clowns have. And it would likely have shown about 5-10% protocol overhead, which would not have done their case any good.
To verify that the device isn't indeed transferring any data as part of any background Apple process they should put it on WiFi and monitor traffic through the router. It should be zero.
I'm logically assuming that any background process that would transfer data over 3G would also do it when on WiFi network.
They could also get a data modem from AT&T and test it by connecting to the tower but not transferring any data. If AT&T is overestimating data transfers or has phantom data then it would be across the board and would also show up on transfers through their data modems not just their iPhone plans.
Why?
Their modems might be programmed to operate or need to update differently.
http://www.networkworld.com/news/2010/083010-open-source-voi...
If you're using the iPhone's operating system, ATT may be calculating space, and rounding up in a different way from Apple. (Examples of this exist in other child-comments of the OP)
An interesting test would be to connect the iPhone to a regular wireless router, measure the activity, then compare that to billing activity. Although my Android Galaxy S, for example, connects to the data network to look for updates even though it is connected to a wireless network -- so this test could be moot.
However, I have worked in capacity planning at a mobile telecom, and it's scary how confused that alleged experts are about "bytes" and "bytes per second."
Given that experience, I'm not surprised that AT&T would get "bytes transferred" wrong, but I think it's more likely due to incompetence and not malice. I wouldn't be surprised if they underbilled people also.