Samsung Galaxy S III Review - AT&T and T-Mobile USA Variants
by Brian Klug on June 20, 2012 12:01 AM ESTI was sampled both the AT&T and T-Mobile SGS3s, so I can really only speak to those particular variants. However, all five of the USA SGS3s use MSM8960’s onboard cellular baseband for their respective cellular interfaces. I’m including the table from our original MSM8960 piece almost a year ago, since that shows the capabilities of the baseband - of course, whether or not your device supports all these things is a function of the rest of the RF chain, including transceiver and power amplifiers.
| Snapdragon S4 - MSM8960 Cellular Support | |||||
| LTE FDD | 100 Mbps DL / 50 Mbps UL (Cat. 3, 3GPP Rel.9) | ||||
| LTE TDD | 68 Mbps DL / 17 Mbps UL (Cat. 3, 3GPP Rel.9) | ||||
| UMTS | DC-HSPA+ 42 Mbps DL (Cat. 24) / 11 Mbps UL (Cat. 8) | ||||
| CDMA2000 | 1xAdvanced, EVDO Rev.B (14.7 Mbps DL / 5.4 Mbps UL) | ||||
| GSM | GSM/GPRS/EDGE | ||||
| TD-SCDMA | TD-SCDMA 4.2 Mbps DL / 2.2 Mbps UL | ||||
In the case of the AT&T SGS3, that’s LTE on bands 17 and 4 as shown in the table below. What’s unique about the AT&T LTE SGS3 is that it’s the first device in the USA I’ve seen with support for both 15 and 20 MHz FDD-LTE on Band 4 (AWS). That should tell you something about the product development cycle here, specifically that the AT&T SGS3 was conceived of back when AT&T was confident about getting T-Mobile’s AWS holdings. In addition, all of the cellular connectivity on the AT&T SGS3 sits on the same transmit path, with transmit at the bottom and receive diversity up at the top.
| SGS3 AT&T - Network Support | |||||
| GSM/EDGE Support | 850 / 900 / 1800 / 1900 MHz | ||||
| WCDMA Support | 850 / 1900 / 2100 MHz | ||||
| LTE Support | 700 / 1700 MHz (LTE Band 17, 4), Category 3 | ||||
| Baseband Hardware | Qualcomm MSM8960 | ||||
The T-Mobile SGS3 is unsurprisingly very similar to the AT&T SGS3, including support for both their own bands and AT&T’s bands for WCDMA as shown in the table below. The T-Mobile device of course supports WCDMA carrier aggregation, or DC-HSPA+. For those that aren’t familiar, DC-HSPA+ Category 24 (3GPP Rel.8) employes carrier aggregation in addition to the other HSPA+ features from Release 7. Essentially, two 5 MHz WCDMA carriers are aggregated together on the downlink, resulting in roughly double the performance of a single WCDMA carrier situation. Note that the uplink remains single carrier, so there’s even more of an asymmetry that happens, but given the traffic asymmetry that already exists for most mobile workloads this isn’t a huge deal.
Samsung's excellent ServiceMode (*#0011#) is present on all the USA SGS3 variants, DC-HSPA+ shown on T-Mobile SGS 3 (left), 10 MHz FDD-LTE shown on AT&T Model (right)
Like the HTC One S, the T-Mobile SGS3 can be used on AT&T’s 3G network if you can manage to unlock one. This is a definite plus if you don’t care about LTE but do care about having a phone with a ton of WCDMA bands supported.
| SGS3 T-Mobile - Network Support | |||||
| GSM/EDGE Support | 850 / 900 / 1800 / 1900 MHz | ||||
| WCDMA Support | 850 / 1700 / 1900 / 2100 MHz | ||||
| HSPA Speeds | HSDPA 42.2 (Cat.24) / HSUPA 5.76 (Cat.6) | ||||
| Baseband Hardware | Qualcomm MSM8960 | ||||
Because of my limited time with the SGS3s, I haven’t had a chance to run a bunch of speedtests on AT&T LTE and report back with plots. In addition, because AT&T does not support DC-HSPA+ yet (and shows no indication of doing so), there’s not much to be learned from 3G WCDMA there, as it’s still just HSDPA 14.4 in my market and almost all others. I’ve still never seen a single AT&T market with 64QAM / HSDPA 21.1. I will update with AT&T LTE results when I have them.
I have however run a bunch on the T-Mobile in my home market of Tucson, AZ and compiled enough to generate some plots. To test, I used the same workflow as always, essentially running as many tests as possible using Ookla’s speedtest.net application on Android, exporting the results, and making some pretty graphs with python. I’ve rewritten my graphing code and prettied it up a bit as well with some stats.
Unsurprisingly DC-HSPA+ is impressively fast on the downlink, with an average of around 11 Mbps and a maximum of just above 20 Mbps. It’s not the kind of performance you’ll get out of LTE (proving somewhat that using subcarriers through OFDMA and other enhancements does pay off), but it’s pretty darn impressive nonetheless. There’s a weird double distribution in latency probably due to setup time coming out of CELL_PCH and setting up the DC-HSPA+ link. Running a test right after this setup yields much lower latency thanks to T-Mobile’s flat IP network, which is why I say it seems to be connection setup related. I’m impressed with how fast T-Mobile’s DC-HSPA+ is in my area, and DC-HSPA+ isn’t a bad interim air interface until the carrier can deploy LTE. You have to applaud T-Mobile for being first to both deploy 64QAM on the downlink (HSDPA 21.1) and deploy DC-HSPA+, two things AT&T still has no intention of doing anytime soon.
I’m headed to an AT&T LTE enabled market as soon as possible to get some AT&T LTE results, but I don’t expect any surprises from that particular device.
WiFi
On the USA SGS3s, I was surprised to find that Samsung hasn’t gone with the on-SoC WLAN and instead implemented BCM4334, mirroring what was done in the international SGS3. BCM4334 we have talked about a lot before, it’s the 45nm version of BCM4330 with added support for 40 MHz channels on 5 GHz, among other lower power features and improvements. Of course, the SGS3s also include NFC (from the incredibly ubiquitous PN544) and BT 4.0 support (from BCM4334).
One of our readers pinged me and let me know that reliable iperf ports are now available on Android and iOS, so I’ll be switching over to using iperf for my main WiFi throughput testing instead of the 100 MB PDF hosted locally. What I’m looking at is still downstream throughput to the phone, since I wager that’s the direction people care most about. I tested a small number of the phones I’ve got on hand with iperf on the new Buffalo 802.11ac compatible router for comparison. For the purposes of the test I’ll be choosing the fastest WiFi interface possible for the device, eg 5 GHz when supported, 2.4 GHz when not supported.
The SGS3s show a PHY of 150 Mbps on 5 GHz with 40 MHz channels, and 65 Mbps on 2.4 GHz with 20 MHz channels. Performance isn’t quite up to the MSM8960 devices like the EVO 4G LTE and One X. I suspect this is due to either limitations on the interface between the SoC and BCM4334, or possibly absence of some other MAC features. Either way I’m glad to see 5 GHz support advancing even more now, to the point where devices are starting to show up with 40 MHz onboard as well.
GNSS
The SGS3 includes onboard GNSS (Global Navigation Satellite System) configuration. In this case, that means GPS with GLONASS. I have no problems getting a fast lock even indoors or in an urban environment, and like other combos with GLONASS you can see those satellites pop into use when GPS signal is weak.
I’m unclear whether the USA SGS3s have gone with Broadcom’s BCM47511 GNSS like what was done in the international SGS3, or whether Samsung is using the MSM8960 onboard GNSS. I need to do more digging to be certain. I suspect this is done on MSM8960, however.
Speakerphone and Sound
Because I’m in the process of moving, I don’t have my sound testing setup complete, nor the sound meter for testing speakerphone. However, I will be able to get that data in the coming week and update with my findings.
Both the AT&T and T-mobile SGS3s use an Audience A2220 for noise rejection using those two microphones (at top and bottom) as well. I need to do my testing here but based on a number of calls I’ve placed already from both I suspect they’ll perform quite well.
Facebook
Twitter
RSS
107 Comments
View All Comments
OCedHrt - Wednesday, June 20, 2012 - link
I wish we would get AWS on AT&T's S3 for WCDMA in addition to LTE.richworks - Wednesday, June 20, 2012 - link
Why isn't the International version of SGS3 not included in the benchmark tests? Am I to understand you haven't reviewed it yet?minhajmsd - Wednesday, June 20, 2012 - link
He did mention in the article that his unit hasn't arrived yet.richworks - Wednesday, June 20, 2012 - link
Ah.. thank you. I might have overlooked that part. I apologize for that :)antef - Wednesday, June 20, 2012 - link
Brian, you mention that by Samsung including a menu button that they don't have to include the full-row on-screen menu button that HTC does, but what you didn't mention is how this is still not ideal because it breaks Google's design goals for ICS completely. Google very plainly stated that the Menu key with its hidden functionalities (and sometimes no functionality) was not good design and encourages all developers to move away from it. Yet Samsung decides to include it on a new device built for ICS (probably because TouchWiz is carried over from Gingerbread).This means a few things. First, some app devs might not move to ICS design standards because they think they don't have to with new devices still coming out with Menu keys. Second, even if an app does use the new standards/action bar, the 3-dot overflow button will be HIDDEN because a Menu button is present. This is confusing and hides functionality that should be grouped with the other actions at the top. Finally, it necessitates a long-press of Home for task switching, which is slow and cumbersome compared to a dedicated button.
All around a bad decision on Samsung's part. The full-row menu key necessary for legacy apps on the One X is not ideal either, which is why on-screen buttons like on the Galaxy Nexus are the way to go.
Impulses - Wednesday, June 20, 2012 - link
I agree with you (and Google) on the menu button overall, it needs to go... I was never particularly bothered by it but it was a pretty sloppy design crutch and it confused new users of the platform... I agree that Samsung's implementation now only makes it worse by encouraging devs to continue using it and by messing with the way current ICS UI layouts are presented.I'm not sure I necessarily agree on screen buttons are better tho... IF you can make the device smaller by using them I'd say you have a case, but the Galaxy Nexus is no smaller than the One X so the latter ends up with more screen real estate the majority of the time (only sacrificing space to menu for legacy apps, which seems to be your main argument for on screen buttons).
I really hope Moto doesn't follow Samsung's lead, cause I believe LG has, and this is worse than the old game of musical chairs that manufacturers played with the four classic buttons. I think we've already had some leaks that showed them going with on screen buttons tho, fortunately.
It's gonna definitely gonna take longer than Google would like to deprecate menu...
hat being said, I've always liked Samsung's side power buttons (much easier to reach) so much do that I mod my HTC phones to wake on volume press... And I also kinda dig the physical home button (even tho it's ugly and another point of failure) because it makes it much easier to wake the phone while it's laying flat.
Most of that is subjective tho, Google moving away from menu is not... Not only was it a design crutch, multi tasking feels so much quicker without long press. I know realistically it's not that much slower to long press home, but subjectively it feels slow. I think Duartesaid in an interview that was one of the reasons they were moving away from long presses and towards the use of more swipes etc.
antef - Wednesday, June 20, 2012 - link
I definitely agree with you about Menu being a design crutch and long-pressing Home feeling slow. People might think Menu is no big deal, but they have to consider the broader audience. Why do people think an iPhone is so much easier to use for most people - because everything is right there and easy to explain. Try explaining Menu and long-press to a new user: "You press this button to show more actions - sometimes it will show things, sometimes it won't, you just have to press it and see. And there's no indication of whether an app uses it or not, you just have to remember it's there. And then you press and hold this to switch apps...no, you didn't press it long enough, try again." versus "Press this button to switch apps. Here at the top of the screen are icons for things you can do. If you there are more things you can do you can access them by pressing the 3-dot button right next to it." It's a night and day difference, and like you said this will stall Google's efforts to deprecate it, now a whole new generation of Android users will get accustomed to a Menu key on the SGS III.You are correct that the Galaxy Nexus loses some screen real estate with the on-screen buttons, but I don't see that being much of an issue when you have a 1280x720 resolution screen. The thing is, with 3 physical buttons, you are going to have one of these problems either way, and the on-screen button eliminates that. In addition I think the on-screen buttons are just preferable anyway. They are bold, easy to see, give you feedback when you press them, and appear coherently part of the UI. It looks like a complete package. Versus the off-screen, backlight-lit keys, which appear "separate" from the UI and are typically smaller. I never realized this from pictures, but after actually using a Galaxy Nexus, I much prefer the look and feel of the on-screen buttons.
Definitely also like the side power button, it's practically necessary for large devices like these.
themossie - Wednesday, June 20, 2012 - link
Yes, it does ignore Google's design goals. It also makes most applications far more usable. Why are contextual menus bad? (I understand the inconsistency problem where the menu button on ICS will not pop up on screen depending on the phone, but still...)Seems like many phone manufacturers agree with me here.
Since I'm complaining anyway... :-)
Does anyone else find ICS task switching far less useful than 2.x's "Recent Apps"? With "Recent Apps", I never had to scroll to find the app I wanted - and never had to worry about closing applications to keep the Task Switcher bar reasonably short.
(For reference, I have a Gingerbread phone and a ICS tablet)
Impulses - Wednesday, June 20, 2012 - link
Contextual menus aren't bad per se, forcing people to guess when they exist at all is. Very few applications are better off with a hidden menu than ICS' action bar + overflow menu plainly visible on screen. Many manufacturers = 2 out 5 or so major Android OEMs? Sony, HTC, and Motor have conformed to the new button scheme.Not sure why you're complaining about scrolling on ICS, are you using a 7" tablet? On my 10" the recent app menu shows 9 apps in portrait and 5 in landscape. Previous versions of Android showed either 6 or 8 icons depending on manufafturer, and had no preview of the app.
You couldn't kick apps out of the recent apps pop up either... ICS multi tasking seems like an improvement in every possible way except maybe landscape use or smaller lower res phones, and even then tap + swipe + tap is no slower than long press + tap.
themossie - Wednesday, June 20, 2012 - link
Re: Contextual menus - I do agree that it's bad to force people to guess when they exist. (That wasn't a problem before ICS, when you could safely assume a program has one!) I don't find the ICS icon to be a useful contextual clue to new users - 3 dots does not a menu suggest.Now, for scrolling: (forgive the rant)
That said, from memory:
* CM9 on HP Touchpad (1024x768) - shows 1 app in landscape.
* ICS on Galaxy Nexus - shows only 3 apps in portrait. (images.google "task switcher galaxy nexus")
* ICS on HTC Evo 4G - shows only 1 app in landscape. This may be a Sense issue, experienced other landscape issues.
You have to scroll to do anything!
Compare this with Gingerbread on my Droid 2 (the not-Motoblur), where "Recent Apps" shows 18 apps. With 18 apps in Recent Apps, I no longer need the homescreen to load applications.
I'd still find the stock "Recent Apps" (I believe it's 8 in Froyo, 10 in Gingerbread?) more usable than ICS.