BeremoTe bluetooth project

Our primary goal was to study Bluetooth and todevelop a small application showing the advantages and disadvantages of BlueTooth in a location and context-based environment like this.. On

BeremoTe – A Bluetooth Project Steffen Larsen (zool@diku.dk) Jesper Hansson (hansson@diku.dk)

15th December 2004

An electronic museum guide

AbstractThis project concerns building an electronic museums guide, having BlueTooth

as the primary network source Our primary goal was to study Bluetooth and todevelop a small application showing the advantages and disadvantages of BlueTooth

in a location and context-based environment like this Another other goal was toresearch and test the different stacks implementations and supported Bluetoothhardware, which we had available As a result we developed the museum applicationusing BlueZ for Linux, as the server part and using a Nokia 3650 Series 60 cell phonewith Symbian OS for the client side

Our application seems to fit our needs for location based services pretty well,and even increases the context awareness as well But we also uncovered somedisadvantages, as the re-connect time seems high and through-put at the other end,not very high

This report is written by Jesper Hansson and Steffen Larsen as a graduate project

at DIKU, fall 2004 Supervisor for the project is Associate Professor Klaus Hansen.The name of the project is “BeremoTe” and is as the name refers to: A projectconcerning Bluetooth and being remote

The source code for the project can be found on the included CD-ROM Thisreport itself can also be found on the CDROM in different formats

Our CDROM contains:

source Contains the source code for the server and client

report Contains this report in different formats

report/litterature Contains the external litterature we had available cally Like small reports, larger references etc

electroni-test Contains images, screendumps and videos etc from our electroni-test scenario

1.1 Motivation 1

1.2 The Structure of the Report 2

1.3 Prerequisites of the Reader 2

1.4 Goals 2

2 The Application Idea 3 2.1 Presentation of the Application 3

2.2 Outlines of the Application 4

2.2.1 Advantages of the Application 4

2.2.2 The Application scenario 5

2.2.3 System Description 6

2.3 Limitations 7

2.4 Why use Bluetooth? 7

3 The Bluetooth Architecture 9 3.1 Bluetooth Introduction 9

3.2 Bluetooth network topology 10

3.3 Bluetooth Protocols 11

3.3.1 Bluetooth Radio (RF) 12

3.3.2 The Baseband 13

3.3.3 The Link Manager Protocol (LMP) 14

3.3.4 HCI interface 15

3.3.5 Logical Link Control and Adaption Protocol (L2CAP) 15

3.3.6 RFCOMM 16

3.3.7 Service Discovery Protocol (SDP) 16

3.3.8 OBEX - FTP - PAN 19

3.3.9 Audio 19

3.4 Throughput 20

3.5 Bluetooth profiles 21

3.6 Low power operation 21

3.7 Security 22

3.7.1 Frequency hopping 23

3.7.2 Authentication 23

3.7.3 Authorization 23

3.7.4 Encryption 23

3.7.5 Pairing 23

3.7.6 The device database 24

3.7.7 Device address filtering 24

4 Platform – System Engineering 25

4.1 BlueTooth Server 25

4.1.1 Bluetooth stack implementations 25

4.1.2 Stacks on Linux 26

4.1.3 Stacks on FreeBSD 28

4.1.4 Stacks on Windows 28

4.2 BlueTooth Client 28

4.2.1 Symbian OS 29

4.2.2 Java 29

4.2.3 Sony Ericsson T610 30

4.2.4 Nokia 3650 30

4.2.5 Compaq iPAQ h3670 running Familiar Linux 31

4.2.6 HP iPAQ h1940 running MS Windows Pocket PC 2003 Pro-fessional 31

4.3 Choosing platform 31

4.3.1 Bluetooth Server 31

4.3.2 Client 32

5 System Design 33 5.1 Connections 33

5.2 Positioning 34

5.3 Network Topology 35

5.3.1 Server/Exhibition Item setup 35

5.3.2 Choice of Power Class 37

5.3.3 Piconet - Scatternet 37

5.3.4 Bluetooth server device bundling 37

5.4 SDP 37

5.4.1 The museum service record 38

5.4.2 Handling of several clients 38

5.5 Security level 39

5.6 The actual connection 40

5.6.1 Simple text 40

5.6.2 Data as files 41

5.6.3 Audio 41

5.6.4 Video 42

5.6.5 Miniprotocol over L2CAP 42

5.6.6 Establishing the connection 42

5.6.7 Data transfer 42

6 Program Description 44

6.1 The BlueTooth server 44

6.1.1 Bluetooth applications development on BlueZ 44

6.1.2 Server Design 45

6.1.3 Implementation description 45

6.1.4 Problems arose during implementation 50

6.1.5 Server user guide 50

6.2 The Bluetooth client 51

6.2.1 Symbian Programming 51

6.2.2 Bluetooth applications development on the Nokia 3650 53

6.2.3 Client Design 54

6.2.4 Implementation description 56

6.2.5 Problems arose during implementation 58

6.2.6 Users guide - Testing BeremoTe on the mobile 59

7 System assessments and test 61 7.1 Testing the client (Nokia 3650) 61

7.1.1 Testing a connection 62

7.1.2 Testing disconnect and reconnect 62

7.1.3 Conclusion about the client test 63

7.2 Testing the server (Linux PC with BlueZ) 64

7.2.1 Testing the HCI layer 64

7.2.2 Testing our advertising 64

7.2.3 Authentication 64

7.2.4 Connection test 65

7.2.5 Conclusion on the server test 67

7.3 Other tests 67

8 Conclusion 68 9 Future Work 69 9.1 Server 69

9.2 Client 70

A Setting up the environments 75 A.1 Installation of bluetooth on Windows XP 75

A.2 Installation of BlueZ with Familiar Linux on an iPAQ 75

A.3 Getting started with programming the Nokia 3650 with Symbian OS 76 A.4 Getting started with Bluez on Linux 78

A.4.1 Upgrading the kernel 79

A.4.2 Upgrade the distribution to unstable 79

A.4.3 Loading the drivers and starting the BT stack 80

A.5 Setting up BT on FreeBSD 80A.5.1 Installing 80

B.1 Server output in syslog 81B.2 SDPd output 81B.3 pstree -H beremote output 82

1 Introduction

This report is written in English to reach a broader audience and because it couldinterest a lot of developers who wish to start out developing new Bluetooth applica-tions based on the BlueZ stack or Symbian 60 Operating system for cell phones Theappendices A.3 and A.4 could be especially interesting for new developers showinghow to install and how to build on a Bluetooth environment

Our motivation arose back in 2003, when we took part in a robot competitioncalled Robocup (http://www.robocup.dtu.dk/) We build a rather embedded andcomplicated robot which we had trouble debugging[8] Our main computer was

a Compaq iPAQ, which could only be accessed by a USB port and a BlueToothnetwork Since our focus at the time was on the robot competition, we did not haveany time to implement and use the Bluetooth stack on the iPAQ, and therefore

we used the more primitive USB port to get our debug from the robot As thecompetition began to take place, we realized that our debug method was quite ahazle Every time our robot had completed a lap, we had to "catch" it and place

it in front of our laptop and connect it to the USB and "download" the debuginformation we had recorded during a lap This really motivated us to take a closerlook at bluetooth and its capabilities, so that we could improve the annoying factor

of catching the robot and use a "real" network instead Thereby we could alsomake a real-time debugging a possibility All this fuss about the robot increasedour interest and attention towards BlueTooth It gave us a lot of other great ideaslike: remote controlling the robot, streaming the images from the robot etc Wehad to investigate what kind of possibilities BlueTooth offered

During our early research (early 2004) we investigated different types of Tooth devices and what can and what can not be done with these devices One ofthe great advantages in BlueTooth lies in the huge support in all kind of devices It

Blue-is supported in USB dongles to ordinary PCs, PDAs like the iPAQ, cellphones andother embedded devices

During our research Steffen was on a small summer vacation to Spain (moreprecisely Malaga) and visited the Pablo Picasso1 Museum.

While Steffen wandered about in the museum it began to irritate him, that alot of the explaining text to the specific art was in Spanish and not in English.With this in mind and the ongoing BlueTooth research, he came up with an idea.Why not use our BlueTooth knowledge to develop some kind of software to getthe text in a Localized language (in Steffen’s case: English or Danish) and get itpresented to him in a nice and easy way We talked about the idea for some time

1The famous painter from Spain, who painted abstract and surrealistic art Lived from 1881 to 1973.

and thought it would be a nice application to have and a really great scenario toshow the possibilities and limitations of Bluetooth in general.

1.2 The Structure of the Report

We have structured this report, so that in the next chapter (chapter two) we willintroduce the idea behind the application In chapter three we will try to explainthe theory and go through the architecture behind Bluetooth and what kind of pos-sibilities it has The focus will be put on the parts of the Bluetooth stack, whichare relevant for developing the chosen application The more hardware specific de-tails and the lowest levels of the protocol will be only shortly introduced We havededicated chapter four for concerns about choosing the platform and the BlueToothstack We have done this because, we had not yet decided which platform to im-plement the software on, when we started the project In the few last chapters

we will present a system design, discuss problems concerning the design, make aprogram description and test the developed application We will end up this report

by evaluating and come up with a conclusion, which wraps up the hole project

1.3 Prerequisites of the Reader

The reader should have some basic knowledge about: networking, operating systems,programming and embedded systems The reader does not have to know anythingabout bluetooth in advance although it would be a small advantage Our audience

is targeted towards our fellow students taking Computer Science courses or otherdevelopers just interested in Bluetooth

Our concise goals about this project can be summoned up as follows:

1 To learn something about Bluetooth Its advantages and limitations

2 To test different Bluetooth devices and stacks

3 To implement a small application which show these advantages/limitations

2 The Application Idea

In this section we will outline the ideas behind our museum application This is only

a presentation of the ideas, as it is beyond the scope of this report to implement itall2 In the limitations section 2.3 we will specify, what we will and will not dig into

in the rest of the report, and what we will and will not try to implement

2.1 Presentation of the Application

Our idea about the museum and localized languages of course evolved into a greateraspect We developed our idea further and decided to make an electronic and remotemuseum guide, which could provide information to a visitor at a museum, throughhis or hers handheld device In this way we would be able to stream out context andlocation-based information to the visitor To begin with the museum applicationshould of course be thought of as a service to a hypothetical museum that providesthe means of a client/server solution with the Bluetooth as a network connectingthem

The guest should plot in his age, language, different kind of art taste, knowledgelevel and other personalized information into his or hers handheld device (the client).This would allow the museum server to refine the information presented and targeted

to the user as detailed as possible The visitor will then get the information aboutthe art artifact in his language, at his level of knowledge and in his taste Thehandheld device would receive the stream from the server and explain by a textmessage (or audio) what kind of exhibit he or she is standing in front of in the givenmuseum It would also show images of other art artifacts related to the room orexhibit where the guest is located By handheld device we mean a cell phone, PDA

or any other small personal computer All this dynamic information has enormouspotential and could easily be extended to a lot more features such as: the visitorcould get an appointment about the start of special events at his handheld, bargainsouvenirs, announcements (the museum is closing etc.) or paging a human guideetc Guided services could also be offered, so that the handheld could show a specificway around in the museum

All this user involvement which takes the user based information into account,i.e the context, will improve the visitors experience in the museum and the location-based service will only strengthen the context-awareness As we can see it, an enddeveloped and complete context-aware system like the, will have endless possibilities

to be implanted in real Museums and have many future extensions One couldimagine a nice scenario at a real museum like "Arken" or even better "The DanishMuseum of Art" (Statens Museum for Kunst)

Actually we could as well have designed and implemented some other kind of

2We find that these ideas needs to be mentioned to justify the need of the application

KIOSK system3 using Bluetooth as network transport, but we really liked this idea

of the museum and it gave us a good scenario for implementing our pilot-project in

a "real-world" scenario in our context All of these wild ideas of cause spawns ofproblems They will involve a discussion of the many aspects and problems of usingBluetooth as a network

The objective for the project (goal 3) as defined in 1.4) will therefore be todevelop and implement a pilot project of the museum guide, which shows the limi-tations and advantages for a Bluetooth application

2.2 Outlines of the Application

Now we will summon up the advantages of this kind of application, and later thestate more exactly the setup of our system and application

2.2.1 Advantages of the Application

We have written down some advantages about this application They can also

be seen as reasons for this application to be realized We have categorized theadvantages for them into two groups, to show that it is a mutual benefit for thevisitor and the museum

Advantages for the visitors

In many museums cassette players delivers audio content in a linear way You have

to follow a special route to follow the discripton, which makes it very in-flexible Our

solution could provide customization what audio to be played could be chosen bythe visitor The visitor could have his own "electronic attendant"4 with him all the

way The visitor could chose among the data available, and thereby the informationparticularly interesting to him He could choose between different presentations:text, audio, video, pictures etc when he wanted to Langague both in audio andtext settings could be implemented to suit tourists’ needs The visitor could alsochoose to save some of the data presented to him for later use, e.g in a schoolproject or to show to his family - instead of having a lot of brochures with datairrelevant to him

The visitor could get the data presented to him in a personal way, if he entereddata about himself, preferences etc (a visitor profile) A tour could be generated forhim based on this (profile) This is the classic attendant tour, but suit to the singlevisitor’s needs Imagine the possibilities e.g in "kids profiles"

3A KIOSK system – A stall set up in a public place where one can obtain information, e.g tourist

information The information may be provided by a human or by a computer In the latter case, the data may be stored locally (e.g on CD-ROM) or accessed via a network using some kind of distributed information retrieval system.

When the visitor leaves the museum, the museum could advertise for up-comingevent, and even put them into the visitor’s electronic handheld calendar - if thevisitor wants to.

In short customization and personal feel for the visitor.

Advantages for the museum

The museum could get a footprint (trail of path, actions and choices) of wherethe visitors have been and can thereby focus on which exhibits have fallen intothe interest of the visitors and which have not This could be beneficial for themuseum, because they could suit the visitors expections and needs better, whichmight increase the number of visitors Maybe fewer attendants would be needed.This could be inflect on the museum’s economy in a positive way

The museum could deliver special on-demand announcements targeted at specificguests (maybe determined by their registration profile), and when the visitor leavesthe museum could advertise for up coming events to promote their next exhibitions

or events These event could be inserted to the visitor’s personal calender if hewants to

The maintenance could be done directly to the central database for simple agement

man-In short the museum would get information about its customers, and thereby

be able to give a better service

2.2.2 The Application scenario

As said before the application is meant as a kind of electronic guide or attendantfor museums The application is only intended as a supplement and of cause not

as a replacement for the attendant Here is the scenario of a museum visit as weimagine it:

1 The visitor of the museum registers their handheld device, download and installthe museum program (our software)

2 The visitor chooses his own user level and language etc

3 If the visitor wishes to take an in-depth tour on a particular exhibit, they canchoose a different level of details

4 The visitor chooses their own path through the museum and get informationabout the different exhibit items they pass along the way

5 This information could be audio streams, pictures or plain text, which will bedelivered from the server to the the handheld device

This means that the scenario consists of both a client and a server side

2.2.3 System Description

Our virtual museum will consist of a collection of Bluetooth devices each in someway relating to one or more art artifacts or pictures Each of these devices areinterconnected to a bluetooth server which again is connected to a database server(see figure 1) In this way we should be able to fetch data from the database andsend it to the bluetooth server which again streams it to a handheld (the client).The connection between the Bluetooth server and the database server could besome kind of ordinary TCP Local Area Network (LAN) A wireless LAN instead

of standard cables would be preferable though, because our virtual museum couldcover several 1000 of square meters where cables wouldn’t be very comprehensive.The wireless LAN speeds are now so high (54Mbit/s) that we think it could coverthe needs

Figure 1: Our museum scenario and setup

Definitions

To avoid confusion among different concepts we will here give some definitions which

we will use in all our forthcoming chapters The definitions are related to figure 1:Visitor Is a user or a guest at the museum using our system

Bluetooth client A handheld or Bluetooth client device

Bluetooth device Any Bluetooth device

Bluetooth server device Bluetooth device attached to a Bluetooth server

Bluetooth server A server which has a bundle of Bluetooth server devices and isconnected (wireless) to the central database server

Central database server A server which handles database queries between tooth servers and a database

Blue-The word "Bluetooth" will sometimes be omitted for shortness E.g "server device"instead of "Bluetooth server device"

2.3 Limitations

This project should be seen as a pilot project That is, we will not implementthe entire idea as it was just presented We will focus on the parts concerningBluetooth For example considerations regarding GUI (Graphics User Interface),database, profiles of the visitor etc will not be discussed, but some of the centralBluetooth subjects, which we will cover, are: network setup, the Service DiscoveryProtocol, connection handling and data transfer

We will only present the part of the Bluetooth theory (chapter three) that wefind important to this application, though our knowledge go deeper than this afterour reading

Since our funds are limited, we have chosen only to use the Bluetooth devices

we have access to The list of these devices looks like this (a picture of most of thesecan be found on the CD-ROM at /test/pictures/ourdevices.jpg):

• Sony Ericsson T610 (cell phone)

• Nokia 3650 (cell phone)

• Compaq iPAQ 3670 (PDA)

• Compaq iPAQ h1940 (PDA)

• D-Link DBT-120 USB-dongle (for PC)

• CSR BUB-103 USB-dongle (for PC)

We will take a starting point in them, and see if they offer the features which weneed Section four is dedicated to the discussion of what device to chose

The first question that comes into mind is: "Why not use normal Wireless ethernet

or infrared connection?"

The obvious disadvantage with infrared is that it needs a clear line of sight,and that the two peers need to be pointed directly at each other - besides it has ashort range and a low transfer rate (115Kb/s) Of cause this is not acceptable for

a museum visitor The wireless technology is a very appealing technology with itslong range, ability to handle many clients and has a high throughput (54Mb/s IEEE

802.3.11g) Compared to Bluetooth (700Kb/s) it is very high But small embeddeddevices can not handle incoming data so fast anyway5.

The downside compared to Bluetooth is that it is not standard in cell phones(mainly because of its greater power consumption) Bluetooth is still not standard

in cell phones, but it increases its market shares at present time And it is veryprobable that it will become standard within the next few years If a museum has topurchase handheld devices with wireless support for the visitors it would be prettyexpensive (600$ a piece) At present time most people carry a cell phone with themanyway, so why not take advantage of this

The use of laptops could also be a possibility, but their size and weight makes

it unhandy and unsuitable

5It is common that Wireless on PDAs has a throughput of as little as 1Mb/s and less, because the

limitation lies in the internal bus to CF- or SD-slot But some of the newest PDAs with integrated wireless achieve higher throughput rates Cell phones probably have even higher restrictions than PDAs because of their smaller capacity

3 The Bluetooth Architecture

In this section we will go into the theory behind Bluetooth technology and how itworks We will start out with a short introduction of Bluetooth and explain howthe network works Then we will make a comprised walk-through of the differentlayers of the protocol in a bottom-up approach Finally we will take a short look

on the security in Bluetooth

The section about network topology is interesting for us, because it gives ideasand limitations for how to set up the network in our application In the protocolwalk through we will focus on the parts that are central to our application, but wewill also mention some concepts which are needed to get an idea of what Bluetooth

is taken as whole The security section is of cause relevant for the application design,but in Bluetooth the security is so integrated, that it is a must to address it, sinceyou can not program for Bluetooth without knowledge of the security functions

com-Currently we have a lot of personal devices that support the BT technology, suchas: cell phones, headsets, PDAs, USB dongles for PCs, smart tags etc Usually thesedevices are used for synchronization, exchanges of files, calendar objects, visitcards,messages, and gaming All are quite small devices that support the main feature

of Bluetooth, that is: small in size, minimal power consumption and low price

developed for personal Bluetooth usage (people-to-people) Especially cell phones

have deeply integrated Bluetooth Among others because it gives easy access touse wireless uplink (bridge) for laptops and because of the possibility of wirelessconnection to Bluetooth headsets

The development of personal Bluetooth units and smart tags in Denmark hasbeen enormous The Danish company BlueTags[32] released a small smart tagdevice this year that was able to track customers and their whereabouts In AalborgZOO in Denmark, BlueTags has provided the ZOO, one of Denmark’s largestzoological gardens, with a BlueTag tracking system allowing the Zoo’s visitors tokeep constant track of each other and their kids Also in one of Denmark’s (evenEurope’s) most visited amusement parks, Tivoli has signed an agreement to install

these smart tags and base stations As of April this year visiting families will beable to take advantage of the system and keep track of each other So now, all theparents in Tivoli have to do is to rent a tag and attach it to the child’s clothes orplace it on their wrist and thereby they can constantly know about their child’swhereabouts This is done by the parents send out a SMS (Short Message Service)

on their mobile to a specific number, and gets back the child’s position Theposition of the child (and smart tags) are sniffed by installed base stations (accesspoints)

3.2 Bluetooth network topology

The topology of the bluetooth network is a little different from the "normal" ogy of a computer network, because of its ad-hoc nature Thus the "normal" dis-tinction between clients and base stations can not be made This approach is chosenbecause Bluetooth devices are often on the move, and they often only need a small

topol-network In a Bluetooth network a device can take one of two roles: master or slave.

This distinction between a normal network and BlueTooth, requires some otherkind of topology There are three kinds of Bluetooth network topologies (see also

(maxi-a m(maxi-aster or (maxi-a sl(maxi-ave The low number of p(maxi-articip(maxi-ating devices is in order tokeep up the high network capacity (throughput) between the devices

c: Scatternet Is when two or more piconets melt together There will still be onemaster per piconet But one device can be master in one piconet and slave inanother Scatternets have even worse network capacity, because one or moredevices participate in more networks 6

The device that invites other devices to establish a connection becomes themaster of the network In other words, it is only the master that can initiate a con-nection - this is only meant on the physical link level For instance, an "applicationconnection" can be initiated by a slave

6It is common for both current Bluetooth stacks and devices not to support scatternets.

Figure 2: The different kinds of topologies.

The protocol supports that two devices change roles (slave/master) Thiscan become necessary if a device serves as LAN access point and another deviceconnects to it and becomes master If more devices are connected to the accesspoint, a master/slave shift is needed to keep the piconet topology (see fig 2) Theprotocol allows this switch to occur during link setup - and later too

The master controls the baseband synchronization between the devices,but has no special privileges On the other hand all traffic on a piconet goesthrough the master It means heavy workload for the master and a narrowing

of bandwidth, when more devices enters the network Thus communicationbetween two slaves in a piconet goes through the master which broadcasts to allother slaves And a slave can only "say" something when the master tells it to do it

3.3 Bluetooth Protocols

We will now go through the central layers of the Bluetooth stack Since we cannot cover everything, we will try to focus on the parts that are important to thedevelopment of our application

The layers above the Host Controller Interface (HCI) are often referred to asthe "The Bluetooth Module", and the lower layers are often referred to as "TheBluetooth Host" (see figure 3) The Bluetooth Module is the "hardware part" andthe Bluetooth Host is "software part" of the stack The HCI layer is the driverneeded to get the two parts to communicate with each other

Figure 3: The Bluetooth protocol

3.3.1 Bluetooth Radio (RF)

As explained before, Bluetooth is a wireless technology It uses a radio to transmitthe data, which it does on the unlicensed ISM band in the 2.4GHz spectrum This

is mainly because it is free in most countries and because it needs to operate and

be available worldwide Although this spectrum is free, it is polluted with a lot ofnoise and interference e.g as micro waves, other wireless and Bluetooth devices.This however requires the transmission to be very robust (see Frequency Hopping)This actual radio link is physically implemented in the Bluetooth radio layer,which is the lowest layer in the protocol It implements the actual radio circuits,and controls the physical sending and receiving of signals to and from the air

Frequency Hopping To overcome the problem with interference from otherdevices Bluetooth uses Frequency Hopping Strategy The 2.4GHz frequency Band

is divided into 79 channels - In most countries 79 channels can be used In that wayevery package, is sent on a different frequency in a given time slot

During connection the master gives the slave a "code" to synchronize the quency Hopping In this way the two devices know when to send/listen on whatfrequency In this way the BT radio will retransmit packages on a different fre-quency, if a frequency is jammed up The constant change of frequency has the niceside effect that it makes evesdropping very hard

Fre-Bluetooth channels use a FH/TDD (frequency hop/time division duplex)scheme The channel is divided into 625 microsecond interval time slots This

gives a hop rate of 1600 hops/sec A different hop frequency is used for each slotaccording to the frequency hopping sequence of the piconet The sequence is de-termined by piconet masters’ device address and its clock, and is distributed to theclients One packet can be transmitted per slot A slave may transmit to the masteronly if he was addressed in the previous slot.

Power Classes The range of Bluetooth is dependent on the power class of theradio unit 3 Power classes are defined Power class 1 has a range of 10 meters,Power class 2 with a range of 20 meters, and Power class 3 is 100 meters The mostcommon range is 10 meters, since it has the lowest power consumption, and theBluetooth technology is mainly used in small battery run devices

The LMP controls can adjust the transmitting power on the remote device

to save energy inside the defined limits of each power class See 3.3.3 for moreinformation, and [1] for Power Class definitions

The RF is mostly relevant in our project in connection with network setupconsiderations - 5.2 and 5.3 Frequency hopping also impacts security 3.7 and 5.5

This section gives the fundamental understanding of the Bluetooth connectiontypes SCO and ACL The connection is a very central issue in this report, and iscommonly referred to in chapter 3, 5, 6 and 7

We will not discuss the package types in details, only mention that different typesexist They represent different trade-offs between reliability and data bandwidth

Physical links Once a connection has been set between a master and slave,the physical link is established There are now two possibilities to transfer data,through:

• Synchronous Connection Oriented (SCO)

• Asynchronous Connection Less (ACL)

SCO The time bounded connection When a SCO connection is established, timeslots (See 3.3.1) are reserved for the connection This means that a device can besure that it can send to the other device regularly, but no resending can be donebecause the next time slot is reserved for the next packet A device can have up

to three SCO connections open at one time, three if it is to the same device or twodifferent devices The SCO connection is often used for transmitting audio Thethroughput of SCO is matched to suit the throughput of cell phone audio standards(64 kb/s).

It is not possible for a device to have a SCO link in two different in piconets.This is due to problems synchronizing two piconets

ACL The packet based connection There can only be one ACL connection tween a master and a slave, but it is a point-to-multipoint connection That is,more slaves can be connected to one master (piconet - see 3.2) Data is exchanged

be-on a per slot basis

Controller states The Link controller is in one of the following states: Standby,Inquiry, Inquiry Scan, Page, Page Scan, Connection The controller states arecontrollable through the HCI layer - See 3.3.4

Standby the device is inactive and the radio is turned off

Inquiry & Inquiry Scan The inquiry procedure is a process where one Bluetoothdevice tries to find all neighboring enabled Bluetooth devices A device that istrying to scan for other devices is said to be in "Inquiry state" The device thatlistens for an inquiry request is in "Inquiry Scan state" This "Inquiry Scanstate" is usually set in a Bluetooth device by setting it to be "discoverable".This procedure is controlled by the Link Controller

Page & Page Scan These states are used when the low level link is being lished - the low level connection procedure When a device is about to connect

estab-to another device found by the inquiry procedure it enters the Page state Thepaging device will become master of the connection The Inquiry Scan state

is entered to check if any other device wishes to connect

Connection The device is connected A connection can be in one of the followingfour substates: Active, Hold, Sniff or Park These states are essential toBluetooth power saving capabilities See 3.6

3.3.3 The Link Manager Protocol (LMP)

The link manager layer is resident in the hardware part of the bluetooth stacka.k.a The Bluetooth Module Applications communicates to LMP through theHCI interface (See 3.3.4)

The LMP controls the links to other devices It both controls connecting, taching and master/slave switches Besides this, it is responsible for setting up theACL (data) and SCO (voice) connections More connections between two devicescan be handled at one time During establishment of connections the LMP must beaware of the security level For a more elaborate explanation read 3.7

de-In addition to the Bluetooth address each device has a "human-friendly" name,which is a string of up to 247 characters The LMP can also ask a device for thisname.

Moreover changes of radio emission power level is controlled by LMP as well

as QoS (Quality of Service) is To control the power level RSSI (Recieve SignalStrength Indication) is used One device can ask another for a decrease or increase

in the signal strength if the signal is very strong or to weak The device receivingthis, can then decide whether it wants to adhere the request Of cause maximumand minimum power levels are defined, see [1]

Besides determining the throughput on a connection it can increase the overallthroughput, because there might not be room for extra connections and negotiationsfor such will not be necessary

3.3.4 HCI interface

The HCI (Host Controller Interface) is an interface which defines standards for theBluetooth Host to communicate with the Bluetooth module An application canaccess various functions in the Bluetooth module through this interface We willnot go into details with the interface Examples are power control, role switch,connection, security parameters, connection modes etc

The available HCI functions depend on what has been included in the stack API

The Bluetooth transport layer is responsible for transporting packets from theBluetooth module to the Bluetooth Host The HCI transport layer is the driver thatconnects the hardware and the software part of the stack The hardware is usually

a serial device, a PC card, USB dongle or a chip embedded onto the motherboard

3.3.5 Logical Link Control and Adaption Protocol (L2CAP)

L2CAP is layered above the Baseband Protocol and offers both connection-orientedand connection-less data services to the upper layers This is the basic protocol inthe upper part of the protocol stack All asynchronous data communication goesthrough this protocol

Many L2CAP links can be managed through one ACL connection L2CAP

man-ages the links through different PSMs (Protocol & Service Multiplexer ), so L2CAP

serves as a kind of connection manager PSM 0x0001 is reserved for SDP

In BlueZ this means that each L2CAP connection must have its own PSM, ifmore connection inside one process should be handled However, if more processesare spawned, they can all listen on same PSM without conflicting

3.3.6 RFCOMM

RFCOMM (Radio Frequency COMM) a.k.a "Cable Replacement protocol" runs

on top of L2CAP It is often used to emulate a serial port Normal AT modemcommands can be used through RFCOMM, since it emulates the RS232 standardserial port By associating a COM port with the RFCOMM connection, standardserial software as MiniCom and HyperTerminal can be used to read/write text/datathrough the connection

More RFCOMM channels can be open at the same time, they just have to havethe same number of L2CAP PSMs open underneath The maximum number ofconnections is implementation specific

The protocol is a reliable connection oriented streaming protocol It providesflow control but no error correction

When choosing protocol 5.6 and in chapter six and seven we will regularly refer

to L2CAP and RFCOMM

3.3.7 Service Discovery Protocol (SDP)

The purpose of this protocol is, to tell other devices which services the device offersand how to search them An example of usage of the SDP service could be a printer

that advertises it self to the Bluetooth community in a office A Bluetooth device

enters the office and needs a printer Only using SDP it is possible for the device

to see if any printers are in range

A device can have a SDP client though it does not have a SDP server And adevice can be both client and server simultaneously There can be maximum oneSDP server per device Other devices, i.e the clients, can then search and browsethese services

Attributes A service is described through a number of attributes These tributes contain information about what kind of service it is and how the clientshould use it The structure of an attribute contains a ID (16 bits) and a At-tribute value (flexible in length) Here is a list some of the more interesting definedattributes:

at-ServiceRecordHandle A 32 bit number uniquely identifying a service recordwithin a server

ProtocolDescriptorList A list of protocols which are needed to use the advertisedservice

BrowseGroupList A list of public groups which is used when browsingservices3.3.7

ProviderName The advertised provider name for the service

ServiceName The advertised service name for the service.

ServiceDescription An attribute describing the service

BluetoothProfileDescriptorList A list that contains the bluetooth profiles (see3.5) supported by the service

ServiceAvailability An 8 bit number that indicates the relative availability ofservice for the clients connecting

ServiceRecordState A 32 bit number that is changed whenever an attribute inthe service record changes

A complete list can be found in the Bluetooth Specification [17] As Bluetoothevolves and new profiles emerge more attributes will be defined

Service records A service record is a collection of attributes describing the vice Information about a service is exchanged between devices using these records.For example a record should contain information (attributes) about what proto-cols are needed, what profile is used, specific parameters to the protocols etc Allinformation necessary for the client to know should be contained in the record

ser-UUIDs Each service record has a Universally Unique IDentifier (UUID) TheUUID can either be defined in the specification and will thereby be unique or man-

ufacturers can define UUIDs These UUIDs are also garantied (read very very probable that clashes occur ) to be unique7 Since UUIDs are unique, no central

im-database is necessary to control the UUIDs

The SDP connection To establish a SDP connection to the SDP server, aL2CAP connection is required The L2CAP protocol has a dedicated PSM (0x0001)for the SDP service This PSM is only for SDP inquiries, so the actual connection

to a service can not be done using SDP, thus a new connection must be established

to the actual service

When the connection is established the client can make three types of inquiries

to the server:

• Service Search

• Service Attribute

• Service Search Attribute

In return it will get a response or an error response These three types will beelaborated below 8

7The procedure and conventions for producing the UUID is not relevant to us, see [1] p.206 for more

detail.

8For a more elaborate explanation of SDP connection establishment see p 1106 in [17] and/or SDP

connection establishment p 222 in [1]

Searching services A service search is when a device queries for one or moreservices This is used when a device wants to look for a (list of) specific service on

a remote device

Standard procedure: First a "Service Search" is performed When the Handle for a wanted service is obtained (if any) the inquiring for the attributes ofthe service can be done ("Service Attribute")

Service-Alternative procedure: "Service Search Attribute" which is a combination of thefirst two

Browsing services Instead of searching for a service, browsing can be done.Browsing is when a chosen device is explored for what services it advertises

The SDP server has the possibility to organize its services into groups If theserver’s set of services is complex, this makes it more manageable and clear if aclient wants to browse through the server’s services The organization is done in

a tree like structure A PublicBrowseRoot UUID is defined by convention, and isknown by all devices From this root the tree is grown A leave on the tree caneither be a service or a group There can be no subtree from a service, and a groupcan have one or more groups and/or services in its subtree

A client can browse through the server’s services starting from the licBrowseRoot

Pub-The service provider can decide which services will be browseable[1]

Connection establishment We will here introduce the way a connectionshould be established when SDP is used for advertising a service

For advertising a service on a server these steps should be followed:

• (Start the server daemon)

• The server establishes a L2CAP connection to the SDP local server

• Make a SDP record by setting all the selected attributes

• Release and close the connection to the SDP server

• In the application, wait for a client to connect to the advertised service

For connecting to a service from a client these steps should be followed:

• The client establishes a L2CAP connection to the remote SDP server

• Search for a specific class of service or browse through services on the remote

device

• Retrieve the attributes for the chosen service record from the remote SDP

server

• Release and close the connection to the SDP server

• Establish a new and separate connection to the service advertised using the

retrieved attributes

This is of cause the super compact version, but it gives a good overview of theprocedure, and we will later use these procedures on the client and server (see 5.1,5.6 and chapter six)

Stack implementation of SDP It is relatively free how to implement theSDP protocol Based on the chosen stack, it therefore varies a little how theapplication designer should interfere with the SDP protocol For example the

"Service Search Attribute" is not implemented in the Nokia 3650 Symbian API.How to build the Service Record and how to decompose them, also varies a lotfrom implementation to implementation, and so on

This were the basics of the SDP idea, which we will use in our discussion of SDP5.4

3.3.8 OBEX - FTP - PAN

Object Exchange or OBEX as it is called, is a binary protocol that is designed

to allow devices to exchange files and data through a simple interface Originallythe OBEX is a IrDa specification standard (see www.irda.org for details) OBEXincludes, like the IrDa standard, means to represent data in a object model and asession protocol in which a client can send a request to a server and get responses.The most common objects that are sent through OBEX are the Calendar objectsand visit cards (also called vCalendar and vCards) This provides an easy ad-hocway to exchange visit card containing data of the user like: phone number, name,address, birthdays, calendar events etc

OBEX is also used as simple FTP like file transfer utility

Implementation of OBEX can very at little from developer to developer, since

no OBEX profile has been defined (there is only an OPP: Object Push Profile)

It runs on top of an PAN (Private Area Network) protocol (TCP/IP protocol andmore) or in some implementations on top of RFCOMM Since it is a higher levelprotocol it means a relatively big amount of overhead in the packages (See 3.4).OBEX is commonly implemented and of potential use for our project

3.3.9 Audio

It is standard to transmit audio over a SCO connection (see 3.3.2) The commoncodec’s used are either a 64 Kb/s log PCM format (A-law or µ-law) or a 64 Kb/s

CVSD (Continuous Variable Slope Delta Modulation), read more in [1] The quality

of this audio is matched to the quality of mobile phones

When sending audio over a SCO link, the data is sent directly from theBaseband to the Application through the HCI layer The SCO audio connection

is full duplex but the quality is quite low It is however still well suited forsimple speech in headsets and its like Especially when packets are lost (e.g.when approaching maximum range) the quality reduces dramatically, since noretransmission is possible on a SCO link

It is also possible to send audio through an asynchronous data connection (ACL).Recently new profiles have been defined [15] The Generic Audio/Video DistributionProfile (GAVDP) and the Advanced Audio Distribution profile (A2DP) defines newstandards for sending better quality (e.g mp3 quality) stereo sound through an ACLconnection New protocols has evolved too, one of them is Audio/Video DistributionTransport Protocol (AVDTP) As the names imply standards for streaming videohas been set Unfortunately these profiles are only implemented in very few stacks

We also considered audio for the museum application - read more in 5.6

The bandwidth of a Bluetooth connection is hard to predict, because it depends onmany parameters If actual values are wanted tests must be made

The bandwidth of Bluetooth is 1Mb/s, but the maximum theoretical throughput

is (723.2Kb/s / 57.6Kb/s) asynchronously and 433.9 Kb/s synchronously (Actualdata throughput - without headers) This is calculated for an L2CAP connection9,

since it is the lowest layer protocol you can send user data through, and thereforehas the lowest header overhead

These values will very rarely be achieved Though distance between deviceshas low impact on performance [9], packet collisions with packets in nearbyBluetooth networks and disturbance/pollution on the radio spectrum decreasesthe performance Network structures other than peer-to-peer also decrease overallperformance (See 3.2) Error correction, channel congestion, and flow control alsolimit throughput Packet headers from higher layered protocols, will decreaseperformance for them The higher the layer, the more overhead, and thus worseperformance

The throughput could be a problem for the museum system if the performance

is to poor

9Using packet type DH5 (the biggest packets available). The packet type greatly impacts

performance[9] For more information on packet types refer to [15]

3.5 Bluetooth profiles

Profile definitions are issued by the Bluetooth SIG group Profiles introduces dards for Bluetooth services that implementors should follow In this way fewerinteroperability problems arise when connecting different manufacturers’ products

stan-A profile can be described as a vertical slice through the protocol stack Itdefines options in each protocol that are mandatory for the profile

All profiles are based on the "Generic Access Profile" (GAC) Examples of

pro-files are: FTP, Object Push, Serial Port, Sync, Headset, Dial up etc (see figure 4)

shows a part of the profile stack For a complete and up-to-date list, check [15]

Figure 4: Examples of the profile stack The outermost profile is always the GenericAccess Profile (GAC)

Low power consumption is essential in Bluetooth And since the setup of a nection may take a few seconds it is often appreciated that the connection is keptinstead of closing and reestablishing the connection when needed This is why thereare four sub-states (modes) for an active connection

con-active mode In this state the Bluetooth unit con-actively participates on the tion The master and slave communicates on the same connection.

connec-sniff mode In this mode a slave device will wake up periodically to connec-sniff packets

to itself If it receives any packets it stays "awake" until no more packets arereceived In this way power can be saved between the sleep periods The mode

is especially usable when packets are expected to arrive all the time

hold mode When in this mode the device will not participate on the ACL linkfor the period of the hold time When in hold mode the device stays in thecurrent piconet Usually a device goes into hold mode to free capacity to doother things like: scanning, paging, inquiring or attending in other piconet.park mode The device enters "Low Power Sleep Mode" most of the time when inpark mode It only has to wake up once in a while to synchronize with themaster In this mode the device will give up its active membership of a piconet,but it stays synchronized with it (and of course saves a lot of battery!) Thismeans that no active communication between master and slave is done Thismode is very useful if the Slave device needs no communication with server insome periods But since the Master is not able to wake it from park mode, it

is only the Slave itself that can put it back in active mode

In case of any doubts, Sniff is the least power efficient mode, then Hold, and themost power efficient mode is Park This active connection substate can be chosenthrough the HCI layer

Since low battery usage is one of the major advantages, it should be considered

to implement these in an application, if it is a battery run device

3.7 Security

The security is a key feature in Bluetooth Bluetooth has many features to makeconnections secure Frequency hopping in the RF layer is one of them The LMP

is responsible for Authentication, Authorization and Encryption, and is thereby

central to Bluetooth security

LMP uses the following keys/items when a connection is established ABluetooth device address (48bits) - hardcoded into the device, a private userkey for authentication (128bits), a private user key for encryption (8-128bits) (ifencryption is enabled), a pseudo-random number that shall be regenerated for eachnew transaction (128bits) The keys and random number must be hidden for theuser, so that no overriding or altering is possible

We will not go into full details with processes of authentication, authorization orpairing, since it is only the ideas that are relevant to us For the full procedures refer

to The Bluetooth Documentation [17] or [1] Beyond the possible typing of a code and the accept of an incoming connection these processes happen transparent

PIN-to the user

3.7.1 Frequency hopping

Beside serving as a good way to utilize the hole / available part of the 2.4GHz trum, Frequency hopping is also a good security If you do not know the Frequencyhopping scheme, it is very hard to sniff what is sent on the line The AmericanMilitary consider frequency hopping secure enough in itself (see [1])

spec-3.7.2 Authentication

All links between Bluetooth devices must be authenticated This is done through

a PIN-code or its like A database of known and paired devices is held for easieraccess to common and trusted devices If a device is shown as paired in the database

it is automatically authenticated

3.7.3 Authorization

The authorization happens at service level When a device tries to connect to alocal service it must be authorized to do that Often the user of the device will bequeried if this should be allowed to happen

This means that a device can not be authorized before it has been authenticated

3.7.4 Encryption

Some services also has an encryption option When this option is set it means thatthe connection between the peers must be encrypted Encrypting is for examplegood when a mobile phone communicates with a headset or when a PC is up-linking through a mobile phone, since it protects against unintended listeners Theencryption level is defined in the service and can be between 8 and 128bits

3.7.5 Pairing

Pairing is a process where two devices get a mutual relationship by exchanging keys.The keys must be exactly the same and entered on both devices to make the pairingsucceed When two devices are paired they do not need to authenticate themselves

to each other This is a nice feature for devices which often connect to each other.Because the connection setup can be done in "one click" 10

10The pairing procedure is fully explained on p 1152 and onwards in [17]

3.7.6 The device database

The Link Manager Protocol maintains this database A device can be in one ofthese three categories (Security level):

1 Trusted devices are devices which are already approved of These devices neednot to authenticate themselves Neither do they need to authorize themselves

to access the available services The link key is stored in the device database,and the device is marked trusted

2 Untrusted devices have earlier been linked, and they do not need to ticate themselves again But if they try to access a service they must still beauthorized The link key is stored

authen-3 Unknown devices This is the category of devices not yet in the database.These must authenticate to establish a link Authorization is also necessaryfor access to services to be granted No security information is stored in thedevice database

3.7.7 Device address filtering

If the Bluetooth address of a peer device is known in advance, Bluetooth addressfiltering can be used This is done on application level

We discuss the security in our application briefly in section 3.7

4 Platform – System Engineering

We now have an idea about how Bluetooth works and what kind of basic ments our application has One of our requirements is to have a server part, sendingout the requested data, and another part to ask for the data (the client) We have

require-to choose a platform, and a Bluerequire-tooth stack and development environment (API

Application Programming Interface to the Bluetooth stack) to each of these In this

section we will discuss the different possibilities to each one and we have thereforeseparated the chapter into two parts: The Bluetooth server and the Bluetooth client(see description in section 2.2.3) We will finish the chapter with a discussion of ourchoices

One of our goals with this project was to try different kinds of Bluetooth devicesand different stacks and operating systems The main condition was that we wanted

a system where we were able to make an application capable of using Bluetooth tocommunicate between different types of devices

As described before in section 2.3, we only had access to specific devices Theycover many of the most important types of devices using Bluetooth, like cell phones,PDAs and USB dongles Unfortunately these restrictions do give some limitations

in our choice of stack and API

As we described in chapter two, our Bluetooth server should be stationary Therefore

we pick our two dongles as part of our server-system The dongles will be connected

to a standard PC (i386 architecture)

• D-Link DBT-120 USB-dongle (for PC)

• CSR BUB-103 USB-dongle (for PC)11

These two dongles have driver support on the Windows, Linux and FreeBSDplatforms (our own primary operating systems)

4.1.1 Bluetooth stack implementations

Our first task was to choose a Bluetooth development kit for the server platform.The Bluetooth stack is available in many different implementations, some of themare open source and free, some are not The proprietary ones are very extended infunctionality, have excellent documentation and the support is great, but they areunfortunately typically very expensive Here are some examples:

• Widcomm Bluetooth SDK ($1,295 for Pocket PC version and $1,495)

• Ericsson Application Toolkit (price not found)

11we have 2 of these

• Zucotto Bluetooth SDK (price unknown)

• Rococo Development kid / simulator (2500£ or above 25.000DKr!, a student

version might be achievable)

As an example the Bluetooth SDK from Widcomm, which is the common /driver used with end-user bluetooth products, can be used, but the price is $1,495for a license Both the D-Link and the CSR dongle device and the Windows iPAQuse this stack

stack-These APIs of course falls out of our league, because of our limited funds fromthe university and we will not even consider using them We also found some opensource projects which was available, free and promising:

• Nokia Affix (http://affix.sourceforge.net/)

• BlueZ (http://www.bluez.org)

• IBM BlueDrekar

• Axis OpenBT (http://sourceforge.net/projects/openbt/)

• FreeBSD Bluetooth stack

• Windows XP SP1 (not open source, but API available)

4.1.2 Stacks on Linux

This is a very appealing setup for students since all the software is free

We used the Debian distribution since we heard that it was a good easy-to-usedistribution After installing Linux, which created several problems for us, we had

to settle for a stack

Nokia Affix is a Bluetooth Protocol Stack for Linux developed by Nokia search Center in Helsinki and released under a open source license (GPL) Affixcurrently supports the core Bluetooth protocols like HCI, L2CAP, RFCOMM, SDPand various Bluetooth profiles In the L2CAP and RFCOMM layer, Affix supports

Re-a Socket interfRe-ace just like Re-an ordinRe-ary BSD-Socket interfRe-ace when working withnetworks That is a neat feature which makes the development time a lot faster,

if the developer already know how to program standard networking under UNIXand Linux system Affix actually goes a step further and handles Bluetooth as anetwork device on the Operating System This simplifies the API a lot, but it alsomakes it far from a reference implementation like e.g Bluez (see in later section).Also the naming convention and function names used in Affix API do not comply

to the Bluetooth specifications[17] – they are oversimplified

The Affix package provides control tools for the HCI, development libraries, andserver daemons for SDP etc Affix also have very excellent documentation for theirAPI, with a lot of concrete examples and text explaining it

Affix supports a lot of features:

• Affix is modular implemented

• SMP safe (Symmetric Multi-Processing)

• Multiple Bluetooth devices support.

• Unified interface for all transport drivers It makes it hardware independent.

which again makes it easy to use USB dongles or PCMCIA cards

• Runs on different platforms (including: i386, mac, sparc and ARM)

BlueDrekar is also a open source (with a special IBM license) implementation

of a Bluetooth API It was developed by IBM as one of the first and gave a great set

of interfaces to the stack, which was proprietary The BlueDrekar package includesHCI, RFCOMM, L2CAP and SDP layers BlueDrekar is actually an old referenceimplementation of the BlueTooth standard The stack and modules are availableall the way back to the 2.2.11 and 2.2.12-20 Linux kernels Although it had someokay documentation, good makefiles and sample programs, the project was stopped

in April 2002

BlueZ is the official BlueTooth stack for Linux The stack was initially developed

by Max Krasnyansky at Qualcomm and in 2001 Later Qualcomm decided to release

it under the GPL open source license It was then included as the official stack in theLinux kernel from the 2.4.6 release Any recent kernels have the BlueZ stack build in,either as loadable modules or compiled into the kernel BlueZ provides vast supportfor all the core Bluetooth layers and protocols, like: L2CAP, RFCOMM, SDP, SCO,BNEP etc It also ships with a large amount of tools and sample programs to testthe Bluetooth equipment, which makes it easier for a new developer to make out newcode from the small code fragments of the samples BlueZ, like Affix, comes with anice abstract implementation of the different protocol layers and gives the developer

a standard socket interface to all of them Although the developers behind BlueZ(mainly Marcel Holtman and Max Krasnyansky) have not described their API inany satisfactory (only a small useless FAQ is available) way we realized that theyhave a very active mailing list which almost answers any questions one may haveabout the API

Other features of the API: It has many interesting features:

• Complete modular implementation

• SMP safe

• Multi threaded data processing

• Support for multiple Bluetooth devices

• Unified interface for all transport drivers It makes it hardware independent.

which again makes it easy to use USB dongles or PCMCIA cards

• Device and service level security support

Axis OpenBT is a small open source bluetooth stack for Linux (and some otheroperating systems) that supports the common functions of the different layers: SD-P/L2CAP/RFCOMM Although it supports SDP, it has no SDP parser functions orlibraries at all Neither does it support dynamic registers in the SDP daemon Thisproject has many flaws: almost no documentation at all, and what exits seems to be

is very outdated and deprecated It’s a project that already have been discontinuedbecause of the official announcement of BlueZ implementation into the Linux ker-nel A lot of the open source developers now work with the BlueZ implementationinstead Only one version of this stack has been released before it was rejected

4.1.3 Stacks on FreeBSD

FreeBSD have only implemented one driver and stack for supporting bluetooth.Actually FreeBSD uses a ported source of Bluez, which almost have the same possi-bilities as the Linux version Although no documentation can be found at all, onlyfragments of code bits from the different tools the stack ships with can be used

as a reference The ported BlueZ stack are available in the FreeBSD-RELEASE(currently in version 5.3)

4.1.4 Stacks on Windows

It is only for Windows XP SP1+ that an API for Bluetooth exits See appendixA.1 for installation procedure If hardware is not in the supported list (which isn’tthat long), it will not work correctly According to what we have read you have touninstall any software which come along with with the Bluetooth device, because itwill interfere with the Windows Bluetooth stack We have not tried this because we

do not have a "designed for Windows XP" device The cheapest of the 4 approveddevices is not for sale in Denmark It is a TDK dongle Price in UK includingshipping 8-900,- DKr, but as far we have been able to read on newsgroups andother forums, there seems to be different revisions of it, where only some of themwork

The documentation is very good and good examples are provided

The choice of the client stack was quite limited because of our small selection ofdevices As described in chapter two, our handheld clients devices to be researchedconsisted of these:

• Sony Ericsson T610 (cell phone)

• Nokia 3650 (cell phone)

• Compaq iPAQ 3870 (PDA)

• Compaq iPAQ h1940 (PDA)

In the following sections we start out with some general APIs that to someextend can be used on the different platforms We have split up some of the nextsections into the different devices rather than specific stacks like with the server.This is because handheld devices mainly have very embedded hardware which againmeans a very specific API

4.2.1 Symbian OS

Symbian Operating System[27] provides a nice C++ API to Symbian phones andPDAs It has a lot of examples It has proven to be stable and is very active (newupdates in their API all the time) The Symbian OS package also ships with anemulator, which emulates the small embedded devices like phones and PDAs Itships with different skins to the emulator and one can chose to have a Nokia 3650,Nokia 6230 or a PDA The emulators major downside is that it doesn’t supportBluetooth So a developer can only use the emulator to GUI programming, audioand imaging The Symbian OS has a good and very large-scale documentation,although as we researched it further we can also conclude that it has flaws, poorpart and not present parts, and some of the examples was actually faulty

4.2.2 Java

Of course the Java language would be preferable in our situation This would give

us a lot of flexibility especially in our client, such that every visitor in the museumonly had to have a Java enabled cell phone instead of a Symbian OS (Series 60)phone It also gives us some other advantages like more rapid development because

of the abstractions and high-level programming language

When developing Bluetooth applications in Java there are quite a differencedoing it on PDAs or on cell phones Cell phones and their limited capabilitiesdoes not support the full-scale Java API and we would therefore be forced to useJava J2ME (Java Micro Edition), which is a special Java environment developed forlimited devices In order to do so, the cell phone has to support MIDlet 2.0 (due tothe lack of socket support in MIDlet 1.0)[51]12and the JSR-82 standard[49] must be

implemented The JSR-82 standard describes the Java API for Bluetooth towardsthe stack and in our case with the cell-phone, the stack is already implemented

The PDAs supports ordinary Java J2SE SDKs and can therefore use the standardJava API But in order to support Bluetooth, the application has to use a librarythat implements the JSR-82 standard and supports the given stack For the JSR-

82 standard on standard Java there exists different implementations for different

12A MIDlet is a J2ME application that can be run on practically any mobile communications device

that implements a Java virtual machine

stacks During our research we did not find a lot of them, but we have found andlooked at two: Avetana Bluetooth and Atinav Of cause J2ME can also be used onPDAs if MIDlet 2.0 and JSR-82 is provided on the PDA.

avetana Bluetooth software is based on the most widely spread bluetoothprotocol stacks and does not use special Bluetooth hardware or software It allowsprogrammers to easily use and offer bluetooth services Avetana Bluetooth is a JavaJNI13 implementation of JSR-82 for J2SE and different stack implementations.

The implementation is actually quite platform independent and supports ent stacks on various platforms:

implementa-be found at: http://www.avetanagmbh.de/avetanagmbh/produkte/jsr82.eng.xml

Atinav Bluetooth provides their own stack implementation and an API for

a wide variety of operating systems like: Windows, Windows CE (for PDAs) andLinux Although it seemed very nice and probably had some good APIs and doc-umentation we couldn’t get munch information out of them and their productsseemed quite expensive and vain The Atinav bluetooth homepage can be found at:http://www.avelink.com/bluetooth/index.htm

4.2.3 Sony Ericsson T610

It is possible to get an Java API from Sony Ericsson for programming to the Mophunoperating system[26] Unfortunately the Java API does not support the JSR-82[49]

as was mentioned before nor does it support the MIDlet 2.0 standard This gives us

no chance to program it in Java We could neither find an API for C++ and sinceSony Ericsson have no intention on releasing Bluetooth support for the programmerfor this device we had to give up programming this device

4.2.4 Nokia 3650

Because the 3650 also only supports the MIDlet 1.1 standard and have no supportfor JSR-82 neither, we can not use the Java API We had to look for another API

13Java Native Implementation is a interface for writing Java native methods and embeddeding the

JVM into native applications like stack implementations as BlueZ, Widcomm etc.

At forum.nokia.com [19] we found an C++ API and some example applications forSymbian OS 6.1 (as mentioned before) The Symbian OS and the emulator seemed

to work well with the Nokia 3650

4.2.5 Compaq iPAQ h3670 running Familiar Linux

From a previous project[8] we had this device running the small Linux distributionFamiliar Linux made especially for the iPAQ We found drivers on the Internet andgot the BlueZ stack up and running (See appendix A.4) Unfortunately we had

to return the device which was borrowed from DISTlab on DIKU We were quiteunhappy about this since the potential of this device was quite promising

4.2.6 HP iPAQ h1940 running MS Windows Pocket PC 2003 fessional

Pro-After reading about programming Bluetooth on Pocket PC 2003 on the Microsoftdeveloper site, we observed that the API only supports a few basic functions forBluetooth, such as enable and disable Bluetooth So basically it isn’t very usefull.This iPAQ also uses a special edition of the Widcomm stack But the WidcommAPI even for a PDA is quite expensive (See 4.1.1)

4.3.1 Bluetooth Server

Since the Windows XP stack is implemented in a way such that it will work only

with a few specific hardware devices (which are not the common ones), we don’t

want to use the Windows software Besides we do not have one of the hardwarecompliant devices

We chose to use a stack on the Linux platform because of the availability andcosts We also already had a Linux box up and running and had a lot experiencewith it One of us also have great experience with the FreeBSD platform, but wedid not chose to use it mainly because of its recently support for Bluetooth and thelack of examples, documentation or mailing lists

Actually, as we see it, there is only two competitors of stacks on the Linuxplatform for our bluetooth server: Affix and BlueZ We have chosen to implementour server with a BlueZ stack due to the fact that it is the official Linux bluetoothstack It is already a great part of the kernel and userland application coming with

a standard Linux distribution It has also very good support for all our devicesand provides all the standard Bluetooth core layers and protocols in a very flexiblemanner (you can code like it was standard network sockets) This will make it some-what easier to implement our server, because we already have good knowledge aboutstandard network programming like Berkeley-Sockets Also the active BlueZ mailing

lists with quick answers and many qualified and skillful developers compensated forthe lack of API documentation.

Although Affix did have some excellent documentation and also covered a lot ofthe core layers it seemed like it didn’t follow the standards of naming conventions,which bothered us a lot This was because we only had knowledge from the Blue-

tooth specifications[15] and our Bluetooth book ”Bluetooth 1.1 - Connect Without Cables”[1] where the proper terms was used.

We never actually tried to install and use the Affix stack since we had mainlygood experiences with Bluez The install and usage instructions to BlueZ can befound in section A.4

4.3.2 Client

We have chosen to implement our handheld client on the Nokia 3650 Series 60 cellphone using the Symbian operating system Of course our implementation using theSymbian API isn’t all perfect It can only be used by phones supporting Symbian

OS and Series 60 (a full list of supported Series 60 can be found at [29]) But as

we said before; our application i just a proof-of-concept The neatest thing could

be to implement the client in a Java environment, such that the application could

be portable to almost any device, such as other phones (supporting Java of course)and PDA devices But since we did not have a phone that were Java Midlet 2.0 andJSR-82 compatible, we where bound to use the 3650 and the Symbian operatingsystem Though if we had or could get a cell phone supporting MIDlet 2.0 andJSR-82, we would definitely think that it was worth spending some time trying itout

When we started to look at Symbian the documentation and HowTos were whelming The huge information and documentation did, that the installation pro-cedures, tips and tricks were unfortunately scattered around in different guides,which made the installation pretty time-consuming We have collected this infor-mation in an ultra short HowTo

over-See the installment and user guidelines for the Symbian OS in appendix A.3.There is also a small guide on how to develop your first "Hello World" program

5 System Design

In section 2 we explained the scenario and what capabilities the application shouldcontain On basis of the scenario we will, in this section, discuss the Bluetoothrelated design issues based upon the theory presented in chapter 3 and with thechosen platforms in mind Though we might not mention it so much, one of themajor concerns in the back of our minds is that it should as be fast and as easy touse as possible for the visitor

Though the Bluetooth protocol implements master/slave switches, it stillmakes sense to define who is the server and who is the client The obviousthing to do is to let the Museum have the server role The major reasonsfor this is, that it makes good sense to let the Museum advertise a museum ser-vice This also gives the client device the opportunity to go into power saving mode

We will now go through the problems as they arise during the scenario Thismight not be the in which we have addressed them when designing/implementingthe application, but it gives an intuitive way to organize them

When the visitor has installed the Museum software and started it on his device,

he is ready to enter the museum When the client enters the museum, he will want

to connect to a server to get information about a certain item A discussion of when

to connect is given in 5.1

The next thing for the client to do, is to establish a single connection, but first

a few things need to be considered Is it possible for the client to know where

it is in the museum? We will address this in 5.2 And what about the networktopology? Considerations about where to put Bluetooth access points, and othernetwork design issues are covered in 5.3

To establish the connection we will follow the procedure described in 3.3.7 Somesecurity concerns must also be made when establishing a connection, these arecovered in 5.5 We will make some considerations about SDP in 5.4 and next weneeded to decide what protocol we want to use for transferring data (see section5.6)

We are now capable of establishing a connection, but how should we use it totransfer data? This will be discussed in section 5.6.1

We would like to establish connections as proposed in the Bluetooth specification.The server advertises a service where connection information can be found Theclient gets this information and after that it logs on See also 5.6

Should the connection remain on? We will here give a short discussion onconnection strategy We see the following possibilities:

1 connect, download all data and close

2 connect, download selected data on demand and close

3 always on and download on demand

The concept of downloading unnecessary data is not appealing to us, though

it might be the best concept if only a small amount of data is available on theBluetooth server "Connect on demand" is very appealing because fewer Bluetoothserver dongles are needed than if always on strategy is chosen The downside ofthis strategy is, that the connection establishment is very time consuming and

it therefore will be annoying to the visitor to wait for the new connection to beestablished This is why we will follow the "always on" strategy Data will only

be downloaded when the user asks for information (by button press(es)) A devicecould be set in "park mode" when not busy for a while, to save energy and freebandwidth on the server

With this approach we get a client, which tries to connect to a another Bluetoothserver as soon as it looses its initial connection In that way the reconnection can bedone while the visitor might be doing something else (than waiting for the connection

to be established, i.e watching the exhibit item etc.)

The discussion of what device to connect to is covered in 5.3

If it is not possible to get a connection, the user of the client should be told tohave patience until resources are released and a connection can be established Theclient should try to reconnect all the time transparent to the user

5.2 Positioning

In the optimal scenario the visitor places himself in front of an exhibit item and the

information about it pops up on his device The problem is: The visitor’s device

can’t see where it is The Bluetooth Radio is not suited for distance measurements,actually it is pointed out in the specification, that attempt to do so should not bemade (See [11]), so it can not even see what devices it is close to It can only knowwhether a device is within range or not

This means that the we need to find another way for choosing the wanted exhibititem:

1 Triangulation to position the client

2 An external tracking solution (not Bluetooth) could be developed - a chipcarried or camera surveillance

3 Handle it in Bluetooth on the cost of more user interaction