No more locking on 2G for the iPhone 4S

People locking their phones on 2G has long been an issue for network operators. Reason being is that 2G networks have long been viewed as "end of life" and no new investment should be made on them. However quite a lot of people find that when their phones are on the 2G network their battery lasts longer and also that 2G networks seem to be more reliable.

Historically all phones could be locked to 2G through their menu, so it was very straight forward for a customer to make that choice. This meant that even though "2G only" devices are hard to find these days, the traffic on 2G networks was on the increase. 

Considering then that all phones allow the user to lock to 2G, I was quite surpised to find out that Apple made the decision to disable that capability on the iPhone 4S. Whether this was done due to pressure from operators or whether Apple believe that their customers can get a better user experience on 3G networks (from a data throughput point of view), is hard to say. Some people have said that Siri was the main reason which requires a high speed data connection to send the spoken command to Apple's voice analysis servers.

For whatever reason, it is a fact (as shown on the menu pictures below) and it will be very interesting to see how this develops. Could other handset manufacturers follow suit or will Apple regret the decision and re-enable the functionality through a SW update? Time will tell..

iPhone 4 with "Enable 3G" option

iPhone 4S with no option to lock to 2G

Fast Dormancy Rel8 in the wild

When fast dormancy was originally introduced a few years back by RIM on the Blackberry, few people would probably have realised how much of a hot topic it would become. A few years later the name has been adopted as a standard and the specifications have been altered to cater for it.

Fast dormancy was initially thought of by UE vendors as a way of saving battery life. Rather than staying in the power hungry state CELL_DCH for as long as the network timers dictated, the UE could send a SCRI RRC message (Signalling Connection Release Indication) which would result in an immediate transition to IDLE. Everything was fine for a while, but as more and more UE vendors started implementing similar mechanisms, the signalling load to transition UEs to IDLE and back to connected mode every time there was even a keep alive, started creating problems. RNC processor load shot up, signalling load on the IuPS and Iub increased and operators started complaining.

The 3GPP finally addresses the whole issue in Rel8, with the standardised implementation of Fast Dormancy. Now the network indicates it supports Fast Dormancy by broadcasting timer T323 in SIB1. The UE is allowed to send the SCRI according to the specs "if the upper layers indicate that there is no more PS data for a prolonged period". Notice the ambiguity in the "prolonged period". This is definately open for interpretation. The difference however now is that within the SCRI is a new IE (information element) "UE Requested PS Data session end". This now gives the network the ability to switch the UE to a more "battery friendly" state such as CELL_PCH or URA_PCH.

The specs also allow the UE to re-send the SCRI from CELL_PCH or URA_PCH if the DRX cycle in this state(s) is shorter than IDLE DRX. However timer T323 has to expire first before any more SCRIs are sent.

The screenshot below shows that networks have already started implementing this (this one taken from T-Mobile UK). On this particular case T323 is set to 0s meaning the device does not have to wait at all in case it decides to send a subsequent SCRI message.

AT&T network teardown (part 1)

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.