Category 4 LTE UEs in the market

It is interesting to see that the first category 4 LTE UEs are appearing in the market. Up to now the vast majority (if not all) of LTE devices have been category 3. The device in question is Huawei's E3276 USB dongle. Category 4 LTE UEs can reach theoretical physical layer DL throughputs of up to 150Mbps. The uplink throughput stays the same at 50Mbps.

The E3276 is also LTE penta-band capable (LTE FDD 800/900/1800/2100/2600) which means that it will operate in pretty much every country that has launched LTE.

The complete 3GPP release 8 LTE UE category table can be seen below.

Moving to the next category, 5,  is not going to be that easy as it requires 4x4 MIMO in the DL. This will mean operators will need to deploy an additional 2 antennas on the base station and UE vendors will need to squeeze another 2 antennas in the device. Possible on a tablet but anything smaller is going to be a challenge. In case you are wondering the increase in the uplink performance of a category 5 device is due to the use of 64QAM as opposed to 16QAM.

Unhappy with 4G? Lock to 3G!

For years now buying a 3G handset and locking it to 2G has been quite popular. As reported here this was mainly done to get around poor battery life in 3G. Of course this would have an obvious impact on data performance as GPRS/EDGE networks struggle to deliver anything faster than a couple of hundered of kbps at best. From an operator (carrier for our US readers) point of view this was bad as it meant the legacy 2G network was still seeing quite a lot of traffic.

Considering the above it was interesting to see what the options are for 4G capable devices. A screenshot from the Network Mode menu of a Samsung SIII LTE is shown below.

As you can see gone is the option to lock to 2G and now the two options are either 2G/3G/4G (i.e. auto) or 3G only. I guess the option to disable 4G has to be there, from a battery life point of view, stability of early 4G networks and the problems with support for voice calls. But at least in my opinion the second choice should be 3G/2G as opposed to 3G only. I guess this will change depending on the device manufacturer so it will be interesting to see what others do.

Chance encounter with a femto cell

I was recently performing some drive tests in a busy city centre and came across a femto cell in closed access mode. It was a chance encounter and I was only alerted to its presence by the automated TEMS voice indicating a failed Location Update. The first thing to note as indicated by the map below, is that this location in theory should have perfect coverage. What this shows (perhaps of no surprise) is that even in city centres, coverage holes do exist and people are forced to install femto cells for in-house coverage.

The second thing to note is that this is probably the worst place to install a closed access femto cell. The road is a busy one and to make things even worse there is a bus stop just outside! The amount of failed location updates must be in the in the hundreds if not thousands per day as a continuous stream of cars, buses and pedestrians pass through. A true closed access femto cell nightmare. The signalling trace below, shows the procedures involved as the UE tries to camp on the femto cell and gets rejected (cause code 13).

The time elapsed from reselecting the femto cell, failing to perform a LAU, returning to the macro and performing a further LAU/RAU (not shown in the trace) was approx. 6 seconds. So quite a large "outage" from the customers point of view. From a femto point of view we can expect the LAU attempt to be handled locally (i.e by the femto itself). The subsequent LAU/RAU back on the macro however is handled normally and as such the load on the core network is measurable. So what can be done is cases like this? Femto cells can be installed anywhere so how can the operator protect themselves? A few things come to mind. First detecting the problem. This could be easily solved by looking at failed LAU attemtps counters from the femto (if the manufacturer has implemented them). For an even more obvious detection method an NMC alarm could be created for when the amount of failed LAUs exceed a particular threshold. Once the problem femto is detected its CPICH could be reduced so it is not over-propagating into the street.

WCDMA code tree fragmentation and what to do about it

Managing the downlink code tree in WCDMA is an important Radio Resource Management function. As a WCDMA system starts accepting traffic, various branches of the code tree will be blocked. Ensuring that the code tree is as compact as possible enables the system to freely allocate higher branches (lower SF). For HSDPA heavy networks this is key in ensuring the scheduler has at any TTI the maximum SF16 available.

Most UTRAN vendors manage this during the set-up phase. So for example a CS12.2kbps voice call (SF128) will get the left most SF128 available. This ensures that the right hand side of the code tree can be allocated to HSDPA. In high traffic situations however, as calls continuously get set up and released, even this approach might lead to fragmentation. As an example assume that at time X, SF128,48 was the left most SF128 available and this get allocated to a UE. At time X+1 however, it might be that a number of connections have been released and SF128,30 is now available. If however the original call on SF128,48 is still ongoing that space between 48 and 30 cannot be utilised.

A solution to this problem is to use dynamic code tree management which is what this network is using. As the trace extract shows at RRC Radio Bearer Setup that UE was allocated SF128-37.

Then as time progresses, a number of calls get released and the RNC instructs the UE to switch to SF128-30 as this is the left most SF128 available. This switch is signalled to the UE using the RRC Physical Channel Reconfiguration message, as the spreading operation in WCDMA is covered by the physical layer.

This procedure can then further repeat itself, depending on how much traffic there is and how long the connection lasts.

Apple announce FaceTime over 3G/LTE on iOS6

At the recent Apple WWDC it was announced that on iOS6 users will be able to use FaceTime over the cellular network. I should point out that this has been possible for a while with a jailbroken iPhone but in iOS6 it will be available as standard.

Now video calling has been possible in 3G since the beginning, but as most people know it never had much success. Some device manufacturers actually even removed the capability from the menu as years progressed. I guess the reasons for it failing were many, but for sure the quality aspect of it had a big impact. Video calls over 3G were handled by a circuit switched 64kbps connection and no matter how good the codecs, trying to send video and audio over that bandwidth just didn't work.

Things have obviously evolved since and now with HSPA(+) and LTE there is quite a lot a bandwidth over the air interface. But how much bandwidth does FaceTime require anyway? To find out I hooked up my iPhone to a Wi-Fi access point that I can monitor and produced the graph below.

The x axis shows bits, so on average the bandwidth utilisation is around 400kbps. I should point out that for this FaceTime call the background was mostly static. As you can see at the beginning of the call there was some movement and the utilisation exceeded 500kbps. This is due to the way video codecs work where only the delta between frames is sent (roughly speaking).

From an network operator point it will be interesting to see how the quality aspect of it is handled. Even though the air interface bandwidth with HSPA(+) and LTE is very high, it is still a shared medium, with mobility, fading, noise, etc which could make the user experience quite poor in some situations.

One approach could be to offer a best effort service (which almost all operators do for data at the moment) but another approach could be to offer some level of QoS. In 3G this could be through the use of a secondary PDP context that is mapped to a streaming type RAB. This would require some development from Apple's point of view as the device would have to request the secondary PDP context activation when the FaceTime app is initiated. In LTE things are simpler and the PCRF (Policy and Charging Rules Function) could detect the FaceTime call through deep packet inspection and request the establishment of a Dedicated EPS Bearer with a better QoS. These concepts are further described here.

LTE CSFB Performance in a live network part 2

A while back I made a post about the performance of CSFB in a live network. Even though it was quite insightful it only captured a single CSFB procedure so from a statistical point of view the performance impact of the call setup delay was not that valid.

Recently Ericsson and Qualcomm produced a paper which summarises their findings from multiple tests and I have presented the most relevant table above. The multiple columns represent the performance impact of the different "flavours" of CSFB. As the implementation becomes more complex (from right to left) the call setup delay is reduced.

The basic impementation is what was initially conceived in the standards in 3GPP rel8. In order to save some time when the UE is redirected to UMTS, it can skip reading some SIBs. This can be either a proprietary implementation or some 3GPP rel7 fucntionality can be used which allows the UE to skip some SIBs and inform the network about it, which can then send the relevant information in connected mode.

SI Tunnel, specified in rel9, allows for the SIBs to be sent to the UE while still in LTE as part of the RRC Release with redirection message.

Finally a handover can also take place which will keep the UE in dedicated mode and allow for the fastest call setup.

In my opinion I think the SI Tunnel approach will be the mainstream solution as it offers a good balance of performance Vs complexity.

Interesting enough looking at the CSFB log I posted previously here, we can see that in this occasion the UE actually used some proprietary SIB skipping fuctionality as some SIBs such as SIB11 and SIB5 were not read by the UE. As SIB5 is mandatory for initiall access I can only assume that the UE had previously camped on that particular cell and had stored the SIB5 and SIB11 in memory.

The full paper that contains a lot more interesting information can be found here.

It is not about the subscribers, but still..

A while back network operators realised that using the number of subscribers as a measure of success was not the best thing to do. Much more important was how much they were spending a.k.a. ARPU. However in my opinion the number of subscribers is still a very interesting metric.

So for this post, I looked at the various 2012 Q1 results UK operators publish and compiled the graph above. So in first place is Everything Everywhere which is the joint venture of T-Mobile and Orange in the UK. With 27.2 millions subscribers it is easily in the lead but interesting enough, when first formed back in 2010 they had 29.5 million subscribers. In second place is O2 UK with 23.3 million, which back in 2007 landed the exclusivity of the iPhone and did quite well out of it (it is not in place anymore). Vodafone is third with a round 19 million followed in last place by 3 with 8.2 million.

3's figure is actually quite impressive considering they were the last entrant in the market and operate a 3G network only. 3's operational statement list another very interesting fact which is that 30% of their subscribers are mobile broadband dongles.

In 3's blog they actually posted that 97% of their traffic was data. Considering the number of dongles that is not surprise.

Finally, one last thing to consider is that the UK population is just under 65 million. The grand total of subscribers across all operators is 77.7 million! That just shows the popularity and level of saturation that mobile telephony has.

I too play my small part by having a SIM from each operator. But that is for research of course :)

Sources
Everything Everywhere here
O2 UK here
Vodafone UK here
3 UK here