You are on page 1of 28

OSS Operation

Chapter 3

This chapter is designed to provide the student with an overview


of the parts of the Operation Support System (OSS) that
provide them radio network management. Elements specifically
addressed in this module are Cellular Network Administration
(CNA) and Cellular Network Administration Interface
(CNAI).

OBJECTIVES:
Upon completion of this chapter the student will be able to:

• understand the concepts of CNA and CNAI


• understand how to modify the network
CME 20/CMS 40 BSC Operation & Maintenance

t io
e n na
lly
t
In

Bl n
a
k

EN/LZT 123 3330 R1B


3 OSS Operation

3 OSS Operation
Table of Contents

Topic Page

CELLULAR NETWORK ADMINISTRATION OVERVIEW ..................91


DIFFERENT AREAS IN CNA .......................................................................................91
DIFFERENT DATA DESIGNATIONS...........................................................................92
COMMON USE PROCEDURES ..................................................................................96
COMMON LAYOUTS ...................................................................................................96
AUTHORITY CATEGORIES ........................................................................................96

CNA INTERFACE (CNAI) OVERVIEW................................................97


AUTHORITY CATEGORIES ........................................................................................97
SCOPE / LIMITATIONS................................................................................................98

BTS CONFIGURATION MANAGEMENT (BCM) OVERVIEW ............98


BTS MANAGEMENT APPLICATIONS.........................................................................98

MO INFORMATION MODEL .............................................................100


UPDATE BY MEANS OF THE PLANNED CONFIGURATION CONCEPT................100
COMMON USE PROCEDURES ................................................................................101
COMMON LAYOUTS .................................................................................................101
AUTHORITY CATEGORIES ......................................................................................102

BTS HARDWARE MANAGEMENT (BHW) OVERVIEW...................103


DIFFERENT CONFIGURATION TYPES IN BHW......................................................105
COMMON USE PROCEDURES ................................................................................105
AUTHORITY CATEGORIES ......................................................................................106

BTS ALARM MANAGEMENT (BAM) OVERVIEW ...........................107


DIFFERENT CONFIGURATION TYPES IN BAM ......................................................109
COMMON USE PROCEDURES ................................................................................110
AUTHORITY CATEGORIES ......................................................................................110

BTS SOFTWARE MANAGEMENT (BSW) OVERVIEW....................112

EN/LZT 123 3330 R1B –i–


CME 20/CMS 40 BSC Operation & Maintenance

AUTHORITY CATEGORIES ......................................................................................113

t io
e n na
lly
t
In

Bl n
a
k

– ii – EN/LZT 123 3330 R1B


3 OSS Operation

CELLULAR NETWORK ADMINISTRATION OVERVIEW


The Cellular Network Administration (CNA) function is used
for retrieving information, viewing and planning the structure of
a cellular network. It is also used for adjusting the network to
optimize its performance. A model of the real cellular network is
stored in the Operation and Support System’s (OSS) database.
This model consists of data (parameters) structured as objects in
hierarchical levels reflecting the real cellular network.

CNA provides an easy and user-friendly way to retrieve


information and adjust the parameters in the cellular network. It
is possible to create, delete, and change new objects and display
parameter data in the CNA Model without interfering with the
existing network elements. The cellular network can be
presented both in text lists in the base window and as a graphic
map in the Graphic Cell Display (GCD). The following
functions in CNA are reached through the user interface
described in this document:

• Retrieving information
• Adjusting the CNA model
• Planning tasks
• Updating the cellular network
• Checking consistency
• Displaying the GCD

DIFFERENT AREAS IN CNA


CNA handles different areas when administrating the real
network. Actions are performed on different types of cellular
network areas defined as follows:

Valid Area: The valid area is a model of the actual network.


This area makes it possible to retrieve information from the
network without interfering with it. The adjust function is used
to transfer accurate data from the network into the valid area.
When the network is updated with a planned area, the valid area
is automatically updated as well.

EN/LZT 123 3330 R1B – 91 –


CME 20/CMS 40 BSC Operation & Maintenance

Planned Area: A planned area is an area in which the user can


change, create, delete objects, etc. without interfering with the
real network. It is then possible to update the network with these
changes.

Fallback Area: A fallback area is a complete copy of the valid


area at the moment the fallback area is created. It is used as a
backup for the valid area. The valid area and the network may be
restored by creating a planned area from the fallback area, and
starting an update job from the planned area.

Log Area: A log area is an area created via the PMR application
in which BSCs, internal cells, and their corresponding channel
groups are stored. The purpose of the log area is to keep a record
of all important parameters during a PMR session. Log areas are
only used by PMR users, but are managed through CNA.

Profiles Area: A profiles area is an area in which the CNA user


can create pre-defined internal cells with parameter values.
These internal cells may be used as templates when creating
internal cells in a planned area.

DIFFERENT DATA DESIGNATIONS


It is important to know that different data is used by the Base
Station Controller (BSC) and the Mobile Services Switching
Center (MSC), as well as for the area. Different designations
are used in order to distinguish between different cell data when
administrating the cellular network. The following data
designations are used:

• Internal cell
• Overlaid subcell
• Underlaid subcell
• Internal cell of umbrella type
• Internal cell of micro type
• External cell
• External cell of umbrella type
• External cell of micro type
• Neighbor relation
• Inner cell

– 92 – EN/LZT 123 3330 R1B


3 OSS Operation

• Outer cell
• Foreign cell
• Foreign cell of umbrella type
• Foreign cell of micro type
• Neighboring cell
• Channel group

Underlaid subcells, micro cells, and umbrella cells are


administrated by an internal cell and are set as parameters for the
internal cell. See the following sections for an explanation of the
different designations used.

Data in the Area


The area contains MSCs, BSCs, and foreign cells administrated
by another Operation and Maintenance Center (OMC).

Foreign Cell: A foreign cell is a cell administrated by another


OMC and is a neighbor to one or more cells administrated by the
OMC in question. Foreign cells can be of type micro, normal, or
umbrella, depending of which type of internal cell they
represent. See the Data in the BSC section for more information
regarding micro and umbrella cell types.

Data in the MSC


The MSC contains inner and outer cells.

Inner Cell: Inner cells contain MSC data associated with the
cell.

Outer Cell: Outer cells are cells that belong to any other MSC
in the PLMN to which it is possible to make a handover from
one or more cells in the selected MSC. An outer cell is only
needed in order to create a neighbor relation to a cell belonging
to another MSC.

EN/LZT 123 3330 R1B – 93 –


CME 20/CMS 40 BSC Operation & Maintenance

Data in the BSC


The BSC contains internal cells, external cells, sites, and
transceiver groups. It also handles data concerning neighbor
relations.

Internal Cell: Internal cells contain BSC data that is associated


with the cell. An internal cell can be set to have a subcell
structure, that is, overlaid and underlaid subcells. It can also be
set to be a micro cell or an umbrella cell. The micro cell and
umbrella cell parameters can be used in combination with a
subcell structure. These cell types are described below.

Overlaid Subcell: An overlaid subcell is used to enhance the


traffic capacity of the PLMN without building new sites. An
internal cell can be divided into an overlaid and an underlaid
subcell. In this way, the internal cell is given a subcell structure.
The overlaid subcell is set to handle traffic in an area smaller
than the total cell coverage area and can thus be seen as a
smaller cell in the center of the internal cell. The remaining area,
surrounding the overlaid subcell, is regarded as an underlaid
subcell. This subcell structure makes it possible to reuse radio
frequencies more frequently. One site can therefore be assigned
a larger number of frequencies than would have otherwise been
possible. An overlaid subcell is created with the same name as
an already existing internal cell, which becomes the underlaid
cell when the subcell structure is defined.

Umbrella Type Internal Cell: An umbrella type internal cell is


intended to handle mobiles that cannot be served by the normal
cells due to congestion or poor radio quality. Umbrella cells are
planned on top of the normal cellular network and are normally
larger than other cells. An umbrella cell is administrated by an
internal cell and is set as a parameter for the internal cell.

Micro Type Internal Cell: A micro type internal cell is a cell in


a network of small cells planned below the normal cell network.
The goal with utilizing a micro type cell is to keep as much
traffic as possible in the lower level cells, optimizing the use of
frequencies in areas where the traffic intensity is very high. For
example, at a traffic light in a city. A micro cell is administrated
by an internal cell and is set as a parameter for the internal cell.

– 94 – EN/LZT 123 3330 R1B


3 OSS Operation

External Cell: External cells are cells that belong to any other
BSC in the PLMN and to which it is possible to make a
handover from one or more cells in the BSC in question. An
external cell is only needed in order to create a neighbor
relationship to a cell belonging to another BSC. External cells
can be micro, normal, or umbrella types depending on which
type of internal cell they represent.

Neighbor Relation: The BSC holds data which defines the


neighbor relationships between cells. This is used to manage
handovers from a serving cell to other cells.

Channel Group: A channel group is a set of radio frequencies.


Each cell and subcell belonging to a BSC must have one or more
channel groups which are connected to a transceiver group. The
set of radio frequencies can be configured for frequency
hopping.

Priority Profile: Priority profiles are used in the Differential


Channel Allocation function. Here it is possible to set the
Inaccessible CHannels (INAC) percentage and the
PRObability of allocation Failure (PROBF) percentage for 16
different PRiority Levels (PRL). Each priority level is set with
a value indicating the number of channels which are accessible
for the priority level, and the probability of failure to allocate the
last accessible channel for the priority level. The inaccessible
channels specified for a priority level are therefore indirectly
reserved for the other priority levels.

Neighboring Cell
A neighboring cell is any cell to which it is possible to make a
handover from the serving cell. A neighbor relationship is
established in order to control the actual handover function.

EN/LZT 123 3330 R1B – 95 –


CME 20/CMS 40 BSC Operation & Maintenance

COMMON USER PROCEDURES


Start CNA by choosing Cellular Network Administration from
the OSS workspace menu. The CNA Base window is opened.

COMMON LAYOUTS
Dimmed menu items or dimmed buttons indicate that a function
is inactive and cannot be selected. If a user does not have
authority to choose certain operations or menu choices, those
choices are not shown. Double-clicking SELECT has a special
function in some cases and can be used as a short-cut for
executing commands.

AUTHORITY CATEGORIES
A CNA user is allowed to be a member of one authority
category only. The Authority Administration system manages
the authority category to which a user belongs. It resides in TPF.
A user may have the authority to run CNA update and
adjustment jobs without having the authority to use the MML
commands for the job question. In such cases, the authority
control system in TPF is only used to check that the user has the
authority to run job via the User Interface, but not issue any
MML commands. The following authority categories are
supported by CNA:

Assistant Operator: A user belonging to this category may


retrieve information from the cellular network using the valid
area. This user also has the authority to perform consistency
checks.

Operator: A user belonging to this category may retrieve


information from the cellular network and plan a cellular
network. Therefore this user has the authority to use the valid
area, to create and load planned areas, to handle fallback, log,
and profiles areas and to perform consistency checks.

Network Operator: A user belonging to this category may


retrieve information from the cellular network, plan, adjust the
valid area, perform consistency checks, and update the network.
This user also has the authority to handle fallback, log, and
profiles areas.

– 96 – EN/LZT 123 3330 R1B


3 OSS Operation

Application Administrator: A user belonging to this category


has access to all functions available for the Network Operator
category. In addition, he can has the authority to perform CNA
administration tasks.

Note! Menu buttons and items are shown or not shown


depending on the user’s authority category.

CNA INTERFACE (CNAI) OVERVIEW


The CNA application in OSS is used for retrieving information,
viewing and planning the structure of a cellular network. It is
also used for updating the network to optimize its performance.
The CNAI application is a file interface operating from a shell
tool in the Open Look environment. The CNAI makes it
possible to automatically exchange data between an external
system and CNA via a data file. An external system can be for
example a cell planning system. The importing and exporting
functions in the CNAI are accessed through the file interface.

The data files used for cell data exchange are called transfer
files. The format of these transfer files is described in Reference
[4] CNA Interface File Format Description, Interwork
Description (IWD). The results of an import or export operation
are always printed in a report file.

Note! File transfer between the external system and the


OMC is not included in the CNAI functions.

AUTHORITY CATEGORIES
The user must belong to one of the following authority
categories:

• Network Designer
• Network Management Operator
• System Administrator

EN/LZT 123 3330 R1B – 97 –


CME 20/CMS 40 BSC Operation & Maintenance

SCOPE / LIMITATIONS
It is possible to administer the cell related data in both R1/R5
and R2/R6 network elements in a cellular network.
Compatibility with the OSS 5.0 and OSS 5.1 towards OSS 6.0 is
as follows:

• A file with cell data generated by the CNAI in OSS 5.0, OSS
5.1, or OSS 6.0 can be imported by the CNAI in OSS 6.0.
• It is not possible to import a file generated by the CNAI in
OSS 6.0 to the CNAI in OSS 5.0 or OSS 5.1.

BTS CONFIGURATION MANAGEMENT (BCM) OVERVIEW


BCM provides the operator with an application to handle BTS
configuration. BCM provides functions for viewing the BTS
structure within BSS, support for taking a BTS into or out of
service and initiating tests on BTS components. BCM is fully
integrated in the common user interface of the BTS
Management applications, thus making use of the common
functionality for BTS Management.

BTS MANAGEMENT APPLICATIONS


BTS Management not only provides BCM functionality, it also
incorporates generic functionality and concepts available in
other BTS Management applications. Thus forming a common
framework for all BTS Management applications. The BTS
Management applications gather information about the MOs
handled by a RBS. For example, information about their
configuration or states. In addition, handling and changing
information can be performed easily.

– 98 – EN/LZT 123 3330 R1B


3 OSS Operation

PLMN

BSC

SITE CELL

TRI CG

TG EMGEM RILT PATH RILCO

CTSLOT

TF IS (2) TRX TX (1) DP (2) CF (2)

(1) RBS 200 only


TX (2) TS RX (2) RBS 2000 only
96

Figure 3-1. Managed MO Information Model (MIN)

EN/LZT 123 3330 R1B – 99 –


CME 20/CMS 40 BSC Operation & Maintenance

MO INFORMATION MODEL
A model of the real cellular network is stored in the OSS
database. This model, displayed in a browser, consists of MOs
structured in hierarchical levels reflecting the actual cellular
network.

UPDATE UTILIZING THE CONFIGURATION PLANNING CONCEPT


The configuration planning concept is based on three existing
configuration types. They are:

Valid Configuration: The valid configuration is the model of


the network at the time of the latest adjustment. It The Valid
Configuration area makes it possible to retrieve information
from the network without interfering with it. This is achieved by
utilizing the adjust function. When the network is updated with
a planned configuration, the valid configuration is not updated
automatically. To update the valid configuration, run the adjust
job.

Planned Configuration: A planned configuration contains


changes made and saved during a valid configuration. The
network can be updated immediately or at a later scheduled time
with the planned configuration. Planned Configurations can be
saved and loaded under a name. If a planned configuration is
edited by a user, it is automatically blocked from use for other
users until another configuration is loaded.

Fallback Configuration: A fallback configuration is a complete


copy of the valid configuration at a given moment. This
configuration can be used as a backup and makes it possible to
make planned configurations from older versions of the valid
configuration. Fallback configurations can also be saved, loaded
and referenced by name. They also can be used for the
scheduling an update jobs.

– 100 – EN/LZT 123 3330 R1B


3 OSS Operation

An adjustment job updates the BSM database with the actual


network data which is loaded into the valid configuration. To
apply changes to the network configuration, the user must
switch over to the planning configuration area by creating a new
planned configuration or by loading an existing one. In this area,
the attributes of the selected MOs can be edited. The changes
made can be applied to the network by starting an update job.
This job can be started immediately with the actual planned
configuration or scheduled at a later point in time. In the latter
case, the planned configuration must be saved under a name.
The update job then references a planned configuration by this
name.

COMMON USER PROCEDURES


Start the desired BSM application by selecting its application
name from the OSS workspace menu. In the base window, a
network model is displayed and in this window commands can
be issued. All operations are easily accessible via menus and
buttons. To issue a command or view the information of a MO,
the corresponding MO must be selected first in the hierarchical
browser which manages and displays the network. Double-
clicking SELECT has a specific meaning in some cases and can
be used as a short-cut for executing commands.

COMMON LAYOUTS
• Unavailable menu items or command buttons are dimmed
• Menu items for actions which require a certain authorization
level are not shown to unauthorized users
• Information about the status of the application or about the
failure or success of operations is displayed in the footer at
the bottom of the window
• Errors or warnings which require immediate action by the
user are displayed in a separate notification window
• Available short-cuts or accelerators for operations are
presented in the interface with the keyboard accelerator keys
next to the name denoting the operation

EN/LZT 123 3330 R1B – 101 –


CME 20/CMS 40 BSC Operation & Maintenance

AUTHORITY CATEGORIES
A BSM applications user is allowed to be a member of one or
several authority categories. The Authority Administration
system manages the authority categories to which a user
belongs. Commands, fields and menu entries are shown or not
shown dependent on the user’s authority level. The following
authority categories are supported by the BSM applications:

Assistant Operator Category: Users belonging to this category


can only view the information stored in the valid configuration.
They are not permitted to interact with the network (that is, to
block or test MOs) or to plan configuration changes.

Operator Category: Users belonging to this category are


permitted to interact with the real network. They may perform
the following interactive operations on the handled MOs:

• block and deblock


• bring in service and take out of service
• perform tests
• reset BSC fault logs
• perform recovery operations
They are not permitted to plan configuration changes.

Application Administrator Category: Users belonging to this


category may initiate configuration changes and changes to the
network structure itself. This means they can create a planned
configuration with deleted, changed, or new MOs and they can
update the network with those changes. Additionally, the
operations provided for the Viewer and Dispatcher Category are
also available for a Network Manager.

System Administrator Category: This user category allows the


administration of user authority and the definition of script for
recovery, for example.

Note! The authority categories are independent from each


other which means the Application Administrator
category does not necessarily include the same
rights that the Assistant Operator and Operator
categories have.

– 102 – EN/LZT 123 3330 R1B


3 OSS Operation

BTS HARDWARE MANAGEMENT (BHW) OVERVIEW


The BHW application is an extended BCM application with
BHW specific functionality. It provides the user with a graphical
interface to retrieve and display all relevant information
concerning installed hardware related MOs in a BTS located at a
certain site. These MOs in BHW are called Replacement Units
(RU). Using BHW, the user can identify RUs and their status. In
RBS 2000, it is also possible to retrieve the serial number for a
RU. In addition, the user can retrieve information from the
network underlying the BHW application but not perform any
changes to the NW. A search facility allows network wide
searches for specific hardware equipment.

Additionally, it is possible to attach user-defined information to


hardware objects and to introduce new RUs. Manually
introduced RUs are called MRUs. Introducing MRUs is a useful
feature if the user wants to manage other important hardware
whose information cannot be retrieved from the NW or other
sources. For example, a user wants to maintain information
about a power supply with a certain revision state on a certain
site. To achieve this, the user creates an MRU object for the site.
When the MRU is created, the user can attach information to it.
Different RU attribute information can be useful, for example.
The new object with its attributes and other user-defined
information is then maintained in the BHW database.

Figure 3-2 illustrates the NW structure managed by the BHW


application within the OSS. It is from this object model that all
hardware relevant information is retrieved. With BHW the user
works on a model of the NW maintained in the application’s
database. The model always mirrors the current NW information
and status at the time of the last adjust. As indicated in Figure 3-
2, the MOs and RUs modeled by BHW are hierarchically
structured and the RU can contain sub-RUs. There can be a
maximum of three hierarchical levels of RUs. This makes it
possible to model the site’s hardware which is composed of a
cabinet and containing magazines which accommodate hardware
boards. Cabinets, magazines, and boards are all regarded as RUs
for which information can be maintained.

EN/LZT 123 3330 R1B – 103 –


CME 20/CMS 40 BSC Operation & Maintenance

SITE

Cabinet RU RU MRU Manually


Introduced RU

Magazine RU RU RU

Hardware Board RUs RU RU

Figure 3-2. Network Structure Managed by BHW

A MRU can only be a subordinate to a site and can, therefore,


only contain one hierarchical level. It is possible to create a
MRU if a site is selected in the Network Browser. The menu
item is dimmed for any other MO types.

Figure 3-3 illustrates the relationship between RU objects and


MO objects. The name of a RU reflects this relationship. A RU
is named according to the name of the MO it belongs to. If there
is more than one RU belonging to the MO, all RUs have the
same name but are indexed 0, 1, 2, . . . , n.

The BHW application also provides the user with a file interface
to import and export hardware related data as plain ASCII files
from and to external systems. More information about these
features are found on the on-line manual pages for the
BSM_IMPORT and BSM_EXPORT functions.

– 104 – EN/LZT 123 3330 R1B


3 OSS Operation

SITE

Cabinet RU RU MRU

Nagazine RU RU RU

Hardware Board RUs RU RU

RU Layers MO Layers

Figure 3-3. Relation between RU and MO Layers

DIFFERENT CONFIGURATION TYPES IN BHW


BHW users should only work in the valid configuration. The
valid configuration models the network at the time of the last
adjustment. It is not possible to create RUs or edit hardware
information in planned or fallback configurations. The different
configuration types are further described in Reference [4] BTS
Configuration Management (BCM), User Guide.

COMMON USER PROCEDURES


As BHW is based on the BCM application and all BHW related
functions are initiated from the BTS Configuration Management
application, BHW is started by selecting BCM from the OSS
workspace menu or by entering the application name on the
command line. During start-up of the application, a start-up
screen is displayed. BHW is active as soon as the base window
appears on the screen.

EN/LZT 123 3330 R1B – 105 –


CME 20/CMS 40 BSC Operation & Maintenance

In the base window, a network model is displayed and


commands can be issued. All operations are easily accessible via
menus and buttons. To issue a command or to view RU
information, it must be selected in the hierarchical Network
Browser which manages and displays the NW in the user
interface. Double-clicking SELECT has a specific meaning in
some cases and can be used as a short-cut for executing
commands.

AUTHORITY CATEGORIES
A BHW user is permitted to be a member of one or several
authority categories. The Authority Administration system
manages the authority categories to which a user belongs.
Depending on the authority of the user, commands, fields, or
menu items are shown or not shown.

Note! The authority categories are independent from each


other which means that the System Administrator
category does not necessarily include the same
rights as the Operator and Assistant Operator
categories.

Assistant Operator: A user belonging to this category has the


authority to:

• Display the contents of the hardware database


• Search for RUs
• Export hardware data

Operator: A user belonging to this category has the same


authority as an Assistant Operator. In addition to this, the user
has the authority to:

• Adjust the BHW database


• Add marks and comments to RUs
• Delete own marks and comments
• Introduce new RUs (MRUs)
• Import hardware data

– 106 – EN/LZT 123 3330 R1B


3 OSS Operation

Application Administrator: A user belonging to this category


has the same authority as an Operator. In addition to this, the
user has the authority to:

• Delete marks and comments made by other users

System Administrator: A user belonging to this category is has


the authority to:

• Take care of the administration of users authorization

BTS ALARM MANAGEMENT (BAM) OVERVIEW


The BAM application provides a consistent and user friendly
way of handling and configuring BTS alarm reports. BTS can
interface with other TMOS applications. For example, Alarm
List Presentation (ALP), Network Status Presentation
(NSP), and Cellular Network Activity Manager (CNAM).
Several alarm configuration and management features allow
reducing the amount of reported alarms and concentrating on the
important ones. The hardware and software structure of a
network can be represented in a hierarchical object model
containing the MOs handled by BAM functions.
(See Figure 3-4).

BSC

SITE SITE

TG TRI

TRX TRX

Figure 3-4. Hierarchical Object Model

EN/LZT 123 3330 R1B – 107 –


CME 20/CMS 40 BSC Operation & Maintenance

BAM offers two interfaces:

• Graphical User Interface: The OpenLook style user interface


offers the functionality for handling alarm configuration
data.
• ASCII Files: BTS error logs and lists of outstanding alarms
can be saved to a file.

BAM is based on the BCM application with BAM specific


functionality. BAM makes use of the BCM base functionality
for handling and configuration of the alarm reporting as well as
handling and administration of the BTSs. In addition, the
following functions are provided by the BAM application:

Alarm Coordination: This feature allows the coordination of


all alarms in a TG, such that only one alarm is presented. (The
alarm with the highest priority.) In addition, a timer interval can
be set where occurring alarms are coordinated in the BSC.
Furthermore, it is possible to mask alarms meaning that certain
alarms types are not forwarded to the OSS.

Alarm coordination data is used for updating the alarm


information in the network. The updates can be set to immediate
or scheduled start. Scheduled start is used either to postpone the
action to a later occasion when the traffic on the network is low
or to establish a regular change of the parameters.

Presentation of Outstanding Alarms: BAM offers the


possibility to present outstanding alarms, which are no longer
forwarded due to the alarm coordination switched on, but are not
masked. These alarms are stored in and can be retrieved from
the BSC. BAM can display the outstanding alarms for single
MOs, or a TG, site, or BSC. The list of outstanding alarms is
presented in an report window that offers the possibility to
create customized lists of outstanding alarms and to print or save
them.

Interfacing with FMA Applications (Drag & Drop to/from


ALP or NSP): The BAM application is intended to be used in
combination with the Fault Management Applications (FMA),
ALP and NSP. Quick navigation to an alarm object is supported
by dragging between NSP or ALP and BAM. It is also possible
to start ALP from the BAM user-interface.

BTS Error Log Administration: Each MO instance in the BTS


has an error log associated with it which records all information
reported from the BTS. These error logs are contained in the
BSC and are not stored locally by BAM. By using the BAM

– 108 – EN/LZT 123 3330 R1B


3 OSS Operation

application, error logs can be retrieved and displayed. BAM also


allows the user to save error logs to a file or print them.

With BAM it is also possible for the user to reset the error logs
for BAM related objects. The following objects can be reset:

• One or several TGs


• One or several sites
• One or several BSCs
• Any combination of TGs, sites, and BSCs
• All BTS objects relating to a BTS logical model in a BSC

To reset the error log for objects relating to a certain BTS logical
model, the user must first collect all relevant objects by using
the generic BCM bucket facility.

DIFFERENT CONFIGURATION TYPES IN BAM


BAM handles different configuration types when administrating
the alarm data. Different types are used for different tasks such
as retrieving information, planning network changes, and saving
network backups. The different configuration types used by
BAM are:

Valid Configuration: Models the network at the time of the last


adjustment. The valid configuration area makes it possible to
retrieve information from the network without interfering with
it.

Planned Configuration: The user can create a planned


configuration to perform changes in the valid configuration
without interfering with the network itself. It is possible to
update the network with these changes.

Fallback Configuration: A fallback configuration is a complete


copy of the valid configuration at a given moment. This
configuration can be used as a backup and makes it possible to
make planned configurations from older versions of the valid
configuration.

EN/LZT 123 3330 R1B – 109 –


CME 20/CMS 40 BSC Operation & Maintenance

COMMON USER PROCEDURES


Installing the BAM application implies adding new BAM
related functionality to the BCM application. This means
introducing additional menu entries in the menu bar or new
interaction elements in the BCM base window (buttons, menus,
etc.) used for the handling and configuring BTS alarm reporting.

As BAM is used BCM application and all BAM related


functions are initiated from the BCM application, BAM is
started by selecting BCM from the OSS workspace menu or by
entering the application name on the command line. During
start-up of the application, a start-up screen is displayed. BAM
is active when the base window appears on the screen.

In the base window, a network model is displayed where


commands can be issued. All operations are easily accessible via
menus and buttons. To issue a command or to view object
information, the corresponding element must be selected first in
the hierarchical network browser, which manages and displays
the network in the user interface. Double-clicking SELECT has
a specific meaning in some cases and can be used as a short-cut
for executing commands.

AUTHORITY CATEGORIES
A BAM user is allowed to be a member of one or several
authority categories. The Authority Administration
administration manages the authority categories to which a user
belongs. Depending on the user authority, commands, fields, or
menu items are shown or not shown.

Note! The authority categories are independent from each


other, which means the System Administrator
category does not necessarily include the same
rights as the Operator, Assistant Operator, and
Application Administrator categories.

The following authority categories are supported by the BAM


application:

Assistant Operator Category: A user belonging to this


category is permitted to:

• Display the current alarm status


• Display the current fault information

– 110 – EN/LZT 123 3330 R1B


3 OSS Operation

Operator Category: A user belonging to this category is


permitted to:

• Change the BTS alarm configuration on network elements


• Change the alarm configuration schedule on network
elements
Application Administrator Category: A user belonging to this
category is permitted to:

• Start alarm update jobs


System Administrator Category: A user belonging to this
category is permitted to:

• Take care of the administration of user authorizations


• Take care of the administration of the database

EN/LZT 123 3330 R1B – 111 –


CME 20/CMS 40 BSC Operation & Maintenance

BTS SOFTWARE MANAGEMENT (BSW) OVERVIEW


The purpose of the BSW application is to enable the user to
manage and down-load BTS software (SW) in a centralized
manner. The SW is distributed as SW packages (SWP) from
the OSS via a BSC to Service Objects (SO) in the BTSs which
are known to that BSC. SWPs are copied from distribution
diskettes and read into OSS where they are stored in a UNIX file
system for later forwarding to the network.

During SWP loading, the SO receives and distributes the SW


internally to subordinate MOs in the BTS. A number of SOs are
subordinate to a TG. A TG is a logical object that distributes the
SWP to its SOs. The user can select to load the SWP directly to
a SO or to first load the TG for later forwarding of the SWP to
the SOs. The actual loading of the BTS is performed and
controlled by the BSC.

The BTSs are different types depending on which version of the


BTS logical model they belong to. BSW supports the BTS
logical models G01 and G12. This means that there are two
different types of SWPs (SWP G01 and SWP G12).

In RBS 200, logical model G01; the SO is represented by the


TRXC. The TRXC distributes the SWP to its subordinate MOs.
In RBS 2000, logical model G12; the SO is represented by the
CF. The CF distributes the SWP to all its subordinate MOs. This
means that all subordinate MOs in one TG in RBS 2000 always
contain the same SWP version. However, in RBS 200 the SWP
versions can vary between subordinate SOs in one TG because
an RBS 200 can contain up to 16 TRXCs.

In BSW, a model of the SWP information in the network is


stored in the BSW database. With the adjustment function, BSW
retrieves the information from the Network Elements (NE) and
stores it in the database. That is, BSW reflects the SWP
information at the time of the last adjustment. The database
contains, for example, information about which SWP that is
loaded into the different SOs. A process control program, Time
Control, handles the queues for adjustment and load jobs.

– 112 – EN/LZT 123 3330 R1B


3 OSS Operation

AUTHORITY CATEGORIES
The authority categories are managed by the Authority
Administration application. A user of BSW may be a member of
more than one authority category. To attain full authority for all
BSW functions, the user must be a member of the following
categories:

• SW Administrator
• Network Updates
• System Operator.
Note! If any menu items are dimmed when running the
BSW application it is because the user does not
belong to the authority category which has authority
to access the function.

The following four authority categories exist in the BSW


application:

Operator: A user belonging to this category has the authority


to:

• Retrieve information on SWPs stored in OSS


• Retrieve information on the SWPs already loaded in the
network
• Adjust data stored in the BSW application with data stored
in the network
• Terminate and delete his own adjustment jobs
• Check job status
SW Administrator: A user belonging to this category has the
same authority as an Operator. In addition to this, the user has
the authority to:

• Store, delete, and rename SWPs in the UNIX file system in


the OSS
Network Updates: A user belonging to this category has the
same authority as an Operator. In addition to this, the user has
the authority to:

• Load SWPs into BTSs


• Terminate and delete his own load jobs

EN/LZT 123 3330 R1B – 113 –


CME 20/CMS 40 BSC Operation & Maintenance

System Operator: This category must be used in combination


with one of the categories above. A user belonging to this
category has the authority to:

• Delete adjustment and load jobs of other users


• Terminate adjustment jobs of other users
If this category is combined with the Network Updates category,
a user has the authority to:

• Terminate load jobs of other users

– 114 – EN/LZT 123 3330 R1B

You might also like