Apple's First LTE iPhone

Section by Brian Klug

If a third of the iPhone 5 story is the A6 SoC, and the other third is the change in display and industrial design, the final third is undoubtably cellular connectivity, specifically 4G LTE (Long Term Evolution). The iPad 3 was Apple’s first LTE-enabled consumer electronic, and the iPhone 5 is now Apple’s first LTE-enabled smartphone. The road to LTE for Apple’s iPhone is a long and interesting one, and unsurprisingly Apple waited for a second generation of LTE-enabled, 28nm basebands before making the move to LTE.

If you’ve already read our piece on the iPhone 5 SVLTE and SVDO situation a lot of this will already be familiar, as I pretty much gave all the background for what I wanted to talk about regarding the iPhone 5 and LTE in that piece at a high level.


MDM9615 and RTR8600 in iPhone 5 - Courtesy iFixit

At the core of the iPhone 5’s cellular architecture is Qualcomm’s MDM9615, which we’ve been predicting would be the solution Apple would use for some time now. This is a 28nm 2nd generation LTE baseband that has at its core the same modem IP block as what’s in MSM8960 and has already shipped in a bunch of phones. MDM9615 supports a host of air interfaces: Category 3 LTE FDD/TDD (Frequency and Time Division Duplexing), 3GPP Release 8 DC-HSPA+ (42.2 Mbps HSDPA/5.76 Mbps HSUPA), TD-SCDMA (4.2/2.2 Mbps), GSM/GPRS/EDGE, 1x-Advanced, and EVDO Rev.A and B. Of course, it depends on the individual OEM to implement the appropriate RF path for these features, but that’s at the maximum what MDM9615 supports.

Apple iPhone - Cellular Trends
  Release Year Industrial Design Cellular Baseband Cellular Antennas
iPhone 2007 1st gen Infineon S-Gold 2 1
iPhone 3G 2008 2nd gen Infineon X-Gold 608 1
iPhone 3GS 2009 2nd gen Infineon X-Gold 608 1
iPhone 4 (GSM/WCDMA) 2010 3rd gen Infineon X-Gold 618 1
iPhone 4 (CDMA) 2011 3rd gen Qualcomm MDM6600 2
(Rx diversity, No Tx diversity)
iPhone 4S 2011 3rd gen Qualcomm MDM6610 (MDM6600 w/ ext. trans) 2
(Rx/Tx diversity)
iPhone 5 2012 4th gen Qualcomm MDM9615 w/RTR8600 ext. trans 2
(Rx/Tx diversity, 2x1MIMO for LTE)

In addition, MDM9615 is the first of Qualcomm’s LTE basebands to be natively voice enabled. MDM9600/9200 was originally designed as a data card solution primarily, but could work with voice if paired with a Qualcomm SoC in a so-called “Fusion” scenario. This was the major design caveat which made MDM9x00 an unlikely choice for anything but a smartphone platform based around a Qualcomm SoC but why it was suited to a platform that doesn’t need voice like the iPad 3. With MDM9x15 these barriers have come down, and along with it we get a smaller overall package size (from 13x13 mm down to 10x10 mm) and lower power consumption thanks to the move from 45nm TSMC to 28nm TSMC. The reality is that to implement cellular connectivity with any baseband you also need a PMIC (power management IC) and transceiver for downconversion after filters to I/Q data that gets shot into the appropriate port on the baseband itself. In this case the PMIC that works with MDM9x15 is PM8018 and the transceiver is either the 65nm RTR8600 in the case of the iPhone 5, or the 28nm WTR1605 that is just now emerging in some other phones. More on that last part in a minute.

Apple iPhone 5 Models
iPhone 5 Model GSM/EDGE Bands WCDMA Bands CDMA 1x/EVDO Rev.A/B Bands LTE Bands (FCC+Apple)
A1428 "GSM" 850/900/1800/1900 MHz 850/900/1900/2100 MHz N/A 2/4/5/17
A1429 "CDMA" 850/900/1800/1900 MHz 850/900/1900/2100 MHz 800/1900/2100 MHz 1/3/5/13/25
A1429 "GSM" 850/900/1800/1900 MHz 850/900/1900/2100 MHz NA 1/3/5 (13/25 unused)

Apple has already announced two hardware models for the iPhone 5: A1428 and A1429, of which one has two different provisioning configurations (A1429 comes in both a “CDMA” and “GSM” flavor). There are physical hardware differences between the two handsets, specifically differences in both the LTE power amplifiers and switches. The two hardware variants support different LTE bands, but the same set of WCDMA and GSM/EDGE bands. All three configurations of iPhone 5 support WCDMA with HSDPA Cat. 24 (DC-HSPA+ with 64QAM for up to 42 Mbps on the downlink) and HSUPA Cat. 6 (5.76 Mbps up). Only the A1429 “CDMA” configuration supports CDMA2000 1x and EVDO, and interestingly enough even supports EVDO Rev.B which includes carrier aggregation, though no carrier in the USA will ever run it. In addition the FCC reports include 1xAdvanced testing and certification for CDMA Band Classes 0 (800 MHz), 1 (1900 MHz), and 10 (Secondary 800 MHz).

Apple iPhone LTE Band Coverage
E-UTRA (LTE) Band Number Applicable iPhone Model Commonly Known Frequency (MHz) Bandwidths Supported
1 A1429 2100 20, 15, 10, 5 MHz (?)
2 A1428 1900 20, 15, 10, 5, 3, 1.4 MHz
3 A1429 1800 20, 15, 10, 5, 3, 1.4 MHz(?)
4 A1428 1700/2100 20, 15, 10, 5, 3, 1.4 MHz
5 A1428, A1429 850 10, 5, 3, 1.4
13 A1429 700 Upper C 10, 5
17 A1428 700 Lower B/C 10, 5
25 A1429 1900 20, 15, 10, 5, 3, 1.4

The difference in LTE bands is a bit more complicated, and both models appear to support more LTE bands than laid out if you simply inspect the iPhone 5 specs page. If we turn to the FCC documentation (which is concerned only with transmitters on regulated bands in the USA) we can glean that there are indeed more LTE bands supported. What’s interesting about this is that Apple did the same thing with the iPad 3 as well, supported a number of LTE bands above and beyond what was simply given on the spec page. I’m willing to bet that’s both a function of Apple wanting to cover as many possible configurations with as few hardware models as possible, and partly because with the right set of filters and PAs it’s entirely possible thanks to the fact that Qualcomm’s transceivers have ports that are created equal. That doesn’t explain why we don’t have WCDMA on AWS on A1428 considering LTE support for band 4, but I’ll admit I don’t know every exacting detail there. Anyhow, I’m presenting the two tables I made for the previous piece with what bands each model covers.

It was touched on in the keynote, but the iPhone 5 likewise inherits the two-antenna cellular design that was touted from the 4S. This is the original mitigation for iPhone 4 “deathgrip” which was introduced somewhat quietly in the iPhone 4 (CDMA), and carried over to the 4S with one additional improvement – the phone included a double pole, double throw switch which allowed it to change which antenna was used for transmit as well to completely quash any remaining unwarranted attenuation. While receive diversity was a great extra for the 4S that drastically improved cellular performance at cell edges, in LTE 2-antenna receive diversity is now mandatory, leaving the base LTE antenna configuration a two-antenna setup (two Rx, one shared for Tx). Thankfully, Apple already had that antenna architecture worked out with the 4S, and carried it over to the iPhone 5.


The two iPhone models have slightly different antenna gains

Apple mentioned that it actually improved this even further, and after a lot of discussions with the right people and digging, I’ve learned that the iPhone 5 actually is a 3 Rx, 1 Tx design. There are two antennas, but three Rx paths required for when the iPhone 5 is in an LTE MIMO or combining diversity mode and also required to listen to the CDMA 1x paging channel for an incoming call. This is the interesting edge case that needed to be tackled in a design without two transmit chains for CDMA and LTE networks like Verizon and Sprint.

The other repercussion is of course no simultaneous voice and data for CDMA2000 and LTE networks that aren’t running VoLTE without that second transmit chain. VoLTE is absolutely the way of the future, and Verizon has repeatedly stated their 2013 target for VoLTE. The big question is whether or not the iPhone 5 will be updated at some point to support VoLTE even though at this point it doesn’t support it. The simplest way to state things is a bit of speculation — while it’s entirely possible to update the platform to do it, there is a fair amount of overhead required (another trip through the FCC, more carrier testing, and a reworked software stack), but MDM9x15 supports it. It definitely isn’t impossible, but at the same time it’s always unwise to buy a piece of hardware with the unmade promise of some future feature being added (both Apple and Verizon won’t comment on any VoLTE updates for the iPhone 5).

The part I didn’t address in my VoLTE piece was the 2.6 GHz and TD-SCDMA China situation. This is partly speculation but I still suspect we will see at least one more hardware model surface. Already we’ve seen rumors of an A1442 for China, and clearly TD-SCDMA support has to be in the cards at some point.

The second part of the situation is transceiver. MDM9x15’s recommended configuration from what I can tell is with WTR1605, the 28nm flagship transceiver replacement for 65nm RTR8600, which is what’s inside the iPhone 5 as it exists today. So much of Apple’s component choice is driven by sheer volume, and I suspect that both design cycle and availability concerns forced Apple to use RTR8600 instead of WTR1605 which is just now starting to show up in other MSM8960 and MDM9x15 based devices. The difference is in the number of “ports” (paired up and down) supported between these two. With RTR8600 that’s 5 total, 2 below 1 GHz, 3 above 1 GHz, for a total of 5. With WTR1605 that changes to both a different RF lithography (28nm) and also adds two more ports, 3 below 1 GHz, 3 above 1 GHz, and 1 very high frequency port around 2.5 or 2.6 GHz. To support 2.6 GHz LTE this would no doubt need to be included, and I suspect the phones we’re seeing advertising 2.6 GHz LTE support today include transceiver.

Implementation and Testing

At present the iPhone 5 gracefully does the hard handover from LTE to CDMA 1x for calls, and then quickly hands back up to LTE on the Verizon handset I tested. It happens extremely quickly and I’ve yet to see it glitch out or refuse to hand back up. In addition testing verifies that there’s no simultaneous voice and data for LTE or EVDO, as expected.


Verizon iPhone 5 showing no call and data

Outside of the errant LTE data use when connected to WiFi network glitch that was patched with the 13.1 carrier bundle, I haven’t seen any unexpected behavior on the Verizon iPhone 5.

On WCDMA/GSM and LTE carriers, the iPhone 5 implements circuit-switched fallback (CS-FB). Quite literally the phone hands down from 4G LTE to 3G WCDMA for the call (where voice and data are already multiplexed) and then back up to LTE when the call is over. In practice like all LTE handsets I’ve seen implementing CS-FB there can be a wait on the order of minutes before the handset hands back up from WCDMA to LTE depending on signal and the network. There’s nothing one can really do to expedite this process but toggle airplane mode or LTE in settings and hope for the best.

 

Thankfully Apple included an LTE toggle with iOS 6 on the iPhone 5, which I saw on both Verizon and AT&T. I managed to unlock my personal AT&T-provisioned iPhone 5 and see a 3G toggle with a T-Mobile SIM inserted as well and briefly tested the iPhone 5 with T-Mobile UMTS1900 in my market, which worked perfectly.

 

iOS 6 on iPhone 5 also includes the familiar FieldTest.app which can be accessed using the ever familiar dialer code (*3001#12345#*). Oddly enough FieldTest.app is clearly updated for the iPhone 5 but includes letterboxing. I’m overjoyed that Apple didn’t remove this like they did inexplicably with the iPhone 4. In addition to the same EVDO and UMTS engineering menus that I saw on the iPhone 4S, the iPhone 5 adds what is undeniably the best set of LTE field test informatics out there on any handset right now. Under appropriate menus are the LTE channel bandwidth, band number, RSRP, and RSRQ. RSRQ refers to the Reference Signal Received Quality (dB), and RSRP refers to Reference Signal Received Power (dBm). RSRQ ranges from –3 dB in excellent conditions to around –20 dB in poor conditions. Meanwhile RSRP will generally range from –75 dBm in excellent conditions to –120 in poor conditions. If you switch your signal indicator to numerics in FieldTest.app, that value which gets reported is RSRP, not RSSI on LTE.

Performance Testing

So the iPhone 5 includes what boils down to really the latest and greatest cellular connectivity possible at the moment, and naturally we wanted to put this to the test. To do that we turned to our usual set of tests, which consists of running lots of tests in various channel conditions using Ookla’s speedtest.net application, then batching up the data and making some pretty histograms from it. I had Anand test in his AT&T 5 MHz FDD LTE market and a few others during his travels, I tested in an AT&T 10 MHz FDD LTE market and my own AT&T market which is still just running WCDMA, and finally I borrowed a Verizon iPhone 5 and ran as many tests as I could.

Before we talk about all the results, let’s touch on the maximum achievable performance for LTE for a moment. LTE supports a variety of different channel bandwidths, and total throughput both up and down goes as a function of the total number of resource blocks available for coding data on top, which is a function of channel bandwidth. Stated another way, wider LTE channel bandwidth, more resource capacity. The limiting factor is how many resource blocks your modem can handle, and for the UE Category 3 MDM9615 that maximum translates to a maximum downlink throughput of 100 Mbps on 20 MHz channels. In the USA AT&T runs 10 MHz channels in some markets, and 5 MHz in others, for a maximum downstream throughput of 73 Mbps and 37 Mbps respectively. Verizon runs a solid 10 MHz everywhere, thus 73 Mbps down at maximum. I mentioned maximum achievable performance since these numbers include overhead already, I’ve seen some readers hitting close to these numbers already.


Note 20 MHz speeds are shown for Category 4 UEs

The iPhone 5 also supports DC-HSPA+ as I touched on earlier, although only T-Mobile is running it in the US, so there’s no way for us to test that at this point. AT&T has no plans to run DC-HSPA+ at all, and in my market only runs up to 16QAM HSDPA 14.4 Mbps down.




First off, Anand’s 5 MHz FDD LTE results get impressively close on the downstream to the maximum realizable throughput of 37 Mbps, at 32.77 Mbps. Upstream also comes pretty close to the maximum of 18 Mbps at 14.6 Mbps. In my 10 MHz testing in Phoenix I tried but couldn’t get as close as I would’ve liked to 73 Mbps, nevertheless an average of 18.41 Mbps is nothing to sneeze at. I’ve been very impressed with WCDMA throughput on the iPhone 5 as well, which regularly gets me results just above 12 Mbps on HSDPA 14.4 in my area, these are numbers I couldn’t see on the 4S even with my APN configured for the 4G Unlimited plan. Verizon LTE is also still speedy in my home market where I tested, though I would’ve enjoyed the opportunity to run even more data than the 66 tests I have for Verizon 4G LTE.

At present these speeds should just give an idea for LTE throughput and how much of a huge leap this is over the iPhone 4S. For CDMA subscribers on Verizon especially getting off of EVDO and onto LTE will be night and day levels of performance difference, and it’s really that changeover that will be the most dramatic.

Video: High Profile H.264 GNSS: GPS with GLONASS
POST A COMMENT

278 Comments

View All Comments

  • mykebrian - Thursday, October 18, 2012 - link

    is motorola razr i same price with iphone 5? Reply
  • Death666Angel - Thursday, October 18, 2012 - link

    "By controlling its own SoC destiny it could achieve a level of vertical integration that no OEM has enjoyed in recent history."
    I would argue that Samsung enjoys a similar level of vertical integration. They trade the OS-stuff for some fabs. Not sure which can be more profitable. But other than that, they are very much like Apple in terms of vertical smartphone integration I think. :)
    Reply
  • iwod - Thursday, October 18, 2012 - link

    Any Reason Why Front Camera not using High Profile When Recording Video? It could have saved yet another bit of space with MUCH better quality then baseline.

    And do Apple offically support play back of H.264 High Profile Video Clip yet?
    Reply
  • Spunjji - Friday, October 19, 2012 - link

    I very much appreciated the details on the SoC design. Your attempts to refine your battery life analysis were also appreciated, as these do seem to better reflect real-world usage. In general this article was well-researched, well-written and very informative.

    Unfortunately, the section on the anodization process does end up reading like one big apology. The matter is explained in detail but it's done with an air of resignation, as if this were the only option available to Apple. The fact is that they could have retained some additional girth (whilst still losing some) and had a device with good handling, good aesthetics and superior durability. No comparison to competing devices is made whatsoever, so we have no idea based on your article alone if this really is unavoidable or just poor choice of materials.

    The same goes for the part about the camera flare. Is a short comparison with a few relevant models too much to ask? The problem is that (like the previous criticism) I already know how this comes out and it doesn't look very good for Apple.

    So there are hundreds of hours spent testing comparative performance and battery life where Apple win, yet no time at all dedicated to comparative analysis where they do not look so good. That starts to look upsettingly like bias. I hope that isn't the case but based on other areas (notebook reviews in particular) it starts to feel like a theme.

    Anandtech, as a site I love your tech journalism, but the personal preferences of the writers need to stay at home (or firmly in editorials).
    Reply
  • Slaanesh - Friday, October 19, 2012 - link

    Couldn't agree more. Reply
  • Krysto - Friday, October 19, 2012 - link

    I have to agree. Through out the article, you almost got the impression of worship from the writers, and they've only focused on what Apple did right and how much better that was than their competitors.

    And what's with all the going back to history of Apple's devices? Was that really necessary for a phone review? Should we expect this for all new iPhones...or for all new Galaxy S devices? I think that part alone shows bias.

    And was 50 page review (or whatever it is) really necessary and to wait a month and a half after the product launch? The reason I'm asking is because I know they will never repeat this for any other non-Apple product. But I also think it's kind of pointless, and reviews need to appear max 1 week after the product launches. Maybe two. More than that is really pointless, and it's already obvious in the review that half of it is about how awesome Apple were in the past and still are, and only the other half goes down to the analysis.
    Reply
  • dyc4ha - Saturday, October 20, 2012 - link

    +1 Reply
  • Klugfan - Friday, October 19, 2012 - link

    Does everyone remember Edward Tufte's complaints about the iPhone 4 design?

    If I wasn't concerned about impact on the antenna performance, I'd be tempted to take some fine grit sandpaper to my black iPhone 5, and round off the edges a little. Believe it.

    If your biggest concern about phones _really_ is resale value, well the iPhone 5 will do fine, with or without scuffs. If your biggest concern about brain phones is what they look like to other people who see you using them, well, first you're an idiot, and second the iPhone 5 really will do fine there, with or without scuffs.

    Does my phone make me look smug? Whatever shall I do.
    Reply
  • Hxx - Friday, October 19, 2012 - link

    got this phone close to release day and I'm throughly impressed with it. Coming from a droid incredible 2 who crapped out on me 10 months after purchase (the memory slot broke and lost all my pics, videos etc - not fun) I gotta say this is my first interaction with an iOS powered device and so far i love it. I think most Apple products are overpriced (hence the reason why i never got one) but this phone is a beauty for $199 given that i paid almost just as much 1 year ago for my droid phone. A huge thank you to Anandtech for providing such detailed review. Although i may never need as much detail about a phone :-), its nice to know i can always rely on you guys if I ever have any technical questions.
    Good job Guys!
    Reply
  • ol1bit - Friday, October 19, 2012 - link

    As always, Anandtech gets into the details I didn't even know I wanted to read about!

    I'm not an apple product owner, and never plan to be, but it really appears to be a great phone.

    Keep up the good work!
    Reply

Log in

Don't have an account? Sign up now