Extensions to ns-2 simulator

Extensions to NS-2 RTP code

---

In this page we describe the extensions made to RTP code in ns-2. Our work mainly is divided into two main areas:

• Providing the RTP code the additional functionality defined in RFC 3550.
• Employing TCP friendly bandwidth share mechanisms for experimental use.

The extensions made in the ns-2.30 version on a Linux platform running Fedora 6 operating system. The extensions are also available for ns-2.31.

Software Architecture

The structure of the RTP code with the UML diagram is depicted in figure 1. We define new data structures named server_reportand receiver_report to store the fields of the RTCP SR and RR respectively. A new class named RTPReceiver was declared to hold the fields that are used by the receiving sources for QoS measurements. Every new instance of the RTPSession class creates two instances of the RTPSource and one instance of the RTPReceiver classes, accordingly. The RTPSessionClass is called via the TCL script and in turn two new Agents (RTPAgent and RTCPAgent) are assigned to every node in the network that participates in the multicast stream. The RTPAgent holds all the functionality for sending and receiving RTPUP packets whereas the RTCPAgent is responsible for the transmission and reception of the RTCPUP sender and receiver reports. We have implemented a one-to-many scheme of the RTP/RTCP protocol in which one sender transmits a multicast stream to a set of receivers. It is however, easy and quite straightforward to extend the code so that a node can be a receiver and at the same time an active sender. This applies to VoIP applications in which, the sender is also a receiver during the VoIP session. Finally, new functions are also used for the implementation of the algorithms described in the previous section.

Figure 1. UML diagram of the RTPUP code

 

TCP Friendly Bandwidth Share Estimations

The subject of transmission of TCP friendly flows over networks has engaged researchers all over the world, [4], [5] and [6]. Various adaptation schemes deploy an analytical model of TCP [4] in order to estimate a TCP friendly bandwidth share. With the use of this model, the average bandwidth share () of a TCP connection is determined (in bytes/sec) with the following equation:

where  is the receiver's estimation of the TCP friendly bandwidth share, P is the packet size in bytes,  is the packet loss rate,  is the Round Trip Time (RTT) of the TCP connection. If the receiver does not experience packet losses, in order to estimate a TCP friendly bandwidth share , the  must not be increased more than a packet / RTT. For this reason the receiver calculates the value of  with the following equation (in bytes/sec):

 

Each time the receiver sends a receiver report to the sender it includes the average value of  since last receiver report.

Packet Loss Rate Estimation

Every receiver that joins the RTP session can measure the packet loss rate based on RTP packets sequence numbers. In order to prevent a single spurious packet loss having an excessive effect on the packet loss estimation, the receivers smooth the values of packet loss rate using the filter presented in [7], which computes the weighted average of the m most recent loss rate values. The authors of [7] have also evaluated this filter and the results are very positive.

RTT Estimations

When a receiver i receives a RTP packet from a sender, it uses the following algorithm to estimate the RTT between the sender and the receiver:

            if no feedback has been received before
                  RTT = sqrt(effective_RTT)
            else
                  RTT = q * RTT + (1-q) * effective_RTT 

where, q has a default value of 0.9
 

This calculation is based on the sender estimation of the RTT time (effective_RTT) and is measured by using the timestamps of the RTCP sender and receiver reports. The algorithm above is described in [16] with the difference that in the TRFC specifications the RTT estimations are made by the sender. In our implementation we have the receivers estimating the RTT time.

Interarrival Jitter Estimations

Our implementation for delay jitter calculations is based on the algorithm defined in RFC 3550. Shortly explaining, let  is the RTP timestamp from packet i, and  is the time of arrival in RTP timestamp units for packet i, then for two sequentially packets i and j, D may be expressed as:

 

This delay variation should be calculated for each RTP packet. RFC 3550 suggests a filter function to avoid temporal fluctuation and the delay jitter is computed with the use of the following equation:

 

All the above described algorithms are implemented in our RTP modified code.

Related Publication

Download Source Code, Documentation