UTILIZATION OF PREDICTIVE BLUETOOTH NETWORK FOR IMPLEMENTATION OF LOCATION-AWARE GUIDANCE SYSTEM Raine Koponen, Pekka Jäppinen and Jari Porras Lappeenranta University of Technology P.O.Box 20, 53851 Lappeenranta, Finland {raine.koponen, pekka.jappinen,
[email protected]}
ABSTRACT Short range radio systems make it possible to implement relatively low cost location-aware network and service solutions. Guidance system is an application which gains added value from that kind of a network. As mobile terminals with Bluetooth properties emerge an intelligently working guidance system becomes available. Our approach on a wireless guidance system is based on Bluetooth technology and Bluetooth enabled mobile terminals. When using wireless connection there is always some delay caused by the change of the used access point. With Bluetooth technology this delay gets too big for almost every real time application because the searching of surrounding devices (inquiry) is very time consuming operation. Therefore, our approach relies on predelivered Bluetooth device addresses of client devices, in which case the time consuming inquiry is avoided. This paper introduces one solution by using access points that are connected to Ethernet network. Implemented system delivers guidance messages accurately and fast after the user has entered the access point range. KEYWORDS Guidance application, Bluetooth, cell based approach, predelivered addresses
1. INTRODUCTION Improvements in the technology and changes in the rhythm of life drive ahead the needs and possibilities to develop personal location-aware services. Bringing location-awareness as one property of the service makes it possible to increase the obtained value for the user. Guidance is a good example of services where the knowledge about user's location is necessary and the use of it increases the accuracy of the given information and expands possibilities to include secondary services in the same system [1]. Short range wireless communication technologies make it possible to offer services like guidance systems with reasonable cost. The value of these services is noticed but the implementations are still scarce. There are only few suitable systems for indoor guidance in the markets and most of the available solutions support only WLAN technology that is not very widely used in mobile terminals, e.g. mobile phones. The location-aware applications have been discussed and researched for a long time already. The different techniques have been introduced for the implementations of location-aware systems on many different fields. On the indoor guidance systems the short range radio systems have shown their pros (and cons) which can be seen on the situation in the markets. The systems using Bluetooth or WLAN connections are the most common for the low cost implementations on that area. Ekahau Inc. is one of the companies that has
already a product for offering location information. They have introduced the product named Ekahau Positioning Engine (EPE) [2]. EPE uses the WLAN technology to provide and gather location information from the network. This system is capable to offer really accurate information about the user location, but for locating process it requires the WLAN interface for each located mobile terminal. Mobile phones, which are still the most common mobile terminals, have usually only a Bluetooth interface integrated so the WLAN network isn't usable for them. Therefore EPE is not usable with them. Another interesting project to take advantage of the location information produced by the short range radio technology is PLIM [3] project of Telematica Instituut in the Netherlands. They have produced an implementation of a location-aware instant messaging system by using Bluetooth technology. Implementation uses same basic idea than our guidance system. The problem in PLIM is the long delay when changing access point due the way used to decide closest access point to use. This paper reveals some of the problems of using Bluetooth technology in real time systems and introduces one possible solution with its implementation to bypass these problems. Troubles are caused by the time that connection establishment between two devices takes. Its duration is hard to predict because the time taken to find surrounding Bluetooth devices by using Bluetooth inquiry can vary a lot [4]. During the inquiry process the unique Bluetooth device addresses of surrounding devices are found out. The connection to the desired destination is formed by using one of those found addresses. In the Bluetooth systems the connection process itself is fast and usually causes no problem. The idea of the implemented Bluetooth guidance system is to skip the whole inquiry process or at least minimize its effect when forming connection between devices. The system is designed so that the first thing to do when starting a new guidance process is to send a registration message. When the registration message is sent to the access point the Bluetooth device address of the sending device is delivered within headers of the transferred data. By using the collected information it is possible to inform other access points of the system so that they can form a new connection to the incoming device without making an inquiry first. The easiest way to share information between access points is to use the fixed network because in most cases these access points are used to share fixed network access to wireless devices so that connection is already available.
2. BLUETOOTH BASED GUIDANCE SYSTEM Basis of the implemented Bluetooth guidance system was to implement a widely supported network for mobile terminals. First demo version is designed to fit only for Linux environment but for wider usability further development should be done for the porting system to other operating systems. The idea is that guidance application is usable for almost any mobile device that users might carry around. The backbone of the guidance network is guides (access points) and the main guide (application server) that passively waits if clients (mobile terminals) take contact and ask them to do something. The idea of our guidance system is that no action is executed if the
client doesn't ask for it first. The client application contains three different commands to send to the guidance network. The first one is for asking the list of currently active guidance destinations. This command returns information about all currently registered rooms and mobile devices of the guidance system. The second one is for registration to the guidance system which simultaneously starts a new guidance process. Starting of guidance process is done by approximating new route for the user and sending the first guidance message which informs the client to start moving to the right direction. The third and final command is for exiting from the guidance system. After this command the ongoing guidance process is run down and all the prepared access point dependent messages are removed from the system. [5]
2.1 Problems of Bluetooth when implementing real time systems Like already mentioned in the introduction the biggest problem with Bluetooth systems in real time applications like a guidance system is the connection establishment time. In the Bluetooth systems connecting time consists of the time for inquiry and the connection establishment itself. The first part (inquiry) is problematic for the implementations because there is no way to predict how long it takes to gather information about the surrounding devices when they are found out by going randomly through all possible frequency hopping schemes. Inquiry time depends on how many inquiry train switches must be completed before the inquirer gets enough answers from the network. Typically in an error-free environment it takes three train switches before that. One inquiry train must be repeated 256 times (that takes 2.56 seconds) before the next train is processed. According this it typically takes about 10.24 seconds to inquire surrounding devices but the maximum inquiry time is the time that is specified before the inquiry process halts. That's because there is no way for inquirer to know when all the surrounding devices have answered to its query. Specification defines this halting time up to one minute but usually a half of that (30.72 seconds) should be enough [4]. Experiments on a real environment with Bluetooth devices have shown that inquiry is very unpredictable.
2.2 Predictive network as a solution If it is possible to use multiple Bluetooth access points as a controlled guidance network the solution for connecting time problem is to exchange information between the guides. The key issue is to form the connections another way around than in traditional systems. If the client searches for active guides itself and after that directs queries about the guidance information on found guides the timing problem occurs. Connecting time increases because usually there is no way for the client to know all guides of the guidance system and that's why all of them have to be searched separately by using the time consuming inquiry. In the documentation of the PLIM project there is an estimate that the appeared delay on that kind of system is between 20 and 40 seconds [6]. The difference compared to the system which only forms the connection without making any inquiries is huge. The documented time for the plain connection forming is between 0.0025 and 2.56 seconds [4]. In our guidance system this inquiry phase is minimized. After registration of a client the main server has all the necessary knowledge to connect to the client devices without making any inquiry. When the system is centrally controlled it is possible to deliver
information about the clients to the guides which establish the final connections. Received information is then used to form connections directly to clients when they arrive at range of a guide and need the next guidance message.
3. ARCHITECTURE OF GUIDANCE NETWORK The wireless guidance system isn't new invention. Our approach is based on Bluetooth technology due to its properties. Our implementation of the guidance system tries to differ from others in its way to use the existing access point network to improve usability of whole system. The implemented guidance system contains three different parts that are dependent on each other and form the guidance network. There is one server module that is called main guide, a needed amount of access points which are called guides and clients or mobile devices that offer the user interface for the guidance system. The main guide provides functionality of the system by handling all possible issues concerning guidance processes. Because of differences in communication networks used by the main guide and clients there must be some kind of gateway to fit these network structures together. The gateway is formed by the guides that provide wireless Bluetooth guidance network for clients and fixed Ethernet connection for the main guide.
Figure 1: Elements of the guidance network
The guidance network is formed by mounting guides to the fixed locations on the area where guidance should be usable. Placing of the guides should be done in a way that the ranges of access points won't overlap much. Overlapping ranges cause problems for the implemented system because the conclusions about the user locations are made by checking out in which access point's range the user currently is. Being simultaneously active with area of two access point causes problems for this conclusion process. When user moves ahead and enters the new access point area the guidance message is automatically delivered. After delivery of a new guidance message the user is considered to be moved away from the previous access points range. If the same user still is found out from the previous access point range the guidance system thinks that the user has changed the direction and gone back to the previous access point's area. This causes a loop in which the system can't decide where the client device is located and wrong guidance messages are
delivered for the user. Jäppinen introduces in his master's thesis work this kind of method for making conclusions about the user movements and location on the area of the guidance network. This kind of network usage is called 'on-arrival' method because all actions are trigged when the user arrives in range of a new guide.
3.1 Network connections In the implemented guidance system all network connections for data transfer are implemented through the Linux socket interface. This implementation method was selected because the easy protocol and network interface definitions makes the socket connections quite adaptable way to create connections between the networked devices. The implemented guidance system is centrally controlled by the main guide so it is necessary that there is always free connection to the main guide for data delivery which defines partly the network implementation. Connections between the main guide and individual guides are handled through fixed Ethernet network by using TCP/IP protocol. New connections are formed by creating a socket for sending and receiving data. Created socket is always closed immediately after data transfer is done which means no fixed connections are used. For data transfers between the main guide and guides there are two different data structures depending on which way it is transferred (from or to the main guide). When the guide is sending information received from network users, the simple data structure containing only information about the connection and the command is delivered to the main guide. Answers of the main guide usually contain more data to deliver for clients so it has own data structure containing greater amount of suitable slots for data transfer. On the other hand the connections between guides of the network and user clients are handled through wireless Bluetooth network. Protocol used for data transfer is L2CAP [8] which can be easily taken for use with socket interface. The data moved between client device and guides are in plain text format which is easy to handle for even quite simple mobile device. The system is designed so that only necessary data is transferred over Bluetooth connection which guarantees the best possible response time for the guidance system. Access points allow only seven simultaneous connections so that's why all connection times are wanted to keep low.
3.2 Elements of the network Like mentioned previously the guidance network consist three elements which use different techniques to provide functionality to the guidance network. Users of the implemented system are equipped with PDA devices running the client software. Before any clients can be accepted to the network all guides have to be installed on their places in the building and appropriate guide software for relaying connections have to be running. And last but not least the server running the main guide software of the guidance system has to be running with correct settings to use database for offering any guidance functionality through the network.
3.2.1
The client software
The interface of the client software is designed as simple as possible because of the limitations in controls on most of the mobile terminals. The idea of the system is to access client application by pressing limited amount of push buttons that access some settings or actions. Count of possible settings is kept as low as possible to keep interface clear and simple to use. There are only two settings to make before guidance can be started but those two have to be defined in exact order. This is presented in Figure 2. First user has to select active access point which initiates the access to the guidance network and communication channel to the main guide. After that a selection about the desired destination is done to accomplish all settings before registration.
Figure 2. Guidance process in the application.
Selection of the guide is done by using a list of guides which is possible to update by pressing one button on the interface. Update process starts an inquiry that returns addresses of all active surrounding Bluetooth devices. Before showing any result, SDP query [8] is used to resolve those devices which are running appropriate software to give guidance. The user can select any of shown devices because the updated list shows only devices which can provide guidance information and are on range of the client device. The selection of desired destination is made in a quite same way that the access point selection. The list of active destinations has to be updated from the guidance system before making the first selection. The update message is sent after pressing appropriate push button on the interface and the answer from network is shown on screen of client device. Received list contains all registered destinations of system including dynamic mobile devices. After destination selection user can send registration for the guidance system which starts a new guidance process to guide device to its desired destination (Figure 3.).
Figure 3. Guidance of the user.
3.2.2
Application for guides
Guides have been left simple so administration is easy and costs are low even if some updates to the main guide is needed. For the updating process it is very unlikely that any changes to the guide software are needed. For the implemented guidance system there have been used guides that have both wireless Bluetooth and fixed Ethernet network interface. The guide itself doesn't make any changes for data that it relays through its network interfaces. The guide software uses both interfaces depending on current communications needs and the only thing it makes for relayed data is to convert it in the correct format and send it forward. Guides need to know the network location of the main guide in order to form a connection to it. This knowledge is defined in startup settings which are located on text file that is read right after the program starts. File contains simply IP-address (or host name) of the main guide and the used port for the communications. With this information network connections can be established and the guide program may be set to as a background job to release hardware for other simultaneous tasks. Execution of the program starts one process that is divided into child processes for serving incoming network connections. All child processes are removed from system after they have finished or the served network connection is closed. 3.2.3
Properties of the main guide
The main guide is used to provide all functionality and intelligence for the guidance system. The implemented system uses the main guide which is running on a normal network connected Linux workstation. Its functionality lays heavily on SQL-database functions which are needed for all actions performed. Actions to database tables are made via functions that can be used to query, insert, remove and update information on predefined tables. That's the reason to require SQL-database software installation on that
environment where the main guide is planned to be run. For database usage there should be added restricted user account for accessing only tables reserved for the guidance use. Restricted account is recommended because like guides the main guide has its settings included in one text file which contains also the used user name and password for accessing the database. The most important job for the main guide is to approximate routes for users and keep them on that route. Jäppinen introduces in his master's thesis few possible route approximation algorithms for the location-aware systems. The approximation algorithm of the implemented guidance system follows quite well the introduced specification of the 'pre-approximated route' algorithm [9]. The difference between the implementation and the original one is the way to represent the approximated route. The original model uses directions (like north, south, east and west) that users are going to follow on their route but in the implemented version these directions have been replaced by raw data about Bluetooth addresses of the access points of the route. So the route is represented as a list of access points that will be used to achieve the desired destination. For route approximation the main guide uses only one table that contains all connections from access point to another. The route for current user is approximated by making queries on that table starting from both sides of route making two separate routes simultaneously. When the last accepted access points on these two routes are the same the main guide combines these halfway routes for one final route [5]. The routes for users are saved to a SQL-table which is used to give further guidance. On circumstances when the route changes between guidance (user goes wrong way) the main guide upkeeps the correct route and informs user to return back and follow orders more specifically.
4. CONCLUSIONS Implementation of our guidance system has shown that making a working guidance network is a challenging job but after the successful installation the efficiency of the system raises dramatically. Accuracy of the gathered location information depends on the class of the used Bluetooth devices because the conclusion about the location of a device is made by using knowledge about the location of currently used access point. For wider usage it is possible to use different device classes for access points on different parts of building in order to provide always sufficient accuracy for the given guidance. It should also be noticed that usage of different Bluetooth classes for client devices cause differences for locating results. If the system is calibrated for class 2 devices then only devices for that class can be located and guided correctly. Implementing the guidance network is always a quite large investment so usually it is useful to combine some other services in the same system. The guidance system is almost fully intended as service for guests of the building so for better usage rates it might be useful to integrate some every day applications for the system. That kind of systems might be systems for controlling electronic locks, some kind of instant messaging or other channel to share information.
Demonstration system works only on Linux operating system base and this fact limits out all devices using other possible base systems. To achieve wider support for the implemented guidance system at least client software should be ported to other operating systems like Symbian.
REFERENCES [1] A. Rainio (ed.), "Personal navigation. Market, technology and applications" (in Finnish), VTT TiedotteitaMeddelanden - Research Notes : 2037, ISBN 951-38-5693-3, 2000. [2] Ekahau Inc., Ekahau Positioning Engine 2.1, 2004. [3] A. Peddemors, M. Lankhorst, and J. de Heer, "Combining presence, location and instant messaging in a contextaware mobile application framework", tech. rep., Telematica Instituut, March 2002. [4] D. Kammer, G. McNutt, and B. Sense, "Bluetooth Application Developer's Guide: The Short Range Interconnect Solution", Syngress Publishing, Inc., 2002. [5] R. Koponen, “Utilization of predictive bluetooth network for implementation of location-aware guidance system" (in Finnish), Master's thesis, Lappeenranta University of Technology, March 2004. [6] A. Peddemors, M. Lankhorst, and J. de Heer, “Precence, location and instant messaging in a context-aware application framework” in The 4th International Conference on Mobile Data Management, 2003. [7] P. Jäppinen and J. Porras, “Architectural Considerations on a Bluetooth based Guidance System” in IASTED international Conference on Wireless and Optical Communications, IASTED, July 2002. [8] B. A. Miller and C. Bisdikian, Bluetooth revealed. Prentice-Hall PTR, 2001. [9] P. Jäppinen, “Bluetooth wireless technology based guidance system”, Master's thesis, Lappeenranta University of Technology, October 2001.
