A Study on Personalization and Customization Mechanisms of ...

2014 IEEE/ACM 7th International Conference on Utility and Cloud Computing

A Study on Personalization and Customization Mechanisms of Vehicular Cloud Platform Muhammad Sarim Zafar

Farhan Ahmad

School of Computing and Mathematics University of Derby, United Kingdom Email: [email protected]

University of Bremen, Germany Email: [email protected]

Abstract—This study discusses the concept of personalization and customization mechanism performed specifically for a cloud based vehicular platform. The proof-of-concept prototype allows the user to create a personalized environment on the Vehicular On-Board Unit (OBU) from hand-held devices of vehicular users. The paper discusses an extensive analysis on different type of vehicular users using different type of services, methodologies to use intermediary component between the vehicle and service providers in-order to personalize OBU. For this purpose, we have defined methodologies both for the service providers and vehicular users. For users, we have enabled peer-to-peer application layer personalization including the module of object storage on cloud. For service providers we have illustrated the idea of an engine allowing them to orchestrate services with respective to the user-types. Although it was implemented as a proof-of-concept system but it can be easily applicable for various users, service providers and hence can be extended further.

providers to provide scoped services as per user-type and enforce policies on the OBU, it is referred in this study to be as the customization of OBU. On the other hand, user can make application level changes and allow to transfer their application files, images and documents using peer-to-peer and cloud infrastructure, referred in this study as personalization. II. S TATE - OF - THE - ART In this section we will be enlisting some of the technologies which remained the part of this study. A. Android Wi-Fi Direct When the Google Android was launched back in 2007, the main motive was to provide maximum available support to the developers for mobile devices. The idea was to integrate Android with the embedded devices with tremendous support and security while executing the third party applications. Therefore, in this study we have made the innovative extension to Google Android for the vehicular users. The prototype have been developed on Android aiming to achieve the personalization for the users on vehicular on board unit, not only communicating on a peer-to-peer infrastructure but also with the cloud storage for backup operations. A recent advancement in Android was made on the connectivity front, by introducing the Wi-Fi Direct [10] allowing the user to build rich peer to peer applications. Hence, for peer-to-peer communication, WiFi Direct API was employed for a faster and secure application level transfer to the OBU.

I. I NTRODUCTION The vehicular community has increased enormously over the last few years and introduction of various technological innovation in the industry have proved to be potential player in providing solutions in safety on road environment and traffic management [20]. The future of vehicular telematics requires to meet the end-user requirements which are available on their portable devices and will be beneficial for the profitability of stake-holders, from a common driver to service provider. Hence to meet demands; organizations are coming up with network architecture which is scalable, flexible, secure and hybrid; allowing the cars to interact with several networked entities. They are called as Car2X systems [8][9] which establish communication between Car-to-Car [9] or Car-toInfrastructure but also permits the vehicular users to communicate with the Car. Along with that, with advent of vehicular cloud network [6][7][18] and considering the Car2X factor, we can predict that in future, techniques of cloud computing will be utilized by users as well as service providers [19] with a wish to completely customize vehicular OBU as per requirements, where a vehicular user would not only request particular services from service providers but can also have the capability to transfer their contents to the OBU. In this study we have developed novel approaches for vehicular users and service providers to personalize and customize the vechicular OBU. For service providers, we have presented an illustration of service orchestration engine which can allow the service 978-1-4799-7881-6/14 $31.00 © 2014 IEEE DOI

B. Openstack Object Storage For the purpose of allowing the user to create backup of their files from OBU, the study mainly relied on cloud storage. Several current technologies such as Swift (Openstack) [1][2], Cumulus (Nimbus) [16] and Walrus (Eucalyptus) [17] can be used as repository but studies like [15] present that swift is a fault tolerant and scalable storage solution in comparison to other available solutions. Meanwhile, swift API consists of a proxy server through which storage operation can be performed via HTTP API by performing standard HTTP methods that is GET, PUT, POST, DELETE to handle the requests between the clients and storage. In the upcoming section we have mentioned details of methodologies performed for storing backup on swift storage. 812

III. P ERSONALIZATION FOR V EHICULAR U SERS Personalization for vehicular user can be defined as any activity that tailors the services to the particular users, or set of users. Generally, the experience of the personalization can range from buying a smartphone for personal use to the purchasing of a car or renting from rental agency. Hence, these actions range from realizing the needs of the user to provide them customized information services. Previously web personalization have gained a lot of popularity from the web customization process[4] in which the organizations identify the needs of the user and provide them advertising services, shopping services, filtering as well to the users. Studies such as collaborative filtering [11][12][13][14] have also defined approaches in the past which takes the explicit information keeping in view the user preferences through a correlation engine and return the information based on the user preference. Whereas studies such as [5] are based on the Content based filtering for web-users where services and contents are offered based on the contents received from the user. Hence, on the basis of the studies [3][4], an extension was made on personalization and customization process for vehicular platform which have been depicted in Fig. 1. The figure is generic architecture for personalizing the on board units as per preferences of the user as well as keeping in view customization needs for the service providers.

Fig. 1. Generic architecture for vehicular personalization and customization

many users can have similar interests and therefore request similar services from the service provider. Predictability between the user and service provider can also improve the customization in the vehicular devices. • Presence of a uniform recommendation engine which can easily integrate different kinds of user profiles and services. For this purpose, we have realized this fact and provided with this study, an idea of Service Orchestration Engine (SORE); the online component for service provisioning and policy handling for service providers for their vehicular users. 3) Personalization and Customization module : This is the main component where our main study is based on. The Personalization and Customization engine is the component to recommend set of services and application to the vehicular users. Fig. 1 and Fig. 2 describes the over-all architecture allowing the user to connect with the vehicular OBU and then using the OBU to communicate with the cloud services. This architecture can be further exploited by the service providers in order to provide services and user-clustering via dataprocessing model from personal devices and OBU of the vehicle. Following were the factors that were taken into account: a) Service provider can be able to store short-term history which can be considered relevant for making recommendations. b) A measure of significance for each recommendation can be calculated and presented with proper rankings based on domain knowledge or structural characteristics. During this study, we have identified several set of services in the upcoming section

IV. A RCHITECTURE The vehicular architecture for personalization should consist of the following: 1) Data processing module: This is the prerequisite step towards any service discovery. This is the module which should be able to create set of services, phone logs, user identity which are being used by the user and pass it to the service identification module where relevant services can be clustered in accordance to the user preferences. 2) Service Identification module: This module involves in vehicular identification, service provider identification and user identification which will contain the user type as well. The main task is to generate relevant services which can be aggregated with the user preferences list and user type. Hence, to provide quality personalization to the vehicular users, we have identified following important characteristics: • Providing user with the power to deploy his/her contents directly or indirectly on the vehicle using their mobile phones. Hence, this activity emerged as prototype during this study. • The second is the customization module, which is also a future recommendation for the vehicular service provider. This module is responsible to capture the most used and common services provided to the user and identify the user-types who can be interested in those services, as it is possible that

813

which can be utilized by service provider inorder to provide user with scoped services.

• •

Personal infotainment and media. Navigation to frequently visited places.

3) Vehicle related services V. U SER AND S ERVICES I DENTIFICATION

•

In Table I we have presented an idea of scoped services where a particular user will have access. For example, drivers will be only entitled to utilize the services therefore they can have the access to the service enablement layer, while all the other users such as service providers, original equipment manufacturers (OEMs) and garages can have access to the underlying layers of the OBU. In order to further understand our users and services, we have defined, identified and categorized them below: 1) Users: Service users are the end-users (internals or externals) which will be using different car services offered by service providers. Users can be categorized in two types: • Active Users: End-Users of services who access services from inside the car. • Passive Users: User accessing services outside of the car (Remotely). 2) Providers: Organizational sub-unit which tends to provide services to the internal and external users of car with respect to their scope access.

Remote vehicle services a) Remote diagnostics.

•

Local vehicle services a) Local diagnostics

4) Roadside related services • • •

Traffic related and routing management services. Emergency road services. Parking assistance.

5) Special purpose services • • • •

Fleet Management. Logistic services. Financial services. Insurance. Application Layer

Temporary drivers Permanent drivers Professionals Manufacturers OEMs Garages Data Aggregator

A. User types and groups 1) Active Users: • Drivers: a) Temporary drivers. b) Professionals. c) Permanent drivers. • Passenger: a) Temporary passengers. b) Permanent passengers. 2) Passive Users: • Primary/Fundamental car users a) Manufacturers. b) OEMs. c) Network Service providers. 3) Data aggregator (e.g. advertisers) A vehicle can be offered with different types of services to the users, in collaboration with service providers, OEMs and cell phone service providers. Furthermore, in the coming sections, we have illustrated the type of services which will be accessible to different users, with respect to the classification of user in Table(1).

Yes Yes Yes Yes Yes Yes Yes

Application and Service Enablement Layer Yes Yes Yes Yes Yes Yes Yes

Communication Services Layer

Connectivity Layer

Components Layer

Yes Yes Yes Yes Yes

Yes Yes Yes -

Yes Yes Yes -

TABLE I S COPED ACCESS OF S ERVICES W. R . T THE USER - TYPE

VI. I MPLEMENTATION AND D ESIGN A. Components Fig. 2 depicts the following main components for the prototype: 1) Wi-Fi Direct activity: This activity is mainly responsible that uses Wi-Fi Direct API to discover and connect with the online peer. This activity is basically asynchronous and it rely on the call-back method using interfaces and respond with the status that whether the operation has been successful or not. This activity also checks if the Wi-Fi of the device is turned on or not. If it is turned off, it will not be notifying us as the main notification will be generated by the Broadcast receiver itself. This activity remains responsible to allow the user to create application level personalization on OBU.

B. Service categorization 1) Diagnostics • Local Diagnostics. • Remote Diagnostics. 2) Passenger related services • Safety.

814

   

    

      

  

    

  & $"%

 $"%

   $'

 $"%

'  '  $

       $     $  

  &

 $"%

 



             



 -.  

-.



 -.



 -. +

$   '-. /

 -.  $  -.

 

 -.

%  -. ! %  -.  

-.



-.



 $ -. $

 $ -.

  $"%

 $"%



 '  

 $"%

!"# 

with the management component of the Application layer of OBU present on Vehicle.

 

   $'

! %  "$  ($      ($ $ '  )% 

   $"%

  



"    

 %  * +%  

!  ),,,$

Fig. 3. Service Orchestration Engine as Tasks recommendation engine with respective to the user-types

 

Following are the parameters integral to generate task list to enforce services on OBU: 1) User type: This parameter will be determined from the OBU of the car and forwarded to the recommendation engine. The recommendation engine will then be able to scope down the services for vehicular user. 2) Services:This parameter enlists the number of services available to the user. 3) Architectural layer:Determines what type of architectural layer of OBU is accessible to the user for scopedservices. As depicted in Fig (4), the Service Orchestration engine has been designed in-order to be a sole entity for generating list of tasks for the vehicular users depending on their user-types and enforcing customization on the OBU. Hence, there are four major tasks of SORE, as a service for Vehicular Users:

Fig. 2. System Architecture

2) File transfer activity: This service is responsible to handle each file handle service on p2p infrastructure over wi-fi. Hence, this activity is responsible to open up the socket in both the devices i.e. between the OBU and the client and allow the client to write file to the memory of the OBU. 3) Content storage activity: Content storage is the HTTP service used to handle the requests between the client and storage. Openstack Swift have two main components, one being the proxy server while other being the object server. This HTTP service was built on standard requests codes allowing the user to use POST method to the Proxy Server. Proxy server sends this request to the storage server and user gets acknowledgment from the service, once the file has been stored on the storage. In this study, we have particularly considered images and documents as storage. B. Profiling Profiling remained as the integral part of this study particularly between the vehicular users and service providers. Profiling, in this study, is based on computing a set of recommended tasks based on the vehicular user-type and enforcing them on the OBU for the client. We named the profiling and customizing component to be ”Service Orchestration Engine (SORE)”. SORE is mainly the cloud based profiling service to customize the OBU for a user depending on the user-type. It is located as a service between the Service Providers and Vehicular Users. As illustrated in Fig .3, the three-dimension of the cube illustrate the fact that the response to the query/request from the user will be transmitted by considering three dimensions: User types, Services and architectural layers of OBU. Each layer communicates with the management component of its relevant layer. For example: For enforcing a new service policy, application layer from the SORE will be communicating

2  /   1 

 %&  %

3       

0 /  $   1 

  (

3   ' /$   ' 



 /

Fig. 4. Methodology for generating task-list and enforcing on OBU

1) Recognizing the user-type from the active session of OBU. 2) Distinguishing and mapping the tasks relevant to the user types and service layers. 3) Generating the task list for the User keeping in view the user-type. 4) Launching the tasks from list in-order to personalize OBU for the user. C. Methodologies 1) Uploading the file operation: A simple methodology for uploading the file have been described in [21] which we

815

extended it for uploading image files from vehicular OBU. The Fig. 5. illustrates the uploading process in which image file from OBU is stored. The application requires the authentication code to initiate the uploading session. The operation needs to passed with several parameters which includes user id, time stamp, API version and key. Once the session is authenticated, the application then calls for the upload method. This upload operation will contain the file content information for example it contains a check to determine whether the file is an image file, size of the image file, image name, and last modification time. During the implementation, the web-service of the openstack also allows to identify if the the image is being stored for the multiple times. Once the information is passed on to the storage service, it generates a content abstract of the image files based on hash algorithm. If the generated content is found consistent with existing abstracts of the image file, it is then considered to be a duplicate file and ignored for upload operation, results in returning back the image address on the swift storage to the OBU.

MAC address, name and identifying which one of the peers is the group owner. Once the group is create, Peer adapter instantiates the TCP connection among to peers for reliable data transfer.

  !  % ' /$

   $ ' /$

3 / 



  







3  -' 8 & 8% .

2  ' 

 

$

 

6

  

3 

' -*' 8,$$ 

.

 (%  '

    $  

%

7$  %

  73

  $   '

 $  '

''4%  -! .

*

Fig. 6. Peer-to-Peer APK Transfer process

The control is returned back to the owner of the group, which can now send the particular APK file from their personal smart phone. It is also important to mention that during the transfer, the status of the peers keeps on notifying whether any of the peer have gone offline. Once the file is received successfully, on the OBU, it determines the type of the file and performs the standard deployment procedure in Android.

( 1   $ 

 4% 

   " 



 4% 

2 1  

 $ , /$

VII. E VALUATION    5 " 

2 1    ' +

+ 

'    *

2  + $ ' 

A. Scenarios

 

6 2 '  $$



  

1) Considering the first scenario where the user comes near to the car and would like to initialize personalization on the OBU. For this purpose, we ran several tests on the system and at first we choose some test images and sent it to the OBU of the car from the client device. 2) From there, we considered that while the user had been in the car for a while and may have received several contents from their friends and family on the OBU of the car, therefore he would like to make backup of those contents. Considering this scenario, using our service and single application from the OBU, that allowed the user to transfer the image files to the cloud storage and the maximum image memory size which was uploaded was 5 MB.

 '

 '

3 ' $$

Fig. 5. File Uploading operation

If the content abstract does not found to be equivalent with any other abstracts, swift will allocate memory exactly to the size of the file. The HTTP service once receive the file and converts the format of the file so that the file can be browsed online from the management user interface. Once the file is stored, swift will generate abstract of the file based on hash algorithm to judge duplication for upcoming files. In the end, user gets the acknowledgment that file have been stored successfully. 2) Peer-to-peer Application transfer: The main task of this module is to transfer the APK (Android application packages) to the OBU and achieve the application level personalization. This process is well-depicted in the Fig. 6 where the user requests for the transfer of application files to OBU. Once the request is generated, discovery of peers are started using the WifiPeerManager from the Wi-Fi Direct API, allowing to enlist all the available peers. Once the peer is selected, peer information is retrieved in-order to make a group between the client and vehicle. This information mainly consists of

B. Environment of evaluations In order to understand and evaluate our efforts for the PoC on vehicular personalization, we considered using Android devices having update of Android 4.4.2, client side being the Nexus 4 whilst OBU was considered to be the Nexus 7 device. Meanwhile, temporary APK files were stored on the local storage of client device and dummy images on the OBU of different sizes. Also, to test and evaluate, following the setup of Linux Ubuntu 12.04 we deployed Openstack Havana release to provide virtualized swift storage. For testing purpose, we asked total number of four users to act accordingly in different scenarios.

816

C. Results of evaluation

We hope that it is going to be the future of the vehicular telematics and mobile computing using the techniques available from cloud infrastructure. Overall, we could comment that the study is an important initiative towards the concept of personalization and service orchestration as well as an introduction to cloud services on vehicular infrastructure that is dealing in holistic way with both vehicular users and service providers. As this is the first version therefore we can comment that it can undoubtedly be improved further to bring a utility into our lives.

1) For application level personalization, we allowed the user to select single APK file from their local storage which was reconfirmed by the client to get the application deployed on OBU. 2) In order to test our second scenario, we put dummy APK files on the local storage and allowed the client device to select multiple number of applications from the list they would like to deploy on OBU device. These APK files are then sent sequentially to the OBU, but because of user-based permissions security model on Linux based Android kernels, each APK file has to be reconfirmed by the client on the OBU whether the user would like to deploy the file on OBU or not. 3) We also found that multiple car-user can interact with the OBU hence allowing passengers along with drivers within the car as well to interact with the OBU and deploy their contents. But in the future release, we have decided to create restrictions and allow the driver to grant permissions to the potential users on OBU. 4) In order the consider the scenario where a single user initiates the uploading operation of multiple images to the storage, we allowed the user to select multiple number of dummy images from local directory. With one user, the images were uploaded perfectly. 5) Later, we allowed multiple users to interact with the cloud storage service and allowed similar images to upload on the storage server. Because of the content based hash storage, only one of those image files were stored hence declining multiple storage of same image file. Based on the results, we can acknowledge that the PoC came out to be a great initiative towards the idea of personalized vehicular platform for both users and service providers. Although, for the next release different maintenance and extension phases will be initiated towards storage, user experience when deploying contents from cloud to vehicle, having secured storage of stored files as well as handling multiple users on the OBU and defining restrictive policies as well as the development and integration of service orchestration engine described in the earlier sections.

R EFERENCES [1] OpenStack. (2013, Oct.) OpenStack Documentation. [Online]. Available: http://docs.openstack.org/ [2] OpenStack. (2013, Oct.) OpenStack Overview. [Online]. Available: http://www.openstack.org/downloads/openstack-overview-datasheet.pdf [3] Ming-Chiao Chen, Jiann-Liang Chen, Teng-Wen Chang. (2011). Android/OSGi-based vehicular network management system, Computer Communications. 34 169-183 [4] Bamshad Mobasher , Robert Cooley , Jaideep Srivastava Automatic personalization based on Web usage mining v.43 n.8, p.142-151, Aug. 2000: Communications of the ACM. [5] Joachims, T., Freitag, D., Mitchell, T. WebWatcher: A tour guide for the World Wide Web. August 1997: In Proceedings of the International Joint Conference in AI (IJCAI97). [6] European Commission Directorate-General Information Society and Media, ICT for Transport. Intelligent car brochure. [7] A. Jameel , M. Stuempfle , D. Jiang and A. Fuchs Web on Wheels: Towards Internet-Enabled Cars 1998: IEEE Computer Magazine. [8] European Commission Intelligent Car Initiative.[Online] 2010. [9] dSpace Car 2 Car Communication Consortium. [Online]. Available:http://www.car-2-car.org/2012. [10] D. Camps-Mur, A. Garcia-Saavedra and P. Serrano Device-to-Device communications with Wi-Fi Direct: overview and experimentation 2013: IEEE Trans. Wireless Communications, vol.20, pp. 96-104. [11] Jonathan L. Herlocker , Joseph A. Konstan , Loren G. Terveen , John T. Riedl Evaluating collaborative filtering recommender systems, ACM Transactions on Information Systems (TOIS) v., January 2004: 22 n.1, p.5-53 [doi¿10.1145/963770.963772] [12] Jonathan L. Herlocker , Joseph A. Konstan , Al Borchers , John Riedl An algorithmic framework for performing collaborative filtering August 15-19, 1999,Berkeley, California, USA: Proceedings of the 22nd annual international ACM SIGIR conference on Research and development in information retrieval. [doi¿10.1145/312624.312682] [13] Jonathan L. Herlocker , Joseph A. Konstan , John Riedl Explaining collaborative filtering recommendations December 2000: Proceedings of the 2000 ACM conference on Computer supported cooperative work, p.241-250,Philadelphia, Pennsylvania, USA. [14] Henry Kautz , Bart Selman , Mehul Shah Referral Web: combining social networks and collaborative filtering March 1997: Communications of the ACM v.40 n.3, p.63-65. [15] Henry Kautz , J. Diaz, G. Von Laszewski, F. Wang, A. J. Younge, and G. Fox Futuregrid image repository: A generic catalog and storage system for heterogeneous virtual machine images March 2011: In Proceedings of the 3rd IEEE Imernalional Conference on Cloud Computing Technology and Science. [16] Nimbus. Nimbus Project,Webpage. [Online]. Available: http://www.nimbusproject.org [17] Eucalyptus. Open Source Eucalyptus,Webpage. [Online]. Available: http://open.eucalyptus.com/. [18] Olariu, S., Hristov, T. and Yan, G. The Next Paradigm Shift: From Vehicular Networks to Vehicular Clouds 2013: In Mobile Ad Hoc Networking: Cutting Edge Directions, Second Edition (eds S. Basagni, M. Conti, S. Giordano and I. Stojmenovic), John Wiley & Sons, Inc., Hoboken, NJ, USA. doi: 10.1002/9781118511305. ch19. [19] Md Whaiduzzaman , Mehdi Sookhak , Abdullah Gani , Rajkumar Buyya A survey on vehicular cloud computing April 2014: Journal of Network and Computer Applications, 40, p.325-344, [doi¿10.1016/j.jnca.2013.08.004].

VIII. S UMMARY AND C ONCLUSION We have presented and described the approach and methodologies, in-depth on the study for personalizing and customizing the vehicular platform for vehicular users. This study describes concept of vehicular personalization and meanwhile also discusses the importance of customizing the vehicular platform along with that the methodologies to personalize OBU for users and service providers. As a proof of concept, we have developed the prototype for personalization combining the hybrid approach to personalize the vehicular OBU using peer-to-peer infrastructure from the client to vehicle and pushing the user contents from the OBU on the cloud storage. The software architecture, components of the prototype and results have been discussed in the paper.

817

[20] Fonseca A,VazoT Applicability of position - based routing for VANET in highways and urban environment 2013: Journal of Network and Computer Applications 2013;36:96173. [21] Yu Peng Cloud storage service in digital campus 23-25 May 2013 : 4th IEEE International Conference on Software Engineering and Service Science (ICSESS), 2013;36:96173.

818