Final New Report

8/22/2019 Final New Report

1/77

Confinement Of Large File Download In Vehicular Network

M.Tech, DC&N, Dept Of ECE, BTLIT 201213 Page 1

CHAPTER 1

INTRODUCTION


2/77



CHAPTER 1

INTRODUCTION

1.1 BACKGROUND TO THE STUDY

As vehicular networks become popular, more and more people want to access data

from their vehicles. When many vehicles want to access data through a roadside unit,

service scheduling becomes an important issue. This work identifies some challenges in

vehicle-roadside data access. As vehicles move pretty fast, the requests should be served

quickly. Also, vehicles may upload data to the roadside unit, and hence the download and

upload requests compete for the same bandwidth. Instead of using paid services such as3G/LTE/WiMAX communication technologies or exclusive Mobile TV Systems, free

road-side APs can also be utilized to deliver videos available on the internet to mobile

users for cost saving.

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 vehicle infrastructure and vehicle to vehicle communication could indeedfoster 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 onboard communication capabilities will also determine a significant

increase in the number of mobile users regularly employing business and infotainment

applications during their displacements. As a matter of fact, equipping vehicles with

WiMAX/LTE and/or WiFi 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.

This work focuses on one of the latter tasks, namely the download of large-sized

files from the Internet. More precisely, an urban scenario has been considered, where

users aboard cars can exploit roadside Access Points (APs) to access the servers that host

the desired contents.


3/77



Notice that the coverage provided by the roadside APs is intermittent. This is

often the case, since, in presence of large urban, suburban and rural areas, a pervasive

deployment of APs dedicated to vehicular access is often impractical, for economic and

technical reasons. It is assumed that not all on-board users download large files all the

time: indeed, one can expect a behavior similar to that observed in wired networks, where

the portion of queries for large contents is small. As a result, only a minor percentage of

APs is simultaneously involved in direct data transfers to downloader cars in their

respective coverage area, and the majority of APs is instead idle. Within such a context, it

is interesting to study how opportunistic vehicle-to-vehicle communication can

complement the infrastructure-based connectivity, so to speed up the download process.

APs inactivity periods are exploited to transmit, to cars within range of idle APs, pieces

of the data being currently downloaded by other vehicles.

Cars that obtain information chunks this way can then transport the data in a carry

& forward fashion, and deliver it to the destination vehicle, exploiting opportunistic

contacts with it. The concept of cooperative download in vehicular networks has been

already proposed for highway environments: however, unlike what happens over one-

dimensional highways, urban/suburban road topologies present multiple route choices

that make it hard to predict if vehicles will meet; moreover, the presence of traffic lights,

stop and yield signs renders cars contact timings very variable.

These key aspects make highway-tailored solutions impracticable in complex

nonlinear road scenarios, for which to the best of my knowledge, first identify challenges

and propose solutions. Vehicular environments are one of the most promising fields of

application for pervasive mobile networking. If the fast dynamics of the topology of a

network built over moving vehicles make the adoption of a fully ad-hoc paradigm

unfeasible, schemes relying on vehicle-to-infrastructure and opportunistic car-to-car

communication appear instead viable.

Among the possible applications of infrastructure-based opportunistic vehicular

networks, the focus is on that of cooperative download. In fact, although having recently

drawn increasing attention from the research community, studies on vehicular cooperative

download have been limited to highway scenarios, where the one-dimensional nature ofnodes mobility simplifies the problem.


4/77



An urban scenario has been considered where users aboard cars are interested in

downloading large files from servers in the Internet, exploiting to this end APs located

over the road topology. Obviously, not all users download large files all the time: indeed,

one can expect that the portion of vehicles actively downloading large contents is small

over the entire car traffic, as it also happens in traditional networks. Therefore, at each

time instant, only a very few APs are involved in data transfers to downloader cars in

their coverage area, and the majority of APs is instead idle.

1.2 INTELLIGENT TRANSPORT SYSTEM

Intelligent transport systems (ITS) are advanced applications which, without

embodying intelligence as such, aim to provide innovative services relating to different

modes of transport and traffic management and enable various users to be better informed

and make safer, more coordinated, and 'smarter' use of transport networks. The

framework for the deployment of intelligent transport systems in the field of road

transport and for interfaces with other modes of transport defines ITS as systems in which

information and communication technologies are applied in the field of road transport,

including infrastructure, vehicles and users, and in traffic management and mobility

management, as well as for interfaces with other modes of transport.

Intelligent Transport Systems (ITS) include telematics and all types of

communications in vehicles, between vehicles (e.g. car to car), and between vehicles and

fixed locations (e.g. car to AP infrastructure). However, ITS is not restricted to Road

Transport they also include the use of information and communication technologies (ICT)

for rail, water and air transport, including navigation systems. In general, the various

types of ITS rely on radio services for communication and use specialized technologies.

Recent advances in vehicle electronics have led to a move toward fewer, more capablecomputer processors on a vehicle. A typical vehicle in the early 2000s would have

between 20 and 100 individual networked microcontroller/Programmable logic controller

modules with non-real-time operating systems. The current trend is toward fewer, more

costly microprocessor modules with hardware memory management and Real-Time

Operating Systems. The new system platforms allow for more sophisticated software

applications to be implemented, including model-based process control, artificial

intelligence, and ubiquitous computing. Perhaps the most important of these for

Intelligent Transportation Systems is artificial intelligence.
http://en.wikipedia.org/wiki/Vehicle_electronicshttp://en.wikipedia.org/wiki/Microcontrollerhttp://en.wikipedia.org/wiki/Programmable_logic_controllerhttp://en.wikipedia.org/wiki/Operating_systemhttp://en.wikipedia.org/wiki/Microprocessorhttp://en.wikipedia.org/wiki/Memory_managementhttp://en.wikipedia.org/wiki/Real-Time_Operating_Systemhttp://en.wikipedia.org/wiki/Real-Time_Operating_Systemhttp://en.wikipedia.org/wiki/Software_applicationhttp://en.wikipedia.org/wiki/Software_applicationhttp://en.wikipedia.org/wiki/Process_controlhttp://en.wikipedia.org/wiki/Artificial_intelligencehttp://en.wikipedia.org/wiki/Artificial_intelligencehttp://en.wikipedia.org/wiki/Ubiquitous_computinghttp://en.wikipedia.org/wiki/Artificial_intelligencehttp://en.wikipedia.org/wiki/Artificial_intelligencehttp://en.wikipedia.org/wiki/Ubiquitous_computinghttp://en.wikipedia.org/wiki/Artificial_intelligencehttp://en.wikipedia.org/wiki/Artificial_intelligencehttp://en.wikipedia.org/wiki/Process_controlhttp://en.wikipedia.org/wiki/Software_applicationhttp://en.wikipedia.org/wiki/Software_applicationhttp://en.wikipedia.org/wiki/Real-Time_Operating_Systemhttp://en.wikipedia.org/wiki/Real-Time_Operating_Systemhttp://en.wikipedia.org/wiki/Memory_managementhttp://en.wikipedia.org/wiki/Microprocessorhttp://en.wikipedia.org/wiki/Operating_systemhttp://en.wikipedia.org/wiki/Programmable_logic_controllerhttp://en.wikipedia.org/wiki/Microcontrollerhttp://en.wikipedia.org/wiki/Vehicle_electronics


5/77



1.3 ACCESS POINT

In computer networking, a wireless access point (AP) is a device that allows

wireless devices to connect to a wired network using WiFi, or related standards. The AP

usually connects to a router(via a wired network) if it's a standalone device, or is part of a

router itself. Prior to wireless networks, setting up a computer network in a business,

home or school often required running many cables through walls and ceilings in order to

deliver network access to all of the network-enabled devices in the building. With the

creation of the wireless Access Point (AP), network users are now able to add devices that

access the network with few or no cables. A WAP normally connects directly to a wired

Ethernet connection and the AP then provides wireless connections using radio frequency

links for other devices to utilize that wired connection. Most APs support the connection

of multiple wireless devices to one wired connection. Modern APs are built to support a

standard for sending and receiving data using these radio frequencies. Those standards

and the frequencies they use are defined by the IEEE. Most APs use IEEE 802.11

standards.

1.4 VEHICULAR COMMUNICATION SYSTEM

Vehicular Communication Systems are an emerging type of networks in which

vehicles and roadside units are the communicating nodes; providing each other with

information, such as safety warnings and traffic information. As a cooperative approach,

vehicular communication systems can be more effective in avoiding accidents and traffic

congestions than if each vehicle tries to solve these problems individually. Generally

vehicular networks are considered to contain two types of nodes; vehicles and roadside

stations. Both are Dedicated Short Range Communications (DSRC) devices. DSRC

works in 5.9 GHz band with bandwidth of 75 MHz and approximate range of 1000m. The

network should support both private data communications and public (mainly safety)

communications but higher priority is given to public communications.

Vehicular communications is usually developed as a part of Intelligent Transport

Systems (ITS). It seeks to achieve safety and productivity through intelligent

transportation which integrates communication between mobile and fixed nodes. To this

end ITS heavily relies on wired and wireless communications.
http://en.wikipedia.org/wiki/Computer_networkinghttp://en.wikipedia.org/wiki/Wi-Fihttp://en.wikipedia.org/wiki/Router_%28computing%29http://en.wikipedia.org/wiki/Wireless_networkshttp://en.wikipedia.org/wiki/IEEEhttp://en.wikipedia.org/wiki/IEEE_802.11http://en.wikipedia.org/wiki/Computer_networkhttp://en.wikipedia.org/wiki/Vehiclehttp://en.wikipedia.org/wiki/Node_%28networking%29http://en.wikipedia.org/wiki/Dedicated_Short_Range_Communicationshttp://en.wikipedia.org/wiki/Intelligent_Transport_Systemshttp://en.wikipedia.org/wiki/Intelligent_Transport_Systemshttp://en.wikipedia.org/wiki/Intelligent_Transport_Systemshttp://en.wikipedia.org/wiki/Intelligent_Transport_Systemshttp://en.wikipedia.org/wiki/Dedicated_Short_Range_Communicationshttp://en.wikipedia.org/wiki/Node_%28networking%29http://en.wikipedia.org/wiki/Vehiclehttp://en.wikipedia.org/wiki/Computer_networkhttp://en.wikipedia.org/wiki/IEEE_802.11http://en.wikipedia.org/wiki/IEEEhttp://en.wikipedia.org/wiki/Wireless_networkshttp://en.wikipedia.org/wiki/Router_%28computing%29http://en.wikipedia.org/wiki/Wi-Fihttp://en.wikipedia.org/wiki/Computer_networking


6/77



1.5 DELAY TOLERANT NETWORKING

It is an approach to computer network architecture that seeks to address the

technical issues in heterogeneous networks that may lack continuous network

connectivity. Examples of such networks are those operating in mobile or extreme

terrestrial environments, or planned networks in space. The ability to transport, or route,

data from a source to a destination is a fundamental ability all communication networks

must have. Delay and disruption-tolerant networks (DTNs) are characterized by their lack

of connectivity, resulting in a lack of instantaneous end-to-end paths. In these challenging

environments, popular ad hoc routing protocols such as AODV and DSRfail to establish

routes.

This is due to these protocols trying to first establish a complete route and then,

after the route has been established, forward the actual data. However, when

instantaneous end-to-end paths are difficult or impossible to establish, routing protocols

must take to a "store and forward" approach, where data is incrementally moved and

stored throughout the network in hopes that it will eventually reach its destination. A

common technique used to maximize the probability of a message being successfully

transferred is to replicate many copies of the message in the hope that one will succeed in

reaching its destination.

This is feasible only on networks with large amounts of local storage and

internode bandwidth relative to the expected traffic. In many common problem spaces,

this inefficiency is outweighed by the increased efficiency and shortened delivery times

made possible by taking maximum advantage of available unscheduled forwarding

opportunities. A delay-tolerant network is a networkdesigned to operate effectively overextreme distances such as those encountered in space communications or on an

interplanetary scale. In such an environment, long latency sometimes measured in hours

or days is inevitable. However, similar problems can also occur over more modest

distances when interference is extreme or network resources are severely overburdened.

Delay-tolerant networking involves some of the same technologies as are used in a

disruption-tolerant networkbut there are important distinctions. A delay-tolerant network

requires hardware that can store large amounts of data.
http://en.wikipedia.org/wiki/Computer_networkhttp://en.wikipedia.org/wiki/Heterogeneous_networkhttp://en.wikipedia.org/wiki/Ad-hoc_On-demand_Distance_Vectorhttp://en.wikipedia.org/wiki/Dynamic_Source_Routinghttp://searchnetworking.techtarget.com/definition/networkhttp://searchnetworking.techtarget.com/definition/disruption-tolerant-networkhttp://searchcio-midmarket.techtarget.com/definition/hardwarehttp://searchcio-midmarket.techtarget.com/definition/hardwarehttp://searchnetworking.techtarget.com/definition/disruption-tolerant-networkhttp://searchnetworking.techtarget.com/definition/networkhttp://en.wikipedia.org/wiki/Dynamic_Source_Routinghttp://en.wikipedia.org/wiki/Ad-hoc_On-demand_Distance_Vectorhttp://en.wikipedia.org/wiki/Ad-hoc_On-demand_Distance_Vectorhttp://en.wikipedia.org/wiki/Heterogeneous_networkhttp://en.wikipedia.org/wiki/Computer_network


7/77



Such media must be able to survive extended power loss and system restarts. It

must also be immediately accessible at any time. Ideal technologies for this purpose

include hard drives and high-volume flash memory. The data stored on these media must

be organized and prioritized by software that ensures accurate and reliable store-and-

forward functionality.

In a delay-tolerant network, traffic can be classified in three ways, called

expedited, normal and bulk in order of decreasing priority. Expedited packets are always

transmitted, reassembled and verified before data of any other class from a given source

to a given destination. Normal traffic is sent after all expedited packets have been

successfully assembled at their intended destination. Bulk traffic is not dealt with until all

packets of other classes from the same source and bound for the same destination have

been successfully transmitted and reassembled.

1.6 REPORT ORGANIZATION

Documenting the thesis not only provides a valuable reference point and form of

communication but often helps reveal issues and gaps in the analysis and design. The

report contains 9 chapters with the description organized in a way that is easily

understandable and aided with suitable figures. A brief introduction about the work is

described in this chapter followed by Chapter 2 which gives an overview of gathered

details on existing techniques, motivation for carrying the work and the problem

definition. Chapter 3 describes not only the hardware and software requirements, also

functional and non-functional requirements. Chapter 4 describes the system analysis,

existing system, proposed system with the case studies. Chapter 5 describes project

modules and their description. Chapter 6 deals with the implementation of the project in

Java. Chapter 7 is the result analysis with the snapshots. Chapter 8 describes the

advantages and the applications of the system. Chapter 9 describes conclusions and future

enhancements which explain what further improvements can be done to the existing

system.
http://searchstorage.techtarget.com/definition/flash-memoryhttp://searchsoa.techtarget.com/definition/softwarehttp://searchsoa.techtarget.com/definition/softwarehttp://searchstorage.techtarget.com/definition/flash-memory


8/77



CHAPTER 2

LITERATURE SURVEY


9/77



CHAPTER 2

LITERATURE SURVEY

The cooperative download of contents from users aboard vehicles has been first

studied in the paper [1] that introduced SPAWN, a protocol for the retrieval and sharing

of contents vehicular environments. SPAWN is designed for unidirectional traffic over a

highway, and is built on the assumption that all on-road vehicles are active downloaders

of a same content. Instead, the target is on urban environments where users may be

interested in different contents. Similar considerations hold for the works in the papers [2]

and [3].

The highway scenario is replaced by a circular bus route within a campus [4],

which however implies again easily predictable vehicular contacts: indeed, the focus of

the work is on the prefetching and multi-hop transfer of data at each individual AP, while

carry & forward communications are not taken into consideration. Conversely, [5] and [6]

examine urban environments. The author study the upload of small-sized contents from

vehicles to roadside gateways [5], rather than the large downloads is the target. Instead of

considering data transfers to vehicular users in grid-like road topologies, the focus is on

the problem of optimizing direct communications between cars and infrastructure,

without taking into account cooperation among mobile users [6]. Recently, the

performance bounds of vehicular cooperative download in urban scenarios have been

studied [7]: there, however, the authors assume perfect knowledge of the car traffic and

outline a centralized optimal solution, rather than the distributed practical techniques.

As far as opportunistic data exchanges are concerned, the potential of such anetworking paradigm in vehicular environments was first shown in the paper [8].

However, most of these works focus on routing delay-tolerant information in vehicular

networks, while none copes with the problem of cooperative download. Finally, since this

work concentrates on the impact of the infrastructure deployment on the cooperative

download, it also relates to the topic of AP placement in vehicular networks. Then the

author studied the impact of random AP deployments on data routing in urban road

topologies [9]. More complex solutions for the deployment of APs over road topologies

have been proposed [10], to favor delay-tolerant data exchange among vehicles.


10/77



However, the diverse goals in these works lead to in different approaches and

results with respect to ours. More recently, the problem of AP placement to provide

Internet access to vehicles has been addressed [12], [13] and [14]. In all these works,

however, the aim is to maximize vehicle-to vehicle infrastructure coverage or contacts,

and no cooperation among cars is considered.

[1] A. Nandan, S. Das, G. Pau, M. Gerla, M.Y. Sanadidi, Co-operative downloading

in vehicular ad-hoc wireless networks [SPAWN].

The author specifies that SPAWN has the same generic structure of any swarming

protocol. Peers downloading a file form a mesh and exchange pieces of the file amongst

themselves. However the wireless setting of SPAWN, characterized by limited capacity,

intermittent connectivity and high degree of churn in nodes requires it to adapt in specific

ways. Future vehicular networks are expected to deploy short range communication

technology for inter-vehicle communications. In addition to vehicle-vehicle

communication, users will be interested in accessing the multimedia-rich Internet from

within the vehicular network. Conventional client-server approaches in the face of

intermittent connectivity would experience degraded performance.

A new paradigm in content delivery on the Internet using peer-peer swarming

protocols is emerging. The goal of the Internet swarming protocols is to reduce the load

on content servers. Peer-to-peer networking gives ordinary users much more power than

they can ordinarily obtain on their own. Increasing popularity of open source projects and

the consequent demand when a new release is out, (e.g. downloading the latest ISO

images of Linux distributions in the first few weeks of its release) is over whelming. The

traditional solution is to add mirror sites or install a distributed hosting service like

Akamai.

However, there is a significant cost associated with establishing a content

distribution network or establishing a global pool of mirrors. Thus the challenge to

content providers is scaling their content delivery to large audiences. To address this

problem, swarming protocols such as BitTorrent and Slurpee have been proposed. The

idea of Co-operative Networking was first proposed to handle flash crowds on the

Internet, where end-hosts cooperate to improve the overall network performance.


11/77



The high mobility of nodes in Vehicular Wireless Ad-Hoc networks coupled with

the intermittent connectivity to the Internet provides an incentive for individual nodes to

cooperate while accessing the Internet to achieve some level of seamless connectivity.

For the above reasons, an interesting problem is the design of cooperative protocols to

improve client perceived performance of the vehicular network as a whole.

The key contributions of SPAWN protocol are as follows: (1) a gossip mechanism

to propagate content availability information, (2) a proximity driven content selection

strategy (which takes into account the fact that TCP throughput degrades over multi-hop

wireless connection) and (3) leveraging the broadcast nature of wireless networks to

reduce redundant message transmission.

[2] M. Sardari, F. Hendessi, F. Fekri, Infocast: A New Paradigm for Collaborative

Content Distribution from Roadside Units to Vehicular Networks.

In this work, the author addresses the problem of distributing a large amount of

bulk data to a sparse vehicular network from roadside info stations, using efficient

vehicle-to-vehicle collaboration. Due to the highly dynamic nature of the underlying

vehicular network topology, we depart from architectures requiring centralized

coordination, reliable MAC scheduling, or global network state knowledge, and instead

adopt a distributed paradigm with simple protocols. In other words, investigate the

problem of reliable dissemination from multiple sources when each node in the network

shares a limited amount of its resources for cooperating with others.

By using rate less coding at the Road Side Unit (RSU) and using vehicles as data

carriers, an efficient way to achieve reliable dissemination to all nodes (even

disconnected clusters in the network) can be described. In the nutshell, vehicles are

exploited as mobile storage devices. Then a method to keep the density of the rate less

codes packets as a function of distance from the RSU is developed. The author has

assumed each RSU is an independent source having a block of information packets to

disseminate to all vehicles. Ideally, every vehicle must recover information data

belonging to each RSU at any distance. However, this is not feasible given the resources.

Hence, the interest is in optimizing the distance from the source (RSU) where a typical

vehicle can recover its data. The main focus is on investigating various tradeoffsinvolving buffer size, maximum capacity, and the mobility parameter of the vehicles.


12/77



[3] O. Trullols-Cruces, J. Morillo, J. Barcelo-Ordinas, J. Garcia-Vidal, A

Cooperative Vehicular Network Framework.

Vehicular Ad Hoc Networks are networks characterized by intermittent

connectivity and rapid changes in their topology. This paper addresses car to road

communications in which vehicles use Access Points (AP) in Delay Tolerant Network

architecture. Results show how the combination of a Delay Cooperative ARQ mechanism

reduces packet losses and in conjunction with a Carry and Forward cooperative

mechanism improves performance parameters in terms of total file transfer delay and

number of AP needed to download files.

[4] B.B. Chen, M.C. Chan, MobTorrent: A Framework for Mobile Internet Access

from Vehicles.

This work, presents MobTorrent, an on demand, user-driven framework designed

for vehicles which have intermittent high speed access to roadside Wi-Fi access points

(AP). Mobile nodes in MobTorrent use the WWAN network as a control channel. When a

mobile client wants to initiate a download, instead of waiting for contact with the AP, it

informs one (or multiple) selected AP(s) to prefetch the content. The scheduling

algorithm in MobTorrent then replicates the prefetched data on the mobile helpers so that

the total amount of data transferred and the average transfer rate to the mobile clients aremaximized.

Therefore, instead of limiting high speed data transfer to the short contact periods

between APs and mobile clients, high speed transfers among vehicles are

opportunistically exploited. Evaluation based on test bed measurement and trace-driven

simulation shows that MobTorrent provides substantial improvement over existing

architectures. For the case of a single AP, its performance approximates that of an off-line

optimal scheduler.

[5] J. Zhao, G. Cao, VADD: Vehicle-Assisted Data Delivery in Vehicular Ad Hoc

Networks

Multi-hop data delivery through vehicular ad hoc networks is complicated by the

fact that vehicular networks are highly mobile and frequently disconnected. To address

this issue, this work adopts the idea of carry and forward, where moving vehicle carriesthe packet until a new vehicle moves into its vicinity and forwards the packet.


13/77



Different from existing carry and forward solutions, make use of the predicable

vehicle mobility, which is limited by the traffic pattern and road layout. Based on the

existing traffic pattern, a vehicle can find the next road to forward the packet to reduce

the delay. Author proposes several vehicle-assisted data delivery (VADD) protocols to

forward the packet to the best road with the lowest data delivery delay. Experimental

results are used to evaluate the proposed solutions. Results show that the proposed VADD

protocols outperform existing solutions in terms of packet delivery ratio, data packet

delay and protocol overhead. Among the proposed VADD protocols, the H-VADD

protocol has much better performance.

[6] S. Yoon, H.Q. Ngo, C. Qiao, On Shooting a Moving Vehicle with Data Flows.

This paper proposes an ITS system that uses not only integrated cellular and ad

hoc relaying technologies, but also users mobility profiles. It focuses on a subsystem

where cellular bandwidth is used mostly for control signals, and an ad hoc distribution

network (ADN) is used for file downloading and video streaming. The paper formulates

an optimization problem with the objective being to maximize the amount of data to be

delivered to a moving vehicle via the ADN, and thereby minimizing the usage of the

costly cellular bandwidth for data transfer. . Three approaches based on non-linear and

linear programs are described and compared, and simulation results indicate that a

satisfying performance for file download applications can be achieved.

[7] Z. Chen, H. Kung, D. Vlah, Ad hoc relay wireless networks over moving

vehicles on highways.

Ad hoc networks can be formed on highways among moving vehicles, each

equipped with a wireless LAN device. How- ever, during times of low density, it is likely

that such networks are disconnected. This paper tests the hypothesis that the motion of

vehicles on a highway can contribute to successful message delivery, provided that

messages can be relayed stored temporarily at moving nodes while wait be relayed stored

temporarily at moving nodes while waiting for opportunities to be forwarded further.

Using vehicle movement traces from a micro simulator, the measurement of average

message delivery time and that it is shorter than when the messages are not relayed. The

author concludes that ad hoc relay wireless networks, based on wireless LAN

technologies, have potential for many emerging applications of this kind.


14/77



[8] Z. Zheng, Z. Lu, P. Sinha, S. Kumar, Maximizing the Contact Opportunity for

Vehicular Internet Access.

With increasing popularity of media enabled handhelds, the need for high data-

rate services for mobile users is evident. Large-scale Wireless LANs (WLANs) can

provide such a service, but they are expensive to deploy and maintain. Open WLAN

access-points (APs), on the other hand, need no new deployments, but can offer only

opportunistic services with no guarantees on short term throughput. In contrast, a

carefully planned sparse deployment of roadside WiFi provides an economically scalable

infrastructure with quality of service assurance to mobile users. This paper proposes to

study deployment techniques for providing roadside WiFi services. In particular

presented a new metric, called Contact Opportunity, as a characterization of a roadside

WiFi network. Informally, the contact opportunity for a given deployment measures the

fraction of distance or time that a mobile user is in contact with some AP when moving

through a certain path. Such a metric is closely related to the quality of data service that a

mobile user might experience while driving through the system. Then the work presents

an efficient deployment method that maximizes the worst case contact opportunity under

a budget constraint. It further shows how to extend this concept and the deployment

techniques to a more intuitive metric the average throughput by taking various dynamic

elements into account. Simulations over a real road network and experimental results

show that this approach achieves more than 200% higher minimum contact opportunity,

30%-100% higher average contact opportunity and a significantly improved distribution

of average throughput compared with two commonly used algorithms.

[9] F. Malandrino, C. Casetti, C.-F. Chiasserini, M. Fiore, Content Downloading in

Vehicular Networks.

Content downloading in vehicular networks is a topic of increasing interest:

services based upon it are expected to be hugely popular and investments are planned for

wireless roadside infrastructure to support it. The main focus is on content downloading

system leveraging both infrastructure-to-vehicle and vehicle to vehicle communication.

With the goal to maximize the system throughput, a max-flow problem that accounts for

several practical aspects, including channel contention and the data transfer paradigm has

been formulated. Through the study, author identifies the factors that have the largest

impact on the performance and derive guidelines for the design of the vehicular network

and of the roadside infrastructure supporting it.


15/77



[10] G. Marfia, G. Pau, E. Giordano, E. De Sena, M. Gerla, Evaluating vehicle

network strategies for downtown Portland: opportunistic infrastructure and

importance of realistic mobility models.

In an urban environment, vehicles can opportunistically exploit infrastructure

through open Access Points (APs) to efficiently communicate with other vehicles. This is

to avoid long wireless ad hoc paths, and to alleviate congestion in the wireless grid.

Analytic and simulation models are used to optimize the communications and networking

strategies. For realistic results, one important challenge is the accurate representation of

traffic mobility patterns. This paper introduces realistic vehicular mobility traces of

downtown Portland, Oregon, obtained from extremely detailed large scale traffic

simulations performed at the Los Alamos National Laboratories (LANL). To the best of

knowledge, these are among the most accurate synthetic motion traces available for study,

with the exception of actual car trace measurements. The new mobility model is used to

evaluate AODV in flat and opportunistic infrastructure routing. To assess the importance

of a realistic mobility model for this evaluation, these results with those obtained with

CORSIM traces are compared. The paper makes the following contributions: (a)

introduction of efficient, opportunistic strategies for extending the AP infrastructure to

use vehicle to vehicle paths, and (b) assessment of different mobility models - CORSIM

traces and LANLs realistic vehicular traces - in the modeling of different routing

strategies.

[11] Y. Ding, C. Wang, L. Xiao, A Static-Node Assisted Adaptive Routing Protocol

in Vehicular Networks.

Vehicular networks have attracted great interest in the research community

recently, and multi-hop routing becomes an important issue. To improve data delivery

performance, SADV is proposed, which utilizes some static nodes at road intersections in

a completely mobile vehicular network to help relay data. With the assistance of static

nodes at intersections, a packet can be stored in the node for a while and wait until there

are vehicles within communication range along the best delivery path to further forward

the packet, which reduces the overall data delivery delay. In addition, this work let

adjacent nodes measure the delay of forwarding data between each other in real time, so

that the routing decision can adapt to changing vehicle densities. The simulation results

show that SADV outperforms other multi-hop data dissemination protocols, especiallyunder median or low vehicle density where the network is frequently partitioned.


16/77



[12] C. Lochert, B. Scheuermann, C.Wewetzer, A. Luebke, M. Mauve, Data

aggregation and roadside unit placement for vanet traffic information system.

In this paper, the author investigates how a VANET-based traffic information

system can overcome the two key problems of strictly limited bandwidth and minimal

initial deployment.

First, a domain specific aggregation scheme in order to minimize the required

overall bandwidth is presented. Then, a genetic algorithm which is able to identify good

positions for static roadside units in order to cope with the highly partitioned nature of a

VANET in an early deployment stage is proposed. A tailored tool chain allows

optimizing the placement with respect to an application-centric objective function, based

on travel time savings. By means of simulation the performance of the resulting traffic

information system and the optimization strategy is assessed.

[13] Z. Zheng, P. Sinha, S. Kumar, Alpha Coverage: Bounding the Interconnection

Gap for Vehicular Internet Access.

Vehicular Internet access via open WLAN access points (APs) has been

demonstrated to be a feasible solution to provide opportunistic data service to moving

vehicles. Using an in situ deployment, however, such a solution does not provide worst-

case performance guarantees due to unpredictable intermittent connectivity. On the other

hand, a solution that tries to cover every point in an entire road network with APs (full

coverage) is not very practical due to the prohibitive deployment and operational cost.

This paper introduces a new notion of intermittent coverage for mobile users, called -

coverage, which provides worst-case guarantees on the interconnection gap while using

significantly fewer APs than needed for full coverage.

An efficient algorithms to verify whether a given deployment provides -coverage

and approximation algorithms for determining a deployment of APs that will provide -

coverage is proposed. The -coverage with opportunistic access of open WLAN APs

(modeled as a random deployment) via simulations over a real-world road network are

compared and shows that using the same number of APs as random deployment, -

coverage bounds the interconnection gap to a much smaller distance than that in a randomdeployment.


17/77



[14] O. Trullols, M. Fiore, C. Casetti, C.-F.Chiasserini, J.M. Barcelo-Ordinas,

Planning roadside infrastructure for information dissemination in intelligent

transportation systems.

The author considers an intelligent transportation system where a given number of

infrastructure nodes (called Dissemination Points, DPs) have to be deployed for

disseminating information to vehicles in an urban area. Then they formulate the problem

as a Maximum Coverage Problem (MCP) and seek to maximize the number of vehicles

that get in contact with the DPs over the considered area. The MCP is known to be NP-

hard in its standard formulation, therefore through heuristic algorithms it is tackled, which

present in different levels of complexity and require different knowledge on the system.

Next, they have addressed the problem of guaranteeing that a large number of vehicles

travel under the coverage of one or more DPs for a sufficient amount of time.

2.1 OBJECTIVE

The main objective of this work is to download large files using roadside access

points while moving in the vehicle. To achieve the main objective, a complex (i.e.,

nonlinear) road scenario is been considered where users aboard vehicles equipped with

communication interfaces and through extensive simulations it can be shown how carry &

forward transfers can significantly increase the download rate of vehicular users in

urban/suburban environment.

2.2 PROJECT SCOPE

This work covers the concepts and mechanism of large file download in vehicular

network by making use of idle access points. Implementation of this work is carried out in

Java on Windows operating system. MySQL is used for the database to store the files.

2.3 MOTIVATION

The drawbacks of the existing system drove the motivation to a new idea of

downloading of large sized files. The highway scenario is replaced by a urban scenario

and also size of the file to download is big.


18/77



CHAPTER 3

SYSTEM SPECIFICATION & DESIGN


19/77



CHAPTER 3

SYSTEM SPECIFICATION & DESIGN

3.1 FUNCTIONAL REQUIREMENTS

Functional requirements define the internal workings of the software that is, the

technical details, data manipulation and processing and other specific functionality that

show how the use cases are to be satisfied. They are supported by non-functional

requirements, which impose constraints on the design or implementation. In this system

following are the functional requirements:

The tool should be able to generate a network. Any mail can be sent from clients to the server. The message arriving at nodes and leaving from the nodes must be displayed in a

window.

A thread must be ping the server all the time to check for incoming mails.

3.2 NON FUNCTIONAL REQUIREMENTS

Non-functional requirements are requirements which specify criteria that can be

used to judge the operation of a system, rather than specific behaviors. This should be

contrasted with functional requirements that specify specific behavior or functions.

Typical non-functional requirements are reliability, scalability, and cost. Non-

functional requirements are often called the utilities of a system. Other terms for non-

functional requirements are constraints, quality attributes and quality of service

requirements.

Usability

Simple is the key here. The system must be simple that people like to use it, but

not so complex that people avoid using it. The user must be familiar with the user

interfaces and should not have problems in migrating to a new system with a new

environment. The menus, buttons and dialog boxes should be named in a manner that

they provide clear understanding of the functionality.


20/77



Reliability

The system should be trustworthy and reliable in providing the functionalities.

Once a user has made some changes, the changes must be made visible by the system.

The changes made by the Programmer should be visible both to the Project leader as well

as the Test engineer.

Security

Apart from bug tracking the system must provide necessary security and must

secure the whole process from crashing. As technology began to grow in fast rate the

security became the major concern of an organization. Millions of dollars are invested in

providing security.

Bug tracking delivers the maximum security available at the highest performance

rate possible, ensuring that unauthorized users cannot access vital issue information

without permission. Bug tracking system issues different authenticated users their secret

passwords so that there are restricted functionalities for all the users.

Performance

The system is going to be used by many employees simultaneously. Since the

system will be hosted on a single web server with a single database server in the

background, performance becomes a major concern. The system should not succumb

when many users would be using it simultaneously. It should allow fast accessibility to all

of its users. For example, if two test engineers are simultaneously trying to report the

presence of a bug, then there should not be any inconsistency while doing so.

Scalability

The system should be scalable enough to add new functionalities at a later stage.

There should be a common channel, which can accommodate the new functionalities.

Maintainability

The system monitoring and maintenance should be simple and objective in its

approach. There should not be too many jobs running on different machines such that it

gets difficult to monitor whether the jobs are running without errors.


21/77



Portability

The system should be easily portable to another system. This is required when the

web server, which s hosting the system gets stuck due to some problems, which requires

the system to be taken to another system.

Reusability

The system should be divided into such modules that it could be used as a part of

another system without requiring much of work.

3.3 SYSTEM DESIGN

3.3.1 LOGICAL DESIGNDesign for Web Apps encompasses technical and non-technical activities. The

look and feel of content is developed as part of graphic design; the aesthetic layout of the

user interface is created as part of interface design; and the technical structure of the Web

App is modeled as part of architectural and navigational design. This argues that a Web

engineer must design an interface so that it answers three primary questions for the end-

user:

1. Where am I? The interface should (1) provide an indication of the WebApp hasbeen accessed and (2) inform the user of her location in the content.

2. What can I do now? The interface should always help the user understand hiscurrent options- what functions are available, what links are live, what content is

relevant.

3.3.2 DESIGN GOALS

The following are the design goals that are applicable to virtually every Web App

regardless of application domain, size, or complexity.

1. Simplicity2. Consistency3. Identity4. Visual appeal5. Compatibility.


22/77



Design leads to a model that contains the appropriate mix of aesthetics, content,

and technology. The mix will vary depending upon the nature of the Web App, and as a

consequence the design activities that are emphasized will also vary. Use case diagram is

as shown below:

Figure 3.1: Use Case Diagram

3.4 THE JAVA PLATFORM

Java can be used to create two types of programs Applications and Applets. An

application is a program that runs on our Computer under the operating system of that

computer. It is more or less like one creating using C or C++. Javas ability to create

Applets makes it important. An Applet is an application designed to be transmitted over

the Internet and executed by a Javacompatible web browser. An applet is actually a tiny

Java program, dynamically downloaded across the network, just like an image. But the

difference is an intelligent program, not just a media file. It can react to the user input and

dynamically change.

3.4.1 FEATURES OF JAVA SECURITY

Every time you that you download a normal program you are risking a viral

infection. Prior to java, most users did not download executable programs frequently, and

those who did scan them for viruses prior to execution.


23/77



Most users still worried about the possibility of infecting their systems with a

virus. In addition, another type of malicious program exists that must be guarded against.

This type of program can gather private information, such as credit card numbers, bank

account balances, and passwords. Java answers both these concerns by providing a

firewall between a network application and your computer. When you use a java-

compatible web browser, you can safely download java applets without fear of virus

infection or malicious intent.

Portability

For programs to be dynamically downloaded to all the various types of platforms

connected to the internet, some means of generating portable executable code is needed

.as you will see, the same mechanism that helps ensure security also helps create

portability. Indeed, javas solution to these two problems is both elegant and efficient.

The Byte Code

The key that allows the Java to solve the security and portability problems is that

the output of Java compiler is Byte code. Byte code is a highly optimized set of

instructions designed to be executed by the Java run-time system, which is called the Java

Virtual Machine (JVM).

That is, in its standard form, the JVM is an interpreter for byte code. Translating a

Java program into byte code helps makes it much easier to run a program in a wide

variety of environments. The reason is, once the run-time package exists for a given

system, any Java program can run on it. Although Java was designed for interpretation,

there is technically nothing about Java that prevents on-the-fly compilation of byte code

into native code. Sun has just completed its Just In Time (JIT) compiler for byte code.

When the JIT compiler is a part of JVM, it compiles byte code into executable code in

real time, on a piece by piece, demand basis.

It is not possible to compile an entire Java program into executable code all at

once, because Java performs various run-time checks that can be done only at run time.

The JIT compiles code, as it is needed, during execution.


24/77



3.4.2 JAVA VIRTUAL MACHINE (JVM)

Beyond the language, there is the Java virtual machine. The Java virtual machine

is an important element of the Java technology. The virtual machine can be embedded

within a web browser or an operating system.

Once a piece of Java code is loaded onto a machine, it is verified. As part of the

loading process, a class loader is invoked and does byte code verification makes sure that

the code thats has been generated by the compiler will not corrupt the machine that its

loaded on. Byte code verification takes place at the end of the compilation process to

make sure that is all accurate and correct. So byte code verification is integral to the

compiling and executing of Java code.

JAVA .CLASS

Figure 3.2: Development Process Of JAVA Program

Java programming uses to produce byte codes and executes them. The first box

indicates that the Java source code is located in a. Java file that is processed with a Java

compiler called javac. The Java compiler produces a file called a. class file, which

contains the byte code. The .Class file is then loaded across the network or loaded locally

on your machine into the execution environment is the Java virtual machine, which

interprets and executes the byte code.

Java Architecture

Java architecture provides a portable, robust, high performing environment for

development. Java provides portability by compiling the byte codes for the Java Virtual

Machine, which is then interpreted on each platform by the run-time environment. Java is

a dynamic system, able to load code when needed from a machine in the same room oracross the planet.

JAVA SOURCE JAVA BYTE CODE JAVA VM


25/77



Compilation Of Code

When you compile the code, the Java compiler creates machine code (called byte

code) for a hypothetical machine called Java Virtual Machine (JVM). The JVM is

supposed to execute the byte code. The JVM is created for overcoming the issue of

portability.

The code is written and compiled for one machine and interpreted on all

machines. This machine is called Java Virtual Machine.

3.4.3 SOFTWARE ENVIRONMENT

The Java Programming Language

The Java programming language is a high-level language that can be characterized

by all of the following buzzwords: With most programming languages, you either

compile or interpret a program so that you can run it on your computer. The Java

programming language is unusual in that a program is both compiled and interpreted.

With the compiler, first you translate a program into an intermediate language called Java

byte codes, the platform-independent codes interpreted by the interpreter on the Java

platform. The interpreter parses and runs each Java byte code instruction on the computer.

Compilation happens just once; interpretation occurs each time the program is executed.

The following figure illustrates how this works.

Figure 3.3: Execution Process Of JAVA Program

You can think of Java byte codes as the machine code instructions for the Java

Virtual Machine (Java VM). Java byte codes help make write once, run anywhere

possible. You can compile your program into byte codes on any platform that has a Java

compiler.


26/77



The byte codes can then be run on any implementation of the Java VM. That

means that as long as a computer has a Java VM, the same program written in the Java

programming language can run on Windows 2000, a Solaris workstation, or on an iMac.

Figure 3.4: JAVA Program As Platform Independent

A platform is the hardware or software environment in which a program runs, as

already mentioned in some of the most popular platforms like Windows 2000, Linux,

Solaris, and Mac OS (Operating System). Most platforms can be described as a

combination of the operating system and hardware. The Java platform differs from most

other platforms in that its a software-only platform that runs on top of other hardware-

based platforms.

The Java platform has two components:

The Java Virtual Machine (Java VM) The Java Application Programming Interface (Java API)

You have already been introduced to the Java VM. Its the base for the Java

platform and is ported onto various hardware-based platforms. The Java API is a large

collection of ready-made software components that provide many useful capabilities,

such as graphical user interface (GUI) widgets. The Java API is grouped into libraries of

related classes and interfaces; these libraries are known as packages.


27/77



The following figure depicts a program thats running on the Java platform. As the

figure shows, the Java API and the virtual machine insulate the program from the

hardware.

Figure 3.5: Components Of JAVA Platform

Native code is code that after you compile it, the compiled code runs on a specific

hardware platform. As a platform-independent environment, the Java platform can be a

bit slower than native code. However, smart compilers, well-tuned interpreters, and just-

in-time byte code compilers can bring performance close to that of native code without

threatening portability.

3.4.4 OPEN DATABASE CONNECTIVITY (ODBC)

Microsoft Open Database Connectivity (ODBC) is a standard programming

interface for application developers and database systems providers. Before ODBC

became a de facto standard for Windows programs to interface with database system,

programmers had to use proprietary languages for each database they wanted to connect

to. Now, ODBC has made the choice of the database system almost irrelevant from a

coding perspective, which is as it should be.

Application developers have much more important things to worry about than the

syntax that is needed to port their program from one database to another when business

needs sudden change. Through the ODBC Administrator in Control Panel, you can

specify the particular database that is associated with a data source that an ODBC

application program is written to use. Think of an ODBC data source as a door with a

name on it. Each door will lead you to a particular database. For example, the data source

named Sales Figures might be a SQL Server database, whereas the Accounts Payable data

source could refer to an Access database.


28/77



The physical database referred to by a data source can reside anywhere on the

LAN. The ODBC system files are not installed on your system by Windows 95. Rather,

they are installed when you setup a separate database application, such as SQL Server

Client or Visual Basic 4.0. When the ODBC icon is installed in Control Panel, it uses a

file called ODBCINST.DLL.From a programming perspective, the beauty of ODBC is

that the application can be written to use the same set of function calls to interface with

any data source, regardless of the database vendor. The source code of the application

doesnt change whether it talks to Oracle or SQL Server. There are ODBC drivers

available for several dozen popular database systems. Even Excel spreadsheets and plain

text files can be turned into data sources. The operating system uses the Registry

information written by ODBC Administrator to determine which low-level ODBC drivers

are needed to talk to the data source (such as the interface to Oracle or SQL Server). The

loading of the ODBC drivers is transparent to the ODBC application program.

In a client/server environment, the ODBC API even handles many of the network

issues for the application programmer. The advantages of this scheme are so numerous

that you are probably thinking there must be some catch. The only disadvantage of

ODBC is that it isnt as efficient as talking directly to the native database interface.

ODBC has had many detractors make the charge that it is too slow. Microsoft has alwaysclaimed that the critical factor in performance is the quality of the driver software that is

used. In our humble opinion, this is true. The availability of good ODBC drivers has

improved a great deal recently. And anyway, the criticism about performance is

somewhat analogous to those who said that compilers would never match the speed of

pure assembly language. Maybe not, but the compiler (or ODBC) gives you the

opportunity to write cleaner programs, which means you finish sooner. Meanwhile,

computers get faster every year.

3.4.5 JAVA DATABASE CONNECTIVITY (JDBC)

It provides uniform access to a wide range of relational databases. The Java

platform also has APIs for 2D and 3D graphics, accessibility, servers, collaboration,

telephony, speech, animation, and more. The following figure depicts what is included in

the Java 2 SDK. In an effort to set an independent database standard API for Java; Sun

Microsystems developed Java Database Connectivity, or JDBC.


29/77



JDBC offers a generic SQL database access mechanism that provides a consistent

interface to a variety of RDBMSs.

Figure 3.6: Java Database Connectivity (JDBC)

This consistent interface is achieved through the use of plug-in database

connectivity modules, or drivers. If a database vendor wishes to have JDBC support, he

or she must provide the driver for each platform that the database and Java run on. To

gain a wider acceptance of JDBC, Sun based JDBCs framework on ODBC. ODBC has

widespread support on a variety of platforms. Basing JDBC on ODBC will allow vendors

to bring JDBC drivers to market much faster than developing a completely new

connectivity solution. JDBC was announced in March of 1996. It was released for a 90

day public review that ended June 8, 1996. Because of user input, the final JDBC v1.0

specification was released soon after. The remainder of this section will cover enough

information about JDBC for you to know what it is about and how to use it effectively.

This is by no means a complete overview of JDBC. That would fill an entire book.

JDBC Goals

Few software packages are designed without goals in mind. JDBC is one that,

because of its many goals, drove the development of the API.


30/77



These goals, in conjunction with early reviewer feedback, have finalized the

JDBC class library into a solid framework for building database applications in Java. The

goals that were set for JDBC are important. They will give you some insight as to why

certain classes and functionalities behave the way they do. The seven Design Goals for

JDBC are as follows:

1. SQL Level APIThe designers felt that their main goal was to define a SQL interface for Java.

Although not the lowest database interface level possible, it is at a low enough

level for higher-level tools and APIs to be created. Conversely, it is at a high

enough level for application programmers to use it confidently. Reaching this goal

allows future tool vendors to generate JDBC code and to hide many of JDBCs

complexities from the end user.

2. SQL ConformanceSQL syntax varies as you move from database vendor to database vendor. In an

effort to support a wide variety of vendors, JDBC will allow any query statement

to be passed through it to the underlying database driver. This allows the

connectivity module to handle non-standard functionality in a manner that is

suitable for its users.

3. JDBC must be implemental on top of common database interfacesThe JDBC SQL API must sit on top of other common SQL level APIs. This

goal allows JDBC to use existing ODBC level drivers by the use of a software

interface. This interface would translate JDBC calls to ODBC and vice versa.

4. Provides a Java interface that is consistent with the rest of the Java system Because of Javas acceptance in the user community thus far, the designers feel

that they should not stray from the current design of the core Java system.

5. Keep it simpleThis goal probably appears in all software design goal listings. JDBC is no

exception. Sun felt that the design of JDBC should be very simple, allowing foronly one method of completing a task per mechanism. Allowing duplicate


31/77



functionality only serves to confuse the users of the API.

6. Use strong, static typing wherever possibleStrong typing allows for more error checking to be done at compile time; also,

less error appear at runtime.

7. Keep the common cases simpleBecause more often than not, the usual SQL calls used by the programmer are

simple SELECTs, INSERTs, DELETEs and UPDATEs, these queries should

be simple to perform with JDBC. However, more complex SQL statements should

also be possible.

Figure 3.7: Java Compiler And Interpreter

Java is also unusual in that each Java program is both compiled andinterpreted.

With a compile you translate a Java program into an intermediate language called Java

byte codes the platform-independent code instruction is passed and run on the computer.

3.5 NETWORKING: TCP/IP PROTOCOL STACK

The TCP/IP stack is shorter than the OSI model. TCP is a connection-oriented protocol;

UDP (User Datagram Protocol) is a connectionless protocol and unreliable. What it adds

to IP is a checksum for the contents of the datagram and port numbers. These are used to

give a client/server model.

Java

Compilers

Interpreter

My Program


32/77



TCP supplies logic to give a reliable connection-oriented protocol above IP. It

provides a virtual circuit that two processes can use to communicate.

Figure 3.8: TCP/IP Stack

IP Datagram

The IP layer provides a connectionless and unreliable delivery system. It considers

each datagram independently of the others. Any association between datagram must be

supplied by the higher layers. The IP layer supplies a checksum that includes its own

header. The header includes the source and destination addresses. The IP layer handles

routing through an Internet. It is also responsible for breaking up large datagram into

smaller ones for transmission and reassembling them at the other end.

Internet Address

In order to use a service, you must be able to find it. The Internet uses an address

scheme for machines so that they can be located.

The address is a 32 bit integer which gives the IP address. This encodes a network

ID and more addressing. The network ID falls into various classes according to the size of

the network address.


33/77



Network Address

Class A uses 8 bits for the network address with 24 bits left over for other

addressing. Class B uses 16 bit network addressing. Class C uses 24 bit network

addressing and class D uses all 32.

Subnet Address

Internally, the UNIX network is divided into sub networks. Building 11 is

currently on one sub network and uses 10-bit addressing, allowing 1024 different hosts.

Host Address

8 bits are finally used for host addresses within our subnet. This places a limit of

256 machines that can be on the subnet. The 32 bit address is usually written as 4 integers

separated by dots.

Figure 3.9: Total Address

Port Addresses

A service exists on a host, and is identified by its port. This is a 16 bit number. To

send a message to a server, you send it to the port for that service of the host that it is

running on. This is not location transparency! Certain of these ports are "well known".

Sockets

A socket is a data structure maintained by the system to handle network

connections.


34/77



A socket is created using the call socket. It returns an integer that is like a file

descriptor. In fact, under Windows, this handle can be used with Read File and Write File

functions.

#include

#include

int socket(int family, int type, int protocol);

Here "family" will be AF_INET for IP communications, protocol will be zero, and

type will depend on whether TCP or UDP is used. Two processes wishing to

communicate over a network create a socket each. These are similar to two ends of a pipe

but the actual pipe does not yet exist.

3.6 MYSQL

3.6.1 INTRODUCTION

MySql is a relational database management system, which organizes data in the

form of tables. MySQL is one of many databases servers based on RDBMS model, which

manages a seer of data that attends three specific things-data structures, data integrity and

data manipulation. MySQL cooperative server technology realizes the benefits of open,

relational systems for all the applications. MySQL makes efficient use of all systems

resources, on all hardware architecture; to deliver unmatched performance, price

performance and scalability. Any DBMS to be called as RDBMS has to satisfy

Dr.E.F.Codds rules.

3.6.2 DISTINCT FEATURES OF MYSQL

1. PortableThe MySQL RDBMS is available on wide range of platforms ranging from PCs to

super computers and as a multi user loadable module for Novel NetWare, if you

develop application on system you can run the same application on other systems

without any modifications.

2. CompatibleMySQL commands can be used for communicating with IBM DB2 mainframe

RDBMS that is different from MySQL that is MySQL compatible with DB2.


35/77



MySQL RDBMS is a high performance fault tolerant DBMS , which is specially

designed for online transaction processing and for handling large database

applications.

3. Multithreaded Server ArchitectureMySQL adaptable multithreaded server architecture delivers scalable high

performance for very large number of users on all hardware architecture including

symmetric multiprocessors (sumps) and loosely coupled multiprocessors.

Performance is achieved by eliminating CPU, I/O, memory and operating system

bottlenecks and by optimizing the MySQL DBMS server code to eliminate all

internal bottlenecks.

Other Features

Client/server architecture. Data independence. Ensuring data integrity and data security. Managing data concurrency. Parallel processing support for speed up data entry and online transaction

processing used for applications.

DB procedures, functions and packages.

3.6.3 Dr. E. F. OCDDs RULES

These rules are used for valuating a product to be called as relational database

management systems. Out of 12 rules, a RDBMS product should satisfy at least 8 rules

+rule called rule 0 that must be satisfied.

Rule 0: Foundation Rule

For any system that is to be advertised or claimed to be relational DBMS. That

system should manage database with in self, without using an external language.

Rule 1: Information Rule

All information in relational database is represented at logical level in only oneway as values in tables.


36/77



Rule 2: Guaranteed Access

Each and every data in a relational database is guaranteed to be logically

accessibility by using to a combination of table name, primary key value and

column name.Rule 3: Systematic Treatment Of Null Values

Null values are supported for representing missing information and inapplicable

information. They must be handled in systematic way, independent of data types.

Rule 4: Dynamic Online Catalog Based Relation Model

The database description is represented at the logical level in the same way as

ordinary data so that authorized users can apply the same relational language to its

interrogation as they do to the regular data.

Rule 5: Comprehensive Data Sub - Language

A relational system may support several languages and various models of terminal

use. However there must be one language whose statement can express Data

Definitions, View Definitions, Data Manipulations, Integrity, Constraints,

authorization and transaction boundaries.

Rule 6: View Updating

Any view that is theoretically updatable iff changes can be made to the tables that

affect the desired changes in the view.

Rule 7: High Level Update, Insert and Delete

The capability of handling a base relational or derived relational as a single

operand applies not only retrieval of data also to its insertion, updating, and

deletion.

Rule 8: Physical Data Independence

Application program and terminal activities remain logically unimpaired

whenever any changes are made in either storage representation or access method.


37/77



Rule 9: Logical Data Independence

Application programs and terminal activities remain logically unimpaired

whenever any changes are made in either storage repres3entation or access

methods.

Rule 10: Integrity Independence

Integrity constraints specific to particular database must be definable in the

relational data stored in the catalog, not in application program.

Rule 11: Distributed Independence

Whether or not, a system supports data base distribution, it must have a data sub-

language that can support distributed databases without changing the application

program.

Rule 12: Non Sub-Version

If a relational system has low level language, that low language cannot use to

subversion or by pass the integrity rules and constraints expressed in the higher

level relational language.

MYSQL SUPPORTS THE FOLLOWING CODDS RULES:

Rule 1: Information Rule (Representation of information)-YES.

Rule 2: Guaranteed Access-YES.

Rule 3: Systematic treatment of Null values-YES.

Rule 4: Dynamic on-line catalog-based Relational Model-YES.

Rule 5: Comprehensive data sub language-YES.

Rule 6: View Updating-PARTIAL.

Rule 7: High-level Update, Insert and Delete-YES.

Rule 8: Physical data Independence-PARTIAL.

Rule 9: Logical data Independence-PARTIAL.


38/77



Rule 10: Integrity Independence-PARTIAL.

Rule 11: Distributed Independence-YES.

Rule 12: Non-subversion-YES.

3.7 DESIGN CONSTRAINT

Hardware Requirements

System : Pentium IV 2.4 GHz.

Hard Disk : 40 GB.

Floppy Drive : 1.44 Mb.

Monitor : 15 VGA Color.

Mouse : Logitech.

Ram : 512 MB.

Software Requirements

Operating system : Windows XP Professional.

Coding Language : Java (Jdk 1.6) with Swings

Data Base : My-SQL 5.0


39/77



CHAPTER 4

SYSTEM ANALYSIS


40/77



CHAPTER 4

SYSTEM ANALYSIS

4.1 INTRODUCTION TO SYSTEM ANALYSIS

System

A system is an orderly group of interdependent components linked together

according to a plan to achieve a specific objective. Its main characteristics are

organization, interaction, interdependence, integration and a central objective.

Analysis

Analysis is a detailed study of the various operations performed by a system and

their relationships within and outside of the system. One aspect of analysis is defining the

boundaries of the system and determining whether or not a candidate system should

consider other related systems. During analysis data are collected on the available files

decision points and transactions handled by the present system. This involves gathering

information and using structured tools for analysis.

System Analysis

System analysis and design are the application of the system approach to problem

solving generally using computers. To reconstruct a system, the analyst must consider its

elements output and inputs, processors, controls, feedbacks and environment.

4.2 PROBLEM STATEMENT

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 vehicle 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 onboard communication

capabilities will also determine a significant increase in the number of mobile users

regularly employing business and infotainment applications during their displacements.


41/77



As a matter of fact, equipping vehicles with WiMAX/LTE and/or WiFi

capabilities 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.

4.3 PROPOSED SYSTEM

In this system, the focus is on of the latter tasks, namely the download of large-

sized files from the Internet. More precisely, an urban scenario is considered, where users

aboard cars can exploit roadside Access Points (APs) to access the servers that host the

desired contents.

Here, the coverage provided by the roadside APs is intermittent: this is often the

case, since, in presence of large urban, suburban and rural areas, a pervasive deployment

of APs dedicated to vehicular access is often impractical, for economic and technical

reasons. It is also assumed that not all on-board users download large files all the time:

indeed, one can expect a behavior similar to that observed in wired networks, where the

portion of queries for large contents is small. As a result, only a minor percentage of APs

is simultaneously involved in direct data transfers to downloader cars in their respective

coverage area, and the majority of APs is instead idle.

Within such a context, how opportunistic vehicle-to vehicle communication can

complement the infrastructure-based connectivity, so to speed up the download process is

also studied. The concept of cooperative download in vehicular networks has been

already proposed for highway environments: however, unlike what happens over one-

dimensional highways, urban/suburban road topologies present multiple route choices

that make it hard to predict if vehicles will meet; moreover, the presence of traffic lights,

stop and yield signs renders cars contact timings very variable.

These key aspects make highway-tailored solutions impracticable in complex

nonlinear road scenarios, for which, first to identify challenges and propose solutions

using figure 4.1.


42/77



In the following diagram vehicle a downloads part of some content from AP A.

The idle AP B delegates another portion of the same content to a vehicle b. When b

encounters a vehicle to vehicle communication is employed to transfer to a the data

carriedby b.

Figure 4.1: Architecture

4.4 CASE STUDY

Case 1:If Downloading Vehicle is within the transmission range of Access point A and

Requested File is small.

The requested file will be completely downloaded from Access point A alone.

Case 2: If Downloading Vehicle is in Transmission range of Access Point A and

Requested File is big.

The Access point calculate the time that vehicle a presence in the transmission

range. For that time period how much file can be download will be calculated and it will

start downloading the file. The remaining file download is forwarded to the second

Access Point i.e. AP B. The Access point B will repeat the calculation and start

downloading the remaining file into the vehicle which is heading towards veh icle a.

Once vehicle b meets the vehicle a it starts to transfer the file to vehicle a. In vehiclea, it will be merged and user will get the merged file i.e., the full file.


43/77



Case 3: If Downloading Vehicle is out of Transmission range of Access Point A

The download request will be rejected since the vehicle is out of transmission

range of the access point and it will not process the request. Hence there will not be any

downloading.

Figure 4.2: Data Flow Diagram

Case 1 can be explained using the above data flow diagram which explains

complete flow. A feasibility check is done by the Access Point. This check includes,

determining size of the file, bandwidth calculation and transmission range checks. If the

result is pass, file will downloaded using single Access Point. Otherwise, case 2 will

come into picture.


44/77



The Sequence Diagram for case 1 is as shown below:

Figure 4.3: Sequence Diagram Of Case 1


45/77



The Sequence Diagram for case 2 is as shown below:

Figure 4.4: Sequence Diagram Of Case 2 (First Part)


46/77



The Sequence Diagram of second part of case 2 is as shown below which explains

merging of files.

Figure 4.5: Sequence Diagram Of Case 2 (Second Part)


47/77



4.5 FEASIBILITY STUDY

Feasibility is the determination of whether or not a project is worth doing. The

process followed in making this determination is called feasibility study. This type of

study, a project can and should be taken. In the conduct of the feasibility study, the

analyst will usually consider seven distinct, but inter-related types of feasibility.

Technical Feasibility

This is considered with specifying equipment and software that will successful satisfy

the user requirement the technical needs of the system may vary considerably but might

include

1. The facility to produce outputs in a given time.2. Response time under certain conditions.3. Ability to process a certain column of transaction at a particular speed.

Economic Feasibility

Economic analysis is the most frequently used technique for evaluating the

effectiveness of a proposed system. More commonly known as cost / benefit analysis.

The procedure is to determine the benefits and savings are expected form a proposed

system and a compare them with costs. It benefits outweigh costs; a decision is taken to

design and implement the system will have to be made if it is to have a chance of being

approved. There is an ongoing effort that improves in accuracy at each phase of the

system life cycle.

Operational FeasibilityIt is mainly related to human organization and political aspects. These points are

considered are:

1. What changes will be brought with the system?2. Wh

Documents

Final New Report