technical product description, billing gateway...

Technical Product Description 1 (65)

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

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

© Telefonaktiebolaget LM Ericsson 2001 - All Rights Reserved



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



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



© 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.



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.



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.



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

NE

NE

NE

Business support network

Billing system

NE

NE

NE

Other

Fraud Analysis

Customeradministration

Mediator

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.



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.



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).



• 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.



• 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.



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.

NEs PPSs

ExternalCollector

In Buffer Out Buffer

Log DB

Process Manager

Job ManagerGUI

Log Manager

Collection Component

ProcessingComponent

Distribution Component

NE Groups PPS* Groups

Control Flow:

CDR Flow:

Log data Flow:

Figure 2, An overview of the Mediator architecture. * PPS = Post Processing System



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.



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”.



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.



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.

1 2

3 4

Database

5

NEs

Post processing systems

Alarm GUI

Mediator

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.



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. Mediator acts as initiator.

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.



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



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.

DB

Disk

Mediator

Auth. Server

Radius Daemon

(Acc Server,

Auth. Proxy)

Auth. Client

Acc. Client

Lookup (MSISDN –IP no)

Acc. files

Acc. messages

Acc. Server

Auth. messages

2

6…

5…

4

43

1

6…

TCP/IP

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.



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.



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.



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. Mediator acts as initiator.

• 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. Mediator acts as initiator.



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. Mediator acts as initiator.

• 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.



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.



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.



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




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.



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.



• 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 messaging centres

SMS-C, 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



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)



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.



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



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).



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.



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.



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.



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, there will not be an asymmetric cluster anymore, but a symmetric cluster. Instead of having the second hardware server in cold 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.



Single site cluster

This level of availability solution adds fail over possibilities to the system in comparison to the single machine solution.

LAN

Mediator _1

Mediator _2

Mediator _SB

Mediator _3Router

Executive

Stand-by

Network Elements

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.



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. The level of effort needed depends on the reason for the primary site crash.

All Mediator features can be used in a both the cluster solutions.

4.2.12.2. Redundant servers

LAN

Mediator_1

Mediator_2

Router

Network Elements – Primary: Mediator _1, Secondary: 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



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.



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.



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.



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



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.

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

BGw compressing

Charging information

Charging information



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.

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.

Network Elements

BGw CDR Stream

A Billing

System

CDR stream-a

B Fraud

Analysis

CDR stream-b

C Storage System

CDR stream-c



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.

BGw

BillingSystemuniform

stream

ISO

stream-b

BERstream-a

Network Elementsthat generate BERcoded CDRs.

Network Elementsthat generate ISOcoded 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.



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.



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.

Shared memory table 1

NE 2

NE 1

Post Processing System

NEGroup 1

NEGroup 2

Memory

buffer 1

Memory

buffer 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



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).



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).

BGw CDR CDR CDR

CDR CDR CDR CDR CDR

CDR CDR CDR CDR CDR

NE-1

NE-2



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.



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.

Figure 12, Example of a look-up table in the Mediator. In

BGw CDR CDR CDR

VIP table:

VIP-id VIP rank

5550001 1

5550002 1

5550003 5

5550004 5

5550005 1

5550006 3

5550007 4

5550008 1

CDR VIP-rank

CDR CDR CDR

The information in the text file is used to keep the look-up table up to date. For example, it can be modified in an editor tool.

VIP_subscriber

Disk The look-up table updates its data by reading the text file at regular intervals.



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.



• 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.

Figure 13, Example of rating tables in Mediator.

Mediator

CDR CDR CDR CDR X $

CDR Y $

CDR Z $

Tariff table:

Tariff Price per unit

1 100

2 200

3 300

Switch table:

Tariff-Class

Day_cat Period,Tariff

1 1 00:00,1, 08:00, 3

1 2 18:00,1, 22:00, 2

2 1 00:00,1, 07:00, 2

2 2 00:00,2

Day category table:

Day Day_cat

Monday 1

Tuesday 1

Wednesday 1

Thursday 1

Friday 1

Saturday 2

Sunday 2

19991231 2



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.



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.



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 server process. It provides useful information about the total availability of the Mediator server. The ISP is not presented 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.



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.



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



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



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



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



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.



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...

Documents