Testing IP Interactions with the mipt Utility

3 Testing IP Interactions with the mipt Utility

This chapter describes how to use the Oracle Communications Convergent Charging Controller mipt test utility.

About the mipt Utility

The mipt utility generally tests the sending and receiving of messages over IP, or internet-based protocols, and you can use it to do high load testing. See "Overview of the mipt Utility" for an overview of mipt.

The mipt utility processes operations from an input text file rather than a real network. The input text file is called the script file and it is a file that you create. In the script file, you add commands and send and receive messages that define the message sequences that you want to test. You can include send and receive messages of the following protocols: Diameter, EMI, M3UA, RADIUS, SMPP, and SUA. The scripting language allows you to define the test sequences. See "Creating the mipt Script File" for more information.

Depending on the protocol, the mipt utility can act as an Application Service Provider (ASP), a Short Message Service Center (SMSC), a RADIUS client, a DIAMETER Credit Control Client, or a DIAMETER Credit Control Server.

See Appendix B, "Supported Protocol Fields for mipt," for the fields that mipt supports for each protocol.

You can run multiple instances of mipt, acting as ASPs or SMSCs, communicating with each other on the same machine.

Running the mipt Utility

The mipt utility is located in the following directory:

/IN/service_packages/TEST_TOOLS/bin

Command Syntax

Use the following command to run the mipt utility:

mipt {<option> ...} [<file> ... <file>]

You can specify the user name, password, host name, and port either on the command line or in the script file.

See "Command-Line Options" for explanations of the command line options.

When the utility is acting as an ASP you can specify the user name, password, host name, and port number of the SMSC in the script with a statement like the following:

connect smpp_asp tcp smschost smscport bind_receiver system_id=username            password=user_password

See "Specifying the Test Sequence" for additional information.

If you specify values both on the command line and in the script, the values you specify in the script override the values you specify on the command line.

Command-Line Options

The mipt utility takes the following command-line options:

-A

Accelerated time (for testing purposes only). Causes mipt to ignore any times specified in the script and perform operations as fast as it can

-D <var>=<string>

Assigns a string to a variable.

<file>

You must specify at least one script file on the command line. You can give your script files any name. If you specify multiple script files, mipt runs them in parallel. You can specify the script file name as -, in which case mipt reads the script from standard input. For example:

mipt {<options>} -<<EOF

This would be followed by lines of script like you would find in a script file and would be terminated by typing EOF.

See "Creating the mipt Script File" for more information.

-N <var>=<number>

Assigns a number to a variable.

-P <password>

Specifies the user's password on the host computer.

-U <user>

Specifies the user's login name on the host computer.

-V

Displays mipt version number and details about how and when mipt was created.

-d

Prints the script file after parsing it, rather than running it.

-e

Exits on error.

-l [<log options>]

Sets logging options. See "Logging Options" for a list of logging options.

-h <host>

Specifies the name of the host short message service center (SMSC) computer.

-n <protocol>

Specifies the network protocol to use if none is specified in the script file.

-p <port>

Specifies the port number on the host SMSC computer.

-q

Suppresses output to the command window other than errors, stats, and warnings.

-u latin

Sets EMI string processing to latin-1 (ISO8859-1).

-u unicode

Sets EMI string processing to UTF-8 (default is latin-1).

-v

Triggers verbose mode, which displays the packets being sent and received, including the smpp_bind_transceiver packet that enables the SMSC to authenticate the connection. The smpp_bind_transceiver packet has the following fields:

Table 3-1 smpp_bind_transceiver packet fields

Field Name	Default Value
smpp_command_status	0
smpp_sequence_number	1
smpp_password	"PASSWORD"
smpp_system_id	"mipt"
smpp_system_type	"mipt"
smpp_interface_version	0x50
smpp_addr_ton	1
smpp_addr_npi	1
smpp_address_range	""

Logging Options

You can specify the following logging options with the -l command-line option. The default options are error, script, stats, and warning.

You can turn off a default logging option by preceding it with a dash (-).

The logging options are:

all: Enable all logging options except for binary and execute.
binary: Log binary packet contents as they are sent and received.
control: Log control packets as they are sent and received.
data: Log data packet contents as they are sent and received.
error: Log error messages.
execute: Log mipt processing at a low level. Use only for development.
match: Trace progress of packet matching.
network: Log information about the network state.
-q: Specify -q as shorthand for -all,error,stats,warning.
script: Log script processing.
stats: Print statistics.
-v: Enable all logging options except for binary and execute.
warning: Log warning messages.
werror: Log an error on any warnings.

Creating the mipt Script File

The mipt script file is a text file that you create to define message sequences that you want to test. You can name the mipt script file whatever you like.

Note:

The following sections use SMPP examples, using mipt as an ASP or SMSC, except for those examples that are specific to other protocols. The syntax and concepts demonstrated in the SMPP examples, however, apply to all protocols.

Specifying the Test Sequence

A script consists of the following five basic statements that you specify to create a test sequence.

connect <node>

The connect statement specifies the role of the initiating node and initiates the connection with the receiving node.
Note:

You can also specify the host name, port name, user ID, and password in the connect statement, using the following format:
```
connect <node> <protocol> <host> <port> <ID> <password> 
```
accept <node>

The accept statement specifies the role of the receiving node and accepts a connection request.
send <message>

The send statement sends a message as defined by <message>.
receive <message>

The receive statement defines the expected short message response in <message>.
end

The end statement defines the end of a repeat block and also defines the end of the test message script and causes mipt to disconnect. Its absence results in a syntax error.

Reserved keywords

The mipt utility supports the following reserved keywords for the connect and accept statements:

emi_asp
emi_smsc
m3ua_asp
m3ua_sgp
diameter_raw
diameter_cooked
diameter_agent
smpp_asp
smpp_smsc
sua_asp
sua_sgp

Using mipt as an ASP or SMSC

The mipt utility can run as either the ASP or the SMSC. The first line of the script specifies the role that mipt plays. For example, the following line indicates that mipt is acting as an ASP and is ready to send messages to an SMSC and receive messages from it.

connect smpp_asp

The following line specifies that mipt is acting as an SMSC and is ready to receive messages from ASPs.

accept smpp_smsc

The following example shows a sample test script with SMPP messages, one sent and one received. This script simulates an ASP that sends a message to an SMSC and waits for it to be accepted.

connect smpp_asp

send submit_sm
    source_addr = "0274022020"
    destination_addr = "0274022023"
    short_message = octets "Hello World"

receive submit_sm_resp
    command_status = 0        # Expect success

end

Sending Multiple Messages

Typically, an ASP script will keep the connection open and send multiple messages, as seen in the following script:

connect smpp_asp

send submit_sm
    source_addr = "0274022020"
    destination_addr = "0274022023"
    short_message = octets "Hello World"

receive submit_sm_resp
    command_status = 0              # Expect success.

send submit_sm
    source_addr = "0274022020"
    destination_addr = "0274022023"
    short_message = octets "I'm still here"

receive submit_sm_resp
    command_status = 0              # Expect success.

end

To handle multiple messages on the SMSC, you must create a loop. For example:

accept smpp_smsc
    repeat
        receive submit_sm
        send submit_sm_resp
    end
end

The repeat statement specifies that the set of statements before the first end statement will repeat indefinitely until a message causes the SMSC to disconnect from the ASP. The first end statement specifies the end of the statements to be repeated, that is, the end of the loop. The second end statement terminates the script.

See "Controlling Loops" for more information about controlling loops.

Rejecting Messages

You might not want to accept all messages. The following script segment rejects messages that contain the word bad:

accept smpp_smsc
    repeat
        receive submit_sm
            short_message = octets "bad"
        send submit_sm_resp
            command_status = 1 # Failure

Using Variables

You can use variables to save values while the script is running. The following SMSC script saves the message_id field in query_sm to a variable named $MID and then uses it to set message_id in the query_sm_resp operation:

    receive query_sm
        message_id -> $MID
    send  query_sm_resp
        message_id = $MID
        final_date = "2005071815234500Z"
        message_state = 1
        error_code = 0

Note:

The mipt utility has many reserved words and using a reserved word as a variable name will result in an error. If you prefix your variable name with a $, you can avoid conflicts with reserved words.

Controlling the Message Flow

The mipt utility provides several statements that enable you to control the flow of messages in the script.

Providing an Alternate Flow

The following script example uses the or statement to direct the flow to an alternate path if a message does not meet a specific condition:

accept smpp_smsc
    repeat
        receive submit_sm
            short_message = octets "bad"
        send submit_sm_resp
            command_status = 1 # Failure

    or
        receive submit_sm
        send submit_sm_resp
    end
end

Controlling the Processing Sequence

When you send two messages at the same time, the replies could arrive out of order. The following is an example of sending two messages:

send submit_sm
    source_addr = "0274022020"
    destination_addr = "0274022023"
    short_message = octets "bad"

send submit_sm
    source_addr = "0274022020"
    destination_addr = "0274022023"
    short_message = octets "good"

receive submit_sm_resp
    command_status = 0  # success

receive submit_sm_resp
    command_status != 0 # failure

In this case, you do not know the order in which the replies will come so either response could be handled incorrectly as a success or a failure.

You can use the and operation to send two messages at the same time and ensure that the results are processed in the correct sequence. In the following example, the and operation allows you to send two statements at the same time and associate the receive operations with the correct send operations:

begin
    send submit_sm
        source_addr = "0274022020"
        destination_addr = "0274022023"
        short_message = octets "bad"
    receive submit_sm_resp
        command_status != 0 # failure
and
    send submit_sm
        source_addr = "0274022020"
        destination_addr = "0274022023"
        short_message = octets "good"
     receive submit_sm_resp
         command_status = 0 # success
end

The begin and end keywords define the scope of the and operation. In this case, the first receive operation will match only the first send operation, and the second receive operation will match only the second send operation.

The SMSC should be able to respond to query_sm requests as well as submit_sm requests. The following example uses the and operation to run two loops in parallel to respond to both query_sm and submit_sm requests:

begin
    repeat
        receive query_sm
            message_id -> MID
        send  query_sm_resp
            message_id = MID
            final_date = "2005071815234500Z"
            message_state = 1
            error_code = 0
    end
and
    repeat
        receive submit_sm
        send submit_sm_resp
    end
end

Controlling Loops

You can add options to the repeat operation to specify a rate or time that controls how many times or how long a loop will continue. For example, mipt does not know when to stop the following loop, which continuously sends enquire_link operations from the ASP to the SMSC:

repeat
    send enquire_link
    receive enquire_link_resp
    sleep 1 # Wait a second
end

You can limit how long a loop will repeat by specifying a time limit after which it will stop. The following loop repeats for up to 10 seconds:

repeat for 10 seconds
    send enquire_link
    receive enquire_link_resp
    sleep 1 # Wait a second.
end

You can also repeat the loop at a particular pace by specifying a rate of hertz, which is one iteration per second. The following example repeats the loop at a uniform distribution of 2 hertz for a duration of 10 seconds:

repeat uniform 2 hertz for 10 seconds
    send enquire_link
    receive enquire_link_resp
end

You can also specify intervals instead of frequencies. In this example, uniform 0.5 seconds means one iteration every 0.5 seconds, which is equal to 2 hertz:

repeat uniform 0.5 seconds for 10 seconds
    send enquire_link
    receive enquire_link_resp
end

You can also ramp the rate up and down gradually. This example ramps up the rate from 0 to 10 hertz over a period of 5 seconds and then holds it at 10 hertz for a period of 6 seconds:

repeat uniform (5 seconds) 10 hertz for 6 seconds
    send enquire_link
    receive enquire_link_resp
end

This example ramps up the rate and then switches rates twice:

repeat poisson 10 hertz (10 seconds) 20 hertz () 1000 hertz (100 iterations)
       1000 hertz () 1 hertz for 20 seconds

This statement has the following effect on the loop:

Uses a Poisson distribution model
Ramps up from 10 hertz to 20 hertz over 10 seconds
Switches to 1000 hertz for an average of 100 iterations, 1 iteration every 0.001 second for about 0.1 seconds
Switches back to 1 hertz
Runs for a total of 20 seconds

The following example demonstrates the implicit flow control in a mipt script. It sends messages as fast as possible until an error is returned:

send submit_sm
    source_addr = "0274022020"
    destination_addr = "0274022023"
    short_message = octets "spam"
 
repeat
    receive submit_sm_resp
        command_status = 0 // OK
    send submit_sm
        source_addr = "0274022020"
        destination_addr = "0274022023"
        short_message = octets "spam"
end

receive submit_sm_resp
    command_status != 0 // OK

The fields and values within the receive section, such as command_status = 0, specify the expected values. If the actual value received does not match the expected value, mipt generates an Unmatched packet error, which would terminate the loop in this case.

Using the RADIUS Protocol

The following example of a mipt script for the RADIUS protocol simulates a short prepaid billing session. The connect statement specifies the RADIUS protocol. The name of the script file can be anything.

connect radius_raw udp 'radius-server-hostname' 1812 packet radius_secret = octets "SECRET"
 
      # Initial request for quota allocation
      send access_request
         user_name = '0219393571'
         radius_correlation_id = '12345678'
         nas_identifier = '12345'
         PPAC = {
            PPAC__select_for_session = octets 00 00 00 10  #Duration accounting
         }
 
      # Assume successful response and a quota allocated
      receive access_accept
 
      # Wait 10 seconds before disconnecting
      sleep 10
 
      # User disconnects
      send access_request
         radius_correlation_id = '12345678'
 
         radius_service_type = 17 # 'Authorize only', i.e. this is an "on-line" Access-Request
 
         PPAQ = {
            PPAQ__quota_identifier = 1
            PPAQ__duration_quota = 10
            PPAQ__update_reason = octets 00 06  # Client Service termination
         }
 
      # Acknowledgement from the radius server
      receive access_accept
 
   end

Using mipt as a Diameter Client or Server

You can send Diameter messages over either a transmission control protocol (TCP) transport or a stream control transmission protocol (SCTP) transport. This section describes how to create a connection as a Diameter client and how to listen for a connection as a Diameter server, as well as how to send an error message.

See "Supported Protocol Fields for mipt", for a list of fields that the mipt utility supports for the Diameter protocol.

Connecting as a Diameter Client

Use the following format of the connect message to create a connection as a Diameter client in raw mode:

connect diameter_raw <protocol> <hostname> <port>

For example, the following connect statements establish Diameter client connections for the TCP and SCTP protocols, respectively:

connect diameter_raw tcp my_host 3868
connect diameter_raw sctp my_host 3868

You can also create a connection using cooked or agent mode, which have the following formats:

connect diameter_cooked <protocol> <hostname> <port>
connect diameter_agent <protocol> <hostname> <port>

There is no difference between cooked and raw mode when mipt is running as a Diameter client. When mipt is running as a Diameter server and using cooked mode, it automatically responds to Device-Watchdog-Request messages so that you do not need to handle them explicitly in the script.

The agent mode is similar to cooked mode except that it automatically performs a basic Capabilities-Exchange at the beginning of the connection.

The following script example connects to a Diameter server, performs a basic Capabilities-Exchange, sends a Credit-Control-Request (CCR) message, and waits for the answer:

connect diameter_agent 'server-hostname' 3868

    send CCR
        end_to_end_identifier = 55
        session_id = 'session id oh yeah'
        origin_host = 'host.example.com'
        origin_realm = 'host.example.com'
        destination_realm = 'host.example.com'
        auth_application_id = 1
        service_context_id = 'service context id woohoo'
        cc_request_type = 0
        cc_request_number = 1
        cost_information = {
            unit_value = {
                value_digits = -1000
                exponent = -20
            }
            currency_code = 888
            cost_unit = 'Polish Zlotys'
        }
 
    receive CCA
        end_to_end_identifier = 55
 
 end

Accepting a Connection as a Diameter Server

When mipt is running as a Diameter server, use the following format to listen for and accept a connection:

accept diameter_raw <protocol> <port>

The value of <protocol> is either TCP or SCTP and <port> is the port number to which mipt is listening.

Sending a Diameter Error Message

You can send a Diameter error message by sending an answer message and explicitly setting the error bit in the command_flags field, as shown in the following example:

send CCA    command_flags = 0x20  # Error bit    session_id = 'session id oh yeah'    error_message = 'Error #12345'