GSM Railway, Rel.

RGR50,
Operating Documentation,
Issue 02

BCF Hardware Database

Handling
DN98799836
Issue 4-0
Approval Date 2008-02-27
 BCF Hardware Database Handling

The information in this document applies solely to the hardware/software product (“Product”) specified
herein, and only as specified herein. Reference to “Nokia” later in this document shall mean the respective
company within Nokia Group of Companies with whom you have entered into the Agreement (as defined
below).

This document is intended for use by Nokia's customers (“You”) only, and it may not be used except for the
purposes defined in the agreement between You and Nokia (“Agreement”) under which this document is
distributed. No part of this document may be used, copied, reproduced, modified or transmitted in any form
or means without the prior written permission of Nokia. If You have not entered into an Agreement
applicable to the Product, or if that Agreement has expired or has been terminated, You may not use this
document in any manner and You are obliged to return it to Nokia and destroy or delete any copies thereof.

The document has been prepared to be used by professional and properly trained personnel, and You
assume full responsibility when using it. Nokia welcomes your comments as part of the process of
continuous development and improvement of the documentation.

This document and its contents are provided as a convenience to You. Any information or statements
concerning the suitability, capacity, fitness for purpose or performance of the Product are given solely on
an “as is” and “as available” basis in this document, and Nokia reserves the right to change any such
information and statements without notice. Nokia has made all reasonable efforts to ensure that the
content of this document is adequate and free of material errors and omissions, and Nokia will correct
errors that You identify in this document. Nokia's total liability for any errors in the document is strictly
limited to the correction of such error(s). Nokia does not warrant that the use of the software in the Product
will be uninterrupted or error-free.

NO WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY OF AVAILABILITY, ACCURACY, RELIABILITY, TITLE, NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, IS MADE IN RELATION TO THE
CONTENT OF THIS DOCUMENT. IN NO EVENT WILL NOKIA BE LIABLE FOR ANY DAMAGES,
INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL
OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS
INTERRUPTION, BUSINESS OPPORTUNITY OR DATA THAT MAY ARISE FROM THE USE OF THIS
DOCUMENT OR THE INFORMATION IN IT, EVEN IN THE CASE OF ERRORS IN OR OMISSIONS
FROM THIS DOCUMENT OR ITS CONTENT.

This document is Nokia proprietary and confidential information, which may not be distributed or disclosed
to any third parties without the prior written consent of Nokia.

Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document
may be trademarks of their respective owners.

Copyright © 2018 Nokia. All rights reserved.

f Important Notice on Product Safety

This product may present safety risks due to laser, electricity, heat, and other sources of danger.

Only trained and qualified personnel may install, operate, maintain or otherwise handle this
product and only after having carefully read the safety information applicable to this product.

The safety information is provided in the Safety Information section in the “Legal, Safety and
Environmental Information” part of this document or documentation set.

Nokia is continually striving to reduce the adverse environmental effects of its products and services. We
would like to encourage you as our customers and users to join us in working towards a cleaner, safer
environment. Please recycle product packaging and follow the recommendations for power use and proper
disposal of our products and their components.

If you should have questions regarding our Environmental Policy or any of the environmental services we
offer, please contact us at Nokia for any additional information.

2 © 2018 Nokia. Nokia confidential. DN98799836 Issue: 4-0

BCF Hardware Database Handling

Table of Contents
This document has 29 pages

Summary of changes..................................................................... 5

1 Overview of BCF hardware database handling..............................6

1.1 BCF hardware database capacity.................................................. 7
1.2 Transferring BCF hardware database files (direct file transfer
connection).....................................................................................9

2 Transferring BCF hardware database files...................................10

3 Modifying BCF hardware database files.......................................11

4 Uploading BCF hardware database files to BSC's disks..............12

4.1 Steps ........................................................................................... 12

5 Bringing a new BCF hardware database into use........................15

6 Removing a BCF hardware database from a BCF.......................22

7 Erasing BCF's non-volatile memory............................................. 26

7.1 Steps ........................................................................................... 26

8 Replacing a BCF hardware database.......................................... 28

8.1 Steps ........................................................................................... 28

9 Verifying a BCF hardware database............................................ 29

DN98799836 Issue: 4-0 © 2018 Nokia. Nokia confidential. 3

 BCF Hardware Database Handling

List of Figures
Figure 1 Management of the BCF hardware database.......................................6
Figure 2 BSC directory tree................................................................................ 8
Figure 3 Uploading BCF hardware database files to BSC's disks.................... 13
Figure 4 Creating a BCF hardware database................................................... 16
Figure 5 Attaching a hardware database to a BCF...........................................18
Figure 6 Activating a BCF hardware database................................................. 21
Figure 7 Detaching a hardware database.........................................................23
Figure 8 Deleting a BCF hardware database................................................... 25
Figure 9 Erasing BCF's non-volatile memory................................................... 27

4 © 2018 Nokia. Nokia confidential. DN98799836 Issue: 4-0

BCF Hardware Database Handling Summary of changes

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

Changes made between issues 4-0 and 3-0

Information on PrimeSite BTSs and 2nd generation BTSs has been removed.

Changes made between issues 3-0 and 2-0

BCF hardware database troubleshooting and Glossary have been removed. The
information has been moved to relevant parts of the document.
No changes have been made due to changes in software.

Changes made between issues 2-0 and 1–1

Changes due to new features

No changes made in the document due to new features.
Changes due to feature enhancements
Removing a BCF hardware database from a BCF:
Command examples with command EVE updated to reflect the change in the syntax of
the command.
Erasing BCF's non-volatile memory:
Added that only Talk-family BTS type support the feature.
Other changes
Structural changes.
The 'Outputting hardware database information' section removed because the
procedures consist of a single command, which can be found in the MML manuals.

DN98799836 Issue: 4-0 © 2018 Nokia. Nokia confidential. 5

Overview of BCF hardware database handling BCF Hardware Database Handling

1 Overview of BCF hardware database handling

The Base Station System (BSS) consists of BTS sites and at least one BSC. 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 site, including all its units. A BTS
site can be sectorised: one BCF can include more than one BTS. If there is only one
BTS in the BTS site, it is a non-sectorised or omnisite.
In Nokia's implementation of the BSS, a BTS site can consist of several logical BTSs.
One entity takes care of all the common functions of the BTSs on one BTS site. This
entity is called a Base Control Function (BCF), which can be seen as the common brain
of several BTSs. The main tasks of a BCF are base station operation and maintenance
functions such as software loading, unit configuration and alarm handling. Therefore,
here the term BCF is used for the functional entity that offers the O&M functions of the
BTS network element. The BCF communicates with the BSC via the Abis O&M interface.

Figure 1 Management of the BCF hardware database

BSC BCFHW
DATABASE

BCF-MMI

RS232/LAN

Abis

BCF

BCF

BCF-MMI

RS232
The BCF hardware database contains an accurate description of the device
configuration of the BCF. The database is stored in the BCF's non-volatile memory.
Databases are managed at the BSC and they are loaded to the BCF when necessary.
BCF hardware database handling is needed particularly when

• the configuration of the BTS site is changed

• a new BTS site is taken into use

6 © 2018 Nokia. Nokia confidential. DN98799836 Issue: 4-0

BCF Hardware Database Handling Overview of BCF hardware database handling

• a BTS site is restarted.

All BCF hardware database management functions can be operated by using local MML
commands at the BSC site or remote MML commands, for example, at the NMS. The
command group EV is used for handling the BCF hardware database. The MML program
used for the BCF hardware database handling is BCF Hardware Database Handling
MML (EV command group).
The BCF hardware database handling uses the operating system, the man-machine
interface system, the I/O system, the file system services, and cellular network
maintenance services. Abis interface is used for communication between the BSC and
the BCF.
These instructions concentrate on the handling of BCF hardware database only. Issues
dealing with BCF software handling are discussed in BCF Software Handling.

Related topics

• Transferring BCF hardware database files

• Modifying BCF hardware database files
• Uploading BCF hardware database files to BSC's disks
• Bringing a new BCF hardware database into use
• Removing a BCF hardware database from a BCF
• Erasing BCF's non-volatile memory
• Replacing a BCF hardware database
• Verifying a BCF hardware database

1.1 BCF hardware database capacity

The BCF hardware configuration is controlled in the databases in the BSC. There is one
subdirectory in the BSC's disks for all the BCF hardware databases of the BSS
(/BCF_PACK/HWDATA).
Refer to figure BSC directory tree for information on the directory structure.

DN98799836 Issue: 4-0 © 2018 Nokia. Nokia confidential. 7

Overview of BCF hardware database handling BCF Hardware Database Handling

Figure 2 BSC directory tree

ROOT

SCMANA BCF_PACK DX200pack DX200pack ...

PACK_0 PACK_1 ... PACK_39 HWDATA

-MASTERFILE -HWDB ASCIIFILES

- APPLICATION -HWDBBINARY FILES
FILES
The capacity of the BCF hardware database management files limits the number of BCF
hardware databases that can be created into a BSC.
There are two management files for the BCF hardware databases in the BSC.

• The BCF Hardware Database Management File (HDMFIL) contains information on

all hardware databases that are located and created on the BSC's disks.
• The BCF Hardware Database Configuration File (HDCFIL) contains information on
the BCFs' hardware database configuration.

Hardware database management files are maintained on the BSC's disks.

The BSDATA (BSS Radio Network Configuration Database) limits the number of BCFs.
The capacity of the management files is as follows:

• the maximum number of BCFs created in a BSC depends on the BSC configuration
(for more information, see Product Description of base station Controller BSC2i,
BSCi and Product Description of base station Controller BSC3i.)
• the maximum number of hardware databases created in a BSC is 256
• the maximum size of a hardware database file is 100 kb.

At any one time there can be only one BCF hardware database management command
that is run in the BSC's OMU, but one command can handle several BCFs at the same
time.
There can be 16 parallel BCF hardware database download operations at the same time.
It is possible to load the same database to several BCFs as a background operation.
Different databases can be loaded parallel to several BCFs during, for example, BSS
system restart.
There can be only one BCF hardware database upload operation at a time.
For an overview, see Overview of BCF hardware database handling.

8 © 2018 Nokia. Nokia confidential. DN98799836 Issue: 4-0

BCF Hardware Database Handling Overview of BCF hardware database handling

1.2 Transferring BCF hardware database files (direct

file transfer connection)

The BSC supports direct connection from the BCF-MMI PC to the BSC's disks, since
hardware database uploading and downloading is implemented in the BSC. The BCF
Remote MMI is an application software that offers an RS232 interface to the BCF-MMI at
the BSC site. From the NMS to the BSC, Remote MMI connection is offered over the
X.25/LAN. The connection between MMI-PC and NMS is based on LAN. For further
information, see BCF Remote MMI.

Uploading hardware database files from BSC to BCF Remote MMI

At the beginning of uploading, the BSC checks that the required file is in the BSC's
system disk. After that the file is transferred to the MMI PC using the same scenarios as
in downloading to the BCF. Only the binary file is uploaded.
For more detailed information, see BCF Remote MMI.

Downloading hardware database files from BCF Remote MMI to BSC

At the beginning of downloading, the BSC checks that there are no files on the BSC's
disks with the same name as the file to be downloaded. After that the file is transferred
from the MMI PC using the same scenarios as in uploading from the BCF. Only the
binary file is downloaded.
For more detailed information, see BCF Remote MMI.

For more information, see Transferring BCF hardware database files.

For an overview, see Overview of BCF hardware database handling.

DN98799836 Issue: 4-0 © 2018 Nokia. Nokia confidential. 9

Transferring BCF hardware database files BCF Hardware Database Handling

2 Transferring BCF hardware database files

Purpose
You need a personal computer (PC) in order to edit the hardware database files. First,
however, you must transfer the database files from the BSC's disk to the MMI-PC. The
editing is done with the BCF-MMI program. For further information, see DE 21/DF 12/DG
26 BTS MMI User Manual and Nokia PrimeSite BTS Man-Machine Interface User's
Guide, and Nokia PrimeSite BTS Hardware Database Editor User's Guide.
The DOSDX application is used when copying files from the floppy disk to the PC.
DOSDX is an MS-DOS application which the user can use to convert files between the
MS-DOS and DX 200 formats. DOSDX is needed when transferring files between a
personal computer (PC) and a BSC.
For an overview, see Overview of BCF hardware database handling.
For more information, see Transferring BCF hardware database files (direct file transfer
connection).

10 © 2018 Nokia. Nokia confidential. DN98799836 Issue: 4-0

BCF Hardware Database Handling Modifying BCF hardware database files

3 Modifying BCF hardware database files

Purpose
The file names in the PC during hardware database editing have differences depending
on the BTS site type. The differences are explained below.
For an overview, see Overview of BCF hardware database handling.

DN98799836 Issue: 4-0 © 2018 Nokia. Nokia confidential. 11

Uploading BCF hardware database files to BSC's disks BCF Hardware Database Handling

4 Uploading BCF hardware database files to

BSC's disks
Expected outcome
The BCF hardware database upload is successful.
Unexpected outcome

1. If the status of the upload command is Ongoing SW operation in the

BFC/HW operation interrupted by SW operation, the database
uploading is prevented or interrupted by software build operation. In such a case,
check the software operation state with the EWI command. Try uploading later when
software operation is finished.
2. If the status of the upload command is File already exists, give the EVU
command with the new file names or with the parameter REP.
3. If the status of the upload command is Files are already included in
created database, change the file name of the files to be uploaded or, if
possible, delete the hardware database with the EVD command with the DSK
parameter.
4. If the status of the upload command is Error in database creation, create
the database by hand with the EVC command, as described in the task Creating a
BCF hardware database.
5. If the status of the upload command is something else than those mentioned before,
check the condition of the O&M links and the BCF with the following commands:
USI, DTI, EFO.
Try again when the fault has been corrected.

Further information
For an overview, see Overview of BCF hardware database handling.

4.1 Steps

1 Check that the required BCF hardware database file or files are located on the BSC's
disks (in the directory: /BCF_PACK/HWDATA).

2 Display the directory (IWX).

Use the IWX command to display the directory.

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

12 © 2018 Nokia. Nokia confidential. DN98799836 Issue: 4-0

BCF Hardware Database Handling Uploading BCF hardware database files to BSC's disks

3 Upload the hardware database (EVU).

Use the EVU command to upload the hardware database.

ZEVU:10:NAME=TEST00,EXT=010;
Where:
ZEVU:<BCF identity>:NAME=<file name>,EXT=<file extension>;
With the EVU command you upload the hardware database file(s) from the non-
volatile memory of the BCF to the BSC's disks as a background operation without
disturbing ongoing calls. All required files can be uploaded with one command. You
can overwrite the old file(s) with the new one(s).
You can create a new BCF hardware database in connection with the upload
command. Creation with the upload command is possible only if the BCF hardware
databases are uploaded one at a time. You attach the created hardware databases
to the BCFs in which they are used. As default, the hardware database is not
created.
The BSC uses temporary files during upload and does not write the files to the disks
with their original names until the file transfer has been completed successfully. The
system starts the uploading if the BCF has been created, the O&M link is in working
state and the BCSU load rate is not too high. It first checks if the files are already
located on the BSC's disks (directory: /BCF_PACK/HWDATA). If the files already
exist and you have not asked for a replacement, the uploading is interrupted. If the
files are already included in another database, the uploading is not possible.
If the creation of a new BCF hardware database is requested after a successful
uploading, the system creates it as described in Creating a BCF hardware database.

Figure 3 Uploading BCF hardware database files to BSC's disks

BSC BTS

BCFHWDB: BCF-HW:
B SW J DB
DBID: J
NAME: BOMNI1 PAS - - SW
EXT: 067 RAM
ACT J
BCFHWDB:
B SW J DB
DBID:
NAME: BOMNI2 A SW
EXT: 068 FLASH

Commandsyntax:
EVU: <numberofBCF>:
NAME=<filename>,
EXT=<fileextension>,
DBID=<databaseid>:
[<uploadmode>];
Example:
EVU:1:NAME=BOMNI2,EXT=068;
If the command execution was not successful, consult the instructions in section
Unexpected outcome.

DN98799836 Issue: 4-0 © 2018 Nokia. Nokia confidential. 13

Uploading BCF hardware database files to BSC's disks BCF Hardware Database Handling

4 Check the upload (IWX).

Use the IWX command to check the upload.

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

14 © 2018 Nokia. Nokia confidential. DN98799836 Issue: 4-0

BCF Hardware Database Handling Bringing a new BCF hardware database into use

5 Bringing a new BCF hardware database into

use
Purpose
Bringing a new BCF hardware database into use includes the procedures listed below.
For an overview, see Overview of BCF hardware database handling.

Creating a BCF hardware database

Before you start
Before you start to bring a new BCF hardware database into use, the following initial
conditions should be met:

• the BSC's OMU is in the normal working state (WO-EX) (the USI command).
• both of the BSC's disks are in the normal working state (WO-BU) (the ISI
command).
• the BCF object has been created in the BSDATA (the EEI command).
• the new BCF hardware database is located in the HWDATA subdirectory on the
BSC's disks in DX 200 format (the IWX command).

Expected outcome
The BCF hardware database creation is successful.
Unexpected outcome

1. If the error code is Error in physical file inquiry, use the ISI command to check that
both BSC's disks are in working state. Correct the situation and try the creation
again.
ZISI::WDU;
You can also use the IWX command to check that the files are located in the
directory /BCF_PACK/HWDATA on both BSC's disks.
ZIWX::WS,NODEF:BCF_PACK,HWDATA:%,%;
If the files are not found, copy the files in the directory on both BSC's disks with the
IWY and IBC commands.
2. If the error code is File locking failed, the database is created successfully,
but the files included in it are not locked. In such a case, you can delete the created
database with the EVD command and try to create it again, if required.
3. If the error code is Database already created, the BCF hardware database is
already defined. In such a case, give the database creation command again but
change the database ID. If there is no attachment to that database, it is possible to
delete the old one with the EVD and to try the creation again.
4. If the error code is Files are already locked to another database,
check the files with the EVL command. Delete the database in which the files are
included if necessary with the EVD command. Try the creation again.

DN98799836 Issue: 4-0 © 2018 Nokia. Nokia confidential. 15

Bringing a new BCF hardware database into use BCF Hardware Database Handling

Steps

1 Create the hardware databases (EVC).

Use the EVC command to create the hardware databases.

ZEVC:BTS10HW:NAME=TEST00,EXT=010;
Where:
ZEVC:<database ID>:NAME=<file name>,EXT=<file extension>;
During the creation the system checks that the required files are stored to both disks
of the BSC. The BSC then locks the disk file(s) of the created database to prevent
writing and deleting and adds a new hardware database ID to the HDMFIL (BCF
Hardware Database Management File).
The database ID is an identity string that is used for identifying different BCF
hardware databases in the BSC unambiguously. The same database ID can be used
in different BSCs at the same time.
If the file locking fails, the system informs you of the error in the MML messages
showing normal creation output and a DX error text. The system creates the
database normally, but you should delete it (EVD command) and try the procedure
again.
The system checks the generation of the hardware database in the header of the
binary file.

Figure 4 Creating a BCF hardware database

BSC BTS

BCFHWDB: BCF-HW:
B SW J DB
DBID: J
NAME: BOMNI1 PAS - - SW
EXT: 067 RAM
ACT J
BCFHWDB:
B SW J DB
DBID: K
NAME: BOMNI2 A SW
EXT: 068 FLASH

Commandsyntax:
EVC: <databaseid>:
NAME=<filename>,
EXT=<fileextension>;
Example:
EVC:K:NAME=BOMNI2,EXT=068;
A new database has been created.

16 © 2018 Nokia. Nokia confidential. DN98799836 Issue: 4-0

BCF Hardware Database Handling Bringing a new BCF hardware database into use

2 Check the created hardware databases (EVL).

Use the EVL command to check the created hardware databases.

ZEVL;
The command has no parameters.

Further information
The BSC updates also the binary file header according to the file name on the BSC's
disks when creating a new hardware database. So the name also appears when you
want to output the contents of the non-volatile memory with the BCF-MMI program.
For an overview, see Overview of BCF hardware database handling.

Attaching a BCF hardware database to a BCF

Purpose
You must attach the successfully created hardware database to the passive status of the
BCF.

Further information
For an overview, see Overview of BCF hardware database handling.

Steps

1 Check that the BCF has been created and that the passive status is empty (EVO).

Use the EVO command to check that the BCF has been created and that the passive
status is empty.
ZEVO:10;
Where:
ZEVO:<BCF identity>;
You can only attach a created hardware database to the passive status of the BCF.

2 If there is a passive database, detach it, if necessary (EVE).

If there is a passive database, use the EVE command to detach it, if necessary.
For more information, see Detaching a BCF hardware database from a BCF.

DN98799836 Issue: 4-0 © 2018 Nokia. Nokia confidential. 17

Bringing a new BCF hardware database into use BCF Hardware Database Handling

3 Attach the hardware database (EVA).

Use the EVA command to attach the hardware database.

ZEVA:10:BTS10HW:;
Where:
ZEVA:<BCF identity>:<database ID>;
During this operation, the database ID is updated to the status field of the BCF
record in the HDMFIL. The same database can be attached to several BCFs at the
same time.
In the attachment the database and the BCF types must be the same, otherwise the
attachment is interrupted.
If the attachment is executed successfully, the system updates information in the
HDCFIL (BCF Hardware Database Configuration File) and increases the attachment
counter of the database in the HDMFIL.

Figure 5 Attaching a hardware database to a BCF

BSC BTS

BCFHWDB: BCF-HW:
B SW J DB
DBID: J
NAME: BOMNI1 PAS K - SW
EXT: 067 RAM
ACT J
BCFHWDB:
B SW J DB
DBID: K
NAME: BOMNI2 A SW
EXT: 068 FLASH

Commandsyntax:
EVA: <numberofBCF>:
<databaseid>;
Example:
EVA:1:K;
If the command was not successful, check the error code in General Error Messages
of System.
Correct the situation and try again.

Activating a BCF hardware database

Purpose
After attaching a BCF hardware database to a BCF you must activate it when it is going
to be used.

18 © 2018 Nokia. Nokia confidential. DN98799836 Issue: 4-0

BCF Hardware Database Handling Bringing a new BCF hardware database into use

Steps
Expected outcome
BCF hardware database activation is successful.
Unexpected outcome

1. The starting phase of the operation is denied: DOWNLOAD DENIED. Check the info
field. If it says: a) “Unfinished SW operation”, wait until the operation is finished. Then
try the activation again; b) “Load rate”, the load rate of the BCSU is too high. Wait for
a while until the load rate decreases; c) O & M link state”, check the O & M link state
and correct it. The state of the link has to be WO-EX. Begin the activation again.
2. The end phase of the operation is DOWNLOAD STARTED/DOWNLOAD COMPLETED.
Background downloading has failed. Try the activation again.
3. The end phase of the operation is SAVE STARTED/SAVE COMPLETED. The
hardware database saving has failed. Try the activation again.
4. The end phase of the operation is RESET REQUEST SENT. Reset request has
been sent but there is a problem with the resetting of the BCF. The activated
hardware database has been set as active, but has not been taken into use in the
BCF. Try to restart the BCF with the EFR command.
5. The BCF site does not recover back to WO state after resetting. Check if the alarm
7730 (CONFIGURATION OF BCF FAILED) has been set. If it has, the database is
incorrect and you must take the correct database into use. Without any action from
the user, the BCF restarts automatically after ten minutes. If it has not, check the
possible errors and try again.

1 Make sure that there are no local modifications made on the BCF site (EOH).

Use the EOH command to check it in the alarm history or from the non-volatile
memory of the BCF.
ZEOH::NR=7207;

2 Activate the hardware database (EVV).

Use the EVV command to activate the hardware database.

ZEVV:10:PAS:SITE;
Where:
ZEVV:<BCF identity>:<database status>:<activation mode>;
The database status is the activity state of a hardware database, which is located on
a disk and created with an MML command. The database has an activity state
known as its status when it is attached to the BCF. The status can be:
• PASSIVE (PAS)
The passive status is the status of a hardware database located on a disk and
attached to a BCF to be taken into use.
• ACTIVE (ACT)

DN98799836 Issue: 4-0 © 2018 Nokia. Nokia confidential. 19

Bringing a new BCF hardware database into use BCF Hardware Database Handling

The active status is the status of a hardware database that has been activated
and is in use. It is possible that local modifications have been made using the
BCF-MMI at the BCF site, in which case the locally installed hardware database
is used during BCF restart.
You can select the database to be activated by giving its status. You can also select
the mode of the activation. It is possible to activate the database only in the
management system in the BSC that has no activities to the BCF. In addition, you
can transfer the activated database to the BCF with or without resetting the BCF at
the end. If the database is to be downloaded to the BCF, the downloading is done as
a background operation without disturbing ongoing calls.
You can proceed with the activation operation without unnecessary downloading to
the BCF using the corresponding activation mode parameter in connection with the
activation command. If you request an activation without downloading, the system
updates the activation to the HDCFIL without any actions towards the BCF. During
normal BCF hardware database activation, the system downloads the hardware
database files from the BSC's system disk to the non-volatile memory of the BCF as
a background operation. Only the binary file downloading is required.
The system starts the activation with downloading if the O & M link is in working state
and the BCSU load rate not too high, and if there is no ongoing BCF software
downloading in the BCF.
Disk operations have been optimised so that the first download operation reads the
database file(s) from a disk to the random access memory (RAM) of the BSC's
operation and maintenance unit (OMU). The database files are maintained in the
RAM buffer when the download has been completed. Subsequent download
operations are done directly from the RAM buffer without using disk files.
When the database file or files are successfully transferred to the non-volatile
memory of the BCF, the system updates the activation information in the HDCFIL. If
there already has been an active BCF hardware database and you want to activate a
passive one, the databases are swapped. In other words, the active database
becomes passive and the passive database active.
After the file downloading, the system restarts the BCF with the new hardware
database if you have so commanded with the activation mode parameter. With the
OMU reset, the ongoing calls are not disturbed and only the BCF unit controller is
restarted. In order to deliver the new hardware database to all TRXs, you must use
the SITE reset value in the activation mode parameter. The SITE reset cuts all
ongoing calls. During ongoing operation, you can check the activation phase
information step by step.
The maximum number of simultaneous operations is restricted to 16. In other words,
activations can be started until there are 16 ongoing activations. However, you can
give more than 16 BCFs as input to the EVV command, because the first activations
may end before the last are entered. After the activation with downloading, local
modifications that have been performed on the BCF site are lost. Therefore, it is
recommended that you check local modifications before the activation operation. You
can check the modifications in the alarm history (EOH command). When you have
made local modifications on the BCF site, the alarm 7803 (LOCAL
CONFIGURATION SAVED TO FLASH) is set. In addition, it is possible to compare
the local hardware database and the active hardware database defined in the BSC.
You can check the contents of the non-volatile memory of the BCF by using the BCF
remote MMI.
For further information, see BCF Remote MMI and DE 21/DF 12/DG 26 BTS MMI
User Manual.

20 © 2018 Nokia. Nokia confidential. DN98799836 Issue: 4-0

BCF Hardware Database Handling Bringing a new BCF hardware database into use

Figure 6 Activating a BCF hardware database

BSC BTS

BCFHWDB: BCF-HW:
B SW K DB
DBID: J
NAME: BOMNI1 PAS J K SW
EXT: 067 RAM
ACT K
BCFHWDB:
B SW K DB
DBID: K
NAME: BOMNI2 A SW
EXT: 068 FLASH

Commandsyntax:
EVV: <numberofBCF>:
<databasestatus>:
[<activationmode>];
Example:
EVV:1:PAS:SITE;

3 Check the command printout.

If the end result is something else than that the operation has been completed, see
the instructions in section Unexpected outcome for more information.

4 Check the BCF's operational state (EEI).

Use the EEI command to check that the BCF's operational state receives the value
WO.
ZEEI:BCF=10;

Incorrect hardware database in use

If the BCF hardware configuration differs from the configuration in the hardware
database in use, the BCF cannot continue the restarting. The alarm 7730
(CONFIGURATION OF BCF FAILED) is set and the BCF waits for 10 minutes for any
action from the BSC before a new restart.
During those 10 minutes, you can activate a new hardware database to the BCF. The
system downloads and saves the hardware database to the non-volatile memory of the
BCF. After that the system restarts the BCF normally, as described in the activation
operation. If required, the hardware database files can also be uploaded from the non-
volatile memory of the BCF to the BSC's disks during that time. If needed, you can erase
the contents of the non-volatile memory.
For an overview, see Overview of BCF hardware database handling.

DN98799836 Issue: 4-0 © 2018 Nokia. Nokia confidential. 21

Removing a BCF hardware database from a BCF BCF Hardware Database Handling

6 Removing a BCF hardware database from a

BCF
Purpose
Removing a BCF hardware database from a BCF includes the procedures listed below.
For an overview, see Overview of BCF hardware database handling.

Detaching a BCF hardware database from a BCF

Further information
For an overview, see Overview of BCF hardware database handling.

Steps

1 Detach the hardware database (EVE).

Use the EVE command to detach the hardware database.

ZEVE:10:;
Where:
ZEVE:<BCF identity>:<hw db status | PAS def>;
If the detachment is executed successfully, the system updates information in the
HDCFIL and decreases the attachment counter of the database in the HDMFIL.

22 © 2018 Nokia. Nokia confidential. DN98799836 Issue: 4-0

BCF Hardware Database Handling Removing a BCF hardware database from a BCF

Figure 7 Detaching a hardware database

BSC BTS

BCFHWDB: BCF-HW:
B SW K DB
DBID: J
NAME: BOMNI1 PAS - SW
EXT: 067 RAM
ACT K
BCFHWDB:
B SW K DB
DBID: K
NAME: BOMNI2 A SW
EXT: 068 FLASH

Commandsyntax:
EVE: <numberofBCF>:
[<hwdbstatus>|PASdef];
Example:
EVE:1:;
In the detachment process the statuses of the hardware databases can be passive,
active or both active and passive.

2 List existing databases (EVL).

Use the EVL command to list existing databases

ZEVL;
The command has no parameters.
If the connection counter is zero, it is possible to delete the detached hardware
database.

3 If the command execution was not successful, check the error code from General Error
Messages of System.

4 Correct the situation and try again.

Deleting a BCF hardware database

Expected outcome
The BCF hardware database is deleted successfully.
Unexpected outcome

DN98799836 Issue: 4-0 © 2018 Nokia. Nokia confidential. 23

Removing a BCF hardware database from a BCF BCF Hardware Database Handling

1. If the error code is Physical file(s) not deleted, delete database files
with the IWD command of the I/O system.
2. If the error code is something else, check the error code in General Error Messages
of System, correct the situation and try again.

Further information
For an overview, see Overview of BCF hardware database handling.

Steps

1 Delete the hardware database (EVD).

Use the EVD command to delete the hardware database.

ZEVD:TEST:DSK;
Where:
ZEVD:<database ID>:<deleting mode>;
As default, no database files are deleted
It is possible to delete hardware database information from the HDMFIL and physical
database file(s) from the subdirectory with the same delete command. The system
removes the protection of database file(s) although only database information is
deleted. A database cannot be deleted if it is attached to a BCF.
The system removes the BCF hardware database ID from the HDMFIL and unlocks
the files included in the database. If you requested file deletion, the system deletes
the file or files from both BSC's disks.
The system deletes the BCF hardware database from the HDMFIL even if the
physical file deletion fails.
If physical file deletion is necessary, use the DSK parameter.

24 © 2018 Nokia. Nokia confidential. DN98799836 Issue: 4-0

BCF Hardware Database Handling Removing a BCF hardware database from a BCF

Figure 8 Deleting a BCF hardware database

BSC BTS

BCFHWDB: BCF-HW:
B SW K DB
DBID:
NAME:
EXT:
PAS - - SW
RAM
ACT K
BCFHWDB:
B SW K DB
DBID: K
NAME: BOMNI2
EXT: 068
A SW
FLASH

Commandsyntax:
EVD: <databaseid>:
[<deletingmode>];
Example:
EVD:K:DSK;

2 If the status of the deletion was not successful, consult the troubleshooting instructions.

DN98799836 Issue: 4-0 © 2018 Nokia. Nokia confidential. 25

Erasing BCF's non-volatile memory BCF Hardware Database Handling

7 Erasing BCF's non-volatile memory

Before you start
The BCF's memory consists partly of a non-volatile memory, which is not erased if the
power supplies fail. It is possible to save information into that memory by a program. The
hardware database and the BCF's software have been saved into that memory. The non-
volatile memory is often called a FLASH memory.

Expected outcome
The BCF's non-volatile memory is erased successfully.
Unexpected outcome

1. Depending on the error, check the condition of the O&M links with the DTI command
and the state of the BCF with the EFO command. Try again when the fault has been
corrected.

Further information
For an overview, see Overview of BCF hardware database handling.

7.1 Steps

1 Make sure that the correct hardware database is found in the BSC and that it is available
for usage after non-volatile memory erasure.

2 Erase the contents of the non-volatile memory (EVR).

Use the EVR command to erase the contents of the non-volatile memory.
ZEVR:10:ALL;
Where:
ZEVR:<BCF identity>:<erasing mode>;
The erasing mode tells if it is only the hardware database or only the software
build(s) that will be erased, or both.
If you erase the contents of the non-volatile memory, the software build will be
downloaded from the BSC to the BCF during the next BCF restart if an active
database has been defined for that BCF in the BSC. The active database can be
downloaded to the non-volatile memory of the BCF. If the hardware database was in
the non-volatile memory before erasing, the next BCF restart cannot be finished
without an active database. The database must be defined for the BCF either in the
BCF hardware database system or in the BCF software build, which is loaded during
restart. If no active hardware databse is defined, the BCF tries to use the hardware
database that was possibly loaded within the software build.

26 © 2018 Nokia. Nokia confidential. DN98799836 Issue: 4-0

BCF Hardware Database Handling Erasing BCF's non-volatile memory

Figure 9 Erasing BCF's non-volatile memory

BSC BTS

BCFHWDB: BCF-HW:
B SW K DB
DBID:
NAME: PAS - - SW
EXT: RAM
ACT K
BCFHWDB: SW DB
DBID: K
NAME: BOMNI2 SW
EXT: 068 FLASH

Commandsyntax:
EVR: <numberofBCF>:
<erasingmode>;
Example:
EVR:1:ALL;

3 Check the contents of the non-volatile memory.

You can check the contents of the non-volatile memory with BCF remote MMI.
This is described in BCF Remote MMI and in DE 21/DF 12/DG 26 BTS MMI User
Manual.
If the erasing was not successful, consult the troubleshooting instructions. See
section Unexpected outcome for more information on the subject.

DN98799836 Issue: 4-0 © 2018 Nokia. Nokia confidential. 27

Replacing a BCF hardware database BCF Hardware Database Handling

8 Replacing a BCF hardware database

Further information
For an overview, see Overview of BCF hardware database handling.

8.1 Steps

1 Check that both the new and the old database have been created (EVL).

Use the EVL command to check that both the new and the old database have been
created.
ZEVL;
The command has no parameters.

2 Check which BCFs use the old hardware database and check that the databases are of
the same type (EVT).

Use the EVT command to check which BCFs use the old hardware database and
check that the databases are of the same type.
ZEVT:TEST;
Where:
ZEVT:<database ID>;

3 Replace the hardware database (EVS).

Use the EVS command to replace the hardware database.

ZEVS:ODB=TEST,NDB=BTS10HW;
Where:
ZEVS:ODB=<old database ID>,NDB=<new database ID>;
The system updates information in the HDCFIL and in the HDMFIL

4 Check the status of the command.

If it is not successful, check the error code from General Error Messages of System,
correct the situation and try again.

28 © 2018 Nokia. Nokia confidential. DN98799836 Issue: 4-0

BCF Hardware Database Handling Verifying a BCF hardware database

9 Verifying a BCF hardware database

After the software downloading during the BCF restart, the BCF sends a verification
request to the BSC. The message includes the name and version of the hardware
database binary file in the non-volatile memory of the BCF or a possible hardware
database download request.
There are three different operation sequence options, depending on how the hardware
databases are used:
For an overview, see Overview of BCF hardware database handling.

Verifying a BCF hardware database when it is found in the non-volatile memory

The BSC compares the file name and the version of the verification request with the
active hardware database of the BCF.
If the names differ, the BSC sets the alarm 7716 (ACTIVE BCF HW DATABASE
DIFFERENCE). In any case, despite the possible differences, the BCF uses the
database found in the non-volatile memory.

Verifying a BCF hardware database when it is not found in the non-volatile

memory
When the hardware database is not located in the non-volatile memory, the system asks
for the database downloading in the verification request. Then the BSC downloads the
active database to the BCF.

Verifying a BCF hardware database when it is not found in the non-volatile

memory and there is no active hardware database defined in the BSC
If the active BCF hardware database was not defined in the BSC, the BCF uses the
hardware database that was loaded in the software build. After verification request
handling, the reset scenario continues according to the configuration request of the BCF.

DN98799836 Issue: 4-0 © 2018 Nokia. Nokia confidential. 29