bcf software handling

BCF Software Handling

dn98633622Issue 3-1 en

# Nokia CorporationNokia Proprietary and Confidential

1 (52)

2003330Nokia BSC S10.5 ED, Vers. 2, ProductDocumentation

The information in this documentation is subject to change without notice and describes only theproduct defined in the introduction of this documentation. This documentation is intended for theuse of Nokia's customers only for the purposes of the agreement under which the documentationis submitted, and no part of it may be reproduced or transmitted in any form or means without theprior written permission of Nokia. The documentation has been prepared to be used byprofessional and properly trained personnel, and the customer assumes full responsibility whenusing it. Nokia welcomes customer comments as part of the process of continuous developmentand improvement of the documentation.

The information or statements given in this documentation 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 documentation areadequate 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 or theinformation 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 2003. All rights reserved.

2 (52) # Nokia CorporationNokia Proprietary and Confidential



Contents

Contents 3

List of tables 4

List of figures 5

Summary of changes 7

1 Introduction to handling BCF software 91.1 BCF software overview 91.2 BCF Software Handling (command group EW) 101.3 Creation of BCF software build 121.4 Software build attachment to BCF 131.5 Activation of BCF software build 141.6 Status change of two BCF software builds 161.7 Detachment of software build from BCF 181.8 Deleting of BCF software build 191.9 Setting of initial software build 201.10 Information listing 211.11 Capacity 22

2 Bringing a new BCF software build into use 252.1 Transferring a BCF software build 252.2 Creating a BCF software build 272.3 Attaching a BCF software build 292.4 Activating a BCF software build 332.5 Changing BCF software build statuses 37

3 Removing an old BCF software build 393.1 Detaching a BCF software build from the BCF 393.2 Deleting a BCF software build 39

4 Setting and removing an initial BCF software build 434.1 Setting an initial BCF software build 434.2 Removing an initial BCF software build 44

5 Listing BCF software information 455.1 Listing the existing software builds 455.2 Listing the contents of the BCF software builds 455.3 Listing the software configuration of the BCF 455.4 Listing the BCF software handling system activities 46

6 Troubleshooting the activated BCF software build 476.1 Returning to the old software build when the BU build is faulty 476.2 Returning to the old software build when the NW build is faulty 48

Glossary 49



3 (52)

Contents

List of tables

Table 1. BCF software overview 9




List of figures

Figure 1. Transferring a BCF software build 11

Figure 2. Creating a BCF software build 12

Figure 3. Attaching a BCF software build 13

Figure 4. Activating a BCF software build 15

Figure 5. Changing BU and FB statuses 17

Figure 6. Changing NW and BU statuses 18

Figure 7. Detaching a BCF software build 19

Figure 8. Deleting a BCF software build 20

Figure 9. BSC directory structure 51



5 (52)

List of figures

Summary of changes

Summary of changes

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

Changes made between issues 3V and 3

Link corrections.

Changes made between issues 3 and 2

Minor changes in BTS build types and in checking functionalities. No softwarechanges. The document has been revised throughout to comply with the latestdocumentation standards.



7 (52)

Summary of changes

1 Introduction to handling BCF software

The Base Station System (BSS) consists of BTS sites and at least one BSC. InNokia's implementation of the BSS, a BTS site can consist of several logicalBTSs. One entity takes care of all the common functions of the BTSs on one BTSsite. This entity is called a Base Control Function (BCF) , which can be seen asthe common brain of several BTSs. Therefore, the term �BCF� is used here forthe functional entity that offers the O & M functions of the BTS network element.

BCF software is handled in software builds. The builds are referred to as BCFsoftware builds.

One of the advantages of a computer controlled network element is that newtelecommunications features can be introduced into existing network elements byreplacing and modifying the software. In the BSC, new BCF software is handledin software builds. Software is loaded to the BCF when new BCF software isreleased, when a new BTS site is brought into use, or when the BCF is restarted.

1.1 BCF software overview

Table 1. BCF software overview

BCF software descriptions BCF software instructions

Introduction to handling BCF software Bringing a new BCF software build into use

Removing an old BCF software build

Setting and removing an initial BCF software build

Listing BCF software information

Troubleshooting the activated BCF software build



9 (52)

Introduction to handling BCF software

1.2 BCF Software Handling (command group EW)

BCF software is handled in the BSC with the commands of the commands groupEW. The MML program that carries out all BCF software operations in the BSCis called SWEHAN (BCF Software Handling MML).

With the EW commands you can create and delete BCF software builds on theBSC's disk. You can attach created software to a desired status in the BCF and todetach the attached software build. A software build that is attached to the BCFcan be activated. You can also change the statuses of two software builds with thestatus NEW, BACKUP or FALL-BACK, so that the attachment of the first statuswill change to the second status and vice versa. You can set an initial build forand remove it from a BTS site type. In addition, there are output commands thatlist information on the software builds created in the BSC, the contents of thesoftware build, and the software configuration of the BCFs. You can also listongoing build management operations. A more thorough introduction of the EWcommands is given in the following sections. Those sections also give importantinformation that should be taken into consideration when using the commands.Figures are used to illustrate how the main commands of the EW command groupfunction.

The most central BCF software handling actions are transferring the softwarebuild to the BSC's disks and bringing the software build into use in the BCFs.Software is brought into use by creating a new software build, attaching it to thedesired status in the BCF and activating the software build. When the newsoftware build is stable, its status is changed to BACKUP. After this the oldsoftware build can be detached from the BCF and deleted from the softwaremanagement file and from the BSC's disks.

All BCF software handling functions discussed here can be done by using localMML commands at the BSC site or with the graphical user interface applicationsat the NMS. See the NMS document Configuration Management Basic OperatingPrinciples and Procedures or refer to NetAct documentation. A new BCFsoftware build can be transferred into the BSC on a floppy disk on site or throughthe operation and maintenance network by means of file transfer services.




Figure 1. Transferring a BCF software build

Transferring software from the NMS is practical for mass downloads, forexample, you can change the software of all target BCFs in the entire network inone operation. Downloading and activation can be timed so that the system cancarry out the operation when the BCFs have the least amount of traffic. You canalso change the build states as a mass operation from the NMS. With the NMSapplications you can also have all the software builds in one controlled place. Seethe NMS document Configuration Management Basic Principles and Proceduresor refer to Nokia NetAct documentation for more details.

BSC

BSC

NMS

BSC



11 (52)


1.3 Creation of BCF software build

With the EWC command you create a new BCF software build into the BCFSoftware Build Management File (BTMFIL).

Figure 2. Creating a BCF software build

The creation operation reads the master file and checks that all the applicationfiles specified in the master file are in the same subdirectory. It also checks thatthe versions of the application files are the same as specified in the master file.The BSC also checks that the sizes of all build files are the same that arementioned in the master file.

The build type is determined during creation. The BSC checks the file format ofthe master file and decides the type of the build. The alternatives are B, DF, C, I,P, or CX.

BCF PACK :

ID:MF:EXT:SDIR:

CBTS_S300033PACK_2

BCF PACK :

ID:MF:EXT:SDIR:

BBTS_S300032PACK_1

BCF PACK :

ID:MF:EXT:SDIR:

ABTS_S300031PACK_0

BCF-SW :

-

B

A

BSC

B I

BTS

-

A I

B

SW

SW

SW

SW

DB

RAM

DB

FLASH

DEFBU

NW

FB

Command syntax:

EWC:

Example:

MF=<master file name>,

EXT=<master file extension>,

SDIR=<subdirectory name>;

EWC:C:MF=BTS_S300,EXT=033,SDIR=PACK_2;

<build id>:




1.4 Software build attachment to BCF

With the EWA command you attach the software build to the desired status in theBCF specified in the command. The BCF builds in the BSC can be attached tothe BCF with three different statuses. These statuses are NEW (NW), BACKUP(BU) and FALL-BACK (FB).

Figure 3. Attaching a BCF software build

The system automatically checks that the site type and the build type arecompatible. The attachment operation then reads the master file and checks thatall the application files specified in the master file are in the same subdirectory. Italso checks that the versions of the application files are the same as specified inthe master file. The BSC also checks that the sizes of all build files are the samethat are mentioned in the master file.

BCF PACK :

ID:MF:EXT:SDIR:

CBTS_S300033PACK_2

BCF PACK :

ID:MF:EXT:SDIR:

BBTS_S300032PACK_1

BCF PACK :

ID:MF:EXT:SDIR:

ABTS_S300031PACK_0

BCF-SW :

C

B

A

BSC

B I

BTS

C

C I

B

SW

SW

SW

SW

DB

RAM

DB

FLASH

DEFBU

NW

FB

Command syntax:

Example:

EWA:

<build status>:

<build id>;

EWA:1:NW:C;

<number of BCF>:



13 (52)


If possible, the attachment operation downloads the software build to the BCF asa background operation without disturbing ongoing calls, and stores it to theBCF's non-volatile memory by replacing the oldest build in that memory.

In the case of Nokia PrimeSite, the attached build will be downloaded parallel tothe non-volatile memory of each TRX under a given BCF. If the O & M link ofeven one unlocked TRX is out of order, the whole operation is denied.

The BCF software management system checks the load rate of the BCSU beforestarting the background downloading of the software build. If the load rate is highenough to possibly prevent the call setup, the downloading will be put in a queueuntil the load rate decreases enough and the downloading can be started.

You can check the state of the download operation with the EWI command. Inthe case of Nokia PrimeSite, the state is the same as the phase of the latest TRXexecuting.

You can also monitor various phases of BCF operations on the display of theservice terminal with the BCF Reset Phase Monitoring Program Block(RPHASE), which is a service terminal extension. For more information, seeRPHASE User's Manual .

1.5 Activation of BCF software build

With the EWV command you activate the attached software build and restart theBCF with it. If necessary, the build will be loaded from the BSC's disks to theBCF.




Figure 4. Activating a BCF software build

The BCF builds in the BSC can be attached to the BCF with three differentstatuses. These statuses are NEW (NW), BACKUP (BU) and FALL-BACK (FB).Each of these builds can be activated.

The activation command changes the default build of the BCF and it stays as thedefault until another build is activated. Build activation normally causes a BCFrestart with the activated software. There are some cases where the BCF restartdoes not begin, but the activated build is only set as a default build. These are:

. the administrative state of the BCF is LOCKED

. the O & M link of the BCF is out of order

. the BCF does not respond to the reset request sent by the BSC

BCF PACK :

ID:MF:EXT:SDIR:

CBTS_S300033PACK_2

BCF PACK :

ID:MF:EXT:SDIR:

BBTS_S300032PACK_1

BCF PACK :

ID:MF:EXT:SDIR:

ABTS_S300031PACK_0

BCF-SW :

C

B

A

BSC

C I

BTS

C I

B

SW

SW

SW

SW

DB

RAM

DB

FLASH

DEF

BU

NW

FB

Command syntax:

Example:

EWV:

<build status>;

EWV:1:NW;

<number of BCF>:



15 (52)


The activation command is rejected by the system if the software attachmentprocedure is still in progress. In that case the activated build is not changed to thedefault build and the activation command must be given again later.

The BCF restart initiates the loading of the software build from the BSC to theBCF if the build is not found in the BCF's non-volatile memory.

In the case of Nokia PrimeSite, the build activation command is BCF-specific butall TRXs of the BCF are restarted separately. If the O & M link of even oneunlocked TRX is out of order, the whole operation is denied.

1.6 Status change of two BCF software builds

With the EWH command you change the statuses of two software builds. If theother status is empty, the attached status will be copied to the empty one, but theempty status cannot be copied to the attached status.




Figure 5. Changing BU and FB statuses

BCF PACK :

ID:MF:EXT:SDIR:

CBTS_S300033PACK_2

BCF PACK :

ID:MF:EXT:SDIR:

BBTS_S300032PACK_1

BCF PACK :

ID:MF:EXT:SDIR:

ABTS_S300031PACK_0

BCF-SW :

C

A

B

BSC

C I

BTS

C I

B

SW

SW

SW

SW

DB

RAM

DB

FLASH

DEF

BU

NW

FB

Command syntax:

Example:

EWH:

ST1=<first status>,

EWH:1:ST1=BU,ST2=FB;

<number of BCF>:

ST2=<second status>;

-



17 (52)


Figure 6. Changing NW and BU statuses

If either one of the builds is the default build, it remains as the default after thestatus has been changed.

If one status is BU and empty, and the default build has the other (NW) status, thechange command copies the NW build to the BU status and changes the buildwith the BU status into the default build.

1.7 Detachment of software build from BCF

With the EWE command you remove the build attachment of the BCF.

BCF PACK :

ID:MF:EXT:SDIR:

CBTS_S300033PACK_2

BCF PACK :

ID:MF:EXT:SDIR:

BBTS_S300032PACK_1

BCF PACK :

ID:MF:EXT:SDIR:

ABTS_S300031PACK_0

BCF-SW :

A

C

B

BSC

C I

BTS

C I

B

SW

SW

SW

SW

DB

RAM

DB

FLASH

DEFBU

NW

FB

Command syntax:

Example:

EWH:

ST1=<first status>,

EWH:1:ST1=NW,ST2=BU;

<number of BCF>:

ST2=<second status>;

-




Figure 7. Detaching a BCF software build

The default build or the BU build cannot be detached.

1.8 Deleting of BCF software build

With the EWD command you delete a BCF software build from the BCF softwarehandling system. If you use the parameter DSK , also the physical build files areremoved from the BSC's disks.

BCF PACK :

ID:MF:EXT:SDIR:

CBTS_S300033PACK_2

BCF PACK :

ID:MF:EXT:SDIR:

BBTS_S300032PACK_1

BCF PACK :

ID:MF:EXT:SDIR:

ABTS_S300031PACK_0

BCF-SW :

C

B

BSC

C I

BTS

C I

B

SW

SW

SW

SW

DB

RAM

DB

FLASH

DEFBU

NW

FB

Command syntax:

Example:

EWE:

<build status>;

EWE:1:NW;

<number of BCF>:

-



19 (52)


Figure 8. Deleting a BCF software build

You cannot delete a BCF software build that still has attachments. You cannotdelete a BCF software build that has been set as the initial build.

1.9 Setting of initial software build

When you have created a software build, you can define an initial software buildin advance for each BTS site type with the EWS command. When a BCF iscreated, this predefined software build is attached and activated automatically tothe new BCF. The build is attached to the BU status. If the O & M link of theBCF is already in the working state, the system also background downloads thesoftware build into the BCF. You may thus ignore two standard manual workphases, attaching and activating, in BTS commissioning.

BCF PACK :

ID:MF:EXT:SDIR:

CBTS_S300033PACK_2

BCF PACK :

ID:MF:EXT:SDIR:

BBTS_S300032PACK_1

BCF PACK :

ID:MF:EXT:SDIR: PACK_0

BCF-SW :

C

B

BSC

C I

BTS

C I

B

SW

SW

SW

SW

DB

RAM

DB

FLASH

DEFBU

NW

FB

Command syntax:

Example:

EWD:

[<deleting mode>];

EWD:A:DSK;

<build id>:

--




You can also remove or change the initial build with the EWS command at anytime. You can see the initial BCF software builds with the EWL command.

From the NMS the initial software build can only be set with remote MMLcommands.

1.10 Information listing

With the EWI command you can output ongoing BCF software handling systemactivities like background downloading or saving software to the BCF's non-volatile memory. The command also shows operations in the pending state.

In the case of Nokia PrimeSite, the activity of the BCF is the same as the phase ofthe latest TRX executing.

You can output all the created software builds on the BSC's disks with the EWLcommand. The command shows the following information on each createdsoftware build:

. build ID

. build type

. release version

. initial build of the BTS generation

. master file name

. subdirectory

. connection counter

The connection counter tells how many attachments have been made to thesoftware build.

You can output the software configuration of the BCF with the EWO command.The command shows the following information on all attached software builds ofthe BCF as well as the BTS site type:

. status

. build ID

. release version



21 (52)


. subdirectory

. state (�DEFAULT� in this field indicates the default build)

You can output build and file information on the application files included in thesoftware build with the EWP command. The command shows the followinginformation on the BCF software build:

. build ID

. build type

. release version

. master file name

. master file version

. subdirectory

In addition, it also shows the following information on the files of the softwarebuild: application file names, file versions, freezing dates, file types, and unitinformation which indicates the units in which these files will be run.

1.11 Capacity

The BSC manages BCF software in builds. In the BSC's disks there are 40subdirectories for BCF software, each containing one build.

The capacity of the BCF software management files limits the number of BCFsoftware builds that can be created in one BSC. The BSDATA (BSS RadioNetwork Configuration Database) limits the number of the BCFs that can becreated in one BSC. The capacity of the management files is the following:

. the maximum number of BCFs created in a BSC depends on the BSCconfiguration (see Product Description High Capacity Base StationController ).

. the maximum number of software builds created in a BSC is 40

. the possible status of a BCF software build attached to a BCF is NEW(NW), BACKUP (BU), or FALL-BACK (FB).

At any one time there can be only one command managing BCF softwarehandling in the BSC, but one command can handle several BCFs at the sametime.




The maximum number of simultaneous download operations has been restrictedto 32. If there are no resources left, the BSC puts the extra downloadingoperations in a queue until resources are available again. It is possible to load thesame build to every BCF or a different one to each BCF.



23 (52)


2 Bringing a new BCF software build intouse

Bringing the BCF software build into use can be separated into the phases listedbelow as links. The procedures in that list are to carry out in the presented order.

Note

BCF software handling functions discussed in the following sections can also beperformed at the NMS with the graphical user interface applications. For moreinformation, refer to Configuration Management Basic Principles and Procedures.

Before you start

The following initial conditions should be met bofore you start to bring a newBCF software build into use:

. the BSC's OMU is in the normal working state (WO-EX) (the USIcommand)

. both of the BSC's disks are in the normal working state (WO-BU) (the ISIcommand)

The new BCF software build should be tested with one BCF. When its stabilityhas been proven to be good, the software build can be distributed to the otherBCFs.

The modifications made in the BCF's software configuration by means of theBSC's local MMI are updated in the NMS via the Q3 interface .

2.1 Transferring a BCF software build

Before you start



25 (52)

Bringing a new BCF software build into use

The BCF software builds are located in the subdirectories on the BSC's disks. Onthe disk there is a directory named BCF_PACK and subdirectories namedPACK_X. The value of X ranges from 0 to 39. Ensure that the new BCF softwarebuild is located on a floppy disk (the IWX command). Copy the BCF softwarebuild files to the first unused build subdirectory of both disks, for example from afloppy disk.

Steps

1. Output the existing software builds and their subdirectories (EWL)

With this command you search the first subdirectory that does not includeany created software builds.

EWL;

The command has no parameters.

2. Check that the subdirectory is empty on both disks (IWX)

IWX::<drive>,<default subdir in use>:<path>:<filename>,<extension>;

3. Delete the extra files from the subdirectory (IWD)

You can delete the extra files from the subdirectory if the subdirectory isnot empty but it contains no files that associated with the created softwarebuilds.

IWD::<drive>,<default subdir in use>:<path>:<filename>,<extension>,<version>,<confirmation>;

4. Define the source of the software build on the floppy disk (IWY)

IWY:<object>:DRIVE=<device>;

5. Define the destination of the software build in unused subdirectorieson both disks (IWY)

IWY:<object>:PATH=<full path>,DRIVE=<device>;

6. Copy the files to the subdirectory (IBC)

IBC:<source unit identifier>,,<file name>,<file nameextension>,,<destination unit identifier>,<destination unit number>;




7. Check that all the files have been copied (IWX)


Further information:

Example 1. Outputting the existing software builds and theirsubdirectories

ZEWL;

Example 2. Checking that the subdirectory is empty on both disks

ZIWX::WS,NODEF:BCF_PACK,PACK_0:%,%;

ZIWX::WB,NODEF:BCF_PACK,PACK_0:%,%;

Example 3. Deleting the extra files from the subdirectory

ZIWD::WSB,NODEF:BCF_PACK,PACK_0:%,%,0,CON;

Example 4. Defining the source of the software build on the floppy disk

ZIWY:S:DRIVE=FDU-N0;

Example 5. Defining the destination of the software build

ZIWY:D:PATH=/BCF_PACK/PACK_0,DRIVE=WDU-SB;

Example 6. Copying the files to the subdirectory

ZIBC:FDU,,%,%,,WDU,SB;

Example 7. Checking that all the files have been copied


ZIWX::WB,NODEF:BCF_PACK,PACK_0:%,%;

2.2 Creating a BCF software build

The identifier of the BCF software build should be defined to contain the releaseversion of the build, for example B_10_0.



27 (52)


The build ID must be unique in the BSC. You can output the already created BCFsoftware build names in the BSC with the EWL command.

Steps

1. Create a BCF software build (EWC)

EWC:<build ID>:MF=<master file name>,EXT=<masterfile extension>,SDIR=<subdirectory>;

2. Check the error code that the system outputs after the creation

Check the error code that the system outputs after the creation. The errorcodes and their meanings are explained in General Error Messages ofSystem . If the command execution was not successful, refer to sectionUnexpected outcome below.

Expected outcome

The creation is successful.

Example 8. Creating a BCF software build

ZEWC:B_10_0:MF=BTS_S301,EXT=101,SDIR=PACK_0;

Unexpected outcome

If creating a BCF software build fails an error code appears. If theerror code is

a. MASTER FILE NOT FOUND , APPLICATION FILE NOTFOUND , DIRECTORY NOT FOUND , or BUILDDIRECTORY IN USE , check the files and directories of thenew BCF software build by following the steps from 1 to 4

b. BUILD ID ALREADY EXISTS , check the build identifierby following the steps from 5 to 7

c. DEVICE NOT IN USE , check the BSC's disks by followingthe steps 8 and 9

For more information on the parameters, see Disk File and DirectoryHandling .

To correct the situation follow the steps below.

a. Check that the subdirectory is correct (IWX)





b. Check that all the files are in the subdirectory (IWX)


c. Check that the version of the software build files are correct(IWX)


d. Repeat the creation operation

e. Check that the given build identifier is correct (EWL)

EWL;


f. Check that the identifier is unique in the BSC (EWL)

EWL;


g. Repeat the creation operation

h. Check that both BSC's disks are in working state (ISI)

ISI::<I/O device type>;

i. Repeat the creation operation


Example 9. Checking a new BCF software build


Example 10. Checking the build identifier

ZEWL;

Example 11. Checking the BSC's disks

ZISI::WDU;

2.3 Attaching a BCF software build

Steps

1. Check that the BCF object has been created in the BSDATA ( EEI)

EEI

2. Check the BCF's NW status (EWO)



29 (52)


EWO:<number of BCF>;

Check that the BCF's NW status is empty and there are no software buildsattached to the NW status. If there is a build attached to the NW status,check if the build is the default build or not.

3. Detach the build attached to the NW status if it is not the default build(EWE)

EWE:<number of BCF>:<build status>;

If the default build has been attached to the NW status, follow the tasksdescribed in Changing BCF software build statuses and Detaching a BCFsoftware build from the BCF .

4. Attach the software build to the NW status of the BCF (EWA)

EWA:<number of BCF>:<build status>:<build ID>;

5. Check the command printout

If the printout shows something other than the BCF identifier andDOWNLOAD-STARTED or DOWNLOAD-DENIED (BUILD INFLASH) , refer to section Unexpected outcome below. DOWNLOAD-DENIED (BUILD IN FLASH) means that the software build alreadyexists in the BCF's non-volatile memory so there is no need to downloadthe build again.

Expected outcome

The attachment is successful.

Example 12. Checking the BCF's NW status

ZEWO:1;

Example 13. Detaching a build

ZEWE:1:NW;

Example 14. Attaching the software build

ZEWA:1:NW:B_10_0;

Unexpected outcome




a. If the command printout is BCF identifier and DOWNLOAD-PENDING (NO RESOURCES) , the download operation willbe in the download queue until the download resources areagain available.

Use the EWI command to see when the download has beenstarted.

EWI:<number of BCF>;

b. If the command printout shows the BCF identifier andDOWNLOAD-PENDING (LOAD RATE) , the downloadoperation will be in the download queue until the load rate ofthe BCSU unit decreases. Use the EWI command to seewhen the download has been started.


c. If the command printout shows the BCF identifier andDOWNLOAD-DENIED (O & M LINK STATE) , follow thesteps from 1 to 3.

Note

In the case of Nokia PrimeSite the O & M link states of all the unlocked TRXshave to be WO-EX.

DTI;

DTC:<D-channel link set name>:,<D-channelstate change>;

d. If the command printout shows the BCF identifier andDOWNLOAD-DENIED (ONGOING RESET) , use the EFOcommand to see when the BCF restart has been finished, thatis, when the BCF has moved from operational state BL-RST(blocked-reset) to operational state WO. Then repeat theattachment.

EEI:BCF=<BCF identification>;

e. If the command printout shows the BCF identifier andDOWNLOAD-DENIED (PARTLY OK) , at least one TRXhas started the downloading and at the same time at least onedownloading has failed. Check with the EOL command ifalarm 7713 (SOFTWARE BACKGROUND DOWNLOADTO BCF FAILS) has been set. Follow the instructions of thealarm to correct the fault. Use the command EWI to see whenthe ongoing loading is finished. Then repeat the attachment.



31 (52)


Note

This printout is only possible for Nokia PrimeSite with more than one TRX.

EOL:<BCF identification>;


f. If the command printout shows an error code, check thereason for it in General Error Messages of System and correctthe situation. Then repeat the attachment.

g. If the error code is MASTER FILE NOT FOUND ,APPLICATION FILE NOT FOUND , DIRECTORY NOTFOUND , or BUILD DIRECTORY IN USE , check the filesand directories of the new BCF software build by followingthe steps from 4to 7.

h. If alarm 7713 (SOFTWARE BACKGROUNDDOWNLOAD TO BCF FAILS) is set, follow the instructionsof the alarm. Then repeat the attachment.

The alarm 7713 is set if the background downloading of theBCF software build from the BSC to the BCF has failed.There is a field in the alarm output which gives more detailedinformation on the fault phase (QUEUING,DOWNLOADING or SAVING TO FLASH).

After the cause of the interruption has been repaired, youmust detach the software build from the BCF. You must alsocheck the O & M link state and attach the BCF software buildto the BCF again.

You must cancel the alarm with an MML command.


a. Check the O & M link state (DTI)

DTI

b. Change the state of the link to WO-EX (DTC)

DTC

DTC:<D-channel link set name>:,<D-channel

state change>;

c. Repeat the attachment

d. Check that the subdirectory is correct (IWX)


e. Check that all the files are in the subdirectory (IWX)





f. Check that the version of the software build files are correct(IWX)


g. Repeat the attachment operation


Example 15. Checking when the download has been started

ZEWI:1;

Example 16. Checking and changing the O & M link state

ZDTI;

ZDTC:CLS00:,WO;

Example 17. Checking when the BCF restart is finished

ZEEI:BCF=1;

Example 18. Checking if the alarm is set and checking when the loading isfinished

ZEOL:1;

ZEWI:1;

2.4 Activating a BCF software build

Before you start

Note

Note that activating the BCF software build causes a BCF reset.



33 (52)


Steps

1. Check that the software build you want to activate has been attachedto the BCF with the required status (EWO)


2. Activate the software build

EWV:<number of BCF>:<build status>;


If the printout shows something other than the BCF identifier and RESET-STARTED , see alarm description of the alarm 7715 below. Otherwisemove to the next step.

4. Check the BCF's operational state

Check that the BCF's operational state receives the value WO and, in thecase of Nokia PrimeSite, the operational state of all unlocked TRXs is WO.


Expected outcome

The activation is successful.

Example 19. Checking the software build

ZEWO:1;

Example 20. Activating the software build

ZEWV:1:NW;

Example 21. Checking the command printout

ZEEI:BCF=1;

Unexpected outcome




a. If the command printout shows the BCF identifier andRESET DENIED(O & M LINK STATE) , follow the stepsfrom 1 to 3.

Note

In the case of Nokia PrimeSite the O & M link states of all the unlocked TRXshave to be WO-EX.

b. If the command printout shows the BCF identifier andRESET-DENIED (ADMINISTRATIVE STATE) , follow thesteps 4 and 5.

c. If the command printout shows the BCF identifier andRESET-DENIED (ALL TRXs NOT RESTARTED) , at leastone TRX has restarted but at the same time at least one TRXrestart has failed. Follow the steps from 6 to 9.

Note

This printout is only possible for Nokia PrimeSite site type.

d. If the command printout shows an error code, check thereason for it in General Error Messages of System and correctthe situation. Then restart the activation.


a. Check the O & M link state (DTI

DTI;

b. Change the O & M link state to WO-EX (DTC)

DTC:<D-channel link set name>:,<D-channelstate change>;

c. Repeat the activation

d. Check the BCF's administrative state (EEI)


The state of the BCF must be unlocked.

e. Change the state if necessary (EFS)

EFS:<BCF identification>:<administrativestate>;

f. Check the alarm printout (EOL)



35 (52)


EOL:<BCF identification>;

g. Follow the instructions of the alarm to correct the fault

h. Check when the ongoing restart has finished (EEI)

That is when the state has changed from BL-RST to WO.


i. Repeat the activation


Example 22. Checking and changing the O & M link

ZDTI;

ZDTC:CLS00:,WO;

Example 23. Checking the BCF's administrative state

ZEEI:BCF=1;

ZEFS:1:U;

Example 24. Checking the alarm printout and whether the restart isfinished

ZEOL:1;

ZEEI:BCF=1;

The alarm 7715 is set if the O & M unit of the BCF is caught in a circle of resets.The BCF or, in the case of Nokia PrimeSite, the TRX has received at least 3resets within 30 minutes. When this alarm is set, the BCF is unable to operateproperly.

You must find out the reason why the BCF or the TRX is receiving continuousresets and correct the error that causes them. Possible reasons for the error can be,for example, a wrong hardware database in the BCF, a hardware fault in the BTS,a change of the O & M link state during the reset, or a corrupted BCF softwarebuild.

The system cancels the alarm when 15 minutes have passed after the last reset ofthe BCF.




2.5 Changing BCF software build statuses

Steps

1. Interchange attached builds between the FB and BU statuses (EWH)

EWH:<number of BCF>:ST1=<first status>,ST2=<secondstatus>;

When the NW build is stable, use the EWH command to interchangeattached builds between the FB and BU statuses.

Note

If the other status is empty, the attached status will be copied to the empty one.

2. Interchange the BU and NW statuses (EWH)



Example 25. Interchanging attached builds

ZEWH:1:ST1=BU,ST2=FB;

Example 26. Interchanging the BU and NW statuses

ZEWH:1:ST1=NW,ST2=BU;



37 (52)


3 Removing an old BCF software build

3.1 Detaching a BCF software build from the BCF

Steps

1. Check the BCF software build (EWO)


Check that the BCF has a software build that has been attached to therequired status and that it is not the default build or the BU build.

2. Detach the software build from the BCF (EWE)



If the system outputs an error code, check it in General Error Messages ofSystem , find out the reason for it, correct the fault, and try again.


Example 27. Checking the BCF software build

ZEWO:1;

Example 28. Detaching the software build from the BCF

ZEWE:1:NW;

3.2 Deleting a BCF software build

Before you start



39 (52)


Note

The BCF software build files cannot be deleted from the subdirectory where thefiles for the created builds are located.

Steps

1. Check if the software build has any attachments (EWL)

Note

Note also the subdirectory name where the build files are located. If the build hasbeen attached to the BCF, it must be detached before it can be deleted.

EWL;


2. Delete the software build using the parameter value DSK (EWD)

EWD:<build ID>:<deleting mode>;


If the command execution failed, check the error code from General ErrorMessages of System , correct the situation and try again.

Example 29. Checking the software build

ZEWL;

Example 30. Deleting the software build

ZEWD:B_9_0:DSK;




Note

If you have problems with deleting the physical software build files with the EWDcommand, you have to delete them with the commands of the I/O system. SeeDisk File and Directory Handling .

The BCF software build files must not be deleted from the subdirectory where thefiles for the created builds are located (IWD command)



41 (52)


4 Setting and removing an initial BCFsoftware build

You must create a BCF software build before you can set it as the initial BCFsoftware build.

From the NMS you can set the initial software build only with the remote MMLcommands.

4.1 Setting an initial BCF software build

Steps

1. Check that the software build has been created (EWL)

EWL;


2. Set the initial software build (EWS)

EWS:<site type>:<build ID>;

3. Check that the software build has been set as the initial build (EWL)

EWL;


If the command execution failed, correct the situation and try again.


Example 31. Checking that the software build has been created

ZEWL;



43 (52)

Setting and removing an initial BCF software build

Example 32. Setting the initial software build

ZEWS:B:B_10_0;

Example 33. Checking that the software build has been set as the initialbuild

ZEWL;

4.2 Removing an initial BCF software build

Steps

1. Check that the initial software build is set for the BTS site type (EWL)

EWL;


2. Remove the initial software build (EWS)

EWS:<site type>;

3. Check the command printout to see that the command execution wassuccessful

If the command execution failed, correct the situation and try again.

4. Check that the initial build is removed (EWL)

EWL;



Example 34. Checking the initial software build

ZEWL;

Example 35. Removing the initial software build

ZEWS:B;

Example 36. Checking that the initial build is removed




ZEWL;

5 Listing BCF software information

5.1 Listing the existing software builds

Steps

1. Output all the created software builds on the BSC's disks (EWL)

EWL;


5.2 Listing the contents of the BCF software builds

Steps

1. Output build and file information on the application files (EWP)

EWP:ID=<build ID>;

EWP:MF=<master file name>,EXT=<master fileextension>,SDIR=<subdirectory>;

5.3 Listing the software configuration of the BCF

Steps

1. Output the software build configuration (EWO)




45 (52)

Listing BCF software information

5.4 Listing the BCF software handling system activities

Steps

1. Output the ongoing activities (EWI)



Example 37. Listing the existing software builds

ZEWL;

Example 38. Listing the contents of the BCF software builds

ZEWP:ID=B_10_0;

or

ZEWP:MF=BTS_S301,EXT=101,SDIR=PACK_0;

Example 39. Listing the software configuration of the BCF

ZEWO:1&5&&10;

Example 40. Listing the BCF software handling system activities

ZEWI:1&2&5&&10;




6 Troubleshooting the activated BCFsoftware build

6.1 Returning to the old software build when the BUbuild is faulty

Steps

1. Activate the build with the FB status (EWV)


2. Interchange the statuses FB and BU (EWH)


3. Detach the software build with the FB status (EWE)



Example 41. Activating the build with the FB status

ZEWV:1:FB;

Example 42. Interchanging the statuses FB and BU

ZEWH:1:ST1=BU,ST2=FB;

Example 43. Detaching the software build with the FB status

ZEWE:1:FB;



47 (52)

Troubleshooting the activated BCF software build

6.2 Returning to the old software build when the NWbuild is faulty

Steps

1. Activate the software build with the BU status (EWV)


2. Detach the software build with NW status (EWE)



Example 44. Activating the software build with the BU status

ZEWV:1:BU;

Example 45. Detaching the software build with NW status

ZEWE:1:NW;




Glossary

Concepts

AF Application file is a load unit that contains the code and standard data of oneprogram block, or one file block. The application files are the smallest parts of asoftware build that can be separately introduced into the BSC.

BCF Base Control Function is a functional unit in the base station. Its main tasks arebase station operation and maintenance functions, that is, software loading, unitconfiguration, and alarm handling. The BCF communicates with the BSC via theAbis O & M interface.

BTS Base Transceiver Station is referred to as a sector of the base station in radionetwork maintenance. A sectorised BTS site can, therefore, consist of severallogical BTSs. Both types of the BTS (sectorised and unsectorised) are covered byone BCF.

BCF non-volatilememory

The BCF's memory consists partly of a non-volatile memory, which is not erasedif the power supplies fail. It is possible to save information into the non-volatilememory by a program. The BCF hardware database and the BCF's software havebeen saved into the non-volatile memory. The non-volatile memory is oftencalled a FLASH memory.

BCF build status Build status is the activity status of a software build that is located on a disk andis created with management commands. When the software build is attached tothe BCF, it has an activity state known as its status. The possible statuses are:

NEW (NW) NEW is the status of a new software build when it is firstintroduced in the BCF, after which it will be brought into use.

BACKUP (BU) BACKUP is the status of a software build that is usuallydefined as active and in use, and is therefore normally loadedduring initial loading when the BCF is restarted.

The BACKUP build cannot be removed with the BCF buildmanagement commands.

FALL-BACK (FB)FALL-BACK is the status of a software build that is usuallyolder than the BACKUP build, and which usually functionsas the online backup copy of the BCF software build. Ifnecessary, the FALL-BACK build can be loaded to the BCFwith the MML commands.

BCF software build Software build is a combination of software entities that provides the definedhardware with the functions required of it. A BCF software build includes thesoftware of the whole base station site.



49 (52)

Glossary

BTS site A BTS site can be considered as the O & M functionality of a physical BTS site.On the other hand, a BCF can be considered as the entire base transceiver stationsite, including all its units. A BTS site can be sectorised: one BCF can includemore than one BTS. If there is only one BTS in the BTS site, it is a non-sectorisedor omni site.

Build ID Build ID is the identity string that is used for identifying unambiguously thedifferent BCF software builds on the BSC's disk.

The same build ID can be used in different BSCs at the same time.

Build type The different base station generations use different kinds of software builds. Thepossible software build types are:

B The software build used in the Nokia 2nd generation of basestations.

DF The software build used in the Nokia Talk-family and NokiaPrimeSite base stations.

C The software build used in the Nokia MetroSite base stations.

I The software build used in the Nokia InSite base stations.

P The software build used in the Nokia UltraSite base stations.

CX The software build used in the Nokia MetroSite and NokiaUltraSite base stations.

Default build The default build is the build that is primarily used for the initial loading of theBCF. The status of the default build must be BACKUP, NEW or FALL-BACK.There can be only one default build at a time.

Directory tree Directory tree is a structure implemented on the BSC's disks. The BCF softwarebuilds are located in various disk directories. Each software build is located in itsown subdirectory.




Figure 9. BSC directory structure

Downloading Downloading is an operation during which software is transferred from a higherlevel network element to a lower level network element. The transfer is carriedout file by file so that the master file and all application files of software aretransferred.

Initial loading Initial loading is the loading of the computer unit's or system's load modules fromdisk or from the non-volatile memory into the random access memory (RAM) forexecution.

Initial build When the software build has been created, it is possible to define an initialsoftware build in advance for each BTS site type. When a BCF is created, thepredefined software build is automatically attached to the new BCF and activated.The initial builds are indicated with the following letters:

B The initial build of the Nokia 2nd generation of base stations.

D The initial build of the Nokia Talk-family base stations.

F The initial build of the Nokia PrimeSite base stations.

ROOT

BCF_PACK DX200 packSCMANA DX200 pack

PACK_1PACK_0 PACK_39 HWDATA. . .

. . .

- MASTER FILE- APPLICATIONFILES

- HW DB ASCII FILES- HW DB BINARY FILES



51 (52)

Glossary

D/F The initial build of the Nokia Talk-family and NokiaPrimeSite base stations.

C The initial build of the Nokia MetroSite base stations.

I The initial build of the Nokia InSite base stations.

P The initial build of the Nokia UltraSite base stations.

C/P The initial build of the Nokia MetroSite and Nokia UltraSitebase stations.

MF Master file is a file that contains information on all the application files of thesoftware build, together with their version data. A software build is alwaysaccompanied by a master file and the master file is located in the samesubdirectory as the software build.

Q3 interface The Q3 interface refers to an object based management interface between theNMS and the network elements (NE) in a Telecommunications ManagementNetwork (TMN). The NMS and the NEs communicate with each other throughthis interface.

Softwaremanagement file

In the BSC there are two BCF software management files where the currentsoftware build configuration of the BCFs is maintained.

The BTMFIL (BCF Software Build Management File) includes the informationof all the software builds that are located and created on the BSC's disks.

The BTPFIL (BCF Software Configuration Management File) includes theinformation on the software configuration of the BCFs in the BSS.

Both management files are maintained on the BSC's disks.

TRX Transceiver is a function that transmits and receives a radio carrier and handlesbaseband and frame functions.




bcf software handling

Documents