Limits...
Protection of HEVC video delivery in vehicular networks with RaptorQ codes.

Piñol P, Martínez-Rach M, López O, Pérez Malumbres M - ScientificWorldJournal (2014)

Bottom Line: In this paper we focus on HEVC video coding standard streaming in vehicular networks and how it deals with packet losses with the aid of RaptorQ, a Forward Error Correction scheme.As vehicular networks are packet loss prone networks, protection mechanisms are necessary if we want to guarantee a minimum level of quality of experience to the final user.We have run simulations to evaluate which configurations fit better in this type of scenarios.

View Article: PubMed Central - PubMed

Affiliation: Physics and Computer Architecture Department, Miguel Hernández University, Avenida de la Universidad, s/n, 03202 Elche, Spain.

ABSTRACT
With future vehicles equipped with processing capability, storage, and communications, vehicular networks will become a reality. A vast number of applications will arise that will make use of this connectivity. Some of them will be based on video streaming. In this paper we focus on HEVC video coding standard streaming in vehicular networks and how it deals with packet losses with the aid of RaptorQ, a Forward Error Correction scheme. As vehicular networks are packet loss prone networks, protection mechanisms are necessary if we want to guarantee a minimum level of quality of experience to the final user. We have run simulations to evaluate which configurations fit better in this type of scenarios.

No MeSH data available.


Vehicular network scenario in OMNeT++ (red circles A, B, C = RSUs//blue circle ∗ = video client//yellow square T = background traffic source//small circles = other vehicles//red rectangles = buildings).
© Copyright Policy - open-access
Related In: Results  -  Collection


getmorefigures.php?uid=PMC4127264&req=5

fig1: Vehicular network scenario in OMNeT++ (red circles A, B, C = RSUs//blue circle ∗ = video client//yellow square T = background traffic source//small circles = other vehicles//red rectangles = buildings).

Mentions: The study case is based on the scenario shown in Figure 1. It is an area of 2000 m × 2000 m of the city of Kiev. In it we can find a long avenue that crosses that area from north to south. Along the avenue, 3 road side units (RSUs) have been positioned, named A, B, and C in the figure. These RSUs will transmit the video sequence simultaneously (in a synchronized way). The coverage radius of the wireless devices is 500 m. RSUs A and B have a small area where their signals overlap. And RSUs B and C have a small shaded area where neither of the two can reach. Therefore we have three different types of areas regarding transmission: areas where a vehicle can receive the data from only one RSU, one area where the vehicle receives the signal from two RSUs (A and B), and one area where signal is momentarily lost (between B and C coverage areas). A total of 50 vehicles have been inserted into the scenario, driving in different routes. Those vehicles send a beacon every second through the control channel (following IEEE 1609.4 multichannel operations). We also have a vehicle driving near the video client that can act as a background traffic source (labeled as T in Figure 1), sending packets through the wireless network at different packets per second (pps) rates. The video client (marked in the figure as ∗) will experience isolated packet losses (mainly due to background traffic) and bursty packet losses (around the limits of RSUs coverage). RSUs send periodically through the control channel advertisements of the video service that they offer, indicating the service channel used for the video stream. The video client receives that invitation and commutes to the specified service channel in order to receive the video stream.


Protection of HEVC video delivery in vehicular networks with RaptorQ codes.

Piñol P, Martínez-Rach M, López O, Pérez Malumbres M - ScientificWorldJournal (2014)

Vehicular network scenario in OMNeT++ (red circles A, B, C = RSUs//blue circle ∗ = video client//yellow square T = background traffic source//small circles = other vehicles//red rectangles = buildings).
© Copyright Policy - open-access
Related In: Results  -  Collection

Show All Figures
getmorefigures.php?uid=PMC4127264&req=5

fig1: Vehicular network scenario in OMNeT++ (red circles A, B, C = RSUs//blue circle ∗ = video client//yellow square T = background traffic source//small circles = other vehicles//red rectangles = buildings).
Mentions: The study case is based on the scenario shown in Figure 1. It is an area of 2000 m × 2000 m of the city of Kiev. In it we can find a long avenue that crosses that area from north to south. Along the avenue, 3 road side units (RSUs) have been positioned, named A, B, and C in the figure. These RSUs will transmit the video sequence simultaneously (in a synchronized way). The coverage radius of the wireless devices is 500 m. RSUs A and B have a small area where their signals overlap. And RSUs B and C have a small shaded area where neither of the two can reach. Therefore we have three different types of areas regarding transmission: areas where a vehicle can receive the data from only one RSU, one area where the vehicle receives the signal from two RSUs (A and B), and one area where signal is momentarily lost (between B and C coverage areas). A total of 50 vehicles have been inserted into the scenario, driving in different routes. Those vehicles send a beacon every second through the control channel (following IEEE 1609.4 multichannel operations). We also have a vehicle driving near the video client that can act as a background traffic source (labeled as T in Figure 1), sending packets through the wireless network at different packets per second (pps) rates. The video client (marked in the figure as ∗) will experience isolated packet losses (mainly due to background traffic) and bursty packet losses (around the limits of RSUs coverage). RSUs send periodically through the control channel advertisements of the video service that they offer, indicating the service channel used for the video stream. The video client receives that invitation and commutes to the specified service channel in order to receive the video stream.

Bottom Line: In this paper we focus on HEVC video coding standard streaming in vehicular networks and how it deals with packet losses with the aid of RaptorQ, a Forward Error Correction scheme.As vehicular networks are packet loss prone networks, protection mechanisms are necessary if we want to guarantee a minimum level of quality of experience to the final user.We have run simulations to evaluate which configurations fit better in this type of scenarios.

View Article: PubMed Central - PubMed

Affiliation: Physics and Computer Architecture Department, Miguel Hernández University, Avenida de la Universidad, s/n, 03202 Elche, Spain.

ABSTRACT
With future vehicles equipped with processing capability, storage, and communications, vehicular networks will become a reality. A vast number of applications will arise that will make use of this connectivity. Some of them will be based on video streaming. In this paper we focus on HEVC video coding standard streaming in vehicular networks and how it deals with packet losses with the aid of RaptorQ, a Forward Error Correction scheme. As vehicular networks are packet loss prone networks, protection mechanisms are necessary if we want to guarantee a minimum level of quality of experience to the final user. We have run simulations to evaluate which configurations fit better in this type of scenarios.

No MeSH data available.