Stelios Sidiroglou-Douskos
In this report, we will introduce an implementation of wireless device location services using bluetooth wireless technology. We built a system where mobile nodes, such as a PDA or a bluetooth wireless enabled laptop, can quickly discover their location to room-accuracy. This implementation is built on top of the bluez library (the office bluetooth protocol stack for linux). We have provided 2 implementations of this service: bluetooth l2cap sockets, object exchange protocol (obex) (Originally we were thinking about doing the 3rd approach- SDP server attribute string retrival, however, Stelios said it's not necessary. The location of a PDA device is thus discovered through retrieving a location XML file from the bluetooth location services server that is within the bluetooth connection proximity.
In the last few years, with the continue increasing emphasize on various wireless technology, numerous applications have emerged. Among them, one of the most interesting wireless applications is location services. This service allows mobile devices that have wireless connection capability to be able to discover their own location information.
With the increasing popularity of the bluetooth wireless technology, we therefore built a prototype server-client system which allows bluetooth enabled clients such as PDA and notebook to retrieve its location information from a bluetooth location services server that contains a location attribute XML file. In our implementation, the location information that we can obtain is not merely numerical information such as coordinates of the exact position. Instead, the information retrieved will be very meaningful to humans as they truely represent the location of the devices. For example, one of the location attributes can be the type of locations the device is currently at (e.g. coffee shop, office, meeting room...). As the mobile nodes traverse from one location to the other, as long as it has a client application running in the background, it'll keep looking for the server program that contains the location information, and if it receives the information, it can display to the user of the device or can be sent to other servers for other services.
For the rest of the report, we will first discuss briefly other related and similar work done in this area, and also the background of the tools and libraries that we use in our implementation. Then, we will provide a description of each approach that we used. We will give provide details on the location information that we provide. Lastly, we will display some sample runs of the program using different approaches.
Efforts have been devoted to the telecommunications community on location services related applations. An example will be OpenLS [1] - an open standard strives to build a foundation for the location services. It is devoted to the development of interface specifications that facilitate the use of location and other forms of spatial information in the wireless Internet environment. The purpose of OpenLS is to produce open specifications for interoperable location application services that will integrate spatial data and processing resources into telecommunications and Internet services infrastructure. Cell phone services providers also provide similar location services, Orange UK introduced location services on their cell phone users which the mobile phones have be ability of a navigation device which will be capable of directing users to nearest ATM, hospital, etc...[2]
However, no effort yet have been devoted to utilize the bluetooth technology to implment location services system, not to mention an implementation on Linux. Therefore, our application prototype provides another possiblity of the location services application system and it can be used in the near future to integrate with ubiquitous computing system as part of its services.
In this section, we are going to give a brief description of the tools and library that we use. As mentioned before this program is linux based, therefore we are using its official protocol stack, namely the bluez library for all the bluetooth device connections and service discovery protocol related parts. Using bluez, one implmentation of our application is built using l2cap sockets transfer which we will further described in the program documentation section.
We also provide another implementation using the object exchange protocol (OBEX), we use openobex library and also the openobex applications library to implment our server and client, the connection and transfer are done through the OBEX layer using the library provided by openobex with slight modifications.
The location xml file's schema is based on Location Inter-operability Forum (LIF) Mobile Location Protocol. In this implementation, we only use the location element definitions as part of our implementation. Location XML files have to follow this format. The dtd schema file for the location information can be found here.
Testing is done entirely on Stelios' laptop which is equipped with 2
bluetooth PCMCIA cards. One of the cards will have sdp server setup
and it'll also have the OPUSH service registered. We will run the
client on the other device. Since we are going the testing on 1 host
machine with 2 devices, you can supply the device id with each you
want your server and client program to reside on. (see program
documentation)
The testing process first start by starting
up the SDP server and then the server program and we'll start the
client program to try to initalize a contact to the server periodically to get
the location xml file.
The description of the program architecture will be included in the program documentation section.
The server program that listens on a bluetooth device and accept a connection to the client. Once the connection is established, the server will send the location xml file to the client. It will then close the connection and listens for connection again. Right now, the server serves one connection at a time. In the near future, we should develop the server into a multithreaded application so that it can service multiple client devices at the same time. There is always a possiblity that multiple users with bluetooth capability will come in to the room at the same time and they should all get a location fix simultaneously. The implementations function the same way except one is through l2cap sockets and another approach is through the object exchange protocol. However, they both have similar performance as we will discuss briefly in the measurements section.
The client program that runs on bluetooth enabled mobile nodes such as PDA, cell phones and laptops. It loops infinitely to look for the presence of SDP server in its proximity. Once an SDP server is found, it'll then try to connect to the address of the device that hosts the SDP server which of course also holds our location services server program. It will try to establish a connection with our server program and get the location xml file to the host machine and then parse the file to extract the location information. The user will be able to specify the path of the directory of which they want to save the file to. In the near future, the client can be developed into multi-threaded as well so that it can service one thread to keep trying to get the location file while invokes other threads to carry out other activities.
System RequirementsBoth the server and client have to run on a linux machine that contains a bluetooth device. It will also have to have bluez, openobex and openobex-apps library installed in order to carry out their functionality. Lastly, libxml will be needed as well for parsing the location xml file. Of course, the server will most likely be running on a static Linux box while the client will be running on mobile devices.
Installation Instructions
A Makefile is provided with the package. To install, please type:
make
The two executables: bt_loc_server and bt_loc_client will then be
generated.
Usage for the server program:
bt_loc_server [location xml file] [1 for obex, 2 for l2cap sockets] [hci# # is the number of the device (optional)]
Usage for the client program:
bt_loc_client [sleep time for client in seconds] [1 for obex, 2 for sockets] [save directory path] [hci# # is the number of the device (optional)]
Build Procedure
OBEX Implementation Sample Run
L2CAP Socket Implementation Sample Run
The entire application is basically divded into 4 parts:
In addition to making both the server and client multithreaded as suggested in the above, a GUI can also be built on the client side to parse the location information nicely and display them to the user in a systematic way. Moreover, a future direction of this project can be integrating this location services with other services. For example, once i know that i am currently at a meeting at meeting room 20. Then, since the server will know my location, it will then direct all my calls to the phone in this meeting room. Moreover, it can immediately display the possible services that this particular access point has and based on some kind of user information (which can also be retrieved from my PDA), I can access to the services that i am allowed to.
Acknowledgements
After a few runs, the time for the client to get the location
information is between 5-10 seconds and this result is consistent with
either the obex and the l2cap sockets approach. Majority of the time
is devoted to looking for the existence of the SDP server, once the
address of SDP server enabled device is found, the connection
establishment procedure and the file transfer is very fast.
However, performance may be harmed if the location xml file's size is
bigger. Morever, since we only did the testing on a single machine (w/ 2
bluetooth devices), performance may not be as well if in a PDA-access
point situation where the distance between the PDA's bluetooth device
and the server access point is farther.
I have developed the entire application myself with Stelios guidance.