Providing Software as a Service to VANET under Cloud Environment

VANET with Cloud

Master's Thesis , 2014 , 124 Pages

Engineering - Computer Engineering

Vehicular Ad-hoc network (VANET) is an emerging technology for roadside communication used by intelligent transportation system (ITS) as well as subclass of MANET where nodes are arranged in an ad-hoc manner and strictly follow traffic rules. VANET is aimed at improving the safety and
efficiency of transportation and deliver timely information to drivers in a cost-effective manner using V2V (Vehicle to Vehicle) and V2I (Vehicle to infrastructure) communication. V2I communication is sometimes too costly, sometimes short lived links in hat case; Vehicle-to-Vehicle communications are effective for enabling VC (Vehicular Cloud) services. In this project, we are provide the vehicular cloud services such as NaaS (Network as a Service) and SaaS (Storage as a Service) by considering the Dynamic vehicular cloud and Static Vehicular cloud, respectively based on the framework of VANET, and propose a novel approach for utilization of resources in a cloud environment.

INDEX

ACKNOWLEDGEMENT

LIST OF FIGURES

LIST OF TABLES

SYNOPSYS

1 Introduction
1.1 Introduction of project topic
1.2 Dissertation Idea
1.3 Motivation of dissertation
1.4 Literature survey
1.4.1 Background Work
1.4.2 Overview of MANET
1.4.3 Overview of VANET
1.4.4 Application Scenario of VANET
1.4.5 Challenges of VANET
1.4.6 Architecture of VANETs
1.4.7 Cloud Computing and Mobile Cloud Computing
1.4.8 Mobile Cloud Computing Architecture:
1.4.9 Vehicular Cloud Computing

2 Problem Definition and Scope
2.1 Problem Statement
2.2 Description of problem
2.3 Goals and Objectives
2.4 Statement of scope
2.5 Software context
2.6 Tool Used
2.7 Hardware Resources Required
2.8 Software resources required
2.9 Area of Dissertation

3 Dissertation Plan
3.1 Problem Definition
3.2 Dissertation Resources
3.2.1 Software Requirements
3.3 Dissertation Tasks
3.4 Dissertation Schedule

4 Software Requirement Specification
4.1 Purpose and Scope of the Document
4.2 Usage Scenario
4.2.1 Use-cases
4.2.2 Use Case View
4.3 Functional Model and Description
4.4 External System Interfaces
4.4.1 Hardware Interfaces
4.4.2 Software Interfaces
4.4.3 User Interfaces
4.5 Non Functional Requirements
4.5.1 Performance Requirements
4.5.2 Safety Requirements
4.5.3 Security Requirements
4.5.4 Software Quality Attributes

5 High level design document
5.1 Introduction
5.2 Purpose of the Document
5.3 System Design
5.3.1 System Architecture
5.3.2 Design Modules
5.3.3 Working Model
5.4 General Setting
5.4.1 Road Types
5.4.2 Traffic Light Logic
5.4.3 Stop Signs
5.4.4 Vehicle Characteristics
5.4.5 Notable Differences from Previous Research
5.5 Scenarios
5.5.1 Accident
5.5.2 Random
5.5.3 Hurricane
5.6 Implementation
5.6.1 Implementation of MAP
5.6.2 Information Computation
5.6.3 Lane-to-Lane Relationship Computation
5.6.4 Analysis of Traffic Condition of Vehicles
5.6.5 Broadcasting of Each Vehicles
5.6.6 Working of TLS logic and Detector
5.6.7 Evaluation of Simulation Result

6 Test Specification
6.1 Goal and Objectives
6.2 Statement of Scope
6.3 Test Plan
6.3.1 Testing Strategy
6.3.2 Unit Testing
6.3.3 Integration Testing
6.3.4 Validation Testing
6.4 Black Box Testing
6.5 White Box Testing
6.6 Test Cases

7 System Analysis and Results
7.1 Performance Metrics
7.2 Performance Analysis
7.2.1 Simulation Environment
7.3 Result and Discussion

8 Summary and Conclusion

9 Future Enhancement

Annexure A

Annexure B

Annexure C

Annexure D

Annexure E

Annexure F

Annexure G

Annexure H

Annexure I

References

List of Figures

1.1 Vehicular Ad Hoc Networks

1.2 RSU extends communication range

1.3 RSU acts as information source

1.4 RSU providing internet access

1.5 Vehicular Networking: Applications and Requirements

1.6 Mobile Cloud Computing Architecture

1.7 Taxonomy of Vehicular Cloud Computing

2.1 SUMO GUI

3.1 Timeline Chart for the Dissertation

4.1 Use Case Diagram

4.2 Class Diagram

4.3 Activity Diagram

5.1 Proposed System: Vehicular Cloud

5.2 Detailed Design Modules of System

5.3 Working Model of System

5.4 Accident scenario

5.5 Random scenario road network

5.6 Two sets of rather complicated junctions as computed

5.7 The resulting order of edges after sorting

5.8 Edge Priority

5.9 Connections from lanes to edges

5.10 Lane Lane Connection at Junction

5.11 Pune city Map generated by NETCONVERT

5.12 Broadcasting of Each Vehicle

5.13 TLS Logic with Detector fix on edges

5.14 Starting of Simulation

5.15 Pune City

5.16 Each Vehicle are follows Traffic Rule

6.1 Project Testing Strategy

7.1 Providing of Software as a Service in VANET under Cloud Environment

7.2 Results on Random Detector A

7.3 Time Vs. Speed Graph for Random Detector A

7.4 Results on Random Detector B

7.5 Time Vs. Speed Graph for Random Detector B

7.6 Area wise Traffic

7.7 Traffic on FC Road

7.8 Time Vs. Speed Graph: Traffic on FC Road

7.21 Time Vs. Speed Graph for CAR Vehicle

7.9 Traffic on Hadapsar

7.10 Time Vs. Speed Graph: Traffic on Hadapsar Road

7.11 Traffic on JM Road

7.12 Time Vs. Speed Graph: Traffic on JM Road

7.13 Traffic on Kothrud Road

7.14 Time Vs. Speed Graph: Traffic on Kothrud Road

7.15 Traffic on KP Road

7.16 Time Vs. Speed Graph: Traffic on KP Road

7.17 Traffic on Shanivarwada Road

7.18 Time Vs. Speed Graph: Traffic on Shanivarwada Road

7.19 Location of Vehicles as per coordinates

7.22 Time Vs. Speed Graph for Passenger/Wagon Vehicle

7.23 Time Vs. Speed Graph for BUS Vehicle

7.24 Location Find out of Passenger Vehicle

7.25 Time Vs. Speed Graph For passenger Vehicle

List of Tables

1.Plan of Dissertation Execution

1.1 Main characteristics of mobile and vehicular ad-hoc networks

3.1 Dissertation Tasks

5.1 Road Types

5.2 Traffic Light Logic

5.3 Vehicle Characteristics

5.4 Attribute for Track the vehicle in Network

5.5 Attributes for Induction Loop

5.6 Attributes for Emission measure

6.1 Black Box Testing

7.1 Simulation Configuration

SYNOPSIS

Dissertation Title: Providing Software as a Service in VANET Using Cloud Environment.

Internal Guide: Prof. Uma Nagaraj

Technical Keywords:

Vehicular ad hoc network (VANET) Road safety, Road Traffic

Cloud Environment Internet

Cloud Services Reroute

Relevant mathematics associated with the Dissertation:

Refer Annexure A

International conference/Journal papers published:

International Journals:

1) Paper Published in International Journal in Advance Research in Computer Science and Software Engineering (IJARCSSE), Volume 3. No.11 NOV 2013 ISSN No- 2277 128X. On topic Shifting VANET to Cloud Survey Impact factor: 2.08.

2) Paper published in International Journal of Advanced Technology Engineering Research (IJATER), Dec 2013, ISSN No- 2250 3536. On Topic: Novel Approach Towards Accident Prevention Using Vehicular Ad Hoc Network Under Cloud Environment Impact factor 0.56

International Conferences:

1. Paper presented uploaded on IEEE XPLORER ISBN No- 978-1-4799-3759-2. On topic Motivation Towards Cost Effective Roadside Communication Techniques Vehicular Cloud Environment.

2. Paper presented and Published in Proceedings of Elsevier Science and Technology, ISBN No: 978-93-5107-220-1, Volume 2. On topic Accident Prevention and Air Pollution Control using VANET under Cloud Environment.

c-PGCON 2014 Details

1. Paper accepted for Elsevier Proceeding Publication. On Topic: Providing Software as a

Service in VANET using Cloud Environment.

2. Presented Paper in an Computers Post Graduate Conference (cPGCON), Matoshri COE,University of Pune, March 2014. Topic: Providing Software as a Service in VANET using Cloud Envi-ronment.

Poster Presentation

1. Pune University Level Poster Presentation for Post PG level Avishkar 2013 Topic : Taking VANET to the Cloud.

Review of Conference/Journal Papers supporting dissertation idea:

1. Saif Al-Sultan, MoathM. Al-Doori, AliH. Al-Bayatti, Hussien Zedan, A comprehensive sur-vey on vehicular Ad Hoc network, Journal of Network and Computer Applications 37 (2014) 380392.

This paper provides a comprehensive survey dealing with all the issues facing VANET, in par-ticular, VANET architectures components, VANET communication domains, wireless access technologies, VANET characteristics, challenges and requirements, VANET applications and simulation tools. This investigation enables researchers to focus on the issues surrounding VANET and its applications, showing great deal of understanding of how to tackle all issues related to VANET, At last it can provide detail review of simulation tool.

Limitation:

In this paper macroscopic and microscopic models of VANET are not discussed.

2. Atta ur Rehman Khan, Mazliza Othman, Sajjad Ahmad Madani, A Survey of Mobile Cloud Computing Application Models, IEEE COMMUNICATIONS SURVEYS TUTORIALS, 2014

Author proposes the different characteristic of Cloud Computing and Mobile Cloud Computing, represent the new architecture of cloud computing environment. The mobile cloud application models that are based on augmented execution of the smart phone clone in the cloud require synchronization of the smart phone and the clone. Therefore, new synchronization policies are required that can perform timely synchronization, taking into account accuracy, execution delay, and bandwidth utilization last explain The mobile cloud execution platforms need to be standardized to ease computation offloading to the mobile cloud platforms. Also, new energy consumption models are required to facilitate accurate decision making by considering the main entities involved in the offloading process.

Limitation:

In this paper synchronization, delays with respect to particular factor in mobile devices are not addressed properly.

3. Qiang Duan, Yuhong Yan, and Athanasios V. Vasilakos , A Survey on Service-Oriented Net-work Virtualization Toward Convergence of Networking and Cloud Computing, IEEE TRANSACTIONS ON NETWORK AND SERVICE MANAGEMENT, Dec 2012

In this paper, author propose the concept of networking with Cloud computing , Network virtualization is being adopted in both telecommunications and the Internet as a key attribute for the next generation networking. Virtualization, as a potential enabler of profound changes in both communications and computing domains, is expected to bridge the gap between these two fields. Service-Oriented Architecture (SOA), when applied in network virtualization, en-ables a Network-as-a-Service (NaaS) paradigm that may greatly facilitate the convergence of networking and Cloud computing.

Limitation:

In this paper just put the basic idea about networking with Cloud, but how to bridge gap between these two fields are not addressed.

4. Md Whaiduzzaman, Mehdi Sookhak , Abdullah Gani, Rajkumar Buyya, A survey on vehicular cloud computing, Journal of Network and Computer Applications.

This paper presents the state-of-the-art survey of vehicular cloud computing. Moreover, present

a Taxonomy for vehicular cloud in which special attention has been devoted to the extensive applications, cloud formations, key management, inter cloud communication systems, and broad aspects of privacy and security issues. itemize the properties required in vehicular cloud that support this model. Compare this mechanism with normal Cloud Computing(CC) and discuss open research issues and future directions.

Limitation:

In this paper, author did survey of VANET but actual implementation VANET are not consid-ered while This paper mainly focus on static cloud.

5. Olariu S, Khalil I, Abuelela M. Taking VANET to the clouds, International Journal of Perva-sive Computing and Communications. 2011; 7: 7- 21.

This Paper puts forth a novel vision namely Vehicular Cloud Computing VC2, the underutilized vehicles resources such as computing power, Internet Connectivity and storage can be shared between drivers or rented like usual cloud resources are.

Limitation:

– Security and privacy are always the two main concerns when allowing multiple users to share same set of resources.

6. Khaleel Mershad, and Hassan Artail, ”Finding a STAR in a Vehicular Network”, IEEE In-telligent transportation systems magazine, pp. 55-68, 2013.

Design a System that enables vehicles in a VANET to search for mobile cloud servers that are moving nearby and discover their services and resources. Transportation server STAR is nothing but Mobile cloud server . Consider several parameters , such as the resources of STAR processing power, transmission range, speed.

Limitations:

– It is not possible to maintain the list of all nodes, replicas in VANET.

7. Md Ali Al Mamun, Khairul Anam, Md Fakhrul Alam Onik, A M Esfar- E- Alam , Deployment of Cloud Computing into VANET to Create Ad Hoc Cloud Network Architecture Proceedings of the World Congress on Engineering and Computer Science 2012 Vol I WCECS 2012, October 24-26, 2012, San Francisco, USA.

In the VANET, cloud computing can be used as a Network as a Service (Naas) or Storage as a Service (SaaS). Not all the cars on the road have internet access. In Naas, the car with access to internet can offer its excess capacity to the other cars in the VANET upon request. For, SaaS, the vehicles with ample storage capacity share storage with other vehicles which need storage capacity for temporary application. The main focus will be SaaS.

Limitations:

– Mobility of the nodes, Signal Fading, Network Scalability

8. T.W. Chim , S.M. Yiu, Lucas C.K. Hui , Victor O.K. Li, VANET-based secure taxi service, Ad Hoc Networks Elsevier, Nov 2011.

In this paper, based on the framework of VANET (Vehicular Ad-hoc Network) and propose a novel secure taxi service scheme. Propose design a cooperative tracking mechanism to locate

a taxi in case of emergency. In some occasions, taxi passengers as well as taxi drivers are concerned with their privacy (such as traveling route). The taxis OBU uses pseudo identities instead of real identity for all ongoing transmissions so that a passengers traveling route (or the drivers traveling route when he/she is not carrying any passengers) cannot be traced by a third party easily.

Limitations:

– Mobility of the nodes, how to maintain connections and communication exactly is not given.

9. Josiane Nzouonta, Neeraj Rajgure, Guiling (Grace) Wang VANET Routing on City Roads Us-ing Real-Time Vehicular Traffic Information. IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 58, NO. 7, Sept 2009

This paper propose the routing scheme in VANET to find out the shortest path between source and destination, and propose paper presents a class of routing protocols called road-based using vehicular traffic (RBVT) routing, which outperforms existing routing protocols in city-based vehicular ad hoc networks (VANETs). And lastly present real-time vehicular traffic information to create road-based paths consisting of successions of road intersections that have, with high probability, network connectivity among them. Geographical forwarding is used to transfer packets between intersections on the path, reducing the paths sensitivity to individual node movements. For dense networks with high contention, we optimize the forwarding using a distributed receiver-based election of next hops based on a multi criterion prioritization function that takes non-uniform radio propagation into account.

Limitations:

– In this paper author working on only microscopic VANET not considered macroscopic.

10. Michele Rondinone , Julen Maneros, iTETRIS: A modular simulation platform for the large scale evaluation of cooperative ITS applications, Simulation Modelling Practice and Theory Elsevier, Sept 2013

This paper propose Cooperative ITS systems are expected to improve road traffic safety and efficiency, and provide infotainment services on the move, through the dynamic exchange of messages between vehicles, and between vehicles and infrastructure nodes. For implementation of VANET they can used iTETRIS simulation platform. iTETRIS is a unique open source simulation platform characterized by a modular architecture that allows integrating two widely adopted traffic and wireless simulator.

Limitations:

– In this paper they put one new simulation iTETRIS, but that is not available in market uptil now.

11. Razvan Stanica , Emmanuel Chaput, Andr-Luc Beylot, “Simulation of vehicular ad-hoc net-works: Challenges, review of tools and recommendations”, Computer Networks Elsevier, 2011.

This paper gives overall idea for available tool in VANET simulation as well as propose the idea for Microscopic model, macroscopic model of VANET, provide limitation of VANET in Field work.

Limitations:

– In this paper they mainly used traffic simulator SUMO and implement VANET but still limitation of VANET such as node velocity, resources inside vehicles are are not ad-dressed.

12. Daniel Krajzewicz, Jakob Erdmann, Michael Behrisch, and Laura Bieker Recent Development and Applications of SUMO - Simulation of Urban Mobility., International Journal On Ad-vances in Systems and Measurements, Dec 2012.

Propose SUMO is an open source traffic simulation package including the simulation appli cation itself as well as supporting tools, mainly for network import and demand modeling.

SUMO helps to investigate a large variety of research topics, mainly in the context of traffic management and vehicular communications. They mainly target on increasing the simulations validity as well as the number of situations. It can support geographic area as well as support microscopic and macroscopic model.

Limitations:

did not provide any means to examine impacts a single vehicle had on the traffic network and the flow of other vehicles through the network.

Plan of Dissertation Execution:

Following table 1 shows the plan of dissertation followed throughout the year:

Problem Statement:

To Find unused resources of vehicle and provide software as a service such as network as a service and storage as a service in vehicular ad-hoc network (VANET) under cloud environments. Means, Give cloud appearance to VANET.

Objectives:

1) To create Vehicular Cloud and provide different services such as NaaS, SaaS using vehicles. To Provide real time traffic conditions of road. (Current Traffic info)

2) To find at a particular time how much traffic was there at a particular position or locations. (Past Traffic info.)

3) To provide noise and pollution information.

4) To trace of all vehicles and its geographic location.

5) To trace particular vehicle and its route of whole journey.

Abbildung in dieser Leseprobe nicht enthalten

Table 1: Plan of Dissertation Execution

Abbildung in dieser Leseprobe nicht enthalten

Chapter 1 Introduction

1.1 Introduction of project topic

India has a larger density of vehicles on a road and has the highest number of road accidents all over the world. India loses $20 billion due to road accidents More than 1.2 million victims every year all over the India, car accidents are the leading cause of death for humans aged between 1 and 34. Tens of millions of people are injured or disabled every year. Every hour, 40 people under the age of 25 die in road accidents around the globe. Children, pedestrians, cyclists and the elderly are among the most vulnerable of road users, therefore, road traffic safety remains a big concern in our daily life. Vehicular transportation is one of the all -important means of shipping around the India from last decade [1].

Mobile ad-hoc network (MANET) is ad-hoc networks, which decentralized infrastructure, wire-less nodes are continuously exchanging the position randomly. VANET is a subclass of MANET, uses moving cars, buses, cabs, trucks, and so forth as a node to create an ad-hoc network. The front of a node is strictly depends on or confined due to some constituents such as traffic and its associated regulations. Because of restrictions it is necessary to implement communication unit on fixed infrastructure which will aid to road side vehicles for providing refuge and comfort to passengers. VANET supports two types of communications such as Vehicle to Vehicle communication (V2V), where each vehicle communicates with each other through an on board unit (OBU) which is available in each vehicle. Another is the vehicle to fixed Infrastructure (V2I) in which each vehicle is communicate with a fixed road infrastructure (RSU) through dedicated short range communication (DSRC), Wi-Fi, 3G or 4G networks [2].

Sometimes RSU is costly, sometimes it is unavailable due to that new concept comes vehicular

cloud with V2V communication. Cloud computing is getting a more and more foundation element of the communication universe. In Cloud computing no upfront investment is needed. The basic idea is, why buy? When we can rent? Whatever helps, resources, software are required that we can charter out on demand. The same concept of cloud computing is applied to VANET to provide different services to ad-hoc network as well as outside the network because each vehicle is turning more and more powerful and has computational power. It employs the hardware devices available in a car or vehicle idle for long time in parking or garage or during traffic available on the road for some time, using that form a cloud which provides different services such as platform as a Service, Infrastructure as a Service, Software as a Service, Application as a Service, and storage as a service [3].

1.2 Dissertation Idea

Taking into consideration advantages of vehicular ad-hoc network and cloud computing from a Vehicular cloud VC to provide safety on road, traffic control and comfort to a passenger while traveling. Instead of purchasing all costly hardware, sensors on each vehicle, individual drivers will subscribe cloud provided services on demand. A vehicular cloud can be form by dynamically integrating re-sources and collecting resources [4]. Vehicles can communicate with cloud and access resources at the right time and place.

1.3 Motivation of dissertation

When we consider only VANET, node velocity and movement pattern are major challenges involved in that. The major challenges cost involved in implementing VANET in the material universe. To minimize that challenge we are shifting VANET to the swarm. Due to Vehicular Cloud, Data is accessible at anytime from anywhere. The old data is not lost. While sharing of hardware resources is performed then that cost factor is minimized. If we will implement this in real life people can access traffic related data from anywhere and at whatever level. The Motivation of Project is providing comfort and safety environment for passengers as well as drivers.

1.4 Literature survey

1.4.1 Background Work

Traditionally, the mobility models used in many network simulation tools do not get into account driver behavior or specific features of the urban environment (presence of point lights, intersections, merge lanes, and so on). As a result, the used mobility models, and thus, the simulation of network protocols may be unrealistic. The chief attribute of the vehicular environment is the high relative velocity that can be noticed between nodes. In this example, the Doppler Effect cannot be dismissed. Some other important characteristic comes from the important number of obstructions that could interfere with the radio wave generation. This is especially true in the instance of an urban scenario, where buildings and trees surround the route, but it is likewise valid for highways where the hitch can come from tunnels or from other cars. The most comfortable means to estimate the signal power at the receiver is to believe that this force depends only on the space between the communicating entities. This free space model can be heightened with a multi-path propagation, which causes self-interference, like the two ray ground model. A shadowing model also adds a random factor to the signal quality for each shape.

The paper [11] suggested a modified shadowing model for VANETs, where the fast fading factor is not totally random, but depends on the vehicular density. This example is founded on the idea that more neighboring vehicles mean more reflections of the received signal and, therefore, a higher degree of intervention. The idea is backed up by experimental results, but the tests have been constructed using a Wi-Fi network card working on the 2.4 GHz frequency while V2V communications will use the 5.9 GHz band.

A higher detail method, based on ray tracing techniques has been developed by Moser et al. [12]. Their approach requires modeling the whole surrounding area (trees, buildings, etc.) and the signal attenuation is computed based on the node positions in this complex environment. The algorithm takes into account physical phenomena like refraction, reflection, scattering and diffraction, and it is computationally- intensive. Moreover, it requires an important knowledge of the topology of the simulated area, which highly reduces the amount of scenarios that could be tested. Nevertheless, these results still require precise topological information, like building location. VANET simulation is the large number of nodes that need to be modeled. The memory and CPU consumption of network simulators grow linearly with the number of nodes even if the act of communicating pairs remains constant [13]. This is because in a wireless simulation, the receivers need to be searched among all the other entities. In the case of V2V networks, every node is also a source, consequently the number of communications is not constant and the resource consumption grows in this lawsuit with the square of the number of automobiles. Some traffic management applications foreseen for the vehicular network will operate at the shell of a metropolis or even a region and sometimes require modeling more than 10,000 guests. The subject of such results is very difficult using the current Network simulation software.

1.4.2 Overview of MANET

In a MANET [14], nodes operate in a peer to peer mode independent of any infrastructure or central-ized governance. To communicate with nodes beyond the range, intermediate nodes forward messages to destination node over multiple hops. Each node acts as an independent router and generates inde-pendent data. Fault detection and network management becomes distributed and hence more difficult. Nodes in MANETs are mobile causing the network topology to change often and unpredictably. This causes nodes to be active inwards and out of wireless range, resulting in node unavailability, changes in packet routes, and perhaps loss of packages. Since MANETs does not bank on any sort of central government or control, nodes in the wireless range dynamically discover each other and build link with each other [15].This serves to defend the ad-hoc network, even in situations where nodes keep moving in and out of each other’s wireless range. Thus, MANETs can be quickly deployed and held with minimal user interference. Since mobile nodes run on batteries, the processing power available for each client is defined. Since each node is acting as an end user system as easily as a router, more energy is eaten up to bear out the use of forwarding packets to the address.

Wireless connections have a significantly lower capacity compared to wired links [16]. Wireless links often suffer from the effects of multiple access, fading, noise, and interference conditions that prevent it from delivering a throughput equal to the maximum throughput. Each client may be fitted with single or more wireless interface operating across different frequencies. Each mobile node might also experience a different hardware/software configuration with different capacities. Designing protocols and algorithms for such heterogeneous, asymmetric links becomes a complex procedure.

1.4.3 Overview of VANET

Vehicular communication (VC) is an important component of ITS where vehicles communicate with other vehicles and/or roadside infrastructure, analysis and process received information, and reaches conclusions based on the analysis. Such a web of self-organized vehicles and road-side infrastructure communicating with each other over wireless, with a view to improve traffic safety and efficiency forms a VANET. The primary benefit of VANET communication is seen in active safety systems that increase passenger safety by exchanging warning messages between vehicles. Other promising commercial applications are Added-Value Services such as: advertising support [6], request/provide data about nearby companies, access to the Internet, etc. A VANET may be considered as a particular type of ad-hoc network used to provide communications between On-Board Units (OBUs) in nearby vehicles, and between OBUs in vehicles and Road-Side Units (RSUs), which are fixed equipment located on the route. In particular, this report deals with the topic of Inter-Vehicle Communication when the systems in a VANET do not rely on RSUs.

The primary advantage of VANETs is that they do not require an expensive infrastructure. Nevertheless, their major drawback is the comparatively complex networking management system and security protocols that are needed. This difficulty is primarily due to some specific characteristics of VANETs that allow differentiating them from the rest of MANETs such as their hybrid architecture, high mobility, dynamic topology, scalability problems, and intermittent and unpredictable communications. Therefore, these features have to be consumed into account when designing any management service or protocol. The vehicular network topology is frequently and dynamically changing, obtaining and maintaining roads is a real challenging task in VANET. Traditional topology-based routing protocols are not suitable for VANETs.

Comparison with MANETs

Vehicular ad-hoc networks (VANETs) are an extreme case of mobile ad hoc networks (MANETs). In MANETs, nodes communicate with each other in an ad-hoc manner, i.e. without a defined base.

Abbildung in dieser Leseprobe nicht enthalten

Table 1.1: Main characteristics of mobile and vehicular ad-hoc networks.

In VANETs, the nodes communicate in a similar way, but with high speed and different mobility characteristics which lead to frequent network topology changes. On the other hand, various features of the vehicular networks can be used as advantages. For instance, in VANETs, vehicles move within specific road directions, and the importance of transmission power and message storage space con-straints is not restricted. Moreover, the geographic position of a vehicle can be seen by applying a global positioning system (GPS) receiver, when applicable. Table 1.1 lists the primary characteristics of mobile and vehicular ad-hoc networks.

1.4.4 Application Scenario of VANET

Integration of communication and computational features into vehicles are being done with an objec-tive to realize vehicular communication. Aside from traffic safety and efficiency, VANETs [1, 2, 3, 4, 5] also support other applications like electronic toll collection, net access, parking, infotainment, traffic updates etc. Yet safety has remained the main focus of VANET research. Many literatures are available for the classification of VANET applications [17] has classified VANET applications on the basis of demands along the communication system. Applications here are classed along the basis of whether the communication is V2V (vehicle to vehicle), V2I (vehicle to base), I2V (infrastructure for vehicle), single-hop/multi-hop, one-way/two-way etc. In VANET applications [18] are generally classed as safety and non-safety applications. In applications are categorized into information and warning functions (public exposure of road information like congestion, surface shape, and so forth), communication based longitudinal control (vehicle platooning), cooperative assistance systems (like lane merge warning, curve warning).

In another classy [19], VANET applications are classified into 3 primary categories: safety (life-critical, time critical applications like collision avoidance), traffic monitoring and optimization (pro-viding traffic information so as to reduce traffic jams), infotainment (internet and payment services). Raya and Hubax [20] have categorized VANET applications as safety-related applications and other applications (traffic optimization, electronic toll collection, internet access, location based services to find nearby restaurants/ gas stations and so on).Safety applications are further categorized as traffic data, general safety and liability-related [21] and has classified safety messages into safety-linked (related to safety, but latency not critical) and safety-critical (latency critical safety message).Has classified safety applications as life-critical safety applications (latency critical) and safety warning application (safety related, latency not critical). Additionally, it gives an added classification called Group communications (e.g. Cooperative platooning). In the classification of VANET applications is further refined by taking into account the diverse situations in which a VANET application is executed.

we have split the applications into two major categories: safety in addition, non-safety hit.

1. Safety applications: Safety applications have the ability to reduce traffic accidents and to improve general safety. These can be further categorized as safety-critical and safety-related applications. In the plan of security, it should be made sure safety messages are not faked.

- Safety-critical: These are applied in the event of hazardous sites (e.g.Like collisions) It lets in the offices where the danger is high or risk is close at hand. Such applications can access the communication channel with highest priority. In this example, latency (100 ms) and reliability of messages, play an important part in making the safety purpose. Safety-critical applications involve communication between vehicles (V2V) or between vehicles and infrastructure/infrastructure and vehicles (V2I/I2V).

- Guard-related: These include safety applications where the risk is either low (curve speed warning) or elevated (work zone warning), but still foreseeable [18].In safety-linked applications, the latency requirements are not as rigorous as in the case of safety-critical ones. Safety-related applications can be V2V or V2I/I2V.

2. Non-safety applications: These applications provide traffic data and enhance riding comfort. Non-safety applications, generally involve a V2I or I2V communication [6, 21].These services access the canals in the communication system, except the command groove. They access the duct in a low priority mode compared to safety applications. Non-safety applications include applications for

Traffic optimization: Traffic information and recommendations, enhanced route guidance and so on

Infotainment: Internet access, media downloading, instant messaging and so on Payment services: Electronic toll collection, parking management and so on

Roadside service finder: Finding nearest fuel station, eating places, etc. This takes communication of vehicles with roadside infrastructure and the associated database.

1.4.5 Challenges of VANET

VANETs are an instantiation of mobile ad hoc networks (MANETs) [15, 16]. MANETs have no fixed infrastructure and instead rely on ordinary nodes to perform routing of messages and network man-agement functions. However, vehicular ad hoc networks behave in different ways than conventional MANETs. Driver behavior, mobility constraints, and high speeds create the unique characteristics of VANETs. These characteristics have significant implications for planning decisions in these nets. 15

Node Velocity

One of the most significant facets of mobility in VANETs is the potential node velocity. Nodes either denote vehicles or road side units (RSUs) [6] in this instance. Node velocity may range from zero for stationary RSUs or when vehicles are bonded in a traffic jam to over 200 km per hour on main roads. In particular, these two extremes each pose a particular challenge to the communication system. In case of very high node velocities, the mutual wireless communication window is really short due to a relatively small transmission range of several hundred meters [22].For instance, if two cars riding in opposite directions with 90 km/h each, and if we take a theoretical wireless transmission range of 300m, communication is only possible for 12 minutes.

Movement Patterns

VANET are characterized by a potentially large number of clients that are highly mobile (i.e. Accord-ing to cars speed). This high mobility can be more or less significant depending on road nature (small streets vs. highways).Vehicles do not move around arbitrarily, only use predefined roads, normally in two instructions. Unpredictable changes in the way of vehicles usually only pass at intersections of roads. We can identify three types of roads [22]:

1. City roads: Inside cities, the road densities are relatively high. There are dozens of smaller roads, but also bigger, arterial roads. Many intersections, cut road segments into small bits. Often, buildings right beside the roads limit wireless communication.

2. Rural roads: These roads usually have much larger sections, which mean that intersections are rarer than in cities. Traffic conditions often do not countenance the establishment of a connected network, because too few vehicles are on the route. The overall management of rural roads changes more frequently than the direction of main roads.

3. Highways: Highways typically from a multi-lane route, which bears very large segments and well-defined exits and on-ramps. High-speed traffic encountered here. A client can quickly link up or leave the network in a very short time leading to frequent network partitioning and topology changes.

1.4.6 Architecture of VANETs

Vehicular ad hoc networks (VANETs) belong to a cosmopolitan category of mobile ad hoc communication networks with fast- moving nodes (i.e., vehicles).In specific, a VANET consists of (1) on-board units (OBUs) [6] built into vehicles and (2) road side units (RSUs) deployed on highways/sidewalks, which facilitates both vehicle-to-vehicle (V2V) [1] communications between vehicles and vehicle-to-infrastructure (V2I) communications between vehicles and RSUs (3) Application Unit (AU) it is a hardware unit fixed on the vehicle. In the presence of RSUs, not only can road and traffic conditions (e.g., sharp turns a head) be broadcast to a driver, but the drive -thru Internet access (e.g., [15]) can likewise be made possible for other occupants in the vehicle. Information from being a mote data server can be given up to a vehicle through the Internet backbone and vice versa. Farther, the communication service area can be great with the RSU sine place. Through V2I [11] communications, infotainment services (such as advertisements, parking lot availability, and automatic tolling) can also be provided with ease.

illustration not visible in this excerpt

Figure 1.1: Vehicular Ad Hoc Networks

A VANET system architecture consists of different lands and many individual components as de-scribed in Figure 1.The image shows three distinct domains (in-vehicle, ad hoc, and infrastructure), and individual elements (application unit, on-board unit, and road-side unit).

In-vehicle domain: This consists of an on-board unit (OBU) and one or more application units

(AU) inside a vehicle. AU executes a lot of applications applying the communication capacity of the OBU. An OBU is at least equipped with a (short range) wireless communication device dedicated to road safety, and potentially with other optional communication devices (for safety and non-safety communications). The distinction between AU and OBU is logical; they can also reside in a single physical unit.

Ad hoc domain: An ad-hoc domain is composed of vehicles equipped with OBUs and road-side units (RSUs), forming the VANET. OBUs form a mobile ad-hoc network which allows communi-cations between clients without the demand for a centralized coordination instance. OBUs directly communicate if wireless connectivity exists among them; use multi-hop communications are used to forward information.

Infrastructure domain: The base consists of RSUs and wireless hotspots (HT) that the vehicle access to safety and non-safety applications. While RSUs for internet access are typically set up by road administrators or other public agencies, public or privately owned hot spots are normally lay up in a less controlled environment. These two types of infrastructure access, RSU and HT, also correspond to different application types. In event that neither RSUs nor HT provide internet access, OBUs can also utilize communication capabilities of cellular wireless networks (GSM, GPRS, UMTS, HS-DPA, Wi-Max, 4G) if they are incorporated in the OBU, in particular for non-safety applications.

Application Units (AU): An Application Unit (AU) is an in-vehicle entity (embedded or plug-gable) and runs applications that can utilize the OBUs communication capabilities. Examples of AUs are i) a dedicated device for safety applications like hazard-warning, or ii) a navigation system with communication capabilities. Multiple AUs can be plugged in with a single OBU simultaneously and share the OBUs processing and wireless resources. An AU communicates solely via the OBU, which handles all mobility and networking functions on the AUs behalf. The distinction between an AU and an OBU is only logical and an AU can be physically co-sited with an OBU [5, 29].

On-board Unit (OBU): The On-Board Unit (OBU) is responsible for vehicle to vehicle (V2V) and vehicle to infrastructure (V2I) communications [5, 29]. It also provides communication services to AUs and forwards data on behalf of other OBUs in the ad hoc domain. An OBU is equipped with at least a single network device for short-range wireless communications based on IEEE 802.11p radio technology. This network device is used to send, receive and forward safety-related data in the ad-hoc domain. An OBU can be fitted with more network devices, e.g. for non-safety communications, based on other radio technologies like IEEE 802.11a/b/g/n. OBU functions and procedures include wireless radio access, geographical ad hoc routing, network congestion control, reliable message transfer, data protection, IP mobility support, and others.

Roadside Unit (RSU): A Road-Side Unit (RSU) is a physical device located at fixed locations along roads and highways, or at dedicated locations such as gas station, parking spaces, and eating places. An RSU is equipped with at least a network device for short range wireless communications based on IEEE 802.11p like radio technology. An RSU can also be fitted with other network devices in society to permit communications with an infrastructure web.

An overview of the primary parts of an RSU is given below [6,18].

1) Drawing out the communication range of an ad hoc network by way of re-distribution of information to other OBUs and cooperating with other RSUs in forwarding or in distributing safety information Figure (1.2).

2) Running safety applications, such as for V2I warning (e.g. Low bridge warning, work-zone warning), and act as information source and recipient, respectively Figure (1.3).

3) Providing internet connectivity to OBUs Figure (1.4).

illustration not visible in this excerpt

Figure 1.2: RSU extends communication range

1.4.7 Cloud Computing and Mobile Cloud Computing

Mobile Cloud Computing is a recently emerging paradigm in the information technology arena. To better interpret and leverage its technological advances, it is necessary to define both Cloud Com-puting and Mobile Cloud Computing. The National Institute of Standards and Technology (NIST),

illustration not visible in this excerpt

Figure 1.3: RSU acts as information source

illustration not visible in this excerpt

Figure 1.4: RSU providing internet access

presents a formal definition of CC: “Cloud Computing is an example for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, computer memory, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction” [21].

The Mobile Cloud Computing Forum defines MCC as follows [22] “Mobile Cloud computing at its simplest refers to an infrastructure where both the data memory and the data processing happen outside of the mobile device. Mobile cloud applications move the computing power and data storage away from mobile telephone sets and into the cloud, taking applications and mobile computing to not just Smart phone users but a much fuller range of mobile subscribers”. Mobile cloud computing is established on the fact that, without financing in infrastructure, businesses can function by renting the infrastructure and the necessary software for their system. Various characteristics are unique in mobile cloud computing in terms of hardware and service provisioning [21] [23]:

- Provides the users the facility of unlimited computing power accessible on demand - Does not require early planning of resource provisioning.

illustration not visible in this excerpt

Figure 1.5: Vehicular Networking: Applications and Requirements

- Upfront costs can be avoided by cloud users, which allow companies to start new small businesses and offer their hardware resources when they are exclusively needed for popular applications.

- Ability to pay for computing resources up to the required time on a short-term basis and release them when they are no longer necessary.

- Services can be accessed from anywhere in the universe. Capable of accessing the resources at whatever time.

- By visualization techniques, one car can serve several users and act as separate machines.

- By resource pooling, many customers can be done with a large networked data center.

1.4.8 Mobile Cloud Computing Architecture:

Considering the definitions and services the architecture for MCC is illustrated in Figure 1.6. This architecture comprises three layers, the Application layer (SaaS), the Platform layer (PaaS) and the autonomous vehicles whose corporate computing, sensing, communication and physical resources can be organized and dynamically allocated to authorized users.”

The VC concept is a further step to set up the information processing system and situational consciousness of drivers in public and the larger percentage of the population. The ultimate focus of the VC is to extend on demand solutions for unpredictable outcomes in a proactive fashion [6]. We must outline the structural, functional and behavioral characteristics of VCs and recognize the independent cooperation of vehicular resources as a unique feature of VCs. VCs are able to provide a unified incorporation and reorganized management of on board installations.VC can adapt dynamically according to the changing application demands and organization environments.

In the close future a huge federation of VCs will be established ad hoc with the provision of alleviating massive emergencies because emergency evacuation in the look of a possible natural dis-aster that will abolish the standing infrastructure and lead to chaos with mobile networks. Thus, a federation of VCs will offer a decision support organization for a while and get the temporary infrastructure replacement. In the USA, the Federal Communications Commissions allocated Dedicated Short Range Communications (DSRC) with a scope of 75 MHz of the spectrum (5.850 to 5.925 GHz) in support of vehicular networking [11]. Moreover, roadside infrastructures such as inductive loop sensors, television cameras, acoustic tracking systems, microwave radar sensors, and access tips are too helpful for VCC.As part of a project, Ford motor company combines social networks, GPS location awareness, and real-time vehicle information in ways that help drivers go where they want efficiently by utilizing the cloud. Ford is equipped with cloud features called Ford SYNC, which links customers to real time traffic updates, information, turn-by-turn driving directions, business, sports, weather, and news through voice instructions. Fords research into cloud-based technology includes adaptive ve-hicle dynamics, driver wellness, wellbeing, and smart electrification. The car could monitor driver health condition and the smart phone apps can interact with the car.

The software system provides access to vehicle performance data, networking services, voice recognition, social networking tools and other data [27]. Recently, Toyota and Microsoft announced a new, 12 million partnership to bring cloud computing to Toyota vehicles [28]. The partnership will equip Toyota vehicles with the latest technology to access telecommunications information, streaming music, energy management, and GPS services, while on the road. Within 2015, by using Microsoft windows Azure cloud platform, Toyota will be possible to turn on heating and air condition while drive towards home. In summation, for hybrid car could select the best time for charging when energy cost is less expensive, check and monitor battery level for calculation how far it can go [29].I also consider some other motor company named General Motors. The General Motor perception and vehicular control groups are employed in producing a vehicle to vehicle communication system [30].GM offers the benefits of the connectivity include in-vehicle Wi-Fi hotspots for mobile devices, entertainment options like streaming TV for passengers, real time updates, and faster application downloads. By OnStar track maintenance and offer more accurate traffic data and Internet radio options and link to personal mobile devices, enabling embedded vehicle capabilities (Harris, 2013).The engineering science will provide workable solutions for essential safety information for drivers. Figure 2 presents taxonomy of Vehicular cloud computing which will be hashed out in the next parts.

illustration not visible in this excerpt

Figure 1.7: Taxonomy of Vehicular Cloud Computing

Chapter 2 Problem Definition and Scope

2.1 Problem Statement

Taking into consideration advantages of VANET and Cloud Computing, give Cloud appearances to VANET and minimize the challenges involved in that such as Node velocity, Movement pattern. Finding unused resources such as implanted devices which are available on or in the car utilized them very efficiently and effectively and provides software as a service (Network as a Service and Storage as a Service) to VANET under cloud environment.

2.2 Description of problem

VANET supports two types of communications such as Vehicle to Vehicle communication (V2V), where each vehicle communicates with each other through an on board unit (OBU) which is available in each vehicle. Another is the vehicle to fixed Infrastructure (V2I) in which each vehicle is commu-tate with a fixed road infrastructure (RSU) through dedicated short range communication (DSRC), WI-Fi, 3G or 4G networks [2].

Sometimes RSU is costly, sometimes it is unavailable due to that new concept comes vehicular cloud with V2V communication. Cloud computing is becoming a more and more foundation element of the communication world. In Cloud computing no upfront investment is needed. The basic idea is, why buy? When we can rent? Whatever services, resources, software are required that we can rent out on demand. The same concept of cloud computing is applied to VANET to provide different services to ad-hoc network as well as outside the network because each vehicle is turning more and more powerful and has computational power. It employs the hardware devices embedded in a car or or vehicle which are unused for long time in parking or garage or during traffic available on the road for some time, using that form a cloud which provides different services such as platform as a Service, Infrastructure as a Service, Software as a Service, Application as a Service, and storage as a service [3].

2.3 Goals and Objectives

The destination of the thesis is to provide software as a service to VANET in a cloud environment to achieve it, following objectives are determined:

- To create Vehicular Cloud and provide different services such as NaaS, SaaS uses vehicles. Provide real time traffic conditions of the route. (Current Traffic info)
- To find at a particular time how much traffic was there at a special position or positions. (Past Traffic info.)
- To provide noise and pollution information.
- To trace of all vehicles and its geographic location.
- To trace particular vehicle and its route of the whole journey.

2.4 Statement of scope

The task is planned to operate on windows or Linux environment. It looks at the implementation of JOSM (JAVA open street map) SUMO (version 0.19.0) technologies namely python. Recent improve-ments in vehicular communications and computing technologies have enabled various types of vehicular communications and networks, intra-vehicle, vehicle-to-infrastructure vehicle-to-roadside, and vehicle-to-vehicle or mobile-to-mobile communications. There has been a firm stake in developing various techniques and significant applications in vehicular communications, which are envisioned to revolutionize the driving experience, roadside internet access and traffic control organizations.

2.5 Software context

1. JAVA:

- Java is related to C++, which is a direct descendent of C. Much of the character of Java is inherited from these two languages. From C, Java derives its syntax. Many of Java object-oriented features were influenced by C++. James Gosling, Patrick Naughton, Chris Warth, Ed Frank, and Mike Sheridan conceived Java at Sun Microsystems, Inc. in 1991. It required 18 months to get the first working version. This speech was initially named Oak but was renamed Java in 1995. Between the initial implementation of Oak in the fall of 1992 and the public announcement of Java in the spring of 1995, many more people contributed to the design and development of the terminology. Bill Joy, Arthur van Hoff, Jonathan Paine, Frank Yellin, and Tim Lindholm were Key contributors to the maturing of the original paradigm.

- Java has successfully directed many of the issues surrounding portability in the Internet environment, there are still features that it misses. One is cross-language interoperability, also called mixed-language programming. This is the power of the code produced by one oral communication to work easily with the code developed by some other. Cross-language interoperability is needed for the creation of large, distributed software systems. It is too desirable for programming software components because the most valuable ingredient is one that can be applied by the widest kind of computer languages, in the greatest act of operating environments.

- Platform independence is one of the most important advantages that Java has over some other Programming languages, especially for systems that need to operate on many different political programs.

- Java is platform-independent at both the beginning and the binary level.

2. Python:

- Python is perhaps best distinguished as an object-oriented scripting language: its design mixes software engineering characteristics of traditional voice communications with the usability of scripting languages.

- Python is an object-oriented language, from the earth upward. Its class model supports advanced nations such as polymorphism, operator overloading, and multiple inheritance; however in the context of Python’s dynamic typing, object-oriented programming (OOP) is unusually comfortable to use. In fact, if you don’t understand these terms, you’ll discover they are much more comfortable to learn with Python than with just about any other OOP language available.

- Python is freeware something which has lately been come to be called open source soft-ware. As with Tcl and Perl, you can receive the total arrangement for free over the Internet. There are no limitations on copying it, implanting it in your systems, or shipping it with your merchandise. In fact, you can even sell Python, if you’re thus disposed.

- Python is written in portable ANSI C, and compiles and runs on nearly every major political program in use today. For exemplar, it operates on Unix systems, Linux, MS-DOS, MS-Windows (95, 98, NT), Macintosh, Amiga, Be-OS, OS/2, VMS, QNX, and more. Further, Python programs are automatically compiled to portable byte code, which operates the same on any platform with a compatible variant of Python What that implies is that Python programs that utilize the core language run the same on Unix, MS-Windows, and any other organization with a Python interpreter. Most Python ports also contain platform-specific references (e.g., COM support on MS-Windows), but the core Python language and libraries operate the same everywhere.

- From a features perspective, Python is something of a hybrid. Its tool set places it between traditional scripting languages (such as Tcl, Scheme, and Perl), and systems languages (such as C, C++, and Java). Python provides all the simplicity and ease of use of a script-ing language, along with more advanced programming tools typically found in systems development languages. Unlike just about scripting languages, this combination makes Python useful for significant development projects. More or less of the things we’ll find in Python’s high-level toolbox:

– Dynamic typing: Python keeps track of the kinds of objects your program applies when it operates; it doesn’t require complicated type and size declarations in your code.

– Built-in object types: Python provides commonly used data structures such as lists, dictionaries, and strings, as an intrinsic character of the language; as we’ll find out, they’re both pliable and soft to apply.

– Built-in tools: To process those entire object types, Python comes with powerful and standard operations, including concatenation (joining collections), slicing (extracting sections), sorting, mapping, and more.

– Library utilities: For more specific tasks, Python also comes with a great accumulation of pre-coded library tools that underpin everything from regular-expression matching to networking to object persistence.

– Third-party utilities: Because Python is freeware, it encourages developers to contribute preceded tools that support tasks beyond Python’s built-ins; you’ll obtain free support for COM, imaging, CORBA ORBs, XML, and much more.

– Automatic storage management: Python automatically allocates and reclaims (”garbage collects”) objects when no longer utilized, and most grow and shrink on demand; Python, not you, keeps track of low-level memory details.

– Programming-in-the-large support: Finally, for building larger systems, Python in-cludes tools such as modules, categories, and exceptions; they permit you to organize systems into components, do OOP, and handle events gracefully.

3. PHP:

- PHP is Open Source, has a very wide community following, is based on C styled scripting, and feels and feels vaguely familiar. It is also objected oriented (or at least can behave in an object oriented fashion), standing for that Web programmers can run round with their own defined objects as if they were part of the language, which makes animation a lot more comfortable. PHP also has the support of the hosting community, so any free or budget Linux host will likely tolerate it, and in that respect are even Windows builds available for those wanting to use that particular program. It can connect to MySQL (a Web database, which you read about in the next chapter) and comes with libraries for processing XML.

- PHP is utilized as a pre-processor. This implies that it is the server has to invoke the PHP soft-ware that is established on the server when serving the page. The PHP software then translates the various assertions that are in the PHP script and ignores everything else, passing any output back to the Web server, which forwards it in an appropriate way to the node.

- These PHP scripts are written in plain text, making them easy to edit and upload to the server. Although they can be picked up (which is programmed-speak for turning them into machine code), this is not common for user-created scripts.

- Like JavaScript, PHP can be contained inline within an HTML document, or it can be referenced from an HTML document, usually through embedded PHP code. HTML and PHP can be freely mixed so long as the regulations are kept abreast.

- The conflict is that all pages that contain PHP code should have the reference. PHP, so that the organization can transmit them to the pre-processor. In addition, they will probably ask to have their permissions changed so that they are classified as executable. Please catch up to your Web hosts documentation or support forum for more inside information on this aspect of managing the PHP scripts.

4. MySQL:

- MySQL is the world’s most popular open source database, enabling the cost-effective delivery of reliable, high-performance and scalable Web-based and embedded database applications. MySQL is a database system used on the web. MySQL is a database system that runs on a server. It is ideal for both small and large applications. It MySQL is very fast, reliable, and easy to use. It supports standard SQL. It compiles on a number of platforms. MySQL is free to download and use. MySQL is developed, distributed, and supported by Oracle Corporation

- Scalability and Flexibility: The MySQL database server provides the ultimate in scalability, sporting the capacity to handle deeply embedded applications with a footprint of only 1MB to running massive data warehouses holding terabytes of information. Platform flexibility is a stalwart feature of MySQL with all flavors of Linux, UNIX, and Windows being supported. And, of course, the open source nature of MySQL allows complete customization for those wanting to add unique requirements to the database server.

- High Performance: A unique storage-engine architecture allows database professionals to con-figure the MySQL database server specifically for particular applications, with the end result being amazing performance results.

- High Availability: Rock-solid reliability and constant availability are hallmarks of MySQL, with customers relying on MySQL to guarantee around-the-clock up time.

MySQL offers variety of high-availability options from high-speed master/slave replication configurations, to specialized Cluster servers offering instant fail over, to third party vendors offering unique high-availability solutions for the MySQL database server.

- Robust Transactional Support: MySQL offers one of the most powerful transactional database engines on the market. Features include complete ACID (atomic, consistent, isolated, durable) transaction support, unlimited row-level locking, distributed transaction capability, and multi-version transaction support where readers never block writers and vice-versa. Full data integrity is also assured through server-enforced referential integrity, specialized transaction isolation levels, and instant deadlock detection.

- Web and Data Warehouse Strengths MySQL is the de-facto standard for high-traffic web sites because of its high-performance query engine, tremendously fast data insert capability, and strong support for specialized web functions like fast full text searches. These same strengths also apply to data warehousing environments where MySQL scales up into the terabyte range for either single servers or scale-out architectures. Other features like main memory tables, B-tree and hash indexes, and compressed archive tables that reduce storage requirements by up to eighty-percent make MySQL a strong standout for both web and business intelligence applications.

- Strong Data Protection Because guarding the data assets of corporations is the number one job of database professionals, MySQL offers exceptional security features that ensure absolute data protection. In terms of database authentication, MySQL provides powerful mechanisms for ensuring only authorized users have entry to the database server, with the ability to block users down to the client machine level being possible. SSH and SSL support are also provided to ensure safe and secure connections. A granular object privilege framework is present so that users only see the data they should, and powerful data encryption and decryption functions ensure that sensitive data is protected from unauthorized viewing. Finally, backup and recovery utilities provided through MySQL and third party software vendors allow for complete logical and physical backup as well as full and point-in-time recovery.

- Comprehensive Application Development: libraries are available to embed MySQL database support into nearly any application. MySQL also provides connectors and drivers (ODBC, JDBC, etc.) that allow all forms of applications to make use of MySQL as a preferred data management server. It doesn’t matter if it’s PHP, Perl, Java, Visual Basic, or .NET, MySQL offers application developers everything they need to be successful in building database-driven information systems.

- Open Source Freedom and 24 x 7 Support: Many corporations are hesitant to fully commit to open source software because they believe they can’t get the type of support or professional service safety nets they currently rely on with proprietary software to ensure the overall suc-cess of their key applications. The questions of indemnification come up often as well. These worries can be put to rest with MySQL as complete around-the-clock support as well as indem-nification is available through MySQL Enterprise. MySQL is not a typical open source project as all the software is owned and supported by Oracle, and because of this, a unique cost and support model are available that provides a unique combination of open source freedom and trusted software with support.

- Lowest Total Cost of Ownership: By migrating current database-drive applications to MySQL, or using MySQL for new development projects, corporations are realizing cost savings that many times stretch into seven figures. Accomplished through the use of the MySQL database server and scale-out architectures that utilize low-cost commodity hardware, corporations are finding that they can achieve amazing levels of scalability and performance, all at a cost that is far less than those offered by proprietary and scale-up software vendors. In addition, the reliability and easy maintainability of MySQL means that database administrators don’t waste time troubleshooting performance or downtime issues, but instead can concentrate on making a positive impact on higher level tasks that involve the business side of data.

2.6 Tool Used

SUMO (Simulation of Urban MObility)

To simulate the way that vehicles act on roadways, we chose the Simulation of Urban Mobility (SUMO) simulator [23]. This simulator is open source, with most of the development coming from the employees of the Institute of Transportation systems at the German Aerospace Center. Figure 2.1 shows SUMOs visual user interface.

illustration not visible in this excerpt

Figure 2.1: SUMO GUI

SUMO is a microscopic simulator, which means that it operates at the level of each vehicle. Every vehicle is simulated. The vehicles react to other vehicles ahead of them, stop for traffic lights, wait for vehicles to pass before entering a roadway that has a higher priority, and follow their own individual route. SUMO can handle large simulation maps imported from reality however; created our own scenarios for the research in this thesis. Initially, SUMO is given a listing of intersections, roads, traffic control lights, routes, and vehicles. A significant contribution made by the research in this thesis was the creation of several programs to run VANET simulations in conjunction with the SUMO simulator.

Features:

The features of SUMO simulators are listed below:

- Complete workflow (network and routes import, DUA, simulation)
- Simulation
– Collision free vehicle movement
– Different vehicle types
– Multi-lane streets with lane changing
– A fast openGL graphical user interface
– Manages networks with several 10.000 edges (streets)
– Fast execution speed (up to 100.000 vehicle updates/s on a 1GHz machine)
– Interoperability with other application on run time using TraCI
– Network-wide, edge-based, vehicle-based, and detector-based outputs
- Network
– Many network formats (VISUM, Vissim, Shapefiles, OSM, Tiger, RoboCup, XML-Descriptions) may be imported
– Missing values are determined via heuristics.
- Routing
– Microscopic routes - each vehicle has an own one
– Dynamic User Assignment
- High portability
– Only standard c++ and portable libraries are used
– Packages for Windows main Linux distributions exist
– High interoperability through usage of XML-data only

2.7 Hardware Resources Required

Minimum two systems each one for installing one of them acts as Road side unit R.S.U. and another will act as client vehicle; having hardware configuration as:

- Minimum 1GB RAM.
- Minimum 80 GB hard disk.
- System with Graphic Card.

2.8 Software resources required

The software resources required for the project are as follows:

- Window xp /2000 /vista/ window 7 / window 8.
- Visual C++ Redistribution 2010.
- .net framework 3.5. Python 2.7
- Traffic Simulator Sumo 0.19.0 OpenGL Viewer
- Java Open Street MAP (JOSM) PHP
- MySQL
- Notepad++

2.9 Area of Dissertation

The area of dissertation is wireless ad-hoc networking (VANET) and Cloud Computing.

Abbildung in dieser Leseprobe nicht enthalten

Chapter 3 Dissertation Plan

3.1 Problem Definition

Taking into consideration advantages of VANET and Cloud Computing, give Cloud appearances to VANET and minimize the challenges involved in that such as Node velocity, Movement pattern. Sometimes RSU is costly, sometimes it is unavailable due to that new concept comes vehicular cloud with V2V communication. Considering cost factor in implementation of VANET and Finding unused resources such as embedded devices which are available on or in the car utilized them very efficiently and effectively and provides software as a service (Network as a Service and Storage as a Service) to VANET under cloud environment.

3.2 Dissertation Resources

3.2.1 Software Requirements

- Operating system

– Window xp /2000 /vista/ window 7 / window 8.

- Programming Languages

– JAVA, python, PHP, MySQL, HTML

- Editors

– Notepad++

3.3 Dissertation Tasks

The tasks to be carried out are as follows:

3. Requirement analysis
4. Project design
5. Environment Configuration
6. Implementation
7. Testing
8. Documentation

Each task is further divided into subtasks and the time required for each task and each subtask is calculated and is as shown in Table 3.1,

3.4 Dissertation Schedule

illustration not visible in this excerpt

Figure 3.1: Timeline Chart for the Dissertation

illustration not visible in this excerpt

Table 3.1: Dissertation Tasks.

Chapter 4 Software Requirement Specification

4.1 Purpose and Scope of the Document

This document seeks to provide the software requirement specification for the dissertation Providing Software as a Service to VANET in cloud Environment . It includes the set of use cases which describes all the interactions of users with the application. It also contains class diagram, activity diagram, sequence diagram and state diagram.

4.2 Usage Scenario

The actors involved in the system are as follows,

- Vehicle

- Road side unit

- Detectors

- Induction loop detector
- Vehicle type detector
- Smoke detector
- Traffic light signal detector

4.2.1 Use-cases

A use case diagram is a graphical representation of a user’s interaction with the system and depicting the specifications of a use case. A use case diagram can show the different types of users of a system and the various ways that they interact with the system. Use case diagrams are used to gather the requirements of a system including internal and external influences. These requirements are mostly design requirements. So when a system is analyzed to gather its functionalists use cases are prepared and actors are identified. So in brief, the purposes of use case diagrams can be as follows:

- Used to gather requirements of a system.
- Used to get an outside view of a system.
- Identify external and internal factors influencing the system.
- Show the interacting among the requirements are actors.

4.2.2 Use Case View

illustration not visible in this excerpt

Figure 4.1: Use Case Diagram

2.7 Functional Model and Description

- Class Diagram

The purpose of the class diagram is to model the static view of an application. The class diagrams are the only diagrams which can be directly mapped with object oriented languages and thus widely used at the time of construction. The UML diagrams like activity diagram, sequence diagram can only give the sequence flow of the application but class diagram is a bit different. So it is the most popular UML diagram in the coder community.

So the purpose of the class diagram can be summarized as,

- Analysis and design of the static view of an application.
- Describe responsibilities of a system.
- Base for component and deployment diagrams.
- Forward and reverse engineering.

The Figure 4.2 shows class diagram for the system in which, we can represent all required files for configuration. And implement any geographic network with required VANET parameter.

- Activity Diagram

Activity diagram is another important diagram in UML to describe dynamic aspects of the system. Activity diagram is basically a flow chart to represent the flow form one activity to another activity. The activity can be described as an operation of the system. So the control flow is drawn from one operation to another. This flow can be sequential, branched or concurrent. Activity diagrams deals with all type of flow control by using different elements like fork, join etc.

2.8 External System Interfaces

4.4.1 Hardware Interfaces

The interfaces that will be required by the system will include input devices like keyboard; mouse and output devices like monitor display. Maximum screen resolution maybe a useful information as it could limit the size of simulation window.

illustration not visible in this excerpt

Figure 4.2: Class Diagram

The Figure 4.3 shows the activity diagram for the system; operational condition is used for simulation used for any geographic network.

4.4.2 Software Interfaces

The python compiler and .NET framework will handle the interactions between the simulator and the protocol. These interactions can be limited by the capabilities of the simulator. So the JAVA and python language and compiler can be used to communicate with each other and the required hardware.

illustration not visible in this excerpt

Figure 4.3: Activity Diagram

4.4.3 User Interfaces

The user interfaces allows user to communicate with the operating system. This will contain all the controls needed to build and simulate an ad hoc network.

4.5 Non Functional Requirements

4.5.1 Performance Requirements

In general, we require the highly responsible application. The simulation speed should me proper that is it should not be much faster or too slow. Every step in the simulation should be comprehensible to the user. The actions related to keyboard and mouse should respond quickly by the system.

4.5.2 Safety Requirements

The simulator is purely virtual so there are no safety related external policies or regulations. In response to safety there are no actions to be taken or prevented.

4.5.3 Security Requirements

As the product is not a real wireless network it does not require any user authentication process. There are no external policies or regulations and no certifications that must be satisfied. So there are no concerns regarding security.

4.5.4 Software Quality Attributes

- Reliability

The system should perform consistently. Due to cloud, service should be provided transparently and reliably.

- Flexibility

The system should allow flexible configurations, as it requires. The scenarios for movement of mobile nodes as a vehicle and traffic can be generated and delivered for different environments.

- Testability

The system should be testable enough to find the errors easily. The performance of the proposed system can be tested by using different performance metrics like time, speed, etc.

- Adaptability

The system should be extendible by some modifications in the existing protocol.

- Maintainability

In creation of new routing protocol system has to follow good policies for designing so as to implement it easily. The vehicle information is maintained periodically in detectors table at detectors which we are called as R.S.U. , which can be broadcasted to all the nodes.

- Correctness

The output of the simulation must be correct so that log can be maintained. The design of proposed system is expected to be correct.

- Usability

The system should be easy to use. This prioritizes ease to use before ease of learning. It should be easier to run for the new users.

- Re-usability

The system should contain reusable components. In particular the log files should be reusable.

Chapter 5 High level design document

5.1 Introduction

The document provides the complete description of the proposed system. It contains the design for data and architecture.

5.2 Purpose of the Document

This document provides the detailed design and working implementation for the dissertation Pro-viding Software as a Service to VANET in Cloud Environment. to be developed as the part of the Dissertation.

5.3 System Design

5.3.1 System Architecture

The Vehicular cloud architecture lies on three layers: Vehicle to vehicle, Vehicle to Infrastructure, RSU to Static Cloud and Vehicle to Dynamic cloud. As illustrated figure 5.1. In the first layer is the Vehicle to vehicle layer, we assume that each vehicle is equipped with an OBU that including a built-in navigation system, with amped the location of a RSUs. The OBUs have abroad band wireless communication to transfer data through 3G or 4G cellular communication devices, Wi-Fi, Wi-MAX and Wireless Access in Vehicular Environment (WAVE) or Dedicated Short Range Communication (DSRC). If driver indicates the abnormal behavior on the road such as: changing direction dramatically, driving over the speed limit or the occurrence of a major mechanical failure in the vehicle, an Emergency Warning Messages (EWMs) will be generated and sent to the cloud storage and surrounding vehicles, which contains the geographical location, speed, acceleration and moving direction of the offender.

illustration not visible in this excerpt

Figure 5.1: Proposed System: Vehicular Cloud

The next layer called vehicles to infrastructure used to transfer the location, movement of vehicles and traffic crucial information. The next layer called RSU to Static Cloud communication, which can used to store all RSU data dynamically on static cloud as create free space for storing new information on RSU unit for future communication as well as RSU unit can hold pollution related information for environmental support as SaaS services. The last layer is vehicles to Dynamic cloud, its can support for multi-hop communication to create dynamic cloud as well as store accident related information to next vehicles on a road as a NaaS services.

5.3.2 Design Modules

The Figure 5.2 shows the detail design modules of system.

5.3.3 Working Model

The diagram in Figure 5.3 shows the flow of programs and files for the simulations run in this scenario. Each simulation is controlled by a Python script called Simulation Controller. This script calls each

illustration not visible in this excerpt

Figure 5.2: Detailed Design Modules of System

of the programs involved, starting with Grid Creator. Grid Creator is in charge of creating the road network used in the simulation. After the road network is defined, Simulation Controller activates NETCONVERT, a tool that comes with SUMO, which converts the road network files into a single file for use with SUMO.

The next step is to define vehicles for the roads. Simulation Controllers choose either Journey Maker or Journey Typhoon, depending on the scenario, for defining these vehicles. The vehicle file created by either of the two journey programs is then fed into the SUMOs routing tool, DUAROUTER, which gives the vehicles their initial paths. The last preparation for the vehicles be-fore they are fed into SUMO is to create a single file with links to the files that SUMO will read. This single file is created by Configurer. SUMO is started up in server mode by Simulation Controller, and then a loop begins for each second of the simulation with exchanges of gathering information about the vehicles, feeding them into my routing program, RouteMan, making the appropriate changes, and then running the next step of the simulation.

illustration not visible in this excerpt

Figure 5.3: Working Model of System

5.4 General Setting

All of the results in this thesis are generated by running each scenario with only one routing method at a time. Additionally, the vehicle departure times and origin destination pairs were kept the same in each simulation. However, a vehicle may be delayed from entering the road network if the roadway is already crowded. Therefore, it can be imagined that each of the vehicles has a scheduled time for turning on their engine and attempting to leave, though the vehicle may not be able to immediately get out of its parking lot if there is too much traffic on the roadway it wishes to enter.

illustration not visible in this excerpt

5.4.1 Road Types

Several road types were created for our initial simulations, but only three road types are used in the simulations presented in this research. These road types are meant to replicate common ones seen in Tulsa, OK. They are a residential road, minor city street, and major city street. The characteristics of each are summarized by the table 5.1 below.

illustration not visible in this excerpt

Table 5.1: Road Types

All the scenarios presented in this thesis have a major street at every tenth street, a minor street every fifth street, and residential roads for all others.

5.4.2 Traffic Light Logic

The traffic lights in the simulations presented for research in this thesis are all static traffic lights with fixed cycles. Dynamic traffic lights based on induction loops can be simulated using TraCI coupled with vehicle sensors in SUMO, but this requires significantly more computing power for large networks and may be obsolete if VANETs are implemented with the ability to affect traffic lights. The fixed cycle nature of the traffic lights used in this research is notable because this will cause a difference between the results from the simulations in this thesis, and the results seen in previous route information sharing simulations. The simulations in [14] did not include any sort of traffic control, and the effects of this difference will be discussed later in thesis. Traffic lights are simulated at intersections of city streets. Vehicles on residential roads must yield to traffic on minor and major streets and find a large enough gap in traffic to safely enter or cross, including the time it takes to accelerate into the roadway. The timing for the cycle is listed below i Tabel 1.3.

illustration not visible in this excerpt

Table 5.2: Traffic Light Logic

Intersections of a major street with a minor street use the same timing. The lights facing the major streets use the major street timing, and the lights facing the minor streets use the minor street timing.

This is the same on edge roads. Corners have lights that are always green, because traffic does not cross lanes.

5.4.3 Stop Signs

SUMO does not contain a built-in stop sign feature, therefore stop signs had to be simulated using traffic lights. The traffic light cycle for simulating a stop sign gives one way of traffic a green light for 1 second, then all intersections have red lights for two seconds. The allowed traffic changes in the counter-clockwise direction so that the next car allowed to pass is the car on the right side.

5.4.4 Vehicle Characteristics

Each routing type is defined as its own vehicle type in the SUMO files, however the characteristics of each vehicle are the same. The vehicle characteristics are displayed below in Table 5.3.

illustration not visible in this excerpt

Table 5.3: Vehicle Characteristics

Multiple vehicle types are declared for the sake of having a different id tags that can be used to easily determine the routing that needs to be applied.

5.4.5 Notable Differences from Previous Research

The simulations in [25] use single-lane roads with uniform speed limits, and no traffic control. The authors state that they chose a simple traffic flow model to examine the interdependence between traffic congestion as macro phenomena and route choice of individual drivers as micro behavior. It is unknown if vehicles took into account the affects of vehicle acceleration and following distance, but this would seem to indicate that they did not. Another difference is that [25] rerouted vehicles and exchanged route information every time a vehicle got to an intersection. Vehicles in real life should not decide to change the path they want to take when they are already at an intersection; this would cause congestion, as vehicles had to cross over lanes of traffic to get into or out of a turning lane. The default in this thesis is for broadcasts to occur every second. Later, there will be a discussion on the results of changing this broadcast rate.

5.5 Scenarios

The following scenarios are used for the simulations presented in this thesis. They were chosen because they highlight the differences in the behavior of route information sharing methods compared to the traditional method live traffic map method.

5.5.1 Accident

The main scenario used for simulation is the Accident scenario. This is a simulation of a four square mile grid network, 21 roads by 21 roads, with three streams of constant traffic. Every two seconds a vehicle enters the roadway, until a total of 5,000 vehicles are created. At 5,000 seconds, halfway through the creation of vehicles, an accident is simulated by changing the speed limit to zero on the roads leading to a main intersection. The accident lasts for 30 minutes before the intersection is reopened. This scenario is particularly useful because it contains two types of traffic patterns: the constant stream of vehicles in the beginning and end, and the congestion created by rerouting vehicles during the middle. The diagram in figure 5.4 summarizes this scenario.

illustration not visible in this excerpt

Figure 5.4: Accident scenario

Although the vehicles do not have to pass through the stopped intersection, the intersection would be part of the ideal route for each origin-destination pair. Even if the routing methods do not use the intersection for all of the traffic, the accident will cause new congestion due to cars diverting from that intersection.

5.5.2 Random

Completely random traffic is unrealistic. The reasons were previous discussed at length in the thesis. Nevertheless, a completely random scenario was done in [14], therefore it is included here as a means

illustration not visible in this excerpt

Figure 5.5: Random scenario road network

to compare these results with the previous results. The grid for the Random scenario is an elongated network as seen in figure 5.5.

The shape of the map has two useful characteristics. The first is that it allows for longer routes so that there is a more significant difference in the times of each routing method. The second is to allow a challenge for the methods to weigh the sacrifice of going out of their way against the savings of traveling a long distance over a road at a faster speed limit. Vehicle origin-destination pairs are generated randomly, and a new vehicle is generated every second up to 2,500 vehicles.

5.5.3 Hurricane

The purpose of the Hurricane scenario is to see the results of a scenario where congestion is unavoidable and unpredictable. The Accident scenario has constant congestion. The Random scenario gets congestion evenly distributed. The Hurricane scenario is unique because streams of vehicles are sent to the same location. This scenario uses the Journey Typhoon program to generate a traffic pattern with settings of 100 typhoons, 10 streams per typhoon, and 5 cars per stream. This results in 5,000 cars. There are two seconds between each car in the stream entering the network. The map for the Hurricane scenario is the same as the one used in the Random scenario.

5.2 Implementation

In the implementation phase of the project, find out the platform where this project is feasible to im-plement, as we know Field tests require not only implementation of the solution on real hardware, but also dedicated road infrastructure and equipped vehicles. These high costs have, until now, limited the size of these experiments at no more than 1020 cars. Even the large-scale deployment scenarios that are currently prepared [8] will only have the capacity to test a minor proportion from the pro-posals made by the vehicular ad-hoc networks (VANET) research community. On the other hand, the vehicular environment is highly complex and analytical models need to take into consideration not only the network, but also the properties of the vehicles and the behavior of the drivers. Under these conditions, computer simulation has become the main tool in VANET research. So I am used Simulation of Urban Mobility (SUMO) tool for implementing VANET, SUMO is a traffic simulator that can support all characteristic of VANET.

The dissertation work will be carried out as follows.

[1] Implementation of MAP.
[2] Analysis of Traffic Condition of Vehicles
[3] Broadcasting of Each Vehicles
[4] Working of TLS logic and Detector
[5] Evaluation of Simulation result (i.e. Noise Emission, Speed and Delay).

5.6.1 Implementation of MAP

Implementation of Map is initial task of Traffic simulator. Road networks are normally stored as a directed graph. Junctions are represented as nodes and streets as edges. Beside the position, it is located at and an identifier, sometimes the information about its type is found which in most cases distinct between simple priority junctions and junctions controlled by a traffic light. The descriptions of the traffic light plans themselves are not that uniform. An edges description contains more parameter. At first, the number of lanes the edge consists of should be given. In the case of macroscopic simulation networks, this is sometimes not the case and the edges capacity has to be used to compute the edges lane number. Assuming the maximum capacity of a lane as 20000veh/h, the formula below computes the number of lanes if this information is not given. The only problem is that in some cases, edges used in macroscopic traffic simulation networks are using unreal values for the flow in order to fit the simulation to reality or to guarantee a high inflow. Furthermore, a maximum number of lanes can be applied. The first case can only be changed by hand.

Further information optionally stored within an edges description is the edges type. It is not found in all inputs and also no standard value sets exist. Other road attributes are either stored directly within the edge or within the type and in the second case they must be retrieved indirectly. These attributes are: the maximum velocity allowed on the edge, possibly the length, information whether overtaking is allowed or not and geometrical information as a single edge may be not a straight connection between two junctions but may possess a curvature.

Below Figure 5.6 denote the structure of LAN generated in SUMO.

illustration not visible in this excerpt

Figure 5.6: Two sets of rather complicated junctions as computed

5.6.2 Information Computation

The import Procedure is divided into two parts. At first, the input is read using a reader capable to parse the format of the imported file and converted into the net converters internal structures. Within the second step, the network converter uses the information stored within these internal structures to compute all values the simulation needs. If any of the needed information was already available within the input file, the computation is skipped and the read values are used. This method allows an easy implementation of import modules and guarantees the same results independent of the import format itself.

5.6.2 Lane-to-Lane Relationship Computation

After loading, all loaded junctions (called nodes from now on) and streets (edges) are stored in two containers one for the junctions and one for the edges. The order of those objects within these containers is not defined. All operations are executed on every junction and on every edge within the according container. The following operations are done in the given order:

[1] for each edge: compute turnaround edges
[2] for each node: sort each nodes edges
[3] for each node: compute each nodes type
[4] for each node: set edge priorities
[5] for each edge: compute edge-to-edge connections
[6] for each edge: compute lanes-to-edge connections
[7] for each node: compute lane-to-lane connections
[8] for each edge: recheck lanes

Compute Turnaround Edges

Among streets successors, the turnaround direction is a special case as the number of lanes used to reach it is always one and because this direction is not regarded as an explicit direction: it is uncommon to have a lane which is only used to turn around as the wish to do so only seldom occurs. A further reason for computing the turnarounds is due to needing this information for the computation of the edges clockwise order within step 2. Due to his peculiarities the backward edge is computed for each edge first and this information is stored to allow neglecting the backward direction on further processing (steps 2-8). To compute the turning directions, we assume that an edge is the backward edge if the absolute value of the difference between the current edges direction and the edge considered to be the backward direction is larger than 160. The angle is measured at the current junction as each edge is a list of straights, and due to this, a streets angle may differ along it. This computation holds a trap: there may be more than a single edge that fits to the 160-rule. In this case, the edge with the largest absolute direction difference is used. Still, to check for 160 is necessary as the usage of the edge with the highest rotation difference only would be false in cases where an edge has no backward direction at all.

Sort each Nodes Edges

Within the second step, each of a junctions streets both incoming and outgoing are sorted clockwise by their direction. Direction means here the angle at the currently regarded junction. After this, the edges are sorted by their logical direction whether they are incoming or outgoing. This is done by going through the sorted list of edges and checking whether the next edge (the one at the current position + 1) is the backward direction of the current one and is an incoming edge. In this case, the outgoing edge was sorted to lie left to the incoming one, but should be on the right side. In this case, the edges are swapped within the list. The result of this operation is a clockwise sorted list of edges that participate in the junction and the incoming lanes lay before the outgoing ones as shown in Figure 4.

illustration not visible in this excerpt

Figure 5.7: The resulting order of edges after sorting

Compute Nodes Types

We regard three different types of junctions: no junction, priority junction, and right before left junction. The first case, no junction is a special case where no right of way rules are applied. A normal network should not contain such junctions, but if for example two highways cross, this type may be used. Within priority junction an incoming street and its consecution has a higher priority than other incoming streets. Within right before left junctions, all directions have the same priority.

Set Edge Priorities

Now for each edge, we set his priority within a junction. This information will be needed later to determine how many lanes shall approach this edge in the case of an outgoing edge from an incoming edge. The priority of an edge within a junction may differ from the edges overall priority because edges of different types may cross within the junction. The edges overall priority is also not always available within the network description. If not, the edges speed may be used. The edges priorities for a certain junction they participate within are computed as following:

highest incoming edge2 = undefined

highest incoming edge1 = get the incoming edge with the highest priority

illustration not visible in this excerpt

Figure 5.11: Pune city Map generated by NETCONVERT

The syntax of a single trip definition is:

Where , above tag denote following information.

id = The name of vehicles that will be generated using this trip definition depart = The departure time of the (first) vehicle which is generated using this trip definition from = The name of the edge the route starts at; the edge must be a part of the used network to = The name of the edge the route ends at; the edge must be a part of the used network type = denote type of vehicles.

color = This generated vehicle’s color

5.6.5 Broadcasting of Each Vehicles

As per trip information, vehicles can follow the route. DUAROUTER imports different demand definitions, computes vehicle routes that may be used by SUMO using shortest path computation; when called iteratively DUAROUTER performs dynamic user assignment (DUA). The syntax of a DUAROUTER definition is:

After running the simulation it can broadcast each vehicle. Below Figure 5, denote the output of duarouter is configuring with sumo.

5.6.6 Working of TLS logic and Detector

The TLS(Traffic Light System) logic is applicable for development of traffic light. Normally, NET-CONVERT generate traffic lights and programs for junctions during the computation of the networks. Detector is used for to calculating the various factor related to vehicle i.e. Arrival time of vehicle,

illustration not visible in this excerpt

Figure 5.12: Broadcasting of Each Vehicle.

Departure time of vehicle, emission of noise and toxic gases. The edge/lane based vehicular emission output based on HBEFA database writes absolute and normed values of vehicular pollutant emissions collected on edges or lanes. The absolute values hold the sum of each of the pollutants emitted on each edge/lane; the normed values give the values normed by the interval duration and the edge /lanes length. Below Figure 5.13, denote TLS logic with detector.

illustration not visible in this excerpt

Figure 5.13: TLS Logic with Detector fix on edges

5.6.7 Evaluation of Simulation Result

SUMO allows generating a large number of different measures. The output is available as per user requirement.

Track the Vehicle in network

Positions of vehicles over time for a certain vehicle type (or all vehicles). This application can used to trace out the location of vehicles. The output is divided into time step-sections. The final output is available in xml file and output is divided into time step-sections:

The values are described in the following table 5.4.

illustration not visible in this excerpt

Table 5.4: Attribute for Track the vehicle in Network

Induction Loop

An instantaneous induction loop is writing a value to the output device as soon as a vehicle was detected. This detector differs between different states:

- ”enter”: a vehicle has entered the detector in this simulation step

- ”stay”: a vehicle which entered the detector in a prior step is still on the detector

- ”leave”: a vehicle has left the detector in this simulation step

The final output is available in xml file and output is divided as per detector: The values are described in the following table 5.5

Emissions Measures

Another output is generated by sumo is used to find out emission of various gases are emitted by each vehicle at particular road i.e. edge/Lane. The final output is available in xml file and output is divided as per edge/Lane:

The values are described in the following table 5.6

illustration not visible in this excerpt

Table 5.5: Attributes for Induction Loop.

Screen Shot of Simulation:

illustration not visible in this excerpt

Figure 5.14: Starting of Simulation

illustration not visible in this excerpt

Table 5.6: Attributes for Emission measure.

illustration not visible in this excerpt

Figure 5.15: Pune City

illustration not visible in this excerpt

Figure 5.16: Each Vehicle are follows Traffic Rule

Chapter 6 Test Specification

6.1 Goal and Objectives

Software Testing is an activity that helps in finding out bugs/defects/errors in a software system under development, in order to provide a bug free and reliable system/solution to the customer. Testing of software is always carried out in two parts viz. verification and validation. Verification refers to the set of activities that ensure that software correctly implements a specific function. Validation refers to a different set of activities that ensure that the software has been built is traceable to customer requirements.

6.2 Statement of Scope

Software scope describes the functions and features that are to be delivered to end users, the data that are input and output, and the content that is presented to the users as consequence of using the software. Test plan for this project involves the testing of the individual components for modules interface. Finally the system as a whole is tested, verified and validated.

6.3 Test Plan

The software is tested using two levels of testing viz. black box testing and white box testing. White box testing could be carried out in three different phases viz. unit testing, system/integration testing and validation testing.

6.3.1 Testing Strategy

The testing strategy followed to test the project is described as follows and shown in Figure 6.1:

Organize Project: All the modules of the project are tested independently using unit testing.

Design Integration Test: It involves identifying Test Cycles, Test Cases, Entrance & Exit Criteria, Expected Results, etc. The test conditions are derived from the business design and the transaction requirement documents.

Build Test Procedures: It includes setting up procedures such as status reporting and setting up data tables

Build Test Environment: It includes building hardware, software and data setups in required for execution of software.

illustration not visible in this excerpt

Figure 6.1: Project Testing Strategy

Execute Integration Test: It combines all modules of the system to form the system as a whole and this combined system is tested.

Execute Acceptance Test: This test is done to check whether the results produced by the software are as per the expectations or not.

Signoff: Signoff happens when all predefined exit criteria have been achieved

illustration not visible in this excerpt

6.3.2 Unit Testing

Unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use. A bottom up approach is used for testing. This strategy will be useful to find out bugs in the individual modules of the system.

illustration not visible in this excerpt

6.3.3 Integration Testing

Integration testing is a systematic technique for constructing the system architecture while at the same time conducting tests to uncover tests associated with interfacing. Integration testing is performed after unit testing. It focuses on the problems related to integration of units that function correctly when used individually. Here we have used bottom-up testing i.e. beginning with construction and testing of atomic modules. We are integrating the managing neighbor table unit and node movement detection unit to select the route failure detection module. After integration testing is complete and the errors detected are fixed, regression testing is required to ensure that the changes made to the system have not introduced new errors.

illustration not visible in this excerpt

6.3.4 Validation Testing

Validation testing allows us to determine whether the system is able to satisfy the specified require-ments or not. This can be done at the end of the implementation process. Validation ensures that the system meets the specified requirements. In terms of simulation we can say that the validation is the process of determining the degree to which the simulation and its associated data are exact representation of the real world.

6.4 Black Box Testing

Black-box testing is a method of software testing that tests the functionality of an application as opposed to its internal structures or working. Specific knowledge of the internal working of the applications code is not required. The tester is only supposed to be aware of what the software is supposed to do, but not how. This testing strategy is used to check whether the system provides the expected output with the predefined inputs. The black box test cases designed for the testing purpose of the project are shown in Table 6.1

illustration not visible in this excerpt

Table 6.1: Black Box Testing

6.5 White Box Testing

The white box testing is usually done at the unit level which validates the internal structure of the code for deriving the test cases. The conduction of this testing requires wide knowledge of programming languages. It is also known as open box or glass box testing. As the tester has knowledge of the source code, it is very easy to find out which type of data can help in testing the application effectively. It also helps in optimizing the code. Sometimes it is impossible to look into every nook and corner to find out hidden errors that may create problems as many paths will go untested.

6.6 Test Cases

2.5 1) Test Case Id: 01

- Test Description- Creation of Pune City Map
- Environment- Windows, python, .net Framework, Xerces-C, Fox, PROJ and GDAL
- Test Input- Google Open street map
- Test Execution- 1. Convert .osm into .net file
- Expected Result- Map should be created.
- Actual Result- Pune City map is created.
- Status-Pass

2. Test Case Id: 02

- Test Description- Create trip file
- Environment- Windows, python, .net Framework, Xerces-C, Fox, PROJ and GDAL
- Test Input- net file
- Test Execution- 1. Run the net file
- Expected Result- Trip File from map should be created.
- Actual Result- Trip file from map is created.
- Status-Pass

3. Test Case Id: 03

- Test Description- Creation of route file.
- Environment- Windows, python, .net Framework, Xerces-C, Fox, PROJ and GDAL
- Test Input- trip file,
- number of vehicle=1000 with different properties. Test Execution- 1. Run the trip file and shortest path algorithm apply
- Expected Result- Route file should be generated foe 1000 vehicles.
- Actual Result-route file is created. Status-Pass

4. Test Case Id: 04

- Test Description- Creation of Configuration file in that call all files and set simulation time. Environment- Windows, python, .net Framework, Xerces-C, Fox, PROJ and GDAL
- Test Input- Net file, route file, some additional supporting files, simulation time= 7000ms
- Test Execution- 1. Generate configuration file, 2. Run the cfg file using SUMO and observe the simulation
- Expected Result- Configuration file is created successfully upto 7000 ms. Actual Result-Configuration file is created successfully.
- Status-Pass

3. Test Case Id: 05

- Test Description- Generation of expected results
- Environment- Windows, python, .net Framework, Xerces-C, Fox, PROJ and GDAL
- Test Input- simulation data
- Test Execution- 1. Run the simulation
- Expected Result- Result should be generated in CSV format
- Actual Result-Result generated in CSV format.
- Status-Pass

4. Test Case Id: 06

- Test Description- Prove Network as a service
- Environment- Windows, PHP Admin WAMP Server.
- Test Input- CSV results
- Test Execution- 1. Stored all results into database of RSU server.
- Expected Result- Database should be created successfully
- Actual Result-Database is created. Status-Pass

5. Test Case Id: 07

- Test Description- Create Cloud server and prove Storage as a Service SaaS.
- Environment- Windows, PHP Admin WAMP Server.
- Test Input- Database data.
- Test Execution- 1. Run the WAMP Server 2. Run the Services.
- Expected Result- Cloud Server should be created.
- Actual Result-Cloud Server is created successfully.
- Status-Pass

Chapter 7 System Analysis and Results

7.1 Performance Metrics

Vehicular ad hoc network can perform V2I and V2V communication, in our project we implement vehicular cloud environment that can help to use to measure various performance parameter using various detector on network

1. Time Vs Speed relationship :

This parameter can measure the speed of vehicle can be pass under detector, and detector can emit out result in from of Time of respected duration vs Speed.

2. Location of Vehicles :

The VANET can be work on geographic location; this performance metric can discover location of vehicle using 2D i.e. with help of X and Y coordinates.

3. Latitude Vs Longitude :

Geographic location of vehicle with respect to time duration can be measure or discovered with help of Latitude Vs Longitude relationship

4. Fuel Consumption :

This performance analysis can measure the fuel consumption with respect to time on edges.

5. Determine vehicle type :

This performance analysis can check out the various type of vehicle are run on road with refer to different time stamp.

7.2 Performance analysis

For the purpose of performance analysis of the proposed mobility implementation using SUMO simulation tool has been employed with python and xml base programming. For the simulations, different scenarios are considered.

7.2.1 Simulation Environment

Simulation of Urban Mobility:

To simulate the way that vehicles act on roadways, we chose the Simulation of Urban Mobility (SUMO) simulator. This simulator is open source, with most of the development coming from the employees of the Institute of Transportation systems at the German Aerospace Center.

SUMO is a microscopic simulator, which means that it operates at the level of each vehicle. Every vehicle is simulated. The vehicles react to other vehicles ahead of them, stop for traffic lights, wait for vehicles to pass before entering a roadway that has a higher priority, and follow their own individual route. SUMO can handle large simulation maps imported from reality however; created our own scenarios for the research in this thesis.

illustration not visible in this excerpt

Table 7.1: Simulation Configuration

7.3 Results and Discussion

The result can evaluated with the help of various factors explain in performance Metrics, the various result can be evaluated in form of table form for Pune city under cloud structure in below section.

1. Induction loop

illustration not visible in this excerpt

Figure 7.1: Providing of Software as a Service in VANET under Cloud Environment

Random detector A: Induction loop say the state of vehicle at detector or roadside unit location. The result of detector can represent the time duration with respect to speed of vehicles, and also detect the length, type of vehicles and its unique identification no for identification.

The ”id” is any string by which you can name the detector. The attributes ”lane” and ”pos” describe on which lane and at which position on this lane the detector shall lay. The ”freq”-attribute describes the period over which collected values shall be aggregated. The ”file” attribute tells the simulation to which file the detector shall write his results into.

An instantaneous induction loop is writing a value to the output as soon as a vehicle was detected. This detector differs between different states: ”enter”: a vehicle has entered the detector in this simulation step ”stay”: a vehicle which entered the detector in a prior step is still on the detector ”leave”: a vehicle has left the detector in this simulation step

illustration not visible in this excerpt

Figure 7.2: Results on Random Detector A

illustration not visible in this excerpt

Figure 7.3: Time Vs. Speed Graph for Random Detector A

illustration not visible in this excerpt

Figure 7.4: Results on Random Detector B

Random detector B.

Area Vise Detector

Location of Vehicle

illustration not visible in this excerpt

Figure 7.5: Time Vs. Speed Graph for Random Detector B

illustration not visible in this excerpt

Figure 7.6: Area wise Traffic

As per coordinate: This result can denote or detect the vehicle as per requirement on a net

illustration not visible in this excerpt

Figure 7.8: Time Vs. Speed Graph: Traffic on FC Road

illustration not visible in this excerpt

Figure 7.9: Traffic on Hadapsar

Location of Vehicle

As per coordinate: This result can denote or detect the vehicle as per requirement on a net here we consider X and Y axis for finding a location of vehicle and speed of vehicles.

Location of Vehicles as per Geo-Graphic Area

This result can denote or detect the vehicle as per requirement on a net here we consider latitude and longitude axis for finding a location of vehicle and speed of vehicles.

Location find out of specific vehicle

illustration not visible in this excerpt

Figure 7.10: Time Vs. Speed Graph: Traffic on Hadapsar Road

illustration not visible in this excerpt

Figure 7.11: Traffic on JM Road

This result can denote the vType can denote find out specific vehicle here we consider some vehicle type i.e. passenger vehicles , bus, bus/city. This output can be represent the output with respect to each time stamp with specific speed

illustration not visible in this excerpt

Figure 7.12: Time Vs. Speed Graph: Traffic on JM Road

illustration not visible in this excerpt

Figure 7.13: Traffic on Kothrud Road

illustration not visible in this excerpt

Figure 7.14: Time Vs. Speed Graph: Traffic on Kothrud Road

illustration not visible in this excerpt

Figure 1: Traffic on KP Road

illustration not visible in this excerpt

Figure 2: Time Vs. Speed Graph: Traffic on KP Road

illustration not visible in this excerpt

Figure 7.17: Traffic on Shanivarwada Road

illustration not visible in this excerpt

Figure 7.18: Time Vs. Speed Graph: Traffic on Shanivarwada Road

illustration not visible in this excerpt

Figure 7.19: Location of Vehicles as per coordinates

illustration not visible in this excerpt

Figure 7.20: Graph for location of vehicle as per coordinates

illustration not visible in this excerpt

Figure 7.20: Time Vs. Speed Graph for CAR Vehicle

illustration not visible in this excerpt

Figure 7.22: Time Vs. Speed Graph for Passengor/Wagon Vehicle

illustration not visible in this excerpt

Figure 7.23: Time Vs. Speed Graph for BUS Vehicle

illustration not visible in this excerpt

Figure 7.24: Location Find out of Passenger Vehicle

illustration not visible in this excerpt

Figure 7.25: Time Vs. Speed Graph For passenger Vehicle

Chapter 8 Summary and Conclusion

Summary

To summarize our project , as we work on vehicular cloud environment for growing a safe system and provide benefit to society. We develop a mobility model of vehicular ad-hoc network in the cloud, which can help to discuss the challenges regarding microscopic and macroscopic scenario, which can benefit to overcome challenges in traditional vehicular ad-hoc network. As well as providing various information regarding travel delay, density of traffic and pollution problem, the benefit of this work-place, traffic data can access from anywhere and can avail in cloud storage for future development.

Conclusion

Vehicular transportation an essential and became important need in daily life and have a great demand for vehicle to vehicle communication and computing. VANETs can realize V2V and V2I communications. This emerging vehicular networking paradigm is considered promising, enabling a wide spectrum of new on-the-road applications including safety, convenience, and comfort services. Vehicular communications are a major component of a future intelligent transportation system. De-signed mainly for safety-related reasons, a vehicular network can also be used by applications with a different profile, like traffic management or passenger entertainment. To make vehicle communication cost effective and efficient with help of cloud environment. In this project, we implement the model of Vehicular Cloud Environments for cost effective in high density structure with some parameters. This dissertation tries to facilitate the first stage of a study on vehicular cloud environments by providing network as a service and storage as a service using traffic simulator simulators. The simulation framework relies on state-of-the-art simulators from both domains, thus, it incorporates well - known models for road traffic micro simulation.

Providing Software as a Service To VANET Under Cloud Environment Future Enhancement

Abbildung in dieser Leseprobe nicht enthalten

Chapter 9 Future Enhancement

9.1 Privacy and security of VC

Security and privacy are very important aspects for the establishing and maintaining the trust of users in VC. Privacy measures are required to ensure the VC communication and information in the isolated and trustworthy environment, while security procedures are needed to protect against network threats. Establishing trust relationships between several participants is a vital part of trustworthy communication and computation. As some of the vehicles related to VC may have met previously, the proactive task of launching a fundamental trust relationship among vehicles is desirable and possible. VC as a set of vehicles which share the capability of computing power, Internet access and storage to form conventional cloud computing. Therefore, it is anticipated that VC suffers the same security problem as CC.

The main security challenges of VC include:

- Verifying the authentication of users and the integrity of messages due to the high mobility of nodes,

- Ensuring the confidentiality of sensitive message by using the cryptographic algorithm,

- Ensuring the secure location and localization because most applications in vehicular systems rely on location information,

- providing data isolation to ensure the security of stored data on the cloud,

- secure data access to protect stored data on the cloud against unauthorized access.

Annexure A

MATHEMATICAL ANALYSIS

Given a directed network G= (V, E, w ) for which the underlying undirected graph is connected. Furthermore, a source vertex r is given.

Objective: Find for each v 2 V a shortest directed path from r to v (if such one exists). Let n denote the number of nodes and m the number of edges in G.

Integer Programming Formulation

Suppose r is the source vertex. Look at the number of paths leaving a vertex vs. the number of paths entering a vertex. For r n1 paths have to leave r.

For any other vertex, the number of paths entering the vertex must be exactly 1 larger than the number of paths leaving the vertex.

Let x e denote the number of paths using each edge e 2 E.

Mathematical Model

This gives the following mathematical model:

illustration not visible in this excerpt

Annexure B

QUALITY AND RELIABILITY TESTING OF DISSERTATION DESIGN

For implementation, Pune city map is considered. total simulation time considered as 7000 ms. total number of vehicles are considered 1000. speed of vehicles considered from 10 km/hr to 70 km/hr. access pint considered as Wi-Fi environment. The following table shows the implementation scenario for the simulation,

illustration not visible in this excerpt

Annexure C

DISSERTATION PLANNER

Dissertation Tasks and Schedule shown below:

illustration not visible in this excerpt

Annexure D

BLACK BOX TESTING AND CORRECTIVE ACTION IN DESIGN

Black-box testing is a method of software testing that tests the functionality of an application as opposed to its internal structures or working. Specific knowledge of the internal working of the applications code is not required. The tester is only supposed to be aware of what the software is supposed to do, but not how. This testing strategy is used to check whether the system provides the expected output with the predefined inputs. The black box test cases designed for the testing purpose of the project are shown in Table.

illustration not visible in this excerpt

Annexure E

DISSERTATION WORKSTATION AND INSTALLATION REPORT

Hardware Resources Required

Minimum two systems each one for installing one of them acts as Road side unit R.S.U. and another will act as client vehicle; having hardware configuration as:

2.6 - Minimum 1GB RAM.

2.7 - Minimum 80 GB hard disk.

2.8 - System with Graphic Card.

Software resources required

The software resources required for the project are as follows:

1) Window xp /2000 /vista/ window 7 / window 8.

2) Visual C++ Redistribution 2010.

3) .net framework 3.5.

- Python 2.7
- Traffic Simulator Sumo 0.19.0
- OpenGL Viewer
- Java Open Street MAP (JOSM)
- PHP
- MySQL
- Notepad++

Simulation tool (SUMO)

SUMO is a microscopic simulator, which means that it operates at the level of each vehicle. Every vehicle is simulated. The vehicles react to other vehicles ahead of them, stop for traffic lights, wait for vehicles to pass before entering a roadway that has a higher priority, and follow their own individual route. SUMO can handle large simulation maps imported from reality however; created our own scenarios for the research in this thesis. Initially, SUMO is given a

listing of intersections, roads, traffic control lights, routes, and vehicles. A significant contribution made by the research in this thesis was the creation of several programs to run VANET simulations in conjunction with the SUMO simulator.

Installation:

- Libraries

– Xerces-C

SUMO used Xerces-C 2.8 by default, now it uses Xerces-C 3.0.1. The changes needed to compile with a different Xerces version should be limited to changing src/windows config.h, build/msvc10/Win32.props and / or build/msvc10/x64.props.

– Fox

- If you do not need a GUI, you can skip this section.

- Up to (and including) SUMO 0.10.3 (precisely up to svn revision 7025) SUMO used Fox 1.4, now it uses Fox 1.6. The building instructions are the same just replace 1.6 by 1.4 (and FOX16 by FOX14) wherever you need it.

- Go to the Fox directory and open the VC project

- Confirm the conversion to VC 10.0 and build the foxdll project as ”release and debug” (if you think you might wish to use the Visual Studio debugger) version. If you want to build for the 64bit platform you need to add a new configuration to the foxdll project using the Configuration Manager.

- You might get approximately 240 warnings and one error, which can be ignored. Errors on not finding windows.h mean the SDK was not installed properly.

- Create an environment variable FOX16 pointing to your Fox directory, e.g.

– PROJ and GDAL

- If you do not need transformation of geo-coordinates you can disable PROJ and GDAL in src/windows config.h, build/msvc10/Win32.props

- Build /msvc10/x64.props.

– SUMO

- Configuration

- If you installed all libraries and defined the environment variables correctly there is no need for further configuration and you can skip to the build section.

- The Visual Studio build is configured using .props files in the build/msvc10 subdirectory. If you change some settings which should apply to all sub-projects, be sure to edit those files (either with a text editor or the property manager of Visual Studio) and not the project configuration (.vcxproj).

- If you do not like to define the places of the includes and libraries via environment variables you can enter the location directly into x64.props or Win32.props (or both, depending on your target platforms). You should also disable PROJ and GDAL in those files (if you don’t need them) by setting the value for the appropriate ”LIB” Usermacro to the empty string.

- Build

- Open the project sumo build msvc10 prj.sln and build the configurations

Annexure F

MODULE DEVELOPMENT AND MODULE DESCRIPTION

The proposed work consists of following modules,

1) Implementation of MAP
2) Create trip file
3) Creation of route file.
4) Creation of Configuration file in that call all files and set simulation time.
5) Generation of expected results
6) Prove Network as a service
7) Create Cloud server and prove Storage as a Service SaaS.

1) Implementation of MAP: Implementation of Map is initial module of Traffic simulator. Road networks are normally stored as a directed graph. Junctions are represented as nodes and streets as edges. Beside the position, it is located at and an identifier, sometimes the information about its type is found which in most cases distinct between simple priority junctions and junctions controlled by a traffic light. The descriptions of the traffic light plans themselves are not that uniform. An edges description contains more parameter. At first, the number of lanes the edge consists of should be given. In the case of macroscopic simulation networks, this is sometimes not the case and the edges capacity has to be used to compute the edges lane number. Assuming the maximum capacity of a lane as 20000veh/h, the formula below computes the number of lanes if this information is not given. The only problem is that in some cases, edges used in macroscopic traffic simulation networks are using unreal values for the flow in order to fit the simulation to reality or to guarantee a high inflow. Furthermore, a maximum number of lanes can be applied.

2) Create Trip File: randomTrips.py generates a set of random trips for a given network. It does so by choosing source and destination edge either uniformly at random or weighted by length , by number of lanes or both. The resulting trips are stored in an xml file suitable for the DUAROUTER which is called automatically if the ”-r” option (with a file name for the resulting route file) is given. The trips are distributed evenly in an interval defined by begin (option ”-b”, default 0) and end time (option ”-e”, default 3600) in seconds. The number of trips is defined by the repetition rate (option ”-p”, default 1) in seconds. Every trip has an id consisting of a prefix (option ”-t”, default ”t”) and a running number.

3) Creation of route file: We can define the shortest path between source and destination using shortest path algorithm (Dijkstras Algorithm).

4) Creation of Configuration file in that call all files and set simulation time: Adding network, route and additional data files such as vType detectors, Traffic light signal, smoke, induction loop detectors and set simulation time. Run the simulation and generate the results.

5) Generation of expected results: after running simulation we will get all result in python based xml files. Analysis the result.

6) Prove Network as a service: Stored the all results into database and access that data using PHP which will give current and past traffic information which prove the Network as a Service.

7) Create Cloud server and prove Storage as a Service SaaS: In this project, to prove Storage as a Service, we use traffic data only. We stored all traffic related data on RSU and that data will accessible to any client.

Annexure G

WHITE BOX TEST PLAN, TESTING AND TEST REPORT

2.9 1) Test Case Id: 01

- Test Description- Creation of Pune City Map
- Environment- Windows, python, .net Framework, Xerces-C, Fox, PROJ and GDAL
- Test Input- Google Open street map
- Test Execution- 1. Convert .osm into .net file
- Expected Result- Map should be created.
- Actual Result- Pune City map is created.
- Status-Pass

5. Test Case Id: 02

- Test Description- Create trip file
- Environment- Windows, python, .net Framework, Xerces-C, Fox, PROJ and GDAL
- Test Input- net file
- Test Execution- 1. Run the net file
- Expected Result- Trip File from map should be created.
- Actual Result- Trip file from map is created.
- Status-Pass

6. Test Case Id: 03

- Test Description- Creation of route file.
- Environment- Windows, python, .net Framework, Xerces-C, Fox, PROJ and GDAL
- Test Input- trip file,
- number of vehicle=1000 with different properties.
- Test Execution- 1. Run the trip file and shortest path algorithm apply
- Expected Result- Route file should be generated foe 1000 vehicles.
- Actual Result-route file is created. Status-Pass

7. Test Case Id: 04

- Test Description- Creation of Configuration file in that call all files and set simulation time.

- Environment- Windows, python, .net Framework, Xerces-C, Fox, PROJ and GDAL

- Test Input- Net file, route file, some additional supporting files, simulation time= 7000ms

- Test Execution- 1. Generate configuration file, 2. Run the cfg file using SUMO and observe the simulation

- Expected Result- Configuration file is created successfully upto 7000 ms. Actual Result-Configuration file is created successfully.

- Status-Pass

6. Test Case Id: 05

- Test Description- Generation of expected results
- Environment- Windows, python, .net Framework, Xerces-C, Fox, PROJ and GDAL
- Test Input- simulation data
- Test Execution- 1. Run the simulation
- Expected Result- Result should be generated in CSV format
- Actual Result-Result generated in CSV format.
- Status-Pass

7. Test Case Id: 06

- Test Description- Prove Network as a service
- Environment- Windows, PHP Admin WAMP Server.
- Test Input- CSV results
- Test Execution- 1. Stored all results into database of RSU server.
- Expected Result- Database should be created successfully
- Actual Result-Database is created. Status-Pass

8. Test Case Id: 07

- Test Description- Create Cloud server and prove Storage as a Service SaaS.
- Environment- Windows, PHP Admin WAMP Server.
- Test Input- Database data.
- Test Execution- 1. Run the WAMP Server 2. Run the Services.
- Expected Result- Cloud Server should be created.
- Actual Result-Cloud Server is created successfully.
- Status-Pass

Annexure H

DISSERTATION ANALYSIS

Review of Conference/Journal Papers supporting dissertation idea:

1. Saif Al-Sultan, MoathM. Al-Doori, AliH. Al-Bayatti, Hussien Zedan, A comprehensive sur-vey on vehicular Ad Hoc network, Journal of Network and Computer Applications 37 (2014) 380392.

This paper provides a comprehensive survey dealing with all the issues facing VANET, in particular, VANET architectures components, VANET communication domains, wireless access technologies, VANET characteristics, challenges and requirements, VANET applications and simulation tools. This investigation enables researchers to focus on the issues surrounding VANET and its applications, showing great deal of understanding of how to tackle all issues related to VANET, At last it can provide detail review of simulation tool.

Limitation:

In this paper macroscopic and microscopic models of VANET are not discussed.

2. Atta ur Rehman Khan, Mazliza Othman, Sajjad Ahmad Madani, A Survey of Mobile Cloud Computing Application Models, IEEE COMMUNICATIONS SURVEYS TUTORIALS, 2014

Author proposes the different characteristic of Cloud Computing and Mobile Cloud Computing, represent the new architecture of cloud computing environment. The mobile cloud application models that are based on augmented execution of the smart phone clone in the cloud require synchronization of the smart phone and the clone. Therefore, new synchronization policies are required that can perform timely synchronization, taking into account accuracy, execution delay, and bandwidth utilization last explain The mobile cloud execution platforms need to be standardized to ease computation offloading to the mobile cloud platforms. Also, new energy consumption models are required to facilitate accurate decision making by considering the main entities involved in the offloading process.

Limitation:

In this paper synchronization, delay with respect to perticular factor in mobile devices are not addressed properly.

3. Qiang Duan, Yuhong Yan, and Athanasios V. Vasilakos , A Survey on Service-Oriented Net-work Virtualization Toward Convergence of Networking and Cloud Computing, IEEE TRANSACTIONS ON NETWORK AND SERVICE MANAGEMENT, Dec 2012

In this paper, author propose the concept of networking with Cloud computing , Network vir-tualization is being adopted in both telecommunications and the Internet as a key attribute for the next generation networking. Virtualization, as a potential enabler of profound changes in both communications and computing domains, is expected to bridge the gap between these two fields. Service-Oriented Architecture (SOA), when applied in network virtualization, en-ables a Network-as-a-Service (NaaS) paradigm that may greatly facilitate the convergence of networking and Cloud computing.

Limitation:

In this paper just put the basic idea about networking with Cloud, but how to bridge gap between these two fields are not addressed.

4. Md Whaiduzzaman, Mehdi Sookhak , Abdullah Gani, Rajkumar Buyya, A survey on vehicular cloud computing, Journal of Network and Computer Applications.

This paper presents the state-of-the-art survey of vehicular cloud computing. Moreover, present

Taxonomy for vehicular cloud in which special attention has been devoted to the extensive applications, cloud formations, key management, inters cloud communication systems, and broad aspects of privacy and security issues. Itemize the properties required in vehicular cloud that support this model. Compare this mechanism with normal Cloud Computing (CC) and discuss open research issues and future directions.

Limitation:

In this paper, author did survey of VANET but actual implementation VANET are not considered while This paper mainly focus on static cloud.

5. Olariu S, Khalil I, Abuelela M. Taking VANET to the clouds, International Journal of Pervasive Computing and Communications. 2011; 7: 7- 21.

This Paper puts forth a novel vision namely Vehicular Cloud Computing VC2, the underutilized vehicles resources such as computing power, Internet Connectivity and storage can be shared between drivers or rented like usual cloud resources are.

Limitation:

Security and privacy are always the two main concerns when allowing multiple users to share same set of resources.

6. Khaleel Mershad, and Hassan Artail, ”Finding a STAR in a Vehicular Network”, IEEE In-telligent transportation systems magazine, pp. 55-68, 2013.

Design a System that enables vehicles in a VANET to search for mobile cloud servers that are moving nearby and discover their services and resources. Transportation server STAR is nothing but Mobile cloud server . Consider several parameters , such as the resources of STAR processing power, transmission range, speed.

Limitations:

It is not possible to maintain the list of all nodes, replicas in VANET.

7. Md Ali Al Mamun, Khairul Anam, Md Fakhrul Alam Onik, A M Esfar- E- Alam , Deploy-ment of Cloud Computing into VANET to Create Ad Hoc Cloud Network Architecture

Proceedings of the World Congress on Engineering and Computer Science 2012 Vol I WCECS 2012, October 24-26, 2012, San Francisco, USA.

In the VANET, cloud computing can be used as a Network as a Service (Naas) or Storage as a Service (SaaS). Not all the cars on the road have internet access. In Naas, the car with access to internet can offer its excess capacity to the other cars in the VANET upon request. For, SaaS, the vehicles with ample storage capacity share storage with other vehicles which need storage capacity for temporary application. The main focus will be SaaS.

Limitations:

Mobility of the nodes, Signal Fading, Network Scalability

8. T.W. Chim , S.M. Yiu, Lucas C.K. Hui , Victor O.K. Li, VANET-based secure taxi service, Ad Hoc Networks Elsevier, Nov 2011.

In this paper, based on the framework of VANET (Vehicular Ad-hoc Network) and propose a novel secure taxi service scheme. Propose design a cooperative tracking mechanism to locate taxi in case of emergency. In some occasions, taxi passengers as well as taxi drivers are concerned with their privacy (such as traveling route). The taxis OBU uses pseudo identities instead of real identity for all ongoing transmissions so that a passengers traveling route (or the drivers traveling route when he/she is not carrying any passengers) cannot be traced by a third party easily.

Limitations:

Mobility of the nodes, how to maintain connections and communication exactly is not given.

9. Josiane Nzouonta, Neeraj Rajgure, Guiling (Grace) Wang VANET Routing on City Roads Us-ing Real-Time Vehicular Traffic Information. IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 58, NO. 7, Sept 2009

This paper propose the routing scheme in VANET to find out the shortest path between source and destination, and propose paper presents a class of routing protocols called road-based using vehicular traffic (RBVT) routing, which outperforms existing routing protocols in city-based vehicular ad hoc networks (VANETs). And lastly present real-time vehicular traffic information to create road-based paths consisting of successions of road intersections that have, with high probability, network connectivity among them. Geographical forwarding is used to transfer packets between intersections on the path, reducing the paths sensitivity to individual node movements. For dense networks with high contention, we optimize the forwarding using a distributed receiver-based election of next hops based on a multi criterion prioritization function that takes non-uniform radio propagation into account.

Limitations:

In this paper author working on only microscopic VANET not considered macroscopic.

10. Michele Rondinone , Julen Maneros, iTETRIS: A modular simulation platform for the large scale evaluation of cooperative ITS applications, Simulation Modeling Practice and Theory Elsevier, Sept 2013

This paper propose Cooperative ITS systems are expected to improve road traffic safety and efficiency, and provide infotainment services on the move, through the dynamic exchange of messages between vehicles, and between vehicles and infrastructure nodes. For implementation of VANET they can used iTETRIS simulation platform. iTETRIS is a unique open source simulation platform characterized by a modular architecture that allows integrating two widely adopted traffic and wireless simulator.

Limitations:

In this paper they put one new simulation iTETRIS, but that is not available in market uptil now.

11. Razvan Stanica , Emmanuel Chaput, Andr-Luc Beylot, “Simulation of vehicular ad-hoc net-works: Challenges, review of tools and recommendations”, Computer Networks Elsevier, 2011.

This paper gives overall idea for available tool in VANET simulation as well as propose the idea for Microscopic model, macroscopic model of VANET, provide limitation of VANET in Field work.

Limitations:

In this paper they mainly used traffic simulator SUMO and implement VANET but still limitation of VANET such as node velocity, resources inside vehicles are are not ad-dressed.

12. Daniel Krajzewicz, Jakob Erdmann, Michael Behrisch, and Laura Bieker Recent Development and Applications of SUMO - Simulation of Urban Mobility., International Journal On Ad-vances in Systems and Measurements, Dec 2012.

Propose SUMO is an open source traffic simulation package including the simulation appli-cation itself as well as supporting tools, mainly for network import and demand modeling. SUMO helps to investigate a large variety of research topics, mainly in the context of traffic management and vehicular communications. They mainly target on increasing the simulations validity as well as the number of situations. It can support geographic area as well as support microscopic and macroscopic model.

Limitations:

did not provide any means to examine impacts a single vehicle had on the traffic network and the flow of other vehicles through the network.

Annexure I

PAPER

International conference/Journal papers published:

International Journals:

1. Paper Published in International Journal in Advance Research in Computer Science and Software Engineering (IJARCSSE), Volume 3. No.11 NOV 2013 ISSN No- 2277 128X. On topic Shifting VANET to Cloud Survey Impact factor: 2.08.

2. Paper published in International Journal of Advanced Technology Engineering Research (IJATER), Dec 2013, ISSN No- 2250 3536. On Topic: Novel Approach Towards Accident Prevention Using Vehicular Ad Hoc Network Under Cloud Environment Impact factor 0.56

International Conferences:

1. Paper presented uploaded on IEEE XPLORER ISBN No- 978-1-4799-3759-2. On topic Motivation Towards Cost Effective Roadside Communication Techniques Vehicular Cloud Environment.

2. Paper presented and Published in Proceedings of Elsevier Science and Technology, ISBN No: 978-93-5107-220-1, Volume 2. On topic Accident Prevention and Air Pollution Control using VANET under Cloud Environment.

c-PGCON 2014 Details

1. Paper accepted for Elsevier Proceeding Publication. On Topic: Providing Software as a

Service in VANET using Cloud Environment.

2. Presented Paper in an Computers Post Graduate Conference (cPGCON), Matoshri COE, University of Pune, March 2014. Topic: Providing Software as a Service in VANET using Cloud Environment.

Poster Presentation

1. Pune University Level Poster Presentation for Post PG level Avishkar 2013 Topic : Taking VANET to the Cloud.

References

1. http://www.dw.de/india-has-the-highest-number-of-road-accidents-in-the-world/a-5519 345-1
2. Saif Al-Sultan, MoathM. Al-Doori, AliH. Al-Bayatti, Hussien Zedan, A comprehensive sur-vey on vehicular Ad Hoc network, Journal of Network and Computer Applications 37 (2014) 380392.
3. Giuseppe Caragnano, Klodiana Goga, Daniele Brevi, Hector Agustin Cozzetti, Olivier Terzo, Riccardo Scopigno, ” A Hybrid Cloud Infrastructure for the Optimization of VANET Simula-tions”, 2012 Sixth International Conference on Complex, Intelligent, and Software Intensive Systems,Palermo , Page(s):1007 1012.
4. M. F. J. B. Mate Boban, Tiago T. V. Vinhoza and O. K. Tonguz., Impact of vehicles as obstacles in vehicular ad hoc networks,” IEEE JOURNAL ON SELECTED AREAS IN COMMUNICA-TIONS vol. 29, no. 1, p. 15 to 28, JANUARY 2011.
5. Md Whaiduzzaman, Mehdi Sookhak , Abdullah Gani, Rajkumar Buyya, A survey on vehicular cloud computing , Journal of Network and Computer Applications.
6. Olariu S, Khalil I, Abuelela M. Taking VANET to the clouds, International Journal of Pervasive Computing and Communications. 2011; 7: 7- 21.
7. Khaleel Mershad, and Hassan Artail, ”Finding a STAR in a Vehicular Network”, IEEE Intelli-gent transportation systems magazine, pp. 55-68, 2013.
8. Md Ali Al Mamun, Khairul Anam, Md Fakhrul Alam Onik, A M Esfar- E- Alam , Deployment of Cloud Computing into VANET to Create Ad Hoc Cloud Network Architecture Proceedings of the World Congress on Engineering and Computer Science 2012 Vol I WCECS 2012, October 24-26, 2012, San Francisco, USA.
9. Gongjun Yan; Rawat, D.B.; Bista, B.B., ”Towards Secure Vehicular Clouds,” Complex, Intelli-gent and Software Intensive Systems (CISIS), 2012 Sixth International Conference on, vol., no., pp.370,375,4-6July2012.
10. Md Whaiduzzaman, Mehdi Sookhak , Abdullah Gani, Rajkumar Buyya, A survey on vehicular cloud computing , Journal of Network and Computer Applications,
11. Samara, G., Al-Salihy, W.A.H., Sures, R. Security issues and challenges of Vehicular Ad Hoc Networks, Proceedings of The 4th International Conference on New Trends in Information Science and Service Science (NISS), 2010, pp.393-398.
12. Christoph Sommer, Zheng Yao, Reinhard German and Falko Dressler, On the Need for Bi-directional Coupling of Road Traffic Micro-simulation and Network Simulation.
13. P. Papadimitratos, A. de la Fortelle, K. Evenssen, R. Brignolo, S. Cosenza, Vehicular communication systems: enabling technologies, applications, and future outlook on intelligent transportation, IEEE Communications Magazine 47 (11) (2009) 8495.
14. Razvan Stanica , Emmanuel Chaput, Andr-Luc Beylot, Simulation of vehicular ad-hoc net-works: Challenges, review of tools and recommendations Computer Networks, journal home-page: www.elsevier.com/ locate/comnet2011.
15. European Commission Report Road accident statistics in Europe,2010. US National Vital Statistics Report, vol. 50, No. 15, 2002.
16. Ho Ting Cheng, Hangguan Shan, Weihua Zhuang, Infotainment and road safety service support in vehicular networking: From a communication perspective, Mechanical Systems and Signal Processing 25 (2011) 20202038, journal homepage: www.elsevier.com/locate/jnlabr/ymssp
17. Rahim A, Ahmad I, Khan ZS, Sher M , Shoaib M, Javed A, Mahmood R (2009) A comparative study of mobile and vehicular adoc networks. Int. J. Recent Trends in Engineering, 2 (4).
18. Josiane Nzouonta, Neeraj Rajgure, Guiling (Grace) Wang, VANET Routing on City Roads Using Real-Time Vehicular Traffic Information IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 58, NO. 7, SEPTEMBER 2009
19. M. Bakhouya , J.Gaber , P.Lorenz, An adaptive approach for information dissemination in Vehicular Ad hoc Networks Journal of Network and Computer Applications, journal homepage: www.elsevier.com/locate/jnca
20. C. Sommer, Z. Yao, R. German, and F. Dressler, Simulating the Influence of IVC on Road Traffic Using Bi-directionally Coupled Simulators, Proc. IEEE INFOCOM: Mobile Networking for Vehicular Environments (MOVE 08), Apr. 2008.
21. D. Dhoutaut, A. Regis, F. Spies, Impact of radio propagation models in vehicular ad hoc net-works simulations, in: Proceedings of the 3rd International Workshop on Vehicular Ad Hoc Networks, Los Angeles, September 2006, pp. 4049.
22. S. Moser, F. Kargl, A. Keller, Interactive realistic simulation of wireless networks, in: Proceedings of the IEEE Symposium on Interactive Ray Tracing, Ulm, September 2007, pp. 161166.
23. E. Weingartner, H. von Lehn, K. Wehrle, A Performance Comparison of Recent Network Simulators Proceedings of the IEEE International Conference on Communications, Dresden, May 2009, pp. 15.
24. Ms. Ashwini B. Abhale, Mr. Sumit A. Khandelwal, Prof. Uma Nagaraj ,Shifting VANET to Cloud Survey, International Journal in Advance Research in Computer Science and Software Engineering (IJARCSSE), Volume 3. No.11 NOV 2013 ISSN No- 2277 128X.
25. Ms. Ashwini B. Abhale, Mr. Sumit A. Khandelwal, Prof. Uma Nagaraj , Novel Approach to-wards Accidents Prevention Using Vehicular Ad-hoc Network under Cloud Environment, International Journal of Advanced Technology Engineering Research (IJATER), Dec 2013, ISSN No- 2250 3536. Impact factor 0.56
26. Ms. Ashwini B. Abhale, Mr. Sumit A. Khandelwal, Mrs. Uma Nagaraj, Motivation towards Cost Effective Roadside Communication Techniques Vehicular Cloud Environment, International IEEE conference, ISBN No- 978-1-4799-3759-2.
27. Mr. Sumit A. Khandelwal, Ms. Ashwini B. Abhale, Prof. Uma Nagaraj, Accident Prevention and Air Pollution Control using VANET under Cloud Environment., Proceedings of Elsevier Science and Technology, ISBN No: 978-93-5107-220-1, Volume 2.

Frequently asked questions

What is the main topic of this document?

This document outlines a dissertation plan for providing Software as a Service (SaaS) in Vehicular Ad hoc Networks (VANET) using a cloud environment.

What is a VANET?

A VANET is a Vehicular Ad hoc Network, a type of mobile ad hoc network that uses vehicles as nodes to create a mobile network.

What is meant by "providing Software as a Service in VANET using Cloud Environment"?

It refers to utilizing cloud computing principles to offer various software services to vehicles within a VANET. This can include services like navigation, traffic information, safety alerts, and infotainment delivered over a cloud infrastructure.

What are the objectives of the dissertation?

The objectives include:

• Creating a vehicular cloud and providing services like Network as a Service (NaaS) and Storage as a Service (SaaS).
• Providing real-time and historical traffic information.
• Providing noise and pollution information.
• Tracking vehicles and their geographic locations.

What software is used in the project?

The project utilizes software such as JAVA, Python, PHP, MySQL, HTML, and tools like SUMO (Simulation of Urban Mobility), JOSM (Java Open Street Map), and Notepad++.

What is SUMO?

SUMO (Simulation of Urban Mobility) is an open-source traffic simulation package used to simulate vehicle movement and traffic flow in urban environments.

What are some of the challenges addressed in the dissertation?

The dissertation addresses challenges such as high node velocity in VANETs, mobility constraints, dynamic network topology, and the cost of infrastructure.

What are the key benefits of using a cloud environment for VANETs?

Key benefits include cost reduction (by renting resources instead of buying), improved scalability, better resource utilization, and enhanced data accessibility.

What are some of the applications of this research?

Applications include improved road safety, traffic management, infotainment services, electronic toll collection, and access to internet and location-based services.

What is the problem statement addressed by the dissertation?

The problem statement focuses on minimizing challenges in VANETs, such as node velocity and movement patterns, by finding unused resources of vehicles and providing software as a service (Network as a Service and Storage as a Service) in vehicular ad-hoc network (VANET) under cloud environments.

What are the different modules in the proposed system?

The modules include:

• Implementing the map.
• Creating a trip file.
• Creating a route file.
• Creating a configuration file with simulation settings.
• Generating expected results.
• Proving Network as a Service (NaaS).
• Creating a cloud server and proving Storage as a Service (SaaS).

What performance metrics are used to evaluate the system?

Performance metrics include:

• Time vs. speed relationship.
• Location of vehicles.
• Latitude vs. longitude.
• Fuel consumption.
• Vehicle type detection.

What is the future scope of this dissertation?

Future enhancements include addressing privacy and security concerns in vehicular clouds.

What are the main components of the proposed vehicular cloud architecture?

The main components are Vehicle-to-Vehicle (V2V) communication, Vehicle-to-Infrastructure (V2I) communication, Roadside Unit (RSU) to Static Cloud communication, and Vehicle to Dynamic Cloud communication.

What are the different test types used to validate the system?

Testing included Black Box testing, White Box testing, Unit testing, Integration testing, and Validation testing.

• College: Savitribai Phule Pune University, formerly University of Pune (MIT Academy of Engineering , Alandi)
• Course: Computer Engineering
• Author: Ashwini Abhale (Author)
• Publication Year: 2014
• Pages: 124
• Catalog Number: V277717
• ISBN (eBook): 9783656704089
• ISBN (Book): 9783656706618
• Language: English
• Product Safety: GRIN Publishing GmbH