multi bcf control

7/26/2019 Multi BCF Control

1/80

Multi BCF Control

DN0176525Issue 8-0 en

# Nokia Siemens Networks 1 (80)

BSC3153

Nokia GSM/EDGE BSS, Rel. BSS13, BSC and

TCSM, Rel. S13, Product Documentation, v.1


2/80

The information in this document is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This documentation is intended for theuse of Nokia Siemens Networks customers only for the purposes of the agreement under whichthe document is submitted, and no part of it may be used, reproduced, modified or transmitted inany form or means without the prior written permission of Nokia Siemens Networks. Thedocumentation has been prepared to be used by professional and properly trained personnel,and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomescustomer comments as part of the process of continuous development and improvement of thedocumentation.

The information or statements given in this documentation concerning the suitability, capacity, orperformance of the mentioned hardware or software products are given as is and all liabilityarising in connection with such hardware or software products shall be defined conclusively andfinally in a separate agreement between Nokia Siemens Networks and the customer. However,Nokia Siemens Networks has made all reasonable efforts to ensure that the instructionscontained in the document are adequate and free of material errors and omissions. NokiaSiemens 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 NOEVENT WILL NOKIA SIEMENS NETWORKS BE LIABLE FOR ERRORS IN THISDOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL,DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUTNOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESSOPPORTUNITY OR DATA, THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THEINFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights andother intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark ofNokia 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 2008. All rights reserved.

2 (80) # Nokia Siemens Networks DN0176525Issue 8-0 en

Multi BCF Control


3/80

Contents

Contents 3

List of tables 4

List of figures 5

Summary of changes 7

1 Overview of Multi BCF Control 9

2 System impact of Multi BCF Control 11

2.1 Requirements 112.2 Impact on transmission 122.3 Impact on BSS performance 132.4 User interface 132.5 Impact on Network Switching Subsystem (NSS) 212.6 Impact on NetAct products 212.7 Impact on mobile stations 232.8 Impact on interfaces 232.9 Interworking with other features 232.9.1 Interoperable features with Multi BCF 232.9.2 Restrictions with Multi BCF Control 30

3 Segment configuration and state management 33

4 Radio resource management and Multi BCF Control 37

5 Handover algorithm and Multi BCF Control 47

6 Expanding Nokia Talk-family cell with Nokia MetroSite or UltraSiteBTSs 63

7 Expanding Nokia UltraSite or Flexi EDGE cell 67

8 Detaching a BTS from Multi BCF cell to a new segment 71

9 Moving a BTS to another existing segment 73

10 Restarting Multi BCF site 75

11 Implementing Multi BCF overview 77

12 Testing Multi BCF 79



Contents


4/80

List of tables

Table 1. Required additional or alternative hardware or firmware 11

Table 2. Required software by network elements 12

Table 3. Impact on BSC units 13

Table 4. Counters of Handover Measurement related to Multi BCF Control 17

Table 5. Counters of BSC Level Clear Code (PM) Measurement related to MultiBCF Control 18


Multi BCF Control


5/80

List of figures

Figure 1. Possible handover directions in a segment 28

Figure 2. Different interference levels with BSC recommendation 2 and withoutrecommendation when searching for full-rate TCHs 43



List of figures


6/80


Multi BCF Control


7/80

Summary of changes

Changes between document issues are cumulative. Therefore, the latest

document issue contains all changes made to previous issues.

Changes made between issues 7-1 and 8-0

The document has been merged with the Nokia GSM/EDGE BSS, Rel.

BSS12, System Documentation, v.1 release document Multi BCF System

Feature Description.

The following additions have been made in the document:

. The information in chapterOverview of Multi BCF Controlhas been

ckecked and updated.

. The chapterSystem Impact of BCF Controlhas been added.

. Chapters Segment Environment, Requirements for Multi BCF

Control, Technical Description of Multi BCF Control, and User

Interface of Multi BCF Controlhave been removed as the

information is already included in the new chapterSystem Impact of

BCF Control.

. Chapters Implementing Multi BCF,Expanding Nokia Talk-family Cell

with Nokia MetroSite or UltraSite BTSs, Expanding Nokia UltraSite

or Flexi EDGE Cell, Detaching a BTS from Multi BCF Cell to a NewSegment, Moving a BTS to Another Existing Segment, Restarting

Multi BCF Site, and Testing Multi BCFhave been added.


In the Segment Environmentchapter, added a table BA range and the

maximum number of ARFCNsand updated information about the

maximum number of segment configuration possible based on the ARFCN

range.



Summary of changes


8/80


Removed all information relating to Common BCCH control.

Enhanced the example of SEG Radio network objects to indicate multi

BCF control.

Removed information relating to PGSM and EGSM.

Included information about Nokia Flexi EDGE BTS.


Radio resource management and Multi BCF Control

Added a topic RX level based TCH resource usability evaluation.

Handover algorithm and Multi BCF Control

A paragraph added to explain the role of the channel allocation algorithm

in TCH resource usability evaluation.

User interface of Multi BCF Control in BSC

Information related to parameters MS txpwr max gsm and MS txpwr maxgsm1x00 removed.

The document has been revised throughout to comply with the latest

documentation standards.


Multi BCF Control


9/80

1 Overview of Multi BCF ControlMulti Base Station Control Function (BCF) is an application software

product that allows combining resources of several physical base stationsinto one logical cell. This enables operators to increase the capacity of a

cell, while maintaining maximum spectral efficiency. Multi BCF increases

the Nokia Talk-family and Nokia MetroSite BTS cell capacity to 24 TRXs,

and the Nokia UltraSite and Nokia 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 Nokia Talk-family BTS, Nokia UltraSite BTS, Nokia Flexi EDGE BTS, and Nokia

MetroSite BTS. The BSC allows up to 36 TRXs and 32 BTS objects in asegment.

The BSC allows the following BTS site type combinations in a Multi BCF

cell:

. Nokia Talk-family + Nokia MetroSite (one MetroSite BCF can contain

a maximum of three MetroSite BCFs in the chain)

. Nokia Talk-family + Nokia Talk-family (a maximum of six Talk-family

BCFs in the chain)

. Nokia Talk-family + Nokia UltraSite (a maximum of five UltraSite

BCFs in the chain)

. Nokia UltraSite + Nokia UltraSite (a maximum of nine UltraSite BCFs

in the chain)



Overview of Multi BCF Control


10/80

. Nokia UltraSite + Nokia 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)

. Nokia Flexi EDGE + Nokia Flexi EDGE (a maximum of nine FlexiEDGE BCFs in the chain)

Related topics

System Impact of Multi BCF Control

Segment configuration and state management with Multi BCF Control



Expanding Nokia Talk-family cell with Nokia MetroSite or UltraSite BTSs

Expanding Nokia 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


Multi BCF Control


11/80

2 System impact of Multi BCF ControlThe system impact of Multi BCF Control is specified in the sections below.

For an overview, see Overview of Multi BCF Control

For implementation instructions, see Implementing Multi BCF Control.

Multi BCF Control is an application software product.

2.1 Requirements

Hardware requirements

Table 1. Required additional or alternative hardware or firmware

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



System impact of Multi BCF Control


12/80

Software requirements

Table 2. Required software by network elements

Network element Software release

required

BSC S11

Nokia Flexi EDGE

BTSs

No requirements

Nokia UltraSite

EDGE BTSs

CX3

Nokia MetroSite

EDGE BTSs

CXM4.0

Nokia Talk-family

BTSs

DF6 SW is applicable

with UltraSite and

MetroSite.

Nokia InSite BTSs Multi BCF Control not

supported

MSC/HLR Not applicable

TCSM No requirements

SGSN Not applicable

Nokia NetAct OSS3.1 ED3

Table Required software by network elementsshows the earliest version

that supports Multi BCF Control.

Frequency band support

The BSC supports Multi BCF Control on the following frequency bands:

. GSM 800

. GSM 900

. GSM 1800

. GSM 1900

2.2 Impact on transmission

No impact.


Multi BCF Control


13/80

2.3 Impact on BSS performance

OMU signalling

No impact.

TRX signalling

No impact.

Impact on BSC

Table 3. Impact on BSC units

BSC unit Impact

OMU No impact

MCMU No impact

BCSU No impact

PCU No impact

Impact on BTS units

No impact on BTS units.

2.4 User interface

BSC MMI

The following MML command groups and commands are used for

handling Multi BCF Control:

. Adjacent Cell Handling (command group EA)

. Base Station Controller Parameter Handling in BSC (command

group EE)

. Base Control function Handling (command group EF)





14/80

Note

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 Synchronisation Recovery Improvement in Nokia

BSC/TCSM Product Documentation.

. Handover Control Parameter Handling (command groupEH)

. Base Transceiver Station Handling in BSC (command group EQ)

. Power Control Parameter Handling (command groupEU

)

BTS MMI

Multi BCF Control cannot be managed with BTS MMI.

BSC parameters

Some of the parameters are needed for the general handling of the

segment environment 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 containingcell-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.


Multi BCF Control


15/80

The parameternon BCCH Layer Offset (NBL) is used to indicate how

much weaker the signal level of a BTS is when compared to that of theBCCH BTS. Because of this the parameter must always be set to a 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.

ParameterRX lev min cell in the Adjacent Cell Handling commandgroup 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 parametercalled 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 theparameters.

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

. GPRS non BCCH layer rxlevel upper limit

. non BCCH layer offset

SEG-specific BTS radio network object parameters





16/80

. direct GPRS access BTS

. rxlev access min

. rxlev access min cell

. SEG identification

. SEG name

Alarms

The segment object is invisible to the BSC alarm system. The alarms are

focused on the same radio network objects independently, whether the

segment architecture is used or not. All the cell and BTS-specific alarmsare 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 CONGESTION 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 THRESHOLD 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 different 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

congestion supervision gives a good idea of how the supply meets thedemand for radio channel resources in a cell.

For more information, see Base Station Alarms (70007999).

Measurements and counters

The basic structure of statistics is maintained with Multi BCF Control.

Measurements that have been collected per BTS before the introduction of

the segment concept are BTS-specific also in the segment environment.

Nokia NetAct offers you the possibility to have segment-specific statistics

based on the BTS-specific measurements.


Multi BCF Control


17/80

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

Table 4. Counters of Handover Measurement related to 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

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 handovers that take place between BTSs of different

segments.

BSC Level Clear Code (PM) Measurement and Multi BCF Control





18/80

Table 5. Counters of BSC Level Clear Code (PM) Measurement related to

Multi BCF Control

Name Number

INTRA INTER BTS TYPE TCH HANDOVER 051147

INTRA INTER BTS TYPE SDCCH HANDOVER 051148

Following the established practice with the handover attempt causes andthe 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

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


Multi BCF Control


19/80

In an intra-cell handover between BTSs inside a segment the handover

attempt counter is updated for the source BTS of the handover. Thisenables 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 theBTS in which the allocation has been made. Also 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 thehandover.

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 information 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 handoversbetween BTSs. They are needed whenever there are segments with

several BTSs. The counters report how many of the intra-segmenthandovers 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.

. INTRA CELL SUCCESS TCH HO BETWEEN BTSS (004132)





20/80

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 reservation, 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 - TCHhandovers 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.


Multi BCF Control


21/80

The following two counters collect information on the number of inter-

segment handovers between different BTS types. The counters report howmany 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.

Nokia NetAct

The following parameters are in use in the Nokia NetAct:

. The BSC parameterintra segment SDCCH HO guard.

.

The BTS parameters SEG identification, SEG name, nonBCCH layer offset and BTS load in SEG.

For an overview, see Overview of Multi BCF Control in BSC.

2.5 Impact on Network Switching Subsystem (NSS)

No impact.

2.6 Impact on NetAct products

NetAct Radio Access Configurator (RAC)

NetAct Radio Access Configurator (RAC) provides network-wide access

and tools for Multi BCF configuration. In the BSC, the Multi BCF

management is handled via segment. In RAC, the segment management

is done using a master BTS definition. For instructions on how to maintain

sites that support Multi BCF Control using NetAct, see Maintaining Multi-

BCF Sitesin Nokia NetAct Product Documentation.





22/80

NetAct Reporter

Reporting for Multi BCF Control is done by common Nokia 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 selection for report properties

NetAct Monitor

Standard Nokia NetAct monitoring applications are used for the monitoring

of Multi BCF Control. All alarms are available for NetAct monitoring tools.

NetAct Tracing

No impact.

NetAct Administrator

NetAct Administrator offers full support to Multi BCF Control administrative

tasks, for example:

. fast download and activation of Multi BCF Control software to BTSs

via Nokia NetAct tools

. expandable software archives

. storages for multiple software configurations

NetAct Planner

Nokia NetAct Planner includes a set of radio network and planning

features for Multi BCF Control. This allows the visibility of Multi BCF

Control in radio network planning. Plans can be completed with Radio

Access Configurator.


Multi BCF Control


23/80

NetAct Optimizer

Optimizer supports Multi BCF Control. Internally, Optimizer creates Cell

objects based on segment ID and Master BTS flag information. In the

geographical map view, Multi BCF cells (segments) are visible entirely;

non-segment BTSs are available as earlier. Two views are available in the

topology view: cell (segment) view and common object model view (BSC-

BCF-BTS). The Adjacency, Power Control and HandOver Control objects

are linked to the master BTS of the segment.

2.7 Impact on mobile stations

No requirements for mobile stations.

2.8 Impact on interfaces

Without Multi BCF Control, there is a separate the BSSGP virtual

connection BVC for each individual BTS in the Gb interface. With Multi

BCF Control, the GPRS traffic of all (E)GPRS-capable BTSs in the same

segment is directed through one BVC.

2.9 Interworking with other features

2.9.1 Interoperable features with Multi BCF

Adaptive Multirate (AMR)

Decisions on the need for packing AMR FR (full rate) calls to AMR HR (half

rate) calls is based on the load situation of each individual BTS also in the

segment environment. AMR FR calls in a particular BTS are packeddepending 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.





24/80

Common BCCH

When Multi BCF Control and Common BCCH are combined you are

allowed to configure 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 evaluated per segment, adjacency definitions are

between segments and DADL/B handovers are made between segments.

For more information, see Direct Access to Desired Layer/Band in NokiaBSC/TCSM Product Documentation.

Directed Retry

The Directed Retry or the Intelligent Directed Retry procedure can be

triggered even if all the resources of a segment are not completely in use.

The triggering of the procedure requires that all the resources that an

accessing MS could use under the current conditions are unavailable.

For more information, seeDirected Retry Procedure in BSCin Nokia BSC/

TCSM Product Documentation.

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.


Multi BCF Control


25/80

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 theoperator with 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 Dynamic Frequency and Channel Allocation in

BSCin Nokia BSC/TCSM Product Documentation.

Dynamic SDCCH allocation

The dynamic reconfiguration of the SDCCH radio time slots is possible

only in those BTSs of a Multi BCF segment which have a negative value orvalue zero in parameternon BCCH layer offsetand are, thus, indicated to

have a signal level at least as strong as in the BCCH BTS.

Extended Cell and Multi BCF Control

In the segment environment, only a BCCH BTS can have extended area

TRXs.

For more information, see Extended Cellin Nokia BSC/TCSM Product

Documentation.

FACCH call setup

In FACCH call setup, the SDCCH phase is skipped and the call is put

directly to a TCH channel. At that time, the measurement reports from the

accessing MS are not available. Therefore, the usability of the non-BCCH

layer resources based on those reports cannot be defined.

In Multi BCF Control, the FACCH setup is possible only in those BTSs of a

Multi BCF segment which have a negative value or value zero in

parameternon BCCH layer offset and are, thus, indicated to have a

signal level at least as strong as in the BCCH BTS.

Frequency Hopping

In the segment architecture, the resources of different base station types

are grouped as separate BTSs. Frequency Hopping is managed by a BTS.

All the different BTSs in a segment have their own hopping parameters

and hopping groups.

The segment architecture enables having BTSs without a BCCH TRX.

This reduces the number of hopping groups in a BTS's regular area,

because there is no need for a separate group for the BCCH TRX in RF

hopping. In BB hopping, there is no need for separating TSL0 from the





26/80

other TSLs in BTSs that do not contain a BCCH TRX. However, the

separation between TSL0 and other TSLs remains and these are regardedas two different hopping groups. The operator gives one set of parameters

for 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 Frequency Hoppingin Nokia BSC/TCSM

Product Documentation.

GPRS

When comparing the TCH load of a segment's BTS with the parameter

BTS load in SEG, the BSC interpretes RTSLs in GPRS territory as busy

channels (excluding dedicated 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 section Radio resourcemanagement and Multi BCF Controlof Multi BCF Control in BSC, in NokiaBSC/TCSM Product Documentation.

For the effects of the segment concept on the radio resource management

of the packet-switched services in the PCU, see GPRS in BSC in Nokia

BSC/TCSM Product Documentation.

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.


Multi BCF Control


27/80

Among the resource types that the BSC defines as reasonable, the TCH

search is performed in a way that the HSCSD channel configuration whichbest fulfils the request is selected. Within a segment, the 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.

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 asegment. In each BTS, the downgrade decision is based on the HSCSD

parameters of the particular BTS.

For more information, seeHSCSD and 14.4 kbit/s Data Services in BSCin

Nokia BSC/TCSM Product Documentation.

Intelligent Coverage Enhancement (ICE+)

Intelligent Coverage Enhancement 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 procedure 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 parameternon BCCH

layer offset in different BTSs of the segment. As a target the BSC





28/80

accepts the BTSs that havenon 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 in Nokia BSC/


MSC controlled traffic reason handover

The MSC-controlled traffic reason handover (TRHO) and the related

resource indications are segment-level procedures.

In the spontaneous resource indication method, the segment-level

parameterBTS load threshold is used when defining the need to send

the resource indication.

BTS1

Regular area

Super-reuse area

BTS2

Regular area

Super-reuse area


Multi BCF Control


29/80

Pre-emption

When the segment architecture is used, Pre-emption is a segment level

function.

In a segment with several BTSs of different properties it is possible that a

TCH request cannot be served even though all the TCH resources in a

segment are not fully used. However, pre-emption is possible, if permitted

by the related parameters.

The candidate for the forced actions is selected among the resource types

that are indicated 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 prioritycall 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 in

Nokia BSC/TCSM Product Documentation.

Queueing

When the segment architecture is used, the queueing for traffic channels isa segment-level procedure including related parameters.

In a segment with several BTSs of different properties it is possible that aTCH 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 QueuinginNokia BSC/TCSM Product Documentation.

Radio network supervision

The congestion supervision for alarm 7746 CH CONGESTION IN CELL

ABOVE DEFINED THRESHOLD is monitored on the segment level since the

target for a channel request is a segment. In a segment with several BTSs,

the channel congestion supervision 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.





30/80

For more information, see Radio Network Supervision in Nokia BSC/


Recovery for BSS and Site Synchronisation and BSSSynchronisation Recovery Improvement

Recovery for BSS and Site Synchronisation and BSS Synchronisation

Recovery Improvement offers synchronisation recovery for a Multi BCF

site and the possibility to define the Multi BCF chain configuration to 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.

For more information, seeActivating and Testing BSS11073: Recovery for

BSS and Site Synchronisation and BSS20371: BSS Synchronisation

Recovery Improvementin Nokia BSC/TCSM Product Documentation.

RX level based TCH access control

By default, the BSC determines the usability of TCH resources of a Multi

BCF segment on a BTS site type basis. As an alternative method, the BSC

can perform a special RX level based TCH resource usability evaluation if

so indicated with the BSC radio network object parameterRX level basedTCH access. When the RX level based TCH access control is applied, the

usability of TCH resources in a segment can be determined on a BTS

basis. For more information on the RX level based TCH access control

method, see Radio Channel Allocationin Nokia BSC/TCSM Product

Documentation.

Trunk Reservation

The control of Trunk Reservation is on the segment level.

For more information, seeTrunk Reservationin Nokia BSC/TCSM Product

Documentation.

2.9.2 Restrictions with Multi BCF Control

The use of Multi BCF Control and the segment environment causes

restrictions for the functionality of the following application and operating

software.


Multi BCF Control


31/80

BCCH TRX recovery

The BCCH channel is recovered only inside a BTS radio network object. In

a BCCH TRX fault situation the BCCH is not reconfigured from one BTS to

another BTS. The new BCCH TRX has to be found from the same BTS

radio network object.

Cell broadcast

User gives definitions for the BCCH BTS only.

Extended cell range

In the segment environment, only the BCCH BTS can have extended areaTRXs.

Intelligent Coverage Enhancement (ICE+)

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

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 supported in segments with more than one BTS.

The child cell concept is not supported when the segment architecture is

used.

Multi BCF site reset by user

Recovery for BSS and Site Synchronisation and BSS Synchronisation

Recovery Improvement enable you to define the synchronisation chain

configuration to the BSC radio network database. If the synchronisationchain is not defined and enabled, Multi BCF restart is only possible with a

series of BCF site reset MML commands (instead of a single command).

SDCCH allocation

With Multi BCF Control, the extent of the SDCCH search in the initial

SDCCH allocation for the call setup and SDCCH allocation for the external

handover depends on the values of the non BCCH layer offset

parameters in BTSs other than the BCCH BTS. If the value of the

parameter in the BTS is positive, the channel is not allocated from that

BTS.





32/80

Dynamic SDCCH allocation

With Multi BCF Control, the same restrictions that apply in initial SDCCH

allocation for call setup are also valid for the dynamic SDCCH feature. The

BSC does not configure a TCH-TSL for dynamic SDCCH use in a BTS in

which the non BCCH layer offset parameter has a value greater than

zero.

TCH allocation

With Multi BCF Control, the extent of the TCH search in both the FACCH

setup and external handover depend on the values of the non BCCH layer

offsetparameters in BTSs other than the BCCH BTS. If the value of the

parameter in the BTS is positive, the channel is not allocated from thatBTS.

PGSM-EGSM900 BTS

When the BCCH TRX frequency is of the type PGSM900 and an

EGSM900 frequency is being used in the same BCCH BTS, the GSM900

band frequencies can only be used in the BCCH BTS of the Multi BCF

segment. For more information about using the PGSM900 and EGSM900

frequencies in the same BTS, see the document PGSM900-EGSM900

BTS in BTC.


Multi BCF Control


33/80

3 Segment configuration and statemanagement

The BSC software update to support the segment concept allows thesystem to automatically convert cells to segments. In practice, the BSC

adds new segment identification information for each cell by copying the

BTS identification data of the cell to the respective segment parameters.

Despite the introduction of the segment object the BTS object remains as

the basic element in the radio network configuration and state

management in the BSC.

BTS creation in segment environment

Create BTSs in the segment environment in the similar way as without thesegment 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 functioning depending on whether the first or an additional BTS to

a segment is created. If your create the first BTS of a segment then both

the BTS-specific and the segment-specific parameters related to the



Segment configuration and state management


34/80

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 copiedfrom 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 restrictions apply as for the BTS identification.

The BSC allows up to 36 TRXs and 32 BTS objects in a segment.

Moving BTSs between segments

The U command in the Base Transceiver Station Handling in BSC

command group is used for changing the segment of a BTS and thusmoving a BTS from a 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 thatsegment 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 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 belocked when the moving command is used. GPRS has to be disabled both

at the source segment and at the target segment during the BTS moving

operation.

State management in segment environment

The state management of a segment is performed through the BTS object.

The segment object has neither operational nor administrative state. When

locking of a segment is needed, for example, when you want to modify asegment level parameter that requires locking, you have to lock the BTSs

of the segment one by one.


Multi BCF Control


35/80

When locking the whole segment the BCCH-BTS of the segment must be

locked first. This is of essential importance especially when the segment islocked using the forced handover procedure. The shutting down of the

segment's BTSs in the BCCH-BTS prevents the calls from being handed

over to other BTSs of the segment. Handovers to other segments are

performed instead. When the BCCH BTS is working and a non-BCCH BTS

of a segment is shut down with forced handover, the calls of the non-

BCCH BTS can be transferred to other BTSs of the segment as well.

In the state transition command scenario where you change the state of all

the BTSs from LOCKED to UNLOCKED the BCCH BTS must be handled

first. The system checks that the BCCH TRX is working when the state

transition command is given for a non-BCCH BTS of a segment.

Parameter management in segment environment

In the segment environment, where individual cells can have several

BTSs, the user has the possibility to modify parameters both through thesegment 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 alternative parameters ABTS,

ANAME, LAC+CI, ASEG, and ASEGNAME are available. ABTS and

ANAME cannot be used for an adjacent cell of several BTSs.



Segment configuration and state management


36/80

In the Handover Control Parameter Handling and Power Control

Parameter Handling command groups all parameters related to the MultiBCF Control are on segment level. In a segment of a single BTS, the

parameter command groups are controlled by using BTS and segment

level identification method (BTS, NAME, SEG, or SEGNAME). In a

segment of several BTS objects the parameter SEG or SEGNAME must

be used. For the identification of a possible reference object, the user can

give one of the parameters REF, RNAME, RSEG, and RSEGNAME if both

the target segment of the command and the reference segment contain

only one BTS, otherwise RSEG or RSEGNAME must be used.

Recovery

The recovery operations during a failure on the TRX carrying the BCCHtimeslot are performed 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

looses 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 incomingsignal, the BSC automatically restarts the slave BCF(s) to work in a

synchronised mode.

For an overview, see Overview of Multi BCF Control in BSC.


Multi BCF Control


37/80

4 Radio resource management and MultiBCF Control

SDCCH allocation in segment environment

SDCCHs are allocated for signalling purposes, immediate assignments,

intra-BSC handovers and inter-BSC handovers. The selection of SDCCH

in all these situations is made by the channel allocation algorithm in BSC.

SDCCH allocation from a segment consisting of BTSs of different BTS

types is based on the usability of the radio resources. The usability of the

radio resources of BTSs of different BTS types for the accessing MS is

defined by either the handover algorithm or the channel allocation

algorithm in BSC.

Selection of BTSs in Multi BCF Segment

Immediate Assignment

If in a segment consisting of BTSs of different BTS types the BCCH carrier

has been configured to the type of BTS which has better link budget than

the other type of BTSs, the SDCCH can be allocated only among the

BCCH BTS type of BTSs. This is because the BSC has no information

based on which the usability of the radio resources of BTSs of different

BTS types than BCCH BTS type could be defined. That is, the MS has not

sent any measurement reports yet.

If the BCCH carrier of the segment has been configured to the type of BTS

which has worse link budget than the other type of BTSs it is safe to use

resources of both types of BTSs for immediate assignment.

The channel allocation algorithm in the BSC verifies the usability of a BTS

for initial SDCCH allocation from a BTS-specific parameternon BCCHlayer offset. The sign of the parameter value indicates if the linkbudget of the BTS is better or worse than that of the BCCH BTS of the

segment.





38/80

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

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 parameternon BCCH layeroffset.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.

Selection of TRX, RTSL and channel

After selecting the BTSs from which the SDCCH can be allocated, the

channel allocation algorithm makes the selection of TRX, RTSL and

channel. The principles of selecting the TRX, RTSL and channel are

described below:

The channel allocation algorithm divides the BTSs into groups according

to their types.

. BTSs of same type as BCCH BTS form one group

. BTSs of 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.


Multi BCF Control


39/80

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. Thechannel 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. SDCCH channel from BCCH TRX is allocated

only if there are no idle SDCCHs in other TRXs at all.

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 reconfiguration is applied only in immediate assignment

phase, not in handovers. For more information, see Radio Channel

Allocation.





40/80

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 procedure. If the TRX where the call is maintained is not

currently blocked, the search procedure differs from the basic one in the

following ways:

. the search procedure is started only if a different SDCCH RTSL than

the serving one is defined in the BTS

. the call-serving TRX is accepted only if other TRXs containing free

SDCCH channels are not available

. a channel in the call-serving RTSL is never selected

If the call-serving TRX is blocked, the basic search procedure is used.

TCH allocation in segment environment

The basic difference between the TCH allocation in a multi BCF segment

and in a single BTS cell is that the target of a TCH request in a segment is

a set of BTSs instead of a single BTS. Also in a BSC internal inter-cell

handover the target cell list contains segments instead of BTSs.

For the TCH allocation algorithm the segment concept brings some issues

to be taken into account when selecting a free TCH resource for a service

request, such as the loads of the BTSs and the possibility of separate

interference recommendations for different BTS site types. All existing

rules for selecting a TCH in a single BTS cell (see Radio channel

allocation) are valid also between BTSs in a segment cell.

RX level based TCH resource usability evaluation

The channel allocation algorithm can perform the RX level based TCH

resource usability evaluation depending on the value of the parameterRX

level based TCH access. If the RX level based TCH access method isin use the resource usability information set by the handover algorithm is

bypassed. If the value of the parameterRX level based TCH access is1, 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.


Multi BCF Control


41/80

This description introduces a method in which usability of different BTS

site types is based on information set by the handover algorithm.

Search of a single slot TCH and Multi BCF Control

The BSC starts the TCH search procedure by selecting the BTSs to be

examined according to the acceptable BTS site types in the prevailing

radio conditions. In call setup and BSC internal handover the allowed base

station types are defined based on the measurement result of the BCCH

layer of the target segment. For the non-BCCH layer resource usability

decision a signal level estimate is used. The estimate is derived from the

BCCH layer measurement with the BTS-specific non BCCH layeroffset parameter. This estimate is further compared to a thresholdparameter. 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 BCCHlayer offset parameter in the BCCH BTS and in the non-BCCH layerBTS 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.

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 parameterBTS load in SEG

2. The interference band of an idle channel, TRX prioritisation in TCH

allocation and the channel type

3. The circuit switched territory load of a BTS

4. Round robin of the BTSs

Load of a BTS is based on load conditions in the BTS and on the

parameterBTS load in SEG of each BTS. The principle is to keep theload of a BTS within the limit defined by the parameterBTS load in SEG.For channel search the BSC divides the BTSs to different load groups:





42/80

1. BTSs with load underBTS load in SEG

2. BTSs with load between BTS load in SEGand the highest BTSload in SEGvalue of the segment

3. BTSs with load above the highest BTS load in SEGvalue of thesegment

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 preference

between the BTSs of different BTS site types is:

1. Talk-family BTS

2. MetroSite BTS

3. UltraSite BTS/ Flexi EDGE BTS

The different BTS types have different recource 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 examinedwithin 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

recommendation 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 interference bands with and without interference

level recommendation.


Multi BCF Control


43/80

Figure 2. Different interference levels with BSC recommendation 2 and

without recommendation when searching for full-rate TCHs

If there are still several candidate BTSs after applying the TRX

prioritisation in TCH allocation (see chapter TRX prioritisation in TCH

allocation), or when no prioritisation is defined, the final selection between

BTSs is made according to the circuit switched territory load in them. The

BSC selects the one with the lowest load using the round robin method sothat 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 therecommendation is present for the BCCH BTS and the BCCH TRX is

preferred in TCH allocation and also if the allocation 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.

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





44/80

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 itsinterference 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 preferred, 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 segment. The preference

between the two non-BCCH frequency layers is made in following way:

1. If BCCH is on PGSM900 frequency band then GSM1800 is preferred

to EGSM900

2. If BCCH is on GSM1800 frequency band then EGSM900 is preferred

to PGSM900

GPRS

GPRS is a BTS-specific application software in a segment environment

and thus there are independent 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 territory downgrade based on the defined safety margins, is

skipped if there is another candidate 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 segmentare busy, the channel is allocated in the GPRS territory taking into account

the following criteria and in order:

1. GPRS territory type according to PCU recommendation

2. Load according to parameterBTS load in SEG

3. Dedicated GPRS territory size

4. Default GPRS territory size


Multi BCF Control


45/80

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 GPRSterritories and recommends usage of the one with lower load.

For the load comparison with the BTS load in SEGparameter the GPRSchannels are handled as occupied channels. If the load of the BTS is

above the highestBTS load in SEGvalue of the segment and the highestBTS load in SEGis under 100% then in the TCH search a Talk-family BTSis preferred to an UltraSite BTS.

If there are still several candidates after having selected between GPRS

and EGPRS and after having compared loads of the chosen type of BTSs,

the selection is made according to the GPRS territory size of different

BTSs. In this case the BTS with the smallest dedicated GPRS territory and

after that the smallest default GPRS territory is chosen. This is done

because it is reasonable to save some larger territories for GPRS rather

than several smaller ones. For more information, see (E)GPRS in BSC.

Multi slot allocation and Multi BCF Control

In multislot allocation for High Speed Circuit Switched Data (HSCSD) call

requests for multiple TCH/Fs in a TRX can be allocated. HSCSD call

configurations of up to four TCH/Fs are possible. In this allocation method

the applied principles somewhat differ from those in single slot allocation,

but basically the same segment-specific rules are valid as in a single slotTCH 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 basedon 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 channelconfiguration fulfilling the request best is selected.

3. Load according toBTS load in SEG (see Search of a single slotTCH and Multi BCF Control).

4. If there are both BTSs with and BTSs without the BSC interference

band recommendation the ranking of the BTSs is:





46/80

. A TSL gap without any interference in a BTS that has no

interference band recommendation and a TSL gap within therecommendation 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 interference band recommendation set by the

BSC.

. The last choice is a TSL gap that does not meet the

interference band recommendation set by the BSC.

5. The circuit switched territory load of a BTS.

6. Round robin method of the BTSs.

Overview of Multi BCF Control in BSC


Multi BCF Control


47/80

5 Handover algorithm and Multi BCFControl

SDCCH resource usability evaluation in Multi BCF Control

Intra-cell SDCCH handover

In cases where the BSC starts an intra SEG SDCCH handover due to a

traditional criterion, the usability of different resource types in the segment

is evaluated according to the reported downlink signal level and the nonBCCH layer offset parameters of different BTSs in the segment. Theused 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 offsetvalue of the BTS.

Internal inter-cell SDCCH handover

When the BSC has defined a need for an inter-cell handover based on the

measurements 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 parameternonBCCH layer offsetfor different resource types in the segment accordingto 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 adjacentsegment must exceed in order for the handover to the adjacent segment to

become possible.

External SDCCH handover





48/80

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 theUltraSite resources of the segment. This is because the radio link

measurements with which the usability of the possible Talk-family

resources are defined are not available on the target side of the handover.

On the other hand, if the BCCH of the target segment is in a Talk-family

BTS also UltraSite resources are applicable for external handover in

addition to the BCCH resource type resources because of the wider

coverage of the UltraSite resources.

TCH resource usability evaluation in Multi BCF Control

The algorithm performing the TCH resource usability evaluation is

dependent on the value of the parameterRX level based TCH access.The handover algorithm performs the TCH resource usability evaluation

during call setup only when the parameterRX level based TCH accesshas 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.

IfRX level based TCH access has the value 2 the handover algorithmdoes 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, itdefines the usability of possible other site type BTSs of the segment for the

MS in the current circumstances. In this definition procedure the BSC uses

the BTS-specific parameternon BCCH layer offsetto get an estimationof the other resource type than BCCH layer based on measurements

made on BCCH layer. The estimate is compared to a segment level

parameterrxlev access min. If the condition

RXLEV_DL - non BCCH layer offset>= rxlev access min

is fulfilled, the use of other resource type than BCCH TCH resources is

reasonable.

Intra-cell TCH handover

In cases where the BSC starts an intra-SEG TCH handover due to a

traditional criterion, the usability of different resource types in the segment

are evaluated according to the reported downlink signal level and thenonBCCH layer offset parameters of different BTSs in the segment. Theused formula for the usability is

RXLEV_DL - non BCCH layer offset>=rxlev access min


Multi BCF Control


49/80

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 byadding up the serving TCH measurement result and the non BCCH layeroffset value of the BTS.

Internal inter-cell TCH handover

When the BSC has defined a need for an inter-cell handover based on the

measurements 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 parameternonBCCH layer offset for different

multi bcf control

Documents