You are on page 1of 5

CONFIDENTIAL

High-Level Planning & Design Workshop:


Macro Network Planning & Policy

David Brock
Director, Product Marketing | 22 Jan 2013
Key Planning assumptions for femtocells

RF planning for self-optimising femtocells


Small set of RF resources reserved for Femto layer
UARFCN/Primary Scrambling Code pairs
LACs
Distinct UARFCN/PSC and LAC pools means that Femtos can detect other
nearby Femtos (via Network Listen) and avoid using the same resources
Distinct LAC pool from Macro means that UE will always perform Location
Update when reselecting a Femto and thus allows Access Control to be applied
(for closed cells)

This LAC separation policy is not essential for open-access femto, but if
sharing LACs between macro and femto layers, planning is needed to
avoid excessive paging load due to large fan out at the Access
Controller
The AC manages a large number of APs, so a single incoming Iu page could
generate a very large number of messages on the AP side

2 CONFIDENTIAL
The need for dynamic and static LACs

As noted, we want the AP to select from a pool of LACs to support closed


access control
The selected LAC may vary over time in response to detecting other APs
But for other purposes, we want a fixed SAI on RANAP
To support billing, cell broadcast, potentially for emergency call routing/positioning

The answer is to break the normal association between on-air LAI and the LAI
part of SAI
Normally SAI = LAI + SAC = MNC + MCC +LAC +SAC
But this convention is not essential to operation because of the different network
usage of LAI and SAI
LAI is used on-air to support Paging and Mobility Management
SAI is used for other, unrelated, purposes
We refer to an On The Air LAI (OTA LAI) and a RANAP SAI
The OTA LAI reflects the LAC selected for on-air use
The RANAP SAI is an entirely separate, provisioned identifier used only in RANAP

3 CONFIDENTIAL
Different uses of OTA LAI vs. RANAP SAI

4 CONFIDENTIAL
Assumptions/Conclusions

Femto shares 2nd and 3rd UARFCNs (F2, F3) with macro
In line with Ericsson recommendation (Scenario 2/B)
At least 2 PSCs per UARFCN for self-planning femtos
Allows moderate femto deployment density without clash
Each UARFCN/PSC pair has an associated LAC
Allows moderate femto deployment density without clash

Additional UARFCN/PSC pairs for planned/open enterprise femtos


Each femto in a macro neighbour list must have unique UARFCN/PSC
LAC can be shared by many femtos, but separate from macro

Normal Core Network configuration to associate LACs with AC Iu


interface
So paging is routed correctly

SAI policy dependant on Emergency Call/Billing topics later

5 CONFIDENTIAL

You might also like