VCR: Vehicular Cloud for Road Side Scenarios

Dimal Baby, R.D. Sabareesh,

R.A.K. Saravanaguru, and Arunkumar Thangavelu

School of Computing Science,

VIT University, Vellore
{dimalbaby,rd.sabareesh,sarophd,
arunkumar.thangavelu}@gmail.com

Abstract. Cloud computing [1] enables the end users to access the required
services on demand without worrying where they actually exists. It delivers
everything as a service and is generally termed as XaaS. Nowadays cloud
infrastructure becomes popular as it provides services in multiple domains like
business, social networking, scientific application, education, gaming etc.,
Vehicular networks [2] as an emerging research area by implementing different
networking technologies for safety and non-safety applications. This paper
investigates the utilization of cloud computing concepts in vehicular
applications. The need for developing a cloud based architecture and the state of
art about the cloud services are discussed. In this paper we present VCR
(Vehicular Cloud for Road side scenarios) an architecture that provides safety
and non-safety services in vehicular applications. Specifically private and
public vehicular cloud prototypes are proposed to provide appropriate services
for road side scenarios. The performance of the system is evaluated with the
simulation results.

1 Introduction

Vehicular Ad-Hoc network is a form of Mobile ad-hoc Networks, to provide

communication among nearby vehicles and between vehicles and nearby fixed
equipment i.e. roadside equipment [3]. The main goal of VANET is to provide the
awareness to the vehicles about the safety measures and alert messages. The vehicular
communication can be classified as vehicle to vehicle communication (V2V) and
vehicle to infrastructure communication (V2I) [3]. Vehicle to vehicle communication
(V2V) [18] is an infrastructure less communication where it is used to communicate
with other vehicles directly in a particular range. Vehicle-to-Infrastructure (V2I)
communications for safety is the wireless exchange of critical safety and operational
data between vehicles and roadway infrastructure, intended primarily to avoid motor
vehicle crashes [4]. The communication between the vehicles can be done through
DSRC, Wi-Fi, and WAVE. Dedicated short-range communications (DSRC) [5] are
one-way or two-way short- to medium-range wireless communication channels
specifically designed for automotive use and a corresponding set of protocols and
standards. Wireless Access in Vehicular Environment (WAVE) [6] required to

N. Meghanathan et al. (Eds.): Advances in Computing & Inf. Technology, AISC 178, pp. 541–552.
springerlink.com © Springer-Verlag Berlin Heidelberg 2013
542 D. Baby et al.

support Intelligent Transportation Systems (ITS) applications. This includes data

exchange between high-speed vehicles and between the vehicles and the roadside
infrastructure. The cloud computing paradigm provides a lot of opportunities to the
developers and providers. Cloud computing is location independent computing,
whereby shared servers provide resources, software, and data to computers and other
devices on demand, as with the electricity grid [3]. There are three categories of
clouds-public cloud, private cloud and hybrid cloud. Cloud offering as a service over
the Internet is the public cloud hosting solution. Whereas, a private cloud is the
deployment within the firewall and its management is taken care by the user
enterprise. Mainly there are three categories of services that are provided by the cloud
environment-Software as a service (SaaS), Platform as a service (PaaS) and
Infrastructure as a service (IaaS) [7]. In the software-as-a-service cloud model, the
vendor supplies the hardware infrastructure, the software product and interacts with
the user through a front-end portal. Platform-as-a-service in the cloud is defined as a
set of software and product development tools hosted on the provider’s infrastructure.
Cloud infrastructure services or infrastructure as a service delivers computer
infrastructure, typically a platform virtualization environment as a service. In this
paper we are more concentrating on software as a service (SaaS) [8] which is also
known as application as a service. Depending on the application we will deploy
services either in public or in private cloud. Sometimes the private cloud needs to
access the public cloud to perform some work.

2 State of Art

In the public and private cloud the vendors like Amazon [9], Microsoft Windows
Azure [10], Google App Engine [11], Eucalyptus [12], and Microsoft Hyper – V [13]
are more concentrated on Web 2.0 like social networking sites (flicker, face book,
twitter), and Web 3.0 which is concentrated on semantic web.
In the future we assume that every vendor will extend their Cloud Services over
Vehicular Network for safety and non-safety applications. So, far there is no cloud
based architecture exists for vehicular communication.

3 Overall System Architecture of VCR

Figure 1 shows the architecture of VCR (Vehicular Cloud for Road Side Scenario)
which provides the complete communication between vehicle to vehicle and vehicle
to infrastructure. Our proposed architecture can be divided into two-communication
through public cloud and communication through private cloud.
 VCR: Vehicular Cloud for Road Side Scenarios 543

Fig. 1. Vehicular Cloud for Road Side Scenarios

3.1 Public Vehicular Cloud

Public cloud comes into picture as a part of road side unit (RSU).These road side
units acts as a mediator in the public cloud environment where we are concentrated
more on the SLA(service level agreement) [14]. We can view it in different
perspective depending on the access rights and permissions of a particular user that
uses the services. We can define it as a negotiation between provider and the
consumer. So the major responsibility of this RSU is to ensure that it is satisfying all
SLA with specified accuracy. The RSU is also responsible for checking whether the
information from a vehicle is correct or wrong. It is directly connected to the public
cloud. Once the vehicle is able to access the public cloud it can access anything and
everything through cloud. The services from cloud environment we can again
classified as automatic services and services on request. No one can stop this
automatic service, for example alert notification. There is one on board unit (OBU)
for each vehicle to get all the information such as speed, tyre pressure etc. It is
responsible to communicate with either to its own private cloud or in public cloud.
The services from public cloud we can specify in term of users. Here it is mainly two
things-safety services especially to the drivers and the entertainment services. Just by
sitting inside a vehicle one can even develop some high end applications, so that he
can efficiently utilize his time while travelling. In VCRS we have a number of
modules as part of public cloud.
544 D. Baby et al.

Fig. 2. Public Vehicular Cloud

SLA
Service Level Agreements form an important part in measuring the performance of
applications and the infrastructure. In the Cloud environment since an application's
performance depends on a number of factors including different resources, there is
a need to track these SLA metrics across different granularities namely - Business
level, Application level and Resource level. Consider a user whose requirement is
4 sec to get a response for an application. Suppose that application uses servers
like application and web server. In this case the application would satisfy the
business level agreement only if: Response time of application server + Response
time of web server less than 4sec.
Service provisioning
Today, independent service providers and vendors are concentrating more on
service provisioning automation to speed up the delivery [15]. So far we have
mentioned in terms of application as a service. We can think about other cloud
services also. For simplicity here we are giving only some services (SaaS) like v-
call, traffic services, and location awareness services, which don’t mean that the
services are limited to those areas. We assume that every service have already
deployed in separate registry.
V-call
It calls the emergency services manually or automatically when any accident
happens, so that it reduces the response time. It sends the information in the form
of v-data set (VDS) to the service deployed in cloud. The VDS consists of time of
accident, exact location including driving direction and vehicle identity. V-calls
also provide a safety alert to the driver when he is unconscious.
 VCR: Vehicular Cloud for Road Side Scenarios 545

Traffic services
Traffic services means any situations like congestion, accidents have to be
reported, which is an example of automated service. This information is
communicated through RSUs. If the driver is able to identify such situation then he
can select an alternate path also from the location services and continue his
journey.
Location aware services
The location services are mainly focusing on the landmarks services such as nearby
hospitals, ATM locations, service stations, parking locations, toll collection and so on.
This is also an example of service on request type.

3.2 Private Vehicular Cloud

For the vehicle to vehicle communication (V2V) consider an adhoc form of private
cloud to solve the interoperability issues and safety measures. The private cloud will
reside in each vehicle i.e. in the on board units (OBU) to maintain frequent update of
their proximity information. The main purpose of the private cloud residing in OBU is
that each vehicle is manufactured by different vendors with different OBU, when data
exchange between vehicles may have interoperability issues; to avoid the problem
private cloud is being setup in the vehicles. DSRC/WAVE/ Wi-Fi/WiMaX/CALM is
used for communication between vehicle to vehicle (V2V) [16].
We assume that the all the vehicles have their unique identity and their registry
keys so that when they access or publish any service they can directly communicate to
other vehicles. In the private cloud consider two application programmable interface
(API), one is Inquiry API [17] which can be used to search or browse through the
information contained in a Discovery Registry. Second, Publisher API [17] is used to
store, to update, and to delete or hide information in the registry. Like all APIs that
store data, the data being stored ideally takes typical subsequent query operations into
account. In other words, appropriate data has to be stored to allow the inquiries to
produce meaningful results.
Inquiry API will find the services like the neighboring vehicles information and
then pass it between the vehicles. The information may be knowing the neighboring
nodes, distance between the vehicles, alerting other vehicles about the accident
happened within the region and so on. Similarly the publisher API will update their
information about the vehicle, and other vehicles can use those services like vehicle
information, data available in other vehicles. When vehicle suddenly occurs break
failure then it will broadcast the message to other vehicles with in that specific region.
Suppose one vehicle wants to find the information about the other vehicles it will find
the services through inquiry API then they will access directly to get the information.
The discovery interface defines the methods set forth by the discovery specification to
interact with the registry.
The discovery contains a collection of services provided for the V2V i.e. alert and
data exchange services. Alert services like accident messages, road conditions, traffic
congestion with in a specific range, every vehicle can broadcast messages to the other
vehicles directly or position based routing protocols. Data exchange mechanism
includes sharing safety related services for drivers and infotainment services through
dash boards for passengers.
546 D. Baby et al.

4 Message Data Format

The information exchange between the vehicles is through messages. There should be
a common message format which will be able to understand vehicles each other. Let
us discuss a proposed format for public and private messages in depth.

4.1 Public Message Data Format

In a multi-tenant cloud environment, to identify a message it has separate fields to

specify the cloud provider, the id of vehicle, the type of message, data and the error
checking field. The registered unique ID and account will keep track all the
information about a particular vehicle. All penalty amounts will be detected from that
account and any dues will be intimated to the owner. The purpose of Cloud identifier
is to identify cloud provider uniquely. The services provided various from vendor to
vendor. So it is important to have a cloud ID to specify a particular provider.

(3)

(4)

Fig. (3). & Fig. (4). Public Message Data Format, Message Type

There are four different types of messages

Short Message Type (S):- To send an alert messages or warning messages use S bit as
1 otherwise 0.
Media Message Type (M):- To get a entertainment services from cloud set Media (M)
bit as 1 otherwise 0.
Priority Message Type (P):- To end the alert messages or urgent messages set
priority message as 1 and also set the short message bit also 1.
Acknowledge (A):- Confirmation to delivery of messages.

4.2 Private Message Data Format

Public message need to have more fields compared to the private message. so we need
a separate message format for private message transfer. In private cloud we will be
concentrating more on vehicle to vehicle communication. The communication can
be one to one or one to all. So it is important to have a broadcasting field and
the timestamp for private messages. If we are using DSRC for short range
communication, the vehicles within its range will be receiving a message if it is a
broadcasted one.
 VCR: Vehicular Cloud for Road Side Scenarios 547

Fig. 5. Private Message Data Format

Generally the private cloud is used for the sending the alert messages like the
accidents, road blocked, call for the ambulance for emergency services etc. When
vehicle wants to send the alert messages, warning messages then it should broadcast
to the vehicles directly, for that purpose broadcast field is needed. To broadcast the
message to the vehicles the 8 bit must be set to all 1s.

4.3 Symbols

The symbols represent the different signs for the messages. For example when you
want to mention the warning message you can send the warning images so that
anyone understands easily the symbols. For those who are not understood the
language they can understand easily the pictorial representation. The symbols play a
major role for understating things quickly. In Figure 6 we have given some of the
symbols and its meaning. It can be varied depends on the application and its
importance.

Fig. 6. Safety Measure Symbol

548 D. Baby et al.

5 Implementation
In the implementation part we have concentrated mainly on private and public cloud
setup for the road scenario.

5.1 Public Vehicular Cloud

We accessed Google App Engine Cloud environment to deploy our public services.
For simplicity we will talk only about a simple service. The deployment of services
requires three phases.
Application ID: Application ID is used to identify a particular application in the
Google-app-Engine.
Deploy: In this phase you can deploy your application in the Google-app Engine
with the help of some xml _les. Figure 7 is an example of appengine-web.xml.
Publish: In this phase you can establish a connection to the deployed application in
the Google-app-Engine.

Fig. 7. Appengine-web.xml
 VCR: Vehicular Cloud for Road Side Scenarios 549

5.2 Private Vehicular Cloud

In private vehicular cloud we considered JUDDI private registry[17] which is

developed by apache. It’s a java based Universal Description, Discovery, and
Integration. In each vehicle we setup one JUDDI private registry to communicate with
each other. So, that interoperability issues is solved The UDDI specification describes
the XML schema for this information model, SOAP messages to transport the XML-
based information, and a set of APIs to manipulate and manage the UDDI data. There
are two key APIs: the UDDI inquiry API, which can be used to search or browse
through the information contained in a UDDI Registry, and the UDDI publication
API, which enables programmers to create or delete the information structures within
a UDDI Registry. Invoking a UDDI API results in one or more SOAP messages being
generated. This UDDI XML schema deals with the following six types of key
information as it relates to service providers.
• Business information pertaining to a business or organization providing one or
more services which, in the context of the UDDI model, is referred to as the
businessEntity.
• Sets of related services (e.g., a set of Web services concerning purchase order
processing and another set concerning online inventory checking) being offered by
a previously described business or organizations which are referred to as
businessService elements.
• The binding information necessary to invoke and make use of a particular,
previously described, service (whether a Web service or otherwise) referred to as a
bindingTemplate element.
• More technical information (or even a technical blueprint) about a service, over
and above the binding information necessary to connect to it, such as pointers to
detailed specifications, protocols used by the service (e.g., SOAP, HTTP, or SMTP
in the case of a Web service), and possible type classification for that service
which is known as a technical model (tModel).
• Relationships between business or organization entities (e.g., certification,
alliances, membership, trading partnerships, and so forth), asserted to by one or
both of those entities. This data structure, referred to as publisher Assertion.
• Standing orders subscribed to by companies, organizations, or individuals
requesting automatic notification in the event of a change to specific entities within
the UDDI registry. This data structure, used for such automated change
notification, is referred to as operationalInfo. It is used, at present, to provide a
change-order subscription mechanism. Consequently, this data structure is also
sometimes referred to as subscription.

Inquiry API Functions

Find Function – find_binding, find_business, find_service, find_tModel are used for

searching the specific service.
Get functions – get_bindingDetail, get_businessDetail, get_serviceDetail,
get_tModelDetail are used for retrieving the specific service
550 D. Baby et al.

Publisher API Functions

Authentication Functions – get_authToken: Requests an authentication token from the
operator site. An authentication token is required for all subsequent save and delete
functions. Discard_authToken: Requests that the specified authentication token be
discarded and invalidated.

Save Functions – save_binding, save_business, save_service, save_tModel all these

are used for insert or update a new service.

Delete Functions – delete_binding, delete_business, delete_service, delete_tModel are

used for deleting a service. A hidden tModel record can still be referenced by another
UDDI record (e.g., a bindingTemplate record), but it will be excluded from search
results generated by the find_tModel function. tModel records cannot be deleted.
The exchange of information between the vehicles is through SOAP messages.
It consists of two types
1. Soap RPC style it contains request and response messages.
2. Document style it contains only notify messages or just sends a message without
any request.

For implementation we need Apache Tomcat 7, Eclipse Helios, MySQL-connector-

java-5.1.15, mysql-5.0.27-win32. Once all required software’s are setup, implement
an alert service application and it generates the WSDL (Web Service Description
Language) .WSDL contains self-described functionality about the service. The
abstraction provided by WSDL and the SOAP binding included in WSDL allow for
the encapsulation of service-based components. WSDL _le is to be published in the
JUDDI private registry which is in the vehicles using the publish API. To access the
services automatically by the other vehicles uses the Inquiry API. Figure 8 represents
a sample code of WSDL.
 VCR: Vehicular Cloud for Road Side Scenarios 551

Fig. 8. Sample code for WSDL

6 Conclusion
In this paper, we proposed VCR, a Vehicular Cloud for Road side scenarios that aims
at providing appropriate services through private and public vehicular cloud
environments. Any additional services can be dynamically added in the vehicular
cloud environment through the Publish API, shared and accessed between different
vehicles through SLA (Service Level Agreements) and Inquiry API. Thus different
types of vehicles can share the safety and non-safety services provided through this
infrastructure to achieve the maximum benefits. As a preliminary part of VCR, we
tested the performance using jUDDI (Service Oriented Architecture Platform) and
GoogleApps. Our future work includes (1) Extending the public vehicular cloud of
552 D. Baby et al.

VCR for IaaS (Infrastructure as a Service) by utilizing the capability of vehicles that
can carry huge volume of memory without power constraints. (2) Implementing Vcall
(Emergency Services for Vehicles) for different situations like Remote Vehicle
Diagnostics and Assistance, Autonomic accident notification for Indian road
scenarios.

References
1. Buyya, R., Yeo, C., Venugopal, S., Broberg, J., Brandic, I.: Cloud Computing and
Emerging IT Platforms: Vision, Hype, and Reality for Delivering Computing as the 5th
Utility. Future Generation Computer Systems 25(6), 599–616 (2009)
2. Guo, H.: Automotive Informatics and Communicative Systems. In: Principles in Vehicular
Networks and Data Exchange. Information Science Reference, New York (2009)
3. Cloud Computing, http://en.wikipedia.org/wiki/Cloud_computing
4. Kannan, S., Thangavelu, A., Kalivaradhan, R.: An Intelligent Driver Assistance System(I-
DAS) for Vehicle Safety Modelling using Ontology Approach. International Journal of
UbiComp (IJU) 1(3), 15–29 (2010)
5. DSRC, http://Sae.org/standarddev/dsrc/
6. WAVE, http://en.wikipedia.org/wiki/WAVE
7. Buyya, R., Yeo, C., Venugopal, S., Broberg, J., Brandic, I.: Cloud Computing and
Emerging IT Platforms: Vision, Hype, and Reality for Delivering Computing as the 5th
Utility. Future Generation Computer Systems 25(6), 599–616 (2009)
8. Ranjan, R., Liu, A.: Autonomic Cloud Services Aggregation. CRC Smart Services Report
(2009)
9. Amazon Elastic Compute Cloud (EC2), http://www.amazon.com/ec2/
10. Windows Azure, http://www.microsoft.com/windowsazure/
11. Google App Engine, http://appengine.google.com
12. Nurmi, D., Wolski, R., Grzegorczyk, C., Obertelli, G., Soman, S., Youse, L., Zagorodnov,
D., et al.: The Eucalyptus Open Source Cloud Computing System. In: Proceedings of the
9th IEEE/ACM International Symposium on Cluster Computing and the Grid (CCGrid
2009), Shanghai, China (2010)
13. Microsoft Hyper V,
http://www.microsoft.com/hyper–v–server/en/us/default.aspx
14. Alhamad, M.: Conceptual SLA Framework for Cloud Computing. In: Accepted for IEEE
DEST 2010 (March 15 ,2010)
15. Buyya, R., Ranjan, R., Calheiros, R.N.: InterCloud: Utility-Oriented Federation of Cloud
Computing Environments for Scaling of Application Services. In: Hsu, C.-H., Yang, L.T.,
Park, J.H., Yeo, S.-S. (eds.) ICA3PP 2010. LNCS, vol. 6081, pp. 13–31. Springer,
Heidelberg (2010)
16. Saravanan, K., Thangavelu, A., Rameshbabu, K.: A middleware Architecture for Vehicular
Safety over VANET (InVANET). In: First International Conference on Networks and
Communications, Netcom, pp. 277–282 (2009)
17. Apache jUDDI, http://juddi.apache.org/
18. V2V,
http://en.wikipedia.org/wiki/vehicular_communication_systems