1 About the Convergent Charging Controller Testing Utilities
This chapter provides an overview of the Oracle Communications Convergent Charging Controller testing utilities.
Overview of Convergent Charging Controller Testing Utilities
Convergent Charging Controller communicates internally using a language known as G8-Intelligent Network Application Protocol (G8-INAP), which is a subset of Capability Set 1 (CS1) INAP but also includes bits of CS2 INAP and CAMEL Application Part (CAP). Using this common language allows Convergent Charging Controller components to perform functions without having to translate the low-level languages used by the telephony network.
Convergent Charging Controller interfaces communicate with the physical network in whichever protocol the network demands. The interfaces translate the messages from the physical network into the G8-INAP messages. The passing of messages between Convergent Charging Controller and the interfaces takes place in the Convergent Charging Controller Service Logic Execution Environment (SLEE), where many interfaces can communicate concurrently. Because they are not tied to low-level network languages, Convergent Charging Controller components can be portable and plug into any network as long as an effective interface exists.
The Convergent Charging Controller testing utilities include:
-
The Service Logic Program Instance Tester (slpit) utility
The slpit utility allows you to test call processing by Convergent Charging Controller applications without the need for a physical telephony network.
-
The Messaging over Internet Protocol Tester (mipt) utility
The mipt utility allows you to test the sending and receiving of messages over internet-based protocols.
-
The short message service center (smsc) test tool
The smsc test tool emulates various parts of the short message service (SMS) environment to enable testing of SMS messaging.
The distinction between the smsc test tool and the two utilities is that you initiate smsc through configuration parameters as part of Convergent Charging Controller startup, whereas you run the two utilities independently from the command line.
Overview of the slpit Utility
The slpit utility is a tool that you can use to do functional testing of Convergent Charging Controller applications, high load testing, and external interface testing without concern for the protocol of a given network. From the perspective of the test application, the slpit utility emulates a real interface that converts the network messages to and from G8-INAP. It communicates with the application by way of the SLEE, just like a regular interface.
Note:
In this context, application or Convergent Charging Controller application refers to the SLEE process to which the slpit utility is communicating. Usually, this process is either slee_acs, which is the main ACS process, or xmsTrigger, which is the main XMS process. But it can also be m3uaIf, which is also a SLEE process. The m3uaIf process is further described in this section.
The slpit utility has the following characteristics:
-
It allows you to effectively test Intelligent Network (IN) applications without requiring a physical telephony network or a low-level network-specific test tool.
-
You can use it to do functional testing of Convergent Charging Controller applications without concern for a particular network protocol. As long as the application provides the correct functionality in G8-INAP, it will perform the same way on a particular network with the appropriate interface.
-
It acts as a normal TCAP interface to trigger IN platform service logic, emulating a service switching point (SSP) and specialized resource function (SRF) interactions.
The slpit utility supports the following IN protocols: CAP, MAP, SCCP, CAP3 GPRS and IS-41.
-
It uses a script file in which you define the INAP operations that are sent and received for one or more types of calls. A single instance of slpit can run many call instances and many calls can be in-progress at once. The script initiates a call and you can specify different distributions and throughput rates. Multiple protocols are supported.
-
You can use it to do moderate load testing and external interface testing, in addition to using it for functional testing of applications.
-
You can run it in the same SLEE as the application being tested or in a separate SLEE using appropriate TCAP interfaces.
On a production Convergent Charging Controller system, the slee_acs process and the xmsTrigger process communicate with a process called m3uaIf, using a TCAP-like protocol. The m3uaIf process is also a SLEE process. The m3uaIf process turns the TCAP-like events into messages that are sent over the IP network in a protocol stack that consists of one of the following:
-
MAP over TCAP over SCCP over M3UA over SCTP over IP
-
CAP over TCAP over SCCP over M3UA over SCTP over IP
Figure 1-1 shows slpit running in the same SLEE as the application being tested.
Figure 1-1 slpit Testing Application in the Same SLEE
You can also use slpit to generate INAP, MAP, CAP3 GPRS or IS-41 over a specific set of protocols if you run it on a different machine than the one where the application is being tested.
Figure 1-2 shows slpit running in a SLEE on a separate machine from the one where the application is being tested.
Figure 1-2 slpit Testing Application in a Separate SLEE
See "Testing Calls and Messages Using the slpit Utility" for more information.
Overview of the mipt Utility
The mipt utility is a test tool that allows you to send and receive messages. Depending on the protocol, the mipt utility can act as:
-
An application service provider (ASP) or a Short Message Service Center (SMSC) when the protocol is one of the following:
-
Short Message Peer to Peer (SMPP)
-
External Machine Interface (EMI)
-
-
An ASP when the protocol is Media Transfer Protocol (MTP) level 3 User Adaptation layer (M3UA)
-
A Diameter agent or a Diameter server for the Diameter protocol
You can run multiple instances of mipt, acting as ASPs or SMSCs, that communicate with each other on the same machine.
You can use the following protocols with mipt:
-
Remote Authentication Dial-In User Service (RADIUS)
RADIUS is a network protocol that is the predecessor to the Diameter protocol and, like Diameter, it is used for authentication, authorization, and accounting.
-
Diameter
Diameter is an authentication, authorization, and accounting protocol. You can also use the Diameter protocol for policy control and resource control.
-
EMI
EMI connects mobile telephones to SMSCs.
-
M3UA
The M3UA protocol enables the SS7 protocol User Part SCCP, as well as others, to run over the internet protocol instead of telephony equipment. It is generally transmitted by using the services of Stream Control Transmission Protocol (SCTP).
-
SMPP
SMPP transfers short message data between message centers and routing and messaging facilities. It is commonly used to transfer short messages and it allows service providers to submit messages in bulk.
-
SUA
The SUA protocol facilitates the transfer of SCCP user messages, such as TCAP, between the signalling gateway and the ASP.
See "Supported Protocol Fields for mipt" for a list of supported fields for each of the protocols that you can use.
To test messages using these protocols, you create a text file, called the script file, that contains the operations or messages that you want to test. The mipt utility accepts the script file as input and processes the operations that you have defined.
See "Testing IP Interactions with the mipt Utility" for more information.
Overview of the smsc Test Tool
The smsc test tool is a multipurpose test tool that runs as a Service Logic Execution Environment (SLEE) interface.
The SMSC test tool emulates the following parts of a short message service (SMS) messaging environment:
-
Visitor Mobile Switching Center (VMSC)
A mobile switching center (MSC) is a telephone exchange in a GSM mobile network. The VMSC is the MSC that the destination phone is attached to, which could be distant from its home network, and, hence, is a visitor.
-
Short Message Service Center (SMSC)
-
Home Location Register (HLR)
Figure 1-3 illustrates how Convergent Charging Controller applications connect to SMSC, HLR, or VMSC in a production environment.
Figure 1-3 Convergent Charging Controller Connecting to SMSC, HLR, or VMSC in a Production Environment
The SMSC attaches to the SLEE as a Transaction Capabilities Application Part (TCAP) interface. The simulated SMSC handles both Mobile Application Part (MAP) and IS-41 (also known as ANSI-41) incoming short message requests. The smsc test tool can simulate an SMSC, a Home Location Register (HLR), and a messaging service center (MSC) at MAP levels 1 through 3. It can also perform one CAP 3 GPRS operation, ActivitytestGPRS.
The smsc test tool can handle the following operations for MAP and IS-41:
-
MAP
-
FORWARD-SHORT_MESSAGE
-
MT-FORWARD-SM
-
SEND-ROUTING-INFO-FOR-SM (HLR operation)
-
SEND-ROUTING-INFORMATION (HLR operation)
-
PROCESS-UNSTRUCTURED-SS-REQUEST
-
UNSTRUCTURED-SS-NOTIFY
-
-
IS-41
-
SmsDeliveryPointToPoint (SMDPP)
-
SMSRequest (HLR operation)
-
SMSNotification
-
Figure 1-4 illustrates how the smsc test tool replaces SMSC, HLR, or VMSC in a testing environment. The diagram illustrates the smsc test tool running on the same SLC (SLC1) that you are testing on, and running on a remote SLC (SLC2). The latter case is necessary to test the interaction between the application and the SIGTRAN interface.
See "Testing Messaging with the SMSC Test Tool" for more information.



