Yuanlong Cao, Shengyang Chen*, Qinghua Liu, Yi Zuo, Hao Wang, Minghe Huang
1 School of Software, Jiangxi Normal University, Nanchang 330022, China
2 Performance Engineering Laboratory, Dublin City University, Ireland
3 Jiangxi innovation funds management center for small and medium-sized enterprises, Nanchang 330046, China
* The corresponding author, email: shengyang.chen5@mail.dcu.ie
Wireless communication technologies are currently undergoing extremely fast-paced developments and continual upgrades. The widespread availability of various wireless access technologies (e.g., WiFi and 4G/LTE networks) provides mobile users with ubiquitous and broadband mobile internet access support[1-2]. Promoted by the latest technological achievements and the increasing popularity of content-rich media communication-based services, more and more mobile phones are equipped with multiple network interfaces[3-4] (e.g., the Samsung Galaxy S5 mobile phones can establish communication associations with both Wi-Fi and LTE networks simultaneously by using the Download Booster[5]). Such multi-homed mobile phones have multiple heterogeneous access capability and can increase their goodput performance by making using of concurrent transmissions over multiple paths, enabled by the Multipath TCP(MPTCP) [6].
MPTCP is a new transport-layer protocol that enables systems to exploit multiple network interfaces to concurrently spread the traffic over multiple end-to-end available paths[7]. It provides a multi-homed host with many and attractive benefits including throughput performance improvement, latency reduction,and fault tolerance, while still maintaining compatibility with existing TCP-based applications[8-10]. Fig. 1 illustrates a basic MPTCP usage in a heterogeneous wireless network environment. It shows how the MPTCP-based mobile phones simultaneously use two paths (WiFi and LTE) to download data from the media server.Through this way, MPTCP can achieve both higher transmission efficiency and better robustness of system, compared to the single-path TCP. Therefore, MPTCP has been regarded as a preferred transport layer protocol to enhance data transport for mobile phones in heterogeneous wireless networks [11-12].
Fig.1 MPTCP-based video delivery in a heterogeneous wireless network
Although the advantages of applying MPTCP to a mobile phone for data transmission have been demonstrated to be useful,there is still significant amount of ongoing work addressing many remaining concerns and challenges. One major concern when running MPTCP on mobile phones is related to the energy consumption problem. By maintaining multiple active interfaces for parallel transmission, MPTCP provides mobile phones with better throughput performance but at the expense of higher energy consumption [13].The battery storage is evolving at a slow pace:Nowadays, mobile phones have limited power capacity and are frequently constrained by the amount of energy resources available in their batteries. Therefore, the energy consumption becomes a major concern when utilizing MPTCP on the power-constrained mobile phones.
Recently, many efforts have been devoted to optimizing MPTCP energy usage [14-18]. To summarize, current energy-efficient MPTCP solutions mostly trade throughput performance for longer battery lifetime and energy-saving through the following strategies:1) capture the energy behavior of MPTCP on mobile devices; 2) choose an appropriate combination of interfaces (e.g., WiFi and LTE interfaces) and enable an energy-aware sub flow usage management mechanism; and 3) shift application traffic to the lowest energy cost path and mute the other paths. However, they seldom consider the impacts of application read-rate of mobile phones in their energy-efficient design. In fact, the application read-rate is one of the dominant factors and becomes a serious concern in energy-aware path/sub flow usage management when using the receive buffer-constraint mobile phones for data application access, as we discuss later.
Another limitation of the existing work on MPTCP energy usage is that they do not consider the energy-overhead caused by the SACK (selective acknowledgment) traffic.This limitation may result in much more SACKs transmitted from a receiver to the sender along a reverse path with high energy-cost. In addition, to the best of our knowledge, most existing MPTCP solutions [19-27]seldom consider the impact of SACK loss on the MPTCP performance optimization. In a wireless network environment, when a wireless error occurs that causes only SACKs to be lost, the lost SACK forces the MPTCP sender to maintain copies of SACKed data in the send buffer, which result in inevitable send buffer wastage. Worse for the send buffer-constraint devices, large numbers of data buffered in the overloaded send buffer will undoubtedly cause the application-level performance degradation seriously.
In this paper, we extend our previous eMTCP solution [17] and propose MPTCPQE, a novel quality of experience (QoE)-driven energy-aware multipath content delivery approach for MPTCP-based mobile phones,by jointly considering the application readrate and SACK loss detection/recovery at the receiver (mobile phones). The goal of our MPTCP-QE solution is to improve on standard MPTCP, also exiting energy-aware MPTCP solutions, by being more energy efficient while preserving the compatibility and robustness benefits of MPTCP. The proposed MPTCPQE was fully tested and results showed how it outperforms existing MPTCP solutions in terms of energy-saving and quality of service.More specifically, the proposed MPTCP-QE has the following advantages:
● It tracks the application behavior at the receiver (mobile phones) and enables an application rate-ware energy-efficient sub flow usage management strategy to intelligently tradeoff throughput performance and energy consumption for MPTCP-based mobile phones.
● It includes an available bandwidth-aware congestion window (cwnd) fast recovery strategy to make a sender avoid unnecessary slow-start and utilize wireless resource quickly.
● It introduces a highly efficient SACK mechanism to help a receiver possible detect SACK loss in a timely fashion and trigger SACK loss recovery in a more energy-ef ficient way.
The rest of the paper is organized as follows. Section II gives a brief overview of MPTCP-QE system. Section III describes the details of the MPTCP-QE system. Section IV evaluates and analyzes the performance of the MPTCP-QE. Section V concludes the paper and gives our future work.
Nowadays, the mobile phones are already equipped with WiFi and LTE network interfaces simultaneously. For example, the Samsung Galaxy S5 mobile phones, previously mentioned, now feature Download Booster to boost data speed by bonding WiFi and LTE networks simultaneously [5]. Meanwhile,Apple’s iOS7 uses MPTCP on an iPhone to establish two connections: a primary TCP connection over WiFi and a backup connection over cellular network [28]. In this paper, we consider a MPTCP-based mobile phone (acted as a receiver) that need to download bulk data, e.g., video streaming and file data, from a server (acted as a sender). We focus on data delivery over the WiFi and LTE interfaces since they are more common in the real-world environment.
Early work [15] has already shown that: 1)WiFi has a comparatively short promotion and tail state, resulting in smaller energy overheads than LTE; 2) using LTE-only to download a video consumes much more power than using both WiFi and LTE simultaneously; and 3)using both WiFi and LTE interfaces achieves better throughput performance but at higher energy cost. Inspired by these facts, MPTCPQE selects an appropriate combination of interfaces accordingly to enable an optimal transmission mode in order to save energy of mobile phones while maintaining the quality-of-service (QoS). MPTCP-QE includes two transmission modes,
● Full MPTCP mode: It refers to the regular MPTCP operations where both WiFi and LTE sub flows are selected for packet delivery.
● Partial MPTCP mode: It refers to the operations where only WiFi sub flow is selected for packet delivery.
For the sake of energy-saving and performance improvement, similar to the other energy-saving MPTCP solutions [14-18], MPTCPQE runs sub flow usage management at receiver (a mobile phone) to monitor the transmission efficiency of each interface and determine an appropriate combination of interfaces.Fig. 2 illustrates the architecture of MPTCPQE system. MPTCP-QE consists of three major blocks, which are application rate-aware energy-efficient subflow usage management module (aeSUM), available bandwidth-aware cwnd fast recovery module (abCWND), and wireless-aware energy-efficient Selective ACK module (weSACK):
● aeSUM aims to track the application readrate at the receiver (mobile phones). It decides to use Partial MPTCP mode or Full MPTCP mode for packet delivery and informs the sender about the decision.
● abCWND serves to provide MPTCP-QE with a proper available bandwidth-aware cwnd fast recovery strategy to avoid unnecessary slow-start when an idle subflow is reactivated for packet delivery.
● weSACK aims to help the receiver possible to detect SACK loss in a timely fashion, by using the Management Information Base(MIB) of the MAC layer. It is also responsible for choosing a reverse path with low energy-cost for SACK delivery.
We design MPTCP-QE with an energy-efficient subflow usage management mechanism for MPTCP-based mobile phones relying not just on the energy usage of MPTCP sub flows but also on the application read-rate at the mobile phones. We here track and analyze the receiver buffer behaviors to explain the reason as follows. First, letandrefer to the initial free-space, remaining space, and the occupancy space of the receiver buffer, respectively. Then we have
Previous work [29-30] proved that the receiver buffer occupancy has no other in fluencers other than the input rate (sending rate)and the drain rate (application rate). Letbe the sending rate of WiFi or LTE subflow,and let AR refer to the application read-rate at receiver, we have
By substituting (2) into (1), we have
Fig.2 MPTCP-QE architecture
For Eq. (3), since today’s mobile phones generally have very limited memory capacity and little free space for the receiver buffer, we thus can believe thatis a constant with a small value. Therefore,may lead towhich result in a receive buffer blocking problem [31-32].
Following the above analysis, MPTCPQE uses the Partial MPTCP mode (using WiFi-only) as the transmission model to download the data if the sending rate of WiFi subflow (denotedis larger than AR.Such transmission mode can possibly help MPTCP-QE avoid the receive buffer blocking problem while reducing the energy overhead since the LTE sub flow with higher energy cost is disabled for data delivery. If the sending rate of WiFi sub flow is less thanMPTCPQE switches from using Partial MPTCP mode to Full MPTCP mode to intelligently tradeoff throughput performance and energy consumption for mobile phones.
To estimate current sending rate of WiFi sub flow, MPTCP-QE receiver samples downloaded bytes through WiFi subflow everyms. Given the sampled sending rates,MPTCP-QE, like [15], uses the Holt-Winters time-series forecasting method [33], which is known as a more accurate predictor than the formula-based predictors using a function of underlying network characteristics, to predict sending rate changes of WiFi subflow. The sampled sending rates of WiFi sub flow used in the Holt-Winters time-series forecasting algorithm can be expressed by
The aeSUM feeds the sampled sending rates into the Holt-Winters time-series forecasting algorithm to accurately predict sending rate changes of WiFi sub flow, and then decides to switch from using Partial MPTCP mode to Full MPTCP mode or vice versa, based on the comparison of theandvalues.Whenis detected, the aeSUM switches from using Partial MPTCP mode to Full MPTCP mode in order to tradeoff throughput performance and energy consumption for mobile phones.
When switching to Full MPTCP mode, ae-SUM runs the eMTCP algorithm [17], which is an energy-aware MPTCP-based data traffic of fload algorithm in order to move traffic from higher energy cost subflow (LTE subflow)to the lower one (WiFi subflow) to achieve energy-savings. In order to make the paper self-contained, we hereby introduce the data traffic offload process works in the eMTCP algorithm:
2) If the WiFi subflow undergoes congestion (the current cwnd size of the WiFi sub flow is zero), the receiver checks whether or not the LTE sub-flow is in congestion. If yes, the receiver gives up receiving the current data. Otherwise, the receiver of floads the queued data from the TCP receive buffer to the LTE sub flow.
3) In step 2), if the cwnd size of the WiFi sub flow is greater than zero, the receiver offloads the amountof queued data in the TCP receive buffer from the LTE subflow to the WiFi sub flow.is calculated by
When MPTCP-QE receiver decides to switch from using Partial MPTCP mode to Full MPTCP mode or vice versa, this decision needs to be advertised to the sender. To inform the sender of the transmission model change,similar to [15], we add an MP_PRIO option[34], which changes the priority of the LTE sub flow, to the next packet to be transmitted.The pseudo code of application rate-aware energy-efficient subflow usage management algorithm is presented in Algorithm 1.
?
Current energy-aware MPTCP solutions increase the energy efficiency of mobile devices by offloading traffic from the more energy-consuming subflows (e.g., LTE) to others(e.g., WiFi). Such solutions may make LTE sub flow undergo an idle period longer than the retransmission timeout [35]. In this case, once the sender needs to reactivate the LTE for data delivery, it enters into the slow-start phase,which means the cwnd of LTE subflow will be reset to the initial value at the beginning of a data delivery. This behavior minimizes the LTE resource utilization and degrades the throughput performance.
Providing a proper cwnd value for LTE subflow in advance before the sender starts re-using the LTE sub flow has been recognized as a good solution to minimize the slow recovery issue [36]. However, how to estimate an appropriate cwnd value for LTE sub flow is a challenge because an inappropriate cwnd size may cause one energy usage increase or other throughput performance reduction problem.For example, letandrefer to the initial cwnd value of LTE sub flow, the estimated cwnd size of LTE sub flow, and the current cwnd size of WiFi sub flow, respectively.
By considering the above cases, MPTCPQE provides a proper available bandwidth-aware cwnd fast recovery strategy to make the sender utilize the LTE subflow quickly and efficiently. When the sender needs to switch from using Partial MPTCP mode to using Full MPTCP mode, it calculates and sets a proper cwnd size for LTE subflow after an idle period longer than the retransmission timeout in order to ensure that the LTE subflow avoids unnecessary slow-start. To this end, thecan be obtained by
As discussed earlier, in case of, the LTE subflow will carry larger amount of data than WiFi subflow, which resulting in more energy consumption. Therefore, the MPTCP-QE sender adjusts the value ofin advance before it starts re-using the LTE subflow, which using below equation,
In current energy-aware MPTCP solutions, an SACK chunk will be delivered from a receiver to the sender along any available reverse paths without considering the energy consumption caused by the SACK traffic. To fill the gap,we introduce a wireless-aware energy-efficient SACK approach (weSACK) which improves on MPTCP by being more energy efficient.weSACK includes an energy-efficient SACK return path selection mechanism, in which a MPTCP receiver transmits SACK chunks, as many as possible, to the sender over a reverse path with the lowest energy-cost among the available reverse paths. In addition, weSACK provides a wireless-aware SACK loss recovery mechanism in order to make MPTCP possible to identify the lost SACK timely and enable SACK loss recovery rapidly at receiver.
For the SACK return path selection, supposing two available paths (WiFi and LTE)within the MPTCP session, and letrefer to the sum of the end-to-end energy cost of the successful transmission of one SACK packet on paththe weSACK chooses the paththat minimizes the following objective function as the return path to carry SACK packets,
Using the Eq. (10), MPTCP-QE will select the WiFi as the primary reverse path to send back SACK packets to the sender since WiFi has a comparatively short promotion and tail state,which resulting in smaller energy overheads than LTE [15-17]. Once the WiFi path breaks, the MPTCP-QE receiver uses the LTE path as the SACK return path. In this way, the energy consumption of mobile phones may be reduced.
Moreover, using WiFi as much as possible to send back SACK packets to the sender provides a potential opportunity to make MPTCPQE receiver identify SACK loss timely. By monitoring the value of dot11FailedCount, a counter defined in the Management Information Base (MIB) of the IEEE 802.11 MAC layer, which has been already used in [38] to help a TCP sender to detect packet loss caused by wireless errors. However, different from[38], our weSACK is thefirst work to run the dot11FailedCount detection at a receiver in order to track the number of wireless errors in transmitting SACK over wireless WiFi link.To this end, the MPTCP-QE receiver sets up reporting constraintsfirst, then the MAC conditionally reports the values of dot11Failed-Count through the WiFi WlanQueryInterface()function, which is already implemented in today’s Windows operating systems.
By detecting the variation of dot11Failed-Count, the MPTCP-QE receiver can efficiently recognize the wireless WiFi link error and track the number of frame transmission that are abandoned because the number of transmission attempts has exceeded a specified value. Letrefer to the number of frame transmission that are abandoned when the MPTCP receiver sends SACK chunks to the sender over pathAnd let the jitter indicator of
Fig.3 Simulation topology
The performance evaluation has been carried out on the Network Simulator 3 version 15(NS-3) [39] with the SACK option. The simulations considered a MPTCP-based heterogeneous wireless network environment shown in Fig. 3. Two MPTCP endpoints, MPTCP-based application server and MPTCP-based smartphone (referred to as UE0 and UE10, respectively) have two asymmetric paths (denoted Path 1 and Path 2). Path 1’s bandwidth is set to 2Mbps and 5-15 ms propagation delay, which corresponds to a WiFi/IEEE 802.11 link [40].Path 2 experiences 100Mbps bandwidth with 100 ms propagation delay which is representative for a 4G/LTE link.
The distance between UE10 and the base station of WiFi and LTE is set to 60 meters,respectively. The initial energy of the battery of UE10 is set to 300 Joules. To simulate the errors encountered in wireless channels, we use the Log-normal Shadowing Model [41],which has been widely adopted to include multipath propagation effects and signal attenuations in the wireless physical channel. Thus,wireless losses, which are caused by radio signal fading in a MPTCP receiver, can be easily implemented in NS-3.
Like the eMTCP solution [17], we inject Internet background traffic generated by adding nine single-interface mobile phones (denoted as UE1, UE2, ···, UE9, respectively), in which UE1, UE2, UE3, and UE4 are located in the WiFi network, UE5, UE6, UE7, and UE8 are located in the LTE network, and UE9 is located in the overlapping coverage of WiFi and LTE networks. The nine mobile phones are communicated with UE0 by using TCP as transport layer protocol for data delivery. The UE0 is attached with a CBR (constant bit-rate)generator with 1040-byte packet size in order to model and generate the video traffic. The application read rate of receiver fluctuates in a pattern of <1, 3>, which means the receiving application reads at 1 Mbps for one RTT, then at the rate of 3 Mbps for another RTT and back to 1 Mbps. The other simulation parameters use the values mentioned in [17]. The total simulation time is 120 seconds.
In this subsection, we present the performance evaluation and comparison among the regular MPTCP [6], energy-aware MPTCP (eMTCP)[17], GMCC-Coop MPTCP [27], and our MPTCP-QE solutions. To make it convenient,we illustrate the results of the regular MPTCP as ‘MPTCP’ in the test result figures, and the results with eMTCP, GMCC-Coop MPTCP,and MPTCP-QE are illustrated as ‘eMTCP’,‘GMCC-Coop’, and ‘MPTCP-QE’, respectively.
1) Energy consumption comparison: Fig.4 presents the energy consumption rate when MPTCP, GMCC-Coop, eMTCP and MPTCPQE are used, respectively. We can observe that MPTCP and GMCC-Coop attain a higher energy consumption rate than eMTCP and MPTCP-QE. This is because both MPTCP and GMCC-Coop use an energy-blind scheduler to distribute the packets over all subflow. Such energy-blind scheduler is bound to high energy consumption because asymmetric paths with different energy-cost are more common, and there is a high probability that a packet is sent over a high energy-cost path. However, since GMCC-Coop is devoted to remaining fair to the competing TCP flows, by constraining the sender from transmitting a certain amount of packets, it correspondingly attains a lower energy consumption rate than MPTCP.
In contrast, eMTCP and MPTCP-QE use an energy-aware scheduler to move traffic from higher energy cost path to the lower one.Thereby, they achieve lower energy consumption rate than the MPTCP and CMCC-Coop solutions. Meanwhile, MPTCP-QE provides an application rate-aware energy-efficient subflow usage management strategy and a wireless-aware energy-efficient Selective ACK mechanism, in which the WiFi interface is possible utilized instead of the LTE interface for data and SACK delivery. Thereby, MPTCP-QE maintains the energy consumption rate at the lowest level. For instance, after 120s of simulation time, MPTCP-QE’s energy consumption rate is 19.05%, 17.48%, and 5.71% lower than that of MPTCP, GMCC-Coop, and eMTCP,respectively.
Fig. 5 shows comparison of energy efficiency among MPTCP, GMCC-Coop, eMTCP,and MPTCP-QE. The energy efficiency metric used in the simulations is calculated by the ratio between throughput and energy consumption. The energy efficiency metric portrays the energy usage characteristics of multipath data transmission in a heterogeneous wireless network environment. As the figure shows,MPTCP-QE maintains the energy efficiency at a higher level than the MPTCP, GMCCCoop and eMTCP solutions. The corresponding comparison of a long-term (after 120s of simulation time) cumulative average energy efficiency is 20.83%, 19.33%, and 5.49% in favor of the proposed MPTCP-QE solution,respectively.
Since a battery-powered energy-limited mobile phone will fail to work when they run out of battery power, we here use the residual battery lifespan as a metric to demonstrate the energy usage of the four solutions. Fig. 6 shows the residual battery lifespan when MPTCP, GMCC-Coop,eMTCP, and MPTCP-QE are used, respectively.It clearly demonstrates that the four multipath transport solutions adversely affect battery life of mobile phones. It can also be observed that the residual battery lifespan decreases with the increase in the simulation time for all the four solutions. However, the residual battery lifespans of MPTCP, GMCC-Coop and eMTCP decrease more significantly than that of MPTCP-QE. For instance after 120s of simulation time, MPTCPQE achieves 27.02%, 24.21%, and 6.83% better than the MPTCP, GMCC-Coop and eMTCP solutions, respectively.
Fig.4 Comparison of energy consumption rate
Fig.5 Comparison of energy efficiency
Fig.6 The remaining battery lifespan comparison
Fig.7 Comparison of throughput performance
Fig.8 Comparison of peak signal-to-noise ratio
Fig.9 PSNR standard deviation comparison
2) Average throughput comparison: Fig. 7 shows the throughput performance comparison when MPTCP, GMCC-Coop, eMTCP, and MPTCP-QE are used, respectively. In order to better illustrate the comparison, the cumulative average throughput of the four solutions with the total 120 seconds simulation time are presented, by using a sub figure. As shown in Fig.7, it is obvious that MPTCP, also GMCC-Coop attains a larger average throughput than the eMTCP and MPTCP-QE solutions. This is because both MPTCP and GMCC-Coop use all available sub flows for the fastest possible data delivery. It can also be noticed that GMCCCoop achieves a lower average throughput than that of MPTCP. This is because GMCCCoop tries to remain fair to TCP-like AIMD-based competing flows under the control of its cooperation-oriented fairness-driven congestion control mechanism.
Compared with MPTCP and GMCC-Coop,MPTCP-QE and eMTCP perform a worse performance in terms of average throughput.This is because both MPTCP-QE and eMTCP trade throughput performance for longer battery lifetime and energy-saving. It is worth pointing out that MPTCP-QE is devoted to improving on eMTCP by being more energy efficient,however, MPTCP-QE’s throughput is very close to that of eMTCP (MPTCP-QE’s throughput is only 0.53% lower than that of eMTCP).That is because MPTCP-QE enables a proper available bandwidth-aware congestion window fast recovery strategy running at sender side to avoid unnecessary slow-start; it also enables an efficient SACK loss detection and fast retransmission mechanism at receiver side. These features possibly help MPTCP-QE improve the throughput performance.
3) User perceived quality for video streaming: Like [17], we use the Peak Signal-to-Noise Ratio (PSNR) and PSNR standard deviation metrics to measure video delivery performance. For PSNR calculation, we estimate it according to the following Eq. (13),
where MAX_Bitrate is the average bitrate of the transmitted video stream. EXP_Thr is the average throughput expected from the delivery of the video stream over the network, while CRT_Thr is the actual average throughput measured during video delivery. Both MAX_Bitrate and EXP_Thr are set to 2Mbps in the simulations.
Fig. 8 presents the PSNR (dB) comparison among the MPTCP, GMCC-Coop, eMTCP,and MPTCP-QE solutions. As the figure shows, MPTCP achieves the highest PSNR,while the GMCC-Coop attains the secondhighest PSNR in all cases. However, as previously mentioned, both MPTCP and GMCCCoop do not take into consideration the energy consumption problem when it allocates traffic across multiple paths. For the comparison between MPTCP-QE and eMTCP, we can observe that the high-level energy optimization behavior of the MPTCP-QE in fluences directly the PSNR which is less than that of other three solutions. This is actually the cost for deploying an energy-efficient behavior. We argue that this is acceptable to the users and worthy for energy savings since MPTCP-QE can obtain the same Mean Opinion Sore (MOS) as that of eMTCP does, according to the relationship between MOS and PSNR mentioned in [42].For instance after 120s of simulation time,the average PSNR of MPTCP, GMCC-Coop,eMTCP, and MPTCP-QE are 30.02, 28.32,26.43, and 25.54 dB, respectively, which have same MOS at ‘3-Fair’ level.
Fig.10 PSNR standard deviation comparison
Fig. 9 illustrates the comparison results of average video quality, expressed in terms of PSNR Standard Deviation (PSNR SD) when MPTCP, GMCC-Coop, eMTCP, and MPTCPQE are used, respectively. As thefigure shows,the PSNR is with frequent and huge fluctuations when using MPTCP, GMCC-Coop, and eMTCP for multipath video delivery. Frequent and deep fluctuations on the PSNR will undoubtedly cause jitter on the user perceived quality and suddenly degrade users’ quality of experience (QoE) for video streaming service.When using MPTCP-QE solution, The PSNR SD is much smaller in comparison with that of MPTCP, GMCC-Coop and eMTCP, indicating that MPTCP-QE results in lower PSNR fluctuations during video delivery. We thus can conclude that MPTCP-QE can enable smooth high-quality service for video streaming over heterogeneous wireless network environment.
In order to introduce the impact of application read rate fluctuations on PSNR performance, we conduct a particular simulation with an application read rate fluctuation pro file of <0, 1, 3> (period of 1 RTT), which means the receiving application does not read any data for one RTT, then at the read rate of 1 Mbps for one RTT, and then at the read rate of 3 Mbps for one RTT and again goes back to not reading. In such a particular pattern,using either MPTCP, GMCC-Coop, eMTCP,or MPTCP-QE, the receive buffer occupancy will increase because the average rate at which data is consumed by the receiving application(average at (0+1+3)/3 Mbps) is lower than network rate, and this will lead to a lower receiver window (rwnd), even rwnd of zero, ad-vertised from the receiver to the sender, which constraining the sender from transmitting more data due to the intrinsic MPTCP flow control characteristics.
Figs. 10(a) and 10(b) present a long-term(after 120s of simulation time) cumulative average PSNR and PSNR SD comparison when the read rate of receiving application fluctuates in a pattern of <0, 1, 3>, when MPTCP,GMCC-Coop, eMTCP, and MPTCP-QE are used, respectively. Compared to Fig. 8, we can observe that the PSNR performance, also PSNR differences between MPTCP-QE and other solutions decrease with the decrease in the average application read-rate. This is because all the four solutions restrict the maximum amount of data to be sent via the rwnd size, which is influenced directly by the application read-rate fluctuations. However, the PSNR performance of MPTCP-QE transcends that of eMTCP and becomes close to that of GMCC-Coop and MPTCP.
When comparing Fig. 10(b) and Fig. 9, it can be seen that the PSNR SD of all solutions increases with the increase in application readrate fluctuations. However, as shown in Fig.10(b), MPTCP-QE also maintains the PSNR SD at the lowest level when compared to the other three solutions. This is because MPTCPQE exploits the multiple paths by taking into account the difference between application read-rate and network rate, and introduces an adaptive application read-rate aware fully-MPTCP/ partial-MPTCP switching mechanism, which alleviates receive buffer occupancy and avoids underlying receive buffer blocking. Therefore, it can be concluded that compared with the other three solutions,MPTCP-QE demonstrates a good behavior as it best balances energy-saving and data transmission efficiency.
This paper proposes MPTCP-QE, a novel quality of experience (QoE)-driven energy-aware multipath content delivery approach for MPTCP-based mobile phones. MPTCPQE includes three major blocks, which are application rate-aware energy-efficient subflow usage management module that aims to track the application read rate of mobile phones and decide to use Partial MPTCP mode or Full MPTCP mode for data delivery, available bandwidth-aware cwnd fast recovery module that serves to enable a proper available bandwidth-aware cwnd fast recovery strategy in order to avoid unnecessary slow-start, and wireless-aware energy-efficient Selective ACK module that aims to detect SACK loss at receiver timely and choose a reverse path with low energy-cost for SACK delivery.
Although the simulation results reveal that the proposed MPTCP-QE obtains better energy-saving results than the existing solutions,the performance gain is not significant enough compared to the existing MPTCP extensions.We notice that recently many efforts have been devoted to optimizing the MPTCP performance by using network coding technologies [43-44], cross-layer activities [45-46], and virtual networking technologies [47].Motivated by the fact that the energy usage design of MPTCP associated with the real-time constraint of multimedia applications has become a hot topic [48], our future work will extend the proposed MPTCP-QE solution by applying these promising technologies to further improve the multipath multimedia delivery performance and optimize the energy consumption of multi-homed MPTCP-based mobile devices.
This work was supported by the National Natural Science Foundation of China (NSFC) under Grant No. 61562044, 61262014; the Natural Science Foundation of Jiangxi Province under Grant No. 20161BAB212046; the Project of Soft Science Research Plan of Jiangxi Province under Grant No. 20161BBA10010;the Science and Technology Research Project of Jiangxi Provincial Department of Education(GJJ150319); and the Higher School Teaching Reform Research Subject of Jiangxi Province(JXJG-15-2-35).
[1] J. Wu, C. Yuen, B. Cheng, M. Wang, J. Chen,“Streaming High-Quality Mobile Video with Multipath TCP in Heterogeneous Wireless Networks”,IEEE Transactions on Mobile Computing,vol.PP, no.99, 2016.
[2] F. Song, R. Li, H. Zhou, “Feasibility and Issues for Establishing Network-based Carpooling Scheme”,Pervasive and Mobile Computing,vol.24, pp.4-15, 2015.
[3] F. Song, M. Xue, S. Zhang, “Security Model for Analyzing Data Privacy in Multipath Transport”,China Communications, vol.9, no.5, 2012.
[4] J. Wu, C. Yuen, M. Wang, J. Chen, “Content-Aware Concurrent Multipath Transfer for High-Definition Video Streaming over Heterogeneous Wireless Networks”,IEEE Transactions on Parallel and Distributed Systems, vol.27, no.3, pp.710-723, 2016.
[5] http://galaxys5guide.com/samsung-galaxy-s5-features-explained/galaxy-s5-download-booster/
[6] A. Ford, C. Raiciu, M. Handley, S. Barre and J.Iyengar, “Architectural Guidelines for Multipath TCP Development”,IETF RFC 6182, 2011.
[7] M. Kheirkhah; I. Wakeman; G. Parisis, “MMPTCP:A multipath transport protocol for data centers”, inProc. of IEEE INFOCOM, pp.1-9, 2016.
[8] Q. D. Coninck, M. Baerts, B. Hesmans, O.Bonaventure, “Observing real smartphone applications over multipath TCP”,IEEE Communications Magazine, vol.54, no.3, pp.88-93, 2016.
[9] M. Li, A. Lukyanenko, S. Tarkoma, Y. Cui,Yla-Jaaski, “Tolerating path heterogeneity in multipath TCP with bounded receive buffers”,ACM SIGMETRICS Performance Evaluation Review-Performance evaluation review, vol.41,no.1, pp. 375-376, Jun. 2013.
[10] M. Li, A. Lukyanenko, Y. Cui, “Network Coding Based Multipath TCP”, inProc. of IEEE INFOCOM, 2012.
[11] Y. Zhang, H. Mekky, Z. Zhang, F. Hao, S. Mukherjee, T. V. Lakshman, “SAMPO: Online subflow association for multipath TCP with partial flow records”, inProc. of IEEE INFOCOM, pp.1-9, 2016.
[12] Q. Peng, A. Walid, J. Huwang, S. H. Low, “Multipath TCP: analysis, design, and implementation”,IEEE/ACM Transactions on Networking,vol.24, no.1, pp.596-609, 2016.
[13] F. Kaup, M. Wichtlhuber, S. Rado, D. Hausheer,“Can Multipath TCP save energy? A measuring and modeling study of MPTCP energy consumption”, inProc. of IEEE LCN, pp.442-445, 2015.
[14] T. A. Le, C. S. Hong, M. A. Razzaque, S. Lee, H.Jung, “ecMTCP: An Energy-Aware Congestion Control Algorithm for Multipath TCP”,IEEE Communications Letters, vol.16, no.2, pp.275-277, Feb. 2012.
[15] Q. Peng, M. Chen, A. Walid, S. Low, “Energy Efficient Multipath TCP for Mobile Devices”, inProc. of ACM MobiHoc, 2014.
[16] Y. Lim, Y. Chen, E. Nahum,et al., “How Green Multipath TCP for Mobile Devices?”, inProc. of ACM SIGCOMM workshop on AllThingsCellular, 2014.
[17] S. Chen, Z. Yuan, G.-M. Muntean, “An energy-aware multipath-TCP-based content delivery scheme in heterogeneous wireless networks”, inProc. of IEEE WCNC, 2013.
[18] R. Khalili, N. Gast, M. Popovic and J. Boudec,“MPTCP Is Not Pareto-Optimal: Performance Issues and a Possible Solution”,IEEE/ACM Transactions on Networking, vol.21, no.5, pp.1651-1665, Oct. 2013.
[19] P. Dong, J. Wang, J. Huang, H. Wang, G. Min,“Performance Enhancement of Multipath TCP for Wireless Communications with Multiple Radio Interfaces”,IEEE Transactions on Communications, vol.PP, no.99, 2016.
[20] S. Ferlin, Ö. Alay, T. Dreibholz, D. A. Hayes; M.Welzl, “Revisiting congestion control for multipath TCP with shared bottleneck detection”, inProc. of IEEE INFOCOM, pp.1-9, 2016.
[21] H. Sinky, B. Hamdaoui, M. Guizani, “Proactive Multipath TCP for Seamless Handoff in Heterogeneous Wireless Access Networks”,IEEE Transactions on Wireless Communications, vol.15,no.7, pp.4754-4764, 2016.
[22] M. Li, A. Lukyanenko, S. Tarkoma, A. Ylä-Jääski,“MPTCP Incast in Data Center Networks”,China Communications, vol.11, no.4, pp.25-37, 2014.
[23] B. Arzani, A. Gurney, S. Cheng, R. Guerin, B. Loo,“Deconstructing MPTCP Performance”, inProc.of IEEE ICNP, pp.269-274, Oct. 2014.
[24] S. H. Baidya, R. Prakash, “Improving the performance of multipath TCP over heterogeneous paths using slow path adaptation”, inProc. of IEEE ICC, pp.3222-3227, 2014.
[25] Y. Cao, M. Xu, X. Fu, E. Dong, “Explicit Multipath Congestion Control for Data Center Networks”,inProc. of ACM CoNEXT, pp.73-84, Dec. 2013.
[26] Q. Peng, A. Walid and S. Low, “Multipath TCP Algorithms: Theory and Design”, inProc. of ACM SIGMETRICS, pp.1-12, Jun. 2013.
[27] D. Zhou, W. Song, P. Wang, W. Zhuang, “Multipath TCP for user cooperation in LTE networks”,IEEE Network, vol.29, no.1, pp.18-24,Jan. 2015.
[28] https://support.apple.com/lv-lv/HT201373
[29] S. Sanadhya, R. Sivakumar, “Rethinking TCP flow control for smartphones and tablets”,Wireless Networks, vol.20, no.7, pp.2063-2080, 2014.
[30] S. Sanadhya, R. Sivakumar, “Adaptive flow control for TCP on mobile phones”, inProc. of IEEE INFOCOM, pp.2912-2920, 2011.
[31] Y. Cao, C. Xu, J. Guan, H. Zhang, “CMT-CC:Cross-Layer Cognitive CMT for Efficient Multimedia Distribution over Multi-homed Wireless Networks”,Wireless Personal Communications,vol.82, no.3, pp.1643-1663, Jun. 2015.
[32] J. Wu, C. Yuen, N. Cheung, J. Chen, “Delay-Constrained High Definition Video Transmission in Heterogeneous Wireless Networks with Multi-Homed Terminals”,IEEE Transactions on Mobile Computing, vol.15, no.3, pp.641-655, 2016.
[33] P. J. Rockwell and R. A. Davis, “Introduction to Time Series and Forecasting”, Springer, 1994.
[34] A. Ford, C. Raiciu, M. Handley, O. Bonaventure,“TCP extensions for multipath operation with multiple addresses”,IETFRFC 6824, Jan. 2013.
[35] M. Handley, J. Padhye, and S. Floyd, “TCP congestion window validation”,IETF RFC 2861, 2000.
[36] Y. Cao, C. Xu, J. Guan, H. Zhang, “Receiver-driven SCTP-based multimedia streaming services in heterogeneous wireless networks”, inProc. of IEEE ICME, 2014.
[37] Y. Cao, Q. Liu, G. Luo, M. Huang, “Receiver-driven Multipath Data Scheduling Strategy for In-order Arriving in SCTP-based Heterogeneous Wireless Networks”, inProc. of IEEE PIMRC, 2015.
[38] K. Shin, J. Kim, S. Choi, “Loss Recovery Scheme for TCP Using MAC MIB over Wireless Access Networks”,IEEE Communications Letters, vol.15,no.10, 2011.
[39] MPTCP-NS3 Project. Available: http://code.google.com/p/mptcp-ns3.
[40] F. Song, Y. Zhang, Z. An, H. Zhou and I. You,“The Correlation Study for Parameters in Four Tuples”, International Journal of Ad Hoc and Ubiquitous Computing, vol.19, no.1/2, pp.38-49, 2015.
[41] The VINT Project, The ns Manual (formerly ns Notes and Documentation). Available: http://www.isi.edu/nsnam/ns/doc/.
[42] S.-B. Lee, G.-M. Muntean, Alan F. Smeaton,“Performance-Aware Replication of Distributed Pre-Recorded IPTV Content”,IEEE Transactions on Broadcasting, vol.55, no. 2, pp.516-526, Jun. 2009.
[43] K. Xue, J. Han, H. Zhang, K. Chen, P. Hong, “Migrating Unfairness among Subflows in MPTCP with Network Coding for Wired-Wireless Networks”,IEEE Transactions on Vehicular Technology, vol.PP, no.99, 2016.
[44] Y. Cui, L. Wang, X. Wang, Y. Wang, “FMTCP: A Fountain Code-Based Multipath Transmission Control Protocol”, IEEE/ACM Transactions on Networking, vol.23, no.2, pp.465-478, 2015.
[45] X. Corbillon, R. Aparicio-Pardo, N. Kuhn, G. Texier, G. Simon, “Cross-layer scheduler for video streaming over MPTCP”, inProc. of ACM MMSys,2016.
[46] Y. Lim, Y. Chen, E.M. Nahum, D. Towsley, K. Lee,“Cross-layer path management in multi-path transport protocol for mobile devices”, inProc.of IEEE INFOCOM, pp.1815-1823, 2014.
[47] F. Song, D. Huang, H. Zhou, H. Zhang, I. You, “An Optimization-Based Scheme for Efficient Virtual Machine Placement”,International Journal of Paral-lel Programming, vol.42, no.5, pp. 853-872, 2014.
[48] J. Wu, C. Yuen, B. Cheng, M. Wang, J. Chen,“Energy-Minimized Multipath Video Transport to Mobile Devices in Heterogeneous Wireless Network”,IEEE Journal on Selected Areas in Communications, vol.34, no.5, pp.1160-1178,May 2016.