Apple Not Throttling iPhone or iPad Cellular Throughput via Carrier Bundles

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.