Network Element Description

Ericsson Multi Mediation 7 - File and event mediation

DESCRIPTION

71/1551-FAM 901 434 Uen N

Copyright

Copyright Ericsson AB 2011-2013. All rights reserved. No part of this document

may be reproduced in any form without the written permission of the copyright
owner.

Disclaimer

The contents of this document are subject to revision without notice due to
continued progress in methodology, design and manufacturing. Ericsson shall
have no liability for any error or damage of any kind resulting from the use
of this document.

Trademark List

Ericsson is a trademark or registered trademark of Telefonaktiebolaget LM

Ericsson. All other product or service names mentioned in this document are
trademarks of their respective companies.

71/1551-FAM 901 434 Uen N | 2013-04-17

 Contents

Contents

1 Introduction 1
1.1 Purpose and Scope 1

2 Product Overview 2
2.1 General 2
2.2 File and event mediation 2
2.3 Interface 3
2.4 Support for Ericsson Products 5
2.5 Support for Multi-Vendor 8

3 Functions 10
3.1 Collection 10
3.2 Distributed Event Collector 11
3.3 Processing 14
3.4 Distribution 20
3.5 Revenue Assurance 22
3.6 Advanced CDR Repair System 23
3.7 Security 25
3.8 File and event mediation Logs 27
3.9 Alarm Handling 29
3.10 Auto Load Balance 30
3.11 BSCS 31
3.12 Charging SDK 33
3.13 Performance Monitor 33
3.14 CDR logging 33
3.15 CDR and File statistics 33
3.16 Configurations for Mediation of Network Data 33
3.17 Configuration Pack 35

4 Operation and Maintenance 36

4.1 Graphical User Interface 36
4.2 Command Line Interface 36

5 Characteristics 37
5.1 Performance 37

71/1551-FAM 901 434 Uen N | 2013-04-17

Network Element Description

5.2 Availability 37
5.3 Reliability 38
5.4 Recovery 38
5.5 Secured Password 39

Glossary 40

Reference List 41

71/1551-FAM 901 434 Uen N | 2013-04-17

 Introduction

1 Introduction

This chapter provides an over view of File and event mediation by including its
the purpose and scope.

IMPORTANT
Some of the features described in this document might not be available
depending upon the procured licenses. For more information, refer Ericsson
Multi Mediation 7 - Network Impact Report, Reference [6].

1.1 Purpose and Scope

The purpose of this document is to provide a general overview of File and event
mediation. The following chapters are included:

• Product Overview, see Section 2 on page 2

• File and event mediation functions, see Section 3 on page 10

• Operation and maintenance overview, see Section 4 on page 36

• Characteristics, see Section 5 on page 37

71/1551-FAM 901 434 Uen N | 2013-04-17 1

 Network Element Description

2 Product Overview

2.1 General
File and event mediation provides a flexible and powerful mediation solution.
The overall aim of the product is to support quick and smooth introduction
of services into the communication network by providing a single point and
flexible interface for charging related information. File and event mediation also
provides flexible tools for all charging data management and data manipulation.

For the interfaces such as Diameter, Radius, SNMP, and NetFlow, File and
event mediation uses the event collector. Event collector is a part of Online
mediation, but File and event mediation is capable of using event collector for
these interfaces.

File and event mediation consists of the various parts as shown in Figure 1

Business Management System

Detail Record Generating

Multi Vendor Network File and event mediation Fraud and Billing Systems
Elements

Prepaid and Charging

Service Applications Event collector
Systems

Network ManagementSystem

Figure 1 File and event mediation Overview

2.1.1 Supported Hardware Configurations

File and event mediation runs on the following hardware:

• Sun SPARC and x86 processors

2.2 File and event mediation

File and event mediation provides a central point for collection and processing
of events and detail records, as well as for distribution of charging information,
see.Figure 2

2 71/1551-FAM 901 434 Uen N | 2013-04-17

 Product Overview

File and event mediation

Collection Processing Distribution

Event
collector

Figure 2 File and event mediation Overview

The event collector is a stand alone module which can be configured on

external hardware, typically closer to the serving elements and gather event
data from those elements. The event data is forwarded to File and event
mediation for further processing.

2.3 Interface
This section describes the interface.

2.3.1 Protocols for Collection

The protocols supported offer a generic support for any collector using the
supported protocols and decoders with small modifications. In these cases,
only a new ASN.1 data structure is to be added. This can be configured and
customized in a flexible way by the user. New collectors can also be offered
from Ericsson as customizations with short lead times if requested.

The generic protocols described offer support for a number of pre-verified

collectors:

• File based collection

• Event based collection

For more information, see Section 2.3.3 on page 4.

2.3.2 Protocols for Distribution

The following types of distribution are supported:

• File based distribution

• Event based distribution

For more information, see Section 2.3.3 on page 4.

71/1551-FAM 901 434 Uen N | 2013-04-17 3

 Network Element Description

2.3.3 Interface and Protocol Overview

The File and event mediation supports the following interfaces for the following
functions, see Table 1.

Table 1 Interfaces used for File and event mediation

Type of Mediation Interface function Protocol
File and event File based collection, FTP
seeSection 3.1 on page
TFTP
10
SFTP
FTAM
Disk
MTP/SFI
MTP/SFO
Block based collection, see BGw-RPC
Section 3.1 on page 10

Block-, event-, and Radius (Supported

entry-based collection, using DEC)
see Section 3.1 on page 10
GTP' (Version 0, 1
and 2)
MIB-II over SNMP
(Supported using
DEC)
File based distribution, see MTP/SFO
Section 3.4 on page 20
MTP/SFI
Disk
FTP
SFTP
FTAM
Stream based collection TCP
Block based distribution, see BGw-RPC
Section 3.4 on page 20
CCI-RPC-1
CCI-RPC-2
Database collection and Oracle®
distribution

4 71/1551-FAM 901 434 Uen N | 2013-04-17

 Product Overview

Type of Mediation Interface function Protocol

Alarm Handling Sending alarms to network Alarm IRP
management systems, see
SNMP
Section 3.9 on page 29
TXF

Note: MTP/SFI, MTP/SFO, FTAM, and Radius are not supported for Linux
on x86 platform.

For more information regarding the interfaces used, refer to Ericsson Multi
Mediation 7 - File and event mediation, Interface Description, Reference [1].

2.4 Support for Ericsson Products

In the following sections some of the pre-verified nodes and collectors are
briefly described. For more details about any node or collector, please contact
the local Ericsson office.

File and event mediation supports pre-verified collectors, for example:

• Core Network (Circuit Switched, Packet Switched, IP Multi Media)

• Service Network (Applications and Enablers)

• Wireline

• Engine

• IP/Datacom

• WLAN

For more information regarding collection, see Section 3.1 on page 10.

The following list is a sample of supported Ericsson products. For a complete

list contact your local Ericsson office.

71/1551-FAM 901 434 Uen N | 2013-04-17 5

 Network Element Description

Table 2 Sample of Supported Ericsson Products

Product Protocol Additional
Information
Ericsson CN 5.0 Ericsson GSM CCI-FTP The MSC supports
Mobile R10 (GSM 900, 1800, and , CCI-SF GSM, TDMA, and
Switching 1900), R11, R12, R13.0, TP, CCI- CDMA networks. As
Center R13.1, R13.2, R14 ITU-T RPC well as switching traffic
(MSC) and R14 ANSI.R14.1, between different cells
2012A, 2012B, 2013A, in a network, the MSC
(1)
and R14.1 ANSI provides the gateway
from the wireless
MSC 3000 in CDMA 18 environment to PSTN,
ISDN and Internet
networks at the local,
transit or international
gateway level.
Ericsson CDMA R6 -
(CDMAx1 and CDMA
(1)
2000).
Ericsson Ericsson MSC/IOG MTP-SF -
IOG O over
X.25
MTP-SFI -
over
X.25
FTAM When the File and
over event mediation acts
TCP/IP as initiator for FTAM,
the Ericsson IOG is not
supported.
FTAM -
over
X.25
Ericsson Ericsson MSC/APG 40 CCI-FTP -
APG 40 -
CCI-SFT
P
CCI-RP -
C

6 71/1551-FAM 901 434 Uen N | 2013-04-17

 Product Overview

Product Protocol Additional

Information
Ericsson Ericsson SGSN R5, R5.5, FTP -
GPRS R6, R7, R8. 2009A, -
GTP'
Support 2009B, 2010A, 2010 A
Node (GSN FP, 2010B, 2010B FP,
) 2011A, 2011B, 2012A,
and 2013A.
Ericsson GGSN R97, R98, FTP -
R99, R4, R5, R5 FP01, -
GTP'
2009A, 2009B, 2010A,
2010B, and 2011A
EPG 2012A -
-
CPG 2012A, 2013A -
-
Other Ericsson S-CSCF - Diameter Event collector
Ericsson Serving Call Session
SFTP Event collector
nodes Control Function 4.0, 4.1
Radius Only used for Ericsson
MultiMedia
Ericsson MGCF - Media Diameter Event collector
Gateway Control Function
SFTP Event collector
4.1, 5.1, and 5.1 FD1
Radius Event collector
Ericsson MRFC - Media Diameter Event collector
Resource Function
Radius Event collector
Controller 4.0, 4.2
Ericsson USIS - User FTP -
Session and Identity
Server 2.0, 2.1
Ericsson MMS-C - Radius Event collector
MultiMedia System Centre
FTP
Charging System 4.0, Diameter Event collector
Charging System 5.0.3,
Charging System 5.1.1,
Charging System 5.1.2,
Charging System 5.1
Charging Compound
1.3.0, and Charging
System 5.2
VPN 3.1 FD1
VIG 3.0 FD1 and FD2

71/1551-FAM 901 434 Uen N | 2013-04-17 7

 Network Element Description

Product Protocol Additional

Information
SIG 4.0 support
MPS 9.0 and 10.0 support
MoIP 6.0 FD1 and FD2
support
MMC 5.0 FD1, FD2, FD3,
and FD4 support
MIEP 4.0 FD1 and FD2 Event collector
support
SBG 3.0 FD1, 3.1
MTAS 2.0 support
MTAS 2011A, 2011B,
2012A, and 2013A
CSCF 4.1 FD1 support
SASN R5 FP01 and FP02,
R6 and FP01 support,
2009B, 2011A, 2011B,
2012A, and 2013A
BSCS iX R2 and BSCS iX
R3
(1) This MSC is using the APG 40 in Core Network (CN) 5.0 as charging output module.

Note: MTP/SFI, MTP/SFO, FTAM, X.25, and Radius are not supported for
Linux on x86 platform.

For more information regarding the interfaces used, refer Ericsson

Multi Mediation 7 - File and event mediation, Interface Description,
Reference [1].

2.5 Support for Multi-Vendor

File and event mediation supports pre-verified interfaces towards the following
vendors and products, see Table 3:

8 71/1551-FAM 901 434 Uen N | 2013-04-17

 Product Overview

Table 3 File and event mediation Multi Vendor Support

Third Party Vendor Third Party Product Protocol
Nokia Nokia MSC FTP
(DX200 M10/DX200
FTAM
M11/DX200 M12)
Nokia WAP FTP
Nokia Messaging
Nokia MMS-C (MC1
CD1 and MC2)
Nokia SMS-C
Siemens Siemens EWSD FTAM
Lucent Lucent 5ESS FTAM
FTP
Nortel Nortel DMS AFT
XFER
Nortel MSC AFT
XFER
Alcatel Alcatel S12 FTAM
Alcatel MSC
LogicaCMG LogicaCMG MMS-C FTP
LogicaCMG SMS-C
SEMA SEMA SMS 2000 FTP
Comverse Comverse SMS-C FTP
Huawei HWCZ08 128M FTAM

For more information regarding the interfaces used, refer Ericsson Multi
Mediation 7 - File and event mediation, Interface DescriptionReference [1].

71/1551-FAM 901 434 Uen N | 2013-04-17 9

 Network Element Description

3 Functions

3.1 Collection

3.1.1 General

The File and event mediation can collect detail records from different types of
network elements, for example, switches, voice-mail systems, datacom nodes,
IP routers, and intelligent peripherals. It can collect detail records using multi
vendor proprietary protocols and collectors, Ericsson proprietary protocols,
and standard protocols.

The communication can be initiated in either of the following ways:

• From the network elements

The File and event mediation acts as a responder.

• From the mediation system

The File and event mediation acts as an initiator.

There are collectors supporting multi vendor, as well as Ericsson proprietary

interfaces. These collectors consists of:

• Protocol

Used for transferring the charging data. For more information, refer
Ericsson Multi Mediation 7 - File and event mediation, Interface Description,
Reference [1].

• Data structures

Logical data description specified with Abstract Syntax Notation One

(ASN.1). For information on ASN.1, refer Specification of Abstract Syntax
Notation One (ASN.1) ITU-T Recommendation X.680Reference [7].

• Decoder

Describes how the parameters and tags in the data structures are coded.
For more information on the decoding, see Section 3.3.2 on page 14.

3.1.2 Intermediate Collector

The CDRs collected by Intermediate Collector will not be counted multiple times
for CDR throughput limit if Intermediate property is set True for collector. The
following collectors can act as Intermediate Collectors:

10 71/1551-FAM 901 434 Uen N | 2013-04-17

 Functions

• Disk

• Optimized Disk

• FTP

• SFTP

• MultiNE

Note: For collectors that collect data from NE, set the property to False.

3.2 Distributed Event Collector

The DEC collects event or charging information as soon as it is distributed from
the network element. It performs basic processing (filtering and routing) on the
collected information and stores the information in files as CDRs. These CDRs
are then distributed to File and event mediation module for further processing.

Figure 3 Distributor Event Collector Deployment Architecture

3.2.1 CDR Distribution to FE

The files containing the CRDs can be stored on disk or distributed to File and
event over FTP/SFTP. The number of entries in each file is configurable for
number of events, time intervals, or for a specific time.

3.2.2 Scalability

DEC makes it possible to scale up the collection of Charging Event across

multiple hardware nodes. It enhances the application availability, since multiple
DECs can run parallelly. It is deployed close to the network elements that
reduces network load.

71/1551-FAM 901 434 Uen N | 2013-04-17 11

 Network Element Description

If a DEC fails, the network node can send the events to any other DEC. Some
constraints to this option are as follows:

• The Distributed event collector is not available as a clustered solution. It

can be offered as a system integration solution.

• The failover to another DEC is Client initiated.

3.2.3 Features
The features of DEC are described in the following sections.

3.2.3.1 Value Routers

The Value Router filters, splits, routes, or discards the transactions before
distributing them to receiving system. The filtering rules can be based on
combination of parameters. The routing conditions can be configured in GUI by
configuration administrator. The routing rules are written in JAVA.

3.2.3.2 Formatter

The Formatter formats the transaction. It uses JAVA based parameter mapping
functions. Syntax highlighting and compilation validation improves error
detection capabilities.

3.2.3.3 File Distribution Capabilities

The file distributor activity transfers files as per following standards:

• Token separated ASCII

0 It is possible to specify content of CDR.

0 The field delimiter per CRD type is configurable.

• ASN.1 BER encoded files

0 Encoding type can be specified as BER.

0 It is possible to specify the ASN.1 files.

3.2.3.4 Throughput Meter

The Throughput Meter logs time spent in each activity per second. It is
displayed in a separate GUI window and can be switched off/on in runtime.

It measures latency on different levels of the configuration. The levels can be:

• Time spent in external interfaces.

• Time spent in execution.

12 71/1551-FAM 901 434 Uen N | 2013-04-17

 Functions

• Time spent in activity queues.

3.2.3.5 Security

The DEC supports following security options.

SSH Support

SSH provides secure encrypted traffic in both directions. The port forwarding
function provides a safe tunnel for any TCP session.

IPSec Support

The IPsec standard provides a secure tunnel (Virtual Private Network) for
transmitting data through an unsecured network such as the Internet. IPSec is
used to provide security between two different networks but can also be used
between two nodes. IPSec protects data transferred over the network but does
not handle user authentication. The protocol is configured on both nodes to
encrypt all traffic on IP level.

3.2.3.6 Diameter F-E

The Diameter F-E activity enables the clients to communicate with DEC using
application protocols based on:

• Diameter Base (RFC 3588)

• Diameter Credit Control Application (RFC4006)

A single configuration can manage connections to several Diameter peers. It is

also possible to redirect or relay requests to another host.

Applications that are supported by the business logic are defined in the activity
profile as Locally Supported Application.

An incoming request is routed to its final destination based on AVPs

Destination-Realm and Application-Id. If it is locally supported by the activity,
then the route defines the Protocol Specification that decodes the message and
translates it into a MapEvent understood by the business logic.

The application protocol is decoded and encoded as described by a protocol

definition, expressed in eXtensible Markup Language (XML). The protocol
definition consists of a list of the AVPs in the protocol, and for each request and
response definitions of the AVPs as part of a particular Diameter Message.

71/1551-FAM 901 434 Uen N | 2013-04-17 13

 Network Element Description

3.3 Processing

3.3.1 General
The File and event mediation supports a number of adaptable processing
functions:

• Decoding, see Section 3.3.2 on page 14

• Encoding, see Section 3.3.3 on page 15

• Data unit processing language, see Section 3.3.4 on page 16

• Formatting, see Section 3.3.5 on page 16

• Value-Router, see Section 3.3.6 on page 17

• Compression/Decompression, see Section 3.3.7 on page 17

• Consolidation, see Section 3.3.8 on page 18

• Database and lookup, see Section 3.3.9 on page 18

Most of the aspects of the processing functions mentioned above can be

configured in runtime, and require no software upgrade or re-compilation of the
system. Several processing functions can be combined, in order to define
the business logic.

Note: It is possible to set different prioritization for flows in the configuration.

3.3.2 Decoding
The decoding mechanism is a basic entity within the File and event mediation.
Decoding is used to unfold the incoming detail records thereby enabling
identification of individual data fields within the detail records. The detail
records received must be decoded before they can be processed.

The following formats can be decoded:

• BER-encoded detail records

For more information on Basic Encoding Rules (BER), refer Specification

of Basic Encoding Rules (BER) for Abstract Syntax Notation One (ASN.1)
ITU-T Recommendation X.690, Reference [8].

• Fixed-size ISO-encoded detail records

• Fixed-size Packed-encoded detail records

• Token separated ASCII-encoded detail records

The separator token can be configured.

14 71/1551-FAM 901 434 Uen N | 2013-04-17

 Functions

• Mixed - detail records and Event Modules encoded in different formats

The formats of the detail records and the Event Modules can be configured.

• XML encoded detail records

In addition to the detail record formats above, the File and event mediation
can handle the following file formats:

• Blocked

Blocked files, where a file consists of several fixed size blocks. Each block
contains a number of detail records. The block-size can be configured.

• Non blocked files

Files containing any number of detail records of any kind of size.

• Header-Trailer

Files consisting of fixed size headers and trailers. Headers and trailers are
supported on file-, block-, and detail record-level.

Note: Decoding of records encoded in Ericsson Bit Packed Format is

supported but the decoder is not delivered in the standard package. It
is delivered as part of the different multi vendor collectors.

3.3.3 Encoding
The encoding mechanism is a basic entity within the File and event mediation.
Encoding is used to assemble individual data fields into a complete detail
record understood by the receiving business system. All data decoded, or
produced, by a configuration must be encoded before it can be sent to a
business system. The output format can be different from the input format. The
following encoding formats are supported:

• BER

For more information on Basic Encoding Rules (BER), refer Specification

of Basic Encoding Rules (BER) for Abstract Syntax Notation One (ASN.1)
ITU-T Recommendation X.690, Reference [8].

• Fixed-size ISO

• Fixed-size Packed

• Structured-ASCII detail records including field names as plain text (ASCII)

Generates output readable for the human eye that can be used to
investigate the content of detail records.

• ASCII

71/1551-FAM 901 434 Uen N | 2013-04-17 15

 Network Element Description

Both fixed-size and token separated encoding are supported.

• Mixed - detail records and Event Modules in different formats

The formats of the detail records and the Event Modules can be configured.

• XML

The following file formats are supported for distribution of detail records:

• Blocked

Blocked files, where a file consists of several fixed size blocks. Each block
contains a number of detail records. The block-size can be configured.

• Non blocked files

Files containing any number of detail records of any kind of size.

• Header-Trailer

Files consisting of fixed size headers and trailers. Headers and trailers are
supported on file-, block-, and detail record-level.

3.3.4 Processing Languages

The File and event mediation supports the following processing languages:

• Data Unit Processing (DUP)

DUP offers the users an integrated developers kit for customizing the
business logic. DUP has special functions, which are optimized for
processing of tele- and data communication charging data. DUP also
allows easy charging data handling and customization down to bit level.
DUP is based on C++ and can easily be understood by a programmer
with basic programming skills.

• Tool Command Language (Tcl)

Provides Tcl specific commands and features and offers the possibility
to execute business logic written in Tcl. Tcl also offers the possibility to
execute specific Tcl scripts at specific processing events.

• Java

It is possible to customize business logic using Java.

3.3.5 Formatting
The formatter activities can be configured with business logic in order to:

16 71/1551-FAM 901 434 Uen N | 2013-04-17

 Functions

• Examine individual fields in detail records

• Translate detail records from one format to another

• Modify individual fields in detail records

• Enrich detail records with new data

• Remove unwanted data and fields

Formatting can be used successfully for the introduction of new services.

A set of standard charging data structures are delivered with the product, for
example different revisions of CME20, CMS40, and GSN. In addition to this,
formatters can be used to transform the incoming detail records into formats
and structures that can be handled by the business systems.

A set of standard formatters is delivered with the product, for example, different
revisions of CME20 R12 to CME20 R11 or SGSN R6 to SGSN R5. Other
formatters can be offered as professional services to the customers.

3.3.6 Value-Router
The Value-Router (dispatching) function is used in order to control the data
flow through a configuration.

The Value-Router can for example be used to route detail records based on
their content or type to:

• Separate detail records originating from roaming-calls, and detail records

originating from non-roaming-calls

• Discard information to reduce load in business systems

The Value-Router compares the value of a field within the detail record with
some predefined value, or a value in a lookup table. Routing can be done
based on a single field, or a combination of fields in a detail record.

3.3.7 Compression and Decompression

Compression can be used to decrease the volume of distributed data thereby
reducing the amount of storage capacity needed for long-term storage, or
reducing the file transfer time in a network with low bandwidth. The File and
event mediation can also decompress collected compressed charging data.

The following compression and decompression algorithms are supported:

• GZIP

• PKZIP

71/1551-FAM 901 434 Uen N | 2013-04-17 17

 Network Element Description

3.3.8 Consolidation

The consolidation function makes it possible to compile a new detail record with
data from different sources and formats.

The consolidation function provides possibilities for storage, retrieval, update,

and removal of single detail records. This combined with the functions of
the processing language, creates a powerful tool for making any kind of
combination of detail records.

The consolidation can be realized in two ways:

• Memory-based

• Database-based

The use of a database for consolidation enables more flexibility regarding

input formats, consolidation options, output formats and cleanup
procedures.

The consolidation can be scheduled to take place at predefined times.

There is a timer for each consolidation activity. This timer controls how long
a specific unconsolidated detail record will be stored before it is reallocated.
The timer can be configured graphically in the GUI.

The reallocated detail records are stored in a special directory for the memory
based consolidator and in a special database table for the database based
consolidator. Optionally, an alarm can be raised.

With configuration services the unmatched detail records can be pulled from
disk, processed, and distributed to several business systems.

All consolidation activities are logged in a consolidation log, see Section 3.8.7
on page 29.

3.3.9 Database and Lookup

The lookup tables make it simple to handle large data tables.

For example, it can be used to define that detail records originating from a
certain group of subscribers are to be processed in a particular way. The
lookup tables can be accessed from DUP, for example, in Value-Routers and
formatters using a function, which takes a table name and a key as argument
and returns the data for that key.

It is possible to use wildcard in the lookup statements.

The following six different kinds of lookup functions are supported:

• Memory Lookup Table

18 71/1551-FAM 901 434 Uen N | 2013-04-17

 Functions

The information in this table is allocated in the RAM of the server. This
grants high performance when accessing the entries in the table. The
information in the table can be kept up to date without stopping the
processing. A copy of this information is also available on file.

• Tree Lookup Table

The tree table is managed similar to the memory lookup table. However, it
is used for number analysis of telephony network directory numbers, for
example, phone numbers. A copy of this information is also available on file.

• Database Lookup Table

If it is required to handle large volumes of data in lookup tables, a lookup

table can be allocated in a database server. The database lookup tables
can be used to perform similar functions as a general memory lookup table.

• LDAP Lookup Table

Lightweight Directory Access Protocol (LDAP) is an internet standard

protocol for accessing and managing directory services. It is based on a
client-server model where File and event mediation acts as a client. The
LDAP server stores description information about, for example, people
or resources.

• DNS Lookup Table

The Domain Name Server (DNS) is the way that internet domain names are
located and translated into internet protocol addresses. The DNS lookup
function can be used to call a central database holding different kinds of
subscriber information.

• Memory Database Lookup Table

This lookup option is a combination of memory lookup and database

lookup. The lookup table is read from database and kept in memory (RAM)
for faster access. This in-memory copy of the lookup table is refreshed from
the database at regular intervals.

The File and event mediation also offers the possibility to access data in external
database tables using DUP. The following functions are possible to use:

• Insert data

• Remove data

• Update and modify data

• Selecting data

It is possible to configure the following logging options when data is saved

in the database:

71/1551-FAM 901 434 Uen N | 2013-04-17 19

 Network Element Description

• Log per file

An entry in the log is created each time a file containing detail records is
processed.

• Log per detail record type

An entry in the log is created each time a detail record of a specified type is
processed.

• Log per individual detail record

An entry in the log is created each time a detail record is processed.

Each log entry contains a timestamp as well as information of the origin of

the data saved.

There also exists a database collector, which makes it possible to reinsert the
detail records distributed by a database distributor into the processing flow.

3.4 Distribution
The File and event mediation supports the following distribution related
functions:

• Multiple Destinations

Distribution of the same detail records to more than one business system
at the same time. Detail records and files can be distributed in different
formats to different destinations.

• Alternative Destination and Protocols

Definition of an alternative route to a business system, in case of link failure.

• Buffering

In case of a link failure, the detail records are buffered on mirrored disks
and sent automatically as soon as it is possible to distribute to the business
system again.

• Scheduled File Distribution

Detail records can be scheduled to be delivered at certain time-intervals or

at certain moments in time, for example at 12.00 AM each night.

• Triggering

Can be used, for example, to alert a business system each time it has
received a new file or to distribute alarms through e-mail.

20 71/1551-FAM 901 434 Uen N | 2013-04-17

 Functions

Detail records can be distributed to different types of business systems, for

example:

• Billing Systems

• Prepaid Systems

• Data Warehouses

• Subscriber Behavior System

• Interconnect Clearing Houses

• Roaming Centers

• Fraud Detection Systems

• BSCS Distributor

BSCS Distributor is a separate executable that is created by BGwDistributor.

The BSCS Distributor interacts with the BSCS data server and sends the
files to BSCS for billing and invoicing. The BSCS Distributor interacts with
the BSCS database to fetch the BSCS UDR configuration. BSCS system
expects input data in the UDR format which is LHS proprietary format.

Note: BSCS Distributor is a 64 bit application. Following platforms are

not supported:

• PA-RISC

• x86 Linux

The BSCS configuration contains a collector that can be configured to

collect data from following Ericsson supported nodes:

0 MSC 13.0/13.1/13.2

0 SGSN R8

0 GGSN R5

The protocols supported offer generic support for any distributor using the
supported protocols and encoders with small modifications. In these cases
only a new ASN.1 data structure is to be added. This can be configured and
customized in a flexible way by the user. New distributors can also be offered
from Ericsson as customizations with short lead times if requested.

3.4.1 Intermediate Distributor

Files distributed by an Intermediate distributor can only be collected by an

Intermediate collector. The following distributors can act as Intermediate
Distributors:

71/1551-FAM 901 434 Uen N | 2013-04-17 21

 Network Element Description

• Disk

• FTP

• SFTP

• Auto Load Balance

3.5 Revenue Assurance

The following communication security functions are available:

• Alternative Destinations

The File and event mediation supports alternative routing of charging

information when distributing. This can for example be useful in case a
business system fails to respond on a call for communication. It is possible
to configure the server to choose an alternative destination to deliver the
charging information. If the primary business system is not reachable, an
alarm will be raised to notify the user about this.

• Buffering

If it is not possible to distribute detail records to a business system, the

detail records are buffered and are sent automatically as soon as it is
possible to distribute to the business system again. This means that all
data buffered, all configurations, all logs and all alarms are kept in safe
storage on the mirrored disks and databases.

• Alternative Media

Network operators can choose to store the charging data from the network
elements in the network, on tape media on a routine basis. This operation
is used as a first level of backup. For example, in case a network element
becomes isolated due to a communication link failure that lasts for a long
time, the normal flow would be broken. By using the charging data that is
backed up on tape, the network operator is able to process the charging
data. This function enables processing of charging data even if the network
is down for a long period of time.

• FTP Recovery Procedure

Manual recovery is supported for FTP. A list of all the files that are available
for collection in the network element can be monitored in the GUI. In this
list it is possible to manually choose which files should be collected again.
FTP initiator is used to fetch the files.

For more information on File and event mediation recovery, see Section
5.4 on page 38.

• Post-collection Acknowledgement Procedures

22 71/1551-FAM 901 434 Uen N | 2013-04-17

 Functions

There exist network elements that require individual handshaking

procedures when transmitting charging related files. For example, a
network element may require an acknowledgement that the file reception
was successful prior to sending the next file. A flexible triggering function
is provided allowing the execution of tailor made UNIX® scripts or other
executable programs written in, for example C++ or Java, each time a file
is received from a specific network element. The triggering function could
also be used to send an alert each time a file is received from a particular
network element.

• IOG Recovery Procedures

The recovery procedures are available when the communication protocol

between the IOG and the File and event mediation is MTP/SFO. By
supporting automatic, as well as manually assisted recovery procedures,
management efforts in case of unexpected failures are minimized.
Charging data files, which are subject for recovery, are those files residing
in the IOG and have the following:

0 Transfer flag set to FAILED

0 Transfer flag set to YES, but are not present in the File and event
mediation

0 Inconsistent size

For more information on File and event mediation recovery, see Section 5.4
on page 38.

3.6 Advanced CDR Repair System

The Advanced CDR Repair System is a graphical tool for viewing and editing
detail record files. The main purpose of this utility is to correct faulty detail
records.

Before detail record data can be edited, it must be decoded from its external
format to an internal format which the Advanced CDR Repair System application
understands. The Advanced CDR Repair System accomplishes this by using
the format information stored in the database. When editing completes, the
data is encoded into an external format (either into original or some other
format) before being written to the original or another detail record file.

The Advanced CDR Repair System consists of a server and a client. The
server runs on either the same system as the client or on a different system.

The server has two main tasks:

• All the work of reading, decoding, encoding, recovering and writing the
detail record files

71/1551-FAM 901 434 Uen N | 2013-04-17 23

 Network Element Description

• Collection of data from the database that is required by the client, for
example, record format information

The client is responsible for the interface towards the user. For example, the
client displays the decoded detail record data in a spreadsheet, where it may
be edited.

The Advanced CDR Repair System has an application specific audit function.
For more information, see Section 3.8.8 on page 29.

3.6.1 Functions
The following functions are available for the Advanced CDR Repair System.

• Encode and Decode Detail Record Files

When opening a file, the user selects the file format and the external
format. The Advanced CDR Repair System then displays the internal
formats that can be mapped to the selected external format. All formats
are retrieved from the database and new formats must first be added with
the format builder before they can be used with the Advanced CDR Repair
System. When encoding a corrected file, the user can select another format
compared to the original, and it is possible to save the corrected file with a
new name or to overwrite the original file. It is also possible to move the
original file, at decoding, to avoid overwriting it.

• Mass Editing/Multiple File Editing

Editing rules can be defined and applied across many detail record files
at the same time, but all files must be of the same format. Each function
consists of one or more filters or editing functions.

• Split Files

It is possible to save modified detail records to one file and save

non-modified detail records to another. It is also possible to split a detail
record file based on detail record selection. The user may define naming
rules when generating new files. The name rule convention contains:

0 source file

0 date

0 time

0 user defined strings

0 a qualifier

• Export Files

24 71/1551-FAM 901 434 Uen N | 2013-04-17

 Functions

This function allows the user to export detail record contents from the
spreadsheet view to a simple text file.

• Global Filters

This function makes it possible to define filters on the Advanced CDR

Repair System server, which can be used on all Advanced CDR Repair
System clients.

• Filter Match Count

This function makes it possible to visualize the number of detail records

that match each filter.

• Compress and Decompress

An optional function, which when selected, compresses detail record

files while encoding (saving) them onto disk. The Advanced CDR Repair
System decompresses these compressed files (.gz) when they are opened
and viewed.

3.7 Security
File and event mediation is assumed to be part of a trusted domain, for
example, an Ethernet (sub) network that is protected from the outside world
through a firewall. Configuration and access to the trusted domain is the
responsibility of the network operator. The hardware and operating systems
also offer a wide range of standard security mechanisms that can be configured
by the system administrator.

3.7.1 Client Security

Clients (GUI) are based on Java. In order to grant a client access towards File
Mediation Manager (FMM), the OS running on the FMM machine needs to be
configured to treat the client as a trusted client (for example to allow the client
to access the FMM). Apart from the Access Control, File and event mediation
requires user authentication (user ID and password) from GUI clients.

File and event mediation uses a hierarchical permission scheme.

3.7.2 Data Consistency

The following data consistency functions are available for the File and event
mediation:

• Detail Record Time Gap Detection

This function makes it possible to detect out-of-sequence or missing detail

records by comparing the time stamp of the previously processed detail

71/1551-FAM 901 434 Uen N | 2013-04-17 25

 Network Element Description

record to the time stamp of the detail record being currently processed. The
time difference must be within a defined interval.

• Detail Record Duplicate Detection

This function makes it possible to check if the detail record already has been
processed by performing a checksum of specified fields in the detail record.

• Detail Record Sequence Validation

This function is based on the Record Sequence Number (RSN) field in

the detail records.

• Trace File Function

This function makes it possible to trace individual files through the chain of
events in a configuration. This means that it is possible to see which input
files that have resulted in an output file or which output files that have been
generated as a result of a certain input file.

• File Duplication Check

The file duplication check is based on a file sequence number check.

This function requires that a unique identifier (for example file sequence
number) exists.

• Data Lost Check

In the processing function it is possible to do detail record lost check.

The check uses one field in all detail records (per detail record type) and
summarizes the values of that field for all incoming and for all outgoing
detail records. This configuration can be performed from the GUI as well.

Performing periodic checks in the form of a comparison of the sums for

incoming and outgoing detail records makes it possible to find abnormalities
in the difference between these two sums. For example, if the outgoing
sum is lower than the incoming, revenue might have been lost.

• Field out of range Alarm

The File and event mediation can be configured to generate an alarm if

the value of a specified field in a detail record is out of range. With this
function, erroneous data can be detected.

• Archiving

The archiving function makes it possible to do long term storage on tape.

This can, for example, be used to make a security backup of charging data
files and store them for later use. Searches can be performed on the stored
files. Reprocessing and distribution of stored files are also possible. Raw,
untouched copies of the charging will be stored away.

• IOG Transfer Verification

26 71/1551-FAM 901 434 Uen N | 2013-04-17

 Functions

This mechanism can be used to validate charging data files transferred

from Ericsson IOG equipment. Basically, this function allows the network
operator to validate that the charging data files sent from a network element
follow a consecutive order. The validation is based on the sequence
numbers, which are reflected in the charging data file names. It is useful to
network operators for surveillance purposes. The File and event mediation
can be configured to raise an alarm in case an inconsistent transfer flag
occurs. That is, if a charging data file marked as non-transferred, is
followed by a charging data file marked as transferred.

• Traffic Monitoring

This feature makes it possible for the operator to monitor the pattern of the
traffic coming in to File and event mediation, comparing it with historical
data and to discover deviations. An example could be that the number of
incoming records from originating calls starts to decline when it should
increasing. This will allow the operator to find any possible faults at the
correct time.

• Event Tracing and Debugging

Event tracing and debugging offers advanced tools for finding and
eliminating faults in the business logic and thus preventing corruption or
loss of charging data.

• Service Simulator

This function makes it possible to simulate traffic coming into File and event
mediation. The service simulator is configured to create any number of
detail records and filling them with the desired content. The function can
be used, among others, for verifying business logic implementation before
applying it to a live environment.

3.8 File and event mediation Logs

An Oracle database is used to store all the logs generated. Using a database
for storing logs makes it possible to use external tools for reading, searching,
and generating reports.

File and event mediation can be configured to distribute the logs to external
systems. It is possible to configure the types of log entries to be distributed and
to format the log entries to suit the external systems.

The following logs are connected to File and event mediation. Most of these
logs are also available through their respective GUIs if the function Advanced
CDR Repair System is delivered:

• Event log, see Section 3.8.1 on page 28

• Statistics log, see Section 3.8.2 on page 28

71/1551-FAM 901 434 Uen N | 2013-04-17 27

 Network Element Description

• Alarm log, see Section 3.8.3 on page 28

• In Service Performance log, see Section 3.8.4 on page 28

• Hardware Supervision log, see Section 3.8.5 on page 28

• Audit trail, see Section 3.8.6 on page 29

• Consolidation log, see Section 3.8.7 on page 29

• Advanced CDR Repair System Audit log, see Section 3.8.8 on page 29

• FMM Event log, see Section 3.8.9 on page 29

3.8.1 Event Log

File and event mediation has an event log. The log keeps track of events
that modify the state of the server or the data stored on the server. Each log
entry holds information such as time of event and which user or activity that
caused the event.

3.8.2 Statistics Log

From the GUI of the statistics function, the user can initiate the collection of
statistical information. The throughput statistical information can be viewed
graphically. It is also possible to print this information either directly to a printer
or to a postscript file.

3.8.3 Alarm Log

The alarm log keeps track of occurred alarm events, as well as ceased alarm
events. All relevant information such as date, time, and alarm information
regarding the event is stored in the alarm log.

3.8.4 In Service Performance Log

The In Service Performance (ISP) log contains information about uptime and
downtime for the processes in the server. The ISP log offers history monitoring.

Note: This log is not available through the GUI.

3.8.5 Hardware Supervision Log

The hardware supervision log contains information regarding processor load,
memory usage, and diskspace.

28 71/1551-FAM 901 434 Uen N | 2013-04-17

 Functions

3.8.6 Audit Trail Log

The audit trail log displays statistics associated with the collection, processing
and distribution of files.

3.8.7 Consolidation Log

The consolidation log contains information regarding matching information
for the consolidation function. One log exists for each consolidation activity.
The log file consists of information such as how many entries that has been
removed, how many that are left as well as timestamps.

Note: The Consolidator log tab is for database consolidators. Only database
consolidators should be used for seeing the logs in the Consolidator
log tab.

3.8.8 Advanced CDR Repair System Audit Log

The Advanced CDR Repair System maintains a special audit log to record
changes to detail record files. The audit log can be viewed through two types of
reports included in the Advanced CDR Repair System:

• Audit Log Report of unfinished sessions

This report contains information regarding editing sessions that have not
been finished in an accurate way or are still in progress. This allows
the user to track what kind of changes have been made to a file before
encoding the file.

• Audit Log History Report

The report visualizes each file that has been opened, the changes that
have been made to a file, which Value-Routers were applied, what kind of
editing was done, who made the changes, how many detail records were
changed, when the changes were made, and so on. This could be used for
legal purposes or to track other information related to changes that have
been made to detail records within the file.

3.8.9 FMM Event log

File and event mediation has an event log. The log keeps track of events that
modify the state of the FMM or the data stored on the FMM. Each log entry
hold information such as time of event and which user or activity that caused
the event.

3.9 Alarm Handling

File and event mediation generate alarms in case of abnormal events. These
alarms are logged in the alarm log, see Section 3.8.3 on page 28. File and

71/1551-FAM 901 434 Uen N | 2013-04-17 29

 Network Element Description

event mediation can be configured to distribute, and cease alarms to external

surveillance systems, for example, network management systems. The
distribution can be done using any of the file based distribution protocols or
any of the following protocols:

• The standardized (3GPP) alarm IRP interface

• Simple Network Management Protocol (SNMP) over TCP/IP

• Text file alarm adaptation unit (TXF) over TCP/IP

For more information regarding interfaces and protocols, see Section 2.3 on
page 3.

3.9.1 Sun Management Centre

Sun Management Centre (Sun MC) can be used to monitor the hardware if File
and event mediation is delivered with Sun hardware products.

Note: Sun Management Centre (Sun MC) only works with Sun hardware.

Sun MC software is an open, extensible system monitoring and management

solution that uses Simple Network Management Protocol (SNMP). Sun MC
provides integrated and comprehensive enterprise-wide management of Sun
products.

The product consists of different parts that can be combined depending on the
requirements. File and event mediation uses the Sun MC, Advanced Systems
Monitoring, which provides the following functions:

• Full kernel reader function

• Solaris health monitoring

• File system monitoring

• Directory size monitoring

• Process monitoring and log viewing

3.10 Auto Load Balance

The Auto Load Balance (ALB) feature enables the user to put a File and event
server as a file proxy with load balancing functionality in front of several File
and event servers processing the data. The proxy File and event Server is able
to balance the load and route the files to the correct File and event Servers
based on the configuration settings.

Files are distributed to the individual destination links based on Weighted

Round Robin algorithm decision.

30 71/1551-FAM 901 434 Uen N | 2013-04-17

 Functions

3.11 BSCS
The section provides information about BSCS Formatter, BSCS ASN.1
structure, BSCS CDR Memory Duplicate Detection, BSCS Consolidator, and
BSCS Collector.

Note: BSCS is not supported on Linux Platform.

3.11.1 BSCS Formatter

The Formatter converts the Ericsson CDR to BSCS UDR. For each of the
supported node, a formatter DUP script is delivered as a .bfo file. Following
are the DUP scripts for the different nodes:

• MSC 13.0 : CME20R13MSCberToBSCSR2udr.bfo

• MSC 13.1 : CME20R131MSCberToBSCSR2udr.bfo

• MSC 13.2 : CME20R132MSCberToBSCSR2udr.bfo

• SSGN R8 : SGSN80berToBSCSR2udr.bfo

• GGSN R5 : EricssonGGSNR5berToBSCSR2udr.bfo

3.11.2 BSCS ASN.1

The following ASN.1 structure represents BSCS iX R2 UDR:

BSCSR2udr.asn1

The following ASN.1 structure is used by memDbLookup() function in

formatters scripts.

BSCSR2Lookup.asn1

The following ASN.1 structure represents BSCS iX R3 UDR:

BSCSR3udr.asn1 (Along with Record Part and Base Part, this ASN1 also
supports the structures for Charge Part and Free Unit Part). Charge Part and
Free Unit Part are used only when rated CDRs are sent to BSCS.

The following ASN.1 structure represents BSCS iX R3 BIR:

BSCSR3bir.asn1 (This ASN1 can be used with BSCS iX R3 when sending

Balance Information Records to BSCS iX R3)

The following ASN.1 structure represents BSCS iX R3 XSC:

BSCSR3xsc.asn1 (This ASN1 can be used with BSCS iX R3 when sending

Contract Data Changes records to BSCS iX R3 )

71/1551-FAM 901 434 Uen N | 2013-04-17 31

 Network Element Description

No sample configuration is provided to illustrate the UDR with Charge and

Free Unit Part, BIR and XSC.

3.11.3 BSCS CDR Memory Duplicate Detection

CDR Memory Duplicate Detection is used to detect the duplicate UDRs and
allow non-duplicate UDR to be processed further.

The following key fields of UDR perform the Duplicate Detection:

• BSCSR2udr.uds_base_part_id.call_type_info.call_type

• BSCSR2udr.uds_base_part_id.start_time.timestamp

• BSCSR2udr.uds_base_part_id.start_time.time_offset

• BSCSR2udr.uds_record_id.s_p_number.address

• BSCSR2udr.uds_record_id.s_p_number.numbering_plan

• BSCSR2udr.uds_record_id.s_p_port.address

• BSCSR2udr.uds_record_id.s_p_port.numbering_plan

• BSCSR2udr.uds_record_id.o_p_number.address

• BSCSR2udr.uds_record_id.o_p_number.numbering_plan

• BSCSR2udr.uds_base_part_id.service.svl_code

3.11.4 BSCS Consolidator

Consolidator is used to assemble and consolidate all the partial UDRs into a
single UDR.

The user configures the following options in Consolidator:

• Assembly: This is a flag to switch on or off the assembly in the

Consolidator script. It can be set to TRUE or FALSE.

Partial UDRs are assembled only in case when Assembly is set to TRUE. If
Assembly is set to FALSE then all the input UDR’s are distributed without
any consolidation.

• Threshold Time: The value is set in seconds in the Consolidator scripts.

When incoming partial UDRs of a call exceeds the total call duration of this
maximum value, then consolidator consolidates them into single record and
distribute it without waiting further.

• Max CDR Age: The value is set in minutes. It defines the maximum time
to wait for the next expected partial UDR. When the time exceeds since
the arrival of the latest partial UDR into the system, consolidator keeps this

32 71/1551-FAM 901 434 Uen N | 2013-04-17

 Functions

partially consolidated UDR into the directory specified in the unmatched

section of the consolidator property table.

Note: From this directory these partially consolidated UDRs can be

collected using Disk Collector and distributed through the Formatter
using BSCSUnmatchedRecordberToBSCSR2udr.bfo to the
BSCS distributor.

3.11.5 BSCS Collector

BSCS Collector is a separate executable that is created by BGwCollector. The

BSCS Collector interacts with the BSCS DATA server and collects the files
from BSCS for billing and invoicing. BSCS system generates output data in
the UDS format which is LHS proprietary format.

Note: BSCS Collector is a 64 bit application and is not supported on PA-RISC

platform.

3.12 Charging SDK

Support for Charging SDK for CCN has been introduced. This feature allows
File and event to direct CDRs towards CCN for rating using SCAPv2 protocol.
Support for Direct Debit of event has also been provided.

3.13 Performance Monitor

Performance Monitoring allows the system administrator to view various File
and event System counters value graphically. It is also possible to export the
value of these counters.

3.14 CDR logging

CDR logging is used for counting the number of occurrences of a certain
logged field for each detail record.

3.15 CDR and File statistics

Provides the statistics on Incoming, Outgoing, Duplicate, Consumed, Created,
and Rejected CDRs. It is also possible to trigger CDR Logging based on values
of fields in CDRs;

3.16 Configurations for Mediation of Network Data

File and event mediation provides protected configurations which extract
Service Assurance information from CDRs generated by Circuit Switch (CS)
and Packet Switch (PS) network. These Service Assurance CDRs can be

71/1551-FAM 901 434 Uen N | 2013-04-17 33

 Network Element Description

used to analyze the quality of CS and PS network. These can be used for
Subscriber Tracing and Analysis, Terminal Analysis, Network Analysis, and
Troubleshooting.

The protected configurations are as follows:

• MSCServiceAssuranceConfig

This configuration supports input CDRs from MSC versions R9 to R14.1.

The supported MSC events are as follows:

0 roamingCallForwarding

0 callForwarding

0 mSOriginating

0 mSTerminating

0 mSOriginatingSMSinMSC

0 mSTerminatingSMSinMSC

0 locationServices

The MSC generates a CDR for each call or SMS. A CDR collects charging
information related to Voice/SMS services for a CS mobile. It stores
information such as calling/called IMSI, calling/called MSISDN, start/end
time, etc.

It is possible that the default CDR output from the network elements does
not contain failure-oriented CDRs, for example calls did not get established,
or were dropped for some technical reason. It is recommended to change
NE’s charging output configuration to include these CDRs as well.

The configuration takes input CDRs from MSC for processing. During
processing non-supported and duplicate CDRs are discarded. After these
transformations are applied on the CDRs to deliver Assurance CDRs in
XML format.

• GSNServiceAssuranceConfig

This configuration supports input CDRs from SGSN and GGSN versions
2009A to 2010B.

The supported event for SGSN is sgsnPDPRecord. The supported events

for GGSN are ggsnPDPRecord and egsnPDPRecord.

The configuration takes input CDRs from SGSN and GGSN. CDRs from
GGSN (for home network) and SGSN (for roaming) are processed and rest
are discarded. During processing non-supported and duplicate CDRs are

34 71/1551-FAM 901 434 Uen N | 2013-04-17

 Functions

discarded and remaining are converted into XML format and distributed
over SFTP.

3.17 Configuration Pack

Configuration Pack is a configuration in an XML file with its dependencies (for
example, data structures, lookup tables, functions, user defined alarms and
Java activity) required to activate and run the configuration. Configuration Pack
can also include a protected configuration with its dependencies excluding
site specific parameters.

71/1551-FAM 901 434 Uen N | 2013-04-17 35

 Network Element Description

4 Operation and Maintenance

4.1 Graphical User Interface

The File and event mediation Graphical User Interface (GUI) is built in Java.
It is a stand alone application. In the GUI the complete configuration of the
system is depicted in a graph including connected collectors, processing
activities and distributors. In this editable graph, the user defines:

• The network elements that will be connected to the File and event mediation
including formats and protocol information

• The business systems that will be connected to the File and event
mediation including formats and protocol information

• The processing activities used to process the charging information

The user can login to FMM with the help of GUI. All the File and event servers
connected to the FMM can be monitored from the GUI. It is possible to see
whether the servers are active (running) or not. All server settings and the
different data flows can be configured from the GUI.

It is also possible for the user to monitor the data flow through the File and
event mediation, inspect logs, handle alarms, start and stop specific activities in
the configuration, or to start and stop the whole configuration.

4.2 Command Line Interface

The Command Line Interface (CLI) will offer possibilities to perform operations
on a File and event configuration from a shell or from an external program. The
feature can typically be used to perform batch updates or script controlled
updates and can save the operator's time and prevent human errors. Basic
operation and maintenance operations are supported such as import and export
configurations, get status, start and stop individual activities or servers.

36 71/1551-FAM 901 434 Uen N | 2013-04-17

 Characteristics

5 Characteristics

5.1 Performance

5.1.1 Scalable Architecture

File and event mediation consists of multiple processes, which improves the
scalability. Each of the components collection, processing, and distribution can
have multiple processes and threads. This offers a very flexible system.

The architecture offers a user-friendly access of parameters, which can be

used for tuning of the configurations to achieve better performance and use
of the system resources. Parameters such as the number of processes and
threads can easily be configured directly in the GUI.

The multi process architecture means that, for example, new third party
interfaces can be placed in separate processes. This means that the security
will increase, since the system will be up and running even if one of the third
party processes goes down.

5.2 Availability

5.2.1 High Availability

To attain high availability, cluster software is used.

The standard cluster solution consists of a 1+1 solution, that is, two nodes
working together in a cluster. The cluster works in a symmetric way, where
both the system nodes can be utilized. In case of n+1 cluster solution, several
nodes working together in a cluster. It is recommended to use +1 node as
a standby node.

In case of failure of one of the system nodes, the cluster solution makes it
possible for one system node to take over disks and network interfaces from
the other system node. The advantage of this solution is that the cluster
detects errors, and fail-over instantaneously and automatically, and that it is
not dependent on functions within the network. All File and event mediation
functions are supported by this high availability solution. The load must not be
higher than what one single node can take of the total load.

71/1551-FAM 901 434 Uen N | 2013-04-17 37

 Network Element Description

5.2.2 Runtime Configuration

For the runtime configuration, it is possible to change the configuration and then
decide if a full activation or a partly runtime activation should be performed. The
runtime configuration enables the following:

• Possibility to add and remove processing flows without affecting other flows

• Modification of business logic such as Value-Router, formatter, and

consolidation without stopping the collection or distribution

• Modification of communication settings without affecting ongoing processes

5.3 Reliability

5.3.1 Mirrored Disks

Mirrored disks are used in all solutions to ensure that no data is lost in case of
disk failure. This includes all buffered data, configurations, logs, and alarms.

5.4 Recovery
The recovery functions can be divided into three different levels:

• File System Recovery

There are a some files from the File and event mediation file structure that
should be backed-up to ensure fast recovery of File and event mediation.

• Server and Manager Process Recovery

There is a function for supervising the server and manage processes. The
supervision function checks that these processes are up and running. If
any of the two processes has gone down for any reason, the File and event
mediation tries to restart the processes.

• Activity Recovery

The activity recovery functions are independent of the activity configuration.

If an activity stops for any reason the File and event mediation server
restarts this activity automatically. The internal message queue will be
restored from the log file and the activity can start processing from the point
where it was discontinued. An alarm event is created which can be used to
inform the operations support system.

• Customizations

38 71/1551-FAM 901 434 Uen N | 2013-04-17

 Characteristics

Customized recovery is enabled by using the available activities, and

configure them to fulfill a specific recovery function. This implies that these
customized recovery functions are activity specific.

5.5 Secured Password

All passwords in the Multi Mediation 7 are in encrypted form when stored in file,
database, or when transferred over the network.

71/1551-FAM 901 434 Uen N | 2013-04-17 39

 Glossary

Glossary

Refer the Glossary of Terms document in

Ericsson Multi Mediation 7 - File and event
mediation, Glossary of Terms and Acronyms,
Reference [2].

71/1551-FAM 901 434 Uen N | 2013-04-17 40

 Reference List

Reference List

Ericsson Documents

[1] Ericsson Multi Mediation 7 - File and event mediation, Interface

Description, 1/15519-FAY 320 40 Uen

[2] Ericsson Multi Mediation 7 - File and event mediation, Glossary of Terms
and Acronyms, 71/0033-FAM 901 434 Uen

[3] Ericsson Multi Mediation 7 - File and event mediation, User's Guide,
71/1553-FAM 901 434 Uen

[4] Ericsson Multi Mediation 7 - File and event mediation, System

Administrator's Guide for Solaris, 71/1543-FAM 901 434 Uen

[5] Ericsson Multi Mediation 7 - File and event mediation, Procedure Manual,
71/1546-FAM 901 434Uen

[6] Ericsson Multi Mediation 7 - Network Impact Report, 71/10948-FAM

901434

Standards

[7] Specification of Abstract Syntax Notation One (ASN.1) ITU-T

Recommendation X.680

[8] Specification of Basic Encoding Rules (BER) for Abstract Syntax Notation
One (ASN.1) ITU-T Recommendation X.690

71/1551-FAM 901 434 Uen N | 2013-04-17 41