Back in September I was in New York and I thought I would have a closer look at AT&T's UMTS network. AT&T operates a UMTS network in band II (1900MHz) and band V (850MHz). It also claims to have 4G capability although strictly speaking it is more of fauxG at the moment. Anyway, armed with my logging tool this is what I discovered..
First, network capability/settings can have a geographic aspect, so lets establish the location..
As shown the location was in the SoHo area of Manhattan, New York.
The device I was using was UMTS tri-band (2100, 1900, 900) so I was camping by default on the 1900 layer.
In terms of device capability, I was using a HSDPA category 24, E-DCH category 6 product.
As far as I know AT&T uses 2 UTRAN vendors namely Alcatel-Lucent and Ericsson. Although no vendor information is broadcasted over the air, certain vendors use certain messages or support certain IEs (information elements) a certain way, so with experience you can tell them apart. Based on this I was pretty certain that the UTRAN vendor in the area was Alcatel-Lucent.
In terms of my analysis, I will start off with information broadcasted in the System Information Blocks or SIBs. Looking at SIB1 the first thing that struck me is the AT&T uses quite a long DRX cycle length coefficient of 8. This translates to 2560ms or 2.56s. What this means is that when IDLE the UE will "wake-up" every 2.56s to listen to the paging channel. Now, most networks have a DRX of 6 (640ms) or 7 (1280ms). Having a longer DRX cycle length has the advantage of prolonging battery life, but on the downside it leads to longer perceived MT call set-up times and to potentially poor IDLE mode re-selection as the UE typically will make IDLE mode measurements when it "wakes-up". This means that if the radio conditions deteriorate rapidly the UE might not react fast enough and reselect to the better cell as it is still in "sleep" mode.
Looking at the remaining timers broadcasted in SIB1, I could see that AT&T uses call re-establishment which is controlled by T314 (for voice) and T315 (for packet). Here the values configured were T314 = 8s and T315 = 30s. Again, these values are quite large. Essentially what these timers allow for is the re-establishment of a call after it has experienced downlink radio link failure. Typically T314 is set to 4s as that is the time when most people will keep the handset to the ear trying to figure out why they can't hear anything. After that they will usually give up. For the packet side it is a bit more in the background, for example if you are reading a web page or an email on your phone you probably wont even notice that you dropped a packet radio bearer. Still though 30s feels quite long, especially if you consider that for this duration the RNC will not release any nodeB resources meaning that they might be tied up for no reason.
Moving over to SIB3 the suprises continue. Qqualmin is set to -24dB. This is the first indication I got (the were many to follow) that AT&T strongly biases their 3G network over 2G and tries to keeps UEs in 3G for as long as possible. Typically this parameter is set to -18dB. Looking at the value of s-SearchRat it is set to 0. This means that UEs will stay camped on 3G up to the limit of -24dB Ec/N0 before they start searching for GSM neighbours. This also means that rather that having a seemless reselection between 3G and 2G, I imagine most phones will go "out of service" before they reselect to 2G.
Another rarity on AT&Ts network is that they use SIB11bis. SIB11bis is used to define the total 96 IDLE mode neighbour cells without the size restrictions of SIB11. SIB11bis is optionally supported by rel6 UEs and mandatory for rel7 UEs and above.
Finally on the SIB5, things look pretty standard. The RACH is configured with a maximum throughput of 18kbps, two SCCPCHs are defined one for the PCH (24kbps) and one for the FACH (36kbps).
This concludes part 1 of the teardown which just looked at the contents of the BCH. Next time I will take a closer look at what happens in dedicated mode and what "4G" capability AT&T actually have.
No comments:
Post a Comment