Vehicular Environment

5/27/2018 Vehicular Environment

1/75

Project Guide

Ms. Padma V

Associate Professor

IT Department

Nazia Tabassum

M.Tech (SE)

11241D2510


2/75

Contents Abstract

Introduction

Existing System

Proposed System Architecture

Modules

Algorithms

Evaluation Scenarios

Design Engineering Source Code

Project Screens

Conclusion

References


3/75

Abstract We consider a complex (i.e., non-linear) road scenario where

users aboard vehicles equipped with communication interfaces

are interested in downloading large files from road-side Access

Points (APs).

We investigate the possibility of exploiting opportunistic

encounters among mobile nodes so to augment the transfer rate

experienced by vehicular downloaders.

To that end, we devise solutions for the selection of carriersand data chunks at the APs, and evaluate them in real-world

road topologies, under different AP deployment strategies.


4/75

Through extensive simulations, we show that carry & forward

transfers can significantly increase the download rate of

vehicular users in urban/suburban environments, and that such

a result holds throughout diverse mobility scenarios, APplacements and network loads.


5/75

Introduction Vehicles traveling within cities and along highways are

regarded as most probable candidates for a complete

integration into mobile networks of the next generation.

Vehicle-to-infrastructure and vehicle-to-vehicle communication

could indeed foster a number of new applications of notable

interest and critical importance, ranging from danger warning

to traffic congestion avoidance.

It is, however, easy to foresee that the availability of on boardcommunication capabilities will also determine a significant

increase in the number of mobile users regularly employing

business and infotainment applications during their

displacements.


6/75

As a matter of fact, equipping vehicles with WiMAX and/orWiFi capabilities would represent a clear invitation for

passengers on cars or buses to behave exactly as home-based

network users.

The phenomenon would thus affect not only lightweight

services such as web browsing or e-mailing, but also resource-

intensive ones such as streaming or file sharing.


7/75

Existing SystemSPAWN PROTOCOL

SPAWN has the same generic structure of any swarming

protocol.

Peers downloading a fileform a mesh and exchange pieces of

the fileamongst themselves.

The wireless setting of SPAWN, characterized by limitedcapacity, intermittent connectivity and high degree of churn in

nodes requires it to adapt in specificways.


8/75

Fig 2: Evolution of a file in a node using the SPAWN protocol.


9/75

Working of SPAWN Protocol

1. A car arrives in the range of a gateway

2. initiates a download

3. downloads a piece of the file.

4. After getting out of range

5. starts to gossip with its neighbors about content availability

6. exchanges pieces of the file, thereby getting a larger portionof the file as opposed to waiting for the next gateway to

resume the download.


10/75

Disadvantages of SPAWN

SPAWN is designed for unidirectional traffic over a highway.

Built on the assumption that all on-road vehicles are active

downloaders of a same content.

Low Network Capacity.

Access only simple files not large files.

It requires high-end infrastructure to support SPAWN Protocol

and cost of maintenance is high.


11/75

VADD: Vehicle-Assisted Data Delivery in Vehicular Ad Hoc

Networks

In VADD the idea of carry and forward is employed, where a

moving vehicle carries the packet until a new vehicle moves

into its vicinity and forwards the packet.

It proposes a vehicle-assisted data delivery (VADD) protocols

to forward the packet to the best road with the lowest data

delivery delay.

Different from existing carry and forward solutions, it makesuse of the predicable vehicle mobility, which is limited by the

traffic pattern and the road layout.


12/75

Disadvantages of VADD

Data Delivery Ratio: Data delivery ratio is defined as thefunction of the data sending rate (DSR) per second. Datadelivery ratio is poor when the vehicle density is low and when

vehicle density is high then the data delivery ratio is high.

Consumes Bandwidth:As the larger packet size consumes themore bandwidth and the data packet with small bandwidth will

be delivered efficiently. In scheduling schemes the highest

priority is given to the data packet which have the small datasize and the algorithm which work on this principle is theshortest data size first scheduling (SDF) .


13/75

Proposed System In this paper, we focus on the download of large sized files.

We identified and proposed solutions to the problems of

carriers selection and chunk scheduling, and extensively

evaluated them.

The main contribution of this work lies in the demonstration

that vehicular cooperative download in urban environments can

bring significant download rate improvements to users

traveling on trafficked roads in particular.


14/75

Advantages of proposed system

Improve the network capacity.

Cooperative downloads large-sized files.

There are good carry and forward transmission. Frequency of transmission of data is reliable.

Compatible for all data formats to be transmitted on the

network.


15/75

ArchitectureThe following figure explains the architecture of the proposed system.


16/75

Working of the proposed architecture

Vehicle a downloads part of some content from AP A.

The idle AP B delegates another portion of the same content toa vehicle b.

When b encounters a, vehicle-to-vehicle communication is

employed to transfer to a the data carried by b.


17/75

Modules1. Cooperative Download

2. Chunk Scheduling

2.1 Global

2.2 Hybrid

2.3 Local

3. AP deployment

3.1 Random

3.2 Density-based3.3 Cross volume-based


18/75

1. COOPERATIVE DOWNLOAD:

Let us first point out which are the major challenges in the

realization of a vehicular cooperative download system within

complex urban road environments.

The selection of the carrier(s): contacts between cars in

urban/suburban environments are not easily predictable. Idle APs

cannot randomly or inaccurately select vehicles to carry datachunks, or the latter risks to be never delivered to their

destinations. Choosing the right carrier(s) for the right

downloader vehicle is a key issue in the scenarios we will target


19/75

The schedul ing of the data chunks: determining which parts of

the content should be assigned to one or multiple carriers, and

choosing in particular the level of redundancy in this assignment,

plays a major role in reducing the probability that destinationvehicles never receive portions of their files.


20/75

2. CHUNK SCHEDULING:

Upon selection of a destination for the carry & forward

transfer, jointly with the associated local carriers, an AP must

decide on which portion of the data the downloader is

interested in is to be transferred to the carriers.

To that end, we assume that each content is divided into

chunks, i.e., small portions of data that can be transferred as a

single block from the AP to the carriers, and then from the

latter to the destination.

Since a same chunk can be transferred by one or multiple APs

to one or more carriers, the chunk scheduling problem yields a

tradeoff between the reliability and the redundancy of the data

transfer.


21/75

2.1 Global

The Global chunk scheduling assumes that APs maintain per

vehicle distributed chunk databases, similar to the time databases

introduced before. These databases store information on which

chunks have already been scheduled for either direct or carry &

forward delivery to each downloader.


22/75

2.2 Hybrid

The Hybridchunk scheduling allows overlapping between carry

& forward transfers scheduled by different APs.


23/75

2.3 Local

The Local chunk scheduling is similar to the Hybrid scheme,

since different APs can schedule the same chunks when

delegating data to carriers.


24/75

3. AP DEPLOYMENT:

The placement of APs over the urban road topology has a

major influence on the cooperative download architecture.

In order to capture such an effect, we extend our analysis byconsidering diverse AP deployments over the different road

topologies.

AP deployment augments the opportunities for carry&forward

transfers in the download process.


25/75

3.1 Random:

Under the RandomAP positioning scheme, each point of the roadtopology has the same probability of being selected for the

deployment of an AP. The resulting placement may be considered

representative of a completely unplanned infrastructure.

3.2 Density Based:

The Density-basedAP deployment technique aims at maximizing

the probability of direct data transfers from APs to downloader

vehicles. To that end, this technique places the APs at thosecrossroads where the traffic is denser.


26/75

3.3 Cross Volume Based:

The Crossvolume basedAP placement is designed to favor carry

& forward transfers, by increasing the potential for collaboration

among vehicles. This technique exploits the predictability of

large-scale urban vehicular traffic flows, which are known to

follow common mobility patterns over a road topology.


27/75

AlgorithmsCarrier Selection Algorithm

Contacts maps can be exploited by APs to select local cars as

data carriers in the cooperative download process, by

retrieving their contact probability estimates with respect todownloader vehicles.

Firstly, it is necessary that APs know which cars in their

surroundings are interested in some content.

Thus, every time a downloader vehicle starts a productionphase, the fact that it is requesting data, as well as the nature of

the desired content, is attached to the usual information on the

production phase that the local AP shares with other APs.


28/75


29/75

Blind Carriers Selection Algorithm

The Blind carriers selection algorithm aims at fully exploiting

the airtime available at APs, by delivering data to all available

local carriers whenever possible.

This algorithm does not make use of the contacts map, butrandomly chooses a downloader car as the destination of the

data: we thus employ it as a benchmark for the other schemes.

The pseudo code for potential and carriers list updating is

outlined in Fig. 6, while lPmin is set to 0, so that cooperativedownload is attempted even in presence of a single local

carrier.


30/75


31/75

p-Driven Carriers Selection Algorithm

The p-Driven carriers selection algorithm is a probability-

driven version of the Blind algorithm above.

It again tries to exploit as much as possible the APs wireless

resources, but this time cooperative download destinations areselected according to the delivery potential obtained from the

contacts map.


32/75


33/75

p-Constrained Carriers Selection Algorithm

p-Constrained carriers selection algorithm builds on top of the

p-Driven scheme, adding constraints on probabilities, as from

the pseudo code.

In particular, local vehicles with individual contact probabilityIPb lower than lP in d > 0 are not considered for data carrying,

and lPmin is set to a value higher than 0, so that downloader

vehicles with delivery potential IPa lower than lPmin are

discarded.


34/75


35/75

Evaluation Scenarios In order to evaluate the cooperative download mechanisms, we

consider several larg escale vehicular traffic scenarios, that are

representative of real-world road topologies.

We have also taken into account different deployments of APs,

that, have a major impact on the download performance.

Thus the two major scenarios are:

o Vehicular Mobility

o AP Deployment


36/75

Vehicular Mobility:

We selected real-world road topologies from the area ofHyderabad, Secundrabad, to assess the performance of the

cooperative download solutions.

The simulation techniques and mobility models employed togenerate the traces allow to reproduce vehicular movements

over very large road topologies, yet with a good degree of

precision.

The regions are thus divided into 2 types of traces

o Microscopic level traces

o Macroscopic level traces


37/75

This macro- and micromobility realism is important in our

study, since, on the one hand, we exploit large-scale propertiesof urban vehicular mobility in designing the cooperative

download system, and, on the other, realistic small-scale

mobility is required to reproduce vehicle-to-vehicle and

vehicle-to-AP networking interactions.

We focused on four scenarios, representing urban, suburban,

and rural areas within and nearby the city of Hyderabad.

All the areas considered cover surfaces between 15 and 20 km,

and frame several tens of kilometers of major roads.


38/75

Vehicular Mobility: The road topologies considered in our study, representing urban (b),suburban (a, c), and rural (d) areas.


39/75

AP Deployment:

The placement of APs over the urban road topology has amajor influence on the cooperative download architecture.

In order to capture such an effect, we extend our analysis by

considering diverse AP deployments over the different roadtopologies.

The goal of all the deployment strategies is to position, along a

road topology, a given number N of APs; in our performanceevaluation, we will discuss the impact of the value of N as

well.


40/75

The three major AP Deployment techniques are

Random:Under the Random AP positioning scheme, each point of the

road topology has the same probability of being selected for the

deployment of an AP.

The resulting placement may be considered representative of acompletely unplanned infrastructure and it is used in our

performance evaluation as a baseline for the other deployment

techniques.

Density based:

The Density-based AP deployment technique aims at

maximizing the probability of direct data transfers from APs to

downloader vehicles.


41/75

This techniques places the APs at those crossroads where the

traffic is denser.

Cross volume:

The Cross volume-based AP placement is designed to favor

carry&forward transfers, by increasing the potential forcollaboration among vehicles.

This technique exploits the predictability of large-scale urban

vehicular traffic flows, which are known to follow common

mobility patterns over a road topology.


42/75

DATA FLOW DIAGRAMDESIGN ENGINEERING

SENDER RECEIVER

IP Address

Browse a

File

yes

Connecting..

no

ROUTER 1

FIle Transfer

IP Address

Connecting..

Flle Receive

Select Node

yes

no

Connecting..

Detect Initila Node

Via RoadEnvironment

Detect Ready Node

Browse areceived path

End

Via RoadEnvironment

Transfer

Delay timeanalysis chart


43/75

USECASE DIAGRAM

CONTINUEDReceiving Path

Receive A File

Sender

Browse A file

Ip Address

Service Time

Node Selection

Router

Receiver

Socket Connection


44/75

CLASS DIAGRAM

CONTINUED


45/75

SEQUENCE DIAGRAM

CONTINUED

Source:S Router1:R1 Router2:R2 Router3:R3 Router4:R4 Destination:D

initial node

Ready

Success

initail node

Ready

Success

initial

Ready

Success

initial

Ready

Success

Received File

Ip Address

Ip Address

Ip Address

Ip Address


46/75

COLLABORATION DIAGRAM

CONTINUED

Source:S

Router1:R1

Router2:R2

Router3:R3

Router4:R

4

Destination:D

2:

3: 5:

6:

8:

9:

11: 12:

13:

1:4:

7:

10:


47/75

ACTIVITY DIAGRAM

CONTINUED

RECEIVER

Select aReceiving Path

Connecting..

Browse

FILE RECEIVE

IP Address

Browse aFile

NO

Yes

FILE TRANSFER

IP Address

Select a Node

Yes

No

Connecting..

Detect Initial Node

SERVICE TIME

Connecting..

SENDER ROUTER

Via RoadEnvironment Via Road

Environment

Detect Ready Node

TRANSFER


48/75

Source CodeSource code for Server:using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Windows.Forms;

using System.Data.SqlClient;

using System.Net.Sockets;

using System.Net;

using System.IO;

namespace WindowsFormsApplication259

{

public partial class Form1 : Form

{


49/75

int len;

string fileDes, fileini;

public Form1(){

InitializeComponent();

}

private void tabControl1_Click(object sender, EventArgs e)

{

}

private void buttonX1_Click(object sender, EventArgs e)

{textBoxX2.Text = "";

openFileDialog1.ShowDialog();

textBoxX2.Text = openFileDialog1.FileName;

fileDes = openFileDialog1.FileName;

if (fileDes == "openFileDialog1")

{


50/75

lblerror.Text = "";

lblerror.Text = "Select a File first";

textBoxX2.Text = "";btnsend.Enabled = false;

}

else

{

len = fileDes.Length;

fileini = fileDes.Substring(fileDes.IndexOf("\\") + 1);

btnsend.Enabled = true;

}

}

private void btnsend_Click(object sender, EventArgs e){

Application.DoEvents();

send();

pictureBox2.Visible = true;

}


51/75

public void send()

{

try{

IPAddress[] ipAddress = Dns.GetHostAddresses(textip.Text);

IPEndPoint ipEnd = new IPEndPoint(ipAddress[0], 5655);

Socket clientSock = new Socket(AddressFamily.InterNetwork, SocketType.Stream,

ProtocolType.IP);

string filePath = "";

fileDes = fileDes.Replace("\\", "/");

while (fileDes.IndexOf("/") > -1)

{

filePath += fileDes.Substring(0, fileDes.IndexOf("/") + 1);

fileDes = fileDes.Substring(fileDes.IndexOf("/") + 1);}

byte[] fileNameByte = Encoding.ASCII.GetBytes(fileDes);

lblerror.Text = "";

lblerror.Text = "Buffering ...";

byte[] fileData = File.ReadAllBytes(filePath + fileDes);


52/75

byte[] clientData = new byte[4 + fileNameByte.Length + fileData.Length];

byte[] fileNameLen = BitConverter.GetBytes(fileNameByte.Length);

fileNameLen.CopyTo(clientData, 0);fileNameByte.CopyTo(clientData, 4);

fileData.CopyTo(clientData, 4 + fileNameByte.Length);

lblerror.Text = "";

lblerror.Text = "Connection to server ...";

clientSock.Connect(ipEnd);

lblerror.Text = "";

lblerror.Text = "File sending...";

System.Threading.Thread.Sleep(1000);

clientSock.Send(clientData);

label1.Text = clientData.Length.ToString();

lblerror.Text = "";lblerror.Text = "Disconnecting...";

clientSock.Close();

lblerror.Text = "";

lblerror.Text = "File transferred.";

}


53/75

catch (Exception ex)

{

if (ex.Message == "A connection attempt failed because the connected party did not properlyrespond after a period of time, or established connection failed because connected host has failed torespond")

{

lblerror.Text = "";

lblerror.Text = "No Such System Available Try other IP";

}

else{

if (ex.Message == "No connection could be made because the target machine activelyrefused it")

{

lblerror.Text = "";

lblerror.Text = "File Sending fail. Because server not running.";

}else

{

lblerror.Text = "";

lblerror.Text = "File Sending fail." + ex.Message;

}

}}


54/75

}

private void Form1_Load(object sender, EventArgs e)

{

}

private void pictureBox2_CursorChanged(object sender, EventArgs e)

{

//

}private void pictureBox2_BindingContextChanged(object sender, EventArgs e)

{

}

}

}


55/75

Debug the project as shownProject Screens


56/75


57/75


58/75

Select a destination folder : click on receiving path Icon


59/75

Enter IP address in router window


60/75

Enter same IP address and browse the file to transfer


61/75


62/75

Observe the file transfer in router window


63/75

Observe the Delay Tolerant information


64/75

Observe the Blind :random density cross volume graph


65/75

Observe the p-Driven : random density cross volume graph


66/75

Observe the total flow vs random density cross volume graph


67/75

Observe file received status


68/75

Check file received or not to the destination folder


69/75

Conclusion Cooperative download in Vehicular Environment dealswith a complete study of cooperative download in urbanvehicular environments.

It identifies and proposes solutions to the problems ofcarriers selection and chunk scheduling, and extensivelyevaluated them.

The main contribution of this work lies in the

demonstration that vehicular cooperative download inurban environments can bring significant download rateimprovements to users traveling on trafficked roads in

particular.


70/75

Refrences[1] F. Aidouni, M. Latapy, and C. Magnien, Ten Weeks in the Life of aneDonkey Server, Proc. Intl Workshop Peer-to-Peer Systems (HOTP2P 09),

May 2009.

[2] K. Fall, A Delay-Tolerant Network Architecture for Challenged Internets,

Proc. ACM Sigcomm, Aug. 2003.

[3] A. Nandan, S. Das, G. Pau, M. Gerla, and M.Y. Sanadidi, Co- Operative

Downloading in Vehicular Ad-Hoc Wireless Net- works, Proc. Second Ann.Conf. Wireless Network Systems and Services (WONS 05), Jan. 2005. [4] M.

Sardari, F. Hendessi, and F. Fekri, Infocast: A New Paradigm for

Collaborative Content Distribution from Roadside Units to Vehicular

Networks, Proc. Sixth Ann. IEEE Comm. Soc. Conf. Sensor, Mesh and Ad

Hoc Comm. and Networks (SECON 09), 2009.


71/75

[4] M. Sardari, F. Hendessi, and F. Fekri, Infocast: A New Paradigm forCollaborative Content Distribution from Roadside Units to Vehicular

Networks, Proc. Sixth Ann. IEEE Comm. Soc. Conf. Sensor, Mesh and AdHoc Comm. and Networks (SECON 09), 2009.

[5] O. Trullols-Cruces, J. Morillo, J. Barcelo-Ordinas, and J. Garcia- Vidal, ACooperative Vehicular Network Framework, Proc. IEEE Intl Conf. Comm.(ICC 09), June 2009.

[6] B.B. Chen and M.C. Chan, MobTorrent: A Framework for Mobile InternetAccess from Vehicles, Proc. IEEE INFOCOM, Apr. 2009.

[7] J. Zhao and G. Cao, VADD: Vehicle-Assisted Data Delivery in VehicularAd Hoc Networks, Proc. IEEE INFOCOM, Apr. 2006.

[8] S. Yoon, H.Q. Ngo, and C. Qiao, On Shooting a Moving Vehicle withData Flows, Proc. IEEE Mobile Networking for Vehicular Environments(MOVE 07), May 2007.


72/75

[9] F. Malandrino, C. Casetti, C.-F. Chiasserini, and M. Fiore, ContentDownloading in Vehicular Networks: What Really Matters, Proc. IEEE

INFOCOM, Apr. 2011.

[10] Z. Chen, H. Kung, and D. Vlah, Ad Hoc Relay Wireless Networks overMoving Vehicles on Highways, Proc. ACM MobiHoc, Oct. 2001.

[11] J. Burgess, B. Gallagher, D. Jensen, and B. Levine, MaxProp: Routingfor Vehicle-Based Disruption-Tolerant Networks, Proc. IEEE INFOCOM,Apr. 2006.

[12] H.-Y. Huang, P.-E. Luo, M. Li, D. Li, X. Li, W. Shu, and M.-Y. Wu,

Performance Evaluation of SUVnet with Real-Time Traffic Data, IEEETrans. Vehicular Technology, vol. 56, no. 6, pp. 3381-3396, Nov. 2007.

[13] H. Wu, R. Fujimoto, R. Guensler, and M. Hunter, MDDV: A Mobility-Centric Data Dissemination Algorithm for Vehicular Networks, Proc. FirstACM Intl Workshop Vehicular Ad Hoc Networks (VANET 04), Oct. 2004.


73/75

[14] A. Skordylis and N. Trigoni, Delay-Bounded Routing in Vehicular Ad

Hoc Networks, Proc. ACM MobiHoc, May 2008.

[15] J. Zhang, Q. Zhang, and W. Jia, A Novel MAC Protocol for Cooperative

Downloading in Vehicular Networks, Proc. IEEE Global Telecomm. Conf.

(GlobeCom 07), Dec. 2007.

[16] S. Ahmed and S.S. Kanhere, VANETCODE: Network Coding to

Enhance Cooperative Downloading in Vehicular Ad Hoc Net- works, Proc.

ACM Intl Conf. Wireless Comm. and Mobile Computing (IWCMC 06), July

2006.

[17] G. Marfia, G. Pau, E. Giordano, E. De Sena, and M. Gerla, Evaluating

Vehicle Network Strategies for Downtown Portland: Opportunistic

Infrastructure and Importance of Realistic Mobility Models, Proc. First Intl

MobiSys Workshop Mobile Opportunistic Networking (MoBiOpp 07), June

2007.


74/75

[18] Y. Ding, C. Wang, and L. Xiao, A Static-Node Assisted Adaptive

Routing Protocol in Vehicular Networks, Proc. Fourth ACM Intl Workshop

Vehicular Ad Hoc Networks (VANET 07), Sept. 2007.

[19] C. Lochert, B. Scheuermann, C. Wewetzer, A. Luebke, and M. Mauve,

Data Aggregation and Roadside Unit Placement for a Vanet Traffic

Information System, Proc. Fifth ACM Intl Workshop VehiculAr Inter-

NETworking (VANET 08), Sept. 2008.

TRULLOLS-CRUCES ET AL.: COOPERATIVE DOWNLOAD IN

VEHICULAR ENVIRONMENTS 677

TABLE 1 Correlation between the Cooperative Rate and Vehicular Density

Characterizing a Same Road, in Different Scenarios

[20] Z. Zheng, P. Sinha, and S. Kumar, Alpha Coverage: Bounding the

Interconnection Gap for Vehicular Internet Access, Proc. IEEE INFOCOM,

Apr. 2009.


75/75

Queries?

Thank You

Vehicular Environment

Documents

Transcript of Vehicular Environment