Speaking Engagements & Private Workshops - Get Dean Bubley to present or chair your event

Need an experienced, provocative & influential telecoms keynote speaker, moderator/chair or workshop facilitator?
To see recent presentations, and discuss Dean Bubley's appearance at a specific event, click here

Tuesday, August 26, 2008

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.

1 comment:

Anonymous said...

"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."

1. The user switches on the UE.

2. Cell selection identifies
candidate cells. Based on operator
info in the SIM, a subset of those
cells will be ignored immediately.

3. Connection establishment means the
UE sends an RRC Connection Req. The
CAC in the femto (RNC) box will not
recognise the UE, and will send an
RRC Connection Reject. The redirect
parameter will be the cell id of the
operator macro-cell(s) with(in) which
the femto-cell dwells/overlaps.


"This would kill the battery on the phone"

At worst no more than any other cell
selection scenario.


"generate a huge amount of signalling traffic"

Obviously not, because the UE has not
established a connection to the radio
network. Could be a bit more *OAM*
traffic (relating to the RRC Connection
Req/Reject messages occurring) .


"and potentially lead to dropped calls."

Only if the UE is in CELL_FACH mode
(cell reselection is possible) , and
chooses a worse cell.

If the UE is in CELL_DCH mode then the
UTRAN decides where the UE goes. Which
is std behaviour.


All that is needed is for an app on the
SIM to be able to hold a set of cell
info (a cell id for home, LAI/RAI for
work etc) . That info can then be fed
into the radio plane just as is the
case today with PLMN info (MNC etc)
held on the SIM.


"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?"

You wouldn't have to.
You can easily provide a "training
mode" where the femto-box lets the
UE connect. The owner (via a web
interface etc) would be asked if the
identified device (IMSI etc) is ok to
admit. Clicking yes (and other stuff
like once-only/always etc) will be
fine.

And away you go.


A lot of these so-called problems
really are non-existent. What you need
to do is speak to people who have
actually worked on the development of
UTRAN/CN NEs +/- OAM. Most of them will
simply go thru the scenarios as I have,
and give you a number of simple options
for solving the issues.

As far as femto-cells go, the only
big issue for me has only been how does
a home femto-cell id get passed down to
an RNC so that it can be conveyed in
UE-specific SIBs (as neighbouring cell
info etc) .

Everything else is more than solvable.