Nokia Siemens Networks

GSM/EDGE BSS, rel.
RG20(BSS), operating
documentation, issue 01
Feature description
BSS10046: Multi BCF Control
DN0176525
Issue 10-0
Approval Date 2010-08-04
2 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c446e
The information in this document is subject to change without notice and describes only the
product defined in the introduction of this documentation. This documentation is intended for the
use of Nokia Siemens Networks customers only for the purposes of the agreement under which
the document is submitted, and no part of it may be used, reproduced, modified or transmitted
in any form or means without the prior written permission of Nokia Siemens Networks. The
documentation has been prepared to be used by professional and properly trained personnel,
and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes
customer comments as part of the process of continuous development and improvement of the
documentation.
The information or statements given in this documentation concerning the suitability, capacity,
or performance of the mentioned hardware or software products are given "as is" and all liability
arising in connection with such hardware or software products shall be defined conclusively and
finally in a separate agreement between Nokia Siemens Networks and the customer. However,
Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions
contained in the document are adequate and free of material errors and omissions. Nokia
Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which
may not be covered by the document.
Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO
EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-
TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-
RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED
TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY
OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION
IN IT.
This documentation and the product it describes are considered protected by copyrights and
other intellectual property rights according to the applicable laws.
The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark
of Nokia Corporation. Siemens is a registered trademark of Siemens AG.
Other product names mentioned in this document may be trademarks of their respective
owners, and they are mentioned for identification purposes only.
Copyright © Nokia Siemens Networks 2010. All rights reserved
f Important Notice on Product Safety
Elevated voltages are inevitably present at specific points in this electrical equipment.
Some of the parts may also have elevated operating temperatures.
Non-observance of these conditions and the safety instructions can result in personal
injury or in property damage.
Therefore, only trained and qualified personnel may install and maintain the system.
The system complies with the standard EN 60950 / IEC 60950. All equipment connected
has to comply with the applicable safety standards.
The same text in German:
Wichtiger Hinweis zur Produktsicherheit
In elektrischen Anlagen stehen zwangsläufig bestimmte Teile der Geräte unter Span-
nung. Einige Teile können auch eine hohe Betriebstemperatur aufweisen.
Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Körperverlet-
zungen und Sachschäden führen.
Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die
Anlagen installiert und wartet.
Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene
Geräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.
DN0176525
Issue 10-0
3
BSS10046: Multi BCF Control
Id:0900d805807c446e
Table of Contents
This document has 53 pages.
Summary of changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1 Overview of Multi BCF Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 System impact of Multi BCF Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Impact on transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Impact on BSS performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Impact on Network Switching Subsystem (NSS) . . . . . . . . . . . . . . . . . . 15
2.6 Impact on NetAct products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.7 Impact on mobile stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.8 Impact on interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.9 Interworking with other features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.9.1 Interoperable features with Multi BCF . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.9.2 Restrictions with Multi BCF Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Segment configuration and state management . . . . . . . . . . . . . . . . . . . 24
4 Radio resource management and Multi BCF Control . . . . . . . . . . . . . . 27
5 Handover algorithm and Multi BCF Control . . . . . . . . . . . . . . . . . . . . . . 34
6 Expanding Talk-family cell with MetroSite or UltraSite BTSs. . . . . . . . . 44
7 Expanding UltraSite or Flexi EDGE cell . . . . . . . . . . . . . . . . . . . . . . . . . 47
8 Detaching a BTS from Multi BCF cell to a new segment . . . . . . . . . . . . 49
9 Moving a BTS to another existing segment . . . . . . . . . . . . . . . . . . . . . . 50
10 Restarting Multi BCF site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
11 Implementing Multi BCF overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
12 Testing Multi BCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c446e
List of Figures
Figure 1 Possible handover directions in a segment . . . . . . . . . . . . . . . . . . . . . . 20
Figure 2 Different interference levels with BSC recommendation 2 and without rec-
ommendation when searching for full-rate TCHs . . . . . . . . . . . . . . . . . . 31
DN0176525
Issue 10-0
5
BSS10046: Multi BCF Control
Id:0900d805807c446e
List of Tables
Table 1 Required additional or alternative hardware or firmware . . . . . . . . . . . . 9
Table 2 Required software by network elements . . . . . . . . . . . . . . . . . . . . . . . . . 9
Table 3 Impact on BSC units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Table 4 Counters of Handover Measurement related to Multi BCF Control . . . 13
Table 5 Counters of BSC Level Clear Code (PM) Measurement related to Multi
BCF Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c446e
DN0176525
Issue 10-0
7
BSS10046: Multi BCF Control Summary of changes
Id:0900d805807c435c
Summary of changes
Changes between document issues are cumulative. Therefore, the latest document
issue contains all changes made to previous issues.
Changes made between issues 10-0 and 9-1
BTSplus and Flexi Multiradio has been added in the BTS site type configuration in the
chapter Overview of Multi BCF Control
The chapter System impact of Multi BCF Control has been updated with BTSplus BTS
s/w release BRG2.
Changes made between issues 9-1 and 9-0
Information on InSite BTS has been removed.
Changes made between issues 9-0 and 8-1
The BSS number has been added to the title of the document.
NetAct Radio Access Configurator has been changed as NetAct Configurator.
In the chapter System Impact of Multi BCF Control, information on Wideband AMR has
been added.
Changes made between issues 8-1 and 8-0
In the chapter System impact of Multi BCF Control, a new note has been added under
the heading Impact on NetAct products.
Changes made between issues 8-0 and 7-1
The document has been merged with the GSM/EDGE BSS, Rel. BSS12, System Doc-
umentation, v.1 release document Multi BCF System Feature Description.
The following additions have been made in the document:
• The information in the chapter Overview of Multi BCF Control has been ckecked and
updated.
• The chapter System Impact of BCF Control has been added.
• Chapters Segment Environment, Requirements for Multi BCF Control, Technical
Description of Multi BCF Control, and User Interface of Multi BCF Control have been
removed as the information is already included in the new chapter System Impact of
BCF Control.
• Chapters Implementing Multi BCF, Expanding Talk-family Cell with MetroSite or
UltraSite BTSs, Expanding UltraSite or Flexi EDGE Cell, Detaching a BTS from Multi
BCF Cell to a New Segment, Moving a BTS to Another Existing Segment, Restarting
Multi BCF Site, and Testing Multi BCF have been added.
8 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c435a
Overview of Multi BCF Control
1 Overview of Multi BCF Control
Multi Base Station Control Function (BCF) allows combining resources of several
physical base stations into one logical cell. This enables operators to increase the
capacity of a cell, while maintaining maximum spectral efficiency. Multi BCF increases
the Talk-family and MetroSite BTS cell capacity to 24 TRXs, and the UltraSite and Flexi
EDGE BTS cell capacity to 36 TRXs, while requiring no extra Broadcast Control
Channel (BCCH).
Multi BCF Control also allows the gradual introduction of EDGE into the GSM networks.
EDGE can be implemented in the Talk-family cells by expanding them with the UltraSite
or Metrosite BTSs which have EDGE capable TRXs.
The Base Station Controller (BSC) supports the Multi BCF for Talk-family BTS, UltraSite
BTS, Flexi EDGE BTS, MetroSite BTS, Flexi Multiradio, and BTSplus. The BSC allows
up to 36 TRXs and 32 BTS objects in a segment.
The BSC allows the following BTS site type combinations in a Multi BCF cell:
• Talk-family + MetroSite (one MetroSite BCF can contain a maximum of three Met-
roSite BCFs in the chain)
• Talk-family + Talk-family (a maximum of six Talk-family BCFs in the chain)
• Talk-family + UltraSite (a maximum of five UltraSite BCFs in the chain)
• UltraSite + UltraSite (a maximum of nine UltraSite BCFs in the chain)
• UltraSite + Flexi EDGE (a maximum of nine BCFs in the chain; the chain can start
with a maximum of three UltraSite BCFs, followed by Flexi EDGE BCFs)
• Flexi EDGE + Flexi EDGE (a maximum of nine Flexi EDGE BCFs in the chain)
• Flexi Multiradio + Flexi Multiradio
• Flexi Multiradio + Flexi EDGE
• Flexi Multiradio + Ultrasite
• Flexi EDGE + BTSplus
• Flexi Multiradio + BTSplus
Related topics
System Impact of Multi BCF Control
Segment configuration and state management with Multi BCF Control
Radio resource management and Multi BCF Control
Handover algorithm and Multi BCF Control
Expanding Talk-family cell with MetroSite or UltraSite BTSs
Expanding UltraSite or Flexi EDGE cell
Detaching a BTS from Multi BCF cell to a new segment
Moving a BTS to another existing segment
Restarting Multi BCF site
Implementing Multi BCF
Testing Multi BCF
DN0176525
Issue 10-0
9
BSS10046: Multi BCF Control System impact of Multi BCF Control
Id:0900d805807c4471
2 System impact of Multi BCF Control
The system impact of Multi BCF Control is specified in the sections below. For an over-
view, see Overview of Multi BCF Control
For implementation instructions, see Implementing Multi BCF Control.
2.1 Requirements
Hardware requirements
Software requirements
Table Required software by network elements shows the earliest version that supports
Multi BCF Control.
Network element HW/FW required
BSC No requirements
BTS Talk-family BTS requires a
BCFB card and this is
possible with CityTalk and
IntraTalk cabinets only.
MSC/HLR No requirements
TCSM No requirements
SGSN No requirements
Table 1 Required additional or alternative hardware or firmware
Network element Software release
required
BSC S11
Flexi EDGE BTSs No requirements
Flexi Multiradio No requirement
BTSplus BTS BRG2
UltraSite EDGE
BTSs
CX3
MetroSite EDGE
BTSs
CXM4.0
Talk-family BTSs DF6 SW is applicable
with UltraSite and Met-
roSite.
MSC/HLR Not applicable
TCSM No requirements
SGSN Not applicable
NetAct OSS3.1 ED3
Table 2 Required software by network elements
10 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4471
System impact of Multi BCF Control
Frequency band support
The BSC supports Multi BCF Control on the following frequency bands:
• GSM 800
• GSM 900
• GSM 1800
• GSM 1900
2.2 Impact on transmission
No impact.
2.3 Impact on BSS performance
OMU signalling
No impact.
TRX signalling
No impact.
Impact on BSC
Impact on BTS units
No impact on BTS units.
2.4 User interface
BSC MMI
The following MML command groups and commands are used for handling Multi BCF
Control:
• Adjacent Cell Handling: EAC, EAM, EAO
• Base Station Controller Parameter Handling in BSC: EEQ, EEO
• Base Control function Handling: EFC, EFM, EFL, EFO
g Base Control Function Handling MML commands are related to BSS and Site
Synchronisation. For more information, see Activating and Testing BSS11073:
Recovery for BSS and Site Synchronisation and BSS20371: BSS Synchronisa-
tion Recovery Improvement.
• Handover Control Parameter Handling: EHC,EHN, EHO
• Base Transceiver Station Handling in BSC: EQC, EQG, EQO
BSC unit Impact
OMU No impact
MCMU No impact
BCSU No impact
PCU No impact
Table 3 Impact on BSC units
DN0176525
Issue 10-0
11
BSS10046: Multi BCF Control System impact of Multi BCF Control
Id:0900d805807c4471
• Power Control Parameter Handling: EUC, EUM, EUQ, EUS, EUB, EUO
BTS MMI
Multi BCF Control cannot be managed with BTS MMI.
BSC parameters
Some of the parameters are needed for the general handling of the segment environ-
ment and some particularly in handling the resources of different BTS site types in a
segment. The most important general parameters of the segment environment are the
segment identification and the segment name. These are available in all command
groups containing cell-specific parameters that are common to all the BTSs of a
segment.
Most of the parameters related to the Multi BCF Control are defined per segment object.
Parameters related to Multi BCF Control in Adjacent Cell Handling, Handover Control
Parameter Handling and Power Control Parameter Handling are all defined as common
values for the BTSs of one segment. In the Base Transceiver Station Handling
command group most of the parameters are segment level parameters, but there are
also BTS-specific parameters with the possibility to define separate values for different
BTS objects of a segment.
In the Base Transceiver Station Handling command group two BTS-specific parameters
have been introduced along with Multi BCF Control. non Bcch Layer Offset is for
estimating the signal level of the non-BCCH layer resources and BTS Load In SEG is
for controlling the traffic load in different BTSs of a segment.
The parameter non BCCH Layer Offset (NBL) is used to indicate how much weaker
the signal level of a BTS is when compared to that of the BCCH BTS. Because of this
the parameter must always be set to the value 0 in the BCCH BTS. A positive value of
NBL in a BTS indicates a signal level lower than in the BCCH BTS and prevents the
SDCCH allocation for call setups and external handovers in that BTS.
There are three groups of parameters that already existed before the multi BCF control
functionality and which have been preserved mainly as BTS-specific also in the segment
environment. These are parameters related to frequency hopping, HSCSD and GPRS.
The parameter RX lev min cell in the Adjacent Cell Handling command group is
used for the usability evaluation of the non-BCCH layer in a segment with resources
from different BTS site types during inter cell handovers.
In Base Station Controller Parameter Handling there is one parameter called intra
Segment SDCCH HO Guard for controlling the transfer of SDCCH reservations out of
the BCCH resource layer in the segments under the control of the BSC.
See BSS Radio Network Parameter Dictionary for the details of the parameters.
The following parameters are involved with Multi BCF Control:
Adjacent GSM cell (ADJC) radio network object parameters
• RX lev min cell
BSC radio network object parameters
• intra segment SDCCH HO guard
BTS radio network object parameters
• BTS load in SEG
• GPRS non BCCH layer rxlevel lower limit
12 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4471
System impact of Multi BCF Control
• GPRS non BCCH layer rxlevel upper limit
• non BCCH layer offset
SEG-specific BTS radio network object parameters
• direct GPRS access BTS
• rxlev access min
• SEG identification
• SEG name
Alarms
The segment object is invisible to the BSC alarm system. The alarms are focused on the
same radio network objects independently, whether the segment architecture is used or
not. All the cell and BTS-specific alarms are given per BTS object also in the segment
environment.
With the alarms that focus on the cell object the alarm is given via the BCCH BTS of a
multi BTS segment. The BSC generates an alarm BCCH MISSING (7767) only for the
BTSs having a BCCH configured. The congestion supervision for an alarm CH CON-
GESTION IN BTS ABOVE DEFINED THRESHOLD (7746) is made in the BCCH BTS
concerning the whole segment. A possible alarm on congestion, even if it is identified
with the BCCH BTS, describes the congestion level of the whole segment.
The supervision for an alarm CH CONGESTION IN BTS ABOVE DEFINED THRESH-
OLD is based on the relation between the received and rejected resource requests in a
cell. It is a general view of the cell's capability to serve mobile subscribers in its coverage
area.
In a multi BCF segment the rejection of a service request does not necessarily mean
that all the segment's resources are occupied. Because of the different properties of dif-
ferent base station site types the resources that are applicable for individual resource
requests can vary case by case. A rejection in a segment means that all the resources
that could be applied for a request at that moment are occupied. Depending on the case
this can mean all the resources of a segment or only part of them. In any case the con-
gestion supervision gives a good idea of how the supply meets the demand for radio
channel resources in a cell.
For more information, see Base Station Alarms (7000–7999)
Measurements and counters
The basic structure of statistics is maintained with Multi BCF Control. Measurements
that have been collected per BTS before the introduction of the segment concept are
BTS-specific also in the segment environment. NetAct offers you the possibility to have
segment-specific statistics based on the BTS-specific measurements.
Introduction of the segment concept and the possibility to have several BTS objects in
one cell causes changes in how the data of some cell level activities is collected and how
the BTS-specific counters are interpreted in the segment environment.
Handover Measurement counters are used to separate the intra-cell handovers in which
calls move from one BTS to another from the ones in which calls only change channels
within a BTS.
Handover Measurement
DN0176525
Issue 10-0
13
BSS10046: Multi BCF Control System impact of Multi BCF Control
Id:0900d805807c4471
In the Handover Measurement as well as in all other measurements collecting statistics
on handovers, the counters that have been describing intra-cell handovers inside a BTS
are in segment environment showing the handovers inside a segment. These include
handovers both between a segment's BTSs and within single BTSs. On the other hand,
the counters of inter cell handovers that used to give information on all handovers
between BTSs of a BSC are in a segment environment collecting information on han-
dovers that take place between BTSs of different segments.
BSC Level Clear Code (PM) Measurement and Multi BCF Control
Following the established practice with the handover attempt causes and the related
Handover Measurement counters there are also success counters in the BSC Level
Clear Code (PM) Measurement. The following two counters are related to the inter band
handover attempts that are indicated by the Handover Measurement counters 004137
and 004139.
• INTRA INTER BTS TYPE SDCCH HANDOVER (051148)
The number of completed and successful SDCCH-SDCCH handovers started
based on the duration of an SDCCH reservation between different BTS types within
a segment.
• INTRA INTER BTS TYPE TCH HANDOVER (051147)
The number of completed and successful TCH-TCH handovers that have been
made within a segment between different BTS types based on source BTS load.
Traffic Measurement and Multi BCF Control
Name Number
INTRA CELL SUCCESS SDCCH HO BETWEEN BTSS 004131
INTRA CELL SUCCESS TCH HO BETWEEN BTSS 004132
HO ATTEMPT INTER BTS TYPE SDCCH 004137
INTRA CELL SUCCESS SDCCH HO BETWEEN BTS TYPES 004138
HO ATTEMPT INTER BTS TYPE TCH 004139
INTRA CELL SUCCESS TCH HO BETWEEN BTS TYPES 004140
SUCCESSFUL HO INTER BTS TYPE TCH 004160
UNSUCCESSFUL HO INTER BTS TYPE TCH 004162
INTER SEGMENT SUCCESS SDCCH HO BETWEEN BTS
TYPES
004167
INTER SEGMENT SUCCESS TCH HO BETWEEN BTS TYPES 004169
Table 4 Counters of Handover Measurement related to Multi BCF Control
Name Number
INTRA INTER BTS TYPE TCH HANDOVER 051147
INTRA INTER BTS TYPE SDCCH HANDOVER 051148
Table 5 Counters of BSC Level Clear Code (PM) Measurement related to Multi
BCF Control
14 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4471
System impact of Multi BCF Control
When a BTS-specific statistical counter is updated in a procedure in which an entire
segment is the target for the attempt, the respective attempt counter is updated for the
BCCH BTS of the segment. In Traffic Measurement this means that all incoming channel
allocation attempts are included in the statistics of the BCCH BTS of the target segment.
If an allocation attempt is not successful, the rejection for the resource request is
updated according to the applicable resources in each particular case. Whenever the
MS could accept a channel of a Talk-family BTS, the resource request rejection is
updated for a BTS of that type, if there is one.
In an unsuccessful channel allocation attempt for an internal inter-cell handover the
attempt and the resource request rejection are updated in the first segment of the
handover candidate list. When the channel allocation succeeds, the success is updated
in a counter of the BTS where the channel was allocated. In this case the attempt
counter is updated for the BCCH BTS of the selected segment.
General counters
In an intra-cell handover between BTSs inside a segment the handover attempt counter
is updated for the source BTS of the handover. This enables gathering information on
the origin of intra-cell handovers with the counters that were defined before the segment
concept was introduced. When the intra-cell handover fails the failure of the handover
is also updated for the source BTS of the handover. In the successful case the update
of the success counter is made for the BTS where the channel is allocated from.
On the target side of an inter-cell handover with only one candidate cell the BSC updates
the appropriate attempt counter for the BCCH BTS of the target segment. If the BSC is
unable to allocate a channel for the handover it also updates the failure for the BCCH
BTS of the target segment. In a successful case the BSC updates the appropriate
success counter for the BTS in which the allocation has been made.In addition if the
handover fails after the channel for the handover has been allocated, the failure is
updated for the selected target BTS.
In inter-cell handovers with several candidate cells and in external handovers between
BSCs the object for the handover counter update on the target side varies depending on
the success of channel allocation. If the BSC is able to allocate a channel for the
handover the counter updates on the target side are made for the BTS where the
channel has been allocated from. In an unsuccessful channel allocation case the
counters are updated for the BCCH BTS of the first SEG on the target cell list of the han-
dover.
Multi BCF control-specific counters
Multi BCF control-specific counters include attempt counters that are updated for the
source BTS of a handover. Other counters for segment environment mainly collect infor-
mation on made handovers of certain types and are updated at the target BTS of the
intra segment handover.
The following two counters are related to the segment environment in general and
collect information on the number of intra-SEG handovers between BTSs. They are
needed whenever there are segments with several BTSs. The counters report how
many of the intra-segment handovers take place between different BTSs. The rest of the
intra-cell handovers are inside single BTSs.
• INTRA CELL SUCCESS SDCCH HO BETWEEN BTSS (004131)
Indicates the number of completed and successful SDCCH-SDCCH handovers
between two BTSs of the segment.
DN0176525
Issue 10-0
15
BSS10046: Multi BCF Control System impact of Multi BCF Control
Id:0900d805807c4471
• INTRA CELL SUCCESS TCH HO BETWEEN BTSS (004132)
Indicates the number of completed and successful TCH-TCH handovers between
BTSs of the segment.
The following counters are related to Multi BCF Control. The first counter indicates the
number of attempts where the BSC has tried to initiate an SDCCH handover from a BTS.
• HO ATTEMPT INTER BTS TYPE SDCCH (004137)
Indicates the number of times the BSC has, based on the duration of an SDCCH res-
ervation, attempted an SDCCH handover between different BTS types.
The following three counters collect information about intra-segment TCH handovers
between different BTS types which the BSC initiates due to load.
• HO ATTEMPT INTER BTS TYPE TCH (004139)
Indicates the number of attempts to perform a TCH-TCH handover due to load
reasons between different BTS types in a segment.
• SUCCESSFUL HO INTER BTS TYPE TCH (004160)
Indicates the number of successful and completed TCH - TCH handovers between
different BTS types of a segment due to load.
• UNSUCCESSFUL HO INTER BTS TYPE TCH (004162)
Indicates the number of unsuccessful TCH - TCH handovers between different BTS
types of a segment due to load.
The following two counters indicate the number of handovers between BTS site types
of a segment.
• INTRA CELL SUCCESS SDCCH HO BETWEEN BTS TYPES (004138)
Indicates the number of all SDCCH handovers that have been made from a BTS of
one base station site type to a BTS of another type in a segment.
• INTRA CELL SUCCESS TCH HO BETWEEN BTS TYPES (004140)
Indicates the number of all TCH handovers that have been made from a BTS of one
base station site type to a BTS of another type in a segment.
The following two counters collect information on the number of inter-segment han-
dovers between different BTS types. The counters report how many of the inter-
segment handovers take place between different BTS types.
• INTER SEGMENT SUCCESS SDCCH HO BETWEEN BTS TYPES (004167)
Indicates the number of completed and successful SDCCH - SDCCH handovers
between two different types of BTSs between two segments.
• INTER SEGMENT SUCCESS TCH HO BETWEEN BTS TYPES (004169)
Indicates the number of completed and successful TCH - TCH handovers between
two different types of BTSs between two segments.
NetAct
The following parameters are in use in the NetAct:
• The BSC parameter intra segment SDCCH HO guard.
• The BTS parameters SEG identification, SEG name, non BCCH layer
offset and BTS load in SEG.
For an overview, see Overview of Multi BCF Control.
2.5 Impact on Network Switching Subsystem (NSS)
No impact.
16 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4471
System impact of Multi BCF Control
2.6 Impact on NetAct products
NetAct Configurator
NetAct Configurator provides network-wide access and tools for Multi BCF configura-
tion. In the BSC, the Multi BCF management is handled via segment. In RAC, the
segment management is done using a master BTS definition. With segment reconfigu-
ration, it is possible to change the master BTS by deleting the existing master BTS or
by moving the master BTS to another segment.
g MML-based segment reconfiguration causes an inconsistency between the NetAct
Configurator and BSC databases. To remove the inconsistency, use the Configura-
tor CM Operations Manager to upload the configuration from the BSC to the Config-
urator after the reconfiguration.
For instructions on how to maintain sites that support Multi BCF Control using NetAct,
see Maintaining Multi-BCF Sites in NetAct Product Documentation.
NetAct Reporter
Reporting for Multi BCF Control is done by common NetAct reporting tools. Network
Doctor uses segment as a measurement object. The BTS level is still applicable in some
cases, but it is replaced in many cases by segment:
• presenting raw counters or KPIs result in segment ID level instead of BTS level with
ReportBuilder
• defining the object (for example, segment ID and BTS) aggregation method on top
of the time aggregation formula in the Formula wizard with ReportBuilder
• selecting the segment ID as hierarchy and as summary level in the dimension selec-
tion for report properties
NetAct Monitor
Standard NetAct monitoring applications are used for the monitoring of Multi BCF
Control. All alarms are available for NetAct monitoring tools.
NetAct Tracing
No impact.
NetAct Administrator
NetAct Administrator offers full support to Multi BCF Control administrative tasks, for
example:
• fast download and activation of Multi BCF Control software to BTSs via NetAct tools
• expandable software archives
• storage for multiple software configurations
NetAct Planner
NetAct Planner includes a set of radio network and planning features for Multi BCF
Control. This allows the visibility of Multi BCF Control in radio network planning. Plans
can be completed with Radio Access Configurator.
NetAct Optimizer
Optimizer supports Multi BCF Control. Internally, Optimizer creates Cell objects based
on segment ID and Master BTS flag information. In the geographical map view, Multi
BCF cells (segments) are visible entirely; non-segment BTSs are available as earlier.
DN0176525
Issue 10-0
17
BSS10046: Multi BCF Control System impact of Multi BCF Control
Id:0900d805807c4471
Two views are available in the topology view: cell (segment) view and common object
model view (BSC-BCF-BTS). The Adjacency, Power Control and HandOver Control
objects are linked to the master BTS of the segment.
2.7 Impact on mobile stations
No requirements for mobile stations.
2.8 Impact on interfaces
Without Multi BCF Control, there is a separate the BSSGP virtual connection BVC for
each individual BTS in the Gb interface. With Multi BCF Control, the GPRS traffic of all
(E)GPRS-capable BTSs in the same segment is directed through one BVC.
2.9 Interworking with other features
2.9.1 Interoperable features with Multi BCF
Adaptive Multirate (AMR)
Decisions on the need for packing AMR FR (full rate) calls to AMR HR (half rate) calls
is based on the load situation of each individual BTS also in the segment environment.
AMR FR calls in a particular BTS are packed depending on the load of that individual
BTS. Furthermore, the intra-cell handovers that perform the actual packing of calls are
implemented as BTS internal events. When an intra-segment TCH handover is made in
order to decrease the load of a BTS, the number of the possible requests for AMR FR
call packing in the BTS is decreased in order to avoid unnecessary handovers.
Advanced Multilayer Handling (AMH)
The BSC-controlled traffic reason handover is a segment-level procedure.
Common BCCH
When Multi BCF Control and Common BCCH are combined you are allowed to config-
ure both BTSs of different frequency bands and BTSs of different base station types to
one segment.
Direct Access to Desired Layer/Band (DADL/B)
In the segment environment, DADL/B can be used to direct traffic between segments.
Everything related to DADL/B concerns a segment instead of a BTS. The loads are eval-
uated per segment, adjacency definitions are between segments and DADL/B han-
dovers are made between segments.
For more information, see Direct Access to Desired Layer/Band .
Directed Retry
The Directed Retry or the Intelligent Directed Retry procedure can be triggered even if
all the resources of a segment are not completely in use. The triggering of the procedure
requires that all the resources that an accessing MS could use under the current condi-
tions are unavailable.
For more information, see Directed Retry Procedure in BSC.
18 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4471
System impact of Multi BCF Control
Dynamic Frequency and Channel Allocation (DFCA)
Dynamic Frequency and Channel Allocation is used for dynamically assigning the
optimum radio channel for a new connection. DFCA uses interference estimations
derived from mobile station downlink (DL) measurement reports and combines them
with the timeslot and frequency usage information.
To have a comprehensive view of the radio environment for DFCA, the BSC collects
long-term statistical data on how different cells using DFCA generate interference to
each other in the network. This segment-specific data is collected by the Background
Interference Matrix (BIM) update process. The segment-level C/I definition of the BIM
update process does not take into account the differences between the segment's
BTSs, when these are of different base station site types.
DFCA is able to handle different circuit-switched traffic classes ((E)FR, HR, AMR FR,
AMR HR, 14.4 kbit/s data) individually, and it provides the operator with the means to
differentiate between users. When DFCA and Multi BCF Control are used together,
access to the DFCA resources can be controlled separately for each BTS of the
segment with the advanced methods that DFCA offers.
For more information, see BSS11052: Dynamic Frequency and Channel Allocation
(DFCA).
Dynamic SDCCH allocation
The dynamic reconfiguration of the SDCCH radio time slots is possible only in those
BTSs of a Multi BCF segment which have a negative value or value zero in the param-
eter non BCCH layer offset and are, thus, indicated to have a signal level at least
as strong as in the BCCH BTS.
Extended Cell and Multi BCF Control
In the segment environment, only a BCCH BTS can have extended area TRXs.
For more information, see Extended Cell.
FACCH call setup
In FACCH call setup, the SDCCH phase is skipped and the call is put directly to a TCH
channel. At that time, the measurement reports from the accessing MS are not available.
Therefore, the usability of the non-BCCH layer resources based on those reports cannot
be defined.
In Multi BCF Control, the FACCH setup is possible only in those BTSs of a Multi BCF
segment which have a negative value or value zero in the parameter non BCCH layer
offset and are, thus, indicated to have a signal level at least as strong as in the BCCH
BTS.
Frequency Hopping
In the segment architecture, the resources of different base station types are grouped
as separate BTSs. Frequency Hopping is managed by a BTS. All the different BTSs in
a segment have their own hopping parameters and hopping groups.
The segment architecture enables having BTSs without a BCCH TRX. This reduces the
number of hopping groups in a BTS's regular area, because there is no need for a
separate group for the BCCH TRX in RF hopping. In BB hopping, there is no need for
separating TSL0 from the other TSLs in BTSs that do not contain a BCCH TRX.
However, the separation between TSL0 and other TSLs remains and these are
regarded as two different hopping groups. The operator gives one set of parameters for
DN0176525
Issue 10-0
19
BSS10046: Multi BCF Control System impact of Multi BCF Control
Id:0900d805807c4471
the TSL0 group and another for the other TSLs. A similar set of parameters can be given
for both.
The segment model offers the opportunity to have several hopping groups even though
there are only resources for one type in a segment. The operator can form hopping
groups by gathering the needed TRXs into one BTS and have several BTSs of the same
type.
For more information, see BSS7005: Frequency Hopping.
GPRS
When comparing the TCH load of a segment's BTS with the parameter BTS load in
SEG, the BSC interprets RTSLs in GPRS territory as busy channels (excluding dedi-
cated GPRS resources). This interpretation prevents the GPRS territory of a single BTS
from shrinking unnecessarily, if there are other BTSs in the segment to which CS calls
could be transferred from the BTS in question.
The interactions between the circuit-switched radio resource management of a segment
and GPRS are described in the section Radio resource management and Multi BCF
Control of Multi BCF Control.
For the effects of the segment concept on the radio resource management of the packet-
switched services in the PCU, see BSS09006: GPRS System Feature Description.
Every GPRS BTS in a segment has to be connected to the same PCU.
High Speed Circuit Switched Data (HSCSD)
From the point of view of HSCSD, the effects of the segment structure appear mainly
when allocating TCHs for HSCSD requests. The basic principles that apply for the TCH
allocation in general are also valid in HSCSD cases. This means that the HSCSD
resource allocation is made considering the radio conditions and the loads on different
resource types.
Among the resource types that the BSC defines as reasonable, the TCH search is per-
formed in a way that the HSCSD channel configuration which best fulfils the request is
selected. Within a segment, the HSCSD allocation is made in a BTS that has no restric-
tions based on the HSCSD load parameters rather than in a BTS where the allocation
is restricted to include only one TCH.
The operator can control the HSCSD traffic load between a segment's BTSs by using
the BTS-specific HSCSD load parameters min HSCSD capacity cell, upper
limit cell load HSCSD, lower limit cell load HSCSD and upper limit
regular load HSCSD.
If necessary, one HSCSD downgrade per segment per received request is made in the
segment environment. When the received request leads to TCH allocation, the need for
an HSCSD downgrade is examined in the BTS of the allocation. If a free TCH cannot be
found, the candidate for the HSCSD downgrade is selected among the segment's BTSs
that are defined as appropriate targets for the request. A round robin method is used to
direct separate downgrade attempts to different BTSs in a segment. In each BTS, the
downgrade decision is based on the HSCSD parameters of the particular BTS.
For more information, see BSS7003 and BSS7037: HSCSD and 14.4 kbit/s Data
Services in BSC .
20 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4471
System impact of Multi BCF Control
Handover Support for Coverage Enhancement (HSCE)
Handover Support for Coverage Enhancement can be used in the BCCH BTS of the
Multi BCF segment.
Enhanced Coverage by Frequency Hopping (ECFH)
Enhanced Coverage by Frequency Hopping can be used in the BCCH BTS of the Multi
BCF segment.
Intelligent Underlay-Overlay (IUO)
In the segment environment, the use of Intelligent Underlay-Overlay is BTS-specific.
Each BTS in a segment can have its own regular and super-reuse layers. The super-
reuse layer of a BTS can only be accessed via the regular layer of the BTS.
The target for a super-reuse TCH request is always one BTS (a few TRXs within the
BTS) and not the whole segment as in resource requests in general. The handover pro-
cedure from regular resources to super-reuse resources in a BTS is the same whether
the segment architecture is used or not.
When an IUO handover from a super-reuse TRX to regular BTS resources is performed,
the information on the usability of different resource types in the segment is decided
based on the values of the parameter non BCCH layer offset in different BTSs of
the segment. As a target the BSC accepts the BTSs that have non BCCH layer
offset parameter value less than, or equal to, the value of the BTS where the
handover was initiated. This is indicated in the figure Possible handover directions in a
segment with dash line arrows from the super-reuse layer of one BTS to the regular
layer of another BTS in a segment.
The child cell concept is not supported in a BSC in which the segment option is enabled.
Direct access to super-reuse resources is possible in segments consisting of only one
BTS, and is not supported in segments with more than one BTS.
Figure 1 Possible handover directions in a segment
For more information, see Intelligent Underlay-Overlay.
BTS1
Regular area
Super-reuse area
BTS2
Regular area
Super-reuse area
DN0176525
Issue 10-0
21
BSS10046: Multi BCF Control System impact of Multi BCF Control
Id:0900d805807c4471
MSC-controlled traffic reason handover
The MSC-controlled traffic reason handover (TRHO) and the related resource indica-
tions are segment-level procedures.
In the spontaneous resource indication method, the segment-level parameter BTS
load threshold is used when defining the need to send the resource indication.
Pre-emption
When the segment architecture is used, Pre-emption is a segment-level function.
In a segment with several BTSs of different properties it is possible that a TCH request
cannot be served even though all the TCH resources in a segment are not fully used.
However, pre-emption is possible, if permitted by the related parameters.
The candidate for the forced actions is selected among the resource types that are indi-
cated as reasonable in the resource request that initiates these actions. In the candidate
selection, the criterion of the lowest possible priority is the most important one. When
searching for the lowest priority call the different resource types are scanned in a
reverse order than in TCH allocation.
The maximum number of possible calls in a pre-emption queue is eight.
For more information, see Radio Resource Pre-Emption and Queuing.
Queueing
When the segment architecture is used, the queueing for traffic channels is a segment-
level procedure including related parameters.
In a segment with several BTSs of different properties it is possible that a TCH request
cannot be served even though all the TCH resources in a segment are not fully used.
However, queueing can be started if permitted by the related parameters.
The maximum number of possible calls in a queue is 32 when the segment architecture
is in use.
For more information, see Radio Resource Pre-emption and Queuing.
Radio network supervision
The congestion supervision for alarm 7746 CH CONGESTION IN CELL ABOVE
DEFINED THRESHOLD is monitored on the segment level since the target for a channel
request is a segment. In a segment with several BTSs, the channel congestion supervi-
sion is made in the BCCH BTS for the whole segment. A possible alarm on congestion,
even if it is identified with the BCCH BTS, describes the congestion level of the whole
segment.
For more information, see Radio Network Supervision in BSC.
Recovery for BSS and Site Synchronisation and BSS Synchronisation Recovery
Improvement
Recovery for BSS and Site Synchronisation and BSS Synchronisation Recovery
Improvement offers synchronisation recovery for a Multi BCF site and the possibility to
define the Multi BCF chain configuration to a BSC's radio network database. If Recovery
for BSS and Site Synchronisation is activated for Flexi EDGE/UltraSite/MetroSite/Talk-
family BTS chain, all BCF sites in the chain are restarted automatically, if necessary,
when the master clock BCF is restarted. BSS Synchronisation Recovery Improvement
applies only for Flexi EDGE and UltraSite BTSs.
22 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4471
System impact of Multi BCF Control
For more information, see Activating and Testing BSS11073: Recovery for BSS and Site
Synchronisation and BSS20371: BSS Synchronisation Recovery Improvement and
BSS Synchronisation.
RX level based TCH access control
By default, the BSC determines the usability of TCH resources of a Multi BCF segment
on a BTS site type basis. As an alternative method, the BSC can perform a special RX
level based TCH resource usability evaluation if so indicated with the BSC radio network
object parameter RX level based TCH access. When the RX level based TCH
access control is applied, the usability of TCH resources in a segment can be deter-
mined on a BTS basis. For more information on the RX level based TCH access control
method, see Radio Channel Allocation.
Trunk Reservation
The control of Trunk Reservation is on the segment level.
For more information, see Trunk Reservation.
Wideband AMR
When Wideband AMR is enabled in a BSC and is set as the most preferred codec type,
the BSC selects the channel primarily from an AMR-WB-capable BTS and TRX.
For more information, see BSS20960: Wideband AMR and BSS21118: Tandem Free
Operation for AMR.
2.9.2 Restrictions with Multi BCF Control
The use of Multi BCF Control and the segment environment causes restrictions for the
functionality of the following application and operating software.
BCCH TRX recovery
The BCCH channel is recovered only inside a BTS radio network object. In a BCCH TRX
fault situation the BCCH is not reconfigured from one BTS to another BTS. The new
BCCH TRX has to be found from the same BTS radio network object.
Cell broadcast
User gives definitions for the BCCH BTS only.
Extended cell range
In the segment environment, only the BCCH BTS can have extended area TRXs.
Handover Support for Coverage Enhancement (HSCE)
Handover Support for Coverage Enhancement can be used only in the BCCH BTS of
the Multi BCF segment.
Low power TRXs cannot be in a BTS that does not have a BCCH TRX.
Enhanced Coverage by Frequency Hopping (ECFH)
Enhanced Coverage by Frequency Hopping can be used only in the BCCH BTS of the
Multi BCF segment.
Low power TRXs cannot be in a BTS that does not have a BCCH TRX.
DN0176525
Issue 10-0
23
BSS10046: Multi BCF Control System impact of Multi BCF Control
Id:0900d805807c4471
Intelligent Underlay-Overlay (IUO)
The super-reuse layer of a BTS in a segment with several BTSs can be accessed only
via the regular layer of the BTS. Direct access to the super-reuse resources is not sup-
ported in segments with more than one BTS.
The child cell concept is not supported when the segment architecture is used.
Multi BCF site reset by user
Recovery for BSS and Site Synchronisation and BSS Synchronisation Recovery
Improvement enable you to define the synchronisation chain configuration to the BSC
radio network database. If the synchronisation chain is not defined and enabled, Multi
BCF restart is only possible with a series of BCF site reset MML commands (instead of
a single command).
SDCCH allocation
With Multi BCF Control, the extent of the SDCCH search in the initial SDCCH allocation
for the call setup and SDCCH allocation for the external handover depends on the
values of the non BCCH layer offset parameters in BTSs other than the BCCH
BTS. If the value of the parameter in the BTS is positive, the channel is not allocated
from that BTS.
Dynamic SDCCH allocation
With Multi BCF Control, the same restrictions that apply in initial SDCCH allocation for
call setup are also valid for the dynamic SDCCH feature. The BSC does not configure a
TCH-TSL for dynamic SDCCH use in a BTS in which the non BCCH layer offset
parameter has a value greater than zero.
TCH allocation
With Multi BCF Control, the extent of the TCH search in both the FACCH setup and
external handover depend on the values of the non BCCH layer offset parameters
in BTSs other than the BCCH BTS. If the value of the parameter in the BTS is positive,
the channel is not allocated from that BTS.
PGSM-EGSM900 BTS
When the BCCH TRX frequency is of the type PGSM900 and an EGSM900 frequency
is being used in the same BCCH BTS, the GSM900 band frequencies can only be used
in the BCCH BTS of the Multi BCF segment. For more information about using the
PGSM900 and EGSM900 frequencies in the same BTS, see PGSM900-EGSM900 BTS
in BSC.
24 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4473
Segment configuration and state management
3 Segment configuration and state manage-
ment
The BSC software update to support the segment concept allows the system to auto-
matically convert cells to segments. In practice, the BSC adds new segment identifica-
tion information for each cell by copying the BTS identification data of the cell to the
respective segment parameters.
Despite the introduction of the segment object the BTS object remains as the basic
element in the radio network configuration and state management in the BSC.
BTS creation in segment environment
Create BTSs in the segment environment in the same way as without the segment
object, but with the additional possibility to give segment identification (parameter SEG
or SEGNAME) in the create command. Thus, in the BTS create command indicate the
segment that the BTS belongs to. If you do not give any segment identification the
system creates a one-BTS segment and copies the segment identification from the
given BTS. Also, when you give a segment identification and there is not a segment with
the given identification, the system creates a new segment with the given BTS as its
contents. As a new segment is created you have the possibility to give both segment
and BTS-level parameters with the create command.
When you give a BTS create command with an identification of an existing segment, the
system adds the BTS as a new BTS into the given segment. In this case give only the
BTS-specific parameters in the command.
If a reference BTS is given in the BTS create command, there are two ways of function-
ing depending on whether the first or an additional BTS to a segment is created. If you
create the first BTS of a segment then both the BTS-specific and the segment-specific
parameters related to the reference BTS are copied to the new BTS. If only an additional
BTS is to be created to a segment then only the BTS-specific parameters are copied
from the reference BTS. Thus, creating of a new BTS in a segment does not change the
parameters that are common to all BTSs of the segment.
For the segment identification (SEG or SEGNAME) the same value ranges and restric-
tions apply as for the BTS identification.
The BSC allows up to 36 TRXs and 32 BTS objects in a segment.
Moving BTSs between segments
The U command in the Base Transceiver Station Handling in BSC command group is
used for changing the segment of a BTS and thus moving a BTS from one segment to
another. For the command the user gives at least the identification of the moved BTS
and of the target segment. The target segment can either be an existing one, or a new
segment that is created as a result of the command.
When moving a BTS between existing segments no other parameters are required in
addition to the BTS identification and the target segment identification. If the moved BTS
is the only BTS in the original segment, that segment is removed as a result of the
command. In that case the procedure can be seen as the combining of two segments.
Moving a BTS into a non-existent segment creates the segment into the network. This
requires that all the obligatory segment level parameters are given in the command. This
procedure can be regarded as splitting of the original segment. If there are no other
DN0176525
Issue 10-0
25
BSS10046: Multi BCF Control Segment configuration and state management
Id:0900d805807c4473
BTSs than the one to be moved in the original segment, creating a new segment is not
possible.
The BCCH BTS of a segment cannot be moved to another segment. In order to enable
the combining of segments, the BCCH channels of the BTS have to be removed before
the moving operation.
All BTSs of the source segment and the destination segment have to be locked when
the moving command is used. GPRS has to be disabled both at the source segment and
at the target segment during the BTS moving operation.
State management in segment environment
The state management of a segment is performed through the BTS object. The segment
object has neither operational nor administrative state. When locking of a segment is
needed, for example, when you want to modify a segment level parameter that requires
locking, you have to lock the BTSs of the segment one by one.
When locking the whole segment the BCCH-BTS of the segment must be locked first.
This is of essential importance especially when the segment is locked using the forced
handover procedure. The shutting down of the segment's BTSs in the BCCH-BTS
prevents the calls from being handed over to other BTSs of the segment. Handovers to
other segments are performed instead. When the BCCH BTS is working and a non-
BCCH BTS of a segment is shut down with forced handover, the calls of the non-BCCH
BTS can be transferred to other BTSs of the segment as well.
In the state transition command scenario where you change the state of all the BTSs
from LOCKED to UNLOCKED the BCCH BTS must be handled first. The system checks
that the BCCH TRX is working when the state transition command is given for a non-
BCCH BTS of a segment.
Parameter management in segment environment
In the segment environment, where individual cells can have several BTSs, the user has
the possibility to modify parameters both through the segment object and through the
BTS object.
In Base Transceiver Station Handling there are both BTS-specific and segment-specific
parameters. Give either a segment identification (parameter SEG or SEGNAME) or a
BTS identification (parameter BTS or NAME) in a command depending on whether you
want to modify a BTS-specific parameter or a parameter common to all BTSs of the
segment. Only one of the identification parameters SEG, SEGNAME, BTS and NAME
is allowed in one command. If a segment contains only one BTS you can manage all the
parameters of the command group either through the segment or the BTS object.
By giving a BTS identification in the parameter output command of the Base Transceiver
Station Handling command group you can have output of the parameters of the given
BTS. If the BTS is the only BTS of the segment, the segment-specific parameters are
also displayed. By giving a segment identification in the output command the user gets
a display of the segment level parameters of the command group.
In Adjacent Cell Handling where all the parameters are cell-specific you can identify the
object of a command either with parameter BTS, NAME, SEG or SEGNAME if there is
only one BTS in the segment to be modified. In a segment having several BTSs a
segment identification must be given. For the identification of an adjacent cell the alter-
native parameters ABTS, ANAME, LAC+CI, ASEG, and ASEGNAME are available.
ABTS and ANAME cannot be used for an adjacent cell of several BTSs.
26 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4473
Segment configuration and state management
In the Handover Control Parameter Handling and Power Control Parameter Handling
command groups all parameters related to the Multi BCF Control are on segment level.
In a segment of a single BTS, the parameter command groups are controlled by using
BTS and segment level identification method (BTS, NAME, SEG, or SEGNAME). In a
segment of several BTS objects the parameter SEG or SEGNAME must be used. For
the identification of a possible reference object, the user can give one of the parameters
REF, RNAME, RSEG, and RSEGNAME if both the target segment of the command and
the reference segment contain only one BTS, otherwise RSEG or RSEGNAME must be
used.
Recovery
The recovery operations during a failure on the TRX carrying the BCCH timeslot are per-
formed inside the BCCH BTS also in the segment environment. A working TRX is
searched for within the BCCH BTS in order to reconfigure the BCCH timeslot to that
TRX.
If the Recovery for BSS and Site Synchronisation is activated in the Multi BCF segment
and the first BCF is a clock source for the chain and the first BCF is restarted, all BCFs
in Multi BCF cell are restarted. If the Recovery for BSS and Site Synchronisation
software is activated and the slave BCF loses the incoming synchronisation signal the
BSC changes the slave BCF to blocked operational state and sets the synchronisation
mode to 'UNSYNCH'. Furthermore, when the slave BCF regains the incoming signal,
the BSC automatically restarts the slave BCF(s) to work in a synchronised mode.
For an overview, see Overview of Multi BCF Control.
DN0176525
Issue 10-0
27
BSS10046: Multi BCF Control Radio resource management and Multi BCF Control
Id:0900d805807c4357
4 Radio resource management and Multi BCF
Control
SDCCH allocation in segment environment
SDCCHs are allocated for signalling purposes, immediate assignments, intra-BSC han-
dovers and inter-BSC handovers. The selection of SDCCH in all these situations is
made by the channel allocation algorithm in BSC.
SDCCH allocation from a segment consisting of BTSs of different BTS types is based
on the usability of the radio resources. The usability of the radio resources of BTSs of
different BTS types for the accessing MS is defined by either the handover algorithm or
the channel allocation algorithm in BSC.
Selection of BTSs in Multi BCF Segment
Immediate Assignment
If in a segment consisting of BTSs of different BTS types the BCCH carrier has been
configured to the type of BTS which has better link budget than the other type of BTSs,
the SDCCH can be allocated only among the BCCH BTS type of BTSs. This is because
the BSC has no information based on which the usability of the radio resources of BTSs
of different BTS types than BCCH BTS type could be defined. That is, the MS has not
sent any measurement reports yet.
If the BCCH carrier of the segment has been configured to the type of BTS which has
worse link budget than the other type of BTSs it is safe to use resources of both types
of BTSs for immediate assignment.
The channel allocation algorithm in the BSC verifies the usability of a BTS for initial
SDCCH allocation from a BTS-specific parameter non BCCH layer offset. The sign
of the parameter value indicates if the link budget of the BTS is better or worse than that
of the BCCH BTS of the segment.
Intra-BSC handover
In intra-BSC handover the channel allocation algorithm receives the information about
the usability of radio resources in different BTS types from the handover algorithm.
Based on this information the channel allocation algorithm selects the BTSs of that type
from the segment as targets of SDCCH selection.
Inter-BSC handover
If the target cell in inter-BSC handover is a segment that has the BCCH carrier config-
ured to the type of BTS which has better link budget than the other type of BTSs, the
SDCCH can be allocated only among the BCCH BTS type of BTSs. This is because the
BSC has no information based on which the usability of the radio resources of BTSs of
different BTS types than BCCH BTS type could be defined.
If the BCCH carrier of the target cell has been configured to the type of BTS which has
worse link budget than the other type of BTSs, it is safe to use resources of both types
of BTSs for inter-BSC handover.
The channel allocation algorithm in the BSC verifies the usability of a BTS for inter-BSC
handover from a BTS-specific parameter non BCCH layer offset.The sign of the
parameter value indicates if the link budget of the BTS is better or worse than that of the
BCCH BTS of the segment.
28 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4357
Radio resource management and Multi BCF Control
Selection of TRX, RTSL and channel
After selecting the BTSs from which the SDCCH can be allocated, the channel allocation
algorithm makes the selection of TRX, RTSL and channel. The principles of selecting
the TRX, RTSL and channel are described below:
The channel allocation algorithm divides the BTSs into groups according to their types.
• BTSs of the same type as BCCH BTS form one group
• BTSs of a type other than BCCH BTS form one group
The channel allocation algorithm calculates the SDCCH load of each BTS group. In
SDCCH load calculation only the static SDCCH resources are taken into account.
If there are idle static SDCCH resources in some group in TRX/RTSL/channel selection
the load of the group is the most decisive factor. The channel is allocated from the BTS
group, which has the lowest load. The TRX/RTSL/channel selection from the TRXs of
the selected BTS group is made according to the following principles:
The channel allocation algorithm selects a suitable (TRX, RTSL) pair by using the TRX-
specific resource information. If possible, the pair to be selected is not the last seized
pair.
There are two methods for selecting (TRX, RTSL) pair among static SDCCH resources
depending on the hopping method and TRX prioritisation in the cell.
The method used in RF hopping BTSs with RF hopping TRX prioritisation:
• In the first phase all SDCCH TRXs except BCCH TRX are examined up to the
starting TRX. The TRX that has the least channel load (busy traffic and signalling
channels) is selected.
• Within the selected TRX the RTSL which has the most idle SDCCH channels left is
selected. However, if a signalling channel was last allocated from the same TRX,
another RTSL than last time is allocated, if possible. An SDCCH channel from a
BCCH TRX is allocated only if there are no idle SDCCHs at all in other TRXs.
The method used in cells without RF hopping or without RF hopping TRX prioritisation:
• In the first phase all SDCCH TRXs are examined up to the starting TRX. The TRX
that has the least channel load (busy traffic and signalling channels) is selected.
• Within the selected TRX the RTSL which has most idle SDCCH channels left is
selected. However, if a signalling channel was last allocated from the same TRX, a
different RTSL is allocated this time, if possible.
If there are no idle static SDCCH resources in the BTSs, the dynamic SDCCH resources
are searched for. All the TRXs in every BTS group including free dynamic SDCCH
resources are examined. From the TRXs the RTSL which has the least idle dynamic
SDCCH channels is selected.
If there are no idle static or dynamic SDCCH resources in the BTSs then an idle TCH
timeslot is configured as a new temporary SDCCH resource. Dynamic SDCCH recon-
figuration is applied only in immediate assignment phase, not in handovers. For more
information, see Radio Channel Allocation.
After the channel allocation algorithm has found a suitable (TRX, RTSL) pair, it allocates
the next free SDCCH subchannel from the RTSL.
In the case of an intra-BTS handover the SDCCH allocation differs from the basic pro-
cedure. If the TRX where the call is maintained is not currently blocked, the search pro-
cedure differs from the basic one in the following ways:
DN0176525
Issue 10-0
29
BSS10046: Multi BCF Control Radio resource management and Multi BCF Control
Id:0900d805807c4357
• the search procedure is started only if a different SDCCH RTSL than the serving one
is defined in the BTS
• the call-serving TRX is accepted only if other TRXs containing free SDCCH
channels are not available
• a channel in the call-serving RTSL is never selected
If the call-serving TRX is blocked, the basic search procedure is used.
TCH allocation in segment environment
The basic difference between the TCH allocation in a multi BCF segment and in a single
BTS cell is that the target of a TCH request in a segment is a set of BTSs instead of a
single BTS. Also in a BSC internal inter-cell handover the target cell list contains
segments instead of BTSs.
For the TCH allocation algorithm the segment concept brings some issues to be taken
into account when selecting a free TCH resource for a service request, such as the loads
of the BTSs and the possibility of separate interference recommendations for different
BTS site types. All existing rules for selecting a TCH in a single BTS cell (see Radio
channel allocation) are valid also between BTSs in a segment cell.
RX level based TCH resource usability evaluation
The channel allocation algorithm can perform the RX level based TCH resource usability
evaluation depending on the value of the parameter RX level based TCH access.
If the RX level based TCH access method is in use the resource usability information set
by the handover algorithm is bypassed. If the value of the parameter RX level based
TCH access is 1, the RX level based TCH access method is used in call setup. If the
value of the parameter is 2, the RX level based TCH access method is used both in call
setup and handovers. For more information, see Radio Channel Allocation.
When the RX level based TCH access method is applied the usability of resources can
be determined on a BTS basis. Whereas if the resource usability evaluation set by the
handover algorithm is used, the resource usability can be determined only on a BTS site
type basis.
This description introduces a method in which usability of different BTS site types is
based on information set by the handover algorithm.
Search of a single slot TCH and Multi BCF Control
The BSC starts the TCH search procedure by selecting the BTSs to be examined
according to the acceptable BTS site types in the prevailing radio conditions. In call
setup and BSC internal handover the allowed base station types are defined based on
the measurement result of the BCCH layer of the target segment. For the non-BCCH
layer resource usability decision a signal level estimate is used. The estimate is derived
from the BCCH layer measurement with the BTS-specific non BCCH layer offset
parameter. This estimate is further compared to a threshold parameter. In call setup and
intra-cell handover the threshold parameter is rxlev access min, while in inter-cell
handover the parameter is RX lev min cell.
In a BSC external handover the usability of the non-BCCH resource type in the target
segment is concluded by comparing the values of the non BCCH layer offset
parameter in the BCCH BTS and in the non-BCCH layer BTS with each other. If the
value of the parameter in the non-BCCH layer BTS is less than or equal to that in the
BCCH BTS of the segment the BTS is included in the TCH search procedure.
30 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4357
Radio resource management and Multi BCF Control
After the applicable base station site types have been defined, the selection between
the remaining candidate BTSs is made by the BSC according to the following criteria
and order:
1. Load of a BTS according to parameter BTS load in SEG
2. The interference band of an idle channel, TRX prioritisation in TCH allocation and
the channel type
3. The circuit switched territory load of a BTS
4. Round robin of the BTSs
Load of a BTS is based on load conditions in the BTS and on the parameter BTS load
in SEG of each BTS. The principle is to keep the load of a BTS within the limit defined
by the parameter BTS load in SEG. For channel search the BSC divides the BTSs
to different load groups:
1. BTSs with load under BTS load in SEG
2. BTSs with load between BTS load in SEG and the highest BTS load in SEG
value of the segment
3. BTSs with load above the highest BTS load in SEG value of the segment
The primary target for the allocation is the first group. After the load limit for some BTS
has been reached, the BSC aborts the TCH allocation to that BTS, if possible, until the
load limits also in all other BTSs have been reached. The equal filling continues in all
those BTSs where the load limit has not yet been reached.
Finally, when each BTS has reached its load limit the allocation continues in the BTSs
where the load is less than the highest load threshold value among the BTSs. The load
in these BTSs is increased so that gradually the load in every BTS approaches the
highest limit value among the BTSs. This takes place until in all the BTSs the load is at
least on the level of the highest load threshold value among the BTSs. After that the pref-
erence between the BTSs of different BTS site types is:
1. Talk-family BTS
2. MetroSite BTS
3. UltraSite BTS/ Flexi EDGE BTS
The different BTS types have different resource cababilities, which should be taken into
account when deciding the preference between BTSs. For instance, an UltraSite BTS
has a 2 dB better link budget than a Talk-family BTS and thus a Talk-family BTS is used
rather than an UltraSite BTS when the preference between BTSs cannot be decided
based on other criteria. This is done in order to save the better UltraSite resources for
MSS on the cell border.
Applying the rules above, either one or more BTSs can be defined as the primary target
group for TCH allocation. The next thing to be examined within these BTSs is the
possible interference level recommendations and the respective interference levels of
idle channels. For a BTS, for which the BSC has defined a recommendation of the
acceptable interference, the TCHs on the acceptable levels are ranked as the best
choices for allocation by values starting from 1. But also in BTSs, for which no recom-
mendation is present, the levels are ranked so that the best possible level (0) has the
ranking value 1. The following table gives an example of the ranking of different interfer-
ence bands with and without interference level recommendation.
DN0176525
Issue 10-0
31
BSS10046: Multi BCF Control Radio resource management and Multi BCF Control
Id:0900d805807c4357
Figure 2 Different interference levels with BSC recommendation 2 and without rec-
ommendation when searching for full-rate TCHs
If there are still several candidate BTSs after applying the TRX prioritisation in TCH allo-
cation (see the section TRX prioritisation in TCH allocation), or when no prioritisation is
defined, the final selection between BTSs is made according to the circuit switched ter-
ritory load in them. The BSC selects the one with the lowest load using the round robin
method so that the BTS that was allocated the previous time is the last choice.
TRX prioritisation in TCH allocation
The possibility to favour or avoid the BCCH TRX in call assigning is maintained in the
segment environment to some extent. This is examined after the BTSs have been
compared based on their loads and their respective load parameters.
In segment environment there can be both BTSs with and BTSs without BSC defined
interference level recommendation in a TCH request. If the recommendation is present
for the BCCH BTS and the BCCH TRX is preferred in TCH allocation and also if the allo-
cation can be made in the BCCH TRX according to the recommendation (interference
less or equal to recommendation), it will also be made there. If this is not possible a TCH
ranked as the best according to its interference level is allocated among the BTSs that
were defined as best targets based on their loads.
If the BCCH TRX is preferred in TCH allocation but no recommendation is present for
the BCCH BTS, a TCH ranked as the best according to its interference level is allocated
among the target BTSs. If a TCH with the selected interference level is found in the
BCCH TRX it is the primary choice. Also in cases where the non-BCCH TRXs are pre-
ferred, the allocation is primarily made according to the interference level ranking and
secondarily according to the defined TRX prioritisation.
Combined usage of Multi BCF Control and Common BCCH Control
When Multi BCF Control is used together with Common BCCH Control, the number of
BTS types that has to be taken into account in TCH search, is increased.
The non-BCCH frequency band is preferred to BCCH frequency band. An extension to
this general rule is needed when there are three frequencies (PGSM900, EGSM900
and GSM1800) in use in a segment. The preference between the two non-BCCH fre-
quency layers is made in the following way:
1. If BCCH is on PGSM900 frequency band then GSM1800 is preferred to EGSM900
2. If BCCH is on GSM1800 frequency band then EGSM900 is preferred to PGSM900
GPRS
Interference
level
Interference level
recommendation 2
No interference level
recommendation
0
1
2
3
4
3
2
1
11
12
8
7
6
13
14
1
2
3
4
5
6
7
8
9
10
Permanent
full rate
Dual rate
full rate
Permanent
full rate
Dual rate
full rate
32 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4357
Radio resource management and Multi BCF Control
GPRS is a BTS-specific software in a segment environment and thus there are indepen-
dent GPRS territories in the BTSs. In TCH search the actions on GPRS territories are
avoided if possible. This means that a TCH for a circuit switched service is not allocated
in the GPRS territory of a BTS if there is an available TCH in the CS territory of another
BTS in the segment. Also, TCH allocation in a BTS where it would cause a GPRS terri-
tory downgrade based on the defined safety margins, is skipped if there is another can-
didate where the allocation can be made in the CS territory without any effect on the
GPRS territory.
When all the CS resources that the MS can utilise in the whole segment are busy, the
channel is allocated in the GPRS territory taking into account the following criteria and
in order:
1. GPRS territory type according to PCU recommendation
2. Load according to parameter BTS load in SEG
3. Dedicated GPRS territory size
4. Default GPRS territory size
When there are both EGPRS and GPRS territories in use in a segment, the PCU is
aware of the usage and loads of different type of GPRS territories and recommends
usage of the one with lower load.
For the load comparison with the BTS load in SEG parameter the GPRS channels
are handled as occupied channels. If the load of the BTS is above the highest BTS load
in SEG value of the segment and the highest BTS load in SEG is under 100% then
in the TCH search a Talk-family BTS is preferred to an UltraSite BTS.
If there are still several candidates after having selected between GPRS and EGPRS
and after having compared loads of the chosen type of BTSs, the selection is made
according to the GPRS territory size of different BTSs. In this case the BTS with the
smallest dedicated GPRS territory and after that the smallest default GPRS territory is
chosen. This is done because it is reasonable to save some larger territories for GPRS
rather than several smaller ones. For more information, see (E)GPRS in BSC.
Multi slot allocation and Multi BCF Control
In multislot allocation for High Speed Circuit Switched Data (HSCSD) call requests for
multiple TCH/Fs in a TRX can be allocated. HSCSD call configurations of up to four
TCH/Fs are possible. In this allocation method the applied principles somewhat differ
from those in single slot allocation, but basically the same segment-specific rules are
valid as in a single slot TCH allocation. This means that the HSCSD resource allocation
is made considering the radio conditions and the loads of different resource types.
In order for the control of HSCSD to be efficient, the HSCSD load parameters are on the
BTS level. This also means a better way of controlling the HSCSD traffic load between
BTSs of a segment.
HSCSD search in segment environment is performed by the BSC using the following
segment-specific rules:
1. HSCSD allocation is made in a BTS that has no restrictions based on the HSCSD
load parameters rather than in a BTS where the allocation is restricted to include
only one TCH.
2. Among the resource types that the BSC defines as reasonable the TCH search will
be performed in a way that an HSCSD channel configuration fulfilling the request
best is selected.
DN0176525
Issue 10-0
33
BSS10046: Multi BCF Control Radio resource management and Multi BCF Control
Id:0900d805807c4357
3. Load according to BTS load in SEG (see Search of a single slot TCH and Multi
BCF Control).
4. If there are both BTSs with and BTSs without the BSC interference band recommen-
dation the ranking of the BTSs is:
• A TSL gap without any interference in a BTS that has no interference band rec-
ommendation and a TSL gap within the recommendation in a BTS where the
interference band recommendation is present are both ranked as the best
choices.
• A secondary choice is a TSL gap with some interference in a BTS without inter-
ference band recommendation set by the BSC.
• The last choice is a TSL gap that does not meet the interference band recom-
mendation set by the BSC.
5. The circuit switched territory load of a BTS.
6. Round robin method of the BTSs.
For an overview, see Overview of Multi BCF Control.
34 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4355
Handover algorithm and Multi BCF Control
5 Handover algorithm and Multi BCF Control
SDCCH resource usability evaluation in Multi BCF Control
Intra-cell SDCCH handover
In cases where the BSC starts an intra SEG SDCCH handover due to a traditional cri-
terion, the usability of different resource types in the segment is evaluated according to
the reported downlink signal level and the non BCCH layer offset parameters of
different BTSs in the segment. The used formula for the usability is:
RXLEV_DL - non BCCH layer offset>= rxlev access min
If the MS is on an SDCCH in a BTS that is of another BTS site type than the BCCH BTS,
the RXLEV_DL is replaced by an estimate that is achieved by adding up the serving
SDCCH measurement result and the non BCCH layer offset value of the BTS.
Internal inter-cell SDCCH handover
When the BSC has defined a need for an inter-cell handover based on the measure-
ments of the serving SDCCH channel, the usability of the different resource types of
each candidate segment are decided using the BCCH measurement results for the
segment and the values of the parameter non BCCH layer offset for different
resource types in the segment according to the criterion:
AV_RXLEV_NCELL(n) - non BCCH layer offset(n)(res_type)>= RX lev min
cell(n)
RX lev min cell(n) is the level which the signal level in the adjacent segment must
exceed in order for the handover to the adjacent segment to become possible.
External SDCCH handover
If the BCCH of the target segment in a handover between two BSCs is in an UltraSite
BTS the SDCCH allocation at the target side is limited to the UltraSite resources of the
segment. This is because the radio link measurements with which the usability of the
possible Talk-family resources are defined are not available on the target side of the
handover. On the other hand, if the BCCH of the target segment is in a Talk-family BTS
also UltraSite resources are applicable for external handover in addition to the BCCH
resource type resources because of the wider coverage of the UltraSite resources.
TCH resource usability evaluation in Multi BCF Control
The algorithm performing the TCH resource usability evaluation is dependent on the
value of the parameter RX level based TCH access. The handover algorithm
performs the TCH resource usability evaluation during call setup only when the param-
eter RX level based TCH access has the value 0. When the value of the parameter
is 1 the TCH resource usability evaluation is made by the handover algorithm in
handover cases. If RX level based TCH access has the value 2 the handover algo-
rithm does not make a TCH resource usability evaluation in any case. In those cases
the evaluation is performed by the channel allocation algorithm.
Call setup
When the BSC has received a measurement report on the SDCCH, it defines the usabil-
ity of possible other site type BTSs of the segment for the MS in the current circum-
stances. In this definition procedure the BSC uses the BTS-specific parameter non
BCCH layer offsetto get an estimation of the other resource type than BCCH layer
based on measurements made on BCCH layer. The estimate is compared to a segment
level parameter rxlev access min. If the condition
DN0176525
Issue 10-0
35
BSS10046: Multi BCF Control Handover algorithm and Multi BCF Control
Id:0900d805807c4355
RXLEV_DL - non BCCH layer offset>= rxlev access min
is fulfilled, the use of other resource type than BCCH TCH resources is reasonable.
Intra-cell TCH handover
In cases where the BSC starts an intra-SEG TCH handover due to a traditional criterion,
the usability of different resource types in the segment are evaluated according to the
reported downlink signal level and the non BCCH layer offset parameters of dif-
ferent BTSs in the segment. The used formula for the usability is
RXLEV_DL - non BCCH layer offset>=rxlev access min
If the MS is on a TCH in a BTS that is of another BTS site type than the BCCH BTS, the
RXLEV_DL is replaced by an estimate that is achieved by adding up the serving TCH
measurement result and the non BCCH layer offset value of the BTS.
Internal inter-cell TCH handover
When the BSC has defined a need for an inter-cell handover based on the measure-
ments of the serving TCH channel, the usability of the different resource types of each
candidate segment are decided using the BCCH measurement results for the segment
and the values of parameter non BCCH layer offset for different resource types in
the segment. The resulted level is compared to an existing threshold parameter RX
lev min cell(n):
AV_RXLEV_NCELL(n) - non BCCH layer offset(n)(res_type)>= RX lev min
cell(n).
RX lev min cell(n)is the level which the signal level in the adjacent segment must
exceed in order for the handover to the adjacent segment to become possible.
External TCH handover
If the BCCH of the target segment in a handover between two BSCs is in an UltraSite
BTS the TCH allocation at the target side is limited among the UltraSite resources of the
segment. This is because the radio link measurements with which the usability of the
possible Talk-family resources are defined are not available on the target side of the
handover. On the other hand, if the BCCH of the target segment is in a Talk-Family BTS,
also UltraSite resources are applicable for external handover in addition to the BCCH
resource type resources because of the wider coverage of the UltraSite resources.
Delayed call setup in Multi BCF segment
To improve the usability of the resources in a secondary BTS type during call setup a
delay has been implemented in the BSC. The delay ensures that a valid measurement
report from the MS is available for the BSC during call setup to evaluate the usability of
the resources of a secondary type of the cell.
If there are resources of a secondary type in a segment, the BSC delays its call setup
procedure to wait for a valid measurement report from the MS. If a valid measurement
report is received before the delay period ends the call setup proceeds immediately. If
a valid measurement report is not received during the delay the resources of a second-
ary type cannot be used during call setup.
The length of the delay can be adjusted by changing the value of the UTPFIL parameter.
The UTPFIL parameter defines how many SACCH multiframe periods the BSC is
allowed to wait for a valid measurement report. The default value of the parameter is 3
and the value range is 1…4.
36 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4355
Handover algorithm and Multi BCF Control
☞ The averaging of radio link measurements in the BTS decreases the probability of
the BSC to receive a valid measurement report in time and thus diminishes the
usability resources of a secondary type during call setup. Therefore, it is recom-
mended to deny the measurement averaging in a Multi BCF cell by having the
parameter BTS measure average (BMA) its default value 1.
SDCCH handover based on reservation duration and Multi BCF Control
Because of the possibility for long lasting SDCCH reservations, an intra-segment inter-
BTS handover is implemented. This reduces the SDCCH pressure on the primary
resource layer.
The need for an intra segment SDCCH handover out of the initial resource layer is
defined on the basis of the length of an SDCCH reservation and on the configuration of
the segment.
If the timer set according to IntraSegSdcchHoGuard for an MS expires (or irrespec-
tive of the timer if IntraSegSdcchHoGuard=0) the BSC defines the usability of the
Talk-family type resources for the MS. The used criterion is
RXLEV_DL - non BCCH layer offset>= rxlev access min
If the BSC concludes that the MS could use the Talk-family BTSs in addition to the Ultra-
Site BCCH BTS type, it starts an intra-segment handover attempt.
In case the intra-segment SDCCH handover fails, interval-timer for intra-segment
SDCCH handovers is set. Interval time is adjusted by the handover parameter min int
between unsucc HO attempt. The interval timer also affects the load-based TCH
handovers in the segment.
Load based TCH handover and Multi BCF Control
With Multi BCF the reason for the segment's TCH load imbalance between BTSs is due
to the bad quality of an MS entering a Talk-family BTS during call setup or handover.
The BSC initiates an intra-SEG handover between different BTS types of the segment
when the load exceeds the set load threshold in the source BTS. The handover initiated
by the BSC due to load reasons is used when there are two different BTS types in the
segment.
If a call cannot be directed to the Talk-family layer of a segment initially in the call setup
or in a handover from another cell, the BSC can later initiate a handover to balance the
load between different resource types. The BSC bases the decision on the need for bal-
ancing the load on the BTS level parameter BTS load in SEG.
BTS load in SEG is used as such in deciding if a new call is allowed to enter a BTS.
When deciding on initiating a handover to balance the load between BTSs of a segment,
the triggering load limit L is defined with the following formula:
L = BTS load in SEG+ ((100 - BTS load in SEG)/2).
Thus, the limit for triggering the load-based handover in a BTS is higher than the limit
based on which the BTS can be avoided in TCH allocation. The limit for triggering the
handover is in the middle between the value of BTS load in SEG and 100%.
Separating the load limit that controls the access to a BTS inside a segment from the
one that triggers the load based handover to another BTS is necessary in order to avoid
a situation where most of the incoming calls enter the segment via a TCH of the BCCH
layer.
DN0176525
Issue 10-0
37
BSS10046: Multi BCF Control Handover algorithm and Multi BCF Control
Id:0900d805807c4355
The BSC checks the load of each BTS of the segment every time it receives a TCH
request for the segment in question. When the BSC selects target BTSs for the load-
based intra-cell handover it accepts as target only BTSs whose load is below the respec-
tive BTS load in SEG value.
The BSC searches for a HO candidate in the given BTS that could be handed over to
the selected target BTS. It uses the formula
RXLEV_DL - non BCCH layer offset>= rxlev access min.
RXLEV_DL is the terminal's reported signal level on the current TCH. This is decreased
by the BTS-specific offset. The resulting estimate is then compared to an existing
threshold parameter rxlev access min.
If the BSC finds an appropriate candidate for the intra-SEG handover, it starts a
handover attempt. Then the procedure continues as described for intra-cell handovers.
Power budget handover and Multi BCF Control
In a Multi BCF case when there are BTSs of different types in a segment, the PBGT
(power budget) calculation depends on the serving BTS.
When a call is in the BCCH resource type, the standard PBGT calculation is applied.
When the call is using the non-BCCH resource layer and the used BTS type is Talk-
Family, the serving TCH measurement is summed up with the non BCCH layer
offset value of the current BTS. The obtained value represents an estimate of the
BCCH resource layer and is subjected to the averaging process and used in the normal
PBGT calculation.
PBGT = (MS txpwr max gsm(BTS) - (AV_RXLEV_DL_HO + non BCCH layer
offset) - (BsTxPwrMax - BS_TXPWR)) - (MS TX pwr max gsm(ADJ)(n) -
AV_RXLEV_NCELL(n))
When the non-BCCH resource layer of the segment is of the UltraSite type, the received
serving TCH measurement can be used as such in the PBGT calculation process.
IUO handover and Multi BCF Control
Each BTS in a segment can have its own regular and super-reuse layers. The super-
reuse layer of a BTS can be accessed only via the regular layer of the BTS.
The direct access to the super-reuse resources is possible in segments consisting of
only one BTS. The direct access to the super-reuse resources is not supported in
segments with more than one BTS. The child cell concept is not supported when the
segment option is in use.
Channel allocation criteria based on the minimum acceptable C/N ratio
When the traffic channel allocation criteria based on the minimum acceptable Car-
rier/Noise (C/N) ratio are employed, the BSC ensures that
• the uplink signal coming from the MS can overcome the uplink interference
• the uplink interference level on the TCH to be allocated is not unnecessarily low
when compared to the uplink signal level
The channel allocation criteria based on the minimum acceptable C/N ratio are con-
trolled by the parameter C/N threshold administered on a BTS-by-BTS basis in a
segment by O & M. C/N threshold gives a recommendation on the minimum accept-
able C/N ratio when a timeslot to be allocated in a call or in a handover attempt is
selected. The range is from 1 dB to 63 dB.
38 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4355
Handover algorithm and Multi BCF Control
If the value of the parameter C/N threshold varies between the BTSs of the same
resource type, the BSC selects the highest value for the calculation. The recommenda-
tion for a certain resource type in the segment is disabled when the value is 'not used'
even in one of the BTSs of the same resource type.
Maximum acceptable interference level
The BSC first calculates the maximum acceptable interference level MAX_INTF_LEV
for each existing resource type in the segment. It is calculated in the following ways
depending on the handover type and whether the software "Optimisation of the MS
power level in handover and call setup" is used:
1. Call setup and intra-cell HO; optimisation of the MS power level in call setup and in
intra-cell HO is not employed:
MAX_INTF_LEV=RXLEV_UL+(MS txpwr max gsm1x00(BTS)-
MS_TXPWR)-C/N threshold
RXLEV_UL+(MS txpwr max gsm(BTS)-
MS_TXPWR)-C/N threshold
if serving BTS is GSM 800 or GSM 900
MAX_INTF_LEV=
if serving BTS is GSM 1800 or GSM 1900
RXLEV_UL is the current uplink signal level and it is measured during the initial sig-
nalling period of call setup or just before the handover attempt. MS txpwr max
gsm(BTS)-MS_TXPWR or MS txpwr max gsm1x00(BTS)-MS_TXPWR depend-
ing on a frequency band is the difference between the maximum RF power that an
MS is permitted to use on a channel in the segment and the actual transmitting
power of the mobile station.
2. Call setup and intra-cell HO; optimisation of the MS power level in call setup and in
intra-cell HO is employed:
MAX_INTF_LEV=
MAX(MIN(RXLEV_UL+(MS txpwr max gsm(BTS)-
MS_TXPWR),
optimum RX level uplink),
RXLEV_UL-(MS_TXPWR-MsTxPwrMin))
-C/N threshold
if serving BTS is GSM 800 or GSM 900
MAX_INTF_LEV=
MAX(MIN(RXLEV_UL+(MS txpwr max gsm1x00(BTS)-
MS_TXPWR),
optimum RX level uplink),
RXLEV_UL-(MS_TXPWR-MsTxPwrMin))-
C/N threshold
if serving BTS is GSM 1800 or GSM 1900
MS_TXPWR-MsTxPwrMin is the difference between the actual transmitting power
of the mobile station and the minimum RF power that an MS is permitted to use on
a channel in a certain resource type BTS. The parameter optimum RX level
uplink indicates the optimum uplink RF signal level which both ensures adequate
speech/data quality and does not cause uplink interference.
If the value of the parameter optimum RX level uplink varies between the
TRXs of the BTSs of the same resource type, the BSC selects the highest value for
the calculation. The optimum uplink RF signal level for a certain resource type in the
segment is disabled when the value is 'not used' even in one of the TRXs of the
BTSs of the same resource type. If the value of the parameter MsTxPwrMin varies
DN0176525
Issue 10-0
39
BSS10046: Multi BCF Control Handover algorithm and Multi BCF Control
Id:0900d805807c4355
between the BTSs of the same resource type, the BSC selects the greatest value
for the calculation.
3. Inter-cell handover; optimisation of the MS power level in handover is not employed:
MAX_INTF_LEV=AV_RXLEV_NCELL(n)—
non BCCH layer offset(n)—
RX level balance-C/N threshold(n)
AV_RXLEV_NCELL(n) is the averaged downlink signal level of the target (adjacent)
segment (n). The parameter RX level balance indicates the difference between
the uplink signal level and the downlink signal level within the BSC coverage area.
The range is from 0 dB to 20 dB and, for example, the value 5 dB indicates that the
downlink signal is 5 dB stronger than the uplink signal. The parameter is set for the
BSC. The parameter non BCCH layer offset (n) indicates the estimated dif-
ference between the signal levels of the BCCH layer and the non-BCCH layer
resource in the target segment (n).
4. Inter-cell handover; optimisation of the MS power level in handover is employed:
MAX_INTF_LEV=
MAX(MIN(AV_RXLEV_NCELL(n)—
non BCCH layer offset (n)-
RX level balance,MS pwr opt level(n)+
non BCCH layer offset(n)-RX level balance),
(AV_RXLEV_NCELL(n)—non BCCH layer offset(n)-
RX level balance)-
(MS txpwr max gsm(BTS)(n)-
MsTxPwrMin(n)))-C/N threshold(n)
if calculation is performed for GSM 800 or GSM 900 target segment.
MAX_INTF_LEV=
MAX(MIN(AV_RXLEV_NCELL(n)—
non BCCH layer offset (n)-
RX level balance,MS pwr opt level(n)+
non BCCH layer offset(n)-RX level balance),
(AV_RXLEV_NCELL(n)—non BCCH layer offset(n)-
RX level balance)-
(MS txpwr max gsm1x00(BTS)(n)-MsTxPwrMin(n)))
-C/N threshold(n)
if calculation is performed for GSM 1800 or GSM 1900 target segment.
MS txpwr max gsm(BTS)(n)-MsTxPwrMin(n)or MS txpwr max
gsm1x00(BTS)(n) -MsTxPwrMin(n) depending on the frequency band is the
difference between the maximum and minimum RF power that an MS is permitted
to use on a certain resource type traffic channel in the target segment(n). The
parameter MS pwr opt level(n) (set independently for each adjacent segment)
indicates the optimum uplink RF signal level on a channel in the adjacent segment
after a handover. The range is from -110 dBm to -47 dBm. The optimisation of the
MS power level in handover is disabled when the value is 'no optimisation'.
☞ When the BSC calculates the optimised RF power level of the MS, it presumes
that the uplink signal level is equal to the downlink signal level, measured by the
MS, within the coverage area of the adjacent segment. If the downlink signal is,
for example, 5 dB stronger than the real uplink signal, the value for the parame-
ter MS pwr opt level should be selected 5 dB higher than the desirable
uplink signal level. Correspondingly, if the downlink signal is weaker than the
40 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4355
Handover algorithm and Multi BCF Control
real uplink signal, the value of the parameter MS pwr opt level should be
lower than the desirable uplink signal level.
Interference band recommendation
Interference band recommendation is used in the traffic channel allocation in a call and
in an intra-BSC handover attempt. The BSC is able to calculate an interference band
recommendation for each existing resource type in the segment by using the minimum
acceptable C/N ratio (parameter C/N threshold), the radio link measurements
reported by the MS/BTS and the boundary limits for the interference bands (parameter
averaging period).
The parameter averaging period is used for calculating averaged values from the
interference level in the active/unallocated timeslots for the traffic channel allocation pro-
cedure (see Extended Cell Range):
• averaging period is the number of SACCH multiframes from which the averag-
ing of the interference level in the active/unallocated timeslots is performed. The
range is from 1 to 32.
• boundary 1-4 are the limits of five interference bands for the active/unallocated
timeslots. The range is from -110 dBm to -47 dBm.
The BSC then compares the maximum acceptable interference level MAX_INTF_LEV
of each existing resource type with 5 interference bands. The comparison indicates the
interference band recommendation which is used in the channel allocation procedure.
The limits of five interference bands are retrieved from a BTS of that resource type for
which the interference band recommentation is calculated.
Example:
An MS is on GSM 900 Ultra Site resource type and the BSC calculates recommentation
for GSM 900 Ultra Site resource type.
The interference band is always a resource type-associated recommendation for a
target segment. In a handover attempt where there are several target segments, the
interference band recommendation does not change the order of preference of the
target segments.
The BSC allocates for a call or for an intra-BSC handover attempt primarily a TCH
whose uplink interference level is within the recommended interference band. For more
information, see Radio Channel Allocation.
C/N threshold = 20 dB Interference band 0 -110 ... -
105 dBm
RXLEV_UL = -78 dBm Interference band 1 - 104... -
100 dBm
Interference band 2 - 99 ... -
95 dBm
Interference band 3 - 94 ... -
90 dBm
Interference band 4 - 89 ... -
47 dBm
MAX_INTF_LEV = -78 dBm - 20 dB = -98 dBm
=> Interference band recommendation for GSM 900 Ultra
Site resource type is band 1
DN0176525
Issue 10-0
41
BSS10046: Multi BCF Control Handover algorithm and Multi BCF Control
Id:0900d805807c4355
Optimisation of the MS power level in handovers and in call setup
If Optimisation of the MS power level in handovers and in a call setup option is not
enabled, the RF power level, which the MS uses as the initial RF power in the BTS of a
certain resource type in the segment, is the maximum RF power that an MS is permitted
to use on a certain resource type channel in the segment (parameter MS txpwr max
gsm (BTS ) if serving BTS is GSM 800 or GSM 900 and parameter MS txpwr max
gsm1x00 (BTS) if serving BTS is GSM 1800 or GSM 1900).
The interference band recommendation is essential for the Optimisation of the MS
power level in a handover and in a call setup. Channel allocation criteria based on the
minimum acceptable C/N ratio eliminate the possibility of handover and call setup
failures due to power optimisation. If channel allocation criteria based on the minimum
acceptable C/N ratio are not employed for that resource type or there are no such idle
TCHs available whose uplink interference level is better than or within the recom-
mended interference band, the BSC cannot perform the optimisation for that resource
type.
For more information, see Radio Channel Allocation.
Optimisation of the MS power level in call setup
When optimisation of the MS power level in a call setup is employed, the BSC deter-
mines the RF power level which the MS uses as the initial RF power on the traffic
channel of certain resource type in the segment so that the RF power level corresponds
to the radio link properties of that resource type in the segment. The crucial principle is
that the better the radio link properties are, the lower the initial MS power level can be.
In other words, if the radio link properties of certain resource type in the segment are
good, the MS may use a lower RF power level than the maximum level when accessing
the traffic channel.
The optimised RF power level MS_TXPWR_OPT is calculated in the following way:
MS_TXPWR_OPT=
MS txpwr max gsm(BTS)-MAX(0,
(RXLEV_UL-optimum RX level uplink))
if serving BTS is GSM 800 or GSM 900
MS_TXPWR_OPT=
MS txpwr max gsm1x00(BTS)-MAX(0,
(RXLEV_UL-optimum RX level uplink))
if serving BTS is GSM 1800 or GSM 1900
RXLEV_UL is the uplink signal level when the MS is transmitting at the maximum RF
power that an MS is permitted to use on a channel in the serving segments BCCH
resource type. RXLEV_UL is measured during the initial signalling period of call setup.
The parameter optimum RX level uplink indicates the optimum uplink RF signal
level which both ensures adequate speech/data quality and does not cause uplink inter-
ference. The range of the parameter is from -109 dBm to -47 dBm. The use of the
parameter is disabled when the value is 'not used'.
g optimum RX level uplink must be set for every TRX of the same resource type
BTSs in the segment in order to enable the optimisation of the MS power level for
that resource type in a call setup.
42 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4355
Handover algorithm and Multi BCF Control
If the value of the parameter optimum RX level uplink varies between the
TRXs of same resource type BTSs in the segment, the BSC selects the highest
value for the calculation.
Optimisation of the MS power level in intra-BSC handover
When optimisation of the MS power level in a handover is employed, the BSC deter-
mines, in the case of a BSC-controlled handover, the RF power level which the MS that
has been handed over uses as the initial RF power in the certain resource type of the
target segment, so that the RF power level corresponds to the radio link properties of
that resource type in the target segment. The principle is that the better the radio link
properties are the lower the initial MS power level can be, that is, if the radio link prop-
erties of a certain resource type in the segment are good, the MS may use a lower RF
power level than the maximum level when accessing the target cell.
When optimisation of the MS power level in a handover is not employed, the initial MS
power level in the target segment is the maximum RF power an MS is permitted to use
on a channel in the target segment (parameter MS txpwr max gsm(BTS) if the serving
segment is GSM 800 or GSM 900 and parameter MS txpwr max gsm1x00(BTS) if the
serving segment is GSM 1800 or GSM 1900).
When the handover to be performed is an inter-cell handover, the optimisation is con-
trolled by the parameter MS pwr opt level(n). If the handover to be performed is
an intra-cell handover, the optimisation is controlled by the parameter optimum RX
level uplink.
The optimised RF power level MS_TXPWR_OPT is calculated in the following two ways
depending on whether the case is an inter-cell handover or an intra-cell handover:
Inter-cell handover
MS_TXPWR_OPT(n) = MS TX pwr max gsm(ADJ)(n)
- MAX(0,((AV_RXLEV_NCELL(n) -
non BCCH layer offset(n)) - MS pwr opt level(n)))
if adjacent segment is GSM 800 or GSM 900
MS_TXPWR_OPT(n)=
MS TX pwr max gsm1x00(ADJ)(n)-MAX(0,((AV_RXLEV_NCELL(n)—
non BCCH layer offset(n))-
(MS pwr opt level (n)+non BCCH layer offset(n))))
if adjacent segment is GSM 1800 or GSM 1900
AV_RXLEV_NCELL(n) is the averaged downlink signal level of the adjacent seg-
ment(n). The parameter MS TX pwr max gsm(ADJ)(n)or the parameter MS TX pwr
max gsm1x00(ADJ)(n)depending on the frequency band (set for each adjacent
segment) is the maximum RF power that an MS is permitted to use on a channel in the
adjacent segment(n).
The parameter MS pwr opt level(n) (set for each adjacent segment) indicates the
optimum uplink RF signal level on a channel in the adjacent segment(n) after the han-
dover. The range is from -110 dBm to -47 dBm. The optimisation of the MS power level
in handover is disabled when the value is 'no optimisation'.
When the BSC calculates the optimised RF power level of the MS, it presumes that the
uplink signal level is equal to the downlink signal level within the coverage area of the
adjacent segment. If the downlink signal is, for example, 5 dB stronger than the uplink
DN0176525
Issue 10-0
43
BSS10046: Multi BCF Control Handover algorithm and Multi BCF Control
Id:0900d805807c4355
signal, the value for the parameter MS pwr opt level(n) should be selected 5 dB
higher than the desirable uplink signal level. Correspondingly, if the downlink signal is
weaker than the uplink signal, the value of the parameter MS pwr opt
level(n)should be lower than the desirable uplink signal level.
Example: Optimum uplink RF signal level after a handover on a channel in the adjacent
segment(n) is -70 dBm.
1. If the uplink signal level equals the downlink signal level within the coverage area of
the adjacent segment(n), the value of the parameter MS pwr opt
level(n)should be -70 dBm.
2. If the downlink signal is 5 dB stronger than the uplink signal within the coverage area
of the adjacent segment(n), the value of the parameter MS pwr opt
level(n)should be -65 dBm.
3. If the downlink signal is 5 dB lower than the uplink signal within the coverage area
of the adjacent segment(n), the value of the parameter MS pwr opt
level(n)should be -75 dBm.
Intra-cell handover
MS_TXPWR_OPT=MS txpwr max gsm(BTS)-
MAX(0,(AV_RXLEV_UL_HO+(MS txpwr max gsm(BTS)-
MS_TXPWR)-optimum RX level uplink))
if serving BTS is GSM 800 or GSM 900
MS_TXPWR_OPT=MS txpwr max gsm1x00(BTS)-
MAX(0,(AV_RXLEV_UL_HO+(MS txpwr max gsm1x00(BTS)-
MS_TXPWR)-optimum RX level uplink))
if serving BTS is GSM 1800 or GSM 1900
MS txpwr max gsm(BTS)-MS_TXPWR or MS txpwr max gsm1x00(BTS)-
MS_TXPWR depending on the frequency band is the difference between the maximum
RF power that an MS is permitted to use on a certain resource type channel in the
segment and the actual transmitting power of the MS. The parameter optimum RX
level uplink indicates the optimum uplink RF signal level which both ensures
adequate speech/data quality and does not cause uplink interference. The range of the
parameter is from -109 dBm to -47 dBm. The use of the parameter is disabled when the
value is 'not used'.
g optimum RX level uplink must be set for every TRX of same resource type
BTSs in the segment in order to enable the optimisation of the MS power level for a
certain resource type in an intra-cell handover.
If the value of optimum RX level uplink varies between the TRXs of same
resource type BTSs in the segment, the BSC selects the greatest value for the cal-
culation.
For an overview, see Overview of Multi BCF Control.
44 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c435b
Expanding Talk-family cell with MetroSite or UltraSite
BTSs
6 Expanding Talk-family cell with MetroSite or
UltraSite BTSs
Purpose
This procedure describes how to expand an existing Talk-family cell with a UltraSite or
MetroSite BTS. You can use the BSC MML or NetAct. For instructions on how to
maintain sites that support Multi BCF using the NetAct, see Maintaining Multi-BCF Sites
in NetAct product documentation.
Before you start
Make sure of the following:
• The TRXs of the Talk-family BTS are in the WO (working) state.
• UltraSite or MetroSite BTS has been installed but not yet created.
• Synchronisation between the BTS sites has been installed.
• Abis lines are connected.
• ET has been connected to the Abis interface and LAPD links have been created for
the BTS.
• If Recovery for BSS and Site Synchronisation is used in the BTS site, the Talk-family
BCF software should be DF7, and it should be defined and activated to use Site or
BSS synchronisation.
During the BSC software installation the system creates a segment for each existing
BTS. The number of the segment is the same as the number of the related BTS, for
example BTS-32 → SEG-32.
Steps
1 Create a BCF (EFC).
Recovery for BSS and Site Synchronisation enables you to define the synchronisation
BCF chain configuration to BSC radio network database.
For more information, see Activating and Testing BSS11073: Recovery for BSS and Site
Synchronisation and BSS20371: BSS Synchronisation Recovery Improvement.
2 Create a BTS (EQC).
Create the UltraSite/MetroSite BTS to the same segment as the existing Talk-family
base station. You can check the information about all BTSs and TRXs of the segment
with the EEI MML command.
3 Delete the old BCCH channel.
☞ If you want to move the BCCH channel to a new BCF, you should do it at this stage.
Delete the BCCH channel from the Talk-family BTS. In UltraSite configurations, it is
logical to define the BCCH TRX to the UltraSite BTS, because its signal level is 2 dBm
better than that of a Talk-family BTS.
a) Lock the Talk-family BTS (EQS).
b) Lock the BCCH TRX (ERS).
DN0176525
Issue 10-0
45
BSS10046: Multi BCF Control Expanding Talk-family cell with MetroSite or UltraSite
BTSs
Id:0900d805807c435b
c) Delete the BCCH channel (ERM).
4 Create a TRX and BCCH channel (ERC).
After creating the TRX and the BCCH channel, you can check the information about all
TRXs of the segment with the EEI MML command.
5 Modify the power control parameters of the segment (EUG).
Modify the power control parameters of the segment unless the power control parameter
values of the Talk-family BTS are suitable for the UltraSite/MetroSite BTS as well. You
can check the values with the EUO MML command.
You can modify the power control parameters only via segment identification if the
segment has more than one BTS. The new value is set for all BTSs of the segment.
6 Define the signal level difference between Talk-family and UltraSite/MetroSite
(EQM).
Define the Talk-family - UltraSite/MetroSite signal level difference for the Talk-family
BTS object (the non-BCCH BTS) with the parameter non BCCH layer offset,
unless it is already set.
7 Define the load limit (BTS load in SEG) for a BTS (EQM).
8 Modify the handover control parameters of the segment (EHG, EHY).
You can output the handover control parameters of the segment with the EHO command.
9 Create adjacent cells (EAC).
10 Activate the BCF software package for UltraSite/MetroSite.
a) Create a BTS software package for UltraSite/MetroSite (EWC).
b) Attach the package to the UltraSite/MetroSite (EWA).
c) Activate the package (EWV).
11 Unlock the BCCH TRX and the BTSs of the segment.
The segment object has neither an operational nor an administrative state, so you must
unlock the BTSs of the segment one by one. The BCCH TRX must be unlocked before
BTS unlock. When you unlock a non-BCCH BTS, the BCCH TRX and BCCH BTS of the
segment must be unlocked first.
a) Unlock the TRX of the UltraSite or MetroSite BTS (ERS).
b) Unlock the UltraSite or MetroSite BTS (EQS).
c) Unlock the TRXs of Talk-family BTS (ERS).
d) Unlock the Talk-family BTS (EQS).
e) Unlock the UltraSite or MetroSite BCF (EFS).
46 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c435b
Expanding Talk-family cell with MetroSite or UltraSite
BTSs
12 Check the postcondition.
After unlocking, the UltraSite or MetroSite and Talk-family BTS TRXs are in WO (work-
ing) state. A call should be possible via both BTSs. Synchronised handovers are used
between the BTSs. The system has set synchronised handovers on by default.
You can get information about all TRXs of the segment with the EEI MML command.
13 Check the synchronisation of the BCFs (EFL).
This is needed if Recovery for BSS and Site Synchronisation or BSS Synchronisation
Recovery Improvement is in use.
DN0176525
Issue 10-0
47
BSS10046: Multi BCF Control Expanding UltraSite or Flexi EDGE cell
Id:0900d805807c446f
7 Expanding UltraSite or Flexi EDGE cell
Purpose
This procedure describes how to expand an existing UltraSite or Flexi EDGE cell. For
possible configurations, see the section Overview of Multi BCF Control. You can use the
BSC MML or NetAct. For instructions on how to maintain sites that support Multi BCF
using the NetAct, see Maintaining Multi-BCF Sites in NetAct product documentation.
Before you start
Make sure of the following:
• The TRXs of the existing BTS are in the WO (working) state.
• The new BTS has been installed but not yet created.
• Synchronisation between the BTS sites has been installed.
• Abis lines are connected.
• ET has been connected to the Abis interface and LAPD links have been created for
the BTS.
During the BSC software installation the system creates a segment for each existing
BTS. The number of the segment is the same as the number of the related BTS, for
example BTS-32 → SEG-32.
Steps
1 Create a BCF (EFC).
Recovery for BSS and Site Synchronisation enables you to define the synchronisation
BCF chain configuration to BSC radio network database.
For more information, see Activating and Testing BSS11073: Recovery for BSS and Site
Synchronisation and BSS20371: BSS Synchronisation Recovery Improvement.
2 Create a BTS (EQC).
Create the UltraSite/Flexi EDGE BTS to the same segment as the existing base station.
You can check the information about all BTSs and TRXs of the segment with the EEI
MML command.
☞ If you want to move the BCCH channel to a new BCF, you should do it at this stage.
a) Delete the BCCH channel from the existing BTS.
• Lock the existing BTS (EQS).
• Lock the BCCH TRX (ERS).
• Delete the BCCH channel (ERM).
b) Create a TRX and BCCH channel (ERC).
After creating the TRX and the BCCH channel, you can check the information
about all TRXs of the segment with the EEI MML command.
3 Modify the power control parameters of the segment (EUG).
Modify the power control parameters of the segment unless the power control parameter
values of the existing BTS are suitable for the new BTS as well. You can check the
values with the EUO MML command.
48 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c446f
Expanding UltraSite or Flexi EDGE cell
You can modify the power control parameters only via segment identification if the
segment has more than one BTS. The new value is set for all BTSs of the segment.
4 Define the load limit (BTS load in SEG) for a BTS (EQM).
5 Modify the handover control parameters of the segment (EHG, EHY).
You can output the handover control parameters of the segment with the EHO command.
6 Create adjacent cells (EAC).
7 Activate the BCF software package for UltraSite/Flexi EDGE.
a) Create a BTS software package for UltraSite/Flexi EDGE (EWC).
b) Attach the package to the UltraSite/Flexi EDGE (EWA).
c) Activate the package (EWV).
8 Unlock the BCCH TRX and the BTSs of the segment.
The segment object has neither an operational nor an administrative state, so you must
unlock the BTSs of the segment one by one. The BCCH TRX must be in unlocked state
before BTS unlock. Before you unlock a non-BCCH BTS, the BCCH TRX and BCCH
BTS of the segment must be in unlocked state.
a) Unlock the TRX of the new BTS (ERS).
b) Unlock the new BTS (EQS).
c) Unlock the new BCF (EFS).
Further information
If the BCCH channel was moved to a new BCF, remember to unlock the TRX and BTS
of the old BCF.
a) Unlock the TRXs of the old BTS (ERS).
b) Unlock the old BTS (EQS).
9 Check the postcondition.
After unlocking, the TRXs are in WO (working) state. A call should be possible via both
BTSs. Synchronised handovers are used between the BTSs. The system has set syn-
chronised handovers on by default.
You can get information about all TRXs of the segment with the EEI MML command.
10 Check the synchronisation of the BCFs (EFL).
This is needed if Recovery for BSS and Site Synchronisation or BSS Synchronisation
Recovery Improvement is in use.
DN0176525
Issue 10-0
49
BSS10046: Multi BCF Control Detaching a BTS from Multi BCF cell to a new segment
Id:0900d805807c4472
8 Detaching a BTS from Multi BCF cell to a new
segment
Purpose
This procedure describes how you can move an existing BTS to a new segment of its
own.
Before you start
If you want to move the BTS that has the BCCH TRX, you must first delete the BCCH
channel because moving a BTS containing a BCCH TRX is not allowed. All BTSs of the
old segment must also be in the locked state.
Steps
1 Lock the BTSs of the segment and the BCCH TRX (EQS, ERS).
2 Delete the BCCH channel from the moving BTS if necessary (ERM).
3 Move the BTS to a new segment (EQU).
4 Define a BCCH TRX. If you move the old BCCH BTS, the BCCH must be defined
for both BTSs.
a) Lock the TRX of the non-moved BTS if necessary (ERS).
b) Define the BCCH channel to a TRX of the non-moved BTS if necessary (ERM).
c) Define the BCCH channel to a TRX of the moving BTS (ERM).
5 Define power control, handover control and adjacency parameters for the moving
BTS.
This must be done because these parameters do not follow a moved BTS to the new
segment.
a) Create power control parameters (EUC).
b) Create handover control parameters (EHC).
c) Create an adjacent cell (EAC).
6 Unlock the BTSs of the segment.
The segment object has neither an operational nor an administrative state, so you must
unlock the BTSs of the segment one by one. The BCCH BTS must be unlocked first.
When you unlock non-BCCH BTSs, the BCCH TRX of the segment must be in the
administrative state WO.
a) Unlock the BCCH TRX of the moving BTS (ERS).
b) Unlock the moving BTS (EQS).
c) Unlock the BCCH TRX of the non-moved BTS (ERS).
d) Unlock the non-moved BTS (EQS).
50 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4358
Moving a BTS to another existing segment
9 Moving a BTS to another existing segment
Purpose
This procedure describes how you can move a BTS from the old segment to a new
segment that already exists. The BTS that is moved starts to use the parameters of the
new segment.
Before you start
g Moving a BTS containing the BCCH TRX is not allowed.
☞ When you combine two segments together, move all BTSs of one segment to a new
existing segment. After you have moved all BTSs the old segment does not exist any
more.
g The GPRS has to be disabled in all BTSs in both segments when moving a BTS
from one segment to another.
Steps
1 Lock all BTSs in the old and the new segment (EQS).
2 Move the BTS from the old segment to the new existing segment (EQU).
3 Define the BCCH (ERS, ERM).
4 Unlock all BTSs in the old and the new segment (EQS).
Further information
For an overview, see Overview of Multi BCF Control.
For more information on activation, see Activating and testing BSS10046: Multi BCF
Control.
DN0176525
Issue 10-0
51
BSS10046: Multi BCF Control Restarting Multi BCF site
Id:0900d805807c4356
10 Restarting Multi BCF site
Purpose
Recovery for BSS and Site Synchronisation offers synchronisation recovery for a Multi
BCF site and the possibility to define the Multi BCF chain configuration to the BSC's
radio network database. If Recovery for BSS and Site Synchronisation or BSS Synchro-
nisation Recovery Improvement is activated for a BTS chain, all BCF sites in the chain
are restarted automatically, if necessary, when the master clock BCF is restarted.
Before you start
A Multi BCF cell must be restarted by restarting each BCF separately, if BSS10 synchro-
nisation is used.
If synchronisation settings are defined and Site synchronisation (clock source = BCF) is
used for the BCFs in the segment, all slave BCFs in the chain are restarted autono-
mously when the master clock BCF (the first BCF in the chain) is restarted.
If synchronisation settings are defined and BSS synchronisation (clock source = LMU or
LMU-ABIS) is used for the BCF chain, slave BCFs in the chain are restarted autono-
mously after the master clock BCF restart, when activation of the BSS synchronisation
is in question.
Steps
1 Restart the Master Clock BCF of the BCF chain (EFR).
2 Restart also the slave BCF(s)(EFR), if the BSS Synchronisation is not activated for
the BCF chain.
Further information
For more information, see Activating and Testing BSS11073: Recovery for BSS and Site
Synchronisation and BSS20371: BSS Synchronisation Recovery Improvement.
52 DN0176525
Issue 10-0
BSS10046: Multi BCF Control
Id:0900d805807c4359
Implementing Multi BCF overview
11 Implementing Multi BCF overview
Before you start
Before implementing Multi BCF, go through the restrictions listed in Restrictions with
Multi BCF.
For more information on the supported BTS site type combinations in a Multi BCF cell,
see Overview of Multi BCF Control.
Steps
1 Configure Multi BCF.
2 Restart the Multi BCF site.
3 Test Multi BCF.
Further information
For detailed instructions, see Activating and testing BSS10046: Multi BCF Control.
For instructions on how to maintain sites that support the Multi BCF feature using the
NetAct, see Maintaining Multi-BCF Sites in NetAct Product Documentation.
DN0176525
Issue 10-0
53
BSS10046: Multi BCF Control Testing Multi BCF
Id:0900d805807c4470
12 Testing Multi BCF
Purpose
You can test the Multi BCF by setting up a call between two mobile stations that have
both camped on a Multi BCF segment. The basic idea of the test is to verify that mobile
stations can also be directed to the channels of the BTS that has no BCCH.
The test environment consists of the following:
• 1 BSC
• 1 BTS having a BCCH TRX
• 1 BTS having a non-BCCH TRX
• 2 MSS
The required test network (with example SEG and BTS IDs) is the following, with one of
the BTSs located in one base station cabinet and the other BTS in another cabinet:
• SEG-32
• BTS-32
• TRX-1 (8 full rate (TCHF) TSLs)
• BTS-66
• TRX-1 (MBCCHC + 7 full rate (TCHF) TSLs)
Steps
1 Set up a call between the two mobile stations in SEG-32.
Make sure that the accessing mobile stations are both well within the coverage area of
the Talk-family BTS of the segment if Talk-family BTS is in use.
2 Check that a TCH channel has been allocated in both BTSs (ERO).
3 Terminate the call.
Expected outcome
At the end of the measurement period, check the measurement data in NetAct or in BSC
using the MEFICO tool. For more information, see Reporter and Performance Manage-
ment Principles in NetAct Product Documentation and Converting BSC Measurement
and Observation Files with MEFICO.
Multi BCF activation has been successful if the BSC allocates TCH channels from both
BTSs of the segment. Counter 001026 TCH CALL REQUEST is updated in the BCCH
BTS, whereas counter 001009 SUCCESS TCH SEIZURE FOR NORMAL ASSIGN-
MENT is updated in both the BCCH and non-BCCH BTS.