Femto Parameter User Guide BCR02

Femto Parameter User Guide BCR2.
2
Document number: Document issue: Document status: Date: BCR/IRC/APP/026964 02.02 / EN Preliminary 31/March/2010
EXTERNAL Document Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
Copyright 2010 Alcatel-Lucent, All Rights Reserved Printed in France
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 AlcatelLucent. 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.
Femto Parameter User Guide BCR2.2
Passing on or copying of this document, use and communication of its contents not permitted without AlcatelLucent written authorization
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 2/158
CONTENTS
1. INTRODUCTION............................................................................................................................6 1.1. 1.2. 1.3. 2. OBJECT ....................................................................................................................................6 SCOPE OF THE DOCUMENT ........................................................................................................6 NOMENCLATURE .......................................................................................................................8
RELATED DOCUMENTS ............................................................................................................10 2.1. 2.2. 3GPP REFERENCE DOCUMENTS .............................................................................................10 ALCATEL-LUCENT REFERENCE DOCUMENTS ............................................................................10
3. 4.
BSR MODEL................................................................................................................................11 AUTOCONFIGURATION / SELF-OPTIMIZATION .....................................................................12 4.1. 4.2. BSR FREQUENCY ...................................................................................................................13 PRIMARY SCRAMBLING CODE ..................................................................................................14
4.2.1 Manual/Auto-Configuration of PSC ...............................................................................14 4.2.2 Automatic Auto-Configuration of PSC...........................................................................14 4.3. POWER SETTING ....................................................................................................................17 4.3.1 CPICH Power Range ....................................................................................................17 4.3.2 CPICH Power update based on Coverage ...................................................................18 4.3.2.1 bsrBasedPilotPowerAdjustMode set to mimBased ...................................................18 4.3.2.2 bsrBasedPilotPowerAdjustMode set to rscpBased ...................................................19 4.3.2.3 bsrBasedPilotPowerAdjustMode set to ecIoBased ...................................................20 4.3.3 CPICH Power update based on UE receiver range......................................................21 4.3.4 CPICH Power update based on UE measurements.....................................................22 4.4. HARDWARE VERSION DEPENDENT PARAMETERS .....................................................................24 4.4.1 Home BSR v1.2 ............................................................................................................24 4.4.2 Enterprise BSR Femto v1 .............................................................................................26 4.4.3 Reserved Channels for signalling .................................................................................27 4.5. FEMTO BSR GROUP SUPPORT................................................................................................29 5. POWER MANAGEMENT ............................................................................................................31 5.1. 5.2. 5.3. 6. BSR TX POWER .....................................................................................................................31 OTHER DL COMMON CHANNEL POWER SETTING ......................................................................31 ENHANCEMENT OF CONTROL POWER ......................................................................................35
RADIO RESSOURCE MANAGEMENT.......................................................................................37 6.1. CALL ADMISSION CONTROL .....................................................................................................37 Emergency Call redirection ...........................................................................................37 Load Estimation ............................................................................................................37 UL Load Calculation ..................................................................................................37 DL Load Calculation ..................................................................................................38 Processing CAC............................................................................................................38 Rejecting RRC Connection ...........................................................................................40 6.1.1 6.1.2 6.1.2.1 6.1.2.2 6.1.3 6.1.4
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 3/158

6.2.
DYNAMIC BEARER CONTROL ...................................................................................................40
6.2.1 DBC based on UL & DL Load measurement ................................................................41 6.2.2 DBC based on Baseband processing limitation............................................................45 6.3. AIR INTERFACE CONGESTION CONTROL ...................................................................................46 7. MOBILITY MANAGEMENT.........................................................................................................47 7.1. NEIGHBOURHOOD DEFINITION .................................................................................................47 7.1.1 Hierarchical Cell Structure (HCS) .................................................................................47 7.1.2 Equivalent Public Land Mobile Network (ePLMN) ........................................................54 7.1.3 3G Macro neighbourhood .............................................................................................56 7.1.3.1 NeighBourlist Parameters..........................................................................................56 7.1.3.2 Neighbour Eligibility ...................................................................................................60 7.1.3.3 Neighbour Measurements .........................................................................................61 7.1.3.4 Neighbour List Generation.........................................................................................62 7.1.4 GSM Macro neighbourhood ..........................................................................................64 7.1.4.1 GSM NeighBourlist Parameters ................................................................................64 7.1.4.2 Neighbour Eligibility ...................................................................................................67 7.1.4.3 Neighbour Measurements .........................................................................................68 7.1.4.4 Neighbour List Generation.........................................................................................69 7.1.5 BSR Neighbourhood .....................................................................................................71 7.1.5.1 NeighBourlist Parameters..........................................................................................71 7.1.5.2 Inter BSR Communication .........................................................................................71 7.1.5.3 Neighbour Measurements .........................................................................................72 7.1.5.4 Neighbour List Generation.........................................................................................73 7.2. CELL RESERVATION AND ACCESS RESTRICTION .......................................................................74 7.2.1 Cell Status and Cell Reservation ..................................................................................75 7.2.2 Access Class Barring ....................................................................................................75 7.2.3 Access Control ..............................................................................................................76 7.2.3.1 Closed Access Mode.................................................................................................76 7.2.3.2 Open Access Mode ...................................................................................................78 7.3. CELL SELECTION ....................................................................................................................79 7.4. CELL RESELECTION ................................................................................................................81 7.4.1 High Mobility Detection algorithm (HMD)......................................................................81 7.4.2 Cell Reselection Measurement Rules without HCS......................................................83 7.4.2.1 Intra-frequency measurements..................................................................................84 7.4.2.2 Inter-frequency measurements..................................................................................84 7.4.2.3 Inter-RAT measurements ..........................................................................................84 7.4.2.4 Measurement Triggers Parameters...........................................................................85 7.4.3 Cell Reselection Measurement Rules with HCS...........................................................87 7.4.3.1 HCS Priority ...............................................................................................................87 7.4.3.2 Neighbouring measurement rules .............................................................................89 7.4.3.2.1 High-Mobility state NOT detected .............................................................................89 7.4.3.2.2 High-Mobility state detected ......................................................................................90 7.4.3.2.3 Recommendations when HCS is used......................................................................90 7.4.4 Cell Eligibility Criteria for REselection...........................................................................91 7.4.4.1 3G Neighbouring Cell Criteria....................................................................................93 7.4.4.2 GSM Neighbouring Cell Criteria ................................................................................94 7.4.4.3 BSR Neighbouring Cell Criteria .................................................................................96 7.4.5 Cell Reselection Ranking Criterion without HCS .......................................................96 7.4.5.1 First Ranking .............................................................................................................97 7.4.5.2 Second Ranking ........................................................................................................99 7.4.5.3 Target Cell Selection .............................................................................................. 100 7.4.6 Cell Reselection Ranking Criterion with HCS ......................................................... 102 7.4.6.1 Quality Level Threshold H Criterion ....................................................................... 102 7.4.6.2 HCS parameters..................................................................................................... 104
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 4/158
7.4.6.3 Ranking R Criterion ................................................................................................ 104 7.4.6.4 Target Cell Selection .............................................................................................. 106 7.5. HANDOVER TO 3G/2G ......................................................................................................... 107 7.5.1 Eligibility for Handover ............................................................................................... 107 7.5.2 Detecting Radio Degradation ..................................................................................... 108 7.5.3 Handover Execution................................................................................................... 111 7.6. BSR TO BSR HANDOVER .................................................................................................... 113 7.6.1 Handover PriNciple .................................................................................................... 113 7.6.2 Handover Failure........................................................................................................ 114 7.6.3 Measurement Control................................................................................................. 115 7.6.4 Handover Execution................................................................................................... 117 7.7. PRESENCE INDICATOR ......................................................................................................... 118 7.7.1 7.7.2 7.7.3 7.7.4 8. Mobility Message ....................................................................................................... 118 Dedicated BSR PLMN................................................................................................ 121 Tone generation during voice call setup .................................................................... 121 MM/GMM Info Generation from Femto ...................................................................... 122
HSXPA ...................................................................................................................................... 124 8.1. HSUPA (E-DCH)................................................................................................................ 124 Introduction................................................................................................................. 124 Feature Activation ...................................................................................................... 124 RAB Combinations..................................................................................................... 125 Selection of E-DCH as the Channel Type.................................................................. 125 Femto Specificity - Definitions.................................................................................... 126 HSUPA UE categories ............................................................................................... 127 Transport and Physical Channels .............................................................................. 128 Uplink channels ...................................................................................................... 129 Downlink Signaling channels.................................................................................. 134 Principle of E-DCH Operation .................................................................................... 137 DL Scheduling Information Serving Grants.............................................................. 139 Absolute Grants...................................................................................................... 139 Relative Grants....................................................................................................... 139 E-TFC Selection......................................................................................................... 141 UL Scheduling Information......................................................................................... 143 Happy Bit ................................................................................................................ 143 Scheduling Information........................................................................................... 144 Air interface limitation................................................................................................. 146 E-DCH uplink Channel Power Control ....................................................................... 148 E-DCH Downlink Channel Power Control.................................................................. 151 8.1.1 8.1.2 8.1.3 8.1.4 8.1.5 8.1.6 8.1.7 8.1.7.1 8.1.7.2 8.1.8 8.1.9 8.1.9.1 8.1.9.2 8.1.10 8.1.11 8.1.11.1 8.1.11.2 8.1.12 8.1.13 8.1.14
9.
INDEXES................................................................................................................................... 152 9.1. 9.2. 9.3. 9.4. TABLE INDEX ....................................................................................................................... 152 FIGURE INDEX ..................................................................................................................... 152 ACRONYMS ......................................................................................................................... 153 MAPPING FMS - MIM .......................................................................................................... 156
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 5/158
1.
1.1.
INTRODUCTION
OBJECT
The Femto Parameter User Guide (FPUG) provides parameter setting recommendations from Alcatel-Lucents experience, coming from studies, simulations and experimentations. This document gives the rationale of these settings by describing Alcatel-Lucents 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 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 BCR2.2. The relevant features are listed in the tables Table 1 to Table 3.
PM ID 34511 83236 81121 75888
Feature Title Generic integrated BSR Femto 100 mWGeneric Standalone Femto 8Users V1.2 Generic standalone femto Integrated 2G sniffer
Basic/Option Option Option Option Option
Release BCR02.02 BCR02.02 BCR02.02 BCR02.02
Table 1 - Hardware Feature
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 6/158

PM ID Feature Title 109907 Reserved channels for Signalling 76977 Detection of collapsing LAI Tone generation during voice call setup under 76980 Femto cell coverage 78320 Enhanced power management 74762 HSUPA 75384 Higher HSDPA throughput 79147 Multiple PDP contexts 76976 Enhanced ePLMN support 34526 Air Interface Congestion control 34527 Pre-emption process for emergency call 34528 Power control 34586 Dynamic Bearer Control 34596 Active call redirect from BSR Femto to Macro 36217 CAC on backhaul resources 74769 Voice Prioritisation over Data 75103 Emergency call redirection to the Macro network
.
Activation Flag BSR:sparePara7 Basic/Option Release Option BCR02.02 Basic BCR02.02 Option Basic Option Option Option Option Basic Basic Basic Basic Basic Basic Basic Basic BCR02.02 BCR02.02 BCR02.02 BCR02.02 BCR02.02 BCR02.02 BCR02.01 BCR02.01 BCR02.01 BCR02.01 BCR02.01 BCR02.01 BCR02.01 BCR02.01
activateUserTone hSDPADynamicPowerEnabled activateEDCH isMpdpIBsupported enableUMTSePLMN LCell::emergencyCallPreemptionEnabled
BSR::activeCallRedirectEnabled BSR:: enableTransportCAC
LCell:: emergencyCallAlwaysRedirectFlag
Table 2 - RRM Features

PM ID 108515 75405 75494 80569 78695 79495 75392 Feature Title MM/GMM info generation from Femto BSR Open access enhancements Femto to Femto CS HO Femto group support Dynamic LAC/SAC allocation Super LAC Hierarchical Cell Structures (HCS) Cell Reselection to/from macro layer (2G or 3G, 34529 intra/inter frequency) Activation Flag BSR:sparePara6 accessMode activateFemtoToFemtoCommunications bsrGroupId dynamicSACLACAllocation activateSuperLAC enableHCS Basic/Option Option Option Option Option Option Option Basic Basic LCell.enableDAHOInterFreqHO LCell.targetHOCS LCell.targetHOPS LCell.targetHOCSPS LCell.enableDAHOInterFreqHO LCell.targetHOCS LCell.targetHOPS LCell.targetHOCSPS Release BCR02.02 BCR02.02 BCR02.02 BCR02.02 BCR02.02 BCR02.02 BCR02.02 BCR02.01
34530 Handover BSR Femto to Macro 3G
Option
BCR02.01
34531 34535 34536 34537
Handover BSR Femto to Macro 2G BSR Femto auto-configuration BSR Femto self-optimisation 3G Network Listening
Option Basic Basic Basic
BCR02.01 BCR02.01 BCR02.01 BCR02.01
Table 3 - Mobility Features
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 7/158
1.3.
NOMENCLATURE
In this document, BSR stands for Femto BSR.
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 recreated through a new MIB built. Class 1: new parameter value is taken into account on the next BSR restart. 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). 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 are presented as follow:
Parameter Object Granularity Range & Unit Class Value
FMS Name | MIM Name FMS Name | MIM Name FMS Name | MIM Name
Notes: When the names are different in FMS and in the MIM, the parameter properties will 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 8/158
The data fill rules (non negotiable) are presented as the following. These are typically OAM checks performed on parameters settings (structure of table, range, etc)
Rule:
Restriction:
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)
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:
FMS:
The implementation process specific to FMS
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 9/158
2.
2.1.
RELATED DOCUMENTS
3GPP REFERENCE DOCUMENTS
[3GPP_R01] [3GPP_R02] [3GPP_R03] [3GPP_R04] [3GPP_R05] [3GPP_R06] [3GPP_R07] [3GPP_R08] [3GPP_R09] [3GPP_R10] [3GPP_R11] [3GPP_R12] [3GPP_R13] 3GPP TS 25.304 3GPP TS 25.331 GSM TS 05-05 3GPP TS 22.011 3GPP TS 24.008 3GPP TS 25.211 3GPP TS 25.306 3GPP TS25.104 3GPP TS 45.005 3GPP TS 25.321 3GPP TS 25.214 3GPP TS 25.213 3GPP TS 25.212 UE procedures in Idle mode and procedures for cell reselection in connected mode Radio Resource specification Control (RRC); protocol
Radio Transmission and Reception Service Accessibility Mobile radio interface Layer 3 specification Physical channels and mapping of transport channels onto physical channels (FDD) UE Radio Access capabilities definition Base Station (BS) reception (FDD) radio transmission and
Radio transmission and reception Medium Access specification Control (MAC) protocol
Physical layer procedures (FDD) Spreading and modulation (FDD) Multiplexing and channel coding
2.2.
ALCATEL-LUCENT REFERENCE DOCUMENTS

1. NTP 411-8111-813 2. UMT/SYS/INF/025597 3. BCR/SYS /DD/025814 Access Network Parameters BCR2.2_Feature_Planning_Guide.doc FTS-77043 Feature Activation Mechanism
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 10/158
3.
BSR MODEL
Figure 1 depicts, within the BSR FMS Model, the location of all the parameters that are presented in this document.
Figure 1 - BSR FMS Model
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 11/158
4.
AUTOCONFIGURATION / SELF-OPTIMIZATION
During the auto-configuration or while self-optimizing, the BSR will adapt its radio parameters automatically to its environment. The processes running during these phase will allow the BSR to Choose the best Primary Scrambling Code (Chapter 4.2) Choose the CPICH Power used to transmit (Chapter 4.3) Generate 3G (UTRAN and BSR) and 2G Neighbourlists (Chapter 7.1)
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 (Chapter 4.3.3) Ensure good service and interference limitation (Chapter 4.3.4) These processes rely on the UE measurements and are running continuously during calls.
Inter-Release Delta: From BCR02.02, different BSR Hardware can be deployed in the field. Some Power Parameters will need to be configured accordingly to the Hardware capabilities. Chapter 4.4 will provide with recommendations for each HW type. Note: From BCR02.02, the FMS will be able to detect the HW and provide the corresponding database depending on the profiles defined.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 12/158
4.1.
BSR FREQUENCY
The UMTS frequency the BSR will transmit on is defined with the parameters LCell::freqBand, LCell::uARFCNDL and LCell::uARFCNUL.
Parameter Object Granularity Range & Unit
Class Value
Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value
freqBand Lcell BSR Profile enum {fdd2100=1, fdd1900=2, fdd1800=3, bandIV=4, bandV=5, bandVI=6, bandVII=7, bandVIII=8, bandIX=9} Class 3 1
uARFCNUL Lcell BSR Profile Integer [0..16383] Class 3 uARFCNDL Lcell BSR Profile Integer [0..16383] Class 3 -
Restriction: Frequency Band In BCR02.02, the only frequency band that is supported by the BSR to transmit on is band1 corresponding to fdd2100.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 13/158
4.2.
PRIMARY SCRAMBLING CODE
Inter-Release Delta: In BCR02.02, the BSR PSC Selection has been modified. Following Sections will present the new PSC procedure which applies to the auto-configuration as well as the self-optimization phase.
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.
4.2.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.
manualPscForFemto Lcell BSR Profile Integer [0511] Class 3 0
Engineering Recommendation: Manual PSC It is strongly recommended to set the PSC manually only for very specific purposes (Lab tests, isolated BSR). Indeed, this procedure will not consider the RF environment at the location where the BSR will be installed.
4.2.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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 14/158
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.
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. 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.
femtoPSC femtoPSCList femtoPSCList Integer [0511] Class 3 '
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).
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 15/158

.
isAutoPscConfigEnabled Lcell BSR Profile Boolean {True, False} Class 3 True rscpPscClashRealloc BSR Profile BSR Profile Integer (dBm) [-115..-25] Class 3 -110
Inter-Release Delta: From BCR02.02 onwards, the PSC list is the only supported method to introduce the PSC to be used by the BSR. As a result, femtoPSCListEnableFlag has to be set per default to True.
Also, an operator will have to enter in the PSC list every single PSC in the case a range is to be used, e.g. for PSC 10 to 15, enter o o o o o o femtoPSCList/1 femtoPSCList/2 femtoPSCList/3 femtoPSCList/4 femtoPSCList/5 femtoPSCList/6 femtoPSC = 10 femtoPSC = 11 femtoPSC = 12 femtoPSC = 13 femtoPSC = 14 femtoPSC = 16
Inter-Release Delta: The following parameters become obsolete: femtoPSCReservedIndex, femtoPSCStartRange, femtoPSCRangeLength
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 16/158
4.3.
POWER SETTING
4.3.1 CPICH POWER RANGE

The following sections define the different algorithms that aim at updating CPICH power which always remain within its range, defined by the 2 following parameters, autoConfigPW::minPilotPowerdBm and autoConfigPW::maxPilotPowerdBm.
autoConfigPW::minPilotPowerdBm is also used to control the minimum BSR pilot coverage to maintain the BSR's minimum coverage.
autoConfigPWminPilotPowerdBm | minPilotPowerdBm BSR Profile | autoConfigPW BSR Profile | BSR Real (dBm) [-5024] step 0.1 Class 3 -45
autoConfigPW::maxPilotPowerdBm is also used to control the maximum BSR pilot coverage, in order to reduce the BSR's interference to neighbour cells
autoConfigPWmaxPilotPowerdBm | maxPilotPowerdBm BSR Profile | autoConfigPW BSR Profile | BSR Real (dBm) [-5024] step 0.1 Class 3 3
Engineering Recommendation: autoConfigPW::maxPilotPowerdBm Keeping in mind that MaxBSRPowerdBm is 10 dB higher than CPICH power (cf. section 5), it is recommended to set autoConfigPW::maxPilotPowerdBm 10 dB lower than maxBSRPowerLimitdBm
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 17/158
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.
4.3.2 CPICH POWER UPDATE BASED ON COVERAGE

The dynamic setting of CPICH power bsrBasedPilotPowerAdjustMode parameter. is enabled through
bsrPilotPowerAdjustMode BSR Profile BSR Profile Enumerated {mimBased, rscpBased, ecIoBased} Class 3 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.
Inter-Release Delta: From BCR02.02 onwards, the 3G Sniffer is used exclusively to perform the needed RF measurements. As a result, the BSR does not require to transmit during the autoconfiguration / Self-optimization phase . The following parameter becomes obsolete:
autoConfigPW::pCPICHPowerIni
4.3.2.1
bsrBasedPilotPowerAdjustMode set to mimBased When set to mimBased, BSR uses pCPICHPower as the static CPICH power.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 18/158

.
pCPICHPower Lcell BSR Profile Real (dBm) [-5020] step 0.1 Class 3 3
4.3.2.2
bsrBasedPilotPowerAdjustMode set to rscpBased When set to rscpBased, BSR dynamically adjusts CPICH power using the following formula: CPICHpower[new]= autoConfigPW::TargetPilotRSCPdBm + MaximumPathLoss
where:
MaximumPathLoss=FreeSpacePathloss + autoConfigPW::indoorPenetrationLoss o FreeSpacePathloss = 20*log10(DL_frequencyMHz) + 20*log10(autoConfigPW::maxCoverageDistancem) 27.5582
autoConfigPWTargetPilotRSCPdBm | TargetPilotRSCPdBm BSR Profile | autoConfigPW BSR Profile | BSR Real (dBm) [-120-30] step 0.1 Class 3 -100
autoConfigPW::indoorPenetrationLoss is used to control the minimum BSR pilot coverage, in order to maintain the BSR's minimum coverage.
autoConfigPWindoorPenetrationLoss | indoorPenetrationLoss BSR Profile | autoConfigPW BSR Profile | BSR Real (dB) [0100] step 0.1 Class 3 30
autoConfigPW::maxCoverageDistancem is used to adjust the BSR coverage within the limit set by autoConfigPW::maxPilotPowerdBm.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 19/158

.
autoConfigPWmaxCoverageDistancem | maxCoverageDistancem BSR Profile | autoConfigPW BSR Profile | BSR Real (m) [1200] step 0.1 Class 3 30
4.3.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]= autoConfigPW::TargetPilotEcIodB + IodBm + MaximumPathLoss where:
IodBm is the average UTRA RSSI (converted in dBm) measured during the network listening period (autoConfigPW::BsrBasedPilotPowerAdjustInterval seconds) MaximumPathLoss is defined as for rscpBased mode.
ecIoBased mode is only applicable when 3G Network Listening feature is enable, i.e. when umtsNtwkListenEnableFlag is set to True (cf. section 7.1.3).
autoConfigPWTargetPilotEcIodB | TargetPilotEcIodB BSR Profile | autoConfigPW BSR Profile | BSR Real (dB) [-250] step 0.1 Class 3 -1 autoConfigPWBsrBasedPilotPowerAdjustInterval | BsrBasedPilotPowerAdjustInterval BSR Profile | autoConfigPW BSR Profile | BSR Integer (s) [0600] Class 3 120
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 20/158
4.3.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, a 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]).
Inter-Release Delta: Investigation in field uncovered problems with UEs near cell edge repeatedly sending e6E measurement reports which were misinterpreted, causing the coverage area to shrink. A solution has been implemented in BCR02.02, which is activated by setting e6eTriggerEnabled to TRUE.
e6eTriggerEnabled BSR Profile BSR Profile Boolean {True, False} Class 3 TRUE
e6eTimetoTrigger in ms, indicates the period of time between the timing of event detection and the timing of sending Measurement Report (Event 6E).
e6eTimetoTrigger BSR Profile BSR Profile Enumerated {ttt0, ttt10, ttt20, ttt40, ttt60, ttt80, ttt100, ttt120, ttt160, ttt200, ttt240, t320, ttt640, ttt1280, ttt2560, ttt5000} Class 3 ttt640
Class Value
When the BSR receives such Event 6E, it increases or reduces the CPICH power by autoConfigPW::pAdjustmentStepdB, keeping the new CPICH power inside the limits set by the autoConfigPW::minPilotPowerdBm and maxBSRPowerLimitdBm. The decision to increase or decrease the power is based on the parameter e6ePowerThresholddBm. Additionally a recovery process has been implemented to avoid that the changes unnecessarily impacts on performance in the BSR coverage area. This is done modifying the CPICH Power in eventRecoverySteps steps during eventRecoveryTimem minutes.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 21/158

Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value
.
eventRecoveryTimem BSR Profile BSR Profile Integer (min) [160] Class 3 5 eventRecoverySteps BSR Profile BSR Profile Integer [010] Class 3 2 e6eUePowerThresholddBm BSR Profile BSR Profile Integer (dBm) [-500] Class 3 -40
4.3.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 BSRs. Event 1F: the active BSRs CPICH becomes worse than an absolute threshold.
ueBasedPilotPowerAdjustMode allows to activate this feature and to define how CPICH power is updated.
ueBasedPilotPowerAdjustMode BSR Profile BSR Profile Enumerated {disable, targetEcIo, neighbourEcIo} Class 3 targetEcIo
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 22/158
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 BSRs CPICH Ec/Io < Neighbouring cells CPICH Ec/Io then CPICHpower[new] = CPICHpower[old] + autoConfigPW::pAdjustmentStepdB
autoConfigPWpAdjustmentStepdB | pAdjustmentStepdB BSR Profile | autoConfigPW BSR Profile | BSR Real (dB) [010] step 0.1 Class 3 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 autoConfigPW::UeBasedPilotPowerAdjustInterval seconds, as follows:
If Active BSRs CPICH Ec/Io < autoConfigPW::targetPilotEcIodB then CPICHpower[new] = CPICHpower[old] + autoConfigPW::pAdjustmentStepdB
autoConfigPWUeBasedPilotPowerAdjustInterval | UeBasedPilotPowerAdjustInterval BSR Profile | autoConfigPW BSR Profile | BSR Integer (s) [0600] Class 3 120
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 23/158
4.4.
HARDWARE VERSION DEPENDENT PARAMETERS
Inter-Release Delta: Additionally to the V1 Hardaware used in BCR02.01, new BSR models will be introduced in BCR02.02. This chapter deals with those.
From BSR02.02, following hardware will be available: V1 Reference: V1.2 V1.2 Integrated: V1 Business: This is the version mostly deployed during BCR02.01 This type has a modified 2G sniffer In this version the BSR is integrated in the DSL router This version supports output power of 100mW It is based on the Version V1.2 and supports 8 users.
4.4.1 HOME BSR V1.2

Feature 75888 introduces new 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, based on the information preconfigured in the DeviceInfo::HardwareVersion, 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 BSR::gsmListenerPicoBasedEnabled=False, then the 2G Network Listening will not be enabled during the auto-configuration nor self-optimization phases. If BSR::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 7.1.4. Some parameters are introduced or named differently such as following.

the PicoChip baseband processor reconfiguration will be bounded by the timer, BSR::NetkListGuardConfigTimer, the BCCH Decode function will BSR::gsmBCCHDecodeGuardTimer be bounded by the timer,
the GSM Cell search function will be bounded by the timer, BSR::GsmCellSearchGuardTimer
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 24/158

the LCELL::minGsmDetectThreshold is the minimum received signal strength of a cell to be considered. the bsr::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.

HardwareVersion DeviceInfo -| String PreConfigured gsmListenerPicoBasedEnabled BSR Profile BSR Profile Boolean {True, False} Class 3 TRUE gsmBCCHDecodeGuardTimer BSR Profile BSR Profile Integer (ms) [500..6000] Class 3 2000 gsmCellSearchGuardTimer BSR Profile BSR Profile Integer (ms) [60..1000] Class 3 250
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 25/158

.
gsmMeasurementPeriod BSR Profile BSR Profile Integer (ms) [5..300] Class 3 25 NetkListGuardConfigTimer BSR Profile BSR Profile Integer (ms) [0..60000] Class 3 5000 minGSMDetectThreshold Lcell BSR Profile Integer (dBm) [-110..-48] Class 3 -104
4.4.2 ENTERPRISE BSR FEMTO V1

This new hardware platform is based on the existing v1.2 standalone BSR supporting 2100MHz UMTS band. Its mains differences is an increase in terms of capacity, 8 users compared to 4 for the home version. Additionally, the v1 Enterprise BSR Femto has an increased transmit power of 100mW, compared to 20mW. 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 4. Most of the power settings are relative to the pCPICHPower as shown in 5.2. Therefore, there are only few power parameters to modify for the different HW.
V1 20mW [Golden Ref.] maxBSRPowerLimitdBm autoConfigPWmaxPilotPowerdBm pCPICHPower numCellDCHUE 13 3 3 4
V1 Business 100mW 8 Users 20 10 10 8
V1.2 20mW New 2G Sniffer 13 3 3 4
V1.2 20mW Integrated 13 3 3 4
Table 4 - Enterprise BSR Femto Specific Parameters

BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 26/158
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.
4.4.3 RESERVED CHANNELS FOR SIGNALLING

Inter-Release Delta: This feature is introduced in BCR02.02 for v1 Enterprise BSR Femto onwards
This feature allows reserving a number of channels for signaling purposes (location updates, SMS, ..). This is particularly important when Femto cells are deployed in public areas with high number of users. To enable the feature, the parameter BSR::sparePara7 should be set to the value restrictNumUEsWithRAB=1;maxUEsWithRAB=x, The parameter maxUEsWithRAB (or x) defines the maximum number of calls with RABs 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.
sparePara7 RRM BSR Profile String Class 3 -
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 27/158
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 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 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 28/158
4.5.
FEMTO BSR GROUP SUPPORT
Inter-Release Delta: In BCR02.01, mobility from one BSR to another was supported only through cell reselection. BCR02.02 introduces an extended support of this mobility (CRS, CS HO) in an optimized way as described in the next chapters.
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.
femtoGroupId | bsrGroupId Femto | BSR Femto | BSR Integer [065534] Class 3 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 differentiated emergency-call handling LAC3/SAC3 values LACx/SACx,
FMS: Femto Group All of the parameter values for the BSR Group will have to be entered under FemtoNetwork::FemtoGroup and will override the values defined for each BSR (under FemtoNetwork::Femto).
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 29/158
the same Network Name
Note: It is possible to populate different Network Names for each BSR in a Group, 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 (see chapter 4.2 and 4.3).
The Neighbourlist generation is modified in the case of BSR groups and will be described in chapter 7.1.5.
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 (chapter 4.3.3) or on UE measurements (chapter 4.3.4) are to be disabled. This is done by setting :

autoConfigPW::pAdjustmentStepdB to 0 and ueBasedPilotPowerAdjustMode to disable
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 30/158
5.
5.1.
POWER MANAGEMENT
BSR TX POWER
Since BSR CPICH power is dynamically updated as presented in section 4.3.1, BSR maximum power is also be 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 autoConfigPW::MinBSRPowerdBm. must always be kept above
maxBSRPowerLimitdBm Lcell BSR Profile Real (dBm) [-5024] step 0.1 Class 3 13

Restriction: Max BSR Power
autoConfigPWMinBSRPowerdBm | MinBSRPowerdBm BSR Profile | autoConfigPW BSR Profile | BSR Real (dBm) [-5024] step 0.1 Class 3 -35
Due to Hardware protection, the maximum allowed output power is given by the Hardware, independently of any parameter configuration.
5.2.
OTHER DL COMMON CHANNEL POWER SETTING

The following parameters define the setting for other DL common channels.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 31/158
.
bCHPower Lcell BSR Profile Real (dB) [-3515] step 0.1 Class 3 -3
bCHPower defines the BCH power, in dB, with respect to P-CPICH power.
pSCHPower defines the Primary SCH power, in dB, with respect to PCPICH power. pSCHPower Lcell BSR Profile Real (dB) [-3515] step 0.1 Class 3 -3
sSCHPower defines the Secondary SCH power, in dB, with respect to CPICH power. sSCHPower Lcell BSR Profile Real (dB) [-3515] step 0.1 Class 3 -5
aICHPower defines the AICH power, in dB, with respect to CPICH power. aICHPower CCPower BSR Profile Real (dB) [-3515] step 0.1 Class 3 -5
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 32/158
fACHSigPower defines the output power level of the Signaling FACH transport channel, in dB, with respect to CPICH power. fACHSigPower CCPower BSR Profile Real (dB) [-3515] step 0.1 Class 3 4
pCHPower defines the PCH power, in dB, with respect to CPICH power. pCHPower CCPower BSR Profile Real (dB) [-3515] step 0.1 Class 3 4
pICHPower defines the PICH power, in dB, with respect to CPICH power. pICHPower CCPower BSR Profile Real (dB) [-3515] step 0.1 Class 3 -5
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 33/158
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(autoConfigPW::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 5 depicts the recommended setting and the maximum power used for common channels so that the previous rule is fulfilled.
Power (dB) maxBSRPowerLimitdBm autoConfigPWmaxPilotPowerdBm bCHPower pSCHPower sSCHPower aICHPower fACHSigPower pCHPower pICHPower -3 -3 -5 -5 4 4 -5
Power (dBm) 13 3 0 0 -2 -2 7 7 -2
% vs. Total Power (mW) 20 2 10% 1 5.00% 1 5.00% 0.63 3.15% 0.63 3.15% 5.01 25.05% 5.01 25.05% 0.63 3.15%
Table 5 - 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 34/158
5.3.
ENHANCEMENT OF CONTROL POWER
Inter-Release Delta: In BCR02.02, the BSR Enhancement of Control Power feature is introduced. The BSR Enhancement of Control Power enables the BSR MAC-hs to be able to allocate the HSDPA Tx power according to the used R99 + common channels and the upper limit defined in NBAP as shown in Figure 2. Thus, with this feature, if not all the HSDPA 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 shall allocate the HSDPA Tx power according to the used R99 + common channels and the upper limit defined through the parameter hsdpaAndEdchTotalDLpower. Additionally the HSDPA scheduler shall reserve a certain margin, hsdpaDynamicPwrHeadroom, to prevent total downlink power clipping.
Amplifier Capability
R99 Power
HSDPA Power Overhead Power
Figure 2 - Dynamic HSDPA Power Allocation
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 35/158
.
hSDPADynamicPowerEnabled Femto | BSR Femto | BSR Boolean {True, False} Class 3 TRUE
hsdpaAndEdchTotalDLpower CCPower BSR Profile Real (dB) [050] step 0.5 Class 1 9 hsdpaDynamicPwrHeadroom CCPower BSR Profile Integer [0.1%] [01000] Class 3 50

Note: the Unit of hsdpaDynamicPwrHeadroom is 0.1%. This means tha setting this parameter to a value of 10 would mean 1%.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 36/158
6.
6.1.
RADIO RESSOURCE MANAGEMENT

CALL ADMISSION CONTROL
The Call Admission Control (CAC) algorithm is used to admit or deny new RRC Connection Request based on several criterions presented in section 6.1.3.
6.1.1 EMERGENCY CALL REDIRECTION

Prior to the CAC processing described in section 6.1.3, 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.
emergencyCallAlwaysRedirectFlag LCell BSR Profile Boolean {True, False} Class 3 FALSE emergencyCallRedirectNetwork LCell BSR Profile Enum {redirectGsmPreferred, redirectUmtsPreferred} Class 3 redirectGsmPreferred If Emergency call redirection is disabled or no Macro neighbouring cell is available nor eligible, CAC check is performed, as presented hereafter.
6.1.2 LOAD ESTIMATION 6.1.2.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))

BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 37/158
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)
6.1.2.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(%)
6.1.3 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.
numCellDCHUE LCell BSR Profile Integer [132] Class 3 4 Refer to section 6.2 for more details on CAC thresholds.
If the above checks fail, the following process applies depending on the RRC Connection Request establishment cause
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 38/158
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).
activeCallRedirectEnabled BSR Profile BSR Profile Boolean {True, False} Class 3 TRUE aCRpreference BSR Profile BSR Profile Enum {nonEmergencyCall, emergencyCall or Both} Class 3 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.
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 Object Granularity Range & Unit Class Value CAC rejection for Emergency calls
enableNormalCallPreemption BSR Profile BSR Profile Boolean {True, False} Class 3 TRUE
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 39/158
If CAC fails, BSR first tries and pre-empts an UE marked for Measurement Acceleration; BSR eventually pre-empts, if needed, an existing Cell DCH UE when emergencyCallPreemptionEnabled is set to True.
emergencyCallPreemptionEnabled Lcell BSR Profile Boolean {True, False} Class 3 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.
6.1.4 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, using:

emergencyCallRedirectNetwork for Emergency calls, redirectNetwork for non-Emergency calls.
redirectNetwork Lcell BSR Profile Enum {disable, redirectGSM or redirectUMTS} Class 3 redirectGSM
6.2.
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:

BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 40/158

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.
6.2.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"
Then, DBC admits the incoming request if the following condition is satisfied, depending on the bearer to be granted.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 41/158
.
Condition for the bearer to be granted UL_load < thrCACUL UL_load < thrDBCUL
OR
PS bearer to be granted
PS bearer
UL PS bearer with 8k, 16k or 32k or 64k UL PS bearer with 128k
UL_load < thrCACUL AND UL_environment_status = Cell Center

UL PS bearer with 384k
UL_load < thrDBCUL AND UL_environment_status = Cell Center DL_load < thrCACDL DL_load < thrDBCDL
OR
DL PS bearer with 8k, 16k or 32k or 64k DL PS bearer with 128k
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

UL non-emergency CS bearer with 12.2k or 64k UL emergency CS bearer with 12.2k DL non-emergency CS bearer with 12.2k or 64k DL emergency CS bearer with 12.2k
Condition for the bearer to be granted UL_load < thrCACUL UL_load < thrCACEmergencyUL DL_load < thrCACDL 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 42/158
Parameters
dBCQualReportingCriteriaDLEcN0thres | ecN0thres Lcell | DBCQualReportingCriteriaDL BSR Profile | Integer (dB) [-240] Class 3 -13 dBCQualReportingCriteriaDLEcN0Hysteresis | ecN0Hysteresis Lcell | DBCQualReportingCriteriaDL BSR Profile | Integer (dB) [049] Class 3 2
dBCQualReportingCriteriaDLTimetoTrigger | TimetoTrigger Lcell | DBCQualReportingCriteriaDL BSR Profile | Enumerated {timetotrigger0=0, timetotrigger10=10, timetotrigger20=20, timetotrigger40=40, timetotrigger60=60, timetotrigger80=80, timetotrigger100=100, timetotrigger120=120, timetotrigger160=160, timetotrigger200=200, timetotrigger240=240, timetotrigger320=320, timetotrigger640=640, timetotrigger1280=1280, timetotrigger2560=2560, timetotrigger5000=5000} Class 3 timetotrigger640
Class Value
dBCQualReportingCriteriaULEcN0thres | ecN0thres Lcell | DBCQualReportingCriteriaUL BSR Profile | Integer (dB) [-240] Class 3 -8
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 43/158

.
dBCQualReportingCriteriaULEcN0Hysteresis | ecN0Hysteresis Lcell | DBCQualReportingCriteriaUL BSR Profile | Integer (dB) [049] Class 3 2
dBCQualReportingCriteriaULTimetoTrigger | TimetoTrigger Lcell | DBCQualReportingCriteriaUL BSR Profile | Enumerated {timetotrigger0=0, timetotrigger10=10, timetotrigger20=20, timetotrigger40=40, timetotrigger60=60, timetotrigger80=80, timetotrigger100=100, timetotrigger120=120, timetotrigger160=160, timetotrigger200=200, timetotrigger240=240, timetotrigger320=320, timetotrigger640=640, timetotrigger1280=1280, timetotrigger2560=2560, timetotrigger5000=5000} Class 3 timetotrigger640
Class Value
thrDBCUL Lcell BSR Profile Integer (%) [0100] Class 3 100 thrCACUL Lcell BSR Profile Integer (%) [0100] Class 3 100 thrCACEmergencyUL Lcell BSR Profile Integer (%) [0100] Class 3 100
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 44/158
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.
thrDBCDL Lcell BSR Profile Integer (%) [0100] Class 3 50 thrCACDL Lcell BSR Profile Integer (%) [0100] Class 3 75 thrCACEmergencyDL Lcell BSR Profile Integer (%) [0100] Class 3 90
Rule: thrDBCDL, thrCACDL and thrCACEmergencyDL thrDBCDL must be lower than thrCACDL. thrCACDL must be lower than thrCACEmergencyDL.
6.2.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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 45/158

.
thrConCDL Lcell BSR Profile Integer (%) [0100] Class 3 90
Otherwise, the BSR shall check whether:

the DL resource consumption is ok, the UL resource consumption is ok, the UL SF usage (including the new RAB) is ok the DL SF usage (including the new RAB) is ok, multiple RAB service combination is supported.
In case one of these checks fails, the BSR renegotiates the RAB setup as presented in section 6.2.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.
6.3.
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 6.2.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).
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 46/158
7.
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 cell (only applicable for CS speech call)
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.
Inter-Release Delta: From BCR02.02, Femto to Femto Handovers are supported for CS Voice and new functionalities introduced. These will be described in chapter 7.1.5
7.1.
NEIGHBOURHOOD DEFINITION
7.1.1 HIERARCHICAL CELL STRUCTURE (HCS)

Inter-Release Delta: The Hierarchical Cell Structure feature is introduced in BCR02.02 and is enabled/disabled through the parameter enableHCS. This will allow a BSR to be integrated into a HCS environment (3G Macro / 2G) if available.
enableHCS Lcell BSR Profile Boolean {True, False} Class 3 FALSE
3GPP defines special cell re-selection algorithm in a Hierarchical Cell Structure environment. 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 47/158
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 3: the GSM layer, the UMTS layer and the BSR layer.
Figure 3 - 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 48/158

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 highmobility state has been detected sLimitSearchRAT: Determines, when the UE starts/stops performing GSM measurements in low mobility state when HCS is used.
hcsPrioS Lcell BSR Profile Integer [07] Class 3 7 qHCSs Lcell BSR Profile Integer [099] Class 3 0
Class Value
tCRmax Lcell BSR Profile Enumerated (s) {notUsed=0,t30=30,t60=60,t120=120,t180=180,t240=2 40} Class 3 notUsed
tCRmaxHyst Lcell BSR Profile Enumerated (s) {NotUsed,t10,t20,t30,t40,t50,t60,t70} Class 3 t20
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 49/158

.
nCR Lcell BSR Profile Integer [116] Class 3 8 sIB3SpeedDependentScalingFactor Lcell BSR Profile Real (dB) [0.01.0] step 0.1 Class 3 1 sLimitSearchRAT Lcell BSR Profile Integer (dB) [-3220] Class 3 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 50/158
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.
qHCSn HcsCellRsInfo BSR Profile Integer [099] Class 3 30 penaltyTime HcsCellRsInfo BSR Profile Enumerated (s) {NotUsed,t10,t20,t30,t40,t50,t60} Class 3 t20
Class Value Parameter Object Granularity Range & Unit
tempOffset1 HcsCellRsInfo BSR Profile Enumerated {offset3=3,offset6=6,offset9=9,offset12=12,offset15=1 5,offset18=18,offset21=21,offsetInfinite=9999} Class 3 offset9 tempOffset2 HcsCellRsInfo BSR Profile Enumerated {offset2=2,offset3=3,offset4=4,offset6=6,offset8=8,offs et10=10,offset12=12,offsetInfinite=9999} Class 3 offset6
Class Value
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 51/158

.
qOffset1 HcsCellRsInfo BSR Profile Integer [-5050] Class 3 0 qOffset2 HcsCellRsInfo BSR Profile Integer [-5050] Class 3 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 7.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).
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 52/158
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 lowmobility measurements in case of non-HCS usage.
Class Value
nonHCStCRmax Lcell BSR Profile Enumerated (s) {notUsed=0,t30=30,t60=60,t120=120,t180=180,t240=2 40} Class 3 notUsed
nonHCSnCR Lcell BSR Profile Integer [116] Class 3 8 nonHCStCRmaxHyst Lcell BSR Profile Enumerated (s) {NotUsed,t10,t20,t30,t40,t50,t60,t70} Class 3 t20
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 53/158
7.1.2 EQUIVALENT PUBLIC LAND MOBILE NETWORK (EPLMN)

Inter-Release Delta: The ePLMN feature is introduced in BCR02.02 and is used while generating the neighbourlists (chapters 7.1.3.4 and 7.1.4.4). 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 National Code (MCC). The BSR is associated with one of the operators 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 operators 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.
enableUMTSePLMN Lcell BSR Profile Boolean {True, False} Class 3 TRUE MNC Lcell::umtsMacroEPLMN umtsMacroEPLMN StringType [Maxlength 3] Class 3 -
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 54/158

.
MCC Lcell::umtsMacroEPLMN umtsMacroEPLMN StringType [Maxlength 3] Class 3 -
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, the flag enableOwnPLMNHighPriority is to be set to TRUE.
enableOwnPLMNHighPriority Lcell BSR Profile Boolean {True, False} Class 3 TRUE
The flag prioritizeOwnPLMNoverRAT is used to prioritize the operators own PLMN over other radio access technology in case a preferred target radio access technology (GSM or UMTS) is configured for macro cell handover.
prioritizeOwnPLMNoverRAT Lcell BSR Profile Boolean {True, False} Class 3 FALSE
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 55/158
7.1.3 3G MACRO NEIGHBOURHOOD 7.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 o o o
fddFreqBand, dlFrequencyNumber and ulFrequencyNumber locationAreaCode, routingAreaCode and primaryScramblingCode, primaryCPICHPower notAllowedCell, hcsPrioN
Inter-Release Delta: Since from BCR02.02, HCS is a supported feature, the parameter hcsPrioN, which specifies the HCS priority level for the provisioned UMTS macro cells, is introduced.
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.
FMS: notAllowedfddCellList The Neighbourlist for a BSR will be entered by populating the Femto::fddCellList for allowed Cells and the Femto::notAllowedfddCellList for the not Allowed ones.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 56/158
For the FDDExtCell

Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit mobileCountryCode | mCC FddExtCell MacroCells | N.A. StringType [Maxlength 3] Class 3 Operator Specific mobileNetworkCode | mNC FddExtCell MacroCells | N.A. StringType [Maxlength 3] Class 3 Operator Specific cellId | cellIdentity FddExtCell MacroCells | N.A. Integer [04095] Class 3 Operator Specific rNCID FddExtCell MacroCells Integer [04095] Class 3 Operator Specific fddFreqBand FddExtCell MacroCells Enumerated {fdd2100=1, fdd1900=2, fdd1800=3, bandIV=4, bandV=5, bandVI=6, bandVII=7, bandVIII=8, bandIX=9} Class 3 Operator Specific
Class Value
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 57/158
Restriction: Frequency Band Current BSR Version only support UMTS fdd2100 (Band 1) [3GPP_R08].
Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value
ulFrequencyNumber | uARFCN FddExtCell MacroCells | Integer [016383] Class 3 Operator Specific dlFrequencyNumber | uARFCNDownlink FddExtCell MacroCells | Integer [016383] Class 3 Operator Specific locationAreaCode | lAC FddExtCell MacroCells | Integer [065535] Class 3 Operator Specific routingAreaCode | rAC FddExtCell MacroCells | Integer [0255] Class 3 Operator Specific primaryScramblingCode | primaryCPICHInfo FddExtCell MacroCells | Integer [0511] Class 3 Operator Specific
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 58/158

.
pcpichPower | primaryCPICHTxPower FddExtCell MacroCells | Real (dBm) [-10,-9.950] Class 3 Operator Specific - | notAllowedCell - | FddExtCell - | BSR Boolean {True, False} Class 3 False hcsPrioN FddExtCell MacroCells Integer [07] Class 3 0
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 Object Granularity Range & Unit freqBand macroUMTSCellFrequencyList macroUMTSCellFrequencyList Enumerated {fdd2100=1, fdd1900=2, fdd1800=3, bandIV=4, bandV=5, bandVI=6, bandVII=7, bandVIII=8, bandIX=9} Class 3 Operator Specific
Class Value
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 59/158

.
uARFCNDL macroUMTSCellFrequencyList macroUMTSCellFrequencyList Integer [016383] Class 3 Operator Specific uARFCNUL macroUMTSCellFrequencyList macroUMTSCellFrequencyList Integer [016383] Class 3 Operator Specific
7.1.3.2
NEIGHBOUR ELIGIBILITY
A neighbouring 3G Macro cell is considered as eligible to be broadcast into SIB11

if its PLMN belongs to the own BSR PLMN or the umtsMacroEPLMN List and then 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. macroCellMeasurementQuantity Lcell BSR Profile Enum {ecNO, rSCP} Class 3 rSCP
macroCellRSCPThreshold defines the threshold applied to CPICH RSCP above which a measured 3G Macro cell is considered as eligible when macroCellMeasurementQuantity is set to rSCP.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 60/158

.
macroCellRSCPThreshold Lcell BSR Profile Integer (dBm) [-116-25] Class 3 -110
macroCellEcNoThreshold defines the threshold applied to CPICH EcNo above which a measured 3G Macro cell is considered as eligible when macroCellMeasurementQuantity is set to ecNO. macroCellEcNoThreshold Lcell BSR Profile Integer (dB) [-250] Class 3 -15
7.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 Macros SIB11 to improve its self-learning.
Inter-Release Delta: In BCR02.01, a method relying on UE measurements was available. From BCR02.02 and since a embedded 3G sniffer can be used, the UE based method is not supported anymore. The sniffer based procedure is faster and need no end-user interaction. As a result, the parameter umtsNtwkListenEnableFlag is to be set to TRUE per default
The following parameter becomes obsolete: periodicMacroCellCheck
umtsNtwkListenEnableFlag enables the 3G Network listening feature which means BSR is able to measure 3G Macro cells by itself. umtsNtwkListenEnableFlag BSR Profile BSR Profile Boolean {True, False} Class 3 TRUE
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 61/158
umtsOpenSearchEnableFlag: allows the reading of the best neighbouring cells SIB11 to improve the knowledge of BSRs 3G neighbourhood. umtsOpenSearchEnableFlag BSR Profile BSR Profile Boolean {True, False} Class 3 TRUE
macroCellListSIB11 defines the maximum number of 3G Macro neighbouring cells to be broadcast in BSRs SIB11.
macroCellListSIB11 Lcell BSR Profile Integer [132] Class 3 8
7.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.
Inter-Release Delta: 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 62/158
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 7.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.
umtsMacroCellRsInfouseOfDetectedHcsPrio | useOfDetectedHcsPrio Lcell | umtsMacroCellRsInfo BSR Profile | BSR Boolean {True, False} Class 3 TRUE
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 63/158

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).
7.1.4 GSM MACRO NEIGHBOURHOOD 7.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 o o
bCC gsmFrequBand and bCCHArfcn 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) 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
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 64/158

FMS: notAllowedgsmCellList
The Neighbourlist for a BSR will be entered by populating the Femto::gsmCellList for allowed Cells and the Femto::notAllowedgsmCellList for the not Allowed ones.
For the GsmExtCell

Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit mobileCountryCode | mCC GSMExtCell MacroCells | N.A. StringType [Maxlength 3] Class 3 Operator Specific mobileNetworkCode | mNC GSMExtCell MacroCells | N.A. StringType [Maxlength 3] Class 3 Operator Specific bCC GSMExtCell MacroCells Integer [07] Class 3 Operator Specific gsmFrequBand GSMExtCell MacroCells Enumerated {gSM450=0, gSM480=1, gSM850=2, gSM900=3, gSM900E=4, gSM1800=5, gSM1900=6, bandVII=7, bandVIII=8, bandIX=9} Class 3 Operator Specific
Class Value
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 65/158
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) R-GSM 900 (ARFCN 0 to 124 & 955 to 1023 inclusive) DCS 1800 (ARFCN 512 to 885 inclusive)
Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value
bCCHArfcn GSMExtCell MacroCells Integer [01023] Class 3 Operator Specific locationAreaCode | lAC GSMExtCell MacroCells | N.A. Integer [065535] Class 3 Operator Specific rAC GSMExtCell MacroCells Integer [0255] Class 3 Operator Specific cellIdentity GSMExtCell MacroCells Integer [065535] Class 3 Operator Specific - | notAllowedCell - | GSMExtCell - | BSR Boolean {True, False} Class 3 False
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 66/158
For the LCell::GsmFrequencyList
Class Value Parameter Object Granularity Range & Unit Class Value Parameter Object Granularity Range & Unit Class Value
bandIndicator gsmFrequencyList Lcell Enumerated {gSM450=0, gSM480=1, gSM850=2, gSM900=3, gSM900E=4, gSM1800=5, gSM1900=6, bandVII=7, bandVIII=8, bandIX=9} Class 3 Operator Specific bCCHARFCNstart gsmFrequencyList Lcell Integer [01023] Class 3 Operator Specific bCCHARFCNsize gsmFrequencyList Lcell Integer [01023] Class 3 Operator Specific
7.1.4.2
NEIGHBOUR ELIGIBILITY
A neighbouring GSM cell is considered as eligible to be broadcast into BSRs 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 gsmcellRSSIThreshold threshold.
gsmCellRSSIThreshold Lcell BSR Profile Integer (dBm) [-110-48] Class 3 -96
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 67/158
Engineering Recommendation: gsmcellRSSIThreshold gsmcellRSSIThreshold shall be set accordingly to gsmMacroCellRsInfo::QRxLevMin (cf. section 7.4.4.2).
7.1.4.3
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).
Inter-Release Delta: In BCR02.01, a method relying on UE measurements was available. From BCR02.02 and since a embedded 2G sniffer can be used, the UE based method is not supported anymore. The sniffer based procedure is faster and need no end-user interaction. As a result, the parameter umtsNtwkListenEnableFlag is to be set to TRUE per default
The following parameter becomes obsolete: periodicGSMCellCheck
The flag allowedGSMOpenSearch: when set to True, allows:

o
to scan the BCCH ARFCN list provided by one or several LCellGsmFrequencyList objects, to improve GSM neighbourhood knowledge by reading the best 3G neighbouring cells SIB11 when umtsNtwkListenEnableFlag is set to True (cf. section 7.1).
allowedGSMOpenSearch Lcell BSR Profile Boolean {True, False} Class 3 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 7.5.3) as locationAreaCode and rAC, needed for Relocation procedure, can not be dynamically retrieved by BSR.
The Parameter gsmListeningMode enables the 2G Network listening feature.

BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 68/158

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.
gsmListeningMode GSMListener BSR Profile Enum {Mode0, Mode1, Mode2} Class 3 Mode2 gsmListeningPeriodicTimer GSMListener BSR Profile Integer (minutes) [010000] Class 3 1440 (1day)
gsmCellListSIB11 defines the maximum number of GSM Macro neighbouring cells to be broadcast in BSRs SIB11.
gsmCellListSIB11 Lcell BSR Profile Integer [132] Class 3 8
7.1.4.4

The process followed for the generation of the 2G neighbourlist steered through the gsmExtCell list
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 69/158
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).
gsmModuleInitGuardTimer GSMListener BSR Profile Integer [0500] Class 3 60 mcc GSMListener::gsmMacroPLMN gsmMacroPLMN StringType [Maxlength 3] Class 3 mnc GSMListener::gsmMacroPLMN gsmMacroPLMN StringType [Maxlength 3] Class 3 -
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 70/158

.
ownPLMN GSMListener::gsmMacroPLMN gsmMacroPLMN Boolean {True, False} Class 3 False
7.1.5 BSR NEIGHBOURHOOD 7.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.
bSRIdentity Femto::BSRneighbourCell | BSRneighbourCell Femto | BSR Integer [065534] Class 3 -
7.1.5.2
INTER BSR COMMUNICATION
Inter-Release Delta: From BCR02.02, BSRs that belongs to the same group have the ability to communicate to each other to exchange informations.
To activate BSR to BSR communication within a group activateFemtoToFemtoCommunications has to be set to TRUE.
of
BSR,
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 71/158
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.
activateFemtoToFemtoCommunications BSR Profile BSR Profile Boolean {True, False} Class 3 TRUE isAutoNeigbourCellDetectionEnabled BSR Profile BSR Profile Boolean {True, False} Class 3 TRUE
7.1.5.3
The measurements of the surrounding BSRs are performed by the 3G sniffer just as it was for the 3G cells (see chapter 7.1.3.3).
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 72/158
The only difference is that the measurements will be stopped when all the PSC of the femtoPSCList have been scanned.
7.1.5.4

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 7.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: Lets 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 73/158
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.
7.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 to prevent 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, 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 7.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 signalled 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 74/158
7.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").
sIB3CellBarred Lcell BSR Profile Enum {barred, notbarred} Class 3 notbarred sIB3CellResForOperatorUse Lcell BSR Profile Enum {reserved, notreserved} Class 3 notreserved sIB3CellResExtension Lcell BSR Profile Enum {reserved, notreserved} Class 3 notreserved
Refer to [3GPP_R01] for details on Cell Reservation.
7.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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 75/158
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.
sIB3AccClassBarredAc0 | AC[1 to 15] Lcell | Lcell::sIB3AccClassBarred BSR Profile | sIB3AccClassBarred Boolean {True, False} Class 3 FALSE
Refer to [3GPP_R01] for details on Cell Access Control.
7.2.3 ACCESS CONTROL
Inter-Release Delta: In BCR02.01, all the BSR in a Cluster had to have the same Access Mode. From BCR02.02, it is possible within a cluster to have BSRs in Closed Access while others are in Open Access Mode.
7.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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 76/158
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 no suitable cells in LA. The UE will store the LA in its list of forbidden Las and will not further try to access any BSRs of this LA. 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 1280ms.
Note: Emergency calls are still possible in the case the BSR is the only available wireless network.
accessMode Femto | BSR Femto | BSR Enumerated {closedAccess, openAccess} Class 3 closedAccess femtoACLlist Femto Femto StringType {xx, yy, zz} Class 3 femtoACLlistGuest Femto Femto StringType {xx, yy, zz} Class 3 -
Inter-Release Delta: The BCR02.01 attribute BSR::femtoACLenable is replaced by the BSR::accessMode
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 77/158

The total number of IMSI that can be provisioned through the different lists has been increase to 256 (previously 32).
Rule: femtoACLlistGuest In the case more IMSI are provided, the BSR will delete IMSIs from the femtoACLlistGuest until 256 is reached.
7.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).
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 78/158
7.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 o o
The cell is not barred; The cell selection criteria are fulfilled 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 o o
The cell is part of the selected or equivalent PLMN The cell is not barred. The cell is not part of the list of "forbidden LAs for regional provision of service" 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 79/158
.
Class 1 +33 N.A. N.A. N.A. N.A. Power (dBm) Class 2 Class 3 +27 +24 N.A. +24 N.A. +24 N.A. +24 N.A. +24 Class 4 +21 +21 +21 +21 +21
Operating Band I II V VI VIII UMTS 2100 MHz UMTS 1900 MHz UMTS 850 MHz (not supported by BSR) UMTS 850 MHz (not supported by BSR) UMTS 900 MHz (not supported by BSR)
Table 6 - UE power Class vs. maximum output power
qQualMin Lcell BSR Profile Integer (dB) [-24...0] Class 3 -19 qRxLevMin Lcell BSR Profile Integer (dBm) [-115..-25] step 2 Class 3 -111 maximumAllowedULTXPower Lcell BSR Profile Integer (dBm) [-5033] Class 3 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
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 80/158
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.
7.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.
7.4.1 HIGH MOBILITY DETECTION ALGORITHM (HMD)

HMD is defined using 3 different parameters: tCrMax, nCr and tCrMaxHyst (either with or without HCS).
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 81/158
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 tCrMax nCr tCrMaxHyst LCell::tCrMax LCell::nCr LCell::tCrMaxHyst
HCS not Used LCell::nonHCStCRmax LCell::nonHCSnCR 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 82/158
7.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 selection/reselection parameters related to the serving cell
o o o o o o o o o o o o o o
SIB11
for
cell
qQualMin qRxLevMin maximumAllowedULTXPower sIntraSearch sInterSearch sSearchRAT sHCSRAT sSearchHCS sIB3CrQualityMeasure sib3qHyst1s sib3qHyst2s sIB3InterRATScalingFactor sIB3InterFreqScalingFactor sIB3TReselection
SIB11 for cell reselection parameters related to the neighbouring cells

o o o o o o o o
umtsMacroCellRsInfo::qQualMin umtsMacroCellRsInfo::qRxLevMin umtsMacroCellRsInfo::.qOffset1s umtsMacroCellRsInfo::qOffset2s umtsMacroCellRsInfo::maxAllowedULTXPwr gsmMacroCellRsInfo::qRxLevMin gsmMacroCellRsInfo::qOffset1s 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 83/158
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.
7.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 intrafrequency measurements.
7.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 interfrequency measurements.
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 4 to get a view on measurement decision based on Squal and Srxlev.
7.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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 84/158

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 4 to get a view on GSM measurement decision based on Squal and Srxlev.
7.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.
sIntraSearch Lcell BSR Profile Integer (dB) [-32..20] step 2 Class 3 2
Note: If a negative value is datafilled and sent in SIB3, the UE shall consider the value to be 0 (see [3GPP_R02]). Note: The value broadcast in SIB3/4 is half the real value sIntraSearch
Engineering Recommendation: sIntraSearch sIntraSearch setting depends on the deployment scenario for BSR:

In case BSR is deployed by a private and standalone user, sIntraSearch shall be set to 2 so as to delay Intra-frequency measurements as much as possible.
Otherwise, sIntraSearch shall be set to 9.
sInterSearch Lcell BSR Profile Integer (dB) [-32..20] step 2 Class 3 2
Note: If a negative value is datafilled and sent in SIB3, the UE shall consider the value to be 0 (see [3GPP_R02]). Note: The value broadcast in SIB3 is half the real value sIntraSearch
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 85/158

.
sSearchRAT Lcell BSR Profile Integer (dB) [-32..20] step 2 Class 3 2
Notes:
If a negative value is datafilled and sent in SIB3, the UE shall consider the value to be 0 (see [3GPP_R02]). In case the value 20 is received, the UE shall consider this IE as if it was absent (see [3GPP_R01] and [3GPP_R02]). The value broadcast in SIB3 is half the real value sSearchRAT.
sSearchHCS Lcell BSR Profile Integer (dB) [-1..91] step 2 Class 3 -1
Notes:

Provisioning of a negative value disables the RSCP triggered interfrequency measurements. The value broadcast in SIB3 is half the real value sSearchHCS
sHCSRAT Lcell BSR Profile Integer (dB) [-1..91] step 2 Class 3 -1 (i.e. not broadcast)
Notes:

Provisioning of a negative value disables the RCSP triggered GSM measurements. The value broadcast in SIB3 is half the real value sHCSRAT
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 86/158
Figure 4 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 sSearchHCS Intra-frequency Inter-frequency sHCSRAT Intra-frequency Inter-frequency GSM sSearchRAT sInterSearch Inter-frequency Inter-frequency GSM sIntraSearch No measurement
Squal
Figure 4 - Decision thresholds for Measurement Engineering Recommendation: Squal is relative to Qqualmin As Squal = Qqualmeas Qualmin and Srxlev = Qrxlevmeas Qrxlevmin, Figure 6 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.
7.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:

High Mobility Detection (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.
7.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 opertors strategy, as depicted in Figure 5:
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 87/158

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 UEs cell reselection behaviour between the layers and to prioritize layers. For the Serving BSR the priority is given through LCell::hcsPrioS (see chapter 7.1.1) For the Neighbours, the priority is obtained from the corresponding sniffers. 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 7.1.3. The other HCS parameters will be configurable per HCS priority.

InterBSRCellRsInfo::hcsPrioN for BSR neighbours (see chapter 7.1.5) umtsMacroCellRsInfo::hcsPrioN for 3G neighbours (see chapter 7.1.3) gsmMacroCellRsInfo::hcsPrioN for GSM neighbours (see chapter 7.1.4)
HM detected Lower priority is favored P3 P2 P1 P3 P3
HM not detected Higher priority is favored P3 P2

Copyright 1996 Northern Telecom
Figure 5 - HCS Priority and HMD
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 88/158
7.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 7.4.2 (sIntraSearch, sInterSearch, sSearchRat, sSearchHcs and sHcsRat) plus a new parameter, sLimitSearchRat, broadcast in SIB3.
7.4.3.2.1
HIGH-MOBILITY STATE NOT DETECTED

Figure 6 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 Inter-frequency hcsPrion >= hcsPrios sSearchHcs All Intra-frequency All Inter-frequency sInterSearch sIntraSearch Intra-frequency Inter-frequency hcsPrion > hcsPrios
Squal
Srxlev
GSM hcsPrion >= hcsPrios sHcsRat All GSM sSearchRat sLimitSearchRat No measurement
Squal
Figure 6 - 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 6 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
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 89/158

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 cells priority; UE is not supposed to measure GSM neighbouring cells.
7.4.3.2.2
HIGH-MOBILITY STATE DETECTED

Figure 7 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 7 - Decision thresholds for Measurement when high-mobility is detected
Note: the main difference between Figure 6 and Figure 7 is the filtering of neighbouring cell based on higher (High-Mobility not detected) or lower (HighMobility detected) HCS priority.
7.4.3.2.3
RECOMMENDATIONS WHEN HCS IS USED
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 90/158
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.
7.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.
umtsMacroCellRsInfoenableBroadcast | enableBroadcast Lcell | umtsMacroCellRsInfo BSR Profile | BSR Boolean {True, False} Class 3 TRUE
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 91/158
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.
gsmMacroCellRsInfoEnableBroadcast | enableBroadcast Lcell | gsmMacroCellRsInfo BSR Profile | Lcell Boolean {True, False} Class 3 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
interBSRCellRsInfoenableBroadcast | enableBroadcast Lcell | interBSRCellRsInfo BSR Profile | Lcell Boolean {True, False} Class 3 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
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 92/158
7.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
umtsMacroCellRsInfoqQualMin | qQualMin Lcell | umtsMacroCellRsInfo BSR Profile | BSR Integer (dB) [-24...0] Class 3 -19 umtsMacroCellRsInfoqRxLevMin | qRxLevMin Lcell | umtsMacroCellRsInfo BSR Profile | BSR Integer (dBm) [-115...-25] step 2 Class 3 -111
Note: As per 3GPP, IE present in SIB is encoded as follows: qRxLevMin = (IE * 2) +1
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 93/158

.
umtsMacroCellRsInfoMaxAllowedULTXPwr | MaxAllowedULTXPwr Lcell | umtsMacroCellRsInfo BSR Profile | BSR Integer (dBm) [-5033] Class 3 24
Rule: qQualMin / qRxLevMin values for umtsMacroCellRsInfo umtsMacroCellRsInfo::QQualMin / QRxLevMin that are defined for 3G Macro acting as neighbouring cell shall be equal to the setting broadcast by the same 3G Macro acting as serving cell.
7.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.
gsmMacroCellRsInfoqRxLevMin | qRxLevMin Lcell | gsmMacroCellRsInfo BSR Profile | Lcell Integer (dBm) [-115...-25] step 2 Class 3 -101
Note: As per 3GPP, IE present in SIB is encoded as follows: qRxLevMin = (IE * 2) +1

BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 94/158
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.
gsmMacroCellRsInfoMaxAllowedULTXPwr | MaxAllowedULTXPwr Lcell | gsmMacroCellRsInfo BSR Profile | Lcell Integer (dBm) [-5033] Class 3 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
Power Class 1 2 3 4 5
Nominal Maximum output Power GSM400, GSM 850 & GSM 900 DCS 1800 1 W (30 dBm) 8 W (39 dBm) 5 W (37 dBm) 2 W (33 dBm) 0.8 W (29 dBm) Table 7 - Maximum output power for GSM mobiles 0.25 W (24 dBm) 4 W (36 dBm) PCS 1900 1 W (30 dBm) 0.25 W (24 dBm) 2 W (33 dBm)
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 95/158
7.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 7.4.4.1; The corresponding parameters are listed below.
interBSRCellRsInfoqQualMin | qQualMin Lcell | interBSRCellRsInfo BSR Profile | Lcell Integer (dB) [-24...0] Class 3 -19 interBSRCellRsInfoqRxLevMin | qRxLevMin Lcell | interBSRCellRsInfo BSR Profile | Lcell Integer (dBm) [-115...-25] step 2 Class 3 -111
interBSRCellRsInfomaxAllowedULTXPwr | maxAllowedULTXPwr Lcell | interBSRCellRsInfo BSR Profile | Lcell Integer (dBm) [-5033] Class 3 24
7.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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 96/158
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.
7.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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 97/158

.
sib3qHyst1s Lcell BSR Profile Integer (dB) [040] range 2 Class 3 2
umtsMacroCellRsInfo::QOffset1s is the offset between the BSR cell and one of its 3G Macro neighbouring cells, in case the quality measure for cell selection/reselection is set to RSCP.
umtsMacroCellRsInfoqOffset1s | qOffset1s Lcell | umtsMacroCellRsInfo BSR Profile | BSR Integer (dB) [-5050] Class 3 0
gsmMacroCellRsInfo::QOffset1s is the offset between the BSR cell and one of its GSM neighbouring cells.
gsmMacroCellRsInfoqOffset1s | qOffset1s Lcell | gsmMacroCellRsInfo BSR Profile | Lcell Integer (dB) [-5050] Class 3 0
interBSRCellRsInfo::QOffset1s is the offset between the BSR cell and one of its BSR neighbouring cells.
interBSRCellRsInfoqOffset1s | qOffset1s Lcell | interBSRCellRsInfo BSR Profile | Lcell Integer (dB) [-5050] Class 3 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 reselection 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 98/158
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.
sIB3CrQualityMeasure Lcell BSR Profile Enum {ecN0, rSCP} Class 3 ecN0
7.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.
sib3qHyst2s Lcell BSR Profile Integer (dB) [040] range 2 Class 3 2
umtsMacroCellRsInfo::QOffset2s is the offset between the BSR cell and one of its 3G Macro neighbouring cells, in case the quality measure for Cell Reselection is set to EcNo.
umtsMacroCellRsInfoqOffset2s | qOffset2s Lcell | umtsMacroCellRsInfo BSR Profile | BSR Integer (dB) [-5050] Class 3 0
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 99/158
interBSRCellRsInfo::QOffset2s is the offset between the BSR cell and one of its BSR neighbouring cells, in case the quality measure for Cell Reselection is set to EcNo.
interBSRCellRsInfoqOffset2s | qOffset2s Lcell | interBSRCellRsInfo BSR Profile | Lcell Integer (dB) [-5050] Class 3 0
7.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 sib3TReselection time interval.
than
the
serving
cell
during
More than 1 second has elapsed since the UE camped on the current serving cell.
sib3TReselection Lcell BSR Profile Integer (s) [031] Class 3 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.
Inter-Release Delta: 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 100/158
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
sib3InterFreqScalingFactor Lcell BSR Profile Real [14.75] step 0.25 Class 3 1
Note: IE present in SIB is encoded as follows: sib3InterFreqScalingFactor = IE*0.25
sib3InterRATScalingFactor Lcell BSR Profile Real [14.75] step 0.25 Class 3 1
Note: IE present in SIB is encoded as follows: sib3InterRATScalingFactor = IE*0.25
sIB3SpeedDependentScalingFactor Lcell BSR Profile Real (dB) [0.01.0] step 0.1 Class 3 1
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 101/158
7.4.6 CELL RESELECTION RANKING CRITERION WITH HCS 7.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 o
W(t)=0 for t<0 W(t)=1 for t>=0
Ln equals to 0 or 1 depending on hcsPrio of neighbouring cell

o o
Ln = 0 if hcsPrio,n = hcsPrio,s Ln = 1 if hcsPrio,n <> hcsPrio,s
H criterion can be reformulated by distinguishing HCS priority of neighbouring cell with respect to serving cells: Hs = Qmeas,s qHcs,s Hn = Qmeas,n qHcs,n Hn = Qmeas,n qHcs,n tempOffset,n * W(t) if hcsPrio,n = hcsPrio,s if hcsPrio,n <> hcsPrio,s
Figure 8 depicts how to apply tempOffset on Hn for a cell whose HCS priority is different than the serving cells.
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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 102/158
In case, CPICH_Ec/N0 is chosen for Qmeas of UMTS neighbouring cell, tempOffset2 applies, tempOffset1 otherwise.
Quality measure
Timer Tn is started
Hn Qmeas,n - qHcsn tempOffsetn time Qmeas,n
penaltyTimen qHcsn
Figure 8 - 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, lets consider the following example:
Topology:
o FDD1 has lower priority hcsPrio1
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 103/158
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 6) 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 7.4.6.3 presents the ranking process when HCS is used.
7.4.6.2
HCS PARAMETERS
The parameters used while HCS is enabled are listed in chapter 7.1.1 Table 8 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
7.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:
Rs = Qmeas,s + qHyst,s Rn = Qmeas,n qOffset,s,n TOn * Ln
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 104/158
.
FDD Rscp (dBm)
-115 -114 -113 -112
qHcs 0 1 2 3
FDD EcNo (dB)

-24 -23.5 -23 -22.5
GSM Rssi (dBm)

-110 -109 -108 -107
45 46 47 48 49
-1.5 -1 -0.5 0 (spare)
-70 -69 -68 -67 -66
-65 -64 -63 -62 -61
72 73 74
(spare) (spare) (spare)
-43 -42 -41
-38 -37 -(spare)
88 89 90
(spare) (spare) (spare)
-27 -26 -(spare)
-(spare) -(spare) -(spare)
Table 8 - Mapping for qHcs
Once again, R criterion can be reformulated by distinguishing HCS priority of neighbouring cell with respect to serving cells:
Rs = Qmeas,s + qHyst,s Rn = Qmeas,n qOffset,s,n temporaryOffset,n * W(t) Rn = Qmeas,n qOffset,s,n if hcsPrio,n = hcsPrio,s if hcsPrio,n <> hcsPrio,s
Temporary offset now applies on the neighbouring cell whose HCS priority is equal to serving cells.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 105/158
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) 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)
7.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 sib3TReselection time interval.
than
the
serving
cell
during
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 7.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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 106/158
7.5.
HANDOVER TO 3G/2G
BSR only supports Blind HO to Macro cell (either 3G or 2G) for CS speech calls due to radio degradation. This means that:

No action is performed when standalone PS call is running. In case of multi-service (CS+PS), PS call is first released then handover is triggered.
7.5.1 ELIGIBILITY FOR HANDOVER

When a CS (resp. CS+PS) call is running, BSR checks the eligibility for blind handover using the following activation flag targetHOCS (resp. targetHOCSPS) whose behaviour is as follows:

When set to disable, handover is disabled and CS 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.

Class Value
targetHOCS Lcell BSR Profile Enumerated {disable, gsm, fdd, gsmPreferred, fddPreferred} Class 3 fddPreferred targetHOCSPS Lcell BSR Profile Enumerated {disable, gsm, fdd, gsmPreferred, fddPreferred} Class 3 fddPreferred

Class Value
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 107/158
Engineering Recommendation: targetHO For CS and CS+PS, it is recommended to perform blind HO to Macro 3G as much as possible; however, blind HO to GSM should be considered as a backup in case no 3G neighbouring cells is available. Therefore, targetHOCS and targetHOCSPS must be set to fddPreferred.
7.5.2 DETECTING RADIO DEGRADATION

Each time BSR detects the need for radio degradation assessment (i.e. when targetHOCS or targetHOCSPS 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:

Class Value
blindHO2d2fEcnoThreshold2d | Threshold2d Lcell | blindHO2d2fEcno BSR Profile Integer (dB) [-240] Class 3 -15
blindHO2d2fEcnoTimeToTrigger2d | TimeToTrigger2d Lcell | blindHO2d2fEcno BSR Profile Enumerated (ms) {timetotrigger0, timetotrigger10, timetotrigger20, timetotrigger40, timetotrigger60, timetotrigger80, timetotrigger100, timetotrigger120, timetotrigger160, timetotrigger200, timetotrigger240, timetotrigger320, timetotrigger640, timetotrigger1280, timetotrigger2560, timetotrigger5000} Class 3 timetotrigger320
Class Value
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 108/158

Class Value
.
blindHO2d2fEcnoHysteresis2d | Hysteresis2d Lcell | blindHO2d2fEcno BSR Profile Real (dB) [0...14.5] step 0.5 Class 3 2
The following setting is used for Event 2D RSCP:

Class Value
blindHO2d2fRscpThreshold2d | Threshold2d Lcell | blindHO2d2fRscp BSR Profile Integer (dBm) [-115-25] Class 3 -110
blindHO2d2fRscpTimeToTrigger2d | TimeToTrigger2d Lcell | blindHO2d2fRscp BSR Profile Enumerated (ms) {timetotrigger0, timetotrigger10, timetotrigger20, timetotrigger40, timetotrigger60, timetotrigger80, timetotrigger100, timetotrigger120, timetotrigger160, timetotrigger200, timetotrigger240, timetotrigger320, timetotrigger640, timetotrigger1280, timetotrigger2560, timetotrigger5000} Class 3 timetotrigger320
blindHO2d2fRscpHysteresis2d | Hysteresis2d Lcell | blindHO2d2fRscp BSR Profile Real (dB) [0...14.5] step 0.5 Class 3 2
Class Value
Class Value
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 109/158
.
blindHO2d2fEcnoThreshold2f | Threshold2f Lcell | blindHO2d2fEcno BSR Profile Integer (dB) [-240] Class 3 -15
The following setting is used for Event 2F EcNo:

Class Value
blindHO2d2fEcnoTimeToTrigger2f | TimeToTrigger2f Lcell | blindHO2d2fEcno BSR Profile Enumerated (s) {timetotrigger0, timetotrigger10, timetotrigger20, timetotrigger40, timetotrigger60, timetotrigger80, timetotrigger100, timetotrigger120, timetotrigger160, timetotrigger200, timetotrigger240, timetotrigger320, timetotrigger640, timetotrigger1280, timetotrigger2560, timetotrigger5000} Class 3 timetotrigger640
blindHO2d2fEcnoHysteresis2f | Hysteresis2f Lcell | blindHO2d2fEcno BSR Profile Real (dB) [0...14.5] step 0.5 Class 3 2
Class Value
Class Value
The following setting is used for Event 2F RSCP:

Class Value
blindHO2d2fRscpThreshold2f | Threshold2f Lcell | blindHO2d2fRscp BSR Profile Integer (dBm) [-115-25] Class 3 -110
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 110/158

.
blindHO2d2fRscpTimeToTrigger2f | TimeToTrigger2f Lcell | blindHO2d2fRscp BSR Profile Enumerated (s) {timetotrigger0, timetotrigger10, timetotrigger20, timetotrigger40, timetotrigger60, timetotrigger80, timetotrigger100, timetotrigger120, timetotrigger160, timetotrigger200, timetotrigger240, timetotrigger320, timetotrigger640, timetotrigger1280, timetotrigger2560, timetotrigger5000} Class 3 timetotrigger640
blindHO2d2fRscpHysteresis2f | Hysteresis2f Lcell | blindHO2d2fRscp BSR Profile Real (dB) [0...14.5] step 0.5 Class 3 2
Class Value
Class Value
7.5.3 HANDOVER EXECUTION

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 7.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 minBlindHoUmtsMacroRSCP for Macro 3G; minBlindHoGsmMacroRSSI for Macro 2G.
and
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 111/158

Class Value
.
minBlindHoUmtsMacroEcNo Lcell BSR Profile Integer [0...49] Class 3 11 minBlindHoUmtsMacroRSCP Lcell BSR Profile Integer [0...91] Class 3 5 minBlindHoGsmMacroRSSI Lcell BSR Profile Integer [0...63] Class 3 9

Class Value

Class Value
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
BSR then builds a list of eligible Macro 3G (resp. 2G) neighbours ranked using EcNo (resp. RSSI) if available, else RSCP. Note: with 2G Network Listening feature disabled, among GSM neighbouring cells, only those provisioned under GsmExtCell are eligible to Blind HO as they contain the mandatory information (locationAreaCode and rAC) for RANAP Relocation procedures that could not have been dynamically retrieved by BSR itself.
Finally, depending on targetHOCS or targetHOCSPS values (cf. section 7.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. Note: In case of multi-service CS+PS, Iu PS is released before performing the handover.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 112/158
7.6.
BSR TO BSR HANDOVER
Inter-Release Delta: Inter-BSR Handover, new feature in BCR02.02, will allow a CS call to continue seamlessly as a UE moves between locations supported by different BSRs within the same group.
To avoid inter BSR handovers, one BSR can be assigned to the Group 0 (chapter Error! Reference source not found.).
7.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
Restriction: Handovers Inter-BSR handover is supported for CS calls. PS connections will drop, when the coverage area of a BSR is left. If the user has both CS and PS connections established, then the PS connection is released and the CS call is handed over to the target BSR. In both cases the PDP context of the UE is preserved in the SGSN and UE and can be reestablished, when the UE camps on a new cell in IDLE mode or the CS handover has been completed in connected mode
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.
Inter-BSR handover does not impact the core network, 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. Source and target BSRs must belong to the same BSR cluster. Source and target BSRs must be connected to the same Brick.
Outgoing Handovers to other BSR enableOutgoingFemtoHandover is set to true. Incoming Handover from another enableInvomingFemtoHandover is set to true. BSR
are is
supported supported
if if
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 113/158
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.

Class Value
enableOutgoingFemtoHandover BSR Profile BSR Profile Boolean {True, False} Class 3 TRUE enableIncomingFemtoHandover BSR Profile BSR Profile Boolean {True, False} Class 3 TRUE

Class Value
7.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 couldnt handover to a BSR, will have to wait until this timer is expired before being able to try again.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 114/158

Class Value
.
tInterFemtoHandoverGuard BSR Profile BSR Profile Integer (s) [1120 Class 3 30
7.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. 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.
Class Value
intrafrequencyFilterCoefficient Lcell BSR Profile Enumerated {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 3 coeff4
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 115/158

.
bSRToBSRReportingCriteria1creportingInterval | reportingInterval Lcell | bSRToBSRReportingCriteria1c BSR Profile | BSR Enumerated {reportinginterval0=0, reportinginterval250=250, reportinginterval500=500, reportinginterval1000=1000, reportinginterval2000=2000, reportinginterval3000=3000, reportinginterval4000=4000, reportinginterval6000=6000, reportinginterval8000=8000, reportinginterval16000=16000, reportinginterval20000=20000, reportinginterval24000=24000, reportinginterval28000=28000, reportinginterval32000=32000, reportinginterval64000=64000} Class 3 reportinginterval1000
Class Value

bSRToBSRReportingCriteria1chysteresis | hysteresis Lcell | bSRToBSRReportingCriteria1c BSR Profile | BSR Real (dB) [0,0.5.. 7.5] Class 3 4
bSRToBSRReportingCriteria1ctimetoTrigger | timetoTrigger Lcell | bSRToBSRReportingCriteria1c BSR Profile | BSR Enumerated {timetotrigger0=0, timetotrigger10=10, timetotrigger20=20, timetotrigger40=40, timetotrigger60=60, timetotrigger80=80, timetotrigger100=100, timetotrigger120=120, timetotrigger160=160, timetotrigger200=200, timetotrigger240=240, timetotrigger320=320, timetotrigger640=640, timetotrigger1280=1280, timetotrigger2560=2560, timetotrigger5000=5000} Class 3 timetotrigger1280
Class Value
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 116/158
7.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 intraFrequency 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 7.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 signalling and user plane information to the targetBSR. 8. The target BSR completes the final signalling 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 117/158
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.
7.7.
PRESENCE INDICATOR
The BSR proposes several methods to inform an end user that it entered into its coverage.
Inter-Release Delta: New features have been implemented in BCR02.02 to increase the capabilities of the BSR regarding this notification.
7.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 o
IE Full name for network= BSR::fullnameofNetwork IE Short name for network= BSR::shortnameofNetwork
In the case LCell::AreaSelectNormalFlag is different from off and the IMSI is in the femtoACLlist,
o o
IE Full name for network= BSR::fullnameofNetwork IE Short name for network= BSR::shortnameofNetwork
In the case LCell::AreaSelectNormalFlag is different from off and the IMSI is in the femtoACLlistguest,
o o
IE Full name for network = BSR::fullnameofNetwork2 IE Short name for network= BSR::shortnameofNetwork2
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 118/158
If the MM/GMM Message does 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. 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. 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).

Class Value
areaSelectNormalFlag Lcell BSR Profile Enumerated {off=0, lac=1, sac=2, lacAndSac=3} Class 3 0 addNetworkNameIEToMMInfo BSR Profile BSR Profile Boolean {True, False} Class 3 FALSE

Class Value
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 119/158

Class Value
.
fullnameofNetwork BSR Profile BSR Profile StringType [Maxlength 255] Class 3 shortnameofNetwork BSR Profile BSR Profile StringType [Maxlength 255] Class 3 fullnameofNetwork2 BSR Profile BSR Profile StringType [Maxlength 255] Class 3 shortnameofNetwork2 BSR Profile BSR Profile StringType [Maxlength 255] Class 3 codingScheme BSR Profile BSR Profile integer {0,1} Class 3 0

Class Value

Class Value

Class Value

Class Value
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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 120/158
7.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 7.1.2) and that the proper configuration changes has been performed in the CN to allow the mobility of the users.
7.7.3 TONE GENERATION DURING VOICE CALL SETUP

Inter-Release Delta: This Feature has been added in BCR02.02
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.

Class Value
activateUserTone Femto | BSR Femto | BSR Boolean {True, False} Class 3 False
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 121/158

Class Value
.
userToneControl BSRClusterProfile | BSRClusterProfile | Integer [0100] Class 3 0 userToneProgressIndicator BSRClusterProfile | BSRClusterProfile | enum Pivalue {pi1=1, pi8=8} Class 3 pi8 userTonePrecedance BSRClusterProfile | BSRClusterProfile | enum TonePrecedance {femto=0, network=1} Class 3 femto

Class Value

Class Value
7.7.4 MM/GMM INFO GENERATION FROM FEMTO

Inter-Release Delta: This Feature has been added in BCR02.02
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 Core Network 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 7.7.1). To enable the feature, the parameter sparePara6 should include the string genNetName set to one of the values {full, short, fullAndShort}. To disable the feature, the parameter sparePara6 should include the string genNetName set to the value {disabled}.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 122/158
It is possible to add a country indication to the BSR network name by adding the string netNameAddCi=1 to the genNetName indication. To disable the country indication, netNameAddCi should be set to 0.
For instance, to display the Full Network Name and the Country Indication, following string has to be inserted in sparePara6 genNetName=full;netNameAddCi=1 If the full network name and/or the short network name are not provisioned in the BSR, the BSR does not include the corresponding information in the GMM/MM Information message. 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 7.7.1).
sparePara6 BSR Profile BSR Profile String Class 3 "genNetName=disabled"
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 Network Identification This feature should not be enabled when the Core Network 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 123/158
8.
8.1.
HSXPA
HSUPA (E-DCH)
Inter-Release Delta: HSuPA From BCR2.2, the BSR is supporting HSuPA. This section will deal with the introduction of this feature.
8.1.1 INTRODUCTION
HSUPA functionality was introduced in Release 6 of 3GPP. It extends the R99 UL capability providing a path to achieve more than 384kbps 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 higher data packet throughput in the UL with up to 5.74Mbps theoretical peak data rate specified depending on the capability of the UE. Further more 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 Node B scheduling. HSUPA adds a new dedicated transport channel in the UL and 3 new grant channels in the DL. It also adds 2 new MAC entities with one MAC-e in the Node B and one MAC-es entity in the RNC.
Restriction: Performance Limitation Due to the limitation of the Chip embedded in the Femto, only the performances of UE categories cat1, cat2 and cat3 are reachable. As a result, the maximum UL Throughput, as well as the aggregate cell Throughput is limited to 1.38Mbps on RLC Level.
8.1.2 FEATURE ACTIVATION

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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 124/158

Class Value
.
activateEDCH Femto | BSR Femto | BSR Boolean {True, False} Class 1 TRUE
Rule: E-DCH activation E-DCH shall 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.
Restriction: EDCH::maxEdchUsersPerCell This parameter should be kept to 4 in BCR2.2, irrespectively of the Hardware type. This is due to a Software limitation.

Class Value
maxEdchUsersPerCell EDCH BSR Profile Integer [0..4] Class 3 4
8.1.3 RAB COMBINATIONS

The RAB combinations supported by the BSR are presented in Table 9.
UL SRB UL SRB over DCH UL SRB over E-DCH
I/B (UL / DL) E-DCH (10ms TTI) E-DCH (10ms TTI) HDSPA HDSPA
Conversational (UL / DL) 12.2 12.2
Table 9 - Service Combinations with E-DCH
8.1.4 SELECTION OF E-DCH AS THE CHANNEL TYPE

During PS RAB establishment the BSR will select E-DCH as the target channel based upon the following rules:
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 125/158

The UE is E-DCH Capable HSDPA must be active and HSDPA resources available in the DL towards the UE in order to consider E-DCH UL. Feature activation flag BSR:: activateEDCH =TRUE This call will result 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 will set 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
8.1.5 FEMTO SPECIFICITY - DEFINITIONS

In [3GPP_R10] the following definitions can be found:

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. The UE has only one serving E-DCH RLS.
From these definitions there are three categories of users to be handled by the EDCH 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 and/or dedicated relative grants sent on E-RGCH. 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 126/158
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 Peerserving users) as defined by 3GPP cannot be found. For the same reasons, the Serving E-DCH RLS will only consist of the BSR cell.
8.1.6 HSUPA UE CATEGORIES

For HSUPA, the following UE categories have been specified in [3GPP_R07] and displayed in Table 10. The resulting maximum HSUPA throughput for each UE category is given in Table 11. These figures will be halved in case CS Voice Calls are made in parallel to the EDCH Packet call. The Spreading Factor will be reduced to SF4 and the performances correspondingly.
Restriction: Performance Limitation The BSR supports all UE categories. Due to current limitation of the Chip embedded in the Femto, UEs will however be configured to the capabilities up to Category 3. As a result, the Maximum UL Throughput is limited to 1.38Mbps on RLC Level. The yellow rows in Table 10 and Table 11 are the ones that are currently supported by the BSR.
E-DCH category
Maximum number of E-DCH codes transmitted 1 2 2
Minimum spreading factor
Support for 10 TTI EDCH
Maximum number of bits of an E-DCH transport block transmitted within a 10 ms E-DCH TTI 7110 14484 14484
Category 1 Category 2 Category 3
SF4 SF4 SF4
10 ms TTI 10 ms TTI 10 ms TTI
Table 10 - E-DCH UE categories
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 127/158

E-DCH category Maximum number of E-DCH codes transmitted 1 2 2 Minimum spreading factor
.
Maximum Data Rate at MAC-e layer Maximum RLC throughput
Support for TTI E-DCH
Category 1 Category 2 Category 3
SF4 SF4 SF4
10 ms TTI 10 ms TTI 10 ms TTI
0.71 Mbps 1.45 Mbps 1.45 Mbps
0.67 Mbps 1.38 Mbps 1.38 Mbps
Table 11 - Maximum E-DCH Throughput
8.1.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 - UL physical dedicated E-DCH data channel E-DPCCH - UL physical dedicated E-DCH control channel E-AGCH - DL Absolute Grant Channel E-RGCH - DL Relative Grant Channel E-HICH - DL HARQ Indicator Channel
Details of the channel structures can be found in [3GPP_R06].
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 signaling, e.g. for UL power control, as well as higher layer signalling information (but this can also be carried over E-DCH directly). The EDCH transport channel is characterized by:

Only for UL TTI : 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 Redundancy. HARQ retransmissions of type Incremental
Turbo coding with rate 1/3 is used
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 128/158

CRC is 24 bits length E-TFCI (Transport Format Combination Indication) indicates which format is currently used for the UL transmission
EAG ECH HI EDP CH DC , E H/ - R G C UL EDP H /D L CC DP H CH
Cell A = Serving E-DCH cell
UE
Figure 9 - HSUPA channels and associated R99 channels

Class Value
eDCHMACdFlowMaxRet EDCHMACdFlow BSR Profile Integer [0..15] Class 3 3
8.1.7.1
UPLINK CHANNELS
E-DPDCH (Enhanced Dedicated Physical Data Channel): This channel is an 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 2 x SF2 and 2 x SF4 is allowed by the standards. The channel coding uses 1/3 Turbo code with a channel bit rate of a single EDPDCH which ranges from 15kbps (SF=256) up to 1920kbps (SF=2).
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 129/158
Restriction: E-DPDCHs Number The BSR currently supports only

2 x E-DPDCHs, each with a 2 x SF4 spreading factor when there is no DPDCH which limits the maximum HUSPA rate supported to 1.45Mbps and 1 x E-DPDCH with 1 x SF4 spreading factor when there is a DPDCH which limits the maximum HUSPA rate supported to 0.71Mbps..
E-DPCCH (Enhanced Dedicated Physical Control Channel): This channel associated with the E-DPDCH is a single E-DPCCH and carries the UL signaling information. This is composed of the E-TFCI (7 bits), which is related to the EDPDCH transport block size, the 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 10.
E-DPDCH
Data, Ndata bits Tslot = 2560 chips, Ndata = M*10*2 bits (k=07)
k
E-DPCCH
10 bits
Tslot = 2560 chips
Slot #0
Slot #1
Slot #2
Slot #3
Slot #i
Slot #14
Subframe #0 1 subframe = 2 ms
Subframe #1
Subframe #2
Subframe #3
Subframe #4
1 radio frame, Tf = 10 ms
Figure 10 - 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 12 and Table 13.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 130/158

Slot Format #i 0 1 2 3 4 5 6 7 8 9 Channel Bit Rate (kbps) 15 30 60 120 240 480 960 1920 1920 3840
.
SF 256 128 64 32 16 8 4 2 4 2 Bits/ Frame 150 300 600 1200 2400 4800 9600 19200 19200 38400 Bits/ Subframe 30 60 120 240 480 960 1920 3840 3840 7680 Bits/Slot Ndata 10 20 40 80 160 320 640 1280 1280 2560
Bits/Symbol M 1 1 1 1 1 1 1 1 2 2
Table 12 - E-DPDCH slot formats

Slot Format #i 0 Channel Bit Rate (kbps) 15 SF 256 Bits/ Frame 150 Bits/ Sub frame 30 Bits/Slot Ndata 10
Table 13 - E-DPCCH slot formats Figure 11 illustrates the spreading operation for the E-DPDCHs and the E-DPCCH, 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 EDPCCH gain factor as defined in [3GPP_R11].

Class Value
eDPCCHPowerOffset ETFCS BSR Profile Integer [0..8] Class 3 4
The translation of the signaled values for the eDPCCHPowerOffset into amplitude ratio is given in Table 14.
Signalled values for E-DPCCH 8 7 6 5 4 3 2 1 0 Quantized amplitude ratios Aec = ec/c 30/15 24/15 19/15 15/15 12/15 9/15 8/15 6/15 5/15
Table 14 - Quantization for E-DPCCH
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 131/158
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 15. This calculation is explained in more details in 8.1.10. 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 channelization code allocation for the E-DPDCH and more details for the associated DPCCH/DPDCH and HS-DPCCH.
Signalled values for E-DPDCH 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Quantized amplitude ratios Aed = ed/c 168/15 150/15 134/15 119/15 106/15 95/15 84/15 75/15 67/15 60/15 53/15 47/15 42/15 38/15 34/15 30/15 27/15 24/15 21/15 19/15 17/15 15/15 13/15 12/15 11/15 9/15 8/15 7/15 6/15 5/15
Table 15 - Quantization for E-DPDCH
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 132/158

ced,1 E-DPDCH1 . . . . E-DPDCHk . . . . E-DPDCHK cec E-DPCCH ec ed,1
.
iqed,1
ced,k
ed,k
iqed,k
ced,K
ed,K
iqed,K
I+jQ Se-dpch
iqec
Figure 11 - Spreading for E-DPDCH/E-DPCCH The Transmit processing chain for the E-DPDCH depicted on Figure 12 is detailed in [3GPP_R13]. 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, 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 service profile (ETFCS) with the parameter punctureLimit. These parameters are sent by RRC to the UE (using IE E-DPDCH Info).
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 133/158
.
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 12 - E-DPDCH Channel Coding

Class Value
punctureLimit ETFCS BSR Profile Real [0.44,0.48..1.00] Class 3 0.72
8.1.7.2
DOWNLINK SIGNALING CHANNELS

E-AGCH (E-DCH Absolute Grant Channel): This single DL channel carries the 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 (30kbps) with a spreading factor SF=256. To identify the user a 16 bit CRC is attached. The control information on E-AGCH is
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 134/158
convolutional encoded with a rate of 1/3.Figure 13 illustrates the frame and subframe 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 1 radio frame, Tf = 10 ms
Figure 13 - E-AGCH frame structure
An E-DCH absolute grant shall be transmitted over one E-AGCH sub-frame or one E-AGCH frame. The transmission over one E-AGCH frame shall be 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 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 14. Note: E-AGCH (Absolute Grant Channel) and E-RGCH (Relative Grant Channel) 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 shall be 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 shall be used on an E-RGCH transmitted to UEs for which the cell transmitting the E-RGCH is not in the E-DCH serving radio link set.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 135/158
The sequence bi,0, bi,1, , bi,39 transmitted in slot i in Figure 14 is given by bi,j = a Css,40,m(i),j. The orthogonal signature sequences Css,40,m(i) is given in [3GPP_R06] In a serving E-DCH radio link set, the relative grant a is set to +1, 0, or -1 and in a radio link not belonging to the serving E-DCH radio link set, 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 Tslot = 2560 chip
bi,39
Slot #0
Slot #1
Slot #2
Slot #i
Slot #14
1 subframe = 2 ms 1 radio frame, Tf = 10 ms

Figure 14 - E-RGCH and E-HICH structure
Restriction: E-RGCH (E-DCH Relative Grant Channel) The Femto BSR does not support common relative grants.
E-HICH (E-DCH HARQ Acknowledgement Indicator Channel): This single 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 14.
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 shall be 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 14 is given by bi,j = a Css,40, m(i),j. The orthogonal signature sequences Css,40,m(i) is given in [3GPP_R06] In a radio link set containing the serving E-DCH radio link set, the hybrid ARQ acknowledgement indicator a is set to +1 or 1, and in a radio link set not
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 136/158
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.
8.1.8 PRINCIPLE OF E-DCH OPERATION

The principle of E-DCH operation is presented in Figure 15. Following steps are performed:
If the UE has data in its buffer and doesnt 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 EDPDCH, 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 o o o
Average Ec/Io measured on DPCCH Average served MAC-e transport block size Happy Bit Reference scheduling grant
For each cell the following common values are calculated:

o o
Average received total wideband power (RTWP) Average E-DCH load for the Serving users Non-serving users Peer-serving users
o o
Average DCH load Average UL load due to HS-DPCCH
From the cell measurements 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
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 137/158
Bit is used to calculate the requests. If unhappy is reported then the current reference scheduling grant is increased by applying relative grants.

Based on these requests a hypothetical E-DCH load is calculated, which is then compared to the available E-DCH load. If the hypothetical E-DCH load is lower than the available E-DCH load, 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 non-serving users: This is done by using common relative grants. Downgrade peer-serving users Downgrade serving users: Here, a proportional fair rule is applied to sort the users, so that the UEs with lowest priority are downgraded first.
o o
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. If an UE stops transmitting for a certain duration, the Node B sends a zero absolute grant to deactivate it.
UE
Scheduling information UE detects data in buffer Scheduling grant
NodeB
Scheduler takes UE for scheduling
DATA
Scheduling grant
Scheduling grant
Scheduling information
Figure 15 - Principle of E-DCH Scheduling, Scheduling Grants are in Terms of AG/RG
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 138/158
8.1.9 DL SCHEDULING INFORMATION SERVING GRANTS
8.1.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-topilot power ratio, TPR), which are defined in [3GPP_R10]. On reception of absolute grants the UE will set: SG = AG In the case the special AG value Zero_Grant is transmitted, the UE will be prohibited transmission.
8.1.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 Node B 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".
Non-serving Relative Grant:
Transmitted on downlink on the E-RGCH from a non-serving E-DCH RL, the nonserving relative grant allows neighbouring Node Bs to adjust the transmitted rate of UEs that are not under their control in order to avoid overload situations. By definition, there could be multiple non-serving relative grant commands received by MAC at any time. This indication can take two different values, "DOWN" or "HOLD".
When the Serving_Grant needs to be determined due to E-RGCH signalling, the UE shall:
Determine the lowest power ratio in the configured SG-table (Table 16) that is equal or higher to the reference_ETPR, and determine the corresponding index in the SG-table: SGLUPR; 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 will determine the Serving_Grant as follows:
o
if SGLUPR < "3-index-step threshold": Serving_Grant = SG[MIN(SGLUPR + 3 , 37)].
if "3-index-step threshold" <= SGLUPR < "2-index-step threshold":
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 139/158
Serving_Grant = SG[MIN(SGLUPR + 2 , 37)].

o
if "2-index-step threshold" <= SGLUPR:: Serving_Grant = SG[MIN(SGLUPR + 1 , 37)].
If the UE received a Serving Relative Grant "DOWN", determine the Serving_Grant: Serving_Grant = SG[MAX(SGLUPR -1 , 0)].
If the UE received a Non-serving Relative Grant "DOWN", determine the Serving_Grant: Serving_Grant = SG[MAX(SGLUPR -1 , 0)].
The theresholds "3-index-step threshold" and "2-index-step threshold" are configurable through the parameters eRGCH2StepThreshold and eRGCH3StepThreshold.
Index
Scheduled Grant
37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3
(168/15)2*6 (150/15)2*6 (168/15)2*4 (150/15)2*4 (134/15)2*4 (119/15)2*4 (150/15)2*2 (95/15)2*4 (168/15)2 (150/15)2 (134/15)2 (119/15)2 (106/15)2 (95/15)2 (84/15)2 (75/15)2 (67/15)2 (60/15)2 (53/15)2 (47/15)2 (42/15)2 (38/15)2 (34/15)2 (30/15)2 (27/15)2 (24/15)2 (21/15)2 (19/15)2 (17/15)2 (15/15)2 (13/15)2 (12/15)2 (11/15)2 (9/15)2 (8/15)2
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 140/158

2 1 0
.
(7/15)2 (6/15)2 (5/15)2
Table 16 - Scheduling Grant Table

Class Value
eRGCH2StepThreshold ETFCS BSR Profile Integer [0..37] Class 3 18 eRGCH3StepThreshold ETFCS BSR Profile Integer [0..37] Class 3 15

Class Value
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.
8.1.10 E-TFC SELECTION

The E-TFC selection is performed at each TTI. [3GPP_R10] provides with the full description of the E-TFC selection process. UEs configured with both, DCH and E-DCH transport channels, performs 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 fulfills 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).
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 141/158
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 the reference E-TFCIs (eTFC::referenceETFC) and the corresponding reference power offsets (eTFC::referenceETFCPowerOffset) as well as on the HARQ power offset (eDCHMACdFlowHARQPO), which are signaled by RRC to the UE. The HARQ power offset is set per MAC-d flow (EDCHMACdFlow). Table 17 provides with the reference values.

Class Value
ReferenceETFC ETFCtable BSR Profile Integer [0..127] Class 3 See Table ReferenceETFCPowerOffset ETFCtable BSR Profile Integer [0..29] Class 3 See Table eDCHMACdFlowHARQPO EDCHMACdFlow BSR Profile Integer [0..6] Class 3 0

Class Value

Class Value
eTFCtable::ReferenceETFC 3 9 25
eTFCtable::ReferenceETFCPowerOffset 10 13 17
Table 17 Reference 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.
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 142/158

Class Value
.
schedulingPowerOffset ETFCS BSR Profile Integer (dB) [0..6] Class 3 0
8.1.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.
8.1.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 shall not be 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] For every E-DCH transmission, the Happy Bit shall be 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 shall be set to "happy".

Parameter Object Granularity Range & Unit happyBitDelay ETFCS BSR Profile Enumerated {happyBitDelay2=2, happyBitDelay10=10, happyBitDelay20=20, happyBitDelay50=50, happyBitDelay100=100, happyBitDelay200=200, happyBitDelay500=500, happyBitDelay1000=1000} Class 3 happyBitDelay10
Class Value
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 143/158
8.1.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 16 includes the following fields:
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 16 - Scheduling Information format
Scheduling information reports will be 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 shall be triggered as soon as there are data to transmit. If data with higher priority than the data already in the transmission buffer arrives, the transmission of a Scheduling Information shall be triggered. 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
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 144/158
schedulingNoGrantPeriodicity, the transmission of a Scheduling Information shall be triggered. T_SING shall be restarted when the transmission of a SI is triggered. T_SING shall be 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 shall be triggered. 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 shall be triggered. 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 shall be triggered. T_SIG shall be stopped and reset once the SG equals "Zero_Grant. T_SIG is restarted when the transmission of a Scheduling Information is triggered. Once the SG becomes equal to "Zero_Grant" and data are to be sent, the transmission of a Scheduling Information shall be triggered. The scheduling information is sent together with scheduled data in MAC-e header.
schedulingNoGrantPeriodicity ETFCS BSR Profile Enumerated {everyEDCHTTI=0, schedulingPeriod4=4, schedulingPeriod10=10, schedulingPeriod20=20, schedulingPeriod50=50, schedulingPeriod100=100, schedulingPeriod200=200, schedulingPeriod500=500, schedulingPeriod1000=1000, noReport=2000} Class 3 schedulingPeriod100
Class Value
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 145/158

.
schedulingGrantPeriodicity ETFCS BSR Profile Enumerated {everyEDCHTTI=0, schedulingPeriod4=4, schedulingPeriod10=10, schedulingPeriod20=20, schedulingPeriod50=50, schedulingPeriod100=100, schedulingPeriod200=200, schedulingPeriod500=500, schedulingPeriod1000=1000, noReport=2000} Class 3 schedulingPeriod100
Class Value
8.1.12 AIR INTERFACE LIMITATION

The Maximum Target Received Total Wide Band Power (8.1.8), which is equivalent to the limitation of the air interface resources, is defined as Noise floor measurement+EDCH::maxULNoiseRiseEdch.
This result is lower and upper bounded in the range defined {EDCH::eDCHminNoiseFloor, EDCH::eDCHmaxNoiseFloor} respectively. This will define the upper RTWP limit used during the scheduling.
by
Note: The Noise floor measurement is described in 6.1.2.1.
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.

Class Value
maxULNoiseRiseEdch EDCH BSR Profile Integer (dB) [0..50] Class 1 20
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 146/158

Class Value
.
eDCHminNoiseFloor EDCH BSR Profile Real (dB) [-112.0,-111.9..-50.0] Class 1 -100 eDCHmaxNoiseFloor EDCH BSR Profile Real (dB) [-112.0,-111.9..-50.0] Class 1 -100

Class Value
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 147/158
8.1.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 algorithm is the control of the number of HARQ retransmissions. The transmit power of the E-DCH channels (E-DPCCH/ EDPDCH) is tied to the transmit power of the DPCCH by power offsets (as described in 8.1.7.1). An outer loop power control controls in the femto the setting of the SIR targets. In normal single user operation the target should be a very low number of HARQ retransmissions to maximise throughput, but to drop the SIR target down far enough to allow the UE to maximise 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 outerloop power control entity shall be retrieved from one of three power control profiles based upon the number of users.
When the number of E-DCH users is eDCHMACdFlowSIRstepThr1 is to be used.
below
Threshold1,
the
profile
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 shall be applied to all outerloop 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 EDCHMACdFlow::maxNumActiveEdchUsersPerCellForThr1 EDCHMACdFlow::maxNumActiveEdchUsersPerCellForThr2.
parameters and
Following parameters can be configured for each power control profiles eDCHMACdFlowSIRstepThr1, eDCHMACdFlowSIRstepThr2 and eDCHMACdFlowSIRstepThr3 : sIRstep0HARQReTx, sIRstep1HARQReTx, sIRstep3HARQReTx and sIRstep4HARQReTx nbrOfConsecutiveZeroHARQReTxThreshold sIRstepConsecZeroHARQReTx sIRstepHfi
sIRstep2HARQReTx,
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 148/158
Table 18 provides with the values for the parameters of the three profiles.
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 the case it is smaller, it will be set to the minimum value. In the case it is higher, it will be set to the maximum value.

Class Value
maxNumActiveEdchUsersPerCellForThr1 EDCHMACdFlow BSR Profile Integer [0..4] Class 3 1 maxNumActiveEdchUsersPerCellForThr2 EDCHMACdFlow BSR Profile Integer [0..4] Class 3 3 eDCHMACdFlowSIRstepThr{1,2,3}sIRstep{0,1,2,3,4 }HARQReTx | sIRstep{0,1,2,3,4}HARQReTx EDCHMACdFlow | eDCHMACdFlowSIRstepThr{1,2,3} EDCHMACdFlow | Real (dB) [-10.000,-9.999..10.000] Class 3 See Table

Class Value
Parameter Object
Granularity Range & Unit Class Value
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 149/158

Parameter
.
eDCHMACdFlowSIRstepThr{1,2,3}nbrOfConsecuti veZeroHARQReTxThreshold | nbrOfConsecutiveZeroHARQReTxThreshold EDCHMACdFlow | eDCHMACdFlowSIRstepThr{1,2,3} EDCHMACdFlow | Integer [0..1024] Class 3 See Table
eDCHMACdFlowSIRstepThr{1,2,3}sIRstepHfi | sIRstepHfi EDCHMACdFlow | eDCHMACdFlowSIRstepThr{1,2,3} EDCHMACdFlow | Real (dB) [-10.000,-9.999..10.000] Class 3 See Table
eDCHMACdFlowSIRstepThr{1,2,3}sIRstepConsecZ eroHARQReTx | sIRstepConsecZeroHARQReTx EDCHMACdFlow | eDCHMACdFlowSIRstepThr{1,2,3} EDCHMACdFlow | Real (dB) [-10.000,-9.999..10.000] Class 3 See Table
Object Granularity Range & Unit Class Value

Parameter Object
Granularity Range & Unit Class Value
sIRstep0HARQReTx sIRstep1HARQReTx sIRstep2HARQReTx sIRstep3HARQReTx sIRstep4HARQReTx nbrOfConsecutive ZeroHARQReTxThreshold sIRstepConsecZeroHARQReTx sIRstepHfi
eDCHMACdFlow eDCHMACdFlow eDCHMACdFlow SIRstepThr1 SIRstepThr2 SIRstepThr3 0.000 0.000 -0.010 0.100 0.100 0.000 0.100 0.100 0.100 0.100 0.100 0.100 0.100 0.100 0.100 200 -0.020 0.150 15 -0.020 0.150 200 -0.020 0.150
Table 18 eDCHMACdFlow parameter values
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 150/158
8.1.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.
eAGCHpowerOffset EDCH BSR Profile Real (dB) [-32.00,-31.75..31.75] Class 1 10 eRgchHichPowerOffset EDCH BSR Profile Real (dB) [-32.00,-31.75..31.75] Class 1 1.5
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 151/158
9.
9.1.
INDEXES
TABLE INDEX
Table 1 - Hardware Feature ............................................................................................................... 6 Table 2 - RRM Features..................................................................................................................... 7 Table 3 - Mobility Features................................................................................................................. 7 Table 4 - Enterprise BSR Femto Specific Parameters..................................................................... 26 Table 5 - Power reservation for common channels.......................................................................... 34 Table 6 - UE power Class vs. maximum output power .................................................................... 80 Table 7 - Maximum output power for GSM mobiles......................................................................... 95 Table 8 - Mapping for qHcs ............................................................................................................ 105 Table 9 - Service Combinations with E-DCH ................................................................................. 125 Table 10 - E-DCH UE categories ................................................................................................... 127 Table 11 - Maximum E-DCH Throughput....................................................................................... 128 Table 12 - E-DPDCH slot formats .................................................................................................. 131 Table 13 - E-DPCCH slot formats .................................................................................................. 131 Table 14 - Quantization for E-DPCCH ............................................................................................... 131 Table 15 - Quantization for E-DPDCH ............................................................................................... 132 Table 16 - Scheduling Grant Table ................................................................................................ 141 Table 17 Reference E-TFC Power Offset Information ................................................................ 142 Table 18 eDCHMACdFlow parameter values ............................................................................. 150
9.2.
FIGURE INDEX
Figure 1 - BSR FMS Model .............................................................................................................. 11 Figure 2 - Dynamic HSDPA Power Allocation.................................................................................. 35 Figure 3 - HCS Example .................................................................................................................. 48 Figure 4 - Decision thresholds for Measurement ............................................................................. 87 Figure 5 - HCS Priority and HMD ..................................................................................................... 88 Figure 6 - Decision thresholds for Measurement when high-mobility is NOT detected ................... 89 Figure 7 - Decision thresholds for Measurement when high-mobility is detected............................ 90 Figure 8 - Applying tempOffset on Hn when hcsPrio,n <> hcsPrio,s ............................................. 103 Figure 9 - HSUPA channels and associated R99 channels........................................................... 129 Figure 10 - E-DPCCH / E-DPDCH frame structure........................................................................ 130 Figure 11 - Spreading for E-DPDCH/E-DPCCH ............................................................................ 133 Figure 12 - E-DPDCH Channel Coding.......................................................................................... 134 Figure 13 - E-AGCH frame structure.............................................................................................. 135 Figure 14 - E-RGCH and E-HICH structure ................................................................................... 136 Figure 15 - Principle of E-DCH Scheduling, Scheduling Grants are in Terms of AG/RG .............. 138 Figure 16 - Scheduling Information format..................................................................................... 144
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 152/158
9.3.
AG AICH ARFCN ARQ BCH BCR BSG BSR CAC CM CPICH CRS CS DBC DCH DL ePLMN E-AGCH E-DCH E-DPCCH E-DPDCH E-HICH E-RGCH E-TFC E-TFCI FACH FDD FMS FPUG GMM
ACRONYMS
Absolute Grant Acquisition Indication Channel Absolute Radio Frequency Channel Number Automatic Repeat Request Broadcast Channel BSR Cluster Release BSR Signaling Gateway Base Station Router Call Admission Control Compressed Mode Common Pilot Control Channel Cell Reselection Circuit Switched Dynamic Bearer Control Dedicated Channel DownLink Equivalent Public Land Mobile Network Enhanced Access Grant Channel Enhanced DCH (also referred as HSUPA or EUL) Enhanced Dedicated Physical Control Channel Enhanced Dedicated Physical Data Channel Enhanced Hybrid ARQ Indicator Channel Enhanced Relative Grant Channel E-DCH Transport Format Combination E-DCH Transport Format Combination Indicator Forward Access Channel Frequency Division Duplex Femto Management Solution Femto Parameter User Guide GPRS MM
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 153/158

GSM HARQ HCS HMD HO HSDPA HDUPA HS-DSCH HW IMSI KPI LA LAC LAU MAC MIB MM NBAP OAM PCH PDP PICH PLMN PS PSC QoS RAB RAC RANAP RAT RAU RF RG
Global System for Mobile Communications Hybrid ARQ Hierarchical Cell Structure High Mobility Detection algorithm Handover High Speed Downlink Packet Access High Speed Uplink Packet Access High Speed Downlink Shared CHannel Hardware International Mobile Station Identity Key Performance Indicator Location Area Location Area Code Location Area Update Medium Access Control Master Information Bloc Mobility Messasge NodeB Application Protocol Operation and Maintenance Paging Channel Packet Data Protocol Page Indication Channel Public Land Mobile Network Packet Switched Primary Scrambling Code Quality of Service Radio Bearer Routing Area Code Radio Access Network Application Protocol Radio Access Technology Routing Area Update Radio Frequency Relative Grant
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 154/158

RLS RoT RRC RSCP RSSI RTWP SAC SCH SF SGSN SHO SIB SIM SIR SRB SW TSSI Tx UE UL UMTS USIM UTRA VIP Radio Link Set Rise over Thermal Radio Resource Control Received Signal Code Power
Received Signal Strength Interference Received Total Wideband Power Service Access Code Synchronization Channel Spreading Factor Serving GPRS Service Node Soft Handover System Information Block Subscriber Identify Module Signal to Interference Ratio Signaling Radio Bearer Software Transmit Signal Strength Indicator Transmit User Equipment UpLink Universal Mobile Telecommunication System UMTS Subscriber Identify Module UMTS Terrestrial Radio Access Very Important Person
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 155/158
9.4.
MAPPING FMS - MIM

FMS Object Femto BSR Profile Femto BSR Profile Femto BSR Profile BSR Profile CCPower Lcell Lcell BSR Profile BSR Profile BSR Profile BSR Profile BSR Profile BSR Profile BSR Profile BSR Profile BSR Profile BSR Profile BSR Profile gsmFrequencyList GSMExtCell GSMExtCell gsmFrequencyList gsmFrequencyList Lcell Lcell Lcell Lcell Lcell Lcell Lcell Lcell Lcell Lcell Lcell Lcell Lcell Femto::BSRneighbourCell BSR Profile Lcell Lcell Lcell FddExtCell GSMExtCell BSR Profile Lcell Lcell Lcell Lcell Lcell Lcell FddExtCell BSR Profile BSR Profile BSR Profile EDCH EDCH EDCHMACdFlow EDCHMACdFlow EDCHMACdFlow EDCHMACdFlow EDCHMACdFlow EDCHMACdFlow MIM Name notAllowedCell notAllowedCell accessMode activateEDCH activateUserTone MIM Object FddExtCell GSMExtCell BSR BSR BSR
FMS Name accessMode aCRpreference activateEDCH activateFemtoToFemtoCommunications activateUserTone activeCallRedirectEnabled addNetworkNameIEToMMInfo aICHPower allowedGSMOpenSearch areaSelectNormalFlag autoConfigPWBsrBasedPilotPowerAdjustInterval autoConfigPWindoorPenetrationLoss autoConfigPWmaxCoverageDistancem autoConfigPWmaxPilotPowerdBm autoConfigPWMinBSRPowerdBm autoConfigPWminPilotPowerdBm autoConfigPWpAdjustmentStepdB autoConfigPWpCPICHPowerIni autoConfigPWTargetPilotEcIodB autoConfigPWTargetPilotRSCPdBm autoConfigPWUeBasedPilotPowerAdjustInterval bandIndicator bCC bCCHArfcn bCCHARFCNsize bCCHARFCNstart bCHPower blindHO2d2fEcnoHysteresis2d blindHO2d2fEcnoHysteresis2f blindHO2d2fEcnoThreshold2d blindHO2d2fEcnoThreshold2f blindHO2d2fEcnoTimeToTrigger2d blindHO2d2fEcnoTimeToTrigger2f blindHO2d2fRscpHysteresis2d blindHO2d2fRscpHysteresis2f blindHO2d2fRscpThreshold2d blindHO2d2fRscpThreshold2f blindHO2d2fRscpTimeToTrigger2d blindHO2d2fRscpTimeToTrigger2f bSRIdentity bsrPilotPowerAdjustMode bSRToBSRReportingCriteria1chysteresis bSRToBSRReportingCriteria1creportingInterval bSRToBSRReportingCriteria1ctimetoTrigger cellId cellIdentity codingScheme dBCQualReportingCriteriaDLEcN0Hysteresis dBCQualReportingCriteriaDLEcN0thres dBCQualReportingCriteriaDLTimetoTrigger dBCQualReportingCriteriaULEcN0Hysteresis dBCQualReportingCriteriaULEcN0thres dBCQualReportingCriteriaULTimetoTrigger dlFrequencyNumber e6eTimetoTrigger e6eTriggerEnabled e6eUePowerThresholddBm eAGCHpowerOffset eDCH2msActivation eDCHMACdFlowHARQPO eDCHMACdFlowMaxRet eDCHMACdFlowSIRstepThr{1,2,3}nbrOfConsecutive ZeroHARQReTxThreshold eDCHMACdFlowSIRstepThr{1,2,3}sIRstep{0,1,2,3,4} HARQReTx eDCHMACdFlowSIRstepThr{1,2,3}sIRstepConsecZe roHARQReTx eDCHMACdFlowSIRstepThr{1,2,3}sIRstepHfi
BsrBasedPilotPowerAdjustInterval indoorPenetrationLoss maxCoverageDistancem maxPilotPowerdBm MinBSRPowerdBm minPilotPowerdBm pAdjustmentStepdB pCPICHPowerIni TargetPilotEcIodB TargetPilotRSCPdBm UeBasedPilotPowerAdjustInterval
autoConfigPW autoConfigPW autoConfigPW autoConfigPW autoConfigPW autoConfigPW autoConfigPW autoConfigPW autoConfigPW autoConfigPW autoConfigPW
Hysteresis2d Hysteresis2f Threshold2d Threshold2f TimeToTrigger2d TimeToTrigger2f Hysteresis2d Hysteresis2f Threshold2d Threshold2f TimeToTrigger2d TimeToTrigger2f bSRIdentity hysteresis reportingInterval timetoTrigger cellIdentity
blindHO2d2fEcno blindHO2d2fEcno blindHO2d2fEcno blindHO2d2fEcno blindHO2d2fEcno blindHO2d2fEcno blindHO2d2fRscp blindHO2d2fRscp blindHO2d2fRscp blindHO2d2fRscp blindHO2d2fRscp blindHO2d2fRscp BSRneighbourCell bSRToBSRReportingCriteria1c bSRToBSRReportingCriteria1c bSRToBSRReportingCriteria1c FddExtCell
ecN0Hysteresis ecN0thres TimetoTrigger ecN0Hysteresis ecN0thres TimetoTrigger uARFCNDownlink
DBCQualReportingCriteriaDL DBCQualReportingCriteriaDL DBCQualReportingCriteriaDL DBCQualReportingCriteriaUL DBCQualReportingCriteriaUL DBCQualReportingCriteriaUL FddExtCell
nbrOfConsecutiveZeroHARQReTxT hreshold sIRstep{0,1,2,3,4}HARQReTx sIRstepConsecZeroHARQReTx sIRstepHfi
eDCHMACdFlowSIRstepThr{1,2,3} eDCHMACdFlowSIRstepThr{1,2,3} eDCHMACdFlowSIRstepThr{1,2,3} eDCHMACdFlowSIRstepThr{1,2,3}
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 156/158

eDCHmaxNoiseFloor eDCHminNoiseFloor eDCHreferencePowerOffset eDPCCHPowerOffset emergencyCallAlwaysRedirectFlag emergencyCallPreemptionEnabled emergencyCallRedirectNetwork enableHCS enableIncomingFemtoHandover enableNormalCallPreemption enableOutgoingFemtoHandover enableOwnPLMNHighPriority enableUMTSePLMN eRGCH2StepThreshold eRGCH3StepThreshold eRgchHichPowerOffset eTFCtable eventRecoverySteps eventRecoveryTimem fACHSigPower fddFreqBand femtoACLlist femtoACLlistGuest femtoGroupId femtoPSC femtoPSCListEnableFlag femtoPSCRangeLength femtoPSCReservedIndex femtoPSCStartRange freqBand freqBand fullnameofNetwork fullnameofNetwork2 gsmBCCHDecodeGuardTimer gsmCellListSIB11 gsmCellRSSIThreshold gsmCellSearchGuardTimer gsmFrequBand gsmListenerPicoBasedEnabled gsmListeningMode gsmListeningPeriodicTimer gsmMacroCellRsInfoEnableBroadcast gsmMacroCellRsInfohcsPrioN gsmMacroCellRsInfoMaxAllowedULTXPwr gsmMacroCellRsInfoqOffset1s gsmMacroCellRsInfoqRxLevMin gsmMeasurementPeriod gsmModuleInitGuardTimer happyBitDelay HardwareVersion hcsPrioN hcsPrioS hsdpaAndEdchTotalDLpower hSDPADynamicPowerEnabled hsdpaDynamicPwrHeadroom interBSRCellRsInfoenableBroadcast interBSRCellRsInfohcsPrioN interBSRCellRsInfomaxAllowedULTXPwr interBSRCellRsInfoqOffset1s interBSRCellRsInfoqOffset2s interBSRCellRsInfoqQualMin interBSRCellRsInfoqRxLevMin intrafrequencyFilterCoefficient isAutoNeigbourCellDetectionEnabled isAutoPscConfigEnabled locationAreaCode locationAreaCode macroCellEcNoThreshold macroCellListSIB11 macroCellMeasurementQuantity macroCellRSCPThreshold manualPscForFemto maxBSRPowerLimitdBm maxEdchUsersPerCell maximumAllowedULTXPower maxNumActiveEdchUsersPerCellForThr1 maxNumActiveEdchUsersPerCellForThr2 maxULNoiseRiseEdch mcc
EDCH EDCH ETFCS ETFCS LCell Lcell LCell Lcell BSR Profile BSR Profile BSR Profile Lcell Lcell ETFCS ETFCS EDCH ETFCS BSR Profile BSR Profile CCPower FddExtCell Femto Femto Femto femtoPSCList BSR Profile BSR Profile BSR Profile BSR Profile Lcell macroUMTSCellFrequencyList BSR Profile BSR Profile BSR Profile Lcell Lcell BSR Profile GSMExtCell BSR Profile GSMListener GSMListener Lcell Lcell Lcell Lcell Lcell BSR Profile GSMListener ETFCS DeviceInfo FddExtCell Lcell CCPower Femto CCPower Lcell BSR Profile Lcell Lcell Lcell Lcell Lcell Lcell BSR Profile Lcell FddExtCell GSMExtCell Lcell Lcell Lcell Lcell Lcell Lcell EDCH Lcell EDCHMACdFlow EDCHMACdFlow EDCH GSMListener::gsmMacroPLMN
bsrGroupId
BSR BSR BSR
enableBroadcast hcsPrioN MaxAllowedULTXPwr qOffset1s qRxLevMin
gsmMacroCellRsInfo gsmMacroCellRsInfo gsmMacroCellRsInfo gsmMacroCellRsInfo gsmMacroCellRsInfo
HardwareVersion
DeviceInfo
hSDPADynamicPowerEnabled enableBroadcast hcsPrioN maxAllowedULTXPwr qOffset1s qOffset2s qQualMin qRxLevMin
BSR interBSRCellRsInfo interBSRCellRsInfo interBSRCellRsInfo interBSRCellRsInfo interBSRCellRsInfo interBSRCellRsInfo interBSRCellRsInfo
lAC lAC
FddExtCell GSMExtCell
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 157/158

MCC minBlindHoGsmMacroRSSI minBlindHoUmtsMacroEcNo minBlindHoUmtsMacroRSCP minGSMDetectThreshold mnc MNC mobileCountryCode mobileCountryCode mobileNetworkCode mobileNetworkCode nCR neigbListMinRscp NetkListGuardConfigTimer nonHCSnCR nonHCStCRmax nonHCStCRmaxHyst numCellDCHUE ownPLMN pCHPower pcpichPower pCPICHPower penaltyTime periodicGSMCellCheck periodicMacroCellCheck pICHPower primaryScramblingCode prioritizeOwnPLMNoverRAT pSCHPower punctureLimit qHCSn qHCSs qOffset1 qOffset2 qQualMin qRxLevMin rAC redirectNetwork ReferenceETFC ReferenceETFCPowerOffset rNCID routingAreaCode rscpPscClashRealloc schedulingGrantPeriodicity schedulingNoGrantPeriodicity schedulingPowerOffset
Lcell::umtsMacroEPLMN Lcell Lcell Lcell Lcell GSMListener::gsmMacroPLMN Lcell::umtsMacroEPLMN FddExtCell GSMExtCell FddExtCell GSMExtCell Lcell BSR Profile BSR Profile Lcell Lcell Lcell LCell GSMListener::gsmMacroPLMN CCPower FddExtCell Lcell HcsCellRsInfo Lcell Lcell CCPower FddExtCell Lcell Lcell ETFCS HcsCellRsInfo Lcell HcsCellRsInfo HcsCellRsInfo Lcell Lcell GSMExtCell Lcell ETFCtable ETFCtable FddExtCell FddExtCell BSR Profile ETFCS ETFCS ETFCS
mCC mCC mNC mNC
FddExtCell GSMExtCell FddExtCell GSMExtCell
primaryCPICHTxPower
FddExtCell
primaryCPICHInfo
FddExtCell
rAC
FddExtCell
END OF DOCUMENT
BCR/IRC/APP/026964
02.02 / EN
Preliminary
31/March/2010
Page 158/158

Femto Parameter User Guide BCR02

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Femto Parameter User Guide BCR02

Hochgeladen von

Copyright:

Verfügbare Formate

Femto Parameter User Guide BCR2.

Copyright 2010 Alcatel-Lucent, All Rights Reserved Printed in France

Femto Parameter User Guide BCR2.2

Femto Parameter User Guide BCR2.2

Femto Parameter User Guide BCR2.2

DYNAMIC BEARER CONTROL ...................................................................................................40

Femto Parameter User Guide BCR2.2

Femto Parameter User Guide BCR2.2

SCOPE OF THE DOCUMENT

PM ID 34511 83236 81121 75888

Basic/Option Option Option Option Option

Release BCR02.02 BCR02.02 BCR02.02 BCR02.02

Table 1 - Hardware Feature

Femto Parameter User Guide BCR2.2

activateUserTone hSDPADynamicPowerEnabled activateEDCH isMpdpIBsupported enableUMTSePLMN LCell::emergencyCallPreemptionEnabled

BSR::activeCallRedirectEnabled BSR:: enableTransportCAC

Table 2 - RRM Features

34530 Handover BSR Femto to Macro 3G

34531 34535 34536 34537

Option Basic Basic Basic

BCR02.01 BCR02.01 BCR02.01 BCR02.01

Table 3 - Mobility Features

Femto Parameter User Guide BCR2.2

The parameters properties are presented as follow:

Parameter Object Granularity Range & Unit Class Value

Femto Parameter User Guide BCR2.2

The implementation process specific to FMS

Femto Parameter User Guide BCR2.2

ALCATEL-LUCENT REFERENCE DOCUMENTS

Femto Parameter User Guide BCR2.2

Figure 1 - BSR FMS Model

Femto Parameter User Guide BCR2.2

Femto Parameter User Guide BCR2.2

Parameter Object Granularity Range & Unit

Femto Parameter User Guide BCR2.2

PRIMARY SCRAMBLING CODE

4.2.1 MANUAL/AUTO-CONFIGURATION OF PSC

Parameter Object Granularity Range & Unit Class Value

manualPscForFemto Lcell BSR Profile Integer [0511] Class 3 0

4.2.2 AUTOMATIC AUTO-CONFIGURATION OF PSC

Femto Parameter User Guide BCR2.2

Parameter Object Granularity Range & Unit Class Value

femtoPSC femtoPSCList femtoPSCList Integer [0511] Class 3 '

Femto Parameter User Guide BCR2.2

Femto Parameter User Guide BCR2.2

4.3.1 CPICH POWER RANGE

Parameter Object Granularity Range & Unit Class Value

Parameter Object Granularity Range & Unit Class Value

Femto Parameter User Guide BCR2.2

4.3.2 CPICH POWER UPDATE BASED ON COVERAGE

Parameter Object Granularity Range & Unit Class Value

Femto Parameter User Guide BCR2.2

Parameter Object Granularity Range & Unit Class Value

Parameter Object Granularity Range & Unit Class Value

Femto Parameter User Guide BCR2.2

Femto Parameter User Guide BCR2.2

4.3.3 CPICH POWER UPDATE BASED ON UE RECEIVER RANGE

Parameter Object Granularity Range & Unit Class Value

Parameter Object Granularity Range & Unit

Femto Parameter User Guide BCR2.2

4.3.4 CPICH POWER UPDATE BASED ON UE MEASUREMENTS

Parameter Object Granularity Range & Unit Class Value

Femto Parameter User Guide BCR2.2