Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Project Base

Project Base

Ratings: (0)|Views: 60|Likes:
Published by api-3725187

More info:

Published by: api-3725187 on Oct 15, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Using Visual Tags to Bypass Bluetooth Device Discovery
David Scott
Richard Sharp
Anil Madhavapeddy
Eben Upton
djs55@cl.cam.ac.uk richard.sharp@intel.com
Computer Laboratory, University of Cambridge. 15, JJ Thomson Avenue, Cambridge, CB3 0FD, UK
Intel Research Cambridge. 15, JJ Thomson Avenue, Cambridge, CB3 0FD, UK

One factor that has limited the use of Bluetooth as a networking technology for publicly accessible mobile services is the way in which it handles Device Discovery. Establishing a Bluetooth connection between two devices that have not seen each other before is slow and, from a usability perspective, often awkward. In this paper we present the implemen- tation of an end-to-end Bluetooth-based mobile service framework designed speci\ufb01cally to address this issue. Rather than using the standard Bluetooth Device Discovery model to detect nearby mobile services, our system relies on machine-readable visual tags for out- of-band device and service selection. Our work is motivated by the recent proliferation of cameraphones and PDAs with built-in cameras. We have implemented the described frame- work completely for Nokia Series 60 cameraphones and demonstrated that our tag-based connection-establishment technique (i) offersorder of magnitude time improvements over the standard Bluetooth Device Discovery model; and (ii) is signi\ufb01cantly easier to use in a variety of realistic scenarios. Our implementation is available for free download.

I. Introduction

Bluetooth is increasingly becoming integrated into a variety of mobile devices, making its way into cell phones, laptop computers and PDAs. The rapid adop- tion of Bluetooth has led many to suggest that it will act as a key enabling technology, driving the deploy- ment of mobile services. Although today Bluetooth is typically used in a limited fashion (e.g. to transfer \ufb01les between a user\u2019s laptop and their PDA, or to con- nect their wireless headset to their mobile phone), it has the potential to do much more. For example, pub- licly accessible Bluetooth-enabled devices in shops could enable consumers to query whether a product is currently in stock using their mobile phone and Bluetooth-based active posters could distribute mobile content (e.g. 1-minute music samples of a band\u2019s lat- est album) to users\u2019 PDAs.

One factor that has limited the use of Bluetooth as an underlying networking technology for publicly accessible mobile services is that itsdevice discov-

erymodel is inappropriate for this kind of interaction

(see Section III). In this paper we describe the imple- mentation of an end-to-end Bluetooth mobile service framework designed speci\ufb01cally to address this issue. Our implementation has a number of novel features:

1. Visual tags are used for out-of-band device se- lection, bypassing the standard Bluetooth device discovery model.

2. The same visual tags are also used for service
selection, enabling users to choose between the
multiple services or content downloads offered
by a single Bluetooth device.

3. Unlike many research prototypes our system is built entirely on commodity hardware, demon- strating that our technique is immediately appli- cable to a variety of existing devices.

We demonstrate that our system for out-of-band Blue-
tooth connection establishment is (i) anorder of mag-
nitudefaster than the conventional Bluetooth Device
Discovery model; and (ii) that, in a variety of realistic
usage scenarios, it is signi\ufb01cantly easier to use.

Our work is motivated primarily by the recent pro- liferation of cameraphones. The Nokia 3660 cam- eraphone, for example, is a fully programmable de- vice (running a general purpose OS) that incorpo- rates a camera and has Bluetooth capability. Tens of millions of Bluetooth-enabled cameraphones have al- ready been shipped globally, with market trends show- ing that the rapid adoption of such devices is set to continue for the foreseeable future [8]. By running our software on their cameraphone, a user can simply \u201cpoint and click\u201d at a tag representing a Bluetooth ser- vice. The connection is set up immediately, eliminat- ing the need for device discovery entirely. Our imple- mentation is freely downloadable over the web [14] allowing users to try it for themselves on their ex- isting cameraphones. Note that, although this paper

Mobile Computing and Communications Review, Volume 9, Number 1

speci\ufb01cally describes our cameraphone-based imple- mentation, the work is also applicable to the increas- ing number of PDAs with Bluetooth capability and

built-incameras (e.g. Sony Clie, Palm Zire).

The remainder of this paper is structured as fol- lows. Section II gives a brief outline of the parts of the Bluetooth speci\ufb01cation that are relevant to this paper:

device discoveryis considered in Section II.A; ser-
vice discoveryis described in Section II.B. Section III

considers using Bluetooth to connect two devices that have not seen each other before and argues that, in scenarios such as this, the current-generation Blue- tooth device discovery model suffers from a number of usability problems. We describe the implementa- tion of our visual-tag based Bluetooth mobile service framework in Section IV. Realistic usage scenarios, in which our device discovery technique offers sig- ni\ufb01cant advantages over the conventional Bluetooth Device Discovery model, are presented in Section V. A performance evaluation of our system running on Nokia 36x0 cameraphones is presented in Section VI. Security issues surrounding the use of visual tags to encode device names are considered in Section VII. Related work is described in Section VIII. We con- clude and give directions for future work in Sec- tion IX.

II. A Bluetooth Primer

Bluetooth is an open standard for low-power, short- range networking that is based on a frequency- hopping spread-spectrum scheme in the 2.4 GHz band [1]. This section serves to brie\ufb02y outline the parts of the Bluetooth speci\ufb01cation that are relevant to the rest of this paper. Readers already familiar with the technical details of Bluetooth may wish to skip straight to Section III.

II.A. Inquiry and Device Discovery

The Bluetooth Baseband Speci\ufb01cation [1] describes point-to-point connection establishment as a two step procedure. Firstly,Inquiry is performed to discover other Bluetooth devices in the neighborhood. During this phase, the inquiring device learns its neighbors\u2019

Bluetooth Device Addresses(BDADDRs) and fre-
quency synchronization information. Secondly,Pag-
ingis performed to establish an actual connection with
(some of) the discovered device(s).

Inquiry is an asymmetric process: a device wish- ing to perform inquiry enters theInquiry state; devices waiting to be discovered must be in theInquiry Scan state. The inquiring device repeatedly sends packets

over a pre-de\ufb01nedInquiry [frequency] Hopping Se-
quencein an attempt to locate other Bluetooth de-

vices nearby. Devices in the Inquiry Scan state that hear these inquiry packets respond with a packet con- taining, amongst other information, their BDADDR. Whilst the precise technical details of Inquiry are be- yond the scope of this paper, the Bluetooth speci\ufb01ca- tion requires the Inquiry Hopping Sequence to be tra- versed multiple times to ensure all inquiry responses have been collated. In an error-free environment, the inquiry phase must last for 10.24s if it is to discover all devices [1, 19]. In a noisy or error-prone environ- ment, inquiry can last much longer than this (see Sec- tion VI).

BluetoothDevice Discovery starts by performing Inquiry and then contacts discovered devices to re- trieve theirDevice Names. After an inquiry phase, paging is performed to establish a connection with each of the discovered devices;Name Discovery itself then consists of a simple request/response protocol. All this adds to the latency a user experiences when they select \u201cdiscover Bluetooth devices\u201d on their PDA or phone.

II.B. ServiceDiscovery

The Service Discovery Protocol (SDP) provides a mechanism for applications to discover which Blue- tooth services are provided by a remote device and to determine the attributes of those services. The at- tributes of a service include the type or class of ser- vice offered and the mechanism or protocol informa- tion needed to access the service. To perform service discovery, a device establishes an L2CAP connection1 and uses this to talk to a remote device\u2019s SDP server.

A client will typically perform a two-stage pro-
cess to obtain service information. Firstly, aSer-
vice Search Requestis issued by the client, specifying

which classes of service it is interested in (e.g. generic printing services). The client sends the Service Search Request to the SDP server, which responds by return- ing a list ofservice handles that identify the services available on the remote device that match the client\u2019s service search request. Secondly, the client may per- form aService Attribute Transaction to \ufb01nd out more about one of the available services. During this pro- cess, the client sends aService Attribute Request con- taining a service handle and a list of theservice at-

tributesrequested. The SDP server responds with the
values of those attributes.
1L2CAP is Bluetooth\u2019s datagram-based Logical Link Control
and Adaption Protocol.
Mobile Computing and Communications Review, Volume 9, Number 1
An example of a service attribute is theProtocol
Descriptor Listwhich identi\ufb01es the communications

protocols over which the service is running and pro- vides protocol-speci\ufb01c parameters. A client uses this information to connect to a service.

III. Usability Issues Regarding De-
vice/Service Discovery

Having brie\ufb02y introduced Bluetooth, we now con- tinue by considering usability issues arising from its device discovery model. Consider the following com- mon scenario: Alice wants to share a picture by trans- ferring a JPEG \ufb01le from her cameraphone to Bob\u2019s cameraphone; Alice and Bob\u2019s cameraphones have not seen each other before. In order to affect this trans- fer Alice must perform the following actions:

Select photo:Use the menu system on her phone to
select the picture to transfer via Bluetooth.
Device Discovery:Wait whilst a list of Bluetooth de-
vice names appears on the phone\u2019s display.
Device Selection:Select the device name corre-
sponding to Bob\u2019s cameraphone.

From a usability perspective, this scenario high- lights three signi\ufb01cant issues. Firstly, the device dis- covery phase takes a signi\ufb01cant amount of time. In a realistic environment it is not uncommon for device inquiry and name discovery to take in excess of 30 seconds (see Section VI). This delay is by far the dominant time-cost for the whole transaction, dwarf- ing the time taking to transfer the small JPEG \ufb01le.

Secondly, device selection requires Alice to know the device name of Bob\u2019s phone. If Bob has not thought carefully about giving his device a distin- guishable name (or, more likely, has left the manufac- turer\u2019s default device name unchanged), Alice is likely to see strings such as \u201cMy Phone\u201d or \u201cNokia 3660\u201d. In an environment with many Bluetooth-enabled de- vices it may be unclear which name corresponds to Bob\u2019s phone.

Thirdly, the list of device names Alice has to choose from may be long. Even if Alice knows the name of Bob\u2019s phone it may take considerable time to scroll through their device name list and select it. Even today, in crowded places such as train stations, it is common for device discovery to \ufb01nd as many as 10- 15 neighboring Bluetooth devices. As Bluetooth be- comes more widely deployed, this problem will be ex- acerbated.

III.A. ContextAwareness

The usability issues described above all indicate a lack of context-awareness in the standard Bluetooth device discovery model. There are a number of common scenarios wherea user knows exactly which physical Bluetooth device they want to connect to. However, they have no way to communicate this contextual in- formation to the devices themselves.

In the scenario above, for example, Alice is able to point to Bob\u2019s cameraphone but has no way of telling their own phone that \u201cthis is the physical device I would like to connect to\u201d. Instead, the connection has to be established by means of the Bluetooth Device Name associated with Bob\u2019s phone: a somewhat ar- bitrary string of characters which the users may not know (despite being able to identify the physical de- vice itself).

III.B. Tag-Based Device Discovery

In contrast, by using visual tags to identify devices and services, Alice can simply point their cameraphone at Bob\u2019s phone and click in order to establish a connec- tion with it. In our framework Bob\u2019s cameraphone has a tag attached to it: either physically printed on the device itself, or displayed on the device\u2019s screen (perhaps as the default wallpaper). Then, to transfer the photo, Alice performs the following sequence of actions:

Select photo:As before, Alice uses the menu system
on their phone to select the picture to transfer via
Select Physical Device:After selecting a picture to

transfer, Alice aims their cameraphone at the tag on Bob\u2019s cameraphone and presses the select but- ton on their phone\u2019s keypad.

The tag is decoded yielding the Device Address of Bob\u2019s cameraphone. A Bluetooth connection is ini- tiated immediately and the selected picture is trans- ferred. By encoding Device Addresses in visual tags, we provide two signi\ufb01cant bene\ufb01ts to the user:

1. The time taken to establish the connection and initiate the picture transfer is an order of mag- nitude faster than performing Device Discovery (see Section VI).

2. The Bluetooth Device Name is abstracted from
the user.

In many ways the use of visual tags in our system is analogous to the use of hyperlinks in hypertext doc- uments. Just as hyperlinks hide URLs from readers,

Mobile Computing and Communications Review, Volume 9, Number 1

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->