Access Keys:
Skip to content (Access Key - 0)









How do I use OpenCloud tools to test IN applications?

Print this page

Introduction

This document describes how to use OpenCloud's IN tools to test IN applications. These tools include the HLR simulator, INCC simulator and backend simulators. It is assumed that the reader has downloaded the latest version of the IN Connectivity Pack. This document refers to examples and configuration files included with this package.

Download the IN Connectivity Pack here:
Register/login to use all DevPortal features - Log in | Sign up )

Overview

OpenCloud provides a number of tools which may be used together to test an IN application. The tools to be used depends on what the IN application to be tested does. Three classes of tool are provided:

HLR Simulator The HLR simulator listens for incoming requests sent via an IN service over the SS7 network and send an appropriate response back to the IN service. The HLR simulator supports IS41 and understands the following requests:
  • AnalyzedInformation
  • FacilitySelectedAndAvailable
  • LocationRequest
  • MessageDirective
  • OriginationRequest
  • ServiceRequest
  • TBusy
  • TNoAnswer
Backend Simulators The backend simulators are used to simulate an SS7 network. They are used as a complete replacement for Signalware. That is, no Signalware installation is required to use them. Backend simulators are provided for CAP, MAP, INAP and IS41. They understand both PC/SSN and GT configurations and may be used for any of the OpenCloud supported SccpAddress formats: C7, J7 and A7.
Load Generators The load generators may be used to send specific IN messages to the SLEE over the SS7 network. These are messages that the service to be tested is expecting to receive. The load generators can be used to send a single message, or a repeating set of messages, either as a single or repeating test run. For a repeating test run the call rate can be specified. There are currently two types of load generator distributed with the IN Connectivity Pack:
  • Legacy Load Generators; Limited CAP, MAP, INAP and IS41 support
  • IN Simulator; Full CAP and INAP support. Full MAP support is an optional purchasable extra. This simulator does not currently support IS41.

Integration and Configuration

The following diagram shows how the tools required to test a simple CAP service fit together. The hypothetical service listens for an incoming CAP request and sends a response directly, without querying any other services.

Simple Test Setup

The tools used in this case were:

  • CAP Load Generator
  • CAP Backend Simulator

A more complex service, involving a service that on receiving an incoming CAP request sends an IS41 message to a HLR, then on receiving a message back from the HLR responds to the initial CAP request.

Test Setup with CAP and IS41

The tools used were:

  • CAP Load Generator
  • CAP Backend Simulator
  • IS41 Backend Simulator
  • IS41 HLR Simulator

The rest of this section describes how to configure the individual components. The following section will show how two of the examples bundled with the IN Connectivity Pack use these tools.

HLR Simulator Configuration

The IS41 HLR simulator is configured via an XML file which defines one or more response profiles. A response profile is associated with a range of digits and one or more request types. For example:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE ResponseProfiles SYSTEM "http://www.opencloud.com/dtd/hlr-simulator-response-profile.dtd">
<ResponseProfiles>
  <DefaultProfile/>
  <ResponseProfile>
    <DigitsRange>12340000-12349999</DigitsRange>
    <LocationRequest mobileIdentificationNumber="constant(1423178237)">
      <RoutingDigits nature="0" numberingPlan="2" digits="constant(64)"/>
      <DestinationDigits nature="0" numberingPlan="2" digits="prefix(64)"/>
      <ElectronicSerialNumber manufacturersCode="34" serialNumber="8128381"/>
      <MSCID marketID="42" switchNumber="7"/>
    </LocationRequest>
  </ResponseProfile>
</ResponseProfiles>

The current DTD describing the permitted syntax can be extracted from the is41-hlr-simulator.jar file in the incc/lib directory of the IN Connectivity Pack. The is41-hlr-simulator.jar file is executed using the following parameters:

java HLRSimulator <RA entity name> <backends> <spc encoding> <IS41 operation timeout> <responsesFile>

Backend Simulator Configuration

Each of the CAP, MAP, INAP and IS41 backend simulators are run from their own jar file. These files are located in the lib/ directory in the IN Connectivity Pack. They are configured via an XML file. The backend simulator should be configured with two or more SS7 PC/SSN or GT listening points. Each listening point requires the following configuration data:

  • SccpAddress in PC/SSN or GT format, including SccpAddress type (A7, C7 or J7)
  • Port on which to accept connections from IN RAs, Load Generators or HLR Simulators.
  • Name to identify the listening point.

A sample configuration file can be found in any of the 'backendsim' directories of the example applications provided with the IN Connectivity Pack. A simple CAP XML configuration file may look like the following:

<?xml version="1.0"?>
<backend-simulator>
  <endpoint>
    <id>switch</id>
    <port>10221</port>
    <sccp-address>type=c7,ri=pcssn,pc=1,ssn=221</sccp-address>
  </endpoint>
  <endpoint>
    <id>rhino</id>
    <port>10222</port>
    <sccp-address>type=c7,ri=pcssn,pc=2,ssn=222</sccp-address>
  </endpoint>
</backend-simulator>
<sccp-address> The SccpAddress format string is fully documented in the SccpAddress JavaDoc included with the IN Connectivity Pack.
<port> The port is the port used by the Load Generator, HLR Simulator or IN Resource Adaptor to connect to the backend simulator. It must be a port that is not currently in use. OpenCloud convention is to use SSN+10000. This allows us to easily remember which port to connect a given SSN to.
<id> The name is a free form string. OpenCloud convention is to use 'rhino' for listening points that Rhino resource adaptors connect to, and 'switch' for listening points that Load Generators or HLR Simulators connect to.

The backend simulator jars are located in the incc/lib directory, one for each protocol, with the PROTOCOL-backend-simulator.jar naming convention. A list of required command line arguments can be found by executing the jar:

$ java -jar cap-backend-simulator.jar 
Required arguments:
  -c <config-file>
     Filename of XML configuration file.

Optional arguments:
  -t <A7|C7|J7|CH7>
     This specifies the SCCP address type to use.  The default is C7.
  -a <application-id>
     This is an integer value in the range 0-32767.
     It is used as part of dialog identifiers, so if an RA connects to multiple
     backend simulators, each simulator must be given a unique application-id.
     If unspecified, a value derived from the current time is used, changing
     every 1/10th of a second and unique every 54m 36.8s.
  -d <max-dialogs>
     Limit the maximum number of dialogs that can be allocated at any one time.
     By default the maximum is effectively unlimited.
  -h Print this help message (all other arguments are ignored).
  -g Output a sample XML configuration file (all other arguments are ignored).

Load Generator Configuration

IN Simulator

The IN Simulator bundled with the IN Connectivity Pack supports CAP and INAP. If MAP support is required, please contact your OpenCloud sales representative.

Legacy Load Generators

It is highly recommended that the IN Simulator is used to generate test messages. The Legacy Load Generators are deprecated and should not be used to test new applications. Legacy load generators are provided with the IN Connectivity Pack for IS41, CAP and INAP. Each load generator supports only a limited subset of the protocol's operations. The Legacy Load Generators each use two configuration files:

  • A switch.xml configuration file; this controls the load generator's SS7 configuration, plus whether to create originating and terminating triggers and the valid subscriber range for the load generator.
  • A switch-loadgen.xml configuration file; this defines the set of test calls to generate.

Example configuration files for the Legacy Load Generators can be found in the 'switchsim' directory of the IN Connectivity Pack examples. The DTDs showing available configuration elements can be found in the JAR files for each load generator. The load generator JAR files to be executed are in the incc/lib directory and are:

  • CAP/INAP: incc-switch-simulator2.jar
  • IS41: is41-loadgenerator.jar

A list of required command line arguments can be found by executing the JAR file:

 $ java -jar is41-loadgenerator.jar 
Test run configuration file must be specified
Available command line format:
        -g            : Use a GUI
        -i            : Start sending immediately
        -c <argument> : The switch configuration file
        -t <argument> : The file containing the test definitions

Examples

This section shows how the tools are used to test some of the examples provided with the IN Connectivity Pack.

Example Service #1: CAP Call Barring Service

The CAP Call Barring service processes an incoming InitialDP and checks either the calling or called address against a list of barred numbers. If the call is barred, it responds with a ReleaseCall request and closes the dialog. If the call is not barred, it responds with a Continue.

Call Barred Message Flow
Call Not Barred Message Flow

Testing this service requires the following tools:

  • CAP Load Generator
  • CAP Backend Simulator
  • Rhino SLEE with CAP RA and CAP Call Barring Service Loaded

The CAP RA for this service is configured with PC=2, SSN=222. The CAP Load Generator is configured with PC=1, SSN=221. This means that the backend simulator needs to be configured in the following way:

  • switch: PC=1, SSN=221, port=10221
  • rhino: PC=2, SSN=222, port=10222

The CAP Load Generator scripts for this example may be found in the IN Connectivity Pack at:

  • incc/examples/cap/callbarring/switchsim/switch.xml
  • incc/examples/cap/callbarring/switchsim/switch-loadgen.xml

The Backend Simulator configuration file for this example is located at:

  • incc/examples/cap/callbarring/backendsim/cap-backend-simulator-config.xml

The procedure used to run this test is as follows:

  1. Start the backend simulator.
  2. Install the RA and Service into the SLEE and activate them.
  3. Run the load generator.
  4. Tell the load generator to generate load.

Example Service #2: IS41 "Complex" Service

The IS41 "complex" service listens for a number of incoming IS41 requests, including:

  • FacilitySelectedAndAvailable
  • ServiceRequest
  • OriginationRequest
  • AnalyzedInformation

To service some of these requests it needs to send a request to a HLR and use data from the HLR's response to respond to the initial request. Other requests are responded to immediately, without invoking a HLR request. The requests that invoke a HLR query are:

  • OriginationRequest (sends LocationRequest to the HLR)
  • ServiceRequest (sends MessageDirective to the HLR)

This test requires use of the following tools:

  • Legacy IS41 Load Generator
  • IS41 Backend Simulator
  • IS41 HLR Simulator

The relationship between the various components of this test setup are:

IS41 'Complex' Service Setup

The backend simulator configuration is located at:

  • incc/examples/is41/complex/backendsim/config.xml

The load generator configuration files are located at:

  • incc/examples/is41/complex/switchsim/switch-config.xml
  • incc/examples/is41/complex/switchsim/config.xml

This particular load generator configuration is long as a large number of test cases are defined. The actual tests to be run are defined in the "test-set" element at the bottom of the config.xml file. This allows a number of different tests for one service to be defined in a single configuration file. Any tests not to be run should have their "run-test" element commented out.

The HLR configuration file is located at:

  • incc/examples/is41/complex/hlr/hlr-config.xml

The procedure to run this test is:

  1. Start the backend simulator.
  2. Start the HLR simulator.
  3. Install the RA and service into the SLEE and activate them.
  4. Run the load generator.
  5. Instruct the load generator to generate load.
Adaptavist Theme Builder Powered by Atlassian Confluence