1. 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 CROWN: Discovering and Consuming Services in Vehicular Clouds

2. Outline I. INTRODUCTION AND BACKGROUND II. THE CROWN FRAMEWORK III. PERFORMANCE EVALUATIONS IV. CONCLUSION AND FUTURE WORK 1

3. I. INTRODUCTION AND BACKGROUND (1/4) 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. 2

4. I. INTRODUCTION AND BACKGROUND (2/4) 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”. 3

5. I. INTRODUCTION AND BACKGROUND (3/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. 4

6. I. INTRODUCTION AND BACKGROUND (4/4) 5

7. II. THE CROWN FRAMEWORK (1/11) 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. 6

8. II. THE CROWN FRAMEWORK (2/11) B. Registration of a STAR at its Nearest RSU : 7

9. II. THE CROWN FRAMEWORK (3/11) 8

10. II. THE CROWN FRAMEWORK (4/11) a. If the speed of the STAR is v, then the radius of AE will be r E = 1.3×v×(t 2 -t 1 ), 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. 9

11. II. THE CROWN FRAMEWORK (5/11) C. Requesting to Rent the STAR Resources : 10

12. II. THE CROWN FRAMEWORK (6/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: Condition Naas = ( BW STAR > BW user ) AND ( D a-STAR < D a-user ) AND ( C a-STAR < C a-user ) AND ( Distance STAR-STAR < Distance to-STAR ) AND ( T current < T a + T l ) 11

13. II. THE CROWN FRAMEWORK (7/11) b. The total condition that the STAR should satisfy to meet the user storage requirement is : Condition Saas = ( S m-STAR > S m-user ) AND ( T t-STAR < T t-user ) AND ( C s-STAR < C s-user ) AND ( P s ≥ Th Ps ) c. The condition that a STAR must satisfy to fulfill a data request is: Condition Daas = ( DT user ⊆ DT user ) AND ( D c-STAR > D c-user ) AND ( C d-STAR < C d-user ) 12

14. II. THE CROWN FRAMEWORK (7/11) 13

15. II. THE CROWN FRAMEWORK (9/11) 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 14

16. II. THE CROWN FRAMEWORK (10/11) 15

17. II. THE CROWN FRAMEWORK (11/11) 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. 16

18. III. PERFORMANCE EVALUATIONS (1/7) · 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 Km 2. · 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. 17

19. III. PERFORMANCE EVALUATIONS (2/7) 18

20. III. PERFORMANCE EVALUATIONS (3/7) 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. 19

21. III. PERFORMANCE EVALUATIONS (4/7) 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 V I 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). 20

22. III. PERFORMANCE EVALUATIONS (5/7) e. If V I 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. 21

23. III. PERFORMANCE EVALUATIONS (6/7) 3. Results and Discussions : 22

24. III. PERFORMANCE EVALUATIONS (7/7) 23

25. IV. CONCLUSION AND FUTURE WORK (1/1) 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. 24

26. Thanks for your listening ~ 25