project report

Design and Development of an Independent Protocol Simulator

Fayçal Smii, Final Project 2006 / 2007 1

Diploma Project Report

Degree

Telecommunication Engineering

Major

Mobile Services And Networks

Design and Development

of an Independent Protocol Simulator

for an Intelligent Network

Carried out by:

Faycel Smii

Supervised by:

Mr. Khalifa Naddari Mr. Naoufel Ezzine Mr. Zied Choukair

Academic year: 2006/2007


Acknowledgement

This project was achieved on behalf to the fulfilment of the Engineer Degree at

the High School of Communication of Tunis (Sup’Com). It was undertaken

within the framework of cooperation between Sup’Com and Siemens Tunisia.

I wish to thank the Siemens Tunisia Society, for opening its doors to me, and

for making all their resources available so that my work could be developed

under the best conditions.

A very special thanks to my advisors; Mr. Naoufel Ezzine, IN Solutions

Manager at Siemens Communication Tunisia, for the opportunity he gave me to

accomplish this work within the department he is leading, and Mr. Zied

Choukair, my professor supervisor at Sup’Com, for his permanent support and

precious advice which contributed importantly to the successful achievement of

this work.

I wish to thank my supervisor Mr. Khalifa Naddari and also to give him all my

gratefulness for his pertinent supervisory, his advice and his help during the

period of this work. My thanks to all employees in Intelligent Network

Department for their valuable suggestions and advices.

Finally, I thank my parents, sisters, brothers and all my friends for their help,

encouragement and love.

Thanks for everyone who gave me hope.

Faycel Smii



Abstract After the exponential growth of the prepaid telephony, the IN has become a major player in

any mobile operator network. It is the central node through and via which all prepaid

communications are established, it’s as drown in many representations the brain of the

network. To ensure this role the IN is responsible of communicating with many interfaces

using many communication protocols first based on SS7 and now converging to IP.

The Idea of our project is to design and to realize an IPS (Independent Protocol Simulator),

this IPS will be exclusively designed and developed according to the Siemens Standard and

compliant with the Siemens Intelligent Network interfaces and protocols. It will be able to

communicate with IN using two types of communication: communication on payment

interface over Payment Plugin and communication on SS7 over Omni Gateway.

Key Words: IN, IN Charge@once, Prepaid Service, Payment Plugin, HTTP, SS7, VoMS, ASN.1,

CAMEL, MSC, MMSC, Simulation.



General Introduction Intelligent Network (IN) is one concept to specify telecom services, and it has emerged from

technical, business and protocol engineering point of view. Intelligent Networks are used by

teleoperators for creation and management of value added services in telecom networks.

Originally, IN has been applied in telephone and voice services, but today its meaning is also

growing in the service integration of mobile and fixed telephone networks and as gateway to

Internet based networks.

IN offers added value:

• Open standards, vendor independence

• Rapid service creation and deployment

• Customized services to users

• Centralized service management

• New opportunities to make business i.e. new services, markets and customers.

The fundamental service offered by IN is Prepaid Service, it is a very convenient way for a

network operator to charge subscribers for their calls, without the necessity of sending them

bills. Due to payment in advance and online charging, the possible damage that could result

from fraud is limited and fraud attempts can easily be detected and successfully defeated.

To design the simulator, it is mandatory to study the IN behaviour; its interfaces and protocols

as well as the prepaid system. The project report includes four chapters:

In the first chapter “Intelligent Network” we will describe the IN of Siemens. Three sections

will be introduced. In a first part we will give an overview of IN and its services oriented to

telecommunication operators. In the second part we will describe the IN@vantage

architecture and interfaces in witch we will explain IN@vantage platform of Siemens: its

components and based protocols as SS7. This chapter will be finished by Prepaid service

description.

In the second chapter “Technical Description of Charging Service” we will describe the

charging@vantage, the CORBA charging service in which we will describe the Payment

Plugin and its interfaces. We will terminate by describing the message flow of Online

Charging Service.



The third chapter will be dedicated to the simulator design. The communication with the

Payment Plugin and the communication with the Omni Protocol Handler (SS7) will be

described in this chapter as a proposed solution to be used by the simulator. After that we will

explain the architecture of the suggested solution.

Finally, in the last chapter “Simulator Development and Result validation” we will give the

result reached in our project as well as the simulator functionalities.



Chapter I Intelligent Network



Introduction Time-to-market and adaptability of network services are vital to network service providers. In

Different generation mobile networks, Intelligent Network (IN) architectures remain a key

framework enabler to developing, deploying and cost-efficiently maintaining large-scale

interactive voice services.

We try, in this chapter, to explain, in first part, an overview of IN; its fundamentals, goals and

its future. The second part describes the integration of the prepaid service within the IN

system and the different components needed. In a third part, we will describe IN@vantage

architecture and interfaces by giving overview architecture and specifying the Siemens IN

platform components interaction. Terminating by description of protocols used as SS7 and

OSI based protocols.

I IN overview

I.1 IN fundamentals: ITU-T standardization effort

Especially three sets of recommendations are relevant as IN standards: ITU-T Q.1200-Series,

ETSI Core INAP and ETSI GSM CAMEL, ITU-T Q.1200-Series constitutes the basic set of

recommendations of IN. The most relevant aspects standardized by that series are [1]:

• the Service Independent Building Blocks (SIBs), which the service logic is made of,

• the Functional Blocks, that are sets of functions to be fulfilled by different subsystems

to enable IN,

• the Basic Call State Model (BCSM) which describes the embedding of IN within the

basic net-work,

• the INAP protocol for communication between the SCF and the SSF/SRF and other

interface protocols,

• IN services

Some of these standards must be seen as what they are: recommendations. It does not make

sense to provide the standardized set of services if there are no operators or providers ready to



market them on the one hand and if there is a Service Creation Environment to develop new

flexible services considering the market demands on the other hand.

The ITU-T IN standard is structured into various Capability Sets. They can be seen as steps of

completion. Siemens fully covers CS-1 and some features of CS-2.

I.2 Goals of the IN

I.2.1 IN behaviour Intelligent Networks are used to make public switched telecommunication networks more

flexible. IN can serve fixed networks (PSTN/ISDN) as well as mobile networks (GSM,

GPRS, UMTS…).

Additional flexibility is achieved through the following [1]:

Flexible routing selects the destination of a telephone call according to criteria such as time,

origin, user input and so on. It also includes features such as percentage distribution, "the nth

call" and "every nth call". Flexible routing answers the question: "Where to put the call?".

Flexible screening checks, whether a call is allowed to be connected according to criteria

such as time, origin, destination, user input and so on. Black or white lists can be used as

checking patterns.

Flexible billing allows the determination of how much has to be paid for a call and who shall

be charged. Again, criteria such as time or distance can be evaluated.

Flexible User Interactive Dialogue (UID) enables the service to request the caller to provide

additional input such as PUI and PIN, or to select a choice from a menu (e.g. "If you want to

order clothes dial 1, if you are interested in household articles dial 2").

Communication with external systems enables the service to request additional input from

external databases as input to answer the questions about how to deal with the call.

Statistical data can be produced based on a variety of parameters e.g. according to counters,

call information, etc.



Figure I. 1 : Additional intelligence for public switched telecommunication networks.

I.2.2 IN Services [3]

• The services Freephone (FPH), Tele-Info Service/ Premium Rate (TIS/PRM),

Universal Number (UN) are also termed Number Translation Services, according to

their principal function: they translate the IN number into a public phone number by

executing the service logic. The main distinction lies in charging.

• Televoting is a service especially designed for voting by a phone call, especially for

Mass Calling.

• Virtual Card Calling and Universal Personal Telecommunications offer flexibility in

charging and mobility also within stationary networks.

• Prepaid Service Card or Prepaid Card Service is a service for online charging of the

subscriber. Therefore an account is continuously decremented according to the

implemented charging algorithm.

• Control of Use offers screening functions both for incoming and outgoing

calls. This service is normally used in Mobile Networks only.



• The Virtual Private Network is an imaginary network within a network. VPN gives the

service user the feeling of in-house connections to any destination connected, like in a

PBX (Private Branch Exchange). In reality, the connections are switched through a

public network. The Virtual Private Network service meets the increasing demands of

companies and institutions for flexible, customizable private networks eliminating

restrictions found in the basic public network. Service variants for fix and mobile

Networks are available.

I.2.3 Prepaid Card Service

The Prepaid Card Service is the main service given by IN to the mobile operator. The prepaid

principle is based on the guarantee of payment for the party offering the service (mobile

company). New and extremely flexible tariffs can be made subscriber specific and will be

charged during the call. No post processing of charging is required any more. That’s why this

kind of charging is called ‘on-line charging’.

After defined time periods the account of the service subscriber is decremented. When the

account reaches its minimum (zero), the call is released optionally after sending a

characteristic tone.

The service is split into two main functionalities with two separate Service Keys:

1) Prepaid Service: a prepaid account is charged during calls, the supplementary features

needed are: Account enquiry (via voice channel), PIN administration, Simultaneous call

blocking, Initial and menu announcements and Recharge reminder.

2) USSD: balance enquiry and display via short message signaling. The service feature

Advice of Charge is managed by USSD.

The service is very flexible concerning the tariff models and the number of providers and their

possibilities to parameterize the service and/or user data.

I.3 Future of IN

The creation of intelligent networks, the growth of the Internet and the evolution of mobile

networks introduce a range of new considerations that regulators will have to address.



Delivering new services to customers over converged networks is defining the future for

communications operators. Gone are the days of delivering just simple voice services to

customers. The demands are now much greater as consumers wake up to a world of new

possibilities including the 'triple play' of Internet, video and voice. And operators are

discovering that delivering these more complex bundled services is not their only problem.

Intelligent Network, IN offers open standards, vendor independence and rapid service creation

and deployment. It can support all generation mobile networks; GSM, GPRS, UMTS … and

it is opened to support all future evolution with advanced services.

One key concept of IN is therefore not to replace it but instead to add value (in form of

network intelligence) to it.

II IN @vantage architecture and interfaces

II.1 Architecture

An Intelligent Network is a computer based system with a standardised architecture. IN is

integrated into an existing communication network to provide centralized services. Services

are telephone services (Prepaid, Freephone ...) that can be made available to a customer for

specific applications.

To gain the benefits of IN the architecture foresees the subsystems SSP, SEP, SMAP

(optional) and SCE (optional).

The Service Switching Point (SSP) is the door into the IN system for the calls originating in

the basic network.

Tasks of the SSP:

• IN trigger, "door into IN" (detecting a call as an IN call)

• Separation of signaling and traffic information

• Connection of the call to the destination

• Charge ticketing (IN AMA tickets)

• Collecting information for statistics

• Precounting for service Televoting

• Call Gapping (in case of overload)



There is at least one SSP in the network, e.g. if it is the Gateway via which an alternative

provider interconnects with a basic network of an established telecom. Normally there are

several SSPs, dependent on the network structure (integrated or overlay). The maximum

number of SSPs is not fixed generally but is configured in each SCP during installation. There

can be up to several hundred SSPs.

The Intelligent Periphery (IP) is used to perform announcements and User Interactive Dialog

(UID), this means playing announcements and receiving responses as speech or DTMF tones.

So the IP is the translator between traffic channel (speech) and signaling.

The Messaging Gateway (MGW) enables the SCP to communicate with a wide range of

external data points (EDPs) such as e-mail servers, or the Short Message Service Centers

(SMSC).

The Voucher Management System (VoMS) only is needed if the Prepaid Service is executed

on the IN system with voucher recharging. It is used to produce and maintain voucher data

packages.

The Interception Control Point (ICP) enables law enforcement authorities to monitor the

activities of IN users. The ICP is an optional component. Lawful Interception is required by

the law in many countries, enabling an Interception Authority usually part of the executive

authority or of the jurisdiction to supervise specific subscribers’ calls, to monitor data base

modifications performed by these subscribers and to collect corresponding interception

records and to deliver them to the Intercepting Authority.

The Serving GPRS Support Node (SGSN) is the switch in the GPRS package transmission

network which triggers the IN service and controls the IN supported package transmission.

The Home Location Register (HLR) as the central register of subscriber records in the basic

network supplies subscriber data to the SEP.

The Service Execution Point (SEP) is the “center of intelligence” in the IN system. It

performs the service execution, which means it runs the service logic. It decides whether it is

allowed to connect the call, and, if so, where to connect it and how to charge it.

Main tasks of the SEP:

• Service execution

• Collection of statistics data

The database stored on the SCP is filled via the Service Management Access Point (SMAP)

“off-line” (i.e. not during the call). It is task of the SMAP to collect data (e.g. subscriber data)



via GUI and to distribute them to the SEPs. The SMAP functionality (SMAF) may also be

integrated in the SEP.

The @vantage Commander provides:

• Fault, message and alarm management (for SMAP, SEP, @vantage Commander,

StWH, MGW etc.)

• Performance monitoring, e.g. real time analysis of number of calls, CPU load or call

setup times including visualization of online measurements

• Configuration management, esp. of the SEP and the SMAP (e.g. process management)

as well as of the monitored network elements

• User management of the logins of all users of the different components

The backup and restore system (B&R) performs centralized regular backup and, if required,

restoration of all network elements of the IN system which are usually under the control of the

network operator (SEP, SMAP, @vantage Commander Server, StWH, Messaging Gateway

and Interception Control Point server).

The Statistics Warehouse (StWH) is a means for archiving and processing call and user

related statistics data. The different types of tickets written at the SEP are collected at the

StWH in order to make the information enclosed there in available for network operator,

service provider or service subscriber.

The Services are developed at a Service Creation Environment (SCE).

An overview of IN@vantage architecture is given by figure I.2 [1].

Figure I. 2: IN@vantage Architecture.



II.2 Interfaces The different interfaces displayed in figure I.2 are explained in the following paragraph [1]:

SSP – SEP: Intelligent Network Application Part (INAP) operations or CAMEL Application

Part (CAP) operations based on the Signaling System No. 7 (SS7) protocol family for

signaling messages.

SEP – SMAP: proprietary messaging based on TCP/IP for transfer of service subscriber

related data.

SEP – SCE: file transfer based on FTP and on TCP/IP for moving Service Logic from SCE to

SEP.

SSP – internal IP: proprietary protocol for signaling messages (announcements, UID).

SSP – external IP: DSS1 or EDSS1 (like a connection with a PBX) for signaling messages

(announcements, UID).

SEP – HLR: Mobile Application Part (MAP) operations based on SS7 to fetch data about

calling or called party.

SEP – AIP: INAP operations for signaling messages (micro services).

SEP – SGSN: CAMEL Application Part (CAP) Phase 3 operations based on SS7 for signaling

messages.

@vantage Commander – SEP, SMAP, @vantage Commander, StWH, MGW etc.: simple

Network Management Protocol (SNMP) based on TCP/IP used for the message (fault)

management. Trivial File Transfer Protocol (TFTP) based on TCP/IP used for performance

monitoring.

@vantage Commander – SEP: proprietary messaging based on TCP/IP for SEP configuration

management.

B&R – SEP, SMAP, @vantage Commander Server, StWH, MGW and Interception Control

Point server: client - server communication based on Embedded Remote Procedure Call

(ERPC) and TCP/IP for transmission of backup relevant data.

StWH – SEP and SMAP: file transfer based on FTAM and on TCP/IP for statistics raw data

ICP – SEP: proprietary messaging based on TCP/IP for interception relevant data.

SSP – remote system (billing center): file transfer based on FTAM and on X.25 packet

switched transmission for IN AMA ticket files (IN charging records).



SEP – remote systems, VoMS: proprietary messaging interface based on TCP/IP to arbitrary

external data points, either directly connected (such as SEP with VoMS) or connected via the

messaging gateway (e.g. SMSC).

SMAP – remote systems (e.g. billing center), External File Interface (EFI): file transfer based

on FTAM and on TCP/IP.

II.3 IN@vantage platform

II.3.1 Platform components A component is a part of software in the system which is separated from other components

with respect to: design, implementation, production, test, installation and upgrade.

Components provide their functionality through interfaces. Only the interfaces of components

are visible to the rest of the system, hiding the implementation [2]. This part discusses the platform for applications and components. The platform provides

features used by applications and components such as

• Database for storage of accounts, configuration data etc.

• Ticket management

• SS7 / IP access

• ...

PPS@vantage is based on the Siemens @vantage platform. The Siemens @vantage platform

offers:

• a multi-purpose platform to support service convergence as fixed/mobile (2G, 2.5G

and 3G) and IP networks

• a scalable platform enabling flexible configuration and distribution of hardware and

applications

• high connectivity via standardized interfaces into telephone and IP networks

• homogenous operation, administration and management for all types of applications

• efficient development environment for short-term introduction of new applications

The network elements realized so far based on the @vantage platform are:

• service execution point (SEP) of IN@vantage supporting the IN service applications

(PPS, PPD, VPN, FPH, VOT, and any more)

• service management access point (SMAP) of IN@vantage for central management of

the IN service applications



• payment execution point (PEP) of Payment@vantage

• home location register innovation

Not all features of the @vantage platform are used by all realized network elements. That

means in the fact that the feature is available in the @vantage platform doesn’t imply that it is

also available / used in a network element based on the @vantage platform. However it may

support a respective feature or functionality in the application.

II.3.2 SS7 based protocols

II.3.2.1 Signalling System no.7 Signaling System no.7 (SS7) is a system in witch signalling is separated from payload (voice,

data) to its own network. The out band signaling enables separation of switching and control

intelligence in telecommunications network. The Major benefits of SS7 include [4]:

• improves the speed and flexibility of call setup

• allows processors to exchange information rapidly for a call requiring special routing

or handling

• enables operation companies to access customer information stored in network

databases to deliver advanced telecommunications services network wide

• provides the originating switch or customer with detailed progress and processing

information about the call as it is established. SS7 is an OSI-RM compliant protocol

• network part is responsible for network related functions (connection setups, routing,

transport, and error detection)

• user/application part includes the service specific functions

II.3.2.2 SS7 network component

The SS7 network is an interconnected set of network elements that is used to exchange

message in support of telecommunications functions. The SS7 protocol is designed to both

facilitate these functions and to maintain the network over which they are provided. Like most

modern protocols, the SS7 protocol is layered [4].



Figure I. 3: SS7 Network Architecture. According to figure I.3 SS7 Network contains the following components:

• Signaling Link, SL (MTP1-MTP2)

• Signaling Transfer Point, STP (MTP1-MTP3)

• Signaling Point, SP (MTP1-SCCP, includes one or more user/application parts)

• Message Transfer Part (MTP)

Provides reliable connectionless service for routing messages through SS7 network

• MTP1 (signaling data link)

– Physical layer of OSI model

– Physical and electrical characteristics

• MTP2 (signaling link)

– Provides reliable sequenced delivery of data across signaling data link

– Layer 2 of OSI model

• MTP3 (signaling network)

– Provides functions for routing data across multiple STPs between signaling points



– Message handling

– Network management

1) Signaling traffic management

2) Signaling link management

3) Signaling route management

• SCCP (Signaling Connection and Control Part)

– Equivalent to OSI network layer

– Addressing capability with PC (Point Code) and SSN (Sub System Number)

– Message delivery management

• TCAP (Transaction Capabilities Application Part)

– Distributed SS7 processes’ dialogue management (comparable to OSI ROSE)

– Interfaces directly with SCCP-layer

– Component sub-layer

– Transaction sub-layer

• INAP (Intelligent Network Application Part)

– Set of different functional service elements as OPERATION-elements and RESULT-

elements

– INAP-services are defined with ASN.1 (Abstract Syntax Notation One) language

– INAP ASN.1 descriptions are compiled to coding/decoding entities

– CS-services are defined with INAP-interfaces.

The layers architecture is given by figure I.4.

Figure I. 4: Layers architecture of SS7.



II.3.2.3 Protocol configuration

SCCP:

The local point code is contained in the main SCCP configuration message and this should be

set to the appropriate value given in the programmer’s manual. In addition, configuration

messages are required for the local subsystem, remote point code and remote sub-system.

TCAP: TCAP should be configured for ITU operation in the flags parameter of the TCAP

configuration message. The dialogue id ranges should be set to allow the appropriate number

of ids split between incoming and outgoing dialogues. Some applications may require

initiation of dialogues in one direction only.

MAP: The TCAP dialogue base id and number values should be set to match those given in the

TCAP configuration module. The user dialogue values are a separate independent range from

the TCAP dialogue ids but will need to be similarly dimensioned, e.g. if 16 incoming dialogue

ids are configured in MAP then TCAP must also support at least 16 incoming dialogue ids.

The SS7 protocol stack is realized via the OMNI Signal/Ware platform. The following

features have been developed in order to extend the SS7 connectivity [2]:

• The SS7 protocol stack is encapsulated by a common interface. Thus it is possible to

use other SS7 protocol stacks than the OMNI Signal/Ware platform in future versions

of the system.

• Support for SS7 boards in four nodes of a cluster in order to ensure the handling of

SS7 traffic even in case that a node is down.

• Support of multiple detection point codes in order to increase the SS7 traffic to a based

network element.

• Support of SSNC in order to offer higher scalability e.g. between HLR and MSC.

Figure I.5 shows the integration of a Telco Service platform into SS7 network.



Cluster interconnect

Fiber channel

SS7 links

Figure I. 5: Integration into SS7 Network.

II.3.3 Integration into IP network IN@vantage architecture shows that several interfaces of the platform are based on different

protocols as SNMP, TCP/IP… We try to explain in this part the integration into IP network.

For IP connectivity subsystem one node with a virtual IP address is configured as IP master

node and is addressed by applications. This node cares for load distribution among all nodes

of the cluster, thus enabling scalable services. If the IP master node fails, another node takes

over the role of the master node. This action is transparent to the applications.

The RTP takes care that all involved parties are informed on the cluster reconfiguration.

Figure I.6 shows the integration of a Telco Service platform into IP network.



Cluster interconnect Fiber channel

Public LAN

Figure I. 6: Integration into IP Network.

III Prepaid service

III.1 Introduction

The PPS (PrePaid Service) provides the means of minimizing the risks resulting form fraud.

Through payment in advance and online charging, there is no need to credit subscribers. The

costs of administration and customer care are also reduced. Customers without a bank account

can become subscribers of the service. The credit rating of subscribers does not need to be

checked. Reduced costs for providers of the PPS may benefit subscribers as well.



SIM cards Subscriber Identity Mobile (SIM) cards are sold with their International Mobile

Subscriber Identity (IMSI) marked “valid for PPS only”. This means that subscribers have to

use the service for all calls, the only exception being the network emergency numbers [2].

III.2 How the PrePaid Service works?

If a call is set up

• The calling party number and the called party number are checked

• If the calling party number is recognized as a PrePaid number, the IN System is

contacted by the MSC.

• The PrePaid service now checks the account, if sufficient money is available, the

services reserves a certain amount of money. A message is sent back to the MSC to

allow a connection for a certain period of time and to report back in case the call

released or the time is elapsed. If there is no money left to setup the call, the PPS

sends a message to release the call.

• The MSC acts according to the message; it sets up the call or releases the call or

reports back

The necessary data to contact the IN System is stored in the HLR. The integration of the

system into network is given by figure I.7.

Figure I. 7: Integration of the PPS into mobile Network.



III.3 Description of the PrePaid Service

Prepaid@vantage is based on the new @vantage architecture with focus on voice-data-

integration, fulfilling highest performance and capacity requirements [2]:

• Support voice and data in GSM, GPRS and UMTS networks.

• Volume based charging in real time for the upcoming applications of the mobile

internet.

• Simultaneous support of 2, 2.5 and 3G networks.

• Support the standardized protocols.

• Can be combined easily with others services, e.g. mobile payment or VPN and allows

for a fast realization of attractive and differentiated offers.

• Enhanced service creation environment and comfortable administration interfaces with

Prepaid@vantage as provided with the platform IN@vantage V7a to speed up time-to-

market and to ease operation during the entire life cycle.

Conclusion To understand the Siemens IN it is requisite to study the different entities of IN platform, its

architecture and its integration into different networks. This chapter introduces an overview of

the IN. It describes components, architecture and interface of the IN@vantage in purpose to

prepare to charging service study. Next chapter will be consecrated to prepaid service

requirement and description.



Chapter II

Technical Description Of the Charging Service



Introduction Charging service is the main service offered by IN to telecommunication network operators

and users. Through payment in advance and online charging, there is no need to credit

subscribers. The cost of administration and customer care are also reduced. Management and

administration of subscriber’s accounts are acts allotted to IN system.

In this chapter, we introduce, briefly, the different Charging Service types, their structure and

message flow. We are interested only in features that are useful to our project.

We will start by presenting, in a first part, an overview of the Charging@vantage with its

description and architecture. In second part we will introduce the CORBA Charging Service

in which we will give a technical description of the Payment Plugin and its interfaces with

their usage scenarios. We will complete by explaining the Online Charging Service.

I Charging@vantage It is the successor of the Payment@vantage system and is used to expand the possibilities of

the classic IN PrePaidSystem by offering additional interfaces to connect to SMSC, MMSC,

MSP and many more. Charging@vantage as a central network element is responsible for

control and monitoring of entire charging transactions. A charging transaction is defined as

the process from the initiation of the charge request until its final confirmation [2]. Depending on the use case one or more network elements interwork with charging@vantage:

• The application servers, e.g. http content server, MMS-C providing services to the

consumers.

• Policy Router and/or Monitor enabling monitoring and control of IP sessions and http

streams.

• Account Management Systems, holding the prepaid consumer accounts.

All systems are controlled and synchronized by Charging@vantage via defined interfaces.

• Charging@vantage determines the chargeable amount based on various parameters

received from the network: MSISDN, service ID, URL, time… It controls the

tariff determination in close cooperation with the online accounting systems. i.e.

PPS. This concept allows for subscriber specific data such as usage counters to be

used for the tariff determination as well.



• Charging@vantage determines the account management system involved in the

charging transaction based on the received MSISDN. The determination is done

via an internal “address resolution table” or by inquiring a User Repository.

• Charging@vantage initiates synchronizes and controls the booking of the

appropriate amounts on the involved consumer accounts. From point of view of

Charging@vantage first a reservation of the amount is carried out: the amount is

withdrawn from the subscriber’s PPS account and is stored as reservation on

Charging@vantage.

• Charging@vantage communicates the successful / unsuccessful reservation back

to the requesting server incl. further details for advice of charge and/or session

monitoring.

• Charging@vantage further monitors the transaction until having received a final

confirmation from the partner network element. The response of the corresponding

partner network element is confirmed in a ticket for subsequent billing or

statistical evaluations. Additionally (e.g. in case of session charging) subsequent

amount reservations or refund of “non-used” amounts are handled by Charging@vantage.

• To support deferred delivery/charging in parts subscriber accounts containing

reserved money are stored temporarily on Charging@vantage system.

Figure II. 1 : Charging@vantage Architecture.



II CORBA Charging Service

II.1 CORBA Architecture Overview

The CORBA Architecture is needed for the communication between the Payment Plugin and

the Intelligent Network. In this part, we try to give an overview of this architecture.

II.1.1 the Object Request Broker (ORB) A fundamental part of the Common Object Request Broker architecture is the Object Request

Broker (ORB). The concept of an ORB is this: When an application component wants to use a

service provided by another component, it first must obtain an object reference for the object

providing that service. After an object reference is obtained, the component can call methods

on that object, thus accessing the desired services provided by that object. (The developer of

the client component knows at compile time which methods are available from a particular

server object.) The primary responsibility of the ORB is to resolve requests for object

references, enabling application components to establish connectivity with each other. The

ORB has other responsibilities as well [5].

II.1.2 Interface Definition Language (IDL) If the concept of the Object Request Broker is one cornerstone of the CORBA architecture,

the Interface Definition Language (IDL) is the other. IDL, as its name suggests, is the

language used to define interfaces between application components. It is not a procedural

language; it can define only interfaces, not implementations. C++ programmers can think of

IDL definitions as analogous to header files for classes; a header file typically does not

contain any implementation of a class but rather describes that class's interface. Java

programmers might liken IDL definitions to definitions of Java interfaces; again, only the

interface is described no implementation is provided.

The IDL specification is responsible for ensuring that data is properly exchanged between

dissimilar languages. For example, the IDL long type is a 32-bit signed integer quantity,

which can map to a C++ long (depending on the platform) or to a Java int. It is the

responsibility of the IDL specification and the IDL compilers that implement it to define such

data types in a language-independent way [5].



II.1.3 CORBA Clients and Servers Traditionally, in a client/server application, the server is the component, or components, that

provide services to other components of the application. A client is a component that

consumes services provided by a server or servers. The architecture of a CORBA application

is no different; generally, certain components of an application provide services that are used

by other components of the application. Not surprisingly, the general terms client and server

refer to these components of a CORBA application.

Frequently, an application component can provide services to other application components

while accessing services from other components. In this case, the component is acting as a

client of one component and as a server to the other components. In fact, two components can

simultaneously act as clients and servers to each other [5].

II.2 Overview of the Payment Plugin Interface

II.2.1 Short Description In general, the Payment Plugin is a client to the Charging@vantage. It is embedded in the

trusted domain and consists of different external interfaces and an internal interface [6].

It provides an HTTP-based interface for a web-based application using servlets and allows

this application to send requests to Charging@vantage. The Plugin handles the CORBA

communication with Charging@vantage.

In addition, the Payment Plugin provides a Java-based API. This makes it possible to connect

a non-web-based client to Charging@vantage in an easy manner.

The Java 2 Enterprise Edition (J2EE) connector interface allows for the deployment of the

Payment Plugin to J2EE compliant servers.

The Payment Plugin has an internal interface. This interface is CORBA-based and connects to

the Charging@vantage server. This internal interface is not released for direct access from

outside. However, the external interfaces use a subset of the methods provided by the internal

interface.

Configuration parameters:

As the technical data needed for the Payment Plugin interface, configuration parameters are

kept in property files. They can be changed project-specifically or site-specifically by all users

who have write rights for the property files.



II.2.2 Usage Scenarios of the Payment Plugin Interface The following figure (II.1) shows how the Payment Plugin can be used in order to connect

different kinds of applications to the Charging@vantage server [6].

Figure II. 2: Payment Plugin Architecture.

Description: the application server can use three methods to pass CORBA calls via the

payment communication layer to Charging@vantage:

• For J2EE servers, the J2EE connector interface may be used.

• For web-based applications (HTTP), the Payment Plugin servlet may be used.

• For non-web-based applications, the Payment Plugin library has to be loaded to the

application.

All these interfaces are functionally equivalent.

J2EE solution: a Java 2 Enterprise Edition (J2EE) connector interface supports a standard

architecture for connecting the J2EE platform to Charging@vantage.

Web-based solution: The web-server-based application has to provide all the parameter

values which are required in the IDL interface specification as name/value pairs. These



name/value pairs (GET or POST requests) from web-based applications are mapped to

CORBA parameters for the call at the payment interface. Result values are also coded in this

way.

Non-web-based solution: Non-web-based applications have to use the

PaymentRequestclasses of the Payment Plugin Java library to pass the parameters of the

request to the CORBA calls. The response parameters are available via the

PaymentResponseclass.

II.2.3 HTTP Interface

II.2.3.1 Payment Plugin Servlet Servlets are designed to work within a request/response processing model. The plugin servlet

is a Java component plugged into a Java enabled web server to enhance its functionality. The

web server communicates with the servlet via the external web server interface.

A servlet can request another servlet on the web server just as a client can by requesting a

URL. The servlet API provides a more efficient inter-servlet communication than opening a

socket connection back to the server.

The plugin servlet provides a synchronous HTTP interface for payment requests. POST

requests are mapped to CORBA calls at the Charging@vantage (PEP) interface.

The client of the plugin servlet, e.g. the content server, has to provide all the parameter values

which are required in the IDL interface specification as name-value pairs. Result values are

also coded in this way.

II.2.3.2 Parameters for Payment Operations

Payment Operations:

The web-server-based application has to provide an attribute list of name/value pairs

(HttpServletRequestfrom javax.servlet.http) for the payment request. Each pair has to be

mapped to a parameter belonging to one of the following ChargingServer or ClearingServer

or AccountManagementServer interface operations.

The asynchronous CORBA operations are chargeAmount, authorizeAmount, captureAmount,

rechargeAmount and transferAmount.

ChargeAmount request: If the Payment server receives a chargeAmount request via the

CORBA interface, it checks the transaction status. If the transaction status is requested, the

Payment server handles the request with HLR and SCP.



If the chargeAmount request has been processed successfully, the Payment server sets the

transaction status to processed and issues a chargeAmount confirmation with a positive

execution code.

If the chargeAmount request has not been processed successfully, the Payment Server sets the

transaction status to failed, and issues a chargeAmount confirmation with a negative

ExecutionStatus.

The charging operation was successful: the consumed money has to be recharged manually to

the SCP with the rechargeAmount operation.

The operation was not successful: indications about the failure are stored as tickets and in a

recovery log (Payment Transaction Administration (PTA) result files).

RechargeAmount Request: The rechargeAmount operation triggers a recharging

transaction on the Clearing server.

If the Payment server receives a rechargeAmount request via the CORBA interface, it checks

the transaction status. If the transaction status is requested, the Payment server handles the

request with HLR and SCP.

If the rechargeAmount request is successfully processed, the Payment server sets the

transaction status to processed and issues a rechargeAmount confirmation with a positive

execution code.

If the rechargeAmount operation is not successful, the Payment server sets the transaction

status to failed and issues a rechargeAmount confirmation with a negative execution code.

AuthorizeAmount request: The authorizeAmount request is used if deferred payment or

payment in instalments is requested. This operation comprises the following transactions:

• Authorizing and reserving an amount of money.

• Executing the first rate for payment in instalments.

If finalizeAuthorization is false, the currently authorized sum of money can be increased by

this value. The currencies of money and moneytoAuthorize must be the same. The

additionalMoneyToAuthorize parameter comprises amount and currency.

CaptureAmount request: The captureAmount request is used if payment with separate

authorization and reservation is requested. This operation comprises the following

transactions:



• transferring the required amount of money from the source to the target (virtual)

account

• reducing the amount of currently authorized money within its transaction context

• either authorizing an additional amount of money or finalizing the authorization

(ending the transaction)

If the Payment server receives an authorizeAmount request via the CORBA interface, it

checks the transaction status. When the authorizeAmount request has been processed

successfully (the requested amount of money is successfully reserved from the SCP), the

transaction status is set to authorized. If any number of captureAmount requests is received

via the CORBA interface while the transaction status is authorized, the transaction status is

changed to capture Requested.

The authorizeAmount request and captureAmount request are used together: firstly, a certain

amount of money is authorized to be used, and then this money is consumed (captured).

Payment Confirmations:

Confirmation is received asynchronously by the operations called by Charging@vantage.

Which type of confirmation (with or without transparent data) is received, depends on the

version of the Payment Plugin interface.

The execution result is returned using the rechargeAmountConf1 operation. The confirmation

also contains the new expiry date and the new balance of the account which has been

recharged.

The result values of ExecutionStatus type are used to confirm the execution of the request in

Charging@vantage and to return the success or error code to the Payment Plugin. The

execution statuses are transported as part of asynchronous responses (confirmation) after the

execution of a transaction has been completed by the Payment server.

Values > 0 are sent from Charging@vantage.

Values < 0 are errors detected by the Payment Plugin.

The Payment Plugin interface provides synchronous request/response behaviour. The

asynchronous behaviour of the CORBA layer is hidden. The CORBA interface is the internal

interface to Charging@vantage and cannot be accessed by the applications. The values and

ranges of attributes are not checked by the Payment Plugin interface.



Result values to return success or error: The result value of type ExecutionStatus is used

to asynchronously confirm the execution of the request in Charging@vantage and to return

the success or error code to the Payment Plugin. The values are the same for the simple

confirmation operations.

Result values caused by Payment Plugin: The following values are created by the

Payment Plugin. These return codes are caused by exceptions immediately after the call of the

CORBA operation, the return error codes are given by Table II.1 [6]:

Return Code Name

-100 transaction already open

-101 invalid transaction

-102 duplicate transaction ID

-103 confirmation timeout

-104 CORBA communication error

-105 overload detected

-106 invalid user ID

-107 invalid access rights

-108 limits exceeded

-109 response timeout

-110 no server resources

Table II. 1: Return error codes from Payment Plugin.

Result values caused by mapping errors: The following errors are caused by mapping

errors. To avoid CORBA exceptions, these errors have to be detected before the interface

operation is called. Table II.2 shows the result values caused by mapping error [6]:

Return Code

Name Comment

-200 Request Type not valid Without the request type the appropriate

request object cannot be created with the

given parameters.



-201 Parameter or attribute

not found

A parameter or attribute needed for the

operation is not found in the http request.

-202 Number Format error A request attribute of type Integer, Long,

Short or Double cannot be parsed from the

attribute or parameter value of the http

request, e.g. mike55 cannot be parsed to

Long.

-203 Class Cast error A class cast exception occurred due to an

invalid parameter value.

-204 Account Handle Specification error

Indicates that the number of elements in

the attribute lists specifying the account

handles is inconsistent.

-205 Multiple user IDs error Indicates that multiple values have been

specified for the user IDs in the list of

account handles.

-206 Multiple PINs error Indicates that multiple values have been

specified for the PINs in the list of account

handles.

-207 Multiple routing info

error

Indicates that multiple values have been

specified for the routing information in the

list of account handles.

-208 Multiple account types

error

Indicates that multiple values have been

specified for the account types in the list of

account handles.

-230 Cluster name not found Indicates that the cluster name specified in

the request has not been configured. not

Table II. 2: Result values caused by mapping errors.



Usage of the ClusterName Parameter: ClusterName is an optional parameter. It is

possible to connect the Payment Plugin to more than one Charging@vantage cluster. When

using the HTTP interface the cluster name may be specified in the list of request parameters.

For all other interfaces the cluster name has to be provided before sending requests to

Charging@vantage.

When the Charging@vantage server confirms the execution of a request, it returns the original

transactionID and an execution status indicating whether the request was successful.

These confirmations are called "simple confirmations".

Enhanced confirmations:

Enhanced confirmations also include a string field containing transparent data with additional

information about the execution of a request, e.g. rating information or the new expiry date.

The usage of enhanced confirmations can be specified in the Payment Plugin configuration

parameters. The default configuration does not support enhanced confirmations.

II.2.4 Java API In this part we try to describe the Payment Plugin interface for non-web-based applications.

Clients which are not web-based and not able to use HTTP can integrate the payment plugin

as a Java library (PaymentPlugin.jar). The Application Programming Interface (API) consists

of the following files:

• PaymentConnectionFactory class

• PaymentConnection class

• Subclasses of PaymentRequest and PaymentResponse

• Property File

Using these files means avoiding the HTTP request. The request parameters for the CORBA

interface calls are passed with set methods or by using the appropriate request constructor.

The response parameters can be retrieved with get methods.

The binaries of the above mentioned classes and of all generated CORBA classes are stored in

a .jar file and need to be installed on the machine where the other Charging@vantage client

runs. Additionally, a CORBA runtime environment has to be installed. Currently there are

two separate Payment Plugin variants for either VisiBroker or JacORB.

II.2.4.1 Usage Scenario for the Java API This section briefly describes how to use the Payment Plugin interface for non-web-based

applications [6].



The package de.siemens.advantage.payment.payplugin.impl.processing, included in the

Charging@vantage product delivery, implements the library interface to the Payment Plugin

interface.

Alive messaging and load distribution can be implemented by clients using functions of the

Payment Plugin.

The design is similar to the J2EE connector API. A PaymentConnectionFactory manages a set

of logical connections to the Payment server. These connections are used to send payment

requests to the Charging@vantage server. Requests to the Payment server are represented by

instances of subclasses of PaymentRequest.

A property file contains the configuration parameters of the Payment Plugin. During start up,

the Payment Plugin reads this file and sets the appropriate internal control variables.

II.2.5 J2EE Connector Interface This part describes the Java 2 Enterprise Edition (J2EE) connector interface as a standard

architecture for enabling J2EE components to interact with enterprise information systems.

The JCA defines a standard architecture for enabling J2EE components such as enterprise

beans, servlets or Java Server Pages (JSP) to interact with enterprise information systems

(EISs). J2EE components use connections to access services provided by the EIS. Connection

objects are pooled by the application server. This provides a scalable application environment

that can support a large number of clients requiring access to an EIS. Using connection

factories, connection is obtained between the application and the EIS through the application

server. On receiving a client request, connections from the pool are given to the client. After

use, these connections are released by the client and are put back in the connection pool.

The J2EE connector interface is very similar to the Java API. Both interfaces use different

classes for connection factories and connections. The request classes are identical.

II.2.6 Installation Instructions The Payment Plugin uses the log4j logging framework to write its log messages. The log4j

library is contained in the Payment Plugin package.

The VisiBroker runtime libraries have to be installed and the JacORB runtime libraries are

part of the PaymentPlugin packages and are installed together with the JacORB variant [7].

II.2.6.1 Tomcat Servlet Engine The Tomcat 4 servlet engine is required to use the HTTP interface of the Payment Plugin.



It may either be used standalone or be integrated into an existing Apache web server

installation.

The standalone installation is recommended if there is no web server already running on the

target host or if the web server is to handle dynamic web content only.

II.2.6.2 Standalone Configuration for VisiBroker In order to make the JVM use the VisiBroker orb instead of the default orb two modifications

to the Tomcat 4 standard installation are required:

1. Making the VisiBroker runtime libraries available to the Tomcat class loader.

2. Instruct the JVM to use the VisiBroker ORB.

II.2.6.3 Standalone Configuration for JacORB Similar to the previous sections two modifications to the Tomcat 4 standard installation are

required for the JacORB variant:

1. Making the JacORB runtime libraries available to the Tomcat class loader:

The jar files required for JacORB are part of the Payment Plugin web application archive and

thus loaded by the Tomcat web application class loader.

2. Instruct the JVM to use the JacORB.

II.2.6.4 Selection of Listener Port for Local Object Adapter The PaymentPlugin needs to open a port where the local object adapter for the broker objects

receives confirmations. This port number needs to be fixed in order to limit the creation of

broker objects in the NameService of the charging@vantage server and to firewall

configurations for the communication between the PaymentPlugin and the charging@vantage

server.

This port is specified in the PaymentPlugin.properties file:

The property Corba.OAPort = <port number> contains the port number to be used. The

number specified must be within the range from 1024 and 65535 and must NOT be used by

any other application running on the same machine.

Both VisiBroker and JacORB provide additional possibilities to specify the listener port, e.g.

by setting system properties possibly overwriting the port value defined in the Payment Plugin

properties file. However, it is recommended not to use those options.



III. Online Charging Service

III.1 Internal Service Handling of SS7 Traffic

III.1.1 Structure of Protocol Handler On @vantage systems, there may found four process groups: CCC_CAP (Common Call

Control CAP), CCC_USER, CCC_MAP and CCC_INAP. Processes of the process group

CCC_CAP containing the protocol handler. The processes of the process group CCC_USER

containing the service logic execution environment (SLEE). The processes CCC_MAP and

CCC_INAP are predicated and may start only for compatibly reasons.

From system view, several layers and processes handle incoming SS7 messages until they are

finally processed by a service.

The figure III.3 gives the architecture of the Internal Message Stack.

OEM

TSP

@vantage

Omni processes

DP*

CCC_CAP

SS7 network

OMNI

CCC (CAF) CFRAME (CAF)

Dispatcher

CCC_USER Service (Appl.) SLEE (SAF)

CFRAME (CAF)

Figure II. 3: Internal Message Stack. The common protocol handler (CPH) and all special protocol handlers (SPH) are enclosed in

a single physical protocol handler process group (CCC) and will manage all current protocol

families SINAP, CAMEL and MAP. There is only a single TCAP user application, which is

registered with multiple SSN. The SSN identifies all adequate/configured protocol families

for further execution. Example, CAMEL Phase 3 (CAP03) deals the GPRS short-term TCAP



and short message service (SMS) and is registered with their own SSN. The specific protocols

are consequently running within this TCAP user application, is only defined by configuration.

Signalware checks incoming messages for correct routing information. The TSP dispatcher

routs the massages to a CCC_CAP process. The protocol handler handles the protocol based

session information and triggers a SLEE-based service, running in the CCC_USER process.

SLEE

SCF

MAP SSN CAP SSN SINAP SSN CCC_CAP

SS7 Stack

CCC_USER

Figure II. 4: Interworking of CCC_CAP and CCC_USER.

III.1.2 Supported Protocol Families – INAP, CAMEL, MAP

The protocol families INAP (i.e. SINAP), CAMEL (CAP) and MAP including their specific

protocol variants are supported by @vantage. Specific protocols are installed as a separate

platform package component. SINAP5i, 6i, 6i+, 5s and 7s have no own installable package;

they are part of other protocol handler packages. The protocol packages can be separately

switched off by configuration. Project specifically it is possible to add further protocol

families or variants.

III.2 Message flow

SS7 Scenarios

In SS7 networks a big variety of different call and signalling scenarios are possible. Typically,

@vantage related application traffic consists of few main scenarios. These scenarios may



appear in combinations (e.g. CAP Roaming with Assisting IP) depending on the special

conditions of the overall scenario. Thin black arrows represent signalling connections and

thick blue arrows represent speech/data channels (with signalling connection included).

The correct translation of SEP in the SS7 world is “Signaling End Point”. There is a confusion

with the IN term “Service Execution Point”. In this chapter means SEP “Service Execution

Point”. Many calls are possible; we explain same of them in this part.

USSD Calls

Dialling special numbers (e.g. *100#) the mobile network may be accessed with USSD. This

USSD request may reach the @vantage on two different ways, configured by respective

network settings. The @vantage answers with a short string that is displayed at the mobile.

No speech/data channel will be established.

Scenario 1:

MSC

SCP HLR

@

2 1

3

Figure II. 5: USSD Call Scenario.

1. A-party dials USSD number

2. The SSP/MSC forwards IN trigger (IDP) to the @vantage.

3. The @vantage answers with a text transferred in the “out band info” field of an

announcement (PA) message.



Scenario 2:

MSC

SCP HLR

@

1

2

3

4

5

Figure II. 6: USSD Call Scenario.

1. A-party dials USSD number

2. The SSP/MSC forwards the USSD request to the HLR

3. The HLR sends USSD request to @vantage (PUSSR).

4. @vantage sends answer text.

5. HLR sends the answer text from it.

Conclusion To study the Payment Plugin and its different interfaces, as well as, its configuration that is

special to the society is a requirement needed to develop the simulator. This simulator must be

able to communicate with Intelligent Network via Payment Plugin using its HTTP Interface.

In the next chapter we will try to forward our design of the simulator and to specify the

requirements to the suggest solution.



Chapter III Simulator Design



Introduction In the previous chapters we went through the architecture of the Intelligent Networks, we

explained its main feature and studied its different interfaces. In this chapter, we will focus on

the design and the positioning of the simulator in its environment. We will try to present in

detail the main feature and the different components of the simulator. As this is the most

important step in our project realization, we will try to argue our choices and the raison that

push us to the direction of the given solution.

We will dedicate a first part to describe the Siemens Charge@once Intelligent Network as a

system that combine both charging of session through IP and charging of transaction through

SS7. In the second part we will speak in detail about the communication through the Siemens

internal Payment Plugin and then the communication via the SS7 interfaces. In the last part

we will describe the design steps, the features and the main components of the simulator that

we will develop.

I Charging@vantage, Prepaid@vantage and Charge@once The Siemens Charge@Once Intelligent Network was introduced to the market as the answer

to the higher demand on the convergent online charging solution for all types of application,

all types of networks and all type of subscribers. It could be simplified to the following

equation:

Charge@once = Charging@vantage + Prepaid@vantage. [2]

The Charging@vantage is dedicated for IP content and event Charging, it could be triggered

by all types of application via the Radius protocol or via a proprietary Payment Plugin. As a

central element in the network, Charging@vantage is responsible for controlling and

monitoring of entire charging transactions: A Charging transaction is defined as the process

from the initiation of the charge request until its final confirmation.

The Prepaid@vantage is the Siemens market leading solution for SS7 session. It offers online

charging and many others attractive features. It provides real-time rating and charging of SS7



sessions and events for prepaid subscribers in fixed networks, 2G, 2.5G and 3G networks as

well as real-time monitoring for the accounts.

Thanks to their modularity, both solutions were embedded together in only one cluster server

machine and were established as the Charge@once. The figure III.1 represents the functional

blocks in a Charge@Once solution:

Figure III. 1: Functional blocks in a Charge@Once solution.

II Communication with the Payment Plugin In order to facilitate the communication between the external server and charging@vantage in

Intelligent Network, Siemens provides a payment Plugin. Payment requests coming from this

server will be delivered to the charging@vantage via the Payment Plugin.

All transaction requests for a Subscriber account are coming from the web server system to

the IN via the payment plugin.



As described in previous chapter, the Payment Plugin is a client of the Charging@vantage. It

provides an HTTP-based interface for web-based applications and allows these applications to

send requests to Charging@vantage in IN. after receiving the request Payment Plugin

transfers this message to IN using CORBA communication and return the result to client.

We concentrate in this part to the HTTP Interface of the Payment Plugin to design the

communication with the IN via this interface.

The simulator is a web client for testing and it has to use the web based solution offered by

Payment Plugin. The web-server-based application has to provide all the parameter values

which are required in the IDL interface specification as name/value pairs. These name/value

pairs (GET or POST requests) from web-based applications are mapped to CORBA

parameters for the call at the payment interface. Result values are also coded in this way.

II.1 Message flow

II.1.1 Read Account balance: used in Recharge and M2M operation Before doing any operation the simulator must take same information related to the concerned

subscriber. It sends a request to the Payment Plugin to take this information. In the request

message the parameter “ProductId” must take the value “VoMS_Account_Info” that means

the request is a get_subscriber_info. The others important parameters to input are the

“ConsumerId” that specifies the subscriber number in question and the “ConsumerAccountId”

to ask the account info on IN, the list of the subscriber account on IN and related

confirmation. This list includes; Main Account, SMS Account and MMS Account.

II.1.2 Recharging Operation confirmation “read Account balance” After receiving the request from the VoMS, the Payment Plugin sends it a response that

includes the requested information about the subscriber identified by his “ConsumerId” and

his Account identified by “ConsumerAccountId” parameters. This information is very

important for the simulator to decide if it can continue the transaction or not.

The Transparent Data returned comprises a field which indicates whether the subscriber is

locked or not, the Simulator extracts these fields and decides the other state.

II.1.3 Recharge Operation: used in Recharge and M2M After tacking the information about the subscriber from the response of the Payment Plugin,

the simulator decides if the Recharge operation is possible or not: if subscriber account isn’t

locked this operation is possible and the simulator sends a Recharge message to the Payment



Plugin and waits the confirmation. The input parameters that must be specified in this

Recharge operation are; the “ConsumerId”, the “ConsumerAccountId”, the “ProductId” which

must take the value “VoMS_Recharge” and the “Money.Amount” that indicates the value to

recharge.

The recharge concerns a main account, an SMS account or an MMS account, in all cases the

money amount will be in currency in this operation.

II.1.4 Recharging Operation confirmation “Recharge” After receiving the request from the simulator, the Payment Plugin sends it a response that

indicates whether the recharge operation is terminated successfully or not, it includes the

requested information about the subscriber identified by his “ConsumerId” and his Account

identified by “ConsumerAccountId” parameter. If the operation succeeds the message

parameter “RechargedMoney.Amount” takes the money or units, which has been recharged to

the consumer’s account, else its value takes 0. This information is very important for the

simulator to know whether recharge succeeds or not.

II.1.5 Charge Operation Like the others operations charge needs a message flow between the simulator and Payment

Plugin, as known this flow begins by a request message to take subscriber’s situation, then if

subscriber account is enabled and its current balance is sufficient the simulator continues its

operation else it declares an error that indicates the not availability of this transfer.

The requests of the Mobile to Mobile process are treated independently. So in case of error

(system, communication, etc), the recharge may be partially done. For example successful for

debit operation but not processed for credit operation. No fallback or retry processes are

proposed.

II.1.6 Recharging Operation confirmation “Charge” Similar to description in paragraph (I.1.4) the simulator receives a confirmation that indicates

whether the charge is done or not, as well as the new account balance.

II.1.7 How to grant a bonus? If a subscriber recharges his main account he can be granted some bonuses in his different

accounts of the list that he owned. This action is attributed to IN after each recharge

operation. In purpose parameter of recharge message user indicates by Bonus Program

Indicator whether bonus accounts; Main Bonus, SMS Bonus and MMS Bonus are considered



or not. If Bonus Program Indicator is “1” after finished successfully recharge process, IN

continue recharging bonus account beneficed by the subscriber.

III. Communication with the SS7 Protocol Handler

III.1 What is the protocol handler? The Protocol handler is one of the most important components in a Charge@Once system. It’s

an interfacing layer between the SS7 network protocols and the running application that

handles the service logic. The protocol handler as acting as a translator that enables the

Charge@Once to understand the signal inside the protocol massages. This component is

meant to support a huge amount of communication protocols (CAP, INAP, MAP…).

The protocol handler layer is linked to the network through the software OMNI from Ulticom,

this software implement the SS7 stack.

III.2 OMNI gateway The OMNI software provides the implementation of the software that will handle the SS7

stack; this is done in 2 methods:

• The first is 100% SS7, which mean that the application protocols (CAP or MAP…)

are encapsulated in an SS7 frame that will be transferred through the physical part of

an SS7 network. A second interesting interface is based on the TCP/IP protocol; in this

case the application protocol will be encapsulated in a TCP/IP packet.

• The second interface is based on a special process called OMNI Gateway. This

process is attached to OMNI and binds to the SCCP layer. In case it’s triggered by an

adequate TCP/IP message, the OGW extract the data unit from this packet and treat

this unit as a TCAP message then it passes it to the SCCP in OMNI, and vice versa.

III.3 Typical message flow We have to describe in this part the message flow of a mobile originating call using

CAP/INAP protocols. A user (A-party) is able to originate a voice call from his mobile

terminal and is charged for the call duration (time based) from his prepaid account.

The chronological events are described by the following steps [12]: 1. The A-party originates a call from his mobile terminal.



2. The Home Mobile Switching Centre (MSC) is triggered and performs an initial service

request to Prepaid@vantage (or charge@once).

3. Upon receipt of the service request, Prepaid@vantage (or charge@once) performs

a. Screening

b. Rating and Tariff Determination

c. Charging and Balance Management

4. Prepaid@vantage (or charge@once) grants the service access to the MSC by providing

quota units (time based), and requests the MSC to monitor the call states (e.g. busy, no

answer, disconnect).

5. The MSC connects the call to the B-party.

6. The MSC monitors the call and reports changes of the call states to the Prepaid@vantage

(or charge@once). In case the granted units are consumed (granted time threshold is reached),

the MSC requests the Prepaid@vantage (or charge@once) to grant a new quota.

7. Prepaid@vantage (or charge@once) completes the charging of the reserved account portion

and prepares the granting of a new quota, i.e. performs

a. Charging and Balance Management

b. Rating and Tariff Determination

c. Charging and Balance Management

8. Prepaid@vantage (or charge@once) grants the further service access to the MSC by

providing new quota units (time based) and requests further monitoring of the call states.

The granting cycle of a new quota (items 6, 7, 8) is repeated until the user’s account balance

is exhausted or the call is disconnected.

9. The call is disconnected.

10. The MSC reports the change of the call state to Prepaid@vantage (or charge@once), and

provides the consumed time.

11. Prepaid@vantage (or charge@once) completes the charging of the last account portion,

i.e. performs

a. Charging and Balance Management

12. Prepaid@vantage (or charge@once) instructs the MSC to release the call.

13. The MSC releases the call.

The scenario is described by figure III.2.



Figure III. 2: MOC via CAP/INAP (Reservation Scenario).

IV Design steps

IV.1 Requirement specifications of the protocol simulator The protocol simulator will be used as a test tool able to trigger the IN through one of its

interfaces: via SS7 or via IP. It’s meant to simulate the behaviour of the network components

that are in interaction with the IN: such as the MSC/VLR, HLR, SMSC, MMSC, VoMS…

In this paragraph we will enumerate the set of requirements that it’s necessary to respect and

to answer in our design.

1. The simulator must be as modular as possible: this will make it easy to update or to

change or even to extend any of its features.

2. The simulator must be able to reproduce any given scenario, this means by the

designed simulator, we can introduce some command to wait for a certain signal, test a

signal contents, alert in case of error…: This will make it possible to troubleshoot

some network faults on IN side or out of it.



3. The protocol description that will be simulated has to be written out of the source code

of the simulator: this will make it easy to add a new version of protocol or to replace

an existing one.

4. The protocol simulator should interact with any of the both functional blocks for the

charge@once system SS7 service logic or IP based service logic.

IV.2 Structure of the simulator

IV.2.1 Architecture To communicate with IN through its different interfaces, different components are needed.

Each one intervenes in the communication with a specific role.

The general architecture is given by figure III.3.

Figure III. 3: Architecture of the proposed solution.

IV.2.2 Role of the different components

IV.2.1.1 Scenario Manager The module scenario-manager will be the interface between the main simulator engine and the

user. This module is aimed to enter a desired scenario represented by a set of instructions that

the simulator has to compile and forward them to the main engine.



The instructions will represent a set of messages to be exchanged with the IN and their

corresponding arguments (for example: send_idp(cgpa,cdpa,ServiceKey…). They could be

also some instructions to command the behaviour of the simulator (start a timer, end a timer,

alert, exit, test an argument inside a message …).

The scenario script is a text file that will contain the communication flow with the parameter

that need to be applied. The script file will be divided into 2 parts: Script header and Script

body.

The script header will contain global declaration like for example the protocol family

(CAP02, CAP01…), and also the fixed parameters like for example the nodes addresses and

the values for the timers.

The script body will be between BEGIN and END and will contain the communication flow

with the micro parameter for the exchanged message.

The instruction inside the script body and the script header will be written using a keyword

dictionary that we have to define during our development.

IV.2.2.2 Protocol engine The answer to the requirement of separating the protocols description and also to make it

possible to extend the protocol database, we agreed that the better solution is to represent the

protocol message with a standardized way. Our choice was to use the ASN.1.

We have to describe, in this part, the ASN.1 and its message form.

Firstly, ASN.1 is an international standard which aims at specifying of data used in

telecommunication protocols. It is a computing language that is both powerful and complex: it

was designed for modelling efficiently the communication between heterogeneous systems.

ASN.1 is used in describing messages to be exchanged between communicating application

programs. It provides a high level description of messages that frees protocol designers from

having to focus on the bits and bytes layout of messages. ASN.1 has since been adopted for

use by a wide range of other applications, such as in network management as cellular

telephony.

Closely associated with ASN.1 are sets of standardized encoding rules that describe the bits

and bytes layout of messages as they are in transit between communicating application

programs. Neither ASN.1 nor its encoding rules are tied to any particular computer



architecture, operating system, language or application program structure, and are used in a

range of programming languages, including Java, C++ or C.

The first encoding rules associated with ASN.1 were the basic encoding rules (BER). The

BER transfer syntax has the form of a triplet (type, length, value) or TLV where type (also

called tag) is a code that identifies unambiguously the transmitted data type, length is the

number of bytes necessary for encoding the value and value is the actual ASN.1 value

encoding. In ASN.1, this “unique identification code” of every type is called a tag.

The constructor SEQUENCE:

The constructed type that is the most commonly used by computing languages is that which

provides an ordered series of elements (or components) of different types. In ASN.1, this

structure is introduced by the keyword SEQUENCE and every component is denoted by a

word beginning with a lower-case letter called an identifier:

Client ::= SEQUENCE { name PrintableString (SIZE (1..40)),

postcode NumericString (SIZE (10)),

country PrintableString (SIZE (1..20))}

The constructor CHOICE: The constructor CHOICE gives the choice (also called `union')

between several alternatives:

Quantity::= CHOICE {units [0] IA5String,

Millimeters [1] IA5String}

An alternative is denoted by an identifier, which is a word beginning with a lower-case letter.

This identifier is not encoded and it makes it possible to build unambiguous abstract values;

for this reason, the identifiers of a CHOICE type must be distinct. A BER decoder will rely on

the received tag to determine the alternative that has been chosen and decode the value

according to this alternative.

ASN.1 compiler: A compiler is a computing tool that reads a program written in a first

language, called `source language', to translate it into a second language called `target

language' (this language is closer to the machine architecture; it is often assembler or some

machine-oriented language). The source language is ASN.1, the target language is generally

C, C++ or Java, and the `program' is a specification made of several modules linked by



IMPORTS clauses. In this respect, an ASN.1 compiler would better be considered as a stub

compiler [15].

Encapsulate message:

After selecting the designed protocol, the protocol engine encapsulates the message using this

protocol. We have to represent, in this part, the communication protocols and the

encapsulating message steps: Communication protocols are organized in layers. Each layer gets messages from a layer

above (PDUs), wraps them with its own overhead information and sends them to the

underlying layer. In the reverse way a layer gets messages from the underlying layer, removes

its overhead and forwards them to the layer above.

The script is responsible for the PDUs of the layer to simulate (layer n). The PDUs created by

the script are inserted as SDUs in a message of the lower layer by the simulator. In the reverse

direction only the PDUs of the messages received by the simulator are delivered to the script.

Script

Sim ulator SDU

PD U

PD U

Figure III. 4: Insertion of a SDU into the PDU of the lower layer. It is possible to transmit multiple PDUs of layer n in one PDU of layer n-1 if the simulated

protocol supports such features (e.g. multiple SINAP-Operations in a TCAP-message) as

shown in figure III.5.

Script

Sim ulator

PDU

SDUSDU

PDUs

Figure III. 5: Multiple SDUs in one lower layer PDU.



The transmission of a message to the other side from a script is done in two steps:

• Pass one or more PDUs to the simulator.

• Transmit the message to the other side.

In the opposite direction, if a received PDU of layer n-1 includes multiple PDUs of layer n,

each PDU is sent to the script as a single receive event. From the view of the script there is no

difference, whether the PDUs were transmitted together or separately. For example: The

SINAP-Simulator does not use TCAP messages as receive events but single operations from

the component portion. If the component portion contains e.g. three operations three receive

events are sent to the script.

Normally the mentioned principles are sufficient for the assembly of the messages. But for

special problems the tester may need access to parameters of lower layers. For this the

simulator can provide simulator variables, which correspond to these parameters. An access to

these parameters is realized by an access to the corresponding variables. More description is

given by figure III.6.

Script

Simulator

PDU

SDUSDU

PDU

Param

SimVar

Figure III. 6: Access to parameters of a PDU of a deeper laying layer.

IV.2.2.3 Simulator Main engine The module simulator Engine is the main coordinator between all the simulator parts, it

receives the compiled script from the scenario manager, convert the instructions into PDUs. It

load from the protocol database the required protocol ASN.1 description then replaces the

variable parts by the values taken from the script and finally prepare the PDU that will be

communicated to the Simulator Gateway.



IV.2.2.4 Simulator Gateway Simulator Gateway is the interfacing modules between the Simulator core and the IN system.

After preparing the message to send, it has to deliver it to the specified interface.

According to script header the Simulator Gateway decides which interface will be used:

• If the communication is with the payment plugin, the Gateway module loads the

HTTP library, opens the required connection to the remote system (payment plugin

system) then prepares the method POST and GET that will be used to exchange the

messages between the simulator and the remote system.

• If the communication is via SS7 interface, the Simulator Gateway loads another

library that will handle the communication through the sockets. It will open the

required port and prepare the required input and output buffers that will be used to

exchange data with the remote OGW.

IV.3 Simulation via IP interface

IV.3.1 HTTP Simulation The simulation script that will be used will look like the following extract:

[HEADER]

Protcocol=HTTP; PayPluginIP=10.1.1.123; PayPluginPORT=8080;

PayPluginURL=http://PayPluginIP:PayPluginPORT/PaymentPlugin/servlet/PaymentPluginServlet;

[BODY] BEGIN Prepare_<MsgName>(arguments); Start_timer(<value_of_timer>);

Post_<MsgName>; Get_<Msg_answer>; If No_Get then Alert; Test_ExecutionStatus; …

END

The architecture of a simulation via Payment Plugin is given by figure III.7.



Figure III. 7: HTTP Simulation architecture.

IV.3.2 Possible transactions The transaction concerns a main account, an SMS account or an MMS account, in all cases

the money amount will be in currency in this operation. The user has to specify the account

type to recharge, the SubscriberID, the Money Amount and the others parameters of the

message and then sends message to the IN and waits the result returned.

IV.3.2.1 Main Recharge A successful main recharge needs four exchanged messages. Others bonuses can be beneficed

by the subscriber. Normally after each recharge a telecommunication operator can offer more

than main bonus an SMS bonus and MMS bonus. A value in purpose parameter of recharge

message is fixed to authorize to IN to recharge a bonus account.

A message flow of a successful recharge operation is described by the figure III.8.



Figure III. 8: Main Recharge Message Flow.

IV.3.2.2 SMS Recharge Each subscriber can own an SMS account which make possible to recharge this account

independently. No bonus is considered in this type of recharge. As described in previous flow,

this operation needs also same necessary information about the subscriber’s account before

recharging it. A first message “Read Account message” is sanded to IN via Payment Plugin to

request about the account state. According to the response returned by the IN, the simulator

decides the next step.

The message flow of a successful recharge operation of an SMS account is given by figure

III.9.



Figure III. 9: SMS Recharge Message Flow.

IV.3.2.3 MMS Recharge Because the MMS account has a common behaviour as the SMS account, the same scenario

of an SMS recharge is needed by an MMS recharge. This operation needs also to take

information about the account before recharging.

The message flow of a successful recharge operation of an SMS account is given by figure

III.10.



Figure III. 10: MMS Recharge Message Flow.

IV.3.2.4 Transfer An amount transfer concerns a Mobile to Mobile recharge operation. this feature needs two

transactions; a charge operation from a subscriber account A and a recharge operation to a

subscriber account B of same type, each operation needs a request to take account’s

behaviour.

Thanks to the definition of the interface, M2M involves no modification of life cycle nether

recharge bonus. Only one account per M2M may be realized: no several accounts in the same

M2M operation.

The requests are treated independently. In case of error, the recharge may be partially done.

By example successful for debit operation but not processed for credit operation and no

fallback or process are proposed only after each message the simulator waits the confirmation

before sending the next message.

Neither Main Bonus nor SMS and MMS Bonus are considered in Mobile to Mobile process.



No life cycle changing in this operation, so the expiry date doesn’t change in the two

accounts. A message flow of a successful transfer is shown in figure III.11.

Figure III. 11: Transfer Message Flow.

IV.3.2.5 MMS Authorize The authorizeAmount request is used if deferred payment or payment in instalments is

requested. This operation comprises the following transactions:

• Authorizing and reserving an amount of money.

• Executing the first rate for payment in instalments.



If the Payment server receives an authorizeAmount request via the CORBA interface, it

checks the transaction status. When the authorizeAmount request has been processed

successfully (the requested amount of money is successfully reserved from the SCP), the

transaction status is set to authorized.

If finalizeAuthorization is false, the currently authorized sum of money can be increased by

this value. The currencies of money and moneytoAuthorize must be the same. The

additionalMoneyToAuthorize parameter comprises amount and currency.

MMS Authorize operation concerns MMS account. It authorizes and reserves a number of

MMS unit if it’s available. Some parameters are different than a recharge message and others

are added. The message flow is given by figure III.12.

Figure III. 12: MMS Authorize Message Flow.

IV.3.2.6 MMS Capture The captureAmount request is used if payment with separate authorization and reservation is

requested. This operation comprises the following transactions:



• Transferring the required amount of money from the source to the target

(virtual) account

• Reducing the amount of currently authorized money within its transaction

context

• Either authorizing an additional amount of money or finalizing the

authorization (ending the transaction).

These transactions are done by IN after receiving a captureAmount message. This operation is

applied to MMS account.

If any number of captureAmount requests is received via the CORBA interface while the

transaction status is authorized, the transaction status is changed to capture Requested.

If the captureAmount requests can be processed successfully, the transaction status is set

again to authorized. For the final capture of the transaction, the status is set to processed.

If failures occur during the processing of authorizeAmount or captureAmount requests, the

transaction status is set to failed.

If the final captureAmount operation has an ExecutionStatus of -109 or -103, it depends on

the result of the getTAState request on how to proceed:

• Transaction status = processed: the operation was successful; the reserved money has

to be recharged to the consumer account using the rechargeAmount operation.

• All other transaction status: the operation has not been successfully processed; the

reserved money was not consumed and will expire. An automatic recharge takes

place. Indications on the reason of the failure are stored in the tickets and in the

recovery log (PTA result files).

The scenario is similar to the others transactions. A first request is sanded to IN. According to

the response returned, the simulator decides if it can continue the transaction or not.

The message flow of a successful operation is represented by the figure III.13.



Figure III. 13: MMS Capture Message Flow. IV.4 Simulation through SS7 interface

IV.4.1 INAP/MAP Simulation

The IPS supports lots of INAP an MAP version.

The IPS is the same for all; the specifics are in the user part packages (protocol versions).

This means the IPS provides the TCAP layer, the INAP/MAP layer is in the scripts.

The scripts dial with:

• Prepare dialog portion

• Prepare components

• Sending the messages

• Wait for components

• Evaluate and check parameters

The INAP/MAP scenarios provide a lot of automatic features for the script writer. The goal is

to keep the scripts simple, clear and safe:



• Chooses the TCAP message type: the first message is sent as BEGIN all following

as CONTINUE

• Manages the transaction and invoke IDs

• Answers dialog requests: per default sends a DialogAccept with the same

ApplicationContextName as reaction on a DialogRequest. This means: Outgoing

scripts setup the DialogRequest, incoming scripts don’t have to do anything.

• Answers dial.

• Adds a DialogAbort to a UserAbortInfo from the script if the dialog was created

with DialogRequest.

• Aborts TCAP transaction on script failure. The architecture of a simulation via SS7 interface is described by figure III.14.

Figure III. 14: Simulation over OGW architecture.

IV.4.2 Exchanged message In this part, we represent same exchanged messages. We need only to define the messages

that we use in simulation.

IV.4.2.1 Operations Description InitialDP:

Direction: from MSC to Charge@once.



This operation is used to indicate request for service.

Connect:

Direction: from Charge@once to MSC.

This operation is used to request the MSC to perform the call processing actions to route or

forward a call to a specified destination. To do so, the MSC may or may not use destination

information from the calling party (e.g., dialled digits) and existing call setup information

depending on the information provided by the Charge@once.

ApplyCharging:


This operation is used for interacting from the Charge@once with the MSC CSE-controlled

call duration charging mechanism.

CallInformationRequest:


This operation is used to request the MSC to record specific information about a single call

and report it to the Prepaid@vantage (with a CallInformationReport operation).

RequestReportBCSMEvent:


This operation is used to request the MSC to monitor for a call-related event (e.g., BCSM

events such as answer or disconnect), then send a notification or request for instructions back

to the Charge@once when the event is detected.

ApplyChargingReport:


The ApplyChargingReport operation provides the feedback from the MSC to the

Prepaid@vantage for the CSE-controlled call duration charging mechanism.

CallInformationReport:


This operation is used to send specific call information for a single call to the Charge@once

as requested by the Charge@once in a previous CallInformationRequest.

EventReportBCSM:


This operation is used to notify the Charge@once of a call-related event (e.g. BCSM events

such as answer or disconnect) previously requested by the Charge@once in a

RequestReportBCSMEvent operation.



We can notice that four messages are sanded by MSC to Charge@once: InitialDP,

ApplyChargingReport, CallInformationReport and EventReportBCSM. These messages will

be sanded by the simulator to Charge@once.

IV.4.2.2 Message flow A first message InitialDP is sanded by the simulator to request the Charge@once for service.

Same parameters are optional and no need to indicate them. Others parameters are entered by

user in the dedicated interface. An example of message flow for Mobile Originating Call is

shown by figure III.15. The quota units is 10 mn.

Figure III. 15: Message flow for Mobile Originating Call.

IV.4.3 Program description The user has to enter the CalledParty and the CallingParty. Then his starts the simulation, the

scenario is described by the following steps:



• The simulator sends a first message to IN (InitialDP) to request for a service and

waits.

• The Charge@once checks the Calling Party account state, two cases are possible:

If the account has a sufficient amount for a first call, the Charge@once returns an

ApplyCharging message (AC), a CallInformationRequest (CIRQ) and a

RequestReportBCSMEvent. With these messages the Charge@once grants the service

access to the simulator by providing quota units.

If the account state doesn’t permit a communication because the user’s account

balance is exhausted or others reasons, the Charge@once returns an error message to

the simulator.

• If it’s the second case, the simulator declares an error to user.

• If it’s the first case, the simulator doesn’t have to connect to Called Party or to wait for

the 10 mn given by the Charge@once as quota units. It returns an

ApplyChargingReport message to provide the feedback to the Prepaid@vantage for

the CSE-controlled call duration charging mechanism.

• The Charge@once provides a new quota units and requests further monitoring of the

call states. The granting cycle of a new quota is repeated until the user’s account

balance is exhausted or the call is disconnected.

• If the user’s account balance is exhausted, the last ApplyCharging indicates that it’s

the last quota units: final forced.

• The simulator sends threes messages to Charge@once: EventReportBCSM,

CallInformationReport and ApplyChargingReport to request the Charge@once to

apply the charge operation.

• In case that the user disconnects the call the simulator sends threes messages to

Charge@once: EventReportBCSM, CallInformationReport and ApplyChargingReport

to request the Charge@once to apply the charge operation. It indicates the time

consumed from the last quota units.

The scenario is described by the diagram in figure III.16.



Figure III. 16: Simulation diagram.

Conclusion During this chapter we went through the design steps that allowed us to define the architecture

of the simulator and the relationship between its components. The designed solution feat

exactly the requirement that we got at the beginning, furthermore and thanks to its modular

architecture it could be extended with new features and with new protocol descriptions.

The development step that will be the subject of the next chapter will describe our choices, the

assumptions and the limitations that we faced.



Chapter IV Simulator Development

And Result Validation



Introduction After specifying simulator behaviour in previous chapter, we attack now the structure of the

simulator and how it works. We develop our application using Java for many reasons. After

realizing the simulator we try to connect to IN for test and validation in a last step. This

application is intended to society usage, for this reason it must have a clear interfaces for easy

using. After studying our requirements and objectives that the simulator must attend, we

decide to program with Java.

This chapter describes communication methods and summarizes the results found in test of

our application.

I Simulation process The simulation process will define the different steps that must be taken in order to prepare a

clean simulation:

1. Define the simulation objective: In this step the user has to define the aim of his simulation,

this mandatory in order to make it easy to define the different operation and instructions that

will build the communication flow between the IN and the simulator.

2. Convert the objectives into a simulation script: The script will translate the simulation

objectives into instructions and tests.

3. Parse the script and Run the simulation: This is a required steps that allow the user to be

sure about the script contents.

4. Analyze the results: At last the result must be analyzed and compared to the initial

objectives.

To implement such process that will run on the simulator architecture that we’ve already

defined in chapter 3, we will use many libraries and more then one programming languages.

The following paragraph will argue for our choices.

II Realization of the different components

II.1 Scenario Manager The scenario manager will implement at the same time a text editor and parser. The parsing is

done once the script is finished, it will test the syntax of the script file and check the



compatibility of the introduced arguments with the types of the arguments from the protocol

description. This is the list of tests to be done:

1. The instructions are compliant with the chosen protocol (for example we cannot send and

IDP through the HTTP or a CaptureAmount through the SS7)

2. A script must contain HEADER and BODY

3. The BODY must be between BEGIN and END

4. Each instructions finish with a “;”

II.2 Protocol engine The protocol engine is based on a protocol description database. This database will store the

message set of a particular protocol. Each protocol will be stored in a dedicated folder

labelled by the name of the protocol. Inside this folder we will write all the ASN.1 description

of the set of messages. Each message will be represented by a file that is labelled as the name

of the message and end with the file extensions “.asn1”.

In case the protocol doesn’t require the ASN.1 representation (like for instance the HTTP) the

folder will contain the message format and the type of the arguments (column mode

representation).

An important part of the development of the protocol description database is an ASN.1

compiler: the role of this component is to translate an ASN.1 message from the ASN.1

representation into PDUs.

II.3 Simulator Gateway The simulator gateway will be based on two libraries: the first is an implementation of the

HTTP protocol library and the second is the TCP/IP Socket implementation library.

II.4 Final Workflow The following figure (figure IV.1) depicts the final work Flow that will implement the agreed

simulation process.



Figure IV. 1: Final Work Flow of the simulation process.

III User Interface

The following figures depict the main interface for the simulator, it contains mainly two parts

the simulation via the SS7 interface and the simulation via the payment plugin. The user

chooses the required interface and some defaults values will appear on the screen. At that

point in time the user has certain scenario preconfigured or he can simple choose to edit the

script that will be used to communicate with the IN.

After choosing the interface to use, the user has to click to button “Run the simulation” to

pass to the next step.

The figure IV.2 shows the simulation via the SS7 Interface and the figure IV.3 shows the

simulation via Payment Plugin Interface.



Figure IV. 2: Simulation via the SS7 Interface.

Figure IV. 3: Simulation via the Payment Plugin Interface.



IV Communication on the http interface This solution permits to communicate with charging@vantage over Payment Plugin using its

http interface. We try, with this simulation, to test the IN by different types of transaction.

IV.1 Connecting with Intelligent Network For start we have to establish a connection to the IN over Payment Plugin and bind with the

appropriate credentials. The connection is over TCP/IP link and use HTTP protocol. After

sending any message of transaction, we have to wait the result. To send a message and receive

the response the following steps are persistent:

1. An URL is needed in witch we specify the address of the host containing the Payment

Plugin and the port reserved to this communication.

2. Make message’s parameters in one message contained the URL in the hand.

3. Make the group in a pointer to a "resource" on the World Wide Web.

4. Build a connection to this URL and send the request.

5. Display some additional information:

Request Method: using the method defined in JAVA class “getRequestMethod ()”.

Response Message: using the method defined in JAVA class “getResponseMessage ()”.

Response Code using the method defined in JAVA class “getResponseCode ()”.

6. Get an InputStreamReader to read the response returned by the Payment Plugin.

7. Use a BufferedReader to the defined InputStreamReader.

8. Read the response from the Payment Plugin line by line to discover transaction’s

result.

9. Display the response in User Interface.

10. Close BufferedReader.

Any exception as an URL error or connection error is returned in a message.

IV.2 Preparation done on the charge@once To be able to connect through the payment plugin to the IN some steps needs to be performed

on the IN in order to make it recognizes our messages. These steps are mainly the declaration

of the subscriber and on its provider to which it belongs.

Product ID to be used: This is done through an internal configuration tool for the

Charge@once called SMAF GUI (Service Management Access Function).



Figure IV. 4: IN@vantage management Interface.

IV.3 Transaction’s test When the Charging@vantage server confirms the execution of a request, it returns the original

TransactionID and an execution status indicating whether the request was successful. It is

enhanced confirmations include a string field containing transparent data with additional

information about the execution of a request, e.g. rating information or the new expiry date.

The usage of enhanced confirmations is specified in the Payment Plugin configuration

parameters. We use this information to judge whether the transaction succeeds or not.

The TransactionID parameter is an identifier of each transaction. An error is returned if a

transaction has the same TransactionID of another transaction. For this reason we have to

change the TransactionID parameter in each operation.

If we select “VoMS Simulator” in the Simulated Scenario field in the interface given by

figure IV.3, the User Interface given by figure IV.5 is displayed. We have to specify the

recharge type and full up the concerned fields.

II.2.1 Main Recharge

To test whether the transaction succeeds or not, we have to read from IN the state of the

account before recharging and to determine the old amount. After recharging a message



received from IN indicates the new account state as well as the recharged amount. But to

check the result we read the account again; if the recharged amount is added to the old amount

the transaction is done successfully.

The same scenario is repeated in SMS recharge and MMS recharge, only the account is

changed.

The user interface used in this transaction is shown in figure IV.2. The user has to choose the

transaction type by checking it, to full up the TransactionID, the ConsumerID and the money

to recharge. After then the message is sanded to IN by clicking to button “Send”. We test this

transaction and the result returned by IN is shown in Result file in figure IV.5.

Figure IV. 5: Recharge transaction.

The result returned by IN indicates that RechargedMoney.Amount = 10. This information

means that the transaction was done successfully because it’s the same amount that we

recharge. It’s indicated by user in the Money.Amount field.

II.2.2 Direct Recharge

A recharge message has different parameters; many of them are static in all operations as

money currency which is fixed to TND. For this reason we don’t need to full up all



parameters in each operation. But to make the simulator opened to each changing, an interface

contained all parameters must be defined. Static parameters are initialized in correspond fields

and enabled to be changed. A test result, using an interface of direct recharge contains all

parameters, is shown by figure IV.6.

Figure IV. 6: Direct Recharge transaction.

As described in the previous transaction, we check the operation result by comparison

between the value entered by user (Money.Amount) and the value of

RechargedMoney.Amount returned by IN. In this case it is the same value (= 12) for the same

TransactionID (=21). This indicates also that the recharge succeeds.

II.2.3 Transfer

To test a transfer transaction we have to read the two considered accounts in this operation.

Firstly we determine the old amounts of the two accounts. After the transfer we have to check



the new amounts; the one of the recharged account must be increased by recharged amount

and the one of the charged account must be decreased by the same amount.

Figure IV. 7: Transfer transaction. II.2.3 MMS Authorize and MMS Capture

If we select “MMSC Simulator” in the Simulated Scenario field in the interface given by

figure IV.3, the User Interface given by figure IV.8 is displayed. We have to specify the

RequestType and full up the others fields and start simulation by sending the message.

In the MMS Authorize and MMS Capture the transparent data returned by the IN is empty.

We have to judge whether the transaction succeeds or not according to the TransactionID and

the ExecutionStatus parameters. If the returned message contains the same TransactionID that

we entered and the ExecutionStatus = 1, the transaction is down successfully. All others forms

of returned message indicates that the transaction is failed.

A result of the MMS Capture transaction is given by figure IV.8.

The same result is returned in case of MMS Authorize test.



Figure IV. 8: MMS Capture transaction. II.2.5 Conclusion After develop the http communication part of the simulator, we test its functionalities by

making it in communication with IN. the different transaction are done. We find some errors

in program that we correct them in each step until validate the result. We try, in the next part,

to describe the communication on SS7 interface and to find same results.

II.3 Historic management After each transaction, a result is returned by the IN. For a control reason it is needed to save

all the results returned. After a first connection to IN the simulator opens a log file to save the

result of each transaction. Error results are also saved in the file.

III Communication on the SS7 interface This solution permits to communicate with Charge@once using SS7 interface. The simulator

takes the role of MSC. It simulates it using the same scenario: sending the same messages to



Charge@once and receiving the responses. But we need only to test whether the IN replies to

a request or not. We don’t need to exchange all this messages.

III.1 Preparation done on the charge@once In case of the simulation through the SS7 interface some steps needs to be done on the

charge@once system, these steps concern mainly the configuration of a virtual node on the

SS7 address table. This step is done via a dedicated internal interface called @vantage

Commander. To declare a virtual node that will be simulated by the tool the following

information has to be entered:

• Node address

• Node name

• Default protocol

• Node type

• And many other parameters…

Figure IV. 9: @vantage Commander Interface.

The last step is to launch the Omni Gateway with the required argument. For example the

following command will launch an OGW process on the IN that will assume the local address

as 200, the subsystem number as 146 and the TCP/IP port that will accept the PDUs as 10050 ogw -o 200 -s 146 -p 10050 -node N1 -b2b >/dev/null



III.2 Coding of the Camel Messages III.2.1 Rules and Recommendations

The encoding rules which are applicable to the defined abstract syntax are the Basic Encoding

Rules for ASN.1, defined in CCITT Recommendation X.209 and ITU-T Recommendation

X.690 [13] [16].

The ASN.1 representation of different messages sanded by the simulator to the Charge@once

is given by Appendix A.

III.2.2 Example for the InitialDP message

The InitialDP operation is used after a TDP to indicate request for service. It is sent by the

MSC after detection of a TDP-R in the BCSM, to request the Prepaid@vantage for

instructions to complete the call. The message comports the following parameters [13]:

Parameters

serviceKey: This parameter identifies for the Prepaid@vantage unambiguously the requested

IN service. It is used to address the correct application/SLP within the Prepaid@vantage (not

for Prepaid@vantage addressing).

callingPartyNumber: This parameter carries the calling party number to identify the calling

party or the origin of the call. The encoding of the parameter is defined in ETS 300 356-1.

callingPartysCategory: Indicates the type of calling party (e.g., operator, pay phone, ordinary

subscriber).

locationNumber: This parameter is used to convey the geographical area address for mobility

services. It is used when "callingPartyNumber" does not contain any information about the

geographical location of the calling party (e.g., origin dependent routing when the calling

party is a mobile subscriber).

highlayerCompatibility: This parameter indicates the type of the high layer compatibility,

which will be used to determine the ISDN-teleservice of a connected ISDN terminal.

eventTypeBCSM: This parameter indicates the armed BCSM DP event, resulting in the

InitialDP operation.

IMSI: IMSI of the mobile subscriber for which the CAMEL service is invoked.

locationInformation: This parameter indicates the whereabouts of the MS, and the age of the

information defining the whereabouts.



ext-BasicServiceCode: Indicates the Basic Service Code.

callReferenceNumber: This parameter gives the network call reference number assigned to

the call by the GMSC/MSC.

mscAddress: This parameter gives the mscId assigned to the GMSC/MSC. calledPartyBCDNumber: This parameter contains the number used to identify the called party

in the forward direction. It may also include service selection information. This parameter

shall be sent only in the MO case.

timeAndTimezone: This parameter contains the time that the gsmSSF was triggered, and the

time zone that the invoking gsmSSF resides in.

We try to describe the encoding rule of an initialDP operation. The ASN.1 representation of

the initialDP message is given by Appendix A.

The encoded message of an InitialDP is given by Appendix B.

To send the message, we have to create a TCP connection to the specified host and port using

socket. The message is sanded to IN and the result is returned indicates a response to the

request. We use an Internal Message Analyser to decode the received message…….

III.3 Test results

To test the simulation on SS7 interface, we use the dedicated interface. We choose, firstly, the

simulation on SS7 Interface, and then we fix the protocol to use. We enter a Calling Party and

a Called Party (two Subscriber numbers used for test) and we start the simulation.

The simulator will send the CAP02 messages and receives the answer from the IN. As shown

in the figure bellow the hexadecimal dump for the exchanged messages are also shown, this

dump could be used for debugging issues.

For example the message ERB sent from the Simulator to the IN, contains the dump:

65 25 48 04 0a 00 40 27 49 04 40 36 05 cd 6c 17 a1 15 02 01 02 02 01 18 30 0d 80 01 09 a3 03 81 01 01 a4 03 80 01 01 This could be debugged as the following:

65 TAG

25 Length = 37 Octets

48 TAG for the Origination Transaction ID



04 = Length

0a 00 40 27 = Value

And so on…

Figure IV. 10: Main Interface of SS7 Simulation.

IV Advantages of the Simulator The simulator that we developed has fulfilled the initial requirements. Furthermore by its

modular architecture it could be extended with new protocol description and news

interfaces.

The developed tool has a very easy and friendly user interface that could be used in different

fields:

• Tutorial for newcomers in the IN world: This tool provides a functional description of

the network components such as the MSC. By using the simulator, the user can



understand how these components are working and reacting to the messages inside the

protocols.

• This tool could be used for the IN troubleshooting purposes: In case of a what ever

error reported against the service part on the IN, the user can analyze the trace from

the real network and draw the same scenario by the scripting language that we

designed and analyze deeply the behaviour of the IN. For example if the customer is

claiming about some called destination which are not charged, the user can prepare a

script that simulate a call toward this kind of destination and test the behaviour of the

IN.

• The tool could be extended to cover many other functions such as a load tester for the

IN: This could be done by bombing the IN with multiple call requests (IDP message)

and observe the limitation that could appear.

• By some modification on the ASN.1 compiler the simulator could be used as a trace

analyser for the real network: This is done if a user provides a binary trace dump file

and modify the ASN.1 compiler to decode the message not from the Simulator

Gateway but from the dump file, this is very useful during the integration of new IN

platforms.

V Extensibility of the designed tool

V.1 Realization of a communication for an SMS-MO In SS7 networks a big variety of different call and signalling scenarios are possible. This

permits to our application to be extensible. Others communications can be reached. Using the

same scenario design a communication for an SMS-MO is possible. Two scenarios can

describe this communication:

Scenario 1:

MSC

SCP

@

5

SMSC

Figure IV. 11: SMS-MO Call Scenario.



For SMS-MO, two different implementations are available as SMS-MO is only standardised

with CAP3 and higher protocols. For CAP1 networks a Siemens proprietary solution is

available via normal MOC IDP message (field Ext-Teleservice=0x22). For INAP no SMS-

MO is available. With CAP3 (and higher) a special SMS-MO extension has been established.

Here the IDPsms message is used. The SMS-MO handling is just similar.

In order to check the SMS reception confirmation of SMSC (e.g. to charge SMS only if

transferred to SMSC) the @vantage may send an RRB together with the connect message.

Accordingly, @vantage would receive respective ERB as soon as the SMS has been received

by SMSC.

1. A-party sends SMS to B-party

2. The MSC forwards IN trigger (IDP, IDPsms) to the @vantage.

3. The @vantage answers with continue/connect (CUEsms, CUE, CON) or release (RC if

CAP1 or RCsms if CAP3) respectively. In case of sending an RRB the @vantage will

receive ERB after step 4 has been finished.

4. The MSC sends the SMS to the dedicated SMSC

5. The SMSC delivers the SMS to the B-party.

Scenario 2:

MSC

SCP

@

SMSC

5

6

Figure IV. 12: SMS-MO Call Scenario with confirmation dialog.

1. A-party sends SMS to B-party

2. The MSC forwards IN trigger (IDP, IDPsms) to the @vantage.



3. The @vantage answers with continue/connect (CUEsms, CUE, CON) or release (RC if

CAP1 or RCsms if CAP3) respectively. In case of sending an RRB the @vantage will

receive ERB after step 4 has been finished.

4. The MSC sends the SMS to the dedicated SMSC

5. The SMSC sends a confirmation.

6. The MSC delivers the SMS to the B-party.

V.2 Realization of a communication for a GPRS session A communication for a GPRS session is also possible. Using the message flows described in

figure IV.13 and in figure IV.14 the communication can be designed easily.

Scenario 1:

SGSN GGSN

SCP

@

2

3

MSP/WAP

1 4 5

Figure IV. 13: GPRS Call Scenario (one GPRS dialog).

In a GPRS scenario (packet data) the called party is an internet address, whereas B-party is

any MSP or WAP server.

1. A-party sends access request.

2. The SGSN forwards respective IN trigger (IDPgprs) to the @vantage.

3. In case that the call is allowed @vantage answers with continue (CUEgprs); otherwise

with release (RELgprs). In-between several messages may be transferred to handle

QoS, charging and handover.

4. In case of CUEgprs the SGSN contacts the GGSN of dedicated server and establishes a

data channel (packet data).

5. GGSN contacts MSP or WAP server and establishes transfer of respective data.



Scenario 2:

Scenario 2 allows CAMEL control of single PDP contexts. Multiple PDP contexts are

controlled in this scenario via multiple GPRS dialogues.

The implementation will support only scenario 2, in the following referred to as PDP Context

Handling. The figure below depicts the PDP Context Scenario:

SGSN / SSP SCP

PDP#2 SM

PDP#1 SM

GPRS Dialogue #2

Information flow related to PDP context #1

Information flow related to PDP context #2

GPRS Dialogue #1

Figure IV. 14: GPRS CAMEL Scenario 2.

By this model each GPRS dialogue contains exactly one PDP context in contrast to scenario 1

where a GPRS dialogue may contain multiple PDP contexts.

PDP ContextHandling is supported with the limitation that charging doesn’t cover multiple

PDP contexts simultaneously.

Conclusion

During this chapter we went through the realization steps that enable us to develop the

simulator. We choose Java as a base programming language; we used many libraries that we

adapted them for our simulator.

We tested the simulator on a real IN platform that exist in Nokia Siemens Tunisia and that

allowed us to correct and validate our work.



General Conclusion We presented, in this work, different steps to answer the initial requirement specifications for

this project which is mainly about the design and the development of an open simulator able

to communicate with an intelligent network platform. We have called the tool an Independent

Protocol simulator thanks to its ability to simulate any application SS7 protocol or other

specific for the Siemens IN platforms. We introduced the steps of study, conception and

implementation that we went though in order to finalize our suggested solution.

We start by studying the Intelligent Network and its services. This study allowed us to

understand working fundamental principles of this type of system as well as the requirements

of our application. In the second chapter we described the charging services and their types.

Then we suggested our solution, which can trigger the Siemens charge@once system through

two of its different interfaces: SS7 and Payment plugin. Nowadays, the Communication with

the IN through the payment plugin is deeply used by most of external systems that will act on

the subscriber status (money account balances, status, expiration…). Concerning the

communication on the SS7 interface, this used by the NSS components like the MSC and the

HLR which interact with the IN to handle all type of prepaid calls.

We started by the requirement specifications that lead us to the design steps which were

described in details. During these steps we presented the internal architecture for the simulator

and the solution for coding the protocol and exchanging the data with the IN platform.

We finalized our work by realizing a simulator able to communicate with the Intelligent

Network via the SS7 interface and also via the payment plugin.

We tried as much as possible to respect the modular architecture during the design and the

development of the simulator. Thanks to this modularity the simulator will be easily extended

and improved. The protocol database is written using the ASN.1 standard, thus it’s easy to

add new protocol family (for instance the MAP protocol used as a communication protocol

between the IN and the HLR). The scenario manager could be improved more by more

instructions. Same thing for the main engine which could be enhanced to work as a load tester

for the IN.



Bibliography [1] IN@vantage TAC2 Workshop, Siemens Documentation, PSE CSS INP4 [2] IN@vantage Introduction V7.5, Siemens Documentation, PSE CSS INP4 [3] Intelligent Network, Siemens Documentation,

INTC-ININTRO-002-1-05 [4] Intelligent Network Evolution Service, Siemens Documentation, [5] DMN: Service Management CORBA

Interface and Client Access Guide, Siemens AG 2001 A50020-A3226-C-2-76D6

[6] DMN: Payment Plugin Interface, Siemens Documentation,

A50020-A3245-E-5-76D6 [7] ADMN: Payment Plugin Installation and Configuration, Siemens AG 2003-

2004 A50020-A2403-E-4-7619

[8] Requirement specification for PPS1a, Siemens Documentation,

P500020-Q0372-B500-7626

[9] Charge@once for Recharging Charge@once V1.0, Siemens Documentation, Eo51 [10] Requirement specification, Siemens Documentation,

P500020-Q0020-B100-04-7626 [11] System Overview IN@vantage V7.5a

A50020-A1110-F-2-7618



[12] Charging & Care, Advanced Prepaid, Siemens Service Description, P50020-Q2837- B500- 04- 7618

[13] Convergent Online Charging Solution, Siemens, A50020-A3411-E000-03-76D6 [14] Charging & Care, Siemens AG 2006 P50020-Q2837-B500-04-7618

[15] ASN.1: Communication between Heterogeneous Systems, Olivier Dubuisson, 0-12-6333361-0

[16] ITU-T SPECIFICATION OF ABSTRACT SYNTAX NOTATION ONE (ASN.1) X.208 and X.209



Appendix Appendix A: ASN.1 representation of the exchanged messages: from MSC to

Charge@once.

InitialDP:

InitialDP ::= OPERATION InitialDPArg ::= SEQUENCE {

serviceKey [0] IMPLICIT INTEGER ( 0 .. 2147483647 ),

callingPartyNumber [3] IMPLICIT OCTET STRING ( SIZE (2 .. 10 ) ) OPTIONAL,

callingPartysCategory [5] IMPLICIT OCTET STRING ( SIZE (1 ) ) OPTIONAL,

locationNumber [10] IMPLICIT OCTET STRING ( SIZE (2 .. 10 ) ) OPTIONAL,

highLayerCompatibility [23] IMPLICIT OCTET STRING ( SIZE (2 ) ) OPTIONAL,

bearerCapability [27] CHOICE {

bearerCap [0] IMPLICIT OCTET STRING ( SIZE (2 .. 11 ) )} OPTIONAL,

eventTypeBCSM [28] IMPLICIT ENUMERATED {

collectedInfo (2 ),

} OPTIONAL,

iMSI [50] IMPLICIT OCTET STRING ( SIZE (3 .. 8 ) ) OPTIONAL,

locationInformation [52] IMPLICIT SEQUENCE {

ageOfLocationInformation INTEGER ( 0 .. 65535 ) OPTIONAL,

geographicalInformation [0] IMPLICIT OCTET STRING ( SIZE (8 ) )

OPTIONAL,

vlr-number [1] IMPLICIT OCTET STRING ( SIZE (1 .. 20 ) ) ( SIZE (1 .. 9 ) )

OPTIONAL,

cellIdOrLAI [3] CHOICE {

cellIdFixedLength [0] IMPLICIT OCTET STRING ( SIZE (7 ) ),

laiFixedLength [1] IMPLICIT OCTET STRING ( SIZE (5 ) )} OPTIONAL,

... } OPTIONAL,

ext-basicServiceCode [53] CHOICE {

ext-BearerService [2] IMPLICIT OCTET STRING ( SIZE (1 .. 5 ) ),

ext-Teleservice [3] IMPLICIT OCTET STRING ( SIZE (1 .. 5 ) )} OPTIONAL,

callReferenceNumber [54] IMPLICIT OCTET STRING ( SIZE (1 .. 8 ) ) OPTIONAL,

mscAddress [55] IMPLICIT OCTET STRING ( SIZE (1 .. 20 ) ) ( SIZE (1 .. 9 ) )

OPTIONAL,



calledPartyBCDNumber [56] IMPLICIT OCTET STRING ( SIZE (1 .. 41 ) ) OPTIONAL,

timeAndTimezone [57] IMPLICIT OCTET STRING ( SIZE (8 .. 8 ) ) OPTIONAL,

}

ApplyChargingReport:

ApplyChargingReport ::= OPERATION

ApplyChargingReportArg ::= CallResult

ERRORS {

MissingParameter,

ParameterOutOfRange,

SystemFailure,

TaskRefused

}

EventReportBCSM:

EventReportBCSM ::= OPERATION

EventReportBCSMArg ::= SEQUENCE {

eventTypeBCSM [0] EventTypeBCSM,

eventSpecificInformationBCSM [2] EventSpecificInformationBCSM OPTIONAL,

legID [3] ReceivingSideID OPTIONAL,

miscCallInfo [4] MiscCallInfo DEFAULT {messageType request},

extensions [5] SEQUENCE SIZE(1..numOfExtensions) OF

ExtensionField OPTIONAL,

...

}

Appendix B: encoded message of initialDP

0A01000001140100FFFFFFFFFFFFFFFF04000900000000000000000000000000000000000

000000000000000000000000000000000000000000000000000000000000000000000000000

000000000000B60000006281B348040A0040006B1A2818060700118605010101A00D600B

A1090607040000010032016C818EA1818B02010102010030818280011F830884131226056

3660685010A8A0903972054000053000097029181BB04800280909C01029F320814068106

000002F4BF34200201008008100000450000350181069112561532F4A309800732F4501500

3A98BF35038301119F36050C030015C49F37069112561532F49F3807911226057377F79F3

9080230104271858500


project report

Documents

simulator design

networks design

final project

communication protocols

prepaid service description

siemens communication

fundamental service

corba charging service