Professional Documents
Culture Documents
Version
Date
Modified by
0.1
07.07.2004
Bartomiej Wojtas
Document creation
0.2
15.07.2004
Bartomiej Wojtas
Document updated
0.3
16.07.2004
Bartomiej Wojtas
0.4
16.07.2004
Bartomiej Wojtas
Document updated
0.5
19.07.2004
Bartomiej Wojtas
Minor updates
0.6
21.07.2004
Bartomiej Wojtas
Document corrections
0.7
26.07.2004
Bartomiej Wojtas
Major updates
0.8
26.07.2004
Bartomiej Wojtas
Minor updates
0.9
26.07.2004
Bartomiej Wojtas
Minor updates
1.0
28.07.2004
Bartomiej Wojtas
Minor updates
1.1
25.03.2005
Bartomiej Wojtas
1.2
26.06.2006
Micha Zajczkowski
Screenshots update
2.0
06.07.2006
Micha Zajczkowski
2.1
27.06.2007
Micha Zajczkowski
2.2
10.01.2008
Micha Zajczkowski
Document identification
Version
Revised on
Number of pages
Status
Author
Comment
[to be defined]
2.2
2008-05-28
23
Confidential
Comarch S.A.
Confidential
sales_support@comarch.pl.
Confidential
TABLE OF CONTENTS
1.
Introduction............................................................................................................ 5
2.
Functional features................................................................................................. 5
2.1.
Collection .......................................................................................................... 6
2.2.
Registration ...................................................................................................... 7
2.3.
Processing......................................................................................................... 7
2.3.1. Filtering ......................................................................................................... 8
2.3.2. Correlation .................................................................................................... 8
2.3.3. Manual handling...........................................................................................10
2.4.
Visualization.....................................................................................................11
2.4.1. Alarm List .....................................................................................................11
2.4.2. Geographical view........................................................................................12
2.4.3. Logical view..................................................................................................13
2.4.4. Floor Plan .....................................................................................................14
2.4.5. Hierarchical view..........................................................................................15
2.4.6. Panels Manager ............................................................................................16
2.5.
Notifications .....................................................................................................17
2.6.
Escalations .......................................................................................................18
2.7.
Reporting .........................................................................................................19
3.
Architecture ...........................................................................................................20
3.1.
Interoperability ................................................................................................21
3.2.
Technology.......................................................................................................21
4.
5.
Standards ..............................................................................................................22
Confidential
1. Introduction
The need for a robust solution to network fault management has become critical in
today's networked economy. According to recent researches, almost 80% of overall network
downtime is spent on problems locating, while only 20% is spent on actually fixing them. The
reason for this statistic is vast size and complexity of todays networks that has made manual
response methods to the fault problems obsolete and insufficient. Different structures and
management systems for each network domain make the situation even worse.
Therefore, on highly competitive telecommunication market, advanced fault management solution
is one of the key factors in companies success. It is essential to assure that your fault
management system has the following features:
fast and reliable identification of root-cause of network faults,
full automation of fault management tasks,
support for many different network domains,
unified alarm handling across different network elements,
easy integration with existing systems.
Based on cutting-edge technology, Comarch Fault Management is the solution to the
foregoing fault management issues inside telecommunication networks. This indispensable tool
monitors the elements of the network, and receives, displays and tracks alarms, all of which allow
users to manage potentially debilitating network problems efficiently and effectively. This flexible
and modern mechanism assists in detecting and solving issues that are at the root of network
faults.
The key benefits of the Comarch Fault Management are:
Network reliability improvement,
Centralized and unified control across all network domains,
Seamless integration with existing systems,
High scalability.
2. Functional features
Comarch Fault Management provides you with rich set of features that cover all issues
of fault management area in telecommunication networks. The alarm processing cycle is carefully
adjusted to handle alarm events efficiently and effectively. The key steps in the processing chain
are:
Collection,
Registration,
Processing,
Visualization,
Notifications,
Escalations,
Reporting.
All alarms are collected, processed and displayed in the real-time mode. Alarm
information is automatically updated as soon as new alarms arrive, thus providing you with
dynamically changing view of your network that exactly reflects its current actual state.
Confidential
Comarch Fault Management is equipped with the Comarch OSS console. Intuitive
interface and rich customization capabilities help you easily perform configuration, administration
and management tasks.
2.1. Collection
Comarch Fault Management solution allows you to collect alarm events from all network
elements regardless of complexity and diversity of your network environment. By means of
Comarch Mediation Platform it provides a consistent way of monitoring all your network devices
both directly and using your already existing management systems. Each managed entity is
connected to the system via specialized component, i.e. mediator which establishes transparent
communication channel between the network element and core engine of the Comarch Fault
Management platform.
We offer you wide selection of the off-the-shelf mediators for the following vendors
equipment:
Alcatel,
Ericsson,
Lucent,
Marconi,
Motorola,
NEC,
Nokia,
Siemens,
Cisco,
Huawei.
Each mediator is built upon generic mediator abstract encapsulating core functions,
common to all mediators. This approach promotes code reusability and reduces time-to-market of
the Comarch Fault Management deployment since only protocol/device specific behavior needs to
be implemented to integrate new vendor-specific elements into the system.
Supported interfaces include:
Q3/CMIP,
CORBA,
SNMP,
HTTP,
ASCII,
TL/1,
JDBC.
Alarms coming from network elements can be collected in two ways:
Synchronous,
Asynchronous.
Depending on the management protocol used, these methods may be used
simultaneously. Database or SNMP variable polling is an example of synchronous alarm gathering;
meanwhile trap and notification mechanism of SNMP operate in asynchronous mode. It means
that the system can either synchronize periodically with NEs or wait for NEs until they send
alarms by themselves.
The mediation process includes alarm events format translation that provides you with
unified and consistent alarm information for all managed entities. While different network
Copyright 2008 Comarch S.A.
Confidential
elements and management systems often deliver information in non-standard way and use
different attribute sets, the Comarch Fault Management displays alarm events in approved X.733
format. It doesnt, however, impose any information loss as original alarm data can be easily
obtained from alarm database where all information is stored. It also means that if original alarm
data lack information crucial from processing cycles point of view such as severity level,
mediators will automatically fill appropriate attribute fields based on defined mediation rules.
Each mediation device is equipped with a correlation engine to enable pre-processing of
incoming alarms already at the event collection phase. Correlation accompanied by pre-filtration
eliminate redundant data received from managed entities as well as detect and ignore false alarm
events, thus radically improve the overall systems performance.
2.2. Registration
All alarm events are registered in the alarm repository. It is divided into two subrepositories. First contains only active alarms, i.e. those immediately forwarded from mediation
devices for subsequent processing. Upon registering new alarms in the alarm repository the
console subsystem is notified and provided with all alarm attributes in order to make this
information available to the user. It means that all user views being open while registering new
alarms will be updated automatically.
Since alarms can be modified during their lifecycle, historical information needs to be
logged to enable future fault analysis and auditing. In the Comarch Fault Management each
modification to an alarm is saved in a separate repository as an historical alarm. Historical alarm
is stored in the database alongside the reference to the original alarm so that all alarm
modifications to a particular alarm are associated to one another. Changing alarm severity for
instance would generate new historical alarm containing original attribute values (i.e. previous
severity level) and store it into the historical repository. At the same time, new entry would be
created in the active alarm log with the name of the user having made the change and time of
the modification. Finally, when an alarm is cleared (operator usually terminates an alarm after the
problem has been solved) it is removed from the active repository and the alarm lifecycle is
finished.
The historical repository can be archived and cleared periodically. The typical time for
keeping historical alarm records is three months; however it may vary case by case depending on
specific requirements and network technology being monitored.
While active repository is used in real-time current alarms processing, historical
repository allows you to generate statistics and reports based on historical data, thus greatly
facilitating network events analysis and consequently tasks automation.
2.3. Processing
Once alarm data becomes available, it is necessary to identify root cause of the failure,
i.e. to pin-point the faulty element and indicate its location. However, considering vast size and
complexity of networks operating these days, reliable root cause identification will often require
you to get additional information from different sources and relate them together. Due to a large
number of managed devices and therefore alarm events, it may be impossible to correctly locate
a failure manually and your network down-time will increase causing substantial revenue
reduction.
Thats why our solution is aimed at alarm processing automation. All necessary
information are automatically collected thanks to mediation devices, while advanced filtration and
correlation functions immediately process the data to timely and reliably identify true root cause
of network failures. As a result, faults are located faster and more precisely.
Copyright 2008 Comarch S.A.
Confidential
2.3.1. Filtering
Filtering operations are involved in many steps of alarm processing chain. Filtration is
an important part of mediation and correlation processes, as well as of subsequent visualization
and reporting phases. It enables limiting amount of data such that specific tasks process only
those information they actually need, thus they are completed much faster reducing overall alarm
processing time.
Creating filters is fast, easy and flexible by means of Expression Editor tool. It wont
take you a second to define your own filter in graphical environment using logical blocks nor
confuse you with underlying SQL clauses. If you, however, do prefer more advanced approach,
you can create a filter specifying it directly using SQL-based query.
2.3.2. Correlation
The main goal of the correlation process is to automate typical operators management
tasks. Automation of tasks can be carried out as specific patterns emerge from network events
analysis. The Comarch Correlation Service can recognize these patterns, by relating together
pieces of different information obtained from events, alarms, filters and other sources and
automatically identify root cause of the network problem. Moreover, notification to your staff can
be sent automatically in case of specific pattern occurrence, thereby whole alarm handling chain
become fully automatic and so reduce your networks down-time.
Every alarm-related event coming to the system is checked against rules defined in
FireFly Correlation Engine. The rules reflecting known event patterns are stored in Knowledge
Bases, and describe specific conditions under which specific actions should be performed. These
conditions can even describe very sophisticated failure scenarios as you can analyze events order,
their time-dependencies and use desired filters.
Confidential
Figure 2 Correlation
Thanks to a special built-in rule editor, you can easily create new rules defining
Knowledge Bases by compiling scenarios of embedded components (e.g. chronicles, rules, events,
etc.). Rules are defined using user-friendly FireFly scripting language similar to Java.
Comarch Fault Management solution provides you with set of standard functions to be
used during scenarios definition for both retrieving additional data during correlation execution
and automating your response action:
Notifications (SMS, email, etc.),
Events generation,
Counters,
Database connections/queries (JDBC),
FTP/Telnet operations,
Remote command execution,
Others.
Confidential
Confidential
10
External tools can be used to deal with a faulty element directly. For example you could
open a telnet session to reconfigure faulty IP router. If another management system sits between
NE and the Comarch Fault Management, you can launch it in the same way and perform
appropriate action with it.
2.4. Visualization
Comarch Fault Managements Console utilizes powerful visualization engine to display
alarms in several different manners, with dynamic views that provide you with consistent way of
displaying elements from all managed networks. Each view can be fully adjusted to meet your
individual requirements. You can quickly switch between different views choosing the most
suitable one for your current needs.
Confidential
11
Table columns are fully configurable regarding their width and order. Each row in the
table is colored according to the alarm severity level. At the bottom of the window there are
statistics of total alarms number in the context of alarm severity and acknowledge status. Both
table and chart form is provided.
You can launch multiple windows and configure them by applying filters, and thereby
divide alarm events into desired groups (e.g. geographically). Each window can be saved for
future use with the same filter setup. Additionally, information on alarms within the current view
can be easily exported to CSV, PNG, XML, XLS or JPG files.
Similar functionality is provided in historical alarms context.
Confidential
12
user. Once a network element within specific location raises an alarm, the icon changes its color
to indicate severity level and optionally it can start blinking. There may be many faulty elements
within the same location and then severity of the most critical alarm is displayed. Short
description is also provided that gives number of the most critical alarms together with their
severity code and indicates if there are any alarms with lower severity level. For example 4M+
would mean four major alarms accompanied by other, less critical. This assures you have
complete and most current view of situation in your network locations and helps you better
prioritize your tasks.
Detailed information on alarms within selected location can be immediately displayed by
opening the Alarm Manager from context menu. Appropriate filter is applied automatically
allowing fast context-based navigation between views and reducing alarm processing time.
Confidential
13
Confidential
14
Confidential
15
It is possible to display the same information in a directory topology which offers more
compact view of network elements. As the directory uses smaller icons than the former tree
structure, only the severity level encoded as icon color can be obtained directly.
Regardless of selected topology, there is a list of all attributes in the right panel of the
window that can be used to get alarm details, as well as context menu available on each element
to switch to the Alarm Manager and start alarm handling immediately.
Confidential
16
2.5. Notifications
Comarch Fault Management allows you quickly send notifications to your personnel that
are responsible for removing the failure. You may use the following methods:
e-mail,
fax,
SMS (Short Message Service),
pager message,
unified messaging based on internal messaging system.
Confidential
17
2.6. Escalations
Escalation Service enables you to define rules for escalating events which were not
handled properly e.g. delayed, thus preventing failures from increasing their impact on your
business processes. There are three main types of escalations available:
Delay a notification is sent if there is no action performed after a predefined time,
Kind sending a notification depends on the type of event,
Quantity - a notification is sent if a specific amount of predefined events occurs.
Confidential
18
Escalations are configured easily via dedicated GUI. Escalation Service supports the
same communication channels as notifications do.
The alarm can be routed to be seen by the user who is responsible for handling a given
type of problem with appropriate user account privilege settings, assigned by an administrator.
For example, for unacknowledged alarms, delay based escalation would have sent a
notification:
to operator after 10 minutes,
to manager after 30 minutes,
and to supervisor after 60 minutes.
2.7. Reporting
Comarch Fault Management provides advanced reporting tool that facilitates performing
advanced network analysis, and consequently taking appropriate measures in order to improve
your networks performance and reliability. It enables you to generate valuable statistics and
reports such as:
total number of specific alarms for last month (grouped by days),
the most frequently alarm-raising devices,
total number of alarms for last week,
total number of alarms grouped by severity.
The system provides ready-to-use templates that allow easy and fast report generation.
Your role is only confined to entering some simple parameter values, e.g. time range, alarm type,
etc. The rest of report generation process is fully automatic. You can also design your own
templates by means of report wizard tool, in few simple steps.
You can create statistics upon you request or schedule periodical reports generation
and automate reporting tasks with Task Scheduler tool.
Confidential
19
It is possible to export alarm data to CSV or JPG format as well as create advanced
printouts based on already defined statistics. You can compose it from text fields, bitmaps and
statistics to design your customized, sophisticated printouts.
Alarm-related information can be presented in both tabular format and as graphic
charts. You can fully control the way the information are displayed, e.g. type of chart, axis
descriptions, colors, etc.
3. Architecture
Comarch Fault Management solution is based on the Comarch OSS Suite which consists
of:
Comarch
Comarch
Comarch
Comarch
OSS Framework;
Framework Services;
Mediation Platform;
Functional Modules.
Alarm Repository main database storing all alarm related data for use by other
components,
Correlation service carries out filtration and intelligent correlation of events detected in
the network, e.g. alarm events,
Confidential
20
Comarch OSS Console provides unified GUI interface: alarm list, geographical view
(GIS), logical view, etc.
System Repository and Configuration supervises and controls all the components and
subsystems. It is responsible for storing configuration of all subsystems and for verifying
integrity of the system,
Authentication Service authenticates users and provides users and privileges
management,
Notification and Escalation Service handles notifications and escalations,
Reporting Service generates statistics and reports.
3.1. Interoperability
The Comarch Fault Management is an exceptional system in terms of openness. You can
greatly benefit from integrating other components of Comarch OSS Suite into your solution:
3.2. Technology
The modern technologies used to develop the Comarch Fault Management guarantee
the full integration of telecommunication and IT systems and the efficient flow of information
among various platforms and systems.
Our solution is based on:
J2EE, OSS/J;
Plug-and-Play architecture;
Suns Java Messaging Service;
Communication bus based on XML/SOAP.
The Comarch Fault Management will grow as your company does. Its scalable
architecture provides a wide range of possibilities for increasing the systems efficiency and
capabilities. No matter how rapidly your network develops, our solution will develop with it,
providing everyday operations with careful, customized support.
The scalability of our solution is a result of:
Confidential
21
4. Key benefits
The key benefits of the Comarch Fault Management are:
Network reliability improvement
The Comarch Fault Management is aimed at automation of fault management tasks to
speed up resolving network problems and reduce your networks down-time. With its
advanced alarm processing procedures, including filtering and correlation it allows you to
rapidly and accurately locate network problems and consequently reduce the time when
your network doesnt earn for you. You can now reach your OPEX (Operational Expenses
Reduction) objectives and dramatically increase your business profits as you can limit
well-trained and expensive personnel engagement and reduce mean-time-to-recovery
simultaneously.
Centralized and unified control across all network domains
The Comarch Fault Management solution uses powerful Comarch Mediation Platform to
enable unified fault management across different network domains and provides
centralized control over them. It allows you to improve your Network Operations Centers
efficiency and increase your revenues.
Seamless integration with existing systems
Thanks to open and flexible architecture, the Comarch Fault Management can be easily
implemented in your already existing environment. As our solution is based on industry
standards (J2EE, CORBA, XML, OSS/J) you can easily and quickly deploy it regardless of
your network infrastructures and management systems diversities.
High scalability
Based on distributed programming environment (RMI, JMS) the Comarch Fault
Management solution can be easily expanded to follow your network development.
5. Standards
Comarch S.A. actively participates in standardization process. As a member of
TeleManagement Forum, we are aware of importance of standardization in telecommunication
evolution. Therefore, the Comarch Fault Management solution conforms to the following
recommendations:
TMF (eTOM, NGOSS) internal architecture, operator business processes recognition
and information flow,
Confidential
22
ITU-T (M.3xxx, X.xxx series) internal systems architecture and interfaces to telecom
networks (e.g. CMIP),
IETF interfaces to IT networks (e.g. SNMP and MIB structures),
OMG CORBA interface,
OSS/J internal architecture implementation,
others (ATM Forum, ETSI, Vendor specific standards).
Confidential
23