Extensions to ns-2 simulator

Home | Extensions to RTP code | Adaptive Smooth Multicast Protocol (ASMP) | Adaptive Smooth Simulcast Protocol (ASSP) | Our Team | References

Home

Real time multimedia applications have enjoyed the global interest over the last few years. These applications are characterized by three main properties: the demand for high data transmission rate (bandwidth-consuming applications), the sensitiveness to packet delays (latency and jitter) and the tolerance to packet losses (packet-loss tolerant applications), when compared to other kind of applications. The Transmission Control Protocol (TCP) is the dominant and the most widely used protocol at the transport layer. However, there are three characteristics of this protocol that makes it insufficient for real time data delivery:

• TCP has a built-in retransmission mechanism that may be in fact useless for delay-sensitive applications.
• TCP does not carry any time related information, which are needed by real time applications and lastly.
• TCP employs a "strict" congestion control mechanism that reacts even in the light of a single packet loss event.

On the other hand, the User Datagram Protocol (UDP) does not also provide any support for multimedia applications. Therefore, the need of a new protocol led the research community to design the Real Time Protocol (RTP) and the associated RTP Control Protocol (RTCP) in order to support multimedia applications. The RTP protocol constitutes a new de facto standard and is the dominant transport protocol for multimedia data transmission. The implementation of the RTP in NS2 is very generic. It provides only the main functions of a "common" transport protocol and runs on the top of the UDP. In this work we extended the functionality of the RTP and RTCP code in NS2 to include:

• Most of its feedback functions described in RFC 3550.
• TCP friendly behavior by the meaning that the transmitted flow consumes no more bandwidth than a TCP connection, which is traversing the same path with the transmitted flow

Real Time Protocol (RTP)

RTP is a real time transport protocol that is used usually on top of the UDP protocol (also other transport protocols are supported). By saying this we already accept a transport protocol on top of another transport protocol and this statement may be misleading. On the other hand, RTP is highly coupled to the application that it carries. Therefore, RTP would better be viewed as a framework for real time applications and not as just a transport protocol. RTP neither provides any guarantees for data delivery nor for sequencing packet delivery. The main functions of the RTP include:

• Identification of payload type
• Identification of the source sending the RTP packets
• Timestamps to the RTP packets
• Sequence numbers of the RTP packets

RTP Control Protocol (RTCP)

The RTCP protocol provides to participants of the RTP session feedback information of the network conditions. RTP and RTCP protocols use different port numbers. The main functions of the RTCP are:

• Network measurements for QoS (packet loss ratio, delay jitter, timestamps of sender and receiver reports etc)
• Identification of the source sending the RTCP packets
• Estimation of the session size and scaling mechanisms

The RTCP sender and receiver reports (SR) and (RR) provide direct information on the packet losses, cumulative number of the RTP packets sent by the source and delay jitter. They provide also additional fields that can be used for the implementation of congestion control policies by separate protocols, like for example TCP-like flow control which we have implemented. A separate entity like a network management can obtain network metrics based on the reception of the RTCP reports without actually taking part in the RTP session.

Other information carried by the RTCP packets include a source identifier of the transport layer (CNAME), the e-mail address, name, phone, location of the source originated the RTCP report.

Back to top

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