Cellular, Wi-Fi, GNSS

Let’s talk about cellular on the Nexus 4, which is for many people the main point of contention with the device. Google didn’t do itself any favors by initially posting incorrect specs for cellular compatibility, when in fact the Nexus 4 was capable of much more. Initially, that spec table showed inclusion of only HSDPA 21.1 (single-carrier WCDMA with 64 QAM), when in fact the Nexus 4 supports pentaband WCDMA up to HSDPA 42.2 (dual-carrier WCDMA with 64 QAM) courtesy of MDM9215. Of course, what gets left out is LTE support, and the reality of that choice is a device completely detached from carrier involvement. The realities of engineering hardware to support both LTE Bands 17 and 13 (for both AT&T and Verizon in the USA, respectively) basically necessitate at least two SKUs, and I have a feeling that Google just wasn’t ready to make that commitment. Band 4 (AWS) could essentially be supported with the power amplifiers and transceiver that already are onboard the Nexus 4, but again it ultimately comes down to a particular OEM choice whether these get supported. The rest of the LTE band support situation is similarly complicated, to say nothing of the political involvement required to support LTE and whatever CSFB (circuit switched fallback) or legacy hard handover is required for each carrier at present. I have a feeling that Google wanted to get the Nexus 4 out the door quickly and without making a million and one models it would have to build images and OTA delta updates for, and the result is a pentaband WCDMA phone with DC-HSPA+ support.

When I heard that LG would be making the next Nexus, I also heard that it would be WCDMA only. Honestly I thought it was obvious that those two go hand in hand to minimize carrier involvement in Google’s purest form of Android. The original goal of Nexus was to change the way that users shop for handsets, primarily in the USA. The goals were lofty at that time and the reality was that Google didn’t yet have the necessary infrastructure (like the Play Store) to do it, nor was hardware at the level required to deliver a single-SKU solution for all the UMTS bands out there. Galaxy Nexus was the first pentaband Nexus, thus it only makes sense for the follow up to likewise be pentaband WCDMA.

Internationally, DC-HSPA+ has widespread support, the reality is that in the USA AT&T’s lack of support for DC-HSPA+ is more of an aberration than the norm for UMTS networks across the globe. Not having LTE support would be much easier to stomach for AT&T subscribers if the carrier enabled DC-HSPA+. T-Mobile has always been something of a silent (or not so silent) target for Google’s Nexus phones, with the G1, Nexus One, and Nexus S all coming in AWS-flavors before 850/1900 (Cellular/PCS) flavors for AT&T, and T-Mobile has had DC-HSPA+ rolled out to nearly all of its WCDMA footprint for months now.

In reality, the cellular and RF architecture of the Nexus 4 is a dramatic improvement over the Galaxy Nexus, which was based on the still-ubiquitous Intel XMM6260 65nm baseband and lacked receive diversity or interference cancelation in its implementation. I was never really fully satisfied with RF performance on the Galaxy Nexus, and although I carried it as my daily driver for months, I could never shake that thought at the back of my head that I could definitely be achieving higher throughput with almost any of my other handsets even on AT&T (up to HSDPA 14.4, single carrier 16 QAM).

Google Nexus 4 - Network Support
GSM/EDGE Support 850 / 900 / 1800 / 1900 MHz
WCDMA Support 850 / 900 / 1700 / 1900 / 2100 MHz
Baseband Hardware Qualcomm MDM9215M + WTR1605L
UE Categories HSDPA Category 24 (43.2 Mbps), HSUPA Category 6 (5.76 Mbps)

Anyhow, the Nexus 4 is a dramatic improvement. It includes the latest and greatest 28nm Qualcomm baseband (MDM9215M), their flagship transciever (WTR1605L) and includes full receive diversity on all WCDMA bands.

Anritsu recently loaned me an MD8475A signaling tester base station emulator for testing devices, and I decided to go and check out the maximum theoretical performance difference between the Galaxy Nexus and Nexus 4 just for illustrative purposes. In this test I corded up the Galaxy Nexus (since it has external antenna ports) and placed the Nexus 4 on top of an antenna, and setup a simulation running an HSPA+ 3GPP Release 8 network running on UMTS Band 4 (AWS). I tested using UDP over iperf on this simulated network. There were additional cabling losses due to me not being able to cable up the Nexus 4 so I adjusted Tx power appropriately.


Galaxy Nexus - HSDPA 21.1

 


Nexus 4 - HSDPA 42.2 (Dual Carrier)

Corded up, the Galaxy Nexus can eek out just over 19 Mbps on 64QAM single carrier WCDMA which is the maximum that hardware supports. Moving to dual carrier on the Nexus 4 buys the device unsurprisingly roughly double the throughput at just shy of 40 Mbps. This is of course in basically an ideal signal environment for both devices.

In real world performance testing I turned to speedtest.net and running a bunch of tests, then making a few histograms of the resulting data. I’m still a big fan of the fact that T-Mobile has always been first to these upgrades to WCDMA, first with 64QAM, then with dual carrier (DC-HSPA+).

Downstream

Stats Download Throughput (Mbps) Avg: 11.28, Max: 23.43, Min: 0.01, StDev: 6.98

Upstream

Stats Upload Throughput (Mbps) Avg: 1.52, Max: 2.99, Min: 0.05, StDev: 0.48

Latency

Stats Latency (ms) Avg: 627.98, Max: 1577.00, Min: 117.00, StDev: 553.65

The speeds I see out of the Nexus 4 on T-Mobile are on par with my expectations for that network. The maximum downstream throughput we see at just shy of 24 Mbps is essentially the result of the maximum bitrate with two 16QAM WCDMA carriers aggregated together. Again getting to 64QAM on the downlink can be quite difficult, I’ve seen breakdowns where 64QAM only gets used sub 10% of the time in the real world for WCDMA. At cell edge the improvement that receive diversity brings should be dramatic for users upgrading from Galaxy Nexus to Nexus 4.

GNSS

GNSS (Global Navigation Satellite System) is supplied courtesy MDM9215 on the Nexus 4, which offers GPS and GLONASS support. I’ve talked at length about this in other reviews, and like other implementations based around Qualcomm’s GNSS, the Nexus 4 locks very fast even indoors. There’s really nothing more to add about GNSS on the Nexus 4 except to note that it performs very well just like other MDM9x15 based devices I’ve played with.

There’s an Avago 3012 GNSS front end with LNA and filters for GPS and GLONASS on the Nexus 4 PCB that I was able to identify as well right near the GNSS antenna feed.

Wi-Fi

The Nexus 4 includes dual band (2.4 and 5 GHz) Wi-Fi support, which as far as I can tell is supplied by the Qualcomm “WCNSS” solution leveraging the digital baseband onboard APQ8064 and some external RF. I have no doubt the actual package is hidden under the last remaining EMI can I couldn’t remove on the Nexus 4 PCB right near the Wi-Fi antenna feed.

I noted that there’s an optimization toggle under Advanced for the Nexus 4 which changes some things around. There still is a band preference toggle as well. I tested the Nexus 4 the same way I always do with iperf on my myriad 802.11n networks and made some graphs.

WiFi Performance - iPerf

What’s curious to me is that the 5 GHz support for Nexus 4 doesn’t include 40 MHz support, instead the Nexus 4 attaches at 72 Mbps (the 20 MHz, short guard interval rate) on both 2.4 and 5 GHz. Likewise we see similar throughput on both bands. I have no complaints about range, the Nexus 4 is on par with my expectations.

Inside the Nexus 4 Speakerphone, Noise Rejection, Audio
POST A COMMENT

188 Comments

View All Comments

  • zeroidea - Wednesday, November 14, 2012 - link

    It's Tucson, AZ!

    They must have been taken a few weeks ago (a lot of the streetcar construction downtown has been completed)
    Reply
  • DukeN - Tuesday, November 13, 2012 - link

    Brian, are you able to verify if the material is actually rubber? This would be a serious issue for many users, including some in my family with severe latex allergies. Reply
  • PeteH - Tuesday, November 13, 2012 - link

    Wow, that didn't even occur to me, but it could be a real problem. It's not like latex is an uncommon allergy either, so hopefully Google or LG thought about that and used something other than rubber. Reply
  • Rits - Tuesday, November 13, 2012 - link

    Its rubberised plastic. Shouldn't be a problem at all to latex-allergic folks. Reply
  • PeteH - Tuesday, November 13, 2012 - link

    Not doubting you, but do you have a source? Reply
  • Rits - Tuesday, November 13, 2012 - link

    Previous LG devices that had the same material were latex-free. There is no reason this one would deviate. But, you could always email LG/Google for an official confirmation. Reply
  • MadMan007 - Tuesday, November 13, 2012 - link

    Should have used a dual core CPU with a decent GPU. Quad core is a waste in phones because overall it hurts battery life more than it helps certain usage models, and if there's so much throttling what's the point.

    Does Android do thread parking? Do these CPUs have per-core power gating?
    Reply
  • JohnnyL53 - Tuesday, November 13, 2012 - link

    Throttling may not be an issue in the real world in terms of a noticeable affect and may just show up in benchmarks. In other words, who cares what the benchmark performance is if its at such a high level it's not perceptible? What I never see explained is how far apart do you need to get before you can distinguish one device's performance from another. Granted on most of the tests the iPhone far outpaces any other phone, but is it even noticeable? Are we just talking bragging rights, future proofing, etc? Reply
  • name99 - Tuesday, November 13, 2012 - link

    The value of a faster CPU on a phone, for normal people, right now, is that the phone feels snappier. So, for example, an iPhone5 feels perceptibly faster than an iPhone 4S not because computational tasks take 1 minute instead of 2 minutes, but because a dozen small things take .1 second instead of .2 seconds.

    From this point of view
    (a) thermal throttling is no big deal, and I personally have no problem with it. It was a good idea when Intel started it years ago (to the accompaniment of a massive chorus of whining) and it would be a fine idea to have it as built into an ever wider selection of phone chips.

    (b) quad-core remains a solution in search of a problem. Maybe one day it will have value; maybe it has value for games (which I don't care about). But for the way I and my crowd use phones, it has no value yet.

    (c) the present collection of benchmarks are largely useless because they do NOT track this essence of snappiness which is what most people mean when they say a phone is "fast". Yes, if you're a developer writing demanding code you care about very particular aspects of the phone --- perhaps you care about the memory bandwidth, or the FLOPs, or the random flash write performance. But for most people, what matters is the snappiness. Existing benchmarks are a poor proxy for that feeling, and I do wish the serious blogs could do better.

    Right now all we have is this lame sniping like 12 yr olds: "My Nokia feels fast", "Oh yeah, well my Samsung feels even faster", "Well my iPhone feels fastest of all". And regardless of your feelings about Apple, if you support Team Android or Team Windows, you should be pushing for snappiness benchmarks because that is one of Apple's great strengths --- they don't care about, and don't optimize for benchmark numbers, they optimize for snappiness, and buyers do appear to be aware of and notice this. As long as the non-Apple market is forced to compete on these "overt" benchmarks as ways for each vendor to differentiate themselves and show their technical superiority, what will be optimized for are benchmark numbers, NOT user feel and snappiness.
    Reply
  • Zink - Tuesday, November 13, 2012 - link

    I think with a DSLR at 60 FPS and editing to synchronize individually recorded videos it would be possible to do accurate side by side comparison of app responsiveness and web page loads. With a bit of video analysis, graphs could be made comparing performance down to the frame and FPS in animations measured.

    You could even do this on the go for a real world performance comparison. A normal day of use could be simulated by walking/commuting around your city and setting up a tripod in an apartment, on the sidewalk, inside an office building, at the bar etc. Then run several tests on each phone where you get the phone out of your pocket like normal and open a web page, post a comment, take a photo etc. all while the screen is on camera. Several similar tasks could be averaged into a single category score for a bit better repeatability.

    With proper analysis of the resulting video a pretty damn accurate comparison of the whole cellular, hardware and software system could be made. Basically the ultimate benchmark measuring user phone performance. I've seen some well done side by side comparisons but never in depth or with good numbers along with the video.
    Reply

Log in

Don't have an account? Sign up now