A Scalable Location-Based Services Infrastructure Combining GPS and Bluetooth Based Positioning for Providing Services in Ubiquitous Environment

Transcription

1 A Scalable Location-Based Services Infrastructure Combining GPS and Bluetooth Based Positioning for Providing Services in Ubiquitous Environment Pampa Sadhukhan Niladrish Chatterjee School of Mobile Computing School of Computing & Communication University of Utah Jadavpur University, India Arijit Das Pricewaterhouse Coopers Pvt. Ltd. Pradip K. Das Faculty of Engineering & Technology Mody Institute of Technology & Science, India Abstract Several methodologies on the provisioning of the Location-Based Services (LBSs) solely using GPS-based positioning or combining several positioning techniques like GPS, GSM Cell-ID, Wi-Fi, Bluetooth and RFID etc. have been proposed over the past few years. Most of these systems do not focus on limited battery power, memory-constraint of the mobile devices, the heterogeneity of mobile platform and proper authentication checks before providing LBSs to the mobile user. Our proposed system utilizes low-cost, low-power Bluetooth wireless technology as indoor positioning technique and combines it with GPSbased positioning to accurately sense the location in outdoor environment. The inclusion of HTML-to-WML parser into the Middleware deployed on each Base Station (BS) enables the devices with micro browser to invoke the LBSs properly. The mobile client application developed in Java is portable and interoperable with a diverse set of mobile platforms. The client application can also run on devices not having support of location API. Scatternet support with our proposed LBS Infrastructure makes it scalable with increasing number of client devices. This paper also evaluates the performance of the Middleware in terms of connection setup time and service consumption time with respect to varying number of mobile clients. Index Terms Location-Based Services(LBSs), Bluetooth, GPS, Base Station(BS), Middleware. I. INTRODUCTION Location-Based Services (LBSs) comprise the automatic tailoring of information and services based on current location of the user. The availability of various wireless interfaces such as Bluetooth [1], RFID [2], Wi-Fi [3] etc. and external positioning technology like GPS [4] in most of the mobile devices motivates the researchers and telecom operators to work in the field of providing LBSs to mobile users. The provisioning of LBSs like Where is the nearest ATM/medical centre from here? or How to reach a destination from the current location? to the subscriber requires the fine-grained location estimation of the subscriber. A major challenge to the telecom operators to provide the aforementioned services is the fine-grained location discovery of the device primarily because of lack of accuracy in Cell-ID-based positioning. The accuracy of GPS-based location sensing makes it an obvious choice over network-based location sensing in outdoor environment but the weak strength of GPS signal in indoor setting necessitates server-based mobile-assisted location discovery through Bluetooth, Wi-Fi or RFID technology. However, a novel Middleware solution is required to properly integrate and switch between different localization solutions such as switching from GPS-based localization to position estimation through Bluetooth/Wi-Fi-enabled Base Station (BS). Moreover, after obtaining the location information of a mobile user, most of the LBS-platforms [5]-[6] lack proper service-advertising facility and are unable to manage user mobility. Our earlier work [7] presented the design of an LBS-Middleware deployed onto each BS and the client application running on mobile devices to solve the aforementioned problems, which we have adapted in our present work. Our LBS Infrastructure employs Bluetooth technology for sensing location indoors. The authors in [8] have compared the capabilities of personal area network (PAN) hosted by a Bluetooth-based system with that hosted by an IEEE bbased system. The wireless technology WLAN and Wi-Fi is primarily compliant with IEEE b. The experimental results provided in [8] show that each Bluetooth-based PAN maintains the same bandwidth and also a constant level of energy efficiency while the bandwidth and energy efficiency decreases sharply for the IEEE based PAN with increasing number of PANs. Since Bluetooth operates in a license free domain, users do not have to incur any extra cost for the bandwidth. The ubiquitous nature of easily available Bluetooth technology on the mobile devices and its low power consumption makes it the technology of choice in the present scenario. In addition, the Bluetooth range being of the order of 10-20m automatically ensures that the accuracy of the location estimation by means of Bluetooth inquiry procedure [9] in indoor environment would be of the same order. On the other hand, to provide fine-grained location estimation of the device in wireless LAN environment, it is needed to use some sophisticated positioning algorithm like radio map technique or some model-based technique where the relation between the signal strength received from an access point (AP) and the distance to this AP is captured as presented in [20]. The

2 location estimation of the device in outdoor can be done by collecting the GPS-based location data from the device over GPRS/Internet connectivity. In our proposed system, the mobile device invokes the web client to interact with the BS as web client reduces the memory consumption compared to standalone client and it is more platform-independent. However there is heterogeneity in mobile platform with respect to the web browser, e.g. a laptop with Internet Explorer (IE) has capability to properly display the HTML pages whereas a smart phone or PDA with micro browser do not have that ability of displaying traditional HTML page. The above problem has been addressed in our present work by incorporating a HTML-to-WML parser in the LBS-Middleware. In the latter sections, we use the term Middleware in place of LBS-Middleware. The difficulties of programming handheld devices like PDAs and smart phones due to the high degree of heterogeneity in platforms and peripherals of those handheld devices have been overcome to a considerable degree with the introduction and widespread adoption of Java 2 Micro Edition (J2ME). J2ME provides the Location API JSR-179 [19] that has well defined methods to retrieve location information from the location sensing hardware interfaced with the device. However the full JSR-179 facility is available on only a certain class of devices [10]. Thus, we focus on the design of mobile client application to overcome the limited availability of Location API for an ever-expanding list of platforms by using the hardware GPS receiver from a lower layer of abstraction than what is done by the JSR-179. Similar endeavors have been made [20, 21] earlier. To overcome the limited support for the API JSR-179 in other platforms, the researchers in [20] have adapted C++ based coding on Linux platform, which they have ported to Windows CE as well. However, they have not elucidated on the interoperability issues of their client application, which are bound to gain significance with the growing diversity in mobile platforms today. Nevertheless, the value addition of our application lies in the fact that it is built on a Java platform that inherently includes the advantages of portability, robustness and interoperability. To prevent the malicious users from consumption of services and resources with mala fide intention we have introduced a registration process to be followed by each mobile user intending to invoke the services and an authentication check in our system before advertising LBSs to the user. The limitation of Bluetooth-based PAN is that it can accommodate at most seven client devices to communicate with the BS at a time. Thus we have proposed a scatternet formation algorithm to make our LBS Infrastructure scalable with increasing number of clients. The paper is organized as follows. Section 2 discusses the related work. In section 3, we present the design and implementation details of our proposed system. Section 4 evaluates the performance of the Middleware. Section 5 draws the conclusion and presents our future goal. II. RELATED WORK Some researchers [11] have proposed an integrated LBS infrastructure combining 3G network with WLAN environment that provides Location Aware Services to be consumed by only those mobile devices that have the XML-based Simple Object Access Protocol (SOAP) [12] message processing capabilities. A similar drawback is found in the work done in [13]. The authors in [14] have proposed a hybrid location estimation scheme by combining the location estimate provided by GPS and also the location information available from 3G network. Their proposed scheme utilizes the navigation signals of BSs available in 3G network whenever at least four satellites are not visible by the GPS receiver of the mobile station (MS) since four Time-of-Arrival (TOA) or Time-Differenceof-Arrival (TDOA) measurements are required to obtain 3D location estimate of the MS. This proposed scheme would not be effective in indoor environment because of poor signal strength of both GPS and 3G networks. The authors in [15] have described a web-based mobility tracking and analysis system that collects cellular network-based location data such as BS ID or GPS-based location data from the mobile device via Internet connection and processes those low level location data to obtain mobility paths with temporal information. However, cellular network-based location data creates inaccurate mobility paths as the BS ID always gives coarse location estimation. The authors in [16] have described a GPS-based tracking system that collects the geographic co-ordinates from the GPS receiver carried by the user and transforms it to comprehensive location by using GIS software. Their proposed tracking system shows that the behavior and activity of a person can be deduced from the track data. Nevertheless, some security concerns are associated with GPS-based tracking such as revealing location information and the possibility of editing tracked data that may pose risks to innocent person. Authors in [17] have presented and evaluated an energy-efficient combination of GPS and GSM Cell-ID based positioning for providing proactive LBSs to the mobile terminals. They have mainly focused on how to reduce power consumption in case of continuous tracking by GPS-based location sensing and also introduced several strategies for extending lifetime of the battery. However, their proposed solution cannot be utilized to provide proactive LBSs in indoor environment. In [18], the authors have presented a seamless indoor/outdoor positioning technique by combining GPS-based positioning in outdoor setting and Wi-Fi-based positioning in indoor environment. In their proposed work, positioning in indoor setting is accomplished by downloading the radio map of signal strength for different locations in a building onto the device and then by searching the radio map for a closest match to the signal strength currently measured by that device. However, from the perspective of power consumption, Bluetooth-based positioning is a better choice over Wi-Fi-based fingerprinting technique.

3 Fig. 1. Architecture of the system III. DESIGN AND IMPLEMENTATION OF PROPOSED SYSTEM Fig. 2. Functional architecture of Middleware. Our proposed system shown in fig. 1 consists of several BSs of which one is attached to a GSM box via a serial port to collect the registration request message from the mobile users. That BS is called the Central BS. The Central BS is connected to other BSs through a LAN so that Central BS can periodically broadcast the list of registered mobile users to the other BSs. Each BS except the Central BS in our system is Bluetooth enabled. A Java and JSP based Middleware is deployed on each BS. A mobile user willing to invoke the LBSs, must have to register with the Middleware deployed onto the Central BS by sending an SMS (Short Messaging Service) to a well-known phone number assigned to the GSM box of the Central BS. The mobile user would receive a unique user name and password from the Central BS via an SMS. The registration procedure to be followed by the mobile users has been described in [22]. A. Detailed Design of Middleware The Middleware consists of several modules such as Main Module (MM), Authentication Module (AM), Service Advertising and Invocation Module (SAIM) as shown in fig. 2. The Middleware is developed using Java and some web technologies like JSP, HTML and WML etc. We have adapted the Web Based Middleware described in our previous work [7] for the present purposes. After completion of registration, the following sequences of events occur if the mobile user attempts to invoke some services while s/he is roaming around public places. 1) When the mobile user lies indoor s/he would initiate the Bluetooth discovery procedure to detect some Bluetoothenabled BS and then proceed to join to the PAN hosted by that BS. In case the device is outdoor or it cannot find out any Bluetooth-enabled BS, it would communicate with the central BS over the Internet. 2) Then it can use the web browser to invoke the Main Module of the Middleware. MM receives and handles the client request sent over the Bluetooth or Internet connection. At first, the user needs to send the user name and password provided to him/her upon completion of registration to the MM. 3) MM invokes AM by providing it the user name and password received from the client. If the user name and password provided by the mobile client match with those of a registered user, it would invoke SAIM to allow the mobile client to receive the service advertisement and to consume the LBSs. The detailed design of MM and SAIM has been given in our earlier work [7] and the functional description of AM can be found in [22]. B. Enhancements made to the Middleware Details of the new module, HTML-to-WML parser incorporated into the Middleware of our previous work and the services deployed onto the BS are presented in this subsection. Each BS advertises two LBSs, namely location service and content-mapping service via SAIM to the mobile client. The BS also provides the location related information that would be useful to the user based on the profile given by the user during registration. The location service gives the location of the mobile user and the second one provides a map showing the direction from the current location to the destination that the user wants to reach upon receiving the name of the destination from the user. The location service deployed on Bluetoothenabled BS provides its own location to the user when the user invokes that service. On the other hand, location service deployed on the Central BS determines the location of the user from the GPS-based positional co-ordinate values sent by the mobile client by using the GIS software. 1) HTML-to-WML Parser: Most micro browsers of mobile devices do not have the ability of displaying traditional HTML pages. Therefore, to consume the deployed services over the native web browser, the service pages have to be present in the form of WML. The process of converting HTML documents into WML documents for use on WAP-enabled devices is not as simple as alteration of the markup tags. Thus, we focused on building a system that can translate a HTML page to a WML page on the fly effectively allowing the users to access the web

4 Fig. 3. Topology of the Scatternet pages from the device s micro browser. The compact nature of WML s tag set means there are limitations when attempting to display HTML elements such as headings, frames, JavaScript, images and the like. The nesting of tags complicates translation between the two languages. The problem breaks down into a set of steps: 1. Provide a WML page where a user can enter a URL into a form field. 2. Receive the web page form request. 3. Convert it to well-formed HTML. 4. Transform the well-formed HTML into WML. 5. Display the new WML page to the WAP device. Steps 1 and 2 are quite simple. However, step 3 presents a problem. Turning arbitrary HTML into well-formed XML is not a trivial task. There are tools available for this purpose [23]. Step 4 is straightforward in principle. The HTML tags that are similar or almost similar to WML tags are kept unchanged or modified slightly. The HTML tags not supported by WML are simply ignored. Finally step 5 is simple once we have the WML file to be displayed. C. LBS Infrastructure Scatternet Support The limitation of Bluetooth-based PAN hosted by the BS is that at most seven client devices can join into it. Thus, each BS has to form a scatternet consisting of several piconets in order to allow more than seven devices to communicate with the BS via Bluetooth technology. The Bluetooth standard does not specify a specific scatternet formation algorithm. In our LBS Infrastructure, we have adopted a scatternet topology similar to one shown in fig. 3. In the scatternet topology, two connections within each piconet are reserved for bridge devices to make our LBS Infrastructure scalable with respect to increasing number of client devices. Two piconets within a scatternet can communicate by sharing one or more bridge devices that may either become a master in one and slave in the other or become slave in both piconets. To enable interpiconet communications, the bridge devices must use time multiplexing to switch between the piconets by alternatively entering into sniff mode or active connection mode. With sniff mode, the time slots when a slave is listening are reduced, so the master shall only transmit to a slave in specified time slots. In the scatternet topology adopted by our LBS Infrastructure, each BS act as the master in piconet 1 as shown in fig. 3 and keeps two connections reserved for bridge devices that act as slave in the piconet 1. These devices act as master in their own piconet and these are termed as Bridge-to-BS in our LBS Infrastructure. The scatternet formation algorithm is as follows. 1. Two Bridge-to-BS connected with the BS generally remain in parked state unless the connection requests from more than five devices have reached at the BS. The slave may enter the park state to reduce power consumption if it does not need to communicate with the master all the time. 2. When the BS receives connection request from a new device while already five clients are connected to it, the BS unparks the Bridge-to-BS to form a piconet with that new device. Here the Bridge-to-BS is a Bluetooth enabled PDA. Whenever a client cannot join to the piconet hosted by the BS, it tries to join the piconet hosted by Bridge-to-BS. 3. After successful unparking, the Bridge-to-BS enters into sniff mode with respect to piconet 1 and starts formation of its own piconet to accommodate the devices that are unable to join piconet 1. Now the devices that have joined in piconet 2 or piconet 3 can receive the service advertisements and invoke the services via the Bridge-to-BS device in the following way. a. The Bridge-to-BS receives the data from and sends the data to the slave devices in its own piconet when it enters into sniff mode with respect to piconet 1 and remains in active mode with respect to its own piconet. b. To deliver the data received from the slave devices to the BS, the Bridge-to-BS enters into the sniff mode with respect to its own piconet and join to piconet 1 in active connection mode. D. Design of Mobile Client When the mobile device resides in indoor environment and discovers a nearby Bluetooth-enabled BS, it would join the PAN hosted by that BS or the PAN hosted by the Bridgeto-BS in case the density of client devices around the BS is high. As each master device acts as a DHCP server [24] in its personal area network, it obtains the IP address If the device has a micro browser, it would use the URL to access the MM of Middleware deployed on the Bluetooth-enabled BS. In case the device has the IE, it would open up the corresponding html page, i.e., When the device cannot find out any Bluetooth-enabled BS or it exits indoor environment and comes to an open place, the device would communicate with the Central BS over GPRS or Internet connection. In that situation, the user has to run GPS Parser to continue the service invocation. GPS Parser extracts GPS coordinates of the device from its GPS port and sends them to the MM deployed on the Central BS. 1) The Architecture of the Client Application using Integrated GPS: Devices with Symbian Operating System (OS) do have the support of Location API JSR 179 that can be utilized by any J2ME based application to obtain location

5 Fig. 5. Connection setup time for Bluetooth and GPRS Connectivity vs. number of clients Fig. 4. Architecture of Mobile Client information from the integrated location sensing hardware. On the other hand, a vast majority of handheld devices come with the OS Windows CE (WinCE) [25] where the availability of JVMs or KVMs is restricted. Although the commercial NSIcom Creme [26] and IBM J9 [27] are available to make J2ME based programs runnable on devices with WinCE OS, the lack of support of API JSR 179 on those devices makes any location discovering program developed using that location API obsolete for them. Thus, we emphasized on building a Java based client application that uses the hardware GPS receiver from a lower layer of abstraction than what is utilized by the JSR-179. The environment in which GPS Parser runs and the mutual relationships between the platform and the application are depicted in fig. 4. In the portable device of our choice, the GPS receiver is connected to the backplane via a serial communications port. The client application uses the Java Communication (javax.comm.) API [28] for opening a connection with the serial port that hosts the GPS receiver and the application has a Java AWT [29] based user interface. The communication API is available with most JVMs including the GNU Mysaifu JVM [30] used by us. A Serial Port Event listener is registered on the port associated with the GPS receiver. The Serial Port Event is triggered whenever the receiver has some data to send. This it does continually regardless of whether it has obtained a GPS fix or not. Therefore, the Event handler has been designed to reject such void data. The GPS on our experimental device complies with the popular NMEA0183 [31] standard of GPS satellite communication. However, GPS receivers with other data formats can be supported just as efficiently by making some minor modifications to our prototype. IV. PERFORMANCE EVALUATION Some preliminary experiments have been carried out to evaluate the performance of our proposed LBS Infrastructure and the Middleware deployed onto the BS in terms of latency due to connection setup and service consumption time taken by the mobile client with respect to varying number of clients. Fig. 6. Time needed to consume the LBSs through two types of connection vs. number of clients. The service consumption time has been measured from the moment client sends the request for a particular service up to the moment it receives the result of that service at the client device. Fig. 5 and fig. 6 show the latency involved in connection setup phase and service consumption phase with respect to varying number of devices respectively. All the experiments have been done five times and the average results have been provided in fig. 5 and 6. Our experimentation shows that mobile devices generally takes 4 to 5 seconds to detect a nearby BS and then to join the PAN hosted by that BS using Bluetooth technology. If the density of the devices around the BS were high, it would take 5 to 6 seconds to join the PAN hosted by the Bridgeto-BS device. This happens because the BS rejects the initial connection request from that device and then it tries to join the piconet hosted by Bridge-to-BS. Thus, the connection setup time and the service consumption time for LBSs offered by the BS through Bluetooth connectivity remains almost same when the number of devices invoking the services is varied up to four and these times increase in case the number of client devices around the BS becomes more than five as shown by the test results in fig. 5 and 6. On the other hand, setting up GPRS connection takes about 4.7 to 6 seconds as shown by our experimental results in fig. 5. However, the setup of GPRS or Internet connectivity

6 depends on the Internet service provider and it grows with increasing number of devices. Thus, the connection setup time and the service consumption time for LBSs through GPRS connectivity grow with increasing number of devices as shown by the test results in fig. 5 and fig. 6. Fig. 6 shows that the service consumption time for LBSs offered by the BS over the Bluetooth connection becomes high compared to that over GPRS connection in case number of devices invoking the services reaches round ten or more than ten. This is so because some devices send their service request and obtain the result via the Bridge-to-BS which increases the average service consumption time in case ten or more client devices are trying to communicate with a particular BS. Thus to obtain improved result in service consumption time by using Bluetooth technology, it is required to have high density of Bluetooth-enabled BSs in order to enable each device to directly communicate with the BS. V. CONCLUSION AND FUTURE WORK The Location-Based Services Infrastructure proposed in this paper provides some definite advantages over prevailing methods of obtaining LBSs. The proposed architecture shows the integration of two location sensing techniques: server-based mobile-assisted (indoor) and mobile-based (outdoor). The design and implementation of our proposed LBS Infrastructure shows that it can overcome the limitation of Bluetooth-based PAN and it is scalable with increasing number of devices. The registration process and the authentication mechanism incorporated into the Middleware ensure that users invoke LBS in secured environment. On the other hand, the client, being a web client, takes less memory and can be run on heterogeneous mobile devices because it requires no API other than the Communication API that comes with Java Runtime Environment. The Java application for discovering location using integrated GPS receiver on a handheld device running Windows CE represents a considerable contribution to the evolving Java API set and opens up the possibilities of future research with the following objective. The methods employed on the mobile client application presented in this paper can be used as a basis for developing a Location API for WinCE platform analogous to JSR-179 for J2ME. Furthermore, a suitable mobility management framework is required to be incorporated into the Middleware to assist the client to consume the services in an uninterrupted fashion. ACKNOWLEDGMENT The authors gratefully acknowledge the facilities and support provided by the Director and all other staff members of the School of Mobile Computing and Communication, Jadavpur University, a Centre of Excellence set up under the University with potential for Excellence Scheme of the UGC. REFERENCES [1] Bluetooth: Bluetooth Core Specification Version 4.0 available at [2] RFID: [3] Wi-Fi: [4] GPS: [5] Y. Xia, H. Y. Bae, General Platform of Location Based Services in Ubiquitous Environments, Proc. of the International Conference on Multimedia and Ubiquitous Engineering, pp , [6] Li Fang, Li Xialei, Bian Fuling, A Framework for Autonomous LBS in Wireless Pervasive Computing Environments, Proc. of the 9th International Conference on Advanced Communication Technology, Vol. 3, pp , Feb [7] Sadhukhan P., Das P.K., Sen R., Chatterjee N., Das A. A middlewarebased approach to mobile web services, in Proc. of Asian Mobile Computing Conference (AMOC-2007): 5th international conference, Kolkata, India, January 3-6, pp [8] P. Johansson, R. Kapoor, M. Kazantzidis and M. Gerla, Personal Area Networks: Bluetooth or IEEE ? International Journal of Wireless Information Networks, Vol. 9, No. 2, pp , April [9] Bluetooth Inquiry Procedure, Bluetooth specification version 2.0, vol. 1, pp. 53. [10] [11] G.C. Park et al., An Automated WSDL Generation and Enhanced SOAP Message Processing System for Mobile Web Services, Proc. of the Third International Conference on Information Technology: New Generations, [12] SOAP: [13] L. Aalto et al., Bluetooth and WAP Push Based Location-Aware Mobile Advertising System, Proc. of Second International Conference on Mobile Systems, Applications and Services, Boston, MA, pp [14] L. He, Z. Deng, J. Huang, Location Based Services combined with GPS and 3G Wireless Networks, Proc. of IEEE International Conference on Service Operations and Logistics, and Informatics, 2008, Vol. 1, pp , Oct [15] M. A Bayir, M. Demirbas, A. Cosar, Track me! a web based location tracking and analysis system for smart phone users, Proc. of 24th International Symposium on Computer and Information Sciences, pp , Sept [16] K. Michael, A. Mcnamee, M. G Michael, H. Tootell, Location-Based Intelligence-Modeling Behavior in Humans using GPS, The Proc. of IEEE International Symposium on Technology and Society, New York, [17] N. Deblauwe, P. Ruppel, Combining GPS and GSM Cell-ID positioning for Proactive Location-based Services, Proc. of Fourth Annual International Conference on Mobile and Ubiquitous Systems: Networking & Services, pp. 1-7, Aug [18] R. Hansen, R. Wind, C. S. Jensen, B. Thomson, Seamless Indoor/Outdoor Positioning Handover for Location-Based Services in Streamspin, Proc. of the 10th IEEE International Conference on Mobile Data Management: Systems, Services and Middleware, pp , [19] Location API (JSR 179): [20] S. Banerjee et al., Rover: Scalable Location-Aware Computing, IEEE Computer, pp , October [21] T. Nadeem and et al., Implementation of a Scalable Context-Aware Computing System, Proc. of International Conference on Personal Wireless Communications, September 23-25, 2003, Venice, Italy. [22] P. Sadhukhan, R. Sen, P. K. Das, A Middleware Based Approach to Dynamically Deploy Location Based Services Onto Heterogeneous Mobile Devices Using Bluetooth in Indoor Environment, Second International Conference, ACN 2010, Japan, June 2010, CCIS 77, pp. 9-22, Springer. [23] tidy.exe: [24] DHCP: R. Droms, Dynamic Host Configuration Protocol, Request for Comments 2131, Internet Engineering Task Force, March [25] Win CE: windowsce/default.mspx. [26] NSIcom Creme: [27] IBM J9: [28] Java Communication API: [29] Java AWT: [30] Mysaifu JVM: dat/java/project/jvm/. [31] GPS NMEA format: