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

But it simply ISN'T the case that every Apple product gets a massive review. Once again you're seeing what you want to see. The Apple products that aren't considered to be introducing notable tech don't get big reviews, often they don't even get noticed. The mac mini with Ivy Bridge was never mentioned. iPod Touch barely gets mentioned, likewise iPod classic or shuffle.

But why am I wasting my time? Anyone who thinks claiming that the iPhone5 is a "mid-range phone" is clearly someone with an agenda who will never be satisfied.Like I said --- AndroidPolice and WinSuperSite both exist. Perhaps you'd be a whole lot happy living your life in a bubble by reading only those?Reply

Where did I say iPhone 5 is a mid-range smartphone? Don't put words in my mouth, learn to read instead. And once again, as I said, all I want is the same treatment to all devices in the same category, not depending on the manufacturer. Last year Apple launched their new mp3 players, and those were covered here. When was someone else's mp3 player launch covered here, however briefly? There's even an iPod touch review from 2010 here. Where are the other mp3 player reviews? Reply

"Why does the Apple mid-range phone matter so much more than the others? "

Is Apple making some phone OTHER than the iPhone5 that has been reviewed recently? What is this "Apple mid-range" phone you are referring to?

Or is your point that you are somehow amazed that Brian Klug (whose entire life revolves around reviewing cellphone minutiae) would weigh on the rumor of the day when it involves cellphones, even when those cellphones are the iPhone 4s and 5? I honestly can't tell what's pissing off anymore.

I mean, Brian wrote an article a week ago on the WHITE Nexus 4, who sole difference from the previous Nexus 4 is the color. I didn't see you screaming in rage at the fact that he wasted precious pixels on such a "minor update". Reply

"Finally, the most unfortunate part for Toshiba is that the worst thing about the Kirabook—the often-blurry, inconsistent mess that is Windows' desktop scaling—isn't really anything it or even Microsoft can wholly remedy. The companies are at the mercy of third-party application developers, some of which don't properly support high-ppi displays in Windows despite supporting them in OS X (or even on the Chromebook Pixel, in Google's case). As was the case when the Retina MacBook Pro launched, buyers will have to wait for all of these applications to update before the things on their screens look as good as they're capable of looking. And if your software won't take advantage of the screen's extra density, why not consider one of the many cheaper 1080p alternatives?"

Have you tried running Win 8 with HiDPI (that's 2560 and beyond). It's the consensus amongst all tech reviewers that Win 8 scaling relies too much on 3rd party apps compliance.Reply

It is true though. Windows 8 DPI scaling is absolutely awful. For something that can scale internally (such as web browsers) things aren't so bad since the OS is cut out of the picture. But the number of applications rendered blurry on my Zenbook Prime (11" 1920x1080) is nothing short of disappointing.Reply

I own a Surface Pro, and while I love the freedom to run all my old x86 programs I have to agree DPI scaling is horrible in desktop mode. Some apps will have huge buttons, others have tiny buttons, others just get completely screwed up where you click on one button but a different one entirely thinks it's been clicked instead. Even basic text becomes blurry in some programs. I don't know where you're getting 'it isn't true' from, unless you just haven't experienced it yourself yet.Reply

First you have to tell us which flagship models to review. Apple's flagship models are the flagships for the industry; Retina displays that are added to PCs a year or two later, aluminum blade design that becomes the Ultrabook archetype, aluminum chassis that becomes the premium archetype, chiclet keyboards, etc. By reviewing Apple, Anand is in fact reviewing the state of the industry a year or two later.Reply

Has anyone else noted how Kepe never writes anything positive about Apple products these days? Some ill-founded rumor gets intelligently refuted and Kepe is right there attacking the publication and ignoring the accuracy.Reply