A Modification of the Fuzzy Logic Based DASH Adaptation Scheme for Performance Improvement

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 HistoryBased TCP Throughput Estimation. Moreover, mFDASH reduces the number of video bit-rate changes by applying Segment BitRate 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.


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 costeffective 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][8][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.

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: (1) buffer occupancy, (2) video playback quality, (3) video rate switching frequency and amplitude, and (4) 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 bitrate.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 bitrate.

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  1 and  2 .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: (1) centroid; (2) bisector; (3) middle of maximum; (4) largest of maximum; and (5) 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 V( + 1) 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.
(1) As shown in Figure 3(a), the range of (  ) (i.e., short becomes 1) in FDASH scheme is [0, 2/3], where  denotes the ideal buffer occupancy.Considering 2/3 is large enough (e.g., if  = 70 s, 2/3 = 46.67 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 [0, /3] to fully use the buffer.
(2) Also, we changed the range of (  ) (i.e., long becomes 1) from [4, ∞] to [2, ∞], since 4 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 Δ(  ) = (  ) − ( −1 ), which is the difference of the buffer occupancies between the case of the th segment completely received and the case of the ( − 1)th 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).
(1) Our analysis of the simulation results confirmed that even if the network condition is congested, Δ(  ) never drops below −/3 s.For that reason, we modify the range (i.e., falling becomes 1) from [−∞, −2/3] to [−∞, −/3], in order for Δ(  ) to be reflected in the FLC more accurately.
(2) Also, we modify the range (i.e., rising becomes 1) from 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 V( + 1) 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.The values of R, NC, and I can be calculated as ( 3), (4), and (5), while  is represented as (6) using the centroid method: (5)

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 V( + 1) or to keep the segment bit-rate as the previous one (V()), by using the average value of the throughputs of the segments downloaded within the past  window 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 if   /V( + 1) >  and (  ) <  high then (5) V( + 1) = V(); (6) end if (7) else if V( + 1) < V() then (8) if   /V( + 1) <  and (  ) >  low then (9) if  low−flag =  then (10)  low−flag = ; (11) end if (12) V( + 1) = V(); (13) end if (14) if q(t k ) < q low and q(t k ) > q min and q low−flag =  then (15)  low−flag = ; (16) else if q(t k ) < q low and q(t k ) > q min and q low−flag =  then (17) V( + 1) = V(); (18) end if (19)  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.

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 V( + 1) 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 V( + 1) or not.
Algorithm 1 is the pseudocode of the SBFM.The three factors named  high ,  low , and  min 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  high >  low >  min .After receiving V( + 1) from FLC, the SBFM decides whether V( + 1) is appropriate as the bit-rate of the next segment or not.
If V( + 1) is larger than V(), 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 V(+1) above a certain level, or if (  ) is larger than the buffer size.If V( + 1) is smaller than V(), 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 V( + 1) is larger than   over a certain level, or (  ) is smaller than  low .
Additionally, as the segment bit-rate has the possibility of being reduced continuously when (  ) drops below  low , we apply  low−flag to prevent the segment bit-rate from being reduced rapidly.The segment bit-rate decreases only one time when  low−flag is false, and (  ) is between  low and  min .After the decrease of the segment bit-rate,  low−flag is changed into true, and the segment bit-rate is unchanged while  low−flag is true.Despite the precedent decrease of the segment bit-rate, if (  ) drops below  min , 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 V( + 1) is larger than V( + 1) again,  low−flag is reversed to false.

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 Begin − flag =  (7) end if (8)  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 (V lowest ).After that, the Start Mechanism begins.In every iteration, V BEGIN is first set as Q(  /), where Q(⋅) 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  −1 , that is, there is enough bandwidth to increase the segment bit-rate, the bitrate is then switched to a higher bit-rate.On the other hand, if  −1 becomes higher than   , then Begin−flag is set to true, and the Start Mechanism is halted.

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,  high , the mFDASH client remains idle for (  )− high s, before sending out the request for the next segment.

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 Pointto-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 shortterm 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 (m avq ), the number of bit-rate changes (Num change ), the total number of interruptions (Int), 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  high = 100 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  low is set to 10 s.Also,  min 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 bitrate.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  = 3 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  = 2 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/(50 × 8) bytes, to make the expected value of  as average packet size.

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).
Table 1 shows m avq , Num change , and Int of DASH clients in C-P2P.First, all the schemes show zero Int.mFDASH shows almost similar m avq with FDASH client and lower Num change than FDASH.Particularly, SVAA shows the highest m avq and the lowest Num change .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.

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.
Table 2 summarizes m avq , 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 m avq 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.The link capacity is 1 Mbps during 0-190 s and after 190 s, the short-term variation starts between 1 and 2 Mbps.Table 3 shows m avq , 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 m avq and the lowest number of bit-rate changes.Also, there is no video interruptions in any DASH clients.

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   The average value of m avq and the number of bit-rate changes of the ten Wi-Fi experiments are also outlined in Table 4, as well as the Int.Table 4 shows that mFDASH has 11.6%, 1.8% higher average m avq , 49.4%, and 81.9% lower average Num change 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 m avq is accompanied by high Num change .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 bitrate changes.This means that FDASH can not find optimal bit-rate in particular network and hardware conditions.In contrast, mFDASH shows highest m avq and lowest Num change , 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   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 m avq while SVAA shows the highest m avq .Nevertheless, SVAA is not the best adaptation scheme since high m avq is accompanied by high Num change .
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 m avq to a mobile DASH client and, most importantly, shows the least Num change .
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), ∑  =1 (  ) considers the total bit-rate of downloaded segments, Int considers the rebuffering time occurred, and ∑ −1 =1 (( +1 ) − (  )) 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 QoE hd .The QoE value in Wi-Fi network is the average value of  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).

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   ,  start, ,  end, , and  denote the average operation time for one segment, the time when the DASH client starts to calculate kth segment's bit-rate (V()), the time when the DASH client finishes the calculation of V(), 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.

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.

Figure 2 :
Figure 2: The fundamental architecture of FLC.

Figure 4 :
Figure 4: Membership functions of the input and the output in mFDASH.

Figure 7 :
Figure 7: Segment bit-rate variations at the very beginning of streaming service.

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 Figure7, one point indicates one downloaded video segment.At first, the

Figure 8 :
Figure 8: Simulation result in constant link Point-to-Point network.
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 Figure11is described in Figure9(b).

Figure 9 :
Figure 9: Link capacity of links with bandwidth variations.

Figure 10 :Figure 11 :
Figure 10: Simulation result in long-term bandwidth variation Point-to-Point network.

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 Figure11(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 Figures11(a) and 11(b), it is clearly shown that even if there are shortterm periodic picks and falls during 200 s-1000 s, all the three algorithms operate normally without showing frequent bitrate switching.
), 13(a), and14(a)  show the bit-rates of the segments that are fetched by the mobile DASH clients.Also, Figures12(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  high as shown below and those facts can decrease the QoE of mobile FDASH clients.Meanwhile, each (  ) of the mFDASH and SVAA client never exceeds  high , even if the network conditions are poor and unpredictable.In addition, as shown in Figure 12(b) andTable 4, the SVAA client experiences playback interruptions while other clients experience no playback interruptions.

Figure 12 :
Figure 12: First simulation result in Wi-Fi network with a mobile DASH client and five background traffic events.

Figure 13 :
Figure 13: Second simulation result in Wi-Fi network with a mobile DASH client and five background traffic events.

Figure 14 :
Figure 14: Third simulation result in Wi-Fi network with a mobile DASH client and five background traffic events.

Figure 15 :
Figure 15: Simulation result in Wi-Fi network with a TV set-top Box DASH client and five background traffic events.

Figure 16 :
Figure 16: Simulation result in LTE network with a mobile DASH client and five background traffic events.

Figure 17 :
Figure 17: Simulation result in LTE network with three mobile DASH clients and five background traffic events.

end if
Algorithm 2: The Start Mechanism.

Table 1 :
Performance in long-term bandwidth variation Point-to-Point network.

Table 3 :
Performance in periodic short-term bandwidth variation Point-to-Point network.

Table 4 :
Average performance value of ten Wi-Fi networks with a mobile dash client and five background traffic events.

Table 5 :
Performance in Wi-Fi networks with a TV set-top box DASH client and five background traffic events.

Table 6 :
Performance in LTE network with a mobile DASH client and five background traffic events.

Table 5 ,
mFDASH provides the highest m avq and the lowest Num change .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

Table 7 :
Performance in LTE network with three mobile DASH clients and five background traffic events.