BCR IRC APP 026964 V3 00 - Femto Parameter User Guide BCR3 0

Alcatel-Lucent
Femto Parameter User Guide 3.0

DOCUMENT NUMBER: BCR/IRC/APP/026964
DOCUMENT ISSUE: 03.00 / EN
DOCUMENT STATUS: PRELIMINARY / EXTERNAL DOCUMENT
DATE: 30/JUNE/2012
Alcatel-Lucent proprietary and confidential.

Copyright © 2012. All rights reserved.
Femto Parameter User Guide 3.0 .
Copyright© 2010-2012 Alcatel-Lucent, All Rights Reserved
UNCONTROLLED COPY: The master of this document is stored on an electronic database and is “write
protected”; it may be altered only by authorized persons. While copies may be printed, it is not recommended.
Viewing of the master electronically ensures access to the current issue. Any hardcopies taken must be regarded
as uncontrolled copies.
ALCATEL-LUCENT CONFIDENTIAL: The information contained in this document is the property of Alcatel-
Lucent. Except as expressly authorized in writing by Alcatel-Lucent, the holder shall keep all information
contained herein confidential, shall disclose the information only to its employees with a need to know, and shall
protect the information from disclosure and dissemination to third parties. Except as expressly authorized in
writing by Alcatel-Lucent, the holder is granted no rights to use the information contained herein. If you have
received this document in error, please notify the sender and destroy it immediately.
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.
Passing on or copying of this document, use and communication of its contents not permitted without Alcatel·Lucent written authorization
BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012

CONTENTS
VOLUME 1 INTRODUCTION
VOLUME 2 AUTOCONFIGURATION
VOLUME 3 POWER MANAGEMENT
VOLUME 4 RADIO RESOURCES MANAGEMENT
VOLUME 5 MOBILITY MANAGEMENT
VOLUME 6 INCOMING MOBILITY
VOLUME 10 HSXPA

FEMTO PARAMETER USER GUIDE

VOLUME 1 INTRODUCTION

CONTENT OF VOLUME 1
1. INTRODUCTION............................................................................................................................2
1.1. OBJECT ....................................................................................................................................2
1.2. SCOPE OF THE DOCUMENT ........................................................................................................2
1.3. PRODUCT NAMING ....................................................................................................................6
1.3.1 Solution name: ................................................................................................................6
1.3.2 Access points: .................................................................................................................6
1.3.3 Gateways: .......................................................................................................................6
1.4. NOMENCLATURE .......................................................................................................................7
2. RELATED DOCUMENTS ..............................................................................................................9

2.1. FPUG VOLUMES ......................................................................................................................9
2.2. 3GPP REFERENCE DOCUMENTS ...............................................................................................9
2.3. ALCATEL-LUCENT REFERENCE DOCUMENTS ..............................................................................9
3. SMALL CELL MODEL ................................................................................................................10
4. FEMTO GATEWAY MODEL .......................................................................................................15
5. INDEXES......................................................................................................................................16
5.1. TABLE INDEX ..........................................................................................................................16
5.2. FIGURE INDEX ........................................................................................................................16
5.3. ACRONYMS ............................................................................................................................17
BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012 Page 1/23

1. INTRODUCTION
1.1. OBJECT
The Femto Parameter User Guide (FPUG) provides parameter setting
recommendations from Alcatel-Lucent’s experience, coming from studies, simulations
and experimentations. This document gives the rationale of these settings by
describing Alcatel-Lucent’s Femto BSR algorithms and parameters from an
engineering point of view. It also gives some engineering rules related to parameter
settings.
The FPUG does not contain the complete list of configuration parameters; the
parameters described are customer configuration parameters accessible via the
Femto Management Solution (FMS).
The parameters presented in this FPUG are supposed to be in line with the values
present in the Templates.
1.2. SCOPE OF THE DOCUMENT

The FPUG describes the features and the associated parameters which represent the
salient functions available within Alcatel-lucent BSR Femto solution, based on
BCR3.0.
The relevant features for each volume are listed in the tables Table 1 to Table 6.

Feature
Id Feature Title Activation Flag Basic/Option Release
34535 BSR Femto auto-configuration Basic BCR02.01
34536 BSR Femto self-optimisation Basic BCR02.01
34537 3G Network Listening Basic BCR02.01
34588 Detection of BSR Femto location change Option BCR02.01
Detection of BSR Femto Location Change
76632 based on the ADSL line Option BCR02.01
78230 National Location Lock nationalLocationLockEnabled Option BCR02.02
78695 Dynamic LAC/SAC allocation dynamicSACLACAllocation Option BCR02.02
79495 Super LAC activateSuperLAC Option BCR02.02
80569 Femto group support bsrGroupId Option BCR02.02
75545 GPS-based Location Lock GPS::enableGPSLocationCheck Option BCR2.4
78229 Location lock on 2G RF fingerprint lMCvisibleGsmCellsTest Basic BCR2.4
81514 8 user capacity Hardware specific Option BCR2.4
89552 Network Overload Avoidance sctpInitRateLimit Option BCR2.4
104564 FMS support of GPS localization locking GPS::enableGPSLocationCheck Option BCR2.4
16 user capacity for V2 Enterprise & Metro
104831 Cells Hardware specific Option BCR2.4
105477 Software Support of Rx Diversity Hardware specific Option BCR2.4
109896 Standards compliant RNCid (BCR2.4) BSR::sRNCIdCluster Basic BCR2.4
114997 2G MCC based NLL on V1 boards (Hilo) Option BCR2.4
117010 V2-AC-2 AWS band Hardware specific Option BCR2.4
117011 Support of AWS band Hardware specific Option BCR2.4
76985 Automatic Carrier Selection acsCarrierSelectionMode Option BCR3.0
rtpMuxEnable on BSR and
78234 Uplink DSL overhead optimization BSG Option BCR3.0
92068 Extended ACL size for large Femto Groups aclListRef Option BCR3.0
32 user capacity on V2 Enterprise & Metro
121160 cell Hardware specific Option BCR3.0
3G Macro to Femto PS and CS+PS
101684 Handover psHoFromUmtsMacroEnabled Option BCR3.0
mahoInterActivationCs
Inter-frequency Femto to 3G Macro mahoInterActivationCsPs
100888 Handover for PS and CS+PS calls mahoInterActivationPs Basic BCR3.0
Intra-frequency Femto-3G Macro
100856 - MAHO for CS calls (100856) and PS
100857 (100857) mahoActivationIntra Basic BCR3.0
Table 1 – Volume 2- Autoconfiguration Features

Feature Id Feature Title Activation Flag Basic/Option Release
34528 Power control Basic BCR02.01
78320 Enhanced power management hSDPADynamicPowerEnabled Basic BCR02.02
83236 100 mWGeneric Standalone Femto 8Users Option BCR02.02

91654 Automated Femto Receiver Gain Control Basic BCR02.02
Continuous coverage self-optimization based enableCoverageSelfOptimisationBa
108877 on Admission sedOnAdmission Option BCR3.0
111039 Extended Range Cell ExtendedCellEnable Option BCR3.0
116495 UL interference management ulIntfCtrlMacroEnabled
ulIntfCtrlFemtoEnabled Option BCR3.0
Table 2 - Volume 3 - Power Features

34526 Air Interface Congestion control Basic BCR02.01
LCell::emergencyCallPreemptionEn
34527 Pre-emption process for emergency call abled Basic BCR02.01
34586 Dynamic Bearer Control Basic BCR02.01
34596 Active call redirect from BSR Femto to Macro BSR::activeCallRedirectEnabled Basic BCR02.01
36217 CAC on backhaul resources BSR:: enableTransportCAC Basic BCR02.01
74769 Voice Prioritisation over Data Basic BCR02.01
Emergency call redirection to the Macro
75103 network Basic BCR02.01
75405 Open access enhancements accessMode Option BCR02.02
76976 Enhanced ePLMN support enableUMTSePLMN Option BCR02.02
76977 Detection of collapsing LAI Automatically Activated Basic BCR02.02
Enhanced transport CAC for the standalone
77030 Femto Option BCR02.02
79147 Multiple PDP contexts isMpdpIBsupported Option BCR02.02
109907 Reserved channels for Signalling BSR:sparePara7 Option BCR02.02
isMpdpIBsupported
76984 Multiple PDP context 3PS + CS maxNoOfMpdpSupported Option BCR2.4
enableIncomingDataShutdown
77713 Shutdown of Data Session enableOutgoingDataShutdown Option BCR2.4
77735 Prioritized Open Access accessMode Option BCR2.4
Real-time monitoring of backhaul
84791 bandwidth BSR::enableTransportCAC Option BCR2.4
Service based redirection & handover to
100889 targetted macro layer sBEnable Option BCR2.4
104376 Signalling over Cell_FACH cellFachEnable Option BCR2.4
105476 Call setup using SRB13.6kbps dCCH136enable Basic BCR2.4
Optimized Paging for large Metro cells
100854 deployment (same LA) enableSameLaRaMacro Option BCR3.0
Table 3 - Volume 4 - RRM Features

Cell Reselection to/from macro layer (2G or
34529 3G, intra/inter frequency) Basic BCR02.01
LCell.enableDAHOInterFreqHO
LCell.targetHOCS
34530 Handover BSR Femto to Macro 3G LCell.targetHOCSPS Option BCR02.01
LCell.enableDAHOInterFreqHO
LCell.targetHOCS
34531 Handover BSR Femto to Macro 2G LCell.targetHOCSPS Option BCR02.01
75392 Hierarchical Cell Structures (HCS) enableHCS Basic BCR02.02
activateFemtoToFemtoCommunicat
75494 Femto to Femto CS HO ions Option BCR02.02
Tone generation during voice call setup under
76980 Femto cell coverage activateUserTone Option BCR02.02
108515 MM/GMM info generation from Femto BSR BSR:generateNameOfNetwork Option BCR02.02
83088 Femto to Femto PS handover enableFemtoPsHandover Option BCR2.4
enableGrpNeighNeighPSCevaluatio
n
enableTimingMeasurements
84331 Femto to Femto Handover improvements enableHandoverToNextBestCell Option BCR2.4
75386 Cell Change Order - Option BCR3.0
mahoOnHoSuccessRate::initialTarg
75387 UE assisted Femto to Macro handover et Option BCR3.0
Intra-frequency Femto to 3G Macro MAHO for
100856 CS calls mahoActivationIntra Option BCR3.0
Intra-frequency Femto to 3G Macro MAHO for
100857 PS and CS+PS calls mahoActivationIntra Option BCR3.0
mahoInterActivationCs
Inter-frequency Femto to 3G Macro Handover mahoInterActivationCsPs
100888 for PS and CS+PS calls mahoInterActivationPs Option BCR3.0
119860 3G Sniffing Capability in 2100/850MHz Option BCR3.0
Table 4 - Volume 5 - Mobility Features

75389 3G Macro to Femto CS handover hoFromUmtsMacroEnabled Option BCR2.4
75390 2G Macro to Femto CS handover hoFromGsmMacroEnabled Option BCR2.4
hoFromUmtsMacroEnabled
83083 Incoming CS handover in open access hoFromGsmMacroEnabled Option BCR2.4
3G Macro to Femto BSR Handover for PS &
101684 CS+PS calls psHoFromUmtsMacroEnabled Option BCR3.0
Table 5 - Volume 6 – Incoming Mobility Features

34523 HSDPA Support activateHSDPA Option BCR02.01
74762 HSUPA activateEDCH Option BCR02.02
75384 Higher HSDPA throughput Option BCR02.02
77024 Dynamic Code Allocation dcaEnabled Option BCR2.4
eDCH2msActivation
eDCHmaxCatPerf
maxEdchCellRate
113161 Full rate HSPA maxHsdpaUserRate Option BCR2.4
116496 64QAM for HSDPA enable64QAMflag Option BCR3.0
116497 Flexible RLC and MAC-ehs support - Option BCR3.0
Table 6 - Volume 10 - HSxPA Features
1.3. PRODUCT NAMING

The Alcatel-Lucent BSR Femto solution is identified with following product names.
1.3.1 SOLUTION NAME:

9360 Small Cell Solution (for the Home, Enterprise and Metro) – this was previously
called the Femto Solution
1.3.2 ACCESS POINTS:

¾ 9361 Home Cell (previously the residential Femto)
¾ 9362 Enterprise Cell (previously the enterprise Femto)
¾ 9363 Metro Cell – Indoor (new product)

¾ 9364 Metro Cell – Outdoor (new product)
1.3.3 GATEWAYS:
¾ 9365 BSR Gateway (BSG, BVG and BPG functions only)
¾ 9366 W-CDMA Small Cells Gateway (BSR Gateway + AAA + ALSMS + Brick)

1.4. NOMENCLATURE
In this document, “BSR” stands for the access point device.
• The parameter names are written in bold italic.

• The objects names are written in bold.
• Class field defines the way the parameter change is handled (e.g. Class 3
means that modification is immediately taken into account and no lock/unlock
is needed). Following Classes
o Class 0: the value of the parameter is set at the parent object
creation. Currently, most of the objects can only be killed and re-
created through a new MIB built.
o Class 1: new parameter value is taken into account on the next BSR
restart.
o Class 2: parameters of an object created at the FMS can only be set
when the object and its parent are both locked. The new value will be
taken into account after the object is back to working state
(administrative state set to “unlocked”).
o Class 3: parameters of an object created on the FMS can be modified
when the object (and parent object) is unlocked. The new value is
taken into account immediately.
• The parameters properties for the BSR are presented as follow:
Parameter FMS Name | MIM Name

Object FMS Name | MIM Name
Granularity FMS Name | MIM Name
Range & Unit
Class
Value
• The parameters properties for the FGW/BSG/BPG/BVG are presented as

follow:
Parameter FMS Name | MIM Name

Object FMS Name | MIM Name
Granularity FMS Name | MIM Name
Range & Unit
Class
Value

Notes:
• When the names are different in FMS and in the MIM, the parameter properties
will be displaying the names of the parameters as they can be found in FMS and
in the MIM separated by a vertical bar.
• The protocol messages are written in CAPITAL LETTERS.
• The Information Elements (IE) contained in the protocol messages are written the
following way: TPC_DL_Step_Size.
• The data fill rules (non negotiable) are presented as the following. These are
typically Operation and Maintenance (OAM) checks performed on parameters
settings (structure of table, range, etc…)
Rule:
• The system restrictions are presented as the following. Typically when the
behaviour of product is not as specified (e.g. parameters not used by algorithm…)
Restriction:
• The engineering recommendations on parameter value are presented as the

following. These are recommendations related to performance (QoS, Capacity,
KPI) to get the best of the network.
Engineering Recommendation:
• The difference between Release N and Release N-1 are presented as the
following. These are major changes that may lead to behaviour change.
Inter-Release Delta:
• The implementation process specific to FMS
FMS:

2. RELATED DOCUMENTS
2.1. FPUG VOLUMES

[Vol. 1] Introduction
[Vol. 2] Autoconfiguration
[Vol. 3] Power Management
[Vol. 4] Radio Resources Management
[Vol. 5] Mobility Management
[Vol. 6] Incoming Mobility
[Vol. 10] HSxPA
2.2. 3GPP REFERENCE DOCUMENTS

[3GPP_R01] 3GPP TS 25.304 UE procedures in Idle mode and procedures for
cell reselection in connected mode
[3GPP_R02] 3GPP TS 25.331 Radio Resource Control (RRC); protocol

specification
[3GPP_R03] GSM TS 05-05 Radio Transmission and Reception
[3GPP_R04] 3GPP TS 22.011 Service Accessibility

[3GPP_R05] 3GPP TS 24.008 Mobile radio interface Layer 3 specification
[3GPP_R06] 3GPP TS 25.211 Physical channels and mapping of transport
channels onto physical channels (FDD)
[3GPP_R07] 3GPP TS 25.306 UE Radio Access capabilities definition
[3GPP_R08] 3GPP TS25.104 Base Station (BS) radio transmission and
reception (FDD)
[3GPP_R09] 3GPP TS 45.005 Radio transmission and reception
[3GPP_R10] 3GPP TS 25.321 Medium Access Control (MAC) protocol
specification
[3GPP_R11] 3GPP TS 25.214 Physical layer procedures (FDD)
[3GPP_R12] 3GPP TS 25.213 Spreading and modulation (FDD)
[3GPP_R13] 3GPP TS 25.212 Multiplexing and channel coding
2.3. ALCATEL-LUCENT REFERENCE DOCUMENTS

1. NTP 411-8111-813 Access Network Parameters

3. SMALL CELL MODEL
Figure 1 and Figure 2 depict, within the BSR FMS Model, the location of the
parameters which are presented in this document.
BSR can be defined in the FMS at different locations depending of their usage.
The Orphan BSR that does not belong or couldn’t be associated to any cluster will
be defined under FemtoNetworks.
BSR that are associated to a given cluster and which does not belong to a BSR
group are to be defined under FemtoCluster.
Finally, BSR in a cluster belonging to a given BSR group will be defined under
FemtoCluster::FemtoGroup.
Inter-Release Delta: Hardware/Location Profiles
From BCR3.0 new Profiles, the Hardware and Location Profiles, are introduced in WiPS.
Figure 3 and Figure 4 present the Hardware and Location profile. These
parameters have been removed from the BCR3.0 BSR Profile.
For backwards compatibility reasons of WiPS, the parameters which are available
under the Hardware and Location Profile can also be found in the BCR2.4 BSR
Profile.

BSRClusterProfile/n
FemtoCluster/n
Network
femto/n
femtoGroup/n
femto/n
EnterpriseList/n
OwnerAclEntry/n GuestAclEntry/n
FemtoNetwork/1
femto/n
MacroCells/label
FddExtCell/mcc.mnc.rncId.cellId
Profile/label
GSMExtCell/mcc.mnc.lac.cellId
BSRProfile/n
IuCSUplane/1
ETFCS/n Lcell/n
FachRrcEstablishmentCause/n
UmtsMacroEPLMN/n HcsCellRsInfo/n
GSMListener/1
RrcMappingTable/n MacroUMTSCellFrequencyList/n
EDCHMACdFlow/n
GsmFrequencyList/n Support656bitsRLCPDUUECategory/n
FemtoPSClistAdd/n
HSDPA/1 CCPower/1
FemtoPSCList/n
EDCH/1 SBCsRabMappingTable/n
GPS/1
TargetHOFddFreqCS/1 TargetHOFddFreqCSPS/1
Figure 1 - BSR FMS Model


Figure 2 – BSR FMS Model (2)

Inter-Release Delta: Hardware Profile
From BCR3.0 a new Profile, the Hardware Profile, is introduced in WiPS.
Network
HardwareProfile/label
BSRhardwareProfile/n
AutoconfigPW/1
LCell/1
EDCH/1
HSDPA/1
Figure 3 – Hardware Profile
Rule: Hardware Profile Naming Convention
It is mandatory to create for each BSR variant (MaxPowerCapacity/number of users ) a profile

following the convention naming convention:
[MaxPowerCapacity]mW_[number of users]_users
e.g. 100mW_8_users, 20mW_4_users, 250mW_32_users etc..
These will be used as default based on the Hardware capabilities.
Additional Power/Number of users combinations can also be created.

Inter-Release Delta: Location Profile
From BCR3.0 a new Profile, the Location Profile, is introduced in WiPS.
Figure 4 – Location Profile

4. FEMTO GATEWAY MODEL

Figure 5 depicts, within the FGW FMS Model, the location of the parameters that are presented in
the document.
Network
FGW/n
FGWConfig/1
BSGConfig/1
BSGbsrPSCforBasicCellID/n BSGbsrPSCforVirtEnhCellID/n
BSGgsmMacroCellID/1 BSGgsmMacroFrequency/n
BSGumtsMacroCellID/1 BSGumtsMacroFrequency/n
SCCP/1 M3UA/1
LegalReq/1 IPSP/1
SCTPAssociation/1
Figure 5 - FGW FMS Model

5. INDEXES
5.1. TABLE INDEX

Table 1 – Volume 2- Autoconfiguration Features............................................................................... 3
Table 2 - Volume 3 - Power Features ................................................................................................ 4
Table 3 - Volume 4 - RRM Features .................................................................................................. 4
Table 4 - Volume 5 - Mobility Features .............................................................................................. 5
Table 5 - Volume 6 – Incoming Mobility Features.............................................................................. 5
Table 6 - Volume 10 - HSxPA Features............................................................................................. 6
5.2. FIGURE INDEX

Figure 1 - BSR FMS Model .............................................................................................................. 11
Figure 2 – BSR FMS Model (2) ........................................................................................................ 12
Figure 3 – Hardware Profile ............................................................................................................. 13
Figure 4 – Location Profile ............................................................................................................... 14
Figure 5 - FGW FMS Model ............................................................................................................. 15

5.3. ACRONYMS
3GPP 3rd Generation Partnership Project
AAA Authentication, Authorization and Accounting
ACK Acknowledgment
ACL Access Control List
ACR Active Call Redirect
AG Absolute Grant
AICH Acquisition Indication Channel
ALSMS Alcatel-Lucent Security Management Server
ARFCN Absolute Radio Frequency Channel Number
ARQ Automatic Repeat Request
AS Active Set
ATM Asynchronous Transfer Mode
BCH Broadcast Channel
BCR BSR Cluster Release
BLER Block Error Rate
BPG BSR Packet Gateway
BRAS Broadband Remote Access Server
BRM Backhaul Resource Management
BS Base Station
BSG BSR Signaling Gateway
BSGPP BSG Paging Protocol
BSIC Base Station Signature
BSR Base Station Router
BVG BSR Voice Gateway
CAC Call Admission Control
CCPCH Common Control Physical Channel
CFN Connection Frame Number
CIO Cell Individual Offset
CM Compressed Mode
CN Core Network

CPE Customer Premises Equipment
CPICH Common Pilot Control Channel
CQI Channel Quality Indicator
CRC Cyclic Redundancy Check
CRS Cell Reselection
CS Circuit Switched
DAHO Data Base Assisted Handover
DBC Dynamic Bearer Control
DCH Dedicated Channel
DL DownLink
DPAT Dynamic Port Address Translation
DSL Digital Subscriber Line
E-AGCH Enhanced Access Grant Channel
E-DCH Enhanced DCH (also referred as HSUPA or EUL)
E-DPCCH Enhanced Dedicated Physical Control Channel
E-DPDCH Enhanced Dedicated Physical Data Channel
E-HICH Enhanced Hybrid ARQ Indicator Channel
ePLMN Equivalent Public Land Mobile Network
E-RGCH Enhanced Relative Grant Channel
E-TFC E-DCH Transport Format Combination
E-TFCI E-DCH Transport Format Combination Indicator
E-TFCS Enhanced Transport Format Combination Set
FACH Forward Access Channel
FDD Frequency Division Duplex
FGW Femto Gateway
FMS Femto Management Solution
FPUG Femto Parameter User Guide
GGSN Gateway GPRS Support Node
GMM GPRS MM
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
HARQ Hybrid ARQ
HCS Hierarchical Cell Structure

HLBS Highest priority Logical channel Buffer Status
HLID Highest priority Logical channel ID
HLR Home Location Register
HLS Higher Layer Scheduling
HMD High Mobility Detection algorithm
HO Handover
HSDPA High Speed Downlink Packet Access
HS-DSCH High Speed Downlink Shared CHannel
HSPA High Speed Packet Access
HSUPA High Speed Uplink Packet Access
HW Hardware
IE Information Element
IMSI International Mobile Station Identity
INIT Initiation
IP Internet Protocol
IPC Iu Protocol Converter
IPFPR IP Fingerprint function
ISP Internet Service Provider
IuCS UMTS Interface between 3G-MSC/SGSN and RNC for Circuit Switched Data
IuPS UMTS Interface between 3G-MSC/SGSN and RNC for Packet Switched Data
KPI Key Performance Indicator
LA Location Area
LAC Location Area Code
LAI Location Area Identity
LAU Location Area Update
LI Length Indicator
MAC Medium Access Control
MAC-hs Media Access Control - High Speed
MAHO Mobile Assisted handover
MCC Mobile Country Code
MIB Master Information Block
MM Mobility Message
MNC Mobile Network Code

MSC Mobile services Switching Center
NACK Negative Acknowledgment
NAS Non Access Stratum
NBAP NodeB Application Protocol
NSAPI Network layer Service Access Point Identifier
OAM Operation and Maintenance
OLPC Outer-Loop Power Control
PCA Power Control Algorithm
PCH Paging Channel
PDCP Packet Data Convergence Protocol
PDP Packet Data Protocol
PDU Packet Data Unit
PGM Probe Gap Method
PLMN Public Land Mobile Network
PO Power Offset
PQ Priority Queue
PS Packet Switched
PSC Primary Scrambling Code
P-TMSI Packet - Temporary Mobile Subscriber Identity
QAM Quadrature Amplitude Modulation
QoS Quality of Service
QPSK Quadrature Phase Shift Keying
RAB Radio Access Bearer
RAC Routing Area Code
RACH Random Access Channel
RAI Routing Area Identity
RANAP Radio Access Network Application Protocol
RAT Radio Access Technology
RAU Routing Area Update
RB Radio Bearer
RBGW Residential Broadband Gateway
RF Radio Frequency
RG Relative Grant

RLC Radio Link Control
RLS Radio Link Set
RNC Radio Network Controller
RoT Rise over Thermal
RRC Radio Resource Control
RRM Radio Resource Management
RSCP Received Signal Code Power
RSN Retrasnmission Sequence Number
RSSI Received Signal Strength Interference
RTWP Received Total Wideband Power
RV Redundancy Version
Rx Receive
SAC Service Area Code
SAI Service Area Identity
SCH Synchronization Channel
SCTP Stream Control Transmission Protocol
SF Spreading Factor
SFN System Frame Number
SGSN Serving GPRS Support Node
SHO Soft Handover
SI Scheduling Information
SIB System Information Block
SIM Subscriber Identify Module
SIR Signal to Interference Ratio
SNMP Simple Network Management Protocol
SPI Service Priority Indicator
SRB Signaling Radio Bearer
SW Software
TEBS Total E-DCH Buffer Status
TFC Transport Format Combination
TI Transaction Identifier
TMSI Temporary Mobile Subscriber Identity
TPR Traffic-To-Pilot Ratio

TSSI Transmit Signal Strength Indicator
TTL Time To Live
Tx Transmit
UE User Equipment
UL UpLink
UMTS Universal Mobile Telecommunication System
UPH UE Power Headroom
URAC UTRAN Registration Area Code
USIM UMTS Subscriber Identify Module
UTRA UMTS Terrestrial Radio Access
UTRAN Universal Terrestrial Radio Access Network
VIP Very Important Person
VPN Virtual Private Network
WiPS Wireless Provisioning System

Z END OF DOCUMENT Y


VOLUME 2 AUTOCONFIGURATION

Femto Parameter User Guide BCR3.0 .
CONTENT OF VOLUME 2
1. INTRODUCTION............................................................................................................................4
1.1. OBJECT....................................................................................................................................4

2.1. FPUG VOLUMES ......................................................................................................................4
2.4. STANDARDS DOCUMENTS .........................................................................................................5
3. AUTOCONFIGURATION / SELF-OPTIMIZATION .......................................................................6

3.1. BSR FREQUENCY .....................................................................................................................6
3.1.1 Frequency Parameters ...................................................................................................6
3.1.2 Dual band 850/1900........................................................................................................7
3.1.2.1 Frequency band...........................................................................................................7
3.1.2.2 3G & 2G Network listening ..........................................................................................8
3.1.3 Automatic Carrier Selection ..........................................................................................11
3.1.3.1 Feature Activation......................................................................................................12
3.1.3.2 Configuration Data.....................................................................................................12
3.1.3.3 Carrier Selection during Autoconfiguration ...............................................................16
3.1.3.4 Carrier Selection during Self-Optimisation ................................................................19
3.1.4 Initialisation ...................................................................................................................20
3.1.4.1 BSR Supported Operational Frequency....................................................................20
3.1.4.2 BSR Supported Sniffing Frequency ..........................................................................20
3.2. BSR PLMN ...........................................................................................................................21
3.3. BSR AREA CODES .................................................................................................................21
3.3.1 Parameters description .................................................................................................21
3.3.2 Configuration of LAC, SAC and RAC at FMS level ......................................................22
3.3.2.1 Manual Assignation ...................................................................................................22
3.3.2.2 Full Auto-Configuration..............................................................................................22
3.3.2.3 Random Assignation .................................................................................................23
3.3.3 Detection of collapsing LAI ...........................................................................................23
3.3.4 LAC and SAC to Differentiate the Billing ......................................................................25
3.3.5 Dynamic LAC/SAC allocation .......................................................................................29
3.3.5.1 Selecting the type of Macro.......................................................................................29
3.3.5.2 Selection of a 3G Macro Neighbor ............................................................................30
3.3.5.3 Selection of a 2G Macro Neighbor ............................................................................31
3.3.5.4 LAC and SAC configuration ......................................................................................32
3.3.6 Super LAC.....................................................................................................................38
3.3.6.1 alignment of LAC in LAI and SAI...............................................................................39
3.3.6.2 Location Reporting ....................................................................................................40
3.3.6.3 Restrictions................................................................................................................40
3.4. BSR SRNC ID........................................................................................................................41
3.5. PRIMARY SCRAMBLING CODE ..................................................................................................42
3.5.1 Manual/Auto-Configuration of PSC...............................................................................42
3.5.2 Automatic Auto-Configuration of PSC...........................................................................42

3.6. HARDWARE VERSION DEPENDENT PARAMETERS .....................................................................45
3.6.1 Maximum Number of users...........................................................................................45
3.6.2 Home BSR v1.2 ............................................................................................................45
3.6.3 Enterprise & Metro Cells BSR v2..................................................................................47
3.6.4 BSR V2-A......................................................................................................................48
3.6.5 BSR V2-EC-2S..............................................................................................................49
3.6.6 Reserved Channels for signalling .................................................................................49
3.7. SUPPORTED RAB COMBINATIONS ...........................................................................................50
3.8. FEMTO BSR GROUP SUPPORT ...............................................................................................52
3.8.1 General configuration....................................................................................................52
3.8.2 Enhanced PSC allocation .............................................................................................54
3.8.2.1 Feature description....................................................................................................54
3.8.2.2 PSC Clash detection .................................................................................................55
3.8.2.3 PSC Selection in the case of PSC Clashes ..............................................................56
3.8.3 Extended ACL for Femto Groups..................................................................................57
3.8.3.1 Objectives and Benefits.............................................................................................57
3.8.3.2 BSR Configuration.....................................................................................................57
3.8.3.3 FGW Configuration....................................................................................................57
3.8.3.4 IMSI Check ................................................................................................................58
3.9. LOCATION & MOVEMENT CHECK..............................................................................................59
3.9.1 Location Check .............................................................................................................60
3.9.1.1 2G RF Fingerprint test...............................................................................................62
3.9.2 Movement Check ..........................................................................................................65
3.9.2.3 MAC Address test......................................................................................................68
3.9.2.4 Trace Route test ........................................................................................................69
3.9.3 National Location Lock..................................................................................................69
3.9.3.1 IP Address Check......................................................................................................71
3.9.3.2 2G Macro Check for MCC .........................................................................................73
3.9.3.3 3G Macro Check for MCC .........................................................................................75
3.10. GPS LOCALIZATION FUNCTION ............................................................................................79
3.10.1 Overview .......................................................................................................................79
3.10.2 GPS-based Location Check..........................................................................................80
3.10.2.1 GPS-based Location Check ......................................................................................80
3.10.2.2 An Authorized and Unauthorized Location................................................................82
3.10.3 Non-GPS Location and Movement Check....................................................................85
3.10.4 Location based Services...............................................................................................86
3.11. NETWORK OVERLOAD AVOIDANCE ..........................................................................................87
3.11.1 Overview .......................................................................................................................87
3.11.2 Configuration.................................................................................................................87
3.11.2.1 Activation ...................................................................................................................87
3.11.2.2 Description.................................................................................................................87
3.12. UL BANDWIDTH OPTIMIZATION ................................................................................................89
3.12.1 Overview .......................................................................................................................89
3.12.2 Activation.......................................................................................................................89
3.12.3 Description ....................................................................................................................90
3.13. SPECIFIC BACKHAUL TYPES PARAMETERS ...............................................................................91
4. INDEXES .....................................................................................................................................92
4.1. TABLE INDEX ..........................................................................................................................92
4.2. FIGURE INDEX ........................................................................................................................92


1. INTRODUCTION
1.1. OBJECT
This volume is dedicated to features and parameters related to the auto-
configuration and self-optimization of BSRs.
2.1. FPUG VOLUMES


[Vol. 10] HSxPA

specification

reception (FDD)

specification

[3GPP_R14] 3GPP TS 25.444 Iuh data transport

[ALU. 1] NTP 411-8111-813 Access Network Parameters
[ALU. 2] BSR Femto Area Codes, Mark Skeates
2.4. STANDARDS DOCUMENTS

[S. 1] ITU-T Recommendation E.212: "The international
identification plan for mobile terminals and mobile users".
[S. 2] RFC2050, Internet Registry IP Allocation Guidelines, Nov
1996

3. AUTOCONFIGURATION / SELF-OPTIMIZATION
During the auto-configuration or while self-optimizing, the BSR will adapt its radio
parameters automatically to its environment based on parameters that are pre-
configured.
The processes running during these phase will allow the BSR to
Choose the best Primary Scrambling Code (Chapter 3.5) 27H X
Optionally choose the best frequency (Section 3.1.3) 28H
Choose the CPICH Power used to transmit ([Vol. 3]) X29H X
Generate 3G (UTRAN and BSR) and 2G Neighbourlists ([Vol. 5]) X230H X
The auto-configuration phase will happen at initial power on (first switch on and
subsequent) and after a power reset.
The self-optimization phase will happen during a non busy hour (also called “quiet
period”) that is determined automatically by the BSR itself.
Additionally, the BSR will adapt the CPICH power to

Keep the Received Power at the UE in its Receiver Range ([Vol. 3]) X231H X
Ensure good service and interference limitation ([Vol. 3]) X23H X
These processes rely on the UE measurements and are running continuously

during calls.
3.1. BSR FREQUENCY
3.1.1 FREQUENCY PARAMETERS

The UMTS frequency the BSR will transmit on is defined with the parameters
LCell::freqBand, LCell::uARFCND and LCell::uARFCNU.
Inter-Release Delta: Automatic Carrier Selection
From BSR Cluster Release (BCR) 3.0 onwards, the Automatic Carrier Selection feature allows the
BSR to select its frequency automatically.
These parameters can either be configured
¾ manually (acsCarrierSelectionMode = ‘ACSOFF’)

¾ or automatically (when feature Automatic Carrier Selection feature
(76985)) see 3.1.3.23H

Parameter freqBand
Object Lcell
Granularity BSR Location Profile
Range & Unit Enumerated
{fdd2100=1, fdd1900=2, fdd1800=3, bandIV=4,
bandV=5, bandVI=6, bandVII=7, bandVIII=8,
bandIX=9, bandX=10, bandXI=11, bandXII=12,
bandXIII=13, bandXIV=14, noBand=99}
Class Class 3
Value 1
Rule: LCell::freqBand
When Dual Band is activated, LCell::freqBand must contain frequencies from dual band
combination.
Parameter uARFCNu
Object Lcell
Range & Unit Integer
[0..16383]
Class Class 3
Value -
Parameter uARFCNd
Object Lcell
[0..16383]
Class Class 3
Value -
3.1.2 DUAL BAND 850/1900
Restriction: Hardware dependency
Hardware and platform must support dual UMTS 1900 and 850 bands and GSM1900 and GSM850
bands. (v2 Hardware Architecture – 1900/850 HW BSR).
3.1.2.1 FREQUENCY BAND

The BSR can transmit and receive in one of the following frequency bands
(850/1900) at any time:

• Band II: 1850 – 1910 MHz (Uplink) & 1930 – 1990 MHz (Downlink).
• Band V: 824 – 849 MHz (Uplink) & 869 – 894 MHz (Downlink).
BSRs can be deployed in the same area with different frequency bands. But, BSRs
belonging to the same group must transmit on the same frequency band.
During the initialization, the BSR will determine if the underlying hardware supports
the configured band for the BSR.
This feature is enabled through the parameter dualModeBandIIandVEnable.
From BCR 3.0 onwards, the BSR can transmit and receive in one of the following
frequency bands (850/2100) at any time:
• Band I: 1920 – 1980 MHz (Uplink) & 2110 – 2170 MHz (Downlink).
• Band V: 824 – 849 MHz (Uplink) & 869 – 894 (Downlink).
Parameter dualModeBandIIandVEnable |
Object Femto | BSR
Granularity Femto | BSR
Range & Unit Boolean
{True, False}
Class Class 3
Value FALSE
Rule: Dual band
To enable dual bands, 2 bands in combination of supported dual bands must be configured in:
• macroUMTSFrequencyList ;
• umtsNatLocLockFrequency;
• gsmFrequencyList;
• gsmNatLocLockFrequency
If dual band is enabled, then freqBand contains only bands from dual band combination and
fddExtCell and gsmExtCell contain only frequencies from supported dual bands.
3.1.2.2 3G & 2G NETWORK LISTENING

The feature 78691 introduces a multi-frequency open search algorithm. It will
perform a deep search over all frequencies and bands before the algorithm is
terminated. This new search can be activated through the parameters
umtsNtkLMultiFreqOpenSearchEnable and umtsOpenSearchEnableFlag.

Engineering Recommendation: 3G Network Listening
It is strongly recommended that umtsNtkLMultiFreqOpenSearchEnable is set to either

autoConfig or autoConfigAndSelfOpt and umtsOpenSearchEnableFlag = True when the dual
band operation is enabled.
Parameter umtsNtkLMultiFreqOpenSearchEnable
Object BSR Profile
Granularity BSR Profile
{disable=0, autoConfig=1, autoConfigAndSelfOpt=2}
Class Class 3
Value disable
If umtsNtkLMultiFreqOpenSearchEnable is set to autoConfig or

autoConfigAndSelfOpt, the BSR searches over all the configured 3G macro
frequencies up to
• Either a configurable time (umtsNtkLMultiFreqOpenSearchTime)
• Or umtsNtkLMultiFreqOpenSearchCellNumber, the number of suitable
cells found and macro neighbours via SIB11 (System Information Block 11)
from the strongest cells in each band decoded before terminating the
search.
When the handover (HO) to 3G is triggered, the parameter umtsPreferredBand

determines in which band the target 3G macro cell is chosen. If it is set to noBand,
the BSR will choose the strongest 3G macro cell. If a band is configured, the BSR
will choose the strongest 3G macro cell in this band.
Parameter umtsNtkLMultiFreqOpenSearchTime
Object BSR Profile
Range & Unit integer (secs)
[1..180]
Class Class 3
Value 10
Parameter umtsNtkLMultiFreqOpenSearchCellNumber
Object BSR Profile
[0…65535]
Class Class 3
Value 4

Parameter umtsPreferredBand
Object LCELL
Class Class 3
Value -
Rule: umtsPreferredBand
umtsPreferredBand must be one of the bands configured in macroUMTSFrequencyList or

‘noBand’ even if the feature 78691 is not activated.
An additional field is added to the 3G/2G detected list which indicates a time to live,
TTL, for every macro cell.
ntkCellLiveThreshold determines how long (determined by the number of
network listening attempts) a zero strength cell (i.e. a cell that has already been
detected at least one time but it is not detected anymore) remains in the 2G and
3G detected cells lists.
Parameter ntkLCellLiveThreshold
Object BSR Profile
Range & Unit integer
[0..255]
Class Class 3
Value 5
The feature 78691 enhances the 2G open search, to allow a multi-frequency open
search. This will sort the cells per band and take the strongest from both bands to
decode, add and check their SIB2 broadcasts. It is enabled through the parameters
gsmNtkLMultiFreqOpenSearchEnable and allowedGSMOpenSearch.
When the handover to 2G is triggered, the parameter gsmPreferredBand
determines in which band the target 2G macro cell is chosen. If it is set to noBand,
the BSR will choose the strongest 2G macro cell. If a band is configured, the BSR
will choose the strongest 2G macro cell in this band.
Engineering Recommendation: 2G Network Listening
It is strongly recommended that this open search is activated if the dual band operation is enabled.
In consequences, gsmNtkLMultiFreqOpenSearchEnable should be set to autoConfig or
autoConfigAndSelfOpt and allowedGSMOpenSearch should be set to true.

Parameter gsmNtkLMultiFreqOpenSearchEnable
Object BSR Profile
{disable=0, autoConfig=1, autoConfigAndSelfOpt=2}
Class Class 3
Value -
Parameter gsmPreferredBand
Object LCELL
{gSM450=0, gSM480=1, gSM850=2, gSM900=3,
gSM900E=4, gSM1800=5, gSM1900=6, noBand=99}
Class Class 3
Value -
Rule: gsmPreferredBand
gsmPreferredBand must be one of the bands configured in gsmFrequencyList or ‘noBand’ even

if the feature 78691 is not activated.
3.1.3 AUTOMATIC CARRIER SELECTION
Inter-Release Delta: Automatic Carrier Selection
From BCR 3.0 onwards, the Automatic Carrier Selection feature allows the BSR to select its
frequency automatically.
The Automatic Carrier Selection feature (76985) allows a standalone BSR to select
its carrier automatically and is part of the autoconfiguration/self-optimizations
processes. It also provides with improvements in the choice of the Primary
Scrambling Code (PSC).
It is intended for Residential deployments and gives operators the ability to deploy
more easily BSRs in areas where the carrier to use depend on the location.
The carrier selection is based on the 3G macro cell neighbours and dependent of
the network listening functionalities.

Restriction: Groups of Enterprise /Metro Small Cells
Feature 76985 is not supported in the case Small Cells Customer Premises Equipments (CPEs)
are grouped.
Restriction: Hardware Support
Feature 76985 is supported on V2 hardware onwards.
Rule: Macro Provisioning
When using the Feature 76985, it is mandatory to ensure that the mobility relations are correctly
set at macro level. For instance, one neighbour per PSC and per Band is to be declared for Cell
Reselection (CRS) or incoming HO.
3.1.3.1 FEATURE ACTIVATION

ACS is activated through the parameter acsCarrierSelectionMode, which can
take following values:
• ACSOFF: The feature is disabled. The parameters have to be configured
manually (see 3.1). 234H
• ACSMACROSTATIC: The feature is only enabled during the

Autoconfiguration phase.
• ACSMACRODYNAMIC: The feature is enabled during the
Autoconfiguration/Self-Optimisation.
Parameter acsCarrierSelectionMode
Object Lcell
Range & Unit Enum
{acsOff=0, acsMacroStatic=1, acsMacroDynamic=2,
acsTrafficDynamic=3}
Class Class 3
Value acsOff
3.1.3.2 CONFIGURATION DATA

For each Macro carrier potentially present in the radio environment of a given BSR,
an operator specifies the BSR carriers allowed.
A matrix mapping the potential Macro carriers into the list of allowed BSR carriers
is defined. The BSR checking its radio environment will detect which of the
potential Macro carriers are in operation. For the case, that no carrier is found, a
mapping is also provided.

The Macro carriers that are to be scanned are provisioned through the parameter
structure acsPotentialMacroCarriers. Each carrier is defined with the following
parameters:
• freqBand;
• uARFCNDL;
• uARFCNUL.
Parameter freqBand
Object acsPotentialMacroCarriers
Granularity acsPotentialMacroCarriers
Class Class 3
Value -
Parameter uARFCNDL
[0..16383]
Class Class 3
Value -
Parameter uARFCNUL
[0..16383]
Class Class 3
Value -
Rule: acsPotentialMacroCarriers
The maximum size of the acsPotentialMacroCarriers is 8 entries.
The carriers which can be considered by the BSR are defined through
acsAllowedFemtoCarriers. This list contains the following information for each
carrier:
• freqBand;

• uARFCNUL;
• uARFCNDL;
• pscListString.
The feature allows an operator to also define separate PSC lists to be used on a
per carrier basis.
Parameter freqBand
Object acsAllowedFemtoCarriers
Granularity acsAllowedFemtoCarriers
Class Class 3
Value -
Parameter uARFCNUL
[0..16383]
Class Class 3
Value -
Parameter uARFCNDL
[0..16383]
Class Class 3
Value -
Parameter pscListString
Range & Unit Comma separated list of PSC bolonging to [0…511]
Class Class 3
Value '

Rule: acsAllowedFemtoCarriers
The maximum size of the acsAllowedFemtoCarriers is 8 entries.

At least 1 entry must be defined if acsCarrierSelectionMode is not set to ACSOFF.
The mapping tables are provided through the parameters

acsMappingMacroCarrierToAllowedFemtoCarrier and
acsMappingNoMacroToAllowedFemtoCarrier.
For each carrier with macro cells detected the allowed FBSR carriers are
provisonned in acsMappingMacroCarrierToAllowedFemtoCarrier. Table 1 235H
provides with an example of a mapping table.
Allowed Femto Carriers

Potential Macro Carriers
List of
acsAllowedFemtoCarriers
AcsPotentialMacroCarrier AFC-1 AFC-2 AFC-3 AFC-4
PMC-1 9 9
Mapping Table:
PMC-2 9
AcsMappingMacroCarrierTo
PMC-3 9 9
AllowedFemtoCarrier
PMC-4 9
Table 1 - Mapping tables
In the case no Macro carrier is detected, a kind of fallback BSR Carrier list can be
provisioned through acsMappingNoMacroToAllowedFemtoCarrier.
Parameter acsMappingMacroCarrierToAllowedFemtoCarrier
Object Lcell
Range & Unit String
[Maxlength 155]
Class Class 3
Value -
Note: The format of acsMappingMacroCarrierToAllowedFemtoCarrier will be

"entry number (ID value) in <LCell::acsPotentialMacroCarriers>:comma separated
entry number (ID value) in <LCell::acsAllowedFemtoCarriers>;" For example
"1:1,2,3,4;2:1,2,4"

Parameter acsMappingNoMacroToAllowedFemtoCarrier
Object Lcell
Range & Unit String
[Maxlength 32]
Class Class 3
Value -
Note: The format will be - "0:comma separated entry number (ID value) in
<LCell::acsAllowedFemtoCarriers>" For example "0:1,2,3,4"
A mapping mode acsMappingMode defines how the final set of selectable Femto
carriers is determined in case multiple Macro carriers are detected. There are three
modes:
• bestMacrocell: Only the 3G macro cell with the highest CPICH RSCP
(Received Signal Code Power) is used to provide the list of selectable BSR
carriers.
• allDetected: All 3G macro cells are used to provide the list of selectable
Femto carriers.
• allDetectedExclusive: All 3G macro cells are used but the list of selectable
Femto carriers must not include any macro carriers detected.
Parameter acsMappingMode
Object Lcell
Range & Unit Enum
{bestMacrocell=0, allDetected=1,
allDetectedExclusive=2}
Class Class 3
Value bestMacrocell
Rule: Dedicated carrier deployment
For dedicated carrier deployment, acsMappingMode must be set to allDetectedExclusive.
3.1.3.3 CARRIER SELECTION DURING AUTOCONFIGURATION

The carrier selection makes use of the BSR’s network listening functionality.
This is used for three tasks:
1. Looking for macro cells (Macro cell detection).
2. Selecting the Femto carrier out of a list of candidates.
3. Selecting PSC for the selected Femto carrier.

MACRO CELL DETECTION
The BSR processes the carriers given in the AcsPotentialMacroCarriers list.

It checks for each one if there are one or more cells detectable on this carrier using
network listening.
Engineering Recommendation: umtsOpenCarrierMacroSearchEnableFlag
Standard sniffing ends when a predefined number of Macro cells are detected and is therefore
faster.
In the ACS process, when umtsOpenCarrierMacroSearchEnableFlag = True, the BSR scans all
the possible PSCs for the carriers defined. This can take a long time and delay the end of the
sniffing period.
The parameter umtsOpenCarrierMacroSearchEnableFlag when set to false, allows to only use

the results of standard sniffing.
Restriction: umtsOpenCarrierMacroSearchEnableFlag
In BCR3.0, umtsOpenCarrierMacroSearchEnableFlag must remain set as per default to false.
Parameter umtsOpenCarrierMacroSearchEnableFlag
Object Lcell
{True, False}
Class Class 3
Value False
In case the AcsPotentialMacroCarriers list is empty, no check on macro

neighbour cells is done (for this feature).
The outputs of this listening phase are:
• A list of macro cells detected;
• For each detected macro cell:
o Primary Scrambling Code;
o CPICH RSCP;
o Public Land Mobile Network (PLMN) Id.
Only Macro cells with valid PLMN Ids are considered.
Based on the results of this listening phase, on the Mapping tables (3.1.3.2) and 236H
acsMappingMode information, the list of selectable BSR carriers is generated.

BSR CARRIER SELECTION
If the list of selectable BSR carriers is empty, a major alarm is generated to the
FMS. In this case the BSR will not become operational.
If the list of selectable BSR carriers contains just one element, it will be the
selected carrier.
In case the list of selectable BSR carriers comprises more than one element, the
list is passed to the network listening functionality to provide information about
“interference” on these carriers.
The BSR ranks the carriers according to “interference”.
The “least interfered” carrier is finally selected.
As criterion for “interference” the sum of all CPICH RSCP for all cells on each
selectable carrier is used. Depending on the setting of
acsFemtoCarrierComparisonMode different neighbour cells can be considered.
• ‘femtoOnly’: only the BSR neighbour cells are considered
• ‘macroDb’: all BSR neighbours and already detected Macro are
considered.
• ‘macroSearch’: all BSR neighbours, already detected macro cells and
newly detected ones (after a new opensearch) are considered.
Restriction: acsFemtoCarrierComparisonMode
In BCR3.0, acsFemtoCarrierComparisonMode must remain set, as per default, to ‘femtoOnly’.
Parameter acsFemtoCarrierComparisonMode
Object Lcell
Range & Unit Enum
{femtoOnly=0, macroDb=1, macroSearch=2}
Class Class 3
Value femtoOnly
PSC SELECTION
The PSC to be used by the BSR if then determined based on the list which has
been defined for the selected carrier, relying on existing PSC slection methods

3.1.3.4 CARRIER SELECTION DURING SELF-OPTIMISATION
The “ACS/macro based, dynamic” procedure is triggered periodically as part of the
self-optimisation if AcsCarrierSelectionMode is set to ‘ACSMACRODYNAMIC’.
The procedure is the same as the one used during the autoconfiguration, except
for the ranking of the BSR carriers based on their ‘interference’.
Indeed, to avoid carrier ping-ponging, Hysteresis have been introduced and the
results of the ‘interference based’ ranking process presented in 3.1.3.3 will be 237H
corrected as specified in Formula 1.

238H
If the “least interfered” carrier [Ca] differs from the carrier currently in use [Cb]
and
“interference level” of [Ca] < “interference level” of [Cb] - acsHystCPICHactive

Then Carrier [Ca] will be the selected carrier for the Femto BSR.
Else stay with the currently used carrier (b).
Formula 1 – Carrier Change condition in Self-Optimisation Phase
Parameter acsHystCPICHactive
Object Lcell
Class Class 3
Value 10
A further difference between self-optimization and auto-configuration is that instead

of critical alarms, minor alarms are raised, and operation continues on previously
selected carrier.

3.1.4 INITIALISATION
3.1.4.1 BSR SUPPORTED OPERATIONAL FREQUENCY

At initialisation, following power on or reset, the BSR determines from the hardware
platform the supported UMTS bands. Depending of its capabilities and
configuration, it will decide either to go in service or not.
If the configured band, (LCELL::freqBand) is not supported then the BSR does
not enter operation and raises a critical alarm, BSR::umtsBandNotSupported
with the band not supported contained in the description field.
If 1900/850MHz dual band operation is enabled,

BSR::DualModeBandIIandVEnable = TRUE then only if UMTS bands II & V and
GSM850 and GSM1900 are supported the BSR enters service.
If none are supported or not operational then the BSR does not enter operation
and raise a critical alarm, BSR::umtsBandNotSupported and/or
BSR::gsmBandNotSupported with the bands not supported contained in the
description field.
3.1.4.2 BSR SUPPORTED SNIFFING FREQUENCY

During BSR initialisation, following power on or reset, the BSR determines from the
hardware platform the supported UMTS and GSM bands.
If BSR::continueServiceIfBandsNotSupported = False, the BSR enters into
service only if the UMTS bands configured in
LCELL::macroUMTSCellFrequencyList are supported by the hardware. A critical
Alarm BSR::umtsBandNotSupported is raised with the bands not supported.
If BSR::continueServiceIfBandsNotSupported = True and UMTS bands
configured in LCELL::macroUMTSCellFrequencyList not supported by the
hardware, the BSR supports following procedures:
¾ Ignore unsupported bands in the LCELL::macroUMTSCellFrequencyList
during various network listening operations and enter into service.
¾ Log the error with description containing band not supported.
Parameter continueServiceIfBandsNotSupported |
Object BSR Profile | BSR
Granularity BSR Profile | BSR
{True, False}
Class Class 3
Value FALSE

3.2. BSR PLMN

The BSR MNC and MCC are provided through the parameters ownPLMNMNC,
ownPLMNMCC, These parameters will then be used by other features such as the
enhanced ePLMN support feature.
Parameter ownPLMNMCC
Object Lcell
Range & Unit String
Class Class 0
Value -
Parameter ownPLMNMNC
Object Lcell
Range & Unit String
Class Class 0
Value -
3.3. BSR AREA CODES
3.3.1 PARAMETERS DESCRIPTION

The BSR LAC, RAC, SAC and URAC (UTRAN Registration Area Code) are
configured through the parameters laLAC, raRAC, saSAC and uraURAC.
Parameter locationAreaCode | laLAC

Object Femto | Lcell
[1..65535]
Class Class 0
Value -
Parameter routingAreaCode | raRAC

[0..255]
Class Class 0
Value -

Parameter uraURAC
Object Lcell
[1..65534]
Class Class 0
Value -
Parameter serviceAreaCode | saSAC

[0..65535]
Class Class 0
Value -
3.3.2 CONFIGURATION OF LAC, SAC AND RAC AT FMS LEVEL

The BSR system offers different means to configure the Area Codes of BSRs:
¾ Manual Assignation
¾ Full Automatic configuration

¾ Random Assignment
Engineering Recommendation: Area Codes
Engineering Guidelines on the planning of Area Codes can be found in [ALU. 2]. X239H X
3.3.2.1 MANUAL ASSIGNATION

The operator has the possibility to manually assign the LAC.
3.3.2.2 FULL AUTO-CONFIGURATION

In the case the LAC is not set manually, The FMS will automatically assign the
LAC using the BSR geographical coordinates, a set of LAcs and a provisioned
location grid as depicted in Figure 1. X240H X
This functionality requires that the geographical coordinates of the different BSRs
are known and configured in the FMS.

Lac Lac Lac Lac Lac Lac

range range range range range range





Figure 1 - Automatic LAC Configuration
3.3.2.3 RANDOM ASSIGNATION

If the LAC is not set and the geographical coordinates are not available, the FMS
can assign randomly the LAC for the BSR. The FMS chooses the LAC from a list of
possible Random LACs defined by the operator.
3.3.3 DETECTION OF COLLAPSING LAI

During the Auto-configuration, when sniffing the RF environment, the BSR will
generate an alarm if it detects a neighbouring BSR having the same Location Area
Identity (LAI). Figure 2 present an overview of this functionality.
X241H X
This rule is not applied in the case the detected BSR belongs to the same BSR
Group.
This feature is from particular interest in the case no geographical coordinates are
available for the BSRs.
Following the alarm notification at the FMS, the operator can assign another LAC
manually.
With this alarm the operator will be able to detect collapsing LAI which could lead
to missed call in case of high dense BSR deployment or bad end-user perception.

FMS
HNM WMS
TR.69
Alarm
retrieved
SIB1
3G Network listening
function
BSR 1
BSR 2
LAI1 autoconfigured with LAI1
Figure 2 - Collapsing LAI Detection

3.3.4 LAC AND SAC TO DIFFERENTIATE THE BILLING

The BSR has the ability to distinguish between “owner” and “guest” (see [Vol. 5] for X24H X
more information on the Access Mode used in the BSR) to select the appropriate
LAC and SAC to send to the Core Network (CN) to enable differentiated charging
for these two categories of UE.
Additionally, the BSR offers the configurability of the Location Information, LAC and
SAC, for Emergency Calls. In this case the categorization owner/guest is not
applicable anymore.
The BSR provides configurability for the population of the LAC and SAC in the
Service Area Identity (SAI), which is used by the core network for e.g. billing.
The BSR will set the LAC and SAC in the SAI IE based on the based on following
rules:
The parameter LCell::areaSelectNormalFlag selects whether LAC or SAC within

the SAI is used to distinguish between owner and guest for normal, non-
emergency calls. Setting it to ‘off’ disables the conditional setting of LAC or SAC.
Table 2 presents the different possible configurations for LAC and SAC for BSR in
X243H X
Closed Access Mode.
LCell::areaSelectNormalFlag laLAC saSAC
‘off’ laLAC saSAC
‘lac’ laLAC1 for owner calls saSAC

laLAC2 for guest calls
‘sac’ laLAC saSAC1 for owner calls

saSAC2 for guest calls.
‘lacAndSac’ laLAC1 for owner calls saSAC1 for owner calls

laLAC2 for guest calls saSAC2 for guest calls.
Table 2- SAI-LAC and SAI-SAC for normal calls / BSR in Closed Access Mode
In the case the BSR is configured in Open Access Mode, every UE attempting a
call over the BSR will be treated as being an ‘public’. Table 3 presents the different
X24H X
configurations for LAC and SAC for BSR in Open Access Mode.
off laLAC saSAC
lac laLAC4 saSAC

sac laLAC saSAC4
lacAndSac laLAC4 saSAC4
Table 3 - SAI-LAC and SAI-SAC for normal calls / BSR in Open Access Mode
In the case the BSR is configured in Semi Open Access Mode, Table 4 presents X245H X
the different configurations for LAC and SAC used for the different types of users.
‘lac’ laLAC1 for owner calls saSAC

laLAC2 for guest calls
laLAC4 for public calls
‘sac’ laLAC saSAC1 for owner calls

saSAC2 for guest calls
saSAC 4 for public calls
‘lacAndSac’ laLAC1 for owner calls saSAC1 for owner calls

laLAC2 for guest calls saSAC2 for guest calls
laLAC4 for public calls saSAC 4 for public calls
Table 4 - SAI-LAC and SAI-SAC for normal calls / BSR in Semi Open Access Mode
The parameter LCell::areaSelectEmergencyFlag selects which LAC and/or SAC

within the SAI is used for an emergency call. Table 5 presents the different
X246H X
possible configurations for LAC and SAC for BSR in Closed Access Mode.
The SAI is particularly important in the case of Emergency Calls for routing to the
appropriate Emergency call centre and may need to represent a geographic
location. For normal calls the SAI may be used for billing differentiation.
LCell::areaSelectEmergencyFlag laLAC saSAC
‘lac’ laLAC3 saSAC
‘sac’ laLAC saSAC3
‘lacAndSac’ laLAC3 saSAC3
Table 5 - SAI-LAC and SAI-SAC for emergency calls
The parameter areaSelectFemto allows to force the LAC and SAC IEs in the SAI
IE, when in the Initial UE, Direct Transfer, or Location Report Message. Indeed,
setting this parameter to the value codex, where X is {1, 2, 3, 4} will result in the

replacement of laLAC and saSAC with the corresponding values of laLACX and
saSACX.
Parameter areaSelectNormalFlag
Object Lcell
Range & Unit enum
{'off', 'lac', 'sac', 'lacandsac'}
Class Class 3
Value off
Parameter areaSelectEmergencyFlag
Object Lcell
Range & Unit enum
{'off', 'lac', 'sac', 'lacandsac'}
Class Class 3
Value off
Parameter serviceAreaCode1 | saSAC1

[0..65535]
Class Class 3
Value -
Parameter locationAreaCode1 | laLAC1

[0..65535]
Class Class 3
Value -

[0..65535]
Class Class 3
Value -

[0..65535]
Class Class 3
Value -

[0..65535]
Class Class 3
Value -

[0..65535]
Class Class 3
Value -

Granularity Femto | Lcell
[0..65535]
Class Class 3
Value -

Granularity Femto | Lcell
[0..65535]
Class Class 3
Value -
Parameter areaSelectFemto
Object Lcell
Range & Unit enum
{off=0, code1=1, code2=2, code3=3, code4=4}
Class Class 3
Value off

3.3.5 DYNAMIC LAC/SAC ALLOCATION
The purpose of the dynamic LAC/SAC allocation is to configure the SAI for the
BSR, owner, guests and emergency calls based on system information broadcast
of the best neighbor macro cell if available. It can be used to provide geographical
representations of the BSRs, which can be particularly useful for emergency call
routing.
In the case no macro cell is available or could be sniffed, the SAI will be set as
though the feature is deactivated and an alarm raised.
This feature is an extension of the ‘Home tariff and visitors’ access differentiated
support feature.
The Dynamic LAC/SAC allocation is activated setting the parameter
dynamicSACLACAllocation to TRUE.
3.3.5.1 SELECTING THE TYPE OF MACRO

When this feature is activated, the BSR decode the LAC and the Cell ID sniffing
the macro cell information. The type of macro neighbor cell that is to be
considered, is configured using the parameter dynamicSACLACmacroConfig
and presented in Table 6.
X247H X
dynamicSACLACmacroConfig Macro neighbor to consider
fdd Only 3G cells
gsm Only 2G cells
fddPreferred 3G cells
If no suitable, 2G cells
gsmPreferred 2G cells
If no suitable, 3G cells
Table 6 - Macro Cell to Sniff
Parameter dynamicSACLACAllocation |
Object Femto | BSR
{True, False}
Class Class 3
Value FALSE

Parameter dynamicSACLACmacroConfig
Object BSR Profile
{disable, gsm, fdd, gsmPreferred, fddPreferred}
Class Class 3
Value fdd
3.3.5.2 SELECTION OF A 3G MACRO NEIGHBOR

In the case the LAC and CellID are to be obtained from a 3G macro neighbor, the
following selection criteria are to be fulfilled.
In the case samePLMNforDynamicLACSAC is set to TRUE, the BSR will check
the PLMN of the strongest neighbor among the 3G macro that were sniffed and
which System Information were decoded. If it matches the BSR PLMN and the
Radio criteria presented in Table 7, the Macro will be selected.
X248H X
In the case samePLMNforDynamicLACSAC is set to FALSE, only the Radio

criteria will be used for the selection of the cell among the 3G macro that were
sniffed and which System Information were decoded.
macroCellMeasurementQuantity 3G Radio Criteria
CPICH RSCP CPICH RSCP ≥ dSAthresholdRSCP
CPICH EcNo CPICH EcNo ≥ dSAthresholdEcNo
Table 7 - 3G Radio Criteria
Rule: Dual Band 850/1900
When the feature Dual Band 850/1900 is activated, the parameter LCell::umtsPreferredBand
determines how the 3G macro is chosen. If it is set to noband, the BSR will select the strongest 3G
macro cell, if a band is configured the BSR will select the strongest 3G macro cell in this band. If no
3G macro cell is detected in the configured band, the default procedure is applied.
Parameter dSAthresholdRSCP
Object Lcell
Range & Unit Integer (dBm)
[-115..-25]
Class Class 3
Value -110

Parameter dSAthresholdEcNo
Object Lcell
Range & Unit Integer (dB)
[-24..0]
Class Class 3
Value -15
Parameter samePLMNDynamicLACSAC
Object Lcell
{True, False}
Class Class 3
Value FALSE
3.3.5.3 SELECTION OF A 2G MACRO NEIGHBOR

In the case the LAC and CellID are to be obtained from a 2G macro neighbor, the
following selection criteria are to be fulfilled.
In the case samePLMNforDynamicLACSAC is set to TRUE, the BSR will check

the PLMN of the strongest neighbor among the 2G macro that were sniffed and
which System Information were decoded. If it matches the BSR PLMN and the
Radio criteria presented in Table 8, the Macro will be selected.
X249H X
In the case samePLMNforDynamicLACSAC is set to FALSE, only the Radio

criteria will be used for the selection of the cell among the 2G macro that were
sniffed and which System Information were decoded..
2G Radio Criteria
BCCH RSSI ≥ dSAthresholdRXLEV2G
Table 8 - 2G Radio Criteria
Rule: Dual Band 850/1900
When the feature Dual Band 850/1900 is activated, the parameter LCell::gsmPreferredBand
determines how the 2G macro is chosen. If it is set to noband, the BSR will select the strongest 2G
macro cell, if a band is configured the BSR will select the strongest 2G macro cell in this band. If no
2G macro cell is detected in the configured band, the default procedure is applied.

Parameter dSAthresholdRXLEV2G
Object Lcell
[-110..-48]
Class Class 3
Value -110
3.3.5.4 LAC AND SAC CONFIGURATION

The BSR will update the SAC and LAC in the SAI IE in the RANAP messages
according to:
¾ Table 9 for non-emergency calls and BSR in Closed Access Mode
X250H X
¾ Table 10 for non-emergency calls and BSR in Open Access Mode

X251H X
¾ Table 11 for emergency-calls

X25H X
¾ Table 12 for non-emergency calls and BSR in Semi Opened Access Mode
X253H X
Note: Macro LAC and Macro CellID meaning either 3G Macro or 2G Macro
U U
depending on the configuration.
If a Macro Cell for dynamic LAC-SAC allocation has been identified, the BSR can
populate the SAC and LAC in the SAI IE in Location Report RANAP message with
the SAC/LAC or Macro CellID/ Macro LAC as described in Table 13 irrespectively X254H X
of the Access Mode. The choice is steered using the parameters

enableDynamicSACfemto and enableDynamicLACfemto.

LCell:: laLAC saSAC

areaSelectNormalFlag
‘lac’ saSAC
enableDynamicLACowner OwnerlaLAC
FALSE laLAC1
TRUE Macro LAC
enableDynamicLACguest GuestlaLAC
FALSE laLAC2
TRUE Macro LAC
‘sac’ laLAC
enableDynamicSACowner OwnersaSAC
FALSE saSAC1
TRUE Macro CellId
enableDynamicSACguest GuestsaSAC
FALSE saSAC2
TRUE Macro CellId
‘lacAndSac’
enableDynamicLACowner OwnerlaLAC enableDynamicSACowner OwnersaSAC
FALSE laLAC1 FALSE saSAC1
TRUE Macro LAC TRUE Macro CellId
enableDynamicLACguest GuestlaLAC enableDynamicSACguest GuestsaSAC

Table 9 - SAI-LAC and SAI-SAC for normal calls / BSR in Closed Access Mode

LCell::areaSelectNormalF laLAC saSAC

lag
off laLAC saSAC
lac saSAC
enableDynamicLACpu PubliclaLA
blic C
FALSE laLAC4
TRUE Macro LAC
sac laLAC
enableDynamicSACpubli PublicsaSA
c C
FALSE saSAC4
TRUE Macro
CellId
lacAndSac
enableDynamicLACpu PubliclaLA enableDynamicSACpubli PublicsaSA
blic C c C
TRUE Macro LAC TRUE Macro
CellId
Table 10 - SAI-LAC and SAI-SAC for normal calls / BSR in Open Access Mode
LCell:: laLAC saSAC

areaSelectEmergencyFlag
‘lac’ saSAC
enableDynamicLACEC laLAC
FALSE laLAC3
TRUE Macro LAC
‘sac’ laLAC
enableDynamicSACEC saSAC
FALSE saSAC3
TRUE Macro CellId
‘lacAndSac’
enableDynamicLACEC laLAC enableDynamicSACEC saSAC
Table 11 - SAI-LAC and SAI-SAC for emergency calls

LCell:: laLAC saSAC

areaSelectNormalFlag
‘lac’ saSAC
enableDynamicLACowner OwnerlaLAC
FALSE laLAC1
TRUE Macro LAC
enableDynamicLACguest GuestlaLAC
FALSE laLAC2
TRUE Macro LAC
enableDynamicLACpublic PubliclaLAC
FALSE laLAC4
TRUE Macro LAC
‘sac’ laLAC
enableDynamicSACowner OwnersaSAC
FALSE saSAC1
TRUE Macro CellId
enableDynamicSACguest GuestsaSAC
FALSE saSAC2
TRUE Macro CellId
enableDynamicSACpublic PublicsaSAC
FALSE saSAC4
TRUE Macro CellId
‘lacAndSac’
enableDynamicLACowner OwnerlaLAC enableDynamicSACowner OwnersaSAC
enableDynamicLACguest GuestlaLAC enableDynamicSACguest GuestsaSAC

enableDynamicLACpublic PubliclaLAC enableDynamicSACpublic PublicsaSAC

Table 12 - SAI-LAC and SAI-SAC for normal calls / BSR in Semi Open Access Mode

enableDynamicSACfemto enableDynamicLACfemto laLAC saSAC
FALSE FALSE laLAC saSAC
TRUE FALSE Macro LAC saSAC
FALSE TRUE laLAC Macro CellId
TRUE TRUE Macro LAC Macro CellId
Table 13 - SAI-LAC and SAI-SAC in the SAI IE in Location Report RANAP message
Parameter enableDynamicSACowner
Object Lcell
{True, False}
Class Class 3
Value FALSE
Parameter enableDynamicSACguest
Object Lcell
{True, False}
Class Class 3
Value FALSE
Parameter enableDynamicSACEC
Object Lcell
{True, False}
Class Class 3
Value FALSE
Parameter enableDynamicSACfemto
Object Lcell
{True, False}
Class Class 3
Value FALSE

Parameter enableDynamicSACpublic
Object Lcell
{True, False}
Class Class 3
Value FALSE
Parameter enableDynamicLACowner
Object Lcell
{True, False}
Class Class 3
Value FALSE
Parameter enableDynamicLACguest
Object Lcell
{True, False}
Class Class 3
Value FALSE
Parameter enableDynamicLACEC
Object Lcell
{True, False}
Class Class 3
Value FALSE
Parameter enableDynamicLACfemto
Object Lcell
{True, False}
Class Class 3
Value FALSE
Parameter enableDynamicLACpublic
Object Lcell
{True, False}
Class Class 3
Value FALSE

3.3.6 SUPER LAC

This feature introduces a differentiation between the LAC that is used toward the
CN (super LAC) and the one that is broadcasted on the air interface (AirLAC). This
is mainly to reduce the number of LACs that needs to be seen in the CN per BSR
cluster and thus the limiting the provisioning effort, but still allowing a larger
number of Air LACs.
As depicted on Figure 3, when activated, the Super LAC feature will place a
X25H X
“SuperLAC” in the messages sent to the CN. The LAC that will be broadcasted in
the SIB1 message on the air interface will be the “AirLAC”.
This feature is activated when setting the parameter activateSuperLAC to TRUE.
For the RANAP messages to the CN, the BSR will always replace the LAC or the
LAC in the LAI IE with the superLAC. For the non-access stratum (NAS) messages
to the CN, the BSR will only replace the LAC in the LAI or/and RAI (Routing Area
Identity) IEs with the superLAC if the “Air LAC” in the NAS messages is in the
same BSR cluster as the BSR. An AirLAC is in the same BSR cluster if the air LAC
is detected in the BSR neighbour cell list.
If the ‘Home tariff and visitors’ access differentiated support feature is activated
(see 3.3.4), the superLAC will either be the owner LAC (e.g. laLAC1), guest LAC
X256H X
(e.g. laLAC2) or the emergency call LAC (e.g. laLAC3).
If the BSR is in Open Access Mode or Semi Open Access Mode, the superLAC will
be given as described in Table 14. X257H X
LCell::areaSelectNormalFlag SuperLAC
‘off’ laLAC1
‘lac’ laLAC4
‘sac’ laLAC1
‘lacAndSac’ laLAC4
Table 14 - Super LAC for Open / Semi Open Mode BSR
If the Dynamic LAC allocation feature is activated and the LAC in the LAI and SAI
towards the CN in the RANAP messages need to be aligned, the LAC in the SAI
should use the superLAC used in the LAI.

BSR Femto
BSR Gateways MSC
BSG
BPG
BVG
Air LAC / Super LAC

translation
SIB messages with CN messages with
Air LAC Super LAC
Figure 3 - Super LAC and Air LAC
Parameter activateSuperLAC |
Object Femto | BSR
{True, False}
Class Class 3
Value FALSE
Parameter lAIalignSAI
Object BSR Profile
{True, False}
Class Class 3
Value FALSE
Parameter replaceLocationReportSAI
Object BSR Profile
{True, False}
Class Class 3
Value FALSE
3.3.6.1 ALIGNMENT OF LAC IN LAI AND SAI

If lAIalignSAI is set to TRUE and activateSuperLAC is set to TRUE, the BSR will
set the LAC in SAI of the uplink (UL) RANAP messages if present with the

SuperLAC for the CN domain. Otherwise, the BSR will not change the SAI IE of the
uplink RANAP messages.
3.3.6.2 LOCATION REPORTING

If the BSR needs to send RANAP Location Reporting to the CN for Location Based
Services and activateSuperLAC is set to TRUE and replaceLocationReportSAI
is set to TRUE, the BSR will replace the LAC in the SAI IE in the RANAP Location
Reporting with the superLAC for the CN. Otherwise, the BSR will not change the
contents of RANAP Location Reporting.
3.3.6.3 RESTRICTIONS
When the UE moves to the 2G/3G Macro network from the BSR, it sends the "old
LAI or RAI" (which is the airLAC of the BSR) in the NAS message (e.g. Location
Update Request, Routing Area Update Request etc.) to the Mobile services
Switching Center (MSC) or Serving GPRS Support Node (SGSN). This cannot be
intercepted by the BSR.
The MSC will not be able to locate the "old VLR" to process the location update
properly. Since the MSC cannot identify the UE, it will always request the IMSI
(International Mobile Station Identity) from the UE and then contact the HLR (Home
Location Register) to get authentication and subscriber data. The MSC will then
accept the Location Area Update (LAU), i.e. the user is not impacted, but the HLR
load is increased.
The SGSN will not be able to locate the "old SGSN" and thus may reject the
Routing Area Update Request with cause = # 9 (i.e. MS identity cannot be derived
by the network). Upon receiving the reject, the UE will delete any P-TMSI, P-TMSI
signature, RAI and GPRS (General Packet Radio Service) ciphering key sequence
number and automatically initiate the GPRS attach procedure with IMSI.
In some cases upon receiving Routing Area Update Request or GPRS Attach
Request, the SGSN may request the IMSI from the UE when it can't resolve the UE
identity and perform in the same manner as the MSC.
As the new SGSN does not know the old SGSN, the preserved Packet Data
Protocol (PDP) Context in the UE will also be deactivated by the new SGSN. This
may impact end user experience as the UE will have to activate the PDP Context
for the PS service again.

3.4. BSR SRNC ID

The feature 109896 “Standards compliant RNCid“ is introduced to break the
relationship between the RNCid and the Cluster id. The need to reserve 8 RNCids
per cluster should also be removed.
The sRNC Id is the Virtual SRNC identifier of a BSR cluster. Previously to this
feature, the sRNCId was derived from the BSR::clusterId using Formula 1. This X258H X
forced to reserve 8 RNC ID per Cluster.
sRNCId = BSR::clusterId *8 Formula 1
With the feature 109896, the sRNCId will be obtained from the parameter
BSR::sRNCIdCluster and no RNC ID block reservation will be needed anymore.
By setting the BSR::sRNCIdCluster value to 0, backwards compatibility is ensured

and in this case the SRNC ID will be derived using Formula 1. X259H X
The OAM parameter BSR::sRNCId remains unchanged and is the BSRs view of
the SRNC ID.
Parameter clusterId |
Object Network / FemtoCluster | BSR
Granularity Network / FemtoCluster | BSR
[1..511]
Class Class0
Value -
Parameter sRNCIdCluster
Object BSRClusterProfile | BSR
Granularity BSRClusterProfile | BSR
[0..4095]
Class Class 3
Value 0

3.5. PRIMARY SCRAMBLING CODE

During the auto-configuration or while self-optimizing, the BSR will have to choose
the Primary Scrambling Code that is to be used to transmit on.
3.5.1 MANUAL/AUTO-CONFIGURATION OF PSC

It is possible to set manually the PSC that a BSR is to use. This is done using the
parameter manualPscForFemto.
Parameter manualPscForFemto
[0…511]
Class Class 3
Value 0
Engineering Recommendation: Manual PSC
It is strongly recommended to set the PSC manually only for very specific purposes (Lab tests,
isolated BSR…) or to sustain manual RF Design.
Indeed, this procedure will not consider the RF environment at the location where the BSR will be
installed.
3.5.2 AUTOMATIC AUTO-CONFIGURATION OF PSC

The BSR can choose automatically its PSC. To enable this feature, the parameter
isAutoPscConfigEnabled has to be set to TRUE.
Engineering Recommendation: Automatic PSC allocation
It is strongly recommended to always allow the PSC to be chosen automatically to ensure

• that a PSC out of the BSR reserved PSC is used (femtoPSCList) and
• that the interferences are limited when in a dense deployment.
In this case, the BSR will go through a detection process and check:
If there is a PSC defined (after a Factory Reset, BSR has no PSC)
If the defined PSC is in the femtoPSCList

If no other BSR is transmitting on the defined PSC stronger than
rscpPscClashRealloc
In the case all these conditions are fulfilled, the BSR will keep its PSC.
U U
In all other cases the BSR will pick a new PSC out of the femtoPSCList.
In the case PSCs in the femtoPSCList are not reported, the BSR will pick
randomly its new PSC out of the not-reported ones.
In the case all PSCs in the femtoPSCList are monitored, the BSR will pick the
PSC with the weakest RSCP level.
The RF measurements are performed by the BSR itself using its embedded sniffer
during auto-configuration/self optimisation.
Parameter femtoPSC
Object femtoPSCList
Granularity femtoPSCList
[0…511]
Class Class 3
Value '
Engineering Recommendation: Number of PSC
Simulation and field deployment have shown that the typical number of PSC that are to be used
among a BSR network is to be chosen between 8 and 15.
This number will depend on the available PSC as well as the supported length of neighbourlists on
the Macro network.
Indeed, as the BSR will pick its PSC by itself, every PSC of the list will have to be populated as
neighbour in the underlay networks (3G or 2G).
Parameter isAutoPscConfigEnabled |
{True, False}
Class Class 3
Value True

Parameter rscpPscClashRealloc
Object BSR Profile
[-115..-25]
Class Class 3
Value -110

3.6. HARDWARE VERSION DEPENDENT PARAMETERS
3.6.1 MAXIMUM NUMBER OF USERS

Inter-Release Delta: LCell::numCellDCHUE
From BCR3.0, the parameter LCell::numCellDCHUE will be calculated automatically by the

Femtos. It will not be possible anymore to configure this parameter.
Its usage by the different algorithms remains the same.
The parameters HSDPA::maxHsdpaUsersPerCell (see [Vol. 10]) and X260H X
EDCH::maxEdchUsersPerCell (see [Vol. 10]) are used to limit the number of

X261H X
users to less than that supported by the HW.

If they are set to a value greater than the maximum supported by the HW, the SW
automatically caps their values.
The parameters maxPSDCHUsersPerCell is used to limit the number of PS users
using DCH (Dedicated Channel) in Uplink and Downlink.
Engineering Recommendation: Maximum Number of users
It is highly recommended to keep the parameters, HSDPA::maxHsdpaUsersPerCell and

EDCH::maxEdchUsersPerCell configured to their highest values of 64.
Parameter maxPSDCHUsersPerCell
Object Lcell | LCell
Granularity BSR Hardware Profile | BSR
[1..64]
Class Class 3
Value 16
3.6.2 HOME BSR V1.2

Feature 75888 introduces 2G sniffing capabilities on the Hardware v1.2. Indeed,
the PicoChip baseband processor will be reconfigured from a base station mode to
a 2G Mobile Station mode. This GSM Listener directly embedded on the PicoChip,
should allow faster searches of the GSM environment and as a result shorter Auto-
configuration / Self-Optimization phases.
The BSR Software determines the board type and will know if the 2G Network
Listener on the PicoChip can be used (v1.2 and above) or if the 2G HiLO Sniffer
(v1) is to be used.

In the case of a hardware version v1.2 and above, if
gsmListenerPicoBasedEnabled=False, then the 2G Network Listening will not be
enabled during the auto-configuration nor self-optimization phases.
If gsmListenerPicoBasedEnabled=True, then a BSR of v1.2 or above will use the
2G Network Listener like the HiLo module was used on other BSRs. The detailed
procedures are given in chapter [Vol. 5]. X26H X
Some parameters are introduced or named differently such as following.

• the Chip baseband processor reconfiguration will be bounded by the timer,
NetkListGuardConfigTimer,
• the BCCH Decode function will be bounded by the timer,
gsmBCCHDecodeGuardTimer
• the GSM Cell search function will be bounded by the timer,
GsmCellSearchGuardTimer
• the minGsmDetectThreshold is the minimum received signal strength of
a cell to be considered.
• the gsmMeasurementPeriod is the duration of the GSM RSSI
measurement period
The 2G Network Listening will take place on BSR v1.2 before the 3G Network
Listening. This is mainly to ensure that 3G Measurements will not change too much
between 3G Network Listening and 3G Transmitting.
Parameter gsmListenerPicoBasedEnabled
Object BSR Profile
{True, False}
Class Class 3
Value TRUE
Parameter gsmBCCHDecodeGuardTimer
Object BSR Profile
Range & Unit Integer (ms)
[500..6000]
Class Class 3
Value 2000

Parameter gsmCellSearchGuardTimer
Object BSR Profile
[60..1000]
Class Class 3
Value 250
Parameter gsmMeasurementPeriod
Object BSR Profile
[5..300]
Class Class 3
Value 25
Parameter NetkListGuardConfigTimer
Object BSR Profile
[0..60000]
Class Class 3
Value 10000
3.6.3 ENTERPRISE & METRO CELLS BSR V2

Enterprise and Metro Cells will be used for public indoor and outdoor coverage.
These are higher capacity cells with up to 32 users and higher output power (up to
250mW). The target of these cells is to fill in coverage holes (due for example to
cell breathing), offload the macro network, and offer specific public area services.
The feature for 16 User Capacity includes a capacity locking mechanism in order
for the operator to control and charge for increase capacity. The maximum allowed
capacity is configurable to the intermediate user capacity or the maximum user
capacity. Intermediate user capacity is half of the maximum user capacity.
The OAM parameter userCapacityLock is used to configure the user capacity on
the platform.
Parameter userCapacityLock
Object Femto
Granularity Femto
{intermediateUserCapacity=0,
maximumUserCapacity=1}
Class Class 0
Value intermediateUserCapacity

In these hardware platforms the feature Software Support of Rx Diversity is
activated by default. This feature brings a 3dB or more Rx diversity gain
(depending on radio channel) by using two antennas that receive the same signal
to increase the uplink receiver sensitivity. The combination of signals, with uplink
interference cancellation, will be done at chipset level below application
programming interface.
There is no new parameter introduced for this BSR version. Some tuning is only
necessary to cope with the increased capacity and power which is showed in Table 263H
15.X
Most of the power settings are relative to the pCPICHPower as shown in [Vol. 3]. X264H X
Therefore, there are only few power parameters to modify for the different HW.
20mW 100mW 250mW

maxBSRPowerLimitdBm 13 20 24
autoConfigPWmaxPilotPowerdBm 3 10 14
pCPICHPower 3 10 14
Table 15 - BSR Specific Parameters (Residential/Enterprise/Metro)
Restriction: Hardware limitations
Due to hardware limitation, the values provided are also the maximum values that will be
considered by a BSR. Indeed, in the case those values are provisioned higher than the
recommendations for a given hardware type, the BSR will limit the values to the recommended
ones. This is mainly to protect the BSR transmitter.
Engineering Recommendation: Profile enabled
The FMS is able to differentiate between the different HW versions and provide the proper CM
information to the BSR. Therefore it is important to ensure that profiles corresponding to each used
HW type are available when required.
3.6.4 BSR V2-A

The hardware V2-A is intended for the American market. This hardware has the
specificity to be equipped with a GPS receiver.
The V2-A hardware has the following aspects:

• Its output power can reach 250mW (depending on the Hardware type).
• It is equipped with a GPS receiver and a port for an external GPS antenna
connector. It can support the feature 75545. A GPS system without
assistance is unable to decode signal lower than -145 dBm.

• The receive (Rx) and transmit (Tx) frequency can operate in only one band
and the hardware is configurable for UMTS 1900 MHz or 850 MHz as the
operating UMTS frequency bands and for 3G network listening.
• The Rx frequency can support GSM 1900 MHz and 850 MHz frequency
bands for 2G network listening.
3.6.5 BSR V2-EC-2S

Inter-Release Delta: Feature 119860
Feature 119860 – 3G Sniffing Capability in 2100-850MHz introduced in BCR3.0 relies on the use of
a new hardware.
The hardware V2-EC-2S is a new variant of the V2-EC which sniffing capabilities
have been extended. Such Hardware have network listening functionalities
supporting the bands :
For 3G: 2100MHz / 850MHz
For 2G: 1900MHz / 850MHz
These sniffing extended capabilities are required to support feature 119860 – 3G
Sniffing Capability in 2100-850MHz.
3.6.6 RESERVED CHANNELS FOR SIGNALLING

Following the introduction of Cell FACH (Forward Access Channel), the capacity
limitation in the case of too high signalling has been mitigated. Therefore this
feature is only provided for completeness, but should not be activated per default
from BCR2.4.
This feature introduced for Enterprise BSRs allows reserving a number of

channels for signaling purposes (location updates, SMS, ..). This is particularly
important when BSRs are deployed in public areas with high number of users.
To enable the feature, the parameter sparePara7 should be set to the value
“restrictNumUEsWithRAB=1;maxUEsWithRAB=x”,
The parameter maxUEsWithRAB (or x) defines the maximum number of calls with
RABs (Radio Access Bearers) and RRC connections in progress for causes other
than "Registration" and "Emergency Call. Its value can be chosen from 4 to 7.
When this limit is exceeded, the BSR will reject and redirect new RRC connections
(when configured) other than those with cause registration or emergency call.
As a result, the number of slots reserved for Signaling will be equal to
numcellDCHUE – maxUEsWithRAB, e.g. 8 - maxUEsWithRAB.

Parameter sparePara7
Object BSR Profile
Range & Unit String
Class Class 3
Value -
Engineering Recommendation: maxUEsWithRAB (x)
The points to consider when defining the maxUEsWithRAB are the number of users that may
enter the coverage area of a BSR (and do LAU/RAU (Location/Routing Area Update) on RRC
Establishment with cause registration), the number of active users in the coverage area and finally
the hardware limitation of 8 for a v1 Business Model.
In areas where a lot of moving users is expected, maxUEsWithRAB should be set to values down
to 4 to give more resources for the Signaling Radio Bearer (SRB).
In the case the number of users is not expected to be very high, maxUEsWithRAB can be set to 7
in order to give more resources to connected users.
3.7. SUPPORTED RAB COMBINATIONS

Inter-Release Delta: numCellDCHUE
From BCR3.0, the parameter numCellDCHUE is calculated automatically by the BSRs. As a

result, there is no possibility to configure it anymore.
Inter-Release Delta: 32 Users Hardware

X
From BCR3.0, a 32 users hardware is available. The supported RAB combinations are listed in
Table 16.
265H
Table 16 presents the different RAB combinations that are supported by different
26H
BSR hardware platforms.

One or two additional simultaneous PDP Contexts can be configured using the
parameter isMpdpIBsupported (see [Vol. 4]) and established per UE. This is also
267H
valid with an active CS call in parallel to the PS Contexts (SimBearer). The column
PS I/B in Table 16 indicates the capacity irrespectively of the number of PDP
X268H X
contexts (single or with mPDP Contexts).
Restriction: Hardware limitation
3 simultaneous PDP contexts are only supported on the v2 hardware. Previous hardware only
supports a maximum of 2 PDP contexts simultaneously.

4 users 4 users 8 users 32 users

RAB Capacity Hardware (v1.2) Hardware (v2) Hardware 16 users Hardware Hardware
SRB [kbps] PS I/B [kbps] * Conv. Max user Max user Max user Interm. user Max user Max user
UL DL UL DL UL DL capacity capacity capacity capacity capacity capacity
Signalling Only 3.4 3.4 4 4 8 8 16 32
3.4 3.4 12.2 12.2 4 4 8 8 16 32
CS Users Only
3.4 3.4 64 64 4 4 6 8 16 30
3.4 3.4 8 8 4 4 8 8 16 32
3.4 3.4 32 32 4 4 8 8 16 32
3.4 3.4 64 64 4 4 8 8 16 30
3.4 3.4 64 128 4 4 4 8 15 15
3.4 3.4 64 384 2 4 2 4 7 7
PS Users Only
3.4 3.4 128 128 2 4 4 8 15 15
(single or with
3.4 3.4 128 384 2 4 2 4 7 7
mPDP on)
3.4 3.4 384 384 1 4 2 4 7 7
3.4 3.4 64 HSDPA 4 4 8 8 16 32
3.4 3.4 128 HSDPA 2 4 4 8 16 16
3.4 3.4 384 HSDPA 1 4 2 4 8 8
E-DCH 3.4 E-DCH HSDPA 4 4 8 8 16 32
3.4 3.4 32 32 12.2 12.2 4 4 8 8 16 30
3.4 3.4 64 64 12.2 12.2 4 4 8 8 16 30
3.4 3.4 64 128 12.2 12.2 4 4 4 8 15 15
3.4 3.4 64 384 12.2 12.2 2 4 2 4 7 7
PS + CS Users 3.4 3.4 128 128 12.2 12.2 2 4 4 8 15 15
(single or with 3.4 3.4 128 384 12.2 12.2 2 4 2 4 7 7
mPDP on) 3.4 3.4 384 384 12.2 12.2 1 4 2 4 7 7
3.4 3.4 64 HSDPA 12.2 12.2 4 4 8 8 16 32
3.4 3.4 128 HSDPA 12.2 12.2 2 4 4 8 16 16
3.4 3.4 384 HSDPA 12.2 12.2 1 4 2 4 8 8
3.4 3.4 E-DCH HSDPA 12.2 12.2 4 4 8 8 16 32
Table 16- Supported RAB for different HW variants

3.8. FEMTO BSR GROUP SUPPORT
3.8.1 GENERAL CONFIGURATION

The BSR Group or Femto group targets various needs, mainly related to coverage
of some areas (small/medium enterprises, or public areas such as airports) where
an individual BSR is insufficient in terms of capacity or coverage.
Increased coverage and capacity will be provided by a group of BSRs, located
closely together. Additionally, non co-located BSRs may be part of a group (for an
enterprise having multiple premises on the same campus where assignment of the
same mobility LAC/RAC and emergency call SACs to a group applies).
The parameter that defines if a BSR belongs to a group or not is bsrGroupId.

• If bsrGroupId=0, then the BSR does not belong to a group
• Any other value for the bsrGroupId will indicate the Id of the BSR Group a
BSR is belonging to.
Parameter femtoGroupId | bsrGroupId

Object FemtoCluster | BSR
Granularity FemtoCluster | BSR
[0…65534]
Class Class 3
Value 0
BSR within the same group must share some common settings.
• Same Access mode and Access Control List(s)
• Same Cluster identifier, Security gateway address
• Same Mobility LAC/RAC/SAC, differentiated-charging LACx/SACx,
differentiated emergency-call handling LAC3/SAC3 values
FMS: Femto Group

All of the parameter values for the BSR Group will have to be entered under
FemtoCluster::FemtoGroup and will override the values defined for each BSR (under
FemtoCluster::Femto).

FMS: FemtoGroupId
The FemtoGroupId is configured when defining the FemtoCluster::FemtoGroup and will be

automatically used to populate the bsrGroupId in the database of the BSR.
• the same Network Name

Note: It is possible to populate different Network Names for each BSR in a Group,
U U
but as all of them must have the same LAC/SAC, the network name will not be
update when the UE moves from one BSR to the other.
• Same PSC List
Restriction: BSR PSC List
As the BSR PSC List is populated in the BSR Profile, it must be ensured that either the same BSR
Profile is used through the BSR group or that the same lists are populated in the different BSR
Profiles.
The auto-configuration/self optimization of BSR belonging to a group is very similar

to the one of standalone BSR with regards to the power and PSC configuration.
The neighbourlist generation is modified in the case of BSR groups and will be
described in [Vol. 5].
269H
Restriction: Power adjustment
In order to ensure successful handover inter-BSRs in a group, a certain overlap is needed between
the coverage areas.
To guarantee this overlap, the automatic power adjustment features that are adapting the BSR
power based on UE receiver range (see [Vol. 3]) or on UE measurements (see [Vol. 3]) are to be
X270H X X271H X
disabled.
This is done by setting :
• autoConfigPW::pAdjustmentStepdB to 0
• and ueBasedPilotPowerAdjustMode to ‘disable’
Table 17 provides with the maximum number of BSRs which can be defined in a
27H
group.
Access Maximum
Type Number of BSR
Closed 256
Semi Open 50
Open 50
Table 17 – Maximum Number of BSR in a Group per Access Type

Engineering Recommendation: Maximum number of BSR in a group
As presented in the following chapters, the complexity of BSRs groups increases with the number
of BSRs belonging to them and the performances must be carefully monitored.
3.8.2 ENHANCED PSC ALLOCATION
3.8.2.1 FEATURE DESCRIPTION

In the case BSRs belonging to the same group are located far away from each
other, they may be able to detect their direct neighbour, but will not be able to
detect neighbours of their neighbours.
In Figure 4, for instance, Femto1 can detect Femto2 and Femto3, but Femto2 can
X273H X
only detect Femto1. This could result in Femto2 picking during the auto-
configuration/selfoptimization a PSC that is the same as Femto3.
UEs in the coverage area of Femto1, moving towards Femto3, would report in the
Handover message the PSC of Femto3 (e.g. PSC1). For Femto1 this will be
ambiguous and Femto1 could try to handover the UE to Femto2 or Femto3.
Figure 4 - Possible issue with PSC selection
To avoid such PSC ambiguity, after having sniffed its RF environment, a BSR in a
group, and if configured, will contact each detected neighbour BSR, which will reply
providing their own neighborlist.
The source BSR then has additional PSC information about its neighbours and its
neighbours-neighbours and uses this in order to avoid a PSC clash and improve
the Handover performances.
The activation of the feature is done setting the parameter

enableGrpNeighNeighPSCevaluation = TRUE and ensuring that the PSC is not
manually configured (see 3.3.2.1). Figure 5 provides with a view of the mechanism
X274H X X275H X
that is used to select the PSC in the case of BSRs belonging to groups and to
avoid PSC clashes.

Figure 5 - PSC Selection Improvement
Parameter enableGrpNeighNeighPSCevaluation
Object BSR Profile
Range & Unit boolean
{True, False}
Class Class 3
Value FALSE
3.8.2.2 PSC CLASH DETECTION

Following the BSR Setup procedure initiated by a BSR in a group and when
enableGrpNeighNeighPSCevaluation=TRUE and the PSC is not manually
configured, the BSR will determine whether the neighbours-neighbours have a
clash in PSC as follows:
1. The BSR will evaluate the CPICH RSCP (NeighRSCP) to each neighbour
as follows :
a) If the neighbour was detected during the most recent network
listening, then use this RSCP as NeighRSCP
b) If the neighbour was not detected, but informed then use the
informed RSCP as NeighRSCP if present
c) If the RSCP is neither detected nor informed then the neighbour-
neighbour evaluation shall not be performed for this neighbour.
2. From the BSR Setup Acknowledge, the BSR determines the neighbours-
neighbours with the same PSC as the source BSR and extract out the
corresponding RSCP (NeighNeighRSCP) if available
If the RSCP is not available for the neighbours-neighbour on the same PSC, then
the neighbours-neighbour shall be discarded.

3. The BSR will determine whether a clash exists with the neighbours-
neighbour on the same PSC using following algorithm:
If
NeighRSCP > pscReallocMinRscpNeigbNeigb
AND
NeighNeighRSCP > pscReallocMinRscpNeigbNeigb
AND
abs(NeighNeighRSCP-NeighRSCP) < pscReallocDeltaNeigbNeigb
Then there is a PSC Clash
This is to be considered for each neighbour BSR, and a PSC clash is determined if
the above criteria applies to any one of the neighbours BSRs.
Parameter pscReallocDeltaNeigbNeigb
Object BSR Profile
Range & Unit Integer [dB]
[0..50]
Class Class 3
Value 10
Parameter pscReallocMinRscpNeigbNeig
Object BSR Profile
Range & Unit Integer [dBm]
[-115..-25]
Class Class 3
Value -110
3.8.2.3 PSC SELECTION IN THE CASE OF PSC CLASHES

When a PSC clash has been detected on the neighbours-neighbours, the BSR will
have to choose a PSC that is the less impacted.
The BSR will use its own CPICH RSCP neighbours measurements and the CPICH
RSCP measurements reports from the neighbours. Based on these, the BSR will
evaluate the strength of the different PSC and which is the less impacted.
The BSR will then choose the less impacted one.
Manually configured neighbours are also considered and a default CPICH RSCP
value is given to them in the evaluation.
In the case that there are multiple PSC choices, the BSR will take the PSC
randomly.

3.8.3 EXTENDED ACL FOR FEMTO GROUPS
Inter-Release Delta: Extended ACL for Femto Groups
From BCR 3.0, the Extended ACL for Femto Groups allows the BSR to use an Extended ACL to
support Enterprise deployments.
3.8.3.1 OBJECTIVES AND BENEFITS

The feature 92068 allows using an extended ACL list (i.e. Access Control List) for
large BSR groups. With this feature, BSRs belonging to the same group can share
a common ACL with up to 10 000 entries. The Extended ACL list is stored in the
Femto Gateway (FGW).
The IMSI are provisioned through the FMS and are identified by the parameter
aclListRef on the FGW.
3.8.3.2 BSR CONFIGURATION

A BSR can use either the ACLs (owner/guest) located in its own database or the
ACLs located on the FGW. The choice is configured using the parameter
femtoACLlistIndicator.
• If femtoACLlistIndicator is set to femtoACL, the BSR uses its local ACL
list (see [Vol. 5]).
276H
• If femtoACLlistIndicator is set to fgwACL, the BSR uses the Extended

ACL on the FGW.
Parameter femtoACLlistIndicator
Object FemtoGroup | BSR
Range & Unit Enum
{femtoACL, fgwACL}
Class Class 3
Value femtoACL
3.8.3.3 FGW CONFIGURATION

The Extended ACL is provisioned/configured on the FGW through the FMS. The
attribute aclListRef identifies the Extended ACL list that a BSR uses. It points to
an EnterpriseList, which contains the list of IMSIs with their associated type
(owner/guest) in the parameter aclList.
One EnterpriseList can contain up to 10000 IMSIs. One FGW can contain up to
16Millions of IMSI. Alarms can be configured to be raised when configurable
thresholds are reached.

Parameter aclListRef
Object FemtoGroup | BSG
Granularity FemtoGroup | BSG
Range & Unit StringType
{EnterpriseList}
Class 3
Value -
Parameter - | aclList
Object | EnterpriseList
Granularity | EnterpriseList
{xx, yy, zz}
Class 3
Value -
FMS: aclList
The IMSI and IMSI Type (Owner/Guest) information composing the aclList are configured through
the entries OwnerAclEntry and GuestAclEntry of the object EnterpriseList in WiPS.
3.8.3.4 IMSI CHECK

In the case an IMSI has to be identified as belonging to the Extended ACL, the
BSR will request the information from the FGW. The request message will contain
additionally to the IMSI, the LAC.
The FGW replies with a message including the IMSI’s type as following:
• ‘Owner’,
• ‘Guest’,
• ‘Public User’ (i.e. if the UE has no access to any BSR in the current LA)
• ‘Public Femto User’ (i.e. the UE has access to at least one other BSR in
the current LA).
• or ‘Not in Extended ACL’;
The BSR stores the relevant IMSI and IMSI type locally for subsequent processing.
This also reduces the amount of signalling.

3.9. LOCATION & MOVEMENT CHECK

The BSR operates in a licensed spectrum and is therefore required to disable
transmission if it is in a location where it is not licensed to operate. As the BSR is
user installable the operator has no control over where the BSR is located,
therefore it is up to the BSR to determine its location and shutdown transmission if
wrongly positioned.
To enable this three different checks have been included in the BSR:
1) Location Check
2) Movement Check
3) National Location Lock
The Location Check tests ensure that the BSR is located in an area in which the
operator is licensed to operate while the Movement check will determine if the BSR
has been moved from its original approved location. National Location Lock tests
have been included to detect if the BSR is in a foreign country.
As determining the current BSR location is difficult and not 100% accurate, a
number of tests have been specified. The tests are divided in two groups:
1) RF Based: 2G/3G RF Fingerprint tests for Location and Movement
checks and 2G/3G Macro Check for MCC for the National Location Lock
check.
2) Network Based: MAC Address test and Trace Route test for the
Movement check and IP Address Check for the National Location Lock
check.
The operator, for each check, can choose the best combination of tests to execute
that would grant the most reliable result. A number of tests, especially the ones
involving 2G or 3G RF measurements can take some time to run to completion
(delaying the time before the BSR enters service) and therefore these test have
been parameterised so that the operator can customise to his deployment needs.
The parameter lmcOvrd determines if the BSR will continue into service following
a Location, Movement or National Location Lock check failure.
Setting lmcOvrd to TRUE will allow a failure to be overridden; in this case it would
be the responsibility of the operator to disable the BSR after the alarm has been
raised. Otherwise if lmcOvrd is set to FALSE the BSR will shutdown its
transmission if a check fails.

Parameter lmcOvrd
Object BSR Profile
{True, False}
Class Class 3
Value FALSE
Engineering Recommendation: lmcOvrd=TRUE
It is recommend setting lmcOvrd to TRUE when the feature is first deployed in order for the
operator to estimate the impact of this feature without preventing customer constraints and allow
the operator to characterise the tests to meet his deployment needs.
If lmcOvrd is set to FALSE and the BSR is disabled because of a check failure,
the operator can reactivate it by setting overrideLocationCheck to TRUE.
Consequently, the Femto will be reset, the location and movement checks will be
forced to pass and the location data will be updated with the new location. Finally,
overrideLocationCheck will be automatically set back to FALSE.
Inter-Release Delta: overrideLocationCheck
The parameter overrideLocationCheck is introduced in BCR 3.0.
Parameter overrideLocationCheck
Object BSR Profile
{True, False}
Class Class 3
Value false
3.9.1 LOCATION CHECK

The location check test is run to determine the BSR position when its position is
not yet known. This would be the case of first power on or factory reset. For
location check the result obtained from the tests are compared against
neighbouring cell information provided by the operator.
For the location check, the tests run are:

3) 2G RF Fingerprint test

Note that the tests for the Location Check only rely on RF measurements. The
Location Check algorithm is illustrated in Figure 6. 27H
Location Check will run during auto-configuration. A flag LocationCheckPassFlag

will be used to determine if it is the initial check or a subsequent check. The BSR
will proceed to the RF Fingerprint tests only if the LocationCheckPassFlag is set
to FALSE.
Figure 6 - Location Check algorithm
The setting of the locationCheckPassFlag (a read only parameter) depends on

the results of the Location Check and National Location Lock tests (if enabled) and
both must pass before the flag is set to TRUE and the BSR can move into the
‘Movement Check phase’ on subsequent power-on or reset. A factory reset takes
the flag back to FALSE and hence to the ‘Location Check phase’.
A test result for the Location check, Weight x Score (Score=0 if test fails, Score=1
if test pass), will be determined for 3G RF Fingerprint and 2G RF Fingerprint tests.
The result of the tests for the location check are then summed and compared with
the threshold lMCthresholdLevelLocationWeight and if the result is greater than
95H
or equal to this value then the check has passed.

Parameter lMCthresholdLevelLocationWeight |
LocationWeight
Object BSR Profile | lMCthresholdLevel
[0...600]
Class Class 3
Value 50
3.9.1.1 2G RF FINGERPRINT TEST

The 2G RF fingerprint test uses the 2G Network Listening functionality to detect the
neighbouring 2G macro cells that are visible to the BSR. The detected 2G
neighbour cells are included in the gsmMacroNCell list that will be compared with
a known list in order to determine a result.
For location checking the gsmMacroNCell list is compared against a list of 2G
macro cells provided by the operator. The test is configurable so as the threshold
needed for the test to pass.
The 2G RF fingerprint test will compare the newly found 2G macro neighbour cells
with the 2G cells configured by the operator in gsmExtCell excluding the cells
which are marked ‘not allowed’. If the number of matched cells is greater than, or
equal to the gsmLocationCheckDetectedThreshold then the test has passed. If
the number of matched cells is less than this threshold and all the cells within the
gsmExtCell were measured or the MaxGSMMeasurementTime have expired
while measuring the gsmExtCell list, then an open search on the 2G FDD
(Frequency Division Duplex) cell frequency will be made to determine if there are
any cells from the newly detected set that are not in gsmExtCell and if so, then the
test will fail, but if there are no new cells then the test will pass.
If the list of gsmExtCell list is empty, the BSR performs an open search on the 2G
FDD cell frequency. If it detects a 2G cell above the threshold
minGSMDetectThreshold (Chapter 3.6.2) the BSR assumes that the test failed.
278H
Otherwise, the BSR will assume that the test passed after completing the open
search with no macro cell detected.
The 2G Fingerprint test result is then weighted (a weight of 0 means that the test is
zero and does not contribute to the overall score – disables the 2G Fingerprint
test). The scores of 2G Fingerprint will then be summed with all the other tests and
compared against a configurable overall threshold for location checking.
The Location weight for the 2G RF Fingerprint Test is configurable through the
parameters lMCvisibleGsmCellsTestLocationWeight.
96H

Parameter gsmLocationCheckDetectedThreshold
Object Lcell
[0...64]
Class Class 3
Value 1
Parameter MaxGSMMeasurementTime
Object Lcell
Range & Unit Integer (days)
[0..365]
Class Class 3
Value 3
Parameter lMCvisibleGsmCellsTestLocationWeight |
LocationWeight
Object BSR Profile | lMCvisibleGsmCellsTest
[0..100]
Class Class 3
Value -

The 3G RF fingerprint test algorithm follows the same principles as the 2G RF
fingerprint test using the 3G Network Listening functionality to detect the
neighbouring 3G macro cells that are visible to the BSR.
For location checking the list umtsMacroNCell populated by the 3G Network
Listening functionality is compared against a list of 3G macro cells provided by the
operator.
If no cells are found (i.e. no 3G coverage) and lMCRFDetectionNoCells is set to
TRUE, then the 3G RF fingerprint test will fail. Otherwise, the test will compare the
newly found 3G macro neighbour cells with the 3G cells configured by the operator
in fddExtCell excluding the cells which are marked ‘not allowed’. If the number of
matched cells is greater than, or equal to the locationCheckDetectedThreshold
then the test has passed. If the number of matched cells is less than this threshold
and all the cells within the fddExtCell were measured or the
MaxFDDMeasurementTime have expired while measuring the fddExtCell list,
then an open search on the 3G FDD cell frequency will be made to determine if
there are any cells from the newly detected set that are not in fddExtCell and if so,
then the test will fail, but if there are no new cells then the test will pass.
If the list of fddExtCell list is empty, the BSR will perform an open search on the
3G FDD cell frequency. During open search, the BSR will exclude the PSCs

reserved for the BSR. If it detects a 3G FDD cell above the threshold
minUMTSDetectThresholdRSCP or minUMTSDetectThresholdEcNo
(depending on macroCellMeasurementQuantity [Vol. 5]), the BSR will assume279H
that the test failed. Otherwise, the BSR assumes the test has passed.
The 3G Fingerprint test result is then weighted (a weight of 0 means that the test is
zero and does not contribute to the overall score – disables the 3G Fingerprint
test). The scores of 3G Fingerprint will then be summed with all the other tests and
compared against a configurable overall threshold for location checking.
The Location weight for the 3G RF Fingerprint test is configurable through the
parameters lMCvisibleMacroCellsTestLocationWeight.
Inter-Release Delta: lMCRFDetectionNoCells
From BCR 3.0, the parameter lMCRFDetectionNoCells replaces sparePara3 in previous

versions.
Parameter lMCRFDetectionNoCells
Object LCell
{True, False}
Class Class 3
Value false
Parameter locationCheckDetectedThreshold
Object LCell
[0...64]
Class Class 3
Value 1
Parameter MaxFDDMeasurementTime
Object Lcell
Range & Unit Integer (days)
[0..365]
Class Class 3
Value 3

Parameter lMCvisibleMacroCellsTestLocationWeight |
LocationWeight
Object BSR Profile | lMCvisibleMacroCellsTest
[0..100]
Class Class 3
Value -
3.9.2 MOVEMENT CHECK

The movement check is run to determine if the BSR has moved from its previous
location. The check is run at power on or reset. For the movement check the test
compares the newly detected cells with the union of the cells provided by the
operator and those found during the previous location or movement check.
For the movement check, the tests run are:

3) MAC Address test
4) Trace Route test
The Movement Check can combine both RF and Network based tests for the
decision of the check result. The Movement Check algorithm is illustrated in Figure 280H
7.
Figure 7 - Movement Check algorithm


If the initial check flag, LocationCheckPassFlag is TRUE (initial Location Check

has previously been performed successfully) then the Movement Check will be
performed.
A test result for the Movement check, Weight x Score (Score=0 for a fail, Score=1
for a pass), will be determined and this will be summed with the results of all other
location tests run.
The result will then be compared with the threshold
lMCthresholdLevelMovementWeight and if the result is greater than or equal to
97H
this value then the check has passed.
Parameter lMCthresholdLevelMovementWeight |
MovementWeight
Object BSR Profile | lMCthresholdLevel
[0...600]
Class Class 3
Value 100

In the Movement check test, the BSR will compare the newly found 2G macro
neighbour cells, using the 2G Network Listening function, with the union of the 2G
cells found during the last search in gsmMacroNCell, excluding the cells which are
marked ‘not allowed’, and any new cells added to gsmExtCell. If the number of
matched cells is greater than or equal to the 2G RF Fingerprint threshold,
gsmMovementCheckDetectedThreshold, then the test has passed. If the
number of matched cells is less than this threshold then a further check will be
made to determine if there are any cells from the newly detected set that are not in
gsmMacroNCell and if so, then the test will fail, but if there are no new cells then
the test will pass.
The 2G Fingerprint test result in the Movement check is then weighted (a weight of
0 means that the test is zero and does not contribute to the overall score) and the
scores of all the tests run are summed and compared against a configurable
threshold for movement checking.
The Movement weight for the 2G RF Fingerprint test is configurable through the
parameter lMCvisibleGsmCellsTestMovementWeight.
98H

Parameter gsmMovementCheckDetectedThreshold
Object Lcell
[0...64]
Class Class 3
Value 2
Parameter lMCvisibleGsmCellsTestMovementWeight |
MovementWeight
Object BSR Profile | lMCvisibleGsmCellsTest
[0..100]
Class Class 3
Value 50

The Movement check with the 3G Network Listening function will follow the same
principle as with 2G Network Listening.
If no cells are found (i.e. no 3G coverage) and lMCRFDetectionNoCells is set to
TRUE, then the 3G RF fingerprint test will fail. Otherwise, the BSR will compare the
newly found 3G macro neighbour cells, with the union of the 3G in
umtsMacroNCell, excluding the cells which are marked ‘not allowed’, and any new
cells added to fddExtCell. If the number of matched cells is greater than or equal
to the 3G RF Fingerprint threshold, MovementCheckDetectedThreshold, then
the test has passed. If the number of matched cells is less than this threshold then
a further check will be made to determine if there are any cells from the newly
detected set that are not in umtsMacroNCell and if so, then the test will fail, but if
there are no new cells then the test will pass.
The 3G Fingerprint test result in the Movement check s then weighted (a weight of
The Movement weight for the 3G RF Fingerprint test is configurable through the
parameter lMCvisibleMacroCellsTestMovementWeight.
9H
Parameter movementCheckDetectedThreshold
Object LCell
[0...64]
Class Class 3
Value 2

Parameter lMCvisibleMacroCellsTestMovementWeight |
MovementWeight
Object BSR Profile | lMCvisibleMacroCellsTest
[0..100]
Class Class 3
Value 50
3.9.2.3 MAC ADDRESS TEST

In the MAC Address test the IP Fingerprint function (IPFPR) will resolve the MAC
address of the Home Gateway (it is assumed that the BSR will be connected to a
DSL (Digital Subscriber Line) router which provided connectivity to the public
Internet Service Provider (ISP) network) and write the MAC address into the BSR
attribute nextHopMacAddress if it is empty or if the BSR Location Check explicitly
specifies that it should be updated.
After each start-up the IPFPR verify the detected MAC address against the
contents of the attribute nextHopMacAddress. If the attribute is empty or the
values match, then the test passes; if the values do not match, then the test fails.
The MAC Address test result in the Movement check is then weighted (a weight of
The Movement weight for the MAC Address test is configurable through the
parameter lMCrouterMACAddressTestMovementWeight.
10H
Parameter lMCrouterMACAddressTestMovementWeight |
MovementWeight
Object BSR Profile | lMCrouterMACAddressTest
[0..100]
Class Class 3
Value 50
Restriction: MAC Address detection over PPPoE connection
Such data is not helpful if the BSR is connected over a PPPoE connection because the only
destination MAC address detected by the BSRs is the MAC address of the Access Concentrator in
the DSL Access Network which is identical for all BSRs in the cluster. So for PPPoE this test
should be disabled lMCrouterMACAddressTestMovementWeight=0 and other criterias like RF
10H
Fingerprint needs to be enabled.

3.9.2.4 TRACE ROUTE TEST
The BSR IPFPR will trace the route to the first public IP address which should be
the IP address of the Broadband Remote Access Server (BRAS) in the ISP
network.
The IPFPR will write the detected first non-private IP address into the attribute
firstPublicIpAddressInPath if it is empty or if the BSR Location Check explicitly
specifies that it should be updated.
After each start-up the IPFPR verifies the detected BRAS DSL Router IP address
against the contents of the attribute firstPublicIpAddressInPath. If the attribute is
empty or the values match, then the BSR Location Check is informed that the test
passes; if the values do not match, then it is informed that the test fails.
The Trace Route test result in the Movement check is then weighted (a weight of 0
means that the test is zero and does not contribute to the overall score) and the
The Movement weight for the Trace Route test is configurable through the
parameter lMCtraceroutePathTestMovementWeight.
102H
Parameter lMCtraceroutePathTestMovementWeight |
MovementWeight
Object BSR Profile | lMCtraceroutePathTest
[0..100]
Class Class 3
Value 50
3.9.3 NATIONAL LOCATION LOCK

The BSR operates in licensed spectrum and licenses are issued to Operators on a
country basis. The National Location Lock feature will enable the BSR to detect the
country in which is located prior to enabling transmission. Based on configurable
parameters a decision can be made on whether to start transmission or turn off
and inform the operator.
For the national location lock check, the tests run are:
1) IP Address Check
2) 2G Macro Check for MCC
3) 3G Macro Check for MCC
The National Location Lock algorithm is illustrated in 281H
Figure 8.

Figure 8 – National Location Lock algorithm
The tests will be run during auto-configuration and will be part of the Location and
Movement checks. National Location checks will have priority over any Location or
Movement checks.
A test result for the National Location check, Weight x Score (Score = 0 if test fails,
Score = 1 if test pass), will be determined for IP Addres check, 2G Macro Check for
MCC and 3G Macro Check for MCC tests.
The result of the tests are then summed and compared with the threshold
nllThresholdLevelLocationWeight or with the threshold
nllThresholdLevelMovementWeight depending if the National Location check is
performed with Location Check or Movement Check.
If the result is greater than or equal to the respective threshold value then the
check has passed.
The National Location Lock feature can be enabled/disabled per BSR cluster
through the flag nationalLocationLockEnabled.
Parameter nationalLocationLockEnabled |
Object Femto | BSR
{True, False}
Class Class 3
Value FALSE

Parameter nllThresholdLevelLocationWeight |
LocationWeight
Object BSR Profile | nllThresholdLevel
[0...600]
Class Class 3
Value 100
Parameter nllThresholdLevelMovementWeight |
MovementWeight
Object BSR Profile | nllThresholdLevel
[0...600]
Class Class 3
Value 0
Engineering Recommendation: Disable NLL with Movement Check
It is recommended performing the NLL test only with the Location Check. If the Movement Check
runs and passes then a NLL movement check would not be necessary to run.
The recommendation is to disable the NLL movement checks and only run if in Movement Check
test is disabled.
Setting nllThresholdLevelMovementWeight=0 disables the NLL with Movement check.
3.9.3.1 IP ADDRESS CHECK

The IP address assigned to the BSR home gateway (i.e. DSL router) by the local
ISP has National significance and can therefore be used as an indication that the
BSR is located in the correct country.
From a knowledge of the IP address ranges assigned to a country, the BSR can
compare the transport address assigned to its home gateway (DSL router) by its
local ISP and use this to determine the country of its host ISP and hence have a
good indication that the BSR is indeed in that country.
The National IP check will be performed centrally in the cluster allowing the
National IP database to be centrally managed and avoid having to download the
address list to each BSR in the cluster and then keep up to date. It will also avoid
having to reserve memory for storage of the file on the BSR, a resource that is in
short supply.
The National IP lookup application on the BSG will be configured and updated with
a file containing a list of country assigned IP addresses from the operator’s IT
system, downloaded from the FMS. The BSR will obtain its gateway IP address
from the security gateway and send a data request for National IP lookup to the
BSG receiving a Pass, Unknown or Fail response.

If the BSG replies to the BSR with Cause of 'No IP Table File Found' then the IP
Address Test result is Unknown. This is in fact a BSG configuration error caused
by missing IP Table, and hence not a BSR National Location Lock failure, also if
the BSG query time-out, then the IP Address Test result will be Unknown.
The IP range file will be sent by FMS to the /opt/natloc/download directory on the
BSG. The activation sequence procedure is described below:
1) FMS will trigger the ActNLLFile action on the Simple Network
Management Protocol (SNMP) interface to the BSG to cause the
BSG to activate a new IP range file.
2) When the BSG accepts the action it will check that there is only
one IP range file present in the /opt/natloc/download directory. If
more than one file exists the BSG will send a failure SNMP
notification to FMS indicating multiple files are present in the
directory.
3) If only one IP range file exists in the /opt/natloc/download
directory the BSG will check that the file contains records of the
expected type and format. If the file contains any records with an
invalid format, the BSG will send a failure SNMP notification to
FMS indicating the invalid format.
4) If the contents of the IP range file validate correctly, the BSG will
move the file from the /opt/natloc/download directory to the
/opt/natloc/active directory and the new file will be available to
perform IP range checks on any new requests arriving from the
BSR. The nLLIpRangeFilename attribute will be updated to
contain the filename of the new file.
5) If an IP range file already exists in the /opt/natloc/active directory
it will remain in existence until it is no longer being used to perform
IP range checks, at which point it will be removed from the
directory.
Finally the IP Address Check result will then weighted (a weight of 0 means that
the test is zero and does not contribute to the overall score) and the scores of all
the tests run for National Location Lock are summed and compared against a
configurable threshold for movement checking.
The Location and Movement weight for the IP Address check are configurable
through the parameters nllPublicIPAddressTestLocationWeight and
nllPublicIPAddressTestMovementWeight.

Parameter nllPublicIPAddressTestLocationWeight |
LocationWeight
Object BSR Profile | nllPublicIPAddressTest
[0..100]
Class Class 3
Value 50
Parameter nllPublicIPAddressTestMovementWeight |
MovementWeight
Object BSR Profile | nllPublicIPAddressTest
[0..100]
Class Class 3
Value 0
3.9.3.2 2G MACRO CHECK FOR MCC

The BSR will use its 2G Network Listening functionality to read the PLMN ID of the
mobile operator that it is broadcasted in the Master Information Block (MIB). The
PLMN ID consists of a Mobile Country Code (MCC) and Mobile Network Code
(MNC).
The 2G Network Listening will read the MCC broadcast from neighbouring 2G cells
to check if the MCC belongs to the country where the BSR is located.
Network Listening is not 100% accurate as in border areas it may be difficult to
accurately position the BSR but in areas where no foreign country code is seen it
will be a good indication that the BSR is in country.
This feature allows the 2G Network Listening functionality to read the PLMN ID of
neighbour cells not only belonging to the Operator’s PLMN but all operators can be
searched and the resulting MCC compared with that of the BSR own operator
PLMN:MCC.
During the 2G Macro Check for MCC test the GSM neighbour cells found during
the cell search will be added to the list gsmNatCell. When the number of cells
being populated in gsmNatCell is equal to gsmNLLCellNum and all the
frequencies in gsmNatLocLockFrequency have been scanned the BSR will
determine the result of the 2G Macro MCC test applying the ranges presented in
Table 18.
28H
The list of GSM neighbour cell frequencies and bands for searching during
National Location Lock 2G MCC test are defined in gsmNatLocLockFrequency.

Engineering Recommendation: gsmNatLocLockFrequency
If the feature dual band 850/1900 is activated, it is recommended to increase the range of
gsmNLLCellNum from 16 to 32. The frequencies in gsmNatLocLockFrequency includes from
both bands.
Parameter gsmNatLocLockFrequency
Object FemtoCluster
Granularity FemtoCluster
Range & Unit Sequence of Struct GSMFrequencyList
[0..4]
Class Class 0
Value -
To be eligible for the National Location Lock 2G MCC test the BCCH RSSI strength
of the GSM neighbour cells must be equal or greater to gsmNLLThreshold.
Parameter gsmNLLThreshold
Object BSR Profile
[-110..-48]
Class Class 3
Value -90
The number of GSM neighbour cells to be considered in the National Location

Lock 2G MCC Test is defined in gsmNLLCellNum.
Parameter gsmNLLCellNum
Object BSR Profile
[1..32]
Class Class 3
Value 8
If a response to the cell search is not received in guard timer

gsmCellSearchGuardTimer then the cell search will be stopped. After timer
expiration the BSR will tune to the next frequency number (ARFCN) and start a
new cell search.

Parameter gsmCellSearchGuardTimer
Object BSR Profile
[60..1000]
Class Class 3
Value 250
Note: Despite a full search across 2G is allowed, this can take a considerable time
to complete the test. As a result, the search algorithm is parameterised to minimise
the search time, especially in border areas and in areas of low coverage.
Operators using this feature must therefore be aware that it is important to choose
the parameter settings with care to avoid long auto-configuration times.
3.9.3.3 3G MACRO CHECK FOR MCC

The 3G Macro Check for MCC will follow the same principle described for the 2G
Macro Check for MCC but with the 3G Network Listening functionality.
The 3G Network Listening will read the MCC broadcast from neighbouring 3G cells
to check if the MCC belongs to the country where the BSR is located. This feature
allows the BSR to compare the own operator PLMN:MCC with the 3G neighbour
cells PLMN ID of any operator.
During the 3G Macro Check for MCC test the UMTS neighbour cells found during
the cell search will be added to the list umtsNatCell. When the number of cells
being populated in umtsNatCell is equal to umtsNLLCellNum and the number of
cell per frequency in umtsNLLCellPerFrequency has been found and all the
frequencies in umtsNatLocLockFrequency have been scanned the BSR will
determine the result of the 3G Macro MCC test applying the ranges presented in
Table 18.
283H
The UMTS neighbour cell frequency bands for searching during National Location
Lock 3G MCC test are defined in umtsNatLocLockFrequency.
Engineering Recommendation: umtsNatLocLockFrequency
If the feature dual band 850/1900 is activated, it is recommended to increase the range of
umtsNLLCellNum from 16 to 32. This allows at least one cell to be found from each frequency in
each band before the search terminates. The frequencies in umtsNatLocLockFrequency includes
from both bands.

Parameter umtsNatLocLockFrequency
Object FemtoCluster
Granularity FemtoCluster
Range & Unit Sequence of Struct UmtsNLLFrequencyList
[0..24]
Class Class 0
Value -
The number of UMTS cells needed to be found per frequency for the National
Location Lock is defined by the parameter umtsNLLCellPerFrequency.
Parameter umtsNLLCellPerFrequency
Object BSR Profile
[1..4]
Class Class 3
Value 1
Will only be eligible for National Location Lock 3G MCC test the 3G neighbour cells
whose CPICH RSCP strength is equal to or greater than umtsNLLThreshold.
Parameter umtsNLLThreshold
Object BSR Profile
[-120..-25]
Class Class 3
Value -100
The number of UMTS neighbour cells to be considered in the test is defined in

umtsNLLCellNum.
Parameter umtsNLLCellNum
Object BSR Profile
[1..32]
Class Class 3
Value 12
The cell search is bounded by the timer umtsNLLCellSearchTimer. After timer

expiration the BSR will tune to the next frequency and start a new cell search.

Parameter umtsNLLCellSearchTimer
Object BSR Profile
Range & Unit Integer (s)
[1..600]
Class Class 3
Value 10
To calculate the test result, the following test will be performed by both the 2G
Macro MCC and 3G Macro MCC tests to determine a Pass or Fail or Unknown
result.
If the test originated from the 3G Macro MCC test then the umtsNatCell neighbour
cell list is to be used and if the test originated from the 2G Macro MCC test then
the gsmNatCell neighbour cell list is to be used. The BSR will determine the
weighted sum of macro cells with the same MCC (LCELL::ownPLMNMCC) as its
own MCC (National cells) in the ranges shown below based on the strength of the
cell. The BSR determines the weighted sum of all cells that are not the same MCC
(LCELL::ownPLMNMCC) as its own MCC (Foreign cells) in the ranges shown
below based on the strength of the cell.
Number of
Number of
own National Weight per
Range Cell strength Ranges in dBm Foreign cells
cells per range
per range
range
i=1 -T < Rangei < -T + n Ni Fi Wi=1
i=2 -T + n < Rangei < -T + 2n Ni Fi Wi=2
i=3 -T + 2n < Rangei < -T + 3n Ni Fi Wi=3
i=4 -T + 3n < Rangei < -T + 4n Ni Fi Wi=4
I=5 -T + 4n ≤ Rangei Ni Fi Wi=5
Table 18 - 2G/3G Macro MCC test result ranges
Where
• T = gsmNLLThreshold for 2G test
• T= umtsNLLThreshold for 3G test
• n = NLLTestStrengthIncrement (dBm)
The BSR will apply the following to obtain a result:

1. If Σ(Ni x Wi) > Σ(Fi x Wi) then umtsNLLMCCResult or gsmMCCResult
is set to Passed.

2. If Σ(Ni x Wi) < Σ(Fi x Wi) then umtsNLLMCCResult or gsmMCCResult
is set to Failed.
3. If all ranges are empty, i.e. no cells are found, then umtsNLLMCCResult
or gsmMCCResult is set to Unknown.
The strength increment to set the ranges for National Location Lock 2G and 3G
Macro MCC tests are defined through NLLTestStrengthIncrement.
Parameter NLLTestStrengthIncrement
Object BSR Profile
[1..10]
Class Class 3
Value 5

3.10. GPS LOCALIZATION FUNCTION
3.10.1 OVERVIEW
The feature 75545 allows the BSR to localize itself using an embedded GPS to
ensure the BSR stays in its authorized area.
Restriction: Hardware dependency
The feature 75545 can only be enabled, if the BSR is equipped with a GPS receiver.
During the Auto-configuration phase, the BSR compares its geographical location
against the provisioned geographical location (also called “authorized location”) as
depicted in Figure 9.
284H
Enable GPS
enableGPSLocationCheck to true
scanOnboot to true
A GPS location is fixed within timer

scanTimeoutInitialStartup &
scanTimeoutSubsequentStartup
Is BSR in an authorized location?
True False
BSR is allowed to transmit the 3G signal if Non- BSR is not allowed to transmit the 3G
GPS location and movement check are not signal.
enabled:
requireNonGPSLocationConsistencyCheck to
false
Figure 9 – Overall GPS Check Procedure
If the GPS receiver is not able to fix a location within the timer, it allows continuing
if the parameter enableGPSAfterTimerExpired is set to TRUE. In this case, the
GPS runs until a location is fixed.

In the auto-configuration phase, the provisioned geographical location is used to
allocate:
• The carrier frequency.
• The area codes (LAC, RAC, SAC).
• The Neighbouring cells.
• The gateway addresses.
In consequences, location check will allow to lock the BSR when it is not in the
authorized location.
The GPS receiver can also be used for:

• Emergency call.
• Location based services.
3.10.2 GPS-BASED LOCATION CHECK
3.10.2.1 GPS-BASED LOCATION CHECK

GPS-based location check is enabled through the parameter
enableGPSLocationCheck.
Rule: GPS scanning
To activate the feature, the parameter gpsScanOnBoot must be set to true. It allows the GPS to
scan upon BSR booting.
Engineering Recommendation: GPS scanning
Even if the feature is not activated (enableGPSLocationCheck set to false). It is strongly

recommended to enable the GPS scanning. The information resulting can be used for Location
based services and emergency calls.
If enableGPSLocationCheck is set to true, the BSR is going to fix a position

during the autoconfiguration phase:
• If the GPS receiver is able to provide its location within the timer
scanTimeoutInitialStartup for an initial start-up or the timer
scanTimeoutSubsequentStartup for a subsequent start-up, the BSR will
estimate if its location is authorized (refer to 3.10.2.2). 285H
• If the GPS receiver is not able to provide its location within the two timers
mentioned above, the GPS can keep continuing to fix a location. It is
configurable through the parameter enableGPSAfterTimerExpired. If it is
set to true, the GPS receiver is allowed to continue indefinitely.

Engineering Recommendation: Enable the GPS scanning
Most of Small Cells are deployed in an Indoor environment. Since, the GPS signal is weak in
indoor; the GPS may take a long time to fix a location. In consequences, to avoid the GPS receiver
looking for its location indefinitely it is strongly recommended to set the parameter
enableGPSAfterTimerExpired to false.
Parameter enableGPSLocationCheck
Object GPS
{True, False}
Class Class 3
Value FALSE
Parameter gpsScanOnBoot | scanOnBoot

Object Femto | GPS
{True, False}
Class Class 3
Value FALSE
Parameter enableAllowedGPSAfterTimerExpired
Object GPS
{True, False}
Class Class 3
Value TRUE
Parameter scanTimeoutInitalStartup
Object GPS
[1..65000]
Class Class 3
Value 1800

Parameter scanTimeoutSubsequentStartup
Object GPS
[1..65000]
Class Class 3
Value 1800
3.10.2.2 AN AUTHORIZED AND UNAUTHORIZED LOCATION

When an accurate GPS location has been detected, the BSR should determine if
the detected location falls within the authorized location using the following
formula.
The Horizontal Position Difference is the distance between the Authorized Position
(defined by the latitude and longitude) and the reported position (defined by
lockedLatitude and lockedLongitude). It will be used for the location lock.
Rule: Provisioned Location
The parameter geographicalLocationConfigured determines whether geographical location has

been configured. It must be set to true for this feature.
The radius of the GPS detected position (in meters) is given through:
Radius _ Detected = GPS :: scannedLocationAccuracy + 10 (1)
The radius of the Authorized BSR is given by the parameter

authorizedLocationRadius:
Radius _ Authorized = GPS :: authorizedLocationRadius (2)
The location of the BSR is considered as authorized if the two following conditions
are met:
• Horizontal _ Position _ Difference ≤ Radius _ Authorized − Radius _ Detected
(3)
• Radius _ Authorized ≥ Radius _ Detected (4)
The Figure 10 shows a possible authorized location of the BSR.
286H

Figure 10 - An authorized location
Parameter latitude
Object Femto
Granularity Femto
Range & Unit Real
[-90.0000…90.0000]
Class Class 3
Value -
Parameter longitude
Object Femto
Granularity Femto
Range & Unit Real
[-180.0000...180.0000]
Class Class 3
Value -
Parameter geographicalLocationConfigured |
Object Femto | BSR
{True, False}
Class Class 3
Value FALSE
Parameter | lockedLatitude
Object | GPS
Granularity | BSR
[-90000000..9000000]
Class Class 3
Value 0

Parameter | lockedLongitude
Object | GPS
Granularity | BSR
[-180000000..18000000]
Class Class 3
Value 0
Parameter authorisedLocationRadius
Object GPS
Range & Unit Integer (meter)
[1..1000]
Class Class 3
Value 65
Parameter scannedLocationAccuracy
Object GPS
Range & Unit Integer (meters)
[1..100]
Class Class 3
Value 15
Example: With the default value:

• Radius _ Detected = 15 + 10 = 25 meters.
• Radius _ Authorized = 65 meters.
That means the GPS detected location is in an authorized location when:
• Horizontal _ Position _ Difference ≤ 40 meters.
When the GPS detected location is in an authorized location, the BSR is allowed to
transmit (or retransmit) the 3G signal.
Even if the GPS detected location is in an authorized location, the non-GPS and
the movement checks can be activated through the parameter
requireNonGpsLocationConsistencyCheck. In this case, the BSR is allowed to
transmit the 3G signal only if the following checks pass:
• The Non-GPS location check (refer to 3.9.1). 287H
• The movement check (refer to 3.9.2). 28H

Parameter requireNonGpsLocationConsistencyCheck
Object GPS
{True, False}
Class Class 3
Value FALSE
When the GPS detected location is in an unauthorized location, it will keep running
during the timer scanTimeoutInitialStartup for an initial start-up and the timer
scanTimeoutSubsequentStartup for a subsequent startup. During this period, the
BSR performs the following actions:
• Stop transmitting the 3G signal.
• An alarm is raised to the operator.
• A visual indication is provided to the end-user.
Upon expiration of the timer, if the BSR is still in an unauthorized location, the BSR
is not allowed to behave normally and the GPS receiver is still up if the parameter
GPS::enableAllowedGPSAfterTimerExpired is set to true otherwise the GPS
receiver is disabled.
3.10.3 NON-GPS LOCATION AND MOVEMENT CHECK

When the GPS scan timeout occurs, the non-GPS location and the movement
checks (Refer to 3.9.1 and 3.9.2) can be performed, it is configurable through the
289H 290H
parameters GPS::enableNonGPSLocationCheckForFailGPSInitialStartup for

an initial start-up or
GPS::enableNonGPSLocationCheckForFailGPSSubsequentStartup for a
subsequent start-up.
Engineering Recommendation: Non-GPS location and movement check
It is strongly recommended to enable the parameters

enableNonGPSLocationCheckForFailGPSInitialStartup and
enableNonGPSLocationCheckForFailGPSSubsequentStartup. This will ensure the location
check will be used if GPS fail.
If these checks pass, the BSR is allowed to transmit the 3G signal. Otherwise, the
operator can still override these checks. For more details refer to 3.9. 291H

Parameter enableNonGPSLocationCheckforFailGPSInitialStar
tup
Object GPS
{True, False}
Class Class 3
Value TRUE
Parameter enableNonGPSLocationCheckforFailGPSSubsequ
entStartup
Object GPS
{True, False}
Class Class 3
Value TRUE
3.10.4 LOCATION BASED SERVICES

When the BSR is allowed to transmit and the GPS receiver has provisioned a
location. The BSR has two sets of geographic location for the Location-based
services:
• Its provisioned location.
• Its GPS location.
If the parameter enableProvisionedlocationReport is set to true, the BSR will
use its provisioned location to respond to a Location Reporting for a Location-
based Services. If it is set to false, the BSR will use its GPS location.
In some cases, the GPS location is less accurate. In consequences, it would be
preferable to use the provisioned location for the Location-based Services.
Parameter enableProvisionedLocationReport
Object GPS
{True, False}
Class Class 3
Value FALSE

3.11. NETWORK OVERLOAD AVOIDANCE
3.11.1 OVERVIEW
In the case of a mass (re-)registration of BSRs with the gateway (FGW) following
for instance a failover of the BSG/FGW from active to standby node, a large
number of Location Area (LA) and Routing Area (RA) updates will be sent towards
the core networks. This can cause overload of the IPC (Iu Protocol Converter) and
MSC/SGSN and other CN nodes.
The BSRs randomly stagger their re-registration times, but as the number of
deployed BSRs increases this mechanism may not be sufficient anymore. The
network overload avoidance has been developed to add a rate-limiting function at
the BSG/FGW which will control the overall rate at which (re) registrations can
succeed.
The rate-limiting function will control the traffic by dropping excessive SCTP INIT
(Stream Control Protocol Initiation) messages. This will cause a rise in the number
of SCTP INITs sent from the BSRs towards the BSG/FGW, due to the re-sending
of INITs, but the rate of successful registrations, and thus traffic towards the CN is
controlled.
3.11.2 CONFIGURATION
3.11.2.1 ACTIVATION
To activate the feature, the parameter sctpInitRateLimit has to be set to a value
different from 0.
3.11.2.2 DESCRIPTION
The configuring of the packet filter shall be performed during the (re)start of
FGW(BSG) software, to ensure it is operational before SCTP associations can be
set-up.
The number of accepted SCTP INIT messages per second can be configured
using the parameters sctpInitRateLimit and sctpInitBurstSize.
If sctpInitRateLimit is non-zero then the packet filter is configured to pass no
more than sctpInitRateLimit SCTP INIT messages per second to SCTP layer with
burst size sctpInitBurstSize.

Parameter - | sctpInitRateLimit
Object | BSG
Granularity | BSG
[0..500]
Class 0
Value 100
Parameter - | sctpInitBurstSize
Object | BSG
Granularity | BSG
[0..100]
Class 0
Value 10

3.12. UL BANDWIDTH OPTIMIZATION
3.12.1 OVERVIEW
The backhaul used for a typical BSR deployment is likely to be DSL which can
have a limited bandwidth. For example the Uplink bandwidth of a PPPoATM DSL
backhaul is typically around 200kbps.
The residential BSR requires the support of 4 simultaneous voice calls. A single
AMR 12.2K voice call requires approximately 84.8kbps, which when scaled up for
4 calls, implies an uplink bandwidth requirement of 339.2 kbps.
As the typically available uplink bandwidth is smaller, issues may occur in the
uplink direction. The downlink bandwidth is usually larger and thus not an issue.
A mechanism is introduced to multiplex multiple CS user plane streams into a
single packet stream to transport voice and/or data packets within the available
backhaul bandwidth.
The use of RTPmux is an optional feature, which is configurable and is likely to be
dependant on the actual backhaul deployed by that operator.
3.12.2 ACTIVATION
RTP multiplexing must be enabled on the BSRs as well as on the FGW.
On the BSR, the activation of RTP multiplexing is done setting the parameter
rtpMuxEnable=TRUE.
On the FGW, the activation of RTP multiplexing is done setting the BVG (BSR
Voice Gateway) parameter rtpMuxEnable=TRUE.
Parameter rtpMuxEnable
Object IUCSUplane
{True, False}
Class Class 3
Value FALSE
Parameter - | rtpMuxEnable
Object | BVG
Granularity | BVG
{True, False}
Class 3
Value FALSE

3.12.3 DESCRIPTION
RTPMux has been introduced to address potential uplink bandwidth exhaustion
when handling voice calls, but it can also be used for CS data calls.
Each voice call generates one RTP packet every 20ms. For transmission over a
DSL line each RTP packet is passed to the lower protocols layers where additional
header bytes are added at each layer causing a large overhead.
Each RTP packet, containing an AMR payload of 31 bytes, is 47 bytes long, but
the total size sent over the DSL line is 212 bytes (efficiency = 14.6%).
RTPMux provides the ability to send multiple RTP packets within one lower layer
packet i.e. with only one set of the lower layer header bytes. As an example, this
enables 4 RTP packets to be sent with 371 bytes over the DSL.
RTPMux introduces a new Header as presented in [3GPP_R14] which increases 29H
slightly the required bandwidth for a single users (therefore not used for a single
user) but brings strong improvements for more CS Voice users.
The required bandwidth to support different number of CS Voice calls with and
without RTPMux is compared in Table 19. 293H
number of voice calls 1 2 3 4

bandwidth w'out RTPmux (kbps) 85 170 254 339
bandwidth with RTPmux (kbps) 85 106 127 148
Table 19 – Required Bandwidth with and without RTP Mux vs number of CS Voice Calls
(PPPoA)
The FGW provides the Mux Port Number (rtpMuxPortNum) during the BSR
registration procedure. The BSR will then forward all RTPmux packets the Mux
Port Number after expiry of the timer rtpMuxTimer.
Parameter rtpMuxTimer
Object IUCSUplane
Range & Unit integer (ms)
[10..50]
Class Class 3
Value 20
Parameter - | rtpMuxPortNum
Object | BVG
Granularity | BVG
[1024..65535]
Class 3
Value 1024

3.13. SPECIFIC BACKHAUL TYPES PARAMETERS
When a BSR is connected to the backhaul via a DSL line, which is typically the
case for Residential deployments, the parameter enableULBWMeasurements
has to be set to TRUE. This will allow the BSR to make measurements of the DSL
bandwidth (as described in [Vol. 4]). 294H
Where DSL backhaul is not used, like in Enterprise deployments, the parameter
enableULBWMeasurements has to be set to False.
Parameter enableULBWMeasurements
Object BSR Profile
{True, False}
Class Class 3
Value TRUE

4. INDEXES
4.1. TABLE INDEX

Table 1 - Mapping tables.................................................................................................................. 15
103H 295H
Table 2- SAI-LAC and SAI-SAC for normal calls / BSR in Closed Access Mode............................ 25
104H 296H
Table 3 - SAI-LAC and SAI-SAC for normal calls / BSR in Open Access Mode ............................. 26
105H 297H
Table 4 - SAI-LAC and SAI-SAC for normal calls / BSR in Semi Open Access Mode .................... 26
106H 298H
Table 5 - SAI-LAC and SAI-SAC for emergency calls ..................................................................... 26

107H 29H
Table 6 - Macro Cell to Sniff............................................................................................................. 29

108H 30H
Table 7 - 3G Radio Criteria .............................................................................................................. 30

109H 301H
Table 8 - 2G Radio Criteria .............................................................................................................. 31

10H 302H
Table 9 - SAI-LAC and SAI-SAC for normal calls / BSR in Closed Access Mode........................... 33
1H 30H
Table 10 - SAI-LAC and SAI-SAC for normal calls / BSR in Open Access Mode ........................... 34
12H 304H
Table 11 - SAI-LAC and SAI-SAC for emergency calls ................................................................... 34

13H 305H
Table 12 - SAI-LAC and SAI-SAC for normal calls / BSR in Semi Open Access Mode .................. 35
14H 306H
Table 13 - SAI-LAC and SAI-SAC in the SAI IE in Location Report RANAP message ................... 36
15H 307H
Table 14 - Super LAC for Open / Semi Open Mode BSR................................................................ 38

16H 308H
Table 15 - BSR Specific Parameters (Residential/Enterprise/Metro) .............................................. 48

17H 309H
Table 16- Supported RAB for different HW variants ........................................................................ 51

18H 310H
Table 17 – Maximum Number of BSR in a Group per Access Type................................................ 53

19H 31H
Table 18 - 2G/3G Macro MCC test result ranges............................................................................. 77

120H 312H
Table 19 – Required Bandwidth with and without RTP Mux vs number of CS Voice Calls (PPPoA)
12H
.................................................................................................................................................. 90
31H
4.2. FIGURE INDEX

Figure 1 - Automatic LAC Configuration .......................................................................................... 23
12H 314H
Figure 2 - Collapsing LAI Detection ................................................................................................. 24

123H 315H
Figure 3 - Super LAC and Air LAC ................................................................................................... 39

124H 316H
Figure 4 - Possible issue with PSC selection................................................................................... 54

125H 317H
Figure 5 - PSC Selection Improvement............................................................................................ 55

126H 318H
Figure 6 - Location Check algorithm ................................................................................................ 61

127H 319H
Figure 7 - Movement Check algorithm ............................................................................................. 65

128H 320H
Figure 8 – National Location Lock algorithm.................................................................................... 70

129H 321H
Figure 9 – Overall GPS Check Procedure ....................................................................................... 79

130H 32H
Figure 10 - An authorized location ................................................................................................... 83

13H 32H

Z END OF DOCUMENT Y


VOLUME 3 POWER MANAGEMENT

CONTENT OF VOLUME 3
1. INTRODUCTION............................................................................................................................2
1.1. OBJECT....................................................................................................................................2

2.1. FPUG VOLUMES ......................................................................................................................2
3. POWER MANAGEMENT ..............................................................................................................4

3.1. CPICH POWER SETTING ..........................................................................................................4
3.1.1 CPICH Power Range ......................................................................................................4
3.1.2 CPICH Power update based on Coverage .....................................................................5
3.1.2.1 bsrBasedPilotPowerAdjustMode set to mimBased .....................................................5
3.1.2.2 bsrBasedPilotPowerAdjustMode set to rscpBased .....................................................6
3.1.2.3 bsrBasedPilotPowerAdjustMode set to ecIoBased .....................................................8
3.1.3 CPICH Power update based on UE receiver range........................................................9
3.1.4 CPICH Power update based on UE measurements.....................................................10
3.1.5 CPICH Power update based on admission ..................................................................12
3.2. BSR TX POWER .....................................................................................................................19
3.3. OTHER DL COMMON CHANNEL POWER SETTING ......................................................................19
3.4. ENHANCEMENT OF CONTROL POWER ......................................................................................23
4. FEMTO RECEIVER CONTROL ..................................................................................................24
5. UL INTERFERENCE MANAGEMENT ........................................................................................25

5.1. BSR START-UP ...................................................................................................................25
5.2. CHANGE IN NEIGHBOUR BSR CONFIGURATION .........................................................................25
5.3. MEASUREMENT HANDLING ......................................................................................................26
6. INDEXES .....................................................................................................................................30
6.1. TABLE INDEX ..........................................................................................................................30
6.2. FIGURE INDEX ........................................................................................................................30

1. INTRODUCTION
1.1. OBJECT
This volume is dedicated to Features and Parameters related to the Power
Management of BSRs.
2.1. FPUG VOLUMES


[Vol. 10] HSxPA


specification

reception (FDD)
specification

[3GPP_R14] 3GPP TS 25.101 User Equipment (UE) radio transmission and
reception (FDD)


3. POWER MANAGEMENT
3.1. CPICH POWER SETTING
3.1.1 CPICH POWER RANGE

The following sections define the different algorithms that aim at updating CPICH
power which always remains within its range, defined by the 2 following limits,
max(minPilotPowerdBm,minBSRPowerdBm-10dB) and
min(maxPilotPowerdBm,maxBSRPowerLimitdBm-10dB).
minPilotPowerdBm is also used to control the minimum BSR pilot coverage to

maintain the BSR's minimum coverage.
Parameter minPilotPowerdBm
Object AutoConfigPW
Range & Unit Real [dBm]
[-50.0..24.0] step 0.1
Class Class 3
Value -20
maxPilotPowerdBm is also used to control the maximum BSR pilot coverage, in

order to reduce the BSR's interference to neighbour cells
Inter-Release Delta: maxPilotPowerdBm
From BCR3.0, a BSR Hardware Profile is introduced. The maxPilotPowerdBm can be found
under this Profile.
Parameter maxPilotPowerdBm
Object AutoConfigPW
[-50.0..24.0] step 0.1
Class Class 3
Value 20

Engineering Recommendation: maxPilotPowerdBm
Keeping in mind that MaxBSRPowerdBm is 10 dB higher than CPICH power (cf. section 3), it is
recommended to set maxPilotPowerdBm 10 dB lower than maxBSRPowerLimitdBm
Restriction: CPICHPower Hardware limitation
Due to Hardware limitations, the maximum Pilot Power that can be achieved is limited to the
maximum output power of the BSR reduced by 10dB. This will pre-empt any parameter
configuration.
3.1.2 CPICH POWER UPDATE BASED ON COVERAGE

The dynamic setting of CPICH power is enabled through
bsrBasedPilotPowerAdjustMode parameter.
Parameter bsrPilotPowerAdjustMode
Object BSR Profile
{mimBased, rscpBased, ecIoBased}
Class Class 3
Value mimBased
When setting the parameter value to mimBased, the BSR will use a static power
value.
When setting the parameter value to rscpBased, the BSR will calculate a power
value based on coverage considerations.
When setting the parameter value to ecIoBased, the BSR will adapt the power
value based on measurement considerations.
More details on the different settings can be found in the following sections.
3.1.2.1 bsrBasedPilotPowerAdjustMode set to mimBased
When set to mimBased, BSR uses pCPICHPower as the static CPICH power.
Inter-Release Delta: pCPICHPower
From BCR3.0, a BSR Hardware Profile is introduced. The pCPICHPower can be found under this
object.

Parameter pCPICHPower
Object Lcell
Range & Unit Real (dBm)
[-50…20] step 0.1
Class Class 3
Value 3
3.1.2.2 bsrBasedPilotPowerAdjustMode set to rscpBased
When set to rscpBased, BSR adjusts CPICH power using the following formula:
CPICHpower[new]= targetPilotRSCPdBm + MaximumPathLoss -
antennaGainIncLoss
where:
• MaximumPathLoss=FreeSpacePathloss + indoorPenetrationLoss
o FreeSpacePathloss = 20*log10(DL_frequencyMHz) +
20*(slopeFactor) + 20*log10(maxCoverageDistancem) –
27.5582 + htCorrectionFactor
Parameter targetPilotRSCPdBm
Object AutoConfigPW
[-120.0..-30.0] step 0.1
Class Class 3
Value -100
Parameter antennaGainIncLoss
Object AutoConfigPW
Range & Unit Real [dBi]
[-25.0..25.0] step 0.1
Class Class 3
Value 0
• indoorPenetrationLoss is used to control the minimum BSR pilot coverage, in

order to maintain the BSR's minimum coverage.

Parameter indoorPenetrationLoss
Object AutoConfigPW
Range & Unit Real [dB]
[0.0..100.0] step 0.1
Class Class 3
Value 30
• slopeFactor is the slope correction factor.
Parameter slopeFactor
Object AutoConfigPW
Range & Unit Real
[-5.0..5.0] step 0.1
Class Class 3
Value 1
• maxCoverageDistancem is used to adjust the BSR coverage within the limit

set by maxPilotPowerdBm.
Parameter maxCoverageDistancem
Object AutoConfigPW
Range & Unit Real [meters]
[1.0..2000.0] step 0.1
Class Class 3
Value 30
• htCorrectionFactor is the correction factor for the antenna height.
Parameter htCorrectionFactor
Object AutoConfigPW
Range & Unit Real
[-50.00..50.00] step 0.01
Class Class 3
Value 0

Inter-Release Delta: Extended Cell Range
From BCR 3.0, if ExtendedCellEnable is set to True and the baseband supports an extended cell
range then maxCoverageDistancem can be configured up to 2km. The free space pathloss model
is extended to include a slope correction factor, slopeFactor and a height offset,
htCorrectionFactor. The calculation of the pCPICH power for rscpBased and ecIoBased modes is
extended to include an antenna gain factor which also includes cable losses
(antennaGainIncLoss).
Restriction: Extended Cell Range
If ExtendedCellEnable is set to True, but the baseband does not support extended cell range, or if
ExtendedCellEnable is set to False, then the Femto operates in standard range mode and caps
maxCoverageDistancem at 200m, does not use the parameters antennaGainIncLoss and
htCorrectionFactor, and slopeFactor is set to 1.
Parameter extendedCellEnable
Object BSR Profile
{True, False}
Class Class 3
Value false
Only the femto baseband device used in V2 Metro and V2 Enterprise (250mW) supports a cell
radius of up to 2km with UE speeds of up to 120km/hr (chip dependent).
3.1.2.3 bsrBasedPilotPowerAdjustMode set to ecIoBased
When set to ecIoBased, the BSR dynamically adjusts CPICH power based on
measurements, using the following formula:
CPICHpower[new]= targetPilotEcIodB + IodBm + MaximumPathLoss -

antennaGainIncLoss
where:
• IodBm is the average UTRA (UMTS Terrestrial Radio Access) RSSI (converted
in dBm) measured during the network listening period
(bsrBasedPilotPowerAdjustInterval seconds)
• MaximumPathLoss is defined as for rscpBased mode.
ecIoBased mode is only applicable when the 3G Network Listening feature is

enabled, i.e. when umtsNtwkListenEnableFlag is set to True (cf. [Vol. 5]).

The extended cell range restrictions of the rscpBased mode also apply to the
ecIoBased mode.
Parameter targetPilotEcIodB
Object AutoConfigPW
[-25.0..0.0] step 0.1
Class Class 3
Value -10
Parameter bsrBasedPilotPowerAdjustInterval
Object AutoConfigPW
Range & Unit Integer [secs]
[0..600]
Class Class 3
Value 120
3.1.3 CPICH POWER UPDATE BASED ON UE RECEIVER RANGE

To make sure that the total power received by UE remains within its dynamic
receiver range, an UE internal measurement is configured after RAB
establishment: Event 6E is then reported by UE when measuring a RSSI that
reaches its dynamic receiver range (as specified by [3GPP_R02]).
Parameter e6eTriggerEnabled
Object BSR Profile
{True, False}
Class Class 3
Value TRUE
• e6eTimetoTrigger in ms, indicates the period of time between the timing

of event detection and the timing of sending Measurement Report (Event
6E).

Parameter e6eTimetoTrigger
Object BSR Profile
{ttt0, ttt10, ttt20, ttt40, ttt60, ttt80, ttt100, ttt120, ttt160,
ttt200, ttt240, t320, ttt640, ttt1280, ttt2560, ttt5000}
Class Class 3
Value ttt640
When the BSR receives such Event 6E, it increases or reduces the CPICH power
by pAdjustmentStepdB, keeping the new CPICH power inside its allowed range.
The decision to increase or decrease the power is based on the parameter
e6eUePowerThresholddBm.
Additionally a recovery process has been implemented to avoid that the changes
unnecessarily impact on performance in the BSR coverage area.
This is done by modifying the CPICH Power in eventRecoverySteps steps during
eventRecoveryTimem minutes.
Parameter eventRecoveryTimem
Object BSR Profile
Range & Unit Integer (min)
[1…60]
Class Class 3
Value 5
Parameter eventRecoverySteps
Object BSR Profile
[0…10]
Class Class 3
Value 2
Parameter e6eUePowerThresholddBm
Object BSR Profile
[-50…0]
Class Class 3
Value -40
3.1.4 CPICH POWER UPDATE BASED ON UE MEASUREMENTS

Once a new RAB is established, BSR may configure at UE side Events 1C and 1F:

• Event 1C: The CPICH of an intra-frequency monitored (or detected) cell
becomes better than the active BSR’s.
• Event 1F: the active BSR’s CPICH becomes worse than an absolute
threshold.
ueBasedPilotPowerAdjustMode allows to activate this feature and to define how

CPICH power is updated.
Parameter ueBasedPilotPowerAdjustMode
Object BSR Profile
{disable, targetEcIo, neighbourEcIo}
Class Class 3
Value targetEcIo
When set to disable, the BSR does not use UE measurements to update CPICH
power; both Events are thus not configured.
When set to neighbourEcIo, the BSR only configures Event 1C and optimizes the
CPICH power by comparing the CPICH Ec/Io of all Intra-frequency reported cells,
as follows:
If
Active BSR’s CPICH Ec/Io < Neighbouring cell’s CPICH Ec/Io
then
CPICHpower[new] = CPICHpower[old] + pAdjustmentStepdB
Parameter pAdjustmentStepdB
Object AutoConfigPW
[0.0..10.0] step 0.1
Class Class 3
Value 3
When set to targetEcIo, the BSR only configures Event 1F and optimizes the
CPICH power based on the worst CPICH Ec/Io (of this active BSR) reported by
any UE in DCH during the last ueBasedPilotPowerAdjustInterval seconds, as
follows:

If
Active BSR’s CPICH Ec/Io < targetPilotEcIodB
then
CPICHpower[new] = CPICHpower[old] + pAdjustmentStepdB
Parameter ueBasedPilotPowerAdjustInterval
Object AutoConfigPW
[0..600]
Class Class 3
Value 120
Engineering Recommendation: UE based pilot coverage control / intra-freq handover
If UE based pilot coverage control is enabled, then BSR CPICH power is increased as Macro
CPICH becomes stronger. That will lead to a race between UE based pilot coverage and Intra-
Frequency Mobile Assisted Handover (MAHO). Therefore those two features should not be
activated together.
A recovery mechanism similar to the one described in 3.1.3 is implemented to get

back to the original CPICH configuration after a given time.
This is done by modifying the CPICH Power in eventRecoverySteps steps during

eventRecoveryTimem minutes.
3.1.5 CPICH POWER UPDATE BASED ON ADMISSION

Dynamic adaptation of BSR coverage is enabled through parameter
enableCoverageSelfOptimsationBasedOnAdmission.
Inter-Release Delta: feature 108877 - CPICH Power Update based on admission
This feature is supported from BCR3.0.
For co-channel deployments, the purpose of this feature is to limit the degradation
of the macro network coverage close to the BSR.
For dedicated channel deployments, it can be enabled in order to reduce the

signaling load due to mobility procedures.

Parameter enableCoverageSelfOptimisationBasedOnAdmissi
on
Object Femto | BSR
{True, False}
Class Class 0
Value false
Restriction: closed access deployments only
The auto-configuration algorithm uses BSR admission system based on ACL ( [Vol. 5]). Therefore,
it has to be disabled for open access and prioritised open access deployments.
Rule: CPICH power updated based on UE measurements
If there is at least one UE in Cell DCH and the parameter ueBasedPilotPowerAdjustMode is not
set to “disable”, the CPICH power will be updated according to UE measurements. CPICH power
update based on admission will be temporarily overridden.
If the feature is enabled, each admissionBasedPilotPower.decreaseTestPeriod

minutes, the following test is performed and the pilot power is decreased if
necessary.
decreaseMeasuredEventRate = numUeRejectEventCount /
admissionBasedPilotPower.DecreaseMeasurementPeriod
where numUeRejectEventCount is the number of ACL rejections during the
measurement period.
decreaseThresholdEventRate =
admissionBasedPilotPower.DecreaseEventThreshold /
admissionBasedPilotPower.DecreasePeriodThreshold
If
numUeRejectEventCount >
admissionBasedPilotPower.decreaseEventMinimum
and
decreaseMeasuredEventRate > decreaseThresholdEventRate
then
CPICHpower[new] = CPICHpower[old] -
admissionBasedPilotPower.decreaseStepdB

Parameter admissionBasedPilotPowerControlDecreaseTestP
eriod | decreaseTestPeriod
Object AutoConfigPW |
admissionBasedPilotPowerControl
Range & Unit Integer [mins]
[1..120]
Class Class 3
Value 10
Parameter admissionBasedPilotPowerControlDecreaseMeasu
rementPeriod | decreaseMeasurementPeriod
[1..1440]
Class Class 3
Value 60
Parameter admissionBasedPilotPowerControlDecreaseEvent
Threshold | decreaseEventThreshold
[1..100]
Class Class 3
Value 10
Parameter admissionBasedPilotPowerControlDecreasePerio
dThreshold | decreasePeriodThreshold
[1..120]
Class Class 3
Value 60

Parameter admissionBasedPilotPowerControlDecreaseEvent
Minimum | decreaseEventMinimum
[1..100]
Class Class 3
Value 5
Parameter admissionBasedPilotPowerControlDecreaseStepd
B | decreaseStepdB
[0.0..10.0] step 0.1
Class Class 3
Value 1
If the period, since the last BSR restart or power change, has reached
admissionBasedPilotPower.increaseMeasurementPeriod minutes, the
following test is performed each
admissionBasedPilotPower.increaseTestPeriod minutes. Then the pilot power
is increased if necessary.
increaseMeasuredEventRate = numUeRejectEventCount /
admissionBasedPilotPower.increaseMeasurementPeriod
where numUeRejectEventCount is the number of ACL rejections during the
measurement period.
increaseThresholdEventRate =
admissionBasedPilotPower.increaseEventThreshold /
admissionBasedPilotPower.increasePeriodThreshold
If
increaseMeasuredEventRate < increaseThresholdEventRate
then
CPICHpower[new] = CPICHpower[old] +
admissionBasedPilotPower.increaseStepdB

Parameter admissionBasedPilotPowerControlIncreaseTestPe
riod | increaseTestPeriod
[1..120]
Class Class 3
Value 30
Parameter admissionBasedPilotPowerControlIncreaseMeasur
ementPeriod | increaseMeasurementPeriod
[1..1440]
Class Class 3
Value 60
Parameter admissionBasedPilotPowerControlIncreaseEventT
hreshold | increaseEventThreshold
[1..100]
Class Class 3
Value 1
Parameter admissionBasedPilotPowerControlIncreasePeriod
Threshold | increasePeriodThreshold
[1..120]
Class Class 3
Value 60

Parameter admissionBasedPilotPowerControlIncreaseStepd
B | increaseStepdB
[0.0..10.0] step 0.1
Class Class 3
Value 1
This process may lead to a degradation of the BSR coverage if the BSR is badly
positioned (e.g. close to a window overlooking the street). To avoid that problem,
the auto-configuration phase can take outgoing mobility events into account. This
is enabled through the parameter
enableCoverageSelfOptimsationBasedOnMacroHO.
Parameter enableCoverageSelfOptimisationBasedOnMacroH
O
Object Femto | BSR
{True, False}
Class Class 0
Value false
If the period, since the last BSR restart or power change, has reached
MacroHOPilotPower.measurementPeriod minutes, the following test is
performed each MacroHOPilotPower.testPeriod minutes. Then the pilot power is
increased if necessary.
macroHOMeasuredEventRate = numMacroHOEventCount /
MacroHOPilotPower.measurementPeriod
where numUeMacroHOEventCount is the number of macro HO events during the
measurement period.
macroHOThresholdEventRate = MacroHOPilotPower.eventThreshold /
MacroHOPilotPower.periodThreshold
If
macroHOMeasuredEventRate > macroHOThresholdEventRate
then
CPICHpower[new] = CPICHpower[old] + MacroHOPilotPower.adjustmentStep

Parameter macroHOPilotPowerControlTestPeriod | testPeriod
Object AutoConfigPW | macroHOPilotPowerControl

[1..120]
Class Class 3
Value 30
Parameter macroHOPilotPowerControlMeasurementPeriod |
measurementPeriod
[1..1440]
Class Class 3
Value 60
Parameter macroHOPilotPowerControlEventThreshold |
eventThreshold
[1..100]
Class Class 3
Value 10
Parameter macroHOPilotPowerControlPeriodThreshold |
periodThreshold
[1..120]
Class Class 3
Value 60
Parameter macroHOPilotPowerControlAdjustmentStep |
adjustmentStep
[0.0..10.0] step 0.1
Class Class 3
Value 1
Note: Activation and parameterization of this feature have to be carefully

performed as it may lead to undesirable femto coverage holes.

3.2. BSR TX POWER
Since the BSR CPICH power is dynamically updated as presented in section 3.1.1
through 0, the BSR maximum power is also adjusted according to the following
formula:
MaxBSRPowerdBm = min (maxBSRPowerLimitdBm, pCPICHpower_dBm+10)
This makes CPICH power always 10 dB lower than MaxBSRPowerdBm, with the
maximum transmission power still within the limit maxBSRPowerLimitdBm.
In parallel, the BSR Tx Power must always be kept above minBSRPowerdBm.
Inter-Release Delta: maxBSRPowerLimitdBm
From BCR3.0, a BSR Hardware Profile is introduced. The maxBSRPowerLimitdBm can be found
under this Profile.
Parameter maxBSRPowerLimitdBm
Object Lcell
[-50…24] step 0.1
Class Class 3
Value 13
Parameter minBSRPowerdBm
Object AutoConfigPW
[-50.0..24.0] step 0.1
Class Class 3
Value 0
Restriction: Max BSR Power
Due to Hardware protection, the maximum allowed output power is given by the Hardware,
independently of any parameter configuration.
3.3. OTHER DL COMMON CHANNEL POWER SETTING

The following parameters define the setting for other DL common channels.

• bCHPower defines the Broadcast Channel (BCH) power, in dB, with
respect to P-CPICH power.
Parameter bCHPower
Object Lcell
Range & Unit Real (dB)
[-35…15] step 0.1
Class Class 3
Value -3
• pSCHPower defines the Primary Synchronization Channel (SCH) power,

in dB, with respect to P-CPICH power.
Parameter pSCHPower
Object Lcell
[-35…15] step 0.1
Class Class 3
Value -3
• sSCHPower defines the Secondary SCH power, in dB, with respect to

CPICH power.
Parameter sSCHPower
Object Lcell
[-35…15] step 0.1
Class Class 3
Value -5
• aICHPower defines the Acquisition Indication Channel (AICH) power, in

dB, with respect to CPICH power.
Parameter aICHPower
Object LCell::CCPower
[-35…15] step 0.1
Class Class 3
Value -5

• fACHSigPower defines the output power level of the Signaling FACH
transport channel, in dB, with respect to CPICH power.
Parameter fACHSigPower
[-35…15] step 0.1
Class Class 3
Value 4
• pCHPower defines the Paging Channel (PCH) power, in dB, with respect
to CPICH power.
Parameter pCHPower
[-35…15] step 0.1
Class Class 3
Value 4
• pICHPower defines the PICH power, in dB, with respect to CPICH power.
Parameter pICHPower
[-35…15] step 0.1
Class Class 3
Value -5

Rule: Ensuring that the sum of common channel powers does not exceed the maximum
transmission power.
Defining, dBm2mW(x) = 10^(x/10), let:

• MaxTPmW = dBm2mW(maxBSRPowerLimitdBm)
• PCPICHmW = dBm2mW(maxPilotPowerdBm)
• PCCPCHmW = dBm2mW(pCPICHPower + bCHPower)

• PSCHmW = dBm2mW(pCPICHPower + pSCHPower)
• SSCHmW = dBm2mW(pCPICHPower + sSCHPower)
• AICHmW = dBm2mW(pCPICHPower + aICHPower)

• FACHSigmW = dBm2mW(pCPICHPower + fACHSigPower)
• PCHmW = dBm2mW(pCPICHPower + pCHPower)
• PICHmW = dBm2mW(pCPICHPower + pICHPower)

The recommended setting must ensure that:
PCPICHmW + max(PCCPCHmW, (PSCHmW + SSCHmW)) + FACHSigmW+ PCHmW + PICHmW
+ AICHmW <= MaxTPmW
Table 1 depicts the recommended setting and the maximum power used for
common channels so that the previous rule is fulfilled.
Power Power Power (mW) %

offset (dBm) vs. Total
(dB)
maxBSRPowerLimitdBm 13 20
autoConfigPWmaxPilotPowerdBm 3 2 10%
bCHPower -3 0 1 5.00%
pSCHPower -3 0 1 5.00%
sSCHPower -5 -2 0.63 3.15%
aICHPower -5 -2 0.63 3.15%
fACHSigPower 4 7 5.01 25.05%
pCHPower 4 7 5.01 25.05%
pICHPower -5 -2 0.63 3.15%
Table 1 - Power reservation for common channels
Note The Common Control channels are not all always active. The combined
activation consumes about 20% of the BSR total power.

3.4. ENHANCEMENT OF CONTROL POWER

The BSR Enhancement of Control Power enables the BSR MAC-hs (Medium
Access Control – High Speed) to be able to allocate the HSDPA Tx power
according to the used R99 + common channels and the upper limit defined in the
NBAP (Node B Application Protocol) as shown in Figure 1.
Thus, with this feature, if not all the HSDPA (High Speed Downlink Packet Access)
power is allocated or if no HSDPA users are active, the remaining power can be
utilized for R99 channels.
The HSDPA dynamic power allocation is enabled/disabled via the parameter
hSDPADynamicPowerEnabled.
When enabled, the BSR MAC-hs allocates the HSDPA Tx power according to the
used R99 + common channels and the upper limit defined through the parameter
hsdpaAndEdchTotalDLpower.
Additionally the HSDPA scheduler reserves a certain margin,
hsdpaDynamicPwrHeadroom, to prevent total downlink power clipping.
Amplifier Capability
R99 Power
HSDPA Power
Overhead Power
Figure 1 - Dynamic HSDPA Power Allocation

Parameter hSDPADynamicPowerEnabled
Object Femto | BSR
{True, False}
Class Class 3
Value TRUE
Parameter hsdpaAndEdchTotalDLpower
[0…50] step 0.5
Class Class 1
Value 9
Parameter hsdpaDynamicPwrHeadroom
Range & Unit Integer [0.1%]
[0…1000]
Class Class 3
Value 50
Note: the Unit of hsdpaDynamicPwrHeadroom is 0.1%. This means that setting

this parameter to a value of 10 would mean 1%.
4. FEMTO RECEIVER CONTROL
The goal of the Automated Femto Receiver Gain Control is to automatically change
the BSR uplink receiver gain. This is to enable the AP to work in a wider dynamic
range of the interference level than what the 3GPP has requested and to prevent
call drops in high interference scenarios, by ensuring receiver doesn't go into
overload. This improvement has been introduced in BCR2.2 and will be
automatically embedded in new releases.
A mechanism has been developed to avoid overloading the BSR receiver, which
may lead to a feedback cycle where all calls can be dropped. If the digital receiver
of the base band processor reported total received wide band power is higher than
the configured threshold, then a gain adjustment is done to reduce the receiver
gain. If it is lower, then adjustments are performed to increase the receiver gain

5. UL INTERFERENCE MANAGEMENT
Inter-Release Delta: UL Interference Management
From BCR 3.0, the feature UL Interference Management allows the reduction of the UL
interferences that a Femto UE can create into a Macro or a Femto cell, limiting thus the macro
coverage and resulting in bad UL performances (UE throughput and cell capacity).
5.1. BSR START-UP

If ulIntfCtrlMacroEnabled is set to True, the BSR identifies all intra-frequency
macro neighbour cells, i.e. whose band and UL UARFCN equal to the BSR’s band
and UL UARFCN.
These cells are called potentially interfered macro neighbour cells.
Parameter ulIntfCtrlMacroEnabled
Object BSR Profile
{True, False}
Class Class 3
Value false
If ulIntfCtrlFemtoEnabled is set to True, the BSR identifies all intra-frequency

Femto neighbour cells, i.e. whose band and UL UARFCN equal to the BSR’s band
and UL UARFCN.
These cells are called potentially interfered Femto neighbour cells.
Parameter ulIntfCtrlFemtoEnabled
Object BSR Profile
{True, False}
Class Class 3
Value false
The BSR reads and stores the CPICH Tx Power for all potentially interfered macro
and Femto neighbour cells.
5.2. CHANGE IN NEIGHBOUR BSR CONFIGURATION

If the BSR is in a Femto group, it notifies other neighbour BSRs in the same group
about a change in its CPICH Tx Power.

If a notification from another Femto BSR is received about a change in its CPICH
Tx Power, the BSR stores this information and, if applicable, the maximum UL Tx
power of the affected UEs is adapted to the new setting accordingly with the next
measurement report for this UE.
5.3. MEASUREMENT HANDLING

If at the establishment of an UL RAB with a data rate bigger than or equal to
ulIntfCtrlMinDataRate either
a) a potentially interfered macro neighbour cell exists, or
b) a potentially interfered Femto neighbour cell exists
then the FBSR starts to monitor the RTWP received by the FBSR.
Parameter ulIntfCtrlMinDataRate
Object BSR Profile
Range & Unit Integer [kbps]
[0..16000]
Class Class 3
Value 384
As soon as the RTWP received by the FBSR exceeds ulIntfCtrlMinRTWP, the

BSR starts, for each UE with an UL RAB with a data rate bigger than or equal to
ulIntfCtrlMinDataRate, a periodic intra-frequency measurement to report the
CPICH RSCP of the intra-frequency neighbour cells.
The reporting interval is set to ulIntfCtrlMeasPeriod.
Parameter ulIntfCtrlMinRTWP
Object BSR Profile
[-120..0]
Class Class 3
Value -94

Parameter ulIntfCtrlMeasPeriod
Object BSR Profile
{reportinginterval250=250, reportinginterval500=500,
reportinginterval1000=1000,
reportinginterval64000=64000}
Class Class 3
Value reportinginterval1000
The FBSR initialises the current maximum UL Tx power for an UE with the
maximum UL Tx power determined by the BSR for the UE.
Generally the maximum UL Tx power is given by the UE’s power class Pmax,UE (as
specified by [3GPP_R14]). However, the maximum UL Tx power Pmax,UE might
already be reduced by the FBSR due to other features.
The maxUlTxPower sets an upper limit to the maximum UL Tx power that can be
signalled at each non-EDCH call establishment to an UE.
Parameter maxUlTxPower
Object LCell
[-50..33]
Class Class 3
Value 33
The maxUlTxPowerEdch sets an upper limit to the maximum UL Tx power that

can be signalled at each EDCH call establishment to an UE.
Parameter maxUlTxPowerEdch
Object LCell
[-50..33]
Class Class 3
Value 33

In the scope of this document, the following quantities are used:
• Pmax,UE is the UE's static maximum UL Tx power according to its power
class. This might also be reduced to a lower value due to maxUlTxPower
or maxUlTxPowerEdch.
• PmaxTx,UE is the dynamically determined current maximum UL Tx power
according to this feature.
Each time a measurement report is received the FBSR checks if a potentially

interfered neighbour cell is reported.
FBSR calculates the UE’s maximum UL Tx power PmaxTx,UE as the minimum of all
reported potentially interfered neighbour cells
PmaxTx,UE = min(PmaxNCellInterferenceLevel + PLNCell) =
= min(PmaxNCellInterferenceLevel + PCpichNCell − PRscpNCell)
Where:
• PmaxNCellInterferenceLevel is ulIntfCtrlMaxMacroInterferenceLevel for macro
neighbour cells or ulIntfCtrlMaxFemtoInterferenceLevel for Femto
neighbour cells.
• PLNCell is the pathloss for this neighbour cell.
• PCpichNCell is the CPICH Tx power as stored for this neighbour cell.

• PRscpNCell is the CPICH RSCP as measured and reported by the UE for this
neighbour cell.
For all potentially interfered neighbour cells which are not reported, PmaxTx,UE for
this cell is set to the UE’s maximum UL Tx power Pmax,UE according to the UE’s
power class or lower, if limited due to other features.
Parameter ulIntfCtrlMaxMacroInterferenceLevel
Object BSR Profile
[-120..-80]
Class Class 3
Value -106
Parameter ulIntfCtrlMaxFemtoInterferenceLevel
Object BSR Profile
[-120..-80]
Class Class 3
Value -100

If PmaxTx,UE is smaller than the currently stored maximum UL Tx power, the FBSR
initiates a Physical Channel Reconfiguration procedure to reduce the UE’s
maximum UL Tx power to the newly calculated value PmaxTx,UE.
If PmaxTx,UE exceeds the currently stored maximum UL Tx power by
ulIntfCtrlTxPwrHyst, the FBSR initiates a Physical Channel Reconfiguration
procedure to increase the UE’s maximum UL Tx power to the newly calculated
value PmaxTx,UE.
Parameter ulIntfCtrlTxPwrHyst
Object BSR Profile
[0..30]
Class Class 3
Value 3
If the RTWP received by the FBSR falls below

UlInftfCtrlMinRTWP−ulInftfCtrlMinRTWPHyst, the FBSR initiates a Physical
Channel Reconfiguration procedure to increase the UE’s maximum UL Tx power
back to the value given before the UL interference control was applied, Pmax,UE.
Parameter ulIntfCtrlMinRTWPHyst
Object BSR Profile
[0..30]
Class Class 3
Value 3
As soon as the RTWP received by the FBSR falls below

UlInftfCtrlMinRTWP−ulInftfCtrlMinRTWPHyst, and the periodic intra-frequency
measurement is started, the BSR stops these measurements.

6. INDEXES
6.1. TABLE INDEX

Table 1 - Power reservation for common channels.......................................................................... 22
6.2. FIGURE INDEX

Figure 1 - Dynamic HSDPA Power Allocation.................................................................................. 23

Z END OF DOCUMENT Y


VOLUME 4 RADIO RESOURCES MANAGEMENT

CONTENT OF VOLUME 4
1. INTRODUCTION............................................................................................................................3
1.1. OBJECT....................................................................................................................................3

2.1. FPUG VOLUMES ......................................................................................................................3
2.4. STANDARDS DOCUMENTS .........................................................................................................4
3. RADIO RESOURCE MANAGEMENT...........................................................................................5

3.1. RRC STATES AND STATE TRANSITIONS .....................................................................................5
3.1.1 RRC States .....................................................................................................................5
3.1.2 RRC State Transitions ....................................................................................................6
3.1.2.1 CelL_FACH .................................................................................................................6
3.1.2.2 CelL_DCH .................................................................................................................10
3.2. SIGNALING OVER 13.6KBPS DCCH .........................................................................................13
3.3. SIGNALLING OVER CELL_FACH ..............................................................................................14
3.3.1 Description ....................................................................................................................14
3.3.2 Exception ......................................................................................................................15
3.3.3 Cell Update Scenarios ..................................................................................................16
3.3.4 FACH to DCH Failure ...................................................................................................16
3.3.4.1 Procedure Guard Timer.............................................................................................16
3.3.4.2 Physical Channel Failure...........................................................................................17
3.3.4.3 UE Bug Work Around ................................................................................................18
3.3.5 SIB Broadcast For Cell_FACH State ............................................................................19
3.3.6 RRC Connection Release.............................................................................................20
3.3.7 Supervision Timer - Maximum Duration in Cell_FACH state........................................22
3.4. PAGING ..................................................................................................................................24
3.4.1 Standard Paging ...........................................................................................................24
3.4.1.1 PAGING TYPE 1 .......................................................................................................24
3.4.1.2 PAGING TYPE 2 .......................................................................................................25
3.4.2 Increased Paging Capacity For Public Femto Cells .....................................................26
3.5. CALL ADMISSION CONTROL .....................................................................................................34
3.5.1 Emergency Call redirection...........................................................................................34
3.5.2 Backhaul Resource Management.................................................................................35
3.5.2.1 Reserved bandwidth..................................................................................................35
3.5.2.2 Bandwidth Measurements.........................................................................................36
3.5.2.3 Transport CAC Checks at RRC establishment .........................................................37
3.5.2.4 Transport CAC Checks at RAB establishment..........................................................38
3.5.2.5 Transport CAC and Emergency Call .........................................................................39
3.5.3 Load Estimation ............................................................................................................39
3.5.3.1 UL Load Calculation ..................................................................................................39
3.5.3.2 DL Load Calculation ..................................................................................................40
3.5.4 Processing CAC............................................................................................................40
3.5.4.1 CAC rejection for non-Emergency calls ....................................................................40
3.5.4.2 CAC rejection for Emergency calls............................................................................42
3.5.5 Cell_FACH CAC............................................................................................................43

3.5.6 Rejecting RRC Connection ...........................................................................................44
3.6. DYNAMIC BEARER CONTROL ...................................................................................................45
3.6.1 DBC based on UL & DL Load measurement................................................................45
3.6.2 DBC based on Baseband processing limitation............................................................49
3.7. AIR INTERFACE CONGESTION CONTROL...................................................................................50
3.8. CAC/DBC IN CASE OF HANDOVER FOR HIGHER PRIORITY SERVICES ........................................50
3.8.1 Successful Cases..........................................................................................................51
3.8.2 Failure Cases ................................................................................................................51
3.8.2.1 Backhaul Check.........................................................................................................51
3.8.2.2 Emergency Calls with Failed Transport CAC............................................................52
3.8.2.3 Emergency Calls .......................................................................................................53
3.8.2.4 Normal Calls ..............................................................................................................54
3.9. MULTIPLE PDP CONTEXTS .....................................................................................................56
3.9.1 Introduction ...................................................................................................................56
3.9.2 Feature activation..........................................................................................................57
3.9.3 MAC ..............................................................................................................................58
3.9.4 Call Flows......................................................................................................................58
3.10. SERVICE BASED REDIRECTION & HANDOVER TO TARGETED MACRO LAYER ..............................60
3.10.1 Introduction ...................................................................................................................60
3.10.2 Redirection at RRC Connection....................................................................................61
3.10.3 Handover at CS RAB Establishment ............................................................................64
3.10.4 Service Based Action on Incoming Handover ..............................................................67
3.11. PDP DEACTIVATION DURING MACRO <-> BSR MOBILITY .........................................................68
3.11.1 Activation.......................................................................................................................68
3.11.2 Assumptions - Restrictions ...........................................................................................68
3.11.3 Incoming Shutdown of Data Session ............................................................................69
3.11.4 Outgoing Shutdown of Data Session ............................................................................69
3.11.4.1 UE Context ................................................................................................................70
3.11.4.2 RAU Location Update and Attach .............................................................................70
3.11.4.3 Periodic RAU .............................................................................................................70
3.11.4.4 Service Request ........................................................................................................71
3.11.4.5 PDP Context activation in the BSR Femto................................................................71
3.11.4.6 RAB Assignment .......................................................................................................72
3.11.4.7 PDP deactivation .......................................................................................................73
4. INDEXES .....................................................................................................................................74
4.1. TABLE INDEX ..........................................................................................................................74
4.2. FIGURE INDEX ........................................................................................................................74

1. INTRODUCTION
1.1. OBJECT
This volume is dedicated to the Features and Parameters related to the Radio
Resources Management
2.1. FPUG VOLUMES


[Vol. 10] HSxPA

specification


reception (FDD)
specification


2.4. STANDARDS DOCUMENTS

[S. 1] RFC 792 Internet Control Message Protocol, September 1981
[S. 2] Evaluation and Characterization of Available Bandwidth Probing
Techniques; Ningning Hu, Student Member, IEEE,
and Peter Steenkiste, Senior Member, IEEE

3. RADIO RESOURCE MANAGEMENT
3.1. RRC STATES AND STATE TRANSITIONS
3.1.1 RRC STATES

Figure 1 shows the UTRAN (Universal Terrestrial Radio Access Network) RRC
states and state transitions supported by the BSR.
Idle Mode: After power on, the UE stays in Idle Mode until it transmits a request to
establish an RRC Connection. In Idle Mode the connection of the UE is closed on
all layers of the access stratum. In Idle Mode the UE is identified by non-access
stratum identities such as IMSI, TMSI and P-TMSI.
Cell_DCH: The CELL_DCH state is characterized by

¾ A dedicated physical channel is allocated to the UE in UL and DL.
¾ The UE is known on cell level.
¾ On the downlink (DL), DCH or HS-DSCH (High Speed – Downlink

Shared Channel) can be used by the UE.
Cell_FACH state is characterized by:

¾ No dedicated physical channel is allocated to the UE.
¾ The UE continuously monitors a FACH in the downlink.
¾ The UE is assigned a default common or shared transport channel in the
uplink (e.g. RACH) that it can use anytime according to the access
procedure for that transport channel.
¾ The position of the UE is known by UTRAN on cell level according to the

cell where the UE last made a cell update.
To activate Cell_FACH, the parameter cellFachEnable is to be set to TRUE.
A RAB Establishment triggers the transition from Cell_FACH to Cell_DCH.

Parameter cellFachEnable |
Object Femto | BSR
{True, False}
Class Class 3
Value TRUE
UTRA RRC Connected Mode
CELL_DCH CELL_FACH
Release RRC Establish RRC Release RRC Establish RRC

Connection Connection Connection Connection
Idle Mode
Figure 1 - BSR supported RRC States
3.1.2 RRC STATE TRANSITIONS
3.1.2.1 CELL_FACH
A new parameter structure BSR::fachRrcEstablishmentCause[i] is introduced to

provide with the information related to:
¾ BSR::fachRrcEstablishmentCause[i]::rrcEstablishmentcause,
¾ BSR::fachRrcEstablishmentCause[i]:rrcPreferredState
¾ BSR::fachRrcEstablishmentCause[i]:likelyRabOnRrcCause.
If cellFachEnable=TRUE, and an RRC connection establishment within the BSR

is required, the BSR matches the establishment cause in the RRC connection
request to the OAM table fachRrcEstablishmentCause[i]::EstablishmentCause.

Table 1 provides with recommended values for Small Cells deployment and Table
2 for other types of deployments.
The Establishment Cause in the RRC connection request message gives indication
of the type of call being performed. [3GPP_R05] Annex L provides a mapping
between some of the NAS procedures and establishment cause, and the
Cell_FACH will use this mapping to guide which RRC state to steer the UE towards
during RRC establishment. A CAC is performed at Cell_FACH level as described
in 3.5.5).
# rrcEstablishmentCause rrcPreferredState likelyRabOnRrcCause

1 originatingConversationalCall dCH true
2 originatingStreamingCall dCH true
3 originatingInteractiveCall dCH true
4 originatingBackgroundCall dCH true
5 originatingSubscribedTrafficCall dCH true
6 terminatingConversationalCall dCH true
7 terminatingStreamingCall dCH true
8 terminatingInteractiveCall dCH true
9 terminatingBackgroundCall dCH true
10 emergencyCall dCH true
11 interRAT-CellReselection fACH false
12 interRAT-CellChangeOrder dCH true
13 registration fACH false
14 detach fACH false
15 originatingHighPrioritySignalling dCH true
16 originatingLowPrioritySignalling fACH false
17 callRe-establishment fACH false
18 terminatingHighPrioritySignalling dCH true
19 terminatingLowPrioritySignalling fACH false
20 terminatingCauseUnknown dCH true
21 other dCH true
Table 1 - Typical Open Access BSR in public areas deployments -
BSR::fachRrcEstablishmentCause[i]

# rrcEstablishmentCause rrcPreferredState likelyRabOnRrcCause

1 originatingConversationalCall dCH true
2 originatingStreamingCall dCH true
3 originatingInteractiveCall dCH true
4 originatingBackgroundCall dCH true
5 originatingSubscribedTrafficCall dCH true
6 terminatingConversationalCall dCH true
7 terminatingStreamingCall dCH true
8 terminatingInteractiveCall dCH true
9 terminatingBackgroundCall dCH true
10 emergencyCall dCH true
11 interRAT-CellReselection dCH false
12 interRAT-CellChangeOrder dCH true
13 registration dCH false
14 detach dCH false
15 originatingHighPrioritySignalling dCH true
16 originatingLowPrioritySignalling dCH false
17 callRe-establishment dCH false
18 terminatingHighPrioritySignalling dCH true
19 terminatingLowPrioritySignalling dCH false
20 terminatingCauseUnknown dCH true
21 other dCH true
Table 2 - Other deployments - BSR::fachRrcEstablishmentCause[i].
Parameter rrcPreferredState
Object FachRrcEstablishmentCause
Granularity FachRrcEstablishmentCause
{dCH=0,
fACH=1}
Class Class 3
Value See Table
Parameter likelyRabOnRrcCause
{True, False}
Class Class 3
Value See table

Parameter rabEstablishFachEnable |
Object Femto | BSR
{True, False}
Class Class 3
Value FALSE
Parameter rrcEstablishmentCause
{originatingConversationalCall =0,
originatingStreamingCall =1,
originatingInteractiveCall =2,
originatingBackgroundCall =3,
originatingSubscribedTrafficCall =4,
terminatingConversationalCall =5,
terminatingStreamingCall =6,
terminatingInteractiveCall =7,
terminatingBackgroundCall =8,
emergencyCall =9,
interRATCellReselection =10,
interRATCellChangeOrder =11,
registration =12,
detach =13,
originatingHighPrioritySignalling =14,
originatingLowPrioritySignalling =15,
callReestablishment =16,
terminatingHighPrioritySignalling =17,
terminatingLowPrioritySignalling =18,
terminatingCauseUnknown =19,
other =255}
Class Class 3
Value See Table
If the parameter rabEstablishFachEnable =FALSE, the BSR will respond to a

RAB Assignment whilst the UE is in Cell_FACH state with an Iu Release towards
the CN issuing the RAB Assignment request.
Engineering Recommendation: rabEstablishFachEnable
It is strongly recommended to keep the parameter rabEstablishFachEnable =TRUE to ensure all

the RRC state transitions are activated when Cell_FACH is used.

If the parameter rabEstablishFachEnable =TRUE, upon reception of a RAB
Assignment whilst the UE is in Cell_FACH state, the BSR attempts to establish the
RAB and transition the UE to Cell_DCH state.
Figure and Figure 3 present the call flow for the RAB establishment for CS and PS
from Cell_FACH.
UE Femto Femto MSC SGSN

L1 RRC UE is in
Cell_FACH
Security & NAS procedures
RAB
Assignment Perform DPAT to
RL Setup
BVG IuUP Init
Prepare Phy Layer
RL Setup Response with CS+DCCH.
Radio Bearer Setup (Cell_DCH, Phy)

RAB
Radio Bearer Setup Complete (Ciphering Start) Assignment
Response Reconfigure
TimerPoll of UE
Radio Bearer Reconfiguration (DCCH RLC)
Radio Bearer Reconfiguration Complete
Figure 2 - CS RAB Establishment in Cell_FACH state
UE Femto Femto MSC SGSN

L1 RRC UE is in
Cell_FACH
Security & NAS procedures
RAB Assignment
RL Setup Perform DPAT to
BPG.
Prepare Phy Layer
RL Setup Response with PS+DCCH.
Radio Bearer Setup (Cell_DCH, Phy)

Radio Bearer Setup Complete (Ciphering Start) RAB Assignment
Response Reconfigure
TimerPoll of UE
Figure 3 - PS RAB Establishment in Cell_FACH state
3.1.2.2 CELL_DCH
The CELL_DCH state is entered from the Idle Mode through the setup of an RRC
connection. The Idle Mode is entered from Cell_DCH through the release of an
RRC Connection. The release of the RRC Connection may be due to Iu Release
Command from MSC or from SGSN or due to user traffic inactivity on the PS RAB.

The timer defining the maximum length of the inactivity of a user before moving it
from Cell_DCH to idle is given through the parameter rABInactivityTimer. The
inactivity timer is used to monitor data activity in the UL and DL direction for all
data services to a UE on DCH, HS-DSCH and the signalling DCCH.
Parameter rABInactivityTimer
Object BSR Profile
Range & Unit Integer [s]
[0..65535]
Class Class 3
Value 120
The BSR does not transition the UE RRC state from CELL_DCH to Idle Mode, in
case an IuCS’ signaling connection exists for the UE. It performs instead a PS
signaling connection release via the RANAP Iu Release Request procedure to the
SGSN and subsequent RRC Signaling Connection Release procedure (if no PS
RAB) or Radio Bearer Release (if PS RAB exists) upon receiving the RANAP Iu
Release Command from the SGSN.
After expiry of timer rABInactivityTimer, the BSR initiates the RRC Connection
Release procedure via the RANAP Iu Release Request procedure with Iu Release
cause = ‘User Inactivity’ in case no CS RAB is assigned for the UE and start the
rABInactivityTimer. In the case of CS signalling connection assigned to the UE, the
BSR releases only the PS signalling connection and PS RAB (if any). The PDP
context will be preserved in the SGSN/UE and can be re-connected later.
In the case the Multiple PDP Contexts features are activated, the parameter
rABInactivityTimerMpdp is to be considered, providing an independent inactivity
timer in the case of MPDP.
The Femto will restart the inactivity timer following a RAB establishment and a RAB
release (i.e. 1 to 2 and 2 to 1 RABs).
Parameter rABInactivityMpdp
Object BSR Profile
[0..65535]
Class Class 3
Value 120

Engineering Recommendation: tuning of rABInactivityTimer and rABInactivityTimerMpdp
Depending of the deployment scenario, the value of these two timers may need to be adapted.
Indeed, in a residential deployment, a long value may be chosen in order to keep the PDP contexts
up. This will keep the internet access time shorter in case of web browsing for instance and give
the end-user the impression of faster internet. Typical values for such scenarios are around 120s.
In hotspot scenarios, with lots of users moving around, these timers require to be set shorter. This
is mainly to free resources. Such settings would also improve the PS drop call rate until PS
Handovers are fully supported. Typical values for such scenarios are around 10s.
Restriction: Smart Phones and inactivity timers
Smart phones (Blackberry, iPhone, Nokia) send a signalling connection release indication when
their data session is finished. This results in the release of the connection before the inactivity timer
expires.

3.2. SIGNALING OVER 13.6KBPS DCCH

The BSR supports a 13.6kbps stand alone DCCH for RRC establishment in
Cell_DCH. This is allowed through the use of 10ms TTI.
This feature is expected to bring improvements in terms of call setup delys and
speed up the LAU/RAU.
This is particularly important when BSR are expected to carry a lot of traffic.
The Feature is activated setting the parameter dCCH136enable to TRUE.
At RAB Establishment on top of stand alone DCCH in Cell_DCH, the BSR
reconfigures the DCCH from 13.6kbps DCCH (10ms TTI) to 3.4kbps DCCH (40ms
TTI) as depicted in Figure 4.
At RAB Release to stand alone DCCH, the BSR keeps the DCCH on 3.4kbps
DCCH.
Figure 4 - RAB Establishment on 13.6kbps DCCH

Parameter dCCH136enable |
Object Femto | BSR
{True, False}
Class Class 3
Value TRUE
3.3. SIGNALLING OVER CELL_FACH
3.3.1 DESCRIPTION
Cell_FACH is an RRC state which uses a low bandwidth DL common channel
(FACH) for transfer of traffic in the DL and UL Random Access Channel (RACH)
for traffic in the UL.
The RACH and FACH were previously used for CCCH common channel signalling
i.e. UL RRC Connection Request, Cell Update, URA Update (Unlikely), and in DL
RRC Connection Setup and RRC Connection Release.
The FACH is a transport channel supported on a physical channel called the

SCCPCH.
In the context of BSR, the LAC and RAC will be different from the overlay Macro
network. As a result, UEs entering the BSR coverage may generate high volumes
of LAU/RAU.
As the FACH is broadcasted on a shared channel, it means that the DCH
resources of the BSR are not consumed when performing data transfer (although
CPU resources to manage the call will be consumed). This can be particularly
useful for such procedures where only NAS and RRC signaling is performed
between the UE and RAN/CN. Figure 6 gives the call flow in the case of LAU/RAU
in Cell_FACH state.
These LAU/RAU will be targeted towards Cell_FACH state guided by means of the
RRC establishment cause. Figure 5 provides with the call flow at RRC
Establishment.

Figure 5 - RRC Connection Establishment in Cell_FACH state
Figure 6 - LAU/RAU in Cell_FACH state
3.3.2 EXCEPTION
Under certain circumstances, it might be needed to allow the RRC establishment in
Cell_FACH mode rather than Cell_DCH, irrespectively of the rules defined in 3.1.2.
This is particulary the case when the maximum number of users in cell_DCH is
reached. RRC establishment causes such as registration can be handled in
Cell_FACH state when there is no longer any user capacity available to deal with.
The BSR will therefore attempt to establish the RRC connection in Cell_FACH, if
¾ BSR::cellFachEnable=TRUE and
¾ The preferred RRC state is DCH and
¾ It has been determined that a RAB is not likely to be established and
¾ The maximum number of users in Cell_DCH state is met and

¾ The BSR::number of users in Cell_FACH state is less than
BSR::maxCellFachUsers
otherwise the BSR will attempt to establish the RRC Connection in Cell_DCH
state.
3.3.3 CELL UPDATE SCENARIOS

The BSR supports the reception of Cell Update from the UE whilst in Cell_FACH
state (served by the BSR) with the following behaviour:
1) If the Cell Update cause is cell reselection, periodical cell update or re-entered
service area, the BSR sends a Cell Update confirm on the CCCH providing the
existing C-RNTI. The BSR then handles the UTRAN Mobility Information
Confirm from the UE.
2) For all other causes the BSR triggers the Iu Release procedure and send an
RRC Connection Release on the CCCH.
3.3.4 FACH TO DCH FAILURE
3.3.4.1 PROCEDURE GUARD TIMER
Upon transmission of a RRC Radio Bearer (RB) Setup in Cell_FACH, the BSR
starts the timer fachDchGuardTimer as depicted on Figure 7.
Upon expiry of this timer, the BSR triggers an Iu Release Request, with cause
“Radio Connection With UE Lost” to all involved CN domains.
Upon reception of a RB Setup Complete or termination of the Iu,

fachDchGuardTimer is stopped.
Following a retransmission of the RRC RB Setup message (triggered by other

requirements) the fachDchGuardTimer is restarted.

UE Femto Femto CN
L1 RRC UE is in
RAB Cell_FACH
Assignment
RL Setup
Procedure guard
timer is started
RL Setup Response
Radio Bearer Setup (FACH->DCH)
Procedure guard
timer expires
Iu Release
Request
Figure 7 - Procedure Guard Timer
Parameter fachDchGuardTimer
Object BSR Profile
Range & Unit Integer [ms]
[0..20000]
Class Class 3
Value 16000
3.3.4.2 PHYSICAL CHANNEL FAILURE
Upon reception of an RRC RB Setup Failure from the UE, with the causes physical
channel failure, cell update occurred or incompatible simultaneous reconfiguration,
and if the BSR has not reached fachDchMaxRetries retransmissions of the Radio
Bearer Setup, then the BSR:
1) Retransmits the RB Setup message (using a new RRC Sequence Number)
2) Restarts timer fachDchGuardTimer (3.3.4.1)
For all other causes or when the maximum number of retransmissions is met, the
BSR sends an Iu Release Request to the CN with cause “Failure In The Radio
Interface Procedure”.

UE Femto Femto CN
L1 RRC UE is in
RAB Cell_FACH
Assignment
RL Setup
UE Fails to achieve
RL Setup Response phy channel synch
and sends back a
Radio Bearer Setup (FACH->DCH) RB setup failure on
the RACH
Radio Bearer Setup Failure (RACH, Phy Chan Failure)
A retry is sent using
Radio Bearer Setup (FACH->DCH) the same phy
channel
Radio Bearer Setup Complete (DCH) RAB
Assignment The retry is
Response successful
Figure 8 - Physical Channel Failure
Parameter fachDchMaxRetries
Object BSR Profile
[1..5]
Class Class 3
Value 1
Note: Setting the parameter fachDchMaxRetries to zero means there will be no

retransmissions.
3.3.4.3 UE BUG WORK AROUND
Upon transmission of an RRC RB Setup towards the UE, the BSR RRC requests
notification from L2 of the successful delivery of the RRC message.
Upon reception of successful delivery of the RRC RB Setup, the BSR starts the
timer fachDchRetxTimer.
Upon expiry of timer fachDchRetxTimer, and if the BSR has not reached
fachDchMaxRetries retransmissions of the Radio Bearer Setup, then the BSR:
1) Retransmits the RB Setup message (using a new RRC Sequence Number)
2) Restarts timer fachDchGuardTimer (3.3.4.1)
Otherwise the BSR shall send an Iu Release Request to the CN with cause “Radio
Connection With UE Lost”.

UE Femto Femto CN
L1 RRC UE is in
RAB Cell_FACH
Assignment
RL Setup
UE Receives RB
reconfig, but
RL Setup Response discards at L3
(known UE bug)
L3 : Radio Bearer Setup (FACH->DCH)
Retransmission
L2 : RLC Status Report (ACK RB Setup) timer is started on
reception of
L3 : Radio Bearer Setup (FACH->DCH) confirmation of
delivery from L2
L3 : Radio Bearer Setup Complete RAB After failure, a retry
Assignment is sent using the
Radio Bearer Reconfiguration (DCCH RLC) Response same phy channel
Radio Bearer Reconfiguration Complete The retry is

successful
Figure 9 - UE Bug Work Around
Parameter fachDchRetxTimer
Object BSR Profile
[0..10000]
Class Class 3
Value 5000
3.3.5 SIB BROADCAST FOR CELL_FACH STATE

In the case cellFachEnable=TRUE, the SIB 11 will be configured with following
parameters:
¾ IE FACH Measurement occasion cycle length coefficient is set to
BSR::fachMeasDrx
¾ IE Inter-frequency FDD measurement indicator shall be set to
BSR::fachMeasInterFreq.
¾ IE Inter-RAT measurement indicators will be included and set to RAT type

set to GSM if BSR::fachMeasInterRAT is true.

Parameter fachMeasDrx
Object BSR Profile
{disable=0,
coefficient3=3,
coefficient4=4,
coefficient5=5,
coefficient6=6}
Class Class 3
Value coefficient3
Parameter fachMeasInterFreq
Object BSR Profile
{True, False}
Class Class 3
Value TRUE
Parameter fachMeasInterRAT
Object BSR Profile
{True, False}
Class Class 3
Value TRUE
3.3.6 RRC CONNECTION RELEASE

During RRC connection release in Cell_FACH state where it is not required to
release on the CCCH, the BSR will send a RRC Connection release on the DCCH
SRB#1 and starts, as depicted in Figure 10, the timer
BSR::rrcReleaseCompleteResponseTimerFach.
Upon expiry of the timer, the BSR retransmits the RRC Connection Release
towards the UE and restart the timer for up to BSR::rrcReleaseRetriesFach
retransmissions.
If the maximum number of retransmissions has been exceeded, upon expiry of
timer BSR::rrcReleaseCompleteResponseTimerFach, the BSR will release the
UE context.

Parameter rrcReleaseCompleteResponseTimerFach
Object BSR Profile
[0..10000]
Class Class 3
Value 1000
Parameter rrcReleaseRetriesFach
Object BSR Profile
[1..10]
Class Class 3
Value 3
Figure 10 - RRC Connection Release Retransmission
The RRC release complete message is transmitted on AM RLC (Radio Link

Control). In the case the RLC status report does not get to the UE as depicted in
Figure 11, the UE will keep retransmitting the complete message at RLC until RLC
unrecoverable error occurs and the UE goes into idle. Such behaviour results in a
waste of RACH resources and delay in the UE being able to perform new
procedures.
Therefore, the BSR will keep up the user plane for a period, configurable through
the parameter BSR::rrcReleaseFachHoldTimer, following RRC release complete
in FACH.

Parameter rrcReleaseFachHoldTimer
Object BSR Profile
[0..10000]
Class Class 3
Value 1000
Figure 11 – RRC Connection Release and UE retransmission
3.3.7 SUPERVISION TIMER - MAXIMUM DURATION IN

CELL_FACH STATE
As DCCH signaling in Cell_FACH state should be a short lived process, a
supervision timer has been implemented for the following purposes :
¾ Handle the case where a UE has lost coverage from the BSR and the BSR
has not detected it.
¾ Handle the case where the CN has not released the Iu connection.
If BSR::cellFachMaxDuration is non zero, the BSR run a supervision timer

starting when the UE sends the RRC Connection Setup Complete in Cell_FACH
state.
Upon expiry of the timer, the BSR triggers the Iu Release Procedure with cause
"Radio Connection With UE Lost" to each involved CN domain.
In the case that two CN domains are involved, the BSR holds off on the signaling
connection release message and wait for the second Iu release command and
then send an RRC connection release.
In the case that there is no Iu established (e.g.UE loses coverage before the initial
direct transfer) the BSR just sends a RRC Connection release towards the UE.

In all cases, the RRC Release Cause will be "unspecified".
Note: It is assumed that loss of radio contact with the UE will generally be the case
for this scenario, but RRC release will be sent in any case.
Parameter cellFachMaxDuration
Object BSR Profile
[0..65535]
Class Class 3
Value 60

3.4. PAGING
3.4.1 STANDARD PAGING

The main purpose of paging is for the Core Network to request the BSR to contact
a UE when a UE-terminating transaction is to be carried out.
The paging procedure is initiated in the BSR on the receipt of RANAP PAGING
message from the CN through the BSG. The accuracy of an UE is known with the
precision of a RA in the SGSN and a LA in the MSC. The BSG distributes the
paging message within the BSR cluster to the paging list, built according to the
following algorithm:
1. If the Paging Area Id is included in the RANAP PAGING message: if LAC

matches a SuperLac, all the associated LAC or LAC/RAC are added to
the Paging Area List. Otherwise, if no SuperLac matches, the LAC or
LAC/RAC is directly added to the Paging Area List.
If the Paging Area Id is not included in the RANAP PAGING message,
all BSR registered LAC or LAC/RAC are added to the Paging Area List.
2. Depending on the type of deployment, the FGW narrows down the BSR
selection inside the Paging Area List:
For open access BSRs and UEs not in the ACL of prioritized open
access BSRs: the BSRs of the candidate paging list with a matching
IMSI entry in their IMSI Directory are added to the paging list.
For closed access BSRs and UEs in the ACL of prioritized open access
BSRs: the BSRs of the candidate paging list with a matching IMSI entry
in their ACL list are added to the paging list.
3. If a BSR in the paging list is part of a group, the whole group is added to
the paging list.
If after this the paging list remains empty, the paging message is not forwarded.
On receipt of RANAP PAGING message from the CN through the BSG, the BSR
performs paging procedure in order to locate the UE. First step is to identify paging
type. The CN Domain Indicator and the UE IMSI are used by the BSR to check if a
signalling connection towards the other CN domain already exists for the targeted
UE.
3.4.1.1 PAGING TYPE 1
If there is no information about the UE in the BSR (IMSI not known) or the UE is in
idle mode, the BSR sends a RRC PAGING TYPE 1 message in the Paging
Channel with mobile identifier received in the PAGING message from the CN. The
message is broadcasted. The UE on receipt of PAGING message responds back

with RRC Initial Direct Transfer Message with establishment cause as “paging
response”. The call flow is presented in.
Figure 12 – Paging UE unkown

Note: The BSR might receive Paging messages for UEs that are not in its
coverage area. In this case, a PAGING TYPE 1 message will be broadcasted but
no answer will come from the UE. This can affect Paging KPIs.
3.4.1.2 PAGING TYPE 2
If the UE is in CELL_DCH state in the BSR, The BSR sends a RRC PAGING
TYPE 2 message on the DCCH to the UE. The message is sent directly to the
targeted UE. The UE on receipt of PAGING message responds back with RRC
Initial Direct Transfer Message with establishment cause as “paging response”.
The call flow is presented in.
Figure 13– Paging with Paging Co-ordination – UE in RRC CELL_DCH state

3.4.2 INCREASED PAGING CAPACITY FOR PUBLIC FEMTO
CELLS
Metro Cells can be deployed to provide additional coverage or capacity to the
macro network. Those Metro Cells can be deployed indoors or outdoors, and any
user is allowed to camp on to it. In order to avoid swamping the CN, Macro RNC
(Radio Network Controller) and Metro Cell with Location/Routing Updates, it is
required that the Public Metro Cells have the ability to use the same Location Area
Code (LAC) and Routing Area Code (RAC) as the overlapping macro cell.
The implications of using the same LA/RA as Macro is that the BSG and BSR will
have to manage a full RNC LA worth of paging. This will be much higher volumes
than ever previously envisaged.
This, in turn, raises the need to perform paging optimization, as when a UE is
paged, paging message will be sent to all BSRs in that LAC (as well as macro
cells).
Generally, the BSR Femto CPU usage is dominated by the number of packet
exchanges. Therefore, one big optimisation which can be made in the BSR is for
the BSG to perform the batching of paging messages from the CN.
The same is expected to be true in the BSG i.e. batching up of paging messages
helps reduce the number of message transmissions to the BSRs which helps
improve the CPU load.
The BSR and BSG support a proprietary paging protocol (BSGPP) that batches
multiple RANAP Paging messages from IuCS and IuPS into one message.
The BSG limits the number of paging messages per batch. This will be hard coded
to around 256 to bound the limit of processing of one message that the BSR
supports in the user plane.
When the BSR is configured to support the same LA/RA as Macro, it supports the
reception and handling of the BSGPP paging protocol.
The BSR is able to also support the normal paging mechanism as well as BSGPP.
The BSR registers to the BSG the fact that it is using the same LA/RA as the
macro network.
The configuration can be manually provisioned or automatically detected through

network listening.
The BSR is configured with enableSameLaRaMacro set to:

• disable - disables feature;
• gsm - autoconfigure from 2G;
• fdd - autoconfigure from 3G;
• gsmPreferred - autoconfigure from 2G if available, 3G otherwise;
• fddPreferred - autoconfigure from 3G if available, 2G otherwise;

• manual - use the manually configured RAC/LAC as same LA/RA as macro.
Parameter enableSameLaRaMacro
Object BSR Profile
{disable=0, gsm=1, fdd=2, gsmPreferred=3,
fddPreferred=4, manual=5}
Class Class 3
Value disable
When the BSR automatically configures to have the same LA/RA as the Macro, the
BSR can only configure to the Macro LAC/RAC when the Macro LAC/RAC
matches a list in OAM.
If a match cannot be made, the BSR raises an Alarm and either goes off air or
takes the provisioned BSR cluster LAC/RAC depending upon the parameter
macroLacRacConfig which can be set to:
• autoConfigFallBack - if auto-configuration is not possible, fallback to
manually configured LAC/RAC.
• autoConfigOnly - if auto-configuration is not possible, do not go into
service.
Parameter macroLacRacConfig
Object BSR Profile
{autoConfigFallBack=0, autoConfigOnly=1}
Class Class 3
Value autoConfigFallBack
The parameter sameSaiMacro is used when same LA/RA as macro is enabled. It

can be set to:
• none, the SAI LAC/SAC (Location/Service Area Code) are both taken from
the BSR MIM .
• lac, the SAI SAC is taken from the BSR MIM , and SAI LAC is the same as
the macro.
• lacSac, the SAI SAC is taken from the Cell ID of the macro cell and the SAI
LAC is the same as the macro.

Parameter sameSaiMacro
Object BSR Profile
{none=0, lac=1, lacSac=2}
Class Class 3
Value lac
The BSR is able to log in OAM the location updates received and the LAC which
the UE has moved from. This is logged over a period of a day and a week.
The BSG determines from OAM parameter macroLacRacList a list of Macro

LAC/RAC which are common to the Macro cell and may be used by the BSR.
When a BSR registers a LAC and RAC corresponding to that provisioned in OAM
parameter macroLacRacList, the BSG passes all paging messages matching the
LAC (CS) or LAC&RAC (PS) to the BSR.
The paging messages are formatted using the BSGPP, bypassing the BSG UE
Directory.
Parameter - | macroLacRacList
Object | BSG
Granularity | BSG
Range & Unit sequence [0..100] of struct MacroLacRac
Class 3
Value -
When a BSR advertises that it is using the same LA/RA as macro and the BSR
registers a LAC or RAC combination which is not provisioned in OAM parameter
macroLacRacList, the BSG raises an alarm and takes the BSR out of service.
The BSG supports a mixture of BSRs on the same and different LA to the macro
using different paging mechanisms.
The BSG needs to optimise the software architecture to support the necessary
performance requirements.
The BSG efficiently deals with the possibility that a CN is provisioned to deliver a
Macro LAC/RAC to the BSG before the BSG is provisioned.
In this case, paging messages can simply be discarded, and the BSG does not
flood alarms/warnings when this occurs.
The BSG supports overload control for RANAP paging and when the aggregate
paging load (RANAP pages per second) exceeds a threshold, the BSG is able to
drop paging messages.
The BSG supports two threshold levels. The first is to provide a warning and the
second is to send an alarm and to start dropping paging messages.

The BSG supports 32 IuPS and 32 IuCS links.
This support is useful for both Same LA/RA as Macro, as well as for normal IuFlex
scenarios as some recent operators have requested support of 18 and 32 Iu links
to each CN domain.
In the case where IuFlex is not supported, the operator has to support a "Custom"
IuFlex implementation where the routing of the initial UE message is performed
based upon the BSR/Macro LAC.
When a new Macro LAC/RAC is added for Same LA/RA as Macro, the appropriate
MSC/SGSN Iu link has to be re-provisioned to add the LAC/RAC.
In the case where IuFlex is supported, the operator has to provision the whole Iu
pool in the SGSN/MSC for the Iu Link to the BSG with the appropriate LAC/RAC
used for Same LA/RA as Macro.
bsgppBatchInt defines the minimum Batch Interval in milliseconds where

individual RANAP Paging messages for a Macro LAC RAC from the CN are
batched into a Batch Paging message towards the BSRs associated with the
Macro LAC RAC.
Parameter - | bsgppBatchInt
Object | BSG
Granularity | BSG
[100..1000] step 100
Class 3
Value 100
bsgppMaxBatchInt defines the maximum Batch Rate Interval allowed. This is

determined by the network provider provisioning a maximum Batch Rate interval to
be less than the Femto DRX cycles.
Parameter - | bsgppMaxBatchInt
Object | BSG
Granularity | BSG
[100..1000] step 100
Class 3
Value 500
minBatchPagingCPUUtilization defines the minimum CPU utilization for Batch

Paging.

Parameter - | minBatchPagingCPUUtilization
Object | BSG
Granularity | BSG
[50..90] step 5
Class 3
Value 60
maxBatchPagingCPUUtilization defines the maximum CPU utilization for Batch

Paging.
Parameter - | maxBatchPagingCPUUtilization
Object | BSG
Granularity | BSG
[50..90] step 5
Class 3
Value 70
batchPagingOverloadLow defines the number of BSGPP Batch Paging

messages per second supported by the BSG before a warning is raised.
Parameter - | batchPagingOverloadLow
Object | BSG
Granularity | BSG
[1000..100000]
Class 3
Value 8000
batchPagingOverloadHigh defines the number of BSGPP Batch Paging

messages per second supported by the BSG before Batch Paging messages are
dropped.
Parameter - | batchPagingOverloadHigh
Object | BSG
Granularity | BSG
[1000..100000]
Class 3
Value 10000

pagingOverloadLow defines the number of RANAP pages per second supported
by the BSG before a warning is raised.
Parameter - | pagingOverloadLow
Object | BSG
Granularity | BSG
[1000..100000]
Class 3
Value 8000
pagingOverloadHigh defines the number of RANAP pages per second supported

by the BSG before paging messages are dropped.
Parameter - | pagingOverloadHigh
Object | BSG
Granularity | BSG
[1000..100000]
Class 3
Value 10000
The OAM provisioning system ensures that BSRs provisioned with same LA/RA as
Macro satisfy the following constraints:
1. The BSR LAC/RAC is provisioned consistently with the BSG.

2. When the BSG has no LAC/RAC for same LA/RA as macro provisioned
(macroLacRacList is empty), the BSR does not enable this feature.
measureLAU activates measurements of the old LAI in LAU procedures.
Parameter measureLAU
Object BSR Profile
{True, False}
Class Class 3
Value false
Being on the same LA/RA as macro does not rule out all signalling impacts due to
mobility in connected mode Cell_FACH/Cell_PCH or URA_PCH state on the
Macro and reselecting into the BSR.
Normally this would need to be tidied up by the BSR releasing the RRC connection
with a special release cause (Directed Signalling Connection Re-establishment).
This results in the UE performing a RAU procedure with the SGSN and the SGSN

will then release the Iu from the RNC which means that the UE, RNC and SGSN
are in synch.
The problem with this is that it will still result in SGSN signalling due to the RAU
procedure.
Figure 14 – DSCR case
Another approach to this problem is to release the UE with a normal cause value
and not have the RAU procedure triggered. The drawback of this approach is that
DL data may be lost towards the UE and the macro key performance indicators
(KPIs) may look poor due to the loss of the UE (drop) when the response to the
UTRAN paging procedure fails to be received (PCH), or RLC disrupts
(Cell_FACH).
Figure 15 – Non DSCR case and loss of data

roamerReleaseCause defines the RRC release cause to be used when a UE
sends a Cell/URA Update from a neighbouring RNC.
Parameter roamerReleaseCause
Object BSR Profile
{dscr=0, normal=1}
Class Class 3
Value dscr

3.5. CALL ADMISSION CONTROL

The Call Admission Control (CAC) algorithm is used to admit or deny new RRC
Connection Request based on several criteria as presented in section 3.5.4.
3.5.1 EMERGENCY CALL REDIRECTION

Prior to the CAC processing described in section 3.5.4, a specific treatment is
performed for Emergency calls, i.e. when RRC Connection Request cause is set to
Emergency. In such a case, emergencyCallAlwaysRedirectFlag is checked;
when set to True, BSR directly performs an Emergency call redirection to Macro
3G or 2G, depending on emergencyCallRedirectNetwork value.
Parameter emergencyCallAlwaysRedirectFlag
Object LCell
{True, False}
Class Class 3
Value FALSE
Parameter emergencyCallRedirectNetwork
Object LCell
Range & Unit Enum
{redirectGsmPreferred, redirectUmtsPreferred}
Class Class 3
Value redirectGsmPreferred
If Emergency call redirection is disabled or no Macro neighbouring cell is available

nor eligible, CAC check is performed, as presented hereafter.
Rule: emergencyCallRedirectNetwork = redirectGSM
In the case the emergencyCallRedirectNetwork = redirectGSM but no GSM cell was identified
during the auto-configuration or self-optimization, the “Redirection Info” IE will be filled with the
frequency of a detected 3G Macro or will not be set in the case neither 2G, nor 3G neighbours are
detected.

Rule: emergencyCallRedirectNetwork = redirectUMTS
In the case the emergencyCallRedirectNetwork = redirectUMTS but no UMTS cell was identified
during the auto-configuration or self-optimization, the “Redirection Info” IE will be filled with the
frequency of a detected 2G Macro or will not be set in the case neither 3G, nor 2G neighbours are
detected.
3.5.2 BACKHAUL RESOURCE MANAGEMENT

The BSR support an additional Call Admission Control procedure compared to the
standard UTRAN ones. It gives the BSR the ability to cope with lack of transport
network resources. This functionality is called Backhaul Resource Management
(BRM).
This feature is activated by setting the parameter
BSR::enableTransportCAC=TRUE.
Rule: BSR::enableTransportCAC and BSR::enableAbwMeasurements

If transport CAC is enabled but BSR::enableAbwMeasurements=FALSE there will be no
transport CAC check performed at RRC connection.
Parameter enableTransportCAC
Object BSR Profile
{True, False}
Class Class 3
Value FALSE
3.5.2.1 RESERVED BANDWIDTH
In the case some backhaul bandwidth must be reserved for applications external to
the BSR, it has to be done using the parameter BSR::reservedRBGWULBW.
The available resource for the BSR will then be the difference between the
backhaul resources and the reserved ones.
Parameter reservedRBGWULBW
Object BSR Profile
Range & Unit Integer [kbps]
[0..65535]
Class Class 3
Value 0

Engineering Recommendation: Reserved Bandwidth
As long as there is no explicit need to reserve backhaul resources, BSR::reservedRBGWULBW

should be kept on 0.
3.5.2.2 BANDWIDTH MEASUREMENTS
For transport CAC the BSR needs to be aware about the available uplink
bandwidth. The type of backhaul connection can vary from one BSR to the other.
One may have a basic DSL connection, while others have DSL 2+ or Fiber. A
manual configuration of the uplink and downlink bandwidth is therefore not
adequate and measurements must be performed in order to evaluate the values.
ABW must be activated clusterwise at the FGW by setting the parameter
enableRTMonitoring=TRUE.
On a BSR per BSR basis, ABW measurement is enabled setting
enableAbwMeasurements=TRUE and enableULBWMeasurements = TRUE.
The BSR will then activate Available Bandwidth measurements during active calls.
The first call will always be accepted.
The measurement is using a Probe Gap Method (PGM). This method relies on the
transmission of 10 defined patterns (probe pairs) between BSR and BSG and is
presented in [S. 2].
The duration of each measurement depends on the measured maximum uplink
bandwidth ULBW as the probe size and the inter-probe gap are tuned for ULBW
Engineering Recommendation: abwShortMeasurementTime
The measurement time increases the call setup time and is therefore relevant for the Call
establishment time.
Rule: Maximum UL Bandwidth
The BSR will NOT perform ABW measurements if the ULBW value measured by the Femto
exceeds 4000kbps. It is assumed that there are no UL bandwidth bottleneck in such cases.
Restriction: DL Bandwidth
The measurement method detects only the uplink rate of the DSL line. The BSR is not able to
detect bandwidth capping by traffic shaping at the DSL Access router or other network router.

Parameter enableAbwMeasurements |
Object Femto | BSR
{True, False}
Class Class 3
Value FALSE
Parameter - | enableRTMonitoring
Object FGW
Granularity FGW
{True, False}
Class 3
Value FALSE
3.5.2.3 TRANSPORT CAC CHECKS AT RRC ESTABLISHMENT
In the case transport CAC is activated (BSR::enableTransportCAC=TRUE) and

ABW measurement is enabled (enableAbwMeasurements=TRUE), on receipt of
a RRC Connection Request the BSR verifies whether there are sufficient backhaul
resources for the call being requested.
The following transport CAC procedure will determine the action taken if there is in-
sufficient bandwidth available for non-emergency calls at RRC connection.
If cacProcedureType=’rrcRedirect’ then the BSR rejects the RRC connection with

redirection and cause “congestion”. Redirection info will be included if the macro
layer has been detected during self-optimisation or auto-configuration.
If cacProcedureType=’acRedirect’ and the BSR has detected 2G or 3G Macro

cells during the auto-configuration/self-optimisation then the BSR performs active
call redirection. If the active call redirection is unsuccessful or disabled, the BSR
BSR rejects the RRC connection with redirection and cause “congestion”.
If cacProcedureType =’acRedirect’ and the BSR has not detected any 2G or 3G

Macro cell then the BSR rejects the RRC connection with redirection and cause
“congestion”.
If cacProcedureType =’none’ then no action is taken.

Parameter cacProcedureType |
Object Femto | BSR
Range & Unit enum
{acredirect=0,
rrcdirect=1,
none=2}
Class Class 3
Value rrcdirect
3.5.2.4 TRANSPORT CAC CHECKS AT RAB ESTABLISHMENT
In the case transport CAC is activated (BSR::enableTransportCAC=TRUE) and

ABW measurement is enabled (enableAbwMeasurements=TRUE), at RAB
establishment, the BSR will go through a Call Admission Control procedure and
validates each requested bandwidth resource against the available bandwidth on
Backhaul.
Oversubscription is allowed for IuCS through the parameter ovsIuCSVoice.
Parameter ovsIuCSVoice
Object BSR Profile
Range & Unit Integer [percent]
[100..1000]
Class Class 3
Value 125
In the case cacProcedureType = ‘rrcRedirect’ or ‘None’ and transport CAC fails at

RAB establishment for non-emergency call, the BSR rejects the call with RABs
failed to setup cause “No resource available”.
In the case cacProcedureType = ‘acRedirect’, and transport CAC fails at RAB

establishment for non-emergency call, but BSR::activeCallRedirectEnable=False
or the call was a PS one, the BSR rejects the call with RABs failed to setup cause
“No resource available”.
Rule: cacProcedureType vs activeCallRedirectEnable
It must be ensured that when choosing to actively redirect calls at transport CAC failure,
activeCallRedirectEnable is set to TRUE (ACR activated).
In the case cacProcedureType = ‘acRedirect’, and transport CAC fails at RAB

establishment for non-emergency call, and BSR::activeCallRedirectEnable=True,
the BSR will perform Active Call Redirect (ACR) of an existing CS Voice non-
emergency call to accept a CS Voice call. In the case of a CS Data attempt, the

BSR will evaluate whether ACR of a voice call would free enough resources. If so,
the BSR will perform ACR of an existing CS non-emergency call to accept the CS
Data one. If not, the BSR rejects the call with RABs failed to setup cause “No
resource available”.
If the Active Call Redirection is failing (e.g. no Macro 3G or 2G available), the BSR
rejects the call with RABs failed to setup cause “No resource available”.
3.5.2.5 TRANSPORT CAC AND EMERGENCY CALL
The transport CAC procedure will determine the action taken if there is in-sufficient
bandwidth available for an emergency call.
If cacProcedureType =’rrcRedirect’ then the BSR rejects RRC connection with

redirection and cause “congestion”. Redirection info will be included if the macro
layer has been detected during self-optimisation or auto-configuration.
If cacProcedureType =’acRedirect’ and the BSR has detected 2G or 3G Macro

cells during auto-configuration/self-optimisation then the BSR performs active call
redirection. If the active call redirection is unsuccessful or disabled, the BSR rejects
the RRC connection with redirection and cause “congestion”.
If:cacProcedureType =’acRedirect’ and the BSR has not detected any 2G or 3G

Macro cell then the BSR rejects the RRC connection with redirection and cause
“congestion”.
If cacProcedureType =’none’ then the BSR admits the call.
3.5.3 LOAD ESTIMATION
3.5.3.1 UL LOAD CALCULATION
The BSR calculates the uplink load “load_UL” from the RSSI value received in the
recent COMMON MEASUREMENT REPORT s follows:
load_UL [%] = 100 – 100 / (10^(noise_rise [dB] /10))
where
noise_rise [dB] = max(reported_RSSI [dBm] – noise_floor [dBm], 0dB)

The noise floor has to be updated every time the dailyLowRSSI value changes
based on following formula
noise_floor = 6/7*noise_floor + (1 – 6/7)*dailyLowRSSI
and dailyLowRSSI = min (reported_RSSI, dailyLowRSSI)
3.5.3.2 DL LOAD CALCULATION
The Downlink Load “load_DL” is calculated from the TSSI value received in the
recent COMMON MEASUREMENT REPORT as below,
load_DL [%] = reported_TSSI(%)
3.5.4 PROCESSING CAC

CAC is based on several checks:
• DL/UL loads are lower than thrCACDL/UL (thrCACEmergencyDL/UL for
Emergency calls);
• DL & UL resource consumptions are ok;
• For non-Emergency call, the number of Cell DCH users is lower than
numCellDCHUE.
Refer to section 0 for more details on CAC thresholds.
If the above checks fail, the following process applies depending on the RRC
Connection Request establishment cause :
¾ CAC rejection for non-Emergency calls
¾ CAC rejection for Emergency calls
3.5.4.1 CAC REJECTION FOR NON-EMERGENCY CALLS
BSR performs Active Call Redirection which allows handing-over an existing CS

Speech call such that resources are freed up to enable the new call. This only
takes place if activeCallRedirectEnabled is set to True and aCRpreference is set
to nonEmergencyCall or both (the type of the RAB to establish).

Parameter activeCallRedirectEnabled
Object BSR Profile
{True, False}
Class Class 3
Value TRUE
Parameter aCRPreference
Object BSR Profile
Range & Unit Enum
{nonEmergencyCall, emergencyCall or Both}
Class Class 3
Value emergencyCall
Engineering Recommendation: Active Call Redirection
It is recommended to enable Active Call Redirection feature for emergencyCall only. This will allow
to pre-empt a normal CS Speech call in order to establish an Emergency CS call.
Engineering Recommendation: Shared Carrier deployments
Active Call Redirection or SB HO on Intra-Frequency will result in high drop call rates. Therefore it
is strongly recommended not to use ACR and SB HO in the case of Shared Carrier deployments.
In the case the BSR is configured in Semi Open Access Mode and
activeCallRedirectAllUsers=FALSE, the Active Call Redirection will only redirect
UEs identified as “Public”.
When in Semi Open Mode and activeCallRedirectAllUsers=TRUE, the BSR will

redirect active calls in following Priority:
1. Public
2. Guest
3. Owners
Parameter activeCallRedirectAllUsers
Object BSR Profile
{True, False}
Class Class 3
Value TRUE

In case Active Call Redirection is disabled or fails, BSR may perform normal call
pre-emption, depending on enableNormalCallPreemption value. When set to
True, BSR pre-empts an existing Cell DCH UE based on the order below:
• Cell DCH UE with only PS RAB Background
• Cell DCH UE with only PS RAB Interactive
Parameter enableNormalCallPreemption
Object BSR Profile
{True, False}
Class Class 3
Value TRUE
In the case the BSR is configured in Semi Open Access Mode and
enableNormalCallPreemptionAllUsers=FALSE, the BSR pre-empts an existing
Cell DCH UE of type “Public” with PS RAB of traffic class Backrground or
Interactive.
When in Semi Open Mode and enableNormalCallPreemptionAllUsers=TRUE,

the BSR will pre-empts an existing Cell DCH UE in following Type Priority:
4. Public with PS RAB of traffic class Backrground or Interactive
5. Guest with PS RAB of traffic class Backrground or Interactive
6. Owners with PS RAB of traffic class Backrground or Interactive
Parameter enableNormalCallPreemptionAllUsers
Object BSR Profile
{True, False}
Class Class 3
Value TRUE
3.5.4.2 CAC REJECTION FOR EMERGENCY CALLS
If CAC fails, the BSR pre-empts an existing Cell DCH UE when

emergencyCallPreemptionEnabled is set to True. This will be done in the
following priority order:
1. Cell DCH UE of type public with only CS Data
2. Cell DCH UE of type public with only CS Voice and not emergency call
3. Cell DCH UE of type public with CS Voice but not emergency call and PS
RAB of traffic class = I/B class

4. Cell DCH UE of type guest with only CS Data
5. Cell DCH UE of type guest with only CS Voice and not emergency call
6. Cell DCH UE of type guest with CS Voice but not emergency call and PS
7. Cell DCH UE of type owner with only CS Data
8. Cell DCH UE of type owner with only CS Voice and not emergency call
9. Cell DCH UE of type owner with CS Voice but not emergency call and PS
Parameter emergencyCallPreemptionEnabled
Object Lcell
{True, False}
Class Class 3
Value TRUE
If emergencyCallPreemptionEnabled is set to False, BSR finally attempts Active

Call Redirection if activeCallRedirectEnabled is set to True and aCRpreference
is set to emergencyCall or both.
3.5.5 CELL_FACH CAC

The only CAC check for Cell_FACH is the following.
The BSR will attempt to establish the RRC connection in Cell_FACH, if

¾ BSR::cellFachEnable=TRUE and
¾ the preferred RRC state is FACH and
¾ the number of users in Cell_FACH state is less than
BSR::maxCellFachUsers
otherwise
the BSR will attempt to establish the RRC connection in Cell_DCH state.

Parameter maxCellFachUsers
Object BSR Profile
[1..20]
Class Class 3
Value 20
Inter-Release Delta: Feature 119860 – 32 User capacity on V2 Enterprise and Metro cell
The feature 121160 updates the range from 10 to 20 of maxCellFachUser. The BSR supports up
to 20 signalling connections over FACH when numCellDCHUE is greater than 16.
3.5.6 REJECTING RRC CONNECTION

In case the previous checks did not allow to accept the new RRC Connection, BSR
sends back RRC Connection Release to UE with cause “Congestion” and specifies
in the same RRC message which network to be redirected to, setting the
“Redirection Info” using:
• emergencyCallRedirectNetwork for Emergency calls,
• redirectNetwork for non-Emergency calls.
Parameter redirectNetwork
Object Lcell
Range & Unit Enum
{disable, redirectGSM or redirectUMTS}
Class Class 3
Value redirectGSM
Rule: redirectNetwork = redirectGSM
In the case the redirectNetwork = redirectGSM but no GSM cell was identified during the auto-
configuration or self-optimization, the “Redirection Info” IE will be filled with the frequency of a
detected 3G Macro or will not be set in the case neither 2G, nor 3G neighbours are detected.
Rule: redirectNetwork = redirectUMTS
In the case the redirectNetwork = redirectUMTS but no UMTS cell was identified during the auto-
configuration or self-optimization, the “Redirection Info” IE will be filled with the frequency of a
detected 2G Macro or will not be set in the case neither 3G, nor 2G neighbours are detected.

3.6. DYNAMIC BEARER CONTROL
The Dynamic Bearer Control (DBC) is in charge of the rate allocation for PS and
CS Conversational services on DCH and/or HS-DSCH transport channels based
on:
• UL and DL load information,
• the baseband processor resource usage.
In the coming sections:

• UL_load refers to measured RSSI level relative to the lowest reference
RSSI.
• DL_load refers to the computed DL power usage relative to the maximum
TX power.
3.6.1 DBC BASED ON UL & DL LOAD MEASUREMENT

DBC algorithm first evaluates the environment status for UL & DL based on the
latest CPICH Ec/N0 measurement reported by UE in RRC Connection Request,
RRC Cell Update or RRC Measurement Report (while in Cell DCH). The
comparison of CPICH Ec/No with ecN0thres thresholds defined for UL and DL
leads to 2 different values for the UL and the DL environment status: “Cell Center”
or “Cell Edge”.
Rule: Environment Status Variables
If CPICH Ec/N0 > DBCQualReportingCriteriaDL::EcI0thr,

then set DL_environment_status = "Cell centre".
If CPICH Ec/N0 <= DBCQualReportingCriteriaDL::EcI0thr,
then set DL_environment_status = "Cell edge".
If CPICH Ec/N0 > DBCQualReportingCriteriaUL::EcI0thr,
then set UL_environment_status = "Cell centre".
If CPICH Ec/N0 <= DBCQualReportingCriteriaUL::EcI0thr,
then set UL_environment_status = "Cell edge"
Inter-Release Delta: Sparepara16
The parameter Sparepara16 is replaced from BCR3.0 by 2 new parameters envStatusF2FhoDl /

envStatusF2FhoUl.

Rule: Environment Status Variables - Special Case – Target BSR during inter-BSR Handover
During BSR to BSR HO, the target BSR initialises the DL_environment_status and UL_environment_status
using the values provided through the parameters envStatusF2FhoDl / envStatusF2FhoUl.
Parameter envStatusF2FhoDl
Object LCell
{cellEdge=0, cellCentre=1}
Class Class 3
Value cellEdge
Parameter envStatusF2FhoUl
Object LCell
{cellEdge=0, cellCentre=1}
Class Class 3
Value cellEdge
Then, DBC admits the incoming request if the following condition is satisfied,
depending on the bearer to be granted.
PS bearer to be granted
PS bearer Condition for the bearer to be granted
UL PS bearer with 8k, 16k or 32k or 64k UL_load < thrCACUL
UL PS bearer with 128k UL_load < thrDBCUL

OR
UL_load < thrCACUL AND UL_environment_status =
“Cell Center”
UL PS bearer with 384k UL_load < thrDBCUL AND UL_environment_status =

“Cell Center”
DL PS bearer with 8k, 16k or 32k or 64k DL_load < thrCACDL
DL PS bearer with 128k DL_load < thrDBCDL

OR
DL_load < thrCACDL AND DL_environment_status =
“Cell Center”
DL PS bearer with 384k loadDL < thrDBCDL AND DL_environment_status =

“Cell Center”

CS bearer to be granted
A similar algorithm applies for CS services:
CS bearer Condition for the bearer to be granted
UL non-emergency CS bearer with 12.2k or 64k UL_load < thrCACUL
UL emergency CS bearer with 12.2k UL_load < thrCACEmergencyUL
DL non-emergency CS bearer with 12.2k or 64k DL_load < thrCACDL
DL emergency CS bearer with 12.2k DL_load < thrCACEmergencyDL
If DBC admission check fails in DL only and DL is allocated on DCH, then the DL
data rate shall be the next lower one. The UL rate shall be the existing UL rate. If
no such combination exists, the UL rate can be negotiated, too.
If DBC check fails in UL only, then the UL data rate shall be changed to the next
lower one. The DL rate shall be the existing DL rate. If no such combination exists
and DL is allocated on DCH, the DL rate can be negotiated, too. If DL is allocated
on HS-DSCH, the DL rate cannot be negotiated.
If finally no combination could be found, DBC negotiation shall be rejected and
procedure shall be stopped.
Parameters
Parameter dBCQualReportingCriteriaDLEcN0thres |
ecN0thres
Object Lcell | DBCQualReportingCriteriaDL
[-24…0]
Class Class 3
Value -13
Parameter dBCQualReportingCriteriaULEcN0thres |
ecN0thres
Object Lcell | DBCQualReportingCriteriaUL
[-24…0]
Class Class 3
Value -8

Parameter thrDBCUL
Object Lcell
Range & Unit Integer (%)
[0…100]
Class Class 3
Value 100
Parameter thrCACUL
Object Lcell
[0…100]
Class Class 3
Value 100
Parameter thrCACEmergencyUL
Object Lcell
[0…100]
Class Class 3
Value 100
Rule: thrDBCUL, thrCACUL and thrCACEmergencyUL
UL RSSI will strongly increase when UE is close to the BSR. Therefore, thrDBCUL, thrCACUL
and thrCACEmergencyUL must be set to 100% so as to disable UL load management.
Parameter thrDBCDL
Object Lcell
[0…100]
Class Class 3
Value 50
Parameter thrCACDL
Object Lcell
[0…100]
Class Class 3
Value 75

Parameter thrCACEmergencyDL
Object Lcell
[0…100]
Class Class 3
Value 90
Rule: thrDBCDL, thrCACDL and thrCACEmergencyDL
thrDBCDL must be lower than thrCACDL.

thrCACDL must be lower than thrCACEmergencyDL.
3.6.2 DBC BASED ON BASEBAND PROCESSING LIMITATION

The BSR shall reject all RAB Setup which is not Emergency call when the most
recent measured DL_load is greater than or equal to thrConCDL.
Parameter thrConCDL
Object Lcell
[0…100]
Class Class 3
Value 90
Otherwise, the BSR shall check whether:

1. the DL resource consumption is ok,
2. the UL resource consumption is ok,
3. the UL Spreading Factor (SF) usage (including the new RAB) is ok
4. the DL SF usage (including the new RAB) is ok,
5. multiple RAB service combination is supported.
In case one of these checks fails, the BSR renegotiates the RAB setup as
presented in section 3.6.1. If renegotiation attempt fails, BSR pre-empts resources
from other established PS RAB by reconfiguring it (several PS RABs if needed).
If the new RAB is a CS emergency voice call and the PS RAB(s) pre-emption did
not release enough resources, the BSR will pre-empt an existing CS RAB (CS
Data first, then CS Voice) if emergencyCallPreemptionEnabled is set to True.

In the case the BSR is configured in Semi Open Access Mode, and one of the
above mentioned checks fails, the BSR will start renegotiating the UL, DL or both
directions datarate of a PS call for a UE identified as Public.
In the case the check still fails and BSR::enableRABDowngradeAllUsers =
TRUE, the BSR will renegotiate the UL, DL or both directions datarate of a PS call
for a UE identified as guest and finally owner.
Following the introduction of the Prioritized Open Access Feature, the priorization
is performed also for Closed Access BSRs. In the case one of the above
mentioned checks fails for a Closed Access Mode BSR, the BSR will renegotiate
the UL, DL or both directions datarate of a PS call for a UE identified as guest and
then as owner.
Parameter enableRABDowngradeAllUsers
Object BSR Profile
{True, False}
Class Class 3
Value TRUE
3.7. AIR INTERFACE CONGESTION CONTROL

For the purpose of UL and DL load calculation, BSR periodically evaluates the
Received Total Wideband Power (RSSI) and Transmitted Carrier Power (TSSI).
When DL_load becomes greater than or equal to thrConCDL (parameter is
presented in section 3.6.2), Congestion Control is triggered for DL and BSR starts
pre-empting existing RAB(s) until DL_load < thrConCDL in the following order:
• PS DCH of the highest data rate with lowest traffic handling priority.
• If no PS DCH left, CS Data.
• If no PS DCH and CS Data left, CS Voice (non-emergency call).
• If no PS DCH, no CS Data and no CS Voice (non-emergency call) left, CS
Voice (emergency call).
3.8. CAC/DBC IN CASE OF HANDOVER FOR HIGHER

PRIORITY SERVICES
The target BSR applies the algorithms used for Call Admission Control and
Dynamic Bearer Control checks for Handover Admission Control.

3.8.1 SUCCESSFUL CASES
The BSR will allow a handover if all CAC and DBC checks pass for the requested
resources
¾ the number of users is less that LCELL::numCellDCHUE
¾ the UL and DL load are below the permitted thresholds
¾ the DBC baseband processing limits have not been exceeded
3.8.2 FAILURE CASES

If the target BSR determines from CAC/DBC checks that there are insufficient
resources to support the handover request, it will try to apply the procedure
described in 3.8.2.3 and 3.8.2.4 to accommodate the call.
If none of these is possible, the handover request will be rejected.
3.8.2.1 BACKHAUL CHECK
During an incoming Femto to Femto HO, the BSR use Backhaul Resource Management to
verify whether there are sufficient backhaul bandwidth resources to support the
incoming call as follows:
¾ If BSR::enableTransportCAC=TRUE and BSR::enableAbwMeasurements=
TRUE and ABW measurement results are available
o Then the BSR compares the new total bandwidth costs against
the current ABW value
¾ If BSR::enableTransportCAC=TRUE and BSR::enableAbwMeasurements=
TRUE and ABW measurement results are not available
o Then the BSR compares the new total bandwidth costs against the
maximum DSL bandwidth value
¾ If BSR::enableTransportCAC=TRUE and BSR::enableAbwMeasurements=
FALSE
o  Then the BSR compares the new total bandwidth costs against
the maximum DSL bandwidth value
¾ If BSR::enableTransportCAC= FALSE
o Then the BSR admits the call without any check on the bandwidth
costs
If there are insufficient backhaul bandwidth resources to support the handover

request and it is not for an emergency call, the handover request shall be rejected.
If there are insufficient backhaul bandwidth resources to support the handover
request and the call is an emergency call, the BSR behaviour is described in
3.8.2.2.

3.8.2.2 EMERGENCY CALLS WITH FAILED TRANSPORT CAC
If the BSR receives an incoming inter-BSR handover request of an emergency call

and transport CAC checks fails for the requested resources, the BSR applies the
following measures in order to permit the handover of the emergency call:
¾ If BSR::enableEmergencyFemtoHandoverPreemption = TRUE the BSR
preempts an existing Cell_DCH UE based upon the order defined below:
o Cell DCH UE of type public with only CS Data
o Cell DCH UE of type public with only CS Voice and not emergency
call
o Cell DCH UE of type public with CS Voice but not emergency call
and PS RAB of traffic class = I/B class
o Cell DCH UE of type guest with only CS Data
o Cell DCH UE of type guest with only CS Voice and not emergency
call
o Cell DCH UE of type guest with CS Voice but not emergency call
o Cell DCH UE of type owner with only CS Data
o Cell DCH UE of type owner with only CS Voice and not emergency
call
o Cell DCH UE of type owner with CS Voice but not emergency call
¾ I f BSR::enableEmergencyFemtoHandoverPreemption = FALSE and
BSR::enableEmergencyFemtoHandoverCallRedirection = TRUE the
BSR attempts active Call Redirection of an existing call.
If emergency call handover pre-emption is disabled or active call redirect is

disabled or either pre-emption or redirect fails to release the resources required to
support the emergency call handover, the handover request will be rejected.
Parameter enableEmergencyFemtoHandoverPreemption
Object BSR Profile
{True, False}
Class Class 3
Value FALSE

Parameter enableEmergencyFemtoHandoverCallRedirection
Object BSR Profile

{True, False}
Class Class 3
Value FALSE
3.8.2.3 EMERGENCY CALLS
If the BSR receives an incoming inter-BSR handover request of an emergency call

and CAC or DBC checks fail for the requested resources, the BSR applies the
following measures in order to permit the handover of the emergency call:
¾ If BSR::enableEmergencyFemtoHandoverPreemption = TRUE the BSR
preempts an existing Cell_DCH UE based upon the order defined below:
1. If The DBC checks on the UL and DL resource consumption
passes, Cell DCH UE of type public with only PS RAB of traffic
class = I/B class
2. Cell DCH UE of type public with only CS Data
3. Cell DCH UE of type public with only CS Voice and not emergency
call
4. Cell DCH UE of type public with CS Voice but not emergency call
passes, Cell DCH UE of type guest with only PS RAB of traffic
class = I/B class
6. Cell DCH UE of type guest with only CS Data
7. Cell DCH UE of type guest with only CS Voice and not emergency
call
8. Cell DCH UE of type guest with CS Voice but not emergency call
passes, Cell DCH UE of type owner with only PS RAB of traffic
class = I/B class
10. Cell DCH UE of type owner with only CS Data
11. Cell DCH UE of type owner with only CS Voice and not
emergency call
12. Cell DCH UE of type owner with CS Voice but not emergency call

¾ If BSR::enableEmergencyFemtoHandoverPreemption = False and
BSR::enableEmergencyFemtoHandoverActiveCallRedirect = True the
BSR will attempt active Call Redirection of an existing call.
If emergency call handover preemption is disabled or active call redirect is disabled

or either pre-emption or redirect fails to release the resources required to support
the emergency call handover, the handover request will be rejected.
3.8.2.4 NORMAL CALLS
For an incoming inter-BSR handover request of a non-emergency CS voice call if

CAC fails due to load or DBC fails, the BSR shall downgrade an existing PS RAB
as specified below and accept the handover request.
If only the DL SF usage check fails, the BSR shall downgrade
1. an existing PS RAB of user type public with the highest DL DCH rate
2. an existing PS RAB of user type guest with the highest DL DCH rate (if
BSR::enableRABDowngradeAllUsers = TRUE)
3. an existing PS RAB of user type owner with the highest DL DCH rate (if
If only the UL SF usage check fails, the BSR shall downgrade

1. an existing PS RAB of user type public with the highest UL DCH rate
2. an existing PS RAB of user type guest with the highest UL DCH rate (if
3. an existing PS RAB of user type owner with the highest UL DCH rate (if
If the UL and DL SF usage checks fail, the BSR shall downgrade

1. an existing PS RAB of user type public with the highest UL DCH rate
associated DL DCH
2. an existing PS RAB of user type guest with the highest UL DCH rate
associated DL DCH (if BSR::enableRABDowngradeAllUsers = TRUE)
3. an existing PS RAB of user type owner with the highest UL DCH rate
associated DL DCH (if BSR::enableRABDowngradeAllUsers = TRUE)
For an incoming inter-BSR handover request of a non-emergency CS voice call if

CAC fails due to unavailability of a DCH or the BSR has been unable to downgrade
a PS RAB then the BSR will attempt to perform pre-emption of a lower priority call
using the following measures in order to permit handover of the call:

¾ if BSR::enableNonEmergencyFemtoHandoverPreemption = True the
BSR shall pre-empt and existing CellDCH UE based upon the order
defined below:
o Cell DCH UE of type public with only PS RAB
o Cell DCH UE of type guest with only PS RAB
o Cell DCH UE of type owner with only PS RAB
If Preemption is disabled or fails to release sufficient resources to allow the

handover UE to be supported the incoming handover request shall be rejected.
Parameter enableNonEmergencyFemtoHandoverPreemption
Object BSR Profile

{True, False}
Class Class 3
Value FALSE

3.9. MULTIPLE PDP CONTEXTS
3.9.1 INTRODUCTION
Some UEs, especially Smart Phones like ones, may request several primary PDP
contexts to be activated. This results in a new IP address being created for the new
PDP context. The motivation of this is to do with data network design, where an
operator may want to route certain services through a separate APN at the GGSN
(Gateway GPRS Support Node). This APN may then go to a private data network.
Examples may be:
1) One PDP context for general IP networking and one for customer VPN
(Virtual Private Network) services
2) One PDP context for general IP networking and one for operator IMS
3) One PDP context for general IP networking and one for a special service
provided by the operator
4) One PDP context for general IP networking, one for operator IMS and
one for a special service provided by the operator
In this context, the support of up to three PDP contexts (both with and without a
voice call) are of a necessity for the operator, and if such MPDP contexts scenarios
are supported by the macro, then lack of support on the BSR will most likely block
user services.
3 PDP Contexts are only supported on the v2 and later hardware.

Earlier Hardware platforms do only support the establishment of up to 2 PDP contexts.
Figure 16 and Figure 17 present an overview of different PDP Context Scenarios.
Figure 16 – Two Primary PDP Contexts

Figure 17 – Three Primary PDP Contexts
3.9.2 FEATURE ACTIVATION

When setting the parameter isMpdpIBsupported to TRUE, the BSR will offer the
possibility to UEs to establish multiple PDP Contexts in parallel. The parameter
maxNoOfMpdpSupported gives the maximum number of PDP Contexts a UE can
establish simultaneously.
Parameter isMpdpIBsupported |
Object Femto | BSR
{True, False}
Class Class 3
Value TRUE
Parameter maxNoOfMpdpSupported
Object BSR Profile
[0..3]
Class Class 3
Value 2
The feature 121160 – 32 user capacity on V2 Enterprise and metro cell -

introduces a new parameter pdpContextPoolSize. This parameter indicates the
total number of PDP context across all users which are allowed to be established
on the BSR.
BSR keeps a count of the total number of PDP contexts established on the BSR
and if the count equals pdpContextPoolSize then the next RAB Assignement
Request for a PS RAB will be rejected in the RAB Assignment Response with
cause “No Ressource Available”.

Parameter | pdpContextPoolSize
Object | BSR
Granularity | BSR
Class Class 3
Value 48
3.9.3 MAC
The standards allow different options for supporting multiple PDP contexts on the
physical/MAC layer, but the industry has converged to a method which the UE
(conformance and testing) and UTRAN have adopted on existing deployments and
this method is used to minimize any interoperability issues.
They are as follows :

1) Multiple I/B RABs on DCH are MAC-d multiplexed onto one
transport channel and the transport channel bandwidth is contended
for between the multiple RABs. This keeps the physical channel
resource usage low. The MAC-d multiplexing adds 4 bits onto the
physical layer for the C/T logical channel field when multiple PDP
contexts exist. The Femto user plane is required to schedule the
multiple PDP contexts through MAC-d onto the transport channel.
2) Multiple I/B RABs on HSDPA are carried over separate MAC-d
flows. This means that each MAC-d flow is not impacted in structure
when multiple PDP contexts exist.
3) Multiple I/B RABs on E-DCH (Enhanced - DCH) are carried over
separate MAC-d flows. This means that each MAC-d flow is not
impacted in structure when multiple PDP contexts exist.
3.9.4 CALL FLOWS

Figure 18 presents the call flow when activating an additional primary PDP
Context.
On Figure 19, the PDP Context deactivation procedure is described.

Figure 18 – Activation of an additional Primary PDP Context
Figure 19 – Deactivation of a PDP Context

3.10. SERVICE BASED REDIRECTION & HANDOVER TO

TARGETED MACRO LAYER
3.10.1 INTRODUCTION
This feature, when enabled by setting the parameter sBEnable =True, will provide
the BSR with the means to redirect or handover singly or in combination configured
service types, which includes CS voice, non-HSPA PS data, HSPA PS Data and
PS streaming to the macro layer.
This may occur at one of 2 stages in the call establishment procedure:

1. At RRC connection where the connection request is rejected with
redirection information included before the connection can be established
2. Following the RAB establishment by handover to the targeted macro layer.
The feature can be enabled by the operator through the FMS and the service types
and target macro layer and frequency will be configurable. The target layer can be
UMTS, GSM or either with one preferred.
Emergency calls will not be subject to service based redirection or handover.

Incoming handover calls will not be subject to service based handover.
The frequency and band for the target 3G macro cell for redirection or handover is
configurable (for handover the cell must also be in the detected list). If not
configured, the strongest of the cells detected by the 3G Network listening function
run during auto-configuration and self-optimisation.
Rule: umtsPreferredBand
The strongest cell selection from umtsMacroNCell only depends on the setting of
umtsPreferredBand (i.e. even if the Dual Band feature is deactivated). If the selection criteria
indicates to choose a cell from the detected list umtsMacroNCell then the cell chosen depend on
umtsPreferredBand:
• If umtsPreferredBand is configured with a umts band, then the strongest suitable
detected cell is chosen in that band. If there is no suitable cell, the strongest suitable
cell is chosen ignoring the band.
If umtsPreferredBand (i.e. ‘noBand’), the strongest suitable cell from umtsMacroNCell is chosen
ignoring the band.

The target 2G macro cell for redirection or handover will be from the strongest of
the cells detected by the 2G Network listening function run during auto-
configuration and self-optimisation.
Rule: gsmPrefeffedBand
The strongest cell selection from gsmMacroNCell only depends on the setting of
gsmPreferredBand. If the selection criteria indicates to choose a cell from the detected list
gsmMacroNCell then the cell chosen depends on the setting of gsmPreferredBand:
• If gsmPreferredBand is configured with a gsm band, the strongest suitable detected cell
in that band is chosen. If there is no suitable cell in that band, the strongest suitable cell is
chosen ignoring the band.
• If gsmPreferredBand is not configured (i.e. ‘noBand’), the strongest suitable detected cell
is chosen ignoring the band.
Parameter sBEnable |
{True, False}
Class Class 3
Value FALSE
Engineering Recommendation: Shared Carrier deployments
Active Call Redirection or SB HO on Intra-Frequency will result in high drop call rates. Therefore it
is strongly recommended not to use ACR and SB HO in the case of Shared Carrier deployments.
Restriction: Assumption
The feature 100889 assumes that the BSR will be deployed on a separate FDD frequency than the
Macro layer.
3.10.2 REDIRECTION AT RRC CONNECTION

On receipt of a RRC Connection Request message from a UE, and before all other
CAC procedures, the BSR will, based on the establishment cause and access
stratum release indicator in the RRC Connection request message either redirect
the request or pass it on to Call Admission Control.
The parameters for the selection of the RRC redirection are configurable through
the RRC mapping table LCELL::rrcMappingTable. Table 3 provides with an
example of a possible configuration.

The LCELL::rrcMappingTable contains following fields:

¾ establishmentCause
¾ sBReDirect
¾ sBMacroTarget
¾ sBTargetFddULFreq
¾ sBTargetFddDLFreq
Note: the service type can be determined from a combination of establishment

cause and terminal capability via the access stratum release indicator in the RRC
Connection Request message. A prerelease 5 terminal will not have HSPA
capability. The parameter establishmentCause and sBReDirect allows this
choice.
If the BSR has determined that a connection shall be redirected then the BSR
determines from the RRC mapping table, the macro layer, sBMacroTarget and,
the UL and DL frequencies for redirection, sBTargetFddULFreq,
sBTargetFddDLFreq. The target cell for the chosen macro layer shall be
determined from the configured frequency for 3G if present or the strongest cell,
previously found during auto-configuration or self-optimisation by the network
listening function.
The Femto send an RRC Connection Reject message with Redirection Info
element included to redirect the in-coming connection request.
establishmentCause sBReDirect sBMacroTarget sBTargetFddULFreq sBTargetFddDLFreq
originatingConversationalCall allUE gsmPreferred UL ARFCN DL ARFCN
originatingStreamingCall no n/a n/a n/a
originatingInteractiveCall no n/a n/a n/a
originatingBackgroundCall no n/a n/a n/a
terminatingConversationalCall no n/a n/a n/a
terminatingStreamingCall no n/a n/a n/a
terminatingInteractiveCall no n/a n/a n/a
terminatingBackgroundCall no n/a n/a n/a
Table 3 - RRC Connection Mapping Table

Engineering Recommendation: Terminating Calls
In the case of terminatingConversationalCall a hand over is to be preferred to a redirection. This

is to ensure that the call is routed correctly to the Gateway MSC.
There might be an issue when a different MSC is used in the target cell, and the terminating call
may not be recognised.
Parameter sBReDirect
Object Lcell::RrcMappingTable
Granularity RrcMappingTable
Range & Unit enum
{no=1,
allUE=2,
allNonHspaUE=3,
allHspaUE=4}
Class Class 3
Value no
Parameter establishmentCause
Range & Unit enum
{originatingConversationalCall =0,
originatingStreamingCall =1,
originatingInteractiveCall =2,
originatingBackgroundCall =3,
originatingSubscribedTrafficCall =4,
terminatingConversationalCall =5,
terminatingStreamingCall =6,
terminatingInteractiveCall =7,
terminatingBackgroundCall =8,
emergencyCall =9,
interRATCellReselection =10,
interRATCellChangeOrder =11,
registration =12,
detach =13,
originatingHighPrioritySignalling =14,
originatingLowPrioritySignalling =15,
callReestablishment =16,
terminatingHighPrioritySignalling =17,
terminatingLowPrioritySignalling =18,
terminatingCauseUnknown =19,
other =255}
Class Class 3
Value -

Parameter sBMacroTarget
Range & Unit enum
{disable=0,
gsm=1,
fdd=2,
gsmPreferred=3,
fddPreferred=4}
Class Class 3
Value fddPreferred
Parameter sBTargetFddULFreq
[0..16383]
Class Class 3
Value 0
Parameter sBTargetFddDLFreq
[0..16383]
Class Class 3
Value 0
3.10.3 HANDOVER AT CS RAB ESTABLISHMENT

Following successful RAB establishment on behalf of a RANAP RAB Assignment
Request from the CS domain, the Femto shall, based on the traffic class and
source statistics descriptor, tag the RAB for possible handover depending on the
RAB mapping table, LCELL::sBCsRabMappingTable.
The LCELL::sBCsRabMappingTable contains a list of the traffic class for the
RAB that are to be marked for handover.
Note: statistics descriptor is used to distinguish between CS voice and CS data

both of which could use traffic class conversational.
Emergency call are not be tagged for handover.
In the case a IuPS connection already exists for a give UE, when a CS RAB is
established, then if simultaneous bearer handover is not configured,

LCELL::sBSimBearerHO=FALSE, the RAB will not be tagged for handover,
otherwise, it will be tagged for handover.
When establishing the RAB, current RAB establishment procedures and admission
control shall be followed.
The target layer and 3G frequency for service based handover shall be determined
from LCELL::targetHOCS and LCELL::sBtargetHOFddFreqCS for a single
bearer and LCELL::targetHOCSPS and from LCELL::sBtargetHOFddFreqCSPS
for a simultaneous bearer.
Inter-Release Delta: LCELL::targetHOFddFreqCS, LCELL::targetHOFddFreqCSPS
From FPUG 3.0, the objects LCELL::targetHOFddFreqCS and LCELL::targetHOFddFreqCSPS

are renamed in LCELL::sBtargetHOFddFreqCS and LCELL::sBtargetHOFddFreqCSPS.
LCELL::targetHOFddFreqCS still exists but does not concern service based handover (see [Vol.
5]). LCELL::targetHOFddFreqCSPS is obsolete.
LCELL::targetHOCS and LCELL::targetHOCSPS are the same parameters as

the one used for the Mobility selection and is presented in [Vol. 5].
LCELL::sBtargetHOFddFreqCS and LCELL::sBtargetHOFddFreqCSPS

provide with the freqBand, uARFCNDL and uARFCNULof the targeted Macro
Layer.
To execute service based handover, an SRNS relocation procedure will be
triggered if the UE's capabilities allow. The target cell for the chosen macro layer
and frequency if configured will be determined from the strongest 2G or 3G cell,
above the handover threshold, previously found during auto-configuration or self-
optimisation by the network listening function.
Rule: Network listening Frequency Bands and Frequencies
The 2G or 3G Macro that will be chosen for the Handover will have to be detected during the auto-
configuration or selfoptimisation.
This implies that 2G or 3G Frequency band and frequencies are configured for the auto-
configuration or selfoptimisation (see [Vol. 5]).
If the first SRNS Relocation attempt fails for service based handover then there will
be no retry and the RAB will be kept established on the BSR with ongoing
handover based on measurement reports continuing.

Parameter trafficClassRAB
Object Lcell::SBCsRabMappingTable
Granularity SBCsRabMappingTable
Range & Unit enum
{conversational=0,
streaming=1,
interactive1=2,
background=3}
Class Class 3
Value conversational
Parameter sBSimBearerHO
Object Lcell
{True, False}
Class Class 3
Value FALSE
Parameter freqBand
Object LCell::sBtargetHOFddFreqCS
Class Class 3
Value -
Parameter uARFCNDL
[0..16383]
Class Class 3
Value -
Parameter uARFCNUL
[0..16383]
Class Class 3
Value -

Parameter freqBand
Object LCell::sBtargetHOFddFreqCSPS
Class Class 3
Value -
Parameter uARFCNDL
[0..16383]
Class Class 3
Value -
Parameter uARFCNUL
[0..16383]
Class Class 3
Value -
3.10.4 SERVICE BASED ACTION ON INCOMING HANDOVER

The BSR will disable the incoming handover of CS calls from 2G and 3G macro
respectively when Service based handover of CS calls are configured.
RABs established as a result of an incoming relocation request from the 2G or 3G
macro will not be tagged for service based handover.
This is mainly to avoid ping-ponging calls between Macro and Femto.
For the same reason, a RAB established as a result of an incoming handover from
another BSR will also not be tagged for service based handover.

3.11. PDP DEACTIVATION DURING MACRO <-> BSR MOBILITY

In some BSR deployments it is desirable to deactivate a PDP context as the UE
moves between the macro and the Femto network.
This deactivation is achieved entirely by means of the BSR network, and provides
a mean to perform it in both, the direction of the Macro to the BSR and the BSR to
the Macro.
The BSR makes use of the scenarios within [3GPP_R05] in the following ways:
4. During Macro to BSR reselection, the BSR deactivates the PDP context
by corrupting the active PDP contexts reported by the UE.
5. During activation of a PDP context on the BSR, the BSR translates the
NSAPI (Network layer Service Access Point Identifier) requested by the
UE towards the SGSN. The BSR maintains this translation for the
lifetime of the call. When the UE reselects to the Macro, the SGSN and
UE will see a mismatch during the RAU procedure and will deactivate
the PDP contexts
3.11.1 ACTIVATION
The deactivation of the PDP context can be configured either for outgoing,
incoming or both direction PS session. The parameters
BSR::enableIncomingDataShutdown and
BSR::enableOutgoingDataShutdown will allow the activation of the features in
either direction.
3.11.2 ASSUMPTIONS - RESTRICTIONS

Each BSR is provisioned on a LAC different from the Macro network. This is to
ensure that the UE will perform a Routing Area Update when it enters the BSR
coverage. The BSR should also have a different RAC than the underlay Macro.
If outgoing PDP de-activation is required, then it is assumed that the volume of
traffic is not high - i.e. the BSR is not deployed in a public area in open access.
This is required to ensure that the number of contexts stored in the BSR is kept
low.
Outgoing PDP deactivation is not enabled on BSRs in a group configuration.
Indeed, the PDP context info can not be transferred between BSRs.
It is assumed that the SGSN and UE follow the procedures in [3GPP_R05].
The UE behaviour during PDP context deactivation is not standardised and it is UE
manufacturer specific whether the UE automatically and seamlessly re-activates
the PDP context.

3.11.3 INCOMING SHUTDOWN OF DATA SESSION
If the parameter BSR::enableIncomingDataShutdown is set to TRUE, upon
reception of a NAS Routing area update request from a UE with updating cause
not equal to Periodic updating, the BSR shutdown the incoming data session by
setting the PDP context status to PDP inactive for all PDP contexts.
The BSR ensures that the Routing Area Update Accept also has the PDP context
status set to PDP inactive for all PDP contexts. If it is not or it is not present, then
the BSR includes it and set it to inactive.
Figure 20 presents the call flow for a PDP context shutdown in the case of an
incoming mobility.
Parameter enableIncomingDataShutdown
Object BSR Profile
{True, False}
Class Class 3
Value FALSE
Figure 20 - PDP context shutdown on incoming mobility
3.11.4 OUTGOING SHUTDOWN OF DATA SESSION

If BSR::enableOutgoingDataShutdown = TRUE, the BSR will apply outgoing
data shutdown as described in the following chapter.

Parameter enableOutgoingDataShutdown
Object BSR Profile
{True, False}
Class Class 3
Value FALSE
3.11.4.1 UE CONTEXT
The BSR Femto stores the following information for data shutdown with respect to
each PDP context:
1) UE NSAPI which is used to represent the NSAPI that the UE is aware of
(Default to none when BSR::enableIncomingDataShutdown=TRUE)
2) SGSN NSAPI which is used to represent the NSAPI that the SGSN is aware of
(May be the same NSAPI for incoming PDP contexts when
BSR::enableIncomingDataShutdown=FALSE)
2) Transaction Identifier of the NSAPI and its optional - The transaction indication
of the PDP context which may be used to deactivate the PDP context
3) Linked TI for multiple PDP context and its optional
3.11.4.2 RAU LOCATION UPDATE AND ATTACH
On reception of a NAS Routing area update request from a UE, that passes the
ACL checks, with updating cause not equal to Periodic updating, the BSR
determines the Active NSAPI contexts from the Request and stores them. This
concerns scenarios where incoming Data Shutdown is deactivated, but outgoing
Data Shutdown is activated.
3.11.4.3 PERIODIC RAU
On reception of a NAS Routing area update request from a UE with cause equal to
Periodic updating, the BSR translates the Active NSAPI contexts from the Routing
Area Update Request with the UE NSAPI stored by the BSR.
The BSR translates the Active NSAPI contexts from the corresponding NAS
Routing area update accept (Identified by the TI) with the SGSN NSAPI stored in
the BSR.
Figure 21 illustrates the Periodic Routing Area Update in the case of Outgoing
Data Shutdown activated.

Figure 21 – Periodic Routing Area Update
3.11.4.4 SERVICE REQUEST
On reception of a NAS Service Request from a UE, the BSR translates the Active
NSAPI contexts from the Service Request with the translated UE NSAPI stored in
the BSR.
The BSR translates the Active NSAPI contexts from the corresponding NAS
Service Accept (Identified by the TI) if present with the SGSN NSAPI stored in the
BSR.
The call flow describing the Service Request in the case of
OutgoingDataShutdown activation is presented in Figure 22.
Figure 22 – Service Request
3.11.4.5 PDP CONTEXT ACTIVATION IN THE BSR FEMTO
On reception of a NAS Activate PDP Context request from a UE, the BSR
determines the Requested NSAPI IE (UE NSAPI) and Transaction Identifier (TI)
from the NAS message as shown on Figure 23.
If the UE requests a NSAPI IE that maps to a SGSN NSAPI stored in the BSR for
that UE, the BSR will deactivate the clashing PDP context towards the UE and
SGSN before proceeding with the PDP context activation.

The BSR then translates the requested NSAPI to a translated NSAPI (SGSN
NSAPI) as follows :
If
¾ The requested NSAPI is the same as an existing UE NSAPI in the UE
context, the original translation is performed.
Otherwise
¾ The BSR chooses a translated NSAPI from the not-used ones and stores
the NSAPI translation and the TI.
¾ To the SGSN, the BSR replaces the requested NSAPI IE with the
translated NSAPI.
¾ From the SGSN to the UE, the BSR intercepts the Activate PDP Context
Accept and replace the NSAPI IE with the UE NSAPI.
When outgoing Data shutdown is enabled, the BSR applies the same procedures
for NSAPI translation during multiple PDP context activation as during primary PDP
context activation, with the additional step that the Linked TI in the other PDP
Context Request is decoded and stored in the UE context.
Figure 23 – PDP Activation
3.11.4.6 RAB ASSIGNMENT
On reception of a RANAP RAB Assignment from the SGSN, the BSR translates
the RAB ID from the RANAP RAB Assignment with the translated UE NSAPI
stored in the BSR when sending a RRC Radio Bearer Setup towards the UE.
Any RANAP message using a RAB ID from the BSR to the SGSN (i.e. RAB
Assignment Response) will use the RAB ID from the SGSN.

3.11.4.7 PDP DEACTIVATION
On Reception of a NAS Deactivate PDP Context Accept from the SGSN, the BSR
decodes the TI and Tear Down Indicator IE, and removes any PDP context
information from the UE Context related to the TI.
If the Tear Down Indicator indicates Tear Down Requested, the BSR removes all
PDP contexts on the Linked TI.

4. INDEXES
4.1. TABLE INDEX

Table 1 - Typical Open Access BSR in public areas deployments -
BSR::fachRrcEstablishmentCause[i] .......................................................................................... 7
Table 2 - Other deployments - BSR::fachRrcEstablishmentCause[i]................................................. 8
Table 3 - RRC Connection Mapping Table ...................................................................................... 62
4.2. FIGURE INDEX

Figure 1 - BSR supported RRC States .............................................................................................. 6
Figure 2 - CS RAB Establishment in Cell_FACH state .................................................................... 10
Figure 3 - PS RAB Establishment in Cell_FACH state .................................................................... 10
Figure 4 - RAB Establishment on 13.6kbps DCCH.......................................................................... 13
Figure 5 - RRC Connection Establishment in Cell_FACH state ...................................................... 15
Figure 6 - LAU/RAU in Cell_FACH state.......................................................................................... 15
Figure 7 - Procedure Guard Timer ................................................................................................... 17
Figure 8 - Physical Channel Failure ................................................................................................. 18
Figure 9 - UE Bug Work Around....................................................................................................... 19
Figure 10 - RRC Connection Release Retransmission.................................................................... 21
Figure 11 – RRC Connection Release and UE retransmission ....................................................... 22
Figure 12 – Paging UE unkown........................................................................................................ 25
Figure 13– Paging with Paging Co-ordination – UE in RRC CELL_DCH state ............................... 25
Figure 14 – DSCR case ................................................................................................................... 32
Figure 15 – Non DSCR case and loss of data ................................................................................. 32
Figure 16 – Two Primary PDP Contexts .......................................................................................... 56
Figure 17 – Three Primary PDP Contexts........................................................................................ 57
Figure 18 – Activation of an additional Primary PDP Context.......................................................... 59
Figure 19 – Deactivation of a PDP Context ..................................................................................... 59
Figure 20 - PDP context shutdown on incoming mobility................................................................. 69
Figure 21 – Periodic Routing Area Update ...................................................................................... 71
Figure 22 – Service Request............................................................................................................ 71
Figure 23 – PDP Activation .............................................................................................................. 72

Z END OF DOCUMENT Y


VOLUME 5 MOBILITY MANAGEMENT

CONTENT OF VOLUME 5
1. INTRODUCTION............................................................................................................................4
1.1. OBJECT....................................................................................................................................4

2.1. FPUG VOLUMES ......................................................................................................................4
3. MOBILITY MANAGEMENT...........................................................................................................6
3.1. NEIGHBOURHOOD DEFINITION ...................................................................................................6
3.1.1 Hierarchical Cell Structure (HCS) ...................................................................................6
3.1.1.1 Introduction to HCS .....................................................................................................6
3.1.1.2 HCS in the BSR...........................................................................................................7
3.1.2 Equivalent Public Land Mobile Network (ePLMN) ........................................................14
3.1.3 3G Macro neighbourhood .............................................................................................17
3.1.3.1 NeighBourlist Parameters .........................................................................................17
3.1.3.2 Neighbour Eligibility...................................................................................................22
3.1.3.3 Neighbour Measurements .........................................................................................23
3.1.3.4 Neighbour List Generation ........................................................................................24
3.1.4 GSM Macro neighbourhood..........................................................................................26
3.1.4.1 GSM NeighBourlist Parameters ................................................................................26
3.1.4.2 Neighbour Eligibility...................................................................................................32
3.1.5 BSR Neighbourhood .....................................................................................................35
3.1.5.1 NeighBourlist Parameters .........................................................................................35
3.1.5.2 Inter BSR Communication.........................................................................................36
3.1.5.5 Determination of SFN Offset .....................................................................................39
3.2. CELL RESERVATION AND ACCESS RESTRICTION .......................................................................40
3.2.1 Cell Status and Cell Reservation ..................................................................................41
3.2.2 Access Class Barring....................................................................................................42
3.2.3 Access Control ..............................................................................................................42
3.2.3.1 Closed Access Mode.................................................................................................43
3.2.3.2 Open Access Mode ...................................................................................................45
3.2.3.3 Semi-Open Access Mode..........................................................................................45
3.3. CELL SELECTION ....................................................................................................................47
3.4. CELL RESELECTION ................................................................................................................49
3.4.1 High Mobility Detection algorithm (HMD)......................................................................49
3.4.2 Cell Reselection Measurement Rules without HCS......................................................51
3.4.2.1 Intra-frequency measurements .................................................................................52
3.4.2.2 Inter-frequency measurements .................................................................................52
3.4.2.3 Inter-RAT measurements ..........................................................................................52
3.4.2.4 Measurement Triggers Parameters...........................................................................53
3.4.3 Cell Reselection Measurement Rules with HCS...........................................................55
3.4.3.1 HCS Priority...............................................................................................................55
3.4.3.2 Neighbouring measurement rules .............................................................................57

3.4.3.2.1 High-Mobility state NOT detected .............................................................................57
3.4.3.2.2 High-Mobility state detected ......................................................................................58
3.4.3.2.3 Recommendations when HCS is used......................................................................59
3.4.4 Cell Eligibility Criteria for REselection...........................................................................60
3.4.4.1 3G Neighbouring Cell Criteria ...................................................................................61
3.4.4.2 GSM Neighbouring Cell Criteria ................................................................................62
3.4.4.3 BSR Neighbouring Cell Criteria.................................................................................64
3.4.5 Cell Reselection – Ranking Criterion without HCS .......................................................65
3.4.5.1 First Ranking .............................................................................................................66
3.4.5.2 Second Ranking ........................................................................................................67
3.4.5.3 Target Cell Selection .................................................................................................68
3.4.6 Cell Reselection – Ranking Criterion with HCS ............................................................70
3.4.6.1 Quality Level Threshold H Criterion ..........................................................................70
3.4.6.2 HCS parameters........................................................................................................72
3.4.6.3 Ranking R Criterion ...................................................................................................73
3.4.6.4 Target Cell Selection .................................................................................................75
3.5. HANDOVER TO 3G/2G ............................................................................................................76
3.5.1 Eligibility for Handover ..................................................................................................76
3.5.1.1 Handover triggering ...................................................................................................76
3.5.1.2 Measurement Configuration ......................................................................................80
3.5.1.3 target cells ranking ....................................................................................................80
3.5.1.4 Compressed Mode (CM) ...........................................................................................83
3.5.1.5 Compliance with 3G network.....................................................................................86
3.5.2 Mobile assisted handover .............................................................................................87
3.5.2.1 Eligibility for handover ...............................................................................................89
3.5.2.1.1 Intra-frequency handover ..........................................................................................89
3.5.2.1.2 Inter-frequency handover ..........................................................................................89
3.5.2.2 Detection radio degradation ......................................................................................91
3.5.2.2.2 Inter-frequency/RAT handover ..................................................................................94
3.5.2.3 Handover execution ..................................................................................................97
3.5.2.3.2 Inter-frequency/RAT handover ..................................................................................98
3.5.3 Blind handover ............................................................................................................104
3.5.3.1 Detection radio degradation ....................................................................................104
3.5.3.2 Handover execution ................................................................................................107
3.6. BSR TO BSR HANDOVER .....................................................................................................109
3.6.1 Handover Principle......................................................................................................109
3.6.2 Handover Failure.........................................................................................................111
3.6.3 Measurement Control .................................................................................................112
3.6.4 Handover Execution....................................................................................................114
3.6.5 Handover Execution considering SFN Offset .............................................................115
3.6.5.1 Algorithm 1 ..............................................................................................................116
3.6.5.2 Algorithm 2 ..............................................................................................................116
3.6.5.3 Handover Execution ................................................................................................116
3.6.6 Target Cell Protection (Interference Reduction) .........................................................118
3.6.6.1 Motivation ................................................................................................................118
3.6.6.2 Failed Handover of a PS call...................................................................................118
3.6.6.3 Failed Handover of a CS+PS call............................................................................120
3.7. PRESENCE INDICATOR ..........................................................................................................121
3.7.1 Mobility Message ........................................................................................................121
3.7.2 Dedicated BSR PLMN ................................................................................................124
3.7.3 Tone generation during voice call setup .....................................................................124
3.7.4 MM/GMM Info Generation from Femto .......................................................................125
4. INDEXES ...................................................................................................................................127
4.1. TABLE INDEX ........................................................................................................................127

4.2. FIGURE INDEX ......................................................................................................................127

1. INTRODUCTION
1.1. OBJECT
This volume is dedicated to Features and Parameters related to the Mobility
Management in the BSRs.
2.1. FPUG VOLUMES


[Vol. 10] HSxPA

specification


reception (FDD)
specification

[3GPP_R14] 3GPP TS 25.402 Synchronisation in UTRAN Stage 2
[3GPP_R15] 3GPP TS 25.215 Physical layer - Measurements (FDD)


3. MOBILITY MANAGEMENT
Mobility Management is supported as follows:

• while in Idle, through Cell Reselection from/to UMTS, other BSR or GSM
Macro cells;
• while in DCH connected mode, through hard handover to UMTS, other
BSR or GSM Macro cells.
For that purpose, BSR must define and maintain a list of neighbouring cells using
auto-configuration and self-optimization procedures described in the following
sections.
3.1. NEIGHBOURHOOD DEFINITION
3.1.1 HIERARCHICAL CELL STRUCTURE (HCS)
3.1.1.1 INTRODUCTION TO HCS

3GPP defines a special cell re-selection algorithm in a Hierarchical Cell Structure
environment. With HCS, the reselection process will favor a smaller cells (with
higher priority), as depicted in Figure 1.
HCS also allows considering indirectly the speed of UEs in the reselection process.
Indeed, this speed is given by the number of reselections a UE would perform in a
given time, meaning that a UE moving in the coverage area of a single UMTS cell
will be considered as a static UE. If a UE is defined as moving, the reselection
process will favor bigger cells.
Defining HCS on a Layer (Macro or BSR) will result in UEs being either pushed to
smaller cells (static UEs) or bigger cells (moving UEs). HCS cannot ensure
keeping UEs in a given Layer, unless it has the highest/lowest priority or because
the reselection is postponed (using timers).
HCS also impact the UE behaviour on the layer it is defined in. For instance,
activating HCS at Macro level will impact Macro UEs. But it does not require any
changes on the BSR configuration and will not impact the cell reselection process
of UEs attached to the BSR.
Activating HCS on the BSR layer only make sense in the case the BSRs ensure a
continuous coverage and are deployed in a group. This is to ensure the UE will not
leave the BSRs coverage area (making the reselection happening naturally) and it
is possible to count reselections between BSRs to evaluate the speed.
However, it is very likely that fast moving UEs will go out of the coverage of the
BSR layers quite fast. There is therefore no real benefit to activate HCS on the
BSR Layer.

On the Macro layer, HCS makes more sense, as it gives some additional flexibility
with additional timers. Macro HCS could prevent a UE to reselect a BSR due to
higher timers (the BSR not being measured long enough). The speed of the UE is
not evaluated in the case (so no need to configure the corresponding parameters).
The current document only addresses HCS on the BSR Layer.
3.1.1.2 HCS IN THE BSR
Parameter enableHCS
Object Lcell
{True, False}
Class Class 3
Value FALSE
The algorithm is performed by the UE, but new HCS parameters are broadcasted
by the BSR in the system information message enabling the UE to run the HCS
algorithm.
The application of HCS in the BSR cell allows to improve the cell reselection
behaviour of UEs camping on the BSR cell:
• HCS allows to keep UEs in the BSR cell, even if the BSR cell quality
diminishes temporarily.
• HCS allows more flexibility in the configuration to keep stationary UEs in
the BSR cell.
• HCS helps to better manage the multilayer scenario. The use of priorities
allows determining the preferred macro cell layer.
The BSR supports 3 Layers as depicted in Figure 1:

• the GSM layer,
• the UMTS layer and
• the BSR layer.

Figure 1 - HCS Example
If HCS is enabled (enableHCS set to True), the BSR will broadcast following
parameters in the SIB3 message:
• hcsPrioS: This parameter specifies the HCS priority level (0-7) for the
neighbouring cells. HCS priority level 0 means lowest priority and HCS
priority level 7 means highest priority.
• qHCSs: This parameter specifies the quality threshold levels for applying
prioritised hierarchical cell re-selection for neighbour cells.
• tCRmax: This is the measurement interval for low/high mobility detection.
• nCR: This parameters is the number of cell reselections during TCRmax in
order to detect low/high mobility.
• tCRmaxHyst: This is an extra time to TCRmax before a UE can revert to
low mobility state.
• sIB3SpeedDependentScalingFactor: This parameter specifies the

scaling (multiplication) factor to be used by the UE in idle mode or RRC
connected mode states for the parameter Treselections in case high-
mobility state has been detected
• sLimitSearchRAT: Determines, when the UE starts/stops performing
GSM measurements in low mobility state when HCS is used.

Parameter hcsPrioS
Object Lcell
[0…7]
Class Class 3
Value 7
Parameter qHCSs
Object Lcell
[0…99]
Class Class 3
Value 0
Parameter tCRmax
Object Lcell
Range & Unit Enumerated (s)
{notUsed=0,t30=30,t60=60,t120=120,t180=180,t240=2
40}
Class Class 3
Value notUsed
Parameter tCRmaxHyst
Object Lcell
{NotUsed,t10,t20,t30,t40,t50,t60,t70}
Class Class 3
Value t20
Parameter nCR
Object Lcell
[1…16]
Class Class 3
Value 8

Parameter sIB3SpeedDependentScalingFactor
Object Lcell
[0.0…1.0] step 0.1
Class Class 3
Value 1
Parameter sLimitSearchRAT
Object Lcell
[-32…20]
Class Class 3
Value 0
Notes: Conditions for omitting parameters in IE ‘HCS Serving cell information’:
• HCS_PRIO shall not be included, if LCell::hcsPrioS = 0.

• Qhcs shall not be included, if LCell::qHCSs = 0.
• TCRmax shall not be included, if LCell::tCRmax = notUsed.
• NCR shall not be included, if LCell::tCRmax = notUsed.
• TCRmaxHyst shall not be included, if LCell::tCRmaxHyst = notUsed or
LCell::tCRmax = notUsed.
If HCS is enabled (enableHCS set to True), the BSR will broadcast following
parameters in the SIB11 message:
• qHCSn: Specifies the quality threshold levels for applying prioritised
hierarchical cell re-selection for neighbour cells with a certain HCS priority
level.
• penaltyTime: Specifies the duration for which the TEMP_OFFSET is
applied for neighbor cells with a certain HCS priority level.
• tempOffset1: Used to favor neighbor cells with a certain HCS priority level
over another in case of Rx level measurements for the duration of the
penalty time.
• tempOffset2: Specifies the quality threshold levels for applying prioritised
hierarchical cell re-selection for neighbour cells with a certain HCS priority
level.
• qOffset1: This specifies the offset between the serving BSR and the
neighbor cells for a certain HCS priority level. It is used in case the quality
measure for cell selection and re-selection is set to CPICH RSCP and for
first cell ranking.
• qOffset2: This specifies the offset between the serving BSR and the
neighbor cells for a certain HCS priority level. It is used in case the quality
measure for cell selection and re-selection is set to CPICH Ec/No.

Parameter qHCSn
Object Lcell::HcsCellRsInfo
Granularity HcsCellRsInfo
[0…99]
Class Class 3
Value 30
Parameter penaltyTime
{NotUsed,t10,t20,t30,t40,t50,t60}
Class Class 3
Value t20
Parameter tempOffset1
{offset3=3,offset6=6,offset9=9,offset12=12,offset15=1
5,offset18=18,offset21=21,offsetInfinite=9999}
Class Class 3
Value offset9
Parameter tempOffset2
{offset2=2,offset3=3,offset4=4,offset6=6,offset8=8,offs
et10=10,offset12=12,offsetInfinite=9999}
Class Class 3
Value offset6
Parameter qOffset1
[-50…50]
Class Class 3
Value 0

Parameter qOffset2
[-50…50]
Class Class 3
Value 0
Note: In a macro network these parameters are configurable per neighbour cell.
In the BSR network, the neighbour cells are determined during runtime and the
operator cannot configure the HCS parameters for individual neighbours in
advance.
Therefore the 3G network listening function will retrieve the HCS priority from the
system information broadcast in the detected UMTS macro neighbour cells as
described in 3.1.3.
The other HCS parameters will be configurable per HCS priority.
FMS: Setting the parameters for the different priorities
Under the LCell::HcsCellRsInfo, it is possible to define the different parameters for each priority.
The priorities correspond to the index (from 1 to 8) of the structure minored of 1 (e.g. Prio 0 will be
entered in index 1).

If HCS is disabled, the BSR shall support the broadcast of the following non-HCS
parameters in SIB 3:
• nonHCStCRmax: This parameter specifies the duration for evaluating

allowed amount of cell reselection(s) in case of non-HCS usage.
• nonHCSnCR: This parameter specifies the maximum number of cell
reselections in case of non-HCS usage.
• nonHCStCRmaxHyst: This parameter specifies the additional time period
before the UE can revert to low mobility measurements in case of non-
HCS usage.
Parameter nonHCStCRmax
Object Lcell
{notUsed=0,t30=30,t60=60,t120=120,t180=180,t240=2
40}
Class Class 3
Value notUsed
Parameter nonHCSnCR
Object Lcell
[1…16]
Class Class 3
Value 8
Parameter nonHCStCRmaxHyst
Object Lcell
{NotUsed,t10,t20,t30,t40,t50,t60,t70}
Class Class 3
Value t20

3.1.2 EQUIVALENT PUBLIC LAND MOBILE NETWORK (EPLMN)
Each operator is allocated one or a number of PLMN IDs per country in which they
operate. The PLMN ID consists of the Mobile Network Code (MNC) and the Mobile
Country Code (MCC).
The BSR is associated with one of the operator’s PLMN IDs and this will be
configured. The BSR can be on the same PLMN as the Macro or on a PLMN only
associated with the BSR network.
The operator may wish to operate the BSR network on a different PLMN than their
Macro network. Alternatively, BSR may be installed in areas of other operator’s
PLMN with roaming relationship.
The ePLMN feature ensures that the operator has maximum flexibility when
designing the BSR network in association with their macro network and enables
the operator to work in partnership with other operators.
The activation of the ePLMN feature, is done setting the parameter

enableUMTSePLMN to TRUE.
The different PLMN that are to be considered are then entered, as MCC and MNC,
through the structure umtsMacroEPLMN.
Parameter enableUMTSePLMN
Object Lcell
{True, False}
Class Class 3
Value TRUE
Parameter MNC
Object Lcell::umtsMacroEPLMN
Granularity umtsMacroEPLMN
[Maxlength 3]
Class Class 3
Value -

Parameter MCC
Object Lcell::umtsMacroEPLMN
Granularity umtsMacroEPLMN
[Maxlength 3]
Class Class 3
Value -
Rule: umtsMacroEPLMN
The maximum number of ePLMN that can be implemented is equal to 15
Engineering Recommendation: umtsMacroEPLMN

The autoconfiguration and self-optimisation time during power-on maybe slightly impacted if the list
of PLMN to search is large.
As an example, each PLMN configured may add an extra 50sec to the GSM search time and each
UMTS frequency configured up to 2minutes per frequency. Therefore the ePLMN and frequency
list supported should be kept as short as possible.
In the case the operator own PLMN needs to have a higher ranking that other
PLMN in the macro cell list for handovers, the flag enableOwnPLMNHighPriority
is to be set to TRUE.
This will also result in the only broadcast of neighbour cells with the own PLMN for
Cell Reselection if present. If no Macro cell with the own PLMN is detected,
ePLMN neighbours will be broadcasted in the SIB11.
Parameter enableOwnPLMNHighPriority
Object Lcell
{True, False}
Class Class 3
Value TRUE
The flag prioritizeOwnPLMNoverRAT is used to prioritize the operator’s own

PLMN over other radio access technology in case a preferred target radio access
technology (GSM or UMTS) is configured for macro cell handover.

Parameter prioritizeOwnPLMNoverRAT
Object Lcell
{True, False}
Class Class 3
Value FALSE

3.1.3 3G MACRO NEIGHBOURHOOD
3.1.3.1 NEIGHBOURLIST PARAMETERS

Auto-configuration aims at generating an initial 3G Macro neighbouring cell list by
scanning and measuring pre-defined 3G Macro cells or frequencies which are
provided to BSR at switch-on.
• FDDExtCell object first provides pre-defined 3G Macro cells, identified by

its instance (mCC.mNC.rncId.cellId) and:
o fddFreqBand, dlFrequencyNumber and ulFrequencyNumber

o locationAreaCode, routingAreaCode and
o primaryScramblingCode, primaryCPICHPower
o notAllowedCell, hcsPrioN
• MacroUmtsCellFrequencyList object may provide a list of UMTS

frequencies that can be scanned in case no FDDExtCell is declared or
BSR does not manage to get enough eligible 3G Macro cells (cf. next
paragraphs):
o freqBand, uARFCNDL / uARFCNUL are the parameters to be set

Note: The list of FDDExtCell provided by FMS should be automatically derived
from the exhaustive list of 3G Macro cells and the geographical coordinates of the
BSR. In the case this list is not populated, the BSR will generate one based on the
MacroUmtsCellFrequencyList using the sniffer.
Rule: MacroUmtsCellFrequencyList
The maximum number of frequencies that can be defined through MacroUmtsCellFrequencyList

Up is equal to 10.
Rule: MacroUmtsCellFrequencyList – Interaction with Feature 100889 Service Based

Redirection and Handover (see [Vol. 4])
The Feature 100889 Service Based Redirection and Handover requires the identification of 3G
Neighbours that will be used for Handover.
This implies that the Frequency Band and Frequencies of the Macro Layer targeted for Feature
100889 are defined to be scanned during the auto-configuration and self-optimisation.

FMS: notAllowedfddCellIdList
The Neighbourlist for a BSR can be entered manually by populating the Femto::fddCellIdList for
allowed Cells and the Femto::notAllowedfddCellIdList for the not Allowed ones.
The parameter useForMobility determines whether the manually configured cell is

to be used for mobility even when not detected by the BSR, and has the following
settings :
1. ifDetected - Include in Cell Reselection and HO Candidates only when
detected by the Femto
2. alwaysForReselect - Always broadcast as a reselection neighbour,

include as a HO target only when detected
3. alwaysForReselectAndHoPrioHigh - Always broadcast as a reselection
neighbour, and always include as a the top priority HO target.
4. alwaysForReselectAndHoPrioLow - Always broadcast as a reselection
neighbour, and always include as a HO target as lower priority than
detected cells.
5. notAllowed - Exclude from reselection and exclude from HO candidates
Rule: useForMobility and notAllowedCell dependency
If notAllowedCell=TRUE, then useForMobility::notAllowed is selected.
The settings of alwaysForReselectAndHoPrioHigh and

alwaysForReselectAndHoPrioLow mean that the manually configured neighbour
may be a handover target i.e. it will be included in ‘blindHO3GList’. The two
settings impact where in the list the HO target will appear:
¾ alwaysForReselectAndHoPrioHigh will place the neighbour to the top of
‘blindHO3GList’.
¾ alwaysForReselectAndHoPrioLow will place the neighbour to the bottom of

The strongest cell selection from umtsMacroNCell only depends on the setting of
umtsPreferredBand (i.e. even if the Dual Band feature is deactivated). If the
selection criterion indicates to choose a cell from the detected list
umtsMacroNCell then the cell chosen depend on umtsPreferredBand:
o If umtsPreferredBand is configured with an umts band, then the
strongest suitable detected cell is chosen in that band. If there is no
suitable cell, the strongest suitable cell is chosen ignoring the band.
o If umtsPreferredBand (i.e. ‘noBand’), the strongest suitable cell from
umtsMacroNCell is chosen ignoring the band.

Parameter umtsPreferredBand
Object LCELL
Class Class 3
Value -
For the FDDExtCell

Parameter mobileCountryCode | mCC
Object FddExtCell
Granularity MacroCells | FddExtCell
[Maxlength 3]
Class Class 3
Value Operator Specific
Parameter mobileNetworkCode | mNC

Object FddExtCell
[Maxlength 3]
Class Class 3
Parameter cellId | cellIdentity

Object FddExtCell
[0…4095]
Class Class 3
Parameter rNCID
Object FddExtCell
Granularity MacroCells
[0…4095]
Class Class 3

Parameter fddFreqBand |
Object FddExtCell
Class Class 3
Restriction: Frequency Band
BSRs support either the UMTS fdd2100 (Band 1) [3GPP_R08] or the UMTS 850/1900 (Band 2/Band 5)
band.
Parameter ulFrequencyNumber | uARFCN

Object FddExtCell
[0…16383]
Class Class 3
Parameter dlFrequencyNumber | uARFCNDownlink

Object FddExtCell
[0…16383]
Class Class 3
Parameter locationAreaCode | lAC

Object FddExtCell
[0…65535]
Class Class 3
Parameter routingAreaCode | rAC

Object FddExtCell
[0…255]
Class Class 3

Parameter primaryScramblingCode | primaryCPICHInfo
Object FddExtCell
[0…511]
Class Class 3
Parameter pcpichPower | primaryCPICHTxPower

Object FddExtCell
[-10,-9.9…50]
Class Class 3
Parameter - | notAllowedCell
Object - | FddExtCell
Granularity - | BSR
{True, False}
Class Class 3
Value False
Parameter hcsPrioN |
Object FddExtCell
[0…7]
Class Class 3
Value 0
Parameter useForMobility |
Object FddExtCell
{ifDetected=0,
alwaysForReselect=1,
alwaysForReselectAndHoPrioHigh=2,
alwaysForReselectAndHoPrioLow=3,
notAllowed=4}
Class Class 3
Value ifDetected
Notes:
• HCS priority level 0 = lowest priority,

• HCS priority level 7 = highest priority.
• hcsPrioN > 7 indicates that no HCS priority is assigned to the neighbor
cell.
For the LCell::MacroUmtsCellFrequencyList
Parameter freqBand
Object Lcell::MacroUMTSCellFrequencyList
Granularity MacroUMTSCellFrequencyList
Class Class 3
Parameter uARFCNDL
[0…16383]
Class Class 3
Parameter uARFCNUL
[0…16383]
Class Class 3
3.1.3.2 NEIGHBOUR ELIGIBILITY

A neighbouring 3G Macro cell is considered as eligible to be broadcasted into
SIB11
• if its PLMN belongs to the own BSR PLMN or the umtsMacroEPLMN List
• and if its measured CPICH RSCP or CPICH EcNo level is above a certain
threshold.
• macroCellMeasurementQuantity defines the measurement quantity

(either CPICH RSCP or CPICH EcNo) that is used for the eligibility of a
measured 3G Macro cell.

Parameter macroCellMeasurementQuantity
Object Lcell
Range & Unit Enum
{ecNO, rSCP}
Class Class 3
Value rSCP
• minUMTSDetectThresholdRSCP defines the threshold applied to CPICH

RSCP above which a measured 3G Macro cell is considered as eligible
when macroCellMeasurementQuantity is set to rSCP.
Parameter minUMTSDetectThresholdRSCP
Object Lcell
[-116..-25]
Class Class 3
Value -115
• minUMTSDetectThresholdEcNo defines the threshold applied to CPICH

EcNo above which a measured 3G Macro cell is considered as eligible
when macroCellMeasurementQuantity is set to ecNO.
Parameter minUMTSDetectThresholdEcNo
Object Lcell
[-30..0]
Class Class 3
Value -24
3.1.3.3 NEIGHBOUR MEASUREMENTS

The Macro 3G measurements are performed by the BSR which switches to a “UE”
mode with receive-only capability and is able to decode the 3G neighbourhood
present in the best 3G Macro’s SIB11 to improve its self-learning.
• umtsNtwkListenEnableFlag enables the 3G Network listening feature

which means BSR is able to measure 3G Macro cells by itself.

Parameter umtsNtwkListenEnableFlag
Object BSR Profile
{True, False}
Class Class 3
Value TRUE
• umtsOpenSearchEnableFlag: allows the reading of the best neighbouring

cell’s SIB11 to improve the knowledge of BSR’s 3G neighbourhood.
Parameter umtsOpenSearchEnableFlag
Object BSR Profile
{True, False}
Class Class 3
Value TRUE
• macroCellListSIB11 defines the maximum number of 3G Macro

neighbouring cells to be broadcast in BSR’s SIB11.
Parameter macroCellListSIB11
Object Lcell
[1…32]
Class Class 3
Value 8
3.1.3.4 NEIGHBOUR LIST GENERATION

During the Auto-configuration and Selfoptimization, the BSR will go through
following steps to generate a neighbourlist that is inline with the BSR RF
environment.
The process is going through following steps:
1. In the case the FDDExtCell List is not empty, the BSR will decode the
BCH information and check the PLMN of the 3G cells against its own
PLMN. In the case enableUMTSePLMN is set to TRUE, the 3G neighbour
PLMN is additionally checked against the values in umtsMacroEPLMN.
2. In the case umtsOpenSearchEnableFlag is set to TRUE, the 3G

neighbours are sorted on RSCP Level.

Restriction: Autoconfiguration Duration
Setting umtsOpenSearchEnableFlag to True will extend the duration of the autoconfiguration /

self-optimization phases from one to two minutes per frequency that is to be scanned.
3. The BSR decodes the BCH of the strongest 3G cell and reads the SIB11 of
that cell.
4. The BSR measures 3G cells from that SIB11 which have not been
measured yet.
5. The BCH of measured cells is read and the PLMNs checked as in Step 1
and the 3G neighbours are sorted on RSCP Level.
6. In the case a new cell is identified as strongest neighbour, the BSR goes
back to Step 3.
7. The BSR will check the eligibility of the 3G cells against the Thresholds
defined in 3.1.3.2
8. In the case the number of neighbour is lower than macroCellListSIB11,
the BSR will start an open search of the Frequencies listed in
MacroUmtsCellFrequencyList.
9. In the case neighbours are found, the BSR will go back to Step 2.
10. The process ends when the number of neighbours is equal to
macroCellListSIB11 or all the Frequencies in
MacroUmtsCellFrequencyList have been scanned.
Parameter umtsMacroCellRsInfouseOfDetectedHcsPrio |
useOfDetectedHcsPrio
Object Lcell | umtsMacroCellRsInfo
{True, False}
Class Class 3
Value TRUE
In the case umtsMacroCellRsInfo::useOfDetectedHcsPrio is set to true, the

BSR, when decoding the BCH information of the strongest 3G Cells, obtains the
HCS Priority from the SIB3 and stores the value for the corresponding neighbour.
If the HCS Priority is not included in the SIB3 IE, but the 3G neighbour present in
the FddExtCell list, the BSR will store the FddExtCell ::hcsPrioN for the
corresponding neighbour.
In the case umtsMacroCellRsInfo::useOfDetectedHcsPrio is set to false and the
3G neighbour present in the FddExtCell list, the BSR will store the
FddExtCell::hcsPrioN for the corresponding neighbour.
Otherwise, the priority for the neighbour will remain unset (no priority).

3.1.4 GSM MACRO NEIGHBOURHOOD
3.1.4.1 GSM NEIGHBOURLIST PARAMETERS

Auto-configuration first aims at generating an initial GSM neighbouring cell list by
scanning and measuring pre-defined 2G Macro cells and possibly a frequency
range which are both provided to BSR at switch-on.
• GsmExtCell object providing pre-defined GSM Macro cells, identified by
mCC.mNC.lAC.cellId (i.e. cell global identifier) and:
o nCC, bCC
o gsmFrequBand and bCCHArfcn
o rAC, cellIdentity and notAllowedCell
• LCellGsmFrequencyList object providing a list with
o bandIndicator, BCCHARFCNStart and BCCHARFCNSize
These informations are to be provided in case:
o no GsmExtCell is declared or BSR does not manage to get
enough eligible GSM Macro cells (cf. next paragraphs)
o and allowedGSMOpenSearch is set to True.
Note: The list of GsmExtCell provided by FMS is derived from the exhaustive list
of GSM Macro cells and the geographical coordinates of the BSR.
Rule: umtsMacroEPLMN
The maximum number of frequencies that can be defined in the GsmFrequencyList is equal to 30
Rule: LCellGsmFrequencyList – Interaction with Feature 100889 Service Based Redirection

and Handover (see [Vol. 4])
The Feature 100889 Service Based Redirection and Handover requires the identification of 2G
Neighbours that will be used for Handover.
This implies that the GSM Band and Frequencies of the Macro Layer targeted for Feature 100889
are defined to be scanned during the auto-configuration and self-optimisation.
FMS: notAllowedgsmCellIdList
The Neighbourlist for a BSR can be entered manually by populating the Femto::gsmCellIdList for
allowed Cells and the Femto::notAllowedgsmCellIdList for the not Allowed ones.

The parameter useForMobility determines whether the manually configured cell is

to be used for mobility even when not detected by the BSR, and has the following
settings:
1. ifDetected - Include in Cell Reselection and HO Candidates only when
detected by the Femto
2. alwaysForReselect - Always broadcast as a reselection neighbour,
include as a HO target only when detected
3. alwaysForReselectAndHoPrioHigh - Always broadcast as a reselection
neighbour, and always include as a the top priority HO target.
4. alwaysForReselectAndHoPrioLow - Always broadcast as a reselection
neighbour, and always include as a HO target as lower priority than
detected cells.
5. notAllowed - Exclude from reselection and exclude from HO candidates
Rule: useForMobility and notAllowedCell dependency
If notAllowedCell=TRUE, then useForMobility::notAllowed is selected.
The settings of alwaysForReselectAndHoPrioHigh and

alwaysForReselectAndHoPrioLow mean that the manually configured neighbour
may be a handover target i.e. it will be included in ‘blindHO2GList’. The two
settings impact where in the list the HO target will appear:
¾ alwaysForReselectAndHoPrioHigh will place the neighbour to the top of
¾ alwaysForReselectAndHoPrioLow will place the neighbour to the bottom of ‘
The strongest cell selection from gsmMacroNCell only depends on the setting of
gsmPreferredBand. If the selection criterion indicates to choose a cell from the
detected list gsmMacroNCell then the cell chosen depends on the setting of
gsmPreferredBand:
• If gsmPreferredBand is configured with a gsm band, the strongest
suitable detected cell in that band is chosen. If there is no suitable cell in
that band, the strongest suitable cell is chosen ignoring the band.
• If gsmPreferredBand is not configured (i.e. ‘noBand’), the strongest
suitable detected cell is chosen ignoring the band.

Parameter gsmPreferredBand
Object LCELL
{gSM450=0, gSM480=1, gSM850=2, gSM900=3,
Class Class 3
Value -

For the GsmExtCell

Parameter mobileCountryCode | mCC
Object GSMExtCell
Granularity MacroCells | GSMExtCell
[Maxlength 3]
Class Class 3
Parameter mobileNetworkCode | mNC

Object GSMExtCell
[Maxlength 3]
Class Class 3
Parameter bCC |
Object GSMExtCell
[0…7]
Class Class 3
Parameter nCC |
Object GSMExtCell
[0…7]
Class Class 3
Parameter gsmFrequBand |
Object GSMExtCell
{gSM450=0, gSM480=1, gSM850=2, gSM900=3,
Class Class 3

Restriction: GSM bands
Current BSR Version only support following GSM bands ( [3GPP_R09]):

• P-GSM 900 (ARFCN 1 to 124 inclusive)
• E-GSM 900 (ARFCN 0 to 124 & 975 to 1023 inclusive)
• DCS 1800 (ARFCN 512 to 885 inclusive)
• GSM 850 (ARFCN 128 to 251 inclusive)
• PCS 1900 (ARFCN 512 to 810 inclusive)
Parameter bCCHArfcn |
Object GSMExtCell
[0…1023]
Class Class 3
Parameter locationAreaCode | lAC

Object GSMExtCell
[0…65535]
Class Class 3
Parameter rAC |
Object GSMExtCell
[0…255]
Class Class 3
Parameter cellIdentity |
Object GSMExtCell
[0…65535]
Class Class 3

Parameter - | notAllowedCell
Object - | GSMExtCell
Granularity - | BSR
{True, False}
Class Class 3
Value False
Parameter useForMobility |
Object GSMExtCell
{ifDetected=0,
alwaysForReselect=1,
alwaysForReselectAndHoPrioHigh=2,
alwaysForReselectAndHoPrioLow=3,
notAllowed=4}
Class Class 3
Value ifDetected
For the LCell::GsmFrequencyList
Parameter bandIndicator
Object Lcell::GsmFrequencyList
Granularity GsmFrequencyList
{gSM450=0, gSM480=1, gSM850=2, gSM900=3,
Class Class 3
Parameter bCCHARFCNstart
[0…1023]
Class Class 3

Parameter bCCHARFCNsize
[0…1023]
Class Class 3
3.1.4.2 NEIGHBOUR ELIGIBILITY

A neighbouring GSM cell is considered as eligible to be broadcast into BSR’s
SIB11
• If its PLMN belongs to the own BSR PLMN or the gsmMacroPLMN List (if
BSR::enableUMTSePLMN is true)
• If its measured RSSI level is above minGSMDetectThreshold threshold.
Parameter minGSMDetectThreshold
Object Lcell
[-110..-48]
Class Class 3
Value -104
Engineering Recommendation: gsmcellRSSIThreshold
minGSMDetectThreshold shall be set accordingly to gsmMacroCellRsInfo::QRxLevMin (cf.

section 3.4.4.2).

GSM measurements are performed using a 2G sniffer, named as HiLO Module,
embedded on the BSR in case 2G Network Listening feature is enabled (i.e.
gsmListeningMode set to Mode1 or Mode2).
The flag allowedGSMOpenSearch: when set to True, allows:

o to scan the BCCH ARFCN list provided by one or several
LCellGsmFrequencyList objects,
o to improve GSM neighbourhood knowledge by reading the best 3G
neighbouring cell’s SIB11 when umtsNtwkListenEnableFlag is
set to True (cf. section 3.1).

Parameter allowedGSMOpenSearch
Object Lcell
{True, False}
Class Class 3
Value TRUE
Note: with 2G Network Listening feature disabled, only the GSM target cells that
have been defined under GsmExtCell can be eligible to CS Blind Handover (cf.
section Error! Reference source not found.) as locationAreaCode and rAC,
needed for Relocation procedure, can not be dynamically retrieved by BSR.
The Parameter gsmListeningMode enables the 2G Network listening feature.

• When set to Mode0, 2G Network Listening feature is disabled.
• When set to Mode1, 2G Network Listening is run in simultaneous mode
with 3G transmission.
• When set to Mode2, 2G Network Listening is run without 3G transmission,
i.e. during non-busy period.
When gsmListeningMode is set to Mode1, the 2G measurements will take place

periodically using timer gsmListeningPeriodicTimer.
When gsmListeningMode is set to Mode2, the 2G measurements will take place
once a day during the “quiet hour”.
Parameter gsmListeningMode
Object GSMListener
Range & Unit Enum
{Mode0, Mode1, Mode2}
Class Class 3
Value Mode2
Parameter gsmListeningPeriodicTimer
Object GSMListener
Range & Unit Integer (minutes)
[0…10000]
Class Class 3
Value 1440 (1day)
gsmCellListSIB11 defines the maximum number of GSM Macro neighbouring

cells to be broadcast in BSR’s SIB11.

Parameter gsmCellListSIB11
Object Lcell
[1…32]
Class Class 3
Value 8

The process followed for the generation of the 2G neighbourlist steered through
the gsmExtCell list
If allowedGSMOpenSearch is FALSE then only the cells in gsmExtCell, not
marked as not allowed, are searched and included in the 2G neighbour list.
If the allowedGSMOpenSearch is enabled then the search is opened to all cells

fulfilling the PLMN criteria (operator PLMN and ePLMN entered in the
gsmMacroPLMN structure) and in the frequency bands specified
(gsmFrequencyList).
This search terminates when the 2G sniffer determines that the search is complete
(gsmCellListSIB11 found) or the timer gsmModuleInitGuardTimer expires for
each frequency band searched.
For gsmListeningMode set to Mode1, the neighbour cells are updated when
SIB11 is next broadcast.
For gsmListeningMode set to Mode2, SIB11 is broadcasted when the BSR cell is
enabled (at the end of the quiet period).
Parameter gsmModuleInitGuardTimer
Object GSMListener
[0…500]
Class Class 3
Value 60

Parameter mcc
Object GSMListener::gsmMacroPLMN
Granularity gsmMacroPLMN
[Maxlength 3]
Class Class 3
Value -
Parameter mnc
[Maxlength 3]
Class Class 3
Value -
Parameter ownPLMN
{True, False}
Class Class 3
Value False
3.1.5 BSR NEIGHBOURHOOD
3.1.5.1 NEIGHBOURLIST PARAMETERS

BSRs belonging to a BSR group are known objects within the BSR Cluster.
Therefore to identify it, only the BSRneighbourcell::bSRIdentity needs to be
obtained to define neighbour relations.
BSR neighbours can be of three types:

• Configured: manually configured from OAM
• Detected: detected by the BSR Sniffer
• Informed: not detected by the BSR sniffer, but detected by another BSR
and informed through inter-BSR signalling.
As an example, BSR A is informed of BSR B when BSR B sends the Neighbour

Cell information IE with measurements relating to BSR A.

Parameter bSRIdentity
Object Femto::BSRneighbourCell | BSRneighbourCell
Granularity Femto | BSRneighbourCell
[0…65534]
Class Class 3
Value -
3.1.5.2 INTER BSR COMMUNICATION

To activate BSR to BSR communication within a group of BSR,
activateFemtoToFemtoCommunications has to be set to TRUE.
When so, BSR will initiate an exchange with other BSR fulfilling following criteria:
• BSR is manually configured neighbours from BSRneighbourCell which
are a part of the same group
• BSR is detected as neighbours through the sniffer which are a part of the
same group when isAutoNeigbourCellDetectionEnabled=TRUE
Additionally, during the self-optimization, BSR will exchange data with:

• BSR from the same Group that were neighbours previously but which are
not detected by the sniffer and were not manually configured
(BSRneighbourCell), named as informed neighbours.
Note: In the case where isAutoNeigbourCellDetectionEnabled=FALSE and

BSRneighbourCell is empty, the BSR shall not attempt inter BSR communications
Rule: Inter-BSR communication
Inter-BSR communication is a perquisite for Inter-BSR Handovers. This means that if a BSR
cannot communicate to another one, there will be no handover between them. There might still be
cell reselection.
Parameter activateFemtoToFemtoCommunications
Object BSR Profile
{True, False}
Class Class 3
Value TRUE

Parameter isAutoNeigbourCellDetectionEnabled
Object BSR Profile
{True, False}
Class Class 3
Value TRUE

The measurements of the surrounding BSRs are performed by the 3G sniffer just
as it was for the case for the 3G cells (see chapter 3.1.3.3).
The difference is that the measurements will be stopped when all the PSC of the
femtoPSCList and femtoPSCListAdd have been scanned.
Parameter femtoPSC
Object femtoPSClistAdd
Granularity femtoPSClistAdd
[0…511]
Class Class 3
Value '
Rule: FemtoPSClistAdd
The PSCs defined in FemtoPSClistAdd must be different from the ones defined in the
FemtoPSClist.
Rule: FemtoPSClistAdd
Up to 16 additional PSCs can be defined through the parameter FemtoPSClistAdd

During the Auto-configuration and Selfoptimization, the BSR will go through
following steps to generate a neighbourlist that is inline with the BSR RF
environment.
1. The BSR will start scanning the PSCs that are present in the
femtoPSCList.

2. For each Femto cell found the Femto shall decode the BCH channel and
check the PLMN of the cells against its own PLMN.
In case the BSR is not part of a group

3. The neighbour and the decoded information are added to the BSR
neighbour cell list.
In case the BSR is part of a group

3. In the case the CellID can be decoded, the detected cell will be added if
not already present in the neighbour list.
4. In the case the CellID cannot be decoded, the detected cell will be added if
there is no other neighbour present in the neighbour list with the same
PSC.
5. In the case the BSRneighbourcell is not empty, the BSR will add the cell
and its information to the neighbour list.
6. The source BSR will finally initiate a communication to all the neighbours
(target) BSR fulfilling condition described in chapter 3.1.5.2 to inform them
that they were considered in its neighbourlist.
Note: Populating the BSRneighbourcell is a way to force an Inter BSR relation

even though the target BSR cannot be sniffed.
Additionally, the BSRs belonging to a group would add cells to their neighbourlist
following an incoming inter-BSR communication. This is done outside the
autoconfiguration / selfoptimization period.
For instance:
Let’s assume a BSR A is active for a long time and a BSR B is just activated.
BSR B will detect BSR A and communicate with it.
BSR B will inform BSR A of its presence so that BSR A can update its neighbourlist
in real time.
Restriction: Neighbourlist for Cell Reselection
The BSR neighbours transmitted in the SIB11 message (for Cell Reselection) will contain all the
PSC from the femtoPSCList, whether they are used or not.

3.1.5.5 DETERMINATION OF SFN OFFSET
With dense re-use of PSC, as depicted in Figure 2, it is still possible to have PSC
ambiguity even with neighbour-neighbour information being used when selecting
the PSC (See [Vol. 2]). This for instance occurs when more BSRs are deployed in
the group than PSCs available (in Figure 2, 7 BSRs are deployed but the PSC List
only allow to choose among 6 PSC)
In order to reduce possible neighbour ambiguity, the BSR will determine an offset
to a reference. This offset will be broadcasted to the surrounding neighbours.
Those will then be able to use this additional timing information to identify the right
target BSR that is reported by a UE in the Handover measurement report
message.
Femto 4 PSC3 Femto 5 PSC4
Femto 7 PSC1 Femto 1 PSC2 Femto 3 PSC1
Femto 6 PSC6 Femto 2 PSC5
Figure 2 –Scenario with Dense re-use PSC
The activation of this functionality is done by setting the parameter

enableTimingMeasurements = TRUE.

Parameter enableTimingMeasurements
Object BSR Profile
{True, False}
Class Class 3
Value FALSE
The offset is defined as the time offset that the BSR will take to cross
SFN (System Frame Number) Mod 25 = 0 after midnight UTC. [3GPP_R14]
provides some additional information on the procedure.
When this feature is activated, the BSR starts calibrating its clock very accurately.
The measurement is taking place via internal communication between BSR and its
RF chip using midnight as a reference time for the calculation. The operation is
repeated several times to reduce possible jitters. The expected time accuracy is
within 2ms and the maximum jitter around 2ms over 24 hours.
Once the offset is been measured, the BSR will broadcast it to its neighbours.
On reception of the information, the other BSR will be able to determine a relative
offset using their own offset.
This will then be used during the Handover procedure.
3.2. CELL RESERVATION AND ACCESS RESTRICTION

There are two mechanisms which allow an operator to impose cell reservations or
access restrictions using radio parameters:
• The first mechanism uses indication of cell status and special reservations
for control of cell selection and re-selection procedures.
• The second mechanism, referred to as Access Control, shall allow
preventing selected classes of users from sending initial access messages
for load control reasons. At subscription, one or more Access Classes are
allocated to the subscriber and stored in the USIM (UMTS Subscriber
Identity Module), which are employed for this purpose.
On top of the two mentioned radio access control, the BSR has implemented an
additional mechanism that will allow operators to limit the access through the used
of white lists of IMSI called Access Class Lists. This parameters are described in
chapter 3.2.3.

As described in [3GPP_R04], all UEs are members of one out of ten randomly
allocated mobile populations, defined as Access Classes 0 to 9. The population
number is stored in the SIM/USIM.
In addition, mobiles may be members of one or more out of 5 special categories
(Access Classes 11 to 15), also held in the SIM/USIM. These are allocated to
specific high priority users as follows. (The enumeration is not meant as a priority
sequence):
• Class 11 - For Operator Use
• Class 12 - Security Services
• Class 13 - Public Utilities (e.g. water/gas suppliers)
• Class 14 - Emergency Services
• Class 15 - PLMN Staff (VIP)
An additional control bit known as "Access Class 10" is also signaled over the air
interface to the UE. This indicates whether or not network access for Emergency
Calls is allowed for UEs with access classes 0 to 9 or without an IMSI.
3.2.1 CELL STATUS AND CELL RESERVATION

As specified by [3GPP_R01], cell status and cell reservations are indicated with
the Cell Access Restriction Information Element in the System Information
Message SIB3 by means of these IE:
• Cell barred (IE type: "barred" or "not barred"),
• Cell reserved for operator use (IE type: "reserved" or "not reserved"),
• Cell reserved for future extension (IE type: "reserved" or "not reserved").
Parameter sIB3CellBarred
Object Lcell
Range & Unit Enum
{barred, notbarred}
Class Class 3
Value notbarred
Parameter sIB3CellResForOperatorUse
Object Lcell
Range & Unit Enum
{reserved, notreserved}
Class Class 3
Value notreserved

Parameter sIB3CellResExtension
Object Lcell
Range & Unit Enum
{reserved, notreserved}
Class Class 3
Value notreserved
Refer to [3GPP_R01] for details on Cell Reservation.
3.2.2 ACCESS CLASS BARRING

Under certain circumstances, operators may want to prevent a selected group of
UE from making any access attempts or responding to pages in specified areas of
a PLMN.
System Information Block type 3 (SIB 3) transmits "Cell Access Restriction" IE
which itself contains another IE called "Access Class Barred list". This list includes
the UE Access Class for which the cell has to be considered as barred.
When sIB3AccClassBarred::Ac0 is set to True, the UEs that are defined with
Access Class 0 are only allowed to initiate Emergency call on this cell.
FMS: Access Class
One parameter is defined at FMS for each Access Class, i.e. 16 parameters, from
sIB3AccClassBarred::Ac0 to sIB3AccClassBarred::Ac15.
Parameter sIB3AccClassBarredAc0 | AC[1 to 15]

Object Lcell | Lcell::sIB3AccClassBarred
Granularity BSR Profile | sIB3AccClassBarred
{True, False}
Class Class 3
Value FALSE
Refer to [3GPP_R01] for details on Cell Access Control.
3.2.3 ACCESS CONTROL

The BSR offers an additional access control at IMSI (e.g. user) level.

3.2.3.1 CLOSED ACCESS MODE
When accessMode = closedAccess, the BSR will operate in Closed Access Mode.
This Mode relies on two list of IMSI that are allowed to access the BSR.
• femtoACLlist: This specifies the list of users permitted to use BSR
resources as owner, within closed access operation mode.
• femtoACLlistGuest: This specifies the list of users permitted to use BSR
resources as guest within closed access operation mode.
The use of the 2 lists allows to grant guest access to a BSR with a different tariff
than the BSR owner.
Other IMSI trying to register in the BSR will be rejected while performing the
LAU/RAU.
In the case the UE is not allowed to register to any other BSR using the same LA,
the UE will be rejected with the cause configured through the parameter
publicUserRejectCause. The UE will store the Location Area in its list of forbidden
LAs and will not further try to access any BSRs of this Location Area. Table 1
provides with typical reject causes ( [3GPP_R05]). In the case a value out of the
listed ones is used, the BSR will use the cause #15 “no suitable cells in location
area”.
In the case the UE is allowed to register to another BSR using the same LAC,
Authentication Failure messages will be exchanged between BSR and UE. As a
result, the UE will enter IDLE mode and considers the cell as barred for 1280s.
Note: Emergency calls are still possible in the case the BSR is the only available
wireless network.
Parameter accessMode
Object Femto | BSR
{closedAccess, openAccess,semiOpenAccess}
Class Class 0
Value closedAccess

Parameter femtoACLlist
Object Femto
Granularity Femto
{xx, yy, zz}
Class Class 3
Value -
Parameter femtoACLlistGuest
Object Femto
Granularity Femto
{xx, yy, zz}
Class Class 3
Value -
Rule: femtoACLlist and femtoACLlistGuest
The total number of IMSI that can be provisioned through the different lists is
¾ 32 in the case of an isolated femto
¾ 256 in the case of a group of femtos
Rule: femtoACLlistGuest
In the case more IMSIs than the maximum are provided, the BSR will delete IMSIs from the
femtoACLlistGuest until 256 is reached.
Parameter publicUserRejectCause
Object BSR Profile
[0..256]
Class Class 3
Value 13
Cause value Reason

11 PLMN not allowed
12 Location Area not allowed
13 Roaming not allowed in this location area

15 No Suitable Cells In Location Area
Table 1 - 3GPP specific cause values for mobility management ( [3GPP_R05])
3.2.3.2 OPEN ACCESS MODE

When accessMode = openAccess, the BSR will operate in Open Access Mode.
In this case, the BSR does not perform access control (based on IMSI).
3.2.3.3 SEMI-OPEN ACCESS MODE

When accessMode = semiOpenAccess, the BSR may give service to all users in
the vicinity while still permitting a priority service to be provided to the BSR Owner
and Guests.
For Operators this feature will widen the Femto market. It allows them to extend or
improve the coverage of the macro network without having to, for example, add
new sites and deal with the associated planning permission and site acquisition
issues. The feature is mainly aimed at improving service in public places like shops
and enterprises.
The prioritized open access BSR does not perform access control. The ACL
(Access Control List) is only used to determine the priority of users. A user is
prioritized if the IMSI of the user is contained in the ACL of owners or of guests. In
order to give this priority to preferred users the BSR Femto may need to redirect
existing calls to the macro using the ACR (Active Call Redirect) feature, or pre-
empt existing PS calls or perform DBC of existing PS calls as decribed in [Vol. 4].
This is necessary as the BSR Femto only has a limited call capacity.
The prioritized open access BSR supports also differentiated billing for public
users, owners and guests as described in [Vol. 2].
When accessMode = semiOpenAccess, the BSR will determine the type of the
user using the IMSI as follows and it sill store it in the UE context for the duration of
the RRC connection:
¾ Public user, if the IMSI is not listed in any ACL.
¾ Guest user, if the IMSI is listed in the Guest ACL.
¾ Owner user, if the IMSI is listed in the Owner ACL.

The prioritized open access BSR is a combination of the open and closed access
BSR with respect of UE tracking. The former UE tracking principles of both types of
BSRs are also applied for the prioritized open access BSR.
The BSG identifies BSRs based on IMSI entries in the ACLs and in the IMSI
Directory. If an user is contained in the ACL of the prioritized open access BSR (=
private user), the user will not be registered in the IMSI Directory of the BSR. If the
user is not in the ACL (= public user), the BSR will send a UE Registration
message to the BSG´s IMSI Directory and apply the UE registration mechanisms
as supported by open access BSRs.
The BSG always checks both the ACL and the IMSI Directory, when a UE must be
paged.

3.3. CELL SELECTION

When an UE is switched on or following a recovery from lack of coverage, the UE
shall select a PLMN. Once the UE has selected the PLMN, the cell selection
procedure is performed in order to select a suitable cell of that PLMN to camp on.
Cells can be classified into 2 different criteria as following:

• Acceptable Cell: a cell that satisfies the following condition:
o The cell is not barred;
o The cell selection criteria are fulfilled
o A UE can always attempt emergency calls on an acceptable cell.
• Suitable Cell: a cell on which an UE may camp. It shall satisfy certain
conditions:
o The cell is part of the selected or equivalent PLMN
o The cell is not barred.
o The cell is not part of the list of "forbidden LAs for regional
provision of service"
o The cell selection criteria are fulfilled
Squal and Srxlev are the two quantities used for cell selection criteria, defined as
follows:
• Squal = Qqualmeas - qQualMin
• Srxlev = Qrxlevmeas - qRxLevMin - Pcompensation
where:
• Qqualmeas is the measured CPICH Ec/Io
• Qrxlevmeas is the measured CPICH RSCP
• Pcompensation = max (maximumAllowedUlTxPower - P_MAX, 0)
• P_MAX = maximum UE output power (dBm) according to its power class.

Power (dBm)
Operating Band
Class 1 Class 2 Class 3 Class 4
I UMTS 2100 MHz +33 +27 +24 +21
II UMTS 1900 MHz N.A. N.A. +24 +21
V UMTS 850 MHz N.A. N.A. +24 +21
VI UMTS 850 MHz N.A. N.A. +24 +21
VIII UMTS 900 MHz N.A. N.A. +24 +21
Table 2 - UE power Class vs. maximum output power
Parameter qQualMin
Object Lcell
[-24...0]
Class Class 3
Value -19
Parameter qRxLevMin
Object Lcell
[-115..-25] step 2
Class Class 3
Value -111
Parameter maximumAllowedULTXPower
Object Lcell
[-50…33]
Class Class 3
Value 10
The cell selection criteria are fulfilled when:
Squal > 0 AND Srxlev > 0

i.e.
Qqualmeas > qQualMin AND Qrxlevmeas > qRxLevMin + Pcompensation
i.e.
CPICH_Ec/No > qQualMin AND CPICH_RSCP > qRxLevMin + Pcompensation

If the criteria are fulfilled, the UE moves to the camped normally state where the
following tasks will be performed:
• Select and monitor the indicated PICH and PCH.
• Monitor relevant System Information.
• Perform measurements for the cell reselection evaluation procedure.
• Execute the cell reselection evaluation process.
If the criteria are NOT fulfilled, the UE will attempt to camp on the strongest cell of
any PLMN and enter in the camped on any cell state where it can only obtain
limited service (emergency calls). The following tasks will be performed in the
camped on any cell state:
• Monitor relevant System Information,
• Perform measurements for the cell reselection evaluation procedure,
• Execute the cell reselection evaluation process,
• The UE will regularly attempt to find a suitable cell trying all radio access
technologies that are supported by the UE. If a suitable cell is found, the
cell selection process restarts.
3.4. CELL RESELECTION

This section defines the cell reselection procedure relying on the classical cell
reselection algorithm or if activated on HCS as defined per [3GPP_R01] and
explained hereafter.
When camped on a cell, the UE regularly searches for a better cell according to the
cell reselection criteria. If a better cell is found, that cell is selected. Depending on
the information broadcast by the network, the mobile may select a cell from:
• The same FDD frequency,
• Another FDD frequency,
• Another system (e.g. GSM), applicable only to GSM radio access
technology.
3.4.1 HIGH MOBILITY DETECTION ALGORITHM (HMD)

HMD is defined using 3 different parameters: tCrMax, nCr and tCrMaxHyst (either
with or without HCS).

The definition of speed is given through following measurements:

• UE enters high-mobility state when the number of cell reselection during
time period tCrMax exceeds nCr.
• UE leaves high-mobility state or enters low mobility when the number of
cell reselection does not exceed anymore nCr during time period
tCrMax+tCrMaxHyst.
Rule: HMD
To determine whether HMD is to use or not, the parameters to be considered in the case HCS is
enabled or disabled are following,
HCS Used HCS not Used
tCrMax LCell::tCrMax LCell::nonHCStCRmax
nCr LCell::nCr LCell::nonHCSnCR
tCrMaxHyst LCell::tCrMaxHyst LCell::nonHCStCRmaxHyst
Engineering Recommendation: tCrMax
To deactivate the HMD algorithm, tCrMax is to be set to ‘not used’
Engineering Recommendation: tCrMax and nCr parameters

When using HMD, tCrMax and nCr must be set accordingly to the cell size and the speed above
which UE is supposed to be in high-mobility state.
As an example, in a dense urban environment, the size of UMTS cell is about 1.5 km (in-car) and
high-speed limit can be set to 90 km/h, which means that UE performs Cell Reselection every 60s.
Therefore, operator can set nCr to 2 and tCrMax to 120.
Restriction: HMD at BSR Level only in Group
Inter-BSR Cell reselection is only possible in the case of BSR Groups. Therefore, HMD can only be
used within the BSR Layer within a Group of BSR.
Configured at Macro Level, HMD can be used to force UEs into Standalone or Group BSR.

3.4.2 CELL RESELECTION MEASUREMENT RULES WITHOUT
HCS
In the case enableHCS is set to FALSE, the cell reselection is processed in the
classical way as presented hereafter.
Following parameters are broadcast in SIB3 and SIB11 for cell

selection/reselection parameters related to the serving cell
o qQualMin
o qRxLevMin
o maximumAllowedULTXPower
o sIntraSearch
o sInterSearch
o sSearchRAT
o sHCSRAT
o sSearchHCS
o sIB3CrQualityMeasure
o sib3qHyst1s
o sib3qHyst2s
o sIB3InterRATScalingFactor
o sIB3InterFreqScalingFactor
o sIB3TReselection
• SIB11 for cell reselection parameters related to the neighbouring cells
o umtsMacroCellRsInfo::qQualMin
o umtsMacroCellRsInfo::qRxLevMin
o umtsMacroCellRsInfo::.qOffset1s
o umtsMacroCellRsInfo::qOffset2s
o umtsMacroCellRsInfo::maxAllowedULTXPwr
o gsmMacroCellRsInfo::qRxLevMin
o gsmMacroCellRsInfo::qOffset1s
o gsmMacroCellRsInfo::maxAllowedULTXPwr
Squal and possibly Srxlev of the BSR serving cell is compared to different
threshold broadcasted in the System Information to determine which kind of
measurement (intra-frequency, inter-frequency and inter-RAT) the UE shall do.

In order to limit the time during which the mobile performs measurements on
UMTS and GSM neighbouring cells, criteria for neighbour cells tracking and
measurements are applied.
3.4.2.1 INTRA-FREQUENCY MEASUREMENTS

Squal is compared with the parameter sIntraSearch:
• If Squal > sIntraSearch, the UE does not perform intra-frequency
measurements.
• If Squal ≤ sIntraSearch, the UE performs intra-frequency measurements.
• If sIntraSearch is not sent for the serving cell, the UE performs intra-
frequency measurements.
3.4.2.2 INTER-FREQUENCY MEASUREMENTS

Squal is compared with the parameter sInterSearch:
• If Squal > sInterSearch, the UE does not perform inter-frequency
measurements.
• If Squal ≤ sInterSearch, the UE performs inter-frequency measurements.
• If sInterSearch is not sent for the serving cell, the UE performs inter-
BSR also makes use of the optional parameter sSearchHCS which is a threshold
to be compared with Srxlev in order to define Inter-frequency measurements.
Refer to Figure 3 to get a view on measurement decision based on Squal and
Srxlev.
3.4.2.3 INTER-RAT MEASUREMENTS

Squal is compared with the parameter sSearchRAT:
• If Squal > sSearchRAT, the UE does not perform measurements on GSM
cells.
• If Squal ≤ sSearchRAT, the UE performs measurements on GSM cells.
• If sSearchRAT is not sent for the serving cell, the UE performs
measurements on GSM cells.
BSR also makes use of the optional parameter sHCSRAT which is a threshold to
be compared with Srxlev in order to define GSM measurements.

• If sHCSRAT is not sent, GSM measurement is only defined by comparing
Squal and sSearchRAT (cf. above conditions)
• If sHCSRAT is sent, refer to Figure 3 to get a view on GSM measurement
decision based on Squal and Srxlev.
3.4.2.4 MEASUREMENT TRIGGERS PARAMETERS

The following tables present the parameters used by the UE to decide whether or
not to perform intra-frequency, inter-frequency or inter-rat measurements.
Parameter sIntraSearch
Object Lcell
[-32..20] step 2
Class Class 3
Value 2
Note: If a negative value is datafilled and sent in SIB3, the UE shall consider the
value to be 0 (see [3GPP_R02]).
Parameter sInterSearch
Object Lcell
[-32..20] step 2
Class Class 3
Value 2
Note: If a negative value is datafilled and sent in SIB3, the UE shall consider the
Parameter sSearchRAT
Object Lcell
[-32..20] step 2
Class Class 3
Value 2
Notes:
• If a negative value is datafilled and sent in SIB3, the UE shall consider the

• In case the value 20 is received, the UE shall consider this IE as if it was
absent (see [3GPP_R01] and [3GPP_R02]).
Parameter sSearchHCS
Object Lcell
[-1..91] step 2
Class Class 3
Value -1
Notes:
• Provisioning of a negative value disables the RSCP triggered inter-
Parameter sHCSRAT
Object Lcell
[-1..91] step 2
Class Class 3
Value -1 (i.e. not broadcast)
Notes:
• Provisioning of a negative value disables the RCSP triggered GSM
measurements.
Figure 3 depicts the decision for selecting Intra-frequency, Inter-frequency or GSM

measurements based on the different thresholds presented before and Squal and
Srxlev levels of the FDD cell selected by UE.
Srxlev
Intra-frequency No measurement
sSearchHCS
Intra-frequency
Inter-frequency
Inter-frequency
sHCSRAT
Intra-frequency
Inter-frequency Inter-frequency
GSM GSM
sSearchRAT sInterSearch sIntraSearch Squal
Figure 3 - Decision thresholds for Measurement

Engineering Recommendation: Squal is relative to Qqualmin
As Squal = Qqualmeas – Qualmin and Srxlev = Qrxlevmeas – Qrxlevmin, Figure 3 can be

translated into a decision chart based on Qqualmeas and Qrxlevmeas.
Rule: UE measurements
In the case sIntraSearch and sIntraSearch are not transmitted in the SIB messages, the UE should
always perform the corresponding measurements.
3.4.3 CELL RESELECTION MEASUREMENT RULES WITH HCS

With enableHCS set to True, cell reselection makes use of 2 independent
concepts to define which neighbour cells UE shall measure:
• HMD algorithm which allows UE to detect whether it is in high-mobility
state or not.
• HCS priority (between 0 and 7) defined per serving and neighbouring cell,
respectively broadcast in SIB3/4 and SIB11/12. HCS priority 0 means
lowest priority and 7 means highest priority.
3.4.3.1 HCS PRIORITY

HCS priorities are broadcast in SIB3 for the serving cell and SIB11 for the
neighboring cells. 3GPP defines that a cell with hcsPriority=7 has higher priority
than another cell with hcsPriority=0. Actually, one shall consider HCS priority in
conjunction with HMD and opertor’s strategy, as depicted in Figure 4:
• When high-mobility state is detected, UE will try and reselect a cell with
lower HCS priority
• When high-mobility state is NOT detected, UE will try and reselect a cell
with higher HCS priority
Therefore, it is better to consider that 2 cells may have equal or different HCS
priorities. HCS rules regarding priorities and HMD are presented in the following
sections.
The Cell reselection parameters can be defined for each of the layers supported by
the BSR. This allows to control the UE´s cell reselection behaviour between the
layers and to prioritize layers.
For the Serving BSR the priority is given through LCell::hcsPrioS (see chapter
3.1.1)
For the 3G Macro Neighbours, the priority is obtained from the configured or
sniffed cells ( 3.1.3.1).

Indeed the BSR will determine its neighbour cells during the auto-configuration /
Selfoptimization phase. It will then get the corresponding priority at that time for
each found neighbour through the network listening function. This will retrieve the
HCS priority from the system information broadcast in the detected UMTS macro
neighbour cells as described in 3.1.3.
In the case the configured or sniffed priority is out of the range [0..7], the femto will
use the value configured through the parameter
umtsMacroCellRsInfo::hcsPrioN.
For the GSM and BSR neighbours, the priority is given through the parameters
gsmMacroCellRsInfo::hcsPrioN and InterBSRCellRsInfo::hcsPrioN
• InterBSRCellRsInfo::hcsPrioN for BSR neighbours

• umtsMacroCellRsInfo::hcsPrioN for 3G neighbours
• gsmMacroCellRsInfo::hcsPrioN for GSM neighbours
The other HCS parameters will be configurable per HCS priority.
Parameter interBSRCellRsInfohcsPrioN | hcsPrioN

Object Lcell | interBSRCellRsInfo
[0…7]
Class Class 3
Value 7
Parameter umtsMacroCellRsInfohcsPrioN | hcsPrioN

[0…7]
Class Class 3
Value 0
Parameter gsmMacroCellRsInfohcsPrioN | hcsPrioN

Object Lcell | gsmMacroCellRsInfo
[0…7]
Class Class 3
Value 0

HM detected HM not detected

Lower priority is favored Higher priority is favored
P3 P3 P3 P3
Copyright © 1996 Northern Telecom

P2 P2
P1
Figure 4 - HCS Priority and HMD
3.4.3.2 NEIGHBOURING MEASUREMENT RULES

When HCS is used, measurement rules are based on the same thresholds as
when HCS is not used, cf. chapter 3.4.2 (sIntraSearch, sInterSearch,
sSearchRat, sSearchHcs and sHcsRat) plus a new parameter,
sLimitSearchRat, broadcast in SIB3.
3.4.3.2.1 HIGH-MOBILITY STATE NOT DETECTED

Figure 5 depicts the neighbouring measurement rules when high-mobility state is
NOT detected; two different graphs are presented, one for FDD neighbouring cells,
another for GSM neighbouring cells, in order to ease the understanding. However,
both graphs are applicable simultaneously.

Srxlev
Intra-frequency Intra-frequency
Inter-frequency Inter-frequency
hcsPrion >= hcsPrios hcsPrion > hcsPrios
sSearchHcs
All Intra-frequency
All Inter-frequency
sInterSearch sIntraSearch Squal
Srxlev
GSM
No measurement
hcsPrion >= hcsPrios
sHcsRat
All GSM
sSearchRat sLimitSearchRat
Squal
Figure 5 - Decision thresholds for Measurement when high-mobility is NOT detected
Engineering Recommendation: Squal is relative to Qqualmin
As Squal = Qqualmeas – Qualmin and Srxlev = Qrxlevmeas – Qrxlevmin, Figure 5 can be

translated into a decision chart based on Qqualmeas and Qrxlevmeas.
The following example aims at explaining how both figures must be understood:
In case, the above conditions are fulfilled (i.e. pink square and blue square)
• sInterSearch < Squal < sIntraSearch
• Srxlev > sSearchHcs
AND
• Squal > sLimitSearchRat
• Srxlev > sHcsRatGsm
UE is supposed to measure Intra- and Inter-frequency neighbouring cells whose
priority is higher than or equal to serving cell’s priority; UE is not supposed to
measure GSM neighbouring cells.
3.4.3.2.2 HIGH-MOBILITY STATE DETECTED
Figure 6 depicts the neighbouring measurement rules when high-mobility state is

detected.

Srxlev
Intra-frequency
Inter-frequency
hcsPrion <= hcsPrios
sSearchHcs
All Intra-frequency
All Inter-frequency
sInterSearch sIntraSearch Squal
Srxlev
GSM
hcsPrion <= hcsPrios
sHcsRat
All GSM
sSearchRat sLimitSearchRat
Squal
Figure 6 - Decision thresholds for Measurement when high-mobility is detected
Note: the main difference between Figure 5 and Figure 6 is the filtering of
neighbouring cell based on higher (High-Mobility not detected) or lower (High-
Mobility detected) HCS priority.
3.4.3.2.3 RECOMMENDATIONS WHEN HCS IS USED
Engineering Recommendation: sSearchHcs and sHcsRatGsm
It is recommended to set sSearchHcs and sHcsRat to 0 (i.e. -115 dBm) so as to have

measurement decisions only based on Squal.
Engineering Recommendation: sIntraSearch, sInterSearch, sSearchRatGSM and

sLimitSearchRat
If the purpose of an operator is to favor BSR coverage and to force UE to remain in the cells at the
maximum, it should set sIntraSearch (=8) > sInterSearch (=6) > sSearchRat (=4)
sLimitSearchRat is only used when high-mobility state is not detected. In such conditions, it is not
recommended to move to GSM; therefore, the operator shall set sLimitSearchRat=sSearchRat
(=4).

Rule: UE measurements
In the case sIntraSearch and sIntraSearch are not transmitted in the SIB messages, the UE should
always perform the corresponding measurements.
3.4.4 CELL ELIGIBILITY CRITERIA FOR RESELECTION

Once the criteria for measurement decision is fulfilled, UE shall measure the
neighbouring cells that are broadcast in SIB11; there are 3 different categories of
neighbouring cell:
• 3G Macro neighbouring cells
• GSM neighbouring cells
• BSR neighbouring cells
In the coming sections, UMTS neighbouring cell stands for either 3G Macro or BSR
neighbouring cell.
• umtsMacroCellRsInfo::EnableBroadcast: when set to True, this flag

allows to broadcast the 3G Macro neighbouring cells in SIB11. When set to
False, the broadcast is inhibited.
Parameter umtsMacroCellRsInfoenableBroadcast |
enableBroadcast
{True, False}
Class Class 3
Value TRUE
• gsmMacroCellRsInfo::EnableBroadcast: when set to True, this flag

allows to broadcast the GSM neighbouring cells in SIB11. When set to
False, the broadcast is inhibited.
Parameter gsmMacroCellRsInfoEnableBroadcast |
enableBroadcast
{True, False}
Class Class 3
Value TRUE
• interBSRCellRsInfo::EnableBroadcast: when set to True, this flag allows

to broadcast the BSR neighbouring cells in SIB11. When set to False, the
broadcast is inhibited

Parameter interBSRCellRsInfoenableBroadcast |
enableBroadcast
{True, False}
Class Class 3
Value FALSE
Following measurement decision and SIB11 decoding, UE applies criterion S on

the measured GSM or UMTS neighbouring cells to assess their eligibility to cell
reselection, as presented in the following sections.
Rule: Femto BSR SIB11
When a BSR belongs to a group, interBSRCellRsInfo::EnableBroadcast should be set to True to

allow neighbours to be broadcasted.
For Standalone BSR, it should be set to False to avoid UEs to reselect to another BSR for which is
not in the ACL of.
3.4.4.1 3G NEIGHBOURING CELL CRITERIA

To be eligible, the 3G Macro (intra and/or inter-frequency) neighbouring cells must
fulfill the following criterion:
Squal > 0 AND Srxlev > 0

i.e.
Qqualmeas > qQualMin AND Qrxlevmeas > qRxLevMin + Pcompensation
i.e.
CPICH_Ec/No > qQualMin AND CPICH_RSCP > qRxLevMin + Pcompensation
Where:
• Pcompensation = max (maxAllowedUlTxPower - P_MAX, 0)
Notes:
• qQualMin stands for umtsMacroCellRsInfo::QQualMin
• qRxLevMin stands for umtsMacroCellRsInfo::QRxLevMin
• maxAllowedUlTxPower stands for
umtsMacroCellRsInfo::MaxAllowedULTXPwr

Parameter umtsMacroCellRsInfoqRxLevMin | qRxLevMin
[-115...-25] step 2
Class Class 3
Value -111
Parameter umtsMacroCellRsInfoqQualMin | qQualMin

[-24...0]
Class Class 3
Value -19
Note: As per 3GPP, IE present in SIB is encoded as follows:

qRxLevMin = (IE*2)+1
Parameter umtsMacroCellRsInfoMaxAllowedULTXPwr |
MaxAllowedULTXPwr
[-50…33]
Class Class 3
Value 24
Rule: qQualMin / qRxLevMin values for umtsMacroCellRsInfo
umtsMacroCellRsInfo::QQualMin / QRxLevMin that are defined for 3G Macro acting as

neighbouring cell shall be equal or higher than the setting broadcasted by the same 3G Macro
acting as serving cell.
3.4.4.2 GSM NEIGHBOURING CELL CRITERIA

To be eligible, the inter-system GSM cells must fulfill the following criteria:
SrxLev > 0
i.e.
QRxLevMeas > qRxLevMin + Max (maxAllowedUlTxPower – Pmax, 0)
Where:

• qRxLevMin stands for gsmMacroCellRsInfo::QRxLevMin
• maxAllowedUlTxPower stands for
gsmMacroCellRsInfo::MaxAllowedULTXPwr
Neighbouring cell which does not fulfill these criteria can not be eligible to
reselection.
Parameter gsmMacroCellRsInfoqRxLevMin | qRxLevMin

[-115...-25] step 2
Class Class 3
Value -101
Note: As per 3GPP, IE present in SIB is encoded as follows:

qRxLevMin = (IE * 2) +1
Engineering Recommendation: qRxLevMin
It is recommended to align the value of gsmMacroCellRsInfo::MaxAllowedULTXPwr with the

used 2G rxLevAccessMin parameter present in the GSM network.
The difference between GSM 900/GSM 850 and GSM 1800/1900 is due to MS sensitivity:
• GSM 900: -104 dBm,
• GSM 1800: -102 dBm.
Parameter gsmMacroCellRsInfoMaxAllowedULTXPwr |
MaxAllowedULTXPwr
[-50…33]
Class Class 3
Value 33

Engineering Recommendation: gsmMacroCellRsInfo::MaxAllowedULTXPwr
The value of gsmMacroCellRsInfo::MaxAllowedULTXPwr shall be set according to the GSM

band which is used on the 2G network, taking also into account the classes of the mobiles (cf.
[3GPP_R03]).
The following values can be used as a starting point when no information is available from 2G:
• 33 for GSM 900 MHz Cells
• 30 for GSM 1800 MHz Cells
Nominal Maximum output Power

Power Class
GSM450, GSM 850 & GSM 900 DCS/GSM1800 PCS/GSM1900
1 1 W (30 dBm) 1 W (30 dBm)
2 8 W (39 dBm) 0.25 W (24 dBm) 0.25 W (24 dBm)
3 5 W (37 dBm) 4 W (36 dBm) 2 W (33 dBm)
4 2 W (33 dBm)
5 0.8 W (29 dBm)
Table 3 - Maximum output power for GSM mobiles
3.4.4.3 BSR NEIGHBOURING CELL CRITERIA

The criteria for the BSR neighbouring cell are the same as for the 3G neighbours
described in chapter 3.4.4.1;
The corresponding parameters are listed below.
Parameter interBSRCellRsInfoqQualMin | qQualMin

[-24...0]
Class Class 3
Value -19

Parameter interBSRCellRsInfoqRxLevMin | qRxLevMin
[-115...-25] step 2
Class Class 3
Value -111
Parameter interBSRCellRsInfomaxAllowedULTXPwr |
maxAllowedULTXPwr
[-50…33]
Class Class 3
Value 24
3.4.5 CELL RESELECTION – RANKING CRITERION WITHOUT

HCS
The cell ranking criterion is used to rank the cells prior to the reselection. When
HCS is not used, the behavior is as follows.
The cell-ranking criterion for serving cell is:
Rs = Qmeas,s + qHyst,s
When sIB3CrQualityMeasure = CPICH_Ec/N0:
Rs =Ec/No + sib3qHyst2s
When sIB3CrQualityMeasure =CPICH_RSCP:
Rs =RSCP + sib3qHyst1s
Cell ranking criterion for neighbouring cells is:
Rn = Qmeas,n – Qoffset s,n
Where:
• Qmeas,n = CPICH Ec/No or CPICH RSCP for FDD cells. For GSM cells,
the RxLev (average received signal level) is used instead of CPICH Ec/No
or CPICH RSCP in the mapping function.
• Qoffsets,n specifies the offset between the serving cell and the
neighbouring cell; it can have two different values:

o qOffset1sn is used with GSM cells or UMTS cells when the quality
measure for cell selection and re-selection is set to CPICH RSCP.
o qOffset2sn is only used for UMTS cells when the quality measure
for cell selection and re-selection is set to CPICH EC/N0.
The cells (serving and neighbouring) will be ranked according to the R criterion.
3.4.5.1 FIRST RANKING

Among the GSM and UMTS Cells verifying S criterion, UE shall perform ranking
according to ranking R criterion, as specified above.
In a first step, the mobile shall always consider the CPICH RSCP / RxLev
measurement and associated set of parameters (qHyst1, qOffset1sn):
Serving Cell: Rs = CPICH_RSCP + sib3qHyst1s

Eligible UMTS Neighbour cell: RnUMTS = CPICH_RSCP – qOffset1sn
Eligible GSM Neighbour cell: RnGSM = RxLev – qOffset1sn
• sib3qHyst1s is the hysteresis value of the serving BSR cell. It is used in

the process of Cell Reselection of cell by the UE when the quality measure
for cell selection and re-selection is the CPICH RSCP.
Parameter sib3qHyst1s
Object Lcell
[0…40] range 2
Class Class 3
Value 2
• umtsMacroCellRsInfo::QOffset1s is the offset between the BSR cell and

one of its 3G Macro neighboring cells, in case the quality measure for cell
selection/reselection is set to RSCP.
Parameter umtsMacroCellRsInfoqOffset1s | qOffset1s
[-50…50]
Class Class 3
Value 0
• gsmMacroCellRsInfo::QOffset1s is the offset between the BSR cell and

one of its GSM neighboring cells.

Parameter gsmMacroCellRsInfoqOffset1s | qOffset1s
[-50…50]
Class Class 3
Value 0
• interBSRCellRsInfo::QOffset1s is the offset between the BSR cell and

one of its BSR neighboring cells.
Parameter interBSRCellRsInfoqOffset1s | qOffset1s
[-50…50]
Class Class 3
Value 0
Then the cell reselection process is as follows (as specified in [3GPP_R01]):

• If a GSM cell is ranked as the best cell, then the UE shall perform cell re-
selection to that GSM cell.
• If an UMTS cell is ranked as the best cell and the quality measure
parameter sIB3CrQualityMeasure for cell re-selection is set to rSCP, then
UE shall perform cell re-selection to that UMTS cell.
• If an UMTS cell is ranked as the best cell and the quality measure
parameter sIB3CrQualityMeasure for cell re-selection is set to eCN0, then
UE shall perform a second ranking.
Parameter sIB3CrQualityMeasure
Object Lcell
Range & Unit Enum
{ecN0, rSCP}
Class Class 3
Value ecN0
3.4.5.2 SECOND RANKING

In case an UMTS cell is ranked as the best cell according to the first ranking, a
second ranking of the UMTS cells is applied at the CPICH EC/NO case with the
associated set of parameters (qHyst2, qOffset2sn):

Serving Cell: Rs = CPICH_Ec/No + sib3qHyst2
Eligible UMTS Neighbour cell: RnUMTS = CPICH_Ec/No – qOffset2sn
• sib3qHyst2s is the hysteresis value of the serving BSR cell. It is used in

the process of Cell Reselection of cell by the UE when the quality measure
for cell selection and re-selection is the CPICH EcNo.
Parameter sib3qHyst2s
Object Lcell
[0…40] range 2
Class Class 3
Value 2
• umtsMacroCellRsInfo::QOffset2s is the offset between the BSR cell and

one of its 3G Macro neighboring cells, in case the quality measure for Cell
Reselection is set to EcNo.
Parameter umtsMacroCellRsInfoqOffset2s | qOffset2s
[-50…50]
Class Class 3
Value 0
• interBSRCellRsInfo::QOffset2s is the offset between the BSR cell and

one of its BSR neighboring cells, in case the quality measure for Cell
Reselection is set to EcNo.
Parameter interBSRCellRsInfoqOffset2s | qOffset2s
[-50…50]
Class Class 3
Value 0
3.4.5.3 TARGET CELL SELECTION

Following these rankings, the UE shall perform cell re-selection to the best-ranked
BSR, UMTS or GSM cell.
In any case, the UE shall reselect the new cell when both following conditions are
met:
• The new cell is better ranked than the serving cell during
sib3TReselection time interval.

• More than 1 second has elapsed since the UE camped on the current
serving cell.
Parameter sib3TReselection
Object Lcell
[0…31]
Class Class 3
Value 2
Several scaling factors, introduced by 3GPP R5 (and thus only considered by R5

and later UEs), can be applied to sib3TReselection:
• sib3InterFreqScalingFactor between 1 and 4.75, in order to delay the
reselection to Inter-frequency neighbouring cell.
• sib3InterRATScalingFactor between 1 and 4.75, in order to delay the
reselection to GSM neighbouring cell.
An additional scaling factor, sIB3SpeedDependentScalingFactor is introduced in

BCR02.02, which is related to the speed detection.
It specifies the scaling (multiplication) factor to be used by the UE in idle mode for
the parameter Treselection in case high-mobility is used and such a state has been
detected.
Rule: sib3TReselection
sib3TReselection has to be multiplied by the corresponding scaling factor if needed.

For instance, in case of a UE in high mobility in inter-frequency reselection, the time to be
considered will be equal to:
sib3TReselection * sIB3SpeedDependentScalingFactor * sib3InterFreqScalingFactor
Parameter sib3InterFreqScalingFactor
Object Lcell
Range & Unit Real
[1…4.75] step 0.25
Class Class 3
Value 1
Note: IE present in SIB is encoded as follows: sib3InterFreqScalingFactor =

IE*0.25

Parameter sib3InterRATScalingFactor
Object Lcell
Range & Unit Real
[1…4.75] step 0.25
Class Class 3
Value 1
Note: IE present in SIB is encoded as follows: sib3InterRATScalingFactor =

IE*0.25
Parameter sIB3SpeedDependentScalingFactor
Object Lcell
[0.0…1.0] step 0.1
Class Class 3
Value 1
3.4.6 CELL RESELECTION – RANKING CRITERION WITH HCS
3.4.6.1 QUALITY LEVEL THRESHOLD H CRITERION

HCS introduces a new criterion, so-called Quality Level Threshold H criterion,
which is used to determine whether prioritized ranking according to hierarchical cell
re-selection shall apply, and is defined by:
Hs = Qmeas,s – qHcs,s
Hn = Qmeas,n – qHcs,n – TOn * Ln
Where:
• Qmeas = CPICH_Ec/N0 or CPICH_RSCP for FDD cells based on
qualMeas parameter. For GSM cells, RxLev (average received signal
level) is used instead of CPICH Ec/N0 or CPICH RSCP in the mapping
function.
• qHcs specifies the quality threshold levels for applying prioritized
hierarchical cell re-selection
• TOn = tempOffset,n * W(penaltyTime,n - Tn)
o W(t)=0 for t<0
o W(t)=1 for t>=0
• Ln equals to 0 or 1 depending on hcsPrio of neighbouring cell

o Ln = 0 if hcsPrio,n = hcsPrio,s
o Ln = 1 if hcsPrio,n <> hcsPrio,s
H criterion can be reformulated by distinguishing HCS priority of neighbouring cell

with respect to serving cell’s:
Hs = Qmeas,s – qHcs,s
Hn = Qmeas,n – qHcs,n if hcsPrio,n = hcsPrio,s
Hn = Qmeas,n – qHcs,n – tempOffset,n * W(t) if hcsPrio,n <> hcsPrio,s
Figure 7 depicts how to apply tempOffset on Hn for a cell whose HCS priority is
different than the serving cell’s.
Rule: Tn
Timer Tn is started, per definition, as soon as Hn get >0 (Qmeas,n >= qHcs,n) and tempOffset is
then applied to Hn during penaltyTime.
In case, CPICH_Ec/N0 is chosen for Qmeas of UMTS neighbouring cell,

tempOffset2 applies, tempOffset1 otherwise.
Quality Timer Tn is started

Hn
measure Qmeas,n - qHcsn
tempOffsetn
time
Qmeas,n
penaltyTimen
qHcsn
Figure 7 - Applying tempOffset on Hn when hcsPrio,n <> hcsPrio,s

Once H criterion has been computed for the serving cell and each neighbouring
cell, UE performs ranking of all cells that fulfill the S criterion among:
• When high-mobility state has NOT been detected (the higher priority, the
smaller size),
o All measured cells, that have the highest hcsPrio among the cells that
fulfill H>=0
o All measured cells, not considering hcsPrio levels, if no cell fulfills H>=0
• When high-mobility state has been detected (the lower priority, the bigger
size),
o All measured cells with the highest hcsPrio that fulfil H>=0 and have a
lower hcsPrio than serving cell, else:
o All measured cells with the lowest hcsPrio that fulfil H>=0 and have a
higher or equal hcsPrio than serving cell, else:
o All measured cells without considering hcsPrio
To better understand this 3GPP algorithm, let’s consider the following example:
• Topology:
o FDD1 has lower priority hcsPrio1
o BSR has higher priority hcsPrio2

• High-mobility state has NOT been detected
• UE has selected FDD1 and corresponding CPICH Ec/No is very good (i.e.
purple square, top-right, of Figure 5) Æ UE is supposed to measure BSR as
hcsPrio2 > hcsPrio1
Assuming BSR CPICH Ec/No is also very good, i.e. H2>0 even after applying
tempOffset2, UE is not supposed to rank FDD1 as:
• hcsPrio2 > hcsPrio1 AND H2>0
In case H2>0 during more than tReselection, UE will directly perform cell
reselection on BSR without comparing BSR to FDD1 (as FDD1 is not ranked).
HCS priority is therefore a way of filtering the cells to be ranked through H criterion.
Chapter 3.4.6.3 presents the ranking process when HCS is used.
3.4.6.2 HCS PARAMETERS

The parameters used while HCS is enabled are listed in chapter 3.1.1
Table 4 gives the mapping between qHcs (provisioned in FMS and broadcast to
UE) and the value used by the UE in the HCS algorithm, depending on quality
measure (FDD EcNo, FDD Rscp or GSM RSSI), following these formulas:

• FDD EcNo: real_value = -24 + qHcs/2

• FDD Rscp: real_value = -115 + qHcs
• GSM Rssi: real_value = -110 + qHcs
3.4.6.3 RANKING R CRITERION

Among the GSM and FDD Cells verifying S and H criteria, UE shall perform
ranking according to ranking R criterion, as specified hereafter:
Rn = Qmeas,n – qOffset,s,n – TOn * Ln

FDD EcNo FDD Rscp GSM Rssi
qHcs
(dB) (dBm) (dBm)
0 -24 -115 -110
1 -23.5 -114 -109
2 -23 -113 -108
3 -22.5 -112 -107
…
45 -1.5 -70 -65
46 -1 -69 -64
47 -0.5 -68 -63
48 0 -67 -62
49 (spare) -66 -61
…
72 (spare) -43 -38
73 (spare) -42 -37
74 (spare) -41 -(spare)
…
90 (spare) -(spare) -(spare)
…
Table 4 - Mapping for qHcs
Once again, R criterion can be reformulated by distinguishing HCS priority of

neighbouring cell with respect to serving cell’s:
Rn = Qmeas,n – qOffset,s,n – temporaryOffset,n * if hcsPrio,n = hcsPrio,s
W(t)
if hcsPrio,n <>
Rn = Qmeas,n – qOffset,s,n hcsPrio,s
Temporary offset now applies on the neighbouring cell whose HCS priority is equal
to serving cell’s.

The ranking is made in 1 or 2 steps depending sIB3CrQualityMeasure value:

• If set to EcNo, the ranking is performed on 1 or 2 steps:
o First ranking based on CPICH RSCP of UMTS cells and RxLev of
GSM cells and associated set of parameters (qHyst1,
qOffset1sn)
o Second ranking (in case an FDD cell is ranked as the best cell
according to the first ranking) based on CPICH EC/NO and
associated set of parameters (qHyst2, qOffset2sn)
• If set to Rscp, the ranking is only based on CPICH RSCP of UMTS cells and
RxLev of GSM cells and associated set of parameters (qHyst1, qOffset1sn)
3.4.6.4 TARGET CELL SELECTION

In any case, the UE shall reselect the new cell when both following conditions are
met:
• The new cell is better ranked than the serving cell during
sib3TReselection time interval.
• More than 1 second has elapsed since the UE camped on the current
serving cell.
Several scaling factors can be applied to sib3TReselection (see chapter
3.4.5.3):
• sIB3SpeedDependentScalingFactor between 0 and 1, in order to speed
up the reselection.
• sib3InterFreqScalingFactor between 1 and 4.75, in order to delay the
reselection to Inter-frequency neighbouring cell.
• sib3InterRATScalingFactor between 1 and 4.75, in order to delay the
reselection to GSM neighbouring cell.

3.5. HANDOVER TO 3G/2G

There are two broad methods for determining handover targets which are on a
different frequency to the serving cell: Femto Assisted Handover and Mobile
Assisted Handover (MAHO).
With Femto Assisted handover (also known as Blind HO or Data Base Assisted
Handover (DAHO)) it is assumed that the relationship between a cell and its
neighbour is well understood. As an example, if a Femto Small Cell is contained in
the centre of a Macro Cell with strong signal power level, it may be assumed that
the macro cell is always there and handover may be reliably executed whenever
required. In this case Femto assisted handover is preferable as it may be executed
immediately without the delay of activating UE measurements and the UE
performing the measurements. This can improve the handover reliability.
There are however cases where mobile assisted handover is preferable. Examples
are where there are a number of macro cells in the Femto Small Cell coverage
area and depending upon UE locations, different target cells selected. Another
example is where there is poor macro cell coverage in the Femto Small Cell area
and there is a high probability that there is no underlying macro cell.
Inter-Release Delta: Mobile assisted handover
MAHO is supported since FPUG 3.0 through the feature 75387.
3.5.1 ELIGIBILITY FOR HANDOVER
3.5.1.1 HANDOVER TRIGGERING

When a CS (resp. CS+PS or PS) call is running, BSR checks the eligibility for
handover using the following activation flag targetHOCS (resp. targetHOCSPS or
targetHOPS) whose behaviour is as follows:
• When set to disable, handover is disabled and call eventually drops if radio
condition keeps on degrading.
• When set to fdd, only handover to Macro 3G may occur.
• When set to gsm, only handover to Macro 2G may occur.
• When set to fddPreferred, handover to Macro 3G is the preference but HO
to Macro 2G may occur as a backup if needed.
• When set to gsmPreferred, handover to Macro 2G is the preference but
HO to Macro 3G may occur as a backup if needed.

Parameter targetHOCS
Object Lcell
Class Class 3
Value fddPreferred
Parameter targetHOCSPS
Object Lcell
Class Class 3
Value fddPreferred
Parameter targetHOPS
Object Lcell
Class Class 3
Value fddPreferred
Engineering Recommendation: targetHO
For CS, CS+PS and PS, it is recommended to perform HO to Macro 3G as much as possible;
however, HO to GSM should be considered as a backup in case no 3G neighbouring cells is
available. Therefore, targetHOCS, targetHOCSPS and targetHOPS must be set to fddPreferred.
In addition, 3G preferred frequencies are set for each type of bearer through
LCELL::targetHOFddFreqCS, LCELL::targetHOFddFreqHSDPA and
LCELL::targetHOFddFreqR99.
Inter-Release Delta: LCELL::targetHOFddFreqHSDPA, LCELL::targetHOFddFreqR99
Objects LCELL::targetHOFddFreqCS, LCELL::targetHOFddFreqHSDPA and

LCELL::targetHOFddFreqR99 are new in FPUG 3.0 (feature 100888). The object
LCELL::targetHOFddFreqCS that concerned service-based handover in FPUG 2.4 is renamed in
LCELL::sBtargetHOFddFreqCS (see [Vol. 4]).

Parameter freqBand
Object LCell::targetHOFddFreqCs | targetHOFddFreqCs

Class Class 3
Value -
Parameter uARFCNDL

[0..16383]
Class Class 3
Value -
Parameter uARFCNUL

[0..16383]
Class Class 3
Value -
Parameter freqBand
Object LCell::targetHOFddFreqHSDPA |
targetHOFddFreqHSDPA
Class Class 3
Value -

Parameter uARFCNDL
[0..16383]
Class Class 3
Value -
Parameter uARFCNUL
[0..16383]
Class Class 3
Value -
Parameter freqBand
Object LCell::targetHOFddFreqR99 | targetHOFddFreqR99

Class Class 3
Value -
Parameter uARFCNDL

[0..16383]
Class Class 3
Value -
Parameter uARFCNUL

[0..16383]
Class Class 3
Value -

3.5.1.2 MEASUREMENT CONFIGURATION
Measurement parameters can be set to different values, depending on the
handover type: CS, PS R99 and PS HSDPA. Four different handover profiles can
be defined through the object HO.
For each handover type, a parameter points to one of those handover profiles:
• csHoConfig for CS call handover,
• psR99Config for PS R99,
• psHsConfig for PS HSDPA.
Parameter csHoConfig
Object LCell
[1..4]
Class Class 3
Value 1
Parameter psR99Config
Object LCell
[1..4]
Class Class 3
Value 1
Parameter psHsConfig
Object LCell
[1..4]
Class Class 3
Value 1
3.5.1.3 TARGET CELLS RANKING

The importance given to each metric used to rank the target cells is set through the
structure hoRanking. Here are the metrics:
• manualHighPrio : HO ranking from manually configured cells with high
HO priority;
• ratPref : HO ranking for preferred RAT;
• ePLMown : HO ranking for own PLMN when ePLMN feature is enabled;
• freqBandPref : HO ranking for preferred frequency band when multi band
is enabled;

• freqPref : HO ranking for preferred frequency when specified;
• blindHoSuccRate : HO ranking for handover success rate during blind
HO;
• measRx : HO ranking for measured received signal;
• mahoUeRep : HO ranking for UE measurement report during MAHO;
• manualLowPrio : HO ranking for manually configured cells with low HO
priority;
• intraFreqBlindHoPref : HO ranking for intra-frequency blind HO.
Parameter hoRankingManualHighPrio | manualHighPrio

Object LCell | hoRanking
[0..100000000]
Class Class 3
Value 100000000
Parameter hoRankingRatPref | ratPref

[0..100000000]
Class Class 3
Value 100000000
Parameter hoRankingEPLMNown | ePLMNown

[0..100000000]
Class Class 3
Value 10000000
Parameter hoRankingFreqBandPref | freqBandPref

[0..100000000]
Class Class 3
Value 10000000

Parameter hoRankingFreqPref | freqPref
[0..100000000]
Class Class 3
Value 1000000
Parameter hoRankingBlindHoSuccRate | blindHoSuccRate

[0..100000000]
Class Class 3
Value 100000
Parameter hoRankingMeasRx | measRx

[0..100000000]
Class Class 3
Value 10000
Parameter hoRankingMahoUeRep | mahoUeRep

[0..100000000]
Class Class 3
Value 10000
Parameter hoRankingManualLowPrio | manualLowPrio

[0..100000000]
Class Class 3
Value 1000
Parameter hoRankingIntraFreqBlindHoPref |
intraFreqBlindHoPref
[-100000000..100000000]
Class Class 3
Value 0

3.5.1.4 COMPRESSED MODE (CM)

Due to restrictions in the UE measurement capability, it is not possible for most
UEs to make measurements on two frequencies at the same time. This restriction
is in order to simplify the hardware costs of the UE. In order to facilitate inter-
frequency measurements the UE is provided with periodic measurement
opportunities where gaps are created in the signal transmission to allow the UE to
perform the measurements. These gaps are typically short (less than 10ms in
length) and repeat periodically (typically of the order of 100ms). The gap patterns
are defined on a 10ms frame basis, generally spanning two frames where half of
the gap is in the first frame and the other half in the second frame. These gaps are
then repeated a number of frames later.
Pattern Repeat (TGPL1)
Measurement 1 Measurement 2 Measurement 1 Measurement 2

Gap Normal Frame Gap Normal Frame Gap Normal Frame Gap
TGL1
10ms Frame 10ms Frame

0.6 66ms Slot
Figure 8 – Compressed Mode
The method of gap generation for the measurement purposes is known as

"compressed mode" and the UE is provided with gap patterns for different types of
measurements. These can be:
Inter-Frequency 3G (FDD);
Inter-RAT 2G (GSM).
Within GSM measurements there are separate measurements for determination of

a GSM frequency (GSM RSSI) and the Base Station Signature (BSIC Verification
and Re-confirmation).
Each set of measurements requires a separate compressed mode pattern to be
activated within the UE and coordinated within the layer 1 of the Femto (Node B
function). There are two methods available for CM pattern generation:
1) SF/2 method - Suitable for CS traffic - During the frames containing CM gaps,
the physical layer is provided with a lower spreading factor for the non-gap
transmission, thus ensuring that the full data is delivered on time in the period
before and after the gap.

In order to avoid clashes with existing calls, the lower spreading factor can be
transmitted on an alternative scrambling code to the primary scrambling code. This
can result in some elevated downlink interference in downlink transmissions during
CM frames, but has the advantage that it can be applied without a re-arrangement
in the channelisation code tree.
2) Higher Layer Scheduling (HLS) - Suitable for PS channels or CS+PS over DCH.
With this method the data rate is reduced during frames containing CM gaps so
that the lower data rate will fill up the non-gap transmission.
HSDPA and E-DCH are scheduled and can fit the scheduling of data with the CM
gap patterns.
The BSR supports the configuration of UE inter-RAT measurements to identify a

GSM cell, and the configuration of UE inter-frequency measurements to identify an
inter-frequency UMTS cell. It also supports combined inter-Frequency and inter-
RAT measurement reporting.
The BSR supports the configuration of CM to support the inter-frequency/inter-RAT
measurements where required.
The Inter-RAT measurements support RSSI (always) and BSIC Verification
(optional).
As an option in OAM, it is possible to configure BSIC measurements for 2G only
when there is a duplication of ARFCN (Absolute Radio Frequency Channel
Number) in the target HO cells.
During 2G HO, bSICselect determines whether BSIC verification is required.
Parameter bSICselect
Object LCell
{arfcnAmbiguity=0, always=1}
Class Class 3
Value arfcnAmbiguity
Restriction: Hardware limitations
The method of never using BSIC Re-confirmation is selected for the Femto.
The CM gap patterns are configurable through the parameter cmScenario

depending upon whether GSM RSSI, GSM RSSI+BSIC, FDD, FDD+ GSM RSSI,
FDD+ GSM RSSI+GSM BSIC are enabled.

Parameter cmScenario
Object TGPInfo
Granularity TGPInfo
{gSMrSSI=1, gSMrSSIbSIC=2, fDD=3,
fDDgSMrSSI=4, fDDgSMrSSIbSIC=5}
Class Class 3
Value gSMrSSI
The BSR determines the need for CM from the UE capabilities signalled to the
BSR in the RRC Connection Setup Complete/ Handover Procedure.
The BSR supports CM deactivation.
The BSR supports compressed mode with SF/2 and alternate scrambling code and
HLS for CS+PS I/B or PS I/B over DCH.
The BSR handles the case where a UE rejects the CM activation and attempts to
maintain the call.
deltaSIR1 defines the Delta Signal-to-Interference Ratio (SIR) target value to be

set in the BSR during the frame containing the start of the first transmission gap in
the transmission gap pattern (without including the effect of the bit-rate increase).
This Delta is applied to the uplink/downlink transmission power control procedure.
Parameter deltaSIR1
Object CMGG
[0.0..3.0] step 0.1
Class Class 3
Value 0
deltaSIRafter1 defines the Delta SIR target value to be set in the Node-B one
frame after the frame containing the start of the first transmission gap in the
transmission gap pattern.
Parameter deltaSIRafter1
Object CMGG
[0.0..3.0] step 0.1
Class Class 3
Value 0
iTP defines the Initial Transmit Power which is the uplink power control method to
be used to compute the initial transmit power after the compressed mode gap.

Parameter iTP
Object CMGG
{mode0=0, mode1=1}
Class Class 3
Value mode0
rPP defines the Recovery Period Power control mode during the frame after the
transmission gap within the compressed frame.
For RPP mode 0, the step size is not changed during the recovery period and
ordinary transmit power control is applied, using the algorithm for processing TPC
commands determined by the value of PCA (Power Control Algorithm).
For RPP mode 1, during RPL slots after each transmission gap, power control
algorithm 1 is applied with a step size DeltaRP-TPC instead of DeltaTPC,
regardless of the value of PCA.
Parameter rPP
Object CMGG
{mode0=0, mode1=1}
Class Class 3
Value mode0
3.5.1.5 COMPLIANCE WITH 3G NETWORK

BSR supports handover to the 3G macro network through SRNS relocation. The
maximum 3GPP release of SRNS relocation Info RRC container which the macro
UTRAN can support is configured through parameter srnsContainerMaxRel.
Parameter srnsContainerMaxRel
Object LCell
{rel5=0, rel6=1, rel7=2}
Class Class 3
Value rel6
If the parameter srnsRelocateOnEarlierContainer is set to true, it is enabled to a

call requiring a particular release of container to be relocated to an earlier release
of RNC. If set to false, that kind of relocation will be forbidden.

Parameter srnsRelocateOnEarlierContainer
Object LCell
{True, False}
Class Class 3
Value true
3.5.2 MOBILE ASSISTED HANDOVER

The MAHO feature enables the configuration of measurements so that the UE is
handed over only when the UE reports that it can see the neighbour cell and which
neighbour it is able to see.
In the case where MAHO cannot be successfully activated for any reason, the BSR
falls back to blind HO.
The following parameterisation is used to configure the algorithm:

• mahoOnHoSuccessRate::initialTarget - Initial default to use:
o maho - Initially use MAHO;
o blindHo - Initially use Blind HO;
o auto - If the number of HO targets is greater than or equal to
mahoNumCellsToEnable, then initially use MAHO otherwise use
Blind HO.
Parameter mahoOnHoSuccessRateInitialTarget | initialTarget

Object LCell | mahoOnHoSuccessRate
{auto=0, maho=1, blindHo=2}
Class Class 3
Value auto
Parameter mahoNumCellsToEnable
Object LCell
[1..3]
Class Class 3
Value 2
• mahoOnHoSuccessRate::thresholdNoCell - If the number of cases

where no target cell is found is higher than this then the automatic HO
selection will select Mobile Assisted Handover.

Parameter mahoOnHoSuccessRateThresholdNoCell |
thresholdNoCell
Range & Unit Real
[0.00..1.00] step 0.01
Class Class 3
Value 0.1
• mahoOnHoSuccessRate::thresholdBest - If the highest frequency

handover target is lower than this then the automatic HO selection will
select Mobile Assisted Handover.
Parameter mahoOnHoSuccessRateThresholdBest |
thresholdBest
Range & Unit Real
[0.00..1.00] step 0.01
Class Class 3
Value 0.9
• mahoOnHoSuccessRate::mahoBlindHoSamples - Minimum number of

samples for a decision to evaluate the HO method.
Parameter mahoOnHoSuccessRateMahoBlindHoSamples |
mahoBlindHoSamples
[0..1000]
Class Class 3
Value 20
mahoNoCellTime defines the minimum time which the UE has to report a macro
neighbour cell before determining that no macro cell is present.
Parameter mahoNoCellTime
Object LCell
[0..255]
Class Class 3
Value 3
The flag blindHoPrioOnHighestSuccCell determines whether the blind handover

is prioritised based upon the most successfully measured cell.

Parameter blindHoPrioOnHighestSuccCell
Object LCell
{True, False}
Class Class 3
Value true
3.5.2.1 ELIGIBILITY FOR HANDOVER

The BSR supports mobile assisted handover based upon UE measurements for all
types of CS Voice, PS and CS+PS Handover Supported i.e.:
• 2G;
• 2G+3G, 2G preferred;
• 2G+3G, 3G preferred;
• 3G.
3.5.2.1.1 INTRA-FREQUENCY HANDOVER

Inter-Release Delta: Intra-Frequency MAHO
Since FPUG 3.0, intra-frequency MAHO is available in CS (feature 100856) and PS (feature
100856) domains.
Intra-frequency handover is enabled through parameter mahoActivationIntra.
Parameter mahoActivationIntra
Object BSR Profile
{True, False}
Class Class 3
Value TRUE
3.5.2.1.2 INTER-FREQUENCY HANDOVER

Inter-frequency handover for CS, CS+PS and PS calls is activated respectively
through the parameter mahoInterActivationCs, mahoInterActivationCsPs, and
mahoInterActivationPs.
• When set to always: MAHO is enabled;
• When set to never: MAHO is disabled;

• When set to automatic: automatic HO selection algorithm presented before
is used;
• When set to numberOfTargets: MAHO is enabled only if number of HO
candidates exceeds mahoNumCellsToEnable.
Parameter mahoInterActivationCs
Object LCell
{automatic=0, always=1, never=2,
numberOfTargets=3}
Class Class 3
Value never
Parameter mahoInterActivationCsPs
Object LCell
numberOfTargets=3}
Class Class 3
Value never
Parameter mahoInterActivationPs
Object LCell
numberOfTargets=3}
Class Class 3
Value never
Each of the following inter-freq/RAT HO scenarios is configurable when MAHO is

enabled:
• RF Quality Triggers;
• Active Call Redirection;
• Service Based Handover.
And each scenario allows separate HO threshold tunings.
mahoInterQualityConfig::mahoInterCandidate,
mahoInterAcrConfig::mahoInterCandidate, and
mahoInterSbConfig::mahoInterCandidate determine whether inter-freq/RAT
MAHO is enabled for the respective scenario - if set to FALSE, it will never be
activated for that scenario. If set to true it will be a candidate for MAHO.

Parameter mahoInterQualityConfigMahoInterCandidate |
mahoInterCandidate
Object HO | mahoInterQualityConfig
Granularity BSR Profile | HO
{True, False}
Class Class 3
Value false
Parameter mahoInterAcrConfigMahoInterCandidate |
mahoInterCandidate
Object HO | mahoInterAcrConfig
{True, False}
Class Class 3
Value false
Parameter mahoInterSbConfigMahoInterCandidate |
mahoInterCandidate
Object HO | mahoInterSbConfig
{True, False}
Class Class 3
Value false
mahoInterLayers determines which macro layers MAHO can be eligible. This

applies to MAHO for inter-freq 3G and inter-RAT only.
Parameter mahoInterLayers
Object LCell
{fdd=0, gsm=1, fddgsm=2}
Class Class 3
Value fddgsm
3.5.2.2 DETECTION RADIO DEGRADATION

When a preferred layer is determined and a measurement report is provided for the
non preferred layer only, the timer
mahoInterMeasurementConfig::mahoTimePreferred allows a wait time for the
preferred measurement to come in.

Parameter mahoInterMeasurementConfigMahoTimePreferred
| mahoTimePreferred
Object HO | mahoInterMeasurementConfig
[0..10000]
Class Class 3
Value 1000
Periodic repetition time of the MAHO measurement report is defined by

mahoInterMeasurementConfig::mahoPeriodicRepTime.
Parameter mahoInterMeasurementConfigMahoPeriodicRepTi
me | mahoPeriodicRepTime
reportinginterval500=500, reportinginterval1000=1000,
Class Class 3
mahoInterMeasurementConfig::mahoIntraFilterCoefficient defines the filter

coefficient for the Intra-Frequency measurement used for evaluating the quality of
the serving cell during MAHO.
Parameter mahoInterMeasurementConfigMahoIntraFilterCoeff
icient | mahoIntraFilterCoefficient
{coeff0=0, coeff1=1, coeff2=2, coeff3=3, coeff4=4,
coeff5=5, coeff6=6, coeff7=7, coeff8=8, coeff9=9,
coeff11=11, coeff13=13, coeff15=15, coeff17=17,
coeff19=19}
Class Class 3
Value coeff3

mahoInterMeasurementConfig::maho3gFilterCoefficient defines the filter
coefficient for the Inter-Frequency measurement used for evaluating the quality of
the inter-frequency cell during MAHO.
Parameter mahoInterMeasurementConfigMaho3gFilterCoeffic
ient | maho3gFilterCoefficient
coeff19=19}
Class Class 3
Value coeff3
mahoInterMeasurementConfig::maho2gFilterCoefficient defines the filter

coefficient for the Inter-RAT measurement used for evaluating the quality of the 2G
cell during MAHO.
Parameter mahoInterMeasurementConfigMaho2gFilterCoeffic
ient | maho2gFilterCoefficient
coeff19=19}
Class Class 3
Value coeff3

The UE measurement to trigger the intra-frequency handover is event 1C “A non-
active primary CPICH becomes better than an active primary CPICH”.
The measurement parameters are common to the BSR to BSR handover (cf
3.6.3):
• intrafrequencyFilterCoefficient,
• bSRToBSRReportingCriteria1C::reportingInterval,
• bSRToBSRReportingCriteria1C::hysteresis,
• bSRToBSRReportingCriteria1C::timetoTrigger.

3.5.2.2.2 INTER-FREQUENCY/RAT HANDOVER
When MAHO is enabled due to RF Quality triggers, a separate set of 2D/2F
thresholds is used to those used for Blind HO.
This is because the MAHO activation needs to occur at a stronger signal quality to
account for the additional delay.
Each time BSR detects the need for radio degradation assessment, 2 Events are
configured at UE side, as per [3GPP_R02]:
• Radio is degrading: Event 2D is reported by UE when BSR CPICH Ec/No
or CPICH RSCP becomes below a certain threshold;
• Radio is back to normal: Event 2F is reported by UE when BSR CPICH
Ec/No or CPICH RSCP becomes above a certain threshold.
The following setting is used for Event 2D EcNo:
Parameter mahoInter2d2fEcnoThreshold2d | threshold2d

Object HO | mahoInter2d2fEcno
[-24..0]
Class Class 3
Value -15
Parameter mahoInter2d2fEcnoTimeToTrigger2d |
timeToTrigger2d
{timetotrigger0=0, timetotrigger10=10,
timetotrigger20=20, timetotrigger40=40,
timetotrigger2560=2560, timetotrigger5000=5000}
Class Class 3
Value timetotrigger320
Parameter mahoInter2d2fEcnoHysteresis2d | hysteresis2d

[0.0..14.5] step 0.5
Class Class 3
Value 2

The following setting is used for Event 2D RSCP:
Parameter mahoInter2d2fRscpThreshold2d | threshold2d

Object HO | mahoInter2d2fRscp
[-115..-25]
Class Class 3
Value -110
Parameter mahoInter2d2fRscpTimeToTrigger2d |
timeToTrigger2d
Class Class 3
Parameter mahoInter2d2fRscpHysteresis2d | hysteresis2d

[0.0..14.5] step 0.5
Class Class 3
Value 2
The following setting is used for Event 2F EcNo:
Parameter mahoInter2d2fEcnoThreshold2f | threshold2f

[-24..0]
Class Class 3
Value -15

Parameter mahoInter2d2fEcnoTimeToTrigger2f |
timeToTrigger2f
Class Class 3
Parameter mahoInter2d2fEcnoHysteresis2f | hysteresis2f

[0.0..14.5] step 0.5
Class Class 3
Value 2
The following setting is used for Event 2F RSCP:
Parameter mahoInter2d2fRscpThreshold2f | threshold2f

[-115..-25]
Class Class 3
Value -110
Parameter mahoInter2d2fRscpTimeToTrigger2f |
timeToTrigger2f
Class Class 3

Parameter mahoInter2d2fRscpHysteresis2f | hysteresis2f
[0.0..14.5] step 0.5
Class Class 3
Value 2
3.5.2.3 HANDOVER EXECUTION

The handover is triggered when a macro cell becomes better than the BSR by an
offset. In case BSR to BSR handover is enabled, the BSR can prioritize handover
to another BSR. So one out of two different CIOs (Cell Individual Offsets) is applied
to the macro cell, depending on the scenario:
• cioMacroMixed if there are other BSRs monitored concurrently,
• cioMacroNormal if not.
Parameter cioMacroMixed
Object BSR Profile
Range & Unit Real
[-10.0..10.0] step 0.5
Class Class 3
Value 0
Parameter cioMacroNormal
Object BSR Profile
Range & Unit Real
[-10.0..10.0] step 0.5
Class Class 3
Value 0
In order to avoid unnecessary mobility procedures, while serving BSR EcNo is

above intraMahoOwnEcNo, 1C measurements are ignored and therefore intra-
freq handover cannot occur.

Parameter intraMahoOwnEcNo
Object BSR Profile
[-24..0]
Class Class 3
Value 0
3.5.2.3.2 INTER-FREQUENCY/RAT HANDOVER

The BSR compares the UE measurements against the following thresholds for
Inter-Frequency 3G HO:
• Own Cell Ec/No - MAHO measurement report must be less than or equal
to the Ec/No threshold by mahoInterQualityFddOwnEcNo;
Parameter mahoInterQualityFddOwnEcNo
Object HO
[-24..0]
Class Class 3
Value -16
• Own Cell RSCP - MAHO measurement report must be less than or equal
to the RSCP threshold by mahoInterQualityFddOwnRscp;
Parameter mahoInterQualityFddOwnRscp
Object HO
[-115..-25]
Class Class 3
Value -111
• Inter-Frequency Ec/No - the minimum acceptable Ec/No quality of an inter-

Frequency cell reported in a MAHO measurement report to be considered
eligible for HO is determined by
mahoInterQualityConfig::mahoQualityFddInterEcNo,
mahoInterAcrConfig::mahoQualityFddInterEcNo and
mahoInterSbConfig::mahoQualityFddInterEcNo;

Parameter mahoInterQualityConfigMahoQualityFddInterEcNo
| mahoQualityFddInterEcNo
[-24..0]
Class Class 3
Value -12
Parameter mahoInterAcrConfigMahoQualityFddInterEcNo |
mahoQualityFddInterEcNo
[-24..0]
Class Class 3
Value -12
Parameter mahoInterSbConfigMahoQualityFddInterEcNo |
mahoQualityFddInterEcNo
[-24..0]
Class Class 3
Value -12
• Inter-Frequency RSCP – the minimum acceptable CPICH RSCP of an

inter-Frequency cell reported in a MAHO measurement report to be
considered eligible for HO is determined by
mahoInterQualityConfig::mahoQualityFddInterRscp,
mahoInterAcrConfig::mahoQualityFddInterRscp and
mahoInterSbConfig::mahoQualityFddInterRscp.
Parameter mahoInterQualityConfigMahoQualityFddInterRscp
| mahoQualityFddInterRscp
[-115..-25]
Class Class 3
Value -108

Parameter mahoInterAcrConfigMahoQualityFddInterRscp |
mahoQualityFddInterRscp
[-115..-25]
Class Class 3
Value -108
Parameter mahoInterSbConfigMahoQualityFddInterRscp |
mahoQualityFddInterRscp
[-115..-25]
Class Class 3
Value -108
When all conditions are met, then HO is eligible to the target.

The BSR compares the UE measurements against the following thresholds for
Inter-RAT 2G HO:
• Own Cell Ec/No – same condition as the one for Inter-Frequency 3G HO;
• Own Cell RSCP – same condition as the one for Inter-Frequency 3G HO;
• Inter-RAT RSSI - the minimum acceptable RSSI of a 2G cell reported in a
MAHO measurement report to be considered eligible for HO is determined
by mahoInterQualityConfig::mahoQualityGsmRssi,
mahoInterAcrConfig::mahoQualityGsmRssi and
mahoInterSbConfig::mahoQualityGsmRssi.
Parameter mahoInterQualityConfigMahoQualityGsmRssi |
mahoQualityGsmRssi
[-110..-48]
Class Class 3
Value -96

Parameter mahoInterAcrConfigMahoQualityGsmRssi |
mahoQualityGsmRssi
[-110..-48]
Class Class 3
Value -96
Parameter mahoInterSbConfigMahoQualityGsmRssi |
mahoQualityGsmRssi
[-110..-48]
Class Class 3
Value -96
When all conditions are met, then HO is eligible to the target.

BSR then builds a list of eligible Macro 3G (resp. 2G) neighbours ranked using the
value of the parameter useForMobility (in the case of manually configured cells as
described in 3.1.3 and 3.1.4 respectively), EcNo (resp. RSSI) if available, else
RSCP.
Finally, depending on targetHOCS or targetHOCSPS or targetHOPS values (cf.

section 3.5.1), BSR triggers the handover to the best ranked eligible cell. If
relocation fails, a new attempt is made on the next eligible cell… until handover
succeeds or eligible cell list is empty. In such a case, handover to the other access
can be performed if fddPreferred or gsmPreferred is selected.
When both 2G and 3G or multiple layers on 3G are configured and there is a

preferred target, the BSR allows
mahoInterMeasurementConfig::mahoTimePreferred ms for the preferred target
to be reported when a non-preferred target is first reported.
Parameter mahoInterMeasurementConfigMahoTimePreferre
d | mahoTimePreferred
[0..10000]
Class Class 3
Value 1000
The periodic repetition time of the MAHO measurement report is defined by

mahoInterMeasurementConfig::mahoPeriodicRepTime.

Parameter mahoInterMeasurementConfigMahoPeriodicRepTi
me | mahoPeriodicRepTime
Class Class 3
mahoInterQualityConfig::mahoInterMaxTimeMeas,
mahoInterAcrConfig::mahoInterMaxTimeMeas and
mahoInterSbConfig::mahoInterMaxTimeMeas define the maximum time that
inter-freq/RAT MAHO measurements are enabled for the respective scenario.
When set to 0 there is no time limit.
Parameter mahoInterQualityConfigMahoInterMaxTimeMeas |
mahoInterMaxTimeMeas
[0..500]
Class Class 3
Value 120
Parameter mahoInterAcrConfigMahoInterMaxTimeMeas |
[0..500]
Class Class 3
Value 120

Parameter mahoInterSbConfigMahoInterMaxTimeMeas |
[0..500]
Class Class 3
Value 120
Following timer based CM deactivation; the minimum time between retries is

defined by mahoInterQualityConfig::mahoInterMinTimeRetry,
mahoInterAcrConfig::mahoInterMinTimeRetry and
mahoInterSbConfig::mahoInterMinTimeRetry. A setting of 0 means that no retry
is performed.
Parameter mahoInterQualityConfigMahoMinTimeRetry |
mahoMinTimeRetry
[0..200]
Class Class 3
Value 10
Parameter mahoInterAcrConfigMahoMinTimeRetry |
mahoMinTimeRetry
[0..200]
Class Class 3
Value 10
Parameter mahoInterSbConfigMahoMinTimeRetry |
mahoMinTimeRetry
[0..200]
Class Class 3
Value 10
Note: in order to perform inter-frequency measurements, the BSR supports

compressed mode on HSDPA and E-DCH. In case of major issues, it can be
disabled on E-DCH through the parameter cmEdchSupported.

Parameter cmEdchSupported
Object LCell
{True, False}
Class Class 3
Value true
3.5.3 BLIND HANDOVER
BSR supports Blind HO to Macro cell (either 3G or 2G) for CS, PS and CS+PS
calls due to radio degradation.
3.5.3.1 DETECTION RADIO DEGRADATION

Each time BSR detects the need for radio degradation assessment (i.e. when
targetHOCS or targetHOCSPS or targetHOPS are NOT set to disable), 2 Events
are configured at UE side, as per [3GPP_R02]:
• Radio is degrading: Event 2D is reported by UE when BSR CPICH Ec/No
or CPICH RSCP becomes below a certain threshold;
• Radio is back to normal: Event 2F is reported by UE when BSR CPICH
Ec/No or CPICH RSCP becomes above a certain threshold.
The following setting is used for Event 2D EcNo:
Parameter blindHO2d2fEcnoThreshold2d | Threshold2d

Object HO | blindHO2d2fEcno
[-24…0]
Class Class 3
Value -15

Parameter blindHO2d2fEcnoTimeToTrigger2d |
TimeToTrigger2d
Object Lcell | blindHO2d2fEcno
Range & Unit Enumerated (ms)
{timetotrigger0, timetotrigger10, timetotrigger20,
timetotrigger40, timetotrigger60, timetotrigger80,
timetotrigger5000}
Class Class 3
Parameter blindHO2d2fEcnoHysteresis2d | Hysteresis2d

Object Lcell | blindHO2d2fEcno
[0...14.5] step 0.5
Class Class 3
Value 2
The following setting is used for Event 2D RSCP:
Parameter blindHO2d2fRscpThreshold2d | Threshold2d

Object HO | blindHO2d2fRscp
[-115…-25]
Class Class 3
Value -110
Parameter blindHO2d2fRscpTimeToTrigger2d |
TimeToTrigger2d
Range & Unit Enumerated (ms)
timetotrigger5000}
Class Class 3

Parameter blindHO2d2fRscpHysteresis2d | Hysteresis2d
Object Lcell | blindHO2d2fRscp
[0...14.5] step 0.5
Class Class 3
Value 2
The following setting is used for Event 2F EcNo:
Parameter blindHO2d2fEcnoThreshold2f | Threshold2f

[-24…0]
Class Class 3
Value -15
Parameter blindHO2d2fEcnoTimeToTrigger2f |
TimeToTrigger2f
timetotrigger5000}
Class Class 3
Parameter blindHO2d2fEcnoHysteresis2f | Hysteresis2f

[0...14.5] step 0.5
Class Class 3
Value 2
The following setting is used for Event 2F RSCP:

Parameter blindHO2d2fRscpThreshold2f | Threshold2f
[-115…-25]
Class Class 3
Value -110
Parameter blindHO2d2fRscpTimeToTrigger2f |
TimeToTrigger2f
timetotrigger5000}
Class Class 3
Parameter blindHO2d2fRscpHysteresis2f | Hysteresis2f

[0...14.5] step 0.5
Class Class 3
Value 2

Once UE has reported an Event 2D, BSR tries to find an eligible target cell starting
from the Macro 3G and/or 2G neighbourhood built during auto-configuration and
self-optimisation steps (cf. section 3.1).
A Macro neighbouring cell is eligible to Blind handover if it fulfills the following

conditions:
• Frequency band is supported by UE
• Radio level (if previously determined by BSR) is above a certain threshold
o minBlindHoUmtsMacroEcNo and
minBlindHoUmtsMacroRSCP for Macro 3G;
o minBlindHoGsmMacroRSSI for Macro 2G.

Parameter minBlindHoUmtsMacroEcNo
Object Lcell
[0...49]
Class Class 3
Value 11
Parameter minBlindHoUmtsMacroRSCP
Object Lcell
[0...91]
Class Class 3
Value 5
Parameter minBlindHoGsmMacroRSSI
Object Lcell
[0...63]
Class Class 3
Value 9
The following formulas apply to get the real threshold:

• 3G EcNo: real_threshold [dB] = -24 + minBlindHoUmtsMacroEcNo / 2
• 3G RSCP: real_threshold [dBm] = -115 + minBlindHoUmtsMacroRSCP
• 2G RSSI: threshold [dBm] = -110 + minBlindHoGsmMacroRSSI
Engineering Recommendation: minBlindHoUmtsMacroEcNo
In case of reduced performances, setting the minBlindHoUmtsMacroEcNo to -24dB leads to

improvement.
Engineering Recommendation: minBlindHoGsmMacroRSSI
In case of reduced performances, setting the minBlindHoGsmMacroRSSI from -101dBm to -

96dBm could lead to some improvement.
BSR then builds a list of eligible Macro 3G (resp. 2G) neighbours ranked using the
value of the parameter useForMobility (in the case of manually configured cells as
described in 3.1.3 and 3.1.4 respectively), EcNo (resp. RSSI) if available, else
RSCP.

Finally, depending on targetHOCS or targetHOCSPS or targetHOPS values (cf.

section 3.5.1), BSR triggers the handover to the best ranked eligible cell. If
relocation fails, a new attempt is made on the next eligible cell… until handover
succeeds or eligible cell list is empty. In such a case, handover to the other access
can be performed if fddPreferred or gsmPreferred is selected.
3.6. BSR TO BSR HANDOVER

To avoid inter BSR handovers, one BSR can be assigned to the Group 0.
3.6.1 HANDOVER PRINCIPLE

The inter-BSR Femto handover algorithm is based on UE measurements of the
serving and neighboring BSR. The handover is triggered, when the quality of a
BSR neighbor cell is better than the current serving BSR by a certain hysteresis
value.
The handover procedure between BSRs is a hard handover procedure. The user
plane is interrupted during the switch over from the source to the target BSR.
The BSR supports handovers of:
¾ CS Voice calls
¾ PS calls (with single or multiple RABs) without Home Network Local
Routing used
¾ CS + PS call
Inter-BSR handover does not impact the core network either MSC or SGSN, i.e.
the handover procedure is performed locally within the BSR cluster. The control
plane is switched from the source BSR to the target BSR in the BSG. The CS user
plane is switched in the BVG. The PS user plane is switched in the BSR Packet
Gateway (BPG). Source and target BSRs must belong to the same BSR cluster
and be connected to the same BVG/BPG.
Restriction: BVG/BPG located on the Brick
In the case the BVG/BPG functionalities are located on the Brick, source and target BSRs must be
connected to the same Brick. The operator can provision the same Brick IP address to each Femto
in the group.
From BCR2.4 and the introduction of the FGW with BVG/BPG functionalities, the limitation is
removed.
Outgoing Handovers to other BSR are supported if

enableOutgoingFemtoHandover is set to true.

Incoming Handover from another BSR is supported if
enableInvomingFemtoHandover is set to true.
Engineering Recommendation: enableOutgoing/enableIncomingFemtoHandover
It is strongly recommended to keep both parameters on True to avoid inconsistencies when adding
one BSR to a femto Group.
Additionally, it is possible to activate or not, PS mobility between BSRs as shown in

Table 5 and Table 6.
Parameter enableOutgoingFemtoHandover
Object BSR Profile
{True, False}
Class Class 3
Value TRUE
Parameter enableIncomingFemtoHandover
Object BSR Profile
{True, False}
Class Class 3
Value TRUE
Parameter enableFemtoPsHandover
Object BSR Profile
{True, False}
Class Class 3
Value TRUE
enableOutgoingFemtoHandover enableFemtoPSHandover Resulting Mobilty

False False No Handover allowed
CS Handover possible
True False
PS Handover blocked
CS Voice and PS Handover
True True
possible
False True No Handover allowed
Table 5 - Feature activation on the source BSR


enableIncomingFemtoHandover enableFemtoPSHandover Resulting Mobilty

False True/False Handover is rejected
Handover is accepted
True True/False depending on available
resources
Table 6 - Feature activation on the target BSR
3.6.2 HANDOVER FAILURE

In case of handover failure with the selected target BSR, the source BSR will
maintain the call even if there are additional BSRs in the measurement report
which meet the criteria for attempting handover.
The UE will send a new measurement report at a later time if the condition persists
and the source BSR will then retry the handover to the best reported target cell to
which handover is permitted.
The parameter tInterFemtoHandoverGuard is a timer to postpone inter-BSR

handovers to target BSR for which the handover failed.
E.g. a UE that couldn’t handover to a BSR, will have to wait until this timer is
expired before being able to try again.
Parameter tInterFemtoHandoverGuard
Object BSR Profile
[1…120
Class Class 3
Value 30
In the case BSR::enableHandoverToNextBestCell = TRUE, the BSR will modify

the described process flow and try immediately after the Handover failure a
Handover to the next best target.
This assumes that the UE has got back to the source BSR.
The best target BSR will be determined as follow
¾ Any duplicate cell(s) with the identical PSC,
¾ The next best reported target cell PSC (if present in the Measurement
Report from the UE).
Note: When selecting the next best target cell from the measurement report, the
source BSR checks that the selected target cell is not equal to the active cell (UE
reports both target and active cell in the same list).

Parameter enableHandoverToNextBestCell
Object BSR Profile
{True, False}
Class Class 3
Value FALSE
3.6.3 MEASUREMENT CONTROL

IF BSR::enableOutgoingFemtoHandover = True, the parameters that are used in
the “Measurement Command” Message that is sent by the source BSR to set-up
the new event triggered intra-frequency measurements “e1c” are following:
• intrafrequencyFilterCoefficient: a filtering is performed by the UE before
UE event evaluation. It is also used for e2D and periodic Intra-Frequency.
• bSRToBSRReportingCriteria1c::reportingInterval: Indicates the interval
of periodical reporting when such reporting is triggered by an event.
Interval in milliseconds.
• bSRToBSRReportingCriteria1c::hysteresis: To limit the amount of
event-triggered reports, a hysteresis parameter may be connected with
each reporting event.
• bSRToBSRReportingCriteria1c::timetoTrigger: Indicates the period of
time during which the event condition has to be satisfied, before sending a
Measurement Report.
The quantity that is measured by the UE for triggering the e1c event is the CPICH
Ec/N0. A neighbour cell is reported when the filtered neighbour cell CPICH Ec/N0
is greater than the serving femto CPICH Ec/N0+ Hysteresis/2 for a period of
timeToTrigger.
Engineering Recommendation: Compromise to avoid ping-pong and drop call
Hysteresis and timeToTrigger are to be chosen carfully.

Setting them too short could result in UEs ping-ponging between two BSRs.
Configuring them too long could results in handovers being triggered later possibly leading to UEs
running out of the BSR coverage and dropping their calls.

Parameter intrafrequencyFilterCoefficient
Object Lcell
coeff19=19 }
Class Class 3
Value coeff4
Parameter bSRToBSRReportingCriteria1ctimetoTrigger |
timetoTrigger
Object Lcell | bSRToBSRReportingCriteria1c
Class Class 3
Parameter bSRToBSRReportingCriteria1chysteresis |
hysteresis
[0,0.5.. 7.5]
Class Class 3
Value 4

Parameter bSRToBSRReportingCriteria1creportingInterval |
reportingInterval
Class Class 3
3.6.4 HANDOVER EXECUTION

Following points are describing the procedure followed during the inter-BSR
handover:
1. The UE establishes a CS call in the source BSR and configures an intra-
Frequency event 1C measurement to support inter-BSR Handover
2. The UE sends a measurement report for event 1C indicating the primary
CPICH for a target BSR is better than the primary CPICH of the source
BSR. The source BSR will determine the target BSR and will then trigger
the handover from source to target BSR, if
BSR(target)::enableIncomingFemtoHandover = True. If not, a
Handover failure is reported.
3. If the UE also has a PS connection, it will be released towards the SGSN
and the UE.
4. The source BSR initiates the hard handover procedure by sending BSR
Handover Request to the target BSR, the message will contain
information on the current RRC connection and CS RAB established
between the source BSR and UE.

Restriction: InterBSR Communication
Configuring this communication is a must for Handovers. Therefore only BSR that are allowed to
communicate to each other (see chapter 3.1.5.2) can be considered for handovers.
5. The target BSR performs call admission control, allocates the resources
for the CS call and prepares the air interface for the incoming handover.
The target BSR includes the Radio Bearer Reconfiguration message in
the BSR Handover Request Acknowledge message that is sent to the
source BSR.
6. The source BSR sends the RRC Radio Bearer Reconfiguration message
received from the target BSR to the UE.
7. After the source BSR has received an indication of the successful
transmission of the RRC message to the UE, it passes the latest
signaling and user plane information to the targetBSR.
8. The target BSR completes the final signaling configuration. The target
BSR completes the user plane configuration and inform the the BVG to
switch the user plan in the BVG from the source to the target BSR.
9. UE and target BSR have synchronized on the Air interface.
10. The UE sends RRC Radio Bearer Reconfiguration Complete message.
The UE has completed the handover procedure and the RRC
connection is now established with the target BSR.
11. The target BSR sends a request to the BSG to switch the signaling plane
from the source to the target BSR. The BSG will release the stream
allocated to the source BSR.
12. The Target BSR sends a Release message to the source BSR to indicate
that it can release the UE Context.
13. The UE context and all associated radio resources are released on the
source BSR and the source forwards all messages received during the
handover phase to the target BSR.
14. The target BSR processes all messages from the source BSR before
processing any additional messages received directly.
3.6.5 HANDOVER EXECUTION CONSIDERING SFN OFFSET

In the case BSR::enableTimingMeasurements = TRUE, the BSR will calculate an
offset as described in 3.1.5.5.
This offset will then be used through two possible algorithms to support the
selection of the target BSR in the case of BSR to BSR Handovers.

3.6.5.1 ALGORITHM 1
The first algorithm is described as follow:
¾ Always use timing information to determine whether to perform handover.
¾ Reject requests to handover when the timing information reported by the
UE is outside range.
The range is defined through the use of the parameter BSR::timingMargin as

[SFNOffset - timingMargin x 3840 .. SFNOffset + timingMargin x 3840], where
3840 is the number of chips per ms.
Note: The value for the SFNOffsets are calculated mod 9830400.
Parameter timingMargin
Object BSR Profile
[0..2560]
Class Class 3
Value 100
This method is more efficient in scenarios where the sniffer is not able to detect
other BSR, which the UE is able to.
As this method only relies on the SFN information and accuracy, in the case of
drifts, the BSR may not trigger a handover where it should have.
Algorithm 1 is selected when timingMargin is not set to 2560.
3.6.5.2 ALGORITHM 2
The second algorithm is described as follow:
¾ Use timing information to assist on which cell to try first
¾ But if it fails to handover first time, then try all other cells in the neighbour
list on the same PSC without rejecting any due to timing.
In order to use Algorithm 2, the parameter timingMargin has to be set to 2560
(maximum value) which implies that any BSR will pass the timing check.

When BSR::enableTimingMeasurements = TRUE, and a UE is reporting an
Handover Measurement Report Message, the BSR will go through following steps:

1. The BSR will search for all possible BSR targets that have the reported
PSC and determine their corresponding SFNOffset.
2. The BSR will calculate a SFNOffsetUE based on information reported by
the UE in its measurements control. [3GPP_R15] provides more
information on the data that are reported by the UE.
3. The SFNOffsetUE is then checked against the range defined through
timingMargin.
a. If there are no matches, the handover will not be attempted for this
PSC.
b. If there is one match, the BSR will attempt to handover only to that
cell. If handover fails, the BSR will not retry on another cell for this
PSC.
c. If there are multiple matches, the BSR will attempt to handover to
the closest match first. If that fails and
BSR::enableHandoverToNextBestCell = TRUE, the BSR will
attempt handover to the next closest match until a successful
handover occurs or there are no more matches, otherwise the
BSR will wait until it receives the next measurement report.
4. If the parameter isUEmeasReportUsedToUpdateTiming=TRUE,
following a successful handover to a new BSR, the source BSR will update
the SFNOffset for the target BSR with SFNOffsetUE.
5. In the case the handover ultimately fails, the BSR traces a warning for the
UE.
Note : In the case the UE is reporting multiple cells on different PSC of acceptable
quality and if BSR::enableHandoverToNextBestCell = TRUE, the algorithm shall
be rerun for a different PSC if failure occurs on one PSC.
Parameter isUEmeasReportUsedToUpdateTiming
Object BSR Profile
{True, False}
Class Class 3
Value FALSE

Engineering Recommendation: Avoiding rejections of HO requests due to timing checks
When BSR::enableTimingMeasurements is set to TRUE, the following parameter configuration is

recommended to avoid call drops due to inter-BSR handovers not being triggered:
BSR::timingMargin = 2560,
BSR::isUEmeasReportUsedToUpdateTiming = TRUE,
BSR::enableHandoverToNextBestCell = TRUE.
3.6.6 TARGET CELL PROTECTION (INTERFERENCE

REDUCTION)
3.6.6.1 MOTIVATION
If a PS call with high UL data rate cannot be handed over, the UL power would be
increased to maintain the call as long as possible in the source cell and thus the
interference increases on neighboring cells. For example, if a user transmitting at
1.4 MBit/s on E-DCH moves into the coverage area of a neighbor BSR and
handover is not performed, it might swamp the receiver of the neighbor BSR. Calls
of other UEs on the neighbor BSR might be disrupted.
In order to avoid this, the standalone PS call will be released. In case of a CS+PS
call the UL data rate of the RABs is reduced to 64 kbit/s.
After the PS call has been released and no data needs to be transferred, it is
expected that the UE performs cell reselection to a better neighbor cell. Otherwise
it is very likely that the UE will re-establish the call in the source cell again. It is
tried to avoid this by adding the target cell to the active set before the PS call is
released. The UE might then select the target cell when moving from connected
mode to Idle mode.
If the UE selects the source BSR again, it will reject the RRC connection request
with a wait time to give the UE time to reselect a better neighbor cell.
3.6.6.2 FAILED HANDOVER OF A PS CALL

If the handover of a PS call to all target cells has failed or measurement report
event 1C is received but no handover attempt is triggered because timer
tInterFemtoHandoverGuard is running for all reported target BSRs are barred
targets or because all PS RABs are using HNLR, the source BSR shall release the
PS call if the following conditions are fulfilled:
¾ The UE has no CS RAB established.
¾ The Inter-BSR interference detection criterion is fulfilled.

Rule: Inter-BSR interference detection
The source BSR takes measures to reduce the interference in target cells, if the RSCP
measurements received in the measurement report event 1C fulfills the following condition:
CPICH RSCP (target cell) - CPICH RSCP (source cell) <= psInterferenceThreshold
If the UE has reported multiple target cells in event 1C, the highest CPICH RSCP value out of the
target cell measurements shall be taken.
If a PS call must be released due to handover failure, the source BSR sends an
RRC Active Set Update message to the UE in order to add the best reported target
PSC to the AS. The response from the UE is supervised by a procedure timer of 5
seconds.
On receipt of the Active Set Update Complete or Active Set Update Failure
message or procedure timer expiry the source BSR initiates the release of the PS
call.
Note: The aim of the AS update is to fulfill TS 25.304, 5.2.7.1. When returning to
idle mode from connected mode, the UE will select a suitable cell to camp on.
Candidate cells for this selection are the cell(s) used immediately before leaving
connected mode.
If a PS call must be released due to handover failure, the BSR releases the
connection towards the SGSN with cause "Release due to UTRAN Generated
Reason" and the RRC connection with cause “normal release”.
The BSR stores the initial UE identity of the released RRC connection for 15s. The
BSR is able to store up to 20 UE identities, overwriting the oldest entry when the
maximum number of entries is exceeded.
When the BSR receives a RRC Connection Request message with a stored initial
UE identity and the establishment cause is not "Originating Conversational Call",
"Terminating Conversational Call" or "Emergency Call", the BSR rejects the RRC
connection request with the cause “unspecified” and the configured wait time
(waitTimeForFailedPsHandover). Otherwise the RRC connection Request is
accepted. In both cases the stored initial UE identity is deleted.
Note: The storage of the initial UE Identity is already applied for access control.

Parameter psInterferenceThreshold
Object BSR Profile
[0..91]
Class Class 3
Value 10
Parameter waitTimeForFailedPsHandover
Object BSR Profile
[0..15]
Class Class 3
Value 8
3.6.6.3 FAILED HANDOVER OF A CS+PS CALL

If the handover of a CS+PS call has failed to all target cells, the source BSR shall
check the following conditions:
¾ The UE has a CS RAB established.
¾ The UE has a PS RAB established
¾ The Inter-BSR interference detection criterion is fulfilled.
¾ The uplink DCH data rate of the UE is greater than 64kbit/s or the UE is on
E-DCH.
If all of the above conditions are fulfilled and the UE uses DCH in UL, the source
BSR reconfigures the UL DCH data rate to 64kbit/s for the duration of the CS call.
If all of the above conditions are fulfilled and the UE uses E-DCH in UL, the source
BSR reduces the E-DCH uplink data rate for the duration of the CS call by
performing a Radio Link Reconfiguration to L1 limiting the E-DCH Maximum Bitrate
to 64kbps.
Note: After the CS call has been released and the UE is still in the handover
region, the release procedure for the PS call will be performed when a new 1c
event comes in and the criterion according to 3.6.6.2.

3.7. PRESENCE INDICATOR

The BSR proposes several methods to inform an end user that it entered into its
coverage.
3.7.1 MOBILITY MESSAGE

This method is relying on the use of the Mobility Messages that can be sent by the
MSC or the SGSN in the NAS Message while LAU or RAU.
When a Mobility Message reaches the BSR during a LAU or RAU, the BSR will
modify the values of the IE “Full name for network” and IE “Short name for
network” based on following rules:
• In the case LCell::AreaSelectNormalFlag = “off”,
o IE “Full name for network”= BSR::fullnameofNetwork
o IE “Short name for network”= BSR::shortnameofNetwork
• In the case LCell::AreaSelectNormalFlag is different from “off” and the
UE is classified as “owner” (IMSI is in the femtoACLlist),
o IE “Full name for network”= BSR::fullnameofNetwork
o IE “Short name for network”= BSR::shortnameofNetwork
UE is classified as “guest” (IMSI is in the femtoACLlistguest),
o IE “Full name for network” = BSR::fullnameofNetwork2
o IE “Short name for network”= BSR::shortnameofNetwork2

UE is classified as “public” (IMSI not in the femtoACLlist , nor the
femtoACLlistguest and AccessMode=SemiOpenAccess)
UE is classified as “public” (AccessMode=Open)
If the Mobility Message (MM) or the GPRS Mobility Message (GMM) do not contain
the IE “Full name for network” or IE “Short name for network”,

o In the case BSR::addNetworkNameIEToMMInfo = “False” the BSR shall
not modify or add the corresponding IEs in the MM/GMM Information
message.
o In the case BSR::addNetworkNameIEToMMInfo = “True” and
BSR::fullnameofNetwork or BSR::shortnameofNetwork are populated,
the BSR shall add the IE “Full name for network” and/or IE “Short name for
network” (if configured) to the MM/GMM Information message even if not
received from the CN.
o In the case BSR::addNetworkNameIEToMMInfo = “True” and
BSR::fullnameofNetwork or BSR::shortnameofNetwork are not
populated, the BSR shall not modify or add the corresponding IEs in the
MM/GMM Information message.
The BSR shall populate the coding scheme and the text string in the IEs “Full
name for network” and “Short name for network” of the MM/GMM Information
message according to the coding scheme configured in BSR::codingScheme
The UE will then receiving this message, display either the full or short name (this
is very UE dependent).
Parameter addNetworkNameIEToMMInfo
Object BSR Profile
{True, False}
Class Class 3
Value FALSE
Parameter fullnameofNetwork
Object BSR Profile
[Maxlength 255]
Class Class 3
Value -
Parameter shortnameofNetwork
Object BSR Profile
[Maxlength 255]
Class Class 3
Value -

Parameter fullnameofNetwork2
Object BSR Profile
[Maxlength 255]
Class Class 3
Value -
Parameter shortnameofNetwork2
Object BSR Profile
[Maxlength 255]
Class Class 3
Value -
Parameter fullnameofNetwork3
Object BSR Profile
[Maxlength 255]
Class Class 3
Value -
Parameter shortnameofNetwork3
Object BSR Profile
[Maxlength 255]
Class Class 3
Value -
Parameter codingScheme
Object BSR Profile
{0,1}
Class Class 3
Value 0
Note: if codingScheme = 0, then the GSM default character set is used

if codingScheme = 1, then the UCS-2 character set is used. This set is not fully
supported by all UEs.

3.7.2 DEDICATED BSR PLMN
Another possibility to inform the end user is to allocate to the BSR network a
specific PLMN that is different to the Macro PLMN. The Operator could then insert
a new name associated to this PLMN on the IMSI provided to the enduser that
would show the naming specific for the BSR network.
In this case, the operator needs to ensure that the different PLMNs are provided in
the BSR (see chapter 3.1.2) and that the proper configuration changes have been
performed in the CN to allow the mobility of the users.
3.7.3 TONE GENERATION DURING VOICE CALL SETUP

The feature is switched on/off using the parameter activateUserTone.
When a user originates a CS voice call on the BSR a distinctive tone will be
provided, during the call set-up period, to provide audible notification that the call is
being served by the BSR.
The tone is defined on the BSR in a data file provided by the operator. It can be up
to 3s long.
All characteristics of the tone perceived by the user is determined by the process
that the network operator uses to generate this file. The BSR does not contain any
AMR Codec.
The mode of playing the tone is configurable through the parameter
userToneControl (N times, or continuous).
userToneProgressIndicator defines the Progress Indicator ( [3GPP_R05]) value
to be generated by the BSR, when playing a tone to the UE.
The parameter userTonePrecedance allows to switch the originating source of the
tone between a tone coming from the BSR and the network.
Parameter activateUserTone
Object Femto | BSR
{True, False}
Class Class 3
Value False

Parameter userToneControl
[0…100]
Class Class 3
Value 0
Parameter userToneProgressIndicator
Range & Unit enum Pivalue
{pi1=1, pi8=8}
Class Class 3
Value pi8
Parameter userTonePrecedance
Range & Unit enum TonePrecedance
{femto=0, network=1}
Class Class 3
Value femto
3.7.4 MM/GMM INFO GENERATION FROM FEMTO

The BSR coverage indication can be provided to a UE modifying in the BSR the
Name of Network Field contained in MM/GMM information messages sent by the
Core Network to the UE.
However, that solution is dependent upon the CN sending a MM/GMM information
message which can be intercepted by the BSR Network and these messages are
not supported in all networks.
The feature “MM/GMM Info Generation from Femto” will allow the BSR to generate
autonomously the BSR Network Indicator to the UE during the Location Area
Update and / or Routing Area Update (e.g. after registration, attach…). This feature
relies on the provisioning of the network full or short names (see 3.7.1).
To enable the feature, the parameter BSR::generateNameOfNetwork has to be

set to a value within {“full”, “short”, “fullAndShort”}.
To disable the feature, the parameter BSR::generateNameOfNetwork is to be set
to “disabled”.
It is possible to add a country indication to the BSR network name setting the
parameter BSR:: networkNameAddCI=TRUE.

If neither the "Full name for network" nor "Short name for network" parameters are
provisioned, then the BSR does not send the message.
Note: Depending on the user type (owner or guest), the corresponding network
names will be used (see 3.7.1).
Parameter generateNameOfNetwork
Object BSR Profile
Range & Unit enum
{disabled=0,
full=1,
short=2,
fullAndShort=3}
Class Class 3
Value disabled
Parameter networkNameAddCI
Object BSR Profile
{True, False}
Class Class 3
Value FALSE
Restriction: Impact of the Macro Configuration
If the Macro network is not provisioned to generate the network name identifier then it is mandatory
to deploy the BSR network on a different PLMN Identity than the Macro network.
This is essential to ensure that in case the Macro network is not able to provide its own network
identifier for the PLMN, that an incorrect indication of BSR coverage is not shown when the UE
relocates from the BSR to the Macro network.
Restriction: Deployment Limitations
This feature should only be deployed on a cluster basis and should not be restricted to specific
BSRs within the cluster to ensure that if a UE moves from a BSR where the Coverage Indicator was
generated to one where the Coverage Indicator was not generated the UE would not continue to
display the Coverage Indicator of the previous BSR.
Engineering Recommendation: Interworking with CN Identification
This feature should not be enabled when the CN has been provisioned to send NAS MM
Information or GMM Information messages to the BSR Network. In that case the functionality to
modify the information in the MM and GMM Information should be used instead.

4. INDEXES
4.1. TABLE INDEX

Table 1 - 3GPP specific cause values for mobility management ( [3GPP_R05])............................. 45
Table 2 - UE power Class vs. maximum output power .................................................................... 48
Table 3 - Maximum output power for GSM mobiles......................................................................... 64
Table 4 - Mapping for qHcs .............................................................................................................. 74
Table 5 - Feature activation on the source BSR ............................................................................ 110
Table 6 - Feature activation on the target BSR.............................................................................. 111
4.2. FIGURE INDEX

Figure 1 - HCS Example .................................................................................................................... 8
Figure 2 –Scenario with Dense re-use PSC .................................................................................... 39
Figure 3 - Decision thresholds for Measurement ............................................................................. 54
Figure 4 - HCS Priority and HMD ..................................................................................................... 57
Figure 5 - Decision thresholds for Measurement when high-mobility is NOT detected ................... 58
Figure 6 - Decision thresholds for Measurement when high-mobility is detected............................ 59
Figure 7 - Applying tempOffset on Hn when hcsPrio,n <> hcsPrio,s ............................................... 71
Figure 8 – Compressed Mode.......................................................................................................... 83

Z END OF DOCUMENT Y


VOLUME 6 INCOMING MOBILITY

CONTENT OF VOLUME 6
1. INTRODUCTION............................................................................................................................3
1.1. OBJECT....................................................................................................................................3

2.1. FPUG VOLUMES ......................................................................................................................3
3. INTRODUCTION - PLURALITY OF TARGET FEMTOS ..............................................................5
4. INCOMING HANDOVER ...............................................................................................................6

4.1. HANDOVER TRIGGER ................................................................................................................6
4.2. INCOMING SERVICE TYPE SUPPORTED FOR HANDOVER ..............................................................6
4.3. TARGET SELECTION – PSC AMBIGUITY .....................................................................................6
4.3.1 Closed vs Open Access BSR .........................................................................................7
4.3.2 Prioritized Open Access BSR .........................................................................................7
4.3.3 BSR with Incoming Mobility Activated vs BSR w/o.........................................................8
4.3.4 Constraints on the PSC Lists due to incoming Mobility ..................................................8
4.4. CONSTRAINTS ON PSC / BSG COMING DUE TO RNC ID ...........................................................9
4.5. IMPACT ON MACRO PERFORMANCE ...........................................................................................9
4.6. CLOSED ACCESS MODE FILTERING AT THE BSG .....................................................................10
4.6.1 Feature activation..........................................................................................................10
4.6.2 Neighbour Configuration at BSG Level.........................................................................11
4.6.2.1 Constraints ................................................................................................................11
4.6.2.2 Basic Cell ID Mapping ...............................................................................................11
4.6.2.2.1 BSG Configuration ....................................................................................................11
4.6.2.2.2 Macro Configuration ..................................................................................................12
4.6.2.2.3 Pros and Cons...........................................................................................................12
4.6.2.3 Virtual Cell ID.............................................................................................................13
4.6.2.3.2 BSR Configuration.....................................................................................................14
4.6.2.3.4 Pros and Cons...........................................................................................................15
4.6.2.4 Enhanced Cell ID Mapping........................................................................................15
4.6.2.4.4 Pros and Cons...........................................................................................................20
4.6.2.5 Macro like Cell ID Mapping .......................................................................................21
4.6.2.5.4 Pros and Cons...........................................................................................................21
4.6.2.6 Cell ID Mask ..............................................................................................................22
4.6.2.7 Maximum number of definable External Cells...........................................................24
4.6.3 Filtering At BSG LEvel ..................................................................................................24
4.6.4 Enhanced BSR Filtering:...............................................................................................25

4.6.5 Maximum Number of Target BSRs ...............................................................................27
4.6.6 Handover Black List ......................................................................................................28
4.6.7 Prioritization of target BSRs..........................................................................................29
4.6.8 Relocation Reject Causes.............................................................................................29
4.7. OPEN ACCESS MODE .............................................................................................................31
4.7.1 BSG Configuration ........................................................................................................31
4.7.1.1 Feature activation ......................................................................................................31
4.7.1.2 Neighbour Configuration at BSG Level .....................................................................32
4.8. INCOMING MOBILITY ON THE BSR............................................................................................32
4.8.1 Allowing Incoming Mobility............................................................................................32
4.8.2 Incoming Handover from Macro....................................................................................33
4.8.3 Failure cases.................................................................................................................34
4.8.3.1 RANAP Failure Causes.............................................................................................34
4.8.3.2 Relocation Complete Failure .....................................................................................35
4.8.3.3 Relocation Cancel .....................................................................................................35
4.8.3.4 Handover Complete Failure ......................................................................................36
4.8.4 UE Registration for (semi-)Open Access BSR .............................................................36
5. INDEXES .....................................................................................................................................37
5.1. TABLE INDEX ..........................................................................................................................37
5.2. FIGURE INDEX ........................................................................................................................37

1. INTRODUCTION
1.1. OBJECT
This volume is dedicated to Features and Parameters related to incoming Mobility.
Information on the configuration of the BSR Network are provided as well as
recommendations on the update on the 3G or 2G Macro side.
2.1. FPUG VOLUMES


[Vol. 10] HSxPA

specification


reception (FDD)
specification

[3GPP_R14] 3GPP TS 25.101 User Equipment (UE) radio transmission and
reception (FDD)
[3GPP_R15] 3GPP TS 25.413 Radio Access Network Application Part (RANAP)
signalling


3. INTRODUCTION - PLURALITY OF TARGET FEMTOS
The deployment of BSR is strongly end-customer steered. The operator may not
have the ability to choose the installation location especially for Home BSRs.
Figure 1 presents a typical BSR deployment. In that picture, under the coverage
area of 2 (GSM or UMTS) Macro cells, several BSRs are deployed. The colors
indicate the PSCs that have been picked by the BSRs during the autoconfiguration
/ self-optimization phases.
At Macro level, the PSC of a neighbour cell is usually sufficient to identify uniquely
a cell. The RF Design Engineering team are providing besides the PSC plans also
with the neighbour definition containing the PSCs and the corresponding cell-Id for
the different cells in the networks.
In the case of the BSR, this is not the case anymore. Not only will there be many
possible BSR neighbours within a given Macro area sharing the same PSCs, but
also the mapping PSC – Cell ID is not static anymore (due to the autoconfiguration/
self-optimization capabilities on boards of BSRs). Finally, the very high number of
BSRs that can be deployed will exceed the limits of the Macro OAM in terms of
neighbour definition.
Femto Cells
................. BSR100
Figure 1 - Typical BSR Deployment
All these result in the need to update the outgoing Macro mobility strategy moving
away from an explicit neighbour definition with a direct PSC-CellID mapping to a
more generic approach. This will rely on defining only the mandatory parameters
keeping as many parameters as possible on generic values.
The following chapters will present the strategy and configuration that are
supported by the BSR and the corresponding updates on the Macro sides to
ensure successful Handovers.
From Rel-9, UEs could be CSG capable. As a part of the home Node B standards,
such UEs have the ability (optional) to measure and report the real Cell ID of a
neighbour cell. This is not possible on legacy UEs, and therefore is not a near term
solution.

4. INCOMING HANDOVER
4.1. HANDOVER TRIGGER

Similar to the UTRAN strategy, the measurements in the UE in the case of BSR
deployment should only be triggered when the signal (Ec/No for 3G Macro, RXLev
for GSM) of the serving macro is degraded.
This is to avoid permanent measurements of the BSR frequency and the resulting
performance degradation in the macro network.
In an intra-Frequency case, it is very likely that a slight degradation will occur
naturally as the UE approaches the BSR, just like NodeBs interfering at their cell
edge.
In an inter-frequency case (either 3G or GSM), it will be less prone to rapid quality
degradation as the BSR is on a separate channel. In such cases, UE may only be
entering Compressed Mode and a Handover triggered when reaching the cell edge
(at the furthest distance of the NodeB or due to higher losses such as in-building
ones).
In many cases, and especially at locations where the Macro has good to very good
signal, UEs will never enter CM. This will result in no handover being triggered and
no Macro to BSR mobility.
As a Macro cell is not aware of ACL information, it will blindly attempt to relocate
any UE triggering a report of a BSR. Successful or not, these will then result in an
increased Macro and CN signaling load.
4.2. INCOMING SERVICE TYPE SUPPORTED FOR HANDOVER

Incoming CS, PS and CS+PS Handover are supported.
Inter-Release Delta: Feature 101684 - 3G Macro to Femto PS and CS+PS Handover
From BCR 3.0, incoming PS and CS+PS Handovers are supported.
4.3. TARGET SELECTION – PSC AMBIGUITY

Once a Handover has been triggered, the system will need to identify the target
BSR the UE is to be handed over to. As described in chapter 3, the plurality of the
BSRs sharing the same PSCs within the coverage area of a Macro cell implies the
need to complete the existing identification methods defined by 3GPP.

Considering the scenario depicted in Figure 1 where each colour represents a
different BSR PSC, each BSR choosing its PSC out of 6 possible and a UE moving
towards BSR100 with a Red PSC.
The Macro cell RNC will map the PSC reported by the UE in its Measurement
Report message to the corresponding Cell-ID defined in the neighbour list.
It will then trigger a relocation to the MSC or SGSN which is then routed to the
BSR Cluster and reaches the BSG. The BSG, receiving the Relocation Request
will have to map the request to a specific BSR.
Due to the fact that the BSG may have a huge number of BSR defined, e.g. 60000
units, the incoming Cell-ID would match roughly 10000 BSRs (6PSCs /
60000CPE).
Alcatel-Lucent proposes different methods to ensure the best possible identification

of the target BSR. The following chapters will describe the methods for different
BSR access types.
4.3.1 CLOSED VS OPEN ACCESS BSR

For Closed Access BSRs, the BSG will be able to narrow the list down further
based upon the IMSIs matching the Access Class List (ACL) of each Femto.
When UEs are registered across multiple Femtos, the BSG may still have more
than one match, but the list will be considerably reduced.
In open access, there is no ACL, so the problem remains of filtering down on all
open access Femtos in a cluster as to which one is the correct one. This will
require some additional PSCs to be set aside for open access as well as some
further encoding on Cell ID.
Engineering Recommendation: PSC Lists for different Access Types
To be able to differentiate Open Access BSRs from Closed Access ones in the case of incoming
Mobility, it is mandatory that the PSC lists are different.
4.3.2 PRIORITIZED OPEN ACCESS BSR

Prioritized Open Access BSRs will be handled as Open or Closed Access BSRs,
depending on the PSCs that are allowed.
In the case the Prioritized Open Access BSR is configured to used Open Access
PSCs, the target BSR selection for Open Access BSR will be used.

In the case the Prioritized Open Access BSR is configured to used Closed Access
PSCs, the target BSR selection for Closed Access BSR will be used. This will
result in the fact that only IMSI declared in the ACL (owner or guest) will be allowed
to hand in the BSR, irrespectively of any other configuration.
4.3.3 BSR WITH INCOMING MOBILITY ACTIVATED VS BSR W/O

In the case BSRs with incoming Mobility activated are deployed with other where
such type of mobility is not allowed, a further issue may occur.
Indeed, a UE moving towards the coverage area of a BSR which does not allow
incoming mobility for the UE, may trigger a Handover, reporting the PSC to its
sRNC. This will then forward the message as described above to the BSG.
In the best case, the BSG will not find any target BSR, because the IMSI is in none
of the ACL for Closed access BSRs. There will be an error in the relocation.
In the worst case, the BSG would find a BSR that maps all the criterias (for
instance if the IMSI is in several closed access mode BSR, some having the
incoming mobility activated. The sRNC will then try to handover the call, which will
fail due to a wrong BSR identification and a resulting degradation of the Macro
network performances (either Handover failure or even drop calls).
Engineering Recommendation: PSC Lists for different inHO BSR configurations
To be able to differentiate between BSR with incoming Mobility Activated and not, , it is mandatory
that the PSC lists are different.
4.3.4 CONSTRAINTS ON THE PSC LISTS DUE TO INCOMING

MOBILITY
When incoming Mobility is introduced, as presented in the previous chapters, the
PSC lists allocated to BSRs will have to be redesigned and possibly extended.
Following scenarios will require different PSC lists without overlapping:

¾ Closed Access BSR with incoming Mobility Activated
¾ Closed Access BSR with incoming Mobility not Activated
¾ Open Access BSR with incoming Mobility Activated

¾ Open Access BSR with incoming Mobility not Activated (Could share the
same PSC as Closed Access BSR with incoming Mobility not Activated)

4.4. CONSTRAINTS ON PSC / BSG COMING DUE TO RNC ID
In the SRNS relocation message send by the source RNC, the target RNC Id is
mentioned besides the target cell ID.
This implies that PSCs for different clusters are to be different in order to
differentiate BSRs from different clusters and the targeted BSG in border areas.
In the BSR clusters border areas, the Macro cells will therefore be updated to
support the neighbours from both clusters.
4.5. IMPACT ON MACRO PERFORMANCE

The ambiguity to determine the target BSR that is being reported by a UE can lead
to performances degradation on the Macro Network side.
In the case, it is not possible to identify a possible target or if there are too many
targets, the BSR Cluster will return a RANAP relocation reject message. The
handover procedure will be stopped and the related metrics in the Macro side
degraded. If the UE does not move forward, this situation would repeat and a
strong KPI degradation on Macro side will be monitored. The call would be
maintained on the macro side.
In other case, where targets are identified, but they are not the one the UE is
approaching, the Handover Procedure will start, but will eventually fail because of
the ambiguity of the target cells.
As this handover type is a Hard Handover with SRNS relocation, a short
interruption in the User Plane will be noticeable.
Once the UE comes back to the Macro, it could reinitiate a handover procedure,
which may again fail. This would again create a short interruption time in the user
plane.
This scenario could repeat until the BSR the UE is measuring is found or the UE
moves to another location.
As seen, in such conditions, the repetition of the interruptions in the user plane will
lead to strong voice quality degradation.
Finally, some troubles may occur on the macro with regard to soft handover (SHO).
Indeed, the macro compound neighbouring will have to deal with multiple BSRs
with the same PSC but different Cell IDs.

Engineering Recommendation: Activation of incoming Handover
It is therefore strongly recommended not to activate incoming Handover in a general manner on the
complete network, but only where it is mandatory.
4.6. CLOSED ACCESS MODE FILTERING AT THE BSG

As it has been seen in the previous chapters, the most critical phase of the
incoming Handover procedure is the identification of the target BSR.
The BSG will be the central NE in this process and almost all the configuration will
take place in that part of the network.
The BSR itself will only have to accept/reject the incoming call and will require only
little configurations.

At BSG level, the incoming handover from either GSM or UMTS is to be activated
to allow the incoming mobility for the closed access mode BSRs in the cluster.
Incoming PS handover is to be specifically activated.
Following parameters are used:
¾ For Handover from GSM to Closed Access BSR:

hoFromGsmMacroEnabledClosedAccess
¾ For Handover from UMTS to Closed Access BSR:
hoFromUmtsMacroEnabledClosedAccess
¾ For PS Handover from UMTS to BSR:
psHoFromUmtsMacroEnabled
Parameter hoFromGsmMacroEnabledClosedAccess
Object BSG
Granularity FGWConfig | BSG
{True, False}
Class 3
Value FALSE
Parameter hoFromUmtsMacroEnabledClosedAccess
Object BSG
{True, False}
Class 3
Value FALSE

Parameter psHoFromUmtsMacroEnabled
Object BSG
{True, False}
Class 3
Value FALSE
4.6.2 NEIGHBOUR CONFIGURATION AT BSG LEVEL

Alcatel-Lucent proposes different methods and features to add information in the
Cell ID that is reported in the RANAP relocation request message to narrow down
the possible target BSRs.
4.6.2.1 CONSTRAINTS
The provisioning presented in the following sections concerns the BSG, Macro
cells and BSR. The consistency between the macro and the BSG provisioning
must be ensured for all macro cells under the BSG cluster from which incoming HO
can be triggered.
4.6.2.2 BASIC CELL ID MAPPING
4.6.2.2.1 BSG CONFIGURATION

This method is the simplest one and relies on a direct mapping Cell Id vs PSC.
A mapping table has to be defined in the BSG to allow the mapping Cell ID vs BSR
PSC using the parameter bsrPSCforBasicCellId
This should reflect the mapping that has been / is configured at Macro Level for the
Closed Access PSCs.
bsrPSCforBasicCellId::id will be the Cell ID to use in the Macro and should
match the bsrPSCforBasicCellId::psc.
Restriction: Cell ID Range
The Cell Id range from 0 to 15 (Four least significant bits of the bsrPSCforBasicCellId) is
available.

Parameter bsrPSCforBasicCellId
Object BSG
Granularity BSG
Range & Unit sequence [0..128] of struct BsrPSCforBasicCellId
Class 3
Value 0
Parameter index
Object BsrPSCforBasicCellId
Granularity BsrPSCforBasicCellId
[0..127]
Class 3
Value -
Parameter psc
Object BsrPSCforBasicCellId
Granularity BsrPSCforBasicCellId
[-1..511]
Class 3
Value -
Note: The setting -1 indicates no PSC mapping
4.6.2.2.2 MACRO CONFIGURATION

In order to allow the BSG to filter the BSR and reduce as much as possible the list
of targets, the reverse mapping table has to be defined in at Macro level.
This should allow the RNC to convert the PSC that is reported in the Measurement
Report Message from the UE into a Cell-ID that will be transmitted to the BSG in
the RANAP Relocation Request message.
The mapping is done while defining the Cell-ID for the BSR Neighbours at Macro
level, where the values for Cell-ID and PSC are to be set according to the ones
defined in the BSG.
The corresponding neighbors should then be entered in the possible Handover
neighbourlists.
4.6.2.2.3 PROS AND CONS

This method is very easy to put in place in the Macro network, where only as many
BSR neighbours as the number of PSCs will have to be defined. These can then
be configured for each Macro Cell (2G or 3G) using scripts.

Unfortunately, it may not provide sufficient information to allow a narrow filtering of

the possible targets and can therefore not be used for Open Access mode BSRs.
If completed with ACL information, it can be used for Closed Access Mode BSRs.
4.6.2.3 VIRTUAL CELL ID

A mapping table, similar to the one for Basic Cell Id, will be defined at the BSG
through the use of bsrPSCforVirtEnhCellId to provide with a PSC ID vs BSR
PSC.
bsrPSCforVirtEnhCellId::id will be the Cell ID to use in the Macro and should

match the bsrPSCforVirtEnhCellId::psc. This method adds an additional
parameter bsrPSCforVirtEnhCellId::type that allows to define whether the BSR is
allocated an Open or Closed Access PSC.
Parameter bsrPSCforVirtEnhCellId
Object BSG
Granularity BSG
Range & Unit sequence [0..128] of struct BsrPSCforVirtEnhCellId
Class 3
Value 0
Parameter index
Object BsrPSCforVirtEnhCellId
Granularity BsrPSCforVirtEnhCellId
[0..127]
Class 3
Value -
Parameter psc
[-1..511]
Class 3
Value -
Note: The setting -1 indicates no PSC mapping

Parameter type
Range & Unit enumerated
{openAccess = 0,
closedAccess = 1}
Class 3
Value -
4.6.2.3.2 BSR CONFIGURATION

The Virtual Cell ID is a 12 bits long identifier that is to be defined manually in each
BSR where Virtual Cell ID is to be used.
Up to 6 Virtual Cell IDs can be specifically defined in each BSRs for UMTS using
the parameter virtualCellIdUmts::cellId.
Up to 6 Virtual Cell IDs can be specifically defined in each BSRs for GSM using the
parameter virtualCellIdGsm::cellId.
This is mainly to catch scenarios where BSRs would be deployed over several
Macro coverage areas.
At BSR registration, each device will provide these information to the BSG.
Parameter cellId
Object virtualCellIdUmts
Granularity Femto
[0..65535]
Class Class 3
Value 0
Parameter cellId
Object virtualCellIdGsm
Granularity Femto
[0..65535]
Class Class 3
Value 0
Restriction: virtualCellIdUmts and virtualCellIdGsm
Whenever you add virtualCellID (VirtualCellIdGsm and VirtualCellIdUmts) for BSRs, all 6 instances
will have to be created (with the non-used instances being =0).

On the Macro side, a neighbour will have to be defined with a Cell ID matching the
information entered at BSG level (related to the possible PSCs) and in each of the
BSRs covered by the Macro Cell.
Figure 1 provides with a way to arrange the bits and define the Cell ID to be
entered. More information on the different possibilities are given in 4.6.2.6.
In the case the BSRs can choose their PSC, as many BSR neighbours will have to
be declared at Macro side as possible combinations {BSR Virtual Cell ID – PSC}.
12 bits 4 bits
Virtual cell ID Femto

1...4095 PSC ID
C-ID=16 bits
Figure 2 – Virtual Cell ID mapping

This method adds information in the Cell ID and allows a better identification of the
target BSR, which makes incoming Handovers in the case of Open Access BSRs
possible. This method does not require updates in the case of Macro PSC
replanning.
Disadvantages are that all special cells must be manually provisioned for a "Virtual
Cell ID", and the macro topology manually determined. In the case new Macro cells
are integrated, the BSR neighbours on Macro side and the Virtual Cell ID on BSR
side may require updates.
4.6.2.4 ENHANCED CELL ID MAPPING

The concept of enhanced Cell ID mapping allows the PSC to be narrowed down to
the location of a Macro Cell, which will greatly cut down the number of false
relocations/preparations performed. This is similar to the "Virtual Cell ID" concept,
but allows a higher level of auto-configuration and also benefits both open and
closed access cells.

The mapping table that is used for Enhanced Cell ID is the same as the one for
Virtual Cell ID ( 4.6.2.3) and will be defined at the BSG through the use of
bsrPSCforVirtEnhCellId to provide with a PSC ID vs BSR PSC.

If 3G Macro to BSR HO is enabled, the BSR will provide the BSG with sniffed
macro network information during its registration.
The reported Macros must fulfill following criteria:
¾ The SIBs could be decoded
¾ The strongest detected cells will be registered with a maximum number
maxUmtsCellsRegister (where 0 means no registered cells) and will be
entered in order of decreasing signal strength.
¾ Its power difference to the strongest detected Macro should be below the
threshold thrRscpUmtsRegister
Following information will be among others reported:

¾ CPICH scrambling code
¾ Cell Identity
¾ RNC Identity
¾ DL Frequency
Parameter maxUmtsCellsRegister |
Object Femto | BSR
[0..3]
Class Class 3
Value 0
Parameter thrRscpUmtsRegister
Object BSR Profile
[0..90]
Class Class 3
Value 90

Engineering Recommendation: maxUmtsCellsRegister and Software support for 850/1900
It is recommended to set the maxUmtsCellsRegister=3 in the case incoming mobility is expected

from one UMTS band.
In the case Software support for 850/1900 is activated, the BSR will consider
maxUmtsCellsRegister for each bands.
If GSM Macro to BSR HO is enabled, the BSR will provide the BSG with sniffed
GSM network information during its registration.
The reported Macros must fulfill following criteria:
¾ The SIBs could be decoded.
¾ The strongest detected cells will be registered with a maximum number
maxGsmCellsRegister (where 0 means no registered cells) and will be
entered in order of decreasing signal strength.
¾ Its power difference to the strongest detected GSM cell should be below
the threshold thrRssiGsmRegister.
Engineering Recommendation: maxGsmCellsRegister
It is recommended to set the maxGsmCellsRegister =3 in the case incoming mobility is expected

from one GSM band.
In the case Software support for 850/1900 is activated, the BSR will consider
maxGSMCellsRegister for each bands.
Following information will be among others reported:

¾ NCC
¾ BCC
¾ Cell Identity
¾ DL Frequency
¾ Frequency Band
¾ RAC
¾ LAC

Parameter maxGsmCellsRegister |
Object Femto | BSR
[0..3]
Class Class 3
Value 0
Parameter thrRssiGsmRegister
Object BSR Profile
[0..60]
Class Class 3
Value 60

On the Macro side, each BSR neighbour will have a Cell ID matching the
information entered at BSG level with the additional information related to the
source Macro cell.
Figure 3 provides with the proposal in the case of 3G Macro cells. The Femto PSC
index is the one entered at BSG level. The Macro PSC represents the PSC of the
cells in which the BSR neighbour is to be defined.
Figure 4 provides with an example of possible information in the case of GSM

cells. The BSR PSC index is the one entered at BSG level.
The additional field allows to enter the BCC (on 3bits), the Frequency Id (5bits) and
the 2G cell ID (4bits).
More information on the different possibilities are given in 4.6.2.6.
3 bits 9 bits 4 bits
Spare Macro PSC Femto

PSC ID
C-ID=16 bits
Figure 3 - Enhanced Cell Id for 3G Macro


4bits 5 bits 3 bits 4 bits
2G Cell ID Freq Femto

Bitmask ID BCC PSC ID
C-ID=16 bits
Figure 4 - Enhanced Cell Id for GSM
The Enhanced Cell ID method allows the use of the Macro frequency to support
the filtering.
It is possible to define a list frequencies that are used by the Macro through the
structure umtsMacroFrequency and gsmMacroFrequency.
The umtsMacroFrequency will define an umtsMacroFrequency::index,
corresponding to the UARFCN umtsMacroFrequency::aRFCN and that is to be
used when defining the Cell ID.
The GSM Frequency will be defined with an gsmMacroFrequenc::index, a

gsmMacroFrequency::bandIndicator and the
gsmMacroFrequency::bCCHARFCN.
Parameter index
Object UmtsMacroFrequency
Granularity UmtsMacroFrequency
[0..15]
Class 3
Value -
Parameter aRFCN
Object UmtsMacroFrequency
Granularity UmtsMacroFrequency
[-1..16383]
Class 3
Value -

Parameter index
Object GsmMacroFrequency
Granularity GsmMacroFrequency
[0..15]
Class 3
Value -
Parameter bandIndicator
Range & Unit enumerated
{gSM450 = 0,
gSM480 = 1,
gSM850 = 2,
gSM900 = 3,
gSM900E = 4,
gSM1800 = 5,
gSM1900 = 6}
Class 3
Value -
Parameter bCCHARFCN
[-1..1023]
Class 3
Value -

This method allows in most of the cases to automatically create the BSR
neighbours in the Macro using scripts.
A drawback of this method is that following a Macro PSC change (due to a PSC
replanning or optimization for instance), the Cell IDs of the BSR neighbours in the
Macro for the modified cells will have to be updated.
On the BSR side, the sniffing functionalities should make to corresponding updates
automatically.

4.6.2.5 MACRO LIKE CELL ID MAPPING
It is possible to set the Cell ID of a BSR manually like it is the case for the Macro
network.

In this case the Cell-ID will use the 16 bits of the Virtual Cell ID. This means that
the operator is able to manually provision the cells in the same way as a macro
cell, allowing up to 65535 open access Femto Cell IDs to be provisioned.
If this is the case then the Femto must have a PSC which is manually provisioned
to match the neighbour relationships provisioned in the Macro network.

If this choice of Cell-ID is used, then the Femto must have a PSC which is
manually provisioned to match the neighbour relationships provisioned in the
Macro network.

At Macro level, when defining the neighbour relation, the PSC and Cell-ID are to be
configured as it would be the case for any other Macro cell (no generic use).

This method allows to define a one to one relation between a PSC and a Cell-ID
for a given Macro cell. This approach should provide with performance level
comparable to the ones of a Macro network.
However, this relies on static definition the complete sets of parameters (PSC, Cell
ID, mapping…) and does need manual update in the case of any changes, just as
it is the case for the Macro network.
Rule: Consistency Femto / Macro configuration
It is mandatory that the information for the neighbour defined at Macro level matches the BSR
information provided when configuring the BSR (PSC manually configured, Cell-ID manually
assigned).

4.6.2.6 CELL ID MASK

The Cell ID mapping method is determined at the BSG by defining the way its
different bit are composed of. Figure 5 presents possible configuration of the
different cell IDs mapping methods.
The parameter umtsMacroCellId allows to define how the different information to
construct the incoming 3G Cell ID.
The parameter gsmMacroCellId allows to define how the different information to
construct the incoming GSM Cell ID.
Rule: umtsMacroCellId and gsmMacroCellId
Following rules are to be followed when defining the Cell ID bits:

¾ Bits with the same field must be contiguous (ex. 4 first ones for the PSC)
¾ Bits 0 must be a bsrPSCbit
¾ To activate Basic Cell ID, bits 4 to 15 are to be set to 0
¾ To activate Virtual Cell ID, bits 4 to 15 should be set to virtualCellIDbit
¾ To activate Enhanced Cell ID, bits 4 to 15 should be set to value different from 0 and
virtualCellIDbit
¾ To activate Virtual Cell ID – Macro Like Provisionning, bits 0 to 15 should be set to
virtualCellIDbit
# Basic Cell ID Basic Cell ID + Enhanced Cell ID Enhanced Cell ID Virtual Cell ID –
Virtual Cell ID Macro Like
Provisioning
umtsMacroCellId umtsMacroCellId umtsMacroCellId gsmMacroCellId
gsmMacroCellId gsmMacroCellId
0 bsrPSCbit bsrPSCbit bsrPSCbit bsrPSCbit virtualCellIDbit
4 zero virtualCellIDbit macroPSCbit bccbit1 virtualCellIDbit
7 zero virtualCellIDbit macroPSCbit frequencyID virtualCellIDbit
12 zero virtualCellIDbit macroPSCbit cellIDbit1 virtualCellIDbit
13 zero virtualCellIDbit freqencyIDbit cellIDbit2 virtualCellIDbit
14 zero virtualCellIDbit freqencyIDbit cellIDbit3 virtualCellIDbit
15 zero virtualCellIDbit zero cellIDbit4 virtualCellIDbit
Figure 5 –Different possible scenarios for the Cell ID definition

Parameter umtsMacroCellId
Object BSG
Range & Unit sequence of 16 bits, each having one of the following
value
{zero = 0,
bsrPSCIDbit = 1, virtualCellIDbit = 2,
frequencyIDbit = 3, macroPSCbit = 4,
cellIDbit1 = 5, cellIDbit2 = 6,
cellIDbit15 = 19, cellIDbit16 = 20}
Class 3
Value 0
Parameter gsmMacroCellId
Object BSG
Range & Unit sequence of 16 bits, each having one of the following
value
{zero = 0,
bsrPSCIDbit = 1, virtualCellIDbit = 2,
frequencyIDbit =3, frequencybit = 4,
bccbit1 = 21, bccbit2 = 22,
bccbit3 = 23, racBit1 = 24,
racBit2 = 25, racBit3 = 26,
racBit8 = 31, gsm1800bit =32}
Class 3
Value 0

4.6.2.7 MAXIMUM NUMBER OF DEFINABLE EXTERNAL CELLS
As it has been presented, the fewer the BSRs sharing the same PSCs are, the
better the identification of the target BSR will be. This implies a high number of
PSCs.
In the case Virtual or Enhanced Cell ID mapping is used, for each possible BSR
PSC, one specific BSR neighbour per Virtual Cell ID or Macro Cell is to be defined.
For instance, to define 5 PSC for a BSR Cluster in a 3G Network with 300 NodeBs,
each 3sectorized, a total number of 4500 external neighbours will have to be
created (5 neighbours for 900 cells).
In many of the UTRAN OAM, the total number of external neighbors is limited to
values below 3000.
Engineering Recommendation: Trade Off
A trade off is to be found between the number of PSCs (and the resulting Handover Performances)
and the Macro OAM (2G or 3G) capabilities
4.6.3 FILTERING AT BSG LEVEL

At BSG level, the RANAP Relocation Request of the CN is intercepted and
decoded.
The BSG will then perform a Mapping of the Target Cell ID contained in the
RANAP Relocation Request to a BSR PSC using one of the methods described in
4.6.2.
For PS or CS+PS Relocation Request, Target Cells are only selected that have
psHoFromUmtsMacroEnabled set to True.
If the number of Iu instances equals two, the BSG ensure that the same target cells
are selected for the CS and PS domains. The IMSI is used to associate requests
from the same UE.
In the case the Target Cell ID cannot be translated into a PSC, the PSC ID is
considered as invalid.
When the PSC ID is invalid and the parameter skipPscCheck=TRUE, the BSG will
skip the PSC filtering.
When the PSC ID is invalid and the parameter skipPscCheck=FALSE, the BSG
will return an empty target BSR list and reject the incoming Handover.

Parameter skipPscCheck
Object BSG
{True, False}
Class 3
Value FALSE
The BSG will determine possible target BSRs based upon all of the following
criteria:
1. BSR which have the IMSI in the ACL.
2. BSR which match the C-ID
3. BSR which match the C-ID to PSC mapping.
4. BSR which have incoming HO Enabled.
It is possible to extend or restrict the second criteria

keepBSRsWithNoMacroCellInfo
If keepBSRsWithNoMacroCellInfo=FALSE, the BSG will remove all BSRs from
the target BSR list, which do not have registered Virtual Cell Ids or UMTS/GSM
macro cell information.
Rule: keepBSRsWithNoMacroCellInfo and Basic Cell ID
In the case Basic Cell ID is used, keepBSRsWithNoMacroCellInfo has to be set to TRUE.
Parameter keepBSRsWithNoMacroCellInfo
Object BSG
{True, False}
Class 3
Value TRUE
In the case that the BSG finds no match on a BSR or the Relocation can not be
supported, the BSG sends a RANAP Relocation Failure message back towards the
MSC.
4.6.4 ENHANCED BSR FILTERING:

In order to reduce further the possible number of target BSRs, the BSG can apply
an Enhanced BSR Filtering based on the information of the source network.

If the incoming HO is triggered from a UMTS network, the BSG will apply
enhanced filtering of target BSRs as follows:
¾ If sourceRNCcheckEnabled = TRUE, the BSG only includes the
BSRs in the target BSR list matching the RNC ID of the macro source
cell. The BSG compares the RNC ID of the registered UMTS Macro
Cell Information with the RNC ID provided by the CN.
¾ If sourceAreaCheckEnabled = TRUE, the BSG only includes the
BSRs in the target BSR list matching the LAC and/or RAC of the
macro source cell. The BSG compares LAC and/or RAC of the
registered UMTS Macro Cell Information with the LAC and/or /RAC
provided by the CN.
Note: RAC is optional in the RRC container.
Parameter sourceRNCcheckEnabled
Object BSG
{True, False}
Class 3
Value FALSE
Parameter sourceAreaCheckEnabled
Object BSG
{True, False}
Class 3
Value FALSE
If the incoming HO is triggered from a GSM network, the BSG will apply enhanced
filtering of target BSRs as follows:
If sourceCellLoadInfoCheckEnabled = TRUE, the BSG only includes the BSRs
in the target BSR list matching the PLMN-Id, LAC and CI the macro source cell.
The BSG compares PLMN-Id, LAC and CI of the registered GSM Macro Cell
Information with the PLMN-Id, LAC and CI provided by the CN.
Note: The Cell Load Information Group IE is an optional parameter in the Source
RNC to Target RNC message.

Parameter sourceLoadInfoCheckEnabled
Object BSG
{True, False}
Class 3
Value FALSE
If a BSR has not registered the macro cell information needed for Enhanced BSR
Filtering, enhanced filtering is not applied.
4.6.5 MAXIMUM NUMBER OF TARGET BSRS

If the number of potential target BSRs in the target BSR list exceeds
maxHoTargets, the BSG will reject the request and clear the list.
Parameter maxHoTargets
Object BSG
[1..10]
Class 3
Value 4
Engineering Recommendation: MaxHOTargets
The value of MaxHOTargets has to be chosen carefully.

Configuring a value that is low may lead to better performances as incoming handovers would only
be allowed when the number of targets is small.
However, in big BSR networks where it is not easily possible to identify the target (so
MaxHOTargets continuously exceeded), it may led to a kind of switch off for the feature.
A similar behaviour can be obtained for Emergency calls using the parameter
MaxHOTargetsEMCall.
Parameter maxHoTargetsEmCall
Object BSG
[1..10]
Class 3
Value 2

4.6.6 HANDOVER BLACK LIST
The Handover Black List is used to prohibit incoming handover from the CN for a
UE to a particular BSR for a configurable time. When the timer expires, the UE is
removed from the list and it can be handed over to the BSR again.
The Handover Black List is needed for three reasons:
1. If multiple target BSRs have been identified, the macro network might
trigger the handover for the same UE again, if the handover fails on the air
interface. Then the next handover attempt shall use another target BSR.
2. If the relocation on Iu was successful, the handover for this UE shall be
prohibited for a configurable time in order to reduce ping-pongs between
the macro network and the BSR.
3. When both CN domains are involved, it ensures that the same target is
selected for each domain.
The Black List is maintained by the BSG and contains the BSR-ID associated with
an IMSI and an expiration timer “HO Black List Timer”.
The value of this parameter is updated as follows:

¾ On receipt of Relocation Request Acknowledge, Relocation Failure
and expiry of the timer relocReqTimer, the value of the HO Black
List timer shall be calculated based on the size of the HO target
BSR list:
HO Black List Timer = hoRetryGuardTime +
hoRetryGuardTimeOffset * number of BSRs available for further
handover attempts.
Note: The timer relocReqTimer is started on sending of the Relocation Request to

the BSR.
¾ After a Relocation Complete message from the BSR, the BSG

shall set the HO Black List Timer = hoBackGuardTime.
If hoBackGuardTime = 0, the BSG shall not add the entry to the
HO Black list.
This filter is performed on the Target BSR list.

Parameter relocReqTimer
Object BSG
Range & Unit integer [s]
[1..65535]
Class 3
Value 15
Parameter hoRetryGuardTime
Object BSG
[1..65535]
Class 3
Value 30
Parameter hoRetryGuardTimeOffset
Object BSG
[1..65535]
Class 3
Value 4
Parameter hoBackGuardTime
Object BSG
[1..65535]
Class 3
Value 15
4.6.7 PRIORITIZATION OF TARGET BSRS

The BSG will sort the BSRs in the target BSR list in the following order.
4. BSRs, which have the IMSI classified as owner in the ACL.
5. BSRs, which have the IMSI classified as guest in the ACL.
6. Other BSRs.
The BSG will then attempt to handover to the BSR according to the order of the
target BSR list.
4.6.8 RELOCATION REJECT CAUSES

The BSG supports the configuration of RANAP relocation reject causes for the
following cases:

¾ Relocation reject on unsupported CN domain
(relocRejectUnsupportedDomain)
¾ Relocation reject due to handover disabled
(relocRejectHoDisabled)
¾ Relocation reject due to unsupported parameters
(relocRejectUnsupportedParam)
¾ Relocation reject due to no target BSR found
(relocRejectNoTargetBSR)
¾ Relocation reject due to no target BSR has accepted the relocation
request (relocRejectByTargetBSRs)
The parameters in the brackets allow to configure the reject cause depending on
the described reason. [3GPP_R15] provide with the list of the different RANAP
causes.
Parameter relocRejectUnsupportedDomain
Object BSG
[1..261]
Class 3
Value 44
Parameter relocRejectHoDisabled
Object BSG
[1..261]
Class 3
Value 44
Parameter relocRejectUnsupportedParam
Object BSG
[1..261]
Class 3
Value 19

Parameter relocRejectNoTargetBSR
Object BSG
[1..261]
Class 3
Value 50
Parameter relocRejectByTargetBSRs
Object BSG
[1..261]
Class 3
Value 50
4.7. OPEN ACCESS MODE
4.7.1 BSG CONFIGURATION
4.7.1.1 FEATURE ACTIVATION

At BSG level, the incoming handover from either GSM or UMTS is to be activated
to allow the incoming mobility for the open access mode BSRs in the cluster.
Incoming PS handover is to be specifically activated.
Following parameters are used:
¾ For Handover from GSM to Open Access BSR:
hoFromGsmMacroEnabledOpenAccess
¾ For Handover from UMTS to Open Access BSR:
hoFromUmtsMacroEnabledOpenAccess
¾ For PS Handover from UMTS to BSR: same parameter than closed access
mode:
psHoFromUmtsMacroEnabled (described in 4.6.1)
Parameter hoFromGsmMacroEnabledOpenAccess
Object BSG
{True, False}
Class 3
Value FALSE

Parameter hoFromUmtsMacroEnabledOpenAccess
Object BSG
{True, False}
Class 3
Value FALSE
4.7.1.2 NEIGHBOUR CONFIGURATION AT BSG LEVEL

When BSRs are configured in Open Access mode, the BSG will not have IMSI
information like it was the case for Closed Access mode to support the target BSR
identification.
Therefore, additional information is to be provided to the BSG to refine the filtering
and reach a target BSR list as small as possible.
The Basic Cell ID mapping will not provide with enough information to allow
incoming Handover in the case of Open Access Mode BSRs.
Therefore it is mandatory, if Open Access Mode has to support incoming
Handovers, to use either the Virtual or Enhanced Cell ID mapping.
Engineering Recommendation: Limited Deployment
It is strongly recommended to also reduce the number of BSRs in Open Access mode and to limit
such usages to absolutely needed cases (locations with higher CDR for instance).
4.8. INCOMING MOBILITY ON THE BSR

The procedures described in this chapter are common for Closed and Open
Access BSRs.
4.8.1 ALLOWING INCOMING MOBILITY

The incoming Mobility, either from GSM or UMTS, can be activated on a per BSR
basis.
Setting hoFromUmtsMacroEnabled=TRUE will allow 3G Macro to BSR mobility
for the considered BSR.
Setting hoFromGsmMacroEnabled=TRUE will allow 2G Macro to BSR mobility
for the considered BSR.
Setting psHoFromUmtsMacroEnabled=TRUE will allow 3G Macro to BSR
mobility for PS calls for the considered BSR.

Engineering Recommendation: PSC List Impact
To avoid Performance degradation as described in 4.3.4, when activating incoming Mobility the
PSC List should be updated accordingly.
Parameter hoFromUmtsMacroEnabled |
Object Femto | BSR
{True, False}
Class Class 3
Value FALSE
Parameter hoFromGsmMacroEnabled |
Object Femto | BSR
{True, False}
Class Class 3
Value FALSE
Parameter psHoFromUmtsMacroEnabled
Object Femto
Granularity Femto
{True, False}
Class Class 3
Value FALSE
4.8.2 INCOMING HANDOVER FROM MACRO

When a BSR receives a Relocation Request message from a UMTS source cell
and BSR::hoFromUmtsMacroEnabled = TRUE (and
psHoFromUmtsMacroEnabled = TRUE in case of a PS call), the BSR will
execute following tasks:
¾ Determine information out of the Relocation Request message. These
mainly concern UE capabilities, number of SRB and RB, measurements
activated.
In case of CS+PS Handover, a timer is used. If a Relocation Request
message is received by the BSR with Number of Iu Instances = 2, the
second message has to arrive within less than tRelocCoord ms.
Otherwise, the Relocation procedure is failed.
¾ Perform Handover admission control
o the BSR performs an RF load call admission check. No pre-
emption is applied.

o the BSR performs a number of users check.
o the BSR performs a baseband load check. No downgrading is
applied.
o the BSR performs a Transport Call admission control for the
incoming CS RAB. No ACR is applied.
o If any of these checks fails, the BSR will send a Reloction Failure
with a cause as specified in 4.8.3.
¾ Allocate and Setup Resources
The BSR will wait a maximum of tRelocForwardSRNSContextSupv ms
for the SRNS context to be forwarded from the UTRAN before resuming
PS data transfer.
Note: In case of CS+PS call, if there are insufficient resources to support
the PS RABs but the CS call can be admitted, seamless voice service is
favoured. Handover is performed for both connections, and then the PS
RABs are released.
If all the three actions are successfully performed, the BSR accepts the relocation
attempt by sending a Relocation Request Acknowledge message to the CN.
Parameter tRelocCoord
Object BSR Profile
[1..100000]
Class Class 3
Value 2000
Parameter tRelocForwardSRNSContextSupv
Object BSR Profile
[0..10000]
Class Class 3
Value 2000
4.8.3 FAILURE CASES
4.8.3.1 RANAP FAILURE CAUSES

Table 1 presents the different Failures causes that will be found in the RANAP
Failure message following a failure in the BSR.

BSR failure RANAP cause
Relocation not supported in Target RNC

Incoming handover disabled
or Target system
RAB Capability check failed Invalid RAB Parameters Value
No Radio Resources Available in Target

Radio resource restrictions
cell
Failure during Iu user plane establishment

Iu UP Failure
(DPAT/Init failure) or Transport resource failure
RRC container decode failure Abstract Syntax Error
UE does not support the frequency band or ACL

Relocation Target not allowed
check failure.
Requested Ciphering and/or Integrity
Ciphering/integrity failures
Protection Algorithms not supported
Failure during air interface set up or other Relocation Failure in Target CN/RNC or
BSR internal failures Target System
Table 1 - RANAP Failure cause for different BSR Failures
4.8.3.2 RELOCATION COMPLETE FAILURE

In the case a UE has not connected with the BSR, and upon expiry of the timer
BSR::tRelocComplete, the BSR releases all resources allocated during the
relocation resource allocation procedure and send Iu Release Request with cause
"Relocation Failure in Target CN/RNC or Target System" to the CN.
Note: The BSR has not received the Radio Bearer Reconfiguration from the UE.
Usually the CN should have already released the Iu connection before the timer
BSR::tRelocComplete expires in the BSR.
Parameter tRelocComplete
Object BSR Profile
[1000..600000]
Class Class 3
Value 10000
4.8.3.3 RELOCATION CANCEL

If the relocation is aborted, the CN releases the Iu connection. This occurs for
instance when the source RNC/BSC have cancelled the relocation/handover.

If the BSR receives an Iu Release Command message from the CN before
completion of the relocation, the BSR releases the allocated resources and send
an Iu Release Complete message to the CN.
4.8.3.4 HANDOVER COMPLETE FAILURE

If a Post-Relocation procedure has failed, the incoming handover from the macro
cell cannot be completed.
Upon expiry of the timer BSR::tHoFromMacroComplete, the BSR will release the
call by sending a RANAP Iu Release Request to the CN with cause ‘Release due
to UTRAN Generated Reason’ and RRC Connection Release to the UE with cause
'unspecified' and release all associated resources and transport bearers.
Parameter tHoFromMacroComplete
Object BSR Profile
[1000..600000]
Class Class 3
Value 30000
4.8.4 UE REGISTRATION FOR (SEMI-)OPEN ACCESS BSR

Following completion of incoming HO from the Macro network of a user on a BSR
in open access mode (open access or prioritised open access), the BSR sends a
UE Registration message to the BSG so that the UE can be registered in the IMSI
Directory.

5. INDEXES
5.1. TABLE INDEX

Table 1 - RANAP Failure cause for different BSR Failures ............................................................. 35
5.2. FIGURE INDEX

Figure 1 - Typical BSR Deployment................................................................................................... 5
Figure 2 – Virtual Cell ID mapping ................................................................................................... 15
Figure 3 - Enhanced Cell Id for 3G Macro ....................................................................................... 18
Figure 4 - Enhanced Cell Id for GSM ............................................................................................... 19
Figure 5 –Different possible scenarios for the Cell ID definition ...................................................... 22

Z END OF DOCUMENT Y


VOLUME 10 HSXPA

CONTENT OF VOLUME 10
1. INTRODUCTION............................................................................................................................3
1.1. OBJECT....................................................................................................................................3

2.1. FPUG VOLUMES ......................................................................................................................3
3. HSXPA ...........................................................................................................................................5
3.1. HSDPA ...................................................................................................................................5
3.1.1 Introduction .....................................................................................................................5
3.1.2 Feature Activation ...........................................................................................................6
3.1.3 RAB Combinations..........................................................................................................8
3.1.4 HSDPA UE Categories ...................................................................................................8
3.1.5 Transport and Physical Channels ...................................................................................9
3.1.5.1 Downlink Channels....................................................................................................11
3.1.5.2 Uplink Channels ........................................................................................................13
3.1.6 HSDPA Power Distribution ...........................................................................................13
3.1.6.1 HS-SCCH Power .......................................................................................................14
3.1.6.2 HS-DSCH Power .......................................................................................................14
3.1.6.3 HS-PDSCH Power.....................................................................................................15
3.1.7 Scheduler ......................................................................................................................16
3.1.7.1 Algorithm ...................................................................................................................16
3.1.7.2 QoS Management .....................................................................................................18
3.1.7.3 Flow Control ..............................................................................................................19
3.1.8 TRFC Management.......................................................................................................19
3.1.8.1 RLC PDU Size Management.....................................................................................19
3.1.9 Dynamic Code Allocation..............................................................................................21
3.2. HSUPA (E-DCH) ..................................................................................................................24
3.2.1 Introduction ...................................................................................................................24
3.2.2 Feature Activation .........................................................................................................24
3.2.3 RAB Combinations........................................................................................................26
3.2.4 Selection of E-DCH as the Channel Type ....................................................................27
3.2.5 Femto Specificity - Definitions.......................................................................................27
3.2.6 HSUPA UE categories ..................................................................................................28
3.2.7 Transport and Physical Channels .................................................................................29
3.2.7.1 Uplink channels .........................................................................................................30
3.2.7.2 Downlink Signaling channels.....................................................................................35
3.2.8 Principle of E-DCH Operation .......................................................................................38
3.2.9 DL Scheduling Information - Serving Grants ................................................................39
3.2.9.1 Absolute Grants.........................................................................................................39
3.2.9.2 Relative Grants..........................................................................................................39
3.2.10 E-DCH Transport Format Combination (E-TFC) Selection...........................................42
3.2.11 UL Scheduling Information............................................................................................44
3.2.11.1 Happy Bit ...................................................................................................................44
3.2.11.2 Scheduling Information..............................................................................................45
3.2.12 Air interface limitation....................................................................................................47
3.2.13 E-DCH uplink Channel Power Control ..........................................................................50
3.2.14 E-DCH Downlink Channel Power Control.....................................................................53

4. INDEXES .....................................................................................................................................55
4.1. TABLE INDEX ..........................................................................................................................55
4.2. FIGURE INDEX ........................................................................................................................55

1. INTRODUCTION
1.1. OBJECT
This volume is dedicated to Features and Parameters related to HSxPA.
2.1. FPUG VOLUMES


[Vol. 4] Radio Ressources Management
[Vol. 10] HSxPA


specification
reception (FDD)
specification



3. HSXPA
3.1. HSDPA
3.1.1 INTRODUCTION
The Small Cells support the establishment of a PS RAB on either HSDPA or DCH
based on the UE capability. If the UE is HSDPA capable, then the PS RAB will be
established on HSDPA.
HSDPA is a service based on a pool of potentially high throughput downlink
channel resource shared among a group of users. A scheduler in the BSR is in
charge of controlling which user(s) is/are being served based on traffic, channel
conditions, UE capability and Quality of Service (QoS) requirements.
The Small Cells support the following HSDPA functionalities:

• HSDPA user plane for HS-DSCH channels and flow control.
• HSDPA air interface scheduler providing the requested quality of service
performance.
• MAC-hs and MAC-ehs scheduling.
• QPSK (Quadrature Phase Shift Keying), 16 QAM (Quadrature Amplitude
Modulation) and 64 QAM modulations.
The MAC layer of the BSR handles priority control of data flows. MAC-d and MAC-
hs (in the baseband processor) interact to provide proper scheduling and priority
control of data over HSDPA. The MAC-hs scheduler supports multiple MAC-d
flows.
The HSDPA scheduler runs every TTI (2ms).
Prior to BCR 2.4 up to 7.21 Mbps DL HSDPA speed could be achieved. In BCR 2.4
the feature 113161 - Full Rate HSPA provides the means to increase the DL data
rates up to 13.98 Mbps.
To achieve the higher bit rate in HSDPA, the feature 77024 - Dynamic Code
Allocation must be enabled.
In BCR 3.0, data rates of up to 21.1Mbps can be achieved. The BSR ensures that
the peak HSDPA rate provided to each terminal will be compatible with their
supported category and within the capacity of the baseband modem.

Inter-Release Delta: 64QAM modulation for HSDPA,
In BCR 3.0 the feature 116496 introduces 64QAM modulation for HSDPA. When used with MAC-
ehs and flexible RLC sizes (feature 116497), data rates of up to 21.1Mbps can be achieved by UEs
of category 13, 14, 17, 18, 19 and 20, in ideal radio conditions.
Restriction: Feature 113161 - Full Rate HSPA - Hardware limitations
The feature Full Rate HSPA is restricted to HW version V2 Enterprise and Metro.
V2 Residential hardware does not support 64QAM.

To activate HSDPA, the parameter activateHSDPA has to be set to True. This
parameter enables/disables overall HSDPA functionality on the Small Cell.
Parameter activateHSDPA
Object Femto
Granularity Femto
{True, False}
Class Class 0
Value TRUE
The Enhanced HSDPA Power Management feature is activated through the

parameter hSDPADynamicPowerEnabled. With the feature enabled, power being
allocated to HSDPA channels does not limit the R99 power. The inner loop R99
power control is unaffected and HSDPA scheduler is capable of using all the
remaining power not used by R99 services.
Refer to [Vol. 3] for more details about Enhanced HSDPA Power Management
XRR X
feature.
The maximum number of concurrent users that the BSR can assign to an HS-
DSCH channel is defined through the parameter maxHsdpaUsersPerCell.
Parameter maxHsdpaUsersPerCell
Object LCell::HSDPA
[0...64]
Class Class 3
Value 64

Engineering Recommendation: maxHsdpaUsersPerCell
It is recommended to set this value higher than the one supported by all the BSRs deployed in the
cluster. If maxHsdpaUsersPerCell is set to a value greater than the maximum supported by the
HW the SW automatically caps its value (refer to [Vol. 2]). XRR X
The maximum DL user throughput for HSDPA is defined during pre-provisioning

through the OAM parameter maxHsdpaUserRate. Note that this value will be
capped by the platform capability.
Parameter maxHsdpaUserRate |
Object HSDPA |
Range & Unit Integer (kbps)
[0..20000]
Class Class 0
Value 14000
The parameter hsdpaMbrCapping enables capping of HSDPA data rate to the

Maximum Bit rate signalled in RANAP. Setting this parameter to 0 means that
capping is disabled.
Parameter hsdpaMbrCapping
Object LCell::HSDPA
[0..200]
Class Class 3
Value 100
Engineering Recommendation: hsdpaMbrCapping
To allow the Small Cell owner to get the maximum possible bit rate from his backhaul DSL the
operator has the option to set hsdpaMbrCapping = 0 so that the MBR signalled in the RANAP
message will not be policed.
The 64QAM modulation for HSDPA feature depends on the baseband device
supporting 64QAM, MAC-ehs and flexible RLC sizes, and is enabled by
enable64QAMflag.

Parameter enable64QAMflag
Object HSDPA
{True, False}
Class Class 3
Value false
3.1.3 RAB COMBINATIONS

The HSDPA RAB combinations are presented in [Vol. 2]. XRR X
Restriction: 64 QAM rates
Peak 64QAM rates are reduced when in combination with simultaneous CS voice and CS data
calls.
3.1.4 HSDPA UE CATEGORIES

The various HSPDA UE Categories supported by the BSR as well as their Max
RLC Rate capabilities are presented in Table 1. X X

Supported
Max RLC Rate UE
HSDPA UE Max Number of modulations
Capabilities
Category SF16 Codes without MIMO
[Mbps]
operation
1 5 1.22
2 5 1.22
3 5 1.82
4 5 1.82
5 5 3.65
QPSK, 16QAM
6 5 3.65
7 10 7.21
8 10 7.21
9 15 10.13
10 15 13.98
11 5 0.91
QPSK
12 5 1.82
13 15 17.64
QPSK, 16QAM,
14 15 21.10 64QAM
15 15 11.69
QPSK, 16QAM
16 15 13,98
17 15 17.64
QPSK, 16QAM,
18 15 21.10 64QAM
19 For future use; supports the capabilities of category 17 in this
20 version of the protocol
Table 1 - HSDPA UE Categories RLC rate capabilities [3GPP_R07] XRR X
Restriction: HSDPA UE Categories 9 and 10
HSDPA UE Categories 9 and 10 performances are restricted to HW version v2.
3.1.5 TRANSPORT AND PHYSICAL CHANNELS

In R99, downlink data is sent on a DCH (Dedicated CHannel) which is mapped on
the DPDCH (Dedicated Physical Data CHannel). In HSDPA, downlink data are
sent on a HS-DSCH (High Speed - Downlink Shared CHannel) which is mapped
on one or several HS-PDSCH (High Speed - Physical Downlink Shared CHannel).
Users are multiplexed on the HS-DSCH channel in time and code. Transmission is
based on shorter sub-frames of 2ms (TTI) instead of 10ms in R99.
In downlink, the HS-PDSCHs are transmitted with the HS-SCCH (High Speed -
Shared Control CHannel) channel. This channel is broadcasted over the cell but its
information is only relevant to the user that is intended to receive the HS-PDSCH.
The HS-SCCH allows the user to know if the HS-PDSCH is for him and to decode
it correctly.

Radio conditions information and acknowledgement are reported by the UE
through the HS-DPCCH (High Speed – Dedicated Physical Control CHannel)
channel. This channel allows the BSR to adapt the downlink data rate and to
manage retransmission process. The HS-DPCCH is divided in two parts. The first
one is the Channel Quality Indicator (CQI) which is a value between 1 and 30
characterizing the radio conditions (1 = bad radio conditions and 30 = good radio
conditions). The second one is the acknowledgement information: if data are well
received by the UE, the UE sends to the BSR an ACK, otherwise a NACK
(Negative Acknowledgement).
Figure 1 summarizes the different channels needed for a HSDPA call:

X X
Figure 1 - HSDPA channels and associated R99 channels
The maximum bit rate that can be achieved in the UL can be the bottleneck for the
maximum bit rate achievable in the DL. For instance, excessive delay of RLC/TCP
acknowledgements due to low bandwidth in the UL will limit the DL throughput,
even if the RF conditions would allow more.
For the case the HSDPA is setup with a R99 DCH in the UL, the BSR has inbuilt a
dynamic bearer control that dynamically adapts the UL bit rate to the amount of
traffic carried over the RB. UL adaptation ranges from 64kbps up to 384kbps.
In Figure 2 it is described the timing relations between the different physical

X X
channels:

Figure 2 - Timing relationship at BSR between physical channels
3.1.5.1 DOWNLINK CHANNELS

The mobile receives a HS-SCCH sub-frame (Figure 3) that contains control
X X
information among which:

• Channelization-code-set information
• Modulation scheme information
• Transport-block size information
• Hybrid-ARQ process information
• Redundancy and constellation version

• New data indicator
• UE identity, i.e. subset of the HRNTI
The SF is fixed to 128. It indicates to which UE the data is intended to, on which
codes and with which parameters. There are as many HS-SCCH transmitted
during a TTI as scheduled user number.
Figure 3 - HS-SCCH structure
A mobile decoding its identity in the slot 0 of an HS-SCCH knows that it has been
assigned resources on the HS-PDSCH channels (as indicated, with modulation, in
this slot 0, other information is given in slots 1 and 2): the mobile receives a
transport block on one or several HS-PDSCH (Figure 4). X X

Figure 4 - HS-PDSCH structure
The HS-PDSCH on which is mapped the HS-DSCH carries only the data payload.
The SF is equal to 16 and up to 15 codes can be reserved to HS-PDSCH per cell.
One HS-DSCH can be mapped onto one or several HS-PDSCH (the maximum
number of codes is given by UE capabilities).
In Figure 5 it is illustrated the DL common channel allocation with E-DCH activated.

X X
Available for
3.4kb/s SRB
signalling
(DCCH)
Figure 5 - DL Channelisation Code Resources
The feature 121160 introduces a second E-HICH/RGCH, this channel is required

when the number of users is higher than 19. Then this channel is only allocated
when the Femto is configured for more than 19 users. It can also be de-allocated
by the dynamic code allocation if all 15 SF16 codes are required by HSDPA.
In the BSR one SF16 C(16,0) is reserved for the common channels however, not
all the capacity of this code is actually used. There is one SF256 code available
which is enough to carry one 3.4kb/s SRB signalling channel leaving the rest of the
15 SF16 codes free for HS-DSCH channels.
Even if the feature Call Setup using 13.6kbps DCCH is enabled, which would use a
SF128 code for the SRBs, once a RAB is established the signalling is reconfigured
down to 3.4Kb/s so the full capacity is still possible.
As the SF16 C(16,0) branch is filled with one DCCH the 15 codes for HS-DSCH
are only possible if there is a single user active in the cell.

Engineering Recommendation: Signalling over Cell FACH
It is recommended to activate the feature 104376 - Signalling over Cell FACH feature together with
the Dynamic Code Allocation feature.
With Signalling over Cell FACH channelization codes are not allocated to signalling only
connections (i.e. Location Area Updates) leaving more codes available to HSDPA and reducing the
number of potential reconfigurations.
3.1.5.2 UPLINK CHANNELS

The UE will send UL feedback frame(s) on HS-DPCCH (SF = 256), roughly 7.5
slots after HS-PDSCH frame, containing:
• The HARQ Ack/Nack;
• The CQI (Channel Quality Indication)
The structure of HS-DPCCH is illustrated in Figure 6. X X
Figure 6 - HS-DPCCH structure
In the BSR the HSDPA feedback information is defined statically such as:
• The HARQ ACK/NACK is not repeated
• The CQI feedback cycle is equal to 2ms
• A CQI is not repeated
• The HS-DPCCH - DPCCH power offset used for CQI, ACK and NACK
transmission is set to 5 dB
3.1.6 HSDPA POWER DISTRIBUTION

If the feature HSDPA dynamic power allocation is enabled (refer to [Vol. 3]) the XRR X
scheduler will use all the cell power allocation that remains once the R99 channels
and the configurable hsdpaDynamicPwrHeadroom power have been taken into
account. The available power for HSDPA is re-calculated every 10ms by the BSR.

3.1.6.1 HS-SCCH POWER
The available power for HSDPA PHSDPA is shared between HS-SCCH and HS-
B B
DSCH channels (see Figure 7). X X
Figure 7 - Power distribution between HS-DSCH and HS-SCCH channels
A HSDPA user is scheduled only if there is enough power for HS-SCCH i.e. if:
PHS-SCCH < PHSDPA
B B B B
Restriction: Performance Limitation
The BSR uses a fixed configuration of two HS-SCCH channels which means that up to two users
may be scheduled in one 2ms TTI.
3.1.6.2 HS-DSCH POWER

The HSDPA power not allocated to HS-SCCH can be used for HS-DSCH transport
channel:
PHS-DSCH = PHSDPA - PHS-SCCH

B B B B B
Due to the dynamic allocation of power in the HSDPA channel, the UE needs to
have a power reference in order to adapt its reported CQI to the radio link
condition. As specified by 3GPP ( [3GPP_R11]) UE has to compute its CQI in order
XRR X
to assure a Block Error Rate (BLER) first transmission equal to 10% by assuming
that BSR sends its HS-DSCH with the following reference power:
PHS-DSCH reference[dBm] = PP-CPICH[dBm] + Γ[dB] + Δ(CQIreported)[dB]

B B B B B B B B

Where:
− PP-CPICH is the power of the P-CPICH channel,
B B
− Γ is the measurement power offset

− Δ is the reference power offset given by the reference tables of CQI [3GPP_R11] XRR X
Note that CQI computation by the UE is totally independent from the HS-DSCH
scheduling by the BSR, since UE has no information concerning HS-DSCH power,
CQI processed and algorithms used by the BSR. That is why the UE reports a CQI
even if it is not scheduled.
The power PHS-DSCH is defined by a power offset compared to the P-CPICH power.
B B
This power offset corresponds to the hSDPAMeasurementPowerOffset

parameter. The mobile is able to compute this reference power thanks to the P-
CPICH power measurement and to the hSDPAMeasurementPowerOffset
parameter.
Parameter hSDPAMeasurementPowerOffset
Object BSR Profile
[-6…13]
Class Class 3
Value 9
Note: The MAC-hs scheduler uses a lookup table based upon [3GPP_R11] to map
U U XRR X
the CQI reported by the UE to the MAC-hs block size to schedule to the UE. The
scheduler assumes that the CQI reported by the UE is perfectly calibrated.
3.1.6.3 HS-PDSCH POWER

Assuming that the power is uniformly distributed over all codes (NHS-PDSCH) that are B B
available for HSDPA, the available power for one HS-PDSCH (for user u from the
ranking list) is:
PavailableHS-PDSCH(u) = (PHSDPA - PHS-SCCH(u)) / NHS-PDSCH
B B B B B B B B
Where:
- PHSDPA is the power that is available for HSDPA
B B
- PHS-SCCH(u) is the allocated power for HS-SCCH channel of user u

B B
- NHS-PDSCH is the number of HS-PDSCH codes computed as below.

B B
If more than one user to be scheduled for the next TTI, then NHS-PDSCH is equal to B B
the total number of HS-PDSCH codes (Ntotal). Else, NHS-PDSCH is the minimum B B
between the total number of HS-PDSCH codes and the UE capability (Nue capability) B B

in other words, the maximum number of HS-PDSCH that a UE of a given category
can manage:
NHS-PDSCH = min(Ntotal; Nue capability)
B B B B B B
The HSDPA power that is allocated in each TTI is calculated as shown in Figure 8. X X
Figure 8 - HS-DSCH Power
3.1.7 SCHEDULER
3.1.7.1 ALGORITHM
As described in the Figure 9, MAC-hs scheduling consists of choosing the MAC-d
X X
flow (QId) to serve.
Figure 9 - MAC-hs scheduler overview

The QId is selected using radio conditions (CQI) and service priority (SPI) criteria.
The selection of a QId to be scheduled is based on a single cost function.
The BSR uses a Proportional Fair Algorithm, with modification to support QoS
considerations and guaranteed bit rate, to inform user/priority queue scheduling
and takes as input both CQI and SPI.
The diagnostics considered by the scheduling algorithm considers:

• User Priority Queue (PQ) throughput
• User Priority Queue occupancy
• User CQIs
• Transmission information (number of codes, UE, PQ and HARQ ID etc)
• Flow Control
• Various events, e.g hitting maximum number of HARQ re-transmissions,
timer expiry.
A typical proportional fair algorithm calculates a scheduling metric based on

supportable and achieved throughput.
SupportableUEThroughput A
proportionalFairScheduling =
AveragePQThroughput B
A and B can make the algorithm completely general

• A=1, B=0 : Maximum C/I scheduler
• A=0, B=1 : Fair Throughput scheduler
• A=1, B=0.75 : typical set-point
The BSR MAC-hs scheduler makes a compromise on the typical values, setting
both A and B to 1, but extending the average throughput figure to accommodate
QoS considerations (priority indicator and guaranteed bit rate) and adding a further
weighting term.
CQIDerivedSupportableUEThroughput
MAC − hsScheduling = weight
Tnormalized
Tnormalised = averaged user throughput for the PQ normalised by a

nominal throughput value for this PQ. The nominal value is the guaranteed
bitrate (where defined) or a value derived from the scheduling priority
indicator.

Weight = The HSDPA Scheduling Priority weighting factor.
Once a user is chosen to be scheduled according to the algorithm cost function,

the scheduler selects for this user a TFRC (transport block size, number of HS-
PDSCH and modulation) based on the reported CQI and by taking into account the
available resources in term of power and codes.
Restriction: Performance Limitation
The MAC-hs scheduler has an inbuilt traffic class QoS management with static SPI weights defined
per traffic class. The QoS differentiation cannot be disabled in the BSR HSDPA scheduler.
MAC-ehs is a feature specified in 3GPP Release 7 [3GPP_R10] and is required for

XRR X
64-QAM. MAC-ehs is a new MAC-hs layer that brings several enhancements and
simplification as shown in Figure 10. It allows support of MAC-d PDUs (Packet
X X
Data Units) of different sizes and the segmentation of MAC-d PDUs. In addition, it
allows scheduling several priority queues of the same UE in the same TTI.
Figure 10 – MAC-ehs frame building process
3.1.7.2 QOS MANAGEMENT

The HSDPA Scheduling Priority SPI is statically defined according to a mapping
table using RAB parameters (Traffic Class & THP) received from the CN.
The SPI contributes linearly to the user average throughput.
In BSR the HSDPA SPI is set as shown in Table 2. X X

Traffic Class (THP) HSDPASchedulingPriority
Background(NA) 11
Interactive(1) 14
Interactive(2) 13
Interactive(3) 12
All other Traffic Classes(&
15
other THP values)
Table 2 - HSDPA SPI

3.1.7.3 FLOW CONTROL

The BSR HSDPA MAC-hs implements a capacity allocation scheme whereby the
upper layers (RLC/MAC) are granted permission (i.e. capacity credits) to transmit
on a HS RAB for a given UE.
A capacity allocation is expressed as a number of credits allocated over an
allocation interval and repeated according to a number of repetitions.
For each user is allocated a certain memory for priority queues (PQs) to store all
MAC-d PDUs and time of arrival data. This memory is divided between however
many PQs the user has.
In each TTI all PQ are checked and will be given a corresponding capacity
allocation.
3.1.8 TRFC MANAGEMENT
3.1.8.1 RLC PDU SIZE MANAGEMENT

The 336 bits RLC PDU configuration might limit the UE throughput (especially for
higher UE categories) due to UE processing capabilities (too many PDUs to
handle) or due to RLC stalling (RLC window size is limited to 2047 PDU) in case of
a too high round-trip delay. So, a RLC PDU of 656 bits will allow a higher user
throughput.
To enable the support of RLC PDU size of 656 bits for HSDPA the parameter
support656bitsHSDSCHFlag must be set to True.
The list of the HSDPA UE categories that will support RLC PDU size 656 bits is
defined by in support656bitsRLCPDUUECategory.

Parameter support656bitsHSDSCHFlag
Object Lcell
{True, False}
Class Class 3
Value TRUE
Parameter ueCategory
Object support656bitsRLCPDUUECategory
Granularity support656bitsRLCPDUUECategory
{category1=1, category2=2, category3=3, category4=4,
category5=5, category6=6, category7=7, category8=8,
category9=9, category10=10, category11=11,
category12 =12, category13=13, category14=14,
category15=15, category16=16, category17=17,
category18=18, category19=19, category20=20}
Class Class 3
Value See the engineering recommendation
Engineering Recommendation: support656bitsRLCPDUUECategory
For improved end user throughput the 656 bits RLC PDU size should be set at least for UE
categories 7, 8, 9 and 10.
Support for flexible RLC sizes in the downlink is a 3GPP Release 7 feature and
can only be used with MAC-ehs. With RLC flexible mode, the Femto determines
the size of the RLC PDU independently of the other RLC PDUs respecting the
maximum PDU size supported, which can be up to 1503 octets (i.e. an Ethernet IP
packet + Packet Data Convergence Protocol (PDCP) header). It allows the use of
big PDU sizes and avoids the need for padding the data to fit a fixed PDU size.
Support of flexible RLC is optional in the UE and the UE informs the Femto
application of its capabilities in the RRC CONNECTION SETUP COMPLETE
message. A UE that supports MAC-ehs also supports flexible RLC sizes and
therefore no explicit message is required for flexible RLC support.
When flexible RLC PDU sizes are supported, the Length Indicator (LI) field in the
RLC header is fixed to 7 or 15 bits and this is configurable through the parameter
HSDPA::rLCLengthIndicatorSize.

Parameter rLCLengthIndicatorSize
Object HSDPA
{bits7=7, bits15=15}
Class Class 3
Value bits15
3.1.9 DYNAMIC CODE ALLOCATION

The DL Channelization Code Tree is used to manage the DL Channelization codes to each
DL channel within a Cell. For Common Channels and R99 UEs individual codes are
allocated to each channel/user whereas for UEs using HSDPA the downlink traffic is
carried over a number of shared (HS-DSCH) channels.
The code tree has a fixed capacity and, as such, is one of the resources that limit the DL
cell Capacity. With the dynamic nature of code allocation/deallocation due to user traffic it
is important to manage carefully the codes within the code tree to ensure that the
maximum capacity is always available.
The DL Channelization Code tree is organised into 3 distinct sections; the codes available
to common channels, the codes available to R99 users and the codes available to HSDPA
users.
Figure 11 - HS-DSCH Dynamic Code Allocation
The feature Dynamic Code Allocation is to dynamically change the size of the sections of
the DL Channelization code tree available to R99 or HSDPA users based on the requested
traffic types. This will allow a more efficient sharing of DL Channelization Codes between
R99 and HSDPA users.

The BSR evaluates the allocation of codes to R99 and HSDPA users every time a DL
Channelization code is allocated, or deallocated, for a R99 channel and adjusts the sizes
of the sections available to R99 and HSDPA users by changing the number of HS-DSCH
channels. On the release of a code allocated to a R99 channel, RAB or RRC release, the
BSR evaluates if the number of HS-DSCH channels needs to be changed.
The flag to enable/disable the feature Dynamic Code Allocation is set through the
parameter dcaEnabled.
Parameter dcaEnabled
Object BSR Profile
{True, False}
Class Class 3
Value TRUE
The BSR supports a maximum and a minimum number of SF16 codes able to be allocated
to HSDPA which are configurable by the parameters minNumberOfHSDSCHCode and
maxNumberOfHSDSCHCode and the BSR automatically configures itself to use a
number between these two limits based on the current traffic profile.
Parameter minNumberOfHSDSCHCode
Object LCell::HSDPA
[1..15]
Class Class 3
Value 5
Parameter maxNumberOfHSDSCHCode
Object LCell::HSDPA
[1..15]
Class Class 3
Value 15
At initialization time, and when there are no calls present, the BSR allocates an initial
number of HSDSCH codes as defined by initialNumberOfHSDSCHCode.

Parameter initialNumberOfHSDSCHCode
Object LCell::HSDPA
[1..15]
Class Class 3
Value 10
Engineering Recommendation: minNumberOfHSDSCHCode
It is not recommended to set minNumberOfHSDSCHCode > 5 since the minimum number of

codes reserved for HSDPA is fixed and is not available for DCH users.
Setting minNumberOfHSDSCHCode = 5 guarantees a minimum capacity for HSDPA users and
suites 4, 8 and 16 DCH users.

3.2. HSUPA (E-DCH)
3.2.1 INTRODUCTION
High Speed Uplink Packet Access (HSUPA) functionality was introduced in
Release 6 of 3GPP. It extends the R99 UL capability providing a path to achieve
more than 384 kbps which was the limit of R99 and it complements HSDPA which
was introduced in release 5 of 3GPP to enhance DL packet rates.
HSUPA provides a higher data packet throughput in the UL with a theoretical peak
data rate specified up to 5.74 Mbps, depending on the capability of the UE.
Furthermore HSUPA allows a dynamic pooling of resources and can improve
coverage and round trip delays compared to R99 DCH. It is achieved through fast
physical layer HARQ with incremental redundancy and fast scheduling.
HSUPA adds a new dedicated transport channel in the UL and 2 new grant
channels in the DL.
The feature Full Rate HSPA provides the means to increase the E-DCH UL data
rate up to 5.74 Mbps.

To activate HSUPA, the parameter activateEDCH has to be set to True.
Feature activation and deactivation is not supported on the fly for E-DCH or
HSDPA. Therefore the resources for E-DCH are always to be created at start up.
Activating them later would result in service interruption.
Parameter activateEDCH
Object Femto | BSR
{True, False}
Class Class 0
Value TRUE
Rule: E-DCH activation
E-DCH can only be activated in the cell if HSDPA is activated.
The maximum number of HSUPA users per BSR is configurable through the
parameter EDCH::maxEdchUsersPerCell.

Parameter maxEdchUsersPerCell
Object LCell::EDCH
[0..64]
Class Class 3
Value 64
Inter-Release Delta: Feature 119860 – 32 User capacity on V2 Enterprise and Metro cell
If SF16 code 1 is to be freed, E-DCH is activated and the number of HSUPA users is greater than
19, then when HSDPA codes are configured through the Physical Shared Channel Reconfiguration
message a 2nd E-HICH/RGCH code is also configured.
P P
Engineering Recommendation: maxEdchUsersPerCell
It is recommended to set this value higher than the one supported by all the BSRs deployed in the
cluster. If maxEdchUsersPerCell is set to a value greater than the maximum supported by the HW
the SW automatically caps its value (refer to [Vol. 2]). XRR X
Restriction: Limitation on 16users BSRs with 2ms activated
In BCR2.4, the maxEdchUsersPerCell should be set according to the following table:
TTI maxEdchUsersPerCell
2ms 8 users
10ms 16 users
The OAM eDCH2msActivation parameter is used to indicate whether 2ms TTI in

E-DCH is activated. It will only apply to BSRs supporting UE Category 4 or 6.
Parameter eDCH2msActivation |
Object EDCH |
{True, False}
Class Class 0
Value TRUE

Restriction: 2ms – Demonstration Feature
In BCR2.4, the BSR only supports 2ms for demonstration purposes.
Engineering Recommendation: sparePara35
It is recommended to set sparePara35 to “allowSimB=0;allowHI=0” in order to force PS to 10ms

when CS is present and when incoming handover occurs.
Parameter sparePara35
Object BSR Profile
Range & Unit String
Class Class 3
Value -
The parameter eDCHmaxCatPerf determines the maximum E-DCH UE category

performance that is supported by the BSR. This value is capped by the maximum
capability of the BSR platform.
Parameter eDCHmaxCatPerf |
Object EDCH |
[1..6]
Class Class 0
Value 6
The maximum UL cell throughput for E-DCH (capped by the platform capability) is
defined through the parameter maxEdchCellRate.
Parameter maxEdchCellRate |
Object EDCH |
Range & Unit Integer (kbps)
[0..6000]
Class Class 0
Value 5740
3.2.3 RAB COMBINATIONS

The RAB combinations supported by the BSR are presented in Table 3. X X

UL SRB I/B (UL / DL) Conversational (UL / DL)
UL SRB over DCH E-DCH HDSPA 12.2 12.2
UL SRB over E-DCH E-DCH HDSPA
Table 3 - Service Combinations with E-DCH
3.2.4 SELECTION OF E-DCH AS THE CHANNEL TYPE

During PS RAB establishment the BSR selects E-DCH as the target channel based
upon the following rules:
• The UE is E-DCH capable;
• HSDPA is active and HSDPA resources are available in the DL towards
the UE in order to consider E-DCH UL;
• Feature activation flag BSR::activateEDCH =TRUE;
• This call results in the number of users on EDCH being less than or equal
to EDCH::maxEdchUsersPerCell.
If all of these conditions are met then the BSR sets up the UE on E-DCH.
Rule: SRB Mapping
• The SRB is mapped onto an E-DCH when there is DCCH+PS.

• The SRB is mapped onto a DCH when there is DCCH+PS+CS.
3.2.5 FEMTO SPECIFICITY - DEFINITIONS

In [3GPP_R10] the following definitions can be found:
XRR X
• Serving E-DCH cell: Cell from which the UE receives absolute grants from
the Node B scheduler. A UE has one serving E-DCH cell.
• Serving E-DCH RLS or serving RLS: Set of cells which contains at least
the serving E-DCH cell and from which the UE can receive and combine
one relative grant (RG). The UE has only one serving E-DCH RLS (Radio
Link Set).
From these definitions there are three categories of users to be handled by the E-
DCH scheduler, as follows:
• Serving users are the users for which the cell controlled by the scheduler
acts as the serving E-DCH cell. These are the users, which are under full
control of the scheduler, because they are controlled by absolute grants

sent on E-AGCH (Enhanced Access Grant Channel) and/or dedicated
relative grants sent on E-RGCH (Enhanced Relative Grant Channel).
• Non-serving users are the users for which the cell controlled by the
scheduler does not act as the serving cell and for which that cell is not part
of the serving E-DCH RLS. These users can only be controlled by sending
common relative grants on E-RGCH. Usually, non-serving users are
controlled by a scheduler outside the Node B.
• Peer-serving users are the users for which the cell controlled by the
scheduler does not act as the serving cell, but for which that cell is part of
the serving E-DCH RLS. These users are controlled by another scheduler
within the same Node B. The scheduler can control those users by sending
a Node B internal overload indicator.
Restriction: BSR Specifics
Due to the fact that the BSR is acting as a one cell NodeB and does not support SHO, the only
user type that is to be considered is the serving users. Other types (Non-serving users and Peer-
serving users) as defined by 3GPP cannot be found.
For the same reasons, the Serving E-DCH RLS will only consist of the BSR cell.
3.2.6 HSUPA UE CATEGORIES

For HSUPA, the following UE categories have been specified in [3GPP_R07] and XRR X
displayed in Table 4. The resulting maximum HSUPA throughput for each UE

X X
category is given in Table 5.

X X
These figures will be halved in case CS Voice Calls are made in parallel to the E-
DCH Packet call. The Spreading Factor will be reduced to SF4 and the
performances correspondingly.
E-DCH Maximum Minimum Support for Maximum number of
category number of spreading TTI E-DCH bits of an E-DCH
E-DCH factor transport block
codes transmitted within a E-
transmitted DCH TTI
Category 1 1 SF4 10 ms 7110

Category 2 2 SF4 10 ms / 2 ms* 14484 / 2798
Category 4 2 SF2 10 ms / 2 ms 20000 / 5772
Category 6 4 SF2 10 ms / 2 ms 20000 / 11484
Table 4 - E-DCH UE categories [3GPP_R07] XRR X

E-DCH Minimum Support for Maximum Data Rate Maximum RLC
category spreading TTI E-DCH at MAC-e layer throughput
factor
Category 1 1xSF4 10 ms 0.71 Mbps 0.67 Mbps

Category 2 2xSF4 10 ms / 2 ms* 1.45 Mbps / 1.40 Mbps 1.38 Mbps / 1.28 Mbps
Category 4 2xSF2 10 ms / 2 ms 2.0 Mbps / 2.89 Mbps 1.89 Mbps / 2.72 Mbps
Category 6 2xSF2+2xSF4 10 ms / 2 ms 2.0 Mbps / 5.74 Mbps 1.89 Mbps / 5.44 Mbps
Table 5 - Maximum E-DCH Throughput [3GPP_R07] XRR X
* The 2ms TTI sub-option of Category 2 is not supported; primarily due to its limited
gains (throughput is reduced).
3.2.7 TRANSPORT AND PHYSICAL CHANNELS

HSUPA introduces one new transport channel and three new physical channels in
downlink for E-DCH.
The physical and transport channels introduced for E-DCH are following:
• E-DCH - Enhanced Dedicated Transport Channel
• E-DPDCH (Enhanced Dedicated Physical Data Channel) - UL physical
dedicated E-DCH data channel
• E-DPCCH (Enhanced Dedicated Physical Control Channel) - UL physical

dedicated E-DCH control channel
• E-AGCH - DL Absolute Grant Channel
• E-RGCH - DL Relative Grant Channel

• E-HICH (Enhanced Hybrid ARQ Indicator Channel) - DL HARQ Indicator
Channel
Details of the channel structures can be found in [3GPP_R06]. XRR X
The transport channel E-DCH (Enhanced Dedicated Channel) carries the user data
in the uplink direction. It is associated with an uplink/downlink DPCH for each UE
to carry physical layer signalling, e.g. for UL power control, as well as higher layer
signalling information (but this can also be carried over E-DCH directly). The E-
DCH transport channel is characterized by:
• Only for UL
• TTI: 2ms or 10ms

• Transport block size and Transport Block set size are free attributes of the
transport format.

• Possibility of HARQ process with retransmission procedures applied. The
maximum allowed number of retransmissions is defined via
eDCHMACdFlowMaxRet parameters.
• Support of E-DCH HARQ retransmissions of type “Incremental

Redundancy”.
• Turbo coding with rate 1/3 is used
• CRC (Cyclic Redundancy Check) is 24 bits length
• E-TFCI (Transport Format Combination Indication) indicates which format
is currently used for the UL transmission
E-
E- AG
E- HI CH
DP C H
DC , E
H/ - R G
UL E- C
/D DP H
L CC
DP H
CH
Cell A
= Serving
E-DCH cell UE
Figure 12 - HSUPA channels and associated R99 channels
Parameter eDCHMACdFlowMaxRet
Object EDCHMACdFlow
Granularity EDCHMACdFlow
[0..15]
Class Class 3
Value 3 [10ms TTI]; 5 [2ms TTI]
3.2.7.1 UPLINK CHANNELS

E-DPDCH (Enhanced Dedicated Physical Data Channel): This channel is an
U U
uplink channel used to carry E-DCH user data in terms of MACe PDUs. Depending
on the E-DCH capability class that the UE supports, up to 4 E-DPDCHs, with a
spreading factor combination of 2xSF2 and 2xSF4, are allowed by the standards.

The channel coding uses 1/3 Turbo code with a channel bit rate of a single E-
DPDCH which ranges from 15kbps (SF=256) up to 1920kbps (SF=2).
E-DPCCH (Enhanced Dedicated Physical Control Channel): This channel

U U
associated with the E-DPDCH is a single E-DPCCH and carries the UL signalling
information. This is composed of the E-TFCI (7 bits), which is related to the E-
DPDCH transport block size, the Retransmission Sequence Number - RSN (2 bits),
which is related to the number of retransmissions and the Happy Bit (1 bit), which
can be used as a kind of scheduling request. The spreading factor is SF = 256 and
channel rate is 15kbps.
The E-DPDCH and E-DPCCH (sub) frame structure is presented on Figure 13. X X
E-DPDCH Data, Ndata bits
k
Tslot = 2560 chips, Ndata = M*10*2 bits (k=0…7)
E-DPCCH 10 bits
Tslot = 2560 chips
Slot #0 Slot #1 Slot #2 Slot #3 Slot #i Slot #14
Subframe #0 Subframe #1 Subframe #2 Subframe #3 Subframe #4
1 subframe = 2 ms
1 radio frame, Tf = 10 ms
Figure 13 - E-DPCCH / E-DPDCH frame structure
On uplink, each radio frame is divided in 5 sub frames, each of length 2 ms.
Different E-DPDCH and E-DPCCH slot formats have been defined as shown in
Table 6 and Table 7.
X X X X

Slot Format #i Channel Bit Rate Bits/Symbol SF Bits/ Bits/ Bits/Slot
(kbps) M Frame Subframe Ndata
B B
0 15 1 256 150 30 10
1 30 1 128 300 60 20
2 60 1 64 600 120 40
3 120 1 32 1200 240 80
4 240 1 16 2400 480 160
5 480 1 8 4800 960 320
6 960 1 4 9600 1920 640
7 1920 1 2 19200 3840 1280
8 1920 2 4 19200 3840 1280
9 3840 2 2 38400 7680 2560
Table 6 - E-DPDCH slot formats
Slot Format #i Channel Bit Rate (kbps) SF Bits/ Frame Bits/ Sub frame Bits/Slot
Ndata
B B
0 15 256 150 30 10
Table 7 - E-DPCCH slot formats
Figure 14 illustrates the spreading operation for the E-DPDCHs and the E-DPCCH,
X X
using the gain factor βec and βed,k and the channelization codes cec and ced,k.
The transmit power of both channels, is given as power offsets to UL DPCCH.

The E-DPCCH power offset eDPCCHPowerOffset is used to calculate the E-
DPCCH gain factor as defined in [3GPP_R11].XRR X
Parameter eDPCCHPowerOffset |
Object ETFCS |
Granularity ETFCS
[0..8]
Class Class 3
Value 4
The translation of the signaled values for the eDPCCHPowerOffset into amplitude
ratio is given in Table 8.
X X
Signalled values for Quantized amplitude ratios

Δ E-DPCCH
B B Aec = βec/βc
B B B B B B
8 30/15
7 24/15
6 19/15
5 15/15
4 12/15
3 9/15
2 8/15
1 6/15
0 5/15
Table 8 - Quantization for ΔE-DPCCH B B

The power offset for E-DPDCH depends on:
• the used MAC-e transport size or E-TFCI (E-DCH Transport Format
Combination Indicator)
• the signaled reference E-TFCIs and reference power offsets
• the signaled HARQ power offset.
The translation of ΔE-DPDCH into quantized amplitude ratios is specified in Table 9.

B B X X
This calculation is explained in more details in 3.2.10. XRR X
In UL the UE can use the whole channelization code-tree. The E-DPCCH is spread
using the channelization code Cch,256,1 (I-branch). [3GPP_R12] provides the XRR X
channelization code allocation for the E-DPDCH and more details for the
associated DPCCH/DPDCH and HS-DPCCH.
Signalled values for Δ E-DPDCHB B Quantized amplitude ratios Aed = βed/βc B B B B B B
29 168/15
28 150/15
27 134/15
26 119/15
25 106/15
24 95/15
23 84/15
22 75/15
21 67/15
20 60/15
19 53/15
18 47/15
17 42/15
16 38/15
15 34/15
14 30/15
13 27/15
12 24/15
11 21/15
10 19/15
9 17/15
8 15/15
7 13/15
6 12/15
5 11/15
4 9/15
3 8/15
2 7/15
1 6/15
0 5/15
Table 9 - Quantization for ΔE-DPDCH B

ced,1 β ed,1 iqed,1
E-DPDCH1
.
.
.
. ced,k β ed,k iqed,k
E-DPDCHk
Σ
.
. I+jQ
.
Se-dpch
. ced,K β ed,K iqed,K
E-DPDCHK
cec β ec iqec
E-DPCCH
Figure 14 - Spreading for E-DPDCH/E-DPCCH
The Transmit processing chain for the E-DPDCH depicted on Figure 15 is detailed X X
in [3GPP_R13].
XRR X
At first a CRC of 24 bits is attached to the MAC-e PDU. Then, segmentation is

done, where the maximum block size will be 5114 bits which is required for the
Turbo coding. The E-DPDCH applies a Turbo code of a fixed rate R = 1/3. All
transmissions and retransmissions have the same coding rate. The first
transmission is self-decodable. The hybrid ARQ (HARQ) functionality matches the
number of bits at the output of the channel coder to the total number of bits of the
E-DPDCH set to which the E-DCH transport channel is mapped. The HARQ
functionality is controlled by the redundancy version (RV) parameters. This is either
tied to RSN, Connection Frame Number (CFN) and sub-frame number or to a fixed
index RV = 0 (i.e. Chase combining). The coding rate and the number of multi-
codes are given by standard algorithms from the transport block size and E-
DPDCH SF according to the puncturing limit and the maximum channelization
codes configured as described in [3GPP_R13].The puncturing limit is defined per
XRR X
service profile (ETFCS) with the parameter punctureLimit.
These parameters are sent by RRC to the UE (using IE “E-DPDCH Info”).

Mac-e PDU
CRC attachment
Code block segmentation
Channel Coding
(r=1/3)
Physical Layer Hybrid-ARQ

functionality/Rate matching
Physical Channel
Segmentation
Interleaving &
Physical channel mapping
E-DPDCH
Figure 15 - E-DPDCH Channel Coding
Parameter punctureLimit |
Object ETFCS |
Granularity ETFCS
Range & Unit Real
[0.44,0.48..1.00]
Class Class 3
Value 0.72 [10ms TTI]
0.8 [2ms TTI]
3.2.7.2 DOWNLINK SIGNALING CHANNELS

E-AGCH (E-DCH Absolute Grant Channel): This single DL channel carries the
U U
absolute grant scheduling, which represents the maximum E-DPDCH/DPCCH

power ratio (5 bits) and includes HARQ process activation flag (1 bit). It is a shared
or dedicated fixed rate channel (30 kbps) with a spreading factor SF=256. To

identify the user a 16 bit CRC is attached. The control information on E-AGCH is
convolutional encoded with a rate of 1/3. Figure 16 illustrates the frame and sub-
X X
frame structure of the E-AGCH
E-AGCH 20 bits
Tslot = 2560 chips
Slot #0 Slot #1 Slot #2 Slot #i Slot #14
1 subframe = 2 ms
Figure 16 - E-AGCH frame structure
An E-DCH absolute grant is transmitted over one E-AGCH sub-frame or one E-

AGCH frame. The transmission over one E-AGCH frame is used for UEs for which
E-DCH TTI is set to 10 ms. 6 bits are used to code Access Grant values. One 16
bits CRC (xored by UE id) is attached to the AG value to form one 22 bits word. A
rate 1/3 convolution coding (constraint length 9) is then used leading to a total of
90 protected bits. A specific puncturing scheme is then applied to finally select a 60
bits sequences (30 bits are removed). With this kind of mechanisms only one UE
can be touched at each E-DCH TTI.
E-RGCH (E-DCH Relative Grant Channel): This single dedicated DL physical

U U
channel (combined with E-HICH) carries the relative to the last allocated UL
resources, scheduling grants (RG = UP, DOWN, HOLD). It has a fixed spreading
factor of SF=128. E-HICH and E-RGCH for the same user are on the same code.
The structure of the E-RGCH is the same than the one used for E-HICH channel
and is given in Figure 17.
X X
Note: E-AGCH (Absolute Grant Channel) and E-RGCH (Relative Grant Channel)
U U
in DL to indicate to the HSUPA UE (individually or per group) what are their

allocated UL resources.
A relative grant is transmitted using 3, 12 or 15 consecutive slots and in each slot a

sequence of 40 ternary values is transmitted. The 3 and 12 slot duration are used
on an E-RGCH transmitted to UEs for which the cell transmitting the E-RGCH is in
the E-DCH serving radio link set and for which the E-DCH TTI is respectively 2 and
10 ms. The 15 slot duration is used on an E-RGCH transmitted to UEs for which
the cell transmitting the E-RGCH is not in the E-DCH serving RLS.

The sequence bi,0, bi,1, …, bi,39 transmitted in slot i in Figure 17 is given by
X X
bi,j = a Css,40,m(i),j.
The orthogonal signature sequences Css,40,m(i) is given in [3GPP_R06]
B B XRR X
In a serving E-DCH RLS, the relative grant a is set to +1, 0, or -1 and in a radio link
not belonging to the serving E-DCH RLS, the relative grant a is set to 0 or -1.. The
E-RGCH signature sequence index l is given by higher layers.
bi,0 bi,1 bi,39
Tslot = 2560 chip
Slot #0 Slot #1 Slot #2 Slot #i Slot #14
1 subframe = 2 ms
Figure 17 - E-RGCH and E-HICH structure
Restriction: E-RGCH (E-DCH Relative Grant Channel)
The BSR does not support common relative grants.
E-HICH (E-DCH HARQ Acknowledgement Indicator Channel): This single

U U
dedicated DL channel (combined with E-RGCH) carries the HARQ

acknowledgements (ACK/NACK channel) form the HARQ function in the BSR. It
has a spreading factor SF=128.
The structure of the E-HICH channel is given in Figure 17. X X
A hybrid ARQ acknowledgement indicator is transmitted using 3 or 12 consecutive

slots and in each slot a sequence of 40 binary values is transmitted. The 3 and 12
slot duration are used for UEs which E-DCH TTI is set to respectively 2 ms and
10 ms.
The sequence bi,0, bi,1, …, bi,39 transmitted in slot i in Figure 17 is given by

X X
bi,j = a Css,40, m(i),j.

The orthogonal signature sequences Css,40,m(i) is given in [3GPP_R06]
B B XRR X
In a RLS containing the serving E-DCH radio link set, the hybrid ARQ
acknowledgement indicator a is set to +1 or -1, and in a RLS not containing the

serving E-DCH radio link set the hybrid ARQ indicator a is set to +1 or 0. The E-
HICH signature sequence index I is given by higher layers.
3.2.8 PRINCIPLE OF E-DCH OPERATION

The principle of E-DCH operation is presented in Figure 18. Following steps are
X X
performed:
• If the UE has data in its buffer and doesn’t have a serving grant yet, it sends
scheduling information (SI) via MAC-e signaling to the BSR. The SI can also
be periodically requested, e.g. every 100 ms (configurable parameter). The SI
contains the current buffer status of the UE as well as the remaining power
headroom.
• After reception of the SI the scheduler will activate the UE by sending an
absolute grant (AG) to the UE.
• A serving grant is a power offset to the associated DPCCH. If the UE is
activated and has a serving grant assigned, it is allowed to transmit data up to
that power offset. In every E-DPDCH transmission the UE reports a Happy Bit
on E-DPCCH to inform the E-DCH scheduler when the UE has data buffered.
• Once the decoding of the potentially combined data is completed for the E-
DPDCH, the BSR sends an ACK/NACK indicator in the downlink direction,
depending on the outcome of the CRC check on MAC-e PDU.
• For each serving user, the BSR collects the following measurements:
o Average Ec/Io measured on DPCCH
o Average served MAC-e transport block size
o Happy Bit
o Reference scheduling grant
• For each cell the following common value is calculated:
o Average received total wideband power (RTWP)
• From the cell measurement above, the available load for E-DCH is determined.
• If no resources are available for E-DCH (available E-DCH load <= 0) the
current E-DCH users are reduced (overload condition). Otherwise, the Happy
Bit is used to calculate the requests. If “unhappy” is reported then the current
reference scheduling grant is increased by applying relative grants.
• If the RTWP load is lower than the target RTWP, all requests can be granted
and the relative grants can be send to the UEs. Otherwise, some requests
have to be downgraded according to the following priorities:
o Downgrade serving users: Here, a proportional fair rule is applied to
sort the users, so that the UEs with lowest priority are downgraded
first.

• Finally, relative grants, which can have the values “UP,” “DOWN” or “HOLD”
are generated and send to the UEs.
• Depending on the received absolute or relative grants and the available UE
transmit power, the UE decides on the MAC-e transport block to be used in the
upcoming transmission.
UE NodeB
Scheduling information
UE detects Scheduler
data in buffer Scheduling grant
takes UE for
scheduling
DATA
Scheduling grant
Scheduling grant
Scheduling information
Figure 18 - Principle of E-DCH Scheduling, Scheduling Grants are in Terms of AG/RG
3.2.9 DL SCHEDULING INFORMATION - SERVING GRANTS
3.2.9.1 ABSOLUTE GRANTS

If the UE is in CELL_DCH state and E-DCH is configured, it maintains an internal
serving grant SG based on the received absolute grants and relative grants from
the BSR.
The SG values are quantized maximum E-DPDCH/ DPCCH power ratios (traffic-to-
pilot power ratio, TPR), which are defined in [3GPP_R10]. XRR X
On reception of absolute grants the UE will set: SG=AG

In the case the special AG value “Zero_Grant” is transmitted, for instance in the
case a UE stops transmitting for certain duration; the UE will be prohibited
transmission.
3.2.9.2 RELATIVE GRANTS

• Serving Relative Grant:

Transmitted on downlink on the E-RGCH from all cells in the serving E-DCH RLS,
the serving relative grant allows the BSR scheduler to incrementally adjust the
serving grant of UEs under its control. By definition, there can only be one serving
relative grant command received at any one time. This indication can take three
different values, "UP", "DOWN" or "HOLD".
When the Serving_Grant needs to be determined due to E-RGCH signalling, the

UE:
• Determines the lowest power ratio in the configured SG-table (Table 10) that is X X
equal or higher to the reference_ETPR (power ratio from previous TTI), and
determines the corresponding index in the SG-table: SGLUPR; B B
• If the UE received a Serving Relative Grant "UP", based on the thresholds "3-
index-step threshold" and "2-index-step threshold" configured by higher layers,
it determines the Serving_Grant as follows:
o if SGLUPR < "3-index-step threshold":
B B
Serving_Grant = SG[MIN(SGLUPR + 3 , 37)]. B B
o if "3-index-step threshold" <= SGLUPR < "2-index-step threshold":

B B
o if "2-index-step threshold" <= SGLUPR:: B B
• If the UE received a Serving Relative Grant "DOWN", determine the

Serving_Grant:
Serving_Grant = SG[MAX(SGLUPR -1 , 0)]. B B
• If the UE received a Non-serving Relative Grant "DOWN", determine the

Serving_Grant:
Serving_Grant = SG[MAX(SGLUPR -1 , 0)]. B B
The thresholds "3-index-step threshold" and "2-index-step threshold" are

configurable through the parameters eRGCH2StepThreshold and
eRGCH3StepThreshold.
Index Scheduled
Grant
37 (168/15)2*6 P P
36 (150/15)2*6 P P
35 (168/15)2*4 P P
34 (150/15)2*4 P P
33 (134/15)2*4 P P
32 (119/15)2*4 P P
31 (150/15)2*2 P P
30 (95/15)2*4 P P
29 (168/15)2 P P
28 (150/15)2 P P
27 (134/15)2 P P

26 (119/15)2 P P
25 (106/15)2 P P
24 (95/15)2 P P
23 (84/15)2 P P
22 (75/15)2 P P
21 (67/15)2 P P
20 (60/15)2 P P
19 (53/15)2 P P
18 (47/15)2 P P
17 (42/15)2 P P
16 (38/15)2 P P
15 (34/15)2 P P
14 (30/15)2 P P
13 (27/15)2 P P
12 (24/15)2 P P
11 (21/15)2 P P
10 (19/15)2 P P
9 (17/15)2 P P
8 (15/15)2 P P
7 (13/15)2 P P
6 (12/15)2 P P
5 (11/15)2 P P
4 (9/15)2 P P
3 (8/15)2 P P
2 (7/15)2 P P
1 (6/15)2 P P
0 (5/15)2 P P
Table 10 - Scheduling Grant Table
Parameter eRGCH2StepThreshold |
Object ETFCS |
Granularity ETFCS
[0..37]
Class Class 3
Value 18
Parameter eRGCH3StepThreshold |
Object ETFCS |
Granularity ETFCS
[0..37]
Class Class 3
Value 15
Therefore the E-RGCH is always referenced about the transmission power level in
the previous TTI whereas the E-AGCH will be an absolute level.

3.2.10 E-DCH TRANSPORT FORMAT COMBINATION (E-TFC)
SELECTION
The E-TFC selection is performed at each TTI. [3GPP_R10] provides with the full
XRR X
description of the E-TFC selection process.

UEs, configured with both DCH and E-DCH transport channels, perform TFC
selection before performing E-TFC selection.
The UE selects the transport format combination (E-TFC) in such a way, which
allows most data from highest priority to be transmitted. To do so, it first evaluates
the remaining power, PO_avail, left after legacy DCH selection.
The SG Update function will provide with the maximum E-DPDCH to DPCCH
power ratio that the UE is allowed to allocate for the upcoming transmission for
scheduled data.
The chosen TFC fulfils following requirements:

• The selected transport block size has to be lower or equal to the current buffer
occupancy of the UE.
• The power offset for the transmission is the one from the HARQ profile of the
MAC-d flow that allows highest-priority data to be transmitted.
• The power offset (PO) has to fulfill the condition: PO ≤ min(SG, PO_avail).
The mapping between PO (i.e. SG) and E-TFC (i.e. transport block size) is defined
in [3GPP_R11]. If needed, values will be interpolated based transmitted values of
XRR X
the reference E-TFCIs (ETFCtable::referenceETFC) and the corresponding

reference power offsets (ETFCtable::referenceETFCPowerOffset) as well as on
the HARQ power offset (eDCHMACdFlowHARQPO), which are signalled by RRC
to the UE. The HARQ power offset is set per MAC-d flow (EDCHMACdFlow).
Table 11 provides with the reference values.
X X
For throughput optimization when dealing with a 2ms TTI and 2xSF2+2xSF4, the
power offset tables for UE Category 6 (ETFCtableAlternative) were constructed
differently to avoid discontinuities in the power offset tables. Table 12 and Table 13X X X X
provides the power offset reference values for 2ms TTI.
Parameter ReferenceETFC
Object ETFCS::ETFCtable / ETFCS::ETFCtableAlternative
Granularity ETFCtable / ETFCtableAlternative

[0..127]
Class Class 3
Value See Table

Parameter ReferenceETFCPowerOffset
Object ETFCS::ETFCtable / ETFCS::ETFCtableAlternative
Granularity ETFCtable / ETFCtableAlternative

[0..29]
Class Class 3
Value See Table
Parameter eDCHMACdFlowHARQPO
Object EDCHMACdFlow
[0..6]
Class Class 3
Value 0 [10ms TTI]
5 [10ms TTI SRB]
2 [2ms TTI]
2 [2ms TTI SRB]
eTFCtable::ReferenceETFC eTFCtable::ReferenceETFCPowerOffset
3 10
9 13
25 17
Table 11 - 10ms Reference E-TFC Power Offset Information
eTFCtable::ReferenceETFC eTFCtable::ReferenceETFCPowerOffset
3 13
5 14
83 20
Table 12 - 2ms/2xSF2 Reference E-TFC Power Offset Information
eTFCtableAlternative::ReferenceETFC eTFCtableAlternative::ReferenceETFCPowerOffset
5 11
58 12
85 15
92 16
107 18
113 19
119 20
122 21
Table 13 - 2ms/2xSF2+2xSF4 Alternative E-TFC Power Offset Information

In case the UE has only to transmit scheduling information without any scheduled
data, it applies a “Control only” HARQ profile with a power offset value,
schedulingPowerOffset. This special HARQ profile uses a maximum number of
HARQ transmissions of 8.
Parameter schedulingPowerOffset |
Object ETFCS |
Granularity ETFCS
[0..6]
Class Class 3
Value 0
3.2.11 UL SCHEDULING INFORMATION

This control information is used by UEs to indicate to their serving E-DCH BSR the
amount of resources they require.
3.2.11.1 HAPPY BIT

The happy bit is a single bit field that is passed from MAC to the physical layer for
inclusion on the E-DPCCH for every E-DCH transmission. E-DCH transmissions
are not triggered specifically to allow the transmission of the happy bit.
This field takes two values, "Not Happy" and "Happy" indicating respectively
whether the UE could use more resources or not.
RRC configures MAC with the duration Happy_Bit_Delay_Condition, over which to
evaluate the current grant as described in [3GPP_R10]. XRR X
For every E-DCH transmission, the Happy Bit is set to "unhappy" if the three
following criteria are met:
1) UE is transmitting fully exploiting the current SG; and
2) UE has enough power available to transmit at higher data rate; and
3) Based on the current SG, the current buffer occupancy cannot be

emptied using the current data rate within the duration of
Happy_Bit_Delay_Condition.
Otherwise, the Happy Bit is set to "happy".

Parameter happyBitDelay |
Object ETFCS |
Granularity ETFCS
{happyBitDelay2=2, happyBitDelay10=10,
happyBitDelay20=20, happyBitDelay50=50,
happyBitDelay100=100, happyBitDelay200=200,
happyBitDelay500=500, happyBitDelay1000=1000}
Class Class 3
Value happyBitDelay10
3.2.11.2 SCHEDULING INFORMATION

The Scheduling Information is located at the end of the MAC-e PDU and is used to
provide the BSR with a better view of the amount of system resources needed by
the UE and the amount of resources it can actually make use of.
This information depicted in Table 10 includes the following fields:
X X
• Highest priority Logical channel ID (HLID):

The HLID field identifies unambiguously the highest priority logical channel with
available data. If multiple logical channels exist with the highest priority, the one
corresponding to the highest buffer occupancy will be reported. The length of the
HLID is 4 bits.
• Total E-DCH Buffer Status (TEBS):
The TEBS field identifies the total amount of data available across all logical
channels for which reporting has been requested by the RRC and indicates the
amount of data in number of bytes that is available for transmission and
retransmission in RLC layer. The length of this field is 5 bits.
• Highest priority Logical channel Buffer Status (HLBS):
The HLBS field indicates the amount of data available from the logical channel
identified by HLID, relative to the highest value of the buffer size range reported by
TEBS. The length of HLBS is 4 bits.
• UE Power Headroom (UPH):
The UPH field indicates the ratio of the maximum UE transmission power and the
corresponding DPCCH code power. The length of UPH is 5 bits.
Figure 19 - Scheduling Information format
Scheduling information reports are triggered differently depending on the value of

the variable Serving_Grant after the Serving Grant Update function.

• Report Triggering when SG = “Zero_Grant” (No data before)
o The transmission of Scheduling Information is triggered as soon as
there are data to transmit.
o If data with higher priority than the data already in the transmission
buffer arrives, the transmission of a Scheduling Information is
triggered.
o RRC can also configure a periodical reporting to protect against
NACK-to-ACK misinterpretation (timer T_SING (SI No Grant) is
used). The timer is started once the SG becomes "Zero_Grant"
and TEBS is larger than zero. When T_SING gets higher than
schedulingNoGrantPeriodicity, the transmission of a Scheduling
Information is triggered. T_SING is restarted when the
transmission of a SI is triggered. T_SING is stopped and reset
once the SG is different from "Zero_Grant".
o The scheduling information can be sent alone in MAC-e control
PDU, or together with non-scheduled data in the MAC-e header.
• Report Triggering when SG ≠ “Zero_Grant” (data already sent)

o If SG becomes too small to allow transmission of a single PDU
from any scheduled MAC-d flow and data are to be transmitted,
the transmission of Scheduling Information is triggered.
o If an E-DCH serving cell change occurs and if the new E-DCH

serving cell was not part of the previous Serving E-DCH RLS, the
transmission of a Scheduling Information is triggered.
o RRC can configure MAC with periodic triggering also for the case
when the variable Serving_Grant is different from "Zero_Grant".
The periodic trigger timer T_SIG (timer T_SING (SI Grant) can be
configured using schedulingGrantPeriodicity to a different value
than T_SING. T_SIG is started once the SG becomes different
from "Zero_Grant". When T_SIG expires, the transmission of a
new Scheduling Information is triggered. T_SIG is stopped and
reset once the SG equals "Zero_Grant. T_SIG is restarted when
the transmission of a Scheduling Information is triggered.
o Once the SG becomes equal to "Zero_Grant" and data are to be
sent, the transmission of a Scheduling Information is triggered.
o The scheduling information is sent together with scheduled data in
MAC-e header.

Parameter schedulingNoGrantPeriodicity |
Object ETFCS |
Granularity ETFCS
{everyEDCHTTI=0, schedulingPeriod4=4,
schedulingPeriod10=10, schedulingPeriod20=20,
schedulingPeriod1000=1000, noReport=2000}
Class Class 3
Value schedulingPeriod100
Parameter schedulingGrantPeriodicity |
Object ETFCS |
Granularity ETFCS
{everyEDCHTTI=0, schedulingPeriod4=4,
schedulingPeriod1000=1000, noReport=2000}
Class Class 3
Value schedulingPeriod100
3.2.12 AIR INTERFACE LIMITATION

The BSR applies enhanced UL load control in the MAC-e scheduler when the flag
enableEnhEdchLoad is set to True. The maximum noise rise for all UL users in
the own cell is lower than maxULNoiseRiseEnhEdchLoad.
The maximum noise rise for all UL users is determined by:
• DPCCH power;
• HS-DPCCH power and HS-EDPCCH power;
• DPDCH power;
• E-DPDCH power;
• Note: RACH signalling could be included, but is not considered necessary.

At the same time the maximum RTWP is set to maxUlRTWPEnhEdchLoad.
Figure 20 - E-DCH UL Load Control based upon noise rise of controlled noise sources
Parameter enableEnhEdchLoad
Object BSR Profile
{True, False}
Class Class 3
Value false
Parameter maxULNoiseRiseEnhEdchLoad
Object EDCH
[0..100]
Class Class 3
Value 8
Parameter maxUlRTWPEnhEdchLoad
Object EDCH
[-120..0]
Class Class 3
Value -70

Restriction: Feature 157240 – Enhanced Noise Rise Management - Hardware limitations
The feature Enhanced Noise Rise Management is only supported by V2.2 Enterprise and V2 Metro
(chip dependent).
In case the flag enableEnhEdchLoad is set to False, the Maximum Target

Received Total Wide Band Power ( 3.2.8), which is equivalent to the limitation of
XRR X
the air interface resources, is defined as

¾ Noise floor measurement+EDCH::maxULNoiseRiseEdch.
Figure 21 - E-DCH UL Load Control with high noise rise and enableEnhEdchLoad=False
This result is lower and upper bounded in the range defined by

{EDCH::eDCHminNoiseFloor, EDCH::eDCHmaxNoiseFloor} respectively.
This defines the upper RTWP limit used during the scheduling.
Note: The Noise floor measurement is described in [Vol. 4].

U U XRR X
Engineering Recommendation: Noise Floor
Current parameter values for EDCH::eDCHminNoiseFloor and EDCH::eDCHmaxNoiseFloor

ensures that the Maximum Target Received Total Wide Band Power is constant.

Parameter maxULNoiseRiseEdch
Object LCell::EDCH
[0..50]
Class Class 3
Value 20
Parameter eDCHminNoiseFloor
Object LCell::EDCH
[-112.0..-50.0] step 0.1
Class Class 3
Value -100
Parameter eDCHmaxNoiseFloor
Object LCell::EDCH
[-112.0..-50.0] step 0.1
Class Class 3
Value -100
3.2.13 E-DCH UPLINK CHANNEL POWER CONTROL

Transmit power control on E-DCH works similar to power control on R99 DCH. The
goal of E-DCH OLPC (Outer-Loop Power Control) algorithm is the control of the
number of HARQ retransmissions. The transmit power of the E-DCH channels (E-
DPCCH/ E-DPDCH) is tied to the transmit power of the DPCCH by power offsets
(as described in 3.2.7.1).
XRR X
An outer loop power control controls in the BSR the setting of the SIR targets.
In normal single user operation the target should be a very low number of HARQ
retransmissions to maximize throughput, but to drop the SIR target down far
enough to allow the UE to maximize the transport block size and user throughput.
To facilitate this, the outer loop power control will have a special step size for
reception of multiple zero HARQ retransmissions.
The SIR step will be based upon HARQ retransmissions and Failures on E-DCH
instead of BLER and QE for DCH.
The E-DCH outer loop power control entity is retrieved from one of three power
control profiles based upon the number of users.
When the number of E-DCH users is below Threshold1, the profile

eDCHMACdFlowSIRstepThr1 is to be used.

When the number of E-DCH users is between Threshold1 and Threshold2, the
profile eDCHMACdFlowSIRstepThr2 is to be used.
And when the number of E-DCH users is larger than Threshold2, the profile
eDCHMACdFlowSIRstepThr3 is to be used.
The change is applied to all outer loop power control entities in progress as calls
are setup and torn down to change the above criteria.
Threshold1 and Threshold2 can be modified through the parameters

EDCHMACdFlow::maxNumActiveEdchUsersPerCellForThr1 and
EDCHMACdFlow::maxNumActiveEdchUsersPerCellForThr2.
Following parameters can be configured for each power control profiles

eDCHMACdFlowSIRstepThr1, eDCHMACdFlowSIRstepThr2 and
eDCHMACdFlowSIRstepThr3 :
¾ sIRstep0HARQReTx, sIRstep1HARQReTx, sIRstep2HARQReTx,
sIRstep3HARQReTx and sIRstep4HARQReTx
¾ nbrOfConsecutiveZeroHARQReTxThreshold
¾ sIRstepConsecZeroHARQReTx
¾ sIRstepHfi
Table 14 provides with the values for the parameters of the three profiles.
X X
The E-DCH outer loop power control entity increments a counter C_Harq each time
it receives a MAC-es PDU that was received successfully at the first transmission.
Upon reception of a frame with Zero HARQ retransmissions and if the counter
C_Harq is greater than nbrOfConsecutiveZeroHARQReTxThreshold, the SIR
target will be incremented by sIRstepConsecZeroHARQReTx.
If the E-DCH outerloop power control entity receives a HARQ Failure Indication,
the SIR target will be incremented by sIRstepHfi.
If the E-DCH outer loop power control entity receives a frame which is not HARQ
Failure Indication, and the counter C_Harq is less than
nbrOfConsecutiveZeroHARQReTxThreshold, the SIR target will be set to one of
the value sIRstep{0,1,2,3,4}HARQReTx depending upon the number of
retransmissions (from 0 to 4 and more).
A final check is performed to verify that the SIR target is in the allowed range. In
case it is smaller, it will be set to the minimum value. In case it is higher, it will be
set to the maximum value.

Parameter maxNumActiveEdchUsersPerCellForThr1
Object EDCHMACdFlow
[0..64]
Class Class 3
Value 1 [10ms TTI]
64 [10ms TTI SRB]
1 [2ms TTI]
64 [2ms TTI SRB]
Parameter maxNumActiveEdchUsersPerCellForThr2
Object EDCHMACdFlow
[0..64]
Class Class 3
Value 3 [10ms TTI]
64 [10ms TTI SRB]
3 [2ms TTI]
64 [2ms TTI SRB]
Parameter eDCHMACdFlowSIRstepThr{1,2,3}sIRstep{0,1,2,3,4
}HARQReTx | sIRstep{0,1,2,3,4}HARQReTx
Object EDCHMACdFlow |
eDCHMACdFlowSIRstepThr{1,2,3}
Granularity EDCHMACdFlow |
[-10.000,-9.999..10.000]
Class Class 3
Value See Table
Parameter eDCHMACdFlowSIRstepThr{1,2,3}nbrOfConsecuti
veZeroHARQReTxThreshold |
nbrOfConsecutiveZeroHARQReTxThreshold
[0..1024]
Class Class 3
Value See Table

Parameter eDCHMACdFlowSIRstepThr{1,2,3}sIRstepConsecZ
eroHARQReTx | sIRstepConsecZeroHARQReTx
[-10.000,-9.999..10.000]
Class Class 3
Value See Table
Parameter eDCHMACdFlowSIRstepThr{1,2,3}sIRstepHfi |
sIRstepHfi
[-10.000,-9.999..10.000]
Class Class 3
Value See Table
eDCHMACdFlow eDCHMACdFlow eDCHMACdFlow

SIRstepThr1 SIRstepThr2 SIRstepThr3
sIRstep0HARQReTx 0.000 0.000 0.000
nbrOfConsecutive
ZeroHARQReTxThreshold 200 200 200
sIRstepConsecZeroHARQReTx -0.020 -0.020 -0.020
sIRstepHfi 0.150 0.150 0.150
Table 14 - eDCHMACdFlow parameter values
3.2.14 E-DCH DOWNLINK CHANNEL POWER CONTROL

The power for the E-HICH, E-AGCH and E-RGCH channels is given as power
offset values relatively to the P-CPICH Power.
The parameter eAGCHpowerOffset gives the power offset to be used to transmit
the E-AGCH. As E-RGCH is associated to the E-HICH, the parameter
eRgchHichPowerOffset provides the offset to be used.
These values are signalled in the Physical Shared Channel Reconfiguration.

Parameter eAGCHpowerOffset
Object LCell::EDCH
[-32.00,-31.75..31.75]
Class Class 3
Value 0
Parameter eRgchHichPowerOffset
Object LCell::EDCH
[-32.00,-31.75..31.75]
Class Class 3
Value 1.5

4. INDEXES
4.1. TABLE INDEX

Table 1 - HSDPA UE Categories RLC rate capabilities [3GPP_R07] ............................................... 9
TU RR UT
Table 2 - HSDPA SPI ....................................................................................................................... 19

TU UT
Table 3 - Service Combinations with E-DCH ................................................................................... 27

TU UT
Table 4 - E-DCH UE categories [3GPP_R07] ................................................................................. 28

TU RR UT
Table 5 - Maximum E-DCH Throughput [3GPP_R07] ..................................................................... 29

TU RR UT
Table 6 - E-DPDCH slot formats ...................................................................................................... 32

TU UT
Table 7 - E-DPCCH slot formats ...................................................................................................... 32

TU UT
Table 8 - Quantization for ΔE-DPCCH.................................................................................................... 32

TU UB UTB
Table 9 - Quantization for ΔE-DPDCH ................................................................................................... 33

TU UB UTB
Table 10 - Scheduling Grant Table .................................................................................................. 41

TU UT
Table 11 - 10ms Reference E-TFC Power Offset Information ......................................................... 43

TU UT
Table 12 - 2ms/2xSF2 Reference E-TFC Power Offset Information................................................ 43

TU UT
Table 13 - 2ms/2xSF2+2xSF4 Alternative E-TFC Power Offset Information................................... 43

TU UT
Table 14 - eDCHMACdFlow parameter values ................................................................................ 53

TU UT
4.2. FIGURE INDEX

Figure 1 - HSDPA channels and associated R99 channels ............................................................. 10
TU UT
Figure 2 - Timing relationship at BSR between physical channels .................................................. 11

TU UT
Figure 3 - HS-SCCH structure.......................................................................................................... 11

TU UT
Figure 4 - HS-PDSCH structure ....................................................................................................... 12

TU UT
Figure 5 - DL Channelisation Code Resources................................................................................ 12

TU UT
Figure 6 - HS-DPCCH structure ....................................................................................................... 13

TU UT
Figure 7 - Power distribution between HS-DSCH and HS-SCCH channels .................................... 14

TU UT
Figure 8 - HS-DSCH Power ............................................................................................................. 16

TU UT
Figure 9 - MAC-hs scheduler overview ............................................................................................ 16

TU UT
Figure 10 – MAC-ehs frame building process .................................................................................. 18

TU UT
Figure 11 - HS-DSCH Dynamic Code Allocation ............................................................................. 21

TU UT
Figure 12 - HSUPA channels and associated R99 channels........................................................... 30

TU UT
Figure 13 - E-DPCCH / E-DPDCH frame structure .......................................................................... 31

TU UT
Figure 14 - Spreading for E-DPDCH/E-DPCCH .............................................................................. 34

TU UT
Figure 15 - E-DPDCH Channel Coding ............................................................................................ 35

TU UT
Figure 16 - E-AGCH frame structure ................................................................................................ 36

TU UT
Figure 17 - E-RGCH and E-HICH structure ..................................................................................... 37

TU UT
Figure 18 - Principle of E-DCH Scheduling, Scheduling Grants are in Terms of AG/RG ................ 39
TU UT
Figure 19 - Scheduling Information format ....................................................................................... 45

TU UT
Figure 20 - E-DCH UL Load Control based upon noise rise of controlled noise sources ................ 48
TU UT
Figure 21 - E-DCH UL Load Control with high noise rise and enableEnhEdchLoad=False ............ 49
TU UT

Z END OF DOCUMENT Y

BCR IRC APP 026964 V3 00 - Femto Parameter User Guide BCR3 0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BCR IRC APP 026964 V3 00 - Femto Parameter User Guide BCR3 0

Uploaded by

Copyright:

Available Formats

Alcatel-Lucent

Femto Parameter User Guide 3.0

Alcatel-Lucent proprietary and confidential.

Copyright© 2010-2012 Alcatel-Lucent, All Rights Reserved

BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012

VOLUME 3 POWER MANAGEMENT

VOLUME 4 RADIO RESOURCES MANAGEMENT

VOLUME 5 MOBILITY MANAGEMENT

VOLUME 6 INCOMING MOBILITY

BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012

FEMTO PARAMETER USER GUIDE

BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012

2. RELATED DOCUMENTS ..............................................................................................................9

3. SMALL CELL MODEL ................................................................................................................10

4. FEMTO GATEWAY MODEL .......................................................................................................15

BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012 Page 1/23

1.2. SCOPE OF THE DOCUMENT

BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012 Page 2/23

Table 1 – Volume 2- Autoconfiguration Features

BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012 Page 3/23

83236 100 mWGeneric Standalone Femto 8Users Option BCR02.02

Table 2 - Volume 3 - Power Features

Feature Id Feature Title Activation Flag Basic/Option Release

Table 3 - Volume 4 - RRM Features

BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012 Page 4/23

Table 4 - Volume 5 - Mobility Features

Feature Id Feature Title Activation Flag Basic/Option Release

Table 5 - Volume 6 – Incoming Mobility Features

BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012 Page 5/23

Table 6 - Volume 10 - HSxPA Features

1.3. PRODUCT NAMING

1.3.1 SOLUTION NAME:

1.3.2 ACCESS POINTS:

¾ 9363 Metro Cell – Indoor (new product)

BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012 Page 6/23

• The parameter names are written in bold italic.

• The parameters properties for the BSR are presented as follow:

Parameter FMS Name | MIM Name

• The parameters properties for the FGW/BSG/BPG/BVG are presented as

Parameter FMS Name | MIM Name

BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012 Page 7/23

• The engineering recommendations on parameter value are presented as the

• The implementation process specific to FMS

BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012 Page 8/23

2.1. FPUG VOLUMES

2.2. 3GPP REFERENCE DOCUMENTS

[3GPP_R02] 3GPP TS 25.331 Radio Resource Control (RRC); protocol

[3GPP_R04] 3GPP TS 22.011 Service Accessibility

2.3. ALCATEL-LUCENT REFERENCE DOCUMENTS

BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012 Page 9/23

3. SMALL CELL MODEL

Inter-Release Delta: Hardware/Location Profiles

BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012 Page 10/23

Figure 1 - BSR FMS Model

BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012 Page 11/23

Figure 2 – BSR FMS Model (2)

BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012 Page 12/23

Inter-Release Delta: Hardware Profile

From BCR3.0 a new Profile, the Hardware Profile, is introduced in WiPS.

Figure 3 – Hardware Profile

Rule: Hardware Profile Naming Convention

It is mandatory to create for each BSR variant (MaxPowerCapacity/number of users ) a profile

BCR/IRC/APP/026964 03.00 / EN Preliminary 30/June/2012 Page 13/23

Inter-Release Delta: Location Profile