TTCN-3 Users Conference Practical application of TTCN-3 for network verification with common TTCN-3 Runtime Interface (TRI) for multiple interfaces TTCN-3 Users Conference Rajesh Kumar Bathina, Technical Leader, Wipro Technologies

Candidate Details Photo Rajesh Kumar Bathina Wipro Technologies Name Rajesh Kumar Bathina Organization Wipro Technologies E-Mail ID kumar.rajesh@wipro.com Phone number +49 151 4350 5388 Date of Presentation 13th June’ 2012 2

Overview 3

Overview Technical Problem TTCN-3 is widely accepted for wireless network verification with TRI (TTCN-3 Runtime Interface) towards various protocol interfaces. Ports defined with specific TRI can handle the send/receive messages towards the System Under Test, which also involves encoding/decoding. Practically, there were some scenario’s which we have faced during our network testing that we could not automate using TTCN-3 alone. Some requirements we found difficult to automate includes Man Machine Language commands required to be sent to the Network Element during the testcase execution or as preamble/postamble. Connectivity to configuration servers to run batch scripts to alter the NE behavior special configuration setup required during the test case execution Database (ODBC) modifications using scripts during the test case execution Configuration changes to Non SUT Network elements during execution Subsequent slides will provide the details of our approach to address above issues. 4

How is it achieved Mediation Server ODBC SUT TRI MML connectivity TSI MTC GSM2 GSM1 SUT TRI MS MSA MSB Mediation port CP Communication port (CP) Mediation Server ODBC MML connectivity SQL / SQL Lite SSH / Telnet SSH / Telnet Config Server

How is it achieved cont… Common TRI (Mediation Port) A commonly defined port (Mediation Port) in Master Test Component (MTC) is introduced which accepts a message with script name and parameters to the script The TRI will connect to a common Linux Server called Mediation Server where we can store the scripts that are required to be executed when needed from TTCN-3 On receiving a message from Mediation Port the TRI will initiate the execution of the scripts with the parameters supplied via the messages. Execution of the intended scripts will happen in the Mediation Server Scripts can be in any language and the selection can also be performed based on the parameter we pass in the message. Mediation Server / Mediation Device A simple Linux server configured within the same IP segment as that of the external devices is used All required packages/Modules were installed (example Perl SSh, Perl SSh Expect, Perl Telnet Etc.) Command Line Shell For SQLite is configured so as to access the database tables.

Detailed Approach Preamble.sh par1 par2 Postamble.sh par1 par2 External Connections We introduced a single port from MTC and can still be able to execute multiple scripts (shell scripts in our case) through the TTCN-3 test case. Perl SSh, Perl SSh Expect or Perl telnet modules were also successfully tested for special configuration setup required during the testcase execution. The common connectivity to Mediation server is achieved by having a defined set of messages to be sent/received from Mediation ports (e.g. as shown below): type port Mediation_port message   {     inout MD_UNIXcmd,          MD_UNIXresp   } type record MD_UNIXcmd   {     PDU_MD_UNIXcmd msg   }// end type record MD_UNIXcmd 7

Detailed Approach Cont… The message can also contain various fields like the script name, parameters to the script, execute user identification. A wrapper / template function is used in order to populate the actual message structure with the script name to be executed, user id to execute the scripts and parameters to the script. MD_Script_execution_SR(Userid, Mediation_port, “ODBC_transaction.sh”, "parameter_to_sh"); ... MD_Script_execution _SR(in template charstring userID, in template charstring id_ne_script, in template charstring param1, in template charstring param2) := { user := userID id := id_ne_script, action_RENAMED := MD_action_change, parm := name := "param1", value_RENAMED := string := param1 } }, name := "param2", string := param2  

Detailed Approach Cont… On reception of the message from Mediation Port, the TRI will execute the scripts on the Mediation Server directly passing the parameters supplied through the TTCN-3 scripts. The TRI will first lock the script before executing it so that no other parallel execution can be run. As soon as the execution of the scripts is completed, the TRI will unlock the scripts and sends back the UNIXresp to the Mediation Port which can further be validated in the TTCN-3 for specific response. Avoiding Deadlock Locking and unlocking of scripts during execution so that the same scripts cannot be accessed via parallel execution. During the postamble phase all the connections established with the Mediation Server should be closed so that the consecutive executions will not get blocked.

Benefits of this Approach Advantages of using this approach are: MML commands required to be sent to the Network Element during the testcase execution or as preamble/postamble.  Database (ODBC) modifications using Command Line SQL/SQLite scripts during the testcase execution  Configuration changes to Non SUT Network elements during execution were achieved.  Perl SSh, Perl SSh Expect or Perl telnet modules can be used for special configuration setup required during the testcase execution. This approach will be reduced compilation times when change is needed as the changes can be moved to the scripts (shell or perl) which does not require any compilation. This approach will be very handy if there are different interfaces that needs to be developed over a short duration and with the help of the scripts (perl or shell) we can achieve most of our requirements like ODBC access and interactive scripts execution via Perl SSH expect. We only have to call the scripts when required from the TTCN-3. Interop between MTC and non SUT is possible by using this approach where any configuration changes needed during the execution that affects the behaviour of SUT can be achieved. Organizational Benefits: This can be integrated with existing suites.The defined message structure is re-usable in various testing scenarios. Most of our network testing and system testing will require us to perform some interface parameter modification during the execution which can be achieved through this approach. The message structure can be made an ASN.1 notation format and can be re-used in conjunction with various testing requirements. 10

Thank You Rajesh Kumar Bathina Wipro Technologies