multi bcf

Nokia Siemens Networks GSM/EDGE BSS, rel. RG20(BSS), operating documentation, issue 01

Feature description

BSS10046: Multi BCF Control

DN0176525

Issue 10-0Approval Date 2010-08-04

2 DN0176525Issue 10-0


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.

DN0176525Issue 10-0

3


Id:0900d805807c446e

Table of ContentsThis document has 53 pages.

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1 Overview of Multi BCF Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 System impact of Multi BCF Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Impact on transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Impact on BSS performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Impact on Network Switching Subsystem (NSS) . . . . . . . . . . . . . . . . . . 152.6 Impact on NetAct products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.7 Impact on mobile stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.8 Impact on interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.9 Interworking with other features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.9.1 Interoperable features with Multi BCF . . . . . . . . . . . . . . . . . . . . . . . . . . 172.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 DN0176525Issue 10-0


Id:0900d805807c446e

List of FiguresFigure 1 Possible handover directions in a segment . . . . . . . . . . . . . . . . . . . . . . 20Figure 2 Different interference levels with BSC recommendation 2 and without rec-

ommendation when searching for full-rate TCHs . . . . . . . . . . . . . . . . . . 31

DN0176525Issue 10-0

5


Id:0900d805807c446e

List of TablesTable 1 Required additional or alternative hardware or firmware . . . . . . . . . . . . 9Table 2 Required software by network elements . . . . . . . . . . . . . . . . . . . . . . . . . 9Table 3 Impact on BSC units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Table 4 Counters of Handover Measurement related to Multi BCF Control . . . 13Table 5 Counters of BSC Level Clear Code (PM) Measurement related to Multi

BCF Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6 DN0176525Issue 10-0


Id:0900d805807c446e

DN0176525Issue 10-0

7

BSS10046: Multi BCF Control Summary of changes

Id:0900d805807c435c

Summary of changesChanges 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-1BTSplus 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-0Information on InSite BTS has been removed.

Changes made between issues 9-0 and 8-1The 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-0In 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-1The 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 DN0176525Issue 10-0


Id:0900d805807c435a

Overview of Multi BCF Control

1 Overview of Multi BCF ControlMulti 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 topicsSystem 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

DN0176525Issue 10-0

9

BSS10046: Multi BCF Control System impact of Multi BCF Control

Id:0900d805807c4471

2 System impact of Multi BCF ControlThe 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 RequirementsHardware 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 DN0176525Issue 10-0


Id:0900d805807c4471

System impact of Multi BCF Control

Frequency band supportThe BSC supports Multi BCF Control on the following frequency bands:

• GSM 800 • GSM 900 • GSM 1800 • GSM 1900

2.2 Impact on transmissionNo impact.

2.3 Impact on BSS performanceOMU signallingNo impact.

TRX signallingNo impact.

Impact on BSC

Impact on BTS unitsNo impact on BTS units.

2.4 User interfaceBSC MMIThe 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

DN0176525Issue 10-0

11


Id:0900d805807c4471

• Power Control Parameter Handling: EUC, EUM, EUQ, EUS, EUB, EUO

BTS MMIMulti BCF Control cannot be managed with BTS MMI.

BSC parametersSome 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 DN0176525Issue 10-0


Id:0900d805807c4471


• 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

AlarmsThe 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 countersThe 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

DN0176525Issue 10-0

13


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 DN0176525Issue 10-0


Id:0900d805807c4471


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.

DN0176525Issue 10-0

15


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.

NetActThe 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 DN0176525Issue 10-0


Id:0900d805807c4471


2.6 Impact on NetAct productsNetAct ConfiguratorNetAct 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 ReporterReporting 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 MonitorStandard NetAct monitoring applications are used for the monitoring of Multi BCF Control. All alarms are available for NetAct monitoring tools.

NetAct TracingNo impact.

NetAct AdministratorNetAct 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 PlannerNetAct 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 OptimizerOptimizer 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.

DN0176525Issue 10-0

17


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 stationsNo requirements for mobile stations.

2.8 Impact on interfacesWithout 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 BCCHWhen 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 RetryThe 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 DN0176525Issue 10-0


Id:0900d805807c4471


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 allocationThe 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 ControlIn the segment environment, only a BCCH BTS can have extended area TRXs.

For more information, see Extended Cell.

FACCH call setupIn 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 HoppingIn 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

DN0176525Issue 10-0

19


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.

GPRSWhen 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 DN0176525Issue 10-0


Id:0900d805807c4471


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

DN0176525Issue 10-0

21


Id:0900d805807c4471

MSC-controlled traffic reason handoverThe 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-emptionWhen 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.

QueueingWhen 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 supervisionThe 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 ImprovementRecovery 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 DN0176525Issue 10-0


Id:0900d805807c4471


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 controlBy 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 ReservationThe control of Trunk Reservation is on the segment level.

For more information, see Trunk Reservation.

Wideband AMRWhen 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 ControlThe use of Multi BCF Control and the segment environment causes restrictions for the functionality of the following application and operating software.

BCCH TRX recoveryThe 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 broadcastUser gives definitions for the BCCH BTS only.

Extended cell rangeIn 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.

DN0176525Issue 10-0

23


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 userRecovery 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 allocationWith 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 allocationWith 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 allocationWith 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 BTSWhen 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 DN0176525Issue 10-0


Id:0900d805807c4473

Segment configuration and state management

3 Segment configuration and state manage-mentThe 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 environmentCreate 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 segmentsThe 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

DN0176525Issue 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 environmentThe 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 environmentIn 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 DN0176525Issue 10-0


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.

RecoveryThe 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.


DN0176525Issue 10-0

27

BSS10046: Multi BCF Control Radio resource management and Multi BCF Control

Id:0900d805807c4357

4 Radio resource management and Multi BCF ControlSDCCH allocation in segment environmentSDCCHs 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 SegmentImmediate 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 DN0176525Issue 10-0


Id:0900d805807c4357


Selection of TRX, RTSL and channelAfter 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:

DN0176525Issue 10-0

29


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 environmentThe 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 evaluationThe 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 ControlThe 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 DN0176525Issue 10-0


Id:0900d805807c4357


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 SEG2. The interference band of an idle channel, TRX prioritisation in TCH allocation and

the channel type3. The circuit switched territory load of a BTS4. 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 SEG2. BTSs with load between BTS load in SEG and the highest BTS load in SEG

value of the segment3. 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 BTS2. MetroSite BTS3. 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.

DN0176525Issue 10-0

31


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 EGSM9002. 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 DN0176525Issue 10-0


Id:0900d805807c4357


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 recommendation2. Load according to parameter BTS load in SEG3. Dedicated GPRS territory size4. 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 ControlIn 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.

DN0176525Issue 10-0

33


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.


34 DN0176525Issue 10-0


Id:0900d805807c4355


5 Handover algorithm and Multi BCF ControlSDCCH resource usability evaluation in Multi BCF ControlIntra-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 ControlThe 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

DN0176525Issue 10-0

35

BSS10046: Multi BCF Control Handover algorithm and Multi BCF Control

Id:0900d805807c4355


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 segmentTo 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 DN0176525Issue 10-0


Id:0900d805807c4355


☞ 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 ControlBecause 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


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 ControlWith 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.

DN0176525Issue 10-0

37


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 ControlIn 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 ControlEach 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 ratioWhen 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 DN0176525Issue 10-0


Id:0900d805807c4355


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 thresholdRXLEV_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 900MAX_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

DN0176525Issue 10-0

39


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 DN0176525Issue 10-0


Id:0900d805807c4355


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



MAX_INTF_LEV = -78 dBm - 20 dB = -98 dBm

=> Interference band recommendation for GSM 900 Ultra Site resource type is band 1

DN0176525Issue 10-0

41


Id:0900d805807c4355

Optimisation of the MS power level in handovers and in call setupIf 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 setupWhen 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))


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 DN0176525Issue 10-0


Id:0900d805807c4355


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 handoverWhen 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

DN0176525Issue 10-0

43


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))


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))


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.


44 DN0176525Issue 10-0


Id:0900d805807c435b


6 Expanding Talk-family cell with MetroSite or UltraSite BTSsPurposeThis 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 startMake 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).

DN0176525Issue 10-0

45

BSS10046: Multi BCF Control Expanding Talk-family cell with MetroSite or UltraSiteBTSs

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 DN0176525Issue 10-0


Id:0900d805807c435b


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.

DN0176525Issue 10-0

47

BSS10046: Multi BCF Control Expanding UltraSite or Flexi EDGE cell

Id:0900d805807c446f

7 Expanding UltraSite or Flexi EDGE cellPurposeThis 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 startMake 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 DN0176525Issue 10-0


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 informationIf 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.

DN0176525Issue 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 segmentPurposeThis procedure describes how you can move an existing BTS to a new segment of its own.

Before you startIf 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 DN0176525Issue 10-0


Id:0900d805807c4358

Moving a BTS to another existing segment

9 Moving a BTS to another existing segmentPurposeThis 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 informationFor an overview, see Overview of Multi BCF Control.

For more information on activation, see Activating and testing BSS10046: Multi BCF Control.

DN0176525Issue 10-0

51

BSS10046: Multi BCF Control Restarting Multi BCF site

Id:0900d805807c4356

10 Restarting Multi BCF sitePurposeRecovery 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 startA 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 informationFor more information, see Activating and Testing BSS11073: Recovery for BSS and Site Synchronisation and BSS20371: BSS Synchronisation Recovery Improvement.

52 DN0176525Issue 10-0


Id:0900d805807c4359

Implementing Multi BCF overview

11 Implementing Multi BCF overviewBefore you startBefore 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 informationFor 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.

DN0176525Issue 10-0

53

BSS10046: Multi BCF Control Testing Multi BCF

Id:0900d805807c4470

12 Testing Multi BCFPurposeYou 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 outcomeAt 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.

multi bcf

Documents