# Seamless Mobile Multimedia Broadcasting Using Adaptive Error Recovery

Authors: Carlos M. Lentisco; Luis Bellido; Encarna Pastor
Journal: Mobile Information Systems
 (2017)

---

## Abstract

Multimedia services over mobile networks present several challenges, such as ensuring a reliable delivery of multimedia content, avoiding undesired service disruptions, or reducing service latency. HTTP adaptive streaming addresses these problems for multimedia unicast services, but it is not efficient from the point of view of radio resource consumption. In Long-Term Evolution (LTE) networks, multimedia broadcast services are provided over a common radio channel using a combination of forward error correction and unicast error recovery techniques at the application level. This paper discusses how to avoid service disruptions and reduce service latency for LTE multimedia broadcast services by adding dynamic adaptation capabilities to the unicast error recovery process. The proposed solution provides a seamless mobile multimedia broadcasting without compromising the quality of the service perceived by the users.


---

## Body

## 1. Introduction

The demand of multimedia streaming services is growing as a result of a wide adoption of more capable mobile devices, as well as of the evolution of mobile networks, which keep growing in terms of capacity. In spite of this increasing capacity, live streaming services impose strict requirements in terms of delay, so novel solutions optimizing the delivery of the multimedia content are still needed. In live streaming services, an important quality of service parameter is service latency, defined as the difference between the time at which a live event occurs and the time at which the live event is played on a receiving terminal. By reducing buffering delays, service latency can be minimized. However, in a typical Long-Term Evolution (LTE) multimedia broadcast service, buffering is needed to avoid service disruptions. This paper addresses, in the context of an LTE multimedia broadcast service, how to reduce latency avoiding service disruptions.The 3rd Generation Partnership Project (3GPP) defines how to broadcast multimedia content over LTE using Dynamic Adaptive Streaming over HTTP (DASH) ‎[1] technologies. DASH allows a multimedia player to adapt to the changing network conditions by switching between different representations of the same content. Each representation is split into segments of the same duration, and each segment is univocally identified by a Uniform Resource Locator (URL). A Media Presentation Description (MPD) file is typically used to define the available representations and the URL of the segments.Although the adaptation mechanism of DASH allows providing a seamless playback, in the context of an LTE multimedia broadcast, HTTP is only used as a unicast recovery mechanism. This is because HTTP is not efficient to broadcast the same content to a mass audience in terms of network resource consumption. In LTE, the 3GPP proposes to use the evolved Multimedia Broadcast Multicast Service (eMBMS) ‎[2] to send, over a common channel, a single copy of the multimedia segments to all the terminal clients connected to the eMBMS service.Thus, multimedia segments, coded at a bitrate that fits the available bandwidth of the eMBMS channel, are encapsulated and sent over eMBMS using the file delivery over Unidirectional Transport (FLUTE) protocol ‎[3]. FLUTE, which is particularly suited to multicast networks, works on top of UDP and can be used together with Application Layer Forward Error Correction (AL-FEC) ‎[4] techniques to improve the reliability of data transmission over eMBMS.However, despite using AL-FEC techniques, a high Packet Error Rate (PER) ‎[5] can result in segments being lost in the multicast channel. In that case, HTTP is used as a unicast recovery mechanism to retrieve the lost segment.The design of the solution makes it possible to use standard DASH multimedia players to play the multimedia content. Figure1 shows how the solution would work: segments are pushed by the FLUTE server to the terminals connected to the eMBMS service. The FLUTE client at the terminal copies the segment to an internal web cache. When a DASH player requests a segment, the cache is checked to see if the segment has been already received. If not, the segment is retrieved by HTTP using a unicast channel.Figure 1
Hybrid FLUTE/DASH architecture. The figure shows the components involved in the delivery of multimedia segments over eMBMS and how HTTP is used as a unicast recovery mechanism.When a segment is lost and then retrieved by HTTP, the available bandwidth in the unicast channel can be lower than the bitrate of the representation sent over eMBMS. Therefore, the multimedia playback can stall if the delay introduced by the unicast retransmission of the segment is so long that the segment cannot be retrieved before the buffer is emptied.In this paper, we propose a mechanism to allow selecting alternative representations in case of segments that need to be recovered by HTTP. The mechanism is based on a DASH proxy located close to the base station, so the representation can be selected taking into account the bandwidth that is allocated to the terminal recovering a lost segment (Section4). This adaptive error recovery makes it possible to avoid buffer starvation without increasing service latency.The remainder of the paper is organized as follows. Section2 discusses the related work. Section 3 analyzes the problem of service continuity in a typical LTE multimedia broadcast service. The mechanism proposed to support a seamless LTE multimedia broadcasting is explained in Section 4. Two different approaches to designing a DASH proxy are detailed in Section 5. The definition of multimedia quality of experience metrics is addressed in Section 6. These metrics are then used in the analysis presented in Section 7. Finally, conclusions and future work are summarized in Section 8.


## 2. Related Work

Currently, there are dozens of proposals ‎[6] describing different DASH adaptation algorithms. However, as far as we know, none of them address how a DASH adaptation algorithm could be used in the context of an LTE multimedia broadcast service.Most of the current proposals are based on passive bandwidth estimation techniques ‎[7]. Passive techniques do not inject additional traffic for estimating the available bandwidth. Instead, they use the download time of the segments already downloaded using HTTP. In an LTE multimedia broadcast service, using the download time of segments is not possible because most of the segments are received over the eMBMS channel. One possible solution would consist of using traffic measurements of other applications running in the terminal client. However, this can increase the complexity of the solution, by requiring the DASH client to interact with other applications.Other works ‎[8, 9] propose using active techniques for adaptive video streaming services based on HTTP. Active probing techniques consist of sending dummy packets that are used to estimate the bandwidth. Even if these techniques show an improvement in some parameters of the service (in comparison to using passive bandwidth estimation techniques), the bandwidth is not efficiently used. Therefore, they are not appropriate for multimedia streaming services over LTE networks.De Fez and Guerri ‎[10] propose an adaptive mechanism for delivering multimedia content in wireless networks. It consists of dynamically changing the amount of redundancy introduced by the AL-FEC encoder according to the losses detected by the clients within the coverage area. They focus on file delivery services, so their solution does not require a unicast recovery mechanism to recover data generated in real-time.Other solutions avoiding buffer starvation propose increasing the initial buffer used by the multimedia players. Lohmar et al. ‎[11] calculate the minimum buffer level needed to ensure a seamless playback of the multimedia content. However, they only focus on live streaming services based on HTTP. Focusing on LTE multimedia broadcast services, we have proposed a mechanism to calculate the minimum buffer level needed so that 90% of the users do not perceive service disruptions ‎[12]. However, in that work, we did not consider how requesting different representations during the recovery of lost segments can further reduce service disruptions.Network-assisted strategies for HTTP adaptive streaming have also been proposed. Regarding multimedia streaming services over LTE networks, El Essaili et al. ‎[13] propose to take advantage of a proxy located next to the base station to improve the performance of streaming services based on DASH. Our work also proposes using a proxy, but in the context of an LTE multimedia broadcast service. Since most of the segments are delivered through eMBMS, Section 4 discusses the most appropriate way of recovering the lost segments.Walker et al. ‎[14] have recently proposed a new protocol for multimedia broadcast known as ROUTE. ROUTE is an alternative to FLUTE, which was initially designed as a file delivery protocol. Nevertheless, the ROUTE/DASH solution lacks mechanisms as the one proposed in this paper to provide service continuity without increasing service latency.


## 3. Service Continuity in LTE Multimedia Broadcast Services

In an LTE multimedia broadcast service, only one representation is sent over the eMBMS channel, and, hence, only segments belonging to that representation can be requested. If a segment is lost in the multicast channel and the transmission delay to recover it via HTTP is longer than the buffer level of the client, the player cannot display the segment before its playback deadline and it stalls.


### 3.1. LTE Service Data Rate for eMBMS and Unicast

The multimedia representation sent over eMBMS needs to be coded at a bitrate suited to the maximum eMBMS service data rate. In a typical LTE multimedia broadcast service, the service data rate depends on several parameters, such as the amount of radio resources allocated to the eMBMS service or the AL-FEC schema used ‎[5]. A multicast session could have a dynamically allocated service rate ‎[15], but it can be assumed that, for a multimedia broadcast service, the data rate remains constant until the session finishes.If a segment is lost during its transmission over eMBMS, it is recovered by HTTP using a unicast channel. However, unlike the eMBMS service, the bandwidth in a unicast channel is allocated dynamically.The maximum service data rate for unicast transmissions depends on the Modulation and Coding Scheme (MCS) and the amount of radio resources allocated to each client. The latter is determined by the packet scheduler ‎[16].The base station selects an MCS that maximizes the data rate to the scheduled user with a given target probability of error ‎[16]. To this end, terminals send the base station a report on the quality of the channel, which is based on Signal to Interference plus Noise Ratio (SINR) measurements ‎[17].Regarding the radio resources allocated to the clients, the packet scheduler uses the quality reports sent by the users together with other information of higher layers, such as QoS parameters, buffer status of the clients, or the number of users in a cell.Monserrat et al. ‎[18] analyze the impact of the number of users on the average throughput per unicast client. The analysis shows that the bandwidth of the unicast channel can be lower than the bandwidth of the eMBMS channel and, hence, lower than the bitrate of the representation sent over eMBMS.


### 3.2. Service Continuity and Unicast Error Recovery

Segments that are lost in the multicast channel may cause a service disruption and an increase in service latency. Figure2 shows an example of service disruption. Each time a segment is available to be sent over eMBMS, it is pushed to the local cache of the clients. The time of arrival of the multimedia segment over eMBMS has been denoted as t
m
c
a
s
t.Figure 2
Example of service disruption. The figure shows the effect of the error recovery delay over unicast being longer than the current buffer of the client. In this example, losing segment 4 causes a buffer underrun.As Figure2 shows, a new segment is transmitted over eMBMS every T
s
g
m
n
t seconds (the duration of a multimedia segment). Segments 1, 2, and 3 arrive correctly through the multicast channel, so they can be retrieved directly from the cache. Figure 2 shows that these segments are requested by the multimedia player in instants t
r
e
q
(1–3), when those segments are expected to be already available in the cache. The buffer level (BL) is increased in T
s
g
m
n
t seconds each time a segment is retrieved.The initial buffer level is set taking into account the value of theminBufferTime field of the MPD ‎[1], which defines how much data must be stored in the buffer before starting the playback. In Figure 2,minBufferTimeis three times the duration of the segment (3
·
T
s
g
m
n
t), so the playback starts at instant t
r
e
q
(
3
).When segment 1 is completely played, segment 2 starts to be played, and at the same time, segment 4 is requested. However, segment 4 is lost in the multicast channel. The time of arrival of the multimedia segment over unicast has been denoted ast
u
c
a
s
t. In this example, the error recovery delay over unicast is longer than twice the duration of the segment (2
·
T
s
g
m
n
t). Therefore, segment 4 arrives at t
u
c
a
s
t
(
4
), after the player has already stalled.In the example above, service disruptions would be avoided with a longer initial buffer. But instead, our proposal focus on how to reduce the unicast recovery delay, by using a recovery mechanism that allows switching to lower quality representations during the recovery of lost segments. This mechanism can be used to reduce latency avoiding service disruptions.


## 3.1. LTE Service Data Rate for eMBMS and Unicast

The multimedia representation sent over eMBMS needs to be coded at a bitrate suited to the maximum eMBMS service data rate. In a typical LTE multimedia broadcast service, the service data rate depends on several parameters, such as the amount of radio resources allocated to the eMBMS service or the AL-FEC schema used ‎[5]. A multicast session could have a dynamically allocated service rate ‎[15], but it can be assumed that, for a multimedia broadcast service, the data rate remains constant until the session finishes.If a segment is lost during its transmission over eMBMS, it is recovered by HTTP using a unicast channel. However, unlike the eMBMS service, the bandwidth in a unicast channel is allocated dynamically.The maximum service data rate for unicast transmissions depends on the Modulation and Coding Scheme (MCS) and the amount of radio resources allocated to each client. The latter is determined by the packet scheduler ‎[16].The base station selects an MCS that maximizes the data rate to the scheduled user with a given target probability of error ‎[16]. To this end, terminals send the base station a report on the quality of the channel, which is based on Signal to Interference plus Noise Ratio (SINR) measurements ‎[17].Regarding the radio resources allocated to the clients, the packet scheduler uses the quality reports sent by the users together with other information of higher layers, such as QoS parameters, buffer status of the clients, or the number of users in a cell.Monserrat et al. ‎[18] analyze the impact of the number of users on the average throughput per unicast client. The analysis shows that the bandwidth of the unicast channel can be lower than the bandwidth of the eMBMS channel and, hence, lower than the bitrate of the representation sent over eMBMS.


## 3.2. Service Continuity and Unicast Error Recovery

Segments that are lost in the multicast channel may cause a service disruption and an increase in service latency. Figure2 shows an example of service disruption. Each time a segment is available to be sent over eMBMS, it is pushed to the local cache of the clients. The time of arrival of the multimedia segment over eMBMS has been denoted as t
m
c
a
s
t.Figure 2
Example of service disruption. The figure shows the effect of the error recovery delay over unicast being longer than the current buffer of the client. In this example, losing segment 4 causes a buffer underrun.As Figure2 shows, a new segment is transmitted over eMBMS every T
s
g
m
n
t seconds (the duration of a multimedia segment). Segments 1, 2, and 3 arrive correctly through the multicast channel, so they can be retrieved directly from the cache. Figure 2 shows that these segments are requested by the multimedia player in instants t
r
e
q
(1–3), when those segments are expected to be already available in the cache. The buffer level (BL) is increased in T
s
g
m
n
t seconds each time a segment is retrieved.The initial buffer level is set taking into account the value of theminBufferTime field of the MPD ‎[1], which defines how much data must be stored in the buffer before starting the playback. In Figure 2,minBufferTimeis three times the duration of the segment (3
·
T
s
g
m
n
t), so the playback starts at instant t
r
e
q
(
3
).When segment 1 is completely played, segment 2 starts to be played, and at the same time, segment 4 is requested. However, segment 4 is lost in the multicast channel. The time of arrival of the multimedia segment over unicast has been denoted ast
u
c
a
s
t. In this example, the error recovery delay over unicast is longer than twice the duration of the segment (2
·
T
s
g
m
n
t). Therefore, segment 4 arrives at t
u
c
a
s
t
(
4
), after the player has already stalled.In the example above, service disruptions would be avoided with a longer initial buffer. But instead, our proposal focus on how to reduce the unicast recovery delay, by using a recovery mechanism that allows switching to lower quality representations during the recovery of lost segments. This mechanism can be used to reduce latency avoiding service disruptions.


## 4. Adaptive Error Recovery Mechanism for LTE Multimedia Broadcasting

A description on the proposed adaptive recovery mechanism is detailed below. The solution takes into account that the MPD must define several representations. A DASH proxy will be aware of those representations and will select the one that is adequate for the bandwidth allocated to the terminal by the base station.


### 4.1. MPD for Multicast/Unicast Multimedia Distribution

The 3GPP defines how to broadcast a multimedia content over LTE ‎[2]. In particular, it defines a metadata file known as User Service Bundle Description (USBD), which describes the eMBMS service. The USBD refers to a MPD file that defines the multimedia representations available. By using some fields of the USBD, it is possible to specify which representation is only available for broadcast services, which ones are only available for unicast access, and which ones are available for both unicast and broadcast reception. Therefore, the standard defines an application level mechanism that allows combining the unidirectional delivery of segments with the HTTP recovery of the lost segments.Bellido et al. ‎[19] define, within the MPD itself, which representation is sent over eMBMS and which representations are available for unicast reception. Although this mechanism is used to support a handover between LTE video broadcasting and unicast streaming, it can also be used for the HTTP recovery of the multimedia segments.Regardless of the mechanism used, the DASH proxy that we propose can use this information to select lower quality representations, thus avoiding service disruptions.


### 4.2. Adaptive Error Recovery DASH Proxy

The advantage of using a DASH proxy that is located next to the base station is that it can obtain information about how much bandwidth will be allocated to each client in advance ‎[13]. Thus, for each segment that a client needs to recover, the proxy can select the most adequate representation.Figure3 shows the procedure that is carried out for the HTTP recovery of the segments lost in the multicast channel. In a live streaming service based on DASH, the player periodically requests the segments as they are generated by the content server. The time at which a new segment becomes available so it can be requested is specified by theavailabilityStartTime field of the MPD file ‎[1]. In an LTE multimedia broadcast service,availabilityStartTime can be set to guarantee that a segment is available on the local cache before it is requested over HTTP ‎[12].Figure 3
Adaptive recovery mechanism based on a proxy. The figure shows how the proxy selects an alternative representation when a lost segment is recovered by HTTP.When a new segment is generated in the content server, it is sent over the eMBMS channel by using the FLUTE protocol (S1). The segment, coded at a bitrate that fits the bandwidth of the multicast channel (eMBMS quality), is pushed to all the terminals connected to the eMBMS service. The figure shows that a segment is lost in the multicast channel due to transmission errors, so it needs to be recovered using HTTP.All of the HTTP requests pass through the DASH proxy, which runs an adaptation algorithm to recover the segments. Although the client requests the URL of the eMBMS segment (S2), the DASH proxy can select a lower quality representation (unicast quality) for its transmission over the unicast channel (S3). If the bandwidth available in the unicast channel is greater than or equal to the bitrate of the eMBMS representation, the DASH proxy does not need to modify the URL requested by the client. Finally, the segment requested by the proxy is sent to the client (S4-5).The objective of the adaptive error recovery algorithm carried out by the DASH proxy is to avoid service disruptions by selecting, for each segment, the representation that can be retrieved before buffer starvation. The following section discusses two different approaches to achieve this.


## 4.1. MPD for Multicast/Unicast Multimedia Distribution

The 3GPP defines how to broadcast a multimedia content over LTE ‎[2]. In particular, it defines a metadata file known as User Service Bundle Description (USBD), which describes the eMBMS service. The USBD refers to a MPD file that defines the multimedia representations available. By using some fields of the USBD, it is possible to specify which representation is only available for broadcast services, which ones are only available for unicast access, and which ones are available for both unicast and broadcast reception. Therefore, the standard defines an application level mechanism that allows combining the unidirectional delivery of segments with the HTTP recovery of the lost segments.Bellido et al. ‎[19] define, within the MPD itself, which representation is sent over eMBMS and which representations are available for unicast reception. Although this mechanism is used to support a handover between LTE video broadcasting and unicast streaming, it can also be used for the HTTP recovery of the multimedia segments.Regardless of the mechanism used, the DASH proxy that we propose can use this information to select lower quality representations, thus avoiding service disruptions.


## 4.2. Adaptive Error Recovery DASH Proxy

The advantage of using a DASH proxy that is located next to the base station is that it can obtain information about how much bandwidth will be allocated to each client in advance ‎[13]. Thus, for each segment that a client needs to recover, the proxy can select the most adequate representation.Figure3 shows the procedure that is carried out for the HTTP recovery of the segments lost in the multicast channel. In a live streaming service based on DASH, the player periodically requests the segments as they are generated by the content server. The time at which a new segment becomes available so it can be requested is specified by theavailabilityStartTime field of the MPD file ‎[1]. In an LTE multimedia broadcast service,availabilityStartTime can be set to guarantee that a segment is available on the local cache before it is requested over HTTP ‎[12].Figure 3
Adaptive recovery mechanism based on a proxy. The figure shows how the proxy selects an alternative representation when a lost segment is recovered by HTTP.When a new segment is generated in the content server, it is sent over the eMBMS channel by using the FLUTE protocol (S1). The segment, coded at a bitrate that fits the bandwidth of the multicast channel (eMBMS quality), is pushed to all the terminals connected to the eMBMS service. The figure shows that a segment is lost in the multicast channel due to transmission errors, so it needs to be recovered using HTTP.All of the HTTP requests pass through the DASH proxy, which runs an adaptation algorithm to recover the segments. Although the client requests the URL of the eMBMS segment (S2), the DASH proxy can select a lower quality representation (unicast quality) for its transmission over the unicast channel (S3). If the bandwidth available in the unicast channel is greater than or equal to the bitrate of the eMBMS representation, the DASH proxy does not need to modify the URL requested by the client. Finally, the segment requested by the proxy is sent to the client (S4-5).The objective of the adaptive error recovery algorithm carried out by the DASH proxy is to avoid service disruptions by selecting, for each segment, the representation that can be retrieved before buffer starvation. The following section discusses two different approaches to achieve this.


## 5. Two Approaches for the Proxy Design

The use of the proxy in the context of LTE multimedia broadcast services opens the possibility of designing different adaptation algorithms. In this paper, two different approaches have been selected, focusing on how to solve the lack of bandwidth in the LTE radio channel.


### 5.1. Buffer-Unaware Proxy

A buffer-unaware proxy receives the HTTP request for a lost segment from a player and selects a multimedia representation whose bitrate fits the available unicast bandwidth for the terminal sending the request. Thus, it is possible to avoid buffer starvation if there is not enough bandwidth as to download a segment coded with the eMBMS quality. As Figure4(a) shows, the DASH client requests the same segment that is sent over eMBMS. Then, the DASH proxy selects a more adequate representation taking into account the number and bitrate of the representations defined in the MPD file and how much bandwidth will be allocated to the client.Figure 4
Two possible designs of the LTE DASH proxy: buffer-unaware proxy (a) and buffer-aware proxy (b).
(a)
(b)The MPD file is received by the proxy at the beginning of the streaming session. Regarding the unicast bandwidth allocated to each client, the DASH proxy will obtain it from the base station.Thus, the selection of the representation, which will be denoted asB
u
n
a
w
a
r
e, is given as (1)
B
u
n
a
w
a
r
e
=
arg
⁡
m
a
x
k
B
K
subject  to
B
k
<
B
W
u
n
i
c
a
s
t
,where B
k is the bitrate of the kth representation and B
W
u
n
i
c
a
s
t is the available unicast bandwidth.The purpose of this selection is to ensure that the unicast transmission delay of a segment is lower than the segment duration, so it can be downloaded before the one currently being played is finished. In this case, the DASH proxy will avoid buffer starvation if the MPD includes a representation whose bitrate is lower than the available unicast bandwidth.


### 5.2. Buffer-Aware Proxy

Figure4(b) shows a second approach to designing the DASH proxy. Several segments must be stored in the buffer of the client before starting the playback of the multimedia content. Each time a segment is requested, the client sends its current buffer level in seconds (BL) to the DASH proxy. By taking into account the buffer status, the buffer-aware proxy can select the eMBMS representation even if its bitrate is greater than the available bandwidth. The adaptation algorithm we propose consists of selecting the eMBMS quality (B
e
M
B
M
S) if the error recovery delay of the segment (D
u
c
a
s
t) is expected to be lower than the current buffer level of the client. Otherwise, the buffer is not considered and the buffer-unaware proxy is in charge of selecting the most adequate representation (B
u
n
a
w
a
r
e). Since in this paper the lack of bandwidth in the LTE radio channel is being addressed, it can be assumed that the main component for the recovery delay is the multimedia segment transmission delay. Thus, D
u
c
a
s
t can be calculated as(2)
D
u
c
a
s
t
=
B
e
M
B
M
S
·
T
s
g
m
n
t
B
W
u
n
i
c
a
s
t
.With this in mind, the representation selected by the buffer-aware proxy (B
a
w
a
r
e) is given as(3)
B
a
w
a
r
e
=
B
e
M
B
M
S
,
D
u
c
a
s
t
≤
B
L
B
u
n
a
w
a
r
e
,
D
u
c
a
s
t
>
B
L
.Therefore, the goal of the buffer-aware proxy is to request the eMBMS representation to avoid switching, while avoiding buffer starvation.


## 5.1. Buffer-Unaware Proxy

A buffer-unaware proxy receives the HTTP request for a lost segment from a player and selects a multimedia representation whose bitrate fits the available unicast bandwidth for the terminal sending the request. Thus, it is possible to avoid buffer starvation if there is not enough bandwidth as to download a segment coded with the eMBMS quality. As Figure4(a) shows, the DASH client requests the same segment that is sent over eMBMS. Then, the DASH proxy selects a more adequate representation taking into account the number and bitrate of the representations defined in the MPD file and how much bandwidth will be allocated to the client.Figure 4
Two possible designs of the LTE DASH proxy: buffer-unaware proxy (a) and buffer-aware proxy (b).
(a)
(b)The MPD file is received by the proxy at the beginning of the streaming session. Regarding the unicast bandwidth allocated to each client, the DASH proxy will obtain it from the base station.Thus, the selection of the representation, which will be denoted asB
u
n
a
w
a
r
e, is given as (1)
B
u
n
a
w
a
r
e
=
arg
⁡
m
a
x
k
B
K
subject  to
B
k
<
B
W
u
n
i
c
a
s
t
,where B
k is the bitrate of the kth representation and B
W
u
n
i
c
a
s
t is the available unicast bandwidth.The purpose of this selection is to ensure that the unicast transmission delay of a segment is lower than the segment duration, so it can be downloaded before the one currently being played is finished. In this case, the DASH proxy will avoid buffer starvation if the MPD includes a representation whose bitrate is lower than the available unicast bandwidth.


## 5.2. Buffer-Aware Proxy

Figure4(b) shows a second approach to designing the DASH proxy. Several segments must be stored in the buffer of the client before starting the playback of the multimedia content. Each time a segment is requested, the client sends its current buffer level in seconds (BL) to the DASH proxy. By taking into account the buffer status, the buffer-aware proxy can select the eMBMS representation even if its bitrate is greater than the available bandwidth. The adaptation algorithm we propose consists of selecting the eMBMS quality (B
e
M
B
M
S) if the error recovery delay of the segment (D
u
c
a
s
t) is expected to be lower than the current buffer level of the client. Otherwise, the buffer is not considered and the buffer-unaware proxy is in charge of selecting the most adequate representation (B
u
n
a
w
a
r
e). Since in this paper the lack of bandwidth in the LTE radio channel is being addressed, it can be assumed that the main component for the recovery delay is the multimedia segment transmission delay. Thus, D
u
c
a
s
t can be calculated as(2)
D
u
c
a
s
t
=
B
e
M
B
M
S
·
T
s
g
m
n
t
B
W
u
n
i
c
a
s
t
.With this in mind, the representation selected by the buffer-aware proxy (B
a
w
a
r
e) is given as(3)
B
a
w
a
r
e
=
B
e
M
B
M
S
,
D
u
c
a
s
t
≤
B
L
B
u
n
a
w
a
r
e
,
D
u
c
a
s
t
>
B
L
.Therefore, the goal of the buffer-aware proxy is to request the eMBMS representation to avoid switching, while avoiding buffer starvation.


## 6. QoE Metrics Used to Evaluate the Proposal

ITU-T defined QoE as the acceptability of a service, as perceived subjectively by the user ‎[20]. This definition seems to lead to users rating the perceived quality using a scale such as the Mean Opinion Score (MOS). However, ETSI points out that user experience when using an ICT service or product can also be measured using objective variables related to the communication process or the task outcome ‎[21]. Accordingly, the 3GPP identifies objective QoE metrics in the context of streaming services based on DASH ‎[2]. This section identifies the QoE parameters that can be measured at the application level in the context of our proposal.In a typical LTE multimedia broadcast service, metrics such as the initial start-up delay or stalling ‎[6] are recommended to measure QoE. However, the proposed adaptive recovery mechanism allows switching to a lower quality representation to avoid buffer starvation. Consequently, the number of bitrate switches and the representation quality should also be taken into account ‎[6, 22].A high error rate will increase the number of segments that needs to be recovered using HTTP, affecting the number of bitrate switches and the segment quality. Only if there are no segment losses, or if the unicast bandwidth is larger than the bitrate of the representation sent over eMBMS, there will be no bitrate switches.To sum up, in order to evaluate the impact of the adaptive error recovery mechanism on the service, the following QoE metrics will be used:(i)
Service disruptionis a metric that we have defined to measure stalling. It is defined as the percentage of multimedia segments that are received later than their playback deadline. It can be calculated as (4)
d
i
s
s
g
m
n
t
i
=
1
,
D
u
c
a
s
t
>
B
L
0
,
D
u
c
a
s
t
≤
B
L
,
s
e
r
v
i
c
e
d
i
s
r
u
p
t
i
o
n
=
1
N
∑
i
=
1
N
d
i
s
s
g
m
n
t
i
,
whered
i
s
(
s
g
m
n
t
i
) indicates if the ith segment has arrived on time or not. A service disruption occurs if the error recovery delay of the segment is longer than the current buffer level of the player. Thus, service disruption is the percentage of segments that have not arrived on time with respect to the number of segments that compose the multimedia presentation (N).
(ii)
Instability is the average number of bitrate switches ‎[23]. In a typical LTE multimedia broadcast service, the expected instability is 0%. However, the use of a proxy can introduce the problem of instability. It can be calculated as follows:(5)
s
w
i
t
c
h
s
g
m
n
t
i
=
1
,
B
i
≠
B
i
-
1
0
,
B
i
=
B
i
-
1
,
(6)
i
n
s
t
a
b
i
l
i
t
y
=
1
N
-
1
∑
i
=
2
N
s
w
i
t
c
h
s
g
m
n
t
i
,
where a bitrate switch occurs if the bitrate of theith segment (
B
i
) is different than the bitrate of the (i
-
1)th segment (
B
i
-
1
). Then, instability is calculated as in (6) as the average number of bitrate switches.
(iii)
Average segment quality(factorQ) is the normalized average bitrate measured with respect to the bitrate of the highest quality representation ‎[24]. In the context of LTE multimedia broadcast services, the highest quality representation is the eMBMS representation, with bitrate B
e
M
B
M
S. So Q can be calculated as follows: (7)
Q
=
1
N
·
B
e
M
B
M
S
∑
i
=
1
N
B
s
g
m
n
t
i
.


## 7. Results

Firstly, this section details the platform that we have developed to obtain the results. Then, the relation between the service data rate of the LTE multimedia broadcast service and the number of segments that need to be recovered by HTTP is analyzed. Later, an analysis of service disruptions for a typical LTE multimedia broadcast service is carried out. Finally, the proposal is evaluated by using the following QoE metrics: instability and average segment quality.


### 7.1. Mobile Multimedia Service Analysis Platform

The service analysis platform combines an analytical model built using MATLAB (“MATLAB,” [Online]. Available athttp://mathworks.com/products/matlab) with simulation results obtained using OPNET (“Riverbed Technology,” [Online]. Available at http://tiny.cc/OPNET). By using OPNET, the radio channel condition for a set of users connected to the eMBMS service has been simulated. Table 1 shows the most relevant simulation parameters used to evaluate an LTE multimedia broadcast service. The simulation scenario consists of 399 terminals and a Multicast/Broadcast over Single Frequency Network (MBSFN) area of seven base stations. In MBSFN a set of synchronized base stations transmit the same signal simultaneously, so it is possible to improve the SINR of the multicast receivers and, hence, to reduce the PER ‎[25].Table 1
Parameters used to evaluate an LTE video broadcast service.
Parameter
Value
Total number of terminals
399
ISD
500 m
MCS
15
Path loss model
3GPP Urban Macrocell
Multipath channel model
ITU Pedestrian B
MBSFN area size
7
AL-FEC code rate
0.72–0.92
Length of video
300 s
T
s
g
m
n
t
2 s
B
W
u
n
i
c
a
s
t
0.3–1 Mbps
Video bitrate
0.25/0.5/1 Mbps
minBufferTime
2/3/4 segmentsOther parameters affecting the packet error rate have a fixed value, such as the MCS, or the Intersite Distance (ISD). The value for the MCS (15) is selected taking into account the fact that it is necessary to provide a minimum bitrate of 1 Mbps. A bitrate of 1 Mbps offers a good compromise between video quality and bandwidth for an LTE video broadcast service ‎[26].Regarding the ISD, a standard distance for the separation between base stations for urban environments has been considered. Larger values of ISD would degrade the SINR and increase the PER.By simulating the above scenario, it is possible to obtain the values for the PER affecting the multicast channel for each user. Since OPNET does not allow simulating the hybrid FLUTE/DASH architecture described in Section1, MATLAB has been used to calculate the probability of failure to deliver a segment over eMBMS. This probability, in turn, has been used to determine if a segment is correctly delivered over eMBMS or not. The calculation on the failure probability takes into account both a value of the PER and the AL-FEC code rate used by the transmitter. The AL-FEC code rate is a metric normally used to express the amount of redundancy introduced by the encoder. Specifically, it is defined as the ratio between the k symbols composing the multimedia stream and the k
+
r symbols resulting from the AL-FEC encoding process (where r is the redundancy introduced by the encoder).Thus, the probability of losing a segment due to errors in the packets received through the eMBMS channel is calculated as(8)
P
f
R
C
=
∑
n
=
0
k
+
r
P
f
R
C
∣
n
·
P
N
=
n
,where P
(
N
=
n
) is the probability of receiving n symbols, either from redundancy or from the original object, and P
(
f
R
C
∣
n
) is the failure probability of the AL-FEC decoder in case of receiving n symbols. In the particular case of Raptor ‎[27], which is the standard AL-FEC code for delivering content over eMBMS, P
(
f
R
C
∣
n
) can be calculated as ‎[28](9)
P
f
R
C
∣
n
=
1
i
f
n
<
k
0.85
×
0.56
7
n
-
k
i
f
n
≥
k
.On the other hand, it can be assumed that each symbol is encapsulated in a different packet. Therefore, it is possible to calculate the probability of receivingn symbols, P
(
N
=
n
), as(10)
P
N
=
n
=
k
+
r
n
·
1
-
P
E
R
n
·
P
E
R
k
+
r
-
n
.To determine if a receiver successfully decodes a segment,P
(
f
R
C
) is compared to a uniformly distributed random variable v
r which is sampled each time that P
(
f
R
C
) is calculated. If v
r
>
P
(
f
R
C
), the receiver decodes the segment; otherwise it fails ‎[28].


### 7.2. Relation between Error Recovery and Service Data Rate

Although the problem of reliability is partially sorted out thanks to the use of AL-FEC techniques, they also introduce the problem of how much bandwidth is available to send the multimedia stream. Equation (11) shows how to calculate the service data rate (SDR), which depends on the AL-FEC code rate (CR) and on the bandwidth allocated to the multicast channel (R
e
M
B
M
S):(11)
S
D
R
=
R
e
M
B
M
S
·
C
R
.Figure5 shows the relation between the AL-FEC decoder performance and the code rate, focusing on a typical segment duration value of 2 s (Table 1). Figure 5 shows how lower AL-FEC code rates provide better error recovery; that is, for low AL-FEC values, the percentage of segments that need to be recovered by HTTP is lower. However, it is necessary to provide a minimum bitrate of 1 Mbps. Taking into account (11) and the value of R
e
M
B
M
S of 1.4 Mbps for MCS 15, the subsequent analysis will focus on an AL-FEC code rate of 0.78, which provides the lowest number of unicast retransmissions while satisfying the target bitrate.Figure 5
Relation between the service data rate and the number of segments that need to be recovered by HTTP. The results are shown for aT
s
g
m
n
t of 2 s.


### 7.3. Analysis of Service Disruptions in an LTE Multimedia Broadcast Service

Below, an analysis of the service disruptions in the case of a typical LTE multimedia broadcast service is presented. The parameters of the service are indicated in Table1. The service is characterized by a 300 s video coded using H.264/AVC with a resolution of 720 p and different bitrates (250 Kbps, 500 Kbps, and 1 Mbps). In this case, only the 1 Mbps video representation is used, which corresponds to the representation sent over eMBMS.Figure6 shows the average service disruption (expressed as a percentage) for different values of the unicast bandwidth and for different lengths of the buffer(minBufferTime) in number of segments.Figure 6
Representation of service disruption for different values of the bandwidth and theminBufferTime(mBT). The results are shown for an AL-FEC code rate of 0.78.The figure shows that for aminBufferTime of two segments the maximum service disruption is around 3%. On the other hand, the results indicate that the larger the bandwidth and the longer theminBufferTime, the less the service disruption. As expected, when the available bandwidth is equal to the bitrate of the representation sent over eMBMS, there are no service disruptions. Our proposed proxy, as explained below, will be able to avoid service disruptions with low bandwidths and small values ofminBufferTime.


### 7.4. Performance Evaluation of a DASH Proxy in the Context of an LTE Multimedia Broadcast Service

Since the use of a DASH proxy allows avoiding service disruptions, the proposal is evaluated only considering the following QoE metrics: instability and average segment quality. In this case, the service is characterized by the 1 Mbps video representation that is sent over eMBMS and the two additional representations (250 Kbps, 500 Kbps) that can be requested in case of unicast error recovery.Figure7 shows the average instability for different values ofminBufferTime and available unicast bandwidth. The selected range for bandwidth starts at 300 Kbps, that is, slightly over the minimum bitrate representation. The maximum bandwidth is 1000 Kbps, which is the bitrate of the eMBMS representation. The evaluation has been carried out for the two alternatives defined for the proxy: buffer-aware and buffer-unaware.Figure 7
Representation of instability when using a buffer-unaware proxy (BUP) or a buffer-aware proxy (BAP). Instability is calculated for different values of the unicast bandwidth and theminBufferTime (mBT). The results are shown for an AL-FEC code rate of 0.78.The results show that when the available bandwidth is below 1 Mbps, instability remains constant for the buffer-unaware proxy. The reason is that every time a segment is lost, the proxy needs to select a different representation from the one being sent over eMBMS.In respect to using the buffer-aware proxy, and as it is shown in Figure7, instability can be progressively reduced to 0% for larger bandwidths andminBufferTimevalues of three and four segments. Figure 8 shows how the buffer-aware proxy with a value ofminBufferTimeof two segments can be worse than with a buffer-unaware proxy. This is because two segments are a too short buffer, so requesting the eMBMS quality using the buffer “credit” is causing more switching. Instability also depends on the number and bitrate of the representations defined in the MPD file. This explains the reduction in instability for an available bandwidth of 500 Kbps, which is the bitrate used for one of the DASH representations.Figure 8
Representation of the average segment quality when using a buffer-unaware proxy (BUP) or a buffer-aware proxy (BAP). Average segment quality is calculated for different values of the unicast bandwidth and theminBufferTime (mBT). The results are shown for an AL-FEC code rate of 0.78.Since the MPD does not define an intermediate representation between the representation coded at 500 Kbps and the one coded at 1 Mbps, instability can increase for a bandwidth slightly over 500 Kbps. However, when the bandwidth is closer to 1 Mbps, the buffer is often long enough to compensate the delay of requesting the eMBMS representation, so switching is reduced.Figure8 shows the average segment quality for different values ofminBufferTime and available unicast bandwidth. As defined in Section 6, the average segment quality is measured with respect to the quality of the representation sent over eMBMS. Figure 8 shows that for the worst case depicted (considering a unicast bandwidth equal to 300 Kbps and aminBufferTime of one multimedia segment) the average segment quality is around 0.98.Therefore, there is not a significant degradation in the video quality with respect to the maximum that can be reached if all the segments are correctly delivered over eMBMS. This is consistent with the value of only 2% of the segments being recovered by HTTP.Figure8 shows that the use of aminBufferTime of four segments can help to increase the average segment quality to a value that is close to the bitrate of the representation sent over eMBMS. However, this increase in the average segment quality implies increasing also the service latency to 8 s. Figure 8 also shows that the average segment quality that is achieved by a buffer-aware proxy is not significantly larger than the average segment quality achieved by a buffer-unaware proxy.In conclusion, both the buffer-unaware proxy and the buffer-aware proxy avoid service disruptions. The buffer-aware proxy can be useful to minimize instability and maximize the average segment quality. However, the use of a buffer-aware proxy increases the complexity of the solution because it requires the player sending the buffer level for each HTTP request to the proxy. This requires modifying the multimedia players to be able to send the HTTP request together with additional information measured by the application. A buffer-unaware proxy has the advantage of providing a minimum service latency without requiring any changes in multimedia players. Besides, it does not significantly increase the impact in instability and average segment quality in comparison to a buffer-aware proxy.


## 7.1. Mobile Multimedia Service Analysis Platform

The service analysis platform combines an analytical model built using MATLAB (“MATLAB,” [Online]. Available athttp://mathworks.com/products/matlab) with simulation results obtained using OPNET (“Riverbed Technology,” [Online]. Available at http://tiny.cc/OPNET). By using OPNET, the radio channel condition for a set of users connected to the eMBMS service has been simulated. Table 1 shows the most relevant simulation parameters used to evaluate an LTE multimedia broadcast service. The simulation scenario consists of 399 terminals and a Multicast/Broadcast over Single Frequency Network (MBSFN) area of seven base stations. In MBSFN a set of synchronized base stations transmit the same signal simultaneously, so it is possible to improve the SINR of the multicast receivers and, hence, to reduce the PER ‎[25].Table 1
Parameters used to evaluate an LTE video broadcast service.
Parameter
Value
Total number of terminals
399
ISD
500 m
MCS
15
Path loss model
3GPP Urban Macrocell
Multipath channel model
ITU Pedestrian B
MBSFN area size
7
AL-FEC code rate
0.72–0.92
Length of video
300 s
T
s
g
m
n
t
2 s
B
W
u
n
i
c
a
s
t
0.3–1 Mbps
Video bitrate
0.25/0.5/1 Mbps
minBufferTime
2/3/4 segmentsOther parameters affecting the packet error rate have a fixed value, such as the MCS, or the Intersite Distance (ISD). The value for the MCS (15) is selected taking into account the fact that it is necessary to provide a minimum bitrate of 1 Mbps. A bitrate of 1 Mbps offers a good compromise between video quality and bandwidth for an LTE video broadcast service ‎[26].Regarding the ISD, a standard distance for the separation between base stations for urban environments has been considered. Larger values of ISD would degrade the SINR and increase the PER.By simulating the above scenario, it is possible to obtain the values for the PER affecting the multicast channel for each user. Since OPNET does not allow simulating the hybrid FLUTE/DASH architecture described in Section1, MATLAB has been used to calculate the probability of failure to deliver a segment over eMBMS. This probability, in turn, has been used to determine if a segment is correctly delivered over eMBMS or not. The calculation on the failure probability takes into account both a value of the PER and the AL-FEC code rate used by the transmitter. The AL-FEC code rate is a metric normally used to express the amount of redundancy introduced by the encoder. Specifically, it is defined as the ratio between the k symbols composing the multimedia stream and the k
+
r symbols resulting from the AL-FEC encoding process (where r is the redundancy introduced by the encoder).Thus, the probability of losing a segment due to errors in the packets received through the eMBMS channel is calculated as(8)
P
f
R
C
=
∑
n
=
0
k
+
r
P
f
R
C
∣
n
·
P
N
=
n
,where P
(
N
=
n
) is the probability of receiving n symbols, either from redundancy or from the original object, and P
(
f
R
C
∣
n
) is the failure probability of the AL-FEC decoder in case of receiving n symbols. In the particular case of Raptor ‎[27], which is the standard AL-FEC code for delivering content over eMBMS, P
(
f
R
C
∣
n
) can be calculated as ‎[28](9)
P
f
R
C
∣
n
=
1
i
f
n
<
k
0.85
×
0.56
7
n
-
k
i
f
n
≥
k
.On the other hand, it can be assumed that each symbol is encapsulated in a different packet. Therefore, it is possible to calculate the probability of receivingn symbols, P
(
N
=
n
), as(10)
P
N
=
n
=
k
+
r
n
·
1
-
P
E
R
n
·
P
E
R
k
+
r
-
n
.To determine if a receiver successfully decodes a segment,P
(
f
R
C
) is compared to a uniformly distributed random variable v
r which is sampled each time that P
(
f
R
C
) is calculated. If v
r
>
P
(
f
R
C
), the receiver decodes the segment; otherwise it fails ‎[28].


## 7.2. Relation between Error Recovery and Service Data Rate

Although the problem of reliability is partially sorted out thanks to the use of AL-FEC techniques, they also introduce the problem of how much bandwidth is available to send the multimedia stream. Equation (11) shows how to calculate the service data rate (SDR), which depends on the AL-FEC code rate (CR) and on the bandwidth allocated to the multicast channel (R
e
M
B
M
S):(11)
S
D
R
=
R
e
M
B
M
S
·
C
R
.Figure5 shows the relation between the AL-FEC decoder performance and the code rate, focusing on a typical segment duration value of 2 s (Table 1). Figure 5 shows how lower AL-FEC code rates provide better error recovery; that is, for low AL-FEC values, the percentage of segments that need to be recovered by HTTP is lower. However, it is necessary to provide a minimum bitrate of 1 Mbps. Taking into account (11) and the value of R
e
M
B
M
S of 1.4 Mbps for MCS 15, the subsequent analysis will focus on an AL-FEC code rate of 0.78, which provides the lowest number of unicast retransmissions while satisfying the target bitrate.Figure 5
Relation between the service data rate and the number of segments that need to be recovered by HTTP. The results are shown for aT
s
g
m
n
t of 2 s.


## 7.3. Analysis of Service Disruptions in an LTE Multimedia Broadcast Service

Below, an analysis of the service disruptions in the case of a typical LTE multimedia broadcast service is presented. The parameters of the service are indicated in Table1. The service is characterized by a 300 s video coded using H.264/AVC with a resolution of 720 p and different bitrates (250 Kbps, 500 Kbps, and 1 Mbps). In this case, only the 1 Mbps video representation is used, which corresponds to the representation sent over eMBMS.Figure6 shows the average service disruption (expressed as a percentage) for different values of the unicast bandwidth and for different lengths of the buffer(minBufferTime) in number of segments.Figure 6
Representation of service disruption for different values of the bandwidth and theminBufferTime(mBT). The results are shown for an AL-FEC code rate of 0.78.The figure shows that for aminBufferTime of two segments the maximum service disruption is around 3%. On the other hand, the results indicate that the larger the bandwidth and the longer theminBufferTime, the less the service disruption. As expected, when the available bandwidth is equal to the bitrate of the representation sent over eMBMS, there are no service disruptions. Our proposed proxy, as explained below, will be able to avoid service disruptions with low bandwidths and small values ofminBufferTime.


## 7.4. Performance Evaluation of a DASH Proxy in the Context of an LTE Multimedia Broadcast Service

Since the use of a DASH proxy allows avoiding service disruptions, the proposal is evaluated only considering the following QoE metrics: instability and average segment quality. In this case, the service is characterized by the 1 Mbps video representation that is sent over eMBMS and the two additional representations (250 Kbps, 500 Kbps) that can be requested in case of unicast error recovery.Figure7 shows the average instability for different values ofminBufferTime and available unicast bandwidth. The selected range for bandwidth starts at 300 Kbps, that is, slightly over the minimum bitrate representation. The maximum bandwidth is 1000 Kbps, which is the bitrate of the eMBMS representation. The evaluation has been carried out for the two alternatives defined for the proxy: buffer-aware and buffer-unaware.Figure 7
Representation of instability when using a buffer-unaware proxy (BUP) or a buffer-aware proxy (BAP). Instability is calculated for different values of the unicast bandwidth and theminBufferTime (mBT). The results are shown for an AL-FEC code rate of 0.78.The results show that when the available bandwidth is below 1 Mbps, instability remains constant for the buffer-unaware proxy. The reason is that every time a segment is lost, the proxy needs to select a different representation from the one being sent over eMBMS.In respect to using the buffer-aware proxy, and as it is shown in Figure7, instability can be progressively reduced to 0% for larger bandwidths andminBufferTimevalues of three and four segments. Figure 8 shows how the buffer-aware proxy with a value ofminBufferTimeof two segments can be worse than with a buffer-unaware proxy. This is because two segments are a too short buffer, so requesting the eMBMS quality using the buffer “credit” is causing more switching. Instability also depends on the number and bitrate of the representations defined in the MPD file. This explains the reduction in instability for an available bandwidth of 500 Kbps, which is the bitrate used for one of the DASH representations.Figure 8
Representation of the average segment quality when using a buffer-unaware proxy (BUP) or a buffer-aware proxy (BAP). Average segment quality is calculated for different values of the unicast bandwidth and theminBufferTime (mBT). The results are shown for an AL-FEC code rate of 0.78.Since the MPD does not define an intermediate representation between the representation coded at 500 Kbps and the one coded at 1 Mbps, instability can increase for a bandwidth slightly over 500 Kbps. However, when the bandwidth is closer to 1 Mbps, the buffer is often long enough to compensate the delay of requesting the eMBMS representation, so switching is reduced.Figure8 shows the average segment quality for different values ofminBufferTime and available unicast bandwidth. As defined in Section 6, the average segment quality is measured with respect to the quality of the representation sent over eMBMS. Figure 8 shows that for the worst case depicted (considering a unicast bandwidth equal to 300 Kbps and aminBufferTime of one multimedia segment) the average segment quality is around 0.98.Therefore, there is not a significant degradation in the video quality with respect to the maximum that can be reached if all the segments are correctly delivered over eMBMS. This is consistent with the value of only 2% of the segments being recovered by HTTP.Figure8 shows that the use of aminBufferTime of four segments can help to increase the average segment quality to a value that is close to the bitrate of the representation sent over eMBMS. However, this increase in the average segment quality implies increasing also the service latency to 8 s. Figure 8 also shows that the average segment quality that is achieved by a buffer-aware proxy is not significantly larger than the average segment quality achieved by a buffer-unaware proxy.In conclusion, both the buffer-unaware proxy and the buffer-aware proxy avoid service disruptions. The buffer-aware proxy can be useful to minimize instability and maximize the average segment quality. However, the use of a buffer-aware proxy increases the complexity of the solution because it requires the player sending the buffer level for each HTTP request to the proxy. This requires modifying the multimedia players to be able to send the HTTP request together with additional information measured by the application. A buffer-unaware proxy has the advantage of providing a minimum service latency without requiring any changes in multimedia players. Besides, it does not significantly increase the impact in instability and average segment quality in comparison to a buffer-aware proxy.


## 8. Conclusions and Future Work

In a live LTE multimedia broadcasting service, overprovisioning the buffer needed to recover lost segments increases the end-to-end latency. As an alternative, this paper proposes to use an adaptive error recovery mechanism to reduce the transmission delay of lost segments taking into account the bandwidth available on the unicast recovery channel.Since the use of passive or active bandwidth estimation techniques is not appropriate for LTE multimedia broadcast services, a DASH proxy supporting adaptive error recovery has been proposed. The proxy can learn the available bandwidth of the unicast channel from the base station and select the most appropriate representation for each segment.The discussion of the results shows that a buffer-aware proxy can be used to improve instability and average segment quality. However, a buffer-unaware proxy is less complex and can provide a minimum latency for the service. Alternative approaches for proxies using different adaptation algorithms in the context of LTE multimedia broadcast services are for further study.Implementing a proxy to validate the proposal in a real environment is another future step. The implementation could then be used to perform a subjective evaluation of the QoE based on user surveys.



---

*Source: 1847538-2017-02-27.xml*