Yesterday there were some allegations made about whether Apple is intentionally throttling cellular data throughput on iPhones and iPads via some files used for network provisioning. The original source post has since been deleted, so I am linking to the always-awesome Tmonews instead. The reality is that this is simply not the case. Apple doesn't limit cellular data throughput on its devices — there's both no incentive for them to do so, and any traffic management is better off done in the packet core of the respective network operator rather than on devices. Sideloading tweaked carrier bundles isn't going to magically increase throughput, either.

At a high level, some of this seemed plausible at first, as this wouldn't be the first time that a handset maker throttled devices via some on-device setting at bequest of a network operator. If you've been with us long enough you'll probably remember the case of the HTC Inspire 4G and Atrix 4G, two handsets which AT&T disabled HSUPA on, and later re-enabled with an update. Later there was the AT&T Nexus S which also had its HSDPA and HSUPA categories limited via build.prop. 

Thankfully this is not the case currently with any iOS devices.

There's no arbitrary capping of UE Category (User Equipment speed category), throttling on-device, or anything else that would prevent the device from attaching and taking full advantage of whatever the network wants to handshake with. If you're going to read anything, just take that away with you, as the full explanation gets technical fast. If you're willing, however, let's walk through it.

First, what is an IPCC or "Carrier Bundle" in the context of iOS? In order to support a huge number of mobile networks, Apple builds these bundles which contain settings used to provision and optimize the device for a particular network in collaboration with the respective network operator. These then get distributed inside a particular iOS release, or asynchronously via iTunes or over the air if they need to make updates as necessary. 

Inside an IPCC are a number of .plist and .pri files for defining things unique to each network. There are also PNG images for the operator logo at top left with appropriate tweaks to character kerning and appearance.

Inside the .plist and .pri files are settings which define relevant network parameters for both iOS and the baseband. This spans the gamut from parameters like APNs that the phone should use, short codes (USSD codes) for checking balance or data use, credentials for WiFi networks that the mobile network operator runs to do offloading, to MMS settings such as payload size, address, and recipients, or tethering and visual voicemail settings. They also do contain lower level things such as band priority, configuration for UE category, and other network access settings. This is also where the "4G" indicator and 3G toggle settings are changed (see the above "DataIndicatorOverride" line), if you remember that whole situation. That last one remains my only gripe I've ever had with Apple's carrier bundles.

Apple doesn't openly document what these settings all do, because it doesn't have to since they're only developed and maintained internally, however nearly all of it is immediately obvious if you know the lingo. The problem is that a few of these were misinterpreted, leading to the false conclusion that there's some throttling conspiracy at play here, when there really isn't. 

I'm going to look at the ATT_US bundle since that's where the most attention is. First is the allegation that the iPhone 5 is being artificially capped to HSDPA Category 10 (16 QAM single carrier - 14.4 Mbps) on the downlink when in fact it is capable of Category 24 (64QAM dual carrier - 42 Mbps).

This is inside the carrier.pri file, but it actually applies only to the iPhone 4S, a device which has Qualcomm's MDM6600 inside and is only capable of up to Category 10 on the downlink in the first place. There's no amount of hacking that is going to enable 64QAM or a second carrier on MDM6600, there simply isn't the appropriate QAM decoder inside the baseband, nor transceiver wide enough to do dual carrier. 

The appropriate setting for HSDPA category on the iPhone 5 is set in the appropriately named 'overrides_N41_N42.plist' which of course refers directly to iPhone 5 via N41 and N42 codename. Inside this file we find the expected HSDPA Category 24 (64QAM dual carrier - 42 mbps) setting. This is actually entirely moot however, as the UE doesn't decide what capabilities it attaches to the network with, it merely exposes them in a message sent to the network on attach, which then decides what to negotiate. In the case of AT&T in the USA, that's Category 10 basically everywhere. I've never ever seen HSDPA Category 14 (64QAM - 21.1 Mbps) ever on AT&T's network, though this is a continually debated subject with enthusiasts, I've been told repeatedly AT&T has no desire to go any further, and certainly none to deploy dual carrier. So your HSDPA Cat 24 handset attaches as Cat 10 on HSPA+ either way, but Apple sets it to the full capabilities of their handset.

There's also the band class preference and something which looks like a UARFCN being set. I suspect this is being used to seed the baseband's preferred frequency table so it can perform a network search in that band on network attach to speed up initial attach. Changing this won't affect the neighbor list which the baseband builds out to decide what to handover to, something many don't understand. 

Down below it we a similar set of settings for LTE.

The two keys here with the word "throttle" in them refer purely to a retry interval throttle to prevent the phone from continually trying to reattach to an LTE network in the case of some error. The name alone seems to be the burden of proof here that this is "throttling," however it could just as easily be renamed "retry interval timeout" and serve the same function. There are similar "FAILURE_TIMER_5:720;" entries in the IPCC files for the rest of the operators which do exactly the same thing and set a retry timer for their appropriate networks. For example, Verizon has "DATA_TRTL_ENABLED" which is the equivalent setting for 3GPP2 networks. I'm not going to go through all of them since they do exactly the same thing and basically prevent your phone from wasting a ton of battery trying to retry endlessly when there's some network issue, or creating a stampede or overload from too many handsets retrying to connect pointlessly fast.

Likewise there's an LTE band preference set here which corresponds to Band 17 (700 MHz Lower B and C), the only band AT&T runs its LTE network at present. There's no AT&T LTE on Band 4 lit up until at earliest later this summer, but again if there were, it'd attach anyway but after a while longer. There's nothing sinister about setting a preference here. 

Virtually all the major mobile network operators do traffic management, but it's done in the packet core away from the UE where anyone can play with it. Some do more than others, and it varies more often than not by market region and time of day like you'd expect, as network conditions change. That's the reality of things, but in almost all cases the operators want their networks to go fast and for their users to see the best speeds. 

Again, there's no reason for Apple to want to arbitrarily limit their devices, and the reality is that they don't, at all, on any version of iPad or iPhone or in any of the carrier bundles they've distributed for network operators. If anything, Apple has long been one of the few handset vendors who initially understood the importance of limiting annoying operator customizations. The Carrier Bundles are quite literally the only place in the entire OS they have indirect access (through Apple) to toggles they can play with.

POST A COMMENT

39 Comments

View All Comments

  • tekneek - Thursday, June 06, 2013 - link

    Wonder what changes the custom/hacked ipcc have.

    http://www.itweakios.com/apps/blog/show/26861181-u...
    Reply
  • reuthermonkey1 - Thursday, June 06, 2013 - link

    Thank you for this confirmation. I feel like i've been saying for years that carriers don't manage their data networks by relying on build.props! Reply
  • jamyryals - Thursday, June 06, 2013 - link

    This whole situation reminds me of the days when "Leaked" OS updates would hit CrackBerry and all the comments proclaimed how fast the update made their phones. Reply
  • Kepe - Thursday, June 06, 2013 - link

    Has anyone else noted how Anandtech never writes anything negative about Apple products these days? Apple products always get the most in-depth articles and new products get several articles covering different aspects of the device in question. And then there's this. Some internet rumour about Apple limiting cellular throughput, and Anandtech is right there defending Apple and refuting the rumour. How about covering the bent iPhones? Oh yeah, that would show Apple in negative light, can't do that here.
    I love the site and the articles, but I don't understand why Anandtech has become such a pro-Apple site. How much are they paying you guys?
    Reply
  • B - Thursday, June 06, 2013 - link

    I think this is a case of you seeing what you want to see. There are 20 main articles on the Anandtech home page right now, and none of them are about Apple. There are another 20 'Pipeline' stories and only one of them is Apple. So there is 1 of 40 about Apple. When there is a refresh and Apple holds its conference there will be a wave of information and probably many articles to cover it and then it will be silent on Apple again, but this is just due to the nature of the product release cycle.

    With respect to this article it's objective, not opinion based, the facts have been laid out empirically and the myth has been debunked. I thought it was interesting to understand how this all works and how the author put this puzzle together. Just my two cents.
    Reply
  • danstek - Thursday, June 06, 2013 - link

    This wasn't contrived. People requested for him to explain what was really going on. Also, there's plenty of well detailed reviews and articles over the past month that have nothing to do with Apple. Reply
  • Homeles - Thursday, June 06, 2013 - link

    Oh, look. Another hiveminded Apple hater. Your kind is like a dime a dozen on the internet.

    Guess you didn't read Brian Klug's HTC One article, and the glowing review he gave the phone? May I point out to you that it's the only smart phone to have ever recieved an editor's choice award on this site?

    Keep your confirmation bias in check, please.
    Reply
  • Kepe - Thursday, June 06, 2013 - link

    I didn't say they don't write positively about other devices. It's just that Apple reviews are always the most in-depth and longest compared to anything else here, and there's no criticism towards Apple at all.
    The HTC One has 4 articles/news about it here on Anandtech (hands on, camera, mini review, review).
    The SGS4 has 6 articles/news about it (3x Exynos 5 Octa, the release, hands on, review).
    Iphone 5 has 15 articles/news about it (rumours, release live blog, 3x A6 SOC, new connector, announcement, hands on, RAM, Geekbench results, SunSpider performance, performance preview, display analysis, review, iphone 5 on T-mobile).

    So yeah. Call me biased, but I'm not the only one who is being biased around here.
    Reply
  • Kepe - Thursday, June 06, 2013 - link

    Also, if you copy/paste the reviews in to a word processor and look at the word counts, they are as follows:
    iPhone 5 review: 30 945 words
    HTC One review: 24 176 words
    SGS 4 review: 7 768 words

    The iPhone 5 has a dedicated article about its display + the longest and most thorough review of the three.
    The One has a dedicated camera article + over 1/3 of the review is also about the camera.
    The SGS4 review is the only proper article about the device.
    Reply
  • unreported - Friday, June 07, 2013 - link

    Seems you have lot of free time. May be you can write a negative article about apple Reply

Log in

Don't have an account? Sign up now