Delay Analysis of Network Coded Video Streams in VANETs

Published Online July 2015 in MECS

Vehicular Adhoc Networks (VANETs) are the type of MANETs where vehicles act as nodes. The vehicles exchange data when they need to communicate. There are two major applications of VANETs-infotainment and safety. The infotainment deals with the transfers like download of documents of interest, news, surveys, transfer of advertisement clips from nearby hotels, tourist spots or restaurants when vehicles approach them and entertainment like movie or music downloads etc. The safety application deals with warning messages to the driver like traffic jams, accidents, work in progress, low-bridge problems etc. The vehicles can communicate among themselves termed as Vehicle to Vehicle communication (V2V) and also communicate with the Road Side Units (RSU) termed as Vehicle to Infrastructure (V2I). The information to be communicated can be in the form of text, image, audio, video etc. The drivers of the vehicles normally prefer video among these as they give quick and correct information. When infotainment application is considered, videos stored in web servers are transmitted as streams to the vehicles. With the safety applications, video is captured in the spot of the event by the vehicles moving nearby and the captured video streams travel from the vehicles to the servers. These videos streams are then broadcasted that helps the drivers travelling towards that locality in making a better decision.

When multiple vehicles are seen in the topology, with the sender and receiver not in the range of each other, a routing protocol is required to establish a route between the sender and the receiver. There are various routing protocols designed especially for adhoc networks. The selection of one among these that suits the environment is also a big challenge.

There are various parameters like throughput, signal to noise ratio, packet losses, delay, and jitter etc, which influence the quality of such video transmissions. Though all these have a significant role, delay and jitter play a major role in video transmission as they deal with the time the video reaches and is played back in the receiver. Playback freezes are experienced when the streams arrive late. There are many situations where the streams are missed out from being played when they do not arrive in time. The performance of the network is reduced as the network resources are wasted. This can be known from the metric jitter which deals with the additional time taken by the packets.

One of the popular techniques used in reducing the delay and making the packets reach the destination in time is Network coding. In this technique, the packets are combined and broadcasted to various nodes waiting for the packets. This paper analyses the delay and jitter parameters using NS3 in VANETs when video streams are network coded and transmitted from one vehicle to the other.

• II.    Literature Survey

• A.    VANETs:

VANETs, which help in communication among vehicles, are self-organized networks where two main types of nodes are involved in communication - Road Side Units (RSUs) and the vehicles. In addition to V2I and V2V, hybrid communication is also encountered when RSUs send data to vehicles that are not in its communication range through the other vehicles resulting in multihop communication.

IEEE 802.11 deals with basic Wi-Fi. This is extended with the support of Intelligent Transportation System (ITS) which covers Wireless Access in Vehicular Environment (WAVE) and is given the standard 802.11p. This standard is oriented towards the physical and medium access control layers. [1]

The devices involved in communication are the Application Units (AUs), On Board Units (OBUs) and the Road Side Units (RSUs). The application units are devices seen in the vehicles which carry the applications like user interface etc, given by the provider and it communicates to the other devices like RSU or vehicles via its own OBU. The OBUs communicate with each other and also they communicate with RSUs which could be seen on the road sides. The RSUs are also connected to the web servers so that the internet services can be provided to vehicles. The Dedicated Short Range Communication followed in US, have allocated around 75 MHz (7.850GHz to 7.925 GHz) of frequency band for such vehicular communication. IEEE 1609 deals with the functionalities of WAVE which includes network protocols, security protocols etc.

Some of the vital features of VANETs could be listed as predicted mobility, variable density, widely varying network topology, abundant power etc. [2]

Fig.1. Communication between OBUs and RSUs [2]

• B.    Video Streaming:

When considering the applications of VANETs, video plays a very important role. In infotainment applications, videos generally get transmitted from the web server towards the vehicles through RSU. Pinol et al. [3] discuss on safety applications that videos get transmitted from the vehicles seen in the vicinity of accidents, traffic jam etc, towards the web server. The timely arrival of data in the infotainment services avoid playback freezes i.e. data that arrives late sometimes are not played and becomes useless in spite of usage of heavy network resources. In some environments, the playing of video is delayed which reduces the performance of the network. Drivers could make a better decision with the routes they take when they receive the videos of accidents, traffic jam etc, in the vicinity beforehand. This could avoid the situations getting worsened. Hence transmission of better quality videos within the expected time becomes a big challenge.

The videos of safety application get generated in camera installed in the vehicles and travel towards web servers via RSU. Meng et al. [4] have designed such a triggering system where the vehicles near the spot are triggered in the initial phase and the video recorded is transmitted to server.

Evgeny Belyaev et.al [5] have presented the results of their demonstration done with Wi-fi connected three laptops in vehicles and have transferred video files between them. The first laptop captures the video, compresses and codes the video files and transfers them to the second. The second passes the same with possible packet drops to the third laptop which decodes and plays the files. The video downloads from RSU have also been analysed where 800 m has been observed as the distance for direct reception from RSUs and clear signal reception has been observed as 600m. The packet loss rate and the visual quality are observed when the distance increases from the RSU.

Abbas Bradai et.al. [6] discuss about their new mechanism (ReViV) which is Rebroadcasted–Video Streaming - VANETs to enhance the performance of video streaming in VANETs. The minimum number of best rebroadcasted vehicles are selected. The objective here is to reach more number of vehicles with less hops. The parameters like Peak Signal to Noise Ratio, frame loss and frame delay have been analyzed to give better results than IEEE 1609.4 and Adaptive Information Dissemination [7] protocol.

• C.    End to End Delay:

End to end delay is a very important parameter in both the above mentioned streaming scenarios. The performance of the network is enhanced with reduced delay. Singh et al. [8] assess the end to end delay which is normally influenced by many forms like transmission delay, propagation delay, processing delay, queuing delay, decoding delay etc. The number of links present between the sender and the receiver also plays a vital role.

• D.    Network Coding:

Generally in networks, when data needs to be transmitted from one node to another, the store and forward technique is used where the intermediate node stores the data and forwards the same to the other node when the output link is free. There is another interesting technique termed as network coding (NC) which instead of simply forwarding the data, processes the data and forwards it. The basic operation used in NC is XOR.

Fig.2b. Demonstration of the simplest form of Network coding [9]

Fig.2a. Transfer of packet via a relay node

(a) В can code packets it wants to send

Packets in Next H В s Queue

Coding Option

Is it good?

A

C

C

D

(b) Nexthops of packets in B’s queue

Bad Coding (C can decode but A can't)

Better Coding (Both A and C can decode)

Best Coding (Nodes A, C, and D can decode)

(c) Possible coding options

Fig.3. Analysis of Network coding done by the node B [10]

Figure 3a. shows the packets that are present in the buffers of the nodes A, B, C and D. The next hops of the four packets are portrayed in Fig. 3b. The various possible combinations of packets that could be done are portrayed in Fig. 3c. As shown, when the packets P1, P3 and P4 are XORed and transmitted, the node A gets P1 by XORing the newly received packet (P1 XOR P3 XOR P4) with (P3 XOR P4) seen in its own buffer. With such appropriate combinations, node C gets packet P3 and node D gets P4.

De Alwis et al. [11] consider the stream to be transmitted as blocks. These are represented in a matrix format. The encoding vector which is randomly chosen from the Galois field is combined with such a block and the encoded packet is formed. The decoder as and when it receives a packet puts it in decoding matrix. If the newly arrived packet is helpful in extracting useful information i.e. a successful decoding with new and correct packets from it, it is termed as an innovative packet. If it is not innovative, the packet is reduced to zeros in the decoding matrix and eliminated by Gaussian method. This forms the basis for Random linear Network Coding (RLNC).

Mario et.al. [12] have worked on improving the throughput on streaming videos when the contents are distributed from the server towards one of the vehicle elected as the cluster head that receives data from the RSU. This broadcasts the received data on request. The packet losses and the errors are being observed here when the video is streamed. A two-level architecture has been proposed here which helps in reducing congestion taking enough care about the network coding done by the cluster node. This work has been implemented with the communication between two laptops inside two vehicles which are initially stationary and then made to move talking to each other through gossip messages and also through the messages received via the access point near them. The data transmission and reception status are noted in their journey throughout. The packet losses and error control are taken care during video streaming. Congestion control is done using a two stage queue taking the advantages of NC into consideration.

• E.    Routing Protocols:

When the network becomes large and the nodes interested in communication are not in the range of each other, routing plays a significant part. The router nodes maintain routing tables with the help of which the route through which the packets are to be sent are known. Each node in adhoc network acts as a router and unlike wired nodes every node maintains a routing table.

Kaur et.al [13] discuss about the types of routing tables. The routing tables in adhoc networks can be categorized into three: proactive, reactive and hybrid. Proactive routing is the term used when the routing table is formed with the details of the neighbours when a node joins a network. These details are periodically updated by hello messages where new members get added up and some of the existing members are removed if they have left the network. OLSR and DSDV are some of the examples. Reactive routing is the term used when the routing table is formed or updated only on demand when a route is required for transmission of packets. AODV is an example of reactive routing. Hybrid routing becomes a combination of the above two. Zone routing protocol is an example.

• F.    Open Link State Routing Protocol (OLSR):

Gaurav et al. [14] discuss about OLSR as proactive routing protocol which is based on the link state routing protocol. A set of nodes termed as Multi Point Relay (MPR) nodes are elected here which are the nodes responsible for the distribution of node information to others. Each node has a path to its two hop neighbours via an MPR. The messages seen here are hello messages to know about link existence, topology control (TC) messages which are given by the MPRs regarding the MPR selectors. Only the links representing MPR selection are advertised and not all interfaces of a node. The traditional flooding problems are solved because of the MPRs. Large bandwidth and power is required for the implementation of this protocol.

Shahram Behzad et. al. [15] discuss about the variation that can be done on OLSR protocol to show better results when unnecessary loops are eliminated. The authors reduce the unnecessary loops by dynamically controlling the number of steps to destination. If the number of steps allowed for this is less than 255 and if the packet has still not reached the destination, it is given one more chance by reducing the number of steps to zero. If the number of steps set is more than 255, such packets are discarded as they would occupy more bandwidth and reduce the performance of the network. With such a setting the unnecessary loops are eliminated and the performance is improved in terms of throughput, PDR etc.

• G.    Destination Sequenced Distance Vector (DSDV):

Narra et al. [16] discuss about DSDV as a table-driven proactive routing protocol that periodically updates its routing table. This contains path to not only its neighbours but to every node in the network. In spite of being based on Bellmann Ford algorithm, the routing loop problem of Bellmann Ford is avoided using a sequence number here.

Komathi et al. [17] clarify about the usage of sequence numbers. Generally these sequence numbers are even numbers as they are always incremented by two when a new route is to be informed to others. When any node gets disconnected and that information is to reach others, then it increments the sequence number by 1. When an odd sequence number packet is encountered the other nodes understands of some disconnection in the network and updates their corresponding table.

• H.    Adhoc on Demand Routing Protocol (AODV):

Ikeda et al. [18] discuss about AODV as a reactive protocol which looks for a route on demand. This suits wireless networks as these networks have bandwidth constraints and varying topology. Here a sequence number given by the destination node represents the freshness of the path information. The source and the intermediate nodes maintain next hop information in their tables. This information is updated only when the received packet has sequence number higher than the one stored in the nodes. When a source is not able to find a path to a destination, a route request (RREQ) is broadcasted by the source. The destination machine or the intermediate node which has a correct updated route can send a route reply (RREP) packet back to the source.

Subrananda Goswami et. al. [19] have made a comparative study of the protocols AODV and DSDV when applied on MANETs. The parameters like packet delivery ratio, throughput, routing overhead have been observed and analyzed by the authors.

Bharath Bhushan et. al. [20] have made a comparative study between the on-Demand routing protocols- AODV, Dynamic Source Routing (DSR), Dynamic Manet On-demand (DYMO) Routing protocol. DSR as it is named is a source routing protocol where the route is decided by the source and is attached in the header of every packet it transmits. Hence the packet size is more compared to other protocols. The DYMO acts as a combination of the other two. The performance shown by the authors clearly shows that AODV outperforms the other two when the average delay and the average jitter parameters are considered.

Reza Fotohi et. al. [21] have made a variation in AODV protocol where the Time To Live (TTL) value in the header of the packets which refers to the number of hops the request packet can travel is reduced. The authors keep the number 255 as the upper limit for the number of hops and set their TTL based on the previous TTL and the hop counts actually encountered. The authors show that with such a setup they are able to achieve improved jitter, throughput etc.

• I.    Network Simulator 3:

The network simulator 3 [22-23] is an open source software written in C++. This is not backward compatible with NS2 but some models have been ported from NS2. The reason for choosing NS3 is that it is maintained actively by users. The new version releases are very frequent with updations and contributed codes. As C++ is the language used by models, there is no need to learn new languages. Carneiro et al. [24] introduce Flow Monitor as a framework that is used by NS3 to monitor various metrics like throughput, delay etc. This has become a very handy tool in the calculation of many metrics like mean delay, mean jitter, packet loss ratio etc, without which the programmers need more time for such metrics measurements. This tool is very flexible and easy to use. When the data to be transmitted becomes huge, flow monitor takes care of the complexity.

Racine et al. [25] expresses Gnuplot as a very popular and most used package for creation of graph. This is advantageous as some of its features like highly customizable, fast, easy, linux package, produces very professional graphs, works with even very small file sizes etc.

Klaue et al. [26] introduces the evalvid tool that can be used to transmit video streams between nodes. The other tool in NS3 which can be used to generate traffic is the OnOffApplication. This works only for unicasting. The evalvid tool has been chosen as it streams videos from the codecs H.263, H.264, MP4 etc, and can be used to multicast data. The server and the client uses dump files into which the data is dumped and retrieved when required. The payload size can be decided by the server and the client acts accordingly. The streaming server and client nodes are decided and the corresponding processes installed accordingly. Lacage et al. [27] introduce YANS-Yet Another Network Simulator module with its helper classes helping in establishing the physical and mac channels.

The concept of network coding discussed above is implemented by kodo network coding library from steinwurf. This has been a very useful package for the implementation of network coding concepts. The kodo package uses NS3 as a library and the modules of NS3 are included as files when using the same. The main three functionalities involved are encoding, recoding and decoding. The server machine does the encoding of the data. Recoder nodes decode, make different combination of packets according to the environment and again recode them before transmission. The same procedure is followed by all intermediate nodes which are selected as recoders. The client machine does the decoding and when sufficient packets are collected starts the playback of the video [28]. Kodo is accepted recently as a contributed module to NS3 [29]. The mobility models have different procedures to direct the nodes movements. The selection of these models needs to be appropriate according to the chosen network environments.

• III.    Proposed Approach

A trace file gets generated from a sample MP4 video. Packets are generated according to the contents of the trace file, encoded and are made ready for the transmission to the destination node. As the concept of network coding is implemented here, these encoded packets are transmitted towards the recoder. One of the nodes in the topology is selected as a recoder. The recoder does two functionalities - decoding and recoding. Recoding is the process of combining different packets according to the environment. This combination is transmitted to the receiver where it is decoded. As combination of packets gets transmitted, the number of packets transmitted per flow normally becomes more than one and hence the time taken for the overall transmission of the file gets reduced.

As the usage of real-time test bed may be expensive and incorporating changes could be more complex, the above discussed scenario has been simulated using NS3 and the parameters delay and jitter have been analyzed.

The WAVE environment and its corresponding parameters are set. The physical layer functionalities of Wi-Fi and VANETs remain the same. The MAC layer functionalities of the above two vary and hence appropriate parameters are set. The physical layer functionalities set are given in Table 1.

As the usage of real-time test bed may be expensive and incorporating changes could be more complex, the above discussed scenario has been simulated using NS3 and the parameters delay and jitter have been analyzed.

The WAVE environment and its corresponding parameters are set. The physical layer functionalities of Wi-Fi and VANETs remain the same. The MAC layer functionalities of the above two vary and hence appropriate parameters are set. The physical layer functionalities set are given in Table 1.

Table 1. Parameters set for physical layer

Parameter	Value
Multiplexing	OFDM
Rate	6 Mbps
Packet Size	1000 bytes
Interval	1.0 sec
Generation size	3

The video streaming is implemented by using the Evalvid module. The video packets from the server are network coded using the kodo modules and the encoded packets are recoded in the intermediate machines which are decoded in the client. The rlnc (Random Linear Network Coding) network coding module is used to implement the concept of network coding. The on-the-fly module of kodo is used as it suits video streaming. This does not wait for all the packets to get downloaded for the network coding to begin and hence used in streaming.

NS3 has implementations for the wireless routing protocols like OLSR, AODV and DSDV. The routing protocols create the routing tables either proactively or reactively as per the protocols. These routes are used to transmit the packets.

The delay sum is the sum of the delays of all the packets for every flow during the transmission of the video. Jitter sum is the sum of end to end jitters of all packets for every flow. The graphs are drawn using gnu plot for the routing protocols- OLSR, DSDV and AODV. The node density is also varied and the behavior is noted. Mean delay and mean jitters are also observed for the above scenario.

• IV.    Results And Discussions

  According to RFC 3393 [30], Jitter (IP packet Delay Variation) is considered as the delay variation of a packet with the previous packet in the stream. All the delay and jitter here are represented in nanoseconds. The observations are done with the number of nodes varied as 10, 25 and 50. The three protocols DSDV, OLSR and AODV are applied and the delay sum and the jitter sum are observed when the node densities are varied as 10, 25 and 50.

Fig.4a. Delay sum observed with DSDV for different node densities

Jitter

Flow

Зе+10

2.56+10

Delay

DELAY_AODV_10 ----

DELAY_AODV_25 ----

DELAY AODV 50 —

2е+10

16+10

5е+09

0    200   400   600   800 1000 1200 1400 1600 1800

Flow

Fig.6a. Delaysum observed with AODV for different node densities

Fig.4b. Jitter sum observed with DSDV for different node densities

Delay

Flow

Fig.5a. Delaysum observed with OLSR for different node densities

Jitter

Flow

Fig.5b. Jittersum observed with OLSR for different node densities

2e+10

1.86+10

1.66+10

1 dQ+Ю

Jitter + 10

le+10

8e+09

6e+09

4e+09

26+09

JITTER_AODV_10 —

JITTER_AODV_25 —

JITTER_AODV_50 —

0    200   400   600   800 1000 1200 1400 1600 1800

Flow

Fig.6b. Jitter sum observed with AODV for different node densities

Fig.7a. Mean Delay observed with all three protocols for different node densities

Fig.7b. Mean Jitter observed with all three protocols for different node densities

Fig.7a. and 7b. show the mean delay and mean jitter observed when the number of nodes are varied as 10,25 and 50 and the three routing protocols DSDV, OLSR and AODV are applied. We can observe here that the DSDV protocol shows lesser mean delay and mean jitter compared to other two as expected as proactive routing takes place and the routes are ready beforehand. Though AODV is a reactive protocol, it shows a better performance compared to the proactive OLSR. AODV is the protocol that could suit VANETs because of the varying topology of VANETs and the frequency change in the routes. This now becomes a big challenge in reducing the delay and jitter with appropriate changes in the parameters set.

• V.    Conclusion

As video transmission needs to be quick, especially in safety applications of VANETs, the transmission should be faster, the havoc should be lesser. Hence in this paper, the network coding is applied and the delay is analyzed. The ConstantPosition mobility model which works on stationary nodes is set and the metrics of delay and jitter are observed. The different behaviors with respect to the routing protocols are also analyzed. With varying mobility model and parameters like type of network coding, number of recoders etc, the observed delay and jitter can be reduced in future.