CROWN: Discovering and Consuming
Services in Vehicular Clouds
PHBLISHED : COMMUNICATIONS AND
INFORMATION TECHNOLOGY (ICCIT), 2013
THIRD INTERNATIONAL CONFERENCE ON,
ISSUE DATE: 19-21 JUNE 2013
AUTHOR : MERSHAD, K.; ARTAIL, H.
SPEAKER: 張任頡
STUDENT NUMBER:MA2G0106
Outline
1
I. INTRODUCTION AND BACKGROUND
II. THE CROWN FRAMEWORK
III. PERFORMANCE EVALUATIONS
IV. CONCLUSION AND FUTURE WORK
I. INTRODUCTION AND BACKGROUND (1/4)
2
1. Vehicular Ad hoc Networks (VANETs) allow vehicles
to connect to roadside units (RSUs), which connect
with each other via a wired network and with
passing by vehicles via wireless communications.
2. It is expected that future vehicles will be
equipped with advanced in-vehicle resources such as
powerful computing and storage devices, and
sensor nodes.
I. INTRODUCTION AND BACKGROUND (2/4)
3
3. In VANETs, Vehicular Clouds are distinctive in that
cloud servers are mobile vehicles with capable resources
and/or Internet access, whereas consumers are vehicles that
desire to rent the resources or gain Internet access. For this,
consumers need to discover the mobile cloud servers,
know their resources, and communicate and request
resources from them.
4. We propose a scheme that uses RSUs as cloud directories
to store information about mobile cloud servers, and
hence, form a distributed dynamic index of such servers. We
refer to the cloud server as “STAR”, and to the whole
system as “CROWN”.
I. INTRODUCTION AND BACKGROUND (3/4)
4
5. In this paper, we extend the concept of vehicular
clouds by enabling STARs to offer their various
resources via the RSU network. To the best of our
knowledge, we are the first to define the concept of
a STAR that offers its cloud services while it is on
the move. Our contributions also include identifying
the services that could be offered by a STAR and their
attributes.
I. INTRODUCTION AND BACKGROUND (4/4)
5
II. THE CROWN FRAMEWORK (1/11)
6
A. Vehicular Cloud Services :
1. Network as a Service or NaaS (Internet access): some
smart vehicles will have an Internet connection (e.g., via a
cellular network), but others do not. Vehicles with internet
access may offer their extra bandwidth to others.
2. Storage as a service or SaaS: some smart vehicles will
have high on-board storage capacity, but others may need
additional storage.
3. Data as a Service or DaaS: a vehicular user may need
specific data, for example, a video or music file. A STAR
may define part of its storage capacity as a data cache, and
use it to store data that it acquires for consumers.
II. THE CROWN FRAMEWORK (2/11)
7
B . Registration of a STAR at its Nearest RSU :
II. THE CROWN FRAMEWORK (3/11)
8
II. THE CROWN FRAMEWORK (4/11)
9
a. If the speed of the STAR is v, then the radius of AE
will be rE = 1.3×v×(t2-t1), considering a 30% error
factor. The area AE will be used by the RSU to define
to consumers the estimated location of the STAR.
b. As a STAR rents out its resources, its attributes
change. In such cases, the STAR adds the new values
of its attributes to the next beacon that it sends to its
nearest RSU R 1 , which in turn updates these values in
its cache and forwards the data to other RSUs in A I .
An RSU that stops receiving beacons from a STAR for
a given time (e.g., 10 sec) deletes the STAR’s RD.
II. THE CROWN FRAMEWORK (5/11)
10
C. Requesting to Rent the STAR Resources :
II. THE CROWN FRAMEWORK (6/11)
11
D. Finding STARs that Satisfy a Request :
a. In order to know whether the STAR will remain in the
VANET for a period of time greater than T a , the RSU adds
T a to current time and checks whether the result is less
than T l . The total conditions the STAR should satisfy is:
ConditionNaas = ( BWSTAR > BWuser) AND ( Da-STAR < Da-user )
AND ( Ca-STAR < Ca-user )
AND ( DistanceSTAR-STAR < Distanceto-STAR )
AND ( Tcurrent < Ta + Tl )
II. THE CROWN FRAMEWORK (7/11)
12
b. The total condition that the STAR should satisfy to meet
the user storage requirement is :
ConditionSaas = ( Sm-STAR > Sm-user) AND ( Tt-STAR < Tt-user )
AND ( Cs-STAR < Cs-user )
AND ( Ps ≥ ThPs )
c. The condition that a STAR must satisfy to fulfill a data
request is:
ConditionDaas = ( DTuser ⊆ DTuser)
AND ( Dc-STAR > Dc-user ) AND ( Cd-STAR < Cd-user )
II. THE CROWN FRAMEWORK (7/11)
13
II. THE CROWN FRAMEWORK (9/11)
14
E. RSU Reply to a User :
Once the RSU chooses suitable STAR(s) from L c
(based on the value(s) of R e ), the RSU sends a
reply that contains the following for each STAR
chosen by the RSU:
• ID of the STAR
• Last location of the STAR’s (from its last beacon)
• Last estimated area A E of the STAR (center, radius)
• The resources and attributes offered by the STAR
II. THE CROWN FRAMEWORK (10/11)
15
II. THE CROWN FRAMEWORK (11/11)
16
F. Consuming the STAR’s resources :
After a user chooses one or more STARs, he specifies the
required resources from each STAR. He then
formulates a service packet for each chosen STAR and
sends it using the routing protocol. The service packet
contains the user credentials and his request.
In CROWN, we focus on finding a way to discover and
choose the best STARs for consuming services. It should
beemphasized that the connection between a user and a
STAR should be tightly secured via a mobile security
system that insures the privacy and integrity of users and
the confidentiality and correctness of data.
III. PERFORMANCE EVALUATIONS (1/7)
17
· CROWN was implemented using ns2 software (with
802.11p and the Nakagami model). We used SUMO [7]
to generate the node movement file that was inputted
to ns2.
· The map used to generate the movement file has a
size of 9×9 Km2.
· The default number of vehicles was set to 300
· minimum and maximum speeds were set to 15 and
30 m/s
· Ten RSUs were deployed uniformly to nearly balance
their loads.
III. PERFORMANCE EVALUATIONS (2/7)
18
III. PERFORMANCE EVALUATIONS (3/7)
19
1. Compared Protocol and Comparison Parameters :
a. We compared CROWN with a cloud service
discovery protocol in which the various operations of
CROWN were replaced by broadcasting. We call this
protocol Broadcast-CROWN (B-CROWN)
b. where a STAR registers its services by
broadcasting to its neighbors a registration packet
with a TTL equal to 10. Each neighbor caches the
registration data, decrease the TTL by 1, and
rebroadcast the packet to its neighbors.
III. PERFORMANCE EVALUATIONS (4/7)
20
c. When a vehicle S needs a certain service, it searches
its cache for appropriate STARs. If it finds one, it sends
a service packet to it; else, S broadcasts a request
packet with a reqID and a TTL set to 5.
d. Each vehicle VI that receives a request packet
searches its cache for STARs that can execute the
request. If it finds, it unicasts a reply to S, provided it
has not forwarded a reply packet to S with the same
reqID (i.e., it did not detect another vehicle replying
before it).
III. PERFORMANCE EVALUATIONS (5/7)
21
e. If VI does not find such STARs, it decreases the TTL and
then rebroadcasts the request to its neighbors, if the TTL is
greater than 0 and if it did not forward a reply to S. When S
receives one or more replies, it chooses the best suitable
STARs.
f. The metrics used for evaluating the two protocols are the:
· Service Discovery Delay (D SD ): time between sending a
request and receiving the reply packet.
· Service Consuming Delay (D SC ): time between sending
a service packet and exchanging the first data packet.
· Percentage of Hits (P H ): percentage of requests to
which a reply is received.
· Vehicle Traffic (T V ): includes forwarded traffic.
III. PERFORMANCE EVALUATIONS (6/7)
22
3. Results and Discussions :
III. PERFORMANCE EVALUATIONS (7/7)
23
IV. CONCLUSION AND FUTURE WORK (1/1)
24
1. This paper presented a cloud service discovery protocol
for VANETs, where STARs were introduced as mobile
cloud servers that offer services to other vehicles.
2. We described how the network of RSUs can be exploited
to ease the operation of discovering the best candidate
STAR by the user.
3. The results of CROWN were compared to a
broadcasting-based protocol and results of some
parameters were calculated and discussed.
4. For future work, our main activity will focus on studying
the required security strategies for the system.
25
Thanks for your listening ~