Printer Friendly

Adaptive Multi-Connection DASH Scalable Video Coding for Wireless Area Networks.

1. INTRODUCTION

Dynamic Adaptive Streaming over Hypertext Transfer Protocol HTTP (DASH) has gained a significant momentum and is widely adopted by many standardization bodies such as open Internet Protocol Television(IPTV) and the 3rd Generation Partnership Project (3GPP)[1, 2]. HTTP streaming has several attractive features that helped in speeding up its acceptance over other traditional streaming techniques such as Real-time Transport Protocol/User Datagram Protocol(RTP/UDP) [3, 4]. Avoiding firewall and Network Address Translation (NAT) traversal issues represent major advantages of HTTP streaming. Another advantage of using HTTP is the availability of HTTP cache infrastructures on the Internet that relieves not only the server load but also reduces the overall uplink traffic towards the cache[5, 6]. High end-to-end delay on the communication link (resulting from the limitation of the available transmission BandWidth (BW) is the main drawback of using HTTP streaming[7-9]. Adaptive streaming techniques are commonly used to avoid the limitation of the transmission BW. They accommodate the variations in the transmission BW in order to avoid annoying streaming interruption[10, 11]. Another problem of using HTTP streaming is the possibility of reducing the link efficiency due to Transmission Control Protocol (TCP) dynamics, however, this can be compensated by using a client-buffer[12].

Adaptive streaming techniques are commonly used to accommodate variations in the BW of transmission medium. As a result, annoying streaming interruption, due to buffer under-run, can be avoided. If Advanced Video Coding (AVC) based on H.264/MPEG-4 Part 10 standard is used, the server would contain multiple versions of each encoded segment at different qualities (resolution and frame rates) [6, 13]. Dynamic Adaptive Streaming over Scalable Video Coding (SVC-DASH) represents an extension to the AVC-DASH standard [10, 14]. SVC-DASH encodes the video segment into N layers including a base layer and numerous enhancement layers. The accumulation of more layers generally leads to an improvement of the video quality. This is because the granularity of quality control extends both horizontally over time and vertically over layers in SVC-DASH [15].

Many studies have focused on the design and the performance evaluation of video streaming over HTTP and using AVC - streaming over a single persistent connection. These studies considered different configurations of video encoding such as AVC and Scalable Video Coding (SVC) standards [10, 16, 17]. Others considered different connection configurations such as persistent versus non-persistent [18], single versus multiple connections, and streaming mode (real-time versus stored) and various segment durations [19].

SVC based streaming over HTTP has several merits| that help avoiding the limitation of the BW of the transmission medium as well as increasing the transmitted video quality. In[5], it is shown that SVC-DASH has several advantages including the possibility of serving a larger number of users with different equipment capabilities and a higher caching efficiency. In[12], SVC-DASH not only needs less buffering requirements in comparison to AVC-DASH but it also improves the Quality of Experience (QoE) for the viewer. In[10], the authors compare the performance of different AVC-based and SVC-based heuristics using NS3 simulations with NS3 cradle. The authors show that AVC performs better under high latencies while SVC better adapts to sudden and temporary BW fluctuations. In[20], the authors analytically investigate the optimal selection policy for layer segment when SVC is used. Their simulations show that a vertical policy is optimal under fixed BW while a diagonal selection policy is optimal for variable rate. In[19], the authors considers a cursor based SVC client heuristic Live TV setting where client side buffers is limited. The authors also exploit parallel and pipelined downloading of segment layers to overcome the high end-to-end delay issues. In another study[21], the authors present a rate adaptive algorithm for AVC-based video streaming over two parallel connections. Their simulations show that parallel connections outperforms the serial segment fetching method in achievable media bit-rates but slightly inferior in buffer underflow frequency. In most of the previously discussed work, high speed video streaming is the most important target. However, getting high speed video streaming is still an issue.

In this paper, we are targeting a high speed video streaming transmission. A novel SVC-DASH client over Multiple parallel connections (SVC-DASH-M) system is implemented and evaluated. In SVC-DASH-M, the quality of the requested layer-segment depends on the amount of buffered media and the network condition. Additionally, it adopts two selection policies that are conservative for the frequency of the video quality shifts.

The paper is organized as follows, in section 2, SVC-DASH-M system is discussed in details. Implementation and performance evaluation is discussed in section 3. A conclusion will be drawn in section 4.

2. SVC-DASH-M SYSTEM

The top level structure of the proposed SVC-DASH-M system is shown in Figure 1.The raw video data is subdivided into short duration chunks, commonly known as segments by the JSVM encoder according to the requirements of the HTTP streaming[22]. Every video segment is split into multiple layers per segment depending on the required video quality level, image size, and frame rate. The contents of each layer segment are stored as a separate file on the HTTP server. The details of the video information are typically stored in a media presentation description (MPD) file that includes web links to the media files with the corresponding encoding details of each file contents [1].The MPD file contains some information such as segment ID, layer ID, layer-segment URL, layer-segment duration, and layer size. It is worth mentioning that the segment ID can be used to identify the timing information of the transmitted segment. In HTTP streaming, the content is requested using HTTP GET request/response dialog that is typically serviced over TCP. Once the DASH client requests a specific video, the streaming process starts by downloading the MPD file through the HTTP streaming client. The MPD parser is parsing the MPD file to obtain the video information.

Once the MPD information is received, our multiple-connection client requests the first [n.sub.min] base layer-segments via the segment requester, where [n.sub.min] represents the minimum number of connections. Upon the reception of a complete layer-segment on connectionc, SVC-DASH-M considers a level-based layer-segment requester that determines the quality of the requested layer-segment.After the reception of a segment with the available layers, it can be decoded and viewed. The proposed DASH client algorithm and its advantages are summarized in the following paragraph.

DASH client algorithm defines two application buffer-level thresholds denoted as [B.sub.min] and [B.sub.target] [B.sub.min] represents a low threshold for the data to be maintained in the buffer to avoid streaming interruptions while [B.sub.target] represents a target buffer level that the application should be operating around. Improving the streaming quality at high buffer levels through downloading enhancement (successive) layers is the main advantage of our DASH client algorithm. Additionally, in case of streaming interruptions, our algorithm maintains the user experience quality at low buffer-level by focusing on the base layer-segments. The dynamics of the used connections are considered as an additional critical design advantage of the proposed SVC-DASH-M. In our algorithm, the number of opened connections, denoted as [n.sub.c], is lower-bounded by [n.sup.min.sub.c] and upper-bounded by [n.sup.max.sub.c]. The number of used connections varies depending on the streaming performance of connection c over which the segment is received. In the following subsection, the detailed components of SVC-DASH-M system are discussed in more details.

A. HTTP DASH Server

HTTP DASH server contains the MPD file and the layer segment files for each video. The layer segment files are generated as follows (Please see Figure 1):

1.The original YUV video file is sliced into smaller YUV video segments using The JSVM BitStream Extractor library [22].

2.Each small video segment is encoded using JSVM encoder, which generates the encoded H.264 segment files for each video.

3.Each H.264 segment file is processed to extract the bytes corresponding to each layer as shown in Figure 2. This extraction is performed using a C code; developed for this purpose as none of the existing tools provide this function.

The layer segment frames extraction process, shown in Figure 2, is summarized as follows. Given the H.264 segment file (Seg_file), and the Layer_info.txt layer file, the start position, the end position, and the size of each frame constituting a layer of a certain segment is fetched from the Layer_info.txt layer file. The layer frame bytes will be then fetched from the segment file (seg_file). Number of bytes should equal to the frame size. The data will be then written into the H.264 layer file. The process will be repeated until the bytes of each frame constructing certain layer are moved to the H.264 layer segment file. This process is performed for each frame constituting a segment layer.

The MPD file is prepared, as seen in Figure 3, as follows. The JSVM BitStream Extractor compiles the H.264 segment file and produces the segment trace file. The segment trace file has the start position, size, scalability levels of each Network Abstraction Layer Unit(NALU), the packet type (stream header or slice data), and the packet importance (Discardable or Truncatable). The frame is consisted from multiple NALU.Using the AWK programming language, the frames constituting complete layer is extracted and their related information is written in a separate .txt file. The bit-rate of each layer is also extracted using the JSVM BitStream Extractor that calculates the accumulative bit-rate of each video quality layer. The segment ID, Layer ID, Layer size in bytes, segment duration in seconds, the URL of each layer, and the layer bit-rate is written to the MPD file to provide the streaming client with important information required for each segment layer and its associated file. All the segment layer files together with the MPD file are stored on the HTTP server.

B. Dash Client

Typically, the first step performed by an HTTP streaming client is to download the MPD file and parse it to obtain the video information. Once the MPD information is received, SVC-DASH-M initiates the operation based on three interacting rules. First, the Layer-Segment Requester that determines whether a base layer or an enhancement layer to be downloaded. The Connection Manager Design and the Enhancement Layer Selection policy are the remaining two rules. Table I illustrates the main functions implemented in the client algorithm. Followings are some detailed description of each function.

i. Layer-Segment Requester

The layer-segment requester initially gets the first [n.sub.min] base layer-segments, where [n.sup.min.sub.c] represents the minimum number of connections. Upon the reception of a complete layer-segment on connection c, SVC-DASH-M considers a level-based layer-segment requester that determines the quality of the requested layer-segment as shown in Algorithm1.
Algorithm 1: Level-based Layer-Segment Requester
Algorithm

bl = getBuffLevel(); //buffer level
if bl<= [B.sub.min]
//request base layer only
reqLaySeg(B,conn);
elseif [B.sub.min]<bl<= [B.sub.target]
//alternate base and enhancement requests
reqLaySeg(A,conn);
else
//request enhancement layers only
reqLaySeg(E,conn);
end if


The details of getBuffL(), and reqLaySeg() functions are shown in table I. The algorithm defines two application buffer-level thresholds denoted as Bmin and Btarget. [B.sub.min] represents a low threshold for the data to be maintained in the buffer to accommodate network condition variations. [B.sub.target] represents a target buffer level that the application should be operating around. The defined policy in Algorithm 1 targeting improving the streaming quality at high buffer levels through downloading enhancement layers. Additionally, the layer-segment requester policy maintains the user experience quality at low buffer-level through avoiding streaming interruptions by focusing on the base layer segments.

ii. Connection Manager Design

The connection manager controls the dynamics of the used connections in SVC-DASH-M. In the implemented algorithm, the number of opened connections, denoted as [n.sub.c], is lower bounded by [n.sup.min.sub.c] and upper-bounded by [n.sup.max.sub.c]. The number of the used connections varies when a layer-segment is received. Let c denotes the connection over which the layer-segment is received. The connection manager operation is shown in Algorithm 2. The details of the used functions are presented in table I. The streaming performance is evaluated based on the segment duration-fetch ratio [mu] = SD/SFT, where SD represents the duration of the received segment and SFT represents the duration over which the segment is fetched. Note that large values of [mu] indicate that the available BW is large and vice verse. This is because a new layer-segment is requested over. An additional segment may be requested over a new connection if [n.sub.c] < [n.sup.max.sub.c] and there exists sufficient BW for downloading two segments. The BW sufficiency condition is satisfied if the ratio between the required BW for downloading the two selected layer-segments (denoted as [r.sub.nxt]) to the estimated connection BW (denoted as [r.sub.prev]) is less than the segment duration-fetch ratio. To this end, it is worth noting that all the decision parameters are available or are readily measured at the application layer and do not incur any additional overhead to the communication process.
Algorithm 2: Connection Management Algorithm
[mu] = SD/SFT

[r.sub.nxt] = estimateNextRate(lsType);
&epsi; =([r.sub.nxt] / [r.sub.prev]) ;
if [micro] >1+ &epsi;
reqNextLaySeg(lsType, conn);
if ([n.sub.c] < [n.sup.max.sub.c])
reqNextLaySeg(lsType, -1);
end if
else if [mu] <1
if [n.sub.c] < [n.sup.min.sub.c]
close(conn);
else
reqNextLaySeg(lsType, conn);
end if
else
reqNextLaySeg(lsType, conn);
end if


C. Enhancement Layer Selection policy

The granularity of the quality control extends both horizontally over time and vertically over layers. The enhancement layer selection policy improves the current segment quality in conjunction with keeping consistent quality level for future segments, so that a balance between the current segment quality and the quality of the future segments has to be guaranteed. It should be ensured that any selected layer-segment is expected to be received before its play out time. Additionally, the requested quality level of the segment should be brought to the buffer before the play out time of this segment, otherwise, the download of the enhancement layer of this segment will be no use and the segment is displayed with the enhancement layers that already existed in the buffer or as a base layer if none of its quality levels is downloaded.

i. Vertical Policy

The vertical enhancement layer selection policy concerns the quality of the current segment and doesn't consider the next segment quality. The streaming client downloads all the enhancement layers of the current segment then the next segment and so on. As shown from Figure 4, for the vertical layer selection policy, all enhancement layer-segments are downloaded for segment i before downloading enhancement layer-segments for segment i+1, which is greedy in nature from the future segments perspective. As the vertical policy cares about the current segment quality, in order to keep the same quality for the future segments buffer starvation may occur. If the client wants to avoid the buffer under-run, quality variation is happened that may be annoyed.

ii. Horizontal Policy

The horizontal layer selection policy minimizes the quality variations among the segments, the streaming client downloads certain enhancement layer for all the segments already in the buffer, then move to downloading higher quality level and so on. As shown from Figure 5 that the horizontal layer selection policy ensures that no layer-segment from layer n is requested unless all the layer-segments of layer n-1 have been already downloaded. This policy prevents requesting higher quality-layer segments if there is not enough BW, it aims to reduce the quality shifts in the received video.

D. Streaming Algorithm Implementation

The proposed streaming client algorithm starts by receiving a URL for the Media Presentation Description file (MPD). The client then initializes the streaming process by:

a) Requesting the MPD from the HTTP server.

b) Parsing the received file to extract the information about the video including segment Id, layer Id, size of layer in bytes, segment duration, available quality per segment, URL, and layer bitrate in Kb/s.

c) Storing these information in an array of structures, each element of that array has these information in addition to the playout time of each segment in the video.

d) Request a number of segments equals to minimum number of segments or the minimum number of the connections.

The client then starts a loop in which it downloads segments and delivers them to the application buffer until the stopping is satisfied. The stopping condition in our case is the playout of the last segment after which the download of any additional segment layer would be of no benefit. In this segment, the client continuously receive from the open sockets and update the buffer level. the next step is to update the buffer level by the difference duration of the delivered segments and the played duration. The played duration is estimated as the difference between the current time and the sum of both the play out start time and the accumulated interruption delay due to buffer under-run if any.

Executing the HTTP streaming algorithm. The algorithm defines different operating modes depending on the current buffer level and the network condition. The network condition depends on two parameters. The first parameter is the network indicator ratio [mu] = SD/SFT, where SD represents the duration of the received segment and SFT represents the duration over which that segment is fetched. Large values of [micro] indicate that the available BW is large and vice versa. The second parameter is the application demand ratio [&e.sub.psi] = [r.sub.next] - [r.sub.prev] x [r.sub.cur], where [r.sub.next represents the rate of the next two segments to be requested and [r.sub.prev] represents rate of the received segment. Large values indicate that changing requesting additional segment would require large additional BW. The network is considered in a good condition if [micro] >1+ [&e.sub.psi], and the network is considered in a bad condition if [micro] <1.

Two buffer levels are defined including MIN, and TARGET levels. The MIN level represents the initial playout latency that is typically maintained in streaming applications to accommodate the impact of variations in link conditions. The TARGET buffer level represents a target buffer level that the application should be operating around in order to focus on improving the quality of the video. The choice of these levels would be investigated during the testing phase. Upon the reception of a complete segment, the client estimates the network condition and checks the buffer level and enters one of the operating modes accordingly as described below:

i. Upon the reception of a segment, the application do the following :

- If the segment is out of order, it is delivered to an ordered segment waiting list.

- If the segment is received in order, it is delivered to the application buffer and the buffer level is updated. Additionally, the waiting segments are checked for other possible deliveries.

ii. Then, the network indicator ratio is calculated.

- If the buffer level is below MIN, the application demand factor is estimated for the next two base layer segments.

- If the network is good, an additional connection is opened and one base layer is requested on each of the available two connections (the one that is just opened and the one on which the last segment is received). If a new connection cannot be opened (the current number of connections equals the per-defined maximum number of connections), a base layer is requested on the current connection.

- If the network is bad, close the current connection if the opened connections is more than the minimum number of connections. otherwise request the next base layer segment on this connection.

- If the network conditions is neither good nor bad, a new base layer segment is requested on an empty connection.

iii. If the buffer level is above the MIN level and below the TARGET level, the application demand factor is estimated for the next base layer segment and the next enhancement segment. The order of the enhancement segments is determined based on a per-defined policy. For example, the policy may be a horizontal policy such that segments belonging to layer n will not be requested until all lower layer segments are downloaded.

- If the network is good, an additional connection is opened and the next base and enhancement layers are requested on the available connections. If a new connection cannot be opened, a base layer segment is requested if the number of active connection downloading a base layer segment is less than or equal the maximum number of connections. Otherwise, an enhancement layer segment is requested.

- If the network is bad, close the current connection if the opened connections is more than the minimum number of connections. otherwise request the next base layer segment on this connection.

- If the network is neither good nor bad, a new base layer segment is requested on an empty connection.

iv. If the buffer level is above the TARGET level, the application demand factor is estimated for the next two enhancement segments.

- If the network is good, an additional connection is opened and the next base and enhancement layers are requested on the available connections. (if there are no base layer for any segment to be downloaded so the two enhancement layers will be requested).

- If the network is bad, close the current connection if the opened connections are more than the minimum number of connections. otherwise request the next enhancement layer segment on this connection.

If the network is neither good nor bad, a new enhancement layer segment is requested on an empty connection.

3. IMPLEMENTATION AND PERFORMANCE

EVALUATION

A. System Setup

A real testbed network composed of a server, a transmission media, and a client are implemented and emulated to test the proposed algorithm, as seen in Figure 6.

i. The streaming DASH Server

The DASH server is a typical laptop with Ubuntu 12.04 LTS and Apache[23]as a standard HTTP server. In our evaluation, the YUV videos used for testing are obtained from Arizona State University video library[24], table II shows the details of the used YUV videos in our testing.

Each video is processed using the Joint Scalable Video Model (JSVM) [22]as following :

1. The original YUV video file is sliced into smaller YUVvideo segments using JSVM down-sampler. The duration of the segment is a design parameter that is selectedas 2 sec.

2. Each segment is encoded to ten scalable layers including spatial (original CIF and a down-sampled QCIF), temporal and quality scalability.

3. The encoder produces one H.264 file per segment. An additional code was developed to extract the different portions corresponding to different layers in each segment using the layer information obtained from JSVM bit-stream-extractor.

The corresponding MPD file is then compiled based on the extracted layer-segment information. Finally, the MPD file together with the layer segment files are uploaded to our HTTP DASH server.

ii. The emulated network

Traffic control tools are employed to emulate different BW and delay values. Netem is used to set the delay. Token bucket filter (tbf) is used to set the link BW to the values of interest. For the proper setup of tbf, we set: limit >> BW * HZ and buffer (burst) = BW/HZ, whereBWrepresents the emulated BW and HZrepre ents theLinux kernel timer interrupt frequency. It is worth mentioning that one may need to reset scatter-gather, TCP-segmentation-offload, generic-segmentation-offload, and generic-receive-offload using ethtoolto avoid packet dropping.

iii. The client

The client is a laptop with linux OS (Ubuntu, 12.04 LTS). Our client is implemented using C programming language to connect and fetch the MPD file and video layer-segments according to the presented algorithm. The implemented C code takes the URL of the MPD file, the minimum, and the maximum number of connections ([n.sub.min], [n.sub.cmax]) as inputs. Table III and table IV illustrate the parameters of our client buffer, where the minimum buffer level represents the play-out latency that is typically maintained to accommodate the impact of variations in link conditions. The application should be operating around the target buffer level to focus on improving the video quality. The application has two operating modes. The streaming client enters the first mode in two cases:

- At the start of the playout, the application has to download a number of segments equals the minimum buffer level.

- If the buffer level is depleted (reached zero seconds) during the streaming, the application re-enters a buffering mode until it secures a six second portion in the buffer again.

The second mode is defined as the streaming mode. During such mode, the client is streaming the downloaded media without any interruptions even if the buffer level is below the minimum. Wireshark is used to trace the transmitted packets to estimate some performance metrics. Then the received video layer segments are decoded and the PSNR is calculated. Note that the average quality is estimated over all received segments. These performance parameters are evaluated for different link and delay configurations.

B. Simulation Results

We investigate the impact of both the horizontal and diagonal enhancement layer selection policies on our SVC-DASH-M streaming client when our client using the whole BW, and under real environment when there is cross traffics with the DASH client. The evaluation of the received video is done based on the video quality and the PSNR. The video quality is measured as the number of layers achieved. Experiments are done under several network conditions for different connection configurations when the video is streamed.

i. Emulation with no crosstraffic

Figure 7 plots the average received quality for the streamed Paris video versus different BW configurations for different min-max connection configurations at l0ms link delay. The results represent the average quality for all video segments over five runs. Intuitively, increasing the BW improves the quality of the received video for all connection configurations. Additionally, it is clear from Figure 7 that a single connection represents a good choice for the tested link configurations especially at low BW values. We also noticed that in case of using a large maximum number of connections, the algorithm closes many connections as their segment fetch time is larger than their segment duration especially at low BW. This observation implies that opening too many connections may not be useful as they incur additional overhead without other gains.

Figure 8 shows the achieved quality for each segment considering different connection configurations for an average link delay of 10 ms and BW of 8 Mbps. The figure provides us with some insights on the quality dynamics versus time. The figure shows that all the connection configurations managed to download the highest quality towards the video session end. However, the main difference lies in the starting dynamics. At the beginning of the streaming, the adopted conservative approach for layer segment request implies requesting base layer segments only and limits the benefit from the available BW to download enhancement layer segments. Note that this conservative approach helps reducing the initial playout latency, which is another important QoS metric.

Table V shows some of the several KPIs for different link BWs with a 10 ms link delay. As a general observation, the connection configuration has limited impact on all the estimated KPIs except for [n.sub.c]and [n.sub.cc]. For any configuration, the algorithm opens more connections as the upper-bound [n.sup.max] increases. It is shown from Table V(a) that approximately 12 connections out of 19 opened connection for (2,32) configuration are closed. It is also shown that increasing the value of [n.sup.max]above a certain limit does not have any effect on improving the performance, and this limit depends on the link parameters.

Our results indicate that under all the tested configurations, the algorithm manages to adapt the streaming to different BWs and no interrupts are encountered. Also, as the link BW increases, the application throughput increases as shown in Figure 9. This increase is due to the ability to download more enhancement layer-segments and the typical drop of the download time ([t.sub.d]). Consequently, a higher average quality is observed as the BW increases. It is also shown from Figure 9 that all the connection configurations achieve approximate throughput under the same network BW. It is worth mentioning that such download dynamics affects the decisions of closing and opening new connections and hence, using larger number of connections may limit the benefit of persistent connections. On the contrary, using a smaller number of connections reduces the need of simultaneous connections opening and also avoiding splitting of the BW, as a result, the segment download time is relatively small.

ii. Emulation with crosstraffic

In order to emulate the real environment, some cross traffic is intentionally added as shown in Figure10. The iperf tool is used to make a Constant Bit Rate (CBR) UDP traffic while the streaming client is running. As the iperf client is the data source and the iperf server is the data sink, consequently, the DASH streaming client device is set to be iperf server also. Additionally, the DASH server is acting as the iperf client in order to have another traffic during the streaming route. Two scenarios are simulated. First, when the cross traffic is starting after the DASH streaming client by 6 seconds (i.e., the play out latency period), and lasts for 10 seconds. This experiment is tested when the cross traffic BW is equal to the settled BW as indicated from Figure 11.a, and when the cross traffic BW is greater than the established BW as shown in Figure 11.b. The second scenario, as shown in Figure12, is done when the cross traffic is existed during the streaming period. This experiment is done for the cross traffic BW equals 50% of the settled BW, and for the cross traffic BW equals 90% of the settled BW. Both the two scenarios are tested for the Paris video using the horizontal and diagonal enhancement layers election policies.

Figure 13 shows the achieved quality for each segment considering different connection configurations for an average link delay of 10ms, a BW of 2Mbps, and a CBR UDP cross traffic of 2Mbps using the horizontal layers election policy. It is shown that the streaming client implementing the algorithm is free of interruptions for all connection configurations. It is also indicated that as the maximum number of connections increase morethan2, the achievable quality for the first segments is low compared to the cases of the (1,1) and (2,2) connection configurations, this is because of the division of the BW among the opened connections. The segment quality suddenly drops to the first for the single connection, which means that the multiple connections are resistant to the cross traffic when comparing with the single connection case. After the end of the cross traffic, most of the connection configuration can achieve the maximum quality except the cases of (2,32), and (2,64), this is due to the fact that when the number of connections increases, each connection takes a small portion of the BW.

Figure 14 illustrates the achieved quality for each segment considering different connection configurations for an average link delay of 10ms, a BW of 2Mbps, and a UDP traffic with rate 4Mbps. It is clear from Figure 14 that as the maximum number of connections increases, the interruptions disappeared. The algorithm is interruption free for the maximum number connections above2, and all the segments are displayed between quality levels 3 and 4 during the cross traffic period. This indicates that as the number of parallel working connections increase, this gives more immunity to the cross traffic. It is also demonstrated that the single connection records a 5 second interruption after the download of segment 11. This is because when there is only one opened connection and the network conditions deteriorate suddenly. Consequently, this breaking down has a great negative effect on the only one opened connection. And also for the (2,2) connection configurations, there is interruption lasts for 3 second after the download of the 12th segment. While for the multiple connection case, the network variations is divided among the opened connections. For illustration, figure shows the average video quality when the cross traffic BW starts after 6 sec from the streaming, one time at the cross traffic BW equals the settled BW, and the other at the cross traffic BW doubles the settled BW.

Figure 15 shows the average video quality at the cross traffic BW equals 50%, and 90% of the settled BW for an average link delay of 10ms, a BW of 2 Mbps for different connection configurations. Figure 15 shows that as the cross traffic BW increases, the average quality decreases. The algorithm is interruption free for the different tested connection configurations. It is noticed that the average quality increases as the maximum number of connections increases then saturates.

Figure 16 shows the achieved quality for each segment considering different connection configurations for an average link delay of 10ms, a BW of 2Mbps, and a CBR UDP cross traffic of 2 Mbps using the diagonal enhancement layer selection policy with slope=1. In comparison with the horizontal policy, the figure shows that the achieved segment quality is higher for all connection configurations, and the sudden quality shifts are reduced for the single connection case which reduce the user's disturbance as the quality of the video segments are smoothly changing. After the cross traffic removal after the 16th second from the start of streaming, all the connection configurations succeed in reaching the maximum quality.

Figure 17 shows the achieved quality for each segment considering different connection configurations for an average link delay of 10ms, a BW of 2Mbps, and a CBR UDP cross traffic with rate4 Mbps. The results show that interruptions occurred for the single connection, (2,2), and (2,4) as the diagonal policy concerns improving the quality for the current and future segments. For example, for the (2,2) connection configuration, the download of the enhancement layers for segments 10, and 11 is the cause for the buffer under run for 5 seconds. When the maximum number of connections increases more than 4, no interruptions occurred.

Three different videos are encoded into 12 scalable layers from Base layer to layer 11, and tested using our DASH client, the average of each video sequence is calculated. Then, using Open SVC Decoder for decoding and JSVM PSNR library for PSNR calculation. Table VI provides some information about the tested video sequences. Figure 17 plots the average video quality for different video sequences using different connection configurations for a BW of 2 Mbps, and an average link delay of 10ms. The network BW is chosen to be more than the bitrate of any tested video. The average quality for high way is the highest as it has less information, also its bitrate is less than the BW. As a result, the video average quality is flat for the different tested connection configurations. The Paris average quality is the least as it has more information compared to the other tested videos, as noticed that its bitrate is near than the network BW. This leads to that none of the connection configurations reached the maximum quality. The figure also indicates that the (1,1) connection configuration is better.

In order to study the relation between the quality and the PSNR. Figure 18 plots the average PSNR versus different videos considering different connection configurations for a BW of 2Mbps, and an average link delay of 10ms. The results confirmed the quality ones. The results show that the BigBuckBunny video has the highest PSNR, then Highway, and after that Paris.

We investigate the impact of both the horizontal and diagonal enhancement layer selection policies on our SVC-DASH-M streaming client when our client using the whole BW, and under real environment when there is cross traffics with the DASH client. The evaluation of the received video is done based on the video quality and the PSNR. The video quality is measured as the number of layers achieved. Experiments are done under several network conditions for different connection configurations when the video is streamed. Table VII provides a performance and implementation comparison between our SVC-DASH-M implemented system and the systems implemented in [25, 26]. It is worth mentioning that the proposed SVC-DASH-M algorithm is faster that than the systems in [25, 26] since a parallel segment fetching method is used. This is very important not to have any delay in the transmitted streaming video sequences. Additionally, the proposed SVC-DASH-M algorithm is implemented on a real testbed compared to the systems proposed on [25, 26]. It is worth mentioning that the proposed SVC-DASH-M system is evaluated using many parameters that accurately evaluate our system and measure its performance compared to those in [25, 26].

4. CONCLUSION AND FUTURE WORK

An adaptive SVC-DASH-M system was implemented using a real testbed over dynamic multiple connections. Improving the streaming quality at high buffer levels through downloading enhancement (successive) layers is the main advantage of our DASH client algorithm. Additionally, in case of streaming interruptions, our algorithm maintains the user experience quality at low buffer-level by focusing on the base layer segments. The dynamics of the used connections are considered as an additional critical design advantage of the proposed SVC-DASH-M. The proposed algorithm is experimentally tested under different connection and link configurations. Our results show that the algorithm successfully achieves interruption free streaming under all the tested BandWidth and link configurations. Additionally, the usage of multiple connections results in noticeable improvements in the achieved streaming quality for large link delays.

ACKNOWLEDGMENT

The authors acknowledge the support of Zewail City of Science and Technology--Cairo--Egypt and Southern University and A&M College - Baton Rouge - USA for their support to finalize this work.

REFERENCES

[1] T. Stockhammer, "Dynamic adaptive streaming over HTTP--:standards and design principles," MMSys '11 Proceedings of the second annual ACM conference on Multimedia systems pp. 133-144, San Jose - CA, USA, 2011.

[2] J.-M. Liang, J.-J. Chen, P.-C. Hsieh, and Y.-C. Tseng, "Two-Phase Multicast DRX Scheduling for 3GPP LTE-Advanced Networks," IEEE Transactions on Mobile Computing, vol. 15, pp. 1839-1849, 2016.

[3] M. Seufert, S. Egger, M. Slanina, T. Zinner, T. Hobfeld, and P. Tran-Gia, "A survey on quality of experience of HTTP adaptive streaming," IEEE Communications Surveys & Tutorials, vol. 17, pp. 469-492, 2015.

[4] Z. Yan, J. Xue, and C. W. Chen, "Prius: Hybrid Edge Cloud and Client Adaptation for HTTP Adaptive Streaming in Cellular Networks," IEEE transactions on circuits and systems for video technology, vol. 27, pp. 209-222, 2017.

[5] Y. Sanchez de la Fuente, T. Schierl, C. Hellge, T. Wiegand, D. Hong, D. De Vleeschauwer, W. Van Leekwijck, and Y. Le Louedec, "iDASH: improved dynamic adaptive streaming over HTTP using scalable video coding," Proceedings of the second annual ACM conference on Multimedia systems, pp. 257-264, 2011.

[6] F.-Y. Shih, C.-L. Fan, P.-C. Wang, and C.-H. Hsu, "A Scalable Video Conferencing System Using Cached Facial Expressions," International Conference on Multimedia Modeling, pp. 37-49, 2017.

[7] D. Gao, H. Lin, Y. Liu, and A. Jiang, "Minimizing End-to-End Delay Routing Protocol for Rechargeable Wireless Sensor Networks," Adhoc & Sensor Wireless Networks, vol. 34, 2016.

[8] A. Golechha, S. Karanje, and J. Abraham, "Comparative study of multicasting protocols based on average end-to-end delay," International Conference on Computing, Analytics and Security Trends (CAST), pp. 58-61, 2016.

[9] C.-H. Wang and T. Javidi, "Adaptive Policies for Scheduling With Reconfiguration Delay: An End-to-End Solution for All-Optical Data Centers," IEEE/ACM Transactions on Networking, 2017.

[10] J. Famaey, "On the merits of SVC-based HTTP Adaptive Streaming," IFIP/IEEE International Symposium on Integrated Network Management (IM 2013), pp. 419-426, Ghent, 2013

[11] A. N. Park and W. Wei, "Adaptive streaming for digital content distribution," ed: Google Patents, 2017.

[12] S. Ibrahim, A. H. Zahran, and M. H. Ismail, "SVC-DASH-M: Scalable video coding dynamic adaptive streaming over HTTP using multiple connections," 2014 21st International Conference on Telecommunications (ICT), pp. 400-404, 2014.

[13] H. Schwarz, D. Marpe, and T. Wiegand, "Overview of the scalable video coding extension of the H. 264/AVC standard," IEEE transactions on circuits and systems for video technology, vol. 17, pp. 1103-1120, 2007.

[14] R. Deng and G. Liu, "QoE driven cross-layer scheme for DASH-based scalable video transmission over LTE," Multimedia Tools and Applications, pp. 1-25, 2017.

[15] Z. Ye, F. De Pellegrini, R. El-Azouzi, L. Maggi, and T. Jimenez, "Quality-Aware DASH Video Caching Schemes at Mobile Edge," 2017 29th International Teletraffic Congress (ITC 29), vol. 1, pp. 205-213, 2017.

[16] M. Zhao, X. Gong, J. Liang, W. Wang, X. Que, Y. Guo, and S. Cheng, "QoE-driven optimization for cloud-assisted DASH-based scalable interactive multiview video streaming over wireless network," Signal Processing: Image Communication, vol. 57, pp. 157-172, 2017.

[17] X. Qiu, H. Liu, D. Li, S. Zhang, D. Ghosal, and B. Mukherjee, "Optimizing http-based adaptive video streaming for wireless access networks," 2010 3rd IEEE International Conference on Broadband Network and Multimedia Technology (IC-BNMT), pp. 838-845, 2010.

[18] S. Lederer, C. Muller, and C. Timmerer, "Dynamic adaptive streaming over HTTP dataset," Proceedings of the 3rd Multimedia Systems Conference, pp. 89-94, 2012.

[19] N. Bouten, S. Latre, J. Famaey, F. De Turck, and W. Van Leekwijck, "Minimizing the impact of delay on live SVC-based HTTP adaptive streaming services," 2013 IFIP/IEEE International Symposium on Integrated Network Management (IM 2013), pp. 1399-1404, 2013.

[20] T. Andelin, V. Chetty, D. Harbaugh, S. Warnick, and D. Zappala, "Quality selection for dynamic adaptive streaming over HTTP with scalable video coding," Proceedings of the 3rd Multimedia Systems Conference, pp. 149-154, 2012.

[21] C. Liu, I. Bouazizi, M. M. Hannuksela, and M. Gabbouj, "Rate adaptation for dynamic adaptive streaming over HTTP in content distribution network," Signal Processing: Image Communication, vol. 27, pp. 288-311, 2012.

[22] "JSVM BitStream Extractor library," Retrieved from http://ube.ege.edu.tr/~boztok/JSVM/SoftwareManual.pdf, Dec. 19, 2017.

[23] "Ubuntu 12.04 LTS "Retrieved from http://releases.ubuntu.com/12.04/, Dec. 19, 2017.

[24] "Arizona State University video library," Retrieved from http://trace.eas.asu.edu/yuv/, Dec. 19, 2017.

[25] C. Liu, I. Bouazizi, and M. Gabbouj, "Rate adaptation for adaptive HTTP streaming," Proceedings of the second annual ACM conference on Multimedia systems, pp. 169-174, 2011.

[26] K. Miller, E. Quacchio, G. Gennari, and A. Wolisz, "Adaptation algorithm for adaptive streaming over HTTP," 2012 19th International Packet Video Workshop (PV), pp. 173-178, 2012.

Samar Ali (1), Yasser Ismail (2) and Ashraf Badawi (1)

(1) The Center for Nanotechnology, Zewail City of Science and Technology, Cairo, Egypt

(2) Electrical Engineering Department, Southern University and A&M College, Baton Rouge, USA

Received 2 Feb. 2018, Revised 7 May 2018, Accepted 14 Jun. 2018, Published 1 July 2018

E-mail:samarali.cairouniv@gmail.com, yasser_ismail@subr.edu, abadawi@zewailcity.edu.eg

Ms. Samar Ali is currently a Teaching Assistant (TA) at Zewail City of Science and Technology - University of Science and Technology - Zewail City - Egypt. She also worked at Nile University, El Gezira High Institute, and Cairo University - Egypt as a TA. She previously worked as a Research Assistant (RA) at Media Streaming Optimization in Heterogeneous Wireless Networks Project in the Faculty of Engineering - Cairo University - Egypt. She received her BSc and MSc in Electrical Engineering from Electronics and Electrical Communication Department - Faculty of Engineering - Cairo University - Egypt in 2011 and 2016 respectively. Ms. Samar's research area of interest includes video streaming protocols and communication systems.

Dr. Yasser Ismail received his B.Sc. degree in Electronics & Communications Engineering from Mansoura University - Egypt, in 1999. He received his M.Sc. in Electrical Communications from Mansoura University - Egypt, in 2002. Dr. Ismail received his M.S. and Ph.D. degrees in Computer Engineering from University of Louisiana at Lafayette - USA in 2007 and 2010 and subsequently joined Umm Al-Qura University - Kingdom of Saudi Arabia as an assistant professor. In Fall 2012, he joined University of Bahrain - Kingdom of Bahrain as a Computer Engineering Assistant Professor. In Fall 2016, Dr. Ismail Joined both Electronics & Communications Engineering Department - Mansoura University - Egypt and Zewail City of Science and Technology - University of Science and Technology - Zewail City - Egypt as an assistant professor. Dr. Ismail is currently working as an assistant professor in the Electrical Engineering Department, Southern University and A&M College - Baton Rouge - Louisiana - USA. His area of expertise is Digital Video Processing Algorithms/Architectures levels, Internet of Things (IoT), VLSI and FPGA Design (Low-Power and High Speed Performance Embedded Systems), automotive transportation, Robotics, RFID, and Wireless and Digital Communication Systems. He has published one book, two book chapters, and more than 35 articles in related journals and conferences. Dr. Ismail served as a reviewer for several conferences and journals, including IEEE ICIP, IEEE GCCCE, IEEE ICECS, IEEE MWSCAS, IEEE ISCAS, IEEE SIPS, IJCDS, Springer, Elsevier, IEEE Transactions on VLSI, IEEE Transaction on Circuit and System for Video Technology (TCSVT), and IEEE Transactions on Image Processing. He severed in the technical committees of IEEE ISCAS 2007, IEEE ICECS 2013,

MobiApps 2016, and IEEE MWSCAS 2018 conferences. He also served in the organizing committee of ICECS2013. He was invited to serve as a lead guest editor for special issue in mobile information systems--Hindawi publishing corporation September 2016. Dr. Ismail has been appointed as a Track Chair in the International IEEE Midwest Symposium on Circuits and Systems (MWSCAS) 2018. Dr. Ismail served as a PI and Co-PI for several funded grants from NSF and other international fund agencies. Additionally, Dr. Ismail served as a member in the Editorial Board Member for Frontiers of Mechatronical Engineering(FME, EnPress Publisher Editorial) - USA, 2018.

Dr. Ashraf Badawiis currently the Dean of Student Affairs at Zewail City of Science and Technology, Egypt. He is also the director for the Center of Learning Technologies. Dr. Badawi's conducts research in Educational Technology, Nanotechnology and Wireless Communications as a senior research scientist. Dr. Badawi was leading a team of research scientists at SMART Technologies exploring areas of research and development that is related to technology for the education and enterprise domains. In particular the current endeavors he is participating in are trying to define technologies to facilitate knowledge focused collaboration, to serve the education and enterprise markets in the fields of knowledge management, summarization, transcription, and student assessment. Prior to joining SMART, Dr. Badawi was the lead WiMAX Solutions Specialists for Intel in the Middle East and Africa where he was the technical lead for the Center of Excellence for Wireless Applications, a joint project between Intel and King Abdul-Aziz City for Science and Technology in Riyadh. Dr. Badawi was the systems architect for emerging market solutions from Intel, he moved back to Egypt in 2005 to be part of the Cairo Platform Definition Center. The team worked on the Classmate PC project that was later deployed to millions of students worldwide. Dr. Badawi graduated from the Systems and Biomedical Engineering Department in 1990 in Cairo, where he started pursuing his MSc in Engineering Physics. He earned his PhD for his work on the numerical analysis for microstrip antennas and high speed printed circuits in 2002. Dr. Badawi did his MBA in Marketing at the AUC, Cairo, graduating in 2009. He has more than 50 Journal, International Conference research papers.

http://dx.doi.org/10.12785/ijcds/070401
TABLE I. Client algorithm functions.

         Function            Meaning

                             Counts the number of segments in the
      GetBuffLevel()         buffer, and returns the buffer level in
                             seconds.
                             Requests a layer-segment from the server
                             over connection conn. IsType could be
  reqLaySeg(lsType, conn)    "B" for base layer, "E" for enhancement
                             layer, or "A" to alternate between base
                             and enhancement layers.
                             Takes the layer segment type, and returns
 estimateNextRate(lsType)    the data rate required for downloading the
                             next two segments to be requested.
                             Given the layer-segment type, this
                             function requests the next layer-segment
                             to be requested over conn. If conn is set
                             to-1, then a new connection is opened to
reqNextLaySeg(lsType, conn)  request the selected layer-segment. Or the
                             conn is set to the number of already
                             opened connection to request a layer
                             segment.

TABLE II. The used YUV video sequences.

  Video     # of     Frame     Duration in    # of
           frames  Rate (fps)    seconds    segments

  Paris     1065       24        44.375        23
Big Bunny   2880       24       120            60
 Highway    2000       24         83.33        42

TABLE III. The segments used for the Buffer Level.

   The Buffer Level      Segments  Seconds

 The Min. Buffer Level      3         6
The Target Buffer Level     5        10

TABLE IV. The used parameters of the used client buffer.

  Index                    Definition

[n.sub.i]   The number of interrupts
[n.sub.c]   The number of opened connections
[n.sub.cc]  The number of closed connections due to the low BW
[n.sub.v]   The application downloaded data in Bytes.
[n.sub.d]   The time at which the application stops downloading more
            layer-segments
 [gamma]    The application goodput that is estimated here as the ratio
            between the total transmitted video layer-segment sizes and
            the time spent in transmitting this amount of data.
    q       The average quality in terms of the number of layers (i.e,
            As the number of layers increase, the average quality
            increases)
   PSNR     Peak-signal-to-noise-Ratio, The PSNR is calculated on the
            frame level by comparing each pixel of every frame in the
            reference video and the received one.

TABLE V. KPIs for different link BandWidths.

                                         (a) 256Kbps BandWidth
([n.sup.min.sub.c],
[n.sup.max.sub.c])             (1,1)  (2,2)   (2,4)    (2,8)  (2,16)

[n.sub.i]                       0.00   0.00    0.00     0.00   0.00
[n.sub.c]                       1.00   3.00   13.80    18.60  17.20
[n.sub.cc]                      0.00   0.00    7.40    11.40  10.80
[d.sub.v](MB)                   1.5    1.3     1.4      1.4    1.3
[t.sub.d](sec)                 37.74  36.81   38.89    41.12  37.89
y(Kbps)                        39.14  35.82   35.74    34.24  35.35
q                               1.81   1.63    1.71    1.77    1.63

                                         (b) 1MbpsBandWidth
([n.sup.min.sub.c],
[n.sup.max.sub.c])              (1,1)  (2,2)   (2,4)    (2,8)   (2,16)

[n.sub.i]                       0.00    0.00    0.00     0.00    0.00
[n.sub.c]                       2.00    3.20   14.40    24.80   40.60
[n.sub.cc]                      0.00    0.00    6.40    11.60   20.20
[d.sub.v](MB)                   5.5     5.1     5.2      4.8     4.66
[t.sub.d](sec)                 37.82   35.01   35.65    32.32   31.09
y(Kbps)                       145.28  145.31  146.33   148.39  149.92
q                               6.19    5.56    5.87     5.37    5.40

                                         (c) 2Mbps BandWidth
([n.sup.min.sub.c],
[n.sup.max.sub.c])             (1,1)   (2,2)   (2,4)   (2,8)   (2,16)

[n.sub.i]                       0.00    0.00    0.00    0.00    0.00
[n.sub.c]                       4.60    3.40   10.80   29.60   50.00
[n.sub.cc]                      0.00    0.00    4.80    9.80   14.20
[d.sub.v](MB)                   6.99    6.58    6.45    6.03    5.85

[t.sub.d](sec)                 33.17   23.44   22.89   21.23   20.50
y(Kbps)                       228.44  280.85  281.75  284.20  285.39
q                               8.03    7.42    7.12    6.85    6.79

                                         (d) 4Mbps BandWidth
([n.sup.min.sub.c],
[n.sup.max.sub.c])             (1,1)   (2,2)   (2,4)   (2,8)   (2,16)

[n.sub.i]                       0.00    0.00    0.00    0.00    0.00
[n.sub.c]                       3.00    4.00    5.40   19.00   60.00
[n.sub.cc]                      0.00    0.00    0.40    4.80   18.20
[d.sub.v](MB)                   7.11    7.11    6.98    6.56    6.41
[t.sub.d](sec)                 12.86   12.84   12.58   11.73   11.43
y(Kbps)                       533.08  533.76  555.15  559.47  560.71
q                               8.52    8.52    8.39    7.72    7.66

                                         (e) 8Mbps BandWidth
([n.sup.min.sub.c],
[n.sup.max.sub.c])             (1,1)  (2,2)   (2,4)    (2,8)  (2,16)

[n.sub.i]                       0.00   0.00    0.00     0.00   0.00
[n.sub.c]                       3.00   4.00    8.40    14.60  52.60
[n.sub.cc]                      0.00   0.00    0.40     1.20   1.00
[d.sub.v](MB)                   7.12   7.12    7.08     6.77   6.77
[t.sub.d](sec)                  6.53   6.54    6.45     6.10   6.17
y(Kbps)                         1.1    1.1     1.1      1.1    1.1
q                               8.61   8.59    8.50     8.17   8.14

                               (a) 256Kbps BandWidth
([n.sup.min.sub.c],
[n.sup.max.sub.c])             (2,32)  (2,64)

[n.sub.i]                       0.00    0.00
[n.sub.c]                      19.40   18.40
[n.sub.cc]                     12.20   11.80
[d.sub.v](MB)                   1.5     1.4
[t.sub.d](sec)                 40.69   40.34
y(Kbps)                        36.35   34.85
q                               1.90    1.78

                               (b) 1MbpsBandWidth
([n.sup.min.sub.c],
[n.sup.max.sub.c])              (2,32)  (2,64)

[n.sub.i]                        0.00    0.00
[n.sub.c]                       45.60   42.00
[n.sub.cc]                      16.20   16.60
[d.sub.v](MB)                    4.72    4.74
[t.sub.d](sec)                  31.50   31.66
y(Kbps)                        149.76  149.64
q                                5.43    5.19

                               (c) 2Mbps BandWidth
([n.sup.min.sub.c],
[n.sup.max.sub.c])             (2,32)   (2,64)

[n.sub.i]                       0.00     0.00
[n.sub.c]                      57.40    56.20
[n.sub.cc]                     16.80    18.80
[d.sub.v](MB)                   5.83     5.73

[t.sub.d](sec)                 20.38    20.01
y(Kbps)                       285.88   289.63
q                              6.77      6.77

                               (d) 4Mbps BandWidth
([n.sup.min.sub.c],
[n.sup.max.sub.c])             (2,32)   (2,64)

[n.sub.i]                       0.00     0.00
[n.sub.c]                      66.80    67.00
[n.sub.cc]                     19.00    21.20
[d.sub.v](MB)                   6.41     6.39
[t.sub.d](sec)                 11.44    11.40
y(Kbps)                       560.44   560.38
q                               7.66     7.67

                               (e) 8Mbps BandWidth
([n.sup.min.sub.c],
[n.sup.max.sub.c])            (2,32)  (2,64)

[n.sub.i]                      0.00    0.00
[n.sub.c]                     58.40   61.20
[n.sub.cc]                     2.80    1.40
[d.sub.v](MB)                  6.72    6.72
[t.sub.d](sec)                 6.12    6.12
y(Kbps)                        1.1     1.1
q                              8.15    8.15

TABLE VI. Information about tested video sequences.

  Video Name    Video size(MB)        Video        Video Bit
                                duration(seconds)  Rate(Mbps)

   Highway            4.03            83.33          0.5
    Paris             7.28            44.375         1.376
Big Buck Bunny       10.2            120             0.713

TABLE VII. Performance and implementation comparison.

Protocol Type  [26]             [25]            SVC-DASH-M
               Application      Application     Application layer
               layer            layer

                                - The           - The received
                                received        number of layers.
Video Quality                   number of       The average is
Measurement    - Bit rate in    layers, The     3.5 at 2Mbps and
in terms of:   Kbit/sec.        average is 8.5  2ms delay at the
               - The PSNR is    at 10MB and     UDP cross traffic
               not calculated.  2 ms delay.     of 4Mbps.
                                - The PSNR      - The PSNR is
                                is not          calculated.
                                calculated.
Adaptation                      Ratio           Current
technique      Client-Buffer    between         Observed BW

based on:      Status           segment         and Client-
                                duration and    Buffer Status
                                its fetch time
                                                Number of
               Buffered media                   interrupts,
The            time, and rate                   Duration of each
performance    adaptation       Buffer          interrupt,
parameters     speed versus     leveland        Number of
               Competitive      throughput.     opened
               Bit Rate                         connections, and
               (CBR).                           Application
segment                                         goodput.
fetching
method         Serial           serial          parallel

               Implementation
               of a platform
Evaluation     independent      Simulation on   Implementation
               library          NS2             using Real
               integrated in a                  Testbed
               DASH client
Algorithm      prototype.
behavior in
presence of    Stable           Stable          Stable
cross traffic
COPYRIGHT 2018 University of Bahrain : Scientific Publishing Center
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2018 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Ali, Samar; Ismail, Yasser; Badawi, Ashraf
Publication:International Journal of Computing and Digital Systems
Article Type:Report
Date:Jul 1, 2018
Words:9357
Previous Article:Docile Smart City Architecture: Moving Toward an Ethical Smart City.
Next Article:User Quality of Experience (QoE) prediction in Heterogeneous Mobile Networks.
Topics:

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters