1. TTCN-3 User Conference 2012 Presentation Proposal
June 11-14, 2012, Bangalore, INDIA page 1 of 3
Name of Authors: Rajesh Kumar Bathina
Name of Presenter: Rajesh Kumar Bathina / Jayakishor Bhanja
E-mail of Contact Person: Kumar.rajesh@wipro.com
Telephone Number: +49 151 4350 5388
Contact Address: Telefonica O2 Germany GmbH,
Room No C116, Georg Brauchle Ring, 23-25
80992 München
Presentation Title: Practical application of TTCN3 for network verification with common TRI for
multiple interfaces.
Intended Audience: TTCN3 users
Summary of Presentation
TTCN3 is widely used for wireless network verification and with TTCN3 Runtime Interface towards
various protocol interfaces. Ports are defined with specific TRI to handle the messages sent to and
from these ports which also involves encoding/decoding.
Though we can have multiple ports to communicate with the SUT, there will be some scenarios which
cannot be completely automated using TTCN3. Some of the scenarios that we had issues in
automating are MML connectivity from TTCN3 to SUT, Database connectivity from TTCN3,
Connectivity to a different network element etc.
In order to overcome this limitation we can use Perl/Shell scripts to perform specific activities which
can be called from TTCN3. In one of our testing approach, we used a commonly defined port
(Mediation Port) in Master Test Component (MTC) which accepts a message with script name and
parameters to the script. The TRI for this commonly defined port will always connect to a common
Linux Server (Mediation Server) where we can have all the scripts that are required to be executed
when needed from TTCN3. On receiving this message the TRI will initiate the execution of the scripts
with the parameters supplied via the messages. The scripts can be in any language and the selection
can also be performed based on the parameter we pass in the message.
This way we can have a single port from MTC and can still be able to execute multiple scripts (shell
scripts in our case) through the TTCN3 test case. Following were some major advantages of using
such Mediation Ports to execute the shell/Perl scripts:
Man Machine Language commands required to be sent to the Network Element during the testcase
execution or as preamble/postamble.
Database (ODBC) modifications using scripts during the testcase execution
Configuration changes to Non SUT Network elements during execution.
Perl Secure shell, Perl SSh Expect or Perl telnet modules can be used for special configuration setup
required during the testcase execution.
How is it achieved?

2. TTCN-3 User Conference 2012 Presentation Proposal
page 2 of 3
We can achieve the common connectivity to Mediation server 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
Thus the message should also contain various parameters like the script to be executed, parameters to the
script, execution user and type of script which is required by the TRI to decide the script type (sh or perl):
MD_Script_execution(Mediation_port, “ODBC_transaction.sh”, "parameter_to_sh");
Typical message used for our requirement will be like the following
where the script name and parameters are sent to the mediation port.
MD_Script_execution (in template charstring id_ne_script,
in template charstring param1,
in template charstring param2) :=
{
id := id_ne_script,
action_RENAMED := MD_action_change,
parm :=
{
{
name := "param1",
value_RENAMED :=
{
string := param1
}
},
{
name := "param2",
value_RENAMED :=
{
string := param2
}
}
}
}
On reception of the message from Mediation Port, the TRI should execute the scripts on the
Mediation Server directly. The adapter can be enhanced to first lock the script before executing it so
that no other parallel execution can be run.
TSI
MTC GSM2GSM1
SUT
TRI
MS
MSA
MS
MSB
Mediation
port
CP
Communication port (CP)
MediationServer
Mediation
port
ODBC

3. TTCN-3 User Conference 2012 Presentation Proposal
page 3 of 3
Evaluation Criteria
1. Which categories of your presentation are covered according to the Call for Papers?
(practical experiences, design/test process, training/education, future of TTCN-3, etc.)
Practical Experience and Test process improvement
2. What is the novelty in your presentation?
This approach is in use for the database handling from TTCN3 (ODBC) in our project. We also
execute some configuration changes through Perl SSH expect during the case execution. Usually the
DB changes are done as preamble and reverted back as postamble.
3. What are the benefits of your chosen approach or method over existing ones?
Main advantage of 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 TTCN3.
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.
4. How can the approach or method be re-used by other organizations?
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.
This can be integrated with existing suites.
Further Details (optional)