UbiqMuseum: A Bluetooth and Java Based Context-Aware System for Ubiquitous Computing

Wireless Personal Communications (2006) 38: 187–202DOI: 10.1007/s11277-005-9001-x C© Springer 2006

UbiqMuseum: A Bluetooth and Java Based Context-Aware Systemfor Ubiquitous Computing

JUAN-CARLOS CANO1, PIETRO MANZONI1 and C.-K. TOH2

1Polytechnic University of Valencia, Camino de Vera, s/n, 46071 Valencia, SpainE-mail: {jucano, pmanzoni}@disca.upv.es2University of Hong KongE-mail: [email protected]

Abstract. This paper evaluates the use of Bluetooth and Java based technologies in ubiquitous computing en-vironments. 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 experimen-tal context-aware application that provides context-aware information to museum visitors. UbiqMuseum combinesthe productivity of Java with the universal connectivity provided by Bluetooth wireless technology. We describethe overall architecture and discuss the implementation steps taken to create our Bluetooth and Java based context-aware application. We demonstrate practicality of building a context-aware system by using UbiqMuseum as aproof of concept that integrates a combination of Bluetooth, WLAN and Ethernet LAN technologies. Finally werun some experiments in a small testbed to evaluate the performance and system behaviour. We evaluate the impacton throughput with varying packet size, coding types and device separation distance sending both images andtext. We also present our findings in term of inquiry delay with respect to distance. Numerical results show thatBluetooth offers a relatively steady throughput up to 10 m while the inquiry delay does not increase significantlywith distance.

Keywords: bluetooth, java, ubiquitous computing, contex aware systems

1. Introduction

The term “ubiquitous computing” refers to making many computing devices available through-out the physical environment, while making them effectively invisible to the user [1]. Thanksto advances in devices processing power, extended battery life and the proliferation of mobilecomputing devices, the realization of ubiquitous computing has become more apparent.

Strongly related to ubiquitous computing is context-aware computing. In context-awarecomputing, applications may change or adapt their functions, the way information is pre-sented, and the user interfaces depending on the context (by inferring or sensing it) and thecharacteristics 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 technolo-gies to interconnect computing devices along with various sensing technologies (such as motionsensors or electronic tags) to set up a new kind of intelligent environment where context-awareapplications can search and use services in a transparent way without users’ intervention.

Clearly, contextual services can provide useful information. However, designing context-aware applications is still a difficult task and much theoretical and practical research must bedone 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 scenariosthat can move ubiquitous computing from academic and research laboratories into our everydaylife.

Various companies are already working to extend wireless technologies that will seamlesslyconnect to others nearby devices. However, despite the wide range of services and potentialsmarts applications that can benefit from using such tools, there is still no clear understandingabout a realistic killer.

We think that tourism could yield the business application area for the development of suchpotential applications. To this end, context-aware services combined with content-oriented ap-plications could exploit wireless technology to provide personalized tours that could guide andassist tourist in museums or historical sites. The idea of using personal guides in museum andhistorical sites as potential applications for pervasive computing is not new. Other researchershave chosen this application area to demonstrate the practicality of implementing context-aware applications.

One on the earlier prototypes of a mobile context-aware tour guide is the Cyberguideproject [9]. The Cyberguide prototype uses the current location of users to provides visitorswith services concerning location and information. For indoor applications, Cyberguide usesthe infra-red technology as the positioning solution. On the other hand, for outdoor applica-tions, they replace the infra-red positioning module with a GPS unit. Cyberguide presents aninnovative architecture, which mainly focuses on the development of location-aware applica-tions. However, further efforts are needed to improve on context awareness. Similar systemsto Cyberguide have also been proposed by others including the GUIDE [10] project proposedat Lancaster University. Cyberguide and GUIDE were influenced by earlier location-awarework such as the PARCTab at Xerox PARC [11], the InfoPad project at Berkeley [12] and thePersonal Shopping Assistant at AT&T [13].

The CoolTown project [6] at HP Laboratories focuses on building ubiquitous computingsystems 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 servicesrelated to physical objects of interest. While websign could be adapted to offer tourist guideservices, its intended use is more general, providing user interactions for services associatedwith physical objects. The Rememberer tool [15] is another interesting approach which, similarto the CoolTown project, chooses museums as the environment to implement context-awareapplications. Rememberer is a tool which offers visitors of museums services for recordingtheir visits. Each record, which can be consulted after the user’s visit, consists of a set of webpages with multimedia data, describing the visit. The location of the visitor is identified usinginfra-red technology and RFID sensors. Other related work performed as part of the Cooltownproject include [16] and [17].

The Digital museum project [18] at Tokyo University uses smart cards to detect the prox-imity of visitors and then provide information about the exhibited objects. The provided infor-mation can be based on a static profile stored previously in the smart card. Similar work havealso been done in [19] and [20], where infra-red infrastructure and wireless LAN connectionswere used for connectivity and location awareness respectively.

In [21] authors uses the ns-2 simulator [22] to evaluate the feasibility and performance ofusing Bluetooth as the underlying networking technology to establish context-aware services.They compared results obtained from simulation with respect those obtained using a smallreal test bed. They observed that the simulation results obtain a quite smoother behavior thatthe 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 infor-mation to visitors about what they are viewing, at their level of knowledge, and in their naturallanguage. 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 inguiding 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 servercode, 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 byusing 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 wire-less networking technology with low power consumption [24]. Bluetooth has the ability tolocate close-by devices and discover the type of services they offer. Our prototype systemallows us not only to confirm the correct behavior of the designed application but alsoto acquire experimental data to evaluate how well Bluetooth is suited for context-awaresystems.

The rest of this paper is organized as follows: Section 2 describes the end application andthe overall system architecture. Section 3 presents the details of the implementation prototypeand Section 4 illustrates the evaluation of the proposal. Finally, in Section 5, we give someconcluding remarks.

2. The UbiqMuseum System Architecture

The overall network architecture is based on the cooperation of an edge wireless network anda core wireless/wired network. The edge side is solely based on the Bluetooth technology usedby mobile devices (i.e., PDAs, laptops, etc.). The core network is based on the integration ofa fixed 100 Mbps Ethernet local area network and a wireless IEEE 802.11b WLAN used toconnect mobile clients with servers.

The system considers three types of software entities: clients applications, museum infor-mation points (MIPs), and the central data server. A visitor provided with a Bluetooth enabledPDA is the basic example of a mobile client. There is a MIP associated to one or more piecesof art or objects. MIPs are connected to the central server using any “adequate” combinationof Bluetooth, Ethernet, or IEEE 802.11b permanent connections. The “adequacy” of the com-bination of devices depends on the physical layout of the facility. Figure 1 shows a pictorialrepresentation of a UbiqMuseum architecture.

A mobile client, while wondering around the museum, will continuously search for newMIPs through Bluetooth inquiry process. When a MIP is found, it is checked for if it can offerany 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 wasentered in the initial configuration process. Knowing the user profile, the information pointcan process the request. It will then combine the user profile with an identifier of the objectthe user is viewing, and it will send it to the central server. There, the request is logged andprocessed, and a reply is returned to the information point which relays it to the client. Thesearch 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


Figure 1. The UbiqMuseum system architecture.

information is too advanced or too basic. This allows future access to be more in line with userexpectation.

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 providesthe socket API to L2CAP. L2CAP provides a reliable channel and uses segmentation andreassembly on “Asynchronous Connection-Less” (ACL) packets. L2CAP also multiplexescommunications through the Protocol/Service Multiplexor (PSM) field abstraction that worksas a TCP port.

3.1. THE MUSEUM CENTRAL DATA SE R VE R (MCDS)

The museum central data server has two main functions: (a) to attend to connections for MIPsrequests, and (b) to manage the SQL database, i.e., to handle all the information related to thepieces of art in the museum.

The MCDS starts and waits for a connection on the default server port, which has beendefined as 9999. When it receives a connection request, a new process is spawned to attend


it and will receive a code operation (codop). If the codop corresponds to a MIP configurationrequest, the server will send to the MIP a list containing all the art objects in the museum. TheMIP 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 anotherprocess to receive the user profile. The server will acknowledge each profile option receivedto provide higher data consistency check. Once the whole profile is received, the server willlog the petition for security and for statistical information. This can help the museum to knowwhich are the preferred objects, which have had more visits and routes followed throughoutthe museum, helping the internal exposition and organization. After logging the petition, thedata server will obtain (according to the received profile) the requested information from theSQL database. This information will be sent back to the information point, which in turnwill resend it to the mobile client. A client profile consists of a language of preference, theeducational level, and the device type. The profile allows information to be formatted to takeinto account the graphical capabilities of the client and to determine the complexity of theexplanations given. Once finished sending the data to the information point, the central serverwill disconnect.

1) Database Services Functionality: The central data server stores in a SQL database all theinformation related to the art objects. It is based on two different tables: (a) the informationtable, and (b) the description table. The information table consists of three different fields thatstore, for each art object: its identifier, the title and the author; the identifier field as its primarykey. The description table stores the information related to every art object. It has a total ofseven fields where the primary key is the combination of the the fifth first field. The SQLprovides 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 administratorto interact with the SQL database. As shown in the figure, it allows one to set up informationon new pieces of art, store more items for a specific piece of art in different languages, andsupport for different client devices, etc.

3.2. THE MUSEUM INFORMATION POINTS (MIPS)

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 configurationfile. 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.


to the information point administrator who has to choose the object for that information pointto represent. After being assigned the represented art object, a MIP would start the ServiceDiscovery Protocol (SDP) daemon and will register its service along with the appropriateattributes and the Protocol Service Multiplexer (PSM) values.

Once all the SDP registrations have been done, the information point will create and bindthe 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 withthe mobile client’s request. The child process will first log the client Bluetooth address anddate of petition. Once the logging has finished, the information point will receive the client’sprofile. The information point would send it to the central Server. There, it will get processedand according to the clients profile, the required information will be sent back and passed onto the client. The parent process will carry on waiting for further client petitions. Figure 3shows the Java code that describes the Museum Information Point behavior.

3.3. MUSEUM INFORMATION CL I E N T S

The first step for each Museum Information Clients is initialization: the user has to state hispreferences 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).


language and (c) the level of details to receive the information. Although this step just requiresa minimal user interaction, the application also has a predefined profile for those mobileclients that do not consider to go through this step. The predefined profile uses the followingparameters: (a) laptop, (b) English, and (c) intermediate. Once all the data is filled in, theapplication 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 foundedobjects with the title of the object in the users preferred language. Once the information pointhas been chosen, either because it was the only one or because the user had chosen it from thelist, the application will connect to the device.

Once connected, the mobile client will send the stored profile to the information point andit will eventually receive the information. Once all the information is received, the applicationwill 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 separatethread. The thread will only modify the user’s viewed data when new servers are found or thecurrent MIP’s service is no longer available. UbiqMuseum reduces network traffic by usingcaching between the MIP and the central data server. We replace the cached information bynotifying 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, inSpain. The use of video and audio clips haven’t been included in the current version ofUbiqMuseum due to the lack of Synchronous Connection Oriented (SCO) links support in thecurrent inplementation of JSR-82 over USB Bluetooth devices.

3.4. THE UBIQMUSEUM SC A T T E R N E T SUPPORT

Bluetooth standard allows up to seven slaves devices and a master to form a centralized ad hocnetwork 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 whileviewing the “Las Meninas” painting in the “Prado” Museum, in Spain.


which will allocate slots to all its clients. When we have an high density of clients around anart 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. Achiev-ing an optimal scatternet topology is currently the subject of intensive research [26–28]. Thedifferent approaches try to obtain a scatternet topology similar to the one in Figure 5. Twopiconets can communicate by sharing one or more “bridge” devices. These bridges may eitheract as a master in one and as slave in the other or as a slave in both piconets, but not as a masterin both.

However most of the studies have not directly addressed the issues related to the imple-mentation. For example, for the master/slave (M/S) bridge device in piconet 3 to operate, itshould have to enter the hold mode with respect to its piconet and the active mode with respectto piconet 1. This implies that communications in its piconet will be suspended until the holdperiod 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 holdtime no POLL packet is sent, from the master device of piconet 2. Whenever a bridge deviceis active in one piconet, it buffers data packets intended for the next piconet and delivers themto the next piconet when it expires the hold time. Thus, all the messages from one piconet toanother pass thought these bridge device.

Siegemund and Rohs [29] showed that master/slave bridges could result in reduced through-put, while slave/slave bridges require more complex negotiation protocols between masterssharing the slave devices. Moreover, the inter piconets scheduling protocols in scatternets withslave/slave bridges devices require complex coordination mechanism to enable such bridgesin an appropriate manner [30].

Since for the UbiqMuseum application nodes do not need excessive bandwidth we willuse bridges devices operating only in the master-slave scheme, passing all the inter-piconetcommunication via the masters, which will switch among piconets. Moreover, this approachallow us to simplify the inter-piconets scheduling protocols.

The scatternet algorithm we propose is based on using the hold mode to allow a de-vice to leave a piconet and to join another one without any modifications to the Bluetoothspecifications. We limited a piconet to a master and a maximum of five slave devices. Ac-cording to [31] using five slave devices allows a tradeoff between path length and piconetcongestion. We thus, reserve two connection per piconet that will be used for bridge connec-tions. 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.


than five clients get within reach of the same MIP, they will create successive piconets usingthe 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 nobridge is found, the device creates its own piconet by acting as the master and as a bridge tothe MIP’s piconet. For this new master to be discovered, it will register a new service calledBridge to the MIP. The bridge device periodically goes into the hold mode to relay packetsfrom the MIP’s piconet to its own piconet members. The master device will periodically POLLits slaves.

When a client requires the associated art object information, its piconet master will relaythe requested information to the MIP. To join the MIP’s piconet, the bridge enters the holdmode in its piconet and then enable the INQUIRY SCAN status in the MIP piconet. The MIPmaster device will discover it using the periodic INQUIRY messages. When the hold timeexpires, 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 iscalculated according to the following parameters: the overhead incurred by entering the holdmode, the time a bridge requires to join a piconet and the time to get the information from theMIP. This period should not be anyway greater than the maximum hold time specified in thestandard (40.9 seconds or 65440 slots). To select the minimum hold time, Section 4 evaluatesthe inquiry delay and throughput performance of UbiqMuseum application in our laboratorytestbed. 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 thenassume that all the master nodes in the same scatternet are within direct radio range with theMIP of the scatternet. We think this assumption is reasonable in a scenario like a museumwhere the application should offer context-aware information to those visitor that are located

Figure 6. Sequence diagram for the bridge operation.


in the vicinity of each art object. Moreover, in Section 4 we observe that Bluetooth offers aquite steady throughput behavior for distances up to 10 m.

Bridges devices are identified using the 48-bit Bluetooth device address. Also, they registera 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 robinintra-piconet scheduling through the POLL data packet. When any of the slaves does notacknowledge the POLL packet the master assumes that the node left and it will accommodatenew vacant in its piconet for new devices. The slaves devices can also detect that the masterhas gone if they do not receive POLL data packet from the master for a given timeout. In thosecases 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 Bluetoothdevices 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 withoutusing the hold mode.

4. Performance Evaluation of UbiqMuseum

We evaluated our application using a small testbed to confirm its correct behavior. We alsoacquired experimental data to investigate how well Bluetooth supports our context-awareapplication.

Our experiments focused on evaluating throughput performance and inquiry delay of theBluetooth channel. We used the results obtained to tune the time a bridge device should spendin hold mode. We performed a sensitivity analysis to evaluate how spatial distance affectsthroughput and inquiry delay.

The museum data server and the MIP run on an Intel Pentium IV 2400 Mhz standard PCbased on Suse Linux 8.2 with a 3Com CREB96 Bluetooth USB Dongle card. The museuminformation mobile client runs on an Intel Pentium IV 2000 Mhz TOSHIBA Satellite 1900-303laptop based on Suse Linux 8.1 with a 3Com CREB96 Bluetooth USB Dongle card.

4.1. THROUGHPUT EVAL UAT ION

We first evaluate the impact on throughput with varying ACL packet types and the devicesdistances. An Asynchronous Connection-Less (ACL) link is parameterized by packet size anddata encoding. Each ACL link allows the use of 1, 3, and 5 data slots, where a slot is 625 μslong. Additionally, it allows the optional use of Forward Error Correction (FEC). Accordingto these parameters, at the baseband layer, Bluetooth offers 6 different data packets that can beclassified in two main groups. Data Medium Rate packets, (DM packets) provide a 2/3 FECHamming 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 parametersit 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 clientduring 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 andDM packets respectively.


0

25

50

75

100

0 m 2 m 4 m 6 m 8 m 10 m 12 m 14 m 16 m

Distance (m)

Thro

ughput

(Kbyte

s/s

)

Data High Rate (DH5)



0

25

50

75

100

0 m 2 m 4 m 6 m 8 m 10 m 12 m 14 m 16 m

Distance (m)

Thro

ughput

(Kbyte

s/s

)

Data Medium Rate (DM5)



Figure 7. Comparison of application throughput of an ACL link under different DHx and DMx packets withrespect to distance.

Firstly, we observe that Bluetooth offers a relatively stable throughput up to 10 m, indepen-dent of the data packet type chosen. Beyond 10 m, the application still works without a sharpperformance degradation. When we select the more efficient DH data packets, throughputincreases when compared to using DM packets. At 10 m the DH packets outperform the DMones by 57%, 46% and 32% respectively for 1, 3, and 5 slots packets. The results confirm thatalthough using DM packets increases efficiency but lowers probability of successful trans-mission, DH packets can be chosen for more efficient transmissions. Moreover, after 10 m, asdistance increases, longer packets (DH5 and DH3) suffer a higher degradation.

Finally, we observed that all obtained results are below the maximum throughput statedin 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) packetsrespectively. When using the more conservative DM (5, 3, 1) packets, this percentage gets to85%, 87%, and 93%. The reason for these differences might stand in the environment wherethe experiments were conducted. Our laboratory has a IEEE 802.11 based access point thatmight interfere with Bluetooth devices. In fact, these results confirm that ideal conditions can-not always be achieved and hence application must be designed to take Bluetooth bandwidthlimitations and fluctuation into consideration.

4.2. INQUIRY DE L A Y EVAL UAT I ON

We now measure the duration of the inquiry procedure. We evaluated two different cases: withthe 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. Theresults shows an average inquiry delay of 2.31 s ± 0.36 and a standard deviation equal to1.81 ± 0.25 with a confidence interval of 95%. As we increase the distance among nodes to10 m, we obtain an average inquiry delay of 2.36 s and a standard deviation of 2.0 with thesame confidence interval. Therefore, it is observed that the inquiry procedure delay does notincrease significantly with distance. In [32] the authors reports similar results.

Figure 9 shows the histogram distribution of the inquiry delay and the cumulative resultsas a function of time for the 100 tests. The results show that at an average of 2.45 s, users


0,000

2,000

4,000

6,000

8,000

10,000

0 10 20 30 40 50 60 70 80 90

# Test number

Tim

e(s

ec)

Inquiry delay (Avg: 2,313, Std: 1,8122)

0,000

2,000

4,000

6,000

8,000

10,000

0 10 20 30 40 50 60 70 80 90

# Test number

Tim

e(s

ec)

Inquiry delay (Avg: 2,364, Std: 2,033)

Figure 8. The inquiry delay value for 100 tests. Distance between the MIP and the mobile client is 1 m and 10 m.

0

2

4

6

8

10

0 1000 2000 3000 4000 5000 6000 7000 8000 9000

Time (ms)

His

togra

mfr

equency

(#T

ests

)

0%

20%

40%

60%

80%

100%

Cum

ula

tive

Histograma Inquiry delay

Cumulative inquiry time

Figure 9. The cumulative inquiry delay distribution for 100 tests. Distance between the MIP and the mobile clientis 1 m.

can discover desired information almost 50% of the time. This waiting time of 2.45 s isnormally acceptable to a user without causes annoyance. Most importantly, we observe thatthis percentage increases to 95% only after 5.26 s. Therefore, we can approximately assume5 s as the highest waiting time for the inquiry process.

Finally, all the experiments done in the laboratory, reported that the maximum time a bridgenode will spend in hold mode should not be anyway greater than 15s, including, in the worstcase, the maximum inquiry delay needed to switch among piconets and the time to get theinformation from the server.

5. Conclusions

In this paper, we demonstrate that Bluetooth might be a candidate wireless networking tech-nology to support ubiquitous context-aware applications. Application programming interfacessuch as BlueZ and JSR-82, although under development, can be used to build mobile clientand server code.

We presented UbiqMuseum which is an experimental Bluetooth-based context-aware ap-plication developed in Java. UbiqMuseum combines the convenience and productivity of Javawith the universal connectivity of Bluetooth wireless technology. The system was designed to


give visitors precise information about what they are viewing at their level of knowledge andin their natural language of preference. Also, it gives the user a GUI which can be adaptedto their devices, hence enhancing their experiences. We developed a multi-process based Mu-seum Data Server. We wrote clients and server code, providing routines to handle clientsinfo request, profile logging and content filtering, formatting and delivery. We constructed theUbiqMuseum 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 ona fixed Ethernet LAN and a wireless IEEE 802.11b LAN. The edge network integrates one ormore close-by mobile users’ devices. From the UbiqMuseum user’s viewpoint, informationpoints associated to any object are detected without user’s intervention, and users can obtainnew information about what they are viewing. We have demonstrated the practicality of build-ing a context-aware system that integrates a combination of Bluetooth, WLAN and EthernetLAN technologies. We have also supplied UbiqMuseum with scatternet support and revealedsome important issues associated with Bluetooth scatternet formation, implementation detailsand performance degradation.

Performance evaluation of UbiqMuseum was made with focus on throughput and inquirydelay. We evaluated the impact on throughput with varying packet size, FEC coding types anddevice separation distance.

We observed that Bluetooth offered a relatively steady throughput up to 10 m, independentof the data packet type selected. The results had also confirmed that although the use of DMpackets improved efficiency while reducing the probability of successful transmission, DHpackets can be good candidates for more efficient transmissions. Our experiments had alsoshowed that the delay incurred during inquiry did not increase significantly with distance.

Key issues related to future advanced mobile context-aware systems include the designneeded to obtain high throughput and fast service discovery, while offering the user with a fastinformation download and a fast and easy entry of users profiles. Our prototype software ofUbiqMusem 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/245and by the Ministerio de Educacion 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.


7. Ambient agoras, “Dynamic Information Controls in a Hybrid World”, (The Integrated Publication and Infor-mation Systems Institute (IPSI). Web page: http://www.ambient-agoras.org/.

8. Smart-its, “Interconnected Embedded Technology for Smart Artefacts with Collective Awareness”, LancasterUniversity, 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-AwareTour 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”, TechnicalReport Computing Department, Lancaster University, 1998.

11. R. Want, A. Hopper, V. Falcao, and J. Gibbons, “The Active Badge Location System”, ACM Transactions onInformation Systems, Vol. 10, No. 1, 1992.

12. S. Long, R. Kooper, G.D. Abowd, and C.G. Atkeson, “Rapid Prototyping of Mobile Context-Aware Applica-tions: The Cyberguide Case Study”, In Proceedings of the 2nd Annual International Conference on MobileComputing and Networking, November 1996.

13. A. Asthana, M. Cravatts, and P. Krzyzanouski, “An Indoor Wireless System for Personalized Shopping Assis-tance”, 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 PhysicalLocation 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 forCapturing Museum Visits”, Proceedings of the Ubiquitous Computing International Conference, Ubicomp2002.

16. M. Spasojevic, Mirjana, and T. Kindberg, “A Study of an Augmented Museum Experience”, Technical ReportHP Laboratories, Web page: http://www.cooltown.hp.com/.

17. R. Semper and M. Spasojevic, “The Electronic Guidebook: Using Portable Devices and a Wireless Web-basedNetwork 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, Number5, 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. Ferrandez, 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, USA2001.

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”, Proceedingsof 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 Engi-neering 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 WirelessSensor Network and Applications. 2002.


Juan-Carlos Cano is an assistant professor in the Department of Computer Engineering atthe Polytechnic University of Valencia (UPV) in Spain. He earned an M.Sc. and a Ph.D. incomputer science from the UPV in 1994 and 2002 respectively. Between 1995–1997 he workedas a programming analyst at IBM’s manufacturing division in Valencia. His current researchinterests include power aware routing protocols for mobile ad hoc networks and pervasivecomputing. You can contact him at [email protected].

Pietro Manzoni received the MS degree in computer science from the “Universita degliStudi” of Milan, Italy, in 1989, and the Ph.D. degree in computer science from the PolytechnicUniversity of Milan, Italy, in 1995. He is an associate professor of computer science at thePolytechnic University of Valencia, Spain. His research activity is related to wireless networksprotocol 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 Uni-versity of London, UK. He is also the Director of the UK Ad Hoc Wireless Consortium andDirector of the Queen Mary/Fudan Joint Research Lab in Mobile Networking and UbiquitousComputing. Concurrently, he is also an Honorary Professor with the University of Hong Kong


and an Adjunct Professor at Fudan University, Shanghai. Previously, he was the Director ofResearch with TRW Tactical Systems in California, USA (now Northrop Grumman Corpora-tion) 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 andUniversity of California, Irvine. CK is the recipient of the 2005 IEEE Kiyo Tomiyasu Techni-cal Medal Award, for “pioneering contributions to communication protocols in ad hoc mobilewireless 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-foundingACM MobiHoc Conference. He is a co-recipient of the Korean Science & Engineering Foun-dation Best Journal paper Award for his work on ad hoc TCP. CK was formerly the Chairmanof IEEE Communications Society Technical Committee on Computer Communications andChairman of IEEE Subcommittee on Ad Hoc Mobile Wireless Networks. He was an IEEE Ex-pert/Distinguished Lecturer and had served as a Steering Committee Member for IEEE WCNCConference and IEEE Transaction on Mobile Computing. He was a member of IEEE Commu-nications Society Meetings & Conferences Board. CK was an editor for IEEE Networks, IEEEJSAC, 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. Hereceived his Ph.D. degree in Computer Science from Cambridge University, England, and hisexecutive education from Harvard.