You are on page 1of 92

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

Design and Development of an Independent Protocol Simulator

Acknowledgement
This project was achieved on behalf to the fulfilment of the Engineer Degree at the High School of Communication of Tunis (SupCom). It was undertaken within the framework of cooperation between SupCom 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 SupCom, 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

Fayal Smii, Final Project 2006 / 2007

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

Design and Development of an Independent Protocol Simulator

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.

Fayal Smii, Final Project 2006 / 2007

Design and Development of an Independent Protocol Simulator 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.

Fayal Smii, Final Project 2006 / 2007

Design and Development of an Independent Protocol Simulator

Chapter I Intelligent Network

Fayal Smii, Final Project 2006 / 2007

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

Design and Development of an Independent Protocol Simulator 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.

Fayal Smii, Final Project 2006 / 2007

Design and Development of an Independent Protocol Simulator

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.

Fayal Smii, Final Project 2006 / 2007

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

10

Design and Development of an Independent Protocol Simulator

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)

Fayal Smii, Final Project 2006 / 2007

11

Design and Development of an Independent Protocol Simulator

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)

Fayal Smii, Final Project 2006 / 2007

12

Design and Development of an Independent Protocol Simulator 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.

Fayal Smii, Final Project 2006 / 2007

13

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

14

Design and Development of an Independent Protocol Simulator

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

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

Fayal Smii, Final Project 2006 / 2007

15

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

16

Design and Development of an Independent Protocol Simulator

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) MTP1 (signaling data link)

Provides reliable connectionless service for routing messages through SS7 network 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

Fayal Smii, Final Project 2006 / 2007

17

Design and Development of an Independent Protocol Simulator

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 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. INAP (Intelligent Network Application Part) Set of different functional service elements as OPERATION-elements and RESULT-

Figure I. 4: Layers architecture of SS7.

Fayal Smii, Final Project 2006 / 2007

18

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

19

Design and Development of an Independent Protocol Simulator

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.

Fayal Smii, Final Project 2006 / 2007

20

Design and Development of an Independent Protocol Simulator

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.

Fayal Smii, Final Project 2006 / 2007

21

Design and Development of an Independent Protocol Simulator

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.

Fayal Smii, Final Project 2006 / 2007

22

Design and Development of an Independent Protocol Simulator

III.3 Description of the PrePaid Service


Prepaid@vantage is based on the new @vantage architecture with focus on voice-dataintegration, 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-tomarket 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.

Fayal Smii, Final Project 2006 / 2007

23

Design and Development of an Independent Protocol Simulator

Chapter II Technical Description Of the Charging Service

Fayal Smii, Final Project 2006 / 2007

24

Design and Development of an Independent Protocol Simulator

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 subscribers 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. 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. All systems are controlled and synchronized by Charging@vantage via defined interfaces.

Fayal Smii, Final Project 2006 / 2007

25

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

26

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

27

Design and Development of an Independent Protocol Simulator

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.

Fayal Smii, Final Project 2006 / 2007

28

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

29

Design and Development of an Independent Protocol Simulator

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.

Fayal Smii, Final Project 2006 / 2007

30

Design and Development of an Independent Protocol Simulator

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: Fayal Smii, Final Project 2006 / 2007 31

Design and Development of an Independent Protocol Simulator

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.

Fayal Smii, Final Project 2006 / 2007

32

Design and Development of an Independent Protocol Simulator

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 -101 -102 -103 -104 -105 -106 -107 -108 -109 -110 transaction already open invalid transaction duplicate transaction ID confirmation timeout CORBA communication error overload detected invalid user ID invalid access rights limits exceeded response timeout 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 -200

Name Request Type not valid

Comment Without the request type the appropriate request object cannot be created with the given parameters.

Fayal Smii, Final Project 2006 / 2007

33

Design and Development of an Independent Protocol Simulator -201 Parameter or attribute not found -202 Number Format error A parameter or attribute needed for the operation is not found in the http request. 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 -204 Class Cast error Account Handle Specification error Multiple user IDs error A class cast exception occurred due to an invalid parameter value. Indicates that the number of elements in the attribute lists specifying the account handles is inconsistent. -205 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 error -208 routing info Indicates that multiple values have been specified for the routing information in the list of account handles. Multiple account types Indicates that multiple values have been error -230 Cluster name not found specified for the account types in the list of account handles. Indicates that the cluster name specified in the request has not been configured. not

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

Fayal Smii, Final Project 2006 / 2007

34

Design and Development of an Independent Protocol Simulator

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]. Fayal Smii, Final Project 2006 / 2007 35

Design and Development of an Independent Protocol Simulator

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.

Fayal Smii, Final Project 2006 / 2007

36

Design and Development of an Independent Protocol Simulator

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.

Fayal Smii, Final Project 2006 / 2007

37

Design and Development of an Independent Protocol Simulator

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.

@vantage

CCC_USER

Service (Appl.) SLEE (SAF) CFRAME (CAF) CCC (CAF) CFRAME (CAF) TSP Dispatcher

CCC_CAP

DP* OEM Omni processes

OMNI

SS7 network

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

Fayal Smii, Final Project 2006 / 2007

38

Design and Development of an Independent Protocol Simulator

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 CCC_USER

MAP SSN CCC_CAP SCF

CAP SSN

SINAP SSN

SS7 Stack

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

Fayal Smii, Final Project 2006 / 2007

39

Design and Development of an Independent Protocol Simulator 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:

HLR

SCP

1
MSC

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

Fayal Smii, Final Project 2006 / 2007

40

Design and Development of an Independent Protocol Simulator Scenario 2:


HLR SCP

3 2 5 1
MSC

Figure II. 6: USSD Call Scenario.

1. 2. 3. 4. 5.

A-party dials USSD number The SSP/MSC forwards the USSD request to the HLR The HLR sends USSD request to @vantage (PUSSR). @vantage sends answer text. 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.

Fayal Smii, Final Project 2006 / 2007

41

Design and Development of an Independent Protocol Simulator

Chapter III Simulator Design

Fayal Smii, Final Project 2006 / 2007

42

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

43

Design and Development of an Independent Protocol Simulator 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.

Fayal Smii, Final Project 2006 / 2007

44

Design and Development of an Independent Protocol Simulator

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 isnt locked this operation is possible and the simulator sends a Recharge message to the Payment Fayal Smii, Final Project 2006 / 2007 45

Design and Development of an Independent Protocol Simulator

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 consumers 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 subscribers 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

Fayal Smii, Final Project 2006 / 2007

46

Design and Development of an Independent Protocol Simulator

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. Its 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 its 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. Fayal Smii, Final Project 2006 / 2007 47

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

48

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

49

Design and Development of an Independent Protocol Simulator 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.

Fayal Smii, Final Project 2006 / 2007

50

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

51

Design and Development of an Independent Protocol Simulator 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, IA5String}

Millimeters [1]

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

Fayal Smii, Final Project 2006 / 2007

52

Design and Development of an Independent Protocol Simulator 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 PD U

Sim ulator PD U

SD 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 PD U s

Sim ulator PD U

SD U

SD U

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

Fayal Smii, Final Project 2006 / 2007

53

Design and Development of an Independent Protocol Simulator 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

SimVar PDU

Simulator PDU

Param

SDU

SDU

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.

Fayal Smii, Final Project 2006 / 2007

54

Design and Development of an Independent Protocol Simulator

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/PaymentPl uginServlet; [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.

Fayal Smii, Final Project 2006 / 2007

55

Design and Development of an Independent Protocol Simulator

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.

Fayal Smii, Final Project 2006 / 2007

56

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

57

Design and Development of an Independent Protocol Simulator

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.

Fayal Smii, Final Project 2006 / 2007

58

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

59

Design and Development of an Independent Protocol Simulator

No life cycle changing in this operation, so the expiry date doesnt 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.

Fayal Smii, Final Project 2006 / 2007

60

Design and Development of an Independent Protocol Simulator

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 its 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:

Fayal Smii, Final Project 2006 / 2007

61

Design and Development of an Independent Protocol Simulator

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.

Fayal Smii, Final Project 2006 / 2007

62

Design and Development of an Independent Protocol Simulator

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:

Fayal Smii, Final Project 2006 / 2007

63

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

64

Design and Development of an Independent Protocol Simulator

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: Direction: from Charge@once to MSC. This operation is used for interacting from the Charge@once with the MSC CSE-controlled call duration charging mechanism. CallInformationRequest: Direction: from Charge@once to MSC. 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: Direction: from Charge@once to MSC. 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: Direction: from MSC to Charge@once. The ApplyChargingReport operation provides the feedback from the MSC to the Prepaid@vantage for the CSE-controlled call duration charging mechanism. CallInformationReport: Direction: from MSC to Charge@once. 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: Direction: from MSC to Charge@once. 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. Fayal Smii, Final Project 2006 / 2007 65

Design and Development of an Independent Protocol Simulator

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:

Fayal Smii, Final Project 2006 / 2007

66

Design and Development of an Independent Protocol Simulator

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 doesnt permit a communication because the users account balance is exhausted or others reasons, the Charge@once returns an error message to the simulator.

If its the second case, the simulator declares an error to user. If its the first case, the simulator doesnt 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 users account balance is exhausted or the call is disconnected.

If the users account balance is exhausted, the last ApplyCharging indicates that its the last quota units: final forced. The simulator sends threes messages to Charge@once: apply the charge operation. EventReportBCSM, CallInformationReport and ApplyChargingReport to request the Charge@once to

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.

Fayal Smii, Final Project 2006 / 2007

67

Design and Development of an Independent Protocol Simulator

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.

Fayal Smii, Final Project 2006 / 2007

68

Design and Development of an Independent Protocol Simulator

Chapter IV Simulator Development And Result Validation

Fayal Smii, Final Project 2006 / 2007

69

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

70

Design and Development of an Independent Protocol Simulator 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 doesnt 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.

Fayal Smii, Final Project 2006 / 2007

71

Design and Development of an Independent Protocol Simulator

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.

Fayal Smii, Final Project 2006 / 2007

72

Design and Development of an Independent Protocol Simulator

Figure IV. 2: Simulation via the SS7 Interface.

Figure IV. 3: Simulation via the Payment Plugin Interface.

Fayal Smii, Final Project 2006 / 2007

73

Design and Development of an Independent Protocol Simulator

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 messages 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 transactions 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). Fayal Smii, Final Project 2006 / 2007 74

Design and Development of an Independent Protocol Simulator

Figure IV. 4: IN@vantage management Interface.

IV.3 Transactions 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 Fayal Smii, Final Project 2006 / 2007 75

Design and Development of an Independent Protocol Simulator 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 its the same amount that we recharge. Its 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 dont need to full up all

Fayal Smii, Final Project 2006 / 2007

76

Design and Development of an Independent Protocol Simulator 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

Fayal Smii, Final Project 2006 / 2007

77

Design and Development of an Independent Protocol Simulator 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.

Fayal Smii, Final Project 2006 / 2007

78

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

79

Design and Development of an Independent Protocol Simulator Charge@once and receiving the responses. But we need only to test whether the IN replies to a request or not. We dont 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

Fayal Smii, Final Project 2006 / 2007

80

Design and Development of an Independent Protocol Simulator

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.

Fayal Smii, Final Project 2006 / 2007

81

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

82

Design and Development of an Independent Protocol Simulator 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 Fayal Smii, Final Project 2006 / 2007 83

Design and Development of an Independent Protocol Simulator 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:
SCP

5
MSC SMSC

Figure IV. 11: SMS-MO Call Scenario.

Fayal Smii, Final Project 2006 / 2007

84

Design and Development of an Independent Protocol Simulator

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 SMSMO 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:

SCP

MSC

5 6

SMSC

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. Fayal Smii, Final Project 2006 / 2007 85

Design and Development of an Independent Protocol Simulator

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:
SCP

2 3 1
SGSN @

4
GGSN

5
MSP/WAP

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. Fayal Smii, Final Project 2006 / 2007 86

Design and Development of an Independent Protocol Simulator

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 PDP#1 SM

GPRS Dialogue #1 Information flow related to PDP context #1

SCP

PDP#2 SM

Information flow related to PDP context #2 GPRS Dialogue #2

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

Fayal Smii, Final Project 2006 / 2007

87

Design and Development of an Independent Protocol Simulator

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

Fayal Smii, Final Project 2006 / 2007

88

Design and Development of an Independent Protocol Simulator

Bibliography [1] [2]


IN@vantage TAC2 Workshop, Siemens Documentation, PSE CSS INP4 IN@vantage Introduction V7.5, Siemens Documentation, PSE CSS INP4

[3] [4] [5]

Intelligent Network, Siemens Documentation, INTC-ININTRO-002-1-05 Intelligent Network Evolution Service, Siemens Documentation,

DMN: Service Management CORBA Interface and Client Access Guide, Siemens AG 2001 A50020-A3226-C-2-76D6

[6] [7]

DMN: Payment Plugin Interface, Siemens Documentation, A50020-A3245-E-5-76D6 ADMN: Payment Plugin Installation and Configuration, Siemens AG 20032004 A50020-A2403-E-4-7619 Requirement specification for PPS1a, Siemens Documentation, P500020-Q0372-B500-7626

[8]

[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

Fayal Smii, Final Project 2006 / 2007

89

Design and Development of an Independent Protocol Simulator

[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


(ASN.1) X.208 and X.209

OF ABSTRACT SYNTAX NOTATION ONE

Fayal Smii, Final Project 2006 / 2007

90

Design and Development of an Independent Protocol Simulator

Appendix

Appendix A:
Charge@once.

ASN.1 representation of the exchanged messages: from MSC to

InitialDP: InitialDP ::= OPERATION


InitialDPArg ::= SEQUENCE { serviceKey callingPartyNumber callingPartysCategory locationNumber highLayerCompatibility bearerCapability [0] IMPLICIT INTEGER ( 0 .. 2147483647 ), [3] IMPLICIT OCTET STRING ( SIZE (2 .. 10 ) ) OPTIONAL, [5] IMPLICIT OCTET STRING ( SIZE (1 ) ) OPTIONAL, [10] IMPLICIT OCTET STRING ( SIZE (2 .. 10 ) ) OPTIONAL, [23] IMPLICIT OCTET STRING ( SIZE (2 ) ) OPTIONAL, [27] CHOICE { bearerCap [0] IMPLICIT OCTET STRING ( SIZE (2 .. 11 ) )} OPTIONAL, eventTypeBCSM [28] IMPLICIT ENUMERATED { collectedInfo (2 ), } OPTIONAL, iMSI locationInformation [50] IMPLICIT OCTET STRING ( SIZE (3 .. 8 ) ) OPTIONAL, [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 mscAddress [54] IMPLICIT OCTET STRING ( SIZE (1 .. 8 ) ) OPTIONAL, [55] IMPLICIT OCTET STRING ( SIZE (1 .. 20 ) ) ( SIZE (1 .. 9 ) ) OPTIONAL,

Fayal Smii, Final Project 2006 / 2007

91

Design and Development of an Independent Protocol Simulator


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 eventSpecificInformationBCSM legID miscCallInfo extensions

[0] EventTypeBCSM, [2] EventSpecificInformationBCSM OPTIONAL, [3] ReceivingSideID OPTIONAL, [4] MiscCallInfo DEFAULT {messageType request}, [5] SEQUENCE SIZE(1..numOfExtensions) OF

ExtensionField OPTIONAL, ... }

Appendix B: encoded message of initialDP


0A01000001140100FFFFFFFFFFFFFFFF04000900000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000000000000000 000000000000B60000006281B348040A0040006B1A2818060700118605010101A00D600B A1090607040000010032016C818EA1818B02010102010030818280011F830884131226056 3660685010A8A0903972054000053000097029181BB04800280909C01029F320814068106 000002F4BF34200201008008100000450000350181069112561532F4A309800732F4501500 3A98BF35038301119F36050C030015C49F37069112561532F49F3807911226057377F79F3 9080230104271858500

Fayal Smii, Final Project 2006 / 2007

92

You might also like