Technical Product Description, Billing Gateway R9.1

11/9/2018 Technical product description, Billing Gateway R9.
This is the HTML version of the file http://learning.ericsson.net/emm_bgw/cpi_manual/cpi_manual.pdf. Google automatically generates
HTML versions of documents as we crawl the web.
Tip: To quickly find your search term on this page, press Ctrl+F or ⌘-F (Mac) and use the find bar.
Page 1
Technical Product Description 1 (65)
Technical product description,

Billing Gateway R9.1
CHAPTERS
1. INTRODUCTION 3
2. OPERATOR BENEFITS 3
3. BGW R9.1 OVERVIEW 3
4. BGW R9.1 FEATURES 3
5. TERMINOLOGY 3
6. REFERENCES 3
http://webcache.googleusercontent.com/search?q=cache:http://learning.ericsson.net/emm_bgw/cpi_manual/cpi_manual.pdf 1/68
11/9/2018 Technical product description, Billing Gateway R9.1
© Telefonaktiebolaget LM Ericsson 2001 - All Rights Reserved
3/1551-ANE 402 02 Rev A 2001-11-19 © Ericsson. Commercial in Confidence
Page 2
Content
1. INTRODUCTION 3
1.1. Document Purpose and Scope 3
1.2. General 3
1.3. Description 3
2. OPERATOR BENEFITS 3
2.1. Increased competitiveness 3
2.2. Protection of investments 3
2.3. High level of flexibility 3
3. BGW R9.1 OVERVIEW 3
3.1. Mediator scalability 3

3.1.1. Splitting a Mediator configuration into groups 3
3.1.2. Splitting groups into components 3
3.1.3. Supporting processes 3
3.2. Mediator Interfaces 3

3.2.1. Collection of charging information 3
3.2.2. Distribution of charging information 3
3.2.3. Distribution of alarm information 3
3.2.4. Mediator Graphical User Interface 3
3.2.5. Oracle Database Interface 3
3.2.6. Prepaid solutions and minimum delay 3
3.3. Supported nodes 3

3.3.1. Multi vendor support 3
3.4. Supported Services 3
4. BGW R9.1 FEATURES 3
4.1. Collection and distribution 3

4.1.1. SDK 3
4.2. Security aspects 3

4.2.1. Network Security 3
4.2.2. Client Security 3
4.2.3. Network Element Security 3
4.2.4. Multiple destination streams 3
4.2.5. CDR Lost Check 3
4.2.6. Alternative destinations 3
4.2.7. Buffering of CDRs 3
Page 3
4.2.8. Archiving 3
4.2.9. TT-file transfer validation 3
4.2.10. Alternative media 3
4.2.11. Recovery procedures 3
4.2.12. High Availability solutions 3
4.3. Revenue Integrity 3

4.3.1. CDR Editor 3
4.3.2. CDR sequence validation 3
4.3.3. CDR Lost Check 3
4.3.4. TT-file transfer validation 3
4.3.5. CDR duplicate check 3
4.3.6. Post-collection acknowledgement procedures 3
4.4. Processing 3
4.4.1. Decoding and encoding 3
4.4.2. Compression 3
4.4.3. Filtering 3
4.4.4. Formatting 3
4.4.5. Consolidation 3
4.4.6. Look-up tables 3
4.4.7. Rating 3
4.5. Logging in Mediator 3

4.5.1. Audit trail log 3
4.5.2. Alarm log 3
4.5.3. Event log 3
4.5.4. Statistics 3
4.5.5. In service performance log 3
4.6. Surveillance of the Mediator 3
5. TERMINOLOGY 3
6. REFERENCES 3
Page 4
© Telefonaktiebolaget LM Ericsson 2001 - All Rights Reserved

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 errors or damages of any kind resulting from the use of this document.
Page 5
1. INTRODUCTION
1.1. Document Purpose and Scope
The purpose of this document is to give an overall view of the features in Billing
Gateway (BGw) R9.1. BGw R9.1 consists of the following applications:
• BGw Mediator R9.1, henceforth only referred to as Mediator.
• BGw R9.1 Software Development Kit, henceforth only referred to as

Software Development Kit (SDK).
• BGw R9.1 CDR Editor, henceforth only referred to as CDR Editor.
Each of these applications are covered by this document.
1.2. General
Intensive competition
The telecommunication market across the world is characterised by
deregulation resulting in intensive competition between operators as well as
service providers. Operators are competing with each other in order to gain a
larger subscriber-base , as well as higher usage of their communication
network. To cope with the competition, operators strive to attract new
customers by offering differentiated services. This basically means, when
competing the operators have to provide services to subscribers that are more
attractive than the competitors. Service usage is chargeable, and this forms
an important source of income for operators.
Charging mechanism
Within telecommunication networks there are built-in mechanisms that allow
measuring, as well as, collection of charging related information. Whenever a
subscriber is making use of the telecommunication network, for example by
making a telephone call, the network will generate one or several Call Detail
Records (CDRs). The CDRs are used to keep track of the subscriber’s usage
of the telecommunication network.
Page 6
Introduction of GPRS and UMTS

The introduction of GPRS and UMTS will have major impacts on charging, for
example:
• The amount of charging data will increase.
• The requirements on making CDRs available for post processing in

short time after call completion, or usage of a service will increase.
• CDRs will no longer be required by internal systems only, they shall

also be available within minutes in the home environment, even when a
subscriber is roaming internationally.
• The competition between operators will get tougher and tougher.
• Subscriber demands for access to new services will increase. The

ability to rapidly introduce and charge for new services will be crucial
for operators to attract subscribers, retain subscribers, and generate
revenue.
This introduces a demand of having the possibility to use the transferred data
for subscriber analysis and accounting in order to avoid losing customers to
other providers. Operators with service providers, content providers, access
providers and so on, will also need to search for new media to get their
margins. One way can be to analyse the subscriber data and actions in such
a detailed way that you can have the answer to questions like:
• What is the perceived quality?
• Which services will specific subscriber groups be attracted to?
• How should services be bundled?
If operators can find these answers, the information could be used to provide
subcontractors with important information about user preferences and
perceived quality.
In UMTS the Mediator handles the off-line interface to the charging network. It
will also provide an interface to the Charging Control Node (CCN, which
handles the on-line interface), and work as a back up for this node. The
interface will be based on a subset of Diameter.
Datacom and IP
A wide range of new services on the Internet such as IP-telephony, streaming
media, video conferencing, application hosting and other services, places new
demands on the mediation systems. A probable development is also the wide
acceptance of the Internet Protocol Detailed Record (IPDR) initiative. In some
cases the mediation system will be responsible for the creation of the IPDRs,
as some network elements will not be able to create a complete IPDR.
Page 7
Business support systems

To an operator it is very crucial to be able to administer their business. This
implies the usage of business support systems, for example:
• Billing and rating systems
• Fraud analysis systems
• Call behaviour systems
• Storage systems
• Interconnect systems
Communication network Business support network
Customer
administration
NE
NE Fraud Analysis
NE
Mediator
Billing system
NE
NE Other
NE
Figure 1, Mediator is situated in the operators network between the

communication network and the business support network.
A common term used to address such systems is post processing systems.

One of the most important functions within the business support network is to
calculate the amount of usage for each subscriber and produce an invoice. By
processing the charging related information the operators can produce
invoices corresponding to the service usage for each individual subscriber
connected to their network. In other words, there would not be much interest in
providing a service if it cannot be charged for.
Page 8
1.3. Description
The Ericsson Mediator is a flexible, yet very powerful billing mediation device
that assists operators in managing charging related information. The Mediator
provides a central point for collection, processing as well as distribution of
charging information. Typically the Mediator is placed between the operators’
communication network and the business support network. The overall aim of
the Mediator is to support quick and smooth introduction of services into the
communication network by providing a "single point", flexible interface for
charging related information.
The CDRs, Usage Detail Records (UDRs, that is logs and event records from
IP nodes that can be used in the Mediator to produce “real” CDRs to send
out), and other usage records can be considered as a primitive form of
revenues that, by refining, result in actual revenues. The collection and
distribution of charging data for either charging or accounting are fundamental
functions for an operator’s revenue flow. Furthermore, by facilitating an
intelligent mediation solution, the Mediator allows a high level of refining of the
charging and accounting data.
Mediator is an integrated part of the Ericsson Charging System for real time or
near real time charging, and accounting data handling, but also provides
flexible tools for all charging data management and data manipulation. The
Mediator also provides an Application Programming Interfaces (API) for data
retrieval and distribution to accommodate instant adaptation to new
communication protocols and formats. This API called Software Development
Kit (SDK) is an optional application. The SDK can be used to implement
supplier proprietary interfaces that would not be supported as standard.
Page 9
2. Operator Benefits
2.1. Increased competitiveness

The Mediator offers operators an increased competitiveness in many ways:
• The Mediator supports both Sun, and HP platforms.
• By reducing the Time To Market (TTM) when introducing new services.

The Mediator supports quick introduction of new services into the
communication network.
• By providing support for diversified charging methods, thereby allowing

adaptation of tariffs depending on subscriber profiles.
• By enabling shorter lead-times for the operator’s revenue flow (for example
the CDRs). Thereby, the Mediator contributes in minimising the amount,
as well as time, for un-credited settlements.
• By assisting business support systems, (for example Fraud Management,

Churn Management) in analysing subscriber behaviour. For example, by
offering comprehensive pre-processing of CDRs.
• One product supporting both circuit switched and packet switched data.
The Mediator supports Wireline, Mobile, Data communication, and IP
networks and the convergence between these.
• The Mediator provides possibilities to charge for time, volume, content,

event, and destination based CDRs.
2.2. Protection of investments

Operators are offered a high level protection of investment taking advantage of
the Mediator in their network:
• The Mediator supports current network technology like GSM and GPRS,
but do also offer a simple migration path to new network technology like
UMTS and IP based networks.
• The Mediator can handle scenarios when network elements are loaded
with software in different revision state, for example when a new SW
release is about to be rolled out in a large network.
• The Mediator supports network infrastructure that may be composed of

different communication technologies, that is mobile networks, wireline
networks, datacom networks. The Mediator is ready to be taken into
service in a mixed network environment, for example, Wireline Mobile
Convergence (WMC) or Telecom Datacom Convergence (TDC).
Page 10
• The Mediator is suitable for multi-vendor networks. Since it in the future will
be even more common with equipment from many different vendors the
Mediator will provide easy adaptations to multi-vendor support. For
example:
- SDK, for dynamic introduction of new decoders, encoders, and

communication protocols.
- GTP', for third party GPRS compliance according to GSM 12.15

and 3GPP standard 3G TS 32.015.
• The Mediator architecture is scalable, that is, it may be expanded as the

operators business grows. See chapter 3.1.
• The Mediator is supported by the Ericsson’s worldwide support

organization. Thus our customers are ensured high availability of high
quality support services, at local conditions. See chapter 4.2.12.
• Improvements as well as support for new services implemented as new

technologies are entering the market will be included in newer releases of
the Mediator.
• As a part of the Ericsson’s solutions, the Mediator supports new features

and enables billing from day one.
2.3. High level of flexibility

The Mediator offers flexibility in a true sense. Below some of the arguments
can be found.
• The Mediator system architecture is designed to allow changes towards its

interfacing systems.
• The Java based GUI offers a high level of flexibility when it comes to
configuring the Mediator. In the R9.1 release of the Mediator several new
parameters for tuning the system are introduced thanks to the new
architecture (see chapter 3.1).
• To make the configuration of the nodes in the processing flow even more
user-friendly, syntax highlighting is introduced in the text-editor areas of the
nodes. Together with the search and replace functions this offers a
flexible, and graspable way of configuring the BGw processing flows.
• The Mediator supports a wide range of communication protocols for

collection as well as distribution of CDRs. The Mediator supports both
Ericsson proprietary file based protocols, as open industry standard file
based protocols. Mediator also supports CDR, or block-based protocols,
as well as protocols to support IP based billing. See chapter 3.2 for more
details.
Page 11
• The possibility to dynamically introduce new decoders, encoders, and

communication protocols, through the SDK. This introduces a possibility to
add, for example, a new communication procedure in run-time, or inter-
facing of new nodes, which were not supported as a standard.
• The Mediator supports numerous formats for charging related information.

Moreover, its internal data representation is capable of representing new
data structures as they are introduced into the communication network.
• The design of the Mediator allows adaptations during operation (note, to

activate the adaptations the configuration has to be stopped). In fact a
modification of the processing flow can be tried out in a side flow without
affecting the core flow.
• The Mediator has a flexible support for new communication protocols, data
formats and the possibility to create CDRs from new types of input data.
• The Mediator streamlines charging data from any service or node, in a

multi-vendor, multi-service network.
Page 12
3. BGw R9.1 overview

3.1. Mediator scalability
Earlier versions of the Mediator were monolithic, that is, everything lived in one
process. The old architecture could take advantage of multi-threading, but
locking constraints limited the scalability. The solution for large systems was
to use multiple Mediator servers (each Mediator server in one processes).
In the R9.1 release of the Mediator the system is broken down into multiple
processes, which will improve the scalability. Each of the components
collection, processing, and distribution can have multiple processes and
threads. This offers a very flexible system. In Figure 2, an architecture
overview for the Mediator is shown. All the components, and the configurable
parameters of interest in each component, in the figure will be described in the
coming chapters.
Process
GUI Job Manager
Manager
Log Manager
Log DB
NE Groups PPS* Groups
External
Collection Processing Distribution
Collector
Component Component Component
In Buffer Out Buffer

NEs PPSs
Control Flow:
CDR Flow:
Log data Flow:
Figure 2, An overview of the Mediator architecture.

* PPS = Post Processing System
Page 13
3.1.1. Splitting a Mediator configuration into groups
Within the Mediator, the processing of files from one Network Element (NE)
proceeds independently from the processing from other NEs (with the
exception for the consolidation feature). Because of the many-to-many
relationship between the NEs, and the post processing systems, these may
not be handled in the same process, but must be treated separately.
Because of the independence between the processing from each different NE,
potentially, all processing from the same NE could be handled, and isolated,
as a separate process. A more flexible solution is however to group several
NEs in a so-called NE group (the same thing apply to the post processing
systems, that is, a post processing system group).
This grouping feature means that the user is offered a very flexible system
with full control from the configuration (through the GUI) of the performance
trade offs associated with multiple process operations.
For example, if a configuration includes an NE group that has its processes

heavily loaded, the user could either choose to assign more processes to the
group, or move one, or several, of the NEs included in the group, to another,
less heavily loaded group. The other way around, for a lightly loaded group the
user could either choose to merge the group with another group, or assign
fewer processes to the group.
This means that the user for each group has the following spectrum:
1. The complete configuration consists of one NE group including all NEs, to

which one process is assigned.
2. An NE group is created for each NE, and one process is assigned to each
group.
The first alternative is the alternative most similar to how earlier versions of the
Mediator looked like. In the second alternative every NE has its own dedicated
process, which might seem very good. However, this configuration would
require a huge amount of system resources in a large configuration.
How many processes that should be assigned to a certain group, is a question

about dimensioning, and is closely related to how the user configuration looks
like. The tuning of the system is very flexible, and fully user configurable.
3.1.2. Splitting groups into components
For both the NE groups, and the post processing system groups, there is a
process separation between the collection and distribution respectively, and
the processing. This means that in an architecture overview (see Figure 2)
these three processes can be presented as different components.
Page 14
3.1.2.1. Buffered protocols
For an incoming file received, or fetched over a buffered protocol (files or

entries written to disk) passes through three processes (components):
1. One process that collects the charging data from the NEs, and writes it to
the inbuffer in the Mediator. This component is called a collection
component. Each collection component contains one or several collectors,
which implement the NE data collection feature. That is, receiving or
fetching charging data from the NE, and placing the resulting CDRs in files
in the inbuffer.
2. One process that reads files from the inbuffer, processes it, and writes the
resulting file to the outbuffer. This component is called a processing
component. Each processing component contains one or several
processing flows, which implement the CDR processing feature. That is,
taking CDRs from the files in the inbuffer, and writing CDRs into files in the
outbuffer.
3. Finally, one process that reads the processed file from the outbuffer, and
transmits the file to the post processing system. This component is called
a distribution component. Each distribution component will contain one or
several distributors, which implement the post processing system data
distribution feature. That is, sending data to the post processing system
from the outbuffer.
3.1.2.2. Unbuffered protocols

The incoming files received, or fetched over unbuffered, or hot protocols like
BGw-RPC is not handled in the same way as the buffered protocols. In the
earlier releases of the Mediator the incoming unbuffered files were processed,
and distributed to the correct post processing system before an
acknowledgement was sent back to the NE. A similar solution has been
incorporated in the distributed architecture of the R9.1 release of the Mediator
with a well-defined data-flow through the component chains.
By allowing the hot CDRs to be sent in the messages between the different
processes, these CDRs never need to be written to disk, nor read from disk.
This means an unbuffered solution similar to the one in earlier releases is
reached. Besides hot CDRs are given priority for both processing, and
distribution. That is, hot CDRs are allowed to jump ahead of the queue, in front
of possible, big, cold files.
In the R9.1 release of the Mediator it is possible to allocate a certain number of

processing threads for hot processing. This means there is no waiting for big,
cold files to be processed, but the hot CDRs can be processed in separate
“hot threads”.
Page 15
3.1.2.3. Configuring processes and threads
The tight connection between the (internal) collection components and the
processing components means that the same number of processes are
allocated for these two components. The number of processes for the
processing component are configured through separate parameter in each NE
group. For the distribution components the number of processes are
configured through a separate parameter in each post processing system
group.
It is important to remember that NEs and post processing systems will never
be duplicated. For example, in an NE group including two NEs, there will never
be possible to assign more than two processes. If more processes are
assigned, these processes will never be possible to take advantage from.
The number of threads for a collection component is configured through the

max concurrency parameter. Max concurrency decides the number of threads
that are simultaneously allowed to use for collection from each NE. The
number of threads used for the processing component are configurable
through a separate parameter in each NE group. For the distribution
component the number of threads are configured for each post processing
system through the max concurrency parameter in the same way as for the
NEs.
The parameters processes, threads, and max concurrency mentioned in the

chapter above are all, directly or indirectly configurable in the GUI through
different parameters.
3.1.3. Supporting processes
All the component processes described above need to be created, co-

ordinated, and controlled. To support this there is a separate process called
job manager. This process acts as the single point of contact for the GUI, and
drives the other components to push the files through the component-chain,
from collection to distribution.
For creating, monitoring, and removing all the processes within the Mediator
system, there is a separate process called process manager. The process
manager has only one client, the job manager, and uses this process to
control all the other component processes.
There is also a separate process for writing log files, and log database tables
from the other component processes. This process is called log manager. It is
no longer practical to have all the other processes writing to the same log file,
or table. The log manager provides the needed serialization of the log writing
functions. It also isolates the other components from problems with the
database system, and loads introduced by log queries from the GUI.
Page 16
3.2. Mediator Interfaces

The Mediator provides interfaces for communication to other systems as well
as for permitting control and monitoring of its functions.
In the following five chapters descriptions of the interfaces as indicated in the

figure below will be described.
Alarm GUI
3
4
Mediator
1 2
5 Post
processing
NEs systems
Database
Figure 3, Overview of the Mediator interfaces.
3.2.1. Collection of charging information
This chapter relates to interface number 1 in Figure 3.
The Mediator collects CDRs from different types of network elements, for
example switches, voice-mail systems, datacom nodes, IP routers, and
intelligent peripherals. Mediator can collect CDRs using either Ericsson
proprietary protocols, or standard protocols.
The communication can either be initiated from the network elements, or from
the Mediator. In the first case, the Mediator acts as a responder, and in the
second, the Mediator is an initiator. For all the file-based protocols in the
Mediator where initiated collection (polling) is supported (FTP, FTAM, SFI,
Disk), it is possible to collect all files available from the NE during one polling
interval, and not only one by one.
Page 17
The following protocols are used in the interface between the network
elements like MSC switches, S-GSN, G-GSN, APG 40 and Charging Control
Node (CCN) for near real time billing, and the Mediator for collection of
charging related information.
3.2.1.1. File based collection
The following protocols are supported for file-based collection of CDRs from
NEs:
• MTP-SFO (Message Transfer Protocol – Session File Output) over X.25.

Ericsson proprietary file based protocol, Mediator acts as responder.
• MTP-SFI (MessageTransfer Protocol – Session File Input) over X.25.

Ericsson proprietary file based protocol, Mediator acts as initiator.
• FTP (File Transfer Protocol) over TCP/IP.

Protocol in the TCP/IP family used to transport files between machines
running TCP/IP. Mediator acts either as initiator or responder.
• CCI-FTP-R over TCP/IP.

File-based collection support from APG 40. Common Charging Interface
FTP - Responder (CCI-FTP-R) over TCP/IP.
• BGw-RPC initiated FTP over TCP/IP.

Collection from Ericsson GSN nodes. Mediator acts as responder for
BGw-RPC, and initiator for FTP.
• TFTP (Trivial File Transfer Protocol) over UDP/IP.

Mediator acts as initiator.
• FTAM (File Transfer, Access and Management) over TCP/IP or X.25.

FTAM is an OSI standard protocol for file transfer (and access and
management) across an OSI network. Mediator acts either as initiator or
responder.
• Disk, either local, or mounted with NFS.
• Database NE.
3.2.1.2. Non file based collection
When it comes to UMTS systems it is important to provide block or even entry

and event based data management in addition to the file based data transfer.
To provide this, the Mediator is equipped with new communication protocols
and procedures.
Page 18
Block-based protocols used for Hot Billing collection
• MTP-DFO with mirroring (Message Transfer Protocol – Direct File Output)

over X.25.
Ericsson proprietary block-based protocol. Disk Mirroring, and immediate
transfer of Data from the IOG over MTP. Mediator acts as responder.
• BGw-RPC (Remote Procedure Call) over TCP/IP.

The block-based protocol BGw-RPC constitutes a hot billing interface for
non-IOG systems. Mediator acts as an RPC server (responder).
Communication daemon
The communication daemon is an external process itself, running
independently of the Mediator. It has two ways of communicating:
• With an NE in IP networks.
• With the Mediator.
The solution for the daemon is aimed to become generic, so that it would be
reusable for various kinds of protocols, which are not a part of the Mediator
core structure. In the Mediator the Radius, and the SNMP implementations are
based on the communication daemon, but are run in separate processes.
The daemon provides the abstract interface of requesting, and receiving the
data from the NE. It also implements the unified way of the data transfer to the
Mediator NE nodes.
Block, event, and entry based protocols
• CCI-RPC-1, and CCI-RPC-2 over TCP/IP.

The block-based protocols CCI-RPC-1, and CCI-RPC-2 are used for
supporting new interfaces in UMTS networks, for example interface to the
APG 40 node. Mediator acts as initiator.
In earlier releases of the Mediator CCI-RPC-1, and CCI-RPC-2 were

implemented as a “Hot” protocol (the protocol was un-buffered, that is not
written to disk at processing). In the R9.1 release of the Mediator it is
configurable in the GUI if CCI-RPC-1, and CCI-RPC-2, should be buffered,
or un-buffered.
For detailed information about the CCI-RPC interface, and the two different
versions, see Ref 2.
• Radius data collector.

Radius is used for datacom and IP charging. The Radius implementation in
the Mediator is based on the communication daemon. An external Radius
daemon (data collector) handles the collection of accounting and
authentication messages from IP routers and datacom nodes, which can
Page 19
be configured as Radius clients (for example Tigris). In these cases

Mediator acts as a Radius server for accounting messages, and Radius
proxy for authentication messages.
Auth. Server
Auth.
messages DB
3 2
4 Lookup
1
Auth. (MSISDN –
Client IP no)
Radius Daemon
4
(Acc Server, Mediator Acc.
Auth. Proxy) Server
5…
Acc. TCP/IP
Client
Acc. files
6…
6…
Acc.
messages Disk
Figure 4, The Mediator Radius Daemon
In Figure 4 an overview of the Mediator Radius daemon is found. The

collection of Radius accounting and authentication messages are
described below:
1. An authentication message is sent from the Radius authentication

client towards the authentication server.
2. Acting authentication proxy, the Mediator collects the authentication

message and forwards it to the authentication server.
3. Acting authentication proxy, the Mediator receives the authentication

server response from the authentication server.
4. The response is forwarded to the authentication client, and in the

same time stored in a Mediator database.
5. When the authentication is finished, the user can start to use the
application. This means that the START Radius accounting
messages is sent from the accounting client.
6. The Mediator is collecting the accounting messages (Mediator

supports START, INTERIM, and STOP messages) from the
accounting client acting Radius server. Acknowledgements are
sent to the accounting client for all the messages and the
messages are stored on disk.
Page 20
How many messages that should be stored in a file before available to the
Mediator is configurable in the GUI.
Many applications that acts as Radius clients provide subscriber identity

information along with the Radius accounting data. For those applications
where the accounting data does not include any subscriber authentication
information (IMSI, MSISDN), this information has to be extracted from the
authentication messages. Using the look-up feature in the Mediator the
mapping between IP-number and MSISDN can be done. Timestamps will
be used together with the IMSI or MSISDN for consolidation of CDRs.
The Radius daemon is up and receiving messages also when the Mediator
is not running. Mediator collects the data from the external collector.
• GTP’ (modified GPRS Tunnelling Protocol) over TCP/IP and UDP/IP.

GTP’ is an event and entry based protocol. GTP’ will be supported in the
Mediator in order to offer a standardised third party support in general, but
support for collection of CDRs from other vendors GPRS switches (GSN
nodes), in particular. Mediator act as initiator normally, but will act as
responder if the GSN node is temporarily down.
• CCN Diameter over TCP/IP.

Diameter is an event and entry based protocol. Mediator supports collection
of CDRs from the CCN over a subset of the Diameter protocol. Mediator
acts as responder.
• Cisco NetFlow.
NetFlow is a proprietary interface built by Cisco, but is also used by other
vendors’ IP routers.
The Mediator provides an interface for collection of NetFlow datagrams
(statistics). An external collector is used. The collector stores the data from
the various routers in files. As soon as enough data has been collected in a
file, the NetFlow collector stores a copy of the file in a temporary directory.
The Mediator can then collect the files from the temporary directory using
BGw-RPC, or CCI-RPC initiated FTP. After collection the temporary file is
deleted.
• MIB-II over SNMP.

Mediator supports collection of charging information from, for example, IP
routers over SNMP. The Mediator also supports the MIB II model of the data
management, which assumes an existence of the MIB specification with a
listed ASN.1 data structures, and MIB objects description. The solution is
based on the communication daemon. Mediator acts as initiator.
Page 21
3.2.1.3. Support for collection in large networks

The amount of charging data that the mediation systems have to collect in the
networks is increasing rapidly. This is depending on:
• An increasing number of subscribers in the network.
• An increasing number of nodes that the mediation systems have to collect

charging data from.
• An increasing number of generated CDRs per subscriber and day, than in

the traditional circuit switched networks.
Based on this fact the Mediator support for large networks is improved in the
R9.1 release to fulfill the operator’s requirements and needs.
One of the limiting factors for supporting large networks is the number of file
descriptors available for one specific process, mainly in some of the third party
libraries used in the Mediator. These third party libraries are, for example, used
in the Mediator collection process. In the Mediator where it is possible to split
the configuration over multiple processes, the limiting factor for large networks
is minimized.
The Multi NE feature existing already in earlier releases of the Mediator is

improved for the R9.1 release. There is no limitation to how many sub NEs a
Multi NE can have. From the GUI it is possible to configure the number of
threads for the Multi NE node, and the desired concurrency of the sub NEs.
The concurrency means that several sub NEs within the Multi NE can collect
charging data in parallel.
It is also possible to update which sub NEs should be included in the Multi NE
through a Multi NE configuration file. This file can be updated either at
configured time intervals, or manually at user intervention through pressing the
update button in the GUI. If the Multi NE node is active when it is time to update
the node, it needs to be stopped. Both the stopping and re-start of the node is
an automatic process.
The new multi process architecture developed for the Mediator, in combination
with the improved Multi NE feature for the configuration view results in good
support for large network.
3.2.1.4. Protocols supporting merging at collection
The Mediator should work with larger files, rather than small files to achieve an
optimal performance. As the event, and entry-based protocols, which collect
charging data in as small entities as single CDRs instead for files are
introduced, this implies a limitation for the processing capacity. To improve the
internal processing capacity the event, and entry based protocols described
below support merging of the incoming charging data into larger entities.
How many entries that will be concatenated in each file is configurable based
on the number of entries, or CDRs.
Page 22
The protocols, which support merging within the Mediator, are the following:
• GTP’
• CCN Diameter
The Mediator also indirectly supports merging for protocols based on the
communication daemon, that is:
• Radius (accounting)
• SNMP over MIB II
The NetFlow FlowCollector can be seen as a communication daemon

developed by Cisco. The FlowCollector receives datagrams, and stores them
in files on disk. The Mediator can collect these files over FTP. The NetFlow
solution in the Mediator also supports merging of incoming data.
3.2.2. Distribution of charging information
This is the interface for distribution of charging related information to post

processing systems, for example billing system, fraud analysis system and so
on.
3.2.2.1. File based distribution
The Mediator supports the following file based protocols for distribution of
CDRs to post processing systems:
• MTP-SFO over X.25.

• MTP-SFI over X.25.

Mediator acts as responder.
• FTP over TCP/IP.

Mediator acts either as initiator or responder.
• FTAM over TCP/IP and X.25.

Mediator acts either as initiator or responder.
• Disk, either local, or mounted with NFS.
• Database post processing system.

Page 23
3.2.2.2. Non file based distribution
Communication protocols and procedures to support entry and event based

data distribution in addition to the file-based distribution.
Block-based protocols used for Hot Billing distribution support
• BGw-RPC over TCP/IP.

Block-based protocol, Mediator acts as initiator.
Block, event, and entry based protocols
• Radius distributor over UDP/IP.

Radius is an event and entry based protocol. Mediator acts as a Radius
accounting client. This means that that Mediator can distribute charging
data over Radius, to post processing systems, which can be configured as
Radius servers.
• CCI-RPC-1, and CCI-RPC-2 over TCP/IP.

The block-based protocols CCI-RPC-1, and CCI-RPC-2 are mainly used
for supporting new interfaces in UMTS networks, for example, the APG 40
node, but can also be used for distributing charging information to post
processing systems.
• CCN Diameter over TCP/IP.

Diameter is an event and entry based protocol. Mediator is supporting
distribution of CDRs to the CCN over a subset of the Diameter protocol.
The Diameter subset is running on top of TCP.
3.2.2.3. Protocols supporting splitting, and merging at distribution

Support for splitting, and merging when distributing offers the user a more
flexible distribution of charging data from the Mediator. The splitting and
merging features work over file boundaries. This means that there is no longer
an automatic distribution upon end of file, but this is configurable.
With the R9.1 release of the Mediator files can be distributed based on the
following criteria:
• Size of the file, that is, number of encoded bytes.
• Number of entries, or CDRs, in the file.
• Time basis.
Page 24
The time basis alternative means that at configurable time intervals all data
that have been processed will be distributed. Both the splitting, and merging
features are available in the Mediator for the protocols described below:
• FTP
• FTAM
• Disk
• CCN Diameter
• Radius (accounting)
3.2.3. Distribution of alarm information
The interface for distribution of alarm information to surveillance systems, for

example network management systems.
Alarms can be distributed to external systems using any of the distribution

protocols specified above (see chapter 3.2.2.1) or of the following protocols:
• Alarm IRP (Integration Reference Point)

Mediator is supporting distribution and control of alarms over Alarm IRP.
For this feature the CORBA implementation set is used.
This means that configuration management of Mediator alarms are

possible by using the CORBA interface, and additionally, notifications are
possible from Mediator to clients’ CORBA interface.
• Appending alarms to a file, either on local disk or on a disk mounted with

NFS using for example TXF. The TXF format can used to distribute alarms
over any of the protocols supported by the BGw.
• Appending alarms to a file through FTP over TCP/IP.
• SNMP (Simple Network Management Protocol) over TCP/IP

SNMP is a request – reply protocol operating between a management
station and agent.
Page 25
3.2.4. Mediator Graphical User Interface
The Mediator Graphical User Interface (GUI) provides a powerful configuration

tool that makes it possible for the user to build and modify configurations for
the Mediator efficiently. The GUI is built in Java, which means that it is platform
independent, and can easily be used in a web browser or executed as an
application.
This makes it simple to re-configure the Mediator to fulfil new requirements.

The configuring of the Mediator is done dynamically in run-time and does not
require any re-compilations of the software. However, note that the
configuration has to be stopped when new alarm nodes, log nodes,
formatters, filters, assemble nodes, NEs, post processing systems, and
consolidation nodes are loaded into the configuration.
In the GUI the different nodes added in the configuration can be monitored.
Depending on the status of the nodes in a configuration, they have different
colours, which makes it easy to get an overview of the network. The colour
settings are configurable, and can for example be:
• Black for ‘Waiting’
• Green for ‘Working’
• Yellow for ‘Stopped’
• Orange for ‘Down’
The fourth status, ‘down’, is added to have a better surveillance of the

distributed architecture of the Mediator. If a collection component (see chapter
3.1.2) by any reason should go down, the NEs in the GUI depending on that
collection component will change status to ‘down’.
One of the advantages with the multi-processes architecture introduced in

Mediator version 9.1 is that in the normal systems there will only be one
configuration needed since the system will not need to be split over several
Mediator servers. This means that there will be a better overview of the
Mediator-configurations in the GUI.
Three different views can be accessed in the GUI, the configuration view, the
supervision view and the server view. Which views and windows that can be
accessed depend on the authority of the logged in user.
Page 26
3.2.4.1. The Server view
The server view is the first view the user comes to when starting the GUI. In
this view the user logs in on one, or several Mediator servers. All the servers
connected to the GUI are monitored in this view. It is possible to see whether
the servers are active or not. It is also in this view that the servers settings are
configured.
3.2.4.2. The Configuration view
The configuration of the data-flow through the Mediator is done in the

configuration view. The user places nodes in the configuration area and
connects the nodes with links to define the data flow. To define the setting for
the individual nodes, the user double-clicks on a node and then specify the
settings. To make the configuration of the nodes in the processing flow even
more user-friendly, syntax highlighting is introduced in the text-editor areas of
the nodes. Together with the search and replace functions this offers a
flexible, and graspable way of configuring the BGw processing flows.
The optional application SDK introduces the possibility for to add new
decoders, encoders, and communication protocols (see chapter 4.1.1 for
more information). This application makes the Mediator even more flexible and
valuable.
Version handling
Mediator has version handling of configurations. Each time a configuration is
stored the user can add information about changes in the configuration, the
date and time are stored automatically. The maximum number of the same
configuration is 20. It is possible to override the version handling.
When the user opens a configuration in the Mediator, it is possible to choose

which version that shall be opened.
3.2.4.3. The Supervision view
The Supervision view in the Mediator GUI makes it possible for the user to
monitor the data-flow through the Mediator, inspect logs, handle alarms, or
start and stop a specific node in the configuration or the whole configuration.
3.2.5. Oracle Database Interface
Page 27
The Oracle database interface is a mandatory part of the R9.1 release of the
Mediator. The Oracle database can either be placed on the same hardware
server as the Mediator or be placed on a separate, external one. The Interface
to the database allows the Mediator to perform flexible and powerful
processing operations on the charging related data.
The Oracle database is controlled by the log manager, which makes it

possible to store all the logs generated in the Mediator in the database. In the
SQL database new and advanced tools for reading, searching and report
generation are possible to use. This means that a greater flexibility will be
achieved for handling the Mediator logs.
Another possible use of the Oracle database is the look-up tables. Generally,
database accesses are slower compared to corresponding actions in RAM,
but the database has the capacity to be used in order to carry out more
advanced features requiring complex operations on the CDRs. One example
is look-up tables including large amounts of data.
One practical example where a database look-up table can be used

(depending on the amount of data) is access through filtering nodes. The look-
up table can for example contain information about the pre-paid subscriber-
base in a network (MSISDN numbers for the pre-paid subscribers). The
database look-up table can in this way be used in the Mediator to filter out the
pre-paid CDRs when distributing the CDRs to pre-paid systems, or to different
post processing systems. How often the look-up table should be updated is
configurable.
In the Mediator it is possible to both send data to the database (database post
processing system), but also collect data from a database NE. The database
NE makes it possible to re-insert the CDRs distributed by a database post
processing system, into the processing flow for re-processing.
3.2.5.1. Back up
The Oracle database offers several back up alternatives. Since the database
has to be up and running all the time, downtime for back up is not allowed.
This means that the back up has to be performed while the database is up and
running. Based on these criteria there is only one alternative back up method
available, the so-called logical inconsistent back up. This back up alternative
copy redo logs to disk. The redo logs makes it possible to recover the
database to any specified time.
3.2.5.2. Recovery
A recovery is needed if the database for any reason has crashed, or been
cleared. The recovery is made based on the redo logs stored on disk from the
back up function. When making a recovery of the database, it is possible to
choose if a complete, or an in-complete recovery should be performed.
The complete recovery means that the latest recovery, using all the redo logs,
will be used. The alternative is an in-complete recovery using just some of the
redo logs.
Page 28
Page 29
3.2.6. Prepaid solutions and minimum delay
In UMTS call-charging data must be delivered within minutes after call

completion.
The Mediator can be dimensioned to process the collected information on real

time basis. There are NEs that can be configured to produce the charging
information on near real time basis, which is within seconds after call
completion. The Mediator provides hot billing support, which allows operators
to offer, for example, rental phone services. The hot billing support uses
special protocols for collection as well as distribution of charging information,
that is, by means of the Ericsson proprietary protocol DFO with mirroring, or
open industry standard block-based protocols BGw-RPC.
The Mediator also is a pre-packaged node in pre-paid solutions for GSM,

GPRS and WAP. A verified interface to the Pre-Paid System (PPS) node is
implemented.
The SDP nodes in a PPS provide the Mediator with the pre-paid subscriber-
base (MSISDN numbers). This data is used for generating a look-up table in
the Mediator. The look-up table is used for filtering a copy of the pre-paid
CDRs to the SDP in the PPS, and post-paid CDRs through the normal
processing flow.
The SDP sends back a rated CDR to the Mediator. This CDR can be sent to a
post processing system, or statistic system of any kind.
The Mediator is also a part of future charging system for near real time
charging solution within Ericsson. This is based on the Charging Control Node
(CCN). The Mediator is handling the off-line charging flow, but also works as a
back up node for the CCN. The protocol used over the interface is a subset of
Diameter, or FTP. In this new real time solution, the SDP in the old PPS is
replaced by the CCN node.
For nodes that distribute their data over IP, message based protocols like
BGw-RPC, CCI-RPC-1, CCI-RPC-2, and Radius will be used to achieve a
minimum delay. The protocols just mentioned are supported in the Mediator
for both collection and distribution of charging data.
3.3. Supported nodes

Mediator supports all new Ericsson nodes and services from day one. This
means that all GSM, GPRS, and UMTS nodes and services included in the
network main project will be supported, but also that other nodes and services
are supported and verified as well. For example:
• AXD
AXD is a high performance, multi service switch. AXD can carry multiple
services and large amounts of data. Services supported include ATM,
IP/MPLS, Frame relay, Circuit emulation, and Voice services.
Page 30
• AXC
The AXC is a cost effective, high capacity IP access point designed to give
carriers and service providers the ability to offer end-to-end “managed
network solutions” to their enterprise customers. The Mediator supports
AXC Tigris and AXC 706.
• MPC (Mobile Positioning Centre)

MPC is a part of Ericsson Mobile Positioning System (MPS) which is used
for positioning of emergency calls, making phone surfing localised
(commercials, restaurants in the area, and so on), transport management
and in many other areas. MPC is a gateway between a mobile network and
various positioning applications. The application uses the output from the
positioning centre to present the geographical position of the phone in
numerical or graphical ways.
• AXI
The AXI offers a fault-tolerant router architecture and a comprehensive,
broadly deployed suite of internet routing software.
The Mediator provides support to the Ericsson routers AXI 510, AXI 520,
and AXI 540.
• WAP gateways
Mediator supports the Ericsson WAP solution.
• MSC (Mobile Switching Centre)

The MSC supports GSM, TDMA, and CDMA networks. As well as
switching traffic between different cells in a network, the MSC provides the
gateway from the wireless environment to PSTN, ISDN and Internet
networks at the local, transit or international gateway level.
• S-GSN (Serving GPRS Support Node)

GPRS node that connects the Mobile Stations (MS) to the network.
Mediator supports both 2G and 3G SGSN nodes.
• G-GSN (Gateway GPRS Support Node)

GPRS node with connection to the internet. Mediator supports both 2G and
3G GGSN nodes.
• Certified
SMS-C, messaging centres
Voicemail services and so on. This category consists of a vast
number of nodes. Verification is continuously ongoing.
• SCP (Service Control Point)

The SCP executes IN services.
• CCN (Charging Control Node)

Node in the UMTS network handling the on-line charging (near real time
charging services).
• APG 40
Page 31
The APG 40 integrates a standard computer system with telecom

environments. It runs on several hardware configurations, and provides a
framework for application developers. It can handle large amounts of
CDRs.
The Mediator is backward compatible, and supports all the nodes supported in
earlier versions of the Mediator (for example Mediator R8 and R9.0).
3.3.1. Multi vendor support

Mediator supports multi vendor product, that is, not only supporting Ericsson
nodes and services, but also supporting other vendors products. For example,
third party nodes from Siemens, Alcatel, Nokia, Cisco and Nortel have been
verified.
Mediator also supports the GTP’ protocol (for collection) to give a standardised
support of third party GPRS equipment.
The SDK can be used to offer a complete multi vendor support. By using the
SDK, third party vendors can develop interfaces from their NEs, to the
Mediator themselves. See chapter 4.1.1, for more information. The new multi
processes architecture of the Mediator means that new third party interfaces
can be placed in separate processes. This means that the security for the
Mediator will increase, since the Mediator will be up and running even if one of
the third party processes goes down.
Nodes and services, which are not supported in the Mediator today, can also
be offered to the operators by special adaptations in the configuration as
professional services.
3.4. Supported Services
The Mediator also supports collection of charging information generated by, for
example, the following services:
MVPN (Mobile Virtual Private Network)

MVPN can be implemented inside public networks to link company sites
irrespective of their location within a given country. Business subscribers can
use the MVPN to establish their own integrated wireline and mobile extension
numbering plan.
GSM Pro (GSM Professional)

GSM Pro adds the features and functions of traditional Private Mobile Radio
(PMR) to the mobile communication system – GSM.
VoIP (Voice over IP)

Enables the subscribers to send voice information in digital form in discrete
packets over the IP network, rather than in the traditional circuit-committed
protocols of the public switched telephone network.
PPS (Ericsson Pre-paid System)
Page 32
The Mediator is a mandatory node in the Ericsson PPS solution, which

enables near real time billing (pre-paid support) of, for example, SMS and
GPRS. The Mediator has a standardised interface to the SDP node in the
PPS. Over this interface data about the SDP pre-paid subscriber-base is
received, and pre-paid CDRs are filtered out (distributed) to the SDP.
MPS (Mobile Positioning System)

MPS is a feature that makes it possible to position a mobile station together
with location based services.
GSM on the Net (GoN)

GSM on the Net is an IP telephony solution combining the advantages of
communication over the Intranet with GSM.
Page 33
4. BGw R9.1 features
4.1. Collection and distribution
Two of the Mediator’s basic functions is to collect and distribute the charging
related information. The amount of charging data produced in the network is
enormous, and it is a fact that the amount of data generated in the networks
will increase in the future. Real growth in UMTS will come from data transfer
over mobile and IP networks. This assumption is based on the fact that the
number of subscribers in the tele and data -communication networks will
continue to grow in the R9 time frame, as well as the number of minutes per
subscriber (telephone call or PDP context). This will have impacts on the
Mediator, both in terms of the number of network elements in a network, and
the increased CDR volumes.
There are extreme occasions where a single telecommunication switch, that

is, an NE generates a huge amount of charging data during a 24-hour period.
As the primary task for the NE is to handle the traffic flow, it would be very
difficult to keep that amount of information in the NE for a long time. Most NEs
are not dimensioned for long time storage of the charging information. To cope
with this, the NEs normally need to forward the CDRs on a regular basis. This
means that the Mediator must have safe storage of CDRs, since this is the
first node in the network that can store CDRs/files in a safe way for a long
time.
What is even more important, from a business perspective, is to ensure a

quick and safe revenue flow. The quicker the CDRs arrive to the post
processing systems, the more efficient revenue flow would be achieved for the
operator.
4.1.1. SDK
The SDK application introduces the possibility to develop new interfaces, both
on collection and distribution side in the Mediator. This application can be used
by, for example, operators or third party vendors, who wants to add a protocol
or format in the Mediator configuration on their own.
The SDK can be used to add new interfaces for collection and distribution.
Depending on what the customer requires, it is possible to select the following
SDK licenses:
• SDK Basic license
• SDK Dynamic NE package
• SDK Dynamic post processing system package
Page 34
With the SDK, it is possible to:
• create new decoders and encoders in order for the Mediator to be able to
handle new formats.
• add new communication protocols for collection.
• add new communication protocols for distribution.
4.2. Security aspects
4.2.1. Network Security
The Mediator is assumed to be part of a trusted domain, for example, an IP

(sub) network that is protected from the outside world through a firewall.
Configuration and access to the trusted domain is the responsibility of the
operator.
The Mediator runs on a standard Sun hardware using the Solaris OS, or a
standard HP hardware using HP-UX. Solaris, and HP-UX offers a wide-range
of standard security mechanisms that can be configured by the system
administrator. The security mechanisms provided are:
• Access Control (allows only trusted hosts to interface, both as source and
destination).
• User Authentication (authenticate users logging in with user name and

password).
• User authorization (Mediator uses hierarchical permission scheme for

Mediator users)
• Application Security (allow only the required services, like Telnet, FTP,
TCP/IP and so on, to be used from trusted hosts).
• Security Logging (allows logging of attempts to get around security, like

invalid login attempts, requests for unsupported services and so on).
• IP-sec will introduce security in the data transfer of IP networks. IP-sec

consists of encryption and authorisation. The implementation of the IP-sec
security package will make any attempts of viewing or manipulating the
packages transferred over the network between network elements
impossible for the unauthorised parts (as long as the keys used for the
encryption and decrypting are kept secret).
Page 35
4.2.2. Client Security
Mediator clients, that is, the GUIs, are based on Java. In order to grant a
Mediator client access towards Mediator server, the Mediator OS machine
needs to be configured to treat the Mediator client as a trusted client (for
example, to allow the client to access to Mediator). Apart from the Access
Control, the Mediator requires User Authentication (User ID and password)
from GUI clients.
Mediator uses hierarchical permission scheme for Mediator users. The

following three user categories and their authorities are available:
Supervisor
Supervisors have the authority to monitor the Mediator server and to change
their personal password.
Administrator
Administrators have the authority to monitor the Mediator server, shutdown
and start up individual nodes, and the server. They can add and delete
supervisors and administrators and change authority and password for these.
Configuration manager
Configuration managers have access to all the features in the Mediator. They
have the authority to monitor the Mediator server, shutdown and start up
individual nodes and the server. They can add and delete users and change
authority and password for any existing user. The configuration managers are
also allowed to change active configurations.
4.2.3. Network Element Security
The security implemented in the interface between the Mediator and the NE is
dependent on the NE and its protocol. For NEs that require user
authentication, the Mediator provides the required information.
4.2.4. Multiple destination streams
The operator’s business support network is built upon different systems, the
so-called post processing systems, each of them facilitating different needs.
The Mediator can distribute tailor made information that suits each individual
business support system.
Other examples of destinations besides the business support systems are

other mediation devices and the rating engines.
Page 36
4.2.5. CDR Lost Check
The Mediator can check so that no CDRs are lost. The CDR lost check uses
one field in all CDRs, per CDR type (for example, ChargeableDuration) and
summarises it for all incoming and all outgoing CDRs. A periodic check will
see if the difference between the two sums are abnormal.
4.2.6. Alternative destinations
The Mediator supports alternative routing of charging information. It is possible

to configure the Mediator to choose an alternative destination to deliver the
charging information. The Mediator will raise an alarm to notify that the primary
post processing system was not reachable.
For example, this can be useful in case a post processing system fails to
respond on a request for communication from the Mediator.
4.2.7. Buffering of CDRs
If it is impossible to distribute CDRs to a post processing system, the Mediator

buffers the CDRs on mirrored disks and sends them automatically as soon as
it is possible to distribute to the post processing system again. This means
that all data buffered on the Mediator, all configurations, all logs and all alarms
are kept in safe storage on the mirrored disks.
4.2.8. Archiving
The archiving function makes it possible to do long term storage in the

Mediator, on optical disk or tape. This can, for example, be used to make a
security back up of billing 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.
4.2.9. TT-file transfer validation
The Mediator provides a mechanism called file transfer verification, which can
be used to validate TT-files transferred from Ericsson IOG equipment.
Basically, this function allows the operator to validate that the TT-files sent
from an NE follow a consecutive order. The validation is based on the
sequence numbers, which is reflected in the TT-file name. It is useful to
operators for surveillance purposes. The Mediator can be configured to raise
an alarm in case the following abnormal event occurs
• Inconsistent transfer flag.

That is, if a TT-file marked as non-transferred is followed by a TT-file
marked as transferred.
Page 37
4.2.10. Alternative media
Most operators store the charging data from the NEs, into optical disk media
on a routine basis. It is used as a first level of back up. For example, in case
an NE site becomes isolated due to a communication link failure that lasts for
a long duration, the normal flow towards the Mediator would be broken. By
using the charging data that is backed up on optical disk, the operator is able
to process the charging data through the Mediator. Thus, the Mediator
supports the operator to maintain the overall revenue flow, or by any reason
process old charging data.
4.2.11. Recovery procedures
The Mediator provides convenient recovery procedures for managing

retransmissions of TT-files from Ericsson IOG equipment. The recovery
procedures are available when the communication protocol between the IOG
and the Mediator is MTP/SFO. By supporting automatic as well as manually
assisted recovery procedures, the Mediator supports operators in minimising
management efforts in case of unexpected failures. TT-files, which are subject
for recovery, are those files residing in the IOG and have:
a) the transfer flag set to FAILED
b) the transfer flag set to YES, but not present in the Mediator
c) inconsistent size
Manual recovery is also supported when FTP is used for collection of charging
data. The Mediator uses FTP initiator for fetching the files. A list over all the
files that has been stored on the Mediator can be monitored in the GUI. In this
list it is possible to choose which files should be collected again.
4.2.12. High Availability solutions
Availability is in this document defined as the total time the Mediator is

receiving, processing, and distributing charging data. Planned, as well as
unplanned downtime is regarded as equally undesired.
There are four different levels of availability solutions:
1. Single machine system
2. Cluster solution
3. Disaster cluster solution
4. Redundant server solution
All four of them are described in the coming chapters.
Page 38
The first level of availability solution consists of a single machine system. This,
the most basic availability solution, handles on-line back up, but does not
handle a system failure. The single system contains shared disks, but then
there are no other similarities to the cluster solutions. Like all of the high
availability solutions the single system uses the Veritas File System (VXFS)
instead of the standard file system (UNIX file system), Veritas Volume
Manager (VXVM) to handle volumes, and Veritas Net Back up (NBU) to handle
on-line back ups. All these products are available on both HP and Sun.
4.2.12.1. Cluster solutions
Running the Mediator in a cluster is invisible to the Mediator application. From

the Mediator point of view the only difference compared to a single system, is
that the application is not always started on the same machine. Since the
cluster is based on shared disks, it will seem like the disks are moved from
the primary system to the secondary.
It is possible to choose between two different levels of cluster solution to get

the degree of high availability that is required. The cluster solutions are based
on VXFS, VXVM, and Veritas Cluster Server (VCS).
With all the new external processes introduced in the R9.1 release of the
Mediator,
cluster. there of
Instead will not bethe
having ansecond
asymmetric cluster
hardware anymore,
server in coldbut a symmetric
stand-by,
external processes like Oracle, Radius daemon, and SNMP over MIB II will be
recommended to be placed on the stand-by server.
When the server, where the primary Mediator is placed, goes down the stand-
by server with the rest of the external processes will take over automatically in
a couple of seconds. In the same way, if the stand-by server with the external
processes goes down, these will be started up on the primary Mediator server.
Mediator data is communicated to the stand-by server through the Veritas
Cluster software.
Page 39
Single site cluster

This level of availability solution adds fail over possibilities to the system in
comparison to the single machine solution.
Network Elements
LAN
Executive
Mediator _1
Mediator _2
Router
Mediator _3
Mediator _SB
Stand-by
Figure 5, Mediator Cluster
A Cluster consists of an X+Y solution, where:
• X = Number of active hardware servers in the symmetric cluster.
• Y = Number of stand-by hardware servers in the symmetric cluster.
The standard solution consists of a 1+1 solution, that is, one active and one
stand-by server. Larger clusters can be offered, and are customized on a
case-by-case basis. However, this was more an issue for older versions of
the Mediator where the solution for large networks was using several Mediator
processes and hardware servers. In the new multi processes architecture
there is no use for several Mediator processes in the same way.
In Figure 5 an example of a 3+1 cluster is described. The servers in the figure

can be configured so that three are running in load-sharing mode, and one
server is on stand-by. Within a cluster of four servers, load-sharing can be
used between three of the servers. This can be useful when a lot of
processing is needed. For example, one server can handle collection, the
second processing, and the third can distribute charging data to the different
post processing systems. If one of the active servers goes down, the stand-by
server can take over.
Page 40
Disaster recovery cluster
Disaster recovery clusters are performed using VCS to build two single site
clusters at different physical locations.
The solution consists of two single site clusters described above. The two
clusters are configured to replicate data on-line from the primary site (the
cluster currently active), to the secondary site (the stand-by disaster site). The
replication is handled by Veritas Volume Replicator (VVR). This allows the
disaster site to take over the operation at any time.
In case the primary site goes down for any reason, a site switch must be
performed. The switch to the secondary site normally involves a manual
intervention, which means that a 24 hours monitoring of the system is required
to meet the availability requirement mentioned above. Once a site switch has
occurred, the primary site must be manually prepared to take back control
again.
crash. The level of effort needed depends on the reason for the primary site
All Mediator features can be used in a both the cluster solutions.
4.2.12.2. Redundant servers
Network Elements – Primary: Mediator _1, Secondary: Mediator _2
LAN
Mediator_1
Router
Mediator_2
Network Elements – Primary: Mediator _2, Secondary: Mediator _1
Figure 6, Mediator, redundant server solution.
It is also possible to combine two Mediator servers to attain a high availability

solution in another way. For example in Figure 6 above, there are ten NEs, and
Page 41
two Mediators. The five upper NEs have Mediator_1 as their primary
destination for CDRs (Mediator_2 as secondary destination), and the five lower
NEs have Mediator_2 as their primary destination (Mediator_1 as secondary
destination). If an NE fails to send its CDRs to its primary Mediator, then it
sends them to the secondary. This means that the CDRs will reach the billing
system even if one Mediator is down. It would also be possible to configure the
Mediator to distribute CDRs to a secondary billing system if the ordinary billing
system is down.
Two requirements must be fulfilled to make the redundant server solution

work:
1. The NEs must support initiated distribution of charging data.
2. The NEs must support alternative distribution destinations. Alternatively,
there must be some equipment in the network (for example a router),
which can route the charging data to the working Mediator if one of them
goes down.
Please note that the consolidation feature, and the hot billing feature is not
supported as standard features for this HA solution.
4.3. Revenue Integrity

Revenue integrity can be offered to the operator in several ways taking
advantage of the features and applications described in the following sub-
chapters
4.3.1. CDR Editor
The CDR Editor is an application for visualization, modification, and generation

of BER coded binary files. It is mainly intended to operate on Toll Ticket files
(TT-files) containing Call Detail Records (CDRs) from switches in wireline,
and mobile telecom networks.
The CDR Editor gives the user possibility to monitor files, which are corrupt to
some extent. This means that corrupted files can be loaded into the CDR
Editor. When the corrupted CDRs in the file have been corrected the file is
stored on disk, where the file can be collected by the Mediator. In this way the
operator does not lose any revenue due to corrupt data.
4.3.2. CDR sequence validation
As long as there exists a unique identifier (for example the Record Sequence
Number, RSN) in the CDRs, this feature can be used.
Page 42
The Mediator allows activation and de-activation of RSN check on CDR

streams received from individual NEs. The RSN check makes it possible to
examine if all CDRs have been received in the correct order and that no CDRs
are missing. In case RSN check fails, an alarm will be raised, but the file will
still be processed and distributed.
The following three bullets are possible failures discovered by the RSN check:
• CDR (RSN number) missing.
• CDR (RSN number) duplicated.
• CDRs (RSN numbers) in wrong order.

4.3.3. CDR Lost Check
The Mediator can check so that no CDRs are lost. The CDR lost check uses
one field in all CDRs, per CDR type (for example, ChargeableDuration) and
summarises it for all incoming and all outgoing CDRs. A periodic check will
see if the difference between the two sums are abnormal.
4.3.4. TT-file transfer validation
The Mediator provides a mechanism called file transfer verification, which can
be used to validate TT-file transfers from Ericsson IOG equipment. Basically,
this function allows the operator to validate that the TT-files sent from an NE
are consecutive. The validation is based on the sequence numbers, which is
reflected in the TT-file name. It is useful to operators for surveillance purposes.
The Mediator can be configured to raise an alarm in case of one of the
following abnormal events occur:
• Inconsistent transfer flag.

That is, if a TT-file marked as non-transferred is followed by a TT-file
marked as transferred.
4.3.5. CDR duplicate check
The CDR duplicate check is based on the consolidation feature. This means
that to use CDR duplicate check, the consolidation module is required.
Page 43
CDR duplicate check is done on some fields of the CDRs over a period of
time. Which fields that shall be used, the rules for the Duplicate check, and
what to do with the duplicated CDRs are configurable. The feature stores a
unique identifier (key) of each CDR in the consolidator node, for example:
• IMSI
• Duration
• Date
• Time
All incoming CDRs are then compared to the unique key from every CDR
stored in the consolidator node. If no match is found for the incoming CDRs,
the key of the CDRs is also saved in the consolidator table, and the CDRs are
sent out from the consolidator node. If there is a match for one of the CDRs, a
duplicate CDR is found, and that CDR can, for example, be discarded. All the
stored keys can be deleted from the consolidator node after a predefined
interval, for example a couple of hours.
CDR duplicate check can for example be used for a pre-paid billing system
where it is important that no data is duplicated, since the subscriber account is
charged in near real time.
4.3.6. Post-collection acknowledgement procedures
There exist NEs that require individual handshaking procedures when

transmitting charging related files. For example, an NE may require an
acknowledgement that the file reception was successful before the next file
can be sent. The Mediator provides a flexible trigging function allowing the
execution of tailor made UNIX-scripts each time a file is received from a
specific NE. The trigging function could also be used for alerting each time a
file is received from a particular NE. Of course, the UNIX-scripts can be
modified to adapt to future changes in the NEs.
4.4. Processing
When a new service is about to be introduced into a telecommunication
network, many billing systems that are in operation today are quite inflexible
when it comes to handling, for example, new CDR formats. Moreover, since
the processing capacity in a billing system is quite costly, operators want to
off-load the billing system. The difficulties in adapting the billing systems often
result in delays. Such delays may have significant impacts on the introduction
of new services in terms of the planned launch-date, or what is often referred
to as, time to market (TTM).
The Mediator addresses precisely those obstacles that often may occur in the
counter-playing between the telecommunication network and the business
network. In its processing capabilities, the Mediator demonstrates its unique
built-in flexibility.
Page 44
A wide range of new services on the internet such as IP-telephony, streaming

media, video conferencing, application hosting and other services, places new
demands on the mediation systems. The new scalable, multi processes
architecture of the Mediator is designed to meet these requirements.
In the following sub chapters descriptions of the processing features available

in the Mediator will be presented.
4.4.1. Decoding and encoding
The decoding and encoding mechanisms are basic entities within the
Mediator. Decoding is used by the Mediator in order to unfold the incoming
CDRs thereby enabling identification of individual data fields within the CDRs.
Encoding is used by the Mediator to assemble individual data fields into a
complete CDR understood by the receiving post processing system.
The Mediator supports decoding and encoding of several pre-defined CDR

formats:
• Supported decoding formats: BER, ISO, PACKED, ASCII, Mixed,

Blocked, Non-blocked, Header-Trailer.
• Supported encoding formats: BER, ISO, PACKED, Structured-ASCII,

ASCII, Mixed, Blocked, Non-blocked, Header-Trailer.
The Mediator also supports encoding formats for other purposes:
• encoding of alarm information
• encoding of log files
Page 45
4.4.2. Compression
Compression can be used to decrease the volume of data and thereby

reduce, for example, the amount of storage capacity needed for long-term
storage, or to reduce the file-transfer time in a network with low bandwidth. A
reduction of storage space, or better usage of the bandwidth, results in lower
costs.
Charging BGw Charging

information compressing information
Figure 7, Compression to achieve better usage of the bandwidth.
The Mediator can compress and uncompress data-files to and from the
following formats:
• GZIP
• PKZIP
Page 46
4.4.3. Filtering
A common situation encountered by operators is exemplified in the figure

below. The CDR flow collected from the network needs to be distributed to
several post processing systems.
Network Elements
A
CDR
Billing
stream-a
System
B
CDR CDR
Stream
BGw stream-b
Fraud
Analysis
C
CDR
Storage
stream-c
System
Figure 8, Filtering one incoming CDR stream to different post

processing systems.
The filtering, or routing, feature is used in order to control the data-flow through
the Mediator. For example, CDRs can be routed based on their type, or any
other information in one or a few of its fields. The return values of the filter
function point out on which link (towards which billing system or other post
processing system) the CDRs should be sent. The name of the link must not
be a number, but can as well be a user-defined string. Every link can be
pointed out by several return values.
In for example GPRS, IP and UMTS, filtering can be based on parameters like
Quality of Service (QoS) or Access Point Name.
The same information can be distributed to more than one post processing
system. For example, in the figure above, the stream-a could be identical to
stream-c while the stream-b distributes only certain type of CDRs suitable to
the post processing system-B. In fact, in most cases, each post processing
system has a specific task and needs only specific information related to its
task.
In case a new post processing system needs to be introduced into the

business support environment, the Mediator can simplify this considerably.
Modifications to the CDR streams distributed by the Mediator to the post
processing systems can be done with minimum disturbances on the
operation.
Page 47
4.4.4. Formatting
Usually billing systems need to receive the charging information in a uniform

structure. As telecommunication networks become more composite, the
variety of CDR formats generated from the network elements grows. The
Mediator provides features that enable re-formatting of CDRs from several
sources into a uniform format.
The formatting feature in the Mediator makes it possible to examine, as well as

modify, individual data fields within the CDR. The Mediator allows collection of
CDRs with different data representation, formats and to translate them into
uniform formats that fits the billing system.
Network Elements
that generate BER
coded CDRs.
BER
stream-a
Billing
uniform System
BGw
stream
ISO
stream-b
Network Elements
that generate ISO
coded CDRs.
Figure 9, Formatting of different charging data streams in the Mediator.
The figure above shows a scenario where the NEs are being upgraded to
newer SW version. The old SW version supports ISO coded CDRs. Once an
NE is upgraded with the new SW release, it can only generate BER coded
CDRs. In this example, it is assumed that the billing system operates with ISO
coded CDRs. However, during the roll out of the new SW release to the NEs,
there will be a period of time when some NEs are running with the old SW
release, and some with the new SW release. For large networks, roll out
periods can last up to approximately six months. With the Mediator such a
scenario can be handled by means of the formatting feature. The BER coded
CDRs can be re-formatted to comply with the ISO format. Thereby, the billing
system would continue to function without needing to consider the BER coded
CDRs. Once the billing system is upgraded to be able to handle the BER
coded CDRs, the re-formatting done by the Mediator can be inhibited.
Page 48

A set of standard billing data structures are delivered with the Mediator, for
example, different revisions of CME 20, CMS 40 and TAP. In addition to this,
formatters can be used to transform the incoming CDRs into formats and
structures that can be handled by the downstream applications.
Also a set of standard formatters are delivered with the Mediator, for example,
different revisions of CME20 -> TAP, or CME20 -> GSM1205. Other formatters
can be offered as professional services to the customers.
Mediator can also be configured to generate CDRs from events and logs.
4.4.5. Consolidation
The consolidation is based on the concept of retaining a pool of

unconsolidated, and partially consolidated CDRs (consolidation table). Every
new record incoming to that consolidation node is then checked against the
consolidation table for possible matches. In the cases where a consolidation
node is connected to multiple, or single, NEs configured to have more than
one thread the consolidation table must be shared between these threads.
This is the reason why the consolidation nodes are a limiting factor from a
performance perspective in the Mediator configurations.
Thanks to the distributed nature of the processing components (see chapter

3.1, for more information), the consolidation table can no longer be maintained
in normal memory. The reason for this is that the consolidation table has to be
accessible from many processes. This is solved in the Mediator using shared
memory. This shared memory can be accessed from multiple processes. The
consolidation table is flushed from the shared memory to disk at the end of
each file transaction to create a security copy.
A chain of shared memory blocks contains the consolidation table for each
consolidation node (that is, there is one separate consolidation table for each
consolidation node). The memory blocks in this chain are built, and initialised
by the job manager.
Page 49
Assume that two NEs connected to the same consolidation node, is placed in
different NE groups. In this case it will only be possible to have one of the NEs
writing their non-consolidated CDRs to the shared memory at the same time.
NEGroup 1
NE 1
buffer 1
Memory
Post
Shared memory table 1 Processing
System
Memory
buffer 2
NE 2
NEGroup 2
Figure 10, Example of shared memory in the consolidation node.
4.4.5.1. Design optimization

The performance is improved in the R9.1 version of the Mediator, by allowing
processing parallelism between the consolidation node and the upstream
processing nodes (like filters and formatters). The solution is based on that all
input CDRs from the same file are accumulated in local buffers in memory,
before being consolidated in the consolidation node’s shared memory, see
Figure 10.
In the old solution the consolidation node is locked for one of the NEs from the
moment the first CDR in that file arrives to the consolidation node, until the last
has arrived. That is, the consolidation node is locked for other NE files
meanwhile the current file is processed upstreams the consolidation node.
With the new Mediator design this locking time (LT) is only a fraction of the LT
in the old solution. This means that the consolidation node is accessible for
other NEs files during the upstream processing of one file, which introduces
the processing parallelism mentioned above.
In the old solution, the LT on the consolidation node’s shared memory also has
to be maintained until all the processing downstreams the consolidation node
is finished. The performance in this case can be improved if the chain of
processing nodes is split in the configuration immediately after the
Page 50
consolidation node, with a file buffer in the memory. In this file buffer all the
consolidated CDRs are written until the complete file is stored. When the
complete file is stored, the file is sent to the job manager for further
processing. This decreases the LT to a fraction of the locking time in the
earlier solutions. This in turn means that the consolidation node is not locked,
and processing parallelism is introduced also here.
Both the optimizations mentioned above are depending on what the

configuration upstreams, and downstreams the consolidation node
respectively, looks like. The gain in terms of increased system throughput will
be better, the more time consuming the configurations are since the LT in
these cases would have affect on the throughput.
4.4.5.2. Consolidation node configuration

Any information contained in the CDR can be combined into a consolidation
condition. Consolidation is not necessarily performed between CDRs from the
same NE, but can be performed on different types of CDRs, for example
consolidation of GSN, WAP and IP CDRs. In case of different incoming
formats, formatters are used to convert the CDRs to the same format into the
consolidation node.
There is a watchdog for each consolidation node, which makes it possible to

control how long a specific CDR have been stored in the consolidation table.
The watchdog can be configured graphically in the GUI. The CDRs, which
have been stored longer than the max CDR age, is removed from the
matching table, and stored in an unmatched directory. An alarm can also
optionally be raised. It is possible to set both an interval, and specific hours
when the watchdog should go in and control the user defined max CDR age.
With configuration services the CDRs stored in the unmatched directory can
be polled from disk, processed, and distributed.
4.4.5.3. Consolidation traffic cases
There are traffic cases in the network when several CDRs are generated for a
single service usage scenario. For example, when a subscriber makes a long
duration call the NE that is serving the subscriber may output several partial
CDRs. This is more and more common in the data communication networks
(GPRS, UMTS) where the subscribers are on-line (connected to the network)
during much longer time periods than in the ordinary wireline and mobile
networks. Normally, NEs can be configured to output partial CDRs periodically
(for example, in 15 minutes interval).
Partial CDRs for the same call may be produced in more than one NE. For
example, if the serving NE changes during the call duration. For example, in a
mobile network when the subscriber is moving from one MSC area into
another MSC area. Another example is in a GPRS network, where CDRs are
generated in both the G-GSN and the S-GSN nodes (see special chapter
about Consolidation in GPRS and UMTS below for more information).
Page 51
NE-1
CDR CDR CDR CDR CDR
BGw CDR CDR CDR
CDR CDR CDR CDR CDR
NE-2
Figure 11, Consolidation of CDR streams.
In the figure above the CDRs in white colour represent the CDRs generated
for a long duration call. By using the consolidation feature in the Mediator,
relevant information components (for example chargeable duration) from all
partial CDRs are consolidated into one CDR. The consolidated CDR would
then be distributed to the billing system and be used to charge for the entire
call.
4.4.5.4. Consolidation in GPRS and UMTS
Likewise, the Figure 11 above could be used to illustrate a GPRS or UMTS

scenario assuming that the NE-1 represents a SGSN and NE-2 a GGSN.
When a GPRS subscriber uses GPRS services, a Packet Data Protocol
(PDP) context is set up. A PDP context can be active for a very long time
while the actual data transmission may only take place occasionally.
In a GPRS network, services are most probably charged based on transmitted

data volumes and maybe also in combination with a time based component.
During a PDP context, partial CDRs may be produced either periodically (for
example every 15 minutes), at pre-defined times (for example at 12.00 and
23.00), at SGSN hand over, or as soon as a certain amount of data has been
transmitted. Partial CDRs for the same PDP context may be produced in
more than one SGSN, since the serving SGSN may change during the PDP
context when the GPRS subscriber has moved from one SGSN routing area
into another. The consolidation feature in the Mediator supports consolidation
of CDRs originating from a GPRS network, since it can consolidate CDRs
generated in different points of time and, in different Network Elements (as
long as there is a unique consolidation key available).
Page 52
The Mediator enables charging for datacom service usage with a minimal
affect on the existing billing system. Mediator can either transform the data into
something the existing billing system can recognise, or it can be used for
building new billing applications, specifically adapted to volume based
charging. This will make it possible to introduce datacom services quickly and
to be able to charge for them immediately. This can be used as an occasional
solution until the billing system has been adapted to handle volume based
charging, or as a permanent solution if that is preferred.
Page 53
4.4.6. Look-up tables
The look-up tables provided by the Mediator makes it simple to handle large
data tables. It can, for example, be used to define that CDRs originating from
certain subscribers (for example VIPs) are to be processed in a particular
way. The look-up tables can be accessed from the processing language, for
example, in filters and formatters using a function, which takes a table name
and a key as argument and returns the data for that key.
VIP table:
VIP-id VIP rank
The information in 5550001 1

Disk
the text file is used 5550002 1
to keep the look-up The look-up table
table up to date. updates its data 5550003 5
For example, it can by reading the 5550004 5

VIP_subscribe
be modified in an text file at
r 5550005 1
editor tool. regular intervals.
5550006 3
5550007 4
5550008 1
CDR
VIP-rank
CDR CDR CDR BGw
CDR CDR CDR
Figure 12, Example of a look-up table in the Mediator.
In
Page 54
Figure 12, VIP subscribers are ranked in a look-up table. The CDR in white
colour originates from a VIP subscriber. For example, by accessing the look-
up table, it would be possible to detect CDRs originating from VIP subscribers
and retrieve the corresponding ranking information. The ranking information
could be added to a copy of the CDR and then be sent to a special post
processing system, for example, call behaviour system and churn
management system.
In principal, look-up tables can be used to hold any type of information.
Combined with the flexible way look-up tables can be used, from within the
Mediator, it increases the total flexibility provided by the Mediator.
One example where a look-up table can be used is the verified interface (the
data is transferred over FTP) between the Mediator and the SDP (Service
Data Point, SDP is one node in the Ericsson pre-paid system, PPS). The SDP
provides the Mediator with information about the Pre-Paid subscriber-base
(MSISDN number). This information is used to create a look-up table in the
Mediator. The update of the look-up table is an automatic procedure and the
Mediator does not need to be stopped. How often the look-up table should be
updated is configurable.
The look-up table is used in the Mediator to filter out the pre-paid CDRs when
distributing the CDRs to post processing systems.
In the cases where the SDP cannot handle the format that the CDRs are
presented in originally, CDR processing is used in the Mediator to adapt the
CDRs to a standardised format.
Another example where look-up tables can be used is subscriber behaviour

trigging. In this case a look-up table is used to hold information about, for
example, a subscriber account, or a number of SMS sent. When user defined
value is reached, an event can be triggered in the Mediator. In the cases
above:
• When a subscriber account goes below zero.
• When a number of free SMS is sent
The Mediator supports four different kinds of look-up tables.
• General memory look-up table;

The information in the table is allocated in the RAM of the Mediator server.
This grants high performance when accessing the entries in the table. The
information in the memory look-up table can be kept up to date, without
stopping the operation of the Mediator. It is done by updating a text file
contained on disk, in which each row represents the corresponding data
for the memory look-up table.
• Tree table – used for number analysis;

Tree tables are managed similar to the memory look-up table. However, it
is used for number analysing of telephony network directory numbers (for
example, phone numbers).
• Tariff table – used for rating;

The tariff table is managed similar to the memory look-up table. However, it
is used for the rating feature provided by the Mediator, see chapter 4.4.7.
Page 55
• General database look-up table;

The information in the database look-up table is allocated in an external
database server. This makes it possible to manage large volumes of data
from the Mediator. For example, a database look-up table could be used to
perform similar functions as a general memory look-up table. A database
look-up table is kept up to date through the external database.
4.4.7. Rating
In order to be able to charge subscribers for their respective usage of the

network, CDRs need to go through a charging analysis. Most operators use
differentiated tariff classes as a competition instrument, for example, when
targeting different subscriber categories. During the charging analysis, an
appropriate tariff class must be determined for the examined CDR.
Parameters such as Quality of Service (QoS), B-number, IMSI, subscriber
type, traffic activity and so on may be used to determine the tariff class. The
fee for the examined CDR will be calculated based on the tariff class together
with the service usage case, for example, the time for start of charge, date for
start of charge, and chargeable duration.
Switch table: Day category table: Tariff table:
Tariff- Day_cat Period,Tariff Day Day_cat Tariff Price

Class per unit
Monday 1
1 1 00:00,1, 08:00, 3 1 100
Tuesday 1
1 2 18:00,1, 22:00, 2 2 200
Wednesday 1
2 1 00:00,1, 07:00, 2 3 300
Thursday 1
2 2 00:00,2
Friday 1
Saturday 2
Sunday 2
19991231 2
Mediator
CDR CDR CDR CDR CDR CDR
X$ Y$ Z$
Figure 13, Example of rating tables in Mediator.
Page 56
The Mediator allows definition of user configurable tariff tables and rating rules
by means of the rating function. The rating feature makes it possible to attach
price, or tariff information in the CDRs, see example in Figure 13.
For example, the rating function can be favourable for pre-paid services,
especially in combination with Hot Billing. The Mediator could be used in order
to determine the tariff, set a price tag on a CDR, and then send it immediately
to a pre-paid system that charges the subscriber’s account.
The Mediator can be used either as a complete rating node, or to make some
pre-rating, depending on the capabilities of the billing system and on the
functional distribution preferred by the operator. For example, it is possible to
translate the volume-based information generated in the GPRS nodes and in
the Internet Access Server (IAS) into a time based charging scheme. Mediator
can translate the volume-based data produced, for example, megabytes sent,
into time-based data that the billing system can handle. An operator may, for
example, decide that one megabyte of data equals ten minutes of speech
time, which corresponds to a known cost in the used currency of the operator.
Mediator can do all these calculations, of course completely user configurable
according to the operator’s needs.
4.5. Logging in Mediator

The logging feature in the Mediator provides monitoring of useful information
about events tracked by the Mediator. The Mediator stores the event
information into log files as the events occur. The Mediator provides the
following log files (detailed information):
1. The data-flow that has passed through the Mediator (Audit trail log).
2. Alarm history (Alarm log).
3. User event history (Event log).
4. Statistics (Statistics).
5. In Service Performance (In service performance log).
For each of the first four log files, the Mediator provide suitable GUI windows
that allow the user to browse among the logged entries. Hence, it is possible
to retrieve substantial history information regarding the events tracked by the
Mediator. Moreover, the user is provided with a statistics function, see chapter
4.5.4, for retrieving a pre-defined diagram visualising trends of the data-flow
through the Mediator.
All the logs in the Mediator are by default stored in an Oracle database. In the
SQL database new tools for reading, searching and reporting are possible to
use. This means that a greater flexibility will be achieved for handling the
Mediator logs.
Page 57
It is possible to configure the Mediator to distribute the log files to external

systems. By post-processing the log files in the external system the operator
can, for example, produce tailor-made graphs visualising trends
corresponding to specific needs. It should be noted that the primary task of the
Mediator is to collect, process and distribute the data that passes through the
Mediator.
4.5.1. Audit trail log
The audit trail log provides information about TT-files that have been collected
or distributed by the Mediator. The following information can be retrieved from
the audit trail log:
• From which NE the TT-file was received, or to which post processing

system the file was sent.
• Time for collection and distribution of a TT-file.
• The number of CDRs contained in the TT-file (only available if the file has
been decoded in the Mediator).
• The number of CDRs per CDR type (for example MsOriginating,

MsTerminating and so on). This information will be stored in the log on the
record type, or tag of the CDR (only available if the file has been decoded
in the Mediator).
The audit trail log is by default stored in an Oracle database. This data can be
useful for an external system, which can search and create reports based on
the Mediator data in the database.
4.5.2. Alarm log
The alarm log contains information related to the alarm events as they take
place in the Mediator since the last clearing of the alarm log. It keeps track of
occurred alarm events, as well as ceased alarm events. All relevant
information such as date, time, alarm information regarding the event is stored
in the alarm log.
There is also an active alarm log, containing all the alarms active in the
Mediator for the moment. When an alarm is ceased, either by the user or
automatically by the Mediator, it is removed from the active alarm log, but the
alarm log is not affected.
All alarms have a configurable severity level. The severity level is set in the
Mediator GUI.
Page 58
Alarms can be distributed, for example, to OSS using TXF, or over SNMP to
other external systems. Mediator also supports distribution and control of
alarms over Alarm IRP. For this feature the CORBA implementation set is
used. This means, for example, that configuration management of Mediator
alarms is possible by using the CORBA interface and besides that noti-
fications will be possible from Mediator, to clients’ CORBA interface.
4.5.3. Event log
The event log contains information about the user commands sent from the
Mediator GUI to the Mediator server process. The event log keeps track of
commands that modify the state of the Mediator server, or the data stored on
the server. It is possible to retrieve the time when the command was issued
and by whom.
4.5.4. Statistics
From the statistics function the user may view graphs visualising the CDR
flow through the Mediator varies over a period of time. From the statistics
window it is possible to printout the statistics information, either direct to a
printer, or to a post-script file. The following parameters are configurable:
• The period of time covered by the graph, that is start-date, end-date.
• The type of events displayed, that is, incoming, outgoing, failed.
• The granularity on the graphs time axis, that is, hour, day, week.
• The type of data on the graphs data-volume axis, that is, files, bytes,
entries.
4.5.5. In service performance log
The In Service Performance (ISP) log contains information about uptime and
downtime for the Mediator
the total availability server process.
of the Mediator server.ItThe
provides
ISP isuseful information
not presented about
in a GUI
window, but is accessed from a terminal window using an SQL monitor.
4.6. Surveillance of the Mediator

The performance of the Mediator is very crucial due to its close relation to the
revenue flow. In order to cope with the strict requirements on its operation; the
Mediator provides a built in mechanism for detecting abnormal events and to
generate alarm information in both single, and cluster configurations.
Page 59
The Mediator also offers surveillance, and alarm generation in both single, and
cluster configurations, for the external processes like Oracle, Radius, and
SNMP over MIB II.
Furthermore, the Mediator offers a watchdog feature, which continuously

monitors its own system environment. It will generate an alarm in case of
internal memory shortage or low disk space. The Mediator user may monitor
the alarm status with comprehensive indications in the Mediator GUI.
In order to keep track of the alarm history, all alarms are logged in the alarm
log. Moreover, the Mediator provides an active alarm log. It is used to keep
track of all alarms currently active in the Mediator. When an alarm is ceased,
either by the user or automatically by the Mediator, it is removed from the
active alarm log, but the alarm log is not affected.
Many operators have central surveillance systems for example Operations

and Support System (OSS). Normally, such systems are manned on 24 hour
basis and are used to supervise the equipment in the network. The Mediator
can be configured to distribute alarms and cease alarm to external
surveillance systems. For example to the OSS over any protocol supported
by the Mediator using the Text File Alarm Adaptation Unit (TXF AAU, see Ref
1). Mediator also supports distribution and control of alarms over the Alarm
IRP.
It is possible to configure the Mediator to distribute only specific alarm types

and to adapt the alarm information to suit the external systems. The Mediator
can be configured to distribute heartbeats to OSS when it has a configuration
running. Heartbeats cannot be distributed over SNMP.
Page 60
5. Terminology
API Application Programming Interface
ASN.1 Abstract Syntax Notation One, used to specify data

formats in the Mediator. ASN.1 is specified in X.208 from
ITU-T
ATM Asynchronous Transfer Mode; A digital signal protocol for

efficient transport of both constant-rate and short burst
information in broadband digital networks. The ATM digital
stream consists of fixed-length packets called “cells”, each
containing 53 8-bit bytes-a 5-byte header and a 48-byte
information payload.
AVP Attribute Value Pair
AXE Ericsson telephone exchange
BER Binary Encoding Rule, a set of rules used to encode ASN.1

values as strings of octets. BER is specified in X.209 from
ITU-T
BGw Billing Gateway
Blocked Blocked files, where a file contains several fix sized blocks.
Each block contains a number of CDRs.
CAPI Communication Application Programming Interface
CAS Customer Administrative System

CCI Common Charging Interface
CCN Charging Control Node
CDR Call Data/Detail Record
DFO Direct File Output
File Descriptor Whenever a file is opened, a file descriptor is returned

which is used for identifying the file.
Filter Filters in the Mediator make it possible to route or discard

CDRs based on their content.
FLAM Frankenstein-Libzda-Access-Method. Compression

formats for files. Owned by Limes Datetechnik gmbh
Page 61
FMC Fixed (wireline) Mobile Convergence
FTAM File Transfer, Access and Management. An ISO standard

(ISO 8571) for the transfer (and access and management)
of files across an OSI network. FTAM is one of the
application layer ISO standards
FTP File Transfer Protocol. A standard mechanism (RFC 959)

for transferring files between both UNIX and non-UNIX
machines.
Formatter Formatters in the Mediator make it possible to convert

CDRs from one format to another and to modify the data in
the CDRs
GPRS General Packet Radio System
GSN GPRS Support Node
GTP’ Modified GPRS Tunneling Protocol
GUI Graphical User Interface
GZIP Compression format for files (RFC 1952).
HA High Availability
HP Hewlett Packard
HIS High Serial Interface
HTML Hyper Text Markup Language
IAS Internet Access Server
IMSI International Mobile Subscriber Identity
IOG Input/Output Group
IN Intelligent Network
IP Internet Protocol
IP-sec Internet Security Protocol, a protocol improving the security

for the IP protocol versions 4, and 6. IP-sec is integrated in
Solaris 8 operating systems.
IRP Integration Reference Point
IPDR Internet Protocol Detail Record
ISO The International Organization for Standardization is the

major body responsible for the development of OSI
Page 62
standards; also used as a prefix to an International

Standard number.
ISO code ISO coded data. International standardized interchange

code where digits and characters are represented by the
International Standards Organization Alphabet number 5
(IA5) character set.
ISP Internet Service Provider
ISP In Service Performance
LT Locking Time
MIB Management Information Base
MPC Mobile Positioning Center
MPLS Multi-Protocol Label Switching, MPLS combines the

strengths of Layer-3 routing and Layer-2 switching, to build
high-performance IP networks. Layer-2 switching is
positioned in the core of the network, where high
concentrations of packet traffic mean that high-
performance packet forwarding is required.
MPS Mobile Positioning System
MSC Mobile services Switching Centre
MSISDN Mobile Station Integrated Services Digital Network number
MSN Service Node
MTP Message Transfer Protocol. A protocol specified by

Ericsson for communication with AXE.
MVPN Mobile Virtual Private Network
NAS Network Access Server
NBU Veritas Net Back up
NE Network Element, for example, a switch or a voice mail

system.
Non-blocked Non-blocked files containing CDRs.
NFS Network File System
OS Operating System
OSI Open System Interconnection is the evolving body of

standards being developed by ISO for the interconnection
Page 63
of different computer systems within a network.
OSS Operations Support System
PACKED PACKED coded data. Interchange code in which IA5 is

used to encode characters and Binary Coded Decimal
(BCD) is used to encode digits.
PCI Peripheral Component Interconnect
PCM Pulse Code Modulation; Coding where input signal is

represented by a given number of fixed-width samples per
sec. Often used for the coding employed in the telephone
network.
PDP Packet Data Protocol
Process A program is an executable file on disk, and an executing

instance of a program is called process. The Mediator
application can be said to consist of several programs.
PPS Pre-Paid System, system for real time billing.
QoS Quality of Service
RADIUS AAA (Authentication, authorization and accounting)

protocol running on UDP/IP according to RFC 2138.
Mediator has a RADIUS accounting server according to
RFC 2139.
RPC Remote Procedure Call
RSN Record Sequence Number
SCP Service Control Point
SDK Software Development Kit
SFI Session File Input, an MTP session for data transfer. The
receiver of data initiates the communication and polls for
data.
SFO Session File Output, an MTP session for data transfer. The
holder of the data sends it spontaneously.
SMS-C Short Message Service Centre
SNMP Simple Network Management Protocol
SQL Structured Query Language
TCP Transmission Control Protocol
Page 64
TDC Telecommunication Datacommunication Convergence
TFTP Trivial File Transfer Protocol. A standard mechanism (RFC

1350) for transferring files.
Thread A process can have several execution paths running

concurrently. Each of these are said to execute in a thread.
TT Toll Ticket
TTM Time To Market
TXF TeXt File alarm adaptation unit
UDP User Datagram Protocol
UDR Usage Data Record
UMTS Universal Mobile Telephone System
VCS Veritas Cluster Server
VMS Voice Mail System
VOIP Voice Over IP
VVR Veritas Volume Replicator
VXFS Veritas File System
VXVM Veritas Volume Manager
X.25 The ITU-T standard for communication in packet-switched

networks.
Page 65
6. References
Ref 1 155 17-FAB 760 170 Uen Text File Alarm Adaptation Unit,
Functional Specification
Ref 2 155 10-CRA 403 22 System Interface Specification,

BGw Mediator R9.0 *
* Note, System Interface Specification does not exist for Mediator R9.1 yet.
Reference to be updated as soon as document is finished.

Technical Product Description, Billing Gateway R9.1

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Technical Product Description, Billing Gateway R9.1

Enviado por

Direitos autorais:

Formatos disponíveis

11/9/2018 Technical product description, Billing Gateway R9.

Technical Product Description 1 (65)

Technical product description,

3. BGW R9.1 OVERVIEW 3

4. BGW R9.1 FEATURES 3

© Telefonaktiebolaget LM Ericsson 2001 - All Rights Reserved

3/1551-ANE 402 02 Rev A 2001-11-19 © Ericsson. Commercial in Confidence

Technical Product Description 2 (65)

1.1. Document Purpose and Scope 3

2.1. Increased competitiveness 3

2.2. Protection of investments 3

2.3. High level of flexibility 3

3. BGW R9.1 OVERVIEW 3

3.1. Mediator scalability 3

3.2. Mediator Interfaces 3

3.3. Supported nodes 3

3.4. Supported Services 3

4. BGW R9.1 FEATURES 3

4.1. Collection and distribution 3

4.2. Security aspects 3

3/1551-ANE 402 02 Rev A 2001-11-19 © Ericsson. Commercial in Confidence

Technical Product Description 3 (65)

4.3. Revenue Integrity 3

4.5. Logging in Mediator 3

4.6. Surveillance of the Mediator 3

3/1551-ANE 402 02 Rev A 2001-11-19 © Ericsson. Commercial in Confidence

Technical Product Description 4 (65)

© Telefonaktiebolaget LM Ericsson 2001 - All Rights Reserved

3/1551-ANE 402 02 Rev A 2001-11-19 © Ericsson. Commercial in Confidence

Technical Product Description 5 (65)

1.1. Document Purpose and Scope

• BGw Mediator R9.1, henceforth only referred to as Mediator.

• BGw R9.1 Software Development Kit, henceforth only referred to as

• BGw R9.1 CDR Editor, henceforth only referred to as CDR Editor.

Each of these applications are covered by this document.

3/1551-ANE 402 02 Rev A 2001-11-19 © Ericsson. Commercial in Confidence

Technical Product Description 6 (65)

Introduction of GPRS and UMTS

• The amount of charging data will increase.

• The requirements on making CDRs available for post processing in

• CDRs will no longer be required by internal systems only, they shall

• The competition between operators will get tougher and tougher.

• Subscriber demands for access to new services will increase. The

• What is the perceived quality?

• Which services will specific subscriber groups be attracted to?

• How should services be bundled?

3/1551-ANE 402 02 Rev A 2001-11-19 © Ericsson. Commercial in Confidence

Technical Product Description 7 (65)

Business support systems

• Billing and rating systems

• Fraud analysis systems

• Call behaviour systems

Communication network Business support network

Figure 1, Mediator is situated in the operators network between the

A common term used to address such systems is post processing systems.

3/1551-ANE 402 02 Rev A 2001-11-19 © Ericsson. Commercial in Confidence

Technical Product Description 8 (65)

3/1551-ANE 402 02 Rev A 2001-11-19 © Ericsson. Commercial in Confidence

Technical Product Description 9 (65)

2.1. Increased competitiveness

• The Mediator supports both Sun, and HP platforms.

• By reducing the Time To Market (TTM) when introducing new services.

• By providing support for diversified charging methods, thereby allowing

• By assisting business support systems, (for example Fraud Management,