Ned

Radio Network ConfigurationManagement

DN9813999Issue 18-0 en

# Nokia Corporation 1 (43)

BSC3119Nokia BSC/TCSM, Rel. S12, ProductDocumentation, v.1

The information in this document is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This document is intended for the useof Nokia's customers only for the purposes of the agreement under which the document issubmitted, and no part of it may be reproduced or transmitted in any form or means without theprior written permission of Nokia. The document has been prepared to be used by professionaland properly trained personnel, and the customer assumes full responsibility when using it.Nokia welcomes customer comments as part of the process of continuous development andimprovement of the documentation.

The information or statements given in this document concerning the suitability, capacity, orperformance of the mentioned hardware or software products cannot be considered binding butshall be defined in the agreement made between Nokia and the customer. However, Nokia hasmade all reasonable efforts to ensure that the instructions contained in the document areadequate and free of material errors and omissions. Nokia will, if necessary, explain issueswhich may not be covered by the document.

Nokia's liability for any errors in the document is limited to the documentary correction of errors.NOKIA WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENTOR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARYLOSSES), that might arise from the use of this document or the information in it.

This document and the product it describes are considered protected by copyright according tothe applicable laws.

NOKIA logo is a registered trademark of Nokia Corporation.

Other product names mentioned in this document may be trademarks of their respectivecompanies, and they are mentioned for identification purposes only.

Copyright © Nokia Corporation 2007. All rights reserved.

2 (43) # Nokia Corporation DN9813999Issue 18-0 en

Radio Network Configuration Management

Contents

Contents 3

List of tables 4

List of figures 5

Summary of changes 7

1 Overview of radio network configuration management 9

2 Functionality of radio network configuration management 132.1 Administrative and operational state of the radio network object 182.2 Procedures in radio network fault conditions 212.3 Interaction of radio network configuration management with other function

classes 222.4 Capacity of the radio network 22

3 User interface to radio network configuration management 27

4 Background downloading of the radio network plan 354.1 Phases of changing a frequency plan 354.2 BSC-specific background data state 374.3 BTS background data state 394.4 Parameters with background data support 404.5 Restrictions in the background downloading of the radio network plan 414.6 User interface of the background downloading of the radio network

plan 424.7 File Based Plan Provisioning 43



Contents

List of tables



List of figures

Figure 1. Relations between logical radio network objects 17

Figure 2. State transition diagram for BSC-specific background data states 38

Figure 3. State transition diagram for BTS background data states 39



List of figures



Summary of changes

Changes between document issues are cumulative. Therefore, the latest documentissue contains all changes made to previous issues.

Changes made between issues 18 and 17–1

Added information about alternate plan download methods introduced in S12.

Updated Capacity of the radio network values.

Modified the Administrative and operational state of the radio network objectswith S12 level values.

Added introduction to File-Based Plan Provisioning (FBPP) and reference toFBPP system feature description.

Changes made between issues 17–1 and 17

Editorial changes.

Changes made between issues 17 and 16

New object collections GPRS Controls file GPC, Authorised Networks file ANEand Subscriber Groups file SG have been added. Information on LMUA, SMLCand RITTT objects has been updated. Capacity information has been updated.

Glossary has been removed.

The document has been revised throughout to comply with the latestdocumentation standards.



Summary of changes



1 Overview of radio network configurationmanagement

The Radio Network Configuration Management in the BSC network element is afunction class of the DX 200/GSM system. It provides the operator with themeans of controlling the permanent radio network configuration data stored in theBSC.

The function class offers the operator the means to create and delete logical radionetwork object instances in the BSS Radio Network Configuration Database(BSDATA) and to modify radio-network-related parameters specific to each radionetwork object. With the help of this function class the user can display thelogical radio network configuration and parameters of the BSC.

The function class stores the BSS radio network data in the BSDATA. It informsthe applications in the BSC about the modifications of the radio networkparameters maintained in the BSDATA. In addition to this, the function classsupervises that the modifications in the logical radio network configuration or inthe parameters maintained in the BTS network element are passed to the BTSsite. The logical radio network data is transferred to the BTS site via the Abisinterface in the initialisation phase of the BTS and always during the normalworking state of the BTS site when the operator modifies the BSS radio networkdata common to the BSC and the BTS.

The BSS radio network data can be managed locally in the BSC site by means ofthe local MMI or in Nokia NetAct. The NetAct and BSC radio networkmanagement units communicate with each other via the Q3 interface. Themodifications to the radio network parameters are updated in NetAct. Themodified parameters are stored in the BSDATA by means of the BSC's localMMI.

Nokia NetAct is especially useful in performing mass operations. For example,you can transfer a new parameter plan from an external planning system toNetAct and save the plan in the NetAct database in the form of named parametersets. In the implementation phase, you can download these parameter sets to theBSS in one mass operation. NetAct automatically locks and unlocks the managed



Overview of radio network configuration management

objects. NetAct also makes it possible to combine the BSS and networksubsystem (NSS) management so that the location area (LA) and cell identity (CI)changes made in the BSS are automatically updated in the NSS. NetAct alsoprovides efficient tools for rehosting a BTS site to another BSC.

In the S12 level system configuration, the BSS radio network data can betransferred to the BSC using File Based Plan Provisioning (FBPP). In FBPP,radio network plans, in XML file format, are transferred to the BSC using the FileTransfer Protocol (FTP) or File Transfer, Access, and Management (FTAM) datatransfer protocols.

For more information on File Based Plan Provisioning, see File Based PlanProvisioning System Feature Description in the BSS documentation set.

Other aspects of radio network administration, such as cell broadcast handling,GSM timer and BSC parameter handling, BTS alarms handling as well as BCFhardware database and software build handling are discussed in their individualsections of the library.

Related topics

. Functionality of radio network configuration management

. User interface to radio network configuration management

. Background downloading of the radio network plan

Instructions on radio network management in Radio NetworkAdministration

. Creating D-channels on Abis interface

. Adding a new BTS site under the BSC

. Adding a new BTS to the BSC

. Adding a new TRX to the BTS

. Deleting network elements

. Modifying the Location Area (LA) or the Cell Identity (CI) of a BTS

. Modifying the BTS site type

. Activating the hopping modes of a BTS

. Modifying the BCCH frequency

. Modifying the frequency of other than the BCCH TRX

. Modifying the O & M signalling link or its ET-PCM



. Modifying the telecom signalling link or ET-PCM of the TRX

. Modifying the radio network frequency plan by using background loading

. Adding an external input and output text (Nokia MetroSite, Nokia UltraSiteand Nokia Flexi EDGE only)

. Errors in radio network configuration



Overview of radio network configuration management



2 Functionality of radio networkconfiguration management

BSS Radio Network Configuration Database (BSDATA)

The BSDATA contains the permanent data of the BSS radio network. It providesother processes with the means of updating and inquiring permanent data storedin the BSC and specific to the radio network.

The BSC's BSDATA is located in the Marker and Cellular Management Unit(MCMU), and it is backed up with the disks of the Operation and MaintenanceUnit (OMU). It consists of the following radio network objects:

. Base Station Controller (BSC)

The BSC object collection contains parameters specific to the Base StationController. There is only one object of this type in the database.

. BCCH Allocation Frequency List (BA) <option>

The BCCH allocation for idle mode contains a list of carrier frequencies,which can be used in cell selection and reselection by the MS. The BCCHallocation list can also be used in the active mode.

. Measurement BCCH Allocation List (MBAL) <option>

The measurement BCCH allocation list contains information on a list ofcarrier frequencies, which can be used in cell selection and reselection bythe MS. The information is used by Automated Planning Enhancements.

. Mobile Allocation Frequency List (MA)

The mobile allocation list contains a list of the frequencies that the cell usesin radio frequency (RF) hopping and DFCA.

. Base Control Function (BCF)

The BCF object collection contains parameters specific to the base controlfunction. The BCF is an entity handling the operational and maintenancefunctions in a base transceiver station. The BCF communicates with theBSC via the Abis O&M interface.



Functionality of radio network configuration management

The identification number of a BCF object is the index to the BCF objectcollection.

. Segment (SEG) / Base Transceiver Station (BTS)

The SEG/BTS object contains SEG and BTS-specific radio network data.

The identification number of a BTS object is the index of the BTS objectcollection.

A BTS's parameters are divided into two different groups: Commonparameters (segment-specific, which are used for all BTSs in a segment)and BTS-specific parameters.

A segment consists of at least one BTS or a group of BTSs that are servedby one BCCH.

In case of sectorisation, there are several BTSs on one BTS site.

. Handover Control (HOC)

The HOC object collection contains handover-control-specific parameters.

A HOC object is indexed in the HOC object collection with thecorresponding BTS/SEG identification number.

. Power Control (POC)

The POC object collection contains power-control-specific parameters.

A POC object is indexed in the POC object collection with thecorresponding BTS/SEG identification number.

. Adjacent GSM Cell (ADJC)

The adjacent cell object collection contains adjacent-cell-specificparameters. There is an adjacent cell object for each adjacent cell.

. Transceiver (TRX)

The TRX object collection contains transceiver-specific parameters.

A transceiver is a BTS's unit, which is a combination of transmitting andreceiving equipment. The transceiver transmits and receives a radio carrierand handles baseband and frame functions.

. Radio Time Slot (RTSL)

A basic physical radio channel, the RTSL object collection contains radio-timeslot-specific parameters. There are eight timeslots in a TRX.

. Frequency Hopping System (FHS)



The FHS object collection contains parameters specific to the frequencyhopping system. The frequency hopping systems are defined for the BTS.When baseband (BB) hopping is used in a cell, the radio timeslots arelogically connected with the hopping systems. The BCCH time does nothop, but baseband hopping is possible on the BCCH transceiver for timeslots 1 to 7.

. Trunk Reservation Decision Threshold Table (TRK_TBL) <option>

The table contains the threshold values which are used when the operatorchooses the trunk reservation algorithm. The table for a call is selectedaccording to the BTS identification and the traffic type of the MS.

. External Input And Output Text (IO_TEXT)

The IO_TEXT object contains ASCII text which can be used asdescriptions of external inputs or outputs. The support of external inputsand outputs is valid for the Nokia MetroSite, Nokia UltraSite, and NokiaFlexi EDGE types of BTSs only.

. Routing Area (RA) <option>

The routing area object contains data that identifies the routing area and theidentifiers of NSEs using the routing area.

. Network Service Entity (NSE) <option>

The NSE object collection contains a group of the identifiers of NS_VCs inthe BSC.

. Packet Control Unit (PCU) <option>

The PCU object collection contains PCU-specific parameters.

. Packet Sevice Entity (PSE) <option>

The PSE object collection contains PSE-specific parameters.

. Network Service Virtual Connection (NS_VC) <option>

The network service virtual connection object contains data that is used toestablish an end-to-end virtual connection between the BSS and SGSNnetwork elements. There can be a maximum of four NS_VC objects foreach network service entity object.

. Dynamic Abis Pool (DAP) <option>

The Dynamic Abis Pool object contains information about cell allocationin the Abis interface.

. Serving Mobile Location Center (SMLC)




The SMLC object collection contains parameters specific to MSlocationing. There is only one object of this type in the database. TheSMLC object contains parameters for managing SMLCs (internal SMLCand stand-alone SMLC).

. Location Services Element (LCSE) <option>

Parameters needed for locationing are defined in the LCS element object.The LCS element contains lobe-related parameters which describe theBCCH lobe.

. Location Management Unit Area (LMUA)

The LMU area is created for synchronisation purposes. The LMUA objectcontains the frame number offset and lmu tsl fn offsetparameters.

. WCDMA RAN cell (UADJC) <option>

Parameters needed for the WCDMA RAN adjacent cells of the segment aredefined in the UADJC object collection. Every WCDMA RAN cell hasone UADJC object.

. Location Area Code to Signalling Point Code (SPC) <option>

The object contains mapping information for the location area code ofinter-BSS neighbour cell and signalling point codes. A mapping listcontains SPCs (addresses of BSCs) that have cells on a certain locationarea.

. GPRS controls file GPC <option>

The GPC object collection contains the segment level packet dataparameters. The GPC object is created to the database with a segment id.

. Authorised Networks file ANE <option>

The ANE object collection contains authorised-network-specificparameters.

. Subscriber Groups file SG <option>

The SG object collection contains parameters specific to subscriber groups.

Relations between logical radio network objects

The following figure describes the object collections and the relations betweenthem in the BSDATA. In the figure, the object collections are described as boxesand object relations as lines. Arrows show the direction of the relation. Twoarrowheads show that the object can be linked to many objects.



Weak relations are marked with (W). A weak relation means that the destinationobject to which the relation points cannot exist without the source object and therelation to it. For example, a BTS cannot exist without a relation to an existingBCF. A discontinuous line indicates a computational relation.

Figure 1. Relations between logical radio network objects

In general, the user must create a higher level object instance in the BSDATAbefore the related lower level object can be created.

RABSC

io_text_users_of

BCF

base_stations_of

(W)

trk_users_ofTRK_TBL

ba_users_of

BTS/SEG

BA

ma_users_of

MA

POC

ma_users_super_of

freq_hopp_systems_of (W)

TRX

hopping_users_ofRTSL

transceivers_of (W)

radio_timeslots_of (W)

FHS

DAPdap_users_of

ADJC

UADJC

utran_adj_cells_of(W)

SMLC

LMUA

adjacent_cells_of(W)

SPC

MBAL

ma_unsynch_dfca_of

ma_users_dfca_of

IO_TEXT

HOC

GPC

SGANEsg_users_of

NSVC

NSE

PSE

ns_v_connections_of

nses_of

PCUpses_of pcus_of

LCSE

SMLC




The Frequency Hopping System (FHS) object instances are created implicitly inthe BSDATA when a BTS object instance is created by means of the MMI. TheRadio Time slot (RTSL) object instances are also implicitly created when therelated TRX object instance is created in the BSDATA.

HOC, POC, FHS and RTSL object instances cannot be removed independentlyfrom the BSDATA, but they are removed from the database when the userremoves the related higher level object instance (the BTS or TRX) from thedatabase by means of the MMI.

The administrative state of the BCFs, BTSs, TRXs and RTSLs can be definedindependently of the administrative state of the related objects.

The relation between DAP and TRX is created during the TRX's creation ormodification by giving the DAP id as a parameter.

A GPC object is created when the first BTS in the segment is created. A GPCobject is deleted when the last BTS in the segment is deleted.

An ANE object must be created before an SG object is created.

For an overview, see Overview of radio network configuration management.

For more information on BSDATA, see Overview of the BSS Radio NetworkConfiguration Database (BSDATA).

2.1 Administrative and operational state of the radionetwork object

Administrative state of the radio network object

The administrative state is the functional state of the radio network object fromthe operator's viewpoint. Only the operator can modify the administrative statethrough the MMI.

The administrative state is maintained for the following radio network objects:BCF, BTS, TRX and RTSL.

The administrative state can have the following values:

. LOCKED

The object is not in the active radio network of the BSS and it is blockedout of use from the viewpoint of the BSS call control functions.



. UNLOCKED

The object is in the active radio network of the BSS. From the viewpoint ofthe call control functions, the UNLOCKED radio network resource isavailable if the related higher-level objects are also UNLOCKED.

. SHUTTING DOWN

The object is going to be LOCKED within a time limit. The administrativestate value SHUTTING DOWN is supported only for the BTS and theTRX object.

Operational state of the radio network object

The operational state represents the functional state of the radio network objectfrom the viewpoint of the BSS radio network management. Only the radionetwork management function class of the BSS can modify the operational state.

The operational state is maintained for the following radio network objects: BCF,BTS, TRX and RTSL.

The operational state can have the following values:

. BLOCKED - BCF FAULT (BL-BCF)

The object is blocked out of use due to a fatal BTS-site-wide failure.

. BLOCKED - BTS FAULT (BL-BTS)

The object is blocked out of use due to a fatal sector-wide failure on theBTS site.

. BLOCKED - FU/CU FAULT (BL-CF)

The object is blocked out of use due to both a fatal Frame Unit (FU) and afatal Carrier Unit (CU) failure on the BTS site.

. BLOCKED - CLOCK (BL-CLK)

The object is blocked out of use due to a clock synchronisation failure onthe BTS site.

. BLOCKED - CU FAULT (BL-CU)

The object is blocked out of use due to a fatal Carrier Unit (CU) failure onthe BTS site.

. BLOCKED - DIAGNOSTIC (BL-DGN)

The object is blocked temporarily out of use due to BTS diagnosticactivities.




. BLOCKED - FLOATING (BL-FLO)

The logical TRX is blocked out of use on the sector because the physicalTRX is switched to another sector of the BTS in order to replace a faultyTRX.

. BLOCKED - FU FAULT (BL-FU)

The object is blocked out of use due to a fatal Frame Unit (FU) failure onthe BTS site.

. BLOCKED - POWER (BL-PWR)

The object is blocked out of use due to a mains power failure on the BTSsite.

. BLOCKED - RSL FAULT (BL-RSL)

The object is blocked out of use due to a telecom Abis D-channel linkdisconnection.

. BLOCKED - RESET (BL-RST)

The logical radio network object is blocked out of use due to the reset ofthe corresponding physical radio network equipment.

. BLOCKED - SHUTTING DOWN (BL-SHD)

The object will be blocked out of use within a time limit. New call attemptsare prohibited via an object in the BL-SHD state and forced handovers areexecuted for ongoing calls via the object.

. BLOCKED - BCSU RESET (BL-SU)

The object is blocked out of use due to a BCSU unit reset on the BSC.

. BLOCKED - SWITCHOVER (BL-SWO)

The object is blocked out of use due to an ongoing background dataswitchover, or plan activation.

. BLOCKED - SYSTEM (BL-SYS)

The radio network management function class of the BSC has blocked thelogical object out of use due to ongoing radio network recovery actionswhich are triggered because of fatal faults in the BSS radio network.

. BLOCKED - TRX FAULT (BL-TRX)

The object is blocked out of use due to a fatal TRX-wide failure on theBTS site.

. BLOCKED - RTSL FAULT (BL-TSL)



The object is blocked out of use due to a fatal Radio Time slot (RTSL)wide failure on the BTS site.

. BLOCKED - TESTING (BL-TST)

The object is blocked temporarily out of use due to radio network testingactivities.

. BLOCKED - USER (BL-USR)

The operator has blocked the object out of use. The administrative state ofthe object is LOCKED or the related higher-level object is LOCKED.

. BLOCKED - WAITING FOR AUTOCONFIGURATION (BL-WAC)

The object is blocked out of use, because it is waiting for theAutoconfiguration.

. WORKING (WO)

The object is in the normal function state. From the viewpoint of the BSScall control functions, the WORKING radio network resource is availablefor call control use.

2.2 Procedures in radio network fault conditions

The MML program block executes main level checks for management commandparameters entered by the operator. If necessary, the MML rejects the radionetwork data modification request and generates the corresponding error code inthe operator's output device. If a command can be executed, the MML programsends a management task to the radio network management application, whichalso verifies the data given in the MML command. The BSDATA is updated if thecommand is acceptable.

The BSDATA is not updated and the command is rejected if the given data isinvalid. This happens also when the system notices a discrepancy between thegiven data and the existing data in the database. When this occurs, the reason forrejecting the command is displayed as a response to the given MML command.

When the BSDATA is first updated successfully, some of the radio networkconfiguration data is also distributed to the call control applications of the BSCand the BTS site according to the BSDATA through the Abis O&M or TelecomD-channels. If there is an error in the distribution of the modified configurationdata inside the BSC or from the BSC to the BTS site, the reason for the failure isdisplayed as a response to the given MML command. In most cases, if there areerrors in updating the BTS site, the corresponding error notice is also generated.




If there are errors in distributing the radio network configuration data inside theBSS, the modified data remains in the BSDATA and, therefore, there is adiscrepancy between the BSDATA and the applications in the BSC or adiscrepancy between BSDATA and the BTS site.

The operator has to solve these kinds of discrepancies that concern the radionetwork configuration data stored in the BSS with the help of the MMI. Forfurther details on solving discrepancies, see Errors in radio networkconfiguration.

2.3 Interaction of radio network configurationmanagement with other function classes

The Radio Network Configuration Management function class receives the localMMI-initiated radio network configuration management tasks of the BSC via aman-machine interface (MMI) system. Nokia NetAct gives BSS radio networkconfiguration management tasks using Q3 Interface Adaptation in NetworkElement. Locally made modifications in the BSS radio network configuration aretransferred to Nokia NetAct. The Radio Network Configuration Managementfunction class reserves and releases radio network resources using services of theRadio Network Recovery and State Management function class.

The function class uses services of the operating system, I/O system, file systemservices, database management system, database disk updating system and D-channel link administration services.

The handling of routing areas, network service entities and network servicevirtual connections is described in (E)GPRS in BSC.

2.4 Capacity of the radio network

The maximum capacity of the radio network depends on the BSC hardwareconfiguration and corresponding options. The maximum capacity of theBSDATA limits the number of radio network objects that can be created into agiven BSC. The capacity of the BSDATA is:



. The maximum number of adjacent cells of the BTS is 32, or 31 if eitherCommon BCCH Control <option> or the ISHO support in BSC <option>is used, or 30 if both Common BCCH Control <option> and ISHO supportin BSC <option> are used. However, a certain cell can be defined as anadjacent GSM cell for maximum 64 cells under the BSC. Common BCCHControl allows to include TRXs in different GSM frequency bands intoone cell with a BCCH allocated from one band used in the cell.

. The maximum number of adjacent GSM cells in the database is 64000 forBSC3i, and 21120 for BSC2i and BSCi.

. The maximum number of BCCH allocation frequency lists in the databaseis 2001 for BSC3i, and 661 for BSC2i and BSCi. The maximum number offrequencies on a list is 32, or 31 if either Common BCCH Control<option> or ISHO support in BSC <option> is used, or 30 if both CommonBCCH Control <option> and ISHO support in BSC <option> are used.

. There can be only one measurement BCCH allocation list in the database<option>.

. The maximum number of mobile allocation frequency lists in the databaseis 2033 and the maximum number of DFCA MA lists in the database is 32.Altogether, the maximum number of MA lists in the database is 2033. Themaximum number of frequencies on a MA list is 63 and on a DFCA MAlist 32.

. The maximum number of Trunk Reservation Decision Threshold Tables inthe database is 65 <option>.

. The maximum number of external input and output texts in the database is201.

. The maximum number of routing areas in the database is 128 <option>.

. The maximum number of network service entities in the database is 800and the maximum number of network service entities in a routing area isalso 800 <option>.

. The maximum number of network service virtual connections in thedatabase is 1600 <option>.

. The maximum number of BTSs belonging to one NSE in a BSC is up to128 depending on a PCU variant.

. The maximum number of NS_VCs belonging to one NSE in a BSC is 4.

. The maximum number of Dynamic Abis Pools in the database is 1601 forBSC3i, and 471 for BSC2i and BSCi. The maximum number of TRXsbelonging to one DAP is 20 <option>.

. The maximum number of LCS elements in the database is 3000 for BSC3i,and 1024 for BSC2i and BSCi.




. The maximum number of LMU Areas in the database is 2000 for BSC3i,and 660 for BSC2i and BSCi <option>.

. The maximum number of WCDMA RAN adjacent cells is 32 for onesegment <option>.

. The maximum number of adjacent WCDMA RAN cells in the database is64000 for BSC3i, and 21120 for BSC2i and BSCi <option>.

. The maximum number of SPCs (location area code to signalling pointcode) in the database is 64 <option>.

. The maximum number of Authorised Networks in the database is 10<option>.

. The maximum number of Subscriber Groups in the database is 129<option>.

. The maximum number of GPRScontrol files in the database is 2001 forBSC3i, and 661 for BSC2i and BSCi <option>.

The administrative numbering of the BCFs, BTSs, and SEGMENTS is limited tothe range from 1 to 2000. The available value range depends on the BSChardware configuration and the corresponding options. The maximum length ofthe ASCII strings called BTS NAME and SEG NAME is 15 characters. A BTSname or SEG name can contain the characters from A to Z and the numbers from0 to 9.

The administrative numbering of the TRXs as well as BTSs is limited to the rangefrom 1 to 16 under the BCF.

The maximum length of the ASCII string defining the network service virtualconnection name is 10 characters. The name can contain characters from A to Zand numbers from 0 to 9. The first character must be a letter.

The maximum length of the ASCII string defining the authorised network nameis 15 characters. The name can contain characters from A to Z and numbers from0 to 9. The first character must be a letter.

The maximum length of the ASCII string defining the subscriber group name is15 characters. The name can contain characters from A to Z and numbers from 0to 9. The first character must be a letter.

The maximum number of radio network management MMI sessions in a BSC islimited to one active session at a time.



There can be only one active radio network MMI session or recovery action on aBCF at a time for all site types except the Nokia PrimeSite. In the case of a NokiaPrimeSite, there can be only one active radio network MMI session or recoveryaction on a BTS.

If there are radio network recovery actions activated on the BCF/BTS, the radionetwork management system rejects the local MMI commands of the BSC orcommands given by Nokia NetAct concerning the radio network configuration orparameters under the BCF.






3 User interface to radio networkconfiguration management

The main functions and related MML command groups of the radio networkconfiguration management in the BSS are:

Base Station Controller (BSC) handling (EE)

The system creates the BSC object in the BSDATAwhen the system is started forthe first time. The system generates the default values for the BSC-specificparameters when the BSC is created. The operator can modify and interrogateBSC-specific radio network parameters stored in the BSDATA using thecommands of the command group EE.

Location Area Code to Signalling Point Code (SPC) handling (EE)

The location area code to signalling point code (SPC) can be created andmodified using the commands of the command group EE.

Base Control Function (BCF) handling (EF)

The commands of the command group EF are used to create and remove a BCFobject in the BSDATA, modify BCF-specific radio network parameters, reset aBCF and interrogate BCF-specific radio network data stored in the BSC.

In addition, with this command group the operator can attach a text string to anexternal input and output of BCF, modify it, and set external input parameters ofBCF.

Base Transceiver Station (BTS) handling (EQ)

The commands of the command group EQ are used to create and remove a SEG/BTS object in the BSDATA. With the commands of this command group theoperator can also modify the SEG/BTS specific radio network parameters andinterrogate the SEG/BTS-specific radio network data stored in the BSC.



User interface to radio network configuration management

With the commands of this command group a SEG/BTS object instance can bereferred to either with the SEG/BTS number or an ASCII string called SEGNAME of BTS NAME. The value range depends on the BSC hardwareconfiguration and the corresponding options.

The BTS object contains the following data which is also defined in the adjacentcell object:

. Network Colour Code (NCC)

. BTS Colour Code (BCC)

. Max MS transmitting power in cell for 850 and GSM 900bands (PMAX1)

. Max MS transmitting power in cell for GSM 1800/1900bands (PMAX2)

. Cell type (CTY) <option>

. GPRS MS max. transmission power when accessing a packetcontrol channel in the cell (GTXP) <option>

. GPRS Traffic Enabling (GENA) <option>

. Routing area code of BTS (RAC) <option>

. The HCS (hierarchical cell structures) priority forthe cells (PRC) <option>

. Signal strength threshold for applying HCS in GPRSreselection (HCS) <option>

. Maximum transmission power an MS may use when accessinga CCH in the cell (TXP1x00) <option>

. Maximum transmission power an MS may use when accessinga PCCCH in the cell (GTXP1x00) <option>

When a BTS configuration or data are changed via local MMLs in a way thataffects the existing adjacent cell definitions of the same BSS, the radio networkconfiguration management checks the validity of the common data between theSEG/BTS object and the existing adjacent cell definitions. If needed, the functionclass automatically updates the adjacent cell definitions according to the SEG/BTS object data. The system returns a notice as a response to the MMLcommand, if the adjacent cell data is modified automatically in connection with aSEG/BTS data modification command.



When the SEG/BTS object data is modified, the function class also checks thatthe combinations of the parameters NCC, BCC, and BCCH frequency areunique within the adjacent cell definitions associated with the modified SEG/BTS. The system returns a warning notice as a response to the MML command, ifthe NCC, BCC and BCCH frequency of the SEG's or BTS's adjacent cells arenot unique. The duplicated adjacent cell definitions in the database can be foundand corrected by using the commands in the adjacent cell handling commandgroup (EA).

The function class does not check the validity of this kind of common databetween the SEG/BTS and the adjacent cell objects, if Nokia NetAct initiates theconfiguration management commands. In such a case, it is the responsibility ofNetAct to handle the validity of the given data.

Transceiver (TRX) handling (ER)

The commands of the command group ER are used to create and delete the TRXobject, and change and output parameters and states of the TRX and the radiotime slot objects in the BSS Radio Network Configuration Database (BSDATA).

In the case of a BCCH TRX, the absolute radio frequency number (ARFCN) ofthe TRX has to be in line with the adjacent cell definitions of the associatedBTSs. When the ARFCN of the BCCH TRX is changed via the BSC's localMMI, that is, the BCCH frequency of a BTS is modified, the existing adjacentcell definitions in the BSDATA associated with the BTS are checked by thisfunction class. If necessary, the function class automatically updates the adjacentcell definitions in the BSDATA according to the TRX object data. The systemreturns a notice as a response to the MML command if the adjacent cell data ismodified automatically in connection with the TRX data modification command.

When a new BCCH TRX is created or the ARFCN of the BCCH TRX is changedwith the commands of the TRX handling MMLs, the function class also checksthat the combinations of the parameters Network Colour Code (NCC),Base Station Colour Code (BCC) and BCCH frequency remain uniquewithin the adjacent cell definitions associated with the modified BTS. The systemreturns a warning notice as a response to the MML command, if the NCC, BCCand BCCH frequency of the BTS's adjacent cells are not unique. Theduplicated adjacent cell definitions in the BSDATA can be found and correctedwith the commands in the adjacent cell handling command group (EA).

This function class does not check the validity of this kind of common databetween the BTS/TRX and adjacent cell objects if the configuration managementcommands are initiated by Nokia NetAct. In such a case it is the responsibility ofNetAct to handle the validity of the given data.




Adjacent Cell (ADJC) and WCDMA RAN Adjacent Cell (UADJC) handling(EA)

The commands of command group EA are used to handle adjacent GSM cellparameters, adjacent WCDMA RAN cell parameters, adjacent GSM cellrelations, and adjacent WCDMA RAN cell relations stored in the BSDATA. Anadjacent GSM cell may be located in any BSS of any public land mobile network(PLMN). Similarly, an adjacent WCDMA RAN cell may be located in any RNCof the public land mobile network (PLMN).

The adjacent cell relations created with these commands are unidirectional. If, forexample, BTS-2 is defined to be the adjacent cell of BTS-1, handovers fromBTS-1 to BTS-2 are supported. Handovers from BTS-2 to BTS-1 are notsupported unless BTS-1 is also defined to be an adjacent cell of BTS-2.

The adjacent GSM cell object data in the BSDATA contains the following datathat is common and has to be in line with the data of the associated adjacent SEG/BTS:

. BCCH frequency (FREQ)

. Network Colour Code (NCC)

. BTS Colour Code (BCC)

. Max MS transmitting power in cell for GSM 850/900 bands(PMAX1)

. Max MS transmitting power in cell for GSM 1800/1900bands (PMAX2)

. Cell type (CTY) <option>

. Maximum transmission power which a GPRS MS may use whenaccessing a packet control channel on GSM800 or GSM900frequency band in the cell (GTXP1)<option>

. Maximum transmission power which a GPRS MS may use whenaccessing a packet control channel on frequencyGSM1800 or GSM1900 band in the cell (GTXP2) <option>

. GPRS Traffic Enabling (GENA) <option>

. Routing area code of BTS (RAC) <option>

. The HCS (hierarchical cell structures) priority forthe cells (PRC) <option>

. Signal strength threshold for applying HCS in GPRSreselection (HCS) <option>



If an intra-BSS adjacency is created or modified through the local MMLs, thesystem checks the mutual validity of the given adjacent GSM cell data and theassociated BTS/TRX object specific data in the BSDATA. The adjacent GSM cellhandling command is rejected and the system returns an error code as a responseto the MML command if the above-mentioned parameters are not in line with theSEG/BTS and TRX data in the BSDATA.

When the BTS/TRX configuration or data, respectively, are changed with thelocal MMLs in a way that affects the existing adjacent GSM cell definitionsassociated with the BTS, the validity of the common data between the BTS/TRXobject and the existing adjacent GSM cell definitions is checked. If necessary, thefunction class automatically updates the adjacent GSM cell definitions accordingto the BTS/TRX object data. The system returns a notice as a response to theMML command if the adjacent GSM cell data is modified automatically inconnection with the BTS data modification command.

The combination of the adjacent GMS cell parameters - Network ColourCode (NCC), BTS Colour Code (BCC) and BCCH frequency - forms anadjacent GSM cell identifier which is used over the Radio interface by the callcontrol applications of the BSC. When an adjacent GSM cell is created or theadjacent GSM cell data is modified with a local MMI, the function class checksthat the combinations of the parameters NCC, BCC and BCCH frequencyremain unique within all the adjacent GSM cell definitions associated with themodified BTS. Similar checks are also done when the NCC, BCC or BCCHfrequency of a BTS is modified with the BTS/TRX handling MMLs. Thesystem returns a warning notice as a response to the MML command if the NCC,BCC and BCCH frequency of the adjacent GSM cells associated with the BTSin question are not unique.

This function class does not check the validity of this kind of common databetween the BTS/TRX and the adjacent GSM cell objects if the configurationmanagement commands are initiated by Nokia NetAct. In such a case, NetAct isresponsible for handling the validity of the given data.

Power Control Parameters (POC) handling (EU)

The commands of the command group EU are used to create a power controlobject in the BSDATA. The power control object contains data which is used bythe BSC to control the power usage of a BTS and Mobile Stations (MS) locatedin the BTS area. The commands of this command group also enable the user tomodify power control parameters of the SEG/BTS and to interrogate powercontrol radio network data stored in the BSC.




Handover Control Parameters (HOC) handling (EH)

The commands of the command group EH are used to create a handover controlobject in the BSDATA. The handover control object contains the data which isused by the BSC to control the handover procedure of the BTS. The commandsof this command group can also be used for modifying the handover controlparameters and interrogating the handover control radio network data stored inthe BSC.

BCCH Allocation Frequency List (BA) handling (EB) <option>

The commands of the command group EB are used to create, modify, delete anddisplay BCCH frequency list objects in the BSDATA.

With the Double BCCH Allocation List application software it is possible todefine a list of BCCH carriers to be used in cell selection and reselection by theMS in the idle state.

The list is sent to the MS in System Information Message type 2 on the BCCHand the MS may store it when powering down. Now the MS need not searchthrough the whole band when powering up. If the list contains all the BCCHcarriers of a certain geographical area of a PLMN, the MS can use it to search thesuitable radio frequency channels quickly in order to camp on a cell.

The operator can define whether a particular cell uses one of the Idle State Listsor the Neighbour Cell List of its own in System Information Message 2 on theBCCH. If the cell is not attached to any of the Idle State Lists, the Neighbour CellList is used as a default list. The frequency of the BCCH carrier of the cell itself isalways added to the BCCH allocation in System Information message 2.

Another selection can be made concerning the list in System InformationMessage 5 on the SACCH. The default is the Neighbour Cell List, but if an IdleState List is attached to the cell to be used in System Information Message 2, thesame list can also be used in System Information Message 5 on the SACCH.

If one of the Idle State Lists is selected to be used on the SACCH, it is possiblethat the list contains carrier frequencies that are not the BCCH frequencies of theactual handover neighbours. In this case, the MS measures signals on thesefrequencies but no handovers are attempted towards those unknown cells.

Attaching any of these lists to certain SEGs/BTSs is done with the commands ofthe EQ (Base Transceiver Station Handling) command group.

Mobile Allocation Frequency List (MA) handling (EB)

The commands of the command group EB are used to create, modify, remove anddisplay mobile allocation frequency list objects (MA) in the BSDATA.



MA lists are used in RF hopping BTSs and they can be attached to any BTS.

Any of these lists can be attached to a given BTS with the commands of the EQ(Base Transceiver Station Handling) command group.

DFCA Mobile Allocation Frequency List handling (EB)

The commands of the command group EB are used to create, modify, delete anddisplay DFCA mobile allocation frequency list objects in the BSDATA.

Routing Area (RA) handling (EB) <option>

The commands of the command group EB are used to create, modify, delete anddisplay routing areas in the BSDATA.

Trunk Reservation Decision Threshold Table (TRK_TBL) handling (ET)<option>

The commands of the command group ET are used to create and delete trunkreservation decision threshold tables, modify the decision threshold parametersand output the contents of the table(s).

The trunk reservation is an algorithm used in traffic channel allocation in order toallow the shared use of traffic channel resources of a BTS by GSM and MicroCellular Network (MCN) users. The algorithm is used to decide on traffic channelallocation if certain conditions prevail in the network. This is an applicationsoftware.

The algorithm is used if there are fewer than the predefined number of free trafficchannels in the cell and the threshold value for the number of free channels islower than the defined random value upper limit. Otherwise the algorithm doesnot restrict channel allocation.

The decision threshold table contains the parameters which are used by thealgorithm. The parameters are the random value upper limit and the thresholdvalue for each number of free traffic channels.

Background downloading of radio network plan

See section Background downloading of radio network plan.

Dynamic Abis Pool handling (DAP) (ES)

The commands of the command group ES are used for handling dynamic Abispools referring to a block of time slots reserved for Abis allocation, and Abisautoconfiguration pools.




Position Based Services handling (LCSE, LMUA) (EX)

The commands of the command group EX are used for handling the databaseobjects needed in MS locationing and synchronisation: SMLC, LCS elements,and LMU areas. The operations include creating and deleting the objects, andoutputting and modifying the parameters associated with them.

Authorised Networks (ANE) and Subscriber Group (SG) handling (E4)<option>

The commands of the command group E4 are used to create, modify, delete anddisplay Authorised Networks and Subscriber Group objects in the BSDATA.




4 Background downloading of the radionetwork plan

This functionality supports fluent changing of those BSS parameters that shouldbe consistent all the time in the entire network. Changing this kind of parametersusually requires that the change comes into effect at the same time throughout theentire network.

Typically, changing the frequency plan has this requirement. All the frequenciesmust be changed during a short period, otherwise serious handover problems andinterference may occur.

After testing the new plan, the operator may want to return to the old plan. Thisrequires a backup copy, which can be reactivated quickly. Backgrounddownloading of the radio network plan also offers a backup copy until thebackground data is altered or cleared again.


4.1 Phases of changing a frequency plan

A new plan is implemented in four separate phases. Once the downloading hasstarted, the BSC and Nokia NetAct will have consistent databases all the time.There is status information available that shows which phase the background datais in.

Background data cannot be operated during the activation phase.

Preparing database for background data downloading

The operator starts this phase by giving the preparation command EER. Thiscommand clears the background data in the BSC by removing the previous newdata or backup data. The command can be given from Nokia NetAct or in theBSC.



Background downloading of the radio network plan

Making a new plan

Background downloading of the radio network plan has no effect on the planmaking phase. Nokia NetAct imports a new plan from an external planningsystem into its databases. Nokia NetAct compares the plan with the old one andbuilds a set of required change commands. This phase produces background datacontaining the change data in NetAct or it may produce a BSC MML commandfile. If the network configuration changes after storing the original configuration,for instance, because of a recovery action in the BSC, NetAct takes the changesinto account when executing the downloading phase.

Downloading the new plan

Downloading of the new plan to the background data is done from Nokia NetActover the Q3 interface using normal CMISE primitives, or it can be done in theBSC by MML commands. Semantic cross-checkings are not automaticallyperformed before the activation.

In this phase, it is possible to display the contents of the background data, changeit further and run semantic cross-checkings. Note that there is only a selected setof parameters which can be managed through background data. The selected setmainly supports frequency plan modifications.

Activating the plan

The activation of the new plan is started by a switchover command from NokiaNetAct or in the BSC. In S12 level system configuration, the plan data, whichwere moved to new database tables in the BSC, are copied to BSDATA andactivated for use.

First, semantic cross-checking through the entire database is performed in theBSC. Then the BSC starts changing data between the active and the backgrounddata, cell by cell. An event is sent to NetAct about every change, the data isdistributed inside the BSC and finally it is sent to the BTS. The system avoidsblocking the radio network elements. If blocking is needed, the system minimisesthe blocking time.

Immediately after the BSIC or the BCCH frequency of a cell has been changed,the system updates the incoming adjacencies. That is done to allow incominghandovers as soon as possible.

Old active data, which is now in the background, stays there as backup data untilit is cleared by a preparation command or altered by a modification command. Aslong as the backup data is kept unchanged, the activation may be started again torestore the original network plan.

Activation may be stopped, continued and cancelled with a command.



4.2 BSC-specific background data state

The state information can be seen in Nokia NetAct and in the BSC. The state hasfive possible values: Clear, New, Activating, Activating-interrupted and Backup.

CLEAR

The value of all background parameters is "not defined". The background datapreparation command sets the background data to the CLEAR state. When thestate is CLEAR, downloading can be started, or a new background datapreparation command can be given.

NEW

After the first change has been done to a previously cleared background data, thesystem sets the state to NEW. Now the value of all background data is "notdefined". When the state is NEW, the downloading may continue, or a newbackground data preparation command can be given. The activation can beinitiated when the state is NEW.

ACTIVATING

After the activation command the system sets the background data to theACTIVATING state. When the activation is finished, the system changes the stateto BACKUP. When activation is going on, no other operation is allowed to thebackground data. If FBPP activation is ongoing, then the background dataactivation is denied.

ACTIVATING-INTERRUPTED

If the ongoing activation is interrupted by a command or if a system restart isperformed during activation, the system changes the background data state toACTIVATING-INTERRUPTED. The downloading may be continued or it can becancelled with a command. Other operations to the background data areprevented. If activation is continued, the system changes the background datastate back to ACTIVATING. If activation is cancelled, the system changes thestate to NEW.

BACKUP

When the state is BACKUP, a preparation command can be given to clear thebackground data. The operator can also modify the contents of the backgrounddata, after which the system changes the backup data state to NEW.

The operator can give the background data activation command to activate thebackup data back to active service.




Figure 2. State transition diagram for BSC-specific background data states

Explanations to the state transitions:

1. The first background data change is done.

2. The background data activation command (EEG) is given. The semanticcross-checking is run automatically by the system before the actualactivation.

3. The activation is finished.

4. The background data preparation command (EER) is given.

5. The backup data is modified.

6. The backup data is switched back to active with the background dataactivation command (EEG). The semantic cross-checking is runautomatically.

ACTIVATING

BACKUP

ACTIVATING-INTERRUPTED

7.

CLEAR

1. 5.

NEW

9.

2.

8.

4.

3.6.



7. The ongoing activation is interrupted with a command (EEG:INT;) orspontaneously by a BSC reset. The interrupted activation can bereactivated by the background data activation command (EEG). Thesemantic cross-checking is not run in the case of reactivation.

8. The interrupted activation is cancelled with a command (EEG:CNL;).

4.3 BTS background data state

The system maintains the BTS background data state as the background data ishandled.

Figure 3. State transition diagram for BTS background data states

Explanations of the state transitions:

1. A background parameter of the BTS is defined by modifying it.

2. The background data activation command (EEG) is given. The parameterswitchover for the BTS starts.

3. The background data is swapped with old active values.

4. The background data is prepared for downloading (command EER).

SWAPPING

SWAPPED

NOT DEFINED

1.

DEFINED

2.

5.

3.

4.

6.




4.4 Parameters with background data support

BTS object

The list below contains BTS objects with an active parameter as well as acorresponding background parameter given in brackets against each object.

. BSIC. Network colour code (NCC, BNCC). BTS colour code (BCC, BBNCC)

. BTS hopping mode (HOP, BHOP)

. Underlay BTS hopping mode (UHOP, BUHOP) <option>

. Hopping sequence number 1 (HSN1, BHSN1)

. Hopping sequence number 2 (HSN2, BHSN2)

. Underlay hopping sequence number (UHSN, BUHSN) <option>

. Mobile allocation frequency list (MAL, BMAL)

. Underlay mobile allocation frequency list (UMAL,BUMAL) <option>

. MAIO offset (MO, BMO)

. MAIO step (MS, BMS) <option>

. Underlay MAIO offset (UMO, BUMO) <option>

. Underlay MAIO step (UMS, BUMS) <option>

Adjacent cell object

. Adjacent cell BSIC. Adjacent cell network colour code (NCC, BNCC). Adjacent cell BTS colour code (BCC, BBCC)

. BCCH frequency of the neighbour cell (FREQ, BFREQ)

. Interfered cell (IC, BIC) <option>

TRX object

. Frequency (FREQ, BFREQ)

. Training sequence code (TSC, BTSC)

. Optimum RX level uplink (LEV, BLEV)



. TRX frequency type (FRT, BFRT)

. Direct access level (DAL, BDAL)

. Intelligent Underlay-Overlay related parameters <option>:. Mobile network code of interfering cell 1..10

(MNC1..10, BMNC1..10 ). Mobile country code of interfering cell 1..10

(MCC1..10, BMCC1..10). Location area code of interfering cell 1..10

(LAC1..10, BLAC1..10). Cell identification of interfering cell 1..10

(CI1..10, BCI1..10). Level adjustment of interfering cell 1..10

(L1..10, BL1..10). C/I estimation weight of interfering cell 1..10

(W1..10, BW1..10). C/I estimation type of interfering cell 1..10

(T1..10, BT1..10)

4.5 Restrictions in the background downloading of theradio network plan

Only the parameters listed in parameters with background data support can beoperated through the background data. Creating or deleting any object is notpossible by using background data.

Changing the BA lists and MA lists can be done by creating new lists beforehandand then later attaching them to the cells. The identification of the MA list usedby a cell can be changed as a background operation. The identification of the BAlist used by a cell can be changed as a normal operation only.

When activating a new frequency plan, a BA list should not be used on SACCHfor active MSs in the cell as the MSs may execute measurements of handovercandidate cells according to an invalid neighbour frequency list.




4.6 User interface of the background downloading ofthe radio network plan

Background parameters are modified and interrogated with the radio networkMMLs. The MMLs are also used to prepare, check and activate background data,as well as to display the background data state and the BTS background datastates. All this can also be done from Nokia NetAct.

Preparing database for background data downloading

The operator enters the command PREPARE DATABASE FOR DOWNLOADOF BACKGROUND DATA (EER). This command sets all backgroundparameters to the value "not defined".

Downloading and interrogating background data

The operator defines the background parameter values with normal modifyingcommands and can display them with normal outputting commands.

Checking background data

The cross-checking operation cross-checks the background data. Checking isdone to the whole database to ensure that the database content is correct after thebackground data activation. The operator enters the command CONTROLACTIVATION OF BACKGROUND DATA (EEG:CHK;).

Activating background data

The activation command starts the activation of the background data, that is, theswitchover of the background data between active data. The system performs thecross-checking operation before switchover. The activation command isCONTROL ACTIVATION OF BACKGROUND DATA (EEG). The systemminimises traffic interruptions during the switchover.

Interrogating switchover states

The operator can display the BSC-specific background data state and the BTSbackground data states with the command OUTPUT BACKGROUND DATAACTIVATION STATES (EEP). BTS background data states can also beinterrogated with the command OUTPUT BTS PARAMETERS (EQO).



4.7 File Based Plan Provisioning

In the S12 level system configuration, file based plan provisioning (FBPP)replaces background plan download functionality. In addition to objectmodification, creation and deletion is possible with FBPP. Most of theconfiguration parameters are supported via FBPP. In FBPP downloading, theradio network plan, in XML file format, is transferred to the BSC using FileTransfer Protocol (FTP) or File Transfer, Access, and Management (FTAM) datatransfer protocols. The plan files are moved to new plan database tables in theBSC. The BSC validates the plan before activation can start. During activation,the plan data - which were moved to new database tables in the BSC - are copiedto BSDATA and activated for use. The BSC automatically locks and unlocksobjects and disables and enables GPRS so that configuration change can be takenin use.

For more information on File Based Plan Provisioning, see File Based PlanProvisioning System Feature Description in the BSS documentation set.




Ned

Documents

base station controller

signalling point code

network colour code

radio network administration

packet control channel

network service entities

xml file format

ascii string defining