Four types of alarms:

notices (0-999)

disturbances (1000-1999)

alarms (2000-2999)

error ratio counters

Recovery system
-recovery of units and the whole network element
-operating states
Recovery of the whole element
-only in total power lost or in commissioning
- first OMU then 2N units come up (more on the file administration)

REDUNDANCY
2N: SAME CODE AND FILE
N+1: SAME CODE, DIFF. FILE->WARM-UP
SE-OU-> Unit is faulty
SE-NH-> When user is changing a PIU

BLCODE:

The Boot Loadable Code subdirectory contains the program

code files and parameter files that are loaded first into the
computer unit's memory when the computer unit starts up

MMDIRE:

The MMI system subdirectory contains MML programs and

their text files

LFILES:

The Loadable Files subdirectory contains disk copies of

memory files, e.g. net elements database

ASWDIR:

The Application Specific Work subdirectory is for saving

applications' work files on disk, e.g. for routine measurings.

CONVPR:

The Conversion Program subdirectory contains the file

conversion programs that are needed to perform software
updates

WEBFIL:

The files of the WEBFIL subdirectory and its six additional

subdirectories are needed for the Web Based management of
the network element and graphical user interface GUI

There are two essential software configuration management files that are controlled
by the software configuration management:
Software configuration management file (SOMAFI) contains management
information of all builds created in the system. SOMAFI is common for all builds.
Software build master list (MAFILE) is a description list of the build's load modules
and files and their versions. Each build has its own MAFILE.
The Software configuration Management File (SOMAFI) contains information on
software builds created in the exchange.
The SOMAFI is found in the SCMANA directory.
SOMAFI includes eight records of the same size. Each record can contain the
administration data of one created software build.
A build is always accompanied by a Master File (MAFILE), which contains a list of
all load modules of the build together with their version data.
The MAFILE is found in the BLCODE directory.
By using the MAFILE, the user can create a software build. Created software builds
can eventually be loaded into the functional units of the exchange.

Software builds stored into the management system are identified and thus
distinguished from one another by means of the following build specific data:

Application identifier of the build and the version of the build Application identifier
of the environment specification and the version of the environment specification

Name of the delivery and the version of the delivery.

In addition to the above, the SW-build can be identified in the network element by a
name given to it in the creation.

A software build located on disk and created with management commands has a
status.
The possible statuses are:
Back-up (BU)
A build on disk that should usually be defined as active and in use, which is therefore
normally loaded during initial loading when the exchange is restarted. The Back-up
package cannot be removed with package management commands.
Fall-back (FB)
A package on disk, which is usually older than the Back-up package, and which
usually functions as the on-line safe copy of the Back-up package. The exchange
can be loaded with the Fallback package with MML commands.
New (NW)
A package on disk that has been introduced into the exchange for testing and
possible subsequent deployment.
Untitled (UT)
It is also possible for the status to be untitled. The system allows more than one
package to have this status.
Undefined (UD)
The status of an uncreated build is UD. This status is visible only in the printout
commands. The UD status cannot be used for referring to a build, because builds
with this status are not mentioned in the software configuration management file in
any way.

The main procedures for handling SW build statuses are:

Safecopy

Roll-back

Status change

Safecopy
A safecopy is a copy of a software package that is kept for reference in case the original
file or data set is destroyed. During the safecopy procedure, the complete software of the
package that currently has the status BU is physically copied. This implies that also a new
package directory tree is created on the disk. The package created during a safecopy
gets the status FB.
Note that the copying process always gets the files of the package with the status BU.
This is not necessarily the current default package.
Command to perform a safecopy: ZWKS:....

Rollback
The rollback procedure supports the user to obey the recommendations for software
packages. In case of a fault in a BU package, the FB package should be taken into use. It
becomes a default package and permanently running in the system. However, a
recommended running package should be BU. So, status changes have to be performed.
With the rollback command:
Status of the FB package is changed to BU Status of the package that functioned as BU
is changed to NW. If there is a package with the NW status, it is changed to UT status.
During a rollback no software is copied, only statuses are changed.
Command to perform a rollback: ZWSR:

Status change
The user can change the status of software packages with 2 possibilities:

Swap the statuses BU and NW

Name one of the UT packages to attach the status NW to it.

Command to perform a status change: ZWSC:

MME measurements (TP - Measurement Configuration Handling product

document)

- Mobility Management Measurement

The Mobility Management Measurement provides information on, for example,
successful and failed EPS attaches and detaches, tracking are updates, service
requests, handovers and paging procedures. The mobility management functions are
used to keep track of the current location of a User Equipment (UE) within the Public
Land Mobile Network (PLMN) or within another PLMN. The counters are collected on
Tracking Area level.
M50C004 / EPS PERIODIC TAU FAIL
M50C006 / EPS TAU FAIL
M50C010 / EPS PATH SWITCH X2 FAIL

- Session Management Measurement

The Session Management Measurement provides information on, for example,
successful and failed default bearer activation procedures. The counters are
collected on Tracking Area level.

- MMDU User Level Measurement

The MULM (MMDU User Level Measurement) provides information on users in ECM
connected, ECM idle, EMM registered and EMM deregistered states on MMDU level.
Minimum, maximum and average number of users in each state is reported per
MMDU. The reported average value is a result of two counters, denominator and
sum. The counters are collected on MMDU level.

- User MME Level Measurement

The User MME Level Measurement provides information on users in ECM
connected, ECM idle, EMM registered and EMM deregistered states on MME level.
Maximum and minimum number or users in each state is reported. The counters are
collected on MME level.
- SGsAP measurement
- Security measurement