Skip to main content

Design of new resource allocation scheme for symbiosis of DASH clients and non-DASH clients

Abstract

In this paper, we propose a new resource allocation scheme for symbiosis of DASH clients and non-DASH clients (RASS) to provide seamless video streaming service to DASH clients and to guarantee fairness among non-DASH clients. In RASS, all the LTE downlink resource blocks are divided into two chunks by a KKT-conditions-based Resource-Division Controller (KCRDC). With the two divided chunks, the proposed scheme leads PFRA and KKT-conditions-based resource allocation scheme (KCRA) to allocate each chunk to non-DASH clients and DASH clients, respectively. PFRA allocates resource blocks with maintaining good trade-off between fairness and spectrum efficiency. On the other hand, KCRA allocates more resource blocks to DASH clients in the risk of re-buffering events to preferentially reduce the re-buffering-time ratios of the DASH clients. Finally, simulations are completed using the NS-3 (network simulator). The obtained results show that the proposed scheme shows a better synthetic performance than the existing resource allocation schemes in consideration of the re-buffering-time ratios and QoE value of DASH clients and the fairness among non-DASH clients.

Introduction

Recently, due to the development of the wireless communication network and mobile devices, mobile-data traffic has increased rapidly. According to the Cisco Global Mobile Data Traffic Forecast [1], mobile-data traffic grew 18-fold from 2011 to 2016, while mobile-video traffic accounted for 60% of the total mobile-data traffic in 2016. Moreover, it is expected that mobile-video traffic will increase 9-fold between 2016 and 2021 to account for up to 78% of the total mobile-data traffic. Accordingly, the Hypertext Transfer Protocol (HTTP)-based Dynamic Adaptive Streaming Over HTTP (DASH) is emerging as a new standard for video streaming for the efficient processing of the tremendous mobile-video traffic in mobile networks. DASH [27] is the adaptive-streaming standard that provides seamless video-streaming services to DASH clients in time-varying network conditions. By using the HTTP/TCP protocol, DASH can overcome the firewall problem in contrast to the previously used RTP/UDP. In other words, firewall does not block HTTP packets due to the usage of well-known port number (80) while it might block RTP packets due to the usage of registered port number (5004). It is also cost-effective due to the employment of standard HTTP servers. In DASH, media content is encoded into various versions at different bit-rates and is divided into multiple segments, and these can be played for seconds or tens of seconds. After the division, the segments are stored in the HTTP servers. To obtain the utmost quality of experience (QoE), DASH clients act accordingly by requesting segments that are appropriate under the variable network conditions.

In the Long-Term Evolution (LTE) network, base stations allocate radio resource blocks, i.e., physical resource blocks (PRBs), to the LTE clients to communicate with them simultaneously. One of the well-known resource allocation scheme named as Proportional Fair Resource Allocation (PFRA) [8, 9] maintains good grade-off between the fairness and spectrum efficiency. Also, there are several other resource scheduling schemes such as Maximum Throughput, Blind Equal Throughput, Token Bank Fair Queue, and Priority Set schemes that serve mobile clients with their own mechanism effectively [10]. These schemes, however, are not appropriate to provide high QoE to DASH clients, since they do not consider whether the traffic is video traffic or not. In this context, with the fact that the average video quality, variance of video quality, and re-buffering-time ratio critically affect QoE [11, 12] (here, the re-buffering-time ratio affects the QoE most significantly), Base Station Optimization (BSOP) scheme is proposed in [13]. BSOP is based on the Lagrange dual approach, and it provides optimal resource allocation solutions by considering the DASH-clients’ playback buffer levels to reduce the re-buffering-time ratios of video services. Also, several resource allocation schemes are proposed to provide utmost QoE to multimedia clients [1318]. Like this, plenty of resource allocation schemes have been proposed, but none of these schemes consider DASH clients and non-DASHs simultaneously. In the resource allocation process, it is important to consider DASH and non-DASH clients simultaneously since LTE system eventually receives payment from all clients.

In this paper, we propose a new resource allocation scheme for symbiosis of DASH clients and non-DASH clients (RASS) to provide seamless video streaming service to DASH clients and to guarantee fairness among non-DASH clients. In RASS, all the LTE downlink resource blocks are divided into two chunks by Karush-Kuhn-Tucker (KKT)-conditions [19, 20]-based Resource-Division Controller (KCRDC). One is for PFRA scheme and the other is for KKT-conditions-based resource allocation scheme (KCRA). KCRDC provides optimal solutions by considering the number of DASH clients, the number of non-DASH clients, the sum of the DASH-client buffer levels, and the channel conditions of every client. With the divided chunks, the proposed scheme leads PFRA and the KCRA to allocate each chunk to the non-DASH clients and the DASH clients, respectively. PFRA considers the achievable rates and the past average throughputs of non-DASH clients to maintain a good trade-off between the spectrum efficiency and the fairness. Alternatively, KCRA considers other factors such as the maximum achievable rates, buffer levels, and past average throughputs of the DASH clients, and it solves the optimization problem by using the KKT-conditions to preferentially reduce the re-buffering-time ratios of the DASH clients. As re-buffering events affect the QoE most significantly, it is expected to increase QoE of DASH clients by reducing re-buffering events.

Finally, simulations are completed using the NS-3 network simulator [21]. It is assumed that all the clients are in the edge of the LTE network, i.e., only one base station can serve the clients. This is for the verification that in such harsh network environment, RASS can provide best QoE to DASH clients by reducing re-buffering events and guarantees fairness among non-DASH clients. The role of Client-Side Rate-Adaptation Scheme (CSRAS) is also important. CSRAS is an application level algorithm applied in DASH clients and helps DASH clients to request optimal quality of video segments. Since each CSRAS behaves differently and exhibits different performance, there is a possibility of gap between performances of resource allocation schemes depending on the type of CSRAS. So, in the simulations, various CSRAS are used to show that the proposed scheme operates effectively regardless of the type of CSRAS. The obtained results show that the proposed scheme shows a more effective performance than those of two selected reference schemes (one from the schemes that do not consider video streaming (PFRA) and one from the schemes that consider video streaming (BSOP)) through an overall consideration of the QoE values of the DASH clients and the fairness among the non-DASH clients.

To sum up, the main contributions of this paper are summarized as follows:

  • The proposal of a new resource allocation scheme for symbiosis of DASH clients and non-DASH clients (RASS) that allocates radio resource blocks to DASH clients and non-DASH clients for its purpose. The proposed scheme implements a control process to divide all the available PRBs into two chunks, which are used by PFRA and KCRA, and let PFRA and KCRA allocate PRBs to non-DASH clients and DASH clients, respectively.

  • Various simulations with multiple client side rate adaptation schemes, reference resource allocation schemes, and network environments.

  • The demonstration that the proposed scheme can increase the QoE value of DASH clients by reducing re-buffering events, especially in harsh network conditions.

  • The demonstration that the proposed scheme can guarantee the fairness of using radio resource blocks among non-DASH clients.

This paper is structured as follows. In Section 2, a review of the recent studies that are related to our work is presented. Section 3 outlines design principle and evaluation items, while Section 4 presents the optimization process of the KCRDC which is one of the components of RASS. Section 5 then describes the KCRA, and Section 6 presents the simulation results. Finally, Section 7 concludes this paper.

Related works

Several rate-adaptation and resource allocation schemes have been proposed to handle tremendous video traffic and provide a higher QoE to DASH clients. In Section 2.1, several resource allocation schemes are described. In Section 2.2, several CSRASs are outlined.

Resource allocation schemes

In [22], the authors proposed a scheme that maximizes the throughput and minimizes the delay of real-time traffic to fulfill the QoS criteria. This scheme consists of the following two resource allocation schemes: (1) PFRA scheme and (2) Maximum-Throughput Resource Allocation (MTRA) scheme. Real-time traffic is scheduled by the proportional fair scheduler, whereas non-real-time traffic is scheduled by the maximum throughput scheduler.

The authors of [13] developed a formulation to maximize the QoE with a combined CSRAS–BSOP scheme. The key factors that are considered for client side rate-adaptation scheme are as follows: (1) average video quality, (2) variance of video quality, and (3) start-up delay. Meanwhile, the key factors that are considered in BSOP are the re-buffering-time ratios of DASH clients and the achievable rate of PRBs.

In [16], QoE-based resource allocation for adaptive HTTP video delivery was proposed to enhance the user QoE in multi-user over-the-top (OTT) DASH. This scheme uses information such as buffer levels of streaming users and channel quality of mobile users. With the information, a proxy-based method is used to optimize the video rate that is requested by streaming users.

A bandwidth-efficient multi-path transport layer protocol for high-quality real-time video was proposed in [17]. This transport layer protocol uses priority-aware data scheduling and adaptive forward error correction (FEC) coding algorithm to mitigate the packet loss rate.

In [18], the authors proposed a QoE-driven cross-layer optimization method to provide improve QoE of DASH clients. The proposed method is a proxy-based scheme that eNodeB changes the HTTP Get Request according to the channel condition and other DASH-related information of DASH clients. By using this scheme, DASH clients with good channel conditions and buffer capacity can request enhancement layers of downloaded video segments so that DASH clients can be provided higher QoE.

Client-side rate-adaptation schemes

The agile smooth-video adaptation algorithm (SVAA) [23] uses the buffer occupancy and the buffer trend to select the segment version that is appropriate for the current network condition and the buffer state of the DASH client. Also, SVAA applies a buffer cap to prevent the buffer overflow that occurs when the buffer is already full and receives another data.

In [24], the authors proposed the segment-fetching time method (SFTM) rate-adaptation scheme for the serial and parallel segment-fetching methods in the content distribution network (CDN). The proposed scheme uses the ratio of the expected segment-fetch time and the measured segment-fetch time to detect the network capacity. Also, the scheme uses a stepwise switch-up method and a multistep switch-down method that are based upon the proposed rate-adaptation metric. In addition, an idling method is used to prevent buffer overflows, and the prioritized optimum segment-fetch time is suggested for the newly joined DASH clients to solve the fairness problem among the DASH clients.

Also, the fuzzy-logic-based rate-adaptation scheme (FDASH) presented in [25] adapts the segment bit-rate by using the fuzzy-logic controller (FLC). The FLC uses the following inputs: (1) buffer level and (2) differential of the buffer level. Also, the scheme controls the bit-rate of the next segment by using the throughput-estimation value.

Methods and evaluation items

RASS is designed to reduce probabilities of re-buffering events of multi-media services and to guarantee fair services among non-DASH clients. The design of RASS is shown in Fig. 1. The overall system consists of the client-side architecture and the base-station-side architecture, and the details of the client-side architecture and the base-station-side architecture are represented in Sections 3.1 and 3.2, respectively.

Fig. 1
figure1

System architecture

Client-side architecture

In the client-side architecture, DASH clients receive the media-content segments that are then stored in their Playout Buffers in the received order. The DASH clients then play the accumulated video segments one by one. During the video playback, the information of the buffer levels of the DASH clients is extracted from the Playout Buffers and is included in the HTTP Get Request [26]. The format of the HTTP Get Request used in RASS is described in Fig. 2. The left side of the format is elliptical, which is an original format of the HTTP Get Request and includes the necessary DASH information such as resolution id and segment id. The buffer states of DASH clients are added to the original format with 32-bit size. Then, the HTTP Get Requests are transferred to the base station via the uplink data channel (PUSCH) [27] of the LTE system.

Fig. 2
figure2

HTTP Get Request Format

Base-station-side architecture

The LTE system that is used in the proposed network model uses the Frequency Division Duplexing (FDD) scheme [28]. In the FDD scheme, since uplink and downlink transmission use different frequency bands, clients send and receive packets simultaneously. Also, multiple clients communicate with a base station simultaneously due to resource (sub-channels, power) allocation in every transmission time interval (TTI). At every TTI (i.e., every 1 ms), the clients send Channel Quality Information (CQI) [29] to their base station. By using the CQI, a base station can calculate the achievable rate that a user can achieve with the allocated PRBs, as follows:

$$ R_{\text{achieve}} = \frac{TB \, (bytes)}{1 \,(ms)} $$
(1)

where TB is the size of a transport block that is determined by a Modulation and Coding Scheme (MCS) and the number of allocated PRBs. Additionally, the MCS is determined by the predefined table that informs the selectable MCS based on the given CQI [30]. At the base-station side, the link-layer model that is proposed in [31] is used. In this model, the data rate of the user i is denoted as Ri and the maximum achievable rate that the user i can achieve if all the available PRBs are allocated to the user i is denoted as Rmax,i. The Ri for all of the N users is denoted as:

$$ R_{i} = \alpha_{i} R_{max,i}, \quad 0 \leq \alpha_{i} \leq 1, \, \forall i $$
(2)

where αi denotes the proportion of the total PRBs that the user i can use and this value will be calculated in our proposed scheme. An Rmax,i for each user is updated in each optimization round, i.e., in each TTI, based on its channel condition that is informed by the user. As an expansion of the client-side architecture, the base station receives the HTTP Get Request, and this is followed by the extraction of the information about the buffer level from the HTTP Get Request that is sent to the RASS. The other two control factors, i.e., the achievable bit-rate and the numbers of DASH and non-DASH clients, as well as the buffer levels of the DASH clients, are included in the RASS. The numbers of DASH and non-DASH clients can be achieved by the control message from DASH clients. If a DASH client starts a streaming service, then it sends a control message to its base station through control channel so that the base station can identify this client as a DASH client and increases the number of DASH clients. On the other hand, if a DASH client stops playing streaming service, it sends a control message again so that the base station can erase this client from the DASH client list and decreases the number of DASH clients. After receiving all the information, KCRDC starts a control process using the KKT-Conditions. The details of these factors are described in Section 4. The KCRDC optimally divides the total PRBs into two chunks by using the KKT-conditions. One chunk is for PFRA scheme and the other is for the KCRA scheme. Then, PFRA scheme allocates its resource chunk to the non-DASH clients according to the following equation:

$$ i_{k}(t) = arg \max_{j=1,\ldots,N} \frac{R_{j}(k,t)}{T_{j}(t)}, \quad \forall j, \, t, \, k, $$
(3)

where ik(t) denotes the chosen user for the transmission of the kth PRB at the time t, Rj(k,t) is the achievable rate for the kth PRB at t, and Tj(t) is the past average throughput of the user j. On the other hand, the other PRB chunk is allocated to the DASH clients by the KCRA scheme. The details of the KCRA scheme are described in Section 5.

To sum up, RASS receives (1) numbers of DASH and non-DASH clients, (2) achievable bit-rate of all the clients, (3) playback buffer levels of DASH clients, and (4) downlink PRBs information as input items. Then, KCRDC, KCRA, and PFRA make downlink scheduling information as an output item of RASS.

Evaluation items

The evaluation items that are used to validate the proposed scheme are as follows: (1) average re-buffering-time ratios of the DASH clients; (2) average received data and standard deviation of the received data of the non-DASH clients; and (3) average QoE value of the DASH clients. The following equations are used to calculate (1) and (2):

$$ Reb(i) \, = \, \frac{I_{total,i}}{\ell_{i}}, \quad \forall i, $$
(4)
$$ m \, = \, \frac{1}{N_{non-DASH}} \sum\limits_{i=1}^{N_{non-DASH}}R(i), $$
(5)
$$ Stad \, = \, \sqrt[]{\frac{1}{N_{non-DASH}}\sum\limits_{i=1}^{N_{non-DASH}}(R(i) \, - \, m)^{2}}, $$
(6)

where Reb(i), Itotal,i, and i denote the re-buffering-time ratio of the ith DASH client, the total playback-interruption time of the ith DASH client, and the total video-playback duration, respectively, and m denotes the average received data of the non-DASH clients that are the results of the division operation of the sum of all of the non-DASH clients’ received data [ R(i)] and the number of DASH clients (NnonDASH). Additionally, Stad denotes the standard deviation of the received data of the non-DASH clients that represents the degree of the fairness among the non-DASH clients.

In addition, a QoE model [11, 13, 32] is needed to prove that the QoE of the DASH clients is actually improved by the application of the proposed scheme; the employed QoE model was proposed in [13] for this reason. The following three factors are considered for the QoE model that is used in the present paper: (1) average video quality; (2) variance of video quality; and (3) re-buffering-time ratio. The average video quality and the variance of video quality are represented as:

$$ m_{avq}(i) \, = \, \frac{1}{N_{seg,i}} \sum\limits_{k=1}^{N_{seg,i}} q(\Re_{i}[\!k]), \quad \forall i, $$
(7)
$$ Var(i) \, = \, \frac{1}{N_{seg,i}}\sum\limits_{k=1}^{N_{seg,i}} (q(\Re_{i}[\!k]) \, - \, m_{avq})^{2}, \quad \forall i, $$
(8)
$$ q(\Re_{i}[\!k]) \, = \, \vartheta \log{\Re_{i}[\!k])} \, + \, \iota_{i}, $$
(9)

where mavq(i) is the average video quality of the ith DASH client; Nseg,i is the number of the segments that are received by the ith DASH client; q(Ri[ k]) is the form of video quality that is proposed in [33], which can be controlled by the parameters 𝜗i and ιi for different DASH clients; and Var(i) is the variance of the video quality of the ith DASH client. With (4), (7), and (8), the QoE can be defined as

$$ QoE(i) \, = \, m_{avq}(i) \, - \, \theta Var(i) \, - \, \xi Reb(i), \quad \forall i, $$
(10)

In the simulations of this study, 𝜗i and ιi are set as 10 and 0 for all of the users, respectively. Also, θ and ξ are set as 0.2 and 300, respectively, since the re-buffering-time ratio is more critical to the QoE than the variance of video quality [34].

KKT-conditions-Based Resource-Division Controller

In this section, the description of the KCRDC is given. The control factors for the controlling of the size of two PRB chunks are presented in Section 4.1, and the KCRDC control process is described in Section 4.2.

Control factors of the KCRDC

In the proposed KCRDC, the following three factors for the effective division of the PRBs are considered:

  1. 1.

    The number of DASH clients and the number of non-DASH clients to allocate more PRBs to the group with the higher number of clients.

  2. 2.

    The sum of the maximum achievable bit-rates of the DASH clients and the sum of the maximum achievable bit-rates of the non-DASH clients to consider the effectiveness of the PRB usage.

  3. 3.

    Buffer levels of the DASH clients to allocate a larger number of PRB chunks to the KCRA for any of the DASH clients that are at risk of the re-buffering events.

The objective of this controller is the maximization of the effectiveness function R(α) that is given by

$$ \mathcal{R}(\alpha) \, = \, \sum\limits_{i=1}^{2} \hbar_{i}(t) C(\alpha_{i}), $$
(11)
$$ \hbar_{1}(t) \, = \, \frac{N_{DASH} \sum_{i=1}^{N_{DASH}} \log{(R_{max,i} + a)}}{\sum_{i=1}^{N_{DASH}} e^{\frac{B_{i}[t] + \varepsilon}{B_{max,i}}}}, \quad \forall i, \, t, $$
(12)
$$ \hbar_{2}(t) \, = \, N_{non-DASH} \sum\limits_{i=1}^{N_{non-DASH}} \log{(R_{max,i} + a)}, \quad \forall i, \, t, $$
(13)

where α= [ α1,α2], C(αi)=−(αi−1)2 is a convex function for the optimization, NDASH is the number of DASH clients, NnonDASH is the number of non-DASH clients, Bi[t] is the buffer level of the user i at the time t, Bmax,i is the maximum buffer level that the user i can use, ε is a small constant value, and a is a small positive constant value with an a>1 to ensure that the log(Rmax,i+a)>0. Additionally, \(\hbar _{1} (t)\) is the control function for the DASH clients that represents how much of downlink resource blocks will be taken from DASH clients. If the Bi[t] is decreased, the number of PRBs that are allocated to the KCRA becomes larger to prevent the re-buffering events of the DASH clients. In the same manner, if the \(\sum _{i=1}^{N_{DASH}}\log {(R_{max,i}+a)}\) is increased, the number of PRB chunks that are allocated to the KCRA will become larger, since it is important to consider not only the re-buffering-time ratios of the DASH clients but also the effectiveness of the PRB usage. Also, it is reasonable to allocate a greater number of PRBs if the NDASH is increased, since a higher NDASH means that the necessity of the PRBs has increased. Also, we have used log function for achievable rate (Rmax,i) and exponential function for buffer levels (Bi[t]) of DASH clients. It is because we want buffer levels to be more influential than achievable rate. In other words, by using the characteristic that exponential values changes rapidly than log values with same amount of input changes, KCRA can get PRBs sufficiently and allocates them to DASH clients who are at risk of buffer underflow. Footnote 1

Likewise, \(\hbar _{2} (t)\) is the control function of the non-DASH clients that stands for the amount of PRBs that is needed for the non-DASH clients. Also, like \(\hbar _{1} (t)\), the amount of the PRB chunk is controlled by the \(\sum _{i=1}^{N_{non-DASH}}\log {(R_{max,i}+a)}\) and the NnonDASH. Footnote 2

Control process

In the control process of the KCRDC, the size of chunks that are allocated to PFRA and the KCRA are controlled with the use of the KKT-conditions. With (11), (12), and (13), it is possible to formulate the optimization problem for the KCRDC as (14), (15), and (16) and the Lagrangian of this problem is represented by (17), as follows:

$$ \alpha \, = \, arg \max_{\alpha_{1}, \alpha_{2}} \mathcal{R}(\alpha), $$
(14)
$$ s.t. \quad g(\alpha) \, = \, \sum\limits_{i=1}^{2} \alpha_{i} - 1 \, \leq \, 0, $$
(15)
$$ \quad \, f_{i}(\alpha_{i}) \, = \, \alpha_{i} \, \geq \, 0, \quad \forall i, $$
(16)
$$ L(\alpha, \, \lambda) \, = \, \mathcal{R}(\alpha) \, - \, \lambda_{1} g(\alpha) + \sum\limits_{i=1}^{2} \lambda_{i+1} f_{i}(\alpha_{i}), $$
(17)

As described earlier in Section 4.1, the objective of this optimization problem is the finding of the proportion set α that maximizes the effectiveness function R(α). Obviously, the optimization problem is constrained by (15) and (16), since the sum of proportion values (alphai) must be less than or equal to 1, and each proportion value must be greater than or equal to zero. The KKT-conditions for (14), (15), and (16) are given by:

$$ \begin{aligned} L_{\alpha_{j}} &= \sum\limits_{i=1}^{2} \hbar_{i}(t) \nabla_{\alpha_{j}} C(\alpha_{i}) - \lambda_{1} \nabla_{\alpha_{j}} g(\alpha) \,\\ &\quad+ \sum\limits_{i=1}^{2} \lambda_{i+1} \nabla_{\alpha_{j}} f_{i}(\alpha_{i}) = 0, \quad \forall j, \end{aligned} $$
(18)
$$ \begin{aligned} L_{\lambda_{j}} &= \sum\limits_{i=1}^{2} \hbar_{i}(t) \nabla_{\lambda_{j}} C(\alpha_{i}) - \nabla_{\lambda_{j}}\lambda_{1} g(\alpha) \, \\ & \quad+ \sum\limits_{i=1}^{2} \nabla_{\lambda_{j}} \lambda_{i+1} f_{i}(\alpha_{i})= \, 0, \quad \forall j, \end{aligned} $$
(19)
$$ \lambda_{1} g(\alpha) \, = \, 0, \quad \lambda_{i+1} f_{i}(\alpha_{i}) \, = \, 0, \quad \forall i, $$
(20)
$$ \lambda_{k} \, \geq 0, \quad \forall i, $$
(21)

By using the conditions of (18), (19), (20), and (21), this problem can be formulated into a matrix form, as follows:

$$ A \, \times \, x \, = \, B, $$
(22)
$$ A \, = \, [\!a_{1}, \ldots, a_{5}]^{T}, $$
(23)
$$ B \, = \, [\!b_{1}, \ldots, b_{5}]^{T}, $$
(24)
$$ x \, = \, [\!\alpha_{1}, \alpha_{2}, \lambda_{1}, \lambda_{2}, \lambda_{3}]^{T} $$
(25)

where ai is the vector that contains coefficient of αi and λi in equation \(L_{\alpha _{i}}\) and \(L_{\lambda _{i}}\). Also, bi is the constant value of equations \(L_{\alpha _{i}}\) and \(L_{\lambda _{i}}\). For instance, if \(L_{\alpha _{1}} = 10\alpha _{1} + 5\alpha _{2} + 0\lambda _{1} - \lambda _{2} + 10\lambda _{3} = 7\), then a1= [ 10 5 0 −1 10] and b1=7

$$ x \, = \, A^{-1} \times B, $$
(26)

If the KKT conditions are not satisfied with the obtained results from (26), some of the conditions are deactivated and the vector x is recalculated. This process is repeated until all the KKT conditions are satisfied. With the values α1 and α2 that are finally obtained from Eq. (26), two PRB chunks that are represented as follows can be obtained:

$$ N_{\mathrm{PRBs-DASH}} \, = \, Tr(\alpha_{1} N_{\text{PRBs}}), $$
(27)
$$ N_{\mathrm{PRBs-non-DASH}} \, = \, Tr(\alpha_{2} N_{\text{PRBs}}), $$
(28)

where NPRBs is the total number of PRBs and Tr() is a truncation function. The sum of NPRBs−DASH and NPRBs−non−DASH, however, will not be NPRBs since α1NPRBs and α2NPRBs are truncated into the integer. In our work, the remaining PRBs are allocated to one of the two schemes which has bigger decimal value.

KKT-conditions-based resource allocation for DASH clients

The KCRA scheme for DASH clients is described in this section. With the resource chunk that is allocated by the KCRDC, the KCRA scheme only needs to allocate resource chunk to the DASH clients to prevent the re-buffering events. Although the KCRA is based on the KKT-conditions same as the KCRDC, its weight factors are different from the KCRDC control factors, since the KCRA objective is different from that of the KCRDC. In Section 5.1, the KCRA weight factors are presented, and the optimization process is described in Section 5.2.

Weight factors of the KCRA

To effectively allocate the PRBs, it is important for the KCRA scheme to consider the following factors:

  1. 1.

    The maximum achievable bit-rates of the DASH clients to maximize the effectiveness of the PRB usage.

  2. 2.

    The buffer levels of the DASH clients to prevent the corresponding re-buffering events.

  3. 3.

    The past average throughputs of the DASH clients to achieve a certain level of fairness among the DASH clients.

The objective of the KCRA is the maximization of the effectiveness function that is given by (29), as follows:

$$ \mathcal{F}(\beta) \, = \, \sum\limits_{i=1}^{N_{DASH}} \phi_{i} (t) C(\beta_{i}), $$
(29)
$$ \phi_{i}(t) \, = \, \frac{R_{max,i}w_{i}(t)}{T_{i}(t)}, \quad \forall i, t, $$
(30)
$$ w_{i}(t) = \frac{\gamma_{i}(t)}{\sum_{i=1}^{N} \gamma_{i}(t)}, \quad \forall i, t, $$
(31)

where \(\gamma _{i} (t)=\log {\left (\frac {B_{i,max}}{B_{i} [t]+ \eta }\right)}\) for all of the t values [13], η is a constant, C(βi)=−(βi−1)2 is a convex function for the optimization, and ϕi(t) is the weight function that consists of the previously described three factors. Also, \(\phantom {\dot {i}\!}\beta =\;[\!\beta _{1},...,\beta _{N_{DASH}}]\) and βi represents the percentage of total downlink resources that ith DASH client will use. The DASH client with the larger ϕi(t) acquires a larger portion of the PRBs, i.e., the DASH client whose buffer level is lower than those of the others (i.e., a large wi(t)), the DASH client whose Rmax,i is larger than those of the others, and the DASH client who previously received less data, i.e., a low Ti(t), can use more PRBs than the other DASH clients. Footnote 3

KCRA optimization process

With (29), (30), and (31), the performance of an optimization process that is similar to the control process of the KCRDC is possible. First, a formulation of the optimization problem as (32), (33), and (34) are necessary, followed by a representation of the Lagrangian of this problem as (35), as follows:

$$ \beta \, = \, arg \max_{\beta_{1},\ldots,\beta_{N_{\text{DASH}}}} \mathcal{F}(\beta) $$
(32)
$$ s.t. \quad \varphi(\beta) \, = \, \sum\limits_{i=1}^{N_{\text{DASH}}}\beta_{i} \, - \, 1 \leq \, 0, $$
(33)
$$ \mu_{i}(\beta_{i}) \, = \, \beta_{i} \, \geq \, 0, \quad \forall i, $$
(34)
$$ L(\beta, \nu) \, = \, \mathcal{F}(\beta) \, - \, \nu_{1} \varphi(\beta) \, + \, \sum\limits_{i=1}^{N_{\text{DASH}}} \nu_{i+1} \mu_{i} (\beta_{i}), $$
(35)

In common with Section 4.2, the KCRA optimization problem is constrained by (33) and (34), and with these constraints, the KKT-conditions for (32), (33), and (34) are given by:

$$ \begin{aligned} L_{\beta_{j}}\! &=\! \sum\limits_{i=1}^{N_{\text{DASH}}} \!\phi_{i}(t) \!\nabla\!_{\beta_{j}} C_{i}(\beta_{i})\,-\,\nu_{1} \nabla_{\beta_{j}}\varphi(\beta) \\&\quad+ \sum\limits_{i=1}^{N_{\text{DASH}}} \!\!\nu\!_{i+1}\!\nabla\!_{\beta_{j}} \mu_{i} (\beta_{i})= \, 0, \quad \forall j, \end{aligned} $$
(36)
$$ \begin{aligned} L_{\nu_{j}} \!&=\! \sum\limits_{i=1}^{N_{\text{DASH}}} \!\!\phi_{i} (t) \!\nabla_{\nu_{j}} C_{i}(\beta_{i}) \! - \! \!\nabla\!_{\nu_{j}} \nu_{1} \varphi(\beta) \,+\,\! \sum\limits_{i=1}^{N_{\text{DASH}}} \!\nabla\!_{\nu_{j}} \nu_{i+1} \mu_{i}(\beta_{i})\\ &= 0, \quad \forall j, \end{aligned} $$
(37)
$$ \nu_{1} \varphi(\beta) \, = \, 0, \quad \nu_{i+1} \mu_{i}(\beta_{i}) \, = \, 0, \quad \forall i, $$
(38)
$$ \nu_{k} \, \geq \, 0, \quad for k \, = \, 1,\ldots, N_{\text{DASH}} \, + \, 1, $$
(39)

By using the conditions of (36), (37), (38), and (39), just like the KCRDC process, this problem can be formulated into a matrix form, as follows:

$$ D \, \times \, y \, = \, E, $$
(40)
$$ D \, = \, [\!d_{1},\ldots, d_{2N_{\text{DASH}}+1}]^{T}, $$
(41)
$$ E \, = \, [\!e_{1}, \ldots, e_{2N_{\text{DASH}}+1}]^{T}, $$
(42)
$$ y \, = \, [\!\beta_{1},\ldots, \beta_{N_{\text{DASH}}}, \nu_{1}, \ldots, \nu_{N_{\text{DASH}}+1}]^{T}, $$
(43)

where di is the vector that contains coefficient of βi and νi in equation \(L_{\beta _{i}}\) and \(L_{\nu _{i}}\) same as the ai in Eq. (23). Also, ei is the constant value of equations \(L_{\beta _{i}}\) and \(L_{\nu _{i}}\) same as the bi in Eq. (24).

$$ y \, = \, D^{-1} \times E, $$
(44)

The iterative process for obtaining optimal results described in Section 4.2 is also done in this optimization process. After the optimization process, the proportion set β is obtained using Eq. (44). By using the set β, every user i receives the amount of resource blocks that is determined by

$$ iNumPRBs(i) \, = \, Tr(\beta_{i} N_{\mathrm{PRBs-DASH}}), $$
(45)

The sum of iNumPRBs(i), i.e., \(\sum _{i=1}^{N} iNumPRBs(i)\), however, will not be NPRBs−DASH, since βiNPRBs−DASH is truncated into the integer. Therefore, to allocate the remaining PRBs to the clients, the Allocating Remaining PRBs (ARP) algorithm is applied.

Algorithm 1 describes the ARP algorithm. At first, the decimal of αiNPRBs is represented as fNumPRBs(i). Then, the array fNumPRBs is sorted into a descending order. Subsequently, with the confirmation that the PRB is available, the DASH clients obtain the PRBs one by one in the order of the fNumPRBs. If the index is NDASH, then the index is set to 1 again to allocate more resources to the clients with a larger decimal.

Results and discussion

To validate the proposed scheme, simulations are implemented in various LTE networks using the NS-3. In Section 6.1, an outline of the simulation parameters and evaluation items is given. In Section 6.2, the simulation results that are obtained in the LTE networks with the application of RASS, BSOP, and PFRA in the base station are introduced. In addition to the base-station application, one of three available CSRASs, SVAA, SFTM, and FDASH, is applied to all of the DASH clients in every simulation. With the obtained results, the following two facts are verified: (1) RASS shows more favorable performances than other reference resource allocation schemes upon the overall consideration of QoE of DASH clients and the fairness among non-DASH clients. (2) RASS operates effectively irrespective of the CSRAS type that is applied.

Simulation setup

To show that the proposed scheme works effectively in various fading environments, the simulation results in Section 6.2 are obtained in the LTE networks using the following two fading models: (1) Extended Vehicular A model—60 km/h, and (2) Extended Typical Urban model—3 km/h. The path loss model of the LTE network in the simulation is the log-distance path loss model. This path loss model can be expressed as

$$ PL \, = \, PL_{0} \, + \, 10n\log\left(\frac{d}{d_{0}}\right), $$
(46)

where PL is the path loss, PL0 is the path loss at the reference distance, n is the path-loss exponent, and d0 is the reference distance (set as 1 m in this simulation). In the simulation, the n is set as 3. Above this, each video is encoded into 13 different bit-rate versions, as follows: = [278 Kbps, 384 Kbps, 522 Kbps, 791 Kbps, 1.033 Mbps, 1.245 Mbps, 1.547 Mbps, 2.134 Mbps, 2.484 Mbps, 3.079 Mbps, 3.527 Mbps, 3.840 Mbps, and 4.22 Mbps]. Also, to simplify the simulation, it is assumed that the traffic that the non-DASH clients received is non-real-time traffic (e.g., FTP, Web) [35]. The rest of the simulation parameters are described in Table 1.

Table 1 Simulation parameters

Simulation results with three CSRAS and three resource allocation schemes

Tables 2, 3, and 4 show the re-buffering-time ratios of the DASH clients with the 50 frames per second (fps) video contents. As shown in the tables, BSOP scheme shows the poorest performance in all the simulation environments. As BSOP scheme uses information of buffer level which only exists in DASH client, BSOP cannot operate effectively in the case that DASH and non-DASH clients exist in network simultaneously. Therefore, it is no wonder that BSOP shows poor and irregular performance even if there are few non-DASH clients in the LTE network (i.e., less harsh network). PFRA scheme shows more favorable performance than BSOP scheme since it considers fairness and allocates more resource blocks to users who have not gotten enough radio resource blocks. However, as the number of non-DASH clients increase, PFRA scheme should allocate more resource blocks to non-DASH clients. Therefore, it is natural that DASH clients experienced more re-buffering events as the number of non-DASH clients increases. On the other hand, with the operation of KCRDC and KCRA, RASS scheme shows no re-buffering events in almost every case. RASS experiences A when there are 9 DASH clients and 30 non-DASH clients (2.117%, 1.715%, 0.412%) due to the large number of DASH clients and non-DASH clients. Nevertheless, RASS still shows the lowest re-buffering ratios among the three resource allocation schemes.

Table 2 Average re-buffering ratios of 3 DASH clients with 50 fps video contents
Table 3 Average re-buffering ratios of 6 DASH clients with 50 fps video contents
Table 4 Average re-buffering ratios of 9 DASH clients with 50 fps video contents

Figure 3 represents the simulation results within the QoE frameworkFootnote 4. The QoE values are normalized by largest value in each case. BSOP provides lowest QoE to DASH clients in almost every case except three cases such as (a)—EVA, (b)—EVA, and (c)—EVA in Fig. 3. In those three cases, PFRA provides lowest QoE to DASH clients when there are 30 non-DASH clients since PFRA have to provide fairness to all the clients. RASS, in constrast with other two schemes, always provides highest QoE value since it manages well the re-buffering events of DASH clients as shown in Tables 2, 3, and 4. With these results, it is verified that by carefully managing re-buffering events of DASH clients, it is possible to increase QoE of DASH clients in harsh network environment.

Figures 4 and 5 show the average received data and the standard deviation of the received data of the non-DASH clients with in various environments. As shown in those figures, BSOP shows the highest standard deviation of the received data, i.e., it performed poorly in terms of the fairness. In contrast, RASS provides almost the same level of standard deviation with PFRA, i.e., it provides great fairness to non-DASH clients. Another point to note in the case of RASS is that the non-DASH clients received a lesser amount of data compared with the other resource allocation schemes. It is because RASS allocates more PRBs to the DASH clients to prevent the experiencing of the expected re-buffering events. However, it is okay for the non-DASH clients to receive data in a slightly more-slower manner since non-real-time traffic is much more tolerant than real-time traffic (i.e., video traffic) [36].

Furthermore, to show that RASS operates effectively regardless of the CSRAS type, the previous results need to be reviewed. If only RASS results in Table 2 and Figs. 3, 4, and 5 are considered, it is noticeable that the DASH clients experience the lowest number of re-buffering events regardless of the type of CSRAS. Furthermore, it is obvious that RASS provides a similar level of fairness to the non-DASH clients regardless of the type of CSRAS. However, there might be a question about the differences among the performances of RASS depending on the type of CSRAS. The differences among the performances are occurred because the segment bit-rates that are requested at a certain time and the timing of the request of a certain segment are different depending on the type of CSRAS. For example, let us assume that RASS provides more data to non-DASH clients in the case of SVAA compared with the case of SFTM. In this context, two cases exist. First, SFTM chooses the segments of the higher bit-rate compared with SVAA. At the cost of a higher bit-rate, SFTM maintains lower DASH-client buffer levels than SVAA. Second, SFTM maintains higher DASH-client buffer levels than SVAA with similar segment bit-rates. In both cases, the SFTM clients use more PRBs than the SVAA clients, i.e., the DASH clients use different amounts of PRBs depending on the type of CSRAS. Therefore, the only focal point is that RASS provides a similar level of the average received data amount and a similar level of the standard deviation of the received data for the non-DASH clients regardless of the type of CSRAS.

Not only the simulation results with 50 fps video contents, but also simulation results with 40 fps video contents have been made. Tables 5, 6, and 7 show the re-buffering ratioss of DASH clients with 40 fps video contents. As shown in those tables, BSOP shows highest re-buffering ratios similarly with the results with 50 fps video contents. However, unlike the results with 50 fps video, PFRA shows low re-buffering ratios because 40 fps video requires 1 frame per 25 msec while 50 fps video requires 1 frame per 20 msec. In other words, re-buffering events occur frequently with higher fps video contents due to the higher number of frames in 1 sec.

Table 5 Average re-buffering ratios of 3 DASH clients with 40 fps video contents
Table 6 Average re-buffering ratios of 6 DASH clients with 40 fps video contents
Table 7 Average re-buffering ratios of 9 DASH clients with 40fps video contents

The average received data and the standard deviation of the received data of the non-DASH clients in the simulations with 40 fps video contents are outlined in Figs. 6, 7, and 8. Same as the Figs. 3, 4, and 5, only the results with 9 DASH clients are represented in those figures. The three resource allocation schemes shows similar tendency compared to the results in Figs. 4 and 5. In other words, BSOP provides lowest QoE to DASH clients except a few cases that PFRA provides lowest QoE. Also, non-DASH clients under RASS received less data than BSOP and PFRA due to the mechanism to prioritize the decrease of re-buffering ratios. Also, RASS shows low standard deviation while BSOP shows bad performance in standard deviation.

Fig. 6
figure6

Average quality of experience (QoE) of 9 DASH clients with 40 fps video contents. a FDASH. b SVAA. c SFTM

Fig. 7
figure7

Average received data of non-DASH clients with 9 DASH clients and 40 fps video contents. a FDASH. b SVAA. c SFTM

Fig. 8
figure8

Standard deviation of the received data with 9 DASH clients and 40 fps video contents. a FDASH. b SVAA. c SFTM

Conclusion

In this paper, we proposed a new resource allocation scheme for symbiosis of DASH clients and non-DASH clients (RASS) to provide seamless video streaming service to DASH clients and to guarantee fairness among non-DASH clients. KCRDC divides the total number of PRBs by considering various factors such as the number of DASH and non-DASH clients, the DASH-client buffer levels, and the maximum achievable bit-rates of all clients. Likewise, KCRA allocates the resource blocks to DASH clients in consideration of the buffer levels, maximum achievable bit-rates, and past average throughput of the DASH clients.

A comparison between the proposed scheme and other resource allocation schemes was performed in various LTE environments with two fading models and a path-loss propagation. With the simulation results, it was verified that RASS scheme provides higher QoE to DASH clients than other schemes and shows almost same fairness compared to PFRA scheme. Also, RASS scheme transparency was proved by a demonstration of a similar tendency regarding the fairness of non-DASH clients and the re-buffering ratios of DASH clients. In summary, the obtained results showed that the proposed scheme operates very effectively in various LTE environments regardless of the type of client-side rate-adaptation scheme.

Notes

  1. 1.

    Also, the α1 and α2 used in this optimization solution represent the proportion of the total PRBs that the DASH clients and non-DASH clients will use. Reviewer 1’s comment 1.

  2. 2.

    Moreover, among the three evaluation items (4)–(6), only re-buffering time ratio is considered by using Bi[t]. Reviewer 1’s comment 5.

  3. 3.

    Same as KCRDC, only re-buffering time ratio is considered in the optimization process by using Bi[t]. Reviewer 1’s comment 5.

  4. 4.

    Unlike the results of the Tables 2, 3, and 4, there are only results of 9 DASH clients in Figs. 3, 4, and 5 since lower number of DASH Clients does not impact the results. Reviewer 1’s comment 2.

    Fig. 3
    figure3

    Average quality of experience (QoE) of 9 DASH clients with 50 fps video contents. a FDASH. b SVAA. c SFTM

    Fig. 4
    figure4

    Average received data of non-DASH clients with 9 DASH clients and 50 fps video contents. a FDASH. b SVAA. c SFTM

    Fig. 5
    figure5

    Standard deviation of the received data with 9 DASH clients and 50 fps video contents. a FDASH. b SVAA. c SFTM

Abbreviations

ARP:

Allocating remaining PRBs

BSOP:

Base station optimization

CDN:

Content distribution network

CSRAS:

Client-side rate-adaptation scheme

CQI:

Channel quality information

DASH:

Dynamic adaptive streaming over http

EVA:

Extended vehicular a

ETU:

Extended typical urban

FDASH:

Fuzzy-logic-based rate-adaptation scheme

FDD:

Frequency division duplexing

FLC:

Fuzzy-logic-controller

HTTP:

Hypertext transfer protocol

KCRA:

KKT-conditions-based resource allocation scheme

KCRDC:

KKT-conditions-based resource-division controller

KKT:

Karush-Kuhn-Tucker

LTE:

Long-term evolution

MCS:

Modulation and coding scheme

MTRA:

Maximum-throughput resource allocation

PFRA:

Proportional fair resource allocation

PRB:

Physical resource block

PUSCH:

Physical uplink shared channel

RASS:

Resource allocation scheme for symbiosis of DASH clients and non-DASH clients

RTP:

Real-time transport protocol

SFTM:

Segment-fetching time method

SVAA:

Smooth-video adaptation algorithm

TTI:

Transmission time interval

QoE:

Quality of experience

UDP:

User datagram protocol

References

  1. 1

    Cisco, Global Mobile Data Traffic Forecast Update, 2016-2021 White Paper (2017).

  2. 2

    ISO/IEC 23009-1:2014, Information technology – Dynamic adaptive streaming over HTTP (DASH) — Part 1: Media presentation description and segment formats.

  3. 3

    ISO/IEC 23009-2:2017, Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 2: Conformance and reference software.

  4. 4

    ISO/IEC 23009-3:2015, Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 3: Implementation guidelines.

  5. 5

    ISO/IEC 23009-4:2013, Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 4: Segment encryption and authentication.

  6. 6

    ISO/IEC 23009-5:2017, Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 5: Server and network assisted DASH (SAND).

  7. 7

    ISO/IEC 23009-6:2017, Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 6: DASH with server push and WebSockets.

  8. 8

    R. Kwan, C. Leung, J. Zhang, Proportional fair multiuser scheduling in LTE. IEEE Signal Process. Lett. 16(6), 461–464 (2009).

    Article  Google Scholar 

  9. 9

    T. Girici, C. Zhu, J.R. Agre, A. Ephremides, Proportional fair scheduling algorithm in OFDMA-based wireless systems with QoS constraints. J. Commun. Netw. 12(1), 30–42 (2010).

    Article  Google Scholar 

  10. 10

    D. Zhou, N. Baldo, M. Miozzo, in Proceedings of the 6th International ICST Conference on Simulation Tools and Techniques, SimuTools ’13. Implementation and Validation of LTE Downlink Schedulers for Ns-3 (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering (ICST)Brussels, 2013), pp. 211–218. http://dl.acm.org/citation.cfm?id=2512734.2512763.

  11. 11

    A. Balachandran, V. Sekar, A. Akella, S. Seshan, I. Stoica, H. Zhang, Developing a predictive model of quality of experience for internet video. ACM SIGCOMM Comput. Commun. Rev. 43(4), 339–350 (2013).

    Article  Google Scholar 

  12. 12

    C. Chen, L.K. Choi, G. de Veciana, C. Caramanis, R.W. Heath, A.C. Bovik, in Acoustics, Speech and Signal Processing (ICASSP), 2013 IEEE International Conference on. A dynamic system model of time-varying subjective quality of video streams over HTTP (IEEE, 2013), pp. 3602–3606.

  13. 13

    K. Xiao, S. Mao, J.K. Tugnait, in Global Communications Conference (GLOBECOM), 2016 IEEE. QoE-Driven Resource Allocation for DASH over OFDMA Networks (IEEE, 2016), pp. 1–6.

  14. 14

    S. Kumar, A. Sarkar, A. Sur, A resource allocation framework for adaptive video streaming over LTE. J. Netw. Comput. Appl. 97:, 126–139 (2017).

    Article  Google Scholar 

  15. 15

    K. Ivesic, L. Skorin-Kapov, M. Matijasevic, Cross-layer QoE-driven admission control and resource allocation for adaptive multimedia services in LTE. J. Netw. Comput. Appl. 46:, 336–351 (2014).

    Article  Google Scholar 

  16. 16

    A. El Essaili, D. Schroeder, E. Steinbach, D. Staehle, M. Shehada, QoE-based traffic and resource management for adaptive HTTP video delivery in LTE. IEEE Trans. Circ. Syst. Video Technol. 25(6), 988–1001 (2015).

    Article  Google Scholar 

  17. 17

    J. Wu, C. Yuen, B. Cheng, Y. Yang, M. Wang, J. Chen, Bandwidth-efficient multipath transport protocol for quality-guaranteed real-time video over heterogeneous wireless networks. IEEE Trans. Commun. 64(6), 2477–2493 (2016).

    Article  Google Scholar 

  18. 18

    M. Zhao, X. Gong, J. Liang, W. Wang, X. Que, S. Cheng, QoE-driven cross-layer optimization for wireless dynamic adaptive streaming of scalable videos over HTTP. IEEE Trans. Circ. Syst. Video Technol. 25(3), 451–465 (2015).

    Article  Google Scholar 

  19. 19

    M.S. Bazaraa, H.D. Sherali, C.M. Shetty, Nonlinear programming: theory and algorithms (Wiley, 2013).

  20. 20

    F.H. Clarke, A new approach to Lagrange multipliers. Math. Oper. Res. 1(2), 165–174 (1976).

    MathSciNet  Article  Google Scholar 

  21. 21

    The network simulator - ns-3. http://www.nsnam.org/. Accessed 25 May 2017.

  22. 22

    A.G. Al-Sakkaf, S. Khan, K. Abdullah, in Communications (MICC), 2015 IEEE 12th Malaysia International Conference on. QoS downlink schedulers in LTE towards 5G network (IEEE, 2015), pp. 225–229.

  23. 23

    G. Tian, Y. Liu, in Proceedings of the 8th international conference on Emerging networking experiments and technologies. Towards agile and smooth video adaptation in dynamic HTTP streaming (ACM, 2012), pp. 109–120.

  24. 24

    C. Liu, I. Bouazizi, M.M. Hannuksela, M. Gabbouj, Rate adaptation for dynamic adaptive streaming over HTTP in content distribution network. Signal Process. Image Commun. 27(4), 288–311 (2012).

    Article  Google Scholar 

  25. 25

    D.J. Vergados, A. Michalas, A. Sgora, D.D. Vergados, P. Chatzimisios, FDASH: A Fuzzy-Based MPEG/DASH Adaptation Algorithm. IEEE Syst. J. 10(2), 859–868 (2016).

    Article  Google Scholar 

  26. 26

    T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext transfer protocol–HTTP/1.0 (1996).

  27. 27

    A. Ghosh, R. Ratasuk, B. Mondal, N. Mangalvedhe, T. Thomas, LTE-advanced: next-generation wireless broadband technology. IEEE Wirel. Commun. 17(3) (2010).

  28. 28

    D. Astély, E. Dahlman, A. Furuskär, Y. Jading, M. Lindström, S. Parkvall, LTE: the evolution of mobile broadband. IEEE Commun. Mag. 47(4) (2009).

    Article  Google Scholar 

  29. 29

    R. Love, R. Kuchibhotla, A. Ghosh, R. Ratasuk, W. Xiao, B. Classon, Y. Blankenship, in Wireless Communications and Networking Conference, 2008. WCNC 2008. IEEE. Downlink control channel design for 3GPP LTE (IEEE, 2008), pp. 813–818.

  30. 30

    3GPP TS 36.213, E-UTRA Physical layer procedures (2008).

  31. 31

    A. Saul, S. Khan, G. Auer, W. Kellerer, E. Steinbach, in Communications, 2007. ICC’07. IEEE International Conference on. Cross-layer optimization with model-based parameter exchange (IEEE, 2007), pp. 5701–5707.

  32. 32

    J. Jiang, V. Sekar, H. Milner, D. Shepherd, I. Stoica, H. Zhang, in NSDI. CFA: A Practical Prediction System for Video QoE Optimization., (2016), pp. 137–150.

  33. 33

    C. Chen, X. Zhu, G. de Veciana, A.C. Bovik, R.W. Heath, Rate adaptation and admission control for video transmission with subjective quality constraints. IEEE J. Sel. Top. Sig. Process. 9(1), 22–36 (2015).

    Article  Google Scholar 

  34. 34

    X. Yin, A. Jindal, V. Sekar, B. Sinopoli, A control-theoretic approach for dynamic adaptive video streaming over http. ACM SIGCOMM Comput. Commun. Rev. 45(4), 325–338 (2015).

    Article  Google Scholar 

  35. 35

    K.B. Johnsson, D.C. Cox, in Vehicular Technology Conference, 2001. VTC 2001 Spring. IEEE VTS 53rd, 4. QoS scheduling of mixed priority non-real-time traffic (IEEE, 2001), pp. 2645–2649.

  36. 36

    D.D. Kouvatsos, Traffic and Performance Engineering for Heterogeneous Networks, vol. 1 (River Publishers, 2009).

Download references

Acknowledgements

This research was supported by the KIAT (Korea Institute for Advancement of Technology) grant funded by the Korea Government (MOTIE : Ministry of Trade Industry and Energy). (No. N0001884, HRD program for Embedded Software).

Availability of data and materials

Please contact the corresponding author at khkim38@konkuk.ac.kr.

Author information

Affiliations

Authors

Contributions

HJK helped in writing the paper, conducting simulations, inventing the proposed scheme, and conducting major revision. YSS helped in conducting simulations, inventing the proposed scheme, and conducting major revision. JTK helped in inventing the proposed scheme. All authors read and approved the final manuscript.

Corresponding author

Correspondence to Hyun Jun Kim.

Ethics declarations

Competing interests

The authors declare that they have no competing interests.

Publisher’s Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Rights and permissions

Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.

Reprints and Permissions

About this article

Verify currency and authenticity via CrossMark

Cite this article

Kim, H.J., Son, Y.S. & Kim, J.T. Design of new resource allocation scheme for symbiosis of DASH clients and non-DASH clients. J Wireless Com Network 2018, 229 (2018). https://doi.org/10.1186/s13638-018-1228-9

Download citation

Keywords

  • Resource allocation scheme
  • Karush-Kuhn-Tucker (KKT)-conditions
  • Rate-adaptation scheme
  • Dynamic adaptive streaming over http
  • Long-Term Evolution (LTE)