rehoming of btss

Rehosting GSM BTS Sites

DN98908338 © Nokia Corporation 1 (44)Issue 5-0 en Nokia Proprietary and Confidential


The information in this documentation is subject to change without notice and describes onlythe product defined in the introduction of this documentation. This documentation is intendedfor the use of Nokia's customers only for the purposes of the agreement under which thedocumentation is submitted, and no part of it may be reproduced or transmitted in any form ormeans without the prior written permission of Nokia. The documentation has been prepared tobe used by professional and properly trained personnel, and the customer assumes fullresponsibility when using it. Nokia welcomes customer comments as part of the process ofcontinuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity,or performance of the mentioned hardware or software products cannot be considered bindingbut shall be defined in the agreement made between Nokia and the customer. However, Nokiahas made all reasonable efforts to ensure that the instructions contained in the documentationare adequate and free of material errors and omissions. Nokia will, if necessary, explain issueswhich may not be covered by the documentation.

Nokia's liability for any errors in the documentation is limited to the documentary correction oferrors. NOKIA WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THISDOCUMENTATION OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL(INCLUDING MONETARY LOSSES), that might arise from the use of this documentation orthe information in it.

This documentation and the product it describes are considered protected by copyrightaccording to the applicable laws.

NOKIA logo is a registered trademark of Nokia Corporation.

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

Copyright © Nokia Corporation 2005. All rights reserved.

2 (44) © Nokia Corporation DN98908338Nokia Proprietary and Confidential Issue 5-0en

Contents

Contents 3

List of figures 5

1 About this document 71.1 Prerequisites 71.1.1 Functionality used in this operation 71.1.2 Other prerequisites 8

2 Changes in NetAct documentation 11

3 NetAct compatibility and capacity information 13

4 Rehosting a GSM BTS site 15

5 Preparing the rehost operation 175.1 Overview of the preparation phase 175.2 Informing customer services 195.3 Checking the transmission polling method 195.4 Stopping TRX loop tests 195.5 Creating a sheet 195.6 Creating and unlocking LAPD links 205.7 Creating DAPs 205.8 Creating managed objects and radio network parameters 215.9 Creating views 235.10 Attaching and activating the BCF software 235.11 Activating the BCF hardware database 24

6 Implementing the rehost operation 256.1 Overview of the implementation phase 256.2 Stopping measurements 276.3 Locking old managed objects 276.4 Manually switching physical links 276.5 Updating CI and LAC references 276.6 Locking, recreating, and unlocking BTSs in the MSC 296.7 Swapping LACs 306.8 Moving Site, Antenna and additional object information 306.9 Unlocking new managed objects 316.10 Updating incoming ADJGs and template IDs 316.11 Updating the Optimizer database 326.12 Running consistency checks 326.13 Checking the state of the objects 32

7 Cleaning up 357.1 Overview of the clean-up phase 357.2 Deleting old sites and LAPD links from the network 367.3 Deleting old objects and views 367.4 Restarting measurement collection 37



7.5 Reactivating scheduled TRX loop tests 377.6 Checking performance 38

8 Reverting back to the old configuration 39

9 Where to find more information 41

Index 43


List of figures

Figure 1. The preparation phase of rehosting a GSM BTS site 18

Figure 2. The implementation phase of rehosting a GSM BTS site 26

Figure 3. The clean-up phase of rehosting a GSM BTS site 35


About this document

1 About this documentThis document gives you an end-to-end Nokia NetAct system-level view on howto rehost BTS sites. When rehosting a BTS site to another BSC with the SplittingBSSs application, only a small number of parameters need to be defined for newobjects under the target BSC; most of the parameters are copied from the oldobjects under the source BSC.

1.1 Prerequisites

This section lists the minimum requirements to enable you to complete siterehosting successfully. Read this section carefully to avoid unnecessarytroubleshooting later.

1.1.1 Functionality used in this operation

The following Nokia NetAct functionality is used in this operation:

• Splitting BSSs

• Radio Network Manager

• Network Editor

• Administration of Measurements

• Scheduled TRX Loop Test Management

• Inter-NetAct Update

• CM Editor

• CM Operations Manager

• CM Analyser

• Network Element Software Configuration Manager

• Optimizer related script for updating tables in Optimizer



1.1.2 Other prerequisites

Ensure that the following prerequisites are met before starting to rehost any sites:

• The site cannot be moved to a BSC that is controlled by another NokiaNetAct.

• Initial BTS SW package must be defined.

• Target BSC, SGSN, and MSC versions must be greater than or equal to thesource versions.

• There must be enough licences in the target BSC.

• The new BSC is integrated with NetAct, that is:

- ETs are installed.- Remote MML connections are working.- Fault and performance data can be collected from the BSC.

• The ET (Exchange Terminal) for the BTS site(s) is installed and configuredin the BSC.

• Identification numbers for the following have been allocated in the newBSC:

- BCF, BTS, and TRXs- DAPs, LAPD links, PCM, TRX channels, and time slots

• The transmission plan is ready.

• If you are managing Nokia MSCs, the LA must exist in the NetActdatabase.

• If external alarms are used, alarm text (TID objects) in each BSC need tobe equal.

• If RF hopping is activated, MAL object must be created to the target.

• If BCCH Allocation lists are used, BAL objects must be created to thetarget.

• CF and DAC measurement collection is stopped.

If GPRS functionality is included, the following tasks must also be completedbefore beginning this procedure:

• SGSN parameters have been created.

• The Gb interface between the SGSN and the BSC has been configured. Formore information about configuring the Gb interface, see Enabling GPRSin the GSM Radio Network.


About this document

Note

• The GPRS capacity parameters have been defined.

• The LA and RA for the new site have been configured.

If EDGE functionality is included, the following tasks must be completed beforebeginning the procedure:

• DAP must be created to the target.

• EGPRS must be enabled in the target BTS.

• GPRS must be enabled.

If Location Services are included, the following tasks must be completed beforebeginning this procedure:

• LCSEs must be created in the source BSC.

• Needed co-ordinates must be planned.

• SMLC LCS control parameter must be set correctly.

If the Dynamic Frequency and Channel Allocation (DFCA) functionality isincluded, Splitting BSSs requires that the following objects have been created andhave the same object IDs in the source and the target BSCs:

• DFCA MA Lists (MALDs)

• DFCA MA Unsynch List (MAL)

Check from the target BSC that the used DFCA MA Unsynch List is the same asin the source BSC. If the used DFCA MA Unsynch List is different, the wronglist of frequencies is used when the BTS drops into the unsynch mode.

There are two ways to activate DFCA:

• Direct: Splitting BSSs supports activating DFCA directly to the “DFCAhopping” mode. This is the fastest method. In this case, BSC is expected tosend a warning DX message about possible radio interference.

• Indirect: It is also possible to activate DFCA with CM Editor but this ismore time-consuming. You must disable DFCA in the source BSC beforerehosting and enable it through “off” and “standby” modes in the targetBSC.

If the IMSI Based Handover (IBHO) functionality is included, Splitting BSSsrequires that the following objects have been created:



• ANE (Authorised Networks)

• SG (Subscriber Group)

The following prerequisites should be taken care of before rehosting sites that arerunning under BSS Synchronization:

• An SMLC exists under the target BSC.

• There should not exist an LMUA object under the target BSC with thesame ID as the object ID of the corresponding target master BCF.


Changes in NetAct documentation

Note

2 Changes in NetAct documentationThe information in this document relates to OSS4 releases and deliveries. Thisdocument is compatible with the latest release of NetAct and covers the necessaryrelease specific updates.

For information on the release specific changes in this document and the relatedsoftware, see Changes in NetAct Documentation.

If you are using a PDF print-out of this document and also need the changeinformation, please print out the Changes in NetAct Documentation(dn03511086) document.


NetAct compatibility and capacity information

3 NetAct compatibility and capacityinformation

For information on NetAct system and capacity, and the compatibility betweenNetAct and network element releases, see the NetAct Compatibility and CapacityInformation document.


Rehosting a GSM BTS site

4 Rehosting a GSM BTS siteRehosting a BTS site means changing the BSC that controls the site. Usually,BTS rehosting is carried out for one of the following reasons:

• The new BSC has been commissioned and capacity needs to be distributedto that BSC.

• To build capacity, for example, by upgrading the TRX configuration from2+2+2 to 3+3+3, but the capacity of the current controlling BSC has beenreached.

• A crucial area of the network, for example a major airport, conferencecentre or shopping centre, is covered by cells that are all under one BSC.To avoid cell outage in the unlikely event of a BSC failure, the coverageshould be split to two BSCs.

The procedure of rehosting GSM BTS sites is divided into three phases.

• For instructions on the preparation phase, see 5 Preparing the rehostoperation.

• For instructions on the implementation phase, see 6 Implementing therehost operation.

• For instructions on the clean-up phase, see 7 Cleaning up.


Preparing the rehost operation

5 Preparing the rehost operationThe following prerequisites must be met before starting the preparation:

• In the case of a new target BSC, all the integration tasks have beencompleted.

• The Exchange Terminal has been installed and configured in the targetBSC.

• Information on managed object IDs, names for the BCFs and TRXs, CI andLAC information, and a transmission plan for the new sites are available.

5.1 Overview of the preparation phase

The following flowchart gives you an overview of the preparation phase as wellas the tools that you can use to do the various steps.



Figure 1. The preparation phase of rehosting a GSM BTS site

Start

Inform customer services

Check transmission polling method

Activate the BCF hardware databaseMML

NE SoftwareConfiguration

ManagerAttach and activate the BCF software

Splitting BSSs Create views

Splitting BSSs

Create managed objects and radionetwork parameters

Splitting BSSs Create and unlock LAPD links

Splitting BSSs Create a sheet

Scheduled TRXLoop Test Mgmt

Stop TRX loop tests

Splitting BSSs

Create DAPs

End



Note

5.2 Informing customer services

During rehosting, services will be disrupted on the rehosted site and handovers tothe site will not succeed. It is advisable to inform your customer servicesorganisation of possible disruptions to the quality of service.

If you have the optional Maintenance Mode feature, you can use it to set networkelements to the maintenance state. This reduces load in the system by blockingunnecessary alarms coming to the monitoring tools and the database.

Maintenance Mode is started from the Top-level User Interface. For moreinformation, see Handling the maintenance mode in Top-level User InterfaceHelp.

5.3 Checking the transmission polling method

The transmission polling method (alarm collection via the Q1 interface) mustalready be defined and set up in the BSC at this stage. You can either use BSC orBTS polling of transmission equipment.

5.4 Stopping TRX loop tests

Stop the TRX loop tests using Scheduled TRX Loop Test Management. Youshould stop all TRX loop tests on the sites to be rehosted. You can do this byeither stopping the test completely or modifying the test to omit the rehosted sites.

For more information, see Scheduled TRX Loop Test Help.

5.5 Creating a sheet

Creating a sheet means creating an ASCII file with a pre-defined set of fields. Forinstructions on how to perform this step, see Creating a sheet in Splitting BSSsHelp. The sheet can be created with Splitting BSS application or with any text ortable editor that is capable of handling ASCII files. ASCII files must be saved assemicolon-separated files.

When creating a sheet:



• Fill in the Target BTSM Network Name and ID field.

• If RF hopping is activated, fill in MAL ID, MAIO Offset, and MAIO Stepsto the sheet. They are not automatically copied from the source.

• If BCCH allocation lists are used, fill in the ID for the BAL column in thesheet.

• If GPRS is activated, enter Y (yes) to the GPRS enabled column. Add alsothe correct RAC value.

• If GPRS and EGPRS are activated, fill in the GPRS columns and EGPRScolumns. Column EGPRS enabled should be Y (yes) and DAP data shouldbe inserted.

If you do not have a sheet ready, the BCF objects of the sites to be rehosted canbe dropped to the application and the parameter values entered for the new objectsin the application UI.

When you are rehosting a Multi-BCF site, the whole segment is copied to thetarget BSC. This means that segment split is not possible. Also, you must give themaster BTS a segment ID that does not already exist in the target BSC.

If same CI and LAC are used during the rehosting and Swap LACs is not used,remember to use the same RAC value also in the old and new BTS in the sheet.

5.6 Creating and unlocking LAPD links

Create and unlock LAPD links. For instructions, see Creating and unlockingLAPD links in Splitting BSSs Help.

5.7 Creating DAPs

For instructions on how to perform this step, see Creating DAPs in Splitting BSSsHelp.



Note

Note

Note

5.8 Creating managed objects and radio networkparameters

Create managed objects and radio network parameters. For instructions, seeCreating managed objects when splitting BSSs in Splitting BSSs Help.

MR data will be copied from the old objects to the new objects during Send toNetwork. If MR needs to be changed, that must be done with Network Editor afterSend to Network.

In case you use the same CI/LAC in the source and target BTS, it is not possibleto have different RAC in the source and target BTS. Use a dummy LAC if youmust use different RACs in the source and target BTSs (for example, if you haveGPRS enabled in the target BTS).

In Splitting BSSs, “dummy LAC” means any non-operational LAC object.

In case of EGPRS, EGPRS and GPRS options in the BSC should be enabled andthe attached BTS and TRX software should support EGPRS. The DAP relatedcolumns present in the new side of the sheet contains the DAP data which is eithernewly created (using the Create DAPs operation) or already existing and will beassociated with the respective TRX. If EGPRS should be enabled in the target,mark the column for EGPRS as Y (yes).

The Location Services are supported by the Splitting BSSs application. If youwant to use SEG/BTS for the Cell ID + TA and U-TDOA location methods youmust create LCS elements for those.

The U-TDOA positioning method is used only for the US emergency callpositioning (E911).

U-TDOA is only used in S11 and S11.5 BSCs. For lower BSC versions, onlyCITA method is available.

The following changes are done automatically by Splitting BSSs if LocationServices are used:



Note

• If the source BSC has Location Services related child managed objects,they will be rehosted to the target BSC. They are created to the target asmentioned below.

• If the source BTS has an LCSE and an LCSE with the given CI/LAC is notpresent in the target BSC, an LCSE is created for the new segment. If theLCSE with the given CI and LAC is already present in the target, the LCSEis not created in the target and the neighbours list will not be updated. Youmust fill in the neighbours list manually. Because of this, during the rehost,it is not recommended that you create LCS elements with a given CI andLAC in the target before the split is performed.

• LCSE element neighbour list in the target LCSE is created on the basis ofthe source LCSE: the list will be exactly the same as the source LCSE. Allthe LCSEs which are present in the neighbour list and missing in the targetBSC are created as alien LCS elements to the target BSC. If the alienLCSEs are already present in the target BSC, they are not created. (Onlyvalid when using the Cell ID + TA based location method.)

For more information on Location Services, see Activating Location Services.

If DFCA is used, there are two ways to activate it:

• Direct: Splitting BSSs supports activating DFCA directly to the “DFCAhopping” mode. This is the fastest method. In this case, BSC is expected tosend a warning DX message about possible radio interference.

• Indirect: It is also possible to activate DFCA with CM Editor but this ismore time-consuming. You must disable DFCA in the source BSC beforerehosting and enable it through “off” and “standby” modes in the targetBSC.

The following changes are done automatically by the Splitting BSSs applicationwhile rehosting the sites that are running under BSS Synchronization.

For all master BCFs in the source side if Clock Source is “LMU” and SynchEnabled is “True” in the source BCF:

• The master BCFs are created in the target side with Clock Source as“LMU” and Synch Enabled as “True”.

• LMUA objects are created under the target BSC with the followingparameters:



Note

Note

• The LMUA object with the same ID as that of the target Master BCFID is created in the target BSC.

• The TRE ID parameter of LMUA will be one and the value of LMUUsage parameter will be “Synch”.

If the LMUA object with this ID already exists in the target BSC, an error isthrown. In such a situation, corresponding target master BCF will not be made“Synch Enabled”.

The Measured LCSE and Reference LCSEs of LMUA will be emptied.

5.9 Creating views

Create BCF views for the new sites in the target BSC using Splitting BSSs. Forinstructions, see Creating BCF views in Splitting BSSs Help.

For information on how to manage views, see Building and Maintaining Views.

5.10 Attaching and activating the BCF software

If an initial software package has been defined in the BSC, you do not need toactivate the BCF software.

BCF software can be activated by using Network Element SoftwareConfiguration Manager.

To activate BCF software using Network Element SoftwareConfiguration Manager

1. Start Network Element Software Configuration Manager by clicking theicon in Application Manager.

2. Check that the correct software package is available in SW Archive. If thecorrect software package is not available, import it using BCF SoftwareArchives.



Note

3. Activate the software. For instructions, see Importing software anddownloading it to a managed object in Network Element SoftwareConfiguration Manager Help.

For more information on BCF software handling in the Nokia BSC, see thefunctional descriptions in the BSC documentation.

5.11 Activating the BCF hardware database

You only need to activate the BCF hardware database if you are rehosting a 2ndGeneration or TalkFamily BTS.

If you are not rehosting a 2nd Generation or TalkFamily BTS, move to 6Implementing the rehost operation.

The BTS hardware database must be activated using MML.

To activate the BCF hardware database

1. Start the Top-level User Interface if it is not already open.

2. Open a view containing the parent BSC of the rehosted site.

3. Begin an MML session to the BSC.

4. List the hardware databases currently available:

ZEVL;

5. If the required BCF hardware database does not exist, upload and create thehardware database:

ZEVU:<BCF_identity>:<file_name,file_extension,database_id>:<upload_mode>;

ZEVC:<database_id>:<file_name>,<file_extension>;

6. Attach the hardware database to the BCF:

ZEVA:<BCF_identity>:<database_id>;

7. Activate the BCF hardware database:

ZEVV:<BCF_identity>:<database_status>:<activation_mode>;


Implementing the rehost operation

6 Implementing the rehost operationThis chapter provides instructions for implementing the rehost operation.

Note that you can bring new sites into operation group by group (PCM by PCM,for example), or you can bring all the objects involved in the split operation intouse at once.

6.1 Overview of the implementation phase

The following flowchart gives you an overview of the implementation phase aswell as the tools that you can use to do the various steps.



Figure 2. The implementation phase of rehosting a GSM BTS site

Unlock new managed objects

Lock old managed objects

Update CI and LAC references

Lock, recreate, and unlock BTSsin the MSC

Swap LACs

Move Site, Antenna andadditional object information

Manually switch physical links

Administration ofMeasurements

Splitting BSSs

Splitting BSSs

Splitting BSSs

Splitting BSSs

Splitting BSSs

Splitting BSSs,CM Editor

External script Update the Optimizer database

Inter-NetActUpdate

Radio NetworkManager

Run consistency checks

Stop measurements

Check the state of the objects

CM Analyser,CM Operations

Manager

Update incoming ADJGs andtemplate IDs

End

Start



6.2 Stopping measurements

Stop the BSC measurements using Administration of Measurements. This appliesonly to the BSCs that are part of the rehosting. It is recommended that you stopthe measurements immediately.

For more information on how to stop measurements, see Administration ofMeasurements Help.

If stopping measurements is needed, you also need to stop MO Upload cron tasksand take BSC SW backup before proceeding with activation. For moreinformation, see Uploading Managed Objects Help.

6.3 Locking old managed objects

Lock the old managed objects at the BSS level with the Splitting BSSsapplication. For instructions, see Locking managed objects in the BSC in SplittingBSSs Help.

6.4 Manually switching physical links

BTS Site cable must be physically switched from BSC to another BSC. SwappingE1/T1 must be done when disconnecting a BTS site from its BSC and connectingit to a new BSC. The new site is usually unlocked immediately after swappingE1/T1 and verified by MML.

6.5 Updating CI and LAC references

For instructions on how to perform this step, see Updating the CI and LACreferences in rehosted sites in Splitting BSSs Help.

During this step, the incoming adjacencies are updated, the C/I-based handoverparameters are updated, and the interfering cells (IUO) information is updated inthe NetAct and BSC databases. During the operation, the old ADCE objectspointing to some other BTSs are deleted and new ADCE objects are createdpointing to the new rehosted BTS.



Note

S11 and S11.5 sites can have inter-PLMN adjacencies and they are redirected asany other incoming adjacencies from the foreign BTS.

If DFCA is used and the target BSC gets new LAC values, SPC objects must beupdated in adjacent BSCs.

The following changes are done automatically by Splitting BSSs, if LocationServices are used:

• The alien LCS elements in the target, which are pointing to the source sitebeing rehosted are deleted. All other alien LCS elements that are created inthis phase and point to the source sites not being rehosted are not deleted.

• The LCSE neighbours list is updated properly to point to the correct LCSEsif the LCSEs defined in the neighbours list are also being rehosted. (Onlyvalid when using the Cell ID + TA based location method.)

• Alien LCSEs under other BSCs, pointing to the source BTS being rehostedwill point to the BTS in the target.




Note

Note

6.6 Locking, recreating, and unlocking BTSs in theMSC

This step is needed only if Nokia MSC is available.

This note is for RNW Manager users!

When doing rehosting with the same CI and LAC without using the Swap LACsoperation in BSS Split, RNW Manager must be used properly. After the BTSMshave been recreated, they are no longer connected to the old BTS but to the newBTS. If you are deleting the old sites before using RNW Manger there will be noproblems. But if RNW Manager is used before the old sites have been deleted, beaware that when selecting the old BTS, RNW Manager is asking for aconfirmation about establishing the connection between BTSM and BTS. Thisconfirmation must be cancelled otherwise, the BTSM will again be connected tothe old BTS and then BTSM will be deleted when deleting old sites.

When the Cell ID (CI) of the BTS changes:

• The BTS in the MSC will always be deleted in the source before it iscreated again in the target.

When the LAC of the BTS changes:

• The BTS in the MSC will first be created in the target MSC and laterdeleted from the source MSC.

To lock, recreate, and unlock BTSs using Splitting BSSs

1. Lock the desired objects in the old sites. For instructions, see Locking BTSsin the MSC in Splitting BSSs Help.

2. Recreate BTSs in the MSC. For instructions, see Recreating BTS in MSCobjects when splitting BSSs in Splitting BSSs Help.

3. Unlock the new BTS sites created in the MSC. For instructions, seeUnlocking BTSs in the MSC in Splitting BSSs Help.



Note

Note

6.7 Swapping LACs

If you want to avoid adjacencies pointing to “wrong” BTSs in the BSC, you canuse a dummy LAC when creating a new BTS, and then use the Swap LACscommand to swap the dummy LAC with the old LAC.

In Splitting BSSs, “dummy LAC” means any non-operational LAC object and“dummy RA” any non-operational RA object.

If you have GPRS enabled in the target BSC, you need to use a dummy LAC anda dummy value should be given for the RAC also. You need a dummy RA in thesource and target BSC and a real RA with a real connection to SGSN. During theSwap LAC operation, the LAC values are swapped.

For instructions, see Swapping old and new LACs in Splitting BSSs Help.

The following changes are done automatically by Splitting BSSs if Locationservices are used:

• The LCSEs for the sites involved in the swapping of LACs in the targetBSC are updated during this operation. LCS element IDs will be changedto point to the correct LAC. The LCS element neighbour list that containsthe CI and LAC of this LCSE is also updated with the swapped LAC.

• The LCSEs associated with old sites are updated as alien LCSEs pointingto the corresponding BTSs in the target BSC.


If DFCA is used and the target BSC gets new LAC values, SPC objects must beupdated in adjacent BSCs.

6.8 Moving Site, Antenna and additional objectinformation

Move the Site, Antenna and additional object information from the old sites to thenew sites using Splitting BSSs. For instructions, see Moving Site, Antenna andadditional object information when splitting BSSs in Splitting BSSs Help.



6.9 Unlocking new managed objects

Unlock the new managed objects created at the BSS level using Splitting BSSs.For instructions, see Unlocking managed objects in the BSC in Splitting BSSsHelp.

If DFCA is enabled directly, BSC is expected to send a warning DX messageabout possible radio interference when unlocking the BTS object.

In case of indirect DFCA enabling, after the standby mode DFCA can be enabledwith CM Editor.

6.10 Updating incoming ADJGs and template IDs

Since the Splitting BSSs application does not automatically update incomingADJGs and template IDs, the update must be done separately according to thefollowing instructions.

To update incoming ADJGs and template IDs

1. Save the sheet, if not already saved, to ensure that the/etc/opt/nokiaoss/configurator/rac/regbss/sheetsdirectory contains the newly created sheet having the rehosted objectsdefined.

2. Update BCF, BTS, and TRX template IDs and Target Cell DN of incomingADJGs to NetAct database by running the updIncomingADJG.pl scriptwith the following command:

/opt/nokiaoss/configurator/rac/regbss/bin/updIncomingADJG.pl/etc/opt/nokiaoss/configurator/rac/regbss/sheets/<sheet>

where <sheet> is the name of the sheet you are using in Splitting BSSsand have saved in step 1.

3. Optional: Check that BCF, BTS, and TRX template IDs are correctlyupdated to the NetAct database by using the sheet from/etc/opt/nokiaoss/configurator/rac/regbss/sheets andrunning the updIncomingADJG.pl script with the -c option using thefollowing command:

/opt/nokiaoss/configurator/rac/regbss/bin/updIncomingADJG.pl/etc/opt/nokiaoss/configurator/rac/regbss/sheets/<sheet> -c



where <sheet> is the name of the sheet you are using in Splitting BSSsand have saved in step 1.

4. Using CM Analyser, create a correction plan to correct the parameters ofthe incoming ADJGs in the network by running theNokia.OSS3_1ed2fn1_3g.AdjgIdParams rule against all the RNCsthat have outgoing adjacencies (ADJG) to the rehosted BTSs.

You can find out the involved RNCs using CM Editor by selecting all theincoming ADJGs of the new BTSs and check the RNC from the ManagedObject DN.

5. Using CM Operations Manager, select the Prepare Plan option and activatethe plan to the network. For instructions, see Provisioning plans in CMOperations Manager Help.

6.11 Updating the Optimizer database

If you have Optimizer installed in your NetAct system, you must update theOptimizer database after you have created the new BTSs and before you deletethe old BTSs. For instructions, see Updating Optimizer database in SplittingBSSs Help.

6.12 Running consistency checks

If the site has incoming inter-region adjacencies (the source cell is located inanother regional NetAct), make sure that the operators in other regional NetActclusters update the CI and LAC of the moved BTSs.

• Run Inter-NetAct Update to check whether there are inconsistencies inincoming adjacencies. Follow the on-screen instructions to generate areport.

• Inform the operators in other regional NetAct(s) about the changes in theCI and LAC of the BTSs under rehosted BCFs.

6.13 Checking the state of the objects

Check the state of the managed objects using Radio Network Manager to seemore information than provided in Splitting BSSs.



To check the state of the managed objects

1. Start Radio Network Manager by clicking the icon in ApplicationManager.

2. In the main window, select the rehosted BCF.

3. Click the ZEEI button to see that the objects have been unlocked.

The ZEEI dialog opens. The dialog shows the administrative andoperational state of the site.

The administrative state can be:

• Unlocked (U)

• Locked (L)

The operational state can be:

• Blocked by user (BL-USR)

• Working (WO)

For more information, see Radio Network Manager Help.


Cleaning up

7 Cleaning upThis chapter describes the clean-up operations related to rehosting a GSM BTSsite.

7.1 Overview of the clean-up phase

The following flowchart gives you an overview of the clean-up phase as well asthe tools that you can use to do the various steps.

Figure 3. The clean-up phase of rehosting a GSM BTS site

End

Check performance

Delete old objects and views

Delete old sites and LAPD links fromthe network

Restart measurement collection

Reactivate scheduled TRX loop tests

Splitting BSSs

Network Editor

Administration ofMeasurements

Scheduled TRXLoop Test Mgmt

Start



Note

7.2 Deleting old sites and LAPD links from the network

LAPD links must be locked before they are deleted from the network.

To delete old sites and LAPD links

1. Delete the old sites from the network. For instructions, see Deleting oldsites when splitting BSSs in Splitting BSSs Help.

If you want to delete also old LAPD links, do not close the UI after deleting oldsites.

2. Delete the old LAPD links from the network. For instructions, see DeletingLAPD links in Splitting BSSs Help.

You need approximately 24 hours of performance data from the new site beforeyou can make the decision whether to delete the old sites.

The following changes are automatically done by Splitting BSSs if LocationServices are used:

• When the Delete LCSEs check box is checked, the LCSEs associated withthe BTS in the source BSC will be deleted.

• If the Delete LCSEs check box is not checked during the deletion, theLCSEs associated with the BTS in the source BSC are changed to alienLCSEs pointing to the corresponding BTS in the target BSC.

• If the BCF being deleted in the source has an attached LMU equipment, itcannot be deleted. It is required that this LMU equipment is detached andconnected to another BCF before deleting the old sites.


7.3 Deleting old objects and views

Delete the old objects and views in the NetAct database by using Network Editor.


Cleaning up

To delete old objects and views

1. Open Network Editor (Utils → System Mgmt → Network Editor...).

2. To delete a managed object, select the BCF in the view and click Delete...on the object’s pop-up menu; remember to select Delete also from DBbutton. Also remember to delete any corresponding BTSM objects.

3. To delete a view, click File → Delete... in the main window and select theview to be deleted.

4. Run RAC doctor script 002, which deletes the plans attached to the deletedold site.

In case the BSC becomes empty, you can delete the BSC object from the NetActdatabase by using the following instructions.

To delete the BSC object from the NetAct database

1. Set the BSC object as non-operational with Network Editor.

Note that if the BSC object has any child objects, all the child objects mustbe non-operational as well.

2. Delete the BSC object with Network Editor.

7.4 Restarting measurement collection

Restart the measurements on the BSC using Administration of Measurements.

For more information on how to restart measurements, see Administration ofMeasurements Help.

7.5 Reactivating scheduled TRX loop tests

Start the TRX loop tests using Scheduled TRX Loop Test Management. Youshould start all TRX loop tests that you stopped earlier.

For more information, see Scheduled TRX Loop Test Help.



7.6 Checking performance

After completing the rehosting, you should take a look at the following statisticsthe next day to ensure that the site is performing normally.

• Call set up failure

• Handover failures

• Dropped call ratio

• Mobile originated calls and mobile terminated calls on the BCCH TRX andSDCCH TRX.


Reverting back to the old configuration

8 Reverting back to the old configurationThere are different possibilities for reverting back to the old configuration:

• Before updating CI and LAC: Switch manually physical links back to theold configuration.

• After updating CI and LAC: Switch manually physical links back to the oldconfiguration and recreate incoming ADCEs manually using CM Editor.

Alternatively, you can create a new Splitting BSSs sheet with inverted oldand new sites and revert back by rehosting site back and recreating ADCEs.


Where to find more information

9 Where to find more informationFor more information, refer to the following documents.

• For more information on Nokia’s radio network management tools and theconcepts associated with managing you radio network, see Radio AccessConfigurator Principles.

• For more information on Nokia’s software and hardware configurationmanagement tools and the concepts and tasks associated with configurationmanagement, see System Administration Principles.


IndexA

activatingBCF hardware database 24BCF software 23

adjacenciesconsistency checks 32using a dummy LAC 30

Antenna information 30

B

BCCH 8, 20, 38BCF hardware database 24BTSM 20, 29, 37

C

checkingperformance 38the state of the objects 32

D

DAP 8, 9, 20, 21deleting

old LAPD links 36old sites 36views 36

DFCA 9, 22dummy LAC 21, 30

E

E1/T1 27EDGE 9EGPRS 20ETs 8Exchange Terminal 8, 17

G

GPRS 8, 21, 30

I

IBHO 9implementation 25inter -region adjacencies 32

L

LAPD links 8, 20, 36Location Services 9, 21, 28, 30, 36locking old managed objects 27

M

Maintenance Mode 19manually switching physical links 27measurements

restarting 37stopping 27

movingAntenna information 30Site information 30

MSC 8, 29

N

Nokia MSClocking BTSs 29recreating BTSs 29

O

old sitesdeleting 36LCSEs 30moving Site, Antenna and additional information.

30

P

prerequisites 7, 17

R

remote MML 8RF hopping 8RNW Manager 29running consistency checks 32

S

SGSN 8, 30Site information 30SPC 28, 30SW Archive 23

DN98908338 ©Nokia Corporation 43 (44)Issue 5-0 en Nokia Proprietary and Confidential


T

TalkFamily BTS 24template IDs 31transmission

plan 8, 17polling 19

TRXchannels 8configuration 15identification numbers 8loop tests 7, 19, 37names 17

U

unlocking new managed objects 31updating

CI and LAC references 27incoming ADJGs and template IDs 31

V

viewscreating 23deleting 36


rehoming of btss

Documents