Abstract
We propose a modification of the fuzzy logic based DASH adaptation scheme (FDASH) for seamless media service in time-varying network conditions. The proposed scheme (mFDASH) selects a more appropriate bit-rate for the next segment by modification of the Fuzzy Logic Controller (FLC) and estimates more accurate available bandwidth than FDASH scheme by using History-Based TCP Throughput Estimation. Moreover, mFDASH reduces the number of video bit-rate changes by applying Segment Bit-Rate Filtering Module (SBFM) and employs Start Mechanism for clients to provide high-quality videos in the very beginning stage of the streaming service. Lastly, Sleeping Mechanism is applied to avoid any expected buffer overflow. We then use NS-3 Network Simulator to verify the performance of mFDASH. Upon the experimental results, mFDASH shows no buffer overflow within the limited buffer size, which is not guaranteed in FDASH. Also, we confirm that mFDASH provides the highest QoE to DASH clients among the three schemes (mFDASH, FDASH, and SVAA) in Point-to-Point networks, Wi-Fi networks, and LTE networks, respectively.
1. Introduction
Recently, mobile data traffic is increasing rapidly due to the development of wireless communication network and mobile devices. According to the Global Mobile Data Traffic Forecast by Cisco [1], mobile data traffic grew 18-fold from 2011 to 2016, while mobile video traffic accounted for 60% of total mobile data traffic in 2016. Moreover, mobile video traffic is expected to increase 9-fold between 2016 and 2021 and account for up to 78% of total mobile data traffic. In this situation, dynamic adaptive streaming over HTTP (DASH) [2, 3] is adopted globally as a new standard for mobile video streaming to provide seamless video streaming services and utmost QoE to DASH clients in time-varying network conditions. By using HTTP/TCP protocol, DASH can overcome the firewall problem, in contrast with RTP/UDP in the past. It is also cost-effective due to the employment of standard HTTP servers. In DASH, media content is encoded into various versions at different bit-rates and divided into multiple segments, which are used to be played for seconds or tens of seconds. After the division, the segments are stored in the HTTP servers. To obtain utmost QoE, DASH clients act accordingly by requesting segments that are appropriate in the variable network conditions.
Recently, the fuzzy logic [4, 5] based rate adaptation scheme called FDASH [6] has been proposed. FDASH shows better performance than any other rate adaptation schemes from the aspect of the average video bit-rate and the seamlessness of video playback. However, FDASH pays no attention to buffer overflow, which is the cause of video packet loss, and shows a high number of video bit-rate changes, even though buffer overflow and number of video bit-rate changes have a decisive effect on the QoE [7–9]. Therefore, to provide optimal QoE for DASH clients, it is important to reduce the number of video bit-rate changes and to prevent buffer overflow. The more details about FDASH are described in Section 2, “Related Work” part.
In this paper, we propose a modification of FDASH for seamless media services in time-varying network conditions. The proposed scheme (mFDASH) selects a more appropriate bit-rate for the next segment by modification of the Fuzzy Logic Controller (FLC) [10, 11] and reduces the number of video bit-rate changes by applying the Segment Bit-Rate Filtering Module (SBFM). Also, we use the History-Based TCP Throughput Estimation (HBTTE) to more accurately predict throughputs upon smoothness of throughput and to select optimal next segment bit-rate, which is different from the throughput estimation method applied in FDASH (FHBTTE). By using this, SBFM can be operated more precisely. Also, we apply the Start Mechanism for clients to provide high-quality videos in the very beginning stage of the streaming service. Lastly, we add the Sleeping Mechanism to avoid any expected buffer overflow.
The NS-3 (network simulator) [12] is used to verify the performance of mFDASH. Upon the experimental results, mFDASH shows no buffer overflow within the limited buffer size, which is not guaranteed in FDASH. Also, we confirm that mFDASH provides the highest QoE to DASH clients among the three schemes (mFDASH, FDASH, and Smooth Video Adaptation Algorithm (SVAA)) in Point-to-Point networks, Wi-Fi networks, and LTE networks, respectively.
This paper is structured as follows. Section 2 outlines the related work. Section 3 introduces the FLC used in our scheme, while Section 4 describes the other components. Section 5 presents the simulation environment setting and results, while Section 6 concludes the paper.
2. Related Work
There have been plenty of researches on the rate adaptation scheme, mainly due to the tremendous increase of video traffic and demands for high Quality of Experience (QoE) created by DASH clients. mDASH presented in [13] selects an appropriate segment bit-rate by using the Markov theory [14, 15]. mDASH then judges whether the selected segment bit-rate is optimal or not, by using the reward values of the following factors: buffer occupancy, video playback quality, video rate switching frequency and amplitude, and buffer overflow. Moreover, mDASH considers future reward values to provide better QoE to DASH clients.
Reference [16] proposed a rate adaptation scheme using scalable video coding (SVC) [17]. The scheme uses channel state information in the physical layer together with information of the video content, video buffer, and so on in the application layer, to optimally allocate radio resources to DASH clients in Broadband Wireless Access systems, such as LTE or WiMAX. By using this scheme, more radio resources can be allocated to the closer segments to the playback deadline.
The rate adaptation scheme called SVAA [18] uses buffer occupancy and buffer trend to select the segment bit-rate. Also, SVAA uses the estimated throughput value, which is estimated using the HBTTE [19] method and the real throughput value to select a more appropriate segment bit-rate. In addition, the SVAA scheme applies a buffer cap, which limits the buffer occupancy from overflowing.
Recently, the fuzzy logic based rate adaptation scheme (FDASH) has been proposed. Figure 1 shows the architecture of FDASH scheme. At first, DASH clients receive segments from DASH server and store them in their Playback Buffers. Then, the information about buffer occupancy and differential of buffer occupancies is conveyed to the FLC of FDASH as two input variables. With those two input variables, FLC calculates the next segment bit-rate (i.e., , where is the throughput estimation value calculated in FHBTTE Calculator) and then FDASH scheme (FS) decides to request the next segment with the calculated bit-rate or just to request the next segment with the previously requested bit-rate.
3. Fuzzy Logic Controller
In this section, we describe the FLC that we apply in our scheme. As a control system based on fuzzy logic, the FLC consists of a Fuzzification Interface, Knowledge Base, Decision-Making Logic, and Defuzzification Interface, as shown in Figure 2.
(1) The Knowledge Base. The Knowledge Base (KB) comprises a data base and a rule base. The data base provides the definitions that are necessary to use fuzzy values (input/output linguistic variables) and fuzzy rules. Among the definitions, membership functions of linguistic variables represent the degree of belonging of the crisp input/output to the linguistic variables. In addition, fuzzy rules in the rule base are simple if-then rules and consist of linguistic variables. The fuzzy rules decide the degree of output linguistic variables by using the input linguistic variables.
(2) The Fuzzification Interface. In the Fuzzification interface, a crisp input is mapped into the universe of discourse, and the fuzzy input values (i.e., input linguistic variables) are determined by the mapped value and the defined input membership functions in the KB.
(3) Decision-Making Logic. In the Decision-Making Logic, fuzzy output (i.e., linguistic variable) is deduced from fuzzy inputs by the fuzzy rules following a format described below:where is a input linguistic variable for all and is a output linguistic variable for all . If the operator is and, then is the minimum value between and . In the case of or, is the maximum value. Also, the number of input linguistic variables can be increased.
(4) The Defuzzification Interface. In the Defuzzification Interface, output linguistic variables are mapped into the universe of discourse, and crisp output is calculated with the mapped value. Several methods exist in Defuzzification method: centroid; bisector; middle of maximum; largest of maximum; and smallest of maximum [20]. In our FLC, the centroid method is applied.
Like the FLC of FDASH, FLC in mFDASH has two input variables and one output variable . The variable stands for the amount of decrease or increase of the HBTTE value and is used as follows:where is the HBTTE value and is the next segment bit-rate. Since the available segment bit-rates of a media content in a DASH server are discrete, is quantized by to the highest value that is lower than .
Figures 3 and 4 show the membership functions of the input and output variables in FLC of FDASH and mFDASH, respectively. Buffer occupancy means the amount of data in a buffer when the latest requested th segment is completely received and is denoted by . Three linguistic variables [short (S), close (C), and long (L)] are selected to depict the state of the buffer occupancy in both FLC. In our scheme, the ranges of membership functions of in FDASH scheme are modified as follows.
(a) Buffer occupancy
(b) Differential of the buffer occupancy
(c) Output
(a) Buffer occupancy
(b) Differential of the buffer occupancy
(c) Output
As shown in Figure 3(a), the range of (i.e., short becomes 1) in FDASH scheme is , where denotes the ideal buffer occupancy. Considering is large enough (e.g., if s, s), the segment bit-rate can be reduced before the buffer is fully used since the FLC judges that the buffer is in the risk of underflow even though 46.67 s does not indicate the shortage of buffer. Therefore, in mFDASH, the range is modified to to fully use the buffer.
Also, we changed the range of (i.e., long becomes 1) from to , since is too large value as the reference point of buffer overflow. With this modification, FLC decides more appropriate bit-rate of the next segment when the buffer occupancy is close to the buffer limit.
Figures 3(b) and 4(b) show the membership functions of differential of the buffer occupancies. The differential of the buffer occupancies is denoted as , which is the difference of the buffer occupancies between the case of the th segment completely received and the case of the segment completely received. Similar to , the status of the second input () is depicted by three linguistic variables [falling (F), steady (S), and rising (R)]. The following modifications are applied to the ranges of the membership functions of in Figure 3(b).
Our analysis of the simulation results confirmed that even if the network condition is congested, never drops below s. For that reason, we modify the range (i.e., falling becomes 1) from to , in order for to be reflected in the FLC more accurately.
Also, we modify the range (i.e., rising becomes 1) from to . It is clear that cannot be higher than , even if the network condition is extremely good. By this modification, the FLC can more accurately judge in the good network condition.
As shown in Figure 3(c), five linguistic variables (reduce (R), small reduce (SR), no change (NC), small increase (SI), and increase (I)) are used in FLC of FDASH. But for the output variable () in mFDASH, only three linguistic variables [reduce (R), no change (NC), and increase (I)] are used with the expectation that the less bit-rate changes will occur if the less linguistic variables are used. Figure 4(c) shows that the ranges of the output membership functions are divided into the fractionation of into , , and . is a factor that decreases compared to the HBTTE value, and the range is . The second factor with the value of 1 retains as . The last factor with the range of increases compared to the HBTTE value.
The fuzzy rules are shown below.
Fuzzy Rules(1)if short and falling then R: (2)if close and falling then R: (3)if short and steady then R: (4)if long and falling then NC: (5)if close and steady then NC: (6)if short and rising then NC: (7)if long and steady then I: (8)if close and rising then I: (9)if long and rising then I:
The values of , , and can be calculated as (3), (4), and (5), while is represented as (6) using the centroid method:
4. mFDASH Scheme
In connection with the architecture of Figure 1, Figure 5 shows the fundamental architecture of mFDASH. As shown in Figure 5, mFDASH consists of previously mentioned components (SBFM, Sleeping Mechanism, HBTTE Calculator, and Start Mechanism) as well as the components (FLC, Playout Buffer, and HTTP Request) already existing in FDASH. Although the FLCs in both schemes use the same inputs, the detail operations are modified as described in Section 3. In this section all the components other than the FLC are described.
4.1. The Throughput Estimation Method
FDASH scheme judges whether to request the next segment of or to keep the segment bit-rate as the previous one (), by using the average value of the throughputs of the segments downloaded within the past s. This method (FHBTTE) greatly smoothens the available bandwidth, but it cannot detect outliers and level shifts of throughputs, which lead to inaccurate throughput estimation values. Thus, mFDASH applies the HBTTE method [19], which conducts the same function as the FHBTTE and additionally detects the outliers and the level shifts of throughputs.
Figure 6 shows the difference between the two throughput estimation methods in a Wi-Fi network. The FHBTTE values cannot predict the actual TCP throughput value properly during 0~70 s, since it cannot detect the level shifts. On the other hand, because of the detections of the level shifts, the HBTTE method predicts the actual TCP throughputs more accurately than the FHBTTE method does. Also, the HBTTE method shows appropriate smoothness with the detection of outliers. With this method, mFDASH can choose a proper segment bit-rate that leads the of the client into the safe region and provides a higher quality of video.
4.2. The Segment Bit-Rate Filtering Module
The output variable is decided by and . For this reason, if the video quality is changed, and are also changed in a moment. As the preceding changes directly influence , so the next will be changed sequentially. Therefore, oscillation of the segment bit-rate will occur if is decided only by using . To solve this problem, we additionally apply the SBFM to decide whether the current segment bit-rate will be changed to or not.
Algorithm 1 is the pseudocode of the SBFM. The three factors named , , and indicate the maximum buffer occupancy, the threshold that prevents a sharp decline of the segment bit-rate, and the threshold that prevents the buffer underflow, respectively; and the size-order of these factors is . After receiving from FLC, the SBFM decides whether is appropriate as the bit-rate of the next segment or not.
| ||||||||||||||||||||||||||||||||||||||
If is larger than , we need to consider and , to avoid oscillation of the bit-rate and buffer overflow. Thus, we only increase the segment bit-rate if is larger than above a certain level, or if is larger than the buffer size. If is smaller than , this indicates that is on the verge of depletion. Therefore, to prevent frequent bit-rate change and depletion of buffer, we need to reduce the segment bit-rate if the ratio of is larger than over a certain level, or is smaller than .
Additionally, as the segment bit-rate has the possibility of being reduced continuously when drops below , we apply to prevent the segment bit-rate from being reduced rapidly. The segment bit-rate decreases only one time when is false, and is between and . After the decrease of the segment bit-rate, is changed into true, and the segment bit-rate is unchanged while is true. Despite the precedent decrease of the segment bit-rate, if drops below , this indicates that the buffer will soon be depleted. So, the segment bit-rate should be decreased rapidly, until is changed into positive. Then if is larger than again, is reversed to false.
4.3. The Start Mechanism
Due to the SBFM, there is a possibility that a DASH client watches a low-quality video for a certain period of time in the very beginning of a streaming service. Therefore, in mFDASH, we apply the Start Mechanism to guarantee higher quality video at the start of streaming service and to prevent buffer underflow which can occur due to the rapid increase of segment bit-rate.
Algorithm 2 is the pseudo code of the Start Mechanism. Before the start of the Start Mechanism, the first segment is requested with the lowest bit-rate (). After that, the Start Mechanism begins. In every iteration, is first set as , where and denote a quantization function that outputs a lowest value that is higher than an input value and a control factor for the first segment bit-rate, respectively. The factor prevents buffer underflow in the case that suddenly decreases. Then if is larger than , that is, there is enough bandwidth to increase the segment bit-rate, the bit-rate is then switched to a higher bit-rate. On the other hand, if becomes higher than , then is set to true, and the Start Mechanism is halted.
| ||||||||||||||||
4.4. The Sleeping Mechanism
In general, the buffer size of a mobile device is limited. Thus, during a streaming service, if exceeds the maximum buffer size, that is, , the mFDASH client remains idle for s, before sending out the request for the next segment.
5. Performance Evaluation
In this section, we evaluate mFDASH scheme by analyzing the results of the experiments conducted in the NS-3. The results of mFDASH are compared with the results of FDASH and SVAA schemes. Our experiments are implemented in three Point-to-Point network conditions, ten Wi-Fi network conditions, and two LTE network conditions. In three Point-to-Point network conditions, a DASH server and a DASH client are connected by a Point-to-Point link. First link network has constant link capacity. Also, there are long-term changes in the second Point-to-Point link capacity and short-term periodic picks and falls lasting 10 s in the third Point-to-Point link capacity. In Wi-Fi network conditions, there is a DASH server, a mobile (or TV set-top box) DASH client, and five background traffic events. We implement ten different experiments in Wi-Fi network conditions by changing the background traffic. In LTE network conditions, there are two scenarios. The first scenario consists of one mobile DASH client (SVAA, FDASH, or mFDASH) with five background traffic events and the second one consists of three mobile DASH clients (one for each algorithm) and five background traffic events. In each session the average segment bit-rate (), the number of bit-rate changes (), the total number of interruptions (), and the existence of buffer overflow are described. Moreover, to evaluate the performance of the proposed schemes realistically, we use a QoE model proposed in [21]. Furthermore, in the last part of this section, the time taken by each scheme is compared with each other to show the complexity of the proposed method.
In our experiments, we set s; that is, we assume that the buffer sizes of all mobile devices in the simulation are 100 s, since this is reasonable considering the performance of current mobile devices. The ideal buffer occupancy () is set to 70 s, and is set to 10 s. Also, is set to 7 s, since it is the minimum buffer occupancy to avoid buffer underflow and to use the buffer most efficiently. The factors of output membership functions in FLC (, , ) are set to 0.8, 1, and 1.3, respectively, to select optimal segment bit-rate. The two factors and used in SBFM are set to 0.85 and 1.3, respectively, to change the segment bit-rate properly when the network condition is extremely good or bad. Also, we set to select a proper segment bit-rate when the streaming service starts. In our experiments, the DASH server provides twenty different versions of segment bit-rate: 45, 89, 131, 178, 221, 263, 334, 396, 522, 595, and 791 kbps; and 1.033, 1.245, 1.547, 2.134, 2.484, 3.079, 3.527, 3.840, and 4.220 Mbps with the segment duration of s and all the videos are played for 1000 s. Also, to simplify the simulation, we assume that the duration between each MPEG frame is 20 ms (i.e., 50 frames per second) and each segment contains 100 MPEG frames with each frame size where is uniform random variable within [0, 2 average_packet_size]. The maximum frame size is set to 2 average_packet_size, where average_packet_size = Segment Bitrate/() bytes, to make the expected value of as average_packet_size.
5.1. Effect of the Start Mechanism
Figure 7 shows the segment bit-rate variations at the very beginning of the streaming service in a Wi-Fi network for the two cases, which include one with the Start Mechanism and another without the Start Mechanism. -axis indicates the simulation time and -axis indicates the bit-rate of segments. In Figure 7, one point indicates one downloaded video segment. At first, the streaming service starts with the lowest bit-rate (45 kbps). In the case of mFDASH without Start Mechanism, 30 segments with the lowest bit-rate are fetched by the mFDASH client and stored in the Playback Buffer; that is, DASH clients should watch the lowest quality video for 60 s ( s). On the other hand, in the case of mFDASH with Start Mechanism, the DASH client can watch higher quality of video, since the DASH client keeps increasing the segment bit-rate as much as possible by Start Mechanism.
5.2. Point-to-Point Network with Constant Link Capacity (C-P2P)
Figure 8 is the simulation results in Point-to-Point link with constant link capacity. The link capacity of the constant link is 4 Mbps. The segment bit-rates that are fetched by each DASH client are shown in Figure 8(a). Also, the buffer occupancy of each DASH client is described in Figure 8(b).
(a) Segment bit-rate
(b) Buffer occupancy
Table 1 shows , , and of DASH clients in C-P2P. First, all the schemes show zero . mFDASH shows almost similar with FDASH client and lower than FDASH. Particularly, SVAA shows the highest and the lowest . However, this does not mean that SVAA is the best scheme and the reason of this will be described with all the other simulation results in Section 5.7.
5.3. Point-to-Point Network with Long-Term Bandwidth Changes (L-P2P)
Figure 10 shows the experiment results when the DASH server is connected with the client by a L-P2P. The link capacity of the L-P2P in Figure 10 is described in Figure 9(a), and it changes sequentially to 1, 2.5, 2, 3, 2, 2, 2.5, 3, 2.5, and 3 Mbps for every 100 s. Figure 10(a) shows the bit-rate of segments that are downloaded from SVAA, FDASH, and mFDASH clients. Also, Figure 10(b) shows each buffer occupancy () of SVAA, FDASH, and mFDASH. In the case of FDASH, buffer overflow occurs since of FDASH rises over 120 s with the buffer limit of 100 s. In other words, the FDASH clients lose several video segments due to the buffer overflow, which results in decrease of the clients’ QoE. On the other hand, SVAA clients avoid buffer overflow due to the buffer cap, and mFDASH clients avoid buffer overflow due to the Sleeping Mechanism.
(a) Long-term
(b) Short-term
(a) Segment bit-rate
(b) Buffer occupancy
Table 2 summarizes , the number of bit-rate changes, and the number of video interruptions of DASH clients in L-P2P. The mFDASH client has almost the same compared to those of other schemes. Moreover, mFDASH shows the lowest number of bit-rate changes. Also, all the three schemes show no playback interruptions.
5.4. Point-to-Point Network with Short-Term Bandwidth Changes (S-P2P)
Figure 11 shows the experimental results when the available bandwidth of the Point-to-Point link has short-term periodic picks and falls lasting 10 s. The link capacity of the S-P2P in Figure 11 is described in Figure 9(b). The link capacity is 1 Mbps during 0–190 s and after 190 s, the short-term variation starts between 1 and 2 Mbps. Figure 11(a) describes the bit-rate of segments fetched by SVAA, FDASH, and mFDASH clients. Also, each of SVAA, FDASH, and mFDASH is shown in Figure 11(b), and the results indicate that mFDASH and SVAA have lower possibilities of the occurrence of buffer overflow because of the Sleeping Mechanism and the buffer cap. Also, according to Figures 11(a) and 11(b), it is clearly shown that even if there are short-term periodic picks and falls during 200 s–1000 s, all the three algorithms operate normally without showing frequent bit-rate switching.
(a) Segment bit-rate
(b) Buffer occupancy
Table 3 shows , the number of bit-rate changes, and the number of video interruptions of DASH clients. According to Table 3, the mFDASH client shows the highest and the lowest number of bit-rate changes. Also, there is no video interruptions in any DASH clients.
5.5. Wi-Fi Network
In our experiment, we evaluate mFDASH in ten different Wi-Fi network conditions. In this section, we only attach three cases because of the paper space consideration. However, of coarse, we reflected all the simulation results in the calculation of performance index in Table 4.
Figures 12(a), 13(a), and 14(a) show the bit-rates of the segments that are fetched by the mobile DASH clients. Also, Figures 12(b), 13(b), and 14(b) show the mobile DASH clients’ . Each of the mobile FDASH client in Figures 13(b) and 14(b) exceeds as shown below and those facts can decrease the QoE of mobile FDASH clients. Meanwhile, each of the mFDASH and SVAA client never exceeds , even if the network conditions are poor and unpredictable. In addition, as shown in Figure 12(b) and Table 4, the SVAA client experiences playback interruptions while other clients experience no playback interruptions.
(a) Segment bit-rate
(b) Buffer occupancy
(a) Segment bit-rate
(b) Buffer occupancy
(a) Segment bit-rate
(b) Buffer occupancy
The average value of and the number of bit-rate changes of the ten Wi-Fi experiments are also outlined in Table 4, as well as the . Table 4 shows that mFDASH has 11.6%, 1.8% higher average , 49.4%, and 81.9% lower average than FDASH and SVAA, respectively. As shown in the results in Table 4, SVAA does not selects optimal bit-rates in every time, since high average is accompanied by high . This means that SVAA operate inefficiently to find optimal bit-rate. FDASH, on the other hand, selects a bit lower bit-rates than SVAA with lower bit-rate changes. This means that FDASH can not find optimal bit-rate in particular network and hardware conditions. In contrast, mFDASH shows highest and lowest , which means that mFDASH can find optimal bit-rate very efficiently.
In addition to those results with mobile DASH clients, we also simulate with a fixed wireless TV set-top box DASH client to prove that mFDASH works well in clients with various types of device. Wireless TV set-top box has powerful hardware, so we assume that set-top box DASH clients has no buffer limit. Also, we use the background traffic used in sixth Wi-Fi simulation. All the other configurations are the same as other simulations. Figure 15 shows the simulation results with one TV set-top box DASH clients and 5 background traffic events. Table 5 outlines the performance evaluation indicators that are the same as Tables 2, 3, and 4. As shown on Table 5, mFDASH provides the highest and the lowest .
(a)
(b)
5.6. LTE Networks
We also evaluate our scheme in two LTE networks. Briefly outlining the configuration of both LTE networks, there is only one base station that serves the mobile DASH clients and 50 Physical Resource Blocks (PRBs) are used as radio resources. Also, the Extended Vehicular A (EVA) fading model is used as a fading model and Log-Distance Propagation Loss model is used. Moreover, Proportional Fair resource allocation scheme is used as the resource allocation scheme in the base station.
Same as described earlier, Figure 16(a) represents the segment bit-rates downloaded by mobile DASH clients and Figure 16(b) represents mobile DASH clients’ buffer occupancies. Also, performance results of the first LTE simulation are outlined in Table 6. FDASH and mFDASH show almost the same while SVAA shows the highest . Nevertheless, SVAA is not the best adaptation scheme since high is accompanied by high .
(a) Segment bit-rate
(b) Buffer occupancy
Figure 17 shows the simulation result in the second LTE network. In that LTE network, three rate adaptation schemes are applied in each one of the three mobile DASH clients. As shown in Table 7, mFDASH provides the highest to a mobile DASH client and, most importantly, shows the least .
(a) Segment bit-rate
(b) Buffer occupancy
5.7. Quality of Experience Evaluation
In this paper, we use a QoE model proposed in [21]. The equation of the QoE model is shown as follows:where is the bit-rate utility function, is the bit-rate of th downloaded segments in Mbps unit, N is the number of segments downloaded, and IntTime is the total rebuffering time, respectively. The coefficient decides how much rebuffering time has influence on QoE and is set as Table 8 [21]. As you can see in (7), considers the total bit-rate of downloaded segments, Int considers the rebuffering time occurred, and considers the number of video quality switching and the variance of video quality, respectively.
The QoE model puts emphasis on High Definition (HD) video by scoring each bit-rate by referring to [22]. According to [22], video bit-rate range of 720 p (which is the start point of HD) is 1500–4000 kbps. By referring this, we scored each of the bit-rate as Table 8.
Figure 18 shows the QoE values calculated with . The QoE value in Wi-Fi network is the average value of ten simulation results. Also, the QoE values are normalized with the largest QoE value in each network environment. First of all, SVAA shows the highest QoE value in (b). Also, SVAA shows quite similar QoE value in (a). However, SVAA shows the lowest QoE value in other networks. This means that SVAA scheme is only suitable in the networks with a few or zero bandwidth changes, which are not common in real world. In the case of mFDASH and FDASH, mFDASH shows almost the same QoE value compared to FDASH in (a) and (b). However, as the network has become more and more confusing (i.e., more realistic networks such as link network with short term periodic changes, Wi-Fi, and LTE), the QoE gap between mFDASH and FDASH increases. In (c), mFDASH shows 0.7% higher QoE value than FDASH while showing 7.4% higher QoE value in (d). Also, mFDASH shows 14.6% higher performance in (e), 15.5% higher performance in (f), and 15.4% higher QoE value in (g).
5.8. Complexity of Proposed Scheme
As the proposed method is a modified version of the existing method (FDASH), it is important to evaluate the complexity of the proposed method. Table 9 represents time taken by each rate adaptation scheme. The operation time is calculated as follows:where , , , and denote the average operation time for one segment, the time when the DASH client starts to calculate kth segment’s bit-rate ()), the time when the DASH client finishes the calculation of , and the total number of segments that are fetched by a DASH client, respectively. According to Table 9, mFDASH takes longer time than FDASH while SVAA takes the shortest time. Whenever more DASH clients try to fetch optimal video segment, they should conduct more complex rate adaptation scheme as a trade-off relationship. In other words, the longest operation time in mFDASH is acceptable since it provides the highest QoE to DASH clients.
6. Conclusions
This paper proposes a modified FDASH scheme for dynamic HTTP streaming. Our scheme modifies FLC of FDASH to make it choose more appropriate segment bit-rates and applies SBFM to reduce the number of bit-rate changes. Also, the HBTTE method is used to estimate throughput more accurately and to let the DASH clients choose optimum segment bit-rate, and the Start Mechanism is applied to rapidly switch to the higher bit-rate in the very beginning of a video. Lastly, the Sleeping Mechanism is applied to prevent buffer overflow. By choosing appropriate values for the factors described in Section 5, we maximize the performance of the average segment bit-rate and minimize the number of video rate changes in mFDASH. Moreover, we validate our scheme in various networks such as Point-to-Point, Wi-Fi, and LTE networks by using NS-3. The obtained results show that compared to FDASH and SVAA, the proposed scheme provides the highest QoE to a DASH client.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
This work was supported by ICT R&D program of MSIP/IITP [R0101-16-0189, Development of the Next Generation Convergence Broadcasting and Monitoring Systems combined with the Networks].