Abstract
In a heterogeneous wireless environment, mobility particularly vertical handover between WiFi and cellular data service has to be supported. The support for multihoming feature makes Stream Control Transmission Protocol (SCTP) become a promising transport layer-based handover scheme for end users. Although the benefits of applying SCTP for multimedia delivery and handover have been proved to be extremely useful, there are still many challenges that remain: (i) current sender-centric SCTP handover management solutions fail to balance the computational overhead between a sender and receiver and (ii) they also suffer from performance degradation due to the rigid three-duplicated-SACK-based loss detection and recovery strategy. This paper proposes SCTP-Rev + , a new receiver-assisted cellular/WiFi handover management mechanism for SCTP-based multimedia transport aiming to (i) optimize SCTP handover management and achieve overhead balancing between the sender and receiver, by moving path estimation and handover decision operations from the sender onto receiver and (ii) improve SCTP loss recovery ability and multimedia delivery performance, by providing SCTP with a simple but effective retransmission-aware loss detection/recovery mechanism. We show that the proposed solution outperforms the current SCTP schemes in terms of goodput performance and multimedia delivery quality.
Introduction
Recently, significant advancements in wireless access systems, such as wireless local area networks (802.11 WiFi family) and cellular networks (UMTS, WiMAX, etc.), offer a mobile user ubiquitous Internet access [1] . In such an environment, mobility particularly vertical handover between the heterogeneous access networks has to be supported [2] . Meanwhile, promoted by the latest WiFi and cellular technological progress, wireless terminals (i.e., mobile PC, smartphones, etc.) are embedded with multinetwork interface and enabled simultaneous access to multiple heterogeneous networks [3, 4] . Such multihomed devices can improve their throughput performance and enhance user's quality of experience (QoE) by making use of multiple links either simultaneously or alternatively in a heterogeneous wireless network, supported by the Stream Control Transport Protocol (SCTP) [5] . Due to its multihoming and partial reliability features [6] , the SCTP has been considered as a good transport-layer technology suitable for continuously realtime multimedia delivery and seamless handover across a heterogeneous network environment (HetNetEnv). Figure 1 illustrates the usage of SCTP-based multimedia transport and handover in a HetNetEnv. As the figure shows, a SCTP-based media server (a sender) is communicated with several receivers (Rec 1, Rec 2, · · · , Rec n) by using two paths, which are path A that is a primary path and path B that is a secondary path. In such a scenario, the SCTP sender manages the two paths by making use of three major functions: (i) using path A and path B for multimedia content delivery and fault tolerance, respectively; (ii) using selective acknowledgment (SACK) and Heartbeat (HB) chunks to detect the connectivity of path A and path B, respectively [7] ; and (iii) handover which means using path B as a new primary path for multimedia transmission once the path A breaks (the maximum number of consecutive timeouts on path A is reached to the value of Path Max Retrans). Such features make SCTP become a preferred transport-layer protocol for content-rich multimedia transport and handover in a HetNetEnv [8, 9] .
Introduction
Although the benefits of using SCTP for multimedia transport and handover in a HetNetEnv have been proved to be useful, there are still many remaining issues and concerns on this topic. The first concern when employing SCTP for multimedia streaming is related to SCTP's TCPlike AIMD-based congestion control mechanism, which makes SCTP (i) cut the congestion window (cwnd) down to half for a single loss and (ii) enter slow-start phase when primary path switching occurs [10] . Such a "rigid" congestion control mechanism will cause bursty and frequent transmission rate fluctuations, and undoubtedly degrade users' quality of experience (QoE) for multimedia streaming services in a HetNetEnv, in which packet loss and handover tend to occur abruptly due to the characteristics of heterogeneous wireless systems [11] .
Introduction
The second concern when applying SCTP to multimedia delivery is the load-balancing problem between the sender and receiver. Current SCTP extensions [12] [13] [14] [15] [16] [17] [18] [19] and multimedia-related solutions [1, 4, [20] [21] [22] depend solely upon the sender to run flow/congestion control and handover management operations. However, taking Fig. 1 as an example, the sender may become a "processing bottleneck" in the system when very large amounts of receivers with multiple paths are communicated. In fact, running some operations (i.e., flow and congestion control) at receiver is a ideal solution to alleviate the workload of the sender [23, 24] . Moreover, such a receivercontrolled solution makes the receiver exploit the firsthand network information obtained in its forward path for flow control decision.
Introduction
The third concern of the SCTP-based multimedia wireless transmission is the "rigid" three-duplicated-SACKbased fast retransmission mechanism. In SCTP, a lost chunk cannot be retransmitted until its transmission sequence number (TSN) is reported as missing three times successively [25] . As a fully reliable and fully ordered transport protocol, the SCTP does not hand over the out-of-order (O 3 ) packets to upper application layer until a lost packet is received successfully, that is, a packet loss may result in numerous O 3 packets buffered in the space-limited receiver buffer and cause a severe hand over delay problem. Worse still for the time-sensitive multimedia streaming services, the delayed delivery of multimedia packets may lead to some of these received packets becoming unplayable.
Introduction
In order to address above concerns, this paper extends our previous work SCTP-Rev [26] to propose a receiverassisted cellular/WiFi handover management mechanism (dubbed as SCTP-Rev + ) for SCTP-based heterogeneous multimedia delivery. SCTP-Rev + moves some operations including path sending rate estimation and primary path selection from the sender onto receiver in order to achieve load-balancing between the sender and receiver. Moreover, SCTP-Rev + includes a simple retransmission-aware model that makes it possible to handle data loss and trigger proper fast retransmission. The major contributions of the paper are introduced as follows:
Introduction
• It moves the path sending rate control and primary path selection operations from the sender onto the receiver side in order to possibly help SCTP alleviate the workload of the sender.
Introduction
• It develops a receiver-triggered path fast recovery strategy in order to prevent bursty packet injection while maximizing resource utilization when a primary path switching event occurs.
Introduction
• It includes an efficient loss detection/recovery mechanism in order to make a SCTP sender possibly identify a packet loss event timely and improve the performance of multimedia transmission.
Introduction
The remainder of this paper is organized as follows. Section 2 introduces the detail design of the proposed SCTP-Rev + solution. Section 3 presents the performance evaluation and analysis of the SCTP-Rev + solution. Section 4 concludes the paper and gives some interesting directions for future work.
SCTP-Rev + detail design
In current SCTP handover solutions, the sender needs to monitor per-path's transmission quality and make a handover decision. In contrast, the SCTP-Rev + sender does not need to detect the transmission quality for each path, it just uses per-path's sending rate, which is calculated and advertised by the receiver, as the transmission quality metric to make a handover decision. Such way possibly helps the SCTP-Rev + to reduce the sender's computing overhead and achieve a desired load-sharing between the sender and receiver. Figure 2 shows the architecture of SCTP-Rev + system. SCTP-Rev + mainly consists of a receiver-based sending rate estimator (SRE-rev), a receiver-assisted path handover trigger (PST-rev), and a retransmission-aware fast retransmit (RAF-rtx) module. The major functions of the three components are described as follows:
SCTP-Rev + detail design
• SRE-rev is devoted to calculating per-path's sending rate at SCTP receiver side and giving the sender feedback on the paths' sending rate value.
SCTP-Rev + detail design
• PST-rev is devoted to choosing a proper primary path at SCTP receiver and giving the sender feedback on the selected primary path information for handover decision.
SCTP-Rev + detail design
• RAF-rtx is devoted to helping the SCTP sender possibly detect packet loss timely and trigger fast retransmission for loss recovery.
SCTP-Rev + detail design
Like TEAR [24] , a well-known receiver-driven TCPbased flow control solution, SCTP-Rev + runs seven states at receiver side for flow control, which are Slow Start, Congestion Avoidance, Slow Start Ready, Timeout, Congestion Avoidance Ready, and Fast Recovery. The state transition among the seven states has been detailed in the TEAR solution. Meanwhile, the SCTP-Rev + uses the round information, which is already defined in the TEAR solution, to measure the values of round-trip time (RTT) 
Definition 2 A round comes to end and a new round is starting once a new SACK is received by sender and the carried PSR values is used for each path's sending rate adjustment.
In SCTP-Rev + , each packet required to be sent will be labeled with a round ID (rID) by the sender in order to tell the receiver about the round info. Meanwhile, the SCTPRev + receiver will record a timestamp for each SACK chunk that is to be transmitted. Based on the SACK delivery time and rID information, the SCTP-Rev + receiver runs the RTT and RTO calculations following the steps below:
Definition 2 A round comes to end and a new round is starting once a new SACK is received by sender and the carried PSR values is used for each path's sending rate adjustment.
1) Once having a SACK S i to be sent, the receiver records the sending time of S i (denoted as t i ). 2) When the sender receives S i , it picks up the advertised PSR information for packet delivery, this means a new round round j begins. 3) When the first packet with the round j information, p 0 round j , arrives at the receiver side, the receiver records the receiving time of p 0 round j (denoted as t i+1 ).
4)
The receiver calculates the RTT value by using the following equation:
4)
where RTT cur is the current RTT value measured on each path and α is coefficient factor with a default value of 1 8 .
5)
The RTO calculation in the SCTP-Rev + solution is the same as that in the regular SCTP, which can be computed by
5)
where SRTT and RTTVAR can be initialized by (t i+1 − t i ) and
5)
2 , respectively.
Receiver-based sending rate estimator (SRE-rev)
As mentioned above, the standard SCTP utilizes a TCPlike AIMD-based sending rate and congestion control. Suppose there are ψ paths
Receiver-based sending rate estimator (SRE-rev)
within an SCTP association, when a packet is scheduled on path 
Receiver-based sending rate estimator (SRE-rev)
Due to the asymptotic behavior of AIMD algorithm, the standard SCTP in congestion avoidance phase will increase the sending rate of d δ by rate after each one RTT period (let packet size refers to the packet size, rate ≈ packet size RTT ). In other words, let us suppose that there are M packets required to be sent within one RTT, the sending rate of d δ will be increased by rate ( rate
Receiver-based sending rate estimator (SRE-rev)
RTT ) when each of the transmitted packets is received and acknowledged by the receiver, and it will be halved if a congestion condition is encountered.
Receiver-based sending rate estimator (SRE-rev)
Since the AIMD-style rate control mechanism is bound to the abrupt and frequent sending rate fluctuations, it cannot make SCTP enable smooth high-quality service for multimedia streaming applications in a varying wireless environment. As a remedy, we introduce a receiverbased sending rate estimator (SRE-rev) necessitating the following aims: (i) running a weighted moving average (WMA)-based AIMD rate control mechanism at receiver to determine the sending rate for each path and (ii) alleviating the sender's computational load and possibly reducing bursty rate fluctuations. With the WMA-based AIMD rate control mechanism, the sending rate calculation for
Receiver-based sending rate estimator (SRE-rev)
where N is the number of packet (the DATA chunks on primary path or the HB chunks on secondary path) received by receiver within one round. L size is the SCTP packet (DATA or HB) size. and are weighting factors with default values of 1 2 for fairness. PLR and thresh are the loss rate and predefined loss threshold, respectively.
Receiver-based sending rate estimator (SRE-rev)
Compared to the classic AIMD-based rate control mechanism, it is found that (i) in case of a network congestion, we have rate and rate is less than a given value. Therefore, SRE-rev can cut the sending rate down to a proper value for network congestion alleviation or speed the sending rate up to a maximum value for bandwidth utilization improvement. These features make SCTP-Rev + adaptively utilize the wireless resource.
Receiver-based sending rate estimator (SRE-rev)
Before giving the sender feedback on the estimated rate d i+1 value, the SCTP-Rev + receiver will smooth the estimated sending rate by using the following equation:
Receiver-based sending rate estimator (SRE-rev)
where g is a matrix used for storing per-path's κ most recent sending rate values, which can be expressed as below using Eq. (6):
Receiver-based sending rate estimator (SRE-rev)
Meanwhile, the coefficient vector ϒ can be defined as in Eq. (7),
Receiver-based sending rate estimator (SRE-rev)
where
Receiver-based sending rate estimator (SRE-rev)
is calculated as in Eq. (8),
Receiver-based sending rate estimator (SRE-rev)
In SCTP-Rev + , when the current sending rate the sender used is unexpected or a timeout event is detected, the receiver will immediately give the sender feedback on the estimated sending rate Rate d e , by using a modified SACK chunk (for a primary path) or a modified HB ACK chunk (for a secondary path), as shown in Fig. 3a Moreover, a delayed response timer of one RTT will be launched at the SCTP-Rev + receiver when a new round is starting. This way can help the receiver to capture a timeout event.
Receiver-assisted path handover trigger (PST-rev)
According to the proposed SCTP standard [5] , an SCTP sender need to detect the primary path error count (denoted as P 2 error count) and conduct primary path handover once the value of P 2 error count exceeds the maximum number of consecutive timeouts Path Max Retrans [28] . Such a sender-centric failoverbased handover mechanism will inevitably degrade the SCTP performance due to (i) failure detection on the primary path is a time-consuming process (more than 60 s [11] ) and (ii) frequent "ping-pong" primary path handover may increase the sender's load and overhead. Moreover, when SCTP switches to a new primary path, it may experience a slow-start phase on the new path because of a timeout event. This may cause a sending rate fluctuation and influence user-perceived quality of multimedia communications.
Receiver-assisted path handover trigger (PST-rev)
To resolve the aforesaid issues, this section introduces a receiver-assisted path handover trigger (PST-rev), which runs at the SCTP-Rev + receiver with the goals of optimizing SCTP handover performance and minimizing the handover overhead of sender. To this end, the PST-rev compares the sending rate of each path (period of 1 round) and select a path with the highest sending rate as the primary path for handover operations. Let Rate e , d cp , and d ap be the path sending rate calculated by SRE-rev, the current primary path, and a secondary path with the highest Rate e value within the secondary path list, respectively. 
Let
The usage of Rate new e can help SCTP-Rev + not only to avoid injecting traffic bursts into d ap but also to maximize the network utilization of d ap when SCTP-Rev + switches to d ap for multimedia content delivery. To tell the sender the selected primary path d ap , the SCTP-Rev + receiver will inform the sender of d ap 's path identifier (pid), by using a Primary Path Switching Notification (PPSN) chunk, as shown in Fig. 3c . The details of pid has been introduced in [30] . In order to trigger a fast primary path handover, the SCTP-Rev + receiver uses a reverse path with the lowest RTT for the PPSN feedback. When the PPSN chunk is received, the sender switches to the d ap and uses the Rate new e value as the sending rate for multimedia delivery.
Let
To summarize, the SCTP-Rev + runs the primary path selection and handover operations as follows: (i) the receiver uses the SRE-rev module to calculate each path's sending rate and then uses the sending rate as a metric to sort these paths in a descending order; (ii) the receiver uses the PST-rev module to compute a proper sending rate Rate new e for the first path (i.e., d ap ) within the sorted list; (iii) the receiver gives the sending feedback on d ap 's pid and Rate new e value, by using the PPSN chunk; and (iv) the sender switches to the path d ap and uses Rate new e as the sending rate for data delivery. The pseudo code of SCTP-Rev + -based path selection and handover is presented in Algorithm 1; we assume that the SCTP association includes two paths, d cp and d ap , where d cp is the primary path, and d ap is the secondary path.
Retransmission-aware fast retransmit module (RAF-rtx)
In a lossy wireless network environment, the performance of SCTP is largely dependent upon its loss recovery mechanism. Taking Fig. 4 for example, due to SCTP's fully reliable and fully ordered nature, even some packets (i.e., TSN 1-2 and TSN 5-6) are received by the receiver, they cannot be handed over to the upper layer at once until the miss-
Algorithm 1 SCTP-Rev + -based path selection and handover operations
At the receiver side: 1: calculating per-path sending rate by using Eqs. (4), (5), (6), (7) and (8) ing packets (i.e., TSN 3-4) are retransmitted and received. However, like it was previously mentioned, the standard SCTP does not mark a loss chunk for fast retransmission until its TSN is reported missing three times successively. Such a rigid three-duplicated-SACK-based packet loss detection/recovery mechanism will degrade user perception quality of real-time multimedia streaming services.
Algorithm 1 SCTP-Rev + -based path selection and handover operations
It would achieve desired performance if a lost packet can be detected timely and further be retransmitted rapidly by a sender [31] . Actually, the retransmission queue length is mostly used as an important parameter for loss detection and managing retransmissions [32, 33] . Motivated by these facts, this section concentrates on improving the performance of SCTP-based multimedia streaming by constructing a simple, yet effective loss detection and recovery model which is dubbed as RAF-rtx. RAF-rtx aims to make SCTP-Rev + possible to identify the lost packets timely and enable loss recovery rapidly in a lossy wireless environment, by detecting the jitter indicator of the retransmission queue length.
Algorithm 1 SCTP-Rev + -based path selection and handover operations
Let d cp be the primary path, and let cwnd d cp and Q(0 ≤ Q ≤ cwnd d cp ) refer to the cwnd size and the retransmission count of path d cp , respectively. We estimate the jitter indicator of Q, Q , by using the following equation:
Algorithm 1 SCTP-Rev + -based path selection and handover operations
where Q curr is the current retransmission count in the transmission queue, Q is the average retransmission 
Algorithm 1 SCTP-Rev + -based path selection and handover operations
Thus, we can simply use Q to probe whether or not the path d cp to be with unreliable transmission condition (high loss). We determine d cp to be with unreliable transmission condition if Q > 0 and the value of Q is increasing continuously, namely,
Algorithm 1 SCTP-Rev + -based path selection and handover operations
which t n and t n−1 (t n > t n−1 ) are the observed time.
Algorithm 1 SCTP-Rev + -based path selection and handover operations
By cognizing the transmission condition of d cp , once a SACK arrived at the sender, RAF-rtx attempts to trigger faster retransmissions for a missing data chunk following the rules below:
Algorithm 1 SCTP-Rev + -based path selection and handover operations
(1) If Q > 0 and (Q ) t n − (Q ) t n−1 > 0, a DATA chunk with two consecutive miss indications (CMIs) will be marked for fast retransmission. (2) Otherwise, RAF-rtx refers to the regular SCTP operations where a DATA chunk with three CMIs will be marked for retransmission.
Algorithm 1 SCTP-Rev + -based path selection and handover operations
(3) RAF-rtx does not mark the DATA chunk(s) with one miss indication for fast retransmission in order to avoid spurious retransmission.
Simulations and analysis

Simulation topology
The performance evaluation have been carried out using In order to simulate the wireless loss at data-link layer, we attach two loss models for each wireless access link, which are the uniform loss model that represents distributed loss caused by wireless interference and the twostate Markov loss model 1 that represents continuous loss caused by bursty traffic or signal fading. Moreover, we attach each path with a variable bit rate (VBR) generator in order to schedule VBR-based competing traffic over the two paths. Like [18] , the packet sizes used for VBR traffic are selected as follows: 50 % are 44-byte, 25 % are 576-byte, and the rest 25 % have 1500-byte length, in which 20 % of these traffics are over UDP protocol and the other 80 % are carried by TCP protocol. Each path's VBR competing Fig. 6 shows the sending and receiving TSN (sr-TSN) when using SCTP, SCTP-Rev, and SCTP-Rev + , respectively. It can be observed that SCTPRev + attains the highest number of sr-TSN, while SCTP attains the lowest number of sr-TSN. This is because the standard SCTP employs a simple failover-based primary path handover mechanism; in this way, it always utilizes the default primary path for data transport even if the transmission quality of the primary path is unsatisfactory. SCTP-Rev and SCTP-Rev + achieve higher sr-TSN than SCTP because of their receiver-based sending rate estimator and receiver-assisted path handover trigger. However, benefiting from its retransmission-aware fast retransmit module, SCTP-Rev + can detect the lossy condition and trigger a fast retransmission for a lost packet. Correspondingly, SCTP-Rev + maintains the transmission efficiency at a higher level than the SCTP-Rev scheme.
Results analysis

1) Sending and receiving TSN:

2) Out-of-order TSN:
The out-of-order TSN (o 3 -TSN), which is computed by the difference between the TSNs of two chunks received consecutively by the receiver, is a good metric used to reflect the performance and characteristics of heterogeneous multipath transport scheme. Figure 7 illustrates the o 3 -TSN variations under the whole simulation time of 120 s. As shown in the figure, SCTP-Rev + generates less o 3 -TSN and requires decreased reordering overhead than the SCTP and SCTP-Rev schemes. This is because that SCTPRev + uses the receiver-based sending rate estimator and receiver-assisted path handover trigger to monitor perpath sending rate and adaptively select an optimal primary path for data delivery. Apart from the receiver-based sending rate estimator and receiver-assisted path handover trigger modules, SCTP-Rev + also benefits from the retransmission-aware fast retransmit module which triggers a fast retransmission for loss recovery. The peak o 3 -TSN reception at the receiver is approximately 24, 17, and 14 when sending the data with SCTP, SCTP-Rev, and SCTP-Rev + , respectively.
3) Jitter Comparison:
Jitter is a variation in packet transit delay caused by path handover, queuing, and other networking-related effects on transmission efficiency. Higher levels of jitter are more likely to occur on unsatisfactory transport solution. Therefore, jitter is an important metric to reflect the performance of multipath transport protocols. Figure 8 presents the jitter comparison results when using SCTP, SCTP-Rev, and SCTP-Rev + , respectively. The simulation results only between simulation time t = 10 s and t = 20 s are illustrated in the figure in order to better show the comparison. As the figure shows, all the three schemes experience delay jitter during data transmission. However, SCTP-Rev presents a lower packet transit delay variation than other two schemes, since it can detect a packet loss event timely and trigger a proper fast retransmission strategy for loss recovery. Moreover, SCTP-Rev is capable of acquiring and exploiting first-hand network parameters at receiver for primary path selection and handover operations. Thanks Figure 10b presents the cumulative average throughput of the three schemes with a total 120 s simulation time. As the figures show, SCTP-Rev + achieves a higher throughput performance than the SCTP and SCTP-Rev solutions in all the different rbuf sizes studied. That is because SCTP-Rev + selects and switches to an optimal primary path, it also provides an adaptive fast recovery to handle packet loss. These factors help SCTP-Rev + to increase the throughput performance in a varying HetNetEnv. After a total 120-s simulation time with a 64-KB rbuf, SCTP-Rev + 's throughput is 32.38 and 5.8 % higher than that of SCTP and SCTP-Rev, respectively. With a 32-KB rbuf is used, SCTP-Rev + performs 37.13 and 10.27 % better than SCTP and SCTP-Rev, respectively. When the rbuf size is set to 128 KB, SCTPRev + performs 38.74 and 5.63 % better than SCTP and SCTP-Rev, respectively. As discussed previously, SCTP-Rev + utilizes a WMAbased AIMD rate control mechanism to run flow control for each path and preserve fairness towards TCP-like network flows, by cutting the sending rate down to half on the congested paths. In order to convince TCP friendliness of SCTP-Rev + , we examine the cumulative average TCP throughput performance when the default rbuf sizes of 64 KB is used, when SCTP, SCTP-Rev, and SCTP-Rev + are used, respectively. After a total 120 s of simulation time, we find that the cumulative average throughput of SCTPRev + 's competing TCP traffic is only 0.17 % lower than that of SCTP-Rev's competing TCP traffic and approximately 0.83 % lower than that of SCTP's competing TCP traffic. We argue that this TCP-aggressive behavior of SCTP-Rev + is acceptable and unharmful. Therefore, we can conclude that SCTP-Rev + , also SCTP-Rev, can ensure TCP friendliness almost the same as SCTP does.
5) Multimedia delivery comparison:
In order to better study the performance of SCTP-Rev + -based multimedia delivery, a well-known YUV video sequence (QCIF format, 176 × 144 pixels), which is composed of total 2000 frames with average streaming quality is used for the experimental video trace. Table 2 presents the encoding information on the first nine frames of the video trace file used in the simulation. The frame rate of the video stream is encoded at 30 frames per second (fps). After processing, an MPEG-4 video sequence which consists of total 223 I frames, 445 P frames, and 1332 B frames is generated. These frames are included into 2250 packets (463 packets for I frame, 453 packets for P frame, and 1334 packets for B-rame) and are introduced to the NS2 by using an MPEG-4 video trace file. The simulation will stop when all the multimedia data are transmitted. Figure 11 illustrates the comparison of multimedia delivery, expressed in terms of PSNR (dB) and received frame number, when SCTP, SCTP-Rev, and SCTP-Rev + are used, respectively. Thanks to its highly efficient primary path selection/handover and loss-aware fast retransmission approaches, SCTP-Rev + selects a path with a higher transmission efficiency as the primary path and schedules multimedia packets over the selected primary path; moreover, it can possibly avoid throughput performance degradation caused by fast retransmission/recovery using the current SCTP solutions. As a result, SCTP-Rev + achieves a better multimedia delivery performance in comparison with SCTP and SCTP-Rev. The average PSNR difference between SCTP-Rev + and SCTP is approximately 2.9 dB, and it is around 0.20 dB between SCTP-Rev + and SCTP-Rev. The total received frame number of SCTP-Rev + is 1832 (206I + 428P + 1220B), 1352 (165I + 305P + 880B) when using SCTP and 1756 (194I+388P+1172B) when using SCTP-Rev.
Conclusions
Motivated by the fact that a receiver may be adjacent to the wireless last hop and it is thus more a b Fig. 11 Comparison of multimedia delivery a PSNR (dB) and b received frame number aware of the wireless network parameters than its corresponding sender, this paper proposes SCTP-Rev + , a new receiver-assisted cellular/WiFi handover management mechanism for SCTP-based multimedia transport. SCTP-Rev + mainly consists of a receiver-based sending rate estimator (SRE-rev), a receiver-assisted path handover trigger (PST-rev), and a retransmission-aware fast retransmit (RAF-rtx) module, in which (i) SRE-rev is devoted to calculating the sending rate for each path at receiver side and giving the sender feedback on per-path sending rate; (ii) PST-rev runs primary path selection at receiver side and returns the selected primary path information to the sender for handover operations; and (iii) RAF-rtx is devoted to possibly detecting and handling packet loss timely.
Conclusions
Although simulation results reveal that applying SCTPRev + for multimedia delivery and handover is very useful, the energy consumption problem when applying SCTP-Rev + to the power-limited mobile devices is an interesting topic worth further investigation. We notice that recent research efforts [35] have been devoted to handling the energy consumption problem of multipath transport protocols by applying the promising cross-layer technology at the sender. Our future work will extend the SCTP-Rev + solution by running the cross-layer activities at receiver towards better reducing the energy consumption of SCTP-Rev + , and an open-source (Linux/Unix) virtual machine [36] -based performance analysis will be also included in our future work. 1 In the two-state Markov loss model, the packet loss process during data delivery is represented as a discretetime random process with two-state Markov chain property. The interested reader, looking for the detail usage of Markov loss model used in a SCTP context, should refer to the reference [12] for more information.
Endnotes


{'paper_id': '26433410', 'title': 'Receiver-assisted cellular/wifi handover management for efficient multipath multimedia delivery in heterogeneous wireless networks', 's2_url': 'https://api.semanticscholar.org/CorpusID:26433410', 'source': 'S2ORC'}