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 Your Comment

39 Comments

I'm talking about much more than this one article. Also, I'm not a review site claiming to be reliable and unbiased. But don't get me wrong. I love AnandTech and all Anand has done to make computing better. I just can't get over the Apple love that has been going on for the past couple of years. Yes, they make desirable products that many want and some even consider as a status symbol, but nothing's perfect.Reply

There's a very straightforward reason for why there are more Apple articles than one may expect: they get mouse-clicks. I clicked on this headline because it had the word Apple on it. I also read the entire HTC one review with interest because it would be the phone I would most likely defect to if I left the iOS ecosystem. I feel anandtech does a very balanced job of reporting tech news. If Kepe only wants to read android news, he should pay someone to do that.Reply

I read almost all reviews published here. Even the Apple ones. And FFS, I'm not saying there shouldn't be ANY Apple news/articles/reviews. I'm just saying that Apple gets way too much attention compared to others, and that isn't right if you're supposed to be an unbiased tech site. There are whole smartphone OSs, manufacturers and ecosystems AnandTech is ignoring, while they're covering every little detail about Apple smartphones.Reply

Anand and the team have taken it upon themselves to report on the state of the art, and whether you agree with Apple or not, they're a huge player, and their design and technical decisions have a disproportionately strong effect on the industry - you can't really effectively discuss the state of the art if you concern yourself with making sure everyone gets the same amount of air time.

I think they've done a good job putting out articles that add meaningful insight to the discussion instead of just troll and fanboy fodder, and true unjustified bias would be if they intentionally suppressed Apple related articles for fear of sounding partial.Reply

These days there are far too many people producing crap on the internet merely to gain pageview via ads.There are Company paying people to pollute, distill the social network in generating traction or hate towards a brand.There are those who are absolutely mindless and just trust what they read blindly without thinking through their heads. Reply

Brian, why don't you actually test this? There are "tweaks" available that supposedly fix the problem that Apple is accused of creating--why don't you do the traditional Anandtech thing and provide some hard evidence? Run speedtest checks (and whatever other data gathering you feel is appropriate) with both the Apple provided settings and with tweaked settings, and show us the difference (or lack thereof).Reply

The ENTIRE PREMISE of tweakios' claim was idiotic the moment it was posted.Let's suppose that ATT has towers that support 64-QAM. Then what possible advantage is there to Apple or ATT of preventing iPhones from using that and forcing them to use 16-QAM? All it does is force the phones to spend more time transmitting data, so it- overloads ATT's network (makes ATT look bad)- makes iPhones slower (makes Apple look bad).

If you're going to create a conspiracy theory, the theory should at least make some sort of sense. This theory makes none. It's the sort of thing spouted by someone who hasn't a clue how the networks actually work and what issues are really gating performance.Reply