Professional Documents
Culture Documents
Telecommunication Engineering
Major
Faycel Smii
Supervised by:
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
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.
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.
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.
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
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.2 IN Services [3] The services Freephone (FPH), Tele-Info Service/ Premium Rate (TIS/PRM),
Universal Number (UN) are also termed Number Translation Services, according to their principal function: they translate the IN number into a public phone number by executing the service logic. The main distinction lies in charging. Televoting is a service especially designed for voting by a phone call, especially for Mass Calling. Virtual Card Calling and Universal Personal Telecommunications offer flexibility in charging and mobility also within stationary networks. Prepaid Service Card or Prepaid Card Service is a service for online charging of the subscriber. Therefore an account is continuously decremented according to the implemented charging algorithm. Control of Use offers screening functions both for incoming and outgoing calls. This service is normally used in Mobile Networks only.
The Virtual Private Network is an imaginary network within a network. VPN gives the service user the feeling of in-house connections to any destination connected, like in a PBX (Private Branch Exchange). In reality, the connections are switched through a public network. The Virtual Private Network service meets the increasing demands of companies and institutions for flexible, customizable private networks eliminating restrictions found in the basic public network. Service variants for fix and mobile Networks are available.
I.2.3 Prepaid Card Service The Prepaid Card Service is the main service given by IN to the mobile operator. The prepaid principle is based on the guarantee of payment for the party offering the service (mobile company). New and extremely flexible tariffs can be made subscriber specific and will be charged during the call. No post processing of charging is required any more. 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.
10
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.
11
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)
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].
13
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).
14
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.
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:
15
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].
16
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
17
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-
18
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.
19
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.
20
21
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].
22
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.
23
24
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.
25
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.
26
27
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].
28
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].
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
29
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.
30
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
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.
32
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
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]:
Comment Without the request type the appropriate request object cannot be created with the given parameters.
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
34
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
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.
36
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.
37
@vantage
CCC_USER
Service (Appl.) SLEE (SAF) CFRAME (CAF) CCC (CAF) CFRAME (CAF) TSP Dispatcher
CCC_CAP
OMNI
SS7 network
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
38
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
CAP SSN
SINAP SSN
SS7 Stack
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.
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
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.
40
3 2 5 1
MSC
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.
41
42
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.
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:
44
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.
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
46
or not. If Bonus Program Indicator is 1 after finished successfully recharge process, IN continue recharging bonus account beneficed by the subscriber.
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.
48
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.
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.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.
50
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
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
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
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
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.
54
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.
[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
55
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.
56
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.
57
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.
58
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.
59
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.
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.
60
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.
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:
61
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.
62
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:
63
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.
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.
64
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
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.
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:
66
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.
67
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.
68
69
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.
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 ;
71
72
73
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.
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
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.
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
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.
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.
78
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.
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.
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
80
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.
81
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.
82
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.
5
MSC SMSC
84
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
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
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
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
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:
SCP
PDP#2 SM
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.
87
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.
88
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]
[10]
[11]
89
[12]
Charging & Care, Advanced Prepaid, Siemens Service Description, P50020-Q2837- B500- 04- 7618
90
Appendix
Appendix A:
Charge@once.
91
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
92