BSR Femto Area Codes

July 2010

BSR FEMTO AREA CODES

Copyright 2010 by Alcatel-Lucent. All Rights Reserved. About Alcatel-Lucent Alcatel-Lucent (Euronext Paris and NYSE: ALU) provides solutions that enable service providers, enterprises and governments worldwide, to deliver voice, data and video communication services to end-users. As a leader in fixed, mobile and converged broadband networking, IP technologies, applications, and services, Alcatel-Lucent offers the end-to-end solutions that enable compelling communications services for people at home, at work and on the move. For more information, visit Alcatel-Lucent on the Internet: http://www.alcatel-lucent.com. Notice The information contained in this document is subject to change without notice. At the time of publication, it reflects the latest information on Alcatel-Lucents offer, however, our policy of continuing development may result in improvement or change to the specifications described. Trademarks Alcatel, Lucent Technologies, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of Alcatel-Lucent. All other trademarks are the property of their respective owners. Alcatel-Lucent assumes no responsibility for inaccuracies contained herein.

Alcatel-Lucent Proprietary Version 1.8

BSR FEMTO AREA CODES

CONTENTS
1 BSR FEMTO AREA CODES .................................................................................... 4 1.1 1.2 2 OVERVIEW ................................................................................................ 4 EXAMPLE REFERENCE ARCHITECTURE ...................................................................... 4

DEFINITION OF AREA CODES ................................................................................ 5 2.1 2.2 2.3 WHAT IS A CELL ID? ...................................................................................... 5 DEFINITION OF CELL-IDS IN THE BSR FEMTO ARCHITECTURE ............................................... 6 ASSIGNMENT OF AREA CODES TO A BSR FEMTO CELL...................................................... 6

RESTRICTIONS ON AREA CODE PROVISIONING ........................................................... 7 3.1 3.2 3.3 IMPACT ON THE CORE NETWORK .......................................................................... 7 IMPACT ON THE FEMTO NETWORK ......................................................................... 7 HOW TO LIMIT THE NUMBER OF AREA CODES USED ......................................................... 8

AUTOMATED AREA CODE PROVISIONING.................................................................10 4.1 4.2 4.3 4.4 4.5 FEMTO ADAPTATION LAYER ..............................................................................10 HOME NETWORK MANAGEMENT ..........................................................................10 CORE NETWORK PRE-PROVISIONING ......................................................................11 MANUAL OVERRIDE FOR FEMTO PRE-PROVISIONING .......................................................11 AUTO-DETECTION OF AREA CODES .......................................................................11

5 6

APPENDIX A: RELATED READING ..........................................................................12 APPENDIX B: GLOSSARY OF TERMS .......................................................................12 6.1 ACRONYMS...............................................................................................12

Alcatel-Lucent Proprietary Version 1.8

BSR FEMTO AREA CODES

1 BSR FEMTO AREA CODES

1.1 Overview
The BSR Femto Solution can support many more Femto Cells than there are Macro Cells in todays UTRAN. The impact of this is that the Core Network cannot support an area code strategy that relies on defining unique per-cell data. Typically the Core Network is a 2G/3G combined approach and there are differences between the existing standards and the needs of a Femto Cell network. This document will only describe some approaches to Core Network area code planning. Other white papers describe the Femto Cell Access Restriction process. The restrictions coming from Access Restriction are summarised below.

1.2 Example Reference Architecture

The BSR Femto Solution is made up of clusters of BSR Femto units 3G access points designed for in-building home use plus a BSR Femto Gateway, which provides connectivity to the 3G core network. The BSR Femto Gateway is comprised of a combined Voice, Packet and Security Gateway, a AAA server, a Signalling Gateway and an optional ATM protocol converter. In the following example, the Macro network has an RNC using LAC 100 and defines a range of SACs according to the localisation needs of Location Based Services such as Emergency Call. In the Femto network, a cluster looks like a Virtual RNC to the Core Network. A range of LACs is required to force Location Update triggers between different Femto Cells (for control intra-network mobility via Access Restriction) and the range of LACs must be different from the Macro Network (to control internetwork mobility). A range of SACs or a reserved value can be used.

LAC 101-105 SAC 100-199 or 65535

LAC 100-105 SGSN RAC 100-105

AAA

HLR

Core PDA Home DSL modem Security Gwy + BVG + BPG BSG IPC G-MSC GGSN

UC-Id H02000100 Femto

AP

Legacy UE

LAC 100 SAC 100-199

PLMN UTRAN PSTN MSC

UC-Id H03000200

Signalling Data
Alcatel-Lucent Proprietary Version 1.8 4

BSR FEMTO AREA CODES

In the above example, the area code planning for the packet core network assumes a similar RAC plan to the LAC plan for a particular RNC. As a RAC is contained under a LAC, there have to be as many RAIs as LAIs defined.

2 DEFINITION OF AREA CODES

2.1 What is a Cell Id?
According to the 3GPP TS 23.003 Numbering, Addressing and Identification standard, a GSM Base Station is identified by a Cell Global Identifier (CGI). LAI = PLMN-Id + LAC CGI = LAI + CI

The CGI is used both on the GSM air interface and is communicated to the Core Network over the A-interface. The LAC and CI are both 2 octets in length. In GSM, the Location Area Identifier (LAI) defines the geographical area within which a mobile is considered to be contained at a certain point of time. The size of the location area is determined by the paging accuracy needed and the loading of location updates. For GPRS, the Routing Area Identifier (RAI) was introduced to identify the geographical area containing the mobile for the packet core. The RAC is 1 octet in length and is contained under a LAC. RAI = LAI + RAC

In UMTS, the introduction of the RNC into the RAN architecture means that the identification of cells is changed. In order to support more than 64K Cell-Ids (2G + 3G), the concept of a Service Area Identifier (SAI) was introduced to the Core Network. The SAC is used on the Iu-interface instead of exposing the UTRAN Cell Id which is used on the air interface. The SAC is 2 octets in length and is contained under a LAC. SAI = LAI + SAC

In order for the Core Network to talk to an RNC, instead of just using a LAC, a Global RNC-Id was defined. The RNC Id is 12 bits in length according to 3GPP TS 25.331 RRC Protocol Specification. Global RNC-Id = PLMN-Id + RNC-Id

Finally according to 3GPP TS 25.401 UTRAN Architecture, the UTRAN Cell-Id is defined. The NodeB has a unique Cell-Id which is 2 octets in length and is contained under a Serving RNC-Id. UC-Id = S-RNC-Id + C-Id

Alcatel-Lucent Proprietary Version 1.8

BSR FEMTO AREA CODES 2.2 Definition of Cell-Ids in the BSR Femto Architecture
In the BSR Femto, a revolutionary flat-ip architecture is used. By distributing the RNC function within the each Access Point (AP), the concept of a Virtual RNC is achieved. The BSR Signalling Gateway acts as the signalling end point for SS7 based Iu connections from the Core Network. As such, the BSG is the Virtual RNC from the Core Network perspective. This means the BSG defines the Global RNC-Id for the BSR Cluster. The UC-Id is then made up from the S-RNC-Id and a BSR Id which is the same as Cell-Id as defined in standards. This is a 16 bit field allowing 64K Femtos within a cluster. A single S-RNC Id need to be assigned to a BSR Femto cluster. This means we need a way to distribute the RNC across the 64K Femto Cells. In order to obtain context information from the old Femto Cell, the BSR Femto Architecture defines a unique encoding the U-RNTI across the whole Femto cluster. This allows the new Femto Cell to perform a Gateway lookup of the old Femto Cell to request the context information. The format of the U-RNTI according to 3GPP TS 25.331 RRC Protocol Specification allows the RNC to define its own format of the S-RNTI. U-RNTI = S-RNC-Id + S-RNTI

The S-RNC-Id is 12 bits and the S-RNTI is 20 bits according to 3GPP TS 25.331 RRC Protocol Specification. For the BSR Femto architecture, the S-RNTI is generated as a random number. In future, it is proposed that for compliance to Iuh standards, that the Gateway allocates the S-RNTI. However today, there is no way of passing this Information Element in an Iuh message, so this is left for future standards evolution. The S-RNC-Id and Cell-Id need to be provisioned in the MIB of the Femto Cell. The SRNC-Id is also provisioned in the MIB of the BSG.

2.3 Assignment of Area Codes to a BSR Femto Cell

Based on the above definitions, the RNC function in the BSR Femto supports the assignment of area codes on a per-cell basis. These fields are stored in the MIB as parameters. The LAC, RAC and SAC are individual attributes of the Cell object. As such, the assignment of area codes to an RNC is an OAM function (since these codes must be co-ordinated with the Core Network provisioning i.e. it is not feasible for the Femto to allocate an area code if the Core Network does not understand it). Typically, the Core Network uses the LAI or SAI for billing purposes. Also the LAI and RAI are used for paging and the SAI is used for Emergency Call routing to the PSAP. Additionally the SAI is reported to the GMLC for Location Based Services and Emergency Calls and it may also be reported to the Lawful Interception system. The LAI/RAI and SAI are stored in the VLR of the appropriate Core Network node. There are constraints imposed on the area code provisioning that come also from the IT system, where changing the use of area codes would cause changes to the IT service provided. The impact of a Femto network on area code provisioning is explained in the next section.

Alcatel-Lucent Proprietary Version 1.8

BSR FEMTO AREA CODES

3 RESTRICTIONS ON AREA CODE PROVISIONING

3.1 Impact on the Core Network
The Core Network owns the definition of area codes and the UTRAN must be provisioned consistently with the Core Network. There are typically some constraints on the number of area codes that are supported in the Core Network elements (e.g. the 3G-MSC, IN system Etc.). For example, earlier versions of the Alcatel-Lucent Control Platform (ALCP) 3G-MSC only supported 16K or 32K SAI values. This meant that the full range of the SAI could not be used. Competitor 3G-MSC products have similar restrictions, up to 64K SAI values in some cases. To solve this, ranges have been introduced, but still there are limitations on the number of LAC values supported per RNC-Id in some implementations e.g. 50 or 1000 up to the maximum of 64K. Examples of other constraints are: LAC ranges cannot be shared between MSCs (to be able to uniquely identify the right VLR to go to) LAC allocation schemes between 2G and 3G have been optimised according to network planning rules which limit the available number of free codes for the Femto network (e.g. if the 2nd digit of the LAC is odd/even then this means the LA is 2G or 3G) Geographic size of area codes is determined by service need, which is especially problematic for the SAC due to regulatory constraints on the accuracy of the location determination for the Emergency Call routing The size of the Emergency Call Routing table in the MSC is limited and in some cases, ranges can be used. The GMLC is limited by the number of SAIs it can handle for Location Reporting queries In some cases, the IT system cannot see all fields in the area code e.g. a LAC contained in the SAI may or may not be visible. This would limit the number of Femto Cells in the PLMN. In some cases, the SAI is made the same as the CGI by setting the SAC to the CI field. This cannot be done with the Femto Network since more than 64K Femtos are envisioned.

3.2 Impact on the Femto Network

The Femto Network has to support Access Restriction, which is triggered using Location Updating procedures. The impact of this is as follows: Femto LAI must not be the same as the Macro LAI (if closed access is required and also if open access is required because of the resulting paging load that would have been shared between the Macro and Femto networks) Femto LAI must not be the same as a Neighbouring Femto LAI (unless the Femto is part of the same Femto group). Also different Femto LAI must be used between closed access and open/semi-open access Femtocells to allow the forbidden LAC

Alcatel-Lucent Proprietary Version 1.8

BSR FEMTO AREA CODES

solution to be used in closed access (otherwise open/semi-open access Femtocells may be forbidden to the UE). Femto LAI cannot be shared between clusters (or Virtual RNCs) as the FMS does not co-ordinate LAC allocation over multiple clusters. Femto RAI and SAI (by definition) cannot span LA boundaries Femto Clusters ideally should be contained within a single MSC Area otherwise movement between the Virtual RNC of the cluster and RNCs in the Macro network will cause an inter-MSC location area update to change the identity of the serving MSC in the HLR. Use of Iu-Flex strengthens this argument, because when pooling Core Network nodes, each node can support the Area Codes used in all of the RNCs connected to it. This means a Femto cluster should be aligned to an Iu-Flex pool.

This results in a range of LAIs being allocated to the Femto layer. If geographical significance is needed in the LAI or SAI, then each locality must be assigned a range distinct from the next. So whereas in the Macro network, you could assign an SAI to a number of Macro cells (e.g. 3 cells = 25 km radius), to cover the same geographical area with Femto cells, the same SAC value could be re-used, but multiple LACs need to be assigned in the new SAI definition. For example, assuming 10 LACs are enough for randomisation of the neighbour cells, then 5 SAI would be needed in the area covered by the Macro SAI. The problem this introduces is a 10 to 1 ratio of Femto SAI values to Macro SAI values and this requires extra work to limit the number of area codes that the Core Network has to be provisioned with. Going beyond the single Macro SAI example above, the Femto LACs can be reused, but now the multiplier is the number of Macro SAI/Cell Ids. So if we have a network consisting of 25,000 GSM/UMTS base stations, this results in 250,000 Femto SAI values if we use the Femto LAC. So another solution is required if the Core Network has a limitation of SAI cardinality, in either of the MSC and SGSN implementations, across different vendor solutions deployed in the network.

3.3 How to limit the number of Area Codes used

The above restrictions can be summarised in the statement that the number of Area Codes should be limited. In a Macro network, the cell planning activity has to take care of allocation of new cells to area codes and this is a manual process. However the time to install and deploy a new Macro cell allows for such manual planning to take place. The issue with Femto cell deployment is that it is not under control of the operator but dictated by the end subscriber purchase of a Femto cell for the home. The construction of the LAI and SAI is controlled by the RNC function in the Femto for inclusion in the Initial UE RANAP message to the Core Network. The Core Network can also request Location Reporting Control of the RNC, so that updates of the Service Area are reported during mobility of the UE. For Location Update, the Core Network uses the LAI constructed by the RNC function in the Femto (only the old LAI is included in the NAS procedure from the UE). Using these facts, the Femto RNC function can control what the Core Network is exposed to, in terms of the number of area codes. For LAI, it is recommended that the real LA is kept in sync between the Core Network and the Femto, for paging reasons. If there was a mapping between the Core Network and the Femto LA in order to reduce the number of Core Network area codes, there would need to be a way to reverse the mapping for when the Core Network tried to page the UE under Femto coverage. The problem of paging with a Super LAC
Alcatel-Lucent Proprietary Version 1.8 8

BSR FEMTO AREA CODES

requires the Femto Gateway to track the location of every UE under Femto coverage. This allows paging to be directed to the exact Femto where the UE is attached. The LAC in the paging message is no longer useful since it does not match the LAC in any Femtocell, so it has to be ignored. Since the LAI and SAI both contain a LAC value, the question arises can this LAC be different between the two information elements in the Initial UE RANAP message? The standards state in TS 25.413 that the LAC in the LAI overrides the LAC in the SAI for mobility management purposes. This indicates that is possible to use different LAC values in the LAI and SAI. Also for the RANAP location reporting procedure, the SAI can be explicitly requested by the Core Network. In this case, the location reporting might be confused if the Femto LAC was used in the SAI, which would change as the UE moved between Femtocells. Also the GMLC has limitations on the number of SAIs it can translate in to geo-coordinates. This leads to the conclusion that the LAI and SAI need to be provisioned separately. For SAI, it is recommended that a compromise between very detailed geographic Service Areas is achieved. One approach is to reuse the value of the SAC in the Macro Network with a reserved LAC value for the Femto network. One problem with this is coverage holes in the Macro network mean that the Femto would not be able to detect the Macro SAC using the Network Listen function. This would require network planning to provide the missing SAC values via the Femto OSS solution. If the Macro UC-ID uses the same value as the SAC, then this can be obtained using the Network Listen function of the Femto in the 3G case. Otherwise, network planning would need to provide the UC-ID to SAC mapping via the Femto OSS solution. For 2G the CGI can be always be obtained since it is the same on the air interface and the core network interface. If this approach is feasible, the Femto can store a second SAC value in the MIB to hold the Macro SAC value, instead of using a geographic SAC for the Femto. Using OAM defined rules, the second SAC value can be used to construct the SAI. If obtaining the 3G Macro SAC value is not feasible, then the second SAC value can be provisioned instead of using the Network Listen function. Finally, it is envisioned that if Emergency Call or Location Based Service use of SAC can be achieved in another way (e.g. using Geographic Coordinates from a GPS system, or by using a geographic SAC value), then the SAI used can be constructed using a reserved SAC value. This can be used to indicate a billing result e.g. for low billing tariff given to certain IMSIs defined in the ACL. For example, the first SAC value in the MIB could be set to a reserved value to indicate the low rate billing. The second SAC value could be set to the Macro SAC/CGI or to another reserved value to indicate standard rate billing (i.e. the same as the Macro billing rate). For prioritised access (or semi-open access) to the Femto, another billing rate can be conceived, requiring a third SAC value. Alternatively, the low billing tariff approach could be achieved using the LAC instead of the SAC, which leads to the advantage that the SAC can remain geographic for use with Emergency Call or Location Based Services. In this case 2 LAC values are needed in the MIB. These values can be reserved or derived from the Macro cell. This also has the advantage that Network Listen can always get the LAC value from the 3G macro cell. For full flexibility, it is also envisioned that Emergency Calls may require a different geographic accuracy to Location Services and so a fourth SAC value can be configured in the MIB to support this. Combining with the above comment about mobility management use of LAI and SAI, we conclude that five LAC and SAC values are needed in the MIB, representing
Alcatel-Lucent Proprietary Version 1.8 9

BSR FEMTO AREA CODES

mobility management, low, standard and prioritised tariffs, and emergency call values.

4 AUTOMATED AREA CODE PROVISIONING

4.1 Femto Adaptation Layer
The FAL is a 3G OAM module developed for the 9353 WMS for Femto OSS, designed to provide an Assisted Cell Planning solution for the BSR Femto Network. The FAL module provides proprietary algorithms to distribute Femto Cells within a geographical area, and also implements the randomisation of area codes for a new Femto Cell. This works by using the geographic coordinates of the Femto Cell and plotting the location of existing cells relative to the new Femto Cell to be provisioned. Once the new location is calculated, the best possible area code is selected by reusing the area code from the Femto Cell which is furthest away from the new location. The FAL algorithm needs to know the location of neighbouring Macro cells and the deployed Femto cells in order to work out the complete picture of area code planning for the Femto network. This information is collected through the Femto preprovisioning and Macro cell planning interfaces. If these interfaces cannot be kept upto-date, then the FAL will be unable to maintain a correct allocation of the area codes to each Femto. Manual overrides will update the network map in the FAL but must be made via the FMS and not using other interfaces. Should the FAL be unable to allocate a non-adjacent area code to a new Femto, this situation is alarmed to the operator. The scenario when this is most likely to happen is when Femto deployments become denser than the number of area codes allocated for reuse. In such cases, the solution is for the operator to provide an increased area code allocation to the Femto cluster. The impact of this area code replan will be to re-provision the Femtos impacted with a new set of area codes.

4.2 Home Network Management

The 5580 HDM is a DSL management solution which provides TR.069 management of the Femto Cells. When the Femto Cell registers with the HDM for the first time, the HDM triggers the FAL using its northbound interface. This causes the Femto Cells configuration data to be calculated and written as an XML file for download to the BSR Femto. This calculation is dependent on knowing the location of the Femto Cell. When the Femto is pre-provisioned, the FAL is provided with a translation of the subscribers address into geographical coordinates. The FAL is also provided with the geographical area plan, and can then plot the Femto Cell within the coverage of a certain geographical area. The area codes can then be derived as described above to provide the best area code to use.

Alcatel-Lucent Proprietary Version 1.8

10

BSR FEMTO AREA CODES

1. Define a Planning approach, e.g. align cluster borders to MSC pool areas. 2. Rebuild the desired areas with location squares
1. Create many locations with the same set of LAC/RAC/SAC 2. Match Lat/Long squares to Macro Layer e.g. MSC pool area

3. FAL assigns the Femto LAC according to distance 4. FAL assigns the Femto RAC and SAC from assigned Lat/Long Square based on Geo-Coordinates

LAC closed access Cluster #1 LAC closed access Cluster #2

In the above diagram, each set of rectangles has a LAC range. For clarity, the rectangles and the Femto Cells are not overlapped, but in reality they would be, as shown by the green Femto Cell near the middle of the diagram, surrounded by the red square which represents a particular LAC, RAC and SAC value.

4.3 Core Network Pre-Provisioning

Whilst the number of Femto Cells demands some automation, it is understood that there needs to be a link between Femto provisioning and Core Network provisioning. So it is possible to dry-run the FAL algorithm ahead of connecting the Femto Cell to the network. This provides the resulting area codes ready for upload into the Core Network elements e.g. to set up billing Etc.

4.4 Manual Override for Femto Pre-Provisioning

From customer request, it is provisioning either by fixing one the other or by fixing both of consequence of doing this is that as part of network planning. possible to override the automated area code of the area codes (e.g. LAC or SAC) and allocating the area codes using pre-provisioned values. The the randomisation of area codes must be performed

4.5 Auto-Detection of Area Codes

The Network Listening function in the Femto allows the second receiver to scan the RF environment for neighbouring Femto and Macro cells. The LAC is broadcast in SIB1 and therefore can be read from the broadcast channel of the neighbouring cells. The Cell Identity is broadcast in SIB3 and therefore can also be read. However the use of this information is restricted to auto-creation of neighbouring cells (for broadcast in SIB11).

Alcatel-Lucent Proprietary Version 1.8

11

BSR FEMTO AREA CODES

For Macro Cells, which operate in open access mode where any UE can camp on the cell, multiple Macro Cells can have the same LAC. However this Macro Cell LAC must be different from the Femto Cell LAC, to support closed access mode. If closed access is not required, then the Macro LAC can be used to minimise the signalling load towards the Core Network. Neighbouring Femto Cells must be provisioned with a different Femto Cell LAC in addition. Lack of geographic coordinates for use with the FAL would mean that the Femto Cell LAC must be allocated randomly. The range of Femto Cell LACs should be increased to limit the probability of a LAC clash. Any clash of Femto Cell LAC can be detected by reading the broadcast channel of the Femto neighbouring cells. If the same LAC is used, but the Access Control List is different, then this situation can lead to forbidden Location Areas or missed paging messages. The Femto Cell must provide this information back to the HDM to correct this situation, via re-provisioning. This may allow the FAL to update its information map of the deployed Femto Cells. If the same LAC is used for both closed access and open access cells, then forbidding the Location Area may prevent subsequent access to an open access cell later. Whilst it is possible to detect that the LAC of this Femto Cell is in use by a neighbour, the Femto cannot reliably change its own LAC. To do so would potentially create an invalid LAI or SAI that the Core Network cannot recognise. Also, changing the area codes on this Femto would create a knock on effect on neighbouring Femtos, causing them to potentially change area code as well. This ripple effect is not controllable, especially since powering off a Femto cannot be prevented, causing LACs to appear and disappear. Such automatic rebalancing should not be attempted in isolation, so it is envisaged that some co-ordination between Femtocells and the Femto Gateway is needed to control this function.

APPENDIX A: RELATED READING

For further information on access control please refer to: White Paper BSR Femto Access Restriction

APPENDIX B: GLOSSARY OF TERMS

6.1 Acronyms

A-Z
3GPP ALCP BSG BSR CGI CI 3rd Generation Partnership Project Alcatel-Lucent Control Platform BSR Signalling Gateway Base Station Router Cell Global Identifier Cell Identity

Alcatel-Lucent Proprietary Version 1.8

12

BSR FEMTO AREA CODES

GPRS GSM HLR LAC LAI MSC PLMN RAC RAI RANAP RNC SAC SAI SGSN S-RNTI UE UMTS U-RNTI VLR General Packet Radio Service Global System Mobile Home Location Register Location Area Code Location Area Identifier Mobile Switching Center Public Land Mobile Network Routing Area Code Routing Area Identifier Radio Access Network Application Protocol Radio Network Controller Service Access Code Service Access Identifier Serving GPRS Support Node Serving Radio Network Temporary Identifier User Equipment Universal Mobile Telephony System UMTS Radio Network Temporary Identifier Visitor Location Register

Alcatel-Lucent Proprietary Version 1.8

13