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.
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.
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, ,  and . Various adaptation schemes deploy an analytical model of TCP  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 , which computes the weighted average of the m most recent loss rate values. The authors of  have also evaluated this filter and the results are very positive.
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)
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  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.
Adaptive Smooth Multicast Protocol is a new congestion control scheme for multimedia transmission over best-effort networks.The smoothness lays in the calculation and adaptation of the transmission rate, which is based on dynamic estimation of protocol parameters and dynamic adjustment of the "smoothness factor". ASMP key attributes are:
a) smooth transmission rate
b) adaptive scalability to large sets of receivers
c) TCP-friendly behavior
d) high bandwidth utilization, and finally
ASMP and TFMCC comparison
We evaluate the performance of ASMP under an integrated simulation environment, which extends ns-2 and Evalvid-RA into the multicast domain with the use of RTP/RTCP protocols. Simulations conducted under this environment combine the measurements of network metrics along with objective evaluation criteria on the perceived video quality by the end user.
You may find the original Evalvid-RA here
The Adaptive Smooth Simulcast Protocol (ASSP) is a new multiple-rate for simulcast transmission over best-effort networks. ASSP iemploys a single rate TCP-friendly protocol as the underlying congestion control mechanism for each simulcast stream. ASSP is build on top of the RTP/RTCP protocol and exploits the RTCP sender and receiver reports for the dissemination of feedback information. The key attributes of ASSP are:
a) TCP-friendly behavior
b) adaptive per-stream transmission rates
c) adaptive scalability to large sets of receivers, and finally
d) smooth transmission rates that are mainly suitable for multimedia applications.
We evaluate the performance of ASSP and investigate its behavior through extensive simulations, conducted with the network simulator software (ns-2).
ASSP and Evalvid-RA for simulcast transmission of MPEG-4 video files
In this work we evaluate the performance of ASSP under an integrated simulation environment, which extends ns-2 and Evalvid-RA into the multicast domain with the use of RTP/RTCP protocols. Simulations conducted under this environment combine the measurements of network metrics along with objective evaluation criteria on the perceived video quality by the end user.
Latest version of ASSP source code with Evalvid-RA extensions can be found here
Comparison of ASSP against SMCC
Significant research effort over the last few years has liberated noticeable solutions in the area of multicast transmission. Although single rate control schemes are more mature and easy to deploy they suffer from low applicability. The diversity of receivers requires multi-rate multicast solutions as they exhibit better scalability. SMCC is a well-defined solution in the area of multi-rate congestion control schemes which employs cumulative layered multicasting. However, the benefits of layered multicast versus simulcast are not yet well investigated, as layered multicast presents higher complexity and more complex deployment than simulcast. In this work we present a simulation-based comparison of SMCC against ASSP. We compare ASSP against SMCC under a controlled simulation environment with the network simulator software (ns-2).
Download Source Code with Simulation Scripts
- Christos Bouras (Professor at Computer Engineering & Informatics Department& Scientific Coordinator of Lab of Distributed Systems and Telematics
- Apostolos Gkamas (Computer Engineer, PhD Researcher)
- Georgios Kioumourtzis (PhD candidate)
Additional information about the members of our team are available in the People area of the website, where full CVs as well as the publications and the projects that they participate are available.
-  MPEG - 4: ISO / IEC JTC1 / SC29 / WG11 N4668.
-  W. Li, "Overview of Fine Granularity Scalability in MPEG-4 Video Standard," IEEE Trans on Circuits and Systems for Video Technology, Vol. 11, No. 3, March, 2001, pp.301--317.
-  M. van der Schaar, D. Sai Shankar N, "Cross-layer wireless multimedia transmission: Challenges, principles and new paradigms, IEEE wireless Communications, August 2005
- J. Pandhye, J. Kurose, D. Towsley, R. Koodli, "A model based TCP-friendly rate control protocol", Proc.International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV), Basking Ridge, NJ, June 1999.
- D. Sisalem, A. Wolisz, "MLDA: A TCP-friendly congestion control framework for heterogeneous multicast environments", in Eighth International Workshop on Quality of Service (IWQoS 2000), Pittsburgh, PA, June 2000.
- L. Vicisiano, L. Rizzo, J. Crowcroft, "TCP - like congestion control for layered multicast data transfer", in IEEE INFOCOM, March 1998, pp. 996 - 1003.
- L. Vicisiano, L. Rizzo, J. Crowcroft, "TCP - like congestion control for layered multicast data transfer", in IEEE INFOCOM, March 1998, pp. 996 - 1003.
-  Jie Chen, Tiejun Lv and Haitao Zheng. "Cross-layer design for QoS wireless communications", Proceedings of the 2004 International Symposium on Circuits and Systems, 2004. ISCAS '04, Volume: 2, On page(s): II- 217-20 Vol.2, May 2004.
-  Carneiro, G. Ruela, J. Ricardo, M, "Cross-layer design in 4G wireless terminals", IEEE Wireless Communications, Volume: 11, Issue: 2, page(s): 7- 13, Apr 2004.
- S. Choudhury and Jerry D. Gibson, "Joint PHY/MAC Based Link Adaptation for Wireless LANs with Multipath Fading", IEEE Wireless Communications and Networking Conference, 2006, Vol2, On pages 757-762, Apr 2006.
-  C. Verikouris, L.Alonso, T. Giamalis, "Cross-layer optimization for wireless systems: A European research key challenge", Global Communications Newsletter, July 2005.
-  Jie Chen Lv, T. Haitao Zheng, "Joint cross-layer design for wireless QoS content delivery", IEEE International Conference on Communications, Volume: 7, page(s): 4243- 4247, June 2004.
-  H. M. Radha, M. van der Schaar and Y. Chen, "The MPEG-4 Fine-Grained Scalable video coding method for multimedia streaming over IP", IEEE Transactions on Multimedia, Vol. 3, No.1, March 2001.
-  T. Ahmed, A. Mehaoua, R. Boutba and Y. Iraqi, "Adaptive packet video streaming over IP networks: A cross-layer approach", IEEE Journal on selected areas in Communications, Vol. 23, No. 2, February 2005.
-  T.Goff, J. Moronski, D. S. Phatak, and V. Gupta, "Freeze-TCP: A true end-to-end TCP enhancement mechanism for mobile environments," in Proc. 19th Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM' 99), vol. 3, p. 1537-1545, Tel Aviv, Israel, March 2000.
-  RFC 3448, M. Handley, S. Floyd, J. Padhye, J. Widmer, "TCP Friendly Rate Control (TFRC)", Network Working Group, January 2003
-  RFC 3550, RTP: A Transport Protocol for Real-Time Applications, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, July 2003
-  RFC 2326 Real Time Streaming Protocol (RTSP). H. Schulzrinne, A. Rao, R.Lanphier. April 1998.
-  RFC 3261 SIP: Session Initiation Protocol. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. June 2002.
-  RFC 2475, "An Architecture for Differentiated Services", S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, December 1998
-  J. Pandhye, J. Kurose, D. Towsley, R. Koodli, "A model based TCP-friendly rate control protocol", Proc. International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV), Basking Ridge, NJ, June 1999.
-  D. Sisalem, A. Wolisz, "MLDA: A TCP-friendly congestion control framework for heterogeneous multicast environments", in Eighth International Workshop on Quality of Service (IWQoS 2000), Pittsburgh, PA, June 2000.
-  L. Vicisiano, L. Rizzo, J. Crowcroft, "TCP - like congestion control for layered multicast data transfer", in IEEE INFOCOM, March 1998, pp. 996 - 1003.
-  A. Alexiou, D Antonellis, C. Bouras, "Adaptive and reliable video transmission over UMTS for enhanced performance", International journal of Communication systems, Vol. 20, issue 1, pp. 65-81, 2007