Femtocells and 3GPP Rel8 closed subscriber groups

I'm catching up on some of the recent developments in femtocell standardisation (3GPP still officially calls them Home NodeB's). In particular, I'm looking at what progress has been made about the issue I highlighted in my June report - that modifications to handsets will be essential for mid-term massmarket adoption of femtos.

The report included detailed analysis of what needs to change in handsets - both in the radio/protocol part of the phone, and in the OS/application layers.

My discussions with femto suppliers and operators recently have shown growing acceptance of the first part of this - that developments in 3GPP Release 8 specifications will need to be implemented in phones as well as networks. Most of the femtocell deployment models now seem to distinguish between supporting "legacy" pre-Rel8 devices, and the later, more capable ones.

Much of the work relates to the mechanisms for phones to register on specific femtos, avoid unnecessary attempts to register with unsuitable ones, and how certain femtos can be "preferred" - particularly the one in a given user's home or workplace.

The worst-case scenario is for a user to walk down a street with many homes with femtocells, and for the phone to attempt to connect to each one for the 5 seconds during which its signal appears strongest. This would kill the battery on the phone, generate a huge amount of signalling traffic and potentially lead to dropped calls. Various other scenarios are similarly unpalatable - for example, the phone not registering quickly with an expected femto (eg at home), and the user not receiving the promised discounted call rate.

The bottom line is that various new approaches need to be made to "white-list" particular femtos for particular devices, and aid the fast registration onto those cells. This will use a feature in Rel8 called CSG (closed subscriber group).

But while CSGs solve part of the problem, they also bring with them a whole raft of other issues. I discuss these in the report in some depth, but a key issue is how the user & operator can access and manage this white-list. Another issue is how a CSG-enabled phone can know when to look for a suitable CSG, without having to spend the whole time using battery power to scan for one.

Wading through various submissions to 3GPP, it strikes me that the majority of network-centric participants are not especially well-versed in the compromises that need to be made in phone design to accommodate these and other aspects. So you get lines in standards documents like "The user shall be able to request the UE to perform a scan for available CSG Identities." Well, that's great, apart from the minor question of "Yes, but how, exactly?" - presumably, this needs some form of connection manager application, a bit like using WiFi on a PC. Bear in mind that the average "manual network select" application on a phone is horribly primitive, rarely used, and usually buried 4 layers down in the menu structure.

As an operator, do you really want to be fielding customer support queries about provisioning guest access on femtos, on 100 different device and OS software types, with the user facing some clunky menu structure and indecipherable femto IDs that might look like WiFi SSIDs?

Based on both conversations and reading submitted material, the company that I see coming closest to "getting" both sides of the femto/handset problem at a radio level is Qualcomm. For example, this (zipped) document is a thoughtful analysis of the problems involved in finding femtos in various CSG scenarios. It looks at some of the issues around femto "public hotspots" and campus deployments as well as home-installed products. (It's also worth noting that Qualcomm invested in femto vendor ip.access recently).

One thing that Qualcomm is (corporately) very conscious of is the protracted timeline for getting any new handset technology into the market. As well as the network side of the industry, the phone and device chipset manufacturers need to get their heads around this issue ASAP as well.

On that note, I'll use this as a suitable opportunity to plug my Femtocell-Aware Handset report once again, and also that Disruptive Analysis is able to offer customised workshop and consultancy services on this and related topics. Please contact me via [information AT disruptive-analysis DOT com] if you're interested.