Location Dependent Parking Service through Bluetooth

Suryanarayana. D.V

(dvsurya@yahoo.com)

Mariappan.V

(vbrms@yahoo.com)

Narayanasamy.P

(sam@annauniv.edu)

Department of Computer Science and Engineering, Anna University,

Chennai, INDIA – 600 025

Abstract

Mobile computing has induced a lot of killer applications recently by extending the parading of parallel and distributed computing across the mobile environment. An important class of applications involves the location dependent service of a mobile user. Two major issues must be addressed to deliver appropriate services to mobile users. One is the availability of a good location-positioning system and the second is an infrastructure that enables the positions to be tracked for the perusal of users’ application. This paper proposed the architecture that allows the mobile client to search for parking space, reserves the space and enters the parking slot through Bluetooth enabled devices.

Keywords: Location Dependent Service, Bluetooth, Distributed Computing

1. Introduction

In the past few years, the mainstream focus of mobile-service (M-service) researches has been rooted on the anytime – anywhere principle: request for services by mobile users should always be satisfied in an unchanged and transparent way, regardless of the time at which a service is requested and of the place from which it is requested [1,2]. The design and development of effective M-services should explicitly take into account the characteristics of the context from which a service is requested. In general, the capability of designing and deploying context-aware services [3, 4], i.e., services whose behavior can be dynamically adapted to the characteristics of the context, can provide a strongly added value to M-service technologies.

Several approaches for the provisioning of services to mobile users aim at supporting service availability from any place and at any time. However, most scenarios also require the enforcement of context-awareness, to dynamically adapt services depending on the context in which they are requested. Location Dependent Data (LDD) is defined as data whose value is determined by the location to which it is related [7]. Data kept for local events, local yellow pages are examples of LDD.

The rapid growth of the volume and diversity of data makes it very difficult for users to discover and know the correct sources of LDD for which they are looking. Thus, Local Dependent Services (LDS) are being developed to facilitate the mobile commerce needs for the mobile users. LDS are applications, which give the desired LDD results through user interfaces by using either a mobile user’s location or externally specified locations. Local directory services, hotel and restaurant, emergency services, location-based advertising and tourist are examples of LDS applications

In this paper a Middleware based approach is used to support LDS applications. Besides being independent of the underlying cellular technology, the middleware approach provides a more flexible and transparent framework for LDS applications. The middleware design facilitates the implementation of a flexible LDS support service, which could work with multiple wireless operators and content providers. In addition, very complex location binding can be supported. There is a need for a Location Dependent Service Manager (LDSM), a middleware between the mobile user and the applications, to provide this flexibility and functionality.

The rest of this paper is organized as follows: In Section 2 an overview of the system architecture is described. Location-dependent services and query processing is described in Section 3. Implementation is discussed in section 4. Finally the conclusion and the future research directions in Section 5.

2. The Architecture

Figure 1 depicts the proposed architecture, which consists of three major segments of system interaction: Wireless Communication Segment, Middleware Segment and Car Park System. The Bluetooth-enabled device in the vehicle can interact with the mobile service provider through the cellular network. The gateway can act as a router to forward messages between cellular network and the rest of the segments. The Middleware ensures the provision of location-dependent services and the processing of location information. The heart of the middleware is the LDSM, which provides location dependent query service and location service providers will offer data to support LDSM. It acts as a manager for different services, defining a unified interface for service providers on their APIs services specification. It also provides access control mechanism for users and their location information. This middleware uses access protocol, data format and remote method invocation to interact with the gateway and car-parking segment.

The Car Parking System consists of the Database Server and the Bluetooth-enabled device to find whether the particular vehicle occupies the reserved slot or not, and it is also responsible to inform the mobile user about the parking system and other data related to the car park provider.

3. Location Dependent Services and Query Processing

Figure 2 depicts the Middleware components, which includes Location Dependent Service (LDS) Application Server, Location Dependent Service Manager (LDSM), Location Dependent Query (LDQ) Parser and Metadata Database and multiple service providers interact with the middleware.

Location dependent service application server

Location dependent service application server provides LDS application for the mobile users. It supports applications to be executed through interface designed for the mobile users. Mobile users connect to the server and download user interfaces to construct their query. Normally these interfaces are in HTML/WML formats. Mobile users submit their query to the application server, which builds the location dependent query with the LDQ language. The LDQ will be forwarded to LDSM for retrieving appropriate location dependent data. The LDD retrieved will be formatted and returned back to the mobile users via the application server.

Location Dependent Service Manager

Location dependent Service Manager manages the execution of LDQ and controls the flow of query processing. The actual query processing functionalities are delegated to other components, such as LDQParser, LocationServiceControl, MetaDBControl, and ServiceProviderControl,. When an LDQ arrives, LDSM identifies the LDQ parser for the required information. LDSM then checks if it requires a location service for resolving the current location of the mobile user. There can be several appropriate service providers, each with its own location hierarchy. The LDSM performs location leveling according to the corresponding location hierarchies of the service providers. LDSM finally obtains LDD from the service providers.

Location Dependent Query Parser

The Location Dependent Query Parser currently supports the following types of LDQs: searching information for the nearest parking area as a static object such as “ Where is the nearby vehicle parking area?” and finding the slot inside the parking area as a dynamic object such as “ What is the slot number to park the vehicle?”. To support these queries, an LDQ language is designed for construction of the query. Each LDQ constructed with the LDQ language is SQL like statement.

Metadata Database

The metadata database stores information like the kind of data service providers provide, location hierarchy (i.e. parking slots) and distance information of locations, etc. To solve the granularity mismatch problem, location-leveling algorithm is used to level location to the desired level of service providers.

Location Service Providers

Location service providers are data sources that provide location dependent data. A service provider can be considered the content provider. In this prototype, service providers are the car park providers; they provide the parking slot data as a dynamic data and the parking location as a static data object. Location and tracking movements of the vehicles inside the parking are tracked with the help of Bluetooth device.

4. Implementation

This location based car park system has three main features (i) Search Vehicle Park Information (ii) Parking Slot Information Retrieval (iii) Parking Slot Reservation. This location based car park system got implemented using Microsoft visual studio .net with tomcat web server.

Search Vehicle Park Information

The user has to logon to the LDS system thro their mobile device and search for the nearby vehicle park by two ways (i) Choose the location where the users wants to park their vehicle (ii) Search the nearby parking area with respect to their current location.

Parking Slot Information Retrieval

The user has to choose one from the given parking list. The LDSM will provide the roadmap to reach the parking area and the number of available slots, space, cost and other information related to the service provider according to the users current location.

Parking Slot Reservation

On selection of the parking space, the system would get the vehicle details and inform the LDSM. The LDSM will take all the vehicular information and store it in the service provider’s database. On confirming the reservation of the slot, the LDSM would generate and send an “Authentication code” to the mobile user as well as to the Bluetooth enabled car park system.

On reaching the parking slot Bluetooth-enabled device in the parking slot can interact with the Bluetooth-enabled mobile and exchange the authentication details. If the authentication fails the parking system will give an alarm.

If the user could not reach and park the vehicle with in expiry time limit the parking system will issue a warning message thro user mobile device and the reservation would get cancelled automatically after the timeout period

Conclusion

This paper describes the architecture to support location dependent car parking service with a modular design. Bluetooth enabled vehicles and the Bluetooth enabled car parking slots are used to resolve the problem of location dependent car parking. The middleware forms the core of the system, providing the facilities needed to carry out the vital functions. In future the functionality of the middleware can be reengineered for better integration need. Application programmers can develop new application by using the same architecture.

References

[1] Z. Maamar, B. Benatallah, Q. Sheng, “Towards a Composition Framework for E-/M-Services”, 1st International Workshop on Software Agents for Pervasive and Ubiquitous Environment at AAMAS, Bologna (I), July 2002.

[2] Z. Maamar, E. Dorion, C. Daigle, “Toward Virtual Marketplaces for E-Commerce”, Communications of the ACM, 44(12): 35:38, Dec. 2001.

[3] G.C. Roman, C. Julien, Q. Huang, “Network Abstractions for Context-Aware Mobile Computing”, 24th International Conference on Software Engineering, ACM Press, Orlando (FL), pp. 363 – 373, May 2002.

[4] M. Roman, B. Ziebart, R. H. Campbell, “Dynamic Application Composition: Customizing the Behavior of an Active Space”, 1st IEEE Conference on Pervasive Computing and Communications, IEEE CS Press, Dallas (TX), pp. 169-176, March 2003.

[5] A. Miller and C. Bisdikian. Bluetooth Revealed: the Insider’s Guide to an Open Specification for Global Wireless Communications. Prentice Hall, Upper Saddle River, 2000.

[6] Hirotsugu Okura, Masami Kato, and Shuji Tasaka, “A Media Synchronization Experiment on Continuous Media Transmission in Bluetooth LAN Access”, 12th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, 2001.

[7] G. H. Forman and J. Zahorjan. The challenges of mobile computing. Computer, pages 38-47, April 1994.

Technical College - Bourgas,