Voice over IP through System in the loop

Simulation using the OPNET SITL module to analyze QoS in a VoIP call -Akash Puthraya -Sreenivas Ravi

Abstract
System-in-the-loop module in OPNET allows real systems to connect to simulations. A VoIP call is made from one real computer to another through a simulated system. The call quality, before and after simulating various load effects on the simulation, is observed.

SITL - what? why?

OPNET does not restrict analysis to networks that are completely simulated from end to end. It allows its simulations to be part of a bigger, real, live network. As this simulated network, and all its attributes are under the control of the user, the user is able to test and observe various conditions on a network or service.

What the module adds:

SITL gateway: allows simulation to connect to a real network through a Network adapter. SITL virtual ethernet link: is used to connect two SITL components together and also to connect a SITL component with another.

SITL Gateways
SITL gateways are virtual gateways to the real world. Real world devices (our laptops) are connected to these gateways on the simulation through the ethernet cards of the machine running OPNET.

These are not real nodes.

SITL Gateways

Voice over IP
The delivery of a real time voice data stream over an IP network, is Voice over IP. Voice is captured on the ends of communication, converted to data packets and transmitted over the IP network, rather than PSTN as in the case of normal calls.

MicroSip
Most VoIP services require connection to a central server through which authentication info and call initiation must pass through, e.g. Skype uses Microsoft servers. This is not useful for our setup, as we need all transactions to pass through only the network in our control. MicroSip is used for this. It is an open-source VoIP application that allows for IP-IP calls in the same subnetwork.

The SIP in Microsip

MicroSip utilizes the SIP and RTP protocols for a Voice call. When a user makes a call, the invite to start a data transfer session is sent as a SIP packet. After the invite has been accepted and a session has begun, subsequent data transfers are made using RTP packets. All voice data from both ends are sent using RTP. Hence, our SITL gateways must be defined to catch SIP and RTP packets.

SITL - The compiler needs to be run differently

SITL does not run using the <stdmod> library repository like standard simulations. In order to have a unified runtime environment for the real and the simulated packets, SITL uses Microsoft Visual Studio by running vcvarsall.bat from the OPNET console.

SITL - The compiler needs to be run differently

Packet of reality to simulation

When a packet of data is sent from the real setup to the SITL gateway, it needs to be caught, filtered, and converted to a format that is used by the simulation. For this, the SITL module calls on the WinPCap. Using filter syntaxes, the exact specification of the packet that we wish to be analyzed by the simulation can be specified. Eg: (arp or icmp) and ether src 30:85:a9:05:2c:a7

SITL- three scenarios

There are three types of scenarios in which SITL is used: 1. Real-Sim simulations 2. Real-Real simulations 3. Real-Sim-Real simulations

Real-Sim
The first step in our project was to test a RealSim project. Here, we got one of our laptops to ping a simulated workstation in OPNET (SITL) using SITL virtual ethernet links.

Real-Sim

Real-Real
The next step in our project was to test a RealReal setup. Here, we got one of our laptops to ping another laptop. This project was especially invigorating because this was Proof of Concept that SITL could make two laptops talk to each other directly.

Real-real

Real-sim-Real
Now that a direct real-real setup was established, the next step was to establish communication through a switch. The switch does not need to be configured, as its interfaces do not have IP addresses.
A switch was inserted and a VoIP connection was established.

Real-switch-real

Real-router-Real
Replacing the switch with a router is the first step at increasing the complexity of the network. Adding a router involves configuring the router to allow packets to be routed from one subnet to another.

Real-router-Real

Router configuration
The router runs RIP, and hence accepts RIP config commands. It is given static routing entries to ensure transmission of packets. We had to add the various subnets involved to our laptops' routing tables through the route add command. Eg.: route add <destination network> mask 255.255.255.0 <default gateway>

Router configuration

Real-sim-real
The next step in our project was to test a Realsim-Real project. Here, we got one of our laptops to ping another laptop through two simulated routers. The routers needed to be configured just like real world devices and we needed to add the routes of the router interfaces to our laptops' routing tables.

Real-sim-real

Real-sim-real setup without any load

Real-sim-real loaded

Real-sim-real setup with added load: ip_traffic_flow starts 1 minute after simulation begins

Results
No-Load conditions Delay conditions Load conditions

Terminal A to Terminal B

Terminal A to Terminal B

1 Gbps Traffic

Terminal B to Terminal A

Terminal B to Terminal A

1 kbps Traffic

Results
No-Load conditions Delay conditions Load conditions

Terminal A to Terminal B

Terminal A to Terminal B

1 Gbps Traffic

Terminal B to Terminal A

Terminal B to Terminal A

1 kbps Traffic

Results

More packets destroyed with 1 Gbps load

Less packets destroyed with 1 kbps load

THANK YOU