Wireless Personal Communications (2006) 38: 187–202 DOI: 10.1007/s11277-005-9001-x
C
Springer 2006
UbiqMuseum: A Bluetooth and Java Based Context-Aware System for Ubiquitous Computing JUAN-CARLOS CANO1 , PIETRO MANZONI1 and C.-K. TOH2 1
Polytechnic University of Valencia, Camino de Vera, s/n, 46071 Valencia, Spain E-mail: {jucano, pmanzoni}@disca.upv.es 2 University of Hong Kong E-mail:
[email protected]
Abstract. This paper evaluates the use of Bluetooth and Java based technologies in ubiquitous computing environments. Ubiquitous computing strongly depends on leveraging appropriate contextual information to users, according to their preferences and the environment in which they reside. We present UbiqMuseum – an experimental context-aware application that provides context-aware information to museum visitors. UbiqMuseum combines the productivity of Java with the universal connectivity provided by Bluetooth wireless technology. We describe the overall architecture and discuss the implementation steps taken to create our Bluetooth and Java based contextaware application. We demonstrate practicality of building a context-aware system by using UbiqMuseum as a proof of concept that integrates a combination of Bluetooth, WLAN and Ethernet LAN technologies. Finally we run some experiments in a small testbed to evaluate the performance and system behaviour. We evaluate the impact on throughput with varying packet size, coding types and device separation distance sending both images and text. We also present our findings in term of inquiry delay with respect to distance. Numerical results show that Bluetooth offers a relatively steady throughput up to 10 m while the inquiry delay does not increase significantly with distance. Keywords: bluetooth, java, ubiquitous computing, contex aware systems
1. Introduction The term “ubiquitous computing” refers to making many computing devices available throughout the physical environment, while making them effectively invisible to the user [1]. Thanks to advances in devices processing power, extended battery life and the proliferation of mobile computing devices, the realization of ubiquitous computing has become more apparent. Strongly related to ubiquitous computing is context-aware computing. In context-aware computing, applications may change or adapt their functions, the way information is presented, and the user interfaces depending on the context (by inferring or sensing it) and the characteristics of the client using the system [2]. Research in these areas has gained popularity, attention, and importance [3–8]. Some context-aware applications today exploit mobile wireless communication technologies to interconnect computing devices along with various sensing technologies (such as motion sensors or electronic tags) to set up a new kind of intelligent environment where context-aware applications can search and use services in a transparent way without users’ intervention. Clearly, contextual services can provide useful information. However, designing contextaware applications is still a difficult task and much theoretical and practical research must be done to reach the Ubiquitous Computing era.
188 J.-C. Cano et al. One critical question still needs to be addressed is the identification of business scenarios that can move ubiquitous computing from academic and research laboratories into our everyday life. Various companies are already working to extend wireless technologies that will seamlessly connect to others nearby devices. However, despite the wide range of services and potential smarts applications that can benefit from using such tools, there is still no clear understanding about a realistic killer. We think that tourism could yield the business application area for the development of such potential applications. To this end, context-aware services combined with content-oriented applications could exploit wireless technology to provide personalized tours that could guide and assist tourist in museums or historical sites. The idea of using personal guides in museum and historical sites as potential applications for pervasive computing is not new. Other researchers have chosen this application area to demonstrate the practicality of implementing contextaware applications. One on the earlier prototypes of a mobile context-aware tour guide is the Cyberguide project [9]. The Cyberguide prototype uses the current location of users to provides visitors with services concerning location and information. For indoor applications, Cyberguide uses the infra-red technology as the positioning solution. On the other hand, for outdoor applications, they replace the infra-red positioning module with a GPS unit. Cyberguide presents an innovative architecture, which mainly focuses on the development of location-aware applications. However, further efforts are needed to improve on context awareness. Similar systems to Cyberguide have also been proposed by others including the GUIDE [10] project proposed at Lancaster University. Cyberguide and GUIDE were influenced by earlier location-aware work such as the PARCTab at Xerox PARC [11], the InfoPad project at Berkeley [12] and the Personal Shopping Assistant at AT&T [13]. The CoolTown project [6] at HP Laboratories focuses on building ubiquitous computing systems by embodying web technologies into the physical environment. The Websign project [14] is a component of the Cooltown research program which allows users to visualize services related to physical objects of interest. While websign could be adapted to offer tourist guide services, its intended use is more general, providing user interactions for services associated with physical objects. The Rememberer tool [15] is another interesting approach which, similar to the CoolTown project, chooses museums as the environment to implement context-aware applications. Rememberer is a tool which offers visitors of museums services for recording their visits. Each record, which can be consulted after the user’s visit, consists of a set of web pages with multimedia data, describing the visit. The location of the visitor is identified using infra-red technology and RFID sensors. Other related work performed as part of the Cooltown project include [16] and [17]. The Digital museum project [18] at Tokyo University uses smart cards to detect the proximity of visitors and then provide information about the exhibited objects. The provided information can be based on a static profile stored previously in the smart card. Similar work have also been done in [19] and [20], where infra-red infrastructure and wireless LAN connections were used for connectivity and location awareness respectively. In [21] authors uses the ns-2 simulator [22] to evaluate the feasibility and performance of using Bluetooth as the underlying networking technology to establish context-aware services. They compared results obtained from simulation with respect those obtained using a small real test bed. They observed that the simulation results obtain a quite smoother behavior that the real experiment.
UbiqMuseum: A Bluetooth and Java Based Context-Aware System 189 In this paper, we describe an experimental context-aware application, called UbiqMuseum, that provides context-aware information to museum visitors. The system gives precise information to visitors about what they are viewing, at their level of knowledge, and in their natural language. It can also provide a graphical user interface (GUI) adapted to their device (i.e., mobile phones, PDAs, or laptops). The application will also help to reduce costs incurred in guiding their museum visitors, and in keeping track of what the preferred pieces of art are, and so on. We developed a multi-process based Museum Data Server. We wrote clients and server code, providing routines to handle clients info request, profile logging and content filtering, formatting and delivery. We demonstrate the practicality of building a context-aware system by using UbiqMuseum as a proof of concept that integrates a combination of wireless technologies. Our proposed system employs Bluetooth [23], a versatile and flexible short-range wireless networking technology with low power consumption [24]. Bluetooth has the ability to locate close-by devices and discover the type of services they offer. Our prototype system allows us not only to confirm the correct behavior of the designed application but also to acquire experimental data to evaluate how well Bluetooth is suited for context-aware systems. The rest of this paper is organized as follows: Section 2 describes the end application and the overall system architecture. Section 3 presents the details of the implementation prototype and Section 4 illustrates the evaluation of the proposal. Finally, in Section 5, we give some concluding remarks.
2. The UbiqMuseum System Architecture The overall network architecture is based on the cooperation of an edge wireless network and a core wireless/wired network. The edge side is solely based on the Bluetooth technology used by mobile devices (i.e., PDAs, laptops, etc.). The core network is based on the integration of a fixed 100 Mbps Ethernet local area network and a wireless IEEE 802.11b WLAN used to connect mobile clients with servers. The system considers three types of software entities: clients applications, museum information points (MIPs), and the central data server. A visitor provided with a Bluetooth enabled PDA is the basic example of a mobile client. There is a MIP associated to one or more pieces of art or objects. MIPs are connected to the central server using any “adequate” combination of Bluetooth, Ethernet, or IEEE 802.11b permanent connections. The “adequacy” of the combination of devices depends on the physical layout of the facility. Figure 1 shows a pictorial representation of a UbiqMuseum architecture. A mobile client, while wondering around the museum, will continuously search for new MIPs through Bluetooth inquiry process. When a MIP is found, it is checked for if it can offer any new information of interest by using the Service Discovery Protocol (SDP) [23]. If the user wants to see the new information it should have to send the user profile that was entered in the initial configuration process. Knowing the user profile, the information point can process the request. It will then combine the user profile with an identifier of the object the user is viewing, and it will send it to the central server. There, the request is logged and processed, and a reply is returned to the information point which relays it to the client. The search for a MIP can take place automatically, which is the default option, or on user-demand. The user can change his profile at any time, for example whether he considers the obtained
190 J.-C. Cano et al.
Figure 1. The UbiqMuseum system architecture.
information is too advanced or too basic. This allows future access to be more in line with user expectation.
3. The Implementation The application was developed using the standard Java APIs for Bluetooth wireless technology (JABWT) [25] proposed by the Java Expert Group JSR-82. The JABWT standard provides the socket API to L2CAP. L2CAP provides a reliable channel and uses segmentation and reassembly on “Asynchronous Connection-Less” (ACL) packets. L2CAP also multiplexes communications through the Protocol/Service Multiplexor (PSM) field abstraction that works as a TCP port. 3.1. T H E M U S E U M C E N T R A L D A T A S E R V E R (MCDS) The museum central data server has two main functions: (a) to attend to connections for MIPs requests, and (b) to manage the SQL database, i.e., to handle all the information related to the pieces of art in the museum. The MCDS starts and waits for a connection on the default server port, which has been defined as 9999. When it receives a connection request, a new process is spawned to attend
UbiqMuseum: A Bluetooth and Java Based Context-Aware System 191 it and will receive a code operation (codop). If the codop corresponds to a MIP configuration request, the server will send to the MIP a list containing all the art objects in the museum. The MIP will select the piece of art to represent and then the central data server will disconnect. If the codop corresponds to a client information request, the data server will spawn another process to receive the user profile. The server will acknowledge each profile option received to provide higher data consistency check. Once the whole profile is received, the server will log the petition for security and for statistical information. This can help the museum to know which are the preferred objects, which have had more visits and routes followed throughout the museum, helping the internal exposition and organization. After logging the petition, the data server will obtain (according to the received profile) the requested information from the SQL database. This information will be sent back to the information point, which in turn will resend it to the mobile client. A client profile consists of a language of preference, the educational level, and the device type. The profile allows information to be formatted to take into account the graphical capabilities of the client and to determine the complexity of the explanations given. Once finished sending the data to the information point, the central server will disconnect. 1) Database Services Functionality: The central data server stores in a SQL database all the information related to the art objects. It is based on two different tables: (a) the information table, and (b) the description table. The information table consists of three different fields that store, for each art object: its identifier, the title and the author; the identifier field as its primary key. The description table stores the information related to every art object. It has a total of seven fields where the primary key is the combination of the the fifth first field. The SQL provides an higher level of security and a more efficient storage support and maintenance. Figure 2 shows the graphical user interface used by the central data server administrator to interact with the SQL database. As shown in the figure, it allows one to set up information on new pieces of art, store more items for a specific piece of art in different languages, and support for different client devices, etc. 3.2. T H E M U S E U M I N F O R M A T I O N P O I N T S (MIP S ) The museum information points are located between the central data server and the clients. The first action of a MIP is to connect to the museum server to retrieve the server configuration file. This configuration file has a list of all the art object in the museum. This list is presented
Figure 2. The GUI server side tool to cope with the MySQL database.
192 J.-C. Cano et al. to the information point administrator who has to choose the object for that information point to represent. After being assigned the represented art object, a MIP would start the Service Discovery Protocol (SDP) daemon and will register its service along with the appropriate attributes and the Protocol Service Multiplexer (PSM) values. Once all the SDP registrations have been done, the information point will create and bind the L2CAP layer sockets and wait for connections coming from the Bluetooth interface. When a connection comes in, the information point will spawn a child process to deal with the mobile client’s request. The child process will first log the client Bluetooth address and date of petition. Once the logging has finished, the information point will receive the client’s profile. The information point would send it to the central Server. There, it will get processed and according to the clients profile, the required information will be sent back and passed on to the client. The parent process will carry on waiting for further client petitions. Figure 3 shows the Java code that describes the Museum Information Point behavior. 3.3. M U S E U M I N F O R M A T I O N C L I E N T S The first step for each Museum Information Clients is initialization: the user has to state his preferences as a basic set of input parameters, that is: (a) the type of device, (b) the preferred
Figure 3. A sample of the java code for the museum information point (MIP).
UbiqMuseum: A Bluetooth and Java Based Context-Aware System 193 language and (c) the level of details to receive the information. Although this step just requires a minimal user interaction, the application also has a predefined profile for those mobile clients that do not consider to go through this step. The predefined profile uses the following parameters: (a) laptop, (b) English, and (c) intermediate. Once all the data is filled in, the application will search for information on what he views through Bluetooth inquiry process. If at least one MIP is found, it will proceed to do SDP searches. If only one device was found, the client will connect to that device. Otherwise, the application will create a list of founded objects with the title of the object in the users preferred language. Once the information point has been chosen, either because it was the only one or because the user had chosen it from the list, the application will connect to the device. Once connected, the mobile client will send the stored profile to the information point and it will eventually receive the information. Once all the information is received, the application will present it to the user. After the first retrieval of information, the entire process of inquiring, SDP searching, profile sending and information receiving is done automatically by a separate thread. The thread will only modify the user’s viewed data when new servers are found or the current MIP’s service is no longer available. UbiqMuseum reduces network traffic by using caching between the MIP and the central data server. We replace the cached information by notifying the MIP when new updated information is stored in the central database. Figure 4 presents the screen that UbiqMuseum will show to a non-expert Spaniard user, with a PDA device while viewing the “Las Meninas” painting in the “Prado” Museum, in Spain. The use of video and audio clips haven’t been included in the current version of UbiqMuseum due to the lack of Synchronous Connection Oriented (SCO) links support in the current inplementation of JSR-82 over USB Bluetooth devices. 3.4. T H E U B I Q M U S E U M S C A T T E R N E T S U P P O R T Bluetooth standard allows up to seven slaves devices and a master to form a centralized ad hoc network called a piconet. In UbiqMuseum each MIP acts as the master of its own piconet
Figure 4. A client screen capture of the application related to a non-expert Spaniard user, with a PDA device while viewing the “Las Meninas” painting in the “Prado” Museum, in Spain.
194 J.-C. Cano et al. which will allocate slots to all its clients. When we have an high density of clients around an art object we have to interconnect the multiple close-by piconets to form a scatternet. The Bluetooth standard does not specify a specific scatternet formation algorithm. Achieving an optimal scatternet topology is currently the subject of intensive research [26–28]. The different approaches try to obtain a scatternet topology similar to the one in Figure 5. Two piconets can communicate by sharing one or more “bridge” devices. These bridges may either act as a master in one and as slave in the other or as a slave in both piconets, but not as a master in both. However most of the studies have not directly addressed the issues related to the implementation. For example, for the master/slave (M/S) bridge device in piconet 3 to operate, it should have to enter the hold mode with respect to its piconet and the active mode with respect to piconet 1. This implies that communications in its piconet will be suspended until the hold period terminates. On the other hand, to connect piconet 1 and piconet 2, the slave/slave (S/S) bridge enters the hold mode in piconet 2 and becomes active in piconet 1. During the hold time no POLL packet is sent, from the master device of piconet 2. Whenever a bridge device is active in one piconet, it buffers data packets intended for the next piconet and delivers them to the next piconet when it expires the hold time. Thus, all the messages from one piconet to another pass thought these bridge device. Siegemund and Rohs [29] showed that master/slave bridges could result in reduced throughput, while slave/slave bridges require more complex negotiation protocols between masters sharing the slave devices. Moreover, the inter piconets scheduling protocols in scatternets with slave/slave bridges devices require complex coordination mechanism to enable such bridges in an appropriate manner [30]. Since for the UbiqMuseum application nodes do not need excessive bandwidth we will use bridges devices operating only in the master-slave scheme, passing all the inter-piconet communication via the masters, which will switch among piconets. Moreover, this approach allow us to simplify the inter-piconets scheduling protocols. The scatternet algorithm we propose is based on using the hold mode to allow a device to leave a piconet and to join another one without any modifications to the Bluetooth specifications. We limited a piconet to a master and a maximum of five slave devices. According to [31] using five slave devices allows a tradeoff between path length and piconet congestion. We thus, reserve two connection per piconet that will be used for bridge connections. The MIP of each art object will create the first piconet of the scatternet. When more
Figure 5. Example topology where three piconets are connected to form a scatternet network.
UbiqMuseum: A Bluetooth and Java Based Context-Aware System 195 than five clients get within reach of the same MIP, they will create successive piconets using the following mechanism. 1) Scatternet Formation Algorithm: When a mobile client device cannot join the MIP’s piconet, it will try to discover any other master that is acting as a bridge to the MIP’s piconet. If no bridge is found, the device creates its own piconet by acting as the master and as a bridge to the MIP’s piconet. For this new master to be discovered, it will register a new service called Bridge to the MIP. The bridge device periodically goes into the hold mode to relay packets from the MIP’s piconet to its own piconet members. The master device will periodically POLL its slaves. When a client requires the associated art object information, its piconet master will relay the requested information to the MIP. To join the MIP’s piconet, the bridge enters the hold mode in its piconet and then enable the INQUIRY SCAN status in the MIP piconet. The MIP master device will discover it using the periodic INQUIRY messages. When the hold time expires, the bridge will leave the MIP piconet, and relay the received information to the slave, that is the client. The minimum interval that the bridge will spend “outside” its piconet is calculated according to the following parameters: the overhead incurred by entering the hold mode, the time a bridge requires to join a piconet and the time to get the information from the MIP. This period should not be anyway greater than the maximum hold time specified in the standard (40.9 seconds or 65440 slots). To select the minimum hold time, Section 4 evaluates the inquiry delay and throughput performance of UbiqMuseum application in our laboratory testbed. Figure 6 shows the overall handshake sequence for a bridge device. 2) Additional Remarks.: We consider the scatternet to be formed around each MIP. We then assume that all the master nodes in the same scatternet are within direct radio range with the MIP of the scatternet. We think this assumption is reasonable in a scenario like a museum where the application should offer context-aware information to those visitor that are located
Figure 6. Sequence diagram for the bridge operation.
196 J.-C. Cano et al. in the vicinity of each art object. Moreover, in Section 4 we observe that Bluetooth offers a quite steady throughput behavior for distances up to 10 m. Bridges devices are identified using the 48-bit Bluetooth device address. Also, they register a Bridge to the MIP service, allowing other nodes to identify and select them. The master of each piconet constantly updates its list of active slaves using a round robin intra-piconet scheduling through the POLL data packet. When any of the slaves does not acknowledge the POLL packet the master assumes that the node left and it will accommodate new vacant in its piconet for new devices. The slaves devices can also detect that the master has gone if they do not receive POLL data packet from the master for a given timeout. In those cases the slaves will behave just like a node just been turned-on. Finally, the protocol could be simplified even more if we have multi-function Bluetooth devices that can act simultaneously as a master of a piconet and a slave in another. Therefore, with multi-function devices our approach could be able to maintain the scatternet without using the hold mode.
4. Performance Evaluation of UbiqMuseum We evaluated our application using a small testbed to confirm its correct behavior. We also acquired experimental data to investigate how well Bluetooth supports our context-aware application. Our experiments focused on evaluating throughput performance and inquiry delay of the Bluetooth channel. We used the results obtained to tune the time a bridge device should spend in hold mode. We performed a sensitivity analysis to evaluate how spatial distance affects throughput and inquiry delay. The museum data server and the MIP run on an Intel Pentium IV 2400 Mhz standard PC based on Suse Linux 8.2 with a 3Com CREB96 Bluetooth USB Dongle card. The museum information mobile client runs on an Intel Pentium IV 2000 Mhz TOSHIBA Satellite 1900-303 laptop based on Suse Linux 8.1 with a 3Com CREB96 Bluetooth USB Dongle card. 4.1. T H R O U G H P U T E VA L U A T I O N We first evaluate the impact on throughput with varying ACL packet types and the devices distances. An Asynchronous Connection-Less (ACL) link is parameterized by packet size and data encoding. Each ACL link allows the use of 1, 3, and 5 data slots, where a slot is 625 μs long. Additionally, it allows the optional use of Forward Error Correction (FEC). According to these parameters, at the baseband layer, Bluetooth offers 6 different data packets that can be classified in two main groups. Data Medium Rate packets, (DM packets) provide a 2/3 FEC Hamming code and Data High Rate packets, (DH) where FEC coding is absent. After the inquiry process is completed, the information point will collect all the parameters it needs from the client. After that, it will send the actual data-block to the mobile client. The application data block size is 150 kbytes on average, which includes images and text. We configured the information point to continuously send a data block to the museum client during 100 s. The throughput for each data block received is calculated at the client side. Figure 7 shows the obtained results when the information point side is using DH packets and DM packets respectively.
UbiqMuseum: A Bluetooth and Java Based Context-Aware System 197 100
100 Data High Rate (DH5)
Data Medium Rate (DM5)
Data High Rate (DH3)
Data Medium Rate (DM1)
75
Throughput (Kbytes/s)
Throughput (Kbytes/s)
Data Medium Rate (DM3)
Data High Rate (DH1)
75
50
50
25
25
0
0 0m
2m
4m
6m
8m
10 m
12 m
14 m
Distance (m)
16 m
0m
2m
4m
6m
8m
10 m
12 m
14 m
16 m
Distance (m)
Figure 7. Comparison of application throughput of an ACL link under different D Hx and D Mx packets with respect to distance.
Firstly, we observe that Bluetooth offers a relatively stable throughput up to 10 m, independent of the data packet type chosen. Beyond 10 m, the application still works without a sharp performance degradation. When we select the more efficient DH data packets, throughput increases when compared to using DM packets. At 10 m the DH packets outperform the DM ones by 57%, 46% and 32% respectively for 1, 3, and 5 slots packets. The results confirm that although using DM packets increases efficiency but lowers probability of successful transmission, DH packets can be chosen for more efficient transmissions. Moreover, after 10 m, as distance increases, longer packets (DH5 and DH3) suffer a higher degradation. Finally, we observed that all obtained results are below the maximum throughput stated in Bluetooth specification. The Bluetooth standard provides the following reference values: 90.40 kB/s for DH5, 73.20 kB/s, for DH3 and 21.60 kB/s for DH1; 59.72 kB/s for DM5, 48.40 kB/s, for DM3 and 13.60 kB/s for DM1. Below 10 m, the application gets a 74%, 85%, and 91% of the maximum throughput provided in the standard for the DH (5, 3, 1) packets respectively. When using the more conservative DM (5, 3, 1) packets, this percentage gets to 85%, 87%, and 93%. The reason for these differences might stand in the environment where the experiments were conducted. Our laboratory has a IEEE 802.11 based access point that might interfere with Bluetooth devices. In fact, these results confirm that ideal conditions cannot always be achieved and hence application must be designed to take Bluetooth bandwidth limitations and fluctuation into consideration. 4.2. I N Q U I R Y D E L A Y E VA L U A T I O N We now measure the duration of the inquiry procedure. We evaluated two different cases: with the distance from the client to the master device fixed to 1m, and with a distance of 10m. Figure 8 shows the obtained inquiry delay at the museum client using a distance of 1 m. The results shows an average inquiry delay of 2.31 s ± 0.36 and a standard deviation equal to 1.81 ± 0.25 with a confidence interval of 95%. As we increase the distance among nodes to 10 m, we obtain an average inquiry delay of 2.36 s and a standard deviation of 2.0 with the same confidence interval. Therefore, it is observed that the inquiry procedure delay does not increase significantly with distance. In [32] the authors reports similar results. Figure 9 shows the histogram distribution of the inquiry delay and the cumulative results as a function of time for the 100 tests. The results show that at an average of 2.45 s, users
198 J.-C. Cano et al. 10,000
10,000
Inquiry delay (Avg: 2,364, Std: 2,033)
8,000
8,000
6,000
6,000
Time (sec)
Time (sec)
Inquiry delay (Avg: 2,313, Std: 1,8122)
4,000
4,000
2,000
2,000
0,000
0,000 0
10
20
30
40
50
60
70
80
0
90
10
20
30
40
50
60
70
80
90
# Test number
# Test number
Figure 8. The inquiry delay value for 100 tests. Distance between the MIP and the mobile client is 1 m and 10 m. 10
100% Histograma Inquiry delay 80%
6
60%
4
40%
2
20%
0
Cumulative
Histogram frequency (# Tests)
Cumulative inquiry time 8
0% 0
1000
2000
3000
4000
5000
6000
7000
8000
9000
Time (ms)
Figure 9. The cumulative inquiry delay distribution for 100 tests. Distance between the MIP and the mobile client is 1 m.
can discover desired information almost 50% of the time. This waiting time of 2.45 s is normally acceptable to a user without causes annoyance. Most importantly, we observe that this percentage increases to 95% only after 5.26 s. Therefore, we can approximately assume 5 s as the highest waiting time for the inquiry process. Finally, all the experiments done in the laboratory, reported that the maximum time a bridge node will spend in hold mode should not be anyway greater than 15s, including, in the worst case, the maximum inquiry delay needed to switch among piconets and the time to get the information from the server. 5. Conclusions In this paper, we demonstrate that Bluetooth might be a candidate wireless networking technology to support ubiquitous context-aware applications. Application programming interfaces such as BlueZ and JSR-82, although under development, can be used to build mobile client and server code. We presented UbiqMuseum which is an experimental Bluetooth-based context-aware application developed in Java. UbiqMuseum combines the convenience and productivity of Java with the universal connectivity of Bluetooth wireless technology. The system was designed to
UbiqMuseum: A Bluetooth and Java Based Context-Aware System 199 give visitors precise information about what they are viewing at their level of knowledge and in their natural language of preference. Also, it gives the user a GUI which can be adapted to their devices, hence enhancing their experiences. We developed a multi-process based Museum Data Server. We wrote clients and server code, providing routines to handle clients info request, profile logging and content filtering, formatting and delivery. We constructed the UbiqMuseum system using both edge wireless network and a core wireless/wired network. The edge side is solely based on the Bluetooth technology while the core network is based on a fixed Ethernet LAN and a wireless IEEE 802.11b LAN. The edge network integrates one or more close-by mobile users’ devices. From the UbiqMuseum user’s viewpoint, information points associated to any object are detected without user’s intervention, and users can obtain new information about what they are viewing. We have demonstrated the practicality of building a context-aware system that integrates a combination of Bluetooth, WLAN and Ethernet LAN technologies. We have also supplied UbiqMuseum with scatternet support and revealed some important issues associated with Bluetooth scatternet formation, implementation details and performance degradation. Performance evaluation of UbiqMuseum was made with focus on throughput and inquiry delay. We evaluated the impact on throughput with varying packet size, FEC coding types and device separation distance. We observed that Bluetooth offered a relatively steady throughput up to 10 m, independent of the data packet type selected. The results had also confirmed that although the use of DM packets improved efficiency while reducing the probability of successful transmission, DH packets can be good candidates for more efficient transmissions. Our experiments had also showed that the delay incurred during inquiry did not increase significantly with distance. Key issues related to future advanced mobile context-aware systems include the design needed to obtain high throughput and fast service discovery, while offering the user with a fast information download and a fast and easy entry of users profiles. Our prototype software of UbiqMusem is available publicly at http://www.grc.upv.es/software.html. Acknowledgments This work was partially supported by the Generalitat Valenciana, Spain, under Grant GV05/245 and by the Ministerio de Educaci´on y Ciencia, Spain, under Grant TIN2005-07705-C02-01. References 1. M. Weiser, “The Computer for the 21st Century”, Scientific American pp. 256, 94–104, 1991. 2. M. Weiser, “Some Computer Science Problems in Ubiquitous Computing”, Communications of the ACM (1993). 3. Project Oxygen, “Massachusetts Institute of Technology”, Cambridge, USA. Web page: http://oxygen. lcs.mit.edu/. 4. The connected project: Swedish Institute of Computer Science (SICS), Uppsala University. Web page: http://www.sics.se/cna/connected/. 5. A. Harter, A. Hopper, P. Steggeles, A. Ward, and P. Webster, “The Anatomy of a Context-Aware Application”, Proceedings of the Fifth Annual ACM/IEEE International Conference on Mobile Computing and Networking (MOBICOM) (1999). 6. T. Kindberg, “People, Places, Things: Web presence for the real world. Technical Report HPL-2000-16”, Internet and Mobile System Laboratory, Laboratories Palo Alto, 2000.
200 J.-C. Cano et al. 7. Ambient agoras, “Dynamic Information Controls in a Hybrid World”, (The Integrated Publication and Information Systems Institute (IPSI). Web page: http://www.ambient-agoras.org/. 8. Smart-its, “Interconnected Embedded Technology for Smart Artefacts with Collective Awareness”, Lancaster University, ETH Zurich. Web page http://www.smart-its.org/. 9. G. Abowd, C. Atkeson, J. Hong S. Long, R. Kooper, and M. Pinkerton, “Cyberguide: A Mobile Context-Aware Tour Guide”, ACM wireless Networks, Vol 3, No. 5, pp. 421–433, 1997. 10. N. Davies, K.K. Mitchell, and G. Cheverst, “Blair: Developing A Context Sensitive Tourist Guide”, Technical Report Computing Department, Lancaster University, 1998. 11. R. Want, A. Hopper, V. Falcao, and J. Gibbons, “The Active Badge Location System”, ACM Transactions on Information Systems, Vol. 10, No. 1, 1992. 12. S. Long, R. Kooper, G.D. Abowd, and C.G. Atkeson, “Rapid Prototyping of Mobile Context-Aware Applications: The Cyberguide Case Study”, In Proceedings of the 2nd Annual International Conference on Mobile Computing and Networking, November 1996. 13. A. Asthana, M. Cravatts, and P. Krzyzanouski, “An Indoor Wireless System for Personalized Shopping Assistance”, Workshop on Mobile Computing Systems and Applications, December 1994. 14. S. Pradhan, C. Brignone, J. Cui, A. McReynolds, and M. Smith, “Websign: Hyperlinks from A Physical Location to the Web”, Technical Report HP Laboratories, Web page: http://www.cooltown.hp.com/. 15. M. Fleck, Ma. Frid, T. Kindberg, E. OBrien-Strain, and M.R. Rajani, “Spasojevic Rememberer: A Tool for Capturing Museum Visits”, Proceedings of the Ubiquitous Computing International Conference, Ubicomp 2002. 16. M. Spasojevic, Mirjana, and T. Kindberg, “A Study of an Augmented Museum Experience”, Technical Report HP Laboratories, Web page: http://www.cooltown.hp.com/. 17. R. Semper and M. Spasojevic, “The Electronic Guidebook: Using Portable Devices and a Wireless Web-based Network to Extend the Museum Experience”, Proceedings of the museums and the Web 2002. 18. K. Sakamura, “Digital Museum” Journal of Information Processing Society of Japan (JIPS), Vol. 39, Number 5, 1998. 19. S. Davin and L. Ing, “Innovations in a Technology Museum”, IEEE Micro, Vol. 19, No. 6, 1999. 20. R. Oppermann and M. Specht, “A Context-Sensitive Normadic Exhibition Guide”, In Proceedings of the HUC2000. 21. J. C. Cano, D. Ferr´andez, and P. Manzoni, “Evaluating Bluetooth Performance as the Support for Context-Aware Applications”, Telecommunication Systems, No. 5, 2005. 22. K. Fall and K. Varadhan, “ns Notes and Documents”, The VINT Project. UC Berkeley, LBL, USC/ISI, and Xerox PARC, February 2000, Available at http://www.isi.edu/nsnam/ns/ns-documentation.html. 23. Promoter Members of Bluetooth SIG: Specification of the Bluetooth System – Core. Version 1.1. Bluetooth SIG, Inc. (2001). 24. J. Beutel and O. Kasten, “A Minimal Bluetooth-Based Computing and Communication Platform” Technical report, Computer Engineering and Networks Lab, Swiss Federal Institute of Technology (ETH) Zurich (2001). 25. Kumar, B., JSR-82: Java APIs for Bluetooth. Available at: http://www.jcp.org/en/jsr/detail?id=82. 26. C. Law and K.Y. Siu, “A Bluetooth Scatternet Formation Algorithm”, Proceedings of the IEEE Symposium on Ad Hoc Wireless Networks 2001. 27. T. Salonidis, P. Bhagwat, L. Tassiulas, and R. LaMaire, “Distributed Topology Construction of Bluetooth Personal Area Networks”, Proceedings of IEEE INFOCOMM, Anchorage, Alaska, USA 2001. 28. S. Basagni and C. Petrioli, “A Scatternet Formation Protocol for ad hoc Networks of Bluetooth Devices”, Proceedings of IEEE VTC Spring 2002. 29. F. Siegemund, and M. Rohs, “Rendezvous Layer Protocols for Bluetooth-Enables Smart Devices”, Proceedings of International Conference on Architecture of Computing Systems 2002. 30. P. Johansson, M. Kazantzidis, R. Kapoor, and M. Gerla, “Bluetooth: An Enabler for Personal Area Networking”, IEEE Network 15 2001. 31. A. Seth and A. Kashyap, “Capacity of Bluetooth Scatternets”, Master’s thesis, Computer Science and Engineering Department, Indian Institute of Technology Kanpur, India (2002). 32. A. Beaufour, M. Lepold and P. Bonnet, Smart-Tag Based Data Disseminations. 1st ACM workshop on Wireless Sensor Network and Applications. 2002.
UbiqMuseum: A Bluetooth and Java Based Context-Aware System 201
Juan-Carlos Cano is an assistant professor in the Department of Computer Engineering at the Polytechnic University of Valencia (UPV) in Spain. He earned an M.Sc. and a Ph.D. in computer science from the UPV in 1994 and 2002 respectively. Between 1995–1997 he worked as a programming analyst at IBM’s manufacturing division in Valencia. His current research interests include power aware routing protocols for mobile ad hoc networks and pervasive computing. You can contact him at
[email protected].
Pietro Manzoni received the MS degree in computer science from the “Universit´a degli Studi” of Milan, Italy, in 1989, and the Ph.D. degree in computer science from the Polytechnic University of Milan, Italy, in 1995. He is an associate professor of computer science at the Polytechnic University of Valencia, Spain. His research activity is related to wireless networks protocol design, modeling, and implementation. He is member of the IEEE.
C.-K. Toh is currently a Professor and Chair in Communication Networks at Queen Mary University of London, UK. He is also the Director of the UK Ad Hoc Wireless Consortium and Director of the Queen Mary/Fudan Joint Research Lab in Mobile Networking and Ubiquitous Computing. Concurrently, he is also an Honorary Professor with the University of Hong Kong
202 J.-C. Cano et al. and an Adjunct Professor at Fudan University, Shanghai. Previously, he was the Director of Research with TRW Tactical Systems in California, USA (now Northrop Grumman Corporation) and was responsible for DARPA and Army programs in communications and networking. He had also worked for Hughes Research, ALR, HP, and was a professor at GeorgiaTech and University of California, Irvine. CK is the recipient of the 2005 IEEE Kiyo Tomiyasu Technical Medal Award, for “pioneering contributions to communication protocols in ad hoc mobile wireless networks.” He is the author of “Wireless ATM & Ad Hoc Networks” (Kluwer Press, 1996) and “Ad Hoc Mobile Wireless Networks” (Prentice Hall Engineering Title Best Seller, 2001–2003). He is a recipient of the ACM Recognition of Service Award, for co-founding ACM MobiHoc Conference. He is a co-recipient of the Korean Science & Engineering Foundation Best Journal paper Award for his work on ad hoc TCP. CK was formerly the Chairman of IEEE Communications Society Technical Committee on Computer Communications and Chairman of IEEE Subcommittee on Ad Hoc Mobile Wireless Networks. He was an IEEE Expert/Distinguished Lecturer and had served as a Steering Committee Member for IEEE WCNC Conference and IEEE Transaction on Mobile Computing. He was a member of IEEE Communications Society Meetings & Conferences Board. CK was an editor for IEEE Networks, IEEE JSAC, IEEE transactions on Wireless Communications, Journal on Communication Networks, and IEEE Distributed Systems. He is a Fellow of four societies: British Computer Society, the IEE, the Hong Kong Institution of Engineers and the New Zealand Computer Society. He received his Ph.D. degree in Computer Science from Cambridge University, England, and his executive education from Harvard.
