Posts tagged 3G

AT&T 4G LTE in Tucson, AZ – Coming Before End of 2012

It has been what seems like an eternity since I wrote a bit about Verizon 4G LTE coming to Tucson, AZ. Since then, the network has been deployed and working just fine, and made it into my mental take-it-for-granted state. Since then, Cricket has lit up their own LTE network on AWS (1700/2100 MHz), and next up is AT&T who just recently announced details about their LTE deployment for a bunch of markets before the end of this calendar year. I wrote about the AT&T LTE news at a high level at AnandTech, and the announcement comes a not-so-coincidentally timed week before the next iPhone announcement in an attempt to prevent lots and lots of LTE related churn.

I’m burying the lead a bit, but before the end of 2012 AT&T will have LTE finally lit up in my part of the world. There’s a relevant press release here which is relatively light on detail – there’s no outline for what parts of town will get LTE, whether it will include surrounding areas, or any further detail. I guess we can only hope that they mean the greater metro area. I’ve asked a few of my sources for a better timeline, but can only say that before December LTE should be lit up.

I hope it goes without saying, but LTE (3GPP Long Term Evolution) is completely different from the earlier announcements AT&T made about “4G” coming to Tucson in May 2011. That was really just deployment of HSPA+ with up to 16QAM on the downlink (HSDPA 14.4) and some additional WCDMA carriers for capacity reasons. I’m pretty pleased with the state of AT&T WCDMA in town, I see around 2-3 carriers on PCS (1900 MHz) around town and what I consider very good peak speeds.

AT&T Spectrum Holdings in Pima County (As of Sept. 7 2012)

Since AT&T LTE doesn’t use the same channel bandwidth everywhere, it’s worth noting that in this particular market (Pima County), AT&T can run 10 MHz FDD-LTE on Band 17, (Lower 700 MHz B+C blocks) and 5 MHz FDD-LTE on AWS (1700/2100) when the time arises. I haven’t seen AT&T enable any LTE on AWS quite yet, this is likely coming at some future date after the rollout is closer to completion or as a way to mitigate loading in the future.

AT&T Bands in Las Vegas – 850 GSM/EDGE, 1900 UMTS/3G

Last time I was in Las Vegas it was for MIX 10 and Windows Phone 7 (back when it included ‘series’ at the end). This time, the reason is CES 2011 with AnandTech and a whole bunch more mobile devices.

I thought it was interesting last time I came that most casino floors in Las Vegas had shockingly poor or non-existant UMTS (3G) coverage on AT&T. I guess I didn’t find it too shocking, since coverage inside buildings in a dense urban environment is probably the most challenging for mobile networks, but it seemed to be a consistent problem. After getting frustrated about 6 hours into my stay, I decided to switch entirely to EDGE for the duration just because of how annoying being constantly handed between GSM/EDGE and UMTS is when you’re trying to do things. For whatever reason, back then I didn’t think to pull up field test on the iPhone 3GS I was currently carrying to see what bands were assigned to which network technology.

Now that I’m back, I decided to check. Thankfully, Apple has restored most if not all of the Field Test data products in iOS 4.2.1, a huge step forward from 4.1 just allowing signal strength in dBm at top left, and a far cry from 4.0 which shipped with no field test whatsoever. To save potential readers some googling, to get here, enter *3001#12345#* from the dialer and hit call – if it hasn’t been removed yet, you’ll get dumped into Field Test on iOS.

In EDGE and tapping on GSM RR Info, it’s immediately obvious why I saw that behavior last time I was here:

ARFCN dictates what channel inside what band we’re on, and 142 just happens to lie inside the GSM 850 band. It’s a number basically used to refer to the FDD pair of frequencies the phone is currently using. You can calculate exactly what frequency downlink and uplink are on with a little math and some reference guide (there’s a good table here), but basically with an ARFCN of 142 we know immediately that GSM/EDGE is on AT&T’s 850 MHz spectrum. Between 128 and 251 is that GSM850 spectrum.

Now, what about UMTS/3G? Enabling 3G (look at how weak that signal is…) and going into UMTS RR info, I saw the following:

Looking at the fields “Downlink Frequency” and “Uplink Frequency” we can see the device’s UARFCN channel numbers. It’s the same thing, but U for UMTS. Again, with a reference aide (read: wikipedia) we can see that UMTS/3G is working in the PCS 1900 MHz band.

Remember that higher frequencies are less effective at propagating through buildings. It’s pretty obvious now why getting good 3G coverage on AT&T is a challenge deep inside a casino in Las Vegas. There’s nothing inherently wrong with putting GSM/EDGE on 850 and UMTS on 1900, it’s just interesting in practice how immediately obvious the difference is walking around. Propagation is a challenge in dense urban environments with lots of people moving around to begin with, I’m sure this doesn’t help in Las Vegas. AT&T promised to put all of its 3G (UMTS) network on the 850 MHz band (wherever it’s licensed to use it) by the end of 2010, but sadly that hasn’t happened quite yet, at least in this market. I’ll keep checking, but thus far it’s been solidly in 1900 PCS. Oh well.

AT&T 3G MicroCell Review

In case you missed it early, early this morning, my AT&T 3G MicroCell review is up and live at AnandTech here.

I played around with the product all last week and finally think I know all there is to be gleaned about it - undoubtedly in time the handover performance (which is pretty abysmal) will improve. It’s something that I talk about a lot in the article itself, but exists across all the major femtocells, and T-Mobile’s implementation of UMA. From a technical standpoint, the problem seems to be that the phone almost treats the femtocell like a roaming tower – implicitly disabling soft handovers to the public network. It’s handled this way most likely for a billing segmentation reason, but that’s unclear.

I learned in the comments that there are enterprise picocells, although I’m not sure what kind of carrier interaction is required for installation. I’d really like to investigate those for something future. Whatever the case, if you’re interested definitely give it a read!

AT&T 3G in Las Vegas

While I was in Las Vegas for MIX10, I couldn’t suppress my inexplicable urge to run as many speedtests as I could muster. Of course, I was packing the usual iPhone 3GS with AT&T. Sadly, nearly the entire visit speeds were barely 250 kilobits/s down, 220 kilobits/s up, if I could even get the application to run. Take a look at the following:

(kilobits/s) Average Min Max
Downstream 251.8 14.0 552.0
Upstream 220.8 0.0 357.0

This data is from 13 tests taken during my 3 day stay. They’re from over 3G UMTS when it did work, and GSM EDGE when it didn’t, and that was virtually the entire time. 3G was either slow, or didn’t work at all; switching to EDGE was the only way to do anything.

How is this possible?

Now, it’s fair to say that some of this is sampling bias and the fact that I was at a conference, but even then, there’s no excuse. This is a city used to a huge flux of visitors in a short time for trade conferences. Frankly, I can only begin to imagine how overloaded networks are during major conferences like E3.

Take a look at the following plot of the average speeds for each day:

Average Downstream Speed

Can you spot which three days are the ones I’m talking about? Note that on the 16th, I couldn’t even get a test to run to completion; it just didn’t work. There’s nothing more to really say about the issue than simply how bad this is. If this is the kind of performance AT&T users see and complain so vocally about in the San Fransisco Bay Area and Manhattan, I can completely understand. Frankly, I can see no other reason for that kind of performance degradation other than congestion.

Stories from MIX10 – Impressions

Over spring break I spent an amazing – and busy – three days in Las Vegas at Microsoft’s MIX10. I got to see a complete platform reboot with Windows Phone 7 Series, some interesting news about IE 9, and most importantly got to meet  some awesome people.

MIX10 Keynote Stage

I’ve been writing a lot over that time with AnandTech, which I’ll wrap up here:

  • First day MIX10 Windows Phone 7 Series Impressions – link
  • Internet Explorer 9 Platform Preview – link
  • Windows Phone 7 Series: The AnandTech Guide – link
    • If you had to read any one of these, this would be the one to be. It’s over 8000 words and comprehensively wraps up the platform in my opinion.

AnandTech - Bing search hands on

There were a couple hilarious quotes that I overheard at the conference, which I think I’ll just share briefly. Keep in mind this is at a development conference.

  1. “…and we call this checkbox driven development. We can do everything we want just with checkboxes”
  2. “…and we only had to write one line of code! Just one line, and we’re done!”
  3. But my favorite: “Can I use the back button for fire? What if I really really want to use the back button?” – immediately after a presentation about how the back button is reserved for going back.

AT&T Observations and Bandwidth

Bandwidth and Latency Data

I’ve always kind of been obsessed with bandwidth. I find myself constantly testing latency, bandwidth, and connection quality (mostly, in fact, through smokeping). Needless to say, that same obsession applies to my mobile habit, and especially given the often-congested perception of AT&T.

It sounds weird, but the two most-run applications on my iPhone are Speed Test and Xtreme Labs SpeedTest. The Xtreme labs test used to be my favorite, largely because of its superior accuracy and stability. As great as’s website is for testing, the iPhone app continually fell short. Tests ended before throughput stabilized, often the test would start, then the data would start being calculated a second later (skewing the average), or it’d just crash entirely. I could go on and on about the myriad problems I saw which no doubt contributed negatively to perception of network performance.

A few months ago, I wrote a big review and threw it up on the App Store. In the review, I noted that being able to export data would be an amazing feature. At the time, I had emailed Xtreme Labs and asked whether I could get a sample of my speed test results for analysis (I have yet to hear back). On Feb. 2nd, Ookla finally got around to releasing an update to the app; it included the ability to export data as CSV.

Since then, I’ve been using it exclusively. I’ve gathered a bit of data, and thought it relevant to finally go over some of it. This is all from my iPhone 3GS in the Tucson, AZ market, largely in the central area. I’ve gathered a relatively modest 76 data points. Stats follow:

Gathered Statistics

Downstream (kbps)
Upstream (kbps)
Latency (ms)
Average 1880.3 263.3 1029.2
St. Dev. 1179.6 101.6 1140.2
Max 4279.0 356.0 6011.0
Min 82.0 18.0 366.0

These stats really mirror my perceptions. Speeds on UMTS/HSPA vary from extremely fast (over 4.2 megabits/s!) to as slow as 82 kilobits/s, but generally hang out around 1.2 megabits/s. On the whole, this is much faster than the average 600 kilobits/s I used to see when I was on Sprint across 3 different HTC phones.

Next, I became curious whether there was any correlation between time of day and down/up speeds. Given the sensitivity of cellular data networks to user congestion (through cell breathing, strain on backhaul, and of course the air link itself), I expected to see a strong correlation. I decided to plot my data per hour, and got the following:

Downstream and Upstream Bandwidth

Some interesting trends appear…

  1. I apparently sample at roughly the same time each day (given the large vertical lines that are evident if you squint hard enough). Makes sense because I habitually test after class, while walking to the next.
  2. There is a relatively large variation per day for those regular samples, sometimes upwards of a megabit.
  3. There does appear to be a rough correlation between time of day and bandwidth, but the fact that I’m moving around from cell to cell during the day makes it difficult to gauge.
  4. Upstream bandwidth is extremely regular, and relatively fast at that.

I’m still mentally processing what to make of the whole dataset. Obviously, I’m going to continue testing and gathering more data, and hopefully more trends will emerge. You can grab the data here in excel form. I’ve redacted my latitude and longitude, just because my daily trends would be pretty easily extracted from those points, and that’s just creepy.

3G Bands – Where is the 850?

Lately I’ve been getting an interesting number of hits regarding the 850/1900 MHz coverage of AT&T here in Tucson.

To be honest, I’ve read a number of different things; everything from certainty that our market has migrated HSPA (3G) to 850 MHz, to that AT&T doesn’t even have a license for that band in Arizona. For those of you that don’t know, migrating 3G to the 850 MHz bands is favorable because lower frequencies propagate better through walls and buildings compared to the 1900 MHz bands. In general, there’s an industry wide trend to move 3G to lower frequencies for just that reason.

I’ve been personally interested in this myself for some time, and finally decided to take the time to look it up.

Maps, maps, maps…

The data I’ve found is conflicting. shows the following on this page:

AT&T 1900 MHz

AT&T 850 MHz

Note that the entire state of Arizona doesn’t have 850 MHz coverage/licensing.

However, the GSM authority over at GSM World shows three very different maps:

HSPA 3G Coverage (yellow)

AT&T 850 MHz coverage

AT&T 1900 MHz coverage

Note that the 3G data coverage map is labeled ambiguously; HSPA coverage exists, but it could be on either 1900 or 850. However, what we do glean is that (at least according to GSM world) there is equal 850 and 1900 MHz coverage in Tucson and the surrounding area. This contradicts the earlier map.

Then you have maps like these, which are relatively difficult to decipher but supposedly show regions of 800-band coverage from Cingular and AT&T before the merger:

Cingular 800, AT&T 850

Finally, you have websites such as these that claim Arizona is only 1900 MHz.

So what’s the reality? Uncertain at this point.

The map given by is sourced from 2008, whereas the GSM world maps are undated, and ostensibly current. The other maps are also undated, but the majority consensus is that AT&T isn’t licensed to use 800 MHz in this market.

If anyone knows about some better resources or information, I’d love to see it.

Update – 3/24/2010

I finally spoke with someone at AT&T, and it turns out that my initial suspicions were correct – Arizona does not have the 850 MHz UMTS Band 5. It’s as simple as that.

Oh well, at least we know now!

Google’s Nexus One – Thoughts

Today, Google finally announced the much-hyped, finally-official googlephone at their Mountain View office. Admittedly, there wasn’t much about the actual announcement that wasn’t previously known; specs, photos, and even an entire review had already leaked out before the official announcement. But the announcement marks google’s first real step into distributing google-branded hardware directly to consumers, the entry of another google-blessed flagship for the Android platform, and a different, long-needed business model for selling phones and wireless contracts.

It’s been a year, 2 months, and 14 days since the launch of the T-Mobile G1, and Android has matured into a serious contender since its beginnings as an aspiring platform in a market dominated by Windows Mobile, Symbian, and the iPhone OS. While the G1 seemed awkward in a kind of adolescent manner, it’s chin a strange design ‘feature,’ its storage ultimately limited, and design-by-committee UI/navigation (anyone remember “how many clocks does it take for google engineers to tell time?”)  the Nexus One is finally enough to make it a real iPhone contender alongside the Droid.

That said, the platform does still suffer from a number of notable shortcomings:

  • Application storage limited to 512 MB partition
    • (Which google says it will fix by allowing applications to reside on an encrypted partition on removable storage, soon)
  • No multitouch within official applications
    • (This strange choice likely stems from legal and patent concerns between Google using Apple IP/prior artwork. Google likely doesn’t want the whole board-member-sharing fiasco to undergo any more scrutiny than it already has)
  • Slower web browsing
    • (Flash? more on that in a second)
  • No support for CDMA (Verizon) until spring, AT&T 3G band support unclear
    • (Rumors abound that Google is working on an AT&T version, but only a “dozen or so employees have access to this hardware”)

I’m going to expand on numbers 2 and 3, since personally I find these the most interesting immediately.

Mobile Flash

Engadget did a rather thorough of the Nexus One, pre-empting it’s announcement (karma for the same way Google tried to pre-empt CES?), and notably included a quick and dirty comparison of the loading speed of browsers on the iPhone 3GS, Nexus One, and Droid. Qualitatively, the winners and losers are painfully obvious from the video, but I took down some times and came up with the following:

  1. iPhone 3GS – 17 seconds
  2. Nexus One – 71 seconds
  3. Motorola Droid – 82 seconds

What immediately sticks out is that it took both of the Android 2.x platforms roughly 4 times longer to load the same website as it did the 3GS.

Initially, this doesn’t make sense. The 3GS is sporting a relatively recent ARM Cortex A8 underclocked from 800 MHz to 600 MHz, while the Nexus One is running the latest (also much-hyped) Qualcomm Snapdragon SoC running at 1GHz (Qualcomm QSD 8250 according to Google). The Snapdragon SoC is extremely similar architecturally to the Cortex A8, so comparing clock speeds is roughly applicable. Then, why the heck is a newer, faster generation chipset clocked 66% faster 4 times slower? Heck, the Android browser even runs lean and mean WebKit at its core, same as Mobile Safari on the iPhone, and Chrome and Safari on the desktop. Why then is it so much slower?

My theory? Flash.

The same multimedia platform hogging resources on the desktop is now hogging resources and slowing down browsing on mobile devices. Excellent. Sure, there’s a lot of content out there that’s driven by Flash that’s useful: videos, games, navigation, photo websites, fancy UI. But what’s the biggest reason? Advertising. Adobe knows it, I mean, just watch their video on mobile flash and notice what they highlight. Advertising.

Up until now, browsing just about everything on all the modern smartphone browsers I’ve used (mobile safari, opera mobile, opera mini, IE mobile) has been usable without adblock primarily because they didn’t have support for flash. Unless mobile browsers begin allowing plugins such as adblock or similar (similar to how mobile firefox, aka Fennec has begun doing), Flash is something I’d rather see disabled than enabled. How much of a feature is it to waste not just performance, but ever-critical battery on a mobile device primarily to show animated and intrusive advertising?

No AT&T 3G, Just T-Mobile

A lot of what Google was really trying to do with the Open Handset Alliance, launching a phone that customers can buy almost directly from HTC (the Nexus One OEM) and introducing essentially a new mobile business model at the same time was abstracting the carrier away from the device.

That is, handsets are increasingly moving towards being carrier-agnostic. In reality, this is the way it was intended to be (and moreover, should have been, at least in GSM-land). In fact, while this business model is entirely new to the US, the portability of handsets using SIMs is nothing new to customers in Europe, who frequently purchase handsets unlocked and bring plans (and SIMs) with them. (As an aside, much of the reason CDMA became dominant in the US was because this same flexibility wasn’t part of the specification; the unique identifier is built into the phone itself in the form of an ESN/MEID.)

It follows, then, that if Google truly wanted to create a splash in the industry and achieve its goal of creating and directly selling the ultimate flagship device that’s totally carrier agnostic, they would have made absolutely certain that HTC built in either multiple radios for UMTS and CDMA, or some modern, hybrid UMTS/CDMA chipset similar to the Qualcomm MSM6200 (PDF link) rumored to be at the core of the next-gen iPhone.

Whatever the case, the decision to launch hardware that at present restricts it to T-Mobile for 3G, EDGE on AT&T, and no CDMA functionality at all, extremely limits the device and ultimate impact. Moreover, it means that HTC and Google are going to have to support 3 sets of unique hardware for the “Nexus One” name. One with a CDMA-stack version for Verizon/Sprint, the current incarnation for T-Mobile, and a final version supporting AT&T’s 3G frequencies. Perhaps even more if they eventually move to support additional carriers in Europe and Asia.

Personally, I find it heartily ironic that rumors abound Apple is using a hybrid UMTS/CDMA chipset in the next gen iPhone. If so, that would make the same iPhone so many complain about because of its exclusivity with AT&T, the most open.

More open, in fact, than the Nexus One.