ISSN ONLINE(2320-9801) PRINT (2320-9798)

All submissions of the EM system will be redirected to Online Manuscript Submission System. Authors are requested to submit articles directly to Online Manuscript Submission System of respective journal.

Performance Evaluation of Multimedia Content Distribution over Multi-Homed Wireless Networks

Dr.K.P.Kaliyamurthie, D.Parameswari
  1. Professor and Head, Dept. of IT, Bharath University, Chennai-600 073
  2. Asst. Prof.(SG), Dept.of Computer Applications, Jerusalem College of Engg.,Chennai-600 100
Related article at Pubmed, Scholar Google

Visit for more related articles at International Journal of Innovative Research in Computer and Communication Engineering


The growing availability of IP based heterogeneous wireless access technologies coupled with the increasing capabilities of mobile devices is creating opportunities for multimedia distribution. Through its multi-homing feature, the ability to support multiple network connections in a single end to end association, the transport layer Stream Control Transmission Protocol (SCTP) can enable seamless and transparent communication sessions over multiple heterogeneous networks. This paper analyzes the performance of multimedia distribution when making use of two multihomingSCTPbasedapproaches: Single Path Transfer and Concurrent Multi-path Transfer, in which a single or all paths within an association are used simultaneously for data transmission. In this investigation various retransmission policies and different parameter sets are used in turn and recommendations are made for achieving best results during video delivery. In order to perform this study a novel realistic evaluation tool-set was proposed and is described, which can simulate video delivery over SCTP. Our simulation results and analysis show how to optimize the transmission of multimedia content over SCTP associations in both single and multipath scenarios.


Concurrent multi-path transfer, multi-homing, multimedia distribution, SCTP, single path transfer.


WIRELESS and mobile IP network environments have changed significantly in recent years. The emergence of wireless network topologies such as mobile self-organizing networks, mobile cellular networks, wireless mesh networks and wireless sensor networks have complemented traditional Wireless LAN (WLAN) deployments by increasing the ubiquity of wireless network coverage. IEEE 802.16 Worldwide Interoperability for Microwave Access (WiMAX) networks provide wireless coverage for metropolitan areas. IEEE 802.11 Wireless Fidelity (WiFi) networks offer local area wireless support and IEEE 802.15Wireless Personal Area Networks (WPAN) enable communications in the user neighborhood, including support for Body Area Network (BAN). Beyond 3G (B3G) cellular mobile networks, WPAN,WiFi andWiMax networks can be utilized to provide a truly ubiquitous IP networking service.
With the growing availability of IP based heterogeneous wireless access technologies, increasing number of mobile devices will be equipped with multiple wireless network interfaces, such as IEEE 802.11, 802.16, 802.15, B3G, etc. The capability to provide support for communication in the next generation heterogeneous Internet is of paramount importance. In this context the Internet Engineering Task Force (IETF) SIGTRAN Working Group has proposed a new transport layer protocol, the Stream Control Transmission Protocol (SCTP) which has an important feature: multi-homing. This ability to support multiple network connections in a single end to end association enables SCTP to support seamlessly, transparently and continuously communication sessions in any heterogeneous network environment. This is especially true with the mobile SCTP extension mSCTP, which enables dynamical addition and deletion of IP addresses to and from the association list end points during the association activity . The increasing computing power and storage capacity of mobile devices is creating opportunities for multimedia application support and development. The capacity of IP access networks in comparison to traditional mobile networks is attractive for the distribution of multimedia components such as voice and video, or triple play. The real-time nature of multimedia content distribution however, has stringent bandwidth, delay, and loss requirements. These requirements have significant performance implications for underlying networks and network protocols First developed for telephone signaling, SCTP gradually expanded into a general-purpose transport layer protocol which has been standardized as RFC 2960. Like TCP, SCTP provide reliable service and flow control mechanisms. In addition, similar to UDP, it can support unreliable transmission, which is called SCTP partial reliability (PR-SCTP) . It can differentiate the level of reliability provided to messages. SCTP can provide multi-stream and multi-homing services for a single connection. Combing the above discussing, SCTP will be good protocol selected for multimedia distribution over heterogeneous wireless networks as Fig. 1 shows.
Current SCTP deployments use multi-homing for fault tolerance in two ways:
• Single Path Transfer (SPT)—each endpoint chooses a single peer IP address as the primary destination address, which is used for transmission of new data during normal transmission. If the primary destination address becomes unreachable, the SCTP sender detects the failure, and switches to an alternate destination address to complete the transfer.
• Concurrent Multipath Transfer (CMT)—in this situation SCTP makes use of the in-built multi-homing support to perform simultaneous transfer of data over multiple independent paths between multi-homed source and destination hosts, increasing the application throughput. End-to-end delay and packet loss are vital Quality of Services (QoS) requirements for real-time multimedia applications, especially difficult to maintain at low levels in wireless networks.This is desired in order to achieve high user quality levels. Therefore it is important to investigate how these applications are affected by various networking conditions and how various solutions proposed improve application behavior.This paper extends the analysis started by looking at how various SCTP-based Single Path Transfer (SPT) and Concurrent Multipath Transfer (CMT) solutions improve end-user perceived quality levels during multimedia delivery over wireless networks. It considers a typical architecture for multimedia distribution which makes use of the SCTP multi-homing feature as illustrated in Fig. 1.
The main contributions of this paper are as follows:
1) It performs a comparative study of real-time multimedia transmission in SCTP Single Path Transfer (SPT) scenarios in a tolerant of network failure manner. This investigation evaluates the perceived end user video quality when different retransmission policies combined with various path failure detection thresholds, path bandwidths, delays and loss rate conditions are used in symmetric and asymmetric path environments respectively. Following this study, an optimum SCTP configuration scheme for SCTP video transmissions is proposed and recommended.
2) The paper analyzes the effect on end user perceived quality of utilizing various Concurrent Multipath Transfer (CMT) mechanisms during SCTP-based video delivery.
CMT, CMT with Partial Reliability (CMT-PR), CMT with Potentially Failed Destination (CMT-PF) and CMT Partial Reliable with Potentially Failed Destination (CMT-PF-PR) are used in turn with different parameters in order to complete the study. Results presented show how CMT-PR and CMT-PF-PR outperform CMT and CMT CMT-PF, respectively. Consequently, the paper recommends usage of the partially reliable CMT variants for real-time video distribution in concurrent multipath environments.
The remainder of this paper is structured as follows. In Section II, we introduced the simulation system architecture.
A comparative study of real-time multimedia transmission in SCTP Single Path Transfer scenarios is presented in Section III. Section IV presents the performance evaluation of distributing real-time video over SCTP CMT. Finally, conclusions are presented in Section V.


In order to properly evaluate the effect different multimedia delivery solutions have on the user perceived quality, the best is to have a prototype system, which would include real implementations of all delivery algorithms to be compared and subjectively measure user perceived quality following subjective testing over real networks differently loaded with generated traffic. However to build such a setup is expensive, time consuming and has little flexibility. Therefore, often network modeling and simulations with tools such as the Network Simulator 2 (NS2) are used instead as they are very cost-efficient and allow building and testing of customizable models and scenarios. Their biggest limitation is in terms of the accuracy user perceived quality assessment, as simulations do not process real data. SCTP-based multimedia streaming has been studied extensively recently. To the best of our knowledge, to date there is no publicly available toolset to perform comprehensive video delivery quality evaluation when employing SCTP network simulations. This section describes our video delivery quality evaluation tool-set which provides an accurate solution for simulating real-time video transmission over SCTP associations in both single and multipath scenarios and helps assess end user perceived quality.
A. Evaluating User Perceived Quality
The video delivery quality depends on the impression a human observer has on the received video. Subjective video quality test results are mostly expressed in terms of the Mean Opinion Score (MOS) as defined by the ITU . The MOS is measured on a scale from 1 (bad) to 5 (excellent). In contrast, objective video quality metrics are calculated based on equations or models, which only estimate user perceived quality with different degrees of accuracy. Among these metrics are pixel-based metrics such as Signal to Noise Ratio (SNR) or Peak Signal to Noise Ratio (PSNR), and psycho-visual metrics such as VQM and MPQM .
In recent years, many investigations have analyzed multimedia delivery through simulations. In MPEG-4 trace files are used to calibrate a Transform Expand Sample mathematical model, and rate adaptation is incorporated by adjusting the frame size output by a scalar (from rate-distortion curve). As the simulation model has no on-line rate controller, and the traffic is synthetic, the perceived quality cannot be investigated.H.263 video trace files are used in , and the sending rate is controlled by a DCCP TCP-like algorithm. In models are derived for pre-recorded media streaming using TFRC and compared to simulation results. The models focus on the impact of the TFRC rate changes to the probability of re-buffering events, i.e. events where the receive buffer is emptied. Evalvid is an open-source project, and supports trace file generation of MPEG-4 as well as H.263 and H.264 video. Using the NS2 interface code suggested by C.-H. Ke, the Evalvid can be integrated into NS2 simulator , but it only support TCP and UDP transport simulation. An evaluation tool called Evalvid-RA (Evalvid Rate Adaptive) based on Evalvid was proposed by the authors of . Evalvid-RA supports rate adaptive MPEG-4 VBR video simulations, but it also only supports TCP and UDP protocols.
B. Evaluation System Overview
In order to assess video quality we have designed a modelling and simulation evaluation system for MPEG- 4 video delivery when using SCTP in NS2, we enhance Evalvid and makes use of the Delaware University’s SCTP module for NS2. The system enables simulation of multimedia data transfer based on MPEG-4 video trace files, extracted from real video sequences . The trace files consist of characteristics of real compressed video and include information on frame number frame type, size, fragmentation into segments and timing for each video frame. These characteristics can be utilized to construct mathematical traffic models and traffic generators for network simulators since they determine the packet sizes and transmission schedules. The evaluation system transmits video over SCTP in NS2, while recording packet throughput at each node including the receiver. Using this information and the original compressed video file, our system reconstructs the video as if it was received over a real network. This reconstruction enables the reconstructed video to be assessed in terms of quality both visually and objectively via computed PSNR and MOS.Fig. 2 illustrates the evaluation system, which has three stages: pre-processing, SCTP-based network simulation of video delivery and post-processing. Table I shows most important tools and modules used in these three stages.
1) Pre-Processing Stage: As media encoding is very much processor demanding, encoding is often performed in a separate step which we denoted as pre-processing. In the pre-processing stage, the original video (i.e.YUVformat) is compressed into an MPEG-4 video (by the Video Encoder) and the trace file which includes information about each frame (I, P or B) is generated (by the Trace Generator). Fig. 3 shows the first Group of Picture (GOP) of a reference video. The number of packets needed to transfer one frame depends on the ratio between the frame size and the packet size.
2) SCTP-Based Network Simulation: This step of network simulation is shown in Fig. 2 on the upper right corner. The trace file is delivered by an enhanced SctpAgent to support SCTP-based Single Path Transfer and a novel SctpCMTAgent for CMT. They record sender trace file info including sending time, packet type, packet id and size. They also record receiver-related information including receiving time, packet type, packet id and size. Given certain packet size, the frames are typically fragmented into several packets. The tool can investigate video delivery quality over SCTP network with variation of different SCTP parameters such as Path Maximum Retransmissions(PMR), retransmission policies,retransmission timeout (RTO), and transmission reliability of the SCTP-PR under different path loss rates, path bandwidths and path delays.
3) Post-Processing Stage: The lower left corner of Fig. 2 depicts the main post-processing functionality.Using the output represent frame number, frame-type (H for header), frame size, number of segments,and offset from the start of video.trace files generated during network simulation and the media files produced during the preprocessing, our tool enables to offer several services including computation of statistics and metrics in relation to the simulated traffic . These are (1) loss rate computation; (2) delay measurement; (3) received media file considering packet loss and/or delay generation; (4) decoding of (possibly) erroneous media file; (5) playing decoded media; (6) calculation of PSNR and/or MOS (using receivedmedia and original media file). Additionally frame jitter can be calculated as in (1).
In (1) is number of frames, is the time-stamp of last segment of frame number and is the average of interframe times. Particularly, in the post-processing stage, the received video can be reconstructed, and subjective quality assessment can be performed using traditional methods, despite using network modeling and simulations for the actual data delivery.


A. Overview
SCTP’s multi-homing allows end systems to utilize multiple divergent paths in order to provide a measure of fault-tolerance against device or path failures. One of the peer’s addresses is designated the primary destination address, and during normal operation all user data is sent along this primary path. The other paths serve as alternative routes that may be used for sending retransmissions. In the event that the primary path fails, a failover is performed, and one of the alternate paths will then be used for transmitting user data. To aid in determining the reach ability status of the peer’s addresses, a heartbeat (HB) is periodically transmitted to each address. This mechanism helps to prevent sending retransmissions to alternate addresses that are unreachable and helps ensure that failovers are performed only to a known reachable destination address. During times of failover,the HB mechanism also serves to discover when the primary address once again becomes reachable. When it does, SCTP performs a failover restoration back to the primary path, allowing subsequent data packers to be sent along it. A number of user configurable protocol parameters are involved in SCTP operation, such as Path.Max.Retrans (PMR), RTO.Min, RTO.Max and HB.interval.
B. Related Works
SCTP congestion algorithms are inherited from SACK TCP, which include slow start, congestion avoidance and fast retransmit. In the authors present a detailed comparison between the congestion algorithms of SCTP and TCP. SCTP defines two retransmission algorithms: fast retransmission and timeout retransmission. The authors of have proposed and investigated three retransmission policies.
1) AllRtxAlt—All Retransmissions to an Alternate Path;
2) AllRtxSame—All Retransmissions to the Same Path;
3) FrSameRtoAlt—Fast Retransmissions to the Same Path,
Timeout Retransmissions to an Alternate Path.
These three retransmission policies with different extensions and the default SCTP parameters in various lossy environments are evaluated . The results show how FrSameRtoAlt with Multiple Fast Retransmission algorithm and the Timestamp or the Heartbeat after RTO extension performs best among the three policies and their respective extensions. AllRtxAlt performs the worst of all because of the stale RTO problem as mentioned.
In the authors studied the performance of different PMR settings with FrSameRtoAlt and the Multiple Fast Retransmission extension . The results show that can achieve best throughput in various path failure or nonfailure situations. The authors of investigate SCTP’s throughput performance in different path scenarios and proposed a change to the protocol’s heartbeat mechanism to improve the performance.The effect of path delay on SCTP performance was studied. It indicates that retransmission of all data on the same path with the path failure detection threshold set to one or zero gives the most stable performance in all path configurations.
studies the effect of path bandwidth differential on the performance of retransmission strategies in multihoming environments. It identifies that fast retransmission on an alternate path may cause receive buffer blocking when path bandwidth differential is significant and the receive buffer is limited. All of above researches focus on the performance of “FTP over SCTP”. We will use the proposed the tool-set investigate the performance of “multimedia over SCTP”.
C. Evaluation Setup
SCTP SPT-based multimedia delivery is evaluated via modelling and simulations, making use of the evaluation system described in Section II. For the network simulation stage, the topology employed which considers different network path conditions is shown in Fig. 4. It includes a SCTP sender (nodeS) and a SCTP receiver (node S). Both SCTP endpoints have two addresses. , , and are routers. The implementation is configured with no overlap between the two paths. The Maximum Transmission Unit (MTU) on each path is 1500 B. The queue length of bottleneck links in both paths is 50 packets. The queue length of all other links is set to 1000 packets, not to introduce any loss in the data delivery process. The SCTP parameters are the default ones which are shown in Table II. The initial slow start threshold is set large enough to ensure that the full primary path bandwidth is used.
SCTP version set is SCTP-PR and the numbers of retransmission for each packet are set to no more than two times. In these tests one SCTP stream is used and the data is delivered to the upper layer in order. For simulations with an infinite receive buffer, the receiver window (rwnd) is set to 100 MB as this size is larger than the data size transmitted by the sender. Network congestion is simulated by varying the path loss rate. The original video sequence used is known as Highway QCIF(176 144) which consists of 2000 frames with average quality. After pre-processing stage, a MPEG-4 video which includes 223 I frames, 445 P frames and 1332 B frames is produced.
Those frames are fragmented into 2250 packets which includes 463 packets for I frames, 453 packet for P frames and 1334 packets for B frames. A corresponding MPEG-4 video trace file including these packets information is fed to the NS2. These 2250 packets will be transferred over the SCTP network.
During network simulation, node S sends this video trace file to node R at a transmission rate equal with the playout rate.The simulation stops after S finishes sending all the frames. A new random seed is used for each one of the 30 simulations.Testing results are calculated by averaging the results of the 30 runs and rounded up to the nearest integer.
D. Symmetric Paths Environment
This section studies the performance of retransmission policies and PMR settings in symmetric path conditions. A computing node has two 3G connections and an infinite buffer. The bandwidth of both bottleneck links is set as 384 Kbps. The delays on the primary and secondary path are 250 ms, and the paths loss rates are set to 1%, 3% and 5% respectively. Aggressive failover and less aggressive failover settings are set respectively. The results for are not shown in this paper, as the path failure detection time becomes very long. For example for , SCTP needs 6 consecutive transmission timeouts to detect path failure, severely affecting delivery quality. RTO is doubled for each transmission timeout and ranges between the SCTP parameters RTO.Min and RTO.Max. The default values for RTO.Min and RTO.Max are 1 s and 60 s respectively. If RTO is 1 s (RTO.Min) in the case of a path failure, the minimum time for detecting path failure is . This is not reasonable for real-time video transmission which is highly time sensitive.
Following the evaluation, Table III shows for comparison the results in terms of average PSNR (dB), number of different dropped frames types (I-frame/P-frame/B-frame) and number of lost packets for transmissions which employed AllRtxSame, AllRtxAlt and FrSameRtoAlt as retransmission policies in turn, with aggressive failover and less aggressive failover respectively. As the table shows, with increasing path loss rate, the average PSNR values decrease and the numbers of lost packets and dropped frames increase in all cases. However, in most cases, aggressive failover setting performs better than the less aggressive. Retransmission of all data on an alternate path with aggressive failover performs the best. However, its performance degrades in the less aggressive failover case. Retransmission of all data on the same path performs in a more stable manner than other retransmissions configurations.
E. Asymmetric Paths Environment
This section studies the performance of retransmission policies and PMR settings in asymmetric path conditions. A computing node has a hybrid of 3G or GPRS connections and an infinite buffer. The primary path bandwidth is 384 Kbps and the secondary path bandwidth is 50 Kbps. The delay on the primary path is 250 ms, the delay of secondary path is 500 ms, and the loss rates of both paths are set to 1%, 3% and 5% respectively. Other settings are the same as in the previous tests. Table IV illustrates the comparison results in terms of average PSNR (dB), number of dropped frames for each type (I-frame/P-frame/B-frame) and lost packets for differentretransmission policies: AllRtxSame, AllRtxAlt and FrSameRtoAlt with aggressive failover and less aggressive failover respectively. As the table shows, with the increasing of path loss rate the average PSNR (dB) values decrease and the numbers of slipped frames and lost packets increase in all the cases. The total average video quality degrades compared with symmetric path conditions. In most cases however, setting less aggressive failover performs better than aggressive failover. Retransmission of all data on an alternate path performs worst in all the cases. Retransmission of all data on the same path performs in a more stable manner than other retransmission configurations under aggressive and less aggressive failover.
According to the Central Limit Theorem, we can use the 30 results of above two simulations to calculate 90% confidence interval with an acceptable error of 10% of the mean respectively. It shows that on average the 90% confidence interval is about 0.01–0.02 dB, 1–2 frames, and 1–5 packets around the mean. As the Tables III and IV show, the higher the packets loss the more dropped frames are recorded, which is very much expected.
F. Analysis
These test results presented in Tables III and IV and illustrated in Figs. 5–10 show that in most cases, aggressive failover setting performs better than less aggressive failover setting regardless of the path loss rates in symmetric path conditions. As we know, the underlying advantage of aggressive failover is that handover occurs with little time lost for failure detection.With ,a single timeout determines the migration of data transmission to the alternative path quickly, while the primary destination is probed with heartbeats. Aggressive failover setting could increase the possibility of spurious failover. This is as a small number of lost packets is interpreted to mean that the destination address is no longer reachable and sender mistakenly concludes that a failure has occurred.
However the alternate path has the same good path conditions with the primary path, which avoids negative impact by unnecessary failovers. So this scenario of symmetric paths with aggressive failover is actually a concurrent multi-path transmission, and then achieves better performance. However, our investigation revealed that when a bandwidth asymmetry did exist, aggressive failover was not good advice. Less aggressive failover setting generally outperforms aggressive failover setting in asymmetric path conditions. As the secondary path conditions are worse than primary path with less bandwidth and larger delay. In this scenario, as it is discussed in, there is a substantial advantage to sticking with the higher speed primary path, despite the fact that it is not functioning,and waiting for it to be restored, rather than switching over to the lower speed alternate path. The reason for this is that when SCTP stays with the primary path, it will more quickly discover when the path is again functional (by retransmitting user data using exponential back-off) than if it fails over to the alternate and relies upon the slower heartbeat (HB) mechanism to probe for the primary’s recovery. So with less aggressive failover mechanism, the worse secondary path is seldom used, which achieves better performance than that of aggressive failover mechanism.
The results show that all retransmissions to an alternate path with aggressive failover mechanism performs best in symmetric path conditions and degrades seriously in asymmetric path conditions. For AllRtxAlt, the lost data will be retransmitted on the secondary path, even for aggressive failover mechanism. Therefore, the performance will be degraded when the secondary path


A. Overview

SCTP implies the existence of a single buffer (rbuf) at the receiver transport layer which is shared across all the sub-association flows. This buffer is used to handle out-of-order data and received data at a rate higher than that of the receiving application’s consumption.Unfortunately demonstrates how a shared rbuf results in a sub-association flow on a higher quality path getting lower throughput than expected. Multiple paths present a sender with a choice where to send a retransmission of a lost transmission.With CMT, new data is being sent to all destinations concurrently. However shows that the common receiver buffer blocking cannot be completely eliminated. In order to cope with the resulting loss, different retransmission policies have been proposed:
1) RTX-SAME—Once a new data chunk is scheduled and sent to a destination, all retransmissions of the chunk are sent to the same destination (until the destination is deemed inactive due to failure).
2) RTX-ASAP—A retransmission of a data chunk is sent to any destination for which the sender has window (cwnd) space available at the time of retransmission. If multiple destinations have available window space, one is chosen randomly.
3) RTX-CWND—Retransmitted data is sent to the destination for which the sender has the largest cwnd. Any eventual tie is broken by random selection.
4) RTX-SSTHRESH—A retransmission is sent to the destination for which the sender has the largest ssthresh(Slowstart threshold). A tie is broken by random selection.
5)RTX-LOSSRATE—A retransmission is sent to the destination with the lowest loss rate path. If multiple destinations have the same loss rate, one is selected randomly.

B. CMT With Potentially-Failed State (CMT-PF)

To mitigate the effect of reoccurring events of receiver buffer blocking, authors introduced a newdestination state called “potentially-failed”. It is based on the rationale that loss detected by a timeout implies either severe congestion or failure in route. After a single timeout on a path, a sender is unsure if this is the case, and marks the corresponding destination as “potentially-failed” (PF). A PF destination is not used for data transmission or retransmission. CMT’s retransmission policies are augmented to include the PF state. CMT with the new set of retransmission policies is called CMT-PF. Relevant details of CMT-PF are:
1) If a Transport Protocol Data Unit (TPDU) loss is detected by RFC4460’s threshold number of missing reports, one of CMT’s current retransmission policies is used to select an active destination for retransmission;
2) If a TPDU loss is detected after a timeout, the corresponding destination transitions to the PF state. No data is transmitted to a PF destination;
3) Heartbeats are sent to a PF destination with an exponential backoff of RTO after every timeout until (i) a heartbeat acknowledgement transitions the destination back to the active state, or (ii) an additional PMR (Path.Max.Retrans) consecutive timeouts confirm the path failure, after which the destination transitions to the failed state, and heartbeats are sent with a lower frequency as described in RFC4460;
4) Once a heartbeat acknowledgement indicates that a PF destination is alive, the destination’s cwnd is set to either 1 Maximum Transmission Unit (MTU) (CMT-PF1), or 2 MTUs (CMT-PF2), and data transmission follows the slow start phase;
5) Acknowledgements of the retransmissions do not transition a PF destination to the active state.

C. CMT-PR and CMT-PF-PR Policies

The Partial-Reliable SCTP (PR-SCTP) is an unreliable data mode extension of SCTP, PR-SCTP allows an SCTP sender to assign different levels of reliability to data so that lost data can be retransmitted until a predefined reliability threshold is reached. When the reliability threshold is reached for unacknowledged data, the sender abandons that retransmission of the data and notifies the receiver (with Forward TSNs) to neglect the outstanding data and move the cumulative ACK point forward. For streaming multimedia content over SCTP, the reliability and thereby the retransmission of missing data could be the bottleneck for the guarantee of a desired frame rate. Sometimes it is necessary to drop a few missing packets, instead of waiting for them to be retransmitted, because they are no longer needed for the stream.
In this section, we investigate and evaluate considerations in implementing CMT and CMT-PF with Partial Reliability extension of SCTP, which we called CMT-PR (CMT-Partial Reliability) and CMT-PF-PR for real-time video distribution.
The following variations areconsidered for comparative evaluations of CMT and CMP-PR:
1) NPR-ASAP/SAME/SSTHRESH/LOSSRATE/ CWND—CMT with no PR-SCTP mechanism for each retransmission policy.
2) PR(0/1/2)-ASAP—CMT with RTX_ASAP retransmission policy and reliability threshold setting to 0, 1, 2 respectively.
3) PR(0/1/2)-SAME—CMT with RTX_SAME retransmission policy and reliability threshold setting to 0, 1, 2 respectively.
4) PR(0/1/2)-SSTHRESH—CMT with RTX_SSTHRESH as retransmission policy and reliability threshold setting to 0, 1, 2 respectively.
5) PR(0/1/2)-LOSSRATE—CMT with RTX_LOSSRATE as retransmission policy and reliability threshold settings 0, 1 and 2 respectively.
6)PR(0/1/2)-CWND—CMT with RTX_CWND retransmission policy and reliability threshold settings 0, 1, and 2 respectively.
The following variations are considered for comparative evaluations of CMT-PF and CMP-PF-PR:
1)PF(1/2)-NPRSSTHRESH/CWND—CMT-PF with no PR-SCTP mechanism for SSTHRESH and CWND retransmission policies respectively.
2)PF(1/2)-PR(0/1/2)-SSTHRESH—CMT with RTX_SSTHRESH retransmission policy, PF destination’s cwnd setting to 1 or 2 MTU when it is alive, and reliability threshold setting to 0, 1, 2 respectively.
3) PF(1/2)-PR(0/1/2)-CWND—CMT with RTX_CWND retransmission policy, PF destination’s cwnd setting to 1 or 2 MTU when it is alive, and reliability threshold setting to 0, 1, 2 respectively.
We will evaluate and compare the above different policies for MPEG-4 video transmission with SCTP/CMT by using the evaluation platform described in Section II.

D. Simulation Setup

If two paths are used for CMT, the lower quality (i.e., higher loss rate) path degrades overall throughput of an rbuf-constrained CMT association by blocking the rbuf. In order to investigate the behavior and quality of real-time video concurrent multipath transmission better, we focus on the following scenario of asymmetric path condition.
The simulation topology is shown in Fig. 11 and includes node S and node R which are the SCTP sender and receiver respectively. Both SCTP endpoints have two addresses are routers. The implementation is configured with no overlap between the two paths. The MTU of each path is 1500 B. The queue length of bottleneck links in both paths is 50 packets. The queue length of other links is set to 10000 packets. Default rbuf values in commonly used operating systems today vary from 16 KB to 64 KB and beyond.We study and analyze performance of the different policies with an rbuf of 64 KB. In the simulations, wireless link parameters are used as the references for network configurations. A computing node has a hybrid of GPRS and 3G connections. The path 1’s bandwidth is 384Kbps and the bandwidth of secondary path is 36 Kbps. The delay on the path 1 is 250 ms, and the delay of secondary path is 500 ms. The path 1 and path 2 experience 4% and 8% loss rate with Bernoulli Loss Model respectively. The original video sequence also used is known as Highway QCIF(176 144) which consists of 2000 frames. After preprocessing in simulation system, a MPEG-4 video trace file is produced. In NS2 simulation, node S begins to send data from this video trace file at a rate of 30 frames/second to node R.The simulation will stop after 30 random seeds are used for simulation.
Testing results are calculated by averaging the results of 30 runs and rounded up to the nearest integer.

E. Comparative Study of CMT and CMT-PR

This section studies the performance when CMT and CMT-PR (CMT-Partial Reliability) are employed for video delivery. that less aggressive failover settings is preferred for asymmetric path condition. In this simulation,the Path.Max.Retrans (PMR) is set 1. Table V shows the comparison results of average PSNR (dB) values, the number of different dropped frames (I-frame/P-frame/B-frame) and the number of lost packets, when CMT and CMT-PR policies are employed respectively. The dropped frames are those frames which can not be decoded after transmission. They may be the lost frames with network transfer or the discarded frames with the delay/jitter handling. Three reliability thresholds with 0, 1, and 2 are simulated for CMT-PR. As the table and Figs. 12 and 13 show, in most cases, CMT-PR performs better than CMT with five different retransmission policies, except the case of PR0 (the reliability threshold is 0). Such as the average PSNR of NPR-SSTHRESH is just only 27.12, but the average PSNRs of PR1-SSTHRESH and PR2-SSTHRESH can arrive at 35.7 and 32.48 respectively. The number of total dropped frames of NPR-SSTHRESH is 998, but there are only 5 and 445 dropped frames for PR1- SSTHRESH and PR2-SSTHRESH respectively.
The simulation of the performance of RTX-ASAP is less than RTX-SSTHRESH, RTX-LOSSRATE and RTX-CWND for file distribution. However, in our simulation,there are some interesting results, if partial reliability mechanism did not be implemented, only five retransmission policies are considered and compared, the average PSNR of RTX-ASAP can achieve 35.34, and the number of total dropped frames and lost packets are only 63 and 73 respectively, RTX-ASAP performs best. RTX-ASAP is a “hot-potato” policy, which retransmit data unit as soon as possible. This mechanism of RTX-ASAP is helpful for time sensitive video transmission.
The performance of PR0 is unstable, such as the performance of PR0-SSTHRESH (33.20) is better than NPR-SSTHRESH (27.12), but PR0-ASAP (33.20) performs worse than NPR-ASAP (35.34). In most cases, the performance of PR0 is worse than that of PR1 and PR2 with different retransmission policies. Additionally PR1 performs better than PR2. At the end, it can be clearly concluded that PR1-SSTHRESH is the best strategy of all of policies involving CMT and CMT-PR.

F. Comparative Study of CMT-PF and CMT-PF-PR

The authors considered and recommended RTX_SSTHRESH and RTX_CWND variants of CMT and CMT-PF, so in this section, we evaluate CMT-PF-PR (CMT-PF PartialReliability)withRTX_SSTHRESH and RTX_CWND retransmission policies respectively. We also investigate the impact of PF destination’s cwnd with setting to 1 or 2 MTU respectively when PF destination is alive. The other simulation parameters are set same with above experiment.Table VI illustrates the comparison results for average PSNR (dB) values as well as dropped frames (I-frame/P-frame/B-frame) and lost packets between CMT-PF and CMT-PF-PR. As the table and the Figs. 14 and 15 show, in all the cases, the performance of CMT-PF-PR is better than CMT-PF with both of RTX_SSTHRESH and RTX_CWND retransmission policies respectively (PF-PR0 is an exception). Such as the average PSNR of PF1- SSTHRESH is 22.13, the number of total dropped frames and lost packets arrive at video delivery with different retransmission policy. 1679, and 1871 respectively. however the average PSNRs of PF1-PR1-SSTHRESH and PF1-PR2-SSTHRESH are 35.47 and 33.62, and the number of total dropped frames are only 44, 276 respectively. The performance of PF-PR0 is unstable, such as the average PSNR of PF1-PR0-SSTHRESH and PF2-PR0-SSTHRESH are 33.06 and 32.78 respectively, and both of them are better than PF1-NPR-SSTHRESH and PF2-NPR-SSTHRESH. However, for PF1-PR0-CWND and PF2-PR0-CWND, the average PSNR of them are 33.06 and 32.80 respectively, which are worse than PF1- NPR-CWND (35.7) and PF2-NPR-CWND (35). But compared with PF-PR1 and PF-PR2, the performance of PF-PR0 is always worse. We also use the 30 results of above two simulations to calculate 90% confidence interval with an acceptable error of 10% of the mean respectively. It shows that on average the 90% confidence interval is about 0.01–0.02 dB, 1–2 frames, and 1–5 packets around the mean. For investigating the impact of PF destination’s cwnd with different size when PF destination is alive, there are interesting results, as the Table VI shows, PF1 performs better than PF2, which is different with the simulation results of [34] for file transfer. In CMT-PF, no data is sent on the PF path, after the timeout. CMT-PF sends a heartbeat on PF path and retransmits lost TPDUs along with new data on other active paths. PF path video delivery with different retransmission policy. is marked active when the heartbeat ack arrives at the sender.Therefore, for PF1, at the end of 1 Round Trip Time (RTT) after the timeout, (i) congestion window on PF path is 1 MTU and (ii) no new data has been sent on PF path. Thus, PF1 has a 1 RTT “lead” in its congestion window evolution. PF2 which initializes the congestion window to 2 MTUs after a heartbeat ack arrives. Though it avoids the 1 RTT lag in PF1’s congestion window evolution, for the asymmetric path condition, because one path is worse than another one, PF1 let the better conditions path has more chance for use, which achieves better real-time video transmission performance than PF2. PF-PR1 performs more stable than PF-PR2, and PF1-PR1- CWND performs best in all policies. Both of the simulation results of Sections IV-E and F show that for distributing real-time video over concurrent multipath, complete reliability, excessive reliability or no reliability will degrade the quality of video for transmission.
The policy with no reliability does not retransmit any data unit, which is an extreme strategy and not reasonable.
The simulation results show that PR1 and PF-PR1 performs more stable than PR2 and PF-PR2 respectively, it is because fast retransmission is used for the former. Since recovery via fast retransmission can happen only once for a given TSN, with other partial reliability thresholds, the number of consecutive timeouts would be high via the timeout retransmission, then the complete or excessive reliability of the retransmission of missing data could be the bottleneck for the guarantee of a desired frame rate. For real-time video, sometimes it is necessary to drop a few missing packets, instead of waiting for them to be retransmitted, because they are no longer needed for the stream.
The simulation results illustrate that PR1-SSTHRESH and PF1-PR1-CWND perform best with CMT-PR and CMT-PF-PR respectively. Using RTX-SSTHRESH ensures that most of the data is sent over the better path with CMT, and RTX_CWND appears to be a better policy than RTX_SSTHRESH during failure with CMT-PF.Combining the analysis of PF destination’s cwnd and our real simulation results, PR1-SSTHRESH and PF1-PR1-CWND are strongly suggested as the strategies to be used for multimedia distribution with parallel transfer.


It becomes increasingly common for a wireless device to be connected to more than one access networks employing either a homogeneous technology or heterogeneous forms of access such as GPRS, 3G, WiFi, WiMax, etc. The characteristics of mobile environments, with the possibility of frequent disconnections and fluctuating bandwidth, pose significant issues for mobile application developers and therefore the path redundancy offered by multi-homing protocols Stream Control Transmission Protocol (SCTP) has a clear attraction. Multi-homing technologies, where a host can be addressed by multiple IP addresses, achieves definite improvements when link/path failures occur or temporary loss is experienced.The growing availability of different wireless access technologies provides the opportunity for real-time distribution of multimedia content. In such services, multimedia data is displayed continuously at the receiver side,which requires the network transport to deliver the multimedia data in a timely fashion. Due to its real-time nature, video transport usually has stringent bandwidth, delay, and loss requirements. This paper investigated in details the performance of real-time multimedia transmission employing the transport layer multi-homing protocol SCTP when utilizing various flavors of Single Path Transfer and Concurrent Multipath Transfer, respectively.

Tables at a glance

Table icon Table icon Table icon
Table 1 Table 2 Table 3
Table icon Table icon Table icon
Table 4 Table 5 Table 6

Figures at a glance

Figure 1 Figure 2 Figure 3 Figure 4 Figure 5
Figure 1 Figure 2 Figure 3 Figure 4 Figure 5
Figure 6 Figure 7 Figure 8 Figure 9 Figure 10
Figure 6 Figure 7 Figure 8 Figure 9 Figure 10
Figure 11 Figure 12 Figure 13 Figure 14 Figure 15
Figure 11 Figure 12 Figure 13 Figure 14 Figure 15


  1. R. Stewart, “Stream control transmission protocol,” in IETF RFC 4960, Sep. 2007.

  2. D. P. Kim and S. J. Koh, “Performance enhancement of mSCTP for vertical handover across heterogeneous wireless networks,” Int. J.Commun. Syst., vol. 22, no. 12, pp. 1573–1591, Jun. 2009.

  3.  B. Ciubotaru and G.-M.Muntean, “SASHA-A quality-oriented handover algorithm for multimedia content delivery to mobile users,” IEEE Trans. Broadcast., vol. 55, no. 2, pp. 437–450, Jun. 2009.

  4. O. Issa, W. Li, and H. Liu, “Performance evaluation of TV over broadband wireless access networks,” IEEE Trans. Broadcast., vol. 56, no. 2, pp. 201–210, Jun. 2010.

  5. T. Maeda, M. Kozuka, and Y. Okabe, “Reliable streaming transmission Using PR-SCTP,” in 9th Annu. Int.Symp. Appl. and Internet, Washington, DC, USA, Jul. 2009.

  6. P. Natarajan, N. Ekiz, P. D. Amer, and R. Stewart, “Concurrent multipath transfer during path failure,” Comput. Commun., vol. 32, no. 15, pp. 1577–1587, Sep. 2009.

  7. C. Q. Xu, Y. S. Qiao, E. Fallon, and G.-M.Munteanet al., “Comparative study of real-time multimedia transmission over multihoming transport protocols,” in 11th IFIP/IEEE Int. Conf. Manage. Multimedia Mobile Netw. Serv.(MMNS), Samos Island, Greece, Sep. 2008.

  8. C. Q. Xu, E. Fallon, Y. S. Qiao, and G.-M.Munteanet al., “Performance evaluation of distributing real-time video over concurrent multipath,” in Proc. IEEE Wireless Commun. Netw. Conf. (WCNC), Budapest, Hungary, Apr. 2009.

  9.  “UC Berkeley, LBL, USC/ISI, and Xerox Parc ns-2 documentation and software,” ver. 2.29 [Online]. Available:, 2005

  10. Mean Opinion Score (MOS) Terminology”, ITU-T recommendation P.800.1, Jul. 2006.

  11. A. A. Webster et al., “An objective video quality assessment system based on human perception,” in SPIE Human Vision, Visual Process., Digital Display IV, San Jose, USA, Feb. 1993, vol. 1913, pp. 15–26.

  12. C. J. van den BrandenLambrecht and O. Verscheure, “Perceptual quality measure using a spatio-temporal model of the human visual system,” in Proc. SPIE, San Jose, CA, Feb. 1996, vol. 2668, pp. 450–461.

  13. C. H. Liew, C. Kodikara, and A. M. Kondoz, “A modelling of MPEG-4 encoded VBR video traffic,” IEE Electron.Lett., vol. 40, no. 5, pp. 355–357, 2004.

  14. C. Xu, J. Liu, and C. Zhao, “Performance analysis of transmitting H.263 over DCCP,” in Proc. IEEE Int. Workshop VLSI Design VideoTechnol., 2005.

  15. L. Xu and J. Helzer, “Media streaming via TFRC: An analytical study of the impact of TFRC on user-perceived media quality,” in Proc. IEEE Infocom, 2006.